RTS software control

[MaximSharkov]

RTS can operate only by hardware ? CwType, for example, need both RTS and DTR software controled

[r2axz]

RTS can be controlled by software if the driver supports it. On Linux and OS X everything works as described in the README.md. On Windows, the situation is slightly different. For some reason, the default USB serial driver in Windows (USBSER.sys) does not send set_control_line_state messages when RTS is changed by software. set_control_line_state is only send when DTR is updated. Interestingly enough, when the driver issues set_control_line_state as a result of DTR update, it also sends a new state for RTS.

This is a long running issue, which Microsoft does not bother to fix. Here are some references:

https://community.arm.com/developer/tools-software/tools/f/keil-forum/32273/usbser-sys-quirks-explained https://answers.microsoft.com/en-us/windows/forum/windows_xp-hardware/virtual-serial-port-usbsersys-is-not-sending/a086cbf6-2d0a-4c46-88fd-73865bc185f5 https://www.winvistatips.com/threads/usbser-sys-rts-problem.191930/

I just checked with Windows 10, and it looks like the problem remains: no USB messages when updating RTS from software.

Now, depending on your software this may or may not be an issue. For instance, if your software updates updates DTR and RTS simultaneously, everything should work just fine. For example, CoolTerm does this. Of course, DTR can be updated to the same value, which effectively updates only RTS. Some other software (e.g. Termite) does not do this.

So, the entire situation depends on our OS and software combination.

I tested the firmware with CwType on Windows 10, and it looks like CwType does not fully take USBSER.sys behavior into account. While RTS goes low (active) at the beginning of the transfer, it does not go high (inactive) at the end. When RTS is used for PTT, this means the transceiver remains in the TX state. Not good.

I will try to figure out possible workarounds.

[r2axz]

Another reference: https://www.embeddedrelated.com/showthread/lpc2000/23168-1.php

[MaximSharkov]

ok, thanks for detailed answer

73 de R3YAP :-)

[r2axz]

I reopened this issue because I believe this should be documented in README.md. Basically, the only reasonable workaround is to set DTR (even to the same state) each time you set RTS. This can be easily implemented on the application level with a code like this:

#include <windows.h>
#include <stdio.h>

int main() {
    HANDLE hComm = CreateFileA("\\\\.\\COM5", GENERIC_READ | GENERIC_WRITE,
        0, NULL, OPEN_EXISTING, 0, NULL);
    if (hComm == INVALID_HANDLE_VALUE) {
        printf("Error opening serial port\n");
    } else {
        printf("Serial port opened\n");
    }

    while (1) {
        // I don't know any easy (and reliable) way to get current DTR state in WinAPI unfortunately.
        // Probably the simplest solution is to keep current DTR value in a variable.
        EscapeCommFunction(hComm, SETRTS);
        EscapeCommFunction(hComm, CLRDTR); // or SETDTR, does not matter
        (void)getc(stdin);
        EscapeCommFunction(hComm, CLRRTS);
        EscapeCommFunction(hComm, CLRDTR); // or SETDTR, does not matter
        (void)getc(stdin);
    }
    CloseHandle(hComm);
    return 0;
}

(@MaximSharkov) As for CwType, I contacted UA9OV and he kindly agreed to implement this workaround. He sent me a test build, which I tested on Win XP, 7, 8, and 10. Everything works as expected. I hope we will see a new version of CwType shortly.

Meanwhile, I will update README.md to describe the behavior of RTS on Windows.

[r2axz]

@MaximSharkov, attached is a test build of CwType that implements a workaround for this bug. You can use it now or you can wait till a new release is available on the project website. cwt234a.zip

[r2axz]

Resolved in #48