Communications Protocol Choices

[mpgmike]

I'm a bit new to communications between processors. I recently spent the time to get USART (HSERIN/HSEROUT) functional. It seems this is a great communications protocol for 2 processors to talk to each other. I'm developing a controller that will incorporate several processors, each dedicated to specific functions. I want them all to be able to talk to a Host (PIC18F25K50) that can then talk to a laptop via USB.

I looked at SPI and I2C. SPI seems hardware intensive, whereas each processor would require a Slave Select (SS) pin. I2C only needs 2 pins (SCK/SDA), but seem software intensive.

Has anyone wired several processors together? Which protocol did you choose, and why?

[richard]

thats a pretty big subject , I would be thinking along these lines

the physical layer depends on :-
transfer rate is it megabytes/S or bits/S
transfer distance is it kilometers or millimeters
transfer cost [priority,interrrupts,reliability,latency]
is it a master slave or a multi master or peer to peer network
does the physical layer need collision sense , ack/nak ,crc
the protocol layer depends on :-
is it just master multi slave or will it need multi master or peer to peer comms
does it need ack/nak ,crc
is it a compelled sequence or asyncronous system
will the slaves be polled or do they need separate channel/s to signal master
when they have the need

[HenrikOlsson]

As Richard says, as is usually the case, it depends.... :-)

If there are severeal boards connected together within the same enclosure like thru a backplane connector etc then you could possibly use the open drain UART aproach (bus pulled up by a resistor and each device yanks it low) for the physical layer - then you apply a PROTOCOL (ie the "language" the devices uses to speak to each other).

If the boards are spread out I'd probably look at RS485 as the physical layer, either half or full duplex depending on what you're doing. Same thing again, you apply whatever protocol you want and transfer it via RS485.

A protocol can be as easy or as complicated as you want/need to make it. MODBUS is a fairly common master/slave protocol for industrial stuff but it might not suit YOUR needs at all.

CAN is another option, which is a differential bus (like RS485) with a specified protocol but the complexity increases.

/Henrik.

[mpgmike]

Thanks for the responses. Individual MCUs will be mounted on the same board, same plane, with one exception. One of the MCUs will be located perhaps 1-3 meters (several feet) away from the Master Controller, and be routed through a somewhat electrically noisy environment.

I'm intending for a single Master with all other MCUs configured as polled Slaves.

The I2C protocol seems like it's suitable so far. I'm just unclear on how much "work" is done manually with software and how much occurs in the background with hardware. The PBP3 Manual lists I2CREAD/WRITE commands, but states they are software driven and don't rely on I2C hardware.

[richard]

i2c would be my last choice , pbp has no slave implementation, no hardware implementation

spi is easy and fast uses hardware but not brilliant at several metres in noise
but then again pbp has no built in functionality for spi modules

rs232/tty ,rs485 are good at distance and noise and use the hardware modules , a little slow

you make no mention of transfer speeds , frequency or data size

[Dave]

For good noise immunity I would suggest RS-485 for any distance. I use a protocol which is loosely based on Modbus RTU.

[mpgmike]

i2c would be my last choice , pbp has no slave implementation, no hardware implementation

you make no mention of transfer speeds , frequency or data size
As for transfer speeds, I intend to use a Rotation variable in the Master that polls one peripheral MCU each pass of the Main loop. Transfer size is 2 bytes; first byte is what the data is (Temp) while the second is the value of that variable (71).

[Dave]

Here is something I found quite a while ago. Use it as a starting point...

[mpgmike]

Thanks Dave, I downloaded it and will give it a thorough looking over.