ASM51

Olá pessoal...

Bem... Eu quero (re)iniciar o projeto de um robô autônomo baseado em um microcontrolador, mas infelizmente não tenho a experiência (e nem posso obtê-la em tão curto tempo) para saber qual seria o microcontrolador que satisfaça alguns requisitos do projeto.

O meu foco é na programação do robô. Gostaria de saber se alguém conhece uma família de microcontroladores que possuam boas ferramentas de desenvolvimento com as quais eu não precise ficar preso em soluções pagas. De preferência algo que possa ser programado em C ou até C++.

Primeiramente pensei em PIC32... Mas é necessário pagar uma licença (MPLAB) quando o código passa de certo tamanho, correto?

O ARM e o GCC, ouvi dizer que não é uma boa mistura, certo?

Gostaria da opnião de vocês

Agradeço desde já!

AVR

bom, se o arm e gcc nao sao uma boa mistura nao sei... conhecendo o gcc, soh digo uma coisa: o problema esta no arm! hehehe

eu usei o gcc com muitos processadores diferentes da freescale e nunca tive problemas: 680x0, 683xx, coldfires e powerpcs. mas o sdcc eh um compilador bom em processadores maiores. para processadores menores existe o sdcc. usei ele no hc908 e tambem nunca tive problemas serios.

em ambos os compiladores o maior problema mesmo que vc vai ter vai ser referente aos mapas de memoria... mas isso nao eh uma falha do compilador, eh uma falha do desenvolvedor hehehe questao de aprender a usar direito os recursos

Agradeço a idéia do AVR. Dei uma pesquisada e parece realmente ser uma boa alternativa. Já que o meu foco vai ser na programação... Quem sabe um Arduíno? Parece ser uma boa idéia

Creio que essa história do GCC acontece porque em alguns casos a empresa investe na produção do back-end do compilador... Talvez eu tenha me expressado errado. Com arquitetura ARM talvez o GCC seja bom... Talvez não seja bom com microcontroladores ARM? Bem, não sei se estou falando porcaria...

Obrigado! Vou dar uma olhada em algo da Freescale também!

Eu ajudei a desenvolver alguns produtos usando ARM, um deles é usado pela CSN e pela Vale, e em todos os casos em que encontrei problemas cabeludos não foram nem no compilador, nem no ARM, mas naquele componente que fica entre a cadeira e o teclado.

Uso o gcc, e se você não precisar otimizar para tamanho de código, não encontrará problemas (as versões mais antigas do gcc fazem um trabalho melhor neste quesito).

Mas voltando ao foco da questão, o problema quase sempre é mais mercadológico do que técnico. Seja AVR, seja ARM, seja MIPS (dsPIC é um exemplo de MIPS, mas até onde pude verificar o custo/benefício é impraticável), seja *o que for*, o mais importante é definir antes o que você quer fazer, o que você pode vir a querer fazer (de modo que você consiga analisar na escolha se a arquitetura é apropriada para os recursos que você talvez deseje implantar no futuro, as vezes você abre mão disto por questões de preço ou incertezas de mercado), e então considerar vários fatores, dentre eles, você pode listar as arquiteturas (ou melhor, as implementações das arquiteturas) e interrogar se cada uma delas:

a) Atende as necessidades técnicas
b) Possuí fácil acesso (incluindo a questão dos $custos$) a ferramentas de desenvolvimento, suporte e material de apoio
c) O custo em tempo e dinheiro do impacto da curva de aprendizado, caso seja uma arquitetura e ferramentas de desenvolvimento com qual o(s) desenvolvedor(es) não possui(em) experiência prévia. Dica: quem programa em C há algum tempo costuma estar habituado a questões envolvidas na portabilidade.
d) Possui fornecedores confiáveis e linha de produtos estável (tem produtos que desaparecem do mercado).
e) Se a errata sheet é maior que o datasheet, desconfie (NXP me vêm a mente. Ops, eu uso NXP, que vergonha)...

... etc.

A resposta a algumas destas perguntas, e outras igualmente fundamentais, muda conforme o volume do projeto e a margem de lucro possível. Antigamente o que era economicamente acessível em baixa quantidade era PIC, cuja arquitetura limitada sempre impediu o desenvolvimento de boas ferramentas de programação (paradoxalmente [ou não], estas mesmas limitações tornam programar em assembler para esta arquitetura um exercício de masoquismo), sem falar que a disponibilidade de ram e memória de programa é mais que limitada.

Mais tarde surgiram os PIC18 e o SDCC que o marcelo mencionou passou a ser uma alternativa para programação em C nesta arquitetura, mas os preços e o monopólio de um grande distribuidor com possível boa margem de lucro tornaram o PIC uma alternativa comercialmente inviável, quando comparável aos outros. Um pic xexelento custa pouco menos que um LPC2368FBD100 (ARM 72mhz com 34k de ram e 512k de flash) aqui no Brasil.

Outra alternativa de baixo custo era 8051. Nenhuma acho que te atende bem, então o negócio é ir pra algo moderno.

Sempre me disseram que o AVR tem bom custo benefício, mas não sei comparar, talvez algum colega possa te ajudar.

o problema eh que o arm hoje eh o windows dos microcontroladores, ou seja, eh uma forma de certos fabricantes sem nenhuma qualidade (os quais infelizmente nao posso citar os nomes aqui, por motivos legais) entrarem no mercado lotado feito um busao e ainda pegarem um lugar na janelinha, sem gastar um unico centavo em pesquisa e desenvolvimento... tem bons produtos com core arm sim, mas isso vc avalia pelos *outros* produtos nao-arm do fabricante... se os outros forem lideres de mercado, o produto com core arm vai ser bom

bom, voltando para o assunto... para robotica mais avancada e sem bugs, tipo o que esse cara faz:

http://www.geology.smu.edu/~dpa-www/rob ... index.html

vc tem q dar um zoio nisso aqui:

http://www.freescale.com/webapp/sps/sit ... H3YTLC6807

que eh um modulo de timers presente em alguns 683xx, coldfires e powerpcs... deixa qualquer microcontrolador moderno no chinelo!

outra referencia boa para TPU:

http://www.eslave.net/tpu/source/source.shtml

para o 68332, em particular, tem varias referencias legais, inclusive software pronto. por exemplo:

http://www.motorobots.org/

q eh uma biblioteca q tem API de acesso ao TPU. em termos de HW, tambem tem muitas referencias:

http://www.seattlerobotics.org/encoder/ ... nst332.htm

mas o 68332, q eh o componente mais simples com TPU, eh um QFP de 132 pinos e requer memoria externa, entao tem q fazer uma PCB para ele. se vc nao precisa de algo muito avancado, melhor usar um mcu menorzinho e mais simples, como jah indicaram.

Eu já fiz um robô de sumô com PIC16 um ano e meio atrás gravando o firmware pela serial(sem debbuger). Foi meio que minha estréia no mundo dos microcontroladores, na época eu nem fazia idéia de como era bom usar um JTAG.

O que mais me incomondava quando estava desenvolvendo o firmware desse robô era ter que carregar ele para perto do computador e ligar o gravador. Por isso atualmente eu optaria por uma plataforma que tivesse um gravador/debbuger sem fio.

Para projeto com complexidade de um sumô ou menos, certamente eu usaria um msp430 com o gravador rf da olimex. Provalmente com a IDE da IAR.

Para um projeto maior eu não sei, mas eu iria procurar uma maneira de gravar/debugar o robô remotamente. Quem sabe um debugger que usar ethernet utilizando um roteador wifi pendurado no robô.


Sobre arm e gcc. Atualmente eu trabalho com STM32(Núcleo ARM Cortex-M3) utilizando a IDE Rowley Crossworks(que usa o gcc como compilador) e o gravador Olimex ARM-USB-TINY.
Estou bastante satisfeito com esse ambiente de desenvolvimento.

