Felipe Electronic

Não, essa placa (aliás tem sido praticas comuns nesses kits de baixo custo) ja possui o proprio programador e debugger na placa, basta apenas configurar a ferramenta no ambiente de desenvolvimento que está a usar. Em específico das Freedom, tem a IDE baseada em eclipse fornecida pela própria Freescale, o code warrior e, recentemente, a Freescale libreou um release de uma IDE sem custo baseada no compilador GCC que é o Kinetis Studio, suporta exclusivamente os micros ARM dela, pra quem nao está com saco de compilar e montar o ambiente GCC do zero é uma boa pedida. Abs.

"Pizeiros" que me desculpem, mas a BeagleBone Black é quase o mesmo preço, oferece um SoC melhor e com mais documentação, alem da mesma quantidade de memória RAM. https://www.adafruit.com/products/1876 Além disso existem outros single board computers baratos com SoCs bem superiores, como a Viola da Toradex, que tem um Vybrid (ARM Dual Core, Cortex - A5 ou CA5 + Cortex M4). Abs.

Mas nunca disse que isso poderia ser feito a nivel profissional, aliás para nível profissional existem outras e numerosas opções. As que citei são formas de avaliar e desenvolver seus projetinhos por hobby apresentada pela comunidade open source. Existe um certo misticismo que me preocupa no aprendizado de sistemas embarcados, e isso faço questão de quebrar, é o que tudo é difícil ou complicado, veja que essencialmente o entusiasta não precisa ser um az da computação, ele tem que gostar de pensar, e é isso que muitos aspirantes não gostam ou sentem preguiça, ainda por cima liderados na faculdade ou curso técnico por professores que mais desencorajam do que incentivam o aprendizado, ai cai sempre na tradicional abordagem, começa com PIC ou 8051, depois ve que com o Arduino é fácil subir um webserver com meia duzia de linhas de código, mas na hora que o led nao pisca, puf! O candidato a ser mais uma pessoa feliz brincando com embarcados em casa pega tudo taca numa caixa, pois se do modo fácil nao funcionou, é errado perder tempo aprendendo pelo modo difícil. Nisso eu concordo, mas iniciante por iniciante, não temos entusiastas aos baldes investindo em Arduinos e shields que nunca vão usar? Acho que nesse ponto pouco podemos fazer, vai do bom senso de cada um. Isso é um ponto que quero desmistificar, sabe aquele conteudo visto em faculdade, pro pior e mais esquisito que ele nos é apresentado, sempre existe uma forma de tornar a abordagem fácil, sendo que a primeira é remover logo de cara da cabeça do iniciante que estrutura de dados por exemplo é pra experts (sabe explicação de como funciona memória como gaveteiro de meias, pois é algo do genero). Por isso sou obrigado a discordar que o uso de um projetinho com microcontrolador baseado em um sistema operacional não exige mutio mais conhecimento, alias grande parte dele ja é entendido pelo entusiasta que se mata pra sincronizar todos os eventos de um projeto que desenvolve. Quem disse? Como disse, sistemas embarcados são formadas por diversas áreas de conhecimento, não apenas microcontroladores, lembra o caso do codigo assembly? Ali naquela discussão daria pra explicar de uma vez por todas para alguem como funciona um ponteiro, ponteiros? sim constituem muito sobre o estudo de estrutura de dados, que são base para formar blocos de controle de um sistema operacional. Entende o que digo, está tudo ligado e nao superficialmente, nao que tal conhecimento serve pra fulano mas nao pra sicrano. Ou seja acho que todo mundo do forum pode contribuir, lembra do topico sobre DSP? Ta la paradinho, aguardando a proxima ideia para terminarmos o projeto do analisador. Espero ter expressado melhor o que quis dizer no post anterior mestre. Abs.

