Since you will need to communicate in both directions, I do not think anything other then USART would be easy to operate and setup.
------------------------------
Since you will need to communicate in both directions, I do not think anything other then USART would be easy to operate and setup.
------------------------------
"If the Earth were a single state, Istanbul would be its capital." Napoleon Bonaparte
You do not state any distance or speed restrictions so I assume you have your devices within a metre or so. That means you can work up to at least 100,000 bps with the DEBUG and DEBUGIN commands - assuming 20 MHz crystals.
I have several applications with three or more PICs chattering amongst themselves. In one case I use a bidirectional data lne with the SERIN/SEROUT commands at 9600 bps. In another I use separated data in and data out lines with the DEBUG/DEBUGIN commands. The DEBUG approach should also be able to use a single shared TX/Rx line. The Master Controller (MC) is a PIC 16F877A as is one of the slaves. The second slave is a PIC 16F88. The slave 'F877A mixes gases while the 'F88 runs a Peltier heater/cooler plus a DS1620 and controls temperature. The MC drives some analyser equipment.
Usually, each processor has a single bidirectional data line to the other processors. In addition, each processor has two strobe lines between them.
Whenever the MC needs to send a command temperature to the 'F88 or a desired gas mix to the slave 'F877, it raises the relevant Strobe 1 line. Each slave checks once per loop to see if there is a new command waiting. As soon as the slave sees that Strobe 1 is high it then knows the MC has new data for the slave. The slave raises Strobe 2 and uses a DEBUGIN command with a timeout to load the new command which arrives in a checksum protected packet at 100,000 bps from the MC.
Likewise, if a slave needs to talk to the MC, it raises Strobe 1 and waits for the other processor to reply by raising Strobe 2. The slave then sends a short checksum protected packet to the MC via the DEBUG command. Except when a command exchange is needed, all PIC to PIC lines are configured as inputs and for safety there is a 330 ohm resistor on all PIC to PIC lines.
In my case the packets are only a few characters long and data rate is 100,000 bps so the data exchange takes place in a few milliseconds.
HTH
Brian
Last edited by BrianT; - 25th October 2006 at 00:01.
I am planning on using PIC16F687s on each end. I was going to have a cable directly connect the two micros which would most likely be only 3 ft long or so. In the future I might try to switch this to using infrared. It is not extremely critical to have instant communication but I thought it would be best. I did not know which way would be best to try to communicate via DebugDebugIN or SERIN/SEROUT.
When you made a reference to using strobe, do you mean that one of the pins on the micro goes high and waits for a corresponding signal from the other micro to know that it can now send a signal?
This is what I was thinking but was not sure what to do. I have been mulling the project over in my head. I need to just sit and work it through. Thanks for suggestions.
There's several way to do this. Using USART interrupt or not, Serin/Serout, Debug, HSEROUT.
It depend of what else you PIC need to do.
I prefer to use a PIC with a USART at least for the interrupt feature, and the 2 bytes buffer. In this case the extra Strobe/Busy line could be remove.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
In the process I am controlling, each micro can have very different cycle times. This variation can easily exceed the buffer time that you get with HSERIN/HSEROUT which is only one character time.
By using the strobes, which are checked every loop by each processor, I can tolerate these highly variable loop times.
HTH
Brian
Bookmarks