quick one about timer acuracy

[teekaytk]

hi all,
I need timer accurate to micro (or even pico) second. I was looking through the PIC manul that says that you should add 2 to your timer value to compensate for 2 ticks loss while timer values are updates. I wanted to ask is the compiler would do it automatically for me or do i need to add the 2 my self.

Regads
teekay_tk

[Haplo]

You will have to do it yourself.

[teekaytk]

thanks,
one more questioin please, timer1 in PIC18f252 set to 65460 in CCS should give a 100 micro sec (at24MHz (6Mhz+pll)) but it gives me like 110micros, any say in this, if you wish i would post the code

[Haplo]

How are you measuring that 110us?

Yes posting the code always helps. Don't forget to use the 'Code' buttons.

[teekaytk]

i am measuring the 110 on digital oscilloscope (tektronix tds210)
the code is as follows . sorry for my crappy C. timer 0 is nested in timer 1

[Mark]

It is probably due to interrupt latency. It takes some time to process the interrupt. If you are setting the timer1 value inside the interrupt handler, that is your problem. You should add you value instead. The timer1 value should be at 0 when you are setting it. In reality, it is not. By adding your offset, you will compensate for the latency. I would use one of the ccp modules instead. Look up the compare feature.

[teekaytk]

thanks ali and mark. i could have done a ccp but i need to use this timer to later send data over the radio, not just 10101 pulses. un fortunately i have found out that this problem is shome how consistant with ccs , i used cc5x compiler that gave me quite accurate times as defined by formula , now i am porting the code to this compiler and seems that it is not consistant any more, there is a lag or lead of upto 8 cycles before presclaer. thanks anyway and i shall be grateful for a reply if any one has solved this problem

[Mark]

I guess you didn't read the first part of my post

[teekaytk]

thanks mark,
i went to assembler and found that it took 4 instructions to write to the register of timer1. that is a good starting point

thanks

[Mark]

You still aren't getting it! At the time of the interrupt, Timer1's value will be 0. The program branches to the interrupt vector. The compiler then saves its working registers and the status, w and so on. Now it must test which interrupt occurred. All this takes time. Probably about 10us from what you are seeing. When you finally get to setting timer1 its value isn't 0 as your code expects. You set timer1 to your count which loses the time already past! You need to add that value to timer1 instead of setting it. It will account for the latency if you do.

[teekay_tk]

hmm..ok, may i ask you one more thing, is this delay variable or fixed? i seem to get a range of delays at different presaclars and different values of timers? also the delay is either negative or positive?

[Mark]

Since the delay is actually in machine cycles, then different prescalers will cause different delays. Is it variable or fixed? Yes If you are not currently servicing an interrupt and you do not disable interrupts (or the compiler is not disabling them) and the interrupt is first in the priority list, then the delay is pretty constant otherwise it could change a bit. However, by adding the timer preset value to the timer value, the average time should always be 100us unless the delay exceeds 100us in which case you would miss that int.