Open Koepel opened 7 years ago
thanks @Koepel
however, did you notice the conditional code? Also, keep in mind it's compatible with all official arduinos, each with it's own bugs (especially the intel boards are full of bugs when it comes to i2c).
Anyways, will have a look at it. Although please note, the codes work as is on all Arduinos. So even if the api is used wrongly - we're forced to do it because of all the wrong implementations in the different boards.
I think you are pushing your luck (a lot).
For AVR microcontrollers, the size is clamped to BUFFER_LENGTH, which is 32. https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/libraries/Wire/src/Wire.cpp I prefer to stick to the maximum of 32 for AVR chips. I'm not sure about the SAMD processors, they might create a RingBuffer with 64 bytes but seems to omit the check for the maximum quantity. By the way, a slave can not stop a Wire.requestFrom() in progress, only the master can stop it.
Calling Wire.endTransmission() out of the blue, without Wire.beginTransmission(), and getting away with it, is very lucky. You will never know if you are still that lucky when a change is made to any Wire library implementation. The Wire.requestFrom() with a stop at the end (third parameter is true or omitted) creates a I2C read transaction that is fully closed. There is absolutely no need to do something else to end something.
The rxBuffer.clear() was added at 18 Jan 2016 in the Wire.requestFrom() for the Wire library for SAMD processors. https://github.com/arduino/ArduinoCore-samd/blob/master/libraries/Wire/Wire.cpp That is a year and a half ago. I thought that was fixed years ago. If you need a workaround for that bug, at least explain it carefully. I prefer not to write a workaround for that bug, but advice your users to use the newest Arduino code.
Thanks for pointing these things out. There has been a lot of bugs and confusions across the history of Arduino boards wire implementations - some of the mess reflected in the examples. Pull requests to clean up / fix stuff are very welcome.
I2C problems of Arduino 101 - for reference https://github.com/01org/corelibs-arduino101/issues/238
The Arduino 101 has a lot of problem with I2C and Serial and what else.
However, fixing a bug with another bug is a beginners mistake, you should know that. The Wire.endTransmission() is not to clear the I2C bus, it is only for writing data together with Wire.beginTransmission() and Wire.write().
If you want to reset/clear the I2C bus for the 101, you could try an extra start-stop with Wire.beginTransmission(() followed by a Wire.endTransmission(). Perhaps a small delay is needed to prevent that the start-stop is too close to the rest.
Perhaps you could explain in the code that you are doing specific things for the 101, that will only work for the 101 and only with the libraries for the 101 at this moment and only with some luck.
By the way, I don't have a Arduino 101, so I can not test it.
@Koepel are you up for hire? you seem to be the right kind of guy to do some Arduino library development for us. If interested, please contact via our contact form: www.whiteboxes.ch/contact
No, sorry. I only want to reduce incorrect use of the Wire library. Although that feels like Don Quixote, fighting windmills sometimes. Beside that, I don't even like how I2C is implemented in the Arduino Wire library.
The Arduino Wire library is used incorrectly in the next files:
The maximum number of bytes to read is 32 for a Wire.requestFrom(). I see 48 many times. The buffer in the Wire library is 32 bytes.
The Wire.endTransmission() may not be used after a Wire.requestFrom(). The Wire.requestFrom() is a complete I2C transaction on its own. The Wire.endTransmission() on the other hand may not be used on its own to do something, it can only be used when writing data with Wire.beginTransmission() and Wire.write(). When the length of the data is unknown, and no more data is needed, then don't read more data. Nothing else is needed.
When the Wire.requestFrom() returns, the I2C transaction on the bus has completely finished and the received data is waiting in a buffer in the Wire library. That data can be read or not.
There is therefor also no need to read any remaining data from the buffer to "clear" it. If there once was a bug in that situation with the Arduino Zero, that should have been solved long ago.