A reader's post about how MCU hardware and software evolution are moving in opposition got me thinking about how today's common design practices came about.
The conflict seems to be that hardware evolution in MCU designs is a matter of growing in complexity and capability by integrating more and more on chip. This has a positive feel to it. But MCU software evolution seems to be a matter of taking software from larger systems and cutting it down to fit, which feels disappointing.
I think this is mostly a matter of perception and comes from the rise of the PC. (After all, the PC seems to be blamed for many of the world's other ills, so why not here as well?) Here's how I see it as having unfolded.
At one time there were just big computers. Then, they started getting smaller. One day, the CPU was born, allowing computers to occupy briefcases instead of closets. This was the time when embedded systems began to arise, with the CPU sensing and controlling real-world events through discrete I/O peripherals. Around the same time, the PC arose. A few IC generations later, the MCU, with its integrated I/O and memory, appeared.
This is where things started inverting. As IC technology improved, the PC kept getting more and more powerful, quickly taking over software functions originally developed for larger computers and then expanding upon them. The fact that PCs used separate CPUs, I/O devices, and memory meant that each individual component doubled in performance and capacity every 18 months in accordance with Moore's Law. Further, the memory capacity available to a PC -- including ROM, RAM, and magnetic mass storage -- grew faster than Moore's law as costs came down.
The MCU, on the other hand, aimed to keep size down as much as possible and to integrate as much as possible. As a result, its total performance could not rise nearly as fast as the PC's. The best MCU fell further and further behind the best PC in terms of what it could accomplish.
Meanwhile, the PC and other embedded computing that was not restricted to single-chip designs grew in popularity. This, in turn, caused a change in user expectations. People have now come to expect that anything with even the appearance of intelligence will provide the same kinds of performance and user experience as the PC. So now it appears that, on a software level anyway, MCUs are in a situation of offering only cut-back software.
It's a false image, of course. If you look at MCUs alone, they have been steadily rising in capability, and the software they run has been steadily increasing in performance. They are following the same growth pattern as discrete-device systems like the PC and set-top boxes. It's just that they are a few years behind. It is only when you compare the MCU and discrete device systems together, and expect the user experience to be the same, that you feel that MCU software is a disappointment.
Think of the MCU as the little brother of the discrete-device design: smaller, not as mature or experienced, but able to fit into places big brother cannot and able to avoid mistakes big brother has made. Sure, some of the clothes are hand-me-downs, but little brother will grow into them and look just as good as, or better than, their original owner.
Rich Quinnell 4/12/2012 12:03:52 PM User Rank Blogger
Re: Inverted Evolutions challenge MCU based design
paulyvee, I think that you're spot on with your description of security in design, especially the part about needing to move security to the front of the design cycle. Bolted in will always be stronger than tacked on. As to score, let's call it even.
And for posterity's sake , I'll let you in on a little secret (I'll also post it as a comment under my FAQ blog). Under each comment box there are a set of links for Reply, Post Message, etc. If you look at any comment that you have written (I know, who reads their own stuff?) you will see that there is one additional link: Edit/Delete. You can click on this link to re-open your post and make changes to it, thus controlling your legacy on MCC.
So you, too, can correct your errors; but only yours. The Edit link is only available for one's own posts.
paulyvee 4/12/2012 7:08:14 AM User Rank Bit twiddler
Re: Inverted Evolutions challenge MCU based design
S'not fair - I have to now leave my mistakes there for perpituity. You can hide yours!! I think as editor of this blog you should be forced to correct all of the rest of them so as to make future readers at least think we know what we are on about.
As to the scoring! I think we'll make it Vines ==1 - Quinnell =2
The security issue at least is something with which I totally agree. There would seem to be a host of firmware locks on micro's' of all sorts meant to protect the "artistic licence" of the frmware several of which I have before hacked simply by monitoring how the devices work. There are only a limited number of ways to do a job and if you know what the job is the rest can be worked out. These stop you reprogramming that particular device but not reprogramming another new (unlocked ) one.
None of the locks are there (certainly on the smaller devices) to actually secure the software only to hide it. Probably the biggest concern is the apparent ease that one can access if not the actual code then the routines by comparatively simple debug programs in these smaller devices.
This presents a high level of concern when you know a design can be hacked even with the lock and in all honesty even before you start the design. Not many people will hack the micro in my heating controller but if I do away with the simple controller and reolace it with a "house environmental system" it would make sense to include the whole system - even control of entry and exit, and add all the bells and whistles. Now we have a problom! (Problom?) no we have a problEm.
Hack that and open the front door!!.
We are still at the local level.
Expand this and you start burning out electric motors in your local power station - via your local SCADA system or perhaps - and there is no reported event YET - emptying the coolant from the reactor containment vessel.
That would be fun!!
Now we go parallel comparing several systems and picking the result of two out of three as being correct. Even this doesn't work as one of the space missions showed - two systems reportedly went faulty and it was the third that was correct - still we are in the sh**.
Now I am in the wrong place. I have started to accept that my system WILL be hackable. Not just recognise the fact but accept it. The next step is the mindset that it is a fact of life. To hell with the security - it will be hackable - get on with the job. Now we are DANGEROUS as designers as we have thrown out the baby with the bathwater. However very easily done.
Design cycle
Survey the job - select the device - design the firmware - test - secure - produce.
New design cycle
Survey the job - set seurity parameters - design WITH SECURITY - test - secure produce - find a good hacker to break it - resecure would at least be a bit better.
Move security from the back end of the process to the front.
This makes the whole process a good deal interesting - it stops any designer becoming complacent providing and only providing we recognise that security has a finite life and advancements will make it hackable . One can never complete a design for a critical system you will always have to be prepared to relook security. Trouble is i'me not sure that the boss or the client will accept that or recognise fully the cost implications to keep it up to date.
" My system is only ten years old! Why didn't you secure it."
"I did based on hacking then. Why have you not updated the system."
A road trafic accident is always initially the driver's fault. He was going too fast - was drunk - was on drugs - using his phone or any other reason. It is only at the end of the investigation and it was discovered that the stupid pedestrian didnt look when he stepped off the curb that he will be exonerated.
We may be in danger of entering the realm of " it was the designer's fault" that the system is not secure even if it was when designed. It will continue to be the designers fault if no positive evidence is provided to the contrary in the same way that the driver is at fault if witnesses are not available at the crash site to prove different.
Rich Quinnell 4/11/2012 3:57:33 PM User Rank Blogger
Re: Inverted Evolutions challenge MCU based design
paulyvee, no I can't spell all that well, and I type even worse (fingers fire in the wrong order), and there is no spellcheck on this posting mechanism. Sigh. At least I can go back and correct my post when folks find such errors (which I have).
I still think your analogies are overstated. There is much more similarity between an MCU and a PC than between man and dog. An MCU can be programmed to emulate a PC (albeit slowly) and a PC can serve as the core of a system just like an MCU. You can't make that same claim for man and dog.
There are many differences between MCU and PC, it is true, but these are relatively minor. You mention the PC being part of a system and the MCU standalone. Not necessarily true, however. Many of the MCU-based designs I have seen are part of systems needing additional systems or humans interacting with them in order to fulfil their function. Even my razor, which has an MCU to run the motors and lights, needs me to push buttons.
I never said the PC and MCU did the same job, by the way, only that they can have tasks in common. A wirelessly-connected MCU needs to run an IP stack just like a PC does. MCUs might need to drive displays, read keyboards, talk to printers, and so on. Same basic functions, only a difference in degree. This is why I think they are comparable in many ways.
As you said, though, the biggest difference between an MCU and a PC is that the PC was designed to do many different tasks based on reprogramming via user-selected software, while most MCU designs power-up to perform a specific task not user configurable. That difference in intent accounts for the relatively minor differences in hardware.
The biggest hardware difference is that the MCU's peripherals are integrated for cost and size reduction while the PC's are external. Having the peripherals external means the PC can put more silicon on the task than the MCU, which has an impact on the speed and sophistication of the hardware. But the functions are fundamentally the same.
I think your sledgehammer/peanut analogy is the best. Using a sledgehammer (PC) to crack a peanut is overkill, for sure, but a tack hammer (MCU) might be just right. And both are hammers, so they invite comparison.
One of the big problems that is facing MCU-based design in the next decade will be the issue of hardware and software security. As these designs increasingly become connected they will open many avenues through which malice can enter our lives. We have to realize that MCUs, even though in use are programmed for a specific purpose, are at their heart little computers that can be reprogrammed. Only then will we see that they, like the PC before them, are vulnerable to attack and compromise.
Comparing the two, looking for the similarities not the differences, is how we'll start seeing that vulnerability.
You're right that the MCU vs. CPU thing is largely a semantic issue. There's no clear-cut definition for either one, so it'll always be a matter of opinion.
For what it's worth, ARM itself refers to the A8 as the "big" part of its branded "big.LITTLE" coprocessing architecture. So at least in ARM's eyes, the A8 is the big brother, not the little brother.
paulyvee 4/11/2012 2:23:54 PM User Rank Bit twiddler
Re: Inverted Evolutions challenge MCU based design
copmputationally ??
Ah! I see you have the same trouble as me. Good as they are one has to accept that you have been unable to teach (neither have i - btw) the damned PC to spell.
I am not sure that one can even consider that a MCU and a PC do the same job - an MCU is by its nature dedicated to one specific job - tailored by hardware and firmware for this. The internal operation is not realy relavent so the computational ability of each is a given.
A PC should be considered as part of a system -the rest of the sytsem may only be you typing or as part of a data collection network or similar but standing in the corner on its own it is a very inefficient controller. The software overhead to control anything is not cost effective - many steps involved to make a multipurpose machine behave lke a MCU.
Multiple commands are required for even a basic control function simply because the data paths are available for and even designed to be multi purpose.
They are NOT the same beast. They may well have originated from the same beginnings but so did humans and dogs - a basic animal DNA.
depending on the comparison humans and dogs have the same genetic start but different inteligence - different shape - different habitats. Yet on a biological level we are the same.
On a component level the MCU and the CPU are both made os silicon. On the programming level they both have a command language. On the operational level they both have (in the main) different jobs. At this level there is no real comparison if one is to take into account the efficiency , cost effectiveness and eash of a MCU as compared to a CPU. at the level of the job - a specific task.
Granted a CPU can do it but the example of a sledgehammer to crack a peanut comes to mind.
My basic contensin s that they should not be considered comparable at the operational level - a CPU is a part of a system and an MCU a stand alone component - perhaps connected to a system to extend its capabilities but ono the less a stand alone component.
Rich Quinnell 4/10/2012 5:34:41 PM User Rank Blogger
Re: Inverted Evolutions challenge MCU based design
paulyvee, thanks for your thoughtful response. I particularly appreciate the point you make about the integrated peripherals making code for MCUs simpler, hence an expected divergence in software.
I think your motorbike/lorrie analogy is a bit overstated, though. Both MCUs and CPUs came from the same beginning. The MCUs got more computationally powerful over time, just as the CPUs did, only not as quickly. The evolutions diverged as one might expect because they tarteted different classes of problem, but their evolution has still had a good bit of parallelism. To me it's more like both starting as Model T's then one branch becoming economy cars while the other becomes SUVs and racing vehicles. The advanced features of the latter class eventually make it to economy cars.
MCUs and PCs were not intended to handle the same job, but they do perform many of the same tasks, especially now that MCUs are getting connected. So, elements of the software developed for larger CPU systems will eventually make it to MCUs as they grow in power. For the reader who posted the original comment, this seemed like MCU hardware was growing in capability while MCU software was taking hand-me-downs from larger systems. I simply tried to address that perception in my blog.
paulyvee 4/10/2012 3:37:55 PM User Rank Bit twiddler
Inverted Evolutions challenge MCU based design
It strikes me that we are tiying to compare different animals. If one transfers the comparisons to vehicular design we are coparing motorcycles and general purpose lorries.
A motorbike is esigned to carry one or two people from A to B as fast s is required and only that. It has evolved to make i faster and easier to use - better suspension, electric start and so on but is still only effective for carrying one or two people and a very limited ovehead of goods. However within these limits it arguably cannot be bettered. (of course if the weather is inclement it has its disadvantages.
A lorry is designed to carry a mulyitude of goods and is very effective at this job. However carrying two people is a bit of an overkill - although still possible.
If this idea is transferrred back to MCU's they are very good at doing a particular job and have the capability to be hardware tailored to make this job not only possible but also easy. Thus the software s bound to get "simpler" when coupled with the abundance of onboard periferals which can be instructed to do their job by sinf=gle word commands in some cases. Thy can alrady make use of high power cores (subject to requirements f the job and (at least in theory) are well capable of meeting or exceeding he speeds of "bg brother - but only assuming that the job requires this speed and the cost considerations which come it.
The PC - our heavyweight lorry can still be used as the thermostat to control your central heating but is again a bit of an overkill - unless of course one considers the possabilities of remote control and command over wireless - telephone or remote PC. Even then it is still overkill.
If one is lookin for software comparisons surely they software - firmware?? - will diverge. The MCU software will get simpler where hardware design is cost effective in doing the intermediate tasks (and has a simple command to do it - command 0C hex may possibly instruct the micro "measure room temperature and send to the actual - set comparator" At thed same time the lorry control - the PC will rquie more sophisticated firware as itis designed to do a mltitude of jobs and to increase its versatility each step must be smaller so it can then be used to do anything The same single command )C hex may be to measure temperature but must be followed with a second command to tell bigbrother what to do with the result (store it, log it, send it down the comms link or simply compare it with another perhaps preset one.
This is surely not something to be iritated about but to look forward to - keeping manufacturers designing more refined chips to do ONE or more jobs better and better, cost effectively and within the parameters of the initial job description.
A MCU going like a bat out of hell with a possible crystal controlled clock speed of 100 MHz is a bit of an overkill for our central heating controller when control loops wuld have response times of minutes or even tens of minutes dependant on how large an area to be heated. This would result in more complexity to slow thing down to match the real world.
As I started to say in the beginning just because the MCU and the PC have the same core silicon so do a motorbike and a lorry both have an engine. Compare a micro with a bimetalic thermostat in your heating system would be to compare a pushbike - pedal power versus a motor bike - true advance - both designed for - and doing similar jobs. An MCU and a PC were never inended to do the same job - except in that the intermediate stage may require a bit of compuation - so should not be compared
Rich Quinnell 3/19/2012 2:59:27 PM User Rank Blogger
Re: The Little Brother is catching up
Micropower, I agree. Little brother catching up is not in the cards near term. The extra silicon area a multi-chip solution has available will probably always be able to outperform the integrated single-ship device. One day, though, little brother will become powerful enough that there is no compelling reason to pay the cost, board space, and power overhead of a multichip design. Then maybe big brother will finally retire. Won't happen during my career, though.
MicroPower 3/19/2012 2:12:57 AM User Rank Program Manager
The Little Brother is catching up
Granted the MCU such as the A8 has made quantum progress in the last few years, it still falls short of the desktop PC power with its CPU, memory, and ample space to contain a myriad of support components.
It will take more years to come until the day if ever we see the Little Brother can finally catch up.
Rich Quinnell 3/15/2012 8:45:37 PM User Rank Blogger
Re: MCU or not?
Ryszard, this goes back to all the discussion in the blogs MCU Definitions Remain Vague, MCU Definition Sets Mental Roadblocks, and Can Readers Recognize MCUs?. In my opinion, the Freescale device is an MCU. My point is that the A8 could have appeard as a cost-effective CPU in its own right several years before it became practical for it to appear as an MCU, so in my taxonomy it would fall into the Big Brother category with the Freescale the little brother.
To save this item to your list of favorite Microcontroller Central content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
