Components

Header file

The S32 SDK contains a device-specific header files which provide direct access to the peripheral registers. Each supported device in S32 SDK has an overall System-on-Chip (SoC) memory-mapped header file. This header file contains the memory map and register base address for each peripheral and the IRQ vector table with associated vector numbers.

Feature Header File

The PAL is designed to be reusable regardless of the peripheral configuration differences from one SOC device to another. An overall Peripheral Feature Header File is provided for device to define the feature or configuration differences for each SOC sub-family device.

Peripheral Abstraction Layer

The PAL provides unified interfaces for families of peripherals, allowing for cross-platform compatibility of application code. The main goal is to provide an application programming interface that is independent of the underlying peripheral implementation.

The PAL supports all instances of each peripheral from a certain family instantiated on the SOC by using a simple integer parameter for the peripheral instance number.

The PAL instances should be configured bearing in mind possible limitations of the underlying peripherals - some features may not be supported on some hardware modules. It is the user's responsibility to correctly handle hardware resources, especially when porting the application to a different platform.

The PAL drivers can be found in the platform/pal directory.

Peripheral Drivers

The Peripheral Drivers are high-level drivers that implement high-level logic transactions based on an internal register access abstraction layer, other Peripheral Drivers, and/or System Services. For example, the UART register access abstraction layer mainly focuses on byte-level basic functional primitives, while the UART Peripheral Driver operates on an interrupt-driven level using data buffers to transfer a stream of bytes. In general, if a driver, that is mainly based on one peripheral, interfaces with functions beyond the register access abstraction layer and/or requires interrupt servicing, the driver is considered a high-level Peripheral Driver.

The Peripheral Drivers support all instances of each peripheral instantiated on the SOC by using a simple integer parameter for the peripheral instance number.The user of the Peripheral Driver does not need to know the peripheral memory-mapped base address.

The Peripheral Drivers operate on a high-level logic that requires data storage for internal operation context handling. However, the Peripheral Drivers do not allocate this memory space. Rather, the user passes in the memory for the driver internal operation through the driver initialization function.

The Peripheral Drivers are designed to handle the entire functionality for a targeted use-case. An application should be able to use only the Peripheral Driver to accomplish its purpose.

The Peripheral Drivers can be found in the platform/drivers directory.

System Services

The System Services contain a set of software entities that can be used by the Peripheral Drivers. They may be used with PAL Drivers to build the Peripheral Drivers or they can be used by an application directly. The following sections describe each of the System Services software entities. These System Services are in the platform/drivers directory.

Interrupt Manager

The Interrupt Manager provides functions to enable and disable individual interrupts within the Nested Vector Interrupt Controller (NVIC). It also provides functions to enable and disable the ARM core global interrupt (via the CPSIE and CPSID instructions) for bare-metal critical section implementation. In addition to providing functions for interrupt enabling and disabling, the Interrupt Manager provides Interrupt Service Routine (ISR) registration that allows the application software to register or replace the interrupt handler for a specified IRQ vector. The drivers do not set interrupt priorities. The interrupt priority scheme is entirely determined by the specific application logic and its setting is handled by the user application. The user application manages the interrupt priorities.

Clock Manager

The Clock Manager provides centralized clock-related functions for the entire system. It can dynamically set the system clock and perform clock gating/un-gating for specific peripherals. The Clock Manager also maintains knowledge of the clock sources required for each peripheral and provides functions to obtain the clock frequency for each supported clock used by the peripheral. The Clock Manager provides a notification framework which the software components, such as drivers, uses to register callback functions and execute the predefined code flow during the clock mode transition.

Power Manager

The Power Manager provides centralized power-related functions for the entire system. It dynamically sets the system power mode. The Power Manager provides a notification framework which the software components, such as drivers, uses to register callback functions and execute the predefined code flow during the power mode transition.

Examples

The examples provided show how to build user applications using the S32 SDK. The examples can be found in the top-level example directory. For details please see Examples and Demos .