Обзор Bluetooth¶

Обзор¶

В этом руководстве описано, как планировать и реализовывать Bluetooth-подключение устройств SF32. Основное внимание уделено практическим решениям, влияющим на конструкцию изделия: выбору между BLE и двухрежимным Bluetooth, проектированию сервисов GATT, выбору профилей, настройке параметров соединения, сопряжению и безопасности, LE Audio, а также совместной работе Bluetooth с графикой, аудио и датчиками.

SF32 разделяет прикладную обработку и задачи Bluetooth-контроллера со строгими временными требованиями. Прикладной процессор обычно выполняет логику изделия и пользовательский интерфейс, а Bluetooth-процессор или процессор низкого энергопотребления отвечает за временные параметры канального уровня и планирование работы радиотракта. Размещение стека хоста и сервисов GATT зависит от устройства и конфигурации SDK. Не считайте, что все сервисы работают на прикладном процессоре: проверьте конфигурацию ядер и межъядерный обмен в выбранном примере.

Подробное описание подсистемы см. в статье Bluetooth-процессор.

Обращайтесь к этой странице при проектировании беспроводного взаимодействия изделия: определите необходимые роли и профили, ожидаемые пользователями скорость отклика и время автономной работы, а также распределение обязанностей между телефоном, радиотрактом и прикладной прошивкой. Это руководство по проектированию, а не замена проверке совместимости с целевыми телефонами и аксессуарами.

Определите требования изделия к подключению¶

До написания кода GATT определите реальные потребности изделия:

• Достаточно BLE или нужен двухрежимный Bluetooth (классический Bluetooth + BLE)?
• Требуется ли Bluetooth-аудио: классическое (A2DP/AVRCP/HFP) или LE Audio?
• Каковы типичные требования к интервалу соединения, задержке и пропускной способности?
• Как часто должен пробуждаться прикладной процессор и как долго он может оставаться в режиме сна?
• Нужно ли изделию взаимодействовать с существующими сервисами на телефоне (уведомления, управление воспроизведением, вызовы) или достаточно собственного сопутствующего приложения?
• Какова требуемая дальность? Какие ограничения накладывают антенна и корпус и какие цели заданы для RF-сертификации?
• Будут ли обновления прошивки передаваться по Bluetooth?

Ответы помогают выбрать устройство, определить примеры SDK, с которых стоит начать, и понять, как долго главный процессор может оставаться в режиме сна.

Выберите BLE, классический Bluetooth или двухрежимный Bluetooth¶

Bluetooth Low Energy (BLE)¶

Для большинства подключённых носимых устройств и датчиков BLE — оптимальный вариант по умолчанию: обмен данными происходит периодически и по событиям, среднее энергопотребление невелико, а поддержка широко распространена в ОС телефонов. Типичные BLE-устройства — фитнес-браслеты, датчики здоровья, маяки и каналы настройки или управления через сопутствующее приложение.

Классический и двухрежимный Bluetooth¶

Классический Bluetooth нужен, если изделие должно передавать потоковое аудио (A2DP/AVRCP), поддерживать громкую связь (HFP), последовательный канал данных (SPP) или работать с существующими классическими профилями. В двухрежимном Bluetooth требования к планированию радиосвязи и совместной работе выше, чем в системе только с BLE. Выделенный Bluetooth-процессор как раз позволяет изолировать эту нагрузку от остальной системы.

Двухрежимный Bluetooth поддерживается не во всех устройствах семейства SF32. Прежде чем фиксировать номер компонента, проверьте таблицу устройств в статье Bluetooth-процессор.

Выберите подходящее устройство SF32¶

Выбирайте устройство по необходимым функциям связи, а не только по тактовой частоте.

Если изделию также нужны дисплей, память или ИИ, сверьте требования со страницами Обзор графики и ИИ-ускоритель.

Сервисы GATT и платформа Sibles¶

SiFli-SDK предоставляет Sibles для регистрации и использования сервисов GATT. GATT определяет иерархию сервисов и характеристик, а также доступ к атрибутам; GAP отвечает за обнаружение устройств, передачу рекламных пакетов, установление соединения и соответствующие роли. Эти функции дополняют друг друга: GATT не является уровнем поверх GAP. Начните с наиболее подходящего примера SDK, а не создавайте базу GATT с нуля.

В SDK есть примеры реализации нескольких стандартных и специфичных для производителя профилей:

Повторно используйте регистрацию, обработку событий и проверки безопасности из наиболее подходящего примера. Для стандартного профиля сохраняйте его UUID и предписанное поведение; если модель данных изделия требует своего сервиса, используйте собственные UUID. Цель — использовать проверенную инфраструктуру, а не подгонять каждый протокол приложения под стандартный профиль.

Профили классического Bluetooth¶

Для изделий с двухрежимным Bluetooth в SDK предусмотрены примеры следующих профилей:

• SPP — простой двусторонний последовательный обмен, полезный для устаревших сопутствующих приложений и приложений без GATT.
• A2DP (приёмник и источник) — передача потокового аудио по Bluetooth.
• AVRCP — управление воспроизведением (пуск/пауза/дорожка/громкость) вместе с соединением A2DP.
• HFP — громкая связь с ролями HF (устройство громкой связи) и AG (аудиошлюз). Документированный пример HFP реализует HF; поддержку AG отдельно проверьте в выбранной конфигурации SDK.
• PAN — передача сетевого трафика по Bluetooth, в том числе пример OTA-обновления через PAN.

Аудио и классические профили, как правило, предъявляют более жёсткие требования к временным параметрам и пропускной способности, чем обычное BLE-соединение. Заложите время на проверку совместной работы (см. раздел Совместная работа с другими нагрузками).

Bluetooth-аудио и LE Audio¶

Выбор зависит от способа передачи аудио:

• Классическое Bluetooth-аудио — A2DP для потоковой передачи, AVRCP для управления воспроизведением, HFP для вызовов. Это зрелый вариант с широкой совместимостью с существующими телефонами и гарнитурами.
• LE Audio — использует базовый аудиопрофиль (Basic Audio Profile, BAP), определяющий процедуры работы с потоками LE Audio в режимах unicast и broadcast. В SDK есть примеры источника и приёмника широковещательной передачи, а также пример, сочетающий источник LE Audio broadcast с классическим Bluetooth для изделий, которым в переходный период нужно поддерживать обе технологии.

Оба варианта требуют стабильных временных параметров, буферизации и надёжной передачи аудиоданных, обычно через DMA. Выбирайте SF32LB52x/56x/58x с учётом нужных ролей Bluetooth-аудио и поддерживаемых конфигураций SDK. SF32LB55x поддерживает только BLE и не обеспечивает классическое Bluetooth-аудио; это не означает отсутствия локальных аудиофункций. О DMA и буферах см. Обзор аудио и Bluetooth-процессор.

Порядок реализации сервисов Sibles¶

Чтобы BLE-сервис было проще сопровождать, используйте следующую схему реализации:

Такой порядок помогает согласовать определение сервиса, интерфейс взаимодействия с приложением телефона, политику безопасности и энергопотребление.

Параметры передачи рекламных пакетов BLE и соединения¶

Параметры передачи рекламных пакетов BLE и соединения позволяют выбирать компромисс между задержкой, пропускной способностью и энергопотреблением.

Эти параметры относятся к соединениям BLE ACL, а не ко всем способам передачи Bluetooth-аудио. Классическое аудио использует временные параметры транспорта BR/EDR; LE Audio — изохронные временные параметры CIS или BIS. Не применяйте интервал соединения GATT BLE непосредственно к этим аудиоканалам. Различия описаны во вводном материале Bluetooth SIG по LE.

Для маяков с рекламными пакетами BLE, совместимыми с iBeacon, и сценариев периодической передачи рекламных пакетов в SDK есть отдельные примеры. Они также охватывают синхронизацию с такой передачей при масштабном или однонаправленном вещании. Полное соединение GATT для этих сценариев не требуется.

Интервал соединения, периферийная задержка и тайм-аут контроля соединения должны образовывать допустимую комбинацию, принятую контроллером и удалённым устройством. Запрос обновления не означает, что параметры изменились. Записывайте согласованные значения и проверяйте целевой телефон или аксессуар, включая отклонённые запросы и возврат к настройкам простоя.

Наборы параметров для разных этапов работы изделия¶

Настраивайте Bluetooth-параметры отдельно для каждого этапа работы, а не ищите одну компромиссную конфигурацию:

