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?