DS1820/DS18S20

> oder bin ich da auf dem Holzweg

Jein ;-)

Genaugenommen ist MSB das Most Significant Bit. Also nicht 0x00 oder 
0xFF stehen drin, sondern 0 und 1.

Da der Sensor nicht genau 8 oder 16 Bit zurückliefert, liegt es bei der 
Ansteuerlibrary bzw. deinen Einlesefunktionen wie die restlichen, nicht 
vom Sensor gelesenen Bits ergänzt werden.

Ich nehme das MSB und setze die anderen hochwertigen Bits dann 
entsprechend. Bsp. 9-Bit Ergebnis vom Sensor 0x1FF (= 511 dez.) 
erweitert auf 16-Bit => 0xFFFF (= -1 dez. im Zweierkomplement, d.h. wenn 
int16_t i = 0xFFFF;).

Ich beziehe mich im folgenden auf dieses Datenblatt:
http://datasheets.maxim-ic.com/en/ds/DS18S20.pdf

Das Datenformat der Antwort des Sensors ist in Figure 2 erklärt. Wie das 
Datenformat in dein Programm kommt, weiss ich nicht, da kein Sourcecode 
vorhanden ist. Daher im folgenden die Erklärung mit den Daten im 
Datenblatt.

Es gibt ein Least Significant Byte (LS) Bits 0-7 und ein Most 
Significant Byte (BS) Bits 8-15 einer 16-Bit Antwort.

In BS steht das Vorzeichen drin und in LS der Wert. Alle Bits von BS 
sind für das Vorzeichen da. Das was ich in der Nachricht oben 
geschrieben habe bzgl. einem einzelnen Bit und Auffüllen ab 9. Bit ist 
bei diesem Sensor falsch bzw. nicht nötig. Ich hatte da noch die 
Diskussion zum DS1620 im Kopp.

In Table 1 sind Beispielwerte angegeben:

<pre>
Temperatur     16-Bit-Wert        Hex.   Dez.
               BS        LS
----------------------------------------------
+0.5°C         00000000  00000001 0x0001   1
 0.0°C         00000000  00000000 0x0000   0
-0.5°C         11111111  11111111 0xFFFF   -1
</pre>

Der Wert 223 (dez.) = 0xDF = 0b11011111 dürfte in BS rein logisch 
gesehen nicht vorkommen. Ausgenommen es gibt Probleme bei der 
Ansteuerung des Sensors oder in der Abfragefunktion für den Sensor.

Der 16-Bit Wert ist ein signed Wert (mit Vorzeichen) und gibt 
vereinfacht gesagt die Zahl der 0,5°C Schritte bis zur gemessenen 
Temperatur an.

Wenn das Problem damit nicht in den Griff zu bekommen ist, schlage ich 
vor, dass du die Hosen runterlässt und deinen Quellcode zeigst, so dass 
man da nachforschen kann und nicht raten muss ;-)

Die DS18S20 Routinen sehen gut aus (von wem sind die?) und wenn der 
Sensor richtig angeschlossen ist (an PC0 mit externem Pullup) sollten da 
auch vernünftige Daten kommen.

Der Haken liegt IMHO in diesem Teil der diversen sensor_x Routinen:

1

  ldi  temp5, 0       ; temp5 = 0

2

  ori  temp5,0x30     ; temp5 += '0' // temp5 = '0'

3

  sts  rsbuff+0,temp5 ; rsbuff[0] = temp5

4

  ldi  temp5, 1       ; temp5 = 1

5

  ori  temp5,0x30     ; temp5 += '0' // temp5 = '1'

6

  sts  rsbuff+1,temp5 ; rsbuff[1] = temp5

7

8

; ... Einlesen des Messwertes ...

9

10

  ; Vorzeichenbehafteter 16-Bit Messwert steht in temp_msb temp_lsb

11

  lds temp5, temp_lsb 

12

  ror temp5

13

  rcall lcd_number

Das ist ungeeignet, um den Messwert auszugeben.

Es wird statt temp_msb auszuwerten ein konstanter String "01" ausgegeben 
und an den wird der in eine zweistellige Dezimalzahl gewandelte 
halbierte 8-Bit Wert aus temp_lsb angehängt.

