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

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

MfG Peter(TOO)