General impressions of MCUXpresso and comparison to KDS and CW

[scottm]

This is more a question for the community than for official NXP support.  I pick development tools about as well as I pick stocks - as in two days after I invested in a biotech company they lost 90% of their stock value and were bankrupt in a month.  I bet on classic CodeWarrior for the sake of avoiding Eclipse just before the CW's switch to Eclipse was announced, then bought a CW 10 license right before support for new devices was ended and Kinetis moved to KDS, and now that I've got a couple of projects going in KDS, KDS is out and MCUXpresso is in.

For those of you who switched from one of those, how do you like it so far?  How's the polish and the debug support, particularly in regards to P&E hardware and FreeRTOS thread awareness?  Anything that particularly stands out as better or worse than the others?

NXP folks can answer this - is CodeWarrior the last word for legacy ColdFire and HCS08 development?  Rising part costs are going to drive out all of my remaining HCS08-based products soon (they're more expensive now than vastly superior Kinetis parts) but I have thousands of deployed devices that could need occasional bug fixes for years to come.  I'm still having to maintain CW 6.x on a Windows XP VM for a few of those that didn't port to CW 10.  For one brief, shining moment a couple of years ago I had HCS08, ColdFire, and Kinetis all in one IDE.  I don't expect that to happen with MCUXpresso but if CodeWarrior is going away, give me some command line tools now and I'll put together something in Eclipse to keep my legacy stuff going and I'll wash my hands of CW and KDS.

I was highly skeptical of Processor Expert in CW 10 (and never touched it at all in its previous incarnations) but grew to appreciate it and thought it had great potential, despite some bugs and deficiencies that have sometimes required ripping the components out completely because they just wouldn't do what was needed.  KDS managed to make PEx way uglier and less intuitive, and my limited experience with KSDK has not been positive.

At its best, PEx does a great job of guiding the user through complex setups.  Sometimes it works beautifully and a clock configuration change that would be a pain to work out manually just works and I can see all of the resulting peripheral baud rates and error terms, and it lets me know what I'm doing wrong when configuring a peripheral.  Sometimes it's not as great and, like in the K22F I2C component, just gives me some binary fields to enter and try to figure out clock divisors myself.  That's at least no worse than doing it manually.

My first experience with KSDK was changing a UART assignment and having the baud rate suddenly change on me.  I had to dig through the KSDK code and then the reference manual and found buried in the chip-specific clocking configuration section a footnote that UART0 has a different clock source from the others.  This is not captured by KSDK, and from a configuration perspective makes it to me not much more valuable than a piece of example code in an app note.

Is KSDK getting better?  Is anything else coming along in MCUXpresso to replace or augment it?  Done well, KSDK ought to be a good tool, but as a runtime system I don't see it providing the kind of design-time feedback that PEx does.

And if I could ask one thing of the powers that be at QualcommNXPFreescalePhilipsMotorolaVLSISignetics it would be a comprehensive in-IDE documentation system to augment or replace the traditional PDF docs for the APIs, SDKs, and parts.  My favorite help system in an IDE ever was Borland Turbo C++ circa 25 years ago, with every keyword and library function linked to a hypertext help system with complete usage and examples for everything, and the occasional chicken anecdote.

We ought to be able to do way better than that today, with interactive clocking diagrams, descriptive text for generic peripheral blocks that actually links directly to the chip-specific information, along with all of the available app notes applicable to that peripheral presented right there.  Give me instant access to exactly the reference material I need (and hopefully at least a few Javascript calculators to speed things along) and I won't care so much if the API isn't what I want it to be or if the PEx tools are gone.  I waste way too much time just trying to find the right docs.

Scott

[BlackNight]

Hi Scott,

thank you for providing that feedback and thoughts. Indeed, with all the changes over the past years, this can be challenging.

I try to answer the following:

>>is CodeWarrior the last word for legacy ColdFire and HCS08 development?

Legacy ColdFire and HCS08 remain supported in CodeWarrior. They are not (and will not) be supported in KDS or MCUXpresso IDE. Latest CodeWarrior version is CW for MCU v10.7 which is still maintained, and maintenance releases coming out.

About:

>>give me some command line tools now and I'll put together something in Eclipse to keep my legacy stuff going.

In CodeWarrior for MCU (as well the legacy CW for MCU 6.x) includes command line tools, and you can use a make file approach with Eclipse (e.g. see Tutorial: Makefile Projects with Eclipse | MCU on Eclipse ). As for debugging, you might consider a standalone debugger/downloader. As for my self, I keep CodeWarrior 10.6 installed for all the legacy projects I have to maintain, and plan to keep it that way the coming years.

For the other items, you are raising good points. As for myself, I have been able to leave KDS behind and use MCUXpresso IDE as the IDE for all NXP Cortex-M microcontrollers (Kinetis and LPC).

Thanks, and I hope this helps,

Erich

[scottm]

>In CodeWarrior for MCU (as well the legacy CW for MCU 6.x) includes command line tools, and you can use a make file approach with Eclipse

Do you happen to know if the 6.x command line tools run under modern versions of Windows?  I have a perpetual license for 6.x, but I made the mistake of going with the annual subscription for 10.x.  That seemed like a way to hedge my bets at the time because of my aforementioned knack for picking the wrong IDE, but now it means that even if MCUXpresso covers my Kinetis needs I'm stuck paying for renewals on something I might eventually use only a couple of times a year for fixes.

I've got a small pile of P&E Cyclones so I'm covered on debugger/downloader tools.

Back to MCUXpresso, it looks like it has no code size limitation in the free version now, and the Pro version (is there a price yet?) only differs in tech support and SWO trace support.  Is that right?  And more importantly, is it the plan to keep it that way?  I'm a little afraid of switching again and then when the next generation of parts comes out having some other limitation introduced, or features not yet migrated from KDS or CodeWarrior becoming premium options.

The purely open source solutions available are good enough that such a move doesn't seem like a big threat anymore, not like with HCS08 where free tools were really not up to the task, but I've been burned before.  The software landscape is changing and as a small business owner I've got more and more software tools I depend on moving to subscription-only plans (thanks, Autodesk and Adobe) and I feel like the choice is between being slowly bled dry and the pain of switching to open source alternatives if they're available.

Thanks,

Scott

[BlackNight]

>>Do you happen to know if the 6.x command line tools run under modern versions of Windows?

Yes, I'm using HCS08 and ColdFire on Windows 10 64bit with CodeWarrior 6.2, and the command line tools work fine. Only the IDE sometimes crashes when I want to close a project, no sure why.

>>Back to MCUXpresso,...

correct, it is unlimited and free of charge. Some advanced SWO and interrupt trace are part of the Pro edition, see MCUXpresso IDE|NXP . There is a link in the 'Purchase' tab which guides you to the store.

Erich

[scottm]

So I'm working on a project right now in CW 10 - it runs on the MK22FN1M0AVLH12 which I think wasn't supported under KDS but it seems to be in MCUXpresso now.  I haven't been able to consider changing IDEs for it previously because of that and the fact that I've been maintaining the older ColdFire version in parallel.

I've now forked the project for a new hardware variant that doesn't have a ColdFire twin to worry about.  I've also begun porting it to FreeRTOS, and I'm using your FreeRTOS PEx component.  I've got other PEx components in there but I started replacing those long ago.  I don't anticipate a lot of difficulty getting off PEx here, but I'll have to look carefully at the FreeRTOS setup.

What's really driving me is the need for task-aware debugging.  I'm going nuts trying to trace stuff down in CW's debugger.  Aside from losing PEx, is there any other pain I can expect from migrating this project to MCUXpresso?  It's about 400 kB of code so far, using a P&E Cyclone ACP for the debug interface.  Are there other CW features I'm going to miss?  I seem to remember KDS not displaying globals except as expressions (which seemed to be slow) and missing peripheral registers in the debugger.

Or is it possible to use MCUXpresso's debugger against a CW 10 generated ELF binary so I can get the task-aware debugging?

Thanks,

Scott

[BlackNight]

Hi Scott,

yes, the biggest delta from CW or KDS to MCUXpresso is Processor Expert (but you can add it in an 'unsupported' way as described in MCUXpresso IDE: Installing Processor Expert into Eclipse Neon | MCU on Eclipse ).

And KDS *has* peripheral register display support through the EmbSysReg plugin added by default (How to Add Register Details View in Eclipse | MCU on Eclipse  describes that plugin and how to install it into any Eclipse).

As for global expressions: this is much improved in MCUXpresso IDE which comes with its own variable view, including the really good Peripherals+ view (see MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers | MCU on Eclipse ). And what you might have missed from CW going to KDS is the 'live variables' view: this has been added to MCUXpresso IDE too, including for the P&E connection (Live Variables | MCU on Eclipse ).

As for debugging a CW10 binary: I have not tried that, but I don't see any reason why this would not be possible: simply specify the .elf file in the launch configuration and that should do it. The only point is about the paths to the source files for the debug information. But as long the sources for that build with CW10 is on your machine, the debugger will be able to find it. Otherwise if you see a problem, let me know and I try to have a more detailed look.

I hope this helps,

Erich

[scottm]

I'm in the process of moving some of my projects away from PEx anyway, in part to deal with the broken DMA stuff (no INTHALF support) and some limitations of various components.  I love it when it works, and I really hope something like that catches on again and gets some ongoing attention.  I'm too busy with deadlines right now to worry about switching IDEs just yet but I'm trying to plan ahead.

The live variables view has never been that useful to me - too slow to be much good.  I'd really like to have something more like FreeMASTER's oscilloscope display, but not so horribly clunky and inefficient.  It can take minutes to add a new variable in FreeMASTER because it populates the list with every single array item, which means I have to try to find what I'm looking for in tens of thousands of entries.  The display also doesn't update smoothly for me and it doesn't scroll or zoom the way I'd like.  I'd love to have a trace output that shows a few values in real time, so I can watch things like the behavior of DMA buffers.

Thanks,

Scott

[BlackNight]

Hi Scott,

I'm using J-Scope (J-Scope | SEGGER - The Embedded Experts ) for this kind of variable watching, but this requires a Segger debug connection.

Erich

[scottm]

I'll have to check that out.  I've got an ancient J-Link but I don't think it's supported.  I'd love a J-Trace Pro but I can't justify the cost right now.  I'm also really interested in seeing how Segger compares for download speed.  I kill a lot of time restarting the debugger after minor changes.  Some of that seems to be CW's fault, with time wasted on mysterious things like "path remapping" that no one seems to be able to explain.  The P&E Cyclone ACP loads reasonably fast but the whole process is slower than it seems like it should be.

Scott

[BlackNight]

All what you need is a J-Link, no J-Trace required for J-Scope.

Erich

[scottm]

I understand, just saying I'd really like a J-Trace as well - P&E doesn't seem to have anything comparable, last I checked, and I need to get in the habit of making more use of tracing a profiling.

I should probably check if anyone does any hands on training or vendor demos for trace and debug stuff in California.  That's something I'd drive a bit for.  Always nice to try it out in person first.