Расположение профиля Bluetooth в системе Bluetooth

Мой вопрос очень простой. Мне нужно знать, где все профили Bluetooth, такие как HID, HFP или HSP, загружаются в стек Bluetooth? Находится ли он на уровне хоста или в аппаратном чипсете Bluetooth, таком как USB-ключ/модуль, или на стороне хоста и чипсета?

Насколько я понимаю, мы можем реализовать профили Bluetooth на стороне хоста, используя такие пакеты, как BlueZ, но в то же время для набора микросхем Bluetooth, подключенного к хосту, должна быть какая-то микропрограмма и логика (например, CSVD, A-law) внутри чипсета.

Цитата из пакета BlueZ Android doc: "Поддержка широкополосной речи в HFP, требуется, чтобы чип BT принимал кодек mSBC". Это означает, что уровень хоста может реализовать этот профиль, только если набор микросхем BT обеспечивает низкоуровневую поддержку, такую как mSBC.

Мой ответ такой: "Мы можем создать любой профиль Bluetooth, скажем," X "на уровне хоста, если в чипсете BT установлена прошивка низкого уровня, поддерживающая профиль" X "". Пожалуйста, согласитесь или не согласитесь с моим пониманием.

PFA диаграмма моего понимания Положение профиля и его низкоуровневая прошивка

Мне нужно выбрать USB-адаптер Bluetooth, совместимый с Raspberry Pi, и настроить HID и HFP с помощью BlueZ.

Заранее Спасибо всем Светлым умам!

Ответ 1

Существует несколько способов реализации функций Bluetooth в системе в зависимости от того, сколько реализовано в контроллере и хосте.

Все в контроллере - приложение, верхний стек, может или не может HCI (нижний и верхний стеки связываются с помощью команд и событий HCI), нижний стек. Пример: большая часть мыши Bluetooth, клавиатуры и т.д., Где за все отвечает один контроллер (Bluetooth, RTOS/планировщик, управляющий светодиод в устройстве и т.д.)
Приложение в хосте и нижняя и верхняя часть стека в контроллере. Может или не может реализовать HCI в контроллере. Пример: где мы используем выделенный чип Bluetooth и интегрируем его с устройством. Здесь устройство будет передавать данные приложения на выделенный чип Bluetooth. Все, что связано с протоколом Bluetooth, будет сделано с контроллера/чипа BT. Если вы используете модуль HC-05 с модулем Arduino, Arduino передаст последовательные данные в модуль HC-05.
Приложение и верхний стек в хосте и нижний стек в контроллере. Bluez, Bluedroid и все другие стеки в операционных системах относятся к этому типу. Это свяжется с контроллером с помощью команд и событий HCI. Пример: мобильные телефоны, компьютеры, телевизор с Bluetooth и т.д. (Устройства с мощным процессором приложений)

Итак, давайте предположим, что вы спрашиваете о третьем типе. В этом случае ваше предположение верно. Здесь все профили реализованы только на хосте. Но протоколы/кодеки, необходимые для их поддержки, будут реализованы в контроллере (либо программно-аппаратный, либо аппаратный блок). Например, GAP (для BR-EDR) реализован на хосте, но алгоритмы шифрования и дешифрования реализованы в контроллере как блоки встроенного ПО или аппаратного обеспечения. Для профилей A2DP аудиокодек/декодеры будут реализованы в контроллере. Затем чип BT передает эти аудиоданные на хост с I2S или другими протоколами. Для профиля диспетчера безопасности BLE алгоритм шифрования/дешифрования реализован на самом хосте, но белый список, автоматическое подключение и т.д. Будут реализованы в контроллере.

Мой ответ таков: "Мы можем создать любой профиль Bluetooth, скажем," X "на уровне хоста, если в чипсете BT установлена прошивка низкого уровня с поддержкой профиля" X "". Пожалуйста, согласитесь или не согласитесь с моим пониманием.

Для случая использования BlueZ это правильно. Вам необходимо использовать контроллер с необходимыми аппаратными возможностями (Прошивка + аппаратные ресурсы).

Для сценариев 1 и 2 профили и поддерживающие протоколы будут реализованы в контроллере.