Forum: Mikrocontroller und Digitale Elektronik Sniffer für HD44780 Display


von gnuopfer (Gast)


Lesenswert?

Hallo,

Ich muss für ein Projekt die Ausgaben eines alten Geräts auf einem 
HD44780 Display irgendwie mitlesen. Ob über PC oder MC ist erstmal egal;
Die Problemstellung hatten offenbar schon mehrere Leute (auch hier im 
Forum), aber ich hab dennoch keine handfesten infos gefunden.
Hat das Thema schon mal jemand gelöst oder kennt einen brauchbaren link 
?

mfg

von spess53 (Gast)


Lesenswert?

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

von gnuopfer (Gast)


Lesenswert?

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

mfg

von GB (Gast)


Lesenswert?

Vielleicht das Teil hier:

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

von Reiner W. (reiner_w)


Lesenswert?

Mal abgesehen, dass dich die Eingabe von "Sniffer HD44780" in die 
Suchmaschine deiner Wahl schon erheblich weiter gebracht hätte, sollte 
schon ein recht simpler Arduino Sketch ausreichend sein (wenigstens bei 
einer 4bit Ansteuerung):

DB0->DB7 sowie RS und E  an Arduino I/O Eingänge.
Prinzipiell reicht es dann, wenn der Eingang RS getriggert wird.
Die Daten können dann an DB0-7 ausgelesen werden und zwar mit jedem 
E-Takt in der Form LByte, HByte.

Komplizierter wird es erst, wenn selbst erstellte Zeichen gelesen werden 
müssen bzw. Befehle mitgeschnitten werden sollte. Für erste Experimente 
sollte der Ansatz aber reichen.

gruß

: Bearbeitet durch User
von gnuopfer (Gast)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

Laut Produktbeschreibung
1
Produktbeschreibung
2
3
Der Bus Pirate ist ein Analyzer für viele seriellen Signale. Das Gerät wurde von Ian Lesnet entwickelt.
4
5
Unterstützte Protokolle:
6
...
7
HD44780 LCD
8
...

kann er es aber doch.

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

Reiner W. schrieb:
> DB0->DB7 sowie RS und E  an Arduino I/O Eingänge.

Wie willst Du dann auf den 450ns kurzen E-Puls triggern?
Der AVR ist damit hoffnungslos überfordert.

von gnuopfer (Gast)


Lesenswert?

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

von Flo (Gast)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

Karl Heinz schrieb:
> Laut Produktbeschreibung
>
1
> Produktbeschreibung
2
> 
3
> Der Bus Pirate ist ein Analyzer für viele seriellen Signale. Das Gerät 
4
> wurde von Ian Lesnet entwickelt.
5
> 
6
> Unterstützte Protokolle:
7
> ...
8
> HD44780 LCD
9
> ...
10
>
>
> kann er es aber doch.

Ich nehms zurück.
Das scheint ein wenig missverständlich geschrieben zu sein.

von Karl H. (kbuchegg)


Lesenswert?

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.

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

Man braucht minimal noch ein externes 8Bit-Latch bzw. im 4Bit-Mode 2 
4Bit-Latches + etwas Zusatzlogik.

von MagIO (Gast)


Lesenswert?

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

von Pete K. (pete77)


Lesenswert?

Wie wäre es mit einer Kamera, um die Ausgabe aufzuzeichnen?

von Davis (Gast)


Lesenswert?

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.

von Thomas P. (topla)


Lesenswert?

Moin,
ich hatte hier
Beitrag "Re: HD44780 - man in the middle mit AVR?"
das Problem für mich befriedigend gelöst.
Mit einer Gatter-Verknüpfung auf jeweils einen INT-Eingang für RD und WR 
und dann eine kurze ISR der Art:
int_wr:
   in    sreg_backup, sreg    ; SREG sichern
   in    inp_MC, PINA       ; Daten holen und sichern

Die Zeit wird bei 16MHz dicke ausreichen, aber sicherheitshalber kann 
man ja vorher mal das Timing mit einem Oszi prüfen. Wenn das ein älteres 
Gerät ist, laufen die Zugriffe mit Sicherheit auch nicht an der Grenze 
sondern haben Reserven.

Thomas

von Soul E. (Gast)


Lesenswert?

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.

von Karl H. (kbuchegg)


Lesenswert?

Davis schrieb:

> 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.

Schon.
Nur garantiert dir die Spec vom HD44780 nicht, dass dann auch noch die 
richtigen Pegel am Port anliegen. Man kann natürlich hoffen, dass die 
ansteuernde Schaltung nicht am minimal notwendigen operiert, aber laut 
Murphy ist das genau dann der Fall, wenn es wirklich wichtig wäre, dass 
die Schaltung problemlos funktioniert.

: Bearbeitet durch User
von gnuopfer (Gast)


Lesenswert?

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 :-)

von Maxx (Gast)


Lesenswert?

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.

von Karl H. (kbuchegg)


Lesenswert?

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.

: Bearbeitet durch User
von Davis (Gast)


Lesenswert?

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 ;)

von Thomas P. (topla)


Lesenswert?

Karl Heinz schrieb:
> Das HD44780 hat gewisse Mindestzeiten. Die ANSTEUERDNE SCHALTUNG kann
> ihr Timing bis auf diese Mindestzeiten reduzieren.

Und genau das sollte man sich als Erstes mal mit einem Oszi oder LA 
anschauen. In meinem Beispiel waren die Mindestzeiten recht großzügig 
ausgelegt.
In so einem Fall ist es auch nett, wenn die Ansteuerung des Displays mit 
einem Burst erfolgt, also alle Daten für ein "Bild" hintereinander im 
Pulk kommen und nicht alle paar Millisekunden ein Byte hereintröpfelt.

Thomas

von Maxx (Gast)


Lesenswert?

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.

von Reinhold_By (Gast)


Lesenswert?

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 :-(

von Max H. (hartl192)


Lesenswert?

Ich würde einfach z.B. mit einem Oszi messen, wie lange die Daten nach 
dem Enable  anliegen und ob es vom Timing her problemlos möglich ist, 
die Daten mit einem µC in der ISR auszuwerten.

von gnuopfer (Gast)


Lesenswert?

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.

von MiWi (Gast)


Lesenswert?

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

von Reiner W. (reiner_w)


Lesenswert?

Also ohne nähere Messungen kann man da eigentlich nicht sagen, was 
konkret in deinem Fall Sinn macht.
Hab grad mal beim Display an meinem Raspi gemessen, da beträgt die 
E-Zylkuszeit beim Schreiben von Daten 3,1ms. Das wäre mit einem IRQ auf 
E sicher nicht das Problem.
Dabei frag ich mich grade, wie ich die Daten dann am Besten 
weiterreiche.

Gruß

von Reiner W. (reiner_w)


Angehängte Dateien:

Lesenswert?

Also die beliebten Saleae - Analyzer (habs grad mit nem Kompatiblen 
getestet) können mit folgendem Plugin 
http://omarfrancisco.com/hd44780-protocol-analyzer/
auch ganz gut das HD44780 Protokoll sniffen.

von c-hater (Gast)


Lesenswert?

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...

von MagIO (Gast)


Lesenswert?

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

von c-hater (Gast)


Lesenswert?

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.

von Reinhard Kern (Gast)


Lesenswert?

Hallo,

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

Gruss Reinhard

von Herr M. (herrmueller)


Angehängte Dateien:

Lesenswert?

So sieht es dann mit einem Logic Analyzer aus (ab D3).

von MagIO (Gast)


Lesenswert?

@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.

von Reiner W. (reiner_w)


Lesenswert?

Also ich für meinen Teil, hab ne ganze Menge über die HD44780 
Ansteuerung gelernt (beschäftige mich grad mit einer ähnlichen 
Problematik) ;-)

Danke für die geballte Kompetenz hier.

von irgendwer (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

Reiner W. schrieb:
> Hab grad mal beim Display an meinem Raspi gemessen, da beträgt die
> E-Zylkuszeit beim Schreiben von Daten 3,1ms.

Daß der Raspi so extrem schnarch langsam das LCD schreibt, hätte ich 
nicht gedacht.
3,1ms / 450ns = 6889-fach langsamer als das LCD.
Da kann der AVR beim Sniffen ja noch nebenbei Schach spielen.

Ich hatte früher mal das LCD beim 8051 als memory mapped IO eingebunden, 
da war das Timing schon recht sportlich (400ns bei 12MHz). Bei 16MHz 
wollte das LCD schon nicht mehr.

von Reiner W. (reiner_w)


Lesenswert?

Peter Dannegger schrieb:
> Daß der Raspi so extrem schnarch langsam das LCD schreibt, hätte ich
> nicht gedacht.
> 3,1ms / 450ns = 6889-fach langsamer als das LCD.
> Da kann der AVR beim Sniffen ja noch nebenbei Schach spielen.

Sorry, das ist so nicht ganz richtig. Hätte vlt. dazu schreiben sollen, 
dass ich das Display mit einem I2C Expander (PCF8574) steuere und da 
muss ich ja schon 4 Bytes per I2C für ein Byte am LCD schicken um den 
Takt zu simulieren. Das ganze wird dann per Python Skript gesteuert, was 
das Verfahren aber nicht merklich verlangsamt. Habe zum Test (und als 
Fingerübung) auch als Bash-Skript per i2cset umgesetzt. Da kannst kann 
man dann die Buchstaben locker mitschreiben;-)
Aber immerhin zeigt es, wie tolerant der HD44780 in Sachen Timing ist 
und dass das ursprüngliche Problem ohne Kenntnis der tatsächlichen 
Ansteuerung kaum sinnvoll zu lösen ist.

von gnuopfer (Gast)


Lesenswert?

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.

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.