nRF52: Enable BLE support by default for feather52

[microbuilder]

This PR:

• Enables BLE support via s132 v2.0.1 SD by default
• Fixed NUS REPL support (via MICROPY_PY_BLE_NUS), tested with Bluefruit LE Connect
• Increased available SRAM from 49.5KB to 52KB
• Added a simple BLE Central example (boards/feather52/examples/ble_scan.py) scanning for devices and displaying the results on the command line:

Test script can be run via: $ ampy -d 1.5 -p /dev/tty.SLAB_USBtoUART run boards/feather52/examples/ble_scan.py

[jerryneedell]

@microbuilder Thanks for the update - I have downloaded, built and tested the ble_scan.py example both via USB REPL and NUS!! Works great!

[jerryneedell]

One thing I have noticed when using the NUS REPL. If I disconnect, I have to manually reset the board ignorer to establish a new connection. Is this a bug or a "feature"

Also do you know if there is a way send a Control-D via the Adafruit_BLE Connect app? I have connected via both IOS and MACOS and the EOL setting works great but I can't find way to send a control-D to execute a soft reboot.

[microbuilder]

We need to make some further additions to the apps to send char sequences like CTRL+C and CTRL+D, yeah ... I'll get an update started for that. Occurred to me just after creating the PR and some quick REPL over NUS tests that I can't cancel a script, for example (CTRL+C).

[jerryneedell]

Good point about the control-C ! I just wanted to make sure I had not missed something. I'll use the USB REPL most of the time anyway, but the NUS REPL is pretty cool!

[tannewt]

This is very exciting!

I'd like us to refine ubluepy back into a bluepy compatible API so that drivers written on top of it can apply to the raspberry pi as well. I'd also like the Python -> conversion of the API to happen in shared-bindings/bluepy so that other ports like ESP32 will use the same thing.

This doesn't need to happen in the PR but it'd be nice to have it soon for the upcoming 3.0 Betas.

[jerryneedell]

Just curious - I have a J-lInk connector on my feather52 board and in the past, I was able to use the "make BOARD=feather52 flash" and "make BOARD=feather52 SD=s132 sd" commands to flash via the J-link. Should I expect that to still work? Does anything need to be updated in the make files for this? I thought I'd ask before trying it.

[jerryneedell]

I decided to just try the J-link and it alls seems to have worked fine. I just wanted to make sure there was not something missing with regards to eh Single bank change. Let me know if I missed something.

[jerryneedell]

I have successfully gone back and forth between the J-link and the DFU boot loader - I just use the arduino IDE to return the default DFU loader then do a make boot-flash and a a make dfu-gen dfu-flash to get back after using the J-Link. Checking with os.statvfs('/') I see the same size file system with both methods.. 20 4K blocks so it all appears to be OK. If I understand correctly, the J-link loadsthe SD directly and overwrites the DFU bootloader. Either method will result in the same File system availability and functionality. Please let me know if I am misunderstanding something here.

It's nice to know both methods are viable and the J-link loaded version does boot a lot faster!

[microbuilder]

@jerryneedell I haven't tried using the CP makefile to flash via a J-Link (my assumption was always the serial bootloader, or I tend to use AdaLink for anything J-Link related), but the same version of the SD will go in the same place in either case.

The bootloader on the Arduino is the same as the CircuitPython version, although with CP we had to add the option to update to a 'single bank' version out of necessity. The latest Arduino nRF52 BSP (<=0.8.0) includes both versions as well now and users can decide between OTA safety and max firmware size.

Things have become /slightly/ more complicated with the latest Arduino BSP since there is now more than one bootloader to manage (single or dual bank) and two versions of the S132 SD (v2.0.1 and v5.0.0, the latter enabling BLE5 and much larger packet sizes for better throughput), but the new options generally won't apply to most users so the effect should be minimal.

[tannewt]

Where are we at on this? I was hoping to hear something about the API plans going forwards.

[microbuilder]

I think this can be merged in as is, separate from any changes to the current BLE API. So far I've found the existing API sensible for peripherals with basic use cases, and have only tryied scanning for devices in Central mode, but I haven't felt a compelling need to reinvent the wheel so far. I still need to test how things like INDICATE and NOTIFY work to make sure they behave as expected, etc., as well as features like the SCAN RESPONSE secondary advertising packet.

[microbuilder]

The advertising API seems a bit limited, but I think all of those issues belong in a different PR and discussion, separate from this one which just enables the radio and BLE by default.

[tannewt]

Works for me. Thanks @microbuilder!

[tannewt]

Thanks! This is exciting!