Loading Binary Data Into SDRAM

#3

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.

Programs to edit or create table files for Axoloti?
#4

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

#5

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

#6

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

#7

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

#8

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:

#9

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

#10

Sort of, but my answer there doesn't seem to work (see above).

a|x

#11

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 :slight_smile: )

#12

Here's the latest version of the patch.

TableAllocRead_test01.axp (84.2 KB)

a|x

#13

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.

#14

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.

#15

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

#17

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.

#18

I'll do it that way, then.
Sorry for the silly questions, guys, and thanks for your patience answering them..

a|x

#19

So presumably the load from file object loads the file a byte at a time, and transfers each byte to SDRAM.

a|x

#20

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

#21

I believe it goes from sdcard to sdram without even touching sram.

#22

just checked, for my own interest :slight_smile:

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)

#23

Sram overflowing or sdram overflowing?
Literal assignment code like
array[0] = 0x29;
expands to multiple bytes of binary executable code.

There is no per-object limit.