Virtual COM port (FTDI chip set) - PC lock up using LV & Visa

[Chris Harden]

The FTDI virtual com port chips (such as the FT2232C device) are industry standard USB com port chips, and yet communication with them via LabView/Visa appears to result in occasional lock up of the PC.  CTRL/ALT/DEL does not work, you have to reboot the PC to get out of it.  What is the problem and why cannot the Visa library accomodate this industry standard chip? What is the work around (apart from buying NI hardware - not an option in this case).

[Ray.R]

**** deleted ***

Message Edited by JoeLabView on 07-24-2008 09:42 AM

[Ray.R]

Can you post your code?

R

Message Edited by JoeLabView on 07-24-2008 09:43 AM

[Dennis_Knutson]

I've used a couple types of USB-RS232 adapters (single and multi-port) and had the FTDI chip set on some in-house designs and have not had any lock-up problems. What OS and version of NI-VISA are you using? do you see the same problem on a different pc?

[Chris Harden]

Hi Dennis,

This is running on a WinXP PC, LV7.1 and Visa 4.3.  I have seen other postings which indicate there could be a Visa related problem with what NI claim are 'non standard' implementations of the virtual comms port protocol.  I haven't yet rried it on my Vista laptop, but may do so over the weekend.

[BENIO]

Guys,

this topic might be interesting for me since I have to write SW for my appliaction using the FT2232C USB to I2C.

Is there anybody having some example code to drive I2c protocol?

Regards,

[Ray.R]

I2C is a bit different than your COM port communication.

It uses a clock and data line.  The clock frequency has to be within the spec of the particular device / mfg.  You will find the protocol on the data sheet for the device, which means any headers, memory locations, registers, etc depending on the type of device.  There are many devices, such as temperature sensors, SEEPROM, etc.  From the hardware side, you may also need to set the ID of the device, which is usually 3 pins that you tie to Vcc or Gnd.  If it is a memory device, you may need to index which block you are writing to. 

I've only written firmware for I2C devices using VxWorks.  The clock was provided by the card.  The FPGA also provided the interface for the data, so the SW just wrote to it.

Now, to describe how to do this using LabVIEW would require that you provide more details about the interface.  Does your USB to I2C provide the clock for you? it probably does.  If it is a product that you purchased, it must come with an API or some explanation on how to communicate with the I2C device.  What does it say that you need to do in order to communicate with it?  Once you tell us this, we might be able to suggest how to proceed with LabVIEW.

R