{"id":2263,"date":"2025-01-01T18:42:40","date_gmt":"2025-01-01T21:42:40","guid":{"rendered":"https:\/\/pedrobertoleti.com.br\/?p=2263"},"modified":"2025-01-03T12:17:28","modified_gmt":"2025-01-03T15:17:28","slug":"acelere-o-desenvolvimento-de-software-embarcado-com-ia","status":"publish","type":"post","link":"https:\/\/pedrobertoleti.com.br\/index.php\/2025\/01\/01\/acelere-o-desenvolvimento-de-software-embarcado-com-ia\/","title":{"rendered":"Acelere o desenvolvimento de software embarcado com IA"},"content":{"rendered":"\n

Introdu\u00e7\u00e3o<\/h2>\n\n\n\n

No desenvolvimento de software embarcado, os desafios t\u00e9cnicos est\u00e3o presentes do dia 1 at\u00e9 o fim do projeto. O profissional desta \u00e1rea precisa achar o ponto de equil\u00edbrio entre as restri\u00e7\u00f5es de hardware (presente em 100% dos projetos) com o desempenho esperado do software embarcado e da solu\u00e7\u00e3o como um todo. <\/p>\n\n\n\n

Por\u00e9m, existem tarefas que consomem um tempo significativo do desenvolvedor, tarefas estas que podem ser delegadas a um agente paralelo, como uma IA generativa. Como exemplo de tarefas assim, \u00e9 o desenvolvimento de software para interfacear com HAL (Hardware Abstract Layers) do fabricante do microcontrolador. Como o desenvolvedor vai lidar com dezenas (as vezes, centenas) de microcontroladores diferentes durante sua carreira, o tempo gasto para aprender como fazer esta interface \u00e9, sim, bastante significativo. Outras tarefas que s\u00e3o grandes consumidoras de tempo e que tamb\u00e9m podem ser delegadas a uma IA s\u00e3o a gera\u00e7\u00e3o de documenta\u00e7\u00e3o clara do c\u00f3digo-fonte, an\u00e1lise de erros de sintaxe e cria\u00e7\u00e3o de testes unit\u00e1rios.<\/p>\n\n\n\n

Neste artigo, mostro como a IA pode beneficiar desenvolvedores, utilizando como microcontrolador de exemplo o ESP32, programado com ESP-IDF.<\/p>\n\n\n\n

Pontos de aten\u00e7\u00e3o<\/h2>\n\n\n\n

Antes de iniciar, \u00e9 importante ressaltar que:<\/p>\n\n\n\n

    \n
  1. A IA nem sempre acerta. \u00c9 NECESS\u00c1RIO <\/mark><\/strong>que o desenvolvedor de software embarcado confira e reflita se o que a IA sugeriu faz sentido. Nunca confie cegamente na IA.<\/li>\n\n\n\n
  2. Por IA, entende-se IA generativa, como o ChatGPT, Google AI Studio e afins.<\/li>\n\n\n\n
  3. A qualidade da sua pergunta para a IA \u00e9 diretamente proporcional \u00e0 qualidade da resposta que ela fornece. N\u00e3o economize palavras e clareza na hora de escrever os prompts e solicita\u00e7\u00f5es.<\/li>\n\n\n\n
  4. Sempre se lembre que voc\u00ea \u00e9 o profissional e est\u00e1 usando a IA apenas como ferramenta para acelerar e delegar tarefas que consomem muito tempo. <\/li>\n\n\n\n
  5. N\u00e3o compartilhe seu c\u00f3digo-fonte inteiro com a IA, seja seletivo. Compartilhe apenas trechos que n\u00e3o revelem segredos de neg\u00f3cio. Lembre-se que a IA aprende com seu c\u00f3digo, e n\u00e3o seria nada legal ela saber de um trecho super sigiloso da sua solu\u00e7\u00e3o e fornecer a qualquer um.<\/li>\n\n\n\n
  6. Use a IA como ferramenta para poupar tempo em coisas deleg\u00e1veis. Assim voc\u00ea pode focar no desenvolvimento da solu\u00e7\u00e3o.<\/li>\n\n\n\n
  7. Nunca se esque\u00e7a do item 1<\/mark>.<\/strong><\/li>\n<\/ol>\n\n\n\n

    Gera\u00e7\u00e3o de c\u00f3digo para interfacear com HAL<\/h2>\n\n\n\n

    Configurar e interfacear perif\u00e9ricos do microcontrolador – tais como UART, PWM e afins – \u00e9 algo trabalhoso. Cada fabricante possui uma HAL distinta e, logo, uma forma diferente de configurar o perif\u00e9rico e fazer interface com ele na sua aplica\u00e7\u00e3o no software embarcado. Este \u00e9, talvez, uma das tarefas deleg\u00e1veis a uma IA que mais consomem tempo do desenvolvedor.<\/p>\n\n\n\n

    Tome como exemplo a UART, perif\u00e9rico usado em praticamente 100% dos sistemas embarcados. Este perif\u00e9rico possui uma HAL diferente para cada microcontrolador, com par\u00e2metros como baudrate, GPIOs para TX e RX, callback de interrup\u00e7\u00f5es, clock-base, e por a\u00ed vai. Imagine em, um ano, fazendo essa mesma configura\u00e7\u00e3o mais de 100 vezes, uma para cada microcontrolador de fabricante e modelo diferente. Mesmo que voc\u00ea for um desenvolvedor experiente, erros podem acontecer devido a um par\u00e2metro ser um pouco diferente em um microcontrolador aqui e outro ali. Em um ano, o tempo perdido nisso ser\u00e1 grande.<\/p>\n\n\n\n

    Neste quesito, a IA pode ajudar muito, pois ela tem conhecimento das HALs e pode j\u00e1 fornecer o caminho das pedras para voc\u00ea s\u00f3 adaptar e usar.<\/p>\n\n\n\n

    Para exemplificar, considere a configura\u00e7\u00e3o de PWM para um LED no ESP32. Imagine que o desenvolvedor precise configurar um pino GPIO para sa\u00edda PWM, cuja frequ\u00eancia base \u00e9 de 1 kHz e o duty cycle inicial \u00e9 de 50%. Um poss\u00edvel prompt para isso \u00e9:<\/p>\n\n\n\n

    \n

    Gerar um c\u00f3digo para servir de base para a configura\u00e7\u00e3o de PWM para controlar um LED ligado a um, GPIO do ESP32. O ESP32 ser\u00e1 programado com ESP-IDF, na vers\u00e3o 4.4. Considere o canal 0 de PWM, que a frequ\u00eancia do PWM \u00e9 de 1 kHz, que a resolu\u00e7\u00e3o \u00e9 de 10 bits (ou seja, duty cycle controlado com valores de 0 a 1024), que o duty cycle inicial \u00e9 de 50%, use low speed mode e que o GPIO utilizado para esse PWM \u00e9 o 4. Este c\u00f3digo deve conter tanto a programa\u00e7\u00e3o do timer que o PWM vai usar, tanto a configura\u00e7\u00e3o do PWM em si, sendo que o timer usado \u00e9 o 0. Encapsule isso na forma de uma fun\u00e7\u00e3o, chamada init_pwm.<\/p>\n<\/blockquote>\n\n\n\n

    Que resulta o seguinte c\u00f3digo:<\/p>\n\n\n\n

    #include \"driver\/ledc.h\"\n\nvoid init_pwm() {\n    ledc_timer_config_t timer_config = {\n        .speed_mode = LEDC_LOW_SPEED_MODE,\n        .timer_num = LEDC_TIMER_0,\n        .duty_resolution = LEDC_TIMER_10_BIT,\n        .freq_hz = 1000,\n        .clk_cfg = LEDC_AUTO_CLK,\n    };\n    ledc_timer_config(&timer_config);\n\n    ledc_channel_config_t channel_config = {\n        .gpio_num = 4,\n        .speed_mode = LEDC_LOW_SPEED_MODE,\n        .channel = LEDC_CHANNEL_0,\n        .timer_sel = LEDC_TIMER_0,\n        .duty = 512, \/\/ 50% de duty cycle\n    };\n    ledc_channel_config(&channel_config);\n}<\/code><\/pre>\n\n\n\n
    Note que o c\u00f3digo gerado foi claro, atendeu \u00e0s exig\u00eancias contidas no prompt e j\u00e1 consideram o uso da HAL do ESP-IDF (na vers\u00e3o 4.4). Assumindo que voc\u00ea n\u00e3o tenha experi\u00eancia pr\u00e9via com o ESP32, voc\u00ea levaria algumas dezenas de minutos para aprender isso, enquanto usando a IA para acelerar o processo voc\u00ea teria o c\u00f3digo em poucos segundos.<\/p>\n\n\n\n
    Verifica\u00e7\u00e3o de erros de sintaxe<\/h2>\n\n\n\n
    Por lidar com m\u00faltiplos microcontroladores de m\u00faltiplos fabricantes diferentes, uma coisa que todos desenvolvedores de software embarcado passam na hora de usar as HALs ou APIs de sistemas operacionais embarcados \u00e9 a sintaxe. Invariavelmente, a sintaxe muda de fabricante para fabricante (algumas vezes, entre modelos do mesmo fabricante), fazendo os desenvolvedores gastar um tempo corrigindo sintaxe.<\/p>\n\n\n\n
    Ao se deparar com erros de sintaxe, a IA pode ser um grande aux\u00edlio para poupar tempo, j\u00e1 indicando exatamente o que est\u00e1 errado e onde. Dessa forma, o tempo de corre\u00e7\u00e3o de sintaxe \u00e9 reduzido a poucos segundos.<\/p>\n\n\n\n
    Como exemplo, vamos dizer que voc\u00ea est\u00e1 em d\u00favida com a sintaxe da cria\u00e7\u00e3o de uma tarefa no FreeRTOS com ESP32, e deseja saber se a sintaxe que pensou est\u00e1 correta ou n\u00e3o. Um poss\u00edvel prompt para isso \u00e9:<\/p>\n\n\n\n
    \n
    Verifique a sintaxe da chamada abaixo, para criar uma tarefa no FreeRTOS, considerando que o microcontrolador a ser usado \u00e9 o ESP32, programado com ESP-IDF vers\u00e3o 4.4. Desejo que al\u00e9m da sintaxe, seja verificado se algum (ou alguns) dos par\u00e2metros est\u00e1 incorreto ou em um formato inesperado.

    Chamada: xTaskCreatePinnedToCore(task_function, “TaskName”, 512, NULL, 5, NULL, 0);<\/p>\n<\/blockquote>\n\n\n\n
    Como resultado, tem-se:<\/p>\n\n\n\n
    \n
    Sua sintaxe est\u00e1 correta, mas h\u00e1 um probema quanto ao tamanho da stack da task. O tamanho de 512 bytes para uma task no ESP32 (programado com ESP-IDF na vers\u00e3o 4.4) pode ser insuficiente, especialmente se a tarefa utiliza bibliotecas que demandam mais mem\u00f3ria. \u00c9 recomendado usar, pelo menos, 2048 bytes, como a seguir:

    xTaskCreatePinnedToCore(task_function, “TaskName”, 2048, NULL, 5, NULL, 0);<\/p>\n<\/blockquote>\n\n\n\n
    Note que, al\u00e9m de verificar a sintaxe, a IA encontrou um par\u00e2metro que poderia causar um problema em runtime (stack overflow ou stack smash), prevenindo tempo de debug. Isso com certeza poupa um tempo consider\u00e1vel do desenvolvedor de software embarcado.<\/p>\n\n\n\n
    Aux\u00edlio para documentar c\u00f3digo-fonte<\/h2>\n\n\n\n
    A falta de documenta\u00e7\u00e3o ou documenta\u00e7\u00e3o sem clareza s\u00e3o problemas comuns em softwares embarcados. Apesar de muitos acharem que documenta\u00e7\u00e3o \u00e9 “perfumaria”, ou ainda que o pr\u00f3prio c\u00f3digo \u00e9 a documenta\u00e7\u00e3o, esses pensamentos s\u00e3o muito ruins, pois c\u00f3digos-fonte com documenta\u00e7\u00e3o fraca ou inexistente t\u00eam sua manuten\u00e7\u00e3o bastante prejudicada. <\/p>\n\n\n\n
    A IA pode gerar documenta\u00e7\u00e3o t\u00e9cnica com base no c\u00f3digo existente, economizando tempo e promovendo melhores pr\u00e1ticas. Como exemplo, suponha que voc\u00ea deseja gerar documenta\u00e7\u00e3o sobre o que uma fun\u00e7\u00e3o de configura\u00e7\u00e3o de GPIOs faz, tamb\u00e9m considerando o ESP32 programado com ESP-IDF. Um poss\u00edvel prompt \u00e9:<\/p>\n\n\n\n
    \n
    Gere a documenta\u00e7\u00e3o para o trecho de c\u00f3digo abaixo, de forma a ficar claro o que \u00e9 feito com o GPIO identificado como GPIO_RELE. A documenta\u00e7\u00e3o deve ser feita no formato de m\u00faltiplas linhas e prezar pela clareza e legibilidade. Se poss\u00edvel, adote o padr\u00e3o do Doxygen.

    Trecho:
    gpio_set_direction(GPIO_RELE, GPIO_MODE_OUTPUT); 
    gpio_set_level(GPIO_RELE, 1);<\/p>\n<\/blockquote>\n\n\n\n
    Como resultado, a IA responde:<\/p>\n\n\n\n
    \/**\n * @brief Configura o GPIO_RELE como sa\u00edda digital e define o n\u00edvel inicial como alto.\n * \n * Detalhes:\n * - GPIO_RELE: Pino configurado como sa\u00edda.\n * - gpio_set_level: Define o n\u00edvel l\u00f3gico como 1 (alto).\n *\/<\/code><\/pre>\n\n\n\n
    A resposta foi uma documenta\u00e7\u00e3o bem feita e clara o suficiente para ser usada, de fato, no c\u00f3digo-fonte da solu\u00e7\u00e3o. 

    Mas relembrando dos pontos de aten\u00e7\u00e3o no in\u00edcio deste artigo, tenha cuidado: n\u00e3o compartilhe seu c\u00f3digo-fonte inteiro com a IA, seja seletivo. Compartilhe apenas trechos que n\u00e3o revelem segredos de neg\u00f3cio.<\/strong><\/p>\n\n\n\n
    Cria\u00e7\u00e3o de testes unit\u00e1rios<\/h2>\n\n\n\n
    Em software embarcado, a possibilidade de fazer testes unit\u00e1rios poupa muito tempo e dificuldade para debug em campo das solu\u00e7\u00f5es desenvolvidas. Muitas vezes \u00e9 poss\u00edvel detectar em bancada alguns erros que levariam a problemas grandes em campo. Entretanto, gerar testes unit\u00e1rios pode ser uma tarefa repetitiva e, em alguns casos, tediosa.<\/p>\n\n\n\n
    A IA pode ajudar nessa parte, gerando testes unit\u00e1rios considerando APIs do pr\u00f3prio SDK fornecida pelo fabricante do microcontrolador, por exemplo. Considerando novamente o ESP32 programado com ESP-IDF, um poss\u00edvel prompt \u00e9:<\/p>\n\n\n\n
    \n
    Fa\u00e7a uma rotina de testes unit\u00e1rios para as fun\u00e7\u00f5es ledc_get_freq e ledc_get_duty, considerando o microcontrolador sendo o ESP32, programado com ESP-IDF vers\u00e3o 4.4. Os testes unit\u00e1rios devem considerar o m\u00e1ximo de APIS para esse fim j\u00e1 presentes no ESP-IDF (vers\u00e3o 4.4), e tais testes unit\u00e1rios devem ser encapsulados numa fun\u00e7\u00e3o chamada test_pwm_init. Para os testes funcionarem corretamente, \u00e9 importante inicializar o PWM a partir da chamada de init_pwm.<\/p>\n<\/blockquote>\n\n\n\n
    Neste caso, a IA apresenta como resultado:<\/p>\n\n\n\n
    void test_pwm_init() {\n    init_pwm();\n    TEST_ASSERT_EQUAL(1000, ledc_get_freq(LEDC_LOW_SPEED_MODE, LEDC_TIMER_0));\n    TEST_ASSERT_EQUAL(512, ledc_get_duty(LEDC_LOW_SPEED_MODE, LEDC_CHANNEL_0));\n}<\/code><\/pre>\n\n\n\n
    A resposta foi bastante completa e atendeu \u00e0s exig\u00eancias do prompt. Obviamente, este foi um exemplo pequeno, mas a IA pode ser usada para gerar testes unit\u00e1rios muito mais extensos e completos podem em poucos segundos, poupando um tempo consider\u00e1vel de desenvolvimento de software embarcado.<\/p>\n\n\n\n
    Conclus\u00e3o<\/h2>\n\n\n\n
    A intelig\u00eancia artificial generativa oferece uma nova perspectiva, permitindo a acelera\u00e7\u00e3o do desenvolvimento de softwares embarcados. Ao automatizar tarefas repetitivas e deleg\u00e1veis a uma IA, identificar erros, documentar c\u00f3digo e gerar c\u00f3digos para interfacear com HALs de fabricantes e modelos de microcontroladores espec\u00edficos, a IA permite que os desenvolvedores de software embarcado concentrem seus esfor\u00e7os no que realmente precisam: desenvolvimento da solu\u00e7\u00e3o como um todo.<\/p>\n\n\n\n
    No contexto do ESP32 com ESP-IDF, os exemplos demonstraram como a IA pode ser uma ferramenta valiosa para agilizar o trabalho e aumentar a produtividade do desenvolvedor de software embarcado. Seguindo as dicas e sugest\u00f5es mostradas neste artigo, desenvolvedores de software embarcado t\u00eam a oportunidade de elevar a qualidade e a produtividade de seus projetos em pouqu\u00edssimo tempo.<\/p>\n\n\n\n
    Quer saber mais sobre IA e programa\u00e7\u00e3o? Veja isso<\/h2>\n\n\n\n
    Se voc\u00ea gostou deste artigo e deseja saber mais sobre o uso de IA na programa\u00e7\u00e3o, eu recomendo ler os seguintes livros:<\/p>\n\n\n\n