mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik HD44780 - man in the middle mit AVR?


Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe hier ein Gerät mit einem µC unbekannter Art, der ein 
LCD-Display mit HD44780+HD44100+HD61100 im 4-Bit-Modus steuert. Das 
angeschlossene Display kann mehr Zeichen darstellen, als vom Gerät 
benutzt werden. Die Idee ist nun, einen AVR dazwischen zu setzen, der 
alle Befehle/Daten "durchreicht" und zusätzliche Daten anzeigt, die über 
die serielle Schnittstelle (RS485) angeliefert werden. Soweit ist das 
auch kein Problem, obwohl ich aus der 8051-Ecke komme und dies erst mein 
dritter Versuch mit AVRs (ATMega8) und einem STK500 ist.
Ich komme aber an der Stelle zwischen "unbekanntem µC" und meinem AVR 
noch nicht zurecht, da sich das Gerät spezifikationsgerecht verhält und 
schön das Busy-Flag und wahrscheinlich auch den Adresszeiger des HD44780 
abfragt, was ich ja jetzt irgendwie emulieren müsste.
So, und jetzt stehe ich im Wald, da mir nichts einfällt, wie das mit den 
sportlichen Timing und einem AVR (aus Platzgründen möglichst ohne 
weitere Hardware) zu lösen ist.

Hat da jemand mit größerer Programmiererfahrung eventuell zielführende 
Hinweise?

Danke
Thomas

PS: Gefundene Emulationen des HD44780 weisen immer nur darauf hin, dass 
ein Lesen vom Displaycontroller nicht erforderlich sei, da das auch über 
das Timing zu lösen ist - hilft hier aber nicht weiter, da der steuernde 
Controller bei nicht richtig gesetztem Busy-Flag dieses immer weiter 
abfragt...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das Timing schnell ist, dann hast du keine Chance mit einem AVR. 
Innerhalb von <1µs müsstest du die Daten liefern. Zumindest ein Latch 
für die Daten und ein weiteres zum Ausgeben des Busy Flags werden schon 
notwendig sein (also quasi ein bidirektionales 1Byte FIFO)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas P. wrote:

> So, und jetzt stehe ich im Wald, da mir nichts einfällt, wie das mit den
> sportlichen Timing und einem AVR (aus Platzgründen möglichst ohne
> weitere Hardware) zu lösen ist.

Sehe ich auch so.
Im 4bit-Modus kommen ja 2 Nibble hintereinander mit vielleicht 1µs 
Abstand. Das schaffst Du bestenfalls im Polling, aber dann kann der AVR 
nichts anderes machen oder Du verlierst Zeichen.
Ohne nen CPLD (z.B. XCR3064) sehe ich schwarz.


Ich sehe jetzt auch nicht den Sinn, mehr darzustellen.
Ist das LCD denn größer, d.h. gibt es Bereiche, wo nie was steht.
Ansonsten gibts ja ein buntes Kuddelmuddel von dem Text den das Gerät 
liefert und dem Text, den Du zusätzlich einblendest.


Peter

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz so schlimm ist es auch nicht, ich muss da noch einmal mit dem LA 
ran, aber ich denke, so 5-7µs hätte ich schon Zeit zwischen E L>H und 
H>L. Die Sendung kommt auch regelmäßig alle 100ms von steuernden 
Controller und für den Zeitraum wären dann alle anderen Aktivitäten 
abzusagen. Gut, mal sehen, was die genaue Analyse noch zu Tage fördert.

Gruß
Thomas

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ich habe hier ein Gerät mit einem µC unbekannter Art,

Könnte es eventuell einfacher sein, die Funktion dieses Gerätes mit in 
den AVR zu packen. Dann hättest Du alles unter Kontrolle - und viele 
neue Erfahrungen gemacht ;-)

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

> Im 4bit-Modus kommen ja 2 Nibble hintereinander mit vielleicht 1µs
> Abstand. Das schaffst Du bestenfalls im Polling, aber dann kann der AVR
> nichts anderes machen oder Du verlierst Zeichen.

