www.mikrocontroller.net

Forum: Compiler & IDEs Mehrere DS18B20 an einen Pin Avr-Mega32


Autor: Rick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich möchte für meine Heizugssteuerung digitale Temperatursensoren 
verwenden.
Meine Wahl viel auf den DS18B20. Laut Datenblatt und Beiträge+Codebsp. 
hier im Forum kann man mehrere Sensoren an einen Pin hängen, da ja jeder 
Sensor eine eigene Seriennummer im ROM hat.
Meine Frage: Was nützt mir die Seriennummer, wenn ich die 
Temperatursensoren nicht zuordnen kann? Ich kann mir zwar die einzelnen 
Seriennummer auslesen, aber welcher jetzt die Kesseltempetatur und 
welcher die Vorlauftemperatur wieder gibt, weiß ich nicht.
Die einzige Anwendung wo diese Seriennummer nützlich ist, ist z.B wenn 
man eine Temperaturdifferenz braucht, oder?

Mir ist bis jetzt nur die Möglichkeit eingefallen einen analogen 
Mutiplexer zu verwenden, um somit die Sensoren eindeutig zuordnen zu 
können.(CD 4051)

Gibts da besserer Möglichkeiten, oder hab ich da was überdehen?

Grüsse Rick

Autor: mehrfacher STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht so, wie man es bei Netzwerkkarten macht:
Die "Seriennummer" (im Fall der Netzwerkkarte MAC-Adresse) auf den 
Sensor drauf schreiben.
Dazu wäre es halt nötig, die Seriennummern der Sensoren vor dem Einbau 
festzustellen.
Das sollte aber auch ein relativ kleines Problem sein...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Danke erstmal für eure Antworten.

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.

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

Hat jemand Erfahrungen von euch, wie lange die Kabel zu den Sensoren 
sein dürfen?
Hie im Forum hab ich gelesen, daß bis etwa 10m man die DS12B20 direkt 
anschleißen kann, darüber braucht man ne Ausgleichsschaltung.

