DS18B20 code funktioniert nicht

[spongebrot (Gast)]

Ich versuche schon seit längerem meinen DS18B20 zum laufen zu bekommen.
Ich verwende einen ATMega328P mit externem Quarz (16 MHz). Versorge 
meinen DS18B20 mit +5V, Data, Gnd und habe einen 4.7k Widerstand 
zwischen +5V und Data

#define F_CPU 16000000UL
#define LOOP_CYCLES    8
#define THERM_INPUT_MODE()    THERM_REGISTER &= ~(1<<THERM_PORT_NUM)
#define THERM_OUTPUT_MODE()    THERM_REGISTER |= (1<<THERM_PORT_NUM)
#define THERM_LOW()        THERM_PORT &= ~(1<<THERM_PORT_NUM)
#define THERM_HIGH()      THERM_PORT |= (1<<THERM_PORT_NUM)

#define us(num) (num/(LOOP_CYCLES*(1/(F_CPU/1000000.0))))

inline __attribute__((gnu_inline)) void therm_delay(uint16_t delay){
  while(delay--) asm volatile("nop");
}

uint8_t Thermometer::reset(){
  uint8_t err;
  THERM_LOW();
  THERM_OUTPUT_MODE();
  therm_delay(us(480));
  ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
    THERM_INPUT_MODE();
    therm_delay(us(66));
    err = (THERM_PIN & (1<<THERM_PORT_NUM));
  }
  therm_delay(us(414));
  if( (THERM_PIN & (1<<THERM_PORT_NUM)) == 0)
    err = 1;
  return err;
}

und im Main:

if(_thermometer.reset())
    _display.print("ERROR",0,0);
  else
    _display.print("OK",0,0);

und ich krieg immer "Error"

Hat wer eine idee, wo mein fehler liegen könnte?

[spongebrot (Gast)]

Error ist übrigens "1"

[Karl H. (kbuchegg)]

Gibt es einen speziellen Grund, warum du dein eigenes Delay-Süppchen 
kochst und nicht die vordefinierten _delay_xx Funktionen benutzt?

Ansonsten:
Da 1-Wire recht kritisch auf korrektes Timing ist ...

> Ich verwende einen ATMega328P mit externem Quarz (16 MHz).

... hast du das KONTROLLIERT?


Deine Reset Funktion stimmt im wesentlichen mit PeDas Funktion in einer 
DS1820-Lib (zu finden in der Codesammlung) überein. Von daher geh ich 
davon aus, dass das prinzipiell korrekt ist, wenn du am richtigen 
Portpin mit dem Programm hängst und dein µC korrekt aufgebaut ist (Vcc, 
AVcc, GND, Blockkondensatoren etc.)

[spongebrot (Gast)]

Wie kann ich kontrollieren, ob die frequenz stimmt (hab kein oszi)

_delay_us verwend ich nicht, weil ich gelesen hab:
The maximal possible delay is 768 us / F_CPU in MHz.

was bei mir 48 wäre (viel zu wenig).

Dass die uC richtig angesteckt ist bin ich mir sehr sicher, weil alle 
anderen sachen (LCD display, LEDs) auch funktionieren

[Felix P. (fixxl)]

Was mir auffällt:
Die Funktion heißt bei der Definition, bei der übrigens ein void in der 
Klammer fehlt:

uint8_t Thermometer::reset()

Aufgerufen wird in der main:

_thermometer.reset()

Aus eigener Erfahrung mit dem DS18B20 kann ich dir versichern, dass die 
_delay_us-Funktion ihren Dienst auch bei diesen hohen Werten so 
verrichtet, dass der Sensor wie gewünscht läuft.

[Karl H. (kbuchegg)]

spongebrot schrieb:
> Wie kann ich kontrollieren, ob die frequenz stimmt (hab kein oszi)

#define F_CPU 16000000UL

#include <avr/io.h>
#include <util/delay.h>

#define DDR_LED  DDRB
#define PORT_LED PORTB
#define LED      PB0


