Atmel versus NXP - Page 1
Forum section: electronics / general

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 19, 2015, 05:51:51 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: April 19, 2015, 10:36:47 am
content: 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 19, 2015, 06:52:29 pm
content: Can you elaborate on the problems you've had with Atmel ARM chips?

author: nctnico
author_rank: Super Contributor
timestamp: April 19, 2015, 07:46:40 pm
content: 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.

author: mark03
author_rank: Frequent Contributor
timestamp: April 21, 2015, 02:57:51 pm
content: 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.

author: Scrts
author_rank: Frequent Contributor
timestamp: April 21, 2015, 03:35:14 pm
content: 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.

author: janoc
author_rank: Super Contributor
timestamp: April 21, 2015, 03:35:27 pm
content: Quote from: nctnico on April 19, 2015, 07:46:40 pmUh, 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.

author: JohnnyBerg
author_rank: Frequent Contributor
timestamp: April 21, 2015, 03:38:12 pm
content: @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.

author: Bassman59
author_rank: Super Contributor
timestamp: April 21, 2015, 04:32:53 pm
content: Quote from: mark03 on April 21, 2015, 02:57:51 pmI 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-selectswhich 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.QuoteSiLabs 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).

author: nctnico
author_rank: Super Contributor
timestamp: April 21, 2015, 04:39:09 pm
content: Quote from: JohnnyBerg on April 21, 2015, 03:38:12 pmI 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.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: April 21, 2015, 05:11:30 pm
content: 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€.

author: poorchava
author_rank: Super Contributor
timestamp: April 21, 2015, 05:11:32 pm
content: 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)

author: Jeroen3
author_rank: Super Contributor
timestamp: April 21, 2015, 05:41:29 pm
content: Quote from: mark03 on April 21, 2015, 02:57:51 pmThat 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.

author: janoc
author_rank: Super Contributor
timestamp: April 21, 2015, 08:50:26 pm
content: Quote from: poorchava on April 21, 2015, 05:11:32 pmWell, 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.

author: senso
author_rank: Frequent Contributor
timestamp: April 21, 2015, 11:11:57 pm
content: Its a mater of taste, love AS6, hate anything Eclipse based, feels strange.

author: nctnico
author_rank: Super Contributor
timestamp: April 22, 2015, 12:23:14 am
content: 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 23, 2015, 07:17:19 pm
content: 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).

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: April 23, 2015, 07:51:36 pm
content: 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-overviewHaven't tried it yet, but having a data watch trace in a free IDE with a 18€ debug probe is pretty nice...

author: nctnico
author_rank: Super Contributor
timestamp: April 23, 2015, 08:58:34 pm
content: Quote from: Sal Ammoniac on April 23, 2015, 07:17:19 pmLook 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: April 24, 2015, 05:27:25 am
content: It's literally emptyhttp://www.nxp.com/documents/errata_sheet/ES_LPC11E6X.pdfBut that only means they've not found them yet, right?

author: poorchava
author_rank: Super Contributor
timestamp: April 24, 2015, 06:05:09 am
content: 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.

author: andersm
author_rank: Super Contributor
timestamp: April 24, 2015, 06:26:31 am
content: Quote from: Jeroen3 on April 24, 2015, 05:27:25 amSome 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.

author: Howardlong
author_rank: Super Contributor
timestamp: April 24, 2015, 09:34:23 am
content: 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.

author: andersm
author_rank: Super Contributor
timestamp: April 24, 2015, 10:13:22 am
content: Quote from: mojo-chan on April 24, 2015, 08:43:26 amOn 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).

author: nctnico
author_rank: Super Contributor
timestamp: April 24, 2015, 10:25:53 am
content: Quote from: mojo-chan on April 24, 2015, 08:43:26 amAre 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).

author: Jeroen3
author_rank: Super Contributor
timestamp: April 24, 2015, 10:38:44 am
content: Quote from: nctnico on April 24, 2015, 10:25:53 amNXP's peripherals are usually reasonable simplistic. Except for the few specialty ones, like sgpio or sct. I did encounter an issue in the SPI of the LPC17 that would always inserts a dead cycle when done writing. But I was attempting to abuse spi for WS2811 led's.I also played around with one of the first generations LPC43's, those can be considered buggy. But still revolutionary with high clocks and two cores, sgpio, quad spi booting from rom (if it works). They should have fixed most bugs by now.

author: Howardlong
author_rank: Super Contributor
timestamp: April 24, 2015, 10:52:45 am
content: Quote from: Jeroen3 on April 24, 2015, 10:38:44 amIt appears they have, although I wouldn't want to risk using a quad spi flash other than those recommended. That is one of the benefits of using a device that has been out for a year or so. It's human nature to go for the latest thing in town, but it's also a risky strategy, as I found to my cost with Microchip's PIC32MZ.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: April 27, 2015, 09:29:07 am
content: Quote from: mojo-chan on April 27, 2015, 09:13:48 amFor the purposes of argument, people will adjust the definitions of words to whatever is convenient, even if they end up spouting meaningless comments.The first micro was created 44 years ago, so 10 years is about 23% of the that. I would say that is a significant proportion.

author: nctnico
author_rank: Super Contributor
timestamp: April 28, 2015, 12:09:41 pm
content: Quote from: mojo-chan on April 28, 2015, 08:59:44 amThat remark is pretty generic so please provide an example of a issue NXP should have fixed.

author: Bassman59
author_rank: Super Contributor
timestamp: April 28, 2015, 08:19:33 pm
content: Quote from: nctnico on April 28, 2015, 12:09:41 pmFor one, theEMIF issue on the LPC1800-series devices.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: June 03, 2015, 08:35:52 pm
content: Quote from: Howardlong on April 24, 2015, 09:34:23 amIt's LPxpresso. I use NXP parts and the LPC-Link2 with Rowley CrossWorks and CrossWorks compiles and programs the chipmuchfaster than LPxpresso.