TinyAVR Serie 1/2 OneWire Zugriff auf DS18B20 Temperatursensor

[Juergen H. (juergen_microcon)]

Hallo Community,

um einen digitalen Temperatursensor DS18B20 mit einer MCUs der TinyAVR 
Serie 1/2 in meinem Fall der ATtiny 1614 (habe aber auch Serie 2 ATtiny 
3216 erfolglos getestet) auszulesen verwende ich die Library OneWire 
(PaulStoffregen) in der Version 2.3.8 wie sie in vielen Beispielen 
verwendet wird. Dies funktioniert perfekt mit einem Arduino UNO R3, 
somit bin ich sicher das mein Hardwareaufbau (Speisung mit 4.7k Pullup 
Widerstand, sprich nicht parasitär) sowie die Programmierung, welche ich 
schon auf das absolute Minimum reduziert habe, in Ordnung sein muss.

Die ATtinys programmiere ich mit Arduino IDE 2.3.6 unter Verwendung von 
megaTinyCore (SpenceKonde) in der Version 2.6.10. Die Settings (Fuses) 
sind
dabei alle in Default Einstellung belassen, hatte aber auch hier in 
meiner
Verzweiflung einiges "versucht", u.a. den gleichen Takt von 16Mhz wie 
beim UNO. Soweit mir bekannt ist OneWire nicht an einen bestimmten Pin 
gebunden, habe aber auch andere probiert.

Es ist auch egal ob zum Auslesen zusätzlich die DallasTemperature 
Library
verwendet wird oder aber direkt per Register Adressierung zugegriffen 
wird.
Nach Suche im Internet gibt es anscheinend Kompatibilitätsprobleme mit 
der
OneWire Library. Daher habe ich auch andere Optionen getestet, u.a. die
OneWireNg Library (PiotrStolarz Version 0.14.0). Wie bereits erwähnt, es
funktioniert immer auf dem Klassiker UNO (ATmega328p).

Hier der kurze Testcode zur Info:

//#############################################################
//# DS18B20 OneWireBus Temperatur Sensor Demo SMALL Version   # 
//# --------------------------------------------------------- #
//# Note: Works with only one DS18B20 Type Sensor on the bus  #
//# which is in default 12 bit resolution mode.               #
//#############################################################
#include <OneWire.h>
OneWire  ds(2);                            // Create OneWire Instance

void setup(void)
{
  Serial.begin(9600);
}

void loop(void)
{
  int celsius = GetTemp();                 // get new Temperatur Value
  Serial.print("Temp = ");
  Serial.print(celsius/10);
  Serial.print(".");
  Serial.println(celsius%10);              // print one decimal place
  delay(1000);
}

//#############################################################
//# FUNCTION: Read Temperatur Value from DS18B20 via OneWire  #
//#############################################################
int GetTemp()                             // Read Temperatur Value (integer version x10 !)
{
  ds.reset();                             // Reset OneWire bus. (needed before communicating)
  ds.skip();                              // Select OneWire device by skip (all, works only with 1 sensor)
  ds.write(0x44, 0);                      // write command to start conversion, with no parasite power(0)
  delay(800);                             // wait before next command (12bit res takes 750ms con. time) 
  ds.reset();                             // Reset again
  ds.skip();                              // Select OneWire device again
  ds.write(0xBE);                         // write command to read Scratchpad
  
  byte data[9];                           // byte array to hold read data 
  ds.read_bytes(data, 9);                 // Read 9 bytes of data from sensor

  if (!(OneWire::crc8(data, 8) == data[8])) return 999;  // Data CRC is invalid return 99.9 °C
  int16_t raw = (data[1] << 8) | data[0]; // Convert the data to integer temperature value
  return (raw * 10) / 16;                 // return as integer value xx.x (%10 for decimal place)
}

Es müsste doch mittlerweile jemand eine funktionierde OneWire Library 
für die neuen ATtinys entwickelt haben, die Serie (1/2) ist ja schon 
einige Jahre verfügbar und anscheinend beliebt. Bevor ich nun analoge 
Temperatursensoren (LM35 DZ) einsetzte würde ich gern in Erfahrung 
bringen ob es vielleicht nicht doch möglich ist OneWire auf der TinyAVR 
Serie 1/2 zu realisieren.

Vielen Dank und Grüße

Jürgen

[Frank K. (fchk)]

Juergen H. schrieb:

> Es müsste doch mittlerweile jemand eine funktionierde OneWire Library
> für die neuen ATtinys entwickelt haben, die Serie (1/2) ist ja schon
> einige Jahre verfügbar und anscheinend beliebt. Bevor ich nun analoge
> Temperatursensoren (LM35 DZ) einsetzte würde ich gern in Erfahrung
> bringen ob es vielleicht nicht doch möglich ist OneWire auf der TinyAVR
> Serie 1/2 zu realisieren.

Früher haben wir das alles selber gemacht. Schau hier:
https://www.analog.com/en/resources/technical-articles/using-a-uart-to-implement-a-1wire-bus-master.html

Download des Quellcodes:
https://www.analog.com/en/resources/evaluation-hardware-and-software/embedded-development-software/software-download.html?swpart=SFW0014780B

Solange Du einen freien UART hast, ist das schwierige, nämlich das 
Erzeugen des Bittimings, damir erledigt. Der Rest ist nur noch 
Runterprogrammieren des Datenblatts.

fchk

[Volker B. (Firma: L-E-A) (vobs)]

Juergen H. schrieb:

> Es müsste doch mittlerweile jemand eine funktionierde OneWire Library
> für die neuen ATtinys entwickelt haben, die Serie (1/2) ist ja schon

Ja, Microchip, siehe:
https://www.microchip.com/en-us/application-notes/an2658

...aber es gibt wohl keine dieser lustigen Arduino Plug&Play "Libs". 
Hier ist vermutlich "Selberdenken" gefordert.

Grüßle,
Volker

[Veit D. (devil-elec)]

Hallo,

nimm eine ältere OneWire Version oder lies hier was zu tun ist.
https://github.com/PaulStoffregen/OneWire/pull/94
Das Thema ist schon länger bekannt, es gibt mehrere Anfragen zum Thema 
und es betrifft nicht nur die ATtiny Serie. Leider verweigert Paul stur 
ein Update.

[Juergen H. (juergen_microcon)]

Erstmal Danke an alle für die Antworten.

Über das Thema mit dem USART in One-Wire Mode, bzw. eine eigene Funktion 
dafür zu Entwerfen bin ich auch schon gestopltert aber meine Kenntnisse 
sind noch nicht so tief das ich das jetzt schon hinbekomme.

Auch war vermutlich zu voreilig, bzw. habe nicht mit soetwas gerechnet, 
denn die Platine für mein Projekt ist schon fertig aus China gefliefert 
und somit keine seriellen Pins mehr frei (da hängt bereits das LCD per 
I2C dran).

Aber ich teste auf jeden Fall mal eine ältere Version der OneWire Lib 
und versuche ansonsten eine sogenannte BitBang Eigenversion sofern ich 
dem Beispiel Code durchblicke.

Grüße
Jürgen

[Loco M. (loco)]

Veit D. schrieb:
> nimm eine ältere OneWire Version oder lies hier was zu tun ist.
> https://github.com/PaulStoffregen/OneWire/pull/94
> Das Thema ist schon länger bekannt, es gibt mehrere Anfragen zum Thema
> und es betrifft nicht nur die ATtiny Serie. Leider verweigert Paul stur
> ein Update.

@Juergen H.
Wenn ich die Kommentare bei github richtig interpretiere, hat Spence 
Konde deshalb ein Fork von Pauls OneWire Library angelegt, und dort die 
Unterstützung für die neueren Tinys implementiert. Ob das wie gewünscht 
funktioniert weiß ich nicht, aber du kannst die Lib ja mal testen:

 https://github.com/SpenceKonde/OneWire

[Veit D. (devil-elec)]

Hallo,

die Änderung funktioniert mit meinem AVRxDB wunderbar. Soviel kann ich 
sagen. Eine ältere Version funktioniert auch. Man hat die freie Auswahl. 
:-)

[Juergen H. (juergen_microcon)]

Hallo miteinander,

wow ich bin neu hier aber das ich selbst als Newbie chon so viel 
Unterstützung erhalte finde ich echt super, Dankschön an alle!

