just checked, for my own interest 
goes via fbuff , which is a 256 byte buffer in sram2. this is of course reused across objects.
(so may have to be careful if multiple loads being done in separate threads!?) ... also used by pconnection.
(streamer has a different implementation I think, but not checked)
Sram overflowing or sdram overflowing?
Literal assignment code likearray[0] = 0x29;
expands to multiple bytes of binary executable code.
There is no per-object limit.
Oops, I meant overflowing SRAM (see error message above).
Shouldn't the extra SRAM used by the assignment operation be freed up after each assignment, though?
If not, I guess that would explain where all the SRAM went..
a|x
Are there any objects that actually use explicit C memory-assignment/garbage-collection commands?
I must say I was a little surprised not to see any of that in any of the objects I've poked around inside (bear in mind that my very basic C knowledge dates back to the end of the last century..).
Maybe all that stuff is handled behind the scenes.
a|x
You've got me thinking here if this is possible. A memory segment containing initialization code could be re-used for other things, but it must be certain that those other things are not accessed by the initialization code. So how are those other things initialized? A "2nd stage" initializer for blank memory only? Potentially a source of confusion and weird errors...
Patches use static memory. Garbage collection is not real time. Dynamic memory allocation can cause memory fragmentation, and overflow during runtime. With static memory, the compiler knows before running the patch.
It's just occurred to me:
Given that simply assigning a value to an array item is about as simple an operation as you can do, isn't any Init routine in the table/alloc object that attempts to fill a largish array in SDRAM going to hit a similar issue (ie running out of SRAM before it manages to fill up the array)?
I was only trying to fill 16kb, the object size attribute allows for the creation of much larger arrays than that.
a|x
When the initial values are computed in a loop, the resulting binary code size can be pretty small.
Interesting. That seems counter-intuitive. Is it because 'working memory' (i.e. memory used to perform the computation) is reused more efficiently, in this case?
a|x
Yeah, if you're doing it in a loop then all the variables inside the loop are only allocated once. Say you're computing a stupidly high-resolution sawtooth wave:
int wave[] = .... // array in sdram
for (int i = 0; i < 65535; i++) {
wave[i] = i;
}
That's only going to use one word of working memory for the counter, but it'll fill a 64k look-up table.
I see. But if I do
array[0] = 0x5a;
Would I be right in thinking that 8 bits of SRAM are required to allocate that value to SDRAM, plus some extra RAM required to do the assignment itself, and that memory is never reclaimed?
Just getting things clear in my head..
a|x
If you just put a long line of assignments like that, it's going to get put into the actual executable code as constants. This is stored in Flash/ROM, but the patch might get loaded into SRAM on start up, I'm not sure.
patch code is loaded into SRAM, only firmware into flash.
(limited flash cycles and size/length of time it takes to flash)
using explicitly assignment I expect be less efficient than using a static array of data.
the former creates lots of instructions, the later simply calls an initialiser when the patch is loaded.
(both use sram, as both .text and .rodata go into sram ... see ramlink.ld)
if this was a normal use case, I wonder if you would move .rodata to sdram....
(I suspect there would be performance issues with this move)
EDIT:
in your example, try to make your array a constant... see if it uses less memory.
(I'm wondering if your getting 2 copies, one in .rodata and one in .bss, both for a patch reside in sram,
it may not be happening as it may be optimised out by the compiler when it sees no writes, but worth a try to save sram)
I'll give that a go. I'm going to focus on loading the data from file first, now, though.
a|x