I’ve been on a number of projects using the former type of tool and been pleasantly surprised at its effectiveness. The closer you go to the other extreme, however, the worse things seem to fall apart, especially when the requirement for multi-threaded code comes into consideration. Leaving aside the issue of the state of the tools for a moment, you’ve probably got more programmers trained in C++ now than any other “modern” language, but C++ might well be the WORST such language for multi-thread – for one thing the current specification doesn’t even provide for ANY form of automatic memory management, let alone one designed to be effective in a multi-thread environment (and add-ons like the Boehm tool for example only work if your system already supports virtual memory, which is not always available in an embedded environment). Also there don’t seem to be any effective tools for C++ to test the source code in order to see that an application is “thread-safe” (like Chord for Java). And I’m pretty certain that a lot of folks would identify the extensive availability of pointers in C++ (thought of by its proponents as an invaluable feature) as not only a relic but an actual albatross inasmuch as it either prevents or severely degrades the performance of any mechanism that could be devised to manage memory automatically.

Certainly “object-by-object” memory management is not going to stand for long if we want to generate our million-line applications, so the development environment needs to evolve – and quickly! In the same way perhaps in the future we’ll have tools that will allow us to simply generate a single-thread model of our application in a language like UML and submit it to a “thread assigner” that will find the maximum likely number of independent threads and convert our input automatically into the multi-thread version. (And if that sounds a bit too much like science fiction, how would you respond if you asked your boss tomorrow “how many independent threads do you need this new program divided into?” and he responds with “this code’s gonna be around for at least three decades, we expect the number of available cores in the target to double each year, how many cores can you keep busy at one time?”, what would you say that would totally satisfy him?) No we need tools like these RIGHT NOW – and better languages too! (I’m also thinking largely in terms of languages following the imperative programming paradigm, since experiments such as Ericcson’s with Erlang as a multiprocessing language, impressive as they are, nonetheless only apply in comparison with other functional languages, which is really a completely different kettle of fish.)

Thanks again for a thought provoking article.

So, for example, Trend #1 (32-bit processors) is not as coupled with Trend #2 (code generation), as it might first appear. This is because the benefits of 32-bit processors over 8-bitters lie mostly in the low-level “action code”.

For example, accessing any peripheral with more than 8-bit-wide data, such as 10-bit ADC or a 16-bit timer, on an 8-bit architecture requires multiple instructions. This can lead to very subtle and difficult to reproduce bugs, for example overflow from the low-byte to the high-byte in a 16-bit timer. (Jack Ganssle’s ESC class “RealReal-Time Sysems” is entirely devoted to this type of issues). Many 8-bitters provide special latch registers and other hardware tricks to avoid such problems. But the programmer must *know* about them, or else they won’t work (e.g., the latch works correctly only if low-byte is read before the high-byte or vice versa). Add to this segmented memory architecture, crippled stack, and other gotchas of 8-bitters, and you can see how 32-bitters can make our life easier. All those problems are simply non-existent in the 32-bit world.

Regarding Trend #3 (connectivity and security), I think that Trend #2 (code generation) helps, rather than hinders security. Most security vulnerabilities arise though inconsistencies (such as buffer overruns). Automatically generated code tends to dramatically improve consistency. And if any vulnerabilities are discovered in the code generation, it’s much easier to fix them at the source (code generator) and *consistently* re-generate the code.

You learn a whole lot stuff about history in school, but noone ever tells where electronics history comes from. So it is really a pleassure to get your inside about how one started to learn 20 – 30 years ago. For example I did not learn assembly nor c language in university I did learn it from working expirience, but since I can program in C now I will never really learn assembly now, since my systems are running succesfully in C.

And even I can see those future trends, I have expirience with freescale and TIs MSP430 and both are introducing more and more graphical program helpers.
For the newcomers this will help big time, I guess. I wont use it, since I now know what I am using, but so you older guys could say you still program time critical parts in plain assembly code, which then I wouldnt be able to use since I was starting with C programming.

And so time keeps on going with its trends and we have to see if it works out well.
Thanks for the article.

Of all these choices, tools based on xUML (eXecutable UML), of which BridgePoint is the leading example, require perhaps the highest degree of ceremony. xUML tools are designed to create an illusion that your model is completely “platform and technology independent” (Whatever that means in embedded systems that by any definition of the term are specific to the task and technology). So, for example, to avoid committing to a specific programming language (such as C), xUML tools use an Abstract Action Language (AAL) to code actions executed by state machines as well as any other “Domain Functions”. Interestingly, various xUML tools use different AALs and BridgePoint, specifically, uses Object Action Language (OAL), which is somewhat like C (only more crippled), but with a different syntax.

But what if I don’t care for the ability to change my embedded code from C to, say, Java? What if I don’t wish to learn and tweak hundreds of parameters of the “model compiler” every time I want to have a little better control over the generated code? What if I care more about avoiding endless repetitions in my state machines (a.k.a. “state/transition explosion”) by using state hierarchy, which BridgePoint for some reason does not support?

The point is, as I argue in my EmbeddedGurus blog post “Economics 101: UML in Embedded Systems”, that all too often a big, complex tool incurs high costs while still missing some important objectives of the project. With such very high ongoing overhead, it is quite easy that a tool fails to deliver a positive return on investment (ROI). When this happens, the tool and the whole modeling approach gets abandoned. And this is just too bad, because it is like throwing out the baby with the bath water.

So, while I don’t contest that big, high-ceremony modeling tools can be applicable in certain situations, I do argue that the embedded industry can also benefit from novel, simpler, more agile approaches. As I describe in my EmbeddedGurus post “Turning automatic code generation upside down”, the free QM modeling tool provides an example of a truly novel, low-risk, and low-overhead approach that fundamentally simplifies modeling and code generation for real-time embedded systems.

uint16_t variable = ~0;