Powertip PC1602-F treibt mich zum Wahnsinn...

[TDI_Cruiser]

Ich versuche obiges Display im 4-bit mode mittels eines AVR mega8 anzusteuern.
Ich habe die Initialisierung schon bei etlichen anderen 2x16er Displays mit HD44780 erfolgreich eingesetzt.
Nur hier bekomme ich keine Zeichen hin.
(ich fürchte, es ist was ganz banales )

Das Display zeigt bei Vo an Masse in der oberen Zeile alle Pixel an. Es ist also anscheinend noch auf 1-zeilig programmiert.

Beschaltung : R/-W, D3-D0 an Masse, RS, E und D4-D7 auf Port D des Mega8. Vcc ebenfalls mit 5V besaftet.
Timing habe ich nachgemessen: Stimmt, alles Mindestwerte werden eingehalten.

Datenblatt ist recht dürftig, aber Pinbelegung hat es hergegeben, nur nicht ob es hd44780 kompatibel ist.......

Ich hoffe, jemand hat das Ding (war von Pollin, gibts aktuell nicht mehr) schon mal ans Laufen gebracht, denn ich habe 2 Stück davon und beide gehen nicht......

HFH,
Dieter

[Finger]

Ein anderes Display an dieser Konfiguration/Hardware geht?

[TDI_Cruiser]

Wäre mal mit etwas Fädelaufwand zu prüfen.....
Das Display ist zwar gesockelt, aber diese Pinbelegung hat kein anderes.....

Ich werde mal einen Adapter friemeln, und berichten.

[xoexlepox]

Das Display zeigt bei Vo an Masse in der oberen Zeile alle Pixel an. Es ist also anscheinend noch auf 1-zeilig programmiert.

Sowas hatte ich mal bei einem anderen (Billig-) Display. Die Ursache was das Timing: Sowohl nach dem Besaften, als auch nach der Initialisierungssequenz ein paar (hundert) Millisekunden warten. Vielleicht ist es ja der gleiche Effekt.

Edith meint: Ich hatte mich mit diesem Display herumgeschlagen. Und das "Busy-Bit" ist vor der abgeschlossenen Initialisierung nicht verfügbar.

[TDI_Cruiser]

Tja, was soll ich sagen,

in einer anderen Schaltung ist bereits eines verbaut, das geht, also mal flugs alle 3 probiert
- ich habe wohl ein totes Pferd geritten - das eine will auch nicht in dem funktionierenden Design.
aber das zweite geht, nur nicht in meiner neuen Schaltung.

Aber was habe ich denn in der neuen Schaltung verbockt....., mal suchen.....

@Finger: danke für den Denkanstoß, manchmal steht man sich selber im weg, *kopf-auf-tisch-hauen*

[TDI_Cruiser]

@xoxeplox:
ich habe 150ms drin: siehe unten.
die delay_ms und delay_us sind mittels gpio vermessen, die stimmen bei 50 und 100

lcd_nibble gibt die oberen 4 bit aus und strobt den Enable für >400ns
lcd_command gibt erst die oberen, dann die unteren 4 bit aus, jeweils mit lcd_nibble

Hier mein Code-snipplet:

Code: Alles auswählen

	LCD_DISABLE;            // Enable low
	LCD_RS_OFF;             // RS low -> command register

	delay_ms(150);           // Delay >15ms (Controller startup Delay)

	lcd_nibble( 0x30 );
	delay_ms( 8 );          // wait >4.1ms

	lcd_nibble( 0x30 );
	delay_us( 260 );        // wait >100us

	lcd_nibble( 0x30 );     // 8 bit mode
	delay_us( 260 );        // wait >100us

	lcd_nibble( 0x20 );     // 4 bit mode
	delay_us( 260 );        // wait >100us

	lcd_command( 0x2C );    // 2 lines, 5*7
	lcd_command( 0x08 );    // display off
	lcd_command( 0x01 );    // display clear
	lcd_command( 0x06 );    // cursor increment
	lcd_command( 0x0C );    // disp on, no cursor, no blink

[Fritzler]

Probier mal diese Lib:
Doku: http://homepage.hispeed.ch/peterfleury/ ... __lcd.html
Sauglink: http://homepage.hispeed.ch/peterfleury/lcdlibrary.zip

Die frisst bisher jedes dieser Displays.

[TDI_Cruiser]

@Fritzler: habe deinen Tip mal befolgt, in lcd.h alle meine Portdefinitionen geändert und es geht auch nicht.....
Da muß was in der Hardware sein. obwohl ich alle Leitungen einzeln durchgetestet habe...

[Fritzler]

In der Tat komisch dann.
Pack doch mal die init in eine Dauerschleife und klingel die Signale am LCD mit nem Oszi ab.

Ganz doofe Frage am Rande:
Ausversehen die falschen 4 Bit angeschlossen?

[TDI_Cruiser]

@Fritzler: das mit der Init-Dauerschleife habe ich auch schon gemacht.
da habe ich auch die Timings vermessen und mit der spec verglichen.

Ich habe DB4-7 vom Display an PD4-PD7 vom ATmega8 angeschlossen und DB0-3 vom Display auf GND (so wie immer)

[andreas6]

Hallo,

das vierzeilige Display an meinem AVR-NetIO läuft auch im 4-Bit-Mode, dort sieht aber der Init etwas anders aus:

Code: Alles auswählen

void lcd_init (void)
{	
	LCD_Port_DDR = LCD_DataOutput+(1<<LCD_RS | 1<<LCD_RW);
	//separater port am pollin-board
	LCD_Enable_DDR |= (1<<LCD_E);
	_delay_ms( LCD_BOOTUP_MS );
	for (unsigned char a=0;a<3;a++)
		{
		lcd_write (0x22,0);	//Init in 4 Bit Mode
		lcd_write (0x80,0);	//Set DD-Ram Adresse = 0
		}		
	lcd_write (0x28,0);	//mehrere Zeilen
	lcd_write (0x0C,0);	//Display On
}		

Das läuft seit nunmehr drei Jahren sauber. lcd_write fragt immer Busy ab und kehrt bei Erfolg sofort zurück. Kommt Busy nicht, wird per Timeout abgebrochen. Klappt prima.
Edit: Zeile eingefügt, da fehlte eine Klammer.

MfG. Andreas

[TDI_Cruiser]

@andreas6: ich habe leider den R/W pin nicht in der Hand, der ist auf Ground, daher kann ich das busy nicht auswerten.
Das mehrfache 4-bit mode setzen kann ich ja mal probieren.
Interessant wären natürlich die Zeiten, die dann bei Warten auf busy so anfallen, bzw. das timeout, das könnte ich ja mal übernehmen.

Gruß, Dieter

[Burga]

Hossa,

wenn mich nicht alles täuscht ist das Bascom Code. Hatte/Hab ein ähnliches Problem :

Immer wenn ich eine Variable, z.B. Temperaturdaten, an das Display schicke, fängt es danach an zu spinnen. Probiere mal aus was passiert wenn du einen fixen String an das Display á la "Hello World" schickst und anschliessend nach Tastendruck eine Variable.

Als Workaround hab ich mir eine Routine gebastelt die Ziffern einer Variable auseinandernimmt und einzelnd als fixen String ausgibt("1", "2", "3" ...). Nicht gerade elegant und Speicherfreundlich, aber es tut.

Edit sagt: Sorry hab zu schnell gelesen, trifft hier wohl nicht zu.

Gruß Jan

[andreas6]

Hallo,

ich habe leider den R/W pin nicht in der Hand, der ist auf Ground, daher kann ich das busy nicht auswerten.

das ist schade, damit wird das immer eine relativ träge Anzeige bleiben. Die Zeiten sind nur aus dem Datenblatt des 44780 geholt, also:

Code: Alles auswählen

// Warte-Zeiten fuer LCD-Befehle
#define LCD_BOOTUP_US           15000
#define LCD_ENABLE_US           1
#define LCD_WRITEDATA_US        46
#define LCD_COMMAND_US          42

Mit Busy-Auswertung geht das dagegen richtig fix, die Anzeige ist schneller als das Auge.

MfG. Andreas

[TDI_Cruiser]

Gelöst: es war ein analoges "Problem":

Das Poti für die Vo war "grundlos". d.h. meine Vo war immer zu hoch.
Eigentlich hätte ich es mir schenken können. das Display ist am besten bei V0=0V.
Werde es beizeiten durch eine Drahtbrücke ersetzen.

ich habe zwar die die Timeouts hochgeschraubt, hat aber alles keine Wirkung "gezeigt"
Ich werde die mal wieder auf die ursprünglichen, getesteten Werte reduzieren.

Vielen Dank an alle die geholfen haben.

[TDI_Cruiser]

So, ich habe mittlerweile eine stabile Initialisierung, aber ich muß noch am Enable Strobe rumbasteln, weil ich eine "unglückliche" Leitungsführung habe:
D4 Leiterbahn ist halb so kurz wie D5-D7, das Display ist 25 mm über der Platine mit Pfostenleisten montiert. da "verhaspelt" sich das Display schonmal.

Eine Loop, die immer das ganze Display füllt und dann 100ms wartet, bringt das Fehlerbild ganz schön zu Tage.
Damit kann ich meine "boardspezifischen" Timings auloten, und dann gebe ich noch mal 50% zu, dann sollte es sicher funktionieren.

@burga: Das sieht mir nach einer zu geringen Wartezeit nach dem Enable aus, denn der Controller muß das Zeichen ja auch noch "verarbeiten", den Cursor weiterschalten, und da der nur mit 120-150 Khz läuft ist der erheblich langsamer als der Atmel, der im MHz Bereich (1-16 MHz) läuft.
Durch die Einzelzeichenausgabe gibst du dem Display dann (mehr als) genügend Zeit. -> daher gehts dann.

Ich habe gerade getestet: Das Display spinnt, wenn ich nach der fallenden Flanke nicht lange genug warte.
Ab 7µs geht es, ich werde also 10 µs nehmen, damit habe ich keine Fehler mehr feststellen können.

Nach den Commands habe ich noch mal 45 µs (etwas mehr als die 39µs aus dem Datenblatt)

Ist schon blöd, wenn man in dieser Beziehung "blind" ist. ich werde mal für folgende Designs den R/-W mit verdrahten, wenn ich einen Pin dafür übrig habe.....

Ich nutze zwar kein Bascom, mir ist traditionsgemäß C mit Winavr im AVRStudio am liebsten - da habe ich "tieferen" Eingriff.


Gruß,
Dieter

[shaun]

Wenn im Datenblatt keine Timingangaben stehen kann man es ja eigentlich nicht richtig machen
Würde man sich aufs 44780-DB verlassen wäre klar: Daten und RS müssen nach E->0 10 resp. 20ns valid bleiben. Das verbietet im Prinzip einen einzelnen Portbefehl, aber zwei direkt hintereinander müssen selbst in Assembler auf einem 20MHz-Controller noch gehen - solange sie nicht zusammenoptimiert werden
Unterschiedliche Leitungslängen dürfen kaum etwas ausmachen, das ist hier ja kein DDR2-Speicherbus, den Unterschied im einstelligen ns-Bereich macht die sowieso notwendige Wartezeit von einem Portbefehl wett.

[Burga]

Kurz und knapp gesagt mein Problem war ein anderes.

[...]
@burga: Das sieht mir nach einer zu geringen Wartezeit nach dem Enable aus, denn der Controller muß das Zeichen ja auch noch "verarbeiten", den Cursor weiterschalten, und da der nur mit 120-150 Khz läuft ist der erheblich langsamer als der Atmel, der im MHz Bereich (1-16 MHz) läuft.
Durch die Einzelzeichenausgabe gibst du dem Display dann (mehr als) genügend Zeit. -> daher gehts dann.
[...]

Soweit, so klar. Er nimmt halt die ersten nibbles nicht war und interpretiert die nachfolgenden dann ggf. falsch. Bei mir handelte es sich definitiv um ein Bascomproblem, da wenn ich eine Variable per Displaybefehl (In meinem Fall "LCD $string") Mist rauskommt und (Buskommando)"LCDCOMMAND $commandnible+$stringhighnibble":"LCDCOMMAND $stringlownibble" mir das richtige Ergebnis liefert. Dabei ist auch egal ob der String nur aus einem Zeichen oder aus mehreren Zeichen besteht (Strings sind in Bascom Null terminiert, also "sizeof $string" würde der tatsächlichen Anzahl der enthaltenen Zeichen entsprechen).

Hab das aber vor einiger Zeit schon den Jungs von MCSelec gemeldet, vielleicht haben die das inzischen ja gefixt.


Wünsche euch einen guten Rutsch in das neue Jahr.

Gruß Jan

[TDI_Cruiser]

Hmm,

Ich habe zwischen den nibbles minimalste Wartezeit (1,2µs beim Atmega8-16MHz), die sich bei dieser Konstruktion ergeben, nur nach dem zweiten nibble, da muß ich die 50us warten :

Code: Alles auswählen

static void lcd_nibble( unsigned char b ) 
{
#define otherbits (LCD_DATA & ~(0x0F << LCD_DATA_ofs))

	LCD_DATA = otherbits | (((b & 0xF0) >> 4) << LCD_DATA_ofs );
	LCD_ENABLE;
	LCD_DISABLE;
}
static void lcd_byte( unsigned char d )
{
	lcd_nibble( d );
	lcd_nibble( d << 4 );
	delay_us( 50 );                 // > 45us
}

Laut Datenblatt dürfen die Nibbles nicht kürzer als in 500ns gesendet werden. Das sollte man erst mal hinkriegen...