Hallo Leute,
bin gerade an meinem ersten MC Projekt, es geht um
Software PWM. Meine Frage bezieht sich aber auf folgendes:
Kann ich beim AVR Studio bestimmen wie lang mein Interrupt dauert?
Mit Breakpoints ist klar, aber wenn ich wissen will, was die laengste
Abarbeitungszeit ueber eine Gewisse Simulationszeit war. Kann ich das
irgendwo nachvollziehen? Waere auch interessant fuer andere Funktionen,
aber hier muss ich wissen wie lange der max ISR dauert um den Timer
entsprechend anzupassen.
z.B. die max Taktzahl zum abarbeiten folgender Routine:
(Atmega8515, 8MHz, AVRStudio)
Danke schonmal und schenes Wochenende
ISR(TIMER1_COMPA_vect) {
static uint8_t pwm_cnt=0;
uint8_t tmp=0, i=0, j=1;
OCR1A += (uint16_t)T_PWM; //Compare Register erhoehen
for (; i<3; i++) {
if (pwm_setting[i] > pwm_cnt){
tmp |= j;
j<<=1;
}
else {
j<<=1;
}
}
PWM_PORT = tmp; // PWMs aktualisieren
if (pwm_cnt>=(uint8_t)(PWM_STEPS-1)){
pwm_cnt=0;
pwm_sine_step++;
}
else
pwm_cnt++;
}
Also erstmal sieht man das am C Code gar nicht. Dazu musst du dir den
entsprechenden Assembler-Code anschauen, den dein Compiler daraus macht.
Und dann einfach nachzählen ;-)
Ansonsten simulierste das halt mit AVRStudio und schaust auf den Cycle
Counter vor der ISR und danach.
MfG
Marius
tobias wrote:
> Kann ich beim AVR Studio bestimmen wie lang mein Interrupt dauert?
Nein.
Wie gesagt: HEX-Code oder asm anschauen und das Maximum über alle Pfade
bilden. Bei Neucompilierung kannst aber prinzipiell alles neu
durchzählen (andere Optionen, Compiler-Version, Makros, etc.)
Denkbar wäre, daß ein Compiler für spezielle Fälle ne WCET, also ne
statische Laufzeitanalyse macht. GCC zumindest kann das jedoch nicht.
Oder man hat das nötige Kleingeld für Tools wie
http://www.absint.de/ait/
@ Johann L. (gjlayde) Benutzerseite
>> Kann ich beim AVR Studio bestimmen wie lang mein Interrupt dauert?>Nein.
Blödsinn. Das kann man wunderbar und auf den Takt genau simulieren und
messen. Im AVR-Studio. Been tere, done that. Siehe Interrupt.
Falk Brunner wrote:
> @ Johann L. (gjlayde) Benutzerseite>>>> Kann ich beim AVR Studio bestimmen wie lang mein Interrupt dauert?>>>Nein.>> Blödsinn. Das kann man wunderbar und auf den Takt genau simulieren und> messen. Im AVR-Studio. Been tere, done that. Siehe Interrupt.
Vielleicht für einen Spezielfall.
Was machst Du bei Abhängigkeit von globalen Variablen/SFRs, Schleifen
und Verzweigungen die evtl davon abhängen? In diesem Fall musst Du alle
Pfade statisch abschätzen/analysieren.
Die vorliegende ISR ist einfach, aber schon wenn du Flags abtestest, ist
einfach ne Zeit stoppen naiv.
Von daher: AVR Studio kann Zeiten stoppen aber keine statischen Analysen
ausführen. Beides mögen in Spezialfällen wie hier gleich sein, im
allgemeinen Fall sind sie es nicht. D.h du hast hier mit dem Blick auf
den Code erkannt, daß beide übereinstimmen.
@Johann L. (gjlayde)
>Vielleicht für einen Spezielfall.
Man kann den Worst Case simulieren, das reicht in fast allen Fällen.
>Die vorliegende ISR ist einfach, aber schon wenn du Flags abtestest, ist>einfach ne Zeit stoppen naiv.
Nöö, man muss halt den längsten Pfad durchlaufen. Einmal mit und einmal
ohne gesetztes Flag und dann vergleichen.
>Von daher: AVR Studio kann Zeiten stoppen aber keine statischen Analysen>ausführen.
Das war gar nicht die Frage.
MFG
Falk
Falk Brunner wrote:
> @Johann L. (gjlayde)>>>Vielleicht für einen Spezielfall.>> Man kann den Worst Case simulieren, das reicht in fast allen Fällen.
Das Problem ist nicht, den worst case zu simulieren, sondern ihn zu
finden (im Sinne der Variablen, des Maschinenzustandes, die ihn
erzeugen).
> Nöö, man muss halt den längsten Pfad durchlaufen. Einmal mit und einmal> ohne gesetztes Flag und dann vergleichen.
Konkret ist die Zeit abhängig von den Werten von pwm_setting[] und von
pwm_cnt und T_PWM.
>>Von daher: AVR Studio kann Zeiten stoppen aber keine statischen Analysen>>ausführen.>> Das war gar nicht die Frage.>> die max Taktzahl zum abarbeiten folgender Routine:
Was ist das anderes als eine statische Abschätzung? Woher bist du
sicher, daß eine Simulation die max Anzahl liefern, wenn nicht
dadurch, dich per Blick in den Code darüber zu versichern?
AStudio übernimmt hier die Schweißarbeit des Taktzählens für einen
bestimmten Zustand der Maschine. Mehr nicht.
Anhand des obigen C-Codes siehtst du noch nichtmal, ob T_PWM ein Makro
ist, das zu einer Compilerzeit-Konstanten auflöst, oder nicht.
@ Johann L. (gjlayde) Benutzerseite
>Das Problem ist nicht, den worst case zu simulieren, sondern ihn zu>finden (im Sinne der Variablen, des Maschinenzustandes, die ihn>erzeugen).
Bei dem Beispiel des OPs? Hust, nicht wirklich.
>Konkret ist die Zeit abhängig von den Werten von pwm_setting[] und von>pwm_cnt und T_PWM.
Im Beispiel durchaus überschaubar. ;-)
>AStudio übernimmt hier die Schweißarbeit des Taktzählens für einen>bestimmten Zustand der Maschine. Mehr nicht.
Na das ist schon mal Einiges.
>Anhand des obigen C-Codes siehtst du noch nichtmal, ob T_PWM ein Makro>ist, das zu einer Compilerzeit-Konstanten auflöst, oder nicht.
Tja, aber der OP wird mit den Superanlaysetools auch ein wenig
überfordert sein. Und da er was lernen will, ist Hand-, respektive
Kopfarbeit der beste Lösungsweg hier.
MFG
Falk
Soetwas mache ich immer so, daß ich mir einen freien Pin nehme, der zu
Beginn auf low steht; bei Eintritt in die ISR setze ich ihn auf high,
beim Ende wieder auf low. Mittels Oszilloskop oder Digitalzähler kann
man dann sehr leicht die Interruptlänge messen (bis auf einige us wegen
des ISR-Overheads). Man kann auch zählen, wie oft der Interrupt eintrat.
Diese Methode ist auch gut geeignet, um innerhalb eines beliebigen
Programmablaufs Zeiten zu messen.
Und wenn man keinen Oszi hat, dann hängt man an diesen Pin einen
langsamen Tiefpass (einfaches RC-Glied) und misst die Spannung. Das
Ergebnis ist die effektive Auslastung des Controllers durch diesen
Interrupt. Oder fast, weil der Overhead der ISR darin fehlt.
Falk Brunner wrote:
> Tja, aber der OP wird mit den Superanlaysetools auch ein wenig> überfordert sein. Und da er was lernen will, ist Hand-, respektive> Kopfarbeit der beste Lösungsweg hier.
Seh ich auch so.
