Atmel SAM ARM versus STM32 or NXP

[Sal Ammoniac]

Anyone here have any experience with the Atmel ARM parts in the Cortex-M4 or M7 series? How do they compare to the STM32F4/F7 and NXP LPC43xx parts? I'm particularly interested in people's opinions of the peripherals in the Atmel parts and the development environment (how does Atmel Studio compare with other ARM development tools).

[nctnico]

I'd check the errata first and read Atmel's datasheets very carefully. I'm not using Atmel's parts due to getting burned in the past; it is just too much hassle to cut through the BS in their datasheets.

[MT]

I compared the 300Mhz (dont even remember the number)because it was i recall cheap with similar ST device 180Mhz F446
i think and Atmel device was a lot less in peripheral number and complexity it seams the 300Mhz is what they want to promote ,
nothing wrong in that btw.   And i'm not to comfortable with Atmel datasheet layout after been mentally modified by reading
ST datashiit's!

Atmel Studio V6 suck wet hairy donkey balls compared to EmBlocks.

[Sal Ammoniac]

Atmel Studio V6 suck wet hairy donkey balls compared to EmBlocks.

Wow, that's a pretty scathing condemnation of Atmel Studio..

I've not looked at EmBlocks before--is it the same as EmBitz? Why would you recommend it over some of the other ARM development tools? Besides it being free, does it have anything else going for it?

[MT]

Yes, i read on the web that studio V6 is like that, but V7 is less hairy and wet!
EmBitz, well, yes it's neat, small and tidy, bare metal with STD lib if you like. Better then others? i dunno, haven't tried the other terrabyte sized monsters recently!

[Sal Ammoniac]

I took a quick look at EmBitz and, as you say, it's rather basic. Most of the useful debug windows (registers, call stack etc.) are floating windows--haven't seen that in a Windows IDE in at least a decade.

I also forked up some dough and bought the embedded version of VisualGDB and tried it with Visual Studio 2015 Community Edition. It integrates reasonably well with VS, but its project creation wizard seems to want to create complex projects pulling in all sorts of HAL or FreeRTOS libraries. There seems to be no option to create a bare bones project with no library references (or perhaps just a reference to something really lightweight like Newlib-nano). The standard startup code calls a library initialization routine that calls malloc(), for god's sake, which really plays havoc with the way I have memory mapping set up on my applications.

It seems like the only way to get rid of this excess garbage is to manually delete files and manually edit startup files.

I guess most of these cheaper tools seem geared to complete newbies who need their hand held at every step, hence the pulling in of all of this library code, HALs, and other junk. 12KB just to blink a bloody LED? Ridiculous!

[dannyf]

Atmel's ARMs aren't that widely used.

ST's offerings are very diverse, too diverse some may say, and of low prices.

NXP offers quality chips that are feature-limited for peripherals.

[Sal Ammoniac]

NXP offers quality chips that are feature-limited for peripherals.

In what way?

[peter.mitchell]

atmels peripherals suck, sts peripherals are good but interfacing with them sucks, nxp is

[nctnico]

Regarding ST's peripherals I came to the same conclusion last time I looked. I'm a heavy NXP ARM microcontroller user and the fact that NXP has kept many of the peripherals (almost) identical between old (ARM7TDMI) and newer Cortex Mx devices has allowed me to re-use existing code many times and not waste time on learning a different peripheral with the same function. So far I have not run into serious limitations.

[Sal Ammoniac]

In my experience, the STM32 peripherals are less quirky than the NXP peripherals.

IMO, the NXP CAN peripheral is a convoluted mess, while the STM32F version is much simpler. It seems like STM32 peripherals are getting better too. A case in point is the I2C peripheral. It was horrid on the STM32F3 parts, okay on the STM32F4s, and very nice on the STM32F7.

[theatrus]

Now that NXP owns Freescale, whats the consensus on the Freescale peripheral sets? I've had mixed luck with various quirky NXP peripherals, and burned by Atmel bugs.

[mark03]

