USO RAM EXTERNA ARM9

[fabim]

Pessoal, estou naquela fase de alucinado, aprendendo tudo que puder sobre arquitetura etc.
Estive olhando e procurando algo sobre usar DRAM SRAM, no arm 9, no barramento externo, e não achei nada consistente acerca de funcionamento pratico, e aplicações.

Alguem conhece algum endereço de site, que contenha exemplos, explicações, e afins ?

Abraços

[tcpipchip]

Voce quer SRAM ou DRAM ?

ARM7 normalmente usa SRAM e ARM9 usa DRAM.

Dificil achar SRAM nos ARM9...seria um desperdicio de GPIOS

[MarcusPonce]

Fabim,
Se no site do fabricante do ARM9 que você está estudando não tem exemplos, você pode procurar sites de fabricantes de kits de desenvolvimento, pois alguns tem o esquema liberado.
Exemplo: www.olimex.com

[tcpipchip]

Outra opção é dar uma lida nos DATASHEETS das SDRAM, por exemplo, da MICREL.

[fabim]

hehe, acho que fui muito fraco na minha colocação.

Por exemplo.
Dram Sram.
O ARM rodar um programa por uma ram externa ?
Como pode isto ? como o barramento da CPU vai enxergar a ram lá fora, e executar um programa lá dentro ?

Como exemplo de duvida!!

Na DRAM interna no 2148 ja peguei as manhas entendi e tal´s..

Em uma RAM externa, imagino eu que o sistema seria a mesma mercadoria.
Pego um SDcard por exemplo, puxo o HEX para o endereço X da ram.
E o software gravado no arm, executa o programa, rotinas etc, para aquele dado endereço ou endereços.
O qual(is), eu crio a montagem do hex, condifurando os ditos endereços no keil por exemplo.
Agora, externo?
é SPI ? paralelo ? como isso funciona ?

Abraços

[tcpipchip]

--------------------------------------------------------------------------------
hehe, acho que fui muito fraco na minha colocação.
Por exemplo.
Dram Sram.
O ARM rodar um programa por uma ram externa ?

SIM, TANTO NUMA SRAM COM SDRAM

Como pode isto ? como o barramento da CPU vai enxergar a ram lá fora, e executar um programa lá dentro ?

É LINEAR, JOGA NA SRAM ou SDRAM via PONTEIROS (C) E CRIE UMA FUNÇÂO QUE APONTE PARA ESTA MEMORIA E PRONTO...

Como exemplo de duvida!!

Na DRAM interna no 2148 ja peguei as manhas entendi e tal´s..

CERTO

Em uma RAM externa, imagino eu que o sistema seria a mesma mercadoria.

SIM, MAS TENHO DUVIDA QUANTO A SÉRIE LPC21XX, MAS LPC22XX VAI BEM

Pego um SDcard por exemplo, puxo o HEX para o endereço X da ram.
E o software gravado no arm, executa o programa, rotinas etc, para aquele dado endereço ou endereços.
O qual(is), eu crio a montagem do hex, condifurando os ditos endereços no keil por exemplo.

ASSIM FUNCIONA PARA O UCLINUX E LINUX!

Agora, externo?

é SPI ? paralelo ? como isso funciona ?

SRAM (PARALELO), SDRAM (SERIAL E PARALELO - HIBRIDO)

Abraços

[fabim]

outro dia, uma amigo aqui do forum me ADD e pediu ajuda about bootloader.
Só que o bootloader do cabra ocupava o inicio da flash, e ia até endereço 800.
Ele criou o programa etc, e quando fazia o boot o programa se perdia etc.
Claro, o compilador montou o hex, com label´s chamadas e etc, iniciando do endereço inicial, ou seja 0.
O que ocorria era que, o boot começava a gravar do endereço 801, em diante, e logicamente o programa se perdia, pois a chamada de endereços caia lá no setor do bootloader.

Com um simples>:
#pragma ORGAL 0x0801.
A ide, começou a montar o software apartir deste ponto em diante, e funcionou redondinho.
Isso é o basico..
O mesmo se dá, a um programa que eu crio, eu tenho que definir para o compilador, qual é o endereço inicial que o hex vai ser montado..

Se eu tiver por exemplo 3 programas distintos a ser executado na SDRAM de fora, eu tenho que gerar 3 projetos, definindo cada um para endereço inicial para aquele endereço de ram lá fora.

O startup do ARM seja qual for, pega na serial flash o programa 1 por exemplo que ocupa 16Kbytes, joga na ram de fora, no endereço ao qual foi criado o projeto para esse programa iniciar 0x00000100, aloca os 0x3E80 bytes.

Agora o bixo pega.
Dentro do arm que tenha hw dedicado a SDRAM ou DRAM que seja, existe registradores os quais eu configuro os endereços iniciais de execução etc?

E como é isto ?

Abraços

[Djalma Toledo Rodrigues]

Código: Selecionar todos

Memories The AT91F40816 embeds 8K bytes of internal SRAM. The internal memory is directly
connected to the 32-bit data bus and is single-cycle accessible.
The AT91F40816 features an External Bus Interface (EBI), which enables connection of
external memories and application-specific peripherals. The EBI supports 8- or 16-bit
devices and can use two 8-bit devices to emulate a single 16-bit device. The EBI implements
the early read protocol, enabling faster memory accesses than standard memory
interfaces.
The AT91F40816 embeds a Flash memory organized as 1M 16-bit words, accessed via
the EBI. Its main function is as a program memory. A 16-bit Thumb instruction can be
loaded from Flash memory in a single access. Separate MCU and Flash memory Reset
inputs (NRST and NRSTF) are provided for maximum flexibility. The user is thus free to
conform the reset operation to the application.
The AT91F40816 integrates resident boot software called AT91 Flash Uploader software.
The AT91 Flash Uploader software is able to upload program application software
into its Flash memory.
Peripherals The AT91F40816 integrates several peripherals, which are classified as system or user
peripherals. All on-chip peripherals are 32-bit accessible by the AMBA Bridge, and can
be programmed with a minimum number of instructions. The peripheral register set iscomposed of control, mode, data, status and enable/disable/status registers.
An on-chip Peripheral Data Controller (PDC) transfers data between the on-chip
USARTs and on- and off-chip memories address space without processor intervention.
Most importantly, the PDC removes the processor interrupt handling overhead, making
it possible to transfer up to 64K continuous bytes without reprogramming the start
address, thus increasing the performance of the microcontroller, and reducing the power
consumption.
System Peripherals The External Bus Interface (EBI) controls the external memory or peripheral devices via
an 8- or 16-bit databus and is programmed through the APB. Each chip-select line has
its own programming register.

Aqui tem Block Diagram Fig. 2 Pág 5

http://www.datasheetcatalog.com/datashe ... 0816.shtml

Ver: Block EBL - External Buss Controller



Ou seja, Barramento Dados / Endereços
8080 já conhecia

DJ

[Rodrigo_P_A]

ARM7 com SDRAM é o 2478

eu já rodei programas na minha placa LPC2478, fiz um bootloader que carrega o arquivo HEX gerado.

o arquivo é gravado em um cartão SDCARD, eu carrego o programa na SDRAM externa e executo tudo na SDRAM externa.

Uma maravilha, tenho 64MB que posso dividir por exemplo 32MB para programa e 32MB para dados ou 1MB para programa e 63MB para dados, etgc....

fica muito flexivel o sistema.

como o TCPIP disse, basta criar o programa e depois configurar os ponteiros, remapear os vetores para a RAM Externa, etc...

fica muito legal.

[Sergio38br]

Fabim procura na ARM os Prime Cell sobre SDRAM

[ ]'s
Sergio

[MarcusPonce]

Fabim, vejo que você tem algumas dúvidas distintas, vou dar algumas idéias para ajudar. Só a idéia básica, sem falar das otimizações.

1) Os ARMs só tem 1 espaço de endereçamento. _Não_é_ como o 8051 que tem 0x0000 a 0xFFFF de programa e 0x0000 a 0xFFFF de dados. Normalmente os ARMs tem um circuito decodificador de endereços que em um intervalo ativa uma FLASH, em outro intervalo ativa um periférico, em outro ativa a SDRAM, em outro a ROM do boot, etc. (normalmente dá para reconfigurar alguns parâmetros deste decodificador)

2) Os Arms só executam instruções que estão neste endereçamento, seja na RAM ou SDRAM ou FLASH. Veja que em um SD card, uma eeprom serial, um HDD, etc. que não dá para ver o conteúdo inteiro diretamente neste espaço de endereçamento então não dá para rodar programa que está lá dentro. Ou seja, para rodar programa de um SD card você tem que executar uma função para ler e transferir para memória primeiro e rodar lá.
OBS: algumas memórias com acesso sequencial podem ser lidas diretamente pelo hardware de alguns ARMs, sem precisar de função específica, portanto o programa pode rodar diretamente de lá. Desde que o hardware consiga ler o conteúdo sozinho então dá para rodar o programa direto de dentro do componente.

3) Sobre o compilador: colocar 3 programas independentes no ARM7 sem sistema operacional dá trabalho... tem que definir endereços diferentes na hora de compilar, controlar o espaço para variáveis, etc. Depois você tem que dar um jump. Em C você vai pular para uma função que o endereço inicial é dado por um ponteiro

No ARM9 rodando LINUX é muito mais fácil , pois os programas rodam dentro de um espaço de memória virtual controlado pelo Linux, vários ao mesmo tempo. Portanto, cada programa pode ver um valor no endereço na memória virtual 0x10000 (exemplo...) mas para cada programa rodando simultaneamente o valor no endereço parece ser diferente. Isso acontece pois cada 0x10000 na memória virtual que um programa acessa corresponde a um endereço diferente na memória real (física). O Linix comtrola automaticamente. No PC é a mesma coisa.
Portanto, o compilador que monta os executáveis para Linux-ARM não precisa se preocupar se tem outro programa com o mesmo endereço ou com um tamanho grande que um cairia por cima do outro etc...

[MarcusPonce]

Exemplo (Keil ARM7) de como dar jump para uma posição de memória, sem passar parâmetro e sem pegar retorno:

int main (void)
{
((void (*)(void))0x12300)();
}

Exemplo passando parâmetro:

int main (void)
{
((void (*)(int))0x12300)(0x55);
}

[Jozias del Rios]

ou então vc faz uma relocation table...

tem que alterar o compilador ou criar macro se vc programa em ASM. Eu fazia isso com meu sistema operacional para x86...

basicamente, todo jump/call ou referencia a dados que exista e dependa do endereço-base para onde foi copiado o seu programa, cria uma entrada de 16bits numa tabela de "relocações".

Quando o programa vai ser iniciado, uma rotina soma o endereço base do programa ao endereço indicado por cada entrada nessa tabela.

Assim vc pode fazer multiplos (e até identicos) programas estarem na RAM ao mesmo tempo, sem precisar de memória virtual (MMU) que um ARM7 ou um CM3 não tem.

Talvez os compiladores GCC sejam capazes de gerar objeto que tenham isso, já que isso é usado em .EXE para DOS, se eu não me engano.

[msamsoniuk]

vc pode compilar com opcao de codigo independente de posicao, o que no gcc costuma ser a opcao -fpic. no caso do 68k, o codigo eh inteiro gerado com enderecamento relativo ao PC, ou seja, qq jmp ou branch passa a ser relativo ao PC, bem como os acessos a dados, de modo que os segmentos text e data ficam unidos e podem ser movidos para qq ponto da memoria. a stack por natureza jah eh independente de posicao, relativa aos registros A6 e A7 no 68k.

quer dizer, vc simplesmente pega o binario e move para qq lugar do espaco de enderecamento, seta a stack inicial e manda um jmp para o start dele, que ele se vira. o problema de fazer dois modulos destes conversarem tem que ser resolvido com ponteiros de funcoes em espaco de endereco absoluto ou com comunicacao interprocesso disparando uma trap.

uma extensao dessa ideia permite quebrar os segmentos text e data em blocos diferentes de memoria, ficando o segmento text relativo ao PC e o segmento data relativo ao registro A5 do 68k, porem se nao me falha a memoria isso eh um patch nao oficial para o gcc criado pelo pessoal do uclinux.

fora isso, comeca a complicar o caminho: a solucao tradicional para codigo e dados que se espalham por mapas diferentes de memoria costuma levar a escrita de um link script q descreve o layout de memoria e o q fica no que... e normalmente nao eh trivial! e vc ainda tem q suprir o codigo que move os blocos para os lugares certos. a outra solucao eh gerar o objeto e linkar dinamicamente na memoria, conforme a posicao, mas menos trivial ainda, pq vc tem q construir um linker dinamico, alem do codigo que move as coisas para os lugares certos.

a cacetada do linker dinamico eh que o compilador gera todos os branches, jumps e ponteiros imediatos com o valor zero, colocando essa posicao em uma tabela que vc tem q varrer para alterar o codigo na memoria...

ou então vc faz uma relocation table...

tem que alterar o compilador ou criar macro se vc programa em ASM. Eu fazia isso com meu sistema operacional para x86...

basicamente, todo jump/call ou referencia a dados que exista e dependa do endereço-base para onde foi copiado o seu programa, cria uma entrada de 16bits numa tabela de "relocações".

Quando o programa vai ser iniciado, uma rotina soma o endereço base do programa ao endereço indicado por cada entrada nessa tabela.

Assim vc pode fazer multiplos (e até identicos) programas estarem na RAM ao mesmo tempo, sem precisar de memória virtual (MMU) que um ARM7 ou um CM3 não tem.

Talvez os compiladores GCC sejam capazes de gerar objeto que tenham isso, já que isso é usado em .EXE para DOS, se eu não me engano.

[fabim]

tendeu, vou me aprofundar mais acerca deste assunto.

Obrigado pessoal