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

Гдето в сети находил что качество кода стека для TI лучше чем Microchip. Правда голословно.
То что хорошего в каждом из них - много и везде написано.
А какие неописанные грабли есть?
Как жертва рекламы я по видимому падаю на атмель. Как сделать осмысленный выбор?

http://electronix.ru/mkportal/modules/medi...ndex.php/ZigBee

Для каких целей производите выбор?
Планируете применять с готовым стеком или писать стек самостоятельно?
Какая требуется дальность связи?
Планируете использовать готовые модемы или производить разводку и согласование RF самостоятельно?

Для сбора данных/замены rs232. Скорость не принципиальна.
Хотелось бы готовый стек.
Расстояние в пределах помещения. Пусть будет метров 20.
Разводка и согласование самостоятельно.

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

Если замена RS232 то планипуется точка-точка?

В принципе все равно. Но было бы не разумно не использовать многоточку.

Замену COM-порта я бы сделал на виртуальном COM-порте (устройство подключается к USB), так как USB щас есть во всех компьютерах, а COM-порт нет. Да и питание из USB проще доставать
Гляньте CC2511F32 - 2.4 GHz Radio Transceiver, 8051 MCU, 32 kB Flash memory and full-speed USB interface.
Ну или CC1111F32 -на субгигагерцовые частоты.

К сожалению ваши ответы так и не пролили свет на проект в котором вы хотите применить zigbee. Поэтому попробую ответить как можно более обще.
Для начала надо определится вам нужен zigbee или просто сетевое решение на базе 802.15.4 Если Zigbee то тут скорее всего надо рассматривать Ember.
Если решение на базе 802.15.4 то можно рассмотреть MIWI, Simplicity и тд. Или написать свой собственный протокол на базе MAC уровня, который предоставляется производителями трансиверов
К сожалению, поделится опытом использования протоколов предлагаемых производителем чипов не могу, так как нам они не подошли по своим характеристикам, и мы пошли по пути создания собственного протокола.
По поводу аппаратной базы. Если планируется большой рынок, и требуется максимально минимизировать стоимость устройства то стоит рассмотреть моночипы Freescale.
Если партии не большие то лучше не связываться с радио частью и взять готовые модемы, к примеру, meshnetics (Atmega 128 + AT86RF231)
Из вашего списка работали с MC13192FC и AT86RF231. Приемопередатчик от Atmel по своим характеристикам лучше.

Благодарствую за ответ!
Не хочется заниматься изначально тюнингом, поэтому только стандартный ZigBee. Задача - максимально общий сбор данных (окружающая среда, кнопки, ...)
Спасибо за Freescale - съекономили мне малость времени на оценке цен. Вполне может быть решающем в последний момент.
Значит вы подтверждаете акцент на Атмел?
Меня еще смущает активность TI Как они в сравнинии?

ps: вот еще нашел блог интереный по теме http://freaklabs.org/index.php/Blog/Zigbee...420-review.html

Если вы собираетесь использовать стандартный Zigbee то попробую рассказать вам свои опасениями и буду рад, если меня кто-то поправит, только не на основании рекламных материалов а на основании реальных опытов.
1. Zigbee реализации разных производителей чипов не совместимы.
2. Zigbee разных версий не совместимы.
3. На данный момент мало стандартных профилей, управления устройствами.
4. В Zigbee ограничено число оконечных устройств на один ретранслятор. В некоторых реализациях 16 устройств.
5. В Zigbee достаточно большая задержка сигнала 30мс на хоп.(на одну попытку связи) , не говоря уже о том если был потерян маршрут.
6. При использовании Zigbee необходимо производить отчисление (Чаще всего закладывается в стоимость чипа).
7. Вы завязываетесь на конкретного производителя, то есть если вы сегодня решили делать на Ember то для перехода потом на другого производителя вам практически придется делать все с нуля.
6. И самое неприятное что на данный момент вам никто ничего не гарантирует. (Нет сетевых параметров) и не совсем понятно, что делать, когда вы разработаете систему на 5-10 устройствах. А потом оказывается, что необходимые вам характеристик можно дыбится только при 20 устройствах в сети а не при 256 как вы планировали.
Поймите меня правильно я не противник Zigbee просто, на мой взгляд, на данный момент он еще очень сырой.


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

Здесь вы можете посмотреть статьи по Zigbee
Статьи по Zigbee

Если хотябы половина из того что вы написАли - правда, то это прям как холодный душ
Для меня в данном случае ключевым словом было 'несовместимость'.
Тоесть если сейчас - то по любому надо принимать чью то религию (атмель, текс, мото, ..) и идти на заклание?
И они в добавок еще каждый свой стек к своим же процам привязывают.
Жуть!

Попробую немного возразить.


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


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


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


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


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

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


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


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

На уровне транспортного протокола ZigBee абсолютно совместимы.
Несовместимость только на прикладном уровне присутствует.
Но речь зашла сразу об оригинальном приложении поэтому с совместимостью вопрос не стоит.

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

Технологии ZigBee вообщем достаточно освоены и сделать свой модуль ни стоит никакого труда.
Здесь TI можно сказать вне конкуренции в плане открытости технологии.
Большой плюс что они выпускают также чип усилителя к ZigBee.

У нас буквально за пару недель разработали модули USB-ZigBee с усилителем на платформе TI

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

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

А открытого Zigbee стека еще не существует?
При таком количестве чипов ему пора появиться уже.

