Fase 1: Fundamentos de C y Lógica de Software

📖 Teoría a Estudiar

Revisión de Firmware y Limpieza de Código

Escribir código que "funcione" es solo la primera mitad del trabajo de un ingeniero de firmware. En la industria, el código que controla maquinaria pesada o fluidos a presión (como el Gas LP) debe ser auditable, escalable y mantenible. A este proceso de mejora interna, sin cambiar el comportamiento externo, se le llama Refactorización.

Una revisión técnica estricta busca erradicar "Código Espagueti" (lógica entrelazada), eliminar "Números Mágicos" (valores literales en el código sin explicación) y establecer una Arquitectura Modular. Además, en sistemas críticos automotrices e industriales, se siguen estándares como MISRA-C, que prohíbe ciertas prácticas de C que son propensas a errores silenciosos.

Los 3 Pasos de la Limpieza

1. Erradicar Números Mágicos: Si escribes if(presion > 250), nadie sabrá si 250 son PSI, bares o pulsos crudos del ADC. Reemplázalos siempre por directivas #define MAX_PRESION_PSI 250 o const.
2. Separación de Capas (Decoupling): Tu código matemático/lógico (Capa de Aplicación) jamás debe escribir directamente en un registro de silicio (ej. GPIOA->ODR = 1;). Debe llamar a una función semántica (ej. bomba_encender();) que viva en un archivo de capa inferior (Driver/HAL).
3. Eliminar Código Muerto (Dead Code): Funciones comentadas, variables declaradas que no se leen y "pruebas temporales" deben borrarse antes del commit final. Ensucian la lectura y aumentan el tamaño del binario innecesariamente.

⚙️ Ejercicios Prácticos

Ejercicio 1: Analiza el siguiente bloque de código. Representa una refactorización donde pasamos de un "código espagueti" acoplado, a un firmware industrial limpio, semántico y modular usando macros y abstracción.

#include <stdint.h>
#include <stdbool.h>

// =========================================================================
// ❌ ANTES (Código Espagueti Amateur - NO HACER)
// =========================================================================
/*
void despachar_gas_malo(uint16_t adc_val) {
    // ¿Qué es 3500? ¿Qué es PORTB? Pésima legibilidad.
    if (adc_val > 3500) { 
        PORTB &= ~(1 << 4); 
    } else {
        PORTB |= (1 << 4);
    }
}
*/


// =========================================================================
// ✅ DESPUÉS (Arquitectura Modular Profesional)
// =========================================================================

// --- 1. ARCHIVOS DE CONFIGURACIÓN (config.h) ---
#define UMBRAL_PRESION_MAX_ADC 3500   // Límite de seguridad de 85% de llenado
#define ESTADO_SEGURO_OFF      0
#define ESTADO_ACTIVO_ON       1

// --- 2. CAPA DE DRIVERS DE HARDWARE (valvula_driver.c) ---
// Esta función abstrae el silicio del STM32/ESP32. Si mañana cambias
// de microcontrolador, SOLO modificas esta función.
void driver_valvula_principal_set(uint8_t estado) {
    if (estado == ESTADO_ACTIVO_ON) {
        // Pseudo-código de hardware
        // GPIOB->BSRR = (1 << 4); 
    } else {
        // GPIOB->BSRR = (1 << 20); // Reset pin
    }
}

// --- 3. CAPA DE APLICACIÓN LOGICA (control_gas.c) ---
// Lógica pura. Entendible por cualquier ingeniero que la lea.
bool evaluar_seguridad_tanque(uint16_t lectura_actual_adc) {
    if (lectura_actual_adc >= UMBRAL_PRESION_MAX_ADC) {
        return false; // Peligro
    }
    return true;      // Seguro
}

void despachador_maquina_estados(uint16_t sensor_adc) {
    
    if (evaluar_seguridad_tanque(sensor_adc) == false) {
        // Cierre inmediato, código semántico
        driver_valvula_principal_set(ESTADO_SEGURO_OFF);
        // disparar_alarma_visual();
    } else {
        // Operación normal
        driver_valvula_principal_set(ESTADO_ACTIVO_ON);
    }
}

// --- PUNTO DE ENTRADA ---
int main(void) {
    while(1) {
        uint16_t adc_crudo = 3600; // Simulación de lectura del sensor
        despachador_maquina_estados(adc_crudo);
    }
    return 0;
}
        

📝 Resumen del Día

• Los Números Mágicos son el enemigo de la mantenibilidad. Usa `#define` o `const` para nombrar de forma descriptiva todos tus límites operativos, tiempos (delays) y umbrales.
• Adoptar una mentalidad MISRA-C significa escribir firmware predecible, defensivo y donde las intenciones del programador son explícitas y evidentes a simple vista.
• La Abstracción en Capas evita que un cambio de hardware (ej. mover un LED del pin A al pin B) requiera reescribir toda la lógica de la máquina de estados.