Это руководство создано как естественное продолжение руководства [3]. Поэтому рекомендуется, хотя и не обязательно, предварительно изучить это руководство. Необходимы также базовые знания по использованию Keil, nRF Connect и nrfjprog, как загружать приложение в память микроконтроллера Вашей платы разработчика. Ознакомьтесь с руководством [4], чтобы научиться пользованию оборудованием и скомпилировать Ваше первое приложение BLE.

Если столкнулись с проблемами, то посетите форум Nordic DevZone (devzone site:nordicsemi.com), просмотрите документацию в Infocenter, и ознакомьтесь с документацией на Ваш кит разработчика.

[Базовая теория]

Generic Attribute Profile (GATT). Bluetooth Core Specification определяет GATT следующим образом: "Профиль GATT определяет структуру, по которой осуществляется обмен данными профиля устройства BLE. Эта структура определяет такие базовые элементы, как службы (services) и характеристики (characteristics), используемые в профиле".

Другими словами, это набор правил, описывающих как объединять, представлять и передавать данные, используя BLE. См. [5], для дополнительной информации прочитайте Bluetooth Core Specification v4.2, Vol. 3, Part G. Возможно, это покажется непростым чтением, но в конце концов должно окупиться.

Services. Стандарт Bluetooth (Bluetooth Core Specification) определяет понятие службы (или сервиса) следующим образом: "Служба (service) это набор данных и связанных с ними алгоритмов поведения, предназначенных для реализации некоторой функции или свойства устройства. [...] Определение службы может содержать в себе […] обязательные характеристики и не обязательные (опциональные) характеристики".

Другими словами, служба это коллекция информации, наподобие значений параметров сенсоров. Организация Bluetooth Special Interest Group (Bluetooth SIG) создала предопределенный список служб [2]. Например, была определена служба с именем Heart Rate Service (HRS) для мониторинга частоты сердцебиений. Причина, почему так было сделано - облегчить разработчикам создание приложений и firmware для устройств, совместимых со стандартной Heart Rate Service. Однако это не означает, что Вы не могли бы сделать свой сенсор HRS на основе своих собственный идей и структур сервиса. Иногда люди ошибочно полагают, что поскольку Bluetooth SIG определила некоторые службы, то приложения можно делать только таким образом, чтобы они соответствовали этим определениям. Это не тот случай. Можно без проблем создавать свои собственные службы для своих собственных приложений.

Characteristics. Bluetooth Core Specification определяет характеристики так: "Характеристика (characteristic) это значение, используемое службой вместе со свойствами и информацией о конфигурации - как получить доступ к значению, и как это значение должно быть отображено или представлено".

Другими словами, характеристика это место для некоторого значения параметра плюс информация о его представлении. Также в характеристике инкапсулируются параметры безопасности (security), единицы измерения (units) и другие метаданные, касающиеся характеристики.

Аналогией может служить склад, заставленный шкафами для хранения данных, где каждый шкаф имеет ряд выдвижных ящиков. Профиль GATT это как бы помещение склада. Шкафы это службы, а выдвижные ящики это характеристики, где хранится разная информация. У некоторых из этих ящиков могут быть замки, ограничивающие доступ к их информации.

Представим для примера монитор сердцебиения (Heart Rate Monitor, HRM). Наручные часы с такой функцией обычно будут использовать как минимум 2 службы:

1. Heart rate service. В этой службе инкапсулируются 3 характеристики:

a. Обязательная характеристика Heart Rate Measurement, где будет храниться частота пульса.
b. Опциональная характеристика Body Sensor Location, показывающая место положение тела человека.
c. Условная характеристика Heart Rate Control Point, точка контроля частоты пульса.

2. Battery service. В этой службе инкапсулируется одна характеристика:

a. Обязательная характеристика Battery Level, уровень заряда батареи.

Почему нужно беспокоиться об этом? Почему бы просто не посылать любые данные напрямую, без лишних действий по встраиванию данных в какие-то сервисы и характеристики? Причина тут простая - стандартизация. GATT, сервис, характеристика - все это предназначено для обеспечения совместимости и упрощения реализации. Когда мобильные устройства iPhones, Android или планшеты на Windows прослушают оповещение (advertising) BLE-устройства, где будут стандартным образом предоставлены данные службы сердцебиения, можно быть на 100% уверенным, что в этой службе будет как минимум характеристика heart rate measurement. Она там будет обязательно, потому что это гарантируется стандартизированным представлением службы. Если устройство содержит больше одной службы, то Вы свободны выбрать и использовать ту службу, которая необходима. Упакованная таким способом информация позволяет быстро обнаруживать в BLE-устройствах доступную информацию, передавать только то, что необходимо, и тем самым экономить драгоценное время и энергию. Помните, стандарт BLE был как раз разработан с целью максимально экономить потребляемую от батареи энергию.

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

