As I commented on #6192 the issue of PWM touches other entities as well.

All in all, PWM is not a specific peripheral in any mcu but is generally done utilizing hardware timer output compare functionality. Thus I think it could be better to abstract the pwm driver as utilizing underlying timer abstraction, which in turn would have relatively simple driver support for the real peripheral.

As to STM32 family, I personally think that supporting timers or pwm at BOARD level is outright wrong as it is the MCU that have the peripheral hardware on SoC die instead of boards. The MCU in turn are arranged so that the whole family of STM32* has four different timer types, of which individual MCU models have some combination of. The subfamily (F0...F7 etc etc) doesn't have much to do with what timers are on a specific model of MCU.

This in turn means that there is no such thing as "the timers in F3 series" as individual models inside the series differ quite a lot in how many which timers are in what register address. Notably the F3x4 has a high resolution timer for 10 channels, which the others do not have.

Now, I'm not opposing merging this PR but more like calling forth discussion on the topic of timer support in general. Most MCU families from all vendors have roughly similar timers, which usually do input capture and output compare in similar fashion. Some of these have functionality that aims at producing certain kinds of pwm but the timers themselves aren't actually pwm devices but counter registers connected to binary compare and clock along with dividers.

In #6192 I linked to a decent article on STM32 timers, which link I include here as well.

All in all, PWM is not a specific peripheral in any mcu but is generally done utilizing hardware timer output compare functionality

Not in any case -> e.g. the NRF52 has a dedicated PWM unit

As to STM32 family, I personally think that supporting timers or pwm at BOARD level is outright wrong

Yes, but that is why we do not do that -> the implementation is done for the CPU, the board merely configures it (e.g. pin configuration, which is board specific).

In general: I agree that the current form of the interface does not cover all the possible timer/PWM setups out there, BUT the interface is not meant to! The aim is, to create a slim, portable, straight-forward, and easy to use access to a CPU's major peripherals. The interface was never meant to cover all the possible configuration options one has -> this would be close to impossible looking at all the different features offered by all the vendors. So if one wants to use (some vendor specific) advanced features (like the advanced 10 channel timer for the STM32F334), one can always write a specialized driver (and define a specialized API) for exactly that functional unit - of course by loosing some means of portability then.

@haukepetersen So in this STM32 case is the PWM implemented on top of stm32 timer abstraction which is on the other pull request? If so, just adding more timer types as supported would immediately make them available for pwm generation as well.

I didn't know Nordic had directly pwm generating hardware. Apparently its register api is geared to modulating the PWM with some calculated waveform. Interesting.

@temmihoo not quite, the PWM implementation is impelemented independently from the low-level timer driver directly on register level. But it is still very simple to enable more PWM devices by adapting the straight-forward configuration in the periph_conf.h

rebased as #6184 was merged

rebased and fixed issue with tests/driver_servo

and go !

thanks!