Nrf connect как пользоваться приложением

Обновлено: 07.01.2025

Этичный хакинг и тестирование на проникновение, информационная безопасность

Bluetooth, как мы знаем, является одной из самых популярных и широко используемых беспроводных технологий в современном мире. В связи с быстрым ростом IoT, ускоряющим развитие технологии Bluetooth, Специальная группа по интересам Bluetooth (Bluetooth Special Interest Group (SIG)) предпринимает постоянные усилия по увеличению скорости передачи с максимальным акцентом на маяки, развлечения, сферу здравоохранения и фитнес.

Примечание: IoT - «Интернет вещей», термин относится к совокупности разнообразных устройств, обычно более простых, чем персональный компьютер, которые подключены к Интернету.

Bluetooth Low Energy (BLE) является частью спецификации Bluetooth 4.0, которая также включает протоколы классического Bluetooth и протокол высокоскоростного Bluetooth (Classic Bluetooth and Bluetooth High Speed Protocols). По сравнению с классическим Bluetooth, BLE предназначен для использования меньшей мощности при сохранении аналогичного диапазона связи. BLE — это технология, которая всегда отключена и передаёт только короткие объёмы данных, когда это необходимо. Это значительно снижает энергопотребление, что делает его идеальным для использования в случаях, когда требуется постоянное долговременное соединение с низкой скоростью передачи данных. BLE идеально подходит для пульта дистанционного управления телевизором, но не для беспроводного устройства потоковой передачи мультимедиа, которому для передачи требуется большой объем данных.

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

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

Что выделяет BLE?

Обеспечивает многоплатформенную связь: может легко общаться через большое количество устройств, работающих на Android, iOS, Linux, Windows Phone, Windows 8 и OS X
Лучшая скорость сопряжения
Помогает поддерживать связь в течение более длительных периодов времени
Значительно ниже затраты на внедрение
Энергоэффективный

На бумаге BLE выглядит хорошо, а как на практике?

Это хороший вопрос с точки зрения безопасности. Дело в том, что BLE — это просто протокол. Изготовители должны безопасно внедрить BLE в своё устройство. Известно, что даже самый сильный криптографический протокол не будет работать, если генератор случайных чисел не является «достаточно случайным». То же самое относится и к BLE. Таким образом, можно сказать, что безопасность BLE лежит в руках его исполнителей.

В то время как все устройства Bluetooth с низким энергопотреблением были разработаны с основной целью улучшения взаимодействия с пользователем, безопасность заняла последнее место во время процесса?

Давайте посмотрим на три основные уязвимости, которым BLE могут подвергать своих пользователей:

Подслушивание: как следует из названия, подслушивание относится к стороннему устройству, прослушивающему данные, которыми обмениваются два сопряжённых устройства. Соединение между двумя сопряжёнными устройствами означает цепочку доверия. Цепь разрывается при удалении одного из устройств. Злоумышленник может использовать номер устройства для доступа к другим Bluetooth-устройствам. Даже если ключи шифрования/расшифровки должны были быть удалены, атакующий может офлайн брутфорсить ПИН, используя Bluetooth Sniffer (на основе идентификатора устройства). Как только PIN-код будет получен, устройство может быть легко взломано.
Атаки «человек посередине» (MITM). Атаки «человек посередине» включают стороннее устройство, имитирующее законное устройство, обманывая два легитимных устройства, заставляя их поверить в то, что они связаны друг с другом, когда на самом деле законные устройства подключены к имитатору (посреднику). Этот тип атаки позволяет злоумышленнику/имитатору получить доступ ко всем данным, которыми обмениваются устройства, а также манипулировать данными, удаляя или изменяя их, прежде чем они достигнут соответствующего устройства.
Отказ в обслуживании и Fuzzing атака. Поскольку большинство беспроводных устройств в наши дни работают на встроенных аккумуляторных батареях, эти устройства подвержены риску атак типа «отказ в обслуживании» (DoS). DoS-атаки подвергают систему частым сбоям, приводящим к полному истощению её батареи. Fuzzing атаки также приводят к сбою систем, поскольку злоумышленник может отправлять искажённые или нестандартные данные на радиомодуль устройства Bluetooth и проверять его реакцию, что в конечном итоге может сбить с толку устройство.

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

Основные понятия в BLE

В BLE есть два основных понятия.

GAP - Generic Access Profile (общий профиль доступа)
GATT - Generic Attribute Protocol (протокол общих атрибутов)

Общий профиль доступа (GAP)

Он ответственен за подключение и распространения информации о наличии устройства BLE. GAP отвечает за видимость устройства во внешнем мире, а также играет важную роль в определении того, как устройство взаимодействует с другими устройствами.

Следующие две концепции являются неотъемлемой частью GAP:

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

Центральные устройства: в основном это мобильные телефоны или гаджеты с увеличенной памятью и вычислительной мощностью.

Advertising process (обеспечение видимости устройства)

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

Периферийное устройство будет отправлять «рекламные» данные каждые 2 секунды. Если центральное устройство готово прослушать рекламные пакеты, оно ответит запросом сканирования. В ответ на этот запрос периферийное устройство отправит данные ответа сканирования. Таким образом, центральное и периферийное устройства узнают друг о друге и связывается друг с другом.

Протокол общих атрибутов (GATT)

Используя общий протокол данных, известный как протокол атрибутов, GATT определяет, как два устройства BLE обмениваются данными друг с другом, используя понятия — сервис (service) и характеристика (characteristic). Этот протокол сохраняет все сервисы и характеристики в справочной таблице с использованием 16-битных идентификаторов, как указано в Bluetooth SIG. Важно отметить, что GATT инициируется только после того, как Advertising процесс, регулируемый GAP, завершён.

Две основные концепции, которые образуют GATT

Сервисы (service)
Характеристики (characteristic)

Сервисы

Сервисы можно представить просто как шкаф, в котором может быть много ящиков, которые в свою очередь называются характеристиками. Сервис может иметь много характеристик. Каждый сервис уникален сам по себе с универсально уникальным идентификатором (UUID), который может быть размером 16 бит для официальных адаптированных сервисов или 128 бит для пользовательских сервисов.

Характеристики

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

Вот спецификации SIG для характеристик и сервисов для устройств BLE. Любое устройство BLE, которое официально приняло UUID от SIG, должно использовать идентификатор, указанный ими в своих приложениях.

Например, официальный UUID мощности передачи (TX power) в соответствии с мандатом SIG равен 0x1804.

Чтобы было наглядно, посмотрите на этот пример сервисов и характеристик конкретного устройства:

В нём «Generic Access (1800)» - это 16-битный сервис. Внутри этого сервиса, следующие 16-битные характеристики:

Ещё один 16-битный сервис это «Generic Attribute (1801)», он содержит только одну 16-битную характеристику: Service Changed (2a05).

анализ приложения для управления устройством (многие устройства имеют программы под Android)
фаззинг — ввод различных данных и наблюдение за устройством, что в нём поменялось

Как взломать Bluetooth Low Energy

Суть процесса взлома Bluetooth Low Energy можно описать следующими стадиями:

Обнаружение устройства
Считывание его сервисов и характеристик
Обнаружение среди характеристик те, которые можно перезаписать
Определение, за что отвечают характеристики
Изменить значения характеристик

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

Я покажу пример изменения BLE параметров на устройстве с помощью bettercap.

Вводим команду для включения модуля по обнаружению BLE устройств:

Чтобы вывести устройства, которые в данный момент в пределах досягаемости, выполните команду:

Для показа характеристик конкретного устройства, запустите команду следующего вида, где вместо MAC укажите MAC-адрес устройства:

К примеру, меня интересует устройство C8:DF:84:1A:9F:26:

В столбце Properties вы увидите свойства данной характеристики, они могут быть:

READ (чтение)
WRITE (запись) — то есть возможно изменение данной характеристики
NOTIFY (уведомление)
INDICATE (индикатор)

В колонке Data присутствует текущее значение характеристики, либо дополнительная информация, например:

Для записи данных HEX_DATA в BLE устройство с указанным MAC адресом, в характеристику с идентификатором UUID:

Чтобы знать, что именно записывать, нужно понимать, за что отвечают характеристики. Вот пример значений для моего устройства — это электрическая зубная щётка Oral-B Genius 9000 (кстати, рекомендую). Значение характеристик я нашёл в Интернете.

Исследование и взлом Bluetooth Low Energy (BLE) с телефона

Поскольку на всех современных телефонах имеется Bluetooth, то вы можете использовать приложения для работы с Bluetooth Low Energy (BLE) окружающих устройств на телефоне.

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

Просмотр сервисов устройства:

Просмотр свойств характеристик:

Редактирование значений характеристик:

Работа с Bluetooth Low Energy (BLE) в Linux

Конечно, в Linux можно работать с устройствами, поддерживающими BLE, напрямую, без таких программ как Bettercap.

К сожалению, этот аспект довольно запутанный. В Debian и производных программы для работы с Bluetooth Low Energy собраны в пакете bluez. В Arch Linux и производных, пакет bluez также имеется, но утилиты, которые нас интересуют, помещены в пакет bluez-utils. Но не это самая большая проблема.

После очередного обновления утилит bluez, авторы вдруг признали многие важные программы «устаревшими», а именно устаревшими объявлены:

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

Была составлена такая таблица замены:

Устаревший инструмент	Самая подходящая замена
gatttool	btgatt-client, D-Bus Gatt API
hciattach	btattach
hciconfig	btmgmt (и bluetoothctl?)
hcidump	btmon (и btsnoop)
hcitool	отсутствует, доступно в D-Bus Device API
rfcomm	отсутствует, реализовано в D-Bus Profile1 API?
ciptool	отсутствует, реализовано в D-Bus Profile1 API?
sdptool	отсутствует, кажется, что функциональность разбросана по разным объектам D-Bus: Profile, Advertising, и массивы UUIDs в device и adapter.

Слова «отсутствует» не вселяют уверенности. По этой причине для Debian и производных этот пакет компилируется с ключом --enable-deprecated, а на Arch Linux в дополнении к пакету bluez-utils, доступному в стандартных репозиториях, в AUR имеется пакет bluez-utils-compat, в котором тоже включены устаревшие инструменты.

В относительно свежих инструкциях, для взаимодействия с Bluetooth Low Energy используются утилиты:

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

Если запустить программу btmgmt:

И в ней выполнить команду:

То она выведет список обнаруженных устройств:

Будут выведены как BLE, так и обычные Bluetooth устройства.

Также умеет искать BLE устройства, если ввести:

С помощью команды connect можно подключиться к устройству, для этого нужно указать его MAC-адрес:

Информация по устройству:

Если перейти в меню GATT:

То можно получить список характеристик:

А также перезаписать характеристики устройства.

Для получения информации по отдельным характеристикам:

Ещё одна программа, которая выведет сразу все характеристики устройства — btgatt-client. Например, выполним подключение и посмотрим характеристики устройства с MAC C8:DF:84:1A:9F:26:

В дополнении к рассмотренным программам, в отдельной консоли можно запустить Bluetooth monitor:

Как и полагается программе-монитору, она будет выводить множество информации о происходящем с Bluetooth и об обнаруженных устройствах.

Заключение

Системные утилиты Linux для работы с Bluetooth заслуживают более внимательного изучения — с их помощью можно узнать более подробную информацию о своей системе и сделать тонкую настройку Bluetooth адаптера.

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

Для начала необходимо скачать из Google Play приложение nRF Connect.

После установки открываем приложение и заходим во вкладку "Scanner":

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

