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
<[email protected]> 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

Reply via email to