The goal: control 8 or 16 LEDs using shift register(s).
Design: (1) put desired data signal on output pin, connected to serial-in (2) write HIGH to shift clock, wait 10us, write LOW to shift clock (3) after 8 (or, eventually, 16) data bits have been transferred, write HIGH to the register clock to transfer data to the output latches, wait 10us, write LOW
There's a few more things going on here; for example, to reduce gratuitous parts count, the LEDs are connected directly to Vcc and then to the open-drain pins of the shift register. OE# is connected to a PWM pin which is running with 224 as its parameter, making the output high 87.5% of the time, and low (transistors conducting) 12.5% of the time, thus managing the duty cycle of both the open drain driver transistor in the shift register (TPIC6B595) and the LED. I have successfully used this multiplexing technique for decades, although mostly with open-collector TTL.
But here's the problem: it didn't work. After much hair-tearing, and hours of time, and checking the ourputs with an oscilloscope, and verifying that I have nice 5V signals everywhere, it still didn't work. By "didn't work", I mean that no LEDs lit when they were supposed to. Or at all.
My first simple diagnostic was to remove the wire between the tiny85 and serial in, and replace it with a 10K resistor to Vcc. All of the lights lit up. I shorted it to ground, and all the lights went out. So I established that data shifting was working, output enable was working, and the strobe-to-output was working.
So I decided that the failure was in my software. Not likely, since all the signals except the PWM are managed by explicit code, and the scope verified them, but I needed debug output. Since I was using every pin of the AtTiny85, I couldn't even do software serial. So I took my Adafruit Feather (AtMega32U4), with a bit of #ifdeffing caused the pin names to be reassigned, added some debug print statements and added a pin for oscilloscope triggering, recompiled, downloaded, and...it worked. Perfectly. Exactly as expected. Debug print statements verified that my (trivially simple) code was correct. No surprise. Oscilloscope showed same waveforms for the tiny85 and the Feather.
A friend suggested moving the wires one at a time from the Feather pins to the Tiny85. I pointed out the obvious failure modes of setup and hold times being violated by the inherent asynchrony, and he pointed out that the pattern might not be the /intended/ data bit, but it would be /a/ data bit. I decided to ignore the D-flop "ringing" that could happen if setup or hold times were violated.
I downloaded the program (two separate builds) to both the Feather and the 85. Then we powered down, switched the PWM signal from the Feather to the 85, and powered back up. It worked; the lights blinked as expected.
We moved the shift-clock signal from the Feather to the 85. It continued to run correctly.
We moved the data line from the Feather to the 85. The lights did not come on at all when power was applied.
Moved the data line from the tiny85 to the 10K resistor to Vcc. All LEDs lit. Shorted it to ground, the LEDs went off. Removed the ground connection, the LEDs turned on. Looked at the data line with the scope. Lots of positive pulses. Hooked it back up to the Feather. Same kind of pulse patterns, but now the LEDs lit.
At this point I gave up and am posting this. It feels like the AtTiny85 is not able to drive the data line for serial input, but the Feather can. This does not seem to be supported by any specs on the chips. I know the data is there in both cases; I can see the waveforms on the scope. So it is not some error in pin assignment.
My BitScope claims to have a logic analyzer, but when I went to that section of the manual, it said that the section had not yet been written. So my most powerful potential tool is going to take more work to figure out. Meanwhile, I'm searching for the reason why the same (except for pin number assignments) code works on an 8MHz AtMega32U4 but not on an 8MHz/8 (i.e., 1MHz) AtTiny85.
I can attach a PDF of the schematic and the .ino source, but not tonight because I'm working on my iPad right now and the source and schematic are both unavailable to me. I do not expect either will be terribly informative beyond what I have explained here. joe