Документируйте переходы между этапами. Многие «случайные» проблемы с энергопотреблением или задержкой Bluetooth на деле возникают потому, что после смены состояния изделие остаётся в неправильном режиме.

Сопряжение, bonding и безопасность¶

BLE может установить соединение без сопряжения. Сопряжение создаёт ключи безопасности, а bonding (сохранение ключей) позволяет использовать их при последующих соединениях. Определите, каким сервисам нужны шифрование, аутентификация и постоянное хранение ключей, вместо обязательного bonding для всех изделий:

• Заранее выберите Just Works, ввод кода сопряжения (Passkey Entry) или числовое сравнение. Just Works не защищает от атак посредника (MITM): шифрование соединения не означает, что оно аутентифицировано. Учитывайте возможности ввода-вывода обоих устройств и требования безопасности изделия; см. требования безопасности Bluetooth GAP.
• Для ANCS разрешение на телефоне — отдельное условие, не равнозначное шифрованию соединения или сохранению ключей сопряжения. Обрабатывайте отказ и отзыв разрешения. ANCS и AMS могут появляться и исчезать во время соединения. Отслеживайте Service Changed и повторно обнаруживайте сервис: сопряжение не гарантирует его постоянную доступность.
• Храните данные bonding согласно рекомендованной в SDK организации хранения и разделов, чтобы сопряжение сохранялось после перезапуска и OTA-обновления.
• Предусмотрите повторное сопряжение и сценарий «забыть устройство» как в интерфейсе изделия, так и на стороне телефона.
• Политику безопасности (требования к шифрованию, возможностям ввода-вывода и длине ключа) нужно определить для изделия, а не оставлять без проверки по умолчанию.

Несколько соединений и роли¶

В SDK есть примеры одновременной работы в центральной и периферийной ролях и нескольких одновременных соединений. Изделие может подключаться к телефону как BLE-периферия и к датчику как центральное устройство либо поддерживать несколько соединений с сопутствующими устройствами. Допустимые сочетания ролей и предел числа соединений проверяйте для устройства, прошивки контроллера, конфигурации SDK, буферов и общей нагрузки радиотракта. Пример не гарантирует одинаковое число доступных соединений для всего семейства.

Если изделию нужна пропускная способность, близкая к пределу соединения, сначала используйте пример SDK по пропускной способности в качестве базового ориентира, прежде чем искать ограничение в коде приложения.

Обновление прошивки OTA по Bluetooth¶

Обычно используют один из двух способов доставки обновлений:

• Обновление по BLE в стиле DFU в рамках соединения с периферийным устройством. В примере peripheral_with_ota показано, как подключить обработчики OTA к обычной роли BLE-периферии с GATT.
• PAN OTA — передача прошивки по сетевому соединению Bluetooth PAN для изделий с двухрежимным Bluetooth, уже использующих PAN для передачи данных.

Для обоих способов до выпуска прошивки спланируйте и проверьте разметку разделов, восстановление после сбоев и откат. При OTA по BLE оцените уменьшение интервала соединения и нулевую периферийную задержку на время передачи, затем восстановите обычные энергосберегающие настройки. PAN OTA использует транспорт классического Bluetooth: пропускную способность и восстановление нужно настраивать отдельно, а не применять параметры соединения BLE.

Совместная работа с другими нагрузками¶

Bluetooth в SF32 редко работает изолированно: система одновременно выполняет задачи графики, аудио и датчиков, а иногда и внешнего Wi-Fi. Выделенный Bluetooth-процессор снимает большую часть рисков, связанных с временными параметрами канала, однако совместную работу на уровне приложения всё равно нужно учитывать:

• Длительные критические секции или отключённые прерывания на прикладном процессоре могут задерживать обработку Bluetooth на стороне хоста.
• Трафик дисплея и PSRAM конкурирует с аудиобуферами Bluetooth за пропускную способность памяти.
• Слишком частые пробуждения прикладного процессора прерываниями от датчиков могут свести на нет экономию энергии, которую даёт его сон, пока Bluetooth-процессор обслуживает соединение.

Общий взгляд на систему приведён в разделе Совместная работа с другими нагрузками. Проверяйте реалистичные сочетания максимальных нагрузок — например, активный дисплей, аудио и интенсивный BLE-обмен, — а не каждую подсистему по отдельности.

RF, совместимость и подготовка к сертификации¶

Проверяйте Bluetooth-прошивку с той же тщательностью, что и RF-часть аппаратуры:

• Проверяйте работу с телефонами разных производителей и версиями ОС, а также сценарии повторного подключения; одного телефона для разработки недостаточно.
• Проверяйте поведение при устаревших данных bonding, после удаления устройства на телефоне, сброса изделия к заводским настройкам и OTA-обновления.
• Проверяйте дальность и стабильность пакетов в окончательном корпусе, с аккумулятором, дисплеем и зарядным устройством, в реальных положениях ношения или удержания.
• Сохраните доступ к RF-тестовым режимам, калибровке и журналам для производства и сертификационной поддержки.
• Для изделий с большим числом профилей предусмотрите время на квалификационные испытания и проверку профилей. Успешная демонстрация приложения ещё не доказывает совместимость.

Диагностика проблем Bluetooth¶

Типичные ошибки¶

• Выбор устройства только с BLE, хотя изделию уже требуется классическое Bluetooth-аудио.
• Лишняя повторная реализация инфраструктуры сервисов или подгонка собственной модели данных под неподходящий стандартный профиль.
• Периферийная задержка, оставленная равной 0 для соединений, которые почти всё время простаивают.
• Игнорирование проверки совместной работы вплоть до поздней интеграции, когда дисплей, аудио и Bluetooth впервые включаются одновременно.
• Отношение к сопряжению и bonding как к второстепенной задаче вместо проектирования пользовательского сценария.
• Пропуск первичной проверки RF-части (антенны, согласующей цепи и точности кварцевого генератора) до последних ревизий PCB.
• Расчёт на то, что настройка одной лишь прошивки компенсирует неудачную разводку RF-части.

Контрольный список первичной проверки¶

• Подтвердите, достаточно ли BLE или нужен двухрежимный Bluetooth, и выберите соответствующее устройство SF32.
• Найдите наиболее близкие к сценарию изделия примеры сервисов/профилей в SDK.
• Задайте целевые параметры передачи рекламных пакетов BLE и соединения для обнаружения, активной работы и простоя.
• Спроектируйте сценарии сопряжения, bonding и «забыть устройство».
• Проверьте разводку RF-части, согласование антенны и точность кварцевого генератора на реальном оборудовании.
• Проверьте выбранные профили (сервисы GATT, A2DP/AVRCP/HFP или вещание LE Audio) с настоящим телефоном или эталонным хостом.
• Проверьте совместную работу дисплея, аудио и датчиков при реалистичной комбинированной нагрузке.
• Спланируйте и проверьте доставку OTA, если обновления будут передаваться по Bluetooth.
• Измерьте энергопотребление при подключении в режиме простоя и убедитесь, что прикладной процессор переходит в сон как ожидалось.

Основные выводы¶

• Сначала решите, нужен ли только BLE или двухрежимный Bluetooth: от этого зависят выбор устройства и большая часть дальнейшей работы с SDK.
• В качестве основы используйте примеры сервисов GATT и профилей классического Bluetooth из SDK (HRPC, DISS, CTS, HID, ANCS/AMS, SPP, A2DP, AVRCP, HFP, PAN), а не создавайте их заново.
• Интервал соединения, периферийная задержка, тайм-аут контроля соединения и мощность передачи — главные параметры компромисса между задержкой, пропускной способностью и энергопотреблением.
• Для Bluetooth-аудио проверьте нужную роль классического Bluetooth или LE Audio на выбранном устройстве и в выбранной конфигурации SDK, затем спроектируйте и испытайте буферизацию и совместную работу. Утверждение о возможностях всего семейства не заменяет такую проверку.
• Bluetooth — системная задача: разводка RF-части, тактирование, сценарий сопряжения и совместная работа с графикой, аудио и датчиками не менее важны, чем код GATT.

Список актуальных проектов SDK для классического Bluetooth, BLE и LE Audio см. в разделе Примеры Bluetooth SDK.

Практический способ определить фактическое энергопотребление Bluetooth-устройства см. в разделе Профилирование энергопотребления Bluetooth.

Последнее обновление: 2026-10-21