Mehrere DS18B20 an einen Pin Avr-Mega32

Die Sensoren habe 2 Byte EEPROM, darin kannst Du z.B. die 
Meßstellennummer ablegen. Dazu die Sensoren einzeln anschließen, dann 
weißt Du ja, welcher dran ist.

Mit ROM-Search liest man sie dann immer der Reihe nach aus und speichert 
das Ergebnis entsprechend der Meßstellennummer.


Peter

Rick wrote:

> Das ist dann bei ungefähr 10 Sensoren eine ganz schöne
> Initialisierungsprozedur....ggg...und sollte einmal ein Sensor den
> "Geist" aufgeben, so muss ich alle anderen Sensoren wieder abschließen
> und alles beginnt von vorne.

Man kann es natürlich auch schön machen. Ein neuer Sensor hat im EEPROM 
0xFFFF stehen, dann springt man in einen Routine, mit der man die 
Meßstelle zuweist.
Somit muß ein einmal definierter Sensor nicht mehr abgesteckt werden. Es 
reicht, einen neuen Sensor anzustecken.

Wenn es nicht stört, daß jeder Sensor ne extra Leitung hat, kann man 
auch multiplexen. Dann fallen bei ner Leitungsstörung nicht alle 
Senosren gleichzeitig aus.
Statt extra Multiplexer kann man besser einen ganzen Port nehmen, wo 
dann der 1-Wire Funktion der aktive Pin per Bitmaske übrgeben wird.
Beim Starten der Wandlung kann man dann mit der Maske 0xFF alle 8 
Sensoren gleichzeitig starten.


Peter

Rick wrote:

> Das ist dann bei ungefähr 10 Sensoren eine ganz schöne
> Initialisierungsprozedur....ggg...und sollte einmal ein Sensor den
> "Geist" aufgeben, so muss ich alle anderen Sensoren wieder abschließen
> und alles beginnt von vorne.

Stimmt schon, man sollte diese Sensoren so montieren, dass man sie ohne 
die Wand aufzumeisseln vom Bus trennen kann. Kann ja auch mal einer 
kaputt gehen und den Bus lahmlegen.

Letzten Endes benötigst du eine Zuordnungstabelle ID=Funktion. Wenn man 
die Dinger also einen nach dem anderen an den Bus dranhängt, wird es 
einfach. Und der Fall eines Austauschs ist auch trivial: der Neue ist 
der einzige, der noch keine Zuordnung zu einer Funktion hat.

> Wenn man über einen Multiplexer immer nur einen Sensor am Pin hat, so
> kann man außerdem auch einfach die ROM-Prozedur überspringen und hat
> gleichzeitig eine eindeutige Zuordnung (8 Sensoren pro Multiplexer).

Wenn der dabei entstehende Strippensalat akzeptabel ist, dann mach das.

> Hat jemand Erfahrungen von euch, wie lange die Kabel zu den Sensoren
> sein dürfen?

Dallas/Maxim hat davon jede Menge, und das auch zu (e)Papier gebracht. 
Lies: such dort nach entsprechenden Appnotes.

@Rick:
Ich habe bei meiner Steuerung zwei Pins verwendet. An einem hängen alle 
Sensoren im Normalbetrieb dran. Am zweiten Pin hänge ich einen neuen 
Sensor dran wenn ich ihn "beschriften" will bevor an den Pin für den 
Normalbetrieb drankommt. Sollte also ein Sensor ausfallen, "beschrifte" 
ich einen neuen und klemm ihn da zu den anderen Sensoren dran, so ist 
der Normalbetrieb nicht gestört bzw. geht der Austausch schnell von 
statten.

Markus

Kabellänge: Appnote 148.

Rick wrote:
> Hi!
>
> @Markus neu:
>
> An diese Möglichkeit hab ich auch schon gedacht.
> Wie hast Du das im Detail gelöst?
> Weißt du per Display dann zu der ausgelesenen Seriennummer die
> ensprechende Mess-Stellennummer zu?

Nein, nicht ganz. Im Display stell ich eine Nummer ein (1 - 9) und 
schreibe sie ins ROM des Sensors. Diese Nummern kann ich dann natürlich 
in meinem Programm fest zuordnen (1=Pufferspeichersensor, 
2=Aussentemperatur, 3=Ölkesseltemperatur usw.). Beim Auslesen der 
Sensoren lese ich neben der Temperatur auch die 2Byte Eeprom mit aus 
(das LowByte würde eigentlich genügen) - schon kann ich wieder zuordnen 
was für ein Sensor das ist.


> Eure Lösungen sind programmiertechnisch gesehen natürlich elleganter als
> die meinige. Jedoch muß ich leider berücksichtigen, daß ich immer noch
> blutiger Anfänger in Sachen C-Programmierung und AVR-Controller bin.
> Somit hab ich mir gedacht, ich nehm 2 Stück 8in1 analog Multiplexer,
> häng jeden an einen eigenen Pin und hänge die 3 Adressleitungen zusammen
> und schließe sie ebenfalls an den Controller an. Somit benötige ich für
> 16 Temp.sensoren nur 5Pins (3 Adress- und 2 Datenleitungen)
> Eine Wahrheitstabelle für die Adressierung der einzelnen Sensoren sollte
> eigentlich kein Problem sein.
> Programmiertechnisch gesehen, aus meiner Sicht, die einfachste Methode.
>
> Mit einder Funktion kann ich dann alle Sensoren auf einmal resetten.
> Die ROM-Funktion überspringen, den Temp.-Konvertierungsbefehl senden und
> nach 1sec die Temparatur einzeln auslesen.
>
> Grüsse Rick

Ich betrachte mich schon auch als Anfänger was die C-Programmierung 
betrifft, aber deine Lösung erscheint mir aus meiner (bescheidenen) 
Sicht aufwändiger. Wenns für dich so lösbar und praktikabel ist würd ich 
natürlich dabei bleiben! Viele Wege führen nach Rom ;-)!


Gruß - Markus

Also ich denke mal, dass Du deine Sensoren ja mit einem Stecker an 
deinen Atmel anschließt und die nicht direkt einlötest :-)

Also ist es doch kein Problem:
a) Neuen Sensor anstecken
b) Romsearch auslösen (Taste an deiner Steuerung)
c) neuer Sensor wird am Display angezeigt
d) Sensor zuweisen über weiteren Tastendruck
e) wenn mehr Senoren, weiter bei a)

Man hat sofort einen Kabel Test. Und wenn deine Steuerung ein Display 
hat und 2 Tasten (Menü und Enter) kann man das Komfortabel 
Implementieren.

Die Zuordnung der Sensoren kann man dann im EEPROM des AVR sichern. Ich 
würde hier die Eindeutige ID sichern. Der Zugriff aufs EEPROM des AVR 
ist schneller und einfacher. Und ich muss nicht immer suchen Wer hat den 
die Sensor ID x im EPROM stehen.

Zyklisches Vorgehen:
a) lese nächste Sensor ID aus EEPROM
b) Sensor mit ID anweisen Temperatur zu messen
c1) kein ACK Sensor defekt nicht mehr da -> Fehlermeldung und ab zu a)
c2) wenn ACK Sensor auslesen und nutzen
d) ab zu a)

So würde ich das tun...
Auch kann man zyklisch einen Romsearch machen und neue Sensoren 
Automatisch anbieten im Menü als "unassigned" und Fehlende einfach 
feststellen. Das würde bei der Ablage der Sensor ID im EEPROM des 
Sensors nicht so einfach gehen.

Und die Sensor ID muss ja so oder so zugewiesen werden. Also hilft hier 
nur Stückweises anstecken und zuordnen.

Mit der Kabellänge habe ich keine Erfahrung, aber da kamen ja schon 
genug Hinweise zu App Notes.

Gruß Juergen

Rick wrote:
> Hi!
>
> @Markus:
>
> Du meinst Du schreibst die Mess-Stellennummer ins RAM und von dort ins
> EEPROM.(EERAM)
> Ins ROM kannst nu nichts schreiben, denn das steht ja nur die Kennung,
> die Seriennummer und die CRC darüber.

Gemeint ist natürlich das EEPROM!

> Deine Lösung spricht mich technisch gesehen auch mehr an.
> Du würdest mir nicht zufällig Deinen Code überlassen, damit ich mir mal
> ansehen kann, wie man so was macht, oder?
>

Basis meiner 1Wire Funktionen ist die 1Wire Lib von Peter Dannegger. Die 
findest du hier in der Codesammlung. Meine Funktion zum Speichern der ID 
sieht folgendermassen aus:

1

char ow_setID(unsigned int id)

2

