Comtrol eCos - Manual (Page 351)

Chapter 12. Future developments
The HAL is not complete, and will evolve and increase over time. Among the intended developments are:
• Common macros for interpreting the contents of a saved machine context. These would allow portable code,
such as debug stubs, to extract such values as the program counter and stack pointer from a state without having
to interpret a HAL_SavedRegisters structure directly.
• Debugging support. Macros to set and clear hardware and software breakpoints. Access to other areas of machine
state may also be supported.
• Static initialization support. The current HAL provides a dynamic interface to things like thread context initial-
ization and ISR attachment. We also need to be able to define the system entirely statically so that it is ready to
go on restart, without needing to run code. This will require extra macros to define these initializations. Such
support may have a consequential effect on the current HAL specification.
• CPU state control. Many CPUs have both kernel and user states. Although it is not intended to run any code in
user state for the foreseeable future, it is possible that this may happen eventually. If this is the case, then some
minor changes may be needed to the current HAL API to accommodate this. These should mostly be extensions,
but minor changes in semantics may also be required.
• Physical memory management. Many embedded systems have multiple memory areas with varying properties
such as base address, size, speed, bus width, cacheability and persistence. An API is needed to support the
discovery of this information about the machine’s physical memory map.
• Memory management control. Some embedded processors have a memory management unit. In some cases
this must be enabled to allow the cache to be controlled, particularly if different regions of memory must have
different caching properties. For some purposes, in some systems, it will be useful to manipulate the MMU
settings dynamically.
• Power management. Macros to access and control any power management mechanisms available on the CPU im-
plementation. These would provide a substrate for a more general power management system that also involved
device drivers and other hardware components.
• Generic serial line macros. Most serial line devices operate in the same way, the only real differences being
exactly which bits in which registers perform the standard functions. It should be possible to develop a set
of HAL macros that provide basic serial line services such as baud rate setting, enabling interrupts, polling for
transmit or receive ready, transmitting and receiving data etc. Given these it should be possible to create a generic
serial line device driver that will allow rapid bootstrapping on any new platform. It may be possible to extend
this mechanism to other device types.
247