Timer2 interrupt problem

[Kavarwax]

Hello everybody,
I'm curently working on the CCS C Compiler Version 4.013, using the environment of MPLAB IED 7.60.00.00
I'm working on a PIC18F2420 with a 8MHz quartz.
I have a problem using the Timer2.

Here is how I initialised it:

setup_timer_2(T2_DIV_BY_4,24,1);
enable_interrupts(INT_TIMER2);
enable_interrupts(GLOBAL);

This mean that I have set up Timer2 interrupts to happen each 50µs.

Here is my source code:

#int_TIMER2
void TIMER2_isr()
{
PIR1bits.TMR2IF = 0;

if(CompteurTimer2 == 39){ //when the counter = 39 it means 2ms have passed
CompterTimer2 = 0; // Reinit the counter
AutorisationBitW = 1; // Special action authorized
}
else{
AutorisationBitW = 0; // Special action unauthorized
CompteurTimer2++; // Incrementation of the counter
output_bit(PIN_B0, 1); // Reinit @5V
output_bit(PIN_B1, 1); // Reinit @5V
}
}

When the Special action is actived, either the PIN_B0 or the PIN_B1 is set at the value 0 (output_low). This mean that 50µs after, the special action is unauthorized and the PIN is set at the high value with output_bit(PIN_Bx,1).
So normally this code toggle PIN_B0 or PIN_B1 during 50µs when special authorization is actived.

My problem is the following : the application turns the bit_low during 25-35µs. This value is not 50µs !! :-( Moreover this value is not fixe... it oscillate between 25 and 35µs...
I don't know what to do, I have tried everything: priority interrupts, clearing the TMR2IF, optimized my source code. Nothing changed.
Do I have to change my quartz speed value?
Is they any problem in my source code ? maybe too much test condition in my Timer2?

Please help me ! :-)

Thank you,


Kavarwax

[Ttelmah]

The timing is not going to happen at 50uSec, with the code as shown.
It appears that the code that actually _clears_ the bit, is in the main routine somewhere. This will execute some significant time after the interrupt event has happened. The actual time is going to be large (even if the code is polling 'AutorisationBitW' all the time, it will take typically perhaps 25 instructions at least, to actually exit the interrupt code, the bit will then be cleared perhaps 12.5uSec latter than when the event occured. The actual timing in the main, will depend on when the interrupt ocurs in the polling loop, leading to variability in the timing. If you are timing from when this clears, to when it is set again, this explains the times you are seeing.

Best Wishes

[Kavarwax]

Thank you Ttelmah for your response,
I understand where it comes from, but I don't know how to calculate the 12,5µs you mentionned for example.
However, do you have an idea to reduce as much as possible this delay between 'when the interruption occurs' and 'when the PIN is set' ?

Regards,

Kavarwax

[kavarwax]

Nobody can help me ?
If I change my 8MHz quartz with a 20MHz quartz, will the delay of 25µs decrease to 10µs ?

Regards

[Ttelmah]

The delay, is the code involved in actually handling the interrupt. The processor has to save all the scratch registers, then all the working registers. Then test the bits to find which interrupt has occured (the 'priority' setting, determines the order this is done), then call the actual interrupt handler. When the handler completes, it then clears the interrupt bit (your operation to do this inside the handler is actually a wasted instruction - the 'NOCLEAR' option on the handler declaration, will save one instruction, as it'll stop this code being automatically added). Then, restores the registers, and finally returns to the main code. The overhead varies with the processor (is actually worse on the 18 chips,than the 16 chips), but is typically about 24 to 27 instructions to 'reach' the interrupt code, and about the same on the way back. Then there will be the time involved to reach the instruction to test the bit inside the main code (will depend on how this is written), and the code to actually reset the output bit. The delay you will 'see', will be the latter delay, plus the code to return from the interrupt. The delay on the way 'in', will be present both in the code to set the bit, and in the code to clear the bit, so won't directly be visible. You would need to count the instructions in the generated assembler, from every possible location where the interrupt could occur, to work out the limits of the delay.
Yes, of course it'll get shorter if you increase the clock.
This has been discussed here _hundreds_ of times. A search in the forum, will find discussions on how to reduce it, and the caveats in this.

Best Wishes