Selección de Pila de Protocolos para Módulo Bluetooth: Comparación de Enfoques HCI, Comandos AT e Integración SoC

Al integrar un módulo Bluetooth en un diseño, una de las primeras decisiones fundamentales es elegir entre tres patrones arquitectónicos: Interfaz de Controlador de Host (HCI), comandos AT o integración SoC. Esta decisión no es simplemente una preferencia técnica; afecta directamente la velocidad de desarrollo, la flexibilidad funcional, los costos de certificación y la escalabilidad en producción. Este artículo compara los tres enfoques con parámetros reales y aclara los escenarios donde cada uno resulta ventajoso.

Descripción General de los Tres Patrones Arquitectónicos

Arquitectura HCI: El procesador host envía comandos HCI al controlador, que devuelve eventos y datos ACL. El host ejecuta el BLE Host Stack (GAP/GATT/SMP/L2CAP) mientras el controlador maneja el Link Layer y las capas inferiores. Ejemplos representativos: firmware USB HCI de Nordic nRF52840, Cypress CYW43012.

Arquitectura de Comandos AT: El módulo ejecuta internamente el stack completo; el host solo envía cadenas de comandos ASCII vía UART. No se requiere conocimiento BLE en el lado del host. Ejemplos: HC-42, HM-10, Microchip RN4870. Ancho de banda de conexión: 115200 baud = máximo 11.5 KB/s de rendimiento efectivo.

Integración SoC: El código de aplicación y el stack BLE corren en el mismo chip, sin necesidad de MCU host externo. Ejemplos: nRF52833 (512KB Flash/128KB RAM), ESP32-C3, Silicon Labs EFR32BG22.

Comparación de Principales Pilas de Protocolos

Pila	Licencia	Chips Compatibles	Flash/RAM Mínimo	Características
Zephyr BLE	Apache 2.0 (gratuita)	Nordic, ST, NXP y otros	~256KB/~64KB	Multiprotocolo, comunidad activa
NimBLE	Apache 2.0 (gratuita)	ESP32, Nordic, otros	~100KB/~32KB	Ligero, nativo de ESP-IDF
SoftDevice	Propietario Nordic (uso gratuito)	Solo serie nRF52	~148KB/~8KB	Certificado, soporte oficial Nordic
BGAPI	Propietario Silicon Labs	Serie EFR32BG	~200KB/~32KB	Compatible con AT, admite modos NCP/SoC

Análisis Detallado de la Arquitectura HCI

HCI ofrece la máxima flexibilidad, pero también el mayor costo de implementación en el host. Para UART HCI se usa el encuadrado H4 (indicador de tipo de paquete de 1 byte), con tasa de baudios máxima generalmente de 1 Mbps. USB HCI utiliza endpoints isócronos para soportar Bluetooth 5.2 LE Audio.

Ejemplo de selección de stack de host: en sistemas Linux se puede usar BlueZ estándar. En entornos RTOS embebidos, se elige el driver HCI de Zephyr o el host HCI de NimBLE. La muestra hci_uart de Zephyr genera ~180KB de firmware de controlador, con ~256KB adicionales requeridos en el lado del host.

Detalles de Implementación de Comandos AT

Los módulos de comandos AT maximizan la velocidad de desarrollo, pero tienen restricciones en rendimiento y latencia. Secuencia de comandos representativa:

AT+RESET               // Reiniciar módulo
AT+ROLE=1             // Configurar modo periférico
AT+NAME=MyDevice      // Establecer nombre del dispositivo
AT+UUID=FFE0          // Configurar UUID del servicio
AT+CHAR=FFE1          // Configurar UUID de característica
AT+NOTI=1             // Habilitar notificaciones
AT+ADVEN=1            // Iniciar publicidad

Características de latencia: tiempo de procesamiento de comandos AT = análisis de comandos (~1ms) + procesamiento del stack (~5-50ms) + tiempo de eco UART. La latencia de eventos de conexión es típicamente de 50-200ms, mayor que la manipulación directa HCI (~10-30ms). No recomendado para aplicaciones que requieren transferencia masiva de datos.

Estrategia de Implementación de Arquitectura SoC Integrado

La integración SoC es el enfoque más elegante, minimizando el conteo de componentes BOM y optimizando el consumo energético. Sin embargo, requiere que el equipo de desarrollo tenga conocimiento profundo del stack BLE.

Tomando nRF52833 como ejemplo, el consumo de recursos de SoftDevice S140 (v7.3.0): Flash 148KB (0x00000-0x26000), RAM 8KB (proporcionada por SD mediante símbolos RAM_START/RAM_SIZE), Flash disponible para aplicación ~364KB. SoftDevice S113 (orientado a ahorro energético) requiere Flash 112KB, RAM 6KB (solo periférico).

Diseño de Interfaz: Elección entre UART y SPI

Parámetro	UART	SPI
Velocidad máxima	Hasta 4Mbps (requiere control de flujo)	Hasta 8Mbps (dependiente del módulo)
Número de pines	2 (TX/RX) + 2 (CTS/RTS)	4 (MOSI/MISO/CLK/CS) + interrupción
Carga de CPU	Baja con DMA	Baja con DMA
Sincronización	Asíncrona	Síncrona (reloj maestro)
Aplicación	Prioridad en costo, velocidad media	Alto rendimiento, entorno ruidoso

Análisis de Costos de Certificación RF

Escenario de Certificación	Costo Estimado	Duración
Adopción de módulo certificado (comandos AT)	$2,000-8,000 (solo producto final)	4-8 semanas
HCI + módulo controlador certificado	$5,000-15,000	6-12 semanas
Diseño SoC personalizado (certificación completa)	$15,000-60,000	16-32 semanas

Adecuación Arquitectónica por Escala de Producción

Escala de Producción	Arquitectura Recomendada	Justificación
<1,000 unidades/año	Módulo con comandos AT	Prioridad en velocidad de desarrollo, BOM alto aceptable
1,000-50,000 unidades/año	HCI + módulo certificado	Balance entre flexibilidad y costo
50,000-200,000 unidades/año	SoC + stack comercial (SoftDevice)	Reducción de BOM recupera inversión
>200,000 unidades/año	SoC + stack de código abierto (Zephyr)	Sin royalties, control total

Ejemplo de cálculo del punto de equilibrio: módulo con comandos AT (HM-10, $3.50/unidad) vs diseño SoC personalizado (nRF52810, $1.80/unidad, costo de desarrollo $80,000). Punto de equilibrio = $80,000 ÷ ($3.50 – $1.80) ≈ 47,000 unidades. El diseño SoC se vuelve ventajoso por encima de las 50,000 unidades de producción.

Conclusión

La selección de la pila de protocolos para módulos Bluetooth es una compensación de diseño sin una única respuesta «óptima». Los comandos AT logran la llegada al mercado más rápida, HCI proporciona máxima flexibilidad con sistemas host existentes, y la integración SoC ofrece la solución óptima en costo de producción masiva y consumo energético. Lo crucial es evaluar honestamente el volumen objetivo de producción del proyecto, los recursos de desarrollo disponibles y el presupuesto de certificación, eligiendo la arquitectura que mejor se ajuste a esas restricciones. Cambiar de arquitectura a mitad del proyecto genera reescrituras importantes de firmware y recertificaciones, por lo que la elección inicial es especialmente crítica. Para más información técnica sobre módulos Bluetooth, contacte con nuestro equipo de ingeniería.