Setting I2C_BUFFER_LENGTH does not set underlying space requirements for larger receive buffer size

[lonerzzz]

Board

Custom board

Device Description

ESP-WROOM-32 with I2C device connected

Hardware Configuration

Pins 21 and 22 are used for I2C and are working fine

Version

v2.0.4

IDE Name

Arduino 1.8.19

Operating System

Windows 10

Flash frequency

80 MHz

PSRAM enabled

no

Upload speed

921600

Description

I needed to increase the size of the I2C message that is received from a peripheral and this works within the Arduino libraries but the underlying hal/idf code does not make use of the I2C_BUFFER_LENGTH being defined. I found that 384 bytes is the maximum size allowed for receipt of messages. If a larger value than this is provided, I get an assertion failure:

0x40093d1d: __assert_func at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/newlib/assert.c line 85 0x3ffb5900: Unknown Method at Unknown File line unknown 0x4008ed3a: xQueueGenericSend at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/queue.c line 821 (discriminator 2) 0x3ffb5a30: Unknown Method at Unknown File line unknown 0x400e92e5: TwoWire::requestFrom(unsigned short, unsigned int, bool) at E:\Program Files\Programming\Arduino_IDE\Arduino15\packages\esp32\hardware\esp32\2.0.4\libraries\Wire\src/Wire.cpp line 397

I would argue that the the two sizes should be linked and a readable error be generated when the size limit is hit. Setting the core logging level results for debug output results in no additional detail.

I would also like to know how to increase this allowed size of the items used in the underlying code.

Sketch

Will be provided if requested

Debug Message

No debug error is being provided, but would be helpful if one was.

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[SuGlider]

It will solved by #7016
Please let me know.

[lonerzzz]

@SuGlider Thanks for the quick response and for the feature.

Though I did not see all the code, I could not find anything that was going to ensure that the underlying queues are happy with the newly allocated buffer size that causes the assertion. I haven't traced all the way to the queue level to see where that size is expected to be set. If you have tested message sizes in excess of 384 bytes, then I assume all is good and look forward to the feature.

[SuGlider]

If possible, please try the PR in your environment and let me know if it solves the issue you presented here.
Thanks!