DS1820 mehr als 3 nicht Möglich?

[Jens S. (straubej)]

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):

;-------------------------------------------------------------------------
;        Generate 1-Wire Reset
;-------------------------------------------------------------------------
;Input: none
;Output: C = 1, if no 1-wire device found
;Used:  a1
;
w1_reset:
  ldi  a1, 480 * xtal / 1000000 / 9
_w1r1:  cbi  w1_out, w1_pin      ;2
  sbi  w1_ddr, w1_pin      ;2  low
  sec          ;1
  seh          ;1
  dec  a1        ;1
  brne  _w1r1        ;2

  ldi  a1, 480 * xtal / 1000000 / 9
  cli
_w1r2:  cbi  w1_ddr, w1_pin      ;2  high
  sbic  w1_in, w1_pin      ;2
  clh          ;  reset released
  brhs  _w1r3        ;2
  sbis  w1_in, w1_pin      ;
  clc          ;  presence detect
_w1r3:  dec  a1        ;1
  brne  _w1r2        ;2
  reti          ;  int enable

;-------------------------------------------------------------------------
;        Read / Write Bit on 1-wire
; DDR auf 1  mC Bein = Ausgang
; DDR auf 0  mC Bein = Eingang
;Ein Pullup-Widerstand an einem Eingangspin wird durch das PORT-Register gesteuert. 
;Das PORT-Register erfüllt also 2 Aufgaben. 
;Bei einem auf Ausgang geschalteten Port steuert es den Pegel an den Ausgangspins. 
;Bei einem auf Eingang geschalteten Port steuert es, ob die internen Pullup-Widerstände aktiviert werden oder nicht. 
;Ein 1-Bit aktiviert den entsprechenden Pullup-Widerstand.
; 
;DDRx   PORTx   IO-Pin-Zustand
;  0     0     Eingang ohne Pull-Up (Resetzustand)
;  0     1     Eingang mit Pull-Up
;  1     0     Push-Pull-Ausgang auf LOW
;  1     1     Push-Pull-Ausgang auf HIGH 
;
;-------------------------------------------------------------------------
;Input  C = bit
;Output  C = bit
;Used  a1
;
w1_bit_rd:
  sec              ; set carry bit
w1_bit_wr:
w1_bit_io:
  cli              ; interrupt
  sbi  w1_ddr, w1_pin      ; pin auf ausgang wie ist der port?
  ldi  a1, 15 * xtal / 1000000 / 3  ; warte 15 uSec
  brcc  _w1io1        ; wenn nicht read oder c=0 dann weiter zu _w1io1
  cbi  w1_ddr, w1_pin      ; pin auf eingang
_w1io1:  
  dec  a1            ; warte
  brne  _w1io1        
  sbis  w1_in, w1_pin    ; wenn bit = 1 scip next
  clc              ; wenn bit = 0 C=0
  ldi  a1, 45 * xtal / 1000000 / 3 ; warte 45 uSec
_w1io2:  
  dec  a1            ; warte
  brne  _w1io2
  cbi  w1_ddr, w1_pin      ; pin auf eingang high ?
  reti            ; int enable

;******************************  Read / Write byte ***********************/
;Input  a0 = byte
;Output a0 = byte
;Used  a0, a1, a2
;
w1_byte_rd:
  ldi  a0, 0xFF
w1_byte_wr:
  ldi  a2, 8
_w1wr1:
  ror  a0      ; lsb first rechtes bit des bytes wird c
  cli        ; because 3th stack level interrupt
  rcall  w1_bit_io  ; send c
  dec  a2      
  brne  _w1wr1  ; 8 mal für jedes bit 1 mal 
  ror  a0      ; last bit in  
  ret

;-------------------------------------------------------------------------
;        ROM Search
;-------------------------------------------------------------------------
;Input  a0 = bit to resolve
;Output  a0 = next bit to resolve
;Used  a0, a1, a2, a3, zl
w1_rom_search:
  mov  a3, a0          ; a3 = FF
  rcall  w1_reset      ; reset bus
  ldi  a0, presence_err    ; a0 = FF -> bei fehler ist das der return wert
  brcs  _wrs7        ; wenn error dann ende sonst weiter
  ldi  a0, search_rom      
  rcall  w1_byte_wr      ; sende search rom
  ldi  zl, romcode        ; point to rom code memory 0x01 ? warum ?
  ldi  a0, last_device      ; a0 = 0x00
  ldi  a2, 8 * 16 - 1      ; 8 bytes a 8 bit -> 1111111  7 mal 1
_wrs1:  
  rcall  w1_bit_rd      ; READ I read bit c=0
  sbc  a1, a1          ; H = C
  rcall  w1_bit_rd      ; READ II read complement bit
  ld  a1, z          ; lade a1 aus speicher
  brhc  _wrs2        ; READ I  =0 wenn H=0 sprung an _wrs2
  brcc  _wrs4        ; READ II =0 wenn C=0 sprung an _wrs4 , bit 1 RESOLVED
  ldi  a0, data_err      ; wenn READ I und II = 1 dann Fehler
  ret
_wrs2:              ; READ I  =0  
  brcs  _wrs5        ; READ II =1 sprung an _wrs5 , bit = 0 -> RESOLV
                ; READ I & II = 0
  cp  a2, a3          ; vergleiche a2 und a3 , a3=initialwert von a0 
  breq  _wrs5        ; bit 0 RESOLVED - warum ?
  brcs  _wrs3        ; bit = 1, resolve - warum ?
  sbrs  a1, 0        ; skip next wenn a1 an position 0 (ganz rechts) = 1;
  rjmp  _wrs5        ; bit = 0
_wrs3:  
  mov  a0, a2          ; bit = 1
  
_wrs4:              ; bit 1 RESOLVED
  sec              ; Set carry bit
  rjmp  _wrs6
  
_wrs5:              ; bit 0 RESOLVED
  clc              ; Clear carry bit
  
_wrs6:              ; Speichere bits im ROM an Z Position               
  ror  a1            ; C->b7------------------b0->C
  st  z, a1          ; speicher a1
  rol  a1            ; C<-b7------------------b0<-C
  rcall  w1_bit_wr      ; sende Bit bei (Bit 0 RESOLVED send 0) 
  subi  a2, 2        ; after 8 times: H = 1
  brhc  _wrs1        ; wenn byte noch nicht fertig dann sprung
  inc  zl            ; next byte im speicher  
  brcc  _wrs1        ; wenn noch keine 64 bits fertig dann sprung
_wrs7:  ret
;-------------------------------------------------------------------------

[Peter (Gast)]

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.

[Peter (Gast)]

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.

[Michael S. (Gast)]

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.

[Peter D. (peda)]

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 D. (peda)]

Peter schrieb:
> ich durchblicke den ROM Search nicht.

Liegt wohl auch daran, daß der OP zu faul ist, die Postingregeln zu 
lesen.
Formatierung

Peter

[Läubi .. (laeubi)]

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"...

[Jens S. (straubej)]

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.

[Michael S. (Gast)]

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.

[Peter (Gast)]

Michael S. schrieb:
> Wozu benötigt man eigentlich dieses ROM-Search ?

was ist wenn den sensoren im Betrieb ausgetauscht werden können?

[Michael S. (Gast)]

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.

[Karl H. (kbuchegg)]

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.

[Christian H. (netzwanze)]

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.

[Michael S. (Gast)]

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.

[Peter D. (peda)]

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

[Karl H. (kbuchegg)]

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.

[(prx) A. K. (prx)]

Wie darf man sich denn den Kabelsalat vorstellen, insbesondere was die 
Länge angeht?

[Markus (Gast)]

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

[Jens S. (straubej)]

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

[Michael S. (Gast)]

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.

[Markus (Gast)]

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!

[Markus (Gast)]

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.

[Karl H. (kbuchegg)]

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.

[Martin (Gast)]

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.

[Jens S. (straubej)]

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\

[Peter D. (peda)]

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

[Markus (Gast)]

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!!!!!

[Jens S. (straubej)]

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

[Peter D. (peda)]

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

[PeterB (Gast)]

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.

[Jens S. (straubej)]

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