Hi Chris, I created a pull request which also updates API to raw data for the opposite direction, i.e. from host to app. Application can still parse this to ble_hs_adv_fields since helper is now public, but has to do this explicitly. The advantage is that if application prefers to work on raw data (I added simple iterator to make this easier) some extra code and static variables are removed saving some flash.
There are also some extra fixes includes for advertising API I had pending in my tree. Link: https://github.com/apache/incubator-mynewt-core/pull/169 BR, Andrzej On Thu, Jan 26, 2017 at 4:16 AM, Christopher Collins <[email protected]> wrote: > 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 >
