We believe that, while C is a powerful and efficient language, it does not provide adequate support for defining higher level abstractions. We feel that language extension is the way to introduce abstractions relevant to embedded software development into C. Initial experience with mbeddr in a real world project confirms this belief.

Examples include components (incl. interfaces with pre- and postconditions, ports and connectors), data types with physical units (as in 300 km/h) and state machines. Many smaller but very useful extensions, such as counters and decision tables are also supported. Support for cross-cutting concerns such as requirements tracing and product line variability are available as well. Additional extensions have been inspired by our application partners SICK and BMW Car IT, and specifically target use cases encountered in their domains.

We perceive the embedded development world as being made up of two camps. One camp uses bare-bones C to develop highly efficient, low level code. The other camp uses tools such as Matlab/Simulink, Ascet or similar tools to "model and synthesize" executable software. We position mbeddr in the middle between the two: you still primarily write code, but with meaningful, customizable abstractions. As a consequence of tight syntactic, semantic and tool-wise integration between the various languages, tool integration becomes a no-brainer. This makes mbeddr especially suitable for multi-paradigm programming/modeling, i.e. systems that use more than one programming/modeling approach.

Libraries don't support custom syntax, static error checking and efficient translation. Language extension can provide all of these. However, libraries of course still play an important role, we don't claim that language extension is the solution to all problems. Language extension also makes programs accessible for meaningful static analysis. Support for model checking or constraint solving is an important ingredient of the approach.

Macros can provide some of the same efficiency (because they are translated statically). However, you cannot implement context-specific optimizations, and macros do not come with support for the type system and the IDE. Experience tells that using macros a lot turns your software into a maintenance nightmare.

We are implementing essentially all of C, with a few differences. There are various reasons for these differences. For some of them, we feel we are compensating weaknesses of C (int vs. boolean). For others, we exploit the capabilities of MPS and the generative approach (modules). Yet others just make our lives as implementers more pleasant (arrays and pointers after type instead of variable name). However, we are generating ANSI C99, so the generated code is compatible with existing target systems.

We have started implementing the basics of C++. The challenge with C++ is the type system for templates. We are not yet sure how far we will be going there; instead of using template meta programming, mbeddr users can use language extensions to achieve many of the same effects in a more elegant and robust way.

No. MPS works by progressively reducing higher abstractions to lower abstractions, leading to ANSI C99 at the end of the chain. That C code can be compiled with existing compilers. We use GCC currently, but others can be plugged in.

mbeddr has a debugger. It supports all of C and most of the existing extensions. When debugging, users step through the code on the level of the extensions, not the low-level implementation. Like the mbeddr languages themselves, the debugger is extensible. The debugger uses the Eclipse CDT Debug Bridge in the backend, so various target platform-specific debuggers can be plugged in.

The C preprocessor is (mis)used for a number of different things in C, including definition of constants, visibility management (header files) and expressing variants of programs. We provide first class support for these use cases in our language. For example, a module system with explicit visibility control is provided. For expressing code variants, we provide first class support for variant management, incl. static verification of correctness (see this short paper). Of course we generate C code that makes use of the preprocessor for some of these use cases, but we don't expose it to users.

We have an importer for all of C. We are working on a debugger that maps #ifdefs to product line variability. Unfortunately, the importer uses non-open source technology, so the importer will not be open source. However, a trial version will become available later in 2013.

mbeddr is open source; you can get it from here. It is licensed under the Eclipse Public License.

While Xtext is a very good and widely used language workbench, it is also limited in many ways, particularly regarding language modularization and composition as well as non-textual notations. MPS is a much more productive environment for working with lots of modular languages.

As of now, the system is built on MPS and MPS is not integrated with Eclipse. However, there is an EMF export for language meta models and programs. JetBrains has also agreed to provide an Eclipse-integrated version of MPS if this becomes necessary for adoption of mbeddr.

Currently all notations used by mbeddr are textual, tabular or symbolic because MPS does not yet support graphical notations. However, MPS will start providing support for graphical notations in early 2014, and we will use them for state machines and components as soon as they become available. In the meantime, mbeddr already supports automatically-generated, read-only visualizations for various extensions based on graphviz, and a viewer that is directly integrated into MPS and provides drill-down support (double-click an element in the view, and the editor opens for this element).

A number of prototypical systems have been built, and a first commercial project is currently being developed. We are also working with a major tool vendor on a commercial development tool based on mbeddr. mbeddr is usable, scales well and is stable enough. Some minor usability challenges with MPS still remain, but these will be fixed until early 2014. In other words: yes, now is the time to seriously investigate mbeddr.