Lpc2000

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> At 08:52 PM 1/21/05 +0000, you wrote:
> >--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> > >
> > > Nope, the interrupt is cleared when you read the identification 
> > register so
> > > that won't work.
> >
> >  If you don't read the identification register then it will work.  That
> >  is my premise.  The only way that you do clear the interrupt is to write
> >  to the THR.  Since I know why I got the interrupt, I don't need to
> >  identify it by reading the identification register and then I can use
> >  that to keep the interrupt alive till more data becomes available.
> 
> 
> What about all the other interrupt sources?  Are you doing transmit only? I 
> would consider that an unusual case but it might work then.  If you are 
> dealing with both transmit and receive (or any of the other serial 
> interrupt sources) though you mist read the IIR, if for no other reason 
> than to clear the interrupt.

 I'm just sending a data stream to an LCD which never talks back so the
 interrupt only comes from the transmitter.  Which gives me the option of not
 having to check the IR.  Although the LSR is an option to avoid IR.

> 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.
 
> 
> > > Um, if you write any number of bytes to the FIFO it will clear THRE until
> > > all bytes in the FIFO have been sent.  If you check THRE after putting the
> > > first byte in and exit you effectively eliminated the FIFO.   There is no
> > > indication on the UART of the send FIFO status other than empty and not 
> > empty.
> >
> >  Actually in my transmit loop I checked the THRE bit before I wrote to the
> >  THR because I was having data loss problems.  As it turns out, this way 
> > I was
> >  able to send 5 bytes before the THRE bit cleared.
> 
> Apparently the fill routine is faster that the UART state machine :)

 It is probably tied to the transmit clock which is slower than the
 processor clock.
 
> 
> >  Then after reading your post
> >  I tried to send the full 16 without checking and that worked.  The place 
> > I have
> >  to check is in the other routine where I kick the transmitter.  In pseudo
> >  code:
> >   timer_interrupt()
> 
> UART_interrupt maybe?  It doesn't make sense to me labelled as timer given 
> your following comments.

 Uh, whoops, too many interrupts on the go!  I'm using the timer for another
 sensor, but that might end up as another thread.
 
> 
> >     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.   The other_code() puts data into
 the software queue and then it checks to see if the THRE is set.  If it is
 not set then the interrupt is running and things are fine.  If it is set
 then the interrupt has run empty and is not running and then it is ok to
 transfer one byte from the software queue to the fifo to restart the interrupt.

> 
> The key to this is getting the disabling done in the proper places so that 
> the only way you send to the UART manually is if the interrupt will no 
> longer send and the flag to send manually will always be set if the 
> interrupt will not respond unless you send manually.  I hope that is 
> somewhat understandable.
> 
> Worse I can see this working by accident and failing when the right 
> combination of parameters hit and the phasing of various signals change.
> 
> 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.
 
 Rob