New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wire.h: Wrong number of bytes returned from the slave device (I2C) #384
Comments
Hm, is this even possible? I haven't checked, but IIRC an ACK is only sent by the device receiving data, so when reading data from a slave, it's the master that sends ACKs, not the slave. So AFAICS, there's no way that the slave can actually tell the master how many bytes to return, so the master always reads as much as he expects to read. As I said, I haven't doublechecked, but the I2C spec should be able to confirm this (or prove me wrong :-p). |
This is part of the I2C standard, therefor this can not be fixed in hardware nor in the Wire library. Related to: #171 |
I agree and i disagree. From the i2c spec, section 3.1.6, page 10 of UM10204:
That makes me solely think of a Master writing to a Slave. But i also find that less reasonable and i think that this is a case of squishing specification for compactness and neatness. I think that it is technically possible to implement it the other way. Of note for that is that the current Arduino Slave Transmit implementation breaks the i2c specification already and ACKs if there is a Byte available to be transmitted, visible in lines 643-648. |
@Ragebone, it is not possible to change the standard I2C behavior, that is not implemented in hardware. Who is sending the ACK makes sense at hardware level. See the 'ACK' as a signal that the next byte can be latched into the shift register. The SCL clock shifts the bits out or in the shift register. The I2C bus was designed 40 years ago, so it is with basic logic hardware. You are right about the code in Slave Transmitter mode. In the source code, the Slave uses ACK or NACK. I assume that it is ignored by the hardware, because the Master does the ACK and NACK. |
I'm sorry but that does not really make sense to me.
That seems reasonable to me and would explain why it was made that way.
Be aware that the used mycrocontrollers don't have i2c hardware. |
The TWI hardware is not a universal programmable block of hardware (such as the USI of the ATtiny, or with newer processors). The TWI hardware is only for I2C. I think that things outside the I2C standard are not implemented in hardware. |
After some tests with two pro micro, i can say that the Master can be made to NACK as stated previously. Anyway, i'd count this as another nail in the coffin of this issue, Fun-fact, the Master can be made to always ACK, which results in funny bogus. Stumbled over the UP9512 GPU VRM Controller that reads like it breaks i2c spec and ACKs as well. |
Hi. According to the documentation, the two functions below will return the number of bytes that the master has received from the slave and which are available in the buffer.
But if slave will respond with a less number of bytes than master requested (as is described in Master Reader/Slave Sender Example), then we have a problem because both functions (Wire.requestFrom() and Wire.available()) will return the requested number of bytes, not the number of bytes received from slave. So, the output will be
hello ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
.master_reader.ino
slave_sender.ino
It will be great if it will be fixed.
Regards,
Florin.
The text was updated successfully, but these errors were encountered: