mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Zeitabschätzung


Autor: Paul W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Ich hätte eine Frage zu Assembler. Und zwar habe ich eine zeitkritische 
Interrupt-Routine in C geschrieben. Ich hab es jetzt so weit optimiert, 
dass im Assemblercode knapp 100 'Befehle' stehen (hab mir die .lss-Datei 
angeschaut).
Im AVR-Tutorial steht, dass sogut wie jeder Assembler-Befehl einen Takt 
benötigt, also braucht der µC bei einem Takt von 20MHz dann knapp 5µs 
(100 / 20000000) für die Abarbeitung dieser Routine. In der 
Interrupt-Routine sind keine If-Verzeigungen, sie müsste also in 
konstanter Zeit ausgeführt werden. Kann ich von dieser Rechnung 
ausgehen?
Der µC macht eigentlich nichts anderes, als gerade diese 
Interrupt-Routine abzuarbeiten (natürlich sobald sich was am Pin tut). 
Von welcher Zeitverzögerung kann ich ausgehen, bis der µC wirklich die 
Interrupt-Routine abarbeitet (passiert vermutlich nicht augenblicklich 
oder?)?

Vermutlich wäre der Einsatz eines FPGAs oder ähnliches (damit kenn ich 
mich nämlich gar nicht aus) logischer als der Einsatz eines 
Microkontrollers in diesem Fall, aber die meisten FPGAs haben definitiv 
zu viele Pins und sind ein wenig überdimensioniert. Der Microkontroller 
wandelt nämlich nur Signale um...

Ich würde ungern eine Simulation durchführen, da ich nicht die Software 
hier habe... mir wäre eine möglichst exakte Aussage lieber, sofern das 
überhaupt möglich ist?!

Ich kenne mich in Assembler außerdem nur in soweit aus, dass ich den 
Code lesen kann, aber ihn auch nur verstehe, weil ich weiß was da 
gemacht werden soll. Ist die lss-Datei denn überhaupt das fertige 
Programm in Maschinensprache (ist ja dokumentiert, aber ohne Kommentare 
ist es doch das richtige Programm?)?

Danke für eure Zeit ;-)
Ich habe zwar eine Seite über die Ausführungszeit gefunden, weiß aber 
nicht wie aktuell und 'seriös' die Seite ist, also habe ich hier 
nachgefragt ;-).

Paul

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paul W. schrieb:

> Ich habe zwar eine Seite über die Ausführungszeit gefunden, weiß aber
> nicht wie aktuell und 'seriös' die Seite ist, also habe ich hier
> nachgefragt ;-).

Im Zweifelsfall gehen wir zum Schmid und nicht zum Schmidl.
Wenn auf diesem Planeten wohl jemand weiß, wieviele Zyklen jeder 
einzelne Befehl tatsächlich dauert, dann wird das wohl Atmel sein. Und 
tatsächlich gibt es bei Atmel das "Instruction Set Summary", in dem 
unter anderem auch die Taktzyklen jedes Befehls aufgeführt ist.

PS: Auch AVR-Studio kennt diese Anzahl.
Einfach mal den Cursor im Textfenster auf einen Befehl stellen und F1 
drücken :-)

Du kannst jetzt natürlich hergehen und händisch alle Befehle addieren. 
Du kannst aber auch im Simulator einen Breakpoint auf den Anfang der ISR 
setzen, einen auf das Ende, die ISR durchlaufen lassen und im AVR-Studio 
die Anzahl der vergangenen Takte ablesen.

> Von welcher Zeitverzögerung kann ich ausgehen, bis der µC wirklich
> die Interrupt-Routine abarbeitet (passiert vermutlich nicht
> augenblicklich oder?)?

Das kann man so pauschal nicht sagen. Das hängt auch vom Befehl ab, der 
gerade unterbrochen wird. Dieser Befehl wird natürlich noch fertig 
abgearbeitet. Details dazu finden sich im Datenblatt. Das wiederrum gibt 
es, wie könnte es anders sein, bei Atmel.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Von welcher Zeitverzögerung kann ich ausgehen, bis der µC wirklich die
> Interrupt-Routine abarbeitet (passiert vermutlich nicht augenblicklich
> oder?)?

Ziemlich augenblicklich, der laufende Befehl wird noch zu Ende 
abgearbeitet, der Interrupt-Call ausgelöst, und los geht's,
wenn, ja wenn er nicht die Interrupts gesperrt hat weil er noch
in der Bearbeitung des vorherigen Pinwechsels steckte, also
wenn er immer noch in der vorher aufgerufenen Interrupt-Routine
steckt.

Wenn die Interrupt-Routine zu langsam sein sollte:
Neu schreiben in Assembler wird die Laufzeit auf 25% kürzen,
vor allem weil du sagst, daß der uC ansonsten nichts zu tun
hat, also auch keine Register gesetzt, geändert etc. werden
müssen.

Noch ein bischen schneller geht es, wenn du aktiv auf einen
Flanenwechsel wartest, also gar keine Interrupts, sondern
das Hauptprogramm einfach so schreiben, dass es in einer
kleinen engen Schleife wartet, bis sich am Eingang was tut.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Von welcher Zeitverzögerung kann ich ausgehen, bis der µC wirklich die
>Interrupt-Routine abarbeitet (passiert vermutlich nicht augenblicklich
>oder?)?

Ist im Datenblatt unter 'Interrupt response time' zu finden.

MfG Spess

Autor: Paul W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für eure Antworten.
Wenn man nicht weiß, wie das heißt, dann kann man auch nicht danach 
suchen :-/. Aber jetzt weiß ich ja wie es heißt: "Instruction Set 
Summary". Ich habe bei der Rechnung aber einen Fehler gemacht: Um zu 
bestimmen, wie viele Assembler-Befehle es sind habe ich einfach die 
Anfangsadresse der Interruptroutine von der Endadresse abgezogen. Was 
ich nicht bedacht habe ist, dass ein Befehl ja aus mehreren Bytes 
besteht. Ich habe jetzt händisch nochmal die Ausführungszeit addiert und 
komme auf 65 Zyklen. Das ist doch recht ordentlich und reicht für meine 
Anwendung vollkommen.

Ich habe es per Hand ausgerechnet, weil ich mit diesem AVR-Studio echt 
meine Probleme habe... es will nie so wie ich will (ich behaupte mal, 
ich kenne mich schon ein wenig mit Compilern und Debuggern aus, aber das 
AVR-Studio ist echt gewöhnungsbedürftig, oder ich checks einfach nicht, 
also benutz ich zum simulieren VMLab, weil das auch noch einige externe 
Beschaltungen ermöglicht. Habe ich bisher bei AVR-Studio nicht 
gesehen?).

Das mit dem aktiven Warten auf den Flankenwechsel: Ich glaube das macht 
es nur schlimmer... meine main:
while(1);

;-)... die Interrupt-Routine macht es meiner Meinung nach wesentlich 
übersichtlicher.
Außerdem hatte ich mal eine ähnliche Anwendung und die Interrupt-Methode 
hat eine höhere Frequenzen mitgemacht als die andere Methode (ständiges 
Abfragen in der main).

Und wieder einmal merke ich, dass echt jedes kleinste Details im 
Datenblatt steht... wenn man es denn auch mal zur Hand nimmt... was ich 
ihn diesem Fall dummerweise nicht getan habe...
Nächstes mal geb ich mir mal mehr Mühe mit der Suche...

Danke nochmal für eure Antworten, meine Fragen sind alle beantwortet 
:-).

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Ich habe es per Hand ausgerechnet, weil ich mit diesem AVR-Studio echt
>meine Probleme habe...

Aber im Simulator vom AVR_Studio hättest du das einfach ablesen können.

MfG Spess

Autor: Paul W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gesagt: Ich stehe in Konflikt mit dem AVR-Studio... wenn du mir 
sagst wo, dann schau ich nochmal nach :-)... ich weiß es echt nicht, F1 
bewirkt bei mir gar nichts.

Autor: Paul W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zitat von MaWin:

"Wenn die Interrupt-Routine zu langsam sein sollte:
Neu schreiben in Assembler wird die Laufzeit auf 25% kürzen,
vor allem weil du sagst, daß der uC ansonsten nichts zu tun
hat, also auch keine Register gesetzt, geändert etc. werden
müssen."

