I2C LCD an ATmega8 - Eichelmann Libary

Udo schrieb:
> Beispiel Belegung:
> PCF >  7   6    5   4   3   2   1   0
> LCD >  E Light R/W  RS DB7 DB6 DB5 DB4
>
> Die LCD Befehle in der i2clcd.h habe ich dementsprechend angepasst.

Hast du nicht.

1

#define LCD_E_PIN      2

Oliver

Ah, ok, ich habs andersrum verstanden.

Oliver

@ Udo (Gast)

>PCF >  7   6   5   4   3    2  1   0
>LCD > DB7 DB6 DB5 DB4 Light E R/W  RS

Funktioniert nicht! Die Lib ist an der Stelle eine schöne Verarschung! 
Die Daten-Pins sind NICHT frei konfigurierbar wie z.B. bei Peter Fleurys 
LCD Ansteuerung! Die Defines sind irreführend!

Die Datenbits MÜSSEN auf P0-P3 liegen, allerdings sind die Steuerpins 
RS, RW und E dann auf den oberen Bits frei konfigurierbar.

PCF >  7   6   5   4   3    2  1   0
LCD > Light E R/W  RS DB7 DB6 DB5 DB4

Ach ja, es ist auche in netter Bug drin, der nur deshalb nicht auffällt, 
weil die LCDs SEHR laaaaangsam sind bzw. 0ns Hold Zeit benötigen. Wer 
findet den Bug? ;-)

1

//-  Write byte to display with toggle of enable-bit

2

void lcd_write(unsigned char value)

3

{

4

  lcd_write_i2c(value | LCD_E);    //-  Set enable to high          

5

  lcd_write_i2c(value | LCD_E);    //-  Send data, keep enable high     

6

  lcd_write_i2c(value & (!LCD_E));  //-  Set enable to low  

7

}

Hier ist ein Leidensgenosse ebenfalls am Werk, wenn gleich auch nicht 
sonderlich erfolgreich, was vor allem an dem reichlich chaotischen 
Vorgehen liegt.

Beitrag "LCD am I2C Bus"

Falk Brunner schrieb:
> Ach ja, es ist auche in netter Bug drin, der nur deshalb nicht auffällt,
> weil die LCDs SEHR laaaaangsam sind bzw. 0ns Hold Zeit benötigen. Wer
> findet den Bug? ;-)

Der ! müsste ein ~ sein.

Aber wo hast du den Ausschnitt her?
Im Zip-File des TO sieht die lcd_write so aus

1

void lcd_write(unsigned char value)

2

{

3

  lcd_write_i2c(value | LCD_E);    //-  Set enable to high          

4

  lcd_write_i2c(value | LCD_E);    //-  Send data, keep enable high     

5

  lcd_write_i2c(value & (LCD_E ^ 0xFF));  //-  Set enable to low    

6

  //lcd_write_i2c(value & (!LCD_E));  //-  Set enable to low  

7

}

ist also schon korrigiert.

Die Sache mit den Datenbits stimmt allerdings.
Das ist Verarsche. Die sind nicht konfigurierbar. Sonst müsste das hier

1

void lcd_putchar(unsigned char value)

2

{

3

  unsigned char lcddata;

4

  lcddata = value;

5

  lcddata >>= 4;

6

  lcddata |= LCD_RS;

7

  lcd_write(lcddata);

8

  lcddata = value;

9

  lcddata &= 0x0F;

10

  lcddata |= LCD_RS;

11

  lcd_write(lcddata);

12

}

ein bischen anders aussehen. Das geht dann nicht mehr so einfach mit um 
4 Bits shiften bzw verunden mit 0x0F

Udo schrieb:
> Vielen Dank für Eure Antworten!
>
> Sollte es nicht gehen, da ich die LCD Kommandos in der header Datei
> angepasst habe?

Was, genau, hast du denn jetzt eigentlich geändert und wie sieht die 
Sache jetzt aus? (Code + Verdrahtung)

