LCD Zeichenfehler mit pfleury lib

Hi,

die Fleurydateien kann ich überhaupt nicht empfehlen. Bei der LCD.c ist
schlecht, dass sie gar nicht funktioniert und zum anderen zu lang ist.
Das geht auch kürzer. Wer will denn schon eine 8 und eine 4 bit Version
zur Ansteuerung in einer Datei haben.

Ich komme auf weniger als ein Drittel vom Umfang her und lese auch das
Busyflag aus.

Rodrigez

@Rodrigez
Zwischen 4bit Mode und 8bit Mode wird durch #defines während
Kompilation ausgewählt. Es wird also kein unnötiger Code erzeugt.

Hat dann jemand noch andere libs zum austesten?

@Peter
Was ich net ganz verstehe: Dein lib läuft bei mir soweit ohne Probleme
mit dem atmega16, testweise angeschlossene at90s8515 und atmega8535
geben auf dem Display keinen Mucks von sich.
Und wie angesprochen klappen die funktionen wie z.B. clrscr() nicht.
Bin am verzweifeln und um jede Hilfe dankbar :)

Gruß
tacklemoe

@tacklemoe
Welchen Quarz verwendest du bei at90s8515 und atmega8535 ?
Ich habe die Timings meiner Lib für 4 Mhz optimiert.

Ich hab's mit verschiedenen Takten probiert, von 1 - 8 Mhz.
Bei 4 Mhz lief's am besten, aber auch da gibt's Zeichenfehler.

Wie lang ist das Kabel zwischen AVR und LCD ?

Hmm, gesamtgesehen schätze ich mal ca. 50 cm

Ja das ist aber doch sehr lang. Da wurdert es mich nicht dass du
Störungen hast. Mein Kabel ist etwa 12cm lang.
Versuche es mit einem kürzeren Kabel.

Hmm, weißt du ne maximallänge oder so?
War halt so ein altes IDE Kabel das ich für den Zweck mißbraucht hab ;)
Aber ich werd's mal demnächst kürzen und testen, danke mal für den
Tipp :)

@Peter:
Hab jetzt die Kabel gekürzt und klappt auch fast alles, nur Sachen wie
der clrscr() leider immer noch net. Die Zeichen werden aber immerhin
schon korrekt dargestellt :)

Gruß und danke
tacklemoe

Frohe Weihnachten allerseits,
kann es sein, das die Funktion clrscr() nicht funktioniert, da die
Reihenfolge in der lcd.h nicht die selbe ist wie in der lcd.c ?

Beispiel:

lcd.h
extern ... function1(...)
extern ... function2(...)
extern ... function3(...)

lcd.c
... function1 (...)
{ x y z}

... function2 (...)
{ w u v }

... function3 (...)
{ w u v }


Änder einfach mal die Reihenfolge der Aufzählung in der LCD.h und
probier es aus oder schreib einfach mal lcd_command(0x01); statt der
Funktion.
Reini

Ne, das klappt leider auch net :(
Das einzige was den Screen zuverlässig löscht ist ein
lcd_init(LCD_DISP_ON);
und damit auch nicht ganz im sinne des erfinders ;)

@tacklemo:

Eine Idee hätte ich noch, die sogenannte "execution time" beträgt bei
meinem Display für diesen Befehl 1,64ms.
Füg doch einfach doch ein delay von 2ms ein am Ende der CMD-write
Funktion(siehe unten)
Reini

else {    /* write instruction (RS=0, RW=0) */

       /* output high nibble first */
       LCD_DATA_PORT = (data>>4)&0x0F;
       lcd_e_toggle();

       /* output low nibble */
       LCD_DATA_PORT = data&0x0F;
       lcd_e_toggle();
     delay(2000);

tacklemo hat mit per email mitgeteilt dass ein zusätzlich hinzugefügtes
lcd_waitbusy() vor lcd_command() die Probleme bei seinem Display
behoben hat.

Offenbar hat tacklemo ein LCD-Display erwischt das einen nicht 100%
kompatiblen Display-Controller beinhaltet.

Hmm, ja muss tatsächlich am Display Controller liegen. Ich werd mal
gucken ob ich ein anders herkrieg zum testen.
An der Lib liegt's wohl nicht, also danke Peter für die Hilfe und
deine coole lib :)
Achso ich hätte einen Verbesserungsvorschlag:
auf www.jalcd.de unter "Schematics" ist zu sehen wie man die
Hintergrundbeleuchtung per Software steuern kann.
Vielleicht kannst du da ja in deine lib eine Funktion zufügen die im IO
Mode auch die Hintergrundbeleuchtung steuert (is ganz einfach aufegbaut
und braucht nur eine weitere Leitung).

Gruß und thanks
tacklemoe