FTDI driver library wrapper VIs for NI RT Linux

[smarlow]

Since FTDI chips are recognized by NI RT Linux out of the box these days, I assume the OS comes packaged with the FTDI chip drivers for Linux.  Are there wrapper VI's available for the RTOS for calling the driver library?  If not, does anyone know off hand where the external driver library is located so I can set up the Call Library function for it?  Thanks in advance.

[Rolf Kalbermatter]

15 hours ago, smarlow said:

Since FTDI chips are recognized by NI RT Linux out of the box these days, I assume the OS comes packaged with the FTDI chip drivers for Linux.  Are there wrapper VI's available for the RTOS for calling the driver library?  If not, does anyone know off hand where the external driver library is located so I can set up the Call Library function for it?  Thanks in advance.

That's not how those drivers work. The device drivers for the FTDI chips (the RS-232422/485 at least) installs in Linux as a serial port driver. That means that they get installed as serial ports under /dev, usually as /dev/ttyUSB* with increasing number and can be accessed through NI-VISA just as any other serial port. There is no exported API in these drivers that you can  interface to with a Call Library Node.

If you want to access the MPSSE engine in those chips (to do bit bang, I2C or SPI for instance) instead of the Virtual Comm Port interface the standard Linux driver provides, you'll have to hunt down the D2XX driver for your Linux distribution and install that instead.

https://www.ftdichip.com/old2020/Support/Documents/AppNotes/AN_220_FTDI_Drivers_Installation_Guide_for_Linux.pdf

This document is from 2017. Your Linux distribution may have changed things considerably in the meantime, so your mileage may vary, but the general distinction between standard VCP and FTDI proprietary interfaces to the chip through the D2XX driver remains.

There exists LabVIEW libraries to interface to the D2XX shared library and also to access the two FTDI provided wrapper libraries to do MPSSE SPI and MPSSE I2C but they are heavily Windows minded, meaning that they try to link to the .DLL version instead of the .so and there might be other API specific details that differ between Windows and Linux. Also last time I checked the two MPSSE VI interfaces here on LAVA were not cleanly prepared to handle 64-bit shared libraries as they were developed when 64-bit LabVIEW was still in its early days and nobody bothered to install and use that.

Edited March 19 by Rolf Kalbermatter

[smarlow]

It is my understanding that the VCP interface sits on top of the D2XX driver.  The EEPROM for any FTDI chip can be programmed to optionally load the VCP driver or not.  The device I am dealing with is programmed to not load the VCP.

Edited March 19 by smarlow
grammer

[smarlow]

After reading the AN you posted, it seems that for the Linux OS, the VCP/D2XX are not connected.  Does this mean that if one of my FTDI chips needs the D2XX driver, that none of my VCP devices can be used?

[Rolf Kalbermatter]

27 minutes ago, smarlow said:

After reading the AN you posted, it seems that for the Linux OS, the VCP/D2XX are not connected.  Does this mean that if one of my FTDI chips needs the D2XX driver, that none of my VCP devices can be used?

Not just for Linux. In Windows it is the same.

But I'm not sure, I never used the D2XX driver on Linux until now. My understanding is that as long as you do not open a VCP interface for a device, the hardware is not really in use and should be accessible by the D2XX driver. In the worst case you may have to configure udev or whatever is used on your system to manage automatic mounting of USB devices, to not install a particular device as tty device, for instance based on the serial number or similar. By default most Linux systems are nowadays configured to automatically install any device they have a standard driver for as the according device. In the past this was often the opposite where you had to mount the device manually or add an according rule to udev for automatic mounting at boot time.

Edited March 19 by Rolf Kalbermatter

[smarlow]

The device originally came with an FTDI VID, and a "custom" PID from the range FTDI assigns to its volume customers.  This is to prevent the device from interfering with the setup of other devices that use the same chip.  This unrecognized PID caused the device to show up in RT Linux as a VISA USB RAW device, which is the default for unrecognized VID/PID USB devices on NI RTOS.  I have some experience working with FTDI chips in the past on the Phar Lap RTOS.  I once wrote a set of drivers for the FT232R using the FTDI packet specs and the USB control pipe and VISA read/write functions.  However, those drivers don't work for this particular chip, which is different model.  The mfg. agreed to change the PID to the standard (the VCP load option will still be off), and I am trying to prepare for dealing with the chip without the VCP or the USB RAW drivers.

[Rolf Kalbermatter]

16 hours ago, smarlow said:

