FAVORITAR
FecharPlease login

NuttX: Criando (ou Copiando!) uma Aplicação para o NuttX

Desenvolvendo um Projeto com Aplicações Existentes

Este artigo faz parte da série Primeiros Passos com o ESP32 e NuttX e mostra como aplicações podem ser criadas, adaptadas e integradas ao NuttX, facilitando o uso de códigos já existentes. Especificamente, será integrada ao NuttX a aplicação RTP Tools como uma continuação do projeto Servidor de Som: Raspberry Pi + Home Theater DIY. A utilização do RTP Tools será explorada mais adiante no artigo.

O processo de compilação de uma aplicação no NuttX, seja ela uma aplicação própria ou uma já existente em outros sistemas operacionais, segue os princípios do sistema de build do NuttX. Embora a documentação do NuttX aborde aspectos do processo de compilação de aplicações, exploraremos algumas opções desta etapa mais profundamente neste artigo.

Para quem não estiver habituado com o NuttX, recomendo a leitura dos artigos Primeiros Passos com o ESP32 e o NuttX e O que é o RTOS NuttX e por que você deve se importar? ou, ainda, o Getting Started da documentação oficial do NuttX. Estes documentos destacam o grande diferencial do NuttX: ser um sistema “POSIX-compliant” permite que muitas aplicações sejam facilmente integradas ao sistema. Com isso, vale aquela máxima: “Não reinventem a roda. Alguém já deve ter desenvolvido uma aplicação para resolver seu ‘problema’”! Neste sentido, o desenvolvimento de um produto com o NuttX é extremamente facilitado ao aproveitarmos aplicações e bibliotecas comumente utilizadas que podem ser adaptadas sem grande esforço ao NuttX (se, é claro, isso já não tiver sido feito antes). Desta forma, o desenvolvedor pode concentrar-se no desenvolvimento da aplicação fim do produto a partir de aplicações e bibliotecas largamente testadas, validadas e com vasta documentação disponível.

Neste artigo explicamos como aplicações e bibliotecas podem ser integradas ao NuttX através do sistema de build e, partindo dessa explicação, iremos integrar da aplicação RTP Tools para o NuttX. Esta aplicação é, na verdade, uma série de utilitários que, dentre outras coisas, permite receber pacotes RTP (Real Time Protocol) pela rede. A aplicação que utilizará o RTP Tools será posteriormente detalhada em outro artigo, que será a continuação de Servidor de Som: Raspberry Pi + Home Theater DIY. Adiantando um pouco o assunto: já pensaram que legal seria fazer de um ESP32 um servidor de som de baixíssimo custo e alta-fidelidade? Pois bem, talvez precisemos do RTP Tools pra isso 😉

No dia 25 de Junho de 2024, ocorrerá o “Seminário de Sistemas Embarcados e IoT 2024“, no Holiday Inn Anhembi — Parque Anhembi, São Paulo–SP.

Garanta seu ingresso

Criando uma Aplicação no NuttX

As aplicações do NuttX são separadas do código-fonte do kernel do sistema operacional. Assim como em outros sistemas operacionais, elas interagem com o kernel do NuttX através de APIs públicas compatíveis com o padrão POSIX. Vale a pena observar, porém, que as aplicações precisam utilizar o build system do NuttX para serem agregadas ao firmware final. Para essa finalidade, o projeto Apache NuttX disponibiliza também o repositório nuttx-apps, que é um compilado de aplicações que estão disponíveis para serem compiladas no NuttX. As aplicações e bibliotecas disponíveis neste repositório são públicas e podem ser utilizadas por qualquer usuário da comunidade. O NuttX fornece, também, meios de compilar aplicações fora deste repositório, permitindo que aplicações proprietárias (e, por vezes, não públicas) sejam agregadas ao sistema.

Nota: não é toda aplicação que precisa ser disponibilizada publicamente no nuttx-apps. É possível manter aplicações não públicas, mas isso é assunto para outro artigo (ou, se estiver muito curioso, consulte a documentação oficial).

