Hallo liebe Mikrocontroller-Community, ich möchte gerne auf den Lin-Bus einer BMW R1000 schreiben. Dazu habe ich mal einige Signale des Buses ausgelesen. D1-D2 sind dabei die Daten des Lenkerschalters. D4 ist ein Counter der von 48-62 zählt und dann wieder von vorne beginnt. D7 ist eine Art Checksumme. Nun zu meinen Fragen and die Gemeinde: Wie muss ich die Checksumme bilden (CRC)? Wie finde ich das Genertorpolynom heraus? Hab leider noch nicht so viel gemacht mit Checksummen vllt. könnt ihr mir da ja weiterhelfen. Schonmal Danke Alle Daten sind Dezimal D0 D1 D2 D3 D4 D5 D6 D7 255 0 0 252 48 0 31 114 255 0 0 252 49 0 31 253 255 0 0 252 50 0 31 113 255 0 0 252 51 0 31 254 255 0 0 252 52 0 31 116 255 0 0 252 53 0 31 251 255 0 0 252 54 0 31 119 255 0 0 252 55 0 31 248 255 0 0 252 56 0 31 126 255 0 0 252 57 0 31 241 255 0 0 252 58 0 31 125 255 0 0 252 58 0 31 125 255 0 0 252 59 0 31 242 255 0 0 252 60 0 31 120 255 0 0 252 61 0 31 247 255 0 0 252 62 0 31 123
:
Verschoben durch Admin
Florian Bonetsmüller schrieb: > Wie muss ich die Checksumme bilden (CRC)? > Wie finde ich das Genertorpolynom heraus? Ich stelle mir das etwas schwierig vor, du weist ja nicht zu 100% ob es eine CRC Checksum ist, könnte auch eine andere Hashfunktion sein. Die meisten Checksummen für Pakete in einem Bus sind zwar CRC aber das trifft nicht auf alle zu, besonders wenn es um Firmeneigene Protokolle geht die man Reverse Enginieren muss da es für die keine Firmenexterne Dokumentation gibt. Es kann da durchaus vorkommen dass da bewusst nicht CRC gewählt wird damit Drittanbieter nicht einfach was nachbauen können. Sollte es dennoch CRC sein, kenne ich keine Möglichkeit ausser Bruteforce um auf das Generatorpolynom zu schließen. CRC beruht ja auf Polynomsdivision besser gesagt ist die CRC der Rest einer so einen Polynomsdivision, jetzt musst du aus dem Rest auf den Dividenden schließen, was nicht wirklich möglich ist. Wenn mans mit Reellen Zahlen macht sieht man das auch 5 mod 2 = 1 Wenn ich jetzt nur 5 und 1 als Information habe, kann ich nicht sagen ob ich modulo 2 oder modulo 4 gerechnet habe. Beide Methoden liefern hier das richtige Ergebnis wenn ich aber eine andere Zahl zB 6 verwende ist das nicht so. 6 mod 2 = 0 6 mod 4 = 2 Ich kann mir zwar vorstellen dass ich aus solchen Versuchen mit mehreren Werten auf den Dividenen schließen kann, aber wie das geht kann ich dir hier auch nicht beantworten. In meinem Beispiel könnte man jetzt mutmaßen 4 ist eine Potenz von 2 und der Rest von 2 deutet auf den Dividenden 2, aber das ist jetzt auch nur bei dem Einfachen Beispiel so.
> D4 ist ein Counter der von 48-62 zählt und dann > wieder von vorne beginnt. Wandel mal in hex um. Nur das untere Nibbel ist der Zähler, das obere enthält auch Daten.
Beim LIN ist die Checksum standardisiert.
...
There are two checksum concepts: the classic checksum and the enhanced
checksum. With the classic checksum, only the useful data is protected.
With the enhanced checksum, the useful data and the PID are protected.
The enhanced checksum is used for identifiers 0 to 59, effective with
Version 2.0 of the protocol. To retain downward compatibility,
diagnostic frames are always protected with the classic checksum.
The checksums are computed according to the following formula:
Checksum = INV (data byte 1 ⊕ data byte 2 ⊕ ... ⊕ data byte 8)
To form the checksum, the individual data bytes are added by modulo-256
arithmetic. This involves adding overrun bits to the specific
intermediate result. Finally, the overall result is inverted, and the
Slave Task transmits it as the checksum. The receiver computes the
checksum for the received data bytes by the same algorithm, except for
the inversion. The receiver detects a transmission error if the sum of
the data bytes and the arriving checksum is not 0xFF.
Quelle:
http://elearning.vector.com/index.php?&wbt_ls_seite_id=989105&root=378422&seite=vl_lin_introduction_en
Lies da (und auf den folgenden Seiten) mal nach.
Gruß aus Beijing
Elux
:
Bearbeitet durch User
>Beim LIN ist die Checksum standardisiert.
Jaja, nur leider geht es hier nicht um die "CRC checksum".
Sondern um 8 Datenbytes (D0 bis D7) wo mit eigendeiner
Berechnungsvorschrift vereinbart ist, in D7 nochmals eine Prüfsumme zu
übertragen.
Ein im automotive Bereich vorkommender doppelt gemoppelter Unsinn, aber
leider üblich...
Gruss
Ja genau das stimmt hinter D7 befindet sich die eigentliche Lin Checksumme Daten stehen wirklich nur in D1-D2.
So hier hab ich noch mal ein paar LIN-Signale diesmal mit MRF und SRF und in Hex. Der MRF besteht aus 4 Byte und der SRF besteht aus 8 Byte. D2 enthält die Daten "0x40" und das beudeutet ABS-Schalter ein. D7 ist wieder die komische Checksumme. Checksumm ist die Prüfsumme des LIN-Buses. ID D0 D1 D2 D3 D4 D5 D6 D7 Checksumm 0x14 0xff 0x00 0x40 0xfc 0x30 0x00 0x1f 0xed 0x71 0x10 0xff 0xff 0xff 0xff 0xaf 0x14 0xff 0x00 0x40 0xfc 0x31 0x00 0x1f 0x62 0xfb 0x10 0xff 0xff 0xff 0xff 0xaf 0x14 0xff 0x00 0x40 0xfc 0x32 0x00 0x1f 0xee 0x6e 0x10 0xff 0xff 0xff 0xff 0xaf 0x14 0xff 0x00 0x40 0xfc 0x33 0x00 0x1f 0x61 0xfa 0x10 0xff 0xff 0xff 0xff 0xaf 0x14 0xff 0x00 0x40 0xfc 0x34 0x00 0x1f 0xeb 0x6f 0x10 0xff 0xff 0xff 0xff 0xaf 0x14 0xff 0x00 0x40 0xfc 0x35 0x00 0x1f 0x64 0xf5
Angehängte Dateien:
-
Checksumme.jpg
320 KB
Hier nochmal ein Bild der Checksumme von mehreren Frames. Sieht irgendwie sehr symmetrisch aus. Aber ich blicke immer noch nicht durch wie es generiert wird?
Erich schrieb: > Ein im automotive Bereich vorkommender doppelt gemoppelter Unsinn, aber > leider üblich... Unsinn ist das nicht weil man damit absichert dass die Applikation noch läuft und nicht nur der Com-Stack weiter labert.
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.