8 bits anyone?

It was well over 10 years ago and I was working a trade show booth with a techie colleague. It was quiet and we were bored. We chatted about things that interested us and eventually settled on our common ground: embedded software. He made a reference to “back in the 8 bit days”. I questioned this: “We are in the 8 bit days now!”. He did not believe me …

It was not that he thought I was deceiving him or that he was stupid – far from it. He has simply led a sheltered life. We worked in a business selling real time operating systems and high end embedded development tools. [The company was later acquired by Mentor Graphics, which is how I came to be here.] The products were targeted almost exclusively at 32-bit processors and that was really the only world he knew, as every customer we met was developing with such devices. Realistically, users of smaller CPUs were unlikely to need an RTOS and even less likely to pay for one. Similarly their development tools were provided by companies who could offer them at the low price that the market would stand.

The reality, at that time, was that an incredible number of number of 8-bit systems were being developed – when just that amount of CPU power was needed for the application in hand. Similarly, 4-bit devices had a place. And 16-bit processors were available to accommodate situations when just a little more horsepower was required. I remember reading then that Intel sold seven times as many 186 devices [a popular 16-bit microcontroller] as Pentiums. And the 8051 family [8 bits worth of horrible architecture] shipped in even larger volumes.

Looking at many multi-processor systems and the need for a diverse range of CPU power levels is apparent. A good example is a car. A modern vehicle has 50-100 processors. The engine management systems and satellite navigation probably both need 32 bits. Braking systems are likely to need 16 bits. Most of the minor systems use 8 bits – things like central locking, security and ultrasonic reversing sensors. A 4-bit processor is quite enough to control electric windows.

My perception is that things have not changed that radically in recent years, but a change is on the way. There is an increasing number of very low cost [and low power] 32-bit devices coming onto the market – most based on ARM processors. They are so cheap and easy to deploy, that they could be used where an 8- or 16-bit device would have been used in the past, even though the 32-bit architecture is gross overkill. What will this do to the software? On the one hand, techniques commonly used for higher-end applications may be employed, like the use of C or C++. Maybe an RTOS could be attractive. But the on-board memory is commonly very limited – a critical factor in keeping down cost and power consumption. This requires some rethinks with regard to software.

I would be very interested to hear from anyone – by comment or email – with experience of using these very low cost 32-bit devices. What are your experiences?

Want to stay up to date on news from Siemens Digital Industries Software? Click here to choose content that's right for you


0 thoughts about “8 bits anyone?
  • I can’t find many reasons to prefer a 8-bit processor (like a 8051) over a 32-bit one (Cortex-M).
    I’m a programmer, and I like these benefits of ARM controllers:
    – faster memory copy (means faster boot time in many cases btw)
    – smaller code size thanks to Thumb instructions
    – “no assembly required” (sorry for the pun) means shorter dev time. You can write 8051 software in C but I think the machine code quality would suffer (actually I haven’t worked with the newest compilers so this may not be an issue).


  • I work with 8-bitters everyday, they can be programmed in C, it actually is the way it is mostly done everywhere. Of course, 8051 is not a really nice C-oriented architecture, but the Freescale S08 core is.

    On the low end 32-bit question, I do work also with these. Freescale has the Coldfire V1 core which is a simplified version of the bigger V2 core. The devices in the V1 family have peripherals that are the same as the 8-bit families. The CodeWarrior IDE for the 8-bit architecture, includes the compiler for the 32-bit V1 architecture. Development is essentially the same (not exactly, word sizes and other stuff is different, but you can always use typedefs to improve portability). There are also newer devices that even include stuff like USB or ethernet, and Freescale is enabling them with stacks and RTOS. It’s a really nice option. The very interesting part is that many customers are actually jumping to these for one critical factor: hardware development. While bigger devices have smaller and more complicated to solder packages and speed issues that requiere more sophisticated development and simulation tools, the low-end devices are just a little bit faster and come in simpler to manufacture packages. Couple that with a very small increase in cost and the 32-bit word size and you’ll jump into it if your a small company with small resources.


  • I’ve been working lately on a controllable (and tunable) LED lighting device; my colleagues had a saying: “How many microcontrollers do we need to light a bulb?” The answer was TWO and both were 32-bit devices 🙂

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.sw.siemens.com/embedded-software/2009/11/23/8-bits-anyone/