When Microchip first went public in 1993, many industry ‘experts’ said that 8-bit was dead, yet 20 years later, 8-bit was still the largest microcontroller market, even when measured by revenue. Explaining how such a strong belief could be reiterated year after year, against all evidence, does require some serious analysis.
This would not be the first time that doomsayers got it wrong, after all, the ‘experts’ are human beings and we are, as a global race, surprisingly inept at predicting the future. Looking back at the past is always easier and while it is not immune from its own set of dangers, it is an exercise that is worth doing in the hope we will be able to learn something from our own mistakes.
There have been a small number of inaccurate assumptions that we could trace back to and here are five of them in increasing order of importance:
1. The link to personal computing that never was
Twenty years ago, we were experiencing the boom of the personal computer industry and we could see how obviously the computing needs of our desktops could easily absorb all the growth that Moore’s Law would provide and more. Personal computer architecture went quickly through all the performance that an 8-bit could give, zipped even faster through the 16-bit and 32-bit architectures and is currently being overtaken by the mobile computing industry, where 64-bit multicore architectures represent the norm.
Our natural expectation was that the same would happen in the embedded control market, except it did not. The dynamics of these two markets are surprisingly un-related because the fundamental set of values is completely different. Embedded control designers are bound by much stricter rules and constraints than their counterparts in personal computing. These make them favour product longevity over fast turnover, balanced ratio of performance and power consumption rather than all out performance at any cost, and robustness and consistent output over peak performance.
2. Smaller geometry does not equal lower cost
The same kind of reasoning could be applied to the use of smaller and smaller manufacturing (CMOS) processes. While the relationship between cost and size of the device is certainly a valid economical concern for the embedded control industry, here the fallacy lies in the assumption that the same rewards or benefits would be reaped by those who would rush to the greatest extremes – to the leading edge of the technology.
But the embedded control designer could not value the added functionality gained by the increased gate/transistor count without considering the downside represented by the often dramatic increase in power consumption (increased leakage currents). Besides, the actual shrinking effect on the ‘digital’ portion of a microcontroller was not automatically accompanied by an equal shrinking of the ‘analog’ portions of the device or its I/Os, the interface to the outside world. In fact in many cases these parts proved to increase in size in order to compensate for the reduced voltage tolerance of the smaller transistors.
Today an 8-bit microcontroller core can represent less than 5% of the total area of its die (silicon), hence the dichotomy. In fact as the process geometry is squeezed, the investments in equipment, manufacturing setup costs and ultimately wafer cost grow so quickly to effectively cancel out all the expected (size reduction) benefits.
3. More bits = Easier work
This is an even more insidious assumption that has and still continues to skew the entire conversation. While database applications, spreadsheets and other sorts of computing tasks can all obviously benefit from the ability of a processor to address a larger amount of memory (more bits) and to perform calculations on large numerical values (even more bits), the kind of tasks an average embedded control device is called to perform are of a very different nature.
Reading a temperature sensor, de-bouncing a button input, measuring an incoming signal frequency or duty cycle, producing a PWM signal to drive a motor, are all examples of the menial workload most embedded microcontrollers are called on to perform on a daily basis in millions (actually billions) of applications.
Many marketing efforts have been spent to demonstrate that a 32-bit processor will perform any of the above better than an 8-bit processor, but the evidence is simply not there. This is even more true today, when most applications are written in C language rather than assembly and most designers are minimally, if at all, aware of the actual size of a microcontroller’s ALU as they write their code, and rightfully so.
4. Computational performance vs. ‘real-time’ performance
The deception here lies in the interpretation of the meaning of the word performance in different computing or application domains. In general computing, performance is used to relate to the ability of a processor to churn through complex math algorithms (floating point?), handle vast swaths of data with ease and emerge victorious in the shortest amount of time possible.
In embedded control, the term performance is much more nuanced. In fact it is often attributed to the ability to perform a given amount of work (no more, no less) within a given amount of time from a specific event. Note how in this instance the amount of work achievable per unit of time is not the critical aspect, but rather the timely way the given amount of work is performed in response to an external stimulus.
A practical example will best illustrate this important distinction. Let’s assume an industrial process calls for a sensor input, a pulse of a given duration, to be detected and result in the prompt (within a maximum number of milliseconds) activation of an actuator, closing a valve for example, to prevent an explosion. A 32- or 64-bit processor (with several MBytes of RAM, operating off a 1 GHz clock, while running the very latest Android operating system) would prove to be an inferior solution to a simple 8-bit microcontroller operating at a fraction of the clock frequency (1 MHz, or three orders of magnitude lower) off a simple interrupt service routine.
The example might seem excessive, but it is emblematic as it represents the true kind of performance needed in embedded control. This is ‘real-time’ performance and it relates more to the hardware peripherals surrounding the core than the core’s own bit-size or design. In fact the best results can be achieved when the peripherals are capable of operating independently from the core, removing key application timing bottlenecks. Experience tells embedded control designers that the right hardware peripherals can be key to an application performance over and above the raw number of MIPS provided by the processor.
5. Low power and robustness
The last two elements that did not factor properly in the original predictions, are power consumption and robustness. The laws of physics clearly link voltage and power inexorably together. Furthermore, the influence of voltage is quadratic, giving lower voltage devices, designed using smaller geometries, a definitive edge.
Unfortunately in embedded control, robustness – a quality that relates to the ability of a circuit to reject noise – dictates that it is the higher voltage devices that need to have an edge. Twenty years of evolution in this industry has changed very little, as today a large number of applications still demand operation off a 5 V supply, while handling 5 V inputs/outputs. The automotive industry is perhaps the sector resisting the transition the most.
The present
Modern 8-bit microcontrollers show an incredible level of adaptation to the real challenges of the industry and are incredibly smarter and easier to use than their predecessors 20 years ago. A side by side comparison of two equivalent (PIC16) datasheets reveals that the core has changed only a little, to reflect the increased use of higher level languages and adding features that make the compiler output more compact.
It is the peripheral set that is dramatically different though. In fact even the lowest cost devices offer system level features that were unthinkable back then. A modern 8-bit (PIC) microcontroller is a little mixed-signal system that includes all that is required to produce a reliable clock source (up to five independent oscillators are commonly present on chip), to condition power supply (voltage regulators, voltage supervisors, fixed voltage references, power-on and brown-out resets), to condition input analog signals (operational amplifiers, fast comparators, ADC and DAC of various types and resolutions).
All this is on top of a very rich set of digital peripherals and even programmable logic. In fact the peripherals themselves have evolved to operate independently from the core, hence the term ‘Core Independent Peripherals’ or CIPs coined for the occasion. Once initialised and configured, they take workload off the shoulders of the core that now requires less performance and less power as many of the timing bottlenecks of the application can be lessened or removed.
The future of 8-bit microcontrollers
If we dare look into the near future, we must consider how the very success of embedded control applications will represent its next natural challenge. As billions of devices will enter production and millions of new projects will be developed and released each year, in a world of abundant silicon, the most precious resources will be time and brain power. Reducing the cost of developing firmware will dictate an even greater importance of the (software) tools available for rapid prototyping, debugging and code re-use.
That’s why tools such as the MPLAB Code Configurator (MCC) will play an increasingly important role, while taking an ever larger part of the developer’s burden by integrating complete solution suites covering entire classes of applications (connectivity, motor control, power, etc.) and allowing the developer to customise them to specific product needs.
At the same time, the complexity level will have to be reduced to lower the threshold for the next generation of designers who will be asked to create products for an ever more connected world. As the best code is the one you don’t have to write, an ever-smarter set of CIPs will be configured and inter-connected to form custom functional blocks that will perform, in hardware, the largest share of an application workload.
For more information contact Tempe Technologies, +27 (0)11 455 5587, willem.hijbeek@tempetech.co.za, www.tempetech.co.za
| Email: | willem.hijbeek@tempetech.co.za |
| www: | |
| Articles: | More information and articles about Tempe Technologies |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version