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
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
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
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
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
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.
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.
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.
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
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.
Man braucht minimal noch ein externes 8Bit-Latch bzw. im 4Bit-Mode 2 4Bit-Latches + etwas Zusatzlogik.
... 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.
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
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.
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
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.
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
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. 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
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 :-(
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.
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
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ß
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.
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.
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.
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.
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.