SHT40AD1B Part Drivers Documentation

This page presents an overview of the SHT40AD1B Part Drivers.

A detailed API documentation is also available here: SHT40AD1B Part Drivers API Documentation - Core.

Introduction

The SHT40AD1B part driver provides APIs to drive SHT40AD1B components. The SHT40AD1B is a digital humidity and temperature sensor designed for compact, battery-powered, and high-volume applications. Its implementation is based on HAL drivers.

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 into 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; they are not meant to be used directly by the application 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:

  • “i2c”: based on the HAL I2C.

Programming model

Folder structure

The driver’s folder structure is as follows: 

sht40ad1b
  |- interfaces
  |   |- custom
  |   |   |- sht40ad1b_io.c
  |   |   |- sht40ad1b_io.h
  |   |- i2c
  |   |   |- sht40ad1b_io.c
  |   |   |- sht40ad1b_io.h
  |- sht40ad1b.c
  |- sht40ad1b.h

The Core layer is implemented in sht40ad1b.c and sht40ad1b.h. IO interfaces are implemented in subfolders of sht40ad1b/interfaces/, in files named sht40ad1b_io.c and sht40ad1b_io.h.

Usage and initialization

The main data structure for this driver is the sht40ad1b_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. However, unlike HAL drivers, the user application has full ownership of the data structures used by the part driver. It is its duty to ensure timely allocation and deallocation.

The IO interface has its own “object” structure, sht40ad1b_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 for the resources (pin modes, I2C address, …) are not enforced by the part driver but must be respected to ensure proper functionality. One of the purposes of CubeMX’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_sht40ad1b.c and mx_sht40ad1b.h. These files contain an implementation of sht40ad1b_io_init(), which is called by the SHT40AD1B driver during initialization (inside sht40ad1b_drv_init()) to initialize the sht40ad1b_io_t structure. The function uses an ID stored in the sht40ad1b_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 sht40ad1b_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 I2C IO interface, the following parameters are available:

  • I2C handle to use

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

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

  • I2C handle configured in polling mode

Sequence Diagrams

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

simple use case for this driver

Dependencies

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

partitioning of this driver into components

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

inclusion graph of this driver