Lpc2000

At 10:45 PM 1/21/05 +0000, you wrote:
>  I'm just sending a data stream to an LCD which never talks back so the
>  interrupt only comes from the transmitter.


Ah, that does allow you to explore specialized solutions.

> > OK, that's just a disable and restore interrupts.  You should check 
> some of
> > the earlier threads in the archives, there was a discussion about spurious
> > interrupts occurring under this kind of scenario.  I've forgotten the 
> exact
> > details as to whether they occur in this particular scenario or not.
>
>  Thanks for the reminder.  I remember that as well but so far I haven't
>  had any problems with that.  I should probably reread the erratta dox.


I don't think you will find it in an errata.  I doubt it's actually 
considered one.  Hmm, this should probably be added to the FAQ.


> >
> > >     send 16  \ no THRE check needed interrupt means 16 can be sent
> > >
> > >   other_code()
> > >     queue bytes in sw queue
> > >     send 1   \ THRE check needed as interrupt might also be active
> >
> > I'd have to see how you disable and enable interrupts here but I do see
> > danger areas.  In particular I can see the following; THRE flags interrupt
> > but before the interrupt can respond you disable interrupts (this is
> > essentially the core of the spurious interrupt issue), you then send a 
> byte
> > and re-enable interrupts.  The interrupt routine picks up and stuffs 16
> > bytes into a FIFO that only has room for 15.  Whether that's an issue and
> > how often it would show up if it is depends a lot on the details.
>
>  I don't disable interrupts with the above code.  I also ran some test cases
>  to see if I could get the THRE before it causes an interrupt and that never
>  happens.  So the above case can not occur.

You ran some tests, it didn't happen, therefore it can't occur?!!

That's a bit of a leap.  I wouldn't trust that without at least some 
underlying reason to believe it's true and preferably some 
documentation.  Even if I had some reason to believe it to be true I'd be 
suspicious and with the code to be sure being so simple ....

Avoiding race conditions on interrupts can be difficult enough without 
borrowing trouble.

And that avoids any questions about whether you can have issues with the 
queue itself due to race conditions.  No code but I'm assuming you've 
protected yourself there.

> > BTW this pseudo code is at odds with your switch commentary above.
>
>  The switch commentary is on a thought experiment not actual code while
>  the pseudo code is what I am currently crafting.


OK, the two were getting mixed up.

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