Kleines externes Interrupt-Problem

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

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?

Zitat:

---

Zitat von 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

---

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

Zitat:

---

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.

Zitat:

---

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.

Zitat:

---

,. 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

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.

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

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

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

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

Zitat:

---

.. 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

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

Hallo Micha.

Zitat:

---

.. kurz angeklickt .. weil was dazwischen kam, nicht detailliert weitergekommen ..

---

Schon gut, kennt man ja unter ".. aus den Augen, aus dem Sinn ..". Kommt bei mir ziemlich oft vor :-/

Hübsch wärs ja, wenn Du dazu ´n Bildchen reinstellen könntest. Ich bin grad dabei meine RC5-3-Routine zu optimieren (RC5-3 : drei Ziffern in RC-5 für EINEN auswertbaren Befehl per Interrupt einlesen und global zur Verarbeitung verfügbar halten - also nicht pollen. Ziel: Tasksteuerung für archie nach dem Schema, das jeder käufliche Fernseher für Programmauswahl und Videotext beherrscht) , z.B. das Togglebit auswerten etc. Da kann man z.B. halbwegs ordentlich die Pulslänge sehen

......Bild hier  
......© 2019 oberallgeier

wobei die 831 µs der Messung zeigen, dass die Fernsteuerung eben nicht korrekt tickert. Für RC-5-Manchester-Signale sind dafür ja 889 µs vorgeschrieben. Na ja, es ist eben nix perfekt, funktionieren tuts trotzdem.

Code:

---

// ============================================================================= =
/*  25. Nov. 2018, 11h00      Zeiten etc zu Manchester-Codierung
        Bitdauer 2x889 µs (2*17,78 tupsi) => 1,778 ms/35,56 tupsi [tp]
        Für den logischen Wert des Bits ist Übergang in Bitmitte massgebend
  Im Folgenden die Zeitwerte in µs (oben) und Zeitwerte in tupsi (unten):
  0    889  1778  1778  2667  3556  -  -  µs
  0    >17    >35  >36    >53    >71  -  -  tupsi
  |            |    |            |
  +------+      |    |      +------+
  |HHHHHH|      |    |      |HHHHHH| 
  |HHHHHH+------+    +------+HHHHHH|  ==> Übergang von 1 nach Null <=> Bitwert 0
  |  Logic 0  |    |  Logic 1  |  ==> Übergang von 0 nach 1    <=> Bitwert 1

== =============================================================================*/
Anm.: "tupsi" ist (m)eine controlerinterne Zeiteinheit - t ime u nit p er s ensor i nterrupt

---

Zitat:

---

.. dass trotz geschilderter 56kHz-Modulation mein 36kHz-Empfänger ziemlich gut funktioniert ..

---

Ja das geht, allerdings hatte ich vor längerer Zeit mal festgestellt, dass der erreichbare Abstand Fernsteuerung <-> Empfänger ziemlich schrumpft bei abweichenden (Sende-) Frequenzen - aber auch bei abweichender Empfängerfrequenz.

Nochmals Danke für das Feedback,

ich konnte die für mich interessanten BITs eindeutig lokalisieren.
Das sind jeweils die letzten 4 der 12 gesamten ersten Hälfte,
diese werde ich nur nutzen und entsprechend die letzten
4 der letzten 12 negierten.

Ich kann jetzt alle Ziffern, 4 Pfeiltasten und OFF damit eindeutig
übertragen. Die FB soll lediglich als alternative Eingabe für
einen experimentellen SDR-Empfänger ohne extreme Reichweite
dienen. Das krieg ich nun hin.

Zum eigentlichen Thema Interrupt:
In der gesamten ISR wird nunmehr der Tastendruck decodiert
und als halbes Byte (mehr brauch ich ja nicht) der Hauptroutine
übergeben. Dort wird dann die Anzeige gemanagt und die
Daten für Downmischer, Preselector, RS232-Senden etc generiert.
Eine weitere ISR gibt es dann noch für den RS232-Empfang.

Die zuerst genannte ISR wird nun sicherlich einigen Mitlesern
sehr lang erscheinen, bedenken sollte man jedoch, dass der
genutzte ATmega162 ausser den genannten Aufgaben nichts
weiteres mehr zu tun hat. Er wurde letztendlich nur eingesetzt,
wegen der 35 I/O-PINSs beim DIL-Gehäuse.

VG Micha

Hallo Micha,

freut mich wenn ich helfen konnte.

Zitat:

---

.. ich konnte die für mich interessanten BITs eindeutig lokalisieren. Das sind jeweils die letzten 4 der 12 gesamten ersten Hälfte ..

---

Klar, es ist ja "vorne" nur "overhead" : 2 Startbits, ein Togglebit (SEHR praktisch gegen Prellen, langen Tastendruck - dann repetierts etliche Male pro Sekunde etc) und fünf Adressbits. Die Adressbits sind bei meiner (billigen) Fernsteuerung von nem alten Fernseher sowieso alle Null . . .

