Full Bluetooth 5.1 stack for V2?
Opened this issue · 12 comments
Apologies if there's a better place to ask about this, but I'm curious if we will be able to get a V2 uP version at some point that includes the full Bluetooth stack and an appropriate Python API.
Hi @AllegroGavin
This is made a bit more complicated by our goal of making sure users can switch between MakeCode and MicroPython programs using only a mobile device - it means that the MakeCode and MicroPython systems need to share a Bluetooth bootloader and stack for that bootloader.
At the moment, that's SoftDevice and a lightly modified Nordic bootloader https://github.com/microbit-foundation/v2-bootloader (in the process of opening this, so may 404 today, but should be working soon), so that the flash for the Bluetooth stack can be shared between the user app and the bootloader.
If we didn't do this, then a user who had programmed their micro:bit with MicroPython wouldn't be able to use their smartphone to switch over to a MakeCode programme and vice versa.
That means that the S113 Bluetooth stack is always in flash and available to MicroPython, but S113 can't be a GAP Central device, and SoftDevice is a different stack to what is used for other MicroPython BLE ports.
Furthermore, lots of micro:bit users expect the micro:bit radio protocol to be available and this is (mostly/realistically) mutually exclusive with BLE at the moment.
We're looking at what the best way to let MicroPython programs use BLE, and having some use-cases will help. Would you like to be a GAP Peripheral? Central? Do you want yo use just a BLE UART, or are you trying to write your own services, etc?
I know this isn't quite an answer to your question, but I hope explaining some of the Ux background for why the answer isn't just "yes, it's over there" is useful.
mutually exclusive with BLE at the moment.
Is there a way to compile in BLE instead radio module?
>>> help('modules')
__main__ love neopixel ucollections
antigravity machine os uerrno
audio math radio urandom
builtins microbit speech ustruct
gc micropython this usys
log music uarray utime
Plus any modules on the filesystem
>>> os.listdir()
[]
>>> microbit.
Image Sound SoundEvent accelerometer
audio button_a button_b compass
display i2c microphone panic
pin0 pin1 pin10 pin11
pin12 pin13 pin14 pin15
pin16 pin19 pin2 pin20
pin3 pin4 pin5 pin6
pin7 pin8 pin9 pin_logo
pin_speaker reset running_time set_volume
sleep speaker spi temperature
uart ws2812_write
Found src/codal_app/codal.json. Tried "MICROBIT_BLE_ENABLED" : 1, instead of 0.
Did not work, so tried DEVICE_STACK_SIZE 16384 + 32768 instead of 8192 — nothing helped, microbit_v2 shows 0 7 1 😢
Is there a way to compile in BLE instead radio module?
It depends what you mean by "compile in BLE". But, as mentioned above, MicroPython on the microbit does not currently support using the BLE from Python, it only supports using the raw radio.
If you, like me, found this issue (or bbcmicrobit/micropython#702) when trying to figure out how to use BLE with the Micro:bit v2, I managed to get BLE working using CircuitPython: https://github.com/adafruit/circuitpython/tree/main/ports/nrf/boards/microbit_v2. CircuitPython is a fork of MicroPython, and as of Oct 2021 provides the _bleio module (https://circuitpython.readthedocs.io/en/latest/shared-bindings/_bleio/index.html) that works. After building the microbit_v2 board, flash the firmware.combined.hex file to the board like normal.
Adafruit also has the adafruit_ble library which you can build into the CircuitPython image by adding FROZEN_MPY_DIRS += $(TOP)/frozen/Adafruit_CircuitPython_BLE to the microbit_v2/mpconfigboard.mk file. You might need to do a make clean and full re-build to include this because the CircuitPython make system is not robust (you can learn from my struggles).
The main drawback to this approach is that CircuitPython expects you can load a code.py file to the board to run custom code. The file is stored in an in-flash FAT filesystem and run at boot. Since the Micro:bit v2 uses a separate DAPlink bootloader this workflow doesn't work. I ended up creating my own FAT filesystem in a local file, storing my code.py file in the filesystem, converting the filesystem to a .hex file offset at address 0x6F000 (the address where the filesystem is located in flash in CircuitPython on the Micro:bit v2), merging that hex file with the built firmware.combined.hex file, and then flashing the merged file using the normal procedure. I have no idea if there is a better option, but this workflow worked for me.
That's awesome, thanks for sharing @bradjc!
I ended up creating my own FAT filesystem in a local file, storing my code.py file in the filesystem, converting the filesystem to a .hex file offset at address 0x6F000 (the address where the filesystem is located in flash in CircuitPython on the Micro:bit v2), merging that hex file with the built firmware.combined.hex file, and then flashing the merged file using the normal procedure. I have no idea if there is a better option, but this workflow worked for me.
If you can enable "storage" at build time so that something like os.open() works (I believe this is normally blocked as the FS is by default accessed via the MSD), you could send files via serial with something like microFS, mpremote, or Ampy.
https://github.com/adafruit/circuitpython/tree/main/ports/nrf/boards/microbit_v2
Hi @bradjc can you make a quick tutorial by any chance?
Definitely still waiting on BLE support. All I want to do is pass data from an attached sensor (I2C) over bluetooth.
Since the micro:bit doesn't have a gyro, I'd like to add one.
Such a simple thing is proving to be very difficult :(
A while ago I integrated the MyNewt RTOS/BLE stack into the uPy codebase for MB v1 allowing the creation of custom GATT services. Can't recall if I wrapped the central API (may have been flash limited so probably a no/alternate hex build, but wouldn't be such an limitation on v2 to have both in a single firmware image)
Have you considered this approach for MB v2?
@WayneKeenan hello, nice to hear from you. Your timing couldn't be more perfect.
This is unusually good timing, as we've got @ForrestFairy at Lancaster University looking at doing something quite like this for CODAL as a University project.
Hey @jaustin good to hear from you too. Cool. Sounds interesting...