Use of mixed i2c legacy and new apis

[empirephoenix]

According to the specification here:
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/i2c.html
it is not allowed to use both the legacy and the new header,
but according to the binding.h we do exactly this.

I tried to disable the legacy api in the hopes that it is only used conditionally, but apparently it is used mixed within the i2c driver. I strongly suspect, that this causes some freezing/native error issues on the esp32c6 platform.

It seems, that this is already enough to trigger a low level error:

        let peripherals = Peripherals::take()?;

        let i2c = peripherals.i2c0;
        let config = I2cConfig::new()
            .scl_enable_pullup(false)
            .sda_enable_pullup(false)
            .baudrate(10_u32.kHz().into())
            .timeout(Duration::from_millis(10).into);
        let scl = peripherals.pins.gpio19;
        let sda = peripherals.pins.gpio20;

        let driver = I2cDriver::new(i2c, sda, scl, &config).unwrap();

It reports that the timeout is not valid.
When not setting the timeout, the first write will hang forever instead of using the default timeout (14 clock cycles according to the low level headers).
(Note: there is no actual device connected (or anything at all, it is just the plain module), I try to setup the failsave correctly, so that a bus error will not result in a hanging esp)

[empirephoenix]

Ok, after a lot of further debugging, and downgrading the sys to the last version before the new includes, the behaviors is still the same. It is now however possible to set the timeout to slightly higher values without getting an error from inside the idf code. I'm pretty sure I tested on the esp32 and it did run into a timeout, if the bus is not responding (one of the pins is low), but I will confirm to be sure. So far, if I add pullups, the esp32c6 seems to work es expected, it just seems to ignore any timeout set during initial waiting for the bus to be ready.

[empirephoenix]

Closed with creation of esp-rs/esp-idf-hal#412, as this seems to be the underlying cause for most of the issues