MCUXpresso recommended Code Bundles vs LPCOpen

[larryviesse]

A few years ago I asked a question about the jump from CMSIS to LPCOpen,  LPCOpen or not?, and it seems that I now need to ask the same sort of question regarding the recommended Code Bundles per the MCUXpresso Supported Devices Table.  The chip I am using is an LPC824.

I found the Code Bundle to be extremely lacking with regard to inline functions.  I saw nothing to provide for support of the ROM APIs.  LPCOpen has these inline functions and quite a few more.  Why are NXP recommending the low level coding approach taken with the Code Bundles?

It now appears that NXP are dropping LPCOpen for newer devices, given the rich development ecosystem that LPCOpen provides, can NXP explain why?

[brendonslade]

Hi Larry,

We are listening to the feedback from you all on the community and are working on a streamlined version of our SDK for LPC8xx devices, and are targeting roll out of these to beginning in early Q2 2018. By aligning with MCUXpresso SDK, we will be able to provide you with a more consistent driver library, configuration and clock tools across LPC and Kinetis devices. While LPCOpen is a good driver/example set, it doesn't have the same tie in with the rest of the tools. We are looking at taking several of the nice inline coding features of LPCOpen into this SDK implementation.

The idea of Code Bundles is to provide very small and efficient, lower level drivers for customers coming across from 8 and 16 bit MCUs. We recognize that this isn't what all customers want, so are working hard to correct that, as described above.

Best regards,

Brendon

[larryviesse]

Hi Brendon,

Thanks for the explanation of NXP plans for the development roadmap for the LPC824, it sounds like NXP understands the importance of having a consistent development environment and that NXP are addressing our concerns.

After viewing the code in the Code Bundle I came to the same conclusion as you described.  It remarkably resembles the low level coding style that I am familiar with for AVRs.  However I prefer productivity over direct bit level manipulation.

Any suggestions for what would be best to use for new development in the interim?  I am assuming it is LPCOpen but if there are other alternatives I would like to hear about them.

Thanks again,

Larry