1-wire CRC

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hey Leute,

    ich versuche gerade den CRC bei einem DS18B20-Temperatursensor durchzuführen, komme aber irgendwie nicht weiter. Ich verwende für Python das Modul crcmod. Der Doku kann man entnehmen, dass ich über die CRC function factory mit "mkCrcFun()" meine Funktion aufstellen kann, mit der sich der CRC berechnen lässt.

    Dem Datenblatt des SD18B20-Temperatursensor lässt sich entnehmen, dass das Generatorpolynom X^8 + X^5 + X^4 + 1 entspricht. Über das Polynom abgeleitet ergibt das bei mir 100110001 ... das sind aber 9-Bits und keine 8-Bits ... ? (Meine erste Verwirrung). Unabhängig von den 8- bzw. 9-Bits stehe ich mit meiner Python-Funktion vor einer Wand, denn betrachte ich die Doku, über das CRC-32 Beispiel, wird der poly-Wert mit Hex angegeben, in der Doku steht allerdings "a Python integer or long" ... ???

    Setzte ich mein Generatorpolynom ein, erhalte ich folgende Fehlermeldung: "The degree of the polynomial must be 8, 16, 24, 32 or 64". Irgendwie komisch.

    Stehe ich auf dem Schlauch, seh den Wald vor lauter Bäumen nicht oder was ist da los? Kann mir wer auf die Sprünge helfen? Big Thx!

    Ich hoffe, dass ich aber sonst korrekt in der Annahme bin, dass ich mit der Funktion, falls sie mein poly erkennen sollte, dann über .crc_function(data[, crc=initCRC]) mein CRC-Value berechnen kann.

    Der 64-Bit ROM-Code setzt sich ja aus 8-Bit "Family Code", 48-Bit "Seriennummer" und dem 8-Bit CRC zusammen. Nehme ich einen Beispiel-Senor mit der Kennung "28-000003cee4ca" handelt es sich dabei ja um Hex. Wandle ich das in Bits um, kommt n langer Rattenschwanz raus. Würde bei mir von LSB nach MSB "0001 0100 0101 0011 0010 0111 0111 0011 1100 0000 0000 0000 0000 0000 00000000" ergeben. Über das Polynom errechnet mir der Sensor daraus ja den bei mir ankommenden CRC, durch erneute Division über das Poly müsste dann ja bei perfekter Übertragung meine 8-Bits 0er rauskommen. Als "data" setze ich also den bei mir ankommenden Wert ein. Nur wo kann ich den entnehmen? Handelt es sich bei der oberen Zahlenreihe innerhalb der w1_slave-Datei dann um den mir übermittelten 64-Bit ROM-Code? Weil ich sehe da 18 Hex Werte, was 72-Bits entspricht und keine 64 ... *Verwirrung*

    Bin ich auf dem Holzweg? Hab das alles bisher nur in der Theorie gemacht, aber noch nie in der Praxis und auch nicht mit Python. Von daher vielen Dank um Nachsicht und ich hoffe, dass mir wer weiterhelefen kann.


    Gruß
    mobby


  • Hey Leute,
    ich versuche gerade den CRC bei einem DS18B20-Temperatursensor durchzuführen, komme aber irgendwie nicht weiter.

    Ähmmmm, sorry, aber wozu das ganze ?
    Der Sensor gibt Dir bei jeden "read" also File öffnen , lesen ,closen, nen 2-zeiligen Code.
    Am Ende der ersten Zeile steht "crc" "YES" , oder eben nicht.
    Am Ende der 2. Zeile steht die gemessene Temp.

    So in der Art:

    Zitat

    37 00 4b 46 ff ff 07 10 1e : crc=1e YES
    37 00 4b 46 ff ff 07 10 1e t=27312

    Wozu dann mit irgendwelchen Alogrithmen das CRC (macht er doch selbst) neu errechnen.
    Wenn Du dem nicht traust, hast wohl verloren ...


    Setzte ich mein Generatorpolynom ein, erhalte ich folgende Fehlermeldung: "The degree of the polynomial must be 8, 16, 24, 32 or 64". Irgendwie komisch.


    "Dein" Generatorpolynom mag ja lustig sein, aber das des Herstellers kennst ja nicht...
    ... Trau keinem weiter, als Du ihn werfen kannst...
    Und das kommt noch dazu:

    Zitat

    The DS18B20 is a small thermometer with a built in 12bit ADC; .


    Würde bei mir von LSB nach MSB "0001 0100 0101 0011 0010 0111 0111 0011 1100 0000 0000 0000 0000 0000 00000000" ergeben. Über das Polynom errechnet mir der Sensor daraus ja den bei mir ankommenden CRC, durch erneute Division über das Poly müsste dann ja bei perfekter Übertragung meine 8-Bits 0er rauskommen. Als "data" setze ich also den bei mir ankommenden Wert ein. Nur wo kann ich den entnehmen? Handelt es sich bei der oberen Zahlenreihe innerhalb der w1_slave-Datei dann um den mir übermittelten 64-Bit ROM-Code? Weil ich sehe da 18 Hex Werte, was 72-Bits entspricht und keine 64 ... *Verwirrung*


    ...Da ist Verwirrung vorprogrammiert... :lol:

    gruß root

    Einmal editiert, zuletzt von root (1. September 2014 um 03:27)

  • Zitat von roor

    Ähmmmm, sorry, aber wozu das ganze ?
    Der Sensor gibt Dir bei jeden "read" also File öffnen , lesen ,closen, nen 2-zeiligen Code.
    Am Ende der ersten Zeile steht "crc" "YES" , oder eben nicht.

    Das ist mir zu langweilig und einfach, ich will es einfach gerne selber machen, weil es mich interessiert und mir sowas Spaß macht. :cool:

    Zitat von roor

    "Dein" Generatorpolynom mag ja lustig sein, aber das des Herstellers kennst ja nicht...

    Das gepostete Generatorpolynom ist das des Herstellers ... alle Dallas bzw. Maxim Geräte arbeiten mit dem CRC-8 Verfahren.

  • Ok ... wenn Du das lustig findest und es dir Spaß macht ...
    Ich kann Dir da jetzt ad hoc auch nicht weiterhelfen, aber schau doch vielleicht mal in den Source für das 1Wire Protokoll (Kernelmodul) ... da müsste ja die Berechnung enthalten sein.

    cu,
    -ds-


  • Das ist mir zu langweilig und einfach, ich will es einfach gerne selber machen, weil es mich interessiert und mir sowas Spaß macht. :cool:


    Hab ich ja schon. Dar ober oben genannte "aplication letter 27" beschreibt das Verfahren sowie "how to use" des CRC bei 1-wire. Nur mein Problem ist mehr das Python-Modul. Weil wenn ich den Ansatz damit versuche nur Errors herauskommen :(

    vielleicht hilft dir die C-Source die ich am Amel einsetze

    crc8.c

    crc8.h

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Wenn Du hier nachsiehst taucht da das GeneratorPolynom wie folgt auf:

    Code
    x⁸+x⁵+x⁴+1 = (x+1) (x⁷+x⁶+x⁵+x³+x²+x+1)

    Letzteres ist mit 8-Bit darstellbar. ... Vielleicht gibt das ja neue Denkanstöße :)

    BTW: Hier wird crcmod.predefined crc-8-maxim erwähnt. Warum benutzt Du den nicht sondern schlägst Dich mit dem GeneratorPolynom rum?

  • Zitat von framp

    BTW: Hier wird crcmod.predefined crc-8-maxim erwähnt. Warum benutzt Du den nicht sondern schlägst Dich mit dem GeneratorPolynom rum?

    Super Sache framp! Vielen dank, das hatte ich wohl übersehen. Mit den vordefinierten crcs läuft das schon besser, der genannte Fehler tritt jetzt nicht mehr auf.

    Allerdings stehe ich noch immer vor dem Problem der praktischen Umsetzung. Meine Vorgehensweise bisher:

    1. Der 1-wire-Sensor müsste mir doch eine 64-Bitfolge übertragen. Bestehend aus "family code", "serial number" und dem crc-value. Der crc-value wird berechnet aus dem 64-Bit-Wert bestehend aus "family code", "serial number" und 8-bit 0er, geteilt durch mein Generatorpolynom (in dem Fall crc-8-maxim).

    2. Diese Bitfolgemuss ich irgendwo finden und anschließend wieder durch mein Generatorpolynom teilen. Wurden alle Daten korrekt übertragen muss 0x00, also 00 rauskommen.

    3. Nur erstens, wo ist diese Bitfolge? Falls es die Hexzahlen innerhalb der w1_slave-Datei sind, dann nehme ich die ersten 16 Hexzahlen als Bitfolge an (sind 64 bit). Daneben stehen noch zwei Hexzahlen (z.B. "e1") und das Ergebnis crc=e1. Aaaaaalso sollte das ja schon das Ergebnis sein !!! Sprich mein schon durch das Polynom geteilter Bitstrom sowie der Rest, in dem Fall eben "e1". Das ist zwar nicht "00" was auch wiederum komisch ist, aber wäre ein Ansatz. Falls ich damit richtig liege, wo bekomme ich dann die noch nicht geteilte Bitfolge her? :s

    Oh man, echt ganz schön verwirrend das Thema. In der Theorie ist es relativ logisch, aber in der Praxis mache ich entweder was elementar falsch oder es ist doch nicht so einfach :D

  • "Schulterklopf" ... nur zu, werd scho wer'n...:thumbs1:


    Oh man, echt ganz schön verwirrend das Thema. In der Theorie ist es relativ logisch, aber in der Praxis mache ich entweder was elementar falsch oder es ist doch nicht so einfach :D


    Kannte mal jemanden, der musste sich auch alles selbst beweisen.
    Angefangen hat es, als seine Pneus abgefahren waren, Mit 2 Eimern in den Urwald, bißchen Kautschuk zapfen und mit Hasenstalldraht und dem Rohkautschuk die Pneus selbst backen...
    Aufgehört hat es, als er Einstein's Theorie der max. Geschwindigkeit (Licht) mit nem "Ariane-selbstbausatz mit Nachbrenner" widerlegen wollte.
    Nach Zündung und nem kurzem Blitz ward er nicht mehr gesehen...

    Wissenschaftler, Theologen und sonst geistiges Volk diskutieren noch heute über den Sinn des Blitzes...
    Zyniker meinen.. da war wohl ein kleiner Fehler im Bausatz...
    Die anderen... Nein, das war der Blitz zum Worp X Einsprung..... Fragen über Fragen ...

    ...nix für ungut...
    gruß root

    Einmal editiert, zuletzt von root (1. September 2014 um 19:05)


  • ....3. Nur erstens, wo ist diese Bitfolge? Falls es die Hexzahlen innerhalb der w1_slave-Datei sind, dann nehme ich die ersten 16 Hexzahlen als Bitfolge an (sind 64 bit).

    das sind 8 Zahlen nicht 16 und 8 Zahlen a 8 Bit sind 64 bit


    ...zwei Hexzahlen (z.B. "e1")

    und wieder eine Zahl


    ich hatte doch die C-Sourcen genannt

    und unter uns als Student, sollte wenigstens Mathe halbwegs sitzen und die Zahlensysteme bekannt sein,
    Dezimal kennt noch jeder
    bei binär und oct schwächeln viele
    und hex ist in aller Munde obwohl hex für 6 steht und die Basis aber 16 sedezimal ist.
    Somit wäre die richtige Bezeichnung sedezimalsystem (hex sagen nur die Progger und Schlusen, ich auch ;) )

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

    Einmal editiert, zuletzt von jar (1. September 2014 um 20:34)

  • jar: Davon ausgehend, dass eine Hexzahl (also 0/1/2/3/4/5/6/7/8/9/A/B/C/D/E/F) den Dezimalen 00-15 entspricht und einer Zahl 4-Bits zugeordnet sind, habe ich das auf die Zahlenfolge in der Datei übertragen. Also wären es nach der Zählung doch 16 Hexzahlen à 4-Bits. Aber die Darstellung in 2er-Pärchen weist eigentlcih drauf hin, dass es sich um eine 8-Bit Hexzahl handelt und keine 4-Bit. Also sry wegen meinem Fehler und danke für den Hinweis drauf! :) Da wurde einfach zu viel gehext um mich herum :blush:


  • .....aber hex ist im EDV Kontext....

    der EDV Kontext ist auch nicht mehr das was er mal war,

    jetzt sind Kbyte nicht mehr 1024 Byte (2^10) wenngleich da ab und an noch k und K unterschieden wird, aber MByte schon lange nicht mehr 1024 x 1024 (2^20) Byte ist, wer mag kann das mit den gebräuchlichen 10er Potenzen entschuldigen, ich nicht. :fies:

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!