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:
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.
Byte1 Byte2 Byte3 Byte4 Byte5 Byte6 CRC 55 1 200 0 0 0 128
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
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.Zitat von Crashmichl
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
Strom fließt auch durch krumme Drähte !
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
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
Strom fließt auch durch krumme Drähte !
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
"sicher" ist die falsche Formulierung, bei deiner Fehlerrate ist er einfach kaputtWohl 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... 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.
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
Strom fließt auch durch krumme Drähte !
Google ist dein Freund:
http://www.python-forum.de/viewtopic.php?f=11&t=33031
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:
Ausgabe ist die 86 (Dezimal)Code:Dim Daten(1) As Byte Dim Crc As Byte Daten(1) = 201 crc = Crc8(daten(1) , 1) print crc end
Das ganze von Hand berechnet:
Nachricht: 11001001
Generatorpolynom: 10001100
Anzuhängende Nullen: 7
Sprich, hier ist das Ergebnis hex 0x14, bzw dez 20Code:110010010000000 : 10001100 = 11000011 10001100 -------- 10001010000000 10001100 -------- 00000110000000 10001100 -------- 010011000 10001100 -------- 00010100
So langsam blicke ich gar nicht mehr durch
Sieht jemand meinen Fehler?
Gruß
Michael
Geändert von Crashmichl (03.02.2014 um 19:17 Uhr) Grund: Formatierung
Hi,
löst das Problem.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]))
Gruß
Michael
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
Berechtigungen
Zitieren
Lesezeichen