Lpc2000

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.

<snip>

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