471,338 Members | 1,022 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,338 software developers and data experts.

DCB Setup disagreeing with SetCommState

Hello,
I am having a problem configuring a certain port on my computer. I
want to loop through a list of active ports and listen to the one that
is giving me the data packets I need.
Right now it loops through the ports just fine but upon trying to
configure the ports with //./COMx configuration, SetCommState believes
that a port is valid even if it's not and then the program freezes at
ReadFile.
My port configuration is as follows:
BOOL updateConnection( HANDLE hndl )
{
time_t TimeSec = 0;

DCB dcb = {0};

dcb.DCBlength = sizeof(dcb);

dcb.BaudRate = 230400; // BAUDRATE(TTYInfo);
dcb.fOutxCtsFlow = FALSE;
dcb.fOutxDsrFlow = FALSE;
dcb.fDtrControl = DTR_CONTROL_DISABLE;
dcb.fDsrSensitivity = FALSE;
dcb.fOutX = FALSE;
dcb.fInX = FALSE;
dcb.fErrorChar = FALSE;
dcb.fNull = FALSE;
dcb.fRtsControl = RTS_CONTROL_DISABLE;
dcb.fAbortOnError = FALSE;
dcb.wReserved = 0;
dcb.XonLim = 1;
dcb.XoffLim = 256;

dcb.ByteSize = 8;
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT; // STOPBITS(TTYInfo);
dcb.EvtChar = EV_RXCHAR;
dcb.fParity = FALSE;
dcb.EofChar = '\n';

if (!SetCommState( hndl, &dcb)) //This does not fail where
expected
{
return FALSE;
}

getAllRs232( 0 );
return goodMSG;

}
BOOL listenOnActivePort(int nBus)
{
.... //Declarations
....//Loop to cycle through active ports
{
....//Try port without "\\.\" COM configuration

strcpy(&tempString,"\\\\.\\");
strcat(&tempString,activecomports[port]);
strcpy(activecomports[port],&tempString);
(HANDLE)fd[nBus] = CreateFile(activecomports[port], GENERIC_READ, 0,
0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0 );
if( updateConnection( (HANDLE)fd[nBus] ) == 1)
{
return TRUE;
}
}

The first step of getAllRs232 is to determine the number of bytes in
the packet being sent, by calling:

ReadFile( (HANDLE)fd, (LPVOID)buf, (DWORD)bufSiz,
(LPDWORD)&nBytesRead, NULL );

This is where my program hangs up. I want it to cycle through the
ports and ultimately (on this specific computer) listen to port
configuration \\.\COM31, however it hangs up on the readfile on the
first instance (\\.\COM12). Is there a reason why SetCommState is not
returning an error for my specific configuration? There should not be
any data coming off any port now except COM31 or COM32.
Thank you very much in advance for any help!

Jul 2 '07 #1
2 3000
Sorry I don't think I can help with your problem, but please can you tell me
something.
(HANDLE)fd[nBus] = CreateFile(activecomports[port], GENERIC_READ, 0,
0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0 );
What compiler are you using?

Well, OK, maybe I might be able to help. I don't really want to know what
your compiler is doing, I just want to know what compiler it is ^_^ But
depending on what your compiler is doing, that might affect your results.

What is the value of fd[nBus] (without a cast) before that assignment, and
then again after that assignment? Does the compiler really generate code to
coerce a HANDLE to whatever type fd[nBus] has? And then it really assigns
to fd[nBus] and not assign to a temporary variable somewhere?
<ku****@gmail.comwrote in message
news:11**********************@d30g2000prg.googlegr oups.com...
Hello,
I am having a problem configuring a certain port on my computer. I
want to loop through a list of active ports and listen to the one that
is giving me the data packets I need.
Right now it loops through the ports just fine but upon trying to
configure the ports with //./COMx configuration, SetCommState believes
that a port is valid even if it's not and then the program freezes at
ReadFile.
My port configuration is as follows:
BOOL updateConnection( HANDLE hndl )
{
time_t TimeSec = 0;

DCB dcb = {0};

dcb.DCBlength = sizeof(dcb);

dcb.BaudRate = 230400; // BAUDRATE(TTYInfo);
dcb.fOutxCtsFlow = FALSE;
dcb.fOutxDsrFlow = FALSE;
dcb.fDtrControl = DTR_CONTROL_DISABLE;
dcb.fDsrSensitivity = FALSE;
dcb.fOutX = FALSE;
dcb.fInX = FALSE;
dcb.fErrorChar = FALSE;
dcb.fNull = FALSE;
dcb.fRtsControl = RTS_CONTROL_DISABLE;
dcb.fAbortOnError = FALSE;
dcb.wReserved = 0;
dcb.XonLim = 1;
dcb.XoffLim = 256;

dcb.ByteSize = 8;
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT; // STOPBITS(TTYInfo);
dcb.EvtChar = EV_RXCHAR;
dcb.fParity = FALSE;
dcb.EofChar = '\n';

if (!SetCommState( hndl, &dcb)) //This does not fail where
expected
{
return FALSE;
}

getAllRs232( 0 );
return goodMSG;

}
BOOL listenOnActivePort(int nBus)
{
... //Declarations
...//Loop to cycle through active ports
{
...//Try port without "\\.\" COM configuration

strcpy(&tempString,"\\\\.\\");
strcat(&tempString,activecomports[port]);
strcpy(activecomports[port],&tempString);
(HANDLE)fd[nBus] = CreateFile(activecomports[port], GENERIC_READ, 0,
0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0 );
if( updateConnection( (HANDLE)fd[nBus] ) == 1)
{
return TRUE;
}
}

The first step of getAllRs232 is to determine the number of bytes in
the packet being sent, by calling:

ReadFile( (HANDLE)fd, (LPVOID)buf, (DWORD)bufSiz,
(LPDWORD)&nBytesRead, NULL );

This is where my program hangs up. I want it to cycle through the
ports and ultimately (on this specific computer) listen to port
configuration \\.\COM31, however it hangs up on the readfile on the
first instance (\\.\COM12). Is there a reason why SetCommState is not
returning an error for my specific configuration? There should not be
any data coming off any port now except COM31 or COM32.
Thank you very much in advance for any help!
Jul 3 '07 #2
On Jul 2, 6:57 pm, "Norman Diamond" <ndiam...@community.nospamwrote:
Sorry I don't think I can help with your problem, but please can you tell me
something.
(HANDLE)fd[nBus] = CreateFile(activecomports[port], GENERIC_READ, 0,
0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0 );

What compiler are you using?

Well, OK, maybe I might be able to help. I don't really want to know what
your compiler is doing, I just want to know what compiler it is ^_^ But
depending on what your compiler is doing, that might affect your results.

What is the value of fd[nBus] (without a cast) before that assignment, and
then again after that assignment? Does the compiler really generate code to
coerce a HANDLE to whatever type fd[nBus] has? And then it really assigns
to fd[nBus] and not assign to a temporary variable somewhere?

<kud...@gmail.comwrote in message

news:11**********************@d30g2000prg.googlegr oups.com...
I have figured out my problem, it was actually pretty simple...but
first my compiler is Microsoft Visual Studio 2003. The value of
fd[nBus] can be many different things, although for example, \\.\COM12
gives an integer value of 984.
fd[nBus] is declared as an integer in another part of the code and
passed as a Handle. I do know the dangers of passing an int as a
pointer value however int this case it turns out to be ambiguous.

So the problem turns out that my program will run through many ports
but some take a little longer to send their packets and confirm. So
the simple solution was just to declare a COMMTIMEOUTS that waits for
20 milliseconds (I think) to check the port. This fixed my ReadFile
hangup in which it would continue to try to read the Handle without
proper data coming through.

Here is what I ended up doing:

COMMTIMEOUTS TimeOut;

....//Set up all the DCB stuff

TimeOut.ReadIntervalTimeout = MAXDWORD;
TimeOut.ReadTotalTimeoutMultiplier = 1;
TimeOut.ReadTotalTimeoutConstant = 10; // 20 miliseconds
TimeOut.WriteTotalTimeoutMultiplier = MAXDWORD;
TimeOut.WriteTotalTimeoutConstant = MAXDWORD;

if(!SetCommTimeouts( hndl, &TimeOut))
{
return FALSE;
}

So in fact if SetCommTimeouts does not return false right off the bat,
it will timeout if I end up not seeing the correct packets at my
getAllRs232() function.

Just as a side note while running the following lines:
TimeOut.ReadTotalTimeoutMultiplier = 1;
TimeOut.ReadTotalTimeoutConstant = 10; // 20 miliseconds
The default value for both is 0 (2 milliseconds), which upon
declaration caused my program to run through all the ports on the
computer and state that I had nothing connected (when I actually
had). Lowering the sensitivity proved to do the trick.

Hope this is informative to someone else with the same problem.

Jul 3 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by paul kölle | last post: by
2 posts views Thread by Chua Wen Ching | last post: by
reply views Thread by Adam Clauss | last post: by
2 posts views Thread by PeteC | last post: by
6 posts views Thread by andrewbb | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.