LPCOpen or not?

[lpcware]

Content originally posted in LPCWare by larryvc on Mon Jan 27 09:37:40 MST 2014
Hi all,

Just returning to LPCs and the forum after a bit of a hiatus and I've tried to figure out what the difference is between LPCOpen and the older CMSIS based builds are?  Is this the future of LPC development?

Can someone give me a thorough explanation of what this is all about?

Do I want to base new projects on LPCOpen?

[lpcware]

Content originally posted in LPCWare by gloverde on Tue Feb 18 08:47:01 MST 2014

---

Quote:
I thought I was the only one thinking it odd that there is no centralized forum for LPCOpen given the direction that NXP has taken. This is a big step switching from CMSIS based to LPCOpen. I am in the midst of doing a test conversion and so far have only been partially successful, there is much to learn. The fact that there is no documentation for project migration, even a summarized one ( I had asked about this in another thread here), is unfortunate. The learning curve is steep, hopefully NXP will think carefully before they make a big switch like this in the future.

---

I agree.

I just started using ARM last week for a project that was transferred to me.
I'm still not sure if the CMSIS based code that was tossed in my lap should be ported or not.
I have IAR's compiler and was hoping to do a port but this doesn't seem like the best option, since the project is small enough for the free version of LPCxpresso.

I asked a question similar to the original post of this thread directly to NXP technical support and received this classy one liner a week later.

---

Quote:
*** Answer
 
Hello,
I can not help you to port it. but i think it is easy .

Please let us know if this does not resolve your inquiry. Your ticket will remain closed if we do not hear from you.

---

^That is word for word, I made no changes I kid you not.
They may think it should be a pretty easy port, but it's just as easy for me to slip a different chip in on the next board revision.
I didn't ask someone to port it for me all I asked was to be pointed in the right direction.

I have found most of the information I needed now, but I had to click my way through a maze to get it.

[lpcware]

Content originally posted in LPCWare by larryvc on Fri Jan 31 12:42:35 MST 2014

---

Quote: jonper
With larryvc's original question, lpcxpresso-support's helpfully frank reply, and wellsk's expansive explanation, it's clear that going forward, LPCOpen will be the only NXP supported resource driver and example code. There's certainly much interest: With just a year of existence, a forum Home>>Search for "LPCOpen" lists 5580 hits!

---

The first hit in that search is LPCOpen Forum?.

---

Quote: jonper
So why then is there still no dedicated LPCOpen forum here despite repeated calls for that on this and several of the other forums? While the NXP engineers busily chip away at the coding and documentation goals, a dedicated forum could better let us early adopters help each other muddle through the gaps.

---

I thought I was the only one thinking it odd that there is no centralized forum for LPCOpen given the direction that NXP has taken.  This is a big step switching from CMSIS based to LPCOpen.  I am in the midst of doing a test conversion and so far have only been partially successful, there is much to learn.  The fact that there is no documentation for project migration, even a summarized one ( I had asked about this in another thread here), is unfortunate.  The learning curve is steep, hopefully NXP will think carefully before they make a big switch like this in the future.

I encourage NXP and the LPCOpen team to consider taking the initiative to add a dedicated forum for LPCOpen.  Now that LPCOpen is at v 2.xx this is the perfect time for that to happen.

[lpcware]

Content originally posted in LPCWare by jonper on Fri Jan 31 10:51:45 MST 2014
With larryvc's original question, lpcxpresso-support's helpfully frank reply, and wellsk's expansive explanation, it's clear that going forward, LPCOpen will be the only NXP supported resource driver and example code. There's certainly much interest: With just a year of existence, a forum Home>>Search for "LPCOpen" lists 5580 hits!

So why then is there still no dedicated LPCOpen forum here despite repeated calls for that on this and several of the other forums? While the NXP engineers busily chip away at the coding and documentation goals, a dedicated forum could better let us early adopters help each other muddle through the gaps.

[lpcware]

Content originally posted in LPCWare by perra_e on Fri Jan 31 04:25:13 MST 2014
After testing a little bit with LPCOpen I must say I like it better then the old CMSIS library.
There are more metods for manipulating port settings for instance. This makes the code  more clear to read for me.
I prefere methods over bit maniputaion in the code.

--Per

[lpcware]

Content originally posted in LPCWare by larryvc on Tue Jan 28 10:56:36 MST 2014
What brought about this change in direction away from the CMSIS way of doing things?

[lpcware]

Content originally posted in LPCWare by larryvc on Tue Jan 28 10:08:07 MST 2014

---

Quote: lpcxpresso-support
However, I can tell you that no further effort is being put into CMSIS and future support will be provided by LPCOpen.

---

Thank you both for your replies.  That statement is the answer I was looking for.

---

Quote: wellsk
If you are happy with the legacy bundles and currently have projects that you are using based on them, I'd stick with the code bundles. If you are considering starting from scratch, or are using a new device, or just starting with LPC device, I'd use LPCOpen.

---

So for new devices I will use LPCOpen.  I will try to port one of my larger CMSIS based projects to LPCOpen to see how many changes I would need to implement as a worst case test scenario.

Don't want to talk about Zero?

[lpcware]

Content originally posted in LPCWare by wellsk on Tue Jan 28 09:53:37 MST 2014
LPCOpen is the current and planned software development and release approach for current Cortex M and any upcoming devices. The intention is to provide a standard software development approach that is the same across all device and platforms. LPCOpen is CMSIS based although it doesn't have the word 'CMSIS' in it's name, it uses the ARM provided CMSIS header files at it lowest level for core functions related to the NVIC, System tick timer, etc.

Here are some of the goals of LPCOpen, but this isn't a complete list. Some goals are met, others are ongoing.
- Provide drivers with the same or very similar APIs across multiple platforms - this has limits based on the functional differences on peripherals across devices, but APIs should be very similar
    - Drivers such as GPI, I2C, SSP, UART, etc. are the same across platforms
- Provide basic examples that show how to use those drivers in an environment, most examples are very similar across platforms, but highlight part specific differences in some cases
- Standardize code startup approach that handles clean system bring up before main() - clocking, platform level pin muxing, external memory setup
- Simplify projects (trying to avoid complex linker scripts, work on non-Windows platforms (LPCXpresso), and use only standard features specific to a tool chain. Projects are provided for Keil MDK/UV4, IAR EWARM, and LPCXpresso tool chains
- Optimization - drivers work at full optimization level and use less code space than legacy drivers, examples ship size or speed optimized by default
- Drivers attempt to avoid the use of data defined in the driver, use of context specific data if possible
- Standardize DEBUG API - DEBUGIN, DEBUGOUT, DEBUGSTR - with ability to disable in production code
- New devices such as the 11u6x are only released in LPCOpen format
- Much improved 3rd party code integration - LWIP, FreeRTOS, uCos-III, emWin, etc.
- Constantly being improved, bugs being fixed, and updates released
- Clean, readable code that is commented with meaningful comments in the right places. Improved documentation for functions (API level documentation)
- Eventually: Driver use documentation that explains the driver use model and how to use and setup the driver in detail
- Distinction between chip and board layer code, standard set of board/platform functions (LED, DEBUG, UART, SystemInit()) that work with all examples

There are a lot of changes behind the scenes, things that aren't necessarily seen or heard - more code reviews, driver improvements and bug fixes, better change and package version history, automated testing, etc. to help improve quality and reduce potential problems.

LPCOpen isn't perfect and will probably never be perfect for everyone. There will be those that prefer the CMSIS code bundle APIs as they are comfortable with them, there are those that want C++ or mbed style drivers, others still want something different that is more suited to what they are doing. Using LPCOpen over the legacy CMSIS packages is a personal choice. If you are happy with the legacy bundles and currently have projects that you are using based on them, I'd stick with the code bundles. If you are considering starting from scratch, or are using a new device, or just starting with LPC device, I'd use LPCOpen.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Jan 28 09:03:33 MST 2014
We (lpcxpresso-support) are not experts in LPCOpen - I have asked our LPCOpen colleagues to provide a more detailed response.

However, I can tell you that no further effort is being put into CMSIS and future support will be provided by LPCOpen.

[lpcware]

Content originally posted in LPCWare by larryvc on Tue Jan 28 08:41:15 MST 2014
Any reason why lpcxpresso-support didn't take the time to answer these questions?

This is not a good indication what this site has turned out to be.  I seem to remember receiving fast and thorough answers in the past.

[lpcware]

Content originally posted in LPCWare by perra_e on Mon Jan 27 12:05:40 MST 2014
I have asked myself the same question.
From what I  read on the page you link to I realy like "Provide a set of common reference drivers can be used across multiple NXP devices".
I dont like the differens in how you write the code with CMSIS for the 13xx and 17xx family. 
If it is possible or not to have a common interface for the differnt MCU's I don't know, but if it is ,I will probably write all new code for LPCOpen.

--Per

[lpcware]

Content originally posted in LPCWare by larryvc on Mon Jan 27 10:55:27 MST 2014
Okay, I did find this and am starting to digest it.  LPCOpen platform design approach and goals

Do I want to base new projects on LPCOpen?

What benefit would it be to migrate older projects to LPCOpen?

OT:  Where the heck did Zero go?