Resumo (Abstract)

O Garbage Compactor Pattern é um padrão de gerenciamento de memória que reorganiza dinamicamente a alocação de memória para reduzir a fragmentação e garantir blocos contíguos disponíveis para uso. Em sistemas embarcados, onde a memória é um recurso extremamente limitado, esse padrão se torna essencial para maximizar o aproveitamento da RAM e evitar falhas inesperadas devido à fragmentação excessiva.

Problema a ser resolvido

Sistemas que fazem uso de alocação dinâmica de memória frequentemente sofrem com a fragmentação, onde blocos livres são dispersos na RAM, impossibilitando a alocação de grandes blocos de memória mesmo quando há espaço suficiente disponível. Esse problema é particularmente crítico em sistemas embarcados, onde a memória é limitada e cada falha na alocação pode levar a travamentos, reinicializações ou falhas de desempenho.

Além disso, a fragmentação pode tornar os tempos de resposta imprevisíveis, pois a busca por blocos de memória disponíveis se torna mais complexa. Sistemas de tempo real precisam de garantias de tempo de resposta determinístico, algo que pode ser comprometido caso a fragmentação cause variações no tempo de alocação. O Garbage Compactor Pattern resolve esse problema ao reorganizar periodicamente a memória, consolidando blocos livres em regiões contínuas e garantindo que grandes alocações possam ser feitas sem falhas.

Estrutura do Padrão

A estrutura desse padrão envolve um gerenciador de heap, que monitora a fragmentação da memória e decide quando realizar a compactação. A lista de blocos ocupados rastreia quais segmentos da RAM estão em uso, enquanto a lista de blocos livres gerencia os espaços disponíveis. Um mecanismo de realocação move os dados dos blocos alocados para consolidar as áreas livres, garantindo que a memória seja reorganizada sem impactar o funcionamento do sistema.

A compactação pode ser realizada em momentos estratégicos, como durante períodos de baixa atividade do sistema ou quando a fragmentação atinge um limite crítico. Esse processo pode ser implementado de forma assíncrona para minimizar impactos no desempenho.

Papéis de Colaboração (Collaborations Roles)

• Gerenciador de Heap: Supervisiona a alocação, desalocação e reorganização dos blocos de memória.
• Lista de Blocos Ocupados: Mantém um mapeamento dos blocos de memória em uso.
• Lista de Blocos Livres: Armazena informações sobre os segmentos disponíveis para alocação.
• Mecanismo de Realocação: Move os dados entre os blocos de memória para consolidar áreas livres.
• Cliente: Solicita alocações e liberações de memória conforme necessário.
• Segmento de Memória: Contém a memória real onde os blocos são armazenados e reorganizados.

Consequências

A aplicação do Garbage Compactor Pattern traz benefícios significativos para sistemas embarcados. Ele melhora a eficiência do uso da memória, garantindo que grandes blocos possam ser alocados sem falhas. Além disso, reduz os tempos de busca por espaço livre, melhorando a previsibilidade dos tempos de resposta, algo essencial em sistemas de tempo real.

Por outro lado, o processo de compactação pode ser custoso em termos de processamento, pois requer movimentação de dados na RAM. Se não for gerenciado corretamente, pode causar pausas no sistema que impactam a responsividade da aplicação. Outra consideração importante é que a movimentação dos blocos pode exigir a atualização de ponteiros e referências, o que pode ser complexo em algumas arquiteturas.

Estratégias de Implementação

A implementação do Garbage Compactor Pattern pode seguir diferentes abordagens, dependendo dos requisitos do sistema. Uma estratégia comum é a compactação periódica, onde a reorganização da memória ocorre em intervalos regulares ou quando a fragmentação atinge um limite predefinido. Esse método é útil em sistemas onde há momentos de baixa carga que podem ser aproveitados para a reorganização da memória.

Outra abordagem é a compactação sob demanda, onde a reorganização ocorre apenas quando uma tentativa de alocação falha devido à fragmentação. Essa estratégia minimiza o impacto no desempenho, pois a compactação é realizada apenas quando necessário. No entanto, pode causar atrasos inesperados no tempo de resposta quando a compactação precisa ser feita em um momento crítico.

