Quando o firmware precisa ser previsível (tempo real), o desenho do filtro não é só “matemático”: você escolhe estruturas e limites para garantir custo computacional constante, estado pequeno e estabilidade numérica, principalmente se você for para ponto fixo ou tiver ADC+DMA alimentando o pipeline. (Essa preocupação de arquitetura e previsibilidade é típica de projetos de tempo real.)

1) Notch discreto: o “biquad” que apaga uma frequência

Um notch digital clássico pode ser implementado como um biquad IIR (segunda ordem) com zeros exatamente na frequência que você quer cancelar e polos próximos, controlando a largura do “buraco” via fator de qualidade (Q). Quanto maior o (Q), mais estreito é o notch (ótimo para interferência tonal estável), mas maior a sensibilidade a variação de (f_0) e a quantização dos coeficientes. Em termos práticos: para hum de rede em 60 Hz, se o sinal tiver variação de frequência (rede oscilando, ou a interferência “escorregando”), um (Q) alto demais pode deixar “vazar” parte do ruído. Para tom de comutação de um inversor ou fonte chaveada, se o clock for estável, dá para usar (Q) alto e atacar de forma cirúrgica.

O biquad notch mais comum pode ser escrito como:

\[
H(z)=\frac{1 – 2\cos(\omega_0)z^{-1} + z^{-2}}{1 – 2r\cos(\omega_0)z^{-1} + r^2 z^{-2}}
\]

onde \(\omega_0=2\pi f_0/F_s\) e (r) controla a “proximidade” dos polos aos zeros (quanto mais perto de 1, mais estreito e mais profundo). Uma ligação prática entre (r) e (Q) é aproximar a largura de banda por \(BW \approx f_0/Q\) e usar \(r \approx e^{-\pi BW/F_s}\). Isso funciona muito bem para firmware porque você calcula coeficientes uma vez (ou quando \(f_0\) muda) e o processamento por amostra fica constante.

Código em C: biquad notch (float) com inicialização por \(F_s, f_0, Q\)

#include <math.h>
#include <stdint.h>

#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif

typedef struct {
    // Coeficientes normalizados (a0 = 1)
    float b0, b1, b2;
    float a1, a2;

    // Estados (forma direta II transposta)
    float z1, z2;
} NotchBiquad;

/**
 * @brief Inicializa um filtro notch IIR (biquad) em forma direta II transposta.
 * @param f     Ponteiro para a estrutura do filtro.
 * @param Fs    Frequência de amostragem (Hz).
 * @param f0    Frequência central do notch (Hz).
 * @param Q     Fator de qualidade (adimensional). Ex.: 10..50 típicos.
 *
 * Observação prática:
 *  - Q maior => notch mais estreito, mais sensível a variações de f0 e quantização.
 *  - Q menor => notch mais largo, remove mais “vizinhança” de frequências.
 */
static inline void notch_init(NotchBiquad *f, float Fs, float f0, float Q)
{
    const float w0 = 2.0f * (float)M_PI * (f0 / Fs);

    // Largura de banda aproximada (Hz)
    const float BW = f0 / Q;

    // Polo raio r (aprox.) -> define a largura do notch
    const float r = expf(-(float)M_PI * (BW / Fs));

    const float c = cosf(w0);

    // Numerador (zeros no círculo unitário em ±w0)
    const float b0 = 1.0f;
    const float b1 = -2.0f * c;
    const float b2 = 1.0f;

    // Denominador (polos em raio r)
    const float a0 = 1.0f;
    const float a1 = -2.0f * r * c;
    const float a2 = r * r;

    // Normaliza por a0 (a0=1 aqui, mas mantemos o padrão)
    f->b0 = b0 / a0;
    f->b1 = b1 / a0;
    f->b2 = b2 / a0;
    f->a1 = a1 / a0;
    f->a2 = a2 / a0;

    f->z1 = 0.0f;
    f->z2 = 0.0f;
}

/**
 * @brief Processa 1 amostra pelo biquad notch (DF-II Transposta).
 * @param f Estrutura do filtro.
 * @param x Amostra de entrada.
 * @return  Amostra filtrada.
 */
static inline float notch_process(NotchBiquad *f, float x)
{
    // DF-II transposta:
    // y = b0*x + z1
    // z1 = b1*x - a1*y + z2
    // z2 = b2*x - a2*y
    const float y = (f->b0 * x) + f->z1;
    const float z1 = (f->b1 * x) - (f->a1 * y) + f->z2;
    const float z2 = (f->b2 * x) - (f->a2 * y);

    f->z1 = z1;
    f->z2 = z2;
    return y;
}

#include <math.h>
#include <stdint.h>

#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif

typedef struct {
    // Coeficientes normalizados (a0 = 1)
    float b0, b1, b2;
    float a1, a2;

    // Estados (forma direta II transposta)
    float z1, z2;
} NotchBiquad;

/**
 * @brief Inicializa um filtro notch IIR (biquad) em forma direta II transposta.
 * @param f     Ponteiro para a estrutura do filtro.
 * @param Fs    Frequência de amostragem (Hz).
 * @param f0    Frequência central do notch (Hz).
 * @param Q     Fator de qualidade (adimensional). Ex.: 10..50 típicos.
 *
 * Observação prática:
 *  - Q maior => notch mais estreito, mais sensível a variações de f0 e quantização.
 *  - Q menor => notch mais largo, remove mais “vizinhança” de frequências.
 */
static inline void notch_init(NotchBiquad *f, float Fs, float f0, float Q)
{
    const float w0 = 2.0f * (float)M_PI * (f0 / Fs);

    // Largura de banda aproximada (Hz)
    const float BW = f0 / Q;

    // Polo raio r (aprox.) -> define a largura do notch
    const float r = expf(-(float)M_PI * (BW / Fs));

    const float c = cosf(w0);

    // Numerador (zeros no círculo unitário em ±w0)
    const float b0 = 1.0f;
    const float b1 = -2.0f * c;
    const float b2 = 1.0f;

    // Denominador (polos em raio r)
    const float a0 = 1.0f;
    const float a1 = -2.0f * r * c;
    const float a2 = r * r;

    // Normaliza por a0 (a0=1 aqui, mas mantemos o padrão)
    f->b0 = b0 / a0;
    f->b1 = b1 / a0;
    f->b2 = b2 / a0;
    f->a1 = a1 / a0;
    f->a2 = a2 / a0;

    f->z1 = 0.0f;
    f->z2 = 0.0f;
}

/**
 * @brief Processa 1 amostra pelo biquad notch (DF-II Transposta).
 * @param f Estrutura do filtro.
 * @param x Amostra de entrada.
 * @return  Amostra filtrada.
 */
static inline float notch_process(NotchBiquad *f, float x)
{
    // DF-II transposta:
    // y = b0*x + z1
    // z1 = b1*x - a1*y + z2
    // z2 = b2*x - a2*y
    const float y = (f->b0 * x) + f->z1;
    const float z1 = (f->b1 * x) - (f->a1 * y) + f->z2;
    const float z2 = (f->b2 * x) - (f->a2 * y);

    f->z1 = z1;
    f->z2 = z2;
    return y;
}

Melhores usos do notch: quando você conhece (ou mede) a frequência indesejada e ela é estreita, relativamente estável e você quer preservar quase tudo ao redor. Em instrumentação, isso aparece em leitura de shunt/ADC contaminada por rede; em áudio, hum; em controle, ressonância mecânica estreita (desde que não destrua margem de fase indevidamente); em eletrônica de potência, uma componente tonal em corrente/tensão.

2) Média sincronizada: “soma coerente” alinhada à fase

A média sincronizada (às vezes chamada de synchronous averaging, time synchronous averaging) não é “só uma média móvel”. A sacada é que você escolhe uma janela exatamente igual a um período do fenômeno repetitivo (ou múltiplos inteiros) e reinicia/alinha essa janela usando um evento de referência: um zero-cross, um pulso de encoder, um índice, ou um marcador derivado do PWM. Se você tem (N) amostras por período e faz uma média sobre (K) períodos alinhados, o componente que se repete com a mesma fase soma e cresce proporcionalmente, enquanto ruído aleatório cai como (\sqrt{K}) no RMS. Além disso, componentes que não “encaixam” naquele período tendem a se cancelar.

Em termos de filtro, isso se comporta como um filtro tipo comb (pente) extremamente eficiente para rejeitar tudo que não é coerente com o período escolhido. A diferença para um notch é que você não está mirando uma única frequência: você está favorecendo toda a forma de onda repetitiva no domínio do tempo, desde que sincronizada.

Código em C: média sincronizada por períodos (com referência externa)

A seguir vai uma implementação simples (e bem útil) para firmware: você acumula amostras de cada posição dentro do período e, a cada período completo, você atualiza a média. Isso é perfeito quando você tem um “gatilho de início de período” (por exemplo, interrupção de índice do encoder ou zero-cross).

#include <stdint.h>
#include <string.h>

typedef struct {
    uint16_t N;          // amostras por período
    uint16_t idx;        // posição atual no período [0..N-1]
    uint32_t K;          // quantos períodos já acumulados (limite/controle externo)

    // Buffers de acumulação (use int64 se seu range for grande)
    int64_t *acc;        // soma por posição
    int32_t *avg;        // média por posição (resultado)
} SyncAvg;

