SensorLib C++ Library

repository·master·Indexed 42 days ago

https://github.com/lewisxhe/sensorlib

A multi-platform C++ library providing drivers for over 44 sensor devices across 11 categories, including Touch, PMIC, and IMU. It supports I2C and SPI buses and is designed for use with Arduino, PlatformIO, and ESP-IDF. For ESP-IDF users, it offers multiple driver implementation modes: LL Driver (for ESP-IDF >= 5.0), Legacy Driver (for ESP-IDF < 5.0), and a flexible Read/Write/Hal callback approach.

Tokens
14K
Snippets
36
Records
60
Agent score
53%

What's inside SensorLib

  1. Understand the ESP-IDF Sensor Hub driver implementation modes

    master

    The sensor hub supports different driver implementation patterns depending on your requirements:

    • LL Driver (Low-Level): Direct hardware access for performance.
    • Legacy Driver: Older driver implementation style.
    • Read/Write/Hal Callback: A flexible approach where the driver uses user-provided callback methods for I2C/SPI communication. This is useful for abstraction and compatibility with different hardware abstraction layers (HAL).
  2. Supported BMA456 Variants and Features

    master

    The BMA456 family includes several variants with different feature sets for motion detection and intelligence:

    • BMA456W: Supports any motion, no motion, step detection, step counting, step activity, and single/double tap.
    • BMA456H: Supports all BMA456W features plus auto low power and triple tap.
    • BMA456MM: Supports all BMA456H features plus orientation, high-g, low-g, and significant motion detection.
    • BMA456AN: Supports any motion and no motion.
    • BMA456 tablet: Supports any/no motion, low-g, orientation, and single, double, and triple tap.
  3. Understand BHI260AP sensor initialization and virtual sensor list

    master

    When initializing a BHI260AP or BHA260 sensor, the driver performs a firmware upload to RAM and boots the kernel. Once successful, the sensor exposes a list of 'Virtual Sensors'. These virtual sensors provide processed data (like 'Gravity vector', 'Step counter', or 'Device orientation') rather than raw sensor readings.

    Each virtual sensor in the list is identified by:

    • Sensor ID: The unique identifier used to enable or configure the sensor.
    • Sensor Name: A human-readable description.
    • ID: An internal identifier.
    • Ver: Version.
    • Min/Max rate: The supported sampling frequency range in Hz.

    Example of a virtual sensor list output during initialization:

    Sensor IDSensor NameIDVerMin rateMax rate
    1Accelerometer passthrough205112.5000400.0000
    37Game rotation vector25211.5625400.0000
    50Step detector24811.00001.0000
  4. Driver Implementation Strategies in ESP-IDF Sensor Hub

    master

    The ESP-IDF sensor hub example supports several ways to interface with hardware via sensorlib:

    • LL Driver: Uses low-level driver implementations.
    • Legacy Driver: Uses older driver versions.
    • Read/Write/Hal Callback: Allows you to provide custom callback methods for I2C/SPI communication. This is useful for using higher version APIs (>= 5.0) or custom hardware abstraction layers.

    As seen in the example output, using callback methods is a common way to implement I2C: I (317) I2C: Implemented using read and write callback methods (Use higher version >= 5.0 API)

  5. Use Read/Write/Hal Callbacks for I2C Drivers

    master
    To implement I2C drivers compatible with modern ESP-IDF (>= 5.0), you should use the callback-based approach. Instead of relying on the legacy I2C driver, the sensor library allows you to provide read and write callback methods. This abstraction allows the library to work seamlessly with the i2c_master component in newer ESP-IDF versions.
  6. Configure AXP517 USB-C PD Negotiation

    master

    The AXP517 PMIC supports USB-PD sink negotiation.

    Critical Requirement: PD negotiation is interrupt-driven. You must connect the PMIC_IRQ pin to an MCU GPIO and pass that pin to begin(..., irqPin) or initPdSink(irqPin) before calling requestPd(). Without a valid IRQ pin, the TCPC RX FIFO cannot be serviced and PD voltage requests will fail.

    To request a specific voltage range, use pmic.requestPd(min_mv, max_mv, &caps).

    #include <Wire.h>
    #include "PmicXPowers.hpp"
    
    PmicAXP517 pmic;
    AXP517PdNegotiator::SourceCaps caps;
    
    static constexpr int PMIC_SDA = 3;
    static constexpr int PMIC_SCL = 2;
    static constexpr int PMIC_IRQ = 44; // Must be connected to PMIC_IRQ
    
    void setup() {
        Serial.begin(115200);
    
        if (!pmic.begin(Wire, AXP517_SLAVE_ADDRESS, PMIC_SDA, PMIC_SCL, PMIC_IRQ)) {
            Serial.println("AXP517 or PMIC_IRQ init failed");
            while (1) delay(1000);
        }
    
        if (pmic.requestPd(9000, 6000, &caps)) {
            Serial.println("9V PD contract ready");
        }
    }
  7. Compare LL Driver vs Legacy Driver in ESP-IDF Sensor Hub

    master

    The ESP-IDF Sensor Hub examples demonstrate two different ways to interface with hardware drivers, primarily distinguished by the version of the ESP-IDF I2C driver used:

    1. LL Driver: Uses the modern ESP-IDF I2C API (version >= 5.0). It implements I2C using read and write callback methods. This is the recommended approach for newer ESP-IDF versions.
    2. Legacy Driver: Uses older ESP-IDF I2C drivers (version < 5.0). It is intended for compatibility with older environments but will trigger a warning in newer ESP-IDF versions: W (333) i2c: This driver is an old driver, please migrate your application code to adapt driver/i2c_master.h.

    Both drivers support initializing sensors like the PCF8563 RTC and BMA423 accelerometer.

  8. Use Read/Write/Hal Callbacks for sensor drivers

    master
    You can implement sensor drivers using read and write callback methods. This allows the driver to remain agnostic of the underlying communication protocol (like I2C or SPI) by delegating the actual bus operations to your application's implementation. This pattern is often used to maintain compatibility with older ESP-IDF versions (e.g., using < 5.0 API).
  9. How to use Bosch firmware with BHI260/BHI360

    master

    SensorLib does not include raw Bosch *.fw files. For BHI260/BHI360, the library uses generated firmware headers located in src/bosch/firmware/.

    If you need to use a custom Bosch firmware image, you must convert it to a C/C++ header or a byte array and then pass it to the driver using the setFirmware() method.

  10. Driver implementation modes: LL, Legacy, and Callback

    master

    The sensor hub examples support different driver implementation patterns:

    • LL Driver: Low-level driver implementation.
    • Legacy Driver: Uses older driver patterns.
    • Read/Write/Hal Callback: A flexible approach where you provide custom callback functions for read, write, and HAL (Hardware Abstraction Layer) operations. This is useful when you need to map the library's communication requirements to your specific hardware abstraction layer or custom I2C/SPI implementation.