Atmel versus NXP

[Sal Ammoniac]

Anyone used both the Atmel and NXP ARM Cortex-M4 MCUs? How do they compare with respect to features, peripherals, documentation, development tools, etc?

I have experience with the NXP LPC17xx and LPC43xx parts, but none with the Atmel SAM series.

[nctnico]

If you want to use Atmel be sure to spell out every little detail in the datasheet. I'm not using Atmel devices anymore due to too many problems with their devices.

[Sal Ammoniac]

Can you elaborate on the problems you've had with Atmel ARM chips?

[nctnico]

Not specifically with their ARM chips but -to put it in an elegant way- Atmel is very optimistic with their specifications and their chips aren't very well prepared for being used in a noisy environment. For example: if the datasheet says an Atmel chip can run at 1.8V then it can't do that in any real circuit. Logic level thresholds/hysteresis can also be sub standard which doesn't help with noise immunity. In short: Atmel stands for low budget, poorly designed products in which every corner has been cut. You'd have to do a lot of testing yourself to find out whether a chip from Atmel really holds up in your circuit or not.

[mark03]

I had a brief brush with the LPC43xx and the experience made me never want to use NXP ARMs again.  They included some rather innovative and unique peripherals on the chip, but then failed to document how to use them.  I watched on the official NXP support forum as, time and again, perfectly reasonable questions were ignored by the NXP moderators and [only sometimes] answered through a lot of trial and error by the community.

As just one example, a relatively high-profile open-source project (HackRF) was almost derailed because no one, NXP included, could figure out how to use DMA with the SGPIO peripheral!  That project's use of the LPC43xx was salvaged by using the companion M0 core instead.

So these may be [may have been?] the fastest and most capable M4 chips on paper, but in practice it didn't do much good.  Why silicon vendors shoot themselves in the foot like this is beyond me.  It's like leaving money on the table!  I only hope the Freescale MCU division gets the upper hand in the upcoming merger.  They seem marginally more competent although their documentation still sucks.  Personally I am rooting for Silabs (formerly Energy Micro).  Their tech support was a dream, at least before the acquisition---not sure if it is still that good.

[Scrts]

Why not ST, Renesas or TI then? Still plenty options to consider.

My experience with NXP was bad because of their development kits were not working properly connected to USB... Went to ST and became happy.

[janoc]

Atmel stands for low budget, ...

Uh, their prices I certainly wouldn't call "low budget", though!

On the other hand, you can find similar gotchas with almost every manufacturer (STM32 peripherals can be a nightmare, some PICs have erratas as long as a roll of toilet paper, ...). So singling Atmel out is perhaps a bit unfair.

Unfortunately poor documentation, bad vendor libraries/tools and silicon bugs are a standard fare in this field. As you said - the only way to be sure that the device (from any vendor, not just Atmel!) will work as intended is to prototype and test, test and test.

[JohnnyBerg]

@ntcnico: what are you using, obviously not Atmel?

I have played with STM32, but de development tools and libraries where, to put it mildly, not as good as Atmel.

[Bassman59]

I had a brief brush with the LPC43xx and the experience made me never want to use NXP ARMs again.  They included some rather innovative and unique peripherals on the chip, but then failed to document how to use them.  I watched on the official NXP support forum as, time and again, perfectly reasonable questions were ignored by the NXP moderators and [only sometimes] answered through a lot of trial and error by the community.

As just one example, a relatively high-profile open-source project (HackRF) was almost derailed because no one, NXP included, could figure out how to use DMA with the SGPIO peripheral!  That project's use of the LPC43xx was salvaged by using the companion M0 core instead.

So these may be [may have been?] the fastest and most capable M4 chips on paper, but in practice it didn't do much good.

I had considered an LPC1800-series device for a high-speed USB audio device. But after going through the process of configuring the device, I realized that it was impossible to use the I2S peripheral while also using the SPI flash interface. It was kind of baffling as to why, but it made the part unusable.

There was also an issue with the LPC18xx's external bus interface, which was mentioned on the forum as a bug: http://www.lpcware.com/content/forum/emc-generates-double-read-cycles-static-chip-selects which makes it less than useful for attaching this bus to an FPGA. (Plus there's no way to use the bus clock to clock the FPGA, which would be quite handy.)

So it looks like an Atmel SAM3U is the thing to use.

Why silicon vendors shoot themselves in the foot like this is beyond me.  It's like leaving money on the table!  I only hope the Freescale MCU division gets the upper hand in the upcoming merger.  They seem marginally more competent although their documentation still sucks.  Personally I am rooting for Silabs (formerly Energy Micro).  Their tech support was a dream, at least before the acquisition---not sure if it is still that good.