Vamos com calma mestre @aphawk Pelo contrário, se encaixaria bem sim, aliás é mais uma ramificação no aprendizado de sistemas embarcados, o RaspPi no caso poderia ser programado em bare-metal, se a broadcom (empresa que fabrica a SoC usada) fornecesse um manual mais decente dele. Mas ate onde sei algumas informações sobre o chip são fechadas. Fazer um programinha para ele essencialmente nao muda o ciclo de design, voce pensa no algoritmo, escreve compila tira os bugs, so que em vez de gravar na memoria flash do micro, voce coloca ele junto a imagem do linux como um módulo estático (ja compilado, so o binario) ou como extensão e linkagem dinamica (a famosa .so presente no linux) onde voce coloca o output gerado pelo seu compilador e o proprio dispositivo compila (ja que a imagem do linux acompanha o toolchain). Além disso, no mundo de sistemas operacionais embarcados, existe diversas distribuições com apenas ferramentas essenciais e o kernel da imagem linux, simplificando o trabalho de embarcar. patchs para que o scheduler do linux rode em tempo real também existe, e tudo isso em grande parcela com codigo aberto, bem feito que você pode modificar e distribuir ao seu gosto. E quem disse que microcontroladores rodam SEMPRE sem um sistema operacional? Veja, um sistema operacional com recursos basico não é nada de outro mundo, prova disso são o FreeRTOS, ucOS-II e outros kernels para microcontroladores de 8 a 32 bits, eu mesmo nos ultimos projetos que estive envolvido, desenvolvi microkernels multitarefa com serviços basicos de um sistema operacional. Programar de forma concorrente e multitarefa é produtivo, expande a visão do projetistas, ajuda na sincronização de serivços ( sabe aquele seu analizador lógico? Perfeitamente factivel usando um sistema operacional de tempo real, e olha só, existe port do FreeRTOS para AVR e ocupa proquissimos recursos de memoria flash e RAM, só que está em C, mas nada impede um estudo em estruturas de dados, escalonamento de tarefas e algoritmos para que voce possa fazer o seu em Basic @aphwak). Minha opinião pessoal do RaspPI, acho legal a iniciativa de ensinar jovens aspirantes a programar sem usar framworks, sim brincar de escrever código, tanto que a PI foi o gatilho para a invasão de mini-computadores embarcados open source baratos e poderosos (Ahhh os Vybrid601x da Freescale). Porém acho seu processador (o nome convieniente é SoC, System on a Chip) bem obsoleto e seu hardware fechado, pelo preço você tem opções mais interessantes com tudo disponivel para voce customizar seu sistema. Particularmente eu paguei mais caro, e comprei uma ZYBO Board, em que sua SoC é um ARM dual core em conjunto com uma FPGA, mais programável impossível. http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,1198&Prod=ZYBO Sou a favor de expandir mais o assunto de microcontroladores do forum, e inclusive a fixação de um tópico sobre computadores embarcados como esse. Abs.

@rodrigocirilo, Isso faz sentido, veja que com comando acima (se bem me lembro como funciona no CCS) voce coloca o terminal do PIC como saída e ele escreve 0 no drive e o fet interno (conectados em push-pull) low side do PIC é colocado em zero, é equivalente com "curto circuitar" a saída do teu sensor de pressão com o 0[V] daí a tensão dele cair a quase zero, e retornar ao valor correto quando voce desconecta do PIC. Se resolveu, pois bem. Abs,.

Não sei se consideraram que a impedância de saída do sensor pode estar acima da impedância de entrada do canal de conversão A/D. Veja, que o pino de input analógico do PIC se bem me lembro possui uma impedância de entrada de 2.5KOhms, veja então que se a saída do teu sensor tiver uma impedância maior que ela a mesma vai se comportar como um divisor de tensão, onde quase todo sinal não é transferido a entrada analógica do PIC. Para verificar se o problema é esse e previnir caso não seja, sugiro que coloque um seguidor de tensão entre a saída do sensor e a entrada do PIC, tal circuito exige apenas um amplificador operacional e mais nada, modelos de uso de geral como LM358 e CA3140 servem perfeitamente para tal, aqui vai uma foto do circuito: Vin é onde deve ser conectada a saída do teu sensor e Vout é conectado a entrada do PIC. Faça o teste e veja se resolve sim. Abs.

Só um alerta, é interessante colocar em paralelo com a bobina do relé um diodo reversamente polarizado (ou seja catodo ligado a fonte e anodo ligado ao coletor do transistor. Essa precaução reduz a chance de destruição do transistor quando ocorrer a comutação do relé (momento em que é gerado força contra-eletromotriz). No mais o circuito é basicamente o apresentado. Segue abaixo uma versão mais completa que vi a muito tempo, mas funciona incrivelmente bem; http://www3.eletronica.org/projetos/interruptor-eletrônico-controlado-por-som Abs.

Desculpe o flood, mas quase esqueci, @Projetos_afg , Compilar o Arm_gnu no Linux e integrar ele no eclipse não rola? É a solução mais sólida que conheço (e pessoalmente estou usando a alguns anos), da um pouco de trabalho, mas você faz somente uma vez? segue o link do arm_gnu: https://launchpad.net/gcc-arm-embedded Plugin para integrar ele com eclipse + suporte a micros da ST (acho que Freescale também): http://gnuarmeclipse.livius.net/blog/ E a ultima versado do Eclipse for C developers: http://www.eclipse.org/cdt/ Acho que vale a pena dar uma olhada Tem passo a passo aos baldes na net. Abs.

@Projetos_afg , Essa plaquinha é a discovery oficial da própria ST, eu tenho uma dessas, e o micro é fora de série, um M4F de 168MHz, porém vou encher ainda mais olhos de vocês com a minha mais recente (e barata!) aquisição, a discovery pro f429 (esse chega a impressionantes 184MHz!): http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090 Custa 24 dólares em quase qualquer lugar... estou rindo a toa com esse LCD e os 8MB de memória externa Sobre o OPenSDA no linux, ja tentou faze - lo funcionar como client gdb junto com o OpenOCD? Hoje tenho uma IDE baseada no Eclipse + GCC rodando no meu MAC de forma nativa, compilei o OpenOCD e ele comunicou sem problemas com os principais debuggers que tenho: TI_ICDI, STLink entre outros Segue o link, veja se o OpenSDA ja é suportado: http://openocd.sourceforge.net/ Abs.

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

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

@Projetos_afg, ta ficando bom esse tutorial hein Alguns comentários, 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. 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

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

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)

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

Tente com algum general purpose como: PIC18f4550, pic16f887 ou 877a são faceis de achar, e devem funcionar com o mesmo algoritmo. Abs!

Vamos la, pensei em algo assim: #define MAX_STEP 0x08 //constante interna para uso #define MOTOR PORTD //por exemplo motor em RD0 a RD3 //declarei como global para facilitar as coisas static unsigned char g_ucCurrStep = 0; //valor corrente do step void interrupt(void) //sua rotina de interrupçao o melhor resultado e quando ela ocorre a cada 10ms { static unsigned char s_ucStep = 0x01; //variavel de step unsigned char ucTemp = 0; //auxiliar //limpa flag de interrupcao: INTCON &= ~(1<<T0IF); //nao lembro os nomes dos bits é bom corrigir //avanca o motor em 1 step: ucTemp = MOTOR; //le o estado anterior do PORT ucTemp &= 0xF0; //mascara os 4 bits nao usado ucTemp |= s_ucStep; //coloca valor do passo atual em Temp MOTOR = ucTemp; //passa o valor para o PORTD e aciona a bobina sem interferir nos pinos do PORTD que nao sao usados //avanca step para proxima interrupcao: s_ucStep <<= 1; //rotaciona o bit para a proxima bobina if(s_ucStep > MAX_STEP) s_ucStep = 0x01; //checa se ja gerou pulso na ultima bobina, se sim volta para a primeira g_ucCurrStep++; //avanca step corrente TIMER0 = Recarga; //voce deve calcular para cada 1ms } //e aqui a rotina para avanço dos steps void stepGo(unsigned char ucStepDesired) { //habilita interrupção do timer 0 INTCON |= (1<<T0IE); while(ucStepDesired < ucCurrStep); //fica travado ate que o Step desejado seja no minimo igual ao corrente //desliga interrupcao do timer 0 INTCON &= ~(1<<T0IE); } Esse codigo é so pra ida, falta fazer a parte da volta bem como criar os flags de direção e precisa modificar conforme o compilador apesar de ser compativel com o C18 e o MikroC pois sao ANSI... Duvidas, pergunte. Abs

Formigoni, excelente trabalho. Os trancos, são provenientes da falta do micropasso, da pra fazer por software. Leia bem o primeiro algoritmo que te passei, ele simula de forma bem interessante um micropasso e nao da trancos no motor. Mas o caminho é esse...existem métodos mais complexos para geração de micropassos... Veja essa app note: http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slva416 Duvidas, va perguntando. Abs.

Driver para LCD 16x2 ou 20x4? Para qual micro? Abs.

Formigoni, a pessoa está certa. Porém a estrutura interna de um pino de I/O de um microcontrolador, ja possui internamente dois push-pull que se combinado em dois I/Os vira uma ponte H com nenhum HW externo, porém so consegue acionar cargas de ate 20mA (com o PIC) e como o motor de cluster drena em torno de 18mA da pra pendurar ele tranquilo no PIC. Quanto ao programa eu acredito que sim pois a sequencia de acionamento vai a ser a mesma no fim das contas. Boa sorte ai, e qualquer duvida va perguntando. Abs

A ideia é bem essa mesmo! Agora tente gerar a sequencia de pulsos que citei no algoritmo, e acredito que teras a melhor solução para comandar motores de passo usados em clusters. Abs.

Formigoni, fiz algo sim, mas utilizando micros ARM, a base do código é a mesma, voce teria apenas que reescrever a parte dos registradores. Ligue no PIC por exemplo Bobina1 A e /A em RB0 e RB1 e Bobina 2 B e /B em RB2 e RB3 Eu utilizo por base o seguinte algoritmo: - Configurar a interrupcao do timer0 para 10ms; - Escolher um port e usar um nibble, no caso escolherei de RB0 a RB3; - RB0 a RB3 --> Saidas; - Carregar em PORTB ou LATB(se for PIC18) inicial 0x01; Aqui termina a inicialização. Agora proceda assim na interrupcao - Limpe o flag de interrupcao - Rotacione o valor de portb, para esquerda (ou direta dependendo do sentido de rotação) - Veja se o mesmo chegou 0x08, se sim reinicie o PORTB escrevendo 0x01; - Repita enquanto quiser girar o motor. Abs.

Mulder, Descontinou, e na minha humilde opiniao mandou para o espaço um dos melhores simuladores de MCU que eu conhecia... O simulador do MPLABX é fraco, possui recursos de interação limitados...fora que a interface mesmo da release é cheia de bugs. E não suporta mais debug pelo ICD2 nem pelo PICKIT2... A unida coisa boa é que ela desenvolveu seus proprios compiladores, e agora prove arquivos startup do assembly para economia de tempo na programação dos fuses por exemplo. Abs

Motores de 4 fios, bipolares são um pouco mais simples. Veja, cada dois polos representam uma bobina, ou seja com um multimetro va medindo os pares usando a escala de resistencia (preferência a de 2K), o par de fios que der um valor de resistencia entre 80 e 200Ohms é uma bobina, separe os pares. Assim, para cada par irao dois sinais A e B, em uma bobina irão A em um fio e /A em outro fio (dois sinais defasados em 180 graus) o mesmo ocorre no B para outra bobina e /B no outro fio da mesma bobina(180 graus) e a defasagem entre os sinais quadrados A e B deve ser de 90 graus...com pulsos de 10ms( para painel de instrumentos tive bons resultados com esse valor). Quanto aos pinos do MCU, pode ligar sim, mas nao esqueça o capacitor de 100n em paralelo com cada bobina para proteger o micro. E veja se a resistencia da bobina esta entre 100 e 200 Ohms...e não teras problemas. Boa sorte. Duvidas, estamos ai

Esses motores bipolares que vem em clusters automotivos possuem uma resistencia de bobina elevadissima! da pra conectar diretamente aos pinos do microcontrolador (que por na tureza ja e uma ponte H) com isso cada lado da bobina vai em um I/O do PIC, ai basta acionar cada uma de forma sequencial, ou seja gerar os pulsos seguintes a cada 90 graus, para inverter o sentido basta inverter a sequencia de geração de pulsos. Fiz testes de acionamento direto com micros da Freescale, e com PIC das referecias 16F877A e 18F452 e funcionou bem legal...com o 629 voce so conseguira acionar um motor ja que ele tem poucos I/O. Duvidas estamos ai. Abs