Is the LPCWare CMSIS driver development now dead, as it seems all development work is on LPCOpen?

[lpcware]

Content originally posted in LPCWare by rgledhill on Fri May 10 12:16:04 MST 2013

Hi,

We are developing code for customers using the LPCWare CMSIS driver from the GIT repository; however there's been no real development on this for some time, and meanwhile there are regular development and updates for the LPCOpen code.

Does this mean the CMSIS support from NXP is dead, and all efforts will now be in LPCOpen?

This is REALLY important to us as we move forward with customer projects and could see us move to ST or Infineon devices if NXP is dropping support for CMSIS.

Thanks,

Richard

[lpcware]

Content originally posted in LPCWare by mburton on Wed Jun 19 11:07:30 MST 2013

Hi Tealok,

Thanks for the reply. Because I only really need CMSIS, FreeRTOS and basic peripheral support at this time, I'm not looking to extend the scope of the lpcopen-make project myself but if anyone does want to use it to compile some of the other LPCOpen components, I would be very happy to incorporate their efforts. It's very much a work in progress and it's going to change as NXP refactor the LPCOpen source but, hopefully, one day will be reasonably stable. I am using it for two projects at the moment and it's working well enough.

To be honest, I think that NXP have taken a retrograde step with LPCOpen - assuming everyone wants to use a Windows based IDE for development is very narrow minded.

Anyway, if you do try lpcopen-make and have some feedback, please contact me off list so we don't pollute the airwaves.

Cheers,

Mark

[lpcware]

Content originally posted in LPCWare by tealok on Wed Jun 19 10:06:24 MST 2013

Mark,

I just spotted your post, and appreciate your makefile Git repo.  My task is likewise focused on Linux (Suse 12.3, Linaro bare-metal toolchain), and I have spent the last 3 days porting an LPCOpen example from Win7 Xpresso to my toolchain.  Evidence of poor Linux support came through when I tried to compile the same examples on the Linux version of Xpresso.  Many compilation failures were due to case errors, which I ultimately fixed with symlinks to an opposite-case version of the offending header files. A simple Jenkins build-bot would have found these, so maybe the Xpresso IDE is  not scriptable ??

I plan to try out your contribution, which appears to be focused on the 43xx/18xx chip example with FreeRTOS.  Our chip is a 4330, so my/our work may not satisfy your invitation to extend the makefiles for other components/chips, but I will at least feed back any issues found.

Tealok

[lpcware]

Content originally posted in LPCWare by rgledhill on Fri May 17 00:59:00 MST 2013

Hi Kevin,

Thanks for this - I see all the filenames and API function names have completely changed so it's not a straightforward swap.  I'll have a trawl through the documentation too.

Looks like we'll have to bite the bullet then and move across to the LPCOpen drivers at some point but I do feel rather misled by NXP on this one, I have to say...

In any case thanks for your help.

Cheers

Richard

Hitex UK Ltd

[lpcware]

Content originally posted in LPCWare by wellsk on Wed May 15 16:31:00 MST 2013

As of yet, I don't think the CMSIS specification actually defines CMSIS peripheral drivers as a usable standard. In LPCOpen, we support v3.01 CMSIS-core types and functions. Drivers are developed using types from the CMSIS files (ie, _IO) and are at best called CMSIS-compliant at this point. (<a title="View user profile." href="http://www.lpcware.com/users/wmues">wmues</a> described it accurately the drivers as a thin layer of access functions.)

Are you looking for the driver source code for your specific device? This would be located in the lpcopen/software/lpc_core/chip_&lt;CHIP&gt; directory, based on the chip you are using. The libraries are built from the code in this Chip area plus board code plus code from a few other areas.

Some help for what's in the libraries can be found at the links below.

http://docs.lpcware.com/lpcopen/v1.03/_l_p_c_o_p_e_n__x_p_r_e_s_s_o__p_r_o_j_e_c_t__p_o_r_t_i_n_g__g...

http://docs.lpcware.com/lpcopen/v1.03/_l_p_c_o_p_e_n__b_o_a_r_d__p_o_r_t_i_n_g__g_u_i_d_e.html

[lpcware]

Content originally posted in LPCWare by rgledhill on Wed May 15 07:17:07 MST 2013

