Lpc2000

At 08:49 AM 1/21/05 +0000, you wrote:
>  --- In lpc2000@yahoogroups.com, Peter Jakacki <peterjak@t...> wrote:
> > Yeah, you'd think that the transmit routine would be simple hey? As Rob
> > brought out, you have to kick it. Usually I do this by a separate
> > polling routine called from a timer interrupt. It checks the queue and
> > the UART and decides whether it needs to load up the UART. Mind you, I
> > *still* check to see if I need to kick it from my queue filler such as
> > when the first character is transmitted etc. But there are conditions
> > where the micro won't detect that the transmitter is ready (I'm trying
> > to think why now, but funny things happen). Anyway, the polling routine
> > also checks for receive lockups/timeouts etc, so it's a good idea and
> > also good practice.
>
>  When you get down to it, there are always a few skellies lurkin.
>
>  Interrupts are always such tricky stuff because you can
>  be in the middle of doing anything when these things
>  go off.  After posting and pondering, here's a thought
>  experiment that might work:
>
>  Start up the UART in loopback mode (via the MCR) and
>  then write two initial bytes to create the initial transmit
>  empty interrupt.  Then set to normal mode and when the
>  interrupt is serviced, it can only clear the interrupt by writing
>  more characters to the hw fifo.  If no more characters
>  are to be sent, then instead of clearing the interrupt, block it.
>  When data is put into the software queue, then unblock the
>  interrupt and the interrupt routine will do the transferring.
>  This creates harmonious asynchronous threads and a simple
>  on/off switch for the transmitter.

Nope, the interrupt is cleared when you read the identification register so 
that won't work.


>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> >disable interrupts
> >transmit()
> >restore interrupts
>  When working with interrupts, as a general rule I try to
>  write code that does not require blocking other interrupts.

Fair enough, that was just a general outline of what was required.

>  In the switch case if the switch gets turned on as a
>  result of a contention of writing to the register, then the
>  interrupt will just recognize this as a known condition and
>  handle it.  In the case that switch is turned off accidentally
>  with data to send, then the next data will clear it.  But it
>  could introduce a fifo empty period.  Since the interrupt
>  routine is the only one that can turn off the interrupt, it
>  must write the register just after it was set to on for data
>  in the software queue.  But if the software queue is written
>  first and then the switch is turned on, then the interrupt
>  routine would have already transferred data to the hw fifo
>  so it would be ok because the interrupt had already been
>  there,... before the other routine had finished.  So that is
>  ok 2.

Huh?  I don't understand what you are getting at.  The interrupt protection 
is there to protect access to the SW queue.  What switch are you referring to?

>--- In lpc2000@yahoogroups.com, Peter Jakacki <peterjak@t...> wrote:
> > BTW, especially at higher baud rates it's advantageous to have the
> > transmit interrupt handler loop and check the queue again before
> > exiting. This way it keeps the transmit fifo filled and makes for more
> > efficient operation. If the interrupt handler routine has a high
> > overhead it might even pay to "tread water" in the handler, timing out
> > if  the UART is not ready yet. This is can be very beneficial when
> > operating at higher baud rates as the handler can empty the queue in one
> > tight burst.
>
>  Initially I didn't even check the status of the fifo to see how many I could
>  stuff in there and just wrote 16 each time.  This worked ok under low
>  loading but failed under high loading.  So I added a quick check to see
>  if the fifo was ready (THRE) and finished the interrupt if it wasn't ready
>  or if 16 had been sent.  I thought about putting in a wait loop as you
>  suggested but that stretches the interrupt and I'm not sure of how
>  much time that might end up costing.  In the worst case, 15 could be
>  queued but the 16th would have to wait for the other 15 @ 230400 is
>  about 650us!

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.


Robert