Poor mans "semi" logic analyzer

Gday all
I am mucking around investigating possible problems with a PWM motor drive system ( 12V ) that is controlled by an OEM PIC in a piece of equipment ( telescope drive ).
I want to be able to log the pulse data on both motor supply lines, such that i can read it out to a PC and then investigate the waveforms ( similar to a digital storage CRO ).
The PWM for the motors is 20KHz, thus i will be gettting an approx 50uS period with changing duty cycle as speed changes.
I need to log up to 30secs of continuous data, on both channels simultaneously, at the best sample rate i can get.
I've been going through this now and have myself totally confused.
I will have to write data out to an external EEPROM and that will take time on each write.
As i cant multithread in the PIC, what are the best options available to me, to ensure i can get the minimum constant sample rate over that time span, and dont end up with holes when i have to write data.
Andrew

I would carefully rethink what you're trying to do and why. This could end up costing you many times the value of your telescope.

Do you really want to digitise 30 seconds worth of 20kHz PWM signal (and to what resolution?)... and when you've got it, the BIG question is what value will it be to you? All you'll see is your motors start, speed up, slow down and stop. No big deal, you can see that happen already by watching the telescope move.

Let's say you're going to Digitise it to a pretty useless 2-bits of information over 30 seconds... let's do the math...

2 bits is actually 4 samples per 50uS PWM perid. One sample every 12.5uS... that's one full byte of data every 100uS, or 300kb of data over 30 seconds - 600kb for your two channels.

Now a PIC can grab that - no problem there, but disposing of 16 bits every 100uS is another story... 600kB of fast RAM? perhaps. DSPIC? perhaps... $1500 or more in parts, design and development time... almost certainly - and that's to gain almost no actual useful information that you can't already guess.

If you must throw money at studying motors spinning up and running down (I suppose it's the mech-techie version of watching paint dry), then an off-the-shelf data-logging card for yor PC is perhaps a better (and cheaper) way to go...

Gday Mel
Thks for the reply.
I figured it was going to hurt ( trying to save the data ) but, as i already have PICs i had to try.

"the BIG question is what value will it be to you? All you'll see is your motors start, speed up, slow down and stop. No big deal,

I'd luv to see that.

"you can see that happen already by watching the telescope move."

The problem cannot be visualised by watching the telescope move
as it is moving at siderial speed when the problem occurs ( Ie slower than drying paint )
The problem is based on Nth vs Sth hemispheres rotating the wrong way, and all sorts of esoteric corrections being made to take up mechanical slop, whenever the scope changes direction, or receives a "move" request.
The PIC that drives the motors controls direction ( hemisphere specific ) and also has "backlash" compensation as well as "training compensation". These all have to be applied in the correct order/sign for it to work.
I have put a std CRO on the motors, but it all happens too quick to see.
As such i need the traces so i can study the "relative" speed and direction changes. From this i can tell if they are applying the relevant changes using the correct directions and signs.

"(I suppose it's the mech-techie version of watching paint dry)"
A truly noble pasttime, especially with a beer in hand.

Andrew

Off to look for a dedicated datalogger

"(I suppose it's the mech-techie version of watching paint dry)"
A truly noble pasttime, especially with a beer in hand.

plus...

moving at siderial speed when the problem occurs ( Ie slower than drying paint )

equals...

This is a job for at least a couple of crates of beer then (tax deductable).