0

I am building a real time audio application using the Arduino DUE. This application needs big arrays like:

uint16_t sDelayBuffer0[46000];

The Due has only 96kb of RAM available so this array just ate up most ot its memory. The problem is i need more arrays like this...

So, i was thinking, instead of declaring all of the arrays as global variables, to declare them inside the timer interrupt functions.

The loop() handles stuff like reading the ADCs. The actual effects are coded inside timer iterrupt funciton that are replayed over and over. So the code constantly loops in loop() and the selected timer interrupt function.

But other timer interrupt fucntions use other arrays. So i was thinking to declare every array that a corresponding timer interrupt function wants inside that fucntion.

So all arrays are not declared at the same time (since when we exit the timer interrupt function we were on and head either to loop or another interrupt function, the grabage collector will destroy the array right?)

The problem with this theory, is that this is a real time audio application. So is it wise to constantly declare a big array like this? Since the timer interrupt ficntion will run very very often. Won't i have delay problems iwth the actual sound? Or variable declarations happen extremely fast inside the CPU, even for big arrays?

Improve this question
8
  • 2
    Have you considered a simple compression algorithm to allow more samples? 8-bit DPCM (-127..127 and escape for full value) for instance.
    – Mikael Patel
    Jul 14, 2017 at 13:25
  • 3
    What are you planning on doing in the timer interrupt that requires an array of 46000 integers?!?! It certainly can't be anything fast (and thus not suitable for running in an interrupt) if you need to process that much data every time...
    – Majenko
    Jul 14, 2017 at 13:36
  • The loop() reads the ADCs that contain the information from the guitar. The place to store it is the big array. The effect is applied and then it is sent to the DACs. This is all working by now. But i want more space. So i was considering instead of declaring the arrays as global variavbles - which is not possible. To declare them inside the corresponding timer interrupt function. But i dont know if declaring something this big, something that will be declared over and over again is viable in a real time audio application
    – user1584421
    Jul 14, 2017 at 13:48
  • 1
    It sounds like you think you can access a variable declared in one function from another function. You can't.
    – Majenko
    Jul 14, 2017 at 14:12
  • 1
    It does sound very much like a classic X-Y Problem.
    – Majenko
    Jul 14, 2017 at 14:57

2 Answers 2

Reset to default
2

The problem is i need more arrays like this...

you probably want to take a look at your processing flow to see if you need all of them at the same time. if you do, well, there is no alternative but to get a bigger chip.

Improve this answer
3
  • No i do not need them at the same time! This is why i am thinking to declare them inside the functions. So as we move to another, the garbage collector destroys the previous array and space is freed up for the next array to be declared.
    – user1584421
    Jul 14, 2017 at 13:34
  • If you declare them as local variables, it should be ok, just make sure you have enough space in all cases.
    – Michel Keijzers
    Jul 14, 2017 at 14:04
  • If you don't need them all at the same time then declare a single array as a global and use the same array everywhere. No reason why you can't re-use the same variable for a different use in a different function as long as you can be sure you won't try to use it both ways once. And as others have said, nothing involving creating and pressing 46,000 values should ever be done in an interrupt.
    – Andrew
    Jul 14, 2017 at 15:27
0

First, I don't think it's a good idea to use 46000 * 2 = 92000 bytes of SRAM. That leaves only around 4K left. I hope you don't use a big stack trace, local variables or other global variables.

I don't know if creating an array costs a lot of space, anyway, constantly creating and removing arrays (in heap space) will make your free memory space a mess. This means, that after some time you cannot allocate arrays anymore, especially big ones which need consecutive memory.

Also, within interrupts the code should be as least as possible.

I suggest you use some arrays and reuse them for different reasons. Keep the name simple (like buffer), and reuse the array when needed, without the need to declare it and destroy it. This keeps your memory clear. Make sure the size is big enough for the maximum/worst case you use it for.

Update:

The above mostly assumes that the arrays are made in heap space, not as local variables. However, using local variables is ok.

But anyway, if you need a 2-byte 46000 array, don't expect to be able to use more arrays. In that case use external SRAM (like 23K256, 23LC1024).

Improve this answer
7
  • I have already ordered a 23LC1024. But wiating for it to arrive, i am thinking some hacks. Because maybe the time to read/write to an SPI external memory is too big for real time audio applications. Other than that, the code is really small in the timer interrupt functions.
    – user1584421
    Jul 14, 2017 at 13:25
  • I suggest you do some timing tests (how long it takes to declare/destroy an array). Garbage collection inside interrupts I wouldn't advise. Better to declare them as local variables on the stack (and make sure you have enough memory left). You also can test for current free memory.
    – Michel Keijzers
    Jul 14, 2017 at 14:05
  • Declare them as local variables on the stack? This is the first time i read of theis concept. Can you post a link or something?
    – user1584421
    Jul 14, 2017 at 14:12
  • @user1584421. Local variables are allocated in the stack. Where else?
    – user31481
    Jul 14, 2017 at 14:33
  • @Michael. Allocating space in the stack cost nothing. And it's freed after return from function. You are thinking about heap space.
    – user31481
    Jul 14, 2017 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.