The 8-bit MCUs won't be going away anytime soon

3/12/2010 10:22 AM EST

I complete agree that the ancient 8-bit MCU architectures like PIC and 8051 need to go. The reasons why they dominate in the 8-bit market are likely because of tradition, convervative enginners and marketing, rather than price or technical benefits. You can get a modern, much more code effective, automotive-classed 8-bit MCU for the same price.

3/12/2010 11:27 AM EST

There are things that the PICmicro line does right, which for some applications are more important than processing power or code density. First, they're available and inexpensive; getting the parts you need from Microchip is never a problem. Second, Microchip maintains availability of parts for a long time, so you don't have to worry about having to redesign an existing product to work around a discontinued part. Third, 5V-capable parts are available; the simplicity and improved noise immunity of a higher-voltage design often have value. Fourth, the wide variety of inputs (including Schmitt triggers on many of the input pins) and peripherals helps minimize external part count. Finally, all the parts with suitable pin counts are still available in DIP packages, which are handy for prototyping and for educational use, and the company has friendly sample policies.

Oh, and there are C compilers for the 8-bit PICmicro processors, and HI-Tech C (now owned by Microchip) has done away with most of the non-standard stuff. It automatically figures out the types of pointers, for example, so you don't have to jump through hoops to declare pointers as near or far or as pointers to code space or data space. It falls short of full ANSI compliance in only one significant way -- no recursive functions, which are not feasible on a device with a limited-size hardware stack. The main drawback is that you either have to spend $1200 for the Pro version or put up with terrible code generation from the Lite version.

I think that simple 8-bit microcontrollers will continue to have a place in the world. They will live on in simple systems where more processing power just isn't needed. And they will live on as I/O extenders for systems with more powerful main microcontrollers. Letting a dedicated small microcontroller deal with a fiddly bit of hardware, and then presenting easy-to-use data to the main system, can have real advantages in keeping code complexity manageable. (I still have my doubts about the continued viability of 16-bit microcontrollers, which look like they might get squeezed from both ends. But that's a discussion for another day!)

3/12/2010 11:43 AM EST

Well, that "the 4 bitter has to go" we decided more than 25 Years ago when the baby 8051 was young and that this is the key to the new heaven of better solutions..

But still 4 bitters drive the (oK cheap) MP3, CD- DVD- Players of today.

Several reasons for this "latency":
- software getting too complex, too buggy
- limited time to market - so use what is already working.
- cost for EMI suppression & external memories (I still want to see the cordless phone with a 32bit MCU and more than 600feet coverage!)
- cost for an old written off design is cheap
- simple tool environment, simplified debugging --> time to market
- technology advantages like the fact that the 8051 of today is much more powerful than the 8051 of the old days --so why not keep the design
- 8051 models are easy to get in VHDL and you can hide it somewhere between the pads of ASIC or Flash chips.
- Applications with 16 bitters require larger RAMs DRAMs & higher speed,
- emit more radiation due to higher clock speed ugly wide busses
- require more complex board design and
- still 90% of the high volum applications for the time being can still be running on 8bit MCUs

That were some of the reasons why - despite big, costly efforts - 16 bit MCU units were never really making it into the world of consumer electronics.. only the new and fancy DTV technologies invented, made 32bit MCUs a requirement (or shall I say "opened a new playing field" for engineers)

3/15/2010 3:39 AM EDT

I buy the "available" argument. Every other good thing mentioned with Microchip doesn't make them unique in any way. Freescale & Renesas for example, have all the things you mention, but at the same time they have much better cores, in terms of speed and code-density. Immunity is also one big reason why these two brands are more favored by the automotive industry, rather than PIC.

And since Microchip parts are so code-inefficient, they will actually be more expensive, as you will need larger flash memory to perform the same tasks as another MCU would do with half the code size.

Have you even looked at Microchip's competition? I think this is the real reason of their success: developers making the assumtion that Microchip have something unique. I can't see anything unique with them myself.

3/16/2010 12:04 PM EDT

I have looked at some of the other 8-bit architectures, and I'm aware of their coding advantages. I have personally done some projects with the AVR (nice architecture) and the 8051 (not much better than PICmicro). But I'm also aware of the availability issue, especially availability of older parts, and some of the competition doesn't get that right. Suppose, for example, you need to repair or build a few new units of something based on the Atmel AT90S AVR series. They don't make them any more; you either have to redesign with the almost-but-not-quite drop-in ATTiny series or find some NOS chips. But I can still buy an ancient PIC16F84 if I need it. One thing I do is amateur radio designs; tell a ham that he can't fix something because the parts are no longer made and you've probably lost a customer forever.

Availability of DIP parts is another factor for me. In ham radio the final quantities are what most professional designers would consider prototyping quantities; that is, the total run is measured in tens or hundreds, and they are often sold as kits and hand-assembled by the hams. For that application DIP parts are easier to work with (easier to solder them by hand, and you can take them out and reprogram them externally if necessary), but a lot of new microcontrollers only come in surface-mount packages. Microchip continues to offer all their PICmicros with 40 or fewer pins in DIPs. And yes, the previous argument applies strongly here; hams will dig up ten-year old projects and expect to be able to build them, and to be able to repair the thing they bought or built ten years ago.

I forgot to mention development tools. The cost of entry for Microchip's parts is very low (all the software is available for free, though you pay for a better version of the C compilers, and the least expensive debugging tool sells for under $50), which is a big factor in their popularity in the educational community. Renesas and Freescale don't offer comparably inexpensive tools. Microchip has succeeded in part by courting the people who AREN'T yet professional developers; true, some of them never become pros and the resources spent on them are wasted, but some do turn pro and order large quantities of chips.

3/16/2010 12:37 PM EDT

All automotive MCU manufacturers have decent availability: the automotive companies force the manufacturer to write a contract stating that they will keep the part alive for lots of years. Freescale for example, still provide some of their HC11 micros, 25-something years after the release. Btw, it is noteworthy that this 25 year old MCU is still more code effective than brand new PIC and 8051.

The DIP isn't really a big argument... yeah it is good... it saves me from buying a QFP holder socket for $5... wee...

Regarding tools: again, you haven't looked around. As far as I know, every MCU manufacturer offers free ANSI/ISO C compilers nowadays. Both Renesas and Freescale offer completely free, excellent compilers. You only need to pay for extra features and for the BDM/JTAG pod hardware to program them.

3/19/2010 1:48 AM EDT

Why are you advocating getting rid of the pic? They are cheap and powerful. Did you guys play with pics so long ago the uv windows put you off? Pics have good c compilers.

So as an engineer you should be saying.. "what good reasons do I have to spend more money on a 32bit processor?" Nevermind that you like the arm better.. if an 8 bit uC works for the application and is one dollar cheaper.. and the company you work for sells 100,000 of these items. Did you just take everyone's christmas bonus away because you like Arms. Are you advocating me put a Arm Cortex M-0 in a flashing led circuit inside a rubber ducky for my kid? After it wore out I took the toy apart. It had a pic 10f series 6 pin micro that is extremely small and extremely cheap. No way an arm could do that. As an engineer I have to match the hardware to the requirements that are given. I think it is really funny to tell me I need 32 bit processing so that I can flash an led. The arm guys in this forum I guess only see their own applications. People already in the 8 bit domain.. what is their motivation to spend money to switch to a 32bit processor? It would cost money to do so.. the processing power is obviously not needed in those markets. So what does an arm have that the 8 bitter doesn't when we look at the market requirements?

Professional products have pics in them. That is why microchip has the highest volume of sales of any uC company. Highest volume but not highest revenue. This means the chips are cheap and catter to the clients bottom dollar. So I say.. actions speak louder than words.

The microchip guy is correct on several arguments. The smaller process chips are not as energy efficient as the bigger chips. In the 65nm process for instance the gate dielectrics are too small. 100 angstroms. The gates on the mosfets leak a little. Multiply a couple million transistors by that leakage and you get hot chips. A cosmic ray must have a field day with that. So we won't be seeing intel quad cores in my black berry.

I learned it is better to go with a mature product than to wait till the chip maker finds the silicon errata.. while your product is in the field. So why would I bet the farm on an Arm cortex m0.. Doesn't it sound funny when a m0 finally gets to the playground and declares himself the winner? 20 years too late.

