A recent blog entry by Chip Overclock caught my attention. He talks about young folks selecting university majors. Some do it for money. Others for their zeal. His advice to aspiring matriculators: To be happy in any profession, you have to be successful at it. To be successful, you have to be proficient at it. To be proficient at it, you have to have spent thousands of hours practicing at it, no matter what your natural skill at it may be. You have to passionate about it, otherwise you'll never spend enough time at practice. You have to love it so much, you can't imagine not doing it.

Dave Kellogg has been thinking that the collapse in the price of 32 bit microcontrollers will kill off smaller processors: There are a several considerations that seem to be left out of the typical "will 8-bit/16-bit CPUs die" discussion. First, there is increased coding productivity with 32-bit processors.I've noticed that a lot of the 16-bit C code I write would be simpler and more robust if I could always use 32-bit math without concern for the extra overhead. For instance, depending on my numeric scaling, I often need to consider if a 16-bit add might overflow, particularly for intermediate results. But when using a 32-bit processor, this entire class of problems can (mostly) be ignored. With 32-bits, there are fewer places that overflow can occur, and hence fewer opportunities for bugs. This results in less time to write the code, as well as less time to test (and debug and fix).For large programs (>64KB) without a 32-bit address space, the normal solution is various segmentation or paging schemes. But the extra complication in linker scripts, inter-page calls, etc. costs a lot of additional effort that is not directed at solving the underlying embedded problem. This costs even more engineering labor dollars, and can run into additional man-weeks of otherwise avoidable effort (which has a negative effect on time-to-market).Although not inherently part of the 8-bit vs 32-bit comparison, debugging support must also be considered. Newer 32-bit MPUs nearly always have on-chip debug capabilities (breakpoint, trace, etc). Older 8-bit parts rarely have the same level of debug capability. So debugging on an 8-bit or 16-bit processor often takes much longer, due to lack of visibility into the CPU.Assume that the burdened cost of a software engineer is $100/hour. Suppose that going to 32-bits would reduce labor costs by 3%. ie, save 3 days ($2,400) on a 3 month project. Then assuming a 32-bit cost penalty of 10 cents (which I suspect is too high, see next point), the 32-bit is cost effective if the lifetime volume is 24,000 units or less. Secondly, the relative cost penalty of 32-bits is decreasing.Today we have 50-cent 32-bit MPUs. So the cost penalty of using 32-bit instead of 8-bit or 16-bit processors cannot exceed the ceiling of 50 cents. Considering the relatively fixed costs of packaging, distribution, etc., I doubt if the actual cost penalty for 32-bits could possibly be more than, say, 30 cents. In reality, I suspect that even a 10-cent cost penalty is too high. This makes sense when you consider how little of a MPU's die is actually dedicated to the CPU. Yes, an 8-bit CPU may take only 25% of the space of a 32-bit CPU. But if the 32-bit CPU is only 10% of the overall chip, then the potential reduction by using an 8-bit CPU instead (with the same memories and peripherals) is only 75% * 10% = 7.5%. 7.5% of a 50-cent part is less than 4 cents. As memories grow and peripherals get more powerful, this penalty for the cost of a 32-bit CPU will continue to shrink. Third, there is the cost of obsolescence. Industrial embedded products are often in production for a decade or more. The last thing I do is pick an older part for a new design. Instead, I pick a part that is no more than a year or two into its life cycle. It is a pure waste of a company's resources to do unneeded product refreshes only due to obsolescence reasons. Generally, most of newer parts are in the 32-bit world. They are also built using more recent, smaller design geometries, and hence are more cost effective than older parts. Finally, there is the power consideration.In recent years and into the foreseeable future, power consumption is and will be king. This is true for both a smart phone and a cheap musical greeting card. Consider a battery-powered application, where the vast majority of the time the MPU is sleeping. The power consumed will be roughly proportional to the amount of time that the CPU is actually awake. But when the CPU is awake, its associated memories, clocks, etc. must also be powered. This is true for both an 8-bit and a 32-bit CPU. So the actual fraction of increased power consumed by an 32-bit processor (vs an 8-bit) is moderated by the overhead of the power for the supporting circuits and memories. So a 32-bit CPU is less than four times as memory hungry as an 8-biter.As compared to an 8-biter, a 32-bit CPU typically requires shorter instruction sequences (sometimes much shorter) to implement a given block of C code. This is particularly true when the application requires 32-bit math. So typically less power per computation is required by a 32-bit CPU. As a software engineer with today's choices, I have a very hard time justifying an 8-bit or 16-bit part in any new design. 32-bit is simply less painful, and is often cheaper in the overall life cycle, too.

This is a never-ending debate! I do think things have changed a lot in the last year or two with the crash in Cortex-M series prices. But there are other factors. A lot of low-end systems are done by non-embedded people. Domain experts cobble up just a bit of code. If they are comfortable with a particular 8/16 bit CPU, they're going to stay with it. And most 32 bitters are complex to use: I/O has a zillion configuration registers, busses can be baffling, and the high clock rates bring in their own electrical and EMI issues.Then there's the package size. A 100 pin TQFP is a big part that requires serious SMT assembly capabilities. However, a lot of 8 bitters come in much more tractable packages - even DIP. There are even some six pin parts, though this year at least one series of ARM devices came out in an 8 pin package. ARM devices dominate in the 32 bit microcontroller market, and there will always be the ARM tax - the fee ARM charges for each CPU. In very cost-sensitive applications that will make them somewhat more expensive than 8 bitters. Further, low-end parts are usually made using long-extant designs with fully-depreciated fabs, further reducing costs.



Then there is the issue of power. The Cortex M0+ has some great sleep numbers but they are nowhere near those of Microchip's XLP series or TI's MSP430. So it is a matter of how much time the processor is sleeping and how long the CPU needs to be awake. This is exceedingly difficult to analyze since modern parts offer so many low-power modes, and it can be awfully hard to know how much time a given computation will take at the very beginning of a project, when selecting the CPU.I expect the vendors of low-end devices will continue to thrive for quite some time, but will face increasing pressure from the 8051-izing of 32 bit microcontrollers. Some will respond with innovative new ideas (the ultra-low sleep numbers some offer are an example). Others will fail. It does seem, though, that with time Moore's Law will drive 32 bit prices down to somewhere just above the cost of the packaging and the ARM tax. The only difference from an 8/16 bitter will be that tax. This delta will be important only for very high volume products.