FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Pages: [1] 2 3 ... 10
 1 
 on: Today at 01:28:11 PM 
Started by piezontm - Last Post by FTDI Community
Hi,

We will have a look through your details provided but here is a link to the latest beta and source code:
LibMPSSE

Best Regards, FTDI Community

 2 
 on: Today at 11:05:22 AM 
Started by MauroDiamantino - Last Post by FTDI Community
Hello,

There should not be a need to add a delay. If FT_GetQueueStatus returns a value, that value should be able to be read straight away.

What are the fail codes that you are seeing, returned by the function calls?

See the D2XX Programmer's Guide for more information and software examples.

If you want to send your code for review, see Contact Us for your local support office.

Best Regards,
FTDI Community

 3 
 on: August 22, 2019, 09:56:51 AM 
Started by GF1981 - Last Post by GF1981
Hi everybody,

i'm using an USB Counter by Hengstler (Model Tico 773 542) which is USB.
i use on windows 10 x64 computer and i poll requests via the virtual com port to read the counter via a command provided by Hengstler.
The normal scenario is:

- computer is on
- counter is on
- i can read it

if i switch off the computer (restart or full power off) and after that i restart the windows 10 then:

- com port exists on device manager
- i cant read due to Timeout

looks like TX it's not there somehow.
only doing a reset (switch off and on) of the counter then i can read again.
i tried with several drivers (2.12.26 / 2.12.28 / 2.08.24) but still the same issue.

can be the case that the chipset it's not reacting if not used for a while via the USB port ? do you have any issue like that on other devices ?

Thanks for support

 4 
 on: August 21, 2019, 08:32:06 PM 
Started by MauroDiamantino - Last Post by MauroDiamantino
Hello people, I'm working with a USB device which incorporates a FT232R chip. I'm using the D2XX library to communicate with the device from a custom C++ software. The data is read as 17 bytes at a time, and to ensure the reading doesn't fail it is queried the number of available bytes inside a loop until this number is greater or equal to 17. The number of available bytes is got with the function FT_GetQueueStatus(). After of facing many errors, I discovered it was necessary to put a delay of 70ms approximately between the calling of FT_GetQueueStatus() which states that the necessary number of bytes are available and the calling of FT_Read(), to avoid reading errors.
Why did I have to put that delay? Isn't it supposed if the needed bytes are available, the reading operation shouldn't fail? Is it the same to use FT_GetQueueStatus() or FT_GetStatus() to get the number of available bytes in the receive queue?

 5 
 on: August 21, 2019, 06:05:24 PM 
Started by piezontm - Last Post by piezontm
I am having same problem as https://www.ftdicommunity.com/index.php?topic=250.msg804#msg804 with the 0.4 version of the MPSSE library.  However, I have found that the fast read/write option runs without the FT_IO_ERROR but there is still a long timeout on the final read operation before returns.  Also, the data returned is not correct, yet a Scope/Protocol Analyzer shows the correct data on the bus.

As the original post, I too compiled the 0.4 MPSSE lib against the 1.4.8 D2xx driver.  I did modify the MPSSE lib to:
  • change the timeout from 5s to 2s (for capture purposes)
  • added timestamps to DBG to add a timestamp

Test Use Case

My test use case is slightly different:
Start, hD0 [ h68 | WR ], h01, h00, Stop
Start, hD0 [ h68 | WR ], h02, Stop
Start, hD1 [ h68 | RD ], hAD NAK, Stop
Start, hD0 [ h68 | WR ], h03, Stop
Start, hD1 [ h68 | RD ], h28 NAK, Stop

Basically:
WR 01 00
WR 02
RD 1 byte (expect 0xAD)
WR 03
RD 1 byte (expect 0x28)

Normal Read/Write

I connected a Scope/Protocol Analyzer for the "normal" read and write mode (non-fast) and see nothing obvious ("ftdiNormalWR_ioError_filtered.pcapng"). The attached image "ftdiNormalWR_ioError.png" is the only portion of the data transfer seen on the bus.  One strange part of the trace is the duration of the stop operation as well as there are no errors seen.  The other is why the transactions stop.

My DBG trace was similar to the original post from https://www.ftdicommunity.com/index.php?topic=250.msg804#msg804.  See the attached log "ftdiNormalWR_ioError.log".  NOTE: The timestamps are on the far left in msec.

Fast Read/Write

When running the above use case using the fast read/write option the signals look fine and the Scope/Protocol Analyzer and [filtered] USB Wireshark ("fdtiFastWR_timeoutBadData_filtered.pcapng") shows the completion of all reads and writes to be approx 39.59ms with the correct I2C protocol.  As you can see in the DBG trace  ("fdtiFastWR_timeoutBadData.log") the final byte READ results in two timeouts: one by the byte read, and one for the NACK read--my code is compiled with a 2s timeout, not 5s.  However, the Wireshark and Scope/Protocol Analyzer indicates the complete I2C transactions were fast and complete.  It would indicate the D2xx driver is causing this timeout.  Also, as I previously mentioned, the data read/returned in the Wireshark and the Scope/Protocol Analyzer is 0x28 ("ftdi_fastWR_getsReadTimeouts_LastDataRead.png"), yet the lib MPSSE does not appear to be filling in the rx buffer at all.  The buffer contains the same data prior to the call to the read routine.

Some other things I have tried
  • Powered USB hub
  • Connected directly to my laptop
  • Other I2C masters can communicate without a problem to my slave device
  • Only tried 100KHz, my slave only operates in this mode
  • Tried a couple USB cables
  • Only tested Ubuntu 64-bit.  I have NOT tried a 32-bit OS or Windows.
  • Attempted uncommenting the SEND_IMMEDIATE for the fast read but this did not return the data any further
  • Modified the Mid_SetClock() for the FT232H to match the various specs for calculating the clock divider.  The routine does not appear to match the formulas in AN_108, etc.  This did not appear to fix/alter the problem, only the clock pulse/width.
  • In the MPSSE lib for the fast read routine there is ifdef'ed code for various proposals/alternatives.  I have tried all the other proposals and they did not work.
  • Modified the I2C_FastRead() to check the FT_GetQueueStatus until the number of expected bytes are read, then do the FT_Channel_Read.  This did nothing.  The timeout still occurred and the data portion was not returned.

Questions
- Why does the "normal" read/write and the fast read/write APIs not yield the same results?  One gives an IO error, the other nearly works but gives some incorrect data.
- Are the Mid_SetClock calculations correct?  Shouldn't it be "((12M/clock)/2)-1" when the clock divide is enabled and "((60M/clock)/2)-1" when the clock divide is disabled?  This correction matches the AN_108 among other Application Notes FTDI has published.
- Why is the final read timing out but does return data?  All indications indicate a problem in the D2xx based on the I2C bus and Wireshark traces.
- Why does the fast read not fill in the rx buffer?
- Is it possible to get the latest lib MPSSE source to compile and try?  The link from the other posts does not work.

Setup
FTDI device: Adafruit FT232H
OS: Linux, Ubuntu 16.04 (64 bit)
Driver: libftd2xx-x86_64-1.4.8
Lib: LibMPSSE-I2C Version 0.4 20-May-2014

Sample Calls
Code: [Select]
ftStatus = I2C_DeviceRead( dcb->hnd,
                           addr,
                           nRead,
                           rBuf,
                           &bytesTransfered,
                           #ifdef MPSSE_FAST_I2C_READ_API
                           (I2C_TRANSFER_OPTIONS_START_BIT |
                            I2C_TRANSFER_OPTIONS_STOP_BIT |
                            I2C_TRANSFER_OPTIONS_FAST_TRANSFER_BYTES) );
                           #else
                           (I2C_TRANSFER_OPTIONS_START_BIT |
                            I2C_TRANSFER_OPTIONS_STOP_BIT) );
                           #endif

Code: [Select]
ftStatus = I2C_DeviceWrite( dcb->hnd,
                            addr,
                            nWrite,
                            (uint8_t*)wBuf,
                            &bytesTransfered,
                            #ifdef MPSSE_FAST_I2C_WRITE_API
                            (I2C_TRANSFER_OPTIONS_START_BIT |
                             I2C_TRANSFER_OPTIONS_STOP_BIT |
                             I2C_TRANSFER_OPTIONS_FAST_TRANSFER_BYTES) );
                            #else
                            (I2C_TRANSFER_OPTIONS_START_BIT |
                             I2C_TRANSFER_OPTIONS_STOP_BIT) );
                            #endif


Due to the attachment limitations I tarred the files up:
  • ftdiNormalWR_ioError.log = DBG output for the normal write/read test.  Timestamps are on the far left in msec.
  • ftdiNormalWR_ioError.png = Image of normal write/read test from Scope/Protocol Analyzer.
  • ftdiNormalWR_ioError_filtered.pcapng = Wireshark trace for the normal write/read use case.  Filtered to only show frames > 66 bytes to reduce the size of the file.
  • ftdiFastWR_getsReadTimeouts.log = DBG output for the fast write/read test.  Timestamps are on the far left in msec. NOTE: My timeouts were changed to 2 seconds, so that is what you see in the log.
  • ftdiFastWR_getsReadTimeouts_filtered.pcapng = Wireshark trace for the fast write/read use case.  Filtered to only show frames > 66 bytes to reduce the size of the file.
  • ftdiNormalWR_getsReadTimeouts_LastDataRead.png = Image of fast write/read test from Scope/Protocol Analyzer showing ONLY the last read transaction 0x28, but the MPSSE lib returns 0xAD.
  • ftdiNormalWR_getsReadTimeouts_Duration.png = Image of fast write/read test from Scope/Protocol Analyzer showing overall I2C transaction time, yet the test takes > 4 seconds due to some read timeouts in the D2xx driver.

 6 
 on: August 20, 2019, 04:30:34 PM 
Started by Yunuce - Last Post by FTDI Community
Hello,

Which USB interface are you using?
If you are using the USB D2XX interfaces on this FT90x then this is possible.

See the D2XX examples here:

AN_360 FT9xx Example Applications

Also see the D2XX Programmer's Guide which provides software examples.

In your application running on the PC, calling FT_Write would write data to the FT90x via USB then you could read that data using D2XX_Read.
See section 2.35 D2XX Feature in AN_365 FT9xx API Programmers Manual.

If you need further support, feel free to [urlhttps://www.ftdichip.com/FTContact.htm]Contact Us[/url].

Best Regards,
FTDI Community

 7 
 on: August 20, 2019, 02:41:53 PM 
Started by DanTrotts - Last Post by FTDI Community
Hello,

Please have a look at the following application notes, which cover I2C examples:

D2XX:
https://www.ftdichip.com/Support/Documents/AppNotes/AN_113_FTDI_Hi_Speed_USB_To_I2C_Example.pdf
https://www.ftdichip.com/Support/Documents/AppNotes/AN_355_FT232H%20MPSSE%20Example%20-%20I2C%20Master%20Interface%20with%20Visual%20Basic.pdf
https://www.ftdichip.com/Support/Documents/AppNotes/AN_411_FTx232H%20MPSSE%20I2C%20Master%20Example%20in%20Csharp.pdf

LibMPSSE:
https://www.ftdichip.com/Support/Documents/AppNotes/AN_190_C232HM_MPSSE_Cable_in_USB_to_I2C_Interface.pdf


The following will also be useful:
https://www.ftdichip.com/Support/Documents/AppNotes/AN_135_MPSSE_Basics.pdf
https://www.ftdichip.com/Support/Documents/AppNotes/AN_108_Command_Processor_for_MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf

Best Regards,
FTDI Community



 8 
 on: August 20, 2019, 08:12:37 AM 
Started by Yunuce - Last Post by Yunuce
Hello,

I try to make USB to I2C/SPI with ft90x MCU and I want to make a GUI with MS Visual Studio but Bridgetek supports eclipse so I decided to make a main function which will be include all source codes and receive data from GUI for use them then I will save these mcu memory with eclipse. After that I will make a GUI with FTD2XX.NET , this GUI will only receive data from the user(i.e speed mode,clock speed, slave address etc.)  and send these data mcu over USB with FT_Write function but i confused where to write data? I search D2XX Programmer's Guide and says 'Write data to the device' so can you give more detail?

Finally, I design a PCB and itit hasn't arrived yet so all of them is a theory.Is it possible this theory?

Best Regards.


 9 
 on: August 19, 2019, 07:05:25 PM 
Started by DanTrotts - Last Post by DanTrotts
Hi.

I have an Adafruit FT232H board with a connected SHT31-D that I want to read the humidity and temperature from. I want to code this in C++ and not Python and I was wondering if anyone had a simple shell of a C or C++ program that would just show the basics of doing that. I have FTD2XX and libMPSSE-i2c libraries installed on Ubuntu 19.04 release.

I can see the FT232H and read its EEPROM. I know that I have to remove the ftdi_sio and usbserial drivers to be able to talk to it. Where I don't have any practical experience is talking through the FT232H to the SHT31-D using either D2XX or MPSSE with i2c or other protocols.

The SHT31-D is wired with ground, D0 to SCL and D1 tied to D2 going to SDA. I have python code that can read the temp and humidity but I just can't seem to compile a C or C++ program with the right library combinations to be able to make it work.

Any help or pointers would be appreciated.

P.S.  I have the following reply from support on the Adafruit support group:

     "by adafruit_support_mike on Mon Aug 19, 2019 5:40 am
      I'm afraid we don't have any C code for communicating with the FT232H. Maybe someone from the community will have more information."

Regards,

Dan

 10 
 on: August 16, 2019, 10:53:24 AM 
Started by techtoys - Last Post by FTDI Community
Hello,

Thanks, I have passed these on to the development team.

Best Regards,
FTDI Community

Pages: [1] 2 3 ... 10