This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

app_uart_fifo & rx length

Hi,

Sorry if the answer is obvious but I'm not getting it :-)

I looked at ble_app_uart, more specifically the uart_event_handle function and its interactions with app_uart_fifo's FIFO. I cannot see how more than one byte in the RX FIFO could be used since the uart_event_handle is called in interrupt context. By unrolling the whole code we basically have

app_uart_event_handler:
  app_fifo_put(c);
  if(FIFO_LENGTH() == 1) uart_event_handle();

uart_event_handle:
  app_fifo_get(c); // So FIFO length is back to 0 (thus 1 on next byte rvcd)

Can someone please enlighten me?

Regards

Parents
  • Hi Sébastien

    That is good observation !

    That is what I observe as well. I suspect the thought behind the implementation is to attempt to extract byte from the FIFO and transfer it to BLE. If the BLE transfer is not successful, the byte would remain in the FIFO. Also, if there are multiple bytes in the FIFO, inserting into the FIFO and extract from it again will make bytes be transmitted in the correct order.

    The bad thing about the implementation of the ble_app_uart in nRF5 SDK 11.0.0 is that it asserts when the softdevice buffers are full, i.e. when the BLE transfer is slower than incoming data from UART. I have attempted to improve this, and presented my preliminary result on my answer on this thread. I anyway plan to work further on this improved ble_app_uart example and provide better documentation. Ill post updates on the linked thread.

Reply
  • Hi Sébastien

    That is good observation !

    That is what I observe as well. I suspect the thought behind the implementation is to attempt to extract byte from the FIFO and transfer it to BLE. If the BLE transfer is not successful, the byte would remain in the FIFO. Also, if there are multiple bytes in the FIFO, inserting into the FIFO and extract from it again will make bytes be transmitted in the correct order.

    The bad thing about the implementation of the ble_app_uart in nRF5 SDK 11.0.0 is that it asserts when the softdevice buffers are full, i.e. when the BLE transfer is slower than incoming data from UART. I have attempted to improve this, and presented my preliminary result on my answer on this thread. I anyway plan to work further on this improved ble_app_uart example and provide better documentation. Ill post updates on the linked thread.

Children
No Data
Related