Shiftin / pic to pic communication.

[bearpawz]

Hi all

I am needing to have one pic communicate info to another pic. What I want to know is this: lets say I need to send info from pic1 to pic2, and use shiftout on pic one to send the data, and shiftin on pic2 to receive. On pic2, will the pic actually wait for the 8 bits of data to shift in? Basicly Im trying to figure out how to syncronize them as pic2 may not always be ready to recieve data, and pic1 may not always be ready to send it. Can someone please point me in the right direction here?

[mackrackit]

Can you switch over to hardware serial ?

Then you could use an interrupt to receive the data.

Less pins used too.

[HenrikOlsson]

Hi,
You can't use Shiftin and Shiftout like that. Both commands expects to be "in control" - both acts as the "master" - so they can't really be used the way you want.

Using RS232 as mackrackit suggests is probably your best bet. You can use either the hardware USART or the bitbanged SERIN(2)/SEROUT(2) commands with flow control to make sure PIC 1 doesn't begin sending before PIC 2 is ready.

/Henrik.

[ScaleRobotics]

Daniel wrote up a pretty nice example of one master pic talking to two slaves via I2C. This might be of interest, though Dave's suggestion would probably be better for busy pics.

http://www.picbasic.co.uk/forum/content.php?r=224-I2C-Salve-with-a-PIC

[BrianT]

I have a system of three 18F4620 and three 16F88's all chattering away. I needed a peer to peer comms system that is able to tolerate the target PIC being busy for a fairly long time and very minimal overhead to those PICs not actually talking at the time. I use 3 common pins on all PICs. ATTention, ACKnowledge and MeSaGe, ATT, ACK, MSG. These all idle high, pulled up by weak pullups. All the ATT, ACK and MSG lines idle as inputs.

Before sending, a calling party checks that ATT and ACK are both high then it pulls down ATT and sends a series of ADDRESS bytes. All other PICs routinely check the ATT line and if ATT is high they immediately resume their normal program. If ATT is low they check the MSG line for what address is being called. If ATT is low and MSG has MyAddr then that PIC pulls the ACK line low. All others set a NotForMe flag and return to normal business. The calling party then knows the target has seen the call and so it then sends the data packet. It sends until the ACK line goes high which signals the sender that the receiving party has received an error free packet. When the ACK line goes high, all other PICs not involved in that transmission reset their NotForMe flags.

There is minimal overhead when there is no active traffic. Each PIC just looks at the ATT line and if low it resets the NotForMe flag, were it high, and skips on to its regular program. I can set the maximum number of tries that a calling party attempts to connect. If that times out I set a "TxPending" flag and get on with the normal program. At a lower rate, the TxPending flag causes the sending party to try again.

Comms is 9600 with a 4 MHz clock or 57600 bps with 20 MHz clocks. Identical code runs in all PICs and in one PIC16F88 I just run the receive code as that PIC is purely a slave. All other 5 are peers.

HTH
BrianT