Re: Reading serial port lines
From: AlanGLLoyd (alanglloyd_at_aol.com)
Date: 10/11/04
- Next message: Rob Kennedy: "Re: wait for process terminate"
- Previous message: Fabio Dell'Aria: "Re: ANN: Catch every Exception showing Line #"
- In reply to: Phil: "Reading serial port lines"
- Next in thread: Phil: "Re: Reading serial port lines"
- Reply: Phil: "Re: Reading serial port lines"
- Reply: Maarten Wiltink: "Re: Reading serial port lines"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 11 Oct 2004 18:47:26 GMT
In article <Xns957F6D0B32C55pj12345pjpj@216.196.97.142>, Phil
<philj@xxspearnet.net> writes:
>I am writing a simple program to be triggered by an external
>switch.
>The switch will be normally closed and the program watches for the
>switch opening.
>
>The program would sit idly watching for the switch opening and when
>detected, would perform its function, then delay for about 5 to 10
>seconds and resume watching for switch opening again.
>
>It would be very easy to use a joystick port but many computers do
>not have one. Since virtually all computers have an unused serial
>port, it would be much more convenient to use that rather than a
>joystick port.
>
>I have never used a serial port for this, but it seems that it
>should be easily implemented. (But then everything I have no
>knowlege of seems easy...) Perhaps the DSR / DTR lines could
>be used?
>
>Has anyone used a serial port in this manner? How did you do it?
>
Yes - I wanted to use a footswitch with three switches - and I found it a can
of a few worms, but made it work.
Basically you SetComm with a DCB structure to initialise the port and set one
of the protocol pins as a supply voltage for the external switch(es). Then you
open a file on the port (using CreateFile) with a FILE_OVERLAPPED FLAG and
create an event on the file. You then WaitForSingleObject on the event. The
WFSO is given a time and is reset if it expires on time. If it returns with an
event you get the modem status. If this is > 0 you check the modem status for a
flag denoting which pin has changed its status to high. If the ModemStatus is 0
you check the CommEvent to see which Item has changed to low (CommEvent's flag
are high for either a pin going high or going low, ModemStatus is the pin
status itself, high for high and low for low)
BUT ... when an pin event occurs the winport appears to pass a number of
varying (and in error) CommEvents, of which only the last is valid, so one has
to start a timer for each triggered event, and only if another has not come
along for 50 mS (or so) do you take that last event.
I tried using some commercially available components but they all showed this
effect. In the end we used Winsoft's TCommPort and added a lag as above to the
events (we were not using it in a time-critical system).
It all went away when we went to a usb footswitch to be our input. But the
footswitch came with a driver which ended in an MCI interface and worked OK.
If you are not discouraged by now <g> I could dig you out some code, but you
would have to consult MSDN Library to understand or change it - its not for the
fainthearted.
Alan Lloyd
alanglloyd@aol.com
- Next message: Rob Kennedy: "Re: wait for process terminate"
- Previous message: Fabio Dell'Aria: "Re: ANN: Catch every Exception showing Line #"
- In reply to: Phil: "Reading serial port lines"
- Next in thread: Phil: "Re: Reading serial port lines"
- Reply: Phil: "Re: Reading serial port lines"
- Reply: Maarten Wiltink: "Re: Reading serial port lines"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
