Timer Starten und Initialisieren dauert wie lange?

[Daniel R. (zerrome)]

Hallo,
ich hab da mal ne Frage zu folgendem Code:

void waitms(uint16_t mis){  
  
  //(16.000.000:64):250=1000
  TCCR0 |= (1<<CS01)|(1<<CS00);    //prescaler 64
  TCNT0 |= 0x6;    //vorladen (moch 250 Schritte)      
  TIMSK |= (1<<TOIE0);  //timer interupt an

  ms=0;      //zähler initial
  
  while(1){
    if(ms==mis){  //gezählte ms (in ISR)= ms vorgabe
      ms=0;
      break;
      }
    }
  TIMSK |= (0<<TOIE0);  //timer interrrupt aus  
}

und

ISR(TIMER0_OVF_vect){  //Timer0 overflow ISR = 1khz
  TCNT0 |= 0x6;  //vorladen bei 6 (noch 250 schritte)
  ms++;    //milli sec zählen  
}

das funktioniert soweit auch.

Aber:

Wie viel Zeit geht durch das Starten und Initialisieren des Timers 
verloren?
Wenn ich das nun mit einem zweiten Timer messe, z.B. mit einem 16 bit 
Timer mit Prescaler 1 könnte man doch recht genau herausbekommen wie 
lange der Timer0 läuft oder?

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

Daniel Rau wrote:

> Wie viel Zeit geht durch das Starten und Initialisieren des Timers
> verloren?

Falls du damit die Registerzuweisungen meinst: 3 Takte, sind ja nur
3 OUT-Befehle am Ende.

Falls du das Nachladen der Zeitkonstante im Overflow-Handler meinst,
das kannst du an Hand des Datenblatts sowie des generierten
Assemblercodes nachzählen.  Es vergeht die Zeit für die Interrupt-
annahme (wimre sind das 10 Takte einschließlich des Sprungs zur ISR)
und dann die des ISR-Prologs, bis das Neusetzen von TCNT0 erfolgt.

Generell keine sonderlich empfehlenswerte Methode.  Sowie es mehr als
diesen einen Interrupt im System gibt, entsteht potenziell ein Jitter
in dieser Interrupannahmezeit.  War früher nicht anders möglich, aber
bei aktuellen AVRs implementieren die meisten Zähler den CTC-Modus
(clear timer on compare match), mit dem man einen vergleichbaren
Effekt rein in der Hardware realisieren kann (und damit ganz ohne
das Erbsenzählen der ISR-Takte).

[Daniel R. (zerrome)]

Ja es gibt mehr als diesen einen Interrupt den ich benutze,
also um genau zu Wissen wie lange die Cpu braucht, seh ich mir einfach
die Assembler Befehle an, gute Idee, die Zeiten für die Ausführungen 
stehen ja im Datenblatt...

Leider habe ich die Timer die ctc können schon für etwas anderes in 
Planung.

Blöde frage, wie seh ich mir den erzeugten Assembler Code an? Ich 
benutze KontrollerLab...

Danke für den Denkanstoß

[Läubi .. (laeubi)]

Du könntest das HEX File in AVR Studio laden...
Alternativ vieleicht auch inline ASM??
Ansonsten sollte es (realtiv) egal sein wie lange das laden dauert, wenn 
du nur gleiche Zeitabstände brauchst und es nicht auf ns ankommt (1 Takt 
= 62,5 nsek) das laden wirs nicht länger als 10 Takte brauchen.

[Daniel R. (zerrome)]

Hm, ja so gesehen
hat man wohl noch ne menge Platz bevor man in den promille Fehler 
Berreich kommt :)
Brauche das eigentlich nur um bischen Zeit vergehen zu lassen. 
Interessierte
mich trozdem halt wie lange das so dauert...

AVR Studio is ja nur für Windows, das möchte ich nicht so...
Gibt bestimt für Linux nen hex to asm Konverter oder so

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

Du kannst dir mit avr-objdump -d das gesamte ELF-File disassemblieren
lassen, oder du kannst den Compiler mit -S (statt -c) aufrufen, damit
er dir den generierten Assemblercode (in einer Datei mit der Endung
.s) direkt erzeugt.  Normalerweise ist dieser Assemblercode nur eine
Zwischenstufe, die er dann dem Assembler selbst übergibt.

Bezüglich des möglichen Jitters wäre es wichtig, dass alle anderen
ISRs entweder so kurz wie möglich sind oder aber zumindest die
Interrupts so frühzeitig wie möglich wieder freigeben, damit die
Timer-ISR zum Zuge kommen kann.