nRF52832 Bluetooth peripheral_uart sample: use RX data and not sent to BLE

[BradEA]

I want to intercept some data in the RX (in section UART_RX_READY in uart_cb() as a command with arguments.  And I do not want this data to be sent on the the BLE.

After I get the data that I want, what should I do with the buf, so the process continues getting new data from the UART RX?

Do I just k_free(buf)?  Or something else?

[BradEA]

Also, is there a more complete description of this sample or what's involved with how this all works?

Does this always require a carriage return or linefeed character before actually sending to the BLE?

I need it to just send raw data and send when a timeout occurs (50 msec) or the buffer is full.

[Karl Ylvisaker]

Hello,

BradEA said:

Also, is there a more complete description of this sample or what's involved with how this all works?

The sample's documentation contains all the description of its function. Let me know if there is anything in particular that is not covered there that you have questions about.

BradEA said:

Does this always require a carriage return or linefeed character before actually sending to the BLE?

Yes, the buffer filling for a single message will end when the \n or \r character is received, as shown in the UART_RX_RDY handling.

Best regards,
Karl

[BradEA]

I want to be able to send any number of bytes without using \n or \r characters to indicate end of the input data packet, if possible.

And I want the program to not lose data in the middle of sending data to the BLE Tx, regardless of its MTU size.

I don't understand how data input to the uart ends up at the UART_RX_READY point in the code.

[BradEA]

Another question: where and how is the flow control handled, use of RTS/CTS?

[BradEA]

another question: how does the BLE prevent or control the flow of data into itself for sending to the tablet?

[Karl Ylvisaker]

Hello,

BradEA said:

I want to be able to send any number of bytes without using \n or \r characters to indicate end of the input data packet, if possible.

Then you would have to modify the code section I referenced earlier. However, the application will need some kind of way to know when to stop the read, so that it can be placed in the BLE TX buffer for transmission.

BradEA said:

And I want the program to not lose data in the middle of sending data to the BLE Tx, regardless of its MTU size.

Could you elaborate what you mean by this? BLE is a lossless protocol - everything you have queued for transmission will either be sent successfully, or the link will be terminated, there is not data lost in the link.

BradEA said:

I don't understand how data input to the uart ends up at the UART_RX_READY point in the code.

The UART_RX_READY is the event handling of the registered UART callback function, which will be called whenever the UART peripheral has generated an event.

BradEA said:

Another question: where and how is the flow control handled, use of RTS/CTS?

This would be handled by the UART peripheral, and needs to be enabled during initialization of the UART peripheral / driver.

BradEA said:

another question: how does the BLE prevent or control the flow of data into itself for sending to the tablet?

Could you elaborate what you mean by this? In the case that you try to queue data for sending while the sending buffer is full the call to queue data will fail with an error code indicating that the buffer is full. The sample is made to re-try the sending if this happens, which you can see as part of the ble_write_thread implementation.

Best regards,
Karl

[BradEA]

My reading of the ble_write_thread(), it does not retry sending the same data.  If it fails it prints a LOG_WRN message, frees the buffer and rechecks the fifo_uart_rx_data for more data to fill buf for another try or waits until data shows up in fifo_uart_rx_data.

Is this a correct interpretation of that function?

This seems to be the behavior I'm seeing as I showed in my previous message.