www.mikrocontroller.net

Forum: Compiler & IDEs timing/ zeit frage


Autor: tubbu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wofür gibt es einen Simulator?

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: tubbu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:

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

Autor: hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<<<<<<<<<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

Autor: tubbu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.