Kleines externes Interrupt-Problem

[hardware.bas]

Hallo zusammen,
ich bin grad dabei diverse IR-Fernbedienungscodes auszuwerten.
Dazu nutze ich einen ATMEGA 162 und den Eingangspin für INT0.
Konfiguriert wurde der INT0 mit Rising, da ein 4093 Gatter als
Flankenversteiler vorgeschaltet ist und das IR-Empfängersignal
negiert. Auch oszilloskopisch sind die anliegenden Impulse korrekt.
Es soll ab der ersten ansteigenden Flanke des Impulspaketes ein
Interrupt ausgelöst werden und in der ISR die restlichen Impulse
am selben PIN ausgelesen werden. Deswegen ist der allererste
Befehl in der ISR die Interruptdeaktivierung. Die ISR dauert
länger als das IR-Impulspaket. Nach der ISR wird der Interrupt
wieder freigegeben, also da sind keine IR-Impulse mehr vorhanden.
Nun muss ich feststellen, dass die ISR nicht 1x, sondern 2x
ausgeführt wird. Für mich ist das zwar für mein Projekt nicht
unbedingt problematisch, aber komisch ist das doch.
Gibt da eventuell versteckte Timingprobleme?
VG Micha

[Holomino]

Mir liegt da irgendwie an, dass das Statusflag (das ist der Trigger für den Interrupt) beim Einsprung in den Interrupt gelöscht wird. Wenn während des ISR-Laufes das Statusflag wieder gesetzt wird, weil weitere Flanken den externen Port-Interrupt auslösen, löst das direkt nach dem Verlassen der ISR erneut einen Interrupt aus.

Abhilfe: Am Ende der ISR das Flag-Register zurücksetzen (Beim Mega168 heißt es, man soll das INTF0/1 im EIFR mit 1 beschreiben, um es zurückzusetzen. Musst Du mal schauen, ob das beim Mega162 auch so geht).

Komisch noch: Normalerweise setzen die Megas automatisch beim Einsprung in eine ISR ein "cli". Erst beim Verlassen geben die die Interrupts über "sei" wieder frei. Ist das beim Mega162 anders?

[Klebwax]

Hallo zusammen,
ich bin grad dabei diverse IR-Fernbedienungscodes auszuwerten. Dazu nutze ich einen ATMEGA 162 und den Eingangspin für INT0. Konfiguriert wurde der INT0 mit Rising, da ein 4093 Gatter als Flankenversteiler

Also ein Gatter mit Schmitt-Trigger Eingang wie auch den HC14. Den 4093 musste ich erstmal nachschlagen.

Es soll ab der ersten ansteigenden Flanke des Impulspaketes ein Interrupt ausgelöst werden und in der ISR die restlichen Impulse am selben PIN ausgelesen werden. Deswegen ist der allererste Befehl in der ISR die Interruptdeaktivierung.

Das ist nicht nötig und eher schädlich. Innerhalb eines Interrupts sind typisch die Interrupts gesperrt, mindestens aber der, in dessen Handler man gerade ist.

Die ISR dauert länger als das IR-Impulspaket. Nach der ISR wird der Interrupt wieder freigegeben

Das sollte man nie machen, dann kann ein neuer (oder auch der gleiche) Handler aufgerufen werden, bevor deiner ganz zuende ist. Mit etwas Pech passiert das mehrfach, bis der ganze Stack aufgeraucht ist. Ein Interrupthandler gibt mit dem letzten Befehl (Return From Interrupt) die Interrupte wieder frei, so wie sie beim Eintritt gesperrt werden.

,. also da sind keine IR-Impulse mehr vorhanden. Nun muss ich feststellen, dass die ISR nicht 1x, sondern 2x ausgeführt wird. Für mich ist das zwar für mein Projekt nicht unbedingt problematisch, aber komisch ist das doch. Gibt da eventuell versteckte Timingprobleme?

Es ist kein Timingproblem. Der Interruptpin oder ein Interruptereignis löst nicht den Sprung in den Interrupthandler aus, sonder setzt ein Interruptflag. Immer, also unabhängig davon, ob die Interrupte enabled oder disabled sind. Ein gesetztes Flag bei freigegebenen Interrupten löst dann den Handler aus. Bei manchen Interruptquellen wird diese Flag durch einen Automatismus gelöscht, bei anderen muß es explizit gelöscht werden (Datenblatt). Lösche also dieses Flag und alles ist in Ordnung.

