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.
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
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.
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.
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?
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?!
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.
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
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
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?
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.
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!
> Freude: Es funktioniert nun Perfekt!
sorry wegen trippelpost aber es funktioniert auch nur wenn im
MainProgramm nur eine while(1); Schleife steht.
Peter Dannegger schrieb: > Ich fürchte, 32Bit Boliden sind für so ein feines Timing einfach nicht > gedacht. Warum? -- Marcus
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.