Forum: Mikrocontroller und Digitale Elektronik Interrupt latenzzeit bei timer


von Ch D. (chrisu) Benutzerseite


Lesenswert?

Hi,
Bei meinem ARM at91sam7s256 ist die Interrupt Latenzzeit beim Timer 
Interrupt nicht immer gleich(6 Takte Unterschied). Da ich aber einen 
genauen Timer-Interrupt brauche, wollte ich in der ISR die Latenzzeit 
erkennen(nur wie?), und dann eventuell warten bis der richtige Zeitpunkt 
erreicht ist und dann mit der ISR weiter machen. Ist das so möglich und 
wenn ja wie?
Gibt es eine bessere Lösung dass ich immer bei genau dem gleichen 
Zeitpunkt die ISR starte? Bei meinem Atmega8 hat es funktioniert das ich 
immer zur selben zeit in der ISR war.
vielen Dank,
mfg chrisu

p.s angenommen im Haupt Programm werden nur 1-Takt lange Befehle 
ausgeführt.

von Peter D. (peda)


Lesenswert?

Das ist bei jeder CPU so, es muß ja erst der laufende Befehl beendet 
werden. Zusätzlich kommen noch Zeiten für das Beenden anderer Interrupts 
oder atomarer Zugriffe hinzu.

In der Regel braucht man auch keinen zyklusgenauen Interrupt. Es reicht, 
wenn der Timer zyklusgenau weiterzählt und das tut er.

Die Latenzzeit hat also keinerlei Einfluß auf den Timer. Es sei denn, 
man ist so verrückt und lädt den Timer im Interrupt mit einer Konstante.

Entweder man addiert den passenden Wert zum Timer oder Compareregister 
oder nutzt einen automatischen Clear oder Reload-Modus des Timers.


Peter

von ch. de (Gast)


Lesenswert?

hi,
danke für die Hilfe.
ich möchte ein vga Bild ausgeben, aber immer wenn der H sync Interrupt 6 
Takte zu spät kommt(ca 120nS.), ist die momentane Zeile auf dem 
Bildschirm verschoben. das Problem ist das die Latenzzeit nie gleich 
bleibt(immer ein bisschen verschoben). Selbst wenn im Hauptprogramm in 
einer Schleife 100Nops ausgeführt werden, ist der Interrupt verschoben. 
Warum ist da der Interrupt nicht immer gleich lang?   Mal ist er 120 
länger und mal nicht.

von ch. de (Gast)


Lesenswert?

sry,

ch. de schrieb:
> Warum ist da der Interrupt nicht immer gleich lang?   Mal ist er 120
> länger und mal nicht.
 Ich meinte warum kommg der Interrupt nicht immer zur gleichen Zeit? Mal 
120nS
 früher und mal nicht.

von (prx) A. K. (prx)


Lesenswert?

Mit exakt auf den Takt genau reproduzierbaren Interruptlatenzen kannst 
du bei keinem Controller rechnen. Taktgenau auf Ereignisse zu reagieren 
ist nicht das Wesen von Interrupts. Sowas geht i.d.R. nur, wenn der 
Controller explizit auf eine solche Fähigkeit dressiert worden ist 
(Propeller, XMOS, und dort sind es keine Interrupts).

Was hängt eigentlich an dem VGA-Ausgang dran?

von Ch D. (chrisu) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hi,
Mit meinem AVR hat es geklappt das Ich zumindest gerade Linien auf dem 
Bildschirm anzeigen konnte. Im Anhang habe ich mal ein Foto vom 
Bildschirm wenn die H sync Interupts verschoben sind(Er soll eigentlich 
gerade Linien anzeigen.) Man sieht ganz gut wie jede einzelne Linie 
entweder etwas füher oder später kommt.

A. K. schrieb:
> Was hängt eigentlich an dem VGA-Ausgang dran?

Der Bildschirm?!

von (prx) A. K. (prx)


Lesenswert?

Ch D. schrieb:

>> Was hängt eigentlich an dem VGA-Ausgang dran?
>
> Der Bildschirm?!

Sollte man kaum glauben, aber da gibt es doch wirklich ein paar 
technisch völlig verschiedene Typen von.

Dem Bild nach zu urteilen tatsächlich noch Röhre. Digital rasternde 
Geräte könnten sich anders verhalten.

Wenn es in bestimmten Umgebungen klappt, dann sei froh. Garantieren wird 
dir ein Controller-Hersteller normalerweise allenfalls eine worst case 
latency.

von Peter D. (peda)


Lesenswert?

Wenns beim AVR geklappt hat, kann das Main zufällig eine magische Zahl 
an Zyklen gedauert haben.

Ich fürchte, 32Bit Boliden sind für so ein feines Timing einfach nicht 
gedacht.

Vielleicht kennt die CPU ja Sleep-Modies, dann wird angehalten und auf 
nen Interrupt gewartet. Und dann sollte die Latenz gleich sein.


Peter

von DerElektrischeReiter (Gast)


