Hi, hab grad Schwierigkeiten zwei Werte (signed int) zu teilen -> als Ergebnis kommt immer 0x00 raus :-( z.B.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Gruß Bernd
Bernd Schuster schrieb: > z.B. >
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
> 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.
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
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 ;) )
hab den fehler gefunden -> man müsste hier float oder double verwenden, wei das erg kleiner als null ist....
Gast
#1792629
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.
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.
Bernd Schuster schrieb: > Beim Keil Compiler muss > signed geschrieben werden, da int alleine unsigned int entspricht. Extrem unwahrscheinlich.
>> 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)?
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.
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?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.