memoria BOOT

[Djalma Toledo Rodrigues]

so uma pergunta que até hj eu nao sei a resposta... o codigo para
memorias são feitos em linguagem especial, uso de um programa especial ou simplesmente
programe como sempre e coloca a porcaria do .HEX dentro dela??

O Programa Objeto, o que o µC, ou o µP, executa é em Binário

Linguagem de Máquina .

DJ

[mastk]

rcakto, vc pode fazer um sistema modular, como fiz. Ou simplesmente deixar um slot, para vc colocar o codigo ja gravado:



A linguagem especial? Nao, no maximo, vai precissar de um ferramenta para gravar o pente de memoria que vai no slot, na situacao a cima, fiz um programa software no pc e uma placa para grava-las. Ou seja, pegava o HEX, que no meu caso era um S19, e enviava para o gravador e pronto, soh testar.

Bem, acho que vale lembrar que os ARMs da NXP podem ser gravador pela serial, dispensando ferramentas de debug, para um contato inicial.

Essa placa funciona e grava de boa o LPC2138.

[rcakto]

djalma, eu sei que ele trabalha com binario, mas eu to falando do codigo em si.. o flash magic tool por exemplo, ele pega o .HEX transforma em binario e coloca dentro do chip... até agora, eu acho que para memoria deve ser a mesma coisa... so queria ter certeza.. pq ja achei projetos para trabalhar com atmega8 onde falam para colocar o codigo .hex na cache e tem um arquivo com extenção diferente para ser gravado na memoria interna... e como a explicação usava de um compilador para linux, eu nao faco ideia do que eles estavam falando para fazer direito....

[msamsoniuk]

depende da arquitetura. eu nao posso falar muito sobre o ARM pq nao conheco a fundo, mas me parece muito similar e deve ser a mesma coisa.

em termos de organizacao, o coldfire parece muito com um PC, onde memoria ROM e RAM podem estar em qq posicao arbitraria dentro de um espaco de 4GB. mas diferente de um PC, nao existe espaco separado para IO e todo o IO tem que estar dentro deste mesmo espaco de 4GB.

no caso do reference design do MCF52277, usaram a seguinte divisao:

- 0x00000000 a 0x01000000: 16MB de memoria FLASH paralela externa
- 0x40000000 a 0x44000000: 64MB de memoria SDRAM externa
- 0x80000000 a 0x8FFFFFFF: 256MB reservado para memoria interna (128KB de SRAM estao disponiveis)
- 0xF0000000 a 0xFFFFFFFF: 256MB reservado para IO

note que para o coldfire eh indiferente a memoria ser interna ou externa. e alem disso existem as caches on-chip, mas sao transparentes, ou seja, vc ativa e ela vai acelerar a execucao por um fator de ateh 10x, sem que no entanto vc tenha que fazer algo alem de ativar no lugar correto... tem que tomar cuidado: vc nao pode cachear os espacos de IO, senao tudo para de funcionar! :)

alem disso, existe uma serie de chip-selects com enderecos base programaveis, que podem estar em qq espaco nao utilizado e podem ativar qq tipo de dispositivo de memoria (FLASH ou SRAM) ou IO.

do ponto de vista de codigo, tipicamente compila-se o codigo usando enderecamento absoluto, o que significa que durante a compilacao eh utilizado um linker script e este contem o mapa conectando variaveis aos respectivos enderecos. normalmente eh necessario indicar ao compilador o endereco onde ira ficar os blocos de codigo, dados, stack e IO.

note que a unica diferenca entre rodar o codigo em FLASH ou SDRAM/SRAM eh apenas a necessidade de se carregar o codigo de algum lugar, o que nao eh necessario na FLASH.

no caso especifico do uboot e uclinux, por exemplo, o uboot eh compilado para rodar no endereco absoluto 0x00000000, portanto roda direto da FLASH paralela. o uboot consome algo em torno de 128 a 256KB e eh comum se seguir a ele uma area de FLASH com filesystem, q eh vista como um disco e tem capacidade RW. seguindo isso, vem a imagem compactada do uclinux.

normalmente a imagem compactada do uclinux divide-se por sua vez em dois blocos, um com o kernel e outro com um filesystem sem capacidade RW. outra variacao eh colocar essa imagem com o kernel e filesystem em um cartao MMC. isso indifere, pois a imagem eh copiada na SDRAM, o que significa que o kernel esta compilado para o endereco absoluto 0x40000000. as imagens costumam ter entre 3 e 8MB e isso varia conforme a quantidade de tralhas que vc coloca dentro.

daih vem as aplicacoes que estao no filesystem. normalmente eles nao sao compilados em nenhum endereco especifico. ao inves disso usam enderecamento relativo ou linkagem dinamica, o que significa que o uclinux eh quem vai linkar em tempo de execucao o codigo para o endereco onde ele vai ser executado. note que o uboot e kernel do uclinux sao binarios linkados, enquanto os aplicativos q vao no filesystem sao binarios nao-linkados, normalmente em formato elf.

