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

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - FTDI Community

Pages: [1] 2 3 ... 40
1
Hello,

We plugged your code into a VNC2 and a Logitech web cam. The code worked straight away with a transfer size of 192 bytes using the simple GET_CUR (probe) and SET_CUR (commit). We used a USB Analyser to observe the output. This particular webcam defaulted to a resolution 320x240 at 15 fps in MJPEG. There were 12 bytes of header per packet leaving up-to 180 bytes of data.

However the program printed out zero bytes per read. The cause is the USB Host read and writes work slightly differently from other read and writes. When a USB host read or write is used the actual length of data transfer is held in the usbhost_xfer_iso_t structure and not in the parameters passed to vos_dev_read/write.

See the page “USB Host Read and Write Operations” in the help file.
“In vos_dev_write() the num_to_write and num_written parameters are ignored and in vos_dev_read() the num_to_read and num_read parameters are ignored as this information is provided and returned in the transfer block.”

Specifically for isochronous transfers the maximum transfer length is specified in the len structure member of the usbhost_xfer_iso_t structure. In the “USB Host Isochronous Transfer Block” page the note for this member says “When the operation completes, the value of len is not updated. However, the transfer length for each frame transaction is updated.” So, the total count of bytes transferred is obtained by reading and checking the condition code of all the deployed len_psw members and summing the sizes there. This is done to ensure that any missed isochronous transfers are accounted for properly in code.

We’ve modified the code as follows and can see 192 bytes reported in the while loop correctly.

                xfer.frame = frame + 1;
               
                *num_read = 0; // LAZ, Added  /*Note this is a pointer and needs dereferenced. */
               
                // now start the read from the ISO endpoint (line 511)
                status = vos_dev_read(ctx->hc, (unsigned char *) &xfer, sizeof(usbhost_xfer_t), num_read); /*(2)*/

                // Sum the total data transferred in each of the isochronous packets for the actual transfer size.
                while (i > 0)
                {
                                *num_read += xfer.len_psw[i - 1].size;
                                i--;
                }
               
                if (status != USBHOST_OK)
                {
                                return UVC_ERROR;
                }

If we set the number of transfers in the usbhost_xfer_iso_t structure to 8 via the ISO_TRANSFER_COUNT macro and disable the printf then we can get meaningful measurements of data transfer from the web cam. In this default resolution the bus utilisation was between 10% and 25%. Maximum throughput can be achieved with the USBHOST_XFER_FLAG_NONBLOCKING set and semaphores used to signal completion as in the original app note code.

Best Regards,
FTDI Community

2
Hello,

If you can get whoever has that keyboard to run the USBDescriptors sample code and log the response then we may be able to help.

Best Regards,
FTDI Community

3
Discussion - Hardware / Re: FT232H failed to program Xilinx XC3S50AN
« on: April 13, 2021, 01:46:31 PM »
Hello,

The FT232H/MPSSE itself is not specific to the type of FPGA but it requires that the programming software supports the MPSSE JTAG programming for the selected target. I have never used xc3sprog but it may be that it does not have support for the XC3S50AN and so it would be worth checking with the developers of the utility.

Best Regards, FTDI Community

4
Hello,

It only works with the one particular camera model that could send data in such a low resolution to be suitable for both the VNC2 and the OLED display.

So, in this example code there is a deliberate dependency on the Logitech Webcam Pro 9000 camera for input. The output format, frames and resolution for the chosen camera and the OLED display are matched.

As for all UVC devices, the USB isochronous reads are matched exactly to the camera output agreed upon by the SET_CUR/GET_CUR during probe exchanges. The parameters requested in the SET_CUR probes are fixed (WebCamApp.c line 320) to what this camera supports and there is no verification in the code that this was accepted by the camera. If the chosen camera does not have a matching mode then it will respond with invalid values in the VProbeAndCom structure in the GET_CUR reply to the probe (line 332) request. You can check the response to the probe request for your cameras at this point before the commit is sent (line 348). The GET_MIN and GET_MAX requests can be used to query likely modes that cameras can support.

The VNC2 is a very mature IC and only operated at Full Speed USB which brings limitations.

Our sister company Bridgetek have an MCU with High Speed USB which is more suited to UVC cameras:

https://brtchip.com/ft900/

The FT9xx Modules (eg MM900EV3A) include an OmniVision OV9655 camera module (1 megapixel).
This uses raw images and doesn’t support compressed images which limits throughput.

FT90x UVC Webcam example includes support for an OmniVision OV5640 (5 megapixel) which is on the CleO Camera module.
This supports compressed MPEG images (compressed) which allows for higher throughputs.
Note some hardware modifications are required to support this camera:

TPS76915DBVR (1.5V) for U17.
FT531GA (2.8V) for U16 and remove C109.

Also there are known issues with the FT90x UVC Webcam example code on our website. We are in the process of uploading a new working version (which can be downloaded on our FTP server for now: AN_414_FT90x_USBD_UVC_Webcam rev 2131.zip).
The example code supports the following resolutions:

QVGA: 320 x 240
VGA: 640x480
SVGA: 800 x 600

Uncompressed at 30fps would only work for QVGA. Lowering the fps would allow for higher resolution.
Compressed at 30fps would work at SVGA.

Higher resolutions and frame rates can be achieved with a different senor and settings.

The FT9xx Toolchain can be used to build, program and make changes to the example code.

Also please note that the MM900EV3A contains RevB silicon. The latest is RevC.
We only have MM900EV1B which contains RevC silicon but we don’t have any RevC hardware with a camera.
The RevB should be ok for test and evaluation purposes though.
You can refer to the following documents:

PCN BRT 005
BRT AN 019 Migration Guide Moving from FT90x Revision B to FT90x Revision C

Best Regards,
FTDI Community

5
Shared Projects / Re: FT4222H Terminal Exerciser .exe application
« on: April 09, 2021, 01:17:26 PM »
Hello,

Thank you for your question.

Unfortunately we have not developed a terminal equivalent application for the FT4222H, but maybe someone else on the forum could help you with this.

We do however have a series of software examples which can be downloaded and used to test the device, these include read/write as well as GPIO examples.

The samples are included in the LibFT4222 download, available in the 'downloads' tab on the product page:
https://ftdichip.com/products/ft4222h/


Best Regards,
FTDI Community

6
Hello,

One of the keyboards in question is an Arduino which may differ from standard USB keyboards.

If there is no traffic then maybe the set idle didn't work. More likely is that there are more than one endpoint or interface on the keyboard. The example code is the simplest one which assumes that the first interface and the first endpoint in that interface is the one to use.

                                // user ioctl to find interrupt endpoint information
                                hc_iocb.ioctl_code = VOS_IOCTL_USBHOST_DEVICE_GET_ENDPOINT_INFO;
                                hc_iocb.handle.ep = epInt;
                                hc_iocb.get = &epInfo;

It might not be of course so an examination of the config descriptor would be needed.
The USBDescriptors example code will tell you on VNC2.

The USBDescriptors program will dump the report descriptors as well. This could be helpful in debugging what's wrong.

Please note, VNC2 is a very mature product which is no longer supported by R&D. It was developed over 10 years ago.

Please note the Vinculum / Vinculum-II may not work with some USB peripheral designs, due to specific design implementations.
We have only tested with particular USB peripherals when the firmware was written many years ago.
The workaround is to use USB peripherals that are working, and disregard ones that are not working.

Another alternative is to use FT90x from our sister company Bridgetek:

https://brtchip.com/ft900/

There are significant benefits of FT9xx:

-Eclipse based IDE
-Source code for API drivers is provided
-Significant performance improvement
-Actively in development by R&D
-Improved documentation and software examples

Example code can be found in AN_360 FT9xx Example Applications.

We provide FT9xx Development Modules and a free FT9xx Toolchain for custom application development.

Best Regards,
FTDI Community

7
Discussion - Software / Re: libftd2xx.a for Apple Silicon
« on: April 05, 2021, 01:18:16 PM »
Hello,

Unfortunately the driver team are still currently working on the VCP driver, but I will see if they can expedite a ARM build for the D2XX drivers:

Is there any news on this? We have several large customers asking for a fully native driver and can't produce one until have an ARM compatible FTDI library.

Best Regards,
FTDI Community

8
Discussion - Drivers / Re: FT231X and Synchronous Bit Bang
« on: April 02, 2021, 04:25:38 PM »
Hello,

Which version of the .net library are you using? The latest can be found here:

https://ftdichip.com/software-examples/code-examples/csharp-examples/

Can you please confirm why you believe the function is not working?

What is the return code after calling the function?

Please note that other function GetBitMode does not actually get the bit mode.
It actually returns the pin state of the I/O pins (used in bit bang mode).
This can be deceiving with the function name.

Please refer to AN_373 Bit-Bang Modes for the FT-X Series which should help you.

Best Regards,
FTDI Community

9
Hello,

Yes, that is correct the ucMask variable in the FT_SetBitMode() call will control which pins are input and which are outputs. If this is the last call you execute to the IC using a ucMask value = 0x0 should ensure that all of the pins remains inputs, at least until a subsequent call which will alter their state.

It is also correct that if "Pull down I/O Pins in USB Suspend" is not set when the IC gets placed into suspend mode by the USB host controller the ADBUS pins will maintain their last previous configuration, such as defining these pins as inputs with FT_SetBitMode().

Best Regards,
FTDI Community

10
Hello,

We recommend to enable the RTS_CTS flow control when using MPSSE, you can do this when configuring the device after opening the port and before entering MPSSE mode.

As you mentioned, there are no RTS or CTS lines on the device in this mode and so using RTS/CTS mode in MPSSE does not require any special connections or signals.

But enabling RTS/CTS mode also enables the flow control features in the driver itself, and so the driver wont try to read data from the chip if it does not have room for the data. Without flow control enabled, this data would otherwise have been lost. You may see the MPSSE wait until space is available if the driver buffer fills and the driver stops taking data over USB and the chip buffer then fills.

Best Regards, FTDI Community

11
General Discussion / Re: Synchronous 245 application project files
« on: March 26, 2021, 05:54:21 PM »
Hello,

You have already contacted us by email and we have supplied the file.

For other users, our website will be updated here:

https://ftdichip.com/products/morph-ic-ii/

However in the meantime, the files can be downloaded from our FTP server:

Synchronous 245 Morph-IC-II Application.zip

Note please use Internet Explorer on Windows 10 to download from our FTP server. The application is included as standard on Windows 10. Simply search for 'Internet Explorer' in Windows 10 search and paste the FTP link into the browser. Windows 10 behaviour has changed as now Edge and Chrome browsers do not allow FTP download without an external FTP Client.

Best Regards,
FTDI Community

12
Hello,

Yes that is correct the ucMask variable addresses the ADBUS0 -> ADBUS7 pins on the IC.

Please note the FT_SetBitmode(ftHandle, 0x0, 0x0) command resets the MPSSE, so you would issue a second command to enable MPSSE with 0x0 as the mask value:
Code: [Select]
ftStatus |= FT_SetBitMode(ftHandle, 0x0, 0x00);
//Reset controller
ftStatus |= FT_SetBitMode(ftHandle, 0x0, 0x02);
//Enable MPSSE mode with all pins as input

Please have a look at the following application note:
MPSSE Basics

And please also be aware of the initial pin states of the device:
FTDI Device Input Output pin States

Best Regards,
FTDI Community

13
Discussion - Drivers / Re: USB Continually Reconnecting
« on: March 19, 2021, 05:04:46 PM »
Hello,

Can you please contact your local support team by email?
We need to get more information to help you recover the device.

https://ftdichip.com/technical-support/

Best Regards,
FTDI Community

14
Hello,

This is not a known issue with our product with our Linux drivers and the IC and driver is widely used.

There is no difference in the behaviour of the 4 ports (COM1 to COM4 ) regarding USB communications.

The nature of USB communication has to be taken into account.
The communication with USB devices depends on multiple factors such as other USB devices on the bus, USB Host scheduling, USB latency, OS processing, etc.

You attached your setup. Is this all inclusive on custom hardware or are the elements separate?

Is your COM2 operating much differently from the other COM Ports? For example, is there more traffic?
What is each of the FT4232H ports connected to externally and what is the expected throughput of each?
Are you using flow control on all the FT4232H ports?

Could there be issues with the Linux board running out of CPU resources to access more than one device concurrently?

You could perform tests with our known good hardware and maybe connect that to a different Linux system to see what the results are like:

USB-COM485-PLUS4
USB-COM422-PLUS4
USB-COM232-PLUS4
FT4232H-56 Mini-Module
FT4232H Mini-Module
FT-MOD-4232HUB

The FT-MOD-4232HUB might be useful as the ST60 2230-PU Wifi+ Bluetooth device can be connected to one of the ports.

Can you also test with our D2XX Drivers (rather than VCP drivers) to see if the results are the same? See the Linux Driver Installation Guide and D2XX Programmer’s Guide for more information.

Maybe there are other FTDI Community users who can help you further.

Best Regards,
FTDI Community

15
Hello,

We have suggested in your previous forum posts that we can't support this as Altera tools require Altera hardware.

However, here is some information on using JTAG with our product which may help you:

The only JTAG support can be found here:

https://ftdichip.com/software-examples/mpsse-projects/

There are two options to use JTAG modes with the MPSSE engine:

1.            Use FTCJTAG DLL library. Example code is provided with the download (This code is no longer supported by FTDI)
2.            Use D2XX drivers direct. Example code is shown at the link above, further down the page (JTAG). AN_108 Command Processor For MPSSE and MCU Host Bus Emulation Modes provides the necessary information.

Unfortunately we don’t have any experience with Altera Cyclone.

Best Regards,
FTDI Community

Pages: [1] 2 3 ... 40