Uma mão cheia de ARM's

[metRo_]

senso Na atmel tambem tens atmegas de 16 e 32bits! Com fizer um roboxito para servir de base de desenvolvimento até devo usar o xmega (16bits), têm registos para encoders e tudo :p

[senso]

Os pic32 têm core mips, que não tem nada, mas mesmo nadinha a ver com a arquitectura de do tempo dos dinossauros dos pics de 8 bits, os de 16bits tambem já não usam 4 ciclos de relógio para cada operação e em termos de capacidades DSP são muito á frente, mas os ARM são uma loiça á parte de tudo, é timers a pontapé, é ADC's de 12 bits, é DAC's é pwm's até dizer chega, é montanhas de RAM, hardware para lidar com encoders directamente interrupções até ao infinito(e mais além como dizia o Buzz Lightyear lol), cada pino tem mil e uma funções, só lhe falta tirar cafés, RTC's incluidos, são mesmo muito interessantes.
Esta minha coisa dos PIC32 é porque vou ter de usar numa cadeira e por isso ou aprendo ou chumbo, e como pela internet se vê tanta gente que domina mil e um processadores diferentes, não vejo porque não serei capaz de o fazer tambem( isto é que é auto-confiança ).
Actualmente estou mais inclinado para usar o LPCXpresso porque é muito superior á STM32, mas como estou a ver que muita gente vai usar as STM depois eu posto aqui sobre a placa da NXP e voces todos ensinam-me a usar a STM eheh.
Já fiz pedido de 6 chips da ST, ao que parece dos chips de 64 pinos ou mais não dão, mas dos de 48 dão de quase todos os modelos sampes, ponto a favor para a ST.
Quanto a IDE gratuito e funcional, ou usam o attolic true studio ai com os retoques que o Kammutier sugeriu para ficar melhor ou então YAGARTO para cima, tudo o resto não vale a pena estar a aprender porque mais dia menos dia os 32Kb de código que as versões demo compilam acabam-se e depois têm de mudar para outro IDE e regra geral estes programas têm sempre bibliotecas proprietárias e mudar de IDE para IDE pode destruir-vos muito código.

[zordlyon]

Pelo que percebi então para programarem a LPCXpresso usam programação MIPS senso??

Cumprimentos..

[StarRider]

StarRider, dizes que a Keil e a Tasking têm as melhores toolchains mas, para quem nao conhece nenhuma, fica um pouco subjectivo. Será que podias enunciar aspectos positivos e negativos que encontraste na utilização dos IDEs/toolchains que usaste até ao momento? Em termos de usabilidade, preço de licenças, suporte, documentação?

Btw, tambem já tenho o meu STM32 Discovery O problema parece realmente ser as toolchains para isto 

Quanto às samples, já recebi algumas da ST. Da NXP é que tá quieto, não enviam nada.

Boas,

Muitas de vezes olhamos para uma "toolchain" e ficamos pelo aspecto do seu IDE, é de facto um factor importante, mas mais importante do que
isso é a "qualidade" do seu compilador, de nada serve tem um IDE todo "gay" e cheiro de truques e funcionalidades e depois o compilador ficar
pelo caminho.

Na minha opinião existem 3 "grandes" compiladores (e digo compiladores e não IDEs por são coisas diferente) : RealView (ARM), IAR, Tasking e
Keil. Depois temos mais 2 compiladores que são "razoáveis" : GNU C/C++  e  Green Hills

Existem ainda outros como o CrossWorks,  LPCXpresso ( CodeRed),  Raisonance, etc. que quando a mim ainda têm provas a dar. Alguns deles,
como o LPCXpresso por exemplo, estão limitados a um determinado fabricante.

Já experimentei todos os IDEs/Compiladores que mencionei acima, e continuo a usar o Keil desde 2003. Pessoalmente gosto do Keil por várias
razões, desde logo porque é propriedade da própria ARM (se bem que somente desde 2008),  depois porque é o único que tem um wizard que
nos deixa configurar de uma forma gráfica o startup code e a parametrização do uC e seus periféricos, tem simulador de hardware, o seu
compilador é mesmo muito bom, o IDE é simples mas no entanto tem tudo o que é necessário, é possível compilar e "flashar" o uC num único
passo e o próprio IDE tem suporte para ST-Link, ULINK, etc, e é muito fácil incluir utilitários externos para programar o uC como o Flash ISP Utility
da NXP ou o FlashMagic por exemplo.

