• A Guide to choosing Microcontroller for Hobby Projects

    SUBMITTED BY : Maxasimo

    Hmm so it's again project time, and you thought you'd leave the whole class behind this time, with your Super Dream Embedded Project. Ok you have all the ideas jotted down on the paper, but wait! Where's the little amazing brain?

    I'm talking about the poor microcontroller. We take a lot of work from that little machine (I agree it is made to do exactly the same) but never give a thought on its choice. Well, one of the most important aims of any project is economics, and you nearly forgot it.

    Here are a few guidelines and a step by step procedure to walk through the requirements of the project and choose the microcontroller that fits best into it. Although this guide is exclusively focused on Atmel uCs, but I'm in no way publicizing for them, it's just because I prefer to use Atmel and this guide should help irrespective of the make's choice.

    The Project Requirements: - Make a list of all the electronic blocks that you would require in the project. These start from the speed, move through memory, peripherals and into the I/O ports; not necessarily in the same order. Here are the outlines of how to make out this list from the project specifications: -

    Speed: - Think about the quickest job you would want the microcontroller to perform. The quickest jobs may include the following: -

    Data Sampling on the port

    Measuring small time intervals (small means nanoseconds)

    Generating high frequency waveforms (say the carrier waves for a communication link)

    Occasional Math Intensive jobs (if there's a constant and complex math oriented work, then a DSP chip would be a better choice)

    Rapid memory access. This issue may even require the chip to possess DMA (Direct Memory Access) capabilities.

    Virtual multithreading. This is a term I use to refer to performing many jobs in a specified time constraint. For example, the chip may have to scan all the ports constantly for the signals from sensors (polling, if you have insufficient interrupts), perform some calculations, send the results to the actuators such as motors, listen through the serial port to the PC and even recognize a simple image, all of which may have to occur simultaneously. This might require one to use an RTOS with multithreading support; this comes for a cost: the speed.

    Interrupts: - Most of the embedded system projects are surrounded by different external interrupts. The number sometimes may even grow to as large as 15! Since these many interrupts are not available "hard", so one can use alternatives to generate more interrupts out of the handful available. However, there is always a certain minimum number of "hard" external interrupts that one would require. One of the interrupts would be dedicated to monitor the communication channel, for example. One can follow the following procedure to decide on the number of hard interrupts that one requires: -

    1. Make out a list of all the interrupts that you would require.

    2. Sort the interrupts in terms of their priority levels. The number of distinct priority levels equals the number of hard interrupts required.

    PC Interfacing: - Most but not all the projects would require this. PC interfacing may be necessary if you have some very complex job to be done fast, but not in real time, say to search a database on a particular criterion. Both the speeds and memory are constraints here, we are however free to let the job be free of real time. This is the concept of Distributed Processing. It is also to be noted that this may sometime require a wireless communication and this might actually make the process more complicated and expensive. One may even add up a second processor exclusively to perform such math oriented tasks. In both cases, one would require a way to interface two microprocessors. One of the commonest ways is to use UART channels, available on almost all the microcontrollers.

    Timers/Counters: - These are the most used hardware components of a microcontroller apart from the processor itself. Timers are required in applications like waveform generation, timing events, measuring time intervals, serial clock generation for UART, PWM Control and so forth. An application may require more than one timer at a time, and each timer may have to be in a different mode. Some microcontrollers have a large functionality build into their timers, e.g. AVRs have timers that can trigger an event on a certain count, and all this takes place completely in hardware. These can also measure time intervals between events. One can also utilize these timers to a greater extent by coding classes to handle multiple instances of the same hardware timer.

    Analog Interfacing: - Most of the sensors and actuators are analog devices, and thus it becomes necessary to be able to produce analog outputs from the microcontroller n order to control then directly. This requires A/D and D/A converters as the internal functioning of a microcontroller is all digital. Thus one must consider the requirements of such converters and try to minimize them as much as possible, as they are expensive and it is usually not easy to multiplex them.

    Memory: - This is also an important aspect of a microcontroller. Most of the microcontrollers possess a definite amount of memory that generally suffices for the application but sometimes one has to add more memory to the system. There are generally the three types of memories: - FLASH to store program, EEPROM to store data, and SRAM to run the program. One should estimate the memory requirements and try to optimize the system so as to accommodate within the internal memory resources. Adding external memory can be quite expensive.

    I/O Lines: - After considering all the above requirements, one should come to this point. Although this is also an important point to consider, but since many I/O lines are special purpose lines, the numbers of free lines left for general I/O left are less. So one should judiciously estimate the number of general I/O lines required. One may even use multiplexers to increase the number of I/O lines.

    Once you have prepared such a list of requirements, the next step in choosing the microcontroller is to choose the architecture. This is not always easy, and one requires a deep knowledge of various microprocessor architectures to successfully choose the one. Here are again some guidelines one can follow in order to choose the architecture: -

    1. Determine the majority of work the microcontroller has to perform. If a lot of mathematical jobs are to be performed, select a microcontroller that supports complex INSTRUCTION SET and has a separate Math Processor. On the other hand, if only a lot of I/O is required, select a RISC controller, preferably with a dual pipeline so that data transfer becomes faster.

    2.Memory access times also play a major role when the application requires a lot of memory related operations, such as referring to lookup tables, modifying stored data frequently and so on.

    Once we are through the above, we have at our disposal a list of most of the requirements of the microcontroller. It's time now to search through the catalogs of different vendors and to select the appropriate microcontroller. This step can again be broken down into the following points: -

    1. Have a list of major vendors available in your locality. The availability is a major issue that is faced by amateur hobbyists. And this is an even worse problem in countries like India, where there are no fabrication plants for microcontrollers.

    2. Refer to the catalogs of different vendors and jot down the product classes, based on architecture. This can easily be done as most vendors have this classification already done for their consumers. The names of various architectures may differ from vendor to vendor, so preferably categorize them according to their properties listed above.

    3. Another important aspect in choosing the architecture and the manufacturer is the availability of low cost development tools. For example, there is a vast amount of information and free tools for the development of AVR family (and 8051 as well, one of the reasons I prefer ATMEL). So this point should also be kept in mind, especially by amateur developers.

    The above steps are one time jobs and need not be done each time you design a new product. It's not easy to switch between architecture frequently, as the learning time may sometimes cost more than the savings. Now scan through the specific requirements and try to figure out specific devices out of the above catalogs. Then compare them and shorten the list so that it matches your requirements as closely as possible. The world of embedded systems is the world of constraints and you have to learn to live like that. Once you have a few makes short listed, inquire the local market for their immediate availability and costs, and then choose the best buy!

    An important point to note here is that it is not always possible to follow the TOP-DOWN procedural approach in designing an embedded system. Sometimes one has to repeat the steps in order to fine tune the economical requirements and to improve performances. Sometimes the situation is even worse; you are given the microcontroller and you have to design the system in the limited resources. All these accomplishments come by practice and experience; they are not the one day games. Nevertheless, the above guidelines can help a lot in initial stages of the design of an embedded system.

    kEEp embedding

    A compilation from various resources from The Internet