memoria BOOT

Software e Hardware para linha ARM

Moderadores: 51, guest2003, Renie, gpenga

Mensagempor msamsoniuk » 27 Set 2010 13:41

nao tem segredo nao, basta fazer as contas!

se vc usar uma memoria FLASH com tempo de acesso de 60ns, por exemplo, e largura do bus igual a largura das instrucoes (32 bits no ARM e 16 bits no CF), vc vai ter um bandwidth para apenas 16 MIPS. mas um core ARM ou CF rodando a 167 MHz deveria conseguir atingir 167 MIPS, o que significa que temos uma diferenca de 10x.

bom, como nao tem milagre, a primeira vez que o core passar por determinado segmento de codigo ele nao tem o que fazer a nao ser inserir wait-states e rodar efetivamente a 16 MIPS. mas com isso ele aproveita e copia as instrucoes para a cache, assim na proxima vez que rodar este codigo, ele vai rodar a 167MIPS.

a primeira vista parece estranho pq a cache eh muito menor que a memoria! no caso do sistema CF tipico, temos 8KB de cache para algo da ordem de 4MB de FLASH e 8MB de SDRAM, uma diferenca de 1000x e isso indicaria que a probabilidade de acerto seria de 1 em 1000, certo? na verdade nao. para comeco de conversa, a cache nao mapeia simplesmente uma janela de 8KB. ela mapeia multiplas janelas de 16 bytes. isto significa que ela pode mapear 512 pequenas janelas independentes, que podem estar bem espalhadas pela memoria. junte isso ao fato da maioria do codigo ser orientada a pequenos loops e vc tem condicoes ideais para ter um elevado indice de acertos.

mas o negocio nao fica soh nisso, pq alem de instrucoes, vc pode cachear dados. neste caso vc tira vantagem nas escritas tambem, que podem ser do tipo write-back: o processador grava na cache e entao a cache transfere para a memoria externa mais lentamente. se vc gravar e ler em seguida, nao tem galho, pq vc vai ler da cache.

finalmente, a vantagem adicional de ter caches de instrucoes e dados separadas eh que vc consegue ter um core com arquitetura de harvard e o dobro do bandwidth, ou seja, acesso a dados na memoria nao impactam na performance.

bom, daih tem tambem os lados negativos. no caso do CF nao existe espaco para IO separado e as caches interferem no funcionamento de perifericos. eh facil de imaginar com um exemplo simples: vc entra em um loop lendo um flag de um periferico... porem na primeira leitura o flag acabou ficando cacheado! daih vc fica preso no loop. ah sim, e da mesma forma que isso falha com um periferico, pode falhar com uma variavel compartilhada entre duas threads.

para prevenir isso, existem dois descritores de pagina no CF, um para mapear a cache de instrucoes e outra para a cache de dados. com isso vc consegue separar areas para a atuacao de cada cache, de modo que nao mapeie a area de IO. e para resolver problemas de comunicacao interprocesso, eh comum usar a memoria SRAM interna para essa funcao. como ela opera com zero wait-states, nao eh necessario incluir ela na cache.

bom, essa eh a essencia do negocio :)

fabim escreveu:Samsonite.
Me explica uma coisa.
Eu ainda não tive oportunidade de mexer com nada além de 112mhz, que deu de sobra pro que eu necessitava.
Sendo assim, não tive a necessidade de pegar coisa barruda pra mexer, sendo assim não conheci a memoria cache na pratica.
Lendo seu post, à cima, eu vi que você disse que o cache aumenta o processamento por um fator de até 10X. Como assim ? eu tentei entender mais não consegui.
Pode me explicar esse negocio de cache, e velocidade de execução aumentada ?

beijunda
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor polesapart » 27 Set 2010 13:42

Eis aqui minha própria resposta hehehe: http://www.embeddedrelated.com/groups/l ... /48649.php
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor rcakto » 27 Set 2010 13:46

mask, blz vou ainda procurar alguem para projetar a minha placa e fazer orcamentos de fabricação tb... nao precisa ser nada profissonal, funcionando 100% ta otimo.. e a parte do manga eu tava de brincadeira, relax XD


