18 Comentários

GNU ARM Cross-toolchain – Eclipse + FreeRTOS + GCC – Parte 2

Eclipse + FreeRTOS

Na primeira parte deste artigo foi detalhado o procedimento para a criação de um projeto em C/C++ no Eclipse para uso em sistemas embarcados bare-metal ou baseados em RTOS. Neste post vamos dar continuidade a esse processo e detalhar como configurar esse ambiente para depuração usando GDB e OpenOCD. É obrigatório que o procedimento listado no post anterior tenha sido seguido.

Neste post serão abordados os seguintes tópicos:

  • Quais são os plug-ins necessários?;
  • Cliente GDB e servidor GDB (OpenOCD);
  • Criação da configuração de depuração;
  • Considerações finais.

Plug-ins necessários

O conjunto de plug-ins GNU ARM Eclipse foi instalado no post anterior, cuja finalidade é dar suporte ao cross-toolchain e também ao depurador via hardware e OpenOCD.

Cliente GDB e servidor GDB (OpenOCD)

Assim como os plug-ins, o cliente GDB já foi instalado no post anterior, quando foi instalado o cross-toolchain. O seu binário, arm-none-eabi-gdb, faz parte do pacote do cross-toolchain da Linaro.

Os passos para instalação do servidor GDB, o OpenOCD, foram listados no primeiro post da série GNU ARM Cross-toolchain. Caso não tenha seguido esses passos, execute-os antes de dar prosseguimento a este artigo. Com isso os pré-requisitos já foram preenchidos e podemos seguir com a criação da configuração de depuração.

Criação da configuração de depuração

Antes de utilizarmos o OpenOCD, é preciso indicar no ambiente de desenvolvimento o local de instalação do OpenOCD, já que essa é uma ferramenta externa ao Eclipse. Para isso, siga os seguintes passos:

1) Na barra de menus do Eclipse, clique no comando Window -> Preferences. Vai aparecer a seguinte tela:

2) Selecione o sub-menu Run/Debug -> String Substitution.

3) Crie uma nova variável clicando no botão New. Na nova janela que é exibida, insira o conteúdo abaixo e clique em OK.

Name: openocd_path

Value: /home/<usuario>/work/tools/openocd/bin

Description: OpenOCD

Obs: Substitua o texto <usuario> pelo usuário atualmente logado no PC.

Agora podemos criar uma nova configuração de depuração, seguindo os seguintes passos:

1) Na barra de menus do Eclipse, clique no comando Run -> Debug Configurations…. Vai aparecer a seguinte tela:

2) Selecione o item GDB OpenOCD Debugging na lista que aparece à esquerda e clique com o botão direito. No menu que é exibido, selecione New. Vai ser criada automaticamente a configuração freertos_hello_world Debug, como mostrado abaixo:

3) Pequenas modificações devem ser realizadas com relação à configuração padrão. O conteúdo de duas abas deve ser alterado:

Debugger

Adicionar as opções abaixo no campo OpenOCD Setup -> Other options.

Obs: Substitua o texto <usuario> pelo usuário atualmente logado no PC.

 

Common

Selecione o check-box Save as -> Shared file e adicione o nome do projeto (por padrão esse campo já vem preenchido corretamente).

4) O conteúdo da aba Startup pode deixar inalterado. Confira os valores que são configurados por padrão:

5) Clique no botão Apply para aplicar as mudanças realizadas. Em seguida, conecte a placa STM32F4Discovery na porta USB do seu PC e clique no botão Debug.

O código da aplicação começa a ser depurado com um breakpoint no começo da função main(), como mostra a figura abaixo:

6) A partir de agora podemos depurar o código da aplicação. Seguem alguns comandos:

  • Step Over: Barra de menus -> Run -> Step Over (F6);
  • Step Into: Barra de menus -> Run -> Step Into (F5);
  • Resume: Barra de menus -> Run -> Resume (F8);
  • Suspend: Barra de menus -> Run -> Suspend;
  • Terminate: Barra de menus -> Run -> Terminate (Ctrl + F2).

Caso desejem, podem ser utilizados os atalhos disponíveis na barra de ferramentas da IDE:

Para iniciar uma nova seção de depuração, na barra de ferramentas existe um atalho chamado Debug . Clique na seta e escolha o nome da configuração de depuração desejada. No nosso caso, freertos_hello_world Debug.

Considerações finais

Nesse projeto foi utilizado um debug adapter já presente na placa de desenvolvimento, o ST-LINK/V2. Num projeto real, esse hardware pode ser um equipamento externo à placa do produto, e envolver comunicação JTAG, por exemplo. Nesse caso tem-se que alterar a compilação do software OpenOCD para oferecer o suporte a essa comunicação, ou gerar uma versão desse aplicativo que já forneça o suporte a diversos meios de comunicação.

No final de contas, vale a pena utilizar uma plataforma open-source para desenvolvimento de projetos na sua empresa? Agora chega aquela parte onde temos que avaliar as vantagens e desvantagens desse tipo de ambiente.

Vantagens

  • Não há custo envolvido para aquisição de ferramentas de software;
  • Pode-se criar plug-ins customizados para uma empresa ou equipe, pois o padrão é aberto. Afinal, essa é uma facilidade oferecida pelo Eclipse!;
  • Existem muitos plug-ins para o gerenciamento do ciclo de vida de uma aplicação;
  • Mesmo que não exista o suporte dentro do OpenOCD do hardware utilizado, pode ser utilizado um hardware externo proprietário e associá-lo como uma ferramenta externa à IDE.

Desvantagens

  • O compilador utilizado é otimizado para a plataforma ARM, embora os compiladores pagos geralmente oferecem melhores otimizações;
  • Os ambientes pagos oferecem mais ferramentas de depuração;
  • Por se tratar de um ambiente sem custos, o suporte é oferecido pela comunidade, ao passo que o suporte de uma ferramenta paga traz consigo um suporte mais ágil;
  • O microcontrolador que vai ser utilizado no projeto deve possuir o suporte no OpenOCD (se este for utilizado);
  • As ferramentas pagas geralmente trazem muitos plug-ins para análise de uso de diversos RTOS’s, o que facilita o desenvolvimento, embora exista um plug-in gratuito para FreeRTOS no Eclipse.

Muito bem pessoal, gostaria muito da colaboração de vocês para trazerem sugestões e críticas para tentarmos promover o uso de um ambiente open-source, caso seja de interesse de vocês, é claro! Afinal de contas, é para uso da comunidade!

Artigos da série GNU ARM Cross-toolchain:

GNU ARM Cross-toolchain - Compilação e OpenOCD

GNU ARM Cross-toolchain – Configurando stack e heap

GNU ARM Cross-toolchain – OpenOCD + GDB

GNU ARM Cross-toolchain - FreeRTOS + GCC + STM32F4Discovery - Parte 1

GNU ARM Cross-toolchain - FreeRTOS + GCC + STM32F4Discovery - Parte 2

GNU ARM Cross-toolchain – Eclipse + FreeRTOS + GCC - Parte 1

GNU ARM Cross-toolchain – Eclipse + FreeRTOS + GCC - Parte 2

Outros artigos da série

<< GNU ARM Cross-toolchain – Eclipse + FreeRTOS + GCC - Parte 1
Licença Creative Commons Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.

Receba os melhores conteúdos sobre sistemas eletrônicos embarcados, dicas, tutoriais e promoções.

Software » GNU ARM Cross-toolchain – Eclipse + FreeRTOS + GCC - Parte 2
Comentários:
Notificações
Notificar
guest
18 Comentários
recentes
antigos mais votados
Inline Feedbacks
View all comments
Andre Lopes
Andre
16/12/2014 20:52

Para mim os comandos de depuração (suspend, resume...) aparecem desabilitados, o que pode ser?

Henrique Rossi
Reply to  Andre
19/12/2014 07:14

Olá André,

De pronto não tenho uma resposta assertiva. Talvez algum caminho passado para os executáveis de depuração não esteja correto, ou não esteja ativa a view Debug do Eclipse. Vou testar neste final de semana e tentar encontrar uma possível causa.

Abraços

Andre Lopes
Andre
Reply to  Henrique Persico Rossi
19/12/2014 08:03

Os caminhos estão certos, pois ele está depurando, só o que acontece é que os comandos de depuração estão desabilitados... Já parei o ocd e iniciei de novo, desconectei a placa e conectei de novo e nada...

De ante-mão obrigado pelo retorno Henrique!

Plugado Net
Ernando
07/10/2014 19:26

Olá, parabéns pelo post.

Segui as suas dicas na hora da configuração, porém ao tentar o debug encontro o seguinte erro que pode ser visto nas imagens.

Sabes o que pode ser isto ?

Grato !!!

Henrique Rossi
Reply to  Ernando
09/11/2014 22:32

Olá Ernando, desculpa pela demora na resposta. Vou tentar reproduzir seu erro, mas acredito que tenha a ver com a execução do gdb client, já que o openocd executou com sucesso. Deve ser caminho errado.

Muito obrigado!!
Abraços!

Eduardo Scherrer
Eduardo C. Scherrer
21/06/2014 18:19

Depois de 2 meses, tenho uma placa com o Córtex M4 nas mãos que será a base de alguns produtos da empresa em que trabalho. É até engraçado, mas é muito bom fazer um led piscar, é a prova de que a placa tem uma parte que funciona. Fontes, clock, interface de gravação. Agora é uma questão de tempo para portar as funcionalidades da placa antiga que rodava com um Pic18f e agora está com um Stm32f4 e com freertos.

Henrique Rossi
Reply to  Eduardo C. Scherrer
22/06/2014 18:55

Muito legal Eduardo! Precisamos, no começo do projeto, validar as nossas alternativas de microcontroladores para o desenvolvimento seguinte. Ótimo! Fico contente que o ambiente de desenvolvimento e o bring-up (da "aranha" rs) do seu projeto tenha sido realizado. Agora vem a parte de portabilidade...envolve o conhecimento nas duas arquiteturas. É um trabalho duro, mas acho muito interessante.

Abraços e muito boa sorte!

Eduardo Scherrer
Eduardo C. Scherrer
Reply to  Henrique Persico Rossi
22/06/2014 20:00

Eu já tinha usado o m3 da St em outros projetos por isso tinha um certo conforto em escolhe-lo. Mas a biblioteca que usei foi uma versão anterior. Acho que a principal diferença é me adaptar com o ambiente, pois já usei IAR, MPAB, KEIL, mas o eclipse ainda não tinha usado. Percebi que as outras ferramentas possuem mais facilidades no momento da depuração de código, por exemplo visualizar os registradores dos periféricos do microcontrolador, mas nada que uns breakpoints e umas variáveis auxiliares para ajudar nisso.
Valeu pela força.

Abraço.

Ronaldo Lins
Ronaldo Lins
23/04/2014 10:24

Era de um post como este que eu estava precisando! Mesmo para mim que uso o Windows consegui acompanhar (com algumas adaptações) a linha de raciocínio e instalar o eclipse, compilar e "debugar".
O único problema é que eu não consigo inserir breakpoint com o debug em Running, gostaria de saber se o pessoal que acompanhou o post usando linux tem o mesmo "problema".

Abraços,

Ronaldo Lins
Ronaldo Lins
Reply to  Ronaldo Lins
24/04/2014 15:53

Problema resolvido! Eu havia baixado a versão standard do eclipse kepler (200 MB) e não sei por qual motivo o debugger não funcionava bem nela, mas na versão Eclipse IDE for C/C++ Developers, funciona perfeito,

Grato.

Henrique Rossi
Reply to  Ronaldo Lins
24/04/2014 16:15

Olá Ronaldo,

Desculpas pela demora! Ainda bem que deu tudo certo. Eu gosto muito da interface do Eclipse, acho simples. Ficou legal trabalhar com projetos com microcontroladores lá.

Abraços!

Eduardo Scherrer
Eduardo C. Scherrer
20/04/2014 17:18

Excelente post.

Não tenho conhecimento de outras IDEs open-source.
Portanto achei muito boa por ser open-source.

Abraços.

Henrique Rossi
Reply to  Eduardo C. Scherrer
20/04/2014 23:27

Muito obrigado Eduardo!

Com relação à IDE, gostaria de testar um dia o Kdevelop. Recebi boas recomendações dela.

Abraços

Vinicius Maciel
vinifr
Reply to  Henrique Persico Rossi
29/07/2015 21:45

E qual é a melhor IDE paga na opinião de vocês?

trackback
23/08/2014 18:18

[…] GNU ARM Cross-toolchain – Eclipse + FreeRTOS + GCC – Parte 2 […]

trackback
23/08/2014 17:58

[…] GNU ARM Cross-toolchain – Eclipse + FreeRTOS + GCC – Parte 2 […]

trackback
31/05/2014 22:46

[…] GNU ARM Cross-toolchain – Eclipse + FreeRTOS + GCC – Parte 2 […]

trackback
17/04/2014 00:04

[...] continuação deste artigo será explicado como configurar o ambiente de depuração com GDB e OpenOCD, como foi [...]

Talvez você goste:

Séries



Outros da Série

Menu

WEBINAR
 
Redes Mesh para Monitoramento
e Controle de Sensores

Data: 15/07 às 14:00h Apoio: Artimar| Microchip| Tecsus
 
INSCREVA-SE AGORA »



 
close-link