Was anderes machen braucht er auch nicht, aber das bringt mich auf eine 
Idee:  Im Zeitraum der einlaufenden Daten im Polling wirtschaften und 
nach Ende der Sendung bis zum Beginn der nächsten (100ms-Empfangszeit) 
die Zusatzdaten ausgeben bzw. über die serielle Schnittstelle empfangen, 
also serielle Schnittstelle umdrehen und aktiv nach Daten fragen. Mal 
sehen....

> Ohne nen CPLD (z.B. XCR3064) sehe ich schwarz.

Da sehe ich schwarz, da keinerlei Erfahrung damit und viel Strom und 
Platz soll (und darf) das Ding auch nicht brauchen.

> Ich sehe jetzt auch nicht den Sinn, mehr darzustellen.
> Ist das LCD denn größer, d.h. gibt es Bereiche, wo nie was steht.

Genau so ist es, und da soll noch etwas hin...

Gruß
Thomas

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:

> Könnte es eventuell einfacher sein, die Funktion dieses Gerätes mit in
> den AVR zu packen.

Leider nein, viiiieeel zu komplex für Reverse-Engineering (für mich und 
meine Freizeit).

> Dann hättest Du alles unter Kontrolle - und viele
> neue Erfahrungen gemacht ;-)

Leider kenne ich da meine Fähigkeiten zu genau - und bestimmte Sachen 
will ich garnicht wissen... ;-))

Gruß
Thomas

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich hole das noch einmal nach oben. Nach Erstellung eines Konzepts 
und eines Programmablaufplans habe ich mal an die Arbeit gemacht. Bin 
aber gleich beim ersten Schritt gescheitert. Das Aufteilen der Pins auf 
die benötigten Funktionen ergab beim aus Platzgründen gewählten Mega8, 
dass es nicht möglich ist, an einem Port 7 freie Pins zu finden, die ich 
aber für performantes Pollen unbedingt benötige: Port D fällt weg wegen 
der benötigten seriellen Schnittstelle und externen Interrupts, Port B 
wegen XTAL1 und 2 und Port C wegen /Reset. Wer zum Geier designt denn 
soetwas, dass ein µC bei typischer Beschaltung nicht einen Port mit 8 
nutzbaren Datenleitungen bietet? Ich frage mich gerade, ob ich zu 
dämlich bin, einen geeigneten Kontroller auszuwählen und ich das Geniale 
an diesem designtechnischen Murks nicht erkenne, oder ob das Entwickler 
von der Benutzung dieser Hardware abhalten soll.
Ich würde mich über Hinweise zu einem geegneten Kontroller freuen sowie 
ebenfalls über Hinweise zur Überwindung meiner offensichtlichen 
Blindheit, denn ich bin ja wohl nicht der Einzige, der mal einen 
8-Bit-Port benötigt?

Etwas frustrierte Grüße
Thomas

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieses herzallerliebste Problem ist nur ein einer Weise wirklich lösbar: 
Mit einer Crossbar zwischen den Pins der Funktionsmodule und den 
Portpins, wie Microchip sie in den PIC24/dsPIC33 implementiert hat.

Microchips erster Anlauf dieser Familie, die dsPIC30, hatten teilweise 
eine derart bescheuerte Pinbelegung (UART=I2C=SPI=CAN=Programmierpins), 
dass Microchip wohl genug Echo der Art "ich habt wohl ein Rad ab" 
bekommen hat, um sich zu einem derart drastischen Schritt zu 
entschliessen.

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-> Mega 16/32 ?

Gruß Fred

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Andreas Kaiser:
Leider habe ich als 8051er absolut keinen Plan von PICs und eine 
vollkommen neue Einarbeitung möchte ich mir in diesem Fall nicht antun.

@Fred:
Jo, der Mega16 ginge schon, ist aber eben gleich wieder mechanisch (und 
eigentlich vollkommen unnötig) größer als der Mega8. Und das alles nur 
wegen diesem Designmurks...

Gruß
Thomas

