Accessing MCU Peripherials not exposed by RIOT's peripherial drivers

Help
1

I want to access some features of an STM32’s ADC peripheral, that are not exposed by the periph_adc module. I’m toying with a few ideas and am seeking opinions on best practice for doing this kind of thing with RIOT.

I could omit the generic ADC driver and just make my own as a module under drivers/. This feels wrong because drivers/ are really meant for off-chip devices and should make use of the generic peripheral drivers.

Another approach is to extend the implementation of peripheral driver of the MCU I am concerned with. This leaves the generic API in-tact and allows anything using it to continue to function. This has the drawback that I would be modifying existing code, making it difficult to update RIOT in the future as I would have now forked code.

Is there a sensible approach to providing access to peripheral features that can’t be exposed in a generic way. I’m thinking about ioctl here.

1 Like
2

So to clarify some things,

  • You want a specific ADC feature on a specific MCU or MCU series
  • The periph_adc module does not contain this feature

I would suggest something like what is done with the periph_uart and MODULE_PERIPH_UART_MODECFG or MODULE_PERIPH_UART_COLLISION. These are optional extensions on the generic driver, as maybe not all MCUs may support this feature (or it just isn’t implemented).

This would mean you introduce a new module for the periph_adc something like MODULE_PERIPH_ADC_MY_FEATURE, then implement it in the cpu/<my_target_cpu>. Then expose it in the drivers/include/periph/adc.h. Ideally that cpu could describe its capability (currently with make and the FEATURES_PROVIDED but soon to be done in Kconfig). This would mean if you want to use that feature you would add a FEATURES_USED in the makefile and if the feature is not provided for that cpu or board then it would prevent building, effectively blocklisting (blacklisting) unimplemented boards.

Just a possible suggestion. The ioctl has been brought up but I think makes the “generic” apis a bit difficult.

1 Like
3

Thanks. I’ll look to the examples you cited for some inspiration.