signed int zahlen teilen

[Bernd S. (mms)]

Hi,

hab grad Schwierigkeiten zwei Werte (signed int) zu teilen -> als 
Ergebnis kommt immer 0x00 raus :-(


z.B.

signed int erg, zahl1, zahl2; 

zahl1 = 0xFFF42A00; 
zahl2 = 0x001CEF80

erg = zahl1 / zahl2;

Gruß
Bernd

[Karl H. (kbuchegg)]

Bernd Schuster schrieb:

> z.B.
>

> signed int erg, zahl1, zahl2;
> 
> zahl1 = 0xFFF42A00;
> zahl2 = 0x001CEF80
> 
> erg = zahl1 / zahl2;
> 
>

>

Auf einem AVR?

dir ist klar dass ein int auf einem AVR nur 16 Bit hat? 0xFFF42A00 ist 
von daher schon viel zu groß dafür.

Bei der Zuweisung wird daher 0xFFF42A00 zu 0x2A00
und 0x001CEF80 wird zu 0xEF80

Dezimal geschrieben: 10752 / -4224

Das müsste also eigentlich -2 ergeben
Wie gibst du das Ergebnis aus, bzw. woher weißt du, dass da 0 
herauskommt.

PS: das signed brauchst du nicht schreiben. int alleine tuts auch, und 
ist dann signed.

[Bernd S. (mms)]

das im erg 0x00 steht, sagt mir die Variable beim Debuggen.

Arbeite auf einem SMT32 (also mit 32Bit-Werten). Beim Keil Compiler muss 
signed geschrieben werden, da int alleine unsigned int entspricht.

Gruß
Bernd

[Detlev T. (detlevt)]

Ist doch alles richtig. Der Dividend 0xFFF42A00 entspricht -(0x000BD600) 
und ist damit (vom Betrag her) kleiner als der Divisor 0x001CEF80. Also 
kommt 0 heraus (bzw. -0 ;) )

[Bernd S. (mms)]

hab den fehler gefunden -> man müsste hier float oder double verwenden, 
wei das erg kleiner als null ist....

[U.R. Schmitt (Gast)]

Bernd Schuster schrieb:
> hab den fehler gefunden -> man müsste hier float oder double verwenden,
> wei das erg kleiner als null ist....

Nicht weril das Ergebnis kleiner 0 ist (-5 ist auch kleiner 0), sondern 
weil Du mit integer keine Bruchteile von ganzen Zahlen darstellen 
kannst.
Wichtig: der "geteilt"  Operator '/' rundet nicht sondern schneidet 
einfach ab, also 100 / 102 ist nicht 1 sondern 0.
Um Runden zu können musst Du das entweder mit dem % Operator zu Fuss 
machen oder Float benutzen und dann runden.

[Karl H. (kbuchegg)]

Bernd Schuster schrieb:
> hab den fehler gefunden -> man müsste hier float oder double verwenden,
> wei das erg kleiner als null ist....

Man müsste sich im Vorfeld besser überlegen was da eigentlich berechnet 
wird. Pauschal zu sagen "float oder double ist die Lösung" bedeutet oft 
nur vom Regen in die Traufe zu fallen.

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

Bernd Schuster schrieb:

> Beim Keil Compiler muss
> signed geschrieben werden, da int alleine unsigned int entspricht.

Extrem unwahrscheinlich.

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

>> Beim Keil Compiler muss signed geschrieben werden,
>> da int alleine unsigned int entspricht.
Hast du dir mal an den chars die Finger verbrannt, und nimmst jetzt 
auch bei integer die feuerfesten Handschuhe (den Signed-Cast)?

[Vlad T. (vlad_tepesch)]

Bernd Schuster schrieb:
> Beim Keil Compiler muss
> signed geschrieben werden, da int alleine unsigned int entspricht.

Dann ist es kein C-Compiler.

vorausgeetzt wir sprechen doch über C:
auch sollte man die verwendung von int vermeiden.
es gibt eine headerdatei: stdint.h
die enthält typdefinitionen, die eine klar definierte signedness und 
Breite (--> Wertebereich) haben.
zB:
uint8_t
int8_t
uint32_t

da nimmt man dann das, was man wirklich braucht.
in deinem Falle (FFF42A00) ein 32bit typen und nicht einen Typ int, der 
auf von dem einen System/Compiler als 32bit, von einem anderen als 16bit 
definiert wird.

Auf kleinen µCs haben Floats und erst recht Doubles in der Regel nichts 
verloren.
Es gibt nur sehr wenige Anwendungsfälle wo man sowas wirklich braucht.
normalerweise hat man klare Vorstellungen von Wertebereich und man kann 
mit Fixpoint rechnen. das ist um den Faktor 100-200 schneller als eine 
SW-Float-Implementierung und belegt nur einen Bruchtteil des 
Programmspeichers.

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

Vlad Tepesch schrieb:

> auch sollte man die verwendung von int vermeiden.

Wenn man etwas ganz bestimmtes damit vorhat, dann ja. Immer uint8_t für 
Daten zu verwenden, die nur 8 Bit haben müssen, ist allerdings nicht 
selten ineffizient. Wer nun wirklich konsequent ist, der verwendet 
folglich uint_fast8_t, aber Hand auf's Herz: Wie oft hast du das schon 
gesehen?

> Auf kleinen µCs haben Floats und erst recht Doubles in der Regel nichts
> verloren.

Auch das ist in dieser Verallgemeinerung unberechtigt. Man sollte sich 
den Einsatz gut überlegen, aber wenn es der Sache dient, nicht zu einlig 
ist und die Laufzeitfunktionen Platz finden, warum nicht?