|
Anzeige
|
Capture Interrupt und Timer overflow
Gast
#594913
Hallo zusammen Hat jemand eine Idee, wie man das Problem von zwei gleichzeitig auftretenden Interrupts (Capture Interrupt und Timer overflow in meinem Fall) beheben kann? Kennt vielleicht jemand ein Paper, in welchem das beschrieben ist? Danke schon mal für eure Hilfe Gruss F.Stadler Wenn ein Interrupt aufgerufen wird, wird das Globale Interrupt Flag zurückgesetzt und erst nach RETI wieder gesetzt. Wenn Du in Deiner Interrupt-Service-Routine das Flag manuell löschst, gibst Du damit andere Interrupts wieder frei. Wirklich gleichzeitig ist das natürlich nicht, da der Interrupt bis zum CLI exklusiv läuft. Aber andere Interrupts werden gespeichert. Wo steht das: z.B. Manual mega88 Seite 15 (glaub ich) Analog Designer wrote: > Hallo zusammen > > Hat jemand eine Idee, wie man das Problem von zwei gleichzeitig > auftretenden Interrupts (Capture Interrupt und Timer overflow in meinem > Fall) beheben kann? Welches Problem? Das Problem, dass beide Interruprs fast gleichzeitig auftreten und sich gegenseitig behindern? - Dagegen hilft nur, die ISRs möglichst kurz zu machen, so dass die Verzögerungszeiten gering bleiben. Das erreicht man, indem man längere Routinen aus der ISR in die Mainloop verlagert und per Semaphore aufruft. Oder das Problem, dass sich die beiden (oder 3, denn meist gibt es 2 OC-Ints) gegenseitig den Timerstand unterm Hintern verstellen? - Dagegen hilft saubere Programmierung, bei der keiner der Interrupts den Timerstand verändern darf. Die OC-Interrupts lesen ihr OC-Register ein, addieren das Intervall darauf und schreiben es als nächsten Int-Termin ins OCR zurück. Die ICP-Routine merkt sich den ICR-Wert (Zeitstempel) der jeweils "letzten Runde" und bildet die Differenz aus aktuellem Zeitstempel und dem vorherigen. Auch hierbei ist es nich nötig, den Timer zu Beginn des zu messenden Impulses auf 0 zu setzen. > Kennt vielleicht jemand ein Paper, in welchem das > beschrieben ist? Nicht alles, was man im Laufe der Zeit durch "Erfahrung" gelernt hat, gibt es gefiltert und mundgerecht als "Paper". > > > Danke schon mal für eure Hilfe > > Gruss > F.Stadler ...
Gast
#595030
Im Falle eines AVR ist es ganz einfach: Die Interrupts unterbrechen sich nicht gegenseitig. Der Capture-Wert wird solange nicht verändert, bis eine (vorher eingegstellte) Flanke erneut auftritt: ISR möglichst kurz halten, wie Hannes schon schrieb. Bei anderen Controllern kann man u.U. Interruptprioritäten vergeben.
Gast
#595195
> Bei anderen Controllern kann man u.U. Interruptprioritäten vergeben. Was passiert denn, wenn 1 Interrupt am abarbeiten ist und ein 2., allenfalls mit höherer Priorität, während dieser Zeit auftritt? Genau dies ist nämlich das Problem bei meiner Software. @ Hannes Lux > Nicht alles, was man im Laufe der Zeit durch "Erfahrung" gelernt hat, gibt es gefiltert und mundgerecht als "Paper". Im Internet ist viel mehr zu finden, als man manchmal denkt... vor allem die Hersteller sind interessiert, dem Kunden den Einstieg und die Arbeit mit ihrem uP möglichst stark zu vereinfachen. Gruss Analog Designer wrote: > Was passiert denn, wenn 1 Interrupt am abarbeiten ist und ein 2., > allenfalls mit höherer Priorität, während dieser Zeit auftritt? Genau > dies ist nämlich das Problem bei meiner Software. Das kommt auf den Controller-Typ an, den Du uns penetrant verschweigst, da gibt es keine allgemeingültige Aussage. Du musst da schon das betreffende Datenblatt befragen. > Im Internet ist viel mehr zu finden, als man manchmal denkt... Stimmt... Im Internet ist über 95% Schrott zu finden. > vor allem > die Hersteller sind interessiert, dem Kunden den Einstieg und die Arbeit > mit ihrem uP möglichst stark zu vereinfachen. Dafür haben einige Hersteller ganz brauchbare kostenlose Datenblätter und AppNotes, andere Hersteller rücken ihre Informationen nur gegen horrende Mitgliedsbeiträge in Organisationen raus. ... Ich bin dafür, dass hier die Autorensuche eingeführt wird. Ich weiss, dass PeDa da in der Codesammlung mal darüber gesprochen hat, ich finde aber den Artikel nicht mehr.
Gast
#595238
Hier drin gibt es anscheindend Leute, die nicht wissen 1. keine Ahnung von Programmierung (-> Amateure) haben und 2. sich des Sinn und Zwecks eines Forums nicht bewusst sind! Thread geschlossen, denn es gibt Foren in denen man kompetente Antworten erhält
Gast
#595257
Wie heißt das Forum, in dem man nur kompetente Antworten erhält? @Analog-Designer: Mach´s gut! Nett, Dich nicht weiter gekannt zu haben. Analog Designer wrote: > Hier drin gibt es anscheindend Leute, die nicht wissen 1. keine Ahnung > von Programmierung (-> Amateure) haben und 2. sich des Sinn und Zwecks > eines Forums nicht bewusst sind! Entschuldege bitte, dass ich Dir helfen wollte und versucht habe, Deine unpräzisen Fragen präzise zu beantworten. > > Thread geschlossen, Ich vermute mal, dass Du nicht Derjenige bist, der hier einen Thread schließt... > denn es gibt Foren in denen man kompetente Antworten > erhält Viel Erfolg... ... Es wäre wirklich interessant zu wissen, um welchen Controller es sich handelt...
Gast
#595342
Es handelt sich um den MSP430
Gast
#595431
Du verwendest also den MSP430... gäbe es nicht die Möglichkeit, den Zählerstand des Timers abzufragen bei einem capture event, damit du feststellen kannst, wenn ein overflow des Timers kurze Zeit später passieren kann bzw. schon passiert ist? Meiner Meinung nach ist dies ein bekanntes Problem, das bei priorisierten Interrupts halt einfach auftreten kann. Eine andere Möglichkeit wäre, die Interrupts entsprechend zu maskieren, habe ich selber aber auch zu wenig Erfahrung. Evtl. kann hier ein erfahrender Programmierer weiterhelfen...? Ich hoffe, dies hilft dir weiter. Gruss Matthias Ich vermute mal, der Frager meinte folgendes: Man will einen Timestamp einer Flanke haben mit mehr als 16Bit und hat dazu im Overflowinterrupt einen weiteren Softwarezähler. Wenn nun der Overflowinterrupt und der Captureinterrupt zeitnah auftreten, weiß man ja nicht, ob das Capture vor oder nach dem Overflow eintrat. Das Problem ist das gleiche, wie bei meinem 32Bit Zählerbeispiel und die Lösung ist es daher auch: Beitrag "AVR Timer mit 32 Bit" Peter
Gast
#595547
Danke Peter, genau so eine Erklärung habe ich gesucht. Und dann noch mit Code-Beispiel... genial! Analog Designer wrote: > Hier drin gibt es anscheindend Leute, die nicht wissen 1. keine Ahnung > von Programmierung (-> Amateure) haben und 2. sich des Sinn und Zwecks > eines Forums nicht bewusst sind! > > Thread geschlossen, denn es gibt Foren in denen man kompetente Antworten > erhält Gibt es eigentlich auch ein Forum, in dem nur kompetente Fragen gestellt werden ?
Gast
#595719
So inkompetent kann die Frage ja nicht gewesen sein, wenn sie nur 2 beantworten können...
Gast
#595730
Hallo, seine Frage war nicht inkompetent, sie war unpräzise und ließ die Leute raten... Das Interruptverhalten von µC ist nicht allgemeingültig, sondern hängt von der µC-Familie ab, die er erst später verraten hat. Der Fall, den er offenbar gemeint hat, tritt in dieser Form auf, wenn man Capture und Overflow des gleichen Counters per IRQ auswertet, das hat er so auch nicht verraten. Viele übersehen beim Fragen im Forum, daß ja nur sie in diesem Moment das Programm, die Abläufe, die Hardware und was noch eine Rolle spielen kann, kennen und die Leser mit dem auskommen müssen, was gepostet wird. Je weniger Info kommt, um so mehr muß spekuliert werden, um so geringer sind die Chancen, eine tatsächlich hilfreiche Antwort zu bekommen. Zumindest hat es mich jetzt daran erinnert, daß ich das in meinem Multimeter auch noch nicht korrigiert habe... :( Gruß aus Berlin Michael Eigentlich hat mich die patzige Art gestört, wie er reagiert hat. Das fand ich reichlich daneben und darauf bezog sich mein Beitrag. Antwort schreiben |
Anzeige
|
