Ir ao conteúdo
  • Cadastre-se

Tutorial ARM Cortex-M0


Posts recomendados

Olá pessoal do fórum!
 
Resolvi escrever esse tópico para ensinar um pouco sobre a arquitetura ARM Cortex M0+. Para quem não conhece, os processadores ARM estão dominando o mercado hoje, estão desde simples controladores de temperatura até computadores completos. Acredito que esse tutorial pode ajudar a entender o básico da arquitetura ARM (com foco no Cortex M0+), até hoje não encontrei nenhum material completo em português, então vou sintetizar o que eu aprendi durante os últimos anos que estudei essa arquitetura.
 
O que são os processadores ARM?
São processadores de 32 bits (alguns 64 bits) de arquitetura RISC.
RISC: Reduced Instruction Set Computing, ou set de instruções reduzido (visando maior eficiência sobre a complexidade do núcleo);

Têm 16 registradores de 32 bits, sendo de R0-R12 de uso geral, e os dedicados são SP(Stack Pointer), LR (Link Register) e PC (Program counter).
 
Algumas famílias ARM:
Existem hoje aproximadamente 18 famílias, dentre elas as mais utilizadas são: ARM7, ARM7TDMI, ARM9TDMI, ARM11, Cortex-M, Cortex-A, Cortex-R.
 
Cada família tem uma especialização. Exemplo: O Cortex-A tem foco na área de processadores para computadores e Smartfones poderosos, o ARM7 abrange uma grande faixa, desde alguns microcontroladores  até processadores de videogames portáteis. O foco deste tutorial será na família Cortex-M (em especial os Cortex-M0+) que são arquiteturas focadas para microcontroladores.
 
Família Cortex-M:
São Von Neumann (Não existe separação entre barramentos de dados e o barramento da memória de programa):
 
Cortex-M0 -->Microcontroladores mais simples, suportam somente o set de instruções Thumb com algumas instruções do Thumb2 (sempre executam no modo Thumb);
Cortex-M0+ -->Apresentam algumas melhorias em relação ao M0, além de ter suporte opcional à proteção de memória (MPU);
Cortex-M1 -->São utilizados juntos com FPGAs;
 
São Harvard (Possuem barramentos separados para dados e instruções):
 
Cortex-M3 -->São microcontroladores mais poderosos, suportam completamente os sets Thumb e Thumb2, além de multiplicação têm divisão por hardware;
Coxtex-M4 -->Têm instruções para processamento de sinais (DSP), têm uma unidade de ponto flutuante opcional (Cortex-M4F).

 

O que é Thumb?

Thumb é um set de instruções de 16 bits que serve para melhorar a densidade do código (as instruções ocupam metade das instruções de 32 bits, existe uma perda de velocidade nisso, porém o código gerado é bem menor).
 
Características gerais do Cortex-M0+:
Baixíssimo consumo de energia: Apesar de consumirem mais energia que microcontroladores de 8 e 16 bits quando trabalhando na máxima velocidade, conseguem realizar a tarefa muito mais rapidamente, podendo ficar em sleep quando terminar;
 
Altíssimo desempenho em relação aos microcontroladores de 8 e 16 bits:
post-541077-0-83240900-1396374977_thumb.
 
Ótimo custo benefício;
 
Multiplicação 32x32bits por hardware (1 ou 32 ciclos dependendo do microcontrolador);

0.93 DMIPS/MHz;
 

Operação em 3.3V;

 

Velocidade máxima de 50MHz;

 

Enorme abundância de periféricos.

 

 

Bom, essa é a introdução, na próxima vez eu entro em detalhes sobre a arquitetura! continua...

  • Curtir 2
Link para o comentário
Compartilhar em outros sites

@Projetos_afg,

Muito legal seu tutorial, acho muito importante levar pras massas os ARM, principalmente os M0 que são concorrentes diretos aos processadores clássicos utilizados (AVR, PIC, 8051).

Conte comigo no que precisar de ajuda a respeito da arquitetura, a propósito em qual fabricante de processador você pretende focar? Além de qual ferramenta de desenvolvimento? Fechada? Open baseada em Eclipse + GCC?

