difference between measurement theory on interrupt timer0.

[nanard-bis]

Hello,

I have probleme with the #int_timer0,
with the code below:
-set_timer0(125);
256-125=131
131*1µs=131µs with quartz 4MHz.
the timer 0 is overflow evry 131µs.
but i use bit0 on portc for flag
and the interrupt is overflow 171µs.
difference measure theory 40µs.
Perhaps this difference become my
ICD1 emulator in real time running.


#int_rtcc
isr(){
RC0 = 1;/*flag*/
RC0 = 0;
set_timer0(125);
}

main()
{
TRISC = 0x00;/*Port C en OUT*/
PORTC = 0x00;/*initialise le portC*/
set_timer0(125);
setup_timer_0(RTCC_DIV_1|RTCC_INTERNAL);
enable_interrupts(GLOBAL);
enable_interrupts(INT_TIMER0);
do
{

}
while( 1 );
}
___________________________
This message was ported from CCS's old forum
Original Post ID: 11093

[R.J.Hamlett]

:=Hello,
:=
:=I have probleme with the #int_timer0,
:=with the code below:
:=-set_timer0(125);
:=256-125=131
:=131*1µs=131µs with quartz 4MHz.
:=the timer 0 is overflow evry 131µs.
:=but i use bit0 on portc for flag
:=and the interrupt is overflow 171µs.
:=difference measure theory 40µs.
:=Perhaps this difference become my
:=ICD1 emulator in real time running.
:=
The difference you have, is slightly more than I'd expect, but a significant difference will allways appear from handling things this way.
This approach is OK, for dealing with a _slow_ timer, that only cycleas once every few hundred machine instructions, but will not work properly for a timer at this sort of speed.
First, there is a hardware latency, to interrupt response, that will delay the start of the actual service routine. Then the interrupt service code, is _not_ the code you write, but the 'int_global' handler, which will normally add perhaps 10 to 20 instructions, to save the registers, before calling your routine.
You are making it worse, by leaving the resetting of the timer to the end of the routine.
So to get the minimum latency, would require you to replace the generic 'int_global' handler (though you will have to ensure that the essential registers 'W', 'Status', and the BSR, are saved before you change timer0), and calculate the instruction times for this code, then put this corrected value into the timer register...
There is (fortunately), another solution that works significantly better. You can add 125 to the timer_0 counter. Since it will have carried on counting from '0' when you entered the interrupt handler, this then adds the required offset to keep the events when expected. Since the register is read at the start of the addition cycle, and then written back at the end of the cycle, I'd have to look carefully at the data sheet, to see if this means one increment will be missed (I'd expect you might have to add 126).
You can access the register directly, by setting up a byte define for it (you don't say what processor this is, so I cannot give the line required), or (preferably), by doing an addition in assembler something like:

#asm
movlw 125
addwf timer_0,1
#endasm

You will again have to define the address of the timer_0 counter to suit your processor.

You are going to be straining to handle an interrupt at this frequency, without a lot of care in the code, since the default handler does add a significant latency...

:=#int_rtcc
:=isr(){
:=RC0 = 1;/*flag*/
:=RC0 = 0;
:=set_timer0(125);
:=}
:=
:=main()
:={
:=TRISC = 0x00;/*Port C en OUT*/
:=PORTC = 0x00;/*initialise le portC*/
:=set_timer0(125);
:=setup_timer_0(RTCC_DIV_1|RTCC_INTERNAL);
:=enable_interrupts(GLOBAL);
:=enable_interrupts(INT_TIMER0);
:=do
:={
:=
:=}
:=while( 1 );
:=}

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 11103