Lesenswert?

Vorschlag:

0. Dein Interrupt muss der mit der höchsten Priorität sein, damit er 
nicht gestört wird.

1. Mache deinen Interrupt-Timer ein wenig kürzer, als die Zeit die du 
benötigst, damit die ISR auf keinen Fall zu spät gestartet wird.

2. In der ISR verheizt du die Takte, um auf die exakte Zeit zu kommen. 
Da ein Timer keine Takte verliert ist er dein Freund. Anschließen Timer 
reload (kann in diesem Fall auch konstant sein ;) ) und fertig.

cu

von Ch D. (chrisu) Benutzerseite


Lesenswert?

Hi,
0 check,
1 check
2 wie soll ich denn Wissen wie viele Takte ich verheizen soll, bzw wie 
weiss ich das ich die exakte Zeit erreicht habe? soll ich immer aus dem 
Timer register lesen und vergleichen oder wie?

von Ch D. (chrisu) Benutzerseite


Lesenswert?

ok, Ich habe es jetzt nochmal versucht ca 400 NOPs in das Hauptprogramm 
zu Packen. Man sieht auf dem Bildschirm einen deutlichen Unterschied. 
Ich denke mal es hat beim AVR so gut geklappt weil die allermeisten 
Befehle nur 1 Takt lang dauern.

von Ch D. (chrisu) Benutzerseite


Lesenswert?

Hi,
Freude: Es funktioniert nun Perfekt!
am anfang der ISR wird der Timerwert Geprüft und gewartet falls man die 
ISR früh ist.

start_pp:
  ldr r1, [r0] // Timerwert auslesen
  cmp r1, #20
  ldrlo pc, =start_pp // noch ein bisschen warten
  ldr r1, [r0]
  cmp r1, #26
  ldrhs pc,=end_pp
  nop // falls ein Takt Unterschied
  ldr pc, =end_pp

Danke für eure Hilfe!

von Ch D. (chrisu) Benutzerseite


Lesenswert?

> Freude: Es funktioniert nun Perfekt!


sorry wegen trippelpost aber es funktioniert auch nur wenn im 
MainProgramm nur eine while(1); Schleife steht.

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

Peter Dannegger schrieb:
> Ich fürchte, 32Bit Boliden sind für so ein feines Timing einfach nicht
> gedacht.

Warum?

--
Marcus

von Peter D. (peda)


Lesenswert?

Marcus Harnisch schrieb:
> Peter Dannegger schrieb:
>> Ich fürchte, 32Bit Boliden sind für so ein feines Timing einfach nicht
>> gedacht.
>
> Warum?

Durch die verschiedenen Cache-Mechanismen ist es sehr schwer, die 
Ausführungszeit von Instruktionen zu bestimmen.
Instruktionen können abhängig vom vorhergehenden Code und 
Speicherbereich (intern/extern, SRAM/Flash) unterschiedliche 
Ausführungszeit haben.

Beim AVR sind dagegen gleiche Befehle auch immer gleich lang.
Es gibt sogar ne Applikationsnote, wie man im Interrupt zyklusgenau was 
machen kann.


Peter

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

Peter Dannegger schrieb:
> Durch die verschiedenen Cache-Mechanismen ist es sehr schwer, die
> Ausführungszeit von Instruktionen zu bestimmen.

Richtig, aber beim ARM7 weniger relevant, da die entsprechenden µC
meist keine Caches haben. Allerdings muss man aufpassen, dass die
diversen "Flash Beschleuniger" der Hersteller letzlich auch eine Art
Cache darstellen.

Man kann Instruktionen in den Caches auch einsperren, was aber etwas
kompliziert ist.

Bei mittel-großen ARM Cores findet man deshalb auch die sogenannten
Tightly Coupled Memories mit deterministischer Zugriffzeit.

> Instruktionen können abhängig vom vorhergehenden Code und
> Speicherbereich (intern/extern, SRAM/Flash) unterschiedliche
> Ausführungszeit haben.

Man muss auf jeden Fall sicherstellen, dass der Code in einem Speicher
mit deterministischer Zugriffszeit liegt. Beim o.g. µC wäre das
interne RAM geeignet, vorausgesetzt der Zugriff wird nicht durch einen
anderen Master (DMA) ausgebremst. Der Flash Speicher garantiert single
cycle Zugriff bei 30MHz.

> Beim AVR sind dagegen gleiche Befehle auch immer gleich lang.

Beim ARM7TDMI üblicherweise auch, wenn man mal von der Multiplikation
(early termination) absieht. Das Problem sind eher die
nicht-unterbrechbaren Instruktionen, wie z.B. Multiplikation,
PUSH/POP. Wenn so einer gerade ausgeführt wird, muss der Interrupt
leider warten.

> Es gibt sogar ne Applikationsnote, wie man im Interrupt zyklusgenau
> was machen kann.

Das wird beim ARM7 in der Tat schwierig, aber keineswegs unmöglich.

--
Marcus

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.