Chapter 17. Package: eCos kernel

Table of Contents
Component: Kernel interrupt handling
Component: Exception handling
Component: Kernel schedulers
Component: Counters and clocks
Component: Thread-related options
Component: Synchronization primitives
Component: Kernel instrumentation
Component: Memory allocators
Component: Source-level debugging support
Component: Kernel APIs

Macro name

CYGPKG_KERNEL

Type

Boolean

Description

This package contains the core functionality of the eCos kernel. It relies on functionality provided by various HAL packages and by the eCos infrastructure. In turn the eCos kernel provides support for other packages such as the device drivers and the uITRON compatibility layer.

Component: Kernel interrupt handling

Macro name

CYGPKG_KERNEL_INTERRUPTS

Type

Dummy

Description

The majority of configuration options related to interrupt handling are in the HAL packages, since usually the code has to be platform-specific. There are a number of options provided within the kernel related to slightly higher-level concepts, for example Delayed Service Routines.

Component: Use delayed service routines (DSRs)

Macro name

CYGIMP_KERNEL_INTERRUPTS_DSRS

Type

Boolean

Description

In eCos the recommended way to handle device interrupts is to do a minimum amount of work inside the low level interrupt handler itself, and instead do as much as possible in a Delayed Service Routine or DSR. If an application does not make use of DSRs directly or indirectly then it is possible to disable the DSR support completely, which reduces the overheads of context switches and interrupt handling. Note that the kernel real-time clock makes use of DSRs, as do many of the device drivers.

Option: Use linked lists for DSRs

Macro name

CYGIMP_KERNEL_INTERRUPTS_DSRS_LIST

Type

Radio

Description

When DSR support is enabled the kernel must keep track of all the DSRs that are pending. This information can be kept in a fixed-size table or in a linked list. The list implementation requires that the kernel disable interrupts for a very short period of time outside interrupt handlers, but there is no possibility of a table overflow occurring.

Option: Use fixed-size table for DSRs

Macro name

CYGIMP_KERNEL_INTERRUPTS_DSRS_TABLE

Type

Radio

Description

When DSR support is enabled the kernel must keep track of all the DSRs that are pending. This information can be kept in a fixed-size table or in a linked list. The table implementation involves a very small risk of overflow at run-time if a given interrupt source is able to have more than one pending DSR. However it has the advantage that the kernel does not need to disable interrupts outside interrupt handlers.

Option: Number of entries in fixed-size DSR table

Macro name

CYGNUM_KERNEL_INTERRUPTS_DSRS_TABLE_SIZE

Type

Count

Description

When DSR support is enabled the kernel must keep track of all the DSRs that are pending. One approach involves a fixed-size table, which involves a very small risk of overflow at run-time. By increasing the table size it is possible to reduce this risk.

Option: Chain all interrupts together

Macro name

CYGIMP_KERNEL_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.