Serial.rts() on Teensy 3.2

Status
Not open for further replies.
Wrote a short VB.NET program that can set the DTR & RTS lines individually and that worked also expected with a Teensy.
Case closed I guess.

Paul
 
There is a collection of ham radio apps that use RTS to key a transmitter. These all work with standard USB to serial port adapters like the FTDI. Of the four apps I tried, only one works to set RTS on the Teensy. Maybe there are two ways to assert RTS on Windows, and most apps use the way that doesn't work on the Teensy.

I'm new to this, but it looks like your code that implements rts() is built on existing Arduino code, is that right? Where might I find the Arduino code to look at?
 
Maybe there are two ways to assert RTS on Windows, and most apps use the way that doesn't work on the Teensy.

Yup, it sure looks that way.


I'm new to this, but it looks like your code that implements rts() is built on existing Arduino code, is that right? Where might I find the Arduino code to look at?

The problem is on the PC side. Nothing you can do on Teensy will help. The combination of Termite & the Windows driver simply isn't sending the control message. There is no way to fix this from the Teensy side, since Windows isn't sending any communication to Teensy when RTS changes in Termite.

I did a test with a USB protocol analyzer, and tried to (rather awkwardly) record a video. It's uploading to YouTube now.
 
Ok, here's the video demo. Sorry about the mediocre quality... not easy to shoot 2 screens and get exposure perfect (and I really need to get back to the bootloader chips... not time to do a more professional video production). If you play in HD quality viewing full screen, you should be able to see the protocol analyzer info.

You can see whatever Termite is doing when you click the RTS button just isn't causing the Windows CDC-ACM serial driver to transmit anything to Teensy. But Coolterm does.

 
Is there a custom driver for the Teensy?

No, for USB serial it's just the USBSER.SYS driver built into Windows.

On Windows 10, it loads automatically. On Windows 2000, XP, 7 & 8, Windows doesn't load USBSER.SYS automatically. So a "driver" is installed on those systems, but it's not actually any executable code, just a text-only INF file which tells Windows to load its own USBSER.SYS driver when Teensy USB serial is detected.

With MacOS and Linux, the USB serial driver is also built in and loads automatically.

Teensy's many other non-serial USB modes also use the built in drivers on all 3 operating systems.
 
Thank you for your time and attention. I really appreciate it. I like that protocol analyzer.

And you answered my question: there is no custom driver. Maybe the bug is in the Windows driver. Any maybe all the "unnecessary" work CoolTerm does when you click RTS works around the bug.

Luckily, most of the apps I looked at (maybe all of them) let you choose between RTS and DTR as the transmit signal, and DTR is working reliably, so I'll be fine.
 
I agree Paul. Windows works, i.e Powershell.
The programs are buggy and maybe tested on FTDI only. The driver seems to be not 100% compatibel. Its more plausible that the bug is in the FTDI driver.
The driver question was answered in Post19, too.
 
My gut feeling is the guesswork on msg #28 is probably right. Microsoft probably only supported use of the modern WIN32 APIs in their USBSER.SYS driver. FTDI's driver probably has support for older Windows APIs (of which I know almost nothing).

I mainly wanted to check whether any communication was happening from Windows to Teensy, to see if there could be any possibility of somehow making this work. It's really nice having the protocol analyzer for these situations, so we can know the issue is Windows simply isn't sending anything. Then I wanted to make a video... which turned into more setup and fiddling than I want to admit, even for such a low quality overexposed picture. Someday I'll get better at quick video demos... But right now, I need to get back to the bootloader chip's diagnostic feature so we can release T4 bootloader chips next week.
 
I agree Paul. Windows works, i.e Powershell.
The programs are buggy and maybe tested on FTDI only. The driver seems to be not 100% compatibel. Its more plausible that the bug is in the FTDI driver.

CP2102-based adapters behave like the FTDI ones.
 
@PaulStoffregen: not a boring video at all, very clear and informative!
My guess is that the other mentioned terminal programs indeed talk to the FTDI driver instead of the WIN32 API.
I recall that long ago I wrote programs for serial communications using an FTDI adapter and I was using FTDI's API. Like this:
Code:
' FTD2XX.DLL functions
Private Declare Function FT_Open Lib "FTD2XX.DLL" (ByVal intDeviceNumber As Short, ByRef intHandle As IntPtr) As Integer
Private Declare Function FT_Close Lib "FTD2XX.DLL" (ByVal intHandle As Integer) As Integer
Private Declare Function FT_SetDivisor Lib "FTD2XX.DLL" (ByVal intHandle As Integer, ByVal div As Integer) As Integer
Private Declare Function FT_Read Lib "FTD2XX.DLL" (ByVal intHandle As Integer, ByVal lpszBuffer As String, ByVal lngBufferSize As Integer, ByRef lngBytesReturned As IntPtr) As Integer
Private Declare Function FT_Write Lib "FTD2XX.DLL" (ByVal intHandle As Integer, ByVal lpszBuffer As String, ByVal lngBufferSize As Integer, ByRef intBytesWritten As IntPtr) As Integer
Private Declare Function FT_SetBaudRate Lib "FTD2XX.DLL" (ByVal intHandle As Integer, ByVal lngBaudRate As Integer) As Integer
Private Declare Function FT_SetDataCharacteristics Lib "FTD2XX.DLL" (ByVal intHandle As Integer, ByVal byWordLength As Byte, ByVal byStopBits As Byte, ByVal byParity As Byte) As Integer
Private Declare Function FT_SetFlowControl Lib "FTD2XX.DLL" (ByVal intHandle As Integer, ByVal intFlowControl As Short, ByVal byXonChar As Byte, ByVal byXoffChar As Byte) As Integer
Private Declare Function FT_ResetDevice Lib "FTD2XX.DLL" (ByVal intHandle As Integer) As Integer
Private Declare Function FT_SetDtr Lib "FTD2XX.DLL" (ByVal intHandle As Integer) As Integer
Private Declare Function FT_ClrDtr Lib "FTD2XX.DLL" (ByVal intHandle As Integer) As Integer
Private Declare Function FT_SetRts Lib "FTD2XX.DLL" (ByVal intHandle As Integer) As Integer
Private Declare Function FT_ClrRts Lib "FTD2XX.DLL" (ByVal intHandle As Integer) As Integer
Private Declare Function FT_GetModemStatus Lib "FTD2XX.DLL" (ByVal intHandle As Integer, ByRef lngModemStatus As IntPtr) As Integer
And yes, there can be an issue with the FTDI driver...

Paul
 
Again, Windows works, Powershell works. Coolterm works, other programs work.
I programmed ESP over NodeMCU emulation running on Teensy - it uses both signals -> The Nodemcu programmer works too.
Teensy uses a default driver built into Windows. Nothing by PJRC. Nothing what PJRC could do (besides writing an own driver - which is not wanted, I hope)

I'm not sure which questions are still open.. :)
 
Status
Not open for further replies.
Back
Top