RC [High|Low]-Pass Filter -- bit of a sanity check

You can do things like that, but they take a bunch more circuitry and tend to be flaky.

1. There are datasheet limits on how slow the clock edges are allowed to be for a given logic family. One reason for this is that you can get different sections clocking at different times, leading to unreliable shifting and possibly to multiple transitions.
2. You can't simply high-pass filter a single-ended digital line, because it relies on specific voltage levels meaning different things. It's possible to sense edges and use them to switch an RS flipflop, for instance, but you have to know the initial state, and you're vulnerable to noise.

What I'd probably do if I were in a jam like that would be to use the LED data stream to clock the shift register. It has a determinate number of edges, so that shouldn't be that difficult, and if you have more than 8 LEDs, you can just ignore bits 8...N on the input.

Cheers

Phil Hobbs

It's the _maximum_ rise and fall times that are the issue. Make it too slow and it's liable to misbehave. Some parts tolerate this better than others.

It's not the edges so much as the destination--you have to have valid high and low logic levels when the edges are done. CMOS parts generally specify a low input level as -0.3 V < V_IL < 0.3*V_DD and a high as

If you do it as I suggest, you don't need any filtering at all--the same transitions that clock out the LED data also clock in the shift register data. You'll need to bitbang the shift register rather than using the SPI peripheral.

Cheers

Phil Hobbs

According to the TI Datasheet I have to hand, T_su (Clock Enable setup time) is minimum 30 ns. Additionally there is a 45 ns Shift setup time. However, it doesn't say anything about minimum rise/fall times on the clock input.

I only plan on clocking the shift register at some 10 KHz (or less), I only need the 8 bits...

Ah, so the issue with adding a High-Pass filter would be that the input rise / fall times would be skewed for the LED driver?

Yes, the "Pin1" out of the ATTiny is the shared SCLK / LED_Data pin.

The other 2 pins being "MISO" from the shift register, and "Serial RX" from the main processor/motherboard (I had considered some form of an OR gate to select between them, but that quickly was "complex for the sake of complexity").

You can load and clock the shift register from a single pin. We discussed that here a while ago. That might let you not share the pin with the LED thing.

After all, three is a lot of uP port pins!

OK, think I found it here for the shift register -- (at VCC = 4.5v) Δt / Δv = 500ns/V

And here I am completely out of my depth :) ; does that then mean it has to hit the VIH / VIL thresholds in (about) 100ns (500/4.5)?

Yes, it is just bit-banged as it stands (the ATTiny10 having no peripherals to speak of, I'm just using the typical peripheral pin names to avoid just having to call everything "Pin1", "Pin2", and "Pin3".

Seems to be the case of "just clock the shift register along with the LEDs and ignore the input pin, it'll be fine"...

(see, i knew I was being "too clever")

Other way around --

A. The LED controller takes one (1) 400KHz Pulse-Width Modulated signal to act as CLK+DATA.

B. This "LED_CLK" on "PIN_1" is also acting as "SHIFT_CLOCK" to the 74xx165.

C. After shifting in 8 bits, the shift-register no longer serves any purpose. Therefore, it makes some semblance of sense to somehow block the ~400KHz "LED_CLK" signal from arriving.

D. Therefore, a low-pass filter on the '165 clock pin to keep it from reaching the "HIGH" threshold once we swap from ~1KHz (ish) clocking of the '165 to the 400KHz(ish) led signal will work.

(apparently though, "D" is very wrong :) )

Yes, anything below 400 KHz is too slow (uh, well, at least as I understand the timing diagram. A bit period is 1.25 μS (+/- 600 ns)

Ideal timing: * "0" -> 400ns "high" + 850ns "low" * "1" -> 800ns "high" + 450ns "low"

Anything where "low" stays "low" for 50μS (or longer) is "reset" for the WS2812 controller (which as I recall is "kill the output", but I can't find my spool to triple-check that, but it doesn't matter anyway :) )

Yeah, but given the shift register can clock at human scale (1Hz, slower), I'm not so super worried there.

S_OUT (from the shift register) is only going into an input pin of the microcontroller dedicated to reading that (I couldn't suss out a way to multipurpose the "DataIN" pin on the micro). The only thing common to the LEDs and the shift register is the "clock".

Yeah, I think I have the ... um ... 'LS' series maybe (they're certainly not the "HC" series)

Yep. I could toss in a SOIC-8 ATTiny 0-series something or other; but I kinda like the idea of that little SOT-23-6 chip running the show. At the end of the day, if I can't do what I'm thinking here with the low-pass filter, I still have the option of "use reset" -- but that will require 12v on the reset line if I need to re-program in circuit).

Less penny-pinching and more "oh this seems a fun challenge".