Du bringst mich auf eine Idee...
Wenn ich mir den Assemblercode anschaue, fällt mir auf, dass beim Aufruf 
der Interrupt-Routine erstmal 10 oder mehr Register auf den Stack gelegt 
werden (weil sie in der Interrupt-Routine benutzt werden) und beim 
beenden logischerweise wieder vom Stack geholt werden (was letztendlich 
wahrscheinlich mehr Zyklen in Anspruch nimmt als die Routine selber!). 
Aber eigentlich ist das total überflüssig, weil die Register nirgendwo 
sonst benutzt werden. Dann mach ich mal an Assembler ran...

Danke für den Tipp!

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dafür gibts Compileranweisungen, dass bitte zu unterlassen (allerdings 
sollte man dann schon wissen, was man tut)
#pragma savereg-
.
.
.
#pragma savereg+

oder so ähnlich :-)

Heutzutage sollte man aber von einem Compiler erwarten, dass er nur das 
Nötige sichert. Wenn er nicht komplett stur ist, hängt das natürlich von 
den eingestellten Optimierungen ab. Optimieren auf Codesize bedeutet 
dann i.a. auch, dass für alle ISR die gleiche Sicherungs- und 
Wiederherstellungsroutine benutzt wird.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Von welcher Zeitverzögerung kann ich ausgehen, bis der µC wirklich die
>> Interrupt-Routine abarbeitet (passiert vermutlich nicht augenblicklich
>> oder?)?
>
>Ziemlich augenblicklich, der laufende Befehl wird noch zu Ende
> abgearbeitet,

Der bis zu 5 Taktzyklen brauchen kann.

> der Interrupt-Call ausgelöst, und los geht's,

Naja, nicht ganz. Zuerst wird mal der Program-Counter auf den Stack 
gelegt und die Interrupts deaktiviert. Dann wird in die 
interrupt-Vektor-Tabelle gesprungen. Kostet zusammen 4 Taktzyklen.  Dort 
steht dann je nach AVR-Modell ein rjmp oder ein jmp, der dann nochmal 2 
bzw. 3 Taktzyklen braucht. Dann sind wir am Anfang der ISR. Da muß dann 
erstmal das SREG gesichert werden, wozu es aber davor noch ein Register 
braucht, das auch gesichert werden muß. Sowas wie:
    push r16
    in r16, SREG
    push r16

Das bringt nochmal 5 Taktzyklen dazu. Also sind hier schon bis zu 16 
Taktzyklen vergangen. Erst dann kann man sich mal damit beschäftigen, 
ggf. noch weitere Register zu sichern und dann den eigentlichen Code der 
ISR auszuführen.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Heutzutage sollte man aber von einem Compiler erwarten, dass
> er nur das Nötige sichert.

Prust.

> Zuerst wird mal der Program-Counter auf den Stack gelegt und
> die Interrupts deaktiviert. Dann wird in die interrupt-Vektor-
> Tabelle gesprungen. Kostet zusammen 4 Taktzyklen.  Dort steht
> dann je nach AVR-Modell ein rjmp oder ein jmp, der dann nochmal
> 2 bzw. 3 Taktzyklen braucht.

Das ist der Interrupt-Call von dem ich sprach.

Das Sichern der Register wurde danach noch mal extra erwähnt.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das mit dem aktiven Warten auf den Flankenwechsel:
> Ich glaube das macht es nur schlimmer... meine main:
> while(1);

Wie gesagt, es spart noch ein paar Taktzyklen ein.

loop:
 SBIC port,bit
 RJMP -2
 :
 deine Routine bei fallender Flanke
 :
 SBIS port,bit
 RJMP -2
 :
 deine Routine bei steigende Flanke
 :
 RJMP loop

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paul W. schrieb:
> Das mit dem aktiven Warten auf den Flankenwechsel: Ich glaube das macht
> es nur schlimmer... meine main:
> while(1);

Wenn Du die Ausführungsebene Main nicht nutzt, verschenkst Du CPU-Zeit.

Wenn es nur ein Interrupt ist, dann poll einfach und schon entfällt das 
ganze CALL, PUSH, POP, RETI-Geraffel.
Pseudocode:
main()
{
  init();
  for(;;){
    if( Int_Flag == geloescht )
      continue;
    loesche_int_flag();
    do_int_stuff();
  }
}


