STM32F407 STEMWIN LOADING IMAGES FROM SD CARD SLOW

[giovani]

Posted on October 15, 2015 at 19:42

Hello!

I am working in a project that uses a STM32F407 and 7'' TFT LCD with SSD1963 controller, after hard work to put the LCD running and some corrections on the board, but now I don't know if what we are trying to do is the better approach for the application. We had done some images to use as background of our app, but the 192KB of RAM is not enough for all images if we convert to c files, then we think to use SD card to store all images and loading them at runtime, but decompress the image and loading is very slow take about 2 seconds. Another thing that we think is the use of a SDRAM of 16MB, but I not sure that this will solve our problem. So I need help of anyone that has passed for this situation or something simila and could give us the better way to solve the problem. Thanks, Giovani #stm32f407-stemwin-ssd1963

[Tesla DeLorean]

Posted on October 15, 2015 at 22:19

So why decompress them, surely the SD Card is large enough to hold the uncompressed images, at the colour depth of the display, and can pull 5-8 MB/s, or why RAM is needed, especially for 'C' files, don't quite understand that.

If they were 'static const' they'd be in FLASH I think you need to determine *where* the bottle-neck is. How long does it take to fill the screen buffer on the LCD, if the image or repetitive pattern is held locally? Are you addressing individual pixels, or painting entire raster(s)? ie can you transfer a 32KB hunk of data to the panel in a single linear write operation? How long does that take? Is a basic screen fill/wipe fast enough now? With the SD Card you want to read very large linear, and aligned blocks of data. Say 32KB. If your decompress routines are doing small fread() type operations these will be very slow. You'd want to put a layer between the data requests and the file system. If you're plotting individual pixels, you'll want to stop doing that. How big is the display, 7'' is a physical size, the bandwidth is going to be driven by the pixel count.

[giovani]

Posted on October 15, 2015 at 23:15

Hi Clive!

We are using display of 7'' 800x480 and I have some pictures on SD Card with 32Kb, below are the routines that we use to show the picture. //global variable static char _acBuffer[0x1000]; int _GetData(void * p, const U8 ** ppData, unsigned NumBytes, U32 Off) {          FILE * phFile;     uint32_t NumBytesRead;     phFile = (FILE *)p;     //     // Check buffer size     //     if (NumBytes > sizeof(_acBuffer)) {         NumBytes = sizeof(_acBuffer);     }     //     // Set file pointer to the required position     //     fseek(phFile, Off, SEEK_SET);     //     // Read data into buffer     //     NumBytesRead = fread(_acBuffer, sizeof(char), NumBytes, phFile);     //     // Set data pointer to the beginning of the buffer     //     *ppData = _acBuffer;     //     // Return number of available bytes     //     return NumBytesRead; } //Loading Background Image hFile = fopen (''Logo.gif'',''r''); if (hFile !=NULL){;      if (!GUI_GIF_DrawEx(_GetData, hFile, 0, 0)) {      }      fclose(hFile); } StEmWin = 64KB reserved This take 1 second to show. If you could help us I will be so grateful, I can't understand yet the real reason for this problem, I researched over the internet forums and on some Application Notes, StEmWin manual, but it doesn't work how some movies of application on youtube using similar hardware. I think that the problem can be my firmware, but I don't know where is. Thanks, Giovani

[Tesla DeLorean]

Posted on October 16, 2015 at 04:31

Ok, that appears to be a 4K buffer, and you're fread()ing every request. You should add some telemetry to understand the sizes of the individual reads.

The mechanism could be altered to have a large fixed size buffer, where you always read the whole buffer, and then serve it out piece-meal as the requests come in, pointing at the offset within the buffer, until all is consumed, and then reading in the next block. Is this a commercial project?

[giovani]

Posted on October 16, 2015 at 14:27

Hello Clive!

Yes, it is a commercial project. It will be used to display data received from another product through RF, showing alerts and graphs of the data. If I have understood what you explained, increasing the buffer of static char to _acBuffer[0x4000] for example will help in the performance, if is this, I tried and didn't changed the performance. One thing that I modified is the prescaler of SPI3 clock to16 that we are using for SD Card, this gives me a better result. Another thing the SD Card class will help in performance? We are using class 2 now. Thanks for your attention, Giovani

[Tesla DeLorean]

Posted on October 16, 2015 at 15:17

No, I mean something more complicated that manages the reads so they are always large and aligned despite the nature of the read requests as they arrive. You serve data out of a buffer, avoiding an fread() in every request.

The fseek() on every read is also detrimental, this can be optimized so it only occurs if the pointer changes from where it left off. SPI? Why wouldn't you use SDIO? It will be at least 4-5x faster at similar clocks The most speed can be obtained from large, aligned, reads. The command overhead to the card is significant, and punishing for single sector reads. Reading a cluster, on a cluster boundary, will be approaching optimal. SD Cards are sensitive to how they are formatted, where clusters/structures are aligned to the underlying erase block size. The factory format will take this into account, user formatting may not. The Class/Quality will make some difference. Most anything should hit at least 1.5 MBps on the Read side. Higher grade cards can get to 7-9 MBps (4-bit SDIO 24 MHz)

[Tesla DeLorean]

Posted on October 16, 2015 at 15:46

The

http://www.st.com/web/catalog/tools/FM116/CL1620/SC959/SS1532/LN1848/PF262395

has an MicroSD Card socket, 8MB SDRAM, and a 800x480 (physically smaller, and without a controller), which might be a good platform to discover what aspects of the design have the most impact to the speed issue(s)

[giovani]

Posted on October 16, 2015 at 19:36

Clive,

first of all, I will modify the board to work with SDIO and buy another SD Card class 10, then I will try to understand the meaning of the routine to manage the readings serving data out of a buffer, at the moment I don't know how I can do this. Thanks for your attention, Giovani

[giovani]

Posted on October 30, 2015 at 11:56

Hello Clive!

I was trying to put SDIO to work in our project, but I have some problems, when I call finit function is returning fsok, but when I call fmount function this return fsnofilesystem, I searched on the forums but doesn't found the solution and don't know what causes this error, because the same card worked when used on the SPI interface. Sd card is wired up as below: SDIO_CK     -->PC12 SDIO_CMD -->PD2 SDIO_D0     -->PC8 SDIO_D1     -->PC9 SDIO_D2    -->PC10 SDIO_D3    -->PC11 Thanks, Giovani

[Tesla DeLorean]

Posted on October 30, 2015 at 14:04

I'm using FatFs, I've posted example code and connection diagrams for the circuit. Do you have any pull-ups on the pins?

There is a .HEX about half way down that should test the interface.[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Discovery/sdio%20fatfs%20speed%20problem&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=2102]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Discovery%2Fsdio%20fatfs%20speed%20problem&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F¤tviews=2102 Output is via the SWV (Serial Wire Viewer) in the ST-Link Utilities.