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: September 29, 2020, 03:12:33 PM 
Started by Magip - Last Post by FTDI Community
Hello,

It can tell the end of the data by the BE (byte enable) signals. The 0x55 is an arbitrary value and is not actually accepted into the FIFO and so the value is not important.

The bus master asserts the signal for the valid bytes in a word strobe. Normally, all 4 bytes should be valid in a bus transaction except in the last word strobe when the data transaction length is not aligned at a word boundary. When BE[3:0]=0001 the FT602 knows that it is the end of data. The FT602 will also then see the header of the next frame and knows that the last frame has ended.

Best Regards, FTDI Community

 2 
 on: September 29, 2020, 02:37:54 PM 
Started by Magip - Last Post by FTDI Community
Hi,

We are pleased to hear it's working well now,

Best Regards, FTDI Community

 3 
 on: September 29, 2020, 05:18:25 AM 
Started by Magip - Last Post by Magip
Hi,
  I have successfully ported pattern generator example to my custom PCBA and I can see vertical colour bars on PC.  I am studying the how the UVC header and data is being sent from FPGA using WR_N transactions.  I also used Wireshark to capture USB tranffic and observe that multiple WR_N transactions are consolidated into 1 USB bulk transfer of size 12 bytes (header) + 640x480x2 bytes (yuy2 data).

  I am confused by how FT602 knows which of the WR_N transaction is the start of UVC frame and which is the last?  What is the purpose of sending data = 0x00000055 and BE = 0x1 and the end of yuy2 data?  This 0x55 byte is not captured by Wireshark even though it is sent by FPGA to FT602.

Regards,

Magip

 4 
 on: September 29, 2020, 04:59:53 AM 
Started by Magip - Last Post by Magip
Hi,
  I solved it by copying config from another FT602.  Working now.

Regards,

Magip

 5 
 on: September 23, 2020, 04:41:01 PM 
Started by randomEngineer - Last Post by FTDI Community
Hello,

You are already in contact with our support team on this issue via email.
Please post any resolution here to help other customers

Best Regards,
FTDI Community

 6 
 on: September 23, 2020, 04:40:29 PM 
Started by unified - Last Post by FTDI Community
Hello,

Flow control is handled by the application program.

For example, with terminal programs like PuTTY or Tera Term there are settings available in the application that allow you to select the type of flow control. These typically use the VCP drivers.

If you wanted to use the D2XX drivers that would involve creating your own application program that would allow you to configure flow control. You can take a look at some software examples here:

https://www.ftdichip.com/Support/SoftwareExamples/CodeExamples.htm

TN_153 Instructions on Including the D2XX Driver in a Visual Studio Express 2013 Project is also useful.

There is no handshaking prior to configuration in software.

Best Regards,
FTDI Community

 7 
 on: September 23, 2020, 02:00:15 AM 
Started by unified - Last Post by unified
Sincere apologies - I must be missing something because there are a lot of posts on the topic of flow control.

The datasheet states "Control signals supported by UART mode include RTS, CTS. .... RTS/CTS and XON/ XOFFhandshaking options are also supported"

Where are these options selected?  I have gone through FT_Prog and can find nothing other than signal inversion settings.  The D2XX_Programmer's_Guide provides options to set flow control, but that would require a D2XX based program to configure them (or is that somehow managed by the VCP enumeration??)  If so then what is the power up condition of the chip - ie is there any handshaking prior to configuration? 

Thanks in advance,
Colin

 8 
 on: September 22, 2020, 03:56:28 PM 
Started by kalle - Last Post by FTDI Community
Hello,

We have a few products using the default FTDI vendor ID with our own PID (granted by FTDI some years back). Will our VID/PID combination also work in the upcoming .dext driver?

If your VID/PID combination is currently included in our macOS VCP driver's Info.plist file then yes it will be included in the .dext version of the driver.

Best Regards,
FTDI Community

 9 
 on: September 21, 2020, 02:44:40 PM 
Started by kalle - Last Post by James
Hi there, we are also looking forward to the .dext driver version.

We have a few products using the default FTDI vendor ID with our own PID (granted by FTDI some years back). Will our VID/PID combination also work in the upcoming .dext driver?

Thanks

 10 
 on: September 21, 2020, 12:22:04 PM 
Started by cioma - Last Post by cioma
Assuming FTDI is interested in selling more chips it would be great if they opened their FT60x protocol documentation (and the same for other chips too).
We know we can use FTDI drivers but many of us would like to write clean code in selected language using generic libraries (e.g. libusb).
Just a thought :)

Pages: [1] 2 3 ... 10