Archive for March, 2009

Insects of the computer world

Monday, March 9th, 2009

The recent Jack Ganssle’s “Breakpoints” blog on Embedded.com makes an excellent point that the same forces (the Moore’s law), which drive down the prices of high-end processors open even more market opportunities at the low-end of the price spectrum. I also agree that the most deciding factor for the price of a single-chip microcontroller (MCU) is the efficiency of its memory use, in other words, the code density. This becomes obvious when one looks at the silicon die of any MCU, which is completely dominated by the ROM and RAM blocks, the CPU being almost insignificant somewhere in the corner.

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.