Tem coisas que só a NXP faz por você...

[KrafT]

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.

[tcpipchip]

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

[fabim]

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.

[KrafT]

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.

[proex]

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

.

[pbernardi]

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?

[msamsoniuk]

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.

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?

[proex]

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.

[KrafT]

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.

[RobL]

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.

[msamsoniuk]

tah bom, se vc esta falando deve ser entao.

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.

[KrafT]

Leitura interessante:

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

[polesapart]

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).