ASM51

Trabalhando no projeto com LPC1114 ( http://www.asm51.eng.br/phpbb/viewtopic ... 5&start=45 ), notei que o ADC estava me sacaneando um bocado...

Depois de alguma perda de cabelo, descobri que o PULL-UP da porta estava ligado...

É o primeiro chip que trabalho que dá para ligar PULL-UP numa entrada analogica... Pode até ser normal, mas para mim parece meio absurdo...

Agora preciso interpretar isso:

5 224 bytes of readonly code memory
64 bytes of readonly data memory
2 207 bytes of readwrite data memory

Acho que meu programa está obeso.

Podia ser, como dizem..."AUTOMATICAMENTE" desabilita....

poisé, o LPC1768 tem pull up em todos os pinos... Só que valor bemmmmm alto,..
E ja inicializa desabilitado. To estranhando o AD ter o pull up abilitado..

DEve ter alguma errata acerca deste caso.

Bem... :oops:

Eu que habilitei indevidamente, mas na minha inocencia e da vivencia com outros mcu´s, isso era automatico, como o Miguel disse...

Mas beleza, tá dominado.

Agora aquela velha historia... Usar variaveis de 8 bits, quando eu só preciso de 8 bits, ou usar 16 ou 32 por que é mais confortavel ao chip? Mas isso é outra história.

Vc pode usar variavel de qualquer tramanho, qual o problema?

.

KrafT escreveu:Bem...

Eu que habilitei indevidamente, mas na minha inocencia e da vivencia com outros mcu´s, isso era automatico, como o Miguel disse...

Mas beleza, tá dominado.

Agora aquela velha historia... Usar variaveis de 8 bits, quando eu só preciso de 8 bits, ou usar 16 ou 32 por que é mais confortavel ao chip? Mas isso é outra história.

Se precisar de performance, o mais confortável ao chip.

E vc esperava o que da NXP? O pior é o fabim, que diz que eles devem ter errata... hehehe. Nem tiram os tbd dos datasheets deles, vão ter erratas?

eh que o fabim eh ingenuo! :D

quanto a performance me parece bem obvio: se o processador tem bus de 32 bits e registros de 32 bits, com um set de instrucoes reduzido e limitado, tentar usar variaveis menores pode impactar a performance significativamente, pois ele vai ter q fazer malabarismos com mascaras para acertar os resultados de 16 e 8 bits.

pbernardi escreveu:

KrafT escreveu:Bem... :oops:

Eu que habilitei indevidamente, mas na minha inocencia e da vivencia com outros mcu´s, isso era automatico, como o Miguel disse...

Mas beleza, tá dominado.

Agora aquela velha historia... Usar variaveis de 8 bits, quando eu só preciso de 8 bits, ou usar 16 ou 32 por que é mais confortavel ao chip? Mas isso é outra história.

Se precisar de performance, o mais confortável ao chip.

E vc esperava o que da NXP? :) O pior é o fabim, que diz que eles devem ter errata... hehehe. Nem tiram os tbd dos datasheets deles, vão ter erratas?

Nao vai fazer malabarismos coisa alguma.

A unica coisa que muda é o tempo de acesso á memoria, tanto na Ram (para buscar uma variavel) como naFlash (para buscar uma Constante)

A memoria Ram e Flash do ARM é organizada em Bytes (8 bits). Logo se usar uma variavel de 32bits, o sistema terá que fazer 4 ciclos de leitura para montar essa variavel naquele banco de registradores de 32 bits.

O Arm tem tambem instruçoes de acesso a qualquer um dos 4 bytes dentro de uma variavel de 32 bits. Não haverá malabarismo algum.

Então... Como o chip é só 32k/8k, pelo log do IAR eu já detonei 1/4 da RAM disponivel.

Mas sendo o Proex diz, se a coisa ficar critica, vou fazer um downsize nas variaveis que não necessitam ser de 16 ou 32 bits.

Um dos motivos da aparição do Cortex Mn é justamente o fato de fazer acessos com SRAM desalinhada, sem perda de eficiência.

Portanto, diminua todas suas variáveis.

Aproveito para informar que essa propriedade é a que possibilitou a aparição, especialmente do CM3, com respeito a seu custo reduzido, exatamente por possibilitar melhor uso da SRAM e FLASH (devido a outra propriedade no acesso as insturções) em relação a outros ARM, pois as memórias são a parte mais relevante no custo do micro.

Cabe lembrar que uma vez dentro do "cérebro" tudo será feito em 32 bits não importando mais, quantos bits temos em cada registro.

tah bom, se vc esta falando deve ser entao.

proex escreveu:Nao vai fazer malabarismos coisa alguma.

A unica coisa que muda é o tempo de acesso á memoria, tanto na Ram (para buscar uma variavel) como naFlash (para buscar uma Constante)

A memoria Ram e Flash do ARM é organizada em Bytes (8 bits). Logo se usar uma variavel de 32bits, o sistema terá que fazer 4 ciclos de leitura para montar essa variavel naquele banco de registradores de 32 bits.

O Arm tem tambem instruçoes de acesso a qualquer um dos 4 bytes dentro de uma variavel de 32 bits. Não haverá malabarismo algum.

Leitura interessante:

http://www.iqmagazineonline.com/current ... -IQ-30.pdf

proex escreveu:A memoria Ram e Flash do ARM é organizada em Bytes (8 bits). Logo se usar uma variavel de 32bits, o sistema terá que fazer 4 ciclos de leitura para montar essa variavel naquele banco de registradores de 32 bits.

Só se esta implementação do Cortex-M0 for assim. Em todos os outros ARM que vi, Cortex-M3 inclusive, a word na memória tem 32 bits, e o barramento também, portanto as transferências de 32 bits alinhadas são sempre feitas em 1 ciclo de clock + wait state, que no caso dos µC que vi, costuma ser 0 para ram, e as vezes tbm para flash.

O sistema de memória deve aceitar sempre leituras/gravações em alinhamentos naturais, portanto p/ reads ou writes de 16 bits, tem que estar alinhado em 16 bits. P/ ler/gravar em 8 bits isto se torna irrelevante.

Quando o acesso é desalinhado (tou falando do cortex, que tem instruções para tal; Os arm7tdmi por ex. só fazem acesso alinhado), ou seja, fora do alinhamento natural, o que o cortex implementa é um buffer e uma lógica que calcula se pode satisfazer o pedido com 1 ou "n" reads no barramento. Estes reads são feitos alinhados como na regra anterior, e em sequencia, para um buffer interno, onde os dados são movidos e mascarados por hardware. Isto foi feito meramente para reduzir a densidade do código, embora pequeno ganho de performance tenha sido obtido pela eliminação das instruções extras. Isto está descrito com detalhes na documentação da ARM sobre o cortex-m3, e sobre o barramento de memória local.

Se o cortex-m0 foi simplificado (?) a ponto de transformar uma leitura de 32 em 4 de 8, eu não sei, mas a meu ver não faria muito sentido implementar um micro-barramento e fazer acessos a 8 bits, esta técnica está em desuso e não faz sentido num projeto voltado a reduzir o número de transistores (bus < largura da word precisa de lógica auxiliar) e o consumo de energia (mais ciclos para efetuar mais transações tendem a consumir mais energia do que transferências mais largas, mas claro que isto depende de como a coisa é implementada e mesmo quando é tradicional, tem um ponto na curva onde a equação balança pro outro lado).