If Dave is still following this thread...
FusionWare.SPOT.Hardware.I2CBus::Write code appears below. Does i2cDevice.Execute return (i.e. not throw an exception) if it times out? If so, that might be why you're seeing the System.IO.IOException (timeout happens before the specified number of bytes were written, so the test fails, and the exception is thrown).
public void Write(I2CDevice.Configuration Config, byte[] WriteBuffer, int TimeOut)
{
ThrowIfDisposed();
lock(this.Device)
{
this.Device.Config = Config;
I2CDevice.I2CTransaction[] xacts = new I2CDevice.I2CTransaction[] {
I2CDevice.CreateWriteTransaction(WriteBuffer)
};
// I2CDevice.Execute returns the total number of bytes
// transfered in BOTH directions for all transactions
int byteCount = this.Device.Execute(xacts, TimeOut);
if(byteCount < WriteBuffer.Length)
throw new System.IO.IOException();
}
}
Contrast with the following Write implementation from
http://blog.codeblac...-with-I2C.aspx. It assumes that the timeout will sometimes occur. Instead of throwing an exception, it executes in a loop until all the bytes are written.
private void Write(byte[] writeBuffer)
{
// create a write transaction containing the bytes to be written to the device
I2CDevice.I2CTransaction[] writeTransaction = new I2CDevice.I2CTransaction[]
{
I2CDevice.CreateWriteTransaction(writeBuffer)
};
// write the data to the device
int written = this.i2cDevice.Execute(writeTransaction, TransactionTimeout);
while (written < writeBuffer.Length)
{
byte[] newBuffer = new byte[writeBuffer.Length - written];
Array.Copy(writeBuffer, written, newBuffer, 0, newBuffer.Length);
writeTransaction = new I2CDevice.I2CTransaction[]
{
I2CDevice.CreateWriteTransaction(newBuffer)
};
written += this.i2cDevice.Execute(writeTransaction, TransactionTimeout);
}
// make sure the data was sent
if (written != writeBuffer.Length)
{
throw new Exception("Could not write to device.");
}
}
Maybe FusionWare.SPOT.Hardware.I2CBus::Write should do the same, but then I guess it would get stuck in an infinite loop if faced with anything other than an intermittent problem. I suppose the exception approach is better, if it's caught and dealt with somewhere appropriate up the call stack.