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
<andrey.serdt...@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

Reply via email to