The Freescale M0 I used for a project last summer had a number of peripherals in common with Freescale's 8- and 16-bit MCUs.  They clearly hadn't changed in a long time, which is great if code reuse is a priority.  Otherwise, I'd rate them average, with average-to-above-average documentation.  Personally I'm more interested in newer and more capable peripherals, so, STMicro.  (Honorable mention to NXP, with even more advanced peripherals but crap documentation, a pity.  I hope the merger keeps both the people behind cool stuff like SGPIO, and the people who know how to write.  That could be a good combination.)

[dannyf]

whats the consensus on the Freescale peripheral sets?

Freescale is a far better player than NXP is in the mcu space - particularly automotive mcus (mixed signal + software support). I would expect that the Freescale guys will lead the combined operations and over the long term you will see a migration to Freescale peripherals -> aka if you use NXP parts now, think hard about investing further into software for those parts.

[nctnico]

IMHO it is way too soon to say. It will depend on which devices have the largest customer base and legacy support requirements. Getting rid of the old peripherals means customers have reason to look at competitors. As I wrote before: one of the very strong points of NXP is the identical set of peripherals across the entire ranges of devices.

[richardman]

I am not aware of anyone being able to "pry" Atmel's library code away from their ASF environment. I presume Keil/IAR basically roll their own. But from a 3rd party vendor's (e.g. ours) POV, it is a not very friendly. Of course this also means harder for GCC/etc. users as well. For an analogy, ST's StdPeriphLib, regardless of its quality, can be easily compiled by different compilers and things just work, whereas you can't extract the peripheral driver code from ASF and use it with our or GCC compilers.

Personally we like ST, primarily because the pinouts are very similar and the prices are very competitive: we will be releasing lines of products based on the ST chips, and we will be offering them with choices of ST M0, or M4 devices. The peripherals are not the same, but we hide those things with our JumpStart API.

The NXP line has always looked very interesting, but actually with the merger, we need to see how the availability holds up: our products will be used by customers that may have 10-15 years of production lifetime, and the long term availability is important. Freescale really understood that, but we will see what the new company will be like.

[theatrus]

I am not aware of anyone being able to "pry" Atmel's library code away from their ASF environment. I presume Keil/IAR basically roll their own. But from a 3rd party vendor's (e.g. ours) POV, it is a not very friendly. Of course this also means harder for GCC/etc. users as well. For an analogy, ST's StdPeriphLib, regardless of its quality, can be easily compiled by different compilers and things just work, whereas you can't extract the peripheral driver code from ASF and use it with our or GCC compilers.

Personally we like ST, primarily because the pinouts are very similar and the prices are very competitive: we will be releasing lines of products based on the ST chips, and we will be offering them with choices of ST M0, or M4 devices. The peripherals are not the same, but we hide those things with our JumpStart API.

The NXP line has always looked very interesting, but actually with the merger, we need to see how the availability holds up: our products will be used by customers that may have 10-15 years of production lifetime, and the long term availability is important. Freescale really understood that, but we will see what the new company will be like.

ASF is ... overengineered. But its built around the GNU tools and Makefiles work fine for it.

I've personally liked SDK sets from: Nordic (not overly layered, and works with gcc / IAR / Keil equally), EnergyMicro (now SiLabs, was my gold  standard about 4 years ago for clean and easy to use), and the newer Freescale Kinetis SDK (its use of CMake is a bit odd but it works)

[westfw]

you can't extract the peripheral driver code from ASF and use it with our or GCC compilers.

There shouldn't be a hugh technical problem; when you add ASF modules to an Atmel Studio project, it pulls actual source code into the project.  I'm not sure what the licensing issues would be, or how difficult it is to extract the (probably differing versions for each chip family) source code from downloads rather than having AS do it.

[eck]

... EnergyMicro (now SiLabs, was my gold  standard about 4 years ago for clean and easy to use)...

Hear hear. The EM32 SDK just works. Plus the application notes and code examples complement the SDK very nicely. My theory is that most vendor SDKs are bloated because they have too many people working on them. Energy Micro didn't seem to have the opportunity to create bloat because they were pretty small. Hope that continues.