> >Questions you need to answer:
> >1.  Do you want to be able to vary the sampling rate?
> 
> No. I didn't even think this was possible without reprogramming. Will
> definitely consider it as a possible upgrade, but initially I just want
> fixed (but not necessarily equal) sampling rates.

Not only possible, but fairly easy, depending on how you do the
sampling.  If, for example, you do a timer based interrupt with
samples captured at each interrupt, the sampling rate can vary between
as slow as you can make the PIC go (which can be quite slow- many
seconds, if you use an RTC) to as fast as the PIC can sample.

> Project 1:
> 4 channels, all sampling at 250-300Hz, dump the data through serial onto a
> PC, which records the values in a timestamped fashion so they can be
> synchronized with other eventual peripherals (eg video). I already have the
> analog amp side set up and working.

Okay, if you have the analog amp set up, that's probably the harder
part.  Now you need to figure out if we can transfer the data fast
enough.  I'll assume we can do it with an 8-bit ADC; 10-bit
complicates matters somewhat because you either need to pack the data
or send two bytes to send across each 10-bit data point.  Neither is a
great option.  At any rate, each byte requires 2 bits of overhead
(start and stop), plus parity and handshaking, but we'll ignore parity
and handshaking and just look at a stream of data.

So, saying 8-bit, 250 Hz, 4 channels, plus a (arbitrary) 16-bit
timestamp once per second means a total of (10*250*4)+20 bits per
second, or just a hair more than 10 kbps.  No problem; an 18F452 can
pull out 19.2 kbps with a 16 MHz oscillator and only .16% error (see
the datasheet).  That even leaves room for parity and handshaking, if
you so desire it.

250 Hz means 4 ms per sample, or 1 ms per channel.  Again, the data
sheet tells us that, for a reasonable system, we should be able to
take a sample less than 13 us after switching channels on the ADC. 
So, no problem meeting our 1 ms per channel deadline, either.

> Project 2:
> Easily 10 channels, initially A/D and maybe timers to count pulses for tach
> (I'm following the other thread on this). Eventually, add more A/D channels,
> a couple of D/A, some PWM stuff. All data is stored on an onboard PC
> (including, eventually, video). Thus, also has to be kept timestamped for
> eventual synch. Using multiple PICs to delegate is probable.

See above about sampling rate, etc. ;-).  You'll run into more trouble
with multiple PICs all vying for a communications bus, and you'll
certainly have loads of fun working in the dirty, hot, crowded,
electrically noisy environment of an automobile, but it is doable.

> Project 1 needs as constant feed as possible, for project 2 a refresh rate
> (of data to the PC) of ~20-50Hz would be sufficient (if displayed, they eye
> wouldn't see the data 'frames').

Human eye refresh rate is ~ 50 Hz.  Bear in mind that a user probably
wants to know approximately what the RPMs of the engine are now, plus
or minus a few tenths of a second, not EXACTLY, since trying to figure
out what the average of the hundreds of values flashing past are takes
up valuable CPU time that could better be spent dodging pedestrians
and fast moving SUVs.

> >5.  What are you going to "catch" this data with on the PC?

> I'm considering dumping the data through serial. A program would catch the
> data and either make a table (which can be looked up by the display
> software), or write it to disk and make it available on a socket for a
> "front end" to plug into. Obviously, I'm still unsure of the limitations and
> advantages of either method, but just getting data showing up on the PC
> serial port would make me happy, and is all I'm trying to do at the moment.

A laudable goal.  For myself I'll tell you that I've had infinitely
more luck getting data into a PC under Linux using C++ than I have in
Windows using VB.net.  But that's all I can comment upon there; I
usually just use HyperTerm for the little things I need to do.

> My knowledge is still limited, but for the moment I'm thinking of doing
> something like this:
> 
> Start
> Poll ch1
> Write data
> Poll ch2
> write data
> ....
> Send all data
> Reset WDT.
> Go back to start.
> 
> But I could have variable sampling rate by simple propotions, eg sample
> 1,2,3,1,2,1,2,1,2,3.... (sampling ch3 at 1/4Hz of ch1)
> 
> And I was thinking that if the A/D conversion is slow enough relative to a
> ~10-16 bit serial transfer, I could: start ch2; transmit data from ch1,
> record ch2, start ch3, transmit ch2, etc.
> 
> The questions I'm trying to answer is how the PC knows from which channel is
> a particular data packet from, and wheter the time stamp should just be left
> to the PC to do as each packet comes in rather than trying to synchronize
> multiple RTCs....

That is the question, isn't it?  A possible solution would be to have
all the PICs monitor the serial line, and then only send when it's
their own turn.  I'm sure there are others and I've honestly never had
to deal with that...perhaps someone else has a brainstorm?

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