На прошедшей неделе Nordic Semiconductor добавил поддержку серии nRF52 в nRF Connect SDK.
Основной вопрос, который возникает у большинства — что это такое и главное зачем? Особенно актуален этот вопрос для тех, кто имеет опыт работы с nRF5 SDK, а их не мало.
Сразу отмечу, что статья в первую очередь написана для тех, кто использует традиционные подходы в разработке встраиваемых (embedded) устройств уровня Cortex-M или близких. Поэтому некоторые определения и аналогии могут показаться не полностью корректными с точки зрения тех, кто работает на высоком уровне (смотрит на происходящее со стороны Linux), но так будет проще понять тем, кто только начинает этот путь.
Комментарии и уточнения всегда приветствуются.
Здесь же встаёт главный вопрос, зачем был выпущен новый SDK и чем он отличается от текущего? Если так всё хорошо у текущего решения.
Текущий nRF5 SDK работает на базе простой очереди, и в большинстве случаев этого оказывается достаточно для реализации почти любой задачи (хотя, некоторые компании используют всё же свои SDK, но это исключения из правил). В новой nRF Connect SDK используется кардинально иной подходит на базе RTOS Zephyr. Рассмотрим отличия подробнее.
RTOS (ОСРВ) несут в себе, как определённые плюсы, так и известные недостатки. К последним можно отнести:
В остальном же ОСРВ несут:
В рамках Nordic это интересно и актуально стало с тех пор, когда появились новые system in package (SIP) c LTE Cat-M/NB-IoT/GPS — серия nRF91. У этой SIP выше производительность за счёт нового ядра Cortex-M33 и иные требования к сетевой составляющей, появившейся из-за перехода от BLE к сетям сотовой связи. Ещё одним нововведением здесь стал SDR модем, который работает на отдельном ядре и с которым требовалось организовать межядерное взаимодействие. Впервые SDK на базе RTOS появился именно здесь, и для тех, кто впервые сталкивался с новым подходом, он вызвал ряд вопросов, уже начиная с этапа подготовки. Был даже выпущен специальный ассистент по правильной сборке среды разработки — Getting Started Assistant. Он подсказывает, какие компоненты необходимо установить (их немало, см. ниже), и проверяет, что всё установлено верно.
С этой точки зрения можно сравнить переход на 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 решил только сейчас.
Для этого есть ряд предпосылок:
Для понимания, насколько кардинальные изменения произошли, хорошо подходит структурная схема из официальной документации. Серым отмечены компоненты являющиеся частью Zephyr.
На практике при реализации данного подхода возникает ряд проблем когнитивного свойства. Разработчики, привыкшие к продукту и решениям испытывают диссонанс при большом количестве изменений.
Рассмотрим версию разработки на Windows, так как именно она вызовет больше вопросов, относительно тех, кто привык к разработке на Linux.
Необходимы следующие пакеты:
Тому, кто в первый раз сталкивается с подобным набором утилит, может показаться, что всё излишне усложнено и можно было использовать старую парадигму, что существующие подходы к разработке достаточно эффективны. Однако, если разобраться глубже, то всё становится гораздо интереснее.
Например, 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 представлен ниже. Как видно в нём можно настроить как аппаратные особенности проекта (платформу, количество потоков, подключаемые модули ядра), так и программные (ключи, адреса и т.п.).
Рассмотрим стадии сборки проекта: Всего их пять:
Подробнее про систему сборки Zephyr с картинками можно прочитать в официальной документации. Текста и картинок и так достаточно много, поэтому не будем рассматривать детали в рамках этой статьи.
Важно понимать, что инструменты использующиеся здесь не являются заменой для препроцессора C (cpp) и линковщика C (ld). И тот и другой используются на всех этапах кроме постобработки. Однако, результат их работы подвергается дополнительным усовершенствованиям, которые позволяют, как значительно снизить время сборки, так и требования к памяти.
Напрямую сравнивать результаты работы программ, созданных на двух SDK нельзя. Так как библиотеки и подходы очень сильно отличаются и пока нет подобных тестов. Определённо можно сказать, что решение хорошо себя ощущает на средних и топовых чипах в линейке (nRF52832 и выше), остаётся большой запас по ресурсам. При этом нельзя сказать, что новый SDK не применим на младших чипах типа nRF52810. Необходимо рассматривать задачу более детально.
Возвращаясь к вопросу выведенному в название статьи, можно сказать, что эта парадигма — определённо новая реальность. Которая на первый взгляд несёт значительные улучшения. Как минимум 2 новых семейства чипов у крупнейшего производителя BLE в мире работают именно и только на этой технологии и возврата назад не предвидится. На мой взгляд это — революция, которую готовили заранее.
Выводы:
Основной вопрос, который возникает у большинства — что это такое и главное зачем? Особенно актуален этот вопрос для тех, кто имеет опыт работы с 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 для беспроводки (ожидаю обсуждения в комментариях).
Основными причинами успеха являются:
Можно сказать, что Nordic Semiconductor даёт всё для лёгкого и быстрого старта.
Да и по миру Nordic Semiconductor имеет долю 40%, в 2.5 раза больше, чем у ближайшего конкурента (TI). См, квартальные отчёты. Даже такие гиганты, как Samsung и Xiaomi используют чипы Nordic в своих продуктах, несмотря на то, что имеют аналогичных решения на базе собственных чипов.
Тут же можно отметить, что не только гиганты используют Nordic, но компании поменьше, а также любители часто используют их в своих устройствах. С этой точки зрения серию nRF5x можно назвать STM для беспроводки (ожидаю обсуждения в комментариях).
Основными причинами успеха являются:
- Высокое качество кода и документации
- Отличная техническая поддержка (особенно на фоне альтернативных решений от других производителей)
- Большое количество примеров в SDK
- Простая схема (встроенный балун и минимальный обвес)
- Готовые проекты Altium для разводки радиочасти
- Конкурентная цена
Можно сказать, что Nordic Semiconductor даёт всё для лёгкого и быстрого старта.
Здесь же встаёт главный вопрос, зачем был выпущен новый SDK и чем он отличается от текущего? Если так всё хорошо у текущего решения.
Текущий nRF5 SDK работает на базе простой очереди, и в большинстве случаев этого оказывается достаточно для реализации почти любой задачи (хотя, некоторые компании используют всё же свои SDK, но это исключения из правил). В новой nRF Connect SDK используется кардинально иной подходит на базе RTOS Zephyr. Рассмотрим отличия подробнее.
RTOS (ОСРВ) несут в себе, как определённые плюсы, так и известные недостатки. К последним можно отнести:
- дополнительные накладные расходы на поддержание ОС
- большая сложность разработки на простых проектах
- повышенная сложность сборки
В остальном же ОСРВ несут:
- повышенную надёжность за счёт контроля отдельных потоков
- более лёгкое взаимодействие между большим количество одновременно работающих потоков на крупных проектах
- большую независимость кода от аппаратной платформы
- масштабируемость и переносимость
В рамках Nordic это интересно и актуально стало с тех пор, когда появились новые system in package (SIP) c LTE Cat-M/NB-IoT/GPS — серия nRF91. У этой SIP выше производительность за счёт нового ядра Cortex-M33 и иные требования к сетевой составляющей, появившейся из-за перехода от BLE к сетям сотовой связи. Ещё одним нововведением здесь стал SDR модем, который работает на отдельном ядре и с которым требовалось организовать межядерное взаимодействие. Впервые SDK на базе RTOS появился именно здесь, и для тех, кто впервые сталкивался с новым подходом, он вызвал ряд вопросов, уже начиная с этапа подготовки. Был даже выпущен специальный ассистент по правильной сборке среды разработки — Getting Started Assistant. Он подсказывает, какие компоненты необходимо установить (их немало, см. ниже), и проверяет, что всё установлено верно.
С этой точки зрения можно сравнить переход на 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 решил только сейчас.
Для этого есть ряд предпосылок:
- Ряд технологий наследуется из Linux:
- работа с потоками, очередями в режиме реального времени (особо важно для времязависимых протоколов типа BLE)
- библиотеки для работы с сетью и безопасностью
- гибкая модель аппаратного описания с оптимизацией на энергопотребление
- библиотеки для работы с периферией (датчиками и т.п.)
- Гибкая система сборки:
- ориентация на снижение размера конечного файла
- удобная конфигурация под проект
- оптимизированная под скорость сборки
- Унификация кода за счёт абстракции от железа
- Позволяет снизить издержки, как самой Nordic, так и конечным разработчикам
- Поддержка от крупного сообщества (код тестируется и аппробируется другими проектами через репозитарии)
- Переход на новый (более высокий) уровень разработки позволяет расширить количество программистов работающих на платформе. Не самый очевидный пункт, но нельзя не отметить тенденцию, что низкоуровневых программистов становится всё меньше.
Для понимания, насколько кардинальные изменения произошли, хорошо подходит структурная схема из официальной документации. Серым отмечены компоненты являющиеся частью Zephyr.
На практике при реализации данного подхода возникает ряд проблем когнитивного свойства. Разработчики, привыкшие к продукту и решениям испытывают диссонанс при большом количестве изменений.
Рассмотрим версию разработки на 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, как и большинство рассматриваемого ПО ставится одной командой:
сhoco install python xxxОбновляется также одной командой:
choco upgrade allПодход немного не привычен для пользователей 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 файлов
Подробнее про систему сборки Zephyr с картинками можно прочитать в официальной документации. Текста и картинок и так достаточно много, поэтому не будем рассматривать детали в рамках этой статьи.
Важно понимать, что инструменты использующиеся здесь не являются заменой для препроцессора C (cpp) и линковщика C (ld). И тот и другой используются на всех этапах кроме постобработки. Однако, результат их работы подвергается дополнительным усовершенствованиям, которые позволяют, как значительно снизить время сборки, так и требования к памяти.
Напрямую сравнивать результаты работы программ, созданных на двух SDK нельзя. Так как библиотеки и подходы очень сильно отличаются и пока нет подобных тестов. Определённо можно сказать, что решение хорошо себя ощущает на средних и топовых чипах в линейке (nRF52832 и выше), остаётся большой запас по ресурсам. При этом нельзя сказать, что новый SDK не применим на младших чипах типа nRF52810. Необходимо рассматривать задачу более детально.
Возвращаясь к вопросу выведенному в название статьи, можно сказать, что эта парадигма — определённо новая реальность. Которая на первый взгляд несёт значительные улучшения. Как минимум 2 новых семейства чипов у крупнейшего производителя BLE в мире работают именно и только на этой технологии и возврата назад не предвидится. На мой взгляд это — революция, которую готовили заранее.
Выводы:
- Изменения радикальны, код работающий с текущим nRF5 SDK получается не совместимым с новым (nRF Connect SDK)
- Переход на RTOS c Devicetree и KConfig позволяет получить дополнительный уровень абстракции для железа, что в свою очередь значительно ускоряет разработку и перенос проекта на новую платформу
- Переход на Zephyr несёт с собой поддержку большого количества протоколов и библиотек из коробки, для устройств интернета вещей наиболее интересны функции работы с сетью и безопасностью, где традиционно силён Linux
- Zephyr OS использует при сборке ряд инструментов, которые позволяют значительно сократить время сборки и требования к памяти, что особо актуально для встраиваемых применений
- Новый SDK позволяет использовать более высокоуровневых разработчиков, которых на рынке, гораздо больше, чем низкоуровневых. Тем самым решается вопрос кадров и увеличении доли рынка.
Lebets_VI
— большая сложность разработки на простых проектах
— повышенная сложность сборки
вот этим они могут и ответнуть от себя разработчиков если вообще перейдут на Connect SDK и закроют обычный SDK.
Им пока не нужно было включать в поддержку этим SDK чипов nRF52 и nRF53 (даже с учетом того, что у 53го 2 ядра), ну а 9-ка уже достаточно серьезная серия и в обычный SDK нордик уже бы не влез.
А то получается что с TI с их 2х ядерными 13-ми и 26-ми уже легче работать чем с этим «Connect SDK».
Про STM32WB55 я вообще молчу, они умудрились реализовать очень легкий SDK с учетом того, что там тоже 2 ядра.
Sinopteek Автор
Закрывать поддержку nRF5 SDK для существующих проектов Nordic не планирует. За это можно не волноваться. Они даже nRF9E5 до сих пор поддерживают, несмотря на то, что найти на сайте его не просто.
Относительно включения 52 семейства — никто не заставляет переходить новый SDK. Стоит рассматривать это сейчас скорее, как реализацию возможности запуска кода с 91 и 53 семейств на младших семействах. Тем, кто уже сделал проект на новом подходе, может быть интересно перенести его части в новых проектах на более слабые и дешёвые чипы.
Также отмечу, что nRF53 аппаратно ближе к nRF91, так как что проще было реализовать на новом SDK. Здесь всё логично.
Относительно того на чём работать легче — это выбор конкретного разработчика и совокупность его привычек. О чём собственно и статья.
От себя могу отметить, что с CC13xx/CC26xx знаком ещё с момента когда они только ещё появились (Preview были в 2014) и с ними развлечений предостаточно. Если тебе нужно запустить что-то простое, то всё работает до того момента, когда нужно расширить функционал или что-то более-менее серьёзно поправить. Также отмечу, что два ядра СС13xx/CC26xx, равно, как и у ST32WB55 — фиктивные. Для пользователя доступно только одно ядро, другое же является вспомогательным и не доступно для исполнения пользовательского кода. По сути на нём крутится радиостек и ты вызываешь функции для обработки радио. С этой точки зрения это прямые конкуренты nRF52, который использует такую же архитектуру, но не говорит, что у него 2 ядра. Cortex-M33 с его 2 настоящими ядрами — принципиального другая история. Сравнивать с ST и TI их можно будет, когда у них появятся аналогичные решения.
Про WB55 могу сказать, что их решение заметно отстаёт, как от Nordic, так и TI. Ответы на вопросы к последнему семинару (декабрь 2019) Компэла это прямо показали. Причём проблемы именно софтовые. Если железо сделано на уровне, то в плане ПО они традиционно выпустили Cube с GUI, где можно быстро собрать проект для старта разработки. Но в реальных условиях предоставляемого функционала зачастую оказывается недостаточно.
Lebets_VI
Не соглашусь, что 2 ядра у TI и у STM фиктивные. Наоборот — они перенесли на второе ядро работу стека и теперь первое ядро работает только с пользовательским кодом (ну еще хост-часть стека), что существенно увеличило производительность приложений, работающих на первом ядре.
Поскольку требования к ресурсам постоянно растут и одному ядру уже трудно справляться одновременно и с работой стека и с работой приложения.
Это теперь и нордик в 53 серии сделал. (Кстати у nRF52 одно ядро). Нордик только объявил что второе ядро можно программировать отдельно, тем самым говоря, что если у вас какое ни будь мелкое приложение, то можно обойтись только вторым камнем.
Что касается WB, согласен, пока решение отстает, но они постоянно работают над улучшением, а как по мне, так я все настройки БТ пишу руками и не надеюсь на КУБ, т.к. КУБ предначен для первичной настройки, для готовых сервисов и для быстрого вхождения.
Решения нордика мне очень нравятся, но и STM понравился тем, что один раз залив стек, ты забываешь о нем и полностью погружаешься в написание аппликухи.
А возьмите Cypress, где стек вообще интегрируется в аппликуху при сборке, а еще настройки стека дефайнами, что-то неправильно изменил и ничего не работает, вот там реально пипец :).