This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2612: Software Processing Time for UART

Part Number: AM2612

Hi,
 
During software development on the AM2612 at my customer, they checked the software processing time for UART.
In UART polling mode, with a 4Mbps, 16-byte FIFO transfer, the software processing took approximately the same amount of time as the 44us transfer time itself.
Since this involves using a peripheral hardware, they had assumed that the software processing time would only consist of the time needed to configure the FIFO.
The receive-side processing also takes about 40us of software processing time, and they would like to reduce this time.
They would appreciate your guidance on possible countermeasures.
 
Thank you in advance.
Waveform.jpg
 
Regards,
Hideaki
  • Hi HIdeaki,

    In UART polling mode, the CPU is blocked for the entire duration of the transfer — it continuously polls the line status register (UART_LSR_UART) to check TX/RX readiness for each byte 1. With a 16-byte FIFO at 4 Mbps, the ~44 µs you observe is essentially the CPU waiting on the wire-time itself, not just "configuring the FIFO." Each byte requires a status register read + data register write/read cycle, which accumulates to match the transfer duration.

    Recommended Countermeasures (in order of effectiveness)

    1. Switch to DMA Mode (Best Option)

    Use UART_lld_writeDma() / UART_lld_readDma() to offload data movement entirely to the EDMA controller 2. The CPU only configures the transfer descriptor, then is free to do other work. Configuration steps:

    • Set DMA mode via UART_SCR[0] DMA_MODE_CTL and UART_SCR[2:1] DMA_MODE_2 1
    • Configure FIFO trigger levels via UART_TLR[7:4] (RX) and UART_TLR[3:0] (TX) — granularity of 4 bytes, range 0–60 1
    • A reference example exists at: mcal\examples\Uart\uart_echo_dma_app in the MCAL SDK 3

    Note: When using DMA, ensure cache coherency — invalidate the RX buffer cache after DMA completion using sys_cache_data_invd_range 4.

    2. Switch to Interrupt Mode with Callback (Good Option)

    Use UART_lld_writeIntr() / UART_lld_readIntr() in callback (non-blocking) mode 2. The CPU initiates the transfer and returns immediately; a user-provided callback fires upon completion. This eliminates the blocking wait, though the CPU still handles data movement in the ISR.

    Set the RX FIFO trigger level to 16 bytes so the interrupt fires only once the full 16-byte payload is received, minimizing interrupt frequency 1.

    3. Optimize FIFO Trigger Levels (If Staying in Polling)

    If polling mode must be retained, set SCR[7]=1 and use the concatenated TLR[7:4] + FCR[7:6] fields to achieve 1-character granularity trigger levels (1–63 bytes) 1. This won't eliminate the blocking time but can help batch operations more efficiently.


    Mode CPU Blocked? Expected Overhead
    Polling Yes, full transfer time ~44 µs (as observed)
    Interrupt + Callback No (ISR only) ISR entry/exit + data copy
    DMA No (descriptor setup only) Minimal (~µs for setup)

    DMA mode is the strongest recommendation for reducing the ~40–44 µs software processing time to near-zero CPU involvement.


    1. AM261x Technical Reference Manual (UART chapter)
    2. MCU+ SDK UART LLD Driver API Guide
    3. E2E: AM2612 EB Demo UART & DMA
    4. E2E: AM2612 SPI+DMA Cache Coherency

    Best Regards,

    Zackary Fleenor