Extending Input Capture using timer overflow.

[jgirard1]

Does anyone have experience extending a timer using the overflow interrupt, say to 24 or 32-bits and beyond?

I am using the HCS08 TPM modules.  I have never done this and I am concerned about any pitfalls.

One concern would be using the timer within a non-related interrupt just before or after the overflow occurs, and then having a discontinuity problem.  If I am in an interrupt then I won't be able to service the overflow interrupt to increment the extending count unless I unmask the interrupts temporarily, but this could have other undesirable affects.

I don't want to add a bunch of strange code to get this to work.

What I'm trying to accomplish is extending the Input Capture to 24-bits.  I need the fine sub-microsecond accuracy, but I also need the extended time of up to 250ms.

Any insight or experience that anyone can share would be great.  Thanks.

[jgirard1]

Does anyone have experience extending a timer using the overflow interrupt, say to 24 or 32-bits and beyond?

I am using the HCS08 TPM modules.  I have never done this and I am concerned about any pitfalls.

One concern would be using the timer within a non-related interrupt just before or after the overflow occurs, and then having a discontinuity problem.  If I am in an interrupt then I won't be able to service the overflow interrupt to increment the extending count unless I unmask the interrupts temporarily, but this could have other undesirable affects.

I don't want to add a bunch of strange code to get this to work.

What I'm trying to accomplish is extending the Input Capture to 24-bits.  I need the fine sub-microsecond accuracy, but I also need the extended time of up to 250ms.

Any insight or experience that anyone can share would be great.  Thanks.

[bigmac]

Hello,

I will assume that tor each TPM overflow interrupt, a 8-bit or 16-bit counter is incremented, and the overflow flag is cleared.

The primary issue is that the input capture event is not subject to latency, whereas the overflow event processing will be subject to some degree of latency.  The question then arises whether, because of this latency, the counter value should be further incremented or not, for the calculation of the period.

If the overflow interrupt has not yet been processed, at the time when the input capture event is processed, the additional increment will possibly be required.  If the overflow flag is tested within the capture ISR, this will show if there is an unprocessed overflow event.

We then need to determine whether the unprocessed overflow occurred prior to, or after the capture event.  If the capture value is "high", this wouldl indicate capture prior to the overflow.  If the capture value is "low", this would indicate that the counter should be further incremented.  The low threshold might conceivably be any capture value less than 0x8000, which should allow plenty of scope for any latency.

Regards,

Mac

[rocco]

Hi Jgirard,

Yes, I have been doing this since 1985. It really is pretty easy, but there are rules that I need to follow.

First, I allocate one or two bytes of page zero ram for the timer-extension. I have a timer-overflow ISR that increments the extension (either a single INC instruction or three instructions), and also queues an overflow task to run (a single BSET instruction). That task may or may not do anything, but I schedule it anyway. Typically, it just keeps time.

Most of the time I am using the timer with the compare function, which allows me to schedule tasks up to 2.38 hours into the future (with the old HC05 timer at its fixed 2 microsecond resolution, ~8 overflows per second). Usually, a single byte of extension is adequate for me. At a 10mHz count rate, a single byte will get you 1 2/3 seconds before a single-byte timer-extension overflows.

Input-Capture is trickier, as the edge interrupt has a higher priority than the overflow interrupt. If you tried to process your capture totally inside the ISR, you could have a coherency problem. My "rule" of processing outside of the ISR addresses that issue.

Here are some of the rules that I need to follow:

No interrupt service routine may take longer than 5 microseconds. This is to insure that interrupt latency stays reasonably short. 5 microseconds allows me to run two SCI modules at a megabit/second.

All ISRs do only what it takes to clear the interrupt, and then request a processing task to do the bulk of the work (again, a single BSET instruction). So almost all processing is done outside of ISRs where interrupts are enabled.

No decisions are ever made inside an ISR, where things might not be coherent.

Any variables that are accessed inside an ISR are treated as critical-sections outside the ISR. That simply means that interrupts need to be disabled during their accesses (typically for less than a microsecond). Again, for coherency.

With those rules you can be assured that, should an overflow and a capture occur near simultaneously, both ISRs will have been executed before you process the capture (outside any ISR). You still need to determine which event happened first, and I use the high-bit of the 16-bit capture data to make that determination.

This is simply how I do it. There are plenty of other ways. This way is very easy for me because I have had the code for years and I program in assembly language. It would probably be more difficult in C.