I am planning to migrate from the nRF5 SDK to the nrf connect SDK.
My application is processing events from SoftDevice on a single thread.
In the same way, please tell me how to receive HCI events in a single thread with the nrf connect SDK.
I am planning to migrate from the nRF5 SDK to the nrf connect SDK.
My application is processing events from SoftDevice on a single thread.
In the same way, please tell me how to receive HCI events in a single thread with the nrf connect SDK.
Hi,
Multithread support is required for BLE, unfortunately. The reason for this is the Bluetooth host implementation relies on multiple threads to operate.
Best regards,
Vidar
I will change the way the question is asked.
nrf connect SDK defines a number of BLE events (in other words, callback functions).
for example,
bt_le_scan_cb_t
bt_le_ext_adv_cb
bt_le_per_adv_sync_cb
bt_gatt_cb
bt_gatt_attr_read_func_t
bt_gatt_attr_write_func_t
I want to know how many threads are calling these.
I find it annoying to have to do lock processing every time I process a BLE event.
Most callbacks appear to be called from the System Workqueue.
I'm planning on migrating from the nRF5 SDK.
my application is
1.GATT service
2. advertise terminate
3.advertise reports
to access the same resource.
With the nRF5 SDK it was possible to handle all of these in the same thread.
As far as I read the source code of nrf connect SDK (zephyr), it seems that most BLE events be called from SystemQorkq.
worry
Does an event exist that is called from the sending thread?
The system workqueue work in a first in first out manner as noted in the documentation here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/zephyr/kernel/services/threads/workqueue.html so there should not be a need to worry about access to a shared resource for tasks running from this thread.
Looking at the source code (hci_core.c), rx_thread is
1. System Workq
2. Dedicated workq (bt_workq)
I can select.
On the sending side, tx_thread(tx_thread_data) is used.
Also, it seems that SystemWrokq is used in the connect process (conn.c).
Depending on how it's configured, there will be more than 3 threads, and I'm concerned.
When using SoftDevice Controller, hci_core.c/bt_recv_prio() is not called?(bt_recv() only?)
bt_recv_prio() is only to be used if you have selected this symbol here: https://github.com/nrfconnect/sdk-zephyr/blob/main/subsys/bluetooth/host/Kconfig#L97
bt_recv_prio() is only to be used if you have selected this symbol here: https://github.com/nrfconnect/sdk-zephyr/blob/main/subsys/bluetooth/host/Kconfig#L97
OK.
Are the following HighPriority events notified (callback) to the application?
(defined by hci_core.c / struct event_handler prio_events[])
BT_HCI_EVT_CMD_COMPLETE
BT_HCI_EVT_CMD_STATUS
BT_HCI_EVT_DATA_BUF_OVERFLOW
BT_HCI_EVT_DISCONN_COMPLETE
BT_HCI_EVT_NUM_COMPLETED_PACKETS
HCI is the communication interface between the Bluetooth controller and host, so it is the Bluetooth host API you should be looking at.
yes. I understand It.
What I am concerned about is which thread (Context) is calling the callback when it is called back using the Bluetooth Host API.
I expect all callbacks to be called from SystemWorkq.
Was your question addressed by Amanda's reply in your other thread here: Why is ble_rx_thread priority cooperative?
No.
my question is
1. How all HCI events are called on SystemWrokq context (this thread)
2. How to set SystemWorkq priority to preemptive (other thread)