Permita - me fazer algumas considerações :)

 

Esses processadores :  ARM7, ARM7TDMI, ARM9TDMI, ARM11 , nada mais são do que subfamílias de uma arquitetura comum, conhecida por ARMv6, eles essencialmente são igual só que possuem aditivos no set de instruções bem como no tratamento das exceções e periféricos internos.
De forma similar os processadores Cortex-M e Cortex-A são da mesma arquitetura a ARMv7 e v7M, essencialmente é o mesmo processador mas que sofre aditivos no set de instruções, no caso dos Cortex-A temos a unidade NEON para calculo vetorial em ponto flutuante via HW, a familia Cortex possui diferenciais como os modos low power, instruções SIMD e DSP extensions (M4) e a unidade de ponto flutuante, nos CM, ainda possuem o diferencial das interrupções que nao tem nos Cortex - A, o NVIC um belo controlador de interrupção deterministico.

 

Sobre processadores 64bits (aarch64) esses derivam da nova arquitetura a ARMv8 e seus processadores se nao me engano ja são usados no IPHONE 5s e 5C, nao devemos esquecer de citar os Cortex - R4 que são voltados para aplicações de missão crítica.

 

Sobre as instruções Thumb, nem sempre se ganha em densidade de código sobre a penalidade de perca de desempenho de execução, inclusive pode melhorar e muito o desempenho, algumas das instruções SIMD por exemplo que executam mais de uma operação em 1 ciclo de máquina fazem parte do set thumb. Processadores RISC que possuem arquitetura Load/Store não fazem milagres ja que a instruções possuem tamanhos fixos, podendo inclusive causar efeitos indesejáveis de desalinhamento na memória de programa... Nisso processadores Harvard - CISC dão um show combinando desempenho e instruções de tamanhos variáveis, dando um ganho de densidade de código incrível (Procesadores RX600 fazem isso).


Seria interessante explicar ao pessoal o que significa DMIPS, se precisar de uma mão estamos ai :)


No mais, parabéns pela iniciativa.

Abs.



 

Link para o comentário
Compartilhar em outros sites

@

 

Valeu o apoio!

 

Sobre o ARM Cortex-M0, M0+ e M1, esses utilizam a arquitetura ARMv6-M, enquanto os M3 e M4 usam a arquitetura ARMv7-M.

 

Vou focar para frente na linha Kinets da Freescale, ela oferece uma placa de desenvolvimento de baixo custo com debugador e programador embutido (OpenSDA). Tenho em mãos a placa FRDM-KL25Z:

FRDM-KL25Z.jpg

Sobre as ferramentas de desenvolvimento, inicialmente vou utilizar o Keil uVision e escrever em assembly, no final vou utilizar o GCC para escrever códigos em C. Ainda não encontrei uma IDE Open Source que suporte compilação e debug (OpenSDA) em C e assembly. Já usei o Coocox, mas só serve para C, e o debug com ele não funciona direito.

 

Continuando...

 

Antes de tudo devemos aprender como se estrutura a memória do microcontrolador. Os Cortex-M0/M0+ são Von Neumann, isso significa que eles têm um único barramento de 32 bits para tudo (memória de código, memória RAM interna, memória RAM externa e periféricos). Os endereços deste barramento são separados em blocos que têm funções específicas:

post-541077-0-95906700-1396452731_thumb.

* Retirado do livro The definitive guide to the ARM Cortex-M0

 
O primeiro bloco começa no endereço 0x00000000 e termina no endereço 0x1FFFFFFF, tem 0,5GB de espaço reservado para a memória de programa (isso não significa que ele tem 0,5GB de memória de programa!!!). Esse bloco tem permissão de execução e é somente leitura.
 
O próximo bloco começa no endereço 0x20000000 e termina no endereço 0x3FFFFFFF, também com 0,5GB de espaço reservado para memória RAM interna (mais uma vez isso não significa que tenha 0,5GB de RAM, de fato nunca vi um Cortex-M0 com mais de 64KB de RAM). Esse bloco tem permissão de execução, de escrita e leitura.
 
