Currently I own a few AT89S52's and AT89LP52's and I run them with 22.1184Mhz crystals.
The difference between the two is that the AT89LP52 processes code 10x faster,
however it can't work with my peripheral as well as the AT89S52 can.

I made myself a large 4-digit number display unit. Each digit is
connected through resistors to a 74HC595 shift register. These shift registers
are then chained together in series, which means I have to send 32 bits of data
to update the display.

I'm assuming the propagation delay of these registers in total are larger than the
pin delay of the AT89LP micro at high speed.

So I tried to scale down the speed just a little bit on the AT89LP52, and I even
added 8 nop's (no operation commands) right after a pin state changes. I'm having
no luck ith the high speed micro on this.

Maybe I'm best to wait until I get the AT89S8253 so that I can try its X2 mode
instead along with adding a "nop" here and there.

Or is "nop" the wrong command? hmm.

Are you using a serial port for writing the 32 bits into the shift register(s) or do you directly program a discrete I/O pin for that task?

In general it is not a wise decision to do timing using NOPs. A more reliable time source would be desirable. Check if there is a timer or a free running HW counter so you can write some routine which waits until a suitable number of increments was seen (consider overflow, please).

When it comes to NOPs: I do not know the AT89S architecture and tooling. However, from other architectures, I know that NOPs are likely to be removed - sometimes by the toolchain (compiler/assembler/optimizer), sometimes by the microcontroller itself, e.g. by discarding the NOP in an early pipeline stage. So the desired effect of a NOP may not be there.

Did you check the timing on the input pin of your display with a scope?

hmm then I guess I'll need a different command. I'm already putting other things on a timer in the same system such as updating the LCD with information. I can't afford to put my big number display on a timer because it has to update very fast. I think my main answer is to get better batteries and work on my division routines.

If your MCU runs at 22MHz, then you can't generate an output faster than 11MHz. The 74HC595 at 4.5V has a maximum clock frequency of 25MHz, so there's no problem there. Furthermore, at 4.5V the setup and hold times are in the 20ns range, a fraction of what you'd need to bit-bang a port pin. If you drive the shift regs via an SPI, the setup-hold there would be roughly half period of SCLK, close to 50ns even if your SPI can run SCLK at half the core's clock.

The propagation delay of these shifts is irrelevant, as they are synchronous registers running from the same clock. As long as a register's serial output delay meets the setup-hold requirements of the next register's input in the chain, then you can build as long a chain as you wish (with sufficient drive capacity for the clock, of course).

What do you see on the scope?

I have no scope, but maybe my problem is the batteries, but eventually I want my system to be able to run on batteries. Maybe I just need stronger batteries.

What is the signal you are using to drive 74HC595 for shifting the data, and what signal you are using to load the data to register. Are you treating all pins that are used for 74HC595 from processor as GPIO pins? Have you made the proper programming of those pins?

It is better to use the internal timer for sequencing all your operations and also you can get proper delays generated out of timers.

Can you replace 22.1184 MHz crystal with some lower one and study the behavior of the system? I feel the proper sequencing of the events such as data I/O to shift register and timely loading and enabling the output will solve your problem.

The signals are from GPIO pins, and yes I did make proper programming, otherwise it wouldn't work on the AT89S52. Both AT89S52 and AT89LP52 understand the same instruction set.

The problem is with this unit, I want to be able to update it at least 5 - 6 times a second. Isn't that going to cause a strain on the timer if I put the update routine in the timer? 

After all, to get the number on the display, the system has to do the following:

1. Load the packet from the wireless module on board.

2. Extract the 16-bit number from it

3. Constantly divide the 16-bit number by 10 until 4 digits are received

4. display each number via bit-banging

This process takes about 512 uS on a AT89S52.

Hi!

Can you try a static approach, just to be sure the problem is/isn't speed?

By static approach I mean driving the clock of the shift register in a pace manually controlled, i.e., use a spare digital input of your system to tell the software that is time to give a clock pulse, or even to rise the clock signal and another command in the input to tell it's time to fall the clock signal.

When I first built the number unit, I tested it in a static fashion (by manually setting and clearing the clock line as well as the data line). It works wonderful in a static fashion.

Did you make the static test with the new micro, the AT89LP52?
Once it works with the old one in 'cruise speed', it isn't worthwhile to do a static test with this micro. I suggested a static test with the new one and I suppose it's what you did, right?
Just to clarify things :-)
Success!

the static test was without the micro. The working version was with the slow micro (at89S52) but the non-working version was with the faster micro (at89LP52) yet the code is the same

According to the data sheet on the 74HC595 device, if your operating voltage is greater than 4.5V, it should be able to handle a 25Mhz clock signal which is well beyond what your micro is capable of generating.  If it's not working the problem is somewhere else.

Oh. Maybe that's my problem. I was running the board on batteries and I don't think the batteries are decent enough now. Now let's just say I wanted to run the thing on lower voltage like 3V. I guess I'll have to somehow add more delays?

For development, you should be running off wall power. When everything is stable, then goto batteries.

And get the rygol oscope we are recommending. You will be way ahead of the game. You can easily check and verify timing...

During development, devote one oscope channel to just looking at the power. You can catch all sorts of obscure problems. Do not rely on a voltmeter - they integrate && you lose what the supply is *really* doing.

oops, I forgot to mention that my number board has a timer that turns on when new data is sensed. When timeout happens, all shift register's (74hc595) load clocks are activated at once which in turn updates all the numbers.

The timer is a CD4538 multivibrator with 1nF capacitor and 10K resistor.

I'm thinking of changing the IC to a 74HC4538 instead because its propagation delay is about 20nS where as the CD4538's delay is 100nS.

Hi,

First of all, Resistors do not provide propagation delays.

I have used 74HC595 - four nos daisy chained - with a routine that is called inside a 0.1 msec timer interrupt. However, I have used a renesas microcontroller with 50ns per instruction time. In your case (89LP), it may be similar.

Works smoothly.

So, go ahead and program your device. It will work fine.

Cheers

jkvasan