{

3

 if(W1_IN & (1<<W1_PID)){   //prüfen ob Bus an PD4 i. O. (high) ist

4

  if(w1_reset(W1_PID)){     //resetten und prüfen ob Sensor antwortet

5

              return 'K';}  //Kein Sensor gefunden

6

7

          w1_byte_wr(SKIP_ROM, W1_PID);   //SKIP_ROM an Sensor senden

8

          w1_byte_wr(WRITE, W1_PID);      //Schreibvorgang initiieren

9

          w1_byte_wr(id, W1_PID);         //1.Byte schreiben

10

          w1_byte_wr(id, W1_PID);       //2.Byte schreiben - immer 0 da nicht benutzt

11

          w1_byte_wr(0x7f, W1_PID);       //3.Byte: Config Byte -> 12bit Auflösung

12

13

              if(w1_reset(W1_PID)){     //resetten und prüfen ob Sensor antwortet

14

                          return 'S';}  //Kein Sensor nach Schreibvorgang gefunden

15

                    w1_byte_wr(SKIP_ROM, W1_PID);   //SKIP_ROM an Sensor senden

16

                    w1_byte_wr(EE_WRITE, W1_PID);   //Neue Werte im EEProm speichern

17

                    _delay_ms(10);          //Warten bis Speichervorgang abgeschlossen ist

18

                    return 'E';             //Kommando erfolgreich

19

   }//1.if

20

 else{

21

   return 'F';  //Busfehler

22

    } //1.else

23

24

}

Ich hab die Lib von Peter so abgeändert dass immer der Pin mitgegeben 
wird, an dem der Sensor angeschlossen ist. Der Rest ist relativ einfach 
bzw. nach einem eingehenden Studium der Maxim Datenblätter nicht allzu 
schwierig.

Gruß - Markus

Hier mal Bilder vom "Pilotbetrieb" meiner Heizungssteuerung. Zu sehen 
ist die Verkabelung zu den Sensoren im Pufferspeicher, alles noch "frei 
Luft" verdrahtet.

Die Steuerung selber...

Hi,

nein ich überprüfe per Code nicht ob die Daten richtig gespeichert 
wurde. Zum Anzeigen der ID hab ich eine Funktion die diese aus dem 
Sensor ausliest und auf dem Display anzeigt, so "prüfe" ich.

Gruß - Markus

Hi Achim!

Vor dieser Entscheidung steh ich auch noch.
Die Methode mit dem Schrumpfschlauch oder ne Hülse machen und vergießen?
Was ich so hier im Forum gelesen habe arbeiten die meisten mit der 
Schrumpfschlauch-Methode.
Wie ich es selber schachen werde, weiß ich auch noch nicht.
Auch das was das Vergußmaterial betrifft, kann ich dir keine Antwort 
geben.

Bei Conrad gibt es die Niro-Hülsen zum selber vergießen.
Ach n Vergußharz.

Gruß Rick

Hi,

ich hab meine Sensoren in einer Messinghülse mit Flüssigmetall verklebt. 
Als Sensor für die Heizung passen sie so optimal in jede Tauchhülse 
rein. Das Ansprechverhalten verzögert sich dadurch natürlich, aber das 
ist in dem Fall auch gewünscht.

Ne Temperaturdifferenz konnte ich dadurch nicht feststellen. Ich hab z. 
B. in meiner Schaltung den gleichen Temperaturwert für den Ölkessel wie 
die Steuerung des Ölkessels selber.

Anbei mal ein Bild davon. Als Kabel habe ich 3X1 Ölflex genommen und 
hinten mit Kleber in der Messinghülse fixiert.

Markus

@Rick:

Die Anschlüsse zum Sensor sind komplett mit Schrumpfschlauch isoliert. 
So ein Messingrohr kriegt man hier:
http://www.modellbauschraube.de

Markus

Hi!

Ich hab da noch ein Verständnisproblem beim Ausleseforgang des Sensors:


Ein Bit wird lt. Datenblatt folgendermaßen vom Sensor ausgelesen:

Ein Lesevorgang wird durch den Master durch eine fallende Flanke 
initialisiert.
Der Master muß die DQ-Line für mindestens 1 usec auf "0" halten.
Anschl. muß der Master die DQ-Line freigeben, damit der DS18B20 senden 
kann.
Die Antwort des Sensors liegt innerhalb von 15 usec ab der fallenden 
Flanke des Masters.
Alle Lesezyklen haben eine Mindesgesamtdauer von 60usec und eine 
Mindesterholzeit von 1usec zwischen den untersch. Abfragezyklen.

Jetzt habe ich aus versch. Beispielcodes unteranderen auch von Peter 
Dannegger folgende Auslesesequenz gesehen:

1.) DQ-Line auf "0"
2.) 1 usec warten, oder etwas mehr
3.) DQ-Line freigeben (per Pullup-R auf high)
4.) 15-1 usec warten
5.) Pin auf Antwort des Sensors auslesen
6.) 60-15 usec warten + Erholzeit von min. 1usec


Die Antwort des Sensort liegt aber genau während der Wartezeit von Punkt 
4.
Da tut der Controller aber nix anderes als warten.
Erst wenn das Zeitfenster vorbei ist wird der Pin abgefragt, wie kann 
das funktionieren?
Müsste man nicht zuerst den Pin abfragen und anschl warten?

Grüsse Rick