Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 12 22:38
    foxieproducts synchronize #597
  • Sep 12 22:31
    foxieproducts opened #597
  • Sep 03 20:11
    mr-tm closed #540
  • Aug 20 08:41
    berrak opened #594
  • Aug 15 20:36
    Makuna updated the wiki
  • Aug 12 17:58
    Makuna closed #585
  • Aug 12 17:44
    Makuna labeled #587
  • Aug 12 17:44
    Makuna closed #593
  • Aug 12 17:43
    Makuna opened #593
  • Aug 10 00:37
    Makuna closed #592
  • Aug 09 21:51
    morganm5665 opened #592
  • Aug 07 14:45
    Makuna closed #588
  • Aug 07 14:45
    Makuna locked #588
  • Aug 07 14:44
    Makuna assigned #587
  • Aug 07 14:44
    Makuna labeled #587
  • Aug 07 14:44
    Makuna labeled #587
  • Aug 07 06:04
    giangchipsieucuoi edited #588
  • Aug 07 06:03
    giangchipsieucuoi opened #588
  • Aug 07 06:03
    giangchipsieucuoi labeled #588
  • Aug 06 16:25
    furynick opened #587
Michael Miller
@Makuna
BTW, c17++ should be fully compatible with older versions so the move upward is often just compiler flags. There are some very rare cases where some new warnings will appear but these are a good thing to look into.
Michael
@sparkplug23
I haven't yet had time to implement any fixes on the esp32, but it is definitely a huge issue now. I may have had some flickering in the past but now my devices stripbus output locks up. If I had any transitions (ie high data output) it freezes in seconds. The esp32 itself remains fully working (it is not hanging) but no output. I am going to implement drzony rtos solution soon to see if that can help
Michael
@sparkplug23

First results are promising

NeoEsp32I2s0Sk6812Method with RTOS pinned task for show appears to be working well (with mqtt/wifi active too). This method previously hung my esp32.

NeoEsp32Rmt0Sk6812Method still causes flickering

oh, crash. Will need to investigate. Had 5 minutes there
Drzony
@drzony
make sure you pin the task to Arduino core
ARDUINO_RUNNING_CORE
Michael
@sparkplug23
Thanks, was that a define you made yourself? (didn't work for me).
I just used xPortGetCoreID()which will give me the core the init part of my code is running from. For now, I am exclusively using dual core esp32's so I will worry about single core later
Drzony
@drzony
It's defined in Arduino core, but it might depend on the version you are using
Michael
@sparkplug23
Yeah cant seem to find it, I made sure the header was included correctly but still not showing. I will figure it later, 36 minutes running stable there (until I reflashed). No flickering noticed but only hitting 12 leds on my test rig
Thanks again for the code, dropped it into my big project and worked :) Going back over it now
I just had to add instance into the begin since my neopixel bus is inside another class
Michael
@sparkplug23
Uploading now to a few of my home automation devices that run 24/7 and will see how this works long term. Will report back if this helps. It would be great to introduce this as an example in neopixel library down the line.
Michael Miller
@Makuna
his sounds like a great topic to add to the wiki ;-)
Michael
@sparkplug23
Kinda unrelated, but from your experience you may have a nice solution for this. I am working on saving my crash reports like tasmota does in RTC_NOINIT etc, then using my binary to decode the crash.
Have you came across a nice program (or if arduino/vscode can nicely do this) to take a binary file saved from the last upload, and then copy and paste a crash stack? I want to start going after those illusive bugs that only happen once every few weeks now, harder to find.
Drzony
@drzony
nope
Michael
@sparkplug23
I have only done it via the built in decoder over serial. I have got many unique builds of my code (using defines to enable sensors etc) so need to work on a streamlined method. I need to look again how tas does it, its been a year since I looked
Drzony
@drzony
decoder is just a python script that reads the elf and decodes exception
you can run it separately
Michael
@sparkplug23
That is probably how they do it. Like I said, been a while. It is probably easier than I remember
I only have 12 leds plugged into test setup, but with sending for 1500 leds your method seems to be working well.
I also have another with 100 connected leds and it is good too
Michael
@sparkplug23
Gentleman, next fun!
Michael Miller
@Makuna
Wow, I missed that @drzony had editted the Wiki and added a great write up on ESP32 and the task mentioned above; LAST YEAR!
https://github.com/Makuna/NeoPixelBus/wiki/ESP32-and-RTOS-Tasks
Drzony
@drzony
TBH I forgot that too ;P
Michael
@sparkplug23
ha! well I just came back to report it has definitely helped. My project is big so still trying to dial in the changes across them all, but I probably have about 10 devices running the code right now without issue. The real text won't be until christmas though when I try to do 1000+ :)
Michael
@sparkplug23
I did try it outputting (in code set to 1500) but only had 12 leds connected, it seemed to work well. I am definitely reaching the limitations of my code at that level though, frame rates drop to about 10-20 fps so I need to dig into my code and optimise now with oscilloscopes.
Michael
@sparkplug23
Just added this to a device that had been up for 30 days, so will see if it really remains stable. The leds before were flickering but as indirect light on a ceiling it was hard to notice.
kleurbleur
@kleurbleur
Hey, I'm trying to follow the code from Peacepinguin https://github.com/peacepenguin/npb-complexblt/blob/master/src/main.cpp
But I get the following error: no matching function for call to 'NeoBuffer<NeoBufferMethod<NeoGrbwFeature> >::SetPixelColor(int&, RgbwColor&)'
Without the Blt method and the virtual strip the NeoGrbwFeature was working ok, just not on the second data pin.
Michael Miller
@Makuna
@kleurbleur The key thing to look at in that error is the NeoGrbwFeature and RgbwColor. These two related values point at that either the buffer or the strip are not defined with the same feature NeoGrbwFeature. Since the original used NeoGrbFeature I suspect you missed changing something.
kleurbleur
@kleurbleur
Ok, that must've been a typo on my side since I tried that already multiple times, the colour error is gone but I'm struggling now with the second pin output. Will get back here if needed, thanks already!
kleurbleur
@kleurbleur
Ok, not sure what's going on but for some reason I cannot get the second output pin to work. When I swap the wires on the board the other led strip does work, so it's not the wiring. Maybe a more seasoned eye has a suggestion?
https://github.com/kleurbleur/SK6812STRIP144RGBW-Olimex-POE-ISO/blob/master/src/main.cpp
The board I'm using is a ESP32 with ethernet but I can't imagine ethernet being the culprit.
Michael Miller
@Makuna
@kleurbleur get a 404 error from you source link. Checked you repo's, that one isn't public or present it seems. Check to make sure the pins you select are available for use as the ESP32 uses a lot of pins for other reasons and even restricts some pins. https://docs.espressif.com/projects/arduino-esp32/en/latest/boards/ESP32-DevKitC-1.html#pin-layout
kleurbleur
@kleurbleur
Weird, it's supposed to be an open repo and is working here. Here's a pastebin link: https://pastebin.com/sxUPNYLn
At the moment it seems to be that only the first declared pin is working. In the monitor I do get data and should be sending it to two pins.
Michael Miller
@Makuna
@kleurbleur So if you swap the pins by using...
const int PixelPin1 = 2;                 // make sure to set this to the correct pin
const int PixelPin2 = 4;                 // make sure to set this to the correct pin
Does the same pin continue to work?
kleurbleur
@kleurbleur
Nope, only the first row. So when above only pin 2, when swapped only pin 4.
Changing the NeoBusChannel to both 0 gives a reboot loop.Setting the other to 2 instead of 1 same problem as before.
In the case of NeoBusChannel_1 and _2, again only the first one works.
Michael Miller
@Makuna
The onDmxFrame callback, is this called during an interrupt? From an ISR? If so, then you can't call strip.Show() in that. Set a flag and in loop check the flag and call strip.Show().
kleurbleur
@kleurbleur
Not sure, but I did the flag in the loop and still the same issue... tried several other pins as well.
Here the pastebin of the try: https://pastebin.com/pxmPT8ig
Michael Miller
@Makuna
isolate to just neopixelbus, create a minimal sketch, and if it still reproduces, I will dig into it deeper. Include what versions of everything you are using.
kleurbleur
@kleurbleur
Made a sketch without artnet and simple first last led of each pin. Works.
Made a sketch with artnet lib loaded and running but setting the led's outside of the artnet lib space. Works.
Then made a sketch without artnet but with udp (underlaying protocol) with the same idea but controlled via udp messages. Works.
This makes me think it is within either the callback function that I wrote or within the artnet lib. I checked the lib but found nothing that uses interrupts or something similar. This is the artnet lib I'm using: https://github.com/natcl/Artnet
kleurbleur
@kleurbleur
Ok, fixed it... I did not realise that the NeoPixelBus objects start counting from 0 again when you have several. So for me adding just the line: led = led - numLed1; fixed it.
kleurbleur
@kleurbleur
Since the ESP32 felt quite slow I'm trying to get NeoPixelBus to work on a Teensy4.1. However I get quite a lot of errors during compiling. Is Teensy supported?
Here a pastebin with the errors: https://pastebin.com/tzU8JWNJ
Michael Miller
@Makuna
@kleurbleur Teensy is not a primary platform I work to support at. First, they don't spend any effort to put their board support into the list under the board manager. Second, there just isn't that much demand. ARM is something I would like to support more, but the interesting hardware support (so not doing bit bang) is often specific to a chip and not a general arm feature making it too broad of platform to support much.
There is ARM bit bang support, but do they include the standard platform defines to turn it on for what every it supports? The errors you see lead me to believe not. In the compile output, there is usually -D option that includes something like MK20DX128 or ARDUINO_ARCH_STM32L4 that will help.