Overview

This section covers any remaining items of note related to the LPC2xxx variant support, not covered in previous sections.

LEDs

If a platform port has support for display values on LEDs, that support is standardised to be accessible from C with the following function:

#include <cyg/infra/hal_diag.h>
extern void hal_diag_led(int leds);

PLL configuration

CDL variables related to the PLL configuration are standardised across LPC2xxx implementations. The platform HAL must provide the input oscillator frequency (CYGNUM_HAL_ARM_LPC2XXX_OSC_FREQ), as well as the desired PLL multipliers and dividers selected by the user and relevant for the chosen part (CYGNUM_HAL_ARM_LPC2XXX_PLL_MULTIPLIER and CYGNUM_HAL_ARM_LPC2XXX_PLL_DIVIDER). It must also supply the VPB divider (CYGNUM_HAL_ARM_LPC2XXX_VPB_DIVIDER) which divides down the core clock (CCLK) to generate the peripheral clock (PCLK). Where applicable a platform may also define a CCLK divider (CYGNUM_HAL_ARM_LPC2XXX_CCLK_DIVIDER).

As a result, the variant HAL calculates CDL options for the absolute values of CCLK (CYGNUM_HAL_ARM_LPC2XXX_CCLK_SPEED) and PCLK (CYGNUM_HAL_ARM_LPC2XXX_PCLK_SPEED) which are exported to the rest of the system, and accessible to applications from <pkgconf/hal.h>.

It is still the responsibility of the platform HAL to initialize the PLL, although assembler helper macros are provided in <cyg/hal/var_io.h to ease implementation.

LPC2xxx definitions

The LPC2xxx variant HAL port includes the header file var_io.h which provides useful register definitions used by eCos, but can also be freely used by applications. It includes register definitions for subsystems unused by eCos.

It may be found in the include/cyg/hal directory relative to your configuration's install tree, or alternatively in the source repository at hal/arm/lpc2xxx/var/VERSION/include/var_io.h. However it should be properly included by applications by using:

#include <cyg/hal/hal_io.h>

This will allow for platform HALs to augment or override any relevant definitions.

Power control

The kernel idle thread is scheduled to run when the system has no other tasks able to run. The idle thread can call a HAL supplied macro to place the chip into an appropriate power saving mode instead of just going around a busy loop. The LPC2xxx variant HAL defines the HAL_IDLE_THREAD_ACTION macro to use the LPC2xxx power control support to place the chip into IDLE mode which will stop the processor clock, without disabling the on-chip peripherals. This state continues until an interrupt is received. This mode has no deleterious effect on program execution, however it has been known to interfere with JTAG/ICE hardware debuggers. Therefore the CDL option CYGIMP_HAL_ARM_LPC2XXX_IDLE_THREAD_USES_IDLE exists in the variant HAL to ensure the processor does not enter the idle mode from the idle thread. It is recommended this option be disabled if hardware debugging solutions are used, especially if reliability is erratic.

Unless specified otherwise by the platform HAL port, no other power saving features are used and no peripherals are disabled, even those unsupported by the eCos LPC2xxx variant port. Therefore if the application wishes to conserve power it is its responsibility to place the relevant peripherals into power down modes.

Memory Acceleration Module support

The variant HAL supplies helper macros to the platform HALs to centralise initialisation code for common subsystems, including the Memory Acceleration Module (MAM).

However it is known that there are errata which affect the MAM, and specifically restrict what mode the MAM should operate in. In some cases, such as the LPC2148, there are conflicting errata, that recommend that the MAM be used only in Full mode in some cases to avoid one erratum, or only Partial mode in others to avoid a different erratum.

Therefore the choice of MAM mode is left to the user and can be set with the CDL option CYGHWR_HAL_ARM_LPC2XXX_MAM_MODE in the variant HAL.

Virtual Vector support

As described in the common HAL documentation, virtual vectors are used to abstract certain services which could be shared between a resident ROM monitor, and an application. In the case where an application is entirely stand-alone, and does not use any resident ROM monitor - for example, if it is itself a ROM application - then virtual vector support is unnecessary.

The CDL configuration option CYGFUN_HAL_LPC2XXX_VIRTUAL_VECTOR_SUPPORT can be used to control the presence of virtual vectors, although it is expected that the default value will be selected appropriately in any case. Disabling virtual vector support can save both Flash and RAM use, which can be important for targets with restricted memory.