[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.
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.
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.
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").
[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.
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.
[...]
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.
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.
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 :) )
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.]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 95:56:55 |
| Calls: | 6,719 |
| Calls today: | 3 |
| Files: | 12,252 |
| Messages: | 5,359,380 |
| Posted today: | 1 |