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?
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?
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!
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?
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?
poobah said: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 said: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?
None of that matters. I2S is completely different from I2C. I2S is a point to point unidirectional link, not a bus. No master/slave, no arbitration, no contention. An SPI peripheral is actually a good building block to start with to talk I2S. You need an SPI that can slave (be clocked externally), and preferably have selectable clock polarity. It will provide the bit clock and data lines, but you still need to handle WCLK in software, and reassemble the individual bytes received over SPI into meaningful 32-bit L/R data.
It would be illogical to bit-bang SPI, but using an SPI peripheral could be very useful. The peripheral takes care of converting the serial bitstream into byte-wide data. Of course if you use eight external byte-wide ser-to-par shift registers and latch the data from them into the micro on every WCLK, that might lend you some extra clock cycles per sample period, but that is a lot of extra external hardware.
It is possible to send I2S data from AVR
Hi,
Several years ago I have made commercial device "digital public voice automatic messenger for public transport".
45 clocks of AVR was required in my program to send 1 byte to I2S bus (TDA1543) using simple bit manipulations.
You can calculate max achievable data speed on yours system.
My system was: 8-bit mono stream with 11025 samples/sec.; processor run on 8MHz.
Best regards,
Juozas Kimtys
Hi,
Several years ago I have made commercial device "digital public voice automatic messenger for public transport".
45 clocks of AVR was required in my program to send 1 byte to I2S bus (TDA1543) using simple bit manipulations.
You can calculate max achievable data speed on yours system.
My system was: 8-bit mono stream with 11025 samples/sec.; processor run on 8MHz.
Best regards,
Juozas Kimtys
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.