[Diy_efi] Traction Control System (update 2)
Brian Dessent
brian at dessent.net
Sat Apr 27 22:09:38 GMT 2002
Crescent Kao wrote:
> Using the LM339, it has 4 input comparators that will transform the ABS
> signal (frequency from each wheel) to a usable square wave. I will then need
> 4 x LM2907 units to convert each channel from a frequency to a usable
> voltage. (the LM2907 has a built in op-amp?) Then I will need an AtoD to
> produce a DC signal from which I can then send via the RS232 using an UART?
The LM2907 is designed to read these siganls directly. Have a look at
the datasheet. If you do this route, you can skip the 339s, but you
would still need A/D. If you want to do that, then look for a serial
output a/d, which you should be able to read directly from the parallel
port. Using the serial port is also possible but will require some more
"glue" hardware. The people that mentioned the LM339 were saying (I
think) that you could count the pulses directly from the parallel port,
without using freq->voltage plus a/d.
Alternatively, along with the 339s you could use a counter circuit in
hardware (such as the CD4020BC or CD4040BC) and then (again with the
parallel port) periodically read the counts and reset them to zero. Or,
don't even bother resetting, just have the software subtract the last
count with the current count, taking account of when it rolls over.
Then, assuming your software knows how often it polls the counters, you
would know the number of pulses/sec. This makes more sense
fundamentally, because that's what you're interested in, the pulse
rate. You could avoid the hassle of converting a digital pulse train to
analog and then back to digital again. Since you have four channels you
would need some muxes and glue logic: for example, have eight data lines
and one select line. THe select line would switch between selecting a
counter (via a mux+latch) or reading data from the selected counter.
Or, use a pic.
> Do I have this correct? I poked around about PIC programming and found a few
> sites pertaining to programming PIC chips. I realize that you must program
> in ASM but I did find a site mentioning that you can program using C/C++ and
> compile it for use on a PIC (which I would prefer). Anyone have information
> on this? Using the PIC route sounds promising, but I'd be lost again as to
> how to incorporate this PIC into the hardware.
There are some C compilers for PICs. If your target is the 16f84a (a
very popular choice) then there are several free C compilers. For other
targets, expect to pay $50 to $5000, depending.
The 16f84a has 13 i/o lines, can run up to 20 MHz, and needs almost zero
external parts count. It's a prettly logical choice for stuff like
this. The reason people have suggested using the parallel port is that
(once you figure out the right way to do it in your operating system)
you basically can read or write all the data and status lines at will.
I think there a total of 12 or 13 usable pins on the parallel port, but
a couple of those may be one-way.
Here are some links.
http://www.htsoft.com/products/piclite/piclite.html
http://www.geocities.com/SiliconValley/Network/3656/c2c/c.html
> Crescent Kao
> Director of Marketing and Sales
> www.c-speedracing.com
(I assume we are not doing free product development for you...)
Brian
_______________________________________________
Diy_efi mailing list
Diy_efi at diy-efi.org
http://www.diy-efi.org/mailman/listinfo/diy_efi
More information about the Diy_efi
mailing list