FastLED now has 50-pin parallel Teensy 4.1 WS2812 support

N

niteris

Member
It turns out, the Teensy 4.1 and 4.0 are absolute LED beasts!

The claim is all 50 pins can be driven with DMA. Can that be possible?

The backend driver is ObjectFLED which just came out for Arduino-Teensy.

FastLED 3.9.8 just made this a core driver option.

Code: 
#define FASTLED_USES_OBJECTFLED
#include "FastLED.h"

Here's a reddit thread where they announced it.

https://www.reddit.com/r/FastLED/comments/1hodkm2

Here's an example sketch:

github.com

FastLED/examples/TeensyMassiveParallel/TeensyMassiveParallel.ino at master · FastLED/FastLED

The FastLED library for colored LED animation on Arduino. Please direct questions/requests for help to the FastLED Reddit community: http://fastled.io/r We'd like to use github "issues&...
github.com github.com
 
niteris said:
Hey Paul, any insight on this issue? Looks like Audio DMA for teensy produces LED flickering on ObjectFLED:
Click to expand...
I've looked into this, and it seems to be a DMA conflict between Audio library and OctoWS2811 code which I hijacked for ObjectFLED. Problem disappears when the user comments out instantiation of AudioInputI2S before calling the addLEDs(), which runs the begin() function on 3 dma channels for LEDs. Is there a known DMA conflict between Audio library and OctoWS2811?
 
I'm still researching this problem. But while learning how DMAChannel.h allocates channels to multiple apps, I found a function I believe is generating errors:
Code: 
void DMAPriorityOrder(DMAChannel &ch1, DMAChannel &ch2, DMAChannel &ch3, DMAChannel &ch4)
{
    if (priority(ch3) < priority(ch4)) swap(ch3, ch4);
    if (priority(ch2) < priority(ch3)) swap(ch2, ch3);
    if (priority(ch1) < priority(ch2)) swap(ch1, ch2);
    if (priority(ch3) < priority(ch4)) swap(ch2, ch3);     //s.b. swap(ch3, ch4)
    if (priority(ch2) < priority(ch3)) swap(ch1, ch2);     //s.b. swap(ch2, ch3)
    if (priority(ch3) < priority(ch4)) swap(ch2, ch3);     //s.b. swap(ch3, ch4)
}

This appears to be a malformed bubble sort. I added comments where I thought code was wrong.

I still haven't zeroed in on this problem, but the above is my primary suspect. I need to install the Audio library in my sandbox to test the theory.
 
Happy New Year! I've reproduced this error and ruled out OctoWS2811 and FastLED as the cause. Also, the funny bubble sort mentioned above has no bearing on it. Apparently I introduced this error in ObjectFLED when I re-packaged the DMA driver code from OctoWS2811. So my PD is focused on this, and any differences I introduced while refactoring OctoWS2811 code.

The conflict can be eliminated by commenting out this single line of code from the Audio library file output_i2s.cpp:
Code: 
393        CCM_CCGR5 |= CCM_CCGR5_SAI1(CCM_CCGR_ON);
This is executed by the constructor for AudioInputI2S. I can't see any direct conflicts between this and ObjectFLED's use of quad timer, but I'm not expert in register-level hardware.

Investigation continues. If anyone has an idea about this, please share! I didn't think I changed anything in OctoWS2811 DMA and timer configuration when I converted it to ObjectFLED. But I will dig deeper into this.
 
Just to confirm, I've added this to my list of issues to investigate. Can't make any promises of time frame when I'll get to it, but it definitely is on my list so I won't forget even if this forum thread becomes inactive.

KurtF said:
The conflict can be eliminated by commenting out this single line of code from the Audio library file output_i2s.cpp:
Click to expand...

Not turning on the clock to the I2S peripheral would completely break I2S audio output, right?
 
:cool: Right. Disabling I2S clock was not offered as a solution. It did tip me off that this is probably not a DMA channel conflict, as I suspected. I commented out each line in the config_i2s() method one-by-one, and only this one (CCGR_ON) fixed the problem.

Thanks for putting this on your list. I am going to do a deep-dive into how I managed to corrupt your timer-dma code while putting it into objectFLED. Hopefully I can find and fix it in a day or two, and you can take it off your list. I have a test sketch which lets me swap between OctoWS2811 and ObjectFLED, and the problem disappears when I run in Octo mode. So since I broke it...
 
WHOO-HOO! I found the problem. And it was not me screwing up Paul's timer-DMA code during refactoring. :)

Well, not exactly. It turns out this problem can be solved in ObjectFLED by specifying non-default LED waveform timing with the begin() function. Alternately, it can be solved by using an overclock factor of 1.2 or above, also using begin().

To recap, the problem is that ObjecFLED was adding 'sparkles' to LED display when the Audio library AudioInputI2S object is instantiated (and turns on it's clock). When OctoWS2811 is used in place of ObjectFLED, the output is clean: no sparkles. So I've been looking for corruption in my copy of OctoWS2811 code in ObjectFLED. But refreshing my code with the original Octo code did not solve this until I used Paul's default LED waveform timing instead of my own defaults.

OctoWS2811 defaults to 1250 nS LED clock with 300 nS T0H and 750nS T1H periods. When developing ObjectFLED I changed this default to 1250, 420, and 840. I had to shrink my T0H time to 350 nS to make the sparkles disappear. The reason I changed defaults in the first place is that the WS2812B data sheet specifies 33%/66% ratios between T0H/T1H and the clock period. Paul's defaults were closer to 25%/60% ratios, likely from a WS2811 data sheet. My ratios fail when sharing Teensy's clocks with Audio library. Specifically, ObjectFLED's T0H period must be decreased when Audio library turns on it's clock.

Also, I can make OctoWS2811 add sparkles by setting it's T0H to 360 or above, which also disappear when I stop Audio from starting it's clock.

I will get outside confirmation for my fix, then update ObjectFLED so it works with Audio out of the box.

Paul, this is no longer a critical issue, but I do thank you for stopping by, and for giving us OctoWS2811 open-source!
 
Glad you found it. :)

Maybe this would be a good moment to mention the WS2812Capture library I recently started. It's meant to capture WS2812 waveforms and analyze the actual timing. If you have another Teensy handy (and time to connect some wires between then), might be worth a try to see the actual timing with and without Audio running.

In my dream world of infinite hours in every day, my hope is to eventually build up hardware and testing software to automatically verify many of the important Arduino libraries. Ideally every commit would run a Github Action would build the library and run it on real hardware while other real hardware analyzes the waveforms, to verify the library really does work rather than merely compile. WS2812Capture is meant as an initial step to someday having that capability...
 
Last edited:
My blind guess is other libraries using DMA may be adding about 90ns latency. If so, you should see the WS2812Capture stats show different min & max timing while Audio is running.

I have an idea how this might be improved (maybe) but first step is to just reliable measure the effect with WS2812Capture before trying new DMA configurations!
 
About the T0H timing, I really believe you could go with no more than 300ns. Many different WS2812 products have been sold over the years, and many different datasheets with varying (sometimes non-nonsensical or contradictory) specs have been published.

But as a practical matter, many real LEDs make the low vs high decision with TH somewhere between 400ns to 500ns (and the actual threshold may vary slightly with temperature). Yes, this is much less than half of the 1250ns cycle.

Inside the chip is an imprecise analog delay circuit. With IC design, you don't get good quality resistors and capacitors like you do with regular electronics. Likewise, the transitor specs can vary quite a lot. The one thing you do get is well defined ratios of transistor size. Design-wise, it's an entirely different world of analog circuitry. The designers of these chips (probably) have a circuit similar to a 555 timer which triggets on the rising edge. If the input signal goes low before the timer, it's detected as a 0 bit. If the timer goes low first, it's a 1 bit. But unlike a 555 timer where you connect 5% or 1% resistor and probably 5% or 10% tolerance capacitor, inside the chip you only get resistors (or current sinking transistor circuits) and capacitors with tolerance in the 40% range, plus variance for changes in temperature and supply voltage. There is a special "bandgap reference" circuit made from carefully matched bipolar transitors which can be better... and who knows, maybe they have something like that inside these chips. But I doubt it (and a bandgap ref only solves the resistor side of a RC delay circuit), since they're so incredibly cheap. It's very likely 555-like, using the polysilicon gate material for the capacitor and likely a length of the well implant for resistor.

The point is that sort of design needs to make do with an on-chip resistor and capacitor having much worse tolerance than you would ever imagine with regular PCB design. 40% is the likely range. So the desiger does not dare to set the T0H vs T1H threshold close to 50% of the 1250ns cycle! If they do, and the capacitor or resistor end up being on the +40% tolerance, the threshold could end up too close to the end of the 1250ns timing. Pretty much all these WS2812 LEDs have their timing threshold abound 1/3rd of the way into the 1250ns period. If the timing tolerance goes long by 40%, they don't risk it being unable to receive data at all. And if the timing threshold goes short by -40%, the product still works if the controller sends a short T0H pulse.

This is why I set the default T0H at 300ns in OctoWS2811. And it's only 250ns in WS2812Serial, though in that case I can only adjust in increments of 125ns.

I would highly recommend using a similar threshold with your library. Please try to avoid thinking the 1250ns clock cycle as some sort of symmetry around 625ns. I know that way of thinking makes logical sense. But that's not how the analog circuitry inside these LEDs is designed. The real threshold is shorter and imprecise due to the limited resources and difficult trade-offs the IC designer faces.
 
PaulStoffregen said:
Please try to avoid thinking the 1250ns clock cycle as some sort of symmetry around 625ns. I know that way of thinking makes logical sense. But that's not how the analog circuitry inside these LEDs is designed. The real threshold is shorter and imprecise due to the limited resources and difficult trade-offs the IC designer faces.
Click to expand...
You hit my nail right on the head. I was just thinking about this very thing. Thanks for giving the detail behind why. The wide tolerances, I guess, are why these things are so overclockable. I wrote a serial driver before I discovered Octo', and OC'd by factor of 1.7. With Octo' code I can clock 1.6. I was thinking, since I expose overclocking & waveform timing, that a 1/3-2/3 ratio "compressed" better when overclocking. But it is about the threshold, not the ratio, as you say.

From experimenting, it seems Audio is adding 60-70 nS to T0H. I tried switching the ObjectFLED from TMR4 to TMR3, but same result.

I will update ObjectFLED to use your original default timing waveform. Also, I will re-think the logic I use to shrink the waveform for overclocking. I think I could user your new Capture library for this work. It comes with perfect timing. :)

Thanks again!
 
KurtF said:
From experimenting, it seems Audio is adding 60-70 nS to T0H.
Click to expand...

That's good info.

Maybe the problem could be lessened using "Channel preemption". The 3 DMA channels used for LED output would be able preempt the audio DMA (if configured some way). Audio should not be nearly as urgent because sample rate is only 44.1 kHz and the SAI ports have FIFOs. Audio can probably tolerate many microseconds of latency.

This feature is described in section 6.3.4 on page 99 in the reference manual. How to actually configure it might take some experimenting. I've been waiting for an actual low latency need before trying to play with this feature. Let me know if you dive into it and find it makes a difference?
 
PaulStoffregen said:
This feature is described in section 6.3.4 on page 99 in the reference manual. How to actually configure it might take some experimenting. I've been waiting for an actual low latency need before trying to play with this feature. Let me know if you dive into it and find it makes a difference?
Click to expand...
I read the section, and it says a channel can be configured to be preemptable; and that a channel can be configured to never preempt another. I infer that the default is for channels to be able to preempt, but no channels are preemptable unless explicitly configured to be.

So Audio would need to be made preemptable, and Octo/Object are ready to preempt as-is. I guess this indicates that good programming practice is to make DMA preemptable if it's slow or has long inner loop?
 
…which I can confirm “works for me”, with a beneficial effect on the interaction between display SPI and Audio library DMA.
 
jmarsh said:
it marks the channels pre-emptible but also disables their ability to pre-empt others. So the net affect is nothing.
Click to expand...

Yes, exactly, the default behavior it to work exactly the same as we always have.

This change means libraries like ObjectFLED and OctoWS2811 which are sensitive to ~100ns latency can clear their DMA_DCHPRI_DPA bit.

Before this change, doing so had no effect, because all other DMA channels defaulted to their bit DMA_DCHPRI_ECP clear. But now that DMA_DCHPRI_ECP defaults to set on all DMA usage, DMA_DCHPRI_DPA can become useful on just some high priority channels. So now (or soon...) when you use Audio and a DMA-based display library and ObjectFLED/FastLED together in a project, code inside ObjectFLED would clear its DMA_DCHPRI_DPA bits, which will give it preemption over audio and display DMA because those less timing critical uses will default to allowing preemption. The assumption is most ordinary libraries that use DMA to feed peripherals with FIFO won't mess with these preemption bits.

Also important will the priorty settings. For the normal case of static instances used by nearly all hardware interface libraries, you would put the instances of high priority libraries first. The normal way of DMAChannel allocation will use the higher priority configured channels first. So in the case of Audio and a DMA display library and ObjectFLED/FastLED, you would need to put the FastLED instances near the top of your code. Then put the audio and display instances later.

But if the absense of libraries specifically clearing their DMA_DCHPRI_ECP bit, the idea is this change keeps all DMA usage exactly the same as we've always had.
 
Last edited:
Might also be worth mentioning the hardware limitation that preemption happens at minor loop granularity. If a lower priority DMA channel configures a large amount of data to be moved on each minor loop, it will still hog the DMA controller because a higher priorty DMA channel can't preempt until the minor loop completes. This change is far from a magic bullet that will make latency sensitive DMA like ObjectFLED and OctoWS2811 work flawlessly with all other DMA-based libraries. It should help in many common cases with small minor loops, but it can't guarantee timing.
 
PaulStoffregen said:
Yes, exactly, the default behavior it to work exactly the same as we always have.

This change means libraries like ObjectFLED and OctoWS2811 which are sensitive to ~100ns latency can clear their DMA_DCHPRI_DPA bit.

Before this change, doing so had no effect, because all other DMA channels defaulted to their bit DMA_DCHPRI_ECP clear. But now that DMA_DCHPRI_ECP defaults to set on all DMA usage, DMA_DCHPRI_DPA can become useful on just some high priority channels. So now (or soon...) when you use Audio and a DMA-based display library and ObjectFLED/FastLED together in a project, code inside ObjectFLED would clear its DMA_DCHPRI_DPA bits, which will give it preemption over audio and display DMA because those less timing critical uses will default to allowing preemption. The assumption is most ordinary libraries that use DMA to feed peripherals with FIFO won't mess with these preemption bits.
Click to expand...
The problem I (and others) are encountering is actually the reverse: audio needs priority (pre-emptive capability) over DMA being used to update displays. We can't "turn on" preemptive capability for channels used by the audio library because they aren't exposed outside their host objects.
PaulStoffregen said:
Also important will the priorty settings. For the normal case of static instances used by nearly all hardware interface libraries, you would put the instances of high priority libraries first. The normal way of DMAChannel allocation will use the higher priority configured channels first.
Click to expand...
I don't think this is correct? Currently channels are allocated starting with the lowest first, which also has the lowest priority.
PaulStoffregen said:
So in the case of Audio and a DMA display library and ObjectFLED/FastLED, you would need to put the FastLED instances near the top of your code. Then put the audio and display instances later.
Click to expand...
For global objects in different files (static or otherwise), there's no way to ensure the order of initialization. I've discussed this in the other thread; there really needs to be a bulletproof way to initialize a high or low priority channel without relying on indeterminate compiler behavior. At the least we need access to DMAChannels used in the audio library even just to know which channel numbers they have been assigned, so they can be manually prioritized with respect to other channels.
PaulStoffregen said:
But if the absense of libraries specifically clearing their DMA_DCHPRI_ECP bit, the idea is this change keeps all DMA usage exactly the same as we've always had.
Click to expand...
The changes I've done also maintain the existing behavior - by default channels will have preemptive capability but cannot be preempted, with an option that channels can be initialized as preemptible.
I also increased the available channel count up to 32 to match the hardware.
PaulStoffregen said:
Might also be worth mentioning the hardware limitation that preemption happens at minor loop granularity. If a lower priority DMA channel configures a large amount of data to be moved on each minor loop, it will still hog the DMA controller because a higher priorty DMA channel can't preempt until the minor loop completes. This change is far from a magic bullet that will make latency sensitive DMA like ObjectFLED and OctoWS2811 work flawlessly with all other DMA-based libraries. It should help in many common cases with small minor loops, but it can't guarantee timing.
Click to expand...
I don't believe this is the case. The reference manual strongly implies that preemption can interrupt the minor loop:
- page 91, "After eDMA activates a channel to execute, it runs until the minor loop completes, unless preempted by a higher priority channel." This indicates a minor loop can be interrupted by preemption.
- page 99, "After the restored channel completes one read/write sequence, it is again eligible for preemption. If any higher priority channel is requesting service, the restored channel is suspended and the higher priority channel is served." One read/write sequence refers to the larger of SSIZE or DSIZE, not a complete minor loop.
- page 101, "DMA arbitration can occur after each minor loop, and one level of minor loop DMA preemption is allowed." There's a distinction made here between ordinary arbitration (performed based on channel priority) and preemption. If preemption could only happen at the end of a minor loop it would serve no purpose because arbitration already occurs at that time.
 
For posterity, I believe this is the other thread to which @jmarsh refers:

I do not love the Arduino-style everything-is-a-static object approach. One of the reasons is because it leads to this: Static Initialization Order Fiasco, where initialization ordering is not guaranteed.

There are a few ways to solve this. If destruction is never needed, then a singleton function where the object is stored as a local static variable is useful. See also: Construct on First Use. Be careful with this because simply using this function to assign to some static global variable might lead to the same problem: we don't know when exactly the variable will be assigned to.

I like the Nifty Counter idiom. It handles destruction properly and it allows proper declaration of global static variables, such that when they're used, it's guaranteed that they're also initialized. This is what I use for all the static global objects in the QNEthernet library.
See how I use, in various places in the library, the STATIC_INIT_DECL() and STATIC_INIT_DEFN() macros from here: qnethernet/StaticInit.h#L19. For example: QNEthernet.h#L508 and qnethernet/QNEthernet.cpp#L53
 
Last edited:
Another thing that makes it tricky to keep things under control is that the Audio library provides the begin() method to start the hardware and DMA, and then spoils the whole thing by calling it from within the constructor…

Similar criticisms can no doubt be made about other libraries - it’s a pretty big ecosystem and I don’t pretend for a moment to be thoroughly familiar with all its corners!
 
You must log in or register to reply here.
Back
Top