FTDI chips VCP or VX drivers

Looking into a test box that will need a USB input.

I have always taken the easy route and used a Virtual Com Port chip form FTDI and run it to a SCI port on a microcontroller.

It appears I can use the chip as a native USB device instead of a virtual Com Port and I was curious as to the advantages to this approach.

Have any of you used a FTDI as a native USB device in Windows 7 or 10 where the native windows driver found and installed the device once plugged in. (no VDP driver install necessary)

When programming the windows application (Labview, C++ etc) how do I find and access the FTDI chip. Does USB justmake it look like it is on part ofthe machine and I can talk directly to it (transparent link) or is there some driver/handle that needs to be interfaced to.

I'm new for all this stuff so basic information is all I need.

Overall, besides not having to install the VCP drivers, is there any advantage to using the FTDI chip in native mode?

thanks

Reply to
mook Jonhon
Loading thread data ...

The big advantage is that you don't have to go chasing com ports, your software can connect automatically.

I've done this in VB using the D2XX drivers from FTDI. I'm no PC software expert, so it can't be too hard. What one fool can do, so can another.

Basically, FTDI provide a load of VB functions (or C++ whatever) which you call from your software. These do things like open the device, set baud rate etc. The FTDI chip can be programmed with an ID string (using FTprog from FTDI)) so that you only open something called 'Mook's Widget' or whatever with no reference to a com port.

Functions are provided for data read, write etc.

It's more complicated than a VCP, but much more professional.

Cheers

--
Clive
Reply to
Clive Arthur

the only issue is that you need to reprogram every FTDI chip with your string ID.

Bye Jack

Reply to
jack4747

You don't *have* to use this facility. But it is useful, you can program a serial number too.

If you're making lots, FTDI would do it for you, but I suspect if you're making lots you'd use something cheaper.

Cheers

--
Clive
Reply to
Clive Arthur

Provided your customers are amateurs. ;)

It's closed-source only, which is a problem--you have to rely on the manufacturer for bug fixes etc.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

... and you still need to install the driver! I think the only advantages are:

- no intermixing with existing COM port numbers so you know where to look

- vendor lock-in because your device works only with your software and your software works only with your device

I once bought a "programming cable" which is merely a TTL Serial to USB cable with a connector matching my equipment, and found it was not recognized under Linux. It would work only with the Windows sofware. But soon enough I found that it was merely such a FTDI chip with re-programmed ID, found the software to re-program it, set it to the standard ID and then it was recognized by Linux and I could use open software with it (via a TTY device).

Reply to
Rob

Yes, the whole thing is dodgy. Chip manufacturers may change things, the there's Windows, then the compiler writers. Potential bugs everywhere. It's a miracle anything works at all.

Cheers

--
Clive
Reply to
Clive Arthur

One approach to the COM port problem is to have the gizmo spit its ID string out the UART periodically when it's idle. Enumerate the ports, look for the one with a valid ID string, and you're done.

Using putty or another terminal emulator would do this the manual way.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

Installation headaches are some of the worst bugs of all, because they hose the very first experience your customer has with your product. That's the problem FTDI solves. No one, amateur or professional, is immune to driver installation hassles.

There isn't much room for bugs in the FTDI ecosystem in any event. Their stuff Just Worked(tm) 10 years ago and has continued to do so ever since. The problem they solve isn't a technical one, anyway, but a spiritual one. They intercede with an omnipotent but indifferent entity -- i.e., Microsoft -- on behalf of the user, no doubt with sighs too deep for words.

FTDI sucks in other respects, such as punishing end users for the sins of their vendors, but I'll still use their (genuine) parts whenever I can.

-- john, KE5FX

Reply to
John Miles, KE5FX

Customers want to plug in their very expensive box-of-tricks like it was a mouse. Com ports are great for development, and ideal for cowboys.

Cheers

--
Clive
Reply to
Clive Arthur

We use the FTDI chips a lot. We just make the gadgets look like serial ports. Every box responds to the "ID" command with its model number and serial number. It's easy to scan all the serial ports and find our boxes.

In a multi-box system, you need to identify the boxes by serial number, no matter which port or hub they are plugged into. S/N 101 may be controlling a water pump and 102 may be wired to a detonator.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

I *hate* that kind of software! Once I had 10 COM ports in the system, with all kinds of equipment and some even used as "bit banging" generic I/O ports. Several programs were running as daemon (service) with a port open and configured.

Evey once in a while a "new" program would do such a stupid scan and upset all the settings and the state of the running software. E.g. when starting the network config program that would helpfully locate modems by setting all ports to 9600 baud one by one and sending AT to each of them. It did not even bother to set the port back to the setup it had when first opening it...

Reply to
Rob

That is probably why FTDI offer that mode. It doesn't really change anything in the device, it just changes its device ID so it isn't recognized by the normal driver that installs a serial (COM) port, and then you can distribute a dedicated driver that registers it as some nonstandard device. It is still a serial port, but the system does not put it in the pool of serial ports so it is easier to find back.

Reply to
Rob

And then it may happen that people "copy" the chip, the original manufacturer revenges by modifying the driver to look for and "destroy" those copies (by setting the device ID to something the driver does not recognize) and then distributes this "driver update" as an "important update" via Microsoft's update service...

Reply to
Rob

Yes, I have a load of 'Prolific' USB serial ports which I use for diagnostics on a multi-processor system. I didn't know they were fakes. Now every so often I have to re-load the old driver from 2008 because Windows keeps updating it.

Cheers

--
Clive
Reply to
Clive Arthur

Well, if your customers are all on Windows, God bless. We're an all-Linux shop here, and our customers are mostly technical folks.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

There's more opportunity for collisions that way, though. Somebody else's box might interpret "ID" as "ignite detonator". ;)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

With Linux there still is the problem that by default the system will assign the devices names like /dev/ttyUSB0 /dev/ttyUSB1 etc with a "random" order determined by the order of plugin, and different after a reboot. When your customer has added your device while something else is already plugged in, it will be /dev/ttyUSB1 but after the next reboot it could be /dev/ttyUSB0 when that first device is not connected during the reboot, or even when it is! (the two would just swap on reboot)

It is possible to work around this, but the way to do it would be considered "black magic" by most users (writing udev rule files) and before you know, the systemd folks have declared it "deprecated". (as they always do when they find some feature they find difficult to implement in their do-it-all program and don't immediately see the need for in their limited "all users work on a laptop" world)

One place where it is explained:

formatting link

Reply to
Rob

Having the device squirt its ID string out the UART when idle is a pretty complete solution to those problems. You just connect, listen for a bit, then move on.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

How does a program open an already-open port?

Tim

--
Seven Transistor Labs, LLC 
Electrical Engineering Consultation and Design 
 Click to see the full signature
Reply to
Tim Williams

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.