Peter

Autor: Paul W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, da bin ich wieder...
Nachdem meine ersten Schritte in Assembler eher eine Qual waren, habe 
ich es dann doch noch geschafft den C-Code nach Assembler zu portieren 
und komme auf unschlagbare Größen (also schom im positiven Sinn :-) ).

Natürlich nur mit Einschränkungen:

- Die verwendeten Register brauchen nicht auf den Stack gelegt werden 
und anschließend wieder von ihm runter
- Durch einen anderen Anschluss der Hardware fallen einige 
bit-Operationen weg

Ich habe im Assembler-Code vom C-Compiler außerdem einigen Code 
entdeckt, den ich vom Sinn her nicht verstehe:
ldi r30, 0
... ;(nix mit Z und auch nix mit r30)
andi r30, 0

Mit dem Optimierungsgrad 3 kommt schon wesentlich weniger Code raus, 
aber den sollte man ja nicht immer benutzen (kenne mich da zu wenig 
aus)?! Habe mich damit auch nicht weiter beschäftigt, tat mir mal ganz 
gut mich ein wenig mit Assembler auseinander zu setzen.

Ich habe das ganze in AVR-Studio getestet (weil VMLab irgendwie einen 
Bug hat, aber wird ja leider nicht mehr weiter entwickelt)... hab mich 
da auch erstmal mit rumgeschlagen, bis ich das ganze verstanden habe. 
Aber es funktioniert :D!

Falls der Autor des ASM-Tutorials das hier liest: Ein wenig mehr mit dem 
Z-Pointer und Arrays im Tutorial wäre toll. Wenn man z.B. nicht auf ein 
konstantes Array-Element zugreifen will, sondern auf ein variables. Da 
das ja nicht im Tutorial steht, und es mich interessiert, frage ich 
hier, ohne ein neues Topic alleine dafür zu erstellen: Angenommen die 
Nummber des Elements steht schon im Register r16. Wäre das hier richtig?
ldi r31, HIGH(Array)
ldi r30, LOW(Array)
add r30, r16
adc r31, 0 ;Im Fall, dass ein Stapelüberlauf auftritt

Ich entschuldige mich schonmal bei euch dafür, dass ich hier schon 
wieder Fragen stelle, die eigentlich in ein neues Topic gehören.


>>Naja, nicht ganz. Zuerst wird mal der Program-Counter auf den Stack
>>gelegt und die Interrupts deaktiviert. Dann wird in die
>>interrupt-Vektor-Tabelle gesprungen. Kostet zusammen 4 Taktzyklen.  Dort
>>steht dann je nach AVR-Modell ein rjmp oder ein jmp, der dann nochmal 2
>>bzw. 3 Taktzyklen braucht. Dann sind wir am Anfang der ISR. Da muß dann
>>erstmal das SREG gesichert werden, wozu es aber davor noch ein Register
>>braucht, das auch gesichert werden muß.
Das SREG speichere ich nicht, muss man das? Habe ich im Tutorial was 
überlesen? Die restliche Sicherung der verwendeten Register findet jetzt 
auch nicht mehr statt.

So, nachdem ich das fürs erste geschafft habe, wage ich mich (da hier ja 
doch viele dazu raten) an die ständige Abfrage der Pins ran...

Danke für eure Antworten, ist echt ein tolles Forum (ja, ich sollte mich 
mal anmelden ^^)

Paul

Autor: Paul W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, gleich melde ich mich mal wirklich an... kann nämlich meinen Beitrag 
nicht editieren.
 SBIC port,bit
 RJMP -2
 :
 deine Routine bei fallender Flanke
 :
 SBIS port,bit
 RJMP -2
 :
 deine Routine bei steigende Flanke
 :
 RJMP loop

Routine bei fallender oder steigender Flanke wäre doch nicht ganz 
richtig. Routine bei LOW- oder HIGH-Pegel wäre das doch? Das will ich ja 
nicht ^^...
Da kommt dann noch ein xor hinzu + Speicherung eines zusätzlichen 
Registers und dann hab ich doch auch fast wieder nix gewonnen?

Egal, ich setz mich mal morgen an die hier vorgeschlagenen Möglichkeiten 
ran und sehe es dann vermutlich selber.

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.