#Doxygen newline driver
#Doxygen newline full
#Doxygen newline code

#Doxygen newline driver

* UART driver must be used in UART_DATA_TEXT mode. * UART_write | Sends data as is | Sends data with an additional newline at the end |

#Doxygen newline full

* UART_read | Returns when buffer is full | Returns when buffer is full or newline was read | * UART operation | UART_RETURN_FULL | UART_RETURN_NEWLINE | * UART_RETURN_NEWLINE unblocks or performs a callback whenever a newline * UART_RETURN_FULL unblocks or performs a callback when the read buffer has This mode only functions when in UART_DATA_TEXT mode. * This enumeration defines the return modes for UART_read() and So it's not just 'tribal UART return mode settings TI needs a document that clearly outlines what works and what doesn't. But they have no idea if they are going down a path where the underlying driver/software/chip doesn't even support the functionality. If you read the message boards you see all sorts of posts where people are trying to make things work, but they don't work and it's causing headache and delay. the following functionality is not implemented, not supported.

Why are there not release notes of some kind that say. This is from the latest UART.h - it's also in the CC1310 native uart.h driver libraries. c files you have written descriptions of functionality that do not work? So why is it that in TI documentation, and in the UART.h and. * reset index to zero to point to begining of the line */ UART_write(uart, uart_s.response, uart_s.responseMsgLen) * Print the response of the command processing */ * If command_process returns 1, then process txTaskFunction */ * Parse the input into command and arguments */ If ((input = (char)CHAR_LINE_END_1) | (input = (char)CHAR_LINE_END_2)) // (charIndex < UART_SERIAL_LINE_SIZE)) * Skip the line feed that appears after an enter as the first character of new line */

#Doxygen newline code

In the sample EasyLink Code it appeaers he is using binary data, and parsing it for a return character in code? Do we think NEWLINE isn't working? Possibly. We have spent 'hours' trying to resolve this. UART_RETURN_NEWLINE, /* readReturnMode */ In uart.c the default readReturnMode is UART_RETURN_NEWLINE. It doesn't flush when reading when getting the /n.Įvery code set (AtTerm.c, uartecho.c, etc.) it's always being set to UART_DATA_BINARY.ĭo you have a code example of this working ? on a CC13xx chipset? I was thinking that we missed a setting, etc. Uart = UART_open(Board_UART0, &uartParams) UartParams.readReturnMode = UART_RETURN_FULL UartParams.readDataMode = UART_DATA_BINARY UartParams.writeDataMode = UART_DATA_BINARY * Create a UART with data processing off. *** this is from CC13xx EasyLink 'Sample Code' Everything seems to be being done in binary mode. We see the in binary.Īfter searching the example code from TI. So we have been fighting with getting our UART read requests to process UART_RETURN_NEWLINE correctly. Other Parts Discussed in Thread: MSP430WARE, CC2640, CC1310