Post by thread:Inter-PIC communication

part 0 2499 bytes 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 -------------------------------------------------------------- </BODY> </HTML> </x-html>

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}> > > 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 > -------------------------------------------------------------- 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)

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}> > Thanks, > Evan Short. > > -------------------------------------------------------------- > Evan Short - Electronics Engineer > Ferrari Gestione Sportiva - Maranello, Italy > -------------------------------------------------------------- > > << File: ATT00001.htm >>

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}> From: Eric Oliver <spam_OUTericTakeThisOuTKEDCOENT.COM> > To: .....PICLISTKILLspam@spam@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 >>