FRC hardware design

[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.