Роли Central/Peripheral и структура данных UUID

Мы разобрались с потоками и таймерами в Zephyr RTOS, чтобы код не «зависал». Теперь выйдем за пределы одного чипа. Технология BLE (Bluetooth Low Energy) — главная причина, по которой выбирают nRF52840. В отличие от классического Bluetooth, BLE передает данные крошечными порциями и почти не тратит заряд батареи. Это стандарт для автономных датчиков.

Кто есть кто: роли GAP

Прежде чем обменяться данными, устройства должны найти друг друга. За это отвечает протокол GAP (Generic Access Profile). Он распределяет роли:

• Peripheral (Периферия): Ваш nRF52840. Он «рекламирует» себя в эфире (Advertising): «Я здесь, я — датчик пульса». Это ведомое устройство, которое экономит энергию и ждет подключения.
• Central (Центр): Смартфон или планшет. Он сканирует эфир (Scanning) и инициирует соединение.

Роль	Инициатива	Энергия	Пример
Peripheral	Ждет запроса	Экономит (спит)	Смарт-часы, датчик
Central	Ищет и подключает	Тратит (слушает эфир)	Смартфон, шлюз

nRF52840 может быть Central и Peripheral одновременно, но мы начнем с классики: чип — это датчик (Peripheral), а телефон — пульт управления (Central).

Порядок в данных: GATT

После подключения в работу вступает GATT (Generic Attribute Profile). Он диктует, как именно передавать информацию.

Забудьте про Serial.print() и «сырой» поток байтов. В BLE данные упакованы в строгую иерархию — как в матрешку:

1. Сервис (Service): Группа функций. Например, «Данные о погоде».
2. Характеристика (Characteristic): Конкретное значение внутри сервиса (температура или влажность). У нее есть права доступа: только чтение, запись или уведомления.

Почему это удобно?

В Arduino мы часто склеивали данные в строку: "T:25.5;H:60". Смартфону приходилось парсить эту строку, тратя ресурсы. В GATT всё четко:

• Сервис «Окружающая среда»
  • Характеристика Температура: 25.5
  • Характеристика Влажность: 60

Смартфон сразу понимает, где какое число, и не делает лишней работы.

Паспорта данных: UUID

Чтобы смартфон отличил температуру от давления, используются UUID (Universally Unique Identifier) — уникальные ID.

• Стандартные (16 бит): Короткие коды для типовых задач. Например, Сервис батареи всегда имеет ID 0x180F. Любое фитнес-приложение сразу поймет этот код.
• Кастомные (128 бит): Длинные строки вида 550e8400-e29b-41d4-a716-446655440000. Нужны для ваших уникальных функций, которых нет в стандарте.

В nRF Connect SDK мы будем использовать макросы для регистрации этих ID. Так стек Zephyr поймет, на какие запросы смартфона нужно отвечать.

Кто владеет данными: Сервер и Клиент

Здесь важно не запутаться. В BLE роли распределяются по факту владения информацией:

• GATT Server: Тот, у кого лежат данные. Ваш nRF52840 с датчиком — это Сервер. Он хранит таблицу значений.
• GATT Client: Тот, кто эти данные запрашивает. Смартфон — это Клиент.

Когда вы обновляете значение температуры в коде, вы меняете его на «Сервере». «Клиент» (телефон) получает уведомление об этом. Это событийная модель: мы не опрашиваем датчик в бесконечном цикле, а ждем событий (Callback-функций).

Теперь у нас есть все «кирпичики» для сборки BLE-устройства. В следующем уроке перейдем к практике: создадим кастомный профиль и передадим первые данные с nRF52840 на экран смартфона. 🚀