I2S naar Atmega32

Zou het mogelijk zijn om I2S in te lezen via SPI?

heb je daaarover al niet eens gepost ?
in ieder geval is je atmel veeeeeeeeeeeeeeeeeeel te traag om i2s te kunne volgen. bijna leke cpu is te traag om dat te kunnen doen.
ok via SPI niet. de framelengtes kloppen niet.

het enige wat je kan doen is ene hardware i2s interface mkane en dat in ene fpga duwen. hang daar je cputje aan.
die fpa paralleliseert de data al, stript er de headers uit en doet clock polariy en bit order correctie en kan eventueel de links en rechts uitbreken ook. dat maakt het voor de cpu al een heel stuk makkelijker ( alhoewel die nog snel zal moeten zijn om de parallele data bij te benen. )

Ja ik heb deze vraag al eerder gepost.
Maar hoe kan ik aan anderen bewijzen dat het met een Atmel niet mogelijk is?
Echter heb ik te weinig tijd om dit te realiseren en te bewijzen met een FPGA.

Als je mij kan vertellen waarom de Atmel veel te traag is zou ik erg dankbaar zijn.

kijk naar de kloksnelheid van i2S die zit op 2MHz en meer.
je moet op elke klokpuls een bit binnennemen.

als je atmel op 20 MHZ draait ( stel nog dattie maar 1 klokpuls nodig heeft voor 1 instructie wat ook al het geval niet zal zijn, je hebt ook bij single clock processoren een latency aan je broek ) dan heb je welgeteld 20 instructies om dit bit binnen te pakken , je moet beslissne of je hem inverteert of niet , of ie in links of rechtse frame moet, of dat er een framewissel gebeurd, en om hem in een byte ( en een 'byte' op i2s is niet noodzakelijk 8 of 16 bit. tkan eender wat zijn. hangt van je a/d af ) te schuiven en dat naar ram te duwen. tegen dat je daar bent is het volgende bit al gepasseerd ...

zelfs als je het lukt met ene atmel op 40MHz dan nog blijft er niks over qua processing power om ook nog maar eender wat te gaan doen met dit signaal.

de i2s stroom is veel te snel. het de-serialiseren moet in hardware gebeuren ( bij al die DSP is dat ene hardware blok te vergelijken met ene 'uart'). dan is de parallel datastroom vele trager (i2s clock gedeeld door 2frames gedeeld door aantal bits per frame. stel een 16 bit stereo convertor ; 2 megabit / 32 ... 62 kilowoorden per seconde dat doet eender welke processor op zijn sokken. ) en kan je WEL zonder problemen volgen.

een normaal CD kwaliteit signaal is 44 kilosample op 14 bit en stereo . de i2s botstream is dan nog pakweg 1.4 megabit.

kijk in uw datasheet wat de clockrate van uw a/d convertor is, kijk wat de klok van je atmel is en hoevel klokpulsen per instructie ( let op dat je clockPULSEN en geen clockcycli te pakken hebt. ) en doe je rekenwerk

@ Free-electron.
Enige tijd geleden had ik deze post op circuits online gezet of het mogelijk was om de Atmega 32 te interfacen met de I2S serial audio bus.
Destijds had jij hier het volgende antwoord op gegeven:

/*
kijk naar de kloksnelheid van i2S die zit op 2MHz en meer.
je moet op elke klokpuls een bit binnennemen.
als je atmel op 20 MHZ draait ( stel nog dattie maar 1 klokpuls nodig heeft voor 1 instructie wat ook al het geval niet zal zijn, je hebt ook bij single clock processoren een latency aan je broek ) dan heb je welgeteld 20 instructies om dit bit binnen te pakken , je moet beslissne of je hem inverteert of niet , of ie in links of rechtse frame moet, of dat er een framewissel gebeurd, en om hem in een byte ( en een 'byte' op i2s is niet noodzakelijk 8 of 16 bit. tkan eender wat zijn. hangt van je a/d af ) te schuiven en dat naar ram te duwen. tegen dat je daar bent is het volgende bit al gepasseerd ...

zelfs als je het lukt met ene atmel op 40MHz dan nog blijft er niks over qua processing power om ook nog maar eender wat te gaan doen met dit signaal.

de i2s stroom is veel te snel. het de-serialiseren moet in hardware gebeuren ( bij al die DSP is dat ene hardware blok te vergelijken met ene 'uart'). dan is de parallel datastroom vele trager (i2s clock gedeeld door 2frames gedeeld door aantal bits per frame. stel een 16 bit stereo convertor ; 2 megabit / 32 ... 62 kilowoorden per seconde dat doet eender welke processor op zijn sokken. ) en kan je WEL zonder problemen volgen.

een normaal CD kwaliteit signaal is 44 kilosample op 14 bit en stereo . de i2s botstream is dan nog pakweg 1.4 megabit.

kijk in uw datasheet wat de clockrate van uw a/d convertor is, kijk wat de klok van je atmel is en hoevel klokpulsen per instructie ( let op dat je clockPULSEN en geen clockcycli te pakken hebt. ) en doe je rekenwerk
*/

