Hey Miguel, thanks for the background that helps a lot.
I agree that (if this is the way the pwm api should work) the top value should be explicit. As the return value from pwm_set_frequency would be an option - given its prominence though it would probably make sense to add an API call for it or add it as a member to `struct pwm_dev`. At least that way the dependency between the application and driver implementation gets broken. It would be great if we could nail that down here so I can implement the stm driver correctly the first time ;). The pin-less PWM is more a result of calling the APIs in the wrong order. I couldn't come up with a use case but also wasn't sure if it should be supported. I do have robot though where the h-bridge is a bit hard to control. What I ended up doing was to generate the same PWM in 2 hw-units and depending on state enabled one of the output pins. Good stuff, Markus On Thu, 1 Mar 2018 00:48:36 -0300 Miguel Azevedo <miguella...@gmail.com> wrote: > 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 > > > > > > > > >
