Selecting 8-bit MCUs: A practical guide

by Steve Terry , TechOnline India - November 24, 2011

Many devices may be available that will do the job, but tailoring the selection tightly to your particular needs can make for a much smoother ride in the long run. This discussion limits its focus to low-end microcontrollers. For this purpose, we'll stick with 8-bit devices.

Many small board designs benefit nicely from the use of a microcontroller. But selecting an appropriate one for a particular design often brings on the feeling of "Where do I begin?"

This discussion limits its focus to low-end microcontrollers. For this purpose, we'll stick with 8-bit devices. 8 bits simply means that internal processing only operates on 8 bits at a time. As one would expect, 16- and 32-bit micros would operate much faster as they are processing more bits of data with each instruction.

To be sure, much of the same thinking applied to 8-bit microcontrollers can be applied to 16- and 32-bit devices; however, cost, size, capabilities, performance, feature integration, and a host of other upscaled attributes quickly make it increasingly difficult to generalize on approach and applicability.

That said, even in the 8-bit microcontroller world, there are many highly specialized devices. So, to avoid confusion, we'll leave that subject for a future discussion and stay with the garden variety parts for now. Quite often, if your design truly calls for one of these specialized micros, there's not going to be much choice, and you'll likely be familiar with those choices already, so you should be okay.

What is a microcontroller, anyway?

The key trait that distinguishes a microcontroller from a microprocessor is that it's a microprocessor with a smorgasbord of built-in peripherals. For relatively simple board designs, such as controller boards, those embedded peripherals can save a lot on design effort and BOM (Bill of Materials) cost. Microcontrollers are commonly referred to as MCUs (for "micro controller unit"); it's nice and short and kinda rolls off your tongue, so we'll use it here, too.

Base MCU feature sets typically include three types of memory (flash, RAM, and EEPROM), general purpose I/O (GPIO), support for various communications ports (UART, I2C, CAN, etc.), timers/PWMs, ADCs, DACs, internal oscillators, temperature sensors, and low-power management. From there, the feature sets branch out widely. And this is really where the details come into play for component selection.

 

 

Figure 1: A typical microcontroller offers a smorgasbord of built-in peripherals that can can save a lot on design effort and BOM cost.

 

Establishing requirements

With so many vendors and varieties of low-end micros, you may find it surprising that a good percentage of them will likely satisfy your design requirements. But even though so many will usually do the job, tailoring the selection tightly to your particular needs and preferences can make for a much smoother ride in the long run.

Generally, the first step is to define what functionality you must have. For example: How many GPIO pins? (Always trying to include a few spare for those late design changes.) How many ADC or DAC channels and with what resolution? Do you need timers or PWM control? How many? 8 or 16 bit?

How do you need to communicate to other devices on this board or another board, like I2C or SPI? Keep in mind that it's always useful to bring a UART off the board for an RS232 debug port that you can connect to a terminal emulator on your PC. And any components added to the board to support it can generally be left off in volume production.

How much code space do you think you'll need? And how much RAM? (Here, we don't consider that you'll need so much extra of either one that you'll need to add external memory devices.) If you're not really sure on memory requirements, err on the high side since:


1. running out of memory can seriously impose on the ability to implement those last few features the marketing guys said they really want included, and

2. you can generally downsize the part later if it turns out you have more memory than you need - maybe do this as part of a cost reduction board spin. Or, quite often (and if you plan it carefully), it will be a pin-compatible part, so it's simply a BOM change. And, well, there's one more good reason that consistently proves prophetic:

3. Murphy's Law Corollary: Code size grows to the size of available memory + 1 byte.

 

Selection process

Now you're ready to start shopping for parts. When it comes to low-end MCUs, often the best place to start is with what might be referred to in this context as "The Big-3:" Atmel, Microchip (with the PIC family), and Renesas (which is an amalgam of Hitachi, NEC, and Mitsubishi). These manufacturers all provide broad selections at the low end and are deeply committed to the 8-bit market.

Here, though, Google won't be of much use: listing a few internal peripherals as search keywords, it will come up with millions of hits and a random mish mash of parts.

The key is to seek out each vendor's selection charts. Atmel, for example, has a giant, interactive matrix that allows you to filter the list by clicking checkboxes and setting sliders. You can get to this matrix right from their home page by selecting the Microcontroller radio button and clicking "Find." From there, select "Show in Parametric Table." Then you might start experimenting with some of the filter selections on the left, such as the AVR 8-bit parts.

For Microchip, select their 8-bit microcontrollers and look for little selector icons that say "View and sort product group by comparison chart." There's no one chart for all their 8-bit MCUs, but you can quickly get comprehensive charts for sub-categories, such as flash memory size or the PIC18 family. These include columns for datasheet sets and volume pricing, to make things that much easier.

For Renesas, you can select "MPU & MCU" from their Products drop-down menu, then select "Parametric Search" under the "Search" tab. There you can, for example, select "8-bit" to get an impressive matrix of parts that you can start whittling down based on your requirements.

To be sure, other manufacturers are well worth considering. Freescale, spun off from Motorola a few years back, still maintains the once predominant HC08 line. And STMicroelectronics has a modest set of 8-bit entries. However, these (and other) manufacturers are more committed to the 16- and 32-bit markets, so be aware that that's likely where most of their customer support resources will be directed.

NXP Semiconductors has much the same focus on higher-end micros; nonetheless, their 8-bit "legacy" offering is significant and largely a carry-over of their spin-off from Philips, thus based on the 8051 core.

 

Figure 2: While companies like NXP Semiconductors may now be focusing on higher-end MCUs like these 32-bit devices, their 8-bit "legacy" offerings can still be significant.

 

And if you have an affinity for 8051 cores, Silicon Labs is a must-see. While they may be regarded as somewhat specialized in their product lines, the offerings are so broad and varied that you might very well fall neatly into one of their niches

An old-timer, Zilog, has positioned itself as catering to the industrial market and may be worth looking at with their Z8 series.

Finally, if you want to make sure you haven't missed something or want to get a high-level perspective on devices generally, Google the terms: "wiki list of common microcontrollers" and take the first link.

Additional considerations

If the planned production volume is relatively small, then you're less cost sensitive and can afford to consider upgrading beyond minimum requirements. This is recommended when, for example, you're designing a platform you intend to use for follow-on products with (hopefully) little or no changes to the board design. Having a generous set of spare peripherals at the ready is often the best hedge against unforeseen or speculative future needs.

Check availability. A simple way to do this would be to check stock at your favorite vendor's website (Jameco, Digi-Key, Mouser, Newark/E14, etc.) to see if they stock the part. You'll also find pricing at different quantity levels. Don't forget to look at lead times; sometimes they can be prohibitively long.

For high-volume production, price must be considered from the get-go. Pare down your required feature list to the bare minimum and see how simple of a part you can live with. In the end, your final cost will come down to a negotiation with a vendor, so you'd like to have several candidate parts from different manufacturers that you can let compete with one another among the distributors.

The package type will also affect price. If you're not tied to a particular package, board space, profile limitation, or assembly technology, you can generally go with the least expensive one.

 

Figure 3: Intel's first 8-bit microcontroller, the 8048, was packaged in a 40-pin DIP.


Some applications require processing large amounts of data in which the data are more than 8 bits in width. An example might be a 12-bit A/D converter sampling at a high rate and requiring a lot of post-processing. In such cases, it may make sense to choose a microcontroller with a 16-bit core so it can keep up with the data. Again, that's not the focus here, but Texas Instruments' MSP430 line is a good example of devices that otherwise offer the benefits of an 8-bit micro - i.e., size, cost, simplicity, etc. - but operate with a more capable 16-bit core.

Development tools

Ultimately, after a particular MCU is designed in and boards are made, there's still the job of writing and debugging the firmware. For this task, the development environment can vary from super simple to highly sophisticated. Much of it depends on the developer's personal preferences and experiences, but can also be affected by budget, time, team conformance and standardization, resource availability, and a host of other factors.

However, the greatest factor in influencing the development environment may be the MCU itself. Manufacturers are always finding ways to make it easier for engineers to design with and write code for their parts, and have created a wide variety tools to accomplish this (directly or through third parties).

For example, if you're planning to design just a single board, you may gladly accept whatever development tools come with the particular MCU you choose. However, if you're planning on developing a series of boards, your efficiency and productivity will go way up if you can use the same tools for every project, thus not having to come up to speed on a new set of tools for each design. This may necessitate choosing an MCU manufacturer that provides versions of their parts that can be expected to satisfy all foreseeable design requirements.

Demo (or evaluation) boards, along with sample code, can also have a big impact. A colleague recently told me that he "never used to pay much attention to that stuff" because he would "just read the hardware manual and figure everything out on [his] own." However, recently, he found he just doesn't have that much time, and the peripherals are getting increasingly complicated. Since starting to use the example projects, he's found it "helps a lot!"

Furthermore, he points out, some of the micro vendors now have click-and-select code "builder" or "wizard" utilities that facilitate peripheral configuration - when done, you click "Generate Code" and your firmware initialization coding is complete. He vouches for the fact that it has made the board bring-up process so much easier.

Feedback

Every electronic component has both a common and a unique set of selection criteria. For a complete listing of common parameters sorted by device type, please visit www.componentsengineering.com.

Keeping in mind that no two designs are ever the same, each experience will tend to be unique. I welcome and encourage others to share what they've found especially helpful, noteworthy, critical - or even difficult - in their microcontroller design efforts.


About the author:

Steve Terry's track record includes dozens of successful firmware development projects for clients ranging from start-ups to large companies such as Logitech and Thomson/Technicolor. His breadth of skills range from tiny 8-bit processors to PC-based systems.

High profile projects include multiple digital video set-top box designs for Thomson/Technicolor, a series of digital video cable TV head-end multiplexers for Transparent Video Systems, and a handheld MPEG-4 solid state digital video camcorder for Logitech. Steve was was co-author on a patent (http://skcom.com/projects_patents.html#Patents) related to the capture, recording, and display of power line impulse disturbances.

For SK Communications, Steve led the software development for a coin counting kiosk project, developed a robust boot loader for a medical diagnostic instrument and developed the firmware for an energy-saving, heating and air-conditioning zone controller.

Steve's design approach emphasizes structure, reliability, and maintainability. His hardware background gives him the ability to debug difficult hardware/software interactions. Steve earned a Bachelor's degree from the University of Illinois at Urbana-Champaign.

About Author

Comments

blog comments powered by Disqus