Serial.rts() on Teensy 3.2

[smeredith]

I am trying to use Serial.rts() as a signal from a Windows program to teensy code, like this:

const int LEDpin = 13;

void setup() {
Serial.begin(9600);
pinMode(LEDpin, OUTPUT);
digitalWrite(LEDpin, LOW);
}

void loop() {
digitalWrite(LEDpin, Serial.rts());
}

I expect the LED to come on when the Windows program sets RTS. This doesn't seem to work. For a simple windows program that can set RTS, I am using termite: https://www.compuphase.com/software_termite.htm, using the "status LEDs" plugin. When you click the RTS button in termite, it asserts the RTS line. This works as expected with an FTDI USB to Serial adapter but not on the teensy.

DTR does work as expected with termite and the teensy. If I change the code above to Serial.dtr() and click on the DTR button in termite, the teensy LED responds as expected.

Either I'm missing something, or there's a bug somewhere.

[smeredith]

Interestingly, RTS works as expected with CoolTerm. It must be something with how the COM port is initialized by the Windows programs. So far, I have 2 programs where RTS works as expected, and 3 where it doesn't. Maybe I'll see if the source is available for any of them so that we can look for the difference.

[smeredith]

As a clarification: the 5 programs mentioned above all assert RTS correctly on the FTDI adapter, but only 2 of them set it on the Teensy.

[PaulS]

Interesting. I modified your sketch a bit to show the status of DTR and RTS in the serial monitor screen.

void setup() {
  Serial.begin(9600);
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, LOW);
}

void loop() {
  digitalWrite(LED_BUILTIN, (Serial.rts() || Serial.dtr()));
  Serial.print(Serial.rts()); Serial.print("   "); Serial.println(Serial.dtr());
  delay(500);
}

CoolTerm 1.8.0 seems to work OK for both DTR and RTS.
Clicking on the bottom-right DTR and RTS indicators shows on the serial monitor screen and the Teensy LED.



Thermite 3.4 only seems to work for DTR.
Clicking the RTS indicator does not show anything on the serial monitor screen and/or the Teensy LED.



I have the feeling the issue is related to the different Windows programs.

Regards,
Paul

[PaulS]

Did a quick test with a genuine FTDI US232R-10 USB serial converter.



This time, both CoolTerm and Thermite were able to correctly set the DTR and RTS lines when clicking on the DTR and RTS indicators.

So perhaps it is Teensy related?

Paul

[PaulS]

Further searching on this forum on DTR & RTS, I found this thread, so I tried with PowerShell.
Here is the screendump:



The first 7 lines shown are with the FTDI dongle plugged in. Then I plugged in the Teensy 3.2, repeated the PS commands and it shows an error.

Does anyone have a clue?

Paul

[Frank B]

Further searching on this forum on DTR & RTS, I found this thread, so I tried with PowerShell.
Here is the screendump:

Attachment 23296

The first 4 lines shown are with the FTDI dongle plugged in. Then I plugged in the Teensy 3.2, repeated the PS commands and it shows an error.

Does anyone has a clue?

Paul

Is the Teensy on COM1?

[PaulS]

Yes, it is on COM1. FTDI dongle also.
Oh, I was not clear. First I plugged in the FTDI dongle, ran the PS commands, then removed the FTDI dongle and inserted the Teensy, then ran the PS commands again.

[Frank B]

Is the Arduino Terminal closed? Only one program can use a serial port.

[Frank B]

Weird windows..
Its not visible in your screenshot: Have you used

$port = New-Object System.IO.Ports.SerialPort COM1

Its interesting that both are COM1. I thought Windows does not do that.

[PaulS]

Yes, Arduino terminal is closed.
The PS shell must have remembered that I assigned COM1 to 'port'.
Here is a new screenshot:



Yes, Windows allows you to reassign the COMport number in the Device Manager [but it warns you to not do so though]. Anyway, for these tests I did not plug in the FTDI dongle and the Teensy at the same.

If I want to dive into this, do I have to look into the usb_xxxx.cpp & .h files in C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\ ?

Thanks,
Paul

Edit: DTRenable and RTSenable work OK, I measured the DTR & RTS lines.

[Frank B]

Files: Yes, I think so.
But I don't think there is a connection with the weired message "..does not exist".
In this case the Arduino Terminal should'nt work.
I tried on my computer, and it works on a T3.2

