Win32API environment.
I need to identify which program is using a particular serial COM port. For example, if putty has opened COM4 and I later try to start another program that also wants to open COM4, how can I discover that putty is the program preventing this?
In other words, assuming I already have a list of all ports installed on the system, how do I work backwards to discover which programs have opened which ports?
Related
I am making a driver for windows kernel and I am using COM1 for getting log of kernel, the host machine is Ubuntu and guest is qemu. Windows 10 is installed inside it. The problem is there is a bulk of data to be write on COM1. So if it has to write a line ABCDEFGHI and in the next line, it has to write JKLMNOPQ.. it is doing something like ABCDEF in one line and GHIJKLMNOPQ in the second line, means one line data is incomplete and 2nd line data is also corrupting due to this.. is there any lock we can apply? that if one connection is using COM1 then no any other should write on COM1?
QEMU does not control who can write to serial port address at certain time. It's the guest OS's job. QEMU just receives whatever data it sees in the virtual registers.
If you really need to write bulk data to the serial port in the guest OS, you would expect very long time of process. I ever had the same problem and had to test the speed on a very fast Intel CPU. The best speed I can get is 220KBps.
If processing time is not a problem for you, from guest Windows perspective, if you directly write to COM1's port address, it's your driver's responsibility to make locking mechanism, assuming there is no other drivers/processes writing to COM1 either. If you write data via a handle to the COM1 device, there is no locking provided directly by Windows built-in serial port driver. But you still can do it in other ways: open a handle to the serial port device exclusively, so only one process can write to it, or make a device filter driver sitting above Windows serial port driver to add this additional access control, or even directly modify Windows serial port driver's source code to add what you want. Its source code is available now on github.
If none of above applies to your case, you might want to double check how you capture the output of COM1 on host, usually redirected to files, shell and etc. They also could cause some mystery of troubles.
I need to be able to close COM ports through the command prompt (Windows 7 OS). The reason for this is that I work with a lot of experimental equipment, controlled with a language called LabVIEW, and communication to these devices is sometimes lost. Right now the only fix is to either rename the COM in device manager, or reboot. Ideally I'd like to close the port in command prompt, which I can implement programatically in my control software.
Does anyone know either; how to close a COM port in command prompt, or a quick and easy way of closing a COM port, so then I can reestablish a connection with my device?
Cheers!
I don't think you can simply close a resource that is in use by another program, this will undoubtedly lead to errors. Programmed correctly LabVIEW should not leave ports open, even if port are left open simply closing labview should be enough.
In LabVIEW programatically open and close the COM port, don't rely on the auto-closing of the VISA system. Also add timeouts to the serial connections, than you should get a connection error time out and be able to clean up the resource.
Basically you need to solve your problem at the origin, if help needed post your LabVIEW code.
Presuming you read from the serial port in a while loop, simply stop the while loop when an error is found, see the code snippet. This stops the loop and the resource will be closed outside the loop regardless of the error.
I'm interfacing to a hardware serial device using QT, I've based my application roughly around the Terminal example, but as the communication needs to be very synchronous the serial handler is living in another thread. The connection is via a 2xRS232 to USB adaptor with an FTDI chipset.
The serial comms are fine, I can connect, send commands, etc. However, when I quit and reload the application the serial port seems to be blocked.
Let COM1 be the connected device, COM2 is unconnected.
If I run the program, do a bit of talking to the hardware and quit, I can no longer connect to COM1 the next time I run the program (the data leds don't flash on the adaptor) unless I attempt to connect to COM2 first. Once I've tried this I can then connect back to COM1 as usual. This behaviour is not seen in the reference utility for the hardware and so must be down to some way I'm handling the port.
My close code is:
void mydevice::closeSerialPort()
{
this->stop();
serial->close();
emit serialClosed();
emit log("Serial port closed.");
}
serial is a QTSerialPort. First a stop command is sent to turn off the hardware (not relevant to the problem, it's just a convenience) and then I send a close command to the serial.
I have a subclassed QWidget for my main window, which calls this command on exit:
/* In the constructor */
connect(this, SIGNAL(WindowClosed()), mydevice, SLOT(closeSerialPort()));
void mainwindow::closeEvent(QCloseEvent *event)
{
emit WindowClosed();
event->accept();
}
Is there any reason for this behaviour? I assume I'm blocking the port open somehow, but surely it would complain that it's already open.
Another odd issue is that say the device is on COM1 and I open it in my application, COM1 is unresponsive in the other utility and the device appears on COM2. However, when I switch back to my program and fiddle a bit, the device appears on COM1 again (though always in COM2 in the other application).
So there seems to be a fairly simple solution, though I don't understand exactly what was causing the problem.
I have two threads, each controlling a different serial device. The serial configuration is accessed through a dialog which I stole from a QT example (the terminal). Each thread has an instance of this settings dialog. It seems that something goes wrong when selecting the port - for instance all the selections in the dialog actually point to the same COM port if checked in a debugger.
Anyway, I chalked this up to non-thread-safe code and changed the program to just ask for the serial port name as the data rates, stop bits, parity, etc are fixed by the hardware and aren't going to change. This has fixed the problem.
There are two possible answers, I think:
Your process doesn't terminate in spite of you closing the main window. How have you verified that the process is, in fact, terminated?
Your use of qt's serialport module exposes a bug in FTDI's driver. That's not unthinkable, but I'd call it a remote possibility at the moment.
Personally I don't see any use for the serial port emulation of the FTDI driver, it's adding an extra layer for no good reason. The D2XX interface is the way to do it, if you don't want to use something like libftdi. On Windows, I've found D2XX and libftdi to be the only viable alternatives, with libftdi working much better than D2XX on virtual machines.
Don't know if this could be useful.
I have a similar issue (but not the same) with a prolific pl2303.
In my case when i close the port (or even at startup, before opening it!), data is received anyway somehow and presented immediately when i open the port.
This happens only with an usb-rs232 adapter, if I use the ttyS0 (physical serial port) the problem does not appear.
The solution for me was forcing QSerialPort::clear() to clear buffers just after QSerialPort::open(). This avoids signal readyRead to be emitted and thus unwanted data to be received.
Is there any way in Windows for a process to enumerate all the open ports/sockets it is using? I'm trying to track down some high port usage in my app, but my app uses very few, so it must be some other DLL getting loaded into the process.
Windows' own command-line netstat utility, as well as the SysInternals' TCPView app, can display the name of the process that owns each open port.
If you want to enumerate this information programmably, you will have to enumerate Windows' port routing tables manually and map them to your process. On XP, you can use AllocateAndGetTcpExTableFromStack() and AllocateAndGetUdpExTableFromStack(). On Vista and later, you can use GetExtendedTcpTable() and GetExtendedUdpTable() instead. Both sets of functions can return the Process ID of each open IP/Port, which you can then compare to the result of GetCurrentProcessId().
Amongst features of terminal desktop services running RDP port, there is port redirection of parallel/serial from remote to local PC.
Can this redirection be somehow used to transfer large data to avoid using Clipboard (due to the known stack bug which may force user to close terminal desktop and re-logon)?
To transmit and receive data I'd use VBA for Excel on both terminal desktop as well as in local PC. Both would be running infinetely or at the same time.
Please advise if it's possible.
At least one company makes a library for doing Kermit (i.e. serial file transfer), which includes VBA support and samples for Access, Excel and Word.
It's not cheap though, and there are a lot of better ways of sending data around than serial file transfer protocols over virtual serial ports so I'd strongly consider better alternatives (file sharing, TCP sockets etc.).