@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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 > >> > >
