Skip to content

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

Closed
WestfW opened this issue Dec 13, 2021 · 6 comments · Fixed by #313
Closed

Built-in neopixel on QT Py M0 (and probably feather M4 CAN) shows incorrect colors #311

WestfW opened this issue Dec 13, 2021 · 6 comments · Fixed by #313

Comments

@WestfW
Copy link

WestfW commented Dec 13, 2021

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

      PORT->Group[0].PINCFG[15].bit.DRVSTR = 1;  // turn up neopixel power

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

@ladyada
Copy link
Member

ladyada commented Dec 13, 2021

oh we should have DRVSTR up all the way anyways
@hathach can you check if we turn on DRVSTR on gpio for samd21/samd51?

@WestfW
Copy link
Author

WestfW commented Dec 13, 2021

I checked, and didn't see it set anywhere. (Probably the assumption that it was set was what led to the problem.)

> pwd
/Volumes/MacOS/HD-Users/BillW/src/adafruit-samd

> gid DRVSTR
bootloaders/mzero/Bootloader_D21/src/ASF/sam0/utils/cmsis/samd21/include/component/port.h:245:    uint32_t DRVSTR:1;         /*!< bit:     22  Output Driver Strength Selection   */
bootloaders/mzero/Bootloader_D21/src/ASF/sam0/utils/cmsis/samd21/include/component/port.h:344:    uint8_t  DRVSTR:1;         /*!< bit:      6  Output Driver Strength Selection   */
bootloaders/sofia/Bootloader_D21_Sofia_V2.1/src/ASF/sam0/utils/cmsis/samd21/include/component/port.h:245:    uint32_t DRVSTR:1;         /*!< bit:     22  Output Driver Strength Selection   */
bootloaders/sofia/Bootloader_D21_Sofia_V2.1/src/ASF/sam0/utils/cmsis/samd21/include/component/port.h:344:    uint8_t  DRVSTR:1;         /*!< bit:      6  Output Driver Strength Selection   */
variants/feather_m4_can/variant.cpp:159:  port->PINCFG[bitnum].bit.DRVSTR = 1;  // turn up neopixel power
variants/qtpy_m0/variant.cpp:89:  port->PINCFG[bitnum].bit.DRVSTR = 1;  // turn up neopixel power

(The occurrances in variants are my patch. PR imminent, if you'd like...)

@ladyada
Copy link
Member

ladyada commented Dec 13, 2021

sure, however, we should turn on drvstr for all gpio pins

@WestfW
Copy link
Author

WestfW commented Dec 13, 2021

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? :-(

arduino#158

@ladyada
Copy link
Member

ladyada commented Dec 13, 2021

we def use it for circuitpython, not sure why upstream doesnt do it. but we want to!
cc @dhalbert

@hathach
Copy link
Member

hathach commented Dec 13, 2021

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants