cpu/fe310: factorize periph_gpio* provided features

[aabadie]

Contribution description

This is a simple PR that moves the periph_gpio* provided features from boards (hifive1/hifive1b) to cpu (fe310).

Testing procedure

• A green murdock
• hifive1/hifive1b are still listed in board supported list of tests/periph_gpio:

$ make -C tests/periph_gpio --no-print-directory info-boards-supported | tr " " "\n" | grep hifive
hifive1
hifive1b

Issues/PRs references

None

[benpicco]

GPIOs are not a feature of the board but a feature of the MCU.

[kaspar030]

This is a simple PR that moves the periph_gpio* provided features from boards (hifive1/hifive1b) to cpu (fe310).

Why? Board features represent what's wired up. An embedded fe310 might not have any pins that can be used, even though the CPU would support it.

[kaspar030]

GPIOs are not a feature of the board but a feature of the MCU.

So are UART, SPI and I2C. But a "board" might not have anything connected to actual MCU pins that could be used. That's why the features are per-board.

[benpicco]

This is splitting hairs.
GPIOs are always there, they don't require any board specific configuration while UART/SPI and I2C might be mapped to certain pins.

In the end, the less code you have to copy & paste when creating a new board, the better.

[kaspar030]

This is splitting hairs.
GPIOs are always there

Maybe, but this is how we handle this on all boards. If you disagree, please open a general discussion and don't start fixing single instances.

[fjmolinas]

Why? Board features represent what's wired up. An embedded fe310 might not have any pins that can be used, even though the CPU would support it.

+1

[aabadie]

This was already discussed in previous PRs. Look at other architectures (sam, stm, etc): they are doing the same.

What kind of application would you expect from a MCU where all pins are unused ?

[benpicco]

Maybe, but this is how we handle this on all boards.

sam0_common, lpc2387, stm32_common, atmega_common, nrf5x_common, efm32 etc do disagree. They all have this in their Makefile.features.

[kaspar030]

What kind of application would you expect from a MCU where all pins are unused ?

something that is not a devboard. If an MCU is used as coprocessor on a fixed PCB that on one end is connected to a host processor via UART and on the other end to e.g., a modem via another uart, with all the other pins not connected, announcing GPIO support is useless. Anyone still interested in using GPIO can just build anyways and ignore the "feature not met" warning, but there's no need to build the gpio test application.

[kaspar030]

sam0_common, lpc2387, stm32_common, atmega_common, nrf5x_common, efm32 etc do disagree. They all have this in their Makefile.features.

Guess who commited those.

The idea of features always was "what is practically usable". That's a board level information for anything pinout related, even for gpio.

[aabadie]

@kaspar030, I'm sorry I don't understand your concern here.

on the other end to e.g., a modem via another uart, with all the other pins not connected, announcing GPIO support is useless

UART is based on gpio, so this is implicitly required.

Anyone still interested in using GPIO can just build anyways and ignore the "feature not met" warning

That's why it's nice to not have to bother at board level about the fact the gpio feature is provided or not. It's here because the cpu provides the feature.

[kaspar030]

@kaspar030, I'm sorry I don't understand your concern here.

My concern is that it is perfectly valid to have a "board" that has only some of its pins wired up, and all those are already taken by other peripherals. E.g., a UART and maybe USB, all set up in the board's periph_conf.h, and no other MCU pins connected. In that case, there is no gpio available that could be used, as all pins are already "taken" by other peripherals. So periph_gpio should not be announced as "available feature", as it can only practically be used when unconfiguring other peripherals. In that case, the feature map needs to be adapted anyways.

[benpicco]

It is not uncommon for other peripherals (uart/spi/i2c) to depend on the GPIO API.

[kaspar030]

It is not uncommon for other peripherals (uart/spi/i2c) to depend on the GPIO API.

In that case, it is valid for the cpu to add the dependency to the periph_gpio module. Still it is a board configuration whether the feature should be announced.

This discussion is quite academic, as AFAIK all current boards in RIOT are dev boards with some exposed pins.

[kaspar030]

This discussion is quite academic, as AFAIK all current boards in RIOT are dev boards with some exposed pins.

Ok, you have convinced me. periph_gpio is never depending on any configuration within the board's periph_conf.h and can always be used (even if it doesn't make much sense). That's different to e.g., i2c or spi that only works if the board provides configuration.