Microcontroller selection - How do you choose?

10/13/2010 1:08 AM EDT

In my case I would say that it all depended upon the Field application Engineers ability to sell me a particular company's processor. The ability of the field application engineer in explaining the positive points about the MCU he is selling, the tool kit and free samples he is ready to give me during the development phase, the amount of effort he spends in getting my application developed , all these things mattered . Especially in 8 bit micro controllers the space is so crowded that you finally rely on the salesman rather than find out those hair thin differences between various families of processors from the data books given by the manufacturers. Some obvious features specific to your application you will always look for like the PWM if your are doing a motor control application, TV tuner interface if you are developing a set=top-box, a good built-in ADC if you are doing some measurement application and so on.

10/15/2010 12:18 PM EDT

I think you left out a critical point: Economics.

If you are making a low volume unit, say 10K pieces and under, then most of the time, it makes little sense to change from your current vendor the cost of learning new tools coupled with the risk is likely going to swamp any cost savings. That is assuming you can find a suitable part with your current vendor.

I also use PIC on the low end 8 bit though considered changing recently as I found their cost not keeping up but some new low end parts have kept me in the fray.

That said, I am not using them for higher performance parts as the cost/feature sets did not meet my goals when amortized over the next 3 years when I was choosing parts.

10/15/2010 6:02 PM EDT

Many time selection of uC is done by one of first user or senior engineer. Once selection is done and development tools are procured and expertise is developed, we try to employ same uC and solve many different applications. Advantage being, it is readily available and that you like to keep inventory of parts to minimum. Same is true for FPGAs too. Ingenuity of circuit design is to achieve new solution with available parts be it uC or op-amp or ADC/DACs.

10/16/2010 10:22 AM EDT

For me, the selection would depend largely on the application requirement & to some extent, economics. When you have a team that has a fair experience, the learning curve paranoia becomes a smaller gating factor as compared to others.
Many a times, the application requirement drives us to choose a chip that can host operating systems like Linux or an RTOS - in that case you do not have too many choices.
However, I'd suggest to the relatively inexperienced engineers to get used to using newer parts. Given the fact that an ability to use newer parts is developed, it helps a long way !

10/18/2010 11:41 AM EDT

When we look at chipsets, we are looking at low enough volumes (sub 1000/yr) that the NRE usually masks the recurring cost of the processor in the device.

So the first decision is whether the processor family we use is economically viable for our solution and does it (or a family member) have the features we require. If so, we use it.

If not, then it breaks down to selecting the processor based on does the the processor meet our solution.

Next, does it support Embedded Linux (our OS of choice)? We've invested in using embedded linux and all of our software development team is experienced and trained in it. The cost of a new embedded OS in training and learning curve can easily mask the cost of a 1000 CPUs.

Finally, what is the least expensive solution to satisfy the requirements.

10/18/2010 12:01 PM EDT

That's a good point about the economics as a major factor. Certainly at higher volumes, it becomes one of the primary determinants. In low-volume, high margin applications, a designer has the luxury of being picky.

Above a certain point, the ability to shave a few cents off will weigh much more heavily. If the hardware PWM costs anything more than the amount of RAM needed to replicate the function in software, the hardware PWM will be tossed out the window.

10/18/2010 1:17 PM EDT

As a matter of staying up to date, I try to read the engineering publications and visit vendors web sites to stay up to date on product offerings. If part look interesting, I will order development kits to explore new parts and design tools.

During design time, the inertia behind the use of known component families and toolsets makes me default to considering those familiar component families first. If time allows, I will investigate other vendors offerings to see what additional optimization (cost, space, features, power consumption, schedule, etc.) may be possible. I normally try to have the product landscape assessed before a part needs to be chosen for a particular task.

In my experience, foreign (Japanese and Korean specifically) suppliers have proven consistently difficult to get timely information and support. I will consider them only if the design cannot be solved with vendors that provide better support. Having a design come to a screeching halt due to a vendor's lack of ability or willingness to acknowledge and resolve new errata or provide additional documentation on specific functionality is a risk I would rather avoid.

10/19/2010 5:12 AM EDT

I have a query regarding choosing between 16-bit dual core freescale and PIC.

I want to implement RTOS on 16-bit microcontroller...

I have worked extensively on 8-bit PIC and 8-bit AVR (ATmega Series...)

I feel that architecture of dual core 16-bit Freescale is difficult to master as compared with PIC...

Also i see less support on internet for Freescale as compared with PIC...

Which one should i choose for RTOS 16-bit PIC or 16-bit dual core Freescale

10/19/2010 9:58 AM EDT

Hi,
Since you already are exposed to the PIC family & tools, it makes a lot of sense to go for the 16-bit PIC usage.
There is a port already available of an RTOS called freertos for the PIC 16 family. So, most of the things are lined-up for you. Check wwww.freertos.org
You'd normally use a dual core chip if the application demands so. Is your application so demanding that you are compelled to think about the dual-core solution ?

10/20/2010 3:31 PM EDT

The last post illustrates the realities of design better than many; a legacy of hardware or software or tradition is a driver for many of our decisions. But engineering is about constraints and for some of us, too much choice is the problem! I always start from the status quo because experience will usually see me through; but when that is ruled out I go for another family I will have been tracking as a part of my obsessive trainspotting of uP architectures. Study and keep up to date - you owe it to yourselves.

10/21/2010 5:38 AM EDT

there are other critical aspects, especially while you choose low price, low end mcu's.

1. swappable register sets implementation
2. Register sets where all can be Accumulators
3. user friendly instruction set for assembly coding
4. Software implementable stack vis-a-vis hardware stack
5. Free tools upgrade
Zilog Z-8 family scores well, though it is not discussed much in forums.

sayee

9/21/2011 6:30 AM EDT

in my opinion personal inclinations or the 'comfort factor' should never be allowed to interfere with the selection process. in today's fast evolving embedded scene one can never run away from the process of upgradation. If you are good with MPLAB, then you can be better with the knowledge of CCS. . even if one is unwilling to make the effort to learn a new tool chain, another resource who can do the stuff (with ease at lower costs)is never far away(at least in indian context), the only scenario i can see where developers preference may drive the selection is when the project is on a very tight deadline and time to deliver dsnt allow the learning curve of a new tool chain.
otherwise while making the selection for a MCU/MPU the technical evaluation panel should take special care that they are not being skewed by the developers and base their decisions purely on cost/features/requirements. If the developers are too lazy or stubborn to learn a new tool-chain(which will only enhance their skillset) then it is they who should be the losers and not the company.