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

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

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

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

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:
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

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

Hello,

I have be liaising with the driver team recently and they are making good progress. We are currently establishing which features supported in our driver but not in the Apple driver are most pertinent for a beta release. For example, baud rate aliasing or latency timer settings.

If you are using any of these feature please let me know.

Best Regards,
FTDI community.