Electronics > Beginners
"Chained" uControllers to configure an I2C device
(1/3) > >>
jmf11:
Hello,

I'm looking for the adequate way to sort out the below use case.

I'm working a TAS3251 board (class D audio amplifier chip with included DSP). The DSP is to be configured/controlled by I2C (slave only). Then, you can configure other things during the operation like the volume. The idea would be to have a small micro-controller on the amplifier board to manage power ON, power OFF, first DSP configuration. But for more powerfull functions the idea would be to use a Raspberry Pi (RPi). But the Rpi does not manages multi-master I2C.

Would there be "proven" strategies to have an I2C slave device controlled by a small board uC and a RPi masters (but not multi-master) ?

I know that this design may not be so good, but from usage perspective, it would make some sense...

JMF

 
rstofer:
As long as everybody plays by the rules in terms of addressing, I don't see why one end of the bus couldn't be a Pi and the other end of the bus be a uC with the audio gadget in the middle.  This is more conceptual because the physical orientation doesn't matter.

At power on, the uC will be done doing it's thing long before the Pi boots.

Both masters should be able to detect collisions on the bus but it seems to me this just won't happen.

Try it!  I would use pull-up resistors around 2.2k Ohms.
jmf11:
Hi,

It is not a question of orientation. It is more the fact of having 2 masters, with different functional roles. This is an option included in the I2C protocol with the "multi master" concept. But this is not managed by the RPi unfortunatly.

In my current set-up (with different off the shelf amps), the RPi is always powered on and I switch ON and OFF the amp when needed. In that type od scenario, the Rpi will be booted before the uC is powered. So there are some risks of master fighting.

JMF
jhpadjustable:
Nothing "proven" but let me throw some things out there.  :)

Since clock stretching does appear to work on Pi at the ACK bit, you could use a micro with at least one hardware I2C controller set to respond to the amplifier's address, and mimic every bus byte or condition on the other side as required, by bit-banging or a second I2C controller as available. Use clock stretching to hold off each side between bytes. This is straightorward and easy to work with, but slow. You can speed it up (and complicate it) if you cared to parse the read/write protocol of the amplifier chip, for example, to handle book/page changes asynchronously, or read-ahead from the amplifier when safe to do so, or cache written values...

If the Pi won't accept another master on the bus, and hold itself off during a transaction, you'll have to hold it off. You can do this from inside by giving the on/off/startup micro an output that tells the Pi to not initiate transactions. Even if the Pi is in master mode, its bus outputs in the idle state "should" be in undriven open-drain mode and shouldn't disturb whatever else might be happening on the bus. You'll need to handle the hold-off signal in the application or, if kernel drivers are issuing the commands, hack the i2c or ALSA(?) device driver.

Or, if your Pi side can handle retries when the amplifier disappears and reappears from the bus, use any I2C hot-plug transceiver to simply detach the Pi whenever the on/off/startup micro does its business. For best results you would need the micro to detect when the bus is in use by the Pi and only detach or attach when idle.
jmf11:

--- Quote from: jhpadjustable on November 19, 2019, 05:48:49 pm ---If the Pi won't accept another master on the bus, and hold itself off during a transaction, you'll have to hold it off. You can do this from inside by giving the on/off/startup micro an output that tells the Pi to not initiate transactions. Even if the Pi is in master mode, its bus outputs in the idle state "should" be in undriven open-drain mode and shouldn't disturb whatever else might be happening on the bus. You'll need to handle the hold-off signal in the application or, if kernel drivers are issuing the commands, hack the i2c or ALSA(?) device driver.

--- End quote ---

Thanks for all proposals,

The one I have quoted above, seems to me the easiest and more robust to implement, in absence of a "multi-master" implementation by the RPi and the board uC.

I had arrived in parallel to a similar idea. Your proposal confirms me in this direction.

Thanks for the help.

JMF
Navigation
Message Index
Next page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod