On Tue, Oct 6, 2015 at 7:48 AM, Sterling Hughes <sterl...@apache.org> wrote: > On Mon, Oct 5, 2015 at 9:24 PM, David Nalley <da...@gnsa.us> 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: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
