Re: PWM API, new features should be driver specific or not?

Awesome indeed! On Fri, 09 Mar 2018 10:32:49 -0800 "Sterling Hughes" wrote: > Awesome, thanks @mlaz. > > On 8 Mar 2018, at 21:00, Miguel Azevedo wrote: > > > Hi Markus, and everyone else, > > > > My proposal for changes on our PWM API is on this PR (most

Re: PWM API, new features should be driver specific or not?

Awesome, thanks @mlaz. On 8 Mar 2018, at 21:00, Miguel Azevedo wrote: Hi Markus, and everyone else, My proposal for changes on our PWM API is on this PR (most recent commit): https://github.com/apache/mynewt-core/pull/836 I think it takes care of the oversized unorganized datastructure

Re: PWM API, new features should be driver specific or not?

Hi Markus, and everyone else, My proposal for changes on our PWM API is on this PR (most recent commit): https://github.com/apache/mynewt-core/pull/836 I think it takes care of the oversized unorganized datastructure problem and allows a clean use of basic PWM capabilities (i.e. looping a duty

Re: PWM API, new features should be driver specific or not?

wow - it's an email day for me I like the idea of having a single pointer for the additional values, or changing `data` to a pointer to said structure instead of a `void*` (and move the void* into that structure). Personally I probably would have combined the ISRs into a single callback

Re: PWM API, new features should be driver specific or not?

Hi again Markus, > I think your enhancements should be their own driver. Plain PWM is such a > basic need and feature that I think the interface for it should be as simple > as possible. I'm also concerned about the memory footprint increase, which is > 3x that of the original interface (and

Re: PWM API, new features should be driver specific or not?

Hi Miguel, I think your enhancements should be their own driver. Plain PWM is such a basic need and feature that I think the interface for it should be as simple as possible. I'm also concerned about the memory footprint increase, which is 3x that of the original interface (and that's just the

PWM API, new features should be driver specific or not?

Hi everyone, I recently implemented a few new features for the nRF52 PWM driver and will probably implement them for soft PWM as well. The features: * Interrupts fired every cycle with user handler and parameter data; * A mode where the device plays for n cycles; * Interrupts fired at the end of