LabVIEW
FTDI drivers usage in Labview
Solved!
Well, a lot of the confusion comes from the fact that FTDI is making those chips for many years already. FTDI was started in 1992 and the first version of their popular chip was a pretty simple RS-232 interface chip that simply converted an USB port into a serial port. Nothing complicated, fancy or whatsoever but it turned out to be a quite successful idea, despite lots of problems about supporting it for all the different OSes.
They of course didn't stop there and worked on improving things, adding options for RS-422 and RS-485 interfaces. Subsequently they developed a sort of serial chip engine, a sort of very small dedicated microprocessor and added it as the MPSSE engine to their chip. Chips with this feature can support implemetations of all kind of dedicated serial and parallel interfaces with very little intervention from the host system. All you have to do is enabling the according MPSSE mode and configuring some parameters for the proper timing and polarity of the according signals and from there on the chip handles the low level timing of that interface mostly autonomous.
The interface to the host sytem (over the USB bus) only is concerned about sending it the outgoing data and receiving the incoming data and some high level control of the interface, without having to worry about the low level timing at all.
FTDI developed an interface driver that works for most of their chips as they all use the same or very similar USB protocol engine. This driver is the D2XX driver. It consists of the low level kernel device driver, which claims all the FTDI chips in the system and is often already included in the host OS nowadays, and a user space DLL that provides an interface to this kernel driver. FTDI does neither document the proprietary USB protocol used nor the kernel driver interface, without some pretty heavy non-disclosure agreements. Generally there is also no need to know these low level details unless you want to use an FTDI interface on your own embedded hardware design. But that would involve writing kernel mode drivers for your specific OS you are using on that hardware and that is definitely a very different league than programming in LabVIEW or trying to access a DLL from LabVIEW.
I did in the past experiment with reverse engineering the USB protocol and it proved to not be that difficult. I had a proof of concept driver that worked with VISA USB raw to directly access the FTDI chip but recent developments in OS driver deployment made this almost entirely useless as you can only install fully signed device drivers in modern OSes and I have no intentions to go and buy a signing certificate from a signing authority for something like that and pay the yearly fees for it.
For your purposes you want to almost certainly use the D2XX driver DLL from FTDI. It's the basic interface to most chips from FTDI. For simple RS-232 or RS-422/485 use it is all you need although it's a bit more work and low level handling than what you might be used from VISA programming a serial port.
If you want to use a more dedicated interface mode of those chips such as I2C or SPI you should look at the MPSSEE driver from FTDI. This is a DLL too and sits on top of the D2XX driver, so basically calls it. It switches the chip into the according MPSSE mode on initialization and takes care about most of the configuration details and possible differences between different versions and chip models. It wouldn't be impossible to implement the entire MPSSE driver fully in LabVIEW and call the D2XX driver directly.
Now the drivers on the FTDI site are fine as far as the DLLs go. The LabVIEW side of things however is another story. They were developed in LabVIEW 6 or 7 and by someone who knew just enough about DLLs and LabVIEW to be dangerous, but not enough to know that he was dangerous 😀. They are in several points not quite right and therefore can lead to crashes of your application when used.
If you want to use the chips in RS-232 mode and even mostly RS-422/485 mode you should just rely on the FTDI Windows device driver and let it convert everything into a Windows serial port and access this through the VISA serial port functions in LabVIEW. This is by far the most painless scenario.
If you plan to use a chip in I2C or SPI mode you will be a lot happier if you go with the drivers on Lavag.
https://lavag.org/topic/19453-cr-mpssedll-labview-driver/
https://lavag.org/topic/19993-cr-mpsse-spi/
As to your questions:
1) SPI functions are implemented in the MPSSE dll and call ultimately the D2XX DLL for anything they do.
1.1) An API is an Application Programmer Interface. It's the interface definition of a driver or library that an application can call to use the drivers or libraries functionality.
1.2) What functionality do you want to use? What interface mode? With what chip?
2) This is simply an integer number whose value indicates an error if not 0. The differnt values and their meaning are declared in the D2XX header files and documented in the D2XX Programmer Manual. It's very similar to the "code" element in a LabVIEW error cluster.
3) The FT_HANDLE is certainly defined in the header files for the D2XX driver. It basically comes down to a pointer sized integer value. Its exact meaning is private to the DLL and should not be attempted to be interpreted beyond what is documented. It could be an array index into a data array in the DLL where the information for each open connection is stored. It could just as well be a real memory pointer that directly points at the memory that holds that information. Or it could be a combination of both or any other possible imaginable concept.
For LabVIEW this means that if you are in LabVIEW 2009 or newer you definitely should configure the according Call Library Node parameter to be a pointer sized integer and for the LabVIEW front panel it should be an (unsigned) 64-bit integer. Unsigned is here in brackets as it does'n't really matter if you use signed or unsigned as long as you keep it consistent throughout your LabVIEW VIs, also for the (unsigned) pointer-sized integer configuration in the Call Library Node.
4) FT_Read_EEPROM() is meant to access the programmable memory on the FTDI chip itself, which can be used to customize the boot mode operation of the chip. Unless you want to design your own device you do want to stay away from any of those functions as far as possible, as it will be either useless (read operations) or even dangerous (if you overwrite this memory with trash data your FTDI interface may startup in a very different mode or simply be unusable).
Remember, words are just words. Different people use them for different things and sometimes they abuse them. 😀
Generally a Software driver is a software library of functions to communicate with some device. This can be a hardware device, a virtual device or a software application providing some functionality.
The API is the interface specification to this device library, or any function library for that matter, that is considered stable for a certain range of versions, which can be a single version too.
Don’t get to much hung up on specific words. Both the FTDI DLL and the LabVIEW VIs directly calling it are usually called drivers, just on different levels. Also the FTDI driver itself really consists of two drivers, the kernel device driver and the user space wrapper that applications call, including the LabVIEW wrapper (driver) VIs.
Hi!
Coming back quickly to this,
I've been trying to use the library you suggested above. It looks really good, except I'm having some troubles using it, for some reason I can't write a simple command to my device, I#ve noticed something's off, but I also probably use it wrong:
In the "Test.vi" Benoit is providing, there's the GetChannelInfo.vi. Problem is that my Description is wrong, I should receive "C232HM-DDHSL-0" (which is my ftdi device) but instead I receive this:
Turns out the device, when requested sends back, sends back a long list of 8bits which he builds an array with, transforms it in unsigned 8bits integer array a then in a string:
Now, aestetically it is problematic, but I can the word in the end, BUT can it be an issue for my application and more importantly, what could make it read some noise after my device info?
I attach his library for reference.
I've just realized something for the operations of write and read that I'm struggling using, so I'll just try it before asking anything 😄
Thanks in advance.
VIncent.
Have you read the entire thread on LAVAG? Or just downloaded the initial library and tried to be happy?
That issue is mentioned for at least the read function and a fix is proposed later on. Mr. Benoit doesn’t currently seem to have access to a LabVIEW installation so the original library itself hasn’t been updated.
It may seem a lot to read the whole thread and anything else your google foo can come up with but when dealing with calling external code in LabVIEW you want to get every possible tidbit you can get. It’s a very hard problem and even experts like me tend to make errors in the first implementation attempt. Most of what you can find on the net for free however is not expert quality and sometimes outright wrong (this doesn’t apply to this library although there are things that could be done more elegantly, but a lot of what is posted online is from people like you who struggle to even understand the basics).
The original D2XX library on the FTDI site is no exception to this.
That is also why it is so often actually cheaper to pay a little more for an NI device and be done with it. Their drivers are as good as it can get and when programming your application you can concentrate on the actual problem at hand rather than trying to get a piece of hardware to start to even work from LabVIEW. If you account for that NI is only really getting expensive if you plan to create something that is going to be rebuild 1000 times or more. One thing about integrating hardware through DLLs yourself is that you are by far not done when things start to work. At that point you have effectively spend maybe 5 % of time that is needed to make the whole thing a stable interface that is never gonna corrupt your memory, which can or won’t crash your program, depending on the current moon phase! 😀
The FT200XD does not seem to use an MPSSE engine inside the chip but is a specifically designed interface I2C chip that does not support anything else but I2C. It is supported by the D2XX driver however.
So you will have to get some support from FTDI about how to access this chip through the D2XX driver API directly but most likely can't use the MPSSE driver on top of it. At least the datasheet mentions absolutely nothing about MPSSE support.