Nou ben ik bezig met het formuleren van deze probleemstelling alleen kom ik niet helemaal uit wat jij met je tekst bedoelt. Echter ben ik verder erg dankbaar voor jou reactie op mijn posting en ben ik een stapje verder gekomen. Maar nog steeds probeer ik met een rekensom te bewijzen waarom een Atmega 32 kansloos is om data afkomstig van de I2S-bus te verwerken.
Zou jij mij misschien specifieker kunnen uitleggen wat jij met je verhaal bedoelt.

Vriendelijke groet Daryl

Op 13 juli 2006 11:25:51 schreef Gert-Jan1981:
Zou het mogelijk zijn om I2S in te lezen via SPI?

Waarschijnlijk wel via de USI, die kan op fclk/2/fclk/4 draaien, dus een 20MHz xtal kan ie op 10MHz data uitsturen (master) en op 5MHz inlezen (slave)
Geloof niet dat een ATmega32 een USI heeft.

Universal Serial Interface – USI

The Universal Serial Interface, or USI, provides the basic hardware resources needed
for serial communication. Combined with a minimum of control software, the USI allows
significantly higher transfer rates and uses less code space than solutions based on
software only. Interrupts are included to minimize the processor load. The main features
of the USI are:
• Two-wire Synchronous Data Transfer (Master or Slave, fSCLmax = fCK/16)
• Three-wire Synchronous Data Transfer (Master, fSCKmax = fCK/2, Slave fSCKmax = fCK/4)
• Data Received Interrupt
• Wakeup from Idle Mode
• In Two-wire Mode: Wake-up from All Sleep Modes, Including Power-down Mode
• Two-wire Start Condition Detector with Interrupt Capability

[Bericht gewijzigd door RES op maandag 31 juli 2006 18:19:15 ]

Maar met welke conclusie/berekening kan ik komen om te zeggen dat het met de Atmega 32 moeilijk wordt?

Op 31 juli 2006 19:57:04 schreef Gert-Jan1981:
Maar met welke conclusie/berekening kan ik komen om te zeggen dat het met de Atmega 32 moeilijk wordt?

Er zit geen ultra snelle seriele interface in de ATmega32. (een USI.)
USART, SPI, TWI, (1-wire, biphase, etc.) allemaal te traag, alleen een USI, omdat dat eigenlijk bitbangen is, maar dan met een extra gedeelte in de hardware gebakken om de rest te ontlasten.
Alleen direct softwarematig bitbangen kost meer instructies, dus meer tijd, vandaar dat ze die USI erin hebben gebakken.
Conclusie: Andere AVR (met een USI erin.) kiezen, dan zou het moeten kunnen. (nog niets over te vinden op het net.)

Ben inmiddels een stapje verder.
Please correct me if I am wrong!

Stel sample freq = 96 kHz --> SCK frequentie op I2S-bus is
64 * 96 kHz = 6MHz --> T = 1/f = 1 / 6MHz = 166ns per SCK cyclus.
De USART van de Atmega 8 werkt met een frequentie van Fxtal / 4 --> stel klok Atmega is 32--> 16MHz/4 = 5MHz waarbij geldt --> T = 1 / 4MHz = 250ns.
hmm de USART krijgt het al moeilijk.
Nu niet te vergeten dat we te maken hebben met een data pakket van 2 x 32 bits per cyclus op de I2S-bus.
De Atmega werkt volgens het 8-bits RISC dus USART doet er 64/8 = 8 keer over per cylus op I2S-bus. Is gelijk aan 8 x 250ns = 2us!!!
De USART heeft dus 2uS nodig om 1 datapakket van de I2S-bus binnen te halen en te verwerken.

Hoop dat ik het juist heb anders hoor ik het wel

Ik weet niet precies hoe I2S werkt.
Misschien heb je hier wat aan?

http://www.semiconductors.philips.com/acrobat_download/various/I2SBUS.…

Ik las ergens dit.

And as far as I can see there should be possible to use SPI and thus also USI to make an I2S driver but I cant tell exactly how. Also, you would need to control the WS line manualy in driver based on which audio channel which is beeing transfered. It should be an easy task however.

BITCLK and LRCLK is not related to I2S but to the Direct-Stream Digital (DSD) standard, I beleive. But this is completely different from I2S.

Een AT89C5132 heeft wel een I2S eenheid.

USB C51-based Microcontroller with 64K Bytes Flash, 2304 bytes RAM, 4 USB Endpoints, SPI, UART, IDE, TWI, MultiMediaCard, DataFlash, I2S, 10-bit ADC.

http://www.atmel.com/dyn/products/product_card.asp?part_id=2890

[Bericht gewijzigd door RES op dinsdag 1 augustus 2006 14:35:46 ]