Utilities architecture

Utilities are common applicative services designed to factorize and simplify application development. They provide reusable functionality that can be considered as lightweight middleware when based on hardware abstraction layers (see Component-based design).

Utility anatomy

A utility component is structured in two main layers:

  • Utility core: Hardware-agnostic part that manages the main state machine, data flow, and end-user functionalities. It orchestrates data flow between modules if required.

  • Hardware interface: Glue layer that provides access to hardware resources through HAL drivers. The interface layers offer two integration mechanisms:

    • User template: Empty or pseudo-empty template source file that can be copied to the application folder and customized for specific needs.

    • Ready-to-use interfaces: Predefined interfaces provided by the utility pack that link the component with the hardware platform without requiring custom interface code.

Interface patterns

Utilities provide flexible integration through interface patterns, similar to Middleware architecture components.

Interface types

Multiple ready-to-use interface variants can be provided for a single utility component, each optimized for different platforms or use cases:

  • Standalone interfaces: Generic implementation adapted to any hardware or applicative scenario without additional configuration.

  • Configurable interfaces: Require a configuration header file to map specific hardware resources. When using configurable interfaces, configuration files are generated by STM32CubeMX2 in user space.

The user can choose to use a ready-to-use interface instead of customizing a user template. When selecting a ready-to-use interface, it can be used as-is with no user modification.

Utility usage principles

Utilities follow the same two-path usage principle as HAL2-based middleware and part drivers components:

Diagram showing the two-path usage model of middleware, part drivers, utilities components, including the resources initialization path and the services usage path.

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

  1. Resources initialization path: Utility resources are initialized either from system initialization code (can be generated with STM32CubeMX2) or application code. This includes hardware peripherals and any OS resources if the utility supports RTOS integration.

  2. Services usage path: Utility services are invoked by the application using logical instance objects. The utility retrieves initialized resources through dedicated methods.

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

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

Commonalities with other components

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

  • Two-path usage model (initialization and service usage)

  • Interface patterns (user templates and ready-to-use interfaces)

  • Platform-agnostic core with hardware abstraction

  • Software component delivery model