Lpc2000

On 1 Mar 2005 at 16:44, Robert Adsett wrote:

> 
> At 10:35 PM 3/1/05 +0200, Anton Erasmus wrote:
> 
> >On 1 Mar 2005 at 13:55, Robert Adsett wrote:
> > > At 07:35 PM 3/1/05 +0200, Anton Erasmus wrote:
> 
> <snip>
> 
> > > >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.
> 
> OK, I understand now.  I would have done it as a single fast timer
> interrupt portion and put both the slow portion and the background
> portion in a state machine in non-interrupt mode.
> 
> A thought occurs to me inspired by the thread on SWI and VICSoftInt. 
> You could (depending on what other interrupts you may be using)
> restructure this in a cleaner way.
> 
>          - Move the timer interrupt to the FIQ
>          - Put the slow portion in a standard interrupt vector
>          controlled 
> by the VIC (ie standard IRQ)
>          - Leave the background task as is
>          - Now when the FIQ fires it will preempt any IRQ (if
>          running).
>                  * in the FIQ perform the high priority task as before
>                  and 
> then use VICSoftInt to trigger the IRQ based interrupt if the flag is
> set appropriately.
>          - In the IRQ perform the low priority task with flag setting
> around it.
> 
> If you don't care about an immediate re-trigger of the low priority
> task you could eliminate the flag communication between the two
> interrupts.  If you do care a little attention would need to be paid
> to the potential for race conditions.  I did something similar to this
> on an ST10 when I needed to change the priority of an interrupt (to
> allow it to be interrupted) on the fly.
> 
> I think that would work.  It's been a while since I read up on
> VICSoftInt so it's a bit of a throw-away suggestion.

I had thought about using a FAQ + IRQ. This should work fine for two levels.
The problem is that as soon as one needs more than 2 levels, one will  have to
use nested IRQs or FIQs. I have found this sort of multi-level interrupt structure the
easiest to implement on Motorola processors. They seem to put a lot of effort into their 
IRQ architecture. And so far the only app note I have found on nested interrupts on the
ARM, is for the Freescale ARM series of MCUs. Unfortunately so far I have been 
unable to find the code that goes with the app-note. I have found some documentation
about this from ARM, but it is for use with their compiler which currently provides much
better interrupt support in C than gcc. 

Regards
   Anton Erasmus
-- 
A J Erasmus