Introduction

The UART driver supports the UART capabilities of the USART, UART, and LEUART peripherals. The driver is fully reentrant and supports multiple driver instances. The driver does not buffer or queue data. However, it queues UART transmit and receive operations. Both blocking and non-blocking transfer functions are available. Non-blocking transfer functions report transfer completion with callback functions. Transfers are done using DMA. Simple direct/forced transmit and receive functions are also available. Note that these functions are blocking and not suitable for low energy applications because they use CPU polling.

UART hardware flow control (CTS/RTS) is fully supported by the driver. UART software flow control (XON/XOFF) is partially supported by the driver. For more information about flow control support, see Flow Control Support.

Note

Transfer completion callback functions are called from within the DMA interrupt handler with interrupts disabled.

Configuration Options

Some properties of the UARTDRV driver are compile-time configurable. These properties are set in a uartdrv_config.h file. A template for this file, containing default values, is in the emdrv/config folder. To configure UARTDRV for your application, provide a custom configuration file, or override the defines on the compiler command line. These are the available configuration parameters with default values defined.

// Size of the receive operation queue.

#define EMDRV_UARTDRV_MAX_CONCURRENT_RX_BUFS 6

// Size of the transmit operation queue.

#define EMDRV_UARTDRV_MAX_CONCURRENT_TX_BUFS 6

// Set to 1 to enable hardware flow control.

#define EMDRV_UARTDRV_FLOW_CONTROL_ENABLE 1

// Maximum number of driver instances.

// This maximum applies only when EMDRV_UARTDRV_FLOW_CONTROL_ENABLE = 1.

The API

This section contains brief descriptions of the functions in the API. For more information on input and output parameters and return values, click on the hyperlinked function names. Most functions return an error code, ECODE_EMDRV_UARTDRV_OK is returned on success, see ecode.h and uartdrv.h for other error codes.

UARTDRV_PauseTransmit() and UARTDRV_ResumeTransmit()
Pause a currently active transmit operation by preventing the DMA from loading the UART FIFO. Will not override HW flow control state (if applicable), but can be used in conjunction.

Flow Control Support

If UART flow control is not required, make sure that EMDRV_UARTDRV_FLOW_CONTROL_ENABLE is set to 0. This reduces the code size and complexity of the driver.

Both hardware and software flow control are supported. To enable either of these, set EMDRV_UARTDRV_FLOW_CONTROL_ENABLE to 1 in uartdrv_config.h.

Hardware Flow Control

UART hardware flow control uses two additional pins for flow control handshaking, the clear-to-send (CTS) and ready-to-send (RTS) pins. RTS is an output and CTS is an input. These are active-low signals. When CTS is high, the UART transmitter should stop sending frames. A receiver should set RTS high when it is no longer capable of receiving data.

Peripheral Hardware Flow Control

Newer devices, such as EFR32MG1 and EFM32PG1, natively support CTS/RTS in the USART peripheral hardware. To enable hardware flow control, perform the following steps:

Define the pins for CTS and RTS by setting ctsPort, ctsPin, rtsPort and rtsPin in the init struct.

Also define the CTS and RTS locations by setting portLocationCts and portLocationRts in the init struct.

GPIO Hardware Flow Control

To support hardware flow control on devices that don't have UART CTS/RTS hardware support, the driver includes the GPIOINT driver to emulate a hardware implementation of UART CTS/RTS flow control on these devices.

Define the pins for CTS and RTS by setting ctsPort, ctsPin, rtsPort and rtsPin in the same init struct.

Note

Because of the limitations in GPIO interrupt hardware, you cannot select CTS pins in multiple driver instances with the same pin number. For example, pin A0 and B0 cannot serve as CTS pins in two concurrent driver instances.

RTS is set high whenever there are no Rx operations queued. The UART transmitter is halted when the CTS pin goes high. The transmitter completes the current frame before halting. DMA transfers are also halted.

Software Flow Control

UART software flow control uses in-band signaling, meaning the receiver sends special flow control characters to the transmitter and thereby removes the need for dedicated wires for flow control. The two symbols UARTDRV_FC_SW_XON and UARTDRV_FC_SW_XOFF are defined in uartdrv_config.h.

To enable support for software flow control, perform the following steps:

The application must monitor buffers and make decisions on when to send XON/ XOFF. XON/XOFF can be sent to the peer using UARTDRV_FlowControlSet(). Though UARTDRV_FlowControlSet() will pause the active transmit operation to send a flow control character, there is no way to guarantee the order. If the application implements a specific packet format where the flow control codes may appear only in fixed positions, the application should not use UARTDRV_FlowControlSet() but implement read and write of XON/XOFF into packet buffers. If the application code fully implements all the flow control logic, EMDRV_UARTDRV_FLOW_CONTROL_ENABLE should be set to 0 to reduce code space.

A UART driver instance handle data structure. Allocated by the application using UARTDRV. Several concurrent driver instances may exist in an application. The application must not modify the contents of this handle and should not depend on its values.