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