-
        

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 13

Thema: ATmega8 ext. Interrupt

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    16.04.2011
    Beiträge
    78

    ATmega8 ext. Interrupt

    Anzeige

    Hallo liebe Gemeinde,

    es handelt sich um ein Problem bei der Tasterabfrage per Interrupt. Ich möchte einen Tasterzustand auf INT1 abfragen und auf low level triggern.
    Hier der grundsätzliche Programmaufbau, mal eben eingetippt:

    Code:
    ISR(INT1_vect) {...}
    
    int main (void)
    {
    DDRD = 0xF7;              // PD3 als Eingang definiert
    PORTD |= (1<<PD3);     // Pullups aktiviert
    ...
    MCUCR &= ~((1<<ISC11)|(1<<ISC10);     // auf low-level Zustand getriggert
    GICR |= (1<<INT1);                              // INT1 aktiviert
    
    sei();
    
    while(1) {...}
    ...
    }
    Nach meinem Verständnis sollte doch, solange der low level- Zustand am Taster herrscht (und der herrscht immer, wenn der Taster nicht gedrückt ist) ständig der INterrupt ausgelöst werden und somit nur die ISR ausgeführt werden?
    Der Taster ist per Tiefpass entprellt und wechselt von HIGH auf LOW und umgekehrt in 500ns.

    Der eigentlich Fehler ist, dass der ext. Interrupt nie durchgeführt wird und ich nicht weiß, woran es noch liegen könnte.

    Ich verwende neben der Funktion auch die beiden Timer, deshalb dachte ich erstmal, dass es an dem im Kap."Errata" aufgeführten bug liegt...


    Grüße,
    Nik
    Geändert von Liquidator (08.05.2015 um 12:06 Uhr)

  2. #2
    Erfahrener Benutzer Roboter-Spezialist Avatar von sast
    Registriert seit
    30.11.2004
    Alter
    47
    Beiträge
    497
    Woher weißt du ob der Interrupt auslöst? Wenn der Taster im nicht geschalteten Zustand auf Low liegt, muss es ein Öffner sein, der an Masse angeschlossen ist. Ansonsten hast du vielleicht ein Verständnisproblem. Taster ist geöffnet bedeutet durch den Pullup ja, dass der Eingang PD3 auf High liegt und nur wenn du über einen gegen Masse schaltenden Taster den Eingang auf Low ziehst, kommt es zu einer Änderung des Eingangspegels. Hast du eventuell den Taster gegen +UB verschaltet? Dann kannst du nämlich lange drücken bzw nicht drücken. Am Eingang wäre dann immer High Pegel.

    sast

    雅思特史特芬
    开发及研究

  3. #3
    Benutzer Stammmitglied
    Registriert seit
    16.04.2011
    Beiträge
    78
    Danke für die Antwort sast,

    ich habe beide Tastervarianten ausprobiert (gegen Masse, gegen 5V) und der vorliegende Code war für die Variante für einen auf GND schaltenden Taster. Dass der Interrupt nicht ausgeführt wird, erkenne ich daran, dass die testweise in ISR(INT1_vect) eingebaute Verzögerung delay_ms(10000) nicht ausgeführt wird und das in main() befindende Programm abläuft.

    Ich habe das Bild am Mikrocontroller-Eingang oszillographiert und lade das mal mit hoch.

    Klicke auf die Grafik für eine größere Ansicht

Name:	taster_nach_tiefpass.png
Hits:	17
Größe:	24,5 KB
ID:	30137

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von 021aet04
    Registriert seit
    17.01.2005
    Ort
    Niklasdorf
    Alter
    29
    Beiträge
    4.544
    Hast du schon versucht den INT umzustellen (auf z.b. Falling)?

    MfG Hannes

  5. #5
    Benutzer Stammmitglied
    Registriert seit
    16.04.2011
    Beiträge
    78
    Hallo Hannes,

    funktionieren tut leider keins davon. Morgen werde ich mal einzelne Prozeduren ausschalten und feststellen, mit welchem Prozess der externe Interrupt in Konflikt kommt. Was ich allerdings nicht verstehe ist: Der INT0/1 hat doch (außer RESET) die höchste Priorität laut der Interruptvektorliste im Datenblatt. Also müsste sich doch eigentlich genau dieser Interrupt durchsetzen?

    Grüße,
    Nik

  6. #6
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    7.554
    ... funktionieren tut leider keins ... einzelne Prozeduren ausschalten und feststellen ... externe Interrupt in Konflikt kommt ...
    Hallo Nik, vor Jahren hatte ich mal unglaublich zähe Probleme mit Interrupts. Abhilfe schaffte ich mit einem kompletten Satz ISRs - für jeden Vektor nach dem Muster
    Code:
    // ===  Nicht unterbrechbare ISR für Vektor "EINERNACHDEMANDERN"
     ISR(EINERNACHDEMANDERN)        // Vektor ij,
     {                             //
       return;                       //
     }                      // Ende ISR(EINERNACHDEMANDERN)
    // ============================================================================= =
    Wenn ich mich richtig erinnere, war das schon mal die halbe Miete. Dann wurden die ISR der Reihe nach mit einem Toggel-Bit zu einer LED versehen. Damit (und mit nem Oszilloskop) war der Schuldige schnell identifizierbar.

    ... nicht verstehe ist: Der INT0/1 ... höchste Priorität ... Also müsste sich doch ... genau dieser Interrupt durchsetzen ...
    Jein. Im Prinzip und theoretisch hast Du völlig Recht. Aber höchste Priorität heißt nicht, dass er - ohne besondere Softwareverfahren - sonstige InterruptServiceRoutinen unterbrechen kann. Das ist per default unterbunden, kann aber durch eine Interruptfreigabe innerhalb einer ISR ermöglicht werden; Ergebnis sind dann sogenannte nested Interrupts. Nested Interrupts sind aber oft ne äusserst hinterhältige Erfindung (ich hab einen mit bester Funktion am Laufen). Langer Rede kurzer Sinn: Wenn eine ISR gerade läuft - ohne dem nested-Trick - hat selbst eine höher priorisierter Interrupt keine Aktien zu einer Unterbrechung.

    Und um die lange Post noch länger zu machen: üblicherweise habe ich an meinem Codeanfang, direkt nach den Portdefinitionen und noch vor jeglicher anderen Aktion eine Routine um "irgendwelche" Interrupts bzw. Abstürze zu erkennen:
    Code:
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      for(i=0; i< 15; i++)  // gLED2(PB5) blinken lassen bevor Interrupts erlaubt sind
      {                     //   um ungewollte Resets u.ä. besser erkennen zu können
                            // 25 Schleifen um die Slaves SICHER hochfahren zu lassen
            // Ab Version x60: 15 Schleifen um die Slaves SICHER hochfahren zu lassen
        ClrBit(PORTC, LCg); // LED auf PC6 schalten EIN, HELL
        waitms(3);          // ###>>> Die onBoard-LEDs schalten K<->Portpin <<<###
        SetBit(PORTC, LCg); // LED auf PC6 schalten AUS, Dunkel
        waitms(97);         //
        ClrBit(PORTC, LCr); // LED auf PC5 schalten EIN, HELL
        waitms(3);          // ###>>> Die onBoard-LEDs schalten K<->Portpin <<<###
        SetBit(PORTC, LCr); // LED auf PC5 schalten AUS, Dunkel
        waitms(97);         //
      }             // Ende von for(i=0; i<
    
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ... und diese ominöse Wait-Routine ist KEINE Bibliotheksroutine sondern ein selbst geschriebenes Ding (damit ich genau weiß, was da geschieht). Diese Routine ist aber KEIN präzises Uhrwerk!
    Code:
    // ============================================================================= =
    // ============================================================================= =
    //### Programm pausieren lassen  !! Der Pausenwert ist nur experimentell !
      void waitms(uint16_t ms)      // Mit #define auch Aufruf wms ( ms );
      {                             //
        for(; ms>0; ms--) 
        { 
          uint16_t __c = 4000; 
          __asm__ volatile ( 
             "1: sbiw %0,1" "\n\t" 
             "brne 1b" 
             : "=w" (__c) 
             : "0" (__c) 
          ); 
        }                           //
    }                       // Ende void waitms(uint16_t ms)
    // ============================================================================= =
    Ciao sagt der JoeamBerg

  7. #7
    Erfahrener Benutzer Roboter-Spezialist Avatar von sast
    Registriert seit
    30.11.2004
    Alter
    47
    Beiträge
    497
    Ohne deinen konkreten Code zu sehen läßt sich da jetzt schwer was sagen. Aber ich finde 10s in einer Interruptroutine schon echt heftig.

    sast

    雅思特史特芬
    开发及研究

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von 021aet04
    Registriert seit
    17.01.2005
    Ort
    Niklasdorf
    Alter
    29
    Beiträge
    4.544
    Das war auch nur zum Testen. Beim endprogramm sollte man delays in den Interrupt vermeiden.

    MfG Hannes

  9. #9
    Benutzer Stammmitglied
    Registriert seit
    16.04.2011
    Beiträge
    78
    Hallo und vielen Dank für die Unterstützung,

    @oberallgeier: Das ist echt 'ne gute Idee für jedes Mikrocontroller-implementiertes Projekt so eine Testroutine zu machen, spart viel Arbeit bei der Fehlersuche. Diese Idee werde ich mir mal leihen

    Der Code ist etwas größer, die Timer 0,1,2 inkl. der Interrrupts beim Überlauf bzw. Erreichen des Vergleichswertes werden verwendet sowie der I²C-Bus. Ich hätte nicht gedacht, dass das Ansteuern eines externen Interrupts mir diese Schmerzen bereiten wird.

    Code:
    #include .....
    
    volatile uint8_t taster = 0;
    
    ISR(INT1_vect)
    {
       taster = 1;
    }
    
    ...
    
    int main(void)
    {
       MCUCR |=(1<<ISC11)|(1<<ISC10);  // auf steigende Flanke triggern
       GICR |= (1<<INT1);     // ext. Interrupt freigeben
    
    ...
    
    sei();
    
    while(1)
    {
       while( taster ==1)
       {
          //auszuführender Code
    
           taster = 0;
       }
       
         // Rest des Codes, falls der Taster nicht 1 ist.
    }
    
       return 0;
    
    }
    Ich befürchte, mittlerweile sehe ich den Wald vor lauter Bäumen nicht. Bei fallender und steigender Flankentriggerung funktioniert es nun - jedoch nur genau ein Mal. Ist auch zeitlich unabhängig, wann ich diesen Taster drücke.

  10. #10
    Erfahrener Benutzer Robotik Einstein Avatar von 021aet04
    Registriert seit
    17.01.2005
    Ort
    Niklasdorf
    Alter
    29
    Beiträge
    4.544
    Hast du schon simuliert oder nur am Controller getestet?

    Ich habe dein erstes Programm mit einem mega88 getestet, ohne Probleme. Habe nur die Register geändert. Ich weiß wirklich nicht woran es liegt.

    MfG Hannes

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. ext. Quarz an ATmega8
    Von Zwerwelfliescher im Forum AVR Hardwarethemen
    Antworten: 3
    Letzter Beitrag: 14.03.2010, 19:31
  2. ext. Quarz an ATmega8
    Von Zwerwelfliescher im Forum AVR Hardwarethemen
    Antworten: 18
    Letzter Beitrag: 24.02.2010, 22:01
  3. Ext. Interrupt löst nur unregelmässig aus
    Von Murus im Forum AVR Hardwarethemen
    Antworten: 27
    Letzter Beitrag: 08.01.2007, 18:34
  4. Rücksprungposition nach einem ext.Interrupt
    Von lejcko im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 9
    Letzter Beitrag: 27.01.2006, 17:21
  5. Verständnisfrage Counter mit ext. Interrupt
    Von m@rkus33 im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 3
    Letzter Beitrag: 23.12.2005, 09:13

Berechtigungen

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