Is it possible not to declare the required memory for all parallel I2S channels on an ESP32 ?

[devarishi7]

I2S is as far as i know the most CPU efficient & most reliable way of creating a ledstrip data signal, The 8 channel parallel I2S is fantastic of course, with it's refresh rate being limited by the longest strip. Unfortunately it seems that the memory allocatedfor a single strip is almost the same as the memory allocated for 8 strips of the same maximum length.
I want to be able to transmit 680 pixels per channel, (4 universes) but even on a single channel, that results in an allocation of more than 130 Kb, with each additional strip requiring just over 2 Kb extra. It appears as the whole block is declared for all 8 channels initially, but i never intend to use all 8. Is there a way to circumvent this ?

[Makuna]

No, there isn't a way to use less than 8 channels using the i2s parallel mode.

The I2S hardware sends them using DMA using a parallel mode that is either 8 channels wide or 16 channels wide. It requires a DMA buffer to asynchronously send the data from; so stuck with either 8 or 16.

RMT methods support four channels (some ESP32 hardware up to 8 channels) but only the first four tend to be sent near the same time.

Some ESP32 hardware supports two i2s busses, so you could also get two channels using i2s in non-parallel modes.

[devarishi7]

Ah Ok, but a single channel, how do i define that ? I would be happy with 1 channel and a reasonable memory allocation for 680 pixels.

[devarishi7]

hmm i think i found it .
NeoEsp32I2s0Ws2812xInvertedMethod
where the 0 aftr I2s is the channel.
Somehow i think there is an example missing. I anyway have a hard time finding the documentation on the methods, is there i file somewhere that explains them all ?
I found the method through the keywords.txt, figuring that if it exists it should be in there. With most libraries the .h .cpp included files in there serve as a form of documentation, but that is not really the case here.
Google pointed me towards the example for the parallel I2s method for the ESP32, should it be pointing me somewhere else ?

[Makuna]

The parallel modes are special ones, single channels are easy.

NeoPixelBus<NeoGrbFeature, NeoWs2812xMethod> strip(PixelCount, PixelPin);

For two i2s busses (non parallel), it's like

NeoPixelBus<NeoGrbFeature, NeoEsp32I2s0Ws2812xMethod> stripA(PixelCountA, PixelPinA);
NeoPixelBus<NeoGrbFeature, NeoEsp32I2s1Ws2812xMethod> stripB(PixelCountB, PixelPinB);

for four RMT channels, it's like

NeoPixelBus<NeoGrbFeature, NeoEsp32Rmt0Ws2812xMethod> stripA(PixelCountA, PixelPinA);
NeoPixelBus<NeoGrbFeature, NeoEsp32Rmt1Ws2812xMethod> stripB(PixelCountB, PixelPinB);
NeoPixelBus<NeoGrbFeature, NeoEsp32Rmt2Ws2812xMethod> stripC(PixelCountC, PixelPinC);
NeoPixelBus<NeoGrbFeature, NeoEsp32Rmt3Ws2812xMethod> stripD(PixelCountD, PixelPinD);

or the alternate to have a single type and store the strips in an array

typedef NeoPixelBus<NeoGrbFeature, NeoEsp32RmtNWs2812xMethod> NPB;

NPB strips[] = {
NPB(PixelCountA, PixelPinA, NeoBusChannel_0),
NPB(PixelCountB, PixelPinB, NeoBusChannel_1),
NPB(PixelCountC, PixelPinC, NeoBusChannel_2),
NPB(PixelCountD, PixelPinD, NeoBusChannel_3)
 };

[Makuna]

I put the effort into keeping the Wiki up to date as much as possible.

https://github.com/Makuna/NeoPixelBus/wiki/Neo-Methods

[devarishi7]

Thank you !! so helpful, now just to get google to show me the correct path.

[devarishi7]

Eh, for the 2 channels of I2S (non parallel) , the definition at runtime through the creation of a NULL pointer is giving me issues, am i missing something, or is there no way to declare the object at runtime like there is for the parallel mode ?

[Makuna]

It is possible. How are you doing it? Show me the snippet of code.

[devarishi7]

