ΣSigmaStudio Ask AI Русский Log in

Cell settings of delay block

SigmaDSP & SigmaStudio AndyKay Feb 14, 2017 00:00 3 replies Original on forum ↗
Subscribe
AndyKay Question
Feb 14, 2017 00:00

I'm booting and controlling an ADAU1452 with an 8bit microcontroller.

In sigma studio I try to exclude RAM content of all delay-cells from export (see file "*_04A_IC_1.h") in order to keep the exported data array ( ADI_REG_TYPE Param_Data_IC_1[PARAM_SIZE_IC_1] ) as short as possible to save flash memory in my microcontroller.

Is there a possibility to exclude RAM content of delay-cells (a lot of 'unnecessary' ZEROs) from export to data array ( ADI_REG_TYPE Param_Data_IC_1[PARAM_SIZE_IC_1] )?

This would be a great feature!

I tried:

- right click on delay-cell -> Cell Settings -> Options -> Advanced -> File Content: Datas "Hirachy + Name (Doesn't Recall)"

---> no success. Does anybody know the effect/sense of this setting?

- right click on delay-cell -> exclude from Export Files

---> no success. RAM content (a lot of ZEROs) still contained in "ADI_REG_TYPE Param_Data_IC_1[PARAM_SIZE_IC_1]"

Can anybody give me a hint?

Related delay-memory-question:

ADAU1452 DM0 delay issue

Audio Signal Processors

adau1452

flash

memory

microcontroller

export

SigmaDSP Audio Processors

array

delay

Show More

DaveThib Reply
Feb 14, 2017 00:00

Hello Andy,

You touched upon something that I need to address and have not had time to. The files you are looking at are files that are not meant to be small and they are a legacy feature that some people had used in the past. What I think is the best way to solve this is to use the EEPROM hex file that is created when you want to make the part selfboot. It is reasonably compact although there are still a lot of zeros in this file as well. I suppose someone could compress this file even further but I digress.

The Hex file format is detailed in the datasheet. The section starts on page 41 in the Rev C datasheet. "EEPROM Self Boot Data Format" is the section.

You could read in this hex file with the 8-bit controller and feed it to the DSP. You would need to write the header as one long write then wait for the PLL to lock, then write the rest in what ever message size you like. The header starts with an 0xAA which is only used to confirm the file is a SigmaStudio program file and does not need to be written to the DSP.

You do not need to worry about the checksum. The DSP only looks at this when it is self-booting not when it is programmed externally. You could of course use the checksum in your controller if you like.

I plan to write an App Note about this in the future but it is not all that difficult to do so I think you could tackle this without too much help.

One other little thing you should know. SigmaStudio will NOT produce a hex file if there is not EEPROM present in the SigmaStudio program. Even though it can never write directly to an EEPROM that would sit on the master comm port, it needs it in the project to know that it has to produce the hex file output. This file will be stored in the IC2 folder. I am assuming that you only have one IC on the configuration page and that it is called IC1. So the EEPROM would be IC2.

Dave T

AndyKay Reply
Feb 15, 2017 00:00

Dear Dave,

thanks for the quick reply!

We also thought of using the EEPROM.hex instead of the looong arrays in the *.h-files. I think it's the only way to a solution for us at the moment.

What do you think about upcoming feature? Will the following be available in the near future?

(because there are many projects with ADAU-DSPs in the pipe at our company and we would really, really be happy to have these features...):

- sigma studio shall provide a possibility to exclude 'unnecesarry zero filled' RAM contents (e.g. delay-cells, reverb-cells) from export to *.h files and EEPROM.hex. (simple suggestion: maybe sigma studio could link the RAM-location of delay- and reverb-cells to the end of memory-sections (DM0, DM1, param) and cut the zero-filled-bytes during export...?)

- sigma studio shall provide a possibility to enter SIZE_MAX of exported arrays in order to "respect" the compiler possibilities of an (8bit) microcontroller. (In our case, the compiler can only compile arrays up to 32767 bytes)

Regards, Andy

ADIApproved Reply
Feb 16, 2017 00:00

Hi Andy:

Those are good ideas for future feature implementation. For now, did you consider simply parsing this file to somehow break those unnecessary long zero sequences.

Depending on the application, it might be that you will still need to clear that memory (if the memory for example is not clean) however, you can do this with a more optimized "For loop"

Please comment.

Miguel