Universally Unique ID (UUID). С аббревиатурой UUID Вы будете часто встречаться в мире BLE. Это уникальный номер, используемый для идентификации служб, характеристик и дескрипторов, также известных как атрибуты. Эти ID передаются по радио, благодаря чему периферийное устройство информирует центральное устройство о предоставляемых службах. Для экономии времени передачи и занимаемой памяти в nRF52 существует 2 вида UUID: 16-битный и 128-битный.

16-bit UUID. Это короткий тип идентификатора. Предопределенной службе Heart Rate Service, например, присвоен UUID 0x180D, и одной из из её внутренних характеристик Heart Rate Measurement присвоит UUID 0x2A37. 16-разрядные UUID эффективным по занимаемой памяти и экономии энергии, однако они предоставляют относительно узкий диапазон уникальных значений; Вы можете передать по радио только лишь предопределенные заранее идентификаторы Bluetooth SIG UUID. Из-за этого появилась необходимость во втором типе UUID, благодаря которому можно будет также передавать свои собственные UUID-ы.

128-bit UUID. Это длинный UUID, который иногда называют уникальным идентификатором, специфичным для производителя (vendor specific UUID). Этот тип UUID нужно использовать, когда Вы хотите создать свои собственные службы и характеристики. 128-битный UUID может выглядеть примерно так: 4A98xxxx-1CC4-E7C1-C757-F1267DD021E8, и он называется базовым UUID (base UUID). Здесь четыре буквы x представляют поле, куда можно вставить свой собственный 16-битный ID для своих пользовательских служб и характеристик, и использовать их так же, как и предопределенные UUID. Таким способом можно сохранить базовый UUID в памяти только один раз, забыть о нем, и работать только со своими 16-битными ID, как с обычными. Вы  можете генерировать base UUID-ы с помощью утилиты nRFgo Studio.

Интересный факт касательно UUID: не существует базы данных, гарантирующей отсутствие совпадений UUID, однако если Вы сгенерируете два случайных 128-разрядных UUID, то вероятность примерно ~3e-39, что они будут одинаковыми (это примерно 1 шанс из 340,000,000,000,000,000,000,000,000,000,000,000,000).

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

Интервал соединения (Connection Interval, CI). Центральное устройство устанавливает параметр CI, когда впервые устанавливается соединение между центральным и периферийным устройством. Периферийное устройство задает минимальное и максимальное значения, которые служат желательными пределами интервала соединения для периферийного устройства. Большинство центральных устройств будут использовать CI по умолчанию, и обычно будут игнорировать максимальные и минимальные значения, заданные периферийным устройством. Периферийному устройству обычно нужно генерировать запрос обновления параметров соединения (Connection Parameter Update Request) через некоторое время после установки соединения BLE, чтобы попытаться поменять CI для соответствия необходимому диапазону. Центральное устройство может как принять, так и отклонить этот запрос, и ответить интервалом соединения, который может как попадать, так и не попадать в указанный периферийным устройством диапазон. Если периферийное устройство примет это значение, то будет использоваться новый CI. Интервал соединения должен быть в диапазоне между 7.5 мс и 4000 мс.

Slave Latency (SL). Латентность (задержка) реакции периферийного устройства. Путем установки ненулевого значения SL периферийное устройство может несколько раз не отвечать на запрос данных со стороны центрального устройства. Однако если у периферийного устройства есть данные для отправки, то оно в любой момент может принять решение отправить данные. Это позволяет периферийному устройству спать в течение долгого времени, если у него нет данных для отправки, но в то же время быстро посылать данные при необходимости. Примерами такого поведения могут служить клавиатура и мышь, которым нужно спать как можно дольше, когда нет данных для отправки, но и сохранять при этом низкую латентность (и для мыши: малый интервал соединения CI), когда необходимо.

Connection supervisory timeout (CST). Это время таймаута контроля соединения - интервал времени от последнего обмена данными, после истечению которого связь считается потерянной. Центральное устройство не будет пытаться восстановить соединение (reconnect), пока не истечет этот таймаут. Поэтому если у Вас такое периферийное устройство, которое часто перемещается, выходя время от времени за пределы расстояния для радиосвязи, то имеет смысл использовать более короткий CST.

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

В зависимости от используемой для разработки платформы могут быть специфические рекомендации или требования по значениям этих параметров. Для iOS, компания Apple предоставляет документ "Accessory Design Guidelines for Apple Devices" (https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf), в котором, помимо всего прочего, есть правила по этим параметрам.

Просто так базу данных GATT на лету менять нельзя.

По факту, если Вы поменяли базу данных, то должны для противоположного участника соединения разрешить и показать изменение характеристики службы. Причина в том, что противоположной стороне разрешено кешировать структуру базы данных, и любые изменения в этой структуре требуют повторного (частичного) считывания структуры базы данных (rediscovery). Если не отправить оповещение Service Changed, то это приведет к нарушению спецификации. Также изменение в базе данных обычно должно использоваться только тогда, когда Вы хотите повторно инициализировать устройство с новым профилем.

uint32_t sd_ble_uuid_vs_add (ble_uuid128_t const * p_vs_uuid, uint8_t * p_uuid_type);

