Hi Johan,

Should i go with the Hardware flow control as enable to solve the buffer flow issue ? Not using HWFC could have any other adverse effect?

As my current implementation is based on flow control as disabled, from processor side i have written beacon scanning application which scans beacons for 10 secs and then immediately flushes the UART buffer. So is it sufficient or still it would be better to go with the HWFC.

Thanks,
Mayank

Hi Mayank,

On 18. Feb 2020, at 11.29, Mayank <mayank7117@...> wrote:

I have a doubt regarding one of the sample application of zephyr (samples/bluetooth/hci_uart).
This 'hci_uart' application has Hardware flow control enable by default in its nrf.conf file. (CONFIG_UART_0_NRF_FLOW_CONTROL=y)

I have build this sample app with CONFIG_UART_0_NRF_FLOW_CONTROL=n. So, i have only configured Tx, Rx from zephyr side.

I have one custom board based on IMX6ULL processor, and on that i have connected nordic's nRF52840 chip over UART ( Flashed nRF52840 with above mentioned hci_uart application).
Purpose: To scan BLE beacons for 10 seconds, Sleep for 10 sec, Scan for 10 sec, and so on (Continuous).

From processor side also i have disabled the hardware flow control (Hence,Only using Tx, Rx).

Q1: As i'm not using HW flow control, Can i have any flow control related problem if there will be more number of devices/beacons available for the scanning.

You might get lucky with disabling hardware flow control, however this standard HCI transport officially requires it (see Vol 4, Part A section 3 in Bluetooth Core Specification 5.2).

Q2: Can i implement software flow control in hci_uart application ? If yes then how?

Yes, but it should be its own application rather than an extension of samples/bluetooth/hci_uart. The standard HCI transport for UART in the situation where you don’t have hardware flow control available is is called the Three-wire UART transport protocol and you can find it in Vol 4, Part D of the Bluetooth Core Specification 5.2. We don't currently have a sample application for this, but a contribution would be very welcome. We do have an HCI driver in drivers/bluetooth/hci/h5.c, but that’s the host side implementation of this transport (you’re interested in the controller side).

Q3: What is the meaning of this flag in zephyr confiuration : CONFIG_BT_HCI_ACL_FLOW_CONTROL?

I don’t think I can explain it any better than its Kconfig documentation (please read it if you haven’t!), but it’s not something that’s directly relevant for you regarding the UART setup, since ACL flow control is a higher level construct. Since you’re doing a controller-only build you may want to enable it (the host can then later choose if it wants to use it or not), but this is not going to help you with the HCI transport situation.

Johan

Hi All,

I have a doubt regarding one of the sample application of zephyr (samples/bluetooth/hci_uart).
This 'hci_uart' application has Hardware flow control enable by default in its nrf.conf file. (CONFIG_UART_0_NRF_FLOW_CONTROL=y)

I have build this sample app with CONFIG_UART_0_NRF_FLOW_CONTROL=n. So, i have only configured Tx, Rx from zephyr side.

I have one custom board based on IMX6ULL processor, and on that i have connected nordic's nRF52840 chip over UART ( Flashed nRF52840 with above mentioned hci_uart application).
Purpose: To scan BLE beacons for 10 seconds, Sleep for 10 sec, Scan for 10 sec, and so on (Continuous).

From processor side also i have disabled the hardware flow control (Hence,Only using Tx, Rx).

Q1: As i'm not using HW flow control, Can i have any flow control related problem if there will be more number of devices/beacons available for the scanning.
Q2: Can i implement software flow control in hci_uart application ? If yes then how?
Q3: What is the meaning of this flag in zephyr confiuration : CONFIG_BT_HCI_ACL_FLOW_CONTROL?

NOTE: Currently i'm not observing any problem while scanning around 70 beacons exists in the surrounding environment.