Version [1.8.4] - 2024-04-20 Get Failure

[ClaudiusVi]

Board ESP32-S3 N8
\Arduino\libraries\Wire\src/Wire.h:125:13: note: candidate 2: 'uint8_t TwoWire::requestFrom(uint8_t, uint8_t)'
uint8_t requestFrom(int address, int size);

// Previous definition using 'int' (not optimal for this application):
// const int EEPROM_ADDRESS = 0x50; // EEPROM address

// Updated definition using 'uint8_t' (optimal for 8-bit addresses):
const uint8_t EEPROM_ADDRESS = 0x50; // EEPROM address

// Create an EEPROM object for a 24LC512 chip using the corrected address type
I2C_eeprom EEPROM_24LC512(EEPROM_ADDRESS, I2C_DEVICESIZE_24LC512);

[RobTillaart]

Thanks for reporting these issues, will have a look at it today.

[RobTillaart]

Cannot replicate,
Can you post a minimal sketch that shows the issue?
Was there a reference to an library line?

[RobTillaart]

@ClaudiusVi
OK, think I found the cause, and created a develop branch with the fix.

Can you verify the develop branch works for you?

[ClaudiusVi]

@rob
I've already made the changes in the ESP32 code. Initially, I wasn't sure where to look, so I checked your library code to find where the issue occurs. Since I'm currently writing libraries for the Raspberry Pi 5 with the new GPIO chip, it made the process straightforward.
Incorporating an example in the documentation like the following would clarify things:

const uint8_t EEPROM_ADDRESS = 0x50;
I2C_eeprom EEPROM_24LC512(EEPROM_ADDRESS, I2C_DEVICESIZE_24LC512);

Our program is quite extensive and includes LoRa, various sensors, and control modules, which is why the I2C addresses are declared as constants, or mistakenly as integers in some cases.

Thanks for your help,

Claudius

[RobTillaart]

You're welcome,

The problem is not in the constructor I2C_eeprom EEPROM_24LC512(EEPROM_ADDRESS, I2C_DEVICESIZE_24LC512); or its parameters, so an additional example would not help or being educative.

The error is introduced by the last PR which allows the I2C buffer to be larger than 256 bytes, making low level calls with 16 bit variables instead of 8 bit. This causes an ambiguity in the library call requestFrom(). By casting the parameters of that function explicit to int this ambiguity is solved.

If you have time, please verify the develop branch,