serial_putc() to make better use of Tx FIFO

[adamgreen]

If don't know if this is an issue that anyone cares about. I am also
not sure what the best way to solve it is either. I just thought I
would issue a pull request with this commit to bring the issue to light
and show a possible solution that I have tested on my mbed-1768 device.

Previously the serial_putc() API didn't make any use of the Tx FIFO
since the serial_writable() API it utilizes only returns true when the
FIFO is completely empty. This is due to the fact that the THRE bit of
the UART's LSR (Line Status Register) only goes high when the whole
FIFO is empty.

I noticed this when doing some performance testing with the network
stack. I went from calling printf() to output 3 bytes every 10 seconds
(with packet drop stats) to instead output 4 bytes every 10 seconds.
I thought these should easily fit in the 16 byte FIFO but outputting
one extra byte caused an additional three 550 byte UDP packets to be
dropped. This should only happen if the additional character being
sent to the UART was taking away extra CPU cycles from the network
stack.

My solution is to keep track of the number of bytes that have been
placed in the Tx FIFO since it was last detected as being completely
empty (via the THRE bit). Only once this count hits 16 does the code
then block, waiting for the THRE bit to go high. Each time the THRE
bit does go high, the count is reset to 0 again and it is incremented
for each byte that is loaded into the THR.

[adamgreen]

I don't see anything in the LPC17xx User Manual (UM10360) that makes me think that the transmit path works as you describe in that scenario. If I look at the Fig 47. UART0, 2 and 3 block diagram in section 14.5 Architecture of that manual, the FIFO feeds into the Transmitter Shift Register and not the THR. However, I would be the first to admit that that diagram makes it looks like the THR is separate from the Transmitter FIFO but my recent experience with the LSR.THRE would indicate that they should be considered as one entity. The following text from the manual which just precedes this diagram describes the THR and the FIFO as being one:

The UARTn transmitter block, UnTX, accepts data written by the CPU or host and buffers the data in the UARTn TX Holding Register FIFO (UnTHR). The UARTn TX Shift Register (UnTSR) reads the data stored in the UnTHR and assembles the data to transmit via the serial output pin, TXDn.

You do ask a very important question though:

One question here: do we know for sure that LSR.THRE is 0 as long as there is data in the FIFO?

The one thing that makes me think that THRE only goes high when the FIFO is completely empty is the fact that THRE can be used to trigger an interrupt as well. If this interrupt triggered, an application would expect to be able to fill the FIFO with 16 bytes and not lose any of them. To me, it is actually this interrupt scenario that allows LSR.THRE's behavior to make any sense. It's behavior is very confusing in our current polling situation where we really just want to know if we can safely place another byte in the transmit FIFO. However, in the case of an interrupt handler, knowing that the FIFO is completely empty when the interrupt fires is exactly what it wants to know.

Maybe you could ping NXP?

[bogdanm]

I'll post a question on the lpc2000 mailing list (http://groups.yahoo.com/neo/groups/lpc2000/info) (after checking if it wasn't already answered), which is a very good resource for NXP ARM chips. If that fails, I'll try to contact NXP.

[mbednotifications]

On Wednesday, September 11, 2013 8:08:09 PM UTC-4, Bogdan Marinescu wrote:

The one thing that makes me think that THRE only goes high when the FIFO
is completely empty is the fact that THRE can be used to trigger an
interrupt as well. If this interrupt triggered, an application would expect
to be able to fill the FIFO with 16 bytes and not lose any of them. To me,
it is actually this interrupt scenario that allows LSR.THRE's behavior to
make any sense.

The THRE interrupt on the LPC43xx MCUs is triggered when the transmit
holding register becomes empty. The same probably applies to other LPC
MCUs. If the register is empty when the interrupt is enabled, an interrupt
will not be triggered. Applications sending data using THRE interrupts
should start transmitting if the transmitter (LSR) is available when the
interrupt is enabled. The interrupt should be disabled after the data
transmission is finished.

[bogdanm]

I've merged this pull request manually. Sorry it took so long.