Using PC HW (& Ignition timing reference points)

Chuck Tomlinson tomlinsc at ix.netcom.com
Tue Oct 8 17:22:47 GMT 1996


> From: tom cloud <cloud at peaches.ph.utexas.edu>
> 
> Am I mistaken, or do many of the posts here seem to want to make the cpu
> do everything?  Take an A/D and read a noisy signal and let the software
> filter it (when a simple integrating lo-pass filter would save so much
> trouble -- and add, maybe, 32 cents to the cost).  Or, try to do all
> the ignition timing via internal counters/timers and interrupts, when
> maybe a little PLL in the front end could process some of that and make
> the cpu / software task lots simpler.

I agree in principle, but extra processor work is not a problem if your
processor has power to spare.  Also, software filters (and other signal 
processors) are adjustable on the fly.  That saves a ton of time and 
effort, since you only need to write a filter routine once (if you 
don't just copy it from somewhere else).

In our PC-based development controllers, we use software processing 
for any signal that *might* need to be tweaked.  As a result, we 
build exactly one set of hardware, and do the fine-tuning in software. 

Our PC processors are so fast that we can simultaneously run the 
algorithm, process signals, log megabytes'o'data, and run a graphical 
user interface.  All this in addition to being able to post-process 
the logged data and run the development environment.

For the anti-PC folks: if you already know exactly what your 
algorithm and parameters are going to be, a PC may be the wrong 
platform.  But for maximum development flexibility and fastest 
progress, *nothing* can beat a PC for anywhere near the money.

I have experience with PCs and 68332s.  When I build my "release" 
PCM, it will almost certainly be based on a 6833x or the like.  
But I will just as certainly do the bulk of my development 
with a PC.  To each their own :-)

--
Chuck Tomlinson <tomlinsc at ix.netcom.com>



More information about the Diy_efi mailing list