-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cpu/esp32: add Bluetooth LE and NimBLE host support #18439
cpu/esp32: add Bluetooth LE and NimBLE host support #18439
Conversation
fc9dbfd
to
2cae517
Compare
@benpicco Now that we are using ESP-IDF directly, even Bluetooth LE support seems to be possible 😉 |
2cae517
to
e648c15
Compare
Since the label |
e648c15
to
cf271dd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good to me. I'm looking forward to test this :)
03d67d3
to
003cd45
Compare
The coexistence of BLE and WiFi in station mode seems to work with this PR. I have created an application that combines Should I add this application for testing to this PR? With the current implementation, coexistence is controlled by the hardware. However, for heavy traffic environments, it is recommended to control the coexistence by the software according the the documentation of Kconfig option
I haven't tried it yet. The coexistence of BLE and WiFi in SoftAP mode isn't supported. Therefore, the coexistence of BLE and ESP-NOW is also not supported. |
Seems to work too, and it makes a significant difference. When I ping the ESP32 node with |
Hm, ESP32 and ESP32-S2 are only Bluetooth LE 4.2 devices that work with the NimBLE host stack but have no extended advertising. Should we introduce feature |
Please squash again |
d67dbbc
to
8ba0d3f
Compare
If the package is used for a controller that supports the HCI UART H4 transport layer protocol, the functions implemented in `nimble/transport/common/hci_h4` are very useful to deal with H4 formatted packages. If required, they can be enabled by module `nimble_transport_hci_h4`.
The package uses the nRFx SDK package `nrfx`. In addition, the `mynewt-nimble` repository contains some files (`porting/nimble/src/hal_timer.c` and `porting/npl/riot/src/nrf5x_isr.c`) that are compilable only for nRF MCUs. To allow the compilation for other platforms, the use of the `nrfx` package and the compilation of these files are now dependent on the use of any nRF5x MCU.
When using Bluetooth LE, the former UART interrupt number 5 is occupied by the ESP32 Bluetooth Controller. Therefore, another interrupt number has to be used for UART.
To reduce the required RAM in default configuration, the BLE interface is used as netdev_default instead of ESP-NOW. Further network interfaces can be enabled with the modules `esp_now`, `esp_wifi` or `esp_eth`.
`nimble_rpl` was not compilable without `nimble_controller` because the header includes were inside the conditional for `MODULE_NIMBLE_CONTROLLER`.
The definition of gettimeofday in pkg/ccn-lite leads to multiple definitions on platforms where gettimeofday is compiled in in newlib. Therefore, the gettimeofday function in pkg/ccn-lite is declared as weak symbol.
When FreeRTOS semaphores, as required by ESP-IDF, are used together with `gnrc_netif`, RIOT may crash if `STATUS_RECEIVE_BLOCKED` is used as a blocking mechanism in the FreeRTOS adaptation layer. The reason for this is that `gnrc_netif` uses thread flags since PR RIOT-OS#16748. If the `gnrc_netif` thread is blocked because of a FreeRTOS semaphore, and is thus in `STATUS_RECEIVE_BLOCKED` state, the `_msg_send` function will cause a crash because it then assumes that `target->wait_data` contains a pointer to a message of type `msg_t`, but by using thread flags it contains the flag mask. This situation can happen if the ESP hardware is used while another thread is sending something timer controlled to the `gnrc_netif` thread. To solve this problem `STATUS_MUTEX_LOCKED` is used instead of `STATUS_RECEIVE_BLOCKED` and `STATUS_SEND_BLOCKED`
8ba0d3f
to
4b0d920
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good, I don't know enough about the BLE examples to judge, but I trust your testing.
Will this also be easy to enable for ESP32-S2, ESP32-S3 and ESP32-C3?
Does this still depend on #18454? |
No, it is using the mutex blocked status instead. There are no assumptions towards the blocked for mutex status as of now. I was planning on reusing that for tracing the owner of a mutex, but one really wants that to be readily available in the mutex, rather than having to search through all running threads. I guess this shows that we should add the dedicated thread states and move to them when merged. But for now, this should work :) |
I already have it ready for ESP32-C3, I was just waiting for this PR to be merged 😉 |
Thanks for reviewing and merging. |
See PR #18510 |
Contribution description
This PR provides Bluetooth LE and NimBLE host support for ESP32. In detail it includes the following changes:
esp_idf_ble
with the ESP-IDF Bluetooth LE controller codeesp_ble
to enable Bluetooth LE supportnimble_transport_hci_h4
in packagenimble
nimble
esp_ble_nimble
to enable NimBLE host supportThe following examples/tests already work:
examples/nimble_heart_rate_sensor
examples/nimble_scanner
examples/nimble_gatt
tests/nimble_autoconn_ccnl
works, however the package requires a fix (a4a4692) to be compilable on platforms that don't need NimBLE controller.tests/nimble_autoconn_gnrc
works in both directions.tests/nimble_autoconn_gnrc_ext
works in both directions with ESP32-C3 (ESP32 has only BLE4.2) but requires PR pkg/nimble: fix the event queue size for nimble_adv_ext #18467.tests/nimble_ext_adv
works on ESP32-C3 (ESP32 has only BLE4.2)tests/nimble_l2cap
tests/nimble_l2cap_server
tests/nimble_netif_ext
works in both directions with ESP32-C3 (ESP32 has only BLE4.2) but requires PR pkg/nimble: fix the event queue size for nimble_adv_ext #18467.tests/nimble_rpble_gnrc
works after a fix (4f03574) of the compilation inpkg/nimble
if ESP32 is the root node and the fix (1741f1e) described in comment.tests/nimble_rpble_gnrc_ext
works in both directions with ESP32-C3 (ESP32 has only BLE4.2) and the fix as above.tests/nimble_statconn_gnrc
works in both directions with PR pkg/nimble:derive peer address type from peer address #18474tests/nimble_statconn_gnrc_ext
works in both directions with PR pkg/nimble:derive peer address type from peer address #18474examples/nimble_scanner_esp_wifi
(combinesnimble_scanner
withgnrc_networking
to test coexistence)BLE support already works for ESP32-C3 as well.
Testing procedure
Use any ESP32 board to test
examples/nimble_scanner
:Issues/PRs references