Forum: Fahrzeugelektronik LIN to RGB - Hilfe gesucht


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Max W. (max_w711)


Lesenswert?

Moin in die Runde!

Ich hab zwar schon versucht, etwas passendes zu finden, bin aber noch 
nicht auf den richtigen Beitrag gestoßen.

Folgende Idee, bei der ich noch nicht so richtig weiter weiß...

Bei Fahrzeugen mit Ambientebeleuchtung ist in den meisten Fällen die LED 
der LIN-Slave, welcher einen bestimmten Befehl in eine RGB-Farbe 
umwandelt.
Es müsste doch also möglich sein, diesen Befehl separat zu lesen und mit 
entsprechendem IC weitere blinde Slaves (also Fahrzeug kennt diese 
nicht, sie lesen aber den Befehl einfach mit) zu programmieren, damit 
man beliebig viele weitere LED's ansteuern kann.

Soll also heißen, ich möchte z.B. pro Tür ein IC verbauen, mit dem ich 
dann einer normales RGB-LED sage, welche Farbe sie jetzt ausstrahlt.

Im speziellen Fall wäre es möglich, dass ich R G und B separat codieren 
und ansteuern kann, damit ich die einzelnen LIN-Befehle der Grundfarben 
schon mal habe.

Es können in diesem Fahrzeug maximal 10 Farben hinterlegt werden, die 
per RGB-Wert codiert werden (VCDS, VW-Plattform). Ich kann also zwischen 
0 und 255 für Rot, Blau und Grün angeben, der Master wandelt es in LIN 
um und die LED dann logisch wieder in RGB zurück.

Ich habe nun auch schon einige Hersteller gefunden, die solche IC's 
anbieten, teilweise auch gleich mit der LED, bei denen sich die 
Industrie wohl auch bedient. Leider fehlt mir da noch das technische 
Know-How in der Programmierung. Ich bin aber nicht auf den Kopf 
gefallen, habe diverse Sachen mit Arduinos und Pi's umgesetzt und bin 
gewillt, bestimmt Sachen zu erlesen um sie zu verstehen. Mir würde hier 
also durchaus reichen, wenn man mir gewisse Richtungen vorgäben könnte, 
damit ich Ideen bekomme, wie ich das Ganze umsetzen kann.

Meine Idee wäre nun folgende:

Ich nehme einen Arduino oder Rasp-Pi mit entsprechendem Board und lese 
mir den LIN direkt an der LED aus. Mit VCDS fange ich mit jeder Farbe 
erstmal einzeln an, damit ich die Grundfarben habe, mache dann 
Mischfarben und speicher mir die einzelnen Datensätze ab.
Wenn ich diese habe, nutze ich das Board, um den Befehl aus dem LIN per 
Befehl in eine RGB zu wandeln und an eine LED weiter zu geben.

Da käme dann schon die erste Frage, falls das so überhaupt geht...
Müsste hier jede LIN-Farbe per "if" an RGB weitergegeben werden oder 
gibt es da einen Algorythmus, der anhand von den R's, G's und B's 
errechnet, welcher Wert das aktuell genau ist? (Ich hoffe ihr versteht, 
was ich meine)

Ich würde mich über Unterstützung freuen!

Liebe Grüße

Max

: Bearbeitet durch User
von Michael B. (laberkopp)


Lesenswert?

Max W. schrieb:
> Bei Fahrzeugen mit Ambientebeleuchtung ist in den meisten Fällen die LED
> der LIN-Slave, welcher einen bestimmten Befehl in eine RGB-Farbe
> umwandelt.
> Es müsste doch also möglich sein, diesen Befehl separat zu lesen und mit
> entsprechendem IC weitere blinde Slaves (also Fahrzeug kennt diese
> nicht, sie lesen aber den Befehl einfach mit) zu programmieren, damit
> man beliebig viele weitere LED's ansteuern kann

Ja.