Grüsse Rick

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also zur Kabellänge kann ich sagen, dass ich mehrere 18S20 und diverse 
andere Sensorik an 25m + Abzwige cat.5 direkt an einem AVR IO betrieben 
habe und keine Fehler in der Übertragung auftraten. Ich halte 10 m auch 
für absolut unkritisch, alles größere würd ich erst mal ohne ext. 
Beschaltung testen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus _neu (markush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Rick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kabellänge: Appnote 148.

Autor: Markus _neu (markush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
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?

------------------------------------------------------------------

Ich habe mir die App.Notes Nr. 127, 148, 163, 187 und 203 von Maxim 
runtergeladen.
Danke für den Tipp.


Grüsse Rick

Autor: Jürgen Sachs (jsachs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus _neu (markush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
char ow_setID(unsigned int id)
{
 if(W1_IN & (1<<W1_PID)){   //prüfen ob Bus an PD4 i. O. (high) ist
  if(w1_reset(W1_PID)){     //resetten und prüfen ob Sensor antwortet
              return 'K';}  //Kein Sensor gefunden

          w1_byte_wr(SKIP_ROM, W1_PID);   //SKIP_ROM an Sensor senden
          w1_byte_wr(WRITE, W1_PID);      //Schreibvorgang initiieren
          w1_byte_wr(id, W1_PID);         //1.Byte schreiben
          w1_byte_wr(id, W1_PID);       //2.Byte schreiben - immer 0 da nicht benutzt
          w1_byte_wr(0x7f, W1_PID);       //3.Byte: Config Byte -> 12bit Auflösung

              if(w1_reset(W1_PID)){     //resetten und prüfen ob Sensor antwortet
                          return 'S';}  //Kein Sensor nach Schreibvorgang gefunden
                    w1_byte_wr(SKIP_ROM, W1_PID);   //SKIP_ROM an Sensor senden
                    w1_byte_wr(EE_WRITE, W1_PID);   //Neue Werte im EEProm speichern
                    _delay_ms(10);          //Warten bis Speichervorgang abgeschlossen ist
                    return 'E';             //Kommando erfolgreich
   }//1.if
 else{
   return 'F';  //Busfehler
    } //1.else

}

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

Autor: Markus _neu (markush)
Datum:
Angehängte Dateien:

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

Autor: Markus _neu (markush)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die Steuerung selber...

Autor: Rick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

@Markus
Danke für Dein Beispiel.
Ich versuche gerade selbst den erforderlichen Code für meine Methode zu 
schreiben.
Überprüfst Du auch per CRC, ob die Daten richtig ankommen?
Ich schnall das nicht wirklich.
In der AVR libc gibts dafür die Bibliothek <util/crc16.h>
Die Funktion "crc_ibutton_update" generiert die CRC nach dem Polynom von 
MAXIM.
Mit den Parametern komm ich jedoch nicht klar. Was ist seed?
Ich habe folgenden Code gefunden (von AVR Freaks):


Funktion für CRC:
unsigned char ow_ComputeCRC8(unsigned char inData, unsigned char seed)
hier sind die Parameter seed und inData im Gegensatz zur libc Bibliothek 
vertauscht.

Aufruf beim Auslesen der Temparatur:

crc=0
crc= ow_computeCRC8(scratchpad[i], crc);


scratchpad enthält die 9 ausgelesenen Bytes des RAM des DS18B20.
i wird von 0 bis acht durchgezählt
anschließend wird diese crc mit dem 9Byte (die CRC vom Sensor) 
verglichen.

Grüße Rick

Autor: Markus _neu (markush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich meinte auch, die CRC zu verwenden, um zu überprüfen, ob die 
Temparatur korrekt ausgelesen und übertragen wurde.

Aber über die ROM-Daten kann man ja auch eine CRC machen.

Kennt sich jemand mit der CRC aus?

Grüsse Rick

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rick!

Eine CRC Funktion für Dallas ist in der AVR-libc dabei, die nutze ich 
auch. Funktioniert prima. Schau mal in die Doku.

Gruß Stefan

Autor: Rick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan!

Ein bißchen weiter oben, hab ich über genau diese  CRC-Funktion 
geschrieben;-)

Wie hast Du diese eingebunden? Bei mir gibts immer ne Compiler 
Fehlermeldung.
undefined reference to 'crc_ibutton_update'


Ich habs so gemacht:
for(c=0;c<=7;c++)
    crc = crc_ibutton_update(crc, scratchpad[c]);

if( crc == scratchpad[8])     // wenn CRC ok, dann Temparatur aufgeben
   .......


Gruß Rick

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rick
uint8_t checkcrc(uint8_t bytes, uint8_t data[])
{
  uint8_t crc = 0, i;
     for (i = 0; i < bytes; i++)
            crc = _crc_ibutton_update(crc, data[i]);
        return crc; // must be 0
};

Versuchst mal damit.

Gruß

Autor: Rick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Stefan!

Der return-Wert verwirrt mich etwas. Soll der nicht der gleiche CRC-Wert 
sein wie das 9. ausgelesene Byte aus dem Scratchpad?(=CRC vom Sensor)

Anschließender Vergleich:

if( crc == scratchpad[8])     // wenn CRC ok, dann Temparatur aufgeben

Gruß Rick

Autor: Stefan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rick

Habe die funktion aus der libc Doku. Seite 113, Version 1.4.6
Habe sie nur etwas umgestrickt, funktioniert bei mir tatellos.

Schau mal im Angehangen Daten blatt seite 8 Letzter Absatz

Auszug:

Next, the 8-bit ROM code or scratchpad CRC
from the DS18B20 must be shifted into the circuit. At this point, if the 
re-calculated CRC was correct, the
shift register will contain all 0s

Gruß

Autor: Rick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan!

Ich hab, jedenfalls dachte ich das, das selbe Datenblatt ausgedruckt vor 
mir liegen. Da steht das nicht drinnen :(

Also wenn ich das jetzt richtig geschnallt habe:

Ich schiebe die empfangenen 7Bytes beginnend mit dem 0. Byte aus dem 
Scratchpad in die CRC-Fkt. dann entsthet mein eigener CRC Code.
Wenn ich dann das 8.Byte aus dem Scratchpad, die CRC vom Sensor, in die 
CRC_Fkt. reinschiebe so muß das Resultat null sein.

Vielen Dank, Du hast mir sehr geholfen!

Gruß Rick

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rick

so stehts in meinem Daten blatt und so funktionierts auch bei mir.

Und so wie du das verstanden hast ist es auch richtig

Viel erfolg


Gruß Stefan

Autor: Sucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

@ Markus _neu und ander Erfahrene.... wie habt Ihr die Sensoren 
eingegbaut?
Schrumpfschlauch, Alu-Hülse mit Zeikomponenntenkleber..etc? Wie ist da 
die Temperaturdifferenz und die Ansprechzeit?
Könnte man Eure gesammelten Ratschläge (zB: ID schreiben) nicht ins Wiki 
stellen....die Fragen tauchen ja zyklisch NEU auf und man sollte doch 
das Rad nicht neu erfinden.

Danke für jede Antwort
Achim

Autor: Rick M. (rick00)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus _neu (markush)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Markus!

Hast Du nicht Angst, daß das Flüssigmetall eine Leitende "Schicht" 
bildet?
Woher hast Du die Hülse?

Gruß Rick

Autor: Markus _neu (markush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rick:

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

Markus

Autor: Rick M. (rick00)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.