Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython

weef · November 17, 2019, 4:30pm

So machen sie es bei Ethersex:

ethersex/ethersex/blob/master/hardware/onewire/onewire.c#L813-L820


/* a value of 85.0°C will only be stored if we get it twice, to
 * eliminate communication errors */
uint8_t tempis85 = temp.val == (temp.twodigits ? 8500 : 850);
if ((tempis85 && ow_sensors[i].conv_error) || !tempis85)
  ow_sensors[i].temp = temp;


/* set a semaphore of if we had a conversion or communication error */
ow_sensors[i].conv_error = tempis85;

Verwendet wird das dann z.B. so hier:

github.com

ethersex/ethersex/blob/master/control6/examples/mqtt.src#L160-L166


#ifdef ONEWIRE_DS18XX_SUPPORT
  if (j < OW_SENSORS_COUNT)
  {
    if (ow_sensors[j].present == 1 &&
        ow_sensors[j].conv_error == 0 &&
        ow_sensors[j].temp.val != ow_last_values[j].val)
    {

Andreas · November 17, 2019, 4:45pm

Slight out-of-band signalling using a semaphore. Good thing. Danke!

So kann man die Implementierung der Spezifikation im Treiber selbst unterbringen, aber der calling code kann dann selbst je nach Kontext unterscheiden, wie Robert es vorschlägt.

Danke für diesen Hinweis, ich habe ihn weitergegeben ^[1]^[2]^[3]. Da wir dort im 1-Wire/DS18X20-Treiber derzeit leider nur einen diskreten Rückgabewert haben und keine Datenstruktur, wird es momentan vermutlich schwierig, das entsprechend unterzubringen.

Vielen Dank @weef!

didilamken · November 17, 2019, 10:26pm

Die ersten Tests mit 200 Messungen an 5 DS18B20 mit den überarbeiteten Onewire-Treibern sehen sehr gut aus.

Andreas · November 17, 2019, 10:30pm

Exzellent, vielen Dank für die Rückmeldung. Mittlerweile sind wir schon eine Runde weiter: @wtf konnte bestätigen, dass die neuen C-level Treiber auch ordnungsgemäß laufen, siehe Dragonfly firmware for Pycom/ESP32 - #6 by Andreas sowie Annapurna firmware images for Pycom/ESP32.

P.S.: Die aktuellste Variante des pure-Python Treibers von Robert beherrscht nun auch Parasite Power Mode, siehe GitHub - robert-hh/Onewire_DS18X20: Classes for driving the DS18x20 sensor with the onewire protocol for Pycom MicroPython.

Andreas · November 18, 2019, 8:50pm

Das ist das aktuelle Ergebnis hierzu, @robert-hh hat es der Dokumentation des Treibers hinzugefügt. Danke nochmals an @weef!

Diskussion

Dokumentation

didilamken · November 18, 2019, 9:45pm

Der DS18B20-Treiber ist deutlich verbessert worden. Z.Z. wird bei ca. jeder 500. bis 600. Messung ein CRC-Fehler erkannt. Die kann man gut behandeln, durch Auslassen oder den letzten Wert.
Das Problem mit den 85°C ist kaum eins, vor jeder Messung gibt es “convert_temp”, “read_temp” ergibt dann einen Wert oder bei CRC-Fehler “None”.
Nicht erkannte Fehler habe ich bislang noch nicht gesehen.

Danke an @amotl und @robert-hh

Andreas · November 19, 2019, 9:11pm

@robert-hh just shared this very interesting analysis with me. Thanks a bunch!

Andreas · November 21, 2019, 11:41am

Mittlerweile haben wir den modonewire C-level Treiber für uns erschließen können und wir sind zuversichtlich, dass etwaige Timing-Probleme damit endlich der Vergangenheit angehören.

github.com/pycom/pycom-micropython-sigfox

Support modonewire from vanilla MicroPython

pycom:Dev ← daq-tools:modonewire

opened 07:44PM - 04 Nov 19 UTC

amotl

+20 -0

Dear Pycom team, first things first: Thank you so much for your hard work on …bringing this hardware and software ecosystem to the world and congratulations to four years of Pycom by the way. Coming from [1] and [2], we are interested to get more stable readings from some DS18B20 sensors we have attached to one of our FiPy devices by bringing in the 1-Wire driver from the upstream vanilla MicroPython [3]. In order to get started with that, we added this PR which enables the respective extmod at compile time and would be happy to get further support on that. With kind regards, Andreas. [1] https://community.hiveeyes.org/t/untersuchung-und-verbesserung-des-timings-bei-der-ansteuerung-der-ds18b20-sensoren-unter-micropython/2309 [2] https://forum.pycom.io/topic/5330/onewire-py-problem [3] https://docs.micropython.org/en/latest/esp32/quickref.html#onewire-driver

Aktiviert werden kann der “native”-Treiber über folgende Konfigurationseinstellung im Terkin-Datenlogger.

github.com

hiveeyes/terkin-datalogger/blob/bbede7c3/settings.example.py#L333-L340


      
          {
              "id": "bus-onewire-0",
              "family": "onewire",
              "number": 0,
              "enabled": True,
              "pin_data": "P11",
              #"driver": "native",
          },

Dank @wtf’s Testaufbau konnten wir bereits vorsichtige Erfolge dazu verzeichnen.

Andreas · November 22, 2019, 10:37pm

I just wanted to share this piece just recently observed by @wtf, @roh and @weef even with the C-level modonewire driver. It’s probably not timing related but… no idea - is it a borked counterfeit!?

clemens · November 22, 2019, 11:51pm

?? Hmm!? Grafana artefact? Had someone a look at the raw data? Looks like an other resolution, not 12 bit but … but why exactly 0.5 steps??

wtf · November 23, 2019, 12:54pm

I don’t believe in Grafana artefacts here. When you look closely: Rarely there are /some/ readings which are not .0 or .5 … according to some document about counterfeit DS18B20 all DS18B20 we got from Bremen have to be assumed to be counterfeits: When we had some timing-problems in the beginning we got for 5 of 6 sensors the reading “25” which shall be a counterfeit-indicator (original DS18B20 state “85”). (For the sixth sensor we had a correct timing/reading.)

We should probably do some switch-devices-tests. But so far we only have these six sensors.

didilamken · December 17, 2019, 9:34pm

Ich teste in hiverize/fipy mit ATOM die von @robert-hh modifizierten DS18B20-Treiber. Da sind mir einige Ungereimtheiten aufgefallen, die ich aber noch nicht präzise formulieren kann.

Grob kann man sagen:
In reinen Testprogrammen nur mit DS18B20 und OLED-Display gibt es selten CRC-Fehler, die den eindeutigen Wert “None” ausgeben, während der alte Treiber beliebige Fehlwerte (Ausreisser) ausgab.

Im vollen Messprogramm sind die CRC-Fehler deutlich häufiger, mit der Firmware 1.20.xx häufiger als mit Firmware 1.18.xx

Die Methode ds18b20.scan() findet nicht immer alle Sensoren.

Ich kann mit dem Mini-LogicAnalyzer von az-delivery sauber das Protokoll decodieren, habe aber noch keine Fehlerursache gefunden.

Andreas · December 17, 2019, 9:38pm

Hallo Didi,

die Timing-Probleme beim Auslesen der DS18B20-Sensoren gehören seit der Einführung des nativen 1-Wire Treibers so ziemlich der Vergangenheit an. Die von @ckrohne bei Fehlende Meßwerte bei den DS18B20- und BME280-Sensoren beobachteten Lücken beim BME280 sind dem dort erwähnten, kürzlich erfolgten Beitrag Shut down peripherals regardless of using deep sleep or not · hiveeyes/terkin-datalogger@61713c7 · GitHub geschuldet – das wurde jetzt durch Power on I2C peripheral after power off · hiveeyes/terkin-datalogger@f35d9a6 · GitHub wieder gerade gezogen.

Hintergrund: Wir schalten nun nach jedem Meßvorgang die Peripherie ab, damit sich – gerade beim HX711 – die Wägezelle nicht erwärmt. Das passiert nun unabhängig davon, ob man die Firmware zum maximalen Stromsparen während der Betriebspausen in der Deep Sleep Konfiguration betreibt oder nicht.

Viele Grüße,
Andreas.

didilamken · December 17, 2019, 9:44pm

ich benutze die files lib/onewire.py und sensors/ds18x20.py als Treiber. Es gibt die alte Version von @vinz und die neuere von @robert-hh

didilamken · December 17, 2019, 9:49pm

Beispiel für 6 Sensoren:

Detailausschnitt:

Andreas · December 17, 2019, 9:54pm

Hallo Didi,

Mehr über die native Version des Treibers gibt es hier oben im Gesprächsverlauf nachzulesen. Die aktuelle, abermals überarbeitete Fassung des Treibers von @robert-hh bei GitHub - robert-hh/Onewire_DS18X20: Classes for driving the DS18x20 sensor with the onewire protocol for Pycom MicroPython ist nun schnittstellenkompatibel mit beiden Varianten.

Die native Variante kannst Du über die – wie erwähnt schnittstellenkompatiblen – lowlevel Treiber ansprechen, wie wir sie an jener Stelle out-of-the-box im Terkin-Datenlogger erschlossen haben:

github.com

hiveeyes/terkin-datalogger/blob/f35d9a665d700a7d0c1408a542cb436a0b535530/tools/setup.mk#L85-L88


      
          	# Genuine MicroPython driver for Pycom MicroPython 1.11.
          	# https://github.com/micropython/micropython/tree/v1.11/drivers/onewire
          	@test -e $(target_dir)/onewire_native.py || $(fetch) $(target_dir) --output-document=$(target_dir)/onewire_native.py https://raw.githubusercontent.com/hiveeyes/micropython/ds18x20-power-on-reset-value/drivers/onewire/onewire.py
          	@test -e $(target_dir)/ds18x20_native.py || $(fetch) $(target_dir) --output-document=$(target_dir)/ds18x20_native.py https://raw.githubusercontent.com/hiveeyes/micropython/ds18x20-power-on-reset-value/drivers/onewire/ds18x20.py

Damit das funktioniert, müsstest Du Dir ein aktuelles Dragonfly-Build der Pycom Firmware aufs Gerät spielen, siehe Dragonfly firmware for Pycom/ESP32. Diese Builds haben den oben erwähnten nativen Treiber per Support modonewire from vanilla MicroPython by amotl · Pull Request #356 · pycom/pycom-micropython-sigfox · GitHub an Bord.

Viele Grüße,
Andreas.

didilamken · December 17, 2019, 10:34pm

Leider kenne ich mich in github nicht so gut aus: ich habe nichts mit “onewire_native.py” und "ds18x20_native.py " gefunden.
Nur dieses Alte

und das von @robert-hh

Andreas · December 17, 2019, 10:44pm

Nativer 1-Wire/DS18B20 Treiber von Genuine MicroPython

Wir haben die Dateien bei der Beschaffung nur entsprechend benannt, damit wir wahlweise beide Varianten umschaltbar innerhalb der gleichen Codebasis betreiben können.

Das sind die richtigen, ja.

didilamken · December 17, 2019, 11:06pm

Das ist alter Code, die Änderungen von @robert-hh wg. CRC-Check sind da nicht drin.

Andreas · December 17, 2019, 11:18pm

Das ist der Python-Teil der nativen (C-Level) Implementierung des originalen MicroPython, die per Support modonewire from vanilla MicroPython by amotl · Pull Request #356 · pycom/pycom-micropython-sigfox · GitHub nun auch endlich(!) im Pycom-Universum zur Verfügung steht.

Die pure-Python Variante ist aus den bekannten und naheliegenden Gründen beim Timing Schrott – war es schon immer und wird es auch immer bleiben. Es gab bis dato halt nur nichts besseres.

Der CRC-Check passiert hier ebenfalls auf C-Level Ebene: DS18X20.read_scratch(rom) ruft per self.ow.crc8(buffer) im modonewire.c-Modul onewire_crc8(data).