1-wire Temperaturmessung mit DS18B20 für TINY2313 in C (ROM-Search-free) Das 1-wire-Protokoll an sich ist leicht verständlich - wäre da nicht die Implementation des ROM-Searchens. Das ist schwer verdauliche Kost. Dabei ist das ROM-Searchen für Temperaturmessungen nicht notwendig und kann sogar in kritischen Netzwerken der Auslöser der ersten Störungen sein. Daher wird hier ein anderer Weg zum Auslesen der DS18B20 gegangen - garantiert rom-search-free. Und hoffentlich auch verständlich dokumentiert. Das Programm benötigt weniger als 2048 Byte, somit reicht ein TINY2313 aus. Die Steuerung und die Datenausgabe erfolgt über die serielle Schnittstelle. Die Umsetzung sind wie folgt aus: 1. Die Sensoren werden zunächst einzeln an den Bus angeschlossen und per Kommando angelernt (dabei wird ihr ROM-Code im EEprom gespeichert). 2. Es ist ein Messintervall vereinbart. 3. Der Timer setzt nach dem Ablauf des Messintervalls ein Flag. 4. Bei gesetztem Flag wird ein SKIP_ROM/CONVERT an alle Sensoren geschickt. Nach ca. 800ms werden die Sensoren einzeln mit ihrer ROM-Adresse angesprochen, ihr Scratchpad ausgelesen, die CRC geprüft und die Temperatur in lesbarer Form via RS232 ausgegeben. Weiter geht's dann mit 3). Mit einem TINY2313 sind bis zu 15 Sensoren anlernbar. Bei einem Umzug auf einen ATMEGA48/88 kann man die Zahl der Sensoren auf 63 erhöhen - und hat genug Pins und Flash frei, um ein LCD anzusteuern. Einige weitere Hinweise gibt's in der beigefügten readme.pdf. Viel Spaß beim Messen, Michael S.
Genial! Beim Tausch eines Sensors sind alle anderen abzuklemmen und neu Anzulernen. Endlich mal eine sinnvolle Beschäftigung die sich nicht in Software erledigen lässt.
@klaus, wenn du über eine funktionierende Lösung verfügst und dich andere Ansätze nicht interessieren, dann ignoriere diese Ansätze doch einfach. Sollte dir an einem anderen Ansatz ein Haken aufgefallen sein, dann kannst du das im Sinne von konstruktiver Kritik gerne einbringen. Zu deinem Einwand: Um einen Sensor zu tauschen, ziehe ich den alten ab und lerne einen neuen an: Dazu trenne ich den Bus (mit den x anderen Sensoren) am Controller, verbinde den neuen Sensor mit dem Controller ... und stecke den Bus wieder an. Dann tausche ich die beiden Sensoren aus. Alle Sensoren müsste ich allenfalls dann neu anmelden, wenn das Eeprom bereits voll ist. Andererseits ist dein Problem keines, das sich mir gestellt hat oder sich mir stellen wird. Würde es sich mir stellen, dann würde ich wenige Zeilen Code ergänzen, so dass der ROM-Code eines neu angelernten Sensors den ROM-Code des auszutauschenden Sensors überschreibt. Oder ich würde das Eeprom patchen. Lösungen findet man immer, naja meistens - wenn man will. Im Übrigen muss der Schritt einer eindeutigen Identifikation eines Sensors in jeder Lösung erfolgen - dieses Problem löst ja das ROM-Searchen nicht. Ob ich dazu den ROM-Code verwende oder etwas, was ich manuell in ein Register des Sensor einschreiben muss, das erscheint mir zunächst gleichgültig. Wobei der ROM-Code sich einfach anbietet: er ist definitiv eindeutig und ausserdem bereits vorhanden. Aber wie wir wissen, führen viele Wege nach Rom. Ich wollte einfach mal die Autobahn verlassen ... Michael S.
Die beiden vergangenen, frostigen Nächte haben es ans Tageslicht gezerrt: Ich habe die Routine zur Konvertierung der Temperaturwerte nicht bei negativen Temperaturen getestet ... Und schon findet sich ein Fehler (die Sign-Bits sind nicht vollständig ausgewertet). Als Anlage die korrigierten Dateien - und diesmal mit einem separaten Testprogramm für die Temperaturkonvertierung. Michael S.
Tolles Projekt, tolle Beschreibung! Würdest du einem " nicht C Programmierer " das Hex-File und die Fuse-Bit Einstellung zur Verfügung stellen? Vielen Dank für die Mühe
Michael S. schrieb: > Das 1-wire-Protokoll an sich ist leicht verständlich - wäre da nicht die > Implementation des ROM-Searchens. Das ist schwer verdauliche Kost. Nö, so schlimm ist das überhaupt nicht. Sag einfach mal, was Du daran nicht verstehst. Fragen kostet nichts. Peter
Achja, einen kleinen Test für die Leserschaft hatte ich noch eingebaut: - als Nachkommastelle wird immer '0' ausgegeben. Die Auflösung des Rätsels: Datei: owi_lib.c, DS18B20_convert_temperatur() anstelle 186: ow_buffer[0] &= 0x0F; 187: temp16 += (int16_t)(ow_buffer[0] & 0xF0) * 640 / 1024; muss es lauten: entweder 186: ow_buffer[0] &= 0x0F; 187: temp16 += (int16_t) ow_buffer[0] * 640 / 1024; oder 186: entfällt 187: temp16 += (int16_t)(ow_buffer[0] & 0x0F) * 640 / 1024; In der Bitmaske ist einerseits ein Verdreher (0xFO statt 0x0F), andererseits ist eine zweifache Maskierung natürlich überflüssig. Wer sich das Archiv 'test.zip angesehen hat, der wird dort die Lösung bereits gefunden haben. Zugegeben: Das Problem ist entstanden, Weil das SRAM im TINY2313 wieder mal knapp wurde. Daher habe ich unterschiedliche Formulierungen ausprobiert um zu sehen, ob sich dadurch der Codeumfang verkleinert. Der Versuch, die Berechnung '* 640 / 1024', durch eine Tabelle zu ersetzen, war unter diesem Aspekt kontraproduktiv. Am Ende habe ich die Tests nicht sauber entfernt - und noch einen Verdreher eingebaut. Michael S.
@ Peter Dannegger, 'schlimm' ist natürlich ein sehr relativer Begriff. Auf mein Niveau bezogen ist die Implementation des ROM-Searchens schwer verständlich. Nicht das Prinzip - das ist nachvollziehbar und erscheint genial. Auffällig ist, dass Maxim in zahlreichen App-Notes und auf vielen, vielen Seiten versucht, der Kundschaft die Lösung des ROM-Searchens zu verklickern. Warum die vielen Worte, wenn der Inhalt doch so trivial sein soll ??? Wenn ich mir etwa in der AN187.pdf die das ROM-Searchen erläuternden Flussdiagramme ansehe, dann muss ich erst einmal tief Luft holen. Und traue mir nicht so ohne weiteres zu, diese Logik in ein (wirklich funktionierendes) Programm umzusetzen. Aber warum sollte ich derart komplizierte Wege gehen, wenn das Ziel auf einfacher, verständlicher und überprüfbarer Weise erreichbar ist ? Eben darum habe ich auf das ROM-Searchen verzichtet. mfg Michael S.
@ Helmut(Gast) hier ist das gewünschte hex-file. Was man nicht sehen kann ist, dass die Kommandos 0x60/0x70 im Programmcode auskommentiert sind (das SRAM auf dem TINY2313 reichte nicht aus). Die Fuse-Bits sind so gesetzt, dass der Controller mit einem XTAL (3.686400 MHz) zusammenarbeitet. Vielleicht noch das Bit/die Bits für die Brown Out Detection setzen. Michael S.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.