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

Я уже предпринимал такую попытку в одной из своих статей. Описанный там адаптер представлял больше учебный интерес, чем имел практическое применение, так как прошивка представляла собой полноценный Linux, кастомизированный скриптами, и использовала слишком мощное (Raspberry Pi Zero 2 W) для такой простой задачи железо.

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

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

Исходный код прошивки адаптера вы можете посмотреть в моём репозитории на GitHub.

Начнём с требований, предъявляемых к устройству.

Требование к адаптеру

Если бы адаптер разрабатывался в промышленных масштабах, то, конечно бы, разрабатывалась печатная плата, на которую помещается микроконтроллер, Bluetooth-чип и обвязка. Но у нас любительский DIY-проект, и поэтому можно использовать различные платы разработчика.

Существует множество плат, имеющих Bluetooth на борту.

У меня выбор пал на Raspberry Pico W. Она поддерживает современный Bluetooth 5, а у меня был опыт разработке приложений для RP2040.

Адаптер должен иметь USB-разъём для подключения клавиатуры, чип с Bluetooth SDR или BLE. Также адаптеру необходимо обеспечить внешнее питание, так как проводная клавиатура является периферийным устройством USB и будет запитываться от адаптера.

С точки зрения операционной системы и проводная, и беспроводная клавиатура являются HID-устройствами: отличаются только нижележащие коммуникационные протоколы (USB и Bluetooth/BLE).

Адаптер должен работать как USB-хост с подключённой USB-клавиатурой и являться периферийным Bluetooth-устройством.

Алгоритм работы прошивки адаптера простой. Нужно, работая в качестве USB-хоста, получать HID-репорты от клавиатуры и пересылать их сопряжённому по Bluetooth устройству. Устройством может быть компьютер, ноутбук, телефон, телевизор.

Здесь я немного упростил, так как при подключении HID-устройства используются дескрипторы, описывающие HID-репорты. У разных клавиатур эти дескрипторы могут отличаться. Но если нам достаточно базового функционала клавиатуры, допустимо, чтобы у адаптера был универсальный дескриптор HID-репорта.

USB

USB можно реализовать аппаратно, а можно программно. Под аппаратной реализацией понимается наличие электронной схемы в микроконтроллере, которая обеспечивает взаимодействие по протоколу USB. Программная реализация подразумевает использование GPIO-пинов и написание программы, которая будет на эти пины выдавать сигнал в соответствии со спецификацией USB. В RP2040 существует механизм PIO, который разгружает процессор при работе с GPIO-пинами, но всё же я решил использовать аппаратный USB.

При использовании аппаратного USB, единственный USB-разъем Raspberry Pico W используется для подключения клавиатуры, поэтому нужно подавать внешнее питание на пин VBUS.

Также для отладки удобно собрать схему со вторым Pico, которую я опишу и приведу позже.

HID

Как я уже писал в предыдущей статье, спецификация HID — объёмный труд.

Разрабатываемый адаптер является USB-хостом для HID USB-клавиатуры и периферийным устройством Bluetooth с профилем HOG для компьютера или телефона, сопрягаемого по беспроводному каналу.

Спецификация HID используется как для USB, так и для Bluetooth-устройств. Если вы изучите исходный код ядра Linux, то заметите, что программный код для HID используется как для USB, так и для Bluetooth.

Из важного: адаптер должен уметь прочитать информацию, касающуюся HID, по USB-протоколу, и передать её часть по Bluetooth.

Нужно уметь обрабатывать подключение USB-устройств, определять, что USB-устройство является клавиатурой, а потом опрашивать клавиатуру на наличие нажатых клавиш, а коды (Usage ID) нажатых клавиш передавать по Bluetooth.

Bluetooth

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

В современных устройствах чаще всего используется версия Bluetooth 5.x. Чип CYW43439, установленный в Raspberry Pico W, поддерживает Bluetooth 5.2.

Bluetooth-устройства могут работать в двух режимах:

• Bluetooth Classic (BR/EDR),

• Bluetooth Low Energy (BLE).

