cpu/native: Allow Access to Hardware GPIO Pins on Linux

[benpicco]

Contribution description

This adds GPIO support for native using the new Linux GPIO API.

Testing procedure

Compile tests/periph_gpio for the native board on any SBC, e.g. a Raspberry Pi.
Run bin/native/tests_periph_gpio.elf --gpio=/dev/gpiochip0

Please consult your board's manual for the pin mapping. For the Raspberry Pi, this would be

Here, GPIO20 and GPIO21 can be conveniently bridged with a jumper.

Setting and Reading GPIOs should work with this PR already:

> init_in 0 20
> init_out 0 21
> read 0 20
GPIO_PIN(0.20) is LOW
> set 0 21
> read 0 20
GPIO_PIN(0.20) is HIGH

For interrupts to work, #12428 is needed:

> init_int 0 20 2
GPIO_PIN(0, 20) successfully initialized as ext int
> init_out 0 21
> set 0 21
> INT: external interrupt from pin 20

Issues/PRs references

depends on #12428
supersedes #7530

[maribu]

This was on my to do list for quite some time, but I never came to id. Thanks for tackling this!

[fhessel]

I'd appreciate that feature, too! Just a short note here, with #11352 being merged now:

I think, the definition of SPI_HWCS(x) will need to be adjusted, as the hardware CS number space collides with the one used for GPIOs. The same goes for the functions using spi_cs_t parameters in spidev_linux.c. If I can help with that, just let me know.

[benpicco]

If you already have a solution in mind, feel free to send a PR to my native-gpio branch.
I don't quite understand yet how your !use_hwcs case works. All those /dev/spidev0.x files are hardware CS from the perspective of RIOT, no?

[fhessel]

By now, RIOT can only control hardware CS lines, as Linux' userspace SPI API only allows those hard-wired connections. In case of the Raspberry Pi, this is pin CE0 (GPIO8) on spidev0.0 and CE1 (GPIO7) on spidev0.1.

However, there is a flag in the SPI API called SPI_NO_CS, which corresponds to "1 dev/bus, no chipselect" on system level. My idea would be, if a valid GPIO pin is used for the cs parameter in RIOT, to use the first Linux spidev for that bus, set this NO_CS flag and control the chipselect line through RIOT's GPIO module. This was not possible without an implementation on top of the kernel's GPIO API.

If that works, it would allow arbitrary GPIOs for CS and also more than two devices. If not, I'd at least separate the number space, so that SPI_HWCS(0) != GPIO(0, 0). This allows to differentiate between actual GPIOs and values for HWCS, so that the developer can get proper feedback on what went wrong.

I'll have a look at it and see if that flag behaves like expected.

[fhessel]

Sorry that it took me so long, testing this with limited access to actual SPI hardware was not that easy.

benpicco#4 contains a suggestion to solve the numbering issue between SPI_HWCS and GPIO_PIN and to allow arbitrary GPIOs for the chip select line.

[mfp20]

No support yet?

[aabadie]

I haven't checked all the details but it seems to me that this PR is in quite a good shape. There's just the problem that I see with the module dependency that I think should be changed.

[miri64]

@aabadie your comments seem to be addressed. Care to take another look, please?

[benpicco]

I moved all the unrelated commits to a separate PR: #14663

[aabadie]

Looks good now. Please squash.

ACK!

[aabadie]

Murdock found a couple of problems. Can you have a look @benpicco ?

[benpicco]

Rebased to fix the warnings introduced by tests/driver_at86rf2xx_aes.