Max W. schrieb:
> Da käme dann schon die erste Frage, falls das so überhaupt geht

Es geht, aber deine Frage zeigt, dass du es nicht hinbekommen wirst.

Wünschen alleine reicht nicht, man muss auch (programmieren) können. 
Also das, was andere in der Zeit gelernt haben, als du dich um Autos 
gekümmert hast.

von Achim M. (minifloat)


Lesenswert?

Max W. schrieb:
> Müsste hier jede LIN-Farbe per "if" an RGB weitergegeben werden oder
> gibt es da einen Algorythmus, der anhand von den R's, G's und B's
> errechnet, welcher Wert das aktuell genau ist?

Wenn du das LDF hast, geht's einfach.
Könnte man in dem Fall bestimmt auch reverse engineeren.

 Vermutlich ist für R G B jeweils ein Byte in einem der LIN-Frames 
vorgesehen, das dann jeweils proportional zur Intensität der Grundfarben 
ist. Also einfach PWM draus machen oder der WS1812-Library übergeben.

256³ = 16777216 if-statements kannst du vergessen. Und was, wenn das 
noch zwischendurch mit der im Fahrzeugmenü einstellbaren Helligkeit der 
Ambientebeleuchtung verrechnet wird oder von Abblendlicht an/aus 
abhängig ist, werden dir deine 3 exakt definierten Lieblingsfarben nicht 
ausreichen.

mfg mf

von Frank K. (fchk)


Lesenswert?

Max W. schrieb:

> Soll also heißen, ich möchte z.B. pro Tür ein IC verbauen, mit dem ich
> dann einer normales RGB-LED sage, welche Farbe sie jetzt ausstrahlt.

Ein IC reicht da nicht.

Zum ersten brauchst Du einen LIN-Transceiver, der aus dem Bus-Signal TX 
und RX für die uC macht. Da gibts dann auch welche, die gleich noch den 
Spannungsregler drin haben, um aus den 12V dr Busspannung 5V oder 3.3V 
für den uC zu machen. Dahier ist z.B. so einer:

https://www.onsemi.com/download/data-sheet/pdf/ncv7428-d.pdf

Der gibt bis zu 70mA an Strom raus. Viel zu wenig für einen Pi. Vergiss 
den einfach, der ist dafür nicht gedacht.

LIN ist im Prinzip eine serielle Schnittstelle, aber mit ein paar 
Besonderheiten. Die klassischen Atmel-AVRs, die auch auf den meisten 
Arduinos drauf sind, kamen mit diesen Besonderheiten nicht gut zurecht. 
Die moderneren von Microchip haben extra LIN-Support in der Hardware und 
sind für Dein Vorhaben besser geeignet. Beispiel der hier:

https://www.microchip.com/en-us/product/attiny3216

Der hat dann auch Timer und PWM-Ausgänge, mit denen Du Deine R, G, B 
LEDs dimmen kannst. Denke daran, insgesamt nicht über 70mA zu kommen. 
Wie das genau geht, liest Du am besten irgendwo nach. Ein Forum ist 
nicht der geeignete Ort für Grundlagenwissen, eher für kurze 
Detailfragen.

Dann wirst Du den passenden LIN-Standard brauchen. Weißt Du, ob Dein 
Fahrzeug LIN 1.3 oder LIN 2.x benutzt? Danach richtet sich auch z.B. die 
Prüfsummenberechnung.

Das mal so ganz kurz.

fchk

von Harald A. (embedded)


Lesenswert?

Im ersten Moment würde ich Dir mal einen LIN-Analysetool anraten, damit 
Du überhaupt nachvollziehen kannst auf welcher ID was wie wo wann 
gesendet wird. Wenn ich das richtig verstanden habe kannst Du per VCDS 
Farben gezielt auslösen. Dann würdest Du sehen, wie das im Protokoll 
umgesetzt ist. Danach kann man weiter sehen. Fertige Bausteine, die 
direkt auf das Protokoll gemünzt sind, halte ich für unwahrscheinlich.
Zum Analyse-Tool. Ich gehe mal nicht davon aus, dass Du viel Geld 
ausgeben möchtest für ein Profi-Tool. Auf Ali gibt es einen samt 
Software, ob der aber etwas taugt musst Du selber rausfinden.
https://de.aliexpress.com/item/1005007460915625.html

von Harald A. (embedded)


Lesenswert?

Frank K. schrieb:
> Die klassischen Atmel-AVRs, die auch auf den meisten
> Arduinos drauf sind, kamen mit diesen Besonderheiten nicht gut zurecht.

Du spielst vermutlich auf die Break-Erkennung an? Ich kann man nicht 
genau erinnern welche es war, aber ich habe das auf CPUs ohne 
LIN-Support schon so gemacht, dass ich gezielt auf den Empfang eines 
Bytes mit dem Wert 0 warte, welches gleichzeitig einen Frame-Error 
ausgelöst hat. Keine echte Break-Erkennung, funktionierte aber recht 
zuverlässig.

: Bearbeitet durch User
von Achim M. (minifloat)


Lesenswert?

Frank K. schrieb:
> Zum ersten brauchst Du einen LIN-Transceiver, der aus dem Bus-Signal TX
> und RX für die uC macht

TX braucht er nicht, weil er nur mitlauschen möchte. Der antwortende 
LIN-Slave wird wohl am Bus belassen.

Frank K. schrieb:
> Weißt Du, ob Dein Fahrzeug LIN 1.3 oder LIN 2.x benutzt? Danach richtet
> sich auch z.B. die Prüfsummenberechnung.

Braucht er vielleicht empfangsseitig. Weil der TO die Farben per VCDS 
parametrieren kann (VAG "codieren" und andere OEMs "kalibrieren"), gehe 
ich mindestens von einem "Diagnoseklasse 3"-Steuergerät aus, wo auch die 
Parameter (Farben) gespeichert sind. Also sind die Farben nicht im 
EEPROM des LIN-Slave.

Vielleicht noch als Anmerkung, LIN ist nicht standardisiert in Bezug auf 
die Dateninhalte, also kein Protokoll zur Lichtsteuerung wie z.B. 
DMX-512:1990...

Max W. schrieb:
> der LIN-Slave,
Mitschnitte dessen Kommunikation bei einfachen Kombinationen der 
Grundfarben (z.B. nur rot, nur grün, nur blau, gelb, magenta, türkis, 
weiß und schwarz/aus) helfen beim reverse engineeren.

mfg mf

von Achim M. (minifloat)


Lesenswert?

Harald A. schrieb:
> Keine echte Break-Erkennung, funktionierte aber recht zuverlässig.

Yes. Der Frame-Error bei den Atmels gehorcht auf Stoppbit = 0. Zusammen 
mit den 55er Syncbytes und protected identifiern ist das wirklich gut 
genug 👍

Wenn man seinem Knoten einen Quarz spendiert, ist auch kein vermessen 
der Bitrate während der Syncbytes nötig...

mfg mf

von Harald A. (embedded)


Lesenswert?

Und auf die Berechnung der Checksumme kannst Du für ein Bastelprojekt 
beim reinen Mitlesen auch verzichten.
Im Grunde wäre es also nicht mal so schwer: Break erkennen, 0x55 prüfen, 
folgende ID korrekt? Falls ja, Folgebytes abzählen und verwerten. Falls 
nein, auf das nächste Break warten.

: Bearbeitet durch User
von Max W. (max_w711)


Lesenswert?

Michael B. schrieb:
> Wünschen alleine reicht nicht, man muss auch (programmieren) können.
> Also das, was andere in der Zeit gelernt haben, als du dich um Autos
> gekümmert hast.

Stimmt! Aber du freust dich ja sicherlich auch, wenn man dir das ein 
oder andere erklärt, wenn es um dein Auto geht, oder? ;)

Achim M. schrieb:
> Wenn du das LDF hast, geht's einfach.
> Könnte man in dem Fall bestimmt auch reverse engineeren.
-LDF?
>  Vermutlich ist für R G B jeweils ein Byte in einem der LIN-Frames
> vorgesehen, das dann jeweils proportional zur Intensität der Grundfarben
> ist. Also einfach PWM draus machen oder der WS1812-Library übergeben.
-WS2812 meinst du, oder?
> 256³ = 16777216 if-statements kannst du vergessen. Und was, wenn das
> noch zwischendurch mit der im Fahrzeugmenü einstellbaren Helligkeit der
> Ambientebeleuchtung verrechnet wird oder von Abblendlicht an/aus
> abhängig ist, werden dir deine 3 exakt definierten Lieblingsfarben nicht
> ausreichen.
-Dachte ich mir, deswegen ja direkt die Frage der Algorythmus oder 
vergleichbarem?

Frank K. schrieb:
> Dann wirst Du den passenden LIN-Standard brauchen. Weißt Du, ob Dein
> Fahrzeug LIN 1.3 oder LIN 2.x benutzt? Danach richtet sich auch z.B. die
> Prüfsummenberechnung.

Nein, weiß ich leider nicht. Gibts Möglichkeiten das zu erkennen? Kann 
ein entsprechendes Analysetool das, anhand von bestimmten Datensätzen 
die vom Master kommen, erkennen?

Frank K. schrieb:
> Wie das genau geht, liest Du am besten irgendwo nach.

Das werde ich machen!

Harald A. schrieb:
> Wenn ich das richtig verstanden habe kannst Du per VCDS
> Farben gezielt auslösen.

Das ist korrekt.

Harald A. schrieb:
> Fertige Bausteine, die
> direkt auf das Protokoll gemünzt sind, halte ich für unwahrscheinlich

Gibt es zumindest in der Theorie. Ich könnte zu Seat gehen, mir eine LED 
nachbestellen, die dann in Spanien fertig codiert zugeschickt wird. 
Kostenpunkt ca. 130€ für eine LED... Danke, Nein!

Harald A. schrieb:
> dass Du viel Geld
> ausgeben möchtest

Zumindest vorerst nicht. Wenn es auf halber Strecke scheitert, dann soll 
natürlich nicht zu viel Geld für so eine Spielerei verbrannt sein. Werde 
mir aber dein Tool von ALI mal angucken! Danke dafür!!!

Achim M. schrieb:
> TX braucht er nicht, weil er nur mitlauschen möchte. Der antwortende
> LIN-Slave wird wohl am Bus belassen.

So siehts aus.

Achim M. schrieb:
> Also sind die Farben nicht im
> EEPROM des LIN-Slave.

Wie interpretiert der Slave dann die Empfangenen Daten?

Achim M. schrieb:
> Vielleicht noch als Anmerkung, LIN ist nicht standardisiert in Bezug auf
> die Dateninhalte

Das ist klar. Ist ja auch kein Licht-Bus :P

Achim M. schrieb:
> Mitschnitte dessen Kommunikation bei einfachen Kombinationen der
> Grundfarben (z.B. nur rot, nur grün, nur blau, gelb, magenta, türkis,
> weiß und schwarz/aus) helfen beim reverse engineeren.

Würde ich mir zutrauen und werde mir, wie geschrieben, das Tool vom ALI 
mal angucken und bestellen.


Ist sonst jemand aus der Region Hannover hier unterwegs, der Zeit und 
Lust hätte, da etwas zu unterstützen? Ich bin da echt gewillt zu lernen!

von Max W. (max_w711)


Lesenswert?

Alles klar. Aktuell noch etwas Magie für mich, aber ich werde mir das 
Protokoll mal weiter verinnerlichen. Mir ist zumindest schon mal klar, 
was du meinst

von Harald A. (embedded)


Lesenswert?

