Is there a good reference for Arduino Due memory architecture and usage?

Question

It's been harder than I expected to find a reference source or usage guide.

There's a number of sources I've looked at along the road to this question:

• The Due is listed here and here as having 512KB flash memory, 96KB SRAM and zero EEPROM.

• The arduino foundation tutorial notes that Due memory architecture is different but doesn't expand further.

• @Majenko's answer to this previous question notes, "There is no PROGMEM required on ARM. There is no memory bus separation between Flash and RAM"

• The SAM3x datasheet block diagrams show a unified bus (i.e. Von Neumann architecture (not Harvard architecture like the AVR boards))

  

• This answer on the Arduino Forum suggests (regarding allocating constants to flash), "[...] all you have to do is use "const" in the variable declaration. [...] Everything that's "const" gets put into flash without consuming any RAM. PROGMEM, pgm_read_byte() and the other AVR names are defined only so code designed for AVR can compile. But they do absolutely nothing on [SAM3X MCUs] "

• The F() macro seems to still work.

So my question is searching for links to a reference or guide for memory usage on the Arduino Due. I hope a guide (or your answers) might explain the differences caused by the change to a Von Neumann architecture bus, what is stored where, highlighting which memory handling techniques developed for Harvard architecture AVR MCUs remain relevant on the Due.

If there is no guide I'm hoping this question and your answers may become a good reference point. Thanks for reading!

Answer 1

Yes, the Arduino Due uses a flat memory model with a single address space for Flash and RAM. Therefore all constant data sits in flash and does not need to be copied to RAM at startup, like the AVR-based arduinos do. The progmem stuff for the AVR-based CPUs is required because they need to use different instructions to read data from flash than from RAM. This is no longer the case on the Due (nor most other 32-bit MCUs, such as the ESP32), and a string address in an instruction works just the same whether its in RAM or in Flash (as long as it's not written to, of course).

The F() macro is available for convenience, so that you can more easily write code that works for all Arduino boards. On the Due, it is basically implemented as no-op.

When you're working on the memory model of the Due, I might point to this question, showing that there's a bug in the memory management implementation of the Due, allowing unlimited memory allocation.

Answer 2

So (review feedback welcomed) in the Arduino Due SAM3x memory architecture compared to the AVR architecture:

Non-volatile flash memory

contains:

• program instruction code (same as AVR)
• bootloader (same as AVR)
• all runtime C++ constants including incode string literals (different to AVR)

is accessed by:

• C++ const data definition code and incode literals (different to AVR)
• C++ instruction code (same as AVR)
• PROGMEM, PSTR(), F(), pgmspace library *_P functions are not required and compile for platform compatibility only (different to AVR).

Volatile SRAM memory

contains:

• variable dynamic storage, organised in a stack and heap structure (same as AVR)
• no static/constant storage, which now stays in flash (different to AVR)

is accessed by:

• C++ data definition code (same as AVR)

Usage

• Heap fragmentation remains an issue to be managed. Preferencing local to global allocation, and avoiding dynamic heap allocation remains relevant to Arduino Due (e.g., Arduino strings)

• Techniques to move constants to flash memory are not relevant for Due, but may be relevant for multi-board compatiblity.