Looking for high-speed digital MUX solution

Status
Not open for further replies.
M

melliott

Member
I would like to MUX Teensy 4.1 primary SPI channel out to 6 different strips at 40MHz (HD107s can be driven that fast _in theory_). The only chip that seems to suit the purpose is the 74HC4067 set. But, the timing characteristics seem like they might not be that fast. 20MHz for sure, but 40 might be pushing it. Any ideas or thoughts? Anyone done this before?

P.s. I did an experiment just this morning with the one 74HC4067 chip I have, at 20MHz, and suffice it to say that if you MUX the clock, you better MUX the data as well. The propagation delay of that chip skews the timing of the clock too far relative to the data. I just got sparkly garbage :)
 
Firstly I'd suggest 74HCT family as the 74HC family is guaranteed to work with 3.3V inputs when powered at 5V, the HC family
is borderline for this.

BTW from what I find the HD107S's are spec'd upto 30MHz, not 40MHz. 30MHz is pushing it for HC or HCT. If the HD107S
works reliably with 3.3V input (couldn't see this in datasheet), then use the fast 3.3V series like LCX or LVC

Why are you using an _analog_ switch for digital demux?(*) A 74HCT154 4->16 demux chip ought to work fine as the HD107S has
clock idling HIGH and the '154 has active low outputs. The input signal goes to an enable input to function as a demux rather
than decode.

(*) What do you do to prevent floating inputs?
 
The 74LCX logic chips work well for higher speeds, much better than 74HC ahd 74HCT.

Agree with Mark on using a digital approach. An analog mux will usually end up relatively slow because you end up driving the output through the on resistance of the switch.

On clock speed, keep in mind the SPI port on Teensy 4.1 is rated for only 33 MHz. It can run faster, but over 33 MHz is technically considered overclocking. It has no extra timing margin above 33 MHz, and extra timing margin is exactly the thing you need if you're going to add signal delay.
 
Could not the FlexIO be used for this,
to 'simulate' multiple spi channels

That way no external muxing ic:s are needed
 
Wow, thanks for all the advice guys! I admit to being quite naive about these chips. Digital vs Analog, duly noted, and somewhat understood now. Thanks Paul for setting my expectations on throughput. Don't know where I got the idea that SPI0 could push 40MHz. Probably from the datasheet where lots of SPI modes are listed, some of which clock at 166MHz, but I will admit I don't know what I am looking at there. Complicated architecture.

I found a repo by KurtE that is an experimental FlexIO based SPI. Will dig a bit further.

Here's a summary of the project:

12 strips of either APA102 (or equivalent) or HD107s
3240 total pixels
unequal strip lengths

Simulations and core effects code running on RasPi quad core
Pixel data pushed to 2 Teensy 4.1s via UDP (RasPi => Switch => Teensies)
Teensies buffer the renderable frames and do final color processing (TBD how much cpu bandwidth I'll have for that)
Teensies push the frames out to the strips
Each Teensy owns 6 strips or 1620 pixels worth

So far, I have the system running at ~210 FPS (20MHz SPI), which is quite nice, but I'd like to push the envelope. The structure is 65 feet long and I'd like to run effects down the entire length of the structure at a fairly high rate of speed (feet/sec) without too much dropout. Imagine a bouncing particle. Persistence of vision, large particles and blended edges go a long way to making the effect look smooth, but raw FPS is the bedrock. The project is headed to the Burn later this year.

I will try to contact KurtE and see if he has any advice around FlexIO approach (which from my quick reading should allow clocking at 40MHz+, as he is already running 12 bit wide IO at 50MHz)

Thanks again for the sage advice, I really appreciate it!
 
If you're thinking of running long strips of APA102 at high clock speed, you might first read this blog article I wrote in 2017.

https://www.pjrc.com/why-apa102-leds-have-trouble-at-24-mhz/

Back then, FastLED was using 24 MHz default for Teensy (no other microcontrollers people used then could get close to that speed), and Adafruit was publishing crazy advise to use even higher clock speeds with Raspberry Pi. Turns out all the testing they had done was with relatively short strips. But almost every week on this forum we had people suffering painful APA102 problems when they tried to use long APA102 LED strips, certain it should work because Adafruit and the FastLED developers said so.

Eventually the FastLED default was changed to 12 MHz and Adafruit deleted their bad advice (like some way to get ~30 MHz) that APA102 was superior in every way (it's not). But in 2016-2017, this was a huge problem. Those APA102s "regenerate" the clock in an analog way, where each copy degrades slightly as you go farther down the strip. The longer the strip, the slower you need to clock.
 
I remember that article but didn't pay attention :) Now I am paying attention! My longest strip will have 300 pixels, which at 20MHz is right at, or beyond, the edge of the timing barrier for those APA102 issues. I wonder if HD107 has better characteristics?... If I can't drive APA102 strings of length 300 at 20MHz, maybe I can drive HD107s at 20MHz (rather than their advertised 40MHz). If they can actually handle 40MHz, then I should have some extra timing headroom at 20MHz, assuming they don't degrade the rising/falling edges worse than APA102. I have two reels of APA102 arriving today, and two of HD107 coming next week. Will test both and report back. Don't currently own an oscilloscope but I think I should invest in one. Would have saved me headaches many times over the years....

Thanks again Paul! We have used Teensy in all of our playa projects over the years and I am grateful to you for all you do for us crazy builders...
 
Status
Not open for further replies.
Back
Top