Favorite budget USB MCUs

[theatrus]

I'm looking for simple (small flash, low pin, low performance) USB capable MCUs, with a good software stack for HID or VCP applications (basic control stuff).

In the past I've ended up with both ATmega8Us and the LPC1343, but feel I'm missing some other contenders. I personally haven't dabbled in PICs, and haven't really explored the rest of the CM3 space (sadly, every vendor has a different USB stack of wildly differing quality). What gems am I missing?

[oPossum]

Get the MSP430F5529 Launchpad. The F5529 has USB including a built-in bootloader, and is a relatively simple processor. No low pin count versions, but there are physically small packages.

http://www.ti.com/tool/msp-exp430f5529lp

[Dago]

ATxmegas. LUFA (http://www.fourwalledcubicle.com/LUFA.php) supports ATxmegas and it just is one of the best frameworks I've ever seen. Pleasure to use and very professionally made. You can implement pretty much any possible USB profile with it.

[nctnico]

NXP also provides LUFA for their ARM controllers. They gave it a different name but it is LUFA.

[hans]

If you're not into PICs then, let me name a few for you:

PIC16F1454 / 55; 14-pin device with 1k RAM and 8Kword flash or so. 54 has no A/D, 55 has a 10-bit one. It has 1 UART and 1 "MSSP" (I2C or SPI). Available for ~1 euro.. ridiculously cheap&small.
PIC16F1457; 20-pin edition
PIC18F25k50; 28-pin chip, 2k RAM, 16kword flash, 1UART/SPI/I2C
PIC18F26J50; 28-pin chip, 3.8K RAM, 32kword flash, 2UART/SPI/etc.
PIC24FJ64GB002; 28-pin 16-bit chip; 16 MIPS; 8K RAM, 64KB flash, remappable I/O, 2SPI/I2C/UARTs
PIC32MX250F128B; 28-pin 32-bit chip; 40/50MIPS; 32kB RAM; 128kB FLASH; similar I/O to PIC24 but not as flexible.

Note all these chips (maybe not the PIC32?) have internal oscillators accurate enough for at least low speed USB. I think it may vary, but maybe high-speed works as well (as the oscillators are often 12MHz +/- 0.25% or so)

One (big)downside; I doubt the quality of Microchips USB stack code. And their trouble with open source software (if that matters; but you can't re-distribute their stack under your project source download) is in general a PITA.

[dannyf]

Rumor has it that certain non-USB STM8/32 chips are identical to their USB-capable counterparts.

[amyk]

Anything with a soft-USB firmware. I don't think there's widely available 6/8-pin devices with hardware USB.

[Zeta]

A bit old. But I've always used the JS16 from freescale. there is a version that comes with usb bootloader in room and small packages. Great usb library

[dannyf]

ATxmegas

I would be cautious investing into that family of chips. I don't think they have much staying power.

[Dago]

I would be cautious investing into that family of chips. I don't think they have much staying power.

Why would you say that? Atmel is the 3rd largest MCU manufacturer in the world and the XMEGA line is their primary 8 bit platform. They have been going from strength to strength with new models being released regularly. At work we have been given 10 year availability guarantees, with compatible replacements for at least 15 years. What a bizarre thing to say.

Yeah. I recommend the atxmegas mainly cause they just are so super nice to use. The event system is very nice, the datasheets are very consistent and concise. Just overall almost flawless little microcontrollers (and I wouldn't say that lightly about anything!).

All ARMs I've used seem to be much more inconsistent, ports have weird amount of pins (PB3 and PB9 here, PA1, 4 and 6 over here and PA3 somewhere totally elsewhere etc.) and have crappier datasheets. Just my experience.

[dannyf]

I recommend the atxmegas mainly cause they just are so super nice to use.

I would be surprised if there is any future for those chips (put in their AVR32 - the homebrew version, and PIC32. The jury is still out on STM8). I think those chips are introduced to delay the inevitable - that AVR users will migrate to 32-bit chips.

There is simply no compelling reason to use those chips.

[Dago]

I recommend the atxmegas mainly cause they just are so super nice to use.

I would be surprised if there is any future for those chips (put in their AVR32 - the homebrew version, and PIC32. The jury is still out on STM8). I think those chips are introduced to delay the inevitable - that AVR users will migrate to 32-bit chips.

There is simply no compelling reason to use those chips.

Might very well be. But it's not gonna happen fast. But I would not worry about that unless you're designing for some really long lifetime applications.

Btw. For example Microchip still manufactures each and every one of it microcontrollers it has ever introduced.

[dannyf]

But it's not gonna happen fast.

Probably but I would be surprised if those chips are still in material shipment 5 - 10 years from now.

Btw. For example Microchip still manufactures each and every one of it microcontrollers it has ever introduced.

For every Microchip that's doing that, you can find 10 Microchips that are no longer in business.

[Bored@Work]

Yeah. I recommend the atxmegas mainly cause they just are so super nice to use.

They lost a lot of good will over the introduction of those controllers.

For a long time the xmegeas were not available at all, while Atmel was lying through their teeth and marketing them as available and buying themselves awards for those non-existing MCUs. Then the disastrous silicon errors when they were finally available. Accompanied with a new disastrous IDE, a disastrous library, and expensive new programmers required.

Many of the originally announced xmegas never shipped. Leaving people in the cold who trusted Atmel and started development on a smaller xmega or one missing a critical feature, believing they could soon get the right one.

Worst of all, Atmel refused to acknowledge the problems and to talk about them. The xmega disaster was what ultimately drove us away from Atmel. They lost all our trust.

[nctnico]

Btw. For example Microchip still manufactures each and every one of it microcontrollers it has ever introduced.

Look at the prices you pay for vintage chips. Usually brokers stock old parts and sell them for a huge profit but it seems Microchip is doing the stocking themselves. The problem with old chips is that these take older processes/factories to produce. So either the designs must be shrunk so they can be produced in modern factories or they must keep old (obsolete) factories open.

[Bored@Work]

Interesting spin on events.

It is not a spin. The xmegas were announced in February 2008 as immediate available, but you couldn't get one. In the same year Atmel bought themselves some awards for the non-existing MCU, the EDN China Innovation Award and the 2008 Product of the Year Award by Electronic Products Magazine. Mind you, for an MCU no one could get.

In 2009 Atmel showed some eval board, which you couldn't get then. Not for love or money.

In 2010, two years after the immediate available announcement you could occasionally get an engineering sample.  Around 2011, maybe late 2010 you could buy the dreadful rev G silicon and a little bit later the still very much broken rev H silicon.

In the meantime announced xmegas just silently disappeared. E.g. the A1 family was announced containing not only the 128A1 and 64A1, but also 192A1, 256A1 and 384A1. So in theory you could start with the 128A1 and later on in your project do some rightsizing. In practice the 64A1 appeared very late, and the others never materialized. The D4 (or was it D3?) series had a similar faith.

People were not just confused about the ADC or other new periphery. The errata, after Atmel finally came clean, listed some really horrible things. The ADC broken, the DAC broken (just something like 200 LSB off in some mode ...), the BOD self-enabling and locking you out of the chip in some cases, I2C timing broken, part of the clock system broken. And a few nastinesses that never made it into the errata, but were present. Like Atmel couldn't be bothered to perform the specified factory calibration. 

A lot of what made these new MCUs interesting was broken. And that after people waited more than two years to finally get some. Oh, also famous on some series was the error that you couldn't write to the EEPROM without completely holding the MCU clock.

And that joke of a library was indeed called ASF. You could spend a lot of time debugging the library. It was as if the ones writing the library had no access to the real silicon and never tested their code. But Atmel was pushing the library very hard. And you could only use it with Atmel's horror IDE. The IDE that refused to install, refused to start, refused to properly communicate with its own debugging backend and refused to work with Atmel's very own programmers. Not to mention that Atmel promised a cross-platform development environment and instead delivered a Windows-only PoS. 

The xmegas were shitty to work with, and for a long time Atmel denied there were problems. It was Atmel's behavior that finally broke the camel's back. Just too many broken promises.

[SirNick]

All ARMs I've used seem to be much more inconsistent, ports have weird amount of pins (PB3 and PB9 here, PA1, 4 and 6 over here and PA3 somewhere totally elsewhere etc.)

I've noticed that too.  Is there a reason for it?  Seems like it would make routing parallel buses an ugly PITA.

[dannyf]

Is there a reason for it?

"ARM chip" is a misnomer in that it doesn't exist as a chip. Instead, it is a standard core (provided by ARM) married to peripherals provided by chip vendors (NXP / ST / TI ...).

So while there is 100% standardization on the instructions, there is zero standardization on the peripherals and how they work.

Thus, books like "the definitive guide to arm" have very limited value for people who program those chips. It is the datasheets that matter.

[SirNick]

I'm not quite sure what you're getting at.  Neither I nor Dago referred to ARM as "a chip".  My question was why certain implementations (or in Dago's case, all he's used) seem to have the consecutive port pins spread all willy-nilly across the package.  Is there method to the madness?  Are silicon designers just masochists, or particularly hate PCB designers and want to make them cry?  Maybe this isn't even universally true.  I don't know, I haven't looked at all that many ARM(-based) MCUs.  But on the ones I have looked at, it was a rather crazy pin order.  Ironically, many of the other peripherals are physically clustered together.  (Though certainly not all.)

As to the book, I get your position there, although I kinda feel like it's akin to saying "all PCs are Intel or AMD chips wrapped in custom motherboards with various peripherals, so why bother reading about the x86?"  I figure the material's relevance strongly coincides with what you do and how you do it.

In terms of the ARM core in particular, I noticed that many in the M-series lack a division instruction.  While I did happen upon that factoid in a datasheet, I'm sure there are hundreds of similar useful little tidbits in a book focused on the generic core architecture.  Does it matter to a C programmer?  Maybe.  I'm sure the compiler will take my "x = y / z;" statement and Do The Right Thing, but if I know in advance that it's a soft implementation, I might be more careful to avoid division in my algorithms where I can.  So it's still potentially quite useful to know.

Just my 2c.

[nctnico]

Why is the pin order important? Usually the pins are grouped by peripheral so you have related pins close to eachother. Needing a parallel bus is really uncommon nowadays. If you really want an ARM with the port pins in sequential order look at the LPC1200 series from NXP.

[SirNick]

Don't need it, just curious.

The times I've used a parallel bus in the past were to interface to (e.g.) a WizNet Ethernet controller (although there are plenty of micros with built-in Ethernet), to interface with external memory (can use dedicated memory interfaces instead), or to control clusters of devices (LEDs, etc.) in physical order without having to do PCB gymnastics or waste cycles shifting data around first (I suppose you could just use a shift register instead).

It's not a deal-breaker or anything, but if you're a manufacturer laying out a die, what's the point of moving those port pins all over the place?  Is there a reason you can't have ports in consecutive order, and their alternate peripheral functions also aligned thusly?  Is there something inherent to the core, or some other tangible benefit, that makes it desirable?  Maybe it's just an opportunity to play Where's Waldo with P0.7?

[nicknml]

Very easy to breadboard and cheap.
http://www.ti.com/tool/msp-exp430g2


I also like the good old ATmega328 as you can sink/source a considerable amount of current on the i/o pins compared with a lot of the newer mcu's.

I would love to see TI  make a DIP version of the MSP430F5529.

[westfw]

Very easy to breadboard and cheap.

But NOT "usb"; let's please stay on-topic, because once you branch out into "what's your favorite microprocessor" you never get anywhere.

XMEGA-wise, You can count me as one of the disappointed.   I don't think the smaller A-series chips (ATxmega64a4, for example) ever showed up for real.  (they didn't have USB either, so they're also off-topic.  The USB versions of the same chip were somewhat heralded as the first xMegas that were fully usable, IIRC, and people interested in a 64a4 were encouraged to just move on the 64a4u.)

[Dago]

Why is the pin order important? Usually the pins are grouped by peripheral so you have related pins close to eachother. Needing a parallel bus is really uncommon nowadays. If you really want an ARM with the port pins in sequential order look at the LPC1200 series from NXP.

It's not essential of course but sometimes you do need to make a parallel bus or have other uses where you'd like to have a bunch of pins next to each other on the same port.

It also makes layout cleaner, makes using the part much simpler (you do not have to check the datasheet every single time you lay a pin since you know there's no missing pins like in atxmegas). Also makes code simpler.

[janoc]

Why would you use an XMega when you can have an STM32F10x or STM32F30x for essentially the same money? You can get a 32bit chip with a lot more power and hardware than 8bit XMega. Furthermore, you don't need to depend on Atmel-proprietary debuggers and programmers, any SWD or JTAG adaptor works with the ST chips.

Someone mentioned "free compiler and IDE" - well, GCC works with every ARM in existence and Eclipse is just fine for an IDE, thank you very much. A lot of functionality works even better than in the Visual Studio (e.g. the Intellisense crap).

I have always been an Atmel guy, but it makes little economical sense to use XMegas for me.

E.g. (Digikey prices, only stocked parts):
Cheapest USB-enabled XMega:
ATXMEGA16A4U-AUR (16kB Flash, TQFP44) $3.62

Cheapest STM32F10x:
STM32F102R4T6A (16kB Flash, LQFP64) $4.41

RadioSpares here in France:
ATXMEGA192C3-AU (32MHz,192o Flash,TQFP64 - that's the cheapest USB-enabled they have here) 3,81€
STM32F102C4T6A (16kB Flash, QFP48) 2.56€
STM32F102CBT6 (128kB Flash, QFP48) 4,11€

If you want to go even cheaper, then Microchip has the new 18F14k50 PICs, those cost like 2€ each in singles, but programming USB on them is a bit more tricky - both because of the architecture, small amount of RAM and the Microchip's compiler woes (well documented elsewhere on this forum)

[janoc]

It's not a deal-breaker or anything, but if you're a manufacturer laying out a die, what's the point of moving those port pins all over the place?  Is there a reason you can't have ports in consecutive order, and their alternate peripheral functions also aligned thusly?  Is there something inherent to the core, or some other tangible benefit, that makes it desirable?  Maybe it's just an opportunity to play Where's Waldo with P0.7?

Don't forget that on many modern chips you can remap pins and move the functionality where you need it. It is more playing "Where's Waldo" in the datasheet to find the location where is which function mapped (each pin can have 5-6 alternative functions + you can remap them!) than identifying the physical pins these days.

[dannyf]

you do not have to check the datasheet every single time you lay a pin since you know there's no missing pins like in atxmegas).

That's a dangerous habit.

Also makes code simpler.

Don't see how.

Why would you use an XMega when you can have an STM32F10x or STM32F30x for essentially the same money?

A few:

1) human factors: programmer's capabilities? learning curve? lack of skills? ...
2) software: migrating existing code base can be expensive and sometimes impossible?
3) customer needs: they may not like it?
4) marketing?
5) ruggedness? simpler chips tend to be more resistant to interference.
...

