How Many LEDs Can You Drive?

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.

34 thoughts on “How Many LEDs Can You Drive?

    1. 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.

    1. 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.

    2. 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.

      1. 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.

          1. 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.

          2. 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.

          3. >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.

          4. 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.

  1. 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?

        1. 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!

          1. 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.

          2. 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…

    1. 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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.