Loading and Unloading the Package
The H8/300 architectural HAL package
should be loaded automatically when eCos is configured for H8/300-based
target hardware. It should never be necessary to load this package
explicitly. Unloading the package should only happen as a side effect
of switching target hardware.
By default the architectural HAL provides a single block of memory to act as both the startup stack and the interrupt stack. The variant, processor or platform HAL may override this. For example if there are several banks of RAM with different performance characteristics it may be desirable to place the interrupt stack in fast RAM rather than in ordinary RAM.
The assembler startup code sets the stack pointer to the startup stack
before switching to C code. This stack is used for all HAL
initialization, running any C++ static constructors defined either by
eCos or by the application, and the
entry point. In configurations containing the eCos kernel
cyg_start will enable interrupts, activate the
scheduler and threads will then run on their own stacks. In non-kernel
single-threaded applications the whole system continues to run on the
When an interrupt occurs the default behaviour is to switch to a
separate interrupt stack. This behaviour is controlled by the common
HAL configuration option
It reduces the stack requirements of all threads in the system, at the
cost of some extra instructions during interrupt handling. In kernel
configurations the startup stack is no longer used once the scheduler
starts running so its memory can be reused for the interrupt stack. To
handle the possibility of nested interrupts the interrupt handling
code will detect if it is already on the interrupt stack, so in
non-kernel configurations it is also safe to use the same area of
memory for both startup and interrupt stacks. This leads to the
If interrupt stacks are enabled via
CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACKand the interrupt stack is not provided by the variant, processor or platform HAL then a single block of memory will be used for both startup and interrupt stacks. The size of this block is determined by the common HAL configuration option
CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE, with a default value
CYGNUM_HAL_DEFAULT_INTERRUPT_STACK_SIZEprovided by the H8300 architectural HAL.
If the use of an interrupt stack is disabled then the H8/300 architectural HAL will provide just the startup stack, unless this is done by the variant, processor or platform HAL. The size of the startup stack is still controlled by
Otherwise the interrupt and/or startup stacks are provided by other packages and it is up to those packages to provide configuration options for setting the sizes.
SCI Baud Rate
The architecture HAL provides a polled driver for the SCI serial device that is common to all H8/300 implementations. This is used by RedBoot for user interaction and by eCos applications for diagnostic output. Configuration of the device is handled in the variant HAL, but the baud rate is set in the architecture HAL using the CYGNUM_HAL_H8300_SCI_BAUD_RATE option.
Interrupt Vector Hook
The H8/300 architecture does not provide any mechanism for determining the source of an interrupt or exception other than the address of the routine to which control is vectored. Since eCos uses common code for most vectors, and demultiplexes the source later, this makes handling difficult. To overcome this, all interrupt and exception vectors are pointers to entries in a table of single instruction JSR instructions which all call the common handling code. The stacked return address can then be used to synthesize a vector number that is used by the common handling code.
By default this JSR hook table is stored in on-chip RAM (it is actually placed by the platform specific .ldi file). This placement makes this vectoring fast and of minimal impact on performance. It also allows individual vectors to be replaced if desired -- although this functionality is also provided in a more convenient form by the standard eCos VSR table that is also placed in on-chip RAM. If the option CYGSEM_HAL_H8300_VECTOR_HOOK is disabled, then the hook table will be stored in ROM, which will free space in the on-chip RAM but will increase interrupt processing time and remove the ability to revector exceptions at this level (but won't affect the VSR table).
If the option CYGSEM_HAL_H8300_SAVE_STUB_VECTOR is enabled then the vector hook table will be saved by an eCos application before being replaced with its own table. This is theoretically to permit RedBoot to coexist with eCos. In practice the common VSR table mechanism handles this in a more portable manner.
The H8/300 architectural HAL package does not define any other configuration options that can be manipulated by the user.