migration from ADAU1701 to ADAU1450

We have a product based on the ADAU1701 and a microcontroller.   The microcontroller uses SPI to load the DSP program and update parameters on the fly using hardware safeload writes.

We are considering migrating to the ADAU1450, and we are wondering what the impact of the migration is for our base of microcontroller firmware and SigmaDSP programs.  I understand that the ADAU1450 has different I/O requireing some code changes.   However, I have read here in the forum that SigmaDSP programs may need to be rewritten because of differences in SigmaStudio processing blocks, and that some SigmaDSP processors have software safeload write mechanism while the ADAU1701 has hardware safeload write.

Can anyone weigh in on whether our SigmaDSP code can be reused, if our microcontroller code (program load and parameter control) needs to change?   Are there any other software impacts that need to be considered?

Thanks,

John

  • 0
    •  Analog Employees 
    on May 20, 2016 11:47 PM

    Hello John,

    The short answer is that all has to change. The underlying code in the SigmaStudio cells are all optimized for the particular environment it is running in. So the code in the cell for a 1701 is different than the code in a cell for the 1450/1/2 processor.

    The safeload routines are in software in the 1450/1/2 so your MCU code will have to know where it is located after the code is compiled. Plus, the memory map is very different so you are going to have to recompile your MCU code.

    Regarding your schematic. It is not possible to copy and paste in cells from one schematic/processor to another so you will have to recreate your schematic using the new cells.

    Now depending on your application you may be able to do a lot more with the new 1450 DSP. This may sway you to take the hit of all the changes migrating will cause.

    There are many enhancements made to the 1450/1/2 core that will make your same "program" run much faster even if the core speeds were to be the same but it is faster in the 1450/1/2. So you will see an improvement in the amount of code you can run. Now the 1701 is very popular so it will continue to be produced for some time into the future. So what is prompting you to consider making a change? What is the limitation?

    Dave T

  • Dave, thanks for your reply which will be helpful as our team  weighs the advantages of the new architecture against the schematic rewrite.

    Regarding our uC firmware, I built a quick ADAU1450 schematic and looked at the exported system files needed for the uC download. I found a DSP Ram data section in addition to Parameter/Program Data found on ADAU1701, and the registers and parameters for the SIGMA_WRITE_REGISTER_BLOCK() function are different. However, it may only be necessary to rewrite this function to download using our uC, so this is probably straightforward.

    Our firmware also uses the DSP Readback cell to get data from the DSP to the host.   I did a search in the ADAU1450 data sheet for the data capture/readback registers (that we now use in the ADAU1701) to do a readback of a value, but I did not find anything resembling them.  Could you briefly point me to how this is done in the ADAU1450?

     

  • 0
    •  Analog Employees 
    on May 23, 2016 11:29 PM

    Hello wygonski,

    Have a look at this screenshot: (sorry, it is a bit large but there is a lot of info on it.)

    YOu see I setup a DC cell and a readback cell. I also have a few other cells that are not shown.

    This is the listing of the parameter memory and you can see the address of the readback cell is decimal 30 and the DC cell is 31.  by the way, you can also see where the safeload area was placed. 20 - 26. The compiler may place this in different locations so you need to check where it is for our program.

    So the readback can be read at location 30. This is 1E in hex.

    Then have a look at this screenshot where I captured the data transmission when I clicked on "Read".

    Here you see the read request and the read result. So you can place these DSPreadback cells anywhere in your program and they will be compiled into the memory map somewhere. You can find them in the system files output or you can look at the project like I did.

    Keep in mind that you can reduce the "clutter" in your system file output by excluding cells that you do not need to address when the program is running. You select the cell, right click and select "Exclude from Export Files". Then all these extra controls will not be reported in the exported header files.

    Dave T.