adammhaile
commented
6 years ago Ah, ok... lesson learned. I use flake8, you use pylint. So, I've cleaned up 2 of the 3 pylint failures but admit I'm not 100% about what to do with this one:
adafruit_dotstar.py:49:0: R0902: Too many instance attributes (12/11) (too-many-instance-attributes)
Now, it's obviously because I added self._sk9822 as an instance attribute to the class. I found the limit in .pylintrc but don't want to just go increasing that value without understanding why you've chosen to limit it in the first place. (Though I assume it's to keep CircuitPython modules more tame than regular python modules.) And I don't currently have a great solution for creating that new mode without either:
- a new attribute
- making a current attribute do double duty
- simply making the new mode default.
So, I'll just hang back for now until I can get your opinion on how you would like things structured.
kattni
tannewt
@kattni - As discussed at Maker Faire, this adds support for SK9822 LED strips.
SK9822 data sheet here: https://cpldcpu.files.wordpress.com/2016/12/sk9822-led-datasheet.pdf Much of the protocol tweaks in this PR from the work done here: https://cpldcpu.wordpress.com/2016/12/13/sk9822-a-clone-of-the-apa102/
TL;DR version: APA102 superimposes a 440Hz PWM on the 19kHz base PWM to control brightness. SK9822 uses a base 4.7kHz PWM but controls brightness with a controllable constant current source. Because of this SK9822 will have much less flicker at lower levels and is still suitable for POV applications while maintaining full color depth even while dimmed. The on-chip brightness control is identical as for the APA102, however the end frame must be switched to all zeros and with 32 bits extra to better handle the SK9822 while still working for the APA102.
I would certainly love to see Adafruit carry the SK9822 LEDs (DotStar Plus maybe?). Far superior in my opinion :)
Notes on my changes In my own usage of this combined protocol (I've done ports into both FastLED and my own python library) I didn't have the option to send a 4 value tuple to a pixel that included brightness. Specifically that in the case of this library, that 4th value is applied to the on-chip brightness level instead of internal scaling. So that made my approach here a little different in order to not change the API.
Because of the per-pixel brightness I implemented it such that when SK9822 mode is enabled (meaning brightness control is always on-chip and not locally scaled, the per-pixel brightness will override the global brightness for that individual pixel. My change simply updates the brightness byte for each pixel whenever the global brightness is changed. Mainly I did it this way to save CPU cycles by not doing it on every call to
show(). But, because of that, the per-pixel brightness overrides global when in this mode.As for the new param in
__init__, I couldn't really decide what to call it, hence it just being calledSK9822at the moment. Open to suggestions. There's no reason this mode isn't valid for APA102 other than it may cause added flicker. But that may be fine for some applications. You'll still get the benefit of no loss of color-depth compared to local color scaling. So, maybe something more likeon_chip_brightness=True?Also, I fixed a bug I found with setting pixel color values using anintinstead oftuple. Noted in an inline comment.