O GCC em si é um bom compilador, o problema é que não existe gratuitamente uma interface de debbuger simples e fácil de usar.O Rowley Crossworks e outras IDE´s comerciais implementam sua própria interface e resolvem esse problema.

Se o lance da gravação sem fio não for problema para voce, eu dira que ARM + GCC é sim uma ótima opção. Eu diria támbem que a maioria dos microcontroladores servem para voce, mas opte por um de 32 bits que é bem melhor para fazer calculos.

Fala mais sobre os requisitos do projeto que a gente pode opinar melhor.

Bem... Meu projeto é muito mais acadêmico, talvez as questões mercadológicas não influam tanto na minhas escolha. Mas mesmo assim gostei da visão polesapart, estou ainda com uma ponta de pé em ARM's

Como seria trabalhar com TPU aqui no Brasil? Isso é caro? Acho documentação na Internet? Pelo jeito não achei nada no mercado livre

Confesso que vocês me intimidaram... Hehehe.

O projeto não é tão grande, queria ir fazendo ele em pequenos passos... Sou aluno de Ciências da Computação, o projeto é pro PET Computação da minha universidade, um programa do MEC. O ideal maior seria quem sabe implementar algoritmos de inteligência artificial em um sistema embarcado.

Por falar em 32 bits, me interessei muito no começo por PIC32... Mas o que me levou a tirá-lo do cominho foi justamente as alternativas pagas de IDE (se não me engano o tamanho do fonte/binário produzido pelo MPLAB é limitado)

Falando de mais requisitos do projeto?

Bem... Reforçando que queremos um ambiente interessante e poderoso de programação... Onde possamos criar API's... bibliotecas... Mais pra frente vamos querer armazenamento... Em um pendrive ou SD. Bem... Pra mim ainda é difícil imaginar o que seriam os requisitos de hardware... Sei apenas terei que controlar servos e sensores... Isso tenho idéia de como fazer como fazer Justamente por não haver fortes (avançadas) exigências é que minha preocupação maior ainda é com qual microcontrolador usar para obter essa versatilidade quanto ao ambiente de programação.

Agradeço novamente a todos!

bom, uma coisa q vc precisa verificar eh como tah sua disponibilidade para mexer com HW... mcus maiores como o 68332 sao interessantes pq eh possivel forrar eles com megabytes de memoria, mas tem q rotear PCB e eh tramposo... enquanto isso, mcus simples single-chip vem com aquele tantinho on-chip e acabou, mas eh meio plug-and-play de fazer um HW para eles.

em ambos os casos vc nem precisa meter a mao na massa... tem uns kits relativamente em conta hoje em dia, tipo esse:

http://www.freescale.com/webapp/sps/sit ... LC00M924B2

eh uma placa base de demonstracao com BDM USB integrado e duas plaquinha, uma com um mcu de 8 bits e outra com um mcu de 32 bits. dae vc pode programar e debugar na placa base, sacar a plaquinha com o mcu e plugar na sua placa de aplicacao final, fica bem joia.

o kit parece vem com software e tudo que precisa pela pechincha de 99 doletas. o fato de poder desplugar o mcu e plugar em outra placa eh um bonus interessante.

jah kit com TPU, em principio vc precisa de gcc, uma interface BDM e fechou... e claro, o kit, mas como eh chique e bombadao, soh tem no exterior... por exemplo:

http://www.robominds.com/

q eh o cara da MRM332 q tem em alguns robos q eu citei no outro post, a placa em si custa 90 doletas e o 68332 eh um mcu mais simples e mais antigo, q rende uns 5 ou 6 MIPS... mas que possui muito mais memoria e recursos q um mcu single-chip, incluindo o recurso de TPU.

http://microcontrollershop.com/product_ ... cts_id=804

q eh um cara potente de 144 MIPS com muitos megabytes de flash e sdram, alem de ethernet e eTPU, e permitindo inclusive rodar uclinux, mas custa uns 250 doletas.

tipo, botando os 3 mcus lado a lado, eh como se vc tivesse uma escala de complexidade: vc escolhe entao o mcu certo conforme a complexidade do seu software e hardware. e se precisar de algo maior, nao se preocupe, tem uns powerpc octo-core de 1.5GHz hehehe

Eu acho que o melhor MCU para 8 bits é o AVR, pode ser o Atmega32, atmega64, etc Tem boa quantidade de memoria e perifericos, pode se usar varios MCU destas interligadas por I2C, cada uma executando uma função.
No caso de 16bits o que gostei de trabalhar foi com o MSP430F169 u 149, que vem com boa quantidade de memoria e tem varias portas I/O a disposição para ligar os sensores do robo.
Agora em 32 bits, recomendo algo mais profissional como a linha Coldfire ou MC68xxx como cpu ou MPU, acho que trabalha com mais eficiencia que um generico ARM de 32 bits. Possuindo varias ferramentas gratuitas para construção do codigo em pascal, C e assembler.
Vai depender da sofisticação do seu projeto e da quantidade de sensores que vc quer gerenciar.

meira escreveu:Bem... Meu projeto é muito mais acadêmico, talvez as questões mercadológicas não influam tanto na minhas escolha. Mas mesmo assim gostei da visão polesapart, estou ainda com uma ponta de pé em ARM's

Acho que podemos pensar de trás pra frente; Pense em todos os requisitos externos (fora o microcontrolador) que você precisa, e aí você começa a procurar aqueles µC que te atendam, inclusive considerando que os periféricos internos geralmente são mais fáceis de integrar (menos trabalho de PCB), como o Marcelo citou. Neste critério você pode colocar as ferramentas de desenvolvimento, mas tenho por experiência que uma opinião do tipo "esta ferramenta é excelente" ou "esta ferramenta não vale nada" costuma ser meio pessoal. Pessoas há que foram treinadas em um certo tipo de ambiente e depois não conseguem usar nada fora aquilo; A melhor coisa que você faz é baixar versões de demonstração e dar uma brincada, melhor ainda se tiver um simulador. Isto se você for fazer a maior parte do trabalho sujo (programação e debug), do contrário seria interessante trazer pra esta experiência o pessoal que vai por a mão na massa.

meira escreveu:O projeto não é tão grande, queria ir fazendo ele em pequenos passos... Sou aluno de Ciências da Computação, o projeto é pro PET Computação da minha universidade, um programa do MEC. O ideal maior seria quem sabe implementar algoritmos de inteligência artificial em um sistema embarcado.

Por falar em 32 bits, me interessei muito no começo por PIC32... Mas o que me levou a tirá-lo do cominho foi justamente as alternativas pagas de IDE (se não me engano o tamanho do fonte/binário produzido pelo MPLAB é limitado)

Falando de mais requisitos do projeto?

Bem... Reforçando que queremos um ambiente interessante e poderoso de programação... Onde possamos criar API's... bibliotecas... Mais pra frente vamos querer armazenamento... Em um pendrive ou SD. Bem... Pra mim ainda é difícil imaginar o que seriam os requisitos de hardware... Sei apenas terei que controlar servos e sensores... Isso tenho idéia de como fazer como fazer Justamente por não haver fortes (avançadas) exigências é que minha preocupação maior ainda é com qual microcontrolador usar para obter essa versatilidade quanto ao ambiente de programação.

Agradeço novamente a todos!

A maioria destas rotinas de baixo nível e genéricas (acessar um sistema de arquivos FAT em um SD-CARD pra ler/gravar arquivos, por exemplo) está relativamente bem exemplificada para vários ambientes e microcontroladores, não creio que você tenha muita dificuldade nesta parte.

Quanto aos servos e sensores, acredito que seja tua primeira decisão de projeto, pelo menos onde a pesquisa deve estar mais refinada.

Uma dica que dou quanto ao microcontrolador é prever mais RAM e memória de programa (flash ou eprom, o que for) do que você imagina precisar. Nada pior do que enxugar código as pressas tentando implementar novos recursos.

De resto, não desanime, estas definições iniciais são obscuras mas não são a pior parte, e você precisa estar animado para o que vem pela frente (animador eu não?!)...