Forum: Mikrocontroller und Digitale Elektronik LCD über 74*595: Busy-Flag?


von Michael R. (Firma: Brainit GmbH) (fisa)


Lesenswert?

Hallo Leute,

ich hab mich wieder mal selbst überlistet... mir sind die I/O Pins am 
ATmega ausgegangen, u.a. weil ich ein LCD (KS108) ansteuern möchte. 
Meine Lösung war, die 8 Datenbits über ein Schieberegister 
anzuschließen, also statt 8 nur 3 I/O Pins.

Eigentlich super, uneigentlich hab ich aufs Busy-Flag vergessen :-(

Rettende Idee: Output-Enable vom 595er doch mit ansteuern, und DB7 
(=Busy-Flag) auf einen freien Eingang legen. Frisst mir zwar zwei 
weitere Pins, aber ich hab immer noch drei gewonnen, und das würde genau 
ausreichen.

Kann ich das so machen, oder hab ich einen Denkfehler?

von Georg G. (df2au)


Lesenswert?

Muss man das Busy Flag nutzen? Wann kommen die Schreibbefehle so schnell 
hintereinander, dass die Mindest-Wartezeiten nicht eingehalten werden? 
Wenn das nur in wenigen Funktionen der Fall ist, baut man da eine feste 
Wartezeit ein und gut ist.

von Purzel H. (hacky)


Lesenswert?

Vergiss das Busy. Nimm einen Timer Interrupt zu zyklischen Schreiben. 
Mit einer Zustandsmaschine

von Michael R. (Firma: Brainit GmbH) (fisa)


Lesenswert?

Georg G. schrieb:
> Muss man das Busy Flag nutzen?

Das ist ein grafisches Display, also sind wesentlich mehr 
Schreibzugriffe nötig als zB bei einem HD44780. Und soweit ich weiss, 
profitiert der KS108 schon von einer Ansteuerung mit BF.

Da ich grad die Platine entwickle, möchte ich das möglichst vorsehen, 
sonst ärgere ich mich nachher grenzenlos...

von fchk (Gast)


Lesenswert?

Nimm doch einen MCP23S17 (SPI) oder MCP23017 (I2C). Bidirektional, 16 
Bit, und Du brauchst nur 4 Pins (SPI) oder zwei Pins (I2C in Software). 
Bei Software-I2C kann es auch ein PCA9536 oder so sein.

Ansonsten: ja, wenn Du nicht feste Delays einbauen willst, kannst Du das 
so machen.

fchk

von fchk (Gast)


Lesenswert?

Michael R. schrieb:
> Da ich grad die Platine entwickle, möchte ich das möglichst vorsehen,
> sonst ärgere ich mich nachher grenzenlos...

Kannst Du nicht einfach einen Chip mit mehr Pins nehmen, oder bist Du 
schon bei einem Mega2560 angelangt? Wäre ja auch eine Möglichkeit.

fchk

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

fchk schrieb:
> Nimm doch einen MCP23S17 (SPI)

Das Dings gibts übrigens gerade als Schnäppchen beim Herrn Pollin.

von Michael R. (Firma: Brainit GmbH) (fisa)


Lesenswert?

fchk schrieb:
> Ansonsten: ja, wenn Du nicht feste Delays einbauen willst, kannst Du das
> so machen.

Danke, das wollte ich hören!

Einen größene Port Expander zu verwenden würde nciht helfen: Das 
BusyFlag per Schieberegister zu lesen wäre zu aufwändig, das würde ich 
in jedem Fall direkt lesen wollen.

fchk schrieb:
> Kannst Du nicht einfach einen Chip mit mehr Pins nehmen, oder bist Du
> schon bei einem Mega2560 angelangt?

Ich bin beim ATmega1284, und nur wegen zwei fehlender Pins möchte ich 
nicht gleich den uC wechseln (vor allem da die Platine schon zu 80% 
fertig ist)

von Dominik (Gast)


Lesenswert?

Michael R. schrieb:
> Frisst mir zwar zwei
> weitere Pins,

Beim 595 ist OE negiert, LOW=aktiv
Beim 108 ist R/W LOW=write
Denke mal, das hast Du schon mit eingerechnet

1 Pin fürs Umschalten (R/W)(OE)
1 Pin für den Takt
1 Pin für Daten(DI) und (RS)
1 Pin fürs Output Latch und (E)

1 Pin fürs busy...

Bin mir nicht 100%ig sicher, müsste man den
Ablauf mal im Detail durchgehen, aber ich glaube
da kann man noch einen Pin sparen ;-)

