Hi,

documented guidelines and standards would be great.

One comment:

"c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )"

Board authors should not be speculating about what board components
will be used by an application. If they do this users will have to turn off
components that they never asked to be turned on in the first place[0].

Boards should be expressing:
"This is what this HW can do"

Applications should be expressing:
"This is what my application needs"

I'm not saying this is easy, and perhaps achieving it requires some plumbing
that is not present yet, but this is the direction we need to be moving.

[0] https://github.com/zephyrproject-rtos/zephyr/issues/5454
________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org <zephyr-devel-bounces@lists.zephyrproject.org> on behalf of Erwan Gouriou <erwan.gouriou@...>
Sent: Wednesday, 28 March 2018 11:54:44 AM
To: zephyr-devel
Subject: [Zephyr-devel] Shave Zephyr boards with Occam's razor

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
Erwan

[1] https://github.com/zephyrproject-rtos/zephyr/pull/5381
[2] https://github.com/zephyrproject-rtos/zephyr/issues/6017