About DMP data acquisition model and a suggestion for improving real-time robustness

[Dreams-Possible]

Please ask your question

About DMP data acquisition model and a suggestion for improving real-time robustness

Hi, first of all, thank you very much for this excellent driver and DMP integration.

I noticed that the example application seems to assume a non-real-time usage model: the host periodically reads a batch of DMP data manually. In my experience, this approach has relatively low robustness, because the DMP output rate becomes tightly coupled to the host polling frequency. Since there is no clock synchronization between them, FIFO overflow or empty reads are almost inevitable after running for some time. This significantly affects both FIFO stability and real-time performance.

Moreover, in many real applications, users mainly care about attitude angles (pitch/roll/yaw). One of the main purposes of using DMP is to offload computationally expensive attitude estimation and filtering from the MCU. This also means that most intermediate data (raw accel/gyro, etc.) will not be processed again by the MCU, so these values lose much of their practical meaning.

Given that interrupts are already used, I was wondering: why not read DMP in the interrupt callback receive_callback()?

For example: by enabling the DMP interrupt

#define MPU6050_DMP_DEFAULT_INTERRUPT_DMP MPU6050_BOOL_TRUE /**< enable dmp */

typedef struct mpu6050_api_data_t
{
    // Others…
    float pitch;
    float roll;
    float yaw;
} mpu6050_api_data_t;

static mpu6050_api_data_t mpu6050_api_data = {0};

// Others…

static void receive_callback(uint8_t type)
{
    int16_t accel_raw[1][3] = {0};
    float accel_g[1][3] = {0};
    int16_t gyro_raw[1][3] = {0};
    float gyro_dps[1][3] = {0};
    int32_t quat[1][4] = {0};
    uint16_t l = 1;

    switch(type)
    {
        case MPU6050_INTERRUPT_DMP:
        {
            mpu6050_dmp_read_all(accel_raw,
                                 accel_g,
                                 gyro_raw,
                                 gyro_dps,
                                 quat,
                                 &mpu6050_api_data.pitch,
                                 &mpu6050_api_data.roll,
                                 &mpu6050_api_data.yaw,
                                 &l);
            break;
        }
        // Others…
    }
}

With this approach, the application always consumes only the latest frame, while guaranteeing real-time behavior and much better robustness.

I understand that this effectively binds DMA mode with interrupt usage, but overall I believe the benefits outweigh the drawbacks. Since this goes beyond a simple example and is closer to real engineering requirements—and would also break the current example structure—I decided to raise it here as a question/suggestion rather than modifying the demo directly.

Additional context

Appreciation

Before that, I must express my sincere gratitude for your work.

Thanks to this driver, I was able to use the MPU6050 in its “full form” for the first time: with features comparable to modern IMUs, including certain state detections and highly accurate, stable attitude angles. In practice, pitch/roll/yaw obtained directly from DMP are usually more precise, have lower bias, and free the MCU from heavy computation.

Because of the complexity of DMP configuration, this was almost unimaginable for me before. You also provide an easy-to-port, platform-agnostic API, which decouples the driver from specific ecosystems (such as Arduino) and allows me to use it conveniently on other MCUs like ESP32 and STM32.

Best wishes, and thank you again.

(I am not a native English speaker. This text was translated with the help of AI—please let me know if anything is unclear or ambiguous.)