[Nesterenko 0]

Действительно, версии 2004 и 2006 года несовместимы, но первую версию уже можно сбрасывать со счетов и относиться к ней как черновой. А что вы имеет в виду под несовместимостью реализаций ZigBee разных производителей чипов? Сами приемопередатчики несовместимы, т.е. на уровне 802.15.4? Или программные стеки ZigBee несовместимы?

 

Я имею ввиду реализации стека различными производителями. На аппаратном уровне все ОК.

 

Думаю, что скоро или уже в стоимость всех приемопередатчиков стандарта 802.15.4 заложены эти отчисления, поэтому вам все равно придется платить независимо от того, используете вы ZigBee или написали что-то свое собственное.

 

Не стоит мешать в одну кучу 802.15.4 и Zigbee Вы можете купить приемопередатчик 802.15.4 и использовать протокол написанный производителем этих чипов (только не Zigbee) или писать свой собственный. А если решили делать устройство на Zigbee то будьте добры производить отчисления с каждого устройства (к примеру у Frescale есть MC13201 и MC13202 первый приемопередатчик только для 802.15.4 а второй можно использовать дял 802.15.4 и Zigbee)

 

Отчасти согласен, но такая ситуация практически всегда, а не только с ZigBee. Только что вы предлагаете?

Я просто предостерегаю человека, что-бы он более тщательно подошол к выбору аппаратной базы.

Также написание своего собственного протокола от части снимает эту проблему.

 

Согласен, что четких гарантий на характеристики никто не дает. Но разве вам кто-то дает гарантии на характеристики WiFi-сетей, которые развиваются гораздо дольше и, на мой взгляд, в чем-то проще сетей класса ZigBee? Такие сети очень сложны для анализа и работают в условиях, которые трудно предсказать.

Я бы не стал сравнивать Zigbee с WIFI. WIFI это звезда и там более менее все прозрачно.

 

Простите, но вам не надоело практически в каждом посте давать ссылку на этот сайт? Тем более, что большинство приведенных статей написано не сотрудниками этой компании.

Прото там сделана хоть какаята подборка мательяда по данной тематике. И если человек пишет тему Zigbee с нуля то я думаю он там может найти для себя много интересного.

 

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

 

Просто нужно четко понимать сильные и слабые стороны ZigBee, а потом уже решать использовать его или нет

Полностью с вами согласен

И Если вас не затруднит опишите пожалуйста более подробно эти сильные и слабые стороны с вашей точки зрения

Изменено 5 февраля, 2009 пользователем Nesterenko

[Dr.NoA 0]

Я имею ввиду реализации стека различными производителями. На аппаратном уровне все ОК.

Естественно, реализации стека разные, но они должны быть совместимы друг другом. Для этого альянс и проводит сертификацию.

 

Не стоит мешать в одну кучу 802.15.4 и Zigbee Вы можете купить приемопередатчик 802.15.4 и использовать протокол написанный производителем этих чипов (только не Zigbee) или писать свой собственный. А если решили делать устройство на Zigbee то будьте добры производить отчисления с каждого устройства (к примеру у Frescale есть MC13201 и MC13202 первый приемопередатчик только для 802.15.4 а второй можно использовать дял 802.15.4 и Zigbee)

Я не мешаю в кучу, а исхожу из практики. Отпускная цена Freescale'а для MC13201 $2.01, а MC13201 - $2.35, такая разница, по-моему, существенна только для очень больших серий. А вот CC2420 вообще обоих вариантах стоит одинаково.

 

Я просто предостерегаю человека, что-бы он более тщательно подошол к выбору аппаратной базы.

Также написание своего собственного протокола от части снимает эту проблему.

Написание собственного стека ZigBee или разработка альтернативных протоколов вовсе не решает проблему зависимости, а просто трансформирует ее.

Во-первых, написание своего стека требует большого количества времени и, следовательно, денег. При этом нужно быть "в теме", а учитывая, что автор темы пытается разобраться в ZigBee с нуля, то вряд ли у него есть такой опыт.

Во-вторых, стек вы все равно должны писать под какую-то платформу (приемопередатчик+микроконтроллер), поэтому при переходе на другого производителя придется часть софта переписывать и снова отлаживать. Естественно, объем этой работы будет зависеть от того насколько грамотно изначально все было написано.

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

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

 

Я бы не стал сравнивать Zigbee с WIFI. WIFI это звезда и там более менее все прозрачно.

Вот именно, что "более менее прозрачно". Для примера можете почитать хотя бы работы проф. Вишневского, одна из статей которого есть у вас на сайте.

 

Прото там сделана хоть какаята подборка мательяда по данной тематике. И если человек пишет тему Zigbee с нуля то я думаю он там может найти для себя много интересного.

