12 ms·

Mbeddr – engineering the future of embedded software

85 points by _qc3o 12y ago

damian2000 12y ago
Its great that it generates C but I'd worry that developers who are writing embedded code won't bother to try it - they often are trying to squeeze some code into a small amount of memory on a limited processor. Some of the things it provides - state machines, unit conversions and error logging are pretty simple to do within C anyway, and developers might not appreciate or want an additional level of abstraction.
- ShinyCyril 12y ago
  State Machines, as you noted, are easy to do with C. I think the added value in this respect is that this makes it much easier to manage the State Machines. I often hear guys at work complaining about how they'd like to switch to using an RTOS because the codebase is a tangled mess of State Machines (not that the two are mutually exclusive of course). Having said that, I seem to remember there is a tool dedicated to creating State Machines that compile down to C - the name escapes me however.
  - tlarkworthy 12y ago
    QP framework. Its bloody brilliant.
    - ShinyCyril 12y ago
      That's the one.
  - jacobparker 12y ago
    Ragel? http://www.complang.org/ragel/ http://www.complang.org/ragel/
- IshKebab 12y ago
  This is clearly aimed at applications that must be very reliable, e.g. life-critical applications like cars (note BMW sponsor it). Most embedded programming isn't that bug-sensitive, but quite a lot is and I'd wager they'd love something like this. I know I'd use it if I were writing safety-critical code.
  - ArkyBeagle 12y ago
    Code exists in context of a culture and processes. This may well facilitate those, but those kind of have to come first.
- sitkack 12y ago
  This adds an amazing amount of verification, but it doesn't mean that the resulting code is slow. Doing unit checks is awesome. The grid state machine view makes it easier to catch errors and refactor the transitions.
Nursie 12y ago
"A cleaned up version of C99 helps avoid low-level bugs. For example, the preprocessor is not supported" NOPE. From my cold, dead hands.
- IshKebab 12y ago
  Why? The preprocessor is a huge hack that is mostly obsolete. 99% of my programs only use `#include` and `#pragma once`.
  - metafex 12y ago
    Macros used right can really help to clean up messy code and/or reduce repeating code to something clearer (e.g. in crypto-code).
    - hrjet 12y ago
      Pre-processing macros can reduce repetition, but they are certainly a hack: They are not type-safe. They are not even syntactically safe. A missing brace in one can cause untoward damage down the chain. And getting it right is especially important in crypto-code!
  - com2kid 12y ago
    #ifdef alone #ifdef HW_REVISION_1 #ifdef HW_REVISION_2 etc
    - mackwic 12y ago
      Playing the devil's advocate, here. When possible, this kind of if_arch/else should be compartmentalized in their own object files or dynamic libraries, and then, linked conditionally to produce an unique binary. You shouldn't clutter your code with ifdef. It makes it hard to think with.
      - SixSigma 12y ago
        The whole of Plan9 is written like that. If you look here http://plan9.bell-labs.com/sources/plan9/sys/src/9/ http://plan9.bell-labs.com/sources/plan9/sys/src/9/ You can see that port & boot are the portable code. Each architecture can fall back on that less optimised code should it need to. Then each of the directories: bcm, kw, mtx, omap, pc, pcboot, ppc, rb, teg have platform specific c files This greatly eases porting to a new architecture and also means cross compilation is significantly easier. #ifdefs are rare in the source code and other pragmas are few and far between. Conditional compilation is the enemy of readable code.
sandGorgon 12y ago
Hmm... is there any relation to mbed.org ? mbed is a new methodology (supported by ARM) for programming and debugging embedded devices through CMSIS-DAP.
mackwic 12y ago
This looks great ! With the JetBrains expertise in IDE, that surely was a missing piece of software. I am slightly concerned by the DSL thing, because I don't want each embedded projects to have specific dialects like we can see on LISP projects. But, on the average, gains are high: modules ! tests ! Inline contracts and model checking ! Very nice state machines ! I like that ! Also, why C99 ? There's hardware where only C89 compilers are available...
- errordeveloper 12y ago
  Because nobody would use those chips for new projects. Legacy chips need legacy tools and run legacy software.
  - mackwic 12y ago
    I don't agree. Popular but legacy chips can have updated tools where new but conservative chips can have odd software packaging. Moreover, embedded development is conservative by nature and I know a lot of teams which prefers to run projects on known hardware when possible, even if we have to suffer of the tooling. Also, don't forget the licencing. We already have to downgrade our targeted platform because we couldn't afford to pay the whole tooling where OSS was only compatible with the previous version.
anon4 12y ago
So this is something like the friendly-C variant proposed some weeks ago?
codehero 12y ago
When I work on an embedded system, I want as few layers between my code and the assembler as possible. Even your C compiler can produce undesirable code if you don't put the proper const, volatile qualifiers on your pointers. The last thing I want is a layer of software and an IDE developed by a team that I can only assume has 0 embedded experience (judging by team page they are all architects or academics). Secondly, if I handed off a work for hire implemented in this language I would not get a next assignment. There is no room for fad modelling in the established engineering trade and unfortunately I don't have the pull to start the disruption if I truly believed in it.
- errordeveloper 12y ago
  There are two problematic types of engineers out there, some have no clue what they do and some have too much clue and wave their flags all over the place. You are in the second group and have probably been doing too much C for too long.
  - sitkack 12y ago
    Clearly a hero.
    - mackwic 12y ago
      I have to say that the sequence "errordevelopper" responding to "codehero" is quite funny. :)
  - fasteo 12y ago
    So true
  - codehero 12y ago
    I really appreciate your succinct criticism of my points, you didn't need to qualify with anything but "you have been doing C for too long." I consider that a compliment. Ask my clients how much of a problem I am and then ask them how many problems I solve. And no, I don't solve them all with C.
FnuGk 12y ago
Why not use something like rust over this? Rust should provide the safety missing in C while also providing higher abstractions and a safe macro system with about the same performance as C
- joezydeco 12y ago
  How big is the runtime? I have 64K of SRAM on my part and 512MB of onboard Flash.
  - FnuGk 12y ago
    That is quite a lot for an embedded system. looking through them comments in an earlier HN post https://news.ycombinator.com/item?id=6268291 https://news.ycombinator.com/item?id=6268291 on running rust on the arduino DUE they link to zero.rs that should make it possible to run without any runtime
    - errordeveloper 12y ago
      Zero.rs is dead now. Checkout http://zinc.rs http://zinc.rs :)
      - mackwic 12y ago
        This is really nice ! Thanks !
      - MrBuddyCasino 12y ago
        Sweet! I'd really like to know how big the resulting binary for that blinking leds example is.
- mackwic 12y ago
  Because Rust is not ready for production ?
SixSigma 12y ago
Oh what a terrible name because of http://mbed.org/ http://mbed.org/ Which is also an online embedded software toolchain from IDE to linker.
errordeveloper 12y ago
Great to hear that quality meta tooling is making it's ways into the industry full of outdated and bad engineering practices.
- mjbellantoni 12y ago
  Could you offer some specifics?
sitkack 12y ago
This is great on many levels. 1. They are using MPS [0] from JetBrains, a system for constructing tooling around Domain Specific Languages. 2. Markus Voelter is a huge proponent of DSLs and a very level headed fellow. Loved his interview with Laurence Tratt [1] about compile time metaprogramming [2]. This brings benefits of Ada and Lisp with a modern JetBrains style IDE while targeting a C99 runtime. I think being able to sculpt the language to the project can greatly compact the abstraction distance from the problem domain to the code. [0] http://www.jetbrains.com/mps/ http://www.jetbrains.com/mps/ [1] http://tratt.net/laurie/ http://tratt.net/laurie/ [2] http://www.se-radio.net/2007/05/episode-57-compile-time-metaprogramming/ http://www.se-radio.net/2007/05/episode-57-compile-time-meta...
linuxlizard 12y ago
Embedded firmware engineers are so conservative I bet the firmware for tricorders will be written in C.
- tmuir 12y ago
  As opposed to all of those other languages that lend themselves so well to the task? Since tricorders will most likely run linux, by default, they will have lots of C.
orf 12y ago
This looks awesome, one thing though: "All code is stored in XML files". I'm not sure I see the advantage of this, what else is stored in the XML other than the code and why can't it be stored on its own?
- vertex-four 12y ago
  This is built on Jetbrains MPS[0], which is essentially an abstract tree editor made to behave like a regular text editor. The weird thing is, the DSLs can collide; there can potentially not be enough information in the text to unambiguously decide which DSL the author intended. Therefore, additional data has to be stored to disambiguate this. [0] http://www.jetbrains.com/mps/ http://www.jetbrains.com/mps/
  - mike_hearn 12y ago
    Well not only that but MPS allows for things like graphical languages too. XML is used because you're not really editing text at all, you're editing at a higher level of abstraction. Regardless, MPS has support for things like version control merging/diffing and so on. It's a pretty mind blowing tool all round.
