Projetos_afg

Quando eu tiver um tempo livre posso tentar montar um circuito modulador por fase com alguns amplificadores operacionais para RF, não me parece algo muito difícil, mas vai requerer alguns cuidados na montagem e seleção dos componentes. Em RF nunca se usa uma modulante que não seja senoidal! No caso da televisão estamos nos aproveitando do fato dela ter um filtro passa baixas e só usar uma banda para o sinal colorido, funciona mas não é o jeito certo. Utilizamos a onda senoidal como modulante pelo fato de ser uma onda "pura". Ondas quadradas, triangulares, dente-de-serra, etc, na verdade são compostas de uma soma infinita de ondas senoidais de frequências múltiplas da frequência fundamental: No caso do 4QAM digital (ou 16QAM, 64QAM ...) a fase e amplitude são alteradas em valores discretos, gerando um diagrama mais compreensível: Já o analógico a distribuição não é discreta mas uniforme:

O burst pode ser uma onda quadrada, a televisão tem um filtro passa baixas que vai atenuar bastante as harmônicas transformando a onda quadrada em senoidal. Você vai precisar basicamente de um conversor D/A (pode ser feito com resistores) para gerar o sinal e conseguir variar a amplitude do sinal das cores. Acredito que sua maior dificuldade é não ter um fundo em radio frequência para entender como funciona a modulação 4QAM analógica (o 4QAM digital é bem mais simples de visualizar).

Com um PIC18 isso não é possível. Nunca vi nenhum projeto utilizando PICs 18/16 gerando video colorido sem auxílio de algum hardware externo para isso. Encontrei um projeto fantástico que utiliza um AVR para gerar o sinal PAL colorido: http://www.linusakesson.net/scene/phasor/index.php O AVR tem uma grande vantagem por ter um set de instruções bem mais poderoso, 32 registradores de uso geral (o pic só tem o W) e acesso à memória de forma linear sem troca de bancos / páginas.

Isso você usa uma tabela pronta com as unidades adequadas. Calcular em tempo real seno e coseno com o PIC demoraria dezenas de milisegundos. Mas gerar um sinal de 3,58MHz mesmo sendo em onda quadrada para o 'color burst' já é complicado com o PIC. Você precisaria fazer um overclock de 14.328224 MIPS e mesmo assim não daria tempo para um loop: ;Cristal = 14.328224MHz;PLL = x4;Gera uma onda quadrada de 12 ciclos a 3,58MHzbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynop Esse sinal nunca foi visado para ser emulado por software. Use um dos CIs que sugeri e sua vida ficará bem mais fácil!

Sim, a unidade de tempo é a mesma de cada pixel da imagem e ela vai depender da resolução do sinal de vídeo.

Esse sinal indica a que em cada linha de varredura você deve defasar a componente "V" em 180º em relação á anterior. Isso é necessário no PAL para evitar que ocorra erros cumulativos na sincronia do sinal (o NTSC originalmente tinha esse problema, o PAL usou essa técnica para resolve-lo, nas televisões NTSC novas isso não acontece mais). Exemplo: 1ª linha: S(t) = Y + U*cos(2*π*FM*t) + V*sin(2*π*FM*t) 2ª linha: S(t) = Y + U*cos(2*π*FM*t) - V*sin(2*π*FM*t) O autor afirmou que não conseguiu encontrar uma forma elegante no software para gerar essa defasagem, já que o sinal Y também teria que estar em fase com as cores. Acabei encontrando 4 CIs que já codificam os sinais em PAL: http://www.cirrus.com/en/pubs/proDatasheet/CS4954-55_F6.pdf http://www.nxp.com/documents/data_sheet/SAA7108AE_SAA7109AE.pdf http://www.analog.com/static/imported-files/data_sheets/ADV7174_7179.pdf http://www.eecg.toronto.edu/~tm3/ad722.pdf

