Can someone please explain why NXP is reducing/discontinuing support for processor expert? The software greatly reduces my burden in learning the details of each chip, it appears to be quite user friendly, and it helps me with porting software from one chip to another.
The newer way appears to be on-line generated libraries which seem more difficult to learn and require more chip-specific knowledge, though probably just as good for portability between chips.
Please help me understand the pros and cons.
Hi @andrewmeyerbti ,
I think there is nothing 'wrong' with it. It is a great piece of technology and a modern approach to software and device firmware development. I have been a great fan of that technology and successfully used it in many commercial products, and you can find many articles about it on my blog https://mcuoneclipse.com/ . But as you noticed: it is fading away, and while I still use it (it still works in the NXP MCUXpresso IDE), it have moved up and have ported projects (https://mcuoneclipse.com/2018/07/27/porting-processor-expert-projects-to-mcuxpresso-ide/ ) or moved to the McuLib (for example https://mcuoneclipse.com/2020/06/14/how-to-get-data-off-an-embedded-system-fatfs-with-usb-msd-host-a... ) approach.
While a component based and code generation approach with deep device knowledge is great, it does not work for everyone:
So in my view: while it is a really great technology it does not fit for everyone, from a vendor point of view it causes a dilemma about continued development for it, especially if you would have to provide the drivers multiple formats: alone supporting all the different IDEs and build tools would be challenging.
As a successor NXP has established the 'MCUXpresso Configuration Tools' which make device and driver configuration easier with a graphical way. So you can consider this as the 'Processor Expert' part of the MCUXpresso SDK. In the end it means reading the device reference manuals again and stick with the SDK code which can be modified and has a permissive license.
But there are alternatives: you could develop your own driver and middleware library (as we did with the McuLib), and you can combine and use this with the SDK too. Many bigger companies do something similar too. As other option I recommend to consider the great uTasker (https://www.utasker.com/ ) project by Mark Butcher.
I hope this helps,
Erich