tmuir 12y ago
Maybe they've never heard of Eclipse.
kabouseng 12y ago
This looks like a lot of effort was put into it, but what pain point / problem does it address? Embedded applications (bare metal) is usually not that complicated, and when they are they are usually developed either on a RTOS, or on embedded linux which gives you almost all the advantages of desktop application development. Coming back to embedded applications not being that complicated, now you also need to get your developers to learn another framework and IDE while they are already under pressure to develop their current feature set. Like codehero states elsewhere it only adds another abstraction layer between you and the silicon, in a field where exact control of the silicon is paramount (Low power, response latency in real time, limited resources etc). Furthermore what guarantee do you have that Mbeddr will support the latest processor you are working on. At least with C being a defacto standard in the industry you have that guarantee. Furthermore most processor manufacturers supplies demonstration code to use their latest processor features, how easy is it to pull that into Mbeddr? I'm afraid this is a very fancy and polished solution looking for a problem.
- dkarapetyan 12y ago
  It's all C. It is all syntactic sugar on top of C so if at the end of the day you want to go back to C then just compile it down and take it from there. Your comment reminds me what people were saying when assemblers were first developed. Real programmers did not use assemblers because it was too high level or too far removed from the hardware or any number of other excuses. The fact is that plain C is inadequate for delivering correct software in high assurance environments. This tool addresses that problem and then some.
  - ArkyBeagle 12y ago
    'C' is perfectly adequate for delivering safe and correct* code. Just because it's possible to have 'C' code that is unsafe is not a blanket indictment of the language. Micheal Barr, the MISRA team, Valgrind all exist to aid and abet delivery of safe and correct systems. *whatever that means in context... As we say - "doctor, doctor it hurts when I do that!" "Well, don't do that!" Tools like this simply automate or add leverage to that process. And unless there's considerable community support for the use of something like this, it'll remain a smaller thing than raw 'C'. But many embedded projects are small enough that there's little pain in reinventing the wheel.

85 points by _qc3o 12y ago

damian2000 12y ago

Its great that it generates C but I'd worry that developers who are writing embedded code won't bother to try it - they often are trying to squeeze some code into a small amount of memory on a limited processor. Some of the things it provides - state machines, unit conversions and error logging are pretty simple to do within C anyway, and developers might not appreciate or want an additional level of abstraction.

ShinyCyril 12y ago
State Machines, as you noted, are easy to do with C. I think the added value in this respect is that this makes it much easier to manage the State Machines. I often hear guys at work complaining about how they'd like to switch to using an RTOS because the codebase is a tangled mess of State Machines (not that the two are mutually exclusive of course). Having said that, I seem to remember there is a tool dedicated to creating State Machines that compile down to C - the name escapes me however.
- tlarkworthy 12y ago
  QP framework. Its bloody brilliant.
  - ShinyCyril 12y ago
    That's the one.
- jacobparker 12y ago
  Ragel? http://www.complang.org/ragel/ http://www.complang.org/ragel/
IshKebab 12y ago
This is clearly aimed at applications that must be very reliable, e.g. life-critical applications like cars (note BMW sponsor it). Most embedded programming isn't that bug-sensitive, but quite a lot is and I'd wager they'd love something like this. I know I'd use it if I were writing safety-critical code.
- ArkyBeagle 12y ago
  Code exists in context of a culture and processes. This may well facilitate those, but those kind of have to come first.
sitkack 12y ago
This adds an amazing amount of verification, but it doesn't mean that the resulting code is slow. Doing unit checks is awesome. The grid state machine view makes it easier to catch errors and refactor the transitions.

Nursie 12y ago

"A cleaned up version of C99 helps avoid low-level bugs. For example, the preprocessor is not supported" NOPE. From my cold, dead hands.

IshKebab 12y ago
Why? The preprocessor is a huge hack that is mostly obsolete. 99% of my programs only use `#include` and `#pragma once`.
- metafex 12y ago
  Macros used right can really help to clean up messy code and/or reduce repeating code to something clearer (e.g. in crypto-code).
  - hrjet 12y ago
    Pre-processing macros can reduce repetition, but they are certainly a hack: They are not type-safe. They are not even syntactically safe. A missing brace in one can cause untoward damage down the chain. And getting it right is especially important in crypto-code!
