| LPCOpen Platform v1.03 LPCOpen Platform for NXP LPC Microcontrollers

- Main Page
- Modules
- Data Structures
- Files
- Related Pages

All Data Structures Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
LPCOpen platform design approach and goals

LPCOpen platform design goals
The LPCOpen platform is designed to provide high quality software for supported NXP Cortex devices. The LPCOpen platform code is meant to be flexible so it works on multiple devices with similar IP without sacrificing speed or build size.

The goals of the LPCOpen platform are to:

- Provide a set of common reference drivers can be used across multiple NXP devices
- Reduce or eliminate software fragmenation due to many varying packages with similar code. Changes will be propogated across multiple devices faster and easier.
- Provide well designed and efficient low level drivers that optimally use the device's features
- Provide driver and library examples that work on multiple boards and devices
- Support for multiple toolchains at full optimization levels
- Standardize the NXP code 'look and feel'
- Provide high-quality documentation for LPCOpen code and examples
- Provide better updates across the entire code base
- Provide integrated support for many 3rd party software packages
- Provide a central configuration file that defines how a system is configured

LPCOpen platform layout
The LPCOpen platform design consists of several software components: example code, core code, software packages and libraries, project files, and tools.

LPCOpen platform - example code
Example code consists of simple and complex software applications that demostrate how a driver or peripheral is used. Example groups are provided for each device family. Examples include simple targeted applications for interfaces or peripheral such as the ADC, timers, interrupt control, or Ethernet interface. Examples may also be more complex and use multiple interfaces, protocol stacks (ie, LPCUSBLIB), or use and RTOS (ie, FreeRTOS).

LPCOpen platform - core code
Core code consists of common reference drivers (IP drivers), chip specific drivers, and board layer code.

The common reference drivers are drivers that are shared across multiple devices. All or part of these drivers may be included in chip specific drivers. For example, the same UART reference driver may be used in the 17xx, 18xx, and 43xx devices. Reference drivers usually never deal with the architecture of a specific device, such as clocking or the interrupt handler, as these vary per device and need to be handled as part of the chip specific driver or board layer code. Common reference drivers are also called IP drivers and usually have generic names such as uart_001.c. Whenever possible, reference drivers use INLINE code.

The chip specific drivers handle the implementation of a driver for a interface or peripheral on a specific device family. The chip specific driver may use all or part of the functions from a common reference driver. Chip specific drivers usually handle device implementation details such as clock source and rate, interrupt handling and routing, pin muxing or GPIO control, events, etc. Chip specific drivers usually have generic names such as uart_18xx_43xx.c. Whenever possible, chip specific drivers use inlined reference driver functions to save space.

Board layer code consists of functions for initializing the board at startup, setup code for debug UART output, global platform configuration, various other support functions for examples (as needed).
All startup code used in the examples call the SystemInit() function which is implemented 'per board'. The SystemInit() function sets up system clocking, external memory, pin muxing, an other early system functions prior to the example being started (and prior to image scatter loading and placement).
The board layer provides a common board API that provides a small set of functions that should be implemented for all supported and new boards.
The board layer also provides the configuration used for the entire platform. All code that is built - libraries, board files, chip drivers, examples, etc. - derive it's configuration from the board layer's 'sys_config.h' file. See the section on the 'LPCOpen platform design approach' for more information on the board driven configuration.

LPCOpen platform - Software packages and libraries
Software packages and libraries consists of NXP developed and 3rd party code such FreeRTOS, uC/OS-III, emWin libraries, LPCUSBLUB source code, SWIM source code, etc.

LPCOpen platform - Project files
Scattered through the LPCOpen tree are project files for the supported toolchains. These files are used to setup the projects for the toolchains.

LPCOpen platform - Tools
Support tools that can be used with specific devices are included with LPCOpen. An example of a support tool might be a USB DFU download utility application for the PC. In most cases, a tool won't be here unless it's needed by an example.

LPCOpen platform design approach
The LPCOpen platform builds all code based on a single platform configuration. This configuration file (sys_config.h) is include in all libraries, software, and example code to determine how to code is built. The sys_config.h file is located with the boards files. (See Adding platform definitions using sys_config.h).
At a minimum, the sys_config.h file must defined the CHIP_* definitions used for building the code. This may be CHIP_18XX, CHIP_11XX, or any supported CHIP_* value. A current list of supported CHIP_* definitions can be found in each CHIP's build time option list:
CHIP: LPC8xx Chip driver build time options
CHIP: LPC11xx Chip driver build time options
CHIP: LPC13xx Chip driver build time options
CHIP: LPC17xx/40xx Chip driver build time options
CHIP: LPC18xx/43xx Chip driver build time options

The sys_config.h file may also configure many other options. You can get possible options to set in the sys_config.h file by reviewing the documentation. Drivers that have configurable options will have a 'build option' section in their documentation that explain their possible options.
Examples of how the options are used can be found in the various sys_config.h files for the boards in the LPCOpen platform source tree.