• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 2311 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS/CC3220: How to use the SimpleLink SDK v1.50.00.06 UART DMA driver

rperezti
Genius 12670 points

Part Number: CC3220

Tool/software: TI-RTOS

I have a question about how to use the CC3220 Simplelink SDK UART DMA driver to accomplish a specific task. In my application I need to enable the UART1 RX path and check it every 100mS while a remote device sends bytes to CC3220. The amount of data sent by the remote host in a 100ms interval may be different each time (e.g 20 bytes this time, 1024 bytes next time). I want to use DMA for this so that the buffering doesn't interfere with the timing of the other threads and so that buffering is never interrupted by other threads. The ring buffer seems perfect for this, but I'm not sure if a ring buffer is available when the UART driver is used in DMA mode (--define=TI_DRIVERS_UART_DMA=1).  I have the following questions about the UART DMA driver:

  1. Is it possible to accomplish the functionality described above with the SimpleLink SDK UART driver?
  2. How do I configure the size of buffer used by the UART driver in DMA mode?
  3. Is the UART driver ring buffer functionality available when DMA is used (--define=TI_DRIVERS_UART_DMA=1)?
  4. Is there any other documentation available for the SimpleLink SDK UART driver besides the API reference? 

Also, occasionally I need to update the UART baudrate for this application. From the documentation it looks like I need to call UART_close/UART_open each time I need to reconfigure the baud. Is this correct or is there another better way to update the baud rate at run-time?

Thanks,

Ruben

  • 0
    TI__Guru 63006 points
    Hi Ruben,

    It is possible to use UART/DMA for such use case. You have couple of options:
    1. if each transaction from the remote device starts with an header that specifies the length, you may use DMA to first read the header. Once the header transaction is complete, trigger another DMA transaction to read the payload (with known length).
    Or
    2. you can start a DMA transaction with the maximal rx buffer (1024 bytes is the maximum supported by the UART driver) and timeout of 100ms. You'll get an interrupt, when the buffer is full or when the timeout expire. On both case, you can schedule the next transaction.

    UARTCC32XXDMA_read contain the size parameter.

    The RingBuffer is only used in manulal (polling) mode (it works as byte-by-byte). You can add different Ring Buffer implementations that reads various number of bytes so that all the DMA transaction will refer to a single allocated buffer (in such you'll need to take care for wrap around cases, so it might add extra transaction from time to time).

    Beside the API reference I would recommend looking at the example applications.

    buadrate is configured at the Open call, so close and open are required to change it.

    Br,
    Kobi
  • 0 in reply to Kobi Leibovitch
    TI__Genius 12670 points
    Kobi,
    Thanks for the reply. I like method 2 in your response, but one concern I have with this is that the DMA will only start buffering after I make the UART_read call. Instead, the UART + DMA should always be buffering data in the background to avoid missing any bytes.

    Sorry this requirement was not clearly explained in my previous post. In my application the CC3220 serves as a "translator" between two separate entities. On one side there is an existing system with a UART interface, and on the other side is a remote host system connected to CC32xx via WIFI. My application reads data from the UART RX path only when requested to do so by the remote host, and these requests are asynchronous to the threads in my application. So the timeout in the UART_read call should start when a request comes in over WIFI. The UART + DMA should always be buffering data in the background to avoid missing any bytes. Of course the buffer will overrun if the host doesn't send a request in time, but this is known condition that is dealt with by the nature of the protocol.

    R,
    Ruben
  • 0 in reply to rperezti
    TI__Guru 63006 points
    Hi Ruben,

    Other than with the ping pong (which again can be supported through the driverlib like it was done in CC3200 and will be supported through TI Drivers in the next SDK), you will always need to enable the next transaction on the previous completion callback (which is based either on buffer full or on timeout).
    The UART HW itself has some small internal fifo that will help compensate for some delayed response and you can also enable the HW flow control (RTS/CTS) to make sure nothing gets lost.

    Br,
    Kobi
  • 0 in reply to Kobi Leibovitch
    TI__Genius 12670 points
    Ok thanks. In that case, I'm hoping (requesting) that the MCPI SDK update planned for March 2018 will maintain a generic UDMA driver that can be programmed for use with the UART in a similar way to how I use the driverlib UDMA driver on CC3200 now.

    R,
    Ruben
  • 0 in reply to rperezti
    TI__Guru 63006 points

    The driverlib is not expected to be changed. The TI driver layer is built on top of the driverlib and enables smooth transitions between TI connected MCU devices.

    The driverlib is specific to the cc32xx UART driver, but as long as you stick to CC3220 - you are ok.

    The TI driver is also more simple for the user and embeds parts of the code that are application responsibility when using driverlib.

    Br,

    Kobi