1Wire-Addressen DS18B20: Vorsicht Falle ...

  • Hallöle zusammen,

    ich habe da gerade ein etwas sonderbares Phänomen festgestellt.
    Wenn ich einen DS18B20 am Raspi anschliesse, dann erhalte ich als Adresse die Bytefolge:

    Code
    10:00:08:02:78:c4:d6


    -> der Sensor taucht also unter /sys/bus/blabla .../10-00080278c4d6 auf.

    Verwende ich auf dem Arduino die DallasTemperature-Library erhalte ich für denselben Sensor über die Funktion getAddress() die Bytefolge

    Code
    10:d6:c4:78:02:08:00:3d


    -> hier ist schon mal bemerkenswert, dass die Addresse ein Byte länger ist, als auf dem Raspi.
    Dieses Byte wird auf dem Raspi scheinbar unterschlagen ( evtl. ist das auch ein CRC-Byte :s ) und dann, um die Adresse zu generieren, auch noch die Bytes von 1 bis 6 in umgekehrter Reihenfolge verwendet.

    Das ist imho ganz gut zu wissen, wenn man einen Datenaustausch Arduino <-> Raspi macht und evtl. mal einen Sensor von einem System abklemmt um ihn dann am anderen zu verwenden.


    cheers,
    -ds-

  • Danke, gut zu wissen - möglicherweise hat der Autor des W1 Moduls das letzte Byte bewusst weggelassen, weil es für die Eindeutigkeit reicht oder es ist, wie Du schon sagst, die Prüfsumme.

    Nicht gerade diesen Beitrag betreffend, aber Du und Deine gadgets - immer wieder aussergewöhnliche Beiträge! Da stoß' ich gleich mal gerne "virtuell" auf Dich an! ;)

    Zum Woi!

  • dange dange mmi ;) ...

    ist aber auch manchmal verrückt ...
    Das letzte Byte ist übrigens tatsächlich der CRC8 über die Adresse in der Reihenfolge, in der der Arduino sie ausliest.
    Ist mir halt genau wegen meiner SQLite DB aufgefallen, weil der RPi plötzlich gar keinen Sensor mehr kannte ...

    BTW: gibts was Neues vom Edison ??

    cheers und pfiad de,
    -ds-


  • Das letzte Byte ist übrigens tatsächlich der CRC8 über die Adresse in der Reihenfolge, in der der Arduino sie ausliest.


    Ok, macht auch Sinn. Fragt sich nur, was das Kernelmodul eigentlich macht, wenn der CRC nicht stimmt? Könnte man ja, wenn man nicht so faul wie ich ist, im Code bzw. auch Doku nachsehen. Ich vermute mal, der Sensor wird dann einfach nicht ins System eingebunden.


    BTW: gibts was Neues vom Edison ??

    Das eine oder andere wird weiterentwickelt und bugs behoben - aber noch nix spektakuläres. Das zusätzliche Sahnestück - der eingebaute uC - taucht jetzt wenigstens schon mal inoffiziell in der Kernelumgebung auf. Hab's Dir ja schon geschrieben - "bitbake" mit "Yoctolinux" - wer hat sich nur diese 'Blähung' einfallen lassen? Bei mir läuft zwar nach etwas Pfriemelei Archlinux, aber aufgund der vielen patches und einem ausschliesslich für den Kernel fehlenden standalone GIT repo ist man vom Yocto Kernel abhängig. "Ubilinux", ein Debianderivat, ist übrigens auch eine OS Alternative.

    Die onboard "sdcard" ist übrigens auf 10 Partitionen aufgeteilt - naja, auch da verstehe ich unter "keep it simple" was anderes und es ginge auch anders. :wallbash:

    Begeisternd ist aber hardwaremässig nach wie vor die Minibauweise mit modernsten Bauteilen, das ist wirklich gelungen. Effizienter Spannungswandler (ca. 7 bis 15V eingangsseitig), intelligente Ladeelektronik für LiPo Akkus, USB als Master/slave möglich, WiFi 2,4/5 GHz, etc. mit dem Minibreakoutboard.
    Intel ist halt kein Softwarehaus und das merkt man somit doch recht deutlich.

    Die mit "nur" 512 MHz getaktete und stark abgespeckte ATOM CPU fühlt sich im Vergleich zu einer mit 1 GHz getakteten ARM CPU keineswegs langsam an, die x86 Architektur hat ja auch klare Vorteile.
    Im Gegenzug hat bzw. hätte man bzgl. Stromverbrauch hervorragende Ergebnisse, was für ein "wearable" device auch erwartet wird. Ein standby-Betrieb mit lediglich ca. 12 mA Stromaufnahme soll möglich sein - wahrscheinlich hat man die aktuellen und noch nicht ganz so passenden OS Fähigkeiten dabei erstmal links liegenlassen. ;)

    Jetzt hab' ich mich wieder in meiner noch nebensächlichen Edison Liebe verloren. Du merkst, das Teil hat was und systemsoftwaremässig wird's (wohl und hoffentlich) auch noch was werden. So wie gemunkelt wird, soll der eingebaute uC ein Pentium 3 sein, mit Quark OS (was mir jetzt erstmal nichts sagt). Das lässt aber im Vergleich zu Atmel und anderen Microcontrollern einiges mehr erwarten. Mal abwarten, kann sich ja nur noch um Monate handeln.:D

    LG und hawediere,
    mmi.

    EDIT:
    Damit's jetzt nicht ganz so klingt, als könne man mit dem Edison mit derzeitigem Softwarestand gar nichts mit externen Gadgets machen:

    Vergleichbar zu einigen libs beim RPi gibt's beim Edison die sog. MRAA library. Damit kann mit GPIOs, i2c, spi, usw. gearbeitet werden, aber eben noch ohne Nutzungsmöglichkeit des eingebaute Microcontrollers.
    Vergleichbar mit einem RPi mit Arduinoboard, wobei der Arduino noch nicht genutzt werden kann.

  • Hi mmi ...

    danke für die Info ...
    Auch wenn das mittlerweile OT ist: das Ding hat irgendwie was ... wenn ich nur nicht so viel anderen, interessanten Kram angefangen hier rumliegen hätte ;)
    Das mit den 10 Partitions macht imho schon Sinn: wenn der integrierte µC in der Tat ein P3 ist, könnte ich mir vorstellen, dass der auch einen Teil des Filesystems z.B. als NTFS abbekommt. Es würde mich wundern, wenn der Redmonder Chaoten-Haufen da nicht auch schon ein Auge drauf geworfen hätte :fies:

    also dann,
    pfiad di, servus, bis amoi,
    -ds-

  • OT? Stimmt, aber hier im Mikrocontrollerforum schon noch vertretbar, denke ich mal - zumal wir es ja nicht mehr weiter ausweiten.


    ... das Ding hat irgendwie was ... wenn ich nur nicht so viel anderen, interessanten Kram angefangen hier rumliegen hätte ;)

    Wem sagst das - bei mir wartet der ESP immer noch auf seinen Einsatz. Vielleicht auch gar nicht so schlecht, wenn die "Betriebssysteme" dafür mittlerweile immer besser werden. :)


    Das mit den 10 Partitions macht imho schon Sinn: wenn der integrierte µC in der Tat ein P3 ist, könnte ich mir vorstellen, dass der auch einen Teil des Filesystems z.B. als NTFS abbekommt. Es würde mich wundern, wenn der Redmonder Chaoten-Haufen da nicht auch schon ein Auge drauf geworfen hätte :fies:

    Die intelseitig bereitgestellten Tools (wie z.B. "IoT Kit") sind natürlich meistens für Windows, FAT/NTFS Partitionen halten sich aber in Grenzen. Diese Tools bringen auch wieder ne Menge overhead mit sich und sollen wohl dem Einsteiger helfen - mit etwas Linux Erfahrung vermisst man eigentlich nichts. Ich nutze nur die Arduino IDE von Intel, die gibt's natürlich auch für Linux (ist ja Java) und ein Sketch ist schnell kopiert und gestartet.

    Muß mich jetzt mal dran machen, das rootfs auf USBstick auszulagern. So kompakt die onboard Speicherlösung auch ist, aber geht dort der Speicher kaputt, kann man gleich alles wegwerfen - das sollte man doch bedenken und im Entwicklungsstadium braucht man's ja auch noch nicht so elegant.


    also dann,
    pfiad di, servus, bis amoi,
    -ds-

    Dessogietza - OT terminated - servus,
    mmi

Jetzt mitmachen!

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