int main()
{
  DDR_LED |= (1<<LED);

  while( 1 )
  {
    PORT_LED |= (1<<LED);
    _delay_ms( 1000 );
    PORT_LED &= ~(1<<LED);
    _delay_ms( 1000 );
  }
}

wenn dein µC mit 16Mhz läuft, dann ist die LED 1 Sekunde an / 1 Sekunde 
aus. Läuft der noch mit 1Mhz, dann sind das nicht 1 Sekunde sondern 16.
Sieht man auch ohne Oszi mit freiem Auge.

Trag in den #define deine Werte für eine LED ein und sieh nach was 
passiert.

Es geht nicht darum, ob der Takt jetzt genau 16000000Hz ist oder doch 
eher 15980000. Es geht darum, ob das 16Mhz oder 8Mhz oder 4Mhz oder 1Mhz 
sind. Und das lässt sich leicht feststellen und unterscheiden.

> _delay_us verwend ich nicht, weil ich gelesen hab:
> The maximal possible delay is 768 us / F_CPU in MHz.

Das gilt schon seit Jahren nicht mehr.
Deine Unterlagen sind veraltet.

[Karl H. (kbuchegg)]

spongebrot schrieb:

> Dass die uC richtig angesteckt ist bin ich mir sehr sicher, weil alle
> anderen sachen (LCD display, LEDs) auch funktionieren

Dieses Argument versteh ich nicht :-)

Wenn du im Programm den (hausnummer) Pin 5 vom Port B ansprichst, dein 
DS1820 aber am Pin 6 hängt, dann funktioniert das nicht. Unabhängig 
davon, ob das LCD funktioniert oder nicht. Falscher Pin ist falscher 
Pin.

[spongebrot (Gast)]

Aso, Pin hab ich schon getestet (einfach mal auf ausgang geschaltet + 
high, das hat hingehaun.

Das mit der LED werd ich dann mal testen wenn ich wieder zuhause bin.

Ausserdem werde ich dann auf _delay_us umsteigen, wenn das eh mit 
höheren werten funktioniert (hab das nur im avr studio im intellisense 
gelesen..)

[spongebrot (Gast)]

Kann's sein, dass das mim Timing nicht hinhaut, weil ich ein ~1m langes 
kabel zwischen sensor und uC habe, dass sich das ein bisschen verzögert?

[spongebrot (Gast)]

So, hab jetzt die Frequenz getestet. Die 16 MHz stimmen schon (schönes 
blinken im 1Sek takt..)

Mein Code:

Main:

#include <avr/io.h>

#ifndef F_CPU
#define F_CPU 16000000UL
#endif
#include <util/delay.h>

#include "include/Statuslight.h"
#include "include/Thermometer.h"
int main(void)
{
  Statuslight _statusLight = Statuslight();
  Thermometer _thermometer = Thermometer();
  
  if(_thermometer.reset())
    _statusLight.red();
  else
    _statusLight.green();
    while(1)
    {
    //TODO:: Please write your application code 
    }
}

Thermometer.h:

#ifndef THERMOMETER_H_
#define THERMOMETER_H_

#ifndef F_CPU
#define F_CPU 16000000UL
#endif

#include <avr/io.h>
#include <util/delay.h>

#define THERM_REGISTER  DDRD
#define THERM_PORT    PORTD
#define THERM_PIN    PIND
#define THERM_PORT_NUM  PORTD5

class Thermometer
{
public:
  Thermometer();
  uint8_t reset();
private:
};

#endif /* THERMOMETER_H_ */

und Thermometer.cpp:

#include "../include/Thermometer.h"
#include <util/atomic.h>

#define THERM_INPUT_MODE()    THERM_REGISTER &= ~(1<<THERM_PORT_NUM)
#define THERM_OUTPUT_MODE()    THERM_REGISTER |= (1<<THERM_PORT_NUM)
#define THERM_LOW()        THERM_PORT &= ~(1<<THERM_PORT_NUM)
#define THERM_HIGH()      THERM_PORT |= (1<<THERM_PORT_NUM)
#define THERM_GET_IN()      (THERM_PIN & (1<<THERM_PORT_NUM))

#define THERM_CMD_CONVERTTEMP 0x44
#define THERM_CMD_RSCRATCHPAD 0xbe
#define THERM_CMD_WSCRATCHPAD 0x4e
#define THERM_CMD_CPYSCRATCHPAD 0x48
#define THERM_CMD_RECEEPROM 0xb8
#define THERM_CMD_RPWRSUPPLY 0xb4
#define THERM_CMD_SEARCHROM 0xf0
#define THERM_CMD_READROM 0x33
#define THERM_CMD_MATCHROM 0x55
#define THERM_CMD_SKIPROM 0xcc
#define THERM_CMD_ALARMSEARCH 0xec


Thermometer::Thermometer(){
}

uint8_t Thermometer::reset(){
  uint8_t err = 0;
  THERM_LOW();
  THERM_OUTPUT_MODE();
  _delay_us(480);
  ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
    THERM_INPUT_MODE();
    _delay_us(64);
    err = THERM_GET_IN();
  }
  _delay_us(480-64);
  if( THERM_GET_IN() == 0)
    err = 1;
  return err;
}

Statuslight ist uninteressant, das schaltet nur die Led ein/aus

Reset funktioniert noch immer nicht :(

[Karl H. (kbuchegg)]

> Reset funktioniert noch immer nicht :(

Das ist interessant, denn eigentlich dauert der Presence Puls, den der 
DS1820 nach dem erkennen der fallenden Flanke auslöst nur so um die 
240µs rum. Nach 480µs sollte der Bus eigentlich schon längst wieder High 
sein.

Hast du schon mal probiert, was eigentlich der Default-Zustand deines 
Busses ist? Durch den externen Pullup sollte der ja eigentlich High 
sein. Sollte - aber ist er das auch?


Zieh mal den DS1820 ab (aber den Pullup lässt du drann).
So wie die Reset programmiert ist, dürfte das eigentlich KEINEN Fehler 
ergeben.

[Karl H. (kbuchegg)]

Wenn alle Stricke reißen, dann poste mal ein Bild von deinem Aufbau. 
Aber so, dass man die Verkabelung nachvollziehen kann. Ich werde das 
Gefühl nicht los, dass da irgendwas nicht stimmt.

[spongebrot (Gast)]

Also es ist jetzt so:

Wenn ich den Pin auf Eingang schalte:
-Kein sensor angehägt --> pin auf high
-Sensor angehängt --> pin auf low

stimmt das so?

[spongebrot (Gast)]

Zieh mal den DS1820 ab (aber den Pullup lässt du drann).
So wie die Reset programmiert ist, dürfte das eigentlich KEINEN Fehler
ergeben.

doch, da sollte schon ein fehler kommen, wenn ichs richtig denk

err = THERM_GET_IN();

dadurch wird err doch schon gesetzt? (und ohne sensor dank pullup -> 1)

[Karl H. (kbuchegg)]

spongebrot schrieb:

> err = THERM_GET_IN();
>
> dadurch wird err doch schon gesetzt? (und ohne sensor dank pullup -> 1)

Ach Mist.
Das nachfolgende

  if( (THERM_PIN & (1<<THERM_PORT_NUM)) == 0)
    err = 1;
  return err;

setzt ja nur dann einen err, wenn der Pin nicht wieder zurück auf 
High-gegangen ist. Das hab ich bisher komplett übersehen.

Hast du auch mehrere LED?
Wenn ja, dann mach mal diese Änderung

uint8_t Thermometer::reset(){
  uint8_t err = 0;
  THERM_LOW();
  THERM_OUTPUT_MODE();
  _delay_us(480);
  ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
    THERM_INPUT_MODE();
    _delay_us(64);
    err = THERM_GET_IN();
  }
  _delay_us(480-64);
  if( THERM_GET_IN() == 0)
    err = 2;       // <---------------------
  return err;
}

und sieh mal nach, ob dein Returnwert 1 oder 2 ist.
Damit wir mal sehen, woher der Error eigentlich kommt. Ob der DS die 
Leitung nicht auf Low zieht oder ob er sie nicht korrekt frei gibt.

Tschuldigung: Ich hatte das komplett falsch gelesen und bin immer davon 
ausgegangen, dass die zweite err-Bedingung der Auslöser des Problems 
ist.

[spongebrot (Gast)]

nix angesteckt kommt natürlich der erste error (input ist auf high)

Wenn ichs angesteckt habe kommt immer der zweite (Wird auf low gezogen, 
allerdings gehts nicht wieder auf high), und ja, ich hab auch geprüft, 
obs zuerst auch auf low gezogen wird, also trifft nur die 2. bedingung 
zu..

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

Irgendwelche Compiler-Warnungen ignoriert?

[spongebrot (Gast)]

Keine Warnungen, Keine Errors..

[Karl H. (kbuchegg)]

spongebrot schrieb:


> und ja, ich hab auch geprüft,
> obs zuerst auch auf low gezogen wird

was muss ich darunter verstehen?

Hast du geprüft, ob die Leitung noch ehe du den DS überhaupt ansprichst, 
schon auf Low ist?

> , also trifft nur die 2. bedingung
> zu..

Seltsam.

Ich kann mir nur noch einen Verkabelungsfehler vorstellen. Oder des DS 
hat seinen magischen Rauch ausgeblasen.

[F. F. (foldi)]

spongebrot schrieb:
> Kann's sein, dass das mim Timing nicht hinhaut, weil ich ein ~1m langes
> kabel zwischen sensor und uC habe, dass sich das ein bisschen verzögert?

Lies dir doch mal die paar Seiten vom Sensor Datenblatt durch, da wir 
der 1-Wire sehr gut beschrieben. Es gibt auch zig fertige Sachen um den 
anzusprechen.
Wenn du einen Kilometer dazwischen hast, dann musst du dir Gedanken um 
die Kabellänge machen.

[F. F. (foldi)]

Wo ist denn überhaupt die Adresse vom Sensor?

Entweder sehe ich das heute Abend nicht mehr (kann ja sein, wegen der 
ganzen Schmerzmittel) oder du spricht den gar nicht an.
Du musst doch erstmal die Adresse vom Sensor auslesen und wenn du die 
hast, dann kannst du den auch ansprechen

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

F. Fo schrieb:
> Wo ist denn überhaupt die Adresse vom Sensor?

Er scheitert doch schon vorher. Ausserdem kann man einen einzelnen 
Sensor am Bus auch ohne Adressierung betreiben.

[F. F. (foldi)]

A. K. schrieb:
> F. Fo schrieb:
>> Wo ist denn überhaupt die Adresse vom Sensor?
>
> Er scheitert doch schon vorher. Ausserdem kann man einen einzelnen
> Sensor am Bus auch ohne Adressierung betreiben.

Datenblatt, Datenblatt, das dachte ich auch immer, wenn sie mir damit 
kamen, aber es ist schon nicht so übel da mal einen Blick rein zu 
werfen.

Wenn ich "Klaus" rufe und nur "Hans" da ist, dann klappt das schon. Wenn 
ich aber gar keinen Namen rufe, wer soll dann wissen wer gemeint ist?

Das Datenblatt ist wirklich sehr gut gemacht und es sind gerade mal 23 
Seiten.

[F. F. (foldi)]

Bin hier bestimmt nicht eines der hellsten Lichter, aber den Sensor habe 
ich nach einer Woche mit Arduino spielen zum laufen gebracht.
Erst nachdem ich die fertigen Sachen getestet hatte und anhand des 
Datenblattes verstand, was da geschieht, erst dann habe ich das an meine 
Bedürfnisse angepasst.

[Karl H. (kbuchegg)]

F. Fo schrieb:

> Wenn ich "Klaus" rufe und nur "Hans" da ist, dann klappt das schon. Wenn
> ich aber gar keinen Namen rufe, wer soll dann wissen wer gemeint ist?


Soweit ist er doch noch gar nicht.


Wenn man die Datenleitung für eine bestimmte Mindestzeit auf Low zieht 
und wieder loslässt, dann antwortet der DS seinerseits damit, dass er 
die Leitung auf Low zieht und wieder loslässt. Während dieser Zeit 
resettet sich der DS.

Und daran scheitert es bereits. Da ist noch gar nichts mit 
Datenübertragung. Das ist ein reines 'Huhu, ist da wer?'

[Karl H. (kbuchegg)]

F. Fo schrieb:
> Bin hier bestimmt nicht eines der hellsten Lichter, aber den Sensor habe
> ich nach einer Woche mit Arduino spielen zum laufen gebracht.

Siehste.
Aber wie man den DS anspricht hast du immer noch nicht kapiert. :-)
Arduino Systematik eben.

Im Ernst. Es ist auch keine Hexerei. In der Codesammlung gibt es Code 
vom PeDa, mit der hat man einen oder mehrere DS in 10 Minuten am laufen. 
Sein Reset Code stimmt mit dem dortigen überein.

Nur irgendwas stimmt bei ihm nicht. Die Frage ist was.

[F. F. (foldi)]

Karl Heinz Buchegger schrieb:
> F. Fo schrieb:
>
>> Wenn ich "Klaus" rufe und nur "Hans" da ist, dann klappt das schon. Wenn
>> ich aber gar keinen Namen rufe, wer soll dann wissen wer gemeint ist?
>
>
> Soweit ist er doch noch gar nicht.
>
>
> Wenn man die Datenleitung für eine bestimmte Mindestzeit auf Low zieht
> und wieder loslässt, dann antwortet der DS seinerseits damit, dass er
> die Leitung auf Low zieht und wieder loslässt. Während dieser Zeit
> resettet sich der DS.
>
> Und daran scheitert es bereits. Da ist noch gar nichts mit
> Datenübertragung.

... klappt das schon nicht ... so sollte es heißen.

Ich hab das nur so grob überflogen.
Verstehe nicht, wieso er nicht erstmal was Fertiges nimmt und es später 
erst ändert.

[Karl H. (kbuchegg)]

F. Fo schrieb:

> Verstehe nicht, wieso er nicht erstmal was Fertiges nimmt und es später
> erst ändert.

Weil das, so wie es aussieht, nichts nützen würde.
Seine Software ist grundsätzlich in Ordnung. Aber ob es seine Hardware 
ist, kann man aus der Ferne schlecht sagen. Ich kann es nur vermuten, 
nachdem ich alle nur denkbaren Programmfehler ausgeschlossen habe. Und 
mittlerweile hab ich die so gut wie alle ausgeschlossen.

[F. F. (foldi)]

Aber gerade zu diesem Sensor kommen immer wieder Fragen, die eine viel 
bessere Antwort im Datenblatt finden, als hier im Forum.
Ist auch wirklich ein geniales Teil. War aber dann doch der DHT11 besser 
für mein Projekt, weil der die Feuchtemessung gleich mit drauf hatte.
Aber durch das Datenblatt hab ich den Bus schon mal verstanden und der 
DHT11 klappte dann auch sofort.
Ich neige auch dazu, bevor ich 12 Kilo Papier lese, erstmal zu fragen. 
Nur hier sind es nur einige wenige Seiten.

[Karl H. (kbuchegg)]

F. Fo schrieb:
> Aber gerade zu diesem Sensor kommen immer wieder Fragen, die eine viel
> bessere Antwort im Datenblatt finden, als hier im Forum.

Stimme ich dir alles zu.

Wenn du meine Meinung akzeptierst. Ich sehe im Code keinen Fehler. Schon 
im allerersten Posting war der Code soweit in Ordnung. Meiner Meinung 
nach ist aus AVR-Programm-Sicht alles in Ordnung und so wie es sein 
soll.
und trotzdem klappt es nicht.

Deine Analyse?

[spongebrot (Gast)]

Ich hab auch die ganze zeit das Datenblatt offen, und dort hab ich 
gelesen, dass als erstes die Initialization Sequence kommt mit 
Reset-Pulse + Presence-Pulse als antwort vom Sensor.
Erst dann kommen die ROM-Commands (Da brauch ich doch eh nur SkipRom, 
dann brauch ich den rom nicht auslesen?)

Was mich ein bisschen stutzig macht ist, dass wenn ich einfach nur den 
Port auf eingang schalte, ohne den reset-pulse zuerst, ich immer LOW am 
eingang habe (Sollte er nicht eigentlich auf HIGH springen ?)

[Karl H. (kbuchegg)]

spongebrot schrieb:
> Also es ist jetzt so:
>
> Wenn ich den Pin auf Eingang schalte:
> -Kein sensor angehägt --> pin auf high
> -Sensor angehängt --> pin auf low
>
> stimmt das so?

Moment.
Das ist interessant.

Nein, das stimmt nicht!
Egal ob du den Sensor anhängst oder nicht, die Leitung muss auf High 
bleiben. (Ok, für die kurze Zeit, in der der Reset und der Presence Puls 
laufen natürlich nicht. Aber die sind so kurz, dass du das maximal als 
kleines Flackern merkst). ABer wenn du mit einem Testprogramm lediglich 
den Pin auf Eingang schaltest und sonst nichts anderes tust, dann muss 
der Pin auf High bleiben.


Bild vom Aufbau.
Pinbelegung noch mal checken.
Wenn sich da auch nichts zeigt, dann muss man wohl davon ausgehen, dass 
der DS defekt ist.

[Karl H. (kbuchegg)]

So muss der angeschlossen sein.

Prüfpunkte
* hast du auch wirklich einen Pullup gebaut und keinen Pulldown?
* hast du beim DS vielleicht den Vcc mit dem GND Pin verwechselt?

[spongebrot (Gast)]

Ok, dann werd ich mal die Kabel vom Sensor vertauschen (Data und GND), 
mal schaun, ob die chinesen da irgendwas verdreht haben.
Normal (War leider kein Datenblatt dabei) is doch:
Rot: VCC
Gelb: Data
Grün: GND

?

[F. F. (foldi)]

Karl Heinz Buchegger schrieb:
> F. Fo schrieb:
>> Aber gerade zu diesem Sensor kommen immer wieder Fragen, die eine viel
>> bessere Antwort im Datenblatt finden, als hier im Forum.
>
> Stimme ich dir alles zu.
>
> Wenn du meine Meinung akzeptierst. Ich sehe im Code keinen Fehler. Schon
> im allerersten Posting war der Code soweit in Ordnung. Meiner Meinung
> nach ist aus AVR-Programm-Sicht alles in Ordnung und so wie es sein
> soll.
> und trotzdem klappt es nicht.
>
> Deine Analyse?

Karl Heinz, du bist doch sowieso der von mir hochgeschätzte Guru und 
wenn du sagst da ist kein Fehler, dann wird da keiner sein.
Nach einer kurzen Pause und noch mal alles lesen, da habe ich weiter 
unten die Initialisierung im späteren Post gesehen. Ich hatte nur das 
oben gelesen und da war ja davon nichts zu sehen.

Sorry. Da bin ich dann wohl drüber gescrollt.

[Karl H. (kbuchegg)]

spongebrot schrieb:
> Ok, dann werd ich mal die Kabel vom Sensor vertauschen (Data und GND),
> mal schaun, ob die chinesen da irgendwas verdreht haben.
> Normal (War leider kein Datenblatt dabei) is doch:
> Rot: VCC
> Gelb: Data
> Grün: GND
>
> ?

Moment.
Hast du das Kabel nicht selber gelötet?

Kannst du das am DS direkt überprüfen, wie die Adern angeschlossen sind? 
Für Gelb oder Grün würde ich meine Hand nicht ins Feuer legen.
Normal ist Vcc-Rot, GND-schwarz

[F. F. (foldi)]

