Формат UUID используемый в Bluetooth описывается в ISO/IEC 11578. Сам UUID состоит из 2 основных частей: времени и уникального идентификатора (MAC). Если не погружаться глубоко, то см. ru.wikipedia.org/wiki/UUID
Пропустив 00000000-0000-1000-8000-00805F9B34FB через сервис www.famkruithof.net/uuid/uuidgen?typeReq=1 мы получаем первый день Григорианского календаря — Friday, October 15, 1582 at 12:00:00 AM
А последняя часть — MAC-адрес ПК на котором был сгенерирован базовый UUID. Это был HP (на момент регистрации Compaq) https://macaddress.webwat.ch/hwaddr/00:80:5F#simname.
ARM TrustZone — технология, которая позволяет исполнять критичный код в защищённой среде, собственно она поэтому и Trust Zone, что ей можно доверять. В тексте я даю ссылку на статью, где описывается принцип работы — habr.com/ru/company/dsec/blog/478948, чтобы ещё больше не увеличивать размер моей статьи.
CryptoCell — расширение ARM TrustZone, реализующее дополнительные функции аппаратно. В частности это хранилище ключей, ускорители шифрования, генератор случайных чисел, блоки проверки кода, ключей и безопасной отладки. Ссылку на официальное описание также привёл — community.arm.com/developer/ip-products/system/b/embedded-blog/posts/arm-trustzone-cryptocell-312-simplifying-the-design-of-secure-iot-systems
Nordic ответил, что вопрос важен для нескольких клиентов (в отслеживающих я уже троих насчитал) и они ждут решения от DSR.
Похоже, что Вы нашли какой-то баг, который не получается быстро поправить.
Главное, что вопрос не останется без ответа.
Nordic использует стек ZigBee от компании DSR Wireless www.dsr-zboss.com/#!/, основную часть написали, кстати наши соотечественники из Воронежа.
Поэтому можно в значительной степени сказать спасибо им.
Про ZigBee могу сказать, что практически всегда это вещь в себе, каждый затачивает её под себя. В итоге решения разных производителей между собой оказываются не совместимы, даже если формально имеют сертификаты. Поэтому в большинстве случаев от неё сейчас отходят. Больше идёт ориентация на BLE Mesh или Thread в зависимости от задачи. И там и там от SDK отзывы очень позитивные. Стек для BLE хвалят почти все, кого я встречал. Про Thread, как правило, говорят, что он проработан гораздо лучше, чем у конкурентов, несмотря на то, что база общая — OpenThread. Оба тезиса могу подтвердить на личном опыте. Поэтому крайне странно видеть комментарии подобного рода, что не работают такие очевидные вещи. Хотя не исключаю, что это в принципе это возможно. Конкретно с ZigBee я тоже опыта имел не много.
p.s. пришлите ссылку на DevZone, где Вам не отвечают. Я знаю, как их замотивировать =) Стандарт ответа — сутки. Сейчас из-за коронавируса возможно увеличение сроков, но не до таких размеров. Дело в чём-то ином.
Закрывать поддержку 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, где можно быстро собрать проект для старта разработки. Но в реальных условиях предоставляемого функционала зачастую оказывается недостаточно.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Пропустив 00000000-0000-1000-8000-00805F9B34FB через сервис www.famkruithof.net/uuid/uuidgen?typeReq=1 мы получаем первый день Григорианского календаря — Friday, October 15, 1582 at 12:00:00 AM
А последняя часть — MAC-адрес ПК на котором был сгенерирован базовый UUID. Это был HP (на момент регистрации Compaq) https://macaddress.webwat.ch/hwaddr/00:80:5F#simname.
CryptoCell — расширение ARM TrustZone, реализующее дополнительные функции аппаратно. В частности это хранилище ключей, ускорители шифрования, генератор случайных чисел, блоки проверки кода, ключей и безопасной отладки. Ссылку на официальное описание также привёл — community.arm.com/developer/ip-products/system/b/embedded-blog/posts/arm-trustzone-cryptocell-312-simplifying-the-design-of-secure-iot-systems
Похоже, что Вы нашли какой-то баг, который не получается быстро поправить.
Главное, что вопрос не останется без ответа.
Поэтому можно в значительной степени сказать спасибо им.
Про ZigBee могу сказать, что практически всегда это вещь в себе, каждый затачивает её под себя. В итоге решения разных производителей между собой оказываются не совместимы, даже если формально имеют сертификаты. Поэтому в большинстве случаев от неё сейчас отходят. Больше идёт ориентация на BLE Mesh или Thread в зависимости от задачи. И там и там от SDK отзывы очень позитивные. Стек для BLE хвалят почти все, кого я встречал. Про Thread, как правило, говорят, что он проработан гораздо лучше, чем у конкурентов, несмотря на то, что база общая — OpenThread. Оба тезиса могу подтвердить на личном опыте. Поэтому крайне странно видеть комментарии подобного рода, что не работают такие очевидные вещи. Хотя не исключаю, что это в принципе это возможно. Конкретно с ZigBee я тоже опыта имел не много.
p.s. пришлите ссылку на DevZone, где Вам не отвечают. Я знаю, как их замотивировать =) Стандарт ответа — сутки. Сейчас из-за коронавируса возможно увеличение сроков, но не до таких размеров. Дело в чём-то ином.
Относительно включения 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, где можно быстро собрать проект для старта разработки. Но в реальных условиях предоставляемого функционала зачастую оказывается недостаточно.