gatt: add missing bit definitions #6
Conversation
More streamlined than having an external openocd or similar. Based on the "new" style code in https://github.com/Tiwalun/stm32wb55-homekit Signed-off-by: Karl Palsson <karlp@etactica.com>
This uses the new APIs to implement the eddystone application. Based on https://github.com/Tiwalun/stm32wb55-homekit as per eupn#3 ble.rs is verbatim from the Tiwalun repo. eddystone_alt.rs is based on the Tiwalun main.rs, merged with the existing eddystone_beacon.rs This is _very_ rough, but functional on the p-nucleo-wb55 board. As a rust novice, I've likely committed atrocities. Signed-off-by: Karl Palsson <karlp@etactica.com>
Use latest versions where possible. In same places dropped the dot release specifier to take anything, and be a bit more clear that we don't _really_ care. Only tested with removing the Cargo.lock file and rebuilding. Can't update cortex-m as there's a dual dependency somewhere in the tree and 0.6 and 0.7 clash? Not enough of a rust expert to resolve that. Signed-off-by: Karl Palsson <karlp@etactica.com>
There's facility for saving bytes by implying the www. Use it to show how it's done. Signed-off-by: Karl Palsson <karlp@etactica.com>
This ports the ibeacon example to the new APIs, as done for the eddystone example. Tested and working on p-nucleo-wb55 board. Signed-off-by: Karl Palsson <karlp@etactica.com>
|
Still, this may not be quite right.. the bitfields docs, https://docs.rs/bitflags/1.3.2/bitflags/#zero-flags, say "Users should generally avoid defining a flag with a value of zero." ? From reading what they're saying, I don't think that's really relevant here, as we'll never be checking for the flags like that? |
|
@karlp, you're right. It mostly depends on the use case. If we only use these bitflags as a user-friendly way to configure something in BLE stack, than it's totally fine. But as soon as there a use-case when we have to check for the presence of this "zero" bit flag, things will get weird. I think the current approach is fine and more readable than just "empty" or zero values though. As soon as we don't expect anyone to check for these zero flags. Should this use case occur in future, we'll reconsider. |
Based on AN5270rev10 For ACI_GATT_ADD_CHAR, added the "NONE" properties, and the "NO_NOTIFY" gatt event mask. For ACI_GATT_ADD_CHAR_DESC, reused the same security bitflags, and extended the access bitflags. Signed-off-by: Karl Palsson <karlp@etactica.com> Fixes: eupn#5
karlp
force-pushed
the
pulls/gatt-bits
branch
from
7791ccd
to
6704cf9
Compare
Based on AN5270rev10
For ACI_GATT_ADD_CHAR, added the "NONE" properties, and the "NO_NOTIFY"
gatt event mask.
For ACI_GATT_ADD_CHAR_DESC, reused the same security bitflags, and
extended the access bitflags.
Signed-off-by: Karl Palsson karlp@etactica.com
Fixes: #5
This might constitute "breaking" as I dropped the old redundant "DescriptorPermission"