-         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 18

Thema: Kleines externes Interrupt-Problem

  1. #1
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.10.2008
    Ort
    Sandfurth
    Beiträge
    1.138

    Kleines externes Interrupt-Problem

    Anzeige

    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
    Was brauche ich für Werkzeug - in dieser Reihenfolge seht ihr es:
    Vorschlaghammer, Notebook, BASCOM, Lötequipment, Rohrzange, Bolzenschneider ...

  2. #2
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    07.04.2015
    Beiträge
    411
    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?

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.649
    Zitat Zitat von hardware.bas Beitrag anzeigen
    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
    Strom fließt auch durch krumme Drähte !

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    2.040
    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.

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.10.2008
    Ort
    Sandfurth
    Beiträge
    1.138
    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
    Was brauche ich für Werkzeug - in dieser Reihenfolge seht ihr es:
    Vorschlaghammer, Notebook, BASCOM, Lötequipment, Rohrzange, Bolzenschneider ...

  6. #6
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Ort
    Berlin
    Beiträge
    895
    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
    Geändert von Siro (07.04.2019 um 20:19 Uhr)

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.10.2008
    Ort
    Sandfurth
    Beiträge
    1.138
    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
    Was brauche ich für Werkzeug - in dieser Reihenfolge seht ihr es:
    Vorschlaghammer, Notebook, BASCOM, Lötequipment, Rohrzange, Bolzenschneider ...

  8. #8
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.10.2008
    Ort
    Sandfurth
    Beiträge
    1.138
    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
    Was brauche ich für Werkzeug - in dieser Reihenfolge seht ihr es:
    Vorschlaghammer, Notebook, BASCOM, Lötequipment, Rohrzange, Bolzenschneider ...

  9. #9
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    7.950
    .. 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 . . .

    ......
    ......© 2019 oberallgeier
    Geändert von oberallgeier (13.04.2019 um 23:10 Uhr)
    Ciao sagt der JoeamBerg

  10. #10
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.10.2008
    Ort
    Sandfurth
    Beiträge
    1.138
    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
    Was brauche ich für Werkzeug - in dieser Reihenfolge seht ihr es:
    Vorschlaghammer, Notebook, BASCOM, Lötequipment, Rohrzange, Bolzenschneider ...

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Kleines Problem mit Assembler
    Von Destroyer im Forum PIC Controller
    Antworten: 5
    Letzter Beitrag: 25.11.2014, 17:28
  2. kleines mathematisches Problem
    Von Felix G im Forum Software, Algorithmen und KI
    Antworten: 7
    Letzter Beitrag: 17.10.2006, 08:58
  3. Kleines Problem mit Motor
    Von cb01 im Forum Mechanik
    Antworten: 10
    Letzter Beitrag: 31.07.2006, 16:47
  4. Kleines I/O-Problem
    Von RCO im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 9
    Letzter Beitrag: 08.11.2004, 20:43
  5. Kleines Problem mit der Fernsteuerung
    Von Maro im Forum Robby CCRP5
    Antworten: 9
    Letzter Beitrag: 15.08.2004, 16:35

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •