The Mode 0 serial channel is a strange bird. If you use it in any way that, at the outset, makes sense, you're in for a rude disappointment.

You're right, in that if you write to the SBUF, it takes one system clock before the clock is enabled onto the TXD pin and the first bit onto the RXD pin (transmit mode) it then takes eight clocks for the last bit to appear on the RXD pin and the last clock tick to appear on the TXD pin. On the next cycle, transmission stops, and the interupt bits are updated concurrently with that enable. That means that it takes NINE bit times after loading SBUF to transmit eight bits (see page 12 of the "bible" hardware guide).

However, if you IGNORE the status (interrupt) bit(s) you can help yourself with synchronous transmission by reloading SBUF before the TI becomes true, and exactly eight cycles after the last time you loaded it. It's not clear to me exactly how this impacts the internals of the serial port, but it appears to work. It's worth noting that, if you wait for the TI, the shift clock is stopped at the same time that the last valid data appears on the RXD pin. I'm guessing, and that's all it is, that the internals of the serial port are cleared ahead of the time that they're reset by the write to SBUF. The result is (again, this is a guess) that the status flag(s) are set (though I ignore them) and reset on the same cycle, but in different phases. The result is that one can, IF AND ONLY IF he can write a short enough loop, work his way through a buffer of data, incrementing the DPTR each on pass through the loop, and reload the SBUF at the appropriate time. Testing the loop length, of course, is a time burden.

The first time I allowed my firmware guys to utilize mode 0, I was unaware that the clock stops when the data ends, hence we were in full production before I noticed that time was wasted between bytes. The communication (between two 8051's) succeeded famously, though not in the time I'd calculated. This left me mystified and my colleagues ecstatic. Having worked many times with synchronous communication devices, even having built a number of synchronous devices myself, I couldn't even imagine that one would work in quite this way.

With respect to the O/P's hardware, it should work in very much the same manner as the Mode-0 serial channel, except that there has, so far, been no indication of how he intends to generate the PISO load clock, or the SIPO receive clock, or, for that matter, the shift clock for both. There's also no indication of how fast he wants to go, but, given that he's using serial logic, I'd guess that he wants to work at some rate other than that at which the MCU operates. Until he tells us otherwise, we have to guess. He's certainly not going to get by with just the two devices he's named. Since the Mode-0 port will do more-or-less the same thing as those two device, aside from the timing, etc, and since it will read its own "writing" as will the hardware he's named, I'd say there's at least a chance that he can do this with Mode-0. Of course, it's ruled out if he has only one serial port and is using it for async comm's already.

RE