SCOTT MILLER

General impressions of MCUXpresso and comparison to KDS and CW

Discussion created by SCOTT MILLER on Aug 3, 2017
Latest reply on Aug 17, 2017 by SCOTT MILLER

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

Outcomes