12F683 and DT Instant Interrupts

[mr.sneezy]

I'm trying to get my head across the DT Interrupt code for a small new RC modeling project and I'm trying a test example first (the blinky LED) , compiling with MCS. I have 12f683 selected in MCS and MPASM being used.

but I get an odd warning message from MCS thus :
Warning[219] d:\pbp code\pbp\pbppic14.lib 336 : Invalid RAM location specified
Warning[219] d:\pbp code\pbp\pbppic14.lib 892 : Invalid RAM location specified

Anybody know why and if I should just disregard it ?

I commented out the wsave lines as required (which led me here BTW)

My code

LED1   VAR  PORTB.1

INCLUDE "DT_INTS-14.bas"     ' Base Interrupt System
INCLUDE "ReEnterPBP.bas"     ' Include if using PBP interrupts

ASM
RBIF = GPIF
RBIE = GPIE

INT_LIST  macro    ; IntSource,        Label,  Type, ResetFlag?
        INT_Handler   TMR1_INT,  _ToggleLED1,   PBP,  yes
    endm
    INT_CREATE               ; Creates the interrupt processor
ENDASM

T1CON = $31                ; Prescaler = 8, TMR1ON
@ INT_ENABLE  TMR1_INT     ; enable Timer 1 interrupts

Main:
  PAUSE 1
GOTO Main

'---[TMR1 - interrupt handler]--------------------------------------------------
ToggleLED1:
     TOGGLE LED1
@ INT_RETURN

My project is quite simple. A 22.5mS interrupt timer (TMR1 I guess) and toggle a few pins then wait for the next interrupt.
Martin

[Darrel Taylor]

Try ...

;LED1 VAR PORTB.1

LED1 VAR GPIO.1
<br>

[mr.sneezy]

Try ...

;LED1 VAR PORTB.1

LED1 VAR GPIO.1
<br>

Yeah.... I forgot about port pins on the smaller PIC's (again).
Ta, Martin

[mr.sneezy]

Now my code compiles fine thankyou, barring a overwriting previous address warning from my config settings (I understand why that is). But I have a small question regarding reloading the timer for anyone.

Must I stop the timer while reloading it with a hex value of A823 in the interrupt handler code (which is all it needs to do) ?

T1CON = %0
TMR1H = $A8
TMR1L = $23
T1CON = %1

Or can I ignore the stop-start safely. Given I can tweak the timer value by trial and error to get my 22.5mS @ 4Mhz ?

The only examples I've dug out on the forum are using ASM code and I'm not strong on interpreting it.

[Darrel Taylor]

It's not absolutely required, unless the reload value is calculated.

When you have a fixed value like that, you can be pretty sure the LowByte won't overflow before it loads the HighByte.

However, you'll need to load the LowByte first, if you're not turning the timer off. And you'll also need to subtract 7 from the number you have, which is adjusted for a reload that does turn the timer off.
<br>

[mr.sneezy]

In my code I do a bunch of stuff then wait doing nothing for an interrupt some mS later, then when that happens I want to run my bunch of stuff again, forever and ever. Rather than return to where the interrupt occurred in my 'wait doing nothing'....

I see the obvious way is to put my 'bunch of stuff code in the interrupt handler subroutine, but that makes the int handler routine very big and the 'main' code very small. Looks all wrong to me. Is that the way to do it or is there a proper way to get the int handler to go to my 'bunch of stuff' rather than return to where it was interrupted from ?

LED1   VAR  GPIO.1

INCLUDE "DT_INTS-14.bas"     ' Base Interrupt System
INCLUDE "ReEnterPBP.bas"     ' Include if using PBP interrupts

ASM
INT_LIST  macro    ; IntSource,        Label,  Type, ResetFlag?
        INT_Handler   TMR1_INT,  _ToggleLED1,   PBP,  yes
    endm
    INT_CREATE               ; Creates the interrupt processor
ENDASM

T1CON = $01                ; Prescaler = 1, TMR1ON
@ INT_ENABLE  TMR1_INT     ; enable Timer 1 interrupts

Main:
     Big bunch of stuff

wait_here:
     pause 1
     Goto wait_here    'wait for an interrupt here
(Return from Interrupt would hang here ?)

GOTO Main    'should never happen

'---[TMR1 - interrupt handler]--------------------------------------------------
ToggleLED1:
     
    T1CON = %0
    TMR1L = $23
    TMR1H = $A8
    T1CON = %1
    TOGGLE LED1    
@ INT_RETURN

[Acetronics2]

Hi, Mr Sneezy

I do not know what's your final project ... BUT :

Did you ever considered the R/C Framerate is an excellent timebase with 22.5 ms granularity ??? ( looks Graupner/JR remote ??? )

No need for heavy interrupt implementing, then.

just a simple idea ...

Alain