Der Link auf die Software auf Baidu funktioniert übrigens. Da sind auch 
einige PDF als Installationsanleitung. Zwar alles auf Chinesisch aber 
durchaus nachvollziehbar. Ansonsten gibt es ja auch mittlerweile 
genügend Übersetzungsmöglichkeiten, Google Translator per Kamera auf dem 
Handy, Google Translate oder ChatGPT.

von Rainer W. (rawi)


Lesenswert?

Frank K. schrieb:
> Zum ersten brauchst Du einen LIN-Transceiver, der aus dem Bus-Signal TX
> und RX für die uC macht.

Es gibt auch SoCs, die das LIN-Interface gleich zusammen mit einem 
ARM-Core auf dem Chip haben, so wie die Autoindustrie sie nutzt.

von Harald A. (embedded)


Lesenswert?

Rainer W. schrieb:
> Es gibt auch SoCs, die das LIN-Interface gleich zusammen mit einem
> ARM-Core auf dem Chip haben, so wie die Autoindustrie sie nutzt.

Na ja, nach seinem Eingangspost bzgl. geringer Kenntnisse (Arduino geht 
aber) würde ich mal nicht unbedingt einen solchen SoC empfehlen.

von Max W. (max_w711)


Lesenswert?

Harald A. schrieb:
> Rainer W. schrieb:
>> Es gibt auch SoCs, die das LIN-Interface gleich zusammen mit einem
>> ARM-Core auf dem Chip haben, so wie die Autoindustrie sie nutzt.
>
> Na ja, nach seinem Eingangspost bzgl. geringer Kenntnisse (Arduino geht
> aber) würde ich mal nicht unbedingt einen solchen SoC empfehlen.

Weil deutlich komplizierter zu programmieren?

Ich habe mir jetzt mal die beiden LIN-Datenblätter vorgenommen, damit 
ich besser verstehe, wie das ganze aufgebaut ist.

Für mich mal als Verständnisfrage:
Es gibt ja Bausteine wie einen Elmos E521.30, um den es sich sehr 
wahrscheinlich auch im Fahrzeug bei mir handelt.
Zu bekommen bei bekannten Elektronikvertrieben ab minimum 3000 Stück. 
Kommt man an sowas auch in geringerer Stückzahl ran? Und ist es 
Sinnvoll, diesen Baustein für solch ein Projekt zu nutzen?

Ich lese dann mal weiter im Datenblatt…

: Bearbeitet durch User
von Harald A. (embedded)


Lesenswert?

Max W. schrieb:
> Weil deutlich komplizierter zu programmieren?

Da steht mal ganz allgemein "16 bit Microcontroller" - welcher das genau 
ist geht nicht hervor. Du kommst bei ELMOS als Privatkunde an keinerlei 
Infos (detaillierte Datenblätter, Programmierwerkzeuge etc.). Diesen Weg 
kannst Du komplett vergessen.

> Kommt man an sowas auch in geringerer Stückzahl ran? Und ist es
> Sinnvoll, diesen Baustein für solch ein Projekt zu nutzen?

Kaum.

Bleibe als Privatperson bei einem Controller, den Du kennst und nehme 
dann einfach APA102-LEDs, die gibt es in allen Größen und sind sehr 
einfach anzusteuern. Bei den allseits beliebten WS2812 musst Du schon 
wieder Klimmzüge beim Timing machen, wenn Du gleichzeitig LIN empfangen 
willst und ein ungestörtes Protokoll Richtung LED ausgeben musst - ist 
grundsätzlich möglich, würde ich mit deinen von Dir beschriebenen 
Vorkenntnissen lassen.

von Soul E. (soul_eye)


Lesenswert?

Max W. schrieb:
> Bei Fahrzeugen mit Ambientebeleuchtung ist in den meisten Fällen die LED
> der LIN-Slave, welcher einen bestimmten Befehl in eine RGB-Farbe
> umwandelt.

