12F683 and DT Instant Interrupts

[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

[mr.sneezy]

Hi, Mr Sneezy

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

Alain

but you're very very close Alain.....

Except in my application I'm needing to generate an 8ch PPM pulse frame at 22.5mS rate from scratch.

To cut to the chase what I want to do is build a simple RC TX radio eliminator so I can test prototype 2.4Ghz transmitter modules in the field (range tests etc etc) without needing a second person to wiggle the sticks on the radio (it uses Futaba compatible TX modules). I did the obvious thing and looked for existing projects but they all seem to decode PPM frames not create them...

The app will change the PPM period for two channels (at least) slowly so the servos move at the RX end while I move away doing testing (sometimes Km's). The remaining channels will just be 1.5mS center position all the time.

Sorry for the apparently newbie programming questions, I've actually written some quite large complex code in the past (way way past) but I do it so infrequently now I have to go back to basics at the start of a new project like a beginner. I never seem to do a similar project twice which doesn't help.

I guess another way of asking my question is can I have a lot of code in the interrupt handler subroutine ? Or could that bugger up the interrupt code ?

Thanks,
Martin