Как видите, мы нашли некоторое количество устройств. Здесь есть устройство Jbl Xtreme - это колонка, которую мы хотим взломать. Учтите, что название колонки так будет отображаться не всегда. Иногда придется действовать наугад. Нажимаем на три точки и ищем пункт "Bond".

В случае успеха устройство появится во вкладке "Bonded".

Пробуем нажать "Connect"

И у нас все получилось, взлом прошел и телефон предложил подключиться.

Можно включать свою музыку. Также возможно придётся зайти в настройки блютуза телефона, если у вас старая версия Андроида или плохая прошивка, и найти там Previously connected devices (Ранее подключенные устройства или что-то подобное, может отличаться на телефонах) и оттуда произвести подключение к колонке.

nRF Connect for Mobile
версия: 4.24.3

Последнее обновление программы в шапке: 08.10.2020

Краткое описание:
Сканирование и обнаружение ваших Bluetooth Low Energy (BLE) устройств

Описание:
nRF Connect for Mobile is a powerful generic tool that allows you to scan, advertise and explore your Bluetooth low energy (BLE) devices and communicate with them. nRF Connect supports number of Bluetooth SIG adopted profiles together with Device Firmware Update profile (DFU) from Nordic Semiconductors and Mcu Manager on Zephyr and Mynewt.

Требуется Android: 4.3+
Русский интерфейс: Нет

04.12.2018 - version 4.22.0
- Dark Theme.
- A lot of fixes here and there

30.10.2018 - version 4.21.0
- Reading and requesting PHY now available with Macros and Automated Tests (AT)
- Reliable Write support added in UI, Macros and AT
- AT fixed on Android 8+
- Requesting Connection Priority has now timeout attribute in AT
- DFU Library 1.8.0
- Minor bugs fixed

На прошедшей неделе Nordic Semiconductor добавил поддержку серии nRF52 в nRF Connect SDK.

Основной вопрос, который возникает у большинства — что это такое и главное зачем? Особенно актуален этот вопрос для тех, кто имеет опыт работы с nRF5 SDK, а их не мало.

Сразу отмечу, что статья в первую очередь написана для тех, кто использует традиционные подходы в разработке встраиваемых (embedded) устройств уровня Cortex-M или близких. Поэтому некоторые определения и аналогии могут показаться не полностью корректными с точки зрения тех, кто работает на высоком уровне (смотрит на происходящее со стороны Linux), но так будет проще понять тем, кто только начинает этот путь.

Комментарии и уточнения всегда приветствуются.

Немного про то кто такие Nordic и как у них всё хорошо сейчас

Системы на кристалле от Nordic пользуются заслуженным авторитетом у многих. Например, среди отечественных компаний, выпускающих устройства с Bluetooth Low Energy, порядка 90% используют их в своих устройствах. В качестве примеров успеха можно привести производителей автомобильных сигнализаций: Starline, Pandora, Scher-Khan в последних поколениях используют именно их. Ещё одним крупным примером успешного применения является компания Redmond, они же Ready4Sky. Свои умные мультиварки и прочую бытовую технику они делают также на этих чипах. За прошедший год количество выпущенных устройств приближается к 2 миллионам только на отечественный рынок.

Да и по миру Nordic Semiconductor имеет долю 40%, в 2.5 раза больше, чем у ближайшего конкурента (TI). См, квартальные отчёты. Даже такие гиганты, как Samsung и Xiaomi используют чипы Nordic в своих продуктах, несмотря на то, что имеют аналогичных решения на базе собственных чипов.

Тут же можно отметить, что не только гиганты используют Nordic, но компании поменьше, а также любители часто используют их в своих устройствах. С этой точки зрения серию nRF5x можно назвать STM для беспроводки (ожидаю обсуждения в комментариях).

Основными причинами успеха являются:

Высокое качество кода и документации
Отличная техническая поддержка (особенно на фоне альтернативных решений от других производителей)
Большое количество примеров в SDK
Простая схема (встроенный балун и минимальный обвес)
Готовые проекты Altium для разводки радиочасти
Конкурентная цена

