I'm looking for a different set of controls than fastLED offers.
I do not need to store an array of colors representing each pixel, this is terribly memory hungry. My project never uses more than 16 colors so I can store each pixel as a color reference and switch them when they are to be passed to the pixel
I rarely need to update all of the pixels.
I don't want any delays
To that end all I think I need is:
The startup sequence for the LEDs
The ability to set the brightness (not sure if that's by the pixel or for the entire chain)
The ability to shift a color to a specific pixel
The ability to turn off a pixel (not sure if this is a color setting or a different command)
Whatever I've overlooked
Before I spend a couple days digging this up from datasheets and pulling out what remains of my hair, I thought I'd see if anyone had a minimal sketch or reading that they'd care to share?
I tried to find something myself but google is flat out jammed up with fastLED examples.
The thing with Neopixels is you can't have more than 50 usec between each "bit" data or the data stream resets. That is why you pre-compute each pixel color data before sending it over. This means, at a minimum, you need 3 x number of LEDs bytes.
Not exist with special sequence.
But I sends 0 to all LEDs.
Resend all data for reduce the intensity of each pixel.
Calculate the intensity with software.
Not exist.
Each pixel glows with the intensity of its last received R, G and B.
That's all of his job.
Basically resend all data for change the color of one pixel.
Not exist.
Simply set all(R,G,B) intensities to 0.
This LED determines the end of the data stream by the data break, so it must be transmitted unbreaked.
I have experience writing programs that send in the background using the CCL of the new AVR like installed in NanoEvery and others.
It doesn't use any libraries and is less flexible, but it doesn't use much CPU to send.
The datasheet has a very few pages and able to read soon, so please read it.
Ultimately, I'd like to compress 16-color pixel data into longs. I could store 8 nibbles per long and bit shift them out and switch the result to get the actual color. If I stagger this so load of the next pixel happens during output of the current pixel then I should be able to achieve this. Contingent on the AVR's speed for bit shifting nibbles.
Furthermore, If you got the new AVR microcontroller adopted by Nano Every, so data transmission processing that doesn't depend on software timing is possible.
Just give a "byte" to the peripheral hardware will send out the data formatted for WS2812B. (It like a SPI/USART.)
I really like the tiny1 series and the AVR Dx series.
Speaking of using peripherals for this I have been toying with the idea of using an external flash and an 8051 or something like that. The idea being to be able to have it refresh with a single pulse from the main MCU and to only update pixels that you want to.
3 wires for duplex communication between main MCU and the 8051 then the 8051 updates the flash and streams the correct buffer straight to the LEDs from the flash output pin.
The Nano Every is definitely something to look into after I reach the absolute limit of the 328's and 2560's capabilities.
One of my side projects is a 10 buzzer piano player. It uses port manipulation to synchronize the vibrations of the buzzers. It's barely a challenge for the 328. I think there is a grumpy fellow on here who will get a kick out of it when it's finished.
Of course, I'm the guy who still plays Ace Combat 4 on my PS2 and Orange Box games on Steam because I'm happy with those and haven't maxed them out yet.
