5.1 Memory Consumption: Frame Buffer, Scratch Buffer, Fixed Heaps and FreeRtos Heap

The PIC32CX-BZ6 is equipped with 2 MB of program memory and 512 KB of data memory. The main contributors to data memory consumption are the FreeRTOS heap, frame buffer, scratch buffer, and fixed heaps. The main contributors of program memory are images, Fonts, and other graphics data. Both projects have different ways of optimizing and storing the above main consumers.

One commonality is shared among both projects which is the FreeRTOS heap size. The FreeRTOS heap size for both projects is 100,000 bytes and is stored in internal data memory. This allowed for safe operation and testing.

Bluetooth® Low Energy LCC Project Consumption:

For the Bluetooth LE LCC project, the frame buffer is stored internally. The frame buffer size in bytes is represented in the following equation: Frame Buffer = (x pixel resolution) * (y pixel resolution) * (bytes of color depth). Therefore, for the Bluetooth LE LCC project using the 480x272 WQVGA display and 8 bpp, the equation is: 480 x 272 x 1B = 130,560 bytes. This memory cannot be optimized but the location is the only controlling factor that is internal for Bluetooth LE LCC.

The scratch buffer is also a large consumer of data memory usage for the Bluetooth LE LCC project. The scratch buffer is used to temporarily draw portions of the screen before rendering. If the entire screen is updated at a single time, then the scratch buffer will need to be the same size of the frame buffer to avoid any partial sequential rendering of the screen. If the scratch buffer is smaller than the portion of screen that is being updated, then the rendering of new data will be in separate noticeable portions. In the case of the Bluetooth LE LCC project, it was observed that only 338x252 pixels are updated at a time. Therefore, the scratch buffer is set to 338 x 252 x 1B = 85,176 bytes. This allows for smooth transitions between screens with only a single noticeable render of the new screen. The scratch buffer size can be minimized but the screen transitions will not be smooth. See the BLE and LCC Transparent UART for more details on scratch buffer optimization for the Bluetooth LE LCC project specifically. Also see Optimizing the Scratch Buffer Size page for more general details about the scratch buffer.

The final main contributor of data memory usage for the Bluetooth LE LCC project is the fixed heaps. The fixed heaps are used to store persistent information, mainly about the widgets. Therefore, the fixed heaps can be minimized corresponding to the amount of widgets used. There are 6 fixed heap pools used by the graphics library (16 byte, 32 byte, 64 byte, 128 byte, 196 byte, and 256 byte). In the case of the Bluetooth LE LCC project, the total size of the fixed heap pool was minimized to 23,892 bytes. See the BLE and LCC Transparent UART for more details on fixed heap optimization for the Bluetooth LE LCC project specifically. Also see Optimizing the Memory Manager Settings page for more general details about the fixed heap pool.

Considering the main contributors of data memroy and all other consumers, the total data memory usage for the Bluetooth LE LCC project is about 360 KB, leaving about 152 KB of data memory for further development.

Since the images are stored in RGB 332 format, the program memory usage is not very high for the Bluetooth LE LCC project. The total program memory usage is about 575 KB, leaving almost 1.5 MB of program memory for further development.

Bluetooth® Low Energy Parallel 8080 Interface Project Consumption:

As mentioned earlier, the frame buffer is stored externally within the LCD for the Bluetooth LE parallel 8080 interface project. This will not consume any memory within PIC32CX-BZ6, but the 320x480 display at 16 bpp used in the Bluetooth LE parallel 8080 interface project will consume 320 x 480 x 2B = 307,200 bytes on the external data memory.

The scratch buffer, however, will be stored internally for the Bluetooth LE parallel 8080 interface project. Since we are using a larger color depth for the Bluetooth LE parallel 8080 interface project, the scratch buffer will need to be equally large as the frame buffer for entire screen updates. Most of the screen updates in the Bluetooth LE parallel 8080 project do not update the entire screen, so to save data memory, the scratch buffer was set to half of the frame buffer. For more information about optimizing the scratch buffer for the Bluetooth LE parallel 8080 project specifically can be found in the BLE and Parallel 8080 Interface Transparent UART. More general information on scratch buffer optimization can be found on the Optimizing the Scratch Buffer Size page.

The same concepts explained above about fixed heap size and optimization for the Bluetooth LE LCC project can also be applied to the Bluetooth LE Parallel 8080 interface project. For this project, the fixed heap pool size was minimized to 3,828 bytes. See the BLE and Parallel 8080 Interface Transparent UART for more details on fixed heap optimization for the BLE Parallel 8080 project specifically. Also see Optimizing the Memory Manager Settings page for more general details about the fixed heap pool.

Considering the main contributors of data memory and all other consumers, the total data memory usage for the Bluetooth LE LCC project is about 281 KB, leaving about 231 KB of data memory for further development.

One tradeoff with a higher color depth is that images will take up more space in program memory. The Bluetooth LE parallel 8080 project uses multiple images to showcase the higher color depth, so the total program memory usage comes out to almost 1 MB leaving another 1 MB for further development. The images used in graphics project are application dependent, so this program memory usage can be increased or decreased. For example, the opening screen shows a coffee maker image that uses about 212 KB of program memory. User can customize these images if more program memory is needed.