Qué placas comprar para una pasarela Matter: hardware y lista de verificación

La lista de compras de una pasarela crece enseguida: placa Linux, kit Bluetooth, depurador, adaptador serie, capturador de paquetes, fuentes, cables y placas de conexión. Todo parece útil.

Al empezar a conectar las piezas aparecen las sorpresas: falta un pin, el firmware corresponde a otro chip o una herramienta todavía no sirve para la prueba que queremos hacer. Tenemos material, pero no el conjunto necesario para verificar la comunicación.

Nuestro proyecto conecta dispositivos Bluetooth Mesh con Matter. El equipo Linux gestiona Matter y la correspondencia entre dispositivos; un módulo Silicon Labs ejecuta Bluetooth Mesh; las luces e interruptores utilizan soluciones Telink. El prototipo en PC ya se conecta a Apple Home y hemos compilado la imagen Linux. Quedan por comprobar la grabación en la placa, la interoperabilidad Mesh real y la estabilidad del conjunto.

Por eso planteo cada compra con una pregunta: ¿qué incertidumbre concreta nos permite resolver?

Dibujar primero la comunicación

Una operación desde Apple Home debe recorrer esta ruta:

Apple Home
    ↓ Matter por la red local
Equipo Linux: dispositivos, órdenes y estados
    ↓ UART / BGAPI
Módulo Silicon Labs: firmware Bluetooth Mesh NCP
    ↓ Bluetooth Mesh
Dispositivo Telink: luz o interruptor

Cuando se pulsa un botón físico, el nuevo estado debe volver y aparecer en Apple Home.

En este diseño, Matter utiliza Ethernet o Wi-Fi. La red de los dispositivos es Bluetooth Mesh. Bluetooth Mesh y Thread son protocolos diferentes, aunque ambos formen redes malladas.

Usar Matter aquí no obliga a comprar un kit Thread y un router de borde Thread. Tendrían sentido al desarrollar o incorporar dispositivos Matter sobre Thread. Los controladores, concentradores del hogar y versiones de software para Apple Home deben cumplir los requisitos actuales de Apple.

Tampoco basta con que la placa Linux incluya Bluetooth para sustituir nuestro NCP. Normalmente ese Bluetooth utiliza otra organización de controladores y software. Nuestra arquitectura ejecuta Mesh en un módulo separado y lo controla mediante BGAPI; cambiarla requiere evaluar también la pila y su interfaz.

La primera compra: verificar Bluetooth

Con el prototipo de PC y teléfono adelantamos la parte Matter. Ahora interesa comprobar si el módulo Silicon Labs controla los dispositivos Telink como necesitamos.

Podemos seguir utilizando el PC como anfitrión. Conectaremos el kit mediante su interfaz serie compatible o un adaptador USB-UART adecuado. Primero deben funcionar el aprovisionamiento, el control y los informes de estado; después cambiaremos a la placa Linux. Así habrá menos causas posibles para cada fallo.

Material	Qué comprobar	Qué permite verificar
Kit Silicon Labs	Chip y referencia exactos, ejemplo Mesh NCP, interfaces de programación y serie	Compatibilidad entre hardware, SDK y firmware
Placa Telink o muestra de luz controlable	Firmware reprogramable, modelos Mesh conocidos y procedimiento de reinicio de fábrica	Aprovisionamiento, control e interoperabilidad
Programador y depurador	Si están incluidos y admiten la placa	Programación, recuperación y diagnóstico
Cable USB de datos, fuente y conexiones	Datos, alimentación, conectores y niveles eléctricos	Descartar fallos de cableado y alimentación
USB-UART, si hace falta	Control de flujo y niveles lógicos	Comunicación entre anfitrión y NCP

Una placa con un modelo estándar de encendido y apagado basta para empezar. Observar un LED resulta más sencillo que conectar inmediatamente una lámpara a la red eléctrica.

Después añadiremos otro nodo, regulación y varios canales para probar grupos, elementos y modelos. Un único nodo operativo demuestra el procedimiento mínimo, no la capacidad de la red ni su fiabilidad prolongada.

Relacionar la placa Silicon Labs con el firmware

Buscar «placa xG24» devuelve productos con interfaces, chips y accesorios distintos. «Módulo BG24» tampoco identifica suficientemente lo que hay que comprar.

Nuestro diseño prevé un módulo de la familia BGM240. Antes del pedido hay que relacionar módulo objetivo, chip de evaluación, versión del SDK y proyecto de ejemplo. Compartir «24» en el nombre no implica que admitan el mismo binario.

Confirmaría estos puntos:

1. ¿El SDK Bluetooth Mesh elegido permite crear el proyecto NCP necesario para esta placa exacta?
2. ¿Hay ejemplos o configuración documentada para el aprovisionador y los modelos cliente necesarios?
3. ¿El chip tiene la Flash, RAM y configuración de componentes que requiere el proyecto?
4. ¿El kit incluye depurador o placa principal? Si compramos solo la placa de radio, ¿qué falta?
5. ¿Dónde están UART, control de flujo, reset y depuración? ¿Son accesibles para un anfitrión externo?

Poder ejecutar un ejemplo Bluetooth acredita ese ejemplo. Nosotros necesitamos Bluetooth Mesh NCP: pediría al proveedor la correspondencia explícita entre placa y proyecto.

La aplicación NCP y el bootloader son componentes distintos. Grabar con un depurador comprueba ese mecanismo de programación. Si más adelante Linux actualizará el módulo por UART, también habrá que verificar bootloader, pines, entrada al modo de actualización y combinación compatible de firmware.

Un kit completo puede costar más que una placa suelta, pero tener depuración, acceso serie y documentación incluidos suele ahorrar trabajo.

USB-UART: comprobar la placa completa

Algunos adaptadores con FT232 o CP2102 solo exponen TX, RX, tierra y alimentación. Que el chip admita más señales no ayuda si la placa no permite conectarlas.

Para este diseño elegiría uno con TX, RX, RTS, CTS y GND, comprobando además el controlador y la velocidad necesaria. Importan el pinout y el esquema de la placa completa.

RTS/CTS coordina el flujo entre ambos extremos. Hay que cablearlo según la dirección de las señales y los manuales. Configuración del NCP, ajustes del anfitrión y conexiones físicas deben coincidir. Si un extremo espera señales que no están conectadas, la comunicación puede no arrancar.

El control de flujo reduce las pérdidas por saturación del receptor; no aporta comprobación de errores ni retransmisión. Interferencias, conexiones incorrectas y errores del analizador de protocolo requieren diagnóstico propio. Su activación depende de la configuración de ambos extremos; nuestro hardware reservará esas conexiones.

También hay que comprobar tensiones. Una UART puede trabajar a 1,8 V o a 3,3 V. En algunos adaptadores, el selector «3,3 V / 5 V» cambia únicamente la salida de alimentación, no los niveles TX/RX.

Antes de comprar deben quedar claros el nivel de señal, los pines de flujo disponibles y las velocidades soportadas. UART TTL y RS-232 no son directamente intercambiables. Si la placa ya tiene alimentación independiente, la conexión del pin de alimentación del adaptador depende de su diseño eléctrico.

La placa Linux: SDK, interfaces y recuperación

Ya comparamos procesadores en RK3506, RK3562, RK3576 y RDK X5. Al comprar, conviene centrarse en las condiciones reales de desarrollo.

Plataforma	Objetivo	Confirmación previa
RK3562	Validar la plataforma estándar prevista	BSP, multiplexado UART, flujo, Wi-Fi y suministro del módulo
RK3506	Evaluar una configuración más ajustada una vez funcionando	Herramientas de 32 bits, memoria medida, almacenamiento y seguridad
RDK X5	Continuar el trabajo de SDK e imagen del sistema	Revisión de placa, imagen compatible, grabación e interfaces
Equipo Linux disponible	Desarrollar el programa anfitrión y el protocolo serie	Compatibilidad del programa y conexión serie o USB adecuada

No hace falta comprar todas. RK3562 sigue siendo la plataforma estándar prevista; el trabajo de imagen comenzó con el SDK X5. El material disponible puede resolver parte de las preguntas antes de cerrar el producto.

Pediría cuatro cosas al proveedor.

Un SDK que podamos reconstruir: descarga, versión, entorno, herramientas y configuración de placa. Una imagen preinstalada no basta para recortar el sistema o cambiar controladores.

Una UART realmente utilizable: muchos puertos en la ficha del procesador no garantizan un conector con TX/RX/RTS/CTS. Hay que comprobar funciones compartidas y árbol de dispositivos. Conviene separar la consola de depuración para no introducir registros de arranque en el flujo del NCP.

Una vía de recuperación: interfaz de grabación, modo de recuperación, consola y documentación de particiones. Cuando una imagen propia no arranca, esto importa más que una CPU más rápida.

Red y almacenamiento adecuados: IPv6, descubrimiento local, controladores Wi-Fi y persistencia de configuración y dispositivos. VLAN, aislamiento de clientes, routers y cortafuegos pueden afectar al descubrimiento; esto es distinto de contratar IPv6 público.

En el trabajo anterior con Buildroot encontramos IPv6 desactivado por defecto. Que una placa arranque y tenga internet no demuestra que ya funcione como pasarela Matter.

Las herramientas de captura pueden esperar

La planificación original mencionaba un nRF52840 Dongle. No lo pondría como obligatorio en la primera compra.

nRF Sniffer for Bluetooth LE ayuda a observar tráfico radio, pero hardware, firmware y métodos admitidos dependen de la versión. Para analizar Mesh también cuentan el portador, el cifrado, las claves y el software de decodificación.

Un dongle Bluetooth no permite entender automáticamente todo el tráfico Mesh. Lo compraría cuando el problema requiera observación radio y la herramienta admita el tráfico concreto. Tampoco se convierte automáticamente en capturador Thread ni en el NCP de la pasarela.

Un analizador lógico sirve para observar UART: actividad, cambios de flujo y bytes alrededor de un fallo. Sus niveles de entrada, canales y muestreo deben cubrir las señales reales.

Primero registraremos datos serie, respuestas, eventos Mesh y marcas de tiempo. Si dejan una duda concreta sobre señales eléctricas o radio, añadiremos la herramienta apropiada.

Una verificación por capa

Etapa	Trabajo	Resultado que buscamos
Kit	Grabar firmware compatible y conectar serie, reset y depuración	Comunicación estable y eventos de arranque o versión esperados
Mesh mínimo	Aprovisionar y configurar con ejemplo o herramienta compatible	Control del dispositivo y respuesta de estado
Estado bidireccional	Accionar el botón físico	El anfitrión recibe el cambio
Programa propio	Implementar órdenes, respuestas y eventos	Añadir, controlar, consultar y eliminar el mismo dispositivo
Puente Matter	Crear los endpoints correspondientes	Apple Home controla y recibe los cambios del dispositivo
Linux	Migrar a la placa, configurar arranque, red y serie	Inicio correcto y recuperación de identidad y datos persistentes
Recuperación	Reiniciar por separado equipo, módulo y dispositivo; cortar red y alimentación	Estado explicable durante el fallo y recuperación del control

Enviar una orden no equivale a completar la operación física. Una escritura serie correcta solo entrega bytes al subsistema serie. La respuesta del NCP debe interpretarse según la operación que confirma. El estado real se comprueba con el Mesh Status correspondiente, la acción física y lo mostrado por Matter.

Si Apple Home indica que la luz está encendida y la lámpara sigue apagada, la prueba no ha pasado. Cuando hay actualización optimista, también debemos desconectar el dispositivo y provocar tiempos de espera: la interfaz no debería mantener indefinidamente un estado incorrecto.

Recuperar un reinicio del equipo no demuestra que podamos sustituir el módulo. Conservar la lista de dispositivos tampoco acredita la gestión correcta de claves, números de secuencia y estado de red. Son pruebas específicas de fiabilidad.

Cómo dividiría los pedidos

Primero compraría el kit Silicon Labs compatible y una placa Telink controlable, completando alimentación, cables y programación. Con el PC validaría aprovisionamiento, modelos e informes de estado.

Después incorporaría la placa Linux y migraría el programa ya operativo. Confirmaría SDK, UART completa y recuperación, preferiblemente con un proveedor que también pueda mantener el futuro módulo de producción.

Luego aumentaría tipos y número de dispositivos: varios canales, regulación, desconexiones y recuperación. Los instrumentos especializados llegarían según los problemas encontrados.

Este texto sirve para consultar a un proveedor:

Desarrollamos una pasarela con anfitrión Linux y Bluetooth Mesh NCP. Necesitamos modelo exacto y revisión de placa, SDK y proyecto compatibles, accesorios de programación y depuración, y pinout y niveles de UART, RTS/CTS, reset y depuración. Para Linux, necesitamos además la configuración UART del árbol de dispositivos, instrucciones de reconstrucción y recuperación por grabación.

Una placa resulta interesante cuando esas respuestas son claras. Resolver compatibilidad de firmware, interoperabilidad, estados y recuperación permite optimizar costes y diseñar la placa propia con mejores fundamentos.

Si trabajas con NCP de Silicon Labs, interoperabilidad Telink o UART en Linux, podemos hablar.

Referencias: API Bluetooth Mesh de Silicon Labs, RDK, Luckfox Lyra RK3506, nRF Sniffer for Bluetooth LE.