Hi Markus, > According to the doc the duty cycle should be absolutely defined between 0 > (no output) and 65535 (full output). Yes, the doc on the PWM API wasn't updated after the first drivers got implemented, if you take a look at pwm_nrf52 on my latest pull request on PWM the driver's doc is different.
> Just to be clear, the way I understand the interface a call like > > pwm_enable_duty_cycle(pwm, 0, 0x7FFF); > > should always lead to a 50% duty cycle, regardless of what the pwm frequency > was set to and regardless of what counter frequency is internally used by the > pwm driver. Well, in a general way PWM uses clock division, so in practice you have a top value, which is clock_freq/pwm_freq and this should be the 100% duty cycle. Some versions ago there was a PWM HAL API, I based the current PWM API on that one, with a few differences which BTW where discussed on this mailing list. Why not convert it and always have a 0 - 65535 and not have external code doing it? At the time I implemented the pwm_nrf52 and soft_pwm drivers it made more sense to have the duty cycle fraction value based on the top value. This is because it would totally respect the resolution and remove the need to convert from one value range to another each time we change duty cycle. If you convert it internally every time you change the duty cycle, which probably will happen frequently, it won't be as efficient as calculating a top value once you set the frequency(something which is likely to happen less frequently). > I would appreciate any clarifying comments as to what's going on here - or > where I'm going wrong. What happens here is that I forgot to change the documentation, although the drivers work consistently the way I just described. Just to be clear here: I understand your concern about the fraction range and that it is on the older API. It still makes sense to me to use the real range and calculate the top value when we set the frequency rather than converting from one value range to another every time we change the duty cycle, its just the way PWM works. Probably it would be better to return a top value on the set_frequency function, this is one of the changes would like to propose. > The second question has to do with the sequence of api calls and at what > point the PWM is actually started (which is an explicit step for STM32s). > - Is it a safe assumption that an application must call pwm_chan_config for a > channel before it can call pwm_enable_duty_cycle? Absolutely. As far as we go we need to set a GPIO output before we fire up a PWM channel. > - Is there support for kicking off a PWM channel without configuring an > output pin? No, can you give us a use case where that would need happen? > Lastly, in some email archive about the original PWM driver thread I found a > reference to 'hal_pwm' - which I can't even find a header for. Did this get > removed from the repo? Yes, it did, here you have it: https://github.com/apache/mynewt-core/blob/mynewt_0_9_0_tag/hw/hal/include/hal/hal_pwm.h Best, Miguel On Wed, Feb 28, 2018 at 9:53 PM, markus <mar...@bibi.ca> wrote: > I started implementing a PWM driver for the STM32 processors a few days ago > and ran into an issue I need clarification. According to the doc the duty > cycle should be absolutely defined between 0 (no output) and 65535 (full > output). > > However, pwm_test and pwm_nrf52 require the application code to get the base > frequency, calculate the top value from that and then scale the duty cycle > accordingly. > > Just to be clear, the way I understand the interface a call like > > pwm_enable_duty_cycle(pwm, 0, 0x7FFF); > > should always lead to a 50% duty cycle, regardless of what the pwm frequency > was set to and regardless of what counter frequency is internally used by the > pwm driver. > > I would appreciate any clarifying comments as to what's going on here - or > where I'm going wrong. > > The second question has to do with the sequence of api calls and at what > point the PWM is actually started (which is an explicit step for STM32s). > - Is it a safe assumption that an application must call pwm_chan_config for a > channel before it can call pwm_enable_duty_cycle? > - Is there support for kicking off a PWM channel without configuring an > output pin? > > Lastly, in some email archive about the original PWM driver thread I found a > reference to 'hal_pwm' - which I can't even find a header for. Did this get > removed from the repo? > > Thanks a lot, > Markus > > > -- -- Miguel Azevedo
