Boosting speed of data on GPIO line between microcontrollers

I made a circuit in which the data bus P0 of an AT89S52 is connected to the P1 of an AT89C4051 and both clocks are each driven by their own 22.1184Mhz crystal.

I have used a 10K standard pull-up on each of the port pins, but due to the high speed of the crystals, I'm starting to think the resistor value is too high.

I looked at both datasheets and the AT89S52 states maximum current per port pin shouldn't exceed 10mA. This suggests I can get away with a 500 ohm resistor but that would kill my batteries in no time.

Both data sheets state each pin has a 10pF capacitance if Ta = 25 degrees and test frequency is 1Mhz, but my test frequency is more like 2Mhz because many instructions on these microcontrollers execute at 1/12th of a clock cycle. and if I keep executing commands to read data from a port, I want to read quickly.

Sure I can get away with this:

Mov A,P0
nop
nop
nop
nop
nop
...
Mov A,P0
nop


But as you can see, those nops waste clock cycles.

Given that I have a capacitance and resistor value, I did some math (10K * 20p) and I got 795774.71545948 Hz which is the max speed? or I did something wrong? I used this tool: http://sim.okawa-denshi.jp/en/CRlowkeisan.htm

I picked 20p for the capacitance because I assume when the pins are connected, the capacitor values are added (capacitors in parallel).

So how do I calculate the max speed on the wire between the GPIO lines and if I'm on the right track, just how low can I go with the resistor without causing significant battery drain? should I use 1K? 4.7K?

• Switching from an open-drain protocol to a push-pull one would improve speed. You could still place a series resistor to limit fault currents. And you could even start out in an open-drain mode but enter a faster push-pull by agreement within a session. But what speed are you currently achieving? And is it limited by analog concerns or software bit-banging ones? I2C's faster mode for example normally runs at 400 KHz with pull-ups in the 2.2K range... Also note that your pull-up only wastes power when you drive the line down to signal, at idle it has no consumption. – Chris Stratton Sep 7 at 16:26
• Chris's advice is well-thought. Too, I wanted to emphasize to you also that if you are looking for speed then you want to take a very careful examination of the peripheral interfaces you have available. They can perform operations faster than software. It is your problem to work through those details to see what might work. You may be better off using a serial peripheral vs bit-banging to use an 8-bit wide port, given the async nature of two cpus. Or using a single oscillator for both cpus. And/or using the bus peripheral as though it were a memory interface (on one side, anyway.) Be creative. – jonk Sep 7 at 17:09
• I am currently looking at replacing AT89C4051 with AT89LP4052 since its advertised as 6X faster but if youre suggesting push-pull over open-drain for speed, then maybe I should just make the switch. Maybe the former chip can't handle a mov A,P1, orl A,B, mov P1, A efficiently like a new chip could with my resistor choice. Ok, I'm going to buy the new chips, a 1K resistor bank and a 2.2K resistor bank and try each one in turn instead of the 10K and make the ports high impedance when not in use and see what happens. – Mike Sep 7 at 17:35
• Agree with @jonk on looking for hardware solution. But in addition to that I always suggest verifying speed requirements. Any data transferred should be processed somehow, unless your device is some kind of modem or adapter. So, the data rate should be based on how much you can process, not on how fast you can transfer it. Note, that allowing hardware to do the transfer allows you to process more – Maple Sep 7 at 17:35
• If your chip has ISR and trigger-on-timer functionality then you can write "drivers" which TX/RX some arbitrary number of bytes while allowing other code to run. Still not as good as a hardware solution though - most HW serial ports include a buffer and run asynchronously on their own. – rdtsc Sep 7 at 17:58