What is wrong with processor expert

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

What is wrong with processor expert

720 Views
andrewmeyerbti
Contributor III

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.

1 Reply

705 Views
ErichStyger
Senior Contributor V

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:

  • Many developers do not trust 'someone else' code: they want to change it. While it is possible with Processor Expert (https://mcuoneclipse.com/2012/03/23/disable-my-code-generation/ , https://mcuoneclipse.com/2014/01/12/diy-changing-processor-expert-components/ ) it is not that straight forward.
  • As most developers prefer plain C code, this causes a dilemma to the vendors: they would have to provide 'traditional' SDKs (like the MCUXpresso SDK) *plus* the component based code generator modules: from an engineering/development cost to provide two things to do basically the same is probably not worthwhile. And say if 70% or 80% prefer the C/C++ code, then I think the choice with limited budget is clear
  • Integration of Processor Expert with modern development flow (build servers, version control system) has been difficult. This is much easier with a 'classic' approach.
  • Processor Expert would have taken off with the concept to build your own components and share them. We have used that approach successfully with more than 100 custom components, but I have not seen much traction elsewhere.
  • Processor Expert would have taken off with the concept to build your own components and share them. We have used that approach successfully with more than 100 custom components, but I have not seen much traction elsewhere.
  • One advantage of Processor Expert is that the code/driver is tuned by the settings you do in the properties. Using properties like this is a great thing (other vendors do this in different ways). But this is the same time a disadvantage because a changed setting will produce different code. Most developers prefer a more 'static' code: while Processor Expert allows this, the drivers provided by NXP did not follow this.
  • Another point is that Processor Expert is proprietary and keeps you inside the NXP ecosystem: it would have been much bigger success imho if it would have been an open source solution with permissible license.
  • Processor Expert approach makes it really easy to move from one device to another. We have used it to move between 8/16bit, DSC, ColdFire, ARM parts of NXP. But this is probably not the most common use case.

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

0 Kudos