You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Simon Ratner <si...@proxy.co> on 2017/09/07 18:49:35 UTC
Trimming controller code size with BLE_EXT_ADV
Hi devs,
Controller code size went from 20k -> 29k with 1_2_0 and BLE_EXT_ADV,
compared to the old BLE_MULTI_ADV_SUPPORT. This happens to be just a bit to
big for our nrf51-based target.
Any suggestions on trimming it?
Would be great to disable the scanner extensions but keep the advertiser,
or generally have more fine-grained control over which of the ext adv
features are enabled (for example, I am interested in multiple advertisers,
but not extended adv size, ext scan, ext connect, etc.)
Re: Trimming controller code size with BLE_EXT_ADV
Posted by Simon Ratner <si...@proxy.co>.
@Szymon: Originally I was 6kb short, but managed to scrape together enough
space from other areas (such as disabling a couple of GATT procs that I
wasn't using, eliminating a 64-bit division here or there -- watch out for
those -- etc). This still doesn't leave much room for additional
application logic, but at least I can build the existing codebase.
@Will: In regard to separating central and peripheral parts of the
controller, that's a separate issue and one I have no opinion on, since I
use both. This is more about each of those two parts being modular. For
example, the fact that I can disable individual GATT procs on the host is
great.
On Mon, Sep 11, 2017 at 8:26 AM, will sanfilippo <wi...@runtime.io> wrote:
> It is still possible but that affects the host much more than the
> controller. I am sure more could be done in the controller to separate the
> two.
>
> > On Sep 11, 2017, at 8:09 AM, Wayne Keenan <wa...@gmail.com>
> wrote:
> >
> > In MyNewt 0.9 it was/is possible to undef the Central role. Is that no
> longer possible in 1.2? (Sorry, I'd check but I'm on the road in France)
> >
> > Thanks
> > Wayne
> >
> >> On 11 Sep 2017, at 16:28, will sanfilippo <wi...@runtime.io> wrote:
> >>
> >> There were always plans to separate central from peripheral in the
> controller to save space but was never added since we always seemed to
> manage to fit it by doing other things.
> >>
> >> I think separating these two is a good idea for those who need the
> flash.
> >>
> >> Just my two cents.
> >>
> >> Will
> >>
> >>> On Sep 11, 2017, at 5:22 AM, Wayne Keenan <wa...@gmail.com>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Being able to disable parts of the Nimble stack to reduced code (and
> RAM) size is a compelling feature of MyNewt/Nimble, I'd like to see as many
> tweak-ables as is sane. The Host not being 100% compliant is fine in my
> mind for some learning/experimenting/tinkering use cases.
> >>>
> >>> Automated tests should/could be setup to help cover some of the well
> trodden and the corner cases, if not done already, sorry not checked or
> aware if they are already, are they?
> >>>
> >>> Is Slack /the/ place now?
> >>>
> >>> Thanks
> >>> Wayne
> >>>
> >>>> On 11 Sep 2017, at 12:21, Szymon Janc <sz...@codecoup.pl>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>> On Thursday, 7 September 2017 20:49:35 CEST Simon Ratner wrote:
> >>>>> Hi devs,
> >>>>>
> >>>>> Controller code size went from 20k -> 29k with 1_2_0 and BLE_EXT_ADV,
> >>>>> compared to the old BLE_MULTI_ADV_SUPPORT. This happens to be just a
> bit to
> >>>>> big for our nrf51-based target.
> >>>>>
> >>>>> Any suggestions on trimming it?
> >>>>>
> >>>>> Would be great to disable the scanner extensions but keep the
> advertiser,
> >>>>> or generally have more fine-grained control over which of the ext adv
> >>>>> features are enabled (for example, I am interested in multiple
> advertisers,
> >>>>> but not extended adv size, ext scan, ext connect, etc.)
> >>>>
> >>>> I mentioned about this on slack but lets discuss this further here as
> this
> >>>> might be useful for other people as well.
> >>>>
> >>>> In general extended advertising feature was suppose to be enabled as
> a whole.
> >>>> This is mostly due to requirements put on HCI by spec but maybe we
> could relax
> >>>> those a bit and just allow people to build incomplete controller...
> >>>>
> >>>> Separating central from ext advertising would save around 3kB of
> flash. We
> >>>> could also try making support for only legacy PDUs in ext advertising
> which
> >>>> should save couple more kBs.
> >>>>
> >>>> I'm bit reluctant for this (especially the latter) since it increase
> number of
> >>>> possible build configurations (which is already huge...) and leave
> places for
> >>>> build errors in less common ones. But if this is a blocker for you to
> upgrade
> >>>> we should probably consider this...
> >>>>
> >>>> Also, how much space is missing on your target when you enable ext
> >>>> advertising?
> >>>>
> >>>> --
> >>>> pozdrawiam
> >>>> Szymon Janc
> >>
>
>
Re: Trimming controller code size with BLE_EXT_ADV
Posted by will sanfilippo <wi...@runtime.io>.
It is still possible but that affects the host much more than the controller. I am sure more could be done in the controller to separate the two.
> On Sep 11, 2017, at 8:09 AM, Wayne Keenan <wa...@gmail.com> wrote:
>
> In MyNewt 0.9 it was/is possible to undef the Central role. Is that no longer possible in 1.2? (Sorry, I'd check but I'm on the road in France)
>
> Thanks
> Wayne
>
>> On 11 Sep 2017, at 16:28, will sanfilippo <wi...@runtime.io> wrote:
>>
>> There were always plans to separate central from peripheral in the controller to save space but was never added since we always seemed to manage to fit it by doing other things.
>>
>> I think separating these two is a good idea for those who need the flash.
>>
>> Just my two cents.
>>
>> Will
>>
>>> On Sep 11, 2017, at 5:22 AM, Wayne Keenan <wa...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> Being able to disable parts of the Nimble stack to reduced code (and RAM) size is a compelling feature of MyNewt/Nimble, I'd like to see as many tweak-ables as is sane. The Host not being 100% compliant is fine in my mind for some learning/experimenting/tinkering use cases.
>>>
>>> Automated tests should/could be setup to help cover some of the well trodden and the corner cases, if not done already, sorry not checked or aware if they are already, are they?
>>>
>>> Is Slack /the/ place now?
>>>
>>> Thanks
>>> Wayne
>>>
>>>> On 11 Sep 2017, at 12:21, Szymon Janc <sz...@codecoup.pl> wrote:
>>>>
>>>> Hi,
>>>>
>>>>> On Thursday, 7 September 2017 20:49:35 CEST Simon Ratner wrote:
>>>>> Hi devs,
>>>>>
>>>>> Controller code size went from 20k -> 29k with 1_2_0 and BLE_EXT_ADV,
>>>>> compared to the old BLE_MULTI_ADV_SUPPORT. This happens to be just a bit to
>>>>> big for our nrf51-based target.
>>>>>
>>>>> Any suggestions on trimming it?
>>>>>
>>>>> Would be great to disable the scanner extensions but keep the advertiser,
>>>>> or generally have more fine-grained control over which of the ext adv
>>>>> features are enabled (for example, I am interested in multiple advertisers,
>>>>> but not extended adv size, ext scan, ext connect, etc.)
>>>>
>>>> I mentioned about this on slack but lets discuss this further here as this
>>>> might be useful for other people as well.
>>>>
>>>> In general extended advertising feature was suppose to be enabled as a whole.
>>>> This is mostly due to requirements put on HCI by spec but maybe we could relax
>>>> those a bit and just allow people to build incomplete controller...
>>>>
>>>> Separating central from ext advertising would save around 3kB of flash. We
>>>> could also try making support for only legacy PDUs in ext advertising which
>>>> should save couple more kBs.
>>>>
>>>> I'm bit reluctant for this (especially the latter) since it increase number of
>>>> possible build configurations (which is already huge...) and leave places for
>>>> build errors in less common ones. But if this is a blocker for you to upgrade
>>>> we should probably consider this...
>>>>
>>>> Also, how much space is missing on your target when you enable ext
>>>> advertising?
>>>>
>>>> --
>>>> pozdrawiam
>>>> Szymon Janc
>>
Re: Trimming controller code size with BLE_EXT_ADV
Posted by Wayne Keenan <wa...@gmail.com>.
In MyNewt 0.9 it was/is possible to undef the Central role. Is that no longer possible in 1.2? (Sorry, I'd check but I'm on the road in France)
Thanks
Wayne
> On 11 Sep 2017, at 16:28, will sanfilippo <wi...@runtime.io> wrote:
>
> There were always plans to separate central from peripheral in the controller to save space but was never added since we always seemed to manage to fit it by doing other things.
>
> I think separating these two is a good idea for those who need the flash.
>
> Just my two cents.
>
> Will
>
>> On Sep 11, 2017, at 5:22 AM, Wayne Keenan <wa...@gmail.com> wrote:
>>
>> Hi,
>>
>> Being able to disable parts of the Nimble stack to reduced code (and RAM) size is a compelling feature of MyNewt/Nimble, I'd like to see as many tweak-ables as is sane. The Host not being 100% compliant is fine in my mind for some learning/experimenting/tinkering use cases.
>>
>> Automated tests should/could be setup to help cover some of the well trodden and the corner cases, if not done already, sorry not checked or aware if they are already, are they?
>>
>> Is Slack /the/ place now?
>>
>> Thanks
>> Wayne
>>
>>> On 11 Sep 2017, at 12:21, Szymon Janc <sz...@codecoup.pl> wrote:
>>>
>>> Hi,
>>>
>>>> On Thursday, 7 September 2017 20:49:35 CEST Simon Ratner wrote:
>>>> Hi devs,
>>>>
>>>> Controller code size went from 20k -> 29k with 1_2_0 and BLE_EXT_ADV,
>>>> compared to the old BLE_MULTI_ADV_SUPPORT. This happens to be just a bit to
>>>> big for our nrf51-based target.
>>>>
>>>> Any suggestions on trimming it?
>>>>
>>>> Would be great to disable the scanner extensions but keep the advertiser,
>>>> or generally have more fine-grained control over which of the ext adv
>>>> features are enabled (for example, I am interested in multiple advertisers,
>>>> but not extended adv size, ext scan, ext connect, etc.)
>>>
>>> I mentioned about this on slack but lets discuss this further here as this
>>> might be useful for other people as well.
>>>
>>> In general extended advertising feature was suppose to be enabled as a whole.
>>> This is mostly due to requirements put on HCI by spec but maybe we could relax
>>> those a bit and just allow people to build incomplete controller...
>>>
>>> Separating central from ext advertising would save around 3kB of flash. We
>>> could also try making support for only legacy PDUs in ext advertising which
>>> should save couple more kBs.
>>>
>>> I'm bit reluctant for this (especially the latter) since it increase number of
>>> possible build configurations (which is already huge...) and leave places for
>>> build errors in less common ones. But if this is a blocker for you to upgrade
>>> we should probably consider this...
>>>
>>> Also, how much space is missing on your target when you enable ext
>>> advertising?
>>>
>>> --
>>> pozdrawiam
>>> Szymon Janc
>
Re: Trimming controller code size with BLE_EXT_ADV
Posted by will sanfilippo <wi...@runtime.io>.
There were always plans to separate central from peripheral in the controller to save space but was never added since we always seemed to manage to fit it by doing other things.
I think separating these two is a good idea for those who need the flash.
Just my two cents.
Will
> On Sep 11, 2017, at 5:22 AM, Wayne Keenan <wa...@gmail.com> wrote:
>
> Hi,
>
> Being able to disable parts of the Nimble stack to reduced code (and RAM) size is a compelling feature of MyNewt/Nimble, I'd like to see as many tweak-ables as is sane. The Host not being 100% compliant is fine in my mind for some learning/experimenting/tinkering use cases.
>
> Automated tests should/could be setup to help cover some of the well trodden and the corner cases, if not done already, sorry not checked or aware if they are already, are they?
>
> Is Slack /the/ place now?
>
> Thanks
> Wayne
>
>> On 11 Sep 2017, at 12:21, Szymon Janc <sz...@codecoup.pl> wrote:
>>
>> Hi,
>>
>>> On Thursday, 7 September 2017 20:49:35 CEST Simon Ratner wrote:
>>> Hi devs,
>>>
>>> Controller code size went from 20k -> 29k with 1_2_0 and BLE_EXT_ADV,
>>> compared to the old BLE_MULTI_ADV_SUPPORT. This happens to be just a bit to
>>> big for our nrf51-based target.
>>>
>>> Any suggestions on trimming it?
>>>
>>> Would be great to disable the scanner extensions but keep the advertiser,
>>> or generally have more fine-grained control over which of the ext adv
>>> features are enabled (for example, I am interested in multiple advertisers,
>>> but not extended adv size, ext scan, ext connect, etc.)
>>
>> I mentioned about this on slack but lets discuss this further here as this
>> might be useful for other people as well.
>>
>> In general extended advertising feature was suppose to be enabled as a whole.
>> This is mostly due to requirements put on HCI by spec but maybe we could relax
>> those a bit and just allow people to build incomplete controller...
>>
>> Separating central from ext advertising would save around 3kB of flash. We
>> could also try making support for only legacy PDUs in ext advertising which
>> should save couple more kBs.
>>
>> I'm bit reluctant for this (especially the latter) since it increase number of
>> possible build configurations (which is already huge...) and leave places for
>> build errors in less common ones. But if this is a blocker for you to upgrade
>> we should probably consider this...
>>
>> Also, how much space is missing on your target when you enable ext
>> advertising?
>>
>> --
>> pozdrawiam
>> Szymon Janc
Re: Trimming controller code size with BLE_EXT_ADV
Posted by Wayne Keenan <wa...@gmail.com>.
Hi,
Being able to disable parts of the Nimble stack to reduced code (and RAM) size is a compelling feature of MyNewt/Nimble, I'd like to see as many tweak-ables as is sane. The Host not being 100% compliant is fine in my mind for some learning/experimenting/tinkering use cases.
Automated tests should/could be setup to help cover some of the well trodden and the corner cases, if not done already, sorry not checked or aware if they are already, are they?
Is Slack /the/ place now?
Thanks
Wayne
> On 11 Sep 2017, at 12:21, Szymon Janc <sz...@codecoup.pl> wrote:
>
> Hi,
>
>> On Thursday, 7 September 2017 20:49:35 CEST Simon Ratner wrote:
>> Hi devs,
>>
>> Controller code size went from 20k -> 29k with 1_2_0 and BLE_EXT_ADV,
>> compared to the old BLE_MULTI_ADV_SUPPORT. This happens to be just a bit to
>> big for our nrf51-based target.
>>
>> Any suggestions on trimming it?
>>
>> Would be great to disable the scanner extensions but keep the advertiser,
>> or generally have more fine-grained control over which of the ext adv
>> features are enabled (for example, I am interested in multiple advertisers,
>> but not extended adv size, ext scan, ext connect, etc.)
>
> I mentioned about this on slack but lets discuss this further here as this
> might be useful for other people as well.
>
> In general extended advertising feature was suppose to be enabled as a whole.
> This is mostly due to requirements put on HCI by spec but maybe we could relax
> those a bit and just allow people to build incomplete controller...
>
> Separating central from ext advertising would save around 3kB of flash. We
> could also try making support for only legacy PDUs in ext advertising which
> should save couple more kBs.
>
> I'm bit reluctant for this (especially the latter) since it increase number of
> possible build configurations (which is already huge...) and leave places for
> build errors in less common ones. But if this is a blocker for you to upgrade
> we should probably consider this...
>
> Also, how much space is missing on your target when you enable ext
> advertising?
>
> --
> pozdrawiam
> Szymon Janc
Re: Trimming controller code size with BLE_EXT_ADV
Posted by Szymon Janc <sz...@codecoup.pl>.
Hi,
On Thursday, 7 September 2017 20:49:35 CEST Simon Ratner wrote:
> Hi devs,
>
> Controller code size went from 20k -> 29k with 1_2_0 and BLE_EXT_ADV,
> compared to the old BLE_MULTI_ADV_SUPPORT. This happens to be just a bit to
> big for our nrf51-based target.
>
> Any suggestions on trimming it?
>
> Would be great to disable the scanner extensions but keep the advertiser,
> or generally have more fine-grained control over which of the ext adv
> features are enabled (for example, I am interested in multiple advertisers,
> but not extended adv size, ext scan, ext connect, etc.)
I mentioned about this on slack but lets discuss this further here as this
might be useful for other people as well.
In general extended advertising feature was suppose to be enabled as a whole.
This is mostly due to requirements put on HCI by spec but maybe we could relax
those a bit and just allow people to build incomplete controller...
Separating central from ext advertising would save around 3kB of flash. We
could also try making support for only legacy PDUs in ext advertising which
should save couple more kBs.
I'm bit reluctant for this (especially the latter) since it increase number of
possible build configurations (which is already huge...) and leave places for
build errors in less common ones. But if this is a blocker for you to upgrade
we should probably consider this...
Also, how much space is missing on your target when you enable ext
advertising?
--
pozdrawiam
Szymon Janc