polesapart,
com relação ao que realmente acontece na pratica, voce está completamente certo, e eu ainda lembro das nossas conversas.. mas estou dizendo com relação ao uC somente, em comparação aos da freescale aparenta que a maioria dos perifericos nao tem sobreposição, somente atrabalha os IOs e outra, se eu juntar o circuito que voce me passou para a saida VGA e um touch no estilho "mouse de notebook", acho que vai dar para usar um lcd simples para mostrar um sensor por vez, e no vga mostro tudo geral visto que tem maior espaco... mas acho que vai concumir memoria DEMAIS essa brincadeira, mas se eu comprar modulos de lcd posso deixar as pixels do lcd fora da memoria do LPC.. sao coisa a se analisar SOMENTE quando eu for por em pratica meu projeto... por agora so posso ter suposicoes, na real vou focalizar aprender... quem sabe no final do ano eu comeco a desenvolver meu projeto, que por coecidencia cai no mes que irei receber uma grana para comecar a montar meu laboratorio...osciloscopio, cnc, uma bancada decente para trabalho e por ai vai... sera bem simples.. somente o basico que preciso...
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

Mensagempor polesapart » 27 Set 2010 14:00

Marcelo Samsoniuk escreveu:nao tem segredo nao, basta fazer as contas!



No caso dos ARM, é dificil achar arm7tdmi (armv4t pra ser mais exato hehe) com cache, por diversas razões. Nos arm9 e demais tralhas voltadas para sistemas mais pesados (e geralmente sem compromissos realtime, ou com estes compromissos mais folgados), é o inverso: embora o cache seja um desenho opcional (um módulo verilog opcional hehe), é mais difícil achar sem cache.

No caso da família arm7tdmi da NXP, a memória flash não tem mágica, ela não consegue (nas primeiras famílias, não sei como tá agora) rodar a mais de 20mhz; Se a cpu roda a mais que isso, ela vai precisar aguardar 1 wait-states adicional pra cada 20mhz.

Como eles compensaram isso (vou falar de cabeça, posso errar algum detalhe menor):

A flash é operada em dois bancos paralelos, cada flash tem se lembro bem 64 bits, portanto cada leitura da flash puxa 128 bits, e existe um conjunto de pequenos buffers (um pra dados, um pra código sequencial, e um pra desvios). Estes buffers são pequenos mesmo, coisa de 128 bytes ou menos.

Quando o tal "módulo acelerador de memória" tá totalmente habilitado, estes buffers são usados e as leituras da flash são "cacheadas" neles. Quando o acesso (seja código, seja dados) é sequencial, a tralha chega a funcionar sem wait states para algo em torno de 3x o clock. No caso dos acessos randomicos a coisa varia um pouco, e existe um buffer de desvios pra minimizar o efeito dos saltos frequentes em loops).

Bom, mas aí tem jitter, certo? Certo. Mas é um jitter pequeno (só é relevante em trechos com interrupção desabilitada, por quê nos outros casos o jitter do mecanismo de irq do armv4 é bem maior e menos previsível), e caso não se deseje encará-lo, o tal módulo acelerador de memória tem um modo que "emula" os wait-states. Putz, mas qual seria a utilidade disso? Economizar energia, simplesmente. Especialmente com o set alternativo de instruções, o thumb, onde cada instrução tem 16 bits e o fetch da flash seria mais frequente.

Por que adotaram isso? Por que o perfil destes µCs é low-end mesmo: Imagine os integrados com 32k de flash, vc ia botar cache de verdade pra um trem desses? seria mais fácil aumentar a sram e copiar o código/dados da flash pra ram.

A sram inclusive, operam em 0ws em todo o range de frequencias suportado pelo integrado.

E no caso dos cortex-m3, a conversa é um pouco diferente hehe.
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor msamsoniuk » 27 Set 2010 17:15

mas daih estamos falando de coisas diferentes.

veja que todos os 68k/coldfires tem cache por default pq a partir do 68020 em 1982 o clock do core ficou maior que o clock das memorias externas por um fator de 3x. e de lah para cah o clock do core soh aumentou, enquanto o clock das memorias ficou quase na mesma. se vc for pensar em memoria FLASH paralela, mesmo hoje em as velocidades nao vai ser muito maiores que 16MHz, o que contrasta bastante com o clock de core tipico de 100 a 180MHz dos V2 e com os clocks maiores dos V3 e V4. os V4 de quebra tem o problema de serem superescalares e conseguirem executar ateh duas instrucoes por clock.