Sofern SPI zum Einsatz kommt ist es natürlich egal,
der MISO ist dann ja eh "über".

Allerdings dimmt man mit der OE-Lösung die Hintergrundbeleuchtung wenn
man diese auch über das 595er laufen lässt.

Michael R. schrieb:
> Meine Lösung war, die 8 Datenbits
aber Du wolltest ja ohnehin den 8bit Mode verwenden

Auch wenn Du das Einlesen per Shiftregister oben ausschließt,
für graphische Darstellungen mach es schon Sinn alle 8 Daten-
Leitungen wieder einzulesen, spart je nach Anwendung ordentlich
Ram.

Gruß Dominik

von Michael R. (Firma: Brainit GmbH) (fisa)


Lesenswert?

Dominik schrieb:
> 1 Pin fürs Umschalten (R/W)(OE)
> 1 Pin für den Takt
> 1 Pin für Daten(DI) und (RS)
> 1 Pin fürs Output Latch und (E)
> 1 Pin fürs busy...
Ja, passt so, 3 weniger, und zwei davon brauch ich.

> Bin mir nicht 100%ig sicher, müsste man den
> Ablauf mal im Detail durchgehen, aber ich glaube
> da kann man noch einen Pin sparen ;-)
Kann sein, brauch ich aber (derzeit) nicht.

> Sofern SPI zum Einsatz kommt ist es natürlich egal,
> der MISO ist dann ja eh "über".
Ich setze kein SPI ein. Also kein "hardware"-SPI, ich mach das "zu Fuß". 
Nachdem ich SPI immer auf den Programmier-Port rausführe, und mir mal 
eine Platine samt AVR zerstört hatte (wegen irgendwelcher Nebeneffekte) 
meide ich SPI.

> Allerdings dimmt man mit der OE-Lösung die Hintergrundbeleuchtung wenn
> man diese auch über das 595er laufen lässt.
Die darf Vollgas laufen... auch wenn ich noch einen Pin übrig hätte :-)

> Auch wenn Du das Einlesen per Shiftregister oben ausschließt,
> für graphische Darstellungen mach es schon Sinn alle 8 Daten-
> Leitungen wieder einzulesen, spart je nach Anwendung ordentlich
> Ram.

Inwiefern?

Nachdem ich einen Atmega1284 einsetze, mit einer vergleichsweise 
einfachen Anwendung, dürfte RAM nicht mein Problem sein.

Trotzdem interessiert mich das: Warum wollte ich alle 8 Datenleitungen 
lesen wollen?

von Dominik (Gast)


Lesenswert?

Hallo,

Michael R. schrieb:
> Kann sein, brauch ich aber (derzeit) nicht.
Falls doch, ich glaube die Taktleitung lässt sich
fürs busy-Flag missbrauchen, zumindest beim 595er mit OE.

Michael R. schrieb:
> Inwiefern?
>
> Nachdem ich einen Atmega1284 einsetze, mit einer vergleichsweise
> einfachen Anwendung, dürfte RAM nicht mein Problem sein.
>
> Trotzdem interessiert mich das: Warum wollte ich alle 8 Datenleitungen
> lesen wollen?

Hallo,
ich habe auch mal ein Projekt mit 128x64er LCD und dem gleichen Atmega
gehabt.
Eine Funktion bestand darin, einen Temperaturverlauf in Echtzeit zu 
plotten (Kurve). Ich habe damals zunächst 1024 Bytes Ram für die 
komplette
Anzeige reserviert und diese dann je nach Anpassung aufs LCD geschoben, 
erst vollständig, nachher nur noch partiell, trotzdem fand ich es später 
eleganter die je 16bits vom LCD zurückzuholen, zu manipulieren und dann 
wieder reinzuschreiben, dann braucht man quasi gar keinen Grafikspeicher 
mehr im uC. Allerdings war mein LCD am Hardware-SPI und lief damit auch 
sehr ressourcenschonend.
Auch wenn man mit kleineren (eigenen) Schriftarten arbeitet ist das 
praktisch, da man ja jedes Mal mindestens 16 Bits schreiben muss,
also braucht man entweder Grafikspeicher oder die Programmierung wird 
sehr komplex wenn man erst wieder alle potentiellen Zeichenroutinen 
abfragen muss ob sie an dem aktuellen 16 Bit-Feld "mitwirken" wollen.


Gruß Dominik

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.