|
The Embedded Mindset February, 2003, pages 39-45. The proliferation of embedded systems means ever-increasing demand for firmware. Developing embedded code, however, takes significantly more than just learning a new API-it requires adapting an entirely new mindset. You can still use C or even C++, but beware-many time-honored techniques from the desktop can hurt you. Article (254KB)
Accompanying code (4KB)
|
|
| |
|
Who Moved My State? April, 2003, pages 28-34. Just as the mice and little-people from the Spencer Johnson's little story "Who Moved My Cheese?", we programmers use different strategies to find our favorite kind of "Cheese": robust, adaptable, and maintainable software. Interestingly, techniques based on hierarchical state machines aren't among the popular, mainstream programming strategies. Yet, state machines are perhaps the most effective method of all for developing robust event-driven code, because they give us the map to the software maze-the blueprint of all the states of the system at any given time. If you don't use state machines today, you'll likely use them tomorrow. Article (283KB)
Visual Basic Calculator Example
Quantum Calculator Example
|
|
| |
|
Dèjà Vu June, 2003, pages 35-39. I hope that you experience a strange feeling of dèjà vu when you read about programming-by-difference, inheritance, guaranteed initialization and cleanup, and the Liskov Substitution Principle (LSP) in the context of hierarchical state machines (HSMs). Such a close analogy between the fundamental concepts of OOP and HSMs is truly remarkable. Indeed, the analogy adds another dimension to the OOP. The traditional OO method seems to stop short at the boundary of a class, leaving the internal implementation of individual class methods to mostly procedural techniques. The concept of behavioral inheritance goes beyond that frontier. It allows applying the OO concepts inside reactive classes. Article (258KB)
Pedestrian Light Controlled Crossing Example
|
|
| |
|
An Exception or a Bug? August, 2003, pages 36-40. If you were to single out just one most effective programming technique for delivering high-quality code, what would you choose? Object-oriented programming? Generic programming? Design patterns? Software components? Frameworks? UML? CASE tools? I don't know if these suggestions would top your list, but I suppose that not many programmers would pick assertions (or more scientifically, Design by Contract) as the single most effective programming technique. Yet, if I were to search my soul, I'd have to admit that none of the aforementioned techniques (not even my favorite hierarchical state machines) has helped me as much as the consistent use of assertions. In this installment of "The Embedded Angle," I try to explain the Design by Contract philosophy, what can it do for you, and why, I think, embedded systems programmers should care.). Article (225KB)
|
|
| |
|
Patterns of Thinking October, 2003, pages 45-48. I’m sure that you have used system metaphors, concept metaphors, or "naive psychology" before, but perhaps you didn’t fully realize the fact. I hope that this article will make you more aware of the different roles metaphors and analogies can play in software development, and that there is more to it than just the venerable system metaphor. I hope that you start paying more attention how you and others use metaphors with the goal of making better use of the natural god-given abilities built into your brain. I hope that you start thinking more about metaphors, learn their limits, and remember their critical aspects. Perhaps you will start collecting metaphors?. HTML version Article (209KB)
|
|
| |
|
Back to Basics December, 2003. My preoccupation in this installment is with state machine fundamentals and some very straightforward programming guidelines for coding state machines in C or C++. I hope that the simple techniques could become more common, so that you (and others) can readily see the state machine structure right from the source code. . HTML version Article (276KB)
Time Bomb Example
|
|
| |
Top of pageVisual Basic Calculator
The currently dominating approach to structuring event-driven software is the “event-action paradigm”, in which events are directly mapped to the code that is supposed to be executed in response. An example from Graphical User Interface (GUI) area illustrates how this paradigm works out in practice. In the book Constructing the User Interface with Statecharts [Horrocks 99], Ian Horrocks discusses a simple desktop calculator distributed in millions of copies as a sample application with Microsoft Visual Basic, in which he found a number of serious problems. As Horrocks notes, the point of this analysis is not to criticize this particular application, but to point out the shortcomings of the general principles used in its construction. (See also "Who Moved My State" article) The following link lets you download the Visual Basic Calculator sample application: |
Visual Basic Calculator — Visual Basic source code, executable, and Visual Basic 4.0 DLL
|
When you execute the application, you might want to reproduce some of the problems that Ian Horrocks found in this application:
- Start application, 6, /, -, =, 6, =
On clicking the equals button, the application crashes with a runtime error caused by a type mismatch. - Start application, 2, -, -, -, 2, =
On clicking the equals button, the application crashes with a runtime error caused by a type mismatch. - Start application, 5, +, CE, 7, =
The Cancel Entry event had no effect, even though it appeared to cancel the 5 from the Readout field. - Start application, 3, 0, +, 3, 0, =, %, x
Clicking the multiply button at this point should not cause the value 36 to appear on the Readout field.
Top of pageQuantum Calculator
State machines offer a better way of approaching reactive systems. You might spend a few hours to design a statechart for a calculator, but if you do it correctly the application will have much better understood behavior without all the corner cases identified in the Visual Basic calculator. (See also "Who Moved My State" as well as "Deja Vu" articles) The following links let you download the Quantum Calculator applications: |
| Example Application | Language | Date | Notes | Download |
| Quantum Calculator in C — Quantum Calculator source code in C, executable, and Microsoft Visual C++ project. Compatible with QEP/C 2.6.xx. |
|
Dec 20, 2004 | ![]() Release Notes |
![]() (287KB) |
| Quantum Calculator in C++ — Quantum Calculator source code in C++, executable, and Microsoft Visual C++ project. Compatible with QEP/C++ 2.6.xx. |
|
Dec 20, 2004 | ![]() Release Notes |
![]() (289KB) |
Top of pagePedestrian Light Controlled Crossing
The Pedestrian Light Controlled (PELICAN) Crossing example has been used in the article "Deja Vu". The following links let you download the PELICAN code: |
| Example Application | Language | Date | Notes | Download |
| PELICAN Crossing in C — PELICAN Crossing source code in C, executable, and Microsoft Visual C++ project. Compatible with QEP/C 2.6.xx. |
|
Dec 20, 2004 | ![]() Release Notes |
![]() (310KB) |
| PELICAN Crossing in C++ — PELICAN Crossing source code in C++, executable, and Microsoft Visual C++ project. Compatible with QEP/C++ 2.6.xx. |
|
Dec 20, 2004 | ![]() Release Notes |
![]() (312KB) |
Top of pageTime Bomb
The Simple Time Bomb example has been used in the article "Back to Basics". The following links let you download the Time Bomb code: |
| Example Application | Language | Date | Notes | Download |
| Time Bomb in C — Time Bomb source code in C, executable, and Microsoft Visual C++ project. Compatible with QEP/C 2.6.xx. |
|
Dec 20, 2004 | ![]() Release Notes |
![]() (395KB) |
| Time Bomb in C++ — Time Bomb source code in C++, executable, and Microsoft Visual C++ project. Compatible with QEP/C++ 2.6.xx. |
|
Dec 20, 2004 | ![]() Release Notes |
![]() (394KB) |
Top of pageLast updated: April 25, 2006





Article
Accompanying code



HTML version