5 errores comunes en las GUI embebidas (y cómo evitarlos)

Publicado en Lopaka.app: el constructor de GUI de LVGL gratuito y basado en la web para desarrolladores embebidos

Introducción

Revisé cientos de proyectos de GUI embebidas, desde construcciones Arduino de aficionados hasta dispositivos IoT de producción. Y sigo viendo los mismos errores una y otra vez.

No son detalles menores. Son la diferencia entre una interfaz que se siente profesional y una que hace que los usuarios recurran al monitor serie en su lugar.

En esta publicación, recorreré los 5 errores más comunes en las GUI embebidas que veo, por qué ocurren y cómo evitarlos, a menudo en solo unos minutos.

Error n.º 1: Codificar las coordenadas de píxeles a mano

El problema

lv_obj_set_pos(label1, 47, 83);
lv_obj_set_pos(btn1, 112, 156);
lv_obj_set_pos(bar1, 23, 201);

Colocas cada elemento adivinando las coordenadas de píxeles, luego ajustas ±5 píxeles, vuelves a flashear, compruebas, repites. Es lento, frágil y se rompe en cuanto cambias el tamaño de la pantalla.

Por qué ocurre

La mayoría de los tutoriales de GUI de Arduino te muestran cómo crear widgets, pero no cómo organizarlos. Así que haces los cálculos tú mismo, y los cálculos son tediosos.

La solución

Usa un constructor visual de GUI como Lopaka que se encarga de la colocación por ti:

1. Arrastra widgets a un lienzo
2. Ve tu diseño en tiempo real
3. Exporta código con coordenadas limpias y coherentes
4. Cambia el tamaño de la pantalla sin rehacer todo

Si debes programar a mano, usa el posicionamiento relativo:

// Instead of hardcoded positions:
lv_obj_align(label, LV_ALIGN_CENTER, 0, -40);
lv_obj_align(btn, LV_ALIGN_CENTER, 0, 20);
lv_obj_align(bar, LV_ALIGN_BOTTOM_MID, 0, -20);

Error n.º 2: Sin jerarquía visual

El problema

Todo en la pantalla tiene el mismo tamaño, el mismo color, el mismo peso visual. El usuario no sabe dónde mirar primero.

┌─────────────────────────────┐
│ Temperature: 25.6C          │
│ Humidity: 65%               │
│ Pressure: 1013 hPa          │
│ Battery: 75%                │
│ Status: OK                  │
│ Time: 14:32                 │
│ Date: 2026-04-02            │
└─────────────────────────────┘

Esto es un volcado de datos, no una interfaz.

Por qué ocurre

Los desarrolladores embebidos piensan en estructuras de datos, no en diseño visual. Cada lectura de sensor recibe el mismo tratamiento porque cada variable es igual de importante en el código.

La solución

Establece una jerarquía clara:

1. Información principal: grande, destacada, en el centro de la pantalla (por ejemplo, la temperatura)
2. Información secundaria: tamaño mediano, contexto de apoyo (por ejemplo, la humedad)
3. Información terciaria: pequeña, periférica (por ejemplo, la marca de tiempo, la batería)

// Primary — big and bold
lv_obj_set_style_text_font(temp_label, &lv_font_montserrat_36, 0);

// Secondary — readable but smaller
lv_obj_set_style_text_font(humidity_label, &lv_font_montserrat_20, 0);

// Tertiary — subtle
lv_obj_set_style_text_font(time_label, &lv_font_montserrat_14, 0);
lv_obj_set_style_text_color(time_label, lv_color_hex(0x888888), 0);

Buena jerarquía:

┌─────────────────────────────┐
│                             │
│         25.6°C              │  ← Primary (large, center)
│                             │
│    Humidity: 65%            │  ← Secondary (medium)
│    Pressure: 1013 hPa       │
│                             │
│  🔋 75%        14:32        │  ← Tertiary (small, bottom)
└─────────────────────────────┘

Error n.º 3: Ignorar el tamaño de los objetivos táctiles

El problema

lv_obj_set_size(tiny_button, 40, 20);

Un botón de 40×20 píxeles en una pantalla táctil resistiva de 2,8" es una pesadilla para pulsarlo con precisión. Los usuarios fallarán, se frustrarán y dejarán de usar tu interfaz.

Por qué ocurre

Los desarrolladores diseñan para la pantalla, no para el dedo. En una pantalla de 320×240, 40 píxeles parece razonable, hasta que intentas tocarlo con la yema del dedo.

La solución

Objetivo táctil mínimo: 40×40 píxeles (idealmente más grande)

// Too small
lv_obj_set_size(btn, 40, 20);

// Good
lv_obj_set_size(btn, 80, 44);

// Better — with padding
lv_obj_set_size(btn, 100, 50);
lv_obj_set_style_pad_all(btn, 8, 0);

Reglas generales:

• Botones: altura mínima de 44px (recomendación HIG de Apple)
• Espaciado entre botones: al menos 8px
• Si no puedes encajar el texto cómodamente, el botón es demasiado pequeño
• Prueba con tu hardware real: las pantallas táctiles resistivas necesitan objetivos más grandes que las capacitivas

Error n.º 4: Sin retroalimentación para las acciones del usuario

El problema

El usuario pulsa un botón. Parece que no pasa nada. Lo pulsa de nuevo. Y otra vez. Ahora la acción se disparó tres veces.

Por qué ocurre

Los sistemas embebidos son lentos. La brecha entre el toque y la retroalimentación visual puede ser de 100-500ms, una eternidad en tiempo de interfaz. Sin retroalimentación inmediata, los usuarios asumen que el toque no se registró.

La solución

Ofrece retroalimentación visual instantánea:

// Button press state change
lv_obj_set_style_bg_color(btn, lv_color_hex(0x444444), LV_STATE_PRESSED);
lv_obj_set_style_transform_scale(btn, 240, LV_STATE_PRESSED);

// Loading indicator for slow operations
lv_obj_t *spinner = lv_spinner_create(lv_scr_act(), 1000, 60);
lv_obj_center(spinner);

// Toast notification for completed actions
lv_obj_t *toast = lv_label_create(lv_scr_act());
lv_label_set_text(toast, "Saved!");
lv_obj_align(toast, LV_ALIGN_BOTTOM_MID, 0, -10);
lv_obj_fade_out(toast, 500, 1500);

Lista de comprobación de retroalimentación:

• El botón cambia de aspecto al pulsarlo
• Indicador de carga para operaciones >200ms
• Mensaje de confirmación para acciones destructivas
• Estado de error visible y claro (borde rojo, ícono de error)
• Confirmación de éxito para las acciones completadas

Error n.º 5: No probar pronto en hardware real

El problema

Tu GUI se ve perfecta en el simulador. La flasheas en el hardware y descubres:

• Los colores se ven desvaídos en la pantalla real
• El texto es ilegible con el tamaño elegido
• La calibración táctil está desviada 10 píxeles
• La pantalla es más lenta de lo esperado, lo que causa un retraso visible al redibujar

Por qué ocurre

Los simuladores son cómodos. Probar en hardware requiere preparación. Así que los desarrolladores aplazan las pruebas en hardware hasta que la GUI está «terminada», y entonces descubren que todo está mal.

La solución

Prueba en hardware real desde el primer día:

1. Flashea una pantalla de prueba básica en tu primer día con la pantalla
2. Verifica de inmediato los colores, las fuentes y la calibración táctil
3. Itera en hardware, no solo en el simulador
4. Usa la vista previa en vivo de Lopaka para diseñar, y luego flashea de forma incremental

Lista rápida de comprobación del hardware:

• Controlador de pantalla inicializado correctamente
• Los colores coinciden con lo esperado (prueba con muestras de color)
• Los tamaños de fuente son legibles a una distancia de visión normal
• Calibración táctil precisa (prueba las esquinas y el centro)
• Frecuencia de actualización aceptable (sin parpadeo ni desgarro visible)
• Consumo de energía dentro del presupuesto (las pantallas consumen mucha energía)

Extra: el metaerror

No usar las herramientas que existen para resolver estos problemas.

No necesitas codificar a mano cada posición de píxel. No necesitas adivinar esquemas de colores. No necesitas calcular manualmente el tamaño de los objetivos táctiles.

Herramientas como Lopaka existen precisamente para eliminar estos errores:

• Diseño visual → No más coordenadas codificadas a mano
• Guías de estilo integradas → Jerarquía visual coherente
• Tamaño adaptado al tacto → Los botones son siempre cómodos para el dedo
• Vista previa en tiempo real → Ve los cambios al instante, prueba en hardware de forma incremental
• Exportación de código limpio → Código LVGL listo para producción, sin tiempo de ejecución de caja negra

Resumen

Error	Impacto	Solución
Coordenadas fijas	Diseños lentos y frágiles	Constructor visual o alineación relativa
Sin jerarquía visual	Interfaz confusa	Tamaño/color según la importancia
Objetivos táctiles pequeños	UX frustrante	Botones mínimos de 40×40px
Sin retroalimentación	Interacciones inciertas	Estados al pulsar, indicadores, avisos
Pruebas tardías en hardware	Retrabajo caro	Probar en hardware desde el primer día

Recursos

• Lopaka.app: crea GUI sin estos errores
• Sistema de estilos de LVGL: inmersión profunda en los estilos de LVGL
• Objetivos táctiles de Apple HIG: tamaño estándar del sector
• Discord de Lopaka: recibe ayuda de la comunidad

¿Qué errores de GUI cometiste? Comparte tus historias de guerra en los comentarios: todos pasamos por eso.