You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Miguel Azevedo <mi...@gmail.com> on 2017/07/11 03:31:14 UTC
PWM Driver
Hi,
I am currently developing a PWM driver for mynewt, more specifically a
driver for nRF52 based hardware.
Therefore I came up with this PWM high level API, which will be
described ahead on this e-mail.
Its source code:
https://github.com/mlaz/mynewt-core/blob/pwm_dev/hw/drivers/pwm/include/pwm/pwm.h
This API is based in both the current ADC high level API
https://github.com/apache/mynewt-core/blob/master/hw/drivers/adc/include/adc/adc.h
and the abandoned hal_pwm API
https://github.com/apache/mynewt-core/blob/090_dev/hw/hal/include/hal/hal_pwm.h
.
The API itself is roughly the same as hal_pwm exposes, which aligns
with the following concepts:
-It is assumed that within a system there is a number of discrete PWM
devices which provide a number of channels per device.
-These devices are configurable, its configuration typically
contemplates all the parameters which affect all the provided channels
(global to the device).
-A channel is also configurable and its configuration may or may not
affect other channels provided by the same device, depending on the
device's configuration.
I would be glad to have some feedback from the community, in order to
validate this approach.
Regards,
--
Miguel Azevedo
Re: PWM Driver
Posted by Miguel Azevedo <mi...@gmail.com>.
Yes Marko, pwm_set_frequency_func_t() is to set the frequency of
device. The comment you mentioned makes no sense to me either, it was
inherited from hal_pwm I just forgot to delete it. I see no reason for
this operation to affect channels provided by other devices.
Thanks for your feedback :)
On Tue, Jul 11, 2017 at 5:56 PM, marko kiiskila <ma...@runtime.io> wrote:
> Hi,
>
>> On Jul 10, 2017, at 8:31 PM, Miguel Azevedo <mi...@gmail.com> wrote:
>>
>> I am currently developing a PWM driver for mynewt, more specifically a
>> driver for nRF52 based hardware.
>> Therefore I came up with this PWM high level API, which will be
>> described ahead on this e-mail.
>> Its source code:
>> https://github.com/mlaz/mynewt-core/blob/pwm_dev/hw/drivers/pwm/include/pwm/pwm.h
>>
>> This API is based in both the current ADC high level API
>> https://github.com/apache/mynewt-core/blob/master/hw/drivers/adc/include/adc/adc.h
>> and the abandoned hal_pwm API
>> https://github.com/apache/mynewt-core/blob/090_dev/hw/hal/include/hal/hal_pwm.h
>> .
>> The API itself is roughly the same as hal_pwm exposes, which aligns
>> with the following concepts:
>> -It is assumed that within a system there is a number of discrete PWM
>> devices which provide a number of channels per device.
>> -These devices are configurable, its configuration typically
>> contemplates all the parameters which affect all the provided channels
>> (global to the device).
>> -A channel is also configurable and its configuration may or may not
>> affect other channels provided by the same device, depending on the
>> device's configuration.
>>
>> I would be glad to have some feedback from the community, in order to
>> validate this approach.
>>
>
> In general this seems reasonable, I like it. And thanks for picking up the effort.
>
> For clarification; setting frequency for a pwm_dev
> would set it for all channels belonging to that pwm_dev? Comment on the
> function prototype for pwm_set_frequency_func_t() says that ‘it might’ affect other
> channels, and this confuses me :) What do you mean by that comment?
>
> —
> M
--
--
Miguel Azevedo
Re: PWM Driver
Posted by marko kiiskila <ma...@runtime.io>.
Hi,
> On Jul 10, 2017, at 8:31 PM, Miguel Azevedo <mi...@gmail.com> wrote:
>
> I am currently developing a PWM driver for mynewt, more specifically a
> driver for nRF52 based hardware.
> Therefore I came up with this PWM high level API, which will be
> described ahead on this e-mail.
> Its source code:
> https://github.com/mlaz/mynewt-core/blob/pwm_dev/hw/drivers/pwm/include/pwm/pwm.h
>
> This API is based in both the current ADC high level API
> https://github.com/apache/mynewt-core/blob/master/hw/drivers/adc/include/adc/adc.h
> and the abandoned hal_pwm API
> https://github.com/apache/mynewt-core/blob/090_dev/hw/hal/include/hal/hal_pwm.h
> .
> The API itself is roughly the same as hal_pwm exposes, which aligns
> with the following concepts:
> -It is assumed that within a system there is a number of discrete PWM
> devices which provide a number of channels per device.
> -These devices are configurable, its configuration typically
> contemplates all the parameters which affect all the provided channels
> (global to the device).
> -A channel is also configurable and its configuration may or may not
> affect other channels provided by the same device, depending on the
> device's configuration.
>
> I would be glad to have some feedback from the community, in order to
> validate this approach.
>
In general this seems reasonable, I like it. And thanks for picking up the effort.
For clarification; setting frequency for a pwm_dev
would set it for all channels belonging to that pwm_dev? Comment on the
function prototype for pwm_set_frequency_func_t() says that ‘it might’ affect other
channels, and this confuses me :) What do you mean by that comment?
—
M
Re: PWM Driver
Posted by Miguel Azevedo <mi...@gmail.com>.
Hi Sterling,
Yes, its purpose is to specify the channel.
Yes, there are PWMs where the duty cycle is per-channel, namely the
nRF52' PWM module, which also allows having the same duty cycle across
all channels and some other more complex setups. I am not sure if
there is a standard behaviour for these kind of modules. Please
correct me if I'm wrong.
The approach I described before aims not to assume much about the
hardware limitations and to be compatible with most
configurations/limitations. It is assumed that frequency is per
device, and duty cycle is per channel. However, since these modules
behave in such diverse ways, I believe we could allow the driver
implementation to impose the behaviour in the case individual channel
mode isn't supported. What do you think?
On Wed, Jul 12, 2017 at 7:45 PM, Sterling Hughes
<st...@gmail.com> wrote:
> Hi Miguel,
>
> I looked over the API, it looks good to me.
>
> In the pwm_enable_duty_cycle() function, I assume the uint8_t is for the
> channel. Are there PWMs where the duty cycle is per-channel, I would think
> generally the duty cycle would be across all channels?
>
> Sterling
>
>
> On 10 Jul 2017, at 20:31, Miguel Azevedo wrote:
>
>> Hi,
>>
>> I am currently developing a PWM driver for mynewt, more specifically a
>> driver for nRF52 based hardware.
>> Therefore I came up with this PWM high level API, which will be
>> described ahead on this e-mail.
>> Its source code:
>>
>> https://github.com/mlaz/mynewt-core/blob/pwm_dev/hw/drivers/pwm/include/pwm/pwm.h
>>
>> This API is based in both the current ADC high level API
>>
>> https://github.com/apache/mynewt-core/blob/master/hw/drivers/adc/include/adc/adc.h
>> and the abandoned hal_pwm API
>>
>> https://github.com/apache/mynewt-core/blob/090_dev/hw/hal/include/hal/hal_pwm.h
>> .
>> The API itself is roughly the same as hal_pwm exposes, which aligns
>> with the following concepts:
>> -It is assumed that within a system there is a number of discrete PWM
>> devices which provide a number of channels per device.
>> -These devices are configurable, its configuration typically
>> contemplates all the parameters which affect all the provided channels
>> (global to the device).
>> -A channel is also configurable and its configuration may or may not
>> affect other channels provided by the same device, depending on the
>> device's configuration.
>>
>> I would be glad to have some feedback from the community, in order to
>> validate this approach.
>>
>> Regards,
>>
>> --
>> Miguel Azevedo
--
--
Miguel Azevedo
Re: PWM Driver
Posted by Sterling Hughes <st...@gmail.com>.
Hi Miguel,
I looked over the API, it looks good to me.
In the pwm_enable_duty_cycle() function, I assume the uint8_t is for the
channel. Are there PWMs where the duty cycle is per-channel, I would
think generally the duty cycle would be across all channels?
Sterling
On 10 Jul 2017, at 20:31, Miguel Azevedo wrote:
> Hi,
>
> I am currently developing a PWM driver for mynewt, more specifically a
> driver for nRF52 based hardware.
> Therefore I came up with this PWM high level API, which will be
> described ahead on this e-mail.
> Its source code:
> https://github.com/mlaz/mynewt-core/blob/pwm_dev/hw/drivers/pwm/include/pwm/pwm.h
>
> This API is based in both the current ADC high level API
> https://github.com/apache/mynewt-core/blob/master/hw/drivers/adc/include/adc/adc.h
> and the abandoned hal_pwm API
> https://github.com/apache/mynewt-core/blob/090_dev/hw/hal/include/hal/hal_pwm.h
> .
> The API itself is roughly the same as hal_pwm exposes, which aligns
> with the following concepts:
> -It is assumed that within a system there is a number of discrete PWM
> devices which provide a number of channels per device.
> -These devices are configurable, its configuration typically
> contemplates all the parameters which affect all the provided channels
> (global to the device).
> -A channel is also configurable and its configuration may or may not
> affect other channels provided by the same device, depending on the
> device's configuration.
>
> I would be glad to have some feedback from the community, in order to
> validate this approach.
>
> Regards,
>
> --
> Miguel Azevedo
Re: PWM Driver
Posted by Jacob Rosenthal <ja...@gmail.com>.
Note: Miguel is working with me at my current client, so these questions
are really more for the newt community than him directly, as I can already
chat with him :)
What use cases do people want a pwm driver for, and thus what do we expect
this driver interface to do?
Is this a very simple way of creating a 0 to 100 duty cycle timer for
servos and dimming leds only and therefore we dont need to be general
enough to support any other use cases. Would other use cases be sibling
drivers or do we expect further libraries to be built on top of this
driver? My current use case is probably an nice interface for rgb led
'playback' of n leds.
It sounds kinda clean, if not more complex, to somehow create a whole
second os_device to handle a second timer/pwm channel. Especially as
peripherals could have n peripherals available and the time to know you
have no more devices available is at os_dev_create...Thoughts?
On Fri, Jul 14, 2017 at 3:11 AM, Sterling Hughes <
sterling.hughes.public@gmail.com> wrote:
> mlaz,
>
> I agree with you. If it’s possible, it would be great to see how
> somebody could implement pwm_play() on top of the pwm driver, perhaps as a
> package. But I think a better route is to find the most portable ppm
> options, and get those going first.
>
> Sterling
>
>
> On 13 Jul 2017, at 17:54, Miguel Azevedo wrote:
>
> Hi Andrey,
>>
>> Well that would definitely make implementing the nrf52 PWM drivers way
>> easier. Although, to my knowledge, most of the PWM modules on other
>> devices don't provide features like playing duty cycle sequences. This
>> feature, is still implementable with the proposed API, using
>> pwm_chan_config(struct pwm_dev *, uint8_t, void *). In my opinion
>> having pwm_play() on this high level API would result in having
>> drivers which wouldn't implement it, I don't know if this is what we
>> want. I'm sure Sterling or Marko might have something to say about
>> this.
>> Thanks for your feedback!
>>
>>
>> On Thu, Jul 13, 2017 at 1:30 PM, Andrey Serdtsev
>> <an...@yotadevices.com> wrote:
>>
>>> Hi Miguel,
>>>
>>> IMO, there should be a possibility to playback PWM sequences as it
>>> supported
>>> by nRF52 hardware PMW module. Something like 'int pwm_play(struct
>>> pwm_dev *,
>>> uint16_t *pwm_sq, uint32_t pmw_sqsz)'.
>>>
>>> BR,
>>> Andrey
>>>
>>>
>>>
>>> On 11.07.2017 06:31, Miguel Azevedo wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I am currently developing a PWM driver for mynewt, more specifically a
>>>> driver for nRF52 based hardware.
>>>> Therefore I came up with this PWM high level API, which will be
>>>> described ahead on this e-mail.
>>>> Its source code:
>>>>
>>>> https://github.com/mlaz/mynewt-core/blob/pwm_dev/hw/drivers/
>>>> pwm/include/pwm/pwm.h
>>>>
>>>> This API is based in both the current ADC high level API
>>>>
>>>> https://github.com/apache/mynewt-core/blob/master/hw/drivers
>>>> /adc/include/adc/adc.h
>>>> and the abandoned hal_pwm API
>>>>
>>>> https://github.com/apache/mynewt-core/blob/090_dev/hw/hal/
>>>> include/hal/hal_pwm.h
>>>> .
>>>> The API itself is roughly the same as hal_pwm exposes, which aligns
>>>> with the following concepts:
>>>> -It is assumed that within a system there is a number of discrete PWM
>>>> devices which provide a number of channels per device.
>>>> -These devices are configurable, its configuration typically
>>>> contemplates all the parameters which affect all the provided channels
>>>> (global to the device).
>>>> -A channel is also configurable and its configuration may or may not
>>>> affect other channels provided by the same device, depending on the
>>>> device's configuration.
>>>>
>>>> I would be glad to have some feedback from the community, in order to
>>>> validate this approach.
>>>>
>>>> Regards,
>>>>
>>>>
>>>
>>
>>
>> --
>> --
>> Miguel Azevedo
>>
>
Re: PWM Driver
Posted by Sterling Hughes <st...@gmail.com>.
mlaz,
I agree with you. If it’s possible, it would be great to see how
somebody could implement pwm_play() on top of the pwm driver, perhaps as
a package. But I think a better route is to find the most portable ppm
options, and get those going first.
Sterling
On 13 Jul 2017, at 17:54, Miguel Azevedo wrote:
> Hi Andrey,
>
> Well that would definitely make implementing the nrf52 PWM drivers way
> easier. Although, to my knowledge, most of the PWM modules on other
> devices don't provide features like playing duty cycle sequences. This
> feature, is still implementable with the proposed API, using
> pwm_chan_config(struct pwm_dev *, uint8_t, void *). In my opinion
> having pwm_play() on this high level API would result in having
> drivers which wouldn't implement it, I don't know if this is what we
> want. I'm sure Sterling or Marko might have something to say about
> this.
> Thanks for your feedback!
>
>
> On Thu, Jul 13, 2017 at 1:30 PM, Andrey Serdtsev
> <an...@yotadevices.com> wrote:
>> Hi Miguel,
>>
>> IMO, there should be a possibility to playback PWM sequences as it
>> supported
>> by nRF52 hardware PMW module. Something like 'int pwm_play(struct
>> pwm_dev *,
>> uint16_t *pwm_sq, uint32_t pmw_sqsz)'.
>>
>> BR,
>> Andrey
>>
>>
>>
>> On 11.07.2017 06:31, Miguel Azevedo wrote:
>>>
>>> Hi,
>>>
>>> I am currently developing a PWM driver for mynewt, more specifically
>>> a
>>> driver for nRF52 based hardware.
>>> Therefore I came up with this PWM high level API, which will be
>>> described ahead on this e-mail.
>>> Its source code:
>>>
>>> https://github.com/mlaz/mynewt-core/blob/pwm_dev/hw/drivers/pwm/include/pwm/pwm.h
>>>
>>> This API is based in both the current ADC high level API
>>>
>>> https://github.com/apache/mynewt-core/blob/master/hw/drivers/adc/include/adc/adc.h
>>> and the abandoned hal_pwm API
>>>
>>> https://github.com/apache/mynewt-core/blob/090_dev/hw/hal/include/hal/hal_pwm.h
>>> .
>>> The API itself is roughly the same as hal_pwm exposes, which aligns
>>> with the following concepts:
>>> -It is assumed that within a system there is a number of discrete
>>> PWM
>>> devices which provide a number of channels per device.
>>> -These devices are configurable, its configuration typically
>>> contemplates all the parameters which affect all the provided
>>> channels
>>> (global to the device).
>>> -A channel is also configurable and its configuration may or may
>>> not
>>> affect other channels provided by the same device, depending on the
>>> device's configuration.
>>>
>>> I would be glad to have some feedback from the community, in order
>>> to
>>> validate this approach.
>>>
>>> Regards,
>>>
>>
>
>
>
> --
> --
> Miguel Azevedo
Re: PWM Driver
Posted by Miguel Azevedo <mi...@gmail.com>.
Hi Andrey,
Well that would definitely make implementing the nrf52 PWM drivers way
easier. Although, to my knowledge, most of the PWM modules on other
devices don't provide features like playing duty cycle sequences. This
feature, is still implementable with the proposed API, using
pwm_chan_config(struct pwm_dev *, uint8_t, void *). In my opinion
having pwm_play() on this high level API would result in having
drivers which wouldn't implement it, I don't know if this is what we
want. I'm sure Sterling or Marko might have something to say about
this.
Thanks for your feedback!
On Thu, Jul 13, 2017 at 1:30 PM, Andrey Serdtsev
<an...@yotadevices.com> wrote:
> Hi Miguel,
>
> IMO, there should be a possibility to playback PWM sequences as it supported
> by nRF52 hardware PMW module. Something like 'int pwm_play(struct pwm_dev *,
> uint16_t *pwm_sq, uint32_t pmw_sqsz)'.
>
> BR,
> Andrey
>
>
>
> On 11.07.2017 06:31, Miguel Azevedo wrote:
>>
>> Hi,
>>
>> I am currently developing a PWM driver for mynewt, more specifically a
>> driver for nRF52 based hardware.
>> Therefore I came up with this PWM high level API, which will be
>> described ahead on this e-mail.
>> Its source code:
>>
>> https://github.com/mlaz/mynewt-core/blob/pwm_dev/hw/drivers/pwm/include/pwm/pwm.h
>>
>> This API is based in both the current ADC high level API
>>
>> https://github.com/apache/mynewt-core/blob/master/hw/drivers/adc/include/adc/adc.h
>> and the abandoned hal_pwm API
>>
>> https://github.com/apache/mynewt-core/blob/090_dev/hw/hal/include/hal/hal_pwm.h
>> .
>> The API itself is roughly the same as hal_pwm exposes, which aligns
>> with the following concepts:
>> -It is assumed that within a system there is a number of discrete PWM
>> devices which provide a number of channels per device.
>> -These devices are configurable, its configuration typically
>> contemplates all the parameters which affect all the provided channels
>> (global to the device).
>> -A channel is also configurable and its configuration may or may not
>> affect other channels provided by the same device, depending on the
>> device's configuration.
>>
>> I would be glad to have some feedback from the community, in order to
>> validate this approach.
>>
>> Regards,
>>
>
--
--
Miguel Azevedo
Re: PWM Driver
Posted by Andrey Serdtsev <an...@yotadevices.com>.
Hi Miguel,
IMO, there should be a possibility to playback PWM sequences as it
supported by nRF52 hardware PMW module. Something like 'int
pwm_play(struct pwm_dev *, uint16_t *pwm_sq, uint32_t pmw_sqsz)'.
BR,
Andrey
On 11.07.2017 06:31, Miguel Azevedo wrote:
> Hi,
>
> I am currently developing a PWM driver for mynewt, more specifically a
> driver for nRF52 based hardware.
> Therefore I came up with this PWM high level API, which will be
> described ahead on this e-mail.
> Its source code:
> https://github.com/mlaz/mynewt-core/blob/pwm_dev/hw/drivers/pwm/include/pwm/pwm.h
>
> This API is based in both the current ADC high level API
> https://github.com/apache/mynewt-core/blob/master/hw/drivers/adc/include/adc/adc.h
> and the abandoned hal_pwm API
> https://github.com/apache/mynewt-core/blob/090_dev/hw/hal/include/hal/hal_pwm.h
> .
> The API itself is roughly the same as hal_pwm exposes, which aligns
> with the following concepts:
> -It is assumed that within a system there is a number of discrete PWM
> devices which provide a number of channels per device.
> -These devices are configurable, its configuration typically
> contemplates all the parameters which affect all the provided channels
> (global to the device).
> -A channel is also configurable and its configuration may or may not
> affect other channels provided by the same device, depending on the
> device's configuration.
>
> I would be glad to have some feedback from the community, in order to
> validate this approach.
>
> Regards,
>