DT-Interrupts - Is there a clash between ExtInt and IntOnChange?

[Dave]

Looking at your code I do not see the IRQ routine "ClockCount".

[Balachandar]

Looking at your code I do not see the IRQ routine "ClockCount".

The routine "ClockCount" is part of the included file "Elapsed_INT.bas".

[richard]

Is there a clash between Timer1 Int and IntOnChange?

no , thats just not the way to manage time critical interrupt routines.

interrupts on a pic16 cannot be interrupted therefore for the entire duration of
RunTheFanAtCurrentSpeed: and the GetTheIRCommand: routines the timer is effectively stalled
it simply cannot keep time.

[Balachandar]

interrupts on a pic16 cannot be interrupted therefore for the entire duration of
RunTheFanAtCurrentSpeed: and the GetTheIRCommand: routines the timer is effectively stalled
it simply cannot keep time.

Thanks Richard, for clearly stating where the problem is.

When one interrupt is being serviced, if another interrupt occurs, the second one either gets ignored (in PIC16 and lower) or is acted upon after a delay (in PIC18). That's what I understand from your post.

When I use my IR remote, if I have to press the button 2 or 3 times or there is a delay of a few milliseconds in executing that command, it is not an issue. But when the error margin is around 80% or higher in the operation of the Elapsed Timer, that is definitely a big problem.

I feel, using another PIC like 12F683 for the Elapsed Timer is one solution. If I use an 18F device, I will have the option to assign priority to interrupts but the Timer accuracy will still be an issue.

Are there other ways of solving the problem?

- Bala

[richard]

generally the best solution is to absolute minimum processing in the isr like set a flag to indicate to main code that a task must be performed

ie
your triac isr can hold processing up for over 6mS
you could instead use zero cross to start another timer for "speed delay" that timer can then cause an interrupt to fire triac
both of these isr's could be very simple and done as asm type for absolute minimum overhead.
the "ir" isr could similarly start a timer and reset for another edge trigger set state 1. with the timer set for a period greater than the ir start pulse time
if the timer int goes off then its a false trigger if the timer value is to low when the edge triggers then its a false trigger otherwise
for a good trigger set a state so the foreground processing can decode the ir stream.
this would be a state managed process
state 0 ir idle
state 1 ir active
state 2 ir start pulse detected ,manage in foreground
it can all be done in uS no bogging down with delays

[Balachandar]

Thank you Richard, for the suggestions. I will try and implement whatever I can.

I haven't written any code in Asm so far. I guess, when it comes to using multiple interrupts, learning to code in Asm may be a necessity.

What about using a second PIC for the Elapsed Timer with a common clock? Is it worth trying?

- Bala

[richard]

i doubt its really necessary , it still leaves the issue of transferring data between chips with lots of isr's running

[Ioannis]

The tricky part as I see it, under Richard's directions, is the processing of ir in the foreground. But states will help, as long as your routines are fast enough.

Better start with one task at the time and if it works ok, add another. All together might complex things and prevent debugging.

Ioannis