[Dago]

It's not a deal-breaker or anything, but if you're a manufacturer laying out a die, what's the point of moving those port pins all over the place?  Is there a reason you can't have ports in consecutive order, and their alternate peripheral functions also aligned thusly?  Is there something inherent to the core, or some other tangible benefit, that makes it desirable?  Maybe it's just an opportunity to play Where's Waldo with P0.7?

Don't forget that on many modern chips you can remap pins and move the functionality where you need it. It is more playing "Where's Waldo" in the datasheet to find the location where is which function mapped (each pin can have 5-6 alternative functions + you can remap them!) than identifying the physical pins these days.

Well this remap thing is quite silly for some STM32 chip I'm developing for currently. Yeah there are multiple pins for lets say the I2C module... except the multiple pins are right next to each other. So By remapping I get pretty much nothing. Should be spread around the chip to make for a cleaner layout. And all the ADC pins are mainly on the port A. But then most of the peripheral functions are also mapped to mainly on port A. So if I need a bunch of ADC pins it gets very difficult to have enough pins for the rest of the stuff, gah. And currently I'm using two timer channels with complementary outputs and you'd assume the outputs would be close to eachother... but nope, these are spread around the MCU without a chance to route them in a clean way.

So far my experience with STM32 is that nobody has really thought about making development pleasant. Even the MCU names are extremely confusing. I'm currently using a STM32F303CCT6 MCU and the headers refer to this as STM32F303x6 and the datasheet refers to it as the STM32F303xC (and datasheet also has a part named STM32F303x6 but it is a different part).

Also often component cost is a fairly small factor in parts selection. Varying of course widely by industry and project volumes. But I do agree if you have any need for speed then ARM is the right choice. For many (if not most) microcontroller projects speed is a non-issue though.

Btw. I think SiLabs or someone had a very interesting "crowbar" remapping where you could almost without limitations remap peripherals to GPIO ports. That seemed pretty neat. The software support for that with GCC was non-existant at the time when I was looking in to it though.

[dannyf]

Should be spread around the chip to make for a cleaner layout.

It should be arbitrary - a perfect example is the remappable pin implementation on PIC24.

Btw. I think SiLabs or someone had a very interesting "crowbar" remapping where you could almost without limitations remap peripherals to GPIO ports.

aka PIC24F. I think some low-pin count LPC chips have that too.

In comparison, STM's remappable pin implementation is quite rudimentary.

[Jeroen3]

Some chips even go further, the LPC43xx series for example. It has P1_7, which corresponds to GPIO1[0] or P3_4 with GPIO1[14]. Good luck with that.
_{Remark: Note that the pin name is not indicative of the GPIO port assigned to it.}

However, question was a budget USB mcu.
You can either go sample some STM chips with usb, they provide USB examples and there are usb drivers available in chibios.
Or you can get an LPC11U24 or LPC1769 with the mbed USB libraries.
Or possibly some lesser known chips from Freescale or Cypress.
But if an 8 bit ATxmega can do your job, then you'll be just fine using that.
Remember Atmel prices contain Atmel studio development. STM/NXP prices do not contain the license to an IDE, you'll have to get it somewhere else.

