ASM51

Surgiu a oportunidade de fazer um treinamento com ARM cortex M3 da Texas, o kit de aprendizado usado será Stellaris® LM3S6965 Evaluation Board http://www.techtraining.eng.br/conteudo ... User_C.pdf
Pelo que pesquisei usa o compilador IAR !
Acredito que os ARMs da NXP sejam os mais usados.

Existe muita diferença de um fabricante de ARM cortex M3 para outro no código fonte ?

Este kit parece muito interessante Andre_Cruz, muito mesmo! Vale a pena.
Quanto a diferença entre os Cortex-M3, acredito eu que não exista muita diferença entre os fabricantes. Quanto aos códigos fontes. existe uma biblioteca, se é que posso chamar assim, coisa chamada CMSIS http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php, que seria uma programação de abstração da camada de hardware, facilitando a portabilidade do código entre os diferentes processadores Cortex-Mx.

Para começar, qualquer ferramenta facilmente disponível para Cortex M3 será a melhor.

Quanto ao fabricante, vai diferir em quantidade de periféricos / custo.
Gama de chips: Por exemplo, a Texas (Stellaris) tem uma ampla linha de Cortex M3.
Deve levar em consideração a facilidade de encontrar a linha selecionada no Brasil.

Há uma interface standard para Cortex Mn (CMSIS). Desta forma, mesmo havendo mudanças de endereços de periféricos de diferentes fabricantes, essas mudanças são transparentes ao programador.

O core Cortex M3 é exatamente o mesmo para todos os fabricantes.
Pode haver diferença em frequências de clock máxima, devido a pureza do material empregado (bolacha de Si) ou devido a relação com periféricos. Somente essa parte depende do fabricante.

Para quem migra para um Cortex Mn, deve avaliar custos natos impostos por sua maior frequencia, como melhor desenho de PCI. Em alguns casos será necessário n camadas.
Disponibilidade de potência bem menor que micros de 8 bits, como AVRs e PICs, o que pode resultar em aumento de custos em tarefas simples interfaceamento. Pode haver custos também no interfaceamento entre os 3,3V para 5 V de certos periféricos, bem como sua fonte exigir um regulador, mais caro que os de 5 V pelo menos por agora.
O tempo de aprendizado é bem maior que os chips de 8bits, quando queremos aproveitar todo o seu potencial, disponibilizado pelo seu amplo sistema de interrupções, perfeitamente preparado para uma ótima qualidade de software. Podemos definir o comportamento para uma ampla gama de falhas, inclusive congelamento no sensor Pitot .
Considerar custos com compiladores e ferramentas de debug.
Quanto a soldagem, para os chips de alta frequência, estes exigem maiores cuidados e know how (mais precisão no processo de soldagem) que pastilhas de baixa frequência. Isto é também custo.
Obviamente é uma linha para fazer o trabalho complexo, pesado e um sistema de qualidade que se tornaria um parto, impossibilidade ou ainda com baixa qualidade, com core de 8 bits.

vinny,

É bom saber que o kit vale apena !
Posso pensar então inicialmente que existe um arquivo, uma espécie de biblioteca que tem os endereços de cada periférico de cada ARM de cada empresa e quando o compilador esta montando o programa ele consulta essa "biblioteca" ?

Robl,

Bem interessante as informações que você citou !
Então fazer a PCI "caseira" para testes com esses uC de frequências mais altas e soldar na mão, não rola ?

Existe alguma(s) recomendação(ões) para quem esta iniciando em ARM ?

Valeww !

Tenho um kit Stellaris a venda, quem interessar.

RDK-IDM

http://www.luminarymicro.com/products/rdk-idm.html

Bom apenas complementando.. realmente o CMSIS cria uma "padronização" porém mesmo assim se você mudar de fabricante para fabricante ainda vai ter que reestudar o manual do ARM deles todo. Existem diversas diferenças possiveis na implementação do proprio ARM, e os perifericos cada fabricante tem o seu, o que faz cada um ter o seu mapeamento de memoria proprio, e firentes opções de registradores. O que é igual na verdade é o compilador (isso é padrão pois é para o processador, que é sempre o mesmo), as ferramentas (na verdade nem sempre pois existem algumas bloqueadas para certos fabricantes), o modo de acesso a qualquer registrador e o modo de acesso à todas as funções relacionadas ao processador. Mas microcontrolador de modo geral é aquela coisa.. se você realmente sabe usar um, aprender os outros é facil, ainda mais quando é o mesmo processador, e você so vai ter que adaptar os seus codigos para os detalhes especificos de cada dispositivo.

Abs

luisf.rossi

Valew

O ARM mais comum em projetos nacionais são de qual fabricante ?Alguém que tem mais experiência na área pode dizer ?

Abraço

Então fazer a PCI "caseira" para testes com esses uC de frequências mais altas e soldar na mão, não rola ?

Rola sim. Me refiro ao know how e custo na soldagem com produção em série de um produto comercial.

O ARM mais comum em projetos nacionais são de qual fabricante ?

Pitaco : Não disponho de estatísticas de venda de ARM Cortex M3 ou M0, mas do jeito que a NXP disponibilizou material no planeta e pelo movimento em foruns, chuto a NXP, no momento.
No Brasil adquirir ARM da NXP, pelo menos em quantidade acima de uma embalagem, esta fácil.

Ufa !!
Vou poder continuar com as placas ou melhor gambiaras de protótipos rsrsrs

É conforme for eu migro para a NXP, deixa eu aprender alguma coisa rsrsr !

Quais projetos mais comuns com ARM ?

Quais projetos mais comuns com ARM ?

Rapaz! Essa questão não saberei responder. Vamos tentar.
Mas pense que você tem que operar variáveis com 4 bytes (apenas 4 bytes, sem pensar em outras comuns bem maiores), suponha que elas sejam predominantes em seu processo. Fica claro que com 32 bits será um passeio para o compilador resolver operações com essas variáveis, resultará em alta performance e uma baita economia de flash.
Já em um micro de 8bits, a flash vai pro brejo rapidinho e a performance será baixa, muito baixa.
Se a predominância do trabalho, for de 8 bits e uma ou outra operação em 16 bits, depende, apesar do custo da CPU de um CM0 ser até menor que um micro de 8 bits.

Devido ao sistema de interrupção preciso dos ARMs, um OS resolverá muitos problemas que são difíceis ou até impossíveis em outros micros, normalmente de 8 bits, ainda que um AVR XMega (8bits) também tenha um sistema de interrupção porreta (determinístico).
Veja que um celular, um Ipad, mp3 e similares, usam 32bits, mas também fazem pisca led com Cortex !!!

Robl,

Meu medo é super dimensionar o uC dos projetos, porque até então só desenvolvo em 8 bits e bem pouco em 16bits.
Mas vou me policiar rsrsrs

Valew !

Andre, pense assim, se um 8 bits nao ta resolvendo E/OU esta lento, parte pro ARM...

Por falar em dimensionar, vou colocar aqui o que me "encasquetou" por esses dias. Talvez isto possa ajudar quem migra dos 8 bits especialmente PICs, 8051, e outros com 16bits como MSP430.

A questão era conseguir estimar a quantidade de flash necessária para certo programa em um CM0.
O problema é que o set de instrução do CMx usa instruções com 16 e 32 bits.
Quanto um programa usaria instruções de 16 e 32 bits ?
Fazendo uma suposição hipotética, se usasse somente thumb2, um chip de 8kbytes de flash, poderíamos escrever 4k instruções. Mas como certas instruções necessitam ser de 32 bits, essas comerão o dobro por instrução.
Pelas leituras da ARM e outros papeis, dizem que as instruções de 32 bits chegariam a 20% (mera estimativa). Então se vão 4 bytes por instrução.

Bom, se fosse em assembly, a estimativa poderia ficar mais próxima do resultado final, mas em C, não saberemos o que o compilador vai fazer para determinada parte do código.
Portanto, a grosso modo, para um chip com Nkbytes devemos ter no máximo (Nkbytes / 2 ) - Nkbytes x 0,10 = 2 / 5 (K bytes) (tenho dúvidas nos somente 10% que estimei. Considerei que 16 bits sempre serão usados mesmo em 32b = 16b + 16b )

O lado bom, por exemplo, em uma multiplicação, será feita com uma ou duas instruções. Em 8 bits sem multiplicador por HW, poderia chegar de 50 a 80 bytes, a mesma operação !!!

O lado interessante é ver que um CMx não é tão barato como apregoado em termos de flash, mas é sim em termos de desempenho.

quando voce faz um build de sua aplicação o arquivo MAP gerado tem a estatística de consumo de memórias.

A ideia aqui é avaliar custo (estimativa) de determinado chip antes de ter migrado, ou seja, antes de dispor das ferramentas.

Se não, aí sim, seria pegar uma aplicação, mudar para os periféricos do chip escolhido, e ver o resultado após compilar. Isto dá um trabalho danado, numa primeira abordagem, fora o tempo de aprendizado.