Karl Heinz Buchegger schrieb:
> spongebrot schrieb:
>> Ok, dann werd ich mal die Kabel vom Sensor vertauschen (Data und GND),
>> mal schaun, ob die chinesen da irgendwas verdreht haben.
>> Normal (War leider kein Datenblatt dabei) is doch:
>> Rot: VCC
>> Gelb: Data
>> Grün: GND
>>
>> ?
>
> Moment.
> Hast du das Kabel nicht selber gelötet?
>
> Kannst du das am DS direkt überprüfen, wie die Adern angeschlossen sind?

Wird mal Zeit für ein Bild des Sensors.
Bei mir sind die "nackig", wenn ich die von Reichelt bekomme.

[spongebrot (Gast)]

nein, is alles wasserdicht verpackt mit einer taucherhülse..

hab extra das ganze internet durchsucht wegen der farbbelegung von den 
drähten, und überall is das selbe gestanden, nur mein kabel dürfte 
anscheinend anderst herum eingebaut sein :-/

Habs umgelötet --> Grünes Licht..

[Karl H. (kbuchegg)]

spongebrot schrieb:
> nein, is alles wasserdicht verpackt mit einer taucherhülse..
>
> hab extra das ganze internet durchsucht wegen der farbbelegung von den
> drähten, und überall is das selbe gestanden, nur mein kabel dürfte
> anscheinend anderst herum eingebaut sein :-/
>
> Habs umgelötet --> Grünes Licht..

:-)

Den PeDa Code in der Codesammlung dürftest du ja schon gefunden haben 
(deiner Reset Funktion nach zu urteilen). Die beiden 
Bitübertragungsfunktionen noch anpassen und der Rest müsste eigentlich 
so wie er ist funktionieren.

[F. F. (foldi)]

spongebrot schrieb:
> nein, is alles wasserdicht verpackt mit einer taucherhülse..
>
> hab extra das ganze internet durchsucht wegen der farbbelegung von den
> drähten, und überall is das selbe gestanden, nur mein kabel dürfte
> anscheinend anderst herum eingebaut sein :-/
>
> Habs umgelötet --> Grünes Licht..

Da kann man mal sehen :-) wie alle rum rätseln können und der Fehler so 
einfach sein kann.
Sicher war ich nicht der einzige hier, der von einem "nackten" Sensor 
ausgegangen war.
Noch ein Tipp. Die brauchst du gar nicht vergossen zu kaufen. Mit einem 
Stück Plastikschlauch und Silikon kannst du die toll selbst wasserdicht 
machen.

[Karl H. (kbuchegg)]

Karl Heinz Buchegger schrieb:

> Den PeDa Code in der Codesammlung dürftest du ja schon gefunden haben
> (deiner Reset Funktion nach zu urteilen).

Beitrag "DS1820, DS18B20 in C"

In längstens einer halben Stunde will ich von Resultaten in Form von 
korrekten Messwerten hören!
:-) :-)

[Karl H. (kbuchegg)]

F. Fo schrieb:

> Da kann man mal sehen :-) wie alle rum rätseln können und der Fehler so
> einfach sein kann.

Fehler sind immer einfach - hinterher, wenn man die Ursache kennt.

[F. F. (foldi)]

Karl Heinz Buchegger schrieb:
> F. Fo schrieb:
>
>> Da kann man mal sehen :-) wie alle rum rätseln können und der Fehler so
>> einfach sein kann.
>
> Fehler sind immer einfach - hinterher, wenn man die Ursache kennt.

Das erlebe ich fast täglich. Ich bin Service Techniker und repariere 
Gabelstapler (Flurförderzeuge heißt es richtig) und da bekomme ich immer 
alles mögliche erzählt und wenn ich dann da bin, stellt sich der Fehler 
völlig anders da.
Hauptsache fertig.
Tut mir leid, dass ich den richtigen Code zunächst nicht gesehen hatte.
Danke Karl Heinz, dass du mich drauf hingewiesen hast.

[spongebrot (Gast)]

So.
Es funktioniert jetzt alles soweit (ausser dass ich nicht glaub, dass es 
wirklich nur 26°C in meinem zimmer hat.. füht sich an wie 50..

Danke an alle, die mitgeholfen haben!

Ich schaffs irgendwie immer wieder, dass so blöde fehler die ursache 
sind :-/