Se você é apaixonado por microcontroladores, FPGAs, sistemas embarcados, eletrônica digital, IoT, AIoT, protocolos industriais, processamento de sinais ou arquitetura de hardware, este é o seu lugar.

Criamos um espaço colaborativo no WhatsApp para reunir desenvolvedores, estudantes, pesquisadores e entusiastas que desejam evoluir juntos no universo de MCU e FPGA e todo o seu ecossistema — do firmware ao hardware, do bare-metal ao RTOS, do HDL ao edge computing.

Aqui você poderá:

• Trocar experiências práticas
• Tirar dúvidas técnicas
• Compartilhar projetos e artigos
• Discutir arquiteturas e boas práticas
• Conhecer novas ferramentas e tecnologias
• Expandir sua rede profissional

Nosso objetivo é construir uma comunidade técnica forte, colaborativa e orientada ao crescimento real.

Entre agora pelo link:
https://chat.whatsapp.com/BYXrqPHsRO5FTP7ap7X5yq

Se você acredita na força do conhecimento compartilhado, convide também seus amigos, colegas de trabalho e membros de outros grupos técnicos. Quanto mais mentes engajadas, mais rico será o aprendizado de todos.

Vamos fortalecer o ecossistema de MCU & FPGA juntos.

The post Participe em nossa comunidade no Whatsapp first appeared on MCU & FPGA.

Conteúdo Educacional e Técnico (Portais e Comunidades)

• Embarcados
  https://www.embarcados.com.br
  Principal portal brasileiro sobre sistemas embarcados, microcontroladores, RTOS, Linux embarcado e indústria. Excelente equilíbrio entre teoria, prática e mercado.
• MCU.TEC
  https://mcu.tec.br
  Conteúdo técnico aprofundado sobre microcontroladores, FPGA, RTOS, protocolos, eletrônica aplicada e integração com IA. Forte foco em didática e engenharia real.
• Microgenios
  https://www.microgenios.com.br
  Cursos, treinamentos e artigos focados em PIC, Arduino, ESP32 e IoT, com abordagem prática para iniciantes e intermediários.
• Instituto Newton C. Braga
  https://www.newtoncbraga.com.br
  Acervo clássico e extremamente vasto de eletrônica, incluindo microcontroladores, sensores, fontes e RF. Um verdadeiro repositório histórico-técnico.
• Vichinsky
  https://www.vichinsky.com
  Conteúdo técnico voltado a PIC (especialmente PIC18F2550), 8051 e Arduino, com exemplos diretos e foco em firmware bare-metal.
• All About Circuits
  https://www.allaboutcircuits.com
  Um dos melhores sites internacionais para eletrônica e microcontroladores, com artigos técnicos, fóruns e análises profundas.

Fabricantes e Documentação Oficial

• Microchip Technology
  https://www.microchip.com
  Documentação oficial de PIC, AVR (Atmel), SAM e ferramentas como MPLAB X. Fonte primária obrigatória para quem trabalha com PIC e AVR.
• STMicroelectronics
  https://www.st.com
  Referência absoluta para STM32, HAL, LL, CubeMX e ecossistema ARM Cortex-M e Cortex-A.
• NXP Semiconductors
  https://www.nxp.com
  Forte em microcontroladores industriais, automotivos, i.MX, LPC e segurança embarcada.
• Renesas Electronics
  https://www.renesas.com
  Destaque para famílias RA, RX e RZ, muito usadas em aplicações industriais e IoT avançado.
• Texas Instruments
  https://www.ti.com
  MSP430, Sitara, documentação exemplar e application notes de alto nível.

Lojas e Kits de Desenvolvimento (Brasil)

• AutoCore Robótica
  https://www.autocorerobotica.com.br
  Venda de microcontroladores, módulos ESP, sensores e kits educacionais.
• Baú da Eletrônica
  https://www.baudaeletronica.com.br
  Grande variedade de CIs, microcontroladores, ferramentas e componentes.
• ACEPIC Tecnologia
  https://www.acepic.com.br
  Especializada em kits, treinamentos e soluções educacionais para PIC, ESP32 e sistemas embarcados.

Plataformas de Pesquisa e Datasheets

• Octopart
  https://octopart.com
  Essencial para pesquisa de microcontroladores, comparação de preços, estoque global e acesso rápido a datasheets oficiais.
• Digi-Key
  https://www.digikey.com
  Além da loja, possui uma biblioteca técnica riquíssima (TechForum, artigos, vídeos).
• Mouser Electronics
  https://www.mouser.com
  Excelente para lançamentos recentes, application notes e kits de desenvolvimento.

The post Os Melhores Sites sobre Microcontroladores, Sistemas Embarcados e IoT em 2026 first appeared on MCU & FPGA.

Por isso, surge o conceito de interfaces sensoriais desacopladas. Essa abordagem se baseia em separar a lógica de aquisição e processamento de dados do sensor da lógica de aplicação que consome esses dados. Essa separação é feita através de interfaces bem definidas que permitem que o sensor seja substituído, atualizado ou simulado sem afetar o restante do sistema. Trata-se de uma prática essencial em arquitetura de software para sistemas embarcados, especialmente quando se busca reusabilidade, escalabilidade e manutenção simplificada.

No contexto de sistemas em tempo real e embarcados, essa técnica é frequentemente associada a padrões de projeto como Proxy, Observer, Adapter e até Component-Based Architecture. O conceito também está fortemente alinhado aos princípios de desenvolvimento dirigidos por interface (interface-driven development), que promovem a padronização e o isolamento de dependências de hardware.

Problema a Ser Resolvido

O desenvolvimento de sistemas embarcados muitas vezes parte da integração direta entre sensores e o restante da aplicação, especialmente em projetos de pequeno porte ou provas de conceito. Essa abordagem, ainda que funcional em curto prazo, se revela problemática à medida que o sistema cresce ou sofre manutenções.

O acoplamento direto entre o código da aplicação e os drivers dos sensores cria uma relação de dependência forte. Isso significa que qualquer modificação no sensor — seja por substituição do modelo, mudança no protocolo de comunicação (como de I2C para SPI), alteração no intervalo de amostragem ou até mesmo diferenças sutis de precisão — exige uma reestruturação que pode afetar não apenas o código do driver, mas também partes significativas da lógica de negócio.

Além disso, sensores reais são recursos físicos sujeitos a falhas, desgaste ou simplesmente indisponibilidade em fases iniciais do projeto. Isso dificulta o desenvolvimento paralelo e o uso de simulações ou testes automatizados, pois a ausência de uma interface desacoplada impede a substituição do sensor por um gerador de dados sintéticos ou módulo de simulação.

Outro ponto crítico é a portabilidade. Sistemas embarcados muitas vezes são projetados para migrar entre plataformas — de um microcontrolador AVR para um STM32, por exemplo — e sem uma abstração clara entre o hardware sensor e o restante do sistema, esse processo se torna custoso, trabalhoso e propenso a erros.

Portanto, o problema reside no risco técnico e na inflexibilidade associados ao acoplamento direto entre sensores e aplicação. A ausência de uma interface sensorial desacoplada limita a evolução do projeto, a sua testabilidade, a reutilização de componentes e até a resiliência frente a falhas de fornecimento ou alteração tecnológica.

Princípios e Estrutura de Interfaces Sensoriais Desacopladas

A estrutura de uma interface sensorial desacoplada repousa sobre um princípio fundamental da engenharia de software: programar para uma interface, não para uma implementação. Na prática, isso significa que o código da aplicação não deve conhecer os detalhes de funcionamento de um sensor específico, mas apenas interagir com ele por meio de um contrato (interface) bem definido.

Essa estrutura pode ser visualizada em três camadas principais:

1. Interface Sensorial Abstrata
   Trata-se de uma definição genérica, usualmente expressa em termos de uma classe abstrata (em C++) ou uma estrutura com ponteiros para funções (em C). Ela define operações como read_data(), initialize(), shutdown() ou calibrate(). Essas operações são independentes do protocolo físico, fabricante ou modelo do sensor.
2. Implementações Concretas
   Cada sensor específico implementa essa interface com suas particularidades. Por exemplo, um sensor de temperatura TMP36 usando ADC terá uma implementação diferente de um DHT22 que usa sinal digital com temporização. Ainda assim, ambos expõem a mesma interface, o que garante que a aplicação possa alternar entre eles sem ser reescrita.
3. Camada de Aplicação
   A lógica da aplicação consome os dados de forma padronizada, podendo inclusive fazer uso de sensores simulados (mocks) para testes, sensores virtuais em ambientes de simulação ou sensores reais conectados via drivers físicos. A aplicação permanece imune às mudanças que ocorram abaixo da interface.

Exemplo prático em C:
Imagine um sistema com dois sensores de temperatura diferentes:

cCopiarEditartypedef struct {
    float (*read_temperature)(void);
    void (*initialize)(void);
} TempSensorInterface;

float tmp36_read() { /* leitura via ADC */ }
void tmp36_init() { /* init ADC */ }

float dht22_read() { /* leitura digital */ }
void dht22_init() { /* init DHT protocolo */ }

TempSensorInterface tmp36 = { tmp36_read, tmp36_init };
TempSensorInterface dht22 = { dht22_read, dht22_init };

// No código da aplicação:
void use_sensor(TempSensorInterface* sensor) {
    sensor->initialize();
    float temp = sensor->read_temperature();
    printf("Temperatura: %.2f °C\n", temp);
}

Dessa forma, a aplicação use_sensor() pode receber qualquer sensor que implemente essa interface, inclusive um sensor simulado para teste de software:

cCopiarEditarfloat fake_temp_read() { return 25.0; }
void fake_temp_init() {}

TempSensorInterface simulated = { fake_temp_read, fake_temp_init };

A flexibilidade dessa estrutura permite que a lógica da aplicação continue funcional independentemente de mudanças no hardware ou no ambiente de desenvolvimento.

Vantagens e Benefícios do Desacoplamento Sensorial

A adoção de interfaces sensoriais desacopladas oferece uma série de vantagens concretas para o desenvolvimento de sistemas embarcados, tanto do ponto de vista técnico quanto estratégico. Vamos explorar esses benefícios em três dimensões: manutenção e evolução do sistema, testabilidade e qualidade de software, e reutilização e escalabilidade.

1. Manutenção e Evolução do Sistema

Ao desacoplar sensores da lógica de aplicação, torna-se possível substituir, atualizar ou até eliminar sensores físicos sem reescrever o código de alto nível. Isso é particularmente valioso quando um sensor se torna obsoleto, sofre alterações de firmware ou precisa ser adaptado para diferentes ambientes (por exemplo, substituição de um sensor de temperatura interno por um sensor externo com sonda).

Além disso, o desacoplamento torna o sistema mais resiliente à obsolescência tecnológica. Em aplicações industriais, onde o ciclo de vida de um produto pode se estender por décadas, ter a flexibilidade para trocar componentes sem comprometer o sistema é vital.

2. Testabilidade e Qualidade de Software

Com interfaces desacopladas, é trivial introduzir sensores simulados (mocks) ou fontes de dados gravadas durante o desenvolvimento e os testes. Isso permite:

• Realizar testes unitários automatizados sem necessidade de hardware.
• Reproduzir comportamentos específicos como falhas, valores fora da faixa, ruído ou latência artificial.
• Executar o sistema completo em modo de simulação, facilitando a integração com interfaces gráficas ou softwares de visualização.

Dessa forma, o ciclo de desenvolvimento se torna mais rápido e confiável, com menos dependência de acesso ao hardware físico.

3. Reutilização e Escalabilidade

Projetos que seguem a filosofia de desacoplamento sensorial tendem a gerar módulos reutilizáveis. Um módulo de leitura de temperatura, por exemplo, pode ser aproveitado em diversos projetos distintos — desde um termômetro portátil até um sistema de climatização industrial — desde que ambos adotem a mesma interface.

Além disso, esse modelo permite escalar o sistema com facilidade. É possível, por exemplo, combinar sensores físicos com sensores virtuais (como estimativas baseadas em modelo matemático) sem alterar a aplicação. Em arquiteturas distribuídas, também é comum abstrair sensores remotos conectados por BLE, Wi-Fi ou CAN bus como se fossem sensores locais, graças ao uso de interfaces desacopladas.

Em resumo, as interfaces sensoriais desacopladas promovem robustez, adaptabilidade, portabilidade, testabilidade e reusabilidade, pilares fundamentais de qualquer projeto de engenharia bem estruturado.

Padrões de Projeto Relacionados

A construção de interfaces sensoriais desacopladas se fundamenta em diversos padrões clássicos de projeto de software. Estes padrões oferecem soluções comprovadas para os problemas de acoplamento, encapsulamento e extensão modular. A seguir, destacamos os mais relevantes no contexto de sistemas embarcados.

1. Adapter (Adaptador)

O padrão Adapter permite que uma classe com uma interface incompatível seja utilizada em um sistema que espera uma interface específica. No contexto sensorial, é comum criar adaptadores que convertem o protocolo e os métodos de sensores legados ou heterogêneos para um formato comum esperado pela aplicação.

Por exemplo, se um sensor de temperatura comunica-se via UART e outro via I2C, mas ambos devem expor a função read_temperature(), o Adapter pode encapsular os detalhes de protocolo, oferecendo uma interface unificada.

2. Proxy (Representante ou Substituto)

O padrão Proxy é útil quando queremos adicionar funcionalidades extras ao acesso ao sensor, como cache de dados, limitação de frequência de leitura ou monitoramento de consumo. Um proxy pode também ser utilizado para representar sensores virtuais, como estimativas ou simulações, que respondem da mesma forma que os sensores físicos.

Em testes, proxies podem substituir sensores reais por componentes simulados sem que a aplicação perceba a diferença.

3. Bridge (Ponte)

Bridge é um padrão que separa uma abstração de sua implementação, permitindo que ambas evoluam independentemente. Aplicado a sensores, permite que o tipo de dado (por exemplo, temperatura, pressão, umidade) seja desacoplado do meio de aquisição (SPI, ADC, rede), tornando o código altamente modular e reutilizável.

4. Observer (Observador)

No caso de sensores que disparam eventos (por exemplo, detecção de movimento ou alarme de fumaça), o padrão Observer permite que vários módulos da aplicação se registrem como ouvintes (listeners) e reajam de forma assíncrona à chegada dos dados. Isso torna o sistema reativo e desacoplado de polling explícito.

5. Strategy (Estratégia)

Quando múltiplos algoritmos de interpretação de dados sensoriais são possíveis (por exemplo, diferentes filtros ou calibrações), o padrão Strategy permite alternar dinamicamente a forma como os dados são processados, mantendo a leitura desacoplada da lógica de decisão.

6. Factory Method (Fábrica)

A criação de sensores pode ser encapsulada em fábricas, o que permite decidir dinamicamente qual sensor será instanciado com base em configurações externas, detecção automática ou parâmetros de compilação.

Esses padrões não são mutuamente exclusivos. Um sistema robusto frequentemente utiliza uma combinação deles para atingir níveis elevados de modularidade e confiabilidade. Em um sistema real, pode-se ter sensores instanciados por uma fábrica, acessados por meio de proxies, encapsulados por adaptadores e monitorados por observadores, tudo operando sob uma ponte entre abstrações e implementações.

Estratégias de Implementação em Sistemas Embarcados

A implementação prática de interfaces sensoriais desacopladas em sistemas embarcados exige atenção a aspectos como limitações de recursos, tempo real, e integração com periféricos específicos. A seguir, apresento estratégias concretas que equilibram desempenho, modularidade e simplicidade.

1. Uso de Ponteiros para Funções em C

Linguagens como C, muito comuns em sistemas embarcados, não possuem suporte nativo a interfaces e polimorfismo. Para contornar isso, uma prática comum é o uso de estruturas contendo ponteiros para funções, simulando uma interface de acesso. Cada driver de sensor implementa seus próprios métodos, que são então atribuídos à estrutura comum.

Exemplo:

cCopiarEditartypedef struct {
    void (*init)(void);
    float (*read_value)(void);
} SensorInterface;

SensorInterface temp_sensor = {
    .init = tmp36_init,
    .read_value = tmp36_read
};

Isso permite que a aplicação invoque temp_sensor.read_value() sem saber qual sensor físico está por trás.

2. Camada HAL (Hardware Abstraction Layer)

Outra estratégia é a introdução de uma camada de abstração de hardware (HAL), que separa os registros e periféricos do microcontrolador da lógica de negócio. A HAL define funções genéricas como HAL_Read_Temperature(), enquanto implementações específicas para cada sensor são feitas em módulos independentes.

Essa abordagem facilita a portabilidade entre diferentes plataformas (por exemplo, trocar um STM32 por um RP2040) e promove reuso de código.

3. Separação por Arquivos e Convenção de Interface

Organizar os sensores em arquivos distintos, cada um com sua própria implementação da interface, ajuda a manter o projeto organizado. É comum ter uma convenção onde cada sensor implementa funções como:

cCopiarEditarvoid sensorX_init(void);
float sensorX_read(void);

Essas funções são então registradas em tempo de inicialização ou via uma fábrica sensorial que escolhe o driver conforme configuração de tempo de compilação ou leitura de EEPROM/flash.

4. Tabelas de Dispositivos e Auto-Detecção

Em sistemas mais avançados, pode-se montar uma tabela de sensores disponíveis. Cada entrada aponta para a interface e metadados do sensor (ID, fabricante, tipo, intervalo de leitura). Isso facilita a criação de sistemas auto-configuráveis ou modulares, onde os sensores podem ser adicionados ou removidos dinamicamente.

Exemplo:

cCopiarEditartypedef struct {
    const char* name;
    SensorInterface* interface;
} SensorEntry;

SensorEntry sensors[] = {
    { "TMP36", &tmp36_interface },
    { "DHT22", &dht22_interface },
};

5. Simulação e Testes com Sensores Virtuais

Durante o desenvolvimento ou em sistemas com failover, sensores virtuais ou simulados podem ser utilizados. Basta substituir o ponteiro de função real por uma função que gera dados sintéticos:

cCopiarEditarfloat simulated_read() { return 22.5 + sin(time_now()); }

Isso permite testes offline ou uso em ambiente de simulação gráfica.

A escolha da melhor estratégia depende do contexto do projeto, mas todas partilham o objetivo de criar uma separação clara entre quem coleta os dados e quem usa os dados, favorecendo manutenção, testes e evolução.

Modelo de Amostragem e Exemplo Completo

Para consolidar os conceitos apresentados, vejamos um exemplo prático de como implementar uma interface sensorial desacoplada em um sistema embarcado simples, escrito em C. Suponhamos que temos dois sensores de temperatura disponíveis: o TMP36 (analógico) e o DHT22 (digital). Nosso sistema precisa apenas ler a temperatura e exibi-la, sem se importar com os detalhes de aquisição.

Etapa 1: Definindo a Interface Sensorial

Criamos uma estrutura que representa nossa interface genérica de sensor de temperatura:

cCopiarEditartypedef struct {
    void (*init)(void);
    float (*read_temperature)(void);
} TemperatureSensor;

Essa estrutura define um contrato que qualquer sensor de temperatura precisa seguir: uma função de inicialização e uma função de leitura.

Etapa 2: Implementações Concretas

TMP36 (analógico via ADC):

cCopiarEditar#include "adc_driver.h"

void tmp36_init(void) {
    adc_init();
}

float tmp36_read_temperature(void) {
    int adc_value = adc_read(); // valor entre 0 e 1023
    float voltage = (adc_value * 3.3f) / 1023.0f;
    return (voltage - 0.5f) * 100.0f; // fórmula do TMP36
}

TemperatureSensor tmp36_sensor = {
    .init = tmp36_init,
    .read_temperature = tmp36_read_temperature
};

DHT22 (digital via protocolo):

cCopiarEditar#include "dht_driver.h"

void dht22_init(void) {
    dht_setup();
}

float dht22_read_temperature(void) {
    return dht_get_temperature();
}

TemperatureSensor dht22_sensor = {
    .init = dht22_init,
    .read_temperature = dht22_read_temperature
};

Etapa 3: Aplicação Usando Interface Desacoplada

cCopiarEditar#include <stdio.h>

void run_temperature_app(TemperatureSensor* sensor) {
    sensor->init();
    while (1) {
        float temp = sensor->read_temperature();
        printf("Temperatura atual: %.2f °C\n", temp);
        delay_ms(1000);
    }
}

A função run_temperature_app() é completamente desacoplada da origem dos dados. Podemos executar:

