In I2C, clock stretching occurs when the controller stops driving SCL
down but the peripheral continues to drive SCL down until the value of
SDA that is expected to be set by the peripheral is ready. This allows a
peripheral to communicate at a high speed but introduce a delay in the
response (like an ACK or read) in some specific situations. Not all I2C
peripherals require I2C stretching, and in many cases SCL is only an
input to these peripherals.
Clock stretching is the only situation where a peripheral may drive down
SCL, which technically makes SCL an open-drain with a pull-up like SDA.
However, if clock stretching is not needed, SCL can be configured as an
output removing the need for a pull-up and specially, allowing to use
as SCL GPIO pins that otherwise have a pull-down connected. In
particular, GPIO15 in the ESP8266 requires an external pull-down during
boot for the ESP8266 to boot from the flash.
This patch allows a board to define `I2C_CLOCK_STRETCH` to 0 to disable
clock stretching and allowing to use GPIO15 as SCL.
ztimer's machinery depends on figuring out if a timer is currently set
or not. It does that using _is_set(), which is also exposed as
ztimer_is_set().
Now when a timer expired and got taken of the timer queue using
_now_next(), the `next` pointer wasn't unset. This caused _is_set() to
wrongly return `true` for that timer.
Internally in ztimer, this didn't cause breakage, just an unnecessary
iteration of the timer queue by _delete_timer_from_list().
But this also broke the public ztimer_is_set().
This commit fixes the issue by correctly NULLing the timer's `next`
pointer when the timer triggers.
While nice at first, this causes more issues than it's worth for
a slightly more pretty output.
Hiding information from developers is not a good idea, especially when
it comes to an often finicky programming step.
While in theory error output should be caught, there are enough
cases where the programmer will get stuck in a loop or require user
input that hiding programmer output by default is a bad idea.
The Silicon Labs Si705x sensors (Si7050/1/3/4/5) are very similar to the
Si7021 sensors featuring only a temperature sensor and no humidity
sensor. The only difference between the Si705x is the temperature
accuracy of the reading, ranging from +/- 0.1 C in the Si7051 to +/- 1 C
in the Si7050.
This patch adds support for this family of sensors extending the
functionality of the existing si70xx driver. Following the style of
other modules, this implements a pseudomodule per supported chip, adding
si7050, si7051, si7053, si7054 and si7055 pseudomodules.
As a minor change this patch also implements the missing
si70xx_get_serial, si70xx_get_id and si70xx_get_revision functions that
were declared in the si70xx.h header but implemented as private
functions. The si70xx_get_id() may be relevant for the application to
know at run time exactly which version of the hardware is installed.
The updated test running with a Si7051 shows the following output, which
seems consistent with the room temperature conditions during the test.
```
make SI70XX_VARIANT=si7051 -C tests/driver_si70xx/ all flash
```
```
SI70XX temperature and humidity sensor test application
Initializing sensor...
[OK]
Found SI7051 sensor, revision 32
temperature: 24.71 C
temperature: 24.69 C
```