5 or 6 way crossover-H/W recommendation?

Most of what you request is probably possible, but could you provide more details? How many pots, how long are the delays?

You have four aux ADCs per 1701, and if you aren't using all of the audio ADCs you can press those into service too. Or you could use the encoder & button approach (I am using two up/down toggles into two aux ADCs for a similar purpose). Or both.

You can trigger writebacks with a GPO and timer, or via button, or simply a reset chip monitoring the power supply.

As for DSP six index filters are well within budget, the delays depend on length. If you need long delays then 1701 won't be suitable, although that can be fudged some if you know that some of your delay channels have limited bandwidth.

You can use GPOs to drive a segment display but you'll need a lot of them. It's probably better to use some DSP as your uC, you can get clever by sending commands stored as values in an index table to a serial output to an integrated display/controller.

Realtime control from SigmaStudio is not a good idea for a product as every install would have to have a USBi, which gets expensive. It's not the way the product is intended to be used.

Hi Alex,

If you require more output channels (up to 8) and would consider an ADAU1442, I would suggest you look at either the ADAU1451 or ADAU1450. The ADAU1452MINIZ evaluation board contains an AD1938 codec which gives you 4 analog in/8 analog out at 48 kHz sample rate.

You probably didn't see these under the "SigmaDSP Audio Processors" selection table on analog.com, because they have not been added yet. (I need to put in a request to add these products to the selection table, sorry).

The ADAU1451 has over twice the program memory (8K) and twice the data memory (16K) to the ADAU1442 at around the same price at 1K quantities. Similarly, the ADAU1450 has over twice the program memory (8K) but has the same amount of data memory (8K) to the ADAU1442 at around half the price in 1K quantities. The ADAU1451/0 also has up to 16 GPIOs (some are multiplexed so probably not as many available, unless you can use an 8-channel codec in TDM8 mode and have more unused serial port pins for use as GPIOs). In addition, the ADAU145x has 6 x 10-bit SAR ADCs for real-time adjustments.

The ADAu145x also supports simultaneous SPI or I2C master and slave modes. So it might be possible to us the SPI or I2C Master Control Port blocks within SigmaStudio to configure an external SPI slave device like an LCD. There was a recent discussion on this last week ("Standalone Audio Processor with 16x2 LCD")

The ADAU145x family can also boot in standalone from a serial EEPROM like the ADAU1442 and ADAU1701.

The ADAU145x SigmaStudio session contains a "Master Control Port" option to program Flash Memories or boot/configure external SPI Slave Devices using commands from an XML file. I have not actually tried this, and don't see any documentation on this block up on the Wiki.

Perhaps with the additional MIPS/memory, 6 SAR ADCs, GPIOs and master I2C/SPI modes, you might be able to run your application in a standalone configuration without a host microcontroller using an ADAU145x.

-JT

Thanks Jon,

If possible, I envisage user control over HP filter freq, LP filter freq, delay (up to 10ms), filter type/slope (12db/oct and 24db/oct- Butterworth and L-R) and polarity. So 5 parameters. I think whichever way I go I'll need to toggle these controls to select which crossover band they effect, so good to know writebacks can be triggered.

"It's probably better to use some DSP as your uC, you can get clever by sending commands stored as values in an index table to a serial output to an integrated display/controller."

Don't suppose you happen to know of any further reading regarding this?

(It's a bit of a niche product, real time control would be for my use only!)

Thanks again.

Thank you also other 'John'!

This helps massively, will take a closer you into your suggestion.

Alex.

As a continuation... Have been setting up the rotary encoder and toggle buttons but am now stuck. I've run out of interface read/writes, it seems 8 is the maximum? If each filter/lookup table needs one read and one write I'll be limited to 8 filters max...Have I got this correct?

You can potentially store a lot of information inside a single interface read/write; it's 24 (or 28, I haven't checked how it gets stored) bits of data where you probably only need 3 or 4 bits per parameter. That would require some math to parse the interface value out to several tables. You can encode with x + 16y + 256z . . ., and decode with masking.

The GPIO modules that require the interface read/write can't be directly written, just toggled, but I think it's possible to link a blue/green or red pin to interface read/writes. I don't have a method of testing that as I don't think the eval kit supports writeback, although I could be wrong there, I don't remember exactly.

Thanks again Jon, although I don't really follow unfortunately.

Could you possibly elaborate on "That would require some math to parse the interface value out to several tables. You can encode with x + 16y + 256z . . ., and decode with masking." please?

Is this using arithmetic operations, such as multiply, to multiply a lookup table?

Whats masking in this situation? Is this specific to Sigmastudio? Google offered no help.

(Can start a new thread if you'd rather, would give the chance others to chime in instead and make it easier for people in the future to find).

You have to get your head around how the number system works in SigmaDSP; you have modules like the lookup tables that use 28.0 numbers while the table data is 5.23. Sometimes it's confusing understanding which system is in use in which module because they aren't always labeled.

Anyway, the actual number stored is the same either way, so I often view the DSP readback in hex so I get less confused. If you are storing multiple points in one number, you might have one nibble (four bits, one hex digit) per parameter. You'd have to multiply the second parameter by 16 to get that parameter shifted to the second hex digit. The trick is you can't multiply by 16, because the maximum 5.23 number is 15.99999. I think the most efficient method is to multiply twice by 4, but that's with ADAU1701. The newer chips have more modules that may work better for this task, but I only code for -1701 so that's all I know.

To decode that value you have to strip out each digit. I think the newer chips have bitwise operators that make that easier, but with -1701 you multiply by a 'masking' 28.0 value, which is really an efficient form of division (because the 28.0 value is really a fractional number in 5.23) and truncation. Then you rinse & repeat until you've read all of your values.

This takes quite a few instructions per parameter and given the relative inefficiency of -1701 vs. the newer chips, you'll probably use up the DSP without leaving enough for the large number of filters you want. But you've probably already decided on -145x.

This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

Thank you,
EZ Admin