1

I'm working in a C/C++ program that communicates with a RS232 device. The port is opened using CreateFile()

hComm = CreateFile(DevPath, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL);

Then, the port is Setup using SetupComm(), SetCommState() and SetCommTimeouts() with no hardware control and a baudrate of 115200 baud and timeouts as shown here:

    cTimeouts.ReadIntervalTimeout = MAXDWORD;
    cTimeouts.ReadTotalTimeoutConstant = 1;
    cTimeouts.ReadTotalTimeoutMultiplier = 0;
    cTimeouts.WriteTotalTimeoutConstant = 40;
    cTimeouts.WriteTotalTimeoutMultiplier = 1;

The port is closed using CloseHandle()

CloseHandle(hComm);

This is not a real-time system but has to be very fast, and after noticing some delays I've measured that instruction CloseHandle() takes always more than 100ms to run, which is a huge amount of time, taking into account that opening and configuring the port takes only 20ms.

Test conditions are as follows:

  • There isn't any anti-virus or firewall in the test machine (off-line).
  • I'm using Visual Studio on an brand-new Intel-based Core-i5 computer, running in Windows 10.
  • FTDI USB device (Virtual CommPort)
  • There is no data pending to be read or written (or it shouldn't).

I've tried to compile a similar program in Linux and the Close time reduces to 25ms. I've also tried to use a physical RS232 connection and the close times turns to be 1ms, so I presume this comes from the FTDI driver.

Does anyone have any clue on what could be happening. Am I missing anything? Did anyone experienced something similar?

Carles
  • 418
  • 2
  • 18
  • How many bytes do you send or receive on this port before closing it? Is it possible that buffered bytes need to be handled? – the busybee Jun 15 '21 at 14:59
  • 1
    Why don't you try this? [bmo/mttty](https://github.com/bmo/mttty) – kunif Jun 15 '21 at 16:03
  • I can not determine the cause of the problem, perhaps the port needs to handle handles or data caching. And although you do not have a firewall or anti-virus software installed, you may be running MSE or Windows Defender. – Zeus Jun 16 '21 at 02:18
  • 1
    What I have experienced is that the async request being published (WaitCommEvent/ReadFile/WriteFile) does not complete. Why not issue a SetCommMask with a different mask value or a PurgeComm that cancels everything before CloseHandle? However, due to a bug in the device driver, the system sometimes hung up when the above measures were taken. – kunif Jun 16 '21 at 10:38
  • 1
    did you check https://stackoverflow.com/questions/52926868/non-overlapped-serial-port-hangs-at-closehandle ? – Christian B. Jun 16 '21 at 15:00
  • @busybee Depends on the session I could send a few bytes or thousands of kilobytes. But that's not the issue. I'm pretty sure that buffers are empty before closing, in fact I check them and purge them, just in case. – Carles Jun 17 '21 at 06:54
  • @kunif Thanks for the info. I'm already purging the port, but you might be right. I was checking the link passed by Cristian B. and I will try to set the Mask and force the RTS, CTS... lines just in case this makes any difference (despite I'm not using them). – Carles Jun 17 '21 at 06:59
  • I've tested everything: CancelIo(), PurgeComm(), SetCommTimeouts(), SetCommState(), SetCommMask(), etc. But does not make any difference. By the way, I've just received a response from FTDI and they aknowkledge the delay, despite they don't consider this is an issue, giving the ball to Microsoft and their driver/port handling. I doubt this is the cause, since it works perfect while using a physical RS232 connection. They might have something wrong in their driver... – Carles Jun 17 '21 at 08:09

0 Answers0