Hello World!

A aplicação mais utilizada como exemplo por sistemas operacionais e linguagens de programação é, talvez, o “Hello World!”: uma aplicação que imprime estas palavras na interface com o usuário. Com o NuttX não é diferente e esta aplicação pode ser encontrada em apps/examples/hello, de nuttx-apps.

A seção Application Configuration File (do repositório nuttx-apps) e a seção Extend the apps/ directory to include a new custom directory, do guia “Custom Apps How-to” (da documentação oficial) explicam um pouco do sistema de build do NuttX e, principalmente, de como agregar uma aplicação ao NuttX. Com base nestes documentos, explicamos aqui sobre a compilação da aplicação Hello World!.

O diretório apps/examples/hello contém os seguintes arquivos:

O arquivo hello_main.c é o código-fonte da aplicação. Os demais estão relacionados ao sistema de build do NuttX, que configura e seleciona esta aplicação para que seja compilada e agregada ao NuttX.

O Sistema de Build

O NuttX utiliza o kconfig-frontends (ou, mais recentemente, a kconfiglib) para gerar o arquivo de configuração do NuttX (.config) no diretório raiz do repositório do sistema operacional do NuttX. Por exemplo, ao compilar o exemplo do Hello World!, uma das opções que este arquivo terá é:

Mas, de onde vem esta opção e como registramos esta aplicação para ser compilada no NuttX?

Kconfig

A configuração CONFIG_EXAMPLES_HELLO=y é disponibilizada para ser selecionada pelo sistema de build através do arquivo apps/examples/hello/Kconfig do repositório de aplicações. Assim, é este arquivo que – através da linha config EXAMPLES_HELLO (como veremos a seguir) – permite que o sistema de build do NuttX saiba da existência dessa aplicação. O arquivo Kconfig da aplicação Hello World! possui o seguinte conteúdo:

Vale notar que todas as opções adicionadas pelo Kconfig terão o prefixo CONFIG_ quando acessadas pela aplicação e outros arquivos de build. Por exemplo, o valor da configuração EXAMPLES_HELLO_PROGNAME poderá ser acessado utilizando a definição CONFIG_EXAMPLES_HELLO_PROGNAME. Essas definições estão disponibilizadas para aplicações através da inclusão do header nuttx/config.h.

Make.defs

Com base nesta configuração, o sistema de build do NuttX incluirá o arquivo apps/examples/Make.defs que, por sua vez, adiciona o diretório apps/examples/hello à variável CONFIGURED_APPS da seguinte forma:

Uma vez adicionado o diretório da aplicação à variável CONFIGURED_APPS, o arquivo apps/examples/hello/Makefile é incluído no sistema de build.

Makefile

Finalmente, o arquivo apps/examples/hello/Makefile fornece as diretrizes para compilação da aplicação no NuttX. Para o Hello World!, o conteúdo do arquivo é:

Note que a receita (o arquivo Makefile) define algumas variáveis como, por exemplo, PROGNAME, PRIORITY, STACKSIZE e MODULE. Estas variáveis são definidas por valores configurados pelo Kconfig.

No entanto, o mais importante é a definição da variável MAINSRC, que define qual será o arquivo fonte (.c) a ser compilado (no caso, hello_main.c). Observe que, embora não presente neste exemplo, outras variáveis podem ser definidas, como CSRCS, que inclui outros códigos C auxiliares, e ASRCS, que inclui arquivos assembly (*.asm), por exemplo.

A Aplicação de Exemplo

O último arquivo no diretório apps/examples/hello é, finalmente, o código fonte da aplicação. O conteúdo de hello_world.c é o seguinte:

Observe que o código fonte desta aplicação não necessita de nenhuma alteração para ser compilado quando comparado a qualquer outro sistema operacional com suporte à linguagem C e a POSIX. O ponto de entrada da aplicação é definido de modo semelhante, sendo representado pela função main().

Integrando Aplicações Externas

