Looking at the memory report in p#3267 - can the sketch really get all dynamic memory: "local variables >> Maximum is 1048576 bytes" ?
No, not really. The memory organization of this chip is far more complex than can be fully shown by Arduino's simple summary. Trade-offs had to be made. I went with showing an aggregate of all RAM usage, with the consequence of finer details obscured, but at least no static allocations (known at compile time) should be hidden from the total.
Is no code moved to RAM if used by the sketch?
Nope, it works pretty much the opposite of that. Whatever code you have that is *not* marked as PROGMEM gets put into RAM first. Then the rest of the RAM (rounded to the nearest 32K boundary) is available for variables. Or at least the rest of the first half. The 2nd half is always dedicated to DMAMEM and malloc().
Like with AVR, you can save RAM by using PROGMEM. Unlike AVR, it applies to functions as well as variables. Also unlike AVR, everything is always accessible by ordinary C/C++ code, so no need for stuff like pgm_read_byte().
And the sketch make 'Global variables' that cross all boundaries and fill RAM?
Oh wouldn't that be nice. But no, the linker doesn't work that way. Neither does the hardware, really, since ARM designed the M7 core with 3 different buses and NXP built the chip around that approach.
Allocations at run time - like Audio Buffers - or malloc() are not included in the compile time allocations from the dynamic RAM.
This is true for malloc() & C++ new. But the audio library does not use malloc. Instead it uses a static allocation, depending on the AudioMemory() line in setup(). The audio lib then does its own allocation from that fixed amount of memory. I designed it this way so the audio library would have 100% deterministic timing.
I'm sorry, I should clarify that I increased the delay times in the example to 1100 2200 3300 respectively. Before, this showed no difference from the unaltered example.
Noting that I'm not entirely sure this *worked*. It only compiled and uploaded.
Using the audio delay, the memory for storing the sound comes from the AudioMemory() buffers. If you configure longer delays, it simply uses more of that memory. If you use too much, so the audio lib runs out of RAM, the audio will stutter or stop.
The T4B1 I got has unfortunately not enough RAM for that experiment but 512K of OCRAM in the T4B2 for the 68000 would be enough
Please email Robin directly. We'll send you the latest beta hardware. If we're sending to Europe, please let her know if you prefer UPS or DHL.