mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LCD mit wenig µC IOs versorgen


Autor: Henrik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin leute!

Ich suche eine Möglichkeit ein 8 Bit parallel LCD mit µC anzusteuern.
Ich habe allerdings keine Lust 8 Datensins + die R/W Bits und so weiter
vom µC zu verschwenden. Gibts da nicht andere Bausteine, die sowas
multiplexen?

Mir fiel spontan ein 74HC164 SIPO Chip ein. Dann bräuchte ich nur 2
statt 8 Pins. Damit kann ich allerdings das Busy Flag nicht auslesen,
da das nur Ausgänge sind.

Oder ein I²C Erweiterungsbaustein. Aber da brauche ich ja auch schon
wieder 3 Pins fürs muxen. Hatte den PCF 8574 gefunden.

Noch andere Ideen?

Autor: Sebastian Eckert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also: Erstens gibt es den 4 Bit-Modus, in der einschlägigen
Dokumentation ausreichend besprochen. Kostet natürlich noch immer 7
Leitungen, 4x Daten + 3 Steuersignale.
Zweitens: Die Lösung mit dem 74(HC/LS)164 gibt es tatsächlich, zu
finden in einem Klassiker der Internet-Dokumentation zum Thema:
http://www.mil.ufl.edu/imdl/handouts/lcd-faq.htm
Siehe Punkt 3.5 - Hier wird auch eine Alternativlösung mit HC595
vorgestellt.
Auf das Einlesen des Busy-Flags wird hier verzichtet - wenn man lange
genug wartet, ist das nicht unbedingt erforderlich. Die
Befehlsausführungszeit beträgt im ungünstigsten Fall etwa 41 ms, wenn
ich mich richtig erinnere, für die meisten Befehle weniger. Zugegeben,
in dieser Zeit könnte der Mikrocontroller auch andere Dinge tun. Ich
weiß ja nicht, wie zeitkritisch die Applikation ist.

I²C ist meiner Ansicht nach zuviel Aufwand für diese Aufgabe. Mehr
Overhead als Funktion, außer natürlich wenn man sowieso schon
I²C-Funktionen hat.

Autor: Henrik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt auch Displays von Electronic Assembly, die sich über SPI
ansteuern lassen, das wären allerdings 4 Pins vom MC, die du dafür
brauchst.
Dafür ist das SPI-Interface meist schon inder Hardware des MC
vorhanden, also ressourcensparend nutzbar.

Wenn du das Schieberegister oder den PCF verwenden willst, musst du dir
die Lib zum Ansteuern selber schreiben (ich kenne jedenfalls keine
fertige dafür).

Die Idee mit dem PCF5474 halte ich für am geeignesten; da er
quasi-bidirektionale Ausgänge hat, ist das Auslesen auch kein Problem.
Warum aber 3 Pins? Du brauchst doch nur SDA und SCL, da du jedem eine
eigene Adresse geben kannst.

Gruss (ebenfalls) Henrik

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jau, der 74HC164 ist ideal.

Man braucht allerdings 3 Drähte, 2 für Takt und Daten und den 3. für
das E-Signal, damit das LCD die Daten parallel übernimmt.

Hier ein Beispiel:

http://www.mikrocontroller.net/forum/read-4-22246.html#new


Peter

Autor: grad nicht eingeloggt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was spricht gegen den PCF8574?

Bin gerade dabei (beruflich) genau den zwischen µC und LCD
zu pflanzen, um Leitungen zu sparen.

Das bissl I2C "Bitgebange", falls der µC das nicht in Hardware
kann, ist doch lächerlich.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@grad,

naja, der ist wesentlich teurer als ein SRG und viel langsamer (max
100kHz).
Wenn Du also den E-Pin nicht extra führst, sind da schnell einige 100µs
verbraten für die Ausgabe nur eines Zeichens.


Mit dem SRG kann man dagegen die ~40µs Delay des Displays zum
Einschieben des nächsten Zeichens nutzen. Man ist also genau so
schnell, wie bei paralleler Ansteuerung.


Peter

Autor: Henrik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da bin ich wieder. Entschuldigt die späte Antwort.

Den HC164 finde ich auch echt gut. Der PCF ist wirklich teuer. Aber für
ne Kleinserie und Unikat Produktion sicher OK. ;)

Das Ding ist, dass ich echt keine Lust habe 41ms zu warten für die
Ausgabe eines einzelnen Zeichens. Das kann im Extremfall echt lange
dauern. Da kann ich ja am schlimmsten Falle beim Erstellen des Bildes
richtig zugucken. 0_o

Nichtsdestotrotz frage ich mich, wie ich das Busy Flag überhaupt
auslese. Muss ich dazu im Code meinen Ausgang kurz wieder als Eingang
umdrehen? Sobald das Busy Flag dann abgelaufen ist, wieder Ausgang und
Inhalt setzen?!

Und Display über SPI ist eigentlich ne gute Idee. Aber da so ein 8-Bit
Datenbus ja quasi Standard ist und ich nen Großteil der Teile bei
Reichelt beziehen will, ist der 8-Bit Datenbus schon OK. Nur bissel
verschwenderisch halt...

Autor: inoffizieller WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Muss ich dazu im Code meinen Ausgang kurz wieder als Eingang
>umdrehen?

Ja.

>Sobald das Busy Flag dann abgelaufen ist, wieder Ausgang und
>Inhalt setzen?!

Das brauchst du erst machen, wenn du neue Daten schreiben willst.

Wie oben schon erwähnt: Man kann die Displays auch hervorragend in
4Bit-Modus betreiben. Dann kommt man mit insgesamt 8 Bit (Daten und
Steuerleitungen) aus.
Da das Display relativ langsam ist, bietet es sich an, die
Kommunikation mit dem Ding an einen Timer zu koppeln.
In der Codesammlung sollten entsprechende Lösungen zu finde sein.

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Das Ding ist, dass ich echt keine Lust habe 41ms zu warten für die
Ausgabe eines einzelnen Zeichens. Das kann im Extremfall echt lange
dauern. Da kann ich ja am schlimmsten Falle beim Erstellen des Bildes
richtig zugucken. 0_o"

Du mußt weder 40ms noch 40µs warten. Die Controller sind etwa so
schnell, wie die Ausgabe eines Zeichens seriell benötigt (Ausgabe per
Software Pinwackeln).
Bei Grafik hält man sich am besten eine Kopie im Prozessor-(nahen)RAM,
macht dort die RMW-Aktionen und gibt nur die geänderten Bytes ans
Display.

Autor: Stephan Henning (stephan-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

es geht auch mit 2 Leitungen.
http://www.rentron.com/Myke1.htm

Habe ich mal mit Proteus für 8051 simuliert, und es geht wunderbar.
Den Code müßte ich noch haben, falls Bedarf.

So dann

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stephan,


"Habe ich mal mit Proteus für 8051 simuliert"

Simulieren kann man vieles, was dann in der Praxis nicht funktiont.


Die 8051 haben nämlich keine sonderlich hohe High-Treiberleistung.
Der 1k wird also den Datenpin als Pull-Down auf Low halten, wenn der
8051 High ausgeben will.


Peter

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.