sht4x - Fix sporadic measurement errors by applying TIME_TO_TICKS() m… #632
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…acro from SHT3x driver to ensure the delay time is at least 1 more tick than desired
Replace pdMS_TO_TICKS() with TIME_TO_TICKS().
FreeRTOS vTaskDelay() (https://www.freertos.org/a00127.html) does NOT guarantee that the delay time is at least the ticks specified, relative to time.
The SHT4x has timing constraints that are required to be followed for the part to be ready to respond. In the case where the delay was 10ms and the FreeRTOS tick time is 10ms vTaskDelay(1) was being called. Measurement via oscilloscope confirmed that most of the time the delay was 10ms + 2-5ms, but sometimes it was 6ms or 7ms.
In the cases where the delay was <10ms, the SHT4x would not respond to the 'read measurement' phase of taking a measurement, resulting in i2cdev logging an error, and the measurement call failing.