Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc/doxygen: add build system doc page for BOARD, CPU, FEATURE #12473

Merged
merged 1 commit into from
Jan 15, 2020

Conversation

fjmolinas
Copy link
Contributor

@fjmolinas fjmolinas commented Oct 16, 2019

Contribution description

This PR is part of #8420 and tries to get to a definition of what a BOARD, CPU and FEATURE is. Having an agreement on this should help resolving discussion on #11676 and others about what a FEATURE is and how it should be used. This should also help maintainability by having an agreement on the definition.

Testing procedure

  • Do you agree with the definitions?

  • Does naming make sense?

  • Does the placing make sense?

Issues/PRs references

Part of #8420

@fjmolinas fjmolinas added Area: doc Area: Documentation Area: build system Area: Build system Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR labels Oct 16, 2019
@fjmolinas
Copy link
Contributor Author

@cladmi if you can take a look and see if this makes sense with the global picture you had for these concepts/variables in the build system scope it would be much appreciated :)

Copy link
Contributor

@cladmi cladmi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This summarize well what I had also understood of the RIOT build system for BOARD/CPU/FEATURES.
It describe the currently expected state. It is not always respected and still has flaws but at least gives a common explanation.
I had my dirty version in #10062 (comment)

This document does not explain "why" it is this way but keeping with this allows releasing it as reference.
I got stuck not writing a similar document because I wanted to have the why and ended up with nothing.

On features a lot more could be said with with the policy/dependency resolution that somehow explain why it is this way, the limitation, the future, but is a big task on its own so good to not include it in there.

doc/doxygen/src/board-cpu-features.md Outdated Show resolved Hide resolved
doc/doxygen/src/board-cpu-features.md Outdated Show resolved Hide resolved
doc/doxygen/src/board-cpu-features.md Outdated Show resolved Hide resolved
doc/doxygen/src/board-cpu-features.md Outdated Show resolved Hide resolved
doc/doxygen/src/board-cpu-features.md Outdated Show resolved Hide resolved
@cladmi
Copy link
Contributor

cladmi commented Oct 30, 2019

Somehow, the fact that I only stayed in tracking issues tells me that there would have been good to have a place for documenting these earlier in the repository. To allow moving the still not entirely precise issues to the repository in a better formatted document.
I had issues writing these as documentation when my mind was not clear and there were 100 exceptions to this.

Not an RDM as it just representing what is supposed to be there and in a more loose format.
And still allow having things that are not yet in the repository but would seal the agreement on the evolutions.

It would also push to have documentation first for these things and prevent things that go against the documentation just because somebody wants it his way.

Copy link
Contributor

@aabadie aabadie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I llke this document, it makes things clearer with features. Maybe you could also add some words about: where features are provided (in Makefile.features), where features are required (in application Makefile or Makefile.dep) and eventually some words about the FEATURES_USED variable ?

FEATURES {#features}
========

`FEATURES_PROVIDED` are hardware (including toolchain) features (e.g.:`periph_hwrng`,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`FEATURES_PROVIDED` are hardware (including toolchain) features (e.g.:`periph_hwrng`,
`FEATURES_PROVIDED` are available hardware (including toolchain) features (e.g.:`periph_hwrng`,

========

`FEATURES_PROVIDED` are hardware (including toolchain) features (e.g.:`periph_hwrng`,
`periph_uart`) that are available or characteristics (e.g:`arch_32bits`) of a board.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`periph_uart`) that are available or characteristics (e.g:`arch_32bits`) of a board.
`periph_uart`) or characteristics (e.g:`arch_32bits`) of a board/cpu.

`periph_uart`) that are available or characteristics (e.g:`arch_32bits`) of a board.

Providing a `FEATURE`
--------------------
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
--------------------
---------------------

--------------------

For a `FEATURE` to be provided by a `board` it must meet 2 criteria, and for
`periph` and other `hw` it must follow the 3rd criteria.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is hw ?

--------------------

For a `FEATURE` to be provided by a `board` it must meet 2 criteria, and for
`periph` and other `hw` it must follow the 3rd criteria.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`periph` and other `hw` it must follow the 3rd criteria.
`periph` and other `hw` it must follow a 3rd criteria.

CPU/CPU_MODEL {#cpu}
======

`CPU` and `CPU_MODEL` refer to the `SOC` (system on a chip) or `MCU` (microcontroller)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SOC was already used earlier but not defined. I would move the definition when it's used the first time. Also no need to "highlight" it with backticks. Same for MCU. Maybe use italic ?

doc/doxygen/src/board-cpu-features.md Outdated Show resolved Hide resolved
and the way each manufacturer groups there products.

These variables allows declaring the `FEATURES` that the mcu/soc provides as well
resolving dependencies.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
resolving dependencies.
as resolving dependencies.

BOARDS {#boards}
======

In RIOT build-system terms a `BOARD` is a grouping of:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In RIOT build-system terms a `BOARD` is a grouping of:
In the RIOT build-system, the variable `BOARD` is a grouping of:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't agree with the need of mentioning variable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, but add a comma after terms, this is more readable.

sensor/actuator, but it doesn't necessarily provide that `FEATURE`.

e.g.:
- `samr21-xpro` provides a `at86r233` radio as well as the necessary
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- `samr21-xpro` provides a `at86r233` radio as well as the necessary
- `samr21-xpro` provides a `at86rf233` radio as well as the necessary

@fjmolinas fjmolinas added this to the Release 2020.01 milestone Dec 16, 2019
@fjmolinas
Copy link
Contributor Author

@aabadie addressed your typo comments and requested for more info in two commits.

@aabadie
Copy link
Contributor

aabadie commented Jan 14, 2020

addressed your typo comments and requested for more info in two commits.

I still see unaddressed comments. Did you forget to push ?

@fjmolinas
Copy link
Contributor Author

I still see unaddressed comments. Did you forget to push ?

Damn I did, will address tomorrow

@fjmolinas fjmolinas force-pushed the pr_board_cpu_features_doc branch from c6b789d to 692ae71 Compare January 15, 2020 08:11
@fjmolinas
Copy link
Contributor Author

@aabadie rebased and now your comments are addressed please take a look.

@fjmolinas
Copy link
Contributor Author

ping @aabadie

Copy link
Contributor

@aabadie aabadie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All my comments are addressed and the document is now IMHO in a good shape.

ACK

@aabadie
Copy link
Contributor

aabadie commented Jan 15, 2020

Please fix the remaining whitespaces, you can squash directly.

@fjmolinas fjmolinas force-pushed the pr_board_cpu_features_doc branch from 692ae71 to e31c07d Compare January 15, 2020 12:55
@fjmolinas
Copy link
Contributor Author

@aabadie Maybe I should move this to the build-system-basics page? seems a little weird standing alone.

@fjmolinas fjmolinas force-pushed the pr_board_cpu_features_doc branch from e31c07d to 963ec79 Compare January 15, 2020 14:53
@fjmolinas
Copy link
Contributor Author

fjmolinas commented Jan 15, 2020

@aabadie Maybe I should move this to the build-system-basics page? seems a little weird standing alone.

Got ACK to do it IRL Offline.

@aabadie
Copy link
Contributor

aabadie commented Jan 15, 2020

I generated the doc locally and it looks nice. My ACK holds :)

@fjmolinas fjmolinas added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jan 15, 2020
@aabadie aabadie merged commit 784920b into RIOT-OS:master Jan 15, 2020
@fjmolinas fjmolinas deleted the pr_board_cpu_features_doc branch April 24, 2020 13:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: build system Area: Build system Area: doc Area: Documentation CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants