Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: PWM width detection

2006-02-20 by brendanmurphy37

Al,

You're right in most circumstances. However, anyone reading this 
needs to be aware that the LPC2xxx parts, like many other 32-bit 
micros with pipelined architectures and multiple (internal) buses, 
are not quite as straightforward as previous generation micros. For 
example, the "1 instruction cycle to flip the bit sense" you refer to 
will actually take multiple clocks, due to the latency of the 
peripheral bus.

Interrupt latency is also not straightforward to work out, as it will 
include some or all of:

- delay to due to background software disabling interrupts
- variable instruction execution delay (ARM is not very "RISC" like 
in this respect, due to extended instructions such as load multiple)
- variable hardware interrupt acknowledgement delay
- software delay in saving additional context and calling correct ISR

If your interrupt software isn't set up to handle nested interrupts, 
there can be even longer delays.

I'm not suggesting you're incorrect or wrong in anything you say, but 
it's important for anyone new to the parts to keep in mind all of the 
above before implementing a particular solution. If you're happy that 
after doing the analysis that the timing is OK, then fine. However, 
don't skip the analysis, particularly if you're planning to respond 
to "fast" events. 

One thing you find is that it is very hard to guarantee to respond at 
a very precise time after any interrupt: there is usually quite a bit 
of jitter involved. In most cases, such as flipping the direction of 
a capture i/p "somewhere" in an ISR this won't matter, but in others 
it will.

Brendan

P.S. there's been plenty of posts to the forum on exact timings of 
peripheral bus access and interrupt latencies: this is just a 
reminder that they exist, rather than a repeat of the actual data 
involved.

--- In lpc2000@yahoogroups.com, Onestone <onestone@...> wrote:
>
> The 'standard' way to do this is to use 1 pin. ISR latency on slow 
small 
> micros is usually more than fast enough. On an LPC it should be a 
shoe 
> in. 1 instruction cycle to flip the bit sense. How hard can it be. 
A 
> typical ISR to measure pulse width on most micros requires fewer 
than 10 
> instructions. Your final sentence may be true, but this is the case 
in 
> 99% of applications, and is certainly true in your case, even with 
the 
> comparatively poor interrupt latency of the LPC2xxx. On the odd 
> occasions where the pulses are too fast I would suggest that using 
two 
> pins is a poor solution anyway, since the resolution of meaurement 
will 
> only be typically 2-4 bits at most, and other solutions would offer 
a 
> better result.
> 
> Cheers
> 
> Al
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.