timing/ zeit frage

[tubbu (Gast)]

Hallo,
ich habe hier einen at90s2343, der mit dem internen 1Mhz Oszillator
läuft.

Ich habe eine relativ zeitkritsche Anwendung und müsste jetzt wissen,
wie lange der uC für einen befehl braucht.

bedeutet 1Mhz   1 Befehl in 1 Microsekunde?

Wie lange bracht zum beispiel ein Befehl wie
sbi(DDRB,0); oder i=1;

Gibt es eine Möglichkeit das allgemein festzustellen?
Oder muss ich den entsprechenden Teil in Assemler schreiben?

Danke für die Hilfe

[Alex (Gast)]

Wofür gibt es einen Simulator?

[Thorsten (Gast)]

> bedeutet 1Mhz 1 Befehl in 1 Microsekunde?

Kann man so sagen. Aber natürlich nur dann, wenn der Befehl auch nur
einen Takt benötigt. Genau genommen bedeutet 1MHz eben 1.000.000 Takte
pro Sekunde.

Thorsten

[tubbu (Gast)]

Danke,
was den Simulator angeht, das ist bei meinem Programm etwas schwierig,
da es ein Signal auswertet.

@ Thorsten
Woher weiß ich welcher Befehl wieviel Takte benötigen?

Zum Beispiel eine for-schleife

int i;                 //ein Takt
for(i=0;i<10,i++)      //ein Takt für i=0;
{                      //jeweils einen Takt für i<10, einen für i++
   asm volatile ("nop");   //ein Takt
}

Ist das richtig so? Oder muss man da viel mehr beachten?

Danke

[Jörg Wunsch (Gast)]

Die Anzahl der Takte steht im Datenblatt (bzw. in der
Befehlsbeschreibung).  Sie ist nicht für jeden Befehl immer gleich,
typischerweise brauchen bedingte Sprungbefehle bei zutreffender
Bedingung länger als bei fehlgeschlagener.

Die Schleife ist im Prinzip OK so.  Wenn es Dir aber nur auf eine
Verzögerung ankommt, kannst Du auch die Makros aus <avr/delay.h>
benutzen.  Die sind schon ausgezählt. :-)

Längere Verzögerungen macht man besser mit einem Hardware-Timer.

[Michael (Gast)]

Wenn du eine so zeitkritische Applikation hast setze einen Quarz ein.
Ich meine der interne Oszillator ist ziemlich empfindlich was die
temperatur angeht.
Michael

[hans (Gast)]

<<<<<<<<<snip>>>>>>>>>
Zum Beispiel eine for-schleife

int i;                 //ein Takt
for(i=0;i<10,i++)      //ein Takt für i=0;
{                      //jeweils einen Takt für i<10, einen für i++
   asm volatile ("nop");   //ein Takt
}
<<<<<<<<<snip>>>>>>>>>


das kann man nicht so sagen...allein schon das speicher allocieren für
einen int dauert länger..

wenns die variable im sram ist hängts davon ab wie schnell das
ist..dann is es eine 16-bit variable also dauerts schon mal
länger...zuweisungen sowieso..dann noch abfragen wie < oder > dauern
wieder anders... (hat der avr sowas überhaupt im befehls satz??)

nur bei asm volatile("nop") kannst du dir sicher sein das das 1nen
zyklus braucht ;) und der hängt vom oszillator ab ;)

es gibt übrigens ein avr-gcc inline asm cookbook..da drinnen ist einen
schöne delay funktion beschrieben... die verwend ich normalerweise...

wenn du auf signale warten bzw richig generieren musst kommst um asm
nicht herum...leider...

73 de oe6jwf

[tubbu (Gast)]

Ich hab ein bisschen mit dem Oszi gemessen und habe folgendes
festgestellt:

Wenn ich eine for-Schleife mit unsigned char als Veriable hab
und diese von 0 bis x durchlaufen lasse:
--------------------
unsinged char i;
for(i=0;i<x;i++)
{
     asm volatile ("nop");   //ein Takt
}
--------------------

So verhält sich die Delaydauer von x=1 bis x=5 linear, macht bei x=6
allerdings einen plötzliche Sprung, x=6 dauert etwa drei mal solange
wie x=5.

Für Delays verwende ich schon <avr/delay.h>, aber das Programm selbst

war nicht mehr einschätzbar.
Hab deshalb die schleife weggelassen und die Befehle per hand 8 mal
hintereinander geschrieben.
Dadurch wurde das Programm zwar größer, aber auch erheblich schneller.
Dann hab ich das Timing noch per _delay_loop_1 optimiert.

Hätte nciht gedacht, dass der Unterschied so extrem ist.

Danke an alle, die hier gepostet haben.

Ich werde mit in zukunft überlegen, ob ich eine schleife verwende, oder
doch lieber Copy & Paste....

Tubbu

[Jörg Wunsch (Gast)]

Sowas nennt sich `loop unroll'. ;-)

Wenn Du statt -Os -O3 zum Compilieren nimmst, bekommst Du zwar
größeren aber u. U. eben auch wirklich schnelleren Code hin.  -Os
heißt eben `optimize for size'.  Im Zweifelsfalle schaue man sich
aber immer den Assembleroutput an...