This is a big rewrite to use DBus calls directly instead of going
through go-bluetooth first.
This is a big change, but I believe it is an improvement. While the
go-bluetooth works for many cases, it's a layer in between that I
believe hurts more than it helps. Without it, we can just program
directly against the BlueZ D-Bus API. The end result is about 10% more
code.
With this rewrite, I fixed the following issues:
* All MapToStruct warnings are gone, like in
https://github.com/tinygo-org/bluetooth/issues/193.
* Advertisements can be restarted after they were stopped. Previously
this resulted in a panic.
* Looking at the source code of go-bluetooth, it appears that it
includes devices from a different Bluetooth adapter than the one
that's currently scanning. This is fixed with the rewrite.
* Fix a bug in Adapter.AddService where it would only allow adding a
single service. Multiple services can now be added.
This was actually the motivating bug that led me down to rewrite the
whole thing because I couldn't figure out where the bug was in
go-bluetooth (it's many layers deep).
* The `WriteEvent` callback in a characteristic now also gets the
'offset' parameter which wasn't provided by go-bluetooth.
This rewrite also avoids go-bluetooth specific workarounds like
https://github.com/tinygo-org/bluetooth/pull/74 and
https://github.com/tinygo-org/bluetooth/pull/121.
I have tested all examples in the smoketest-linux Makefile target. They
all still work with this rewrite.
There used to be GAP events (connect/disconnect). The main purpose for
these events was to allow applications to re-start advertisement when a
connection was lost - on nrf. Unfortunately things work differently on
Linux, which already has this behavior and for which I haven't yet
implemented these events. Therefore I have removed these events and
instead added code to automatically restart advertisement on connection
loss.
Supporting multiple (incoming) connections as a peripheral would be
useful, but is not currently supported.
This changes the previous raw advertisement packets to structured
advertisement configuration. That means you can set the local name not
with a raw byte array but with a normal string.
While this departs a bit from the original low-level interface as is
often used on microcontroller BLE stacks, it is certainly easier to use
and better matches higher level APIs that are commonly provided by
general-purpose operating systems. If there is a need for raw BLE
packets (for baremetal systems only), this can easily be added in the
future.
The nrf51822 chip is still widely available, for example in the BBC
micro:bit. Therefore it's a good idea to support it too.
Unfortunately, Nordic decided to change the API in some significant ways
so many parts are not compatible between S110 for nrf51 and the other
nrf52* SoftDevices.
