imPARTing Knowledge 3: Understanding Component Engineering – Microcontrollers

Oct 26th, 2011 | By | Category: Electronic Design, Technology

By Steve Terry, SK Communications
Advisor to ComponentsEngineering.com

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 the 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 “microcontroller 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 in to play for component selection.

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.

Feel like you’re ready to pick one?  Read the rest at: element14.

 

Tags: , , , , , ,