[ainyan03]

Summary

Two commits:

1. Enable the threshold of the hardware I2C input glitch filter. The filters were enabled with a threshold of 0 cycles.

On ESP32-C61, with ModuleDisplay on CoreMatrix (the transmitter's ACK only reaches about half of VDD), the controller detected a STOP right after the ACK and left the command list: it kept clocking with SDA high until the stall timeout, and the device received 0xFF bytes. Initialization of that device failed on every power-on. With the threshold set, the stalls no longer occurred.

The threshold is 1/16 of the bit period, up to the maximum of 15 source clock cycles (with a 40 MHz source clock: 15 at 100 kHz, 6 at 400 kHz). The filter stays disabled for bit periods of 64 source clock cycles or less, as it was. ESP32 and ESP32-S2 use a different filter register and are unchanged. ESP-IDF also sets a threshold on these chips.
2. Support ModuleDisplay on CoreMatrix (ESP32-C61): enable M5ModuleDisplay on ESP32-C61 with the CoreMatrix M-Bus wiring (I2C port 0 on G0 / G1, SPI2 with CS G22, MOSI G27, MISO G26, SCLK G25) and use the write-only transmitter path, since register reads from the transmitter fail on CoreMatrix. CoreMatrix is the only ESP32-C61 host with an M-Bus, so the wiring does not depend on board detection. M5Unified sets it up in M5.begin() with a separate PR.

Bus speed

The filter delay can lengthen the SCL high time when it approaches the SCL wait-high period. Measured on ESP32-C61 (logic analyzer, address byte time):

setting	threshold 0	threshold 6 (this PR)	threshold 15
400 kHz	about 435 kHz	about 418 kHz	about 382 kHz
100 kHz	unchanged	unchanged	unchanged

Testing

• CoreMatrix + ModuleDisplay, power-on: threshold 0 failed every time (stalls on almost every transfer after the device started to answer); with the threshold set, 0 stalls in 15 power-ons. Other devices on the same bus (400 kHz and 100 kHz) worked.
• Build check on ESP-IDF 5.1 / 5.2 / 5.3 / 5.4 / 5.5 / 6.0 / 6.1 and Arduino core 2.0 / 3.x for the supported chips passed.
• CoreMatrix + ModuleDisplay with both commits, rebuilt from a clean build: picture in 3 of 3 power-ons with this revision, and 5 of 6 with an earlier revision (same threshold at 100 kHz). The failed one is a different, known issue (the transmitter did not answer during both reset + init passes of the write-only path), not related to I2C.
• Not tested on hardware with other chips.
• Fork CI passed.