Здесь же встаёт главный вопрос, зачем был выпущен новый SDK и чем он отличается от текущего? Если так всё хорошо у текущего решения.

Текущий nRF5 SDK работает на базе простой очереди, и в большинстве случаев этого оказывается достаточно для реализации почти любой задачи (хотя, некоторые компании используют всё же свои SDK, но это исключения из правил). В новой nRF Connect SDK используется кардинально иной подходит на базе RTOS Zephyr. Рассмотрим отличия подробнее.
RTOS (ОСРВ) несут в себе, как определённые плюсы, так и известные недостатки. К последним можно отнести:

дополнительные накладные расходы на поддержание ОС
большая сложность разработки на простых проектах
повышенная сложность сборки

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

С этой точки зрения можно сравнить переход на Zephyr с появлением первых массовых ARM Cortex-M и переходом на 32 бита. Сейчас же большинство используют 32-битные МК в качестве основных, о чём есть статья на Хабре. В ней же рассказывается про переход, который первоначально казался излишне сложным. Но, со временем практически все пришли к тому, что это стало стандартом.

Стоит отметить, что Zephyr OS не является единственной RTOS работающей на чипах Nordic. Примеры проектов с FreeRTOS доступны в с SDK v.11 начиная с 2016 года, а ещё раньше в SDK v.9 была поддержка Keil RTX для семейства nRF51 (2015 год). Однако, ранее это были скорее экспериментальные функции и поддержка предоставлялась в большей степени со стороны производителей RTOS. Что в принципе верно и сейчас.

Неофициальная поддержка Zephyr для семейств nRF5x появилась ещё в 2016 году.

Полностью же сделать новый SDK на ОСРВ Zephyr Nordic решил только сейчас.

Для этого есть ряд предпосылок:

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

ориентация на снижение размера конечного файла
удобная конфигурация под проект
оптимизированная под скорость сборки

Позволяет снизить издержки, как самой Nordic, так и конечным разработчикам

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

Рассмотрим версию разработки на Windows, так как именно она вызовет больше вопросов, относительно тех, кто привык к разработке на Linux.

Необходимы следующие пакеты:

Chocolatey (менеджер пакетов)
Git (система контроля версий)
Ninja (система сборки ориентированная на скорость)
CMake (высокоуровневая система сборки)
DTC-MSYS2 (система сборки дерева устройств(device tree))
GPerf (генаратор хеш)
west (позволяет работать с несколькими репозитариями из одной папки и конфигурационного файла)
pip (менеджер пакетов Python)
Python3
GNU Arm Embedded Toolchain (GCC, GDB для встраиваемых систем от самой ARM)

Например, Chocolatey и pip позволяют установить все необходимые пакеты через консоль для ОС и Python соответственно. Причём сам Python, как и большинство рассматриваемого ПО ставится одной командой:

Обновляется также одной командой:

Подход немного не привычен для пользователей Windows, для тех же, кто знаком с консольными менеджерами пакетов в Linux (apt, zypper и т.п.) ничего нового. Не раз замечал ситуацию, что разработчики ПО для МК обновляют софт, лишь при переустановке ОС на ПК. Про то, почему это плохо мы говорить не будем, отмечу лишь, что здесь это задача решается автоматически.

Гораздо более интересны нововведения в области конфигурации и сборки проектов.

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

Cmake в свою очередь позволяет генерировать конфигурационные файлы для Ninja на высокоуровневом (скриптовом) языке под платформу на которой будет происходить сборка. Про Cmake можно почитать на Хабре, например, тут, тут и тут,
GPerf генерирует таблицу указателей, что позволяет сэкономить память, см. 3 стадию сборки ниже.

Отдельно стоит обратить внимание на новый подход к описанию железа. Появились Devicetree, описывающие аппаратную структуру устройства. Это является прямым следствием поддержки Zephyr силами Linux Foundation.

Плюсы заключаются в том, что теперь аппаратное описание вынесено в отдельный .dts файл, который имеет простую стуктуру, его легко модифицировать, и, как следствие, портировать код между разными семействами чипов.
В качестве примера насколько всё наглядно приведу базовый dtsi на nRF52840, который в свою очередь используются в описании платы nRF52840-DK nrf52840dk_nrf52840.dts
Количество плат поддерживаемых Zephyr уже сейчас более 200.

Как было сказано ранее, Nordic впервые выпустил Zephyr на nRF91 серии, потом на nRF53, и сейчас он наконец добрался до наиболее массовой nRF52.

Переход на RTOS позволяет в свою очередь решить проблему адаптации кода под новое железо. Даже среди чипов одного семейства переход требовал определённых ресурсов со стороны разработки, если сопровождался переходом на другой softdevice (предкомпилированную библиотеку BLE). Не говоря уже про переход, например с 51 или 91 серии на 52, когда значительно меняется сама аппаратная платформа. Сейчас же эта задача будет решаться гораздо проще и быстрее.

Железо у Nordic постоянно совершенствуется, но об этом необходимо писать отдельно. В рамках этой статьи можно лишь отметить, что ставка делается на интеграцию с RTOS, безопасность, энергоэффективность и улучшение радиоканала (BLE 5.2). Спасибо можно сказать двухядерным Cortex-M33, ARM Cryptocell и ARM TrustZone

Для сборки devicetree используется Device Tree Compiler, входящий в состав MSYS2 (улучшенная система сборки на базе Cygwin и MinGW-64).

Вторая часть конфигурации проекта находится в KConfig (Kernel config), который также был наследован из Linux. Он позволяет через графический интерфейс выбрать необходимые блоки и задать параметры для сборки под конкретную задачу, что особо актуально в условиях ограниченных ресурсов систем на кристалле.

Можно использовать традиционные утилиты типа menuconfig или же в рамках Segger Embedded Studio (официальной рекомендованной IDE) есть встроенный интерфейс, который запускается через соответствующий пункт в меню: Project > Configure nRF Connect SDK Project

Пример конфигурации проекта с SSL/TLS на базе nRF9160 представлен ниже. Как видно в нём можно настроить как аппаратные особенности проекта (платформу, количество потоков, подключаемые модули ядра), так и программные (ключи, адреса и т.п.).

Рассмотрим стадии сборки проекта: Всего их пять:

Конфигурация — предварительная обработка всех конфигов (devicetree, KConfig), на выходе получаем заголовочные файлы описывающие железо и конфиг для Ninja
Предварительная сборка (I) — обработка структур на высоком уровне, компиляция системных файлов и смещений (offset), создание таблиц вызовов
Первоначальная сборка (II) — компиляция основных исходных кодов и упаковка их в архивы, линковка
Окончательная сборка (III) — на этом этапе достигается снижение требуемого объёма памяти за счёт хешей индексов (GPerf), дополнительные скрипты линковщика также могут быть обработаны здесь
Пост-обработка (IV) — генерация hex, bin файлов

Напрямую сравнивать результаты работы программ, созданных на двух SDK нельзя. Так как библиотеки и подходы очень сильно отличаются и пока нет подобных тестов. Определённо можно сказать, что решение хорошо себя ощущает на средних и топовых чипах в линейке (nRF52832 и выше), остаётся большой запас по ресурсам. При этом нельзя сказать, что новый SDK не применим на младших чипах типа nRF52810. Необходимо рассматривать задачу более детально.

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

Update: 14 Мая Nordic провёл вебинар про новый SDK в котором озвучил, что все версии BLE старше 5.0 будут доступны только в nRF Connect SDK. Соответственно Directino Finding aka AoA/AoD (BLE 5.1) и LE Audio (BLE 5.2), которые многие ждут, принесут с собой новый инструментарий уже в этом году и изменения в разработке наступят раньше, чем предполагалось.

Читайте также: