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. > 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. 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¹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
