Unklare Fehlermeldung

[Peter(TOO)]

Hallo fredyxx,

Ja, prima Idee. Aber was bewirkt das float in Klammern gegenüber nur return 0.0??

Hier eigentlich nichts

Es war davor aber die Diskussion, dass je nach verwendeter Hardware, der Compiler float oder double verwendet.
Mit einem typecast kann man dem Compiler dazu bringen einen bestimmten Datentyp zu verwenden, bzw. kann verhindern, dass interne Konvertierungen vorgenommen werden.

Ein schlechter Compiler mit double, würde die 0.0 zuerst als double erzeugen und dann in einen float umwandeln. Mit "(float) 0.0" wird er gezwungen 0.0 gleich als float zu erzeugen.

Es gibt manchmal Fälle, wo man aus Sicht des Compilers etwas "murksen" muss und dann meckert der Compiler rum.
z.B. sind Ports typischerweise 8-Bit breit:

uint8_t port;
int i;

i &= 0xFF; // i hat jetzt garantiert nur noch 8 gültige Bits

port = i;  // hier motz der Compiler, weil int mehr als 8 Bits hat und Daten verloren gehen könnten
           // wir haben aber im Programm sicher gestellt, dass nur noch 8 Bit vorhanden sind

port = (uint8_t)i; // hier motzt der Compiler nicht mehr.

Ein anderes Beispiel:

int i;
i = i * 3.3;  // das geht nicht
              // der Compiler wandelt i zuerst in einen double um und multipliziert dann mit 3.3
              // das Resultat ist dann aber auch double und passt nicht in einen int

i = (int) (i * 3.3); // dies funktioniert und es ist auch dokumentiert, dass bewusst die Nachkommastellen abgeschnitten werden.

Das mit den Typenkonvertierung ist aber immer eine heisse Kiste und man muss sich genau überlegen was man da tut. Nur weil der Compiler nicht motzt, funktioniert der Code noch lange nicht.
Auch muss man bedenken, welchen Wertbereich ein Datentyp abbilden kann und welche Konvertierungen der Compiler automatisch macht

volatile uint8_t c;

c = c * 255;
c = c / 256;  // liefert immer 0!

c = (c * 255) / 256; // hier bekommst du das erwartete Resultat

Im ersten Fall wird das Zwischenresultat auf 8 Bit gekürzt, erzeugt für alle Werte von c >1 einen Überlauf
Aber das ist egal, weil ein 8-Bit Wert geteilt durch 256 immer 0 ergibt.

Im zweiten Fall ist das Zwischenresultat ein Long und es wird kein Überlauf erzeugt.

"volatile" sagt dem Compiler, dass c sich ausserhalb des Kontext verändern kann. Das habe ich hier verwendet damit der Compiler nicht optimieren kann und das erste Beispiel dann trotzdem funktioniert!

Wegen solche "Details sind schon Raketen explodiert.
Hier die Kurzversion: https://de.wikipedia.org/wiki/Ariane_V88#Fehlerursachen
Und noch der ausführliche Bericht: http://www4.in.tum.de/lehre/seminare...g-27-11-02.pdf


MfG Peter(TOO)

[Unregistriert]

was fredyxx' "Unklare Fehlermeldung" angeht ist das Problem ja gelöst, hier muss einfach die fragliche Variable eine Stufe "höher" deklariert werden.
fredyxx' Mega arbeitet immer mit 32bit floats (ca. 7 Stellen Genauigkeit) und nie mit 64bit double , daher braucht man sich um double und type-casting keine Gedanken machen.
Ob unter dem Strich der Mega die ganzen float-Berechnungen "schnell genug" schafft, muss man schlicht abwarten, da hilft kein vor-ab Spekulieren und letztlich muss es fredyxx selber entscheiden.
Wenn fredyxx dann feststellt, dass der Mega zu langsam ist, kann er ja immer noch auf ein schnelleres Board wechseln, für die Arduino-IDE gibt es ja auch jetzt schon noch ein paar Alternativen mit diversen ARM-cpus (wobei der Due vom Layout her dem Mega am ähnlichsten und momentan auch am leistungsfähigsten ist).

