- 12V Akku mit 280 Ah bauen         
Ergebnis 1 bis 10 von 10

Thema: PIC12F675 TMR0 Overflow Interrupt

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    02.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    1.023
    Herzlichen Glückwunsch zum Erfolg und herzlichen Dank, dass du die Lösung hier postest und so dein Wissen mit uns (mir) teilst!

    Zitat Zitat von juppkk Beitrag anzeigen
    Beim XC8/ PIC12F675 ist alles anders, das ist mein Problem schlechthin.
    XC8 kennt T0IE nicht. Dort heißt es TMR0IE.
    Das ist ja fies. Und es läuft der Microchip-Gewohnheit zuwider, Bitnamen im XC8 abweichend vom Datenblatt zu wählen. Sieht nach einer übertriebenen Vereinheitlichung mit TMR1IF ... aus. T0IF ist ja der historische Standardname beim Timer0-Interruptflag.

    Zitat Zitat von juppkk Beitrag anzeigen
    >>>dein Kommentar //RETFIE wird von XC8 autom. generiert, ebenso GIE=0. (heißt es) macht keinen rechten Sinn. Das Global Interrupt Enable ist aktiviert, wenn =1; <<<
    Da bin ich mir sicher, das gelesen zu haben. XC8 generiert den RETFIE, ist im Debugger ja auch zu sehen und GIE wird automatisch in der ISR auf 0 gesetzt.
    Ja, schon. GIE wird mit dem Einsprung in die ISR per Hardware weggenommen und beim Verlassen der ISR vom retfie-Befehl wieder gesetzt, damit kein zweiter Interrupt verschachtelt aktiviert werden kann. Dafür ist dieser Controller nicht ausgelegt, die Rücksprungadressen würden dann durcheinander kommen.

    ISR-Priorisierung gibt es hier ebenfalls nicht. da solltest du nochmal genauer hinschauen.

    Zitat Zitat von juppkk Beitrag anzeigen
    Darum muß es im Main() immer wieder neu gesetzt werden.
    Nein. Wie sollte main() das auch sinnvoll leisten? GIE sollte in der Regel nur dort manipuliert werden, wo man einem Interrupt die Unterbrechungserlaubnis geben oder entziehen will oder zur Realisierung atomarer Befehlssequenzen. Ansonsten kann im Controller hundert Jahre lang eine Timer0-ISR zyklisch aktiviert werden ohne dass jemals GIE durch einen Programmbefehl gesetzt oder gelöscht werden muss.

  2. #2
    Neuer Benutzer Öfters hier
    Registriert seit
    30.06.2017
    Beiträge
    5
    Hallo,

    @RoboHolIC
    stimme Dir zu, mit dem GIE habe ich mich verlaufen.
    GIE wird in ISR zurückgenommen und mit RETFIE wieder gesetzt.
    Das Einzige was gehändelt werden muß ist in der ISR das TMR0IF.

    Nur so nebenbei:

    Ich habe in ISR einfach TMR0IF = 0; gesetzt.
    Warum ist das in einem Beisp. INTCON &= ~(1<<T0IF); // clear timer0 overflow bit.
    wie ein Schuß von hinten durch die Brust ins Auge?

    Interessant, TMR0IF = 1; löst umgehend einen Interrupt aus.
    Ich muß mich korrigieren, T0IF wird ebenso akzeptiert wie TMR0IF
    Kann nur vermuten, daß ich mich verschrieben hatte.

    @Klebwax
    ja, das war auf die Schnelle ein einfaches Beispiel. Jetzt wo ich es bräuchte finde ich keines, doch die letzten zwei Wochen bin ich zu Hauf über solche Besonderheiten gestolpert.
    Sei es drum, das Einzige was mich noch drückt ist die Interrupt Routine.
    Im XC8 wird von __interrupt . . . geschrieben.
    Ich bin durch Zufall und probieren bei "void interrupt lowISR(void)" gelandet.
    Es geht und stört nicht weiter, doch es scheint letztendlich nicht im Sinne des Erfinders zu sein.

    Was noch etwas bedenklich stimmt ist die beständige Meldung:
    . . . mplab_ipe\xc8\v1.00\sources\ftmul.c:60: warning: (751) arithmetic overflow in constant expression
    Es ist eine Warnung und wirkt sich nicht weiter aus.


    Gruß juppkk

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von juppkk Beitrag anzeigen
    Sei es drum, das Einzige was mich noch drückt ist die Interrupt Routine.
    Im XC8 wird von __interrupt . . . geschrieben.
    Ich bin durch Zufall und probieren bei "void interrupt lowISR(void)" gelandet.
    Das klingt für mich nach PIC18, wo es Interrupts mit Low und High Priority gibt. PIC12 hab ich bisher nicht mit Interrupt betrieben, bei PIC16 benutze ich void interrupt tc_int(void) , wobei tc_int ein Platzhalter ist. Es gibt ja nur einen Interruptvektor. Probier doch einfach void interrupt name(void).

    Warum ist das in einem Beisp. INTCON &= ~(1<<T0IF); // clear timer0 overflow bit. wie ein Schuß von hinten durch die Brust ins Auge?
    In den Headerfiles der (aller) PICs werden alle Control- und Statusbits als Bitfelder aufgedröselt und können daher im C-Code einzeln gesetzt werden. INTCONbits.T0IF = .... Daher hab ich mir abgewöhnt, solche Construkte wie "INTCON &= ~(1<<T0IF) " gedanklich nachzuvollziehen oder zu verwenden.

    Was noch etwas bedenklich stimmt ist die beständige Meldung:
    . . . mplab_ipe\xc8\v1.00\sources\ftmul.c:60: warning: (751) arithmetic overflow in constant expression
    Ich kann da nur vermuten, daß es an #define _XTAL_FREQ 4000000 liegt. Die Zahl ist zu groß für ein Integer, es sollte #define _XTAL_FREQ 4000000UL heißen. Die Wirkung könnte sein, daß die delay-Routinen falsche Zeiten liefern.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    30.06.2017
    Beiträge
    5
    Hallo,
    danke,
    #define _XTAL_FREQ 4000000UL bringt keine Änderung.

    Das meine ich ja. TMR0IF =0; ist kurz u. bündig, INTCON &= ~(1<<T0IF) muß man erst einmal durchblickern.

    Gruß juppkk

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von juppkk Beitrag anzeigen

    Das meine ich ja. TMR0IF =0; ist kurz u. bündig, INTCON &= ~(1<<T0IF) muß man erst einmal durchblickern.
    Warum benutzt du es dann? Schreib einfach INTCONbits.T0IF =... oder INTCONbits.TMR0IF = .... Das sind Bezeichnungen von Strukturelementen, da gehört der Name der Struktur INTCONbits mit hinein. Aus PIC12F675.h

    Code:
    // Register: INTCON
    extern volatile unsigned char INTCON @ 0x00B;
    #ifndef _LIB_BUILD
    asm("INTCON equ 0Bh");
    #endif
    // bitfield definitions
    typedef union {
        struct {
            unsigned GPIF                   :1;
            unsigned INTF                   :1;
            unsigned T0IF                   :1;
            unsigned GPIE                   :1;
            unsigned INTE                   :1;
            unsigned T0IE                   :1;
            unsigned PEIE                   :1;
            unsigned GIE                    :1;
        };
        struct {
            unsigned                        :2;
            unsigned TMR0IF                 :1;
            unsigned                        :2;
            unsigned TMR0IE                 :1;
        };
    } INTCONbits_t;
    extern volatile INTCONbits_t INTCONbits @ 0x00B;
    Hier sieht man, daß aus Kompatibilitätsgründen TMR0IF und TMR0IE auch noch unterstützt werden.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  6. #6
    Neuer Benutzer Öfters hier
    Registriert seit
    30.06.2017
    Beiträge
    5
    Hallo,
    irgendwie ein Mißverständnis.
    Ich verwende TMR0IF =0;
    INTCON &= ~(1<<T0IF) habe ich auf der Suche nach Lösungen einem Beispiel entnommen.
    Es stellt sich die Frage, warum macht jemand so etwas?

    Gruß juppkk

Ähnliche Themen

  1. Seltsames Verhalten Timer 0 overflow interrupt
    Von Markus87 im Forum Assembler-Programmierung
    Antworten: 6
    Letzter Beitrag: 24.08.2011, 19:27
  2. Kein Overflow Interrupt für Timer0
    Von eli45 im Forum C - Programmierung (GCC u.a.)
    Antworten: 4
    Letzter Beitrag: 05.06.2007, 20:56
  3. Timer2 overflow Interrupt will nicht
    Von BomberD im Forum C - Programmierung (GCC u.a.)
    Antworten: 10
    Letzter Beitrag: 30.01.2006, 16:37
  4. Overflow Interrupt für Timer
    Von Maestro im Forum AVR Hardwarethemen
    Antworten: 8
    Letzter Beitrag: 28.09.2004, 17:02
  5. Analogverarbeitung und TMR0 Interrupt am 12F675
    Von Steffen35 im Forum PIC Controller
    Antworten: 1
    Letzter Beitrag: 09.09.2004, 21:05

Stichworte

Berechtigungen

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

MultiPlus Wechselrichter Insel und Nulleinspeisung Conrad