Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length.

[marbalon]

Hi all,

I'm trying to find a way to display images one by one from SD card but rapidly one by one. The problem is that when I'm trying to do this I got always rolling effect for all images except the first one. Below is the code with just two images, and it is not working because second images is slightly overwritten with white colour. Images are about 300-500kb. What is the best method to do this? do I have to put images to a different part of the RAM_G? Is there any trick to do this with media fifo or something like that to save a ram for fonts etc.?

The best solution will be:

- froze the screen
- fill with new data using fifo or RAM_G but with the same address
- switch to the new screen

But now everytime I start to write to the RAM_G new data it is automaticaly writed to the screen.

Code: [Select]

void TFT_loop(void)
{
static int index = 0;
uint32_t target_address=0;

target_address = index ? 512*1024 : 0;

EVE_cmd_load_from_sd(target_address, EVE_OPT_NODL , file_name[index], CMD_LOADIMAGE);
EVE_start_cmd_burst(); /* start writing to the cmd-fifo as one stream of bytes, only sending the address once */
EVE_cmd_dl(CMD_DLSTART);/* start the display list */
EVE_cmd_dl(DL_CLEAR_RGB | WHITE); /* set the default clear color to white */
EVE_cmd_dl(BITMAP_HANDLE(index));
EVE_cmd_dl(BITMAP_SOURCE(target_address));
EVE_cmd_setbitmap(target_address, EVE_RGB565, EVE_HSIZE, EVE_VSIZE);
EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_dl(VERTEX2II(0, 0, index, 0));

EVE_cmd_dl(DL_DISPLAY); /* instruct the graphics processor to show the list */
EVE_cmd_dl(CMD_SWAP); /* make this list active */
EVE_end_cmd_burst(); /* stop writing to the cmd-fifo */
EVE_cmd_start(); /* order the command co-processor to start processing its FIFO queue but do not wait for completion */

index ^= 1;

DELAY_MS(1000);
}


[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

[marbalon]

Thanks for a quick answer. So the best way is to keep the images small around max 200kb to save some RAM_G for extra fonts and FIFO when I need to play AVI files because all of this functionality is used in the same time.

Edit.
I have similar problem like another user on this forum (he didn't get an answer). When I try to use 2 buffers in RAM_G for images when I'm writing to first one second is overwritten but img size is much smaller then buffer size. All images are jpg files smaller than 200kb, the maximum size is about 120kb. Btw. When I'm playing avi files from media fifo everything is working fine.

Here is slow-motion video to show this effect:

https://www.youtube.com/watch?v=-DPUduvh1ps

Here are definictionsand code:

Code: [Select]

#define EVE_RAM_G_SIZE 1024*1024L
#define EVE_CMDFIFO_SIZE 4*1024L
#define EVE_RAM_DL_SIZE 8*1024L
#define MEDIAFIFO_SIZE (64*1024)
#define IMG_SIZE (200*1024)
#define IMG1_ADDR (EVE_RAM_G_SIZE - MEDIAFIFO_SIZE - IMG_SIZE)
#define IMG2_ADDR (IMG1_ADDR - IMG_SIZE)

...
void TFT_loop(void)
{
static int index = 0;
static int handle = 0;
uint32_t target_address=0;

target_address = handle ? IMG1_ADDR : IMG2_ADDR;

EVE_cmd_load_from_sd(target_address, EVE_OPT_NODL , file_name[index++], CMD_LOADIMAGE);
EVE_start_cmd_burst(); /* start writing to the cmd-fifo as one stream of bytes, only sending the address once */
EVE_cmd_dl(CMD_DLSTART);/* start the display list */
EVE_cmd_dl(DL_CLEAR_RGB | WHITE); /* set the default clear color to white */
EVE_cmd_dl(BITMAP_HANDLE(handle));
EVE_cmd_dl(BITMAP_SOURCE(target_address));
EVE_cmd_setbitmap(target_address, EVE_RGB565, EVE_HSIZE, EVE_VSIZE);
EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_dl(VERTEX2II(0, 0, handle, 0));

EVE_cmd_dl(DL_DISPLAY); /* instruct the graphics processor to show the list */
EVE_cmd_dl(CMD_SWAP); /* make this list active */
EVE_end_cmd_burst(); /* stop writing to the cmd-fifo */
EVE_cmd_start(); /* order the command co-processor to start processing its FIFO queue but do not wait for completion */

handle ^= 1;

if (index >= 7)
index = 0;

DELAY_MS(1000);
}



[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

[marbalon]

Again thanks for the reply.

I thought images are stored in RAM_G still in JPEG format ant then are converted "in the fly" when chip when need to be used.
So different buffers for different images will not help at all for full-screen images (800x480), most of the images decompressed are bigger than 500kb.
So to make this effect almost not noticeable is use the same buffer address, but small JPG files small as possible and uploaded using  QuadSPI interface.

[Rudolph]

The chance of getting an answer from the community might be a little higer over in the BRT community forum. :-)

Annother solution would be to scale the images down untill they fit into the designated memory space.
With 200k available this would be 400x240.
And then let EVE scale the images to the desired size.
See cmd_scale

I just tried this in the EVE Screen Editor and the result looked okay.
And as a nice side-effect, the smaller images are loaded faster from SD, transfered faster to EVE and EVE needs less time to unpack these to RAM_G.

[FTDI Community]

That's another good suggestion Rudolph,

You could either scale the image up for the main image or could even load a small version of the same high quality image currently displayed, scale it up and display it in place of the main image whilst replacing the data of the main image. That way the image would appear to remain on-screen whilst you change the high quality one un-seen by the user.

Alternatively, with fast SPI transfers, you can load the image very quickly and so the user won't notice the change (some of our examples where we play video are basically loading a series of images from an SD or camera in this way such as this one https://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/MCU/BRT_AN_018-FT90x-Camera-to-EVE.pdf)

Best Regards, FTDI Community

[marbalon]

Hi,
Back to the suggestion about checking decompressed data, I'm trying to get these values, and this command is not working. I get correct width and height values but the size is always 0.

I'm using this library:
https://github.com/RudolphRiedel/FT800-FT813/blob/4.x/EVE_commands.c

And checked the command implementation and it looks fine. The user manual says that it is RAM_G address of the image and this is true - I'm loading the image to the address 0, but how to check end address?

Any suggestion?

BR,
Marcin.

[Rudolph]

Yes, cmd_getprops returns the start-address and this is kind of useless since we already know the start-adress, we just fed it into cmd_loadimage.
And since the random image we just loaded could be either using 8 bit per pixel or 16 bit per pixel we can not really calculate the end-address from the size.
However, we do need to know the format to properly display the image, so it can not be all random.
And if the only allowed images are regular full color .jpg we can calculate the size as: width * height * 2
This is also at least safe in case a monochrome image is processed.