- com2kid 12y ago
  #ifdef alone #ifdef HW_REVISION_1 #ifdef HW_REVISION_2 etc
  - mackwic 12y ago
    Playing the devil's advocate, here. When possible, this kind of if_arch/else should be compartmentalized in their own object files or dynamic libraries, and then, linked conditionally to produce an unique binary. You shouldn't clutter your code with ifdef. It makes it hard to think with.
    - SixSigma 12y ago
      The whole of Plan9 is written like that. If you look here http://plan9.bell-labs.com/sources/plan9/sys/src/9/ http://plan9.bell-labs.com/sources/plan9/sys/src/9/ You can see that port & boot are the portable code. Each architecture can fall back on that less optimised code should it need to. Then each of the directories: bcm, kw, mtx, omap, pc, pcboot, ppc, rb, teg have platform specific c files This greatly eases porting to a new architecture and also means cross compilation is significantly easier. #ifdefs are rare in the source code and other pragmas are few and far between. Conditional compilation is the enemy of readable code.

sandGorgon 12y ago

Hmm... is there any relation to mbed.org ? mbed is a new methodology (supported by ARM) for programming and debugging embedded devices through CMSIS-DAP.

mackwic 12y ago

This looks great ! With the JetBrains expertise in IDE, that surely was a missing piece of software. I am slightly concerned by the DSL thing, because I don't want each embedded projects to have specific dialects like we can see on LISP projects. But, on the average, gains are high: modules ! tests ! Inline contracts and model checking ! Very nice state machines ! I like that ! Also, why C99 ? There's hardware where only C89 compilers are available...

errordeveloper 12y ago
Because nobody would use those chips for new projects. Legacy chips need legacy tools and run legacy software.
- mackwic 12y ago
  I don't agree. Popular but legacy chips can have updated tools where new but conservative chips can have odd software packaging. Moreover, embedded development is conservative by nature and I know a lot of teams which prefers to run projects on known hardware when possible, even if we have to suffer of the tooling. Also, don't forget the licencing. We already have to downgrade our targeted platform because we couldn't afford to pay the whole tooling where OSS was only compatible with the previous version.

anon4 12y ago

So this is something like the friendly-C variant proposed some weeks ago?

codehero 12y ago

When I work on an embedded system, I want as few layers between my code and the assembler as possible. Even your C compiler can produce undesirable code if you don't put the proper const, volatile qualifiers on your pointers. The last thing I want is a layer of software and an IDE developed by a team that I can only assume has 0 embedded experience (judging by team page they are all architects or academics). Secondly, if I handed off a work for hire implemented in this language I would not get a next assignment. There is no room for fad modelling in the established engineering trade and unfortunately I don't have the pull to start the disruption if I truly believed in it.

errordeveloper 12y ago
There are two problematic types of engineers out there, some have no clue what they do and some have too much clue and wave their flags all over the place. You are in the second group and have probably been doing too much C for too long.
- sitkack 12y ago
  Clearly a hero.
  - mackwic 12y ago
    I have to say that the sequence "errordevelopper" responding to "codehero" is quite funny. :)
- fasteo 12y ago
  So true
- codehero 12y ago
  I really appreciate your succinct criticism of my points, you didn't need to qualify with anything but "you have been doing C for too long." I consider that a compliment. Ask my clients how much of a problem I am and then ask them how many problems I solve. And no, I don't solve them all with C.

FnuGk 12y ago

Why not use something like rust over this? Rust should provide the safety missing in C while also providing higher abstractions and a safe macro system with about the same performance as C

joezydeco 12y ago
How big is the runtime? I have 64K of SRAM on my part and 512MB of onboard Flash.
- FnuGk 12y ago
  That is quite a lot for an embedded system. looking through them comments in an earlier HN post https://news.ycombinator.com/item?id=6268291 https://news.ycombinator.com/item?id=6268291 on running rust on the arduino DUE they link to zero.rs that should make it possible to run without any runtime
  - errordeveloper 12y ago
    Zero.rs is dead now. Checkout http://zinc.rs http://zinc.rs :)
    - mackwic 12y ago
      This is really nice ! Thanks !
    - MrBuddyCasino 12y ago
      Sweet! I'd really like to know how big the resulting binary for that blinking leds example is.
