Reducing unneeded memory use

You should probably list off the specifics of your project because I have never see this in any of mine. If you start a new barebones project and just connect an input to an output do you still have the full memory allocated in the array?

Thanks. I was testing with 1701 code, is that the platform you were using, where apparently this doesn't happen?

And yes, even with a minimal project, just and input and output block, both the program memory and parameter memory are fully allocated:

#define PROGRAM_SIZE_IC_1 5120
#define PROGRAM_ADDR_IC_1 1024
ADI_REG_TYPE Program_Data_IC_1[PROGRAM_SIZE_IC_1] = {

...

#define PARAM_SIZE_IC_1 4096
#define PARAM_ADDR_IC_1 0
ADI_REG_TYPE Param_Data_IC_1[PARAM_SIZE_IC_1] = {

This is Sigmastudio 3.14. No matter the program, it seems that SigmaStudio eats up as much memory as it possibly can.

This really should be fixed, ADI. But for now, is there a clever workaround, aside from manually changing the #defines every time, and tolerating several thousand compiler warnings?

Doesn't seem to happen with the 1761 or 1452. I don't use any other processors regularly. I will note that I needed to manually zero out the memory in the 1452 to keep from getting panic flags. Perhaps zeroing out is also needed in certain circumstances on the 1701? I am unfamiliar with the part. I can say I used code to zero out the 1452 I don't actually pad the stored parameters\program data arrays from sigmastudio...

Right, I checked the 1761 and 1452, and it correctly allocates only the space that is needed. I haven't seen any issues with not zeroing the memory in the 1701, but it's worth looking out for. (Maybe I'll zero it before writing my program). I'm surprised that the 1452 requires zeroing, if the compiler doesn't force it. Seems like a lot of people would have problems.

ADI: In the 1701, do we need to fill/zero the 'unused' memory on a 1701? And can you add this corrected allocation feature to a future sigmastudio please?

The only problem I saw was the panic flag didn't seem to work correctly. Most users probably don't look at it I guess.

Hello

It is my understanding from the programming team that all the parts will clear out all memory before it loads in the program.

The panic flag issue I was told has to do with the USBi. Apparently it has to read past the last location of the memory in use and that triggers the flag. I personally have not looked deeper into this but this is what I was told. It should happen once you are running using a controller. Please comment if this is not the case.

Dave T

Thanks, Dave. Any information on the original question of memory usage reduction, or a workaround?

Hello Joe,

Been busy and have not had a chance to give this the time it requires. What is needed is to compress the file and then have the controller expand it out. Then write an App note about it. Just have not had the time to do it.

Dave T

Thanks. But I'm confused about your comments about compression and expansion. That shouldn't be required at all, nor is an app note needed. This should be considered a simple bug fix.

The compiler knows the program and parameter size, as they're both output to the "compiler_output.txt" file. The subroutine in SigmaStudio that exports the header files just needs to be adjusted so that the exported arrays use these sizes, rather than the full memory size, exactly as it already does for other devices, such as the 1761 and 145x.

I'm adding my vote for this proposed SigmaStudio feature that the exported header files are adjusted so that the program and parameter memory arrays are only as large as needed. As the original poster suggested, filling out to the limit of program and parameter memory just eats up space in my microcontroller code. Our current uC + ADAU1701 project is now running out of uC memory space which I am looking to reclaim by manually editing the SigmaStudio header files each time they are exported.

Thanks. Given Dave's comments above, I'm concerned there may be some misunderstanding of the issue within ADI. I hope this is added to a revision of SigmaStudio; it really is basic expected functionality, and should be a rather simple fix.

Hi.

I have been practicing reducing the exported arrays manually (using a custom made Python script).

But I have very recently been having issues with the DSP when not filling the entire memory sections with 0 (besides the actual used data).

The unused parts of the memory simply seems to be corrupted by "random" data after a reset. This might be an HW related issue on my side, but I just wanted to highlight that writing all 5012 bytes of program data and 4096 bytes and parameter data has saved my application from not "blowing up" when the unused sections of these memory blocks are holding these random values.

Best regards.