Comtrol eCos - Manual (Page 347)

Chapter 11. Porting Guide
function pointers between labels __CTOR_LIST__ and __CTOR_END__ which must called in order from the
top down. Generally, this function can be copied directly from an existing architecture HAL.
• Bit indexing functions. If the macros HAL_LSBIT_INDEX() and HAL_MSBIT_INDEX() are defined as func-
tion calls, then the functions should appear here. The main reason for doing this is that the architecture does
not have support for bit indexing and these functions must provide the functionality by conventional means.
While the trivial implementation is a simple for loop, it is expensive and non-deterministic. Better, constant
time, implementations can be found in several HALs (MIPS for example).
• hal_delay_us() . If the macro HAL_DELAY_US() is defined in hal_intr.h then it should be defined
to call this function. While most of the time this function is called with very small values, occasionally
(particularly in some ethernet drivers) it is called with values of several seconds. Hence the function should
take care to avoid overflow in any calculations.
• hal_idle_thread_action() . This function is called from the idle thread via the
HAL_IDLE_THREAD_ACTION() macro, if so defined. While normally this function does nothing, during
development this is often a good place to report various important system parameters on LCDs, LED or
other displays. This function can also monitor system state and report any anomalies. If the architecture
supports a
halt instruction then this is a good place to put an inline assembly fragment to execute it. It is
also a good place to handle any power saving activity.
9. Create the < architecture > .ld file. While this file may need to be moved to the variant HAL in the future,
it should initially be defined here, and only moved if necessary.
This file defines a set of macros that are used by the platform .ldi files to generate linker scripts. Most
GCC toolchains are very similar so the correct approach is to copy the file from an existing architecture and
edit it. The main things that will need editing are the
OUTPUT_FORMAT() directive and maybe the creation or
allocation of extra sections to various macros. Running the target linker with just the --verbose argument
will cause it to output its default linker script. This can be compared with the .ld file and appropriate edits
made.
10. If GDB stubs are to be supported in RedBoot or eCos, then support must be included for these. The most
important of these are include/ < architecture > -stub.h and src/ < architecture > -stub.c . In all ex-
isting architecture HALs these files, and any support files they need, have been derived from files supplied in
libgloss , as part of the GDB toolchain package. If this is a totally new architecture, this may not have been
done, and they must be created from scratch.
include/ < architecture > -stub.h contains definitions that are used by the GDB stubs to describe the
size, type, number and names of CPU registers. This information is usually found in the GDB support files for
the architecture. It also contains prototypes for the functions exported by
src/ < architecture > -stub.c ;
however, since this is common to all architectures, it can be copied from some other HAL.
src/ < architecture > -stub.c implements the functions exported by the header. Most of this is fairly
straight forward: the implementation in existing HALs should show exactly what needs to be done. The only
complex part is the support for single-stepping. This is used a lot by GDB, so it cannot be avoided. If the
architecture has support for a trace or single-step trap then that can be used for this purpose. If it does not
then this must be simulated by planting a breakpoint in the next instruction. This can be quite involved since
it requires some analysis of the current instruction plus the state of the CPU to determine where execution is
going to go next.
243