Finally, some progress with the ADAU1466…
There are quite a few software differences between the ADAU1701 and the ADAU1466, so I expected a long and difficult effort to update my ADAU1701 library files for the newer DSP. However, it really wasn’t too difficult, and the problems I ran into were from unexpected differences and some over-reliance on SigmaStudio.
The ADAU1701 code uses a micro to allow controlling the volume, input selection, crossovers, bass enhancements, and EQ from a cell phone app. In order to do that, the code in the micro needs to be able to generate the proper data to control the DSP cells and then be able to write that data in the proper format to the Parameter RAM in the DSP. None of the “upper” layers of the code are affected by the change, and the lowest levels (I2C communications) are identical. The ADAU1701 uses a different number representation: 5.23 versus 8.24 for ADAU1466, but this change was easy enough to implement.
But I ran into a snag with the biquad coefficient loading routine. The biquad coefficients get calculated in the micro using the “Audio Cookbook” equations published by Robert Bristow-Johnson. For the ADAU1701, there are safeload registers for updating the 5 biquad coefficients all at once, to minimize “glitches”. The ADAU1466 also has these safeload registers, but for some mysterious reason the “order” is totally different, and I can’t find any documentation anywhere on the Analog website that explains the “correct” order for the coefficients. In fact, the only documents I could find were for one of the SHARC series, which use an even different order. The normalized coefficients for the ADAU1701 must be loaded in this order: B0, B1, B2, A1, and then A2. The ADAU1466 loads the coefficients in this order: B2, B1, B0, A2 and A1. Get that sequence wrong and you won’t get any output from the ADAU1466. C’mon, ADI…that is just weirdly inconsistent, and you could at least document the coefficient order somewhere.
But the other snag that really cost a lot of debug time was relying on SigmaStudio to set up the clocks. I was able to control the volume just fine, but the biquads seemed to be getting calculated or loaded incorrectly. This didn’t make any sense, until it became clear that it was a clock issue. Somehow the default clock dividers got changed to “0”, so instead of running the DAC at 48K, it was running at 288KHz. I would expect SigmaStudio to be smart enough to know that if you have selected 48KHz sampling, the clock dividers need to be properly set, or at least issue a warning notice that your selected sampling rate is not possible given the current clock ratios. So, lesson learned. Fortunately, the clock dividers are well documented in the datasheet, with default values and two examples. But jeez…who reads the fricking manual when we have this sophisticated software to help us out (not)?
The other major difference of the ADAU1701 and the ADAU1466 is the way the self-boot EEPROM is configured. I never used an EEPROM in any of the board designs on Audiodevelopers, because it was easy to load the ADAU1701 code from the micro. This approach had the nice benefit of not needing a USBi programmer. I just processed the “tx” file generated by the SigmaStudio compiler to create an Arduino “.h” file with the code and loaded the Program RAM at power-on reset using that data. But the ADAU1466 uses two different memory spaces with multiple pages, and there is a lot more code to deal with. For the ADAU1466, it makes more sense to let SigmaStudio program the EEPROM. So, the new designs will require a USBi interface board to program the EEPROM. The biggest “downside” to this approach is that the USBi SPI interface interferes with the I2C interface from the micro, because on the 72-pin devices like the ADAU1466, those signals are shared pins. So, when using the USBi, you need to unplug the micro. You will need to develop and test the SigmaStudio code fairly well before using the micro to control the cells. The 88-pin ADAU1467 does not use the same pins for the slave SPI and I2C signals, so that might be a better choice for future designs.
That’s the end of the gripes. The ADAU1466 is a really nice chip. Having 8 ASRC modules plus SPDIF is great–you can connect anything to the DSP and not worry about synchronizing the clocks. Easy peasy, lemon squeezy, as my wife would say. SigmaStudio hides the complexity of the ASRC–it is really nice to just pick from some high-level menus and hear the audio without having to program a huge number of registers. I’ve used several other ASRC chips, and no other chip is this easy to use. And overall, SigmaStudio is really nice. I’ve used it before for designing the ADAU1701 signal flow but have never used it in “active download” mode. I much prefer controlling the DSP with my cell phone app, but I can certainly understand why DIY’ers would be enthused by SigmaStudio.
There is still a lot of code to update to use the updated libraries, but there don’t seem to be any problems that will require extensive debugging in implementing the next generation designs. The only challenge left is that spring has arrived here in the Maryland mountains, so “software season” is officially over. It’s time to work on those legs that have atrophied over the winter. Progress on software will be slower, but I’ll start ramping up on the cabinet work and maybe get some new board designs completed.