adnega

Вот так //------------------------------------------------------------- // int date_to_int(int y, int m, int d) //------------------------------------------------------------- int date_to_int(int y, int m, int d) { if(m<3) { m+=12; y-=1; } return ((y*1461)>>2)+((m*306+7)/10)+d-730533; } //------------------------------------------------------------- // void int_to_date(int jd, int &y, int &m, int &d) //------------------------------------------------------------- void int_to_date(int jd, int *y, int *m, int *d) { *d=jd+730533; *y=((*d<<2)/1461); *d-=((*y*1461)>>2); *m=(((*d*10)-7)/306); if(*m==0) { *m+=12; *y-=1; } *d=jd-date_to_int(*y,*m,1)+1; }

Реализовывал, но в пределах от 2000 до 2099 года. Если устроит, есть функции перевода из секунд в дату, из даты в секунды.

"Проводов будет много. И ставить его в комнате негде.") Проводов будет как в обычной квартире. (может больше, но порядок тот же) Жить в микроволновке? Радиомодулям тоже нужно питание (выключатели, например). Радио саботировать легче.

Делал. Правда микрофон у меня не спец и терять пакеты можно. ЦАП работает с частотой дискретизации чуть выше требуемой (точнее ближайшей возможной выше требуемой). Заполняет некоторый буфер. Компандируется, вычисляется энергия, максимумы и проч. Буфер расщепляется на два: один содержит все четные отсчеты, второй - все нечетные. Буфера маркируются инкрементным счетчиком и по UDP отсылаются. Приемная сторона накапливает принятые пакеты в кольцевом буфере. Если потерян один из пакетов пары - происходит копирование из существующего пакета (эквивалентно снижению частоты дискретизации). Если потеряны оба, то копируется предыдущие существующие (ослабленные). Если кольцо заполнено больше чем на половину, то воспроизвожу на один отсчет меньше (один пропускаю), иначе - на один отсчет больше (проигрываю один лишний). При сильном отклонении число отбрасываемых/дополняемый отсчетов пропорционально отклонению. При малом отклонении - корректировку не производим.

Все ли согласны, что слейв должен быть простым устройством? А не будет ли самым верным решением сделать, скажем, "контроллер комнаты"? В контроллер сходятся все провода от всех выключателей и лампочек одной комнаты (порядка 16 входов и 16 выходов; если больше, то можно в комнату поставить несколько контроллеров). Контроллер берет на себя все функции управления электрооборудованием только этой комнаты. Если что-то надо передать в другие "комнаты" или получить из других "комнат" - использует общую сеть. При таком подходе комнаты локально-живучи, сеть не нагружена неактуальным трафиком, все устройства одинаковые по сложности (просто - одинаковые). Я бы предложил следующие критерии: - число "комнатных" контроллеров и места их расположения выбирать с позиций оптимизации кабельных трасс и удобству эксплуатации. Пусть вся проводка комнаты сходится в один щиток (коробку), в котором установлен контроллер, защитные цепи (автоматы, УЗО), резервные цепи (перевод Умного Дома на ручное управление). - в сеть должны передаваться только те сообщения, которые точно будут использоваться другим контроллером/и. При этом надежность передачи высокая не нужна - подумаешь, не выключил свет в ванной из спальни. Попробуй второй раз, в конце концов сходи ножками и выключи. К сети можно подключить "комнатный" контроллер с функцией Ethernet (имея реализацию Ethernet и CAN, скрещивание производится в считанные часы). Риторический вопрос: уважаемый All менял ли когда разбитую лампочку в люстре, управляемой Умным Домом? Нельзя быть уверенным, что ток сейчас не появится. Отрубать автоматы - остаешься без света. Дилемма еще та)

Или, к примеру, DMX512. Есть и UART, и RS-485, но... верхушка другая - называется одним словом "DMX512".

Замечу, что это не доработка, а необходимая надстройка. Система должна решать: - как передавать данные больше 8 байт; - как распределять идентификаторы/приоритеты. Спорить тут действительно не о чем. Любую более-менее реальную систему можно построить и на CAN, и на RS-485 (или еще чем-нить). Вопрос не в физике, вопрос в сложности разработки. В RS-485 относительно "тупые" слейвы и суперсложный Мастер (содержит в себе практически весь функционал системы). Благодаря этому можно клепать дешевые слейвы, а на Мастера можно и раскошелиться. В CAN все одинаковые как по цене, так и по сложности (суперсложность Мастера раскидана по слейвам). "Каждый выбирает для себя". Я придерживаюсь пути: лучше сделать десять сложных вещей, чем одну супер-сложную. Автору ветки (с atmega`ми) конечно быстее будет разобраться с RS-485, но я советую "идти другим путем". Всем Мира и удачи в делах) :cheers: PS: интересно, на чем он будет делать? Без конкретных цифр не интересно. Судя по тому, что все прекрасно ожило через Инет - постоянная времени гораздо больше упоминаемых 100мс. Моя CAN-система может). (с переходником Ethernet-CAN, конечно) Могу по сети поуправлять любым контроллером, поменять параметры, перепрошить в конце концов. Делал управление по TCP/IP - можно заходить на страничку с УД. Хоть в локалке, хоть в Инете, хость с мобилки. Кстати, и RS-485 не проблема прикрутить. (Я надеюсь понятно, что не к CAN-шине).

Хорошо. А attiny13 подойдет? Как никак 64 байта ОЗУ. Хватит ли хранить информацию о всех слейвах? Или atmega8? Уже 1024 байта - под стек, перемнные, буфера, состояния слейвов... atmega128! Дык, это дорого ;) С ПК сразу облом. Скорее всего ОС Windows, а это означает что про миллисекунды можно забыть, иногда, на минуты. Делать в одном потоке - загрузка под 100%. В разных - можешь управление раньше чем через ~14мс не получить. К тому же ПК грузится долго, вирусы, шум, пыль, электроэнергия, а самое главное - он будет дороже контроллера с аппаратным CAN!

Если делать сеть на RS-485, какой контроллер можно взять для Мастера?

Мне кажется, что автор ветки под Мультимасеровостью понимал: //---------------------------- // Контроллер номер раз #define lamp_1 (0) #define lamp_2 (1) #define lamp_3 (2) #define lamp_4 (3) #define button_1 (0) #define button_2 (1) #define button_3 (2) #define button_4 (3) void main(void) { init_all(); while(1) { if(click(button_1)) invert(lamp_1); if(click(button_2)) invert(lamp_2); if(is_message(button_3)) invert(lamp_3); if(click(button_4)) send_message(button_4); } } С CANом is_message и send_message очень просты. Все контроллеры одинаковы, за исключением содержимого while(1), которое пишется под конткретный контроллер и не зависит от других контроллеров. Не нужен дополнительный (или выделенный) контроллер.

Почему же? Звук по домовой шине для меня актуальная реальность. Эдак и про домофон можно сказать, что не надо. Если в доме всего-то 5 выключателей, да 5 лампочек (10 слейвов), 50 метров кабеля, и ничего более, то автоматизировать тут НОЛЬ. А если нужна сложная система? Я как пользователь хочу пойти в магазин, купить коробочку, подключить ее к 4 проводкам, и что бы все что работало ранее - продолжало работать; после настройки событий - заработал новый модуль с новым функционалом. Писать программу для Мастера даже не вздумайте предлагать. А заложить в Мастера весь функционал, который когда либо может быть - утопия. Забыли обсудить еще X10... или 1-wire... )

А если источник звука слейв_1, а приемник слейв_2. Да и общение идет двухстороннее.

16 бит на команду - будем считать, что для передачи полезной информации от устройства к устройству нужно всего два байта. Теперь понятно? То, что можно прокачать по шине трафик не вызывает сомнения. (хотя трафик будет зависеть не от происходящих в системе событий, а от числа слейвов - не айс) Мультимастер получается не нужен - молотим опросом. С кнопками, лампами, воротами... понятно. А я хочу звук! ) В посте 58 описывал рабочую систему. В принципе все можно сделать на RS-485 (если добавить Мастера-бездельника-молотильника). Все, кроме звука.

Там где 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 - по-моему, оптимальное решение.