M95P32 Part Driver Documentation

This page presents an overview of the M95P32 part driver.

A detailed API documentation is also available here: M95P32 Part Driver API Documentation - Core.

Introduction

The M95P32 part driver provides APIs to drive m95p32 components. Its implementation is based on the HAL. It offers a higher level of abstraction than the HAL, with features supporting read and write operations of the EEPROM memory.

This driver is delivered as an OpenCMSIS pack. The structure of the pack and its usage are described in the following section.

Principles

This driver is split in two layers:

• a “Core” layer containing the high-level algorithms, type definitions and APIs;

• “IO” interface(s) that build a basic level of abstraction between HAL drivers and the Core layer.

The scope of the IO interfaces is strictly internal; it is not meant to be directly used by the applicative code. However, users might develop their own IO interface in order to adapt this driver to a custom environment (non-HAL, mixed HALs…).

The Core layer is implemented as a single component. Each IO interface is another component. This structure enhances the composability and reusability of the driver in various use cases.

Note: The I/O interfaces are mutually exclusive: only one can be used in a software project.

The IO interfaces currently implemented are:

• “spi”: based on the HAL SPI.

Programming model

Folder structure

The driver’s folder structure is as follows:

m95p32
  |- interfaces
  |   |- spi
  |   |   |- m95p32_io.c
  |   |   |- m95p32_io.h
  |- m95p32.c
  |- m95p32.h

The Core layer is implemented in m95p32.c, m95p32.h. IO interfaces are implemented in subfolders of m95p32/interfaces/spi, in files named m95p32_io.c, m95p32_io.h.

Usage and initialization

The main data structure for this driver is the m95p32_obj_t “object” structure, which contains all the internal state needed by the Core. The user application never needs to access that structure’s fields directly.

The IO interface has its own “object” structure, m95p32_io_t, to store its own specific state. The layout of that structure is specific to each IO interface, as it is linked to the underlying (HAL) driver being used.

At initialization, the resources used by the part driver must be initialized separately by the user application, optionally relying on STM32CubeMX2 generated code. The requirements on the resources (pin modes, SPI, …) are not enforced by the part driver but must be respected to ensure proper functionality. One of the purposes of STM32CubeMX2’s project generation is to assist in this regard. Once all the required resources (HAL instances) are properly initialized, the part driver initialization may be called and given those resources.

STM32CubeMX2 configuration and code generation

STM32CubeMX2 generates two files, mx_m95p32.c and mx_m95p32.h. These files contain an implementation of m95p32_io_init(), which is called by the m95p32 driver during initialization (inside m95p32_init()) to initialize m95p32_io_t structure. The function uses an ID stored in the m95p32_io_t structure to discriminate the configuration that will be used. They may also contain macros specifying the value of the various parameters chosen in STM32CubeMX2’s GUI.

Most values used to initialize the m95p32_io_t instances are extracted from the HAL generated init code: mainly mx_hal_def.h.

The specific settings available to users depend on the IO interface that was selected.

For the SPI IO interface, the following parameters are available:

• SPI handle to use

The M95P32 part driver may impose a specific configuration to HAL components in order to guarantee their functionality.

For the SPI IO interface, the following constraints are applied:

• SPI handle configured in polling mode

Sequence Diagrams

The diagram below presents a simple use case for this driver.

Dependencies

The diagram below presents the partitioning of this driver into components.

This components’ structure translates to the following inclusion graph in terms of C code: