Thanks Andrzej. That makes sense. Chris
On Fri, Jan 27, 2017 at 04:57:48PM +0100, Andrzej Kaczmarek wrote: > 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 <ccoll...@apache.org> > 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 > >
