1
\$\begingroup\$

I'm learning I2S right now and am curious how to work in an environment where 8 or so audio devices could be in the setup. I understand TDM mode would allow the Controller (Master in legacy terms) to read N channels on the single bit serial data line (as shown in the picture). However, I don't understand how the audio device knows when to drive the serial data line with it's data. How is contention avoided?

From https://d3uzseaevmutz1.cloudfront.net/pubs/appNote/AN301REV1.pdf

\$\endgroup\$
0
\$\begingroup\$

However, I don't understand how the audio device knows when to drive the serial data line with it's data. How is contention avoided?

You need to design the device so that it skips as many slots as necessary, while someone else drives the serial clock. There's no bidirectional communication in I2S. There's no contention, only pre-defined slotting.

However, it feels like the usual design choice here would be that there's a single device delivering all the data, and receiving samples from 8 sources (e.g. by clocking ADCs, or by receiving from 4 stereo I2S links) in itself. That's a classical FPGA use case, but I'm sure there's also dedicated ASICs for such purposes.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ By "design the device" -> the device here is the Controller? \$\endgroup\$ – Lee S Oct 23 at 21:36
  • \$\begingroup\$ Ooops didn't realize pressing enter submits the comment... to go on with another question.. This is an environment with only one Controller (Master), and its just the controller that is driving the clock to all 8 mics. I was thinking maybe there has to be a Ser/Des setup? \$\endgroup\$ – Lee S Oct 23 at 21:37
  • \$\begingroup\$ not clear what you mean with that. \$\endgroup\$ – Marcus Müller Oct 23 at 21:42
  • \$\begingroup\$ All the mics (I2S audio devices) would have data in parallel and in order to Serialize it like when is shown in the picture, I was thinking there needs to be something that serializes it and puts each of the mic outputs in the right slot, because it would have to stay consistent each frame. \$\endgroup\$ – Lee S Oct 23 at 21:45
  • \$\begingroup\$ yes, that would be the FPGA I mentioned above. Really, a tiny design, because it's really just boring shift registers. You could probably hack that together from discrete shift register and counter ICs. But if you designed your microphone's digital side (I have literally no idea at which level you're working on this), you could just as well make each microphone a slave on a bus, knowing on which clock edges to use the bus. I was assuming you were going the "shared medium/bus" approach, since you assumed a transmitter would have to know about slots. \$\endgroup\$ – Marcus Müller Oct 23 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.