It used to be that the number of different microcontroller chips available to the hobbyist was pretty limited. You got to use whatever you could manage to buy from the mail-order chip dealer, and that narrowed down the choice to a small number of chips.
But times have changed. Digikey lists over 16000 different line items under a 'microcontroller' search. Which one should a hobbyist with no particular prior experience choose?
Here are some hints. These are particularly aimed at someone trying to pick a microcontroller to use for the first time at least partially as a learning experience, rather than someone who wants to accomplish a particular task.
-------------------------------------------------------------------------------------
step 1What IS a "Microcontroller" ?
If you ever took a very introductory computer course, you probably learned about the major components of ANY computer:
A Central Processing Unit or CPU. The part that actually performs logic and math
Memory. Where the computer stores data and instructions
Input and Output or I/O. How the computer moves data between its other components and the real world.
A microprocessor uses microelectronic fabrication techniques to shrink the CPU to a very small size; usually a single "chip."
A microcontroller uses the same techniques to shrink the entire computer to a single chip (or very small module.) CPU, Memory, and I/O all in a little package as small as a grain of rice. Just connect up power and it starts doing its thing; computing and talking to the world. Usually the I/O on a microcontroller is aimed at "low level" hardware like talking to individual switches and LEDs instead of keyboards, internets, and displays (like your desktop computer.) A microcontroller is just the thing you want, if you want to talk to individual switches and LEDs...
step 2Show Stoppers
There are a number design considerations that might immediately reduce your number of choices a great deal.
Programability and Reprogramability:
At this point in time, I would say that a hobbyist should only consider microcontrollers that have internal flash or eeprom program memory and can be erased and reprogrammed a substantial number of times. There are also micros that can be used with external memory (adds complexity and expense), UV erasable micros (usually quite expensive due to the special packaging), one-time programmable chips (potentially usable after you have a working design, but losing their price advantage anyway), and mask-programmed chips (essentially useless.)
Peripherals:
If you want your microcontroller to have built in Ethernet, CAN, USB, or even multiple serial ports, many common choices are going to be eliminated. Some peripherals can be handy to have: UARTs, SPI or I2C controllers, PWM controllers, and EEPROM data memory are good examples, even though similar functionality can frequently be implemnented in software or external parts.
It's convenient if output pins can supply reasonable amounts of current for driving LEDs or transistors directly; some chips have 5mA or less drive capability.
Physical packaging:
Hobbyists are somewhat limited is the packages they are able to deal with, from a prototyping, PCB fabrication, and/or soldering. That 256 ball BGA coldfire CPU may be sweet, but it's effectively unusable by mere mortals. Microcontrollers available in 0.1in DIP packages are much easier to deal with. Probably anything with a pin spacing smaller than 0.05in should be viewed with some skepticism.
Memory:
The size of memory may be an important consideration. Some micros have as few as 256 innstructions and 16 bytes of RAM. You can do a lot in that sort of space (believe it or not), but not everything. Moreover, while you can frequently upgrade to a "bigger chip", some chip families have relatively small memory limits imposed by their architecture, so even the biggest chip you can get will have only 8k instructions (for example.) RAM (data memory) is usually scarce in microcontrollers; some algorithms require substantial RAM to be implemented in a straightforward manner, and it may be worthwhile looking for a micro with a lot of RAM (or external RAM expansion capabilities) if that's the sort of thing you had in mind. (For instance, implementing TCP/IP networking protocols in a micro whose total RAM space is less than used by a typical ethernet packet is likely to be ... interesting.)
step 3Thoughts about Architectures
The "architecture" of a microcontroller refers to the philosophy of the internal implementation, sort of. It includes details like how many "registers" there are, and how "general purpose" those registers are, whether code can execute out of data memory, whether the peripherals are treated like memory, registers, or yet something else, whether there is a stack and how it works, and so on.
You will hear people talk about how some architectures are better than others. I suppose this is true. But I'm going to claim that it is largely irrelevant for the typical hobbyist. If you wish to avoid the architectural quirks of a particular family of microcontrollers, you can use a high level language. If you're willing to program in assembler, you're at a level of interest where learning and overcoming the quirks is party of the stuff you should be learning. Besides, we're not talking here about evaluating some new architecture that some company is proposing. All of the chips I mention in this instructable have been around long enough that they've proven that their architectures are good enough for MANY real applications.
Here are some architectural "features" you may read about and some explanation of what they mean.
CISC/RISC. Complex Instruction Set Computer. Reduced Instruction Set Computer.
In the old days, CPU designers were getting clever and wanted their CPUs to support high-level language features in hardware, leading to cobol-like string manipulation instructions that accepted arguments in blocks of 8 registers. IIRC, it was Berkeley and IBM who noticed that compiler writers didn't really know how to USE such complicated instructions from a compiler, the amount of silicon real estate used by these instructions was getting large, and in fact the hardware implementation sometimes wasn't as fast as doing the same thing in software anyway. So they said "I bet we can make the CPU go a lot faster if we leave out these complex instructions and dedicate the silicon to more registers or cache memory or something", and thereby invented the RISC CPU. Nowadays "RISC" is widely used by marketing departments to mean "we don't have very many instructions", even if the rest of the architecture isn't very much like the original RISC researchers had envisioned.
Harvard Architecture.
In a Harvard architecture, the instruction memory and the data memory are separate, controlled by different buses, and sometimes have different sizes. For microcontrollers, the instructions are usually stored in "read only" memory, and data is in RAM or registers. An example is the
PIC microcontroller, where instructions are in 12, 14, or 16 bit wide flash, and data is in 8bit
wide RAM.
Von Neuman Architecture.
In a von Neuman Architecture, data and instructions share memory space, so you could do things like dynamic compilation to generate instructions in RAM and then execute them. The TI MSP430 is an example of a von Neuman architecture.
Accumulator based
In an "accumulator based" architecture, there is usually one "special" register where most of the actual computation (math, logic, etc) occurs. Some effort has to be spent to get operands into the accumulator and results back out to where you need them. The opposite is a processor with "general purpose" registers, where any of several registers can be used for math/etc.
Load/Store
A load/store architecture typically means that operands to ALU operations have to be in registers, so that you have to load them from memory beforehand and store them back when operations are complete. The opposite typically allows operations between a register or
accumulator and a memory location directly. RISC architectures tend to be load/store, since a lot or the CISCness of CISC processors shows up in implementing complex "addressing modes" for accessing the memory operands. In a RISC architecture, all that complexity only has to be implemented in the load and store instructions (if at all.)
