Lpc2000

On 1 Mar 2005 at 13:55, Robert Adsett wrote:

> 
> At 07:35 PM 3/1/05 +0200, Anton Erasmus wrote:
> 
> >On 28 Feb 2005 at 16:04, Robert Adsett wrote:
> >
> > >
> > > At 10:15 PM 2/28/05 +0200, Anton Erasmus wrote:
> > > >Does anyone have some example code for gcc for a nested timer
> > > >interrupt ? I have googled a bit, and have found some discussion
> > > >regarding the switching of modes from interrupt mode to system
> > > >mode before re-enabling interrupts.
> > >
> > > Before you go too far make sure you've read the timer race
> > > conditions errata.
> >
> >I am using the LPC2292, and there is no mention in the LPC2292 errata
> >regarding timer problems.
> >http://www.semiconductors.philips.com/acrobat/erratasheets/2292.pdf
> >Can you maybe point me to the specific errata sheet that describes
> >this ?
> 
> Take a look for Timer_issue.pdf in the files section (I'd post a link
> but that seems problematic).  I think this has not made the actual
> errata sheets yet and AFAIK has not been addressed in any of the new
> devices yet (that was certainly the case when I asked about the 213x).

Thanks, I will have a look.

> >The idea is to set up a periodic interrupt of x milli-seconds. After
> >the interrupt has been acknowledged, interrupts are enabled again. If
> >an overrun occurs, the interrupt routine will be interrupted, and I
> >can then detect this and take appropriate action as neccesary.
> 
> You expect the timer interrupt to take multiple milliseconds?  That's
> a pretty busy interrupt routine.  I'll take some measurements of the
> SPI interrupt I'm working on if you'd like a time comparison.

Yes, my main application actually runs in the timer interrupt. 
Typically I use a periodic interrupt rate of 2ms. My high priority code
then executes every 2ms. This code must not take more than about 1ms
on average, and NEVER the full 2ms. After the "fast" code executes, I re-enable
interrupts, check a "slow-code" flag, and if not set, set the flag and start executing
the slow code. This code can then be interrupted by the 2ms interrupt, so that
the fast code always executes. When the interrupt returns, the "slow-code" continuse
to execute. The slow code can take up multiple 2ms cycles as needed. When the
slow code returns, it disables interrupts and returns back to the "main" code, which
in my case is just used for background debugging and Built-in-test code.


> Hmm, I did some performance measurements on a polled timer for the
> lpc-newlib support.
> http://www.aeolusdevelopment.com/AppNotes/LPC210X/an-timerperformance.
> pdf
> 
> microsecond resolution, 12 microsecond minimum time, keeps track of
> time as long as it's polled at least once every few minutes.  The 12
> microsecond time is the overhead required to deal with various
> overflow, underflow and scalings so it's doing a fair amount of work. 
> I wouldn't expect even a fairly busy timer routine to take the two
> orders of magnitude longer that would be required to overflow a
> multi-millisecond timer.

As can hopefully be seen from my explanation above, I do not use
the timer interrupt to time thing per-se. I use it to implement a simple
shedular where I can garauntee that portions of my code WILL execute
every 2ms. I can then add debugging stuff, and user interfacing etc.
in the background without affecting my main application timing.
This approach has worked remarkably well on every CPU I have used except
the 8051.

Regards
  Anton Erasmus


-- 
A J Erasmus