Sniffer für HD44780 Display

Hi

>Ich muss für ein Projekt die Ausgaben eines alten Geräts auf einem
>HD44780 Display irgendwie mitlesen.

Wozu? Du siehst doch, was auf dem Display passiert. Und die Befehle dazu 
sind bekannt.

MfG Spess

Es geht nicht darum das Display zu ersetzen oder nachzubauen, sondern 
den angezeigten Inhalt einem anderen (externen) System verfügbar zu 
machen.

mfg

Vielleicht das Teil hier:

http://www.watterott.com/de/Bus-Pirate

GB schrieb:
> Vielleicht das Teil hier:
>
> http://www.watterott.com/de/Bus-Pirate

Lt. Doku kann das Ding LCDs über eine Zusatzplatine ansteuern, aber 
mitlesen geht nicht. Hat jemand Infos ob das doch geht ?  Wenn ja, wär 
der buspirate ideal für meine Anwendung.

mfg

Reiner W. schrieb:
> Mal abgesehen, dass dich die Eingabe von "Sniffer HD44780" in die
> Suchmaschine deiner Wahl schon erheblich weiter gebracht hätte....

Wie ein LCD anzusteuern ist, und wie man es siffen kann ist mir durchaus 
bekannt.

> Für erste Experimente sollte der Ansatz aber reichen.

Sogern ich herum-experimentiere, in dem Fall ist bei mir leider keine 
Zeit dafür. Wie ich bereits oben schrieb: Der BusPirate wär' OK, wenn er 
von Haus aus sniffen könnte (leider geht das nicht; siehe Meldung ganz 
unten: 
http://dangerousprototypes.com/2009/08/13/bus-pirate-hd44780-character-lcd-adapter/)

mfg

Ich würde die Enable Leitung mit einem Interrupt Pin verbinden, und bei 
jedem Interrupt die anderen Leitungen einlesen und auswerten.

... oder eine Propeller. Ein COG, der nix anderes macht, als PINs zu 
überwachen.

Peter Dannegger schrieb:

> Flo schrieb:
>> Ich würde die Enable Leitung mit einem Interrupt Pin verbinden, und bei
>> jedem Interrupt die anderen Leitungen einlesen und auswerten.
>
> Eh Du endlich im Interrupt bist, die Register gesichert hast und die
> Leitungen gelesen hast, ist aber der E-Puls sowas von ewig vorbei, daß
> die Datenbits bestenfalls noch als Zufallszahl taugen.
> Und falls noch andere Interrupts enabled sind, no Chance.

Die Zeit ist völlig ausreichend. Da der Anwender Herr über sein Programm 
ist, kann er es so gestalten, dass er z. B. erst den Port ließt.

Darüber hinaus geht es natürlich auch ohne Interrupts: Auf den Pegel des 
E-Signals warten, den Port lesen und via serieller Schnittstelle 
"versenden". Das ganze in ein Assemblerprogramm gegossen (ein paar 
Stunden "Arbeit", wenn überhaupt), um die bestmögliche Kontrolle über 
die Zeit zu haben.

Karl Heinz schrieb:

> (...) Mit der fallenden Flanke werden die Datenleitungen übernommen und
> dürfen 10ns später wieder machen was sie wollen.

Ein 74LS374 mit einem Inverter vor seinem Clock-Pin tut genau dieses. 
Parallel dazu könnte man per Interrupt dem Controller Bescheid geben, 
damit der das Flipflop ausliest.

Pete K. schrieb:
> Wie wäre es mit einer Kamera, um die Ausgabe aufzuzeichnen?

Das hätte den grossen Vorteil, dass kein Eingriff ins Gerät notwendig 
wäre, allerdings ist die dafür notwendige OCR ein Fachgebiet in dem ich 
mich in etwa so gut auskenne wie die Kuh beim Eislaufen :-)

Karl Heinz schrieb:
> Nur garantiert dir die Spec vom HD44780 nicht, dass dann auch noch die
> richtigen Pegel am Port anliegen.

Muss es auch nicht. Die Kommunikation uC -> HD44780 soll mitgeschnitten 
werden, nicht die HD44780 -> uC. Bedeutet: es ist egal ob das HD44780 
die Pegel nicht zum passenden Zeitpunkt setzt, solange der uC dies 
macht.

Karl Heinz schrieb:
> Maxx schrieb:
>> Karl Heinz schrieb:
>>> Nur garantiert dir die Spec vom HD44780 nicht, dass dann auch noch die
>>> richtigen Pegel am Port anliegen.
>>
>> Muss es auch nicht. Die Kommunikation uC -> HD44780 soll mitgeschnitten
>> werden, nicht die HD44780 -> uC. Bedeutet: es ist egal ob das HD44780
>> die Pegel nicht zum passenden Zeitpunkt setzt, solange der uC dies
>> macht.
>
> Ist das wirklich so schwer zu begreifen?
> Das HD44780 hat gewisse Mindestzeiten. Die ANSTEUERDNE SCHALTUNG kann
> ihr Timing bis auf diese Mindestzeiten reduzieren. D.h. das ist das,
> womit dieser Sniffer zurecht kommen muss, wenn sie der ansteuernden
> Schaltung ein HD44780 vorgaukeln will, bzw. den Datentransfer
> mitschreiben will.
> Das Datenblatt vom HD44780 ist insofern relevant, weil es Auskunft
> darüber gibt, womit der Sniffer rechnen muss, wenn er die Leitungen
> beobachtet.

Du bist natürlich zu 100 % im Recht. Das Datenblatt ist die Mutter aller 
einzuhaltenden Zeiten. In der Praxis sind jedoch die Programme so 
geschrieben, dass ein Sniffer auf einem 20 MHz AVR funktionieren wird.

Wer anderer Meinung ist, der soll bitte seine Ansteuerung des HD44780 
bitte posten ;)

Karl Heinz schrieb:
> Das HD44780 hat gewisse Mindestzeiten. Die ANSTEUERDNE SCHALTUNG kann
> ihr Timing bis auf diese Mindestzeiten reduzieren. D.h. das ist das,
> womit dieser Sniffer zurecht kommen muss, wenn sie der ansteuernden
> Schaltung ein HD44780 vorgaukeln will, bzw. den Datentransfer
> mitschreiben will.

Das gilt genau dann, wenn jedes gültige aber unbekannte Setup durch 
Abdeckung aller möglichen Timings werden aufgefangen muss.

Das ist aber nicht der Fall und ein spezifisches Setup, also nur eine 
Teilmenge der möglichen Timings ist gegeben.

Eine Anekdote aus meiner Entwickler-Historie:
Wir haben Wochen gesucht, warum das neue Sharp-LCD in der Anzeige 
'hüpfte' das Original HD44780 nicht, obwohl doch beide kompatibel waren.
Ergbnis der Suche:
Der Ansteuernde Code im FPGA hat Strobe und Daten GLEICHZEITIG 
ausgeschaltet.
Ein HD44780 kann das ab (Holdtime 0ns), das Sharp-LCD hatte eine 
geforderte Holdtime von 10ns.
(Daten sollten 1ons länger anstehen als das Strobe)

