My $0.02… I agree with Chris (I think!) regarding being able to build to extremely parsimonious use cases. I don’t have a full list of all of the requirements, but a tangible use case would be that of a disposable, battery-powered beacon. In this case, the requirement might be such that it’s only functioning as a transmitter/broadcaster with no requirement to be upgraded or respond to connection requests. Here, you would want to strip out any extraneous functionality and fit into the smallest footprint possible for cost and power-saving reasons.
Perhaps an ideal, but a state that should be aimed for. thanks, James On Feb 12, 2016, at 10:09, Christopher Collins <ch...@runtime.io> wrote: > Regarding compile-time options, I was thinking of cases involving BLE > applications. Nimble is a complete BLE stack, and some applications may > not want the entire package to be compiled in to the end product. For > example, some devices are simple peripherals (slaves) that don't need > any of the central (master) functionality. These targets would need to > define the appropriate nimble macros to "compile out" unneeded > functionality. Similarly, an application may need to minimize the > amount of statically allocated memory. If an application/BSP combo > (i.e., target) only has enough RAM for a single concurrent connection, > the NIMBLE_OPT_MAX_CONNECTIONS setting needs to be set to 1. > > There are a few solutions to the above problems that work today: > * Minimize the amount of code in each project, and create a separate > project for each target. > * Use identities to configure groups of settings at a time. > > The first solution doesn't "feel right" to me; I dislike the idea of > having to create a separate main() function for each configuration. > > The second solution works for coarse-grained configuration (e.g., > central vs. peripheral vs. combined), but it is not ideal for more > precise configuration (setting a specific number of max monnections). > > I have an actual use case for this: the bletiny project. bletiny is a > simple project which provides a shell interface to the nimble > host API. I want this project to be capable of running on a variety of > different hardware with different amounts of RAM. BSPs with 16kB RAM > might only support peripheral functionality with a single connection, > while other BSPs can support something more ambitious. It would be nice > if the same project could be used in both cases. > > Chris > > > On Fri, Feb 12, 2016 at 05:42:15PM +0000, p...@wrada.com wrote: >> I think that is fantastic. Right now it feels a bit mysterious where the >> come from and its a bit awkward to share them. >> >> I was also thinking about target specific options. Some were compiler >> options like debug or optimization that you may want to turn off for >> simulation targets etc, but I think that current method would work ok for >> these since they are limited. What kinds of target specific options were >> you thinking of? Can you give some examples? >> >> >> Paul >> >> On 2/12/16, 9:31 AM, "will sanfilippo" <wi...@runtime.io> wrote: >> >>> +1 sounds great to me. >>> >>>> On Feb 11, 2016, at 11:05 PM, Christopher Collins <ch...@runtime.io> >>>> wrote: >>>> >>>> Hello all, >>>> >>>> It occurs to me that in the newt world, there is one entity that is not >>>> like the others: targets. Everything else--pacakges, projects, compiler >>>> definitions--all share the same structure: a .yml file and some source >>>> files >>>> enclosed in a directory. Targets, on the other hand, are tables stored >>>> in a sqlite database. I was wondering if it would be better if targets >>>> had the same structure as everything else. >>>> >>>> I am envisioning a directory called "targets". Each subdirectory in the >>>> targets directory would contain an individual target definition. I >>>> think this change would provide several benefits: >>>> >>>> 1. Targets could be shared and downloaded using the newt package >>>> manager. >>>> >>>> 2. Target definitions would be stored as yml files. This would bestow a >>>> simple means of reading, modifying, and copying targets, the ability >>>> to add comments next to target variables, and all the other benefits >>>> inherent in human-readable configuration files. >>>> >>>> 3. A target's directory could contain target-specific header files. >>>> >>>> The last point is what spurred me to write this email. I was thinking >>>> about the best way to allow compile-time configuration of packages. >>>> Modifying settings at the project or package level is not precise enough >>>> for some uses. There are some cases where settings need to be >>>> configured at the target level. The newt tool allows you to specify >>>> compiler flags for each target (via the "cflags" variable), but this >>>> becomes unwieldy when you need to configure hundreds of settings. >>>> >>>> Anyway, just a thought. Feel free to chime in with your own :). >>>> >>>> Thanks, >>>> Chris >>> >>