/**
 * @brief Inicializa a média sincronizada.
 * @param s       Estrutura.
 * @param acc     Buffer de acumulação de tamanho N (int64_t).
 * @param avg     Buffer de saída média de tamanho N (int32_t).
 * @param N       Amostras por período.
 */
static inline void syncavg_init(SyncAvg *s, int64_t *acc, int32_t *avg, uint16_t N)
{
    s->N = N;
    s->idx = 0;
    s->K = 0;
    s->acc = acc;
    s->avg = avg;

    memset(s->acc, 0, (size_t)N * sizeof(int64_t));
    memset(s->avg, 0, (size_t)N * sizeof(int32_t));
}

/**
 * @brief Deve ser chamado quando ocorre o "marcador" de início de período (ex.: zero-cross ou índice do encoder).
 *        Isso força alinhamento de fase.
 */
static inline void syncavg_period_reset(SyncAvg *s)
{
    s->idx = 0;
}

/**
 * @brief Alimenta a média sincronizada com uma amostra do ADC já alinhada ao relógio de amostragem.
 * @param s Estrutura.
 * @param x Amostra (ex.: ADC já convertido para int32).
 *
 * Funcionamento:
 *  - A cada amostra, acumula na posição idx.
 *  - Ao completar N amostras, fecha um período e atualiza avg[].
 *  - A referência de fase vem de syncavg_period_reset() (externa).
 */
static inline void syncavg_push_sample(SyncAvg *s, int32_t x)
{
    s->acc[s->idx] += (int64_t)x;
    s->idx++;

    if (s->idx >= s->N) {
        s->idx = 0;
        s->K++;

        // Atualiza a média inteira por posição (custo O(N) por período).
        // Se N for grande e seu MCU for apertado, dá para atualizar de forma incremental.
        for (uint16_t i = 0; i < s->N; i++) {
            s->avg[i] = (int32_t)(s->acc[i] / (int64_t)s->K);
        }
    }
}

#include <stdint.h>
#include <string.h>

typedef struct {
    uint16_t N;          // amostras por período
    uint16_t idx;        // posição atual no período [0..N-1]
    uint32_t K;          // quantos períodos já acumulados (limite/controle externo)

    // Buffers de acumulação (use int64 se seu range for grande)
    int64_t *acc;        // soma por posição
    int32_t *avg;        // média por posição (resultado)
} SyncAvg;

/**
 * @brief Inicializa a média sincronizada.
 * @param s       Estrutura.
 * @param acc     Buffer de acumulação de tamanho N (int64_t).
 * @param avg     Buffer de saída média de tamanho N (int32_t).
 * @param N       Amostras por período.
 */
static inline void syncavg_init(SyncAvg *s, int64_t *acc, int32_t *avg, uint16_t N)
{
    s->N = N;
    s->idx = 0;
    s->K = 0;
    s->acc = acc;
    s->avg = avg;

    memset(s->acc, 0, (size_t)N * sizeof(int64_t));
    memset(s->avg, 0, (size_t)N * sizeof(int32_t));
}

/**
 * @brief Deve ser chamado quando ocorre o "marcador" de início de período (ex.: zero-cross ou índice do encoder).
 *        Isso força alinhamento de fase.
 */
static inline void syncavg_period_reset(SyncAvg *s)
{
    s->idx = 0;
}

/**
 * @brief Alimenta a média sincronizada com uma amostra do ADC já alinhada ao relógio de amostragem.
 * @param s Estrutura.
 * @param x Amostra (ex.: ADC já convertido para int32).
 *
 * Funcionamento:
 *  - A cada amostra, acumula na posição idx.
 *  - Ao completar N amostras, fecha um período e atualiza avg[].
 *  - A referência de fase vem de syncavg_period_reset() (externa).
 */
static inline void syncavg_push_sample(SyncAvg *s, int32_t x)
{
    s->acc[s->idx] += (int64_t)x;
    s->idx++;

    if (s->idx >= s->N) {
        s->idx = 0;
        s->K++;

        // Atualiza a média inteira por posição (custo O(N) por período).
        // Se N for grande e seu MCU for apertado, dá para atualizar de forma incremental.
        for (uint16_t i = 0; i < s->N; i++) {
            s->avg[i] = (int32_t)(s->acc[i] / (int64_t)s->K);
        }
    }
}

Melhores usos da média sincronizada: quando existe um evento/clock de referência que define o período do fenômeno e você quer extrair o comportamento repetitivo com máxima imunidade a ruído. Isso aparece em análise vibroacústica sincronizada com rotação (encoder), em medição de ripple sincronizada com PWM, em leitura de sinais biomédicos quando há marcador, e em sistemas de potência quando você quer “ver” a forma média ao longo de ciclos de rede sem ser enganado por ruído ou eventos transientes fora de fase.

3) Exemplo prático combinando os dois: remover hum e depois reforçar a forma repetitiva

Em pipeline real, é comum usar notch primeiro para derrubar uma interferência tonal forte e, em seguida, média sincronizada para aumentar SNR do que restou (principalmente se o sinal útil é repetitivo e você tem referência). A ordem pode inverter dependendo do caso: se a interferência também for coerente com o mesmo período, a média pode reforçá-la, então o notch antes costuma ser mais seguro.

Abaixo, um esqueleto de uso. Imagine ADC a 4 kHz, hum em 60 Hz, e você quer fazer média sincronizada por ciclo de 60 Hz usando zero-cross (logo \(N \approx 4000/60 \approx 66\) amostras por ciclo; na prática você ajusta para manter N inteiro e usar PLL/medição de período se a rede variar).

#include <stdio.h>

// Reaproveita NotchBiquad e SyncAvg já definidos acima.

#define FS_HZ        4000.0f
#define NOTCH_F0_HZ  60.0f
#define NOTCH_Q      25.0f

#define N_SAMPLES_PER_PERIOD  66  // exemplo (depende do seu sincronismo real)

static int64_t acc_buf[N_SAMPLES_PER_PERIOD];
static int32_t avg_buf[N_SAMPLES_PER_PERIOD];

int main(void)
{
    NotchBiquad notch;
    notch_init(&notch, FS_HZ, NOTCH_F0_HZ, NOTCH_Q);

    SyncAvg s;
    syncavg_init(&s, acc_buf, avg_buf, N_SAMPLES_PER_PERIOD);

    // Exemplo: loop de aquisição (mock)
    for (int n = 0; n < 20000; n++) {
        // Em firmware real: x_raw vem do ADC (DMA buffer), e zero-cross chama syncavg_period_reset(&s)
        int32_t x_raw = (int32_t)(1000 * sinf(2.0f * (float)M_PI * 10.0f * (n / FS_HZ))); // sinal útil 10 Hz
        x_raw += (int32_t)(300 * sinf(2.0f * (float)M_PI * 60.0f * (n / FS_HZ)));        // hum 60 Hz

        // Notch (float) -> converte de volta para int32
        float y_notch = notch_process(&notch, (float)x_raw);
        int32_t y = (int32_t)y_notch;

        // Evento externo de sincronismo: aqui é só demonstração (a cada N amostras)
        if ((n % N_SAMPLES_PER_PERIOD) == 0) {
            syncavg_period_reset(&s);
        }

        // Média sincronizada
        syncavg_push_sample(&s, y);

        // Quando s.K aumenta, avg_buf contém a forma média por período
        if (s.K > 0 && (n % (N_SAMPLES_PER_PERIOD * 20)) == 0) {
            printf("K=%lu, avg[0]=%ld, avg[10]=%ld\n",
                   (unsigned long)s.K, (long)avg_buf[0], (long)avg_buf[10]);
        }
    }

    return 0;
}

#include <stdio.h>

// Reaproveita NotchBiquad e SyncAvg já definidos acima.

#define FS_HZ        4000.0f
#define NOTCH_F0_HZ  60.0f
#define NOTCH_Q      25.0f

#define N_SAMPLES_PER_PERIOD  66  // exemplo (depende do seu sincronismo real)

static int64_t acc_buf[N_SAMPLES_PER_PERIOD];
static int32_t avg_buf[N_SAMPLES_PER_PERIOD];

int main(void)
{
    NotchBiquad notch;
    notch_init(¬ch, FS_HZ, NOTCH_F0_HZ, NOTCH_Q);

    SyncAvg s;
    syncavg_init(&s, acc_buf, avg_buf, N_SAMPLES_PER_PERIOD);

    // Exemplo: loop de aquisição (mock)
    for (int n = 0; n < 20000; n++) {
        // Em firmware real: x_raw vem do ADC (DMA buffer), e zero-cross chama syncavg_period_reset(&s)
        int32_t x_raw = (int32_t)(1000 * sinf(2.0f * (float)M_PI * 10.0f * (n / FS_HZ))); // sinal útil 10 Hz
        x_raw += (int32_t)(300 * sinf(2.0f * (float)M_PI * 60.0f * (n / FS_HZ)));        // hum 60 Hz

        // Notch (float) -> converte de volta para int32
        float y_notch = notch_process(¬ch, (float)x_raw);
        int32_t y = (int32_t)y_notch;

        // Evento externo de sincronismo: aqui é só demonstração (a cada N amostras)
        if ((n % N_SAMPLES_PER_PERIOD) == 0) {
            syncavg_period_reset(&s);
        }

        // Média sincronizada
        syncavg_push_sample(&s, y);

        // Quando s.K aumenta, avg_buf contém a forma média por período
        if (s.K > 0 && (n % (N_SAMPLES_PER_PERIOD * 20)) == 0) {
            printf("K=%lu, avg[0]=%ld, avg[10]=%ld\n",
                   (unsigned long)s.K, (long)avg_buf[0], (long)avg_buf[10]);
        }
    }

    return 0;
}

