sigmaDsp cofig by microcontroller use I2C?

We have a tutorial using an ARM Cortex processor available here:

How do I create the microcontroller code to interface to my SigmaDSP?

The example contains a tutorial and full source code.

If you microcontroller is programmed in assembly and does not have a C compiler, then this tutorial might be useful:

Booting a SigmaDSP from a microcontroller with no C compiler

Brett,

For the product I've been working on, I finished the ADAU1701 project while a fellow engineer wrote the C code for a PIC processor which also boots the -1701. After boot, these two ICs only communicate via a few GPIO lines. Presently the DSP config is embedded in our PIC-C code -- when needed I copy and paste the new Program RAM, Parameter RAM, and Core Register code from the TxBuffer_IC_1 export file, writing over the old stuff in the source. This works fine, for now.

We're thinking about a second application where run-time I2C will control EQ, etc. Before getting involved with safeload writes and so forth, we would like to make our boot operation work like the AD tutorial. In this way we hope to be on the same page with this forum when needing help later on (does that make sense?). Also, I read that the TxBuffer file is actually from a legacy export method, another reason to change.

Problem is, the tutorial's example files confuse me (my C programming skill keeps me chasing missing semicolons). The example boots its ADAU1761 with 35 groups of I2C writes, while my present project's -1701 export files show only five block writes (of which the three largest are Program RAM, Parameter RAM, and Core Registers). What makes the example so much more involved?

The -1761 has "Non-Modulo Data RAM" -- what is this for?

Best regards.

Bob

Hi Bob,

That makes sense!

The ADAU1701 has all of its control register writes grouped into one block. That means there are far fewer write operations when you need to boot the chip.

The ADAU1761, on the other hand, has a large number of control registers, and we divided up the write operations in such a way so that you need to perform many writes in order to configure them all. That's why the ADAU1761 operation appears on the surface to be more complicated. In reality, though, it's just more of the same.

Non-modulo RAM is really just a section of data RAM that is not part of a circular buffer. We set up most of the data RAM to work in a circular buffer fashion, because this lends itself well to data streams. You can read the first few paragraphs on the Wikipedia article for Circular Buffer to get the gist.

On the ADAU1761 (and some other newer SigmaDSPs), it makes sense because of the core architecture and pipelining reasons to sometimes store non-audio data in the data RAM. In this case, you don't want that data to be part of the circular buffer, because it's not part of an audio stream like a delay line. It's just a fixed value. So, in that case, the compiler sets aside a section of memory to not be part of the circular buffer.

In any case, the important thing for you to know is that you should replicate the exact write sequence that SigmaStudio uses to boot the chip when you make your system, including the non-modulo data RAM.

Brett.

Thanks for your help! It appears that adopting SigmaStudio's standard export method becomes especially beneficial when different or multiple DSPs are involved. Your explanation helps a lot.