i tried the same way it is done with the parallel method
`
const int Pin[] = {27, 26};

NeoPixelBus<NeoRgbFeature, NeoEsp32I2sNWs2812xInvertedMethod> *strip[] = {NULL, NULL};

void setup() {
strip[0] = new NeoPixelBus<NeoRgbFeature, NeoEsp32I2s0Ws2812xInvertedMethod>(680, Pin[0]);
strip[1] = new NeoPixelBus<NeoRgbFeature, NeoEsp32I2s1Ws2812xInvertedMethod>(680, Pin[1]);

strip[0] -> Begin();
strip[1] -> Begin();
}

void loop() {
static uint8_t i = 0;
delay(500);
switch (i) {
case 0:
for (uint8_t j = 0; j < 45; j++) strip[0]->SetPixelColor(j, RgbColor(255, 0, 0));
break;
case 1:
for (uint8_t j = 0; j < 45; j++) strip[0]->SetPixelColor(j, RgbColor(0, 255, 0));
break;
case 2:
for (uint8_t j = 0; j < 45; j++) strip[0]->SetPixelColor(j, RgbColor(0, 0, 255));
break;
}
i++;
i = i % 3;
strip[0]->Show();
}

and i am getting
cannot convert 'NeoPixelBus<NeoRgbFeature, NeoEsp32I2sMethodBase<NeoEsp32I2sSpeedWs2812x, NeoEsp32I2sBusZero, NeoEsp32I2sInverted> >' to 'NeoPixelBus<NeoRgbFeature, NeoEsp32I2sMethodBase<NeoEsp32I2sSpeedWs2812x, NeoEsp32I2sBusN, NeoEsp32I2sInverted> >' in assignment
`
For any of the changes. Now i figured i could create NULL pointers for any configuration i intend to use and call begin on the 2 objects i actually want to use and delete them when i don't want to use them, so i suppose there is a workaround, There must be a better way than that though.

[Makuna]

The Parallel methods internally allocate the channels, the N variant methods do not.

You are trying to put two different types into the array and arrays only contain a single type.

this is a type...

NeoPixelBus<NeoRgbFeature, NeoEsp32I2sNWs2812xInvertedMethod>

a better way to understand this is to create a named type and use it.

typedef NeoPixelBus<NeoRgbFeature, NeoEsp32I2sNWs2812xInvertedMethod> NPB;
NPB *strip[] = {NULL, NULL};

you can't just then assign it with a NeoPixelBus<NeoRgbFeature, NeoEsp32I2s0Ws2812xInvertedMethod>, it has to be a NPB.

With the N variants of methods, they take an extra argument on the constructor for the bus channel which you also didn't provide.

strip[0] = new NPB(680, Pin[0], NeoBusChannel_0);
strip[1] = new NPB(680, Pin[1], NeoBusChannel_1);

[devarishi7]

Ok, but how does that work when i want to have a different type of LED, say using the NeoEsp32I2sNSk6812Method ? Wouldn't that need a separate typedef and separate pointers ?

[Makuna]

Yes you will need different ones.

https://github.com/Makuna/NeoPixelBus/wiki/Smaller-Code

What does having an array of pointers give you? What are you trying to improve by using an array? What are you trying to solve?
Let alone, why are you needing to dynamically allocate the NeoPixelBus and using pointers rather than just statically define them?

[devarishi7]

Yeah i figured that much. I am not really trying to improve much by using an array, 2 variable would also work just fine, but when generating patterns for display on the strip, either through internal pattern generation or by generation from an external data source like ArtNet, an Array will let me do both strips simple by passing the index to the pointer, and otherwise i would have to pass the pointer, it doesn't change much. What i am trying to solve is how i can declare the object at runtime so that i can first retrieve it's specifics from EEPROM. Basically i want create a device with which a user can control ledstrip of different types. Now i can not read from the EEPROM before the declaration of a static object, So i just want to declare the pointers and i am willing to spend the extra Flash, but not the extra RAM, for every method, since the buffer is rather sizeable for at 3x the pixels for a byte and the output buffer being 4x that, altogether 15x pixels = bytes. I am not considering dotstars, and most of the chips supported are so rare that they are hardly ever used, but RGBW SK6812's, it would be nice to have that included. Anyway, it is not all that important, but i hope i have explained the 'why'

[Makuna]

Dynamic configuration was not the goal for this library and will require more work on the sketch writer's part.

While I have not spent a lot of time coming up with the best pattern to use to solve this problem, this is what I suggest, and I believe is what several solutions that use my library do (WLED). Tasmoto used to rely on compiling a specific configuration, but I thought they also moved to a similar solution.

