Does anyone have any code examples of how I can use a LPC2138 to detect 
the width of the positive pulse in a PWM signal. I know I can use the 
timer circuit and detect the rising and falling edges do some math and 
determine the width. I am very new to micro controllers and some code 
examples or guidance would be greatly appreciated.

Thanks
J Parham
	

Hi J,

> Does anyone have any code examples of how I can
use a LPC2138 to detect
> the width of the positive pulse in a PWM signal. I know I can use the
> timer circuit and detect the rising and falling edges do some math and
> determine the width. I am very new to micro controllers and some code
> examples or guidance would be greatly appreciated.

For some theory take a look at this Atmel application note:
AVR135: Using Timer Capture to Measure PWM Duty Cycle   (12 pages, revision
A, updated 10/05)
Found here: http://www.atmel.com/dyn/products/app_notes.asp?family_id`7

As for the LPC2100 you would use the Capture feature of the Timer
peripheral.  Setup timer to generate an interrupt on capture pin leading or
trailing edge.  In the interrupt routine read the capture register value and
pass it on to your algorithm.  

Be sure to read the correct section of the errata sheet related to TIMER.
	Joel
	

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
	--- In lpc2000@lpc2..., "Joel Winarske" <joelw@...> wrote:
>
> Hi J,
> 
> > Does anyone have any code examples of how I can use a LPC2138 to
detect
> > the width of the positive pulse in a PWM
signal. I know I can use the
> > timer circuit and detect the rising and falling edges do some math and
> > determine the width. I am very new to micro controllers and some code
> > examples or guidance would be greatly appreciated.
> 
> For some theory take a look at this Atmel application note:
> AVR135: Using Timer Capture to Measure PWM Duty Cycle   (12 pages,
revision
> A, updated 10/05)
> Found here:
http://www.atmel.com/dyn/products/app_notes.asp?family_id`7
> 
> As for the LPC2100 you would use the Capture feature of the Timer
> peripheral.  Setup timer to generate an interrupt on capture pin
leading or
> trailing edge.  In the interrupt routine read the
capture register
value and
> pass it on to your algorithm.  
> 
> Be sure to read the correct section of the errata sheet related to
TIMER.
>  
> 
> Joel
	

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
>
>
>--- In lpc2000@lpc2..., "Joel Winarske" <joelw@...> wrote:
>  
>
>>Hi J,
>>
>>    
>>
>>>Does anyone have any code examples of how I can use a LPC2138 to
>>>      
>>>
>detect
>  
>
>>>the width of the positive pulse in a PWM signal. I know I can use
the
>>>timer circuit and detect the rising and falling edges do some math
and
>>>determine the width. I am very new to micro controllers and some
code
>>>examples or guidance would be greatly appreciated.
>>>      
>>>
>>For some theory take a look at this Atmel application note:
>>AVR135: Using Timer Capture to Measure PWM Duty Cycle   (12 pages,
>>    
>>
>revision
>  
>
>>A, updated 10/05)
>>Found here:
>>    
>>
>http://www.atmel.com/dyn/products/app_notes.asp?family_id`7
>  
>
>>As for the LPC2100 you would use the Capture feature of the Timer
>>peripheral.  Setup timer to generate an interrupt on capture pin
>>    
>>
>leading or
>  
>
>>trailing edge.  In the interrupt routine read the capture register
>>    
>>
>value and
>  
>
>>pass it on to your algorithm.  
>>
>>Be sure to read the correct section of the errata sheet related to
>>    
>>
>TIMER.
>  
>
>> 
>>
>>Joel
>>    
>>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>
	

> 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

Yes.  I have a design using six capture inputs doing bit banged CAN bus on
the LPC214x.  Polarity is being conditionally flipped in ISR.  It's been
rock solid.  

If IRQ latency is a problem, and timing permits you can always implement as
FIQ.
	Joel
	

> > 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
> 
> Yes.  I have a design using six capture inputs doing bit banged CAN bus on
> the LPC214x.  Polarity is being conditionally flipped in ISR.  It's
been
> rock solid.

I should mention it uses one capture pin per bus.
	Joel
	

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@lpc2..., 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
>
	

Hi brendan,  I am aware of the latencies with the LPC, especially the 
over discussed slow I/O issues. I am also aware of the odd interrupt 
latency issues (for a supposed RISC machine), but promoting them touse 
the FIQ ISR helps resolve some of these issues. Knowing the exact isr 
latency isn't really an issue in timer capture for pulse timing, as long 
as the ISR is taken and completed before the next edge to be detected, 
since the time of the event is stored, like time travel backwards, and, 
since the post I responded to discussed 1ms/20ms remote control signals 
ISR latency and single pin handling certainly wasn't going to be an 
issue. I do appreciate that the LPC is not really a conventional 
microcontroller, more like a microprocessor with the extra hardware 
kludged into the same silicon.

Thansk for the reminders though

Al
	brendanmurphy37 wrote:

>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@lpc2..., 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
>>
>>    
>>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>
	

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@lpc2..., 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
	

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@lpc2..., 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
>
>
>
> 
>
>
>
>
>
>  
>