LusoRobótica - Robótica em Português
Sistemas específicos => ARM => Tópico iniciado por: KammutierSpule em 18 de Agosto de 2010, 03:24
-
Viva!
Alguem por aqui ja experimentou debuggar ARMs, compilador GNU / debuggers/ IDEs, etc..?
Procuro ajuda com os STM32... uhmm
-
Que coincidência. Mandei vir um PRIMER2 (http://www.stm32circle.com/resources/stm32primer2.php) para começar a explorar os mesmos e também ver se são interessantes para a robótica e a loja.
Infelizmente ainda não tive tempo nenhum para o começar a utilizar.
-
Quero no futuro aprender como os arm's funcionam...
-
eu pedi 2 samples da st e 2 samples da texas.. os texas ja chegaram, mas para minha infelicidade sao de 7*7mm.. a ver se tenho mais sorte nos da st, porque nao consigo arranjar pcb pra isso.. ando a fazer uma cnc para fazer pcb's, mas de momento encontra-se em aguas de bacalhau:S
-
Pois, mas não há arms em pdips nem lá perto, só mesmo smd's infelizmente.
Em termos de arms quando tiver tempo e € disponiveis vou antes aproveitar por uma coisinha destas, pelo preço acho que vale a pena:
http://ics.nxp.com/lpcxpresso/ (http://ics.nxp.com/lpcxpresso/)
-
Pois, mas não há arms em pdips nem lá perto, só mesmo smd's infelizmente.
Em termos de arms quando tiver tempo e € disponiveis vou antes aproveitar por uma coisinha destas, pelo preço acho que vale a pena:
http://ics.nxp.com/lpcxpresso/ (http://ics.nxp.com/lpcxpresso/)
Estou a pensar no mesmo, quando for para começar com isso, será uma placa dessas.
-
Eu também não tenho experiência com este tipo de processadores, mas há algum tempo atrás perguntei aqui no fórum sobre os ARM's. Ao mesmo tempo andei a investigar pela net. Acabei por me decidir por algo que suportasse linux porque as ferramentas disponíveis em open-source actualmente são muito poucas e quase todas as proprietárias são para windows em exclusivo. Assim em vez de perder tempo e cabelo a aprender utilizar um ARM, prefiro fazer aquilo que já sei (programar em Linux) e pagar um pouco mais pelo hardware.
A diferença de preço ? Na Watterott o Primer 2 (ARM7, lcd de 128x160, 512KB de flash) custa 66 euros, enquanto um mini2440 (ARM9, lcd de 3.5'', 256 MB de flash, 64 MB de RAM) fica por 120 euros. É quase o dobro, mas as capacidades são bastante superiores e posso desenvolver num ambiente que já conheço.
Dito isto, eu já vou tendo idade em que já não tenho assim tanto cabelo para perder e por isso prefiro os caminhos de menor esforço para onde quero chegar. Mas talvez ainda perca a cabeça e compre o Primer 2. Parece ser tão fixe....
P.S.Tiago, obrigado pela a referência ao Primer 2, que não conhecia e quase me ia apaixonando até ver que as ferramentas de desenvolvimento eram apenas para Windows.
-
Sim, realmente as ferramentas de desenvolvimento limitadas também me "afogam".
Ando à alguns meses (4~5) a estudar o mercado e a analisar desde soluções a produtos ou componentes e ainda não encontrei o que considero ser a board que me falta.
Compreendo quando vais para sistemas embebidos linux, mas para mim não me apetecia tanto.
O que eu ando mesmo à procura e acho que estou quase a encontrar o equilíbrio ideal, é um sistema ARM entre 60~100Mhz programável em C/C++ GNU tools mas com um open real time operating system como o FRTOS ou eCos a um preço interessante e que dispense grande complicação de jtags e gdb para o programar. Acho que com toda esta pesquisa cheguei à conclusão que está na altura de fazer uma plataforma de robótica que satisfaça estas necessidades e que tenha um preço atractivo. O mbed é uma grande plataforma mas como o M3 exige alguma complexidade, eles tiveram que fechar muito algumas coisas para o fazer um concorrente do Arduino para iniciantes.
O que acham? Alinhavam numa solução assim?
-
e o LCDExpresso?
-
The LPCXpresso IDE is available for Windows platforms.
Contudo vou ver de forma mais atenta.
-
Bahhh, não tinha reparado! Ainda por cima eu que agora também estou numa de usar mais Linux!
-
E hoje o meu linux morreu de um reboot para o outro, que raio de coisa :(
Eu penso que existe um certo gcc para arm, que se chama arm-gcc e que até tem algum suporte activo e tal, mas pouco há sobre ele na internet, apesar de tudo acho que a melhor thread sobre o assunto que já li foi mesmo esta:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=89609 (http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=89609)
Vale a pena ler.
-
Sim, realmente as ferramentas de desenvolvimento limitadas também me "afogam".
Ando à alguns meses (4~5) a estudar o mercado e a analisar desde soluções a produtos ou componentes e ainda não encontrei o que considero ser a board que me falta.
O que eu ando mesmo à procura e acho que estou quase a encontrar o equilíbrio ideal, é um sistema ARM entre 60~100Mhz programável em C/C++ GNU tools mas com um open real time operating system como o FRTOS ou eCos a um preço interessante e que dispense grande complicação de jtags e gdb para o programar.
Exactamente o mesmo que eu ando à procura sem encontrar. Há uns tempos vi-me grego por causa de uma placa que não era compatível com o meu programador não standard de AVR's e tão cedo não quero passar pelo mesmo.
Entendo perfeitamente que as empresas queiram ganhar dinheiro a vender sistemas de debug e IDE's todos pipis, mas não estou para pagar por ferramentas fechadas e com funcionalidades limitadas a meia-dúzia de chips.
-
Desculpem desenterrar , mas tenho um STM32 e quero começar a trabalhar com ele . Não sei o que fazer a não ser apenas ir ver o código de exemplos. Existe algum tutorial?
-
COm os exemplos les e pronto, é o mesmo que um tutorial, depois com o datasheet tens o nome dos registos e afins..
Eu disste-te, nem uma USART no Atmega és capaz de ir ver ao manual como se programa, dificilmente fazes alguma coisa com um ARM.
-
http://www.codeproject.com/KB/cpp/STM32_Discovery_Project.aspx (http://www.codeproject.com/KB/cpp/STM32_Discovery_Project.aspx)
-
Mas exemplos com Keil só funcionam com Keil, pois aquilo faz mais de metade com bibliotecas expecificas e tem N menus em que é só point&click e está a funcionar.
-
Mas exemplos com Keil só funcionam com Keil, pois aquilo faz mais de metade com bibliotecas expecificas e tem N menus em que é só point&click e está a funcionar.
Mas basicamente, se queres usar ARM ou outra arquitectura qualquer a 32bits vais ter sempre que usar bibliotecas. Primeiro só o facto de ser 32bits configurar cada registo é muito trabalho e depois o numero de registo existentes aumenta imenso!
-
COm os exemplos les e pronto, é o mesmo que um tutorial, depois com o datasheet tens o nome dos registos e afins..
Eu disste-te, nem uma USART no Atmega és capaz de ir ver ao manual como se programa, dificilmente fazes alguma coisa com um ARM.
Senso , não tem no user manual ? ou programming manual? no stm32 só vi os registos mas acho que tu ja me disseste que nos atmegas tem exemplos.
-
Só para USART e pouco mais..
Isso tem funções de alto nivel até para GPIO, já viste o link que te mandei e o mundo de links que estão nos tópicos?
É que se leres aquilo tens lá pelo menos 5 blinkys diferentes, no site da Olimex na secção de Dev-boards ARM tens mais um blinky com make para compilar e tudo, obvio é que só compila se tiveres a toolchain montada, mas está lá tudo, se instalares o CS num Ubuntu é o que chega.
-
Boas pessoal,
Num ARM (como em qualquer outro MCU seja ele AVR, PIC, 8051, M16, M32, etc) é completamente viável usar todos os periféricos recorrendo somente à manipulação dos registos, para o caso dos UART num ARM não é muito diferente de um AVR, muda o nome dos registos, muda a forma de receber e enviar byte mas no fundo tudo se resume ao mesmo.
O facto de serem registos de 32 ou 98 bits nada tem a ver com a dificuldade, por exemplo, muitos registos dos STM e dos LPC usam somente meia dúzia de bits para controlar os periféricos
Os registos da buffer UART dos LPC (U0RBR e U0THR) ou dos STM (USART_DR) são usados exactamente da mesma forma que o registo UDRn dos AVR.
Pessoalmente acho que o salto de um AVR ou PIC para um ARM é bastante simples se tiverem as bases necessárias, no fundo é tudo a mesma coisa, a inicialização de um core ARM é de facto mais complexa, mas tirando isso é sempre a mesma coisa, configurar os periféricos e usar os mesmos, isto pode ser feito pela manipulação directa dos registos ou recorrendo a funções já existentes em librarias (ou bibliotecas se preferirem).
Os STM32 têm uma lib excelente com funções e macros para configurar e usar todos os periféricos, configurar o core, DMA, clocks, timers, etc, tudo isto transparente para o programador e sem pensar em registos e bits.
Para mim o Keil + STM32 Lib é a solução completa, de tal modo que é usada em muitos projectos dos sub-sistemas da ESA que recorrem ao uso de MCU (não os MCU que podem encontrar no mercado como é óbvio).
Abraços,
PA
-
Eu tenho uma LPCXpresso e uma STM32 Discovery, o ideal para mim será escolher uma delas, pois não compensa estar aprender as duas, vocês têm-se virado mais para ARM da NXP ou ARM da ST!? Muito resumidamente quais são para vocês os pontos fortes e fracos de cada uma.
-
faço a mesma pergunta que o metRo_, o que aconselham?
-
Vêem-se mais projectos com STM32 do que com LPC's, mas acho que a gama da NXP é maior que a da ST.
Provavelmente é porque os poucos tutoriais que há para usar o CodeSourcery são mais virados para a ST, por outro lado para usar as LCP é só instalar o CodeRed, isto se usarem Windows é claro..
-
mas o CodeRed não está limitado a 32kb?
-
128Kb de código, e na realidade não está limitado a nada em termos de código que compila, só no código que programa lol.
Se compilares um ficheiro maior ele só se recusa a programar o chip, agarras no FlashMagic e uma porta serial/ftdi e programas o chip usando o bootloader serial que todos os ARM's trazem e muitos começam a ter bootloaders usb.
-
Tinha ideia que a ferramenta do LCPXpresso estava tambem disponivel para linux :s
-
E têm, acho que tem é algum bugs lol, mas aquilo é gcc e Eclipse não ter para linux seria um pequeno fail.
-
Boas,
Pois é, STM32 ou LPC ? Essa é a grande questão :)
A minha escolha vai para os STM32
A favor dos STM32:
- DMA em alguns periféricos e timers (muito importante pois permite poupar interrupts e ciclos de processamento)
- Conversores AD até 2 vezes mais rápidos que dos LPC
- Sensor de temperatura
- Timers oferecerem mais potencialidades (encoder input, melhor PWM, etc)
- IOs push-pull e open-drain nos outputs
- CRC
- EEPROM emulation
- Excelente biblioteca para periféricos e core com perfeita integração no Keil
A favor dos LPC:
- Maiores frequências de funcionamento
- Timers com capture e compare de 32 bits
- Packages PLCC44 mas somente nos Cortex-M0 (LPC1114)
- Ligeiramente mais baratos
Ambas as implementações ARM têm méritos, mas actualmente a minha escolha vai sem margem de duvida para os STM32.
Abraços,
PA
-
não há LPC com encoder input?! afinal há!
Existe o keil para linux?
Tens conseguido mandar vir samples dos stm32?!
-
não há LPC com encoder input?! afinal há!
Existe o keil para linux?
Tens conseguido mandar vir samples dos stm32?!
Boas,
Sim, mas os LPC com encoder interface somente nas series topo de gama LPC17xx ... com packages LQFP80 e LQFP100.
Infelizmente o Keil só existe para Windows, mas tens o DS-5 aqui: http://www.arm.com/products/tools/software-tools/ds-5/index.php (http://www.arm.com/products/tools/software-tools/ds-5/index.php)
Samples da ST para particulares é para esquecer, somente para empresas ... e mesmo assim têm que ser empresas já com alguma dimensão ... dizem eles.
Abraços,
PA
-
blink no lcpxpresso done :D vou agora passar para o STM32, estou a ver que para linux não vai ser tão fácil então.
Os projectos têm muitos ficheiros etc, etc. Enquanto não aprender a sério tudo o que fizer com aquilo vai ser martelado :D
E confirmo que só mesmo nos topo de gama :s
-
blink no lcpxpresso done :D vou agora passar para o STM32, estou a ver que para linux não vai ser tão fácil então.
Os projectos têm muitos ficheiros etc, etc. Enquanto não aprender a sério tudo o que fizer com aquilo vai ser martelado :D
E confirmo que só mesmo nos topo de gama :s
Estás a usar o Keil ?
Abraços,
PA
-
Tendo em conta que está em linux e que é LPC diria que usou o CodeRed, tens de mostrar ai o código se nao te importares que a minha LPC nem nunca foi ligada ao usb do pc...
-
"Os projectos têm muitos ficheiros etc, etc. Enquanto não aprender a sério tudo o que fizer com aquilo vai ser martelado " Eu quando disse isto estava a falar dos LCPXpresso até porque ainda nao testei o stm32.
-
Não está nada facil conseguir alguma coisa com o STM32 em Linux :s
Do que experimentei até agora aqui estão alguns pontos importantes para mim:
STM32 - Informação muito confusa para utilização do STM32 em linux principalmente por não existir suporte do ST-LINK para linux.
LCPXpresso - Instalando o IDE deles para linux (http://lpcxpresso.code-red-tech.com/LPCXpresso/) foi bastante simples programar com o exemplo blink.
No geral pareceu-me que existe bastante mais informação para os LCP que para os STM32. A ST tem uma familia, STM32W, que possui comunicação ZigBee o que para mim é algo importante.
Para já parece que qualquer um dos dois para uma utilização comercial necessita que pague o compilador/IDE e a pagar então ficaria pelo LPCXpresso pois pelo menos este existe para Linux.
Sugestões!?
PS: Parece que para já o avr-gcc ainda vai funcionar durante muito tempo :)
-
Boas eu tenho um chip stm32f100cb uso linux.
Para gravar o chip uso o bootloader que vem de fabrica uso o comando stm32flash (aqui (http://code.google.com/p/stm32flash/)).
Para quem tem placas STM32VL-Discovery ver este blog link (http://gostm32.blogspot.com/2010/09/converting-stm32-to-boot-mode.html)
Para usar o bootloader que vem de fabrica tem de se configurar os pinos BOOT0=1 e BOOT1=0.
Para compilar uso o gcc(arm-elf-gcc). Vou explicar como fazer uma toolchain para Debian tudo em comandos estilo copy paste atenção ao $(user) #(root).
Antes de mais vamos instalar pacotes deb:
#apt-get install flex bison libgmp3-dev libmpfr-dev libncurses5-dev libmpc-dev autoconf texinfo build-essential
Criar um drirectório em /opt é nessesário ser root
#mkdir /opt/ArmGnu
Agora criamos dois directório um dentro do outro:
$mkdir tmp_arm
$cd tmp_arm
$mkdir tmp_gcc
Download do binutils:
$wget http://ftp.gnu.org/gnu/binutils/binutils-2.21.tar.gz
Descompactar o tar.gz e entrar no directório criado configure make make istall:
$tar -vzxf binutils-2.21.tar.gz
$cd binutils-2.21
$./configure --prefix=/opt/ArmGnu --target=arm-elf
$make
#make install
$cd ..
Agora adicionamos a PATH /opt/ArmGnu/bin
$export PATH=$PATH:/opt/ArmGnu/bin
Vamos até a directório tmp_gcc e fazemos o download do gcc:
$cd tmp_gcc
$wget http://gcc-uk.internet.bs/releases/gcc-4.5.2/gcc-4.5.2.tar.gz
Descompactar configurar e compilar e instalar:
$tar -vzxf gcc-4.5.2.tar.gz
$./gcc-4.5.2/configure --target=arm-elf --prefix=/opt/ArmGnu --enable-interwork --enable-languages=c --disable-libssp
$make
#make install
Se tudo correu bem já temos o comando arm-elf-gcc.
Temos compilador mas não temos libc (podemos sempre ser nós a fazer ou buscar algum lado...).
agora vamos ao blinky led do bolg que vos dei:
$cd ..
$mkdir teste
$cd teste
$wget http://www.robsons.org.uk/blinky.zip
$unzip blinky.zip
$make
Para gravar no chip eu uso usb-serial(fdti)
$stm32flash -w blinky.bin -v -g 0x0 /dev/ttyUSB0
Espero ter ajudado em alguma coisa.
-
Acho que ajudas-te bastante, vou tentar dar uma vista de olhos nisso nos proximos tempos e depois digo alguma coisa :)
Só que por exemplo, por ai não dá para fazer debug on-chip certo!?
-
Sim tens razão não dá para fazer debug on-chip só se for com printf(não é a mesma coisa).
Mas necessitares podes sempre usar jtag e o openocd.
Ou usar st-link com versaloon http://takenapart.com/?p=82 (http://takenapart.com/?p=82)aqui explica o que fazer. (nunca usei este)
-
Ainda não percebi muito bem o conceito do versaloon, é um programador para JTAG, SWD, STLINK, etc?!
@zedlav Se eu arranjar um programador SWD ou assim, posso fazer tudo o que fazes ai, mas depois no ultimo comando em vez de utilizar o stm32flash utilizaria o meu programador para enviar o programa correcto!? De resto a tollchain funcionaria na boa para desenvolver aplicações para o stm32?!
-
Acho que o nome st-link é o hardware que coresponde ao chip mais pequeno na placa, SWD e JTAG além de ser o tipo de ligação(interface de programação) tambem são dois tipos diferentes de protocolo.
No versaloon o que eles fazem é mudar o firmware do chip mais pequeno da placa, não sei se dá para JTAG devido aos pinos(mas não tenho a certeza).
Se tiveres um outro programador SWD podes fazer aquilo que dizes, tens é de ver qual o commando a usar e que tipo de ficheiro esse comando aceita ou bin ou hex (ou outro??). Estuda o Makefile do blinky.zip para poderes mudar para o que te der jeito. Quando conseguires gravar o blinky no teu chip diz-me, para poder passar a segunda parte da toolchain(start files & libc).
-
Acho que o nome st-link é o hardware que coresponde ao chip mais pequeno na placa, SWD e JTAG além de ser o tipo de ligação(interface de programação) tambem são dois tipos diferentes de protocolo.
No versaloon o que eles fazem é mudar o firmware do chip mais pequeno da placa, não sei se dá para JTAG devido aos pinos(mas não tenho a certeza).
Se tiveres um outro programador SWD podes fazer aquilo que dizes, tens é de ver qual o commando a usar e que tipo de ficheiro esse comando aceita ou bin ou hex (ou outro??). Estuda o Makefile do blinky.zip para poderes mudar para o que te der jeito. Quando conseguires gravar o blinky no teu chip diz-me, para poder passar a segunda parte da toolchain(start files & libc).
Mas posso comprar(fazer) a placa que eles têm à venda na versaloon, fico com um programador ou nem por isso?!
-
podes usar o bus pirate para fazer SWD
http://blog.willdonnelly.net/2010/10/02/serial-wire-debugging-the-stm32-via-the-bus-pirate/ (http://blog.willdonnelly.net/2010/10/02/serial-wire-debugging-the-stm32-via-the-bus-pirate/)
-
Agora começas a preceber porque nunca utilizei o ST-LINK, é nessesário ter outro gravador de SWD para gravar o firmware do versaloon na placa STM32VL-Discovery(mcu pequeno) e se usares outra STM32VL-Discovery para gravar vais ter de usar Windows ou usar Linux com outro gravador de SWD como o CBX indicou,
ou usar JTAG(mais complicado mas mais barato com porta paralela) .
A STM32VL-Discovery é uma boa placa e muito barata mas pouco amiga do linux.
-
Então só para ver se percebi bem,
Programar e Debug:
1-Posso usar o bus-pirate e o STM32! (http://blog.willdonnelly.net/2010/10/02/serial-wire-debugging-the-stm32-via-the-bus-pirate/)
2-Posso programar o versaloon no STM32, e apartir daqui o meu ST-Link passa a ser um versaloon! Para programar o versaloon preciso de um programador como por exemplo SWD, e para isso podia utilizar outro ST-LINK mas teria que fazer isto em windows. (http://takenapart.com/?p=82)
Programar:
Definir o bootloader por porta-serie e usar o stm32flash!
Duvida:
No ponto 2 depois de programar o STLINK para versaloon, fico com um versaloon normal que me permitirá programar outros STM32 ou so este?! Isto é, aquele SWD que se encontra no STM32 pertence ao pequeno micro que esta na parte do STLINK ou pertence ao micro normal em que se vai desenvolver?!
Obrigado por toda a ajuda, eu sei que se calhar algumas questões bastaria ir um bocado mais fundo para obter resposta :s
EDIT:
Estive a ver isto: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00251732.pdf (http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00251732.pdf) e os pinos PA9 e PA10 são os TX e RX respectivamente e são ambos 5V tolerant. Estou a pensar então usar o Arduino, já lhe tirei o atmega e ja fiz as ligações do STM32 ao Arduino.
Para colocar o BOOT0 a 1 basta ligar este a 3.3v, certo!? É que o gajo anda para ali com resistências, eu suponho que seja só para tirar os 3.3v dos 5v nada mais, certo?!
-
Programar e Debug:
1- Sim. Podes usar o bus-pirate para gravar o mcu grande(stm32f100rbt6b) usando os pinos SWD, sem nunca estragar o firmware da ST que está no mcu pequeno.
2-Sim. Mas uma vez gravado com o firmware do versaloon o mcu pequeno(stm32f103c8t6) deixa de ser ST-LINK (o software do pc da ST já não pode ser utilizado). Depois de este se tornar versaloon poderás programar ST e outros mcus (de outras marcas desde que o software do pc assim o deixe) que aceitem SWD. O SWD vem substituir o JTAG.
Programar com o bootloader de fabrica:
Exactamente como dizes só não testei a cena dos 3.3 volts liguei com uma resistencia de 2.2k aos 5v.
EDIT: O pino BOOT está ligado ao GND por uma resistência.
-
EDIT: O pino BOOT está ligado ao GND por uma resistência.
Logo tenho que o ligar a 3.3v para ele ficar a 1, certo!?
-
Se ligares a 3.3v directo pode ser que dê, mas não te garanto se não der tenta a resistencia com os 5v.
-
No blog gostm32 tem lá a explicar como alterar o pino BOOT.
Pois, só hoje aqui vim, mas tanto podes usar o BusPirate como SWD ou como JTAG.
No forum avrfreaks tambem tem lá um tópico no offtopic sobre o versaloon que é tipo um urJtag personalizado para meter no chip mais pequeno da placa Discovery e a partir desse momento ficas com um programador SWD, SWD é o mesmo que JTAG mas só com dois fios.
Como já deves agora saber, todos os ARM's saem de fábrica com um bootloader serial gravado numa rom especial que não podes aceder, assim garantem que podes sempre programar o chip.
Acho que compilar um compilador é muito trabalho, basta usar o CodeSourcery lite é instalar e usar.
Quanto aos ficheiros de startup e o loader e o linker o melhor é ou usar os ficheiros que a Olimex dá para a devboard deles, aqui:
http://olimex.com/dev/soft/arm/ST/Eclipse-GCC-project-for-STM32F103.zip (http://olimex.com/dev/soft/arm/ST/Eclipse-GCC-project-for-STM32F103.zip)
Se tiveres o CodeSourcery é só fazer make, mas como o chip da Discovery é o 100 tens de alterar algumas coisas, mas é relativamente simples, outra fonte para esses ficheiros prontos a usar é sacar o Atollic TrueStudio e tirar de lá tudo o que é relacionado a chips ST, já tem as funções básicas para SPI, i2c, pwm, adc, dac tudo feito pronto a usar.
Zedlav, não tens os scripts para o linker e o startup bons para usar com a Discovery?
-
Tenho. O que vem no blinky tem um bug com strings.
-
Pois, é por isso que me afastei dos arm's enquanto não estiver nas férias de verão, para além de ser uma nova arquitectura é preciso batalhar com a toolchain..
-
Eu neste momento por ter o STM32 discovery kit e o LPCXpresso estou a começar a testar uns hello worlds etc, começar a conhecer alguns termos e perceber +- como funciona pois também neste momento por causa da faculdade não há muito tempo livre. No verão há em mente o controlador para um avião autónomo(desta vez já comecei a comprar algumas coisas :) ) e algo mais rápido e potente que um atmega8 vai dar jeito principalmente para obter uma boa parte de controlo e com frequências aceitáveis. Passar para um xmega tambem não me parece opção embora pareçam bastante interessantes pois a nivel de preço deixa mesmo de compensar, pelo menos é a ideia que tenho.
-
Os Xmega vapourware durante 2 ou 3 anos, o suporte no compilador ainda é assim tipo hit and miss, o hardware está uma desgraça, o ADC tem de se usar mil e um remendos em software só para trabalhar para além de que a errata vai tipo na revisão H e nada foi corrigido no hardware, são caros como tudo e comparado com um ARM, bem é para esquecer mesmo.
Para além de que precisas de um Dragon ou de um AVRISPMK2 para fazer PDI para os programar porque tinham que inventar um protocolo novo para os programar, e tambem não têm usb, só serial.
Eu já aqui tenho uns quantos STM32F103 quando tiver tempo é para eles que vou olhar, 72Mhz powa lol, e os poucos tutoriais que há nas nets sempre são para esta gama.
Quando houver algum conhecimento aqui no forum sobre eles acho que deviamos fazer uns tutoriais conjuntos entre todos os menbros.
-
Não tinha essa noção dos Xmega, pois a nível dos atmegas mais baixo, atmega8 ou por exemplo attiny acho que são bastante bons.
Não sei quando me vou decidir em relação ao STM32 ou ao LPC, acho que a informação para o LPC é bastante mais organizada.
Tu estás a usar linux ou windows para programar os STM32!
PS: Os LPC parecem-me bem mais baratos :s acho que se não fosse a família STM32W e me decidia pelos LPC!
-
Se procurares no avrfreaks está lá um tópico na primeira ou segunda página do offtopic com 6 ou 7 páginas com todas as falhas dos atxmega.
Tem mesmo mutias falhas.
Actualmente, nem windows nem lunux/ubuntu, tempo de universidade, só passo tempo com os avr's.
Acho que devias antes optar pelos chips da Nordic para a parte do Rf porque juntar RF com um bom protocolo tipo ZigBee e mais processamento para a aplicação dá barraca, a stack do zigbee é relativamente pesada e vale mais ter as coisas separadas que tudo junto a correr e ver quem acede ao processador primeiro.
-
isso será para outro projecto, rede de sensores em que cada nó não terá muito que fazer para além de ter o protocolo zigbee e alguns sensores e assim algo tudo no mesmo chip facilita quer no desenho da placa, consumo e BOM, só que já que vou aprender alguma coisa que depois dê para aplicar noutros projectos. Já estive mesmo para comprar os atmega128rfa1 que aparentemente me parecem bons mas depois a minha consciencia diz que tenho a faculdade e a verdade é que estou quase no final :)
-
Não estou a conseguir usar o stm32flash, estou sempre a receber o erro:
ze@ze-KPC:~/teste$ sudo stm32flash -w blinky.bin -v -g 0x0 /dev/ttyUSB0 -b 115200
stm32flash - http://stm32flash.googlecode.com/ (http://stm32flash.googlecode.com/)
Using Parser : Raw BINARY
Serial Config: 115200 8E1
read_byte: Success
stm32flash: stm32.c:90: stm32_read_byte: Assertion `0' failed.
Aborted
Alguma sugestão!? :s
-
Já está :D Não tinha lido a parte do RESET :p
-
Podem me dizer onde está o tal manual de 900pág do M3?
Estou a começar a brincar com o discovery e não sei o que fazem uns registos
-
É o reference manual ou coisa assim o manual especifico do chip diz onde o ir buscar.
-
Esse eu tenho, mas não tem lá o que quero. Não faz mal..
Os nomes dos registos são iguais tanto para NXP como para o STM32?
Tenho aqui um livro em português para AMR7 da NXP, mas os nomes são diferentes :(
-
ARM7 é uma arquitectura completamente diferente de cortex m3.
O manual chama-se:
RM0041: STM32F100xx advanced ARM-based 32-bit MCUs
E tudo sobre o micro que está nessa placa está aqui:
http://www.st.com/internet/mcu/product/216844.jsp (http://www.st.com/internet/mcu/product/216844.jsp)
Não garanto que o link funcione muito tempo que a ST anda sempre a trocar os links todos.
-
Tenho um lpcxpresso com o LPC1114:
No lpcxpresso ide montei um projecto para testar a placa e quando declaro o seguinte: GPIO0_IODIR |= (1 << 7); o ide diz que o registo não está declarado. Será que tenho de adicionar algum header?
Cumps :D
-
Viva,
alguém sabe como contornar o HardFault_Handler ? todo o codigo que faço por mais simples que seja dá-me esta coisa, assim não estou a conseguir evoluir >:(
-
Isso é um trap para erros, logo alguma coisa estás a fazer mal.
-
é o loop ser infinito..
ele dá erro após decrementar o primeiro delay passa de 0x00000001 para 0x00000000 e bloqueia..
o ciclo da main é este:
while(1)
{
Delay(10);
GPIOC->BSRR = (1 <<9);
Delay(10);
GPIOC->BSRR = (1 <<25);
}
// end while
} // end main
void Delay(unsigned int nTime)
{
while(nTime > 0)
{
nTime--;
}
}
-
Mete breakpoints nisso ou prints por serial e vê se é o delay ou se é a manipulação dos registos que rebenta.
-
já tive a meter e corri o código passo a passo..eu disse mal em cima é quando nTime passa de 0x00000001 para 0x00000000 e bloqueia logo, não salta para a main.
Eu tenho o um startup (STM32F10x.s) diferente daquele que vem nos exemplos do discovery (startup_stm32f10x_md_vl.s) mas supostamente deveria ser igual não?
-
Provavelmente é a stack mal configurada, o primeiro return que ele tem de fazer rebenta-se todo.
Por isso é que deixei os ARM's de lado por enquanto, ter que inventar com linkers, loaders e startup's, no fim disso tudo não se sabe se o bug é um erro no código, se é o linker que está mal feito, ou se é o startup que nem inicia o chip como deve ser, ou usas um bom IDE ou é como caçar gambuzinos.
-
Acredita, e isto é uma coisa básica e empancar aqui é uma desmotivação para não ir para a frente.
Eu estou a usar a versão lite do Keil e até estou a gostar.
Vou continuar a martelar nisto a ver se vai dar algum lado.
-
já agora aproveito para perguntar se alguém conhece um bom livro ou ebook de preferência em Português sobre cortex-m0\m3 da NXP?
-
Penso que existe algures na net um ebook sobre cortex m3.
m0 axo que ainda há muito pouco.
os processadores são da ARM e não da NXP, por isso não faz sentido ser especifico para o NXP.
Só tens interesse em ler coisas sobre cortex, se fores desenvolver cenas muito lowlevel para ARMs (exemplo: sistemas operativos, codigo em assembly, codigo muito optimizado.. eventualmente bootloaders?)
De resto, basta ler a documentação do fabricante do microcontrolador e info o compilador e exemplos.
N vejo necessidade para mais.
-
faz sentido pois os registos são diferentes dos demais e estou a usar as bibliotecas do LPCXpresso
de qualquer maneira tenho-me desenrascado a ler os comentários dos exemplos, a duvida que tinha (para já ;D) acho que já percebi mais ou menos como é que funciona, mas um esclarecimento adicional, ainda que em inglês era bom
já agora, já alguém separou o LPC-Link da target board?
-
Mas essas duvidas tiram-se é com o user manual da familia e com o datasheet especifico de cada chip, não é com livros de contar históriazinhas.
-
Eu ainda não separei.