Pic-TO-Pic Communication

[pasini]

Hi all,

I have 4 small/cheap PICs running at 20MHz with UART, SPI, I2C peripherals. UART is dedicated to RS232 communication with external devices (I am using #USE RS232...). I cannot use UART RX/TX pins for PIC-PIC communication.
I want to communicate all 4 PICs to each other via a serial link. I would like to receive suggestions or experiences on how connect them in order to make data transfer simple. Data throughput is not high and speed can be relatively low at 9600-57600bps, with 8bits/byte of data.

A UART-like communication could be used, if I did not disturb other MCUs tasks, and could use an interrupt to receive or send data.

I tought of using SPI or I2C, since I prefer a hardware soluction than a software one. Are they good options ? I have up to 5 free I/Os to do this task in each MCU. Other pins are being used for LEDs, keyboard ...

I thought of a simple connection like this (point-to-point):

MCU#1 <---> MCU#2 <---> MCU#3 <---> MCU#4

MCU#1 can be considered a MASTER in the communication,since most of the data requests will be originated from it.
In every MCU I can have a routing table like this:

ORIGIN FINAL DESTINATION SEND TO
MCU#1 MCU#2 MCU#2
MCU#1 MCU#3 MCU#2
MCU#1 MCU#4 MCU#2
MCU#2 MCU#1 MCU#1
MCU#2 MCU#3 MCU#3
MCU#2 MCU#4 MCU#3
... .... .....
MCU#4 MCU#1 MCU#3

Thanks in advance for any suggestion. Sample codes are appreciated.
My best regards,
Pasini

[PCM programmer]

If the PICs have an SSP module, then they could be i2c slaves.
See the CCS example file Ex_Slave.c, in c:\Program Files\Picc\Examples
But that method won't work if each PIC must talk directly to every other
PIC. Perhaps look at Mark's i2c Multi-Master code in the Code Library.
http://www.ccsinfo.com/forum/viewtopic.php?t=22105

Also CCS has this method, described in their FAQ. I haven't tried it.
http://www.ccsinfo.com/faq.php?page=connect_pics
The files Ex_pbusm.c and Ex_pbusr.c are in the same directory as above.

[arunb]

Hi,

You can use serial RS 232 pins for this, the RDA interrupt can be used if the PIC has a hardware USART.

thanks
arunb

[Ttelmah]

The problem is that he is already using both the hardware resources that are built for this. The UART is already 'in use', as is the I2C/SPI port.
There are a number of questions:
How far apart are the chips?.
How 'noisy' is the enviroment?.
Which unit currently drives the serial?.
Can one unit be the 'master', or do all units need to be able to trigger communications?.
What devices are currently 'on' the I2C bus or each chip?.
What devices are on the SPI bus from each chip?.

I'd suggest that probably the easiest way, would be to switch the current I2C/SPI devices, to using a _software_ master implementation. The key here is that sice both these busses are 'timed' by the master device, slight pauses or delays in the clocks won't matter, and hence a software implementation will be fine. This then leaves the hardware I2C port available, and a multi-master implementation on this (or single master if one device can be chosen to be the permanent 'master'), can be used.

Best Wishes

[linux123]

Try make protocol 1-wire to comunication, the 1-wire protocol permit 1 master and any slave with 1 pin from PIC, and the protocol it�s simple.

[arunb]

Hi,

You could implement software USART, with the receive pin as pin_b0 , enable the ext interrupt to detect changes in the port, you may also use the portb interupts for this.

I have used int_rb interrupt in a software USART, but I find that it works well only at slow speeds....

thanks
arunb

[Ttelmah]

The problem with software UART receive/transmit, is that both require the chip to be doing nothing else for the entire byte time. A software UART receive inside an interrupt, triggered by the falling edge of the first byte unfortunately requires a relatively low data rate, if the interrupt latency, is not going to result in corrupted data.
One suggestion that does work, is instead to use a seperate 'hardware request' line. If a single interrupt pin is connected between the devices, with a pull up resistor, then the device wanting to send, polls the line, and if it is high, then simply pulls the line low, triggering an interrupt on the other devices (in fact, if the interrupt is enabled, right up to the moment it pulls the line low, there is no need to 'poll' the line, since the chip will have jumped to it's interrupt handler if the line has dropped before this point). It then waits a tiny moment (changed for each device, with the 'highest priority' device waiting the longest), releases the line, and reads it. If the line is still low, _another_ higher priority device has tried to access the bus at the same moment, and a 'bus collision' has occurred. This device then needs to go to it's receive routine (since it must be the lower priority device if the line is still low). Assuming the line goes high, the device waits a time equal to the worst interrupt response latency expected from all the devices, and then sends the data using software serial at the fastest rate possible on another line. The software serial can use the 'float_high' option, allowing the same pin to be used as both the transmit and receive pin on all the devices (obviously with a pull up resistor). Variations of this type of system, can give quite short total times, and work well.

Best Wishes

[pasini]

Hi all,
Thanks for the replies. I think I will use the spare I2c I have, since UART/RS232 cannot be used since it is connected to an external device with MAX232.
I have a PIC18F4550 that can be the master and 3 PIC16F876A that can be the slaves.

How far apart are the chips? They are close in the same PCB, a few centimeters apart.

How 'noisy' is the enviroment? Yes, it is quite noisy but since MCUs are on the same PCB I can handle the noise.

Which unit currently drives the serial? PIC18F4550 can be the master.

Can one unit be the 'master', or do all units need to be able to trigger communications? It is better if all units are able to trigger but I can create a master and poll devices to hear them.

What devices are currently 'on' the I2C bus or each chip? Other microcontrollers of same type PIC16F876A an RTC DS1678 and maybe a temperature sensor.

What devices are on the SPI bus from each chip? I don�t have SPI communication yet. I am not using it for anything, only if I can use it for PIC-PIC communication, but I don�t think it is possible because they share pins with UART.

Thanks all
Pasini

[asmallri]

[Ttelmah]

Very true, but the timings of everything else then become terribly critical. I have systems still on the market, that were built with the very first PICs launched (back before they were 'Microchip'), which manage full-duplex 9600bps communications, and handling half a dozen other peripherals, all based on the device running at only 4MHz. However I'd not suggest this sort of code, if serial comms at other rates are needed at the same time (even using the high priority interrupt, you run into whether you can service the other communication channels without losing data).

Best Wishes

[RSO]

Andrew,

How well do your routines integrate in the CCS compiler since it has no linker?