Habs nicht mehr im Kopf parat, aber vermutlich sollte das Latch die 
Daten mit der steigenden Flanke von Strobe übernehmen.
Strobe kann dann natürlich trotzdem noch auf einen INT-Pin geführt 
werden, ich bezweifle ob ein SW-Polling einen 450ns Puls noch sauber 
erkennen kann.
Wär so ein schönes Bastelprojekt, nur leider fehlt mir aktuell die Zeit 
dazu :-(

Reinhold_By schrieb:

> Wär so ein schönes Bastelprojekt, nur leider fehlt mir aktuell die Zeit
> dazu :-(

Amen Bruder.
Mir gehts genauso... ...obwohl: Weihnachtsurlaub wär' eh bald.

Karl Heinz schrieb:
> Flo schrieb:
>> Ich würde die Enable Leitung mit einem Interrupt Pin verbinden, und bei
>> jedem Interrupt die anderen Leitungen einlesen und auswerten.
>
> Wird trotzdem eng.
> Laut HD Datenblatt, darf der E-Puls minimal 450ns lang sein. Vor der
> steigenden Flanke müssen R/W und RS korrekt eingestellt sein, zwischen
> steigender und fallender Flanke dürfen sich die Datenleitungen noch
> ändern, müssen aber eine bestimmte Zeit vor der fallenden Flanke stabil
> sein. Mit der fallenden Flanke werden die Datenleitungen übernommen und
> dürfen 10ns später wieder machen was sie wollen.
>
> Wenn man das exakt genau so, mit allen Möglichkeiten die sich daraus
> ergeben, alles berücksichtigen will, dann wirds zeitlich eng.
> Da kann man nur hoffen, dass die ansteuernde Elektronik nicht alle
> Möglichkeiten ausschöpft und die Datenleitungen auch nach der fallenden
> Flanke noch eine zeitlang stabil anliegen.

Dann wirft TO mit einem LPC1768 @ 100Mhz (oder was auch immer am Cortex 
M3 oder M4 ve3rfügbar ist) auf das Problem und 450ns sind eine mittlere 
Ewigkeit.

Oder er latcht das mit einem 574 oder was auch immer dazu verfügbar 
ist....

Grüße

MiWi

Karl Heinz schrieb:

> Laut HD Datenblatt, darf der E-Puls minimal 450ns lang sein.

Was für den AVR kein Problem darstellt, selbst wenn man das 
sinnloserweise Pollen wollte...

> Vor der
> steigenden Flanke müssen R/W und RS korrekt eingestellt sein

Also recht unwichtig, denn die dürfen ihren Zustand auch bis zur 
fallenden E-Flanke dann nicht mehr ändern.

> zwischen
> steigender und fallender Flanke dürfen sich die Datenleitungen noch
> ändern, müssen aber eine bestimmte Zeit vor der fallenden Flanke stabil
> sein.

Das ist der EINZIGE wirklich kritische Punkt. Die Setup-Zeit. Der 
Capture-Code muß nämlich sicherstellen, daß er den Status der Daten- und 
Steuerleitungen  höchstens um diese Zeit vor dem tatsächlichen 
Auftreten der fallenden E-Flanke gelesen hat. Dazu kommt aber leider die 
Latenz, mit der der Code eben diese fallende Flanke erkennen kann. Rein 
mit idiotischem Polling geht das wirklich nicht mehr mit dem AVR.

Aber mit einem sinnvollen Ansatz läßt sich das Problem natürlich 
lösen. Tatsächlich ist das garnichtmal so schwierig.

Interrupts machen es möglich. Man macht sich einfach den Sachverhalt 
zunutze, daß niedrig priorisierter Code im Moment der Interuptauslösung 
unterbrochen wird.

Also Pollschleife (worst case mit 8Bit-Ansteuerung des LCD):

poll:
 in R16,CTRLIN ; 1
 in R17,DATAIN ; 1
 rjmp poll     ; 2

Diese Schleife sorgt dafür, daß zu jeder Zeit in R16 und R17 der 
Status aller Signale liegt und diese Informationen maximal 4 Takte 
(200ns) alt sind. OK, das entspricht noch nicht ganz der Spezifikation, 
die läßt für die Setup-Time 195ns als Untergrenze zu. Aber auch das kann 
man notfalls noch unterbieten. Das wäre dann mal wieder ein Job für 
exzessives Loop-Unrolling. Oder man übertaktet den AVR einfach um diese 
lächerlichen 2,5%. Das kann der ab.

Dazu dann noch die ISR, die auf die H/L-Flanke des E-Signals reagiert, 
denn das ist der alles entscheidende Moment:

int:             ; 4 (konstante Latenz)
 st X+,R16       ; 2
 st X+,R17       ; 2
 cp XL,BUFENDL   ; 1
 cpc XH,BUFENDH  ; 1
 brcc auswertung ; 1
 reti            ; 4
                 ;--
                 ;15
auswertung:
  ...

solange der Puffer reicht, kann also nach 15 Takten (750ns) alles wieder 
von vorn losgehen, womit auch die Zykluszeit des HD44780 (1000ns) locker 
eingehalten ist und auch noch genug Zeit verbleibt, daß die Pollschleife 
mindestens noch einmal vor der nächsten H/L-Flanke die Signalinfo 
vollständig aktualisieren kann.

Bei 4Bit-Ansteuerung und entsprechend für nur einen Port angepaßtem 
Capture-Code verkürzt sich die Pollschleife übrigens auf drei Takte 
(150ns) und die ISR auf 13 (650ns). Da ist man dann endgültig auf der 
sicheren Seite.

Das alles ist absoluter Kinderkram für einen gelernten 
Asm-Programmierer, der sieht diese Möglichkeiten sofort.

Für C-ler eine Herausforderung? Scheint so. Der Herr Dannegger hat sich 
da ja sogar sehr resolut geäußert:

> Der AVR ist damit hoffnungslos überfordert.

Nein, mein lieber Herr Dannegger, es ist gut möglich, daß irgendwer 
damit hoffnungslos überfordert ist, der AVR ist aber wohl nicht 
derjenige, der ist damit nur knapp am Limit oder haarfein darüber, wie 
du mir ganz sicher
erzählen wirst wegen der fehlenden 2,5% im 8Bit-Modus oder dem doch 
letztlich unvermeidlichen einen rjmp beim alternativen Ausrollen der 
Schleife...

Dann können wir uns gleich auch noch über angewandte Statistik 
unterhalten. Auch ein schönes Thema...

Aha ... und wo ist die dekodierung und das anschließende 
weiterversenden?

c-hater schrieb:

> Also Pollschleife (worst case mit 8Bit-Ansteuerung des LCD):
>
> poll:
>  in R16,CTRLIN ; 1
>  in R17,DATAIN ; 1
>  rjmp poll     ; 2
>
> Diese Schleife sorgt dafür, daß zu jeder Zeit in R16 und R17 der
> Status aller Signale liegt und diese Informationen maximal 4 Takte
> (200ns) alt sind. OK, das entspricht noch nicht ganz der Spezifikation,
> die läßt für die Setup-Time 195ns als Untergrenze zu. Aber auch das kann
> man notfalls noch unterbieten. Das wäre dann mal wieder ein Job für
> exzessives Loop-Unrolling. Oder man übertaktet den AVR einfach um diese
> lächerlichen 2,5%. Das kann der ab.

Nicht ganz bis zum Ende durchdacht. Es geht auch ohne exzessives 
Loop-Unrolling und ohne Übertakten. Nämlich so:

> poll:
>  in R17,DATAIN ; 1
>  in R16,CTRLIN ; 1
>  in R17,DATAIN ; 1
>  rjmp poll     ; 2

Damit verlängert sich die Schleife zwar auf 5 Takte (250ns), aber dafür 
ist sichergestellt, daß die wirklich kritische Information immer 
höchstens drei Takte (150ns) alt ist.

Die Zykluszeit ist damit dann allerdings vollständig ausgereizt. So soll 
es sein. Für freie Rechenzeit gibt's kein Geld zurück.

Hallo,

was für ein Aufwand, man schliesst einen Logic Analyzer an und fertig.

Gruss Reinhard

@gnuopfer: Bist du jetzt nach sovielen Antworten schon einen Schritt 
weiter?

Geht es jetzt nur um ein re-display, oder darum dass das mitlesende 
System auch etwas mit den Daten anfangen kann? Also z.B. ein Umwandeln 
von Zahlen-Strings in byte/word/float ... ? Verstehen von 
Status-Anzeigen usw.

Das würde dem ganzen doch noch ein Stückchen an komplexität hinzufügen, 
weil man dann auch erkennen muss, wann z.B. die Übertragung eines 
zusammenhängenden Strings beendet ist, wo Zahlen anfangen ...
Am einfachsten wäre sicherlich die Kommandos zum setzen einer Adresse 
als Ende der vorherigen Übertragung zu interpretieren, da es bei LCDs 
eher unüblich ist Ausgaben einfach durchzuscrollen.

Wie gesagt, ich denke dass das mit einem Propeller in einer abendlichen 
Sitzung zu machen ist.

c-hater schrieb:
> c-hater schrieb:

>
> Die Zykluszeit ist damit dann allerdings vollständig ausgereizt. So soll
> es sein. Für freie Rechenzeit gibt's kein Geld zurück.

Reicht doch, wenn das Polling mit der steigenden E-Flanke am INT0 
beginnt und der letzte  Wert vor der fallenden Flanke gespeichert wird.
Dann bleibt Zeit das ganze auszuwerten.

MagIO schrieb:
> @gnuopfer: Bist du jetzt nach sovielen Antworten schon einen
> Schritt weiter?

Immerhin weiss ich jetzt das es mit den käuflichen Optionen (buspirate 
usw) nicht geht. Das spart Geld und Zeit fürs ausprobieren. Ich hab halt 
gehofft dass irgendjemand einen Adapter o.Ä. kennt, mit dem es geht. Es 
ist witzig dass es offensichtlich ein Thema ist, das bei vielen 
Entwicklern mal auftaucht aber niemand hat bisher etwas source dazu 
veröffentlicht.

> von Zahlen-Strings in byte/word/float ... ? Verstehen von
> Status-Anzeigen usw....

Das Interpretieren der Daten vom Display muss ich sowieso selbst machen, 
das kann mir kein anderes System abnehmen.