This is probably really simple, but I'm failing dismally in my attempts so far.
I want to load a 16kb array of 8-bit ints into a table in SDRAM.
I don't want to load it from a file, as I want to roll the data into a custom 'ROM' object.
I need need to be able to access the table by reference, in another object, as with the Factory table alloc/read objects.
Could anyone tell me how this is done?
a|x
have you looked at the table read object?
simplified it reads (the rest is to do with checking limits and scaling)
x=attr_table.array[n];where attr_table has to be an objref parameter.
if you don't want the table to be user selectable (which would be less flexible/user friendly).
I think it generates to something like parent->objname->array[x], but check the generated xpatch.cpp, as I think objname has a prefix/suffix, but can't remember what off-hand.
(this is essentially what objref parameters get expanded too, can be used for all sorts of things when you want to access another objects data etc... just be careful of execution order!)
If you're passing full initialization data in object code, the initialization data will be in SRAM, and you may as well use it from there. I mean, you'll not save SRAM space by copying initialization data to SDRAM.
Hi @thetechnobear thanks for getting back to me. It's writing the array to SDRAM that I'm struggling with, currently, rather than reading it. I'm sure I'm being really stupid, but I can't work out how/where to initialise the array in SDRAM with the data.
a|x
Hmm.. OK. There must be a way to load data directly into SDRAM. My problem is there's too much data to fit in SRAM.
a|x
Oh hang on... so the alloc 8b sdram object works on the basis that the data is first loaded into SRAM, then transferred into SDRAM from there... I seeeee....
So the only way I'll be able to load more data into SDRAM than will fit in SRAM is to load it from a file.
That makes sense, now I think about it I think, since I guess if the data is too big to fit in SRAM, the Axoloti would never be able to recall the patch without being connected to the computer.
a|x
Can I just double-check that it IS in fact possible to load a file that's larger than the available SRAM directly into SDRAM?
Incidentally, exactly how much SRAM and SDRAM memory is available?
a|x
sorry, I'm getting confused here....
writing, is the same as reading and no different for sram or sdram
using SDRAM rather than SRAM is down to how the array is allocated... eg.
static int8_t _array[LENGTH] __attribute__ ((section (".sdram")));is this what your after?
EDIT:
I guess Im totally missing your point, as this was the same thing you asked and answer in a previous thread
https://sebiik.github.io/community.axoloti.com.backup/t/object-using-sdram
size available are included in here:
That's what I thought. I think I'm confused, too...
I tried doing
array[0] = 0x29;
...
array[16360] = 0x00;in the Init field of an table/alloc 8b sdram object but get an error:
Applications/axoloti_runtime/platform_osx/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: regionSRAM' overflowed by 124872 bytes`
a|x
the access you show wont cause overflows.
as i said, Id need to see your allocation of the array. I can only guess for some reason, the attribute is not applied properly. (it defaults to SRAM, so if its wrong, this would be expected)
EDIT: its probably easier if you upload a test patch with the relevant object embedded. then we can see what the issue is/what you are trying to do.
(minimal patch, with just your allocate/read/write nothing else 
)
ok, but this is as @johannes pointed out...
in your init code you are allocating an array for the initialisation data, and that is in SRAM.
but the issue is you cannot put that constant data in SDRAM, which means there is no point in copying it there, as you have already allocated the memory to hold the initialisation data, so you might as well use as is.
The only way to supply initialization data in SDRAM without adding data in SRAM is loading the data from sdcard. "table/load" shows how it is done.
The "table/alloc 8b sdram" does not transfer data from SRAM to SDRAM. But it can supply initialization code, which will be in SRAM, if that code transfers a ROM image to SDRAM, the initialization data is still in SRAM.
Hmm.. so what's this object actually for, then? If all the data is stored in SRAM, anyway, then as you said before, why not just use it from SRAM?
a|x
The initialization code can compute values to write into SDRAM. Such computation code will often be quite small. But not if you use this to copy a ROM image.
I'll do it that way, then.
Sorry for the silly questions, guys, and thanks for your patience answering them..
a|x
So presumably the load from file object loads the file a byte at a time, and transfers each byte to SDRAM.
a|x
Hang on though, if there's 256kb of SRAM, and my patch contains just the one alloc 8b sdram object, why is it overflowing the SDRAM trying to allocate 16kb?
Is there a hard limit on the amount of SRAM a single object can use?
a|x