toggle quoted messageShow quoted text
On 27 April 2018 at 14:53, Cufi, Carles <Carles.Cufi@...>
In case anyone is wondering, the current dtc version in our Windows packaging scheme is 1.4.4, so we should be safe in this regard.
Guidelines for default board configuration are now documented in Zephyr board porting guide.
Next step will be to get all existing boards to comply with these guidelines.
I've open issue #7191: boards: Move existing boards to "default configuration guidelines" to drive this.
PR #7176 has also been created to provide a reference for board configuration, comments are welcome.
Please note that this activity has a dependency on upcoming SDK v0.9.3, as introduction of connectors
in device tree files requires usage of dtc > v1.4.1 .
On 29 March 2018 at 17:14, Erwan Gouriou <erwan.gouriou@...> wrote:
On 29 March 2018 at 17:04, Erwan Gouriou <erwan.gouriou@...> wrote:
Thanks for the feedbacks, I'll fill a GH Issue and try to get this progress
On 28 March 2018 at 14:13, Marti Bolivar <marti@...> wrote:
On 28 March 2018 at 13:41, Bøe, Sebastian <Sebastian.Boe@...> wrote:
documented guidelines and standards would be great.
"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.
Boards should be expressing:
"This is what this HW can do"
Applications should be expressing:
"This is what my application needs"
Agreed. Then we might turn this into:
"c) Configure board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
Ethernet, VCP, )"
So that enabling (activation) is application responsibility.
With this modification, I think this list sounds great for users (and should make things more consistent and simple for developers and reviewers too).
Thanks a lot, Erwan, for driving this.
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.
email@example.com <firstname.lastname@example.org> on behalf of Erwan Gouriou <erwan.gouriou@...>
Sent: Wednesday, 28 March 2018 11:54:44 AM
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)
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
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.
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 
I also have a short coming work using aliases and addressing:
#6017 Enable easy use of shields with overlays 
Zephyr-devel mailing list