adnega

Там где LON, там и спец чипы, и жесткий протокол, и бабло) Опять пример из жизни. Есть система УД на базе модулей I-7000 - т.е. RS-485, опрос и т.п. Иногда паузы в опросе доходят до 0.8 секунды (обработка скриптов, еще что-то)... Приходит в такой дом гость). Вскоре гостю "приспичило", он подходит к роялю выключателей и пытается найти тот, который включает свет в заветной комнате... Поверьте, с задержкой в полсекунды сделать это не легко (придется пройти первый уровень игры "елочная гирлянда"). Хозяин стоит рядом и краснеет. По-моему, 100 мс - для человека уже чувствительно. Событий происходит не много - по сути всякий раз, когда что-нить щелкаешь, крутишь и т.п. В пределе (10 событий в сек на человека). Думаю, 16 бит на событие вполне достаточно.

В рамках поста №1 хочу заметить, что сеть нужна скорее для задач умного дома, а не для промышленного управления. А это означает: - событийный характер работы; - обмен маленькими пакетами; - минимальное время отклика; - гибкая масштабируемость. ... + В промышленности RS-485 лучше!

Если широта возможностей определяется возможностью передавать более 8 байт в одном пакете, то может показаться что MODBUS шире. К счастью, к вершнему уровню CAN нет жестких требований - поэтому изобретайте свой протокол под конкретную задачу. Хотя, можно и не изобретать - взять готовый (свой или чужой). Надежность у CAN выше. Только надо измерять частно. Передаем ровно 8 байт данных в контроллер CAN и в UART, на другом конце их ловим. CAN доставит достоверные данные, а UART - увы, прочухает только нарушение формата кадра и контроль четности. Часто применим? А в какой области? В авто, что-то RS-485 не используют... Моя реализация CAN: 32 программный буферов на прием и передачу. Т.е. заполняешь нужные поля структуры и выставляешь флажок "готов" для передачи. В прерывании по освобождению передатчика отсылается следующий пакет "готово". На прием тоже просто: заполняется свободный буфер и выставляется его флажок "готово". Никаких контрольных сумм, повторов передачи, мультимастеров в софте нет. Цены уже приводились. Плюс минус пять копеек. Вы хотите чтобы Вас обслужили: 1. Быстро 2. Вкусно 3. Дешево Выбирете 2 пункта. Да, скорость передачи и длина линии связаны. У CAN требование, чтобы значение бита было одинаково во всей сети. Длина и скорость привязаны к констранте с, а ее как известно, не поменяешь. Приведите пожалуйста пример, какой скорости на какой длине Вы добивались на RS-485. Можно подробнее и с примерами, ибо я фанат CAN...

Вроде, CANу от среды нужно немного: - наличие двух состояний среды "доминантное" и "рецессивное"; - при выводе сколь угодно многих "рецессивных" состояний, одно "доминантное" при считывании должно давать "доминантное" в сумме. Оптика: есть/нет света. Радио: есть/нет модулированный сигнал Витая пара: есть/нет разность напряжений. Открытый коллектор, в конце концов.

Длина зависит от скорости. 10кБ/с.

OWON PDS5022S. Второй год пошел - отличная штука. У меня версия 4.1 - можно смотреть видеосигнал по номеру линии. На работе тот же девайс, но со старой прошивкой - такой фичи нет (и кое чего еще). Удобно приделать аккум (есть отсек, пять "пальцев" влезает)- на объекте помогает сильно. Прицепляешь к компу - имеешь красивые графики в отчете, а не фотки с мыльницы, как делалось раньше)

Уж если RS-485, то могу посоветовать две фишечки: 1. Использовать схему приоритетного опроса. Реализуется не сложно,принцип такой: - у каждого узла на шине есть приоритет. - мастер за один цикл опрашивает все узлы с наивысшим приоритетом и одно устройство с приоритетом на единицу ниже (окно). От цикла к циклу в окно последовательно попадают все устройства с приоритетом на единицу ниже и одно на две единицы ниже. Далее рекурсивно. Пример, A, B - наивысшиq приоритет, C, D - чуть ниже, E - низший приоритет. Опрос будет выглядеть так: A B C A B D A B E и т.д. Если какой-то узел не ответил N раз - считаем его потерявшим связь с шиной и устанавливаем низший приоритет. При восстановлении связи с этим узлом - восстанавливаем исходные приоритет. Плюсы: гарантированный период опроса (ограничен сверху), минимизация простоев на шине. Минусы: пока не придумал) 2. После запроса мастера к конкретному слейву, тот отвечает на запрос мастеру и может продолжать занимать шину. Скажем, послать команду другому слейву, а затем освободить шину. Псевдомультимастер ) 3. Недавно всплывала задачка автоматического поиска устройств на шине RS-485 (охранно-пожарная сигнализация с нестабильно конфигурацией - например, поезд с перецепкой вагонов). Готовые контроллеры имеют 24 битный адрес (8 под тип устройства; 16 под идентификатор, прошиваемый на заводе) - тупой перебор займет мнооого времени (скорость 9600, минимальный пакет слейву 7 байт + таймаут неответа), или я не правильно считаю?

Думаю будет интересно: Имея неприятный опыт внедрения "чужих" умных домов, однако же не побоялся сделать себе свой. В спальне под кроватью расположен контроллер с SD-картой, длинным проводочком, релюшкой, полным мостом на 245 логике, и динамиком. Контроллер постоянно измеряет емкость провода, аккуратно прикрепленного к краю одной из спинок кровати. Стоит поднести руку к проводу - загорится свет под кроватью (релюха + светодиоды). Аналогично свет выключается. Искать тапки зимой удобно. В 11.00 с SD-карты играет колыбельная (44100Гц, 10 бит @ 2-ШИМ + полный мост + динамик). В 7.00 играет будильник (довольно спокойная композиция), в 7.30 - более настойчивый трек). Второй контроллер расположен у письменного стола. Имеет аналогичный емкостной датчик, управляет двумя релюхами, имеет вход с ИК-приеника. Со всех пультов что были в доме, можно управлять настольной лампой (одна из релюх). Ей же можно управлять с емкостного сенсора. Вторая релюха пользуется как ШИМ включалка средства от комаров - два часа работает, два отдыхает (ночью). Все это локально работает и удобно для меня и супруги. Но если добавить немножечко CANа, то: - можно управлять настольной лампой с емкостного сенсора кровати (если удерживать 3 секунды). Фича появилась, когда лентяйки забывались на столе, а разработчик с супругой уже были в постели. - можно управлять громкостью звука под кроватью с пульта. особенно удобно выключать будильники. Можно запускать другие треки. - появилась возможность работы с напоминалками. С пульта нажимаешь кнопочку и голосом тебе сообщают об истечении времени по истечении времени. Нажатием кнопки по кругу выбирается "5 мин - 15 мин - 30 мин - выкл". Чайник на кухне стал реже подгорать). - кроме того, есть возможность гонять живую речь между контроллерами у стола и кабинетом. Интерком поверх CAN: "женушка, принеси чай") Все это работает, масштабируется и, что самое интересное, - не глючит. Последний раз глюк был, когда жена повесила на кровать новогоднюю мишуру - контроллеру под кроватью было не легко. Он откалибровался на новые условия и включал свет под кроватью, как мне показалось, даже при мысли о включении света под кроватью) Пришлось автокалибровку отключить. По CANу конфигурирую, круглосуточно мониторю - трафик ничтожный, задержек нет. Как говорится "а Вам слабо, уважаемый RS-485"? Или умный дом это что-то другое? Может, это привычные выключатели и лампочки в альтернативной реализации? - тогда RS-485 рулит, и я сдаюсь)

1. CAN совсем не дорого. 2. Насчет того что нужно мастеру, а что слейву - соглашусь, посмотреть можно и под Вашим ракурсом. Но типичный хомо-сапенс спроектирован для работы по принципу "причина-следствие". Заменив понятия, легко можно из Вашей концепции получить мою, где для актеров "выключатель" и "реле" система должна обеспечить некий сервис. В таком случае, "выключателю" и "реле" уже что-то надо - и с таким положением дел согласится 99% домохозяек. Применив, готовые микросхемы/интерфейсы с событийным характером работы, а не опросным, можно стать ближе к народу и Матушке-Природе, веками оттачивающей свое совершенство. 3. По поводу Заказчиков. Когда работаешь "на себя" - все запускается с первого раза, когда "работаешь на дядю" - как правило, Заказчика выбирает дядя. У них свои интересы, а делать из "г" конфетку за зарплату приходится разработчику. Эх... Заказчик с "100 выключателей" достался мне "по наследству". А с дядей я до сих пор работаю, и мысленно благодарю его за такой бесценный опыт. 4. ПК для конфигурирования и мониторинга очень удобен. Для управления в реальном времени... извиняйте. 5. Не изобретайте велосипед... возьмите готовый... интерфейс из транспорта )

RS-485 без ухищрений - вещь, живущая до первого прецидента, на который разработчик, обычно разводит руками, мол "кто ж знал? помеха...". Не буду озвучивать имен, но не раз приходилось "солидным" конторам грозить пальчиком "ай-я-яй" - в погоне за простотой "обычного мастер-слейва" даже контрольную сумму не стремились использовать. Не надо пытаться делать вещи проще, чем они того заслуживают. Табурет с 3 ногами устойчивее лишь в теории; 5 ног - явный перебор. "Битый жизнью" Мерфи утверждал, что если что-то негативное может случится, то оно случится обязательно с самым максимальным ущербом. Если под "защитой от дурака" понимать несложные программные или аппаратные проверки, уберегающие от явно деструктивного поведения системы при возможных (допустимых физически, реализуемых) входных условиях, то такая защита повышает надежность. Яркие примеры: проверка перед делением на ноль и плавкий предохранитель. Кстати, и прямовключенный диод во входной цепи питания много жизней спас. Мастер, несмотря на всю свою активность, все же товарищ пассивный. Мониторят датчики и клацают релюхи слейвы. В контексте сети, для передачи сигнала о нажатии на кнопку на слейве_1 слейву_2 для управления реле, требуется, чтобы жили: слейв_1, слейв_2, мастер и не пакостничали все оставшиеся. Яркий пример несовместимого по стандарту железа - топор - может запороть любую проводную шину. Пожалуй, поможет кольцевание и сегментация - и тут CANу легче. Разорвав сеть, в случае с CAN получите две маленькие работоспособные сеточки; у RS-485 одна сеть 100% мертвая, вторая - с простоями на шине из-за таймаутов на ответ "потеряных" узлов. То, что есть защищенная от длительного удержания на линии доминантных бит физика - не секрет. Для надежности лучше использовать аппаратные CAN-модули, строго придерживающиеся стандарта. А у меня есть опыт общения с Заказчиком, когда пытаешься объяснить почему не работают "100 выключателей" - а в глазах лишь скорбь... и оттенок зарождающегося сомнения: "может... 100 проводов было бы надежнее... чем 2, но увы - стены ужо стоять, а паркеты ужо лежать". Многие разработчики - произошли от программистов, некоторые от радиофизиков. Статистическая радиофизика утверждает, что все работает с какой-то вероятностью (точнее, интересуется вероятностью "не работы") и учит методам снижения вероятности отказа. Программист всегда работает на исправном железе - "отказ? - перезагрузись!" Не хотите наступать на грабли - используйте для умного дома распределенную сеть и ни когда, слышите, никогда не используйте ПК. CAN Вам в помощь ) ... + купил когда-то ADM485 - так и лежат. Правда, уж второй год на московских АэроЭкспрессах бегает речевое оповещение с RS-485 - тьфу-тьфу... хотя и поезд)... хотя и не мультимастер)

Согласен что надежность и сложность находятся в определенной зависимости при определенных условиях... 1. Использовать сложный в аппаратном, но легкий в программном плане CAN _надежнее_ того же RS-485 с программными "ухищрениями" для получения соизмеримой вероятности необработанной ошибки. Ибо, программист грешен и допускает ошибки. 2. Защита от дурака усложняет, но надежность от этого увеличивается. 3. Распределенная система (CAN) по числу элементов может быть и меньше централизованной на RS-485... Если отказом считать невозможность нормально функционировать какому-то отдельно взятому узлу, то в случае CAN надежность равна надежности одного узла; в случае с RS-485 сумме всех узлов. Например, промышленный модуль I-7015 при "слете" прошивки на ногах проца имеет такой потенциал, что продолжает висеть на шине с _включенным_ передатчиком RS-485. Сеть при этом глючит - найти кто виноват в этом случае, на объекте, в условиях, за потолком или в теплоузле, мягко говоря... ! 4. Если речь идет о "контроллере светодиода", то микросхемы тут не нужны - тупо включатель и провода (надежнее не придумаешь). 5. Контроллер для умного дома или _сети_ уже подразумевает под собой нечто сложное. Ресурса tn13 может не хватить (сейчас или в будущем). Прыгать по камушкам - затратно. 6. tn13 - шикарные микросхемы! ) Постоянно держу неснижаемый остаток штук 50. Пихаю везде, где только можно

Друзья, у схемы "мастер-слейв" есть один существенный недостаток: если нужно поменять конфигурацию сети, скажем, добавить нового слейва, это повлечет за собой конфигурирование мастера, что косвенно может сказаться на остальных слейвах. Второй момент: это когда из 10 устройств на шине работает только одно, остальные, к примеру, отсутствуют (или неисправны). Тормоза на шине гарантированны. Т.е. на работу конкретного слейва влияет работоспособность других слейвов. Подсознательно и на опыте - снижение надежности. Кстати, про "жабу". Если душит STM32F103T за 80 рублей, то может и автоматизировать не надо. Рулить по-старинке, с выключателей. К сэкономленным деньгам добавить еще 4 раза по столько же и сидеть в Инете (на форуме) целый месяц) И уж совсем офф. Блин, ye не можем найти путных разработчиков! Такое впечатление, что ARMы кодят в Ярославле всего три человека (и я их всех знаю). Призываю Вас - решайте задачи адекватно. Не надо "пыхтеть" на PICе, или ставить промышленный комп в задачу, в которую явно напрашивается иное. Главное искусство разработчика встраиваемых систем - нагрузить аппаратные блоки контроллера по максимуму для решения поставленных задач. Включает в себя и выбор оптимальной платформы. По существу темы: интерфейсом для маленькой сети с несколькими мастерами может служить CAN - по-моему, оптимальное решение.

5 mega8 по CAN связать, не то чтобы не получится... проще сделать на контроллере где есть аппаратный CAN. В avr-семействе есть такие, но я их не пробовал. Может, лучше махнуть сразу на C-M3? ;)

А почему не CAN?! Если нужно гонять данные до 8 байт, то самое простое решение (или нет?). Мультимастер, неразрушающий арбитраж, приоритеты, аппаратный контроль целостности, настройка момента выборки, подстройка скорости, счетчики ошибок с автоотключением от шины... Что касается витой пары, то дифференциальная пара, высокая скорость, не дорого и понятно. Кодить тоже приятно и не сложно. По сути реализовать буфер приемника сообщений и буфер передатчика сообщений. Не сложно делать преобразователи CAN что в RS232, что в Ethernet. Где минусы?! У меня восемь месяцев - полет нормальный; верните на грешную землю)

Радио не могу назвать надежным и безопасным. Раз в секунду контроллеры посылают сообщение, чтобы заинтересованный мог знать какие контроллеры есть в сети (по сути узнать все идентификаторы в сети). Я обращал внимание на то, что каждый контроллер сам по себе. Иначе придется вести базу, синхронизировать и т.д. и т.п. Более того - логика в контроллерах сделана на графах. Графы работают параллельно и независимо. Даже при обновлении логики (расширение функционала) контроллер работает непрерывно по старым графам, мгновенно переключаясь на новые после обновления. Я проектировал распределенную систему... + кста, насчет проводков: а питание?

Себе дома сделал на CAN. Контроллер сам по себе: управляет выходами, по информации со входов и другим признакам. Однако, есть возможность "кинуть в сеть" уникальный идентификатор события и принять событие из сети. Возможно передавать параметры в теле события. По CAN прошивается логика, устанавливается время и т.п., а также гоняется аудио-трафик с нескольких переговорных блоков. Есть преобразователь CAN в Ethernet (UDP), для "общения по сеточке" с буком и внешним миром. Скорость делал, вроде, 500 килобит, проверял на катушке CORE4, метров на 100 работает устойчиво (правда терминаторы подбирал щепетильно с осциллографом, но на мегабите). Идентификаторы в контроллеры зашиваю железные. Раз в секунду все контроллеры грят "я жыф".

Чтобы ни случилось UPS должен быть включен, если входное напряжение есть в течение T_ON, и должен быть выключен, если входного напряжения нет в течение T_OFF. Необходимо знать наличие входного напряжения - использовали реле на 24VDC через резистор, конденсатор, два диода (один выпрямительный, второй для защиты от обратного тока), симметричный стабилитрон. Сухой контакт от реле подключался к контроллеру. Необходимо знать включен UPS или нет - подключался к светодиодам UPS ("работа от сети" и "работа от батареи"). Параллельно кнопке/кнопкам включения-выключения установлен транзистор(ы) (схема ОК). Контроллер питается от АКБ, через ключ и стабилизатор. Если напряжение АКБ >40В, еще и через стабилитрон на 9.1В. МК attiny13 настроен на самую низкую частоту тактирования ядра, основное время проводит в спячке, просыпаясь раз в секунду. Он проверяет наличие входного напряжения, по свечению светодиодов определяет включенность UPS. Обрабатывает графы включения/выключения UPS, контроля входного напряжения, таймаутов светодиодов, таймаута самоотключения. При необходимости меняет состояние графов и внешние ноги. При включении не выдает управляющих воздействий - какое-то время просто "наблюдает". После однозначного определения включенности UPS и наличия входного напряжения переходит в активный режим (с возможностью управления). После выключения UPS отключает себя от АКБ.

Модель какая? Я делал для 650 и еще какого-то APC... Схемы отличаются, могу кинуть на почту (схему, граф работы, печатку, софт)

Если я правильно понимаю IEEE1588, то Windows тут ни при чем (роутеры тоже): В Ethernet контроллере есть специальные аппаратные механизмы, которые помогают осуществить синхронизацию, каким бы ни было время обработки пакетов (в разумных пределах, конечно). Принцип, на самом деле не сложен - но если нет аппаратной поддержки, то высокой точности не получишь. Опыт... Я жду звонок по телефону с целью синхронизации часов. Как только телефон зазвонил, я регистрирую время на своих часах, потом неспешно поднимаю трубку, здороваюсь, "как дела?...", попутно узнаю у звонящего сколько было времени, когда он начал вызов. Из одного времени вычитаю второе и получаю разницу. Т.к. к своим часам доверия меньше, то подвожу их в нужную сторону. Теперь два вопросика? 1. Если время прохождения вызова фиксированное, то проведя еще одну попытку синхронизации какую я получу разницу? Правильно, нулевую. 2. Если у телефона сижу не я, а нерасторопная бабушка, которая "ась? кого? сейчас?" - зовет меня, а я регистрирую не время звонка, а время когда я оказался у аппарата? Какую точность можно достичь? IEEE1588 позаботились, чтобы время начала звонка регистрировалось самим телефонным аппаратом и всякие бабушки рояля не играли. Кста, вопрос реализации - это одно, а дядька с точными часами - это другое)

А какая точность Вам нужна? В USB, вроде, SOF приходит раз в 1 мс. Т.е. это совсем другой порядок - не тот, для которого задуман IEEE-1588

Один раз (по-молодости) провел дороги под LM7805... С тех пор зарекся) Маска-маской, а там где возможна проблема - проблема случится.

Странное явление наблюдал на одном типе промышленных материнских плат. В БИОСе есть опция автоматического включения при подаче питания. Так вот, если подать питание, то плата включается. Если снять напряжение и подать его вновь ДО момента писка бипера, то плату можно включить ТОЛЬКО с кнопки POWER - отключения/включения питания не помогают. Поскольку, на объекте все это очень далеко и контроллеров много - ходить "поднимать пингвонов" никто не будет. Поставили электролит, чтобы описываемого ступора не было. Работает 100 из 100. В конце концов строительные работы на объекте были закончены, поставили UPS - и проблема более не всплывала. Как временная мера - электролит вполне подходит. Для гарантированных включений/выключений, по-моему, нужен контроллер (но той же тиньке-осьминогой). Кста, делал контроллер для включения UPS APC - если кому интересно...

Для автоматического включения контроллера (на базе ПК) при подаче питания установить параллельно кнопке "POWER" электролитический конденсатор номиналом 100мкФ х 10В соблюдая полярность.

http://www.mt-system.ru/index.php?id=126 Может у них поспрошать?

Два DAC есть у STM32F107