Will having register remembering each pixel color will have significant increase in performance
So, I attempt to use 96 8-bit register / d latch to allow consistent display,
I still want to know if I can obtain "higher" framerate for smoother animation if I do it this way.
all of 8 input of registers will share the same 8 output from Arduino.
You could however theoretically use 48 TLC5940's
The maximum number of cascading TLC5940 devices depends on the application system and is in the range of 40 devices.
Are you planning to do PWM as well, or is this just a 6 color + black variant?
QuoteI still want to know if I can obtain "higher" framerate for smoother animation if I do it this way.Not particularly, you will have a big problem just working out what part of the image to update, it is much easier to refresh it all.
You can't really control the colors with those registers, you will only be able to make them red, yellow, green, blue, violet, cyan, white, and off.You could however theoretically use 48 TLC5940's, but that will be expensive (100,- if you order them in china), and you will need a LOT of decoupling. I'm currently building a big board with 256 warm white leds to light my room, and with only 4 TLC's I already had to decouple a lot, but it could be possible.
Make it modular with one controller per board and one more chip to distribute data. 8x8 RGB (PWM-ed) is known to work with shift registers (done that) and it certainly works very well with LED drivers. If you want to force everything into one micro it will be pretty busy and probably won't have much time left for other stuff (user interaction).
I think architecturally, I would run 12 groups of 8 shift registers in series, with each group having its own SlaveSelect line, and then update a group using eight SPI.transfer commands. Cuts way down on the number of parts, your data could be stored as 96 bytes in an array, and just update the section that changed.Or arrange other ways: 4 groups of 4x4 with 4 SS lines, update each group as something changed.16 groups of 2x2. Whatever.
Ok, I miscounted. 16 x 16 x 3 for RGB = 768 bytes.SPI runs at 4 MHz.4,000,000 / 8 = 500,000 bytes/second / 768 byte = 650 frames/secondThrow in loss for other stuff going on, you can still hit 30 frames/second easy.Get a chip with more memory, '328 with 2K of memory and storing your image in 768 bytes of it could be an issue.Like a '1284 with 16K of RAM.16 x 16 x RGB is really more like 48 x 16, I'd go multiplexing route with 48 anode drivers and 16 cathode current sinks using >1A transistors (48 x 0.02A)
I don't see how that works unless you add a diode as well to prevent the drive line from just discharging the cap as soon as the the charge line turns off.Might as well go with a bank of 12 7219/7221's to control 64 LEDs each.8 SPI.transfer()s to each to update the display. Techone just bought 70 of them for 50 cents each.
Please enter a valid email to subscribe
We need to confirm your email address.
To complete the subscription, please click the link in the
email we just sent you.
Thank you for subscribing!
via Egeo 16