FTDI emulation

[stevech]

I have a product manufactured in the thousands for industrial automation. It has a USB 1.1 port. In the proprietary operating system of this device is a driver that supports FTDI's USB/Serial adapter. I tried an adapter from Prolific, Inc. It didn't work. I suspect that the proprietary OS looks for FTDI in the vendor / product enumeration.

Does this suggest that I cannot use a Teensy 3 (or 2) with this product, where all I want is the product's OS to do is accept the USB/Serial and do fundamental serial I/O? Nothing more.

(i.e., would it be ethically impossible to appear as does the FTDI, to the device's OS?)

The work-around is hacking in a true FTDI USB/serial PC board no cable, then connect to UART of Teensy.

Goal: Make T3 be a co-processor of the industrial product mentioned above. The T3 would do encryption/decryption in a fraction of a second per small data packet, since the product per se is doggy slow due to it using a bytecode interpreter. Would speed this up a lot, even with the overhead of UART-USB I/O.

 

[PaulStoffregen]

Using a real FTDI chip is probably the easiest way. If you only need one unit, or a small number, I'd do that.

Teensy probably can emulate the FTDI chip, but of course the results will depend on how much that proprietary driver "knows" and checks for the FTDI chip.

Changing the VID & PID are the most obvious things. The one other part you'll almost certainly have to edit is the code for transmitting USB packets. The FTDI chips reserve the first 2 bytes of every data packet for the handshake signals. You can probably just send zeros, but you'll definitely need to change the code to send 2 non-data bytes at the beginning of each packet.

Other changes might be needed too, but if the driver only checks the VID/PID and then sends and receives packets, these changes might do the trick.

 

[stevech]

Thanks. I'll experiment.
Ideally, I'd avoid using FTDI's chip - complexity and slows data vs. what USB alone with T3 could do; but high baud rate would do fine).

re FTDI's bytes for handshake... that's two bytes in every packet both ways?
Lastly: is there a Windows utility to display the VID/PID (e.g., for a USB/serial from FTDI that works properly?) I'll guess FTDI has a variety of PIDs as chipsets have changed.
Somehow, Windows and Linux seem to cope with many varieties of USB/Serial adapters.

 

[PaulStoffregen]

re FTDI's bytes for handshake... that's two bytes in every packet both ways?

I'm honestly not sure. I know it's in the FTDI to PC direction. The other way might use control transfers. The source code for the FTDI driver in Linux is probably the best source for reliable info.

Lastly: is there a Windows utility to display the VID/PID (e.g., for a USB/serial from FTDI that works properly?)

Yes. The Windows device manager can show you this info. Look for the drop-down list on the last tab and choose Hardware IDs.

Here's a screenshot for HID. The process is similar for nearly all devices.

 

[stevech]

thanks very much.