Unklare Fehlermeldung

[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]

so habe ich mir das auch vorgestellt und daher auch vermutet, dass es mit fp Arithmetik auf dem Mega wahrscheinlich kein Geschwindigkeitsproblem bei deinen Berechnungen gibt.

[Ceos]

@Unregistriert man kann auch etwas bauen ohne dabei zu lernen, aber ist "basteln" nicht eigentlich zum lernen da?
wir wollten nur helfen und haben unsere meinung zu codestil und umsetzung gegeben, kein grund hier irgendwen anzufahren weil er etwas zur verbesserung generell empfiehlt oder sich aufzuspielen weil der OP sich (jetzt) damit nicht beschäftigen möchte

Du hattest mich sogar explizit gefragt dass ich dir die beispiele für die arithmetik nennen soll, habe es aber unterlassen weil das zu stark abschweift vom thema es sei denn der OP hätte es sich gewünscht

PS: jetzt wo du schon so engagiert schreibst, registrier dich doch mal, das sind keine 5minuten aufwand

[Unregistriert]

nein, da hast du mich falsch verstanden.

wir wollten nur helfen und haben unsere meinung zu codestil und umsetzung gegeben, kein grund hier irgendwen anzufahren weil er etwas zur verbesserung generell empfiehlt oder sich aufzuspielen weil der OP sich (jetzt) damit nicht beschäftigen möchte

Erst mal habe ich überhaupt niemanden "angefahren". Aber unmotivierte, unsinnige und unbegründete Hinweise, fp sei zu langsam für einen AVR, sei grundsätzlich oder besser zu vermeiden und durch Integer zu ersetzen, lese ich hier nicht zum ersten Mal.
Geschwindigkeit war kein Thema und ist es auch nicht, und daher schrieb ich, solange es kein Thema ist, braucht man nicht drüber zu reden.
Gegen den einen oder anderen Tipp habe ich nichts einzuwenden, und so einen habe ich mit x*x statt pow(x,2) ja selber gegeben.
Aber grundsätzlich bei einer Anwendung zur Kinematik oder inversen Kinematik mit massenweise trigonometrischen und anderen rationalen und reelen Funktionen zu empfehlen, auf fp zu verzichten und Integer zu verwenden, ist kein ernstzunehmender Tipp, aus dem man was lernen kann, das ist (zumal keine ernsthaften Geschwindigkeitsprobleme bestehen) einfach unangemessen, würde bei dieser Vielzahl an fp Funktionen zu einem durch die fp-int Umwandlungen völlig aufgeblasenen Code mit immer noch fraglicher Performance führen und ist daher alles andere als hilfreich in diesem Zusammenhang.

[Unregistrierter]

Aber grundsätzlich bei einer Anwendung zur Kinematik oder inversen Kinematik mit massenweise trigonometrischen und anderen rationalen und reelen Funktionen zu empfehlen, auf fp zu verzichten und Integer zu verwenden, ist kein ernstzunehmender Tipp, aus dem man was lernen kann, ...

Es wurde nicht empfohlen auf fp zu verzichten. Sich darüber Gedanken zu machen finde jedoch einen sehr enstzunehmenden Tipp, aus dem man sehr viel lernen kann.