Dank den Anreizen habe ich gerade begonnen die alten Versionen zu 
installieren und hatte nun einen durchschlagenden Erfolg. Zwar nicht mit 
einer älteren Version (ich kann in der Arduino IDE wählen zwischen 2.30 
bis 2.38), diese gingen alle nicht.
ABER: Mir ist aufgefallen das die OneWireNg Library (in der Version 
OneWireNg-0.14.0) welche ich bereits getestet hatte bei mir so nie 
funktionieren konnte da der Header den exakt gleichen Namen hat. Erst 
nachdem die OneWire von Spence komplett deinstalliert war hat der 
Compiler auch die OneWireNg herangezogen und siehe da, es funktioniert.

Damit ist mir erst einmal geholfen, vielen Dank.

Jürgen

[Juergen H. (juergen_microcon)]

Zur Ergänzung will ich noch hinzufügen das die Modifizierung der Spence 
OneWire Library (wie in "Add support for new ATTiny MCUs #98") 
beschrieben tatsächlich funktioniert.

Hatte mir die Mühe gemacht auch diesen Vorschlag umzusetzen da in einem 
Kommentar irgendwo erwähnt wurde das diese besser ist als die OneWireNg 
(zumindest sehe ich einen großen Unterschied beim Speicherbedarf was ja 
nicht unerheblich ist bei den Tinys).

Grüße
Jürgen

[Peter D. (peda)]

Hier mal mein 1W-Lib.
Sie braucht nur einen Timerinterrupt, sollte also leicht an andere µCs 
anzupassen sein.

Beitrag "DS18B20 mit Interrupt, AVR-GCC"

[Peter D. (peda)]

Juergen H. schrieb:
> die Serie (1/2) ist ja schon
> einige Jahre verfügbar und anscheinend beliebt.

Das Problem ist nur, warum sollte man ohne Not ständig immer dem 
neuesten nachjagen, wenn die bewährten AVRs doch voll und ganz ihre 
Aufgaben erfüllen.
So epochal sind die Erweiterungen ja nicht. Allerdings wurde vieles 
komplett umgestellt (Timer usw.), so daß man einen ganzen Rattenschwanz 
an Umbauten seiner Libs benötigt. Und Zeit ist ja bekanntlich auch Geld.

Auch hat sich Microchip keinen Gefallen damit getan, ständig neue 
Familien mit minimalsten Änderungen (tiny 0, 1, 2 usw.) rauszubringen. 
Das hat die Nutzer zutiefst verunsichert, worauf sie nun setzen sollen. 
Daher bleiben sie erstmal beim Bewährten.

Und hast Du mal überlegt, wie teuer im industriellen Umfeld die 
Einrichtung eines neue Bauteils in der Lagerverwaltung ist. Sowas macht 
keine Firma mal eben nur so zum Spaß.

Ich kann mich noch gut erinnern, wie Intel und Phillips versuchten, den 
8051 auf 16Bit zu pimpen. Den 8051 gibt es immer noch von vielen 
Herstellern. Die 80C251 und 80C51XA kennt kaum noch jemand und werden 
wohl auch nicht mehr produziert.
https://www.keil.com/dd/docs/datashts/intel/8xc251sx_um.pdf
https://docs.rs-online.com/788c/0900766b80025448.pdf


Der 80C51XA hat schon nette Sachen gehabt, die man sich auch beim AVR 
gut vorstellen könnte:
fast 16 × 16 multiply and 32/16 divide

[900ss (900ss)]

Peter D. schrieb:
> Sie braucht nur einen Timerinterrupt

Was ist, wenn an anderer Stelle die Interrupts disabled werden müssen? 
Das zerreißt je nach Dauer vom disable das Timing und irgendwann 
funktioniert es nicht mehr. Wie geht ihr damit um? HW-1Wire verwenden?

Da wird die Lösung mit UART vermutlich besser sein wenn man denn einen 
übrig hat. Hab mir das nicht angesehen.

[Peter D. (peda)]

900ss schrieb:
> Was ist, wenn an anderer Stelle die Interrupts disabled werden müssen?

Steht im Text. Der 1W-Timerinterupt darf nur bis ~60µs gesperrt sein, 
das sind bei 16MHz immerhin ~1000 CPU-Takte für andere Interrupts. 
50..200 Zyklen für Interrupts ist in der Regel kein Hexenwerk. Und 
atomare Zugriffe brauchen selten >10 Zyklen.
Oder man macht super extrem lange Sperren in den Meßpausen. Zu schnelle 
Wandlungen führen ja eh zu Fehlern durch die Eigenerwärmung des Sensors.
Die Meßpause muß man ja nicht den 1W-Interrupt mitmachen lassen.

[900ss (900ss)]

Peter D. schrieb:
> Der 1W-Timerinterupt darf nur bis ~60µs gesperrt sein, das sind bei
> 16MHz immerhin ~1000 CPU-Takte für andere Interrupts. 50..200 Zyklen für
> Interrupts ist in der Regel kein Hexenwerk.

OK, das wird für viele Fälle dann funktionieren.
Danke für die Aufklärung

.

Peter D. schrieb:
> Die Meßpause muß man ja nicht den 1W-Interrupt mitmachen lassen.

Nein, wahrlich nicht ;)

[Peter D. (peda)]

900ss schrieb:
> Peter D. schrieb:
>> Die Meßpause muß man ja nicht den 1W-Interrupt mitmachen lassen.
>
> Nein, wahrlich nicht ;)

Wäre aber auch kein Beinbruch. Man könnte einfach onwi.delay abtesten, 
ob die Wartezeit noch läuft. Selbst bei superlangen Interruptsperren 
wartet man dann eben x * 100ms länger.

[Juergen H. (juergen_microcon)]

Peter D. schrieb:
> So epochal sind die Erweiterungen ja nicht. Allerdings wurde vieles
> komplett umgestellt (Timer usw.), so daß man einen ganzen Rattenschwanz
> an Umbauten seiner Libs benötigt. Und Zeit ist ja bekanntlich auch Geld.

Hallo Peter,
unter dem Aspekt gebe ich dir natürlich recht und eigentlich bin ich 
auch eher "Old-School" aber mich haben die neuen Tinys letzendlich doch 
begeistet da sie für meine Anforderungen einige Vorteile mitbringen, 
dafür hatte ich sogar meine Werkstatt um SMD Löttechnik erweitert.

Epochal sind die Erweiterungen nicht aber ich finde die UPDI 
Schnittstelle welche nur einen CH340n mit minimalster Beschaltung 
erfordert was den Entwurf eigener Platinen recht einfach gestaltet und 
das auch kein exterer Ozzi benötigt wird schon lohnenswert umzusteigen. 
Ein ATtiny 3216/26 bietet gegenüber dem klassischen ATmega328P (mit dem 
ich immer noch arbeite) den gleichen Speicher bei höherem Takt und ist 
zudem noch deutlich günstig.

In wie weit diese Teile im industriellen Umfeld genutzt werden hab ich 
keinen Schimmer, hab so das Gefühl das die sind eher für 
Amatueranwendungen und uns Hobbyisten sind.

Gruß
Jürgen

[Falk B. (falk)]

Juergen H. schrieb:
> hab so das Gefühl das die sind eher für
> Amatueranwendungen und uns Hobbyisten sind.

Wenn das mal kein Irrtum ist. Glaubst du ernsthaft, daß Micochip den 
nicht ganz unwesentlichen Entwicklungsaufwand für DIESE Zielgruppe 
betreibt? Keine Sekunde! Die sind nebensächlicher als nebensächlich!

Hier gibt's auch noch eine Onewire/DS18xx Bibliothek.

Beitrag "Re: Onewire + DS18x20 Library"

[Veit D. (devil-elec)]

Hallo,

ich kann nicht nachvollziehen und ich verstehe es auch nicht, warum 
Peter seinen Kriegspfad gegen die neuen Controller so aggressiv 
fortführt. Im ARM Umfeld kommen "jede Woche" neue Controller raus mit 
minimalsten Unterschieden. Läuft auch.

[Ob S. (Firma: 1984now) (observer)]

Veit D. schrieb:

> ich kann nicht nachvollziehen und ich verstehe es auch nicht, warum
> Peter seinen Kriegspfad gegen die neuen Controller so aggressiv
> fortführt.

Weil er faul geworden ist. Er will am liebsten immer nur seine 
liebgewordenen alten "libs" (gemeint sind natürlich: bewährte 
Codefragmente) immer weiter verwenden können.

Ich habe da durchaus ein gewisses Verständnis für, aber er übertreibt 
das wohl doch etwas.

Die neuen AVR8 haben durchaus etliche technische Vorteile gegenüber dem 
Classic-Kram aber, und insofern hat er Recht: auch einige Nachteile. Das 
betrifft weniger die Tinys, da überwiegen die Vorteile meist massiv. 
Aber bei den Megas gibt es schon einige Features, denen man nachweint.

Aber: Die neuen sind heute schon deutlich günstiger und diese 
Preisschere wird sich in Zukunft noch weiter öffnen. Das ist die 
klassische Microchip-Politik. Die kündigen nur recht selten was stumpf 
ab, vorher treiben sie lieber noch über Jahre die Preise in die Höhe.

[Peter D. (peda)]

Veit D. schrieb:
> ich verstehe es auch nicht, warum
> Peter seinen Kriegspfad gegen die neuen Controller so aggressiv
> fortführt.

Ich verstehe auch nicht, warum mit gleich ein Kriegspfad unterstellt 
wird. Man wird doch wohl seine Meinung sagen dürfen, ohne sofort 
angegriffen zu werden. Diese Aggressivität im Forum ist wirklich 
unerträglich geworden.

Es ist nunmal so, daß in Firmen neue Bauteile begründet werden müssen, 
weil damit Kosten verbunden sind (Buchung, Lagerhaltung usw.).
In den Anfängen mit µCs konnte ich relativ frei Bauteile selber 
aussuchen. Die Firma ist aber seitdem erheblich gewachsen, d.h. die 
Edelbastlerzeiten sind schon lange vorbei.
Es gibt zusätzlich den Effekt, wenn man für eine Baugruppe neue Bauteile 
verwendet, d.h. ein neues Layout erstellt, daß dann der Fertiger diese 
auch neu kalkuliert und damit der Preis erheblich ansteigt.
Bei einer Bestandsbaugruppe fallen dagegen Preisanpassungen deutlich 
moderater aus.

Ich bin ja bald in Rente, vielleicht bastele ich dann mal wieder mehr.
Der ATtiny1614 ist ja bei Reichelt recht günstig:
https://www.reichelt.de/de/de/shop/produkt/8-bit-attiny_avr-risc_mikrocontroller_16_kb_20_mhz_soic-14-349270

Oder wäre der ATtiny1604 besser?

[Falk B. (falk)]

Peter D. schrieb:
> Es gibt zusätzlich den Effekt, wenn man für eine Baugruppe neue Bauteile
> verwendet, d.h. ein neues Layout erstellt, daß dann der Fertiger diese
> auch neu kalkuliert und damit der Preis erheblich ansteigt.

Nö. Es fallen einmalige Einrichtkosten an. Der Preis der Baugruppe 
bleibt gleich, wenn die Bauteile nicht teurer werden.

[Peter D. (peda)]

Falk B. schrieb:
> Es fallen einmalige Einrichtkosten an.

Um die geht es doch gar nicht. Alle Einmalkosten sind Pillepalle.
Wenn ein Bäcker Streuselschnecken verkauft, will er möglichst lange den 
Preis beibehalten, weil die Kunden ihn ja schon kennen. Wenn er nun 
Zimtschnecken neu ins Programm nimmt, kann er den Preis frei 
kalkulieren.

Falk B. schrieb:
> Der Preis der Baugruppe
> bleibt gleich, wenn die Bauteile nicht teurer werden.

Träum weiter. Der Fertiger hat ständig steigende Kosten (Strom, Miete, 
Löhne), die er weiterreichen muß.
Bisher ist keine Baugruppe bei einer Neukalkulation günstiger geworden, 
obwohl ich die Fertigung vereinfacht habe (weniger THT, mehr SMD, 
weniger Montageaufwand, günstigere Bauteile usw.).

[Veit D. (devil-elec)]

Peter D. schrieb:
> Veit D. schrieb:
>> ich verstehe es auch nicht, warum
>> Peter seinen Kriegspfad gegen die neuen Controller so aggressiv
>> fortführt.
>
> Ich verstehe auch nicht, warum mit gleich ein Kriegspfad unterstellt
> wird. Man wird doch wohl seine Meinung sagen dürfen, ohne sofort
> angegriffen zu werden. Diese Aggressivität im Forum ist wirklich
> unerträglich geworden.

Hallo Peter,

ich fange mit dir keinen Streit an. Ich möchte weder unerträglich sein, 
noch möchte ich dich ärgern, auch nicht verärgern oder sonstwas in der 
Richtung. Ich habe nur eine Auffälligkeit niedergeschrieben, die mir 
schon länger ins Auge sticht. Diese Auffälligkeit könnte mit deinem 
Alter zu tun haben. :-) :-) :-)