> Well, let the master PIC send messages to the slave and tell the slave what
> to do, then read the result from the slave. It's no different than
> interfacing another IC except that YOU define the protocol between them. Use
> I2C if you like or plain parallell communication or RS232 or whatever feels
> good.

I've been working on a good bus protocol for potentially-busy CPU's.  The
best I've come up with so far for connecting precisely two CPU's which may
be arbitrarily busy and do not have any "special" hardware useable for such
a task is described below.  Note that I2C does not meet this criterion since,
without hardware assistance, a busy slave device could miss bits coming from
the master.

Hardware:
  The hardware consists of two open-collector signal wires for a two-device
configuration, or three or four [four wires will reduce CPU overhead on any
devices that aren't being addressed] open-collector wires for any other
number of devices.

Protocol:
  All data bytes are formatted as nine bits: a "0" start bit and eight data
bits.  Other than during a byte, all "1" bits received will be ignored.  Any
device transmitting should send at least one "1" bit before the first zero
bit, and messages are ended by sending a "1" bit where the start bit would
be expected.

During idle state, both lines are idle.  To send a zero, the sender asserts
line A; the receiver then asserts line B to acknowlege receipt.  Once the
sender sees B asserted, he releases A; the receiver will then release B.
Once the sender sees B released, he can send the next bit.

To send a one, the procedure is as above except that the sender asserts B
and the receiver acknowleges by asserting A, etc.

If the sender is sending a message to which a reply is expected, he will
assert B to send the final "1" and the receiver will assert A.  Then the
sender will release B and the receiver will release A and assert B [to
send his leading "1" bit].  Since the sender has released B and yet it
is still asserted, the sender can tell that B has acknowleged the sender's
release of B and is trying to send a bit.

While this protocol is somewhat speed-limitted by the requirement of two
transitions in each direction for each bit sent, it is completely insensitive
to any unexpected delays either party might experience.  Naturally, if one
party is busy with a 90ms task every 100ms the throughput will suffer, but
any bits sent will be (eventually) received and confirmed.

What does everyone think of this as a protocol?