-
Notifications
You must be signed in to change notification settings - Fork 236
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
Neopixel lib doesn't behave well with esp32-s3 boards that have an on board Neopixel #1188
Comments
It sounds like you may have a conflict with the built-in Neopixel on the board. Most hosts set-up that Neopixel to animate rainbow colors. Try turning that off by adding this fragment to your project's manifest.json (if your project's manifest already has a "config": {
"led": {
"rainbow": false
},
}, |
I have added config to the manifest and addresses the BLE issue the device no longer panics and disconnects when writing a packet that in turn sets a color. So the TFT feather works great now over BLE thanks for the tip. However, I don't see any improvement on the atoms3_lite. I wonder as I'm using the button to drive change of color on the neopixel on atoms3_lite, let me check quick if BLE works nicely on it and i will report back. However I think the code I have for the button press is not quite right somehow for the atoms3_lite. Something I noted is the last pixel losses its connection and goes out about a second after you press the button and when you click again its sets red again meaning the code is initialising again somehow as I'm setting currentColor to 0 and in the global scope. Red is the first color at index 1 Are there differences to the button implementations for the atoms3 and atoms3_lite respectively ? |
So I can report atom-s3-lite causes a panic on write for BLE even though the config you suggested is present. And it bugs out on button press also suggesting even though the config is there, there is still a conflict somewhere. |
It looks like the moddable/build/devices/esp32/targets/m5atom_s3_lite/setup-target.js Lines 27 to 34 in 787bf7c
That behavior is consistent across M5Atom targets and M5Stack Fire. To avoid breaking things, it would probably be best to initialize NeoPixels from the global Object.defineProperty(globalThis, "lights", {
enumerable: true,
configurable: true,
get() { // instantiate lights on first access
const value = new NeoPixel({});
Object.defineProperty(globalThis, "lights", {
enumerable: true,
configurable: true,
writable: true,
value
});
return value;
}
}); |
That works well now, all burning brightly and changing on button press now. Ble works great too. |
Very nice! Always good to see a glowing Neopixel image here. ;) I'll apply the patch above to the M5Atom & Fire ports so the behavior is consistent. |
Closing - fixes now committed. |
Build environment: macOS
Moddable SDK version: 3.9.4-88-ga7fc383c
Target device: m5atom_s3_lite and s3_tft_feather
Description
I think something is going on with the Neopixel implementation on these boards when using the neopixel lib with an external neopixel strip or ring it doesn't behave in the same way as using the same lib, same code tested across atom_s3 and works fine. In fact any of the esp32-s3 boards work expect the ones with an onboard neopixel. I may be missing something as there isn't much docs on this lib but there's an example blog post.
Steps to Reproduce
This is the main.js
This is the maifest
On the atom_s3_lite and tft_feather it bugs out on button press and Im not sure the currentColor gets updated, its almost as if every time I use the neopixel the code initialises again and sets it back to 0 . Worth also noting that they cause a panic in BLE that disconnects the device when you try write a packet. Should I be doing something different with the boards that have an onboard neopixel ?
Expected behavior
I would expect the atom _s3 and the atom_s3_lite to behave the same with the same code. However as I say its strange how these boards only with onboard neopixel are behaving strangely as it also works on the m5stack_cores3, so I could be missing some fundamental documentation for how to handle libs that have them baked in neopixel.
Other information
Works on atom_s3, m5stack_cores3
Doesn't work on atom_s3_lite and tft_feather_s3
The text was updated successfully, but these errors were encountered: