CYGPKG_HAL
Dummy
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.
CYGPKG_HAL_COMMON
Dummy
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.
CYGFUN_HAL_COMMON_KERNEL_SUPPORT
Boolean
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.
CYGPKG_HAL_COMMON_INTERRUPTS
Dummy
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.
CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK
Boolean
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.
CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE
Count
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.
CYGSEM_HAL_COMMON_INTERRUPTS_ALLOW_NESTING
Boolean
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 reenable 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.
CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT
Boolean
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.
CYGIMP_HAL_COMMON_INTERRUPTS_CHAIN
Boolean
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.
CYGPKG_HAL_COMMON_CONTEXT
Dummy
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.
CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM
Boolean
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.
CYGPKG_HAL_EXCEPTIONS
Boolean
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 behaviour of the system is undefined.