Продолжаем разрабатывать Умный Дом.
Хотя Умный Дом звучит слишком громко)) Скорее простая автоматизация - управление выключателями и розетками по Интернету))
Сценарии и т.д. - это отдельная тема))
Есть W5500 (подключён к провайдеру) + AVR (управление выключателями и розетками + датчики всякие).
Думаю сделать управление всеми выключателями и розетками по витухе. Да, придётся штробить стены)) Зато надёжно.
Думаю поставить в каждый выключатель и розетку отдельный AVR.

Вопрос:
А какой протокол использовать для связи AVR (в каждом выключателе и розетки) и главного AVR ?
У кого есть опыт разработки таких устройств ?

Лучше поставить не авр, а STM32F0x2 (если у вас пара десятков завалялась, купленных еще по 70 рублей на али; сейчас они огого сколько стоят) и связь сделать по нормальному CAN'у.
Если же так хочется аврки, то можно на крайняк RS-485 замутить, но уж здесь придется самому решать проблему мультимастера (либо ограничиться одним-единственным мастером).
Собственно протокол - любой, какой самому в голову придет. Для CAN можно в первом байте команду передавать, а в остальных семи — параметры. Для 485 лучше всего делать текстовый протокол, чтобы удобно было во время отладки просто подключиться терминалом и вводить данные вручную (и просматривать ответы), скажем "socket r1 off\n" → "OK\n", "socket r1 state\n" → "off\n".

Может будет интересно:
https://z-uno.z-wave.me
тоже вроде под "умный дом" делалось....

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

Открыт интернет-магазин MEAN WELL.Market – весь ассортимент MEAN WELL, выгодные цены

Открыта удобная площадка с выгодными ценами, поставляющая весь ассортимент продукции, производимой компанией MEAN WELL – от завоевавших популярность и известных на рынке изделий до новинок. MEAN WELL.Market предоставляет гарантийную и сервисную поддержку, удобный подбор продукции, оперативную доставку по России. На сайте интернет-магазина посетители смогут найти обзоры, интересные статьи о применении, максимальный объем технических сведений.

Подробнее>>

Пока что просто мысли в слух...


Забыл добавить... Там есть есть бойлеры с таймерами и датчиками... кофеварки... телевизоры... и прочая техника.
Ими с пускателя управлять не получится))

869.0 МГц (Россия)
Скорость передачи: 42 кбит/с, 100 кбит/с и 9.6 кбит/с.
Предельная мощность передачи 1 мВт.

Неее... не хочу беспроводное. Хочу проводное. Причин масса.
-надёжней.
-низкое потребление.
-все устройства в доме хочу питать от одного блока питания/аккумулятора по витухе типа PoE.
-...


Не понял... Чем лучше ?
AVR сейчас стартуют от 70 рублей за штуку на али.
Главное что у меня для них всё есть))

Собственно весь вопрос в том как подключить 20 штук AVR к одному AVR.

Казалось бы нет ничего проще ! А нет ! Не всё так просто))


Добавлено after 13 minutes 31 second:
Переформулируем вопрос.))
Есть куча устройств в доме (от выключателей и розеток до умных телевизоров и стиральных машин).
Вопрос:
Как их всех связать вместе по витухе ? Какой лучше использовать интерфейс и протокол ?


На словах всё просто. В реальности всё сложней.))

Надо:
-надёжность (гарантированная доставка пакетов).
-низкое потребление.
-скорость высокая не нужна.


Добавлено after 16 minutes 20 seconds:

Чем лучше ?
Сейчас у меня простая передача пакетов ФИКСИРОВАННОЙ ДЛИНЫ между МК по принципу чтение/модификация/запись.
С пакетами фиксированной длины проще работать.
Пакеты фиксированной длины имеют фиксированное время передачи. Для пакетов фиксированной длины нужен фиксированный размер буфера. Пакеты фиксированной длины проще обрабатывать (код программы практически на всех устройствах одинаковый).
И т.д. и т.п.

Осталось только придумать как подключить 20 штук AVR к одному AVR. Чтоб онит обменивались пакетами между собой. Вот собственно и вся задача))

LED-драйверы MOSO - надежные решения для индустриальных приложений

Продукция MOSO предназначена в основном для индустриальных приложений, использует инновационные решения на основе более 200 собственных патентов для силовой электроники и соответствует международным стандартам. LED-драйверы MOSO применяются в системах наружного освещения разных отраслей, включая промышленность, сельское хозяйство, транспорт и железную дорогу. В ряде серий реализована возможность дистанционного контроля и программирования работы по заданному сценарию. Разберем решения MOSO подробнее>>

удивительное рядом. Стоит некий модуль в розетке, рядом с которым леппездричества, что через край. Мы же тянем витуху с POE.


Зато можно всё сделать буквально за неделю. И оно будет работать.

Стиралкой, кофеваркой, телевизором зачем управлять удалённо?

1. классический USART даже без драйвера, т.е. TTL-уровни
2. RS-485 - тот же USART, но с физическим драйвером
3. CAN

вариант 1 - самый дешевый, потребление целиком определяется МК, все ведомые МК соединяются параллельно по линиям RX-TX, а потом эта шина подключается к RX-TX ведущего, который всем колхозом и рулит. CRC в пакете даст гарантию доставки данных.

вариант 2 - подороже, посложнее, но по сути то же самое. от 1-го отличается тем, что более помехозащищен на физическом уровне. по экономичности почти такой же, т.к. драйвер в режиме "сна" ничего не потребляет практически

вариант 3 - самый дорогой и сложный, зато самый надежный. для простых протоколов вообще ничего не надо городить, достаточно сообщений CAN, но для обмена информацией поболее 8-и байт придется городить протокол посложнее... есть AVR со встроенным контроллером CAN, есть внешние (через SPI) контроллеры...

я недавно делал по 1-ому варианту устройство, протокол текстовый, скорость обмена 57600 бит/сек. все как часы работало, но расстояния были сантиметровые для квартиры скорость придется понижать, думаю, при 9600 бит/сек можно все реализовать

Хочу Умный Дом с постоянным доступом ко всем устройствам, в любое вмеря суток... 24/7/365 ...))
леппездричество бывают в Доме отключают)) POE не отключается НИКОГДА ! Потому что PoE будет работать от аккумулятора. Например автомобильного))

Мне не надо за неделю)) Можно и за год.
Буду делать дома ремонт - буду закладывать витуху - буду добавлять устройства по мере необходимости. Пока все устройства в доме не будут подключены к серверу с Интернетом.


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



Добавлено after 2 minutes 26 seconds:

Надо подумать... Всё разобрать подробней...

Добавлено after 18 minutes 46 seconds:
Подумали))

Для RS-485 и CAN нужно дополнительное устройство (драйвер).
А зачем нам лепить отдельный драйвер, если сами по себе AVR достаточно умные устройства и могут подключаться к друг другу НАПРЯМУЮ.
Осталось придумать как))


Добавлено after 7 minutes 13 seconds:
Надо придумать топологию.

В AVR есть USART.
Это типа топология "общая шина" с одним ведущим.

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


Что за вариант ?

В AVR нет CAN.
Лепить внешний модуль не хочется...

А как происходит обмен пакетами без коллизий ?


Добавлено after 4 minutes 49 seconds:
Ещё думал использовать топология "кольцо".

Все AVR подключить последовательно и гонять пакеты по кругу))
Ведущий и все ведомые МК соединяются последовательно по линиям RX-TX. В этом случае нет коллизий.

Синхронизация. Тут два варианта:
1-Ведущий всем колхозом рулит.
2-Все равноправные участники обмена. Никто никем не рулит))

Сделать не проблема. Проблема в другом.))
1-Меньше надёжность. Если один AVR сдох - вся сеть легла))
2-Не гарантированная доставка пакетов (возможна потеря пакетов). Для гарантированной доставки нужна буферизация пакетов. А то вдруг все AVR одновременно захотят передавать пакеты))

Всё таки лучше топология "звезда"

20 штук AVR и один AVR главный (он же ведущий ? Или все равноправны ?).

Есть ещё варианты...


Но это уже перебор))
Думаю остановимся на "звезда"

Ну вот, а я три десятка STM32F072CBT6 брал в среднем по 75р за штучку (статистику нарушил последний десяток, который я в этом январе купил аж по 85р за штучку). К нему прицепляется 10-рублевый CAN-конвертер — вуаля!!!
Я в ЖЖшке писал про конвертер CAN-USB, у него (с учетом заказа плат в Китае) себестоимость вышла в 300р С ГАЛЬВАНОРАЗВЯЗКОЙ!

Что вуаля ? Как его цеплять к AVR ?

И кто будет писать протокол управления шиной ? Кто будет бороться с коллизиями ? И т.д.

Добавлено after 2 minutes 49 seconds:
Да не буду я покапать специально STM и к нему прицеплять CAN-конвертер...
Есть 20 AVR которые надо подключить к одному AVR напрямую. Вот и вся задача))
Нафиг мне для этого отдельно покупать STM и CAN ?))


Добавлено after 29 minutes 29 seconds:
Короче...
Есть AVR (мастер, и к нему уже подключен Ethernet).
Осталось придумать как подключить к одному AVR (мастер) ещё 20 штук AVR (слейв).


USART в AVR только один (в больших AVR два). Этого явно мало))
Значит надо или использовать мультиплексор или писать свой протокол.

CAN решает вопрос с коллизиями на уровне физического доступа аппаратно, вам не нужно будет вообще об этом думать.
физическая среда у вас шина, а логическая - звезда: есть мастер, который посылает пакет одному из ведомых и от него же ожидает ответ. сами ведомые никогда не передают ничего, пока мастер не попросит - откуда коллизиям взяться?!
AT90CAN32/64/128 - как это нет?! лично работал с ними!
в сети, где есть главный узел, это не нужно. кольцо - слишком сложно работает, забодаетесь протокол писать
смотря для чего. для простой сети достаточно одного. но и мультиплексировать не сложно. хотя проще взять МК посолиднее с двумя USARTами, если нужно, конечно...

Ниоткуда))


Не работал с такими...


Фиг его знает)) В теории вроде всё просто... Больше смущает низкая надёжность.
Ну и фиг с этим кольцом))

Мультиплексировать не сложно. достаточно найти мультиплексор)) Или использовать в качестве мультиплексора тот же AVR ))

Проблема в другом: в режиме мультиплексирования и в режиме физическая среда общей шины мастер по любому должен постоянно опрашивать все слейвы...
То что мастер будет постоянно слать пакеты опроса - не самое страшное)) Счётчика трафика в локалке нет))
Важнее другое - задержки - мастер должен опросить 20 слейвов прежде чем произойдёт событие...
А при включении например выключателей света задержки мягко говоря немного раздражают)) И чем больше задержки тем больше это раздражает))

Ошибка. Имелось ввиду другое))
-передавать большой объём данных не нужно. А скорость передачи пакетов нужна !
Свет в Умном Доме должен включаться/выключаться с минимальными задержками (на сколько это возможно).


Добавлено after 16 minutes 6 seconds:
Ещё...
У всех схем где мастер постоянно опрашивает слейвы есть ещё один ЖИРНЫЙ минус - мастер и все слейвы не могут уйти в глубокий сон. Мастер должен непрерывно опрашивать все слейвы, а все слейвы должны непрерывно слушать мастера.
В итоге про SLEEP можно забыть)) А значит и про низкое энергопотребление всей системы тоже ))

очередная утопическая тема о высоком превртилачсь в холивар AVR vs STM32

С STM32 я не работал... Их практически не знаю.
Зато я хорошо знаю AVR. ))
Никакая не утопическая)) Тема в стадии активного тестирования на макетках. ))

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

Осталось решить вопрос с синхронизацией мастера и слейвов.

в лоб это невозможно. через костыль если только.

А зачем им глубокий сон? Для сидящих на розетке хватит и IDLE.

Ну значит будем делать через костыль))

Какой розетке ? Все AVR питаются от аккумулятора.

SLEEP.
Для начала выбираем режим сна для AVR. Практически у всех AVR режимы сна одинаковые))

Для тестов берём к примеру популярную ATmega8 и тестер. Измеряем потребляемый ток.

Вот что получилось для ATmega8:

0-Активный режим - 3,3V, RC=8 MHz, 6mA.
1-Режим холостого хода (Idle) - 3,3V, RC=8 MHz, 3mA.
2-Режим снижения шумов АЦП (ADC Noise Reduction) - 3,3V, RC=8 MHz, 2mA.
3-Режим выключения (Powerdown) - 3,3V, RC=8 MHz, ~ 0,5 мкA.
4-В экономичном режиме (Power-save) - 3,3V, RC=8 MHz, ~ 0,5 мкA.
5-В дежурном режиме (Standby) - только для кварца (у нас нет кварца).

Для 20 штук AVR:
0-Активный режим 6mA x 20 штук = 120 mA. Это явно дофига ! Аккумулятора надолго не хватит. Даже автомобильного))
1-Режим холостого хода (Idle) 3mA x 20 штук = 60 mA. Экономия не большая)) Всего в два раза)) Аккумулятора надолго не хватит.))
3-Режим выключения (Powerdown) ~ 0,5 мкA x 20 штук = ~ 10 мкA. Нормально))

Пробуждение AVR по приёму пакета по USART возможен только в Режим холостого хода (Idle).
Но у Режим холостого хода (Idle) слишком большой потребляемый ток: 20 штук = 60 mA.

Вывод:
Да и хрен с этим USART )) Будем делать на костылях))
Будем использовать Режим выключения (Powerdown): 20 штук = ~ 10 мкA.
Нормально))

120мА при 3,3В = 0,396Вт. Пусть КПД ДЦ-ДЦ 80% = 0,495Вт. Значит от 12В аккумулятора будет сосать 41мА... Авто аккумулятора хватит на пару месяцев...
КАН совсем конечно не для умного дома... Тем более нужно чтобы любой мог стать мастером + большая длина сети (помехи, наводки) + относительно быстрое реагирование. Тут только костыли. Хотя вариантов хватает.

Авто аккумулятор слишком жирно будет)) Хватит и простого Li-Ion.

Протокол.
Будем подключать 20 штук AVR по самодельному протоколу))
Возьмём самый простой протокол - с частотным кодированием.

Который использовал ещё мой дедушка во времена своей юности))

К слову... его можно использовать даже для связи по рации))


Добавлено after 15 minutes 54 seconds:
Принцип работы простой:
TX - используем задержки или любой таймер. Переводим биты в импульсы разной частоты.
RX - используем прерывания INT0 по изменению уровня и любой таймер который считает время между изменениями уровня и переводит частоту импульсов обратно в биты.
Всё)) Больше нам ничего не нужно))
Закидываем в протеус...

Всё работает.
Скорость самодельного протокола (при RC = 8 MHz) получилась не менее 20 кБит/с. Пойдёт))
Хотя можно и больше... просто AVR не успевает обрабатывать импульсы более высокой частоты (при RC = 8 MHz).
Для сравнения скорость USART (при RC = 8 MHz) максимум 56 кБит/с. Что не намного больше)) Хотя в реальности получается меньше.. учитывая стартовые и стоповые биты USART.
В нашем самодельном протоколе нет ни стартовых, ни стоповых бит. Пакет передаётся целиком (как в Ethernet).
У нас даже преамбулы нет. Она нам не нужна))

Пакетики между AVR побежали))



Добавлено after 32 minutes 32 seconds:
Теперь самое интересное - режим SLEEP.
Переводим слейв в Режим выключения (Powerdown) и пробуждения по получению пакета от мастера.

Работает. ))
AVR переходит в активный режим (ток потребления 6 mA) только на время приёма и отправки пакета/ всё остальное время AVR спит (ток потребления ~0,5 мкA).
У нас получился самый экономичный слейв ))

Что интересно время пробуждения AVR из Режим выключения (Powerdown) в активный режим составляет менее нескольких микросекунд. Можно измерить точно, только придётся писать прошивку на Ассемблере... а это долго))
Хотя в даташите сказано, что для пробуждения AVR из Режим выключения (Powerdown) требуется ещё не менее 4 миллисекунды (время на запуск RC генератора). В реальности же RC генератору не требуется время вообще)) Или требуется очень мало времени (несколько микросекунд)... Короче я так и не понял сколько точно RC генератору требуется времени...

И так мы подключили один AVR по самодельному протоколу на скорости 20 кбит/c.


Теперь задачка посложней...
Надо подключить 20 штук AVR !!!


))
А я предупреждал... что задачка будет не простая))

у тебя 8 жил... сделай усарт и линию побудки

Будет шина RS-485? А для неё буферный усилитель без вариантов. А жрёт он наравне с МК. Его тоже в сон? А как тогда пробуждаться? Тут верно скзали - CAN шина. Года как раз хватит, чтобы освоить МК с CAN шиной на борту.

Добавлено after 1 minute 33 seconds:

В ADSL модеме вовсе не частотное кодирование.