>>>>>>>I am facing problems writing "Serial Communication" routines under Windows.I am trying these routines since last few months and with my experience, I have come accross foll Conclusions/problems
>>>>>>>
>>>>>>
>>>>>>Narendra
>>>>>>
>>>>>>The market seems to definitely be moving towards Windows & away from DOS. Going to DOS will find you in a shrinking market.
>>>>>>
>>>>>>There are COMM utilities out the like SilverFox from SilverWare and others that will support the 16 bit environment. Plus eliminate a tedious learning curve. Look in the trade magazines for such products.
>>>>>>
>>>>>>Tom
>>>>>
>>>>>Thanks Tom but my problem is different. I have to write the
>>>>>routines bcz I am reading data from the device which has its own
>>>>>protocol & handshking that too very fast.I have to respond to
>>>>>each char received on port, (For example device first send ENQ
>>>>>then I reply with ACK, then it sends block of 4 chars, then i
>>>>>respond, then it sends header etc...). In this case I need a
>>>>>utility/OCX which is so fast & powerful that it generates
>>>>>interrupt as soon as char arrives at port.
>>>>>
>>>>>I tried MSCOMM16.OCX with VB4.0, it just does not work for me.and I don't think any utility can do this, bcz being a multitasking env,
>>>>>Windows does not give highest priority to COM port (ie a char
>>>>>just arrived at port & windows starts swaping between HDD & RAM,
>>>>>you can't do anything at this time). Its OK if
>>>>>you want to upload/download a large file in which case time is
>>>>>not that much critical.
>>>>>If you have come across any utility which is 100% perfect for
>>>>>these type of application,please reply soon.
>>>>
>>>>Narendra
>>>>
>>>>The only way to handle this is with a clever buffering scheme. Some products (the more effective) actually use a 3 part buffering scheme; The UART buffer, a low level buffer & a user buffer. You should be able to get away with 2 at the most; the UART buffer & maybe a low level buffer. Just watch the size of your buffers. Don't try to read each char from the port but read it from the buffers.
>>>>
>>>>HTH,
>>>>Tom
>>>
>>>Ya Tom,I have tried with buffering(size ranging from 10 bytes
>>>to 30000), but in some cases, if I don't read char by char & give reply in time to the device, it generates an error & starts negative response. In this case I face more trouble. To give u an example say device sends ENQ & then waits for some
>>>time (say few milisecs), now during this if I don't give answer
>>>It again sends ENQ, so now if I read from buffer one char & reply the second char is also ENQ, where as for me after I send a reply it should be STX). Also I have to perform Check sums etc on the data.
>>
>>Narendra
>>
>>Whoops! Anyway...
>>
>>Maybe you should read the buffer in a LIFO manner? Just a suggestion.
>>
>>Tom
>
>Hi Narendra,
>We communicate with some systems that are like yours. Two methods we use are: 1. Handle all control characters in the control's OnComm event, pass data to higher level handler. 2. Check and see if the device responds to DC1 /DC3 or other x-on / x-off signals, so that you can exercise some control over it, if possible.
>HTH

Yes,I do the same thing. But I have faced foll situation.
Say in my control I have Rthreshold (Receive threshold) =1, so control should trigger OnComm event as soon as a character arrive. But when I read input with Control.Input property I get more then one character.
This is because MSCOMM does make sure that it does not lose any character, but in my case its a problem.

Narendra