Skip to content
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

"Loop Sends" for repeating output stream on low memory builds. #771

Open
sparkplug23 opened this issue Feb 17, 2024 · 3 comments
Open

"Loop Sends" for repeating output stream on low memory builds. #771

sparkplug23 opened this issue Feb 17, 2024 · 3 comments
Assignees
Labels
active development This issue is a primary item I am actively working on. Interested testers add a comment. enhancement

Comments

@sparkplug23
Copy link

Is your feature request related to a problem? Please describe.
As discussed on Discord, sending the data stream multiple times to replicate the output. This would be particularly useful in low memory applications.

Describe the solution you'd like
An optional parameter to enable repeating pixel buffer multiple times. Perhaps with optional arg on begin, or simply a function that should be called during runtime (similar to usage settings). Runtime config would be easier than setting it when the class is defined. Since this is an optional feature, it may just be easier (memory efficient) to keep it as a build/template option.

In my personal use of this library, when I need to maintain FPS and have large data outputs (1000+ pixels) I have introduced a "decimate" feature. For example, if I had 1000 LEDs physically connected but the effect running only calculated the first 100 internal pixels then repeated this in sequence, instead of regenerating the internal colours from the effect/palette code, I would replicate the first 100 pixels 10 times (with SetPixelColour). This case would be decimate of 10% (ie only 10% of the output needs to be calculated). You could perhaps introduce this type of feature natively in NeoPixelBus as my repeated output is essentially this feature.

@Makuna Makuna self-assigned this Feb 17, 2024
@Makuna
Copy link
Owner

Makuna commented Apr 16, 2024

BTW, what platform are you using? I might have an alpha branch up shortly for AVR that supports this. ESP32 is next on the list.

@sparkplug23
Copy link
Author

I am mostly using esp32 these days as I work on my code, though will eventually compiling again on esp8266. I have added my own colour type into your library so it takes me some time to merge with your latest releases.

I will be able to test on the attiny85, this is what sparked this original conversation.

@Makuna
Copy link
Owner

Makuna commented Apr 17, 2024

This branch contains the current alpha version that builds only for AVR platforms. It should be fully compatible API; except for several things.

  1. For the NeoPixelBusLg, the GetPixelColor() will return the same exact value that you called SetPixelColor() with. Most would call this an improvement.
  2. The data that Pixels() points to is an array of RgbColors (or whatever the color object the feature you use). Most again would call this an improvement.
  3. Most buffers will also work only in DIB (device independent bits).

The new work that addresses this issue/request, is the ability to define a "repeated pixel count" and the strip pixel count; such that the repeated pixel count will repeat across the transmitted set or truncated if its longer than the strip pixel count.

If you don't want the repeated count, you would still instance your NeoPixelBus the same old way like...

NeoPixelBusLg<NeoRgbFeature, NeoWs2812xMethod> strip(PixelCount, PixelPin);

And when you call strip.GetPixelCount() it will return PixelCount.

If you do want a repeated count, you would pass two counts bracketed in curly braces like...

NeoPixelBusLg<NeoRgbFeature, NeoWs2812xMethod> strip({RepeatedCount, PixelCount}, PixelPin);

And when you call strip.GetPixelCount() it will return RepeatedCount; while still sending out the bus a total of PixelCount.

Let me know how it works for you. I am actively working on expanding this to all supported platforms.

@Makuna Makuna added the active development This issue is a primary item I am actively working on. Interested testers add a comment. label Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
active development This issue is a primary item I am actively working on. Interested testers add a comment. enhancement
Projects
None yet
Development

No branches or pull requests

2 participants