It might be that Windows gets confused by two devices with the same portnumber.

[PaulS]

Solved, I had to close the complete Arduino IDE [although I did not have the Terminal open].



And also DTRenable and RTSenable work OK now measuring the DTR & RTS lines.

Paul

[Frank B]

Ok.. great.

[PaulS]

Correction/addition: it seems that the Teensy Loader [or is it teensy_ports?] is 'screwing' up the Powershell serial port behaviour, not the Arduino IDE.
When Teensy Loader is open but idling, it allows Powershell to open and close the serial port. But once you uploaded a hex file, Powershell can't get a hold of the serial port anymore.

Wait, now Windows is screwed up: nothing is plugged in but "PS C:\WINDOWS\system32> [System.IO.Ports.SerialPort]::getportnames()" shows "COM1".

Time to reboot Windows...

[PaulS]

After rebooting my PC, no strange behaviour anymore with Powershell and/or Arduino and/or Teensy Loader...
Powershell can't open COM1 when the Arduino Terminal is open [as expected] and is able to open COM1 again when I close the Arduino Terminal [as expected].

Well, all good for now.

Paul

[PaulStoffregen]

Teensy Loader uses only HID protocol. It never tries to access any serial ports.

In the Arduino IDE, Teensy should appear twice in the Tools > Ports menu. If you select the "Teensy ports" entry, access to the device is done by the teensy_serialmon program, which uses Windows native APIs (WIN32 CreateFile, SetDefaultCommConfig, etc). It knows how to access either Serial or HID, using WIN32 setupapi and configuration manager to detect which type of device. If you select the one from "Serial ports", access is done through Java JRE & the JSSC library, which is only for serial ports. Either way, the Arduino IDE should not be actually trying to access the device unless you open the serial monitor, or if you're doing an upload and it's trying to access the device to send the auto-reboot to bootloader request.

[PaulS]

After the perils with Powershell and rebooting my PC, back to the original issue this thread started with: I verified my initial tests again and the messages #4 and #5 are still valid.

I'm not sure where the differences between CoolTerm and Thermite come from when using the Teensy.

Paul

[Frank B]

I'd blame the programs.
There is no "Teensy driver" - everything is native Windows. The driver too.

Perhaps something gets confused by your com-port-hack or the FTDI driver on com1.
Could it be that the FTDI driver thinks that it is responsible for COM1? Or that it does not release needed resources?

[PaulS]

Yeah, I tend to think so too. Powershell is also working as expected with Teensy and FTDI dongle.

[smeredith]

Here's more interesting behavior using Termite:

DTR can be ON or OFF as its initial state.

Turn RTS ON. Teensy does not see the RTS state change to ON.
Toggle DTR. Teensy now sees the RTS state change to ON.
Turn RTS OFF. Teensy does not see the RTS state change to OFF.
Toggle DTR. Teensy now sees the RTS state change to OFF.

Just turning DTR on and leaving it on is not sufficient for the Teensy to get the RTS state changes--DTR has to see change (in either direction) before Teensy notices an RTS state change.

Hope this helps.

[smeredith]

I should add that it's not *just* Termite that is doing something weird. I have several other programs that use RTS as a signal, and they all function fine using other USB-to-serial adapters but not with the Teensy.

[smeredith]

I just did a quick google and found this: https://github.com/PaulStoffregen/co...3/usb_serial.h and I can't help wonder if

operator bool() { return usb_configuration && (usb_cdc_line_rtsdtr & USB_SERIAL_DTR) &&
((uint32_t)(systick_millis_count - usb_cdc_line_rtsdtr_millis) >= 15);

should be

operator bool() { return usb_configuration && (usb_cdc_line_rtsdtr & (USB_SERIAL_DTR | USB_SERIAL_RTS)) &&
((uint32_t)(systick_millis_count - usb_cdc_line_rtsdtr_millis) >= 15);

[PaulS]

Gave it a quick try, modified usb_serial.h on my PC, compiled and uploaded it.
Even tried the || (double pipe) operator USB_SERIAL_DTR || USB_SERIAL_RTS .
Unfortunately no change...Termite can not toggle the RTS line.

Paul

[smeredith]

Yeah, never mind. That just looks like a function that you can use to wait for DTR to come high. Like

while (!Serial)
;