Fechando a ideia: o notch discreto e a média sincronizada resolvem problemas parecidos (melhorar a qualidade do sinal), mas por “mecanismos” bem diferentes, e isso muda totalmente quando cada um é a melhor escolha. O notch é a ferramenta certa quando você conhece uma frequência indesejada bem definida e relativamente estável e quer arrancá-la do sinal com o mínimo de impacto no restante do espectro. Em firmware, isso costuma ser “hum” de 50/60 Hz, tons de chaveamento, ou uma ressonância estreita que aparece como pico bem localizado. O ponto crítico é que o notch é tão bom quanto a precisão do seu (f_0) e a escolha de (Q): se a interferência varia de frequência, um notch muito estreito deixa passar; se você alarga demais, começa a “machucar” conteúdo útil perto de (f_0). Além disso, como é um IIR, você precisa cuidar de estabilidade numérica e do formato de implementação (a forma direta II transposta tende a ser mais robusta em ponto flutuante e também costuma ser a melhor porta de entrada para depois migrar para ponto fixo).

Já a média sincronizada não é “um filtro de frequência” no sentido clássico; ela é uma técnica de extração por coerência: tudo que está alinhado com o período de referência fica mais forte, e o que não está alinhado tende a desaparecer. Por isso ela é superior quando o sinal útil é repetitivo e você tem um marcador de fase confiável, como encoder em máquina rotativa, o próprio PWM em conversores/inversores, ou zero-cross da rede. O ganho prático é enorme porque ela aumenta SNR sem precisar “inventar” um modelo espectral do ruído, mas ela também tem uma fragilidade: se o sincronismo for ruim (jitter, período variável, marcador inconsistente) a média “borrará” a forma de onda e pode até criar artefatos que parecem sinal real. Em projetos de rede elétrica, por exemplo, se você fixa (N) como “amostras por ciclo” sem acompanhar a variação real da frequência, a média começa a perder fase ao longo dos ciclos; nesse caso, ou você mede o período e ajusta (N) dinamicamente, ou você reamostra o ciclo para um grid fixo antes de acumular.

Na prática, em pipeline embarcado, uma combinação muito comum é usar notch primeiro para remover uma interferência tonal forte e depois usar média sincronizada para revelar a forma repetitiva de interesse com ruído bem mais baixo. Isso funciona especialmente bem quando a interferência não é coerente com o período que você está usando para sincronizar; se for coerente, a média pode reforçar a interferência, e aí o notch vira praticamente obrigatório antes. Se o seu sistema estiver no limite de CPU, o notch custa um número fixo e pequeno de multiplicações por amostra, enquanto a média sincronizada pode custar pouco por amostra mas “cobra” um custo por período quando você atualiza a forma média; dá para manter determinismo atualizando médias de forma incremental, ou reduzindo taxa, ou usando buffers e processamento em tarefa de menor prioridade.

The post Filtro notch discreto (notch IIR) e média sincronizada (sync averaging) first appeared on MCU & FPGA.

Introdução

A escolha de um microcontrolador é uma das decisões mais críticas no desenvolvimento de sistemas embarcados, pois impacta diretamente o custo, o consumo de energia, a complexidade do firmware, a conectividade disponível e até mesmo a viabilidade do produto final. Nos últimos anos, o mercado passou a oferecer famílias extremamente distintas, que atendem desde projetos educacionais e protótipos rápidos até aplicações industriais, IoT em larga escala e dispositivos vestíveis de ultra-baixo consumo.

Neste artigo comparativo, analisamos cinco plataformas amplamente utilizadas — ESP32, STM32, Arduino (AVR), RP2040 e nRF52 — destacando suas arquiteturas, capacidades de processamento, conectividade, consumo energético e contextos de uso. O objetivo não é eleger um “melhor” microcontrolador, mas fornecer critérios técnicos claros para que o engenheiro ou desenvolvedor escolha a solução mais adequada ao seu projeto.

The post Comparativo Técnico de Microcontroladores: ESP32, STM32, Arduino, RP2040 e nRF52 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.

Em automação industrial, o “problema real” não é só medir uma grandeza (pressão, nível, vazão, temperatura), e sim transportar essa informação com confiabilidade por cabos longos, passando perto de motores, inversores de frequência, contatores e ambientes com aterramento imperfeito. Por isso, o setor convergiu para dois padrões analógicos simples, baratos e robustos: tensão (tipicamente 0–10 V) e corrente (tipicamente 4–20 mA). Ambos representam a mesma ideia: um sensor transforma uma variável física em um sinal elétrico proporcional; a diferença está em como esse sinal “sobrevive” ao mundo industrial.

O padrão 0–10 V é muito comum quando as distâncias são moderadas, o cabeamento é bem controlado e o custo/complexidade precisa ser mínimo. Ele é intuitivo: a variável medida vira uma tensão proporcional na entrada analógica do CLP/DAQ. A relação básica de escalonamento (linear) é:

\[
y = y_{\min} + \frac{(V – V_{\min})}{(V_{\max}-V_{\min})},(y_{\max}-y_{\min})
\]

Para 0–10 V, fica:

\[
y = y_{\min} + \frac{V}{10},(y_{\max}-y_{\min})
\]

Já o padrão 4–20 mA nasceu para vencer o que “mata” sinais de tensão no campo: queda de tensão no cabo, variações de resistência de contato, ruído acoplado e diferenças de referência de terra. Em um loop de corrente, o receptor não “confia” tanto em uma tensão absoluta; ele mede a corrente, e a corrente é a mesma ao longo de todo o circuito em série (pela própria natureza do loop), desde que o transmissor tenha tensão de alimentação suficiente para manter a conformidade. O escalonamento típico é:

\[
y = y_{\min} + \frac{(I-4,\text{mA})}{16,\text{mA}},(y_{\max}-y_{\min})
\]

O “4 mA” (e não 0 mA) é intencional: é o chamado zero vivo. Assim, 0 mA pode significar falha (fio rompido, transmissor sem alimentação), enquanto 4 mA significa “medindo zero da grandeza, mas o circuito está vivo”. Esse detalhe sozinho reduz diagnósticos ambíguos e melhora manutenção.

Na prática, a escolha vira um trade-off objetivo:

• 0–10 V tende a ser simples, barato, fácil de interfacear, porém mais sensível a ruído e a problemas de referência/aterramento em longas distâncias.
• 4–20 mA tende a ser mais robusto para cabos longos e ambientes agressivos, e ainda oferece diagnóstico de falha via “zero vivo”, ao custo de exigir loop, alimentação e resistor de carga (burden) adequados.

Observação importante (para conectar com arquitetura de sistemas reais): a indústria adota esses padrões porque eles reduzem risco sistêmico e tornam o comportamento mais previsível em campo — uma lógica muito alinhada à mentalidade de projeto de sistemas embarcados/tempo real, onde decisões de arquitetura existem para otimizar confiabilidade sob restrições práticas.

Padrão 0–10 V em detalhe técnico (vantagens, limites e matemática do erro)

O padrão 0–10 V representa a variável medida como uma tensão proporcional aplicada à entrada analógica do sistema de aquisição (CLP, módulo de I/O, microcontrolador). Do ponto de vista elétrico, isso significa que o sensor funciona como uma fonte de tensão (idealmente) e o equipamento de leitura como uma carga de alta impedância. Quanto maior a impedância de entrada, menor a corrente drenada do sensor e menor o erro introduzido.

Modelo elétrico simplificado

Na prática, o sensor não é uma fonte ideal: ele pode ser modelado como uma fonte de tensão \(V_s\) em série com uma resistência interna \(R_s\). O cabo adiciona uma resistência \(R_c\) e a entrada do conversor A/D (ADC) possui uma impedância \(R_{in}\).

\[
V_{med} = V_s \cdot \frac{R_{in}}{R_s + R_c + R_{in}}
\]

Se \(R_{in} \gg (R_s + R_c)\), o termo tende a 1 e o erro é desprezível. Em ambientes industriais, módulos analógicos costumam ter impedâncias de entrada entre 100 kΩ e 1 MΩ, justamente para minimizar esse efeito. Já cabos longos, com seções pequenas, aumentam \(R_c\) e tornam o sistema mais sensível a erro.

Influência do ruído eletromagnético

Outro ponto crítico do 0–10 V é o acoplamento de ruído. Um campo eletromagnético variável (por exemplo, próximo a motores ou inversores de frequência) pode induzir uma tensão espúria no cabo. Como o sinal é uma tensão absoluta, qualquer interferência somada ao sinal aparece diretamente na medição:

\[
V_{ADC} = V_{sinal} + V_{ruído}
\]

Mesmo alguns poucos milivolts podem ser relevantes. Em um sensor escalado de 0–10 V para 0–100 bar, por exemplo, 10 mV equivalem a 0,1 bar. Em aplicações de precisão, isso não é desprezível.

Por isso, boas práticas são praticamente obrigatórias:

• uso de cabos blindados;
• referência de terra bem definida (sensor e receptor compartilham o mesmo GND);
• filtragem analógica simples, como um filtro RC passa-baixa antes do ADC.

O corte de um filtro RC típico é dado por:

\[
f_c = \frac{1}{2\pi RC}
\]

Esse filtro reduz ruído de alta frequência, mas introduz atraso de fase, algo que precisa ser considerado em sistemas de controle em malha fechada.

Resolução e relação com o ADC

Quando o sinal 0–10 V entra em um ADC de \(N\) bits, a menor variação detectável (LSB – Least Significant Bit) é:

\[
\Delta V = \frac{10\ \text{V}}{2^N}
\]

Por exemplo:

• ADC de 10 bits: \(\Delta V \approx 9{,}77\ \text{mV}\)
• ADC de 12 bits: \(\Delta V \approx 2{,}44\ \text{mV}\)

Esse valor define o limite teórico de resolução do sistema. Na prática, ruído, offset e erro de ganho costumam dominar antes mesmo do limite do ADC.

Quando 0–10 V faz sentido

O padrão 0–10 V é muito usado quando:

• as distâncias são curtas (painel ou máquina compacta);
• o ambiente eletromagnético é relativamente controlado;
• há necessidade de baixo custo e simplicidade;
• o sistema já possui entradas analógicas de alta impedância e boa referência de terra.

É exatamente nesses limites — ruído, referência de terra e distância — que o padrão 0–10 V começa a perder espaço para o 4–20 mA, que trata esses problemas de forma estrutural, e não apenas mitigativa.

Padrão 4–20 mA: robustez elétrica, “zero vivo” e imunidade a ruído

O padrão 4–20 mA foi adotado em larga escala porque resolve, de forma estrutural, problemas que no 0–10 V exigem cuidados adicionais. Aqui, a variável física não é representada por uma tensão absoluta, mas por uma corrente proporcional, que circula em um loop em série envolvendo transmissor, cabo, carga (burden) e fonte de alimentação. A grande vantagem é simples e poderosa: a corrente é a mesma em todos os pontos do loop, independentemente da resistência do cabo, desde que o transmissor tenha tensão suficiente para manter o regime.

Modelo elétrico do loop de corrente

Um loop típico pode ser modelado como:

• fonte de alimentação \(V_{loop}\),
• transmissor de corrente (sensor),
• resistência do cabo \(R_c\),
• resistência de carga \(R_b\) (burden resistor, onde a corrente é convertida em tensão),
• eventualmente dispositivos intermediários (isoladores, barreiras).

A tensão total necessária para o loop funcionar corretamente é:

\[
V_{loop} \ge V_{tx} + I \cdot (R_c + R_b)
\]

onde:

• \(V_{tx}\) é a tensão mínima de conformidade do transmissor,
• \(I\) é a corrente do loop (entre 4 e 20 mA).

Se essa condição for satisfeita, a corrente permanece correta, mesmo com variações de resistência do cabo, oxidação de contatos ou distâncias longas.

O conceito de “zero vivo” (4 mA)

Diferentemente de um sistema 0–20 mA, o uso de 4 mA como zero não é arbitrário. Ele resolve dois problemas fundamentais:

1. Detecção de falhas
   • 0 mA → fio rompido, transmissor sem alimentação ou falha grave.
   • 4 mA → zero físico medido, sistema operando normalmente.
2. Alimentação do próprio sensor
   Em muitos casos, o transmissor é alimentado pelo próprio loop (loop-powered). Os 4 mA mínimos garantem energia suficiente para a eletrônica interna.

O escalonamento linear clássico é:

\[
y = y_{\min} + \frac{(I – 4,\text{mA})}{16,\text{mA}} \cdot (y_{\max} – y_{\min})
\]

Por exemplo, em um sensor de pressão de 0–100 bar:

• 4 mA → 0 bar
• 12 mA → 50 bar
• 20 mA → 100 bar

Conversão corrente → tensão (burden resistor)

Na maioria dos sistemas embarcados e CLPs, o ADC mede tensão, não corrente. Por isso, usa-se um resistor de carga \(R_b\) para converter corrente em tensão:

\[
V = I \cdot R_b
\]

Valores típicos:

• \(R_b = 250,\Omega\) → 4–20 mA vira 1–5 V
• \(R_b = 100,\Omega\) → 0,4–2 V

A escolha de \(R_b\) é crítica:

• valores altos aumentam a tensão disponível para o ADC,
• valores altos também aumentam a tensão exigida do loop (impactando a conformidade).

Imunidade a ruído: por que funciona melhor

Ruídos eletromagnéticos tendem a se manifestar como tensões induzidas no cabo. Em um sistema de corrente:

• pequenas tensões parasitas não alteram significativamente a corrente do loop;
• o transmissor “força” a corrente correta dentro de sua faixa de conformidade.

Matematicamente, um ruído de tensão \(V_n\) somado ao loop gera uma variação de corrente:

\[
\Delta I = \frac{V_n}{R_{total}}
\]

Como \(R_{total}\) costuma ser relativamente alto (centenas de ohms), \(\Delta I\) é pequeno, tornando o sistema naturalmente mais imune.

Quando 4–20 mA é a melhor escolha

O padrão 4–20 mA é preferido quando:

• há longas distâncias (dezenas ou centenas de metros);
• o ambiente é eletricamente agressivo;
• é necessário diagnóstico simples de falhas;
• sensores precisam ser alimentados pelo próprio sinal;
• confiabilidade é mais importante que simplicidade.

Essa robustez explica por que, mesmo com fieldbuses modernos e Ethernet industrial, 4–20 mA continua extremamente atual.

Comparação direta: 0–10 V vs 4–20 mA e impactos no projeto de hardware e firmware

Depois de entender cada padrão isoladamente, a decisão de engenharia passa a ser comparativa e contextual. Não existe “melhor padrão absoluto”; existe o mais adequado ao cenário físico, elétrico e ao nível de confiabilidade exigido. Aqui vale olhar não só o sensor, mas o sistema completo: cabeamento, entradas analógicas, ADC, referência, firmware e manutenção.

Comparação elétrica fundamental

No 0–10 V, o sistema depende fortemente de uma referência comum de terra entre sensor e receptor. Qualquer diferença de potencial entre GNDs aparece diretamente como erro de medição. Em ambientes industriais, isso é frequente devido a:

• correntes de retorno pelo terra,
• malhas de aterramento,
• equipamentos de potência próximos.

Já no 4–20 mA, o loop é essencialmente diferencial em corrente. A referência de terra perde importância relativa, porque a variável medida é a corrente no circuito em série. Isso reduz drasticamente problemas de ground loop.

Comparação matemática do erro

Erro por resistência de cabo

• 0–10 V:
  \[
  \varepsilon_V \approx I_{in} \cdot R_c
  \]
  Onde \(I_{in}\) é a corrente drenada pela entrada. Se a impedância de entrada não for suficientemente alta, o erro cresce com o comprimento do cabo.
• 4–20 mA:
  \[
  \varepsilon_I \approx 0 \quad (\text{desde que haja conformidade})
  \]
  A resistência do cabo só “consome” tensão, não altera a corrente medida.

Erro por ruído

• 0–10 V:
  \[
  V_{med} = V_{sinal} + V_{ruído}
  \]
• 4–20 mA:
  \[
  \Delta I = \frac{V_{ruído}}{R_{loop}}
  \]
  Com \(R_{loop}\) elevado, a variação de corrente é pequena.

Impacto no projeto de hardware embarcado

Entradas analógicas (ADC)

• 0–10 V: geralmente exige divisor resistivo ou amplificador para adaptar ao range típico do ADC (0–3,3 V ou 0–5 V). Isso adiciona erro de ganho e offset.
• 4–20 mA: basta um resistor de precisão (ex.: 250 Ω, 0,1%) e, opcionalmente, um filtro RC simples. A conversão corrente→tensão é extremamente previsível.

Proteção elétrica

• 0–10 V: mais sensível a surtos e ESD, pois a entrada “vê” diretamente a tensão do campo.
• 4–20 mA: o loop naturalmente limita corrente; ainda assim, proteção contra sobretensão é aplicada, mas o sistema tende a ser mais tolerante.

Impacto no firmware

No firmware, ambos acabam convergindo para a mesma lógica: ler um ADC e aplicar um escalonamento linear. A diferença está na confiabilidade do dado bruto.

Exemplo conceitual comum:

\[
y = y_{\min} + \frac{(x – x_{\min})}{(x_{\max} – x_{\min})}(y_{\max} – y_{\min})
\]

Onde:

• em 0–10 V, (x) é a tensão medida,
• em 4–20 mA, (x) é a corrente (ou a tensão no burden resistor).

No entanto, no 4–20 mA, o firmware ganha uma vantagem adicional:

• leituras abaixo de 3,8 mA podem ser tratadas como falha de campo, e não apenas “valor baixo”.
  Isso simplifica diagnóstico, alarmes e estratégias de fail-safe.

Critérios práticos de escolha

Escolha 0–10 V quando:

• o sensor está próximo ao controlador;
• o ambiente é pouco ruidoso;
• custo e simplicidade são prioritários;
• o sistema é mais “máquina local” do que “planta industrial”.

Escolha 4–20 mA quando:

• há longas distâncias de cabo;
• existe forte interferência eletromagnética;
• confiabilidade e diagnóstico são críticos;
• sensores precisam ser alimentados pelo próprio sinal;
• o sistema faz parte de uma planta industrial maior.

Essa análise explica por que, mesmo em projetos modernos com microcontroladores avançados e Ethernet industrial, o front-end analógico 4–20 mA continua sendo padrão de ouro no chão de fábrica.

Integração prática com microcontroladores (STM32, ESP32): cálculo, front-end analógico e firmware

Ao integrar sensores 0–10 V ou 4–20 mA a microcontroladores, o desafio deixa de ser conceitual e passa a ser engenharia de interface: adaptar níveis elétricos ao ADC, preservar precisão, filtrar ruído e transformar a leitura bruta em uma variável física confiável no firmware.

Integração de sensores 0–10 V

A maioria dos microcontroladores (STM32, ESP32, RP2040) possui ADCs com faixa máxima de 3,3 V (alguns STM32 permitem 5 V externamente, mas o ADC interno continua limitado). Portanto, é necessário rebaixar a tensão.

Divisor resistivo
A solução mais simples é um divisor:

\[
V_{ADC} = V_{in} \cdot \frac{R_2}{R_1 + R_2}
\]

Para mapear 0–10 V em 0–3,3 V:

\[
\frac{R_2}{R_1 + R_2} = 0{,}33
\]

Um exemplo prático:

• \(R_1 = 20,k\Omega\)
• \(R_2 = 10,k\Omega\)

Cuidados importantes:

• resistores de 1% ou melhor (idealmente 0,1%);
• impedância equivalente não muito alta, para não prejudicar o sample-and-hold do ADC;
• uso de buffer com amplificador operacional se o cabo for longo ou a fonte tiver alta impedância.

Filtragem
Um filtro RC simples antes do ADC ajuda muito:

\[
f_c = \frac{1}{2\pi RC}
\]

Para sinais lentos (temperatura, nível), cortes entre 5 Hz e 20 Hz são comuns.

Integração de sensores 4–20 mA

Aqui o caminho é mais elegante e previsível.

Resistor de carga (burden)
Escolhendo \(R_b = 250,\Omega\):

\[
V = I \cdot R_b
\]

• 4 mA → 1,0 V
• 20 mA → 5,0 V

Se o ADC for de 3,3 V, duas opções surgem:

1. usar \(R_b = 165,\Omega\) → 0,66–3,3 V
2. manter 250 Ω e usar divisor/buffer.

A primeira opção costuma ser preferida pela simplicidade.

Potência do resistor
A potência dissipada é:

\[
P = I^2 \cdot R
\]

No pior caso (20 mA, 250 Ω):

\[
P = (0{,}02)^2 \cdot 250 = 0{,}1,W
\]

Logo, usa-se resistor de 0,25 W ou maior, com baixa deriva térmica.

Conversão no firmware

No firmware, a leitura do ADC ((N) bits) gera um valor digital (D):

\[
V_{ADC} = \frac{D}{2^N – 1} \cdot V_{ref}
\]

Para 4–20 mA:

\[
I = \frac{V_{ADC}}{R_b}
\]

E o escalonamento final:

\[
y = y_{\min} + \frac{(I – 4,\text{mA})}{16,\text{mA}}(y_{\max} – y_{\min})
\]

Boas práticas de firmware:

• rejeitar leituras abaixo de 3,8 mA (falha);
• filtrar por média móvel ou filtro IIR simples;
• separar claramente aquisição, conversão e lógica de controle.

Layout e EMC

Independentemente do padrão:

• mantenha trilhas analógicas longe de PWM, clocks e barramentos rápidos;
• use plano de terra contínuo;
• aterramento da blindagem do cabo em um único ponto;
• considere isolamento galvânico em ambientes severos.

Esses cuidados fazem mais diferença do que aumentar bits de ADC.

Seção 6 — Conclusão técnica: por que 0–10 V e 4–20 mA continuam dominantes na indústria

Mesmo com a evolução de barramentos digitais industriais, Ethernet determinística e sensores inteligentes, os padrões 0–10 V e 4–20 mA permanecem amplamente utilizados porque resolvem, de forma simples e comprovada, um problema central da automação: transportar informação analógica com previsibilidade em ambientes hostis. Eles não dependem de pilhas de protocolo, não exigem sincronismo complexo e falham de maneira compreensível para técnicos e engenheiros de campo.

O 0–10 V sobrevive pela simplicidade. Ele é direto, fácil de depurar com um multímetro comum e suficiente para aplicações locais, máquinas compactas e painéis onde o controle de aterramento e ruído é viável. Em termos de engenharia, é um padrão que funciona bem quando o sistema é tratado como um todo — sensor, cabo, referência e ADC — e quando as limitações são conscientemente aceitas.

Já o 4–20 mA permanece como referência em confiabilidade porque sua robustez é estrutural, não circunstancial. A imunidade a ruído, a tolerância a longas distâncias, a independência de referência de terra e o conceito de zero vivo fazem dele um padrão naturalmente alinhado com requisitos de segurança, manutenção e diagnóstico. Em projetos industriais reais, isso se traduz em menos paradas, menos ambiguidades e decisões mais claras no firmware e na operação.

Do ponto de vista de sistemas embarcados, esses padrões também ensinam uma lição importante: engenharia de sinal vem antes de sofisticação de processamento. Um ADC de alta resolução ou um algoritmo avançado não compensam um front-end mal escolhido. É por isso que, mesmo em arquiteturas modernas com STM32, ESP32 ou SoCs industriais, o caminho analógico clássico continua sendo a fundação.

Em resumo:

• 0–10 V é uma solução eficiente quando simplicidade e proximidade física são garantidas.
• 4–20 mA é a escolha natural quando confiabilidade, diagnóstico e ambiente industrial severo entram em jogo.
• a escolha correta reduz complexidade no hardware, no firmware e na manutenção ao longo de toda a vida útil do sistema.

Materiais para SEO

Título do artigo

Frase chave foco

The post Por que sensores industriais usam 0–10 V e 4–20 mA? Fundamentos, fórmulas e aplicações práticas first appeared on MCU & FPGA.

The post Comparação das Séries do Microcontrolador ESP32 first appeared on MCU & FPGA.

The post Espressif SoC Portfolio first appeared on MCU & FPGA.

Objetivo da Seção

Apresentar uma visão geral do papel do Linker no processo de construção de firmware, destacando:

• O que é o Linker e qual sua função;
• Como ele é usado para posicionar variáveis e trechos de código em regiões específicas da memória;
• A diferença entre seu uso em plataformas STM32 e ESP32;
• A importância dos arquivos .ld e partitions.csv no projeto embarcado.

Conceito Básico

Durante a compilação, o código-fonte (em C ou C++) é transformado em arquivos objeto .o. O Linker pega esses arquivos e os combina, resolvendo endereços de funções, referências cruzadas entre variáveis globais e posicionando tudo de acordo com o layout de memória definido pelo script .ld. Esse script age como um mapa da memória, especificando as regiões onde devem ser colocados:

• Código (.text);
• Dados inicializados (.data);
• Dados não inicializados (.bss);
• Pilha e heap;
• Tabelas de vetores de interrupção e memória de inicialização.

Plataformas em Destaque

• STM32: Usa arquivos .ld customizados que refletem a memória RAM e Flash, com seções bem definidas para bootloaders, vetores de interrupção, código principal, etc.
• ESP32: Usa também arquivos .ld, mas sua complexidade aumenta com a presença de múltiplas CPUs, caches e particionamento de memória Flash definido pelo partitions.csv.

Estrutura de um Arquivo LD: seções e símbolos

O script do Linker, geralmente com extensão .ld, descreve como o firmware será disposto na memória do dispositivo. Ele segue a sintaxe da linguagem de scripts do GNU Linker (ld) e define regiões de memória física e a atribuição de seções do programa nessas regiões. Essa estrutura garante que o código e os dados sejam colocados em áreas apropriadas da RAM e Flash.

Definindo a Memória

No início do arquivo .ld, define-se o layout físico da memória com a diretiva MEMORY. Essa seção especifica os nomes, tamanhos e endereços base da RAM, Flash e outras regiões, como SRAM2 ou CCM no STM32, ou RTC_SLOW na RAM do ESP32.

Exemplo – STM32:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
  RAM (xrw)  : ORIGIN = 0x20000000, LENGTH = 128K
}

Exemplo – ESP32:

MEMORY
{
  iram0_0_seg (RX) : org = 0x40080000, len = 0x20000
  dram0_0_seg (RW) : org = 0x3FFAE000, len = 0x20000
}

Seções Padrão

A diretiva SECTIONS define como as seções do código objeto (geradas pelo compilador) são mapeadas nas regiões de memória definidas anteriormente.

Principais seções:

• .isr_vector: Vetor de interrupções (normalmente colocado no início da Flash).
• .text: Código do programa.
• .rodata: Dados somente leitura (constantes).
• .data: Dados inicializados na RAM.
• .bss: Variáveis globais não inicializadas (zeradas na inicialização).
• .heap / .stack: Reservas para alocação dinâmica e pilha de execução.

Trecho típico:

SECTIONS
{
  .text :
  {
    KEEP(*(.isr_vector))
    *(.text*)
    *(.rodata*)
  } > FLASH

  .data : AT (ADDR(.text) + SIZEOF(.text))
  {
    *(.data*)
  } > RAM

  .bss :
  {
    *(.bss*)
    *(COMMON)
  } > RAM
}

Símbolos Especiais

Os scripts .ld frequentemente definem símbolos que serão usados no código C para indicar, por exemplo, o início e fim da RAM, do stack, ou a posição de carga de dados:

_end = .;
_estack = ORIGIN(RAM) + LENGTH(RAM);

No código C, podem ser declarados como:

extern uint32_t _estack;
extern uint32_t _end;

Observações Importantes

• A ordem das seções é essencial: o que estiver listado primeiro será posicionado primeiro na memória.
• A diretiva KEEP() impede que o Linker remova seções não referenciadas, comum em vetores de interrupção.
• A diretiva AT() é usada para indicar onde os dados residem na Flash antes de serem copiados para a RAM.

Diferenças entre os arquivos LD no STM32 e no ESP32

Embora tanto o STM32 quanto o ESP32 utilizem scripts .ld para definir o mapeamento de memória, existem diferenças estruturais e conceituais importantes entre essas plataformas. Essas diferenças são motivadas pelas arquiteturas distintas de hardware, modelos de inicialização e tipos de memória disponíveis.

STM32 – Arquitetura Simples e Direta

O STM32, baseado na arquitetura ARM Cortex-M, segue uma abordagem linear e previsível no mapeamento de memória. A memória Flash normalmente começa em 0x08000000, e a RAM em 0x20000000. A posição do vetor de interrupções (reset vector) é crucial, pois a CPU começa a executar a partir desse ponto após o reset.

Características:

• O arquivo .ld do STM32 é quase sempre dividido em FLASH e RAM;
• Contém o vetor de interrupções na primeira posição (.isr_vector);
• Define símbolos como _estack para controle da pilha;
• Permite personalizações simples para bootloaders ou seções específicas de RAM (como DTCM, SRAM2, CCMRAM, etc.);
• Ferramentas como STM32CubeIDE geram .ld automaticamente com base no modelo selecionado.

Exemplo típico de layout:

