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.
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
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.
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
:
Bearbeitet durch User
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.
Du könntest den 74HC4094 nehmen, der kann transparent latchen. Dann sind die Ausgänge schon nach dem letzten SCK gültig.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.