Distributed system with PICs (general discussion)

[KansaiRobot]

Hello and thank you all for the help.

This time I would like to ask a little bit more general type of question (rather than an implementation one)

So far I have been doing my projects using a PIC18F2550. For every project I used one PIC. (for example to control a stepper)

Now, say that I want to control 5 motors (or any other process-LEDs , valves, it does not matter). Let's call these processes A,B,C,D,E
Each process is done on a PIC and I want to control (centralized or distributed) these from another processor (PIC or maybe other , say ARM, Raspberry Pi, BeagleBone whatever).

How do you guys think communication between the modules should be done?? (serial, CAN, SPI, I2C,anything etc etc etc)

Any advice or opinion about this will be greatly appreciated.

 

[Ian Rogers]

Me personally! I would use a 16 pin port expanders on the SPI... The drivers only need 4 pins each and the the last could be done on a pic port!!

 

[granddad]

Things to consider , amount of code area and speed of mcu / communications , distance and noise , master / slave or polled . error detection . Personally my choice would be PIC24EP512GU810 70MIPS, 51 I/O keep it all in one micro.

 

[KansaiRobot]

Me personally! I would use a 16 pin port expanders on the SPI... The drivers only need 4 pins each and the the last could be done on a pic port!!

I ve been told SPI would work only for small distances.. (how small I dont know). What do you think?

 

[KansaiRobot]

Things to consider , amount of code area and speed of mcu / communications , distance and noise , master / slave or polled . error detection . Personally my choice would be PIC24EP512GU810 70MIPS, 51 I/O keep it all in one micro.

You mean keep all the control in one micro?
But I am going for having each process on its own micro and coordinating them (I am thinking master-slave but I am open to others)

 

[nsaspook]

I ve been told SPI would work only for small distances.. (how small I dont know). What do you think?

SPI will work at any reasonable distance with the right line drivers if you account for transmission delays in the order of a ns per foot each way. Protocol overhead with networks of small controllers can be a headache if you partition the tasks to hardware module detail and expect real-time control with large datasets being exchanged. Don't pass raw data unless it's necessary and use a task/results/exception based protocol unless the critical data has a dedicated communications path with deterministic timing.

 

[ronsimpson]

How do you guys think communication between the modules should be done?? (serial, CAN, SPI, I2C,anything

It sounds like you need more CPU speed and maybe more hardware than will fit in one part.
Do as much of the serial in hardware as possible. Example: don't do I2C in software! I would choose a serial type that uses the least CPU power. Example:some UARTs have a 9 bit mode where the 9th bit can be set to 1 for the first byte in a command and set to 0 for all data. And the UART will only interrupt you when bit 9 = 1. (on interrupt check to see if it is my address, if not then return, else service command and data)

There is a advantage to having a motor driver that only has one motor to think about. (one motor and serial port) This might allow for a small slower part. Then what you are building is a smart motor.

There is an advantage to "RS232 at 5V". Then with the addition of a RS232 line driver a PC can listen in or even send commands.

 

[granddad]

Thanks for the interesting post. I think plus and minus for any robotic solutions, for sake of argument... focus on one task say an ultrasonic distance sensor handled by a remote slave mcu its program computes distance and waits for its master to ask for its data , it then sends " Edge of cliff 1 meters away" master tells motion motor to slow , motor slows. master checks task B, but task B takes some time to resolve , task C interrupts master a few seconds , task D interrupts master , master checks distance from cliff ........... oops .
Ok a bit simple and easy fix , just check sensors more often ... or have all the tasks given mcu time and / or priority interrupts on one chip....
Devise your own RTOS ...