Die meisten Einkoppelelemente (z.B. Hella oder Dräxlmaier) haben vier 
Anschlüsse. KL15, Masse, LIN rein und LIN raus. Die Module sind in Reihe 
geschaltet und der LIN wird durchgeschleift.

Nach dem Einschalten erfolgt eine Slave Node-Erkennung. Die LEDs 
reagieren erstmal alle auf die gleichen IDs und die Verbindung zum LIN 
out ist getrennt. So empfängt nur das erste Modul. Dem teilt man seine 
neue ID mit und aktiviert es, damit leitet es den LIN durch an das 
folgende Modul. Das wird ebenfalls konfiguriert, usw.

> Es müsste doch also möglich sein, diesen Befehl separat zu lesen und mit
> entsprechendem IC weitere blinde Slaves (also Fahrzeug kennt diese
> nicht, sie lesen aber den Befehl einfach mit) zu programmieren, damit
> man beliebig viele weitere LED's ansteuern kann.

Weitere Slaves müssten passend konfiguriert werden. Du brauchst also ein 
aktives Gateway, das erst Deine Teilnehmer konfiguriert, dann den 
offiziellen LIN beobachtet und die Daten von dort zu Deinen Modulen 
sendet.


> Es können in diesem Fahrzeug maximal 10 Farben hinterlegt werden, die
> per RGB-Wert codiert werden (VCDS, VW-Plattform). Ich kann also zwischen
> 0 und 255 für Rot, Blau und Grün angeben, der Master wandelt es in LIN
> um und die LED dann logisch wieder in RGB zurück.

Das EKE bekommt Farbnummer (Palette, nicht RGB) und Helligkeit. Es kann 
die Werte direkt übernehmen, oder in einer vorgegebenen Zeit von der 
alten Farbe auf die neue überblenden.

Mach 100 Ohm in die LIN-Leitung und häng jeweils einen Tastkopf des 
Oszis davor und dahinter. So siehst Du, welche Bits vom Master kommen 
und welche vom Slave.

von Harald A. (embedded)


Lesenswert?

Soul E. schrieb:
> Weitere Slaves müssten passend konfiguriert werden. Du brauchst also ein
> aktives Gateway, das erst Deine Teilnehmer konfiguriert, dann den
> offiziellen LIN beobachtet und die Daten von dort zu Deinen Modulen
> sendet.

Wenn er nur die gleiche Farbe an eine andere Stelle übertragen möchte 
kann er eine Botschaft parallel abhören und verwerten. Einbindung als 
neuer Teilnehmer ist doch völlig überzogen.

von Soul E. (soul_eye)


Lesenswert?

Harald A. schrieb:
> Wenn er nur die gleiche Farbe an eine andere Stelle übertragen möchte
> kann er eine Botschaft parallel abhören und verwerten. Einbindung als
> neuer Teilnehmer ist doch völlig überzogen.

Einen zweiten Strang parallel klemmen könnte klappen, wenn die 
Statusbotschaften einigermaßen gleich sind. Es antworten dann ja immer 
zwei Slaves, einer aus jeder Kette.

Eventuell könnte man den zweiten Strang mit einer Diode im LIN auf 
Read-only stellen. Die Diode so einbauen, dass der dominante Pegel (low) 
vom Master zum Slave kann, aber nicht umgekehrt. Dann sieht der Master 
nur die Statusbits von den original verbauten EKE.

von Paul B. (paule201)


Angehängte Dateien:

Lesenswert?

https://www.amazon.de/gp/product/B0CFFGS5XF

Kaufen, Software installieren, Masse und LIN anklemmen und lauschen. 
Reengineering. Wenn du das Protokoll verstanden hast, dann nimmst du dir 
einen STM32F103 (BluePill) + LIN Interface Chip (MCP2025 mit 3.3V an 
Board), stellst den UART des STM auf LIN ein und bist schon zu 50% am 
Ziel.

Sieht dann so wie im Anhang aus, dass ist ein Mitschnitt von einer 
Webasto Thermo TopC, die nutzen zwar kein "genormtes LIN", aber das 
Prinzip ist fast gleich.

von Harald A. (embedded)


Lesenswert?

Soul E. schrieb:
> Eventuell könnte man den zweiten Strang mit einer Diode im LIN auf
> Read-only stellen.

Warum möchtest Du eine Diode einsetzen? Mir wäre es in diesem Fall 
vollkommen egal, ob der Master oder ein Teilnehmer die Nachricht auf den 
Bus bringt. Den LIN-Transceiver (falls man den überhaupt verwendet) nur 
zum Lesen der Nachrichten verwenden, TX vollständig deaktivieren. Jetzt 
auf den Break, den Sync und die entsprechende ID warten und die Bytes 
der Nachricht auswerten. Er muss ja nicht einmal die Prüfsumme 
auswerten, denn hier wird kein wichtiges Bauteil gesteuert. Wenn es 
wirklich einmal für den Bruchteil einer Sekunnde aufgrund einer falschen 
Nachricht eine andere Farbe gibt (sowieso eher unwahrscheinlich) ist das 
kein Weltuntergang.

Du scheinst dich ja auszukennen, da Du Hersteller benennst und Palette 
anstelle RGB in Spiel bringst. Weißt Du, wie die Farbinfo aufgebaut ist?

: Bearbeitet durch User
von Soul E. (soul_eye)


Lesenswert?

Harald A. schrieb:
> Warum möchtest Du eine Diode einsetzen? Mir wäre es in diesem Fall
> vollkommen egal, ob der Master oder ein Teilnehmer die Nachricht auf den
> Bus bringt.

Dir schon, aber dem Master vielleicht nicht. Ich weiss nicht, ob das BCM 
die Statusworte der EKE liest und was es damit anstellt. Wenn da nun ein 
zweiter Strang danebenhängt, dann kommt bei unterschiedlichen Inhalten 
Datenmüll an. Wenn man dem Fremd-Strang das Senden verbietet, dann nimmt 
er die Konfigurationsdaten vom Master an, stört aber die Statusabfragen 
nicht.

Bzgl Palettendefinition: ich weiss nicht, ob da jeder OEM was eigenes 
bekommt oder ob die Hersteller da mehr oder weniger Katalogteile 
verkaufen. Theoretisch könnte man über den LIN auch RGB oder YUV 
schicken. Umrechnen muss das Ding sowieso, denn da ist eine 
Temperaturkompensation und eine Weisspunkt-Kalibrierung drin. Sonst 
könnte man ja auch billige WS8211 nehmen, da sieht im Gurt jeder anders 
aus.

von Harald A. (embedded)


Lesenswert?

Ich denke wir reden letztlich über das Gleiche. Um eben Datenmüll zu 
verhindern sollte das zu bauende Gerät wie ein Analysetool nur auf dem 
Bus lauschen und keinem einzigen Bit ein Haar krümmen. Kann sein, dass 
es nicht perfekt wird (keine Statusrückmeldung, Weißabgleich, 
Temperaturkompensation etc.), aber darauf kommt es dem TE vermutlich 
garnicht an.

: Bearbeitet durch User
von Max W. (max_w711)


Lesenswert?

Ich danke euch sehr für eure Gedankenanstöße!

Ich werde mir jetzt den Logic Analyzer bestellen und dann mal Stück für 
Stück weiter schauen. Es waren bis hier auf jeden Fall sehr viele sehr 
kompetente und hilfreiche Antworten dabei und das ist wirklich sehr 
löblich und echt nicht selbstverständlich. Freut mich!

Wenn ich wieder Hilfe brauche, würde ich dann gerne wieder auf euch 
zurück kommen. Ich denke in den nächsten 14 Tagen wird aber Funkstille 
sein, denn die Zeit ist momentan doch sehr eingeschränkt.

Liebe Grüße

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.