Druckbare Version
ja, vielen Dank, ich wollte den Fehler auf dem ESP32 (!!) finden. Auf M3 und M4 gibt es keinen Fehler.Zitat:
Zitat von Moppi
Daher meine Anfrage:
Zitat:
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?
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
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
sonst niemand hier, der einen Arduino-kompatiblen ESP32 hat und evtl sogar gegen einen Due oder einen Arduino-kompatiblen M4 testen kann?
der Espressiv Server hat scheinbar noch ein 56k Modem für den Upload -.-
Code: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!
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?
inzwischen konnte jemand anderes ebenfalls bestätigen, dass ein M4 ebenfalls wie bei mir auch Due, M4 und Mega2560
32.843750
messen:
Zitat:
Running on a Feather M4 Express, the final value of TBase.m was 32.843750.
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)
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.
ein weiterer User, der das unheimliche Ergebnis bestätigen kann,
diesmal ARM Cortex M0 vs. ESP32:
http://forum.arduino.cc/index.php?to...601#msg4157601
- - - Aktualisiert - - -Zitat:
The Arduino Zero (ARM Cortex M0+) agrees with the other ARM microcontrollers and evaluates to 32.843750.
The ESP32 (WROOM32) generates 54196.625.
ich habe jetzt mal dieses "unerwartete" Verhalten im Expressiv-github Repo gemeldet:
https://github.com/espressif/esp-idf/issues/3405
würde mich freuen, wenn noch mehr User hier testen könnten.
@Ceos: was hast du für ein ESP32 board genau?