From: Thomas McGahee <tom_mcgahee@sigmais.com>
To: pic microcontroller discussion list <PICLIST@MITVMA.MIT.EDU>
Subject: Re: Inter-PIC communication
Date: Thursday, August 19, 1999 5:55 PM

You can achieve TWO way communication using just TWO lines. Let's 
say that each PIC has a SEND line and a RECEIVE line. Let's call
the lines on PIC(A) SEND(A) and RECEIVE(A). The other PIC has 
I/O lines named SEND(B) and RECEIVE(B). Use a wire to connect
SEND(A) to RECEIVE(B), and another wire to connect RECEIVE(A)
to SEND(B).

To initiate a transfer of data, PIC(A) would pull SEND(A) LOW and
then wait for PIC(B) to acknowledge the send request with a LOW
on SEND(B). As soon as SEND(B) changes from a LOW back to a HIGH,
(end of ACKnowledge), PIC(A) will wait for a time equal to what
we will call a Short Period, and then output a HIGH on SEND(A).

PIC(B) will have been counting in a loop waiting for RECEIVE(B)
to go HIGH. When it sees the HIGH on RECEIVE(B) it will have
generated a count that it will use to determine the timing for
data. 

Take the loop count we got during the Short Period, and multiply
it by 1.5 
(clear carry, shift original right, and add to original)
Call this the 1.5Short Count



Each data bit will begin with a HIGH to LOW transition

PIC(A) now waits a bit to give PIC(B) a chance to do whatever
housekeeping it needs, and then it proceeds to send out data
in the following format:
     _
|___| |   High-to-Low followed by 2x LOW and 1x HIGH means a ZERO
   ___
|_|   |   High-to-Low followed by 1x LOW and 2x HIGH means a ONE

Note that each "BIT" begins with a High-to-Low transition, and
this provides on-going synchronization at the BIT level. It is
perfectly OK for a data stream to stretch out the HIGH time, as
the determination of whether the BIT is a 0 or a 1 is made based
solely on the length of the LOW time. If it is significantly 
longer than a Short Period, then it must have been a 1. One way
to determine whether or not you have received a 0 or a 1 is to
go through a loop with exactly the same number of instruction
cycles as the loop used to generate the count from which we
derived the 1.5Short Count. Execute the loop for a number of times
equal to the Short Count. When the loop terminates read the
RECEIVE(B) line. What you see at that moment is the BIT value.
(The value at 1.5 x Short Period)

Rotate the BITs into a BYTE. Once you have a byte, process it.

If you are always processing packets of data that have a 
fixed length, then you can calculate timing values just once
for each packet. This helps to speed things up.

This method will not give you blazingly fast transfer rates, 
but it will allow two PICs operating at different speeds to
communicate reliably.

By the way, it is a good idea to have an initialization phase
in which the two PICs determine which is the slowest, and
then they can efficiently determine what is the highest speed
that they can communicate at. Otherwise you might have a 10 MHz
PIC talking to a 32KHz PIC a bit too fast! Sort of like two
Modems negotiating over what baud rate they will run at.

Fr. Tom McGahee

----------
From: Short, Evan <eshort@FERRARI.IT>
To: PICLIST@MITVMA.MIT.EDU
Subject: Inter-PIC communication
Date: Thursday, August 19, 1999 12:16 PM

Hello all,

It may well be that this is simpler than I think, I suspect I'm missing
something basic. Is there any easy way to transfer a byte (unidirectionally)
between two PICs running at different clock speeds, without using 4 I/O
lines? I keep sketching things and coming up with four lines for the
synchronous approach - a clock line, a data line, a request line and an
acknowledge line (or some variation of the above.) I can do this fine with
three lines by using the request line to clock data, but then I don't have
any way to resynchronize the link if the two PICs get out of step.
Methinks I'm not being as clear as I should. Ok, how's this:

1) Host PIC requests a byte
2) Slave PIC sends a byte, waiting for each bit to be read and acknowledged
somehow by the host
3) If one of the two gets out of step, they resynchronize before the next
byte.

I guess I could also do this async. with only a request line and a data
line, but then I have to slow things down lots to account for the different
clock speeds and possible drift in clock frequencies (Slave PIC is using an
internal osc, host a crystal at a different frequency.)
I'd appreciate suggestions, links, or even cries of "fool, look elsewhere!"

Thanks,
Evan Short.

--------------------------------------------------------------
Evan Short - Electronics Engineer
Ferrari Gestione Sportiva - Maranello, Italy
--------------------------------------------------------------