This section describes the software architecture concepts used by PAL.
PAL is separated into individual drivers typically implementing either:
- peripheral in a SoC (e.g. TWI, UART, etc.)
- components on board (e.g. LED, buttons, etc.)
- devices/IC on board (e.g. audio amplifier, I/O expander, etc.)
Asynchronous operations use completion callbacks. Callbacks are typically called in the ISR context. Client callback routines are expected to return immediately without blocking.
PAL clients expect drivers to return immediately with minimal delay. Driver implementations do not busy wait for an operation to complete. Rather, a callback is used to signal the completion of operations.
Some drivers externally expose state. The state can be used to optionally poll for current operational behavior. State is not needed for valid functional operation by the client. However, polling the driver state can be used for debugging and testing.
Clients expect operations to always succeed and always complete. This allows clients to simplify error handling code paths.
For example, setting LED always succeeds without error. Another example, UART write should not fail and its operation always completes.
A few exceptions exists. For example, the BB driver may fail an operation and inform the client of the failure.
Some peripherals (e.g. UART) may have multiple instantiations in an SoC. Clients will initialize each required instance. An instance ID returned at initialization of the resource is used to distinguish operations between peripheral instances.