Hi Chris, On Tue, Jan 24, 2017 at 8:45 PM, Christopher Collins <[email protected]> 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. > Raw buffer works for me. Anyway, I also like approach used in Zephyr: the data passed via API is an array of TLV structures which is then flattened by the host. Using few macros you can create nice looking definition of adv data. The advantage compared to ble_hs_adv_fields for me is smaller memory overhead since you only define elements you need, while the adv struct always occupies quite a lot of memory no matter how many tags are defined. > 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. > +1, let app have full control over adv data BR, Andrzej
