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 ---------- > From: Eric Oliver > To: PICLIST@MITVMA.MIT.EDU > Subject: Re: Inter-PIC communication > Date: Thursday, August 19, 1999 6:34 PM > > 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!" > > > > Thanks, > > Evan Short. > > > > -------------------------------------------------------------- > > Evan Short - Electronics Engineer > > Ferrari Gestione Sportiva - Maranello, Italy > > -------------------------------------------------------------- > > > > << File: ATT00001.htm >>