Espera ai, podemos executar o código na memória RAM? SIM! Isso significa que é possível armazenar o binário executável em qualquer mídia digital externa, ler essa mídia e executar o código! Apesar que isso raramente é necessário quando falamos de microcontroladores (que em produtos finais o programa é fixo, não precisa ter funcionalidades adicionadas de forma dinâmica).
 
O bloco do endereço 0x40000000 até 0x5FFFFFFF é reservado para acesso aos registradores de periféricos internos, este bloco não tem permissão de execução, somente de escrita/leitura.
 
Em seguida temos o bloco para o uso de RAM externa, do endereço 0x60000000 até 0x9FFFFFFF (permite endereçar até 1GB, apesar de ser um exagero extremo para microcontroladores em geral).
 
Do endereço 0xA0000000 até 0xDFFFFFFF é dedicado para acesso à periféricos externos.
 
Por fim, o último bloco de acesso do endereço 0xE0000000 até 0xFFFFFFFF é dedicado para uso dos perifércos do núcleo do processador tais como: NVIC (controlador de interrupções), debug e acesso ao System Control Block que contém alguns registradores para o controle do processador.
 
 
Continua...
  • Curtir 1
Link para o comentário
Compartilhar em outros sites

...e por fim acho que vocês devem iniciar pelo inicio pois ficou atropelado para um leigo o set de instruções THUMB,pois é preciso explicar a diferença entre o set ?ARM em comparação ao THUMB 1 e 2.

Não esquecer tambem sobre o uso do DMA nesta linha e os detalhes de wait state entre as memorias RAM e Flash.

Eu uso o Keil ,que gera um código final ,muito limpo  em relação ao GCC.

 

PS:Tomara que o tópico progrida pois tenho um tutorial sobre manipulação de imagens e Touch num GLCD, que vai depender da demanda do pessoal aqui quando usarem micros mais rapidos que AVR/PIC.

Link para o comentário
Compartilhar em outros sites

 

...e por fim acho que vocês devem iniciar pelo inicio pois ficou atropelado para um leigo o set de instruções THUMB,pois é preciso explicar a diferença entre o set ?ARM em comparação ao THUMB 1 e 2.

Não esquecer tambem sobre o uso do DMA nesta linha e os detalhes de wait state entre as memorias RAM e Flash.

Acho que para um leigo o set de instruções deve ser explicado sem tantos detalhes, uma vez que o tutorial tem por objetivo iniciar quem quer aprender. Já detalhes da arquitetura (ex.: o que são os Bus I-CODE e D-Code, instruções SIMD, e outros) podem ser consultados em bons livros, uma vez que o iniciado tera um conhecimento maior do que aquele que entrou. Os Wait States podem ser perceptíveis ou não, mais um detalhe que vale a pena ser buscado em um livro e nao num tutorial, pois a maioria dos fabricantes ja possuem instruction caches customizados para compensar a penalidade de memória Flash mais lenta que o clock do processador (por exemplo o ART usado nos micros da ST).

O Keil e o IAR ainda são referências na geração de código eficiente e limpo, por outro lado, se o objetivo é focar em gente que quer aprender e nao tem como investir na ferramenta (e convenhamos 32K de código limitado é muito pouco) valeria a pena cobrir tanto o desenvolvimento em uma ferramenta proprietária como em ferramenta aberta baseada no combo Eclipse + GCC.

Fora que a interface do keil e do IAR é feia que dói e pouco intuitiva :) (mas isso é mais questão de opinião)

Link para o comentário
Compartilhar em outros sites

 

 Os Wait States podem ser perceptíveis ou não, mais um detalhe que vale a pena ser buscado em um livro e nao num tutorial,

Se o tutorial chegar a programação,tem que explicar como setar o código pois este item faz parte da configuração inicial de um ARM ,que é obrigatótio. :)

Link para o comentário
Compartilhar em outros sites

