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 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 use ROM once (in the .rodata section of
the appropriate periph driver object). You can see this in the .map
file in the bin dir after building, there should only be one reference
to each configuration struct.
I don't know if using the _NUMOF macro constitutes as usage with
regards to linker GC, if the compiler is smart then the struct itself
should not be allocated when you only use sizeof(pwm_conf) but never
reference pwm_conf itself.
Putting the configuration struct in the periph driver implementation
file is equivalent to putting it in the header from the compiler point
of view when building the periph driver, so it should be possible to
perform the same optimizations as when the configuration is in
periph_conf.h, which is good.
Putting the configuration in the periph driver implementation will
place the configuration inside the CPU, which is bad for flexibility
and configurability. Unless you also define an initializer macro
somewhere in the board config, e.g. periph_conf.h, which is a bit more
inconvenient than the current approach due to multi line macros
needing to escape newlines etc.
One possible alternative solution is to create a periph_conf.c file in
the board directory, and use extern declarations in periph_conf.h just
like you proposed in order to let the drivers access the structs. The
drawback here is that the compiler will not be able to optimize away
execution paths which are not reachable using the current
configuration. On some implementations this will make no difference
but on others this will make the code a lot larger due to multiple
large branches which would normally be optimized away due to dead code
elimination in the compiler.
XFA would also have the same drawback as the periph_conf.c solution,
because the whole array is not visible to the compiler during
compilation of periph/abcd.c, so it can't fully perform DCE and other
optimizations.
Best regards,
Joakim
On Mon, Dec 17, 2018 at 4:14 PM Gunar Schorcht <gu...@schorcht.net> wrote:
>
> 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 these arrays as follows:
>
> ```
> static const pwm_conf_t pwm_conf[] = {
> {
> .dev = MINI_TIMER0,
> .pin_ch = PWM_PINS_CH0,
> .div = MINI_TIMER0_DIV,
> },
> {
> .dev = MINI_TIMER2,
> .pin_ch = PWM_PINS_CH1,
> .div = MINI_TIMER2_DIV,
> }
> };
> #define PWM_NUMOF (sizeof(pwm_conf) / sizeof(pwm_conf[0]))
> ```
>
> 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.
>
> For ESP32-Boards I tried another approach. In `periph_conf.h` there is
> only a declaration of an external const variable `pwm_dev_num` which
> contains the number of PWM devices and the macro `PWM_NUMOF` is then
> defined as follows:
>
> ```
> extern const unsigned pwm_dev_num;
> #define PWM_NUMOF (pwm_dev_num)
> ```
>
> That's it. The complex configuration array of PWM is defined as static
> const array in the according .c file. The `prm_dev_num` variable is also
> defined there as usual:
> ```
> const unsigned pwm_dev_num = sizeof(_pwm_hw) / sizeof(_pwm_hw[0]);
> ```
>
> With this apporach, the pretty complex static configuration array
> `_pwm_hw[]` exists only once, the complexity of the configuration is
> hidden and the variable `pwm_dev_num` is also determin at compile time.
>
> The question I have is: should I change the board definitions according
> to the approach used by all other board definitions to be compatible
> with these board definitions, or can I leave them as they are?
>
> What would be your advice?
>
> Regards
> Gunar
>
> --
> Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
> kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
>
> _______________________________________________
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
