ManuvrOS is the open-source software that forms the asynchronous core of a Manuvrable. It was designed to be easily extensible, platform abstract wherever possible, and have the challenges of IoT as its central design constraint set.
ManuvrOS will always be open-source. It is the framework on which all of Manuvr's products are built.
TL;DR... just show me how to build it.
Building is straight-forward on a RasPi.
~/$ git clone git@github.com:jspark311/ManuvrOS.git
~/$ make
~/$ ./manuvr
The README.md file also contains instructions for building in an Arduino environment.
Design principles
1. Communication with peers is a core function.
Communication is the differentiating characteristic of an IoT device. This becomes tricky to talk about, because internet-connected appliances of various sorts have been in common use for many years. The thing that will make this time different is that distributed organization and emergent behavior has now become an easier thing to achieve at the sizes, power-efficiency, and cost-points of modern microcontrollers. Which brings us to the first design goal of ManuvrOS: de facto peer-to-peer communication support with auto-negotiation of device capabilities and identity.
Communication has its own set of problems, both theoretical and in practice. Aside from the much-hyped security problems, there are problems of discovery (who is nearby), protocol (how do we talk to each-other), and the distillation of meaning and intention between devices that were (quite probably) not intended to mutually interact. All these matters, and the (not-to-be-trivialized) security concerns will be covered in specialized posts.
2. Asynchronicity is a feature of the Natural world, and programming cheap computers with that mindset ought to be easier than it is at present.
Reality at our scale is not synchronous. But computers are. The author of a firmware program cannot afford to have vis interrupt service routines doing long-running tasks on-the-event as a purely-functional approach would demand[^1]. Since a sophisticated program typically needs to be doing several things at once, and since the real-world cannot be paused while the CPU does them, any program reacting to real-world stimulus is obliged to have a means of chunking up the work it can't manage at the moment, and returning to it when time is available.
Solving this problem of time-allocation is the basic design goal of any operating system.
ManuvrOS allows the fast, reliable authoring of asynchronous IoT firmware by means of Events, priority queues, and a built-in abstraction layer for communication. Each of these things will be covered in later posts.
If the goal is build software that interacts in a "natural" manner (with us and itself), we should probably learn from (and emulate) Nature. And that means that some form of an asynchronous artifice needs to be created over the clock-bound state-machine that is a CPU.
That artifice is ManuvrOS.
Anticipated questions
1. Is this a replacement for other embedded operating systems?
It depends. It can be if you already have the support code for your platform, and are simply needing to coordinate software and real-world events. This would include usage of ManuvrOS in an Arduino project. For an example of this use-case, see Viam Sonus.
However, there is also a test-bench application that is meant to be built on a Raspberry Pi (or any linux environment, for that matter). In this context, ManuvrOS will build to a shared library named libmanuvr.so, where it will happily manage asynchronous events within linux userland.
2. Why not use an already extant package such as RToS
Future development road-maps may see supported ports into RToS. But our use-cases for ManuvrOS (specifically, Digitabulum) are very sensitive to latency and resource allocation patterns.
3. Do you guys know about libuv, and if so, why aren't you using it in the linux builds of ManuvrOS?
Yes, we do know of libuv. And yes, we ought to be migrating the "large-environment" builds into that package. Our constraint is time. If you are interested in extending ManuvrOS to libuv, or other microcontroller platforms, we are always happy to answer questions, give tips/hints, and accept pull requests for well-written code.
4. Why is feature
(Time constraint) | (ROI analysis)
Want something specific? Submitting issues on github is probably the best way to get things sorted out. It will also inform the right-hand-side of the relationship above.
Notes, asides, and citations
[1]: I am of the mindset that the natural world is representable as (if not actually is) a process of computation, and that the stack-limited-scope and expression of recursion in the functional programming paradigm is the best current means of representing these features of reality in a Von Neumann CPU.
For reasons I might digress into later, state-machines are notoriously tricky things to build in a functional language. Watching my teammates argue with this issue in JavaScript (MHB) has been particularly educational. Being the Cpp junkie that I am, state-machines and pointer-access drive a great deal of the internal logic in my programs because this directly reflects the organizing principles of the machine I'm programming, and makes the best possible use of the hardware for that reason. But it also means that a purely-functional approach to many problems is not advisable (although C might allow it).
When you come to the point of considering 192KB of RAM to be spacious, iteration over state-machines looks much more appealing than recursion over immutable data on the stack. So ManuvrOS generally doesn't recurse or copy data, except in limited circumstances.
