Comments 30
А кикстартер не думали?
какие-то совсем не радужные новости :(
Поняли, что текущий аппаратный дизайн диммера не совместим с программным стеком Atmel BitCloud. Расстались с одним участником. Решили вернуться к разработкам на базе NRF24LE1. Начали разработку одного нового интересного решения с новым разработчиком.
Что-то Вас штормит… причем неслабо так, то перешли с NRF24LE1 на ZigBee, потом обратно… Грустно. Желаю наконец то устаканиться и выпустить продукт.
Может стоить пойти более простым путем? Взять дешовский pic или даже arm, придумать радиоканал связи как у noolite, но только двунаправленный, придумать минимальное шифрование и все. При наличии опытного разработчика (ключевое слово ОПЫТНОГО) такое решение можно сделать за неск. месяцев.
Мне кажется, более простой путь и так выбран. Готовый радиоканал, который не надо отлаживать, у которого есть контроль ошибок и адресация ( и кстати каждый модуль внутри имеет по 6 буферов и 6 адресов для приема ). Остается только настроить и включить его.
В Вашем случае надо разработать+отладить канал, на нем поднять контроль ошибок, контроль коллизий, идентификацию — это все гораздо дольше.
В Вашем случае надо разработать+отладить канал, на нем поднять контроль ошибок, контроль коллизий, идентификацию — это все гораздо дольше.
Смотрю, Вы перешли на маленькие модули как у меня :)
С большим интересом слежу за Вашим проектом, желаю успехов!
С большим интересом слежу за Вашим проектом, желаю успехов!
" BitCloud накладывает на пользовательский код серьезные ограничения по времени выполнения отдельных участков. Мы пришли к выводу, что не получится объединить в одном чипе управление диммером (контроль ноля + управление симистором) и работу со стеком BitCloud "
Как меня радует подобный подход. Стандартная бибилиотека не работает в наших условиях — варианты решения: ищем другую стандартную библиотеку, меняем условия ( в нашем случае — МК). Просто очаровательно. Посмотреть исходники библиотеки (они, как правило, есть), понять, что там не так, немного подпилить (заодно получив массу полезных знаний) — такой вариант современным разработчиком даже не рассматривается. Будущее индустрии в нашей стране мне представляется весьма туманным…
Кстати а по поводу Вашего нового проекта — видел его раньше в виде ТЗ — позволю себе маленькое предложение — вместо того, чтобы менять существующий контроллер, раз он так хорош (хотя тиристорное управление существует на первый десяток лет), сделайте модуль, который будет под управлением радиоканала имитировать изменение параметров регулирующего элемента (скорее всего переменного резистора) и задача решена (DISS в действии).
Как меня радует подобный подход. Стандартная бибилиотека не работает в наших условиях — варианты решения: ищем другую стандартную библиотеку, меняем условия ( в нашем случае — МК). Просто очаровательно. Посмотреть исходники библиотеки (они, как правило, есть), понять, что там не так, немного подпилить (заодно получив массу полезных знаний) — такой вариант современным разработчиком даже не рассматривается. Будущее индустрии в нашей стране мне представляется весьма туманным…
Кстати а по поводу Вашего нового проекта — видел его раньше в виде ТЗ — позволю себе маленькое предложение — вместо того, чтобы менять существующий контроллер, раз он так хорош (хотя тиристорное управление существует на первый десяток лет), сделайте модуль, который будет под управлением радиоканала имитировать изменение параметров регулирующего элемента (скорее всего переменного резистора) и задача решена (DISS в действии).
Прежде чем писать мнение о нашем подходе, следует ознакомиться, что есть BitCloud. Хотя бы поверхностно. Он без исходников поставляется, объектными файлами. И скорректировать его внутреннюю архитектуру нет никакой возможности.
По второму вопросу вы предлагаете подключиться к штатному резистору термостата и менять его сопротивление по сигналу с радиомодуля — я правильно понял суть предложения? :)
По второму вопросу вы предлагаете подключиться к штатному резистору термостата и менять его сопротивление по сигналу с радиомодуля — я правильно понял суть предложения? :)
По второму вопросу — именно так. При этом вы можете совершенно не думать об объекте управления — все уже сделано.
А по первой части — приношу извинения, если кого то обидел. Мысль была высказана о наболевшем — полнейшее нежелание среди молодых людей в чем то углубленно разбираться. И если нет исходников конкретной библиотеки, то наверняка существуют исходники других библиотек для такого достаточно распространенного интерфейса. Даже если они не портированы на выбраный МК, задача вполне решаема, разумеется при наличии желания ее решать (все остальные факторы не столь значимы, по моему мнению).
А по первой части — приношу извинения, если кого то обидел. Мысль была высказана о наболевшем — полнейшее нежелание среди молодых людей в чем то углубленно разбираться. И если нет исходников конкретной библиотеки, то наверняка существуют исходники других библиотек для такого достаточно распространенного интерфейса. Даже если они не портированы на выбраный МК, задача вполне решаема, разумеется при наличии желания ее решать (все остальные факторы не столь значимы, по моему мнению).
1. Никого не обидели, просто удивляет способность людей критиковать что-либо, при полном нежелании хоть как-то самим разобраться в вопросе. У этой библиотеки нет исходников. Под эту архитектуру это единственное доступное решение. И даже если бы исходники были, протокол не так прост, чтобы взять и скорректировать работу стека за пару вечеров. Портировать стек с другого МК — это вообще утопия, даже если бы было что портировать. Думаю, вы совсем слабо себе представляете расход временных ресурсов на такие «простые» действия. Почитайте пожалуйста документацию на ZigBee и другие доступные материалы на эту тему, чтобы продолжать риторику.
2. Если вы видели наш термостат еще в виде ТЗ, то видимо опять не очень внимательно читали. В конвекторах NOBO электроника четко поделена на силовую и управляющую. Мы подменяем только управляющую часть, используем штатную силовую. Мы создаем законченное решение, которое можно будет купить и просто вставить в конвектор. Без каких-либо доработок его напильником/паяльником.
Вы предлагаете сделать «колхоз», который обычно делают в устройствах «для себя». В каком виде вы предлагаете отдавать продукт людям в вашем сценарии разработки? В виде инструкции, куда подпаять и где подточить? Это не наш путь.
2. Если вы видели наш термостат еще в виде ТЗ, то видимо опять не очень внимательно читали. В конвекторах NOBO электроника четко поделена на силовую и управляющую. Мы подменяем только управляющую часть, используем штатную силовую. Мы создаем законченное решение, которое можно будет купить и просто вставить в конвектор. Без каких-либо доработок его напильником/паяльником.
Вы предлагаете сделать «колхоз», который обычно делают в устройствах «для себя». В каком виде вы предлагаете отдавать продукт людям в вашем сценарии разработки? В виде инструкции, куда подпаять и где подточить? Это не наш путь.
Значит так. Насчет полного нежелания разбираться в вопросе — сильно сказано. Я конкретно не работал с ZigBee, но работал с протоколами и интерфейсами, сравнимыми с ним по сложности. Я ОЧЕНЬ хорошо представляю себе расход временных ресурсов на ЛЮБЫЕ действия по проектирования электроники (более 20 реализованных проектов в разных областях тому подтверждение). За пару вечеров — видимо нет, но если Вы за эту пару вечеров успели разработать платы под новый МК, развести их, заказать и получить, то тогда, конечно, Ваш подход правильнее. Но, опять таки, мой многолетний опыт мне подсказывает что переход на другой МК займет ни в коем случае не пару вечеров. Мое личное мнение (естественно, я допускаю существование неправильного другого), что для портирования существующего стека на другой МК (при отсутствии СУЩЕСТВЕННЫХ различий в объеме постоянной и оперативной памяти и ЖЕСТОЧАЙШИХ требований стандарта к времени реакции) для квалифицированного инженера не должно занять более 2-3 недель упорного труда, что более чем сравнимо со временем перехода на другой МК. Сначала Вы сами пишете, что разработчики, привыкшие к ATMEL, не хотят переходить на не столь уж сильно от него отличающийся МК (что, на мой взгляд, не говорит в их пользу), а когда я пишу о нежелании современной молодежи глубоко разбираться в том, что составляет суть профессии, которую они выбрали, выясняется, что задача понять происходящее в полностью документированом стандарте совершенно неподъемна и чудовищно сложна. Мне данный подход представляется не вполне верным.
Что касается второго вопроса, то конечно, если речь идет о поставляемом широкому кругу пользователей продукте, реслизация предлагаемого мной варианта не является приемлемой, я его предложил, исходя из минимальной стоимости разработки. Удобство монтажа неподготовленным пользователем сильной стороной такого решения не назовешь, тут Вы абсолютно правы.
Что касается второго вопроса, то конечно, если речь идет о поставляемом широкому кругу пользователей продукте, реслизация предлагаемого мной варианта не является приемлемой, я его предложил, исходя из минимальной стоимости разработки. Удобство монтажа неподготовленным пользователем сильной стороной такого решения не назовешь, тут Вы абсолютно правы.
Ну вот, оценки уже идут ближе к реальности. 2-3 недели упорного труда (читай — fulltime) опытного разработчика? Может быть. Но у нас нет в распоряжении такого количества времени у специалиста такого уровня. А если бы было, мы бы предпочли его потратить на расширение линейки продукции, а не на портирование какого-то гипотетического зигбишного стека (повторю, не откуда его портировать, разговор сейчас о воздухе идет). Я уже молчу, что стек должен получиться сертифицированным (чтобы работать с другими девайсами), а на этот процесс тоже потребуются значительные средства.
В целом мы исходим из реалий с параметрами минимизации расходов, рисков и времени. Если вы сами хотите написать нужную реализацию ZigBee — welcome, пишите, продавайте. Будем только рады появлению альтернативы. Мы пока разберемся с более простым и дешевым решением вопроса.
В целом мы исходим из реалий с параметрами минимизации расходов, рисков и времени. Если вы сами хотите написать нужную реализацию ZigBee — welcome, пишите, продавайте. Будем только рады появлению альтернативы. Мы пока разберемся с более простым и дешевым решением вопроса.
Как меня радуют люди, склонные обобщать и подгонять целые категории других людей под одну гребёнку. Просто очаровательно.
1) Вы не рассматривали вариант использования NRF51822?
+++ arm (есть нормальный gcc, а не какой-то sdcc)
+ BT LE (можно управлять напрямую с телефона)
+ поддерживает протокол nrf24l*1 (если будут проблемы с BT)
— возможно будут те же проблемы что и с BitCloud (стек BT и код приложения крутится одном контроллере)
2) Контроль ноля не на прерываниях? Что там так долго выполняется?
+++ arm (есть нормальный gcc, а не какой-то sdcc)
+ BT LE (можно управлять напрямую с телефона)
+ поддерживает протокол nrf24l*1 (если будут проблемы с BT)
— возможно будут те же проблемы что и с BitCloud (стек BT и код приложения крутится одном контроллере)
2) Контроль ноля не на прерываниях? Что там так долго выполняется?
1) нет, больше никуда прыгать уже не будем, напрыгались :) и BT LE напрямую можно управлять только с телефона со встроенным именно BT LE (на сколько я знаю), а таких телефонов не много.
2) лично я на этот вопрос ответить не могу. если Александр сюда заглянет, может быть ответит. он в курсе
2) лично я на этот вопрос ответить не могу. если Александр сюда заглянет, может быть ответит. он в курсе
1) Да, нужен телефон с BT4 (это фактически BT3+BT LE) и Android 4.3+/iOS.
Когда диммер зарелизите таких телефонов будет уже много.
Когда диммер зарелизите таких телефонов будет уже много.
только сегодня на новом месте инет подключил =), долбаный «кабинет» ((( — прошу прощения, наболело.
2) все очень просто, чтобы поддерживать сеть zigbee нужно с определенным интервалом выполнять определенные действия (даже на конечных устройствах), накладываем сюда еще работу самого bitcloud (считай работа операционки) — а его работа простая — по таймеру она проверят всю кучу назначенных ей задач и выполняет их, + также последовательно обрабатывая другие прерывания.
Детекция 0 разумеется на внешнем прерывании и даже импульс включения, подаваемый на оптопару, тоже на прерывании от таймера (при чем НЕ на том, который использует bitcloud, предоставляя api для пользования разработчику)
При этом я очень неплохо разобрался с самим bitcloud (использованием таймеров, прерываний и тд.) и с реализацией профилей, конечных точек и тд по zigbee — сам по себе протокол работает стабильно на atmegarfa1 — что радует — есть возможность делать очень быстро zigbee устройства, которые не критичны к времени исполнения пользовательского кода.
Решением для диммера, вижу использование доп чипа (самого дешевого и простого) на силовую часть, а atmegarfa1 использовать для работы с сетью и управления чипом силовой части.
2) все очень просто, чтобы поддерживать сеть zigbee нужно с определенным интервалом выполнять определенные действия (даже на конечных устройствах), накладываем сюда еще работу самого bitcloud (считай работа операционки) — а его работа простая — по таймеру она проверят всю кучу назначенных ей задач и выполняет их, + также последовательно обрабатывая другие прерывания.
Детекция 0 разумеется на внешнем прерывании и даже импульс включения, подаваемый на оптопару, тоже на прерывании от таймера (при чем НЕ на том, который использует bitcloud, предоставляя api для пользования разработчику)
При этом я очень неплохо разобрался с самим bitcloud (использованием таймеров, прерываний и тд.) и с реализацией профилей, конечных точек и тд по zigbee — сам по себе протокол работает стабильно на atmegarfa1 — что радует — есть возможность делать очень быстро zigbee устройства, которые не критичны к времени исполнения пользовательского кода.
Решением для диммера, вижу использование доп чипа (самого дешевого и простого) на силовую часть, а atmegarfa1 использовать для работы с сетью и управления чипом силовой части.
Вы упёрлись в ограничение на 50us в коде «своего/не_системного» прерывания перехода через ноль? (в остальных местах вполне достаточные ограничения на 10ms/50ms).
Вроде кроме этого прерывания и импульса включения по таймеру для диммера ничего больше и не нужно…
Вроде кроме этого прерывания и импульса включения по таймеру для диммера ничего больше и не нужно…
то ли я много написал, то ли написал не понятно —
Может на примере будет легче понять, хотя из выше сказанного вывод сам напрашивается.
Какие то действия, например подготовка\прием-отсылка пакета координатору (это не единственное), происходит под протекцией и когда на такие моменты попадает, скажем 0 — то, например, пропадает полупериод т.к. прерывание обрабатывается после действий над пакетом.
все очень просто, чтобы поддерживать сеть zigbee нужно с определенным интервалом выполнять определенные действия (даже на конечных устройствах), накладываем сюда еще работу самого bitcloud (считай работа операционки) — а его работа простая — по таймеру она проверят всю кучу назначенных ей задач и выполняет их, + также последовательно обрабатывая другие прерывания
Может на примере будет легче понять, хотя из выше сказанного вывод сам напрашивается.
Какие то действия, например подготовка\прием-отсылка пакета координатору (это не единственное), происходит под протекцией и когда на такие моменты попадает, скажем 0 — то, например, пропадает полупериод т.к. прерывание обрабатывается после действий над пакетом.
Протекция это критическая секция? То есть системный код bitcloud запрещает хардварные прерываний на время значительно превосходящее озвученные 50us?
Ваше прерывание по переходу через ноль никуда не должно пропадать и должно вызываться при выходе из критической секции.
Timer Input capture не пробовали? При его использовании вы сможете узнать точное время перехода через ноль, даже если во время перехода выполнялась критическая секция.
Ваше прерывание по переходу через ноль никуда не должно пропадать и должно вызываться при выходе из критической секции.
Timer Input capture не пробовали? При его использовании вы сможете узнать точное время перехода через ноль, даже если во время перехода выполнялась критическая секция.
Вы на самом деле сделали шаг назад. ATMEGA128RFA1 имеет лучшие в классе параметры (в частности, чувствительность приемника). Мы, правда, в одном из коммерческих проектов использовали не его, а AT86RF231. Но ATMEGA128RFA1 это суть тот же AT86RF231 с какой-то атмегой внутри.
NRF24LE1 – известное решение, есть много либ и стороннего кода, но с потребительской точки зрения (надежность связи) оно сильно проигрывает. Его ж Нордик для мышей и клавиатур делал, т.е. для дистанции в несколько метров. Намучаетесь вы с реальной сетью в помещениях с ж/б перекрытиями…
Вариант продолжения проекта – взять мелкий PIC10F (SOT23-6) за 20 центов в опте и реализовать диммер на нем. У некрочипа есть готовый проект.
NRF24LE1 – известное решение, есть много либ и стороннего кода, но с потребительской точки зрения (надежность связи) оно сильно проигрывает. Его ж Нордик для мышей и клавиатур делал, т.е. для дистанции в несколько метров. Намучаетесь вы с реальной сетью в помещениях с ж/б перекрытиями…
Вариант продолжения проекта – взять мелкий PIC10F (SOT23-6) за 20 центов в опте и реализовать диммер на нем. У некрочипа есть готовый проект.
Кстати по поводу готового проекта — ознакомился. Нестандартное применение выпрямительного диода порадовало -это без сарказма. Но лично меня сразу насторожили в нем номиналы гасящих резисторов и быстрый подсчет подтвердил, что имеется перегрузка по мощности в 2.5 раза. В общем по пустячек, резисторы такое вытерпят и является следствием арифметической ошибки в рассчетах, но тем не менее — «тщательнее надо быть». Еще один примерчик недотсточно ответственного подхода к проектированию, причем со стороны известной фирмы.
PS. А почему НЕКРОчип? Я что то пропустил?
PS. А почему НЕКРОчип? Я что то пропустил?
Господин GarryC решил создать отдельный топик про нашу профнепригодность, в связи с откатом на NRF24LE1, где во всю не стесняется в выражениях. Кому интересно, можете поучаствовать. Я там еще раз написал о причинах отката, другими словами, для тех, кто на бронепоезде.
Я никоим образом не знаком с упомянутой платформой, чтобы сделать такие выводы. Этот комментарий я видел, он от другого автора, и моего мнения по поводу отката на данную конкретную платформу я не имею ввиду отсутствия достаточного уровня компетентности именно по данному поводу. Я стараюсь избегать подхода «Пастернака не читал, но, как весь советский народ, решительно осуждаю» — читателям судить, насколько мне это удается. При этом я все таки стараюсь допускать, что существуют аспекты, которые я мог упустить либо не придать им должного внимания, опять таки мне так казалось. Мое личное мнение, что переход с одной платформы на другую, а затем возврат на предыдущую не может быть отнесен к сильным сторонам проекта и, скорее всего, свидетельствует о недостаточно тщательном продходе к разработке. В своем первом посте я как раз и рассказывал, как вытягивал из МК и библиотеки по крохам требуемое быстродействие и таки вытянул. Если есть аргументированое противоположное мнение, с радостью с ним ознакомлюсь.
А вот такую штуку вы видели mysensors.org/? Хорошая стандартная открытая платформа с поддержкой и комьюнити для устройств с nrf24l01.
Возможно есть смысл сделать вашу железку на их протоколе. Исходники там есть, правда для арудино.
Возможно есть смысл сделать вашу железку на их протоколе. Исходники там есть, правда для арудино.
Sign up to leave a comment.
COOLRF: Перезагрузка