Hi Joakim,
many thanks for your comprehensive answer.
> First, let's clear up one thing regarding the current
> implementation: The static const structs defined in periph_conf.h are
> garbage collected in all modules where they are not directly used, so
> usually, this means that it will only us
Hi Gunar,
I have experimented with something similar, moving the configurations
to a .c file instead of periph_conf.h, but I came to the conclusion
that there are a number of drawbacks to the various alternatives.
First, let's clear up one thing regarding the current implementation:
The static con
Hi Juan,
thanks for your answer.
> So you are saying that the data gets duploicated in ROM several
> times? I did not know that. If that is the case, then it's
> definitely a bad thing!
Yes, at least for object files where they are used and cannot be
optimized. The static storage type limits th
Hi Gunar,
Even though these static const arrays are allocated in the .rodata
segment, they are allocated in each module that includes `board.h`. XFAs
addresses this problem.
So you are saying that the data gets duploicated in ROM several times? I
did not know that. If that is the case, then
Hi,
I'm thinking about to revise the ESP32 board definitions and would need
an advice from experienced core developers.
Most (if not all) boards define their peripheral configuration of ADCs,
DACs and PWMs in `periph_conf.h` in a kind of static const arrays and
define macros based on the size of