Manual
do
Maker
.
com
Chegamos ao primeiro grande ponto dessa jornada, que é o debug com OpenOCD e GDB para Raspberry Pi Pico. Claro, esse ambiente rodará todo na Raspberry Pi 400, com tenho mostrado nos artigos anteriores.
Quando usamos SWD, a comunicação serial só deve acontecer pela UART, porque a USB é interrompida quando a MCU é paralisada no debug.
Vamos fazer diversas coisas interessantes, mas é fundamental passar por cada etapa para entendermos as ferramentas; não para que nos tornemos especialistas nelas, mas para que saibamos o que estamos fazendo de fato.
Dessa vez vamos utilizar o exemplo hello_world. Já escrevi anteriormente como programar usando o SDK da Raspberry Pi Pico, mas atualmente temos suporte a ela usando a API do Arduino, assim não é necessário ter que aprender mais um SDK. Mas mesmo que estiver começando agora com embarcados, minha opinião é que vale mais a pena usar a API do Arduino porque assim programamos para montes de outras plataformas usando o mesmo padrão. Claro, algumas dessas plataformas tem suas peculiaridades, como o ESP32, que roda um RTOS e com isso contamos com recursos de thread (chamadas 'tasks' no RTOS).
A instalação de pacotes no seu Raspberry está demorando uma eternidade? Pois é, no Brasil as coisas funcionam do jeitinho brasileiro.
Para resolver o problema de lentidão, sugiro trocar o repositório para um mirror de sua escolha. Eu optei por esse:
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bkp
sudo echo "deb https://raspbian.mirror.constant.com/raspbian/ bullseye main contrib non-free rpi" >/etc/apt/sources.list
Se preferir selecionar outro, pode procurar nessa lista. Se não estiver usando a versão bullseye do Raspberry Pi Os, troque para o nome correto. Por exemplo, a versão anterior a ela é buster. No momento a bullseye é a mais atual, mas posteriormente bastará fazer o mesmo; troque para o nome da versão desejada ou mais atual. Mas não troque achando que isso fará seu sistema se atualizar automaticamente.
Se estiver na dúvida de qual é sua versão, faça isso:
egrep 'deb https' /etc/apt/sources.list|awk '{print $3}'
Deverá retornar o nome da versão na linha seguinte:
Depois basta trocar o nome naquele comando mais acima e tudo ficará bem.
Tenha em mente que usaremos OpenOCD e GDB conjuntamente. Partindo do pressuposto que seu ambiente foi configurado seguindo os padrões do artigo anterior, agora vamos instalar apenas mais um pacote:
sudo su
apt-get update
apt-get install gdb-multiarch
O GDB é a ferramenta de depuração, que fará interface com a RPi Pico através da conexão do OpenOCD. Basicamente:
Usaremos agora a conexão serial UART como descrito nos artigos e vídeo publicados anteriormente. Assim sendo, vamos usar o código de exemplo hello_world para fazemos nossa primeira interação com OpenOCD e GDB.
cd ~/pico/pico-examples
cmake -DCMAKE_BUILD_TYPE=Debug
cd hello_world
make -j3
cd serial
make -j3
O firmware estará pronto após o último comando. Se quiser criar seu próprio programa usando o SDK da RPi Pico, basta copiar um dos diretórios de exemplo e então modificar o código. Já expliquei detalhamente o processo em outros artigos sobre a Raspberry Pi Pico, disponíveis no menu RASPBERRY. Mas foco; o firmware está compilado. Ponto.
Agora vamos conectar o OpenOCD ao chip através da interface SWD:
openocd -f interface/raspberrypi-swd.cfg -f target/rp2040.cfg
O OpenOCD está fazendo apenas uma interface com a MCU. Executando esse comando teremos um retorno assim:
O OpenOCD será a ponte entre o GDB e a Raspberry Pi Pico. Agora iniciamos o GDB passando a ele o firmware - que nesse caso deve ser o arquivo .elf, uma vez que o arquivo .uf2 é utilizado para carregamento no modo BOOTSEL.
Chegou a hora do OpenOCD e GDB darem as mãos. O comando agora deve ser:
gdb-multiarch hello_serial.elf
Isso deve retornar algo como:
Agora é hora de nos conectarmos à RPi através do OpenOCD, cuja conexão deve ter permanecido aberta. No console (gdb) que aparece, digite:
target remote localhost:3333
Estava com o blink, daí a mensagem. E agora carregamos o firmware para a flash. Olha que interessante:
load
Agora executamos o programa:
monitor reset init
continue
Se houver erro, lembre-se de fazer o checklist:
Os breakpoints são os pontos em que o programa deve aguardar para seguir adiante. Podemos ter quantos breakpoints quisermos e cada vez que o programa chegar no ponto marcado, o processador pára ali, até que seja informado o next. Mas veremos isso em detalhes, fique tranquilo!
Esse é um exemplo de breakpoint no main, que é a função principal do SDK da RPi Pico:
monitor reset init
b main
continue
Usei o minicom para ler a serial0, conforme imagem abaixo, mas no artigo Debug com Raspberry exemplifiquei vários modos de fazer a conexão serial, inclusive com uma dica de ouro para quem gosta de shell.
Para sair do GDB, usamos quit.
Apesar de não ser complexo, não é a maneira mais prática de se usar debug. Particularmente prefiro dedicar 100% da atenção à resolução do problema quando um bug aparece e ter que prestar atenção no depurador não parece ser uma coisa tão atraente. Mas precisamos passar por isso para entender "ao vivo" como as ferramentas operam e posteriormente usaremos de duas formas diferentes no VS Code; uma, pelo SDK, outra, usando a API do Arduino através do PlatformIO instalado no VS Code.
Espero que esteja gostando da série e, calma, tem muito mais e tem coisas bem mais interessantes por vir.
O vídeo está em produção e deve estar disponível em breve. Enquanto isso, vá se preparando, pegando suas ferramentas de desenvolvimento na Saravati, que tem a RPi 400 e a Pico nesse link. A RPi 400 à vista está com um preço espetacular, não perca a oportunidade!
Se não é inscrito em nosso canal DobitaobyteBrasil no Youtube, inscreva-se. As edições estão cada vez melhores e os vídeos são extremamente curtos, nada de enrolação dando sorrisos falsos e jogando conversa furada para consumir seu tempo!
Inscreva-se no nosso canal Manual do Maker no YouTube.
Também estamos no Instagram.
Autor do blog "Do bit Ao Byte / Manual do Maker".
Viciado em embarcados desde 2006.
LinuxUser 158.760, desde 1997.