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.
There are one or more examples on the web how to do it. I did a quick search (ws2812b without library - Google Search) and found e.g. NeoPixels Revealed: How to (not need to) generate precisely timed signals | josh.com; I hope that it gets you on the way. I'm not sure if it was the one that I did see long ago.
Thanks guys. That's everything I needed.
I appreciate it.
I've fixed the url in reply #5; forum SW added the semicolonto the URL. Space added.
These other articles are top shelf!
I think I'm going to use FAB_LED for this project and spend some real time on that Josh guy's page.
Ultimately that's what I want, a simple and low-memory tool that does on the fly color interpretation and is speed adjustable.
30ish FPS for 1000 LEDs from a 16MHz device with such flexibility is unreal.
When I get it the way I like it I'll share it for everyone.
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.
AVR has SWAP instruction.
If you write the code well, get much faster than 4 bit shifts.
It's does in single cycle.
Cool, looks like I'd be better using bytes and swaps than longs and shifts.
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.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.