So I want to try some arm home projects because I think knowing the major platforms would make me a well rounded engineer. So I try and find a dev system.. compiler, debugger, programmer, and dev board.. all in one box.. Where do I find this all packaged and working out of the box for cheap? I have been looking for a while. Haven't found a package yet under $1000 that doesn't involve open source software. Anybody seen good documentation for open source software?.. sheesh.. man-pages.. kill me. That is product support at its finest..

3/19/2010 3:44 AM EDT

The argument here isn't 8-bit PIC VS 32-bit ARM. It seems you think those two plus Intel 64-bit heat radiators are the only processors in the world.

My argument is 8-bit sluggish, ugly PIC VS fast, modern 8-bit for the same price. Actually cheaper than PIC, as you won't need as much flash, which is the most expensive part of a MCU.

There is a horrible hype around PIC (and 8051). No they aren't cheaper than other 8-bit micros. No they aren't the only MCUs with free compilers. That was perhaps true 15 years ago, open your eyes.

Last dev kit I bought for a Renesas R8C cost me a few $100 including the pod, the compiler+debugger are free. A few $100 for the dev kit before that, a 16-bit Freescale S12X. Freescale compilers are free up to 32k code, but note that that is about 64k equivalent of PIC code, as PIC is roughly twice as code-inefficient.

3/19/2010 11:11 AM EDT

I think this article is whistling while walking past the graveyard.

The main reason for microchips success in the 8 bit world is that they catered to students and had really cheap development tools. This meant that an entire generation of developers grew us using pics.

The reality is that the pic architeture is terrible. Other processor companies have finally understood the value of close to free development systems (SiLabs for example). Even as a working engineer, it is easier to order a $50 - $100 development board (including a free Keil IDE and ICE) with a credit card, than have to deal with getting a purchase order for a $XXXX tool chain.

With ARM7 processors available for less than $2, the only real niche left for 8 bit processors is in very reduced pin count applications. I haven't seen if anyone is producing a really compact Cortex M0 yet, but as soon as a sub $1 part in a very compact package becomes available, I won't see any reason to buy 8 bit parts at all.

It is amazing how much power you can get in an $8 arm processor. I use the NXP LPC2368 in designs and it gives you ton's of processor bandwidth, 4 UARTS, CAN, USB, Ethernet, ADC's, DAC, PCA's, 512K-Bytes Flash, 64 K-Bytes RAM, etc, etc, etc.

3/21/2010 2:57 AM EDT

I disagree, the PIC architecture is awesome. Banking was crappy in the older PIC's (and even worse in competing 8-bit architectures), but the new enhanced core PIC16F1xxx architecture devices are really looking nice. Banking and pointer operations have been improved tremendously. Meanwhile, the new parts still only need 14-bits of FLASH per instruction, so die area and cost are subsequently kept at levels unreachable by 16 and 32 bit microcontrollers. Less die area and building on silicon processes with lower leakage currents gets you extreme low power that is not going to be reachable by the high end microcontrollers. There are applications where 32-bits will be the only fit, but the 8-bit MCU will be around for a long time to come in applications that require extreme low power, low cost, and fast time to market.

3/22/2010 12:39 AM EDT

I feel like pretty much everything said here is correct, and maybe obvious. But I also find it interesting that nobody just comes out and says the truly obvious: for such low-end applications, there is no other deciding factor that weighs as heavily as cost. Let's say an 8-bit MCU costs $0.75 at your quantities; I believe we all know that if a similarly capable 16- or 32-bit MCU was available for the same price, most folks would just move to a more recent architecture. I've designed 8-bit systems, and I currently work for a software vendor that serves the 32 and 64-bit markets. I get the "I only need bit, byte and occasionally word-oriented" thing, but that's an engineer's argument, and not a purchasing argument. (I'm an engineer, not a purchasing person, by the way, :) ).

Unless you need the horsepower, it's strictly cost.

Am I missing something here? I don't see an argument at all, other than price.

3/22/2010 6:13 AM EDT

DLG3 asks: "Am I missing something here? I don't see an argument at all, other than price."

Maybe that's because your're a Software engineer. Ours too always press for using one of the fancy new ARM cortexes in the next design instead of some "good old" 8-bitter.

But besides that I personally find it a little over the top using C++ to program some surveillynce funktions for voltage, overcurrent and temperature (the main task of many small µCs in our designs), there are real reasons for the "old ones":
- They don't need extra low voltage regulators for some core supply which take extra PCB space (and cost - which was DLG3's native topic).
- What's called a "high current output" of many 32-bit µCs is usually spec'ed a lot less in current than a common 8-bitter's output. So if you need to drive something serious (which in this case might include even LEDs or relays), you need extra drivers (again costs for parts and board space).
- speaking of relays: you could argue that there are 3V relays which you could use without drivers, but many of them are too susceptible to vibrations to be used in the automotive world. You don't get too much mechanical power out of 3V so everything is built (too) light here.
- Our experience shows, that most 32-bitters are a lot more susceptible for radiated disturbances (which might be partly due to their lower core voltages?). And I don't always have the luxury to use extra shielding cages (for cost, boardspace and sometimes even cooling reasons).
- most of the 32-bitters come in housings with 64+ pins (often not needed for our "system support chips"), some of them even with 0.5mm pitches. So cost for the PCBs goes up since you can't use HAL tinning, might need smaller hole sizes for your vias, need more of them etc.
- Most 32-bitters won't run without a crystal. Have a look at the efforts some manufacturers take to make their chips fail save re. clock sources and you know what I mean.
- Many of the 32-bitters aren't available with automotive temperature specifications which DQs them for my applications "right out of the datasheet".

At least in the automotive field the good old 8- and 16-bitters won't disappear anytime soon...

3/22/2010 1:29 PM EDT

Come on you guys. What are we engineers or engineers? If the tool works for you then use it. 8bit 16 bit or 32 bit there are tradeoffs for all three types. The most important feature is how long does it take to get the product up and reliably running. Most of us do not work on mega projects with 100K+ quantities so the human effort gets amortised over a relatively small number of units.
And yes you do need to understand the documentation for the I/O hardware, ignoring the documentation is a sure way to an "in the field " disaster 8/16/32 bit it makes no difference. Understanding and driving the peripherals and I/O is where the engineering bit comes in!
I do not stir my coffee with a spade but there again I do not dig the garden with a spoon, the intelligent bit is knowing when to use a spoon and when to use a spade!

Kind regards to you all

3/22/2010 2:35 PM EDT

Hi,
I fully agree with the author, 8 bits vs higher bit processors have their own application areas where one can not easily replace the other. Especially, for large volume, simple controller applications,8 bits will continue to be used. Both PIC and 8051 architecture will be used for a long time to come, since these are the ones that are being taught first in the Engineering Colleges as typical microcontrollers.

Regards,

Laktronics

3/23/2010 5:08 AM EDT

You can make a fairly decent 6-ENOB DAC peripheral with a $0.25 6-pin 8-bit micro. With a tiny bit of extra effort, you can even make it spread-spectrum, and increase the ENOBs...

That's pretty darn cost-effective.

cheers, - vic

3/23/2010 5:14 AM EDT

PS: I have loved 8-bit micro's since the 1802, but I *hate* the 8051 -- especially after using it successfully...

- vic

3/23/2010 10:28 AM EDT

I think most of you lost your focus. While I agree that the original PIC architecture is terrible (I am an user, I know it), the article is about the reasons for 8 bit uC still staying on market. Not about Microchip x Arm or Microchip x Rest of World. But once the subject arouse, just to add something about PICs: They DO have some good I/O, they used to be the only low cost chip manufacturer with VERY low cost tools (yet not any more, ok). And they DO supply all variants they advertise in ANY quantity. I remember some years ago when I was in love with Mororola (now Freescale) elegant HC11 architecture, my heart was broken when I found that all that incredible variety of models for 68HC11 were available only by request for production (you shoud ask for some thousand parts). So a small poor developer like me would be limited to a few models available on the distributor shelves or still use the model that came with the dev kit. I think this is one of the main reasons (beside cost) to Microchip to have a legion of followers. Besides low cost and silicon good quality, of course.

