Problem with Serial communication and CreateFile(...)
Svein-K Nilsen
I am having trouble getting a serial port up and running from time to time.
I have an component(COM) which opens the serial port like this:
if (port > 9 ) {
sprintf( szTemp, "\\\\.\\COM%d", port);
}
else {
sprintf( szTemp, "COM%d", port);
}
hComDev = CreateFile (szTemp,
GENERIC_READ | GENERIC_WRITE,
0 ,
0, // no security attrs
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL |
FILE_FLAG_OVERLAPPED, // overlapped I/O
NULL);
if (hComDev == INVALID_HANDLE_VALUE) {
.....
}
And then it is closed like this:
PurgeComm (hComDev, PURGE_TXABORT | PURGE_RXABORT |
PURGE_TXCLEAR | PURGE_RXCLEAR);
CloseHandle( hComDev);
The open-close cycle is run two times due to various (design) reasons.
The code works _always_ the first time, but the second time it is run, it
might flunk, and CreateFile will return and "INVALID_HANDLE", and
getlasterror will give:
ERROR_OPERATION_ABORTED ("The I/O operation has been aborted because of
either a thread exit or an application request.")
It works in most of the cases(i.e. 9 out of 10), so it is not a too big
problem, but it is big enough to be a mayor pain in the b... .
Do anyone have any idea what might be wrong ? (and if I am posting this
request to the wrong usenet group, please direct me in the right direction.)
Regards,
Svein-K. Nilsen
Lotfi
I have a similar pb... under w2K it works sometimes (the first time I access
the port then...)
wheras on W98 it works always !
if you find someting, please drop me an email (remove the (nospam..) from my
addy.
yours,
Lotfi
"Svein-K Nilsen" <sv...@start.no> a écrit dans le message news:
jT60a.19275$CG6.3...@news4.e.nsc.no...
Ian Boisvert
port - why do you use both? I don't know what the problem could be, but it
seems to me that you aren't quire sure what you are trying to do in your
call to PurgeComm. In the same call you are telling the driver to abort
everything and also to clear the buffer (i.e. finish transmitting). You
should probably pick one or the other that suits your situation.
Actually, it could be that the serial driver is trying to flush the FIFO,
but it doesn't have enough time to complete before you call CreateFile
again. I would rethink that design in any case - it sounds a bit wonky.
Ian.
"Svein-K Nilsen" <sv...@start.no> wrote in message
news:jT60a.19275$CG6.3...@news4.e.nsc.no...
Ian Boisvert
news:_S11a.213066$sV3.7...@news3.calgary.shaw.ca...
> Actually, it could be that the serial driver is trying to flush the FIFO,
Sorry, make that "UART is trying to flush the FIFO". Either that or the
serial driver is busy disconnecting from the serial port when your request
to create another handle on that port comes in.
Ian.
Svein-K Nilsen
connected to multiple COM ports(max is in fact 255 ....).
I keep a list of the units, but keep the serial port closed when it is not
in use. When the units connected are being activated, the port is opened
again. This is fair enough. I don't want to keep all ports with equipment
connected opened at all times, even if they are not in use.
The client software that is using my COM object, intializes the
equipment(thereby creating a list with it), and then activates all the
available equipment in the list. Of course: This does make my design
somewhat overkill, but in other cases the design is exactly on target for
the application.
The time from the first initialization to the second, is about 5 seconds or
more, so the UART should have had plenty of time clearing its buffer..
The serial driver and adapter(we are using a USB to RS232 interface) might
be a problem. We have tested numerous devices based on the same
USB-to-Serial chip, and have come up with on manufacturer that make a decent
interface with a driver that behaves the way it should do. Of course: That
does not make us feel very confident to the USB-RS232 adapter.. But the
alternative is to produce them ourselves, but that is NOT cheap, and would
kill the project.
(On my machine, and old driver for one of the other USB-RS232 interfaces
seems to hang around in the system, creating a nice blue-screen out of the
blue.(just staring at the screen can make my machine crash(!)..) Fortunaly
it is quite rare(happens once every forthnight or so..))
There was a reason for differing between high port numbers. I think I put
the code in there because the mere \\.\COMx notation didn't work that well
on some occasions.
I know the Q115831 in Knowledgebase states the opposite, but I do remember
that the first things I modified with the class, was the com-port thing. (I
just cannot remember why..)
About the PurgeComm:
You are correct about that I do not know much about the call: This is an old
class, being used in a lot of applications where I work.
I just looked into the documentation of purgecomm, and I see what you mean..
:-)
So: I divided it into two calls, one to clear the buffers, and one to abort
the communication.
And then I put a sleep inbetween(50 ms), just to make sure that the call
finish. (It could seem logical that this might be the error.. Testing on
monday will tell.. )
Thanx a lot for your input!
/Skn
"Ian Boisvert" <iboi...@yahoo.com> wrote in message
news:_S11a.213066$sV3.7...@news3.calgary.shaw.ca...