Mbeddr – engineering the future of embedded software
mbeddr.com
mbeddr.com
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.
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.
(It seems errordeveloper is doing exactly the same flag waving they originally unfairly lambasted you for...)
Although, our pattern matching is a strict superset of C's switch (other than fall-through). But yeah, fall-through and goto aren't supported yet, and if we were to get them (in safe code), they may have to be restricted to preserve memory safety.
The thing about these systems is they attempt to prevent you from shooting your own foot by not letting you aim. Some operations (such as erasing and writing flash) require you to do dangerous things like relocating code to SRAM and running from there while your flash operation completes. The details of each platform vary: ARM code is generated in a position dependent fashion; MSP430 is not.
I am certainly not calling C the end-all be all, but it's a tough system to beat. You could convince managers that mbedder may be the way to go, but it would be an absolute boondoggle to get existing engineers to use it. (They couldn't even convince the Park-o-matic folks to rewrite their code to use it). To a "C simpleton" like me, I would not call mbedder obviously better.
SVG: 2001 AJAX/Javascript: 2002 Windows CE: 2005 DirectFB: 2005 FLTK: 2006 SCons: 2007
I have been learning new things my entire career. I have wasted tons of time trying to support the "better" technology. mbedder presents a very weak case in my mind.
My question to you is how has your experience with mbedder been so far? You seem to understand its superiority. Does the code size and RAM consumption live up to your expectations?
This statement alone disqualifies you from making any comment about embedded development and automotive embedded development in particular.
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/ [1] http://tratt.net/laurie/ [2] http://www.se-radio.net/2007/05/episode-57-compile-time-meta...
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.
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.
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.
*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.
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...
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.
NOPE.
From my cold, dead hands.
#ifdef HW_REVISION_1
#ifdef HW_REVISION_2
etc
You shouldn't clutter your code with ifdef. It makes it hard to think with.
If you look here 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.
Using many small object files is my solution of choice but it pushes the if/else/endif problem into the Makefile instead.
I know people who use the file header to autodetect the right architecture but I found it too overkill and weird-bug-prone.
[1] At the risk of starting a flame war, this situation and those like it have really soured me on the rest of the industry's obsession with "big O" for complexity analysis. I have never found it useful; I always needed to pay attention to the stuff I was supposed to be dropping.
You are absolutely right. It's a real effort of architecture, and sometimes one of the marks of a great projects. EDIT (thinking of a bad experience of mine): Sometimes, this compartmentalization is also unnecessary and force the architecture to be far worse, too loosely coupled and hard to follow.
> There was no way to separate the code the way you describe without implementing it twice.
Your mileage may vary but implementing it twice can be the best solution if there was so many dependencies to the platform. You should then document the algorithm and reference this documentation in each implementation so that they don't diverge too much. That's not always the best solution, thought. There's no silver bullet in this world...
Well, the architecture of what I was working on was not going to win any awards. :P It was made worse because we were converting code that was originally implemented to run on DSPs.
> Your mileage may vary but implementing it twice can be the best solution if there was so many dependencies to the platform. You should then document the algorithm and reference this documentation in each implementation so that they don't diverge too much. That's not always the best solution, thought. There's no silver bullet in this world...
Standard practice was for systems engineers[1] to create Algorithm Description Documents and Algorithm Implementation Documents that explained in mathematical formulas (ADD) and pseudocode (AID) what the code was doing. At least. that was the theoretical practice. The actual practice was a mess. But yes, there is no silver bullet.
[1] Which was me, even though I got to write lots of code, too.
> At least. that was the theoretical practice. The actual practice was a mess. :( This another big problem yet to solve...
First was that the chips were fixed-point. That mainly changed the arithmetic of the individual algorithm steps, but it led to some really strange number packing schemes[1] that affected memory layout and added a bunch of code just for dealing with them.
Second was the concept of "on-chip" and "off-chip" memory. The chips did not have a conventional memory bus. Instead, the program had to manually make a DMA request to move data on-chip for processing. This was basically a stack memory space local to the DSP core. It was the only memory space the core could access directly, though. Thus, algorithms had to be implemented such that they moved memory on-chip in blocks, processed the data, then moved it back off-chip. Since these movements were expensive, the implementation also tried to chain as many things together on the core in order to minimize the DMA transactions.
Needless to say, these make for extremely inefficient code in some cases when you try to recompile on a real processor or controller that actually has an FPU and memory controller.
[1] If you have never tried working with complex numbers on a fixed-point processor, don't.
Regardless, MPS has support for things like version control merging/diffing and so on. It's a pretty mind blowing tool all round.
Which is also an online embedded software toolchain from IDE to linker.
looking through them comments in an earlier HN post 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
Since tricorders will most likely run linux, by default, they will have lots of C.