Kleines externes Interrupt-Problem

[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