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.