[dannyf]

Remember Atmel prices contain Atmel studio development.

Atmel studio development = IDE (VS Express = free) + Compiler (gcc = free).

It is OK to pay for free things, but...

STM/NXP prices do not contain the license to an IDE,

STM: CooCox (Eclipse IDE + gcc), emIDE and emBlocks, ......

NXP: LPCXpress (Eclipse IDE + gcc).

Seems to be quite comparable to me, and as you suggested, they are truly free and none of the costs are baked in the chips. You seem to be making a great case FOR STM/NXP?

[Corporate666]

Probably but I would be surprised if those chips are still in material shipment 5 - 10 years from now.

Atmel has guaranteed availability for at least 15 years (or compatible parts, like the MEGA-P and PU series they did). If they decided to back out there would be huge legal liabilities. On top of that it would destroy their credibility in the industry. It just isn't going to happen.

Don't let the promises fool you.  I got screwed by Atmel on the same promises.  They came out with their super low cost MCU, I think it was the Tiny 11 at the time, and their selling point was $0.25/ea in reels... a remarkable price point that would let MCU's take over many jobs previously handled by analog or discrete logic chips.  We designed that ATTiny chip into a very cost sensitive product... within a few months, the original chip was discontinued, replaced by an upgraded model, I believe the ATTINY13 which had various improvements like ADC/EEPROM or whatever... none of which we needed.  The price was "upgraded" also, to $1.25 in reels.  A 500% jump.