[Peter(TOO)]

Wenn fredyxx dann feststellt, dass der Mega zu langsam ist, kann er ja immer noch auf ein schnelleres Board wechseln, für die Arduino-IDE gibt es ja auch jetzt schon noch ein paar Alternativen mit diversen ARM-cpus (wobei der Due vom Layout her dem Mega am ähnlichsten und momentan auch am leistungsfähigsten ist).

Es gibt fast immer auch Lösungen ohne FP. Ich konnte in 30 Jahren Entwicklung PFs auf µCs immer vermeiden, braucht halt manchmal etwas mathematisches Geschick oder Tabellen.
Intern kann man z.B. in 1/100 °C rechnen, das sind dann Ganzzahlen bei den Berechnungen. Bei der Ausgabe "fummelt" man dann das Komme halt zwischen die Ziffern.
Skalierungen mit krummen Werten lässt sich über Brüche umsetzen.

So lange man keine FPU hat, sind FPs nun mal langsam.

Bei Einzelstücken ist die CPU-Leistung nicht so ein Problem, da spielt der Preis keine so grosse Rolle.
Geht es in Stückzahlen sieht es dann anders aus.

Ich weiss noch, AutoCAD auf einem normalen 8088 war eine Quälerei und so viel Kaffee, wie man warten musste, konnte man gar nicht trinken. Mit einem zusätzlich 8087 konnte man dann doch schon vernünftig arbeiten. Allerdings kostete der 8087 damals (um 1985), direkt bei Intel um die CHF 600.--

MfG Peter(TOO)

[Unregistriert]

ich verstehe nicht, was jetzt dein Post aussagen soll oder welchen Zweck er hat. Geschwindigkeitsprobleme hat fredyxx bisher nicht berichtet, also warum redest du welche herbei oder thematisierst es überhaupt? Und wenn ihm sein Programm wirklich zu langsam ist und wenn aber Funktionen wie sin, cos, tan, asin, acos, atan, atan2, Wurzel, exp() etc gebraucht werden, dann ist eine Konvertierung in Integerarithmetik sicher die schlechteste aller Lösungen (oder: viel Spaß dabei...!).
Für 13 EUR kriegt man einen Due, der hat zwar keine fpu, aber rechnet fp Operationen trotzdem etwa 10x schneller als ein Mega, kann zusätzlich auch mit 64bit double rechnen und hat auch etwa 10x so viel Speicher. Wenn es also nötig wird, wieso dann keinen ARM, und ob es nötig wird, wissen wir ja noch gar nicht. Auch ein Mega schafft ja wahrscheinlich schon seine 1000 fp Berechnungen pro Millisekunde, was ja durchaus ausreichend sein könnte.

[Ceos]

@unregistriert warum in den 2ten gang schalten, wenn der ferrari im ersten doch auf gute 70kmh beschleunigen kann

es geht hier mehr darum wissen um optimierung und besseres programmieren zu vermitteln und nicht die schwächen in der programmierung mit gekaufter CPU leistung zu erschlagen ... darum hab ich ja auch gesagt wie er seine variablen initialisiert sei unordentlich .... und der verweis von MXT dass es "üblich" sei einfache variablen vor Ort zu deklarieren stört mich ebenfalls ... scheiß drauf dass es "üblich" ist, es ist aber leselicher wenn ich schon am Kopf der Methode einschätzen kann wie groß der Footprint und vll. die Optimierungs-Möglichkeiten sind.

[Unregistriert]

dass die spezielle Variable an der falschen Stelle initialisiert war und daher eie Fehlermeldung kam, ist ja richtig, aber wenn du Funktionen wie sin, cos, tan, asin, acos, atan, atan2, Wurzel, exp() alle mit Interarithmetik ausrechnen willst - das möchte ich sehen. Sicher mag es mit großem Aufwand gehen, aber viel Spaß dabei (und wieviel schneller dann alles wird, wäre auch noch interessant zu sehen).
Aber Schnelligkeit ist doch (noch) gar nicht das Thema, also warum jetzt der Streit um des Kaisers Bart?

