Hi Brian,

Our developers are still working on this but we'll check and let you know if there is any further information which would help.

Best Regards,
FTDI Community

Hello,

Eve Screen Editor does not currently support the generation of a flash block containing selected assets.

Our Eve Asset Builder utility can be sued to generate flash images:
https://brtchip.com/eve-toolchains/#EVEAssetBuilder


It is important to note that only images in the ASTC format can be rendered directly from flash. You may
need copy other format bitmaps into RAM_G by cmd_flashread and render them from RAM_G.


Best Regards,
FTDI Community

Hello,

Unfortunately there are currently no EVE tools supported under Linux.

Best Regards,
FTDI Community

Hello,

Please see AN_176 - Vinculum Comparison of VDAP and V2DAP:

When a bulk endpoint is used for data mode, it will block when no data is received from the device. No further data will be sent to the device until data is received. Interrupt endpoints will send data only after data is received from the device but they will typically send data after each polling interval. FT232 devices will have data ready to receive after a configurable time interval, these will work the same as interrupt endpoints. Both bulk and interrupt endpoints are supported in command mode (DRD command).
This is due to the architecture of the V2DAP firmware. If the application required is primarily to perform tasks in data mode then it recommended that a simple application is used to transfer data between the devices rather than V2DAP firmware.

The source code for V2DAP is provided with the Vinculum-II Tools which you can take a look at:

C:\Users\Username\Documents\FTDI\Firmware\Samples\V2.0.2-SP2\VNC1L\V2DAP

These are very mature products and are no longer supported by R&D and have been superseded by FT9xx.

The best solution we have is to use the FT90x MCUs.

We provide example code in AN_360 FT900 Example Applications, but since we provide source code you can customise to meet your needs:

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

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

Best Regards,
FTDI Community

Hello,

I see that you are using either a USB 2.0 cable or USB 2.0 host. Can you try connecting to a USB 3.0 Host with a USB 3.0 cable to see if that makes any difference?

If you are still having problem please contact support1@ftdichip with a screenshot of your Configurator, so that we may review your setting and details of your FPGA.

Regards,
FTDI Community

Please note that our 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

The FT90x library driver for I2C only supports 8-bit addressing.
However, you could take a look at FT90x UVC Webcam Example. The OV5640 module code includes a set of subroutines to allow 16-bit addressing on the I2C bus. These may be reused for other projects.
The source code is downloadable at the link above.

This should help you access the 24LC64 64k range.

The device addressing of both EEPROMs are very similar. The control byte format starts with 1010.

Maybe someone else on the Bridgetek Community can help further with this.

Best Regards,
FTDI Community

Hello,

This is not possible because D0 to D7 bidirectional FIFO data are used for both read and write operations.

Best Regards,
FTDI Community

Hello,

You can check for a pen down condition where the REG_TOUCH_SCREEN_XY becomes not-equal-to 0x80008000 and likewise a pen-up condition where it changes from a coordinate to value 0x80008000. You can use a small state machine or if-else routine in your code to track the previous and current values and therefore detect pen-down and pen-up conditions.   You can use these along with a counter in your MCU code to detect the length of touch that was held on the screen.

As the item is normally a tagged object, you can monitor the tag value and count the number of polls of the tag register where the tag remains at the value of the object being monitored. This can be used to determine how long the touch was held for.

You can also combine these two techniques to allow you to detect both how long a touch is held and for how long it was on the particular tagged item being monitored. e.g. if you detect pen-down, also poll the TOUCH_TAG register to confirm that the touch is actually on the image button whilst waiting for the pen-up.

If you use interrupts, there are also interrupts available for both touch detect and the tag value changing which could be used to reduce the polling required in the above cases.

Best Regards,
FTDI Community