Not long after (IIRC, less than a year), that chip was also discontinued and replaced by another "upgrade" in features.... and in price, to $1.50 in reels.  Presumably Atmel got a lot of backlash, because the prices came down, but it was not the first time Atmel did that.  They discontinue chips with alarming regularity and replace them with bigger (in features and price) chips. 

[Corporate666]

Yeah. I recommend the atxmegas mainly cause they just are so super nice to use.

They lost a lot of good will over the introduction of those controllers.

For a long time the xmegeas were not available at all, while Atmel was lying through their teeth and marketing them as available and buying themselves awards for those non-existing MCUs. Then the disastrous silicon errors when they were finally available. Accompanied with a new disastrous IDE, a disastrous library, and expensive new programmers required.

Many of the originally announced xmegas never shipped. Leaving people in the cold who trusted Atmel and started development on a smaller xmega or one missing a critical feature, believing they could soon get the right one.

Worst of all, Atmel refused to acknowledge the problems and to talk about them. The xmega disaster was what ultimately drove us away from Atmel. They lost all our trust.

Wow, your story mirrors mine almost exactly.

We were asked by a customer to develop a new product - an industrial tachometer, to be shown off in 6 months at an important industry trade show.  I was looking at Atmel's website and saw the much hyped XMega.  After talking with our FAE, he couldn't stop raving about how amazing the chip was and how it would be so easy to use, blah blah.  He assured me I could get samples immediately and lead time on reels would be 4-6 weeks or less... and that they were in mass production now, but the chip was soooo popular that they had a huge backlog of orders.

