I2C master/slave maximum requestEvent message size

Question

Using a NodeMCU master and an Arduino slave (Wire.h on both sides), is there a maximum message size (32 bytes?) for the answer that the slave sends from requestEvent()?

If so, is there any solution to circumvent such a restriction WITHOUT the use of other libraries (like I2C_Anything, for example)?

• chrisl: What libraries do you use on both sides? Wire on the Arduino? And what library on the NodeMCU?

Answer 1

The I2C protocol itself does not have a transmission size restriction. But the implementation in the Wire library only reserves a specific amount of RAM for the buffers. This site mentiones 32 bytes for normal Arduinos (couldn't find the source code currently) and I found 128 bytes for the ESP8266 in the source code.

You cannot have unlimited message length, since the buffer has to hold the whole message and the RAM on normal Arduinos is very limited.

But you can make the buffers of the libraries bigger by changing the corresponding defines in the header files to a bigger value. Keep in mind, that the actual used memory space is with a factor 2, since the buffer size gets used for both send and receive buffer.

---

If you need bigger messages, than is fitting in the available RAM, you should either change to a board with more RAM, or develop a way to process one part of a message, deleting it and then process the next part (multi part message). Though that raises the question, why the messages have to be that big in the first place.

• tony gil: I tested and the limit, without tinkering with the Wire.h library and it didnt work.
• chrisl: What exactly did you test how and what exactly didn't work?
• tony gil: i increased the char array to 64, instead of 32 bytes. Master did not receive message. Changed back to 32 bytes and it starts receiving again.
• Juraj: github.com/arduino/ArduinoCore-avr/blob/…
• tony gil: apparently, yes, the Wire.hlibrary must be tinkered with, which would make the sketch implementation non-standard. There is no guarantee that future versions of this library will accept such tinkering.