Does TyCommander handle FTDI? Or am I doing something wrong?

[clinker8]

I'm adding a FTDI cable for some data logging for my ELS (to avoid badly behaved USB transactions) and can't seem to get anything. When I use TyCommander it sees the FTDI device.

I'm on Mac running the latest and greatest OS. But in the serial data window, I get no data. Also the bottom, where one would be able to send data appears to be disabled. I can't write to the area. But using the USBSerial connection, sending data is fine. Here's the snippet of the FTDI initialization

void setup() {
  //TeensyTimerTool::attachErrFunc(ErrorHandler(Serial));
  //Init FTDI Serial. 
  pinMode(TX5, OUTPUT);  //Serial pin needs to be output.
  pinMode(RX5, INPUT);
  FTDISerial.begin(3000000);                                                 
  FTDISerial.addMemoryForWrite(FTDISerialTXbuffer, FTDISerialTxBufferSize); 
  //Update serial buffer.
  NVIC_SET_PRIORITY(IRQ_LPUART8, 96); //Set Interrupt Priority.

  while(!Serial && millis() < 4000);
  Serial.begin(115200);
  Serial.printf("System start time = %3.10lf seconds\n", mysec());
  if (FTDISerial.availableForWrite() > 8) {
  FTDISerial.printf("Start time = %llu\n", mycycles());
  FTDISerial.printf("Start time = %3.10lf seconds\n", mysec());
  }
  FTDISerial.println("Hello, FTDI is up!");
more stuff, not related...

Buffer size is 4K.

Backside connections.

Documentation for the real FTDI cable.

Did I get the wiring wrong? The set up? Or just a bad solder joint? Yeah, it's a little ugly there, I'll inspect it with a magnifier.

 

[defragster]

Under 'Options' tab check that the Rate matches the .begin( ## )?

Can the FTDI unit do 3 MBaud? :: FTDISerial.begin(3,000,000);

With it is showing in the UI the USB<>FTDI unit is working and recognized

 

[clinker8]

Under 'Options' tab check that the Rate matches the .begin( ## )?

Can the FTDI unit do 3 MBaud? :: FTDISerial.begin(3,000,000);

With it is showing in the UI the USB<>FTDI unit is working and recognized

It's currently greyed out at 115200 in TyCommander.
According the the FTDI datasheet it supports 3MBaud.

However, the native Apple MacOS FTDI driver might not support 3Mbaud. The FTDI documentation is quite old, the latest release of Mac SW mentioned is 10.9, I'm running 15.5.

Guess I can try 115200 to see if it works.

Edit: No difference. Does not work at 115200 either.

 

[defragster]

Has been used here after @Koromix added that functionality with ESP32 and other devices that present USB when plugged in.

For those like ESP setting the baud was added and active when it was recognized. If it is greyed then something not meeting the expected view is there.

A typical SparkFun or other FTDI that runs at 3.3V should work.

If you have a Second Teensy you can use the Serial Example ECHO sketch on that Serial to Serial and then just plug the Teensy into USB.

 

[defragster]

Not sure what the use case and end use is ?

Another option is to use Dual Serial on building and then look at the example for that usage. The Teensy will present TWO USB devices to TyCommander and one is the Primary and the other is the second USB that acts the same but is independent.

 

[clinker8]

Not sure what the use case and end use is ?

Another option is to use Dual Serial on building and then look at the example for that usage. The Teensy will present TWO USB devices to TyCommander and one is the Primary and the other is the second USB that acts the same but is independent.

End use case is for data logging for my electronic lead screw. I'm debugging a really tough problem. I'm losing sync, and I don't understand why. I had attempted extensive data logging using the standard USB serial, and discovered the logging itself was changing the operation and it shouldn't.

USB Serial has the unfortunate property of disabling ALL interrupts globally for longer periods of time than it should. I can see it in the usb source code. This is wreaking havoc on my interrupt driven control system. I can't afford to datalog using USBSerial if it blocks interrupts on a running machine. FTDI serial on the other hand does not behave badly. I can assign the FTDI ISR priority and it can be preempted by a higher priority. I have interrupts coming in every 32us and have to make decisions right then an there. I cannot have blockage for greater than 32us, or my control algorithm falls apart. Dual USB logging exascerbated the problem, it made it more likely that there was global ISR blocking... That was when I experienced my first application crashes.

I am using an authentic 3.3V FTDI cable, sourced via Digikey. I just found out by contacting FTDI tech support that I do not need to install any drivers, as FTDI support is built in to MacOS now. They also suggested a loopback connection and to use minicom to set up the interface to 3Mbaud, no flow control. So, I'm going to try that now.

 

[clinker8]

My FTDI cable is working. Did a 3M baud loop back, at least according to minicom. Turned echo on and off and got double characters, or not. Now to check if Teensy is transmitting at all, I will need to set up a scope for that.

 

[clinker8]

Teensy is transmitting, both disconnected, and with the FTDI yellow wire (RX in) attached to the Teensy TX5 pin. I can see the 3Mbaud burst.
TyCommander is not picking it up at all. TyCommander has not picked up the correct data rate, it's still set at 115200 and greyed out, so I cannot set it. If TyCommander is using screen as it's hook, it won't be able to use the max baud rate of the FTDI. Minicom can use up to 3M.

TyCommander sees the FTDI device, but cannot display the data. It displays no data.

However, if I bring up a minicom terminal, the output is present. I'd say this is a weird TyCommander bug.

Pity that TyCommander can't display the data, as minicom is a dinosaur program that is really DOS era weird to use.

 

[KurtE]

Note: Tycommander can handle some/most FTDI USB To Serial adapters. I know it works with some as:

However not all FTDI boards are equal. I know for example I we had to add support to handle some of them
differently. For example they have some that create more than one USB Device (i.e show up as two USB Serial devices)

 

[clinker8]

Note: Tycommander can handle some/most FTDI USB To Serial adapters. I know it works with some as:
View attachment 37872
View attachment 37873
However not all FTDI boards are equal. I know for example I we had to add support to handle some of them
differently. For example they have some that create more than one USB Device (i.e show up as two USB Serial devices)

Interesting. Mine is a genuine FTDI cable, sourced from Digikey, 6/9/2025, so I'd expect it to be authentic.
PN: TTL-234X-3V3-WE. Mfr: FTDI, Future Technology Devices International Lt. Digikey PN: 768-1322-ND.

TyCommander just sits there, I get zippo on the display. I don't get the two way symbol, there's a bar through mine. Like it's broken...

For my test, I only connected Teensy TX5 to the FTDI RX wire. But minicom sees it. ? marks are because I had sent binary data.

Seems to me that TyCommander isn't handling a stock FTDI adapter properly, at least not on a M3 using Apple Silicon with Sequoia 15.5.
Sure wasted a lot of time on this, my code was working all the while, but TyCommander wasn't working properly.

If I right click on the FTDI on the left and attempt to enable serial, I get the following error in the TyCommander log

tcsetattr() failed on '/dev/cu.usbserial-FT9LYIU8': Invalid argument

Right clicking on the Teensy icon shows the serial interface is enabled. The FTDI interface is NOT enabled in TyCommander, TyC can't communicate with it, or so it seems.

 

[defragster]

Did you check FTDI in loopback on TyComm? If that doesn't work then there is a recognition problem.

As @KurtE note - since the change was made we've used other Arduino devices to good effect.

If you have any second Teensy running the Echo sketch would replace the FTDI for UART from the Target Teensy to get USB from the 2nd Teensy.

 

[clinker8]

I've been able to run dual and triple usb serial before, so it's not that TyCommander can't do that. I have also had different Teensy's simultaneously connected to TyComm. I have yet to get TyComm to enable FTDI, don't know the magic sauce yet.

I did try connecting TX to RX on FTDI and using TyComm. That didn't work, The send data button never was enabled, but I'm willing to try that experiment again.

 

[jmarsh]

Smells like some sort of permissions problem with TyCommander being able to see the FTDI usbserial device node but not being able to open it.

 

[clinker8]

@defragster Ahem, loop back worked. I needed to enable the interface! Now to hook it up again and see if things still work. Funny, I didn't need to explicitly enable the Teensy... Time to turn on the iron again...

 

[defragster]

@defragster Ahem, loop back worked. I needed to enable the interface! Now to hook it up again and see if things still work. Funny, I didn't need to explicitly enable the Teensy... Time to turn on the iron again...

That's a good sign. Good Luck!

 

[clinker8]

Got wires attached. Now there's at least some garbage on the screen. Now the device came up enabled.

TyComm doesn't seem to auto adjust the baud rate for FTDI. So I set the baud rate. Sadly, the maximum baudrate in TyComm is 230,400. But FTDI can do 3,000,000. So TyComm is limiting reception to less than 7.7% of the adapter capability for FTDI. My opinion that's lame, especially since the true USB side can much faster. But, it's quite possible that once again, I have missed some magic incantation!

Got FDTI to work for 230400 baud. This is not good enough, need practically the full FTDI bandwidth, nearly 3Mbaud. Actually, even 3M may not be enough, but I'm going to exhaust that possibility before I *have to* use ethernet. I'm trying to avoid ethernet, as it's a whole new can of worms, mostly because I haven't done anything like it on a Teensy. And I'm kind of scared that the platform is going to run out of gas for the machine control application AND running ethernet.

 

[defragster]

TyComm doesn't seem to auto adjust the baud rate for FTDI.

Indeed, have to pick one of the few supported entries. Not sure if there was a code reason for that limit? When the edit was asked for that was where they topped out IIRC.

I know @Koromix took on a new work field after school and has been quiet since. But a github Issue might get attention.

The 2nd Teensy ECHO USB <UART> 1st Teensy would get around that.

 

[clinker8]

Indeed, have to pick one of the few supported entries. Not sure if there was a code reason for that limit? When the edit was asked for that was where they topped out IIRC.

I know @Koromix took on a new work field after school and has been quiet since. But a github Issue might get attention.

The 2nd Teensy ECHO USB <UART> 1st Teensy would get around that.

Looks like there are 16 entries in the table. Wonder if everything under 9600 could be dumped? That would save 10 entries! I mean who uses acoustic coupler baud rates these days? Can you even buy an acoustic coupler? To me, 3M is a lot more useful than 110, 134, 150, 200, 300, 600, 1200, 2400, & 4800 baud.

Can you explain what you mean by the last sentence, I'm not following you.

I'll try to write a coherent issue over at github. I don't even know where to find the baud rate stuff in his source. A quick look didn't show any obvious file names.

Edit:
serial.h in libhs is where the enum is with all the baud rates. rygel/tytools/libhs, it seems to be repeated for posix and windows. No idea if it's as easy as changing that. Somehow, I doubt it!

 

[defragster]

Can you explain what you mean by the last sentence, I'm not following you.

The 2nd Teensy ECHO USB <UART> 1st Teensy would get around that.

1st Teensy is the DEV unit, with a dedicated UART port.
2nd Teensy is a stand in for FTDI:
> use appropriate variation {common .begin(baud) and proper Serial#'s) of: "...\arduino-1.8.19\examples\Teensy\Serial\EchoBoth\EchoBoth.ino"
> Connect a UART from 2nd to 1st [Rx, Tx, GND]
> plug 2nd Teensy to USB
- any TyComm output to 2nd echos over UART to 1st
- any 1st UART output to 2nd echos over USB to TyComm

Here is a quick browser copy/hack edit of that sketch that might work per notes above:

// set this to the hardware serial port you wish to use
#define HWSERIAL Serial1

void setup() {
    Serial.begin(9600);
    HWSERIAL.begin(2000000); // T_4.x might go to 5Mb, but higher will bring more interrupts on 1st
}

void loop() {
    int incomingByte;
        
    while (Serial.available() > 0) {
        incomingByte = Serial.read();
        // HWSERIAL.print("USB received:");
        HWSERIAL.println(incomingByte);
    }
    while (HWSERIAL.available() > 0) {
        incomingByte = HWSERIAL.read();
        // Serial.print("UART received: ");
        Serial.println(incomingByte);
    }
}

 

[clinker8]

Created an issue on Github on tytools\libhs. Hope it's compelling enough. I'm controlling a lathe, and USB serial is globally blanking all interrupts while data logging. This should not be. I requested higher data rates be enabled on TyCommander so that the available bandwidth of the FTDI adapter be more efficiently used. Currently one can only use 230400 baud, or 7.7% of the adapter.

I don't know how to build tytools on a Mac. If I did, I'd try it. I'd just try modifying the enum in serial.h and see what happens. Honestly, I don't know if it would break everything else, since I don't know the tytools application. But seriously, who uses 134 baud any more? I'd rather have 1M, 2M or 3M baud, than 134, 150, 200 baud. Heck, 300 baud was used for acoustic couplers in the 60's. I just looked, can't even find an acoustic coupler modem these days. My teletype with paper tape reader is long gone, it's been at least 35 years...

 

[KurtE]

You probably already know this but the baud rate in a lot of the different cases is meaningless in the
communications between the two processors (PC and FTDI). That is they are talking to each other
using USB at USB speed... When you change that value on your PC. The main thing that happens
is the app like TyCommander will send a control message to the FTDI device: CDC_SET_LINE_CODING

Which the device may or may not handle:
For example with a Teensy, we receive it in usb.c

#ifdef CDC_STATUS_INTERFACE
    // 0x2021 is CDC_SET_LINE_CODING
    if (setup.wRequestAndType == 0x2021 && setup.wIndex == CDC_STATUS_INTERFACE) {
        memcpy(usb_cdc_line_coding, endpoint0_buffer, 7);
        printf("usb_cdc_line_coding, baud=%u\n", usb_cdc_line_coding[0]);
        if (usb_cdc_line_coding[0] == 134) {
            usb_start_sof_interrupts(NUM_INTERFACE);
            usb_reboot_timer = 80; // TODO: 10 if only 12 Mbit/sec
        }
    }

The only thing it does is in the Serial object, it remembers this value and if you ask for it it will return it...

How it is often used, is like for the teensy example sketch: USBtoSerial is like in the main loop.

void loop()
{
  unsigned char dtr;
  int rd, wr, n;
  // check if any data has arrived on the USB virtual serial port
  rd = Serial.available();
  if (rd > 0) {
...
  }

  // check if any data has arrived on the hardware serial port
  rd = HWSERIAL.available();
  if (rd > 0) {
...
  }

  // check if the USB virtual serial port has raised DTR
  dtr = Serial.dtr();
  if (dtr && !prev_dtr) {
    digitalWrite(reset_pin, LOW);
    delayMicroseconds(250);
    digitalWrite(reset_pin, HIGH);
  }
  prev_dtr = dtr;

  // if the LED has been left on without more activity, turn it off
  if (millis() - led_on_time > 3) {
    digitalWrite(led_pin, LOW);
  }

  // check if the USB virtual serial wants a new baud rate
  if (Serial.baud() != baud) {
    baud = Serial.baud();
    if (baud == 57600) {
      // This ugly hack is necessary for talking
      // to the arduino bootloader, which actually
      // communicates at 58824 baud (+2.1% error).
      // Teensyduino will configure the UART for
      // the closest baud rate, which is 57143
      // baud (-0.8% error).  Serial communication
      // can tolerate about 2.5% error, so the
      // combined error is too large.  Simply
      // setting the baud rate to the same as
      // arduino's actual baud rate works.
      HWSERIAL.begin(58824);
    } else {
      HWSERIAL.begin(baud);
    }
  }
}

Is in the main loop, it checks if changed: if (Serial.baud() != baud) {
And if so it changes the baud rate of the corresponding UART ... i.e. on your FTDI adapter it changes the RX/TX pins to that Baud
rate....

So yes it can potentially move data faster to the FTDI from what it is connected to. The question will then be how fast can your
main computer handle the Serial data coming to it over USB?

 

[clinker8]

@KurtE it's clear to me that usb.c does some pretty severe interrupt blocking in loops. It's not exactly well behaved. If it blocks for more than 33 microseconds I lose synchronization. There's nothing in the usb.c code that prevents interrupt blockage for more than that time. That's unacceptable in real time machine control. So I have to use a different data logging interface to get access to what is happening.

I have a real bear of a bug that I am trying to address, but the old school data logging (since there's no ICE) is affecting the normal operation of the control algorithm (due to blanking interrupts too long). The bug causes destruction of the part in the lathe, so the bug is not benign, unlike a sparkle on a display. If the loss of synchronization is great enough, the lathe itself can be damaged. It's a big deal, and a really bad bug. I've been trying to get a handle on this for over three months. Nothing is going smoothly. If I knew the actual cause of the bug, it might be easier to fix! Logging was to help identify, or at least narrow the region for detailed inspection.

HW serial, apparently does not block like usb. At least that is what I found. But it is slower. However, it won't block my encoder interrupts which are at a higher priority. Usb blocks everything except NMI.

TyCommander will not connect automatically, nor auto negotiate up to the FTDI speed. It doesn't, I tried. I had expected it to work identically to USBSerial, but it doesn't. At least for my authentic FTDI cable.

FTDI is not my first choice, it was chosen because the complexity of management was low. I had considered ethernet, but my experience with it on Teensy is minimal. I did get some examples to work, but I have not tried anything at the scale that would be required. Just didn't want to get in over my head on yet something else. I'm already in trouble with understanding why I have this bug, I really need less complexity, not more. Continually increasing the scope of a project is a sure way to kill it. I want this to work, so I have to keep the scope achievable.

It is my experience, that my main computer can handle about 1 Gbps rates, so 3Mbps is nothing. My 2009 laptop handled 786Mbps data payload transmission rates over 1Gb Ethernet, I'm expecting similar if not better performance in 2025. That's actual data transfer rate including TCP/IP overhead. Obviously, that was continuous operation (and 1GbE). Start stop mode is far less efficient. I haven't tried doing a USB transfer recently, but it's many orders of magnitude faster than FTDI. It will work. Of course, I'll have to quit my browser with 20 tabs open, but hey, that's ok. Actually my 2024 laptop has thunderbolt/usb ports, which are 40Mbps. Writing to external NVMe disk is really very fast.

Is there the equivalent of a sockets library for Teensy? I did a client server using sockets, long ago. I still may have the source code for that...
Edit: Yeah, found the server code. Origin date: 11 Sept. 2009. Wow. C++, OpenMP, & FFTW.

 

[shawn]

Is there the equivalent of a sockets library for Teensy? I did a client server using sockets, long ago. I still may have the source code for that...

I made a library called QNEthernet that does TCP/IP via the Arduino-style Ethernet API, and can also be used in a non-blocking way. The Teensy can do 100Mbps Ethernet. (The actual speed will be smaller.) See the examples for a little guidance.

 

[clinker8]

I made a library called QNEthernet that does TCP/IP via the Arduino-style Ethernet API, and can also be used in a non-blocking way. The Teensy can do 100Mbps Ethernet. (The actual speed will be smaller.) See the examples for a little guidance.

Thanks. After I posted, I realized the standard C/C++ sockets library is relying on an OS, and Teensy isn't running an OS. I'm hoping I don't need to use ethernet, only because of processing load. Serial is simple... But it's seeming more likely that I'll need a higher bandwidth pipe.

I'm amazed when I look back at the client/server code I wrote in 2009. I knew nothing of ethernet, networking, endianess, nor client server things in August 2009. Learned a heck of lot, all on the job training, while under pressure...

 

[KurtE]

Sorry, not sure if this would help or not... But maybe a faster USB To Serial adapter?

If I am looking right, the FTDI document Appendix A for your cable I see:

You might try to find something that uses a Higher speed USB, like FT232H like:

Example: https://www.adafruit.com/product/2264

Not sure how well it works as I don't have any, but...