So we designed the chip into our product.  I distinctly remember that our samples were so delayed that I ended up buying a couple of eval boards from eBay (Atmel had given them away at some event and many ended up on eBay) and desoldering the chips from them to get some prototypes working.  And after pulling our hair out trying to get the project working, there was some bug in the ADC (don't recall the specifics this long after) that just made it non-working at all in our application.  Various folks at Atmel *promised* to high heaven that it was fixed in production silicon that would be available in mere weeks.

They never showed.  Ever.  We ended up cobbling together a totally hacked "prototype" of that product for the show that consisted of a Cypress dev board under the desk and a huge ribbon cable hacked onto the LED display of the product.

I distinctly remember getting the call from someone @ Atmel to let me know my samples had shipped - we had already scrapped the XMega idea and scrapped Atmel alltogether... and it was well over a YEAR from when we were first told that we could get a reel within a few weeks.

By that point, I had designed any Atmel chips out of any products that were in development, and since then we've designed them out of every product when we came up on redesigns.  Just like with you - Atmel just totally lost our trust.

That was not the only incident, but it was one of a few and it was by far the biggest.  I remember sitting in a large room filled with electronic design engineers getting a presentation from Atmel about some chip with built-in LCD control.  They had a slide with a BOM and costs... it had this $14 chip listed as "Less than $1".  When he got to that line, the room literally erupted in laughter.  The nordic guy giving the presentation got flustered and defensive at this and tried to sternly correct the audience that this was realistic pricing - which pissed off a few audience members who then took him to task on it.  He later admitted that this price was a special deal negotiated for one customer as a chip-on-board version in million-per-month quantities.  Everyone was laughing and guffawing at the excuses this guy was making about how these new chips were money savers and how they were going to be around to stay.

I realized that I wasn't the only victim of Atmel's pricing/availability/life-span business tactics.  A real eye-opener.  Not to mention the stack of ridiculous junk I spent a few grand on - STK600's with ridiculous adapters for various chips - Dragon's that had some flaw that caused them to burn out with regularity, and ISP programmers that died regularly (got a box full of dead versions of those).  Just crap, crap, crap.

[Vasi]

Very easy to breadboard and cheap.

But NOT "usb"; let's please stay on-topic, because once you branch out into "what's your favorite microprocessor" you never get anywhere.

XMEGA-wise, You can count me as one of the disappointed.   I don't think the smaller A-series chips (ATxmega64a4, for example) ever showed up for real.  (they didn't have USB either, so they're also off-topic.  The USB versions of the same chip were somewhat heralded as the first xMegas that were fully usable, IIRC, and people interested in a 64a4 were encouraged to just move on the 64a4u.)

SAM D21 - ATMEL advertise them as the next step for ATmega users (and maybe that is why there will be Arduino ZERO) and it came also in TQFP cases. What do you think?

[Kjelt]

In volume XMEGA is cheaper from Farnell:
ATXMEGA16A4U - £1.08 for 2000+
STM32F102C4T6A - £1.20 for 2000+

In those quantities I would call the factory distributor in your country and be amazed at what can be done if you order these regularly a complete reel at a time 

[nctnico]

Why would you use an XMega when you can have an STM32F10x or STM32F30x for essentially the same money? You can get a 32bit chip with a lot more power and hardware than 8bit XMega. Furthermore, you don't need to depend on Atmel-proprietary debuggers and programmers, any SWD or JTAG adaptor works with the ST chips.

Sorry, but these two platforms are not at all the same thing. Skimming the STM32F102x4 datasheet the current consumption is through the roof - 7mA at 8MHz, and a massive 32mA at 48MHz which still doesn't give you the I/O performance of an XMEGA at 32MHz which only needs 6mA. The 16K flash memory won't go nearly as far with ARM code either, and that 16K includes the bootloader where as on XMEGA you get an EXTRA 4k on top (so really the total memory size is 20k).

Someone mentioned "free compiler and IDE" - well, GCC works with every ARM in existence and Eclipse is just fine for an IDE, thank you very much. A lot of functionality works even better than in the Visual Studio (e.g. the Intellisense crap).

Atmel Studio comes with Visual Assist which is the best code completion tool ever. Seriously. It really does help improve code quality. Also GCC for ARM is fine, but what about debugging? Do you have source level stepping and real-time monitoring in the IDE?

Eclipse does all that. If you are used to Eclipse then having to use Visual Studio is like taking a cold shower when it is winter. IMHO the chips from ST are not the 'best' ARM chips you can get so make a poor comparison. For some reason they are popular because they are a few cents cheaper. NXP's ARM controllers consume less power. The LPC1111 for example consumes about 9mA when running at 48MHz.

[westfw]

SAM D21

Haven't you been listening?  The SAMD21 is a new Atmel product: its actual existence is not to be trusted until digikey and mouser both have had stock for "a while."  So far, the only D21 even in the catalog is the eval board...

(another Atmel horror story: remember the ATmega328p-pu shortage, where Atmel couldn't ship enough chips to keep a hobby board supplier supplied?)

[theatrus]

Sounds like we need a thread on "I've been burned by X" :-)   For the record, I too was burned by the xMega ADC and DAC problems (amazing spec sheet, never worked that well). Also burned by the Luminary/TI LM3 cancellation (though it had been years and was clear nothing was ever going to ship), and the Energy Micro (now SiLabs) Draco radio (slipped for years).

LUFA is bloated, but easy enough to understand. I have yet to make the jump over to ASF, but remembered finding some severe USB bugs back when I was using an AVR32 (!) in a project.

[Vasi]

(another Atmel horror story: remember the ATmega328p-pu shortage, where Atmel couldn't ship enough chips to keep a hobby board supplier supplied?)

I remember that one but, you know, I have an ASUS X202E laptop with an ATMEL chip for the touchscreen inside ...
And I'm hopping that now there are good times for ATMEL. Now ATmega/ATtiny series are fueling almost the entire Maker movement.

[Corporate666]

Strange, Mouser and Digikey bother still stock ATtiny models at those price ranges and pin compatible with the tiny11. Atmel usually only retire products when there is an easy migration path, often binary compatible. I'm not sure why you changed to vastly more expensive parts.

No, they don't.

Unless you consider more than double the price to be in the same price range.  And I'm not sure if you read my post, but the current pricing is about 1/3rd what it was a couple of years ago.

We changed to "vastly more expensive parts" because Atmel forced us to.  They came out with a part that was $0.25, then within the span of some months, it was discontinued, and Atmel's pin-compatible replacement was 500% more expensive.  Then that part was discontinued and replaced with another one that was about 20% more expensive still.  When I spoke to my FAE at Atmel about this, I just got bullshit excuses about how so many of their customers were just delighted with the new features of the ATTINY13 chips and felt the price was more than worth it. 

Bullshit.  There was a lot of complaining on AVRFreaks at the time.  Looks like their website is down, but the last post on this thread (Cached version) jives exactly with what the experienced.

http://webcache.googleusercontent.com/search?q=cache:IZxrkWolxm4J:www.avrfreaks.net/index.php%3Fname%3DPNphpBB2%26file%3Dprintview%26t%3D53596%26start%3D0+&cd=14&hl=en&ct=clnk&gl=us

Atmel loves to highlight their advantage as not being tied down with a bunch of legacy BS the same way Microchip is - but they discontinue parts with reckless abandon, and feel that a 500% more expensive replacement is acceptable.

Just to add some extra straw to the camel's back , we also had issues with ATTINY's "popcorning" - i.e. failing during the reflow process.  We had a few batches where the failure rate was around 30%.  When we talked to Atmel, they couldn't care less... "well, we adhere to JEDEC standards, so it's something you are doing wrong".  Except we were using a ridiculously expensive and process controlled reflow oven and were reflowing the boards within 30 minutes of when the reel was opened - a reel which had come directly from Atmel.  Only when cornered did they even agree to look at the chips, confirming they had popcorned and stating we must have done something wrong.  Strange that it was an issue for a few months and the problem disappeared as quickly as it started - all with chips from similar lot numbers. 

Contrast that with Cypress who decapped and analyzed chips for us when we experienced 3 failures out of a few thousand.  Atmel just doesn't give a shit.

[stevech]

I moved from AVRs to Teensy 3.1 ... because of value, small size, large memory, 32 bit, great library, great forum

http://www.pjrc.com/teensy/index.html
http://forum.pjrc.com/forum.php

[dannyf]

I moved from AVRs to Teensy 3.1

Paul is an upstanding guy. His bootloader is infinitely better than the arduino ones and the freescale chips are infinitely better than arduino arm offerings.

Arduino users are fool to migrate up without giving him a look.

[janoc]

Eclipse does all that. If you are used to Eclipse then having to use Visual Studio is like taking a cold shower when it is winter. IMHO the chips from ST are not the 'best' ARM chips you can get so make a poor comparison. For some reason they are popular because they are a few cents cheaper. NXP's ARM controllers consume less power. The LPC1111 for example consumes about 9mA when running at 48MHz.

Fully agree on Eclipse - the CDT plugin for C/C++ in Eclipse works a lot better for code editing than anything Visual Studio ever had, unless you want to buy a ton of plugins and extensions for Visual Studio.

The debugger in VS is decent, though - the one in Eclipse works only with gdb (problem when developing for Windows using MS compiler ). Most often I am writing code in Eclipse and running Visual Studio debugger in a second window on the side to debug. The only issue I have with Eclipse is that the configuration can be arcane (but have you seen the VS one?!) and that it can get sluggish at times (VS often just crashes outright though ...)

NXP chips are decent, I have been playing LPC17xx series, but they are a bit harder to get here. I need a one-offs and most distributors aren't too keen to deal with customers like me. ST is more widely available and a tad cheaper here too.

Let's not get into the discussion which ARM is the "best" ARM, that would be a worse flamewar than the eternal Atmel vs Microchip discussion 

[Kjelt]

Microchip is not a preferred supplier with my company since they *&*&^* up a couple of years ago.
We designed a uC of them in a mass product but when the production started after a year of R&D en pre-dev they couldn't deliver the amounts necessary.
The factory was ready to go , PCBs and all components ordered but from the I believe around 1 million uC's ordered we got 150000  (15%) and they told us we should wait till next quarter for the next batch (also probably 150000).
It was game over for them at that moment, we redesigned the product, had to do all the retesting again, huge write off.
They might be better now but in the past they had logistical issues to deliver huge quantities. So if you are designing and need huge quantities better make a good contract with them with a huge penalty for not delivering on time, that's the only way to deal with it.

[dannyf]

around 1 million uC's ordered we got 150000

Their issue is that they have too broad of a portfolio so the demand for each chip doesn't allow large scale production. So when a big order comes, they are unprepared for that.

I think it would have been a lot better to produce a feature rich chip and sell it at a lower mark-up so it covers a larger set of applications. The economy of scale would work better in that case for them.

[Kjelt]

Their issue is that they have too broad of a portfolio so the demand for each chip doesn't allow large scale production. So when a big order comes, they are unprepared for that.

A company as ST also has a broad portfolio but has no problem with those numbers of uC's 

[dannyf]

ST's microcontroller portfolio is probably less than 50% of Microchip's, if not 10% of microchip's.

Not to mention that ST is a far bigger company overall.

[Kjelt]

ST's microcontroller portfolio is probably less than 50% of Microchip's, if not 10% of microchip's.

I didn't know that, seeing all the different packages and types ST sells ..........

Not to mention that ST is a far bigger company overall.

Well that is the whole point isn't it?

[dannyf]

OK.

For mcu offerings:

digikey: 13000 microchip vs. 2000 st;
mouser: 9500 microchip vs. 1200 st;
avnet: 12000 microchip vs. 2300 st.
...

Now, it is not scientific and quite flawed but generally points you in the right direction.

Microchip's advantage is its huge installed base.

Unfortunately, its disadvantage is also its huge installed base.

Well that is the whole point isn't it?

Yeah -> a smaller company + a more diversified portfolio -> even less economy of scale.

[Kjelt]

Microchip's advantage is its huge installed base.
Unfortunately, its disadvantage is also its huge installed base. 

Must be the quote of the day 

[dannyf]

That's what they meant when they say that "a sword cuts both ways".

[Corporate666]

Back then Atmel had problems with distributors charging silly prices for new parts. The great price reduction that happened shortly after the ATtiny13's introduction was actually just Atmel getting vendors to be sensible, i.e. Atmel didn't reduce their wholesale prices at all. I'm not saying it wasn't a genuine fuck-up at the time, but you could definitely by the ATtiny13 for around your original target price if you had a good distributor or went to Atmel direct.

That's definitely not true - I'm sure someone at Atmel claims it was distributor gouging but it's absolutely not the case.  I remember the "oh shit" moment when I saw the prices on the Tiny chips jumped from $0.25 to $1.25... all the distributors mentioned that Atmel had done big price increases that they were passing along, but I also have a good friend who works at Digikey in executive management of their buying division and I ran it by him and heard the same thing - Atmel had raised their prices dramatically and I knew what Digikey's before and after pricing was on that specific part.  Even Atmel at the time acknowledged that they had raised prices substantially on parts - that's where the "but we also added features so everyone is really happy!" line came from - it was their boilerplate reply to the (presumably) massive push-back from the users.  And it wasn't just on new parts either - we were also using a lot of Mega8 chips at the time and the prices went up, and up and up.  I was buying from Atmel directly in pretty decent volume and they were asking if we wanted to retain a blanket PO for Mega's at the lower price after the increase (i.e. when it was in my favor they wanted to ditch the PO) but when the price cut happened the story was the opposite. 

We had similar issues with PICs. I'm not picking on Microchip, it's just that we used to use a lot of them. We used a lot of 24 series and found that our board manufacturer's process was killing a significant number of them. We opened a support ticket with Microchip and they did eventually acknowledge it and stated it would be fixed in later revision silicon, as well as a couple of other bugs that were causing occasional EEPROM write failures. I could characterize it was Microchip "not giving a shit" if I were so inclined, but it' just par for the course.

Oh, I agree, I am sure many manufacturers have similar problems - certainly not limited to Atmel, but as with any customer service issue, it's always "what do you do about it when the problem occurs" that matters most.  I've had interactions with Avago, Alpha Omega Semi, TI, On-Semi, National, Cypress, Atmel, Philips/Lumileds, and others.  Atmel is far and away the leader in the "we don't give a shit so fuck off" category for how they treat their customers.  Philips/Lumileds is firmly in second place.  AOZ, Cypress, On Semi, and Avago all went above and beyond to take care of me and fix problems I was having.  National and TI were OK but I had to do a lot of legwork and prodding to get issues resolved.  Just my experience, but Atmel is at the very top of my shit list for repeated and egregious shitting upon their customers with no remorse.