Fase 5: Diseño Industrial y Proyecto Final

📖 Teoría a Estudiar

El Gemelo Digital y la Inmutabilidad (CI/CD)

CI (Continuous Integration): Significa que cada vez que tú o un miembro de tu equipo guardan un cambio en el código (hacen git push), un servidor en la nube (ej. GitHub Actions, GitLab CI) crea una máquina virtual limpia, descarga la cadena de herramientas exacta (GNU Arm Embedded Toolchain), compila tu código y ejecuta pruebas automáticas.

CD (Continuous Deployment): Si la compilación es exitosa y cumple con las reglas MISRA-C, el servidor empaqueta el archivo .bin, calcula su Checksum (CRC/SHA256) y lo inyecta automáticamente en los servidores de Amazon Web Services (AWS) listo para que tu flota de máquinas lo descargue vía FOTA.

¿Por qué es obligatorio en Hardware? (Reproducibilidad)

En el mundo del software web, si algo falla, recargas la página. En el mundo del hardware, un binario compilado con el parámetro de optimización -O3 puede alterar los retardos de tiempo que usa tu bus SPI, destruyendo la comunicación con el Caudalímetro. Al usar CI/CD, garantizamos Inmutabilidad: el binario de producción siempre será generado por el mismo robot, en el mismo sistema operativo (Ubuntu Linux), con las mismas banderas exactas de compilación, eliminando el error humano.

⚙️ Ejercicios Prácticos

El Archivo YAML (La Receta del Robot): Configurar CI/CD moderno ya no requiere montar servidores Jenkins complejos. Usaremos GitHub Actions. Creamos un archivo oculto en nuestro repositorio en la ruta .github/workflows/firmware_build.yml. Este archivo contiene las instrucciones (script) que le dirán a los servidores de Microsoft/GitHub cómo construir exactamente el binario del Despachador de Gas LP.

Ejercicio 1: El Pipeline YAML de Hardware. Escribiremos el flujo de trabajo que se activará cada vez que hagamos un `push` a la rama `main`.

# ==============================================================================
# ARCHIVO: .github/workflows/firmware_build.yml
# ==============================================================================
name: CI Firmware Build (STM32)

# El evento que dispara este flujo de trabajo
on:
  push:
    branches: [ "main", "release/*" ]
  pull_request:
    branches: [ "main" ]

# Trabajos a ejecutar
jobs:
  build-and-analyze:
    name: Compilar y Analizar Firmware STM32
    # Máquina virtual en la que correremos (Servidor Linux provisto por GitHub)
    runs-on: ubuntu-latest

    steps:
    # 1. CLONAR EL REPOSITORIO
    - name: Checkout del código fuente
      uses: actions/checkout@v3
      with:
        submodules: recursive # Importante si usas librerías como FreeRTOS en submódulos

    # 2. INSTALAR DEPENDENCIAS DE HARDWARE (ARM TOOLCHAIN)
    - name: Instalar GNU Arm Embedded Toolchain
      run: |
        sudo apt-get update
        # Instala el compilador oficial de ARM para Cortex-M y la herramienta Make
        sudo apt-get install -y gcc-arm-none-eabi binutils-arm-none-eabi build-essential cmake

    # 3. ANÁLISIS ESTÁTICO DE CÓDIGO (Pre-compilación)
    - name: Análisis MISRA-C Básico (Cppcheck)
      run: |
        sudo apt-get install -y cppcheck
        # Busca desbordamientos, variables no usadas y bugs lógicos
        # Fallará el pipeline si encuentra un error grave.
        cppcheck --enable=all --error-exitcode=1 --inconclusive -I Core/Inc Core/Src

    # 4. CONSTRUCCIÓN (BUILD)
    # Suponiendo un proyecto exportado de STM32CubeMX con Makefile generado
    - name: Compilar Firmware (Make)
      run: |
        # Entra a la carpeta del proyecto y ejecuta el Make
        # -j4 usa 4 núcleos de CPU para acelerar la compilación
        make -j4
        
        # Opcional: Imprime el tamaño de las secciones Flash/RAM
        arm-none-eabi-size build/despachador_gas_lp.elf

    # 5. GENERAR SHA-256 PARA INTEGRIDAD DE FOTA
    - name: Generar Hash del Binario
      run: |
        sha256sum build/despachador_gas_lp.bin > build/despachador_gas_lp.bin.sha256
        cat build/despachador_gas_lp.bin.sha256

    # 6. GUARDAR LOS ARTEFACTOS (El producto final)
    # Toma los archivos compilados y los guarda en GitHub para su descarga 
    # o posterior envío a los servidores OTA.
    - name: Subir Artifacts de Firmware
      uses: actions/upload-artifact@v3
      with:
        name: Firmware-Release-Binaries
        path: |
          build/despachador_gas_lp.bin
          build/despachador_gas_lp.elf
          build/despachador_gas_lp.bin.sha256
        retention-days: 30
        

📝 Resumen del Día

• En entornos profesionales de desarrollo de hardware, la compilación de binarios de producción (Release) nunca debe hacerse en las máquinas locales de los desarrolladores, ya que las diferencias en los sistemas operativos y herramientas introducen inconsistencias mortales (El problema de "Funciona en mi máquina").
• CI/CD (Continuous Integration / Continuous Deployment) para embebidos requiere configurar un archivo de instrucciones (ej. YAML en GitHub Actions) que automatiza la creación de un entorno estéril de compilación por cada cambio de código.
• El Pipeline debe instalar la cadena de herramientas cruzada exacta, como GNU Arm Embedded Toolchain (gcc-arm-none-eabi), que permite a un servidor de arquitectura Intel/x86 compilar instrucciones para silicio ARM Cortex-M.
• Una de las mayores ventajas del CI/CD es la automatización del Análisis Estático (Linting). Herramientas de bajo consumo en la terminal como cppcheck inspeccionan el código buscando fugas de memoria o errores lógicos severos antes de siquiera intentar compilar, bloqueando subidas de código peligrosas.
• El último paso del pipeline es la recolección de los Artifacts (Artefactos). El archivo .bin resultante se empaqueta junto con su firma de verificación (Hash SHA-256) y se expone para que otros sistemas automáticos lo descarguen y lo envíen a los servidores FOTA (Firmware Over-The-Air) de AWS.