MEMORY
{
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
  RAM   (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
}

ESP32 – Arquitetura Multinível e Particionada

O ESP32 é mais complexo: possui múltiplos tipos de RAM (DRAM, IRAM, RTC RAM), cache externa e bootloader configurável. A memória Flash é externa e compartilhada entre o bootloader, partições de aplicativo, sistema de arquivos (SPIFFS/FFat) e NVS (armazenamento não-volátil).

Características:

• Utiliza vários arquivos .ld para diferentes segmentos (esp32.ld, memory.ld, sections.ld, etc.);
• Define múltiplas regiões: iram0, dram0, rtc_slow, rtc_fast, etc.;
• Utiliza a diretiva INCLUDE para modularizar o layout;
• Integra o conceito de partições, definidas no arquivo partitions.csv;
• O bootloader da Espressif localiza a partição de aplicação na Flash e carrega o código para a IRAM ou executa diretamente da Flash (via cache).

Trecho exemplo de esp32.ld:

MEMORY
{
  iram0_0_seg : org = 0x40080000, len = 0x20000
  dram0_0_seg : org = 0x3FFAE000, len = 0x20000
  rtc_slow_seg : org = 0x50000000, len = 0x2000
}

Principais Diferenças Resumidas

Entendendo o partitions.csv no ESP32

Resumo

O arquivo partitions.csv é um componente essencial nos projetos com ESP32. Ele define como a memória Flash externa será particionada para armazenar diferentes partes do firmware, como o bootloader, a aplicação principal, o sistema de arquivos (SPIFFS, FATFS, LittleFS), armazenamento de chaves criptográficas, dados de calibragem de RF, entre outros. É o que garante que o firmware saiba onde cada bloco de dados deve ser gravado e lido na memória externa.

O que é o partitions.csv?

É um arquivo de texto, em formato CSV (Comma-Separated Values), que define as partições da Flash para uso pelo bootloader e sistema operacional (no caso do ESP-IDF). Ele é convertido em um binário de tabela de partições que o bootloader carrega durante a inicialização.

Formato do Arquivo

Cada linha do partitions.csv define uma partição com os seguintes campos:

nome, tipo, subtipo, endereço, tamanho, flags

Exemplo comum:

# Nome      Tipo     Subtipo  Endereço   Tamanho    Flags
nvs         data     nvs      0x9000     0x5000
otadata     data     ota      0xe000     0x2000
app0        app      ota_0    0x10000    1M
app1        app      ota_1    0x110000   1M
spiffs      data     spiffs   0x210000   0xF0000

Campos Explicados

• nome: Identificador da partição (pode ser usado no código C, por exemplo para montar SPIFFS).
• tipo:
  • app: usado para partições de firmware.
  • data: para armazenamento persistente (ex: NVS, SPIFFS).
• subtipo:
  • factory, ota_0, ota_1: partições de aplicação.
  • nvs, spiffs, fat, ota, etc.: tipos específicos de dados.
• endereço: onde na memória Flash essa partição começa (em hexadecimal).
• tamanho: em bytes ou usando sufixos (K, M).
• flags: parâmetros opcionais (ex: encrypted para criptografia).

Como o partitions.csv é usado

1. Durante a compilação, o arquivo é processado e gera um binário chamado partition_table.bin.
2. Durante a gravação (flash), esse binário é gravado em um endereço fixo (tipicamente 0x8000).
3. Durante o boot, o bootloader do ESP32 lê essa tabela para saber onde está cada partição.
4. No código, você pode montar sistemas de arquivos ou acessar partições diretamente com base nos nomes definidos no CSV.

Customização

Você pode modificar o partitions.csv para incluir, por exemplo:

• Mais partições OTA para atualizações em lote;
• Uma partição para armazenamento FAT montado via esp_vfs_fat_mount;
• Uma partição para arquivos estáticos com LittleFS;
• Tamanhos reduzidos para aplicações mínimas.

Exemplo com FAT:

storage     data     fat      0x300000   512K

Estratégias de Construção de Arquivos LD: práticas e ferramentas

Resumo

A criação e manutenção de arquivos .ld pode ser feita manualmente ou gerenciada por ferramentas automáticas. Em sistemas embarcados, a escolha da estratégia depende da complexidade da aplicação, do ambiente de desenvolvimento e da necessidade de controle sobre o uso da memória. Nesta seção, exploramos como construir e adaptar arquivos de Linker para STM32 e ESP32, além das ferramentas que auxiliam no processo.

Construção Manual de Arquivos .ld

A escrita manual é útil em projetos onde se deseja controle total sobre a organização de memória — especialmente para bootloaders, realocação de código crítico em RAM, ou para usar áreas especiais como DTCM, CCM ou RTC.

Dicas práticas:

• Sempre comece definindo corretamente as regiões com MEMORY.
• Use SECTIONS para mapear precisamente o conteúdo dos binários.
• Defina símbolos auxiliares (_end, _stack_start) para controle no código C.
• Use KEEP() para evitar que o Linker remova trechos importantes como vetores de interrupção.
• Comente abundantemente o arquivo .ld — erros silenciosos podem causar falhas difíceis de depurar.

Uso de Ferramentas:

Para STM32:

• STM32CubeIDE / STM32CubeMX:
  • Gera automaticamente arquivos .ld com base no modelo do microcontrolador selecionado.
  • Permite configuração de áreas específicas de memória (ex: RAM2, CCMRAM).
  • Reorganiza o linker script ao incluir bibliotecas HAL ou FreeRTOS.
• GNU Arm Toolchain (arm-none-eabi-ld):
  • O script .ld é passado na linha de comando usando -T.
  • Pode ser usado em Makefiles ou CMake para projetos personalizados.

Para ESP32:

• ESP-IDF:
  • Utiliza um conjunto modular de scripts .ld organizados em:
    • memory.ld: define as regiões de memória disponíveis.
    • sections.ld: organiza onde o código e dados são colocados.
    • esp32.ld: script de entrada que inclui os anteriores.
  • Permite criar fragmentos de linker (ld fragments) no diretório do componente para colocar variáveis em regiões específicas, como IRAM.

Exemplo de fragmento:

myvar (noinit) : ALIGN(4)
{
  _myvar_start = .;
  KEEP(*(.myvar_section))
  _myvar_end = .;
} > DRAM

• idf.py linkmap:
  • Gera o mapa de ligação (.map) detalhado, útil para depuração de problemas de alocação de memória.

Boas Práticas

• Sempre gere e revise o mapa de ligação (.map) após compilar. Ele mostra o endereço final de cada seção.
• Valide o tamanho das regiões para evitar sobreposição.
• Em projetos com OTA, certifique-se de que as partições app0/app1 não ultrapassem o tamanho máximo.
• Use ASSERT() no script .ld para verificar restrições em tempo de link:

ASSERT(SIZEOF(.data) < 0x2000, "Data section too big!")

Casos Práticos: Customizando o Linker para necessidades reais

Resumo

Customizar o script de Linker permite criar soluções otimizadas para aplicações embarcadas que demandam desempenho, economia de energia ou acesso rápido à memória. A seguir, são apresentados exemplos reais de customizações em projetos com STM32 e ESP32, incluindo alocação de variáveis em regiões específicas, execução de código diretamente na RAM, buffers persistentes e uso de seções noinit.

Executar código diretamente na RAM (STM32)

Para funções críticas em tempo real — como interrupções com baixa latência — pode ser necessário colocá-las na RAM, onde a execução é mais rápida que na Flash.

Etapas:

1. Criar uma seção .ramfunc no script:

.ramfunc :
{
  *(.ramfunc*)
} > RAM

2. Declarar a função no código com atributo:

__attribute__((section(".ramfunc"))) void critical_ISR(void) {
  // Código de alta prioridade
}

3. (Opcional) Garantir cópia da Flash para RAM durante a inicialização usando AT() e símbolos auxiliares para copiar os dados.

2Criar buffers fixos em local específico da RAM (ESP32 e STM32)

Se você precisa garantir que um buffer de DMA fique em uma região não cacheada da memória (ou alinhada), é possível forçar sua posição.

ESP32 – usando fragmento de linker:

1. Crie um arquivo linker_fragment.ld no componente:

__dma_buffer_start = .;
.dma_buffer (NOLOAD):
{
  . = ALIGN(32);
  KEEP(*(.dma_buffer))
  . = ALIGN(32);
} > DRAM
__dma_buffer_end = .;

2. No código:

__attribute__((section(".dma_buffer"))) uint8_t dma_rx[256];

3. Buffer persistente entre resets (seção .noinit)

A seção .noinit impede que variáveis sejam zeradas na inicialização. Isso é útil para armazenar dados temporários entre resets, watchdogs ou soft reboots.

Script LD:

.noinit (NOLOAD):
{
  *(.noinit*)
} > RAM

Código C:

__attribute__((section(".noinit"))) uint32_t retained_counter;

Importante: você é responsável por inicializar essa variável, pois o C startup não o fará.

4. Espaço reservado para bootloader ou firmware OTA

Em projetos com bootloaders, você pode reservar o início da Flash para ele e mover o início da aplicação:

MEMORY
{
  BOOTLOADER (rx) : ORIGIN = 0x08000000, LENGTH = 16K
  APP_FLASH  (rx) : ORIGIN = 0x08004000, LENGTH = 496K
}

E ajustar o início da seção .text para a nova região APP_FLASH.

5. Dividindo a RAM em blocos com finalidades distintas

No STM32 com RAMs separadas (SRAM1, SRAM2), você pode mover buffers grandes para a RAM auxiliar:

MEMORY
{
  RAM1 (xrw): ORIGIN = 0x20000000, LENGTH = 96K
  RAM2 (xrw): ORIGIN = 0x20018000, LENGTH = 32K
}

.bigbuffers (NOLOAD):
{
  *(.bigbuffer*)
} > RAM2

Esses exemplos ilustram o poder e a flexibilidade dos scripts de Linker quando bem utilizados. Customizá-los pode ser a chave para alcançar desempenho, estabilidade e segurança em sistemas embarcados críticos.

Considerações Finais e Dicas de Diagnóstico

A compreensão e personalização de scripts de Linker são habilidades essenciais para engenheiros de sistemas embarcados. Erros nesse estágio podem resultar em falhas silenciosas, corrupção de dados, mau uso de memória e comportamento imprevisível do firmware. Esta seção final destaca boas práticas, armadilhas comuns e ferramentas úteis para diagnóstico e validação do layout de memória.

Boas Práticas ao Trabalhar com .ld

• Comente extensivamente cada bloco do script para documentar a intenção de uso de cada região.
• Use símbolos nomeados (_start, _end, stack_top) para facilitar o acesso no código C.
• Divida responsabilidades em arquivos menores com INCLUDE (usado amplamente no ESP-IDF).
• Crie seções específicas para dados críticos, buffers, código de interrupção ou dados de boot.
• Teste variações de layout com segurança em projetos de bootloader + aplicação OTA.

Validação com o Arquivo .map

Após a compilação, o GCC gera um arquivo de mapa de ligação (.map), contendo o endereço real de cada símbolo, função e variável alocada.

Dicas para leitura do .map:

• Verifique se há sobreposição entre seções;
• Confirme se buffers grandes foram realmente colocados em RAM auxiliar;
• Localize variáveis em .bss que estão ocupando muito espaço;
• Confirme se a tabela de interrupções foi posicionada corretamente (ex: início da Flash).

Uso de ASSERTs no Linker

Para evitar erros silenciosos, você pode usar ASSERT() no script .ld para impor limites:

ASSERT(SIZEOF(.data) <= 0x2000, "Erro: a seção .data ultrapassou o limite da RAM!")

Isso impede que a compilação gere um firmware que vá ultrapassar o espaço físico disponível.

Ferramentas de Apoio

• objdump (arm-none-eabi-objdump -h): mostra as seções e onde foram colocadas.
• nm (arm-none-eabi-nm): lista símbolos com endereços — útil para variáveis específicas.
• size (arm-none-eabi-size): resume o tamanho das seções .text, .data e .bss.
• idf.py size-components (ESP32): mostra quanto cada componente ocupa na Flash/RAM.
• STM32CubeIDE: gera visualizações gráficas do uso de memória, além de adaptar o linker automaticamente.

Armadilhas Comuns

• Esquecer de alinhar buffers de DMA (pode causar falha silenciosa).
• Colocar código na IRAM sem definir corretamente as seções no ESP32.
• Deixar variáveis grandes na .data (copiadas da Flash para a RAM, consumindo tempo e espaço).
• Não usar NOLOAD em seções como .noinit, resultando em perda de dados após o reset.

Conclusão

Scripts de Linker não são apenas “detalhes técnicos”, mas componentes essenciais que controlam como o firmware funciona na prática. Dominar sua estrutura, lógica e sintaxe permite que você construa sistemas mais rápidos, estáveis e confiáveis — explorando ao máximo o hardware disponível, seja no robusto STM32 ou no versátil ESP32.

The post Introdução ao Linker em Sistemas Embarcados first appeared on MCU & FPGA.

O Que São Ontologias?

Ontologias são estruturas formais que definem conceitos, categorias e as relações entre eles em um determinado domínio. Elas funcionam como um “dicionário inteligente”, permitindo que sistemas diferentes compartilhem uma compreensão comum dos dados. Por exemplo, dois sensores de temperatura diferentes podem enviar dados em formatos distintos, mas uma ontologia permite que ambos sejam compreendidos como representações da mesma informação semântica: a temperatura ambiente.

O Papel do Gateway Ontológico

Gateways são dispositivos intermediários que conectam sensores, atuadores e sistemas maiores, como servidores em nuvem. Quando dotados de capacidade ontológica, esses gateways não apenas transmitem dados, mas também interpretam, traduzem e contextualizam as informações de acordo com uma ontologia comum.

Imagine o seguinte cenário:

• Um sensor envia { "tmp": 25 }
• Outro envia { "temperature": { "value": 25, "unit": "C" } }

Ambos indicam temperatura, mas de formas distintas. O gateway com suporte ontológico é capaz de interpretar que tmp e temperature.value representam o mesmo conceito, e traduzi-los para uma ontologia comum como OWL (Web Ontology Language), mapeando os dados para, por exemplo:

<Temperature rdf:about="#sensor1">
  <hasValue rdf:datatype="xsd:float">25.0</hasValue>
  <hasUnit rdf:datatype="xsd:string">Celsius</hasUnit>
</Temperature>

Exemplo de Implementação em C com ESP32

Para ilustrar, vamos criar uma estrutura básica para um gateway que recebe dados de sensores via UART e traduz essas informações para um modelo RDF simplificado, ainda em C.

typedef struct {
    float value;
    char unit[10];
    char semantic_id[32]; // Ligação com ontologia
} SensorData;

void parse_uart_message(const char* raw, SensorData* data) {
    // Exemplo bruto: "tmp=25.5;unit=C"
    sscanf(raw, "tmp=%f;unit=%s", &data->value, data->unit);
    strcpy(data->semantic_id, "http://example.org/ontology#Temperature");
}

void print_rdf(SensorData* data) {
    printf("<Temperature rdf:about=\"#sensor1\">\n");
    printf("  <hasValue rdf:datatype=\"xsd:float\">%.2f</hasValue>\n", data->value);
    printf("  <hasUnit rdf:datatype=\"xsd:string\">%s</hasUnit>\n", data->unit);
    printf("</Temperature>\n");
}

Este exemplo mostra como uma mensagem recebida pode ser traduzida para uma estrutura semântica compreensível por serviços externos.

Benefícios da Integração Ontológica

• Interoperabilidade: dispositivos de diferentes fabricantes e protocolos podem ser integrados sem ajustes manuais.
• Descoberta automática: novos dispositivos podem ser automaticamente identificados e compreendidos.
• Integração com IA: sistemas de inteligência artificial podem raciocinar sobre os dados com base em seus significados e não apenas em seus valores.

Tecnologias Complementares

Para gateways mais avançados, bibliotecas como OWL API (Java) ou RDF4C (C) podem ser incorporadas ao sistema. Em dispositivos embarcados como ESP32, devido às limitações de memória, uma alternativa é converter os dados para formatos semânticos leves (como JSON-LD ou RDFa) e enviá-los para processamento posterior em um servidor.

Gateways ontológicos são peças-chave para tornar a IoT verdadeiramente inteligente. Eles não apenas conectam dispositivos, mas traduzem dados brutos em conhecimento compreensível e compartilhável. A adoção de ontologias nos gateways eleva o patamar da integração de sistemas embarcados, tornando possível a construção de aplicações robustas, escaláveis e orientadas ao significado.

A integração semântica de dispositivos embarcados por meio de gateways ontológicos representa um salto qualitativo na construção de sistemas IoT e automação inteligente. Em vez de apenas trafegar dados, esses gateways entendem e contextualizam as informações que circulam na rede, favorecendo a interoperabilidade, a escalabilidade e a tomada de decisão automatizada.

A mini-ontologia apresentada aqui oferece uma base para representar sensores de ambiente com consistência semântica, enquanto o exemplo em Python com RDFLib mostra como esse modelo pode ser aplicado facilmente em servidores de borda ou aplicações em nuvem.

Benefícios em Destaque

• Interoperabilidade total: Dispositivos de diferentes fabricantes e protocolos convergem para uma linguagem comum baseada em ontologia.
• Rastreamento e auditoria: Cada medição é armazenada com significado explícito, facilitando auditorias e diagnósticos.
• Base para inteligência artificial: A semântica dos dados permite raciocínio automatizado, inferências e respostas proativas.
• Escalabilidade: Novos sensores podem ser adicionados com mínima ou nenhuma reconfiguração.

Desafios

• Capacidade computacional dos gateways: Processamento ontológico exige memória e poder de CPU, o que pode ser limitado em dispositivos embarcados.
• Curva de aprendizado: Tecnologias como OWL, RDF, SPARQL e ferramentas como RDFLib ou Protégé podem exigir treinamento específico.
• Padrões em evolução: O ecossistema semântico ainda está amadurecendo no contexto de sistemas embarcados.

Caminhos Futuros

• Uso de ontologias padronizadas, como SSN (Semantic Sensor Network) da W3C;
• Integração com bancos de dados triplestore como GraphDB, Jena Fuseki ou Blazegraph;
• Visualização semântica com dashboards interativos baseados em React ou Grafana;
• Extensão da ontologia para atuadores, eventos temporais e alertas automatizados.

Em um mundo cada vez mais conectado, onde sensores e dispositivos proliferam em ritmo exponencial, os gateways com suporte ontológico surgem como peças-chave para transformar dados dispersos em conhecimento útil e acionável.

The post Gateways que Integram Dados Ontológicos de Dispositivos Embarcados first appeared on MCU & FPGA.

O uso de ontologias, tradicionalmente vinculado às ciências cognitivas e à web semântica, vem ganhando espaço em contextos mais técnicos como a Internet das Coisas (IoT) e os Sistemas Embarcados. Neste artigo, exploramos como ontologias podem organizar o conhecimento de sensores, dispositivos e contextos de forma padronizada e interoperável, facilitando o desenvolvimento, a escalabilidade e a manutenção de sistemas inteligentes. Também apresentamos exemplos práticos de aplicação em C no ESP32.

O que é Ontologia em Computação?

Na ciência da computação, uma ontologia é uma representação estruturada de conhecimento de um domínio específico, composta por:

• Conceitos (classes) — como “Temperatura”, “Sensor”, “Dispositivo”
• Propriedades (atributos) — como “valor”, “unidade”, “timestamp”
• Relações — como “um Sensor mede uma Temperatura”
• Regras de inferência e restrições — como “um valor de temperatura em °C deve estar entre -40 e 125”.

Aplicações de Ontologia em IoT e Sistemas Embarcados

1. Interoperabilidade Semântica

Permite que sensores de diferentes fabricantes “falem a mesma língua” em gateways, hubs ou sistemas centralizados.

2. Autodescrição de Dispositivos

Usando ontologias, um sensor pode anunciar seu tipo, unidade de medida, intervalo de operação, e método de leitura, facilitando configuração automática.

3. Raciocínio Baseado em Regras

Um sistema pode inferir que “o ambiente está em risco de incêndio” se Temperatura > 60°C e Sensor de Fumaça = Ativado.

4. Diagnóstico e Autoconfiguração

Ontologias permitem definir causas e efeitos, como “se umidade estiver zero e temperatura estiver alta, o sensor pode estar desconectado”.

Estrutura Ontológica Simples para Sensores

Vamos criar uma mini ontologia em C para o ESP32, simulando algo como:

Sensor → Temperatura
        → Umidade

Sensor tem:
  - nome
  - unidade
  - valor
  - função de leitura

Exemplo em C para ESP32

Estrutura Base

typedef struct {
    char nome[20];
    char unidade[10];
    float valor;
    float (*lerValor)(void);  // ponteiro para função de leitura
} Sensor;

Funções de Leitura Simuladas

float lerTemperatura() {
    // Simula leitura de sensor
    return 25.0 + (rand() % 1000) / 100.0;
}

float lerUmidade() {
    return 40.0 + (rand() % 1000) / 100.0;
}

Criando os Sensores

Sensor sensorTemp = {
    .nome = "Temperatura",
    .unidade = "C",
    .lerValor = lerTemperatura
};

Sensor sensorUmi = {
    .nome = "Umidade",
    .unidade = "%",
    .lerValor = lerUmidade
};

Leitura em Loop

void loopSensores() {
    sensorTemp.valor = sensorTemp.lerValor();
    sensorUmi.valor = sensorUmi.lerValor();

    printf("Sensor: %s = %.2f %s\n", sensorTemp.nome, sensorTemp.valor, sensorTemp.unidade);
    printf("Sensor: %s = %.2f %s\n", sensorUmi.nome, sensorUmi.valor, sensorUmi.unidade);
}

Expandindo com Inferência Simples

Vamos fazer uma “regra ontológica” hardcoded:

void verificarCondicoes() {
    if (sensorTemp.valor > 60.0 && sensorUmi.valor < 10.0) {
        printf("⚠ Risco de superaquecimento e ar seco!\n");
    }
}

Benefícios Concretos

• Reuso de código com base em tipos semânticos
• Padronização do comportamento de sensores
• Capacidade de diagnóstico automatizado
• Facilidade para integração com sistemas semânticos (ex: OWL + MQTT + RDF)

Ontologia em Comunicação Semântica: Integrando ESP32 com MQTT

Além da modelagem local de sensores no firmware, as ontologias brilham quando utilizadas em sistemas distribuídos, permitindo que um sensor transmita dados já semânticos, ou seja, com significado explícito.

Vamos ver como isso funciona na prática, criando uma camada que transmite dados com metadados semânticos usando MQTT — um dos protocolos mais populares em IoT.

Estrutura da Mensagem Ontológica

Em vez de apenas transmitir 25.3, transmitimos algo como:

{
  "sensor": "Temperatura",
  "valor": 25.3,
  "unidade": "C",
  "contexto": "ambiente_interno",
  "tipo": "observação",
  "timestamp": 1711459200
}

Essa estrutura, ainda que JSON simples, representa uma mini-ontologia em ação.

Enviando via MQTT com ESP32 (usando PubSubClient)

Instalação das dependências (no PlatformIO ou Arduino IDE)

lib_deps =
  knolleary/PubSubClient
  bblanchon/ArduinoJson

Código para Envio com Ontologia JSON

#include <WiFi.h>
#include <PubSubClient.h>
#include <ArduinoJson.h>

WiFiClient espClient;
PubSubClient mqtt(espClient);

const char* ssid = "SuaRedeWiFi";
const char* password = "SenhaDaRede";
const char* mqttServer = "broker.hivemq.com";

void conectarWiFi() {
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) delay(500);
}

