This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to address several amplifiers on an I2C bus?

Other Parts Discussed in Thread: TAS5709, TAS5709A

Hello
I have designed an amplifier with TAS5709. It works very well. Now I am about building a system with several (6) amplifiers, that will be independently controlled over the I2C interface.
My problem: Can I address these six amplifiers DIRECTLY through an I2C bus?
As far as I can see, there is only one address given to each unit (0x36). This address can be changed by software to only one other address (0x38). There are no hardware pins to set the address!
Is there any way to use several circuits on a I2C bus?
I would be thankful if I don't have to build a separate I2C address decoder for this project!
Best regrds, Dan Backlund, Electrobrains

  • Hi, Dan,

    We have another part, TAS5709A, which has two different addresses, so we can get you up to 4 total.

    However, past that, you'll need an I2C address decoder. Look at something like PCA9543A or PCA9518

    -d2

  • Thank you Don for the answer!

    It's about what I expected (and feared).

    Even with those two circuits involved, the solution seems to be rather complex for six units.

    I have another solution, a compromise, not allowing me to configure each amplifier individually:
    I would only use the I2C bus unidirectionally. Connecting all 6 units to the bus and leaving them with the same address. They would all read the same information and be set up in exactly the same way. It's a limitation, but maybe acceptable compared to the address decoder circuit.

    My concern with that solution is this: It seems that the TAS5709 (and I suppose I2C units in general) generates an ACKNOWLEDGE PULSE during the communication with the master. In this case there would be 6 units generating the same pulse on the SDA line. Do you think that could cause problems? There sure will be small delays between the units, but the bus speed is rather slow... And the low ACK state should never get interrupted (wired NOR configuration), thus only causing a small variation in the ACK pulse length.

    What do you think about that?

  • Dan,

    While theoretically that should work, it violated the I2C specification, so I can't officially condone it.

    The issue will be - if you get it to work on your prototypes, and then go to production, some timing parameter may shift and mess up the whole product. So, I don't think it's a good idea to do this... Unless you're just making a few units, and you can thoroughly test them, and don't mind if they stop working some time later down the road...

    -d2

  • Thank you for the advice.

    I will build a prototype and try to analyze the risk for an error.

  • Dan,

    Have you tried this out? I assume it will work just fine - for a small sample size -- but if you go to production, I expect you might run into errors.

    -d2

  • I have now tested the unit with 6 boards (12 channels) connected in parallel and the I2C part seems to work fine!

    I can send the same messages to all six TAS5709's at the same time!

    There have been two problems though, that I would like to mention:

    1. It's written in the data sheet of TAS5709 that "Serial Control Interface Operational Without MCLK" This seems not to be the case! Through the paralleling of the I2S signals, the MCLK got too weak and the TAS5709 stopped working. Also if the signal was totally removed, the circuit did not work. After buffering the MCLK, the function returned.
    Please overview this function! What is wrong?

    2. The address programmed into the register 0xF9 (2 addresses available for TAS5709 and 4 addresses for TAS5709A) seems to be volatile! According to my opinion that makes the function useless...
    The whole idea is to be able to differ between several circuits, all hanging on the same I2C bus, isn't it? In the way it's working now, all units loose their set addresses to default (0x36) as soon as the supply is removed! After that, you cannot differ between the chips any longer and will not be able to give them different addresses - leaving only hardware decoding as an option! Could not the future versions get non volatile memory instead?
    p.s. I have not tested this function with the "A" version.

  • Hi, Dan,

    1. I think the text may be a little unclear in that section. Without MCLK, there is no way to play audio... However, the I2C interface is supposed to continue working. 

    2. Yes, this is volatile. Unfortunately, the process we make this IC in does not provide the option for non-volatile memory...

    -d2