MfG Klebwax

[wkrug]

Ich würde die Routine ohnehin anders aufbauen.

1. Einen der internen Timer als Zeitbasis aktivieren.

2. Je nach IR Code kann man den Interrupt bei jeder Flanke, oder nur bei steigender oder fallender Flanke des Signals auslösen.
( Interrupt Sensing in der Interrupt Routine umschalten, oder Pin Change Interrupts verwenden ).
( Auch der ICP des Timers könnte genutzt werden ! ).

3. Der Timer wird bei jedem Interrupt Ereignis ausgelesen und zurück gesetzt. Dadurch bekommt man eine Timing Information über das ankommende Signal, das man auswerten kann. Und in ensprechende Befehle, Bits oder sonstwas umsetzen kann.

4. Am Ende der Impulskette wird ein Flag gesetzt, das dem Hauptprogramm mitteilt, das eine komplette Impulskette empfangen wurde.

5. Bei dem Verwendeten Timer kann man einen Comparematch Interrupt mit CTC setzen um unvollständige Codes zu erkennen und diesen String dann zu verwerfen. ( Zählregister und Pointer für den Empfang zurück setzten ).

6. Die komplette Abarbeitung eines empfangenen Strings findet in der Hauptroutine statt. Nach der Verarbeitung wird dann das Flag für einen komplett Empfangenen IR Code gelöscht, damit das System für den nächsten String wieder "scharf" ist.

Es gibt sicher auch andere Methoden um so etwas zu lösen, allerdings ist es schon so wie oben Beschrieben wurde.
Bei einem aktiven Interrupt sind alle!!! anderen Interrupts gesperrt.
Die entsprechenden Flags werden aber dennoch gesetzt.
Das bedeutet, das dann alle freigegebenen und anstehenden Interrupts nach Beendigung einer Interruptroutine nach Ihrer Priorität nacheinander ausgeführt werden.
Es gilt also nach wie vor die Anweisung Interrupt Routinen so kurz wie möglich zu halten!
Komplette Abfragen in einen einzigen Interrupt zu packen erscheint zwar einfach, ist aber keine gute Idee.

[hardware.bas]

Erstmal vielen Dank für die konstruktiven Antworten,

das Problem ist gelöst, ich habe am Anfang der ISR die Deaktivierung
des Interrupts entfernt. Gegen Ende der ISR habe ich GIFR.6 = 1
eingefügt und damit die INT0-Anforderung gelöscht.
Die Test-ISR läuft jetzt nur einmalig, wie gewünscht.

Ob bei eingeschalteten INT0-Interrupt der PIN sich noch pollen lässt,
muss ich noch ausprobieren, jedoch bin auch ich der Meinung, dass
Interuptroutinen kurz sein sollten, darum steht noch Finetuning an.

Der IR-Empfänger wird übrigens über einen RC-Tiepass mit Ub versorgt,
um die Störsicherheit zu erhöhen, deshalb ist ein 4093-Gatter
nachgeschaltet. Um die Frage zu beantworten; der 4093 ist ein
4-fach CMOS-NAND-Gatter, dessen Eingänge Schmitt-Trigger-
Eigenschaften hat, übrigens ein sehr universell verwendbarer IC.

VG Micha

[Siro]

Hallo, Micha,

ich hab so etwas über ein "Capture" gemacht.
Ein Timer läuft kontinuierlich (Free Running Mode) und läuft immer wieder über.
Es wird der Capture Mode so eingestellt, dass er auf positive und negative Flanken reagiert.
Ein Interrupt "Flanke" speichert dann "automatisch" den momentanen Timerwert in einem 16 Bit Register.
Das passiert im Controller komplett in Hardware.
Im Interrupt selbst wird nur der Wert ausgelesen und der vorige Wert abgezogen.
Wirds negativ, weil der Timer überläuft, dreht man einfach das Vorzeichen vom Ergebnis um.
Den Timer fässt man nicht mehr an, den lässt man einfach weiterlaufen.
So kann man sehr präzise Impulse messen.
Man zählt quasi die Taktzyklen des Timers und das ist Quarzgenau, deshalb darf man den Timer auch nicht anhalten
oder zurück setzen.

Ich hab auch Versuche mit 2 Eingängen gemacht, wobei einer nur auf negative, der andere nur auf positive Flanken reagiert.
Eventuell kann man im Interrupt die Pausenlänge auswerten um festzustellen ob alles Übertragen wurde, also eine komplette Impulskette.
Die einzelnen Werte landen bei mir in eimen kleinen Zwischenspeicher (Ringspeicher) das mache ich im Interrupt, das geht ja fix.
Die eigentliche Auswertung mach ich dann im Hauptprogramm.

Es gibt, wie ich grad im Datenblatt sehe, in dem ATMega 162 sogar einen "Input Capture Noise Canceler"

The Noise Canceler improves noise immunity by using a simple digital filtering scheme. The
Noise Canceler input is monitored over four samples, and all four must be equal for changing the
output that in turn is used by the edge detector.

Vorsicht ist geboten beim Auslesen des 16 Bit Timerwertes,
hier muss man dann zuerst das Low Byte lesen, das High Byte wird dann ins temporäre Register übernommen
Siehe Datenblatt: "Accessing 16-bit Registers"

Viele Wege führen zum Ziel, das soll nur als Anregung dienen.

Siro

[hardware.bas]

Hallo, zusammen,
eine weitere Frage konnte geklärt werden
und ist sicherlich auch für andere Projekte
von allgemeinem Interesse;
Trotz "scharfgeschalteten" PIND.2 beim
ATMEGA162 als INT0 - RISING kann dieser
problemlos konventionell abgefragt, also
auch gepollt werden.
Bei mir geschieht das allerdings innerhalb
der betreffenden ISR.
VG Micha

[hardware.bas]

Hallo, zusammen,
auch wenns jetzt etwas optopic wird, ich konnte oszilloskopisch
alle mir zur Verfügung stehenden (alte und aktuelle) IR-Fernbedienungen
hardwaremässig auslesen. Eine Ähnlichkeit mit dem allgemein im Netz
veröffentlichen RC5-Code war nicht zu erkennen, allerdings wurden die
Impulse exakt dargestellt.
Der nächste Schritt war das softwaremässige Pollen innerhalb der ISR
mit ca 10kHz, um die softwaremässige Auswertung vorzubereiten zu
können. Das Ergebniss war ein sichtbar gleiches Oszi-Ergebniss.
Danach wurden in der AVR-Mutterschaltung diverse "Pollingfenster"
programmiert, um festzustellen, welche Impulspakete den Tasten:
0-9, bzw OFF oder Pfeiltasten entsprechen könnten.
Eine diesbezügliche Logik konnte nicht festgestellt werden.
Als FB nutze (oder versuche) ich die RCA RC2070U.
Vielleicht hat da jemand eine Idee.
VG Micha

[oberallgeier]

.. konnte oszilloskopisch alle mir zur Verfügung stehenden (alte und aktuelle) IR-Fernbedienungen hardwaremässig auslesen. Eine Ähnlichkeit mit dem allgemein im Netz veröffentlichen RC5-Code war nicht zu erkennen ..

Kann denn die umfangreiche Sammlung von San Bergmans da nicht helfen, auf die ich Dich schon mitte Februar hingewiesen hatte ? Vierzehn (14) verschiedene IR-Codes sind ja nu auch nicht grad wenig *gg*.

Na ja, mir kommt ja z.B. das Philips RECS-80 Protocol ziemlich schwer zu lesen vor. Aber das (mir bekannte) RCA Protocol ist ja auch nicht ohne . . . Und eine ordentliche Systematik für die Fernsteuercodes ist bei diesen Tastengräbern aber auch nicht oft zu finden . . .

......Bild hier  
......© 2019 oberallgeier - IR-Fernsteuerung + Tastencodes

[hardware.bas]

Hallo, Oberallgeier,

sorry, ich hatte Deinen Hinweis damals kurz angeklickt,
bin jedoch, weil was dazwischen kam, nicht detailliert
weitergekommen. Das dargestellte Impulspaket scheint
meinem Oszillogramm zu entsprechen.
Erstaunlich, dass trotz geschilderter 56kHz-Modulation
mein 36kHz-Empfänger ziemlich gut funktioniert.
Ich müsste das Ganze jetzt mit einer Timerabfrage
lösen können. Vielen Dank

VG Micha