Dei uma lida no pdf que indiquei. Entendi que sobre o sinal de vídeo em preto e branco é adicionado mais um sinal com uma modulante de 4.43 MHz (no Brasil utilizamos o PAL-M que usa uma modulante de 3.58 MHz) que transporta a informação de cor utilizando o esquema de modulação 4QAM analógico. O 4QAM significa Quadrature Amplitude Modulation que utiliza a modulação por fase combinada com a modulação em amplitude para a transmissão de informações. O 4QAM permite transmitir permite transmitir 2 bits por Hz (digital) ou 2 sinais diferentes (analógico) conferindo assim uma boa eficiência espectral. No começo da varredura de cada linha do televisor é enviado um sinal de sincronia para que o oscilador interno da televisão esteja em fase com o oscilador do dispositivo que está gerando o vídeo: É dessa forma que o televisor consegue perceber a defasagem dos sinais. Com o sinal em preto e branco e as componentes R - Y (vermelho - luminância) [V] e B - Y (azul - luminância) é possível reconstruir as cores RGB. No sinal PAL a luminância (preto e branco) pode ser calculada por: Y = 0.222R + 0.707G + 0.071B Então para convertermos uma imagem RGB em suas componentes Y, U e V podemos utilizar a seguinte matriz: ┌ ┐ ┌ ┐ ┌ ┐│Y│ │ 0.299 0.587 0.114 │ │R││U│ = │-0.147 -0.289 0.436 │ * │G││V│ │ 0.615 -0.515 -0.100 │ │B│└ ┘ └ ┘ └ ┘ O sinal gerado pode de imagem para cada linha pode ser gerado com a seguinte função: S(t) = Y + U*cos(2*π*FM*t) ± V*sin(2*π*FM*t) Em que FM é a frequência da modulante e t é o sinal no domínio do tempo. Você pode observar nessa função o sinal ±, isso é devido ao PAL (Phase Alternating Line) precisar que um dos sinais seja defasado 180º (o color burst precisa ser defasado em 90º) em cada linha em relação à anterior. O autor utilizou o microcontrolador SX rodando a 50MIPS para gerar um sinal com cores somente por software. Acredito que nessa parte seja necessário fazer em hardware para ter uma boa resolução e não exigir um microcontrolador poderoso dedicado somente para essa tarefa.

@Vicente Cesar Consegui apenas desenhar uma linha na tela, mais nada! Você conseguiu muito mais do que eu. O que andei pesquisando recentemente foi o protocolo VGA que é muito mais fácil de se usar. Usei um FPGA como controlador de vídeo, mas o projeto está incompleto e estou cheio de coisas para se fazer nesse final de ano!

Por volta de 2010~2011 eu estive procurando como gerar sinais de vídeo composto com um PIC16. Lembro-me de ter encontrado um site muito bom sobre o assunto. Hoje não encontrei mais esse site, mas encontrei este PDF que foi escrito pelo mesmo autor: http://elinux.org/images/e/eb/Howtocolor.pdf Apesar do autor afirmar que não conseguiu gerar sinais no padrão PAL (só teve sucesso com o NTSC) ele explica muito bem como funciona a geração desses sinais. Edit: Encontrei o site no web archive: http://web.archive.org/web/20140209113630/http://www.rickard.gunee.com/projects/video/sx/gamesys.php

Lembre-se que o clock do PIC sempre demora 4 ciclos de clock para executar a maioria das intruções. Se você têm um PIC16 com um cristal de 20MHz na verdade ele está executando 5 milhões de instruções por segundo. No caso do PIC18 a maioria dos modelos têm um PLL interno para multiplicar a frequência do cristal. No projeto que o @vtrx postou o cristal do microcontrolador é de 12MHz, mas o PLL interno multiplica por 4 e resulta em 48MHz, como o PIC precisa de 4 ciclos para cada instrução então nesse caso ele executa 12 milhões de instruções por segundo. Vi que o 6502 demora entre 2 e 7 ciclos de clock por instrução dependendo do endereçamento utilizado, o que parece dar uma boa margem de tempo para um PIC18 emular o binário, desde que você consiga ler rápido o suficiente da memória RAM externa (não encontrei nenhum PIC18 com mais de 4KB de RAM interna). Pelo que entendi esse atari tinha um processador de vídeo, acho difícil você decodificar as instruções e gerar um sinal de vídeo em tempo real somente com um PIC18. Volto a dizer que não dá para utilizar um pendrive com um PIC18. Nenhum modelo dessa família tem USB Host, somente USB Device. Use um cartão SD que é tranquilo de interfacear (utiliza o protocolo SPI).

Usar um pendrive!? Que eu saiba nenhum PIC18 tem USB Host para isso. Esqueça o pendrive, implementar a pilha USB host é muito complicada e consumiria muitos recursos do microcontrolador, duvido que conseguiria manter a taxa de transferência mínima para o jogo rodar na velocidade normal. Uma saída seria usar um cartão SD que é infinitamente mais fácil de se interfacear do que um pedrive, mas levando em conta que estará usando uma tabela de arquivos (FAT32), com um pic18 seria muito difícil conseguir velocidades de transferência maiores que 200Kbytes/s. Não sei quanto ocupa o binário desses jogos, se não for muito grande você pode transferir do cartão SD para uma memória RAM externa (existem umas memórias RAM seriais da microchip com até 1Mbit de armazenamento). Agora a emulação vai exigir um poder de processamento grande. Esse projeto que o @vtrx postou dei uma olhada no código fonte e descobri que o jogo não é emulado, todo o jogo está escrito no arquivo 'game.c'. Não sei qual era a velocidade que o processador 6502 do console atari (minhas pesquisas indicam algo entre 1 e 2MHz), mas você vai precisar de pelo menos 16 (chute meu) vezes essa velocidade para dar tempo de ler e executar o conjunto de instruções equivalente.

Essa webcam que você tem não será útil. Os terminais D+ e D- são para o barramento USB. O protocolo USB é bastante complexo e exige um microcontrolador bem poderoso que tenha um periférico USB Host para a comunicação. O módulo que você indicou nesse site utiliza comunicação serial assíncrona que é muito mais fácil de utilizar do que o protocolo USB.

Esqueça essa webcam. Você precisaria de um microcontrolador bem poderoso e com uma interface USB Host para conseguir se comunicar com essa câmera, além de o firmware ficar bastante complexo. Procurei aqui no mercado livre e encontrei algumas câmeras para arduino e encontrei algumas por um preço bem razoável: http://lista.mercadolivre.com.br/camera-arduino. Lembrando que a qualidade delas é bem baixa (640x480) então não espere uma imagem perfeita. Agora gravar vídeo com um arduino comum não tem como. Você precisará de um microcontrolador bem poderoso para comprimir video em tempo real. Acho que existem alguns CI's dedicados para compressão de vídeo em tempo real, mas ainda não procurei.

@MatheusLPS O CodeBlocks é uma excelente IDE, mas não sei como configurar ele para exibir os estados dos periféricos. Mas para o desenvolvimento de programas em C/C++ em um computador ele é bem satisfatório. O emIDE tem exatamente o que eu quero: Só falta um port para linux!

@ O Eclipse comigo nunca deu muito certo, eu acho desnecessariamente complexa para ser usada para o desenvolvimento embarcado. Tive um bug estranho em que os botões de debug ficavam desabilitados sem explicação, a "solução" era restaurar os comandos de cada botão. O Eclipse foi desenvolvido como um IDE para Java, não C ou C++. Gosto de interfaces simples que vão direto ao ponto. Sobre o vim, eu uso emacs, mas ainda não encontrei um plugin que permita usar ele para debugar via gdb + OpenOCD e exibir o estado dos periféricos e registradores de microcontroladores. Já pensei em fazer um port do emIDE para linux, mas não acredito ser algo fácil, mesmo que esteja utilizado wxwidgets, pois utiliza algumas dll's para ter acesso ao debugador. De qualquer forma vou dar uma olhada no código deles e ver o que posso aproveitar.

Não tem jeito. Essa 'ideia' do moto-perpétuo gerador infinito mágico quântico revolucionário nunca morre de uma vez por todas. Tenho que admitir que já considerei essa ideia quando tinha por volta de 11 anos, mas isso era devido a minha ignorância científica. Meu conselho é: Não disperdisse seu tempo tentando quebrar leis da física, tente usar elas ao seu favor e você terá boas chances de desenvolver algo útil. O ceticismo e criatividade andam de mãos juntas para que seja possível o progresso.

Vou ter que me desculpar por não ter postado com muita frequência, mas é que esse ano está sendo excepcionalmente corrido (estágio, vestibular), mas não se preocupem que não vou abandonar esse tutorial. A minha placa STM32F4Discovery chegou faz um tempo, e logo corri aprender a mexer com ela. Consegui compilar e instalar o OpenOCD no meu Debian, e consegui configurar o Eclipse para o utilizar o OpenOCD e o gdb para debugar. Mas não fiquei satisfeito com essa solução, pois o eclipse é uma IDE instável, complexa e lenta. Acabei por aprender como compilar para microcontroladores Cortex-m utilizando makefiles e invocando o gcc pelo terminal, também aprendi como utilizar o gdb pelo terminal para debugar, ficou bem melhor que utilizar o Eclipse, mas tem o incômodo de não mostrar valores dos registradores dos periféricos de forma conveniente (você sempre pode ler o valor de um registrador sabendo o seu endereço, mas convenhamos que isso é deagastante). Estou pensando em desenvolver uma interface gráfica (wxwidgets e c++) para o gdb específica para microcontroladores Cortex-m, que possa mostrar os dados das memórias e periféricos de forma conveniente, mas meu tempo anda curto (tenho essa mania de assumir muito mais coisas do que consigo fazer a tempo). A pouco tempo postei no Linux Questions (para os manjadores de inglês: aqui) pedindo auxílio no desenvolvimento desse projeto. Bom, não tenho previsão de quando vou fazer os próximos posts do tutorial, mas vou deixar alguns links (inglês) que me ajudaram com o desenvolvimento embarcado no linux: http://www.triplespark.net/elec/pdev/arm/stm32.html - Ignore a parte do JTAG já que a placa da ST já tem debugador embutido http://vedder.se/2012/07/get-started-with-stm32f4-on-ubuntu-linux/ - Para quem gosta do Eclipse... http://www.tincantools.com/wiki/GDB_Debugger - Utilizando o gdb com o OpenOCD pelo terminal http://alvarop.com/2013/02/debugging-arm-cortex-m3-devices-with-gdb-and-openocd/ - Tutorial rápido do gdb + OpenOCD http://www.cse.unsw.edu.au/~cs3221/labs/assembler-intro.pdf - GNU Assembler para ARM http://caxapa.ru/thumbs/424855/The_Definitive_Guide_to_the_ARM_Cortex-M.pdf - Livro EXCELENTE sobre o Cortex M0 http://amzn.com/0124080820 - Livro EXCELENTE sobre os Cortex-m3 e m4

Deveria ter comprado essa placa, é monstruosa! Bom, vou tentar configurar aqui o OpenOCD com o Eclipse (não sou muito fã dessa IDE, mas é o que tem por enquanto).

O OpenSDA foi um pouco chato de fazer funcionar, mas consegui (alterando o firmware do debugador), mas ainda não consegui fazer funcionar no linux (hoje é meu SO primário). Olha o que eu encontrei para comprar da china: http://www.aliexpress.com/item/FREE-SHIPPING-Stm32f4discovery-stm32f407-cortex-m4-development-board-st-link-v2/1184124652.html Preço ótimo e frete grátis para o Brasil! O legal do aliexpress é que eles aceitam boleto bancário para pagar! Ainda estou em busca de uma IDE para ARM open source que suporte C e Assembly assim como tenha ferramentas de debug, por enquanto estou com o Keil versão de teste, mas quando eu encontrar uma IDE legal eu posto aqui.

Já já sai post novo (andei meio ocupado essas semanas)! 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.

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

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.

@ 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: 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: * 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...

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: Ó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...

Você diz em relação a posição dos pinos ou o número do pino ter uma função diferente da pinagem convencional? Se for em relação a posição dos pinos, siga o datasheet, já usei vários displays que a a posição dos pinos é diferente. Agora em relação ao número do pino que eu saiba é sempre igual (1:GND, 2:VCC, 3:VEE ...)!