Shift Register 595 Library

I'm going to develop shift register driving circuit and code. Actually I use TI TPIC6A595 register, that is almost the same as 74HC595 (main difference is that TPIC drives more current).
There is library at Arduino Playground for 595 Arduino Playground - ShiftRegister595 Library, but this library actually doesn't work. ShiftOut function goes endless loop due to typing mistake, also there are some other mistakes.
I get it working making some changes but as guess better I write a new library with ability to change clock frequency and some other useful features.
Just now I can write out working variant of ShiftOut function

#define MCLOCKDELAY delay(5)
...
void ShiftRegister595::shiftOut(byte out){
  bool pinState = false;
  pinMode(clockPin, OUTPUT);
  pinMode(dataPin, OUTPUT);
  digitalWrite(dataPin, LOW);
  digitalWrite(clockPin, LOW);
  for (int i=7; i>=0; i--)  
  {
    digitalWrite(clockPin, LOW);
    if ( out & (1<<i) ) 
    {
      pinState= true;
    }
    else 
    {	
      pinState= false;
    }
    digitalWrite(dataPin, pinState);
    MCLOCKDELAY;
    digitalWrite(clockPin, HIGH);
    MCLOCKDELAY;
    //digitalWrite(dataPin, LOW);
  }
  digitalWrite(clockPin, LOW);
  MCLOCKDELAY;
}

I'll put here whole library when I done with it.

Sweet. Will be following this thread.

why the 5ms delays?

Here is a good and simple library, why write another?

http://bildr.org/2011/08/74hc595-breakout-arduino/

Why use software when you have fast onboard hardware - the SPI port?

#include <SPI.h>

digitalWrite(RCKpin, LOW);
SPI.transfer(your_data_byte);
digitalWrite(SRCKpin, HIGH);

SCK, goes to SRCK (shift register)
MOSI goes to serial data in
MISO not used
SS got to RCK (output register)
OE/ to GND if not using for PWM
MCLR to +5 if not being used

CrossRoads:
Why use software when you have fast onboard hardware - the SPI port?

#include <SPI.h>

digitalWrite(RCKpin, LOW);
SPI.transfer(your_data_byte);
digitalWrite(SRCKpin, HIGH);

SCK, goes to SRCK (shift register)
MOSI goes to serial data in
MISO not used
SS got to RCK (output register)
OE/ to GND if not using for PWM
MCLR to +5 if not being used

It is good point but my application has some requirements that makes me to writing software shifter.
I should drive few registers (not in serial mode) , also I'm going to use only 2 wires to drive register, how? I'll explain later.
And another point is that due to long distance between amtega and register I should use low frequency clock, but I can't serve only one register long time, therefore I'm going to drive registers via loop and timed clocking.

guix:
Here is a good and simple library, why write another?

http://bildr.org/2011/08/74hc595-breakout-arduino/

Unfortunately this library has the same problem, the clock frequency isn't supposed to be controlled.

Here is simple model of register driving logic via 2 wires.
Idea is to generate RCK rising via SRCK, just by R-C and diode.

you should use R & C according Clock frequency and packages interval.
It is supposed that there is some interval between pakages sent to register. For my application it is normal, if you need continuous shifting mode, you can't use my logic.

Why not just use a shift register without a 2nd stage then?
Like 74AC299 or equivalent?

Lets run the circuit simulator and see what we have

You can see that after clock signal goes off, capacitor C1 begins discharging through resistor R1 and we have delayed RCK signal.
Keep in mind register datasheet to figure out logic levels for stable working.
For example for my TPIC6A595 we have:
High-level input voltage at least: 0.85VCC;
Low-level input voltage max: 0.15VCC;

Oh, I understand the concept just fine - I'd just rather see a nice clean clock edge vs a slow capacitor charging up signal to drive the 2nd state Clock line.

CrossRoads:
Why not just use a shift register without a 2nd stage then?
Like 74AC299 or equivalent?

Do you mean shift register without buffer register?
Then you have dirty data on output while you send serial data in.

I suppose having all outputs change together on the RCLK after shifting a bit in is somewhat better.
But since only 1 bit is changing, I'm not sure you'd see much difference.

Slow rising shouldn't considered as problem if RC is calculated correct.
Here is two things:

1. register in has hysteresis to guarantee that there isn't any debounce.
2. RCK rise should be delayed from SRCK, this guarantees that all data is send correctly.

CrossRoads:
I suppose having all outputs change together on the RCLK after shifting a bit in is somewhat better.
But since only 1 bit is changing, I'm not sure you'd see much difference.

I don't understand exactly what do you mean.
Look, my task is to drive shift register via 2 signal wires (clock and data), do you have any better idea how should I do it?

Run the RC signal thru a buffer so that it puts out a nice clean edge.
A simple op-amp/comparator would do it - output stays at low level until the cap charges up to the comparison level, and then the output flips, nice & clean.
Logic devices with "schmitt trigger" inputs are designed to do that. Here is an example device

CrossRoads:
Run the RC signal thru a buffer so that it puts out a nice clean edge.
A simple op-amp/comparator would do it - output stays at low level until the cap charges up to the comparison level, and then the output flips, nice & clean.
Logic devices with "schmitt trigger" inputs are designed to do that. Here is an example device
http://www.ti.com/lit/ds/symlink/sn74lvc1g17.pdf

This register has inside trigger with hysteresis, why should I add extra external trigger?

You are inferring that from something in the data sheet? I see no mention of hysterisis.
Nor a minimum rise time on the clock signals, only that the testing was done with <=10nS rise & fall times.
So maybe it doesn't matter, as long as the current into the cap is limited to not overstress the pin driving the serial clock line.

page 5
High-level input voltage, VIH 0.85 VCC VCC V
Low-level input voltage, VIL 0 0.15 VCC V
Also there is EQUIVALENT OF EACH INPUT, on page 4.

About max frequency, same page
Pulse duration, tw (see Figure 2) 20 ns

but I'm talking about frequency due to cable limitations, not register limitations.