At 09:38 AM 1/21/05 +1000, you 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.
You they re-occur to you let us know, I can't think of any conditions that
shouldn't be dealt with without needing a watch process.
>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.
Remember the FIFO has no indicator of being partially empty. So if you
check after sending 16 bytes to the FIFO and it indicates empty then it's
sending as fast as you can put them in. If that's the case why run a
transmit interrupt? Just poll the darn thing it will be less overhead.
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, IIIMessage
Re: [lpc2000] transmit interrupt kicker
2005-01-21 by Robert Adsett
Attachments
- No local attachments were found for this message.