mackwic 12y ago
Because Rust is not ready for production ?

SixSigma 12y ago

Oh what a terrible name because of http://mbed.org/ http://mbed.org/ Which is also an online embedded software toolchain from IDE to linker.

errordeveloper 12y ago

Great to hear that quality meta tooling is making it's ways into the industry full of outdated and bad engineering practices.

mjbellantoni 12y ago
Could you offer some specifics?

sitkack 12y ago

This is great on many levels. 1. They are using MPS [0] from JetBrains, a system for constructing tooling around Domain Specific Languages. 2. Markus Voelter is a huge proponent of DSLs and a very level headed fellow. Loved his interview with Laurence Tratt [1] about compile time metaprogramming [2]. This brings benefits of Ada and Lisp with a modern JetBrains style IDE while targeting a C99 runtime. I think being able to sculpt the language to the project can greatly compact the abstraction distance from the problem domain to the code. [0] http://www.jetbrains.com/mps/ http://www.jetbrains.com/mps/ [1] http://tratt.net/laurie/ http://tratt.net/laurie/ [2] http://www.se-radio.net/2007/05/episode-57-compile-time-metaprogramming/ http://www.se-radio.net/2007/05/episode-57-compile-time-meta...

linuxlizard 12y ago

Embedded firmware engineers are so conservative I bet the firmware for tricorders will be written in C.

tmuir 12y ago
As opposed to all of those other languages that lend themselves so well to the task? Since tricorders will most likely run linux, by default, they will have lots of C.

orf 12y ago

This looks awesome, one thing though: "All code is stored in XML files". I'm not sure I see the advantage of this, what else is stored in the XML other than the code and why can't it be stored on its own?

vertex-four 12y ago
This is built on Jetbrains MPS[0], which is essentially an abstract tree editor made to behave like a regular text editor. The weird thing is, the DSLs can collide; there can potentially not be enough information in the text to unambiguously decide which DSL the author intended. Therefore, additional data has to be stored to disambiguate this. [0] http://www.jetbrains.com/mps/ http://www.jetbrains.com/mps/
- mike_hearn 12y ago
  Well not only that but MPS allows for things like graphical languages too. XML is used because you're not really editing text at all, you're editing at a higher level of abstraction. Regardless, MPS has support for things like version control merging/diffing and so on. It's a pretty mind blowing tool all round.

tmuir 12y ago

Maybe they've never heard of Eclipse.

kabouseng 12y ago

This looks like a lot of effort was put into it, but what pain point / problem does it address? Embedded applications (bare metal) is usually not that complicated, and when they are they are usually developed either on a RTOS, or on embedded linux which gives you almost all the advantages of desktop application development. Coming back to embedded applications not being that complicated, now you also need to get your developers to learn another framework and IDE while they are already under pressure to develop their current feature set. Like codehero states elsewhere it only adds another abstraction layer between you and the silicon, in a field where exact control of the silicon is paramount (Low power, response latency in real time, limited resources etc). Furthermore what guarantee do you have that Mbeddr will support the latest processor you are working on. At least with C being a defacto standard in the industry you have that guarantee. Furthermore most processor manufacturers supplies demonstration code to use their latest processor features, how easy is it to pull that into Mbeddr? I'm afraid this is a very fancy and polished solution looking for a problem.

dkarapetyan 12y ago
It's all C. It is all syntactic sugar on top of C so if at the end of the day you want to go back to C then just compile it down and take it from there. Your comment reminds me what people were saying when assemblers were first developed. Real programmers did not use assemblers because it was too high level or too far removed from the hardware or any number of other excuses. The fact is that plain C is inadequate for delivering correct software in high assurance environments. This tool addresses that problem and then some.
- ArkyBeagle 12y ago
  'C' is perfectly adequate for delivering safe and correct* code. Just because it's possible to have 'C' code that is unsafe is not a blanket indictment of the language. Micheal Barr, the MISRA team, Valgrind all exist to aid and abet delivery of safe and correct systems. *whatever that means in context... As we say - "doctor, doctor it hurts when I do that!" "Well, don't do that!" Tools like this simply automate or add leverage to that process. And unless there's considerable community support for the use of something like this, it'll remain a smaller thing than raw 'C'. But many embedded projects are small enough that there's little pain in reinventing the wheel.