Pessoal, o Cortex-M0/M0+ não suporta o modo ARM, somente o Thumb, junto com algumas instruções de 32 bits do Thumb 2. Se você tentar mudar para o modo ARM nele ocorrerá uma Hard Fault.

 

Sobre as ferramentas de desenvolvimento o que eu não encontro é uma IDE Open Source com um bom suporte de Debug (esse é essencial, já que quase não existem microcontroladores Cortex-M no Proteus, e sem debug em um microcontrolador relativamente complexo é como programar às cegas).

 

No keil vou passar somente a programação em assembly, assim estourar os 32K não é muito fácil.

Link para o comentário
Compartilhar em outros sites

@Projetos_afg,

O combo Eclipse + GCC é um bom começo, além disso existe também o OpenOCD que é um gdb server que suporta uma grande variedade de ferramentas de debbuging, inclusive o st-link e o OpenSDA, atualmente estou com operando essa solução em meu MAC para desenvolvimento com micros da ST (STM32F407) e me livrei de ter que fazer isso usando uma máquina virtual, deu trabalhinho pra configurar, deu, mas é algo que vai fazer só uma vez.

 

O Proteus é engraçado, não colocaram suporte a micros ARM, mas ofereceram suporte aos microcontroladores de tempo real derivados do DSP C28Fx da Texas Instruments... vai entender.

Abs.

Link para o comentário
Compartilhar em outros sites

Olá,

Veio a calhar este tópico, pois, estou no caminho das pedras com minha plaquinha ARM (STM32F103VC). gravador J-TAG J-LINK "clone".

Instalei o CooCox e o Keil, estão funcionando, compilei "led blink"(rs) nos 2, gravei e funcionou.

Venho dos PICs com compilador predominante CCS C, mas sei programar em assembly.

O que posso dizer até agora é que, fazendo uma analogia grotesca, se o PIC é um carro popular, o ARM é um onibus espacial em termos de recursos.

Está muito difícil assimilar tudo o que ele tem.

Estabeleci algumas metas para meu aprendizado, assim como comecei com PIC, fazer programas simples para explorar os periféricos separadamente, como I/O, Timers, Interrupções, comunicações(USART, I2C, SPI, etc) e depois fazer um projeto integrando vários.

Vou acompanhar o tópico, com certeza será de muito proveito.

 

Parabéns pela iniciativa.

 

Fervolt

Link para o comentário
Compartilhar em outros sites

  • 2 semanas depois...

Continuando...
 
Alinhamento de memória
 
Como a maioria dos microcontroladores RISC, a linha Cortex-M só executa instruções de forma alinhada na memória de programa. O que isso significa? Que cada instrução deverá estar alinhada conforme o seu tamanho em bytes.
 
Por exemplo: Uma instrução de 16 bits jamais terá o seu primeiro byte começando em um endereço ímpar. Isso significa que o bit menos significativo do PC (program counter) não é utilizado para endereçar instruções. Na verdade este bit tem uma outra função: Alternar entre o modo ARM (valor 0) e o modo Thumb (valor 1). No caso dos Cortex-M0/M0+ este bit sempre deverá estar setado, já que ele somente executa no modo Thumb, tentar apagar este bit resultará em uma HardFault.
 
Tabela de Vetores (Somente nos Cortex-M)
 
Antes de começarmos a escrever qualquer programa, devemos entender o que é a Tabela de vetores.
 
Ao contrário da maioria dos microcontroladores em que o programa começa no endereço 0 da memória de programa e as interrupções são desviadas para endereços fixos no começo da memória (no qual executamos saltos para as respectivas rotinas de interrupção), no caso dos Cortex-M os primeiros endereços da memória de programa são reservados para a Tabela de vetores.
 
O que é a tabela de vetores? É uma tabela que contém os endereços (vetores de 32 bits) para todas as exceptions (Reset, Hard Fault, Bus Fault, Supervisor Call, etc), com exceção do primeiro vetor (endereço 0) que aponta o fim da pilha (Stack Pointer).
 
Exceptions
As chamadas "exceptions" são basicamente interrupções do programa são controladas pelo periférico NVIC (Nested Vectored Interrupt Controller), depois explicarei ele com mais detalhes, mas basicamente o NVIC gerencia as interrupções levando em conta sua prioridade, o contexto, e carregando automaticamente o endereço da rotina de interrupção correspondente (por isso se chama "controlador de interrupções vetorado").
 
Depois eu explico todas as exceptions, mas por enquanto vou me concentrar nas principais: Reset e Hardfault.
 
Utilizando a sintaxe do assembler do keil:

	DCD	0x20000100		;Reserva 256 bytes para pilha	DCD	Reset_Handler		;Vetor de reset	DCD	NMI_Handler		;Nonmaskable interrupt					;Interrupção de mais alta prioridade					;(não usaremos por enquanto)	DCD	HardFault_Handler	;Vetor de Hard FaultNMI_Handler			;Ainda não utilizaremos essa interrupção	bx	LR		;Retorna da interrupçãoHardFault_Handler		;É importante ter essa exception em todos os programas,				;assim podemos encontrar erros que provoquem Hard FaultsStop_loop	b	Stop_loop	;Loop infinitoReset_Handler			;Rotina principal (main)	movs	R0, #0xFF	;Carrega o valor 0xFF em R0Loop_principal	b	Loop_principal	;Loop principal	END

Utilizando a sintaxe do Assembler GNU:

	.thumb				@ Instruções thumb	.syntax unified			@ Sintaxe unificada.section .text	.org 0				@ Endereço da memória 0	.word	0x20000100		@ Reserva 256 bytes para pilha	.word	Reset_Handler + 1	@ Vetor de reset	.word	NMI_Handler + 1		@ Nonmaskable interrupt					@ Interrupção de mais alta prioridade					@ (não usaremos por enquanto)	.word	HardFault_Handler + 1	@ Vetor de Hard Fault					@ Soma-se 1 para garantir o modo 'thumb'NMI_Handler:			@ Ainda não utilizaremos essa interrupção	bx	LR		@ Retorna da interrupçãoHardFault_Handler:		@ É importante ter essa exception em todos os programas,				@ assim podemos encontrar erros que provoquem Hard FaultStop_loop:	b	Stop_loop	@ Loop infinitoReset_Handler:			@ Rotina principal (main)	movs	R0, #0xFF	@ Carrega o valor 0xFF em R0Loop_principal:	b	Loop_principal	@ Loop principal

Este é um simples programa para entender como usar a tabela de vetores, no próximo post explicarei set de instruções.
 
Aqui uma tabela com a organização das principais exceptions:
 
post-541077-0-60843300-1397671075_thumb.
Retirado do livro The Definitive Guide to the ARM Cortex-M
Registradores
 
Todos os ARMs de 32 bits têm 16 registradores de 32 bits, sendo de R0 a R12 de uso geral. Os registradores com funções reservadas são:
 
SP - Stack Pointer (R13):
 
Esse registrador aponta para o endereço que pilha se encontra no momento. Sempre deve ser incializado na tabela de vetores (Inicio_RAM + Tamanho_da_pilha).
Ex:
0x20000100 ->Reserva 256 bytes para pilha (0x20000000 + 0x100).
 
A pilha "cresce" para tráz, isso quer dizer que ela termina em 0x20000000.
 
LR - Link Register (R14):
 
Esse registrador armazena o endereço de retorno de uma sub-rotina ou de uma interrupção. No caso de interrupções, ele aponta para um endereço especial para restauração de contexto.
 
PC - Program Counter (R15):
Aponta o endereço onde o código está executando, devido a algumas características internas da arquitetura ele sempre aponta para a próxima instrução a ser executada, e não para o endereço da instrução atual.

Link para o comentário
Compartilhar em outros sites

@Projetos_afg, ta ficando bom esse tutorial hein :)

Alguns comentários,

 

 

 

Como a maioria dos microcontroladores RISC, a linha Cortex-M só executa instruções de forma alinhada na memória de programa. O que isso significa? Que cada instrução deverá estar alinhada conforme o seu tamanho em bytes.

