Resumen de Bluetooth¶

Resumen¶

Esta guía explica cómo planificar e implementar la conectividad Bluetooth en productos SF32. Se centra en las decisiones prácticas de diseño: elegir entre BLE y Bluetooth de modo dual, diseñar servicios GATT, seleccionar perfiles, ajustar los parámetros de conexión, definir el emparejamiento y la seguridad, evaluar LE Audio y gestionar la coexistencia con gráficos, audio y sensores.

SF32 separa el procesamiento de la aplicación de las tareas del controlador Bluetooth con requisitos estrictos de temporización. El procesador de aplicación suele ejecutar la lógica del producto y la interfaz de usuario; un procesador Bluetooth o de bajo consumo gestiona la temporización de la capa de enlace y la planificación de radio. La ubicación de la pila host y de los servicios GATT depende del dispositivo y de la configuración del SDK. No presuponga que todos los servicios se ejecutan en el procesador de aplicación: compruebe los núcleos utilizados y la comunicación entre ellos en el ejemplo elegido.

Para una explicación más profunda del subsistema subyacente, consulte Procesador Bluetooth.

Consulte esta guía al definir el comportamiento inalámbrico del producto: qué roles y perfiles necesita, qué capacidad de respuesta y autonomía esperan los usuarios, y cómo deben repartirse las responsabilidades entre el teléfono, la radio y el firmware de aplicación. Es una guía de diseño, no sustituye las pruebas de interoperabilidad con los teléfonos y accesorios previstos.

Defina los requisitos de conectividad del producto¶

Antes de escribir cualquier código GATT, precise lo que el producto realmente necesita:

• ¿Solo BLE, o Bluetooth de modo dual (Bluetooth clásico + BLE)?
• ¿Audio Bluetooth: Bluetooth clásico (A2DP/AVRCP/HFP) o LE Audio?
• ¿Qué intervalo de conexión, latencia y caudal de datos necesita el producto?
• ¿Con qué frecuencia debe despertarse el procesador de aplicación y cuánto tiempo puede permanecer en reposo?
• ¿Debe interoperar con servicios existentes del teléfono (notificaciones, control multimedia y llamadas) o solo necesita una aplicación complementaria propia?
• ¿Qué alcance se espera? ¿Qué restricciones imponen la antena y la carcasa, y cuáles son los objetivos de certificación de RF?
• ¿Se distribuirán las actualizaciones de firmware por Bluetooth?

Estas respuestas orientan la elección del dispositivo, los ejemplos del SDK con los que empezar y cuánto tiempo puede mantenerse en reposo la CPU principal.

Elija BLE, Bluetooth clásico o modo dual¶

Bluetooth de baja energía (BLE)¶

BLE suele ser la opción inicial más adecuada para la mayoría de los dispositivos vestibles y sensores conectados: el tráfico es intermitente y se activa por eventos, el consumo medio es bajo y cuenta con amplia compatibilidad con los sistemas operativos de teléfonos. Entre los productos centrados en BLE se incluyen pulseras de actividad, sensores de salud, balizas y enlaces de configuración o control con una aplicación complementaria.

Bluetooth clásico y modo dual¶

Añada Bluetooth clásico si el producto necesita transmisión de audio (A2DP/AVRCP), llamadas manos libres (HFP), enlaces de datos serie (SPP) o compatibilidad con perfiles Bluetooth clásicos existentes. El modo dual exige más planificación de radio y pruebas de coexistencia que BLE por sí solo. Precisamente para aislar esa carga del resto del sistema se utiliza el procesador Bluetooth dedicado.

No todos los dispositivos de la familia SF32 admiten Bluetooth de modo dual. Antes de elegir una referencia concreta, consulte la tabla de dispositivos de Procesador Bluetooth.

Elija el dispositivo SF32 adecuado¶

Elija el dispositivo según el conjunto de funciones de conectividad que el producto necesita, no solo la velocidad de reloj.

Contraste con los requisitos de pantalla, memoria e IA de las páginas Resumen de Gráficos y Acelerador de IA si el producto necesita más que solo conectividad.

Servicios GATT y el marco Sibles¶

SiFli-SDK ofrece Sibles para registrar y utilizar servicios GATT. GATT define la jerarquía de servicios y características, así como el acceso a los atributos; GAP se ocupa de los anuncios BLE, el descubrimiento de dispositivos, el establecimiento de conexiones y los roles correspondientes. Son responsabilidades complementarias: GATT no es una capa construida sobre GAP. Parta del ejemplo del SDK más cercano en lugar de crear una base de datos GATT desde cero.

El SDK incluye ejemplos de implementación de varios perfiles estándar y específicos del proveedor, como:

Reutilice el registro, la gestión de eventos y las comprobaciones de seguridad del ejemplo más cercano. Si implementa un perfil estándar, conserve sus UUID y comportamiento; si el modelo de datos del producto lo requiere, diseñe un servicio y UUID propios. El objetivo es reutilizar código de soporte probado, no encajar a la fuerza todos los protocolos de la aplicación en un perfil estándar.

Perfiles de Bluetooth clásico¶

Para productos de modo dual, el SDK incluye ejemplos de implementación para estos perfiles:

• SPP: datos serie bidireccionales simples, útiles para aplicaciones complementarias heredadas o no basadas en GATT.
• A2DP (receptor y transmisor): transmisión de audio Bluetooth.
• AVRCP: control de reproducción (reproducir/pausar/pista/volumen) junto a un enlace A2DP.
• HFP: llamadas manos libres, con los roles HF (dispositivo manos libres) y AG (pasarela de audio). El ejemplo HFP documentado implementa HF; compruebe por separado el soporte de AG en la configuración del SDK elegida.
• PAN: red sobre Bluetooth, incluyendo un ejemplo de entrega de OTA basado en PAN.

Los perfiles de audio y los perfiles heredados suelen tener requisitos de temporización y de caudal de datos más estrictos que los enlaces BLE sencillos. Reserve tiempo suficiente para las pruebas de coexistencia (consulte Coexistencia).

Audio Bluetooth y LE Audio¶

Existen dos rutas distintas dependiendo del enfoque de audio:

• Audio Bluetooth clásico: A2DP para transmisión, AVRCP para control de reproducción y HFP para llamadas. Es una tecnología madura y ampliamente compatible con teléfonos y auriculares existentes.
• LE Audio: el perfil de audio básico (Basic Audio Profile, BAP) define los procedimientos para gestionar flujos LE Audio tanto unicast como de difusión. El SDK incluye ejemplos de fuente y receptor de difusión, además de un ejemplo que combina una fuente de difusión LE Audio con Bluetooth clásico para productos que necesitan admitir ambas tecnologías durante una transición.

Ambas rutas requieren temporización estable, gestión de búferes y transferencia fiable de muestras de audio, normalmente mediante DMA. Seleccione SF32LB52x/56x/58x cuando sus roles de audio Bluetooth admitidos y las configuraciones del SDK cumplan los requisitos del producto. SF32LB55x solo admite BLE y no ofrece audio Bluetooth clásico; esto no significa que carezca de funciones de audio local. Para DMA y búferes, consulte la descripción general del audio y Procesador Bluetooth.

Patrón de implementación para servicios Sibles¶

Un servicio BLE mantenible generalmente sigue este patrón:

Así se mantienen coherentes la definición del servicio, la interfaz con la aplicación móvil, la política de seguridad y el comportamiento energético.

Parámetros de anuncios BLE y conexión¶

Los parámetros de conexión y anuncios BLE son los principales ajustes para equilibrar la latencia, el caudal de datos y el consumo energético.

Estos parámetros describen enlaces BLE ACL, no todos los transportes de audio Bluetooth. El audio clásico utiliza la temporización de BR/EDR; LE Audio utiliza la temporización isócrona de CIS o BIS. No aplique directamente un intervalo de conexión GATT BLE a ninguna de esas rutas de audio. La introducción a LE de Bluetooth SIG explica la diferencia entre estos transportes.

Los productos tipo beacon (con anuncios compatibles con iBeacon) y los casos de anuncios periódicos —incluida la sincronización para difusiones a gran escala o unidireccionales— se cubren con ejemplos específicos del SDK y no requieren una conexión GATT completa.

El intervalo de conexión, la latencia del periférico y el tiempo de supervisión deben formar una combinación válida aceptada por el controlador y el otro dispositivo. Solicitar una actualización no demuestra que se haya aplicado: registre los valores negociados y pruebe el teléfono o accesorio real, incluidos el rechazo de solicitudes y el regreso a los ajustes de reposo.

Preajustes de parámetros por fase del producto¶

Use diferentes parámetros de Bluetooth para diferentes fases en lugar de un único ajuste de compromiso:

Documente las transiciones entre fases. Muchos problemas de consumo o latencia Bluetooth que parecen «aleatorios» se deben a que el producto permanece en la fase equivocada después de un cambio de estado.

Emparejamiento, vinculación y seguridad¶

BLE puede establecer una conexión sin emparejamiento. El emparejamiento genera claves de seguridad; la vinculación las conserva para conexiones posteriores. Determine qué servicios requieren cifrado, autenticación y vínculos persistentes, en lugar de exigir vinculación para todos los productos:

• Decida desde el principio si necesita Just Works, introducción de un código de emparejamiento o comparación numérica. Just Works no protege frente a ataques de intermediario (MITM): una conexión cifrada no está necesariamente autenticada. Elija el método según las capacidades de E/S de ambos dispositivos y los requisitos de seguridad del producto; consulte los requisitos de seguridad de Bluetooth GAP.
• En ANCS, la autorización del usuario en el teléfono es independiente del cifrado del enlace y de la vinculación; gestione su denegación o revocación. Tanto ANCS como AMS pueden aparecer o desaparecer durante una conexión. Supervise Service Changed y vuelva a descubrir el servicio: el emparejamiento no garantiza su disponibilidad permanente.
• Almacene los datos de vinculación según el enfoque de almacenamiento/partición recomendado por el SDK para conservarlos tras reinicios y actualizaciones OTA.
• Defina un proceso para volver a emparejar y olvidar el dispositivo, tanto en la interfaz del producto como en el teléfono.
• Trate la política de seguridad (requisitos de cifrado, capacidad de E/S, tamaño de clave) como una decisión de producto, no como un valor predeterminado sin examinar.

Conexiones múltiples y roles¶

El SDK incluye ejemplos de operación simultánea como central y periférico y de varias conexiones concurrentes. Un producto puede conectarse al teléfono como periférico BLE y a un sensor como central, o mantener varias conexiones con dispositivos complementarios. Verifique la combinación de roles y el límite de conexiones para el dispositivo, firmware del controlador, configuración del SDK, búferes y carga de radio conjunta elegidos; un ejemplo no garantiza la misma capacidad en toda la familia.

Si el producto debe acercarse al límite de caudal de datos del enlace, use el ejemplo de caudal de datos del SDK como referencia antes de atribuir la limitación al código de la aplicación.

Actualizaciones de firmware OTA sobre Bluetooth¶

Existen dos rutas de entrega comunes:

• Actualizaciones tipo DFU sobre BLE, integradas en una conexión periférica (el ejemplo peripheral_with_ota muestra cómo integrar la OTA en el rol GATT habitual de un periférico).
• PAN OTA, entregando firmware a través de un enlace de red Bluetooth PAN para productos de modo dual que ya usan PAN para datos.

En ambos casos, planifique y pruebe las particiones, la recuperación ante fallos y la reversión antes de la liberación. Para OTA por BLE, evalúe un intervalo de conexión más corto y una latencia del periférico de cero durante la transferencia; después, restablezca los ajustes normales de ahorro energético. PAN OTA utiliza Bluetooth clásico: ajuste su caudal de datos y su recuperación por separado, sin aplicar los parámetros de conexión de BLE.

Coexistencia con otras cargas de trabajo¶

Bluetooth rara vez funciona de forma aislada en SF32: comparte recursos con gráficos, audio, sensores y, en algunos productos, Wi-Fi externo. El procesador Bluetooth dedicado absorbe gran parte de la carga de temporización del enlace, pero también hay que gestionar la coexistencia en la aplicación:

• Las secciones críticas largas o las interrupciones deshabilitadas en el procesador de aplicación pueden retrasar el manejo de Bluetooth del lado del host.
• El tráfico de pantalla y PSRAM compite por el ancho de banda de memoria con los búferes de audio Bluetooth.
• Si las interrupciones de los sensores despiertan con demasiada frecuencia el procesador de aplicación, se pierde el ahorro de mantenerlo en reposo mientras el procesador Bluetooth gestiona el enlace.

Consulte Coexistencia con otras cargas de trabajo para conocer la perspectiva del sistema y pruebe las combinaciones realistas más desfavorables —por ejemplo, pantalla y audio activos junto con un enlace BLE con mucho tráfico—, no cada subsistema por separado.

