Mistake on this page? Email us

Architecture

This section describes the software architecture concepts used by PAL.

Drivers

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

Asynchronous operations use completion callbacks. Callbacks are typically called in the ISR context. Client callback routines are expected to return immediately without blocking.

Non-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.

State

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.

Always Succeeds

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.

Multiple Instances

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.

Important Information for this Arm website

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work.