Página 1 de 2

Velocidade ARM

MensagemEnviado: 04 Nov 2006 15:18
por Renato
Fiz um teste no seguinte cenário:
LPC2138 / Clock 60 MHz / PCLK 15 MHz / Modo ARM

void main()
{
init_devices();
while(1)
{
GPIO_IOSET1 = P1_25;
GPIO_IOCLR1 = P1_25;
}
}

O sinal de saída no P1_25 foi ~ 500 kHz, o que
parece pouco p/ um processador de 60 MIPs. :?: :?: :?:

MensagemEnviado: 04 Nov 2006 18:38
por mastk
qual o clock do barramento da pereferia?

ARM

MensagemEnviado: 04 Nov 2006 19:43
por sandei
Quem é o Fabricante destes ARM!

MensagemEnviado: 04 Nov 2006 22:10
por mastk
philips

NXP

MensagemEnviado: 05 Nov 2006 21:23
por tcpipchip
NXP

MensagemEnviado: 06 Nov 2006 06:58
por gafar
Durante a inicialização vc incluiu estas intruções para aumentar a velocidade..

void Initialize(void) {


// Setting the Phased Lock Loop (PLL)
// ----------------------------------
//
// Olimex LPC-P2106 has a 14.7456 mhz crystal
//
// We'd like the LPC2106 to run at 53.2368 mhz (has to be an even multiple of crystal)
//
// According to the Philips LPC2106 manual: M = cclk / Fosc where: M = PLL multiplier (bits 0-4 of PLLCFG)
// cclk = 53236800 hz
// Fosc = 14745600 hz
//
// Solving: M = 53236800 / 14745600 = 3.6103515625
// M = 4 (round up)
//
// Note: M - 1 must be entered into bits 0-4 of PLLCFG (assign 3 to these bits)
//
//
// The Current Controlled Oscilator (CCO) must operate in the range 156 mhz to 320 mhz
//
// According to the Philips LPC2106 manual: Fcco = cclk * 2 * P where: Fcco = CCO frequency
// cclk = 53236800 hz
// P = PLL divisor (bits 5-6 of PLLCFG)
//
// Solving: Fcco = 53236800 * 2 * P
// P = 2 (trial value)
// Fcco = 53236800 * 2 * 2
// Fcc0 = 212947200 hz (good choice for P since it's within the 156 mhz to 320 mhz range
//
// From Table 19 (page 48) of Philips LPC2106 manual P = 2, PLLCFG bits 5-6 = 1 (assign 1 to these bits)
//
// Finally: PLLCFG = 0 01 00011 = 0x23
//
// Final note: to load PLLCFG register, we must use the 0xAA followed 0x55 write sequence to the PLLFEED register
// this is done in the short function feed() below
//

// Setting Multiplier and Divider values
void feed(void)
{
PLLFEED=0xAA;
PLLFEED=0x55;
}


PLLCFG=0x23;
feed();

// Enabling the PLL */
PLLCON=0x1;
feed();

// Wait for the PLL to lock to set frequency
while(!(PLLSTAT & PLOCK)) ;

// Connect the PLL as the clock source
PLLCON=0x3;
feed();

// Enabling MAM and setting number of clocks used for Flash memory fetch (4 cclks in this case)
MAMCR=0x2;
MAMTIM=0x4;

// Setting peripheral Clock (pclk) to System Clock (cclk)
VPBDIV=0x1;

}


void feed(void)
{
PLLFEED=0xAA;
PLLFEED=0x55;
}

ARM / Velocidade

MensagemEnviado: 06 Nov 2006 07:22
por Renato
Gafar:
Mas mesmo com VPBDIV=4 (PCLK=15 MHz), o sinal de saída não
deveria ser maior que 500 kHz ?
Seriam esses compiladores tão ineficientes ou tem outras variáveis
em jogo por aí ?

MensagemEnviado: 06 Nov 2006 08:48
por Fábio Pereira
Bom,

