Lpc2000

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