Atmel ARM Cortex (or NXP? or STM32?)

[msr]

Hi,

Have anyone tried the Atmel ARM Cortex-based microcontrollers?
Im looking for a microcontroller with good performance and SAM4L seemed very interesting (AES and low power are nice additional features). I also need a bootloader and this series have SAM-BA pre-programmed but I would prefer something compatible with STK500v2 or more open-source (ie. some comand-line tool, cross platform and that can be freely distributable).

What's your opinion?

[nctnico]

NXP's ARM controllers have a bootloader which allow programming over the serial port. There is also a Linux tool to program them.

[dannyf]

There are Atmel ARM powered arduinos out there so I am sure others have done it, if not that particular chip or family of chips.

I also need a bootloader

Many of them do, like STM32's for example. All you need is a serial program (HyperTerminal for example) and you are done.

[Psi]

STM32 seem to work well in opensource EmBlocks IDE out of the box, debugging works too.

Ive only used the one STM32F0 dev board but it was a simple matter of creating a project, selecting the STM chip and start coding

F0 has more power/features than a high spec $12 ATMega but with a $1.20 pricetag.
(except no built in eeprom)

[zapta]

STM32 seem to work well in opensource EmBlocks IDE out of the box, debugging works too.

I couldn't find on EmBlocks site what OSs it runs on (ideally Mac, Linux and Windows).

[SirNick]

IMO, Atmel's data sheets are top notch, but the hardware lags behind NXP's equivalents.  NXP seems to have a better feature set, and at least from what I've seen, at a lower cost too.

OTOH, NXP's data sheets are not that great.  So it might be good to learn on a SAM, and continue using them were cost and peripheral selection are not prime concerns, then switch over to NXP when you really want to drive the thing hard, or to scale up for production.

[dannyf]

They both do a decent job there. NXP assumes that you have prior knowledge about the (kind of) devices so their datasheet may seem skimpy / cryptic to a newbie.

[nctnico]

When looking at NXP devices make sure to read the user manual as well. The datasheet only contains a short description about the functionality and contains the electrical specifications. If you want to know what a device does and how it works you really need the user manual. Most of the user manuals for NXP's cortex devices also contain an extensive section about the ARM Cortex core.

I know needing two documents for a chip takes some getting used to but it makes sense to have the electrical specification seperated from the 'software' specification.

[msr]

Ok, so I changed my mind and now Im trying to choose between NXP and STM32 

In a first application I'll be using it to interface with a W5200 (ethernet chip from Wiznet) so one of the features Im favoring is SPI maximum speed. CPU max frequency is also important of couse so transfered data can be processed "fast". Other important parameters: low pin count (~48 pins), flash size (minimum 64KB), price and availability.
So taking these parameters into consideration I sumbled upon these parts:
- LPC1115 (64KB, 50MHz, SPI @25Mbit/s)
- STM32F051K8T6 (64KB, 48MHz, SPI @18Mbits/s)

Regarding the bootloaders. I know every ARM microcontroller has a preprogramed serial bootloader but as far as I know not all of them have cross-platform, open-source loader applications. I developed myself a loader for EFM32 some time ago and since it uses XMODEM protocol it was fairly easy to implement. LPC and STM32 use their own protocols which I suppose are well documented, but unfortunately I don't have the time to develop such application so I have to rely on what's already done and freely availabe. Thus, I found FlashMagic for NXP (closed, windows only) and stm32flash for STM32 (https://code.google.com/p/stm32flash/, not sure if it supports STM32F0x series).

Another very important thing: the toolchain! NXP has the LPCXpresso "platform" based on GCC, everything seems to be included and to work "out of the box". For STM32F Im not sure about the GCC support (linker files, startup code?).

Well... Can you help me deciding what mcu should I pick once again ?

[dannyf]

STM32 has more features.

LPC has less bugs.

[ve7xen]

If you need Ethernet, why not choose an ARM with an Ethernet peripheral? Like STM32F107 (64/128/256KB, 72MHz, 100mbit Ethernet MAC, SPI @ 18Mbps, LQFP64).

stm32flash worked for me on a STM32F105 project, so should work with the rest of the series, and I believe the protocol is consistent across the F0 and F2/3/4 products as well, so should work.

Toolchain was a big challenge for me. Development files (linker scripts and startup files etc.) are included for two different GCC-based commercial products, as well as a proprietary one, but it still took me some steep learning curve to get it running. Now every time I go to work with these I have to wonder if my toolchain still works or if I'll have to go through that again... I think this is pretty much the case with any of them though if you're not going to use the provided tooling directly.

+1 on bugs, at least in the provided peripheral library for STM32.

[SirNick]

I agree with ve7xen.  Unless you have a legacy codebase using the WizNet, drop that puppy and go with onboard Ethernet.  Example NXP parts: LPC1768 (Cortex M3) or LPC4078 (Cortex M4).  BYO Ethernet PHY though.  I'm using the Micrel KSZ8041RNLTR (10/100 RMII-based) for a project in the works now.

[andersm]

I know every ARM microcontroller has a preprogramed serial bootloader

This is not true at all. Most modern mainstream parts probably have one, but you definitely need to check the documentation to make sure.

[theatrus]

Certain LPC parts actually have a USB Mass Storage firmware update mode. It shows up as a tiny 32KiB FAT16 flash drive, and you can delete and write a new firmware image via Windows explorer.

Since it's kinda a hack, it's dodgy in Linux and OS X, but there is the "mtools" package which you can use to workaround the differences.

As for tool chains, it's somewhat of a pain since not everyone even ships linker files for all of the big three (plain GCC, IAR, Keil). IAR and Keil both have free 32KiB versions available.

[Psi]

Pretty sure EmBlocks also works with LPC, PIC, AVR, but ive not tried that

I really didn't like the toolchain/IDE that came bundled with the LPC dev board i got, cant remember what its called.

STM32 seem to work well in opensource EmBlocks IDE out of the box, debugging works too.

I couldn't find on EmBlocks site what OSs it runs on (ideally Mac, Linux and Windows).

I use it in windows, no idea if it can be run in linux. It's open source though, so it wouldn't surprise me at all.

[ctz]

Another very important thing: the toolchain! NXP has the LPCXpresso "platform" based on GCC, everything seems to be included and to work "out of the box". For STM32F Im not sure about the GCC support (linker files, startup code?).

I've had good results with plain arm-gcc and http://libopencm3.org/ with STM32F4xx. libopencm3 gives you a measure of portability over lots of Cortex parts (though obviously lots of peripherals vary), a lot like CMSIS except with a sensible open source license.

[nctnico]

STM32 has more features.

LPC has less bugs.

Then they must have added more features to the STM32 recently. About 7 years ago I evaluated several ARM controllers. The offering from ST and Luminary where not a good fit. I tried to make something with the STR710 (ARM7TDMI core) but that controller is a complete joke. It is by far the worst microcontroller I have ever had to deal with. I also didn't like the flash speed was limited to much less than the CPU speed. What is the point of having a fast CPU? A couple of years later I looked at ST's ARMs again but still wasn't impressed. IMHO ST is trying to create cheap parts but they cut too many corners so the end result is just an incoherent kludge.

Back then I choose for NXP which turned out to be a good choice for me. Many of the peripherals found on the ARM7TDMI devices migrated to the ARM Cortex devices without much changes (mostly extra features) so I can reuse 99% of the hardware drivers I wrote.

[theatrus]

If we wanted to talk about bugs we shouldn't forget the Luminary LM3 line (which TI bought). The fact that all references to these parts are gone from TIs website (unless you search by part number) should be a clue.

(Before that many parts were in eternal preview status for years. I wonder if my dev boards will become collectibles)

[msr]

Thanks everyone for sharing your ideas and experience.

I've had good results with plain arm-gcc and http://libopencm3.org/ with STM32F4xx. libopencm3 gives you a measure of portability over lots of Cortex parts (though obviously lots of peripherals vary), a lot like CMSIS except with a sensible open source license.

I recognize the effort of libopencm3 but unfortunately I can't trust it for the time being.

The API of the library is NOT yet considered stable! Please do
           not rely on it, yet! Changes to function names, macro names etc.
           can happen at any time without prior notice!

However I was not aware of the linker generator for ARM GCC. That seems awesome, i'll give it a try!

If you need Ethernet, why not choose an ARM with an Ethernet peripheral? Like STM32F107 (64/128/256KB, 72MHz, 100mbit Ethernet MAC, SPI @ 18Mbps, LQFP64).

That was my first thought but its a matter of (lack of free) time. I want to build a "minimum viable prototype" and the time is running fast so the idea of having all the TCP/IP stuff done, by using the W5200, was appealing. I "just" want to send some TCP/UDP packets. In case I didn't find an appropriate ARM mcu to work with I was planning to use an EFM32LG for which I already have some code base.

But now Im considering it again.
Im planning to buy this board from Olimex: https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware
The challenge: get a working toolchain for STM32F with arm gcc (not IAR), port the lwIP (olimex only provides some a very simple uIP example, but ST has an appnote for lwIP running on STM32F2x7xx), hope the ST Ethernet MAC library isn't buggy

I'll give it a try and let you know about how the things are going. If it takes too much time and hair and neurons, I'll get back to W5200 as a not-optimal but working solution.

[andersm]

I've had good results with plain arm-gcc and http://libopencm3.org/ with STM32F4xx. libopencm3 gives you a measure of portability over lots of Cortex parts (though obviously lots of peripherals vary), a lot like CMSIS except with a sensible open source license.

The LGPL license is troublesome for embedded software. Of course, if you're only going to release open-source software there's no problems.

[nctnico]

Buzzz. Wrong. LGPL may be used in closed source applications.

[gmb42]

Thanks everyone for sharing your ideas and experience.

However I was not aware of the linker generator for ARM GCC. That seems awesome, i'll give it a try!

What link script generator was that, I don't see any reference to one in the previous posts, can you share a link?

[msr]

What link script generator was that, I don't see any reference to one in the previous posts, can you share a link?

Check the libopemcm3 github page: https://github.com/libopencm3/libopencm3/tree/master/ld

[vvanders]

Buzzz. Wrong. LGPL may be used in closed source applications.

Unless you are using a system that allows dynamic linking you're still required to distribute something that can link with the lgpl code.

See http://stackoverflow.com/questions/10130143/gpl-lgpl-and-static-linking

[andersm]

Buzzz. Wrong. LGPL may be used in closed source applications.

You can, as long as you satisfy the license requirements. For a microcontroller-based application that means either distributing the source code or linkable objects. Even if using dynamic linking, the anti-Tivoizaition clause of the LGPLv3 means the system must still work if the LGPL-licensed components are replaced.