Skip to content

Cleanup retry logic in I2C drivers, implement better retries in main event polling loop, remove delays, possibly return NaNs #588

Open
@tyeth

Description

@tyeth

A few of the sensors are more unreliable than most.
They fail before a data read and return false.
The firmware then loops over the event polling code again and detects the sensor is still overdue.
This repeats.
If they failed forever, then the code is basically in a tight loop polling the sensor indefinitely. The serial monitor can become flooded (along with the UI if available, but so far the main issue is around whether to retry inside the driver).

A few of the I2C drivers retry the data read inside the driver code to ensure the user's best chance of recording their desired data.

This deviates from the idea of being a short rapid interrupt-like method to fetch the data by using delays between read attempts.

In an ideal world they would quickly fail, and the main event loop would retry them a sensible number of times before marking the event as passed and updating the next poll time.

It's possible we may want to send a NaN in this situation (although the current thinking is NaN means something specific - i.e. that a target is not currently in the area for a proximity sensor), or bubble up another kind of error / msg to the IO website and accept the sensor data read event returned unsuccessfully.

Again there is a fair bit of code repetition for retries, and the main thing that came up was trying to monitor the millis while checking the result of a conditional, a possible rollover situation, which leads to a horrific looking for loop with the main execution block indistinguishable from the conditions (VL53L4CX development #564 ).
It was an interesting excercise to explore the idea of a RETRY_UNTIL_TIMEOUT macro, but unnecessary if we fix the main event loop to retry more efficiently. For posterity: https://chatgpt.com/share/b760dd1d-5bdf-4f5d-b3ae-ec762eab6207

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions