MASS STORAGE.

[fabim]

Pessoal.
A porta usb de PC vai de 1.1 a 2.0.

Existe a lenda de 12Mbps generico para USB 2.0 HID e afins.
Só que tipo, quando se usa um pendrive no pc, sabemos que a velocidade é estupidamente rapida!!!!!
Se usarmos aqueles PENDRIVES tocadores de MP3, logicamente a velocidade é de no maximo 12Mbps..

Ai que esta, o meu armizinho, "atende perfeitamente", mais porque ele acessa o pendrive no maximo a 12Mbps ? Tipo, a velocidade é parecida com a de um MP3 player-Pen drive..

Procurei no usb.org, e não achei nada explicando tipo.
Olha pra mass storage, você precisa de tal protocolo pra aumentar a velocidade de transição.. etc

Alguém ja leu algo em algum lugar sobre isso ?

[fabim]

é realmente, fiz varios testes, de varias formas..
Nao passa de 1.12MBps, usando bulk de 8192 bytes..

Bão tamén...

[mastk]

Que eu saiba fabim, USB 2.0 em full ou eh high speed chega a 100Mbps

[msamsoniuk]

nao era para ser 480 mbit/s? segundo as lendas, usb 1.0 eh 12 mbps, usb 1.1 eh 12 mbps + 1.5 mbps e usb 2.0 eh 1.5 mbps, 12 mbps e 480 mbps.

[proex]

Meninos, a interface USB encontrada em MCus nao é a mesma encontrada em PCs.

Quando digo que não é a mesma, me refiro a velocidade e a capacidade de gerenciar varios dispositivos.

Na USB do meu PC consegui ler e reproduzir 6 musicas simultâneamente , no formao MP3. Ou seja, a capacidade de tranferencia de dados de uma USB de PC é muito alta.

No MCU não, no maximo uma ou duas simultâneamente.

[Rodrigo_P_A]

Acho que você tem que fazer técnica de buferização, e não ficar amarrando na velocidade do dispositivo

[fabim]

ja descobri o que era rodrigo!!!! O junior é um animal e nem me lembrou... hehehe Por isso eu odeio ele!!!!!!!!!! ehehe

Seguinte..

Puxei 79.862.328 bytes em 432 segundos.....

Só que é um problema!!!!!!!
Eu estava baseando no seguinte.

Ja existe um arquivo, eu tava puxando pro arm, e devolvendo para o pendrive..
Fica.
Tempo = Tempo para puxar, processar, tempo para devolver...

Sendo assim, na verdade se eu for só escrever ou só ler. a velocidade é igual a.

79.862.328 * "8 bits" = 638898624Mbit.. em 432/2Segundos.

638898624Mbit/216 segundos"média 2" = 2 957 864Mega Bit... ou 369.733KBps..

Bão bagarai..!!!!!!

[msamsoniuk]

o problema eh que nao tem memoria e a memoria que tem nao tem bandwidth... para conexao de 480 Mbit/s seria necessario bandwidth de 60MB/s. e se vc pegar como referencia um mcu de 64KB de sram e colocar metade para buffers, vc tem 60MB/s dividido em 32 buffers de 1KB (que eh o payload maximo para high speed)...e isso significa que vc tem que tratar 60 mil frames/segundo, do contrario o buffer estoura. como vc tem um buffer de 32 entradas, vc pode agrupar interrupcoes e atrasar elas, o que significa algo em torno de 4 mil interrupcoes/segundo, cada uma delas tratando em media metade dos buffers enquanto a outra metade esta sendo ocupada para a proxima interrupcao.

eh um contraste grande com HDLC e ethernet, onde a performance eh tratada com maior importancia. no caso de HDLC operando a 2Mbit/s, eu vi o pessoal utilizar tipicamente 32 buffers de 1500 bytes. no caso de ethernet a 100Mbit/s, as implementacoes tipicas reservam 1000 buffers de 1500 bytes. nao parece, mas bursts rapidos com frames curtos, o processador normalmente demora para reagir e a ocupacao dos ring-buffers vai lah em cima. as vezes o pessoal dimensiona mal e mesmo produtos desenhados para telecom acabam arriando com um simples ping-flood, sem que seja necessario ocupar toda a banda disponivel, mas ao inves disso atingindo o limite de frames/segundo que o equipamento suporta.

