Unklare Fehlermeldung

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