LPCOpen is constantly being improved, updated, and enhanced. becase of this, LPCOpen in constantly changing. This topics provides some guidelines for using LPCOpen and developing LPCOpen applications from versioned LPCOpen releases. The intention of this document is to reduce change impact due to LPCopen updates and make projects that are not released as a part of the LPCOpen tree work better with LPCOpen.
This topic applies to v2.x LPCOpen releases only. Chnages between v1.x and v2.x release are substantial and impact LPCOpen structure, driver APIs, projects, and much more.
In LPCOpen v2.x releases, most changes are related to bug fixes, improvements, enhacements, driver additions, and new examples/projects.
Low impact common changes are in the list below. Low impact changes usually don't affect an application developed with LPCOpen.
We avoid high impact changes if at all possible, but sometimes they are needed.
Versioned LPCOpen releases are internally based on the core LPCOpen code and is internally versioned inside NXP. Public releases are based on this core, but are tied to specific platforms. It is possible for a v2.07 release to be based on one device and platform, and then a v2.08 release to apply to a different platform entirely. This means that only specific versions of LPCopen apply to any one device or platform.
For example, LPC11xx releases on the LPC11xx LPCOpen page currently show release versions v2.00a, v2.04, and v2.06 for different LPC11xx platforms. This can be confusing, but you can always get a versioned history of LPCOpen for a specific device with changes per version on the version history page. The version history page can be found by clicking on the history link for a release on the LPCOpen download pages.
With the topics above in mind, here are some guidelines to help reduce impact due to updating you application to a later version of LPCOpen.
If you make change to drivers code or example code, you need to keep track of what you changed. If you want to keep these changes when you update to a later version of LPCOpen, you'll need to manually reapply the changes. If you make lots of changes to the LPCOpen core code (chip library), we recommend using a version control system such as GIT or SVN to manage the changes, generate patches, and then reapply those changes to an updated LPCOpen release.
If you do your own board layer code and you are using the LPCOPen examples with your board, use an existing board layer area without changing it's name. For example, use the 'nxp_lpcxpresso_1549' board area for your new board by simply updating the files in that directory with your board specific code. When you get a new version of LPCOpen, all the examples will already be configured for that board path and library name, so you don't have to manually change each example project to your specific board name and path.
LPCOpen projects paths can sometimes get very large and come very close to reaching the 255 character Windows limit. Installing LPCopen close to the root directory on your development machine will help reduce problems with very long paths. The problems usually appear as missing header or library files.
We recommend installation at "C:\nxp\lpcopen".
Develop your application at the same folder level as LPCopen and relative paths to the LPCOpen files. All LPCopen projects use this apporach. If you develop your projects using this apporach, you can simply move your current LPCOpen tree and drop in an updated one at the previous location and things should work.
We recommend installation at "C:\nxp\lpcapps".
The chip and board layer code include projects files for Keil, IAR, and LPCXpresso to generate chip abd board libraries. For Keil and IAR, these project files are included in the chip and board layer areas. Use these projects files and the generated libraries instead of individual files in the chip and board areas.
This will reduce impact due to chip and board layer file additions, file renames, file removal, etc.
The included files in chip.h and board.h can sometimes change between versions as files as added, removed, or renamed. If you include these files in your application instead of the specific include files, you'll get the include file changes on an LPCopen update.
This will reduce impact due to changes in include files.