ADC Messung falsch

Ohne das jetzt konkret analysiert zu haben, ob das deine Ergebnisse 
bestätigt:

return_temp = ((temp*5)/1024)*3.2;

Siehe
http://www.mikrocontroller.net/articles/FAQ#Datentypen_in_Operationen
und denk darüber nach, wie sich das auf die Division durch 1024 bei dir 
auswirkt.

Generell: Du möchtest in einem Ausdruck Divisionen so weit wie möglich 
nach rechts schieben, so dass sie so spät wie möglich abgearbeitet 
werden.

Andi schrieb:

> Also ändere ich alle meine Datentypen in unsigned int und die
> Rückrechnung:
>
> return_temp = (temp*125)/8;

Das ist nur die halbe Miete.
Du musst auch auf die Zahlenbereiche achten.


> ADC = 3V*1024 /5 = 614,4
> müsste im ADC Register 614 stehen.

OK.

>
> temp  = ADCL;
>     temp += (ADCH<<8);

Warum so kompliziert. Lass das doch den Compiler machen. Der weiß schon, 
wie man mit 16 BIt Registern umgeht:

    temp = ADCW;


> return_temp = (temp*125)/8 = 9593,75 mV

Nö.
Du hast das Zwischenergebnis vergessen

     614 * 125 = 76750

Mööp. 76750 ist zu groß für einen 16 Bit unsiged int. Bei 65535 ist 
Schluss. Darüber gibts einen Overflow.

Der Compiler wählt nicht nur die Art der Berechnung anhand der 
Datentypen der Operation aus, sondern auch in welchem Datentyp das 
Ergebnis vorliegen wird. Bei dir ist das alles unsigned int. Du hast 
also eine 16 Bit * 16 Bit Multiplikation, die ein 16 Bit Ergebnis 
bringen wird. Und dein Zwischenergebnis ist schlicht und ergreifend zu 
groß für 16 Bit.

> also liefert retun_temp 9593 zurück.

nicht ganz.
Es liefert 11214 / 8 = 1401

11214, weil die Multiplikation überlaäuft und du nicht 76750 sondern 
76750 - 65536 = 11214 bekommst

   return_temp = (temp * 125UL) / 8;

Jetzt müsste das richtige rauskommen. Durch die 125UL forciere ich eine 
Berechnung als unsigned long

Andi schrieb:

> Hatte es dann mit "uint32_t" als Typ probiert aber das ging nicht.
> aber mit 125UL geht es.

Doch, das geht genauso.
Nur wirst du es falsch gemacht habe :-)

Du musst temp auf uint32_t casten, BEVOR die Multiplikation stattfindet. 
Danach ist es zu spät

return_temp = ( (uint32_t)temp * 125) / 8;

Andi schrieb:
> Karl heinz Buchegger schrieb:
>> Doch, das geht genauso.
>> Nur wirst du es falsch gemacht habe :-)
>
> ja ich hatte return_temp als uint32_t und temp normal unsigned int
> gelassen...;)

:-)
dachte ich mir schon.
Also der klassische Fall aus der FAQ

1

Warum kriege ich bei

2

3

  double i = 5 / 8;

4

5

keine Nachkommastellen?

Gleiche Ursache :-)

Weil es für den Compiler irrelevant ist, was mit einem Ergebnis gemacht 
wird. Die Art und Weise wie eine bestimmte Operation durchgeführt wird 
(im Zahlenraum welchen Datentyps gerechnet wird) hängt einzig und 
alleine von den beteiligten Operanden ab und von sonst gar nichts.

  temp * 125
wird, so wie es da steht, im Zahlenraum unsigned int gerechnet. Selbst 
wenn du das Ergebnis in 128 Byte Fliesskommaformat-Variablen mit 
hyperbolischem Exponenten in trinärer Darstellung und gelbem Kommapunkt 
abspeicherst: Diese Multiplikation findet in unsigned int statt und in 
sonst nichts anderem. Da fährt die Eisenbahn drüber. Erst mit dem 
Ergebnis wird dann wieder etwas gemacht. Aber dann ist es zu spät sich 
über Overflows den Kopf zu zerbrechen.

Willst du das nicht, dann muss mindestens einer der beiden, entweder 
temp oder 125 oder alle beide, zu einem unsigned long werden. Nur die 
beiden Teilnehmer an der Operation sind relevant und steuern das.