Hallo zusammen, ich würde gerne mehrere LCD-Displays mit dem Parallel Interface ansteuern. Meine Frage ist, ob die Leitungen als Bus verwendet werden können, damit nicht unnötig viele Pins am MCU verschwendet werden. Folgende Leitungen würde ich demnach parallel zum MCU führen: Pin 4 - RS Pin 5 - R/W Pin 7-14 - DB0-DB7 Die Enable-Signale würden dann natürlich für jedes Display separat geführt um das grade gewollte Display auszuwählen. Es handelt sich um folgendes Display: https://de.farnell.com/fordata/fc2004c03-nswbbw-91-e/anzeige-alphanumerisch-20x4-weiss/dp/2674146?st=LCD%20Display Vielen Dank im voraus!
Fragensteller schrieb: > Meine Frage ist, ob die Leitungen als Bus verwendet werden können, damit Ja. Fragensteller schrieb: > nicht unnötig viele Pins am MCU verschwendet werden. Folgende Leitungen Überlege mal ob du unbedingt R/W brauchst. 4-bit mode ist genauso gut wie 8-bit, vor allem da bei LCD-Displays Geschwindigkeit nicht im Vordergrund steht. Das wären dann schon 5 Leitungen weniger.
Marc V. schrieb: > Überlege mal ob du unbedingt R/W brauchst. Mit dem R/W-Signal wähle ich doch nur zwischen Schreiben und Lesen Marc V. schrieb: > 4-bit mode ist genauso gut wie 8-bit, vor allem da bei LCD-Displays > Geschwindigkeit nicht im Vordergrund steht. Die 8 Pins sind eingeplant, deswegen werde ich diese auch komplett ausnutzen. Danke für deine Antwort!
Fragensteller schrieb: > Die 8 Pins sind eingeplant, deswegen werde ich diese auch komplett > ausnutzen. Das ist beim Text-LCD wirklich, wirklich sinnlos da der Prozessor nur die meiste Zeit drauf wartet ein neues Zeichen schicken zu können. Dann kann er auch zwischendrin die halben Bytes multiplex schreiben. Kein LCD ist so schnell das man jemals einen Einflauss darauf sehen könnte.
Fragensteller schrieb: > Mit dem R/W-Signal wähle ich doch nur zwischen Schreiben und Lesen Eben, warum willst du unbedingt vom Display lesen? Fragensteller schrieb: > Die 8 Pins sind eingeplant, deswegen werde ich diese auch komplett > ausnutzen. Bist du sicher, dass der Plan gut ist, wenn du jetzt doch unnötig viele Pins am MCU verschwendest? Fragensteller schrieb: > Meine Frage ist, ob die Leitungen als Bus verwendet werden können, damit > nicht unnötig viele Pins am MCU verschwendet werden
Wolfgang schrieb: > Fragensteller schrieb: >> Mit dem R/W-Signal wähle ich doch nur zwischen Schreiben und Lesen > > Eben, warum willst du unbedingt vom Display lesen? Nicht jede parallele Schnittstelle unterstützt das Lesen auf den Datenleitungen. Aus Kompatibilität also lieber weglassen!
Wolfgang schrieb: > Eben, warum willst du unbedingt vom Display lesen? Eventuell will er ja das Busy-Signal auswerten!?
Route 6. schrieb: > Nicht jede parallele Schnittstelle unterstützt das Lesen auf den > Datenleitungen. Es geht hier wohl nicht um den PC-Frickelport.
Fragensteller schrieb: > ich würde gerne mehrere LCD-Displays mit dem Parallel Interface > ansteuern Aus Interesse: wie viele denn? Teo D. schrieb: > Eventuell will er ja das Busy-Signal auswerten!? Was bei mehreren Anzeigen auch nicht verkehrt ist.
Route 6. schrieb: > Rufus Τ. F. schrieb: >> Es geht hier wohl nicht um den PC-Frickelport. > > Wo hast du die Glaskugel her? Nee, nich schon wieder. Keinen im Sandkasten zum Kloppen gefunden?
Teo D. schrieb: >> Eben, warum willst du unbedingt vom Display lesen? > > Eventuell will er ja das Busy-Signal auswerten!? Wenn man die dokumentierten Wartezeiten der einzelnen Kommandos beachtet, kann man problemlos auf "Busy" verzichten.
> Eventuell will er ja das Busy-Signal auswerten!?
Vergiss das Busy, vergiss das Lesen. Der Aufwand lohnt sich nicht. Nimm
einen Timer. Ich verwende meinen ueblichen 10ms Tick. Jeden Tick ein
einzelnes Zeichen, oder command. Der Inhalt des Displays wird periodisch
von einem Buffer her vollstaendig ueberschrieben.
Wenn's um Portpins geht, kann man auch auf den 4bit breiten Bus
zurueckgreifen.
Glaub Esuns schrieb: > Das ist beim Text-LCD wirklich, wirklich sinnlos da der > Prozessor nur die meiste Zeit drauf wartet ein neues > Zeichen schicken zu können. Der Prozessor hat ja nebenbei noch einige andere Sachen zu tun =). Regelungen und so weiter. Glaub Esuns schrieb: > Kein LCD ist so > schnell das man jemals einen Einflauss darauf sehen könnte. In dem Datenblatt zu dem verbauten LCD-Controller steht, dass maximal zwei rising edges am Enable-Signal innerhalb von 500ns liegen dürfen. Das bedeutet, ich könnte 8Bit innerhalb von 500ns und 2 * 4Bit innerhalb von 1µs übertragen. Demnach würde sich doch die Zeit verdoppeln. Wolfgang schrieb: > Eben, warum willst du unbedingt vom Display lesen? Nein, lesen wollte ich eigentlich nicht, könnte den Pin somit auf GND legen. m.n. schrieb: > Aus Interesse: wie viele denn? Voraussichtlich werden es drei. A. K. schrieb: > Wenn man die dokumentierten Wartezeiten der einzelnen Kommandos > beachtet, kann man problemlos auf "Busy" verzichten. Diese Umsetzung hatte ich im Kopf. Jetzt ist G. schrieb: > Wenn's um Portpins geht, kann man auch auf den 4bit breiten Bus > zurueckgreifen. Die 8 Port-Pins sind locker frei. Es ging mir bloß darum, dass ich nicht 3 * 8 Datenleitungen brauche. Die hätte ich wahrscheinlich auch noch gehabt, aber wollte nicht jedes Display einzeln routen =).
Ich denk nur die RS & CS muessen pro LCD einzeln angesteuert werden, die anderen duerfen parallen mehrere devices bedienen.
Jetzt ist G. schrieb: > Vergiss das Busy, vergiss das Lesen. Der Aufwand lohnt sich nicht. Nimm > einen Timer. Über lass das bitte mir, welch Aufwand ich treiben möchte. Immer hin hab ich damit, bei 16MHz Befehlszyklus, ganze 4µs gespart. :D (Hängt natürlich stark vom Display und Temperatur ab) Du hast natürlich recht, der Aufwand lohnt nicht. Ein Watchdog o.ä. ist dann ja auch noch fast Pflicht.
Jetzt ist G. schrieb: > Ich denk nur die RS & CS muessen pro LCD einzeln angesteuert werden, die > anderen duerfen parallen mehrere devices bedienen. Solange die kein Enable bekommen, kümmer sie das nicht. CS gibts nich, R/W war sicher gemeint.
Fragensteller schrieb: > Der Prozessor hat ja nebenbei noch einige andere Sachen zu tun =). > Regelungen und so weiter. deswegen hat es keinen Sinn zu oft zu schreiben, ich schreib bei Bedarf in ein Schattenram und nur alle 250ms wird das zum LCD gebracht, 10ms Timer countdown von 24 bis 0, mehr als 4 Werte/Sekunde kann doch kein Mensch sehen, bzw. erkennen, für Uhr und Temperatur würde sogar 1s reichen, nur läuft es mit 4/s runder.
Joachim B. schrieb: > mehr als 4 Werte/Sekunde kann doch kein > Mensch sehen, bzw. erkennen, Lass mal die Bananen in Ruhe und komm vom Baum runter. 300 Bd sollten Vergangenheit sein. Bei 4 x 20 sieht man schon bei schnellerer Ausgabe den zeitlichen Versatz, wann das 1. und wann das letzte Zeichen ausgegeben werden. A. K. schrieb: > Wenn man die dokumentierten Wartezeiten der einzelnen Kommandos > beachtet, kann man problemlos auf "Busy" verzichten. Je nach Controller können die aber doch recht stark schwanken. Wenn man "busy" nutzen kan, wieso nicht? Man darf nur nicht so ungeschickt hantieren, wie man es immer wieder bei EEPROMs sieht - erst schreiben und dann auf "busy" warten - sondern genau anders herum.
Jetzt ist G. schrieb: > Ich denk nur die RS & CS muessen pro LCD einzeln angesteuert > werden, die > anderen duerfen parallen mehrere devices bedienen. Teo D. schrieb: > Jetzt ist G. schrieb: >> Ich denk nur die RS & CS muessen pro LCD einzeln angesteuert werden, die >> anderen duerfen parallen mehrere devices bedienen. > > Solange die kein Enable bekommen, kümmer sie das nicht. > CS gibts nich, R/W war sicher gemeint. Das verwirrt mich jetzt etwas... generell müsste ich doch alles außer Enable parallel schalten können, wenn ich die Displays nacheinander anspreche, oder?
Fragensteller schrieb: > Das verwirrt mich jetzt etwas... generell müsste ich doch alles außer > Enable parallel schalten können, wenn ich die Displays nacheinander > anspreche, oder? Ja.
Rufus Τ. F. schrieb: > Route 6. schrieb: >> Nicht jede parallele Schnittstelle unterstützt das Lesen auf den >> Datenleitungen. > > Es geht hier wohl nicht um den PC-Frickelport. ...der allerdings seit seligen AT-Zeiten auch praktisch fast immer BiDi ist. Erst diese unsäglichen USB-Parallel-Adapter haben ihn wieder auf die minimalen Fähigkeiten zusammengestutzt, die er ursprünglich mal hatte, so vor ca. 35..40 Jahren...
m.n. schrieb: > Lass mal die Bananen in Ruhe und komm vom Baum runter. 300 Bd sollten > Vergangenheit sein. > Bei 4 x 20 sieht man schon bei schnellerer Ausgabe den zeitlichen > Versatz, wann das 1. und wann das letzte Zeichen ausgegeben werden. ja ja, höre auf zu beleidigen und erzähle nicht das du mehr als 4 Werte / Sekunde lesen und erkennen kannst! > Wenn man "busy" nutzen kan, wieso nicht? hat ja keiner was dagegen WENN man es nutzen kann, aber ob es nötig und MÖGLICH ist muss halt von Fall zu Fall entschieden werden, das wissen wir beide doch nicht. Ich brauchte busy nur 2x bis jetzt, an der RTC ob sie noch mit der Temperatur beschäftigt ist und beim EEPROM Block schreiben, da nervte das übliche delay in fast jedem veröffentlichen Code!
Fragensteller schrieb: > Jetzt ist G. schrieb: >> Ich denk nur die RS & CS muessen pro LCD einzeln angesteuert >> werden, die >> anderen duerfen parallen mehrere devices bedienen. > > Teo D. schrieb: >> Jetzt ist G. schrieb: >>> Ich denk nur die RS & CS muessen pro LCD einzeln angesteuert werden, die >>> anderen duerfen parallen mehrere devices bedienen. >> >> Solange die kein Enable bekommen, kümmer sie das nicht. >> CS gibts nich, R/W war sicher gemeint. > > Das verwirrt mich jetzt etwas... generell müsste ich doch alles außer > Enable parallel schalten können, wenn ich die Displays nacheinander > anspreche, oder? Lass dich von "Jetzt ist G." nicht verwirren, der postet auch in anderen Threads größtenteils Unsinn. Alle Signale bis auf den EN dürfen an alle LCDs. Allerdings würde ich dir auch den 4Bit Bus empfehlen. Auch wenn du die Pins frei hast, so musste ja dann noch 4 weitere Signale übers PCB routen und dann sind die LCDs vllt noch übern Flachbandkabel angeschlossen. Das wird dann auch etwas schmaler ;) Was solls denn am Ende werden, dass es so viele Displays braucht? Bzw guck dich mal bei den "DOGM" Displays von EA um. Die können auch SPI und I2C. Joachim B. schrieb: > m.n. schrieb: >> Lass mal die Bananen in Ruhe und komm vom Baum runter. 300 Bd sollten >> Vergangenheit sein. >> Bei 4 x 20 sieht man schon bei schnellerer Ausgabe den zeitlichen >> Versatz, wann das 1. und wann das letzte Zeichen ausgegeben werden. > > ja ja, höre auf zu beleidigen und erzähle nicht das du mehr als 4 Werte > / Sekunde lesen und erkennen kannst! Is nur doof, dass m.n. recht hat, das zappelt dann ganz schön. Eine Zahl die mehrmals von 3,999 auf 4,000 und zurück springt nervt da schon sehr. Zusaätzlich dazu schmieren dann so manche billig China LCDs wegen der trägen Reaktionszeit auch sehr stark bei zu hohen Updateraten.
Mw E. schrieb: > Is nur doof, dass m.n. recht hat, das zappelt dann ganz schön. hast du das falsch verstanden? Die bemerkung mit 300Bd kann ja nur so aufgefasst werden das es schneller heute geht, also mehr LCD Updates als 4/s möglich sind, das bestreite ich kein bischen! > Eine Zahl die mehrmals von 3,999 auf 4,000 und zurück springt nervt da > schon sehr. > Zusaätzlich dazu schmieren dann so manche billig China LCDs wegen der > trägen Reaktionszeit auch sehr stark bei zu hohen Updateraten. ja und deswegen scheint es dir sinnvoll zu sein die Taktrate zu erhöhen statt sich zwischen 3,999 und 4,000 zu entscheiden? also erst dann neu zu schreiben wenn die Abweichung unterscheidbar ist!, so 2-5% und nicht 0,001
Er hat 2 Dinge angesprochen: - schnelles schreiben damit man den Refresh nicht an einem durchlaufenden Cursor erkennt (jagut kann man abschalten solange) oder sich der Reihe nach ändernde Buchstaben sieht. Bei den hier genannten 10ms sieht man bei nem 4x20 Zeichen dann durchaus den Refresh. - Die Updaterate an sich Also schnell schreiben, aber nur 4mal/s.
Mw E. schrieb: > Er hat 2 Dinge angesprochen: > - schnelles schreiben damit man den Refresh nicht an einem > durchlaufenden Cursor erkennt Deswegen dauert ihm Schreiben in 1 µs ja zu lange, da kann er nur 1 Mio Zeichen pro Sekunde schreiben. Wahrscheinlich gehört er zu den Übersensiblen, die das als Flimmern sehen können. Wieder mal eine perfekte Lösung gesucht für ein nicht existierendes Problem. Georg
Joachim B. schrieb: > und erzähle nicht das du mehr als 4 Werte > / Sekunde lesen und erkennen kannst Doch, kann ich! Zumal es ja hier nicht um die Ausgangswerte eines Zufallzahlengenerators geht. Bei Sprüngen zwischen 4.000 und 3.999 sehe ich mir ja nicht alle Ziffern einzeln an, sondern die gesamte Ziffernfolge auf einen Blick. Mich stören auch 20 Ausgaben/s nicht. Daran kann man nämlich gut die Qualität des Signals/Meßwertes erkennen. Durch 'integrierendes Kucken' kann man auch Tendenzen bei den Änderungen erkennen. Ich möchte kein Gerät abgleichen müssen, daß eine lahme Anzeige oder womöglich noch eine Hysteres bei den angezeigten Werten eingebaut hat.
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.