Author Topic: Atmel versus NXP  (Read 11646 times)

0 Members and 1 Guest are viewing this topic.

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 702
  • Country: us
Atmel versus NXP
« on: April 19, 2015, 03:51:51 PM »
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.
« Last Edit: April 20, 2015, 04:06:10 AM by Sal Ammoniac »
Never trust a government that doesn't trust you.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 13876
  • Country: nl
    • NCT Developments
Re: Atmel versus NXP
« Reply #1 on: April 19, 2015, 08:36:47 PM »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 702
  • Country: us
Re: Atmel versus NXP
« Reply #2 on: April 20, 2015, 04:52:29 AM »
Can you elaborate on the problems you've had with Atmel ARM chips?
Never trust a government that doesn't trust you.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 13876
  • Country: nl
    • NCT Developments
Re: Atmel versus NXP
« Reply #3 on: April 20, 2015, 05:46:40 AM »
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.
« Last Edit: April 20, 2015, 09:31:15 AM by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 276
  • Country: us
Re: Atmel versus NXP
« Reply #4 on: April 22, 2015, 12:57:51 AM »
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.
 

Offline Scrts

  • Frequent Contributor
  • **
  • Posts: 521
  • Country: lt
Re: Atmel versus NXP
« Reply #5 on: April 22, 2015, 01:35:14 AM »
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.
 

Online janoc

  • Super Contributor
  • ***
  • Posts: 2159
  • Country: fr
Re: Atmel versus NXP
« Reply #6 on: April 22, 2015, 01:35:27 AM »
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.

 

Offline JohnnyBerg

  • Frequent Contributor
  • **
  • Posts: 429
  • Country: nl
Re: Atmel versus NXP
« Reply #7 on: April 22, 2015, 01:38:12 AM »
@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.
 

Offline Bassman59

  • Frequent Contributor
  • **
  • Posts: 642
  • Country: us
  • Yes, I do this for a living
Re: Atmel versus NXP
« Reply #8 on: April 22, 2015, 02:32:53 AM »
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.

Quote
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).
« Last Edit: April 23, 2015, 05:41:39 AM by Bassman59 »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 13876
  • Country: nl
    • NCT Developments
Re: Atmel versus NXP
« Reply #9 on: April 22, 2015, 02:39:09 AM »
@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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline 0xdeadbeef

  • Frequent Contributor
  • **
  • Posts: 990
  • Country: de
Re: Atmel versus NXP
« Reply #10 on: April 22, 2015, 03:11:30 AM »
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€.
Trying is the first step towards failure - Homer J. Simpson
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1527
  • Country: pl
  • Troll Cave Electronics!
Re: Atmel versus NXP
« Reply #11 on: April 22, 2015, 03:11:32 AM »
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)
I love the smell of FR4 in the morning!
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 2784
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Atmel versus NXP
« Reply #12 on: April 22, 2015, 03:41:29 AM »
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.
 

Online janoc

  • Super Contributor
  • ***
  • Posts: 2159
  • Country: fr
Re: Atmel versus NXP
« Reply #13 on: April 22, 2015, 06:50:26 AM »
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.





 

Online senso

  • Frequent Contributor
  • **
  • Posts: 815
  • Country: pt
    • My AVR tutorials
Re: Atmel versus NXP
« Reply #14 on: April 22, 2015, 09:11:57 AM »
Its a mater of taste, love AS6, hate anything Eclipse based, feels strange.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 13876
  • Country: nl
    • NCT Developments
Re: Atmel versus NXP
« Reply #15 on: April 22, 2015, 10:23:14 AM »
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.
« Last Edit: April 22, 2015, 10:25:06 AM by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 702
  • Country: us
Re: Atmel versus NXP
« Reply #16 on: April 24, 2015, 05:17:19 AM »
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.  :wtf:

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).
Never trust a government that doesn't trust you.
 

Offline 0xdeadbeef

  • Frequent Contributor
  • **
  • Posts: 990
  • Country: de
Re: Atmel versus NXP
« Reply #17 on: April 24, 2015, 05:51:36 AM »
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...
Trying is the first step towards failure - Homer J. Simpson
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 13876
  • Country: nl
    • NCT Developments
Re: Atmel versus NXP
« Reply #18 on: April 24, 2015, 06:58:34 AM »
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.  :wtf:

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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 2784
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Atmel versus NXP
« Reply #19 on: April 24, 2015, 03:27:25 PM »
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?
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1527
  • Country: pl
  • Troll Cave Electronics!
Re: Atmel versus NXP
« Reply #20 on: April 24, 2015, 04:05:09 PM »
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.
I love the smell of FR4 in the morning!
 

Offline andersm

  • Frequent Contributor
  • **
  • Posts: 889
  • Country: fi
Re: Atmel versus NXP
« Reply #21 on: April 24, 2015, 04:26:31 PM »
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.

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4118
  • Country: gb
Re: Atmel versus NXP
« Reply #22 on: April 24, 2015, 07:34:23 PM »
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.
 

Offline andersm

  • Frequent Contributor
  • **
  • Posts: 889
  • Country: fi
Re: Atmel versus NXP
« Reply #23 on: April 24, 2015, 08:13:22 PM »
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).

Online nctnico

  • Super Contributor
  • ***
  • Posts: 13876
  • Country: nl
    • NCT Developments
Re: Atmel versus NXP
« Reply #24 on: April 24, 2015, 08:25:53 PM »
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).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 2784
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Atmel versus NXP
« Reply #25 on: April 24, 2015, 08:38:44 PM »
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).
NXP'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.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4118
  • Country: gb
Re: Atmel versus NXP
« Reply #26 on: April 24, 2015, 08:52:45 PM »

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.

It 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.
 

Offline donotdespisethesnake

  • Frequent Contributor
  • **
  • Posts: 620
  • Country: gb
  • Embedded stuff
Re: Atmel versus NXP
« Reply #27 on: April 27, 2015, 07:29:07 PM »
Are you kidding? NXP has been making ARM microcontrollers for over a decade now. Their peripherals are very mature.

A decade isn't very long.

For 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.
Bob
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 13876
  • Country: nl
    • NCT Developments
Re: Atmel versus NXP
« Reply #28 on: April 28, 2015, 10:09:41 PM »
What I mean is, look at how far the ICs have come in that time frame. NXP's peripherals still have issues.
That remark is pretty generic so please provide an example of a issue NXP should have fixed.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Bassman59

  • Frequent Contributor
  • **
  • Posts: 642
  • Country: us
  • Yes, I do this for a living
Re: Atmel versus NXP
« Reply #29 on: April 29, 2015, 06:19:33 AM »
What I mean is, look at how far the ICs have come in that time frame. NXP's peripherals still have issues.
That remark is pretty generic so please provide an example of a issue NXP should have fixed.

For one, the EMIF issue on the LPC1800-series devices.
 

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 702
  • Country: us
Re: Atmel versus NXP
« Reply #30 on: June 04, 2015, 06:35:52 AM »
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,

It's LPxpresso. I use NXP parts and the LPC-Link2 with Rowley CrossWorks and CrossWorks compiles and programs the chip much faster than LPxpresso.
Never trust a government that doesn't trust you.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf