DT_INTS-14 , Elasped_INT, and 16F87 code not working

[Dave]

Maybe it's my eyes but I see NO "Gosub StopTimer, or any GOSUB ResetTime" routines. Also you should NOT be using GOSUB's inside an interrupt.

[Archangel]

Try WDT_OFF WDT will reset everything if ISR takes too long, at least that's what I read once upon a time.

[HenrikOlsson]

Hi,

Also you should NOT be using GOSUB's inside an interrupt.

This is one of my pet peeves.... I see it being mentioned "all the time" but never ever does anyone give an explanation to why.

I mean, I CAN see reasons for it not being a good idea but to just generally advising against it is a bit strong IMO.

One reason for it not being a good idea is, for example, if you're GOSUB'ing a routine (from within the ISR) that you ALSO may be GOSUB'ing from somewhere in your main program loop - if an interrupt occurs while the main program loop is within the subroutine. If that happens the "instance" of the routine that the main program is executing may be "corrupted" by the ISR executing the same piece of code.

I'm not saying I'm correct here, what I'm asking for it to please explain WHY you should NOT do it. Doing so will help us UNDERSTAND and not just painstakingly follow an advice that we do not understand the reasoning behind.

/Henrik.

[richard]

the problem is with the stack . core 14 devices have a 8 level hardware stack , 4 levels can be used by pbp leaving 4 for your program. an interrupt will use 1 of these , a gosub in the interrupt uses another .
its not impossible to do but you need to be mindful of the limitations

[mark_s]

I seem to remember when using pic16F's and interrupt on change you had to read portb to clear a mismatch?

dummy = portb
@ INT_RETURN

[Dave]

Mark_s, You are correct, But who reads the data sheets anyways? Henrick and Richard, you are both correct, Also there are the extra cycles used up in the stack execution.