void conectarMQTT() {
  mqtt.setServer(mqttServer, 1883);
  while (!mqtt.connected()) {
    mqtt.connect("esp32_ontologia");
  }
}

Função para Enviar um Dado Semântico

void enviarDadoOntologico(Sensor sensor, const char* contexto) {
  StaticJsonDocument<256> doc;
  doc["sensor"] = sensor.nome;
  doc["valor"] = sensor.valor;
  doc["unidade"] = sensor.unidade;
  doc["contexto"] = contexto;
  doc["tipo"] = "observação";
  doc["timestamp"] = millis();  // em produção use RTC ou NTP

  char mensagem[256];
  serializeJson(doc, mensagem);
  mqtt.publish("iot/esp32/sensores", mensagem);
}

Uso no Loop

void loop() {
  if (!mqtt.connected()) conectarMQTT();
  mqtt.loop();

  sensorTemp.valor = sensorTemp.lerValor();
  sensorUmi.valor = sensorUmi.lerValor();

  enviarDadoOntologico(sensorTemp, "ambiente_interno");
  enviarDadoOntologico(sensorUmi, "ambiente_interno");

  delay(5000);
}

Compatibilidade com Ontologias OWL/RDF

Esses dados, ao serem coletados no broker, podem ser convertidos para RDF ou consultados com SPARQL, caso estejam armazenados em uma base semântica (como o Apache Jena).

Você pode criar um mapeamento semântico entre o JSON e uma ontologia OWL, como:

:Sensor rdf:type owl:Class .
:valor rdf:type owl:DatatypeProperty ; rdfs:domain :Sensor ; rdfs:range xsd:float .

Benefícios de Integrar Ontologia com MQTT

• Reuso e composição automática de dados
• Integração com Knowledge Graphs e inferência
• Consulta semântica unificada de dispositivos heterogêneos
• Facilidade de extensão: novos sensores, mesmos padrões

Conclusão

A introdução de ontologias no desenvolvimento de sistemas embarcados e IoT não é apenas uma questão teórica — é uma abordagem pragmática para lidar com complexidade, interoperabilidade e evolução dos sistemas. Mesmo em plataformas como o ESP32, com recursos limitados, é possível aplicar os princípios semânticos para criar sistemas mais inteligentes, autodescritivos e expansíveis.

The post Ontologias Aplicadas a Sistemas Embarcados e IoT first appeared on MCU & FPGA.