DS18s20: Zu hohe Temperatur

Ich weiss nicht, ob's mit dem Problem irgendwas zu tun hat, aber die
Steuerung vom 1W Pin scheint mir problematisch. 1-Wire ist immerhin als
Open-Drain-Bus definiert.

Vom Messvorgang mit parasitärer Stromversorgung vom Sensor mal
abgesehen, sollte es keinen Zeitpunkt geben, zu dem der Prozessor den
Pin aktiv hochzieht. Hier hingegen wird stets erst der Pin als Ausgang
definiert, dann der Wert gesetzt. D.h. für 1 Takt wird der Pin ggf.
hochgezogen - kommt ein Interrupt dazwischen, dann entsprechend
länger.

Insgesamt also: Das Output-Latch anfangs einmalig auf 0 setzen und so
stehen lassen. Danach nur noch per Direction-Register arbeiten, 0=high
via externem Pullup, 1=low.

Ansonsten: Peter Danegger hat dazu einen recht passablen Code
veröffentlicht. Versuch's mal damit. Der ist zwar auch nicht 100%
Interrupt-fest aber zum Test reicht es [der Fehler: wenn in
start_meas() nach ow_command und vor ow_parasite_enable einer
reinrutscht, dann geht beim Sensor das Licht aus].

Ich unterstuetze die Vermutung das es am Pegel liegt. Ich hab mal eine
Schaltung entwickelt die mit den ersten DS1820 im langen Gehaeuse
lieft. Als dann spaeter die neuen im kurzen Gehaeuse rauskam hat sie
nicht mehr funktioniert.
Ursache war bei mir das ich den Pullup-Widerstand vergessen habe.
<schaem> Den alten Typen war das interessanterweise egal, den neuen
aber nicht mehr. Die muessen sich da also irgendwie unterscheiden.

Olaf

@Peter: Schon ok so, wenn da bloss deine knapp gehaltenen Interrupts
dazwischen kommen - ich habe hier im Forum allerdings schon Interrupts
im MS-Bereich und drüber gesehen. Grad heute, wo jemand im seriellen
Interrupt den kompletten Inhalt eines DRAMs über die serielle würgt.

Ich hatte deinen Code vor allem deshalb nach so etwas durchforstet,
weil das bei Multitasking weit stärker ins Gewicht fällt. Da kann die
Pause schon mal länger dauern. Kapseln kam wiederum auch nicht in
Frage, weil's dafür zu lang dauert. Meine Lösung war, Bit- und
Byte-Routine mit abgeschaltetem Interrupt zu beenden und den Caller das
Einschalten zu überlassen. So sind die Interrupts nur jeweils für gut 15
µs ausgeschaltet.

@Peter:

Ich habe nicht die delay-Funktion aus der oben angehängten C-File
benutzt sondern die standardmäßig bei CodevisionAVR inkludierten
Funktionen.

Liegt da also die Ursache allen Übels?

Das wäre aber merkwürdig, da ich wie gesagt an den delay-Werten grob
rumgespielt habe und es hat sich entweder nichts an den
Scratchpad-Temperaturwerten geändert oder er hat schlagartig konstante
0xFF geliefert wegen falschen Timings.

Viele Grüße,
Henning