bom, isso eh como a coisa funciona. do ponte de vista de aplicacao, na pratica, vc vai ver tudo mais ou menos como se estivesse em um PC, sendo que a FLASH sera tratada mais ou menos como se fosse um HD. no caso do boot via SPI, imagino que o coldfire tenha que copiar um bloco inicial para a SRAM interna para comecar a rodar, mas isso eh um processo meio automatico.

so uma pergunta que até hj eu nao sei a resposta... o codigo para memorias são feitos em linguagem especial, uso de um programa especial ou simplesmente programe como sempre e coloca a porcaria do .HEX dentro dela??

[rcakto]

mask o que é exatamente esse seu projeto, seu viciado em manga???

é uma placa verdinha dessa que eu quero fazer, mas nela vai o LPC2478 com seus componentes basicos para funcionamento ( cristal 20MHz, capacitores resistores e afins...), fonte DC-DC 5V para 3,3V para alimentar o lpc, a bateria, o gravador via serial, um conjunto de dip switch para conectar e desconectar a serial que sera de uso exclusivo para gravar, e todos os pinos que possam ser usados no projeto..

quanto deve sair esse brinquedo para alguem projetar??? espero que não saia caro.....

[rcakto]

Marcelo, eu dei uma olha BEM superficial no coldfire e achei MUITO complicado ele... eu vou ficar no LPC por enquanto.. entender melhor o que é exatamente ARM na pratica e daqui uns 2 meses vo procurar algum livro sobre microcontroladores arm da freescale.. fiquei boiando na parte de memoria L, D e afins mas realmente parecem ser melhores que a NXP estruturalmente falando...mas os desenhos da nxp mostra melhor as conecções internas...

outra coisa o codigo que eu tinha mensionado sobre o atmega8 tinha essa extenção .ELF

[msamsoniuk]

vc tem que aprender a usar um processador de verdade! :)

duas sugestoes de leitura:

http://www.hanssummers.com/computers/z80/index.htm
http://www.users.cloud9.net/~stark/hardw68k.htm

descrevem computadores classicos quase completos, ou seja, sao feitos com processadores que usam memorias externas e possuem muitos perifericos externos. o coldfire, em particular, eh a evolucao do antigo 68000. eles foram adicionando mais e mais perifericos dentro dele, mas ele continua hoje mais parecido com um computador como o PC, enquanto os ARMs sao mais parecidos com microcontroladores onde tudo esta integrado, como eh um PIC ou AVR tipico.

uma dica para as coisas parecerem mais simples eh justamente estudar processadores mais complexos. isso vai ajudar a entender melhor como funcionam os processadores menos complexos e vc vai perceber que eles vao parecer bem mais simples do que parecem hoje.

djalma, eu sei que ele trabalha com binario, mas eu to falando do codigo em si.. o flash magic tool por exemplo, ele pega o .HEX transforma em binario e coloca dentro do chip... até agora, eu acho que para memoria deve ser a mesma coisa... so queria ter certeza.. pq ja achei projetos para trabalhar com atmega8 onde falam para colocar o codigo .hex na cache e tem um arquivo com extenção diferente para ser gravado na memoria interna... e como a explicação usava de um compilador para linux, eu nao faco ideia do que eles estavam falando para fazer direito....

[rcakto]

Marcelo, eu ja tentei aprender a programar um Z80 para fazer um mini PC, me amarro nesses homemades...mas da não.. é MUITA complicação para a minha cabeca... dexa eu comecar a minha faculdade de engenharia eletrica ano que vem que algum ano qualquer ae eu comeco a ir para outros horizontes do mundo eletronico...

[Djalma Toledo Rodrigues]

Arquivo .hex formato Intel :


RECLEN com 1 byte, usado para informar o tamanho do campo DATA;
ADDRESS com 4 bytes, usado para endereçar a posição de memória;
RECTYPE com 1 byte, usado para identificar o tipo do registro;
DATA com tamanho variável, normalmente 16 bytes, sendo informado no campo RECLEN;
CHKSUM 1 byte, usado para verificar a integridade dos dados.

O campo RECTYPE pode conter um dos seguintes valores:

’00’ para registro de dados;
’01’ para fim do arquivo;
’02’ para registro de endereço com segmento extendido
’03’ para início do registro de segmento extendido
’04’ para registro de endereço linear extendido
’05’ para início do registro linear extenddo

Resumindo: Cada linha possui normalmente 16 Bytes do Programa a serem extraidos
pelo Gravador do Dispositivo.

Pode abri-lo, examinar, e até editar desde que respeite o formato, no Bloco de Notas
do Windows ou outro editor de texto qualquer que não tenha formatação .

DJ

[fabim]

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

[Djalma Toledo Rodrigues]

E é essa a finalidade única do Cache, aumentar a velocidade.

E aumenta a velocidade por estar interna, no barramento interno do µP

----------------------------------
O HD também possui Cache

Cache de disco

O cache de disco é uma pequena quantidade de memória incluída na placa lógica do HD. Tem como principal função armazenar as últimas trilhas lidas pelo HD. Esse tipo de cache evita que a cabeça de leitura e gravação passe várias vezes pela mesma trilha, pois como os dados estão no cache, a placa lógica pode processar a verificação de integridade a partir dali, acelerando o desempenho do HD, já que o mesmo só requisita a leitura do próximo setor assim que o último setor lido seja verificado.

Fonte: wikipedia.

DJ

[polesapart]

eu so fico triste em usar memoria externa pq ela SEMPRE esta eliminando os pinos de todos os perifericos essenciais como o LCD, USB do LPC2478... os 3 compartilham de pinos entre si.. a memoria acaba com quase tudo, o LCD 24bits TFT acaba com a memoria e o USB OTG e por ai vai.... acho que os fabricantes NUNCA irao dar acesso a tudo sem perder nada...

Não sei o que é mais cômico: vc bater o olho num desenho e interpretá-lo desta forma, ou o marcelo indo na tua

Nem a NXP conseguiria fazer uma cagada dessas! Bom, a intel conseguiu com a primeira família dos PXA, mas isto é outra história

Rcakto, vai com calma tá? Procura um reference design do 2478 e vc vai ver que a coisa não é tão caótica quanto vc tá pensando. Bom, na verdade, ela é muito mais, mas não neste ponto

[rcakto]

polesapart, da uma olhada no datasheet do LPC2478 na pagina 66, la esta os pinos do LCD TFT 24 bit e quais os pinos do lpc que deverao ser usados...
tambem repare nas notas no final da tabela, até as interrupções EINT1 2 3 perderam pinos ( não procurei saber se eram todos)....

[mastk]

mask o que é exatamente esse seu projeto, seu viciado em manga???

é uma placa verdinha dessa que eu quero fazer, mas nela vai o LPC2478 com seus componentes basicos para funcionamento ( cristal 20MHz, capacitores resistores e afins...), fonte DC-DC 5V para 3,3V para alimentar o lpc, a bateria, o gravador via serial, um conjunto de dip switch para conectar e desconectar a serial que sera de uso exclusivo para gravar, e todos os pinos que possam ser usados no projeto..

quanto deve sair esse brinquedo para alguem projetar??? espero que não saia caro.....

Esse eh o sistema que roda o pong.

O adaptador, comprei n a mosaico, mas se for algo com muito pinos, ou vc faz em casa ou manda fazer em uma empressa, para o coldfire que estou trabalhando, mandei fazer o custo beneficio, foi bem interresante.

Nana é legal, pow.

[polesapart]

polesapart, da uma olhada no datasheet do LPC2478 na pagina 66, la esta os pinos do LCD TFT 24 bit e quais os pinos do lpc que deverao ser usados...
tambem repare nas notas no final da tabela, até as interrupções EINT1 2 3 perderam pinos ( não procurei saber se eram todos)....

Bom, as vezes eu me sinto falando pras paredes hehehe. O que eu quis dizer é que é preciso ser prático, recorde de conversas que já tivemos.

Lembra que já comentamos que a maioria dos displays são de no máximo 18 bits, e que tem controladores que nem suportam mais que isso? Então: o 2478 está dando a opção de usar 24 bits, ao custo de alguns periféricos. Pra quem *realmente* precisa de 24 bits *e* quer usar o 2478, o caminho é esse, ponto final. Mas me acredite, você não quer um lcd de 24 bits e você não precisa de um. E por consequencia, não perde a USB ou outro periférico útil!

Por quê você não quer? Só por isso:

• Bem mais caro;
• Difícil de achar;
• Não é garantido que a profundidade de cores do hardware corresponda a da interface (ou seja, vc pode comprar gato por lebre).
• Você precisará de mais memória de aplicação e de framebuffer.
• Mais linhas para rotear
• etc.

Se você realmente quer um lcd de 24 bits, e vai usar isto com uma boa resolução, boa sorte achando um µC e um painel lcd que ambos suportem estes requisitos e que caibam no teu bolso... tá mais fácil achar LCDs de 16 bits, e num desse fica a teu critério escolher se trabalha a 15 ou 16 bits.

Em tempo: eu posso estar enganado, mas creio que os pinos da usb otg estejam expostos em mais de um conjunto de pinos, pois brinquei com um kit com lcd usando um 2478, e nele você espetava um pendrive com arquivos pdf, e na tela (lcd com touchscreen) voce visualizava os arquivos. Como só tinha o 2478 de µC, presumo que estavam usando a própria interface OTG (ou host dedicado) do mesmo. Dá uma conferida.