Skip to content

discussion on architecture: supporting MCU and BOARD features in which files #8066

@temmihoo

Description

@temmihoo

Currently in several issues and pull requests there is ongoing work in refactoring the boards/* in a generally good direction. This sparked in me an idea I've chatted about in real life discussions several times over during the few years I've known RIOT.

Currently many features supported in the boards/* files are actually peripherals or features of the MCU silicon. Some of the boards are more limited than others in that not all MCU pins are mapped into connectors while some boards, such as the Nucleo families, are notably trying their best to map out all MCU pins into connectors.

Any which way, the features are on the MCU chip put there by the silicon foundry and at most they should be disabled by the board level files for the cases where a peripheral cannot be reached.

As the Nucleo families are specifically mentioned in the roadmap as something we as community would like to see fully supported, I feel that we should use the various Nucleo families as example in how a large family of related hardware should be supported.

Some of the Nucleo boards do have peripherals that are external to CPU and definitely they should be specified in BOARD level files. As all of the peripherals cannot be enabled all of the time (the MCU pins have multiple alternate functions only one of which is active at a given time), I think the BOARD spec should have the enables and disables for a default configuration and MCU level files should list all of the possible peripherals and somehow (in comments?) indicate which are alternate functions to which.

ST specifically has somewhat rigid peripheral to pin mapping and has had to work a lot to achieve the very good level of pin-compability within each STM32 family. You can pretty much drop in any STM32F0 to replace any other STM32F0 and the pins are not conflicting but of course you'll have somewhat different peripherals. All STM32 peripherals that are connected to external pins are mapped through the PORT abstraction and then there are some peripherals that are internal to the silicon and will not have any io pin.

The task of supporting all Nucleo boards is large and daunting and I'm feeling that this is best kept as an ideal goal that might not be ever reached, like world peace or something. However that ideal is very good in pointing us the way which we should go.

My goal in raising this issue is to...

  1. Get rid of unnecessary code repetition.
  2. Enable better support for peripherals for all boards.
  3. Make it easier to mentally map RIOT abstraction to reading the MCU specific Reference Manual

...by the means of making the software abstractions more in line with how the hardware are.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Discussion: RFCThe issue/PR is used as a discussion starting point about the item of the issue/PR

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions