Available services, The comms channels, Console and debugging channels – Comtrol eCos User Manual
Page 314: Mangling

Chapter 11. Porting Guide
Con: The layer of indirection is another point of failure.
The concern primarily being that of vectors being trashed by rogue writes from bad code, causing a complete
loss of the service and possibly a crash. But this does not differ much from a rogue write to anywhere else in
the address space which could cause the same amount of mayhem. But it is arguably an additional point of
failure for the service in question.
Con: All the indirection stuff makes it harder to bring a HAL up
This is a valid concern. However, seeing as most of the code in question is shared between all HALs and
should remain unchanged over time, the risk of it being broken when a new HAL is being worked on should
be minimal.
When starting a new port, be sure to implement the HAL IO drivers according to the scheme used in other
drivers, and there should be no problem.
However, it is still possible to circumvent the vectors if they are suspect of causing problems: simply change
the HAL_DIAG_INIT and HAL_DIAG_WRITE_CHAR macros to use the raw IO functions.
Available services
The
hal_if.h
file in the common HAL defines the complete list of available services. A few worth mentioning in
particular:
•
COMMS services. All HAL IO happens via the communication channels.
•
uS delay. Fine granularity (busy wait) delay function.
•
Reset. Allows a software initiated reset of the board.
The COMMS channels
As all HAL IO happens via the COMMS channels these deserve to be described in a little more detail. In particular
the controls of where diagnostic output is routed and how it is treated to allow for display in debuggers.
Console and Debugging Channels
There are two COMMS channels - one for console IO and one for debugging IO. They can be individually config-
ured to use any of the actual IO ports (serial or Ethernet) available on the platform.
The console channel is used for any IO initiated by calling the
diag_*()
functions. Note that these should only be
used during development for debugging, assertion and possibly tracing messages. All proper IO should happen via
proper devices. This means it should be possible to remove the HAL device drivers from production configurations
where assertions are disabled.
The debugging channel is used for communication between the debugger and the stub which remotely controls the
target for the debugger (the stub runs on the target). This usually happens via some protocol, encoding commands
and replies in some suitable form.
210