What is the best way to develop with LPCopen to avoid change impact to LPCopen version updates?

[lpcware-support]

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.

What can and can't change in LPCOpen releases?

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.

• Bug fixes in individual examples, chip and board layer code.
• Improvements to projects and code, occasional project tweaks (ie, updating project files for a later version of a tool chain), improving an examples functionality.
• Enhancements include additional driver functions without breaking existing driver APIs or functions that didn't exist the the previous driver
• Driver additions include new drivers not released in previous releases - these include drivers such as the IAP driver, EEPROM driver, stopwatch driver, new common or board drivers, etc.
• New examples/projects are always being added to LPCOpen. Because a lot of the devices have similar peripherals, examples written for one device or platform usually get ported over to the other platforms.

Uncommon high impact LPCOpen changes

We avoid high impact changes if at all possible, but sometimes they are needed.

• Driver API changes. Changes that affect a software API are not common, but in rare cases, they do happen. Driver API changes can happen due to standardizing the driver among multiple device families. In most cases, driver API changes will be avoided - if an API needs to be redesigned for a specific peripheral, a new driver is usually developed without removing the old driver. When this happens, the driver code in the chip library may get shuffled some - file name changes, new files, APIs moved between files, etc. - but the original driver should still work.
• Standard based changes that break something. Although we hate to admit it, sometimes we do something that can break something in one or more LPCOpen projects. If this happens, the issue will appear at some point on the known issues list for the device or platform.
• Project changes. We try to avoid these. Some project changes have occurred in the past that have had some minimal impact on users. An example change that has occurred in the past is a library name changes for LPCXpresso. Because the name changed, an existing LPCXPresso project imported into the new LPCOpen workspace would not find the old library name. In cases like this, the imported project needs to be updated with the correct information.
• It is common for chip and board layer code to change - sometimes significantly - between releases. Files may be renamed, added, or removed. Functions may be moved around in files, etc. Although this is ahigh impact change, you can avoid this impact by using the preconfigured chip library projects to generate the chip and board libraries.

Where can I learn about changes between several LPCOpen releases?

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.

Guidelines for development with LPCopen

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.

Keep track of your changes

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.

Use an existing board layer to save time

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.

Windows users: Install LPCOpen close to the root directory!

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 relative to the LPCOpen tree

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".

Use and pre-built chip and board layer projects and libraries

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.

Include chip.h or board.h instead of individual chip and board layer include files

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.