* gap: fix comment
* gap: expose ServiceData() in AdvertisementFields
* macos: include ServiceData in AdvertisementFields
* gap/linux: include ServiceData in AdvertisementFields
* gap: add unimplemented ServiceData() to raw advertisement
* added ServiceData advertising element also to the sending pieces
* more explicitly use the ad element type ids
* added a test case for ServiceData
* linux: added ServiceData advertising element
* sd: fix: handle no servicedata present
* linux: bluez uses string uuids for service data
* linux: fix: correct datatype for advertise with ServiceData
* uuid: add 32-Bit functions
* ServiceData now also uses a slice instead of a map as in #244
* Revert unnessesary changes
* formatting
* remove extra check
---------
Co-authored-by: William Johansson <radar@radhuset.org>
This is a breaking change, but I believe it is necessary for
correctness. Because maps have an undefined iteration order, the actual
advertised packet could change each time which I think is a bad thing.
In addition to that, using a slice should be much more lightweight than
using a map.
I've also added some tests (that should have been there in the first
place) and added some manufacturer data to the advertisement example.
Furthermore, I've optimized the code that constructs manufacturer data
for raw advertisement payloads, it should now be entirely free of heap
allocations.
This allows changing the connection latency, slave latency, and
connection timeout of an active connection - whether in the central or
peripheral role. This is especially helpful on battery operated BLE
devices that don't have a lot of power and need to lower the connection
latency for improved speed. It might also be useful for devices that
need high speed, as the defaults might be too low.
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.
Remove the Addresser type. It isn't really necessary (the Address type
can change between OSes) and makes it difficult to fix a heap allocation
in interrupts (on the Nordic SoftDevices).
This is a backwards incompatible change, but only programs that use
SetConnectHandler should notice this.
Unlike what I previously thought, BlueZ does expose it. Unfortunately it
doesn't seem to respect it: the bit is not included in D-Bus paths.
Windows also supports the bit, which I hope to fix in a future commit.
Like BlueZ, it appears to ignore it when connecting to a device.
I have intentionally chosen to implement HasServiceUUID() and not
ServiceUUIDs() because returning a slice of UUIDs will likely cause a
heap allocation. And perhaps the most common use may be checking whether
a packet has a particular UUID, so no list is necessary. Getting the
full list can of course be implemented in the future, if needed.
This is necessary when connecting to a device when using the SoftDevice.
The information is not set on Linux and Windows and is ignored on those
platform when connecting.
Instead of attempting to allocate multiple advertisement instances, only
use one by default. If needed, a NewAdvertisement method could be added
in the future for devices that actually do support multiple
advertisements at a time.
The motivation for this change is fix an inconsistency with the nrf51
(which already had the behavior of DefaultAdvertisement) and the
discovery that nrf52 devices also don't seem to support more than one
advertisement instance, even though their API does allow for multiple
instances. But the primary motivation is that for consistency with
hosted systems, it would be best if the nrf port would automatically
re-enable advertisement when a connection is lost (or made).
While BlueZ does support more than one instance, it is implemented by
simply iterating through the active advertisement instances so could
also be implemented by doing that manually. I haven't checked the
behavior of Windows and MacOS - but as always, the API is not yet stable
and can be changed if needed.
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.
