Skip to content

sys/board_common: add generic board_init() function#17008

Merged
fjmolinas merged 4 commits intoRIOT-OS:masterfrom
benpicco:board_common
Feb 23, 2022
Merged

sys/board_common: add generic board_init() function#17008
fjmolinas merged 4 commits intoRIOT-OS:masterfrom
benpicco:board_common

Conversation

@benpicco
Copy link
Contributor

@benpicco benpicco commented Oct 18, 2021

Contribution description

Usually board_init() will just initialize the on-board LEDs.
This PR provides a generic, weak board_init() function that can be used as a fall-back if the board does not define a customboard_init()

I also dropped the trivial board_init() functions from a few boards as an example.

Testing procedure

examples/blinky still works as expected.

Issues/PRs references

@benpicco benpicco requested a review from dylad as a code owner October 18, 2021 20:19
@benpicco benpicco requested review from fjmolinas and maribu October 18, 2021 20:20
@github-actions github-actions bot added Area: boards Area: Board ports Area: build system Area: Build system Area: sys Area: System labels Oct 18, 2021
@benpicco benpicco added Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation and removed Area: build system Area: Build system Area: sys Area: System labels Oct 18, 2021
@github-actions github-actions bot added Area: build system Area: Build system Area: sys Area: System labels Oct 18, 2021
@benpicco benpicco removed the Area: build system Area: Build system label Oct 18, 2021
@github-actions github-actions bot added the Area: build system Area: Build system label Oct 18, 2021
@benpicco benpicco added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Oct 18, 2021
@benpicco benpicco requested a review from gschorcht as a code owner October 18, 2021 20:52
@github-actions github-actions bot added Area: drivers Area: Device drivers Area: cpu Area: CPU/MCU ports Platform: ESP Platform: This PR/issue effects ESP-based platforms labels Oct 18, 2021
Copy link
Member

@maribu maribu left a comment

Choose a reason for hiding this comment

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

lgtm

gpio_init(LED##x##_PIN, GPIO_OUT); \
LED##x##_OFF; \
} while (0)

Copy link
Member

Choose a reason for hiding this comment

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

I think that drivers/include/led.h can be useful, as it e.g. already has a function like macro LED_OFF(x) and empty fallbacks for non-existing LEDs from 0 to 7.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure can do - but that would not help me with the gpio_init()

Comment on lines +190 to +192
#ifdef LCD_BACKLIGHT
gpio_init(LCD_BACKLIGHT, GPIO_OUT);
#endif
Copy link
Member

Choose a reason for hiding this comment

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

Do we really need to init this GPIO everytime we want to turn on a backlight ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And why only a single backlight if we can have multiple displays?

This should be moved to a separate PR, I just wanted to get this past CI.

@benpicco benpicco added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Oct 19, 2021
@fjmolinas
Copy link
Contributor

ping

@github-actions github-actions bot removed the Area: sys Area: System label Jan 27, 2022
#endif
#ifdef LED7_PIN
LED_INIT(7);
#endif
Copy link
Contributor Author

@benpicco benpicco Jan 27, 2022

Choose a reason for hiding this comment

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

Thinking about it, maybe this should better be moved to an auto_init_leds module

Copy link
Member

Choose a reason for hiding this comment

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

I like the idea :)

fjmolinas
fjmolinas previously approved these changes Feb 22, 2022
Copy link
Contributor

@fjmolinas fjmolinas left a comment

Choose a reason for hiding this comment

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

ACK on my side let's wait and see if anyone has comments and merge this.

@leandrolanzieri
Copy link
Contributor

Shouldn't we adapt documentation accordingly? It currently states:

[...] Board initialization functions are defined in board.c. This file must at least define a board_init() function that is called at startup. [...]

@benpicco benpicco removed the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Feb 22, 2022
@github-actions github-actions bot added the Area: doc Area: Documentation label Feb 22, 2022
@benpicco benpicco requested a review from basilfx as a code owner February 22, 2022 18:08
@github-actions github-actions bot added the Platform: native Platform: This PR/issue effects the native platform label Feb 22, 2022
@github-actions github-actions bot added the Area: core Area: RIOT kernel. Handle PRs marked with this with care! label Feb 22, 2022
@fjmolinas fjmolinas dismissed their stale review February 22, 2022 21:41

new changes

@fjmolinas
Copy link
Contributor

Hmm I see you also went for #16013, I think that the last commit was a bit too greedy to do in this one, now there is the question if "kernel_init.h" is the right place for the definition, here it just seems like it was used as a header that is known to be included everywhere.

@benpicco
Copy link
Contributor Author

benpicco commented Feb 22, 2022

Oh I just thought that if board.c no longer provides board_init(), there is no justification to declare it in board.h.

I can drop the commit if you prefer that.

@fjmolinas
Copy link
Contributor

Oh I just thought that if board.c no longer provides

I definitely agree, that's why in parallel I had nudged @chrysn on #16013, it's just the placing of the function I'm unsure off. As the PR was before I would have merged tomorrow.

@benpicco
Copy link
Contributor Author

What would be a better place for it?

@benpicco
Copy link
Contributor Author

I dropped 48088cb for now.

@github-actions github-actions bot removed Platform: native Platform: This PR/issue effects the native platform Area: core Area: RIOT kernel. Handle PRs marked with this with care! labels Feb 22, 2022
@fjmolinas
Copy link
Contributor

What would be a better place for it?

I don't know... but everything that touches core is a sensible spot, which is why I would rather avoid it from this PR :)

Copy link
Contributor

@fjmolinas fjmolinas left a comment

Choose a reason for hiding this comment

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

re-ACK

@fjmolinas fjmolinas merged commit 5920872 into RIOT-OS:master Feb 23, 2022
@benpicco benpicco deleted the board_common branch February 23, 2022 08:46
@OlegHahm OlegHahm added this to the Release 2022.04 milestone Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: boards Area: Board ports Area: build system Area: Build system Area: cpu Area: CPU/MCU ports Area: doc Area: Documentation Area: Kconfig Area: Kconfig integration CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Platform: ESP Platform: This PR/issue effects ESP-based platforms Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants