Re: Contolling Serial Port

Charington_at_att.net
Date: 02/27/04 

Date: Fri, 27 Feb 2004 22:17:04 GMT

Hi Chris
Thanks for your comments..
The other device is configured to look at it's DSR, but it's a long
story... depending on what it's doing, it takes some time to actually
stop sending ... Sometimes it's busy but doesn't have anything to
send to me and everything is ok... Other times it's busy and it also
has stuff to send to me.... it sometimes sends more data than I would
like to have coming in... that's why I thought if I could have my
serial port buffer the data, it would give me a little more control of
the process....
I had not thought about raising the Threshold..... If I made it as
big as the receive buffer itself, it would stop giving me OnComm
events....(at least till the buffer filled!) Then if I reset the
Threshold to the normal amount, will the OnComm events come uniil I do
enough reads to get below the threshold????

Thanks for your thoughts....
John

On Fri, 27 Feb 2004 16:10:18 -0500, "Chris Kusmierz"
<cakusmierz(at)adelphia(dot)net> wrote:

>Comments InLine
>
><Charington@att.net> wrote in message
>news:403f8e48.9081999@news.usenetserver.com...
>> Hi All
>>
>> I have an application that deals with the Serial ports, and reads a
>> string of about 72 ascii characters.
>> (Thanks to Richard Grier for info on how to do that)
>>
>> I have now a situation where I am dropping DTR to the sender, but it's
>> taking them a long time to stop sending (it's not another PC..) and I
>> want to make sure that after I drop DTR and wait awhile that I don't
>> get interrupted by data still coming in. (Insurance)
>>
>
>Are you able to configure the other device?
>The other device may have to have handshaking enable in order to properly
>use the DTR.
>
>
>> Is there a way to tell my serial port to keep buffering the input,
>> till I want the data again.
>>
>> I've been using the OnComm event:
>>
>> Case comEvReceive ' Received RThreshold # of chars.
>> InBuff$ = MSComm1.Input
>> Call ParseChars(ByVal InBuff)
>>
>>
>> Is it sufficient just to stop doing the read (MSComm1.Input)?
>>
>
>For the most part yes, you could also then change the RThreshold to higher
>number to stop the comEvRecieve event from firing.
>
>
>> What about when I want to start reading the port again... I assume
>> that unless data is coming in, I won't get any OnComm events......
>>
>> I'm concerned that even though I raise DTR, there may not be data sent
>> which might lead to data being stuck in the input buffer.....
>>
>> Should I somehow loop separatly .. doing the InBuff$ = MSComm1.Input
>> until I don't get anything? or is there somthing that I can read that
>> would tell me how many characters are in the input buffer?
>>
>> What's the "right" way to handle this...
>> Thanks
>> John
>>
>
>
>The *right* way is whatever you decide works.
>
>
>My 2 Cents.
>
>Chris
>
>

Loading