Bluetooth-процессор¶

Введение¶

Bluetooth-процессор — это выделенная подсистема управления беспроводной связью в устройствах SF32LB. Она отвечает за задачи Bluetooth-контроллера с жёсткими временными ограничениями: планирование радиосвязи, управление соединением, его поддержание в режиме низкого энергопотребления и взаимодействие с главным прикладным процессором.

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

Набор и объём прикладных задач, которые может выполнять этот процессор низкого энергопотребления, зависят от семейства. Сверьтесь с таблицей ниже и проверьте поддерживаемое распределение задач в SDK для выбранной модели.

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

Зачем нужен выделенный Bluetooth-процессор¶

Bluetooth — это не просто программный протокол, который время от времени работает в фоне. Подключённое устройство должно соблюдать строгие временные требования к радиосвязи при анонсировании (advertising), сканировании, событиях соединения, обмене пакетами, передаче аудио, шифровании и совместной работе с другими подсистемами.

Выделенная Bluetooth-подсистема отделяет эти чувствительные ко времени задачи радиосвязи от основной прикладной нагрузки. Это даёт несколько практических преимуществ:

• Меньшее среднее энергопотребление в режиме ожидания при активном соединении.
• Более точное соблюдение временных параметров радиосвязи при одновременной работе UI, графики, аудио или ИИ.
• Обработка событий радиосвязи на стороне контроллера без пробуждения прикладного процессора для каждого события.
• Более чёткое разделение между прикладной прошивкой и прошивкой управления протоколом.
• Поддержка изделий, которым нужно оставаться на связи, пока главный процессор находится в режиме сна.

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

Это возможности архитектуры, а не гарантированные значения потребления или времени пробуждения. Результат измерений зависит от места выполнения стека Host, прерываний, запуска тактирования, политики сна и прикладного трафика. Измеряйте ток и время отклика с целевой прошивкой и нагрузкой.

Место Bluetooth в системе SF32¶

Упрощённую архитектуру беспроводной связи SF32 можно представить так:

Application Processor
  - product firmware
  - UI and graphics
  - audio application logic
  - user services
        │
        ▼
Bluetooth Host / System Services
        │
        ▼
Bluetooth Processor / Controller Firmware
  - link-layer timing
  - radio scheduling
  - low-power connection events
  - controller-side protocol work
        │
        ▼
Bluetooth Radio and RF Front End

Точное разделение между Host, Controller и прикладной прошивкой зависит от SDK, конфигурации стека и требований изделия. Однако прикладной процессор не следует считать единственным процессором, участвующим в работе Bluetooth. У Bluetooth-подсистемы есть собственный контекст выполнения; она помогает обеспечить предсказуемую работу беспроводной связи с низким энергопотреблением.

Различия между семействами устройств¶

В разных классах устройств SF32LB используются разные конфигурации процессора низкого энергопотребления. Всегда сверяйтесь с даташитом и документацией SDK для конкретной используемой модели.

В руководстве SiFli по HAL для SF32LB52x сказано, что LCPU выполняет стек протоколов Bluetooth и недоступен прикладному коду. Руководства по HAL для SF32LB55x, SF32LB56x и SF32LB58x описывают выполнение на LCPU задач, чувствительных к энергопотреблению, например BLE и обработки данных датчиков. Для SF32LB57x в руководстве SDK по ACPU указана архитектура HCPU/ACPU/LCPU и отнесены к LCPU такие задачи, как BLE и обработка данных датчиков, однако полный перечень пользовательских задач не определён. Не переносите выводы о программируемости LCPU с одного семейства на другое. Для конкретной модели проверьте конфигурацию ядер по даташиту, а затем убедитесь, что используемый выпуск SDK и конфигурация платы поддерживают нужную прикладную задачу на LCPU. Если такая комбинация не документирована, считайте распределение задачи непроверенным; до принятия решения уточните доступную память и ограничения планирования.

То же руководство по ACPU отдельно описывает роли прикладных ядер: в SF32LB57x ACPU отвечает за обработку аудио и графики, а в SF32LB58x предназначен для аудио-DSP. Эти функции не относятся к обязанностям Bluetooth-контроллера; проверьте распределение задач для выбранных платы и SDK.

Возможности Bluetooth в таблице обобщают документацию для семейств и не гарантируют поддержку каждого профиля во всех вариантах или сборках SDK. В даташитах SiFli для SF32LB52x, SF32LB55x, SF32LB56x и SF32LB58x указаны соответствующие возможности BLE или двухрежимного Bluetooth. В руководстве SDK по сигнальным испытаниям Bluetooth описаны тесты BR/EDR и BLE, а SF32LB57x включён в перечень поддерживаемых серий. Проверьте поддержку профилей, функций и конфигураций для конкретной модели и версии SDK.

Программирование приложений и прошивка контроллера¶

Возможность выполнять прикладные задачи на LCPU не означает доступа к исходному коду Bluetooth-контроллера или возможности заменить стек радиосвязи. Поддерживаемые обновления прошивки и патчи, доступная память и ограничения планирования зависят от устройства и SDK.

• Разработка энергосберегающих приложений. При наличии поддержки переносите на LCPU сбор данных датчиков, несложную обработку и управление системой. Учитывайте память стека, время выполнения и обмен с HCPU.
• Обслуживание и настройка контроллера. Используйте обновления прошивки и механизмы патчей, поддерживаемые производителем для выбранных устройства и SDK. Программируемое прикладное ядро не доказывает доступности исходного кода проприетарного контроллера или альтернативного радиостека. Отдельно уточните эти возможности у SiFli.

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

BLE и двухрежимный Bluetooth¶

В зависимости от модели устройство SF32 может поддерживать только Bluetooth Low Energy (BLE) или двухрежимный Bluetooth — одновременно Bluetooth Classic и BLE.

Bluetooth Low Energy¶

BLE предназначен для обмена данными с низким энергопотреблением. Типичные сценарии:

• Фитнес-браслеты и умные часы.
• Датчики здоровья и носимые устройства.
• Уведомления с телефона и сопутствующие приложения.
• Синхронизация данных датчиков.
• Маяки и устройства с функциями определения местоположения.
• Каналы управления и настройки с низким энергопотреблением.

BLE-соединения часто работают периодически и по событиям, поэтому хорошо подходят для Bluetooth-процессора с низким энергопотреблением.

Bluetooth Classic и двухрежимные системы¶

Двухрежимный Bluetooth дополняет BLE сценариями Bluetooth Classic. Он полезен для таких изделий, как:

• Bluetooth-аудиоаксессуары.
• Беспроводные адаптеры и модули.
• Устройства, которым нужна совместимость с существующими профилями Bluetooth Classic.
• Изделия, сочетающие управление по BLE с аудио или передачей данных по Bluetooth Classic.

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

Bluetooth-аудио и LE Audio¶

Bluetooth-аудио предъявляет дополнительные требования к архитектуре системы. Аудионагрузка включает тайминги радиосвязи, буферизацию, обработку кодека, синхронизацию тактовых сигналов и, иногда, одновременное обновление пользовательского интерфейса.

В хорошо спроектированной аудиосистеме SF32 Bluetooth задачи обычно распределены так:

• Bluetooth-процессор отвечает за радиосвязь и тайминги соединения на стороне Controller.
• Прикладной процессор выполняет логику изделия, UI и аудиофункции высокого уровня.
• Аудиоинтерфейсы, например I2S, PDM, ADC или DAC, передают отсчёты в остальную систему и из неё.
• DMA и буферизация снижают нагрузку на CPU при непрерывной передаче аудио.

Для LE Audio и других современных сценариев Bluetooth-аудио результат также зависит от архитектуры прошивки, поддержки стека, выбора кодека, пропускной способности памяти и политики управления питанием. В даташитах SiFli для SF32LB56x и SF32LB58x явно указана поддержка BLE Audio; поддержка BLE или двухрежимного Bluetooth сама по себе не означает поддержку LE Audio. Доступность конкретных профилей, кодеков и путей реализации в SDK зависит от модели и версии SDK. Проверьте это до выбора LE Audio для изделия. Bluetooth-процессор обеспечивает основу для соблюдения таймингов, но поведение всего изделия определяется SDK и архитектурой приложения.

Работа с низким энергопотреблением¶

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

• Получено уведомление или команда.
• Изменилось состояние соединения.
• Наступило время запланированной синхронизации.
• Начался или завершился аудиопоток.
• Произошло событие датчика или действие пользователя.
• Выполняется обновление прошивки или настройка устройства.

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

Фактический профиль энергопотребления зависит от интервала соединения, мощности передачи, параметров анонсирования, режима сна, конфигурации кварцевого генератора, разводки RF-части, политики прошивки и частоты пробуждения прикладного процессора.

Границы Host, Controller и приложения¶

Программную часть Bluetooth обычно делят на два основных уровня:

В системе SF32 обязанности Controller тесно связаны с Bluetooth-процессором и радиоподсистемой. В зависимости от архитектуры стека сторона Host может работать на прикладном процессоре, в системной прошивке или в компонентах, предоставляемых SDK.

Разработчикам приложений важно учитывать, что Bluetooth задействует несколько процессорных доменов. Разделяемая память, обмен сообщениями между процессорами, события и API SDK являются частью архитектуры изделия. Рассматривайте Bluetooth как подсистему, а не просто как библиотеку, подключённую к основному приложению.

Взаимодействие с прикладным процессором¶

Как правило, прикладной процессор управляет поведением изделия:

• Запускает и останавливает анонсирование (advertising).
• Инициирует соединения или принимает входящие.
• Управляет сервисами и характеристиками GATT.
• Обрабатывает сопряжение, bonding (сохранение ключей) и политику безопасности.
• Обменивается данными приложения с телефоном или шлюзом.
• Обновляет состояние UI при изменении состояния Bluetooth.
• Координирует аудиопотоки, датчики и режимы питания.

Bluetooth-процессор выполняет низкоуровневую работу, необходимую для поддержания соединения. Взаимодействие между процессорами обычно скрыто за API SDK, событиями, очередями или механизмами межпроцессорной связи.

Хорошая архитектура приложения не будит главный CPU без необходимости. По возможности объединяйте события в пакеты, выбирайте подходящие параметры соединения и не опрашивайте состояние из приложения с высокой частотой, если доступны обработчики событий.

Требования к RF и тактированию¶

Один Bluetooth-процессор не обеспечит хорошую беспроводную связь без правильно спроектированного окружающего оборудования. Разводка RF-части, настройка антенны, точность тактирования, качество питания и калибровка в производстве влияют на дальность, чувствительность, мощность передачи и стабильность соединения.

К важным аппаратным требованиям относятся:

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

Команды разработки ПО и аппаратуры должны рассматривать производительность Bluetooth как свойство системы. Параметрами прошивки нельзя полностью компенсировать плохую разводку RF-части или нестабильное тактирование.

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

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

Типичные проблемы совместной работы:

• Обновление дисплея или обмен с PSRAM уменьшают доступную пропускную способность памяти.
• Для DMA аудио и буферов Bluetooth-аудио нужны стабильные тайминги.
• Прерывания от датчиков слишком часто пробуждают прикладной процессор.
• Внешний Wi-Fi или другие источники RF-сигналов влияют на Bluetooth.
• Длительные критические секции или отключённые прерывания задерживают обработку Bluetooth на стороне Host.

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

Типичные сценарии применения¶

Bluetooth-процессор играет ключевую роль во многих категориях изделий SF32:

• Bluetooth-модули и последовательные адаптеры.
• Начальные модели умных часов и фитнес-браслетов.
• BLE-датчики здоровья и носимые устройства.
• Bluetooth-аудиоаксессуары.
• Умные бейджи и электронные ценники.
• Подключённые к телефону панели и HMI-устройства.
• Устройства управления умным домом и изделия с сопутствующим приложением.
• Устройства синхронизации датчиков и регистрации данных.

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

Практические рекомендации по проектированию¶

При разработке Bluetooth-прошивки для SF32 сначала определите, как изделие должно использовать беспроводную связь:

• Достаточно BLE или нужен двухрежимный Bluetooth?
• Требуется ли Bluetooth-аудио?
• Каковы требования к интервалу соединения, задержке и пропускной способности?
• Как часто должен пробуждаться главный прикладной процессор?
• Какие события должны выводить систему из режима Deep Sleep или Standby?
• Конкурируют ли задачи датчиков или UI с таймингами Bluetooth?
• Каковы целевые дальность RF-связи и мощность передачи?
• Как будут выполняться загрузка прошивки и калибровка RF в производстве?

Надёжная система обычно сочетает Bluetooth-процессор с тщательным выбором параметров соединения, событийной логикой приложения, планированием режимов низкого энергопотребления и качественной разводкой RF-части.

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

• В устройствах SF32LB используется выделенный Bluetooth-процессор или подсистема процессора низкого энергопотребления, которая обеспечивает стабильные тайминги беспроводной связи и снижает энергопотребление.
• В SF32LB52x LCPU выделен для Bluetooth-контроллера. В SF32LB55x, SF32LB56x и SF32LB58x прикладные задачи, определённые SDK, можно выполнять на LCPU в документированных конфигурациях. В SF32LB57x LCPU обслуживает Bluetooth и задачи, чувствительные к энергопотреблению, но поддержку каждой планируемой пользовательской задачи нужно проверить в целевой версии SDK и на целевой плате.
• Программируемый LCPU выполняет прикладные задачи в пределах ограничений SDK; доступ к исходному коду стека контроллера и возможность его изменения требуют отдельного подтверждения. Используйте обновления производителя и проверяйте изменения.
• BLE оптимизирован для подключённых устройств с низким энергопотреблением; двухрежимный Bluetooth добавляет сценарии Bluetooth Classic, например аудио и поддержку классических профилей.
• Bluetooth-процессор позволяет основному прикладному процессору оставаться в режиме сна, пока сохраняются соединения, продолжается анонсирование и происходят запланированные события радиосвязи.
• Хорошая работа Bluetooth зависит как от архитектуры прошивки, так и от аппаратуры, включая разводку RF-части, тактирование, питание, настройку антенны и калибровку.
• Рассматривайте Bluetooth как подсистему с границами Host/Controller, межпроцессорным взаимодействием, решениями по политике энергопотребления и ограничениями общих ресурсов.

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