Inteface I2S do LPC2368.

[proex]

Estava com a intenção de usar o 2368 numa aplicação de audio digital com 24 bits de resolução.

Mas observando a interface I2S do arm, notei que desabilitaram a configuração do tamanho da palavra de audio para 24 bits.

No LPC só podemos configurar o I2S para trabalhar com palavras de audio do tamanho de 8, 16 ou 32 bits. Justamente o tamanho de 24 bits, que é o padrão atual de audio digital, não é permitido.

Por que será que os manés fizeram isso?

O barramento I2S dos conversores A/D e o DSP da minha placa são todos de 24 bits. Ou seja, haverá um pulso de clock para cada bit da palavra.

Como fazer o Arm entender 24 bits?

.

[Djalma Toledo Rodrigues]

00000000xxxxxxxxxxxxxxxxxxxxxxxx

Não pode colocar os 24 Bits no registro de 32 Bits justificado a direita ou a esquerda ?
.

[proex]

Poderia mas os conversores A/D, por serem de 24 bits, só irão fornecer 24 pulsos de clock. O Arm por sua vez vai esperar 32 pulsos de clock se estiver setado para palavras de 32 bits.

[pbernardi]

Pelo que endendi são duas placas separadas, não proex? Qual a limitação em se setar o I2S para 32 bits? Velocidade ou não está disponível nos DSP/conversor?

Uma opção seria colocar uma CPLD no meio. Mas imagino que você não queira adicionar mais um componente com tal complexidade... o que poderia ser feito é ligar um pino de saída do LPC em uma porta OR.

A idéia que tive seria mais ou menos assim: ligar o pino do ARM e o clock na entrada da porta OR, e a saída da porta OR na entrada do clock do ARM. O pino de saída do ARM ficaria em default em nível baixo. Assim, toda vez que você detectasse que recebeu algo na porta I2S, dá um jeito de temporizar isso e o próprio ARM poderia gerar os pulsos restantes.

Talvez haja um problema se você tiver duas transmissões muito rápidas, e o ARM não tiver tempo de mandar os pulsos de clock nesse meio-tempo, mas acho que isso poderia ser contornado por software. E, também, esse método pode ser problema se sue limitador realmente for velocidade de adquisição, você irá perder algum tempo até receber os bits, temporizar isso de alguma forma e enviar os 8 clocks restantes você mesmo. Mas acho que vale a pena tentar.

[fabim]

paulo, o buraco é mais embaixo.
Tava falando com o manéx ontem e dei uma pesquisada.
O problema do I2S é o MSCLK.
Ele rege o sample rate do DAC ou ADC da interface I2S.
Por exemplo para 24 bits, e 48Ksps.
A velocidade do MSCLK =
Numero de bit´s X frequencia de amostragem = 24 * 48000 = 1152000
para uma setagem de 32 bits = 32 * 48000 = 1536000
Sobre velocidade sem problemas, pois o tempo para determinado frame rate e numero de bits é conhecido.

O problema é, Se o serial shift da interface I2S ou do LPC23.., vai deixar ele perder 8 + 8 bits LSB quando o LSCLK fazer a mudança de estado para o latch que fica neste barramento de serial shift carregar o ADC ou DAC..

É pirex, acho que so fazendo teste mesmo.
O problema é que se você colocar 32 bits stereo(16R-16L), e mandar o msb primeiro, de qualquer forma você vai estar perdendo 8 bits MSB e não LSB, aí froid tudo.
Vai ter que pegar dentro do LPC audiodata>>8; e ,mandar bola para o DAC, o duro é como pegar isto no ADC...

Froid..

Abraços o caramba, MORRA!!!

Fabim

[proex]

Fabim, nao é 32 bits stéreo 16+16 e sim 24+24.

[fabim]

Fabim, nao é 32 bits stéreo 16+16 e sim 24+24.

eu sei putex....

Estou dizendo que se jogar 16+16, eles vão ser apenas o LSB e vai perder os 8 bits msb. ..
Lasco

[proex]

Não tem 16 bits envolvido nessa estória. Nem pode, a resoluçao da minha placa é de 24 bits.

Abaixo segue a sinalizaçao do I2S do meu DSP comparado com o I2S do ARM configurado para 32 bits:

DSP= [D23 .........Canal Dir .........D0] [D23.............Canal Esq ........D0]

ARM= [D31..........Canal Dir............................D0] [D31 .............................Canal Esq................D0]

Entenderam a encrenca?

.

[fabim]

putex, hum........
olha só.
Posso até estar enganado mais pense bem,
Dentro do DAC I2S tem um serial shift e um latch de 24 bits.
Se você empurrar 32 bits, ele perde os 8 de cima e pega os 24 de baixo.
Quando o LSCLK fazer a troca ele da o strob e carrega o latch do DAC com os 24bits lsb desta palavra de 32.

Num tem como fazer um testinho aí?

[msamsoniuk]

vc jah experimentou configurar o ambiente para fazer o processador gerar RCLK e RFS? em principio o dispositivo periferico deveria fazer as transferencias alinhadas com a comutacao de RFS do master: se o master troca o RFS a cada 32 clocks, o periferico deveria transferir os seus 24 bits nos primeiros 24 clocks e ignorar o resto ateh o RFS comutar.

[proex]

É que na placa já existe um DSP que é o Master do I2S. Ele gera o BITCLK e o LRCLK para os A/Ds e D/As.

Dai resolvi botar um ARM no circuito pra capturar o audio pelo I2S e gravar num cartão de memoria.

O Arm neste caso tem que ser Escravo do I2S.

Pelo que li, o sinal LRCLK é o que indica o fim da palavra de audio, de acordo com a quantidade de bits enviados.

Acho que dá pra contornar essa deficiencia do arm. O Arm vai receber os 24 bits da palavra de audio e o sinal LRCLK vai indicar o fim da palavra.

Então, teremos no registrador de 32 bits do arm, apenas 24 bits, qué é justamente o que eu quero.

Sei lá, só testando na prática mesmo.

[mastk]

Mas no LPC2138 era possivel configurar quantos sao enviados na SPI, nesse cara nao da? mandar 3 pacotes de bits nao resolve?

[fabim]

vc jah experimentou configurar o ambiente para fazer o processador gerar RCLK e RFS? em principio o dispositivo periferico deveria fazer as transferencias alinhadas com a comutacao de RFS do master: se o master troca o RFS a cada 32 clocks, o periferico deveria transferir os seus 24 bits nos primeiros 24 clocks e ignorar o resto ateh o RFS comutar.

Esquece, você ta pensando como eu.
Mais nesse caso o arm é o SLAVE, e o DSP o master..

[polesapart]

http://www.embeddedrelated.com/groups/l ... /36503.php