Isso é uma coisa que acho ruim nos ARM, e em outros RISC com arquitetura Harvard, na verdade ai está a razão para compiladores C fazerem estripulias para manter uma boa relação densidade de código x velocidade de execução, como o ARM so possui dois tamanhos de instruções e alinhada a memória o compilador tem que se virar com isso. Essa é uma característica que falta a ele mas presente em outros micros de 32bits como o PIC32 (MIPS M4K) e RX600 que possuem VLE (Variable Code Length) em que uma instrução pode ter diferentes comprimentos, melhorando muito a densidade de código sem descuidar da velocidade.

 

 

 

O que é a tabela de vetores? É uma tabela que contém os endereços (vetores de 32 bits) para todas asexceptions (Reset, Hard Fault, Bus Fault, Supervisor Call, etc), com exceção do primeiro vetor (endereço 0) que aponta o fim da pilha (Stack Pointer).

 

Outra grande coisa chata, que me faz sentir saudades até do lerdão ARM7TDMI, são essas interrupções vetoradas, o NVIC não, ele é sensacional, os vetores ficam estaticos, com uma tabela definida em um local, e cada ferramenta implementa essa tabela de uma forma diferente e vai la no linker e acerta as seções de memória como bem entende... o que dificulta por exemplo escrever um RTOS portável entre micros ARM - CortexM de diferentes fabricantes. Em micros como o dsPIC, os C2000 da TI e o ARM7TDMI a tabela ja era mapeada em memória bastando passar  um ponteiro de função para o registrador correspondente o que facilitava e muito na hora de configurar uma interrupção.

PS.: o NVIC é legal, só é chatinho de configurar no começo.

Que venham as próximas partes :)

Abs.

Felipe

Link para o comentário
Compartilhar em outros sites

  • 5 semanas depois...
  • Membro VIP

Amigos, vou entrar nessa também, principalmente depois que vi o preço da placa que o amigo Projetos_afg usa.

Tá mais barata que alguns uC de 8 bits.

http://www.farnellnewark.com.br/ferramentadesenvfreedomkl25zfreescalesemicond,product,28W5033,0.aspx

Tá na hora de evoluir pra 32bits.

  • Curtir 1
Link para o comentário
Compartilhar em outros sites

Estava lendo esse site aí agora pouco.

 

Realmente parece ser bem simples. Meu medo é ficar preso depois com alguma rotina mais complexa e não conseguir ajuda.

 

Para quem quiser algo mais em conta tem o MSP430 da Texas. Perece ser Interessante também (R$30 reais)

 

http://www.farnellnewark.com.br/msp430launchpadferramentadesenvolvimentotexas,product,AR00002,0.aspx

 

Falou

Link para o comentário
Compartilhar em outros sites

  • 2 semanas depois...

@ e @Matheus_LPS...

Pra vocês que ja vem de brincadeira a fundo com micros de 8bits explorar o núcleo de 32bits não será de tão grande novidade. 

Sobre as placas, e opinião pessoal, eu não começaria pelos micros (ARM) da Freescale, documentação deixa muito a desejada, a fabricante só fornece device drivers e afins sob o uso do horrendo processor Expert, que era muito bom quando tinha o componente de inicialização de hardware para configurar fonte de clock e watchdog por exemplo, até ela remove - lo deixando aquele gerador de código inútil. 

O bom das Freedom realmente é o preço, apesar que kits de avaliação pra ARM está bem cheio, eu tenho preferência pelos micros da ST:
http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF253215

Os chips são baratos, e vem com mais periféricos (úteis) que os Freescales baratinhos.

Se forem usar o mbed para iniciar (só não gosto do codigo final que ele gera), vejam a stm núcleo (10 doletas!)

http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847

 

Essa é nativamente compatível com o mbed (juntamente com as LPCExpresso).

Divirtam - se, o mundo dos ARM é divertido, oferece um mundo de possibilidades, e formas de programar, hoje estou envolvido em dois projetos, bem legais, um sistema operacional de tempo real para microcontroladores (esse ja ta pronto!) e um quadcóptero, e ter uma máquina dessas ajuda bastante (embora o controle de motores eu use um DSP de 32bits para fazer o serviço sujo).

Divirtam - se e contem comigo pro que precisar.

Abs.

  • Curtir 1
Link para o comentário
Compartilhar em outros sites

Já já sai post novo (andei meio ocupado essas semanas)!

 

 

 

Sobre as placas, e opinião pessoal, eu não começaria pelos micros (ARM) da Freescale, documentação deixa muito a desejada, a fabricante só fornece device drivers e afins sob o uso do horrendo processor Expert, que era muito bom quando tinha o componente de inicialização de hardware para configurar fonte de clock e watchdog por exemplo, até ela remove - lo deixando aquele gerador de código inútil. 

 

Realmente concordo com você nesse ponto, acabei comprando a placa da freescale pelo baixo preço e pelo fato dela ter um debugador embutido, porém foi bem difícil encontrar documentação e suporte, acabei por ter que produzir essa documentação por conta própria, e vou compartilhar aqui.

Link para o comentário
Compartilhar em outros sites

@Projetos_afg, e demais,

Eu particularmente gosto de outros micros da Freescale (S12X e os baseados na arquitetura power E200z), pois esses possuem notas de aplicações bem detalhadas, diagramas funcionais e o principal, software desenvolvido de forma bare metal, ou seja sem abstrações é atuação direta com hardware do microcontrolador, isso ensina muito mais do que forncer frameworks e apenas exemplos usando uma ferramente de confuguração gráfica (parece que o conceito de time to market esta tão forte que estão desconsiderando que conhecer sua máquina é essencial para manter esse "market").

O ecossistema de microcontroladores ARM da Freescale (familia Kinetis) deixa muito a desejar, eles possuem esse kit chamado de freedom board e se contentam com o fato da disposição dos pinos ser compatível com Arduino, ok, mas nem todo mundo quer ficar eternamente nos shields do Arduino...é diferente do ecossistema launchpad criado pela Texas, que fornece a placa com processador a um preço baixo, mas fornece diversas placas perifericas e preços excelentes, alem de um fork próprio do Arduino. 
http://www.ti.com/ww/en/launchpad/boosterpacks.html

O link acima leva para uma pagina com todos launchpads e boosterpacks. 

Na mesma linha de raciocinio, a ST também está indo por esse caminho, fabrincando periféricos para sua stmdiscovery, afim do entusiasta nao ficar só nos leds. Ambas as fabricantes, ST e TI estão provendo muita documentação, seja pro kit ou prochip especifico que vai no kit, desde datasheet até manual de programação, isso acelera o que chamo de aprendizado com qualidade, não é muito melhor conhecer a arquitetura do chip e projetar tudo a seu gosto do que ficar contatando a fabricante para prover suporte quando o framework nao atende?

Sobre o tutorial também estou doido pra ver os textos projetos, em especial a documentação que voce fez sobre a Freedom Board, aproveitando, voce teve algum problema para usar o OpenSDA?

Abs.

Link para o comentário
Compartilhar em outros sites

@

 

Realmente. Estou muito inclinado em pegar alguma placa da Texas mesmo. Precisei de ajuda uma vez no forum deles e fui muito bem recebido pela staff. São os próprios funcionários que respondem. Show de mais.

 

E gostei muito dos booster packs.

 

Como eu falei ali em cima, o MSP430 LAUNCH PAD está 30 reais na Farnell Brasil.

 

Falou

Link para o comentário
Compartilhar em outros sites

Visitante
Este tópico está impedido de receber novas respostas.

Sobre o Clube do Hardware

No ar desde 1996, o Clube do Hardware é uma das maiores, mais antigas e mais respeitadas comunidades sobre tecnologia do Brasil. Leia mais

Direitos autorais

Não permitimos a cópia ou reprodução do conteúdo do nosso site, fórum, newsletters e redes sociais, mesmo citando-se a fonte. Leia mais

×
×
  • Criar novo...