Beispiel einer schnellen PCA9554 I2C LCD Interface Funktion Im Anhang ist ein Beispiel zu finden. Die untenstehende Funktion ist ein Beispiel einer schnellen I2C LCD Treiber Anwendung. Es hat mich immer gestoert dass bei vielen I2C Parallel Expander ICs wie PCF8574, PCA9554 fuer jedes Zeichen zwei, bzw. drei I2C Schreibvorgaenge notwendig sind. Die untenstehende Funktion kommt mit nur vier internen Schreibvorgaengen aus. Z.B. Fuer die String "IRREN IST MENSCHLICH" muessen nur 24 Zeichen gesendet werden anstatt der traditionellen 60 bytes. Bei laengeren Texten macht sich das angenehm bemerkbar. Das ist immerhin eine zweieinhalbfache Reduzierung der Uebertragungszeit bei 20 Zeichen. Bei 400Khz I2C Taktrate braucht man anstatt 1.4ms also nur ca. 550us um 20 Zeichen zum LCD zu senden. Bei traditionellen Gebrauch von I2C Funktionen wird noch mehr Zeit mit dem CALL Overhead verschwendet. Ich hoffe Ihr findet diese Methode vielleicht nuetzlich. Vielleicht geht es anders noch schneller. mfg Gerhard
> PCA9554 Parallel Ausgaenge an LCD Dateneingaenge DB0-DB7 > Drei uC GPIO Ausganege fuer RS, RW, und E Damit brauchst Du aber 5 IOs. Der einzige Grund, warum man I2C nimmt, ist doch, nur 2 IOs zu benötigen. Dann kannst Du auch gleich 6 IOs nehmen und das LCD direkt im 4-Bit Mode anschließen: http://www.mikrocontroller.net/attachment/30300/lcd_drv.zip Oder nimm nur 3 IOs und schließe es per 74HC164 an: Beitrag "Standard LCD über nur 3 Drähte" Oder nimm nur einen IO und schließe es mit eigenem MC (ATtiny25) an: Beitrag "LCD über nur einen IO-Pin ansteuern" Um die LCD-Ausgabe wirklich effektiv zu beschleunigen, nimmt man besser einen Puffer von der Größe des LCD und schreibt einfach direkt dort hinein, das geht ratzfatz. Und ein Timerinterrupt gibt dann im Hintergrund an das LCD aus: Beitrag "Formatierte Zahlenausgabe in C" Peter
Hallo Gerhard O. > LCD Anschluss Details: > PCA9554 Parallel Ausgaenge an LCD Dateneingaenge DB0-DB7 > Drei uC GPIO Ausganege fuer RS, RW, und E wenn ich es richtig sehe, dann benötigst du einen Port-Expander UND einen mc ? Ist das nicht ein ziemlicher Aufwand ? Einen PCF8574 zum Ansteuern eines LCD's zu verwenden, macht nach meiner Auffassung nur dann Sinn, wenn bereits ein I2C-Bus vorhanden ist UND/ODER die Anzahl freien Pins nicht ausreicht, um das LCD direkt anzusteuern. Auf der anderen Seite: wenn ich doch bereits eine I2C-Bus habe, dann würde ich das gesamte Handling des LCD's dem I2C-Slave überlassen und einen "programmierbaren Portexpander" wählen. Nebenbei ist z.B. ein ATTINY2313 preisgünstiger als ein PCF8574. Und er kann die Initialisierung des LCD's, die Ausgabe der Zeichen sowie noch reichlich Zusatzaufgaben freier Wahl meistern. Dein I2C-Master muss dann - um einen Text der Länge (n) zu übertragen - lediglich (n+1) Bytes über den Bus schicken (nämlich die Slave-Adresse + den Text). Plus gelegentlich mal Kommandos zum Positionieren des Cursors. mfg Michael S.
Hallo Peter und Michael, Eure Einwaende sind auf alle Faelle richtig und ich bedanke mich fuer Eure Stellungsnahme. Mir ging es eigentlich mehr darum rauszustellen dass der PCA9554 fuer eine direkte sequentielle Datenuebertragung geeignet ist. Das Datenblatt dokumentiert nur dass so eine Art der Datenuebertragung nur im READ Modus moeglich sei. Ich war eben nur neugierig ob das auch in die andere Richtung moeglich waere. Moechte aber nur bemerken dass in diesem Fall das LCD nur ein Teil eines mehrgliedrigen I2C Bus auf meiner ZILOG Experimentierplatine sind und der Einsatz von drei uC Portleitungen nur fuer das LCD vertretbar waren da ja alles auf der Platine sitzt. Fuer eine reine I2C LCD Steuerung habe ich auch schon eine kleine LCD Platine mit uC entwickelt die hinterm LCD aufsteckbar ist und natuerlich mit nur 2 Draehten auskommt und entweder I2C, SPI, und RS232/485 macht. mfg, Gerhard
Gerhard O. wrote: > Das Datenblatt dokumentiert nur dass so eine Art der > Datenuebertragung nur im READ Modus moeglich sei. Ich war eben nur > neugierig ob das auch in die andere Richtung moeglich waere. Beim Vorgänger PCF8574 war das noch drin. > der Einsatz von drei uC Portleitungen nur fuer das LCD vertretbar waren > da ja alles auf der Platine sitzt. Dann wäre aber der 74HC164 an 3 Leitungen und ohne I2C noch besser, da der nicht auf 400kHz begrenzt ist. Allerdings sehe ich nirgends in Deinem Code die Wartezeit von >40µs zwischen den Bytes. Bei 400kHz komme ich auf nur 22,5µs und das ist arg weit weg von der HD44780 Spezifikation. Falsches Zeit sparen kann somit auch Nichtfunktionieren bedeuten. Besser spart man daher mit der Methode mit Timerinterrupt. Peter
Hallo Peter, Peter Dannegger wrote: > Gerhard O. wrote: >> Das Datenblatt dokumentiert nur dass so eine Art der >> Datenuebertragung nur im READ Modus moeglich sei. Ich war eben nur >> neugierig ob das auch in die andere Richtung moeglich waere. > > Beim Vorgänger PCF8574 war das noch drin. > > Das habe ich ganz vergessen;-( Weil ich meistens nur mehr PCA95XX Port Expander verwende. >> der Einsatz von drei uC Portleitungen nur fuer das LCD vertretbar waren >> da ja alles auf der Platine sitzt. Da hast Du nicht unrecht. > > Dann wäre aber der 74HC164 an 3 Leitungen und ohne I2C noch besser, da > der nicht auf 400kHz begrenzt ist. Stimmt. Ich waehlte I2C fuer das LCD weil ich den SPI port fuer eine SD Karte reservieren wollte. Auch wollte ich auf meiner Platine den PCA9554 fuer andere Anwendungen ohne LCD als INPUT/OUTPUT Parallel Interface verwenden. > > Allerdings sehe ich nirgends in Deinem Code die Wartezeit von >40µs > zwischen den Bytes. Bei 400kHz komme ich auf nur 22,5µs und das ist arg > weit weg von der HD44780 Spezifikation. Das stimmt. ab 375kHz gibt es Probleme mit dem LCD module. Allerdings wenn ich ein DOGM163 verwende geht es bis 475kHz gut. (Die LCD Initialisierung ist umschaltbar zwischen HD44780 und DOGM163 LCD Module) Beim HD44780 habe ich die I2C Baudrate auf 250kHz festgelegt. Das sollte genug Sicherheitsabstand geben. > Falsches Zeit sparen kann somit auch Nichtfunktionieren bedeuten. Da hast Du recht. > Besser spart man daher mit der Methode mit Timerinterrupt. Obwohl ich die Timer Interrupt Methode bis jetzt noch nicht selber bei LCDs verwendet habe, gefaellt mir das im Prinzip auch besser. Werde mich mal damit befassen. Man koennte auch einen gepufferten Treiber schreiben welcher die LCD Datenbytes mittels I2C Interrupts fortbewegt. Habe das mit RS232 so gemacht und funktioniert recht gut. Der Aufwand ist nicht zu gross. Vielleicht war das LCD BEispiel auch ein schlechtes Beispiel. Ich wollte eigentlich nur aufzeigen dass man den PCA9554 zu sequenziellen Datenuebertragungen missbrauchen kann. Aber trotzdem Danke fuer Deine konstruktive Kritik. Gruss, Gerhard > > > Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.