The device originally came with an FTDI VID, and a "custom" PID from the range FTDI assigns to its volume customers.  This is to prevent the device from interfering with the setup of other devices that use the same chip.  This unrecognized PID caused the device to show up in RT Linux as a VISA USB RAW device, which is the default for unrecognized VID/PID USB devices on NI RTOS.  I have some experience working with FTDI chips in the past on the Phar Lap RTOS.  I once wrote a set of drivers for the FT232R using the FTDI packet specs and the USB control pipe and VISA read/write functions.  However, those drivers don't work for this particular chip, which is different model.  The mfg. agreed to change the PID to the standard (the VCP load option will still be off), and I am trying to prepare for dealing with the chip without the VCP or the USB RAW drivers.

USB Raw will of course require your LabVIEW code to use the right USB control endpoints, pipes and binary bit patterns and if the new chip is not 100% upwards compatible with the old, that means a different driver (or one with conditional code based on the chip as detected at communication initialization). Without a detailed specification of the low level USB protocol for the new chip that is not gonna work.

Using the FTDI provided D2XX driver should fix that as that driver somehow makes sure to talk to each chip as needed, as long as FTDI supports that chip with this driver. Some of the FTDI chips need a different driver such as D3XX. It's definitely easier than trying to do USB Raw communication but requires a bit of C programming knowledge to be able to figure out the proper Call Library Node configuration for each function. The existing LabVIEW wrapper as provided from FTDI is outdated and only supports 32-bit, possibly even with a bug or two even in 32-bit, but it is a starting point.With a little love it can definitely be made to work for modern LabVIEW in 32-bit and 64-bit and for Windows and Linux.

I may revisit my earlier  attempts of writing a fully LabVIEW OOP based solution for this with pluggable low level driver using USB Raw or FTDI D2XX and a pluggable high level driver for the I2C and SPI MPSSEE modes of the chips that have such an engine build in, but I haven't currently a use case for this and that tends to push this project always towards the end of the "projects that are nice to develop" queue.

[ShaunR]

41 minutes ago, Rolf Kalbermatter said:

I may revisit my earlier  attempts of writing a fully LabVIEW OOP based solution for this

Booooh! 

Edited March 21 by ShaunR

[Rolf Kalbermatter]

3 hours ago, ShaunR said:

Booooh! 

For this type of functionality it is absolutely not Booh. 😀

It is OOP in the sense that it uses LabVIEW classes as an easy means of instantiating different driver implementations at runtime. One interface (or a thin interface class in pre LabVIEW 2020) and then a child implementation to call the DLL, one to call VISA USB Raw and possibly others. On top of that one driver as a class to do MPSSE I2C and another for MPSSE SPI. That way it is very easy to plugin a different low level driver depending what interface you want to use. D2XX DLL interface on Windows, D2XX so interface or D2XX VISA USB Raw on Linux and LabVIEW RT. With a little extra effort in the Base Class implementation for a proper factory pattern implementation, the choice which actual driver to load can be easily done at runtime.

I did the same with other interfaces such as Beckhoff ADS, one driver using LabVIEW native TCP, another interfacing the Beckhoff ADS DLL, one for Beckhoff ADS .Net and one for Beckhoff ADS ActiveX, although the ActiveX one has a bug in the type library that tells LabVIEW to use a single reference byte as data buffer for the read function and there is no way to overwrite the type lib information except patching the ActiveX DLL itself. The Typelib should declare that as an array datatype but instead simply declares it as a byte passed by reference. The same thing for a C compiler but two very different things for a high level type description.

The base class implements the runtime instantiation of the desired driver and the common higher level functionality to enumerate resources and read and write data IO elements using the low level driver implementation. For platforms that don't support a specific "plugin" you simply don't install that class.

Edited March 21 by Rolf Kalbermatter

[ShaunR]

1 hour ago, Rolf Kalbermatter said:

With a little extra effort in the Base Class implementation for a proper factory pattern implementation,

Booh with bells on.  Hello 7 hr build time. 

[Rolf Kalbermatter]

4 minutes ago, ShaunR said:

Booh with bells on.  Hello 7 hr build time. 

The whole ADS library overhead in an application adds about 0.0something seconds to the whole build time of any project. As long as you have a linear hierarchy in object class dependencies, there is virtually no overhead at all beyond what you would have for the involved number of VIs anyhow. Once you happen to create circular dependencies the app builder will go into making overtime to resolve everything properly and your build times start to grow into the sky. At some point you can get all kinds of weird build errors that are sometimes almost impossible to understand.

Untangling class hierarchies is in that case a very good (and usually also extremely time intensive) refactoring step to get everything to build nicely again.