Hallo zusammen,
ich hoffe mir kann jemand bei meinem Projekt etwas Behilflich sein, im Netz ist über den LIN Bus im VW nicht gerade viel zu finden.
Es soll ein Golf 7 R Lenkrad werden, das in meinem T4 eingepflanzt wird
Ein Mikrokontroller soll die Kommunikation zum MFL herstellen und dann über Ausgänge und Schnittstellen diverse Dinge im Bus ansteuern.
So zumindest mein Plan, Mechanisch sollte soweit alles Möglich sein, die Kommunikation mittels LIN zum MFL wird zumindest für mich wohl noch eine zu knackende Nuss werden.
Nun da ich kein Experte in Sachen CAN & Co bin, mich die ganze Thematik aber schon lange brennend interessiert
und der Wunsch etwas Eigenes zu bauen, was dann in dem ganzen "Chaos" auch noch Funktioniert...
will ich meinen Ehrgeiz durchsetzen und bin Überzeugt mein Projekt auch wenn es schwierig wird, schon irgendwie hinzubekommen.
Hab mir ein paar Unterlagen zum LIN Bussytem besorgt und mich in letzter Zeit ein wenig eingelesen.
Nun, der LIN Bus ist ein 1-Draht BUS, alle Teilnehmer (Knoten) werden mit der Boardspannung versorgt und hängen am LIN, es gibt nur einen Master und bis zu 16 Slaves.
Slaves dürfen nicht selbsständig senden, sondern nur auf Anfrage vom Master eine Antwort geben, die wiederum aber von allen Slaves mitgelesen werden darf.
Somit kommt es normalerweise auch zu keinen Kollisionen am Bus, da der Master die ganze Kommunikation steuert und dadurch auch von vornherein weiß was ihm bei seinen Abfragen erwarten wird.
Fehlerkontrolle bzw. Analyse ist dem Master unterlegen, zur Sicherheit eine Checksumme.
Also, hab ich mir von Microchip den "LIN Serial Analyzer" gekauft, ein kleines einfaches und auch günstiges Gerät um auf dem LIN Bus per PC (USB) und einer einfachen Software die Kommunikation für Testzwecke zu ermöglichen.
Genau das richtige für mein Vorhaben, denn wenn damit die Kommunikation mal läuft, dann kann ich mich drum kümmern wie ich das mit irgend einem Kontroller verwirklichen kann.
Bis dahin wahrscheinlich ein wertvolles Tool und später dann zur Kontrolle ob auch alles richtig läuft.
Der Master müßte laut meinen Recherchen eigentlich nur eine ID senden, natürlich die richtige auf die der Slave reagiert und dann die passende Antwort gibt.
Wie ich das verstanden habe, läuft die Kommunikation am LIN so ab, das der Master zuerst ein "Sync Break" am Bus erzeugt, damit alle Slaves wissen jetzt kommt was.
Darauf sendet der Master einen Sync 0x55 damit sich die Slaves an das richtige Timing vom Master anpassen können.
Zu guter letzt folgt dem String noch das PID (Protect-ID) und dar für den Normal Fall einen Wert von 0x00 bis 0x3b (0x3F) haben, also 64 Adressen.
Das genannte PID (1Byte) beinhaltet also in den niederwertigen Bits 1-6 die ID und in den hoherwertigen Bits 7+8 die Paritätsprüfung
Wenn die richtige ID auf den Bus gelangt und ein Slave sich angesprochen fühlt, füllt er den rest vom String mit bis zu 8 Bytes an Informationen auf und gibt somit die Antwort "Response" auf die Anfrage "Header" vom Master preis.
So,zumindest die Theorie und falls ich was falsch verstanden habe bitte korrigiert mich.
Fürs erste übernimmt nun schonmal mein LIN-Tool den "Sync Break", "Sync" und die Checksum Berechnung.
Nun müsste ich nur die richtigen ID´s ans Lenkrad senden um den aktuellen Status der Tasten zu erhalten.
Die richtige Geschwindigkeit für dieses Unterfangen, hab ich mit ein paar Tests herausgefunden und liegt bei 19.200 Baud.
Es gibt laut LIN Spezification auch 2.400 und 9.600, aber die 19.200 sind, so glaube ich zumindest aktueller Standart.
Also Lenkrad und LIN-Tool an 12V angeschlossen, LIN Verbindung zwischen den zwei Knoten hergestellt und schonmal gewundert wieso denn die Tastenbeleuchtung nicht angeht.
Naja wird wohl wahrscheinlich einem Befehl vom Master unterliegen, oder schläft der Slave etwa noch ?
Da ich überhaubt keine Infos zu den ID´s im Netz gefunden habe und wenn dann nur welche die dann weiter auf dem CAN Bus laufen, fange ich also bei NUll an.
Erstmal alle 64 ID´s durch probiert und siehe da auf 3 Stück habe ich eine Response erhalten.
Es handelt sich um die 0x0F, 0x0E und 0x3A.
Am Bus bekam ich aber andere ID´s vorangeschrieben, hab da wohl übersehen das es zwei Varianten für die Protectet-ID zusammenstellung gibt.
Laut Unterlagen wird ab LIN 2.0 eine "Enhanced Checksum" berechnet, wo die 2 Parität Bits mit dazugerechnet werden. Bei der "Classic Checksum" ist dies nicht der Fall.
Also wird aus 0x0F > 0xCF, aus 0x0E > 0x8E und aus 0x3A > 0xBA
Nochwas, der Slave scheint wirklich ein wenig zu schalfen, denn wenn ich ein PID sende dann bekomme ich keine Response vom Slave, erst beim zweiten Versuch Meldet er sich dann.
Weitere Abfragen kommen dann immer sofort.
Habe herausgefunden, daß wenn ca. 4sec keine Kommunikation mehr läuft der Slave wahrscheinlich in einen anderen Modus verfällt, wahrscheinlich in den Slave ?
Hinterher geht immer die erste Abfrage ins leere, bewirkt aber das der Slave sich aufweckt und dann gleich für weitere Anfragen zur Verfügung steht, also will er ständig Unterhalten werden
Soweit sogut, mit den Response Daten vom Slave bin ich dann aber so gar nicht Schlau geworden...
Ich wills mal erklären:
PID 0xBA
========
Antwort = 2 Byte + 1 Byte Checksum
FE FE immer dann wenn die Kommunikation für länger als 4 sec. nicht aktiv war
FF FE auf alle weiteren Anfragen. Scheint im 1. Byte also eine Info Vorhanden zu sein, das die Kommunikation vorher nicht aktiv war. Das 2. Byte konnte ich nicht zuweisen.
Weiters bekomme ich noch ständig die Meldung "Bus Timeout Error", da scheint etwas nicht ganz zu passen ??
PID 0x8E
========
Antwort = 8 Byte + 1 Byte Checksum
80 00 00 00 40 00 00 00
81 00 00 00 40 00 00 00
82 00 00 00 40 00 00 00
83 00 00 00 40 00 00 00
84 00 00 00 40 00 00 00
85 00 00 00 40 00 00 00
86 00 00 00 40 00 00 00
87 00 00 00 40 00 00 00
88 00 00 00 40 00 00 00
89 00 00 00 40 00 00 00
8A 00 00 00 40 00 00 00
8B 00 00 00 40 00 00 00
8C 00 00 00 40 00 00 00
8D 00 00 00 40 00 00 00
8E 00 00 00 40 00 00 00
8F 00 00 00 40 00 00 00
Bei jeder Abfrage vom Master kommt ein Response mit den 8 Byte, startet mit 0x80 (1.Byte) und macht 16 Durchgänge bis es bei 0x8F angelangt ist um dann wieder beim ersten mit 0x80 zu beginnen.
Fakt ist, wenn ich die PID 0x8E dauernd abfrage, dann laufen diese Response Frames mit ständig selben Inhalt auf den Bus, egal ob ich eine Taste am MFL drücke oder nicht ??
PID 0xCF
========
Antwort = 8 Byte + 1 Byte Checksum
86 40 80 2A 00 00 00 00
F4 41 80 2A 00 00 00 00
50 42 80 2A 00 00 00 00
08 43 80 2A 00 00 00 00
88 44 80 2A 00 00 00 00
2D 45 80 2A 00 00 00 00
34 46 80 2A 00 00 00 00
11 47 80 2A 00 00 00 00
C4 48 80 2A 00 00 00 00
CC 49 80 2A 00 00 00 00
DC 4A 80 2A 00 00 00 00
79 4B 80 2A 00 00 00 00
3C 4C 80 2A 00 00 00 00
68 4D 80 2A 00 00 00 00
27 4E 80 2A 00 00 00 00
0D 4F 80 2A 00 00 00 00
Auch hier wieder 16 Durchgänge, diesmal ist es das 2. Byte was bei 0x40 startet und bis 0x4F durchläuft, natürlich auf jede Anfrage vom Master nur ein Frame.
Das 1. Byte wechselt zwar etwas wirr umher, aber wiederhohlt sich auch nach 16 Durchgänge wieder vorn vorne.
Der Rest bleibt starr, wiederum keine Änderung bei irgend einem Byte wenn ich eine Taste am Lenkrad drücke ??
So nun steck ich fest mit meinem ganzen Aufbau, entweder mache ich was Grundlegendes falsch, oder mir fehlen noch wichtige Infos um den Slave etwas mehr Leben einzuhauchen.
Auf jeden Fall bekomme ich zwar Antworten vom MFL, kann aber nichts damit anfangen.
Irgendwas schläft da noch am Bus, vieleicht auch ich selber
Wie geht´s jetzt wohl weiter... ?
Gruß
Martin
ich hoffe mir kann jemand bei meinem Projekt etwas Behilflich sein, im Netz ist über den LIN Bus im VW nicht gerade viel zu finden.
Es soll ein Golf 7 R Lenkrad werden, das in meinem T4 eingepflanzt wird
Ein Mikrokontroller soll die Kommunikation zum MFL herstellen und dann über Ausgänge und Schnittstellen diverse Dinge im Bus ansteuern.
So zumindest mein Plan, Mechanisch sollte soweit alles Möglich sein, die Kommunikation mittels LIN zum MFL wird zumindest für mich wohl noch eine zu knackende Nuss werden.
Nun da ich kein Experte in Sachen CAN & Co bin, mich die ganze Thematik aber schon lange brennend interessiert
und der Wunsch etwas Eigenes zu bauen, was dann in dem ganzen "Chaos" auch noch Funktioniert...
will ich meinen Ehrgeiz durchsetzen und bin Überzeugt mein Projekt auch wenn es schwierig wird, schon irgendwie hinzubekommen.
Hab mir ein paar Unterlagen zum LIN Bussytem besorgt und mich in letzter Zeit ein wenig eingelesen.
Nun, der LIN Bus ist ein 1-Draht BUS, alle Teilnehmer (Knoten) werden mit der Boardspannung versorgt und hängen am LIN, es gibt nur einen Master und bis zu 16 Slaves.
Slaves dürfen nicht selbsständig senden, sondern nur auf Anfrage vom Master eine Antwort geben, die wiederum aber von allen Slaves mitgelesen werden darf.
Somit kommt es normalerweise auch zu keinen Kollisionen am Bus, da der Master die ganze Kommunikation steuert und dadurch auch von vornherein weiß was ihm bei seinen Abfragen erwarten wird.
Fehlerkontrolle bzw. Analyse ist dem Master unterlegen, zur Sicherheit eine Checksumme.
Also, hab ich mir von Microchip den "LIN Serial Analyzer" gekauft, ein kleines einfaches und auch günstiges Gerät um auf dem LIN Bus per PC (USB) und einer einfachen Software die Kommunikation für Testzwecke zu ermöglichen.
Genau das richtige für mein Vorhaben, denn wenn damit die Kommunikation mal läuft, dann kann ich mich drum kümmern wie ich das mit irgend einem Kontroller verwirklichen kann.
Bis dahin wahrscheinlich ein wertvolles Tool und später dann zur Kontrolle ob auch alles richtig läuft.
Der Master müßte laut meinen Recherchen eigentlich nur eine ID senden, natürlich die richtige auf die der Slave reagiert und dann die passende Antwort gibt.
Wie ich das verstanden habe, läuft die Kommunikation am LIN so ab, das der Master zuerst ein "Sync Break" am Bus erzeugt, damit alle Slaves wissen jetzt kommt was.
Darauf sendet der Master einen Sync 0x55 damit sich die Slaves an das richtige Timing vom Master anpassen können.
Zu guter letzt folgt dem String noch das PID (Protect-ID) und dar für den Normal Fall einen Wert von 0x00 bis 0x3b (0x3F) haben, also 64 Adressen.
Das genannte PID (1Byte) beinhaltet also in den niederwertigen Bits 1-6 die ID und in den hoherwertigen Bits 7+8 die Paritätsprüfung
Wenn die richtige ID auf den Bus gelangt und ein Slave sich angesprochen fühlt, füllt er den rest vom String mit bis zu 8 Bytes an Informationen auf und gibt somit die Antwort "Response" auf die Anfrage "Header" vom Master preis.
So,zumindest die Theorie und falls ich was falsch verstanden habe bitte korrigiert mich.
Fürs erste übernimmt nun schonmal mein LIN-Tool den "Sync Break", "Sync" und die Checksum Berechnung.
Nun müsste ich nur die richtigen ID´s ans Lenkrad senden um den aktuellen Status der Tasten zu erhalten.
Die richtige Geschwindigkeit für dieses Unterfangen, hab ich mit ein paar Tests herausgefunden und liegt bei 19.200 Baud.
Es gibt laut LIN Spezification auch 2.400 und 9.600, aber die 19.200 sind, so glaube ich zumindest aktueller Standart.
Also Lenkrad und LIN-Tool an 12V angeschlossen, LIN Verbindung zwischen den zwei Knoten hergestellt und schonmal gewundert wieso denn die Tastenbeleuchtung nicht angeht.
Naja wird wohl wahrscheinlich einem Befehl vom Master unterliegen, oder schläft der Slave etwa noch ?
Da ich überhaubt keine Infos zu den ID´s im Netz gefunden habe und wenn dann nur welche die dann weiter auf dem CAN Bus laufen, fange ich also bei NUll an.
Erstmal alle 64 ID´s durch probiert und siehe da auf 3 Stück habe ich eine Response erhalten.
Es handelt sich um die 0x0F, 0x0E und 0x3A.
Am Bus bekam ich aber andere ID´s vorangeschrieben, hab da wohl übersehen das es zwei Varianten für die Protectet-ID zusammenstellung gibt.
Laut Unterlagen wird ab LIN 2.0 eine "Enhanced Checksum" berechnet, wo die 2 Parität Bits mit dazugerechnet werden. Bei der "Classic Checksum" ist dies nicht der Fall.
Also wird aus 0x0F > 0xCF, aus 0x0E > 0x8E und aus 0x3A > 0xBA
Nochwas, der Slave scheint wirklich ein wenig zu schalfen, denn wenn ich ein PID sende dann bekomme ich keine Response vom Slave, erst beim zweiten Versuch Meldet er sich dann.
Weitere Abfragen kommen dann immer sofort.
Habe herausgefunden, daß wenn ca. 4sec keine Kommunikation mehr läuft der Slave wahrscheinlich in einen anderen Modus verfällt, wahrscheinlich in den Slave ?
Hinterher geht immer die erste Abfrage ins leere, bewirkt aber das der Slave sich aufweckt und dann gleich für weitere Anfragen zur Verfügung steht, also will er ständig Unterhalten werden
Soweit sogut, mit den Response Daten vom Slave bin ich dann aber so gar nicht Schlau geworden...
Ich wills mal erklären:
PID 0xBA
========
Antwort = 2 Byte + 1 Byte Checksum
FE FE immer dann wenn die Kommunikation für länger als 4 sec. nicht aktiv war
FF FE auf alle weiteren Anfragen. Scheint im 1. Byte also eine Info Vorhanden zu sein, das die Kommunikation vorher nicht aktiv war. Das 2. Byte konnte ich nicht zuweisen.
Weiters bekomme ich noch ständig die Meldung "Bus Timeout Error", da scheint etwas nicht ganz zu passen ??
PID 0x8E
========
Antwort = 8 Byte + 1 Byte Checksum
80 00 00 00 40 00 00 00
81 00 00 00 40 00 00 00
82 00 00 00 40 00 00 00
83 00 00 00 40 00 00 00
84 00 00 00 40 00 00 00
85 00 00 00 40 00 00 00
86 00 00 00 40 00 00 00
87 00 00 00 40 00 00 00
88 00 00 00 40 00 00 00
89 00 00 00 40 00 00 00
8A 00 00 00 40 00 00 00
8B 00 00 00 40 00 00 00
8C 00 00 00 40 00 00 00
8D 00 00 00 40 00 00 00
8E 00 00 00 40 00 00 00
8F 00 00 00 40 00 00 00
Bei jeder Abfrage vom Master kommt ein Response mit den 8 Byte, startet mit 0x80 (1.Byte) und macht 16 Durchgänge bis es bei 0x8F angelangt ist um dann wieder beim ersten mit 0x80 zu beginnen.
Fakt ist, wenn ich die PID 0x8E dauernd abfrage, dann laufen diese Response Frames mit ständig selben Inhalt auf den Bus, egal ob ich eine Taste am MFL drücke oder nicht ??
PID 0xCF
========
Antwort = 8 Byte + 1 Byte Checksum
86 40 80 2A 00 00 00 00
F4 41 80 2A 00 00 00 00
50 42 80 2A 00 00 00 00
08 43 80 2A 00 00 00 00
88 44 80 2A 00 00 00 00
2D 45 80 2A 00 00 00 00
34 46 80 2A 00 00 00 00
11 47 80 2A 00 00 00 00
C4 48 80 2A 00 00 00 00
CC 49 80 2A 00 00 00 00
DC 4A 80 2A 00 00 00 00
79 4B 80 2A 00 00 00 00
3C 4C 80 2A 00 00 00 00
68 4D 80 2A 00 00 00 00
27 4E 80 2A 00 00 00 00
0D 4F 80 2A 00 00 00 00
Auch hier wieder 16 Durchgänge, diesmal ist es das 2. Byte was bei 0x40 startet und bis 0x4F durchläuft, natürlich auf jede Anfrage vom Master nur ein Frame.
Das 1. Byte wechselt zwar etwas wirr umher, aber wiederhohlt sich auch nach 16 Durchgänge wieder vorn vorne.
Der Rest bleibt starr, wiederum keine Änderung bei irgend einem Byte wenn ich eine Taste am Lenkrad drücke ??
So nun steck ich fest mit meinem ganzen Aufbau, entweder mache ich was Grundlegendes falsch, oder mir fehlen noch wichtige Infos um den Slave etwas mehr Leben einzuhauchen.
Auf jeden Fall bekomme ich zwar Antworten vom MFL, kann aber nichts damit anfangen.
Irgendwas schläft da noch am Bus, vieleicht auch ich selber
Wie geht´s jetzt wohl weiter... ?
Gruß
Martin