ADAU1701 - Exported system files are way too big
When exporting system files for my SigmaStudio code, the compiler of course knows the data and parameter RAM utilized by my code, but when the system files are exported, the arrays for the program and parameter data are way larger than they need to be. Sigma Studio exports these arrays as if my code were FILLING the ENTIRE size of available RAM, rather than what is needed by the code.
This makes the memory required in my microcontroller far larger than it needs to be.
Of course, I can edit these manually before building the microcontroller code, but that's quite tedious and really should be unnecessary.
SigmaStudio knows exactly how many bytes the Program_Data_IC[] and Param_Data_IC[] arrays need to be. Why can't it just use those numbers (and export the correct array size) rather than filling the entire memory?
Seems like a pretty easy fix. This has been a problem for years. Why can't this be fixed?
Similarly, is there a workaround, like a script/batch file to automatically change the #define PROG_SIZE and PARAM_SIZE? I'll still get thousands of compiler warnings, but at least I don't have to manually edit them every time.
Audio Signal Processors
memory
microcontroller
sigmastudio
SigmaDSP Audio Processors
adau1701 sigmastudio
adau1701
Show More
Hello,
We do not currently have this option for ADAU1701. Some of the newer SigmaDSP processors do have this option.
If you write a script or manually edit the exported files to exclude the zeros, I would recommend that you still initialize all of the registers. You could write the registers with 0s in a loop to save memory on your microcontroller.
Regards,
Joshua
A lot of people have been asking for this feature, so here is a Python script which removes the ending zero initializations for ADAU1701. It was written in Python 3.8 and should be compatible with any Python 3 release. You will need to change variables in the first 3 lines to make the Python script recognize your files.
Depending on your SigmaStudio program, some of the zeros in param memory might have been allocated to hold audio samples (for delay, filter history, etc). If these memory locations are not initialized properly the audio might sound pretty bad when the DSP first starts up.
One solution is to write your own setup function based on default_download() which, after loading the now-truncated memory packets, iterates through the remaining memory to ensure these registers are at 0 before the DSP core is started.
remove_zero_initializations.zip
Thanks! This will help for now, but please be sure this is strongly recommended as an addition to future Sigma studio releases.
Please log in to reply.