This section covers any remaining items of note related to the LPC2xxx variant support, not covered in previous sections.
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);
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_DIVIDER). It must also supply
the 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 (
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
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.
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:
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
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
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
CYGHWR_HAL_ARM_LPC2XXX_MAM_MODE in the variant
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.