A search in an online catalogue for microcontroller units (MCUs) would lead you to a massive collection of thousands upon thousands of various MCUs, leaving you spoilt for choice. There would be so many good choices that it would be difficult to make a decision. The following is what the experienced designers in the industry advise.
For most embedded systems, you have the choice between 8-bit, 16-bit and 32-bit cores. When it comes to applications involving computations, 32-bit cores have a clear edge over 8-bit and 16-bit, in addition to making the most of the compiler features.
Basavaraj Garadi, chief expert, Robert Bosch Engineering and Business Solutions, shares, “Personally, I am not a great fan of 16-bit controllers. They are passé. Of late, 8-bit controllers don’t have significant cost advantage either. Moreover, when it comes to the available choices in operating systems, the 32-bit core is a clear winner. The RISC and CISC architectures have become a little less meaningful with continued evolution of both the CISC and RISC designs and implementations.”
“The architecture of a microcontroller refers to the philosophy of the internal implementation,” explains Jigar Patel, CTO, Mansi Research. “It includes details like how many registers are used, whether the code can execute out of the data memory, whether the peripherals are treated like memory, registers or something else, whether there is a stack and how it works, and so on. A RISC processor can handle simple math functions much faster, but a CISC processor will handle complicated functions faster because it can do them all at once instead of the several processing commands that a RISC processor would have to take to complete the same function.”
Personally, I am not a great fan of 16-bit controllers. They are passé. Of late, 8-bit controllers don’t have a significant cost advantage either
— Basavaraj Garadi, Chief Expert, Robert Bosch Engineering and Business Solutions
MCU process technology, architecture and memory technology also need to be considered as these affect the real calculation speed rather than MHz and memory size requirements.
“Since RISC core requires a load or store instruction to access any data item in the memory, a memory-to-memory move requires a load operation to first read the data from the source and temporarily store it into a general register, then a store operation to move the data from the register out to the memory. This requires four CPU clock cycles to execute and 4 bytes of code storage space. An RX MCU, on the other hand, can move the data item directly from the memory source to the memory with no need for load/store operation. This takes only three CPU clocks and 2-byte code size, thus giving 165DMIPS calculation speed with only 100MHz core,” explains Wang Kaifei, assistant principal engineer, Renesas Electronics Singapore.
When it comes to the architecture, another issue that you may come across is DSP versus general-purpose microcontroller.
“Honestly, the line between the two is narrowing by the day. Microcontrollers are designed for simple math and control (of other devices) functions. Some may also come with hardware multiplication units. DSPs are processors optimised for processing the streaming signal. These have special instructions that speed-up common tasks such as multiply-accumulate in a single instruction, as well as other vector or SIMD (single-instruction multiple-data) instructions. They are usually designed to operate in one big loop, processing a data stream. DSPs can be designed as integer, fixed-point or floating-point processors,” adds Garadi.
Chip vendor support and development tools play a very important role among selection verticals
— Siddharth Patel, lead engineer-embedded software, EATON India Engineering Centre
2. Programming language. This is indirectly related to the MCU but directly to the tool chain used. The most popular programming languages for MCUs are Assembly (ASM) and Embedded C.
Working with ASM is much more time-consuming but gives you great insight into the architecture and actual working of the MCU. However, when the code size efficiency does not matter as much as the time to develop, Embedded C is the way to go. Again, you can write efficient code in ‘C’ and some projects require you to use ‘C’ to keep things simple.
For most of the 8051s available in the Indian market, Keil supports the code in ASM and Embedded C. For the PIC series, MPLAB has a CCS plugin (I use this as opposed to Hi-Tech Compiler), which enables you to code a PIC in ‘C’. So before you select the chip, make sure a tool chain with the right options is available for development. Do consider the cost of the same as many of them do not have free versions.
3. GPIOs and features. Manufacturers release many MCUs of similar specifications but different features and resolutions. Select a chip that has all the features with the resolution as per your needs. Try to keep external chip interfacing to a minimum. This will help you in your design. Also make sure your MCU has sufficient input/output (I/O) pins for your needs. Try using alternate modes for peripherals—like 4-bit LCD mode—to save some I/O pins.
4. Cost. If it is your first time working with an MCU, there is no need to purchase an expensive MCU. We all have had our share of burnt MCUs, and likely you will too. So keep the cost low initially. Weigh all the points mentioned here (and elsewhere too) and select an appropriately priced MCU that suits your budget. For absolute beginners, I would recommend AT89S series and P89V51RD2 (expensive but has PWMs) from 8051 family, and PIC16F877A (has ADCs too) from PIC family. In general, 8051s tend to be cheaper than PICs, which are cheaper than Atmega’s, but PICs have much more functionality.
5. Availability. Select an MCU that will be available for a long time to come. There is no general rule of thumb to know this, but selecting a popular one is your best bet. (The ones mentioned above are most widely used in many universities.) If for some reason you select an MCU which is not available in India, you may have to pay additional shipping charges to get it, which will be costly as well as frustrating.
6. Online support. This is crucial when you’re just venturing out and when you move on to 32-bit cores. Selecting an MCU which has good online support will help you with your ideas and solve most of your problems as the experience of other users is available for your reference. Getting to know existing bugs with tool chains or MCU documentation will help you avert the problem in advance and speed up development.
7. Packaging. For most DIY projects, a DIP package is suitable and easy to work with. SMD packages are a bit difficult to work with without proper tools and therefore not recommended for first timers. Once the design is ready, you can always use SMD equivalents to make it more compact.
—Compiled by Frenoy Osburn at EFY’s Community of Electronics Pros (www.forum.electronicsforu.com)
As microcontrollers have been available for a very long time, the selection decision in the industry is now governed by the support from chip vendor and development tools, not the price and features.
Siddharth Patel, lead engineer-embedded software, EATON India Engineering Centre, explains: “Now we have multiple vendors offering chips with the same CPU core and similar features at almost similar prices across various segments. So now chip vendor support and development tools play a very important role among selection verticals.”
Sai Ram Mannar, founder and director, GreenOcean Research Labs, adds, “The availability and richness of the development tools is a key aspect. As these tools are expensive and mostly tied to the microcontroller, they need to be evaluated clearly, ensuring flexibility of the tool in supporting multiple families with ease. The debugging capabilities and an easy graphic user interface (GUI) for configuring the various peripherals of the MCU also help a lot.”
The key parameters to be considered while selecting an MCU should also include the possibility of reduction in the number of electronic components. This will allow integration of more functionality
— Prashant Mahendrakar, Technical Manager at Sankalp Semiconductor
How much should you focus on application requirements?
The application requirements of an embedded system under development have a big say on the system processing needs. Based on these requirements, you select the MCU. The question is: “Should I choose strictly based on the requirements from a commercial perspective or consider the greater good of all?
“This part is usually taken very seriously during MCU selection in our firm. We usually do not prefer to use too many different types of MCUs in our products only to tightly match the application requirements. This would leave us with too many tools of development and maintenance, which unnecessarily blocks lots of money. Instead, we have carefully chosen a few powerful devices and also a few low-profile devices that we choose from,” explains T. Anand, managing director, Knewron.
Plato Pathrose, senior engineer, design & development, Tata Elxsi, explains how things work in the automotive industry: “Automotive compliance of the MCU should be considered at first; without this, nothing could be taken inside the automotive industry. Next, we look for product familiarity in development, which could reduce the development costs and increase the flexibility in usage. Following this, we look into the availability of the tools and samples and also the vendor’s support during the course of development.”
“The key parameters to be considered while selecting an MCU should also include the possibility of reduction in the number of electronic components with the MCU. This will allow integration of more functionality. For instance, you can integrate more memory (Flash/RAM) and a multiprocessor,” adds Prashant Mahendrakar, technical manager at Sankalp Semiconductor.
Don’t forget about memory
The cutthroat competition in the market has pushed software development so much that we now live in a world that seems to be obsessed with the ‘Beta Culture.’ Almost every new service or product is run on Beta software. The designer should keep this in mind while choosing the memory size for his product. The software that he has been given now may soon bloat up as bugs get squashed and new features added. So there better be memory available for the update.
Jigar Patel says, “Some algorithms require substantial RAM to be implemented in a straightforward manner. It may be worthwhile looking for a micro with a lot of RAM. On the other hand, the size of the Flash memory depends on the size of the object file generated by the assembler/compiler. The size of the Flash program memory is an important factor when the user has decided to use the internal program memory. The user must keep in mind to keep a few percentage (depending on the nature of the application) of the free space in the program memory for future requirements.”
When choosing memory sizes (of all kinds), we give a thought to scalability (if it is planned) such that tomorrow we may update the program. This would need additional memory, so the installed MCU should have the margin already built-in. We go with the closest possible option. When in doubt, we go with one slot higher option.
— T. Anand, Managing Director at Knewron
Anand adds, “When choosing memory sizes (of all kinds), we give a thought to scalability (if it is planned) such that tomorrow we may update the program; this would need additional memory, so the installed MCU should have the margin already built-in. This margin has to be around 15-20 per cent. MCU sizes usually come in different slots such as 4kB, 8kB, 16kB and so on. Therefore we go with the closest possible option. When in doubt, we go with one slot higher option.”
Scalability is very important for a commercial embedded system to stay viable in the market over the long run.
Shrenik Shikhare, embedded software engineer, Maven Systems, says, “Embedded designers must have their eye beyond their designs and think strategically when selecting platforms with appropriate migration paths for long duration, feature set and performance. As scalability is the ability to handle the growing workload that may come in the future, one should think in all directions—whether the system will perform well to handle the extra work after adding some hardware into the existing system, or the existing system itself is capable of handling the extra work in the future. In short, your system must be designed for upcoming workload while fulfilling the current requirements too.”
“The memory technology used inside the MCU also affects its calculation speed. Some MCUs use MONOS flash technology, which can run up to 100 MHz with zero wait states. This differs from other MCUs that use normal flash technology and need to insert wait states, dropping CPU performance a lot,” adds Wang Kaifei.
Availability is an important consideration for commercial designs. You would have different requirements for different stages of development—for instance, smaller quantities for engineering samples, and larger ones once you enter production. Moreover, make sure that the MCU is available in the future by ensuring that it’s not nearing obsolescence
— Vivek Tyagi, Country Sales Manager, Freescale Semiconductor India
Think about the future
If you want your product to be available in the market for at least a couple of years, you have to consider the number of years that the selected microcontroller has been in the market. An almost obsolete microcontroller which you have chosen just because you are very familiar with it, is like a ticking time bomb ready to blow back up on you. If the MCU later becomes obsolete, it will result in having to rewrite a lot of code and change the PCB—I am sure you would not want to be responsible for that.
Vivek Tyagi, country sales manager, Freescale Semiconductor India, explains, “Availability is an impor-tant consideration for commercial designs. You would have different requirements for different stages of development—for instance, smaller quantities for engineering samples, and larger ones once you enter production. Moreover, you should make sure that the MCU is available in the future by ensuring that it is not nearing obsolescence.”
Anand adds, “Many a times, MCU families come up with specific programming methods, programmers, IDEs, tools, etc. This means changing from one family to another not only changes the MCU cost and parameters but also the additional maintenance and overhead cost— in some cases, total ownership costs too.”
There are a lot of other considerations to look at while choosing an MCU family.
“The roadmap of an MCU family ensures that the time and investment made in choosing the family are futureproofing the designs. It simplifies migration and helps in optimisation of the forthcoming product releases. Pin and package compatibility would ensure that the design could scale up or down easily by just replacing the processor with minimal or no board change. Software compatibility ensures that the software written for one device would be reusable on another device,” says Sai Ram Mannar.
Siddharth adds, “With growing demand to roll out products faster in the market, full-fledged BSPs and software compatibility between various MCU segments have become a major selection criteria for new designs. While selecting new MCUs, it is also important to understand the product life-cycle in which it is going to be used. Selection criteria may be different if the MCU is required for enhancing the existing product or for a totally new product.”