Wanting to send frames smaller than the declared object size

[devarishi7]

For a project i would like to be able to send not the complete output buffer but just a part of it in the interest of increasing the framerate.
I am using an object of 680 RGB (ws2812b) leds, and the refresh rate maxes out at almost 50Hz (by calculation 24 * 680 / 800 is about 20ms) In many cases the 680 pixels are not used, and so there is no real need to transmit them. The memory i have, and even the 'FillBuffers()' should be ok to execute, although the break should be done separately i guess, anyway i don't think there is an easy way to do this, unless i start modifying the private variables. I mean i followed the tree from Show() to Update()

void Update(bool)
    {
        // wait for not actively sending data
        while (!IsReadyToUpdate())
        {
            yield();
        }

        FillBuffers();

        i2sWrite(_bus.I2sBusNumber);
    }

and there i got a little lost, since i do suspect Fillbuffers() would have to be different, Anyway these things would in many cases be method specific and therefore rather complex to implement i guess. The question is really, is there a way ?

[Makuna]

The wire protocol would only allow you to shorten the number you send starting at the first pixel. In your example of 680 pixels, you might be able to send the first 100, the first 200, but never would you be able to send the last 200 or skipping any at the front.

The internal buffer for sending MAY contain not only pixel data but may also include pre-ambles and or post-ambles. The WS2812b doesn't, but my library supports more than that one chips protocol. Further, it may also include the reset signal tagged onto the end of the send buffer, sometimes completely and sometimes just a small part that is looped for the reset time needed. These implementation details are abstracted at a low level; but limit at a high level what can be modified or accomplished to a standard supportable model.

My suggestion when the wire protocol is slowing you down, then use parallel channels/busses. For methods that don't support true parallel (bitbang, i2s non-parallel mode), you would just call Show on the busses you want to update. On methods that do (ESP32 i2s supports 8x and even 16x parallel channels method) then the show will send them all out in parallel and thus faster. 680 divided by 8 channels is only 85, and thus reducing the time to send to only the time needed for 85 pixels.

[devarishi7]

you might be able to send the first 100, the first 200, but never would you be able to send the last 200 or skipping any at the front.

This is totally clear to me. (also i really don't see a purpose for that) I did modify the adafruit_neopixel.h to suit my needs initially. (years ago..) a Bit-banged method on an AVR was holding up processing when there was no need for that. I just ended up modifying show() to take a number of pixels as an argument, and since the frame-reset was done by a simple micros() function calculation that was all there was to it. I did add the overloaded show() without the argument, simple calling show(all-pixels) to prevent any of the existing code from breaking.

These implementation details are abstracted at a low level; but limit at a high level what can be modified or accomplished to a standard supportable model.

I did figure that much, but at some point looking thru the code i got seriously lost and wasn't really sure what was what anymore.

My suggestion when the wire protocol is slowing you down, then use parallel channels/busses.

The way we use it actually is always using a single chain ledstrip with varying length. Several objects are placed near each other, parallel busses are not practical as such, These are deco objects for for parties setup in different configurations. More nodes is always an option, but several busses from the same node will rarely be practical. And really i don't want to try and explain that the objects should now be connected differently ! It is nearly always a rush job with nuts & bolts & cables, and trouble-shooting should be limited as much as possible.

The other issue is that mainly that even though 50Hz is fine, it seems wasteful to send say only 340 pixels with data and then send another 340 pixels without, and having to wait before starting again. The other thing is that the amount of pixels will only be known at runtime. Since i don't really want to mess with the memory allocation i can declare for the whole lot, but getting the time back for the pixels that are being sent but are not actually part of the Deco-object would be really nice.
Although i seriously doubt that anyone can see the difference between 50Hz & 100Hz with the naked eye, i would prefer not to have the discussion about it.

The other option would of course be to declare a pointer to an object statically, and declare the actual object dynamically with varying size, in some ways that would be trying to resolve the issue on a higher programming level, but also that would mean messing with the memory allocation, which is what i am trying to avoid.

[Makuna]

"is that the amount of pixels will only be known at runtime"

To be clear, you are not changing the number between calls to Show(), you change the number based on the configuration at the specific site? How do you set/store this number of pixels to update? A configuration file (spiffs/attached SD)? An exposed configuration interface (web page, uart protocol)?

In these cases, the common practice to follow is when the device turns on, it retrieves the configuration for its store (EEPROM/SPIFFS/SD/etc), and then dynamically creates the NeoPixelBus once using the number pixels (configuration). If reconfigured while powered, store the configuration for later power on, then delete the current one and create a new one OR just reset the device. If not resetting, then this sort of action is expected to be done rarely, so this isn't the solution for some sort of active animation or dynamic optimization. 

[devarishi7]

Yes, i understand that this is good common practice, it was the fallback plan to do it that way, I would prefer a reset would not be needed. Basically after connecting everything, the number of pixels would be determined, by a bit of calculus icw trial and error, then stored in EEPROM in case of a power down. Ideally i would not want to have to reset, I also don't want to frag fragment the heap, but i guess i could first declare an object with a pre-defined maximum size. If i delete that, whatever memory is freed should suffice for the new object. Then there is just the matter of making sure nothing fills any gap that may have appeared on a permanent basis. You know, if i just maintain the existing object, but just change some of the parameters, i would actually know for sure this all works out. That was my train of thought. It was never about some active animation. I suppose i could just do a soft reset, then i also know for sure. Thanks for clearing that up.