Interrupts or polling what do you guys think?

[Toymaker]

Hi Group
 
Can any of you experts give me some serial comms and interrupt advice? I have an unusual project, where I am building an advanced robot which has 9 PIC's, 5 are glue logic (bit controlled), but 4 larger PIC's need to be high speed serial linked. There is a master PIC, a sensor PIC, a drive PIC and an arms/claw controller PIC. The master controls everything, but the sensor uC gathers data independently etc. The master is also wirelessly linked to a PC via Easy Radio transceivers.
 
My problem is that I do not want to re-invent the wheel here, I need a good serial comms routines that seamlessly connect everything together (probably via priority interrupts), and am looking for expert advice from those that have experience on such things, and I know there are some amazing technical guru's on this forum.
 
I think the serial comms needs to be in hardware, and the Master PIC is the main processor that the other three connect to. As there is only one USART, then I need to mux (and demux) the Master's CK and DT lines with something like a 4066. My main question is whats the best (and most efficient) way to let the master communicate with the three other processors and RF transceiver? Maybe priority interrupts, where the most important processor gets priority like:
 
RF link [INT0]
Sensory processor [INT1]
Drive processor [INT2]
Arms/claw processor [lowest priority]
 
What has anyone else done? My other idea is to use polling say at 50Hz, this would be much simpler?
 
Many Thanks in advance for any thoughts!

Toymaker

Conceptioneering Ltd - Inventors of the Award winning Cube World - Visit: www.radicagames.com/cubeworld/index.php
To see Product Innovation - visit our website at www.conceptioneering.co.uk

[hgordon]

Without a better understanding of your message structure and processor task assignments, it would be really difficult to provide a useful answer.  As discussed here -
    http://www.societyofrobots.com/robotforum/index.php?topic=4387.0
I have a strong bias against using any interrupts, mostly based on many years of experience with real-time programming and debugging of distributed minicomputer and microprocessor systems, so I will always look for approaches that avoid interrupts.  Maybe this isn't practical for your application, but there's not enough information to make that assessment.

[Toymaker]

Without a better understanding of your message structure and processor task assignments, it would be really difficult to provide a useful answer.  As discussed here -
    http://www.societyofrobots.com/robotforum/index.php?topic=4387.0
I have a strong bias against using any interrupts, mostly based on many years of experience with real-time programming and debugging of distributed minicomputer and microprocessor systems, so I will always look for approaches that avoid interrupts.  Maybe this isn't practical for your application, but there's not enough information to make that assessment.

Hi hgorgon

Thanks for the quick reply, looking at my post, you are right, I did not give enough info! It's the handshaking I am referring to, the serial comms code is no problem, I have all this in my code library. My Master PIC is the main robot processor (although the PC is the main intelligence) and its the handshaking with the 3 (I guess we could call slave) PIC's that are in the comms link. I am leaning on the side of using polling to enable efficient handshaking and comms between the 4 main PIC's. Some of you guy's must have done Multiple processor schemes before, so I was wondering how they did it?

Cheers

Toymaker


Conceptioneering Ltd - Inventors of the Award winning Cube World - Visit: www.radicagames.com/cubeworld/index.php
To see Product Innovation - visit our website at www.conceptioneering.co.uk

[dunk]

hi Toymaker,
have you looked into either I2C, SPI or CAN bus for communicating between microcontrollers?
these are all methods of inter chip communication.
i generally use the i2c bus for this task because i have experience with it but SPI or CAN are also options.

for an example of a microcontroller that can send and receive information via a UART (connected to your EasyRadio module for example) and send it out on an I2C bus to other similar modules have a look at the example module here:
http://www.societyofrobots.com/member_tutorials/node/69

using this method you would need to decide whether modules on the I2C bus are each going to be able to broadcast on the bus (I2C MultiMaster)
or have one I2C Master device poll all the other Slave devices.
if you were going with a single Master on the us it would make sense for it to be the device with the EasyRadio module.


dunk.

[Admin]

I am building an advanced robot which has 9 PIC's, 5 are glue logic (bit controlled), but 4 larger PIC's need to be high speed serial linked. There is a master PIC, a sensor PIC, a drive PIC and an arms/claw controller PIC

Hmmm thats quite a lot of microcontrollers . . . Why so many? And a PIC just for arms and claw? What info is being passed?

It just sounds like its being over complicated and that there is an easier way . . .

[coldkryten]

You are in for many many headaches with a system like that.  I'm currently building a system that has 6 processors, a master, a spare, one each for three motors and a one for power management, all of which communicate over SPI.  The master also has a serial up-link to a PC, so it is relatively similar to what you're describing.  If you can simplify your system do it, debugging something like this is a nightmare, especially if you've never done it before.

As dunk suggested, look at I2C, SPI, depending on what your PIC's have built-in support for.  Serial has high overhead and is slow compared with any of the above, and they all have built-in support for talking to many different devices.  SPI is really ideal for this, and you can communicate at speeds close to the clock rate of the chips if they support it.  I'm using a DMA controller to manage communication in sort of a hybrid between polling and interrupts, but you can't do that on a PIC.

The usual way to organize something like this is in a loop where you: collect data, optionally do some processing or analysis (or send it out over the wireless link,) then send out new commands/instructions.  This will work equally well with serial, SPI, or I2C, but serial will be quite a bit slower.  I'd suggest arranging the master PIC to run a loop similar to this:

{
 Ask Sensor PIC for new data
 Ask Motor PIC for new data (if you have any feedback from the motors)
 Asks Claw PIC for new data (if you have any feedback from the claw)
 Do any processing or evaluation that the Master PIC would do
 Send Data out the RF link
 Get Data/Commands from the RF link
 Send Commands to Motor PIC
 Send Commands to Claw PIC
}

Interrupts will make things much more complicated, but are useful if you need really fast responses to certain things.