The Mountaineer Platform: Safe Path from Idea to Product

"People who are really serious about software should make their own hardware."

Alan Kay

If you want to write software for controlling a rocket’s trajectory, then you basically need to understand the physics of such a system, and then implement software that controls the rocket accordingly. You may simulate launches to test the software, and finally test the “real thing”. You are tempted to delay flight testing as much as possible, as any such attempt is highly expensive – in particular if it is a failure that destroys the rocket plus the house into which it crashes...

As engineers, we often follow this role model when creating a novel product. Alas, it is the worst possible approach for many product developments that are “of this earth”. The reason is that most products - including products that contain embedded systems - are primarily meant to provide some direct benefit to a human user, and at most indirectly to satisfy some law of physics. If these users are not satisfied with a product, it will fail. Unfortunately, customer satisfaction is a deceptive and fickle target, compared to the well-known, stable laws of physics. Potential customers may reject a perfectly functional toaster because they don’t like its user interface. Bad user interaction design is a frequent cause of failure in the market. Another frequent cause is even more fundamental: products often don’t provide benefits that users want – don’t develop a toaster for people who only want to bake cakes.

Engineers – and management – hope that market research has made sure that the right product will be developed, i.e., a product that provides so much value to its customers that they buy it. Product development is planned well in advance, and then the plan is executed as faithfully as possible. For well-known product categories like toasters and ovens this works pretty well. It usually fails completely if the product is novel in its kind. There is simply too much uncertainty about what customers may actually value - not just the uncertainty what kind of user interaction they would accept, or how such a product could be implemented technologically. As potential customers cannot understand a truly novel product if they are merely given an abstract description, it isn't even sufficient to interview them.

Modern embedded devices, especially when part of some larger Internet-connected “ecosystem”, are novel products in most cases. Even their business models are often unproven and a radical departure from how things have been done before. A customer literally needs to touch such a product in order to know whether she likes it.

The Lean Startup Method by Eric Ries is a way to reduce the investments into failed product developments in such an environment. The idea is to develop products iteratively, by repeatedly building new product versions as quickly as possible, by using real customers to measure their acceptance, and by learning from the results. In order to avoid the fatal “let’s just hack away” trap, each iteration is treated as a scientific experiment with explicit hypotheses to be tested. If necessary, the course is corrected, possibly leading to a product very different from the one originally envisioned. Which is exactly the right thing to do if the original vision was flawed.

But how do you quickly build new versions of an embedded system? Note that we are talking multiple prototypes here that can be tested with real customers and improved in quick iterations. Exotic tool suites, libraries intricately coupled to specific hardware components, the costs for developing custom boards, and the need for developers with combined software and hardware skills make iterative embedded development difficult, slow and expensive.

Exactly this frustration led a team at Microsoft Research to create the .NET Gadgeteer platform (see video). This is a small class library plus a set of rules about how to attach all kinds of add-on modules to a processor board ("mainboard"). The goal is to simplify the integration of hardware (and the corresponding driver software) from different vendors. This allows to quickly and safely put together a complete system without soldering and to take it apart again for later reuse of the valuable modules.

A mainboard is the core of a .NET Gadgeteer device and contains the microcontroller and a number of sockets. The sockets are physically identical 10-pin connectors, but each socket defines its own set of socket types that it supports. For example, socket 6 on our mainboards allows its use as an analog input socket (type “A”), as an I2C bus socket (type “I”), as an analog output socket (type “O”), or as a digital input/output socket (type “X”). You can connect a cable from this socket to any module that has a corresponding socket of type “A”, “I”, “O”, or “X”. No soldering necessary, no danger of accidentally destroying a board. And once you have learned all that you can from a prototype, you can take it apart and reuse the components for the next prototype.

So basically, .NET Gadgeteer is a way of assigning the plethora of functions that a microcontroller provides to sockets that have a standardized, small set of interfaces at the hardware level (socket types). Electrical compatibility of modules with mainboards can be easily determined from these socket types, rather than from studying data "sheets" with hundreds of pages of technical descriptions.

