ESP32 Forum

I'm using a library to interface with an I2C OLED display (specifically this one https://github.com/nkolban/esp32-snippe ... plays/U8G2), and have a long standing problem that when the I2C display is not connected my device just crash loops. The reason this happens is because of the calls to ESP_ERROR_CHECK like this one: https://github.com/nkolban/esp32-snippe ... hal.c#L159
Since there is no I2C device attached, the assert here will fail, and abort will be called. I'd love for my device to be able to handle this a little more gracefully, and simply print an error message when the I2C connection fails. Is there a straightforward way to do that?

In this case, you could just change the local definition of ESP_ERROR_CHECK.

You can also redefine/replace it with an alternate, see e.g. https://docs.espressif.com/projects/esp ... bort-macro.

However, you probably need to do a bit of refactoring to make sure any errors are represented as such in return values for the calling code to be able to react to unsuccessful operations.

You can also look into initially 'manually' probing the I2C slave and skip all U8G2 routines if the display was not detected.

Excellent, thanks so much for the recommendations! I think I like the idea of manually probing the I2C slave, though I'm not sure exactly how to go about that.

I think it might be worth pointing out that you don't have to use the ERROR_CHECK macro, you can just check the response of your function and implement custom code.

These standard macros are there to help you cut down writing tedious boilerplate if you are handling errors in typical ways. Check out their documentation (https://docs.espressif.com/projects/esp ... dling.html) Other macros exist that don't abort, or you can just check err != ESP_OK and do your own thing.

That said, redefining a standard macro is terrible advice and will only lead to chaos, because it of all sort of unintended consequences resulting from people who wrote libraries or colleagues to expect them to behave in the documented fashion.

flimsy wrote: ↑

Fri Jul 12, 2024 9:25 pm

probing the I2C slave, though I'm not sure exactly how to go about that.

With I2C it's actually really simple: You prepare a minimal I2C tranasction of START, slave address, STOP.; read or write doesn't really matter much.
You then send this tranasction to the bus.If the slave with the specified address is not present, sending the transaction will result in a non-success return value indicating an ACK error.
With the IDF's new I2C driver, this functionality is already provided for you in i2c_master_probe().