Lpc2000

If the signal is too fast to be captured by a single capture pin, using 
the edge flipping method, then it is occuring faster than the capture 
ISR can execute, and reservice itself.  Assuming that the ISR is well 
written, executes in the absolute minimum possible time, ie no calls , 
no massive processing in the ISR, then the pulse  is obviously very 
short. having one edge captured by pinA and the other by pin B won't 
change this, in fact the nett time to execute and service the two 
routines will be shorter, typically, than the nett  time to service a 
single bit flipping routine, and the pulse, depending upon the processor 
of course, will typically be only a few counts long,  thus a few bits of 
resolution, and a limited dynamic range. In this case other methods 
would perform the task better.

With respect to noise in the system, this is where I believe system 
design enters the picture. In this case if the time is taken to learn 
the system before ever laying down hardware or software, and the 
vagaries of the signals are studied and understood first, not discovered 
to be a problem later, as seems to be the more common event, then they 
can be first of all minimised during the hardware design, then perhaps 
compensated for during the software design with signal or logical 
filters, or a combination.

Cheers

Al

Ryan Niemi wrote:

>Hi Al,
>
>Why would the capture resolution using two capture pins only be 2-4
>bits at most?
>
>One note on using an ISR for flipping the capture edge, this works
>fine if the signal you're capturing is not noisy..  Determinism in
>hard-realtime systems goes away anytime interrupts can be triggered by
>external noise.
>
>-Ryan
>
>
>--- 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
>>
>>Ryan Niemi wrote:
>>
>>    
>>
>>>I recently implemented pulse width measurement on an LPC2124 to detect
>>>the width of pulses from an R/C radio receiver (varies between 1ms and
>>>2ms positive-going pulse width) for a theatrical motion control and
>>>lighting control project.  There's an interesting shortcoming that I
>>>encountered, each capture pin can only capture a rising or falling
>>>edge, but not both.  So to measure pulse width, I found it necessary
>>>to use *two* capture pins tied together, one to capture the rising
>>>edge and another to capture the falling edge.  The main loop of the
>>>program compares the two, and if the count on the falling edge capture
>>>is larger than the count on the rising edge capture, then pulse_width
>>>= falling_edge_capture - rising_edge_capture.
>>>
>>>The Hitex book includes an example whose description says it measures
>>>a pulse width, but the example shown (using one capture pin) very
>>>clearly does not measure pulse width and is incomplete, and merely
>>>measures the time between pulses (but not the pulse width).  Now my
>>>curiosity is had, has anyone succeeded in measuring pulse widths
>>>without using multiple capture pins?  From the way the LPC capture
>>>units are set up, I doubt it's possible, short of flipping the capture
>>>edge polarity in an ISR.  ISR-based solutions are only really useful
>>>if the pulse width is larger than the execution time of the ISR + any
>>>interrupt latency due to other ISR's executing at the time.
>>>
>>>-Ryan
>>>      
>>>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>