Here are the socket types currently defined for the .NET Gadgeteer platform:

Source: Microsoft's .NET Gadgeteer Module Builder's Guide

To enable high productivity also at the software level, .NET Gadgeteer is programmed in C# using Visual Studio. To make this possible, it uses a .NET implementation specifically designed to run even on small, inexpensive microcontrollers with limited amounts of RAM and Flash. This is the .NET Micro Framework (note the Micro in the name!), which is about a hundred times smaller than the full .NET framework on the desktop. Yet it allows using Visual Studio, including things like symbolic debugging with breakpoints; it supports automatic garbage collection; and it also provides a processor-independent class library for accessing digital and analog inputs and outputs and other hardware specific to embedded systems. Notably, both the .NET Micro Framework and .NET Gadgeteer are published under the liberal Apache 2.0 open source license.

The Mountaineer Platform is our collection of .NET Gadgeteer-compatible open source hardware and software components. The hardware consists of two Gadgeteer mainboards. The software consists of our own port of the .NET Micro Framework to the increasingly popular ARM Cortex-M (warning: this is a link to a 5 MB document) microcontroller architecture, more specifically to the STM32F4 microcontroller family of STMicroelectronics.

The two mainboards are very similar, except that one is very small (the Mountaineer USB Mainboard), while the other additionally provides built-in Ethernet connectivity (the Mountaineer Ethernet Mainboard).

Our focus is on systems that need as few components as possible - ideally, only a microcontroller and nothing more. We have managed to run the Gadgeteer platform entirely on a Mountaineer mainboard's microcontroller itself, i.e., in its internal RAM and internal Flash memories. This approach allows us to minimize the cost and space premium of using such a flexible platform.

The Ethernet mainboard integrates three traditional Gadgeteer boards into one: the mainboard, a power supply / USB device module, and an Ethernet module.

Here are the detailed specifications of the two mainboards:

As the Mountaineer Platform is completely open source, including the hardware, we provide design files along with the source code of the firmware. Some design aspects are described here.

Of course, our mainboards are compatible with Gadgeteer modules from other vendors.

The Lean Startup Method relies on a rapid succession of experiments with real customers, where every experiment is intended to fail (or succeed) as fast as possible, so that learning happens as quickly as possible. With hardware products, this is acceptable only as long as you work with a small number of customers and low volume of products, so that you can replace the hardware of your customers with new, improved product versions if necessary. Once you step up to large volume production, the rules change radically: the hardware itself needs to be nearly perfect, because a recall would be prohibitively expensive.

"Perfection" here means that some of the prototypes'  qualities need to be increased: e.g., smaller size, less power consumption, increased vibration resilience, regulatory approvals, reduced price. The latter is particularly relevant if you gear up to larger production runs, say tens of thousands of devices.

In such cases, all of the mentioned quality improvements can be achieved by creating a new custom board that combines a mainboard and all necessary modules onto a single printed circuit board (PCB) – but leaves out all unnecessary features, and all sockets and cables. Often, it is possible to use another member of the same microcontroller family that is slower or has less memory, and is therefore usually less expensive, consumes less power, and takes up less board space. Or another member of the same microcontroller family with a larger package that provides address and data buses, so that large external memories can be provided for applications that need it.

At the software level, it is similarly possible to perform various optimizations, once a product's resource requirements are better known. While a complete rewrite in C would allow wringing out the last cent from the component costs, this is only warranted if you intend to produce hundreds of thousands of devices.

To achieve, or at least approximate, perfection well enough, requires competent engineering and usually a lot of work. This is where the Mountaineer Group can help you in particular. While we love to help you develope prototypes if you don't want to do them all yourself, we can also help you scale up to industrial-strength or cost-optimized high-volume production.

We have developed the Mountaineer boards primarily for our clients and the engineering work that we do for them. They are not available outside of engineering projects.