Die richtige Variante wäre, temp_msb in die Ausgabe einzubeziehen. Z.B.

Zuerst prüfen, ob temp_msb 0x00 ist ('+' Vorzeichen oder ' ') oder 0xFF 
('-' Vorzeichen).

Wenn '-' Vorzeichen, dann Betrag von temp_lsb bilden (temp_lsb = 0 - 
temp_lsb).

Optional: Nachkommastelle (.5°C-Schritte) bearbeiten. Prüfen auf 0.5°C 
im LSB (1 => nachkommastelle = '5', 0 => nachkommastelle = '0').

temp_lsb durch 2 teilen.

Dann Vorzeichen ausgeben, temp_lsb ausgeben (3 Dezimalstellen: +125°C 
bis -55°C), optional '.' ausgeben, dann Nachkommastelle ausgeben.

> die werte die in rsbuff und rsbuff+1 drin stehen sind die sensor nummern
> damit ich weiss wo welcher sensor ist

Ah, das habe ich in der Source mit den vorhandenen Kommentaren nicht 
gesehen. Ich habe nur die Funktion sensor_0 näher angesehen. In sensor_1 
usw. wird dann wahrscheinlich die Inhalte von rsbuff und rsbuff+1 
hochgezählt.

> aber wie gesagt mit den werten unter null grad funktioniert bei mir
> jedenfalls nicht

Weiss ich, hast du schon geschrieben und ich weiss auch wieso ;-)

Wenn du deinen problematischen Quellcode nach meinem obigem Vorschlag 
umschreibst? Funktioniert es dann auch nicht? Wenn der Teil 
umgeschrieben ist, kannst du den ja wieder zum Begutachten an deine 
nächste Nachricht anhängen.

Du hast in deinem Programm eine UART-Übertragung drin. Ich würde die zum 
Debuggen nutzen und mir die Rohdaten in temp_msb und temp_lsb 
übertragen lassen und auf dem PC in HEX protokollieren (z.B. auf dem 
Windows-PC mit HTerm oder dem Br@y-Terminal aus dem Artikel RS232). 
Die Übertragung z.B. mit 4 Bytes: * für Start, temp_msb, temp_lsb, # für 
Ende des Telegramms. Das kannst du mitloggen und auch in einem 
Zip-Archiv an deine nächste Nachricht anhängen.

Ich schaue mir die Rohdaten an und ich hoffe der "zb." Quellcode inkl. 
dem seltsamen "print" ist in echt im Archiv. Wenn ja, checke ich den 
auch. Bis denn erstmal ;-)

...

Wieder da. Die Rohdaten sehen perfekt aus. Der Sensor arbeitet über Null 
und unter Null. Du hast nicht weit unter Null getestet, gell? In dem 
Assembler-Quellcode im Archiv ist keine Spur einer Umwandelroutine zu 
finden.

Mal sehen, ob ich das ohne Vorlage hinbekomme. Meine ASM-Kenntnisse 
beschränken sich nämlich auf's Debuggen. Komplett von Null losschreiben 
ist eine andere Kiste.

Wenn ich mich lange nicht mehr melde, habe ich mich in den 
Maschinenbefehlen verstrickt. Es kann sich für dich lohnen, dass du 
irgendeinen Quellcode beibringst, dir nur zu debuggen ist ;-)

So im Anhang ist mal was. Ich habe dein "temperatur zum pc.asm" 
umgestrickt, so dass man was Debugbares/Simulierbares bekommt.

Achtung, da ich den Sensor nicht habe, sind alle Funktionen hierzu als 
Dummyfunktionen (einfaches RET) drin. Nur read_scratchpad füllt temp_lsb 
und temp_msb für die Simulation. Pass auf, dass du deine Quellen 
sicherst und nicht überschreibst!

Die Umwandlungsfunktion 8-Bit => Dezimalzahl (ohne Unterdrückung der 
führenden Nullen) stammt aus dem AVR Tutorial. Vorzeichen, Komma und 
Nachkommastelle wie oben beschrieben.

ADD: Ich habe nicht das AVR Assembler Instruction Set gewälzt und die 
optimalen Befehle gesucht sondern genommen, was gerade passte. Da kannst 
du sicher noch Eleganz reinbringen ;-)