D4D eGUI External Memory Bitmap Images

[miket]

Hello,

I am attempting to store raw bitmap images in NAND flash, move them to external memory (DDR2), and then setup my pictures in D4D to point to this picture data.  The NAND Flash and DDR2 portions of my code are working, but I am not able to successfully get D4D to display the image.  I am wondering if anyone has any tips for storing bitmap pictures/images in DDR that are not a file sitting on a filesystem such as MFS or FFS.

I've been trying to change the D4D macro's/structures to not require 'const' for everything, but this had other unintended consequences with MQX in that I was having problems with _mem_extend().

I am using the k70 tower kit w/ MQX 4.0 & D4D 3.0.

Thanks for looking!

-Mike T

[miket · Accepted solution]

I just wanted to close this thread out after the work-around solution we came up with.

Originally, we were trying to use the internal D4D image decoder to read raw bitmap images out of external RAM by getting rid of some const declarations.  With the 'const' issue encountered we decided to go a different route.  After playing around with the MFS/FFS to read the files out of NAND Flash, and into external RAM, we were seeing quite a bit of performance hit.  Reading a QVGA (800x480) uncompressed 24-bit bitmap image took on the order of ~3.5 seconds. 

In digging into the D4D code, the size of our buffer, which reads in and parses the bitmap data, was very small (64 bytes I believe).  This was increased to 4kB:

#define D4D_EXTSRC_BUFF_SIZE    4096 (found in d4d_user_cfg_app.h)

This speeds our access times up to just over a second; which is fine for our application.

The main route we took was to use the external bitmap image decoder source and instead of using the standard MFS/FFS file operations (e.g. fopen, fclose, fseek) we hijacked these and tied them into our own calls to read in the bitmap image from NAND into RAM and have the fseek calls move the pointer within the memory of where in the bitmap file D4D is expecting it.

There is a third option for using image decoding in the D4D source called external D4D.  Looking at the source for this, it appeared to not be quite ready.  We are using 24-bit bitmaps for our application.  However, the external D4D could be what we were looking for all along, but since we got this work-around going we probably will not investigate this path any further.

One final note is that if you are encountering random unhandled interrupts and you see the debugger going to the default interrupt handler, but you are pretty sure you have everything configured right, you may be overflowing memory somewhere.  This is one of the main issues we ran into.  When we would remove our previously defined interrupts from our application the debugger would just crash and not report a warning within CodeWarrior.  So, if you encounter similar strange observations, look closely at your memory usage and allocations.  The Task-Aware Debugger (TAD) was very helpful in this investigation.

Hopefully this leaves a few bread crumbs for anyone else that winds up on this path.

May success attend your efforts,

-Mike T

[soledad]

Hi,

Please check the below threads, please let me know if this helps :smileywink:

TWR-LCD with eGUI (D4D) and MQX on TWR-K70F120M

TWR-K70 + MQX + eGUI with external bitmaps

Example for K70 + MQX 4 + eGUI 3 + TWR-LCD

Sample code request eGui + TWR-K70 + TWR-LCD-RGB + MQX + CW

Have a great day,
Sol

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[miket]

Thanks for the response Sol,

I looked through these threads and nothing stood out in regards to the issue we're encountering.

Basically we can display images just fine if they are stored in on-chip Flash (ROM).  When we try and store images in RAM, and have the D4D_BMP structure point to this location in RAM, is where the issues are at.  The internal data types within the D4D_BMP structures are all 'const void *' and trying to get around this is causing the problems.  We are attempting to not use MFS/FFS so we can't use the external source option since the Bitmap data is store in RAM directly without a filesystem.

Any other ideas or thoughts?

Thank you,

-Mike T