For me, the available software and tools are the primary key decision factor why I select a particular silicon vendor. Without good software and tools, a microcontroller only ‘sand in plastic case’, even if it is the best microcontroller in the world. I do have several probably excellent microcontroller boards, and they are only getting touched by more durst over the months and years.
Undusted LPC824 Board
Some of these ‘dusted’ boards I gave away, some I have recycled, some I have given away (but they usually come back, see the article about the FRDM-KL26Z).
But sometimes things can change, and suddenly tools are available for the ‘dusted’ parts. We have occasionally used NXP LPC parts in our university projects.I’m a big fan of open software and tools, and Eclipse with GNU tools are simply the best framework for me. And my students appreciate if they have the freedom of host operating systems (Mac, Linux, Windows) and that tools are free and can be extended with extra plugins.
There has been the LPCXpresso IDE, but because it has not supported P&E and Segger probes (which we are mostly using here), the LPC parts have been used in niche areas. Yes, there is the Linkserver/RedLink/LPC-Link2 debug connection in LPCXpresso, and on many boards there is a way to use Segger debug firmware, but required extra steps, extra software installation and was not up to par with P&E and Segger solutions which both support the educational market very well). And both P&E and Segger always were very generously donating hardware and software. Yes, both P&E and Segger are commercial (and not open source) debug connections, but having a solid, ‘just working’ debug probe for a broad range of microcontroller is definitely a plus and a time saver, as I want to teach embedded system programming and not about getting the debug probe to work.
Now with the availability of MCUXpresso IDE (see “MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers“) which covers both LPC *and* Kinetis devices, things have suddenly changed: several students came to me this week asking telling me that they digged our their dusted LPC boards and finally can use the same tools as for their Freedom boards they love so much. Plus with the LPC-Link2 with CMSIS-DAP I have a good open source debug connection available in my arsenal. I hope silicon vendors realize how big this could be, and how important the right software and tools are?
And obviously I’m not alone with this: check out the article of David Karibe from the University of Nairobi:
http://karibe.co/2017/03/dynamics-of-embedded-systems-development-for-arm-based-microcontrollers/
David touches on the importance of Processor Expert in his blog post: I’m still working on an article about how to get this into MCUXpresso IDE :-).
Happy Influencing 🙂
MCU on Eclipse 
In our company, 5V I/O is critical; next is availability and price. The dev environment then is hopefully good enough. We’ve been very pleased with CodeWarrior for the last 10+ years on HCS12X, less happy with the price increases after NXP swallowed Freescale. So far, KDS has been ok but took more effort to get to a useful point, and is less stable through a days work. It looks like NXP have no update plans (for KE06Z), too.
Which reminds me that support is important too – but choosing Freescale (Motorola actually) and then watching a takeover that has negative effects on support, is disappointing!
LikeLike
Good point about support, that’s indeed important. CodeWarrior has been very stable for me as well, and I did not face any bigger issues with KDS myself (except the one described in https://mcuoneclipse.com/2014/10/11/failed-to-debug-with-gdb-breakpoints-or-expressions-on-non-existing-locations/). Maybe I was lucky that I moved off S08 and S12X early enough to the ARM world: the competition on the ARM side is much higher, so prices in my view are better. But my projects are not high volume: the development costs for the software are by far the biggest price part.
LikeLike
Tools are far and above the most important thing, yes. Particularly in these days of rapindly changing silicon. Who has the time to read let alone grok a thousand page user manual. If the tools can’t gloss over the easy stuff, they aren’t usable IMHO. Thus PE is a make or break thing in NXP land.
That said, if the project isn’t real sensative to part cost, Cypress PSoC parts will save you tons of time due to much fewer board layout. You can also do some fancy things inside them since they are sort of gate array parts. There are limitations to be sure but the tool set for it, while based on Visual Studio, is nothing short of greatness. Besides, I love to play at the boundary of silicon and firmware where it’s a little ambiguous if it’s hardware or software.
LikeLike
Hi Randy,
yes, the ever changing silicon is a challenge. On the automotive side, the AUTOSAR (https://www.autosar.org/) has enforced an approach to have a kind of BIOS established in software to allow better portability and uniform abstaction layer across different silicon vendors. Here the pressure came from the big OEM’s which then forced the silicon vendors to deliver AUTOSAR compliant devices. An interesting approach.
The Cypress PSoC is indeed a very cool device, and and as you say, the additional gates many times can reduce the amount of extra glue logic or components on the board. It is like a microcontroller with extra programmable gates and logic. I have found the PSoC Creator very easy to use, and in some areas it is like ‘Processor Expert for creating software and hardware’. And it is exactly at the sweet spot between hardware and software, enabling a good co-design approach.
LikeLiked by 1 person
It would be great if you can do a little post about PSoCs. I worked with PICs at school, but PSoC was my first ARM microcontroller to work with, i’m very used to them, even when all my projects are hobbyist level :).
LikeLike
For the AUTOSAR, this sounds a little like the Arduino bootloader, which does make sense. Other than mbed (which is not completely cross-platform compatible), is there any other viable way to make using projects on different components viable? I guess it comes down to things that the different vendors have included in their designs that are not compatible with others. You also have the different features from m0 to m4, etc.
My experience has been to pick a line that is cost/feature optimized with good documentation and tools available and good availability for production. With the Kinetis lines, they kept the pinout close enough that porting from one to another isn’t too bad.
LikeLike
On ARM Cortex (M0(+), M3, M4, …) the core is mostly the same among vendors, but the peripherals are completely different. One would expect that a vendor would have one UART, SPI, I2C, etc implentation, but for example the NXP KE and K/L devices are completely different here again which makes it nearly impossible to port software between them (or at least very hard). Yes, mbed is currently one of the best platforms/libraries to run on multiple vendors. But if your device is not supported by mbed, you are deep in the water too. Plus the lack of good/real development tools puts it out of any professional work. Mbed (like Arduino) works well if things are exactly the way you need it, otherwise (especially if it comes to debugging and solving problems), imho it is pretty useless.
What has been the best to me for cross platform development was Prcoessor Expert: because of its components and its object oriented inheritance, it was easily possible to move applications from proprietary 8bit to 16bit to 32bit microcontrollers, regarless of the pinout, package or core used. I guess if someone would buy-out Processor Expert, that could be a good business case to provide a uniform cross platform development model?
LikeLiked by 1 person
Other than the KE line, what other options are there for 5V ARM parts? I’m doing a design right now with a KE02, but I’m curious what else is out there.
LikeLike
There are is the KE1xF, KE1xZ, KE02, KE06, KE04 (http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/e-series-5v-robust-m0-plus-m4:KINETIS_E_SERIES). I have the FRDM-KE02Z (but that one is actually running at 3.3V, https://mcuoneclipse.com/2013/08/19/a-5v-freedom-board-frdm-ke02z/). All of my current designs are using 3.3V.
LikeLiked by 1 person
Yes, we have a KE18F kit for testing; hopefully that part will be the replacement for the Freescale one that we use currently
LikeLiked by 1 person
Hello Erich, thanks for this post !
I’d like to emphasize on this even more because I observed during my embedded engineering studies and now that I work, that people often chose the microcontroller for their product mainly based on the available tools AND on the families they already know, as long as there’s not a too big sacrifice to do on the features or the technical characteristics.
As an example, in the engineering school I was we mainly used Freescale/NXP K6X and KL1X microcontrollers and those were the microcontrollers used in all the bachelor thesis mandated by external companies, which means those companies quickly gained a huge external know-how on those families.
By the way, is there a consensus somehow between all the embedded systems professors in the HES in Switzerland ? Because I was amazed to see in your blog the same boards and microcontrollers than those that are in use where I studied embedded system engineering.
LikeLike
Hi Tim,
yes, I see as well that ‘choosing what I already know’ is a common pattern. Not a bad one per se, but prevents to look out for new families or new devices. A device family or vendor can be good for some time, but then usually someone else is getting better. And no, there is no such consensus about which micrcontrollers to use. I know that others are using Freescale or NXP devices too, but everyone is (at least at my university) to use what fits best for the course. The NXP FRDM boards a STM Nucleo boards are very popular (at least the lower cost ones): for less than $15 you get a usuable board with debug interface, sensor and headers for Arduino shields which makes them very attractive.
LikeLike