Warum meinst Du, so viel Assembler benutzen zu müssen?

Warum machst Du Dir über die Lebensdauer sorgen? Die hinterfragst Du doch auch nicht beim Mikrocontroller oder einer Leuchtdiode.

Zum Timing hat Michael ja schon oft genug geschrieben, dass man die Messung anstößt, dann tausend andere Dinge abarbeiten lassen kann und dann den Messwert vom Sensor abholen kann. Man sollte also nicht warten.
Synchronisation 7 Segment Anz. mit 1Wire Sensor 18B20

„Skip Rom [CCh]
The master can use this command to address all devices on the bus simultaneously without sending out any ROM code information. For example, the master can make all DS18B20s on the bus perform simultaneous temperature conversions by issuing a Skip ROM command followed by a Convert T [44h] command.“

Das Datenblatt dieser Temperatursensoren zu lesen und zu verstehen dürfte nicht schwierig sein. In diesem kleinen Gehäuse sitzt eine gute Elektronik, die per wenigen Befehlen angesprochen werden. Die Logik dürfte auch zu verstehen sein. Jedes Kommando beginnt mit 1wreset, womit die Signalleitung für ein exaktes Timing auf Low gezogen wird. Dieses Low ist für die interne Elektronik die Startsequenz, um das nächste Kommando einzulesen und zu verarbeiten. Diese ROM-Kommandos sind in dem Datenblatt ausführlich beschrieben.

Kommando CC (Hex) leitet die Temperaturmessung ein, die nach Abschluss der Messung im Scratchpad zur weiteren Verfügung abgelegt wird. Somit muss es entsprechende Kommandos geben, um diesen Temperaturwert lesen zu können. Falls es mehrere Sensoren gibt, können die über die jeweils einmalige ROM-ID unterschieden werden, also den betreffenden Sensor zum lesen exakt selektiert werden über seine ROM-ID. Oder wenn man in die entsprechenden Scratchpad- Stellen (2e) eine Kennung programiert hat, über diese Option.

Ab beauftragung einer Messung liegt dieser Messwert bis zur Abholung im Scratchpad. Eine Messung und Abholung im Sekundentakt ist meistens nicht nötig und zudem nicht sinnvoll.
Nicht sinnvoll, weil bei sekündlichen Betrieb die interne Elektronik bis zu 1,5 Grad wärmer werden kann. Bedeutet, dann ist die Messgenauigkeit nicht mehr optimal, wegen interner Eigenerwärmung.

Bezüglich Erfahrung: Ich verwende diese DS18B20 seit über 10 Jahren in Anwendungen in denen es von nur einem bis zu 12 Sensoren an diesem einen Pin betrieben werden.
In einem Fall habe ich sogar Mischbetrieb mit direkter Spannungsversorgung und dieser Sparversorgung gemixt. Zwei Sensoren werden sogar über Telefonkabel bis zu 35 Meter Länge betrieben.
Ich hatte bisher mit keinem einzigen Sensor irgendwelche Probleme, sie sind sehr zuverlässig.
Sie sind betreibbar von 3,0 V bis 5 V. In meinem Mischbetrieb in dem die längste Kabellänge rund 36 Meter beträgt, habe ich ein Poti eingesetzt, das die Versorgungsspannung auf 3,8 V reduziert.
Damit läuft es seit angegebenen Jahren problemlos.

Wenn es eine Uhr im System gibt, könnte diese benutzt werden um nur alle 4,23 Minuten den Temperaturwert, bzw je nach zeitlichem Messbedarf abholen. Sekündlich muss es sehr selten sein.

Also bei mir ist einer im Garten vergaben (Bodentemperatur) seit 8 Jahren kein Mangel.
Läuft mit 5V

Es ist doch eindeutig im Datenblatt beschrieben, wenn man den Messwert mit 12 Bit Genauigkeit haben will benötigt Temperatur convert 750 ms. Wer diese Stellen hinter dem Komma nicht benötigt, kann die Genauigkeit auf 9 Bit reduzieren. Dann ist Temperatur convert in 94 mS erledigt. Wenn Dir der Messwert mit einer Stelle hinter dem Komma also z.B. 18,5 bzw 18,0 Grad genügen, dann programiere das Scratchpad mit den Config-Bits auf Betriebsart 9 Bit Genauigkeit und du könntest ab dann alle 0,1 Sekunden messen.
Lasse dich nicht verwirren, nach dem Komando $44 ist der 1WireBus auf Low, bis der Messwert convertiert ist. Danach geht der 1Wirebuspegel wieder auf Status high, das bedeutet convertierzeit abgelaufen, Messwert verfügbar.