[fredyxx]

Hallo,

ich baue keinen tanzenden Roboter, sondern einen Bagger und diese Berechnungen sind nur vor einem Auftrag an einen Schrittmotor erforderlich. Sobald der läuft, sind diese Rechnungen nicht mehr nötig.
Damit steuere ich 6 Schrittmotoren und habe noch keine Zeitprobleme festgestellt. Die Schrittmotoren sind eher die Geschwindigkeitsgrenze, weil ich vom Porgramm die Schrittfolge so hoch stellen kann, dass die Motoren stehen bleiben.

vG

fredyxx

[Unregistriert]

klar, Gedanken machen darf man sich immer über alles mögliche, nur bringt das hier in diesem Falle nichts konkretes
(s. Posts von Peter(Too)

Es gibt fast immer auch Lösungen ohne FP. Ich konnte in 30 Jahren Entwicklung PFs auf µCs immer vermeiden, braucht halt manchmal etwas mathematisches Geschick oder Tabellen.
Intern kann man z.B. in 1/100 °C rechnen, das sind dann Ganzzahlen bei den Berechnungen. Bei der Ausgabe "fummelt" man dann das Komme halt zwischen die Ziffern.
Skalierungen mit krummen Werten lässt sich über Brüche umsetzen.
So lange man keine FPU hat, sind FPs nun mal langsam.

und Ceos,

warum in den 2ten gang schalten, wenn der ferrari im ersten doch auf gute 70kmh beschleunigen kann
es geht hier mehr darum wissen um optimierung und besseres programmieren zu vermitteln und nicht die schwächen in der programmierung mit gekaufter CPU leistung zu erschlagen ... darum hab ich ja auch gesagt wie er seine variablen initialisiert sei unordentlich .... und der verweis von MXT dass es "üblich" sei einfache variablen vor Ort zu deklarieren stört mich ebenfalls ...

und was sind diese Hinweise dann hier als Tipp zur "Optimierung" für fredyxx tatsächlich wert?

[Ceos]

es ist einfach gut gemeint

und um es kurz zu fassen, wenn man etwas gut meint und einer daher kommt "wozu denn den scheiß" ist das indirekt beleidigend .... wie ich bereits einer anderen person einmal gesagt habe

"Bevor du jemandes Ratschläge als unnütz oder unsinnig bezeichnest nur weil sie dir nicht passen, sage einfach 'Danke aber so weit wollte ich jetzt nicht gehen' oder etwas vergleichbares" ... Das Danke dabei ist simple Höflichkeit und die Ablehnung danach ist ein Zeichen dass einen das nicht interessiert, man aber die Mühe zumindest wertschätzt der Post mit dem "du hast mich falsch verstanden" war ja fast schon versöhnlich und verständlich, aber jetzt weider alles in Frage zu stellen ist einfach nur unhöflich


Sorry für zu weit OT ich werde auch nix mehr darauf schreiben, sorry nochmals

[Unregistrierter]

klar, Gedanken machen darf man sich immer über alles mögliche, nur bringt das hier in diesem Falle nichts konkretes ...
...
und was sind diese Hinweise dann hier als Tipp zur "Optimierung" für fredyxx tatsächlich wert?

Ich maße mir nicht an, das für den TE zu bewerten und traue auch dir die Fähigkeit nicht zu. Seine eigentliche konkrete Frage war sowieso schon längst beantwortet. Der Hinweis die Fließkommarechnung durch Integerrechnung zu ersetzen als "kein ernstzunehmender Tipp, aus dem man was lernen" könne, zu bezeichnen ist daneben und ist ein Punkt, an dem ich deine Kompetenz für mich bewerte und deine "Tipps" einschätze.