Frequently Asked Questions

Where can I buy Mountaineer boards?

In Switzerland and some other European countries, directly from a Web shop operated by the Mountaineer Group itself. In all countries, they can be ordered from Mouser.

Where are the Mountaineer boards produced?

Some of the boards are produced in Switzerland, some of the boards are produced by GHI Electronics in the United States.

Is there a Mountaineer community?

Yes, you can find it on the GHI forum.

.NET on a microcontroller? Isn't .NET far too large for that?

The original implementation for PCs and servers is indeed way too large for a microcontroller, and provides much functionality not needed in an embedded system. However, the .NET Micro Framework is a completely separate implementation, with a carefully chosen subset of the .NET libraries, especially designed for microcontrollers. It is only about one percent (!) of the full framework's size. You can build useful, albeit small, NETMF applications for microcontrollers that have a total of 48 KB of RAM. For someone used to developing software for resource-constrained devices, a micro-controller with 96 KB of RAM is comfortable, one with 192 KB of RAM downright luxurious, not to speak of the high-end 256 KB parts. And this enables application (and to a large extent, even driver) development in C#, cross-developing from Visual Studio, symbolic debugging with breakpoints, etc.

Is Microsoft's NETMF really open source?

The Apache 2.0 license is one of the most popular open source licenses. Examples of Apache-licensed projects are Apache Tomcat (Web server), Apache Subversion (version control system), and Google's Android. Unlike GPL-licensed software, you can use, modify and distribute Apache-licensed software, both non-commercially or commercially, without having to publish your changes. As far as we are concerned, this license is extremely open.

Why did you open-source NETMF for STM32 and the Mountaineer boards?

Managed code enables us to write more robust code faster. We like programming environments in which we can work quickly. However, as engineers, we do not like hacking together some code that barely works, and will break down completely when the first change requests are implemented. Managed code is an effective aid for achieving both robustness and productivity. We want to use these advantages in at least some of our embedded projects as well. By contributing to the NETMF platform and by creating suitable hardware designs, we helped expand the scope of mission-critical projects for which NETMF is suitable. It is now possible to use modern Cortex-M microcontrollers without having to do the difficult architecture port from older ARM microcontrollers. And now there are boards that allow the quick and low-risk development of prototypes, and have a path towards optimized "industrial strength" custom boards as well. We don't depend on anyone else's code that we cannot change, nor are we drowned in millions of lines of code of large operating systems. In a time-honored Swiss tradition, we like to cooperate and contribute, nevertheless want to remain fiercely independent as well.

Is this an open source / open hardware project?

If we distinguish between open source software and open source projects, then Mountaineer and NETMF for STM32 are open source software / hardware, but not open source projects. Why not? Our companies have developed these assets for our own internal uses, and for our customers (usually medium to large enterprises). And as we have profited from the openness of NETMF ourselves, it seemed only fair that we contribute back. However, we do not have the resources to manage open source projects: to constantly interact with the community, to regularly and quickly assess and integrate submitted contributions, etc.

What are the further goals with your software?

For our software, we have the following goals:

  • We understand NETMF for STM32 well enough, including the STM32-specific drivers, that we can reliably judge whether NETMF is suitable for a customer's mission-critical application, or not.
  • We are able to modify anything in order to make our customers' projects successful.
  • No embedded platform is suitable for every application. We want to steadily increase the range of mission-critical applications for which NETMF is suitable, even excels.
  • We want to keep NETMF for STM32 in sync with Microsoft's official NETMF releases.
  • Over time, we want NETMF for STM32 to earn its place as the gold standard for robust NETMF implementations.

 

To achieve these goals with our very limited resources, we established the following policies:

  • We do not accept contributions to the portable part of NETMF (PAL layer). Such contributions should be submitted directly to Microsoft via Codeplex. They will automatically come back to us later, after Microsoft has integrated them into the NETMF mainline.
  • In more or less regular intervals of about three months (paying customers always get preference), we will look at possible issues of our STM32 HAL-layer code that have been submitted on Codeplex.
  • For non-critical issues, we will focus on those issues that are clearly described and can be reproduced most easily, or come with a good analysis of their root causes.
  • We give priority to robustness over new functionality, to reliability and maintainability over quick-and-dirty fixes, and to customer-relevant issues over others.

Through the above policies, and the community support provided by companies like GHI Electronics and SecretLabs, we hope to be able to further contribute to NETMF from time to time. Even if our work is done mostly in the background.

Is it possible to program a Mountaineer system even without the Gadgeteer libraries, using "plain vanilla NETMF"?

Yes. If you only use modules with digital or analog I/O - including PWM - then the standard NETMF drivers are all that you need. If you use UARTs, SPI or I2C buses, you also have access to these communication mechanisms through standard NETMF drivers. However, the modules may require some more or less complex protocol on top of these buses. In such a case, you want to find out whether the driver that comes with the module allows use without Gadgeteer, or is available in source form so that it can be adapted. All Mountaineer-branded modules can be used with and without Gadgeteer, as "plain vanilla NETMF" is often the best choice in commercial projects.

Is it possible to program a Mountaineer system even without NETMF, using some other RTOS?

Yes. We clearly focus on NETMF, because of its unique nature as a small bootable managed code runtime and its integration into the larger .NET ecosystem. However, the fundamental nature of embedded systems is their extreme variety. As a result, no single platform can be the best choice for all projects. There exists support for various operating systems for STM32, e.g., FreeRTOS, ECos, and Contiki. uClinux is too large, it would require several MB of external RAM (which would be possible with the larger STM32 packages that support a bus to external memories, but would require the design of a larger mainboard, such as the Mountaineer Prime M4-MCU board). You would probably need to write your own drivers for 3rd party modules, though.

Does Mountaineer fragment the Gadgeteer platform, by introducing incompatibilities?

Not at all. Every Mountaineer board is a true Gadgeteer board, and compatible with other Gadgeteer products. We simply constrained the mechanical design space slightly, to make use of the boards easier in some situations.

Can I produce boards that adhere to the Mountaineer Design Rules?

Sure, see the design rules here. However, you must not call them Mountaineer boards, as Mountaineer is our trademark.

Will there be more Mountaineer boards?

That's possible, but will depend on where our customer projects lead us. There is no product roadmap, as we are not product companies. However, see our Mountaineer Prime reference designs, which can be licensed.

Besides software and hardware, will there also be Mountaineer cloud services?

There are no plans for such services. Note, however, that Yaler GmbH, which is a spin-off of Oberon microsystems, hosts a relay service that allows to connect to devices behind firewalls.