Iot: Need abscract class for Read, Write for SPI, I2C and Serial

[Ellerbach]

Some sensors like PN532 can have multiple interface like UART, SPI and I2C. See https://www.nxp.com/docs/en/user-guide/141520.pdf
Some other sensors like AK8963 can be accessed thru a different sensor and require a specific Read and Write primitive. see https://github.com/dotnet/iot/pull/523 and code here https://github.com/dotnet/iot/pull/523/files#diff-8dcf6685a84684cbe74a22d67f921308. In this last case, the abstract built is a bit more complex as it directly take the advantage of registers but it can be as well basic and reuse a more generic abstract.

 public abstract partial class SerialInterface : IDisposable
    {     
        // This one may be done thru the Read one but would be nice to have
        public abstract byte ReadByte();

        public abstract void Read(Span<byte> buffer);

        // This one can be done thru the Write but would be nice to have
        public abstract void WriteByte(byte value);

        public abstract void Write(ReadOnlySpan<byte> buffer);

        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }

        public virtual void Dispose(bool disposing)
        {
            //Nothing to do in base class.
        }
    }

[shaggygi]

I've been working on a few devices that are based on I2cDevice and SpiDevice so I can develop/control bindings directly from WPF apps without having to download/execute via RPi/BBB. It would be nice to have an implementation that does all, but not sure how it would be coded without interfaces. In addition, how would it know when WriteByte(...) should be used for I2C and when to use SPI?

I'm thinking just create new specific classes that inherit each. Meaning, the binding API would have a Pn532I2cDevice, Pn532SpiDevice, etc..

But then again, I haven't looked too much into this device. Looks promising though 👍

[joperezr]

Usually what we do in cases like this is that we have an internal enum in the binding, something like ConnectionType where we have the possible ones like Spi or I2c, and depending on this enum, we pick which device to use for communication. I don't see a big benefit of having a parent class to Spi, I2c and SerialPort devices if that is what you are suggesting here.

[Ellerbach]

Usually what we do in cases like this is that we have an internal enum in the binding, something like ConnectionType where we have the possible ones like Spi or I2c, and depending on this enum, we pick which device to use for communication. I don't see a big benefit of having a parent class to Spi, I2c and SerialPort devices if that is what you are suggesting here.

Yes, that I understand. The point here is that for many sensors using multiple ways like SPI and I2C, they are using the exact same way of reading and writing. And you basically have to copy/paste lines and just changing the name of the device. And abstract would avoid this. Still, in some cases, you'll need to know if you are I2C or SPI as you may have to use specific commands but that's quite limited compare to what youn may have to do repetitively one read/write operations.

[HakanL]

One comment regarding this is to perhaps have a discussion about connectivity that is one-way, for example when controlling pixels via SPI (WS281x) you only use two wires (DA and CK) and there are no read-capabilities. There are other devices like that (TLC59711 for example). I suggested SpiOutputDevice, but there are other issues with that so I figured I'd just add my comments here to perhaps have that use-case of the discussion, even if SpiOutputDevice isn't the correct design.