Overview
FM4, S6E2DH/S6E2DF/S6E2D5/S6E2D3 Series, 32-Bit Microcontroller, Graphic Driver User Manual, Doc. No. 002-04387 Rev. *A
26
4.7 Memory Management
Different to many other graphics drivers the 2D Graphics Driver for S6E2D does not include or use any memory
management routines (dynamic memory usage). However memory is required for different functions:
4.7.1 System Memory:
System Memory is a memory block assigned to the CPU as operating memory for OS and application. The driver
requires some static memory blocks that should be assigned by the linker to this block. In the reference
implementation, S6E2D’s SRAM0 is used for this purpose.
2D Graphics hardware blocks can read and write system memory. Typically the 2D Graphics components should
not be configured to access system memory because especially frame buffer and similar operations are optimized
for the VRAM access.
4.7.2 Video Memory (VRAM):
The Video Memory is a dedicated memory block inside the Graphics hardware designed to store graphical content.
The VRAM is also used as command list buffer. Therefore, it is required that the CPU must also have access to the
VRAM.
4.7.3 Flash Memory:
Program code and image data are typically read from (embedded or external) flash memory. In most of the example
applications, the embedded flash is used for code and external (hyper) flash for data used by the graphics engine
("RES_SECTION"). This is accomplished by a linker directive (see flash_resource.h).
4.7.4 Physical Address - Virtual Address
In this document, in particular in the Surface API description, the terms Virtual Address and Physical Address are
used.
For S6E2D devices the physical and virtual address of a register or memory block are identical because the
hardware does not contain a Memory Management Unit. Such a Memory Management Unit is typically used by
complex operating systems to assign different applications or drivers individual (virtual) memory ranges different
from the real physical addresses. If the 2D Graphics Driver is used in such a system an address type differentiation
and translation is required and therefore the driver partly supports both types.
Because the 2D Graphics Driver was developed using a software model of the 2D core that requires a differentiation
of physical and virtual address, some tutorial examples use an address translation macro. The macro does not
change the address for the final 2D Graphics Driver.
