incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: [DISCUSS] Mynewt Incubation Proposal
Date Tue, 06 Oct 2015 08:37:36 GMT
On Tue, Oct 6, 2015 at 7:48 AM, Sterling Hughes <> wrote:
> On Mon, Oct 5, 2015 at 9:24 PM, David Nalley <> wrote:
>> Hi Sterling, this looks fascinating.
>> I have a few questions for you:
>> How many arches are you targeting initially? I saw ARM and MIPS
>> commented below, but not sure if that's the initial list, or just a
>> few notable.
> ARM and MIPs are the main processors we're working on.  From ARM, the
> Cortex-M series, which is very popular in new connected device
> platforms, pretty much across the board (from industrial to
> wearables.)
> We're also planning on porting to AVR, because Arduino uses it.
> The goal is to work well across 8-32bit systems, and there are others
> we don't have plans for, but would be happy to accommodate.  I'd love
> to see a MSP port.
>> What's the CI/Build/Testing environment that you currently have? How
>> many nodes, how is it managed?
> We have no CI environment setup, yet.  Its something we definitely
> need, especially as we expand the number of supported platforms.
> We have two types of regression tests currently implemented:
> - "Native": Simulated on Linux and Mac OS X.  We compile the OS &
> libraries with 32-bit GCC, and then use setjmp() and longjmp() to save
> and restore our task stacks, and signals to provide a timing interval.
> Every egg (package) has unit tests that run in this simulated
> environment, and per-egg unit tests can be run natively on your PC.
> - "Project": The per-package regression tests can be combined into a
> build project designed to test them for a specific platform (e.g.
> olimex-stm32-e407.)  The project defines what packages to include, and
> what tests to run.  This produces an ELF file that can be loaded on
> the native platform, and the tests will spit their results to the
> local FS on that platform.

How much hardware are you going to end up needing to do this?

> We're looking for help getting both the basic CI setup (running the
> "native" / "simulated" tests automatically), and the super-fancy
> version, where we compile for every platform, automagically run the
> regression tests, and spit out the results on every commit.
>> I haven't spent much time in the embedded world, so my understanding
>> is a bit nascent, so forgive my ignorance. I see you have some package
>> management tools, are you planning on having package repositories? How
>> large do you expect your manifest of available packages to grow to?
> Yes, inherent to the OS is a source package management and build tool
> called "newt."  The idea here is to have a stable core (OS, HAL) and
> then allow that core to have a number of eggs (packages) built around
> it for all the areas where an RTOS makes sense.  The newt tool can
> automatically download, resolve depedencies and install eggs.  This
> enables a developer who is creating a project to only include what
> they need for their project (BSPs, Networking stacks, etc.)
> As an example of how broad this can be, a wireless power meter and a
> wearable will likely share:
> - Bootloader, OS, HAL, FS
> But the power meter will want an IP stack that looks like: 6lowpan,
> ROLL/RPL, 802.15.4g/e, CoAP, whereas a wearable device will likely
> want a BLE stack, and the BLE profiles associated with heart rate,
> etc.  The alternative would be to have  one monolithic source tree
> with a lot of build options (Linux.) However, this can lead to highly
> interdependent code, which makes it hard to strip down the kernel (and
> remember: on small systems, you count _bytes_ of RAM usage), and also,
> many duplicate symbols all in one source code tree, which makes
> searching through it annoying.  On the Linux side, Yocto has spent a
> lot of time re-doing the kernel build system to move more towards
> source package management with a shared core for embedded systems.
> Right now in our source code tree, Larva contains every egg developed,
> and Tadpole is just the core of the OS.  You can create a new "nest"
> (workspace), which will be populated with the contents of tadpole.
> Then you can choose which eggs you want to install from larva, as you
> compose the project.  We support resolving dependencies and installing
> eggs from multiple nests today, even if all of our eggs are in a
> single nest (larva.) (*)
> Prior to release, we'll have to decide whether we want to start with
> just a single big package repository or break it up into smaller
> multiple nests.  I imagine we'll start with one big one, and then as
> the code base grows, tease out the package repositories into distinct
> sets of functionality (that probably makes sense to test together as
> well.)

I suppose my curiosity is exactly that. Most linux distros tend to
have repo per package, though they migrated to that from a SVN tree.

> Hope that gives some color!  If you're interested in starting with
> some embedded stuff, but don't know where to start, we have dire need
> on the CI setup, and would love help on the build and package
> management code, as its very raw and could use much improvement!
> Sterling
> (*) In retrospect, we may have taken this metaphor too far. :-)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message