LPC2138 timers

controller.

captured

between

a new

Surely that will introduce a error due to the interrupt latency. Shouldn't you be subtracting the previous capture value leaving the time to free run?

you

not

You shouldn't need to reset the timer at all. You want it to keep going so that the results are entiely based on hardware timing without and latency issues (except to respond to the interrupt before the next capture is expected).

Peter

Hi Peter,

thank you for the idea. If the timer was used only for measurement, it would work I guess. However, the timer is also used as timeout timer (if for a long period no edges are detected a timeout occures). I could manually detect if the timeout period is elapsed, but this should be done outside the interrupt service routine. Anyway, automatically reset the timer would be the best solution, but I am afraid it isn't possible?!

Frank

service

I have a similar situation. (With a different processor.) In my case, the precision required for timeout detection is much lower than the one used to measure time intervals. So I use another lower repetition timer in my system to detect timeouts as follows:

In the ISR for edge detection, reset the "edge" timeout counter every time.

In the lower resolution timer ISR, increment the edge timeout counter and declare a timeout if a limit is exceeded.

controller.

captured

new

From the datasheet:

• Four 32-bit capture channels per timer/counter that can take a snapshot of the timer value when an input signal transitions. A capture event may also optionally generate an interrupt.

If a snapshot of the timer is taken, doesn't the timer continue to run? If it does, no need to reset the timer, just subtract the previous reading from the current CAP reading using the same data width as the CAP register for the math.

~Dave~

so

latency

would

long

if the

service

but I

So use two timers. Don't reset the input capture one but reset the timout one. That way you'll get both the timeout and the timing to the nearest clk.

Peter

going

solution,

clk.

Alternatively, if the timer supports capture and compare then update the compare value to be capture_value+timeout (modulo timer size) in the capture interrupt. You should only get a compare interrupt if no edge has occured during the timeout interval.

Peter

controller.

captured

between

new

The timer does continue to run, but if you looked at the previous posts, you can see that I use it also as timeout timer. So each interrupt the timer has to reset (or the timeout occures while I still receive edge interrupts within time).

Frank

controller.

captured

between

new

The timer does continue to run, but if you looked at the previous posts, you can see that I use it also as timeout timer. So each interrupt the timer has to reset (or the timeout occures while I still receive edge interrupts within time).

Frank

It is supported and a good solution I think, because I already use a second timer for other purposes. So no timers left anymore.

Thanks for your suggestions, Frank