[From the "I know just enough to be dangerous" department :)] Thanks to Don, I've got an upgrade in the works for my project to make the "daughtercard" a little smarter / easier. First pass here, I'm trying to see if I can get away with the ATTiny10 on the board, because that SOT-23-6 package is nice and tiny. However, this means I technically only have three easily-available I/O pins (plus /RESET, but if I can avoid it and the High-Voltage Programming mode using it would entail, all the better). It *seems* that I can use a single pin to facilitate both: (a) clocking a 74xx165 (parallel -> serial shift register) AND (b) Data Out to WS2812 LED controllers with nothing more than a low-pass filter on the '165 CLK pin, and potentially a high-pass filter on the first WS2812 -- worst case, I'll plan for the pad and stick a 0-ohm link in there instead, or, well, what is the "correct" way to do layouts with potentially optional pads?. But, this almost seems too easy (or rather, that I'm being "too clever"), and there's something I haven't accounted for on this particular pin. -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
RC [High|Low]-Pass Filter -- bit of a sanity check
Started by ●January 5, 2024
Reply by ●January 5, 20242024-01-05
On 2024-01-05 07:46, Dan Purgert wrote:> [From the "I know just enough to be dangerous" department :)] > > Thanks to Don, I've got an upgrade in the works for my project to make > the "daughtercard" a little smarter / easier. > > First pass here, I'm trying to see if I can get away with the ATTiny10 > on the board, because that SOT-23-6 package is nice and tiny. However, > this means I technically only have three easily-available I/O pins (plus > /RESET, but if I can avoid it and the High-Voltage Programming mode > using it would entail, all the better). > > It *seems* that I can use a single pin to facilitate both: > > (a) clocking a 74xx165 (parallel -> serial shift register) AND > (b) Data Out to WS2812 LED controllers > > > with nothing more than a low-pass filter on the '165 CLK pin, and > potentially a high-pass filter on the first WS2812 -- worst case, I'll > plan for the pad and stick a 0-ohm link in there instead, or, well, what > is the "correct" way to do layouts with potentially optional pads?. > > But, this almost seems too easy (or rather, that I'm being "too > clever"), and there's something I haven't accounted for on this > particular pin. > >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 -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●January 5, 20242024-01-05
On 2024-01-05 12:11, Dan Purgert wrote:> On 2024-01-05, Phil Hobbs wrote: >> On 2024-01-05 07:46, Dan Purgert wrote: >>> [From the "I know just enough to be dangerous" department :)] >>> >>> Thanks to Don, I've got an upgrade in the works for my project to make >>> the "daughtercard" a little smarter / easier. >>> >>> First pass here, I'm trying to see if I can get away with the ATTiny10 >>> on the board, because that SOT-23-6 package is nice and tiny. However, >>> this means I technically only have three easily-available I/O pins (plus >>> /RESET, but if I can avoid it and the High-Voltage Programming mode >>> using it would entail, all the better). >>> >>> It *seems* that I can use a single pin to facilitate both: >>> >>> (a) clocking a 74xx165 (parallel -> serial shift register) AND >>> (b) Data Out to WS2812 LED controllers >>> >>> >>> with nothing more than a low-pass filter on the '165 CLK pin, and >>> potentially a high-pass filter on the first WS2812 -- worst case, I'll >>> plan for the pad and stick a 0-ohm link in there instead, or, well, what >>> is the "correct" way to do layouts with potentially optional pads?. >>> >>> But, this almost seems too easy (or rather, that I'm being "too >>> clever"), and there's something I haven't accounted for on this >>> particular pin. >>> >>> >> >> 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. > > 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...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.>> 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. > > 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?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 0.7*V_DD < V_IH < V_DD+0.3 V.>> 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. > > Yes, the "Pin1" out of the ATTiny is the shared SCLK / LED_Data pin.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.> 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"). >Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●January 5, 20242024-01-05
On 2024-01-05, Phil Hobbs wrote:> On 2024-01-05 07:46, Dan Purgert wrote: >> [From the "I know just enough to be dangerous" department :)] >> >> Thanks to Don, I've got an upgrade in the works for my project to make >> the "daughtercard" a little smarter / easier. >> >> First pass here, I'm trying to see if I can get away with the ATTiny10 >> on the board, because that SOT-23-6 package is nice and tiny. However, >> this means I technically only have three easily-available I/O pins (plus >> /RESET, but if I can avoid it and the High-Voltage Programming mode >> using it would entail, all the better). >> >> It *seems* that I can use a single pin to facilitate both: >> >> (a) clocking a 74xx165 (parallel -> serial shift register) AND >> (b) Data Out to WS2812 LED controllers >> >> >> with nothing more than a low-pass filter on the '165 CLK pin, and >> potentially a high-pass filter on the first WS2812 -- worst case, I'll >> plan for the pad and stick a 0-ohm link in there instead, or, well, what >> is the "correct" way to do layouts with potentially optional pads?. >> >> But, this almost seems too easy (or rather, that I'm being "too >> clever"), and there's something I haven't accounted for on this >> particular pin. >> >> > > 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.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...> > 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.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?> > 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.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"). -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
Reply by ●January 5, 20242024-01-05
On 1/5/2024 5:46 AM, Dan Purgert wrote:> First pass here, I'm trying to see if I can get away with the ATTiny10 > on the board, because that SOT-23-6 package is nice and tiny. However, > this means I technically only have three easily-available I/O pins (plus > /RESET, but if I can avoid it and the High-Voltage Programming mode > using it would entail, all the better). > > It *seems* that I can use a single pin to facilitate both: > > (a) clocking a 74xx165 (parallel -> serial shift register) AND > (b) Data Out to WS2812 LED controllersTo be clear, do you reason: "The '165 shifts in data on a rising edge. I will set up the DATA signal (output from MCU) for the '165 at least one setup time before I drive the SHIFT (output from MCU) high. "The SHIFT signal will (effectively) be delayed to the data input of the LED controller, by the low-pass RC filter there (because there is a resistor in series with the SHIFT signal before it gets to the RC filter thus ensuring the RC filter isn't dragging down the SHIFT signal THAT THE '165 WILL SEE). "If I want to LED controller to see a LOW level, I will quickly drive the CLOCK (output from the MCU) that feeds the LED controller while the RC is still trying to charge. Conversely, if I want the LED controller to see a HI level, I will twiddle my thumbs for a few time constants to ensure the level AT THE LED CONTROLLER has risen to a valid HI before driving the CLOCK to the LED controller. etc.? (I've used a hack like that on the (buffered) serial RxD coming into a UART to force the RESET line on the MCU that was receiving the data stream -- to provide a remote reset capability for a device. But, you have to be very aware of the fact that the mechanism is in place ALL THE TIME) Without looking into the specifics of the LED controllers (ISTR there was some magic, there), why can't you just have *one* DATA line that feeds the '165 *and* the LED controller and use two other signals (CLOCK and SHIFT) to clock one or the other device (LED controller or '165), knowing the DATA line's state? E.g., Drive DATA to level required for '165 Pause for one setup time Drive SHIFT high Pause for one hold time meanwhile (this is easier to illustrate with a Petri net but too early to dick with ASCII art): Drive DATA to level required for LED controller Pause for one setup time Drive CLOCK (however required) Pause for one hold time [N.B. the setup and hold times are << MCU cycle time but may be larger than the skew between the output pins -- DATA and SHIFT -- of the MCU if you try to combine steps! There are obvious interdependencies in these two "sequences" that, *sometimes* require them to be serialized and, other times, not] Another idea may be to use unused '165 OUTPUTs as an output that you can "program" as needed.> with nothing more than a low-pass filter on the '165 CLK pin, and > potentially a high-pass filter on the first WS2812 -- worst case, I'll > plan for the pad and stick a 0-ohm link in there instead, or, well, what > is the "correct" way to do layouts with potentially optional pads?. > > But, this almost seems too easy (or rather, that I'm being "too > clever"), and there's something I haven't accounted for on this > particular pin.
Reply by ●January 5, 20242024-01-05
On Fri, 5 Jan 2024 12:46:16 -0000 (UTC), Dan Purgert <dan@djph.net> wrote:>[From the "I know just enough to be dangerous" department :)] > >Thanks to Don, I've got an upgrade in the works for my project to make >the "daughtercard" a little smarter / easier. > >First pass here, I'm trying to see if I can get away with the ATTiny10 >on the board, because that SOT-23-6 package is nice and tiny. However, >this means I technically only have three easily-available I/O pins (plus >/RESET, but if I can avoid it and the High-Voltage Programming mode >using it would entail, all the better). > >It *seems* that I can use a single pin to facilitate both: > > (a) clocking a 74xx165 (parallel -> serial shift register) AND > (b) Data Out to WS2812 LED controllers > > >with nothing more than a low-pass filter on the '165 CLK pin, and >potentially a high-pass filter on the first WS2812 -- worst case, I'll >plan for the pad and stick a 0-ohm link in there instead, or, well, what >is the "correct" way to do layouts with potentially optional pads?. > >But, this almost seems too easy (or rather, that I'm being "too >clever"), and there's something I haven't accounted for on this >particular pin.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!
Reply by ●January 5, 20242024-01-05
On 2024-01-05, Phil Hobbs wrote:> On 2024-01-05 12:11, Dan Purgert wrote: > [...] > 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.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)?>>> [...] >>> 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. >> >> Yes, the "Pin1" out of the ATTiny is the shared SCLK / LED_Data pin. > > 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.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") -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
Reply by ●January 5, 20242024-01-05
On 2024-01-05, Don Y wrote:> On 1/5/2024 5:46 AM, Dan Purgert wrote: >> First pass here, I'm trying to see if I can get away with the ATTiny10 >> on the board, because that SOT-23-6 package is nice and tiny. However, >> this means I technically only have three easily-available I/O pins (plus >> /RESET, but if I can avoid it and the High-Voltage Programming mode >> using it would entail, all the better). >> >> It *seems* that I can use a single pin to facilitate both: >> >> (a) clocking a 74xx165 (parallel -> serial shift register) AND >> (b) Data Out to WS2812 LED controllers > > To be clear, do you reason: > "The '165 shifts in data on a rising edge. I will set up the DATA > signal (output from MCU) for the '165 at least one setup time before > I drive the SHIFT (output from MCU) high. > > "The SHIFT signal will (effectively) be delayed to the data input of > the LED controller, by the low-pass RC filter there (because there is > a resistor in series with the SHIFT signal before it gets to the > RC filter thus ensuring the RC filter isn't dragging down the SHIFT > signal THAT THE '165 WILL SEE). > > "If I want to LED controller to see a LOW level, I will quickly > drive the CLOCK (output from the MCU) that feeds the LED controller > while the RC is still trying to charge. Conversely, if I want the > LED controller to see a HI level, I will twiddle my thumbs for a > few time constants to ensure the level AT THE LED CONTROLLER > has risen to a valid HI before driving the CLOCK to the LED > controller.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 :) ) -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
Reply by ●January 5, 20242024-01-05
On 1/5/2024 3:12 PM, Dan Purgert wrote:> On 2024-01-05, Don Y wrote: >> On 1/5/2024 5:46 AM, Dan Purgert wrote: >>> First pass here, I'm trying to see if I can get away with the ATTiny10 >>> on the board, because that SOT-23-6 package is nice and tiny. However, >>> this means I technically only have three easily-available I/O pins (plus >>> /RESET, but if I can avoid it and the High-Voltage Programming mode >>> using it would entail, all the better). >>> >>> It *seems* that I can use a single pin to facilitate both: >>> >>> (a) clocking a 74xx165 (parallel -> serial shift register) AND >>> (b) Data Out to WS2812 LED controllers >> >> To be clear, do you reason: >> "The '165 shifts in data on a rising edge. I will set up the DATA >> signal (output from MCU) for the '165 at least one setup time before >> I drive the SHIFT (output from MCU) high. >> >> "The SHIFT signal will (effectively) be delayed to the data input of >> the LED controller, by the low-pass RC filter there (because there is >> a resistor in series with the SHIFT signal before it gets to the >> RC filter thus ensuring the RC filter isn't dragging down the SHIFT >> signal THAT THE '165 WILL SEE). >> >> "If I want to LED controller to see a LOW level, I will quickly >> drive the CLOCK (output from the MCU) that feeds the LED controller >> while the RC is still trying to charge. Conversely, if I want the >> LED controller to see a HI level, I will twiddle my thumbs for a >> few time constants to ensure the level AT THE LED CONTROLLER >> has risen to a valid HI before driving the CLOCK to the LED >> controller. > > Other way around -- > > A. The LED controller takes one (1) 400KHz Pulse-Width Modulated > signal to act as CLK+DATA.Ah, OK. Are there limits on how slow you can go before it will RELIABLY *not* recognize it as "active"? I.e., could you use it for another purpose by playing in the frequency domain?> B. This "LED_CLK" on "PIN_1" is also acting as "SHIFT_CLOCK" to the > 74xx165.So, you MUST talk to the LED controllers in order to talk to the shift register. But, the SR likely sees less of a required pulse train due to its limited size/capacity.> 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.The '165 isn't buffered so AS you are shifting data into it, the outputs (which are connected to LEDs) are twitching... Make sure this isn't visible in your design (?)> 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.Clock pins want to see nice clean/fast edges. If you wanted to "slow down" a signal, it would want to be on a data input (if anywhere) and not proximate to any activating edges. Even data inputs can cause problems with slow rise/fall times -- esp in CMOS -- as the devices can "go linear" in the transition range.> (apparently though, "D" is very wrong :) )The signal that feeds the LED controllers is likely not available for other uses, as is -- without worrying about how the contents of those controllers is affected. (you could likely avoid this by ensuring your SUBSEQUENT data stream pushes all of the spurious data "out" of the LED controllers) Working with tiny MCUs is delightfully challenging, eh? :> [I have high enough quantities (e.g., I use hundreds of them in a single "site" -- they are cheaper than a package of gates!) that I don't have to pinch as many pennies.]
Reply by ●January 5, 20242024-01-05
On 2024-01-06, Don Y wrote:> On 1/5/2024 3:12 PM, Dan Purgert wrote: >> On 2024-01-05, Don Y wrote: >>> On 1/5/2024 5:46 AM, Dan Purgert wrote: >>>> First pass here, I'm trying to see if I can get away with the ATTiny10 >>>> on the board, because that SOT-23-6 package is nice and tiny. However, >>>> this means I technically only have three easily-available I/O pins (plus >>>> /RESET, but if I can avoid it and the High-Voltage Programming mode >>>> using it would entail, all the better). >>>> >>>> It *seems* that I can use a single pin to facilitate both: >>>> >>>> (a) clocking a 74xx165 (parallel -> serial shift register) AND >>>> (b) Data Out to WS2812 LED controllers >>> >>> To be clear, do you reason: >>> "The '165 shifts in data on a rising edge. I will set up the DATA >>> signal (output from MCU) for the '165 at least one setup time before >>> I drive the SHIFT (output from MCU) high. >>> >>> "The SHIFT signal will (effectively) be delayed to the data input of >>> the LED controller, by the low-pass RC filter there (because there is >>> a resistor in series with the SHIFT signal before it gets to the >>> RC filter thus ensuring the RC filter isn't dragging down the SHIFT >>> signal THAT THE '165 WILL SEE). >>> >>> "If I want to LED controller to see a LOW level, I will quickly >>> drive the CLOCK (output from the MCU) that feeds the LED controller >>> while the RC is still trying to charge. Conversely, if I want the >>> LED controller to see a HI level, I will twiddle my thumbs for a >>> few time constants to ensure the level AT THE LED CONTROLLER >>> has risen to a valid HI before driving the CLOCK to the LED >>> controller. >> >> Other way around -- >> >> A. The LED controller takes one (1) 400KHz Pulse-Width Modulated >> signal to act as CLK+DATA. > > Ah, OK. Are there limits on how slow you can go before it will > RELIABLY *not* recognize it as "active"? I.e., could you use it > for another purpose by playing in the frequency domain?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 :) )> >> B. This "LED_CLK" on "PIN_1" is also acting as "SHIFT_CLOCK" to the >> 74xx165. > > So, you MUST talk to the LED controllers in order to talk to > the shift register. But, the SR likely sees less of a required pulse > train due to its limited size/capacity.Yeah, but given the shift register can clock at human scale (1Hz, slower), I'm not so super worried there.> >> 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. > > The '165 isn't buffered so AS you are shifting data into it, > the outputs (which are connected to LEDs) are twitching... > Make sure this isn't visible in your design (?)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".> >> 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. > > Clock pins want to see nice clean/fast edges. If you wanted to > "slow down" a signal, it would want to be on a data input (if > anywhere) and not proximate to any activating edges. Even data > inputs can cause problems with slow rise/fall times -- esp > in CMOS -- as the devices can "go linear" in the transition range.Yeah, I think I have the ... um ... 'LS' series maybe (they're certainly not the "HC" series)> >> (apparently though, "D" is very wrong :) ) > > The signal that feeds the LED controllers is likely not available > for other uses, as is -- without worrying about how the contents of > those controllers is affected. (you could likely avoid this by ensuring > your SUBSEQUENT data stream pushes all of the spurious data "out" of the > LED controllers) > > Working with tiny MCUs is delightfully challenging, eh? :>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).> [I have high enough quantities (e.g., I use hundreds of them > in a single "site" -- they are cheaper than a package of gates!) > that I don't have to pinch as many pennies.]Less penny-pinching and more "oh this seems a fun challenge". -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
