PIC TMR0 adjustment - Trap for young players?

[igendel]

Hi,

While writing this, I have a feeling that the PIC programmer folk are snickering behind by back, but... 

I wanted to generate a 104us periodic interrupt on an 8-bit PIC (e.g. PIC12F675) using Timer0. The clock is the internal oscillator, effectively 1MHz (1us per instruction). Now, Timer0 can only generate an interrupt when its 8-bit counter, TMR0, overflows from 0xFF to 0x00 - meaning once per 256us, which is too slow for my requirements.

However, as the datasheet heartily suggests, we can write new values directly to TMR0. If we set TMR0 at the beginning of the ISR function to 152, it will only need 104 more cycles* to reach 0x00 and I'll have our desired 104us period.

* Yes, I know about the two-cycle count inhibition... let's ignore that for now

But here's the trap: try the above and you won't get 104us. It'll be closer to 125us. My understanding is that it's because there's a time gap between the interrupt event and the setting of TMR0: The MCU needs time to enter the ISR and run the instructions until the new value is in place. Makes sense, right? What's really weird for me is that I found no reference to this anywhere. Every online/offline "timer calculator" I tried, even Microchip's own "MPLAB Code Configurator" that generates code for you, makes the mistake of ignoring this time gap (I tested it on a PIC12F1840). Is everyone's timing off by ~20 clock cycles? Can anyone provide some feedback on this finding?

Thanks!

[ludzinc]

Yep

Been there, empirically done that.

There's overhead to account for. Either calculate or measure.

I measured it, found it repetable across multiple devices (100 or so) and called it done.

[dannyf]

you won't get 104us. It'll be closer to 125us.

Something is at work here.

Generally, don't write to TMR0.

If you have to, use increments:

Code: [Select]

  TMR0+=-PERIOD; //load offset

However, you will likely see a small error that way, as the value of TMR0 will continue to increment as its value is being modified.

As to ISR overhead, it only impacts the very first period. After that, the same overhead is applied to consecutive ISR invocation so your timing (since the last invocation) is the same.

[igendel]

Generally, don't write to TMR0.

 

If you have to, use increments:

Code: [Select]

  TMR0+=-PERIOD; //load offset

However, you will likely see a small error that way, as the value of TMR0 will continue to increment as its value is being modified.

That does make sense.

As to ISR overhead, it only impacts the very first period. After that, the same overhead is applied to consecutive ISR invocation so your timing (since the last invocation) is the same.

I'm not sure I understood this one... indeed there's the same overhead each time, so each and every period is off by that overhead; if I set TMR0 to 152, the next interrupt will be triggered after 104us, but will still require the extra time until I can actually set TMR0 again.

[dannyf]

let's say the ISR overhead is 20ticks / 20us.

So 20 ticks after the TMR0 overflows, your ISR is executed; In your case, another 104us - 20us later, your TMR0 overflows, and 20us later, your ISR gets executed again.

The time between the two invocations is 104us - 20us + 20us = 104us.

The ISR overhead doesn't matter.

Going back to TMR0 offset, if you really want to get your timing right, do this:

Code: [Select]

  TMR0+=-PERIOD+TMR0_ERROR;

where TMR0_ERROR accounts for the time elapsed in modifying TMR0. Usually it is 2.

[dannyf]

Generally, don't write to TMR0.

The problem gets more interesting when a prescaler is used on a fast signal.

[igendel]

So 20 ticks after the TMR0 overflows, your ISR is executed; In your case, another 104us - 20us later, your TMR0 overflows, and 20us later, your ISR gets executed again.

Right - if I adjust for PERIOD as you suggested. I thought you meant the setup I described at the beginning.

We should also be careful if we change the ISR (add another interrupt-source check before checking the Timer0 flag), or if we change the compiler (e.g. from free to pro).

[igendel]

The problem gets more interesting when a prescaler is used on a fast signal.

Heh, "Interesting" may not be the most accurate adjective here
What I still don't get is why this matter isn't mentioned anywhere (that I could find so far, anyway). It really is a trap, for instance if someone trusts the MPLAB Code Composer blindly.

[dannyf]

We should also be careful if we change the ISR (add another interrupt-source check before checking the Timer0 flag), or if we change the compiler (e.g. from free to pro).

Short of a caveat, none of that matters to the approach I gave earlier.

Where it fails is if the timer has advanced so much and / or the value of PERIOD is so short so that the operation caused an overflow.

[dannyf]

What I still don't get is why this matter isn't mentioned anywhere (that I could find so far, anyway).

It is well documented in the datasheet.

It really is a trap, for instance if someone trusts the MPLAB Code Composer blindly.

Well, that's the fault of the person who trusts blindly, either MPLAB Code Composer or anything else.

[igendel]

We should also be careful if we change the ISR (add another interrupt-source check before checking the Timer0 flag), or if we change the compiler (e.g. from free to pro).

Short of a caveat, none of that matters to the approach I gave earlier.

The approach will still work, but the PERIOD value probably won't be the same. We'll have to measure/cycle-count it again, right? Edit: No, I get what you're saying now 

It is well documented in the datasheet.

But in entirely separate sections, not as a single topic/discussion as far as I can see.

Well, that's the fault of the person who trusts blindly, either MPLAB Code Composer or anything else.

Yeah well, of course I won't build an application without testing each and every part of it - that's how I found this issue - but still, one would expect some minimal correlation between MCC-generated code and the user requirements... 

[dannyf]

one would expect some minimal correlation between MCC-generated code and the user requirements... 

Not sure. I would say generally no: the configurator's job is to provide you with building (code) blocks that you can assemble together for your application. It has no knowledge of your application and the responsibility has to reside with the user of such configurators to make sure that the generated code works to that specific application.

Putting too much faith in the configurator to get it right for your application is risky, as you have shown here.

[Bruce Abbott]

Every online/offline "timer calculator" I tried, even Microchip's own "MPLAB Code Configurator" that generates code for you, makes the mistake of ignoring this time gap

It's not a mistake. It's a well documented limitation of Timer0 that it cannot generate periodic interrupts with arbitrary timing. You can emulate it in software, but of course that will result in timing variations caused by the software overhead.

Is it a trap for young players? Yes, but only for those who think they can get away with programming a chip without knowing its features and limitations. The first step in working with any MCU should be to read the datasheet, so you know what it is capable of and how to use it.

Is everyone's timing off by ~20 clock cycles?

If they use that method then yes, their timing will be off. You can tweak the count to get close to the timing you want, but there is no guarantee that it will be single cycle accurate.  In many cases that is good enough. When it isn't you use a different method, eg. change the system clock to a frequency that gives the correct timing with a count of 256, or use a PIC which has a more advanced timer.

[Mechatrommer]

what compiler? have you looked at disassembled code? tracing from interrupt vector to where you set the TMR0?