Interrupting an Interrupt?

[arrow]

Hi Andrew

Thank you- I shall try what you suggest

Can you please explain to me why the interrupts have to be disabled in the first place? (Do they absolutely have to be disabled?)

I am assuming that the interrupts will not effect the i2c_write() command if it comes when its being executed?

Regards
arrow

[asmallri]

You are using "long" variables. These are 2 byte values. The problem occurs because to examine and/or modify these values in the mainline., the comiler must first evaluate the low order byte (usually) and then the high order byte. Depending on the operatio it can take several cycles to complete and can result in the incorrect modification of the variable.

Consider the following example. You have a value that is 0x00ff and the mainline is about to increment it by one. You would expect the result to be 0x0100. First the compiler increments the low order byte. The value is now 0x00 with the carry flag set. The compiler then increments the high order byte. and the final result is 0x01 (high order byte) 0x00 (low order byte). But what happens if an interrupt occurred immediately after the PIC incremented the low order byte? The interrupt handler sees the low order byte = 0x00 (the new value) and it sees the high order byte = 0x00 (not yet incremented) so the interrupt handler sees the long value of the 0x0000. In your specific example it is the other way around. You are testing a value set in the interrupt handler but the results are the same - your comparison is meaningless.

Do interrupts HAVE to be disabled? No. You are ways to code around the problem. For example is you used an 8 bit integer instead of a 16 bit then you would not have hit this problem.

HAving said that, the amount of time you are "losing" is 2us per loop. You may be adding 20us of jitter with respect to the INT_RB event but, compared with your earlier code, this is far superiour.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[arrow]

Hi Andrew

Thank you very much!!-- I have tried what you suggested and it works pretty well.
I am not too worried about the 2us jitter. I am not certain why you say I get 20us jitter in the INT_RB event, but in any event both times are insignificantly small for me.

I noticed that by removing the first printf in the original code, things also work fine, and I dont miss any interrupts.
I will try and convert the int long to int as well- just to clean things up further.

I really appreciate all your help.
All the best
arrow

[asmallri]

The lost 2us comes from having to add the enable and disable interrupt instruction in your for loop. Each instruction takes one cycle therefore adding 2us to the time it takes to run through the loop.

The 20us jitter occurs because when interrupts are enables, the interrupt event immediately interrupts the processor. Bu now with interrupts disabled in the mainline, the wirst case scenario is an interrupt event occurs immediately after the interrupt is disabled but the PIC ignores it but the interrupt is disabled (masked). It will take the PIC about 20us to execute the code between the disable interrupt instruction and the enable interrupt instruction. This is where the 20us jitter comes from.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[arrow]

Hi Andrew

Thank you for all your help and explanations! It has helped me tremendously.

Just to make absolutely certain- if I have one state of my B port, and then I go into the disable/ enable interrupts.
When I enable interrupts, I have another state of my B port- will I miss the event that has occured? (I think I will).

Also, if I am executing a line of code, and an interrupt occurs, does that mean that I first finish that line, and then go to the interrupt subroutine?

Regards
arrow

[Ttelmah]

Key thing is to use 'disable_interrupts(GLOBAL)'.
Basically, if you use this, is disables the flag, preventing the CPU from responding to any interrupt that occurs. However the individual interupt flags will still be set. Hence if you re-enable the global interrupt as soon as you have finished, at that moment, the chip will then call the interrupt handler.
Interrupt 'events' are checked in the first clock cycle of an instruction (not a line of code). You will enter the interrupt routine, the instruction after the event occured. However the actual interrupt 'handler', then takes perhaps 20 to 30 instructions to save the registers, and call the individual handler routines, so you do not actually 'reach' the interrupt code till quite a few instruction times latter.
As an example of how to disable interrupts, I wrote this (quite a while ago), when the compiler had a fault with the way it was disabling interrupts in a 'block move' routine, if it was used in both an interrupt handler, and outside. I therefore have to disable interrupts if the routine is called outside the interrupt handler, but leave them unchanged if the routine is called inside. I defined the internal processor registers and bits needed (particularly 'GIE', which is the 'global interrupt enable' bit), and check this before deciding what to do.

[asmallri]