8000 stm32: Integrate BLE using nimble by dpgeorge · Pull Request #4893 · micropython/micropython · GitHub
[go: up one dir, main page]

Skip to content

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

Closed
wants to merge 28 commits into from

Conversation

dpgeorge
Copy link
Member
@dpgeorge dpgeorge commented Jul 4, 2019

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:

  • low-level CYW (aka Broadcom) bluetooth driver
  • generic nimble support
  • nimble bindings to @aykevl 's bluetooth module
  • integrating all the above into the stm32 port

aykevl and others added 28 commits July 4, 2019 18:10
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.
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.
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.
@dpgeorge
Copy link
Member Author
dpgeorge commented Jul 4, 2019

@aykevl a few points that came up during this integration:

  • Nimble requires that advertising be stopped when a service is created, so this has to be done behind the scenes to conform to your BT interface.
  • In order to implement mp_bt_characteristic_value_set() I needed to maintain my own list of connection handles, and then loop over them all and write the characteristic value to them all (nimble needs a conn_handle to do a char write). I'm wondering why you didn't do this explicitly in characteristic_write(), where you do such a loop for notify (but not value set)?

@dmazzella
Copy link
Contributor

@dpgeorge are there plans for bluetooth support on stm32wb?

@dpgeorge
Copy link
Member Author

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.

@dmazzella
Copy link
Contributor

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?

@dpgeorge
Copy link
Member Author

do you have a PoC ready to test?

No, not yet. It's not a high priority at the moment.

jimmo added a commit to jimmo/micropython that referenced this pull request Jul 30, 2019
@andrewleech
Copy link
Contributor

@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.
https://gitlab.com/alelec/nrf52810_zephyr_hci_controller
https://github.com/andrewleech/micropython/commits/stm32-bluetooth

@andrewleech
Copy link
Contributor

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.

@dpgeorge
Copy link
Member Author
dpgeorge commented Aug 6, 2019

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.

@dmazzella
Copy link
Contributor

@dpgeorge what are the times for the merge of this PR?

@dpgeorge
Copy link
Member Author

what are the times for the merge of this PR?

It is high priority, hopefully can be done next week.

@jimmo jimmo mentioned this pull request Aug 28, 2019
@dpgeorge
Copy link
Member Author
dpgeorge commented Oct 1, 2019

Superseded by #5051

@dpgeorge dpgeorge closed this Oct 1, 2019
@dpgeorge dpgeorge deleted the stm32-bluetooth branch October 1, 2019 02:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0