I2C API should support Restart/Repeat condition

[dotnet]

I2C API should support Restart/Repeat condition

[shaggygi]

I was tinkering with this for a little bit and was able to get the Restart bit to occur between write/read buffers. I'm just not so sure on the best solution as devices can required different sequences of this. For example, You might have to write a few bytes for addressing, followed by a Restart bit, write another for a command and then remaining data can be clocked in to read buffer. One question is how can this be structured to allow multiple types of bits in specific locations of command? 🤔

I'm putting these notes here to ponder later.

Added to I2cDevice.cs:
public abstract void WriteRead(Span<byte> writeBuffer, Span<byte> readBuffer);

Added to UnixI2cDevice.Linux.cs:

public override unsafe void WriteRead(Span<byte> writeBuffer, Span<byte> readBuffer)
{
  Initialize();

  fixed (byte* writeBufferPointer = writeBuffer)
  {
    fixed (byte* readBufferPointer = readBuffer)
    {
      Transfer(writeBufferPointer, readBufferPointer, writeBuffer.Length, readBuffer.Length);
    }
  }
}

[joperezr]

I think we can add the WriteRead method, but individual device bindings should still have to think about the specific protocol they require (meaining the Restart bit that you mention above) since that can't really be generalized. I would expect each binding to have all of that logic in their source code, and then call either Write(), Read() or WriteRead() methods as appropriate.

[joperezr]

Next steps for this: We would need a formal Api proposal for this in order to consider adding it to the library, so feel free to submit one.

[shaggygi]

Just to note, all the bindings I've worked with appear to work by setting register pointer using a Write first and then follow up with the Reads. So it hasn't hindered me so far. Most of the device datasheets have diagrams on the steps to perform where a few had some more complex steps to do things like sequential writes/reads (and for more than one cycle of Writes/Reads within one command).

I also came across a note in a random blog that stated they had devices that would only work using the Reset condition and extra steps to configure the RPi. They were not using .NET IoT, didn't provide the device names, so I couldn't confirm their accuracy.

I was able to produce the Reset condition with above code, but needs to be thought through more. I'm okay with keeping this issue open for a period to allow others to chime in and keep record on possible devices that require this scenario. Investigate further if popular or close if not.

Thx

[ZhangGaoxing]

Hope to be implemented in the master branch as soon as possible.
I have encountered problems in adding KT0803L binding recently. This is not the only one. When I used the old version System.Devices.Gpio package, it contained ReadWrite(), and MLX90614 worked well. However, Write()Read() mode does not work correctly when using the current System.Device.Gpio package.
@shaggygi @joperezr @krwq

[joperezr]

Adding WriteRead sounds reasonable to me. @ZhangGaoxing do you want to put up a PR for it?

[ZhangGaoxing]

@joperezr Let you do it. I'm not familiar with Linux drivers.😀

[krwq]

@ZhangGaoxing @shaggygi - @joperezr is currently on vacation so won't be able to help for couple of weeks. I think this just uses just some linux APIs I can help with linux implementation if it's not too much work although I'm not familiar with that piece of code - I don't think I currently have any devices which require Restart/Repeat so will be hard to test if it is working - perhaps one of you could start WIP PR and ask questions if you're not sure about something - or alternatively please point me to PRs which are broken because of lack of that and I can try to fix but you will need to tell me if it work...

add two work incorrectly sequence diagrams

not sure what that means 😄

Do you know of any cheap devices which would require Restart/Repeat we could get for testing? You have mentioned KT0803L, do you perhaps know any other?

Perhaps @JeremyKuhne knows or has some devices like that

[krwq]

Marking as 3.0 since this is potentially blocking adding new devices

[ZhangGaoxing]

I think we should try to solve this problem as soon as possible. I found that the SMBus protocol devices I tried to bind were not working properly (I can't guarantee all the devices), like MLX90614 (this sensor adafruit is on sale). I don't know if the latest version of the Raspberry Pi driver supports I2C Repeated Start, I refered this post to back the I2C driver, then I realized that our lib didn't provide WriteRead() method...

I remember that a long time ago version of System.Devices.Gpio provided this method.🤔