Problem mit PIC-interrupts

[Frank M. (aktenasche)]

ich hab gerade mit der programmierung von einem PIC18F4550 begonnen.

IDE: mplab + proteus/isis
compiler: C18
vorkenntnisse: 8051, AVRs

ich bin durch ein wenig googeln nun darauf gekommen, dass der pic18f 
generell nur 2 interruptvektoren kennt, 0x08 für high priority und bei 
0x18 für high priority.
so gut so weit.

leider wird meine ISR (Timer1_ISR()) nie ausgeführt? code ist copypasta.

gibt es denn keine möglichkeit dem compiler zu sagen: die funktion soll 
meine timer1 isr sein? ausser über die flagunterscheidung.

der timer1 interrupt tritt jedenfalls auf, sagt isis (siehe screenshot). 
vielleicht kann man der simulation auch nicht ganz trauen.

//main insterrupt handler
#pragma interruptlow MainISR
void MainISR(void)
{
  Timer1_ISR();
}  

//high ISR routine
#pragma code _HIGH_INTERRUPT_VECTOR = 0x000008
void ISR_high(void)
{
     _asm
       goto MainISR      // Sprung zur Interruptroutine
    _endasm
}  
//low ISR routine
#pragma code _LOW_INTERRUPT_VECTOR = 0x000018
void ISR_low(void)
{
  _asm
       goto MainISR       // Sprung zur Interruptroutine
    _endasm
}

void InitializeRTC(void)
{
  T1CONbits.RD16 = 1;    //16 bit mode
  T1CONbits.T1CKPS1 = 1;  //prescaler: 1:8
  T1CONbits.T1CKPS0 = 1;
  T1CONbits.T1OSCEN = 1;  //enable oscillator circuit
  T1CONbits.TMR1CS = 0;  //use internal clock
  T1CONbits.T1SYNC = 0;  //synchronize timer with external clock
  
  TMR1L = 0x00;
  TMR1H = 0x00;
  
  T1CONbits.TMR1ON = 1;  //enable timer 1
}  

void Timer1_ISR(void)
{
  T1CONbits.TMR1ON = 0;  //disable timer 1
  PIR1bits.TMR1IF = 0;  //reset flag
  TMR1L = 0x00;    //reset timer registers
  TMR1H = 0x00;
  MAX7219_DisplayChar(3,'A');
  T1CONbits.TMR1ON = 1;  //enable timer 1
}

//initialize interrupts
void ConfigureInterrupts()
{
  RCONbits.IPEN = 0;    //no interrupt priority
  RCONbits.SBOREN = 0;  //no brownout detection
    
  //timer
  PIE1bits.TMR1IE = 1;    //enable timer 1 interrupt
  INTCONbits.GIE = 1;      //global interrupt enable
}

[slow (Gast)]

>0x08 für high priority und bei
>0x18 für high priority.


???????????

[Frank M. (aktenasche)]

0x18 low, sorry ^^

[Meister E. (edson)]

Du musst auch die Interrupts der Peripherie zulassen:

//timer
   PIE1bits.TMR1IE = 1;    //enable timer 1 interrupt
   INTCONbits.PEIE = 1;// <- hier Peripherie-Ints erlauben
   INTCONbits.GIE = 1;      //global interrupt enable

Gruß,
Edson

[Frank M. (aktenasche)]

danke, jetzt funktioniert es!

[Marcus (Gast)]

Hallo Frank,


>>gibt es denn keine möglichkeit dem compiler zu sagen: die funktion soll
>>meine timer1 isr sein? ausser über die flagunterscheidung.

Nein. Ist halt so. Geh' halt in den Interrrupt-Handlern die jeweiligen 
Flags durch und gut.
In der Praxis wirst Du es ohnehin so gestaltem, daß Du das _wirklich_ 
zeitkritische in den Handler mit der hohen Prio legen wirst. Der Rest 
ist eh' egal. D kommt es auf die paar Zyklen zur Fallunterscheidung 
nicht an.

BTW: Wenn Du GENAUE Timerzyklen haben willst: Schalt' den Timer in der 
Interruptroutine nicht ab. Never. Einfach laufen lassen.

Schau Dir mal im Datenblatt die Interruptlogik an; Du musst noch 
Pheeripheral Interupts einschalten, dann sollte es funktionieren.

Viele Grüße,
Marcus

[Frank M. (aktenasche)]

Marcus schrieb:
> BTW: Wenn Du GENAUE Timerzyklen haben willst: Schalt' den Timer in der
> Interruptroutine nicht ab. Never. Einfach laufen lassen.

ja, eigentlich brauch ich sehr genaue timerzyklen da ich eine RTC 
implementieren will (mit quarz versteht sich)

damit das timerregister nach genau einer sekunde überläuft muss ich 
allerdings das high register bei jedem interrupt auf 0x80 setzen und das 
dürfte doch unvorhersehbare ergebnisse liefern wenn ich den timer 
weiterlaufen lasse?

oder ist das egal, wenn man davon ausgeht dass die ISR innerhalb von 255 
(also vor dem überlauf von low->high) abgeschlossen ist?

eine autoreload funktionalität scheint es ja nicht zu geben...

p.s.: was ist denn peripheral und was nicht?

[holger (Gast)]

>ja, eigentlich brauch ich sehr genaue timerzyklen da ich eine RTC
>implementieren will (mit quarz versteht sich)

Da wirst du mit Overflow aber nichts. Bei jedem Overflow
verlierst du Zeit. Nimm CCP.

[Frank M. (aktenasche)]

ist auch ne möglichkeit, danke für den tipp

[Dieter W. (dds5)]

Frank Meier schrieb:
> eine autoreload funktionalität scheint es ja nicht zu geben...

Gibt es, aber nur mit 8Bit Timer 2.