[Joe Johnson]

I used a stamp2 as my "coprocessor" this year.

It worked out ok but there were difficulties.

The main thing had to do with the Programming port from the Stamp2 on the RC echoing back any character that I sent it.

This was a MAJOR pain in the rear.

The only way I could get it to work was to use the programming port as my RC -> CO-Processor path and to use the digital input port on the RC as my CO-Processor -> RC path.

Once I figured this out, I still was not out of the woods because I discovered that in the worst case conditions there is a 3 data packet delay from the data being put onto the digital input port and the Master CPU on the RC passing the data to the Stamp2 on the RC.

I spoke to Innovation First folks about this a bit and they were not very helpful to be honest.

In any case, here is the scheme that I developed that worked for me.

#1
I would send out a data request or other command (for example, zero all counters or give me CG position data) by asking for one of 16 "addresses" via the programming port of the RC stamp2.

#2
4 pins of the digital input port were then devoted to the address of the data that was put on the port (this limited me to 12 bits of data per transfer, but it was a reliable handshake method).

#3
The RC Stamp2 would only request a new address after the address it got back from the digital input port matched the address it had requested.

This worked pretty well.

Note that the coprocessor Stamp2 had some counter circuits and a latch/shift register in order to do the fast work of keeping track of wheel positions (a Stamp2 is not really capable of keeping track of left and right wheel positions at the same time yet alone communicate with another Stamp2 via serial data while doing it -- the counters did all the time critical work and the Stamp2 just read the counters at its leisure).

I hope that Innovation First comes up with a better system next year, but if they don't, I would use the system we had this year again without hesistation.

Joe J.

P.S. The only thing I would do is improve some of my routines on the co-processor Stamp2 to do more stuff. I had plans to have the co-processor keep track of CG velocity (direction and speed) and to compute a "virtual Yaw Rate sensor" as well as a few other things but never got around to it. In the end, all I needed from the co-processor was distance the CG moved since reset and angular orientation relative to orientation at reset. Not too sexy but enough to get to the stack in sub 3 second times.