Blink LED no ESP32 e Zephyr RTOS

ESP32 zephyr
Este post faz parte da série Zephyr RTOS no ESP32. Leia também os outros posts da série:

Este é o segundo artigo da série Zephyr RTOS no ESP32. O primeiro artigo aborda as etapas de instalação, configuração e validação de um ambiente de desenvolvimento que integra o Zephyr RTOS no ESP32. 

Neste artigo, vamos usar aquele ambiente para criar uma aplicação embarcada que, embora trivial, tem o objetivo de mostrar como um projeto Zephyr/ESP32 é estruturado, e também de apresentar alguns conceitos básicos envolvendo o uso de periféricos do ESP32 no Zephyr. Sim, vamos acender LEDs 🙂


Novamente, eu usarei a placa ESP32 DevkitC da Espressif como exemplo. Infelizmente, esta placa não disponibiliza um LED para testes (o chamado “user LED”). Se você tem um placa baseada no ESP32 e que foi montada por outra empresa, a chance de que ela inclua um LED de testes é grande. Do contrário, você pode conectar um LED externamente.

Preparação do Hardware

O resistor (100 Ω a 1 kΩ) é conectado no Pino 2 do DevKitC e o jumper preto no GND. Se a sua placa já vem com o LED, provavelmente o pino 2 não estará exposto (pois está conectado internamente ao LED). Neste caso, a placa é todo o hardware de que você precisa. 

image 1
Figura 1 – hardware utilizado no exemplo

Preparação do Projeto

O Zephyr estrutura e representa os componentes mapeados em memória de um MCU/SoC através de um devicetree. A figura a seguir é um recorte do arquivo esp32.dtsi que encontra-se na pasta zephyr/dts/xtensa/espressif/ e mostra parte do devicetree do ESP32. 

image 22
Figura 2 – Trecho do Device Tree do ESP32

O trecho escolhido não foi ao acaso, vamos usar o nó gpio0 na nossa aplicação. Este nó representa a porta que dá acesso ao pino conectado ao LED. Repare que o device tree tem a informação do endereço base do gpio0 (0x3FF44000) e o tamanho da faixa de memória ocupada (0x800 ou 2 KiB). Outras informações também estão presentes,  por exemplo, vemos que esta porta controla 32 gpios e que pode ser referenciada pelo label GPIO_0. Parte da informação é relevante para a aplicação final enquanto outra parte é utilizada na infraestrutura que dá suporte ao projeto. Repare no atributo compatible do nó gpio0 pois vamos utilizá-lo mais adiante ao escrevermos nossa aplicação.

Eu escolhi criar o projeto na pasta esp32_led dentro da mesma estrutura em que o Zephyr abriga outros exemplos básicos. Para tanto, usei os seguintes comandos: 

Na pasta esp32_led crie uma pasta src onde iremos colocar o código-fonte da aplicação. Vamos também criar o arquivo de build e o de configuração do projeto.

O código fonte

Este é todo o nosso código-fonte. Vamos às explicações por partes.

image 23
Figura 3 – código-fonte do exemplo

Os includes dão acesso aos serviços básicos do kernel do Zephyr, à estrutura de dispositivo genérico usada na inicialização de periféricos, ao Device Tree do ESP32 e às APIs de controle do GPIO. Para acessarmos o nó gpio0 usamos a macro DT_DRV_COMPAT do Zephyr, definimos seu valor como sendo igual ao do campo compatible do nó gpio0 (veja o Device Tree), porém, trocamos quaisquer símbolos não alfanuméricos por underscore ( _ ). Como veremos mais adiante, esta definição permite o acesso ao nó através do seu label. Definimos também um tempo de sleep de 1 segundo e o pino de acesso ao LED.

4
Figura 4 – includes e definições

Em seguida, criamos dev como um ponteiro para um dispositivo genérico, esta é a maneira como drivers são iniciados no Zephyr. Reservamos memória para o dispositivo através da função device_get_binding, note que utilizamos o valor do campo label do Device Tree como argumento do binding. Por fim, configuramos o pino do LED como saída ativa e declaramos a variável led_on para salvarmos o estado atual do LED.

