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.
You can always place a breakpoint in these callbacks to find out what thread you are currently running in. Most are run from the workqueue as you said. But can you explain why you need to lock processing in these threads? Could this processing have been offloaded to the 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.
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
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.