K.I.S.S.

If you want dead simple/cheap, you can connect 12 reed switches to 
ECP/EPP parallel port input pins (D0-7, ack, bsy, PE, SLCT) and
poll the heck out of them with the PC.

You could also use an SPP with cascaded data multiplexer
(74HC4051's) to get out to 256 sensors
and read back the reed switches using the 4 inputs available
on the standard parallel port, 4 at a time, as long as the
closure time is longer than your poll time (or throw caps
across the switches with high value pullups to create a R/C pulse
stretcher). Just remember to add series Rs & clamp diodes to the 4051
inputs to protect them from static.

Cheapest PIC solution: low end PIC bit banging serial I/O on
open collector RS232 line. Get power off RTS & DTR
since the spec says they can supply UP TO 30 mA (but a
lot of laptops cannot). Have a separate USB dongle for
those computers that do not have a serial port, and just
add a 9V battery/wall wart to power the PICs from the cable.

You can get away with higher baud rates by using a lower
pulldown value. I am using 3.3k and get 19.2k baud off an
emitter follower opto over 10 meters of cable. (opto
pulls against DTR).

Use pulldown instead of pullup since you want the line to
IDLE between characters sent by the various PICS.
RS232 idle is -12V, Mark is +12V, but anything outside
the +/- 3V band is considered 'valid' so pulling to ground
is OK. Use a common transmit line to all PICS, to poll
them, and each one responds in turn after it is addressed.

I wouldn't even bother with RS232 tranceivers on the PIC side.
2-3 74HC14 gates in parallel, with a diode and series 100R
for protection is good enough to
drive hundreds of feet of cable (as I have). One gate of the
74HC14 is used as a receiver with a series 1K resistor, 100k
pulldown and clamp diodes to rails.

You poll the devices by simply sending a byte from 0 to $FF
and they respond with a few bytes containing the number of
revs seen in the previous timing interval(s). You CANNOT trust
windows to pass you serial data in a timely manner so the
timing window MUST be done by the PIC and the returned packet
must include a PIC ID.

Lots of ways to skin this cat.
Given the likely environment, shielded microphone cable out
to the reed switches and PC with ECP port would do.

Robert

liam . wrote:
> All,
> 
> I was tending toward the PC based processing because my background is
> more in the computer programming area already so this is good news. As
> far as I know so far there is no need for any local infomation display
> at the bike and why cant the rider just look at the computer screen.
> 
> Its interesting the mention of multiple PIC's on a single RS232 port.
> I was actually thinking along the lines of a serial to usb dongle per
> bike and a USB hub, then the bikes could also be plugged into a
> computer on an individual basis.
> 
> I would like to go down the path of USB but am concerned about the
> costs involved in a programmer and software, what do other people use?
> My current PIC compiler would not cope with 18F as far as i know but I
> will check. What programmers would be recommended if I need to buy
> another?
> 
> I'll try and get myself a copy of USB Complete
> 
> Would adding an FTDI Style Serial to USB converter chip into the
> hardware be a better approach than terminating to serial and leaving
> the Seial to USB open ended which would enable use on computers which
> actually do have serial? (Keeping costs low except when no serial is
> avaliable and then an add on expansion)
> 
> 
> Thanks,
> 
> 
> Liam
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist