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...
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)
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
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
>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 ;-)
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
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
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
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.
@ 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
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
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...
...da war der Roland wohl schneller als ich ;)
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
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
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
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
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
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.