FTDI FT232H VCP com port commands (not 2XX driver)

[Ron1two3]

I'd like to talk to FT232H chip using COM3 port that was created when I installed the chip driver on windows 10. 

Putty and LabVIEW natively knows how to commutate with a real or fake COM port.  Note: The 2XX drivers with LabVIEW have been a three day nightmare (multiple options tested , each in a different failure , most with compound failures)  

I suspect (hope) the COM port is good. However I can type anything into Putty COM3 terminal and nothing comes back. I was hoping for an text error message or even gibberish (binary response), but no luck.

The big goal is to setup FT232H as an I2C master and send a couple bytes to an I2C address and read a couple bytes back (LabVIEW).

Lesser goal is to prove this COM3 port is alive (via Putty or LabVIEW); is there anything I send send and get some response back?

I did try to register for FTDI forum, but I couldn't prove I was a human. 

[GerdW]

Hi Ron,

---

@Ron1two3 wrote:

Lesser goal is to prove this COM3 port is alive (via Putty or LabVIEW); is there anything I send send and get some response back?

---

Attach a device to that serial port, then send a (valid!) command to that device and read the answer of that device…

Is there anything attached on your COM3 port? What kind of answer do you expect if there is no device attached?

[crossrulz]

---

@Ron1two3 wrote:

I suspect (hope) the COM port is good. However I can type anything into Putty COM3 terminal and nothing comes back. I was hoping for an text error message or even gibberish (binary response), but no luck.

Lesser goal is to prove this COM3 port is alive (via Putty or LabVIEW); is there anything I send send and get some response back?

---

If nothing is one the other side, you can't expect anything to come back.  A simple test would be to connect the RX line to the TX line.  This will not be a loop back and whatever you write you will read right back.

[Ron1two3]

Gerd,

Thanks for the quick response. With the USB to FT232H adapter pugged in, there is a virtual COM3. With the adapter unplugged from PC , COM3 vanishes. COM3 is not real, but it should be able to pass data.

https://www.digikey.com/en/products/detail/ftdi-future-technology-devices-international-ltd/C232HM-D...

FDTI has C++ code examples to talk to 2XX driver, but no example's of data sent on COM3 serial port as a pipeline to the FT232 chip on the adapter. I do not know any valid commands.

I'd prefer not to call complied C++ application from LabVIEW. Perhaps in a couple weeks when all else fails.  

[rolfk · Accepted solution]

The VCP option for the FTDI chip simply creates a serial port. It is a transparent port and you can NOT talk to the FTDI chip in that way. Anything you send to the serial port is send out on the digital side of the chip either as TTL (3.3V or 5V) or as RS-232 or RS-485 port to whatever is connected on that port. If you do not connect a device to this side there is NOTHING you can talk with, unless you do the loopback test as explained by crossrulz. In this way whatever you send out through the port will be possible to read back through the serial port. You can NOT use the serial chip for SPI, I2C or any of the other special interface modes with this driver version.

The FTDI D2XXX driver is a DLL that interfaces to the chip on a different level. You can NOT use the FTDI VCP driver and the FTDI D2XXX at the same time for the same interface. The FTDI D2XXX allows to use the special chip modes that implement the SPI or I2C interface. You MUST use the LabVIEW Call Library Node to interface to that DLL driver.

Most FTDI chips support an on-chip MPSSE (Multi Protocol Synchronous Serial Engine) that is a small microprocessor like system to implement specific serial interfaces such as I2C and SPI without having to do any interface timing from the application level. FTDI distributes an MPSSE DLL library that interfaces to the FTDI D2XXX DLL and provides a ready made interface to configure and use the on-chip MPSSE for I2C or SPI operation. There are two implementation of LabVIEW libraries for this MPSSE DLL on lavag.org, one for the SPI interface of that DLL and the other for the I2C interface. If you want to use one of these two you really should use this if you do not want to be bothered to much about setting up Call Library Nodes yourself.

[Ron1two3]

Averna,

Ok, so COM port is not the way to go. 

I do see the lavag solution. It seems to be missing a file. I will try to fix this missing file and try this route. Thanks for the help.  

 

[rolfk]

That's the header file for the DLL. It is part of the FTDI package but only needed if you want to read about the function prototypes when trying to make changes to the Call Library Node configurations. To let LabVIEW call the DLL it is totally unnecessary.

And read the ENTIRE thread there are multiple comments about things that should be improved in the VIs. The library as is is a good attempt but not everything is fully correct.

[Ron1two3]

This I2C project worked well for me once I changed to a 32 bit version of LabVIEW.