Timing problems betwee two interrupts ?

Bart · Joined: 12 Jul 2005 Posts: 49

Hello,

As I am still newbie, I can't directly find why my blue led is not flickering at a constant interval.
It blinks about 3 (or 6 or 9 or 10) times correct and than it give a long (not 100 ms but about 1 sec) blink. This repeats.

Is this somewere a confusion between the two interrupt routines ?

Thanks.

PS : some people will recognise parts of the code. Smile

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

The routine for blinking the led looks fine to me, so I guess the error is in the other interrupt.
Interrupt routines should be as fast as possible, never implement any blocking function calls in an interrupt routine. Once an interrupt routine is active it will prohibit other interrupts from executing.
In your external interrupt routine you are calling fgetc() which is a potential blocking function, if no data is available it will wait for a character to arrive.

What is connected to your external interrupt line?
Is it possible for you to use the serial receive (INT_RX) instead?

Bart · Joined: 12 Jul 2005 Posts: 49

( Bedankt ckielstra voor de reactie ! )

To the external interrupt line there is a serial GPS connected with generate a interrupt when the data string comes in. So, normally, as I detect the start off the string with the interrupt, the fgetc() never has to wait. (String is about 70 characters long).

The only I can thing is that it stays to long in that interupt routine for putting the string in the buffer. As you say, a new interrupt will not start before the previous is finished, I thing I am missing some blinking interupts.

Can someone confirm this ? Is there a solution ?
Thanks.
_________________
I like Skype (www.skype.com), my username is BplotM

Ttelmah · Guest

One thing that would make things go really screwy, would be if there is an edge seen on the interrupt, and this is not the leading edge of a byte (noise, or a repeated trigger from the tail of the last byte received). In this case, the system will hang at the fgetc. Though it involves a couple of extra instructions, I'd add a test that the signal line is low, before calling fgetc, and return if not. It might fix the problem.
One problem, might be the case that the system is in the timer interrupt, when the external interrupt occurs. The typical interrupt 'latency' is about 25 instructions. so if a timer interrupt occured just at the same moment as a external interrupt, given that it has priority (this is implicit in the handler being first), then you will have the 25 instructions into the routine, the routine itself (perhaps another 20 instructions), plus the return time (about 20 instructions), plus about 28 instructions to get into the external interrupt code. This gives a worst case of about 93 instructions from the moment the interrupt occurs, to actually arriving at the fgetc routine. This then checks the signal for being low. This should be true (about 20uSec after the edge), but the time involved might make it unreliable. You can reduce this time, by giving the external interrupt priority over the LED code. Either move it's routine in front of the RTCC code, or use the 'priority' statement to define this as the higher priority routine. though it seems 'odd' to raise the priority of the interrupt that is not giving the problem, it might help.
So, I'd try testing for the start bit, and reversing the interrupt priority.

Best Wishes