Driving more than a handful of LEDs from a microcontroller is often a feat that takes tedious wiring, tricking the processor, or a lot of extra external hardware. Charlieplexing is perhaps the most notorious of these methods, and checks two of those three boxes. This library for the Teensy 4.0 checks all three, but it can also drive a truly staggering 32,000 LEDs at one time.
The TriantaduoWS2811 library is able to drive 32 channels of LEDs from a Teensy 4.0 using only three pins and minimal processor resources. It uses the FlexIO and DMA subsystems of the i.MX RT1062, the particular ARM processor on the Teensy, to drive four external shift registers. Together, the system is able to achieve 30 frames per second on with 1,000 LEDs per channel, for a total of 32,000 LEDs. Whoah.
[Ward] aka [wramsdell] wondered what one would do with all of the horsepower of a Teensy microcontroller when he first saw its specifications, and was able to build this project to take advantage of its features. What’s surprising, though, is that it doesn’t use nearly everything the processor is capable of, so you can do other tasks at the same time as driving that giant LED display.
It can’t drive 32000 leds at one time just sayin
I see no trickery. It’s driving several WS strings through shift registers by the usual DMA method. FlexIO looks marginally interesting though.
I think there are a handful of things that may be more broadly interesting. By leveraging these techniques one could potentially drive dozens of I/O at update rates approaching 10 MHz without burdening the main execution loop or interrupt system at all. The codebase also reconfigures one of the on-chip PLLs, so it’s a good jumping-off point for anyone interested in generating (semi-) arbitrary frequencies on chip. I do some on-the-fly modification of transfer control descriptors along with use of the scatter-gather functionality of the Kinetis DMA that might find use elsewhere. These are all things that happen on a regular basis in the professional firmware world, so there’s nothing earth-shattering there, but there are precious few examples of most of them in Arduino/Teensy land.
Why are people still messing around with those dam WS2811 leds when the APA102 is far superior in every way.
Because they cost 2-3x a comparable strip of something like the ws2812b?
Because their operating frequency is much lower. It’s not possible to get more than 640 leds on a single string with a @50Hz refresh rate (at maximum rated frequency of ~1MHz). So this means that for a simple QVGA display, you’d need at least 120 strings of APA102, while only 3 strings are required for WS2811-like LEDs.
Maybe misunderestimating your comment, but isn’t 32k pix half QVGA, 200×160.
APA102 is not superior in every way. Many people incorrectly assume it is, partly because of Adafruit selling it as a solution for anything else needing interrupts when used with their blocking libraries (therefore the LEDs are better – pay no attention to the root cause being their library disables interrupts & bitbangs), partly because of early comments about its higher internal PWM speed (greatly overstating the speed), which were amplified by the FastLED developers. So APA102 gained a not-necessarily-deserved reputation as “far superior”.
In fact, APA102 “regenerates” the clock in an analog way. It’s similar to making a photocopy of a photocopy of a photocopy of a document. The clock width deteriorates slightly as it passes to each LED, reducing the timing margin. I know this pain well, because in the early days of APA102 the FastLED library used a default clock speed of 24 MHz. Many people complained of flicking or data corruption after about 100 to 200 LEDs. Eventually I looked into the problem and documented the timing problems.
https://www.pjrc.com/why-apa102-leds-have-trouble-at-24-mhz/
Admittedly, this can be “solved” by simply using a slower clock. FastLED was changed to default to 12 MHz, which solved the problem for all but extreme cases (people tend to use Teensy for those sorts of more extreme projects….)
You may still prefer APA102. The PWM is faster, and it can run at higher clock speeds even with the analog clock regeneration issues. Just don’t fool yourself or others into thinking it’s far superior. The way it regenerates the clock leaves much to be desired.
hi paul, that is not true that adafruit sells it as a solution for anything needing interrupts (after all, we have dma code libraries for neopixels on samd21 and samd51 and they work really well :) apa102 are recommended for use because many people have raspberry pi and other embedded linux boards, circuitpython and other development boards that may not have neopixel drivers, pin and multi-strip flexibility, and of course you can drive them fast.
No. Paul was right.
@tadpole, you might want to look up Phillip Torrone.
This Adafruit page is Google’s first result searching “Dotstar”.
https://learn.adafruit.com/adafruit-dotstar-leds
It specifically says “Not compatible with interrupts” for NeoPixel and “Works with Servo library, tone() function, interrupts, etc.” for Dotstar. No mention is made of DMA or non-blocking libs.
Kinda does sound like selling APA102 as a solution for anything needing interrupts.
paul, a lot has happened in the years since that guide was published. most folks are using arduino unos/nanos, and do not have dma, so to make it even more clear, we’ve updated the page to list even more dma options and other considerations. you can always contact us if you have suggestions.
Phil, indeed a lot has happened in the years since that guide was published. But during that time, Adafruit has published that sort advice, on product pages, in forums, videos, and many other ways. Years of consistent messages have had a huge effect.
I realize you probably can not accept the possibility that Adafruit’s communication could have played any role in the widespread misunderstanding of APA102’s technical superiority. But the reality is many people mistakenly believe APA102 is technically superior.
At the time I investigated that clock distortion problem (late 2017) we were getting customers almost every week on our forums having those flicker problems on APA102 / Dotstar LEDs. Over and over again I have needed to explain to customers that APA102 are not actually able to handle extremely high clock speeds (until just now, your site still said 32 MHz). You and Limor and others at Adafruit were mostly shielded from these problems because your products couldn’t (then) create such high clocks.
Well, I have lived this tech support nightmare. I can tell you that the vast majority of people I’ve helped get their projects working obtained their overly inflated expectations of APA102’s capability from exactly 2 places: Adafruit’s website and an old FastLED blog article.
>a lot has happened in the years since that guide was published
Phil touches on a process issue, but without saying as much or asking how people think this could be improved. Just my 2 cents on the underlying issue:
PROBLEM: tutorials have no “expiration date” for re-review.
SUGGESTION: Things don’t necessarily need to be re-written, but someone could flag an article adding bullet points – a Callout of what has changed with a couple of links/references for more info.
PROBLEM: Contributing fixes to AF Tutorials is (IMO) a pain.
A minority of people recognize these errors. They have to locate the “Found Errors” link (out of the way place), which when clicked looks like a Sendmail form from 2004. It’s not impossible, but it’s discouraging.
SUGGESTION: The whole world now uses “Fork me on GitHub”. Do this for Tutorials, and allow your customers to play a large role in tutorials. Github via the website isn’t any harder than old form methods, and the public nature of GH encourages participation.
I appreciate greatly what both websites/communities have done for the public. Peace.
thanks scott for the thoughtful comment and kind words. we have full time staff members that review the feedback on each guide and we update hundreds of guides each month. each of the 2,000+ guides has a feedback button that gets us to us instantly to send us any suggestions, edits, and more. we are reseller of paul’s product(s), paul has emailed with us and we respond immediately, paul has even visited adafruit – this is the first time that we heard about an issue with this guide from paul. after i saw paul’s comment here, we added more information on that specific guide within minutes.
the last email i see with paul on it was from 1 month ago where we specifically said “We’re here, please just ask us.”
paul (or anyone!) please let us know if there are any updates to any guides either by email or via the feedback feature on each guide. it’s on each page of every guide and says “Feedback? Corrections?” additionally, users post in our forums, email us via our contact form, chat on the discord server, and/or on our live shows. we listen and gather all the feedback and if there is something that needs an update, we update it.
s/can/could
No problem with Parallax propeller 1 and 10 000 LEDs in framebuffer mode @ 25-30 fps and really small latency. With tricky programming I can do more. Additional hardware: en28j60
Sounds like a challange: with what MCU you can drive 32 000 leds?
Easy – not even a challenge. Any MCU soft-core in an iCE40up5k, for example, can drive orders of magnitude more than 32,000 LEDs.
Wait! FPGA… Different beast.
I said FPGA+softMCU. The only difference between that and a hard MCU is the later had the same RTL code used to generate both – run through a different synthesis process that stripped out all the reconfigurable bits and generated a standard cell mask rather than a programmable bit-stream. There is no difference between the MCU code you write for, for example, a hard msp430 from TI and a a soft msp430 from open-cores. But the FPGA wrapper allows you to generate as many custom peripheral blocks as your heart desires; on-demand!
In addition to that only difference, there are many more. The toolchain differences and the complexity of setting up an FPGA project alone makes it a different beast as JDat already pointed out.
With FPGA it is possible to drive 1M LEDs and no need for softMCU at all. Take 400k LE and go! Story is with tiny and not so powerful MCU.
/ME thinking about to use two Propellers in tandem/parallel…
The real question is who has so much spare cash around to buy all the LED!? I don’t know about you, but if I had so much cash, I would rather spend that on a few 4K TV.
Yes, but the LEDs are actually useful… 4K TVs? Not so much.
They’ll be useful to someone, the tech is there, just waiting for the “programming” to catch up…
https://www.youtube.com/watch?v=lxVhqtj83U8
Well, let’s fill a 40 foot container with LEDs and put it on a flatbed semi-trailer.
One could “drive” a lot of LEDs that way!
B^)
Come now, we can do better with a turnpike double, for twice as many, or a Canadian turnpike double with 2x 53 footers, for nearly 2 2/3…. okay shut up Aussies with your roadtrain nonsense… :-D
Never underestimate the resolution of a semi-trailer full of LEDs…
RW,
You just reminded me of the Canadian Pacific “Christmas Train” and of the many LEDs that adorn its sides!
B^)
I know right, if we had high speed bullet trains they could just do it with a single bar and POV :-D
Just imagine how bright that 1 LED would need to be!
How about a Great Lakes ore freighter filled with LEDs?
32K with a micro that’s impressive! Then I saw DMA, ARM and i.MX RT1062. i.MX run at@600Mhz. Yeah it can probably decode low-res h.264 vid software.
Hi everyone!
I’ve been watching this LED business from afar for ~8 years.
I used to do 3d graphics at the times of DOS in the 90’s (quake1 style – 320x240x256colors).
But had a looong break from programming.
I’d love to make some POV effect stuff.
I’m starting with a costume (Gyroscopes and I’m aiming at real time animation on this costume)
(It’ll run leds from fingertips to toes (say 2.2m in my case * 30LED/m = 66 LEDs in a row))
I already see that the GYROS will give me much more readout frequency than I need to make POV efects with, say windmilling my hands.
Which LED’s will give me a chance of 30fps or even maybe 60?
I’d love to animate my suit depending on my dance.
But I’ve no idea where I might come against bottlenecks… I understand raspi (running Linux) might not be reliable enought to drive time-sensitive APA’s directly, so was thinking of making a “graphics adapter” out of an wemos or arduino for raspi which might weight-lift my 3d effect calculations.
I exactly did get the notion that APA102 is tons faster than say WS8212b.
Alas I have yet (that is to change soonish) not much electronics knowledge and also none on the insides and quirks of MCU’s. (I’ve been doing Java for a living for 3 years now).
With which LEDs would you recommend me do this ?
And if you might be so kind as to recommend what platform would be best here to do calculations ?
Sincerely, Mike, Warsaw, Poland, Earth