ST or NXP

[Howardlong]

I'd be wary of running code from RAM. Too much chance on memory corruption so you'd have to implement some kind of self-checking. Another fun fact: NXP's flash has error correction built in.

Why would you get memory corruption (other than shit code!)?

Just apply Murphy's law. It is not only bad code which can change memory but also Alpha radiation and other mayhem which is why servers usually have ECC memory. Google did quite a bit of research on this. IIRC MISRA rules also forbids to have anything in RAM which can affect program flow (like function pointers).

I would say it's down to a risk analysis. I had not been aware of how bad the problem really is in terrestrial applications: the only place I deal with this is in space applications where you plan and design around failure, both hard and soft, it's not a matter of "if", more a matter of "when".

The terrestrial applications I design frankly it wouldn't matter, the device is orders of magnitude more likely to fail for some other reason - I get three or four devices returned to me for repair after a lightning strike each year for example, now that's definitely a hard error!

[Bassman59]

Generally, the lpc18/43 family has been suffering a lot of bugs in its early days. From corrupted ADC when using CAN (or vice verse can't remember) to non functional bootloaders.
Please read the errata sheet for these parts.

The LPC18xx has a bug which makes using the external memory interface problematic. See here. I have not checked to see if that was fixed in a later rev of the silicon.

[Kjelt]

Most has been said, miss just two points that might be important for the OP:

- choice in esp. ROM sizes in the manufacturers portfolio. ST wins hands down on that. So if you choose a certain microcontroller, ST offers multiple packages with multiple ROM sizes so if you run out codespace you often can find a compatible package, often even the same micro, with larger ROM. Not always ofcourse there are limits but IMO NXP has far less choice, if you run out you can have a problem.
- price in quantities there are big differences between ST and NXP.

[Sal Ammoniac]

To me, one of the key decision factors is the quality of a vendor's documentation. I refuse to use parts from a vendor that has poorly written, confusing, and/or inaccurate data sheets and user's guides even if the part itself is technically excellent. It's just not worth my time to figure out how the part works by what amounts to trial and error.

I use a third-party toolset (Rowley Crossworks), so I'm not tied to any particular vendor's tools. This gives me the freedom to use a Cortex-M part from any vendor, whereas vendor-specific toolsets are often tied to that vendor's parts and won't work with anyone else's parts. I also avoid anything based on Eclipse, primarily because I just don't like it. We use both Keil and IAR at work, and I like both of them, but for my own hobby use at home I just can't justify the high cost of these tools.

With respect to NXP versus ST, I find NXP's documentation better than ST's, and ST's peripherals a little better (and simpler) than NXP's. So for me, it's a toss-up between NXP and ST, and I use both. Right now I'm primarily using ST, however, because NXP doesn't have any Cortex-M7 offerings yet.

I never use vendor-supplied libraries. I prefer to write my own, from scratch. I've found that vendor libraries are often buggy as hell. My code is usually simpler and more robust anyway (primarily due to my thirty years of experience writing embedded code).

[nctnico]

I also avoid anything based on Eclipse, primarily because I just don't like it.

I agree Eclipse looks odd at first and seems convoluted. I took me a while to grasp the concepts behind it because Eclipse has been build from a viewpoint where managing source code and dealing with large projects (with sub-projects) is important to increase productivity and maintainability. Many of the typical microcontroller IDEs are poorly equiped editors with a compile button and some debugging bolted on. These IDEs are totally useless where it comes to navigating through code and figuring out how a piece of software has been put together. In Eclipse this is a trivial task.

[Omicron]

I use a third-party toolset (Rowley Crossworks), so I'm not tied to any particular vendor's tools.

I use Crossworks as well. I have the same sentiment towards Eclipse. I've used it in the past to do Java development (non embedded) and it worked really great for that. But every time I've tried to use the C/C++ tools it has frustrated the hell out of me. Not because of lacking functionality, it has everything you could wish for, but more because of it's convoluted settings architecture and weird behaviour with the indexer getting out of sync causing the strangest errors (like it all compiles just fine in the evening but when you return next morning all of a sudden there's tons of compile errors because somehow it's forgotten where to find the headers). I'm on OSX, maybe CDT is better behaved on other platforms? Crossworks works a lot better for me. It also has a very responsive debugger. I always thought embedded debuggers where inherently slow until I tried Crossworks. That debugger just flies in comparison to GDB on Eclipse (like single stepping that can actually keep up). And it has good support for debugging NXPs multi core parts.

We use both Keil and IAR at work, and I like both of them, but for my own hobby use at home I just can't justify the high cost of these tools.

I'd be interested to learn what your experience is with IAR and Keil compared to Crossworks. Would you still go for Keil or IAR in a professional setting?

[richardman]

..Many of the typical microcontroller IDEs are poorly equiped editors with a compile button and some debugging bolted on. These IDEs are totally useless where it comes to navigating through code and figuring out how a piece of software has been put together. In Eclipse this is a trivial task.

I don't know where you get this idea from, most 3rd party IDEs are quite competitive with Eclipse. Ours is based on CodeBlocks, and Atmel Studio is based on Visual Studio and both of these have features as good as Eclipse. I bet IAR's workbench is quite decent as well.

[nctnico]

..Many of the typical microcontroller IDEs are poorly equiped editors with a compile button and some debugging bolted on. These IDEs are totally useless where it comes to navigating through code and figuring out how a piece of software has been put together. In Eclipse this is a trivial task.

I don't know where you get this idea from

Simple: from using those IDEs (ofcourse!) and the need to go through / understand / modify really large pieces of software I didn't write myself. Perhaps Visual Studio caught up in the last couple of years but the latest version I used (2008) was not an improvement and still needed lots of add-ons to add things which are standard in Eclipse. No doubt there are equal or better IDEs around compared to Eclipse nowadays but you'd better look for a product which has been designed to be an IDE and not a notepad+ cool looking compile button to get a blinky example going quickly.

You better look at IAR's product before assuming! It takes a lot of work to write a good IDE while the heavy power users will use their own editors, build and code management system. In other words: the actual use for a vendor specific IDE is very limited and is mostly there as beads & mirrors for managers who need to decide what to buy. Many of the vendor provided IDEs lack support for managing code, projects, version control  or are at least behind with the latest trends in that area.

[richardman]

...
You better look at IAR's product before assuming! It takes a lot of work to write a good IDE while the heavy power users will use their own editors, build and code management system. In other words: the actual use for a vendor specific IDE is very limited and is mostly there as beads & mirrors for managers who need to decide what to buy. Many of the vendor provided IDEs lack support for managing code, projects, version control  or are at least behind with the latest trends in that area.

Well, not my place to advocate for IAR  , in any case, this is one of the reasons we chose CodeBlocks in 2011 - it has the latest features and used by active community AND build on a lightweight framework (i.e. not Java)

[nctnico]

in any case, this is one of the reasons we chose CodeBlocks in 2011 - it has the latest features and used by active community AND build on a lightweight framework (i.e. not Java)

I'm not a fan of Java as well. Based on seeing lots of quirks in Java applications I had serious doubts Eclipse would be a good choice for me to invest time in. But it seems the creators of Eclipse have them under control although once in a while (about 5 times per year with almost daily use) a typical Java-ism rears its ugly head.

[Kjelt]

The only problem I have with eclipse is that it runs on Java which is continuously updated/attacked and makes it unstable and slow.

[zapta]

I don't know where you get this idea from, most 3rd party IDEs are quite competitive with Eclipse. Ours is based on CodeBlocks, and Atmel Studio is based on Visual Studio and both of these have features as good as Eclipse.

... and both don't run on Linux or Mac OSX.

[nctnico]

Java which is continuously updated/attacked and makes it unstable and slow.

Now that is twisted logic. Needing to update Java is total overkill for a user space application which runs from a standard (protected) user account. Besides that the code in Eclipse is signed as well and if you install an unsigned module into Eclipse it will show a big fat warning.

It is a totally different story if you have an internet (web)server where people use all kinds of Java applications. But that is a very special case.

[richardman]

I don't know where you get this idea from, most 3rd party IDEs are quite competitive with Eclipse. Ours is based on CodeBlocks, and Atmel Studio is based on Visual Studio and both of these have features as good as Eclipse.

... and both don't run on Linux or Mac OSX.

Plain CodeBlocks does run on Linux and Mac OSX. We did/do not have the resource to port our debugger to Linux/OSX... yet, but it's a doable job.

[Howardlong]

These days Java apps seem to be increasingly distributed with their own "integrated" JVM runtime.

Somewhat perversely one of the selling points of Java was a shared framework, but it also became one of its downfalls. As well as having to tailor various mutually incompatible environmental parameters for each application, there are so many backward compatibility issues between versions that to be able to rely on a single JVM for all the Java based apps from different vendors has become a practical impossibility. At one time we even resorted to Citrix and other virtualisation and sandboxing technolgies. So nowadays, many Java applications ship with their own preconfigured sandboxed JVM, warts and all.

[nctnico]

As far as I can see the shared framework philosophy has been a big fail in every case. Too much bloat and too much incompatibilities.

[Howardlong]

As far as I can see the shared framework philosophy has been a big fail in every case. Too much bloat and too much incompatibilities.

Agreed, .Net has very similar traits, some worse due to inherent distribution and integration with the OS, and the massive overhead of maintenance in the form of security updates for multiple versions in multiple locales. Sadly at the development level, too few folks are interested in understanding the cost of deployment foobars that this introduces until it is too late.

[richardman]

 It's just the modern versions of DLL Hell.

[Howardlong]

It's just the modern versions of DLL Hell.

Agreed, but worse! Ever tried dealing with an SxS DLL cock up?