um dos maiores extremos que eu vi foi o blackfin, onde eu tenho clock de core de 600MHz para um clock da SDRAM de apenas 133MHz. mas isso fica pior ainda quando se pensa que as memorias FLASH estao operando com um clock de miseros 16MHz. eh tao lento que apenas o uboot roda direto da FLASH: na hora de rodar o uclinux, ele eh copiado inteiro para a SDRAM e assim a diferenca fica menor. daih gracas as caches on-chip, que nao sao nada pequenas no blackfin, consegue-se milagrosos 1200 MIPS! :)

mas no caso de microcontroladores single-chip, a coisa muda totalmente. primeiro que os clocks no core nao sao tao exagerados e segundo que as memorias internas sao muito boas. a vantagem de uma cache se torna menor. mas isso as torna caras e de pequena capacidade e tambem mais enrolado o projeto... do meu ponto de vista, particularmente acho mais simples partir do pressuposto que alguma cache ou fifo eh mandatoria. isto pq fica mais facil separar os barramentos de instrucoes e dados ateh as caches e entao unir eles apos as caches.

com isso vc tem um processador que usa arquitetura de harvard no core e arquitetura de von neumann fora do core. se for opcional, vc vai ter que obrigatoriamente projetar como von neumann e, portanto, a eficiencia do core vai ser menor e o nivel de complexidade muito maior.

polesapart escreveu:
Marcelo Samsoniuk escreveu:nao tem segredo nao, basta fazer as contas!


No caso dos ARM, é dificil achar arm7tdmi (armv4t pra ser mais exato hehe) com cache, por diversas razões. Nos arm9 e demais tralhas voltadas para sistemas mais pesados (e geralmente sem compromissos realtime, ou com estes compromissos mais folgados), é o inverso: embora o cache seja um desenho opcional (um módulo verilog opcional hehe), é mais difícil achar sem cache.

No caso da família arm7tdmi da NXP, a memória flash não tem mágica, ela não consegue (nas primeiras famílias, não sei como tá agora) rodar a mais de 20mhz; Se a cpu roda a mais que isso, ela vai precisar aguardar 1 wait-states adicional pra cada 20mhz.

Como eles compensaram isso (vou falar de cabeça, posso errar algum detalhe menor):

A flash é operada em dois bancos paralelos, cada flash tem se lembro bem 64 bits, portanto cada leitura da flash puxa 128 bits, e existe um conjunto de pequenos buffers (um pra dados, um pra código sequencial, e um pra desvios). Estes buffers são pequenos mesmo, coisa de 128 bytes ou menos.

Quando o tal "módulo acelerador de memória" tá totalmente habilitado, estes buffers são usados e as leituras da flash são "cacheadas" neles. Quando o acesso (seja código, seja dados) é sequencial, a tralha chega a funcionar sem wait states para algo em torno de 3x o clock. No caso dos acessos randomicos a coisa varia um pouco, e existe um buffer de desvios pra minimizar o efeito dos saltos frequentes em loops).

Bom, mas aí tem jitter, certo? Certo. Mas é um jitter pequeno (só é relevante em trechos com interrupção desabilitada, por quê nos outros casos o jitter do mecanismo de irq do armv4 é bem maior e menos previsível), e caso não se deseje encará-lo, o tal módulo acelerador de memória tem um modo que "emula" os wait-states. Putz, mas qual seria a utilidade disso? Economizar energia, simplesmente. Especialmente com o set alternativo de instruções, o thumb, onde cada instrução tem 16 bits e o fetch da flash seria mais frequente.

Por que adotaram isso? Por que o perfil destes µCs é low-end mesmo: Imagine os integrados com 32k de flash, vc ia botar cache de verdade pra um trem desses? seria mais fácil aumentar a sram e copiar o código/dados da flash pra ram.

A sram inclusive, operam em 0ws em todo o range de frequencias suportado pelo integrado.

E no caso dos cortex-m3, a conversa é um pouco diferente hehe.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor polesapart » 27 Set 2010 17:29

Marcelo Samsoniuk escreveu:mas no caso de microcontroladores single-chip, a coisa muda totalmente. primeiro que os clocks no core nao sao tao exagerados e segundo que as memorias internas sao muito boas. a vantagem de uma cache se torna menor. mas isso as torna caras e de pequena capacidade e tambem mais enrolado o projeto... do meu ponto de vista, particularmente acho mais simples partir do pressuposto que alguma cache ou fifo eh mandatoria. isto pq fica mais facil separar os barramentos de instrucoes e dados ateh as caches e entao unir eles apos as caches.

com isso vc tem um processador que usa arquitetura de harvard no core e arquitetura de von neumann fora do core. se for opcional, vc vai ter que obrigatoriamente projetar como von neumann e, portanto, a eficiencia do core vai ser menor e o nivel de complexidade muito maior.



Nos cortex-m3, que são harvard, mas encaixam na mesma classe de uso do arm7tdmi (clocks não exorbitantes e portanto relação de clock memória/core próxima), o que o povo tem usado é uma bus matrix, que pra mim é coisa do capeta. Ela opera naquele principio: qualquer bus master pode acessar qualquer bus slave a 0ws, desde que nao exista contenção. Usando bus slaves separados para flash & ram (alguns desenhos usam bancos separados de ram em bus slaves distintos, por exemplo pra permitir que a controladora dma descarregue numa área em que a cpu normalmente não faça uso intensivo). Mas é uma coisa necessariamente minimalista, a hora que você começa a espalhar inteconnects a torto e a direito, começa a ficar complexo o desenho do bus matrix e ficando + simples usar outras abordagens
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor polesapart » 27 Set 2010 18:46

rcackto, a meu ver, pro que vc quer fazer, não tem como fugir de não usar "muita" memória. É bom até planejar com sobra, vc pode precisar implementar um "doublebuffer" ou coisas malucas do gênero :P
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor rcakto » 27 Set 2010 20:09

rapaz.. faz eu pira a cabeca logo cedo não... eu nem faco ideia do que é uma implementação de buffer que de tempo em tempo falam, quanto mais um doublebuffer que voce esta falando.... ate o momento buffer e usado automaticamente pelo uC e voce so ativa e desativa, fora isso sao aplicações externas, mas assim mesmo voce nao tem muito o que fazer, é muito automatico até aonde me falaram....
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

Mensagempor msamsoniuk » 27 Set 2010 22:34

eh para sistemas *simples* de video vc vai ter um buffer na memoria. por exemplo, suponha que vc tenha 8MB de SDRAM e esteja trabalhando com 640x480 pixels em 16 bits de cor. entao nessa memoria de 8MB vc vai criar um buffer de 614400 bytes, que corresponde aos 307200 pixels de 16 bits da tela, e o canal de DMA do controlador de LCD vai continuamente puxar esse buffer e copiar para o video com uma cadencia de 60 buffers/s.

porem, uma coisa que vai acontecer eh que se vc for fazer animacoes vc vai precisar apagar a tela e redesenhar, porem isso vai fazer a tela flickar. para eliminar isso, utiliza-se a tecnica de double-buffer, onde vc usa dois buffers alternados: um para desenhar, outro para exibir. depois que o buffer esta com o desenho pronto, vc alterna e entao parece que o desenho surge de forma fluida, sem que vc perceba o processo de apagamento e redesenho.

rcakto escreveu:rapaz.. faz eu pira a cabeca logo cedo não... eu nem faco ideia do que é uma implementação de buffer que de tempo em tempo falam, quanto mais um doublebuffer que voce esta falando.... ate o momento buffer e usado automaticamente pelo uC e voce so ativa e desativa, fora isso sao aplicações externas, mas assim mesmo voce nao tem muito o que fazer, é muito automatico até aonde me falaram....
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor rcakto » 27 Set 2010 23:05

Marcelo, adiantando um pouco os estudos... o buffer, os dados sao enviados para o buffer sozinho ou voce tem que direcionar cada bit?? ex.: bitX vai para enderecoX da memoria e por ai vai....
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

Mensagempor msamsoniuk » 27 Set 2010 23:28

um buffer na memoria eh soh um buffer na memoria. se vc configurou o controlador de LCD para puxar via DMA um buffer no endereco 0x40000000 para aquele exemplo de 640x480 e 16 bits de cor, entao cada pixel vai ter 16 bits e vc pode acessar diretamente em C:

Código: Selecionar todos
unsigned short *buffer = (unsigned short *)0x40000000;

void set_pixel(unsigned short x, unsigned short y, unsigned short color)
{
  buffer[y*640+x] = color;
}


obviamente isso pode ser melhor otimizado se vc fizer uma cache com os offsets das 480 linhas e eliminar a multiplicacao, algo como:

Código: Selecionar todos
unsigned short *line[480];

void line_init()
{
  int i;
  for(i=0;i!=480;i++)
  {
    line[i] = 0x40000000 + i*640;
  }
}

void set_pixel(unsigned short x, unsigned short y, unsigned short color)
{
  unsigned short *buffer = line[y];
  buffer[x] = color;
}


mas obviamente isso tudo jah esta pronto no uclinux se vc usar ele.

rcakto escreveu:Marcelo, adiantando um pouco os estudos... o buffer, os dados sao enviados para o buffer sozinho ou voce tem que direcionar cada bit?? ex.: bitX vai para enderecoX da memoria e por ai vai....
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor rcakto » 27 Set 2010 23:40

marcelo, eu tava querendo saber mais sobre o uclinux, sabe me informar onde posso aprender desde o basico sobre ele, em portugues se possivel, to com preguica de traduzir.... XD
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

Mensagempor polesapart » 27 Set 2010 23:45

O framebuffer é uma área de memória que geralmente é contínua, ela começa num endereço x, que aponta pro primeiro pixel na coluna zero e linha zero, e vai crescendo. Ok, mas na tela, qual é canto que representa isso? Depende. começa a ficar divertido por aí hehhee. Mas imaginemos que seja o canto superior esquerdo.
Agora imaginemos que você precisa de 8 bits pra cada cor primária (R, G, B) que compõe um pixel. Portanto, cada byte representa uma cor, e você precisa de três bytes para representar um pixel. Imagine que na memória estes bytes estejam nesta ordem: RGB.

Então, pra endereçar o byte "R" correspondendo ao pixel de numero "N", você multiplica por três. Pra acessar a cor "G" você soma um, e B, dois. Simples (?) aritmética de ponteiros.

O framebuffer costuma espelhar o formato de imagem na tela, então se você tiver 320 pixels de largura (o que equivale a dizer que você tem 320 colunas), o ponteiro base * 320 (que aponta pro 321º conjunto, lembre que na nomenclatura mais comum, endereços iniciam em zero :P), você está apontando pro primeiro pixel da segunda linha, etc.

Bom, começa a ficar complicado quando os teus conjuntos RGB não são múltiplos de 1 byte, pq aí é necessário calcular deslocamentos de bit. Tem os modos onde certo número de bits são índices em uma paleta de cores, e por aí vai.

O controlador gráfico pra painéis TFT costuma ser relativamente flexível no sentido de que ele as vezes te permite usar uma profundidade de cor no framebuffer e outra na tela, mas os pormenores variam muito de um para outro.

Em cima dessa salada toda, uma biblioteca gráfica precisa desenhar elementos geométricos (pontos, linhas, circulos) e fazer o preenchimento dos mesmos, fora outras coisinhas legais que começam a complicar (o que, achou que eu já tinha complicado tudo?), como transparência, manipulação de pixmaps, e outras coisinhas malucas :D E isso tudo pra duas dimensões, imagina pra 3? Não, não imagina não, senão vc vai ter pesadelos hehehe

Por essas e outras que é complicado bolar um projeto do zero :P

Bom, isto aí é o framebuffer, e foi o conceito que o Marcelo tentou passar, eu só joguei em outras palavras.

Agora imagina que o hardware gráfico tá o tempo todo lendo esta área de memória e mostrando na tela. Se você começa a desenhar nesta memória, o hardware vai começar a mostrar desenhos incompletos, por que ele vai capturar a memória enquanto vc (a biblioteca gráfica) está desenhando nela. Por isso se usa o doublebuffer, você desenha num buffer, e diz pro hardware gráfico mostrá-lo. Ai quando vc precisa alterar algo, vc desenha no segundo buffer, e diz pro hardware passar a mostrar o segundo, o que te libera o primeiro. Aí vc volta a desenhar no primeiro, e assim sucessivamente. Com isto vc (a biblioteca gráfica) tem controle sobre quando mostrar uma nova imagem, completa, e isto evita o flicker, que seriam os efeitos colaterais (bizarros!) de ter desenhos incompletos aparecendo na tela num ritmo bem rápido.
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor polesapart » 27 Set 2010 23:46

E o Marcelo postou algo + simples enquanto eu digitava o meu livro hahaha :P
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor rcakto » 28 Set 2010 00:07

ta... blz... agora entendi... ?????????????? f****.... olha a pergunta que passou na minha cabeca.. se eu estou trabalhando em gerar os pixels no LCD, como é que eu vou fazer para receber os dados das I2Cs, I/Os, e ADCs, tudo em tempo real igual no pc, onde da pra deixar uma porrada de coisa aberta e vai alterando os dados tudo sozinho ( winamp, msn, firefox....tudo aberto...).....
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

AnteriorPróximo

Voltar para ARM

Quem está online

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

x