DS18b20 ID auslesen

[Jürgen (Gast)]

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

[Jürgen (Gast)]

Keiner eine Idee?

Kleiner Nachtrag noch:

Verwende einen Atmega 8515 getacktet mit 12 Mhz.

Jürgen

[chris (Gast)]

hast du denn ein datenblatt und schon mal reingeschaut?????

[Stefan R. (kroko)]

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

[Jürgen (Gast)]

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?

[Tom (Gast)]

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.

[Jürgen (Gast)]

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.

[Stefan R. (kroko)]

Ä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

[Jürgen (Gast)]

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

[Stefan R. (kroko)]

Sry, mein Fehler. Schreib beim Lcd Befehl u-1 statt u.

Mfg Kroko

[Jürgen (Gast)]

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?

[Tom (Gast)]

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

[Stefan R. (kroko)]

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

[Tom (Gast)]

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

288469CF0100C2 klingt doch schon ganz gut.

[Tom (Gast)]

bis auf das das erste Byte fehlt.

[Stefan R. (kroko)]

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

[Klaus (Gast)]

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

[Jürgen (Gast)]

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

[Tom (Gast)]

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

[Jürgen (Gast)]

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

[Stefan R. (kroko)]

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

Mfg Kroko

[Helmut J. (Gast)]

Wieso ist die Ausgabe verkehrt, Stefan?

Der ds18s20 sendet das MSB zuerst und das LSB zuletzt.

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

[Stefan R. (kroko)]

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

Mfg Kroko

[Wolfgang-G (Gast)]

>sendet der DS18B20..und damit LSB zuerst.
bei mir auch
MfG