Middleware architecture ¶

Middleware components are standalone software modules that provide high-level services to applications. They sit on top of the HAL drivers and part drivers, and are delivered as standalone software components including all necessary interfaces (see Component-based design).

Middleware anatomy ¶

A middleware component is structured in multiple layers:

Library core: Kernel of the component that manages the main state machine and orchestrates data flow between modules.
Modules: Common functionality sublayers that can be added or removed individually to customize the middleware configuration.
User templates: Empty or pseudo-empty template files that can be copied to the application folder and customized.
High-level ready-to-use interfaces: Generic applicative code built on middleware services, providing common functionalities in a platform-agnostic manner.
Low-level ready-to-use interfaces: Hardware-specific interfaces targeting generic hardware configurations that can be shared across multiple STM32 series.

Interface patterns ¶

Middleware components provide flexible integration mechanisms through interface patterns. An interface pattern is a ready-to-use implementation that links the middleware component with application code or the hardware platform without requiring custom interface development.

Interface types ¶

The interface layers include both user templates and ready-to-use interfaces:

User template: Template file that must be copied to the application folder and customized by the user, providing maximum flexibility for specific use cases.
Ready-to-use interfaces: Predefined implementations that can be used as-is with no user modification.

Ready-to-use interfaces can be:

Standalone: Generic implementation adapted to any hardware or applicative scenario without additional configuration.
Configurable: Require a configuration header file to map specific hardware resources. Configuration files can be generated using STM32CubeMX2.

Interface selection ¶

Ready-to-use interfaces can be categorized as:

Exclusive: Only one pattern can be selected at a time in the project.
Cooperative: Multiple ready-to-use interfaces can be selected simultaneously in the same project.

When using a ready-to-use pattern, it can be used as-is with no user modification.

Middleware usage principles ¶

The middleware usage follows a two-path principle common to all HAL2-based middleware, utilities and part drivers:

Two-path usage model of middleware, part drivers, utilities components

Resources initialization path: Middleware resources are initialized either from system initialization code (can be generated with STM32CubeMX2) or application code. This includes hardware peripherals, memory allocation, and OS resources if applicable.
Services usage path: Middleware services are invoked by the application using logical instance objects. The middleware retrieves the initialized resources through dedicated methods and uses them to identify physical instances.

This separation of concerns ensures clear responsibility boundaries: the application is fully responsible for the resources management, while the middleware is responsible for the services implementation.

For middleware-specific usage details, refer to the individual middleware component documentation.

Commonalities with other components ¶

Middleware components share common principles with Part drivers architecture and Utilities architecture:

Two-path usage model (initialization and service usage)
Interface patterns (user templates and ready-to-use interfaces)
Platform-agnostic core with hardware abstraction through interfaces
Software component delivery model