Kleines externes Interrupt-Problem

**Siro** · 07.04.2019, 20:13

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** · 10.04.2019, 09:02

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** · 13.04.2019, 21:03

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** · 13.04.2019, 22:47

.. 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** · 14.04.2019, 11:32

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

**oberallgeier** · 14.04.2019, 12:55

Hallo Micha.

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

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

**hardware.bas** · 15.04.2019, 08:44

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