JTrotta/RaspberrySharp

Write to wrong register in I2cDriver

ifbeginend opened this issue · 3 comments

ifbeginend commented

Hi, there is probably a mistake in RaspberrySharp.IO.InterIntegratedCircuit.I2cDriver in methods
WriteRead (currently line 245), WriteRead (336), Write (396), Read (453).

Should write to status register, not control register:
WriteUInt32Mask(status, OP.BCM2835_BSC_S_DONE, OP.BCM2835_BSC_S_DONE);

The corresponding bit in control register is reserved. See http://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf pages 29-32

JTrotta commented

@ifbeginend
Take a look here https://github.com/janne/bcm2835/blob/master/bcm2835.c
I translated from c to c# quite line-to line. For example line 1321 is exactly this line
WriteUInt32Mask(status, OP.BCM2835_BSC_S_DONE, OP.BCM2835_BSC_S_DONE);
Did you find any malfunction? I usually use I2C without any problem using all the features.

Let me know if you notice any strange behavior.

ifbeginend commented

@JTrotta
About 40% of the I2cDriver.Write(addr, buf) calls fail (NACK) in my setup:

That's why I reviewed the RaspberrySharp I2cDriver source code. The change proposed above doesn't help, the behaviour is the same as before. I'm not sure what the intention of the WriteUInt32Mask() 245/336/396/453 lines is, but since each read/write method clears the status first, I don't think the lines have any important impact.

As I see now, the Python code for GrovePi+ simply does retries
https://github.com/DexterInd/GrovePi/blob/master/Software/Python/grovepi.py line 170..198,
so I think the RaspberrySharp I2cDriver is ok and it's the GrovePi hardware that does not confirm the written bytes.

JTrotta commented

Sorry but I can't help you.
Just a suggestion: Windows IOT seems to be too young, I currently use this library with mono and I2C works always as expected. Mono is very stable on rasperry pi