Entrar    Registrar

LPC1768 DMA.

Software e Hardware para linha ARM

Moderadores: guest2003, 51, Renie, gpenga

  • Autor
    Mensagem

LPC1768 DMA.

Mensagempor fabim » 05 Ago 2015 12:55

Pessoal,
Gastei uns dois dias e já consegui entender como funciona a configuração do DMA de memoria para periférico, e já esta funcionando.
Mas estou com um problema que não consigo resolver, já pesquisei na net, no datasheet. Existe algo que esta passando despercebido por mim!

Quando eu habilito o DMA, ele começa a cuspir 28bytes pela serial como eu queria, tudo lindo!
Só que eu queria que ele cuspisse 28bytes apenas, e desligasse. De forma que eu habilitei a interrupção, e dentro da interrupção eu desligo o canal.
Mas após eu desligar, se eu ligar novamente FERROU!
Ele fica disparando os bytes indefinidamente e a interrupção para de funcionar :(

Alguém aqui já usou DMA dos LPC17 e sabe o que pode ser ?
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 4955
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Re: LPC1768 DMA.

Mensagempor tcpipchip » 05 Ago 2015 14:27

Eu vi no mbed.org o pessoal discutindo algo parecido...

https://developer.mbed.org/users/dpslwk ... T_example/
------------------------------------------
http://www.youtube.com/tcpipchip
Avatar do usuário
tcpipchip
Dword
 
Mensagens: 5745
Registrado em: 11 Out 2006 22:32
Localização: TCPIPCHIPizinho!

Re: LPC1768 DMA.

Mensagempor fabim » 06 Ago 2015 13:55

Bem, como eu nunca havia utilizado DMA.
Pode ser que eu esteja engolindo caroço no raciocínio.

Pergunto -:
DMA é utilizado para ficar 100% do tempo lendo certa região, e movendo-a para outra ?. Seja ram para ram, ou periférico para periférico ?.
OU
DMA também pode ser utilizada para disparar uma certa quantidade de dados e ao final não fazer mais nada!?.

Alguém já utilizou isto na unha ?
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 4955
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Re: LPC1768 DMA.

Mensagempor andre_teprom » 06 Ago 2015 16:49

Eu já usei num projeto com o Z80, mas não foi na unha, tava tudo pronto escrito em C.

O problema que eu vejo na utilização do DMA ao menos na arquitetura padrão ( a unica que conheço ) onde a CPU fica no centro de tudo, é que o DMA ocupa o barramento do uP, e como os cores atualmente são mais velozes que os perifericos, dependendo da velocidade do destino pra onde estiver transmitindo, o DMA pode não fazer muita diferença, acho eu.
"Por maior que seja o buraco em que você se encontra, relaxe, porque ainda não há terra em cima."
Avatar do usuário
andre_teprom
Dword
 
Mensagens: 5265
Registrado em: 11 Out 2006 18:27
Localização: Brasil - RJ

Re: LPC1768 DMA.

Mensagempor tcpipchip » 07 Ago 2015 06:58

Eu tambem peguei pronto, para ARM STM32.
Lia um canal AD e jogava uma sére de leituras para uma área específica da RAM.
------------------------------------------
http://www.youtube.com/tcpipchip
Avatar do usuário
tcpipchip
Dword
 
Mensagens: 5745
Registrado em: 11 Out 2006 22:32
Localização: TCPIPCHIPizinho!

Re: LPC1768 DMA.

Mensagempor fabim » 07 Ago 2015 07:37

Cara, nossa.

André.
O que você me disse, deu um nó na minha cabeça.
Um SO utiliza DMA pra praticamente tudo, e enquanto dados etc são movidos o SO esta executando outras coisas no cache, ou na própria ram que seja.
Não entendi ao certo o que você quis afirmar.

Bom, enfim, ontem depois de ficar o dia todo escrevendo em papel, ticando os comandos etc. Me toquei que estava esquecendo algo importante.
Segue as rotinas:
Código: Selecionar todos
 #define Bytes_Out 10
#define DMA_SEND  LPC_GPDMACH0->CConfig|=0x00000001
#define DMA_STOP  LPC_GPDMACH0->CConfig&=~(0x00000001)


typedef struct{
  unsigned int  source;         // start of source area
  unsigned int  destination; // start of destination area
  unsigned int  next;        // address of next strLLI in chain
  unsigned int  control;     // DMACCxControl register
}LLIO;

 LLIO buff;

void DMA_IRQHandler (void)
{
    unsigned int regVal;
 
   regVal = LPC_GPDMA->IntTCStat;
   if( regVal & (0x01) )
   {
     LPC_GPDMA->IntTCClear |= 0x01;
   }
   
   regVal = LPC_GPDMA->IntErrStat;
   if( regVal & (0x01) )
   {
     LPC_GPDMA->IntErrClr  |= 0x01;
   }
   
   DMA_STOP;
   LPC_GPIO3->FIOPIN ^= 1<<26;
}
 

void DMA_start(unsigned int *Source, unsigned int *Dest,unsigned char Num_Bytes ,LLIO *Controle){
   
  Controle->source      = (uint32_t)Source;  //source data
  Controle->destination = (uint32_t)Dest;    //direção data
  Controle->next        = (uint32_t)Controle ;    //endereço dele mesmo
  Controle->control     = 0x80000000 |1<<26 | Num_Bytes;

     /* clear all interrupts on channel 0 */
    LPC_GPDMA->IntTCClear = 0x00000003;
    LPC_GPDMA->IntErrClr  = 0x00000003;
    LPC_GPDMA->Sync       = 0x00000000;                         // enable synchro logic for all reqs
     LPC_SC->DMAREQSEL     = 0x00000000;

    LPC_GPDMACH0->CSrcAddr  = (uint32_t)Source;     //seta endereço de leitura de dados na memoria RAM
    LPC_GPDMACH0->CDestAddr = (uint32_t)Dest;       //seta endereço de escrita de dados no registrador de envio de dados pela serial
    LPC_GPDMACH0->CLLI      = (uint32_t)Controle;   // linked lists for ch0
    LPC_GPDMACH0->CControl  = Num_Bytes             // transfer size (0 - 11) = 64
                            | (0 << 12)               // source burst size (12 - 14) = 1
                            | (0 << 15)               // destination burst size (15 - 17) = 1
                            | (0 << 18)               // source width (18 - 20) = 32 bit
                            | (0 << 21)               // destination width (21 - 23) = 32 bit
                            | (0 << 24)               // source AHB select (24) = AHB 0
                            | (0 << 25)               // destination AHB select (25) = AHB 0
                            | (1 << 26)               // source increment (26) = increment
                            | (0 << 27)               // destination increment (27) = no increment
                            | (0 << 28)               // mode select (28) = access in user mode
                            | (0 << 29)               // (29) = access not bufferable
                            | (0 << 30)               // (30) = access not cacheable
                            | 0x80000000;             // terminal count interrupt disabled

    LPC_GPDMACH0->CConfig   =  1        /*(bit 0)*/     // channel enabled (0)
                            | (0 << 1)    /*(bit 5-1)*/   // source peripheral (1 - 5) = none
                            | (12 << 6) /*(bit 10-6)*/   // destination peripheral (6 - 10) = SER2
                            | (1 << 11) /*(bit 13-11)*/ // flow control (11 - 13) = mem to per
             | (1<<14)   /*(bit 14)*/    // habilita flag gera interrupção por erro de barramento
                            | (1<<15)   /*(bit 15)*/    // habilita flag de tratamento da interrupção
                       | (0<<16)   /*(bit 16)*/    // não utilizado
                            | (0<<17) ;  /*(bit 17)*//   // apenas leitura
                               
   
      
    LPC_GPDMA->Config = 0x01;                          // enable the GPDMA controller
    while ( !(LPC_GPDMA->Config & 0x01) ); 
      
    NVIC_EnableIRQ(DMA_IRQn);//habilita interrupção de DMA
}


DMA0_Init((unsigned int *)&datos[0],(unsigned int *)&LPC_UART2->THR,  sizeof(datos), &buff);
   
 


As configurações acima estão para RAM->UART2.
Peguei exemplos, capinei, reguei, joguei esterco.
Ai nasceu isto ai, e funcionou lindamente bem.
Só que fiz um teste aqui:

Eu mandei ele enviar 512 bytes pela uart2 a 1200 bauds;
o tempo transcorrido por frame é de, 4,2666666666666666666666666666666 segundos;
Neste meio tempo, quando ele dispara a transmissão, eu entro num loopin para piscar um led a cada 100mS gerando 5hz de cintilancia.
O uP não fica com barramento ocupado como o André disse!
Ou é outra coisa, e eu entendi mal?
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 4955
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Re: LPC1768 DMA.

Mensagempor tcpipchip » 07 Ago 2015 11:07

Sim, utiliza o barramento quando o mesmo estiver livre...

Mas, FABIM, você já sabe disto!!!! Estas zoando né :)
------------------------------------------
http://www.youtube.com/tcpipchip
Avatar do usuário
tcpipchip
Dword
 
Mensagens: 5745
Registrado em: 11 Out 2006 22:32
Localização: TCPIPCHIPizinho!

Re: LPC1768 DMA.

Mensagempor msamsoniuk » 07 Ago 2015 14:29

tcpipchip escreveu:Sim, utiliza o barramento quando o mesmo estiver livre...

Mas, FABIM, você já sabe disto!!!! Estas zoando né :)


zueira forte, no minimo, pq 150 bytes/s de uma UART de 1200bps em um barramento q opera a 50Mbytes/s realmente nao vai mostrar diferenca nenhuma... mas facam as contas ae fabim e andre, com um exemplo mais palpavel em termos de volume de dados:

void memcpy(char *s, char *d, int size)
{
while(size--) *d++ = *s++;
}

converte isso para asm na sua arquitetura hipotetica preferida, por exemplo:

// puxa da stack
move.l *sp++,d0 // size
move.l *sp++,a0 // *d
move.l *sp++,a1 // *s
// loop
loop:
move.l *a1++,*a0++ // *d++ = *s++
dbnz d0,loop // se (d0--)!=0 -> loop
// retorna
ret

supondo 1 clock por instrucao, vc tem um loop com 2 instrucoes. mas nesse caso eu usei uma arquitetura cisc com arquitetura von newman, portanto vai 1 clock para puxar a instrucao move, 1 clock para ler o operando, 1 clock para escrever o operando, 1 clock para decrementar e comparar o contador e 1 clock para limpar o pipeline no branch, totalizando 5 clocks para mover 1 byte. se seu core hipotetico roda a 50MHz, vc vai mover 10Mbytes/s usando 100% da capacidade do processador.

digamos que o tamanho do seu problema, entao, eh menor, apenas 5Mbytes/s... isso significa que vc vai mover 5Mbytes/s usando 50% da capacidade de nosso processador hipotetico. e se fosse usar DMA? bom, partindo do pressuposto que o DMA pode fazer os acessos a memoria na mesma velocidade de 1 clock por operacao, vc teria portanto uma capacidade total de 50Mbytes/s usando 100% do tempo de barramento. como seu problema eh do tamanho de 5Mbytes/s, vc vai usar apenas 10% do barramento. ah, mas DMA consegue realmente essa performance? provavelmente. mesmo que o controlador nao seja muito grande coisa, veja que a operacao eh transparente, pq ele nao consome tempo de barramento, nem tempo de processador. a logica que incrementa os ponteiros e decrementa o contador existe igual, mas estah em um hardware que roda em paralelo com o processador.

entao, como conclusao, vc tem o seguinte: fazendo os 5Mbytes/s pelo processador, vc tem apenas 50% do processador livre. fazendo os mesmos 5 Mbytes/s pelo DMA, vc tem 90% do processador livre. o motivo eh simples: embora seja fato que o DMA concorre com o processador no uso do barramento, o overhead em torno da transferencia eh bem menor (ou menos exposto), o que permite ter mais tempo de barramento livre e, portanto, mais capacidade de execucao no processador.

isso eh um caso hipotetico de transferencia de dados bem otimizada, soh para diferenciar o overhead de um e de outro... o mundo real eh muito pior! pensa em uma interrupcao: o cara para o que estah fazendo, troca contexto, puxa o contexto da interface, transfere dados e retorna o contexto do que estava fazendo. digamos que isso eh para atender uma interrupcao que transfere um byte... e digamos que o processo todo gaste uns 25 clocks, daih vc vai estar entao gastando 25 clocks para transferir um byte, coisa que o DMA faz com um unico clock.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2882
Registrado em: 13 Out 2006 18:04

Re: LPC1768 DMA.

Mensagempor fabim » 07 Ago 2015 16:26

Né zoeira não!
André, como eu nunca mexi com DMA, me perdoe se eu fui sarcástico ao contrário, ou direto, não entendi ainda porque acham que estou brincando.

Eu entendi o André dizendo que:
Se usar DMA, e demorar digamos 200mS para mover os dados. O núcleo fica 200mS parada sem fazer nada, o que teoricamente seria o mesmo tempo gasto pra transferir na unha através de código.

No meu caso, eu vou disparar a DMA, e continuar fazendo outras coisas.
Fiz um teste, e o núcleo não fica preso quando eu disparo a DMA, ela fica cuspindo dados sem parar e o núcleo livre pra fazer qualquer outra coisa.
Quando diz ocupa o barramento, que barramento disse ?

Desculpe novamente se estou com cara de burro, é que hoje é sexta e acordo as 5 pra vir trabalhar, e chego em casa depois das 20:30, ficando 4 horas por dia em busa!
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 4955
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Re: LPC1768 DMA.

Mensagempor msamsoniuk » 08 Ago 2015 00:31

na realidade se vc demora 200ms para mover os dados via DMA, vai demorar uns 1000ms para mover os mesmos dados na unha via codigo. pegue esse 200ms do DMA e divida pelo volume de dados, provavelmente vc vai ter 1 clock para ler a memoria e 1 clock para escrever na memoria. uma implementacao simples disso em verilog vai gerar um pseudo-hardware mais ou menos assim:

reg [1:0] DMASTATE = 0; // estado do controlador: 0 = parado, 1 = leitura, 2 = escrita
reg [15:0] WPTR = 0; // ponteiro de escrita
reg [15:0] RPTR = 0; // ponteiro de leitura
reg [15:0] SIZE = 0; // tamanho

wire [15:0] DMAADDR = DMASTATE==1 ? RPTR : DMASTATE==2 ? WPTR : 16'hzzzz;
wire [15:0] DMADATA = DMASTATE==2 ? DATA : 16'hzzzz;
wire DMARD = DMASTATE==1 : 1'bz;
wire DMAWR = DMASTATE==2 : 1'bz;

reg [15:0] DATA; // temporario

always(posedge CLK)
begin
DATA <= DMASTATE==1 ? DMADATA : DATA;
RPTR <= DMASTATE==0 ? RPTR_PROG : DMASTATE==1 ? RPTR+1 : RPTR;
WPTR <= DMASTATE==0 ? WPTR_PROG : DMASTATE==2 ? WPTR+1 : WPTR;
SIZE <= DMASTATE==0 ? SIZE_PROG : DMASTATE==2 ? SIZE-1 : SIZE;
DMASTATE <= DMASTATE==0 && DMAENA ? 1 : DMASTATE==1 ? 2 : DMASTATE==2 && SIZE ? 1 : 0;
end

os estados de operacao sao 3:

quando DMASTATE==0, ele programa os ponteiros WPTR, RPTR e o tamanho SIZE, vindo de algum registro de configuracao, bem como deixa o DMAADDR em tri-state, para o processador usar. se neste estado parado o DMAEN mudar para 1, ele liga a maquina de estado que fica trocando DMASTATE entre os estados 1 e 2. com DMASTATE==1, o DMAADDR sai de tri-state e passa a ter o endereco de leitura da memoria. no caso, provavelmente DMASTATE diferente de zero para o processador, para q o controlador de DMA use o barramento de dados. eventualmente, em uma implementacao onde o processador tem cache, o processador pode continuar rodando a partir da cache. anyway, note que enquanto DMAADDR estah enderecando a memoria, o resultado serah gravado no registro DATA ao mesmo tempo em que RPTR eh incrementado e SIZE eh decrementado (como um pipeline, eu adianto isso para no proximo ciclo poder testar SIZE). DMASTATE vai entao para 2, onde ocorre algo similar, mas agora na escrita, com WPTR apontando a memoria de escrita e DATA sendo colocado no barramento de dados. enquanto a memoria estah gravando DATA no endereco DMAADDR, WPTR eh incrementado e tambem ocorre a mudanca de DMASTATE, que depende do valor de SIZE. se SIZE for zero, DMASTATE vai para 0 e a transferencia se encerra, senao vai para o estado 1 novamente e assim por diante.

bom, o conceito eh esse... note o numero de operacoes que eu faco em apenas dois clocks:

clock 1 = ler o dado em um registro temporario, incrementar o ponteiro de leitura, decrementar o indicador de tamanho
clock 2 = escrever o dado do registro temporario, incrementar o ponteiro de escrita, testar o indicador de tamanho para ver se a transferencia acabou

a mesma operacao feita na unha em um processador hipotetico, imaginando que cada operacao em assembler representa um clock:

clock 1: lod *rptr++,rtmp // carrega registro rtmp a partir do ponteiro rptr e incrementa rptr
clock 2: sto rtmp,*wptr++ // armazena registro rtmp na memoria apontada por wptr e incrementa wptr
clock 3: dec size // decrementa contador de tamanho
clock 4: bnz loop // testa e salta se size nao for zero

varia de processador para processador... se o processador usar pipelines, provavelmente tem uma penalidade ali no branch, mas vamos simplificar e imaginar que eh isso apenas. entao nesse exemplo, jah usamos 4 clocks. tem como otimizar mais? depende do processador. tem processadores em que vc nao pode incrementar os ponteiros no proprio acesso, entao vc teria 2 clocks extras com inc rptr e inc wptr. tem processadores que permitem mover *rptr++,*wptr++, mas obviamente a operacao consome pelo menos dois clocks, uma para ler e outra para escrever. e tem processadores com instrucoes magicas que decrementam, testam e saltam na mesma instrucao. mas acho que na melhor das hipoteses ainda usaria 3 clocks no loop principal...entao 200ms de transferencia de DMA transfere muito mais coisa que 200ms de transferencia via processador, pq o overhead eh menor no DMA. isso sem falar no overhead de setup: no caso do controlador de DMA, apenas um unico clock eh necessario para rearmar os ponteiros e o contador de tamanho. enquanto isso, no processador, vc vai ter que configurar registro por registro sequencialmente. e claro, o controlador de DMA estah sempre em espera pronto para comecar a transferir, ou seja, a latencia para inicio eh zero. no caso do processador, provavelmente vc vai disparar uma interrupcao, salvar o contexto corrente, configurar os registros para operar e soh entao comecar a transferencia. finalmente, jah comentei, mas vale enfatizar, se o processador tiver caches, o controlador de DMA opera em paralelo com o processador, ou seja, dobra o bandwidth!

bom, nao sei o que vc conclui, mas eu acho que temos claramente um vencedor aqui: DMA! se vc tiver ele disponivel, vale a pena usar sim.

fabim escreveu:Né zoeira não!
André, como eu nunca mexi com DMA, me perdoe se eu fui sarcástico ao contrário, ou direto, não entendi ainda porque acham que estou brincando.

Eu entendi o André dizendo que:
Se usar DMA, e demorar digamos 200mS para mover os dados. O núcleo fica 200mS parada sem fazer nada, o que teoricamente seria o mesmo tempo gasto pra transferir na unha através de código.

No meu caso, eu vou disparar a DMA, e continuar fazendo outras coisas.
Fiz um teste, e o núcleo não fica preso quando eu disparo a DMA, ela fica cuspindo dados sem parar e o núcleo livre pra fazer qualquer outra coisa.
Quando diz ocupa o barramento, que barramento disse ?

Desculpe novamente se estou com cara de burro, é que hoje é sexta e acordo as 5 pra vir trabalhar, e chego em casa depois das 20:30, ficando 4 horas por dia em busa!
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2882
Registrado em: 13 Out 2006 18:04

Re: LPC1768 DMA.

Mensagempor Silvio51 » 08 Ago 2015 02:59

O DMA é totalmente independente da CPU...se você habilitar a interrupção, apenas quando todo o bloco que você delimitou for transferido, aí sim a CPU pára e vai catar o que tu colocou lá...

Se você for transferir por exemplo um pacote com 2Kbytes (não sei se tua CPU suporta), a cada ciclo de clock um byte será transferido (ou word)...ou seja, o DMA tem a capacidade de transmitir um byte (ou word) por ciclo de clock...é claro que teu periférico que no caso é a UART não vai suportar, então neste caso o DMA transfere na velocidade em que o periférico está configurado através de um mecanismo de "arbitração"...

Exemplificando que precise-se executar uma transferência de 4kbytes para um periférico qualquer (como nossa antiga e arcaica UART) com velocidade de 1200baud/rate...supondo que a cada carcter transmitido a CPU seja interrompida: já viram o caos que seria?

Se pusermos estes 4Kbytes na ram do DMA e iniciarmos a transferência (sim podemos iniciar a transferência "manualmente" ou por alguma interrupção), o processador ficará livre pra executar outras tarefas enquanto o DMA se encarrega e transferir byte a byte nessa lentidão toda e só ao final de tudo (4K transferidos) será gerada a interrupção...nota-se que sem o DMA a cada dado seria uma nova int.

É claro que se a CPU tentar acessar a mesma áera de memória durante este processo haverá um overrun e será gerado um erro: Mas pergunto porque diabos alguém iria acessar esta área de memória? A "área" tá ocupada...vai usar teu tempo de sobra pra fazer alguma coisa...o DMA tá fazendo todo o trabalho sujo...usa teu tempo com coisas relevantes...

Quando utilizo o DMA a única "coisa" que geralmente coloco na iterrupção é o limpa na flag da int...e geralmente quando tô gerando PWM senoidal via tabela em RAM, apenas atualizo o DutyCycle e sáio do meio do caminho!!! O DMA é um troço que gostei pra caramba...tá difícil fazer um projeto sem utilizá-lo...tô viciado!!!
Silvio51
Byte
 
Mensagens: 378
Registrado em: 02 Nov 2006 14:04
Localização: Brasil

Re: LPC1768 DMA.

Mensagempor fabim » 10 Ago 2015 07:32

Marcelo, Silvio;
Muito obrigado, e sim, consegui entender melhor o uso do DMA.

Mas de qualquer forma, ainda não consegui visualizar o que o André disse, de que o uso do DMA ocupa " barramento do uP";

Como a arquitetura do ARM tem o AHB, creio que quando ele seta esta matriz para interligar os pontos, apenas este ponto de camada da matriz esta sendo usado, e existem outros livres;
Será que é isto que ele quis dizer?
Se fechou os pontos da AHB, entre A e B.
O processador continua livre pra fazer qualquer outra coisa, correto ?
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 4955
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Re: LPC1768 DMA.

Mensagempor andre_teprom » 10 Ago 2015 10:50

fabim,

Posso ter me equivocado; Ao menos na arquitetura que mexi, Z80, como disse mais acima, a CPU ficava travada, mas pode ter sido um caso especifico de como foi implementado lá, já que havia apenas um banco de memoria, mas enfim...tem tempo que não mexo com isso.
"Por maior que seja o buraco em que você se encontra, relaxe, porque ainda não há terra em cima."
Avatar do usuário
andre_teprom
Dword
 
Mensagens: 5265
Registrado em: 11 Out 2006 18:27
Localização: Brasil - RJ

Re: LPC1768 DMA.

Mensagempor msamsoniuk » 10 Ago 2015 13:46

andre_teprom escreveu:fabim,

Posso ter me equivocado; Ao menos na arquitetura que mexi, Z80, como disse mais acima, a CPU ficava travada, mas pode ter sido um caso especifico de como foi implementado lá, já que havia apenas um banco de memoria, mas enfim...tem tempo que não mexo com isso.


eh que o Z80 tinha um barramento unico para instrucoes e dados e nao tinha cache: quando vc arbitrava esse barramento para o DMA usar, o processador nao conseguia nem executar instrucoes e esperava. mesmo assim o overhead e latencia eram muito menores via DMA do que via rotina disparada por interrupcoes. no caso dos processadores modernos, a maioria dos mais simples possuem arquitetura de harvard, o que permite continuar buscando instrucoes na FLASH mesmo que o barramento de dados esteja indisponivel (sao barramentos diferentes), enquanto que os mais rebuscados possuem caches, tanto de leitura quanto escrita, e podem rodar varias instrucoes antes de efetivamente precisar acessar realmente o barramento. ou seja, eh igualmente eficiente em termos de overhead e latencia, porem com um impacto menor ainda no processador central.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2882
Registrado em: 13 Out 2006 18:04

Re: LPC1768 DMA.

Mensagempor fabim » 10 Ago 2015 15:55

A André, entendi agora;
Eu estava com uma baita dúvida, pois eu queria entender exatamente!
Tipo, se fica travado, como ele esta piscando o led!?!

Muito obrigado, e desculpe a insistência animal!

Sam, eu entendi!

Só para acrescer um pouco mais de informações;;

Eight channel General Purpose DMA controller (GPDMA) on the AHB multilayer
matrix that can be used with the SSP, I2S, UART, the Analog-to-Digital and
Digital-to-Analog converter peripherals, timer match signals, GPIO, and for
memory-to-memory transfers.
• Multilayer AHB matrix interconnect provides a separate bus for each AHB master.
AHB masters include the CPU, General Purpose DMA controller, Ethernet MAC, and
the USB interface. This interconnect provides communication with no arbitration
delays unless two masters attempt to access the same slave at the same time.
• Split APB bus allows for higher throughput with fewer stalls between the CPU and
DMA. A single level of write buffering allows the CPU to continue without waiting for
completion of APB writes if the APB was not already busy.

http://www.nxp.com/documents/user_manual/UM10360.pdf -> PAGINAS 9 e 12;

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

Próximo

Voltar para ARM

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 3 visitantes