Многие устройства поддерживают оба режима одновременно (dual-mode), однако у каждого режима разные стеки протоколов и области применения. Я использовал BLE, так как он проще, энергоэффективнее и лучше подходит для периферийных устройств.

Стек Bluetooth — это набор протоколов, разбитых по уровням (аналогично сетевым моделям).

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

Стек Bluetooth Low Energy

Для лучшего понимания BLE приведу схему, иллюстрирующую его стек.

Схема позволяет понять взаимосвязи составляющих BLE. Стек BLE логически делится на две части:

• контроллер (Controller) — низкоуровневая часть: управление радиомодулем, приём и передача LL-пакетов, обеспечение радиопередачи;

• хост (host) — высокоуровневая часть: реализация системных профилей GAP и GATT, безопасность, логика BLE-соединений.

Bluetooth-хост реализуется микроконтроллером, а Bluetooth-контроллер — отдельным чипом, способным генерировать радиосигнал.

Обычно контроллер и хост взаимодействуют через Host Controller Interface (HCI), а HCI может быть основан на UART, SPI или USB. На базе чего основан HCI в Raspberry Pico W, я не нашёл, в принципе это не сильно важно, так как в Pico SDK есть библиотеки для взаимодействия с чипом CYW43439, их описание приведено здесь.

На схеме приведены как базовые протоколы (L2CAP, SMP, ATT), так и BLE-профили, их использующие (GATT, GAP). Обратите внимание, что профиль GAP может использовать протокол Link Layer, так как advertising-пакеты, используемые при обнаружении BLE-устройств, представляют собой пакеты уровня Link Layer.

Профили Bluetooth

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

В GATT (Generic Attribute Profile) атрибуты (сервисы и характеристики) однозначно определяются через UUID. Протокол не поддерживает строковые имена («Battery Service», «Temperature») на низком уровне — они существуют только для удобства чтения в документации и отладчиках. Приложения и устройства оперируют именно числами.

У каждого сервиса и характеристики есть числовой UUID (либо 16/32-битное короткое число для стандартных, либо 128-битное длинное число для кастомных).

Любое BLE-устройство поддерживает два системных профиля: GAP и GATT.

GAP определяет процедуры и правила, по которым устройства:

• объявляют себя (advertising),

• находят друг друга (scanning),

• устанавливают соединение.

GATT описывает, как представить модель «сервисы — характеристики — дескрипторы» в виде набора атрибутов, доступных через протокол передачи атрибутов ATT.

Основные функции BLE-устройства реализовываются в прикладных профилях. Для BLE-клавиатуры это HID over GATT Profile (HOGP).

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

Функции разрабатываемого адаптера, разбитые по профилям BLE

Разрабатываемый адаптер поддерживает несколько профилей: два обязательных системных (GAP и GATT) и один прикладной (HOGP).

GAP

В роли BLE-устройства адаптер должен:

• передавать рекламные пакеты (advertising), чтобы быть обнаруженным,

• выполнять сопряжение (pairing),

• сохранять ключи безопасности (bonding),

• устанавливать соединение (connecting) с ранее сопряжённым устройством.

GATT

Периферийное BLE-устройство обычно выступает как GATT-сервер, предоставляющий доступ к своей базе атрибутов (сервисам, характеристикам и их значениям) по запросам клиента.

При использовании библиотеки BTstack эта база описывается в .gatt файле. Низкоуровневая логика GATT-сервера уже реализована библиотекой. Нам только нужно реализовать прикладную логику.

У BLE-устройства, на котором запущен GATT-сервер, должен присутствовать один экземпляр GATT-сервиса. Внутри этого сервиса обычно находится важная характеристика Service Changed (UUID 0x2A05). Она уведомляет клиента о том, что структура сервисов изменилась (например, при обновлении прошивки). Даже если ваша база статична, стандарт требует наличия этого сервиса для обеспечения совместимости.

HOGP

В спецификации профиля HOGP описано, какие сервисы и характеристики должно реализовать BLE-устройство, чтобы работать как HID (клавиатура, мышь и т. п.).

BLE HID-устройство включает:

• HID Service (0x1812) — основной сервис,

• Battery Service (0x180F) — уровень батареи,

