Dynamically Allocate and Access Memory in .text section of Arduino Mega 2560

[kush_g]

Hello, this thread is meant to be a continuation of Receiving wrong values from four 32000 char arrays (Arduino Mega) that I created some time back.

Backstory:
In the thread linked above, I was able to statically allocate 128KB of memory in an Arduino Mega using 4 unsigned char arrays, with the help of @guix, which are being placed in the .fini1 subsection of the .text section. After this, I am able to get 32 bit pointers using pgm_get_far_address and read the bytes there using pgm_read_byte_far.

Present:
I am now trying to create a library that will work with AdafruitGFX to use WaveShare colour e-Paper displays. Since the refresh time for these displays is >30 seconds, it makes the most sense to use with a display buffer for all the drawing functions, and send it to the actual display with another dedicated function. I am trying to create something similar to the Adafruit SSD1316 Library, which uses a buffer for very small 1 bit displays.

As there are many similar displays with varying resolutions, I want to dynamically allocate (malloc or new) enough memory (max 150KB I guess? ) for a buffer in the .text section, since we saw that .data wasn't large enough.

I also looked here:

• Avr-Libc Memory Sections
• Avr-Libc Memory Areas and Using malloc()
• Avr-Libc Data in Program Space

The last article seems to imply that only constant data can be stored in the program space. I wanted to ask if this is true and what options I have to dynamically allocate and manage ~150KB on an Arduino Mega for this buffer.

Any help/insight is much appreciated. Thanks!

[Coding_Badly]

@kush_g

...if this is true...

For all practical purposes it is.

@kush_g

...what options I have...

External RAM.

Is it necessary to have a complete frame buffer? Can the display be updated in sections?

I am curious to know why you don't use a processor with more RAM.

[Koepel]

When there are multiple large PROGMEM sections, the libraries that use PROGMEM might not work anymore.
I recently learned that the Optiboot bootloader has now included the possibility to write to Flash. You might have to burn a new compiled bootloader.

Combining multiple large PROGMEM sections, with another PROGMEM section that can be written during runtime, makes me feel uncomfortable.

It was fun as a exercise, but you have already gone too far with this. This is not standard Arduino programming anymore. You should not look for trouble when you don't want trouble. Leave all these troubles behind you and continue with (for example) a ESP32.