Protothreads are an attempt to write event-driven code in a sequential way. To do so, protothreads introduce a concept of “blocking abstraction” to event-driven programming–something that event-driven programming is trying to get rid of in the first place.

Obviously, to be compatible with event-driven programming, protothreads cannot *really* block, at least not in the same sense as traditional threads of a conventional blocking RTOS can. Instead, a protothread is still called for every event and still *returns* to the caller without really blocking. However, when a given event does not match the “blocking abstraction”, the protothread returns without doing anything and without progressing. Only when the current event matches the “blocking abstraction” the protothread advances to the next “blocking abstraction” and also returns. Please note that protothreads allow standard flow control statements, such as IF-THEN-ELSE and WHILE loops between any two “blocking abstractions”. Therefore the program feels more “natural” for designers used to the traditional sequential programming style. You simply see the expected sequence of events.

Protothreads are indeed a simplification, but only for *sequential problems*, in which only specific sequences of events are valid and all other sequences are invalid. Examples for using protothreads include the sequence of events for initializing a radio modem.

However, protothreads lose their advantage entirely if there are many valid sequences of events. This is actually the most common situation in event-driven systems. State machines are capable to handle multiple sequences of events easily. In fact, state machines are getting simpler when the sequence of events matters less. In contrast, protothreads are getting more and more complex when they need to accept more sequences of events.

So, in the end, protothreads are an attempt to replace state machines, which are considered complex and messy by the inventors of the protothread mechanism. But, the “messiness” of state machines is obviously a very subjective statement. A good state machine implementation technique can remove many (most) accidental difficulties of coding state machines. I mean, if a state machine as depicted in a state diagram is simple, and if the code does not reflect this simplicity, the problem is with the implementation technique, not with the inherent complexity of a state machine.

The bottom line: good state machine implementation techniques eliminate most reasons for using protothreads. State machines are far more generic and flexible, because they can easily handle multiple sequences of events. In comparison, protothreads are intentionally crippled state machines that transition implicitly from one “blocking abstraction” to another executing code in between as the “actions” on such implicit transition.

Traditionally, such tools haven’t particularly caught on in the embedded space, mainly because too often such tools fail to pull their own weight. Developers find themselves fighting the tool at every step of the way: from drawing the diagrams to trying to live in a straight jacket of the code structure it generates.

The new, free QM tool from Quantum Leaps (my company) is different, because it was designed from the ground up around the code-centric approach. Unlike other graphical tools, QM gives you complete control over the generated code structure, directory names, file names, and elements that go into every file. You can mix your own code with the synthesized code and use QM to generate as much or as little of the overall code as you see fit. At the low level, QM respects your graphical layout as much as possible and will not re-attach or re-route connectors, resize nodes, or adjust text annotations. You will find that you don’t need to fight the tool.

Even though a lot of effort went into making QM as UML-compliant, the tool is innovative and might work differently than other graphical state machine tools on the market. For example, QM does not use “pseudostates”, such as the initial pseudostate or choice point. Instead QM uses higher-level primitives of initial-transition and choice-segment, respectively. This simplifies state diagramming immensely, because you don’t need to separately position pseudostates and then connect them. Also, QM introduces a new notation for internal transitions, which allows actual drawing of internal transitions (in standard UML notation internal transitions are just text in the state body). This notation enables showing internal transitions with regular state transitions in a choice point–something that comes up very often in practice and was never addressed well in the standard UML.

The QM tool is available now for a free download and free, unrestricted use from state-machine.com/qm. I’d appreciate any comments about the tool, comparisons to other similar tools, code generation, UML, state machines, etc.

But, I would disagree with Jack’s statement that “tiny (8-bit) processors make more efficient use of memory”. From my experience with several single-chip MCUs I draw a different conclusion: the CPU size (8-, 16-, 32-bits) almost doesn’t matter for the code density. The deciding factor is how old a design is, whereas the newer instruction set architectures (ISAs) generally far outperform the older ISAs.

To support the point, I present below a table that shows the code size of a tiny state machine framework written in C (called QP-nano), which has been compiled for a dozen or so very different single-chip MCUs. The code consists of a small hierarchical state machine processor (called QEP-nano), and a tiny framework (called QF-nano). The QEP-nano consists mostly of a conditional logic to execute hierarchical state machines. QF-nano contains an event queue, a timer module, and a simple event loop. I believe that this code is quite representative to typical projects that run on these small MCUs.

CPU type          C Compiler         QEP-nano   QF-nano

(bytes)   (bytes)
---------------+-------------------+----------+---------
PIC18                MPLAB-C18         3,214     2,072

(student edition)

---------------+-------------------+----------+---------
8051 (SiLabs)      IAR EW8051            952       603

---------------+-------------------+----------+---------

PSoC (M8C)        ImageCraft M8C       2,765     2,425

---------------+-------------------+----------+---------

68HC08          CodeWarrior HC(S)08       957      660

---------------+-------------------+----------+---------

AVR (ATmega)     IAR EWAVR                541      650

---------------+-------------------+----------+---------

AVR (ATmega)      WinAVR(GNU)             998      810

---------------+-------------------+----------+---------

MSP430           IAR EW430                552      460

---------------+-------------------+----------+---------

M16C             HEW4/NC30                984      969

---------------+-------------------+----------+---------

TMS320C28x       C2000               369 words 331 words (Piccolo)                            738 bytes 662 bytes

---------------+-------------------+----------+---------

ARM7(ARM/THUMB)  IAR EWARM          588(THUMB)  1,112(ARM)

---------------+-------------------+----------+---------

ARM Cortex-M3    IAR EWARM          524         504

(THUMB2)

---------------+-------------------+----------+---------

Interestingly, the winner is MSP430, which is a 16-bit architecture.
It seems that the 16-bit ISA hits somehow the “sweet spot” for the best code density, perhaps because the addresses are also 16-bit wide and are handled in a single instruction. In contrast, 8-bitters need multiple instructions to handle 16-bit addresses.

I would also point out the excellent code density (and C-friendliness) of the new ARM Cortex-M3, which is a modern 32-bit ISA, and still far outperforms all 8-bitters, including the good ol’8051.

On the other hand, the venerable PIC architecture is by far the worst (or, C un-friendly). That’s interesting, because this is the 8-bit market leader. I honestly don’t understand how Microchip makes money when their chips require the most silicon for given functionality. Clearly some other forces than just technical merits must be at work here.

In conclusion, I understand that my data is highly subjective and different code sets (and different compilers) could perhaps produce different results. However, I believe that the general trend is true and this is an important lesson for engineers selecting MCUs.