cancel
Showing results for 
Search instead for 
Did you mean: 

Images from SD Card: STM32F746ZG

Ray Mendoza
Associate II

Posted on August 31, 2017 at 00:41

Hello!

I was wondering how to load only half of a bmp image from an sd card. I am capable to loading a full image from a header file using the examples provided for the STM32F746G-Discovery. The reason I am asking this is because our hardware is set in a way where the SRAM is not big enough to store the entire bmp file from the sd card. I'm talking about a customized board created here at work. It uses a STM32F746ZG chip. I was able to understand which details had to be changed in the STM32F746G-Discovery files for those examples to work.

Also I was wondering if instead of doing this, then is it better to pull the images from flash memory. Is it faster than the method above? Or do they not matter because they are both fast?

There is a QSPI chip on the board but I'm a little confused on setting it up on Keil. It is 16MB. The part is :

http://www.issi.com/WW/pdf/25LP-WP016D.pdf

I have made the connections on CubeMX but I'm unsure what the parameters settings should be in order to run with the QSPI chip on board.

Thank you!

10 REPLIES 10
Ray Mendoza
Associate II
Posted on October 06, 2017 at 03:07

As an update, I decided to not use the qspi. But I am still trying to load parts of an image located in a SD Card.

Posted on October 06, 2017 at 04:09

Well typically you pull the header, and then walk the rasters, you step a line at a time, pull out the portion you want to display/use, and only index through the lines you want.

You can use fseek() to step through the file, but is often more efficient to load a fixed sized block (4KB, 8KB ?), and walk a pointer through the memory buffer.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on October 06, 2017 at 08:20

You could scale down the image during loading, all necessary information is present in the file header.

Or, insist on scaled-down images, like many pocket-size MP3/MP4 players do.

Posted on October 06, 2017 at 18:08

Decimation vs Windowing, I assumed the latter

JPEG will be more complicated as content needs to be decompressed first.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on October 07, 2017 at 00:26

So if I'm understanding this correctly, you're saying to find the location of the bitmap file in the SD card, store that value in separate variable, and then extract a certain chunk of (4KB,etc.) and display that portion of the image?

Posted on October 07, 2017 at 00:49

I'm saying walk the structures where you read aligned 4K (or larger) blocks, if you use fseek()/fread() it's going to be a complete sloth.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on October 07, 2017 at 02:22

I may be a little confused. Why is fseek()/fread() slow? Is using the DMA to read blocks from SD better?

Posted on October 07, 2017 at 14:54

You have no caching in the block storage subsystem or file system.

Each command to the SD card has very significant overhead, you want to always read/write multiple sectors and have them aligned with the mega-blocks within the geometry of the array, ie not span across two of them. These are likely to be of the order of 128KB

The file data is highly structured, yet you throw out that knowledge and let the computer do random seeks to byte offsets, and do small unaligned reads. This exposes the worst possible characteristics in the system.

When cards say they are Class 4 or 10, or whatever, they are describing the linear streaming of data in the most efficient manner, not jumping around randomly, or skipping forward 1920 bytes for every other read.

Advancing a memory pointer in a buffer by 1920 bytes has no cost, reading a 4K or 8K block is significantly faster than doing multiple 512 byte sector reads and extracting 1920 bytes that falls somewhere inside 4 or 5 them. Repeat over 1080 lines and the inefficiency scales nicely.

DMA helps if you do something with the time it frees up on the processor rather than spinning in a while() waiting for it to complete. It would help significantly to have one thread reading the data, and a second one consuming/processing it, and have multiple buffers.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on October 09, 2017 at 22:25

Thank you for the explanation! Well I believe this explains why switching between images was really slow when using fseek. But what I'm confused about is how can you put the data into multiple buffers without using fseek? I might be confusing myself with the BSP function and HAL_SD functions. 

From the functions, I see that HAL_SD_ReadBlocks_DMA reads from a specific address and moves the data to a buffer Am I going in the right direction?

Again thank you very much. I'm learning a lot here because I came from using Arduino to using ARM.