Verschiedenes > Bastelecke

1-Wire-Slave-Baukasten

(1/3) > >>

RoBue:
Hi Leute,
wie versprochen stelle ich hier mal einige meiner Entwicklungen zum Nachbasteln und Herumexperimentieren ein.

Etwas heikel ist die Entwicklung von eigenen 1-Wire-Slaves. Maxim scheint nicht besonders erpicht darauf zu sein, aber es fehlen leider zu viele Komponenten für ein umfassendes System. Außerdem werden gute und sinnvolle Bauteile (z.B. DS2423, DS2450) abgekündigt. Deswegen finden sich im Internet einige Ansätze, vorhandene Bausteine durch den Einsatz von Mikrocontrollern nachzubauen oder neue zu entwickeln.

Hier einige gute Beispiele:
-> http://www.mikrocontroller.net/topic/241934#new
-> http://www.mikrocontroller.net/topic/44100 (vor allem DS2423)
-> http://www.mikrocontroller.net/topic/271772 (DCF77)
-> http://www.tm3d.de/index.php/1-wire-device-mit-avr (DS18B20, DS2423, Barometer)
-> http://www.mcselec.com/index.php?option=com_content&task=view&id=256&Itemid=57 (DS2450 mit BASCOM)
-> http://www.brain4home.eu/index.php

Aus diesen Vorlagen entschloss ich mich einen einfachen 1-Wire-Slave-Baukasten zu entwickeln, mit dem man unter BASCOM leicht eigene Slaves erstellen kann. Auf diese Weise kann man evtl. abgekündigte Bausteine im begrenzten Umfang nachbilden, aber vor allem andere Sensoren (z.B. analoge oder I²C) in das 1-Wire-System einbinden. Dies ist  z.B. bei dem weit verbreiteten SHT11 durchaus sinnvoll.

Schwierig ist das jedoch, WIE diese neuen Slaves vom Master angesprochen werden sollen, wenn der Master bzw. dessen Steuersoftware diesen Slavetyp überhaupt nicht kennt!
Es gibt zwei Lösungswege:
- Wenn man die Steuersoftware selbst schreiben kann, ist ein eigener Family-Code am einfachsten. Dann kann man darüber den Slave eindeutig identifizieren und ihn seiner Funktion entsprechend auslesen.
- Wenn man auf eine fertige Steuersoftware zurückgreifen will/muss, bleibt einem nichts anderes übrig, als den Slave so zu programmieren, dass er sich analog zu einem vorhandenen Baustein verhält. Die Gefahr, dass es dabei zu Doppelungen in der 64-Bit-ID kommt, ist dabei sicher gering, aber trotzdem möglich.

Meine Lösung:
- In der Slave-Software ist ein DS18B20 als Standard eingestellt (Data &H28 , &H53 , &H48 , &H54 , &H00 , &H00 , &H00 , &H68).
- Um eine andere ID mit evtl. einem anderen Familiy-Code einzustellen, muss man diese in die ersten 8 Bytes des EEPROMs des ATmega schreiben. Dann wird diese automatisch beim Starten als (neue) ID genutzt.
- Der Slave verhält sich ähnlich wie ein DS18B20, d.h. der Befehl "&H44" (Convert Temperature) berechnet alle Werte, schreibt sie in die ersten 8 Bytes eines Arrays und erstellt  daraus eine CRC-Prüsumme, die in das 9.Byte des Arrays geschrieben wird. Der Befehl "&HBE" (Read Scatchpad) gibt  8 Werte und die CRC-Prüfsumme (=9. Wert) aus.
- Diese 8 Werte selbst sind aber nicht mit denen eines DS18B20 kompatibel,  sondern daraus muss man nun, je nach Funktionen des Slaves, seine Werte gewinnen. Das funktioniert also nur mit  Steuerssoftware, die auch das Scatchpad ausgibt und nicht nur fertige Werte anzeigt. Möglich ist das z.B. mit DigiTemp oder den 1-Wire-Kernel-Modulen des RaspberryPi, leider geht es wohl nicht mit owfs oder IPSymcon.
- Wenn man auf eigene Software zurückgreifen kann, dann kann man für den Slave entweder einen eigenen Family-Code wählen (z.B. &HFE) oder über den Befehl "&H10" und "1wread()" einen Wert auslesen. Ist er <> 255/&HFF, dann ist es kein echter DS18B20. Eine eigene 64-Bit-ID(s.o.) kann man sich z.B. bei -> http://www.tm3d.de/index.php/tools berechnen lassen. Das AVR-PC-Control erkennt  Eigenbau-Slaves mit Familiy-Code &HFE und "falsche" DS18B20 über den Befehl "&H10" und gibt die Messwerte im richtigen Format aus.

