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 2016/06/08 19:43:47 UTC
Base a custom bsp on an existing one
I would like to create a couple of custom bsps for boards which are
identical to nrf51dk but a few small tweaks (e.g. led pin, flash area
layout).
From the docs, I gather that copying hw/bsp/nrf51dk and patching bsp.h and
os_bsp.c would do the trick, and it seems that's how mynewt itself handles
this. However, I'd really prefer not to, so I can keep up with upstream and
avoid duplicating fixes in multiple places (like
https://github.com/apache/incubator-mynewt-core/commit/c70353c193bf3e91a095cfc5076ac578f8e1bc69).
Any suggestions on how to best layer my tweaks on top of an existing bsp?
Can I abuse the deps system somehow?
Simon.
Re: Base a custom bsp on an existing one
Posted by Simon Ratner <si...@proxy.co>.
That's fair enough. There is definitely a cost to "inheritance" if a change
in the base bsp breaks a bunch of boards that were based on it but perhaps
not quite as closely as the bsp author had assumed.
One way to prevent breakages is to depend on a locked version and only
upgrade the dependency explicitly. Unfortunately, then you are no longer
running up-to-date software bits that come from the same repo, and locking
just the bsp sounds dangerous due to tight hal/mcu coupling. In short, I
don't have a good answer either ;)
I'll copy-and-patch for now.
On Wed, Jun 8, 2016 at 3:51 PM, will sanfilippo <wi...@runtime.io> wrote:
> Simon:
>
> Dont take this as a judgment on what you are proposing (others have
> mentioned it as well) but there are pros and cons to both approaches. What
> we (and maybe that is the royal “we”; meaning it is just my opinion, lol)
> wanted to avoid was tons of “tweaks” to a particular bsp platform. I can
> see a case where there are many similar bsps and all these tweaks get messy
> and also possibly break working bsps.
>
> All that said, it does seem wasteful to have a plethora of bsps with very
> minor changes and if these tweaks can be contained in a single place it
> seems like a good idea.
>
> I dont have any particular suggestions as of this moment but will give
> this some thought and hopefully we can come up with something that will
> make all happy. Sorry if this answer is not tremendously satisfying…
>
>
>
> > On Jun 8, 2016, at 12:43 PM, Simon Ratner <si...@proxy.co> wrote:
> >
> > I would like to create a couple of custom bsps for boards which are
> > identical to nrf51dk but a few small tweaks (e.g. led pin, flash area
> > layout).
> >
> > From the docs, I gather that copying hw/bsp/nrf51dk and patching bsp.h
> and
> > os_bsp.c would do the trick, and it seems that's how mynewt itself
> handles
> > this. However, I'd really prefer not to, so I can keep up with upstream
> and
> > avoid duplicating fixes in multiple places (like
> >
> https://github.com/apache/incubator-mynewt-core/commit/c70353c193bf3e91a095cfc5076ac578f8e1bc69
> ).
> >
> >
> > Any suggestions on how to best layer my tweaks on top of an existing bsp?
> > Can I abuse the deps system somehow?
> >
> > Simon.
>
>
Re: Base a custom bsp on an existing one
Posted by will sanfilippo <wi...@runtime.io>.
Simon:
Dont take this as a judgment on what you are proposing (others have mentioned it as well) but there are pros and cons to both approaches. What we (and maybe that is the royal “we”; meaning it is just my opinion, lol) wanted to avoid was tons of “tweaks” to a particular bsp platform. I can see a case where there are many similar bsps and all these tweaks get messy and also possibly break working bsps.
All that said, it does seem wasteful to have a plethora of bsps with very minor changes and if these tweaks can be contained in a single place it seems like a good idea.
I dont have any particular suggestions as of this moment but will give this some thought and hopefully we can come up with something that will make all happy. Sorry if this answer is not tremendously satisfying…
> On Jun 8, 2016, at 12:43 PM, Simon Ratner <si...@proxy.co> wrote:
>
> I would like to create a couple of custom bsps for boards which are
> identical to nrf51dk but a few small tweaks (e.g. led pin, flash area
> layout).
>
> From the docs, I gather that copying hw/bsp/nrf51dk and patching bsp.h and
> os_bsp.c would do the trick, and it seems that's how mynewt itself handles
> this. However, I'd really prefer not to, so I can keep up with upstream and
> avoid duplicating fixes in multiple places (like
> https://github.com/apache/incubator-mynewt-core/commit/c70353c193bf3e91a095cfc5076ac578f8e1bc69).
>
>
> Any suggestions on how to best layer my tweaks on top of an existing bsp?
> Can I abuse the deps system somehow?
>
> Simon.
Re: Base a custom bsp on an existing one
Posted by Christopher Collins <cc...@apache.org>.
Hi Wayne,
On Fri, Jun 17, 2016 at 02:28:26PM +0100, Wayne Keenan wrote:
> or perhaps I'll break up my app into parts that can be independently
> included as dependencies in the pkg.deps section of pkg.yml.
> > Is it possible to use 'features' to include/exclude subdirectories of
> > source and include under app/myapp/ ?
> >
> > For example, I may have an app which *can* use bluetooth if available, but
> > I may want to have a target with a hardware platform that doesn't have
> > bluetooth so I don't want to compile any app code that depends on Nimble
> >
> > although "#ifdef'ing FEATURE_NAME" the whole contents of many .c/.h files
> > out is possible I don't see it as desirable.
As you suspected, those are your only two options at the moment. The
design of newt favors the approach where you break your app into several
packages, since newt's "fundamental unit" is the package, rather than
the directory or file.
After removing the bluetooth-dependent parts of your app and putting
them in separate packages, there are two ways to conditionally include
them in your project:
1. #ifdefs
* A newt "feature" gets defined if your app will be using bluetooth
(e.g., BLE).
* The bluetooth-dependent library only get included as
a dependency if the bluetooth feature is defined, e.g.,
pkg.deps.BLE: <ble-depedencent-pkg>
* A preprocessor symbol gets defined if the BLE feature is defined,
e.g.,
pkg.cflags.BLE: -DBLE_PRESENT
* All calls into the BLE-dependent library are enclosed in ifdefs,
e.g.,
#ifdef BLE_PRESENT
initialize_ble();
#endif
2. Stub library
* You create two packages: my_ble_pkg and my_ble_stub. Both of
these packages expose the same interface via identically-named
header files.
* The app chooses which package it depends on based on the presence
of a feature:
pkg.deps.BLE: my_ble_pkg
pkg.deps.NO_BLE: my_ble_stub
* The my_ble_pkg contains a real implementation. The stub package
just contains function stubs which return not-supported error
codes or similar.
* The BSP defines of the BLE or NO_BLE features.
The advantage of the stub library approach is that you don't need to
litter your app code with ifdefs. However, it may not be practical to
design the app so that it is entirely ignorant of whether BLE is
supported.
I think there is some room for improvement in this area of newt, but I
don't know what the right fix would be. I think as people build Mynewt
projects we will start to see what functionality is missing. Any
thoughts you may have on the subject are very welcome, of course.
Thanks,
Chris
Re: Base a custom bsp on an existing one
Posted by Wayne Keenan <wa...@gmail.com>.
or perhaps I'll break up my app into parts that can be independently
included as dependencies in the pkg.deps section of pkg.yml.
All the best
Wayne
On 17 June 2016 at 09:41, Wayne Keenan <wa...@gmail.com> wrote:
> Is it possible to use 'features' to include/exclude subdirectories of
> source and include under app/myapp/ ?
>
> For example, I may have an app which *can* use bluetooth if available, but
> I may want to have a target with a hardware platform that doesn't have
> bluetooth so I don't want to compile any app code that depends on Nimble
>
> although "#ifdef'ing FEATURE_NAME" the whole contents of many .c/.h files
> out is possible I don't see it as desirable.
>
>
> All the best
> Wayne
>
> On 9 June 2016 at 22:36, Simon Ratner <si...@proxy.co> wrote:
>
>> Great, I'll give features a try. Thanks!
>>
>> On Thu, Jun 9, 2016 at 10:33 AM, Sterling Hughes <st...@apache.org>
>> wrote:
>>
>> > Hi Simon,
>> >
>> > I agree with Will’s response, the problem you have with “inherit’ing”
>> > BSPs, at least at this stage, is that the APIs are changing, and
>> everything
>> > that inherits the BSP will have to change as we morph APIs.
>> >
>> > However, you shouldn’t have to maintain a different BSP for every
>> slightly
>> > different version of your own boards. If you use something called
>> > features, you can control these settings.
>> >
>> > A good example of this is the Arduino zero BSP, here:
>> >
>> > https://github.com/runtimeinc/mynewt_arduino_zero
>> >
>> > If you look at the pkg.yml in hw/bsp/arduino_zero (
>> >
>> https://github.com/runtimeinc/mynewt_arduino_zero/tree/master/hw/bsp/arduino_zero
>> ),
>> > you’ll see the following lines:
>> >
>> > pkg.cflags.arduino_zero_pro: -DARDUINO_ZERO_PRO
>> > pkg.cflags.arduino_zero: -DARDUINO_ZERO
>> >
>> > This changes the values of the CFLAGS based upon which feature is set,
>> > either arduino_zero or arduino_zero_pro. This is to accommodate the
>> fact
>> > that on the board, two pins are swapped depending on whether you get it
>> > from .cc or .org. The C code can then check this with #ifdefs.
>> >
>> > Features allow you to change dependencies, cflags, lflags and anything
>> > else, depending on which features are set in the build system. Features
>> > can be either specified as a package variable (pkg.features), or at the
>> > target level by doing
>> >
>> > $ newt target set your_target features=“feature1 feature2”
>> >
>> > Features are global to the build system, and everything will respect
>> them.
>> >
>> > sterling
>> >
>> >
>> > On 8 Jun 2016, at 12:43, Simon Ratner wrote:
>> >
>> > I would like to create a couple of custom bsps for boards which are
>> >> identical to nrf51dk but a few small tweaks (e.g. led pin, flash area
>> >> layout).
>> >>
>> >> From the docs, I gather that copying hw/bsp/nrf51dk and patching bsp.h
>> and
>> >> os_bsp.c would do the trick, and it seems that's how mynewt itself
>> handles
>> >> this. However, I'd really prefer not to, so I can keep up with upstream
>> >> and
>> >> avoid duplicating fixes in multiple places (like
>> >>
>> >>
>> https://github.com/apache/incubator-mynewt-core/commit/c70353c193bf3e91a095cfc5076ac578f8e1bc69
>> >> ).
>> >>
>> >>
>> >> Any suggestions on how to best layer my tweaks on top of an existing
>> bsp?
>> >> Can I abuse the deps system somehow?
>> >>
>> >> Simon.
>> >>
>> >
>>
>
>
Re: Base a custom bsp on an existing one
Posted by Wayne Keenan <wa...@gmail.com>.
Is it possible to use 'features' to include/exclude subdirectories of
source and include under app/myapp/ ?
For example, I may have an app which *can* use bluetooth if available, but
I may want to have a target with a hardware platform that doesn't have
bluetooth so I don't want to compile any app code that depends on Nimble
although "#ifdef'ing FEATURE_NAME" the whole contents of many .c/.h files
out is possible I don't see it as desirable.
All the best
Wayne
On 9 June 2016 at 22:36, Simon Ratner <si...@proxy.co> wrote:
> Great, I'll give features a try. Thanks!
>
> On Thu, Jun 9, 2016 at 10:33 AM, Sterling Hughes <st...@apache.org>
> wrote:
>
> > Hi Simon,
> >
> > I agree with Will’s response, the problem you have with “inherit’ing”
> > BSPs, at least at this stage, is that the APIs are changing, and
> everything
> > that inherits the BSP will have to change as we morph APIs.
> >
> > However, you shouldn’t have to maintain a different BSP for every
> slightly
> > different version of your own boards. If you use something called
> > features, you can control these settings.
> >
> > A good example of this is the Arduino zero BSP, here:
> >
> > https://github.com/runtimeinc/mynewt_arduino_zero
> >
> > If you look at the pkg.yml in hw/bsp/arduino_zero (
> >
> https://github.com/runtimeinc/mynewt_arduino_zero/tree/master/hw/bsp/arduino_zero
> ),
> > you’ll see the following lines:
> >
> > pkg.cflags.arduino_zero_pro: -DARDUINO_ZERO_PRO
> > pkg.cflags.arduino_zero: -DARDUINO_ZERO
> >
> > This changes the values of the CFLAGS based upon which feature is set,
> > either arduino_zero or arduino_zero_pro. This is to accommodate the fact
> > that on the board, two pins are swapped depending on whether you get it
> > from .cc or .org. The C code can then check this with #ifdefs.
> >
> > Features allow you to change dependencies, cflags, lflags and anything
> > else, depending on which features are set in the build system. Features
> > can be either specified as a package variable (pkg.features), or at the
> > target level by doing
> >
> > $ newt target set your_target features=“feature1 feature2”
> >
> > Features are global to the build system, and everything will respect
> them.
> >
> > sterling
> >
> >
> > On 8 Jun 2016, at 12:43, Simon Ratner wrote:
> >
> > I would like to create a couple of custom bsps for boards which are
> >> identical to nrf51dk but a few small tweaks (e.g. led pin, flash area
> >> layout).
> >>
> >> From the docs, I gather that copying hw/bsp/nrf51dk and patching bsp.h
> and
> >> os_bsp.c would do the trick, and it seems that's how mynewt itself
> handles
> >> this. However, I'd really prefer not to, so I can keep up with upstream
> >> and
> >> avoid duplicating fixes in multiple places (like
> >>
> >>
> https://github.com/apache/incubator-mynewt-core/commit/c70353c193bf3e91a095cfc5076ac578f8e1bc69
> >> ).
> >>
> >>
> >> Any suggestions on how to best layer my tweaks on top of an existing
> bsp?
> >> Can I abuse the deps system somehow?
> >>
> >> Simon.
> >>
> >
>
Re: Base a custom bsp on an existing one
Posted by Simon Ratner <si...@proxy.co>.
Great, I'll give features a try. Thanks!
On Thu, Jun 9, 2016 at 10:33 AM, Sterling Hughes <st...@apache.org>
wrote:
> Hi Simon,
>
> I agree with Will’s response, the problem you have with “inherit’ing”
> BSPs, at least at this stage, is that the APIs are changing, and everything
> that inherits the BSP will have to change as we morph APIs.
>
> However, you shouldn’t have to maintain a different BSP for every slightly
> different version of your own boards. If you use something called
> features, you can control these settings.
>
> A good example of this is the Arduino zero BSP, here:
>
> https://github.com/runtimeinc/mynewt_arduino_zero
>
> If you look at the pkg.yml in hw/bsp/arduino_zero (
> https://github.com/runtimeinc/mynewt_arduino_zero/tree/master/hw/bsp/arduino_zero),
> you’ll see the following lines:
>
> pkg.cflags.arduino_zero_pro: -DARDUINO_ZERO_PRO
> pkg.cflags.arduino_zero: -DARDUINO_ZERO
>
> This changes the values of the CFLAGS based upon which feature is set,
> either arduino_zero or arduino_zero_pro. This is to accommodate the fact
> that on the board, two pins are swapped depending on whether you get it
> from .cc or .org. The C code can then check this with #ifdefs.
>
> Features allow you to change dependencies, cflags, lflags and anything
> else, depending on which features are set in the build system. Features
> can be either specified as a package variable (pkg.features), or at the
> target level by doing
>
> $ newt target set your_target features=“feature1 feature2”
>
> Features are global to the build system, and everything will respect them.
>
> sterling
>
>
> On 8 Jun 2016, at 12:43, Simon Ratner wrote:
>
> I would like to create a couple of custom bsps for boards which are
>> identical to nrf51dk but a few small tweaks (e.g. led pin, flash area
>> layout).
>>
>> From the docs, I gather that copying hw/bsp/nrf51dk and patching bsp.h and
>> os_bsp.c would do the trick, and it seems that's how mynewt itself handles
>> this. However, I'd really prefer not to, so I can keep up with upstream
>> and
>> avoid duplicating fixes in multiple places (like
>>
>> https://github.com/apache/incubator-mynewt-core/commit/c70353c193bf3e91a095cfc5076ac578f8e1bc69
>> ).
>>
>>
>> Any suggestions on how to best layer my tweaks on top of an existing bsp?
>> Can I abuse the deps system somehow?
>>
>> Simon.
>>
>
Re: Base a custom bsp on an existing one
Posted by Sterling Hughes <st...@apache.org>.
Hi Simon,
I agree with Will’s response, the problem you have with
“inherit’ing” BSPs, at least at this stage, is that the APIs are
changing, and everything that inherits the BSP will have to change as we
morph APIs.
However, you shouldn’t have to maintain a different BSP for every
slightly different version of your own boards. If you use something
called features, you can control these settings.
A good example of this is the Arduino zero BSP, here:
https://github.com/runtimeinc/mynewt_arduino_zero
If you look at the pkg.yml in hw/bsp/arduino_zero
(https://github.com/runtimeinc/mynewt_arduino_zero/tree/master/hw/bsp/arduino_zero),
you’ll see the following lines:
pkg.cflags.arduino_zero_pro: -DARDUINO_ZERO_PRO
pkg.cflags.arduino_zero: -DARDUINO_ZERO
This changes the values of the CFLAGS based upon which feature is set,
either arduino_zero or arduino_zero_pro. This is to accommodate the
fact that on the board, two pins are swapped depending on whether you
get it from .cc or .org. The C code can then check this with #ifdefs.
Features allow you to change dependencies, cflags, lflags and anything
else, depending on which features are set in the build system. Features
can be either specified as a package variable (pkg.features), or at the
target level by doing
$ newt target set your_target features=“feature1 feature2”
Features are global to the build system, and everything will respect
them.
sterling
On 8 Jun 2016, at 12:43, Simon Ratner wrote:
> I would like to create a couple of custom bsps for boards which are
> identical to nrf51dk but a few small tweaks (e.g. led pin, flash area
> layout).
>
> From the docs, I gather that copying hw/bsp/nrf51dk and patching bsp.h
> and
> os_bsp.c would do the trick, and it seems that's how mynewt itself
> handles
> this. However, I'd really prefer not to, so I can keep up with
> upstream and
> avoid duplicating fixes in multiple places (like
> https://github.com/apache/incubator-mynewt-core/commit/c70353c193bf3e91a095cfc5076ac578f8e1bc69).
>
>
> Any suggestions on how to best layer my tweaks on top of an existing
> bsp?
> Can I abuse the deps system somehow?
>
> Simon.