ST or NXP

[Boomerang]

Hi to all,

I'm close to the start of a project that will require intensive floating point calculations (I will need Cortex-M4 core) and I cannot decide what to use... What you can suggest about pros and cons of STM32xxxx and LPCxxxx (not only the chips but the whole development experience with the IDE, libraries, drivers, RTOS choices and etc.)?

[Yansi]

We cannot choose you the best, you have to do it yourself, as we don't know any background you have or what will you need.

If the FPU is the only thing you need, then it seems it doesn't matter which one, just pick one and use it.

As for IDE,  both of these can be KEILed. I don't recommend macking around with that GCC stuff. Is inefficient, poor IDEs that will drive you nuts or even cannot offer most functionality professional IDEs do. - But this also depends on what you need to do.

You should be more specific in your goal, as both ST and NXP has extensive sets of products with CM4 cores, from those small  things up to some pretty beasts.

[Boomerang]

I will need 2 or 3 UARTs and SD-card interface. I'm worried about the usability of the libraries/drivers for these interfaces! Is it better to write my own code for the peripherals or to use some of the libraries? Also NXP has their own IDE; ST relay on 3-rd party IDEs  - it's a big mess with these so many options...

[zapta]

Least year I faced a similar choice between ST and NXP (for a M0) and ended up with NXP, big part because of the free tool chain. Lpcxpresso is a single package install IDE (eclipse based) that works out of the box.

[AndyC_772]

ST's Hardware Abstraction Layer has few friends here. IMHO it fails in that basic task; each library call requires a complete set of parameters which match up reasonably well with the actual underlying registers, and all it really does is sanity check them before writing them to the hardware.

For an IDE I use CrossWorks, which is a great deal less costly than Keil but has excellent device support. It scores well in the "just works" stakes, but the basic package gives you basic start-up code and C libraries, and that's about it. If you want driver code for things like storage devices, then it's extra.

[Jeroen3]

NXP does not offer their own ide. They acquired CodeRED which offered an IDE that is based on Eclipse, as is the competition.
Yansi made some dangerous statements by saying GCC is inefficient, shipped with poor IDE's and does not offer professional features.
While partly true for average or new users, it can outperform expensive toolkits when used by highly skilled people. Yet, you need to be highly skilled before the project to not waste any time on it.

When you actually buy keil, you get a lot of middleware with it. Instead of relying on the various open source alternatives which can also take a lot of time for first time users. Compare the cost of an proprietary ide with your hourly rate and see how many hours you can work for that. Not saying keil middleware is of the the utmost fine quality, I have no experience with it. Both vendors come with some version of segger Emwin as binary library.

The main difference between ST and NXP is the level of complexity of the peripherals. ST offers complex peripherals which can do all kind of tricks in hardware, while NXP keeps it more basic. But nonetheless very versatile if you can afford a few lines of code in an interrupt.
For FPU parts you can use either LPC4xxx or LPC5xxxx, or STM32F4 or STM32F7.
Unique points on the NXP side are the dual core or flashless parts, and state configurable timer.
Unique points on the ST side are the camera interface, and fancy DMA for display purposes.

[nctnico]

Yansi made some dangerous statements by saying GCC is inefficient, shipped with poor IDE's and does not offer professional features.
While partly true for average or new users, it can outperform expensive toolkits when used by highly skilled people. Yet, you need to be highly skilled before the project to not waste any time on it.

I agree. A vendor provided IDE like Keil's uVision can be a quick start to get a blinking led going quickly but for serious software development it falls short quickly. GCC + Eclipse are powerful tools for serious software engineering but they do take time to learn. For example: I had to use Freescale's own compiler for a certain microcontroller. There are many things which Freescale's linker can't do but GCC's ld (linker) has no problem with. For a led blinking program that is not a problem but if you want to map variables onto an internal eeprom a good linker is a huge aid to keep things simple and have some self-checking (warning for overlaps) mechanisms in place.

Regarding NXP and ST: I have looked at both in the past en did hands on evaluations. I quickly found the devices from NXP more mature (run from flash at full speed for example) and the pheripherals have no hidden surprises. Either way: make sure to check the errata sheets and look very close whether the function you want is actually supported in the hardware or doesn't interfere with other functions.