Da Du ohnehin gerne in Assembler programmierst könntest du dich mit Hilfe des Datenblattes regelrecht austoben! Dieser Lowpegel nach Kommando $44 bedeutet, Device is busy.
Welche Minzeiten für 1wirereset zu beachten sind und sonstige Pegelzeiten sind super im Datenblatt beschrieben und sehr zuverlässig, für Personen die gerne per Assembler programmieren.

Das Poti habe ich verwendet, weil gemischter Spannungsbetrieb und gleichzeitig sehr kurze und lange Leitung (bis 36 m) zu unkorrekten Tempwerten führten. Hatte keinen Mosfet für parasite Powerbetrieb verfügbar, sonst hätte ich das angewendet.

Du darfst dich an diesem tollen und zuverlässigen Device mal so richtig per Assembler austoben, wird dir sicherlich Spaß machen. Ich hatte dazu keine Lust und mir genügen Messwerte alle 254 Sekunden, was bekanntlich als Zahlenwert in ein Byte (for Sekunden-Timer) passt.
Der Messbereich passt für die meisten Anwendungen, folglich ist dieses Device eine sehr gute Entwicklung.
Viel Spaß damit.

Grundsätzlich ist es immer eine schlechte Idee, zeitkritische Protokolle wie 1Wire, die im Direktmode (ohne Interrupt) laufen, und auch dafür vorgesehen sind, durch Interrupts zu unterbrechen. Die Timeslots von 1Wire sind im µs Bereich (15µs bis 460µs), da darf eine Interrupt-Routine nicht trödeln. Sonst führt das schnell zu Fehlern bei der Übertragung. Das hast du ja selber gemerkt.

Eine Möglichkeit ist, zu einem Zeitpunkt x die Conversation des DS1820 zu starten, und sich während der Wandlung um andere Sachen zu kümmern.
Die 700ms sind eben Systembedingt, die der Sensor braucht, um die Daten zu wandeln. Soll es schneller gehen, musst du einen anderen Sensor nehmen.
Aber zurück zum Sensor. Ist die Wandlung gestartet, kann man sich um andere Dinge kümmern.
Und bei jedem Durchlauf in der Hauptschleife einfach mal den 1W-Data-Pegel prüfen, ob der high ist. Wenn ja, dann kannst du die Daten holen.
Das sollte auch mit mehreren Sensoren funktionieren an einem Bus. Der langsamste Sensor bestimmt dann eben, wann das Signal wieder High wird.

Während dem Lesen oder Schreiben des Sensors sollten allerdings keine Interrupts laufen.

Wenn du da parallel noch den Empfang eines Uarts überwachen willst, haben wir das Problem auch, dass das Timing an 1Wire Bus durcheinander kommt, sobald Daten reinkommen.
Da hängt es jetzt von der Anwendung ab, ob man das aneinander vorbei bekommt. Hardware-Uart ist hierbei nach meiner Meinung Pflicht. Und ein Empfangsbuffer bietet sich auch an. Trotzdem kann es zu Problemen kommen.

Daher wenn irgend möglich, diese beiden Dinge abwechselnd machen (1Wire und UART oder andere Interrupts)

Man kann aber auch mal über den Tellerrand rausschauen und überlegen, ob man den 1Wire Betrieb auch Interrupt gesteuert hinbekommen kann.
Aufgrund der kurzen Zeiten bei 1Wire müssten die Interrupt-Routinen kurz und schnell, also in Assembler sein. Gleiches gilt auch für den UART, wenn man den gleichzeitig nutzen will. Hierbei kommt einem ein hoher Takt des Controllers zu gute, weil das die ISR-Abarbeitung beschleunigt.

Im Übrigen könnte man auch den UART langsamer laufen lassen. Und wieso brauchst du 19600 Baud?
Ich kenne 19200 Baud als typische Baudrate.

Was das Managen der Sensoren am Bus angeht, gibt es auch Möglichkeiten.

Jeden Sensor an einen Controller-Pin legen. Das ist einfach in der Zuordnung des Sensors zu einem Kanal und man kann den Code einfacher halten.
Denn man muss sich keine ROM-Codes merken.

Meist ist das aber nicht gewünscht, weil man dann immer für die maximale Anzahl Sensoren die Pins vorhalten muss.

Und da kommt wieder der 1W-Bus ins Spiel
Was man braucht ist nicht nur eine Zuordnung der Sensoren mit dem ROM-Code, sondern auch eine Zuordnung für den Benutzer.

Man will ja einfach die Sensoren anschließen und dann die Zuordnung der Kanäle machen, ohne auf den ROM-Code zu achten (als Benutzer)