А в чем заключается логика собрать статьи, причем "хвалебные", по теме ZigBee, но при этом предлагать решения на базе альтернативной технологии?

 

И Если вас не затруднит опишите пожалуйста более подробно эти сильные и слабые стороны с вашей точки зрения

Если поставленная задача четко укладывается в те приложения, под которые ZigBee создавался, то нужно использовать ZigBee, потому что это будет дешевле, быстрее и т.д., т.е. главный козырь ZigBee - стандартизация и все что с ней связано. Конечно, при этом нужно детально разобраться в ZigBee, а не слепо верить тому, что пишут в презентациях альянса и в статьях менеджеры по продажам. В других случаях нужно внимательно смотреть на задачу и выбирать между ZigBee и другими вариантами.

Если говорить о сильных сторонах с технической точки зрения, то я не знаю ничего уникального в ZigBee.

А про слабые стороны уже много раз говорили, в том числе и на этом форуме.

[AlexandrY 2]

TI вообщем дает достаточно исходников,

правда не дает исходников нескольких либ для низкого аппаратного уровня,

ровно настолько чтобы нельзя было так просто портировать стек на иной процессор чем MSP430.

 

Но MSP430 и так идеальный процессор для ZigBee особенно новые поколения с DMA и проч наворотами.

 

Freescale уже довольно давно дает полные исходники до самых мелочей своего стека ZigBee. Сначала они были только под ядро HCS08

и не представляли особого интереса в виду убожества самого HCS08.

Нынче Freescale дает исходники и для своих чипов на основе ARM7

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

 

Поэтому решения от TI мне кажутся наиболее оптимальными в плане скорости разработки, экономичности и цены.

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

Поскольку TI дает простые решения для увеличения дистанции связи, то можно существенно сэкономить на количестве узлов сети.

 

 

На нашей плате один контроллер MSP430, один конвертер в USB, радиочип и усилитель.

 

 

 

А что стек Zigbee они дают в исходных кодах? :)

У вас на плате 2 контроллера?

[Alexashka 0]

TI вообщем дает достаточно исходников,

правда не дает исходников нескольких либ для низкого аппаратного уровня,

ровно настолько чтобы нельзя было так просто портировать стек на иной процессор чем MSP430.

 

Нынче Freescale дает исходники и для своих чипов на основе ARM7

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

 

Это конечно радует. В свое время (пару лет назад) мы так и не смогли подобрать нормальную платформу под Zigbee -у Freescale был стек, но за него тогда просили чтото порядка 10 тыщ убитых енотов, у техаса (ака чипкон) был полный голяк, а Ember мы отбросили чуть позже из-за, как тут правильно было сказано, их тупикового пути -стек в ассемблерном коде, процессор какойто уж совсем неизвестный.

 

По вашей плате- а как один контроллер справляется и со стеком Zigbee и выполняет пользовательские функции (ну там собрать данные с датчиков, обработать их и т.д) ?

[AlexandrY 2]

MSP430 работающий на 16 МГц на стек ZigBee тратит считанные проценты своей производительности.

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

А для лучшего планирования ресурсов CPU в стеке ZigBee от TI применяется очень компактная кооперативная RTOS.

На нее кстати все исходники открыты.

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

Простой выключатель освещения в ZigBee 2007 Pro варианте требует 74 KB Flash.

 

У Freescale подобное приложение в ZigBee 2006 варианте требовало не более 36 KB

 

Тут коллеги из соседнего отдела сделали на PIC-ах ZigBee модуль. Там тоже в варианте ZigBee 2006 требуется около 40 КB Flash. Стек у Microchip-a тоже полностью открыт, но в нем не используют RTOS и у PIC-ов нет отладочного интерфейса типа JTAG. Поэтому сильно оригинальные комплексные приложения на нем делать довольно трудно.

 

 

По вашей плате- а как один контроллер справляется и со стеком Zigbee и выполняет пользовательские функции (ну там собрать данные с датчиков, обработать их и т.д) ?

[Alexashka 0]

MSP430 работающий на 16 МГц на стек ZigBee тратит считанные проценты своей производительности.

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

А для лучшего планирования ресурсов CPU в стеке ZigBee от TI применяется очень компактная кооперативная RTOS.

Вот это как раз непонятно. Если контроллер работает на 16МГц под операционкой- все замечательно, это без вопросов. Но тогда не будет микропотребления. Для этого либо надо снижать тактовую до мин.возможной -так проще делать различные операции в фоновом режиме, либо нужно чтобы контроллер по прерыванию (от того же приемопередатчика, скажем от его таймера) выходил их спящего режима, чтото делал и снова засыпал. Как в этом случае будет работать операционка?

[Andrey_B 0]

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

 

Если ожидаемый тираж менее 1к, то смотреть нужно на модули, на пример www.jennic.com для ваших применений подойдет даже одна из их апнот. Все достаточно дешего и доставабельно.

[AlexandrY 2]

Всегда забавно когда embedded RTOS путают с виндами.

Правда есть плохие примеры и среди самих embedded RTOS.

Популярная к примеру uCOS всегда должна иметь задачу IDLE, которая если не позаботится отдельно

и не влезть во внутренности оси всегда работает и не дает процессору отдохнуть. (В Windows сделано также)

Но есть даже среди вытесняющих осей не говоря уже о кооперативных которым не нужна специальная задача IDLE,

и они просто уходят в sleep когда нет активных задач.

 

У TI как раз ось заточенная под постоянный сон.

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

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

Естественно все круто замешено не прерываниях. Любой чих в такой оси начинается с прерывания или пробуждения по другой причине.

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

 

Чаще всего структурирование на задачи является непреодолимой проблемой для эмбеддеров определенного уровня, поэтому думаю микрочип в своем стеке и не применяет ось чтобы не потерять аудиторию, так сказать

Но за это он платит некоторыми упрощениями в стеке там где без многозадачности трудновато обойтись.

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

Но спецификация ZigBee формализована на языке SDL предусматривающем параллельное выполнение задач.

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

 

 

 

 

Вот это как раз непонятно. Если контроллер работает на 16МГц под операционкой- все замечательно, это без вопросов. Но тогда не будет микропотребления. Для этого либо надо снижать тактовую до мин.возможной -так проще делать различные операции в фоновом режиме, либо нужно чтобы контроллер по прерыванию (от того же приемопередатчика, скажем от его таймера) выходил их спящего режима, чтото делал и снова засыпал. Как в этом случае будет работать операционка?

 

Эта цифра (ожидаемого тиража) ИМХО уже давно снизилась до 1-10 ;)

 

Если ожидаемый тираж менее 1к, то смотреть нужно на модули, на пример www.jennic.com для ваших применений подойдет даже одна из их апнот. Все достаточно дешего и доставабельно.

[kimstik 0]

То есть микрочиповский стек уступает другим только нагрузкой на проц (потреблением)?

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

И почему они вообще на поллинг сели? Ограничение трансивера?

[AlexandrY 2]

Не, вы не поняли.

Безусловно у всех при обмене с трансивером используются аппаратные прерывания.

Без них вообще немыслимо какую либо развитую коммуникацию сделать.

 

Я речь веду о более высоком системном уровне. О том как построен алгоритм взаимодействия уровней стека: PHY, MAC, сетевого, приложения.

У микрочипа они вызываются последовательно один за другим в строгом порядке.

Процедуры каждого уровня вызываются в обязательном порядке не смотря на то нужно им в этот момент что-то делать или нет.

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

Это я и называю полингом хотя устоявшееся название - round-robin цикл.

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

Сложность построения и отладки машин состояний и заставляет микрочип прибегать к упрощениям.

К тому же стоит в какой либо машине состояний программе задержаться и все тайминги стека летят в ж...

 

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

Плюс сама модель стека написана на SDL и идеально ложится на RTOS, а на машины состояний приходится делать неформальные преобразования алгоритма.

 

 

 

То есть микрочиповский стек уступает другим только нагрузкой на проц (потреблением)?

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

И почему они вообще на поллинг сели? Ограничение трансивера?

[Alexashka 0]

У TI как раз ось заточенная под постоянный сон.

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

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

Естественно все круто замешено не прерываниях. Любой чих в такой оси начинается с прерывания или пробуждения по другой причине.

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

 

Чаще всего структурирование на задачи является непреодолимой проблемой для эмбеддеров определенного уровня, поэтому думаю микрочип в своем стеке и не применяет ось чтобы не потерять аудиторию, так сказать

Но за это он платит некоторыми упрощениями в стеке там где без многозадачности трудновато обойтись.

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

Но спецификация ZigBee формализована на языке SDL предусматривающем параллельное выполнение задач.

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

 

Уходит в сон...ммм...это конечно все хорошо, но вот как быть если трансиверу (ну или томуже контроллеру) нужен стабильный тактовый сигнал от кварца. На раскачку кварцевого генератора уходит до 5мс. Если уходить в сон очень часто (а у меня например обычно прерывания лупят с частотой неск.сотен герц), то какой смысл тогда в этих переходах в сон, если все время система будет ожидать момента стабилизации кварц.генератора? Поэтому я пошел по другому пути- уменьшение тактовой частоты до минимума и никаких переходов в сон и никаких задержек от кварца.

[foma.ua 0]

Не, вы не поняли.

 

С большим интересом AlexandrY прочел Вашу статью. Меня интересует Ваше мнение о чипе Freescale MC13224. Есть ли у Вас опыт построения на базе этой мс беспроводных сетей сбора данных, в частности, сети электросчетчиков? Какие плюсы, минусы у этого чипа на Ваш взгляд?

[AlexandrY 2]

Принципиально, это просто одна из технических деталей реализации (ваша схема управления потреблением)

Все зависит от конкретного микроконтроллера. Схемы энергосбережения могут быть и другие.

Главное, что RTOS у TI переходит в режим пониженного потребления всегда когда есть возможность, т.е. как только все задачи перестали быть активны.

У чипов СС2520 которые мы применяем время старта кварца 0.3 мс в худшем случае.

Из неглубокого сна - 200 мкс.

Это помимо того, что у MSP430 самого есть куча генераторов и с пониженной частотой и с резким стартом.

Вообщем, что там отключать, что переключать и что понижать - все это мелочи по сравнению с тем КОГДА это делать.

Здесь RTOS незаменима.

 

Уходит в сон...ммм...это конечно все хорошо, но вот как быть если трансиверу (ну или томуже контроллеру) нужен стабильный тактовый сигнал от кварца. На раскачку кварцевого генератора уходит до 5мс. Если уходить в сон очень часто (а у меня например обычно прерывания лупят с частотой неск.сотен герц), то какой смысл тогда в этих переходах в сон, если все время система будет ожидать момента стабилизации кварц.генератора? Поэтому я пошел по другому пути- уменьшение тактовой частоты до минимума и никаких переходов в сон и никаких задержек от кварца.

 

 

Конечно приятно, что он сделан на ARM и вроде скорость приличная.

Но эта химия с перекачкой программы из Serial FLASH в RAM мне совсем не нравиться.

Если учесть, что код для ARM7 даже в режиме THUMB будет занимать больше места чем для того же MSP430,

то понятно, что их 96 Кб RAM-а еле хватит на сам стек ZigBee

Ни о каком серьезном пользовательском приложении речь не идет.

Расчет скорее на каких-то корпоративных разработчиков и моду,

поскольку ARM-ы претендуют на роль великой объединительной архитектуры для микроконтроллеров.

A Freescal-у как раз плюнуть всунуть ARM-ы еще куда нить.

 

С большим интересом AlexandrY прочел Вашу статью. Меня интересует Ваше мнение о чипе Freescale MC13224. Есть ли у Вас опыт построения на базе этой мс беспроводных сетей сбора данных, в частности, сети электросчетчиков? Какие плюсы, минусы у этого чипа на Ваш взгляд?

[Alexashka 0]

Принципиально, это просто одна из технических деталей реализации (ваша схема управления потреблением)

Все зависит от конкретного микроконтроллера. Схемы энергосбережения могут быть и другие.

Главное, что RTOS у TI переходит в режим пониженного потребления всегда когда есть возможность, т.е. как только все задачи перестали быть активны.

У чипов СС2520 которые мы применяем время старта кварца 0.3 мс в худшем случае.

Из неглубокого сна - 200 мкс.

Это помимо того, что у MSP430 самого есть куча генераторов и с пониженной частотой и с резким стартом.

Вообщем, что там отключать, что переключать и что понижать - все это мелочи по сравнению с тем КОГДА это делать.

Здесь RTOS незаменима.

Да к RTOS давно присматриваюсь, однако нехватка знаний и опыта в программировании систем на основе RTOS останавливает пока что. Можете посоветовать какуюнить книжку (книжки) которую следует прочитать для начала освоения, желательно на русском?

[foma.ua 0]

Конечно приятно, что он сделан на ARM и вроде скорость приличная.

Но эта химия с перекачкой программы из Serial FLASH в RAM мне совсем не нравиться.

Если учесть, что код для ARM7 даже в режиме THUMB будет занимать больше места чем для того же MSP430,

то понятно, что их 96 Кб RAM-а еле хватит на сам стек ZigBee

Ни о каком серьезном пользовательском приложении речь не идет.

Расчет скорее на каких-то корпоративных разработчиков и моду,

поскольку ARM-ы претендуют на роль великой объединительной архитектуры для микроконтроллеров.

A Freescal-у как раз плюнуть всунуть ARM-ы еще куда нить.

У МС13224 вкусная цена и универсальность для разработки. По крайне мере так его представляют. А как у него с реальным потреблением? Какое "серьезное приложение" Вы имеете ввиду?

Я читал статью Akiba.

С копированием из флеш в RAM согласен - это непонятная химия.