atan2() auf ATmega Rechenaufwand per avr-gdb abschätzen

[Jens (Gast)]

Hallo,

werte mit einem ATmega einen Kompass aus, dazu sind atan() Berechnungen 
notwendig. Ich möchte nun gerne wissen, wieviel Rechenaufwand das für 
den avr ist.
Dazu lasse ich ein Testprogramm durch den Simulator laufen, das zwei 
feste doubles "tangiert".
Leider gibts auf den ersten Blick keine Möglichkeit, die vergangenen 
Taktzyklen auszugeben.

Ich verwende Eclipse mit avr-Plugin, avr-gdb und simulavr.

Wie lässt sich diese Information anzeigen?
Alternativ geht auch ein Timer im Hintergrund, denn Register lassen sich 
auslesen.

Bin für alle Anregungen dankbar!

[Detlef _. (detlef_a)]

Das ist keine Antwort auf Deine Frage(n), aber atan in float aufm AVR 
ist nicht so rechenaufwendig.

Ansonsten hier was:

Beitrag "Goertzel-Algorithmus und Signed Fractional Format"

Cheers
Detlef

[Wolfgang Horn (Gast)]

Jens schrieb:
> werte mit einem ATmega einen Kompass aus, dazu sind atan() Berechnungen
> notwendig. Ich möchte nun gerne wissen, wieviel Rechenaufwand das für
> den avr ist.
> Dazu lasse ich ein Testprogramm durch den Simulator laufen, das zwei
> feste doubles "tangiert".

Hi, Jens,

Vermutlich meinst Du "float", das aber "double" benannt wird, inkorrekt, 
aber zweckmäßig.
Aber selbst float ist für Berechnung eines Kompass mit zitternder Nadel 
übertrieben. ob die nun mechanisch sichtbar zittert oder ob der digitale 
Kompasswert verrauscht scheint.

int ist mehr als ausreichend. Daher kannst Du Rechenzeit sparen durch 
Tabellen, Festkomma-Arithmetik und CORDIC, worauf Detlef ja schon 
hingewiesen hat.


Ciao
Wolfgang Horn

[Detlev T. (detlevt)]

Der Simulator vom AVR Studio kommt nicht in Frage?

Für eine solche Anwendung habe ich schon erfolgreich den 
CORDIC-Algoritmus angewendet. Wenn man den richtig implementiert, kommt 
man da mit integer-Addition und -subtraktion sowie Bit-Shiften aus. Also 
die Dinge, die ein µC ganz besonders gut kann.

Im Anhang die Routine, ich damals verwendet habe (SDCC für AT89C2051, 
lang, lang ist es her. :-) ) Die gibt den Winkel [0°..360°[ als 
16-Bit-Wert zurück, also 0x0000 = 0°, 0xFFFF = 359.9945°. x und y müssen 
vorher nicht normiert werden.

Die Genauigkeit hängt von der Zahl der Schritte ab, die Rechenzeit 
natürlich auch. Insgesamt ist dieser Algorithmus aber irre schnell.

Neben dem Winkel fällt auch die Länge des Vektors insgesamt ab (also 
sqrt(x*x+y*y) ) Das ist manchmal ganz nützlich, um Fehler zu detektieren 
bzw. die Genauigkeit zu ermitteln, die durch die Eingangsdaten erreicht 
werden kann.

[Jörg W. (dl8dtl) (Moderator)]

Meiner Erinnerung nach gibt simulavr auf seiner Console die aktuelle
CPU-Zeit bei einem Breakpoint mit aus.  Es müsste also genügen, wenn
du vor und nach der Berechnung einen Breakpoint setzt.

Ansonsten messe ich solche Zeiten immer in der Hardware mit einem
Timer: Vorteiler so wählen, dass der geschätzte Zeitbedarf mit
Sicherheit ohne Überlauf erfassbar ist, Timer vor der Berechnung
starten, danach anhalten und Zählerwert auslesen und anzeigen.
Gleitkomma hast du sowieso dabei, da kannst du dir das auch gleich
noch vom AVR sauber anhand von CPU-Takt und Vorteiler in Millisekunden
umrechnen lassen.  Auf der Hardware gibt man das über eine UART aus
oder sowas, im Simulator entweder per sprintf() in einen Puffer
schreiben oder in einer als volatile deklarierten Variable hinterlegen,
die man sich im Debugger angucken kann.