SRAM overflowed

[berzelius]

Hi,
I have this error:
"region `SRAM' overflowed by 208 bytes
collect2: error: ld returned 1 exit status"
It comes when I put some more objects in my patches. The DSP load is 61%. Everything works fine untill I insert an new object even without connection.
When I delete the object the error disappears. Objects are kfilters and gpioin, but it appears on other objects either.
My patch is too big? Any idea?
thanks for the help

[SmashedTransistors]

Hi @berzelius
SRAM is the internal RAM of the microcontroler. It is not large.
Some delay lines or all pass filter may cause this problem.

You can reduce their size or use modules that will use SDRAM.

[jaffasplaffa]

Hey @berzelius

One way to save SRAM is to go to the dropdown menu /View/Settings and then set all settings to zero. Modulation sources/destinations/everything to zero. This can save you a little bit of SRAM.

Another suggestion could be to use SDRAM version of objects instead of SRAM versions. If you for example are using the "delay/write" object. Try changing it to "delay/write SDRAM" version. That one uses the SDRAM instead of SRAM.

But it is hard to tell what exactly is going on, when we cant see the patch. You could post the patch or just a screenshot of it. That would make it easier to help you out

Anyway, hope you find this useful.

[Blindsmyth]

check this out:

Using precious resources

Overview The axoloti board is a powerful board, but like everything it has only a finite amount of memory and processing power. The good news is axoloti is also very flexible, so there are lots of ways to get to similar results! Here are some tips about how to best make use of the resources it has. General Dont get too worried about 'optimisation' when creating a patch, its better to make it understandable and functioning initial - but try to keep it efficient as you build it. Keep it …

on a very abstract level there is everything you need in order to optimize your patches so that they consume les ram.

More concrete for me the 2 most important tricks apart from the ones mentioned already are:
1 Execution Order: Always work from left to right, up to down. upwards connection can cost you a lot, especially the red ones
2 all user interface stuff costs ram, that's dials you can twist, displays, scopes. So once you decided for fixed paramater use const i instead of the dial, and once you know everything is working delete the displays, scopes etc.
Also if you're working with a midi controller do it like this (avoids the dial = less ram usage):
Uploading...

The good thing about this is: Once youve reached the limit, you get aware of what you're doing and you need to learn how to use your resources wisely

[berzelius]

Thank you all, I got a better understanding of the board. I'll try these tricks.

[berzelius]

@Blindsmyth, very good tricks to know! works fine now.

[jaffasplaffa]

Always work from left to right, up to down. upwards connection can cost you a lot, especially the red ones

I look forward to being able to see how much of each memory is actually being used. If I remember correct, this is something that will be implemented some time down the road.

[Blindsmyth]

I look forward to being able to see how much of each memory is actually being used. If I remember correct, this is something that will be implemented some time down the road.

True that. But once you're at the limit it's a good way to find out what kind of stuff costs you unnessecary ram