CRC-8 in Python

[Crashmichl]

Hallo,

ich bin zur Zeit dabei, eine Ansteuerung für die RN-Schrittmotor zu auf dem RPi in Python zu lösen.
Da mir beim Pollen auf dem Bus öfters fehlerhafte Werte reinschwirren, will ich die mit CRC verriegeln.
Stehe heute schon den ganzen Tag auf dem Schlauch:
Ich habe im ganzen 6 Bytes, über die ich den CRC laufen lassen muss.
Ein Beispiel habe ich mir in Bascom ausrechnen lassen:


Byte1
Byte2
Byte3
Byte4
Byte5
Byte6
CRC


55
1
200
0
0
0
128


Beim spielen mit anderen Tools, um ein Gefühl dafür zu bekommen (z.B. http://www.smbus.org/faq/crc8Applet.htm) und habe keine Ahnung, wie ich das genau machen soll, da ich dort nicht auf das gleice Ergebnis gekommen bin.
Wie muss ich mir das vorstellen?
Werden die Bytes hintereinander aufsummieren (z.B. 055001200000000000) und dann die Polynomdivision durchführen?
Vielleicht kann mir da mal jemand einen Schupser in die richtige Richtung geben.

Gruß

Michael

[Klebwax]

ich bin zur Zeit dabei, eine Ansteuerung für die RN-Schrittmotor zu auf dem RPi in Python zu lösen.
Da mir beim Pollen auf dem Bus öfters fehlerhafte Werte reinschwirren, will ich die mit CRC verriegeln.

Das ist der ganz falsche Ansatz. Eine Prüfsumme, ein CRC macht die Übertragung nicht besser. Es macht die Datentelegramme nur länger, womit die Fehler dann häufiger auftreten. Irgendwann bekommst du dann überhaupt keine Daten mehr übertragen. Du hast nur noch fehlerhafte Blöcke.

Such den wirklichen Fehler und beseitige ihn. Um dann singuläre Ereignisse, die alle paar Tage oder seltener mal auftreten auszuschließen, kommt die Prüfsumme dran.

MfG Klebwax

[Crashmichl]

Servus,

der Aufbau ist momentan auf einem Steckboard. Daher vermute ich die Fehler. Allerdings kann ich mit dem CRC-Check die Gültigkeit des Telegramms prüfen und entsprechend das Telegramm verwerfen. Momentan kommen auf ca. 100 I2C Telegramme zwischen 1 und 3 fehlerhafte rein. Nur wenn ich momentan noch am schreiben vom Core bin, dann will ich den CRC gleich mit einbauen und später nicht mehr anfassen müssen.

Gruß

Michael

[Klebwax]

Servus,

der Aufbau ist momentan auf einem Steckboard. Daher vermute ich die Fehler. Allerdings kann ich mit dem CRC-Check die Gültigkeit des Telegramms prüfen und entsprechend das Telegramm verwerfen. Momentan kommen auf ca. 100 I2C Telegramme zwischen 1 und 3 fehlerhafte rein. Nur wenn ich momentan noch am schreiben vom Core bin, dann will ich den CRC gleich mit einbauen und später nicht mehr anfassen müssen.

I2C ist unkritisch, wenn man es richtig macht. Die Übertragung ist erstens langsam und zweites synchron. Selbst bei einem Steckbrettaufbau dürften Fehler im Bereich 1 auf 1 Million oder weniger auftreten. Deswegen wird bei I2C typisch kein CRC gemacht. Die Bausteine, die ich kenne, die Sensoren auf dem SMBus unterstützen das nicht. Wenn du den Bus mal mit Standardteilen nutzen willst, mußt du es sowieso abschalten, also spar dir den Aufwand und such den wirklichen Fehler.

MfG Klebwax

[Crashmichl]

Servus,

danke für die Antwort. Das der I2C eigentlich recht stabil läuft ist mir bekannt. Die RN-Schrittmotor kann z.B. CRC und diese verwende ich und will selbst auf 1 Milliarde Teegramme den Fehler verwerfen können. Und eigentlich bin ich über die Übertragungsfehler froh, da ich wieder eine Fehlerquelle entdeckt habe, die ich ausschließen muss. Daher stelle ich aber nicht die Frage, wie ich den Bus sicher bekomme, sondern wie ich den CRC am besten implementiert bekomme und hier gerade auf dem Schlauch stehe. So gesehen muss ich leider sagen, bringen mich deine Antworten nicht weiter.

Gruß

Michael

[Klebwax]

Daher stelle ich aber nicht die Frage, wie ich den Bus sicher bekomme ..
"sicher" ist die falsche Formulierung, bei deiner Fehlerrate ist er einfach kaputt
.. sondern wie ich den CRC am besten implementiert bekomme und hier gerade auf dem Schlauch stehe. So gesehen muss ich leider sagen, bringen mich deine Antworten nicht weiter.

Wohl war. Wo ich bisher mit CRC zu tun hatte, wurden die von der Hardware erzeugt und waren auch länger als CRC8. Ich hab also nie darüber nachgedacht, wie man CRC berechnet, sondern was man tut, wenn ein Datenpaket verloren geht.

Aber deine Idee, alle Bytes aufzusummieren kommt mir falsch vor. Wenn ich mich recht erinnere, wird für jedes Bit der CRC neu berechnet. Du verwendest ja Python, da gibts doch sicher was fertiges.

MfG Klebwax

[Pyro-Mike]

Google ist dein Freund: ;-)
http://www.python-forum.de/viewtopic.php?f=11&t=33031

[Crashmichl]

Servus,

@Klebwax: Das der I2C stabilisiert werden muss ist klar. Wie gesagt, ich sehe momentan die Möglichkeit, das ganze Abzufangen und bei einer späteren Schaltung hat dies den Vorteil, dass ich direkt Log-Einträge erzeugen kann und somit das ganze noch Auswerten kann.
@Pyro-Mike: Hab ich auch schon gefunden. Bringt mir aber ganz andere Ergebnisse :(

Die CRC-8 Funktion in Bascom hat ja als Poly 8C. Ich hab mir über Bascom für 6 Bytes den CRC berechnen lassen und komme auf anderen Seiten nicht auf den gleichen CRC.
Probiere momentan auch mit dem crcmod Package rum, allerdings auch mit unterschiedlichen Ergebnissen.
Wenn ich das Internet richtig ausgelesen habe:
=> Bascom verwendet 8C, Poly is die x⁸ + x⁵ + x⁴ + 1 => Hexadezimal 8C, binär 10001100.
Selbst wenn ich mit der Hand rechne, komme ich laut CRC Vorgabe auf ein anderes Ergebnis:

Rechnung in Bascom:


Dim Daten(1) As Byte
Dim Crc As Byte
Daten(1) = 201

crc = Crc8(daten(1) , 1)
print crc
end


Ausgabe ist die 86 (Dezimal)

Das ganze von Hand berechnet:
Nachricht: 11001001
Generatorpolynom: 10001100
Anzuhängende Nullen: 7



110010010000000 : 10001100 = 11000011
10001100
--------
10001010000000
10001100
--------
00000110000000
10001100
--------
010011000
10001100
--------
00010100


Sprich, hier ist das Ergebnis hex 0x14, bzw dez 20
So langsam blicke ich gar nicht mehr durch :(

Sieht jemand meinen Fehler?

Gruß

Michael

[Crashmichl]

Hi,



import crcmod.predefined


sample1='\x37\x01\xc8\0\0\0'
crc8_func = crcmod.predefined.mkPredefinedCrcFun('crc-8-maxim')
print "Print CRC Sample1 0 ", crc8_func(sample1[0])
print "Print CRC Sample1 0 ", hex(crc8_func(sample1[0]))


löst das Problem.

Gruß

Michael

[Crashmichl]

Anmerkung an den eigentlich gelösten Eintrag (habe mittlerweile wieder Zeit gefunden, weiter zu machen):
http://93.93.128.176/forums/viewtopic.php?t=13771&p=459989
(http://93.93.128.176/forums/viewtopic.php?t=13771&p=459989)Problem am I2C Bus ist nicht ein fehlerhafter Aufbau, sondern der RPi (leider auch der Raspberry Pi 2) unterstützt kein clock stretching.
Dadurch kommen die Störungen.

Gruß Michael

[Peter(TOO)]

Hallo Michaek,


Beim spielen mit anderen Tools, um ein Gefühl dafür zu bekommen (z.B. http://www.smbus.org/faq/crc8Applet.htm) und habe keine Ahnung, wie ich das genau machen soll, da ich dort nicht auf das gleice Ergebnis gekommen bin.
Wie muss ich mir das vorstellen?
Werden die Bytes hintereinander aufsummieren (z.B. 055001200000000000) und dann die Polynomdivision durchführen?
Vielleicht kann mir da mal jemand einen Schupser in die richtige Richtung geben.

Bei eine Prüfsumme werden die Bytes addiert.
Unterschiede gibt es beim Startwert. Die Variable für die Summe wird oft mit 0 oder -1 initialisiert.
Dann wird bei manchen Protokollen der Wert oder das 1er Komplement übertragen.
Ein Grund für den Startwert -1 oder das 1er Komplement liegt darin, dass ein gültiges Datenpaket mit lauter 00 dann auch eine Prüfsumme von 00 hat und möglicherweise nicht von einem Leitungsunterbruch unterschieden werden kann.
Manche Prüfsummen verwenden auch das Resultat, z.B. einer Modulo Division. Oft wird MOD 9 oder MOD 11 verwendet.

Ein Problem bei der Prüfsumme ist, dass Mehrbitfehler nicht immer erkannt werden können. Die Summe von 3+1 und 1+3 ist die Selbe!

Bei einer CRC werden auch noch die Bitpositionen zusätzlich mit einbezogen, sodass 3+1 und 1+3 unterschiedliche CRCs ergeben.
Die einfachste Form wäre, dass man die Summenvariable nach jeder Addition um 1 Bit rotiert.
Die meisten CRC-Polynome sind aber etwas komplizierter. Je nach Wahrscheinlichkeit, welche Bitfehler gehäuft auftreten können, sind unterschiedliche Polynome unterschiedlich gut geeignet. Auch mit einer CTC hat man keine 100% Erkennungsrate für Mehrbitfehler. :-(

http://www.tecchannel.de/netzwerk/management/431454/netzwerk_grundlagen_teil_2/index7.html

MfG Peter(TOO)