i2s bus vs. i2c bus

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
This is slightly random, but what are the fundamental differences between i2s and i2c busses? I realize i2s has three wires, but is it essentially a specialized version of i2c bus for audio applications? If so, how easy (or hard) do you think it would be to connect an i2s IC (ADC) to an i2c port of a microcontroller (arm7)? Of course there would have to be some modifications here and there, but as far as the difficulty, does anyone have any ideas? Thanks,

Doovieman
 
rfbrw said:
It would be completely pointless. The I2S but is an peer to peer unidirectional audio bus for streaming audio from a to b with no guarantees at all. The I2C bus is a bidirectional bus for moving commands and data between multiple devices with arbitration between them

The I2S Bus. http://www.semiconductors.philips.com/acrobat_download/various/I2SBUS.pdf
The I2C Bus. http://www.semiconductors.philips.com/acrobat/literature/9398/39340011.pdf


It's not pointless actually. My ARM7 doesn't have an I2S bus and the ADC I want to use only supports I2S. The question is then, do I write an I2S controller from scratch or do I try to write a minimal amount of code in order to use the I2C bus on my ARM7. Any other thoughts?
 
Doovieman said:



It's not pointless actually. My ARM7 doesn't have an I2S bus and the ADC I want to use only supports I2S. The question is then, do I write an I2S controller from scratch or do I try to write a minimal amount of code in order to use the I2C bus on my ARM7. Any other thoughts?


If you really believe shoehorning the I2S protocol into the I2C protocol will result in a minimal solution then one can only conclude you have failed to read and understand the specifications in the links provided. Nonetheless, every success in your endeavour.
 
rfbrw said:



If you really believe shoehorning the I2S protocol into the I2C protocol will result in a minimal solution then one can only conclude you have failed to read and understand the specifications in the links provided. Nonetheless, every success in your endeavour.


So I'll ask my question again so that somebody a little more helpful might answer it. Which is the better solution:

a) try to write some code in order to take advantage of the already exisiting hardware in the ARM7 that supports I2C such that I can use an I2S part on the I2C port.

b) write an I2S controller from scratch using 3 GPIO lines and not taking advantage of any hardware support.

Again, the question is which is better, a or b. Snide remarks (such as the one quoted above) don't help and are not appreciated. Thanks,

Doovieman
 
a) try to write some code in order to take advantage of the already exisiting hardware in the ARM7 that supports I2C such that I can use an I2S part on the I2C port.

b) write an I2S controller from scratch using 3 GPIO lines and not taking advantage of any hardware support.

Again, the question is which is better, a or b. Snide remarks (such as the one quoted above) don't help and are not appreciated. Thanks,

I think, you've missed the point. I2S is a 3-wire interface, I2C is a bidirectional two wire interface. The interfaces are not hardware compatible in any way. So you are not able to program the I2C interface to support I2S signals.

a) NO!

b) NO!

You've to write some VHDL code to solve your problem.
 
Doovieman said:



So I'll ask my question again so that somebody a little more helpful might answer it. Which is the better solution:

a) try to write some code in order to take advantage of the already exisiting hardware in the ARM7 that supports I2C such that I can use an I2S part on the I2C port.

b) write an I2S controller from scratch using 3 GPIO lines and not taking advantage of any hardware support.

Again, the question is which is better, a or b. Snide remarks (such as the one quoted above) don't help and are not appreciated. Thanks,

Doovieman

b) is better, but better yet is c), see below. But first:

rfbrw did not make a snide remark in my opinion. I share the view that, if you believe that a writing "some code" will make an I2C controller talk to an I2S device, then you simply do not understand the (very significant) differences between the two protocols. Read the specs for both, understand how they work, and then you tell us whether this is an option worth considering. You clearly haven't done your research and yet you are off-handedly dismissing an educated opinion from a well-meaning member of our community. He wants to help (as do I) by steering you away from a dead-end course. In other words, forget about trying to talk I2S over I2C. The simularity in the names, is where the simularity ends.

I assume that the micro you are using has an SPI interface. If you would like to take advantage of a built-in peripheral, investigate the possibility of using that. SPI is much closer to what you need than is I2C. You could use the SPI data out and clock lines as the I2S data and bit clock. You would still need to generate a Word clock (aka LRCLK or WCLK) and, probably, a master clock as well. A low jitter WCLK is important, so generating it in your microcontroller is probably not the best option. Rather, generate it externally using a good quality timer circuit, and feed it into your micro (as well as your I2S device). Use it as a trigger in your micro to begin the transmission of the bit data for the next word... well, you need to figure the rest out. But not before reading up on the SPI protocol and the I2S protocol (of which there are many variants... figure out which you need).
 
I assume that the AVR you are using has an SPI interface. If you would like to take advantage of a built-in peripheral, investigate the possibility of using that. SPI is much closer to what you need than is I2C. You could use the SPI data out and clock lines as the I2S data and bit clock. You would still need to generate a Word clock (aka LRCLK or WCLK) and, probably, a master clock as well. A low jitter WCLK is important, so generating it in your microcontroller is probably not the best option. Rather, generate it externally using a good quality timer circuit, and feed it into your micro (as well as your I2S device). Use it as a trigger in your micro to begin the transmission of the bit data for the next word... well, you need to figure the rest out. But not before reading up on the SPI protocol and the I2S protocol (of which there are many variants... figure out which you need).

Let's make it yet clearer: I've used an 200MHz ARM9 processor with a FPGA to convert 24-bit audio data to I2S. The data itself is buffered by a FIFO. That 200MHz ARM9 core is just powerfull enough to support 192kHz data streaming. Other tasks must not running. Although the requirements are less for 16bit/44kHz audio I do not think, that an ARM7 and using the SPI interface for data conversion is powerfull enough, to support the necessary data conversion, because of the interrupt overhead.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.