www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik DS18b20 ID auslesen


Autor: Jürgen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

muss mall wieder das heiße Thema DS18b20 aufgreifen.
Ich weis es wird gerade öffters diskutiert, aber ich komme nicht weiter.
Möchte die ID des Sensors auf ein Display ausgeben.
Das Reset funktioniert schonmall. Es geht zumindest die richtige LED an, 
wenn der Sensor angelötet wird und die richtige LED wenn keiner 
angehängt ist.

Habe mall meinen Code angehängt.

Bei folgender Änderung wird 3a 8x auf dem Display ausgegeben. So wies 
sein sollte.
  char byte_lesen(void) 
  { 
     unsigned char loop1; 
    
  
      //for(loop1=0;loop1<8;loop1 ++)
      //{ 
        
      //byt=(bit_lesen());
      uebergabe=0x3a; //<<= 1;

        //if (byt==1)
        //{
        //  uebergabe |= 0x01;
        //}

      //}

    return uebergabe;
    
  } 

Änder ich aber denn Code wie in den Dateien um, bekomme ich nur 16 F`s 
aufs Display.

Was mach ich falsch?

Danke für eure Hilfe.

Jürgen

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keiner eine Idee?

Kleiner Nachtrag noch:

Verwende einen Atmega 8515 getacktet mit 12 Mhz.

Jürgen

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hast du denn ein datenblatt und schon mal reingeschaut?????

Autor: Stefan R. (kroko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jürgen,

ich bin mir nicht sicher, aber was ich weiß muss man beim Reset nach dem 
der DS18B20 den Bus auf Low gesetzt hat noch warten.

Ausschnitt aus deinem Code:
_delay_us(480);
BUSDDR_EIN();
_delay_us(70);
reset = (Eingang & 1<<Bus);

Hier nach der Pinabfrage noch ca. 480us warten, damit das Zeitfenster im 
Datenblatt (Seite 15) eingehalten wird.

Mfg Kroko

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antworten.

Stefan R. schrieb:
> Hier nach der Pinabfrage noch ca. 480us warten, damit das Zeitfenster im
> Datenblatt (Seite 15) eingehalten wird.

Danke für denn Tip. Hat was gebracht. Jetzt erscheint auf dem Display: 
142196F380043

Allerdings sollte laut Datenblatt Seite 6 in der ID die 28h vorkommen.

chris schrieb:
> hast du denn ein datenblatt und schon mal reingeschaut?????

(Soviel zu dem Thema)

Wo ist sie hin?
Es sollten auch 64Bit sein. Es sind aber nur 7 Ziffern. Wenn ich richtig 
rechne müßten es 8 Ziffern sein. Richtig?

Noch jemand ne Idee?

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe grad zwei Adressen von DS18S20 Sensoren hier.
Die fangen beide mit 0x10 (nicht mit 0x01 wie bei Dir)an und das 
vorletzte Byte ist 0x00. Also scheint Deine Adresse nicht ganz falsch.

Da stimmt dann irgendwas mit Deiner Routine zum einlesen nicht.
Ich sehe mir das nach dem Abendbrot mal an.

Bis dahin.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch dir danke. Hat auch was gebracht. Jetzt erscheint: 288469CF0100C2

Was habe ich geändert?:
char byte_lesen(void) 
  { 
     unsigned char loop1; 
    
  
      for(loop1=0;loop1<8;loop1 ++)
      { 
        
      byt=(bit_lesen());
      uebergabe >>= 1;

        if (byt==1)
        {
          uebergabe |= 0x80;
        }

      }

Aber immernoch falschrum.

Würd mich also freuen wen du doch noch mall kurz drüberschaust.

Autor: Stefan R. (kroko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ändere mal folgendes in der byte lesen Funktion:

uebergabe <<= 1;
hier auf rechts Schieben ändern

uebergabe |= 0x01
hier auf 0x80 ändern

Und in der main bei der Lcd Ausgabe die for Schleife von 8 nach 0 zählen 
lassen.

Mfg Kroko

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, jetzt hat sich was überschnitten. Aber egal.

Das mit 0x80 und schieben nach recht hatte ich ja schon.
Folgendes kommt:
288469CF0100C2

Nachdem ich die Main noch geändert habe...
    for(u=8;u>0;u--)
    {
    lcd_char_hex(rom[u]);
    }

...bin ich dem Ziel wieder etwas weiter enfernt.
01C20001CF6984

Autor: Stefan R. (kroko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sry, mein Fehler. Schreib beim Lcd Befehl u-1 statt u.

Mfg Kroko

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie meinst du?

Wieso sind das jetzt eigentlich 14 Ziffern anstatt 8?
Weil 14 x 8 = 112 Bit.
Ich brauch doch nur 8 Ziffern, weil 8x8 gibt 64.
Und ich brauch ja nur 64 Bit. Oder verstehe ich da was falsch?

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
8 Ziffer 14 Ziffern???
Du brauchst 8Byte das sind 16 Stellen auf dem Display. Bei Dir werden 14 
Ziffern angezeigt, also nur sieben Byte. Irgendwie geht Dein erstes Byte 
verschütt.

  for(u=8;u>0;u--)
    {
    lcd_char_hex(rom[u]);
    }

Du musst schon bei der Ausgabe mit dem ersten Byte anfangen also rom[0];
Denn das höchstwertige Byte kommt zuerst.

Der Aufbau von der Adresse sieht beim DS18S20 so aus:
1.Byte GeräteCode (wie gesagt bei meinen Sensoren 0x10)
2.-7. Byte Adresse
8.Byte Checksumme

Autor: Stefan R. (kroko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da du ja jetzt von 8 auf 1 zählst, damit die Reihenfolge stimmt, musst 
du lcd_char_hex(rom[u-1]); schreiben.
Da in rom[0] bis rom[7] die Werte stehen und nicht in rom 1-8.

Warum dein Lcd mehr als 8 Byte ausgibt, muss an deiner LCD Routine 
liegen...

Mfg Kroko

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht liegts an den Interrupts, die sollten bei 
1-Wire-Kommunikation abgeschalten sein.

288469CF0100C2 klingt doch schon ganz gut.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bis auf das das erste Byte fehlt.

Autor: Stefan R. (kroko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach Gott, ich bin heute nicht bei der Sache.
Wie mein Vorredner sagt, das sind 7 Byte (bei Hex 14 Zeichen).
Das eine wurde verschluckt, weil ich auf das u-1 vergessen hatte.

Mfg Kroko

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh! ich denke da iss bissel ärger mit dem Timer im Spiel!

Timerinterrupt sperren bei der Verwendung von Temperatursensoren.


Oje das  seh ich grad auch noch! Wie liest den Jürgen das Scratchpad aus
und wo ist die Routine welche veranlasst das der Sensor auch die 
Temperatur messen soll. Tipp? Schau mal ins Datenblatt 44h

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
{28, 0xCD, 0x15, 0xB8, 0x01, 0x00, 0x00, 0x43},
    //ROM nr. for sensor 1
    {0x28, 0x48, 0xDA, 0xB7, 0x01, 0x00, 0x00, 0x95},
    //ROM nr. for sensor 2
     {0x28, 0x5A, 0xF4, 0xB7, 0x01, 0x00, 0x00, 0xFA},
    //ROM nr. for sensor 3
    {0x28, 0xAA, 0xC9, 0xB7, 0x01, 0x00, 0x00, 0xE0}

Ich glaub ich weis wo die zwei byts sind. Das obige habe ich aus dem 
Beispiel entommen wo nach ich mein Code geschrieben habe. Mann sieht, 
das zweitletzte und dritletztes byt ist 0x00. In der zwischenzeit habe 
ich einen zweiten Sensor ausprobiert und auch hier sind zwei nullen an 
der zweitletzten und dritletzten stelle. Folgendes habe ich versucht:
unsigned  char z; 
    
    for(z=0;z<8;z++) 
    { 
      rom[z]=0x00;//byte_lesen();
    }
    sei();
    unsigned  char u; 
  
    for(u=0;u<8;u++)
    {
    lcd_char_hex(rom[u]);
    }
  
Erscheint auf meinem Display 8x0.
Somit wären die zwei nullen eigentlich 4 Nullen. Ich habe also meine 16 
Ziffern. Möglich?

Klaus schrieb:
> Wie liest den Jürgen das Scratchpad aus
> und wo ist die Routine welche veranlasst das der Sensor auch die
> Temperatur messen soll. Tipp? Schau mal ins Datenblatt 44h

Soweit bin ich noch nicht.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt plausibel.

Der Test ist ganz einfach:
reset();
writeByte(0xcc); //skipROM
writeByte(0x44); //starte Wandlung

800ms warten

reset();
writeByte(0x55);//matchROM
for (8x)
 writeByte(die einzelnen Bytes der Addresse);
 //mit dem Byte anfangen, was zuerst empfangen wurde!


writeByte(0xbe); //readScratchPad
2Bytes einlesen;

Wenn die beiden Bytes am Ende nicht 0xff sind, hat alles funktionert und 
Du hast schon die Temperatur.

MfG, Tom

Autor: Jürgen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das wars!
Meine Vermutung war richtig. Dieser Code ...
    unsigned  char z; 
    
    for(z=0;z<8;z++) 
    { 
      rom[z]= byte_lesen();
    }
    
    unsigned  char u; 
  
    for(u=0;u<8;u++)
    {
    lcd_char_hex(rom[u]);
    lcd_string(" ");
    }

gibt folgendes aus:
28 82 09 8E 02 0 0 EA

Passt.

Herzlichen dank für eure Hilfe.

Falls es jemand interessiert, ich habe den gesammten Code angehängt.

Nochmals Danke!!!

Autor: Stefan R. (kroko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt hast du die Ausgsbe erst Wieder verkehrt.
Aber egal, wenn man weiß wo das 1. Byte ist, ists ja kein Problem.

Mfg Kroko

Autor: Helmut J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso ist die Ausgabe verkehrt, Stefan?

Der ds18s20 sendet das MSB zuerst und das LSB zuletzt.

http://de.wikipedia.org/wiki/Bitwertigkeit

Autor: Stefan R. (kroko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich nicht, laut Datenblatt und meinem Code, sendet der DS18B20 
zuerst den family code und damit LSB zuerst.

Mfg Kroko

Autor: Wolfgang-G (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>sendet der DS18B20..und damit LSB zuerst.
bei mir auch
MfG

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.