Antes de acusar o compilador, verifique o código assembly gerado.

Experimente rodar o código num simulador e observe o número de ciclos gastos na execução de cada instrução.

Até +

MensagemEnviado: 06 Nov 2006 09:36
por Renato
O Fábio está dizendo, implícitamente, que a causa então são as
outras variáveis !
Quais seriam então ?

MensagemEnviado: 06 Nov 2006 10:21
por gpenga
Bem coloque o VPBDIV=1 (PCLK=60 MHz),
assim vc almentara a velocidade do barramento de IO
eu ja consegui 7.5Mhz de clock em um pino no LP2138

MensagemEnviado: 06 Nov 2006 12:42
por Renato
Fazendo uma continha:
60 MHz => ~ 60 MIPs
60 / 7,5 = 8 , logo o loopsinho talvez tivesse uns 8 ciclos (~8 instruções).
Parece coerente ...

Mas p/ PCLK = 15 MHz já muda bastante, com o mesmo loop, logo as
mesmas supostas 8 instruções, o sinal fica em 0,5 MHz, ou seja, não
é uma relação linear.

Será que é a comunicação entre barramentos que faz isso.

MensagemEnviado: 06 Nov 2006 19:54
por mastk
Creio então, q GPIO, não é msm barramento, logo não visa velocidade e sim comunicação com o mundo externo. Certo?

Então já deve ter 8051 por ai q ralam os ARMs pra certa coisas...

MensagemEnviado: 07 Nov 2006 11:52
por msamsoniuk
ele nao possui bus externo tambem ? poderia testar usar um 74F374, diretamente no bus de dados dele, mapeado como memoria e fazendo o latch por um chip-select ou por um endereco especial. entao, eh possivel testar a performance com um loop mais ou menos assim:

Código: Selecionar todos
char a=0,b=1,*port=endereco_da_porta_F374;

while(1) {

    *port=a;
    *port=b;
    *port=a;
    *port=b;
    *port=a;
    *port=b;
    *port=a;
    *port=b;
}


imagino que esse codigo vai produzir o resultado mais eficiente, pois todas as constantes estao em registros. alem disso, foi feito manualmente o unroll do loop, reduzindo em 25% o tempo desperdicado pelo loop. se nao eh possivel ligar um 74F374 no bus externo dele, poderia tentar essa forma:

Código: Selecionar todos
char a=P1_25,*ports=GPIO_IOSET1,*portc=GPIO_IOCLR1;

while(1) {

    *ports=a;
    *portc=a;
    *ports=a;
    *portc=a;
    *ports=a;
    *portc=a;
    *ports=a;
    *portc=a;
}


se for possivel comparar ambos, melhor ainda. acredito que seria ideal usar um 74F pq eles sao capazes de operar em velocidades da ordem de 100MHz, enquanto que os 74LS e 74HC operam em frequencias mais baixas.

MensagemEnviado: 07 Nov 2006 13:53
por Renato
Encontrei uma referência no User Manual que descreve:
1) PCLK=CCLK=60 MHz,
2) Uso de Fast Registers,
3) MAM totalmente habilitado,
4) Loop em Assembly.

Máx. frequência numa GPIO: ~15 MHz.

Tem jeito ...
(que saudade do 8085 ...)

MensagemEnviado: 08 Nov 2006 22:22
por gibim
Só lembrando pessoal, é muito importante ligar o MAM quando está operando com PLL. Estava com uns problemas que o LPC2138 ia rodar umas instruções de acesso a memória e dava uma interrupção por "data abort". Fuçando...Encontrei numa errata da NXP que o erro era por causa de problemas na máscara do ARM e para corrigir isso, seria obrigado a ligar MAM = 3 antes de acessar a memória, pois a velocidade de PCLOCK a 60Mhz causava esse tipo interrupção.

Feito isso resolvi o problema.

Só tome cuidado... ARM é bonitinho... mas ordinário às vezes.