O exemplo Hello World! é uma ótima introdução de como o sistema de build do NuttX permite a compilação de aplicações de forma rápida e simples. No entanto, note que o código fonte da aplicação (hello_main.c, no caso) está integrado ao repositório de aplicações e, assim, poderíamos inferir que a aplicação de exemplo foi escrita para o NuttX (embora seja muito semelhante a uma aplicação genérica). Assim sendo, vamos explorar nesta seção a integração de uma aplicação/biblioteca externa cujo código fonte tenha sido concebido – originalmente – para outros sistemas baseado em Unix. Sendo assim, como poderíamos compilar no NuttX, por exemplo, o Mbed TLS?

Mbed TLS

O repositório do Mbed TLS a define como, em tradução livre: “Mbed TLS é uma biblioteca C que implementa primitivas criptográficas, manipulação de certificados X.509 e os protocolos SSL/TLS e DTLS. Seu pequeno tamanho de código o torna adequado para sistemas embarcados”. Ou seja, o Mbed TLS é uma biblioteca que, embora possua aplicações próprias, fornece funções criptográficas que podem ser usadas por outras aplicações. Vejamos como ela pode ser integrada ao NuttX!

O diretório apps/crypto/mbedtls/Makefile do repositório de aplicações contém os arquivos que permitem compilar esta aplicação no NuttX:

Observe que não existe nenhum arquivo fonte (.c) ou de cabeçalho (.h) presente neste repositório! Isso é possível porque o código fonte do Mbed TLS é baixado para ser compilado somente quando a aplicação é selecionada no sistema de build do NuttX. Mas como?

Makefile

O arquivo Makefile disponibilizado no diretório de cada aplicação, além de definir variáveis utilizadas na compilação da aplicação e do sistema NuttX, permite também escrever (e sobrescrever) receitas comumente utilizadas em arquivos Makefile (caso necessário, consulte o manual da aplicação make). Observe o conteúdo do arquivo apps/crypto/mbedtls/Makefile:

Baixando o Código Fonte

De acordo com a seção Built-In Applications (do nuttx-apps), em tradução livre:

“A compilação ocorre em várias fases conforme diferentes destinos de compilação (targets) são executados: (1) contexto (context), (2) dependência (depend) e (3) padrão (todos/all). As informações do aplicativo são coletadas durante a fase de compilação do contexto”.

Note que a receita context é sempre executada pelo sistema de build do NuttX e, geralmente, é ela que prepara a compilação de uma aplicação. Para esta aplicação, do Mbed TLS, ela é dependente do arquivo definido por $(MBEDTLS_UNPACKNAME), que é dependente de outro arquivo definido por $(MBEDTLS_ZIP) que, por sua vez, é baixado pela receita:

Desta forma, o sistema de build é capaz de baixar um arquivo compactado que contém o código fonte do Mbed TLS diretamente do repositório do próprio projeto. Uma vez baixado, este código será descompactado em uma pasta e estará disponível para ser compilado e integrado pelo NuttX.

Aplicações e Biblioteca

Diferentemente do exemplo anterior, podemos observar que este Makefile acrescenta arquivos fonte também à variável CSRCS:

Desta forma, arquivos fontes da pasta library do Mbed TLS são adicionados à variável CSRCS. Ou seja, arquivos da biblioteca do Mbed TLS serão compilados apesar de não serem – propriamente falando – aplicações executáveis. A biblioteca do Mbed TLS fornece APIs de criptografia a outras aplicações do sistema. Mas, de modo a testar as funcionalidades da biblioteca, o repositório do Mbed TLS fornece também aplicações de teste, que podem ser ativadas através das configurações em apps/crypto/mbedtls/Kconfig. O registro da aplicação executável de benchmark é realizado na seguinte seção do arquivo Makefile:

