I'm trying again to sort the definitions of board configurations. I feel
like doing this for the tenth time.
I have taken a look at many board.h, periph_conf.h, board_common.h and
periph_conf_common.h files for different platforms, eg., Arduino*,
Nucleo*, IoTlab, ...
The difference between *.h and their *_common.h counterparts is qute clear.
However, I'm still unsure what the difference between board.h and
periph_conf.h is. For example, LED pins are mostly defined in board.h
while the definition of the of I2C or SPI pins are defined in
periph_conf.h. What exactly makes the difference, LED pins as well as
I2C or SPI pins are determined by the board.
So the question is, what belongs in board.h and what in periph_conf.h?
Are there any rules or guidelines.
in `periph_conf.h` we configure all the MCU/CPU peripherals, i.e., SPI, I2C bus and so on,
these are typically not bound to a board. On the other hand, in `board.h` we configure all
board specific stuff, like for instance LEDs which are not part of the MCU. While LEDs also
need a certain GPIO pin to be configured, you can connect an LED to any (free) GPIO while
peripheral busses are bound to certain pins on most MCUs - except for, e.g. TIs CC2538.
However, you're right it is (in parts) a bit confusing what to configure where (and why).
I have to disagree here. While the peripherals belong to the MCU
hardware-wise, the actual board might limit the available
configurations, as pins might be used as GPIOs, and the peripherals
might not be available. Therefore it would also belong to the board.h.
IMO it is *possible* to merge into board.h and omit periph_conf.h to
make it more clear. The only argument for keeping it seperate would be
the re-usaility of periph_conf.h, on the other hand a board_common.h
could be created and re-used as well.
While the peripherals belong to the MCU
hardware-wise, the actual board might limit the available
configurations, as pins might be used as GPIOs, and the peripherals
might not be available. Therefore it would also belong to the board.h.
There's another layer: the application.
board.h should define hard-wired stuff (LEDs, stuff that is actually
hard-defined by the board). periph_conf.h contains a (default)
"peripheral configuration" that an application might want to (and almost
always does) override.
One problem is that much here is not entirely clear. E.g., some Nucleos
have an LED on an also exposed IO pin, or boards can be run with both
internal and external OSC, or SAMR21-XPRO have an integrated at86rf233
hard-wired to an SPI, so all "boards" using that CPU should configure
that SPI if but only if that RF chip is used by the application.
Also, some stuff is actually difficult to express nicely with C.
Usually for every piece of configuration, you'll find arguments to move
it somewhere else. But usually, the next place is just a different
trade-off.
Currently, we're trying for uniformity and consistency, so as soon as a
location is determined, it is at least the same for all boards.