Unklare Fehlermeldung

[Mxt]

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

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.

[fredyxx]

Herzlichen Dank

Gruß

fredyx

[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

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

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

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

[Ceos]

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

[Mxt]

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

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

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

vG

fredyxx

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