Comments 13
UFO just landed and posted this here
Закрывать поддержку 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, где можно быстро собрать проект для старта разработки. Но в реальных условиях предоставляемого функционала зачастую оказывается недостаточно.
Относительно включения 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, где можно быстро собрать проект для старта разработки. Но в реальных условиях предоставляемого функционала зачастую оказывается недостаточно.
А что с энергопотреблением при использовании Zephyr? При использовании FreeRTOS оно довольно прилично увеличивалось.
Основными причинами успеха являются:
Высокое качество кода и документации
Отличная техническая поддержка (особенно на фоне альтернативных решений от других производителей)
Большое количество примеров в SDK
Был небольшой опыт работы с nrf52840 и Zigbee — честно говоря, не очень разделяю перечисленное в цитате.
Код местами так себе, с явными ошибками в примерах, из-за чего не работает некоторый базовый функционал. Например, не обрабатываются нажатия некоторых юзерских кнопок, из-за того, что функция проверки нажатия кнопки для очистки памяти сбрасывает состояние пина на дефолтное. Как можно было не заметить, что не работают кнопки в примерах я прям не знаю.
Документация по зигби ужасная, шаг влево-вправо от стандартных лампочки и кнопочки — сиди самостоятельно разбирайся с исходниками, декомпили зигбишную (закрытую, кстати) либу, пробуй, экспериментируй, гугли и так далее. Отсылки к збоссовским примерам типа «See also DR-TAR-TC-02 sample», которых, конечно же, нет в сдк от нордика — это вообще издевательство.
Большое количество примеров в SDK — явно не про зигби. Примеров мало и там буквально самый-самый базовый функционал зигби.
Про отличную техническую поддержку (которая сама свой же форум технической поддержки починить не может и открыто признаёт, что он глючит) могу сказать лишь то, что они не могут ответить ничего по существу на мой вопрос про не работающие подписки на атрибуты вот уже две недели.
А так — да, первое впечатление от нордиков было на уровне щенячьего восторга :) Какие прекрасные примеры лампочки и кнопочки, какой крутой чип по даташитам, как всё просто в коде относительно зигбишных примеров от TI :)
Nordic использует стек ZigBee от компании DSR Wireless www.dsr-zboss.com/#!/, основную часть написали, кстати наши соотечественники из Воронежа.
Поэтому можно в значительной степени сказать спасибо им.
Про ZigBee могу сказать, что практически всегда это вещь в себе, каждый затачивает её под себя. В итоге решения разных производителей между собой оказываются не совместимы, даже если формально имеют сертификаты. Поэтому в большинстве случаев от неё сейчас отходят. Больше идёт ориентация на BLE Mesh или Thread в зависимости от задачи. И там и там от SDK отзывы очень позитивные. Стек для BLE хвалят почти все, кого я встречал. Про Thread, как правило, говорят, что он проработан гораздо лучше, чем у конкурентов, несмотря на то, что база общая — OpenThread. Оба тезиса могу подтвердить на личном опыте. Поэтому крайне странно видеть комментарии подобного рода, что не работают такие очевидные вещи. Хотя не исключаю, что это в принципе это возможно. Конкретно с ZigBee я тоже опыта имел не много.
p.s. пришлите ссылку на DevZone, где Вам не отвечают. Я знаю, как их замотивировать =) Стандарт ответа — сутки. Сейчас из-за коронавируса возможно увеличение сроков, но не до таких размеров. Дело в чём-то ином.
Поэтому можно в значительной степени сказать спасибо им.
Про ZigBee могу сказать, что практически всегда это вещь в себе, каждый затачивает её под себя. В итоге решения разных производителей между собой оказываются не совместимы, даже если формально имеют сертификаты. Поэтому в большинстве случаев от неё сейчас отходят. Больше идёт ориентация на BLE Mesh или Thread в зависимости от задачи. И там и там от SDK отзывы очень позитивные. Стек для BLE хвалят почти все, кого я встречал. Про Thread, как правило, говорят, что он проработан гораздо лучше, чем у конкурентов, несмотря на то, что база общая — OpenThread. Оба тезиса могу подтвердить на личном опыте. Поэтому крайне странно видеть комментарии подобного рода, что не работают такие очевидные вещи. Хотя не исключаю, что это в принципе это возможно. Конкретно с ZigBee я тоже опыта имел не много.
p.s. пришлите ссылку на DevZone, где Вам не отвечают. Я знаю, как их замотивировать =) Стандарт ответа — сутки. Сейчас из-за коронавируса возможно увеличение сроков, но не до таких размеров. Дело в чём-то ином.
devzone.nordicsemi.com/f/nordic-q-a/59648/zigbee-unable-to-subscribe-to-attributes-and-or-receive-reports-on-device-with-multiple-endpoints
У меня сложилось впечатление, что они как раз передали мой «вопрос» в dsr/zboss, поэтому и не отвечают :)
У меня сложилось впечатление, что они как раз передали мой «вопрос» в dsr/zboss, поэтому и не отвечают :)
Nordic ответил, что вопрос важен для нескольких клиентов (в отслеживающих я уже троих насчитал) и они ждут решения от DSR.
Похоже, что Вы нашли какой-то баг, который не получается быстро поправить.
Главное, что вопрос не останется без ответа.
Похоже, что Вы нашли какой-то баг, который не получается быстро поправить.
Главное, что вопрос не останется без ответа.
По стеку BLE большая претензия по поддержке LE coded PHY, эта функциональность до сих пор в стадии альфы и примеров нет в SDK.
Thread_and_Zigbee не смотрел, небольшой опыт с базовым nrf5_sdk_16 и примерами глюков не видать пока
Sign up to leave a comment.
Что несёт новый nRF Connect SDK для Nordic? Эволюция, революция или альтернатива?