12F683 and DT Instant Interrupts

[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

[Acetronics2]

Hi, Martin

I already have it here aboard a 12F675 ... just change repeating time to match the 22.5 ms ( was originally intended for a MPX frame ) lol !!!

But do no want to tear your pleasure at all ... if it's your wish to discover interrupt charms !

I' d recommand you to trim the first channel to 1.1 ms, the second to 1.2, third to 1.3 ... and so on. That will make later channel identification much easier.

My application was static demo of boats without using RF ... ( Other Boats on "live show" at same time ... for the Warwick show !).

Humouristically yours ...

Alain

[Acetronics2]

BTW ...

I remember there's a non-PCM other solution ...

PULSIN + some little lines can detect bad pulse duration ( = glitches = max. range) just place a servo in a preset position if glitches appear ( you can allow as much glitches as you want before entering " Fail safe" )

Based on that ... you just take a receiver a batt and a servo, or your plane ... with you while the Tx keeps steady.

I use it aboard a Glo Driver : Engine is slammed to idle, or cut, if too much glitches.

Already saved many planes ... including scale championship ones !!!


PCM have that feature ... so, just need to use it !!!

My MC18 Transmitter also has a Servo-test feature ... that move automatically servos one after the other ...


I didn't write it ... but why not use the coder's signal through the "Pupil's plug" ???
Alain

[mr.sneezy]

Hi, Martin

I already have it here aboard a 12F675 ... just change repeating time to match the 22.5 ms ( was originally intended for a MPX frame ) lol !!!

Alain

Hi Alain,

Yes thanks, if you have a code that does the same job I'd like to see it. I'll either try it out as you wrote it or use it for inspiration to finish mine. You could send it via a personal message or post it here. I have a couple of 12F675's in my bits box.

Going on to your second reply, that is a good idea about the servo positions. To take it one step further I could have a PIC analysing the channel outputs over time and coming up with a sort of 'error rate' like we use on digital communications bearers here. Going all the way would have a PIC with LCD, displaying error rate (glitches/holds per minute ?) for each channel plus a summed figure. That way I can compare different 2.4Ghz receiver versions against a mathmatical benchmark...

Oh boy, I'd better go do something else before this turns into a monster project !

Martin

[mr.sneezy]

Getting back on topic with DT int code. Is it a bad thing to put GOTO's or GOSUB'S inside the interrupt handler ? Therefore maybe never seeing the @ INT_RETURN

'---[TMR1 - interrupt handler]--------------------------------------------------
ToggleLED1:

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

GOTO MAIN 'is this dangerous ?

@ INT_RETURN

[Darrel Taylor]

GOTO MAIN 'is this dangerous ?

Suicidal!

You will only get one interrupt that way, untill power is cycled or the GIE bit is set manually.

If you need to trigger processes in the main loop, you can set a Flag in the handler. Once it returns from the handler, the main loop can execute the required task where it can be interrupted again.

On 12F's and 16F's, you should NEVER gosub from the handler. There just aren't enough stack levels.

[mr.sneezy]

"Suicidal" I like it Darrel :-)
That word doesn't get used in code discussion much I'm sure...
OK, I just hit 'undo' on my code several times to stop myself needing to go slash my wrists ;-)

Flag. OK, if I understand correct I should set a flag variable in the int handler, then put my main code into a tight loop checking for it, then jump to my PPM output code when true, then back to the tight loop after clearing the flag...

There are a heap of ways to make a tight loop (If-then, While-wend, repeat-until). What would be the tightest (fastest) ? ASM ?

Martin