Available services, The comms channels, Console and debugging channels – Comtrol eCos User Manual

Page 314: Mangling

Advertising
background image

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

Advertising