CMSIS or Not

[lpcware]

Content originally posted in LPCWare by richas on Mon Feb 15 18:15:28 MST 2010
I am tempted to not link in the CMSIS project in order to keep my code more portable.  Including it seems clumsy and big as compared to handled the low-level stuff myself.

Opinions?

Rich

[lpcware]

Content originally posted in LPCWare by NXP_USA on Wed Feb 17 10:33:14 MST 2010
One more tip:

Check out the usbhidrom_tiny project in the latest LPC1343 example bundle on www.nxp.com/lpcxpresso-support. The example implements a USB HID device using only 404 bytes of Flash. It shows how to reduce code size by removing the CMSIS init code from your project, while still using the CMSIS header files.

usbhidrom_tiny is meant as a collection of techniques to reduce code size, and it uses many advanced techniques to reduce flash usage (such as placing code inside the vector table) which may not all apply to your application.

Note: A known issue with this project is that it is not compatible with LPCXpresso debugging. It can be programmed once and then the debugger will not be able to connect to the board. Make sure you can trigger the in-system programming (by pulling P0.1 low) in order to recover the board for future LPCXpresso programming.

-NXP

[lpcware]

Content originally posted in LPCWare by richas on Wed Feb 17 10:16:00 MST 2010
Thanks for your help in understanding how this works.

Rich

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Wed Feb 17 06:59:50 MST 2010
The CMSIS files are supplied as an example library project for LPCXpresso, as this makes it simple for new projects (and the provided examples) to access the CMSIS headers and code. However if you wish to make changes to the CMSIS files (for example changing the clock speed) this will of course effect all the projects within the current workspace that make use of the CMSIS library project.

Thus if you want to make changes to CMSIS for just a single project, we would recommend that you consider doing one of the following:

[LIST]
[*]Create a new workspace within which you have only your modified version of the CMSIS library project, and your actual application project.
[/LIST]

[LIST]
[*]Copy the CMSIS header and code files from within the CMSIS library project into your actual application project - and modify the CMSIS files within the application project itself. If you do this, make sure that you modified the project settings so that you don't pick up headers/code from the original, unmodified CMSIS library project.
[/LIST]

[LIST]
[*]You could create a bespoke version of CMSIS library project with a different name, though again you would then need to make sure that you modify all of the application project properties to point to your bespoke version rather than the standard one. Note also that the LPCXpresso IDE project wizard only knows about the"standard" CMSIS library project names, so if you create your own version, you will need to modify the project properties of any application projects you want to use your own version manually.
[/LIST]
Regards,

CodeRedSupport.

[lpcware]

Content originally posted in LPCWare by richas on Tue Feb 16 14:13:20 MST 2010
The structured register descriptions are weird but I understand the idea behind it.  I think I will keep life "simple" for now and keep the CMSIS stuff.  It looks like I change the system_LPC11xx.c file in the CMSIS project to  change hardware specifics such as clock source etc.
Since the CMSIS project could be referenced by several projects do I have to change these parameters for each individual project?  :P

Rich

[lpcware]

Content originally posted in LPCWare by ktownsend on Mon Feb 15 18:38:55 MST 2010
I'm kind of divided on it myself.  It's nice to have a standard way to handle the interrupts, etc., but the (to my mind) unusual structs and typedefs kind of annoy me, and GCC throws out a lot of warnings because of them.  I ended up making my own LPC134x.h file (even though it took about a week) simply because I'm used to working with definitions on a single 'level' (i.e., not A->B, etc.).

For the moment I've kept CMSIS in my code, but only use it for working with interrupts (I configure the CPU, clocks, etc., myself).  I may end up removing it in the future, but ut will take me a bit of time to learn all the ins and outs of the Thumb-2 command set, so I'd rather leave the low-level ASM until the end.

That said ... it's a great idea for people just starting out, since the worst part is usually just getting the chip up for the first time, especially if you're using GCC (Keil etc. provides startup code for you).

Kevin.