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]

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]

Is this how the Rx works?

• data comes into the UART
• uart causes interrupt for every byte it receives
• interrupt causes evt of type UART_RX_RDY via notify_rx_buffer()?
• uart_cb() handles these events
• data is in evt->data.rx.buf, len is in evt->rx.len (always 1?)
• if all data to termination (\r, \n), then call uart_rx_disable(uart) and disable_req = true
• not sure what all goes on, but I presume we end up in uart_cb() again at UART_RX_BUF_RELEASED
  • seems there is a new buffer, evt->data.rx_buf.buf?
• data is transferred to fifo_uart_rx_data (another buffer) if there is data, otherwise k_free(buf)
• thread ble_write_thread() detects and sends to bt_nus_send()
• here the len can be no longer than what bt_nus_get_mtu() returns

How do the following get attention?:

• UART_RX_DISABLED 

  UART_RX_BUF_REQUEST

  Where is the size of these buffers determined?

  What process controls the RTS line for the uart's rx buffer?