......Bild hier  
......©opiert aus San Bergmans Sammlung; Informationen zu RC-5 (im Bild verlinkt)

SDR . . . hmmm, finde ich interessant. Als Nicht-Funker (die Prüfung ist halt s..schwer) sind aber sicher die interessanten Möglichkeiten tabu.

Hallo, Oberallgeier,

ohne Deine Hinweise hätte ich mir warscheinlich "einen abgebrochen".

Zum Thema SDR; auch ich habe keine Funklizenz, will ja auch nur
empfangen. Bei meinem Projekt ist vorwiegend der Weg das Ziel.
Dazu nutze ich teilweise Lösungen, wo richtige Funkfreaks sicherlich
schmunzeln werden, jedoch will ich mich, auch für andere Projekte
etwas selber trainieren;
- kein bequemer DDS, sondern voreinstellbarer Frequenzteiler
- obwohl simultane 7-stellige 7-Segmentanzeige, wird eine sequentielle
Ansteuerung unter Nutzung der Speicher der 4511-Decoder genutzt
- Wiederbeschäftigung mit HF-Technik
- Optoelektronik puristisch anwenden
- "durchblickbares" UART-Protokoll anwenden
- Kommunikation zwischen den Baugruppen ausschliesslich mit Hardware
- Programmiertraining (bei mir ist es BASCOM)
- mechatronischer Preselector mit Luftdrehko und Steppermotor
- hardwaremässig angebundenes LED-Signalmonitoring
- viele Messpunkte auf den Platinen
- Nutzung versilberter Lochrasterplatinen 100x160
War zwar wieder mal Off-Topic.
Das Projekt dient jedoch vorwiegend Übungszwecken

VG Micha
-

Kurz zum Stand der Dinge:

Die Dekodierung der einzelnen Ziffern und einiger Funktionen
hat geklappt, allerdings muss man mehrere Sekunden dauernd
an der IR-FB drücken, um sicher zu sein, dass die Dekodierung
korrekt erfolgt. Könnte ich grade so akzetieren, da die IR-Eingabe
nur für die Verwendung an Rechnern ohne RS232 gedacht ist.

Die Einzeleingabe der Ziffern mit gleichzeitigen Linksruck konnte
mit einem Testprogramm erfolgreich simuliert werden.

Die Kombination des Ganzen hat jedoch dazu geführt, dass das
bisherige Gesamtprogramm nicht mehr nachvollziehbar ist und
daher auch nicht funktioniert.

Ich werde daher nur noch IR-Streams aller Tasten aller FB
uncodiert als Tipptasten auswerten, nach dem Motto:
kurz Tippen, bis Digit passt, nach mässiger Pause das
nächste Digit, nach langer Pause dann Eingabeende.

Der Programmierstress ist mir jetzt zu viel, ich muss
jetzt hardwaremässig weiterkommen und die UART-
Kommunikation funktioniert eh berfekt.

VG Micha

Ich werde mir daher nicht weiter den Stress antun
ist.

Zitat:

---

.. Ich werde daher nur noch IR-Streams aller Tasten aller FB uncodiert als Tipptasten auswerten ..

---

Gut so. Das klappt bei mir öfters - ich nutze teilweise so ein unspezifisches Signalbündel aus um einen Task zu starten. Si ist Dein lang-kurz-Code sozusagen nix anderes als ne Art Morsen.

Due komfortable Decodierung in Verbindung mit
der Funktion ist ja noch nicht vom Tisch,
Kommt vielleicht später.

Jedoch will ich mich erstmal nicht noch weiter
verennen sondern mal wieder zum Lütkolben greifen.

Eine Art Morsen ist es nicht, jedoch ist eine ziemlich
komfortable Eintastenbedienung rausgekommen,
welche mit allen FB funktioniert.

Kurze Tastendrücke ermöglichen ein feinfühliges Tuning
in eine Richtung. Längeres Tastendrücken erhöhen die
Tuninggeschwindigkeit weiter.
Etwas längere Tastenpausen kehren den Tuningvorgang
um. Dadurch ist eine quasi 8-stellige Frequenzeingabe
sowohl feinfühlig als auch schnell realisiert.

Kann ich ganz gut mit leben.
Allerdings ist das Thema jetzt etwas offtopic geworden.

VG Micha

Hallo Micha

das ist doch wirklich eine tricky Idee - die ich bisher in dieser Art und mit diesen Möglichkeiten nicht kannte.

Zitat:

---

.. Eine Art Morsen ist es nicht, jedoch .. eine ziemlich komfortable Eintastenbedienung .. jetzt etwas offtopic ..

---

Manchmal entwickelt sich da etwas in nem Thread - und wenn das so kreativ wird, dann stört off topic nicht wirklich.

PS: Sandfurth zwischen MD und SDL?