cCopiarEditarrun_temperature_app(&tmp36_sensor);
// ou
run_temperature_app(&dht22_sensor);
// ou até
run_temperature_app(&simulated_sensor);

Etapa 4: Sensor Simulado para Testes

cCopiarEditar#include <math.h>

float simulated_temperature(void) {
    static int t = 0;
    t++;
    return 25.0f + 2.0f * sinf(t * 0.1f); // variação senoidal
}

void simulated_init(void) {
    // nada a fazer
}

TemperatureSensor simulated_sensor = {
    .init = simulated_init,
    .read_temperature = simulated_temperature
};

Esse sensor pode ser usado em testes automatizados, ambientes virtuais ou para demonstrar o sistema em laboratório sem hardware real.

Conclusão

Interfaces sensoriais desacopladas representam uma abordagem elegante, robusta e escalável para o desenvolvimento de sistemas embarcados. Elas permitem que aplicações sejam mais modulares, testáveis e adaptáveis às inevitáveis mudanças de hardware que ocorrem ao longo do ciclo de vida de um produto.

Ao adotar esse modelo, engenheiros embarcados reduzem o risco de retrabalho, promovem reutilização de código e constroem sistemas mais resilientes — qualidades essenciais em projetos industriais, acadêmicos ou comerciais.

The post Interfaces Sensoriais Desacopladas: Modularidade e Testabilidade em Sistemas Embarcados first appeared on MCU & FPGA.

Este artigo explora a convenção de nomenclatura do FreeRTOS, explicando a lógica por trás da escolha dos prefixos e sufixos, além de fornecer exemplos práticos e amplamente documentados para ajudar iniciantes no uso desse sistema operacional.

1. Convenção de Nomenclatura no FreeRTOS

O FreeRTOS segue um conjunto de regras bem definido para nomear funções, variáveis e tipos de dados. Essas regras são fundamentais para manter a legibilidade e a consistência do código. As principais características da nomenclatura são:

1. Prefixos das Funções – Indicam a categoria da função.
2. Tipos de Dados e Estruturas – Usam typedefs com convenções específicas.
3. Uso de Sufixos – Algumas funções e variáveis possuem sufixos que indicam propriedades específicas.

Nos tópicos seguintes, vamos explorar essas convenções com mais detalhes e exemplos práticos.

2. Prefixos das Funções no FreeRTOS

As funções do FreeRTOS seguem uma padronização de prefixos para indicar a categoria ou funcionalidade à qual pertencem. Isso facilita a organização do código e a compreensão rápida do que cada função faz. Os prefixos mais comuns são:

2.1. Funções de Gerenciamento de Tarefas

Essas funções lidam com a criação, suspensão, retomada e exclusão de tarefas no FreeRTOS. O prefixo usado é vTask ou xTask, dependendo do tipo de retorno. Elas são definidas no arquivo de cabeçalho tasks.h que deve ser incluído para seu uso.

• xTaskCreate() – Cria uma nova tarefa.
• vTaskDelete() – Exclui uma tarefa existente.
• vTaskDelay() – Suspende a tarefa por um período de tempo.
• xTaskGetSchedulerState() – Obtém o estado atual do escalonador.

Exemplo: Criando uma tarefa no FreeRTOS

#include "FreeRTOS.h"
#include "task.h"

void vTaskFunction(void *pvParameters) {
    while(1) {
        // Código da tarefa
        vTaskDelay(pdMS_TO_TICKS(1000)); // Atraso de 1 segundo
    }
}

void app_main(void) {
    xTaskCreate(vTaskFunction, "MinhaTarefa", configMINIMAL_STACK_SIZE, NULL, 1, NULL);
}

Neste exemplo, xTaskCreate() é usada para criar a tarefa, e vTaskDelay() para introduzir um atraso.

2.2. Funções de Gerenciamento de Filas

As filas são amplamente utilizadas no FreeRTOS para comunicação entre tarefas. As funções relacionadas a filas começam com o prefixo xQueue. As funções relativas ao Queue são definidas no header queue.h que deve ser incluído sempre que forem usadas.

• xQueueCreate() – Cria uma fila.
• xQueueSend() – Envia um item para a fila.
• xQueueReceive() – Recebe um item da fila.
• uxQueueMessagesWaiting() – Retorna o número de itens na fila.

Exemplo: Criando e usando uma fila

QueueHandle_t xQueue;

void vTaskSender(void *pvParameters) {
    int valor = 42;
    while(1) {
        xQueueSend(xQueue, &valor, portMAX_DELAY);
        vTaskDelay(pdMS_TO_TICKS(500)); // Envio a cada 500ms
    }
}

void vTaskReceiver(void *pvParameters) {
    int recebido;
    while(1) {
        if (xQueueReceive(xQueue, &recebido, portMAX_DELAY)) {
            printf("Recebido: %d\n", recebido);
        }
    }
}

void app_main(void) {
    xQueue = xQueueCreate(10, sizeof(int)); // Cria fila com 10 posições
    xTaskCreate(vTaskSender, "Sender", configMINIMAL_STACK_SIZE, NULL, 1, NULL);
    xTaskCreate(vTaskReceiver, "Receiver", configMINIMAL_STACK_SIZE, NULL, 1, NULL);
}

Aqui, xQueueCreate() cria a fila, xQueueSend() insere valores e xQueueReceive() os lê.

2.3. Funções de Semáforos e Mutexes

Os semáforos e mutexes são usados para sincronizar tarefas e gerenciar acesso a recursos compartilhados. O prefixo para essas funções é xSemaphore ou xMutex. Estas funçõe são definidas no arquivo de cabeçalho semaphore.h.

• xSemaphoreCreateBinary() – Cria um semáforo binário.
• xSemaphoreGive() – Libera um semáforo.
• xSemaphoreTake() – Captura um semáforo.
• xSemaphoreCreateMutex() – Cria um mutex.

Exemplo: Uso de mutex para evitar condições de corrida

SemaphoreHandle_t xMutex;

void vTask1(void *pvParameters) {
    while(1) {
        if (xSemaphoreTake(xMutex, portMAX_DELAY)) {
            printf("Tarefa 1 acessando recurso\n");
            vTaskDelay(pdMS_TO_TICKS(500));
            xSemaphoreGive(xMutex);
        }
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

void vTask2(void *pvParameters) {
    while(1) {
        if (xSemaphoreTake(xMutex, portMAX_DELAY)) {
            printf("Tarefa 2 acessando recurso\n");
            vTaskDelay(pdMS_TO_TICKS(500));
            xSemaphoreGive(xMutex);
        }
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

void app_main(void) {
    xMutex = xSemaphoreCreateMutex();
    xTaskCreate(vTask1, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, NULL);
    xTaskCreate(vTask2, "Task2", configMINIMAL_STACK_SIZE, NULL, 1, NULL);
}

Aqui, xSemaphoreCreateMutex() cria um mutex, enquanto xSemaphoreTake() e xSemaphoreGive() garantem o acesso seguro ao recurso.

2.4. Funções de Timers

Os timers no FreeRTOS permitem a execução periódica de funções. As funções relacionadas a timers começam com xTimer. As funções de Timer são definidas no arquivo de cabeçalho timer.h.

• xTimerCreate() – Cria um novo timer.
• xTimerStart() – Inicia um timer.
• xTimerStop() – Para um timer.
• xTimerReset() – Reinicia um timer.

Exemplo: Criando um timer no FreeRTOS

TimerHandle_t xTimer;

void vTimerCallback(TimerHandle_t xTimer) {
    printf("Timer expirado!\n");
}

void app_main(void) {
    xTimer = xTimerCreate("MeuTimer", pdMS_TO_TICKS(2000), pdTRUE, NULL, vTimerCallback);
    if (xTimer != NULL) {
        xTimerStart(xTimer, 0);
    }
}

O timer dispara vTimerCallback() a cada 2 segundos.

3. Tipos de Dados e Estruturas no FreeRTOS

No FreeRTOS, a padronização dos tipos de dados e estruturas é essencial para garantir a portabilidade entre diferentes arquiteturas de microcontroladores. A nomenclatura segue convenções bem definidas para facilitar a leitura e evitar ambiguidades.

Os principais tipos de dados no FreeRTOS são:

• BaseType_t – Tipo base genérico para representar valores numéricos.
• TickType_t – Usado para armazenar valores de tempo (ticks do sistema).
• UBaseType_t – Variante sem sinal de BaseType_t, usada para contadores e índices.
• TaskHandle_t – Representa uma referência para uma tarefa.
• QueueHandle_t – Representa uma referência para uma fila.
• SemaphoreHandle_t – Representa um semáforo ou mutex.
• TimerHandle_t – Manipulador para um timer do FreeRTOS.

A seguir, exploraremos esses tipos de dados com exemplos práticos.

3.1. BaseType_t e UBaseType_t

O tipo BaseType_t é a base para a maioria dos tipos de retorno no FreeRTOS. Ele é definido de forma genérica para ser compatível com diferentes arquiteturas (8, 16, 32 ou 64 bits).

• BaseType_t pode ser positivo, negativo ou zero.
• UBaseType_t é sempre positivo e é usado para índices e contadores.

Exemplo: Verificando retorno de uma função

BaseType_t xStatus;
UBaseType_t uxCount = 0;

void app_main(void) {
    xStatus = xTaskCreatePinnedToCore(vTaskFunction, "Task", configMINIMAL_STACK_SIZE, NULL, 1, NULL, 0);

    if (xStatus == pdPASS) {
        printf("Tarefa criada com sucesso!\n");
    } else {
        printf("Falha ao criar tarefa.\n");
    }

    uxCount++;
    printf("Número de tentativas: %u\n", (unsigned int)uxCount);
}

Aqui, BaseType_t verifica se a criação da tarefa foi bem-sucedida, enquanto UBaseType_t conta as tentativas de criação.

3.2. TickType_t

O tipo TickType_t é usado para armazenar valores de tempo no FreeRTOS. O sistema mede o tempo em “ticks”, que dependem da frequência configurada (configTICK_RATE_HZ).

Exemplo: Obtendo o tempo atual do sistema

TickType_t xStartTime, xElapsedTime;

void app_main(void) {
    xStartTime = xTaskGetTickCount(); // Obtém o tempo atual em ticks
    vTaskDelay(pdMS_TO_TICKS(500)); // Aguarda 500ms
    xElapsedTime = xTaskGetTickCount() - xStartTime; // Calcula o tempo decorrido

    printf("Tempo decorrido: %lu ticks\n", (unsigned long)xElapsedTime);
}

Aqui, xTaskGetTickCount() é usado para medir o tempo decorrido de uma operação.

3.3. TaskHandle_t

O tipo TaskHandle_t é um ponteiro que referencia uma tarefa, permitindo manipulá-la dinamicamente.

Exemplo: Criando e suspendendo uma tarefa

TaskHandle_t xTaskHandle = NULL;

void vTaskFunction(void *pvParameters) {
    while (1) {
        printf("Tarefa executando...\n");
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void app_main(void) {
    xTaskCreate(vTaskFunction, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, &xTaskHandle);

    vTaskDelay(pdMS_TO_TICKS(5000)); // Espera 5 segundos antes de suspender a tarefa
    vTaskSuspend(xTaskHandle);
    printf("Tarefa suspensa!\n");
}

Aqui, xTaskHandle é usado para suspender a tarefa após 5 segundos.

3.4. QueueHandle_t

O tipo QueueHandle_t armazena uma referência a uma fila, permitindo sua manipulação por diferentes tarefas.

Exemplo: Criando e verificando uma fila

QueueHandle_t xQueue;

void app_main(void) {
    xQueue = xQueueCreate(5, sizeof(int)); // Cria uma fila com capacidade para 5 inteiros

    if (xQueue != NULL) {
        printf("Fila criada com sucesso!\n");
    } else {
        printf("Falha ao criar a fila.\n");
    }
}

Aqui, QueueHandle_t é usado para armazenar a referência da fila criada.

3.5. SemaphoreHandle_t

O tipo SemaphoreHandle_t é usado para armazenar referência a semáforos e mutexes.

Exemplo: Criando um semáforo binário

SemaphoreHandle_t xSemaphore;

void app_main(void) {
    xSemaphore = xSemaphoreCreateBinary();

    if (xSemaphore != NULL) {
        printf("Semáforo criado!\n");
    } else {
        printf("Falha ao criar semáforo.\n");
    }
}

Aqui, SemaphoreHandle_t armazena o manipulador do semáforo criado.

3.6. TimerHandle_t

O tipo TimerHandle_t é usado para armazenar referências a timers criados no FreeRTOS.

Exemplo: Criando um timer que dispara a cada 2 segundos

TimerHandle_t xTimer;

void vTimerCallback(TimerHandle_t xTimer) {
    printf("Timer expirado!\n");
}

void app_main(void) {
    xTimer = xTimerCreate("MeuTimer", pdMS_TO_TICKS(2000), pdTRUE, NULL, vTimerCallback);

    if (xTimer != NULL) {
        xTimerStart(xTimer, 0);
        printf("Timer iniciado!\n");
    } else {
        printf("Falha ao criar o timer.\n");
    }
}

Aqui, TimerHandle_t armazena a referência do timer criado.

4. Uso de Sufixos em Funções e Variáveis do FreeRTOS

Além dos prefixos e tipos de dados padronizados, o FreeRTOS também utiliza sufixos em funções e variáveis para indicar propriedades específicas. Esses sufixos ajudam a identificar rapidamente características como escopo, tipo de dado ou comportamento esperado da função.

Os principais sufixos usados no FreeRTOS são:

• FromISR – Indica que a função pode ser chamada a partir de uma interrupção.
• _t – Indica que o nome refere-se a um tipo de dado.
• Handle – Representa um manipulador para um objeto do FreeRTOS.
• Ticks – Refere-se a unidades de tempo do sistema (ticks).
• MS – Representa valores em milissegundos.

A seguir, exploramos cada um desses sufixos com exemplos práticos.

4.1. Sufixo FromISR

Funções que podem ser chamadas dentro de um handler de interrupção possuem o sufixo FromISR. Isso é necessário porque chamadas dentro de interrupções não podem executar determinadas operações do sistema operacional, como esperar indefinidamente (portMAX_DELAY).

Exemplo: Enviando um item para uma fila dentro de uma interrupção

QueueHandle_t xQueue;

void IRAM_ATTR vISRHandler(void *arg) {
    int valor = 10;
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    xQueueSendFromISR(xQueue, &valor, &xHigherPriorityTaskWoken);

    if (xHigherPriorityTaskWoken == pdTRUE) {
        portYIELD_FROM_ISR();
    }
}

void app_main(void) {
    xQueue = xQueueCreate(5, sizeof(int));

    gpio_install_isr_service(0);
    gpio_isr_handler_add(GPIO_NUM_4, vISRHandler, NULL);
}

Aqui, xQueueSendFromISR() é usado para evitar bloqueios dentro da interrupção.

4.2. Sufixo _t

O sufixo _t indica que o nome representa um tipo de dado definido pelo FreeRTOS.

Exemplo: Utilizando tipos de dados do FreeRTOS

BaseType_t xStatus;
TickType_t xTime;
QueueHandle_t xQueue;

Aqui, BaseType_t, TickType_t e QueueHandle_t seguem essa convenção.

4.3. Sufixo Handle

O sufixo Handle é usado para representar manipuladores de objetos do FreeRTOS, como tarefas, filas, semáforos e timers.

Exemplo: Criando e manipulando uma tarefa

TaskHandle_t xTaskHandle = NULL;

void vTaskFunction(void *pvParameters) {
    while (1) {
        printf("Executando tarefa...\n");
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void app_main(void) {
    xTaskCreate(vTaskFunction, "MinhaTarefa", configMINIMAL_STACK_SIZE, NULL, 1, &xTaskHandle);
    vTaskDelay(pdMS_TO_TICKS(5000));
    vTaskDelete(xTaskHandle);
}

Aqui, TaskHandle_t armazena o manipulador da tarefa para que possamos manipulá-la posteriormente.

4.4. Sufixo Ticks

O sufixo Ticks indica que o valor da variável ou função está expresso em ticks de sistema.

Exemplo: Calculando tempo em ticks

TickType_t xStartTime, xElapsedTime;

void app_main(void) {
    xStartTime = xTaskGetTickCount(); // Obtém tempo atual
    vTaskDelay(pdMS_TO_TICKS(2000)); // Aguarda 2 segundos
    xElapsedTime = xTaskGetTickCount() - xStartTime;

    printf("Tempo decorrido: %lu ticks\n", (unsigned long)xElapsedTime);
}

Aqui, xStartTime e xElapsedTime armazenam valores em ticks do sistema.

4.5. Sufixo MS

O sufixo MS é usado para representar valores em milissegundos.

Exemplo: Definindo tempos em milissegundos

#define TEMPO_DELAY_MS 500

void app_main(void) {
    vTaskDelay(pdMS_TO_TICKS(TEMPO_DELAY_MS)); // Converte para ticks
    printf("Aguardou %d ms\n", TEMPO_DELAY_MS);
}

Aqui, TEMPO_DELAY_MS representa um tempo em milissegundos.

Resumo da Seção

Os sufixos no FreeRTOS ajudam a identificar o propósito de variáveis e funções rapidamente:

5. Prefixos de Retorno de Funções e Variáveis no FreeRTOS

Além dos prefixos usados para categorizar funções (xTask, vTask, xQueue etc.), o FreeRTOS também utiliza prefixos em variáveis e valores de retorno para indicar tipos de dados específicos. Esses prefixos ajudam a identificar rapidamente a natureza da variável ou o tipo de dado que uma função retorna.

Os principais prefixos utilizados no FreeRTOS incluem:

A seguir, exploramos cada um desses prefixos com exemplos práticos.

5.1. Prefixo u (Unsigned)

O prefixo u indica que a variável é um número inteiro sem sinal, ou seja, não pode armazenar valores negativos.

Exemplo: Contador sem sinal

uint8_t uCounter = 0;

void app_main(void) {
    for (uCounter = 0; uCounter < 10; uCounter++) {
        printf("Contador: %u\n", uCounter);
    }
}

Aqui, uCounter é uma variável do tipo uint8_t, que é um inteiro sem sinal de 8 bits.

5.2. Prefixo x (Retorno de Função)

O prefixo x é usado em funções que retornam um valor de status, geralmente do tipo BaseType_t.

Exemplo: Verificando status da criação de uma tarefa

BaseType_t xStatus;

void app_main(void) {
    xStatus = xTaskCreate(vTaskFunction, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, NULL);

    if (xStatus == pdPASS) {
        printf("Tarefa criada com sucesso!\n");
    } else {
        printf("Falha ao criar a tarefa.\n");
    }
}

O xTaskCreate() retorna um BaseType_t, e o valor de retorno xStatus indica se a operação foi bem-sucedida.

5.3. Prefixo v (Void)

O prefixo v é usado para funções que não retornam valores, ou seja, cujo tipo de retorno é void.

Exemplo: Função sem retorno

void vTaskFunction(void *pvParameters) {
    while (1) {
        printf("Executando tarefa...\n");
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

A função vTaskFunction() não retorna valores, então segue a convenção v.

5.4. Prefixo ux (Unsigned BaseType_t)

O prefixo ux é usado para variáveis do tipo UBaseType_t, que é um inteiro sem sinal usado para contadores e índices.

Exemplo: Usando UBaseType_t para armazenar um índice

UBaseType_t uxIndex;

void app_main(void) {
    for (uxIndex = 0; uxIndex < 5; uxIndex++) {
        printf("Índice: %u\n", (unsigned int)uxIndex);
    }
}

O UBaseType_t é frequentemente usado para contadores e índices em loops.

5.5. Prefixo e (Enumeração)

O prefixo e indica que a variável é uma enumeração (enum), usada para definir valores simbólicos.

Exemplo: Obtendo o estado de uma tarefa

eTaskState eState;

void app_main(void) {
    eState = eTaskGetState(NULL);
    printf("Estado da tarefa: %d\n", eState);
}

O eTaskGetState() retorna um valor do tipo eTaskState, que segue a convenção e.

5.6. Prefixo p (Pointer)

O prefixo p é usado para variáveis que armazenam ponteiros.

Exemplo: Ponteiro para uma string

char *pMessage = "Olá, FreeRTOS!";

void app_main(void) {
    printf("%s\n", pMessage);
}

O pMessage armazena um ponteiro para uma string.

5.7. Prefixo s (String)

O prefixo s indica que a variável é uma string.

Exemplo: Definição de uma string

const char *sWelcomeMessage = "Bem-vindo ao FreeRTOS!";

void app_main(void) {
    printf("%s\n", sWelcomeMessage);
}

Aqui, sWelcomeMessage representa uma string constante.

5.8. Prefixo pc e pu (Ponteiros para constantes)

Os prefixos pc e pu são usados para indicar ponteiros para constantes, diferenciando entre char e unsigned.

Exemplo: Ponteiro para constante

const char *pcMessage = "Mensagem constante";
const uint8_t *puData;

O pcMessage aponta para uma string constante, enquanto puData pode apontar para um buffer de dados constantes.

5.9. Prefixo c (Char)

O prefixo c indica que a variável é do tipo char.

Exemplo: Armazenando um caractere

char cCharacter = 'A';

void app_main(void) {
    printf("Caractere: %c\n", cCharacter);
}

Aqui, cCharacter armazena um único caractere.

5.10. Prefixo pd (Port Define)

O prefixo pd é usado para constantes internas do FreeRTOS, geralmente definindo estados ou resultados de funções.

Exemplo: Uso de pdPASS e pdFALSE

if (xTaskCreate(vTaskFunction, "Task", configMINIMAL_STACK_SIZE, NULL, 1, NULL) == pdPASS) {
    printf("Tarefa criada com sucesso!\n");
}

if (xSemaphoreTake(xSemaphore, 0) == pdFALSE) {
    printf("Semáforo não disponível.\n");
}

O pdPASS indica sucesso e pdFALSE indica falha na tentativa de captura do semáforo.

6. Boas Práticas na Nomenclatura do FreeRTOS

O uso correto da nomenclatura do FreeRTOS não é apenas uma questão de padronização, mas também uma prática essencial para aumentar a legibilidade, manutenibilidade e clareza do código. Aqui estão algumas boas práticas recomendadas ao trabalhar com o FreeRTOS.

6.1. Use os Prefixos e Sufixos Corretamente

O FreeRTOS adota uma convenção de nomenclatura bem estruturada para ajudar os desenvolvedores a entender rapidamente o propósito de funções e variáveis. Para manter essa clareza:

Use os prefixos apropriados para funções:

• Funções que retornam um status devem começar com x (ex.: xTaskCreate()).
• Funções que não retornam valores devem começar com v (ex.: vTaskDelay()).
• Funções que podem ser chamadas dentro de interrupções devem terminar com FromISR (ex.: xQueueSendFromISR()).

Use os tipos de dados apropriados:

• Utilize BaseType_t e UBaseType_t para variáveis de controle.
• Use TickType_t para valores relacionados ao tempo.
• Manipuladores devem ser sempre declarados com seus respectivos tipos (TaskHandle_t, QueueHandle_t, etc.).

Respeite a nomenclatura dos sufixos:

• Para variáveis que representam tempo, use Ticks ou MS.
• Para ponteiros, use p, pc, ou pu, conforme necessário.
• Para caracteres e strings, use c e s.

6.2. Evite Modificar os Nomes das Funções do FreeRTOS

As funções do FreeRTOS seguem uma convenção bem definida e não devem ser renomeadas. Isso pode causar confusão e dificultar a manutenção do código.

Evite fazer isso:

#define CriarTarefa xTaskCreate  // NÃO RECOMENDADO
CriarTarefa(vTaskFunction, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, NULL);

Forma correta:

xTaskCreate(vTaskFunction, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, NULL);

Alterar nomes de funções pode tornar o código difícil de entender para outros desenvolvedores.

6.3. Nomeie Tarefas, Filas e Recursos de Forma Clara

Sempre nomeie tarefas e recursos do FreeRTOS com nomes descritivos que indiquem sua função.

Evite nomes genéricos:

TaskHandle_t xTarefa1;
QueueHandle_t xFila;

Use nomes descritivos:

TaskHandle_t xTaskSensor;
QueueHandle_t xQueueMensagens;

Nomes descritivos tornam o código mais intuitivo e fácil de depurar.

6.4. Utilize pdMS_TO_TICKS() para Conversão de Tempo

O FreeRTOS mede o tempo em ticks, então é essencial converter corretamente valores de tempo em milissegundos para ticks.

Evite valores fixos em ticks:

vTaskDelay(100); // NÃO RECOMENDADO, pois depende da configuração do sistema

Use pdMS_TO_TICKS():

vTaskDelay(pdMS_TO_TICKS(100)); // Correto e portátil

Isso garante que o código funcione corretamente em diferentes configurações de configTICK_RATE_HZ.

6.5. Declare Variáveis no Escopo Adequado

Variáveis globais podem ser úteis, mas devem ser usadas com cuidado para evitar conflitos e garantir encapsulamento.

Use escopo local sempre que possível:

void vTaskFunction(void *pvParameters) {
    uint32_t ulContador = 0; // Variável local, melhor encapsulamento
    while (1) {
        ulContador++;
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

Evite variáveis globais desnecessárias:

uint32_t ulContadorGlobal; // Pode causar conflitos e dificultar depuração

void vTaskFunction(void *pvParameters) {
    while (1) {
        ulContadorGlobal++;
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

Sempre prefira variáveis locais, a menos que seja essencial compartilhá-las entre tarefas.

6.6. Documente Seu Código

O FreeRTOS facilita o desenvolvimento de sistemas embarcados, mas um código mal documentado pode se tornar difícil de entender e manter.

Exemplo de código bem documentado:

/**
 * @brief  Função da tarefa que lê sensores periodicamente.
 * @param  pvParameters: Parâmetros da tarefa (não usados aqui).
 */
void vTaskSensor(void *pvParameters) {
    while (1) {
        printf("Lendo sensor...\n");
        vTaskDelay(pdMS_TO_TICKS(1000)); // Espera 1 segundo
    }
}

Uma boa documentação ajuda a equipe de desenvolvimento e facilita futuras manutenções.

6.7. Teste e Valide o Código Com Regularidade

Ao trabalhar com o FreeRTOS, é essencial testar o código regularmente para garantir que ele funcione corretamente e não tenha problemas de concorrência.

Dicas para testes eficazes:

• Use configASSERT() para verificar condições críticas.
• Monitore o uso de memória e pilha (uxTaskGetStackHighWaterMark()).
• Teste cenários de alta concorrência e preempção para evitar deadlocks e starvation.

Conclusão

O FreeRTOS fornece um sistema operacional leve e eficiente para sistemas embarcados, mas seu uso correto exige boas práticas na nomenclatura e estrutura do código. Resumindo:

Use os prefixos e sufixos corretamente para garantir legibilidade.
Não modifique nomes das funções do FreeRTOS para manter compatibilidade.
Dê nomes descritivos a tarefas, filas e semáforos para facilitar manutenção.
Sempre converta milissegundos para ticks com pdMS_TO_TICKS().
Evite variáveis globais desnecessárias para reduzir riscos de conflitos.
Documente e teste seu código regularmente para manter qualidade.

Seguindo essas boas práticas, você garantirá que seus projetos baseados no FreeRTOS sejam mais organizados, confiáveis e fáceis de manter.

The post Introdução à Nomenclatura do FreeRTOS first appeared on MCU & FPGA.

Neste artigo, iniciamos uma série de artigos sobre padrões de projeto aplicáveis ao desenvolvimento em C para microcontroladores. Para cada padrão, descreveremos seu propósito, vantagens e um cenário de aplicação. Cada um desses padrões será tratado com mais profundidade em artigos separados ao longo desta série.

Este material tem como base os seguintes livros de referência:

• Design Patterns for Embedded Systems in C de Bruce Powel Douglass
• Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems de Bruce Powel Douglass
• Patterns of Enterprise Application Architecture de Martin Fowler
• Domain-Driven Design de Eric Evans
• Design Patterns: Elements of Reusable Object-Oriented Software de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (Gang of Four)

Minha Jornada com Padrões de Projeto em C

Quando comecei a programar em Java, há 20 anos, fiquei fascinado com a capacidade da linguagem de representar objetos em forma de código. Isso me levou a buscar mais conhecimento sobre o assunto, e logo me deparei com livros como Domain-Driven Design de Eric Evans, Patterns of Enterprise Application Architecture de Martin Fowler e Design Patterns. O entendimento desses padrões de projeto abriu minha mente para a importância de desenvolver código altamente estruturado e de qualidade.

Entretanto, nunca havia considerado que no contexto procedural da linguagem C também pudessem existir tais padrões. Para minha surpresa, em uma conversa recente com meu tutor na Embarcatech, fui apresentado ao conceito de Orientação a Objetos em C. Não estou falando de C++, mas sim de C puro! Isso me despertou uma enorme curiosidade, e iniciei uma pesquisa sobre o tema. Foi então que me deparei com os livros de Bruce Powel Douglass sobre padrões de projeto em sistemas embarcados.

Ainda não tive meu boooommmm de entendimento total no contexto de microcontroladores, pois não consegui ler os livros por completo. No entanto, como tudo que estudo vira material para meus sites e livros (um dia eles saem!), decidi abordar um padrão de projeto por mês e compartilhar essas descobertas com vocês.

Padrões de Projeto para Sistemas Embarcados

Aqui está uma lista abrangente dos principais padrões de projeto aplicáveis ao desenvolvimento de software para microcontroladores e sistemas embarcados. Eles estão organizados por categoria para facilitar a compreensão:

1. Padrões de Arquitetura de Subsistema e Componentes

Os padrões desta categoria ajudam a estruturar o software embarcado de forma modular, facilitando a manutenção, a escalabilidade e a reutilização de código. Eles definem como os diferentes módulos do sistema interagem entre si e organizam a arquitetura geral do software.

1.1 Layered Pattern (Padrão em Camadas)

• Problema que resolve: Mistura de responsabilidades dentro do código, dificultando a manutenção e a reutilização.
• Cenário de uso: Projetos que exigem separação clara entre hardware, drivers, middleware e aplicação.
• Vantagens: Organização do código, maior reutilização de componentes e facilidade de manutenção.
• O que é: Divide o sistema em camadas hierárquicas onde cada uma depende apenas da camada inferior, promovendo um código mais organizado e de fácil escalabilidade.

1.2 Microkernel Architecture Pattern

• Problema que resolve: Sistemas grandes e complexos com funcionalidades variáveis que precisam ser ativadas ou desativadas dinamicamente.
• Cenário de uso: Sistemas embarcados modulares que precisam suportar diferentes configurações de hardware ou software.
• Vantagens: Melhor gerenciamento de recursos e flexibilidade na ativação/desativação de módulos.
• O que é: Mantém um núcleo mínimo do sistema (microkernel) e permite adicionar funcionalidades por meio de módulos externos.

1.3 Component-Based Architecture Pattern

• Problema que resolve: Alto acoplamento entre módulos, dificultando a reutilização e a substituição de componentes.
• Cenário de uso: Sistemas embarcados que precisam de alta modularidade, como IoT e automação industrial.
• Vantagens: Facilita a manutenção e a atualização do sistema sem afetar outros componentes.
• O que é: Estrutura o software em componentes independentes que interagem por meio de interfaces bem definidas.

1.4 Virtual Machine Pattern

• Problema que resolve: Dificuldade em portar software para diferentes plataformas de hardware.
• Cenário de uso: Sistemas embarcados que precisam rodar em múltiplos tipos de hardware sem grandes adaptações no código.
• Vantagens: Independência de hardware e reutilização de código entre diferentes plataformas.
• O que é: Cria uma camada de abstração que simula um ambiente de execução padronizado, permitindo que o software funcione de forma mais genérica.

1.5 Hierarchical Control Pattern

• Problema que resolve: Falta de organização em sistemas embarcados que possuem múltiplos níveis de controle.
• Cenário de uso: Sistemas que exigem tomada de decisão em diferentes níveis, como controle de motores e automação.
• Vantagens: Melhor separação de responsabilidades e hierarquia clara no fluxo de controle.
• O que é: Divide o controle do sistema em diferentes níveis hierárquicos, permitindo um gerenciamento mais eficiente e modular.

1.6 Recursive Containment Pattern

• Problema que resolve: Complexidade na organização de subsistemas que possuem componentes recursivos ou aninhados.
• Cenário de uso: Sistemas embarcados que possuem módulos que precisam ser tratados como subsistemas independentes.
• Vantagens: Organização modular clara e facilidade na expansão do sistema.
• O que é: Estrutura os componentes do sistema de maneira hierárquica e recursiva, onde cada elemento pode conter outros elementos semelhantes.

1.7 ROOM Pattern (Real-Time Object-Oriented Modeling)

O que é: Um padrão que fornece uma abordagem orientada a objetos para modelagem de sistemas de tempo real.

Problema que resolve: Falta de um modelo estruturado para desenvolvimento orientado a objetos em sistemas embarcados.

Cenário de uso: Sistemas de tempo real que precisam seguir um modelo de desenvolvimento baseado em objetos.

Vantagens: Modelagem bem definida, facilitando o desenvolvimento e manutenção do sistema.

2. Padrões de Concorrência

Os padrões desta categoria lidam com a execução de múltiplas tarefas em sistemas embarcados, garantindo que processos concorrentes operem de maneira eficiente e segura. Eles ajudam a evitar condições de corrida, otimizar a comunicação entre tarefas e melhorar a previsibilidade do sistema.

2.1 Message Queuing Pattern

• Problema que resolve: Concorrência e sincronização inadequada entre diferentes tarefas que compartilham dados.
• Cenário de uso: Sistemas embarcados multitarefa onde tarefas precisam trocar informações de forma controlada.
• Vantagens: Evita condições de corrida e melhora a organização da comunicação entre tarefas.
• O que é: Utiliza filas de mensagens para permitir a comunicação assíncrona entre tarefas de forma controlada.

2.2 Interrupt Pattern

• Problema que resolve: Latência alta ao lidar com eventos externos devido a verificações contínuas (polling).
• Cenário de uso: Sistemas que precisam responder rapidamente a eventos externos, como acionamento de sensores.
• Vantagens: Reduz consumo de CPU, melhora tempo de resposta e eficiência energética.
• O que é: Utiliza interrupções de hardware para lidar com eventos externos de forma imediata, evitando verificações constantes.

2.3 Guarded Call Pattern

• Problema que resolve: Concorrência inadequada e acesso simultâneo a recursos compartilhados.
• Cenário de uso: Sistemas embarcados multitarefa que precisam garantir a execução segura de chamadas a funções compartilhadas.
• Vantagens: Previne corrupção de dados e melhora a confiabilidade do sistema.
• O que é: Implementa verificações e sincronização para garantir que chamadas a funções críticas sejam executadas apenas quando seguras.

2.4 Rendezvous Pattern

• Problema que resolve: Sincronização inadequada entre duas ou mais tarefas que precisam se comunicar diretamente.
• Cenário de uso: Sistemas onde duas tarefas dependem do estado da outra para avançar, como protocolos de comunicação.
• Vantagens: Melhora a coordenação entre tarefas e evita espera passiva.
• O que é: Estabelece um mecanismo onde duas tarefas precisam estar prontas simultaneamente para prosseguir com a comunicação.

2.5 Cyclic Executive Pattern

• Problema que resolve: Complexidade e overhead na gestão de múltiplas tarefas concorrentes.
• Cenário de uso: Sistemas embarcados simples sem RTOS, onde tarefas precisam ser executadas periodicamente.
• Vantagens: Controle determinístico e fácil implementação.
• O que é: Um loop fixo que executa cada tarefa em uma ordem predefinida dentro de um ciclo fixo de tempo.

2.6 Round Robin Pattern

• Problema que resolve: Falta de tempo de CPU equitativo entre tarefas concorrentes.
• Cenário de uso: Sistemas embarcados com multitarefa onde cada processo deve receber um tempo justo de execução.
• Vantagens: Distribuição justa de CPU entre tarefas, evitando monopolização do processador.
• O que é: Um mecanismo de escalonamento que alterna a execução de cada tarefa por um tempo determinado, em um ciclo contínuo.

2.7 Static Priority Pattern

• Problema que resolve: Falta de controle sobre a execução de tarefas críticas em tempo real.
• Cenário de uso: Sistemas de tempo real que exigem resposta imediata para determinadas tarefas prioritárias.
• Vantagens: Garante que tarefas críticas sejam executadas antes das menos prioritárias.
• O que é: Define prioridades fixas para cada tarefa, garantindo que aquelas com maior prioridade sempre sejam executadas primeiro.

2.8 Dynamic Priority Pattern

• Problema que resolve: Problemas de bloqueios ou inversão de prioridade em sistemas multitarefa.
• Cenário de uso: Sistemas onde a prioridade das tarefas pode mudar com base na carga de trabalho.
• Vantagens: Melhora o balanceamento de carga do processador e evita deadlocks.
• O que é: Ajusta dinamicamente as prioridades das tarefas conforme necessário para garantir melhor desempenho e tempo de resposta.

3. Padrões de Gerenciamento de Memória

Os padrões desta categoria ajudam a otimizar o uso da memória em sistemas embarcados, onde os recursos são frequentemente limitados. Eles garantem que a alocação e a liberação de memória ocorram de forma eficiente, evitando desperdícios e garantindo previsibilidade no consumo de RAM.

3.1 Static Allocation Pattern

• Problema que resolve: Uso imprevisível de memória devido a alocações dinâmicas, que podem causar fragmentação e falhas em sistemas embarcados críticos.
• Cenário de uso: Sistemas embarcados com recursos limitados que precisam de controle total sobre a alocação de memória.
• Vantagens: Evita fragmentação da memória e melhora a previsibilidade do uso de RAM.
• O que é: Utiliza apenas alocações estáticas, definindo variáveis globais e buffers fixos durante a compilação.

3.2 Pool Allocation Pattern

• Problema que resolve: Ineficiência e fragmentação de memória ao alocar e desalocar pequenos blocos dinamicamente.
• Cenário de uso: Sistemas que precisam gerenciar dinamicamente a alocação de pequenos blocos de memória sem risco de fragmentação.
• Vantagens: Reduz fragmentação e melhora a previsibilidade no tempo de acesso à memória.
• O que é: Aloca um conjunto fixo de blocos de memória e os gerencia em um pool pré-definido, evitando alocações e desalocações imprevisíveis.

3.3 Fixed-Sized Buffer Pattern

• Problema que resolve: Overhead e fragmentação ao lidar com buffers de tamanho variável.
• Cenário de uso: Aplicações que precisam de buffers para comunicação ou armazenamento temporário de dados.
• Vantagens: Maior eficiência no gerenciamento de memória e redução de falhas associadas a alocações dinâmicas.
• O que é: Define buffers de tamanho fixo e pré-alocados para operações específicas, garantindo previsibilidade e eficiência no uso da memória.

3.4 Smart Pointer Pattern

• Problema que resolve: Vazamento de memória devido a alocações dinâmicas sem liberação adequada.
• Cenário de uso: Sistemas embarcados que precisam gerenciar dinamicamente a memória sem risco de vazamentos.
• Vantagens: Reduz a necessidade de gerenciar manualmente a liberação de memória, evitando erros de alocação.
• O que é: Implementa ponteiros inteligentes que controlam automaticamente a alocação e liberação da memória associada.

3.5 Garbage Collection Pattern

• Problema que resolve: Necessidade de liberação manual de memória em sistemas que fazem uso intenso de alocação dinâmica.
• Cenário de uso: Aplicações complexas que utilizam alocação dinâmica e exigem gerenciamento automatizado da memória.
• Vantagens: Libera automaticamente memória não utilizada, reduzindo erros de alocação e melhorando a estabilidade do sistema.
• O que é: Implementa um mecanismo que monitora e libera memória não referenciada automaticamente.

3.6 Garbage Compactor Pattern

• Problema que resolve: Fragmentação de memória ao longo do tempo devido a alocações e desalocações dinâmicas.
• Cenário de uso: Sistemas embarcados com uso dinâmico de memória onde a fragmentação pode comprometer a alocação de novos blocos.
• Vantagens: Reduz fragmentação de memória e melhora a eficiência da alocação.
• O que é: Reorganiza a memória alocada periodicamente para eliminar fragmentação e garantir blocos contíguos livres.

4. Padrões de Gerenciamento de Recursos

Os padrões desta categoria garantem o acesso eficiente e seguro a recursos compartilhados em sistemas embarcados. Eles ajudam a evitar problemas como deadlocks, inversão de prioridade e acesso concorrente inadequado a periféricos e variáveis globais.

4.1 Critical Section Pattern

• Problema que resolve: Condições de corrida causadas por múltiplas tarefas acessando simultaneamente um mesmo recurso.
• Cenário de uso: Sistemas multitarefa onde variáveis globais ou periféricos precisam ser acessados por diferentes processos.
• Vantagens: Evita corrupção de dados e garante acesso controlado aos recursos compartilhados.
• O que é: Implementa seções críticas onde apenas uma tarefa pode acessar um recurso por vez, utilizando mutexes, semáforos ou desativação de interrupções.

4.2 Priority Inheritance Pattern

• Problema que resolve: Inversão de prioridade, onde uma tarefa de baixa prioridade impede a execução de uma tarefa crítica.
• Cenário de uso: Sistemas de tempo real onde tarefas críticas podem ser bloqueadas por tarefas de menor prioridade.
• Vantagens: Garante que tarefas de alta prioridade não fiquem bloqueadas desnecessariamente.
• O que é: Permite que uma tarefa de baixa prioridade herde temporariamente a prioridade de uma tarefa de maior prioridade até liberar o recurso.

4.3 Highest Locker Pattern

• Problema que resolve: Deadlocks gerados por múltiplas tarefas bloqueando recursos de forma desordenada.
• Cenário de uso: Sistemas onde várias tarefas competem por múltiplos recursos compartilhados.
• Vantagens: Evita deadlocks e melhora a previsibilidade do sistema.
• O que é: Assegura que apenas a tarefa com a maior prioridade entre as que precisam do recurso possa bloqueá-lo, forçando uma ordem de acesso previsível.

4.4 Priority Ceiling Pattern

• Problema que resolve: Inversão de prioridade e bloqueios inesperados devido a compartilhamento inadequado de recursos.
• Cenário de uso: Sistemas embarcados críticos onde múltiplas tarefas acessam o mesmo recurso.
• Vantagens: Evita bloqueios imprevisíveis e melhora o tempo de resposta das tarefas críticas.
• O que é: Define uma prioridade máxima para cada recurso compartilhado, garantindo que apenas tarefas com prioridade igual ou superior possam acessá-lo.

4.5 Simultaneous Locking Pattern

• Problema que resolve: Deadlocks e ineficiência ao acessar múltiplos recursos compartilhados ao mesmo tempo.
• Cenário de uso: Sistemas onde múltiplas tarefas precisam acessar vários recursos simultaneamente.
• Vantagens: Reduz o risco de deadlocks e melhora a eficiência no gerenciamento de recursos.
• O que é: Implementa um mecanismo de bloqueio simultâneo de todos os recursos necessários antes de iniciar uma operação crítica.

4.6 Ordered Locking Pattern

• Problema que resolve: Deadlocks causados por ordem inconsistente de bloqueio de recursos.
• Cenário de uso: Sistemas multitarefa onde diferentes processos podem acessar recursos em ordens variadas.
• Vantagens: Previne deadlocks sem necessidade de mecanismos complexos de verificação.
• O que é: Impõe uma ordem fixa de bloqueio de recursos, garantindo que todas as tarefas sigam a mesma sequência ao acessá-los.

5. Padrões de Distribuição e Comunicação

Os padrões desta categoria garantem uma comunicação eficiente entre diferentes partes do sistema, seja dentro de um único microcontrolador ou entre múltiplos dispositivos conectados em rede. Eles ajudam a estruturar a troca de informações de forma confiável e escalável.

5.1 Shared Memory Pattern

• Problema que resolve: Comunicação ineficiente entre tarefas devido ao uso de filas ou mensagens que geram sobrecarga.
• Cenário de uso: Sistemas embarcados que precisam compartilhar grandes volumes de dados entre múltiplas tarefas ou processadores.
• Vantagens: Baixa latência e alta taxa de transferência de dados.
• O que é: Um espaço de memória compartilhado é utilizado como meio de comunicação entre processos, evitando a necessidade de cópias de dados desnecessárias.

5.2 Remote Method Call Pattern

• Problema que resolve: Comunicação entre processos distribuídos sem uma interface de baixo nível bem definida.
• Cenário de uso: Sistemas embarcados que se comunicam via redes como CAN, Modbus ou Ethernet.
• Vantagens: Oculta a complexidade da comunicação e facilita a implementação de chamadas remotas.
• O que é: Permite que um processo invoque funções em outro sistema remoto como se fossem chamadas locais.

5.3 Observer Pattern

• Problema que resolve: Comunicação ineficiente entre módulos que precisam ser notificados sobre mudanças de estado.
• Cenário de uso: Sistemas de eventos, sensores e notificações em tempo real.
• Vantagens: Reduz o acoplamento entre os módulos e melhora a escalabilidade do sistema.
• O que é: Define um mecanismo de notificação assíncrona onde múltiplos observadores podem ser informados sobre mudanças de estado de um único sujeito.

5.4 Data Bus Pattern

• Problema que resolve: Comunicação complexa e desorganizada entre múltiplos módulos do sistema.
• Cenário de uso: Arquiteturas de sistemas embarcados que exigem comunicação padronizada entre diversos componentes.
• Vantagens: Centraliza a comunicação, reduz a complexidade e melhora a modularidade.
• O que é: Implementa um barramento de dados onde múltiplos componentes podem publicar e assinar mensagens de forma padronizada.

5.5 Proxy Pattern

• Problema que resolve: Comunicação ineficiente e insegura entre componentes distribuídos ou remotos.
• Cenário de uso: Sistemas embarcados que utilizam interfaces de comunicação externas ou protocolos remotos.
• Vantagens: Melhora a segurança, reduz a latência e otimiza a comunicação entre módulos separados.
• O que é: Um intermediário que atua como representante de outro objeto, fornecendo uma interface simplificada e segura para acessá-lo.

5.6 Broker Pattern

• Problema que resolve: Dependência direta entre módulos que precisam trocar informações de forma distribuída.
• Cenário de uso: Sistemas de comunicação assíncrona, como IoT e redes industriais.
• Vantagens: Desacopla os módulos e permite escalabilidade na comunicação.
• O que é: Introduz um broker (intermediário) que gerencia a comunicação entre diferentes partes do sistema sem que elas precisem conhecer diretamente umas às outras.

6. Padrões de Segurança e Confiabilidade

Os padrões desta categoria garantem que o sistema continue operando de forma segura e confiável mesmo diante de falhas de hardware, software ou interferências externas. Eles são especialmente importantes em sistemas críticos, como automação industrial, aeroespacial e dispositivos médicos.

6.1 Protected Single Channel Pattern

• Problema que resolve: Falhas na comunicação entre módulos devido a corrupção de dados.
• Cenário de uso: Sistemas que transmitem dados críticos via barramentos compartilhados.
• Vantagens: Garante a integridade dos dados transmitidos.
• O que é: Implementa mecanismos de verificação, como CRC e checksum, para assegurar que as mensagens recebidas sejam íntegras.

6.2 Homogeneous Redundancy Pattern

• Problema que resolve: Falhas em componentes críticos sem um sistema de backup imediato.
• Cenário de uso: Sistemas embarcados de missão crítica, como aeronaves e equipamentos médicos.
• Vantagens: Aumenta a confiabilidade do sistema ao replicar funcionalidades críticas.
• O que é: Usa múltiplas instâncias idênticas de um componente para fornecer redundância e permitir recuperação automática em caso de falha.

6.3 Triple Modular Redundancy (TMR) Pattern

• Problema que resolve: Erros transitórios ou permanentes em hardware crítico.
• Cenário de uso: Sistemas de controle de segurança, como sensores de usinas nucleares e controle de motores em aeronaves.
• Vantagens: Aumenta a resiliência do sistema contra falhas de hardware.
• O que é: Utiliza três módulos independentes executando a mesma tarefa e um votador que decide o resultado correto com base no consenso entre os três.

6.4 Heterogeneous Redundancy Pattern

• Problema que resolve: Falhas que afetam sistemas idênticos devido a vulnerabilidades comuns.
• Cenário de uso: Aplicações onde falhas sistêmicas devem ser evitadas a todo custo.
• Vantagens: Maior robustez contra falhas comuns.
• O que é: Usa diferentes implementações de um mesmo sistema para reduzir o risco de falhas sistêmicas.

6.5 Monitor-Actuator Pattern

• Problema que resolve: Falta de monitoramento automático para detectar falhas antes que causem danos ao sistema.
• Cenário de uso: Sistemas que precisam garantir operação contínua sem intervenção humana constante.
• Vantagens: Aumenta a resiliência do sistema.
• O que é: Implementa sensores e atuadores que monitoram o estado do sistema e tomam ações preventivas quando necessário.

6.6 Sanity Check Pattern

• Problema que resolve: Comportamento imprevisível do sistema devido a erros internos ou falhas não detectadas.
• Cenário de uso: Sistemas embarcados que precisam garantir um funcionamento previsível e seguro.
• Vantagens: Detecta erros rapidamente e evita falhas catastróficas.
• O que é: Implementa verificações automáticas que garantem que o sistema esteja operando dentro dos parâmetros esperados.

6.7 Watchdog Pattern

• Problema que resolve: Travamento do sistema devido a loops infinitos ou falhas inesperadas.
• Cenário de uso: Qualquer sistema embarcado onde a operação contínua deve ser garantida.
• Vantagens: Melhora a estabilidade e recuperação do sistema.
• O que é: Utiliza um temporizador de supervisão (watchdog) que reinicia o sistema se uma falha for detectada.

6.8 Safety Executive Pattern

• Problema que resolve: Falha na tomada de decisões de segurança em sistemas críticos.
• Cenário de uso: Sistemas de segurança industrial e dispositivos médicos.
• Vantagens: Melhora a confiabilidade e a resposta a falhas.
• O que é: Implementa um mecanismo de supervisão que avalia continuamente os riscos e toma ações para evitar falhas graves.

7. Conclusão

Os padrões de projeto desempenham um papel fundamental no desenvolvimento de sistemas embarcados eficientes, seguros e escaláveis. Cada categoria de padrões abordada neste artigo fornece soluções estruturadas para problemas recorrentes, desde a organização da arquitetura até o gerenciamento de concorrência, memória, recursos, comunicação e segurança.

A escolha adequada dos padrões a serem utilizados em um projeto pode impactar diretamente na modularidade, desempenho e confiabilidade do sistema embarcado. Implementar esses padrões corretamente pode reduzir a complexidade do código, melhorar a manutenibilidade e garantir que o software funcione de forma previsível, mesmo em cenários críticos.

Nos próximos artigos desta série, exploraremos cada padrão em detalhes, apresentando exemplos práticos e sua aplicação em C para sistemas embarcados. Assim, engenheiros e desenvolvedores poderão aplicar esses conceitos de maneira eficaz em seus projetos.

The post Padrões de Projeto para Sistemas Embarcados em C first appeared on MCU & FPGA.

Para isso, três técnicas são amplamente utilizadas: mutex, semáforos e a suspensão do escalonador. Cada uma dessas abordagens tem seu melhor momento de aplicação e, se usada de maneira inadequada, pode levar a problemas de desempenho ou até mesmo a falhas difíceis de depurar. Neste artigo, exploraremos quando e como usar cada uma delas, incluindo exemplos práticos para facilitar a compreensão.

Mutex: Exclusão Mútua para Recursos Compartilhados

O mutex (mutual exclusion) é um mecanismo utilizado para garantir que apenas uma tarefa por vez tenha acesso a um recurso compartilhado. Ele funciona como um cadeado: a primeira tarefa que o adquire pode continuar a execução, enquanto as demais precisam aguardar sua liberação.

Quando Usar Mutex

• Quando há um recurso que não pode ser acessado simultaneamente por mais de uma tarefa.
• Para garantir consistência de dados ao modificar variáveis compartilhadas.
• Em sistemas operacionais com preempção habilitada, onde uma tarefa pode ser interrompida a qualquer momento.

Quando Evitar Mutex

• Quando há altíssima concorrência, pois as tarefas podem passar muito tempo bloqueadas, reduzindo o desempenho.
• Quando um recurso pode ser acessado de forma não exclusiva, ou seja, múltiplas tarefas podem lê-lo sem problemas.
• Quando há risco de deadlocks, onde múltiplas tarefas ficam bloqueadas esperando a liberação de mutexes que nunca ocorrerão.

Exemplo de Uso de Mutex no STM32F411RE com FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"
#include "stm32f4xx.h"

SemaphoreHandle_t xMutex;
int shared_resource = 0;

void Task1(void *pvParameters) {
    while(1) {
         if (xSemaphoreTake(xMutex, portMAX_DELAY)) {
                    shared_resource++;
                    printf("Task1: Recurso compartilhado = %d\n", shared_resource);
                    xSemaphoreGive(xMutex);
          }
          vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void Task2(void *pvParameters) {
    while(1) {
            if (xSemaphoreTake(xMutex, portMAX_DELAY)) {
                      shared_resource--;
                      printf("Task2: Recurso compartilhado = %d\n", shared_resource);
                      xSemaphoreGive(xMutex);
            }
           vTaskDelay(pdMS_TO_TICKS(500));
     }
}

int main() {
    xMutex = xSemaphoreCreateMutex();
    if (xMutex != NULL) {
            xTaskCreate(Task1, "Task 1", 128, NULL, 1, NULL);
            xTaskCreate(Task2, "Task 2", 128, NULL, 1, NULL);
            vTaskStartScheduler()
    }
    while(1);
}

Semáforos: Controle de Fluxo e Contagem de Recursos

Os semáforos são estruturas mais flexíveis que os mutexes e podem ser usados para diferentes propósitos. Eles operam com um contador interno, que pode permitir múltiplas tarefas acessando um mesmo recurso, dependendo da configuração.

Quando Usar Semáforos

• Para controlar múltiplas instâncias de um recurso compartilhado, como um conjunto de conexões disponíveis em um servidor.
• Para sincronizar tarefas, permitindo que uma aguarde a outra concluir uma operação antes de continuar.
• Em sistemas embarcados onde múltiplas tarefas precisam se comunicar sem causar bloqueios desnecessários.

Quando Evitar Semáforos

• Quando há necessidade de exclusão mútua. Um semáforo mal configurado pode permitir que múltiplas tarefas acessem um recurso crítico simultaneamente.
• Quando o código não foi planejado corretamente, podendo levar a inconsistências difíceis de depurar.
• Quando há possibilidade de inversão de prioridade, onde tarefas de baixa prioridade podem atrasar a execução de tarefas mais importantes.

Exemplo de Uso de Semáforo no STM32F411RE com FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"
#include "stm32f4xx.h"

SemaphoreHandle_t xSemaphore;
int shared_counter = 0;

void Task1(void *pvParameters) {
    while(1) {
        if (xSemaphoreTake(xSemaphore, portMAX_DELAY)) {
            shared_counter++;
            printf("Task1: Contador = %d\n", shared_counter);
            xSemaphoreGive(xSemaphore);
        }
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

void Task2(void *pvParameters) {
    while(1) {
        if (xSemaphoreTake(xSemaphore, portMAX_DELAY)) {
            shared_counter--;
            printf("Task2: Contador = %d\n", shared_counter);
            xSemaphoreGive(xSemaphore);
        }
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

int main() {
    xSemaphore = xSemaphoreCreateBinary();
    xSemaphoreGive(xSemaphore);
    if (xSemaphore != NULL) {
        xTaskCreate(Task1, "Task 1", 128, NULL, 1, NULL);
        xTaskCreate(Task2, "Task 2", 128, NULL, 1, NULL);
        vTaskStartScheduler();
    }
    while(1);
}

Suspensão do Escalonador: Controle Total com Custo Alto

A suspensão do escalonador (scheduler lock) é uma abordagem mais extrema, onde o sistema operacional pausa a troca de tarefas, garantindo que a tarefa em execução complete seu trabalho sem interrupções.

Quando Usar a Suspensão do Escalonador

• Quando uma operação crítica precisa ser executada em um curto período de tempo e não pode ser interrompida.
• Para seções de código extremamente curtas e atômicas, onde o impacto da suspensão do escalonador é mínimo.
• Em sistemas bare-metal sem suporte a mutexes ou semáforos.

Quando Evitar a Suspensão do Escalonador

• Quando há tarefas de tempo real que precisam responder rapidamente a eventos externos.
• Se o código protegido for muito longo, pois a suspensão prolongada do escalonador pode causar degradação significativa no desempenho do sistema.
• Em sistemas onde múltiplas CPUs são usadas, pois suspender o escalonador em um núcleo não impede que outros núcleos executem tarefas concorrentes.

Exemplo de Suspensão do Escalonador no STM32F411RE com FreeRTOS

#include "FreeRTOS.h"
#include "task.h"

void CriticalTask(void *pvParameters) {
    while(1) {
        vTaskSuspendAll(); // Suspende o escalonador
        // Código crítico
        printf("Executando tarefa crítica\n");
        xTaskResumeAll(); // Retoma o escalonador
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

int main() {
    xTaskCreate(CriticalTask, "Critical Task", 128, NULL, 1, NULL);
    vTaskStartScheduler();
    while(1);
}

Abordagem para Dispositivos I2C e SPI

Os protocolos de comunicação como I2C e SPI são amplamente utilizados em sistemas embarcados para comunicação entre microcontroladores e periféricos. A abordagem correta para controle de concorrência depende do tipo de comunicação e do contexto de uso.

I2C com Mutex no STM32F411RE

O protocolo I2C é um barramento compartilhado onde múltiplos dispositivos podem estar conectados ao mesmo controlador. Como apenas um dispositivo pode realizar a comunicação por vez, o uso de mutex é essencial para evitar colisões entre tarefas concorrentes que tentam acessar o barramento ao mesmo tempo.

#include "stm32f4xx_hal.h"
#include "FreeRTOS.h"
#include "semphr.h"

I2C_HandleTypeDef hi2c1;
SemaphoreHandle_t i2cMutex;

void I2C_Write(uint16_t devAddress, uint8_t *data, uint16_t size) {
    if (xSemaphoreTake(i2cMutex, portMAX_DELAY)) {
        HAL_I2C_Master_Transmit(&hi2c1, devAddress, data, size, HAL_MAX_DELAY);
        xSemaphoreGive(i2cMutex);
    }
}

SPI com Mutex no STM32F411RE

O protocolo SPI geralmente é mais rápido que o I2C, mas também pode sofrer de concorrência quando múltiplas tarefas tentam acessá-lo simultaneamente. O uso de mutex impede que duas tarefas interfiram uma na outra enquanto utilizam o barramento SPI.

#include "stm32f4xx_hal.h"
#include "FreeRTOS.h"
#include "semphr.h"

SPI_HandleTypeDef hspi1;
SemaphoreHandle_t spiMutex;

void SPI_Write(uint8_t *data, uint16_t size) {
    if (xSemaphoreTake(spiMutex, portMAX_DELAY)) {
        HAL_SPI_Transmit(&hspi1, data, size, HAL_MAX_DELAY);
        xSemaphoreGive(spiMutex);
    }
}

Melhor Abordagem

• I2C: Como é um barramento compartilhado entre múltiplos dispositivos, usar um mutex é essencial para evitar colisões.
• SPI: Em ambientes multitarefa, o uso de mutex também é recomendado para evitar que diferentes tarefas tentem acessar o mesmo barramento ao mesmo tempo.
• Semáforos podem ser usados para sincronizar eventos, como a recepção de dados em interrupções.

Essas práticas garantem que a comunicação com dispositivos externos ocorra de maneira segura e eficiente, sem causar falhas no sistema.

Conclusão

Escolher a técnica correta para o controle de concorrência é essencial para garantir a estabilidade e o desempenho de sistemas multitarefa. Como visto ao longo deste artigo:

• Mutexes são ideais para garantir exclusão mútua, prevenindo que múltiplas tarefas modifiquem simultaneamente um mesmo recurso compartilhado.
• Semáforos são úteis tanto para controle de múltiplas instâncias de um recurso quanto para sincronização de tarefas.
• A suspensão do escalonador deve ser usada com cuidado, sendo útil apenas em situações críticas onde uma interrupção durante a execução pode causar problemas graves.

Quando se trata de dispositivos como I2C e SPI, a escolha de mutexes para proteger o barramento e garantir a integridade da comunicação é a abordagem mais recomendada, enquanto semáforos podem ser úteis para coordenar eventos assíncronos.

Entender essas técnicas e aplicá-las corretamente resulta em sistemas mais eficientes, confiáveis e fáceis de manter. O uso adequado de mutexes, semáforos e a suspensão do escalonador garante que aplicações multitarefa operem de maneira fluida, sem impactos negativos na performance do sistema.

Com isso, esperamos que este artigo tenha esclarecido as principais diferenças entre essas abordagens e ajudado a tomar decisões mais informadas no desenvolvimento de sistemas embarcados e aplicações multitarefa.

The post first appeared on MCU & FPGA.