On Mon, Oct 5, 2015 at 9:24 PM, David Nalley <[email protected]> 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. 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.) 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: [email protected] For additional commands, e-mail: [email protected]
