How does one get high-speed UART data on a low-speed MSP430

Question

My project has an MSP430 connected via UART to a Bluegiga Bluetooth module. The MCU must be able to receive variable length messages from the BG module. In the current architecture, each received byte generates a UART interrupt to allow message processing, and power constraints impose a limit on the clock speed of the MSP430. This makes it difficult for the MSP430 to keep up with the any UART speeds faster than 9600bps. The result is a slow communication interface. Speeding up the data rate results in overrun errors, lost bytes, and broken communication.

Any ideas on how communication speed can be increased without sacrificing data integrity in this situation?

score 2 · Accepted Answer · edited Feb 02 '20 at 21:58

I was able to accomplish a 12x speed improvement by employing 2 of the 3 available DMA channels on the MSP430 to populate a ring buffer that could then be processed by the CPU. It was a bit tricky because the MSP430 DMA interrupts are only generated when the size register reaches zero, so I couldn't just populate a ring buffer directly because the message size is variable.

Using one DMA channel as a single byte buffer that is triggered on every byte received by the UART, which then triggers a second DMA channel that populates the ring buffer does the trick.

Below is example C code that illustrates the method. Note that it incorporates references from the MSP430 libraries.

#include "dma.h"

#define BLUETOOTH_RXQUEUE_SIZE <size_of_ring_buffer>

static int headIndex = 0;
static int tailIndex = 0;

static char uartRecvByte;
static char bluetoothRXQueue[BLUETOOTH_RXQUEUE_SIZE];

/*!********************************************************************************
  * \brief Initialize DMA hardware
  *
  * \param none
  *
  * \return none
  *
  ******************************************************************************/
void init(void)
{
    // This is the primary buffer.
    //  It will be triggered by UART Rx and generate an interrupt.
    //  It's purpose is to service every byte recieved by the UART while
    //    also waking up the CPU to let it know something happened.
    //  It uses a single address of RAM to store the data, so it needs to be
    //    serviced before the next byte is received from the UART.
    //  This was done so that any byte received triggers processing of the data.
    DMA_initParam dmaSettings;
    dmaSettings.channelSelect = DMA_CHANNEL_2;
    dmaSettings.transferModeSelect = DMA_TRANSFER_REPEATED_SINGLE;
    dmaSettings.transferSize = 1;
    dmaSettings.transferUnitSelect = DMA_SIZE_SRCBYTE_DSTBYTE;
    dmaSettings.triggerSourceSelect = DMA_TRIGGERSOURCE_20; // USCA1RXIFG, or any UART recieve trigger
    dmaSettings.triggerTypeSelect = DMA_TRIGGER_RISINGEDGE;
    DMA_init(&dmaSettings);
    DMA_setSrcAddress(DMA_CHANNEL_2, (UINT32)&UCA1RXBUF, DMA_DIRECTION_UNCHANGED);
    DMA_setDstAddress(DMA_CHANNEL_2, (UINT32)&uartRecvByte, DMA_DIRECTION_UNCHANGED);

    // This is the secondary buffer.
    //  It will be triggered when DMA_CHANNEL_2 copies a byte and will store bytes into a ring buffer.
    //  It's purpose is to pull data from DMA_CHANNEL_2 as quickly as possible
    //    and add it to the ring buffer.
    dmaSettings.channelSelect = DMA_CHANNEL_0;
    dmaSettings.transferModeSelect = DMA_TRANSFER_REPEATED_SINGLE;
    dmaSettings.transferSize = BLUETOOTH_RXQUEUE_SIZE;
    dmaSettings.transferUnitSelect = DMA_SIZE_SRCBYTE_DSTBYTE;
    dmaSettings.triggerSourceSelect = DMA_TRIGGERSOURCE_30; // DMA2IFG
    dmaSettings.triggerTypeSelect = DMA_TRIGGER_RISINGEDGE;
    DMA_init(&dmaSettings);
    DMA_setSrcAddress(DMA_CHANNEL_0, (UINT32)&uartRecvByte, DMA_DIRECTION_UNCHANGED);
    DMA_setDstAddress(DMA_CHANNEL_0, (UINT32)&bluetoothRXQueue, DMA_DIRECTION_INCREMENT);

    DMA_enableTransfers(DMA_CHANNEL_2);
    DMA_enableTransfers(DMA_CHANNEL_0);
    DMA_enableInterrupt(DMA_CHANNEL_2);
}

/*!********************************************************************************
  * \brief DMA Interrupt for receipt of data from the Bluegiga module
  *
  * \param none
  *
  * \return none
  *
  * \par Further Detail
  * \n Dependencies:   N/A
  * \n Processing:     Clear the interrupt and update the circular buffer head
  * \n Error Handling: N/A
  * \n Tests:          N/A
  * \n Special Considerations: N/A
  *
  ******************************************************************************/
void DMA_Interrupt(void)
{
    DMA_clearInterrupt(DMA_CHANNEL_2);
    headIndex = BLUETOOTH_RXQUEUE_SIZE - DMA_getTransferSize(DMA_CHANNEL_0);

    if (headIndex == tailIndex)
    {
        // This indicates ring buffer overflow.
    }
    else
    {
        // Perform processing on the current state of the ring buffer here.
        // If only partial data has been received, just leave.  Either set a flag
        // or generate an event to process the message outside of the interrupt.
        // Once the message is processed, move the tailIndex.
    }
}

Doesn't this method trigger a DMA interrupt for every single byte that is being put into the ring buffer? If so, how is this any better than a simple UART receive interrupt? The idea with DMA is typically to avoid interrupts (their latency/overhead) and to avoid CPU based copying of data (slower than DMA copying). On other MCU architectures, I've seen DMA used to continuously fill ring buffers (or dual buffers) from UART which are then drained from the "main loop", or from an interrupt generated when the ring buffer is half full (or the double buffer was swapped). — Forest Darling, Oct 05 '21 at 13:03
Yes, an interrupt is triggered when data is transferred on DMA channel 2. This allows the CPU to start processing data. If there isn't enough in the buffer, it just quits and waits for another interrupt. Usually your communication message would have a size field in its header, so the code can determine how large the message should be and just wait to process when at least that many bytes have been received. The trick to the speed increase is that the use of two DMA channels allows the buffer to fill as data is received and does not require the message to be processed until the end of message. — John Stroebel, Oct 13 '21 at 01:43
Also, it is important to note that the receive buffer of the UART on this MCU is only one byte in length, so if you don't read it fast enough it will be overwritten by the next byte. Using code with a slow clock really limits your throughput. This DMA method allows the data to be buffered for processing without losing any data. — John Stroebel, Oct 13 '21 at 01:59

How does one get high-speed UART data on a low-speed MSP430

1 Answers1