selbe Anweisung, unterschiedliche Auführungsdauer

Gast #1606614
Lesenswert?

Hallo Leute,


ich programmiere auf einem AVR mit AVR-GCC und debugge mit AVR-Studio4
nun bin einem echt heimtückischen Bug in meinem Programm auf der Spur...
Ich habe bemerkt, dass eine meiner Funktionen manchmal viel zu lange 
dauert, um berechnet zu werden.
Klar, kann passieren, dachte ich, schließlich wird sie ja immer mit 
unterschiedlichen Werten gespeist.
Nun wollte ich gucken, bei welcher Art von Werten die Funktion Probleme 
bekommt, habe aber überhaupt keine Systematik finden können.
Habe eine acos Funktion in meiner Funktion. Es scheint, als ob hier der 
Bug sitzt...
Zufällig bin ich darauf gestoßen, dass selbst wenn ich in meinem Prog 
acos mit den Selben Werten lade, es manchmal (aber eher selten) statt 
4000 Takte 56000 Takte braucht! Das Ergebnis ist dabei immer richtig.

Habe daraufhin versucht das Nachzustellen:
habe an der Stelle, wo das auftritt folgendes gemacht:
1
    debug31[0] = acos(((uint16_t)(OS*OS) + d123*d123 - (uint16_t)(US*US)) / (2 * OS * d123));
2
    debug31[0] = acos(((uint16_t)(OS*OS) + d123*d123 - (uint16_t)(US*US)) / (2 * OS * d123));
3
    debug31[0] = acos(((uint16_t)(OS*OS) + d123*d123 - (uint16_t)(US*US)) / (2 * OS * d123));
4
    debug31[0] = acos(((uint16_t)(OS*OS) + d123*d123 - (uint16_t)(US*US)) / (2 * OS * d123));

d123 ist ein float, alles andere sind Konstanten.
Manchmal, nicht systematisch, braucht eine dieser Rechnungen 56000 
Takte.

Woran könnte das liegen?
Ich habe eine sehr zeitkritische Anwendung und kann auf diese 52000 
Takte kaum verzichten...


Gruß, Yaro
Gast #1606642
Lesenswert?

Ich habe jetzt versucht, das Problem ganz gesondert nachzustellen, doch 
leider klappt das nicht... Anscheinend tritt es nur im Zusammenhand mit 
dem restlichen Programm auf...
Ein Überlauf von sonstwas kann es nicht sein, SRAM steht noch genügend 
zu Verfügung., außerdem ist das Ergebnis ja auch immer richtig...

Ich bin echt am Verzweifeln...
Gast #1606667
Lesenswert?

OMG......Wie blöd war ich.........
Natürlich liegts an einem Interrupt!

Ich bin nicht darauf gekommen, weil dort normalerweise kein Interrupt 
auftreten kann... Zu debug-Zwecken habe ich es aber verändert, weil mir 
AVR-Studio sonst zu lange rechnet!

Manchmal sieht man den Wald vor lauter Bäumen nicht!

Danke für deine Hilfe!

Gruß, Yaro
Gast #1606670
Lesenswert?

Ich hatte mal ein ähnliches Problem, nachdem ich im Simulator was am 
Non-Volatile-Memory-Controller verstellt hatte. (Das war aber ein 
ATxmega.) Die LPM-Instruktionen, die sin() und cos() verwendeten, 
brauchten dann plötzlich länger.

Wenn es nur im Zshg. mit dem restlichen Programm auftritt, lösche doch 
nach und nach das drumherum weg. Wenn es dann geht, weißte in welchem 
Bereich der Fehler ausgelöst wird.

Gruß

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