MPU 6050 Beschleunigungssensor - Programm zu langsam

[Atvilar]

Hallo,

@ HaWe
1) Danke, ich war mir nicht sicher ob ich auf Sensor oder Arduino posten sollte.
2) Multithreading, so etwas habe ich mir gedacht. muss mich da aber erst einlesen, wie ich das hinbekomme! (hab Arduino Uno)
3) Lib Möchte ich verhindern, da in einer weiteren Ausbaustufe 2 Libs kollidieren würde (Ich glaube die Beiden verwenden die gleiche Clock oder so)

@ Rabenauge:
Den Dallas Sensor benutze ich, weil ich den gerade zur Hand hatte. Er läuft NICHT im Parasit-Modus
Die Seriellen Ausgaben benutze ich zum Debugging und Kalibrieren, auch die kommen später raus. Trotzdem: Ohne Seriellen Ausgaben + SD Speicherung: 369 952 micros / loop
Schreiben auf die SD ist aber nicht zu vermeiden. wäre eine Lange "Wurst" schneller?
1 Loop mit Seriellen Ausgaben dauert ca. 422 488 micros

Edit:
Ohne die beiden T Berechnungen (Dallas + MPU) komme ich auf 40 056 micros / Loop.
Außerdem habe ich die baudrate auf 230400 erhöht.
Nichtsdestotrotz muss der Loop noch schneller sein.

Danke für die Tipps!

[HaWe]

Mit dem Uno geht MT nicht bzw. nicht vernünftig, da viel zu wenig RAM. Der Arduino Zero/M0 hat aber denselben Formfaktor, hat aber ~15x soviel RAM und ~3x soviel Takt.
Deine Bedenken wegen "Clock" vesretehe ich nicht....
Der Flaschenhals wird aber sicher das schnelle Schreiben auf SD sein.

[Rabenauge]

Du kannst versuchen, die Ausgaben, die auf die Karte geschrieben werden, erst ein paar Datensätze lang zu puffern.
Das erspart zumindest das dauernde öffnen und schliessen der Datei...da musst du halt schauen, wie weit du mit dem Arbeitsspeicher kommst.

Weiters würde ich versuchen, möglichst viele der Fliesskomma-Berechnungen zu umschiffen (je mehr davon verschwindet, umso besser).

[wkrug]

Wie wärs, wenn Du die Gyro Abfragen in einen Timer Interrupt legst, der alle 5 bis 10ms ausgelöst wird.
Dort zyklisch die Gyro Werte addieren und in der Hauptroutine die Position daraus berechnen.
Komplexe Berechnungen sollten da aber dann vermieden werden ( Zeitfaktor ).

Zum anderen würde ich statt der float Variablen lieber int Typen wählen, wo das möglich ist, weil die ein Controller wesentlich schneller verrechnen kann.

[HaWe]

Ist die Frage, was genau gespeichert werden soll: die nackten raw-Werte direkt aus den Registern (6DOF, zusammengesetzt zu 3x integer für Gyro und 3x integer für Accel.) - oder schon fertig ausgerechnete Winkel.
Eulerwinkel (bzw. yaw, pitch, roll) werden aber nur mit floats vernünftig berechnet. Wenn also abspeichern, dann entweder direkt die raw-Werte aus den Registern (ohne weitere Umrechnungen), oder die daraus bereits fertig ausgerechneten geometrischen Winkel und dann erst zu int gerundet:
z.B. die float-Eulerwinkel mit 100 multiplizieren und dann runden (edit: je nachdem, int16_t oder uint16_t). Dann hat man gegenüber float nur die halbe Anzahl an Bytes auf SD zu schreiben und statt 6 Werte für 6DOF nur 3 ausgerechnete Euler-Winkel.

[HaWe]

PS:
es gibt auch SAMD51 (ARM Cortex M4) Platinen im Uno-Formfaktor, programmierbar per Arduino genau wie auch UNO oder DUE. Vorteil: 120MHz Takt plus extra fpu Coprozessor für schnelle float-Berechnungen, da sind dann auch komplizierte float-Berechnungen rattenschnell:
https://www.adafruit.com/product/3382
https://www.adafruit.com/product/4000 .

Aber auch der MPU6050 hat ja bereits einen onboard-digital-motion-processor (dmp), der komplizierte Berechnungen onboard, also schon ohne Arduino, ausführen kann, nur muss der gesondert angesprochen werden, was längst nicht alle MPU6050 Libs auch tatsächlich tun, im Gegensatz zu dieser hier, wie schon erwähnt: https://github.com/jrowberg/i2cdevli...rduino/MPU6050 .