Posts Tagged ‘programming’

Quantum Programming

Saturday, August 17th, 2002 Michael Barr

I don’t buy many books about embedded systems. Most books of relevance find their way to me as review copies. I try to read, or at least skim, all those that look promising. Unfortunately, I’ve found that relatively few are worthy of permanent space on my bookshelf or recommendation to others. Which is why I want to tell you about one recent standout.

Perhaps you recall the article “State-Oriented Programming,” which appeared precisely two years ago in Embedded Systems Programming magazine? If not, suffice it to say it described a very simple manual coding technique for turning hierarchical state machines into compact C or C++ programs. Though I was certainly impressed by the authors and their approach, I didn’t then recognize the brilliance of the underlying ideas.

The primary author’s recent publication of a book-length treatment of the topic has helped me see the light. The book, by Miro Samek, is titled Practical Statecharts in C/C++ (CMP Books). However, the title of the book is a major understatement. What stands out in my mind is not the practical nature of the solution it provides to a common recurring problem, but the downright revolutionary ideas behind that solution.

The author’s so-called “Quantum Programming” may ultimately change the way embedded software is designed. Never before has there been a viable alternative to the traditional main()+ISR vs. RTOS problem. Preemptive multitasking only works well in specific scenarios, while main()+ISR comes with its own set of problems when you try to scale it. A third way is needed.

This book presents a solution, based around state machines, that is compact (5KB is all that’s typically required), realized in C and C++ (no fee or royalties), of theoretical value in any language (even assembly), and can support multiple state machines running in parallel if necessary. It’s also the first good way I’ve seen to deal with the inheritance of state behavior in hierarchical state machines. Samek calls his implementation the “Quantum Framework.”

Before quantum programming, there were basically three approaches to state machine implementation: switch statements, tables of function pointers, and object-oriented programming constructs. The handling of substates in hierarchical state machines was complex in all three approaches. Hierarchical state machines are common, with part of each state’s behavior being determined by its parent state and the rest by the substate itself. This is difficult to implement in the traditional approaches because it either requires duplication of code or additional function/method calls. At best, the results tend toward spaghetti code.

In a nutshell, the quantum programming technique is a design pattern for direct efficient implementation of flat or hierarchical state machines. It uses the popular and proven UML statecharts as its graphical specification language, and leaves the choice of implementation programming language up to the developer. Hierarchical states are implemented via an externally-driven “event processor,” the use of which ensures that substates need not duplicate the functionality of their parents (and grandparents).

I believe that Miro Samek’s innovative techniques will quickly become popular, and I have already put them to good use. If you read only one book about embedded systems this year, make it Practical Statecharts in C and C++.

Is C Passing?

Sunday, June 2nd, 2002 Michael Barr

One of the very first comments I received in response to my editorial for the May 2002 edition of Embedded Systems Programming magazine (subsequently revised and posted to this blog as “Firmware Ethics”) was the following:

You’re obviously not a very good programmer and are using an archaic language. Nearly everything you said was biased toward mediocrity. Those of us Ada professionals wish that you would speak for yourself.

Though quite rudely put, the author does suggest an interesting possibility. Could the choice of programming language alone significantly improve the quality and safety of our finished products?

Of the eight suggested professional “ethics,” three (check return codes, enforce coding standards, and run lint regularly) might possibly be removed from the list if we all used a more strongly enforced language. Such a language would need to at least support exceptions, have strict syntax rules, and be strongly typed.

The C programming language fails on the first two counts. C++ adds support for exceptions but does not require programmers to use them. Among the “well-known” languages only Ada and Java meet all three requirements. Both also offer language-level support for multithreading, which enhances program portability. Yet few embedded programmers use either language.

A recent Embedded Systems Programming study suggests that almost three quarters of subscribers use C regularly. C++ is used by about half, with a slight erosion of C’s relative numbers in recent years. Assembly language remains almost as popular as C++, though the trend with that language is clearly toward decreasing use. Despite its strengths, the use of Ada—currently below 5%—is also on the decline. And, though its use is higher and on the increase, Java has a long way to go before it achieves acceptance within the embedded community.

Why not consider a switch? Not all of us develop systems with safety aspects; but perhaps those who do ought to take the issue of language selection seriously at the outset of new projects. How many bugs need to be preventable to make such a transition cost effective?

Many recognize C’s weaknesses and some, like the U.K.’s Motor Industry Software Reliability Association, have even laid down complex ground rules for its use in safety-critical systems. So why stick with C at all? Why should we allow past practice to dictate future language choices? Will it take a future catastrophe to get us to make the change we should today?

Don’t get me wrong. I love C. It was my first programming language and the one I use most competently. In an ideal world, though, the language decision should not be made based on our personal biases and experience. This is a decision that should be based solely on professional standards. But how can we compare languages analytically and measure the results of a transition from one language to another? It would be nice if there were easy answers.

Unfortunately, even if every one of us did switch to some “safer” language, miscommunication and logical errors would continue to be part and parcel of our discipline. To produce quality maintainable code, it would still be necessary to comment our work well, use version control, perform code inspections and regular testing, and measure real-time performance. Though compilers might be able to protect us from shooting ourselves in the foot, they’ll never stop us from being entirely too human.