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 initialization 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 implementation. 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.
