Searching \ for 'Inter-PIC communication' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Inter-PIC communication'.

Truncated match.
PICList Thread
'Inter-PIC communication'
1999\08\19@121211 by Short, Evan

flavicon
face
part 0 2499 bytes
<P><FONT SIZE=2 FACE="Arial">Hello all,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">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. </FONT></P>

<P><FONT SIZE=2 FACE="Arial">Methinks I'm not being as clear as I should. Ok, how's this:</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">1) Host PIC requests a byte</FONT>
<BR><FONT SIZE=2 FACE="Arial">2) Slave PIC sends a byte, waiting for each bit to be read and acknowledged somehow by the host</FONT>
<BR><FONT SIZE=2 FACE="Arial">3) If one of the two gets out of step, they resynchronize before the next byte.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">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.)</FONT></P>

<P><FONT SIZE=2 FACE="Arial">I'd appreciate suggestions, links, or even cries of &quot;fool, look elsewhere!&quot;</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Thanks,</FONT>
<BR><FONT SIZE=2 FACE="Arial">Evan Short.</FONT>
</P>

<P><FONT SIZE=2 FACE="Tahoma">--------------------------------------------------------------</FONT>
<BR><FONT SIZE=2 FACE="Tahoma">Evan Short - Electronics Engineer</FONT>
<BR><FONT SIZE=2 FACE="Tahoma">Ferrari Gestione Sportiva - Maranello, Italy</FONT>
<BR><FONT SIZE=2 FACE="Tahoma">--------------------------------------------------------------</FONT>
</P>

</BODY>
</HTML>
</x-html>

1999\08\19@122839 by Francisco Armenta

flavicon
face
part 0 2586 bytes content-type:text/x-vcard; charset=us-ascii; (decoded 7bit)

I think in a possible solution whit 2 lines (1: clock signal and 2:data
signal)
in the line of data the host PIC send a bit of request, the slave PIC is
waiting for request of byte (pin host PIC as output and pin of slave PIC
as input), after that host PIC send the bit of request the pin change to
input, when slave PIC recived the request change the pin to output and
send the data whit a bit of stop.

precautions:
the bit of request should be a pulse i.e. line data= 0 then line data=1
and line data = 0, the whit of the bit depending of the time instruction
of slave PIC

Francisco

"Short, Evan" wrote:

{Quote hidden}

Content-Type: text/x-vcard; charset=us-ascii;
name="briones.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Francisco Armenta
Content-Disposition: attachment;
filename="briones.vcf"

Attachment converted: wonderland:briones.vcf 2 (TEXT/CSOm) (0000B952)

1999\08\19@192337 by Eric Oliver

flavicon
face
Can you kind of mix the two ?

1) Master normally sets request line as an input and Master has to check
request line within certain intervals.

2) Slave wants data so it takes request line high and holds for a given
period of time (longer than the interval between master polling).  At the
end of that time, it releases the line.  Master checks and sees that the
request line is high.  Master waits for the line to be released.

3) When the slave releases the line, the Master pauses for a few uSeconds
and makes the request line an output and uses it for a clock line to clock
data to the slave. After the master has clocked out data, the master sets
the request line to input and goes back to other tasks periodically polling
the request line.

Maybe something along these lines might work but you have to watch for line
contention.

It would be timing dependent, but not frequency dependent.

Eric

>
> 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!"
{Quote hidden}

1999\08\19@212635 by Thomas McGahee

flavicon
face
To avoid line contention you can set the line up this way:

                                         10K
                          -------------/\/\/\----+5v
          330             |             330
PIC(A)----/\/\/\-----------*------------/\/\/\----PIC(B)


or, if you want to save a few pennies:


                                         10K
                          -------------/\/\/\----+5v
          680             |
PIC(A)----/\/\/\-----------*----------------------PIC(B)



Note that the pullup resistor is about ten times the value of the
resistor used to limit current in case of a contention.


To answer your question about mixing methods. Sure, "there is more than
one way to skin a cat."

A lot has to do with the PROTOCOL you settle on. For example, here
is a two-wire protocol with a pullup resistor on each line that is
wired up PIC(A)#1 to PIC(B)#1   and    PIC(A)#2 to PIC(B)#2.

Lines #1 and #2 are BOTH bi-directional lines. The protocol is:
BOTH PIC(A) and PIC(B) start off with lines #1 and #2 as inputs.
If PIC(A) has something to say, it will first of all
check to make sure that Line #1 is free (HIGH). If it is, PIC(A) will
assert it's #1 I/O line as an OUTPUT, and pull it LOW. PIC(A) will
then keep reading its #2 line until PIC(B) pulls line #2
LOW as it's acknowledgement. PIC(A) takes note of how long it took
PIC(B) to respond. PIC(A) will acknowledge the
PIC(B) acknowledgement by returning Line #1 HIGH.

PIC(A) sees Line#2 go HIGH, and it is now synchronized and ready
to send data bits.


+++ (loop point)
PIC(A) switches Line#2 to output mode. Data is first placed on Line#2
by PIC(A), and then Line#1 is pulled LOW for a time determined
by the original PIC(B) response time. DATA is kept on Line#2,
but Line#1 is now made into an INPUT by PIC(A), and
it waits for this line to be brought LOW by
PIC(B) as an acknowledgement that it has read the DATA bit.
(If it does not get an acknowledgement within a certain period
of time, it should quit).
When PIC(A) sees the LOW on Line#1, it changes the bit value
on Line#2 to its OPPOSITE value. When PIC(B) sees the value on
Line#2 change, it acknowledges by making it's Line#1 an INPUT
again.

Loop to +++ and update a counter until all 8 bits are assembled

Both PIC(A) and PIC(B) go back to using LINE#1 and LINE#2 as
inputs.

Note that this method allows either PIC(A) or PIC(B) to initiate
a data transfer.

*****
If the direction of data movement is unidirectional, say always
from PIC(A) to PIC(B), but initiated by a REQUEST for data from
PIC(B), then modify the protocol accordingly:

BOTH PIC(A) and PIC(B) start off with lines #1 and #2 as inputs.
When PIC(B) wants to request a data transfer, it make it's
Line#1 an output and pulls the Line#1 LOW. PIC(A) would
respond by setting it's Line#2 as an output
and pulling Line#2 LOW. When PIC(B) sees Line#2 go LOW, it
makes Line#2 an input again, so it gets pulled HIGH.
PIC(A) takes note of how long it took PIC(B) to respond.
PIC(A) sees Line#2 go HIGH, and it is now synchronized and ready
to send data bits.

+++ (loop point)
Data is first placed on Line#2
by PIC(A), and then Line#1 is pulled LOW for a time determined
by the original PIC(B) response time. DATA is kept on Line#2,
but Line#1 is now made into an INPUT by PIC(A), and
it waits for this line to be brought LOW by
PIC(B) as an acknowledgement that it has read the DATA bit.
(If it does not get an acknowledgement within a certain period
of time, it should quit)
When PIC(A) sees the LOW on Line#1, it changes the bit value
on Line#2 to its OPPOSITE value. When PIC(B) sees the value on
Line#2 change, it acknowledges by making it's Line#1 an INPUT
again.

Loop to +++ and update a counter until all 8 bits are assembled

Both PIC(A) and PIC(B) go back to using LINE#1 and LINE#2 as
inputs.

*****
Again, you can use an existing protocol, which may have more
twists and turns in it than you need for your own application,
or you can "roll your own" protocol, as I have done in the
above examples.

Make sure that your protocol is complete. It should include
some way of gracefully recovering from error and glitches.

When the speeds of the two PICs are quite different you want
to avoid anything that relies on absolute timing. Instead
use relative timing. This can be done by timing responses
in the initial synchronization phase and placing this value
in a register so it can be used to set the relative timing
loops.

I hope this helps.
Fr. Tom McGahee

----------
{Quote hidden}

1999\08\19@232033 by Joseph Rutsky

picon face
If you are really looking to save some lines, look into the Dallas one wire
specs.  All timing dependent.  It is covered in the book Serial Pic'n.  If speed
isn't the greatest concern, it might work for you.

Joe

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...