I'm also not a fan of vendor provided libraries. Often bloated and written by interns. For dealing with an SD card I can recommend the Fatfs library. A UART is simple enough to come with something yourself or re-use something from the past. I think my own UART handling routines (with circular buffers) are about 2 decades old by now.

[richardman]

For an alternative to the vendor libraries etc., you may take a look at our JumpStart API:
http://c4everyone.com/index.php/technologies/jumpstart-api

It gets you up and going with initial stuff fast and continues to help you writing code throughout the project. It works for the STM32F0xx series and we will release the STM32F4xx support today. Once we add the STM32F1xx and STM32F2xx, we will probably add support for the LPC series afterward.

[zapta]

For an alternative to the vendor libraries etc., you may take a look at our JumpStart API:
http://c4everyone.com/index.php/technologies/jumpstart-api

"mbed also relies on a cloud compiler, which engineers cannot rely on for production."

FYI, that's inaccurate. Mbed supports local toolchains. For example I export my mbed projects to lpcxpresso and do all development locally.  It's a single file project export.

[richardman]

"mbed also relies on a cloud compiler, which engineers cannot rely on for production."

FYI, that's inaccurate. Mbed supports local toolchains. For example I export my mbed projects to lpcxpresso and do all development locally.  It's a single file project export.

Thanks, the points are that by itself, no engineer will ship products using the mbed compiler, and that once you export mbed to a local project, you are now back to either using GCC+Eclipse, or $$$ for IAR/Keil, but I will modify the wordings so it's less ambiguous.

Actually, it's a bit surprising to me that NXP bought Code Red and nothing comes of it. I mean, what's the point?!

[Yansi]

Yansi made some dangerous statements by saying GCC is inefficient, shipped with poor IDE's and does not offer professional features.
While partly true for average or new users, it can outperform expensive toolkits when used by highly skilled people. Yet, you need to be highly skilled before the project to not waste any time on it.

I agree. A vendor provided IDE like Keil's uVision can be a quick start to get a blinking led going quickly but for serious software development it falls short quickly. GCC + Eclipse are powerful tools for serious software engineering but they do take time to learn. For example: I had to use Freescale's own compiler for a certain microcontroller. There are many things which Freescale's linker can't do but GCC's ld (linker) has no problem with. For a led blinking program that is not a problem but if you want to map variables onto an internal eeprom a good linker is a huge aid to keep things simple and have some self-checking (warning for overlaps) mechanisms in place.

Regarding NXP and ST: I have looked at both in the past en did hands on evaluations. I quickly found the devices from NXP more mature (run from flash at full speed for example) and the pheripherals have no hidden surprises. Either way: make sure to check the errata sheets and look very close whether the function you want is actually supported in the hardware or doesn't interfere with other functions.

Keil or IAR fails with what?  GCC  IS inefficient, in performance regards, IDE regards, all. I know quite a bunch of as you say "skilled" programmers who hate proprietary toolchaines so they use GCC and such freewares. They rarely use onchip debugging, as their crappy IDEs doesn't support that well, they know mostly nothing about  SWO/Trace capabilities (still debug  using UART and FT232 cable... sigh), have problems controlling the programmers (everything is a problem, like "connect under reset" on STLink or so)... now tell me what is efficient. I'd rather learn how to code stuff than spend time learning how to use the toolchain I use for coding.
And also you should explain, why most bigger design companies do use proprietary toolchains, rather than opensource stuff with ZERO support and warranty on it.
But thats just pure opinion, your's might differ. I am a big fan of proprietary toolchains, as they work better for me, every time. Nothing has convinced me enough yet to switch from them to opensource. (Maybe I am used to them as I work just in one of the big corporates, that prefers Keil/IAR)


And also, ST has free toolchain. It is called "System Workbench for STM32" (www.openstm32.org). But never have tried that. Is it worth a try? 

Regarding the second paragraph: What do you mean by "run from flash at full speed for example"? Never heard of flash with such low access times. Strongly doubt NXP has its own flash technology, thats so much better and faster than others. Maybe they only didn't tell you, that there are waitstates 

PS: Mbed is c*p for kids, not for serious production.

[richardman]

