Moin zusammen, Ich bin grade dabei das Display von meinem Autoradio zu kapern (128x16). Wie die Datenübertragung funktioniert ist mittlerweile klar, jetzt geht es darum das Ganze für eigene Zwecke umzumodellieren. Die Daten werden seriell Bit für Bit bzw Pixel für Pixel übertragen, wenn der Data/Command-Pin auf High ist. Ich würde gerne die Funktion des Radios erhalten, jedoch die Möglichkeit haben, auf Teilen des Displays etwas anderes anzuzeigen. Meine Idee war folgende: Über einen Multiplexer (Duplexer?) den SerialIn-Pin auf einen zweiten Mikrocontroller legen sobald D/C High wird (statt auf DataIn vom Display). Dann soll der µC mit einem Interrupt die Signale aufnehmen, zwischenspeichern und anschließend die zweiten, individuellen Daten drüberlegen. Jetzt werden die kombinierten Daten an das Display weitergeschickt. Die Frequenz mit der die Daten über den Seriellen Bus geschickt werden ist ungefähr 50khz (clock). Im Leerlauf schickt das Radio jede Sekunde einmal die Daten durch. Wenn ein Knopf gedrückt wird, wird automatisch auch ein Refresh ausgelöst. Der zweite µC Müsste also ziemlich schnell sein. Am besten fast synchron. Somit würde der "original"-µC weiterhin alle Commandos schicken, die Daten werden aber von meinem µC eingeschleust. Kann das soweit funktionieren oder seht ihr irgendwelche größeren Probleme? Müsste ich da am Besten mit Assembler ran oder kriegt man das auch "einfach" in C gelöst? Gerne auch andere Lösungsvorschläge falls euch was "Besseres" einfällt :-) EDIT: Wobei. Es wäre wahrscheinlich praktischer, falls ein Knopf gedrückt wird, den zweiten µC und das Overlay für zb 5 Sekunden zu deaktivieren. Das würde die Bedienung vereinfachen
:
Bearbeitet durch User
1. Datenleitung auftrennen und 2. Portpins (Eingang und Ausgang) Deines µCs dazwischen hängen. 2. Clockleitung an einen IRQ-Eingang 3. D/C an einen weiteren Eingang. Sobald D/C auf Daten schaltet, den IRQ einschalten. Dabei sollte dieser genau auf der anderen Flanke liegen, als der, bei der das Display die Daten übernimmt. Bei jedem IRQ wird ein Zähler inkrementiert. Solange sich der Zähler außerhalb Deines Bereichs (Bereiche!) befindet, werden die Daten vom Eingangspin mit höchstmöglicher Geschwindigkeit zum Ausgangspin geschaufelt. Ist der Zähler innerhalb, dann muss bei jedem IRQ ein Bit aus Deinem Speicher am Datenpin ausgegeben werden. Wenn D/C wieder auf Kommandos schaltet, alle Zähler zurücksetzen, Daten wieder einfach durchreichen. Viel Spaß! Gruß Jobst
:
Bearbeitet durch User
Jobst M. schrieb: > 1. Datenleitung auftrennen und 2. Portpins (Eingang und Ausgang) Deines > µCs dazwischen hängen. > 2. Clockleitung an einen IRQ-Eingang > 3. D/C an einen weiteren Eingang. > > Sobald D/C auf Daten schaltet, den IRQ einschalten. > Dabei sollte dieser genau auf der anderen Flanke liegen, als der, bei > der das Display die Daten übernimmt. > Bei jedem IRQ wird ein Zähler inkrementiert. > Solange sich der Zähler außerhalb Deines Bereichs (Bereiche!) befindet, > werden die Daten vom Eingangspin mit höchstmöglicher Geschwindigkeit zum > Ausgangspin geschaufelt. Ist der Zähler innerhalb, dann muss bei jedem > IRQ ein Bit aus Deinem Speicher am Datenpin ausgegeben werden. > Wenn D/C wieder auf Kommandos schaltet, alle Zähler zurücksetzen, Daten > wieder einfach durchreichen. > > Viel Spaß! > > Gruß > Jobst Perfekt, danke dir für deine ausführliche Antwort. Das klingt schon mal nach einem guten Leitfaden. Jetzt muss ich mich nurnoch um einen geeigneten µC kümmern. Ich hätte gerne ein CAN-Anbindung, da ich einige Sensoren auslesen + anzeigen lassen will. Hat da eventuell jemand eine geeignete Kombination im Kopf? Ich hatte an den ATMEGA16M1 gedacht, der hätte CAN direkt mit an Board. Oder macht ein dedizierter CAN-IC hier mehr Sinn der dann über SPI angebunden wird? Das ganze auf einem ATTINY zu realisieren wäre natürlich cool, jedoch wird es da schon mit den seriellen Schnittstellen knapp, wenn ich noch einen IC anbinden will (oder?) Ist mein erstes "größeres" Projekt, deshalb entschuldige ich mich mal für eventuell offensichtliche Fragen :-)
:
Bearbeitet durch User
Solche Fragen wurden hier schon öfter gestellt und sämtliche Versuche mangels Erfolg bzw. ausufernder Komplexität wieder eingestellt. Du müßtest alle Kommandos prüfen, ob sie Positionen setzen oder beschreiben, die im gesperrten Bereich liegen. Wenn Du nur mitlauschst, ist es zu spät, das LCD hat sie dann schon empfangen. Du müstest also sämtliche Daten erstmal zwischenspeichern, um zu entscheiden, sollen sie weiter gereicht werden oder nicht. Außerdem müßtest Du alle globalen Kommandos so umändern, daß sie nur den erlaubten Bereich ändern. Und Du müßtest Deine eigenen Daten geschickt mit einfädeln, ohne das es zu Kollisionen kommt.
Ein anderer Ansatz wäre, der zwischen-MC fungiert als Software-LCD, d.h. schreibt in einen internen Bildspeicher. Diesen gibt er dann zyklisch mit dem zusätzlichen Bereich an das LCD aus. Der MC muß alle LCD-Befehle intepretieren. Das Ganze wird also richtig aufwendig.
> Der MC muß alle LCD-Befehle intepretieren. Das Ganze wird also richtig > aufwendig Eigentlich nicht. Er kann ja alle Befehle welche sich nicht als Pixel auf dem Screen wiederfinden, ignorieren. Aber natuerlich muss man dann einmal selber das Display initialisieren. Vanye
Peter D. schrieb: > Der MC muß alle LCD-Befehle intepretieren. Das Ganze wird also richtig > aufwendig. Mal in meiner Uralt-Bookmarkkiste gekramt: http://dinceraydin.com/djgfxlcdsim/djgfxlcdsim.html Das Javascript ist recht übersichtlich, und es ist ja nichtmal gesagt, dass das Autoradio alle möglichen Befehle auch nutzt.
Ricardo M. schrieb: > Ich bin grade dabei das Display von meinem Autoradio zu kapern (128x16). Für so ein winziges LCD wäre mir der Entwicklungsaufwand viel zu hoch.
Peter D. schrieb: > Für so ein winziges LCD wäre mir der Entwicklungsaufwand viel zu hoch. Immerhin hätte er mit einer Simulator-Lösung die Option ein viel größeres LCD anzuschließen, und den 128x16-Bereich da irgendwie reinzumappen.
Peter D. schrieb: > Für so ein winziges LCD wäre mir der Entwicklungsaufwand viel zu hoch. Andererseits wäre dabei der Buffer, den der 'Man-in-the-Middle' MC bereitstellen muss, auch entsprechend übersichtlich und zumindest mal eine gute Fingerübung für den TE. Aber stimmt schon, das ist recht winzig.
Matthias S. schrieb: > Peter D. schrieb: >> Für so ein winziges LCD wäre mir der Entwicklungsaufwand viel zu hoch. > > Andererseits wäre dabei der Buffer, den der 'Man-in-the-Middle' MC > bereitstellen muss, auch entsprechend übersichtlich und zumindest mal > eine gute Fingerübung für den TE. Aber stimmt schon, das ist recht > winzig. Naja hier geht es ja nicht um das Display selbst, sondern darum das Autoradio im verbauten Zustand für eigene Zwecke zu nutzen. Es soll neben dem üblichen Radiokram auch Vcc, Strom (Generator,Batteri out/in), Öltemp, etc anzeigen. Wichtig sind eigentlich nur die Anfangskommandos der ersten 200ms, wenn das Display initialisiert wird. Die Kommandos danach sind recht übersichtlich und regeln nur den Speicher/Pagezugriff des LCD-Controllers. Ich will auch bewusst kein anderes Display einbauen, da es am Ende nicht nach Bastelbude aussehen soll :-) Sonst könnte man sich den ganzen Aufwand sparen und einfach einen CAN-Receiver + 16x2 Display verbauen Peter D. schrieb: > Solche Fragen wurden hier schon öfter gestellt und sämtliche Versuche > mangels Erfolg bzw. ausufernder Komplexität wieder eingestellt. > > Du müßtest alle Kommandos prüfen, ob sie Positionen setzen oder > beschreiben, die im gesperrten Bereich liegen. Wenn Du nur mitlauschst, > ist es zu spät, das LCD hat sie dann schon empfangen. > Du müstest also sämtliche Daten erstmal zwischenspeichern, um zu > entscheiden, sollen sie weiter gereicht werden oder nicht. Außerdem > müßtest Du alle globalen Kommandos so umändern, daß sie nur den > erlaubten Bereich ändern. > Und Du müßtest Deine eigenen Daten geschickt mit einfädeln, ohne das es > zu Kollisionen kommt. Die Daten werden ohne Zwischenkommando seriell durchgeschoben. Das heißt insgesamt 1024 Clockcycles am Stück deren Anfang sich ganz leicht über die Data/Command-Line erkennen lässt. Ich hätte jetzt vermutet dass es reicht die Daten über den MC aufzunehmen, den entsprechenden Bereich zu manipulieren und dann wieder rauszugeben? Kommandos sind hier wie gesagt nur 3 nötig Ablauf: Page adress set -> column adress set -> column adress set lower bit -> DATA/CMD High -> 1024x Pixel als einzelne ClckCycles.
:
Bearbeitet durch User
Klingt doch spannend; probier's aus. Radio auf den Basteltisch und los geht's ;) Das am Kfz im eingebauten Zustand testen zu wollen, würde ich für den Anfang ablehnen.
Axel R. schrieb: > Klingt doch spannend; probier's aus. Radio auf den Basteltisch und los > geht's ;) Das am Kfz im eingebauten Zustand testen zu wollen, würde ich > für den Anfang ablehnen. Ist schon passiert :D hab mir auch zwei weitere Radios besorgt und die Stecker ausgeschlachtet um einen ordentlichen Adapter zwischen Radio und Display zu verbauen. Ich häng mal den Saleae Logic Trace mit an und das Datenblatt des Controllers, falls es jemanden interessiert :-) Das ätzende wird wohl eher, dass ich die ganze Bibliothek für Zeichen und Buchstaben selbst schreiben/definieren muss, da der Controller keine interne hat. Oder kennt jemand dafür ein existierendes Tool?
:
Bearbeitet durch User
Ron-Hardy G. schrieb: > Ricardo M. schrieb: >> 1024x Pixel als einzelne ClckCycles > > bei einem 128x16 Display? Ah upsi, du hast recht. Es sind 1024 Pixel pro Page/Zeile (8x128). Also ingesamt 2048 die jeweils in 1024er Paketen verschickt werden
:
Bearbeitet durch User
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.