My best wishes for all,
Andre W.

3/23/2010 2:12 PM EDT

Some of the comments here remind me of the saying, "If the only tool you have is a hammer, every problem looks like a nail."

For some projects, 8 bits are overkill. For others, 32 might not be enough. Not because 32 isn't enough, but because you need more throughput, or addressable memory, or something REAL - not data word size!

A

3/23/2010 6:51 PM EDT

Why so much fuss about it? For sure 32-bit market will be extended, although is need serve a simple sensor(s), and execute a few tasks, it has a lot of sense. Plus C cross compilers aren't bad at all. So choose it wisely, we have need in both.

3/23/2010 10:49 PM EDT

This discussion is really interesting.
Choosing a microprocessor should depend not only on features, but on planned production quantity and development cost, too.
If there is a high volume, you need a low cost MP, if there is a low volume, you should use the easiest to use MP to save development time - that was the 6500 family for me until the advent of the ARM.
My recent project is a very low cost project, and I looked what's available.
I knew about the PIC problems, but Microchip has an amazing set of great tools. But to my surprise I recognized that the Zilog Z8 Encore had all the features I needed (even EEPROM on chip), and it was cheaper then the PIC. But I ended up with TI's MSP430 because this is the one with the lowest power needed, and the MSP430F2012 is available in DIP!
Does anyone have experience with the great looking amazing Zilog Z8 Encore?

7/28/2010 12:21 PM EDT

I agree with Steve. That was a nice,brief analysis of the current trends prevailing in the microcontroller market. I'd like to add that our good old friend, the 8051, is still active & very much kicking. There are many applications that still use the legacy 8051 core that sells at less than 1 USD ( I use this core a number of times ).
The total cost of development for cases using an 8-bit is much less, with an abundance of engineers available to do the job. Add to this the higher MIPS capacity of the new micros & you have a tough competitor for the 32-bitters !
I have been acting as a consultant & a trainer for numerous companies & have found that they typically migrate from the 8051 to the 32-bitters just because the 32-bit cores offer additional peripherals like PWM,I2C et al. However, look at the new range of 8-bit micros & you will find that besides being power-conscious, they are a resourceful lot.
Not many people realise that you can make the 8-bit micro more powerfull by adding external hardware resources like an ASIC for USB host/device/OTG or a device server ASIC for making the 8-bit web-capable.
So, I'd also like to conclude that the 8-bit core is here to stay & rock !

7/29/2010 12:26 AM EDT

Technically 8-bit micros were and are upgrading equally as 32-bit... From my personal opinion, I see a marketing stand towards sweeping all 8-bit micros with 32-bits especially Cortex M0s. I am very keen on seeing this change if it occurs i.e. whether Cortex M0 take away 8-bit share because it claims at high code-density, low-power and other strengths of typical 8-bits or any 8051s.

8/18/2010 7:13 PM EDT

One of the often overlooked aspects to this debate is the cost/effort to start up for non-experts. Sure if embedded design is your life, you'll take a more sophisticated approach, but more and more often, non-electronics folks are being tasked with adding a microcomputer into some other device, like a pump, valve, heater or other previously non-intelligent device. The learning curve, both in regards to the schematic / layout and the software can be much lower with a simple 8-bit controller. They are more often available in the larger and easier to build packages. The software tends to be quicker to learn and code and they tend to use long-standard 5 volt power. Such lower-end aspects can mean the difference between hiring an expensive embedded engineer vs tasking an ME to figure it out.

9/3/2010 6:40 PM EDT

I read these arguments, why 8-bit architectures are history and wonder how many of these engineers have really supported a high volume product that is deployed in a medical, industrial or aerospace market setting, where long testing and verification processes are the norm.
Product longevity is cherished because it has proven itself to perform with the least "errata" or bugs that newer architectures may be still ironing out.
So please do not go discontinuing proven performance with questionable one.

For short life products such as consumer mass markets, I see value with speed to market, where profits are measure on terms of days, how fast you deploy; and many times the product allows for a back door to provide ability of field upgrades for correction on the fly.
However for critical mission devices there is always going to be lag on the development effort of several years at a minimum.