Signal Glitch and Initialization

Diagnoses of compatibility issues:

The esp32 hardware implementation creates some issues with implementing an Arduino compatible I2C interface. The original Arduino environment was designed around the ATmel ATmega168 family of MCU's, their hardware implementation supported SCL clock stretching. Each step of the i2c communications operation would use SCL stretching to allow for transparent software response to events. This ability to transparently delay transmission is very beneficial when SLAVE mode communications are supported by software. When the SLAVE was address the ATmega MCU would start stretching SCL to delay the MASTER while software generated a reply buffer. The ESP32 assumes the data is already buffered in the hardware FIFO. So, the data must be generated and loaded before the request arrives. This results in stale data. (I am investigating methods to refresh this data).

An additional issue with the Main Branch is that it does not correctly initialize the hardware, both GPIO's and the peripheral, this incorrect initialization has two known failures:

First:

The incorrect GPIO attach sequence created a negative going signal glitch on SCL and SDA when the GPIO pins are attached to the peripheral (fig.1).

(fig. 1 Original Glitch)

Thanks to work by @ESP32DE, I have found what I believe to be the correct sequence of both GPIO configuration and peripheral initialization(fig.2).

(fig. 2 After Correct Sequence)

Second:

The incorrect initialization of the peripheral does not reset the hardware. If the hardware was in a BUS_BUSY state, usually because the peripheral interpreted the "attachment" glitches as another MASTER i2c transacting the bus, the initialization did not clear the incorrect state. The original initialization assumed (ass you me) that the hardware had already been reset before it was initialized. This assumption has been proven false.