incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sterling Hughes <>
Subject Re: [DISCUSS] Mynewt Incubation Proposal
Date Tue, 06 Oct 2015 05:48:34 GMT
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

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.

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

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!


(*) In retrospect, we may have taken this metaphor too far. :-)

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

View raw message