Create a wrapping class that manages the supported "matrix" of pixel features and methods. Assign an identifier to each of these and expose that. Often the chips specific method like WS2812x matches only one specific Feature like NeoGrbFeature for the most part. But there are far more variances that you think thanks to the Chinese manufacturers not sticking to standards very well; let alone documenting them; OR even marketing them using the same id as WS2812b but behave differently. But you can decide how wide your support is by your identifier.

Internally it will "switch" on that identifier and do work specific to the supported type. It does this by having a member PVOID that it will cast to the NPB type AND make the call. It will do with for every exposed API.
Externally, your wrapping class will expose a constructor that takes the identifier and expose the wrapping methods like Show(), SetPixelColor, etc that you use.

While the code size will increase to support each type, the calling overhead in time is minimized to a single extra branch per call.

[devarishi7]

Yeah something like that. I'm not fussed about features, it's easy enough to do at runtime to set the RGB(W) order. There are theoretically 6 RGB orders, It is not a big deal. The methods are a different matter, I guess it won't be very elegant, but i guess i will manage in some way.
Anyway it is not that easy and i did not miss an easy solution somewhere. Ok that's clear. Thank you !

[Makuna]

I have been thinking about how to implement a NeoXxxFeature that allows for dynamic order for 24bit per pixel. My last refactor made this easier to do. Still want to figure out to support also 32bit per pixel to include a dynamic W into the mix.
If you want, you could add an issue to track supporting dynamic Feature.

It's unlikely that I would support a dynamic method, just too much variance on that side. But a dynamic feature could narrow the matrix you would have to support.

[devarishi7]

Well yeah in some way it's the method that i'm after. Ideally actually a object that has access to the main functions of a set of specified methods would work. See with the access to the pointer for the pixel buffer the need for dynamic features doesn't really exist, even 32 bit features are easy enough to create on the fly. It is the compile of the Begin() & Show() functions and the access to the correct method specific versions of them, that is of interest to me
So yes i guess that would work, having a featureless object, for static declaration one could even just calculate what the maximum pixel & output buffer can be. I haven't checked how the other signals are created, but i have seen that the WS2812b signal is done with a byte representing 2 bits at 3.2Mbps to create the 800Kbps signal, for other chips the timing might be slightly different, but the general idea will stay the same, same with the break time, i don't think the extra flash for having some of those chips supported can be all that much. And hey, either they are all inverted or all not, it doesn't really matter much, it's only 2 channels. I would prefer not dynamically declare the objects, If declared statically, the chance of fragmentation is smaller, still if both dynamic objects are constructed at the end of setup() and destroyed and reconstructed at the beginning of loop(), not much can go wrong unless you have other global dynamic objects that can expand or new ones. So a statically declared object, ideally. Static buffer size, how do the different chips compare actually, i mean outside of the obvious difference between a 24 & 32 bit pixel, what is the ratio for pixelbuffersize & outputbuffersize ? is it 1 : 4 for those chips ?

[Makuna]

Buffer size is really two issues.

One, how the bits are sent out, bitbang, i2s, RMT, uart, etc. Each of these require different encoding. Even i2s single channel to 8x to 16x requires different encoding. Some require different encoding for inverted and some don't as the hardware can just invert the bits. This effect the send final send buffer primarily. Some require the pulses to be sent at different speeds, but this shouldn't affect the buffer size.
Two, what the bit format the pixels need to see. Not just pulse width issues, not just color order, not just RGB vs RGBW, and not just 8bit or 16bit color elements. Some require that a header or footer is sent (while common with DotStars (two wire), there is still a few single wire that require this. Some RGB require a blank element (not white, but either all 0 or all 1). Some require the first color element to never have the first few upper bits to be 1 for configuration or 0 for pixel data.

[devarishi7]

Well yeah i am not talking about an object that can use different output channels, but just about output channels being able to control different kind of LED's.. Hmm those 2 aspects are somehow included in the same methods. Anyway, given that a hardware change is not going to happen in the scenario i pictured, there will be no need even for assigning different pins. I was looking for a way to control different LEDs using the same way of sending the bits out, declared in a similar way to how it is done with the dynamically declared I2s parallel methods, but i understand it is a bit more trouble than it's worth. I think i can make that work anyway, create pointers for every Chip + channel i intend to support, but only construct the ones i intend to use at run-time, thus not allocating excess memory. Easiest to address would be if i could create an array of pointers to these pointers, but i guess that may not quite work the way i hope it might. Anyway thank you again.