Interfacing the I2S bus to an Atmel

[Daryl]

I posted this question before but am still trying to proove it with an answer.

I was told that I could not interface the I2S bus with an Atmega32.
I have found an alternative processor. But how can I proove that the Atmega32 is not possible for this application.
Which calculations can be made?
I am using sample rates up to 96 kHz and possibly 192 kHz.
Therfore the SCK line of the I2S-bus is 64*Fs = 6.1 MHz T= 1/F = 160ns

These are the only calculations I can work out.
Could somebody help me with some more information?

[macboy]

Therfore the SCK line of the I2S-bus is 64*Fs = 6.1 MHz T= 1/F = 160ns

You've nailed the most important number. All other signals are lower frequency than SCK. LRCLK or WCLK (word clock) is the sampling frequency, and the data line toggles at most at 1/2 the bit rate (assuming the very unlikely pattern of alternating 1's and 0's).

Keeping in mind that I know nothing of how the Atmega32 works specfically, in general you would need to receive the data as 8 bytes per WCLK period (in the 96 kHz case, 1 byte every 1.3 microseconds or so. You would probably use a syncronous serial port or similar peripheral. Then (I guess!) you have to do something useful with that data within the remaining CPU cycles until another byte is ready. If you need to transmit too, then you add even more stuff to do within the 1.3 microseconds. And don't forget that the data needs to be syncronised to the WCLK somehow. How many MIPS does the Atmega32 run at? Interrupt latency and overhead? I personally wouldn't say it's impossible, but... good luck!

[rfbrw]

Depending on your approach, one can prove or disprove either case.

[poobah]

It all depends on your I2C bus... and what you plan to implement.

An I2C bus can be "bit banged" on an AVR and the built in SPI's can be used with some tricks. More elegant solutions are available when when there are Master/Slave limitations involved. It is true that the AVR lacks the hardware to detect bus contention... bus contention is not always an issue though.

Do you have a specific implementation in mind?

[Daryl]

The MIPS of the Atmega 32 is:16MIPS --> 16MHz
Does this give you any more information to help me further on?

[poobah]

Nope, speed has nothing to do with it...

It's more about what you wish to hook to the AVR



SORRY... I misread your speed req's... yeah that could be a problem.

[rfbrw]

Originally posted by Daryl
The MIPS of the Atmega 32 is:16MIPS --> 16MHz
Does this give you any more information to help me further on?

You are looking through the wrong end of the telescope. You need to determine how many cycles it takes to do what you need and work back from there. For example at 192k you have about 80 cycles to work with.

[poobah]

rfbrw,

The AVR SPI's are limited to local clock over 4. So about the best one can do is 5 mHz.

Of course there ways around this, to me it comes back to what the AVR is supposed to do afterwards.

[rfbrw]

Originally posted by poobah
rfbrw,

The AVR SPI's are limited to local clock over 4. So about the best one can do is 5 mHz.

Of course there ways around this, to me it comes back to what the AVR is supposed to do afterwards.

It would be illogical to attempt to move I2S data over SPI when I can do it with time to spare in parallel.

[poobah]

Exactly what I was thinking... a few shift registers and byte wide data.