On the ESP32 it is often not possible with the I2C software implementation to communicate with an AIP31068 based LCD module. Therefore, the I2C hardware implementation is enabled when the AIP31068 driver is used, but it is more buggy than stable. The timing of the two implementations seems to be almost identical. The only difference is that the hardware implementation clears the bus before each access by sending 10 clock pulses on the SCL line while SDA is LOW. Using the same mechanism during I2C initialization for the software implementation solves the communication problem with the AIP31068.
The same software implementation works reliably with the AIP31068 on the ESP8266.
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.
GPIO32 and GPIO33 are used during boot to start an 32.768 kHz XTAL if it is connected to these GPIOs. If the 32.768 kHz XTAL is not connected, these pins can be used digital IO. However, the 32.678 kHz XTAL has to be disabled explicitly in this case. Furthermore, the handling of GPIOs greater than GPIO31 had to be fixed in I2C software implementation.