Esta porção do Makefile compila, se selecionado, a aplicação de benchmark do Mbed TLS. Observe que, se CONFIG_MBEDTLS_APP_BENCHMARK=y, o código fonte em [programs/test/benchmark.c](https://github.com/Mbed-TLS/mbedtls/blob/v3.0.0/programs/test/benchmark.c) será acrescentado à MAINSRC. De forma semelhante, a aplicação de auto-teste em [programs/test/selftest.c](https://github.com/Mbed-TLS/mbedtls/blob/v3.0.0/programs/test/selftest.c) pode ser compilada se CONFIG_MBEDTLS_APP_SELFTEST=y.

Kconfig

O arquivo Kconfig do Mbed TLS, por exemplo, seleciona – além da versão da biblioteca a ser baixada – as aplicações de teste que também serão compiladas. O conteúdo do Kconfig pode ser visualizado a seguir:

Make.defs

Finalmente, o último arquivo presente na pasta é o Make.defs. A grande diferença em relação ao arquivo do exemplo Hello World! é que ele disponibiliza os arquivos de cabeçalho (.h) da biblioteca do Mbed TLS para serem usados por outras aplicações do NuttX, adicionando-se o conteúdo da pasta mbedtls/include do Mbed TLS às variáveis CFLAGS e CXXFLAGS do sistema de build do NuttX:

RTP Tools

Agora que temos uma ideia de como uma aplicação externa pode ser integrada ao NuttX, podemos integrar o RTP Tools ao NuttX (e, claro, disponibilizá-lo para os demais usuários do repositório nuttx-apps).

Segundo o próprio repositório do RTP Tools, em tradução livre: “O RTP Tools deve compilar e executar em qualquer sistema compatível com POSIX, bem como no Windows. Alguns sistemas operacionais também fornecem um pacote pré-compilado do RTP Tools. No UNIX, o usual ./configure && make deve funcionar”. Esta passagem nos traz algumas informações. A mais importante é o fato da biblioteca ser compatível com sistemas que adotam o padrão POSIX (pontos para o NuttX!). A segunda informação importante é que, no Linux, o primeiro passo do processo de build consiste em executar o comando ./configure. Precisaremos descobrir o que este comando faz antes de prosseguirmos.

Compilando o RTP Tools no Linux

Precisamos conferir o que o comando ./configure do RTP Tools gera para, então, planejarmos a mesma ação no NuttX, se necessário. Assim, tentaremos compilar a aplicação no Linux para verificarmos: 1) a função do comando ./configure e 2) confirmar que a compilação em um sistema Unix esteja funcionando, conforme esperado.

E, para compilar o RTP Tools no Linux:

Ignorando por ora os warnings da compilação, verificamos que, além dos arquivos resultantes da compilação, foram criados os seguintes arquivos:

  • config.h;
  • config.log;
  • Makefile.local

Verificamos também, analisando o código fonte do RTP Tools, que config.h é um arquivo de cabeçalho utilizado por diversos arquivos do código fonte. Assim, verificamos que ./configure analisa o sistema operacional para gerar um header – de configuração – personalizado de acordo com as características do sistema operacional em que o RTP Tools está sendo compilado. Como iremos compilar o RTP Tools no NuttX, precisaremos verificar quais são estas configurações e fornecer um arquivo semelhante para a aplicação. O conteúdo de config.h gerado no Linux (x86/64) é:

O arquivo config.h, como pode ser observado, é criado dinamicamente a partir do comando ./configure. A própria descrição do repositório do RTP Tools observa que, em tradução livre: “O script ./configure é acompanhado por um conjunto de programas simples que detectam automaticamente a disponibilidade das funções do sistema (por exemplo, have-err.c) e se bibliotecas extras precisam ser envolvidas (por exemplo, -lnsl para have-gethostbyname.c)”.

Desta forma, verificaremos cada uma destas aplicações have-x.c (disponibilizadas no repositório do RTP Tools) para verificar quais são os testes executados e, assim, verificar se estas funções estão presentes no NuttX.

Compilando o RTP Tools no NuttX

O Código Fonte

O repositório do RTP Tools possui os seguintes arquivos:

Gerando o Arquivo config.h

Observe que o arquivo config.h não está presente no repositório: ao executar o script ./configure, alguns testes são executados no sistema operacional para verificar a disponibilidade de algumas funções e, de acordo com o resultado dos testes, o arquivo config.h é gerado dinamicamente. Os arquivos have-<function>.c executam testes que definem as macros presentes em config.h.

De forma semelhante, precisaremos verificar quais são estas funções e analisar se são também implementadas pelo NuttX. Além disso, o arquivo config.h define a macro #define RTP_BIG_ENDIAN 0 que, considerando o NuttX, dependerá do dispositivo selecionado para compilação. Assim, as configurações em config.h, no NuttX, também devem ser analisadas dinamicamente, a depender da configuração da arquitetura para a qual o NuttX será compilado. Criaremos, assim, o nosso arquivo config.h:

Endianess

Embora exista um teste (have-bigendian.c) para verificar o endianness do sistema, precisaríamos compilá-lo no NuttX, executá-lo no dispositivo alvo para, então, descobrir se é um sistema big-endian ou little-endian. Trabalhoso, né?

Felizmente, o sistema de build do NuttX já possui uma configuração que identifica o endianness do dispositivo: CONFIG_ENDIAN_BIG. Desta forma, poderíamos incluir a seguinte verificação em nosso arquivo config.h:

have-err.c

Executa o seguinte teste:

Procurando pelas funções warnx, warn e err no NuttX, verificamos que estão definidas em nuttx/libs/libc/misc/lib_err.c e independem de qualquer configuração para serem selecionadas. Assim, podemos definir #define HAVE_ERR 1. No entanto, procurando pela macro HAVE_ERR no código do RTP Tools, verificamos que ela é avaliada somente no arquivo compat-err.c para que, caso seu valor seja 0, compile uma versão das funções testadas. Como o valor dela no NuttX é 1, não precisaremos compilar compat-err.c e, assim, sequer seria necessário defini-la em nosso arquivo config.h.

have-gethostbyname.c

Executa o seguinte teste:

A função gethostbyname é definida, no NuttX, por nuttx/libs/libc/netdb/lib_gethostbyname.c. Procurando por este arquivo nos arquivos do NuttX, verificamos que (em nuttx/libs/libc/netdb/Make.defs):

Ou seja, o arquivo lib_gethostbyname.c depende da configuração CONFIG_LIBC_NETDB. Desta forma, precisaremos selecioná-la ao compilar o RTP Tools no NuttX.

have-getopt.c

Checa a seguinte função:

getopt é implementado pelo NuttX em libs/libc/unistd/lib_getopt.c. De forma semelhante, poderíamos incluir #define HAVE_GETOPT 1 no config.h mas, igualmente, não é necessário já que nenhuma versão alternativa será compilada.

have-gettimeofday.c

Semelhantemente, este arquivo testa se a função gettimeofday existe. No NuttX, ela é definida em libs/libc/time/lib_gettimeofday.c. Portanto, #define HAVE_GETTIMEOFDAY 1 (novamente, não será necessário porque esta macro é usada para compilar uma versão alternativa da função se é definida com o valor 0).

have-msgcontrol.c

O código fonte do teste é:

Basicamente, o teste verifica se há uma estrutura (struct) de msghdr. Esta estrutura está definida em include/sys/socket.h no NuttX e, portanto, também está implementada no nosso sistema operacional. Podemos, assim, definir #define HAVE_MSGCONTROL 1 no arquivo config.h. Ao contrário das demais declarações, a macro HAVE_MSGCONTROL é utilizada no código fonte do RTP Tools em rtptrans.c e, portanto, deve ser definida no arquivo config.h.

have-progname.c

Testa a função getprogname. No entanto, esta função não é utilizada por nenhum código do RTP Tools atualmente e, portanto, pode ser ignorada em nosso config.h.

have-socket.c

Implementa o seguinte teste:

