Hello Stephen,
your settings seem to be optimized for a system with less RAM. Accordingly, bitmaps are loaded into the RAM only when they are actively displayed on the screen. If the surface cache is full, bitmaps are discarded even if they are referenced from the application. This mode increases the number of heap allocations/deallocations. Consequently, the heap fragmentation is more probable. On the other hand, this mode results in the less possible RAM usage.
From this point of view, your configuration is already the best one. Interesting factor to consider is the size of the surface cache (determined by the macro EW_MAX_SURFACE_CACHE_SIZE). What is its actual setting?
Or I'm glad to get any better suggestion from you.
It is difficult without knowing your application. The error code 41 indicates an 'out of memory' when trying to allocate video memory (possibly for a surface). Can you please try following:
1. Enlarge the heap to max. possible size on your target.
2. Run the application in the target and using EW_PRINT_MEMORY_USAGE track the max. memory occupation.
3. Adjust the size of the heap to the value estimated in step 2 + 10%. Test the application again.
4. You can repeat the step 3 with larger or smaller heap (+20, +25%, ...) to find the optimal heap size the application is running correctly.
Concerning the opened third question, I got following answer from my colleague. I hope it helps you to understand the resulting effects:
I have a mempool of 1MB in OCRAM which is slower and another of 200kB in DTCM which is faster. Does it make difference in performance as to assigning which one as primary and extra mempool in ewconfig.h?
When allocating memory, Embedded Wizard distinguishes between small and large objects. Within an application there are usually many small objects and few large objects. Small objects are e.g. Chora objects, strings, diverse temp. data structures, events, etc. The small objects are created and freed very often during the runtime of the application. Large objects are containing usually large bitmaps and these are longtime living instances unless you configure the system to not to use any caches.
The small objects being data structures are accessed exclusively by the CPU. The large objects containing bitmaps can be accessed by the GPU and the CPU depending on whether the operation can be accelerated by the GPU or it has to be performed by software drawing routines on the CPU.
When you configure two memory pools (primary and extra pool), the small object allocations will start with the primary pool (this means, from the beginning of the entire heap). Large object allocations will start in the extra pool (from the end of the entire heap). When one of the pools is exhausted the system will try to satisfy the respective allocation using the other pool. So it is possible that small objects will be allocated from the extra pool and large objects from the primary pool.
Small objects (since they don't occupy a lot memory) are less problematic when it comes to heap fragmentation. The large objects may be problematic. However, since you have configured the system with EW_DISCARD_BITMAPS, the system will discard the bitmaps (large objects) from the cache even if they are still referenced. This configuration seems to be optimal for less RAM systems. Just check the setting for the surface cache (EW_MAX_SURFACE_CACHE_SIZE). Try to set it to 0.
Nevertheless, there also other aspects to take in account. EW_DISCARD_BITMAPS has no effect on a bitmap which is actually involved in a drawing operation. Such bitmap has to remain in memory until the drawing is done. Embedded Wizard manages a drawing instruction buffer (so-called issue buffer) to optimize and eliminate drawing operations. This may result in multiple bitmaps pending for the completion of the drawing operation. These bitmaps will not be discarded unless all drawings in the issue buffer are done.
Also the system can discard only bitmaps which can be recovered again. This is true for bitmap resource. If your application is rendering dynamically contents into a bitmap (e.g. using Buffered components or Extern Bitmap object), such bitmaps can't be discarded as long as they are referenced from the application. Doing this the application were not able to restore the content of the discarded bitmaps.
I hope it helps you further to optimize your system.
Best regards
Paul Banach