Well, one good example is the Digital I/O. Lets say you have some extra sensors attached to the eduBot RC, the Gyro for example. For those who havent, check out StangPS, the auto system that Wildstang developed. You can see their explanation here:
http://www2.wildstang.org/2003/video/StangPS/
Lets say your Main RC, or MRC, as I'll say, is connected by it's last 2 digital i/o pins, 15 + 16, to the eduRC, or ERC. I'm just giving this as a rough example, not a hard fact of how to do it all. The MRC gets the signal from the competition controller that the user mode has been turned to Auto mode. It's auto program is to do the following:
-Ping the ERC
-Receive a small array of Data from the eduRC
-Output that Data to the PWM outputs.
-Loop until Auto mode is turned off
Lets look at Step 1.
Ping the ERC:
The MRC sends out a "1" or on signal through both its Digital pins. The ERC, while calculating, treats this form of signal as a signal to send the data.
Send the Data:
The ERC Stops what it's doing, and sends data out to the MRC. It could probably send in binary form. If pin 15 is activated, it represents a "1", and pin 16 represents a "0". At the same time, the MRC is receving the data and assigning it to a chunk of memory. When the ERC is done, it will send an on signal through both pins. This Would represent an "EOF" of some sorts, because it would be impossible to have both 0 and 1 at the same time in a binary "string".
Sort and Output data:
The MRC would check back to that memory location, convert the "string" to integers, assign them to individal values, and output them the the PWMs.
Why would you do this?
Well, there are several reasons. First off, you would have a clean slate using the ERC's memory to hold all of your Auto Mode data. This would free up lots of room on the MRC for whatever you need. Also, the ERC would be doing the sensor input and calculations for auto mode, and the MRC would only be outputting that data. That leaves more room for program space on the MRC as well. The ERC would be treated as it's own auto mode device. This can clear things up sometimes when your defining parts of your robot. All your auto sensors branch to the ERC, and can continue to be read during user mode.
Also, for speed. By the time the MRC put the string in memory into variables, and outputs it to the PWM's, the ERC has calculated the next batch of data, and can send it. If you only used the MRC, you'd have to calculate, then send, but you could do both at once with connecting the two controllers.
My example isn't perfect. In reality, you would probably need 3 pins for it to work correctly. Why?
If your program loops are not exactly synced, this is what happens:
SENDS ERC:1
RECEIVES MRC:1
RECEIVES MRC:1
SENDS ERC: 0
RECEIVES MRC:0
So thus:
The ERC tried to send this data:
10
but the MRC got this:
110
Why did the MRC get an extra 1? Because it looped it input routine around 2 times before the ERC had the next bit ready.
A way to get around this would use 3 pins.
One that Represents a 1, one that represents a 0, and one that acts as a go-between, or I'll call it the "GB" bit.
When the ERC receives the "All Go" signal from MRC, it pings back one "All go signal", and if it gets another back, it begins sending data.
First, it activates it's GB pin. This tells the MRC to wait for the next value before it adds anything more to the string.
Then it begins sending the data as normal, with a GB signal in between each bit value. At the end, it pings back an all go signal. The mrc pings one back if it received everything fine, and the ERC trots on its merry little way.
This way, even though it might be a tad slower, it is absolutely stable data that you are receiving.
Anyway, I'll post more on this later, but I'm glad someone brought it up.