Preparación para RF, interoperabilidad y certificación¶

El firmware Bluetooth debe validarse con la misma disciplina que el hardware de RF:

• Pruebe con teléfonos de distintos fabricantes, varias versiones de SO y distintos escenarios de reconexión; no se limite a un único teléfono de desarrollo.
• Verifique el comportamiento cuando haya datos de vinculación obsoletos, al usar «Olvidar dispositivo» en el teléfono, después de restablecer el dispositivo de fábrica y tras una actualización OTA.
• Valide el alcance y la estabilidad de los paquetes con el producto dentro de su carcasa final, con la batería, la pantalla y el cargador instalados, y en las distintas posiciones en que el usuario lo llevará o sujetará.
• Mantenga disponibles los modos de prueba de RF, el acceso de calibración y los registros para soporte de producción y certificación.
• Para productos ricos en perfiles, reserve tiempo para pruebas de calificación/perfil; pasar una aplicación de demostración no es lo mismo que ser interoperable.

Depuración de problemas de Bluetooth¶

Errores comunes¶

• Elegir hardware solo BLE después de que el producto ya necesita audio Bluetooth clásico.
• Reimplementar innecesariamente el código de soporte de los servicios o forzar un modelo de datos propio en un perfil estándar inadecuado.
• Dejar en 0 la latencia del periférico en enlaces que pasan la mayor parte del tiempo inactivos.
• Ignorar las pruebas de coexistencia hasta la integración tardía, cuando pantalla/audio/Bluetooth se combinan por primera vez.
• Tratar el emparejamiento/vinculación como algo secundario en lugar de un flujo de UX diseñado.
• Omitir la validación de puesta en marcha de RF (antena, red de adaptación, precisión del cristal) hasta las revisiones finales de PCB.
• Asumir que el ajuste solo por firmware puede compensar un diseño de RF deficiente.

Lista de comprobación de puesta en marcha¶

• Confirme el requisito solo BLE frente a modo dual y seleccione el dispositivo SF32 correspondiente.
• Identifique los ejemplos de perfil/servicio de SDK más cercanos para el caso de uso del producto.
• Defina los objetivos de los parámetros de anuncios BLE y conexión para el descubrimiento, el uso activo y los estados inactivos.
• Diseñe la experiencia de emparejamiento, vinculación y olvido del dispositivo.
• Valide el diseño de RF, la adaptación de la antena y la precisión del cristal en hardware real.
• Pruebe los perfiles elegidos (servicios GATT, A2DP/AVRCP/HFP o difusión LE Audio) con un teléfono real o un host de referencia.
• Pruebe la coexistencia con cargas de pantalla, audio y sensores bajo una combinación de carga realista.
• Planifique y pruebe la ruta de entrega de OTA si las actualizaciones de firmware se distribuirán por Bluetooth.
• Mida el consumo en reposo con una conexión activa y confirme que el procesador de aplicación entra en reposo según lo previsto.

Conclusiones clave¶

• Decida primero si el producto necesita BLE o Bluetooth de modo dual: esta elección determina el dispositivo y gran parte del camino de desarrollo con el SDK.
• Parta de los ejemplos existentes del SDK (HRPC, DISS, CTS, HID, ANCS/AMS, SPP, A2DP, AVRCP, HFP y PAN), tanto de servicios GATT como de perfiles de Bluetooth clásico, en lugar de crear una implementación desde cero.
• El intervalo de conexión, la latencia del periférico, el tiempo de espera de supervisión y la potencia TX son los principales ajustes para equilibrar latencia, caudal de datos y consumo.
• Para audio Bluetooth, verifique el rol clásico o LE Audio requerido en el dispositivo y la configuración del SDK elegidos; después diseñe y pruebe los búferes y la coexistencia. Una afirmación sobre toda la familia no sustituye esta comprobación.
• Bluetooth es una cuestión de sistema: el diseño de RF, los relojes, la experiencia de emparejamiento y la coexistencia con gráficos, audio y sensores importan tanto como el propio código GATT.

Para un mapa orientado a tareas de los proyectos actuales del SDK para Bluetooth clásico, BLE y LE Audio, consulte Ejemplos de SDK de Bluetooth.

Para un método práctico de medir y analizar el consumo de Bluetooth de un dispositivo, consulte Medición y análisis del consumo energético de Bluetooth.

Última actualización: 2026-10-19