Forum: Mikrocontroller und Digitale Elektronik LCD (HD44780) via SPI (74xx595) mit BUSY-Flag


von Daniel (Gast)


Angehängte Dateien:

Lesenswert?

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.

von OMG (Gast)


Lesenswert?

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.

von OMG (Gast)


Lesenswert?

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.

von Manfred (Gast)


Lesenswert?

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.

von OMG (Gast)


Lesenswert?

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.

von Christian S. (roehrenvorheizer)


Lesenswert?

Hallo.

ich habe für solche Ideen immer gerne diese beiden ICs verwendet:

https://www.microchip.com/wwwproducts/en/MCP23S17
http://ww1.microchip.com/downloads/en/DeviceDoc/20001952C.pdf

Mit diesen kann man auch GLCDs ansteuern.

mfG

von Peter D. (peda)


Lesenswert?

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.

von Peter D. (peda)


Angehängte Dateien:

Lesenswert?

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.

von Andreas S. (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

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

: Bearbeitet durch User
von Daniel (Gast)


Lesenswert?

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.

von Daniel (Gast)


Lesenswert?

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.

von Wolfgang (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

Du könntest den 74HC4094 nehmen, der kann transparent latchen. Dann sind 
die Ausgänge schon nach dem letzten SCK gültig.

von Rudolph R. (rudolph)


Lesenswert?

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.

von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

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

von Daniel (Gast)


Angehängte Dateien:

Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.