boards/esp32: changes the approach for configurations of I2C in board definitions

[gschorcht]

Contribution description

This PR changes the approach of peripheral configurations for I2C in board definitions to the usual RIOT approach. With these changes, peripheral configurations use static const arrays in the boards/esp32*/periph_conf.h files and define the *_NUMOF macros using the size of these static array.

The static configuration arrays contain only definitions that can be changed by the board definition or the application. They do not contain any MCU implementation detail. The board definitions use preprocessor defines as before to fill these static configuration arrays. This makes it possible to override all configurations either with the make command or application specific configuration files.

Please note that commit 8b48dfd is in also in related PRs to get each PR compilable separately.

Testing procedure

Compilation and test with the most common ESP32 board should be executed

make BOARD=esp32-wroom-32 -C tests/periph_i2c flash test

Issues/PRs references

PRs #11289 #11290 #11291 #11292 #11293 #11294 are releated and should be merged together.

[MrKevinWeiss]

I will add it to the list but it will require some testing since it is a structure change and not just a cleanup.

[gschorcht]

@MrKevinWeiss Thanks 😄 Sorry, for so many new PRs. Initally, they all were part of the single PR #10644 but splitted now into a separate PR for each peripheral by request from @leandrolanzieri for easier reviewing.

In case of I2C, I have tested it with

make BOARD=esp32-wroom-32 -C tests/driver_lis3mdl

without any problems.

Please, don't wonder about the changes of GPIO definitions in cpu/esp32/periph_cpu.h. These are part of all PRs to make them all compilable. The changes became necessary to have gpio_t and GPIO_* macros defined in boards/common/esp32/include/periph_conf_common.h.

[MrKevinWeiss]

hey all were part of the single PR #10644 but splitted now into a separate PR

That is a good thing!

I will rerun it through the RF tests to be sure (they have negative testing). Just need a bit of time to setup.

[MrKevinWeiss]

I would say it looks good. I also tested it and it appears to work (just manually against PHiLIP). There are wrong error codes but that isn't related to this PR and I will soon add a test to expose that so don't worry about it now. I will ACK.

[MrKevinWeiss]

I will let @leandrolanzieri coordinate the merging.

[MrKevinWeiss]

Quick retests against philip (flashing, reading and writing registers). Seems good. ACK!

[gschorcht]

@MrKevinWeiss Thanks a lot for testing and reviewing it again 😄