FRC hardware design

[Alan Anderson]

I'm not sure you have a good grasp of the "hardware software model", as you call it. You're asking questions that seem to assume things are not as they are. The IFI Robot Controller system is set up as a main processor with a coprocessor. The software isn't running a "dual thread" scheme with interrupts to switch between tasks; the fast user loop is the "main loop".

The system is set up with an amazingly useful feature: hardware inputs are automagically read and made available to the program as variables, and hardware outputs are automagically generated based on variables set by the program. The minor nuisance of having to call the get_data and send_data communication routines explicitly is worth it.

One thing you're leaving out is the cost of the system. Adding "just one more small PIC" for PWM outputs, and "just one more small PIC" for modem communication, and "just one more small PIC" for a motor drive system...it adds up.

[Gdeaver]

I'm suggesting that having 2 pic 18's and the interrupt for them to talk adds complications. Having 1 pic 18 and a pic 16or two on an expandable async bus would be less complex. The main processor would have a senddata getdata function and a set-pwm function. Off loading the PWM from the pic 18's would eliminate the critical timing that is needed in the current controller. As for cost, aren't pic 18's to pic16's about 1 to 3. I would rather send a couple high level commands to a intelligent motor coproc than have to fit the pid in the current FRC and worry about conflicts with a gyro, accelerometer, other time critical sensing.

[Alan Anderson]

Originally Posted by Gdeaver

...Off loading the PWM from the pic 18's would eliminate the critical timing that is needed in the current controller...

That is taken care of in the non-user-programmable PIC. It doesn't matter whether or not the timing is critical; it is neither exposed to nor under the control of the programming we are allowed to do.

(The four PWMs which are optionally controllable by the user processor would still have to be that way in order to permit the kind of immediate control possible under the existing scheme.)

[Alan Anderson]

Originally Posted by Gdeaver

I'm suggesting that having 2 pic 18's and the interrupt for them to talk adds complications. Having 1 pic 18 and a pic 16or two on an expandable async bus would be less complex...

I'm obviously not seeing what you are. How can having more processors and a more complicated communication bus end up being less complex? Even if the additional hardware is somehow easier, how can communicating between the user processor and multiple I/O processors be any simpler than communicating between the user processor and a single I/O processor?

I don't wish to sound like I'm trashing your ideas, but I honestly don't understand how they would make things any easier than they are now.