(siehe Anhang / see attachement)

Beispiel für einen 1-Wire-Slave mit ATmega8/168 für SHT11 und LCD-Ausgabe (Source- und Hex-Files):
Aufbau der ID: Familycode: &H28 oder &HFE; Byte 2-4: &H53 &H48 &H54 = "SHT"; Byte 5-7: Nummer; Byte 8: CRC8
Scatchpad: Byte 1+2 = Temperatur x 10, Byte 3+4 = Luftfeuchte x 10, Byte 5+6 ADC oder Counter, Byte 7 = z.Z. unbenutzt, Byte 8 = Fehlerstatus (Byte 9 = CRC)

Folgende Ergänzungen und Erweiterungen sind möglich:

- LED an PORTB0 mit Widerstand gegen GND. Sie zeigt an, wenn der Slave gerade angesprochen wird

- Jumper an PORTD4 (Pin 6)gegen GND. Wenn der Jumper gesteckt ist, dann läuft das Modul im Standalone-Betrieb (Ausgabe alle 15s, kein 1-Wire-Zugriff möglich!!!)

- 16Bit-Counter an PORTD5 (Pin 11)

- ADC-Eingang an PORTC0 (Pin 23) füer analoge Sensoren (Luftgüte, Druck, Licht ...)

(siehe Anhang / see attachement)

Viel Spaß,
RoBue

erwin:
Hi RoBue,

großartige Sache, die du da ins Spiel bringts!
Ich hab deine Beiträge in der Vergangenheit im Bascom Forum verfolgt und daraus jede Menge gelernt.
Mein Vorschlag zu deinen Überlegungen:

--- Zitat ---- Der Slave verhält sich ähnlich wie ein DS18B20, d.h. der Befehl "&H44" (Convert Temperature) berechnet alle Werte, schreibt sie in die ersten 8 Bytes eines Arrays und erstellt daraus eine CRC-Prüsumme, die in das 9.Byte des Arrays geschrieben wird. Der Befehl "&HBE" (Read Scatchpad) gibt 8 Werte und die CRC-Prüfsumme (=9. Wert) aus.
--- Ende Zitat ---

...damit die Sache OWFS..usw. "kompatibel" wird:
Wie wär's, entweder ein RAM / ROM (DS192x) zu emulieren, wo OWFS sowohl scratchpad, ... schreiben als auch lesen kann -
Alternativ auch ein DS2450, DS2438 - wenn es was zu "triggern" gibt.....
Was man sich "ersparen" würde, wäre die physische Schittstelle/das Transportprotokoll usw. neu zu erfinden.
Die Interpretation der "Werte" bleibt dann natürlich nach wie vor der Software, die auswertet....das ist in FHEM jedoch retaliv einfach zu implementieren (siehe OWDevice).

Was hälts du davon ?
l.g. erwin

RoBue:
Hallo erwin,

da bin ich dabei, aber das macht auch eine ganze Menge Arbeit.
DS2450-Anpassung habe ich schon angefangen, aber da sind die ständigen CRCs,
die mich einfach nerven. Darum habe ich mich vorerst für die einfachere Version entschieden.

Die ROMs/RAMs wären fast noch besser,
aber da habe ich gar keine Erfahrung.

Auf jeden Fall habe ich noch ein paar Bilder und die Programme für eine ATtiny45-Version, aber leider noch in der DS18B20-Variante.

(siehe Anhang / see attachement)

(siehe Anhang / see attachement)

Liebe Grüße,
RoBue

RoBue:
Hi Leute,

hier nun ein Beispiel,
wie man die (neuen) 1-Wire-Slaves am RaspberyPi
mit bash-Scripten und mit Hilfe der 1-Wire-Kernel-Module
ansprechen und auslesen kann:

Installation der Module:


--- Code: ---
modprobe wire
modprobe w1-gpio
modprobe w1-therm

--- Ende Code ---


Der Slave wird als DS18B20 erkannt und ein Verzeichnis mit seiner ID unter

     /sys/bus/w1/devices

angelegt.

Nun die Abfrage und Ausgabe (nur 1 Slave angeschlossen !!!):


--- Code: ---
#!/bin/bash

# ID des 1. Sensors auslesen
sensor=`cat /sys/devices/w1_bus_master1/w1_master_slaves | head -1`

while true
do
    clear

    echo -n "Sensor auslesen ..."

    # Scratchpad auslesen
    scratchpad=`cat /sys/bus/w1/devices/$sensor/w1_slave | grep "t=" | tr a-f A-F`

    echo " fertig!"
    echo

    # einzelne Werte isolieren
    temp_low=`echo $scratchpad | cut -d" " -f1`
    temp_high=`echo $scratchpad | cut -d" " -f2`
    hum_low=`echo $scratchpad | cut -d" " -f3`
    hum_high=`echo $scratchpad | cut -d" " -f4`
    wert_low=`echo $scratchpad | cut -d" " -f5`
    wert_high=`echo $scratchpad | cut -d" " -f6`
    error=`echo $scratchpad | cut -d" " -f8`

    # Temperatur berechnen (mit bc)
    temperatur=`echo "ibase=16; ($temp_high * 100) + $temp_low" | bc`
    temperatur=`echo "scale=1; $temperatur / 10" | bc`

    # Luftfeuchte berechnen
    luftfeuchte=`echo "ibase=16; ($hum_high * 100) + $hum_low" | bc`
    luftfeuchte=`echo "scale=1; $luftfeuchte / 10" | bc`

    # 3. Wert (Counter, ADC, ...)
    wert=`echo "ibase=16; ($wert_high * 100) + $wert_low" | bc`

    # Ausgabe
    datum=`date +"%H:%M %d.%m.%Y"`
    echo "Datum      : $datum"
    echo "Sensor-ID  : $sensor"
    echo "Scratchpad : $scratchpad"
    echo "Temperatur : $temperatur °C"
    echo "Luftfeuchte: $luftfeuchte %H"
    echo "3. Wert    : $wert"
    echo "Errorstatus: $error"

    sleep 15

done

--- Ende Code ---


Auf dem Bildschirm müsste dann Folgendes zu lesen sein:


--- Code: ---
Sensor auslesen ... fertig!

Datum      : 12:31 16.04.2013
Sensor-ID  : 28-030000544853
Scratchpad : FE 00 99 01 00 00 00 00 74 t=15875
Temperatur : 25.4 °C
Luftfeuchte: 40.9 %H
3. Wert    : 0
Errorstatus: 00

--- Ende Code ---


Alles klar?

Falls Fragen sind, bitte melden!

Viel Spaß und liebe Grüße,
RoBue

PS:
Hätte jemand Lust mit mir die Kernel-Module um weitere Sensortypen zu erweitern?
Er oder sie müsste sich in C gut auskennen, da da meine Schwächen liegen.
Aber gemeinsam würden wir das sicher in 1 Tag schaffen, z.B. den DS2450 und den DS2413 auch noch zu integrieren.

PS2:
Welche digitalen (evtl. auch analoge) Sensoren sollte man noch in 1-Wire integrieren?
Macht mal Vorschläge (ich schlag dann zurück!)
Anstelle von SHT-Sensoren, kann man übrigens auch HYT-Sensoren nehmen.

RoBue:
Hi Leute (und erfahrene FHEM-User),

ich möchte in den nächsten Tagen FHEM installieren
und damit auch meine Slaves testen
und evtl. die Module von FHEM daran anpassen.

Darum 2 Fragen, damit ich nicht gleich am Anfang auf dem Schlauch stehe:

Frage 1:

Wenn ich 1-Wire über eine serielle Schnittstelle betreibe
(mit den entsprechenden Adaptern natürlich),
reicht es wenn ich z.B. Folgendes eingebe:


--- Code: ---
define 1-Wire OWX /dev/ttyUSB0

--- Ende Code ---


Muss ich dann noch die anderen Module vom Typ 21_OWxxx irgendwie anmelden oder einbinden?
Muss ich noch weitere Änderungen irgendwo vornehmen?

2. Frage:

Wenn ich am RPi die 1-Wire-Kernel-Module nutze,
ist dann der Eintrag:


--- Code: ---
define 1-Wire GPIO4 BUSMASTER

--- Ende Code ---


(vgl. http://forum.fhem.de/index.php?t=msg&goto=67059&rid=0)?

Muss ich da weitere Kernel-Module o.ä. aktivieren?

Danke schon im Voraus,
RoBue

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln