This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

emWin Memory Aloc.

I want to use emWin to draw a GIF file or a jpeg File to my screen. I have to do this at run time, since I will not know what the picture is until then. I have used GUI_GIF_DrawEx(); function, because I do not have enough internal RAM. The issue is with GIF it takes 16K of dynamic memory to convert the file, and Jpeg I need at least 33k. I just don;t have that kind of Internal RAM on my processor. I am also using a processor with out an EMC. However, I do have lots of room on my flash device, or I can add external SPI RAM. Can emWin use external RAM via SPI, or memory space in the external flash for its memory allocation? If so, how would I do this?

Parents
  • Well, the library is most probably not written to like serial RAM. So it would probably be easier to see if the library can be modified to only have access to a band of the frame buffer memory at a time.

    Operating on a band of the frame buffer means it can use internal RAM at maximum speed. Just that it has to process any graphical primitives multiple times, while performing clipping relative to the current draw area (i.e. the current band).

    If the library instead needs 30kB of RAM for stack etc, when processing a GIF, then you either have to get a bigger processor or another library. But the problem is that a GIF image contains compressed data. So there is a need to create the symbol tree of that compression when decompressing it. It would not work well to have this information serially accessed. It would work really lousy. Extremely lousy.

Reply
  • Well, the library is most probably not written to like serial RAM. So it would probably be easier to see if the library can be modified to only have access to a band of the frame buffer memory at a time.

    Operating on a band of the frame buffer means it can use internal RAM at maximum speed. Just that it has to process any graphical primitives multiple times, while performing clipping relative to the current draw area (i.e. the current band).

    If the library instead needs 30kB of RAM for stack etc, when processing a GIF, then you either have to get a bigger processor or another library. But the problem is that a GIF image contains compressed data. So there is a need to create the symbol tree of that compression when decompressing it. It would not work well to have this information serially accessed. It would work really lousy. Extremely lousy.

Children
No data