Comtrol eCos - Manual (Page 296)

Chapter 9. HAL Interfaces
in the platform HAL. This file is used by the MLT to manufacture both the .ldi and .h files. Users should beware
that direct edits the either of these files may be overwritten if the MLT is run and regenerates them from the .mlt
file.
The names of the .ldi and .h files are defined by macro definitions in pkgconf/system.h . These are
CYGHWR_MEMORY_LAYOUT_LDI and CYGHWR_MEMORY_LAYOUT_H respectively. While there will be little need for
the application to refer to the .ldi file directly, it may include the .h file as follows:
#include CYGHWR_MEMORY_LAYOUT_H
Diagnostic Support
The HAL provides support for low level diagnostic IO. This is particularly useful during early development as an
aid to bringing up a new platform. Usually this diagnostic channel is a UART or some other serial IO device, but
it may equally be a a memory buffer, a simulator supported output channel, a ROM emulator virtual UART, and
LCD panel, a memory mapped video buffer or any other output device.
HAL_DIAG_INIT() performs any initialization required on the device being used to generate diagnostic output.
This may include, for a UART, setting baud rate, and stop, parity and character bits. For other devices it may
include initializing a controller or establishing contact with a remote device.
HAL_DIAG_WRITE_CHAR(c) writes the character supplied to the diagnostic output device.
HAL_DIAG_READ_CHAR(c) reads a character from the diagnostic device into the supplied variable. This is not
supported for all diagnostic devices.
These macros are defined in the header file cyg/hal/hal_diag.h . This file is usually supplied by the variant or
platform HAL, depending on where the IO device being used is located. For example for on-chip UARTs it would
be in the variant HAL, but for a board-level LCD panel it would be in the platform HAL.
SMP Support
eCos contains support for limited Symmetric Multi-Processing (SMP). This is only available on selected architec-
tures and platforms.
Target Hardware Limitations
To allow a reasonable implementation of SMP, and to reduce the disruption to the existing source base, a number
of assumptions have been made about the features of the target hardware.
• Modest multiprocessing. The typical number of CPUs supported is two to four, with an upper limit around
eight. While there are no inherent limits in the code, hardware and algorithmic limitations will probably become
significant beyond this point.
• SMP synchronization support. The hardware must supply a mechanism to allow software on two CPUs to syn-
chronize. This is normally provided as part of the instruction set in the form of test-and-set, compare-and-swap
or load-link/store-conditional instructions. An alternative approach is the provision of hardware semaphore reg-
192