Interpretação DMA.

Software e Hardware para linha ARM

Moderadores: 51, guest2003, Renie, gpenga

Mensagempor msamsoniuk » 14 Mar 2012 23:22

opa! os coldfires tem um modulo chamado "dma timer", que consiste em um elaborado sistema programavel de ativacao do controlador de dma. na pratica vc pode escolher entre um impulso externo (borda de subida, descida, etc) ou impulso interno, daih seta um prescaler e vai ter entao um pulso periodico ou nao, que vai disparar o controlador de dma. o controlador, por sua vez, eh do tipo 2D. digamos que vc tem um buffer de video: vc vai setar o dma timer para gerar 31.5kHz e, a cada disparo, vc quer que o controlador transfira, digamos 800 bytes. eh o que eles chamam de loop menor. o loop maior pode ser setado para 525, por exemplo, o que significa que ele vai fazer 525 transferencias de 800 bytes cada e vai gerar uma interrupcao. alternativamente a interrupcao, ele poderia terminar as 525 transferencias com um reload, que seta novamente o loop maior e menor para o inicio, assim o controlador automaticamente transfere 525 blocos de 800 bytes e recomeca sozinho. bom, cada transferencia de 800 bytes nao tem cadencia: ela ocorre na maior velocidade possivel. entao uma solucao inicial seria ter uma fifo de 800 bytes no controlador de video. mas transferir 800 bytes toma o bus e faz a latencia do processador aumentar muito. outra solucao eh configurar o controle de banda: o coldfire permite setar o controle de banda do bus para valores de 100%, 75%, 50%, etc. na pratica, em 50%, significa que a cada transferencia o controlador libera o processador p/ uma transferencia antes de pedir o bus novamente p/ fazer sua transferencia.

tem um caso interessante onde eu usei isso: um controlador de comunicacoes HDLC que tinha uma fifo de 32 bytes apenas. mas este controlador podia receber frames muito maiores, com ateh 320 bytes. entao eu configurei o loop menor p/ transferir blocos de 32 em 32 bytes e o loop maior para 10 blocos. o resultado eh que o controlador de comunicacoes e o controlador de dma do coldfire interagiam sem controle de software para transferir entre 32 e 320 bytes. finalizada a transferencia, eu nem gerava interrupcao no controlador de dma, mas sim no controlador de comunicacoes. isso disparava a rotina de tratamento de frame, que trocava o ponteiro do controlador de dma para um frame novo. note q eu nao ficava movendo dados nunca na memoria: eu simplesmente passeava os ponteiros dos frames para cima e para baixo sem mover na memoria. a unica hora em que eles eram realmente inteiramente manipulados era na transmissao ou recepcao via dma.

voltando ao mundo real, eu nao entendo o que vc nao entendeu... mas imagina que vc tem sua interface SPI rodando a 8MHz. entao, na realidade, sua interface pode trabalhar no maximo a 1MB/s e, portanto, ela vai gerar dma requests a taxa de no maximo 1 milhao de requests/segundo. ou seja, quem cadencia a transferencia eh o periferico. porem, a transferencia do periferico p/ memoria ou memoria p/ periferico vai consumir precisamente os clocks necessarios p/ acessar a memoria e o periferico. o periferico soh ativa o dma quando esta pronto, entao o dma nao vai ficar testando flag ou nada do genero, simplesmente vai transferir um dado disponivel e pronto.

eh claro, o fato da minha SPI trampar a 1MB/s nao quer dizer que eu tenha um buffer na memoria de 1MB. em termos praticos, a SPI recebe o que vc transmite, entao, quando vc transmite um frame de 100 bytes, e vc vai setar o tamanho de transmissao para 100 bytes no controlador de dma, vc vai receber um frame de 100 bytes tb e, no final desse frame, vai querer uma interrupcao p/ avisar que o frame foi recebido...veja bem: eu quero aproveitar o tempo do dma justamente para fazer outras coisas, portanto eu nao fico olhando o bit done! hehehe

pensa na seguinte dinamica:

- um thread "X" tem um modulo de controle que transmite comandos e dados p/ um device. essa thread prepara um bloco de comandos e dados e envia p/ cima. como retorno, ela vai ter justamente o bloco de comandos e dados de resposta do periferico. digamos que vamos mandar 100 bytes.

- o driver de transmissao eh ativado diretamente e seta no controlador de dma para que aponte p/ aquele frame de comandos e dados de 100 btyes, ao mesmo tempo, programo o controlador de dma da recepcao p/ q aponte p/ um novo frame de comandos e dados com o tamanho de 100 bytes tb. programado o dma, eu ligo o bit de transmissao da SPI e, cada vez q ela estiver com a fifo vazia, ela vai puxar algo via dma.

- feito isso, eu escalo a thread "Y" para rodar, pq a thread "X" esta "dormindo", esperando o SPI, entao eu aproveito o tempo p/ o processador fazer outra coisa.

- quando o controlador de dma termina de receber os 100 btyes de resposta, ele gera uma interrupcao. essa interrupcao serve p/ indicar que a transferencia foi feita e a thread "X" pode ser acordada. vc pode optar escalonar a thread "X" ou, simplesmente, tirar ela da lista de threads dormindo (o mais facil neh, vc faz isso e retorna p/ a thread q esta em execucao).

- quando houver um escalonamento, a thread "X" acorda e bingo: ela acorda com o buffer de recepcao preenchido com os 100 bytes lah da SPI.

nao parece tao logico quando usamos SPI, mas pense em um microcontrolador com duas ethernets e vc jah visualiza quatro threads totalmente concorrentes: 2 threads de TX e 2 threads de RX. para saturar o bandwidth de cada interface tanto no RX quanto TX, vc tem que uasr esse tipo de escalonamento e usar dma, senao o negocio arria! :)

nao sei se responde suas duvidas... mas a sua frase entre aspas parece verdadeira! hehehe

fabim escreveu:Nossa será que to falando çhineix ?
hehehe
Eu observei vários DMAs, e nenhum deles pode-se configurar finamente o digamos sample rate !! hehehe
Procurei 3 app note de fabricantes diferentes, e todos eles.

Confirmaram o que eu imaginava e perguntei a afirmação ou não lá encima noprimeiro post.

" A transferencia pela DMA de dados para periférico, é controlado automaticamente sem a intervenção de software. A velocidade de transferencia de bytes é limitada pela velocidade de transferencia do periférico."

hehehe, tendeu agora minha duvida sam ?
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor fabim » 15 Mar 2012 08:45

o sam é um viadinho.
O terceiro paragrafo "bloco", ja respondeu afirmativamente o que eu afirmei perguntativamente.!!! hehehe

Agora eu sei como utilizar o inferno do DMA com um módulo que eu recebi de amostra.

Cara, eu sempre ficava imaginando por causa de demos de uso da DMA.
Nossa mais uma int por byte, ta loco.

hehehe
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor tcpipchip » 16 Mar 2012 13:24

Bomba

Por falar em DMA...a ultima versao do UCLINUX M3 já gerencia DMA...segundos alguns gringos....

"DMA and AUDIO DRIVERS for NXP's LPC178x"

TCPIPCHIP

PS: como a gente se empolga com algo que se viu na disciplina SISTEMAS OPERACIONAIS :(
Avatar do usuário
tcpipchip
Dword
 
Mensagens: 6560
Registrado em: 11 Out 2006 22:32
Localização: TCPIPCHIPizinho!

Anterior

Voltar para ARM

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

x