DS18s20: Zu hohe Temperatur

[Henning (Gast)]

Hallo zusammen,

habe schon erfolgreich mehrere DS1820s mit vorgefertigten Funktionen
aus CodevisionAVR verwendet, nun habe ich einen Stapel DS18s20 hier
rumliegen (genauer gesagt die DS18s20z im 8pin-Gehäuse), mit den
gleichen Funktionen und Timings bekomme ich jedoch ca. 200° anstatt ca.
25-30° geliefert.

Wenn ich diese mitgelieferten CodevisionAVR-Libraries für 1Wire und den
DS1820 durch manuelle ersetze (siehe Anhang, Code ist hier aus dem
Forum), dann bekomme ich auf einmal Temperaturen von ca. 90° anstatt
der 25-30°.

Nun dachte ich, dass das ein Timing-Problem sei, habe an den
µs-Verzögerungen manipuliert und rumgespielt, aber keine Annäherung an
die richtige Temperatur hinbekommen.

Hat jemand eine Idee?

Controller ist ATmega8535 (8MHz), ich schreibe in C und compiliere mit
CodevisionAVR.


Vielen Dank für jede Unterstützung.

Viele Grüße,
Henning

[A.K. (Gast)]

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

[Peter D. (peda)]

Hast Du Dir mal den Assembler von Deiner Delay-Routine angesehen ?

Eine Multiplikation zur Laufzeit und noch dazu im Schleifentest ist
zumindest für alle AT90S und ATTinys tödlich.

Zieh mal die Multiplikation raus per #define, es sind doch alles
konstante Delays.

Dann sollten auch kleine Delays (15µs) funktionieren.


@A.K.

wenn man längere Interrupts hat, muß man das kapseln.

In dem Beispiel ist aber nur ein sehr kurzer Timerinterrupthandler, da
geht es auch so.

In jedem Fall ist ja nach dem letzten Datenbit noch eine Pause von 60µs
bis das strong-pullup aktiviert werden kann, da machen 10µs mehr den
Kohl nicht fett.


Peter

[Olaf (Gast)]

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

[A.K. (Gast)]

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

[Henning (Gast)]

@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