nRF52: BLE Python Helper Classes

[microbuilder]

Easier to use helper classes on top of the current low level BLE library are required for the following:

Peripheral Mode

Core Classes

• GAP: Advertising
• GATT: Characteristic Wrapper
• GATT: Service Wrapper
• GATT: Description Wrappers (CCCD, etc.)

Service Wrappers

• Device Information Service
• BLE UART (NUS)
• Physical Web (formerly Eddystone)

Central Mode

TBD

Requirements

These helpers classes should require no packet level knowledge from users, which is currently the case constructing advertising packets, etc.

The wrappers must work with both S132 (nRF52832 boards) and S140 (nRF52840) SD APIs.

[arturo182]

Are we talking about Python classes here? Are we following the bluepy (http://ianharvey.github.io/bluepy-doc/) API? I would like to help but need to decide on the API first.

[arturo182]

In the future we could also look into adding HID and ANCS support, they are quite useful.

[microbuilder]

Yeah, the goal is ideally something sitting on top of bluepy (for portability reasons), and I'm talking about Python helper classes, I'll clarify that in the subject line.

The current bluepy API assumes a reasonable amount of knowledge at the packet level and about BLE, and helper classes can make working with things like indicate/notify and advertising properly much less error prone for end users.

[microbuilder]

@arturo182 We already have helpers for a lot of useful services like ANCS for Arduino ... the goal is of course migrating similar helpers over to Python, though the API will obviously be different on a different platform and language: https://github.com/adafruit/Adafruit_nRF52_Arduino/tree/master/libraries/Bluefruit52Lib/src

[arturo182]

If we want to only support s132 and s140, does that mean we drop support for s110, s120 and s130? I see there are many defines for those SDs in the ble driver and I'm not sure how well those have been tested, does CP even run on those 16K/32K RAM nRF51 devices? Maybe we should remove the board and linker files for the nRF51 family and only support nRF52.

And another question, is the pca10040 supported? Because I couldn't build it, was missing a board.c file, how did you test the ble code when developing,w as it only on the feather52?

[arturo182]

I think we should also have an issue for more advanced BLE features like security, bonding (and we need somewhere to keep the IRK), advertising whitelists, and connection interval management (important for power efficiency).

[microbuilder]

Personally, S132 and S140 are the only targets that I think have a lot of value moving forward. The older devices are too small to be useful. As part of the next PR, I was actually planning on removing a lot of boards, and focus on the micro:bit, feather52 and PCA10056 boards exclusively, or anything similar enough to those to easily maintain without stretching ourselves too thin. The combination of S132/S140 and nRF52832 (32+512KB) or nRF52840 are all that really make sense to me.

[arturo182]

That sounds good, If we remove the older SDs from the ble driver i think it will become way cleaner and since s132 and s140 SDK is fairly similar, there won't be that many ifdefs.

I think it's worth leaving the pca10040 in, but remove all the nRF51 boards.

Let me know how I can help, don't want to step on your toes.

[tannewt]

It sounds like the bluepy API will work to build the higher level helpers on top of. The current ubluepy is slightly different from the proper bluepy API and it'd be great to redo ours to be an exact subset (or identical). The biggest difference I know of is that ubluepy doesn't use properties. That's a MicroPython design decision that we don't follow. (We pick consistency over memory optimization.)

Here is an example of a difference: bluepy vs ubluepy

Here is an example of a Python property in C.

It would be awesome to introduce a bluepy module to the shared-bindings directory and have it be consistent with CPython's bluepy. It would then call a C api that any port can implement to provide BLE.