ESP32 berechnet floats falsch im Vergleich zu M4 und Due/M3

[Moppi]

Ich dachte, Du wolltest Fehler finden.
Dann bin ich mal wieder raus.


MfG

[HaWe]

Ich dachte, Du wolltest Fehler finden.
Dann bin ich mal wieder raus.


MfG

ja, vielen Dank, ich wollte den Fehler auf dem ESP32 (!!) finden. Auf M3 und M4 gibt es keinen Fehler.

Daher meine Anfrage:

Hat jemand so etwas schon einmal gehört oder gelesen und kann die Rechenergebnisse ggf nachprüfen bzw für M3, M4 und ESP32-Plattformen bestätigen?

[Ceos]

ich habe mir leider nur meinen ESP8266 mitgenommen und habs gerade mal damit ausprobiert, seltsamerweise funktionierts damit auch
Chip mäßig sind die relativ ähnlich, muss wohl wirklich was ESP32 mäßiges sein, heute Nachmittag bin ich wieder zu Hause und kanns mal mit meinem 32er testen

aber da stimmt wirklich was mit den ausgaben nicht im programm er wandelt die floats nicht richtig um bei mir,d as sieht alles etwas kryptisch aus, aber wenigstens landet er ordentlich

[HaWe]

ja, ESP8266 ist problematisch, evt. auch weil es Konflikte mit den WiFi-Scheduler gibt, auch die alten Core-Versionen haben teilw. Fehler.
Der ESP32 hat aber u.a. 2 cpus, einer davon ausschließlich für Wifi, sodass es das "eigentliche" Programm nicht stört wie beim ESP8266.
Auch Mega2560 funktioniert bei mir nicht (Flash/RAM, evt. auch wieder sprintf(..."%f"...)-Problem).

Daher habe ich mich bei mir auf M3, M4 und ESP32 beschränkt.

Bin neugierig, was bei dir beim ESP32 rauskommt!
(Wenn dein ESP32 auch 32.84... rechnet, liegt es an MEINEM ESP32, wenn du dann auch über 54000 rauskriegst, ist es ein ALLGEMEINES ESP32-Problem).

Aber auch auf weitere Ergebnisse von anderen Usern zu M3/M4- (und ESP32-) Tests bin ich gespannt!

- - - Aktualisiert - - -

edit:
habe es jetzt auch für Mega2560 hingekriegt mit einem sprintf-float-patch;
Flash/RAM sind extrem knapp, aber er errechnet ebenfalls nach etwas Hin und Her
32.843750

[HaWe]

sonst niemand hier, der einen Arduino-kompatiblen ESP32 hat und evtl sogar gegen einen Due oder einen Arduino-kompatiblen M4 testen kann?

[Ceos]

der Espressiv Server hat scheinbar noch ein 56k Modem für den Upload -.-

t.sec  hi.m vVert vHoriz   Burn tilt    brake acc  Fuel TBase.m
776.0     0    0     1      33%    0     2.1 -0.5   481 54197.343750

t.sec  hi.m vVert vHoriz   Burn tilt    brake acc  Fuel TBase.m
776.5    -1    1     1       0%    0     0.0  1.6   481 54196.625000


Very good but way off!

[HaWe]

ist ja irre!
derselbe Fehler!

Jetzt pass mal auf:
schau dir mal Zeile 109 an:

if( sHorzm<15600.0) burnPerc=0; // sHorzm<15600

hast du die gefunden?

umändern in:
if( sHorzm<=0) burnPerc=0; // oder ganz auskommentieren

ergibt: beim ESP32
69359.656250

Due und M4 (und sogar der Mega2560!) aber rechnen hier aus:
15197.906250


kann doch nicht sein, oder?

PS,
welches ESP32 modul has du verwendet?

[HaWe]

inzwischen konnte jemand anderes ebenfalls bestätigen, dass ein M4 ebenfalls wie bei mir auch Due, M4 und Mega2560
32.843750
messen:

Running on a Feather M4 Express, the final value of TBase.m was 32.843750.

[Ceos]

Sorry, war gestern abend von der Fahrt noch zu kaputt um noch irgendwas weiter zu probieren

ich hab mal spaßeshalber alles double und explizit float geamcht

an eingien Stellen hast du einen impliziten Integer im Divisir gehabt und ich habe vermutet dass der Compiler da mist baut und vielleicht das ERgebnis zu Int umcastet

hat aber auch nix gebracht .... heute ist Feiertag und den will ich genießen, aber vielleicht schlägt mich die Muße und ich guck mir mal die rEchenschritte an ... ich vermute irgendwo in der Math Umsetzung für den ESP32 einen Bug, die Zahlen die du ermittelt hast ergeben leider kein eindeutges Muster aber sie gebe einen Hinweis auf einen Überlauf in irgendeiner Funktion (vielleicht eine spezielle FPU Funktion die einen f16 erwartet aber mit einem f32 befüttert wird und dann einfach überläuft ... hab leider noch nciht herausgefunden wie man die FPU für den Compiler abschaltet, dann kann ich wenigstens sicherstellen dass die normale Math Library richtig funktioniert)

[HaWe]

ja klar, vielen Dank dafür!
Dass double vs. floats auch nichts groß ändern, deckt sich ebenfalls mit meinen Versuchen.
Bin ntl auch noch auf weitere Ergebnisse auch anderer User gespannt, tatsächlich kann es aber ja nicht sein, dass 1 cpu erheblich anders rechnet als 3 andere, insb. 1 davon mit fpu.
Woran es immer liegen mag - type casting, fp32, fp64, oder meinetwegen auch abweichende if...else... Auswertungen:
minimale Abweichungen an der letzten Selle wären sicher tolerabel, aber nicht wie hier 32 vs. 54196.