Este teste verifica, basicamente, o suporte à sockets do tipo SOCK_DGRAM. Este tipo de socket é usado pelo RTP Tools e deve ser disponibilizado pelo sistema operacional. O NuttX implementa este tipo de socket em net/local/local_sockif.c se a macro CONFIG_NET_LOCAL_DGRAM estiver selecionada. Precisamos garantir que esteja!

have-strtonum.c

Testa se a função strtonum é implementada. Esta função, porém, não está sendo utilizada pelo código fonte do RTP Tools atualmente e, portanto, pode ser ignorada.

have-windows.c

Testa se estamos preparando para compilar o RTP Tools em um ambiente Microsoft Windows. Claramente não estamos (Apache NuttX wins!)

config.h

O arquivo config.h gerado para o NuttX, a partir da análise do testes acima, terá o seguinte conteúdo:

Este arquivo deverá ser disponibilizado juntamente com a receita para compilação do RTP Tools no NuttX, a qual iremos definir a seguir.

Adicionando o RTP Tools ao NuttX

Analisados aspectos inerentes à compilação do RTP Tools, podemos integrá-lo ao repositório nuttx-apps. A organização deste repositório é exibida a seguir:

Como pode ser observado, as aplicações estão organizadas por pastas “temáticas”. O RTP Tools, por sua vez, pode ser inserido na pasta netutils, conforme:

A partir da criação da pasta rtptools no nuttx-apps, é necessário criar as estruturas básicas para que o RTP Tools possa ser compilado no NuttX. Tal como fizemos em Integrando Aplicações Externas, criaremos uma estrutura que permita baixar o código fonte do repositório do RTP Tools e compilá-lo no NuttX. Os arquivos presentes neste diretório serão:

config.h

Tal como o arquivo gerado através do comando ./configure ao compilar o RTP Tools no Linux, adicionamos o arquivo config.h que define os macros aplicáveis ao NuttX, como explicado em config.h.

Makefile

O arquivo Makefile inclui as etapas de download do código do RTP Tools do repositório remoto, da compilação dos arquivos fontes comuns e dos arquivos fontes das aplicações do RTP Tools, que podem ser selecionadas pelo arquivo Kconfig (como será demonstrado mais adiante). O conteúdo do arquivo é o seguinte:

Como esperado, o arquivo Make.defs é incluído pelo Makefile logo no início do arquivo. A seguir, são definidas as seguintes variáveis RTPTOOLS_VERSION, RTPTOOLS_TARBALL, RTPTOOLS_UNPACK e RTPTOOLS_SRCDIR que serão usadas para definir o pacote com os arquivos fonte que será baixado do repositório do projeto. A seguir, adicionam-se arquivos fonte às variáveis CSRCS: estes arquivos não são aplicações de fato, mas servem a outros arquivos fontes que implementam as aplicações em si. Finalmente, as aplicações que compõem o RTP Tools são marcadas para serem compiladas de acordo com as configurações selecionadas via arquivo Kconfig. Entre as aplicações do RTP Tools, o rtpdump, por exemplo, é selecionado através da configuração CONFIG_NETUTILS_RTPTOOLS_RTPDUMP que, se selecionada, inclui o arquivo fonte da aplicação (que contém a função main) à variável MAINSRC.

Até agora, no entanto, não falamos de como o código fonte é obtido. Esse processo se inicia pela receita context. Esta receita depende do arquivo config.h disponível dentro do diretório de compilação (RTPTOOLS_UNPACK), junto com os demais arquivos fonte do RTP Tools. Isso, por sua vez, depende da existência do diretório RTPTOOLS_UNPACK que, finalmente, depende da existência do arquivo com o código fonte compactado do RTP Tools. Em suma, temos as seguintes ações:

  1. O código fonte do RTP Tools é baixado do repositório no github como um arquivo compactado, na versão definida por RTPTOOLS_VERSION (que, por sua vez, pode ser definido por CONFIG_NETUTILS_RTPTOOLS_VERSION);
  2. A seguir, este arquivo é descompactado em RTPTOOLS_UNPACK;
  3. Finalmente, o arquivo config.h é copiado para RTPTOOLS_UNPACK;
Kconfig

O arquivo Kconfig permite configurar aspectos do RTP Tools no NuttX e possui o seguinte conteúdo:

NETUTILS_RTPTOOLS seleciona a compilação do RTP Tools. As aplicações do RTP Tools a serem compiladas, no entanto, podem ser selecionadas individualmente como, por exemplo, NETUTILS_RTPTOOLS_RTPDUMP. Para cada aplicação, podemos definir o tamanho da pilha e também a prioridade de execução através de, por exemplo, NETUTILS_RTPTOOLS_RTPDUMP_STACKSIZE e NETUTILS_RTPTOOLS_RTPDUMP_PRIORITY, respectivamente. Finalmente, NETUTILS_RTPTOOLS_VERSION define uma versão a ser baixada do repositório do RTP Tools (que pode ser definida por uma tag ou, simplesmente, um hash que representa um commit).

Make.defs

O conteúdo do arquivo Make.defs é tão simples quanto:

A estrutura final da pasta que adiciona o RTP Tools como uma aplicação no nuttx-apps é, então:

1, 2, 3, Testando…

Embora as aplicações sejam adicionadas no repositório nuttx-apps, a seleção das mesmas – para serem compiladas junto ao NuttX – é através do repositório do NuttX. Um teste rápido de compilação pode ser efetuado através do uso do simulador do NuttX. Convém lembrar, porém, que o RTP Tools é uma aplicação de rede e, portanto, devemos partir de uma configuração (defconfig) que habilita as funcionalidades de rede.

Referindo-se à documentação do NuttX, encontramos a seção Accessing the Network que utiliza, por exemplo, a configuração sim:tcpblaster para testar as funcionalidades de rede do NuttX com o simulador. Partindo-se dela, iremos selecionar o RTP Tools para ser compilado. Para tal:

Pelo utilitário do menuconfig, navegue até: Application Configuration → Network Utilities. Nesta tela, selecione a opção Enable RTP Tools. Uma vez selecionada a opção, é possível selecionar as aplicações do RTP Tools que serão compiladas, conforme imagem a seguir:

Aplicação para o NuttX

A seguir, salve as configurações feitas pelo menuconfig e, para compilar, execute:

O rtpdump, do RTP Tools, foi compilado com sucesso? Parabéns! Temos uma aplicação POSIX-compliant compilada para o NuttX (até que não foi tão difícil, né?).

Para executar o simulador, execute ./nuttx. A seguir, execute help e verifique se o rtpdump está disponível.

Nota: um defconfig específico para compilar o RTP Tools com o simulador foi criado para o processo ser facilitado. Tente executar:

Conclusão

O objetivo deste artigo é aprofundar-se, justamente, no sistema de build do NuttX. Não falamos ainda: 1) do porquê o RTP Tools foi portado para o NuttX 2) como que o simulador fornece uma grande interface de teste e debugging de aplicações e 3) de como é possível contribuir com o projeto NuttX. Fique ligado para conferir os próximos artigos desta série. Dúvidas, críticas e sugestões? Deixe seu comentário na página 😉

Referências

Agradecimentos

Agradecimento especial aos revisores do artigo: Alan Carvalho de Assis, Lucas Saavedra Vaz e Ricardo Tafas.

Outros artigos da série

<< Executando NuttX em um ESP32 emulado com QEMUNuttX: Usando o Simulador para Testes e Debugging de Aplicações >>
Licença Creative Commons Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.
Comentários:
Notificações
Notificar
0 Comentários
Inline Feedbacks
View all comments
Home » Software » NuttX: Criando (ou Copiando!) uma Aplicação para o NuttX

EM DESTAQUE

WEBINARS

LEIA TAMBÉM

JUNTE-SE HOJE À COMUNIDADE EMBARCADOS

Talvez você goste:


Seminário de
Sistemas Embarcados e IoT 2024
 
Data: 25/06 | Local: Hotel Holiday Inn Anhembi, São Paulo-SP
 
GARANTA SEU INGRESSO

 
close-link