Shave Zephyr boards with Occam's razor


Erwan Gouriou
 

TL;DR: Numquam ponenda est pluralitas sine necessitate
           (approx: define guidelines for default board configuration)

Hi,

Most of the boards supported in Zephyr tree could be configured in quite multiple ways,
either for pins configuration, hardware interfaces, instances of these interfaces and
then configuration of the drivers for each of these entities.
When porting a board and pushing it upstream, one will either copy configuration from
a similar board, either configure the board according to his constraints or interesting
new ideas.
Outcome is a great heterogeneity of configurations and discussions during reviews.
Besides, these various configurations don't make things easy when one try to enable
tests/samples running on multiple boards.

I propose to shave away board configuration multiplicity and promote few guidelines
defining default (in tree) board configurations:

a) When a connector (arduino, 96board, ....) is present, configure pins to fit this connector
b) Configure ips matching these pins (For instance configure SPI instance for arduino SPI)
c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )
d) Configure an output for console
e) Propose and configure a default network interface
f) Enable all GPIO ports
g) Provide device tree Zephyr aliases

These guidelines won't avoid discussions since some for these points will conflict for
some boards. Also, some points deserve clarification (configuration means configured
only or configured and enabled?).


g) introduces zephyr aliases and could be seen a separated topic:
Some are already used today, as a tacit rule, also known as LED0, SW0. I propose to
extend these to other components (SPI, I2C, .) and define them in board device tree file.
For instance:
       aliases {
                   zephyr,led0 = &green_led_1;
                   zephyr,sw0 = &user_button;
                   zephyr,spi = &spi3;
                   zephyr,serial = &uart2
       };
Using these aliases (and their generated #define) directly in samples/tests would help to
make tests generic without too much trouble. I've set this approach in practice in PR
#5381 [RFC] Add gpio nodes to stm32 based soc/boards [1]
I also have a short coming work using aliases and addressing:
#6017 Enable easy use of shields with overlays [2]

Best Regards

Join devel@lists.zephyrproject.org to automatically receive all group messages.