Lösen kann man das z.B. folgendermaßen.
Man steckt einen Sensor an und weist den Controller an, alle bisherigen Sensoren zu vergessen.
Dann soll er eine Sensorsuche machen.
Er merkt sich den ROM-Code und weist dem den Kanal 1 zu (Array).
Wenn nun noch ein 2. Sensor benötigt wird, wird der jetzt angeschlossen und man sagt dem Controller, er soll nach einem neuen Sensor suchen.
Findet er einen neuen (Nicht in der ROM-Code Liste vorhanden), bekommt der neue Sensor den nächsten freien Kanal, Nr 2 zugewiesen.
Das Spielchen kann man so weiter treiben und ist nicht auf eine Sensoren-Anzahl begrenzt und brauch nur ein Pin.

Diese ROM-Code Liste und die Kanal-zuweisung, wenn sie fertig erstellt ist, kann im EEProm gespeichert werden.
Solange man die Sensoren nicht umsteckt kann der Kontroller bei einem Reset diese Zuordnung wieder verwendet.

Hat man eine andere Applikation, braucht wieder ein neues Set an Sensoren, löscht man die interne Sensor- und Kanal-Liste und entfernt alle Sensoren bis auf den, der Kanal 1 repräsentieren soll, und sucht nach neuen Sensoren.

Also wie oben beschrieben werden dann weitere Sensoren zugeordnet.

Auf diese weise ist es auch möglich, wenn mal ein Sensor defekt geht, diese Liste dynamisch neu zu erstellen. Aber auch neue Sensoren hinzuzufügen.

Wer denkt, man kann jetzt einfach die Stecker beschriften, der hat bedingt recht. Dumm nur, wenn ein Sensor ersetzt werden muss, welcher ROM-Code gehört zu dem? Das ist dann alles irgend wie nichts ganzes und nix halbes.

Eine ordentliche Anwendung hat in der Regel sowieso ein Display und Tasten, da kann man das ja per Menü abvespern und das ganze am jeweiligen Ort anpassen.

Jeder wie er mag.

Es war eine Anregung, weil ich genau mal vor diesem Problem stand.

Heute brauche ich 3 Sensoren, Dann wird alles aufgeräumt.

Ne woche später bauche ich 12 Sensoren.

Ach und welcher Sensor war Kanal 1 usw?

Ich brauchte das flexiebles.

Wie habe ich das mit meinen Sensoren gemacht. Ich habe immer ein System zum testen, an dem ein 20X4 Display angeschlossen ist. Daran sind allerlei Sensoren anzuschließen, mithin auch diese 1Wire-Sensoren. Das jeweils benötigte Programmteil lässt sich einspielen. Somit gibt es eines das die ROM-ID liest und anzeigt. Diese notiere ich in einer DS18b20 Liste und füge da entweder eine
Nummer hinzu, oder ein 2stelliges Kürzel. Kürzel z.B. VL, RL, AT, WZ, FB usw für die Sensoren der Heizung. Um den Sensor kommt ein Aufkleber am Kabelende, auf dem die Nummer oder das Kürzel steht.
In das Userbyte 1 und Userbyte 2 programmiere ich entweder die Sensornummer, oder das entsprechende Kürzel und übertrage es noch in das Eprom vom Sensor.
Sensoren die als Reserve in einem Behältnis liegen, sind somit bereits vor einer Verwendung gekennzeichnet.

Anzusprechen ist ein Sensor somit über die ROM-Match Funktion, oder nach dem auslesen des Temperaturwertes per Userbyte 1 und 2 zuortbar.

Seit etwa 20 Jahren sind die Teile bei mir verbaut, im Keller 4 Stück, im Pool, im Gartenteich 3 Stück, im Dachboden (Drempel), im Gartenhaus. Es ging noch kein einziger davon kaputt. Das einzig negative war, das ich mal Fälschungen erwischt hatte in einem Shop.
Ansonsten laufen die auch sehr gut am ESP+DS2480B via WLAN, da können diese seriell angesprochen werden. Im Garten ganz nett, wenn man nicht überall Kabel hat.

Die funktionieren nicht wie die Originale: github.com/cpetrich/counterfeit_DS18B20

Mein letzten Fehlkauf hatte ich mit DS2480B - da hatten mir die Burschen einfache Mosfets untergeschoben…



Ich habe die Sensoren (Kabel) mit Etiketten beschriftet und habe eine Liste, dann kopiere ich den Kram in den Quelltext bei Bedarf.
(Ursprünglich habe ich mit C und Assembler angefangen die AVR zu bespielen. Erst dann kam ich durch Zufall zu BASCOM, dabei blieb es dann auch bis heute - Assembler nutze ich nur noch, um Platz/Geschwindigkeit zu schaffen)