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.

CC1310: Improving the performance of UART in uartEcho example

Part Number: CC1310
Other Parts Discussed in Thread: CC1311R3

Tool/software:

It seems that the uart_read() function has an unexplained delay in returning the data from the UART. The screenshot below is of the UART RX and TX pins. In the UART Echo example (no RTOS, CCS, CC1310) running on the CC1310 Launchpad, the receive sequence of 8 bytes on the wire is completed in 8.8ms (for uartParams updated for 9600 baud, even parity, and one stop bit). The echo implementation transmits the 8 bytes on the wire in 24 ms. 

Clearly, this is not sustainable as the UART buffers will overflow as the transmission is taking 3x as long as the receive time. 

The code is given below. It is the same as the example for CC1310, No RTOS, CCS Compiler except for the data rate, parity and stop bit. 

void *mainThread(void *arg0)
{
    char        input;
    const char  echoPrompt[] = "Echoing characters:\r\n";
    UART_Handle uart;
    UART_Params uartParams;

    /* Call driver init functions */
    GPIO_init();
    UART_init();

    /* Configure the LED pin */
    GPIO_setConfig(Board_GPIO_LED0, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);

    /* Turn on user LED */
    GPIO_write(Board_GPIO_LED0, Board_GPIO_LED_ON);

    /* Create a UART with data processing off. */
    UART_Params_init(&uartParams);
    uartParams.writeDataMode = UART_DATA_BINARY;
    uartParams.readDataMode = UART_DATA_BINARY;
    uartParams.readReturnMode = UART_RETURN_FULL;
    uartParams.readEcho = UART_ECHO_OFF;
    uartParams.baudRate = 9600;
    uartParams.parityType = UART_PAR_EVEN;
    uartParams.stopBits = UART_STOP_ONE;

    uart = UART_open(Board_UART0, &uartParams);

    if (uart == NULL) {
        /* UART_open() failed */
        while (1);
    }

    UART_write(uart, echoPrompt, sizeof(echoPrompt));

    /* Loop forever echoing */
    while (1) {
        UART_read(uart, &input, 1);
        UART_write(uart, &input, 1);
    }
}

To get from the 8 byte receive sequence to transmitting the first byte, there is a quiet time of about 3.56ms!! What is making the UART_read of 1 byte take so long to get to the UART_write? Both FIFOs are enabled for TX and RX. So, while the RX is in progress, the TX FIFO should get written to by the UART_Write and once the transmission start, there is no reason for successive bytes to get a gap of 2.3ms! 

   

Can you please help explain this and improve the performance? Thanks. 

  • Some more followup queries:

    1. Do you have a uart Echo example with Even parity, and in which the parity errors are handled? If so, please share.

    2. When parity is disabled (removed line 25 in code snippet posted previously), the receive callback is executed soon after the first byte is received. See screenshot.

    It is not clear why enabling parity checks leads to such a stark change in the behaviour of the code. 

    Please help. Thank you. 

  • Hi Manish,

    We don't have bandwidth to look into this right now. 

    Can you do the same measurements with the newest SimpleLink F2 SDK, e.g. use CC1312?

    https://www.ti.com/tool/SIMPLELINK-LOWPOWER-SDK

    Cheers,

    Marie H

  • Hi Marie,

    Thank you for responding. It is quite challenging to switch to CC1312 at this point - CC1312 is 7x7 48-pin package, whereas CC1310 is 5x5 32-pin package.

    Few questions:

    1. Is CC1310 an end-of-life or NRND designated device? Please do advise as this will help make the right decision.

    2. The TI Driver implementation is easy to use in the beginning. But once we start using it, getting it to do what is needed is a bit harder than expected without support from TI in terms of more examples or E2E response. So, is the driver lib better than the TI drivers for low level access to the UART?

    I do understand that the team may be very busy. Still, I humble request you to run the example snippet above in the uartecho.c on CC1310LP with and without even parity and advise how we should proceed next. 

    Thank you. 

  • Hi Manish,

    The CC1312 suggestion was just for testing reasons. We have made several changes and updates on the CC1312 UART driver.

    1. No the CC1310 is still recommended for new devices. But if you look at the software page you can see that we don't update it very often any more.

    2. I would recommend to use the driver. The driver lib is not intended for use by customers.

    Cheers,

    Marie H

  • BTW, if you're considering moving to a newer device you should look at the CC1311R3 as well. This one is available as 5x5 package. It does not have sensor controller, though.

    https://www.ti.com/product/CC1311R3#pps 

    Cheers,

    Marie

  • 1. With the software, hardware and test efforts already invested, it may be challenging to switch devices. I also see that the 5x5 package has 40 pins, so it must be smaller pitch than CC1310. 

    2. While driver lib is not intended for customer use, it turns out that it is easier than the TI Driver for UART, and the performance is lot better. Even the delay with parity checking is not there and it is easier to know what is going on in the device. There is quite likely an issue with the UART driver when parity is enabled.

    3. I think it is not a good idea to deprioritize older devices for the software updates and support. This device family is excellent and the support should be wholehearted across the board. 

    I am marking the issue as resolved - we do not have a choice but to use the driverlib. It has solved the performance and the functionality issues documented above. Thank you!

  • Hi Manish,

    Glad to hear that you got it working!

    Cheers,

    Marie H