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 >
Message
Re: PWM width detection
2006-02-20 by brendanmurphy37
Attachments
- No local attachments were found for this message.