Indeed some companies have their own flash technology as a competitive advantage. Back in the ARM7 days, one differentiator between vendors' offerings was the flash access speed: some claim they fetch 128 bits at once, some claim other speed-up measures. With the STM32F401/411, when you run at 84 MHz, you have to program the flash to run at 5 wait states. It scales up when you run at 168 MHz. 

[nctnico]

@Yansi: I have used the IAR, Keil's, Analog Devices', Freescale, etc proprietary IDEs and they all suck big time compared to Eclipse. Ever wondered why so many vendors are switching to Eclipse? I have also used my fair share of on-target debugging tools as well but have discovered they are a huge waste of my time. Most are buggy/unstable as hell and besides that there is very little use to debug software running inside a micro. IRQs make it almost impossible to really halt somewhere (you are basically debugging an application with multiple parallel threads!) and some things you actually don't want to halt. At the other end of the spectrum is the higher level code which is much easier/efficient to debug / unit test on a PC. Now unlike any microcontroller compiler GCC is also available for x86 so moving code between a PC and a microcontroller is a piece of cake. Add the excellent debug capabilities of Eclipse CDT to that and you are all set.

Yes, I do know NXP's controllers can add wait states for flash accesses but the flash in the NXP devices have a pre-fetcher so the performance is still better than ST's flash.

[hans]

My experience is the complete opposite. I need to use "google" as my primary support tool for Keil as well, and chances are I have more search results for GNU tools than for Keil or IAR.
We used to work with IAR at work, but switched to Keil. I needed to compile (several firmware builds we want to try in the field) and download (released bootloader image) a few SREC images for a few test units. Couldn't find the "Download SREC" and "Compile to SREC" button in Keil. Was thoroughly disappointed.

I have setup my hobby toolchain now with Qt Creator + GCC/GDB + OpenOCD. It has full debugging support, I can write batch scripts for anything I need (like production programming of any file), and IMHO most importantly I wrote my QBS project file in such a way that I can seamlessly switch between x86 device and an ARM device. Once the hardware is fully abstracted or mocked it's pretty darn easy to test program logic & protocols on a desktop machine. And that with the click of 1 button, staying in the exact same IDE & file views, etc.


As for the OP's question: I agree that NXP products seem very mature and robust, IMHO more tailored towards that than the absolute lowest price or highest banner specs. ST seem more feature rich, but consider the front-page just as a brochure (good general tip for any datasheet anyway). Sometimes some combinations are not possible on the ST devices, like I was a bit disappointed in how DMA works on STM32F4 compared to the PIC's or AVR's (which is much simpler to setup). STM32Cube is a nice program however to lay out peripheral pinning on the bigger chips, where finding a path through 6 SPI's, 5 I2C's, 8 UARTS, SDRAM, LCD, Ethernet and 3 ADC's is quite dizzying.

I think both boards (LPCxpresso vs ST Link) have pretty similar debuggers, which only work for NXP/ST brands. Watch out for the older LPCxpresso boards though, they only work with CodeRed's IDE (which also has code size limits I believe).

[zapta]

Actually, it's a bit surprising to me that NXP bought Code Red and nothing comes of it. I mean, what's the point?!

Don't they have now control over lpcxcpresso that they provide for free under some restrictions?

Personally I find it to be very useful, an easy to install full featured IDE with seamless support for hardware debugger,  a toolchain that can be used from the IDE or command line (it generates standard make files) and runs on all three OSs.

[zapta]

As for IDE,  both of these can be KEILed. I don't recommend macking around with that GCC stuff. Is inefficient, poor IDEs that will drive you nuts or even cannot offer most functionality professional IDEs do. - But this also depends on what you need to do.

Are you referring to LPCXpresso?

Works great for me, no need to mack with anything, just download and install a single package.

[exmadscientist]

I've bought fully in to NXP's LPC line here, and I haven't really regretted it. I obviously haven't got the same level of experience with ST, so I can't say how green the grass is on that side of the fence, but here are some thoughts about the LPC ecosystem:

The good:

• LPCXpresso is a good free IDE. Eclipse has its own pros and cons, but everything does and LPCXpresso is, on balance, as good as anything you'll find.
• GCC versions are usually kept fairly up to date. In particular, recent LPCXpresso releases have direct interface support and access to GCC's link-time optimizations (LTO). If you haven't used it, LTO is amazing for most embedded work; it cuts the final sizes of some of my binaries in half!
• You can always go to a bog-standard GCC-based setup if you exceed the capacity of the free LPCXpresso version, rather than being forced to pay to upgrade.
• Their HAL/interface libraries, LPCOpen, are fairly comprehensive and mostly work. Mostly. There's surprisingly good commonality between the large (Cortex-M4) and small (M0) chips.
• Few severe chip errata. I've hit a couple (including a nasty 5V tolerance issue on USB pins that got "fixed" by clarifying the datasheet...), but for the most part all those complicated peripherals work right.
• Good selections of MCU variants to cover most needs, from M0 to triple-core M4F+2xM0.

The bad:

• Peripherals are often complicated and sometimes (very) poorly documented. My life got a lot easier when I figured out which ARM peripherals were licensed in certain chips and could just go direct to ARM's documentation for that IP core.
• Pin assignment sucks. But I think that's true of all complicated microcontrollers these days. (I have not been blessed enough to try one of the newer designs with a full I/O routing matrix... someday one of those parts will be the right chip!)
• Some LPCOpen interfaces are brain-damaged. Often it's less work to just roll your own than figure out how to use the crap in the library.
• No M7 core options (yet).

The ugly:

• LPCOpen's example code was written by what I can only assume were outsourced wage slaves. It's terrible in pretty much every respect.
• Trying to use the baked-in ROM drivers is a waste of time. Just write your own code -- that way you can actually debug it. The ROM drivers are buggy as hell, and source code is not provided.
• Good luck figuring out which of their USB stacks to use. Navigating the USB maze to figure out where to start and what is and isn't obsolete is actually harder than the work to get USB going on the damned things.
• Errata don't get fixed quickly. Yeah, I know masks are expensive and they're minor things. I still like seeing errata sheet entries get crossed off!

[Boomerang]

You say that the flash cannot be fast enough to run at full speed. Did you ever reached the point where you must copy a function or group of functions to the RAM in order to execute them at full speed guaranteed?

[nctnico]

The good:

• Their HAL/interface libraries, LPCOpen, are fairly comprehensive and mostly work. Mostly. There's surprisingly good commonality between the large (Cortex-M4) and small (M0) chips.

That is one thing I have always liked about NXP's ARM (ARM7 / Cortex) portfolio: they used the same peripherals for all their chips so existing code is easy to port and you can get a 'new' controller going quickly.[/list]

[richardman]

That is one thing I have always liked about NXP's ARM (ARM7 / Cortex) portfolio: they used the same peripherals for all their chips so existing code is easy to port and you can get a 'new' controller going quickly.

Very good to know, it will make our life easier when we add support for them :-) Did NXP ever release their dual-core LPC4350? I did some work for it as part of their push-out, but I think they re-churned the silicon.

[AndyC_772]

You say that the flash cannot be fast enough to run at full speed. Did you ever reached the point where you must copy a function or group of functions to the RAM in order to execute them at full speed guaranteed?

ST advertise something called "ART Accelerator", which as far as I can tell means it reads enough bits in parallel from the Flash to execute code at full speed without having to copy to RAM first.

[Boomerang]

I read about this ART accelerator and it's a combination of prefetch and cache. Does anyone knows how big is this cache?

[Boomerang]

After a short search I found that it's 256 entries each 128 bits = 4 KB

So if my part of the program that needs to run fast is < 4KB - I don't have to do anything special. Otherwise - copy in the RAM and run from there.

[Boomerang]

Just for comparison - NXP also has "flash accelerator" that reads 256 bits at once.

[Jeroen3]

Flash is wider than 32 bit. Thus one fetch catches multiple instructions since instructions are 16 bit thumb.
Both vendors have accelerators for internal flash, to prefetch for sequential code and cache for loops. But you'll have cache miss when you go to interrupts (put these in ram) or far away functions.
The flash accelerators do not work for external memories if I recall correctly..

Yes, they did release the lpc4350, after several silicon revisions. The SGPIO peripheral is a one of a kind not seen in the competitors yet. Yet it's so simple.

Read the errata sheet before using any of the chips in this class.