Hello,

Yes would you be able to provide the converted images and code that you're using?

Best Regards,
FTDI Community

Hello,

Can you please test with known good hardware like our Development Modules?

You could also send your schematics to your local support team for review. See Contact Us.

Best Regards,
FTDI Community

Hello,

The alpha colour channel does not take effect for theses widgets.
But I've ran a test and the colours seems to be working fine on our end.

Can you provide your project files?

Best Regards,
FTDI Community

Hi,

One thing to check is how large your images are when de-compressed by LoadImage. The resulting image data in RAM_G will be larger than the JPG itself as it will be de-compressed.

You can add a check using the CMD_GETPROPS (see 7.3 of this appnote below). As a quick test, you can also try converting to RGB565 with our asset builder to see how large the raw data output file is to give an idea of the decompressed size.
https://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/EVE/BRT_AN_014_FT81X_Simple_PIC_Library_Examples.pdf

Best Regards, FTDI Community

Hi,

EVE displays the image in real time from RAM_G and so any change to memory used for a bitmap will be immediately shown on the screen if the bitmap is visible.

As you said, double buffering is the best solution, as you can load the second image whilst still displaying the first and change over immediately. Note that compressed images such as PNG (via Loadimage) and bin files from the asset converter (via Inflate) still take the same amount of RAM_G once decompressed by the Loadimage or Inflate command. However, depending on the image you may be able to experiment with the image quality by converting via our asset converter. The table in the BITMAP_LAYOUT section of the Programmers Guide shows how many bits per pixel. e.g. RGB565 uses 2 bytes per pixel whereas RGB332 uses only one byte per pixel.

Another option if two images won't fit is to load a version of the image in lower quality and change to this whilst the other is being updated. (either by loading a separate low quality image or by inflating to a different area of RAM_G as L8 greyscale. A slightly less complex way might be to dim the image or blank it completely by setting COLOR_RGB before the Vertex command to a low value or to (0,0,0). Then put back to (255,255,255) once the image has been loaded.

Best Regards, FTDI Community

Hello,

Are you connecting to a USB 3.0 Host port on your host PC? If so do you notice any difference if you use a USB 3.0 cable rather than a USB 2.0 cable?

Also, you mention that you encounter some error messages, can you provide some details on these error messages please?

Regards,
FTDI Community

Hello,

This is confirmed as a bug in FT4222_I2CMaster_Write().
It will be fixed with the next LibFT422 patch.
However the actual transaction is OK and the extra count of 4 can be discarded as a workaround.

Best Regards,
FTDI Community

Hello Liam,

Which driver version and IC are you using?

Has BytesWritten been initialised correctly first? This would be good practise.

You could also try FT_Purge.

What are your timeouts set to in FT_SetTimeouts? Could it be that it's timing out before there is enough time to send the data?
Remember USB is non-deterministic. There can be lots happening on a USB bus or with the OS which can cause delays.

See the D2XX Programmer's Guide for more information.

Also AN232B-04 Data Throughput, Latency & Handshaking provides some useful information and applies to all FTDI devices.

Best Regards,
FTDI Community