Multi Pic comunications

I am wanting to connect a number of PICs together and have them all communicating. My plan is to connect a number of devices like GLCD, keypad, I2C and others to a network of Pics which will all feed in to a Master Pic (GLCD controller).

My question is about the best communication form, I have looked at Canbus and the I2C communications can anyone advise on others or if the said communication have any down falls to my requested requirements?
I haven't yet worked with Canbus and only used I2C communications with DS1307 realtime clock so my experience is low, but would like to be heading in the right direction for the start.

I personally use the I2C bus for a number of things... But!!! sometimes I find devices that appear as SPI only with no I2C equivalent.. So sometimes I wish I'd have gone down the SPI route...


But I get on with I2C, so I'll stay with it....

My 2 cents; for communications between PICs I've found it easier to create RS232/RS485 Master/Slave PICs with a solid protocol (Modbus is a solid protocol, but depending on your complexity you may not need such). Next, 3-wire (e.g. SPI, Microwire) communications is also easy to implement Master/Slave PICs. Third, 2-wire (e.g. I2C) communication is easy to implement on PIC as a master but not as easy for slave. Finally, 1-wire Maxim protocol is quite complicated to implement as a slave on a PIC.

How I consider level of complexity (especially for the slave-side on a PIC): will the code required to implement the slave-side communication allow for other processing to occur in the same PIC?

Ian Rogers said:

I personally use the I2C bus for a number of things... But!!! sometimes I find devices that appear as SPI only with no I2C equivalent.. So sometimes I wish I'd have gone down the SPI route...

But I get on with I2C, so I'll stay with it....

Click to expand...

I started with I2C stuff too but soon changed to SPI where possible, it's much faster, easier to implement, easier to debug, easier to run multiple devices etc, I think you would find it a dream to use after using I2C.

The down side is it takes 3 wires, not 2, and the extra wire (CS) is needed for each device. So for two devices you need 4 wires. I think that's a small tradeoff for something faster and easier to use and the penalty of having the extra Chip Select wire also pays off in safety and reliability, as any device on the SPI bus can only work if its CS wire is activated.

There's too many people using I2C for completely the wrong reasons - its sole purpose was to interconnect IC's on a largish size board, specifically TV sets originally.

SPI would be far less good for this because of the multiple wires required, the point of I2C is that it's a simple two wire bus.

For what the OP wants it depends entirely on EXACTLY what he's wanting to do - why limit yourself by starting off with an unwanted, complicated and limited protocol - it's simple and easy to have RS232 type connections between the chips, bi-directional on a single pin if that's needed - or even loop through from one chip to another, checking for specific device addresses.

By all means use I2C IF you've got I2C chips in the design, or SPI IF you've got SPI chips in the design, or CANBUS IF you've got CANBUS devices in the design - but if you don't have any of those, why use them?, unless you've got a good reason to?.

Mr RB said:

I started with I2C stuff too but soon changed to SPI where possible, it's much faster, easier to implement, easier to debug, easier to run multiple devices etc, I think you would find it a dream to use after using I2C.

The down side is it takes 3 wires, not 2, and the extra wire (CS) is needed for each device. So for two devices you need 4 wires. I think that's a small tradeoff for something faster and easier to use and the penalty of having the extra Chip Select wire also pays off in safety and reliability, as any device on the SPI bus can only work if its CS wire is activated.

Click to expand...

Totally agree, I have used I2C and SPI in the past and I will always choose SPI wherever possible. Much faster and less hassle. Plus it is very easy to implement in programmable logic.

I would love to see a micro with an inbuilt shift register you can sample when CS resumes to idle and another shift reg that gets clocked out when CS goes active. You could daisy chain as many as you wanted, and clock them all at decent speeds (some SPI controlled chips offer this).