Buffers and memory allocation on sam board

=

Hi TeylorW,

Thanks for reaching out! Please find my responses to your questions below:

1. Yes, you can use the #pragma section directive to place variables in specific memory regions, such as external DDR RAM, as you have shown. Similarly, you can use the same directive to store data in L1 or L2 memory by specifying the appropriate section names, such as "seg_l1_block0". These section names are defined in the linker description file (.ldf), which controls how memory is allocated in the project. You can refer to the default .ldf for the processor, which can be found in the SHARC/ldf directory of the CCES install.

2. Since your uses ~1MB, storing it in external SDRAM is recommended. For smaller effects in series, you should use separate, smaller buffers — ideally in L1 or L2 memory. To cascade effects, simply pass the output of one effect as the input to the next in your processing loop.

3. To verify memory placement, you can generate a map file for your project by going to: Project Properties > C/C++ Build > Settings > CrossCore Baremetal C++ Linker > General and then enabling the "Generate symbol map" option.  This will produce a detailed memory map showing how your variables are allocated across L1, L2, and external memory. For more detailed information, the Linker and Utilities Manual (cces-LinkerUtilities-manual.pdf) from Analog Devices is a great resource on memory sections and the use of #pragma.

Best, 

Aradhita

I am sharing a document that provides additional details regarding the LDF modification for your reference. Hope it helps with your query.

PDF

Thank you very much, this clears up a lot.

Some other questions regarding the signal chain popped up as I was reading your response.

1. For smaller effects in series, is it necessary to have separate smaller buffers within each effect module if I can just read the input and send out an output? Do I need a buffer to store temporary data if no long history is required? I guess what I'm getting at is can these smaller effects simply apply their processing on a buffer of the auido_block_size that is getting passed into them?

2. Processing audio in blocks (using the default block size of 32 stored in "AUDIO_BLOCK_SIZE") should I have the for loop (int i=o;i<AUDIO_BLOCK_SIZE;i++) inside of callback_audio_processing so that when each effect processing function is called, it operates on one index of the block? Or should I have the for loop inside each effect processing function as I have in this example:

Hi Teylor, 

Answering your questions below:

1. Yes, smaller effects can be processed directly on the passed-in audio_block_size buffer. No extra internal buffer is needed unless history is required. It's generally not necessary to allocate separate internal buffers beyond the input/output buffer passed to the module.

 2. If only a single effect is needed, a dedicated processing function can be created and added as a case in the audio_effects_process_audio_core1/core2 function. This function would operate on the entire audio buffer, keeping the structure simple and centralized. However, for multiple effects in sequence, it's more efficient to perform all processing within a single for loop inside callback_audio_processing. This avoids repeated buffer copying and function calls, reducing overhead and improving performance, especially in real-time audio systems.

 3. As for cascading effects: yes, effects can be chained together as you described. In the framework, the audio_effects_process_audio_core1 function uses a switch-case routine to select and apply different audio effects. This design is specifically intended for use with the Audio Fin board push buttons, where each button press corresponds to a different effect being applied. The switch-case structure makes it easy to map button inputs to specific processing routines. For more details, the official documentation provides a helpful overview: Introduction to the "Audio Elements" and "Audio Effects" [Analog Devices Wiki]

Best,

Aradhita