• Device Information Service (0x180A) — информация об устройстве.

В скобках указаны UUID для этих сервисов.

HOGP во многом повторяет модель USB HID. Характеристики HID Service имеют прямые соответствия в спецификации USB HID.

Таким образом, BLE-клавиатура обычно реализует следующие сервисы:

• GAP Service — для отображения имени устройства,

• GATT Service — для того, чтобы клиент мог определить, изменились ли описания сервисов на устройстве,

• Device Service — для отображения информации об устройстве,

• Battery Service — для отображения информации о заряде батареи,

• HID Service — для реализации взаимодействия по протоколу HID.

Схема стенда

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

Я привык в сложных случаях в десктопных приложениях использовать интерактивный дебаггер. Часто использование дебаггера даёт лучшее понимание того, что происходит, чем консольный вывод или логи, особенно на начальных стадиях разработки. Лучше, когда микроконтроллер может выполнять дебаг микроконтроллера с использованием как интерактивно, так и использованием консольного вывода.

Часто для интерактивной отладки Raspberry Pi Pico / Pico W используют Pico Debug Probe.

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

Эта схема удобна тем, что вам не нужно переподключать Pico при обновлении программного кода, зажимая кнопку Boot. Это экономит ваше время, а разъём меньше изнашивается. Кроме того, USB-разъём можно использовать для подключения USB-клавиатуры (как в нашем случае) или другой USB-периферии к Pico.

На первую Raspberry Pico необходимо установить прошивку Debug Probe, которая находится на GitHub.

Настройка отладчика

Прошивку для адаптера я разрабатывал в Visual Studio Code на Debian 13. Ниже привожу настройки, которые нужно выполнить, чтобы добиться работы отладчика.

1. Устанавливаем пакеты Debian:

   sudo apt install libusb-1.0-0 libhidapi-hidraw0 gdb-multiarch binutils-multiarch gcc-arm-none-eabi binutils-arm-none-eabi
   

2. Добавляем udev-rules для Debug Probe:

   sudo tee /etc/udev/rules.d/199-pico-debug-probe.rules > /dev/null <<'EOF'
   SUBSYSTEM=="usb", ATTR{idVendor}=="2e8a", ATTR{idProduct}=="000c", MODE="0666"
   KERNEL=="hidraw*", ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000c", MODE="0666", GROUP="plugdev"
   EOF
   

3. Применяем правила:

   sudo udevadm control --reload-rules
   sudo udevadm trigger
   

4. Добавляем следующие строки в файл settings.json нашего проекта в Visual Code:

   "cortex-debug.objdumpPath": "/usr/bin/arm-none-eabi-objdump",
   "cortex-debug.gdbPath": "/usr/bin/arm-none-eabi-gdb",
   "cortex-debug.armToolchainPrefix": "arm-none-eabi-",
   

Реализация

Часть низкоуровневого функционала для USB, Bluetooth и HID уже реализовано в библиотеках TinyUSB и BTstack, которые входят в состав Pico SDK. Чтобы получить готовое устройство, их нужно настроить и дописать свой функционал.

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

Хорошо помогают в понимании примеры, поставляемые вместе с библиотеками. Если что-то неясно в спецификации или что как настроить, всегда можно подсмотреть решение в примерах.

Я разрабатывал прошивку в Visual Studio Code и использовал официальный плагин Raspberry. Останавливаться на том, как установить Visual Studio Code и плагин, не буду.

Приведу важные участки исходного кода прошивки и прокомментирую интересные моменты.

Конфигурирование USB-стека

Конфигурирования USB-стека при использовании библиотеки TinyUSB сводится к написанию нескольких define. Ниже содержимое файла tusb_config.h.

#ifndef _TUSB_CONFIG_H_
#define _TUSB_CONFIG_H_

#define CFG_TUSB_MCU                OPT_MCU_RP2040

// Only Host
#define CFG_TUH_ENABLED             1
#define BOARD_TUH_RHPORT            0


#define CFG_TUH_DEVICE_MAX          1  // Only one device  
#define CFG_TUH_HUB                 0  // Do not support hubs
#define CFG_TUH_HID                 2  // Number of HID Report Descriptor
#define CFG_TUH_VENDOR              0  

// Buffer settings
#define CFG_TUH_ENUMERATION_BUFSIZE 256
#define CFG_TUH_HID_EPIN_BUFSIZE    64
#define CFG_TU_HID_EPOUT_BUFSIZE    64

#endif

Реализация USB-хоста для клавиатуры

Реализация USB-хоста с помощью библиотеки TinyUSB — это написание коллбеков и вызовов функций библиотеки.

Из коллбеков нам интересны два, которые относятся к работе HID-устройства:

• tuh_hid_mount_cb — вызывается при подключении HID-устройства,

• uh_hid_report_received_cb — вызывается при получении HID-репорта от клавиатуры.

В первом мы определяем, действительно ли подключается клавиатура, а во втором — обрабатываем получение HID-репорта, отсылая его по Bluetooth.

#include "bsp/board_api.h"
#include "tusb.h"
#include "hog_keyboard.h"

#define MAX_REPORT  4

// Each HID instance can has multiple reports
static struct
{
  uint8_t report_count;
  tuh_hid_report_info_t report_info[MAX_REPORT];
}hid_info[CFG_TUH_HID];

static void process_kbd_report(hid_keyboard_report_t const *report);

void tuh_hid_mount_cb(uint8_t dev_addr, uint8_t instance, uint8_t const* desc_report, uint16_t desc_len)
{
  printf("HID device address = %d, instance = %d is mounted\r\n", dev_addr, instance);

  // Interface protocol (hid_interface_protocol_enum_t)
  const char* protocol_str[] = { "None", "Keyboard", "Mouse" };
  uint8_t const itf_protocol = tuh_hid_interface_protocol(dev_addr, instance);

  printf("HID Interface Protocol = %s\r\n", protocol_str[itf_protocol]);

  // By default host stack will use activate boot protocol on supported interface.
  // Therefore for this simple example, we only need to parse generic report descriptor (with built-in parser)
  if ( itf_protocol == HID_ITF_PROTOCOL_NONE )
  {
    hid_info[instance].report_count = tuh_hid_parse_report_descriptor(hid_info[instance].report_info, MAX_REPORT, desc_report, desc_len);
    printf("HID has %u reports \r\n", hid_info[instance].report_count);
  }

  // request to receive report
  // tuh_hid_report_received_cb() will be invoked when report is available
  if ( !tuh_hid_receive_report(dev_addr, instance) )
  {
    printf("Error: cannot request to receive report\r\n");
  }
}

void tuh_mount_cb(uint8_t dev_addr) {
  // application set-up
  printf("A device with address %d is mounted\r\n", dev_addr);
}

void tuh_umount_cb(uint8_t dev_addr) {
  // application tear-down
  printf("A device with address %d is unmounted \r\n", dev_addr);
}

// Invoked when device with hid interface is un-mounted
void tuh_hid_umount_cb(uint8_t dev_addr, uint8_t instance)
{
  printf("HID device address = %d, instance = %d is unmounted\r\n", dev_addr, instance);
}

// Invoked when received report from device via interrupt endpoint
void tuh_hid_report_received_cb(uint8_t dev_addr, uint8_t instance, uint8_t const* report, uint16_t len)
{
  uint8_t const itf_protocol = tuh_hid_interface_protocol(dev_addr, instance);

  switch (itf_protocol)
  {
    case HID_ITF_PROTOCOL_KEYBOARD:
      TU_LOG2("HID receive boot keyboard report\r\n");
      process_kbd_report( (hid_keyboard_report_t const*) report );
    break;
    default:
      printf("Unsupported protocol\n");
  }

  // continue to request to receive report
  if ( !tuh_hid_receive_report(dev_addr, instance) )
  {
    printf("Error: cannot request to receive report\r\n");
  }
}

static void process_kbd_report(hid_keyboard_report_t const *report)
{
  send_hid_report((const uint8_t*) report, sizeof (hid_keyboard_report_t));
}

Реализация Bluetooth peripheral с профилем HID

Конфигурирование Bluetooth-стека

Конфигурирование Bluetooth-стека осуществляется в файле btstack_config.h. Как и в случае c USB, это написание define. Их количество больше, поэтому подробно вы можете посмотреть в моём репозитории.

Настройка advertising

Advertising — это транслирование информации об устройстве, чтобы можно было обнаружить устройство, а потом с ним сопрячься.

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

Транслируются следующие записи:

• флаги (вид обнаружения и поддерживается Bluetooth Classic или нет),

• имя устройства,

• список поддерживаемых сервисов,

• представление устройства.

const uint8_t adv_data[] = {
    // Flags general discoverable, BR/EDR not supported
    0x02, BLUETOOTH_DATA_TYPE_FLAGS, 0x06,
    // Name
    0x0d, BLUETOOTH_DATA_TYPE_COMPLETE_LOCAL_NAME, 'H', 'I', 'D', ' ', 'K', 'e', 'y', 'b', 'o', 'a', 'r', 'd',
    // 16-bit Service UUIDs
    0x03, BLUETOOTH_DATA_TYPE_COMPLETE_LIST_OF_16_BIT_SERVICE_CLASS_UUIDS, ORG_BLUETOOTH_SERVICE_HUMAN_INTERFACE_DEVICE & 0xff, ORG_BLUETOOTH_SERVICE_HUMAN_INTERFACE_DEVICE >> 8,
    // Appearance HID - Keyboard (Category 15, Sub-Category 1)
    0x03, BLUETOOTH_DATA_TYPE_APPEARANCE, 0xC1, 0x03,
};

Кроме самих описаний записей, нужно выполнить дополнительное конфигурирование и включение:

    uint16_t adv_int_min = 0x0300;
    uint16_t adv_int_max = 0x0300;
    uint8_t adv_type = 0;
    bd_addr_t null_addr;
    memset(null_addr, 0, 6);
    gap_advertisements_set_params(adv_int_min, adv_int_max, adv_type, 0, null_addr, 0x07, 0x00);
    gap_advertisements_set_data(adv_data_len, (uint8_t*) adv_data);
    gap_advertisements_enable(1);

Настройка Security Manager

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

sm_init();
sm_set_io_capabilities(IO_CAPABILITY_NO_INPUT_NO_OUTPUT);
sm_set_authentication_requirements(SM_AUTHREQ_SECURE_CONNECTION | SM_AUTHREQ_BONDING);

Обработка сопряжения BLE-устройств

Для обработки сопряжения BLE-устройств необходимо обработать ивенты от контроллера SM_EVENT_JUST_WORKS_REQUEST, SM_EVENT_NUMERIC_COMPARISON_REQUEST и SM_EVENT_PASSKEY_DISPLAY_NUMBER. Так как мы выбрали IO Capabilities на прошлом шаге IO_CAPABILITY_NO_INPUT_NO_OUTPUT, то, скорее всего, придёт ивент SM_EVENT_JUST_WORKS_REQUEST. Остальные ивенты просто приведены, чтобы удобно было выполнять отладку.

        case SM_EVENT_JUST_WORKS_REQUEST:
            printf("Just Works requested\n");
            sm_just_works_confirm(sm_event_just_works_request_get_handle(packet));
            break;
        case SM_EVENT_NUMERIC_COMPARISON_REQUEST:
            printf("Confirming numeric comparison: %"PRIu32"\n", sm_event_numeric_comparison_request_get_passkey(packet));
            sm_numeric_comparison_confirm(sm_event_passkey_display_number_get_handle(packet));
            break;
        case SM_EVENT_PASSKEY_DISPLAY_NUMBER:
            printf("Display Passkey: %"PRIu32"\n", sm_event_passkey_display_number_get_passkey(packet));
            break;

Настройка GATT

Настройка GATT-сервера в BTstack сводится к написанию .gatt-файла, который потом при сборке приложения разворачивается в большой include-файл. В этом файле прописываются реализуемые сервисы и характеристики. Для BLE-клавиатуры уже всё реализовано за нас, нужно только собрать нужное.

PRIMARY_SERVICE, GAP_SERVICE
CHARACTERISTIC, GAP_DEVICE_NAME, READ, "HID Keyboard"