A documentação do Keil é muito completa, embora por vezes um pouco confusa na versão actual, pessoalmente penso que nas antigas versões
o Help era mais directo. Em termos de IDE, é tudo uma questão de gosto mas sobretudo uma questão de prática, penso que o IDE do Keil por
ter uma apresentação mais simples se torna mais fácil de aprender, por exemplo, o IDE do CrossWorks tem tantas janelas, menus, panes, caixas
e demais coisas que se torna intimidador. A única coisa que não gosto no IDE do Keil, e que está assim nestas ultimas versões, é a cor da caption
da pane activa.

Quer o Keil quer o Tasking tem preços altos, e compreendo que para muito do pessoal aqui do fórum acabam por ser custos proibitivos, mas o
Keil tem uma versão demo que dá para compilar código até 64K se não estou em erro.

O meu conselho é, experimentem o Keil. Usem a "stm32vldiscovery package" que vem com exemplos próprios para o Keil, só têm que abrir os
exemplos, ligar a STM32VLDISCOVERY na ficha USB e compilar. Olhem para código do startup e da parametrização do uC e seus periféricos que
está nos exemplo, com um pouco de perseverança vão ver que passadas umas horas já estão a fazer experiências com a vossa board.

A evolução para ARM, qualquer que seja o IDE/toolchain, é sempre um caminho que requer muita leitura, tenham em atenção quer as diferentes
implementações da ST e NXP nada têm a ver entre si, o core é o mesmo mas os periféricos, registos, endereços, etc são diferentes, por isso
escolham a documentação adequada, quer a NXP quer a ST têm montanhas de info nos seus sites.

Qualquer duvida, e se eu souber responder é claro, podem contar com a minha ajuda.

Abraços,
PA

[metRo_]

Quanto a soluções gratuitas o que aconselhas?!
Outra coisa que me esta a meter confusão, todos esses compiladores é para programar em C?
Cada compilador, por exemplo Keil, disponibiliza bibliotecas para o STM32 podemos programar os registos normalmente? (32bits é coisa que nunca mais acaba)
Compilar tipo avr-gcc, não há amr-gcc? Ou esse é o que indicas como GNU-C/C++?

[StarRider]

Actualmente estou mais inclinado para usar o LPCXpresso porque é muito superior á STM32

Boas,

LPCXpresso ?? Isso é um IDE, acho que queres dizer uma qualquer serie de uC LPC, como os LPC1000 por exemplo.

E já agora,  não queres elaborar um pouco mais sobre isso ? É que existem muitos LPC, desde Cortex-M0 a ARM9 e os STM32 são todos
Cortex-M3, por isso e, segundo a tua experiência, quais, porque e onde é que os LPC são superiores aos STM32 ?

Abraços,
PA

[metRo_]

StarRider Caso saibas será que podes responder às perguntas que coloquei?!
Obrigado

[senso]

Vamos começar por uma ponta, primeiro, todos esses IDE's usam o arm-gcc, o problema é que o desenvolvimento do arm-gcc enquanto projecto open-source parou por volta de 2006, temos algumas pessoas a trabalhar no arm-gcc gratuitamente que é o caso da versão lite do CodeSourcery e do YAGARTO, entre um e outro depois vai um bocadinho dos tutoriais que encontrarem para os meterem a funcionar, mas se calhar apesar do que disse acima o melhor é mesmo o CodeSourcery pois deriva de software profissional e é actualizado de 6 em 6 meses, é muito tempo eu sei, mas é melhor que nada, o YAGARTO ainda não me debrucei sobre ele a sério, o code sourcery como disse acima se forem á wiki do projecto OpenPilot têm lá como montar a vossa toolchain para micro-controladores da ST, o YAGARTO tem a própria documentação no site, se quiserem CodeSourcery recomendo vivamente ler a wiki que já referi um pouco atrás.
Sim, todos os compiladores são para C, é triste e estúpido que todos esses compiladores são baseados em arm-gcc, isso é visivel até nas pastas dos compiladores mas todos usam algumas bibliotecas privadas para acabar com o open-source, se fosse tudo open-source muito provavelmente os compiladores seriam muito melhores que o que são actualmente, isso é bem visivel no compilador dos avr's que é 99% feito pela comunidade e não por empresas privadas.

Depois, para uso pessoal e mais para mim que sou estudante e que tenho mais onde gastar 150€ no minimo para ter uma versão coxa e perneta do Keil com metade das funções desactivadas.

Para o zordlyon e um pouco para o metro_ tambem, ARM programa-se em C, tal como programas um PIC ou um AVR, se já programaram um PIC ou um AVR sabem bem que na datasheet do micro especifico que querem programar tem lá os nomes todos dos registos, se é para um timer pode ser por exemplo TMR1, com os ARM's é precisamente a mesma coisa, vão ao datasheet vêm o registo e escrevem o nome no código, a parte "chata" é que por exemplo só para definir um pino como saida digital simples têm que meter ao barulho um monte de registos, e antes disso tipicamente tem que se tratar basicamente do boot do micro-controlador, configurar PLL's, activar os periféricos que queremos usar e coisas assim, e é nisto que um IDE pago a peso de ouro serve, ele tem Wizards para estas coisinhas(até o CodeVision para AVR tem coisas destas, mas lá está é pago e comparado com o avr-gcc nenhum hobbista que eu conheça o usa).
Mas como os fabricantes até estão a ser bonzinhos, se procurarem na página do fabricante onde estão as App Notes e os Datasheets de cada micro-controlador especifico podem ver que para além de muitas App Notes que ensinam a usar ADC ou USART e coisas assim costumam ter um zip chamado CMSIS que tem muito código de exemplo as vezes até para piscar um led, aconselho a estudar bem esses ficheiros antes de se iniciarem na programação.
Coisas giras, pelo menos o lpc1768 da placa que eu tenho tem registos especificos para fazer o set e o clear atómico de um pino qualquer, o que é muito giro para quem percebe o que quer dizer atómico

Quando me refiro a STM32 e LPCXpresso refiro-me ás duas placas de desenvolvimento de arms que tenho em minha posse e se fores ver o chip lpc1768 é bastante mais capaz que o st32m100xxx que a placa da ST tem, só em termos de clock a placa com o lpc anda a 72Mhz a da ST anda a 24Mhz, a lpc tem 512Kb de flash e 64Kb de ram a da ST tem 8Kb de ram, é nisso que baseio as minhas diferenças, não em toda a gama de chips de cada fabricante.

Acho que respondi a todas as perguntas

[StarRider]

Quanto a soluções gratuitas o que aconselhas?!
Outra coisa que me esta a meter confusão, todos esses compiladores é para programar em C?
Cada compilador, por exemplo Keil, disponibiliza bibliotecas para o STM32 podemos programar os registos normalmente? (32bits é coisa que nunca mais acaba)
Compilar tipo avr-gcc, não há amr-gcc? Ou esse é o que indicas como GNU-C/C++?

Boas,

Todos eles são compiladores de C/C++ e vêm com as librarias ANSI e/ou ISO para o C/C++, alem disso têm headers com defines para ligar os
endereços dos registos a mnemônicas.

No caso dos STM32, tens que puxar a libraria para estes do site da ST no seguinte link:
http://www.st.com/stonline/stappl/resourceSelector/app?page=resourceSelector&doctype=FIRMWARE&SubClassID=1169

Se não quiseres usar a libraria da ST que usa funções de alto nível para "mexer" por ti nos registos que controlam o uC e os seus periféricos,
vais ter que programas tu mesmo esses registos utilizando as mnemônicas acima referidas.

Para o STM32 gratuitas para ser sincero não estou a ver nada, tens o Keil com uma demo limitada a 64k... o que em 32 bits é mesmo muito
código.

Mas tens aqui uma lista de todos os compiladores/IDEs para os STM32:
http://www.st.com/internet/com/software/ides_mcu.jsp

Abraços,
PA

[senso]

StarRider Caso saibas será que podes responder às perguntas que coloquei?!
Obrigado

YAGARTO versão consola:
http://www.yagarto.de/howto/yagarto1/index.html
Yagarto versão eclipse:
http://www.yagarto.de/howto/yagarto2/index.html

CodeSourcery Lite + Eclipse by OpenPilot:
http://wiki.openpilot.org/Flight_Software_Development
http://wiki.openpilot.org/Software_Development_on_Linux
Aconselho a explorar os links que são dados nessa página, MUITO MUITO informativa, do melhor que já encontrei na internet.

StarRider, o Keil não é antes limitado a 32Kb e não a 64Kb, tenho ideia que é 32Kb de código.

[StarRider]

Vamos começar por uma ponta, primeiro, todos esses IDE's usam o arm-gcc, o problema é que o desenvolvimento do arm-gcc enquanto projecto open-source parou por volta de 2006, temos algumas pessoas a trabalhar no arm-gcc gratuitamente que é o caso da versão lite do CodeSourcery e do YAGARTO, entre um e outro depois vai um bocadinho dos tutoriais que encontrarem para os meterem a funcionar, mas se calhar apesar do que disse acima o melhor é mesmo o CodeSourcery pois deriva de software profissional e é actualizado de 6 em 6 meses, é muito tempo eu sei, mas é melhor que nada, o YAGARTO ainda não me debrucei sobre ele a sério, o code sourcery como disse acima se forem á wiki do projecto OpenPilot têm lá como montar a vossa toolchain para micro-controladores da ST, o YAGARTO tem a própria documentação no site, se quiserem CodeSourcery recomendo vivamente ler a wiki que já referi um pouco atrás.
Sim, todos os compiladores são para C, é triste e estúpido que todos esses compiladores são baseados em arm-gcc, isso é visivel até nas pastas dos compiladores mas todos usam algumas bibliotecas privadas para acabar com o open-source, se fosse tudo open-source muito provavelmente os compiladores seriam muito melhores que o que são actualmente, isso é bem visivel no compilador dos avr's que é 99% feito pela comunidade e não por empresas privadas.

Depois, para uso pessoal e mais para mim que sou estudante e que tenho mais onde gastar 150€ no minimo para ter uma versão coxa e perneta do Keil com metade das funções desactivadas.

Boas,

Deve haver por ai alguma grande confusão, arm-gcc é um compilador "publico" que NADA TEM A VER com os compiladores da IAR, ARM, KEIL,
TASKING e Green Hills produzem... nem agora nem nunca na sua historia.

Mais,  todos os demais que mencionei usam o SEU COMPILADOR PROPRIETÁRIO desenvolvido pelas suas empresas.

Existe isso sim muitos IDEs que se "penduram" no compilador gnu arm-gcc pois não têm que pagar direitos sobre o mesmo, mas para uso
em projectos que vão alem de uma simples experiência ou uso domestico é óbvio que temos que recorrer a ferramentas profissionais.

Eu diria que mais vale uma "versão coxa e perneta do Keil" do que uma do arm-gcc completa e a brilhar, é a tal coisa, sem ovos não se fazem
omeletes...e uma versão demo do Keil é mais do que suficiente para qualquer projecto domestico.

Quando me refiro a STM32 e LPCXpresso refiro-me ás duas placas de desenvolvimento de arms que tenho em minha posse e se fores ver o chip lpc1768 é bastante mais capaz que o st32m100xxx que a placa da ST tem, só em termos de clock a placa com o lpc anda a 72Mhz a da ST anda a 24Mhz, a lpc tem 512Kb de flash e 64Kb de ram a da ST tem 8Kb de ram, é nisso que baseio as minhas diferenças, não em toda a gama de chips de cada fabricante.

Acho que respondi a todas as perguntas

Então eu lanço outro desafio, experimenta as duas, por exemplo para ler um encoder de 500 pulsos em quadratura, ou para controlar um
servo com PWM e depois falamos.... nada como a experiência pois na teoria e no papel é tudo um mar de rosas.

Abraços.
PA

[senso]

Eu sei que o lpc1768 tem hardware para ler encoders, pwm's tem uns 14 ou 15 geradores de pwm.

[metRo_]

É esperar que o arm-gcc evolua e que chegue a um ponto como por exemplo o avr-gcc

[StarRider]

Eu sei que o lpc1768 tem hardware para ler encoders, pwm's tem uns 14 ou 15 geradores de pwm.

Boas senso,

Pois o problema é esse mesmo

Os periféricos dos STM32 são superiores aos dos LPC, eu compreendo perfeitamente a tua preferência pela LPCXpresso, e já deu para perceber
que estás dento do assunto, mas acredita que velocidade de clock não é tudo, posso te dizer que ainda recentemente num projecto que
envolvia DSC ("digital setting circles" para indicar as coordenadas RA e Declinação de um objecto celeste) tivemos que mudar o design  a meio do
desenvolvimento do firmware pois o LPC1766FBD100 "falhava" alguns inpulsos do encoder, coisa que deixou de acontecer com o STM32F103.

Mas é claro que existem casos, e cada projecto tem as suas especificações, penso que podemos dizer que a escolha entre um STM32 ou um LPC
acaba por estar dependente de muitos factores, mas todos  têm pontos fortes e pontos fracos.

Abraços,
PA


 

[KammutierSpule]

Estou a falar de cor, mas: Penso que a ST (ou seria a ARM?) estava a tentar "certificar" as suas "librarias"  para um standard de modo a que fosse compatível entre vários fabricantes e talvez diferentes uC.... Alguém sabe ao certo o que é isto que estou a "inventar" ? =)