Vergleich von Variable mit Zahl geht nicht

Hallo zusammen,

erstmal vielen Dank für die schnellen Antworten!

@Preisfrage:
Wenn ich test eine 0 zuweise anstatt den Wert (vom ADC) result, dann 
leuchtet die LED nie, da 0*1000 gleich ist wie 0*100. Habe ich 
ausprobiert.

@lala:
Wenn ich "test" einen negativen Wert zuweise geht es manchmal (z.B. test 
= -500) und manchmal nicht (z.B. test = -50). Aber "test" ist ja 
unsigned?!

@Robert R.:
Ohne die *1000 resp. *100 geht es.
Ich habe es jetzt mal mit 65 ausprobiert: Vergleich ist richtig!
Bei 66: Vergleich ist falsch!

EDIT:
Aber im Vergleich if(test*1000 > test*100) wird die Variable "test" doch 
gar nicht verändert?
Und wieso optimiert der Compiler den Vergleich nicht und kürzt mit 100?




lg Adrian

Adrian W. schrieb:
> Und wieso optimiert der Compiler den Vergleich nicht und kürzt mit 100?

Für die (Unsigned-)Integer-Arithmetik gibt es in C spezielle Regeln.
Auszug aus dem C-Standard:

1

A computation involving unsigned operands can never overflow, because a

2

result that cannot be represented by the resulting unsigned integer type

3

is reduced modulo the number that is one greater than the largest value

4

that can be represented by the resulting type.

Selbst wenn der Compiler so intelligent wäre, beide Operanden des
Vergleichs durch 100 zu dividieren, dürfte es dies schlichtweg nicht
tun, oder er dürfte sich nicht mehr "C-Compiler" nennen.

OK, also wird das nicht optimiert, aber welches ist denn der "resulting 
unsigned integer type"?

lg Adrian

Das kommt aud die Größe vom int an.
Wenn der Wertebereich von uint16_t komplett in int abgebildet werden 
kann, dann int, sonst unsigned int.

Hallo,

> test*3 > test*2 ist vom ergebnis her das selbe wie test*1000 > test*100

Darf der Compiler jetzt schon selbst logarithmieren, wenn er lustig ist?

Martin

Klausi schrieb:
> Man kann auch einfach if(1) schreiben. Oder es ganz weglassen. :)

Genau das eben NICHT!

Für Test == 0 fehlt die Elisabeth (oder besser: das Else).  ;-)

Hallo, da bin ich wieder :)

Es tut mir leid, dass ich euch nicht genauer informiert habe.
Das *1000 resp. *100 hatte es gebraucht, weil mein eigentlicher code so 
aussieht:

1

2

if(var1 + var2 + var3*20000 > var4*1000)

3

{

4

  PORTC |= (1<<PORTC5);  //LED an

5

}        

6

else

7

{

8

  PORTC &= ~(1<<PORTC5);  //LED aus

9

}

Die Multiplikation braucht es bei meinem Programm.

Da ich aber nicht verstanden habe, wieso es bei grossen Zahlen wie 20000 
nicht funktioniert, wollte ich das Problem eingrenzen.

Ich habe immer gedacht, dass der Typ bei einer Rechnung in einem 
Vergleich keine Rolle spielt, da der Wert (z.B. var3*20000) ja gar nicht 
der Variable (z.B. var3) zugewiesen wird.

Wieso hat eigentlich bei einem 8-Bit Mikrocontroller der Datentyp "int" 
16 Bits?

lg Adrian

Adrian W. schrieb:
> Wieso hat eigentlich bei einem 8-Bit Mikrocontroller der Datentyp "int"
> 16 Bits?

Weil der C Standard für "int" mindestens 16 Bits fordert.

Ein Cast an der richtigen Stelle löst dein Problem.

1

if((uint32_t)test*1000 > (uint32_t)test*100)

@ A.K.: Ah ja, klar :)
Hätte ich wissen oder nachschauen müssen.

be stucki schrieb:
> Ein Cast an der richtigen Stelle löst dein
> Problem.if((uint32_t)test*1000 > (uint32_t)test*100)
Danke

Adrian W. schrieb:
> Und wieso optimiert der Compiler den Vergleich nicht und kürzt mit 100?

Der Compiler ist schlau.
Er optimiert nur dann etwas weg, wenn das am Ergebnis nichts ändert.

Peter Dannegger schrieb:
> Adrian W. schrieb:
>> Und wieso optimiert der Compiler den Vergleich nicht und kürzt mit 100?
>
> Der Compiler ist schlau.
> Er optimiert nur dann etwas weg, wenn das am Ergebnis nichts ändert.

... und zwar in allen denkbaren Fällen (mit allen überhaupt möglichen 
Zahlenwerten). Nicht nur in den Fällen, an die du jetzt denkst bzw. die 
dir in den Sinn kommen.