Just to follow up - I've downloaded the LPCOpen distribution and I can't see any source code for the CMSIS drivers; they appear to be pre-compiled in a library file.  This no use at all for us as we frequently need to make modifications to the drivers (and indeed regularly find bugs in them, I have to say).  Could you point me to the source code for these drivers?

We'd also be happy to feed back our bug-fixes to you :-)

Thanks

Richard

[lpcware]

Content originally posted in LPCWare by mburton on Wed May 15 02:17:04 MST 2013

Hi,

For me, the fact that lpcopen appears to be only really supported for Windows based dev environments is very worrying. I believe that it should be supported for all the major development systems. I can currently build the core lpcopen libraries on Linux using <a href="https://bitbucket.org/smartavionics/lpcopen-make">https://bitbucket.org/smartavionics/lpcopen-make</a> and I would be happy to provide support for building some of the other lpcopen components if people want to use them and are willing to participate in the development of the Makefiles.

Cheers,

Mark

[lpcware]

Content originally posted in LPCWare by rgledhill on Wed May 15 02:05:00 MST 2013

Hi,

Firstly many thanks for getting back to us officially, I really appreciate it.

Essentially I just need to ensure that we are always using the most up to date version of the drivers from NXP.  So does this mean that I should download LPCOpen and take the drivers from there as CMSIS drivers?

You are right, LPCOpen is huge, but as long as the necessary drivers are clearly defined for me to move to our project, this is fine.

One other point: there is no documentation for the CMSIS drivers in the GIT repository - you have to basically guess by looking at the source code.  Are the LPCOpen drivers properly documented?

Thank you again

Richard

[lpcware]

Content originally posted in LPCWare by NXP_Support on Tue May 14 16:53:00 MST 2013

Hi Richard,

Indeed NXP is focusing on developing and maintaining our LPCOpen Platform, which is compatible with CMSIS definitions.  Is your primary concern the current bulk of LPCOpen, or that it is not currently in a public GIT repo, or do you see incompatibility w/ CMSIS definitions?  We are working to make LPCOpen Platform easier to use and more manageable for our customers - there is still a lot to do!  We appreciate any feedback for improvements. 

[lpcware]

Content originally posted in LPCWare by rgledhill on Tue May 14 00:28:56 MST 2013

Thanks for the thoughts.  I agree that the CMSIS drivers really are only a starting point - we keep unearthing bugs in them all the time, though to be honest "example" code such as this often has bugs in from any manufacturer so NXP are probably no worse than many others in this respect.  Their drivers are indeed quite thin but that's often because the underlying peripherals are quite complex - though compared to Infineon micros (which I'm used to), they are very simple peripherals and really the drivers should work.

My concern is that NXP seem to have taken a decision not to develop the CMSIS driver support any further, in favour of their LPCOpen platform, which is clearly going against ARM's intention of harmonising the APIs used for developing on ARM micros.

I'm actually quite happy to feed back the bugs as I fix them but there's no point if they aren't going to release any more code...

<strong>It would be very useful to have someone from NXP comment on this please!</strong>

Richard

[lpcware]

Content originally posted in LPCWare by piotr.olczyk on Sun May 12 11:19:19 MST 2013

I feel that NXP corp. did nothing in the subject line of software for microkontrolerów. The problem is not only with the CMSIS (currently CMSIS v.3), but also with there aren't any examples for many new microcontrollers. Absolutely nothing for the LPC1347.  The advertising campaign with new microcontrollers must include examples of software for them. Last examples were in 2011.
Who gives their product NXP e.g. LPC 800, LPC1347 ... to large corporations or to individual designers who are often students.

[lpcware]

Content originally posted in LPCWare by wmues on Sat May 11 04:24:01 MST 2013

Richard,

I have done a project for the LPC1788. I have looked at the CMSIS drivers and found that most "drivers" are only a thin layer of access functions, not more. And everytime the hardware gets complex, the CMSIS drivers are incomplete and/or not usable. In the end, I have used the CMSIS driver as educational tool, not in production code.

For me, it's not clear which goal is behind the CMSIS library:

- If the intention is to be an abstraction layer, the CMSIS library will fail to export all features of the underlying hardware. This is bad.

- If the intention is to export all features of the underlying hardware, how on earth is a portable abstraction layer possible? No way.

I have found the feature set of the NXP chips far superior than the competition. And this is what counts most for me.

best regards

Wolfgang