CRC-8 in Python

Druckbare Version

02.02.2014, 16:16
Crashmichl

CRC-8 in Python

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
02.02.2014, 20:48
Klebwax

Zitat:

Zitat von Crashmichl

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
02.02.2014, 21:09
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
02.02.2014, 23:16
Klebwax

Zitat:

Zitat von 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.

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
03.02.2014, 06:14
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
03.02.2014, 13:47
Klebwax

Zitat:

Zitat von Crashmichl

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

Zitat:

.. 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
03.02.2014, 15:31
Pyro-Mike

Google ist dein Freund: ;-)
http://www.python-forum.de/viewtopic.php?f=11&t=33031
03.02.2014, 18:16
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:

Code:

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

Code:

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
03.02.2014, 22:15
Crashmichl

Gelöst

Hi,

Code:

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
15.02.2015, 22:50
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
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
16.02.2015, 00:07
Peter(TOO)

Hallo Michaek,

Zitat:

Zitat von Crashmichl

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/ma..._2/index7.html

MfG Peter(TOO)

Byte1	Byte2	Byte3	Byte4	Byte5	Byte6	CRC
55	1	200	0	0	0	128