uint16_t Division klappt nicht

[Peter (Gast)]

Hallo zusammen, ich habe folgendes Problem und wäre über etwas Hilfe 
dankbar.


uint16_t value1 = 1400;
uint16_t value2 = 15;
uint16_t result = 0;
float div = 0.0;

div = value1 / value2;
result = (int)div;

Als Ergebnis bekomme ich immer 0!!!


Im anderen Fall bekomme ich aber immer ein richtiges Ergebnis:

uint16_t value1 = 1320;
float multiply = 0.0;
uint16_t result = 0;

multiply = value1 * 0.00209;
result = (int)multiply

Weis jemand, woran das liegt und wo das Problem im ersten Fall liegt?

[Karl M. (Gast)]

Hallo,

wie stellst Du fest, was in den Variablen steht?

Warum ist float div?

[Rufus Τ. F. (rufus)]

Peter schrieb:
> div = value1 / value2;
> result = (int)div;
>
> Als Ergebnis bekomme ich immer 0!!!

Das stellst Du auf welche Weise fest?

[Stefan K. (stefan64)]

Wahrscheinlich wurde die Berechnung vom Compiler wegoptimiert, weil das 
Ergebnis nirgends gebraucht wird.

[M. K. (sylaina)]

Stefan K. schrieb:
> Wahrscheinlich wurde die Berechnung vom Compiler wegoptimiert, weil das
> Ergebnis nirgends gebraucht wird.

Eher unwahrscheinlich wegen:

Peter schrieb:
> Als Ergebnis bekomme ich immer 0!!!

Irgendwie muss er sich ja div anzeigen lassen und spätestens da wird das 
Ergebnis gebraucht.
Wahrscheinlicher ist, dass die gewählte Anzeigeart ungeeignet ist. Ohne
den kompletten Code ist das aber alles nur Stochern im Nebel.

[Peter (Gast)]

Entweder castest du die Operanden auf float BEVOR die Operation 
ausgeführt wird:

div = (float)value1 / (float)value2;

Oder du definierst die Operanden von vorne herein als float:

float value1 = 1400.0;
float value2 = 15.0;

Den C-Compiler juckt der Typ vor dem '=' nicht. Wenn die Operanden 
integer sind, dann wird auch eine integer-Operation durchgeführt.

[Jim M. (turboj)]

Peter schrieb:
> Entweder castest du die Operanden auf float BEVOR die Operation
> ausgeführt wird:

Auch dann wäre das Ergebnis nicht Null, denn 15 passt ein paar mal in 
1400.

Der OP hat ein Anzeigeproblem, vermutlich weil die passende 
Format-String Library nicht verlinkt wurde. Aber das sehen wir ohne 
Zugriff auf den restliche Code nicht.

[Di P. (drpepper)]

Bei mir kommt auch keine 0 als für result raus: 
https://onlinegdb.com/HyGUKu9mG

Hab's mal um den richtigen cast für div2 erweitert ;)

#include<stdio.h>

int main() {
__uint16_t value1 = 1400;
__uint16_t value2 = 15;
__uint16_t result = 0;
__uint16_t result2 = 0;
float div = 0.0;
float div2 = 0.0;

div = value1 / value2;
result = (int)div;

div2 = (float)value1 / value2;
result2 = (int)div;

printf("div: %.6f \n", div);
printf("result: %i \n \n", result);

printf("div2: %.6f \n", div2);
printf("result2: %i \n \n", result2);
}

[W.S. (Gast)]

Peter schrieb:
> Hallo zusammen

..also schreib zuerst mal, auf was für einer Hardware und mit welchem 
Compiler das ganze laufen soll.

Der Grund für meinen Einwurf besteht darin, daß ich vor einiger Zeit bei 
einer speziellen CPU, nämlich dem LPC11E12 und mit dem Keil übersetzt 
festgestellt habe, daß dort Rechnungen in float bei bestimmten 
Argumenten schlichtweg falsch gehen.

Derselbe Code - präziser: derselbe Maschinencode, dasselbe Hexfile auf 
einen LPC11E14 gebrannt - funktionierte richtig.

Peter schrieb:
> float div = 0.0;
>
> div = value1 / value2;
> result = (int)div;

Warum schreibst du sowas?

Also ich würde es so schreiben:

 int result;
 float div;

 div = value1;
 div = div / value2;
 result = div;

Warum? Damit die Division in float stattfindet und nicht in int.

Und in Pascal würde ich dann auch result:= round(div); schreiben.

W.S.

[Jim M. (turboj)]

W.S. schrieb:
> daß dort Rechnungen in float bei bestimmten
> Argumenten schlichtweg falsch gehen.
>
> Derselbe Code - präziser: derselbe Maschinencode, dasselbe Hexfile auf
> einen LPC11E14 gebrannt - funktionierte richtig.

Bei sowas sollte man mal in das Errata Sheet schauen. Ich würde spontan 
auf Errata 5.2 tippen:

> For LPC11E14/401 devices with date codes 1238 and before, the 2 kB SRAM
> located at address 0x20000000-0x20000800 is not available.

Float Sachen auf Cortex-M0 sind reine Software. Wenn DAS nicht geht ist 
was grundsätzliches faul.

[M. K. (sylaina)]

W.S. schrieb:
> Damit die Division in float stattfindet und nicht in int.

Und welchen Vorteil soll das beim bestehenden Problem haben? Ich mein, 
1400/15 = 93, und wenn das System nur auf 8 bit arbeiten würde käme da 
immer noch 17 raus. Beim TE kommt aber anscheinend 0 raus und daran 
sieht man, es ist kein Typ-Problem sondern ein Anzeigeproblem. Er sollte 
erstmal das Problem lösen.