Hi Miguel I went ahead and added an API call to get the max duty value from the driver, this is what I came up with:
https://github.com/mlampert/mynewt-core/commit/1505c2f15aa175c456273eb2bb1c918093071c17#diff-6e1ac1dce00788efcedf1e166f74cdb5 if you (and everyone else interested in the pwm driver) could have a look and let me know if this is the direction we want to go. The code isn't ready for review, it's really just about the API change. Thanks, Markus On Wed, 28 Feb 2018 21:10:21 -0800 markus <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 > > > > > > > > > > > > > > > >