5
Figura 5 – criação e binding do device

Finalmente, o LED chaveia a cada segundo usando o soft-timer fornecido pelo Zephyr, usamos a UART do ESP32 para mostrar o status atual do LED no terminal.

6
Figura 6 – loop da aplicação

Configuração do Build

Nosso CMakeLists.txt é bem enxuto. Se você acompanhou o primeiro artigo da série vai reconhecer ZEPHYR_BASE como uma das variáveis de ambiente exportadas lá (aliás, não se esqueça de exportar as variáveis!), ela aponta para o caminho-base do repositório do Zephyr. 

image 27
Figura 7 – arquivo cmake

A configuração do build também aponta o caminho para o código-fonte, define o nome do projeto e a versão mínima do CMake necessária.

Arquivo de configuração do projeto

O arquivo prj.conf tem só uma linha.

image 28
Figura 8 – configuração do projeto

Ela habilita o uso do GPIO no seu projeto e é tratado pelos arquivos Kconfig existentes na estrutura do projeto. A outra alternativa é usar o menuconfig para habilitar o uso (veja mais adiante).

Build e Teste da Aplicação

Para fazermos o build, ainda da pasta esp32_led, chamamos o comando:

Finalmente, gravamos o binário e checamos o resultado no terminal:

image 29
Figura 9 – resultado da aplicação no terminal

Não deixe de verificar o seu LED também! Lembre-se, se a sua placa já possui um LED de testes montado, ele estará piscando na placa. Se não estiver, troque o valor de LED_PIN pelo utilizado na sua placa.

image
Figura 10 – demonstração da aplicação

Menuconfig

Terminamos nossa aplicação, mas vale uma observação sobre uma ferramenta de interface gráfica extremamente útil que temos à nossa disposição, o menuconfig. Esta ferramenta permite ativar/desativar features em tempo de compilação. Ao invés de habilitarmos o uso do GPIO, ou de qualquer outra feature, usando o arquivo prj.conf podemos, alternativamente, usar o menuconfig.

No caso de GPIO, navegamos até Device Drivers -> GPIO Drivers -> ESP32 GPIO e habilitamos o uso do periférico.

image 30
Figura 11 – tela das configurações do kernel

Na parte de baixo da janela você encontra os principais comandos de navegação, por exemplo “?” abre a ajuda de um campo destacado, “S” salva as mudanças feitas e “ESC” sai da janela atual. Esta é uma ferramenta que vale a pena ser explorada, em projetos maiores você certamente irá ver a utilização de arquivos Kconfig e do menuconfig das maneiras mais criativas.

image 31
Figura 12 – tela com configurações por SoC/MCU

Conclusão

Vimos uma aplicação simples, porém completa, usando o Zephyr RTOS no ESP32. O exemplo cobre os aspectos mais gerais envolvidos na criação de um projeto conjunto Zephyr/ESP32, por exemplo, como o Device Tree pode ser utilizado para fazer referência ao nó desejado, como estruturar os arquivos em um projeto e como utilizar o menuconfig para habilitar features. São diversos os aspectos e detalhes desta integração e não daria para explorá-los exaustivamente neste artigo. Ao menos, espero que o texto sirva como estímulo para um estudo mais aprofundado. 

Até breve!

Outros artigos da série

<< Zephyr RTOS no ESP32 – Primeiros Passos
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.

[wpseo_breadcrumb]
Comentários:
Notificações
Notificar
guest
0 Comentários
Inline Feedbacks
View all comments
Talvez você goste:

Nenhum resultado encontrado.

Séries



Outros da Série

Menu
Privacy Settings saved!
Configurações de Privacidade

Entenda quais dados e informações usamos para ter melhor entrega de conteúdo personalizado para você.

These cookies are necessary for the website to function and cannot be switched off in our systems.

Para usar este site, usamos os seguintes cookies tecnicamente exigidos

  • wordpress_test_cookie
  • wordpress_logged_in_
  • wordpress_sec

Decline all Services
Accept all Services