Еще интересна статистика. Поиском в инете складывается впечатление что большинство разработок делается на паре RF от текса + Аврка.
А производители видно тужатся - хотят перетянуть вторую часть пирога на себя.
Атмелю мне кажется в данном случае это сделать проще.

Насколько я знаю, CC2420 был первым приемопередатчиком стандарта 802.15.4 и имеет очень неплохие технические характеристики, поэтому и получил широкое распространение. А поскольку тогда это был еще Chipcon, то и не возникала стойкая ассоциация, что его надо использовать в связке с MSP430. Видимо поэтому и получила широкое распространение пара CC2420+AVR.

Проблема Atmel'а в том, что у него нет собственного стека, поэтому они и дружат с Meshnetics'ом

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



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


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


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


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

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


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

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


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


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


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


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


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

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

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

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

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


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

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

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

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. Поэтому сильно оригинальные комплексные приложения на нем делать довольно трудно.

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

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

Всегда забавно когда embedded RTOS путают с виндами.
Правда есть плохие примеры и среди самих embedded RTOS.
Популярная к примеру uCOS всегда должна иметь задачу IDLE, которая если не позаботится отдельно
и не влезть во внутренности оси всегда работает и не дает процессору отдохнуть. (В Windows сделано также)
Но есть даже среди вытесняющих осей не говоря уже о кооперативных которым не нужна специальная задача IDLE,
и они просто уходят в sleep когда нет активных задач.

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

Чаще всего структурирование на задачи является непреодолимой проблемой для эмбеддеров определенного уровня, поэтому думаю микрочип в своем стеке и не применяет ось чтобы не потерять аудиторию, так сказать
Но за это он платит некоторыми упрощениями в стеке там где без многозадачности трудновато обойтись.
У микрочипа применен примитивный полинг в главном цикле. Чтобы все работало гладко полинг должен осуществляться быстро и без перерывов.
Но спецификация ZigBee формализована на языке SDL предусматривающем параллельное выполнение задач.
Микрочип вынужден исказить алгоритм написанный на SDL чтобы переложить его на стиль полинга отсюда и все упрощения их стека.






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

То есть микрочиповский стек уступает другим только нагрузкой на проц (потреблением)?
Правльно реализованный поллинг по идее не должен уступать прерываниям.
И почему они вообще на поллинг сели? Ограничение трансивера?

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

Я речь веду о более высоком системном уровне. О том как построен алгоритм взаимодействия уровней стека: PHY, MAC, сетевого, приложения.
У микрочипа они вызываются последовательно один за другим в строгом порядке.
Процедуры каждого уровня вызываются в обязательном порядке не смотря на то нужно им в этот момент что-то делать или нет.
Уже в самих процедурах идет поиск чего бы им сейчас сделать и если делать нечего производится выход из процедуры.
Это я и называю полингом хотя устоявшееся название - round-robin цикл.
Здесь много времени тратится на поиск собственно предмета обработки, а хуже что нужно строить сложные алгоритмы называемые "машины состояний"
Сложность построения и отладки машин состояний и заставляет микрочип прибегать к упрощениям.
К тому же стоит в какой либо машине состояний программе задержаться и все тайминги стека летят в ж...

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

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

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

Принципиально, это просто одна из технических деталей реализации (ваша схема управления потреблением)
Все зависит от конкретного микроконтроллера. Схемы энергосбережения могут быть и другие.
Главное, что RTOS у TI переходит в режим пониженного потребления всегда когда есть возможность, т.е. как только все задачи перестали быть активны.
У чипов СС2520 которые мы применяем время старта кварца 0.3 мс в худшем случае.
Из неглубокого сна - 200 мкс.
Это помимо того, что у MSP430 самого есть куча генераторов и с пониженной частотой и с резким стартом.
Вообщем, что там отключать, что переключать и что понижать - все это мелочи по сравнению с тем КОГДА это делать.
Здесь RTOS незаменима.




Конечно приятно, что он сделан на ARM и вроде скорость приличная.
Но эта химия с перекачкой программы из Serial FLASH в RAM мне совсем не нравиться.
Если учесть, что код для ARM7 даже в режиме THUMB будет занимать больше места чем для того же MSP430,
то понятно, что их 96 Кб RAM-а еле хватит на сам стек ZigBee
Ни о каком серьезном пользовательском приложении речь не идет.
Расчет скорее на каких-то корпоративных разработчиков и моду,
поскольку ARM-ы претендуют на роль великой объединительной архитектуры для микроконтроллеров.
A Freescal-у как раз плюнуть всунуть ARM-ы еще куда нить.

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

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

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

Серьезным приложением я бы назвал достаточно универсальный многопрофильный измерительный или сервисный дивайс с дисплеем (маленьким но графическим), клавиатурой, каким нибудь проводным интерфейсом для осуществления моста с проводным миром. Поверх проводного интерфейса протоколы типа TCP/IP, CanOpen, MODBUS. С накоплением данных на сменных носителях типа SD карт, USB донглов или NAND чипов и соответственно с файловой системой.

Так на mc13224 я даже одной трети из этого не рискнул бы делать.

Такие дивайсы делаются на других чипах.. которые можно у того же Freescale и поискать.. ColdFire... или же NXP LPC2478

Коллеги, скажите какова сейчас ситуация со стандартом ZigBee?
Он уже прошёл стадию апробации и перестал быть "сырым"?