Absolute minimum delay required to process data across shift registers

Question

In an effort to make my serial data processing faster, I attempted to use serial mode 0 with a system clock speed of about 3.686Mhz. Its clock comes from the ALE output of an unprogrammed at89S52 that has a 22.1184Mhz clock attached to it.

Rather than resort to bit-banging, I'm going to try to lower my crystal speed because I was looking at a datasheet for 74HC595 from Texas Instruments and it mentioned about some rise and fall time for 500ns and based on 8051 documentation serial mode 0 makes a clock at 307200Hz (1/12th the 3.6Mhz). I also seen values of 100ns and numbers close to it in both 74HC138 and 74HC595 datasheet as well.

Basically the circuits I show is pretty much a serial to parallel data expander in which the output dataset is selectable by the microcontroller, and also the microcontroller can issue a flush to the registers when its time to display the data.

What's the highest speed crystal I should be using for this microcontroller to overcome the propogation delays under the worst-case scenarios (assuming power is 5VDC regulated)?

Do I just add the biggest delays up for each bit or is it more involved?

And when I send the data, I'll be filling all the bits up. Example: for device zero, I'll be filling up all 16-bits and for device 1, I'll be filling up all 24-bits, so the clear functionality of each register is unnecessary as the outputs will eventually be connected to LED's through resistors anyway.

Answer 1

Looking at the Ti datasheet of the 74HC595, the 500ns is the maximum rise time at which your input signals should rise. It basically says 'don't clock this too slowly' which your controller will not do.

The 74HC595 themselves can run at >25 MHz (All for 4.5V). Your critical path will be the serial clock SCK going through the 74HC138. But if, in your software you set the 'SER' signal first and after that the clock you will be safe.

Some notes:

Why is the 74HC138 in there? You generate two signals from it but use up 5 CPU pins to control it.

Have you thought of using a small FPGA?