FT232R detection - Windows & Linux

[npelov]

Does anyone know how to enumerate and identify (get pid, vid and serial) FT232R chips in windows and linux. When you use it yourself it's not a big deal if you enter the COM port number in your program's configuration, but if you make it for someone else - well people like it when it's user friendly ... "plug and play", not "plug and pray".

[Sander]

FTDI has a software tool somewhere with which you can chance various parameters, such as pin configuration. Have you already tried that?

[npelov]

Yes, I used the tool. I can set the PID/VID and the serial number, but I don't know how to read them in C/C++ and how to setup an "event listener" of some kind to trigger upon device connect. I need:
1. enumerate devices and get device info (I'll do that on start) to search for already plugged device
2. setup event listener that will call a callback whenever a device is plugged. I don't want to waste system resources by scanning for devices every few seconds.

[Bored@Work]

Linux:

Event listener: udev rules, and from within a program libudev

Polling/looking for devices etc., one of:

* Scanning the /sys file system for the device data, endpoint, map to /dev/tty... name, etc.

* Scanning the /proc file system ...

* libusb (commonly used is v0.1.x, esp. in legacy code, but I prefer 1.0, more stable and a better API) for numerating devices.

* D2XX Linux driver should have some enumeration support, too.

[firewalker]

You could also use D-Bus in GNU/Linux systems. UDEV will broadcast a D-BUS signal for the device.

Alexander.

[fcb]

Are you using the FTDI supplied D2XX and VCP drivers?

[Bynun]

For windows i found the easiest way is to use the ftd2xx library supplied with the drivers, just add the header, link the libraries then do something like...

FT_DEVICE_LIST_INFO_NODE info[CPO_MAX_DEVICES];
int iNumDevices = 0;

uint32 numDevs = 0;
FT_STATUS ftStatus = FT_CreateDeviceInfoList(&numDevs);
if((ftStatus == FT_OK) && (numDevs > 0))
{
   // Extract information
   FT_DEVICE_LIST_INFO_NODE *pNodes = new FT_DEVICE_LIST_INFO_NODE;
   if(FT_GetDeviceInfoList(pNodes, &numDevs) == FT_OK)
   {
      for(uint32 i = 0; i < numDevs; i++)
      {
         CopyMemory(info[iNumDevices], &pNodes, sizeof(FT_DEVICE_LIST_INFO_NODE));
         iNumDevices++;
      }
      delete[] pNodes;
   }
}

Then go through the iNumDevices sized list of info to see what you have. The FT_DEVICE_LIST_INFO_NODE structure includes description, location id, serial number, etc... Usable with FT_OpenEx(), e.g.

FT_HANDLE hHandle;
FT_OpenEx(info.Description, FT_OPEN_BY_DESCRIPTION, &hHandle);

To discover when it's plugged in, just loop the code above every second or so until something appears

[npelov]

Thanks for replies.
It's a busy time of the year and I don't know when I'll be able to test the code. Yes, under linux I had the idea to set PID/VID and use udev to signal my program when something is plugged. Now the only left is:
1. list FTDI devices (maybe using libusb - code examples or even a link would be appreciated). couldn't be that hard.
2. ... and plugin event handling under windows. Windows is such an a***ole...
@Bored@Work sys and proc ... well yes, but I'd rather use libusb. sys and proc is like running system('lsusb') - not that it's that that bad, but ... I guess it's just a feeling more than a real reason. I don't know how to talk to Dxxx driver under linux. under windows they supplied a library to use for communication with device.

happy holidays to everyone!

[Psi]

Unless you're able to identify your specific FT232 chip over any others you have to send an init frame to each com port chip on the system and listen for the reply from your product. (or at least every FT232 on the system)

You can code your device to send out a ident packet every so often and then listen for it, but to scan many com ports fast you need this ident packet repeating very fast which can be undesirable.

In one of my products i don't bother checking for FT232 chips, i just enumerate all com ports on the system and cycle through them looking for a responses to my init frame. 

I found it to take less than 2sec to check 10 ports for my device with a fast baudrate and a realistic timeout before trying the next port. Is pretty uncommon on a consumer pc/laptop to have more than 4 active com ports so detection speed really isn't a problem at all.

However, one thing you have to be aware of when testing all ports on the PC is potential side effects of probing unknown devices serially with your init string.
It's conceivable you could trigger some response from other devices on the system. It might use up expensive paper (com port printers) or corrupt serial terminals etc..

In my case the product is installed in a car so people are only ever going to be connecting with a laptop. I can be pretty sure no one is going to connect to my product with a $10,000 desktop PC wired to expensive equipment over many serial ports.

So ideally you want to identify your FT232 over all others and eliminated this problem entirely but for general consumer stuff it's usually fine to just cycle through the ports probing for your product.

Side note: Always enumerate the active ports on the system, never loop through trying to open ports from 1 up to X catching/handling the errors from ports that don't exist.
For one things it's really slow, com port numbering is remembered so someones 5 year old laptop maybe up to assigning COM30 to new devices. So you have to scan to quite a high number.
Secondly windows sometimes gets a bit annoyed with you opening/closing ports and throwing exceptions fast like that.
And lastly, its just an ugly way to do it
(I think there was another problem as well, but i cant remember it)

[Bynun]

Had a quick look at the linux version of the driver and it looks pretty much the same, just link your program to ftd2xx.o, include the header and copy the code i posted. (change CopyMemory to memcpy)

It's alot easier then it looks

[Erwin Ried]

In .net/c# you can just use System.IO.Ports.SerialPort.GetPortNames(). This works in Linux too, with mono.


If you want to "detect" the arduino (in a non-console app) when is plugged-in, you can intercept the messages Windows broadcast for all processes:

Code: [Select]

        protected override void WndProc(ref Message m)
        {
            if (m.Msg == 0x0219)
                 // Check SerialPort here
        }

[ingep]

In Linux you could use the symbolic links in the directory: /dev/serial/by-id/

For FTDI you get a path like:
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A800JZ5I-if00-port0  (that is a symbolic link to /dev/ttyUSBx)

Where "FTDI" is manufacturer, "FT232R_USB_UART" is product description and "A800JZ5I" is the serial number. These values can be changed with the FT_PROG util from FTDI. You cold for instance change the product description to easily identify your device.