>It will be on the car, mostly in the engine compartment
>(electrical noise and mass issues)

Electrical noise, yes, Mass - why would that be a problem?, I would have
thought temperature would be the other major problem.

>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

Well that lot would look ideal for a dsPic to me - especially as they seem
to have a family of them with this style of problem in mind.

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

I would have thought that a single dsPic could handle this lot with ease,
considering that many ECU units seem to use considerably less capable
micros. Use an I2C or SPI EEPROM for the logging, and have the log block
size the same size as the block size of the chip means that it would write
as fast as you could feed a block, then wait for the next block. Alternative
here would be FRAM which doesn't have the block or write time constraints.
Almost all the dsPics have CAN IIRC (some have 2 CAN ports) and with the DSP
core any of the calculations should be easy. IIRC there is a quadrature
encoder handler as well - it becomes a case of spending 2-3 hours at most
sorting through the dsPic options between the families, but I do get the
impression that one of the motor family would handle your requirements. And
with the PLL giving high internal clock speeds I doubt you would run out of
computing power.

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