Использование vendor specific UUID в основном заключается в выполнении двух шагов:

1. Добавьте ваш собственный базовый 128-битный идентификатор (base UUID) в стек с помощью функции sd_ble_uuid_vs_add(). Сохраните возвращенное этой функцией значение в параметре p_type вызова этой функции.

2. Установите тип всех переменных ble_uuid_t, которые должны использовать это базовое значение, возвращенное из sd_ble_uuid_vs_add(). Когда Вы установите это поле в свой собственный тип вместо BLE_UUID_TYPE_BLE, значение будет использоваться поверх custom base UUID, заданного Вами, вместо базового Bluetooth SIG.

Своим вызовом функция sd_ble_uuid_vs_add() добавит Ваш base UUID в внутреннему списку базовых UUID кода SoftDevice, и вернет индекс таблицы для этого UUID в поле p_uuid_type. Когда этот тип позже будет использоваться в ble_uuid_t later, код SoftDevice сможет найти этот базу в той же самой таблице, используя этот индекс.

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

#define BLE_UUID_NUS_SERVICE           0x0001

#define BLE_UUID_NUS_TX_CHARACTERISTIC 0x0002

#define BLE_UUID_NUS_RX_CHARACTERISTIC 0x0003

typedef struct ble_nus_s
{
  uint8_t uuid_type;   /**< Тип UUID для Nordic UART Service Base UUID. */
  ...
} ble_nus_t;

...

service_init:
  uint32_t   err_code;
  ble_uuid_t ble_uuid;
  ble_uuid128_t nus_base_uuid = {0x9E, 0xCA, 0xDC, 0x24, 0x0E, 0xE5, 0xA9, 0xE0,
                                 0x93, 0xF3, 0xA3, 0xB5, 0x00, 0x00, 0x40, 0x6E};

  // Добавление кустарного base UUID:
  err_code = sd_ble_uuid_vs_add(&nus_base_uuid, &p_nus->uuid_type);
  if (err_code != NRF_SUCCESS)
  {
    return err_code;
  }

  // Добавление службы:
  ble_uuid.type = p_nus->uuid_type;
  ble_uuid.uuid = BLE_UUID_NUS_SERVICE;

  err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
                                      &ble_uuid,
                                      &p_nus->service_handle);
  if (err_code != NRF_SUCCESS)
  {
    return err_code;
  }

  ...

char_add:
  ble_uuid.type = p_nus->uuid_type;
  ble_uuid.uuid = BLE_UUID_NUS_RX_CHARACTERISTIC;
  ...
  return sd_ble_gatts_characteristic_add(p_nus->service_handle, &char_md,
                                          &attr_char_value,
                                          &p_nus->rx_handles);

Изначально главное устройство (Central) будет соединяться с периферийным устройством (Peripheral), по своему усмотрению назначая параметры соединения. После того, как соединение установлено, Peripheral может отправить для Central запрос на обновление параметров соединения (connection parameter update request), и скорее всего Central ответит обновлением параметров соединения. Однако по спецификации стандарта Bluetooth устройство Central не обязан отвечать на запрос обновления параметров соединения, и может просто его игнорировать. Принятое обновление от Central не обязательно будет тем, что запрашивало периферийное устройство. Если периферийное устройство не может принять обновление параметра от Central, то оно может выбрать отключение (разрыв соединения с Central).

Во время процесса согласования параметров соединения к Central посылаются следующие параметры, как пример:

// Минимально допустимый интервал соединения (0.5 секунды):

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(500, UNIT_1_25_MS)

// Максимально допустимый интервал соединения (1 секунда):

#define MAX_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS)

// Латентность подчиненного устройства:

#define SLAVE_LATENCY     0

// Таймаут контроля соединения (4 секунды):

#define CONN_SUP_TIMEOUT  MSEC_TO_UNITS(4000, UNIT_10_MS)

Для интервала соединения установлен желаемый минимум и максимум, так что для устройства Central доступна некоторая гибкость в выборе интервала.

Если периферийное устройство получает обновление параметров соединения от Central, которое неприемлемо, то оно может отправить другой запрос на обновление параметров соединения к Central, чтобы заново договориться о параметрах, которые могли бы быть допустимы. Количество отправляемых запросов на обновление параметров соединения определяется константой MAX_CONN_PARAMS_UPDATE_COUNT, как это сделано в примере ble_app_hrs из SDK. Макрос FIRST_CONN_PARAMS_UPDATE_DELAY определяет, сколько времени должно пройти от начала оповещения до отправки первого запроса обновления параметров соединения, и NEXT_CONN_PARAMS_UPDATE_DELAY определяет, через какое время должны обновляться последующие запросы на обновление параметров соединения.

В примере ble_app_hrs запрос обновления параметров инициируется запуском таймера в приложении с идентификатором m_sensor_contact_timer_id. Таймер инициализируется вызовом conn_params_init() в функции main, и скорее всего запускается в обработчике события соединения.