ZigBee с нуля Опции

[kimstik]

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

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

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

Сообщение отредактировал kimstik - Feb 3 2009, 12:17

[Nesterenko]

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

[kimstik]

К сожалению ваши ответы так и не пролили свет на проект в котором вы хотите применить 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

Сообщение отредактировал kimstik - Feb 4 2009, 15:53

[Nesterenko]

Не хочется заниматься изначально тюнингом, поэтому только стандартный ZigBee.

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

Значит вы подтверждаете акцент на Атмел?
Меня еще смущает активность TI Как они в сравнинии?

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

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

Сообщение отредактировал Nesterenko - Feb 4 2009, 18:03

[kimstik]

1,2,3...

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

[AlexandrY]

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

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

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

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

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

[Alexashka]

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

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

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

[AlexandrY]

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

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

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

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


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

А что стек Zigbee они дают в исходных кодах?
У вас на плате 2 контроллера?

[Alexashka]

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

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

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

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

[AlexandrY]

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]

MSP430 работающий на 16 МГц на стек ZigBee тратит считанные проценты своей производительности.
Ибо суммарный трафик которым может загрузить процессор радиочасть сравнительно небольшой.
А для лучшего планирования ресурсов CPU в стеке ZigBee от TI применяется очень компактная кооперативная RTOS.

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

[AlexandrY]

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

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

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

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

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

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