Heads up: I have pushed this API change.
The new functions are:
int ble_gap_adv_set_data(const uint8_t *data, int data_len);
int ble_gap_adv_rsp_set_data(const uint8_t *data, int data_len);
/* Converts a high-level set of fields to a byte buffer. */
int ble_hs_adv_set_fields(const struct ble_hs_adv_fields *adv_fields,
uint8_t *dst, uint8_t *dst_len,
uint8_t max_len):
The old functions are still around because they are convenient
(ble_gap_adv_set_data() and ble_gap_adv_rsp_set_data()); they won't get
included in the build if your app does not call them.
If you use ble_hs_adv_set_fields() or the old functions, please be aware
of one more API change: you need to explicitly specify the flags value
that you want to include in advertisements. Before this change, you
could specify a value of 0, and the flags field would get
auto-calculated by the host.
E.g.,
OLD API:
fields.flags_is_present = 1;
fields.flags = 0;
NEW API:
fields.flags = BLE_HS_ADV_F_DISC_GEN |
BLE_HS_ADV_F_BREDR_UNSUP;
Thanks,
Chris
On Tue, Jan 24, 2017 at 11:45:33AM -0800, Christopher Collins wrote:
> Hello all,
>
> I've mentioned this before - I really don't care for the advertising
> data API that we ended up with:
> http://mynewt.apache.org/latest/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_fields/
>
> I think we should change this API now before the 1.0 release. I was
> wondering what others think.
>
> The current API is high-level and is relatively easy to use, but
> requires a lot of code space and RAM. I think a function which just
> takes a raw byte buffer (or mbuf) would be much better. Then, there
> could be a helper function which converts an instance of `struct
> ble_hs_adv_fields` to a raw byte buffer.
>
> A simple peripheral that always advertises the same data shouldn't be
> burdened with the ble_hs_adv_fields API.
>
> There is actually a rationale as to why the API is the way it is today.
> There are a few fields in the advertisement data that the host can be
> configured to fill in automatically:
> * Flags (contains advertising type).
> * TX Power Level
>
> I figured it would be safer if these values got calculated when
> advertising is initiated. This is impractical if the host were handed a
> byte buffer rather than a series of fields.
>
> Under the new proposal, the application would need to specify the
> correct advertising type when building the byte buffer, and the tx power
> level would be queried before the advertising procedure is actually
> started. I don't think this will be a problem in practice, and I think
> the benefits in code size and RAM usage outweigh the API burden.
>
> All thoughts welcome.
>
> Thanks,
> Chris
