Thanks for the reply, Alex...
Quote:
|
Originally Posted by Qbranch
The only time i can think of (correct me if i'm wrong) that you would need a co processor is when you are doing vision processing. However, no one need worry since all vision processing is done off site in the CMUcam's Fujitsu processor....
|
Actually, I wouldn't say that at
all. We've found co-processing a
GREAT boon to development.
FYI we did a co-processor PIC at 1502 this season, to monitor and control our shooter's speed. IMHO that was a
great decision. The Shooter PIC and the RC talked to each other via only a few digital I/O lines. The RC gave the PIC the desired shooter speed in RPM. The co-processor monitored the shooter wheel's encoder, ran a PID loop within itself, then told the RC both what command to send to the shooter's motor Victor (and when it was "ready to shoot" via a separate line).
It worked wonderfully! The Shooter code team simply provided a few "shooter call functions" on the RC side to do all the R/W dirty work, and the RC programming team had a very simple to use "smart device" on their hands.
Advantages of co-processing:
- it separated the shooter's software development from the RC, breaking code development up into parallel tracks with separate programmers on separate workstations;
- it
totally unloaded the RC from all "high prio widget timing issues" (eg no interrupt code required on the RC side);
- for the shooter code, it avoided the RC's classic "going mental for significant blocks of time" issue due to interprocessor overhead, that tends to screw up realtime code (both encoder sampling
and PID calculations);
- the PID loop was
extremely fine tunable because it ran in a "clean environment" (no RC code to contend with).
- Using the digital I/O for interprocess communications allowed the RC to determine the data clocking between them, eliminating
all realtime timing issues on the RC side (again avoiding the RC's "going mental" problem).
In the end our final shooter's performance was fantastic. It settled into any new commanded speed within a second! We'll
definitely consider using co-processing again for any future "smart payload devices" a future game may require.
The reason I bring this up is as I've said, up to now we've used
other PIC processors as RC co-processors. Moving to a PIC18F8722 HPC board as a "generic co-processor board"
might make sense to us. Handling
both RC and co-processor programming with a single target MPU (and programming environment) would vastly reduce the amount of new student training we'd have to set up and maintain.
My concern with that plan though is again Errata issues with the 8722 die (especially after you said the HPC boards DO have issues...). If they're too flaky, we may be better off sticking to the PIC PCB we developed for the 2006 season.
So... have you tried using your HPC as a RC co-processor board? If so, have you run into any issues yet? (ESPECIALLY Errata Sheet related issues... After all, that
is this thread...)
Speaking of which... Guys,
please don't hijack this thread with off topic issues like camera model speculations,
unless they interact with "errata" issues. Please start another thread instead. (That's also a cool topic!)
Thanks!
- Keith