Hi,
As a part of the HAL refactor, I’m looking at how we can allow
external libraries to be more easily brought in, specifically driver
packages from the various MCU vendors. Most MCU vendors have a fair
amount of very useful code written for their processor that we want to
leverage when implementing the various HALs and BSPs. Examples of these
packages can be found:
- https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF5-SDK
- http://www.atmel.com/tools/AVRSOFTWAREFRAMEWORK.aspx
When adding these packages to the Mynewt system, a few things are
desirable:
- Minimizing source code changes in vendor drivers
- Keeping track of vendor SDK versions
- Keeping track of patches to these vendor SDKs
In order to do these, there are a couple of changes I’m contemplating
making to newt:
- Add a new package type, pkg.type = SDK
- Add a pkg.sdk_vers field, which indicates the version of the SDK, and
pkg.sdk_url which is the URL used to grab this SDK version.
- Add a command “newt list-sdks” which lists the SDK packages, and
the URL used to grab them.
- For pkg.type == SDK, add an “ext” directory in the source folder,
which is special cased.
- The ext directory has the following build and include rules:
- The ext directory should have a sdk directory in it, which contains
the contents of the vendor sdk.
- For people who want to include a SDK package, they will have SDK/ as
the base of the include path
- Newt will build sdk, when it does, it will first recurse the SDK
directory, and add every sub-directory of sdk/ to the include/ path when
building SDK
- sdk/ext can contain override headers for the SDK, and will be the
first element in the include path
I don’t really have a good way to keep track of patches yet, but my
initial lean is to search ext/ for anything with a *.patch extension.
If *.patch is present, mark it in newt list-sdks, and let people go
search that directory for any diffs that are distributed.
One thing I was thinking of, is allowing for multiple versions of a SDK
to be included. This could be done, by having a ext/vers/sdk structure
to the directory, and letting the package include select this. The only
real use case I could think of for this, is if you want to upgrade the
OS, but not the version of vendor SDK you are using for some reason.
However, I don’t think this would be a common use case, and in any
case, at that point you can always create a custom vendor SDK package
and lock your app to that.
Thoughts? Anything additional folks think is helpful here?
Sterling
