-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
stm32: Integrate BLE using nimble #4893
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
Conversation
Rebased to master with the help of Mirko Vogt.
This is useful for more advanced use cases, like iBeacon/Eddystone.
At the moment, only a service is created. Characteristics within a service cannot yet be added.
128-bit proprietary UUIDs can be passed using strings. Dashes and capitalization are ignored.
Add support for adding characteristics to services. They can be read and written on both the esp32 and the nrf. Events of any kind (notifications etc.) haven't been implemented yet.
Instead of raising EPERM, raise EINVAL.
Keep track of all connected centrals and notify them when a characteristic is written to.
Running write callbacks on the main thread using the scheduler has the advantage that you can do heap allocations. This is especially useful for the ESP32 which cannot easily run some code in a separate thread.
This makes the method a bit more compatible with the Hardware API: https://github.com/micropython/micropython/wiki/Hardware-API#irqs Another advantage is that we can now add other triggers besides 'on write', like 'on read'.
It may be useful to know the current device address. This method provides a way to read the device address from the BLE stack.
One application profile does not map to a single service, but it really maps to a single application. This resulted in a number of connect/disconnect events equal to the number of registered services, which of course is wrong unless exactly one service is registered. Make sure we create one application profile at start and use that the whole time.
This commit allows the Python code to explicitly disconnect a central device using device objects from connect or write events.
As requested by Damien.
This costs about 1kB in code size but is very useful to convert MAC addresses to hex format: MAC addresses will be returned in raw form in a future commit.
Instead of returning a human-readable string with .address() on both the Bluetooth and Device object, return a raw MAC address with a .config('mac') call. This is more extensible and more in line with how the network module does it. The MAC address can easily be converted back to hex format with the ubinascii module.
Tag nimble_1_1_0_tag.
@aykevl a few points that came up during this integration:
|
@dpgeorge are there plans for bluetooth support on stm32wb? |
Yes. It could use nimble as the stack via HCI, probably this is the easiest thing to get working initially. |
do you have a PoC ready to test? |
No, not yet. It's not a high priority at the moment. |
Based on micropython#4589 by @aykevl and micropython#4893 by @dpgeorge.
@dpgeorge Thanks for your work on this! I've finally had some time at work this week to rebuild my bluetooth support, so this is a perfect starting point. I've confirmed that this works as-is (unsurprisingly) with the PYBD-SF6 once the bluetooth micropython.mk flags are added. Sample code used for testing: #4589 (comment) With relatively few changes I've got the same functionality working on our custom board with a nrf52810 BLE chip running zephyr as a HCI controller. I chose zephyr instead of mynewt here as zephyr in controller configuration comes pre-certified. |
On a related note; the nimble bindings, if moved from stm32 to a common module, would work equally well to provide BL support to unix port with a standard csr style usb bt adapter. |
Yes, agreed. And they'd also work for other ports like nrf/esp32 if nimble were to be used as the BT stack on those. So it would be good to put the nimble bindings in a common (extmod) directory. |
@dpgeorge what are the times for the merge of this PR? |
It is high priority, hopefully can be done next week. |
Superseded by #5051 |
This PR integrates BLE for the stm32 port. The BLE stack is Apache mynewt-nimble using a UART HCI connection to a BT device. It supports the bluetooth device on PYBD_SFx, but any other BT device could easily be supported by using a different UART connection.
It builds upon #4589 by @aykevl to provide the Python-level API. Although currently not all parts of that API are supported advertising and adding a service works, as well as writing to characteristics.
Components introduced in this PR: