12F683 and DT Instant Interrupts

[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

[Darrel Taylor]

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

Anything that requires precise timing should be done in the handler, preferably in an ASM handler.

When it returns to the Main loop with a Flag set, the process it triggers should be able to do it, "whenever it gets around to it". There may be several things going on, and there's no guarantee when it will be processed.

If you're reading servo pulses, then the entire process of measuring the pulse should be done with the interrupts, and I don't mean sitting in a PULSIN statement in the handler. On the rising edge, start a timer. On the falling edge, stop the timer and collect the reading. Each time leaving the handler until the next condition occurs. Once you have a reading, then set a flag to let the main loop know to process the data. Now it has all the time in-between pulses to work on all those error rates, jitter etc and display them on the LCD at it's leisure.

[mr.sneezy]

Thanks Darrel,
In this part of the project (maybe the only part) I'm making the pulses, eight in a row for eight RC servo channels, of varying periods, rather than reading them. The TMR1 interrupt is just keeping the overall frame timing right.
Looking it now I think a tight loop reading the roll-over flag of the counter then doing the pulse train code would have worked just as well. I guess I thought that a real timer interrupt would minimise jitter in the total frame length.
Never mind, I'll carry on with the interrupt method now that I've started it.

I'd still like to see Alains code though.... Alain ?

Martin