InstallComCallback resets port settings

[gtoph]

I have an issue with InstallComCallback and would like to see if it is behaving as expected.  Basically, we're not using hardware handshaking and rather using those lines to control other things by using the comsetescape function.  For example, first I clear the RTS signal to start a sequence on our device and then use the InstallComCallback function to wait for data on the port.  The problem I ran into is that InstallComCallback more or less resets the port.... it sets/clears RTS and DTR, sets the baud, and various other things that have already been done in com open call.  Concequently, our device never sees the RTS clear as the callback function changes the state.

For a workaround, I've simply moved the install function before the clearing of the RTS line, but I would rather not do it in this order.

Is it really necessary for InstallComCallback to reset the ports settings?  Can it not just set the mask or specifically what it needs and leave everything else alone?

Thanks.

[Mert_A.]

Presumably you're registering a callback for the RXFLAG event (to respond to the arrival of a specific character). The issue is tied to the underlying Windows API. In order to get Windows to notify the arrival of an event character, we have to call SetCommState Win API function which sets a whole slew of port options (refer to the DCB structure, and the EvtChar member). Despite the fact that we initialize the structure with all the current port settings, it still apprently effects some changes. If you are not enabling the RXFLAG event, then SetCommState does not need to be called; calling SetCommMask is sufficient.

So unfortunately, no, InstallComCallback cannot just set the mask or specifically what it needs and leave everything else alone, because one of the things it needs to change is bundled up with a bunch of other settings in the DCB structure.

Hope this helps.

Mert A.
National Instruments

[gtoph]

Well that explains it, I am indeed using RXFLAG. 

Without really diving into the API documentation, it appears that the 'fRTSControl' member is the initial state of the RTS line?  If so, Is this one the fields that you pre-fill before calling the API?

[Mert_A.]

InstallComCallback calls GetCommState to initialize the DCB with current settings, changes EvtChar, then passes the DCB right into SetCommState. My guess would be that EscapeCommFunction (which is used by CVI's ComSetEscape) changes the state of the control lines without updating the port state that is returned by GetCommState. This actually makes sense, because fRtsControl (and fDtrControl) does not indicate the line state; according to the documentation, it is a flag indicating the kind of flow control associated with the line. I think the real issue is that calling SetCommState has the side effect of reinitializing the states of the control lines, even if the flow control settings have not changed.

Mert A.
National Instruments