outro problema eh a operacao em multiplas velocidades... ou vc esta operando a 480 Mbit/s ou a 12 Mbit/s ou entao a 1.5 Mbit/s, mas nao a todas ao mesmo tempo. se vc precisa transferir dados por um USB/serial de 1.5Mbit/s, vc toma uma janela de tempo grande que poderia ser usada pelo dispositivo de 480 Mbit/s... ficar mexendo a seta do mouse na tela, portanto, causa atrasos na transferencia de um HD externo pq vc fica consumindo banda preciosa. ethernet nao eh diferente se vc usar um HUB, mas se usar um switch o equipamento forma um buffer que compensa as portas mais lentas e todas as portas rapidas podem se manter operando na velocidade maxima sempre.

Acho que você tem que fazer técnica de buferização, e não ficar amarrando na velocidade do dispositivo

[fabim]

to fazendo o bulk em 4 * 4096 bytes!!!!!!!
Ele tem um bulk de maximo 4096 bytes... e to usando no talo !!!!!!

[msamsoniuk]

Nao poderia ser por DMA ? Se tiver....

se nao tiver DMA tah ferrado! vai ser uma chuva de interrupcao sem parar! :D

[tcpipchip]

Eu lembro que no ECG (projeto ST), o ST ARM7 capturava os dados do batimento cardiaco, filtrava os ruidos e entao a transferia para USB via DMA...enquanto capturava novos dados do batimento....

Eu nunca tinha visto na pratica...só teoria...

[fabim]

intão, vejam só como é.

O host do LPC, manda microframes de até 256 bytes!!! e é o seguinte.
Aponto um endereço qualquer, falo para o MS que é pra mandar, ele só vai no host e manda bala, e ja volta!!!
Isto para microframes, só que no meu caso. Eu to brincando de menino grande e com dois buffers de 8KB em ping pong pra tentar tocar audio em wav..
Mais tem uma pá de erro louco, e acabei de descobrir que realmente. Quando o ARM ta lá no FAT32 pegando dados, as interrupções do sample audio de 62.5uS estão fazendo o arm se perder..!!!!!
A prioridade o TMR0 MTH0 é primeira que o USB..

Estou fazendo mais alguns testes, mais de inicio ja esta muito bom 3Mbit. Bom mesmo!!!

[msamsoniuk]

nao tem nenhuma queue ou buffer para essa saida de audio? 62.5us eh cavalarmente apertado! :P

intão, vejam só como é.

O host do LPC, manda microframes de até 256 bytes!!! e é o seguinte.
Aponto um endereço qualquer, falo para o MS que é pra mandar, ele só vai no host e manda bala, e ja volta!!!
Isto para microframes, só que no meu caso. Eu to brincando de menino grande e com dois buffers de 8KB em ping pong pra tentar tocar audio em wav..
Mais tem uma pá de erro louco, e acabei de descobrir que realmente. Quando o ARM ta lá no FAT32 pegando dados, as interrupções do sample audio de 62.5uS estão fazendo o arm se perder..!!!!!
A prioridade o TMR0 MTH0 é primeira que o USB..

Estou fazendo mais alguns testes, mais de inicio ja esta muito bom 3Mbit. Bom mesmo!!!

[fabim]

marcelo, eu não entendi sua pergunta.......

Eu comecei a mecher com audio digital a muito pouco tempo, e processo de audio nunca mexi na vida, éssa é a primeira vez.
Tu pode dar um help, e explicar melhor isso ?

Abraços

[msamsoniuk]

entao, vc falou em 62.5us, o que daria algo em torno de 16KHz... isso contrasta muito com os processadores q eu conheco, onde o volume de interrupcoes para tratar audio eh muito menor. nesses sistemas normalmente existem canais de dma e ring-buffers, de modo que eh possivel ler e receber varios frames de audio antes do processador ser interrompido. na pior das hipoteses as transferencias podem ser feitas pelo processador, porem existem buffers suficientes para que nao seja necessario fazer interrupcoes muito periodicas. claro, se vc nao tem como ter ring-buffers ou nao tem buffers no hardware, tem que ir para interrupcoes amostra a amostra mesmo. e daih o negocio eh deixar o mais realtime possivel, limpando todas as rotinas de tratamento de interrupcao de modo que a interrupcao de audio nunca fique mascarada por outra. sei lah, tb nao sei os detalhes de como vc esta fazendo...

marcelo, eu não entendi sua pergunta.......

Eu comecei a mecher com audio digital a muito pouco tempo, e processo de audio nunca mexi na vida, éssa é a primeira vez.
Tu pode dar um help, e explicar melhor isso ?

Abraços