Chapter 15. Package: eCos HAL

Table of Contents
Component: Platform-independent HAL options
Component: Source-level debugging support
Package: ARM architecture
Package: i386 architecture
Package: MN10300 architecture
Package: PowerPC architecture
Package: SPARClite architecture
Package: TX39 architecture

Macro name

CYGPKG_HAL

Type

Dummy

Description

The eCos HAL package provide a porting layer for higher-level parts of the system such as the kernel and the C library. Each installation should have HAL packages for one or more architectures, and for each architecture there may be one or more supported platforms. It is necessary to select one target architecture and one platform for that architecture. There are also a number of configuration options that are common to all HAL packages.

Component: Platform-independent HAL options

Macro name

CYGPKG_HAL_COMMON

Type

Dummy

Description

A number of configuration options are common to most or all HAL packages, for example options controlling how much state should be saved during a context switch. The implementations of these options will vary from architecture to architecture.

Option: Provide eCos kernel support

Macro name

CYGFUN_HAL_COMMON_KERNEL_SUPPORT

Type

Boolean

Description

The HAL can be configured to either support the full eCos kernel, or to support only very simple applications which do not require a full kernel. If kernel support is not required then some of the startup, exception, and interrupt handling code can be eliminated.

Component: HAL interrupt handling

Macro name

CYGPKG_HAL_COMMON_INTERRUPTS

Type

Dummy

Description

A number of configuration options related to interrupt handling are common to most or all HAL packages, even though the implementations will vary from architecture to architecture.

Option: Use separate stack for interrupts

Macro name

CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK

Type

Boolean

Description

When an interrupt occurs this interrupt can be handled either on the current stack or on a separate stack maintained by the HAL. Using a separate stack requires a small number of extra instructions in the interrupt handling code, but it has the advantage that it is no longer necessary to allow extra space in every thread stack for the interrupt handlers. The amount of extra space required depends on the interrupt handlers that are being used.

Option: Interrupt stack size

Macro name

CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE

Type

Count

Description

This configuration option specifies the stack size in bytes for the interrupt stack. Typically this should be a multiple of 16, but the exact requirements will vary from architecture to architecture. The interrupt stack serves two separate purposes. It is used as the stack during system initialization. In addition, if the interrupt system is configured to use a separate stack then all interrupts will be processed on this stack. The exact memory requirements will vary from application to application, and will depend heavily on whether or not other interrupt-related options, for example nested interrupts, are enabled.

Option: Allow nested interrupts

Macro name

CYGSEM_HAL_COMMON_INTERRUPTS_ALLOW_NESTING

Type

Boolean

Description

When an interrupt occurs the HAL interrupt handling code can either leave interrupts disabled for the duration of the interrupt handling code, or by doing some extra work it can re-enable interrupts before invoking the interrupt handler and thus allow nested interrupts to happen. If all the interrupt handlers being used are small and do not involve any loops then it is usually better to disallow nested interrupts. However if any of the interrupt handlers are more complicated than nested interrupts will usually be required.

Option: Save minimum context on interrupt

Macro name

CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT

Type

Boolean

Description

The HAL interrupt handling code can exploit the calling conventions defined for a given architecture to reduce the amount of state that has to be saved. Generally this improves performance and reduces code size. However it can make source-level debugging more difficult.

Option: Chain all interrupts together

Macro name

CYGIMP_HAL_COMMON_INTERRUPTS_CHAIN

Type

Boolean

Description

Interrupts can be attached to vectors either singly, or be chained together. The latter is necessary if there is no way of discovering which device has interrupted without inspecting the device itself. It can also reduce the amount of RAM needed for interrupt decoding tables and code.

Component: HAL context switch support

Macro name

CYGPKG_HAL_COMMON_CONTEXT

Type

Dummy

Description

A number of configuration options related to thread contexts are common to most or all HAL packages, even though the implementations will vary from architecture to architecture.

Option: Use minimum thread context

Macro name

CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM

Type

Boolean

Description

The thread context switch code can exploit the calling conventions defined for a given architecture to reduce the amount of state that has to be saved during a context switch. Generally this improves performance and reduces code size. However it can make source-level debugging more difficult.

Option: HAL exception support

Macro name

CYGPKG_HAL_EXCEPTIONS

Type

Boolean

Description

When a processor exception occurs, for example an attempt to execute an illegal instruction or to perform a divide by zero, this exception may be handled in a number of different ways. If the target system has gdb support then typically the exception will be handled by gdb code. Otherwise if the HAL exception support is enabled then the HAL will invoke a routine deliver_exception(). Typically this routine will be provided by the eCos kernel, but it is possible for application code to provide its own implementation. If the HAL exception support is not enabled and a processor exception occurs then the behavior of the system is undefined.

Option: Stop calling constructors early

Macro name

CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG

Type

Boolean

Description

This option supports environments where some constructors must be run in the context of a thread rather than at simple system startup time. A boolean flag named cyg_hal_stop_constructors is set to 1 when constructors should no longer be invoked. It is up to some other package to deal with the rest of the constructors. In the current version this is only possible with the C library.