Hallo,
ich möchte ein LCD mit einem HD44780 (kompatiblen) Controller an ein AVR
anschließen.
Leider sind die Pins knapp, deshalb würde ich es gerne über den (schon
vorhandenen) SPI-Bus mit machen.
Als weitere Herausforderung würde ich gerne das Busy-Flag auslesen und
dafür keinen weiteren Pin am AVR opfern.
Ausgedacht habe ich mir die beigefügte Schaltung, welche ich im
Folgenden kurz erklären möchte.
Als allererstes der "Ruhezustand": 595_EN ist High, LCD_EN ist Low.
Die Ausgänge des 595 sind damit hochohmig, ebenso die Datenbits des LCD.
Andere SPI Slaves können MISO treiben und mit dem AVR kommunizieren.
Zweitens "Busy-Read": 595_EN ist High, LCD_EN wird High gesetzt. Das
595 ist hochomig, am D7 des LCD und somit an MISO liegt das
Busy-Flag an. Der AVR liest ein SPI Byte und LCD_EN wird auf Low
gesetzt. Das LSB des SPI Daten Registers oder das ganze Byte kann auf
seinen Wert getestet werden und bei 0 ein Byte an das LCD gesendet
werden.
Drittens "LCD-Write": Das untere Nibble des SPI Daten Registers wird mit
den an das LCD zu sendenden Daten Bestück, Bit 4 mit dem passenden
Register, Bit 5 mit Low und Bits 6 & 7 sind irrelevant. Die Daten werden
in das 595 geschoben, 595_EN auf Low gesetzt, LCD_EN einmal High
gepulst und 595_EN wieder auf High gesetzt.
Weitere Nibbels / Bytes werden mit der selben Routine geschrieben.
So kann das SPI regulär genutzt werden und um ein LCD zu betreiben
werden lediglich 2 statt mind. 7 Pins (bei gleicher Funktionalität) am
AVR benötigt.
Ein weiterer Pin könnte eingespart werden, wenn man /QH*/ ung G
kurzschließt. Wollte man das LCD beschreiben müsste man Bit 7 des SPI
Daten Registers auf 0 setzen.
Das Problem bei der Methode ist, dass auf MISO immer die Daten des
vorhergehenden SPI Registers liegen würde wenn /QH*/ gerade ein Low
ausgibt. Man müsste also vor (und bei) jedem "Slave Read" das SPI Daten
Registers des AVR mit 0xFF beschreiben und ein Byte durchtakten. So wäre
G immer High und QD hochohmig. Dadurch wären jedoch Read-while-Write
SPI-Slaves ausgeschlossen.
Macht das ganze so Sinn, oder habe ich einen totalen Knoten im Hirn und
irgendwas daran haut nicht?
Über Feedback und Fragen würde ich mich freuen.
Daniel schrieb:> Über Feedback und Fragen würde ich mich freuen.
Von hinten durch die Brust ins Auge?
Ich denk mir das nicht durch.
Zwei Leitungen über I2C und ferddich.
Mach das wie alle mit einen 8-Bit I2C Port.
Daniel schrieb:> Macht das ganze so Sinn
Nachtrag: es macht sowieso keinen Sinn da diese LCDs so
langsam sind dass das Abfragen des Busy Flags praktisch
keinen Gewinn an Geschwindigkeit bringt. Ein festes
Delay nach jedem Schreibvorgang, mehr braucht es nicht.
OMG schrieb:> Ein festes Delay nach jedem Schreibvorgang,
Herr, wirf Hirn vom Himmel. Delay ist Arduino-Kindergarten, korrektes
Timing geht anders.
Ich merke mir meine Werte und beschreibe das Display dann, wenn eine
relevante Änderung vorliegt.
Manfred schrieb:> Ich merke mir meine Werte und beschreibe das Display dann, wenn eine> relevante Änderung vorliegt.
Das mache ich auch so.
Man kann Delays auch anders ausführen als wie es im
Arduino-Kindergarten gemacht wird.
Viel GLück bei deinen kleinen Hardware-Perversitäten.
Anbei mal ne einfache Schaltung, die funktioniert.
RS legt man über den SPI-Mode fest.
Busy-Waiting braucht man nicht. Man gibt einfach im 1ms Timerinterrupt
ein Byte aus dem Zeichenpuffer aus. Ein 4*40 LCD ist dann nach 164ms
aktualisiert. Schneller kann man eh nicht ablesen.
Warum das Rad neu erfinden-schon was von I2C Backpack gehört ?
Hast nur zwei Leitungen und gut.
Das Ganze gibt es für wenig Geld und man spart Zeit und Nerven.
Auch hast Du (wenn erforderlich) fertige Librarys für Dein Arduino.
Andreas S. schrieb:> Warum das Rad neu erfinden-schon was von I2C Backpack gehört ?
Man sollte allerdings auch die Nachteile nennen.
Um das Timing nicht zu verletzen braucht man je Nibble 3 Ausgaben (RS +
Nibble anlegen, E=1, E=0). Das ergibt bei 100kHz mit I2C Adresse für ein
Byte zum LCD schon 7 I2C-Byte a 9 Bit = 360µs. Macht man das I2C nicht
als Interrupt, ist das schon eine recht hohe CPU-Last. Busy-Polling
verbietet sich quasi von selbst, das LCD ist früher fertig als das ganze
I2C-Geraffel.
Peter D. schrieb:> Man sollte allerdings auch die Nachteile nennen.> Um das Timing nicht zu verletzen braucht man je Nibble 3 Ausgaben (RS +> Nibble anlegen, E=1, E=0).
Hi,
das hatten wir schon' mal bei "USI" durchgekaut.
Das Verständnisproblem liegt wohl darin, dass
die "Statusbits" des HD44780 LCDs, RS, RW, Enable
nicht direkt (parallebusmäßig) angesteuert werden können jetzt.
Busyflagauslesen geht ja so wie so nicht über ein Busy-Bit
wie bei der Centronics-Druckerschnittstelle.
Sondern erfordert ein Umschalten auf Lesemodus,
Auslesen von Bit 8, usw. usf. Wobei "Dummy" bei 4-Bit-Modus
oft vergessen wird.
Sogar das Trasitionstate-Bit wie Enable,
dessen Flanke ja entscheidend ist, wird
in den 8-Bit Rahmen verpackt.
Und alles so nacheinander seriell gesendet.
Dadurch erklärt sich eine höherer Zeitaufwand.
PCF8574->0x40; PCF8574A->0x70
Die Adressenangabe der Portadapter bringt insofern Probleme, weil
ursprünglich der 7 Bit Rahmen zugrundegelegt wird.
ciao
gustav
Peter D. schrieb:> Lt. HD44780 Datenblatt müssen RS und R/W gegenüber E >=40ns voreilend> sein. Bei Dir sind sie aber um die Schaltzeit des 595 (<=42ns)> nacheilend.
Weder beim "Busy-Read", noch beim "LCD-Write" sehe ich das Problem.
Beim "Busy-Read" sind RS und R/W ewig vorher gesetzt, da sie der
"Ruhezustand" sind. Bei "LCD-Write" wird 595_EN gesetzt, je nach
Taktrate 0-2 Takte gewartet und dann LCD_EN...
Alle anderen Beiträge gehen mehr oder weniger an der Fragestellung
vorbei. Ich habe kein I2C und möchte es per Busy Flag machen.
Das es andere Wege gibt ist mir bewusst, aber es soll nun mal dieser
sein.
Daniel schrieb:> Alle anderen Beiträge gehen mehr oder weniger an der Fragestellung> vorbei. Ich habe kein I2C und möchte es per Busy Flag machen.> Das es andere Wege gibt ist mir bewusst, aber es soll nun mal dieser> sein.
Damit es keine Verwirrung bzgl. meiner Bitte um Verbesserungsvorschläge
gibt:
Ich würde mich über Verbesserungsvorschläge, _welche SPI und Busy-Flag
nutzen_, freuen. Andere Techniken sind aufgrund diverser
Nebenbedingungen ausgeschlossen.
Manfred schrieb:> OMG schrieb:>> Ein festes Delay nach jedem Schreibvorgang,>> Herr, wirf Hirn vom Himmel. Delay ist Arduino-Kindergarten, korrektes> Timing geht anders.
Würde dich die Formulierung: "Eine feste Verzögerung nach jedem
Schreibvorgang ..." beruhigen. Nicht jedes Delay ist ein Aufruf der
delay()-Funktion von Arduino, die sich nämlich "delay" schreibt.
Daniel schrieb:> Bei "LCD-Write" wird 595_EN gesetzt, je nach> Taktrate 0-2 Takte gewartet und dann LCD_EN...
Nö, RCK_595 ist mit LCD_EN verbunden, d.h der 595 übernimmt erst kurz
nach der high Flanke des LCD_EN.
Daniel schrieb:> Andere Techniken sind aufgrund diverser> Nebenbedingungen ausgeschlossen.
Anstatt das generell abzutun könntest Du mal mit jeweils einer Zeile auf
Vorschläge eingehen.
Eine Möglichkeit wäre noch ein LCD Backpack mit UART, so als fertige
Lösung.
Eine andere Möglichkeit wäre selber einen Controller für das LCD zu
benutzen aber den üer SPI anzubinden.
Damit hat sich dann auch die Frage nach dem Timing erledigt, so aus
Sicht des SPI, das Display wird zum Speicher der wahlfrei ohne warten zu
müssen beschrieben werden kann.
Und das brauch nur einen CS Pin am Haupt-Controller.
Peter D. schrieb:> Du könntest den 74HC4094 nehmen, der kann transparent latchen.> Dann sind die Ausgänge schon nach dem letzten SCK gültig.
Hi,
clock,
data,
strobe
So habe ich die wichtigstenen Bezeichnungen für den 94-er noch in
Erinnerung.
Womit was wann angesteuert wird, kann dann eine Extra-Routine machen.
Dürfte nicht so schwer sein.
ciao
gustav
Peter D. schrieb:> Nö, RCK_595 ist mit LCD_EN verbunden, d.h der 595 übernimmt erst kurz> nach der high Flanke des LCD_EN.Peter D. schrieb:> Du könntest den 74HC4094 nehmen, der kann transparent latchen. Dann sind> die Ausgänge schon nach dem letzten SCK gültig.
Dankeschön fürs wegreißen des Bretts vorm Kopf! Genau wegen solcher
Tipps frage ich gerne hier ob meine Designs passen. Vielen vielen
Dank!!!
Nicht nur RS & R/W sondern ebenso D4-D7 hätten so noch falsche Zustände
beim LCD_EN. Das wäre ganz schön schief gegangen...
Der 74HC4094 ist die einfachste Lösung. STR mit CLK verbinden und die
Daten stehen unmittelbar bereit.
Anbei ein Bild des neuen Designs, falls es jemanden interessiert.
Rudolph R. schrieb:> Anstatt das generell abzutun könntest Du mal mit jeweils einer Zeile auf> Vorschläge eingehen.
Wie im ersten Beitrag schon geschrieben sind die Pins knapp. D.h.
I2C-Pins sind anderweitig in Verwendung, UART ist ebenfalls schon als
UART in Verwendung. Wieso soll ich also auf Vorschläge eingehen, die
technisch einfach nicht möglich sind?
Bzgl. SPI über zweiten Controller: Danke für die Idee. Wenn möglich
möchte ich mir aber eine zweite Software sparen. Preislich könnte ich
dann auch gleich einen AVR mit mehr Pins nehmen. Da ist ein 74HC4094
günstiger. Daher wirds vorerst mal beim 74HC4094 bleiben.
screenshot.gif
(22 KB)
