I usually break it up into several PICs. The main PIC for Master 
communications
and executive functions. Then each motor would control each main task, 
communicated
to by RS232 serial or a proprietary scheme. A Master with two uarts is 
helpful, and
one with a deep PGM array to allow a floating point math unit and 
conversions.

The problem with a huge ARM (or whatever) is that no matter what is 
processed, only
ONE task happens at a time. With multiple PICs, an AWESOME amount of
processing can be done simultaneously, such as positioning 3 different 
motors. Even
if an ARM can run at 80Mhz, it  will be outprocessed by  3 peripheral 
16F88s  at 20Mhz
and an 18F at 40Mhz.

The secondary PICs are extremely  helpful controlling stepper motors  or 
DC motors with
quad tach positioning sensors, or controlling 12-bit D/A outputs. Each 
secondary PIC
controls one motor or one DAC. Since each PIC has a unique communication 
address
and shares a serial bus, there is no confusion. I'd use clone ICD2's to 
handle the F88's,
and an MC ICD2 for the main processor.

--Bob

 

Denny Esterline wrote:

>I've done more than a couple PIC projects but this one's upped the ante and
>I'm trying to decide if I should throw a whole handful of PICs at it or
>should I move on to something else. I think your considered opinions might
>be some use here so...
>
>This is a testbed application for a local engineering college to study some
>aspect of vehicle dynamics, I'm under NDA for most of the details, but
>here's the broad strokes:
>It will be on the car, mostly in the engine compartment (electrical noise
>and mass issues)
>Primary task is to run a PID loop between a linear encoder and a brushless
>motor ~10mS update rate
>Monitor several sensors and perform an unspecified (complicated, possibly
>floating point) algorithm to control the position of the motor
>Sensors include at least one remote node (probably CAN), 3x ADC, 2x timers
>and an accelerometer (probably an Analog ADXL...)
>Filter and log the data (~40 bytes @ 20Hz for minimum 10 minutes)
>Allow non-electronics types to retrieve the data and modify the algorithm in
>the field (I'm thinking USB or SD memory card)
>
>Now I've done most of this before with PICs, but never all at the same time.
>I'm thinking that I could segment the project and have a separate PIC manage
>each task. Something like a PIC18FXX31 with it's quadrature encoder and
>motor control hardware could easily handle the servo, another PIC to monitor
>the sensors, one more to process the algorithm. Put them all on some type of
>bus and add another to just sniff the bus and log the relevant data.
>
>Sure, it's a plan - but is it a good plan?
>
>There's obviously other options, even in the MChip family, a DSPIC or one of
>the new PIC24s. Or I could just move on to something else ARM7, ARM9,
>Freescale 56F8xxx, FPGA with soft core(s), PC104 SBC, etc, etc.
>
>Thoughts?
>
>-Denny
>
>  
>


-- 
Note: To protect our network,
attachments must be sent to
attach@engineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist