dsPIC: sin() oder Taylorreihe

OP #3601434
Lesenswert?

Hallo zusammen. Ich hab da mal eine Frage: Wenn ich eine Sinusberechnung 
auf einem dsPIC machen will (zwischen +- pi/2), kann ich ja die sin() 
Funktion aus der math.h nehmen. Bringt es RAM-/ROM- , aber vorallem 
Geschwindigkeits-technisch etwas, wenn ich statt der sin() Funktion eine 
Reihenentwicklung nutze?:
http://de.wikipedia.org/wiki/Sinus#Motivation_durch_Taylorreihen
und
http://commons.wikimedia.org/wiki/File:Taylor_Approximation_of_sin(x).jpeg

Es wäre z.b.:
double ownsin(double x){
double erg;
erg = x - (x*x*x/6) + (x*x*x*x*x/120);
return erg;
}

Ich frag mich, ob diese Berechnung nicht schneller geht, als die normale 
sin() Berechnung. Jedoch ist x^5 und x^3 auch nicht gerade toll. Hat da 
jemand Erfahrungen mit gemacht?

Mir gehts darum 3 sin und 3 cos Berechnungen so schnell es geht zu 
berechnen.
Gibt es vielleicht ein Tool, womit man eine Software auf Geschwindigkeit 
testen kann?

Mich interessiert es, wie schnell sin() ist, wie schnell die 
Polynomvariante mit Grad 5 und 7 hat und da ggf. noch den Unterschied 
zwischen ausgeschriebener Multiplikation und mit der pow() Funktion.

Grüße,  Michael
OP #3601719
Lesenswert?

Ich möchte mit dem vom Gyroskop ermittelten Winkel und der Daten eines 
Beschleunigungssensors die Beschleunigung in x, y und z Richtung 
berechnen. Wenn die Neigung 10° ist und der Beschl.sensor nur einen 
z-Teil angibt, ist die Bewegung ja in Wirklichkeit cos(10°) * Wert nach 
oben und sin(10°) * Wert zur hingekippten Seite.
#3601725
Lesenswert?

Michael Skropski schrieb:
> Ich frag mich, ob diese Berechnung nicht schneller geht, als die normale
> sin() Berechnung. Jedoch ist x^5 und x^3 auch nicht gerade toll. Hat da
> jemand Erfahrungen mit gemacht?

Wie wäre es, wenn Du einfach in MPLAB in den Simulator gehst und dort 
die verbrauchten Taktzyklen deiner gewünschten Funktionen mittels 
Breakpoints ermittelst?
#3601777
Lesenswert?

Michael Skropski schrieb:
> Ich möchte mit dem vom Gyroskop ermittelten Winkel und der Daten eines
> Beschleunigungssensors die Beschleunigung in x, y und z Richtung
> berechnen. Wenn die Neigung 10° ist und der Beschl.sensor nur einen
> z-Teil angibt, ist die Bewegung ja in Wirklichkeit cos(10°) * Wert nach
> oben und sin(10°) * Wert zur hingekippten Seite.

Das Gyroskop gibt aber auch keinen Winkel aus, sondern nur Drehraten. 
Durch die Aufintegration und Konversion in Winkel erzeugst Du bereits 
einen Fehler, bei der Umwandlung durch den Sinus auch wieder. Wenn Du 
nicht mit Winkeln, sondern Vektoren (Quaternionen) arbeitest, kannst Du 
Dir die ganze Umwandlung sparen. Habe gerade keien Referenz griffbereit, 
aber es gibt ja einen Haufen IMU-Codes im Netz.
OP #3601780
Lesenswert?

Ich hab MPLAB X, damit sollte das doch auch gehen, oder? Muss ich mal 
gucken, wie das genau geht.

Ansich wollte ich MikroC for dsPIC nehmen. Dort kann man bei Statistic 
die Größe der einzelnen Funktionen ansehen, aber nicht deren 
abarbeitungszeiten. Und einen Simulator gibt es nicht, oder? Wenn ja, 
muss ich ihn bisher immer übersehen haben.

Das problem ist ja, wenn ich das bei MPLAB X austeste, nutze ich ja auch 
einen anderen Compiler mit ggf anderen Optimierungen. Somit kann ich das 
Ergebnis ja schlecht auf den MikroC Compiler übertragen.

Die letzte Möglichkeit wäre mit nem Timer zu messen und auf nem Display 
anzuzeigen, doch ich dachte, dass es ggf einfacher geht und vor allem 
ohne extra Aufbau geht.
OP #3601800
Lesenswert?

LostInMusic schrieb:
>>erg = x - (x*x*x/6) + (x*x*x*x*x/120)
>
> wobei Du da auch mit drei Multiplikationen auskommst:
>
> s = x*x;
> erg = x - s/6 + (s*s*x)/120

Muss dann ja s*x/6 sein. Aber trotzdem ne Ersparnis.

Tim    schrieb:
> Das Gyroskop gibt aber auch keinen Winkel aus, sondern nur Drehraten.
> Durch die Aufintegration und Konversion in Winkel erzeugst Du bereits
> einen Fehler, bei der Umwandlung durch den Sinus auch wieder. Wenn Du
> nicht mit Winkeln, sondern Vektoren (Quaternionen) arbeitest, kannst Du
> Dir die ganze Umwandlung sparen. Habe gerade keien Referenz griffbereit,
> aber es gibt ja einen Haufen IMU-Codes im Netz.

Danke für den Tipp. Da werd ich mal nachgucken. Das aufintegrieren war 
mir bewusst, nur wusste ich nicht, das man da so große Fehler macht.
#3601808
Lesenswert?

>> Das Gyroskop gibt aber auch keinen Winkel aus, sondern nur Drehraten.
>> Durch die Aufintegration und Konversion in Winkel erzeugst Du bereits
>> einen Fehler, bei der Umwandlung durch den Sinus auch wieder. Wenn Du
>> nicht mit Winkeln, sondern Vektoren (Quaternionen) arbeitest, kannst Du
>> Dir die ganze Umwandlung sparen. Habe gerade keien Referenz griffbereit,
>> aber es gibt ja einen Haufen IMU-Codes im Netz.
>
> Danke für den Tipp. Da werd ich mal nachgucken. Das aufintegrieren war
> mir bewusst, nur wusste ich nicht, das man da so große Fehler macht.

Die Fehler erzeugt man natürlich trotzdem, aber der ist überschaubarer, 
wenn man im gleichen Koordinatensystem bleibt :)
Gast #3601816
Lesenswert?

>Muss dann ja s*x/6 sein. Aber trotzdem ne Ersparnis.

Args... danke.

Neuer Drei-Multiplikationen-Versuch:

x2 = x*x
x3 = x2*x
erg = x - x3/6 + x2*x3/120

oder

s = x*x
erg = x*(1 - s*(1/6 + s/120))

Jetzt stimmt's aber.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren