Hallo Zusammen,
ich habe ein kleineres Problem mit meinem ATMega8 und den 1Wire Sensoren
DS1820.
Mit 1 - 3 Sensoren läuft alles prima, ich kann über SEARCH_ROM
adressieren und auch Temperatur auslesen.
ab 4 geht das irgendwie nicht mehr richtig.. er findet bei der Suche
dann nur noch 2 Sensoren auch wenn 5 oder mehr dran sind ...
Ich habe auch so ziemlich alle Kombinationen von Sensoren mal
miteinander ausprobiert - verhalten immer gleich - sodass ich nahezu
auszuschließen kann das es möglicherweise an einem defekten Sensor
liegt.
Zur Hardware:
ich habe verschiedene Pullups zwischen VCC und Datenbein versucht (ich
arbeite mit 3 Leitungen - KEIN PARASIT POWER), dass hatte ich in einem
Beitrag gelesen, dass bei längeren Leitungen und mehreren Sensoren ein
kleinerer Widerstand 2 kOhm das Problem beheben könnte.
War aber leider nicht so.
Zur Software/Firmware:
ich habe eine allseits bekannte 1wire Implementierung (siehe unten), an
1,8432 MHZ, und habe dort bereits am Timing in der w1_bit_io Routine
verschiedene Werte (von 10-15) ausprobiert.
ldi a1, 15 * xtal 1000000 3
ldi a1, 9 * xtal 1000000 3
...
Nichts zu machen ...
hat jemand noch Ideen woran es liegen kann?
Cheers Jens
Hier der 1Wire Code (in großen Teilen von Peter Dannegger):
Hallo,
ich durchblicke den ROM Search nicht. Aber ich habe vor kurzen das ganze
in c geschrieben und wenn mehre sensoren vorhanden sind, dann ist das
suche nicht mehr ganz trivial. ich vermute du hast ein Problem bei der
auswertung. Wenn muss ja immer die letzte Position merken wo man
zwischen 0 und 1 entscheiden muss.
Ich hatte für den code ewig gebraucht und er sieht selbst in C
wesentlich komplexer aus als dein ASM code. Entweder habe ich es mir zu
kompliziert gemacht oder du hast es dir zu einfach gemacht.
Nachtrag:
mann muss ich auch immer merken bei welchen Bits man schon die
entscheidung getroffen hat. Es hilft also nicht zu sagen das man jetzt
beim 5Bit eine 1 senden soll, dafür muss man auch wissen das man beim
2.Bit auch schon ein 1 Setzen muss.
Hallo Jens,
versuch's mal mit einem 10O Ohm Widerstand jeweils in den DQ-Leitungen.
Den Hinweis habe ich in irgendeiner App-Note gefunden
- und er hat bei mir ähnliche Probleme behoben.
mfg
Michael S.
Jens Straube schrieb:> ich habe eine allseits bekannte 1wire Implementierung (siehe unten), an> 1,8432 MHZ
Man sollte die Stromsparwut nicht übertreiben.
Das 1-wire Timing ist recht fix, da sollte man der CPU noch Luft zum
Atmen lassen.
Der ATmega kann doch bis 16MHz, als Baudratenquarz sind da 11,0592 oder
14,7456MHz geeignet.
Und die 15µs sind der Maximalwert, nimm besser 10µs.
Wenn Du Strom sparen willst, gehe einfach in Power Down.
Und dann alle Minute eine Messung sollte dicke reichen.
Peter
Peter Dannegger schrieb:> Peter schrieb:>> ich durchblicke den ROM Search nicht.>> Liegt wohl auch daran, daß der OP zu faul ist, die Postingregeln zu> lesen.> *Formatierung*>> Peter
Habe das mal "gefixt"...
Hallo Zusammen,
vielen dank für die Antworten ... Stromsparen ist eigentlich nicht mein
Ziel bei der Wahl des Quarzes gewesen ... habe noch 4,irgendwas MHZ und
11,irgendwas MHZ rumliegen, daher lässt sich das ändern ...
Allerdings passts dann nicht mehr beim Reset mit nur einer Zählvariable,
denn
ldi a1, 480 * xtal 1000000 9 bei xtal > 4 passt glaub ich nicht
mehr in ein Byte habt ihr da ne Lösung (Y-Register)?
Auch den 100 Ohm Widerstand werde ich checken ....danke für den Tip.
Zu meinem Posting-Fehler, sorry, tut mir Leid, hilfreich wäre hier neben
der berechtigten Kritik auch ein kleiner Hinweis zum besser machen
gewesen ...
Cheers Jens
@Michael S. was meinst du mit jeweils?
ich habe in DER Datenleitung EINEN Widerstand - ist das nicht ok?
Sollte ich für jeden DS einen Pullup ran hängen ?
Das heist mit jedem weiteren würde sich dann der Gesamtwiderstand gegen
Vcc reduzieren.
Hallo Jens,
ich betrachte die drei (Zu-)Leitungen als Bus.
Immer wenn ich einen Sensor daran anschließe, füge ich in die DQ-Leitung
einen 100 Ohm Widerstand ein.
Die Widerstandswerte addieren sich also nicht bei vielen Sensoren.
Der Hinweis ist übrigens ein Schuss ins Blaue.
Ich hatte das Problem, dass viele Sensoren auf dem Steckbrett
hintereinander aufgereiht funktionierten.
Sobald ich dieselben Sensoren an der "langen Leine" hatte, gab es
Ausfälle.
Nach dem Einfügen der Widerstände tauchte das Problem nicht mehr auf.
Michael S.
PS.
Wozu benötigt man eigentlich dieses ROM-Search ?
Das ist doch eigentlich überflüssig wie ein Kropf.
Wenn ich die Sensoren einmalig dem System bekannt mache (d.h. ihre
ROM-Codes registriere), dann kann ich anschließend jeden Sensor mit
seinem Namen ansprechen.
Hallo Peter,
gut, nehmen wir sogar einmal an, es werden gleich 2 Sensoren
ausgetauscht.
Welcher Sensor liefert dann welchen der beiden Temperaturwerte ?
Es muss doch immer eine eindeutige Zuordnung von Sensor (=Messstelle)
und Temperaturwert vorhanden sein.
Und die nehme ich vor, indem ich den ROM-Code eines Sensors auslese und
ihn über diesen ROM-Code (quasi als Namen) ansprechen.
Spinnen wir mal weiter.
Was passiert eigentlich, wenn ein Schelm zusätzliche Sensoren auf den
Bus steckt ?
Michael S.
Michael S. schrieb:> Hallo Peter,>> gut, nehmen wir sogar einmal an, es werden gleich 2 Sensoren> ausgetauscht.>> Welcher Sensor liefert dann welchen der beiden Temperaturwerte ?
Ich würde es cool finden, wenn sich dann das Programm beim Hochfahren
bei mir meldet und mir sagt, dass es Sensoren vorgefunden hat, die es
nicht kennt.
>> Es muss doch immer eine eindeutige Zuordnung von Sensor (=Messstelle)> und Temperaturwert vorhanden sein.> Und die nehme ich vor, indem ich den ROM-Code eines Sensors auslese und> ihn über diesen ROM-Code (quasi als Namen) ansprechen.
Kannst du natürlich machen.
Irgendwann mach ich das mal:
Im Programm eine Art Suchlauf installieren, bei dem das System alle
Seonsoren mit ihrem ROM-Code feststellt und sie mir in einer Liste
präsentiert.
Danach kann ich hergehen und mir einen davon aussuchen und in dieser
Liste dem einen Begriff zuordnen: zb Schlafzimmer
Dann steckich den nächsten auf den Bus, mach wieder einen Suchlauf und
in der Liste taucht ein neuer Sensor auf, der noch keinen Namen
zugeordnet bekommen hat. Dem geb ich wieder einen
usw. bis alle Sensoren identifiziert und erkannt wurden.
Vorteil: Ich brauch keine zusätzliche Software oder sonst irgendwas,
sondern kann alles mit Bordmitteln erledigen.
Im resltichen Programm wird dann natürlich überall der zugeordnete Name
benutzt, wenn eine Temperatur auszugeben ist. Eh klar.
> Was passiert eigentlich, wenn ein Schelm zusätzliche Sensoren auf den> Bus steckt ?
Ja ok.
Man kann natürlich für alles immer Fehlerszenarien postulieren. Wenn das
Programm mitteilt, dass es 2 unbekannte Sensoren gefunden hat, dann
reicht das schon. Es muss nicht automatisch wissen, dass der eine im Klo
und der andere im Treppenhaus ist.
ROM Search hat eigentlich nur einen inventarisierenden Nutzen.
Wenn man im laufenden Betrieb die IDs der Sensoren kennt, wird man
sowieso nur Match ROM einsetzen.
Man kann den ROM Search entweder vorher nach Anlieferung des Sensors an
einem PC machen und die ID anschließend dem Messsysten bekannt machen.
Beides geht natürlichh beides auch auf dem Messsystem selber.
Hallo Karl Heinz,
> Irgendwann mach ich das mal:> Im Programm eine Art Suchlauf installieren, bei dem das System alle> Seonsoren mit ihrem ROM-Code feststellt und sie mir in einer Liste> präsentiert.> Danach kann ich hergehen und mir einen davon aussuchen und in dieser> Liste dem einen Begriff zuordnen: zb Schlafzimmer
Wie soll das funktionieren, wenn mehr als 1 Sensor gefunden wurde ?
Welcher Sensor ist in welchem Zimmer eingebaut ?
Wie kann ich das erkennen ?
> Dann steckich den nächsten auf den Bus, mach wieder einen Suchlauf und> in der Liste taucht ein neuer Sensor auf, der noch keinen Namen> zugeordnet bekommen hat. Dem geb ich wieder einen> usw. bis alle Sensoren identifiziert und erkannt wurden.
Hier kann ich zustimmen.
Wenn genau ein Sensor hinzugefügt wird, dann ist mir sein Standort
bekannt.
Also - ich habe einfach Probleme mit dem ROM-Search.
Nicht mit dem Verständnis (zumindest kaum), sondern mit der
Notwendigkeit.
Irgendjemand hat das mal im Zusammenhang mit dem Auslesen von DS18B20
eingeführt - und seitdem machen alle es nach.
Als ich mich mit den Sensoren auseinandergesetzt habe, habe ich mir die
kursierenden Lösungen natürlich angesehen.
Die Verwendung des ROM-Search empfand ich als "unnatürlich".
Im normalen Leben macht man sich bekannt - und spricht sich anschließend
gezielt mit dem Namen an.
Dieser Weg erschien mir auch beim Auslesen der Sensoren als logisch und
naheliegend. Und es funktioniert.
Michael S.
Michael S. schrieb:> Wenn ich die Sensoren einmalig dem System bekannt mache (d.h. ihre> ROM-Codes registriere), dann kann ich anschließend jeden Sensor mit> seinem Namen ansprechen.
Und genau das sparst Du Dir mit dem ROM-Search ein.
Der MC muß sich nichts merken.
Es gibt nun verschiedenen Möglichkeiten:
1.
Der Nutzer steckt die Sensoren an, prüft mit dem Finger, welcher Sensor
an welcher Stelle erkannt wird und ordnet sie dann entsprechend an.
Nachteil: wenn eine Sensor ausfällt, rücken die nachfolgenden auf.
Die SW merkt aber, daß ein Sensor fehlt.
2.
Der Nutzer steckt einen Sensor an, die SW merkt daß dieser neu ist und
der Nutzer gibt ein, für welche Meßstelle dieser Sensor zugewiesen
werden soll.
Diese Nummer trägt dann die SW im EEPROM des Sensors ein.
Peter
Michael S. schrieb:>> Liste dem einen Begriff zuordnen: zb Schlafzimmer> Wie soll das funktionieren, wenn mehr als 1 Sensor gefunden wurde ?
Ich steck einen nach dem anderen an den Bus an, identifiziere ihn
> Also - ich habe einfach Probleme mit dem ROM-Search.> Nicht mit dem Verständnis (zumindest kaum), sondern mit der> Notwendigkeit.
Du gehst davon aus, dass du einen Sensor vorher in einer anderen
Schaltung einsteckst, dort den Code ausliest und dann mit Sensor und
bekanntem Code in die Zielschaltung gehst.
Das ist schon legitim.
Aber ich möchte das eigentlich nicht machen. Vor allen Dingen deshalb,
weil ich in 2 Jahren die Testschaltung nicht mehr im Abstellraum finden
werden. Ich möchte gerne den Sensor an den Bus anstecken, dem System
sagen: Such nach dem neuen Sensor und den dann ins Programm integrieren
lassen. Den Hex-Code nehm ich als notwendiges Übel in Kauf, aber
eigentlich will und muss ich mir seinen Wert gar nicht merken und den
irgendwo eintragen. Das kann das System selbst genauso gut - wenn es
nach Sensoren suchen kann.
Michael S. schrieb:> Also - ich habe einfach Probleme mit dem ROM-Search.> Nicht mit dem Verständnis (zumindest kaum), sondern mit der> Notwendigkeit.>> Irgendjemand hat das mal im Zusammenhang mit dem Auslesen von DS18B20> eingeführt - und seitdem machen alle es nach.>> Als ich mich mit den Sensoren auseinandergesetzt habe, habe ich mir die> kursierenden Lösungen natürlich angesehen.> Die Verwendung des ROM-Search empfand ich als "unnatürlich".> Im normalen Leben macht man sich bekannt - und spricht sich anschließend> gezielt mit dem Namen an.
Bei einem 1-Wire-Netzwerk ist es unmöglich, dass sich die Sensoren,
sprich, die Slaves, beim Master bekannt machen! Das ist einfach nicht
vorgesehen.
Die Sensoren antworten nur, wenn sie auch gefragt werden. In so fern ist
der Rom-Search die einzige Möglichkeit der 1-Wire-Spezifikation, alle
angeschlossenen Sensoren oder was auch immer überhaut zu finden. Diesen
dann noch Namen oder Standorte zuzuweisen, ist allein Aufgabe der
Master- oder einer aufgesetzten Software!
Die 1-Wire Sensoren haben eine feste Adresse, mit welcher Sie sich
finden lassen. Wenn man diese also nicht von Hersteller auf Papier
geliefert bekommt und seinen Master damit füttert, ist der ROM-Search
die einzige Chance, die Sache überhaupt zum laufen zu bringen.
Ich habe selber schon 1-Wire Master und Slaves geschrieben und anders
geht es einfach nicht!
Gruß,
Markus
Hallo Zusammen,
zu diesem Thema gibt jede menge Threads ...
ich für meinen Teil musste mich auch entscheiden ROM_SEARCH oder ID
Selber Auslesen.
@ Markus
Datenblat des DS1820
/
*READ ROM [33h]*
This command can only be used when there is one slave on the bus. It
allows the bus master to read the
slave’s 64-bit ROM code without using the Search ROM procedure. If this
command is used when there
is more than one slave present on the bus, a data collision will occur
when all the slaves attempt to
respond at the same time.
/
(ich hoffe die Formatierung geht ... in der Vorschau wars nicht mit
drin)
Zum Auslesen der ID reicht nämlich READ_ROM und das ist im Vergleich zu
ROM_SEARCH schnell verstanden .... funktionieren aber nur in einem BUS
mit nur einem Slave.
Egal....
der Vorteil von search_rom .. du hast alle Werte im Speicher, wenn du
einen neuen Sensor hin zusteckst, steht der - so wie ich Peters Code
verstanden habe - im Speicher ganz hinten also Ausgabe welche Id's neu
sind leicht möglich.
Zur initialen Befüllung des Systems geht das dann so:
1) einen Sensor anstecken, Reset,"letzte" ID lesen, fertig
2) zweiten Sensor anstecken, Reset, letzte ID lesen, fertig
usw. usw.
Man brauch halt keine zweite Schaltung etc.
Mittlerweile, mit der ganzen "Such" und "nicht finde"-Thematik bin ich
fast so weit die Rom's von Hand in den Speicher zu schieben.
Via zweiten Pin am uC für ROM_Auslesen reservieren und dann wie folgt:
anstecken an Pin für READ_ROM, auslesen und speichern der ID, sensor in
den eigentlichen Bus einfügen usw.
Vielleicht das Auslesen über nen Taster getriggert und gleich die ID
nicht nur in den Speicher des uC sondern auch über UART raus...
Nachteil:
einen Pin weniger für andere Dinge und das 1Wire Zeug muss Pin
unabhängig zusammen gebaut werden
Fazit:
Wenn die Sache mit dem Suchen weiter nicht hin haut, dann teste ich ob
es die selben Probleme gibt, wenn die ROM's bekannt sind und direkt
angesprochen werden und wenn das rockt
-> bye bye ROM_SEARCH
Ich schreib weiter wie's läuft ....
Cheers Jens
Hallo Karl Heinz,
> Ich steck einen nach dem anderen an den Bus an, identifiziere ihn
Aha !!
Mit einem einzelnen Sensor vereinfacht sich das Problem.
> Du gehst davon aus, dass du einen Sensor vorher in einer anderen> Schaltung einsteckst, dort den Code ausliest und dann mit Sensor und> bekanntem Code in die Zielschaltung gehst.
Nein, etwas eleganter habe ich das schon gelöst:
Immer brav einen einzelnen Sensor identifizieren und seinen Code
übernehmen.
Das geht ohne zusätzliche Hardware oder gar Bleistift und Notizblock.
Was mir nicht gefällt ist, dass in vielen (allen ?) gefundenen
Programmlösungen für JEDES Auslesen der Sensoren ein ROM-Search
angestossen wird.
Aber vielleicht haben wir an dieser Stelle sogar den selben Ansatz.
Michael S.
Hallo Nochmal,
Also, ich habe es bei meiner Entwicklung folgendermaßen gemacht:
1. fertiges Search-Rom-Programm direkt von Hersteller genommen:
http://www.maxim-ic.com/products/ibutton/software/sdk/sdks.cfm
2. Anpassung für meinen µC gemacht.
(TMEX-Funktione/Driver durch eigene Read/write-Funktionen ersetzt)
3. Durchlesen, Nachvollziehen, ausprobieren, geht.
Ich verstehe oft nicht, warum sich einige leute den totalen Stress
geben, wenn doch selbst der Hersteller der originale freie Lösungen
anbietet.
Also bei mir funktoniert der Search-ROM ohne Probleme und man kann auf
der Basis des Dallas-Programms wunderbar seine eigene Anwendung
kreieren, sei es nun auf Windows oder -mit Modifikationen- auf dem µC!
Viel Erfolg!
Michael S. schrieb:> Was mir nicht gefällt ist, dass in vielen (allen ?) gefundenen> Programmlösungen für JEDES Auslesen der Sensoren ein ROM-Search> angestossen wird.
Damit stellt man nur sicher, das der gewählte Baustein überhaupt noch am
Bus ist und nicht irgendein Schmarrn an Messwerten zurückkommt.
Außerdem: Ein Match-ROM muss sowieso gemacht werden. Bei nur einigen
wenigen Sensoren ist der Aufwand dann vergleichbar.
Michael S. schrieb:> Was mir nicht gefällt ist, dass in vielen (allen ?) gefundenen> Programmlösungen für JEDES Auslesen der Sensoren ein ROM-Search> angestossen wird.
Ah, ok.
Das kann ich nachvollziehen.
Ich hab für mich auch eine Variante, bei der ich weiß dass es nur 1
Sensor gibt und da arbeite ich dann auch mit Skip ROM, weils einfacher
ist.
Habe probeweise nach einem Beispielsprogramm für DS1820 gesucht.
Resultat: NIL
Mit µC haben die es wohl nicht so.
Search Parameters
1-Wire Device: DS18B20
Platform: Microprocessor
API: ALL
Programming ALL
Results of Software Example Search
There were no Software Examples matching your search parameters.
Try your search again.
Hallo Markus....
Markus schrieb:> Also, ich habe es bei meiner Entwicklung folgendermaßen gemacht:>> 1. fertiges Search-Rom-Programm direkt von Hersteller genommen:> http://www.maxim-ic.com/products/ibutton/software/...> 2. Anpassung für meinen µC gemacht.> (TMEX-Funktione/Driver durch eigene Read/write-Funktionen ersetzt)> 3. Durchlesen, Nachvollziehen, ausprobieren, geht.>> Ich verstehe oft nicht, warum sich einige leute den totalen Stress> geben, wenn doch selbst der Hersteller der originale freie Lösungen> anbietet.
Och ja, hab mal rein geschaut, ist sogar Assembler drin ... sehr schön,
vielen Dank für den Link das werde ich in jedem Fall gleich mal testen
...
Cheers Jens
@ Martin: besser suchen ! owpd310r2.zip\lib\misc_micro\
Markus schrieb:> Ein Match-ROM muss sowieso gemacht werden.
Nö.
Lies mal das Datenblatt.
Entweder Search-ROM oder Match-ROM oder Skip-ROM adressiert den
Sensor.
D.h. danach kannst Du Daten lesen oder schreiben.
Mit Skip-ROM kannst Du für alle Sensoren die Wandlung starten.
Und dann mit Search-ROM der Reihe nach auslesen.
Peter
Peter Dannegger schrieb:> Nö.> Lies mal das Datenblatt.>> Entweder Search-ROM oder Match-ROM oder Skip-ROM adressiert den> Sensor.> D.h. danach kannst Du Daten lesen oder schreiben.>> Mit Skip-ROM kannst Du für alle Sensoren die Wandlung starten.> Und dann mit Search-ROM der Reihe nach auslesen.
Stimmt, mein Fehler, sorry.
Ich habe ein wenig zu weit ausgeholt und mich nicht nur auf diese
Sensoren bezogen, sondern auf alle möglichen 1-Wire-ICs. Was ich
eingentlich sagen wollte: Adressieren muss man so oder so, und wenn man
einen funktionieren Search-ROM hat und kein zu großes Netzwerk, kann es
nicht schaden, vor jedem Messen zu prüfen, ob alle ICs noch da sind.
Fehler im Netz lassen sich durch ein Search-ROM gut erkennen (Meiner
Meinung nach ;)
Aber danke für den Hinweis!!!!!
Hallo zusammen,
der ROM_SEARCH Code, der hier von mir gepastet wurde muss einen Fehler
haben,
ich habe mittlerweile 15 Sensoren an meinem Bus - Temperatur ermitteln
und lesen geht, ROM_SEARCH nicht.
Ich schätze das Timing ist es nicht, sonst würde ja das andere Zeug auch
nicht gehen, oder?
Ich habe die ROM_CODES mit Hilfe eines zweiten Pins meines uC und einer
zweiten Bus-Implementierung ausgelesen und schicke je nachdem welchen
Sensor ich brauche diese Codes ueber UART an den Controller und der
antwortet mit der Temperaturwert.
Sollte jemand den Fehler in der ROM_SEARCH Geschichte finden wäre ich
sehr dankbar ...
Cheers Jens
Naja, Du mußt schon einige Anpassungen im Vergleich zum ATtiny12
vornehmen.
Der Z-Pointer muß 16bittig initialisiert werden, wenn Dein SRAM >128Byte
ist.
Und Du mußt auch prüfen, ob die verwendeten Register nicht noch woanders
benutzt werden.
Ansonsten sollte der Code funktionieren, wenn Du ihn 1:1 kopiert hast.
Kopieren ist in diesem Fall besser als Abschreiben (vermeidet Fehler).
Bei Assembler muß man sich selber um die Variablenverwaltung (Register,
SRAM) kümmern, bei C nimmt einem das der Compiler ab.
Peter
Ich hatte ein ganz ähnliches Problem. Auch ich hatte Peters ASM-Code auf
den Mega8 umgeschrieben. Der SEARCH_ROM hat immer nur den ersten Sensor
gefunden, da konnte ich machen was ich wollte.
Nachdem ich mehrere Stunden nach der Ursache geforscht habe, und mir
diverse Threads zum Thema angesehen habe, bin ich auf diesen Tipp
gestossen:
> Und Du mußt auch prüfen, ob die verwendeten Register nicht noch woanders> benutzt werden.
Und der war Gold wert! Auf dem Mega8 ist das SRAM über das 16bittige
Z-Register anzusprechen, das zum Teil durch "a3" mitbenutzt wird.
Also: a3 umdefinieren und gut ists.
Vielen dank, werde das testen ....
und Feedback geben ... hatte inzwischen auf den Teil verzichtet und ein
weiteres Beinchen des mega zum Auslesen einzelner Sensoren spendiert ...
Wenn ich das sparen kann um so besser ....
Cheers Jens