Lpc2000

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 08:03 PM 10/11/04 +0000, you wrote:
> 
> 
> >...Or am I doing something wrong?
> No answers, only questions.
> 
> You are running at full speed, ie MAM fully enabled, a divisor of 1 
> on the peripheral bus?

External clock is 10MHz, PLL is enabled and multiplies this to 60MHz. 
MAM is enabled and MAMTIM is set to 3. VPBDIV is set to 1. As far as 
I can see, the core is working at 60MHz (e.g. baud rate divisors work 
out as expected for this value). Interestingly, I tried clocking TC 
at this rate (i.e. one count every 16.7ns) with appropriate MR 
values. The problem I've outlined was much much worse i.e. interrupts 
were lost almost immediately.



> Have you measured how long an interrupt takes?  IE done something 
like 
> toggle a pin at the beginning and end of your dispatch routine?  If 
> possible I'd consider generating assembly from the C and inserting 
the pin 
> toggle as close to the start and end of your interrupt as 
possible.  I'm 
> wondering if latency or simple overhead and execution time isn't a 
part of 
> the issue.

That's what I initally thought. However, the final code only takes 
around 2us to action ANY of the various events. Assuming ALL events 
occur simultaneously, I could get a maximum of 6us latency (give or 
take!). The sample code I posted also exhibits the same behavior and 
it is very minimalistic (I didn't measure the various execution paths 
but I would be surprised to see any event taking much longer than 1us 
to process). Also, my bit bashed port with the clock stopping 
workaround is very reliable at 9600 bps full duplex and passably so 
at 19k2 full duplex. This wouldn't be the case if my event processing 
was taking a long time.


I think your previous post hit the nail on the head - when there are 
simulataneous accesses to an interrupt register, it does not 
accurately reflect what's happened. 


> One of the reasons I'm asking is I did some measurements on timing 
(polled, 
> no Interrupts) and found that the smallest time period I could 
effectively 
> wait for was about 11uS.  That obviously included overhead but your 
> routines will too.  If your timing was similar (and I would naively 
expect 
> it might be faster) then that would give an overhead of 44uS if all 
four 
> happened at the 'same' time.  That's close enough to your 52uS 
cycle time 
> that I'd want to check how long it was actually taking.
Hmmmm.... It still shouldn't miss events though!


> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to
> chew a radio signal. "
> 
>                          Kelvin Throop, III