Und warum vergreifst du dich an irgendwelchen Kommandos (was auch immer 
du damit meinst). An dem Teil gibt es nichts anzupassen oder zu 
verändern.

Es gibt nur 2 Möglichkeiten
Entweder du schliesst die Datenpins wie vorgesehen an den Pins 3 bis 0 
an, oder du schreibst die beiden Byte-Ausgabefunktionen so um, dass sie 
mit geänderter Pinbelegung klar kommen.
Für eines der beiden musst du dich entscheiden.
(Oder aber eine andere QUelle suchen, deren Programmierer nicht 
schlampig waren)

@ Karl Heinz (kbuchegg) (Moderator)

>Der ! müsste ein ~ sein.

Spielverderber! Dass DU den Fehler findest stand ja wohl ausser Frage 
:-(

>Aber wo hast du den Ausschnitt her?
>Im Zip-File des TO sieht die lcd_write so aus

Ja, das ist aber nicht das Original aus dem Netz, da hat schon jemand 
dranrumgeändert. Und ich hätte einfach das ! gegen ~ getauscht. Nicht 
nur, weil es weniger Tipparbeit ist, sondern vor allem weil es 
inhaltlich "korrekter" ist. Denn ein ~0xFF invertiert ALLE Bits, auch 
die Daten. Damit ändern sich die EIngangssignal gleichzeitig zum E 
SIgnal am LCD. Es GEHT, weil die Haltezeit (Hold time) <=0ns ist, aber 
schön ist es nicht.

Falk Brunner schrieb:
> @ Karl Heinz (kbuchegg) (Moderator)
>
>>Der ! müsste ein ~ sein.
>
> Spielverderber! Dass DU den Fehler findest stand ja wohl ausser Frage
> :-(

Ich muss gestehen, ich hab ein paar Sekunden gebraucht und wenn du nicht 
darauf aufmerksam gemacht hättest, hätte ich den wohl ein paar mal 
überlesen.

Aber zurück zu Udo

Wie sieht es denn jetzt aus?
Hast du die Datenleitungen umgelötet?
Das wäre der pragmatische Ansatz der einfachsten Veränderung (aus deiner 
Sicht)

Diese Änderung muss nicht bedeuten, dass dein LCD danach funktioniert. 
Da gibt es noch genug andere Möglichkeiten. Aber es ist eine der 
Voraussetzungen, dass es überhaupt je mit diesem Code funktionieren 
kann.

@ Udo

Hallo Udo,

zu deinem aktuellen Problem mit der Eichelmann Lib kann ich Dir jetzt 
auch nicht helfen. Dazu reichen meine Kenntnisse noch nicht aus.

Ich hatte aber wohl ein ähnliches Problem eine Lib für die LCD 
Ansteuerung via I2C zu finden. Außer LiquidCristal für Arduino war nix. 
Habe dann aber eine m.E. gute Lib gefunden:

http://davidegironi.blogspot.de/2013/06/an-avr-atmega-library-for-hd44780-based.html#.Uyw4gGd7MWM

Mit der habe ich sogar problemlos die billigen i2c LCD Adapter aus der 
Bucht für 2 Eus ans laufen gebracht. Vielleicht hilft es dir ja.

Gruß Jörg

Yes it is. There is no need for modifications, just connect to the real 
SDA/SCL pins of your AVR.

Hallo Falk
deine Info ist falsch. Habe das Teil in den Griff bekommen. Es war 
eigentlich nur ein kleiner Fehler. Von Chaos kann man auch nicht 
sprechen. Du hattest die Arbeitskopie bekommen mit allen möglichen 
auskommentierten Versuchen. Es hat aber keiner angegeben was alles in 
den i2clcd.d/.c usw. geändert werden muss, so wie 16 Mhz oder so was wie 
"" statt <>. Der blödeste Fehler war aber lcd_init und i2clcd_init in 
der reihenfolge vertauscht war. Wie gesagt es geht jetzt wunderbar und 
das Chaos ist auch beseitigt.
achim

Beitrag "I2CLCD Library für HD44780 LCDs"