Loading and Unloading the Package

The H8/300 architectural HAL package CYGPKG_HAL_H8300 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.

Stacks

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 cyg_start 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 startup stack.

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 CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK. 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 following scenarios:

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.

Other Options

The H8/300 architectural HAL package does not define any other configuration options that can be manipulated by the user.