-
Notifications
You must be signed in to change notification settings - Fork 118
Built-in neopixel on QT Py M0 (and probably feather M4 CAN) shows incorrect colors #311
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
oh we should have DRVSTR up all the way anyways |
I checked, and didn't see it set anywhere. (Probably the assumption that it was set was what led to the problem.)
(The occurrances in variants are my patch. PR imminent, if you'd like...) |
sure, however, we should turn on drvstr for all gpio pins |
The "DRVSTR for all pins" idea has been brought up multiple times, and I've never seen a negative argument, but it hasn't happened yet, perhaps out of desire for the "third-party" forks to remain compatible with the main arduino fork? :-( |
we def use it for circuitpython, not sure why upstream doesnt do it. but we want to! |
|
On QTPy M0 boards running Arduino code, the onboard neopixel can show colors that are "red shifted" (actually, lacking in blue) from what they ought to be.
This appears to be because the neopixel on those boards is powered by a SAMD output pin, and by default that pin leaves the neopixel under-powered.
Workaround: add
to setup() in your sketch. (for QTPy)
The Feather M4 CAN board seems to have the same "powered by a pin" scheme, and so it probably has the same bug.
I have some concern that at maximum brightness levels, the power consumption of the neopixel may exceed even the "high current" drive of a SAMD output pin.
https://forums.adafruit.com/viewtopic.php?f=47&t=186027
(Hmm. This may also be a problem no the RP2040 boards with IO-powered neopixels; I think they have a similar "drive strength" setting.)
The text was updated successfully, but these errors were encountered: