Unklare Fehlermeldung

Hallo,

bei diesem Programm erhalte ich ganz unten bei "Umdrehungen3 = 0.0;" die Fehlermeldung, dass "Umdrehungen3" nicht deklariert ist, obwohl das kurz oberhalb passiert.
Wenn ich "Umdrehungen3" aber nicht in der Anweisung, sondern am Anfang des Programms als "static float" deklariere, dann klappt's.

Wieso ist das so?

Code:

---

//  **************************************UP lzahn3_ber  *******************************

float lzahn3_ber ( float x1, float y1) {

  float P0_P1 = sqrt(pow(x1, 2) + pow(y1, 2));                                  //Gerade P0-P1

  float CosinusW4 = (117140.0 - pow(P0_P1, 2)) / 107536.0;
  float W4 =  180.0 / 3.1415926536 * acos(CosinusW4);                          //  W4 in Grad

  float P1_P5  = sqrt((1.03310787 - cos(3.1415926536 / 180.0 * (W4 + 12.58))) * 91368.0);            // Linie P1-P5

  float W10 =  180.0 / 3.1415926536  *  acos((5184.0 + pow(x1, 2) + pow(y1, 2) - pow(P1_P5, 2))  /  (144 * sqrt (pow(x1, 2) + pow(y1, 2))));  // = W4 in Grad

  lzahn3 = sqrt((1.00419 - cos((154.23 - W10 - (180.0 / 3.1415926536 * atan(y1 / x1))) * 3.1415926536 / 180.0)) * 11361.6);

  if (lzahn3 >= 68.0  && lzahn3  <=  105.0)  {

    float delta_lzahn3 = lzahn3 - lzahn3_alt;      // berechnet die Differenz zum alten Wert


    float Umdrehungen3 = 0.05 * delta_lzahn3;    // 0.05 = 1 / 20.0; das sind die Umdrehungen für 1 mm Weg


    return Umdrehungen3;    // die Ausgabe erfolgt in Umdrehungen um die errechnete Längenänderung zu erreichen

  }      // >>>>  ENDE    if (lzahn3 >= 68.0  && lzahn3  <=  105.0)



  Serial.println ("FEHLER: lzahn3 ausser Bereich!!!");
 
  digitalWrite (52, HIGH);
  Umdrehungen3 = 0.0;      // keine Bewegung, da Fehler vorliegt
  return Umdrehungen3;   


}  //*************    ENDE  UP lzahn3_ber

---

vG

fredyxx

die variable wird innerhalb des if-block deklariert und ist außerhalb nicht bekannt!

generell gaaaaaanz schlechter stil variablen on the fly zu deklarieren.

deklariere bitte ALLE in eienr methode verwendeten dateien immer gaaanz oben!

Hallo,

lokale Variablen sind auf dem {} Block beschränkt, in dem sie deklariert wurden (und alles was darin verschachtelt liegt).

D.h. in obigem Code ist Umdrehungen3 nur bis zu schliessenden Klammer des if sichtbar.

Zwei Anmerkungen zu dem ganzen Code:

Auf 8-Bit Arduinos ist Rechnen mit float sehr langsam.

Auf 32-Bit Arduinos (Zero, Teensy, Due, usw.) ist der Code ungünstig, da alle Kommazahlenkonstanten (wie 0.05), wenn sie so geschrieben werden, den Typ double (15 Stellen Genauigkeit) haben. Man müsste richtiger 0.05f schreiben, wenn man float meint (7 Stellen Genauigkeit), sonst würde da sehr häufig umgerechnet, was auch wieder langsam wäre. Auf 8-Bit Arduinos spielt das keine Rolle, weil es dort kein double gibt, es wird immer float genommen.

- - - Aktualisiert - - -

Zitat:

---

Zitat von Ceos

deklariere bitte ALLE in eienr methode verwendeten dateien immer gaaanz oben!

---

@Ceos
In C macht (bzw. muss man das), in Sprachen wie C++ (und das ist Arduino), C#, Java usw. ist es eher empfohlen Variablen erst wenn man sie braucht zu deklarien. In C++ wird sogar der AAA-Stil (Almost Always Auto) propagiert (z.B. von Herb Sutter, Chef des ISO C++ Kommitees), d.h. man schreibt den Typ nur hin, wenn es unbedingt sein muss.

Herzlichen Dank

Gruß

fredyx

Anm.:
auch die Funktion pow() ist sehr rechenzeitintensiv. Wenn du nur quadrieren willst, schreibe lieber ausführlich x*x statt pow(x,2). Du kannst auch selber ein Makro dafür definieren:

#define sq(x) (x*x) // sq für Square

- - - Aktualisiert - - -

Anm.:
auch die Funktion pow() ist sehr rechenzeitintensiv. Wenn du nur quadrieren willst, schreibe lieber ausführlich x*x statt pow(x,2). Du kannst auch selber ein Makro dafür definieren:

#define sq(x) (x*x) // sq für Square

- - - Aktualisiert - - -

Zitat:

---

Zitat von Unregistriert

Anm.:
auch die Funktion pow() ist sehr rechenzeitintensiv. Wenn du nur quadrieren willst, schreibe lieber ausführlich x*x statt pow(x,2). Du kannst auch selber ein Makro dafür definieren:

#define sq(x) (x*x) // sq für Square

---

Auch dafür danke!

vg

fredyxx

Hallo fredyx,

Du kannst das Problem auch umgehen im den du am Ende der Funktion
return 0.0;
schreibst.
bzw. explizit:
return (float) 0.0;

Vom Stil her, wäre es sogar übersichtlicher da dieser Ausgang nur im Fehlerfall benutzt wird.

MfG Peter(TOO)

@Mxt das ist doch C-Code oder hab ich da was übersehen? Wenn er nach C++/#/Java fragt hätte ich was anderes gesagt ... aber bei Java geh ich !nicht! konform mit dir. Ich schreib dir dazu eine kurze PM weil ich dazu gern eine Meinung von dir hätte :)

PS: mir ist aufgefallen dass das "gaaaaanz oben" missverständlich klingt, ihc meinte damit innerhalb der methode ganz oben nicht innerhalb der Datei (Datei-Global)

ARGSNbla .. du hast private Messages leider aus
Sorry fürs kurze OT dann:
Mittlerweilen bin ich (Minecraft sei dank) auf den Trichter gekommen, zumindest in Java Objekte wo es nur geht zu recyclen(also so zu strukturieren dass ich immer eine Referenz drauf halte und statt eines "new" ein "populate" aufrufe), der Garbage Collector und den Anwender der nicht alle Nase lang einen langen Freeze hat wird es dir danken :D
Aber der persistente RAM Footprint wird natürlich deutlich größer! Oder man spendiert der JVM ein -XX:NewGenSize=xxxx in einer Größe die man bei der Art der Daten erwartet.

Zitat:

---

Zitat von Ceos

@Mxt das ist doch C-Code oder hab ich da was übersehen?

---

Naja, das ist hier die Arduino Rubrik. Und das ist C++, sonst gäbe es ja keine Objekte wie Serial, Wire usw. Rein technisch betrachtet hat die Arduino IDE (seit 1.6.8 ?) den Schalter -std=gnu++11 gesetzt ...

Und OT:
Ja, Java und C# sind da, wegen Garbage Collector, streng genommen wieder eine andere Baustelle als C++. Trotzdem ist es in allen diesen eher üblich nur kurz benötigte Variablen erst am Ort des Geschehens zu deklarieren.

Zitat:

---

Zitat von Peter(TOO)

Hallo fredyx,

Du kannst das Problem auch umgehen im den du am Ende der Funktion
return 0.0;
schreibst.
bzw. explizit:
return (float) 0.0;

Vom Stil her, wäre es sogar übersichtlicher da dieser Ausgang nur im Fehlerfall benutzt wird.

MfG Peter(TOO)

---

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

vG

fredyxx

Hallo fredyxx,

Zitat:

---

Zitat von 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:

Code:

---

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:

Code:

---

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

Code:

---

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)

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

Zitat:

---

Zitat von Unregistriert

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)

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.

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

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?

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

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.

@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 :)

nein, da hast du mich falsch verstanden.

Zitat:

---

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.

Zitat:

---

Zitat von Unregistriert

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.

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)

Zitat:

---

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,

Zitat:

---

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?

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

Zitat:

---

Zitat von Unregistriert

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.

Ceos, wieso "fast versöhnlich" ? Nicht ich war doch der, der die Anschuldigung mit dem "anfahren" gebracht hat, sondern du, also wenn, dann hättest höchstens du dazu Anlass, versöhnlich zu reagieren. Ich habe nur deine Anschuldigung mit dem "anfahren" klargestellt. Dabei hatte ich weder dich noch andere ursprünglich angegriffen, weder dort noch anderswo, und ich habe auch nirgends geschrieben "wozu denn den scheiß" -
- jemand anderes vielleicht, oder woher nimmst du das?
Man wird doch sagen dürfen, dass der Vorschlag an fredyxx, hier Integer statt fp zu verwenden, keine praktische Konsequenz und auch keine Veranlassung hat? Seine fp sind doch richtig und auch nicht zu langsam, aus welchem Anlass oder Grund sollte er nun Integer dafür verwenden, mit all dem Aufriss, der für sin, cos, atan etc dafür nötig wäre, auch wenn es nett gemeint ist?

Zitat:

---

Zitat von Unregistriert

Man wird doch sagen dürfen, dass der Vorschlag an fredyxx, hier Integer statt fp zu verwenden, keine praktische Konsequenz und auch keine Veranlassung hat?

---

Wo steht das denn? Ich bezog mich hier auf diese Stelle :

Zitat:

---

Zitat von Unregistriert

auf fp zu verzichten und Integer zu verwenden, ist kein ernstzunehmender Tipp, aus dem man was lernen kann,

---

Zitat:

---

Seine fp sind doch richtig und auch nicht zu langsam, aus welchem Anlass oder Grund sollte er nun Integer dafür verwenden, mit all dem Aufriss, der für sin, cos, atan etc dafür nötig wäre, auch wenn es nett gemeint ist?

---

Woher willst du das denn wissen? Das kann man doch erst nach Austesten des Systems beurteilen. Und niemand hat die von dir abgetanen Integer vorgeschrieben. Sie wurden als Möglichkeit aufgezeigt. Deine ewigen Sorgen, Mutmaßungen und Annahmen, aus welchem Grund oder Anlass jemand anderes etwas tun oder lassen soll oder was gut oder schlecht für ihn ist und danach Vorschläge von Dritten in unangebrachter Weise kritisierst, nervt. Du glaubst nur, daß du dem TE damit hilfst.

Zitat:

---

Zitat von Unregistrierter

Woher willst du das denn wissen? Das kann man doch erst nach Austesten des Systems beurteilen. Und niemand hat die von dir abgetanen Integer vorgeschrieben. Sie wurden als Möglichkeit aufgezeigt. .

---

da hast du wohl was verpasst.
Es kamen Hinweise, fp sei zu langsam und solle durch Integer esetzt werden, und zwar von Peter(Too) und Ceos (Zitate s.o.)
Ich habe daraufhin geschrieben, dass Geschwindigkeit doch gar kein Thema wären, und was diese Hinweise jetzt für einen Sinn haben sollen:

Zitat:

---

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?

---

das auch tatsächliche keine Geschwindigkeitsprobleme vorliegen, hat fredyxx bestätigt:
[QUOTE] 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. [QUOTE]

Also war das System getestet und für schnell genug befunden worden.

Erst als von Ceos erneut wieder auf Codestil und Umsetzung Bezug genommen und mir vorgeworfen wurde, ihn angefahren zu haben, habe ich dann geantwortet (woraus du einen Teil aus dem Zusammenhang gerissen hast):

Zitat:

---

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.

---

Jetzt klar?

- - - Aktualisiert - - -

Zitat:

---

Zitat von Unregistriert

Jetzt klar?

---

Nein.
Die Möglichkeit auf FP zu verzichten wurde schon hier: https://www.roboternetz.de/community...l=1#post631970
VOR freddyxxs Statement zur Geschwindigkeit vorgeschlagen und gleich im nachfolgenden post noch VOR freddyxxs Statement zur Geschwindigkeit angezweifelt und statt dessen schnellere HaWe vorgeschlagen, die ja wohl auch nicht notwendig ist.

Zitat:

---

das auch tatsächliche keine Geschwindigkeitsprobleme vorliegen, hat fredyxx bestätigt:

---

Das hinterher als Argument anzuführen akzeptiere ich nicht.

Zitat:

---

Zitat von Unregistriert

Jetzt klar?

---

Nein!

Die Möglichkeit auf FP zu verzichten wurde schon hier: https://www.roboternetz.de/community...l=1#post631970
VOR freddyxxs Statement zur Geschwindigkeit vorgeschlagen und gleich im nachfolgenden post noch VOR freddyxxs Statement zur Geschwindigkeit angezweifelt und statt dessen schnellere HaWe vorgeschlagen, die ja wohl auch nicht notwendig ist.

Zitat:

---

das auch tatsächliche keine Geschwindigkeitsprobleme vorliegen, hat fredyxx bestätigt:

---

Das hinterher als Argument anzuführen akzeptiere ich nicht.

also ich sehe hier nur einen oder mehrere unregistrierte, und für Fließkomma die Geschwindigkeit als Problem wurde angezweifelt und auf fehlende Daten verwiesen, und dann hat der TO bestätigt dass es kein Problem damit gibt, und damit war doch alles klar, oder nicht?

Zitat:

---

Zitat von Unregistriert

also ich sehe hier nur einen oder mehrere unregistrierte, und für Fließkomma die Geschwindigkeit als Problem wurde angezweifelt und auf fehlende Daten verwiesen, und dann hat der TO bestätigt dass es kein Problem damit gibt, und damit war doch alles klar, oder nicht?

---

Das ist für mich ein Schlußwort, das ich sofort akzeptiere im Gegensatz von sämlichen posts von Unregistriert :-)

Zitat:

---

Zitat von Unregistrierter

Das ist für mich ein Schlußwort, das ich sofort akzeptiere im Gegensatz von sämlichen posts von Unregistriert :-)

---

Ich verstehe jetzt zwar nicht was das nun soll - ehrlich gesagt interessiert mich aber auch nicht, ob du was akzeptierst oder nicht und wen das sonst vielleicht interessiert, aber immerhin ist dann ja jetzt gut. :D