// add Battery Service
#import <battery_service.gatt>

// add Device ID Service
#import <device_information_service.gatt>

// add HID Service
#import <hids.gatt>

PRIMARY_SERVICE, GATT_SERVICE
CHARACTERISTIC, GATT_DATABASE_HASH, READ,

Вы, наверное, заметили, что имя устройства мы уже прописывали в записях для advertisment, теперь мы его опять прописываем как характеристику GAP Service. Характеристика GAP_DEVICE_NAME определяет, как будет отображаться устройство в системе после сопряжения, хотя многие устройства на Android эту характеристику игнорируют, чего не скажешь об iPhone.

Нужно не забыть инициализировать GATT-сервер:

att_server_init(profile_data, NULL, NULL);

Переменная profile_data получается после обработки .gatt-файла при сборке.

Инициализация сервисов и регистрация обработчиков коллбеков

Инициализируем Battery Service, Device Information Service и HID Service:

    // Battery service
    battery_service_server_init(battery);

    // Device information service
    device_information_service_server_init();

    // HID Device service
    hids_device_init(0, hid_descriptor_keyboard_boot_mode, sizeof(hid_descriptor_keyboard_boot_mode));

hid_descriptor_keyboard_boot_mode — это массив, содержащий HID Report Descriptor для клавиатуры

Регистрируем обработчики коллбеков:

    // HCI events
    hci_event_callback_registration.callback = &packet_handler;
    hci_add_event_handler(&hci_event_callback_registration);

    // register for SM events
    sm_event_callback_registration.callback = &packet_handler;
    sm_add_event_handler(&sm_event_callback_registration);

    // register for HIDS
    hids_device_register_packet_handler(packet_handler);

Отсылка HID-репортов по Bluetooth

Отсылка HID-репортов выглядит очень просто. Вызывается функция hids_device_send_input_report, которой передаётся дескриптор, полученный при подключении Bluetooth-устройства, сам HID Report и размер HID Report в байтах.

void send_hid_report(const uint8_t* report, size_t len){
    hids_device_send_input_report(con_handle, report, len);
}

Отладка работы устройств по протоколу BLE

Для отладки работы устройств по протоколу BLE удобно использовать снифер и приложение Wireshark.

Я использовал USB-донгл nRF52840 Dongle от Nordic Semiconductor, на который была установлена прошивка, превращающая его в BLE снифер.

К сожалению, для просмотра защищённого трафика необходимо знать ключи, которые получаются при Bluetooth pairing. Ключ необходимо вывести в Wireshark, чтобы расшифровать захваченный трафик.

Можно посмотреть трафик, не прибегая к cниферу, выбрав интерфейс bluetooth-monitor в Wireshark. Вы не увидите advertising-пакеты, но вам не нужно будет расшифровывать пакеты для остального трафика, так как в bluetooth-monitor выводится взаимодействие через HCI хоста и контроллера в ядре Linux.

Выводы

Важно понимать основы USB, HID, Bluetooth, уметь использовать библиотеки, знать язык С на базовом уровне и уметь работать с конкретным микроконтроллером/платой разработчика.

Если у вас это вызывает затруднения, вы уже знаете, какие темы нужно подучить.

Я считаю, что адаптер, созданный на базе Pico и не использующий полноценный Linux и Raspberry для реализации Bluetooth-периферии, лучше, чем в моей прошлой статье по Bluetooth. Он проще, использует более дешёвую плату, практически сразу готов к работе, не нужно писать Linux userspace-код для реализации профилей Bluetooth.

Можно использовать другие микроконтроллеры или платы разработчика вместо Raspberry Pi Pico W. Но Pico устроил меня по цене и по накопленному багажу знаний.

C целью упрощения повествования в статье я не стал рассказывать, как реализовать обработку HID Output Report (для управления светодиодами Caps Lock и Num Lock на клавиатуре).

В следующей статье я планирую рассказать, как я сделал адаптер для своей клавиатуры Kingston HyperX, с чем столкнулся и как решал возникшие трудности.

© 2026 ООО «МТ ФИНАНС»