i2c (TWI) buffer size for Mega and Due ?

hey,
I just read some puzzling ressources about i2c (TWI) buffer size on Arduinos: some say it's 32 bytes, some say 64 bytes, I already read something about 193 bytes - but I don't understand what is now the correct information.
I have a Mega and a Due, and I intend to connect them to a Raspberry Pi (Arduino=slave, Raspi=master).

My question is:
How many bytes at most (in 1 byte array) can I

  • request by 1 single Raspi i2c read command
  • write by single 1 Raspi i2c write command

a) addressing an Arduino Mega
b) addressing an Arduino Due
c) just for completeness: addressing an Arduino Uno R3
from my Raspi?

no idea anyone?

Perhaps people (like me) are puzzled why this question is in the LEDs and multiplexing section, or why it's in the Arduino forum at all, since it appears to relate to the RaspberryPi

buffer is 32 on UNO but IIRC 2 bytes are needed for addressing. ==> 30.

aha, ok, thank you!
and what about i2c buffer sizes of Mega and Due ?

Mega buffer size is 32 bytes of user data. That may apply to all Arduinos of the 8 bit versions. I use 32 byte packets from Nano to Mega using the Wire.onRequest event. The wire library may add some more for it's own housekeeping. You can use the Wire.onReceive event to previously tell the slave what you want on the next command.

ok, thank you!
so all AVR seem to have a 32 byte bit buffer.
Is that also true for the far more powerful ARM boards, especially for the most powerful DUE ?

I don't personally know to what size it is set. I found my AVR info by searching the twi.c file. You'll have to search for the file that is used with the Due hardware.

One way to test it is to create a byte buffer of perhaps 128 with sequential numbers and see how much of it you can send. The compiler may give you an error message or another Due as a receiver may not get it all.

If you find the answer then please post the result here so we can all get the info.

for the Due (connected to a Raspberry Pi) I failed for 32 bytes
(i2c connection broken, no device detected by the Raspi any more,
send buffer on the Arduino serial monitor just shows up the 1st byte - then hangs up, too.)

After restart: same results for 32 bytes.

Then I lowered to 31 bytes: stabile i2c connection,
31 bytes content for send buffer shown correctly on the Arduino serial monitor,
but unfortunately I didn't manage so far to write a Raspi C/C++ communication code to receive a byte array at all.

Did your buffer index run from 0 to 31 or 0 to 32?

Try moving data between two UNOs.

I have no Uno, I just use my Due. The 32-byte buffer which failed was from 0 to 31 of course, and the one which worked for the Due part was from 0 to 30.

But I actually didn't want to perform a clump of trial-and-error experiments, I actually was trying to get a reliable answer about how the Due libs are designed for i2c buffers by the Arduino developers.

I understand your view, stop testing and move on with the project. My only suggestion at this point is to use 30 or 31, I like even numbers, and proceed.

I have four sonar data arrays of 1024 bytes residing in Nanos so packets of 32 work nicely while sending to a Mega. You could use a size that divides evenly into your array size then pass whole chunks until finished.

You could still search the libraries used by the Due and maybe find a more definitive answer. That's how I found the AVR limit as it was confusing seeing a lot of opinions.

Good luck.

I don't find a twi.c for the Due, just a twi.c for AVR

Maybe some of the developers could join this discussion, please?

Isn't it at the very top of "Wire.h"? #define BUFFER_LENGTH 32

I expected this in twi.c in the AVR folder (CMIIW) - or in which Arduino folder is wire.h to find?
(there is no wire.h in Arduino\libraries\ ... why not?)

hardware/arduino/sam/libraries

thank you, then I'have to check the Raspi side - FTM I just can transfer single bytes but no arrays.
Most probably my communication program (Raspi C/C++) is faulty, I'll have to see where I can find one which is working already, ready to use. Arduino to Arduino works fine though.

I'm using a combination of I2C, NRF24, and Serial1 in a conglomeration of six Arduinos and one laptop running Lazarus Pascal and in all cases there is a buffer limit ranging from 32 on the low end to 128 on the high end. When you want to send more than one byte, always look for a buffer limitation. The number may not be easy to find but it's likely there. You can always set up a simple test and increase the size in powers of 2 until it does some wrong. The I2C and NRF24 were known to me early on but the Serial1 took a little testing to be sure.

Good luck.

I have byte array[30] now for both the Arduino and the Raspi (Raspbian Jessie) which then will be beneath either buffer limits. This lets me assume that the i2c communication code is faulty (alternating read and write 30 bytes each). I can clearly see that the Arduino provides 30 bytes (onRequest) but if the Raspi reads them (30 single reads) I always just poll array[0]: so the Arduino does not increment the read pointer when bytes are requested by the Raspi.
OTOH, if I do the same by 2 Arduinos, then it works.
Anyway, it's most probably not a buffer issue then and no Arduino issue, but a Raspi-related issue using the Arduino as a multiplexer board.
But nevertheless, I woud be happy to find Arduino and Raspi source code which would be working ot-of-the-box, ready to use.

Good idea and good luck.