HD44780 ähnlicher Controller: Seltsames Verhalten

[SeriousD]

Hallo liebe Community,

ich programmier seit einigen Tagen an einem kleinen Projekt und möchte dazu ein OLED Display betreiben. Um genau zu sein ist es dieses hier.
Hier das Datenblatt.

Nun zum Fehlerbild:
Es geht nicht. Es zeigt schlicht nichts an. Bzw... tut es das mal und mal nicht und seit dem letzten "Crash" garnicht mehr. Das letzte mal hatte ich einfach zu schnell auf das Display geschrieben - danach hat es nichtsmehr gemacht.
Das Display initialisiert aber richtig - ich debugge via UART/COM-Port und der Controller bleibt nicht in den initialisierungsroutinen hängen.
Da es mal ging und ich elektronisch auch nichts geändert habe gehe ich davon aus, dass das Problem auf jeden Fall nicht in der Verkabelung liegt - der Vollständigkeit wegen aber hier nochmal die Pinbelegung:

Code: Alles auswählen

#define LCD_DATA	PORTC 
#define LCD_DATA_D	DDRC  
#define LCD_INPUT	PINC 

#define LCD_D4		PC0
#define LCD_D5		PC1
#define LCD_D6		PC2
#define LCD_D7		PC3

#define LCD_CTRL	PORTA 
#define LCD_CTRL_D	DDRA 

#define LCD_E		PA3 //Enable Portpin
#define LCD_RS		PA1 //RS Portpin
#define LCD_RW		PA2 //RW Portpin

Ja. JTAG ist deaktiviert - PORTC funktionert wunderbar.

Das Display selber hat vorher ein wenig gelitten - ich hatte es versehentlich verpolt angeschlossen und der Displaycontroller wurde heiß. Danach hat das Ding aber bei richtiger Polung trotzdem brav sein "Hallo Welt" angezeigt.
Da ich mir danach jedoch nicht so ganz sicher war ob das Display noch geht habe ich erstmal zu Testzwecken eine Libary aus dem Internet genommen und diese entsprechen angepasst - dies waren nicht nur die Pins sondern auch die Initialisierung die bei diesen Display ein wenig anders ist. Ursprünglich war die Libary für diese kleinen Zweizeiligen Pollin Displays gedacht.

Hier meine Inintialisierung:

Code: Alles auswählen

void lcd_init() {

	//Portrichtungen setzen
	sbi(LCD_DATA_D,LCD_D4);
	sbi(LCD_DATA_D,LCD_D5);
	sbi(LCD_DATA_D,LCD_D6);
	sbi(LCD_DATA_D,LCD_D7);

	sbi(LCD_CTRL_D,LCD_E);
	sbi(LCD_CTRL_D,LCD_RS);
	sbi(LCD_CTRL_D,LCD_RW);

	INIT_DELAY();

	//LCD Initalisierungssequenz
	writeMode();
	commandMode();

	//Function Set: 0 0 1 DL N F — —
	#ifdef C080204	//Pollin init C080204
	sendNibble(0x2); //4-Bit Mode (DL=0)
	_delay_ms(10);
	#else	//Init for EA W162-X3LG
	sendNibble(0x3);
	sendNibble(0x3);
	sendNibble(0x3);
	sendNibble(0x2); 
	_delay_us(5);
	
	sendCommand(0x28);
	sendCommand(0x08);
	sendCommand(0x06);
	sendCommand(0x17);
	sendCommand(0x02);
	#endif

	unsigned char cmd=CMD_FUNCTION;
	if (LCD_LINES!=1) cmd |= BIT_N; // Anzahl Zeilen
	if (LCD_5X10) cmd |= BIT_F; //Zeichenhöhe
	

	//sendCommand(cmd); // 4-Bit Modus, Zeilen und Font setzen
	_delay_ms(10);
	//Display On/Off: 0 0 0 0 1 D C B
	sendCommand(0xC); //Display on, no cursor, no blink
	//Clear Display: 0 0 0 0 0 0 1
	sendCommand(0x1); //Clear Display and Cursor home
}

Um ehrlich zu sein weiß ich nicht genau woher das komische Fehlerbild kommt - mir scheint es fast so als wenn es mal ginge und mal nicht.

Weiß irgendjemand Rat?

Mit freundlichen Grüßen
SeriousD

[durchgebrannt]

Sehe ich das richtig, dass du das BUSY-Bit nicht nutzt und daher feste Wartezeiten irgendwo definiert sind?

Ich habe gerade einmal die Datenblätter des HD44780 und das deines Moduls verglichen. Dein Display kann deutlich schneller angesteuert werden als der HD44780. Sind also die Wartezeiten für den HD eingestellt, sind derartige Probleme auszuschließen.

Dass das Display durch die Verpolung gestorben ist, ist sicher möglich, halte ich aber für unwahrscheinlich. Ein vergleichbares Pollin-Display war selbst durch dauerhafte Verpolung nicht tot zu bekommen. Trotzdem ist das natürlich Spekulation.

Die sicherste Variante, um eine sichere Funktion des Displays zu überprüfen wäre das Abfragen des BUSY-Bits. Wenn das Display auf die gesendeten Kommandos nicht antwortet müsste man dann mit einem Logic Analyser den Bus untersuchen.

(Am Rande: In unserem Dropbox-Ordner liegt noch meine Display Bibliothek, die das BUSY-Bit nutzt )

Gruß Jannis

[SeriousD]

Moin Jannis,

danke für die Antwort.
Ja die Libary nutzt das Busy-Bit, an diese Fehlerquelle habe ich bereits auch gedacht.
Innerhalb der send-Commands ist auch ein BusyWait() Implementiert.
Das komische ist, dass es halt auch nach der Verpolung ging - ich konnte Text anzeigen - alles cool.

Die Funktionsverweigerung stellte sich, meiner Meinung nach, zufällig ein. Manchmal gehts halt und manchmal nicht - das Display ist auch über Ribbon-Cable + Pinheader mit dem Steckbrett verbunden, ich gehe nicht von einem Wackler aus.

Beste Grüße
Dennis

[durchgebrannt]

Berücksichtigst du zum Systemstart auch eine ausreichende Wartezeit, damit der Displaytreiber zuverlässig gestartet ist und nicht sporadisch irgendwo hängen bleibt?
Um ein Hardwareproblem auszuschließen könntest du die Signale am Display überprüfen. Kabelbruch oder ähnliches führt bekanntlich auch zu sporadischen Ausfällen.

Gruß Jannis

[SeriousD]

Der Fehler ist behoben.
War ein wenig tükisch:
Ich habe immer den Controller, der das Display anspricht resettet, den Displaycontroller selbst aber nicht. Das funktionert halt nur, wenn dieser vom der Betriebsspannung getrennt wird. Dabei sind komische Effekte aufgetreten, grade, wenn man den Displaytreiber noch am entwickeln ist und ständig Änderungen in der Software macht.

Also das Display lässt sich problemlos mit einer HD44780 Lib ansteuern, wenn man die Initialisierung der aus dem Datenblatt des OLED-Displays anpasst. Danach immer auf vernünftigen Reset achten und die Kiste läuft.

Beste Grüße
SeriousD