Comments… > On Mar 31, 2016, at 1:59 AM, Greg Stein <[email protected]> wrote: > > On Mar 30, 2016 11:48 PM, "[email protected]" <[email protected]> wrote: >> >> Thanks Greg, >> >> That¹s new information for me on the LEDs visuals. Are you talking about >> PWM to control brightness or just visual blink rate? 16-bits seems large >> to me for specifying a duty cycle for brightness, but I have no > > Brightness. The human eye easily detects the difference between 1% and 2% > duty (on) cycle. It is evolved for those low level differences. Imagine an > asymptotic curve approaching 100% -- the first couple duty cycle ticks jump > upwards. That is the eye seeing the slight change. But that last 30% is > pretty level. I dont think it is a big deal to use a 16-bit value.
> >> experience. I was just imagining 8-bit PWM for LED color and brightness >> control kind of like 24-bit RGB. After a few searches it seems like >> most custom LED PWM chips are 12-bits. > > Like the 5940? Sure. I've got a couple of those. But in code, we don't > usually run around with 12 bit types :-) > > The 2811 is 8 bits per channel, but with 24 bits to play with, your fade-up > sequence will work great. Just not perfect white the whole way :-) > >> I chose channel intentionally, and I¹m open to hearing your comments. The >> chips I looked at have many pin multiplexing options for which pin >> connects to which PWM channel; a given channel has a small set (2-3 bits) >> of choices. In some, a pin can connect to one of several channels. Some >> channels can event connect to multiple pins simultaneously with some >> complicated synchronization (not covered in this simple API). Boiling that >> down, I felt the channel (actual silicon implementation of PWM) was the >> unique resource to acquire. The BSP, when binding the driver to the hal >> will give the pinmux information, clock source, clock divider, output >> settings etc as BSP-specific configuration. For generic boards like >> arduino, these channels will probably be called PWM_D8,PWM_D9 etc so they >> are named like the PWM arduino pins that are printed on the PCB, but on >> other custom boards, I think we¹d more likely see them named for the stuff >> they are controlling like SYSTEM_PWM_LED_RED, SYSTEM_PWM_LED_GREEN etc. > I like the term channel. > All good. In this respect, I am not familiar enough with newt's API design > to comment. > > As an *application* programmer, I want the enable/disable I quoted. > Generally, my app is targeted, so I already know the capabilities of my > platform and just want to start the damned PWM. No query needed. > >> I don¹t mind the idea of rounding to make it fit in a API like Will is >> suggesting taking frequency and duty cycle, but want to ensure that we >> have an API that is specified without rounding so there is a ³I know >> exactly what I am getting when I call this² method to drive the PWM. > > The enable() API as I quoted should be sufficient. The *query* API will > inform the app about rounding. "Given the specs I have queried, will my > enable() call fit within my tolerance?" > > Goal here: enable() is simple. Apps that need rigor can query. I also > believe most apps will know their target. They won't even query. Portable > apps which query will be the minority. > I agree on this one. I think for most cases the enable works and we can have some query functions for libraries to obtain the PWM most suited to their use (for example). >> I¹ll have to think more about adding the ³config² to the enable command. >> I was thinking that many PWMs have a synchronous way to change the duty >> cycle or period and that folks may want to reconfigure while enabled, but >> that seems like it could also be met by calling enable when its already >> enabled. > > Yup. Just call enable() again, with the new values. > > Consider: if you have a separate API to set duty cycle, what will the > reader think about calling that on an active pin? Do they need to call off > first? Then set the duty, and call on again? If they set the duty, does it > take effect immediately? Or do they need another call? ... But with my > proposed single function, it seems clear: just call it, and the pin will > run with those new parameters. Done. > > Cheers, > -g