Para garantir a integridade dos dados durante a realocação, é essencial utilizar mecanismos de proteção de ponteiros, garantindo que referências a blocos de memória sejam atualizadas corretamente. Outra técnica útil é a utilização de buffers temporários, permitindo que dados sejam copiados para uma área intermediária antes de serem reposicionados.

Padrões Relacionados

O Garbage Compactor Pattern está diretamente relacionado a outros padrões de gerenciamento de memória:

• Pool Allocation Pattern: Ambos lidam com otimização do uso de memória, mas o Pool Allocation evita a fragmentação desde o início, enquanto o Garbage Compactor atua quando a fragmentação já ocorreu.
• Fixed-Sized Buffer Pattern: Pode ser combinado com a compactação de memória para garantir um uso mais eficiente da RAM.
• Priority Ceiling Pattern: Pode ser usado para garantir que o processo de compactação ocorra sem interrupções indesejadas em sistemas críticos.
• Critical Section Pattern: Pode ser necessário para evitar acessos concorrentes durante a compactação.

Modelo de Amostragem (Exemplo de Código)

Segue um exemplo de implementação simplificada do Garbage Compactor Pattern em C:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include <string.h>

#define HEAP_SIZE 1024  // Tamanho total do heap
#define BLOCK_SIZE 32    // Tamanho de cada bloco de memória
#define NUM_BLOCKS (HEAP_SIZE / BLOCK_SIZE)

typedef struct MemoryBlock {
    bool in_use;
    void *ptr;
    size_t size;
} MemoryBlock;

typedef struct Segment {
    MemoryBlock blocks[NUM_BLOCKS];
    uint8_t memory[HEAP_SIZE];
    struct Segment *next;
} Segment;

typedef struct BufferedPtr {
    void **ptr;
} BufferedPtr;

typedef struct GarbageCompactor {
    Segment *activeSegment;
    Segment *inactiveSegment;
} GarbageCompactor;

Segment segment1, segment2;
GarbageCompactor gc;

void init_segments() {
    memset(&segment1, 0, sizeof(Segment));
    memset(&segment2, 0, sizeof(Segment));
    gc.activeSegment = &segment1;
    gc.inactiveSegment = &segment2;
}

void *allocate_memory(size_t size) {
    Segment *seg = gc.activeSegment;
    for (int i = 0; i < NUM_BLOCKS; i++) {
        if (!seg->blocks[i].in

The post Garbage Compactor Pattern first appeared on MCU & FPGA.

Resumo

O Pool Allocation Pattern é um padrão que gerencia a memória de forma eficiente ao pré-alocar blocos de tamanho fixo para reutilização. Ele resolve problemas comuns da alocação dinâmica, como fragmentação e imprevisibilidade no tempo de acesso, tornando-se essencial para sistemas embarcados e de tempo real. Esse padrão melhora a eficiência do uso da RAM ao garantir que blocos de memória sejam reutilizados conforme necessário, sem necessidade de alocações dinâmicas constantes.

Problema a ser resolvido

A alocação dinâmica de memória (malloc() e free()) pode levar à fragmentação e latências imprevisíveis, o que é inaceitável para sistemas embarcados de tempo real. Além disso, quando a memória se esgota ou está altamente fragmentada, pode ocorrer falha na alocação de novos blocos, resultando em comportamento inesperado do sistema.

Outro problema comum é a sobrecarga de gerenciamento de memória, onde a alocação e desalocação frequente de pequenos blocos gera um overhead significativo. Isso reduz a eficiência do sistema e pode impactar o tempo de resposta em aplicações críticas. Em sistemas embarcados com recursos limitados, é crucial garantir que a memória seja usada de forma previsível e eficiente.

O Pool Allocation Pattern resolve esses problemas ao manter um conjunto fixo de blocos de memória pré-alocados, permitindo que o sistema reutilize esses blocos de maneira eficiente. Isso elimina a necessidade de alocação e desalocação dinâmica, garantindo tempos de resposta constantes e previsíveis.

Estrutura do Padrão

A estrutura desse padrão se baseia em um gerenciador de pool de memória, que mantém uma lista de blocos livres prontos para serem usados. Cada bloco tem um tamanho fixo e pode ser alocado rapidamente sem a necessidade de recorrer ao heap. A fábrica de objetos pode ser usada para criar e inicializar os blocos, enquanto um gerenciador de heap dimensionado garante que os blocos sejam usados de maneira eficiente.

Os dados são armazenados no segmento de memória, garantindo que a RAM seja utilizada de forma previsível. O acesso ao pool pode ser gerenciado por mecanismos como filas FIFO (First In, First Out) ou LIFO (Last In, First Out), dependendo das necessidades da aplicação.

Papéis de Colaboração

• Cliente: Solicita e libera blocos de memória conforme necessário.
• Lista de Blocos Livres: Mantém o controle dos blocos de memória disponíveis para reutilização.
• Gerenciador de Pool: Supervisiona a alocação e liberação dos blocos, garantindo que a memória seja usada eficientemente.
• Segmento de Memória: Armazena fisicamente os blocos alocados.
• Fábrica de Objetos: Pode ser usada para criar instâncias de objetos que utilizam a alocação por pool.
• Heap Dimensionado: Garante que os blocos tenham um tamanho fixo e que a memória seja utilizada de maneira eficiente.

Consequências

O Pool Allocation Pattern traz diversas vantagens para sistemas embarcados. Ele reduz drasticamente o tempo de alocação de memória, pois os blocos já estão pré-alocados e prontos para uso. Isso melhora o tempo de resposta do sistema e evita problemas de fragmentação. Além disso, ao reutilizar blocos já existentes, o padrão reduz a necessidade de operações de gerenciamento de heap, economizando processamento.

Entretanto, esse padrão pode levar ao desperdício de memória se o número de blocos pré-alocados for maior do que o necessário. Se a quantidade de blocos for insuficiente, pode ser necessário um mecanismo de fallback para lidar com situações onde não há memória disponível. Além disso, a implementação deve ser bem planejada para evitar vazamentos de memória devido a blocos que não são liberados corretamente.

Estratégias de Implementação

Para implementar o Pool Allocation Pattern, um array de blocos de memória é criado no momento da inicialização do sistema. Um gerenciador de pool mantém uma lista encadeada de blocos disponíveis, permitindo alocação e liberação rápidas. Em sistemas que exigem eficiência máxima, um buffer circular pode ser utilizado para gerenciar os blocos de forma ainda mais eficiente.

A implementação pode incluir verificações para evitar acessos indevidos a blocos não alocados. Além disso, em sistemas multitarefa, mutexes ou semáforos podem ser usados para garantir que múltiplas tarefas acessem o pool de maneira segura. Em casos onde há necessidade de realocação dinâmica, pode-se combinar esse padrão com o Fixed-Sized Buffer Pattern, garantindo que cada bloco tenha um tamanho fixo e previsível.

Padrões Relacionados

O Pool Allocation Pattern está diretamente relacionado a outros padrões de gerenciamento de memória e sincronização:

• Fixed-Sized Buffer Pattern: Ambos evitam alocação dinâmica e melhoram a previsibilidade do uso da memória.
• Message Queuing Pattern: Pode ser usado em conjunto para gerenciar filas de mensagens sem consumir memória excessiva.
• Garbage Compactor Pattern: Pode ser útil quando há necessidade de reorganizar a memória para evitar fragmentação.
• Critical Section Pattern: Pode ser necessário para evitar acesso concorrente a blocos do pool.

Modelo de Amostragem (Exemplo de Código)

Aqui está um exemplo de implementação do Pool Allocation Pattern em C:

#include <stdio.h>
#include <stdint.h>

#define POOL_SIZE 1000 // Número máximo de objetos TempData

// Estrutura de dados de temperatura
typedef struct {
    int id;
    float temperature;
} TempData;

// Estrutura para o Pool de Recursos
typedef struct {
    TempData pool[POOL_SIZE];  // Array de objetos
    uint8_t allocated[POOL_SIZE];  // Flags para indicar quais objetos estão em uso
} TempDataPool;

// Inicializa o pool de dados
void initPool(TempDataPool* pool) {
    for (int i = 0; i < POOL_SIZE; i++) {
        pool->allocated[i] = 0;  // Nenhum objeto está alocado inicialmente
    }
}

// Aloca um objeto TempData do pool
TempData* allocateTempData(TempDataPool* pool) {
    for (int i = 0; i < POOL_SIZE; i++) {
        if (!pool->allocated[i]) {  // Se não estiver em uso
            pool->allocated[i] = 1; // Marca como alocado
            return &pool->pool[i];
        }
    }
    return NULL; // Pool esgotado
}

// Libera um objeto TempData e o devolve ao pool
void releaseTempData(TempDataPool* pool, TempData* data) {
    int index = data - pool->pool;  // Calcula o índice do objeto
    if (index >= 0 && index < POOL_SIZE) {
        pool->allocated[index] = 0; // Marca como livre
    }
}

// Simulação de sensores e histórico
void simulateUsage() {
    TempDataPool tempPool;
    initPool(&tempPool);

    TempData* temp1 = allocateTempData(&tempPool);
    if (temp1) {
        temp1->id = 1;
        temp1->temperature = 23.5;
        printf("TempData %d alocado: %.2f°C\n", temp1->id, temp1->temperature);
    }

    TempData* temp2 = allocateTempData(&tempPool);
    if (temp2) {
        temp2->id = 2;
        temp2->temperature = 24.0;
        printf("TempData %d alocado: %.2f°C\n", temp2->id, temp2->temperature);
    }

    releaseTempData(&tempPool, temp1);
    printf("TempData %d liberado\n", temp1->id);

    TempData* temp3 = allocateTempData(&tempPool);
    if (temp3) {
        temp3->id = 3;
        temp3->temperature = 22.8;
        printf("TempData %d alocado: %.2f°C\n", temp3->id, temp3->temperature);
    }
}

int main() {
    simulateUsage();
    return 0;
}

Abaixo segue o diagrama Estrutural:

A seguir o diagrama de sequência:

The post Pool Allocation Pattern first appeared on MCU & FPGA.

Resumo

O Fixed-Sized Buffer Pattern é um padrão de gerenciamento de memória que utiliza buffers de tamanho fixo e pré-alocados para armazenar dados temporários em sistemas embarcados. Ele é amplamente utilizado para comunicação entre módulos do sistema, filas de mensagens, buffers de entrada e saída e armazenamento intermediário de dados. A sua principal vantagem é a previsibilidade do uso da memória, evitando fragmentação e problemas de desempenho associados à alocação dinâmica. Esse padrão se mostra essencial para sistemas de tempo real, onde a confiabilidade da memória é um fator crítico.

Problema a ser resolvido

Muitos sistemas embarcados precisam armazenar temporariamente dados antes de processá-los. Isso pode ocorrer, por exemplo, em buffers de recepção de comunicação serial, aquisição de sinais analógicos ou manipulação de pacotes de rede. A alocação dinâmica de memória, como o uso de malloc() e free(), pode levar à fragmentação e falhas inesperadas, além de introduzir latências imprevisíveis que prejudicam o desempenho em aplicações de tempo real.

Outro problema comum ocorre quando buffers de tamanho variável são usados, pois isso dificulta a previsão do consumo de RAM. Em sistemas embarcados, onde cada byte de memória é valioso, a má gestão desses buffers pode levar a desperdício de memória ou esgotamento precoce dos recursos disponíveis. Além disso, sistemas que dependem de alocação dinâmica podem sofrer falhas catastróficas caso a memória se esgote durante a execução, causando travamentos ou reinicializações inesperadas.

O Fixed-Sized Buffer Pattern resolve esses problemas ao pré-alocar um buffer de tamanho fixo, garantindo um consumo de memória estável e previsível. Dessa forma, evita-se a fragmentação e garante-se um tempo de acesso constante aos dados, permitindo que sistemas críticos operem sem interrupções.

Estrutura do Padrão

A estrutura do padrão se baseia na alocação de um bloco de memória de tamanho fixo no momento da inicialização do sistema. Esse bloco pode ser organizado como um array circular ou uma lista estática de elementos. O gerenciamento do buffer é feito por índices ou ponteiros que controlam a posição de leitura e escrita, garantindo que os dados sejam armazenados e recuperados de forma ordenada.

Além da estrutura principal do buffer, há também um gerenciador de heap, que pode ser responsável por distribuir múltiplos buffers conforme a necessidade da aplicação. A lista de blocos livres mantém o controle sobre quais partes do buffer estão disponíveis para escrita, evitando sobrescrita acidental. Já o segmento de memória contém o espaço físico onde os dados são armazenados.

Outros elementos importantes incluem a fábrica de objetos, que pode criar e liberar instâncias de buffers conforme necessário, e o heap dimensionado, que garante que os buffers alocados tenham um tamanho predefinido e constante.

Papéis de Colaboração

• Cliente: Solicita espaço no buffer para armazenar dados e recuperá-los posteriormente.
• Produtor: Responsável por inserir dados no buffer, como sensores, módulos de comunicação ou periféricos.
• Consumidor: Recupera os dados armazenados no buffer para processamento ou transmissão.
• Lista de Blocos Livres: Mantém um registro das áreas disponíveis no buffer para novas alocações.
• Gerenciador de Heap: Supervisiona a alocação e reutilização dos buffers de tamanho fixo.
• Segmento de Memória: Armazena fisicamente os dados dentro do buffer pré-alocado.
• Fábrica de Objetos: Pode ser usada para criar instâncias de buffers conforme a demanda do sistema.
• Heap Dimensionado: Assegura que os buffers tenham tamanhos predefinidos e não sofram alterações durante a execução.

Consequências

O Fixed-Sized Buffer Pattern oferece diversas vantagens. Ele elimina a necessidade de alocação dinâmica de memória, reduzindo riscos de fragmentação e falhas inesperadas. Além disso, por definir um tamanho fixo para os buffers, o consumo de RAM é altamente previsível, permitindo que o sistema seja otimizado para uso eficiente dos recursos. Esse padrão também melhora a performance, pois evita as operações de alocação e desalocação que podem introduzir latências imprevisíveis.

Por outro lado, esse padrão pode levar a um certo desperdício de memória caso o tamanho do buffer seja superdimensionado. Se o buffer for maior do que necessário, a memória será ocupada sem ser utilizada de forma eficiente. Além disso, em sistemas com múltiplos buffers, pode ser necessário um mecanismo adicional para garantir a reutilização adequada das áreas de memória.

Estratégias de Implementação

Uma das formas mais comuns de implementar esse padrão é através de buffers circulares, onde os dados são armazenados em um array fixo e os índices de leitura e escrita são atualizados continuamente. Isso permite que o buffer seja reutilizado sem a necessidade de realocação de memória. Outra abordagem é utilizar listas de blocos fixos, onde cada bloco é tratado como uma unidade independente de armazenamento.

Para garantir acesso seguro ao buffer em sistemas multitarefa, pode ser necessário o uso de mutexes ou semáforos para evitar condições de corrida. Outra estratégia comum é implementar verificações de integridade no buffer, como a adição de checksums para detectar corrupção de dados. Em alguns casos, pode ser interessante combinar esse padrão com o Priority Ceiling Pattern, garantindo que tarefas críticas tenham acesso prioritário ao buffer.

Padrões Relacionados

O Fixed-Sized Buffer Pattern possui uma forte relação com outros padrões de gerenciamento de memória e comunicação:

• Pool Allocation Pattern: Ambos utilizam blocos de memória predefinidos para evitar fragmentação.
• Message Queuing Pattern: Pode utilizar buffers fixos para armazenar mensagens temporárias antes de processá-las.
• Critical Section Pattern: Pode ser necessário para evitar condições de corrida ao acessar buffers compartilhados.
• Garbage Compactor Pattern: Pode ser útil em sistemas que precisam reorganizar a memória quando múltiplos buffers são usados.

Exemplo de Código

Aqui está um exemplo otimizado da implementação do Fixed-Sized Buffer Pattern em C:

Abaixo está um diagrama em blocos que exemplifica o uso do padrão Fixed-Sized Buffer Pattern, veja código a seguir que representa de forma mais realista o padrão de projeto estudado.

#include <stdint.h>
// Tipos de dados padronizados
#include <stdbool.h> 
// Booleanos

#define SMALL_BLOCK_SIZE  64
#define MEDIUM_BLOCK_SIZE 128
#define LARGE_BLOCK_SIZE  256
#define BLOCKS_PER_POOL  10  // Número de blocos fixos por pilha
typedef enum { SMALL, MEDIUM, LARGE } BlockSize;

// Estrutura do bloco reutilizável
typedef struct Block {
    struct Block* next;
} Block;

// Estrutura da pilha de blocos

typedef struct {
    Block* free_list;
    uint8_t memory_pool[BLOCKS_PER_POOL][LARGE_BLOCK_SIZE]; // Buffer estático máximo
    uint8_t block_size;
} BlockStack;

// Estrutura do gerenciador de pilhas
typedef struct {
    BlockStack small_stack;
    BlockStack medium_stack;
    BlockStack large_stack;
} StackManager;
// Estrutura da fábrica de objetos
typedef struct {
    StackManager* stack_manager;
} ObjectFactory;

// Inicializa uma pilha de blocos (pré-alocação)
void init_stack(BlockStack* stack, uint8_t block_size) {
    stack->block_size = block_size;
    stack->free_list = NULL;
    // Divide o buffer estático em blocos reutilizáveis
    for (int i = 0; i < BLOCKS_PER_POOL; i++) {
        Block* block = (Block*)&stack->memory_pool[i][0];
        block->next = stack->free_list;
        stack->free_list = block;
    }
}

// Aloca um bloco reutilizando a lista livre
void* allocate_block(BlockStack* stack) {
    if (!stack->free_list) {
        return NULL; // Nenhum bloco disponível
    }
    Block* block = stack->free_list;
    stack->free_list = block->next;
    return block;<br>}

// Libera um bloco de volta para a pilha
void free_block(BlockStack* stack, void* block) {
    if (!block) return;
    ((Block*)block)->next = stack->free_list;
    stack->free_list = (Block*)block;
}

// Inicializa o gerenciador de pilhas
void init_stack_manager(StackManager* manager) {
    init_stack(&manager->small_stack, SMALL_BLOCK_SIZE);
    init_stack(&manager->medium_stack, MEDIUM_BLOCK_SIZE);
    init_stack(&manager->large_stack, LARGE_BLOCK_SIZE);
}

// Aloca um bloco baseado no tamanho especificado
void* allocate_from_manager(StackManager* manager, BlockSize size) {
    switch (size) {
      case SMALL: 
           return allocate_block(&manager->small_stack);
      case MEDIUM: 
           return allocate_block(&manager->medium_stack);
       case LARGE: 
           return allocate_block(&manager->large_stack)
    }
    return NULL;
}
// Libera um bloco baseado no tamanho especificado

void free_to_manager(StackManager* manager, void* block, BlockSize size) {
    switch (size) {
        case SMALL: free_block(&manager->small_stack, block); break;
        case MEDIUM: free_block(&manager->medium_stack, block); break;
        case LARGE: free_block(&manager->large_stack, block); break;
   }
}

// Inicializa a fábrica de objetos
void init_object_factory(ObjectFactory* factory, StackManager* manager) {
    factory->stack_manager = manager;<br>}<br><br>// Cria um objeto utilizando a fábrica<br>void* create_object(ObjectFactory* factory, BlockSize size) {<br>    return allocate_from_manager(factory->stack_manager, size);<br>}<br><br>// Libera um objeto utilizando a fábrica<br>void destroy_object(ObjectFactory* factory, void* object, BlockSize size) {
    free_to_manager(factory->stack_manager, object, size);
}

// Função de exemplo para testar no microcontrolador
void test_memory_allocation() {
    StackManager manager;
    ObjectFactory factory;
    init_stack_manager(&manager);
    init_object_factory(&factory, &manager);
    
    void* obj1 = create_object(&factory, SMALL);
    void* obj2 = create_object(&factory, MEDIUM);
    void* obj3 = create_object(&factory, LARGE);
    
    if (obj1 && obj2 && obj3) {
        // Simula LED aceso para indicar sucesso
        // gpio_set_level(LED_GPIO, 1);
    }
    
    destroy_object(&factory, obj1, SMALL);
    destroy_object(&factory, obj2, MEDIUM);
    destroy_object(&factory, obj3, LARGE);
    
    // Simula LED apagado para indicar memória liberada<br>   
    // gpio_set_level(LED_GPIO, 0);<br>
}

Material de apoio no GitHub

• https://github.com/ArvoreDosSaberes/Design-Patterns

The post Fixed-Sized Buffer Pattern 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.