Clever Geek Handbook

Simulating devices on a COM port

I have a device that is sending data to a COM port. And I would like to simulate this device when it was not connected. I thought it could be done by simply sending data to a specific COM port:

int main() {
    char *port = "\\\\.\\COM40";

    HANDLE hCom = CreateFile(port, GENERIC_READ | GENERIC_WRITE,
        FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
    if (hCom==INVALID_HANDLE_VALUE) return 0;

    DWORD writeBytes;
    int buffer = 0xDEADBEAF;
    BOOL success = WriteFile(hCom, &buffer, 4, &writeBytes, NULL);

    FlushFileBuffers(hCom);
    Sleep(1000);

    HANDLE hCom2 = CreateFile(port, GENERIC_READ | GENERIC_WRITE,
        FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
    if (hCom2==INVALID_HANDLE_VALUE) return 0; // Exit. GetLastError() == 5

    DWORD readBytes;
    success = ReadFile(hCom2, &buffer, 4, &readBytes, NULL);

    CloseHandle(hCom);
    CloseHandle(hCom2);
    return 0;
}

Unfortunately this doesn't work, and the second CreateFile()

installs the last bug in ERROR_ACCESS_DENIED

. What am I missing?

+3


source to share


4 answers


To simulate, install a virtual COM port driver such as com0com . Then you can define 2 COM ports that are linked together with the driver. No hardware required. Anything written on one port can be read on another port. Then you can open a handle for each port with separate calls to CreateFile ().



I use this technique myself, it works really well. When I need to write an application that communicates with a device, I usually write a separate simulation application that generates data for the main application to read and consumes the data sent by the main application. The main application doesn't know that it is not communicating with a real device, so you don't need to change any code in the main application to support the simulation.

+5


source


You cannot send messages to a serial port by opening the same port twice. A serial port has two different physical wires: one for transmitting and one for receiving. Without connecting anything to the port, the two wires don't go anywhere, and signals don't automatically go from one to the other.

Having said that, it is possible to create a key that connects the TX and RX pins together and receives the same bytes that you write. It's a physical component, but you can't just do it in software (well, unless you've created a "loopback" COM port driver that doesn't even have to talk to the hardware).



A quick Google search reveals that both the physical key and the loopback driver could not be obtained.

0


source


you can use two different COM ports for this test. use one as a simulated device and the other as a receiving system receiving data. For this, you do not need CreateFile

to be on the same port twice.

0


source


The serial port is not an IPC link. If you want loopback it either has to be simulated in the driver or you need to enable loopback mode. I think the driver is preventing the two handles from opening on the device even though exchange flags are being passed to CreateFile

. (I could never get two serial applications on Windows to open the same serial port.)

http://msdn.microsoft.com/en-us/library/ms810467.aspx

I don't see any flags in the structure DCB

for loopback setup, even though chips like 16550 UARTS have the option.

So an extenal loopback over a null modem cable is.

0


source






More articles:


All Articles