Support Ack Polling for I2C

When writing to an EEPROM (Microchip 24LC256), the device goes into a “busy” state for a few milliseconds when a page of data has been written. It is possible to “poll” the device to determine when it has finished by essentially performing a zero byte write, essentially meaning that the device address is sent on the bus, then if the device is ready it will acknowledge (ACK) and if it is not ready it will not acknowledge (NACK).

The issue is that there needs to be a way to poll the device to determine whether it is ready for the next command.

Ideal solution: add the following method to I2cDevice: bool AckPoll(), which sends only the device address on the bus and returns a boolean matching the ACK/NACK state. This can then be read in a tight loop to determine when the device is ready. Could probably also be implemented as an awaitable async method with a timeout to do background polling, but the simple implementation is fine.

Note: I am not using the underlying OS support for I2c via I2cDevice.Create(), I have derived from I2cBus and I2cDevice to implement a Serial to I2C converter that works on any OS, so all my testing so far has been done using this running on Windows 10. The trivial implementation below works, in that a zero byte write that is not acknowleged by the device throws an exception stating “NACK on address” - it just takes too long to throw/catch the exception longer than the busy time of the device), hence the need for a proper AckPoll method that doesnt rely on catching exceptions (I am assuming that the OS support for I2C works in the same way):

bool AckPoll()
{
    try
    {
        i2cDevice.Write(new byte[0]);
        return true;
    }
    catch
    {
        return false;
    }
}

[pgrawehr]

Regarding your last point: We’re kind of having a hard time continuing to support Windows IOT. It officially only works on the Pi3 and has never been updated to the Pi4. Event the upcoming Windows 11 for ARM is (as it currently looks) not supported on the Raspberry Pi (any version). The information you find about it is very poor. Advertisements and “developer resources” everywhere, but no operating system image to download and test.

I therefore think we currently don’t have to worry about windows support, but maybe @joperezr can get some information about whether there will one time be a new Windows Version for a Raspi (or a similar device).

[joperezr]

[Triage]: This feature is approved. We would like the API to look like the following:

    public abstract partial class I2cBus : IDisposable
    {
       //..
+      public virtual bool IsDeviceReady(int deviceAddress);
    }

    public abstract partial class I2cDevice : IDisposable
    {
       //..
+      public virtual bool IsDeviceReady();
    }

@philrawlings would you be interested in contributing a PR for this addition?