selbe Anweisung, unterschiedliche Auführungsdauer

[Yaro (Gast)]

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:

    debug31[0] = acos(((uint16_t)(OS*OS) + d123*d123 - (uint16_t)(US*US)) / (2 * OS * d123));
    debug31[0] = acos(((uint16_t)(OS*OS) + d123*d123 - (uint16_t)(US*US)) / (2 * OS * d123));
    debug31[0] = acos(((uint16_t)(OS*OS) + d123*d123 - (uint16_t)(US*US)) / (2 * OS * d123));
    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

[Yaro (Gast)]

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

[Frank L. (franklink)]

Hallo Yaro,
schonmal an Deine Interrupts gedacht, die den "normalen Programmablauf" 
immer mal wieder kurzfristig unterbrechen und damit "indirekt 
verlängern"

Gruß
Frank

[Yaro (Gast)]

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

[Gaast (Gast)]

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ß

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Yaro schrieb:
>> Ich habe eine sehr zeitkritische Anwendung und kann auf diese 52000
>> Takte kaum verzichten...
> Natürlich liegts an einem Interrupt!
Du solltest mal die Interruptroutine überarbeiten, wenn die so lange 
braucht... :-o