FTDI chips VCP or VX drivers

mook Jonhon · 2018-07-17T23:53:14+00:00

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

Jul 17, 2018 63 Replies

Rate this thread:

Rob 8 years ago

Even in a single process and with a normal diskfile it can be useful to have the file open multiple times (on different fd) e.g. to read it at one position and write it at another position without having to seek between te positions all the time. (a single fd has a single read/write position)

This can be done in the same thread or in different threads in the same process. Having threads in the process can be another reason to want to open it several times, so you don't have to needlessly interlock the threads to share the access to the file. (e.g. when one thread reads and another thread writes the same file at a different position)

Vote

Dave Platt 8 years ago

Yup. The whole Unix file-descriptor-and-process model accomodates this, in several ways.

Consider the whole function of dup() - take an existing file descriptor, and "clone" it into a different and independent file descriptor while leaving the first one open.

Consider fork(), which spawns off a separate child process, and clones _all_ of the existing file descriptors from the parent process into the child.

Neither of these is (technically) "opening" the file more than once within a single process... in both cases you only call open() once... but they all have a similar effect, of providing two or more independent access paths to a single underlying file.

Unix/Linux/POSIX would be a very different beast, if these APIs didn't work that way.

The knowledgeable POSIX programmer is expected to be aware of these things, and either (1) not use them when not needed, (2) be aware of the need to close() descriptors you don't need, or (3) use them appropriately with the proper safeguards e.g. locks and semaphores and mutexes and so forth.

No different than working with a propane torch, or a soldering iron, or a hacksaw, or a hammer. You have to know which end to grab and which end not to grab :-)

Vote