The example in the DS3231 datasheet shows first writing the subaddress to read from, then generating a repeated start code and then reading 3 bytes from the device. Does “i2c.read( 0xD1, “\x00”, 3)” actually translate to this??
I have tried doing this in a similar way with i2c.write( 0xD0, “\x00”) followed by i2c.read( 0xD1, “”, 3), but this also doesn’t work )-:
Btw: I can ‘write’ successfully to the device (at least I don’t get a fail on that as I cannot determine if the data was actually written correctly…).
The i2c API will take care of setting the least significant bit for reads and writes, so you can just use 0xD0 as the address for both commands. (Though it ought to work either way.)
i2c.read(0xD0, "\\x00", 3) first writes 0x00 to the device and then reads three bytes like the datasheet describes - it’s how most i2c devices work - just behind the scenes. So that should be the right command.
What value pull-up resistors do you have connected to SCL and SDA?
Both pull-ups are 4k7. As the DS3231 can acknowledge on the (successful) write command it should not be a matter of it not being able to pull SDA low during a read.
As you have confirmed the read command to be correct my next step will have to be to have a look at the signals on a scope. Will keep you posted.
Most probably not related to the issue I have but I noticed that in “i2c.write” “write” is coloured according to colouring syntax: blue in the “Light” IDE and red in the “Dark” IDE setting. In “i2c.read” “read” is NOT coloured in both IDE settings!?
I also have the sam oddity. My read() is also not color coded. I thought that was odd. I am also having a similar i2c issue. However, I’m sure that it’s just coincidence.
On the i2c issue have you made any progress? If not have you tried using:
i2c.readerror();
If not that might point you in the right direction.