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

Reply via email to