Autor: Roland Praml (pram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Evtl geht es so:

Wenn die Pausen in denen das Gerät nicht auf das LCD schreibt, 
einigermaßen konstant und lang genug sind, kannst ja du einfach 
schreiben.

z.B.: Wenn sich 10mS lang nix tut auf den Enable-Pin kann man ggf. davon 
ausgehen dass auch in den nächsten 90ms nix geschrieben wird.
also schnell Cursorposition auslesen, Daten schreiben und Cursor wieder 
herstellen.

Gruß
Roland

Autor: Maik Fox (sabuty) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man könnte vielleicht auch die noch benötigten Anzeigen einfach nach dem 
der Original-µC mit Display-Beschreiben fertig ist ans Display senden. 
Wenn der das sowieso nur alle 100ms macht, wartet man mit dem Atmega 
darauf, dass er mit dem Aktualisieren des Displays fertig ist und 
schreibt dann noch seine eigenen Sachen ins Display.

Was man da nur bräuchte, wäre ein Tristate-Buffer, damit man die Daten- 
und Controlleitungen des Original-µC vom Display entkoppeln kann.

Problem bei diesem Ansatz ist aber wohl eher wieder das Busy-Flag, dass 
ja trotzdem noch vom Original-µC gelesen werden können muss...

Autor: Maik Fox (sabuty) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...da war der Roland wohl schneller als ich ;)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
topla wrote:
> dass es nicht möglich ist, an einem Port 7 freie Pins zu finden, die ich
> aber für performantes Pollen unbedingt benötige: Port D fällt weg wegen
> der benötigten seriellen Schnittstelle und externen Interrupts, Port B
> wegen XTAL1 und 2 und Port C wegen /Reset.

Naja, Du könntest nen Bootloader reinbrennen und dann PC6 als IO fusen. 
Dann hast Du 7 Pins auf einem Port.

Du hast natürlich recht, daß es äußerst unklug war, die XTAL- und die 
UART-Pins auf verschiedene Ports zu legen.
Aber das ist der Abwärtskompatibilität zu den Classic-AVRs geschuldet, 
da waren die XTAL-Pins noch nicht als IO fusebar.


Peter

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, so in etwa habe ich mir das auch gedacht. Um möglichst schnell zu 
sein, will ich RW und E mit Gattern verknüpfen und auf je einen 
INT-Eingang gehen. Aus Zeitgründen dann in der ISR jeweils das SREG nur 
in ein Register sichern und den Port bedienen, kritisch ist eigentlich 
nur der Lesevorgang des Busy-Flags. Der Rest, also Flankenwechsel und 
das zweite Nibble läuft dann im Polling. Nachdem das Telegramm in 
konstanter Länge eingelaufen ist (ca. 6,5ms) habe ich alle Zeit der 
Welt, um die Daten aus dem Puffer dem LCD zu übergeben, da die 
Telegramme in exakt 100ms Abstand eintreffen. Bisher habe ich noch keine 
Abweichungen messen können. In der Zeit mit Bedienung des LCDs bzw. 
danach kann dann auch die serielle Schnittstelle scharf gemacht werden. 
Eigentlich wollte ich das über Empfangs-Interrupts lösen, aber während 
des Pollings darf nichts dazwischen kommen, da wird es eben eine 
Softwaresteuerung ala xon/xoff durch den LCD-Kontroller.

Gruß
Thomas

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
topla wrote:
> Ja, so in etwa habe ich mir das auch gedacht. Um möglichst schnell zu
> sein, will ich RW und E mit Gattern verknüpfen und auf je einen
> INT-Eingang gehen.

Anstatt extra Gattern würde ich nen ATMega48..168 nehmen, der hat nen 
PIN-Change Interrupt.


Peter

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da muss ich mich erstmal belesen, wenn es aber so ist, wie ich denke 
(Interruptauslösung bei jeder Änderung am Pin), dann bringt das nix, da 
ich ja dann immernoch in Software nachsehen muss, ob jetzt Schreiben 
oder Lesen dran ist. Genau das möchte und muss ich sparen, da ich durch 
die Verknüpfung schon einen Lese- und einen Schreibinterrupt habe. Oder 
mache ich einen Denkfehler?

Gruß
Thomas

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, das Ganze funktioniert wie geplant, die Gatterverknüpfung auf die 
Interrupteingänge tut es einwandfrei. Controller ist ein Mega16 
geworden, da sind genügend Pins frei. Auch das Bedienen der Busy-Abfrage 
funktioniert zeitgerecht - ich bin zufrieden.
Danke für alle konstruktiven Ratschläge.

Gruß
Thomas

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.