UART Polling vs Interrupt

Question

I have two UART ports on an MSP430 that need to stream data between a Host Controller (Freescale IMX6) and potential devices that can be hooked up on the other side. The Host Controller communicates (read/write) data with MSP430 (including serial data from devices) over an I2C bus.

IMX6 --writes I2C--> MSP430 --writes `UART`0--> Device 0
IMX6 <---reads I2C-- MSP430 <---reads `UART`0-- Device 0

IMX6 --writes I2C--> MSP430 --writes `UART`1--> Device 1
IMX6 <---reads I2C-- MSP430 <---reads `UART`1-- Device 1

Currently, UART receives are interrupt-based on the MSP430. When a byte comes in, it interrupts the MSP and tosses the byte into a ring buffer.

UART writes, on the other hand, are polling-based. In my main loop, I have a UART_process that runs. In that process, I check if the UART TX hardware single-byte buffer is ready for a byte. If it is, I write in a new byte, set of the transfer, and exit the function. With this functionality, it could be (for example) 1 millisecond before I send out another byte to the UART device, even though the MSP's UART may have been ready to transmit another byte much sooner.

My concern is that if I have to manage 2 UART ports from the MSP430 that are both running at 115200 Baud, will writing a byte out every 1ms (potentially a little more or less) be sufficient for the device? The baud rate transmission will still be at 115,200 obviously, but the bytes will be streaming over slowly. Some quick n rough calcs:

• 1 bit @115,200 takes about 8µs.
• 1 byte @115,200 will take about (8µs * 8bits) = 64µs.

So as you can see, a new byte can be transmitted from the UART driver, let's say every 100 µs. If I'm sending a byte out every 1 ms, I'm not transmitting to the device very fast (about 1/10) compared to the potential max speed.

I don't want to transmit UART via interrupt, because I fear that 2 UARTS with both RX and TX being interrupt based could take over my CPU. I have other important things I am doing as well on the MSP430. Like constantly accepting I2C messages via interrupts and handling a timer interrupt based IR process.

I've considered adding a simple task scheduler. But that wouldn't do much to speed things up because I'd probably run the task scheduler at 1ms intervals. This would only guarantee a UART byte write every 1 ms (which was what I was proposing above anyway). The other option is to look into using the DMA with the UART transmit. But I only want to explore these options if I have to.

From your experience, will most UART devices/implementations be OK with receiving bytes at a slow rate compared to the Baud rate? Any general suggestions? Let me know if I'm being unclear on any points. Thanks!

Answer 1

Yes, most software that receives data over an asynch channel is agnostic to how fast the data arrives (up to the point where timeouts come into play). For the receiver, your situation is comparable to a baudrate that allows 1char/ms.

Answer 2

Interrupt based routines will not take over thr CPU unless you let them.

I've written many MSP430 uart drivers and the way to approach TX is to make the ISR send the bytes. Trigger the interrupt flag and then let the ISR manage sending the bytes from a buffer. You need a couple of variables in memory to manage this, but it works very well.

Remeber that it is you that trigger the ISR to send the data. You know how many bytes to send. The ISR is quite fast, so there isn't any taking over.

You are using polling which is in fact eating up your CPU time. No reason for this. Interrupts shouldn't be feared, they should be mastered.

You didn't mention which MSP430 you're using but I've been running many MSP430 based design with multiple interfaces and never had an issue with interrupts loading the CPU. In fact customers have been extatic that issues they had before due to polling and other things were gone when I re-architected them.

You mentioned RTOS. Depending on the MSP430 this might not be practical, and you don't need it. An RTOS won't solve these kind of issues.

Answer 3

I often use polling for transmission and interrupts for reception; whether that approach is adequate will depend upon what sort of buffering the UART has, and how your polling rate compares with the rate at which you actually need to send data.

Some chips have a UART which require that a byte be fully transmitted before code can load the next byte. Most chips allow the processor to load at least one byte in addition to the one which is presently being clocked out. Some may allow the processor to preload 16 bytes or even more.

If your port is set for 115,200 baud, your UART can buffer one character plus the one being transmitted, and your polling interval is 100us, then you will likely be able to transmit almost but not quite continuously, since on some occasions you will poll when the UART is almost done transmitting a byte, you will load one byte, and that byte will end up getting fully sent before your next polling operation. If your polling interval is much longer than 100us and the chip is as described, you will likely be able to send two characters per polling interval; whether that is adequate will depend upon your application.