Preferred MCU manufacturer selection

There's no one-brand-fits-all approach. Use what you're comfortable with (and have the tools for). I'm presently defaulting to STM32F chips -- but that is probably mostly because I'm comfortable with them and have a standard workflow set up. And also so I don't have to train "the hardware guy" half of the team on the care and feeding of a new architecture. ;-)

The best advice might be to check for inexpensive header/dev-boards for candidate architectures, grab the data sheets and programming manuals and give them a test drive. Try out the canonical "fire up a timer interrupt and flash an LED" and also check, say, whether the {timer | USART | I2C | CAN | USB ...} peripherals easy to use or a giant PITA.

Atmel gets high marks in my book for their support of GCC for their parts. Other companies like ST don't seem to give a toss. Of course if they use an ARM core, they get gcc suport for free. I've had good experience with TI and the MSP430 family, but their product line seems rather sparse if you want to move up a notch without going to a DSP or a high-end ARM.

I found supoprt from Samsung to be miserable if you're a small customer, but Atmel and NXP are pretty decent.

I guess I've never felt the need to pick a single microcontroller company. I think it would be more useful to pick 2-3 product families that work best for the application area (arbitrary example: TI MSP430 for low-end, NXP Cortex-M3 for mid-level, Atmel ARM9 for high end).

--
Grant Edwards               grant.b.edwards        Yow! Hand me a pair of 
                                  at               leather pants and a CASIO 
                              gmail.com            keyboard -- I'm living 
                                                   for today!

I find it odd that you would refer to companies the way you do and talk about companies not "feeling right". What is important to you about a company you buy MCUs from? Only you can determine the right company because only *you* know your needs.

If you share with us what your needs are and what is important to you, then we can give you our experiences in those regards.

I would suggest that you consider engineering aspects of the parts and consider the supplier and support issues of the company. For example, when you talk about needing "low pin-count 8-bit MCUs up to perhaps medium advanced Cortex-M3", why would you need an 8 bit part vs a 32 bit part? If you need lower performance, that's easy to meet with a high performance part, just don't clock is as fast. If you mean you need a lower cost part, then put a dollar figure on it and don't exclude parts because they have more bits, that's just a number on a data sheet that has little relevance really.

I would also suggest that you consider a single line of processors so that you can become highly proficient in that line. As others have pointed out, there is not much difference in your coding between an ARM and other instruction sets, but each company has peripherals which have their own quirks and library support. Why deal with this from multiple lines of MCUs if you don't need to?

Simplify, simplify, simplify.

--

Rick

But ST provide pretty comprehensive libraries for the STM32 range. As you say they rely upon the GCC compiler as indeed do all "ARM" manufacturers.

I can't say the same for NXP, well not for the microcontroller I used!

--
Mike Perkins 
Video Solutions Ltd 
www.videosolutions.ltd.uk

Without knowing which NXP device you found support lacking - I've used their LPC17xx series (Cortex M3) finding that their CMSIS support to be pretty good. Not completely bug free or efficient code, but the source is available so you can tweak it as needed, or use it as a base for your own code. And cost=$0 is very attractive to a small scale research support outfit.

The 8-bit Atmels are definitely less effort for smaller, less intensive jobs.

Looking at the code generated for 8-bit AVR CPUs when using C pointers makes me cringe. The complete lack of 16-bit data types is a real crippler, but you do get plenty of 8-bit registers to play with.

--
Grant Edwards               grant.b.edwards        Yow! !  Up ahead!  It's a 
                                  at               DONUT HUT!! 
                              gmail.com

The greatest expense I've seen on the software side for changing a processor is the necessary change in tool chains.

Which has pretty much driven me to use ARM Cortex-M parts almost exclusively, because I have my one tool chain and I'm happy.

I'm currently using ST parts because they seem to have the best balance between peripherals and low incidence of silicon bugs. (Certainly compared to Luminary parts, which ended up to be a great disappointment as far as silicon bugs go).

The two greatest expenses that I've seen on the circuit side of things is a lack of peripherals that do quite what one wants, and insufficient current drive -- at some point you just need to drive more current than a pin can source, and the more current a pin can source the more you can avoid external drivers. ST is good for that, Microchip is great, while to date Atmel has kinda sucked (but I haven't looked at Atmel lately).

The greatest expense on the manufacturing side comes when a chip has supply-chain problems. I've heard bad things about Atmel, but only a long time ago. I don't know who's the best now.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com

It depends on the customer, but ours specify Microchip. CPU core (PIC32) doesn't mean much to them, but supplier does.

When the customer wants a specific part, that's what you give them.

When they don't -- I prefer ARM. Some day I'll have some reasonable need for an itty bitty 8-bit processor and I'll have to eat my words, but until then -- I prefer ARM.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com

Seems a slightly strange 'feel' approach to use on a technical choice ?

Renesas claim to be #1 uC global supplier (by revenue ?), and I think Microchip are #1 by volumes.

If you are working in control and automation systems, then Infineon are worth a look.

Infineon do wide-supply voltage M0 parts, (XMC1100/120x/130x) that can cover an awful lot of applications.

.. but price, package and peripherals often matter more in a design-choice,than the core itself.

Microchip

Yes, surprisingly so:

In 2011: #1 Renesas 24% #2 Atmel 14% #3 Microchip 9% #4 Freescale 7% #5 TI 7% #6 NXP 7%

Smaller package, lower power, possibly simpler programming depending on what you're doing, lower cost.

First, thanks for a great start of the discussion!

Second, a few have commented on my "feelings" about certain companies. I probably should have elaborated that sentence a bit more. I guess I should have written "They don't feel right BECAUSE of this and that." I never meant it as a gut feeling only, it is a bit more to it than that, I assure you.

To clarify a bit more,

I am not obsessed with the bits of the MCUs. But most Cortex-Mx MCUs start at around 30-pins, and I don't think it is a good idea to put a 32-pin M3 on a board where there is only a need for a simple 8-pin MCU, which in most cases will be an 8-bitter.

I see now that one advices to select several manufacturers and another one advices to select one family only, I guess my road is in between.

This is my idea:

When the application is simple and the need is somewhere between an 8-pin and a 32-pin MCU, I would use the AVR line of MCUs. That is the tinyAvr, megaAVR or possible on rare occasions the XMEGA. When the application is bigger and we are talking about 48-pin up to perhaps 100-pins, I would use the SAMx line of MCUs. That is the M3 and M0+ devices, in our cases. I don't see a reason for using the larger AVRs here.

--------------------------------------- Posted through

Agree, STM32 SW lib is good. Any insight on Atmels ASF for SAM devices?

--------------------------------------- Posted through

? The Infineon MX1000 parts start at TSSOP-16. ( and they can pack 64KF and 16KR in to TSSOP-16.)

However, you are right that simple MCU tasks can use something smaller.

The MSOP10 package is one I like, & also the SOT23-6 for extremely simple 'corner' tasks.

That's life with an 8-bit cpu - it's inefficient for 16-bit data. Of course, since it is quite fast for an 8-bit device, it often doesn't matter much that it takes several cycles for 16-bit arithmetic. But I agree that the pointer support on the AVR is very limited - you only get three pointer registers, and much of the manipulation of these must be done using multiple 8-bit operations.

You'd be hard pushed to beat Freescale's latest package for its M0+ chips - can you name an 8-bit MCU that is smaller than 2mm x 2mm ?

Ok, if you want small package (how small?), simple programming (how simple) and low costs (how low), then specify that. Saying you want an

8 bit CPU is a poor spec as there is only a loose correlation to the features you actually care about.

The issue of 8 vs. 16 vs. 32 bit MCU has been batted around here a lot. I'm not trying to say one is better than the other. My point is to specify what you actually care about and then find the chip that best suits those requirements.

It seems odd to me that anyone would want to spend the time to get familiar with multiple MCU lines when it is very likely that unless you have a very high volume application requiring the absolute last penny be saved, you can do very well with a single brand and likely a single line of MCUs.

--

Rick

The odd thing is that "8-bit" CPUs solved that issue decades ago by including a few key 16-bit operations that allowed for efficient pointer operation and atomic read/write of 16-bit values. Atmel apparently decided to ignore those lessons and go for purity over utility.

I agree it doesn't matter much (except in cases where you want to do atomic read/write operations on a 16-bit object). But it's best not to look at the code. OTOH, with an MSP430 for the same price or less, in a packages just as small, it's a joy to look at the code generated by a C compiler. I remember looking MSP430 interrupt service routines that consisted of two instructions where the AVR equivalent was over a dozen. [And don't get me started on the always-present dataspace vs. codespace headaches.]

On TI's debit sheet, it took TI a _long_ time to get rid of its hostility towards open-source tools (gcc, gdb, etc.). They've imporoved somewhat over the past 10-12 years, but they're still lagging behind Atmel in that area.

--
Grant Edwards               grant.b.edwards        Yow! VICARIOUSLY experience 
                                  at               some reason to LIVE!! 
                              gmail.com