SiLabs has always been great. I haven't used any of the former Energy parts but I've used tons of their 8051s over the years. I like their Precision32 devices, too (they are faster than all of the Energy parts) but I don't know if that line is moving forward.

I did ask them if they were considering a High Speed USB interface, and they didn't give me a definite yes or no, which I suppose is reasonable (nobody comments on upcoming products).

[nctnico]

@ntcnico: what are you using, obviously not Atmel?

I have played with STM32, but de development tools and libraries where, to put it mildly, not as good as Atmel.

I have been using the ARM based controller from NXP for almost a decade. The installed base is in the thousands by now. But every now and then I inherit a design with a different microcontroller. I don't really care about vendor provided tools or libraries. The libaries are usually written by interns anyway. I use Eclipse exclusively. I'm more interested in examples on how to use the peripherals to get going quickly. I have my own libraries and run time environment which work on about any microcontroller.

[0xdeadbeef]

I second NXP. I used the Cortex M3 and M0(+) devices like LCP1768, LCP812, LCP1347 and LCP1549. Overall very good peripherals, fast I/O, the bigger devices have very good DMA support and some of the newer ones have on board trace memory. Datasheets/manuals/application notes are pretty good even compared to what you get e.g. from Freescale as a big industrial customer.
Also the LPCXpresso IDE is pretty nice, has only minor limitations (256k code size) and supports several JTAG probes. Then again, it's hard to beat the LPC-Link 2 for < 20€.

[poorchava]

Atmel uses IDE which is essentially Visual Studio with some mods aiming towards making it usable for microcontroller development. And it was done terribly. It is not very stable, doesn't handle debugging  very well and is just plain different from any other arm IDE (code warrior,  code composer, coide, that-nxp-thing-however-its-called,  pure Eclipse).

As far as I know some of Atmel's CM4 microcontrollers are best in class when it comes to power consumption vs processing power (provided that you use an external smps for core voltage)

[Jeroen3]

As just one example, a relatively high-profile open-source project (HackRF) was almost derailed because no one, NXP included, could figure out how to use DMA with the SGPIO peripheral!  That project's use of the LPC43xx was salvaged by using the companion M0 core instead.

That is because the M0's are the DMA of the SGPIO's.
Anyways, indeed the documentation is sometimes fuzzy or missing. The parts seem very robust.

Nobody forces you to use vendor-locked IDE's with ARM processors. You can use any IDE suite you like.

[janoc]

Atmel uses IDE which is essentially Visual Studio with some mods aiming towards making it usable for microcontroller development. And it was done terribly. It is not very stable, doesn't handle debugging  very well and is just plain different from any other arm IDE (code warrior,  code composer, coide, that-nxp-thing-however-its-called,  pure Eclipse).

Well, I guess they can't make everyone happy. Lot of people on this forum complain that IDE XYZ is horrible exactly because it is not Visual Studio.

Personally speaking, I find Visual Studio absolutely terrible and backwards in many aspects unless you pay a lot of money for extensions to make it actually semi-usable - it can't even rename identifiers out of the box ... The only thing that is decent is the debugger if you are developing for Windows.  However, many people can't imagine developing in anything else.

[senso]

Its a mater of taste, love AS6, hate anything Eclipse based, feels strange.

[nctnico]

Eclipse definitely takes some getting used to because it is aimed at dealing with large software projects. I have been using it for about a decade now. They added an extra layer which they call a workspace. Within that workspace you can have multiple projects. In different languages and/or for different targets if you want. It all plays nicely together. I have workspaces which mix a C++ PC application, VHDL and embedded C code. Eclipse has definitely boosted my productivity.
The major advantages of Eclipse are the highly configurable well working editor and the way it helps you to navigate through your code. IMHO it is well worth the effort to learn how to use Eclipse. Because of the wide support of languages you'll never have to learn to work with a different IDE.

[Sal Ammoniac]

Every ARM I look at from every vendor seems to have a nasty errata that makes it hard to use in some way. For example, I recently did a project using the LPC4357 and it turns out NXP goofed up the CAN peripheral register decoding so that if you use one of the CAN ports, you can't use any other peripheral attached to the same peripheral bus. 

I've heard the ST Cortex-M3 and M4 parts have seriously messed up I2C peripherals that require jumping through hoops to tame.

I'm just looking for a part that doesn't have an errata list as long as my arm (pun intended).

[0xdeadbeef]

Well, honestly, every microcontroller I had to do with at work in the last 16 years or so had more or less dramatic errata.
It is not uncommon to have errata sheets with more than 40 pages for complex controllers.
The question is how a manufacturer handles them. Are there up to date errata sheets publicly available? How detailed is the error/context description? Do the offer workarounds? Are the known errata fixed in time?

Anyway, as a side note: by chance I noticed that NXP released a new version of LPCXpresso lately that finally offers data watch trace over SWO for M3/M3 CPUs:
http://www.lpcware.com/content/faq/lpcxpresso/trace-overview

Haven't tried it yet, but having a data watch trace in a free IDE with a 18€ debug probe is pretty nice...

[nctnico]

Every ARM I look at from every vendor seems to have a nasty errata that makes it hard to use in some way. For example, I recently did a project using the LPC4357 and it turns out NXP goofed up the CAN peripheral register decoding so that if you use one of the CAN ports, you can't use any other peripheral attached to the same peripheral bus. 

I've heard the ST Cortex-M3 and M4 parts have seriously messed up I2C peripherals that require jumping through hoops to tame.

I'm just looking for a part that doesn't have an errata list as long as my arm (pun intended).

Look at the LPC11E67 for example. It's errata sheet is empty. The smaller ARM microcontroller from NXP usually have very few (annoying) bugs because they have been using the same peripherals for many chips for a long time.

[Jeroen3]

It's literally empty http://www.nxp.com/documents/errata_sheet/ES_LPC11E6X.pdf
But that only means they've not found them yet, right?

[poorchava]

Don't get me wrong - I like visual Studio very much, I use it mainly for C# development (my go-to language for Windows apps) and have never complained.

The problem is,  that on Atmel IDE there are serious flaws,  like for example not being  able to display register contents in binary format during debugging. The Atmel studio is also quite unstable for me - it crashes I would say 2-3 times a day on average.

[andersm]

But that only means they've not found them yet, right?

Some years ago I was working on a project that intended to use the then-new LPC1768, and its errata sheet was similarly empty for about a year after launch. Now it looks kind of average.

[Howardlong]

My ARM platforms are largely M4 based with NXP LPC43xx and various TI TM4C12xx and CC3200 offerings, and I am amazed there are not more bugs in the NXP peripherals due to their sheer complexity. Their State Configurable Timer for example is tortuous to configure. The same applies to high speed ADC in the LPC4370. Of course, as with most vendors, they try to wrap up the peripherals in cotton wool with an API... which rather inconveniently doesn't cover all bases, so you frequently have to directly hack the peripheral registers anyway. Basically, always keep some of your own boilerplate code around for re-use or you'll be reinventing the wheel every time youmwant to,use a peripheral.

After moving from PIC32MZ about ten months ago, I found the NXP devices to be mature and refreshingly relatively bug free albeit with often outrageously complicated peripherals.

The compile/program/debug cycle is slow though on NXP. I use the LPC Link2 with LPCxpresso, I am not sure if this is just LPCxpresso or the debugger tool itself, or both, but TI's Code Composer Studio is faster in this respect. LPCxpresso seems to be dependant on a bunch of loosely coupled software components like Redlink Server which I am sure is part of the reason. The bolt on environment that NXP have added to Eclipse is a bit "how you doin'" in that if you inadvertently don't use their home made wizards, you open yourself up to a whole world of pain.

I also find the LPCxpresso debug environment to be flakey, although some of that is user error, if you forget to stop debugging a core before trying to debug again, it can be trying to recover yourself. You just train yourself not to push the wrong buttons monkey style. Such are the joys of supporting multi core simultaneous debugging I suppose. It also seems to take time to "make" even a simple blinky even when it's already up to date. However LPCxpresso does work, I can't ever remember it crashing on me (apart from trying to recover a debugger connection), but inevitably as soon as you move beyond blinky and start getting under the hood it is quite hard going. But that's the same for any MCU.

[andersm]

We are still in the relatively early days of ARM for most manufacturers I think. It will be another 5+ years before they really work all the silicon bugs out of their peripherals at least, and even then the relentless drive for lower power and lower cost will create new ones.

On the other hand, many manufacturers use the same peripherals across several of their product lines. Eg. ST's infamous I2C peripheral is found in the STM8 line, with the same problems (newer ST micros use a different peripheral).

[nctnico]

Look at the LPC11E67 for example. It's errata sheet is empty. The smaller ARM microcontroller from NXP usually have very few (annoying) bugs because they have been using the same peripherals for many chips for a long time.

This. Errata are not always "bad" if there is a known, usable work-around and they are just keeping the flaw in there to maintain software compatibility.

We are still in the relatively early days of ARM for most manufacturers I think. It will be another 5+ years before they really work all the silicon bugs out of their peripherals at least, and even then the relentless drive for lower power and lower cost will create new ones.

Are you kidding? NXP has been making ARM microcontrollers for over a decade now. Their peripherals are very mature.

@Jeroen3: I didn't run in any trouble with the LPC11U67 (the one with USB which does have a minor bug in the USB part).