FTDI COM Port ID using C# on windows

krillis

Hello Folks,

I am trying to write a little program that configures a prop board that is connecting to the host PC using an FTDI 245 part. I also have another microcontroller on this board that is sitting and watching usb traffic and interfacing with the propeller and other components.

My chief concern is how to find the ftdi part from a windows C# environment. I can open a serial port and start walking thru each com port until something answers on the board, but I would like a real solid way to id the ftdi part, and then know exactly what COM port it is setup on. For example, think about Parallax's IDE for the propeller. How does this tool ID the eval board?

So I browsed around on FTDI's site, and saw the ChipID stuff. Very cool, but there doesnt seem to be an interface to get the COM port out of this. I can read/write the eeprom on the FTDI part, but I dont know which COM port windows has assigned to the darn thing.

Anybody out there know a good approach, or maybe someone from parallax can tell me how they do it in the prop IDE.

Thanks,

Krillis

hippy

The PropTool simply scans each serial port asking if a Propeller is there and looks for a response. You could probably use the Registry to find which ports were VSP's, whether they were using FTDI drivers or not and which COM port is assigned but you'd never have a solid solution if there were more than one FTDI device attached.

I have no idea how to do that Registry search on XP but I've done it on 98SE to find VSP's I was using there and it seemed to work reliably.

krillis

Can someone from Parallax tell me what they do with more detail, so I can try to set things up to do the same?

I was hoping they were taking advantage of the ftdi capabilities in the driver to read the ChipID or some kind of description field, and then using that info to discover the exact com port.

Parallax? Can you help?

Thanks,

Krillis

Jeff Martin

Hi Krillis,

Hippy is correct, the Propeller Tool determines what serial ports are present on the system, then it opens each of them, one at a time, and executes the Propeller Chip connection protocol (basically a toggle of the DTR control line and transmission of a stream of data that the Propeller Chip recognizes and responds to) to determine which port has a Propeller on it. We do this, rather than looking for an FTDI-specific connection, because the Propeller could be connected to the PC via any RS-232-type serial connection; the FTDI chip is merely a "serial" bridge we provide to translate between RS-232 and USB, and back again.

We don't write in C#, but I can tell you the Win API's we use to achieve this.

We use the SetupDI (SetupAPI) methods provided by Win2K and above to determine what serial ports are present on the system. I "highly" recommend you use these API calls from your C# application, because reading the appropriate parts of the registry directly only works if the user that is logged in at the time has sufficient security permissions to access hardware information in the registry... and many times they do not. We had this problem in the BASIC Stamp Editor for a long time before we finally learned how to do it properly in WinNT-based implementations of Windows.

You can find the actual C code that I used as an initial template to write our calls to SetupAPI here: http://support.microsoft.com/kb/259695
In our final implementation,
1) We first call SetupDiClassGuidsFromName using 'PORTS' as the first argument to get the GUID for the Ports class of devices.
2) Then, we call SetupDiGetClassDevs with that GUID (returned by the previous call) as the first argument, and with DIGCF_PRESENT as the last argument to get a Device Info List structure that is a handle (pointer) to a list of devices that fit the "present Ports" category.
3) Finally, we call SetupDiEnumDeviceInfo with the DeviceInfoList as the first argument, and the index of the item (0..n) we're interested in, and for every successful response, we call SetupDiGetDeviceRegistryProperty using SPDRP_FRIENDLYNAME as the third argument to get the "friendly" name of the port, which is exactly what appears in Device Manager's Ports (COM & LPT) listing for each present port on the system (serial ports and parallel ports). We ignore the parallel port entries.

I think I remember other system constants similar to SPDRP_FRIENDLYNAME that you can use to retrieve the device driver information, so that you can determine if it's an FTDI-based device and what it's hardware instance ID is... but we don't do that, so I can't really provide details there.

Search for "SetupDI" or "SetupAPI" on msdn.microsoft.com for more extensive information on the Setup Device API.

By the way, when I had to figure out how to do this stuff, I couldn't find ANYONE with this knowledge willing to talk; so the above is the result of perhaps 100 hours of my research and experimentation and I don't know how many millimeters of lost hair line. I hope I've saved you a lot of unnecessary loss of time and hair. Good luck!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.

krillis

Thanks for the detailed reply, Jeff. I will be going down this path for my application, so if I find alternatives that may work better in c#, I will post the news here.

Thanks again,

Krillis

Bob Lawrence (VE1RLL)

c# serial port enumeration

- It should return you a list of valid serial ports

string[noparse]/noparse SerialPortNames = System.IO.Ports.SerialPort.GetPortNames();
=================================================================

ID DLL :

Example code showing how to use the FTChipID DLL is available for the following platforms:

*

C Sharp (requires .NET interface DLL to be included in project)


http://www.ftdichip.com/Projects/FTDIChip-ID.htm