AVR GCC Rechenfehler?

[Sören (Gast)]

Hallo,

folgende Zeile liefert falsche Ergebnisse:
u16_adcBatt = (ADCH * 330) / 256;

ebenso
u16_adcBatt = (ADCH * 330) >> 8;

Wenn das ganze schrittweise gerechnet wird, ist das Ergebnis korrekt:
u16_adcBatt = (ADCH * 330);
u16_adcBatt = u16_adcBatt / 256;

Kann jemand erklären, warum das so ist?
Besten Dank!

Sören

[Sören (Gast)]

Es kommt dann so etwas wie 0xFFC8 raus, wenn ein Wert um ca. 0x0082
erwartet wird.

[Paul (Gast)]

Was liefert

u16_adcBatt = ((unsigned int)ADCH * 330) / 256;

?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Sören schrieb:
> Kann jemand erklären, warum das so ist?
Es hängt mit vermutlich mit Datentypen und Wertebereichen zusammen.

> folgende Zeile liefert falsche Ergebnisse:
> u16_adcBatt = (ADCH * 330) / 256;
Welche denn? Für welchen Prozessor?

[Kein Name (Gast)]

Nach C Standard muss der Compiler zuerst ADCH in int umwandeln. Die 
meisten MC-Compiler rechnen aber mit 8 Bit Zahlen.

[Sören (Gast)]

Das scheint zu funktionieren. Und auch, wie ich eben gefunden habe, wenn
u16_adcBatt = (ADCH * 330L) / 256;

geschrieben wird.

Jetzt funktioniert das zwar, danke für die schnelle Hilfe!
Aber ich verstehe noch nicht, wo das Problem lag.

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

Sören schrieb:
> folgende Zeile liefert falsche Ergebnisse:
> u16_adcBatt = (ADCH * 330) / 256;

(ADCH * 330) wird als int gerechnet und läuft über.
100 * 330 = 33000 > 32767

> Wenn das ganze schrittweise gerechnet wird, ist das Ergebnis korrekt:

Nö, nicht bei z.B. ADCH=255.

[Sören (Gast)]

Verstehe. Und was macht bei der zweiten Möglichkeit das 330L? Damit 
geht's dann nämlich auch.

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

Sören schrieb:
> Verstehe. Und was macht bei der zweiten Möglichkeit das 330L? Damit
> geht's dann nämlich auch.

Wird als long gerechnet und läuft nicht über.

[Sören (Gast)]

OK, wieder was gelernt!
Euch vielen Dank für die Hilfe und Geduld.