[
https://issues.apache.org/jira/browse/MYNEWT-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-564:
---------------------------------------
Description:
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.
New functions:
{noformat}
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);
{noformat}
Additional API change:
The flags field is no longer auto-calculated. Instead, the application has to
specify the exact value to send over the air. For example:
*OLD API*
{noformat}
fields.flags_is_present = 1;
fields.flags = 0;
{noformat}
*NEW API*
{noformat}
fields.flags = BLE_HS_ADV_F_DISC_GEN |
BLE_HS_ADV_F_BREDR_UNSUP;
{noformat}
was:
The current API requires the user to fill in a struct of advertising fields,
then pass that struct to the host. This requires a lot of code and RAM. If the
application knows the exact bytes to advertise, it shouldn't need to go through
this heavy weight API.
New functions:
{noformat}
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);
{noformat}
> BLE Host - Allow byte buf for adv / rsp data
> --------------------------------------------
>
> Key: MYNEWT-564
> URL: https://issues.apache.org/jira/browse/MYNEWT-564
> Project: Mynewt
> Issue Type: Bug
> Components: Nimble
> Reporter: Christopher Collins
> Assignee: Christopher Collins
> Fix For: v1_0_0_beta2
>
>
> 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.
> New functions:
> {noformat}
> 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);
> {noformat}
> Additional API change:
> The flags field is no longer auto-calculated. Instead, the application has
> to specify the exact value to send over the air. For example:
> *OLD API*
> {noformat}
> fields.flags_is_present = 1;
> fields.flags = 0;
> {noformat}
> *NEW API*
> {noformat}
> fields.flags = BLE_HS_ADV_F_DISC_GEN |
> BLE_HS_ADV_F_BREDR_UNSUP;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
