TinyGo: Compilación optimizada para sistemas embebidos y WASM

TinyGo es un compilador basado en LLVM diseñado para generar binarios extremadamente pequeños para entornos con recursos limitados, como microcontroladores (ESP32, Arduino, Raspberry Pi Pico) o WebAssembly (WASM). Mientras que el compilador estándar de Go (gc) está optimizado para el throughput y la ejecución de procesos pesados en sistemas operativos complejos, TinyGo está diseñado para la densidad de código y el uso mínimo de memoria RAM y Flash. Esto se logra mediante un runtime simplificado que prescinde de la complejidad del scheduler de Go estándar y utiliza un recolector de basura (GC) mucho más ligero, a menudo orientado a la baja fragmentación de memoria.

Debes entender que TinyGo no es un “drop-in replacement” para todo uso; es una herramienta especializada. El diseño responde a la restricción física de los microcontroladores: un chip con apenas 32KB de RAM no puede soportar la estructura de datos de una goroutine estándar ni el overhead de un scheduler basado en la segmentación de stacks clásica de Go. Por tanto, TinyGo optimiza la arquitectura para que el código sea ejecutable en hardware donde el tamaño del binario es el factor determinante. Debes usar TinyGo cuando tu objetivo sea desarrollar firmware para dispositivos IoT, sensores de bajo consumo o módulos WASM que deban cargarse rápidamente en un navegador o un motor de ejecución ligero. Si intentas compilar un servidor web complejo que dependa de la reflexión (reflect) masiva o de la biblioteca estándar completa, te encontrarás con errores de compilación o binarios que superan la capacidad de memoria del target, ya que muchas funciones de la stdlib se omiten para mantener la ligereza.

package example_test

import (
	"errors"
	"testing"
	"time"
)

// Sensor define la interfaz para la abstracción de hardware (HAL).
// En TinyGo, el uso de interfaces es fundamental para permitir el testing
// en una arquitectura x86/arm64 antes de desplegar en el hardware real.
type Sensor interface {
	Read() (float64, error)
}

// MockSensor permite simular el comportamiento de un sensor físico
// (ej. un sensor de temperatura DHT22) durante las pruebas unitarias.
type MockSensor struct {
	valorSimulado float64
	errorSimulado error
}

func (m *MockSensor) Read() (float64, error) {
	return m.valorSimulado, m.errorSimulado
}

// Controller encapsula la lógica de control del dispositivo.
// Al depender de una interfaz y no de una implementación concreta,
// mantenemos el código portable y testeable.
type Controller struct {
	sensor Sensor
	limite float64
}

// RunControlLoop simula el loop principal de un firmware.
// En un microcontrolador real, esto podría estar conectado a un timer de hardware.
func (c *Controller) RunControlLoop(iteraciones int) ([]float64, error) {
	resultados := make([]float64, 0, iteraciones)

	for i := 0; i < iteraciones; i++ {
		val, err := c.sensor.Read()
		if err != nil {
			return nil, err
		}

		resultados = append(resultados, val)

		if val > c.limite {
			// En firmware, aquí activaríamos un GPIO o una alarma.
			// Usamos un retorno para propósitos de la prueba.
		}

		// Simulación de delay de muestreo.
		time.Sleep(10 * time.Millisecond)
	}

	return resultados, nil
}

func TestControllerLogic(t *testing.T) {
	// Configuración del escenario de prueba.
	sensor := &MockSensor{valorSimulado: 25.5, errorSimulado: nil}
	ctrl := Controller{
		sensor: sensor,
		limite: 20.0,
	}

	// Ejecución de la lógica.
	lecturas, err := ctrl.RunControlLoop(5)

	if err != nil {
		t.Fatalf("Error inesperado en el loop: %v", err)
	}

	if len(lecturas) != 5 {
		t.Errorf("Se esperaban 5 lecturas, se obtuvieron %d", len(lecturas))
	}

	if lecturas[0] <= ctrl.limite {
		t.Errorf("La lectura %v no debería estar por debajo del límite", lecturas[0])
	}
}

Desglose del ejemplo

En el código anterior, hemos implementado un patrón de Abstracción de Capa de Hardware (HAL), esencial en el desarrollo de sistemas embebidos con Go.

1. La interfaz Sensor: Es la pieza clave. En TinyGo, no puedes simplemente importar un paquete que acceda directamente a registros de memoria si quieres que tu lógica sea testeable en tu PC. Al definir Sensor, permitimos que el Controller sea agnóstico al hardware.
2. MockSensor: Esta estructura implementa la interfaz Sensor. En un entorno de producción con TinyGo, tendrías una implementación real que utilice el paquete machine para leer pines GPIO o protocolos I2C/SPI. Aquí, la implementamos para que go test pueda ejecutarse en cualquier entorno.
3. Controller.RunControlLoop: Este método representa el ciclo de vida típico de un firmware (leer $\to$ procesar $\to$ actuar $\to$ esperar). Fíjate en el uso de make([]float64, 0, iteraciones). En sistemas embebidos, es vital pre-alocar la capacidad de los slices para evitar múltiples re-allocaciones en el heap, lo cual podría causar una fragmentación de memoria crítica en un dispositivo con poca RAM.
4. Gestión de errores: Aunque en un microcontrolador un error de lectura de sensor podría significar un “panic” o un reset, aquí seguimos el idiom de Go devolviendo error para asegurar que la lógica de negocio sea robusta y verificable.

El error frecuente

Un error común al migrar código de Go estándar a TinyGo es el uso intensivo del paquete fmt o la reflexión mediante reflect en bucles críticos.

// ERROR: Esto puede hacer que tu binario crezca de 10KB a 100KB de golpe.
for {
    val := sensor.Read()
    fmt.Printf("Valor actual: %f\n", val) // La reflexión de fmt es pesada
}

El paquete fmt utiliza mucha reflexión para parsear los verbos de formato (%f, %d, etc.). En un compilador basado en LLVM como TinyGo, esto obliga a incluir una cantidad ingente de código de soporte en el binario para inspeccionar tipos en tiempo de ejecución. Para sistemas embebidos, es preferible usar funciones de logging simples que escriban directamente en un buffer de UART o usar tipos estáticos para evitar el costo computacional y de espacio de la reflexión.

N° 243