домофонная система с видеоканалом

[SLvik]

Ну, совсем скрытые датчики движения мне неизвестны А нескрытый будет сразу заметен. Следующий шаг вора какой? Правильно, прийти в натянутой до шеи шапке (чтобы лица не было видно на камеру) и залепить датчик непрозрачным скотчем (а можно наверно и прозрачным). После этого ничего не сработает.:

Попробуйте вариант с ИК. датчиком или лазерным лучом.

Кстати поставить камеру тоже не так просто. Если будут винты, то их сможет отвернуть любой желающий. А если сделать например заклёпки, то сам потом намучаешься открывать. Причём открывать может понадобиться раньше, чем сломается камера – нужно ведь учитывать любителей засовывать спички в любые pinhole отверстия :

Надо делать по такому принципу "Прикркпила и забыла" какой дурак будет обшаривать стену в поисках маленькой дырочки. Никаких болтов, никаких заклёпок которые сразу привлекут внимание. Заклеиваете объектив камеры скотчем и вмуровываете всю камеру в стену не забыв до этого разобрать её и замазать щели герметиком.
Если плата на камере открыта замазать её не очень толстым слоем.
Прямо замажьте её цементом или алебастром с таким рассчётом чтобы край треугольного объектива камеры был в ровень со стеной. Потом закрашиваете это дело. Как высохнет отдирайте скотч от объектива.
Вам одной камеры на 10 лет хватит после чего её можно и ломом выломать она своё отслужит и лазить к ней не надо. Загрязнилась - ночью вышел протёр линзу и дальше.

А, вот вы о чём. Ну так у нас в подъезде просто нет выключателей, свет включается во всём доме централизованно. Точнее, включался (в одном из подъездов стояло фотореле), а последние лет пять горит круглосуточно.

Тогда вам нечего волноваться если никто не знает где выключается свет.

Я говорил про вариант с одним кабелем, как вы предлагали. Когда по одному проводу идёт видеосигнал, а по второму шина + питание (совмещенная). Или я не так понял?

Я имел ввиду, что по кабелю питания идёт шина, а питание у всех устройств своё.

Да, кстати точно шина будет фонить, правда есть ещё шанс выбрать ультразвуковую скорость обмена (если заработает конечно)

Ну это надо чисто эксперементально подобрать.

В том-то и прелесть, что они и не будут работать все одновременно К коаксиалу-то всё равно подключается только одна в каждый момент времени. А значит можно и питание выборочно подавать.

Да, но надо всё равно рассчитывать питание минимум с тройным запасом, а то вдруг релюха видео отключит, а камеру контроллер не выключит.

Это конечно правильно, но про эти датчики я уже написал свои соображения, а для запуска камеры на двери можно так же использовать к примеру акустический датчик (шум на площадке или на поверхности двери – очень хорошо срабатывает), ну или датчик прикосновения к двери (ручка металлическая).

Ну тут много вариантов например емкостной датчик, ИК и т.п.
Если дверь железная ручку нужно изолировать, чтобы при прикосновении к ней сработал датчик.

Почему? Я вообще планировал реализовать подтверждение через ответ ведомого устройства. Грубо говоря, мастер "выкрикивает" его адрес, а в ответ получает набор битов, соответствующих состоянию каналов или коду события. Если в ответ ничего нет, мастер зажигает индикатор Error XX и исключает устройство из дальнейшего обмена "до устранения".)

А если при фонящей шине (Например в этот момент произошёл запуск компрессора холодильника) вы недополучите пару бит или неверно получите. Можно для проверки запустить опрос этого устройства ещё раз и при несовпадении ещё раз - опять тормоза.

Мне бы использовать какой-нибудь стандартный (желательно аппаратный) порт, имеющийся на борту МК. Такая шина – это видимо SPI? Не очень понятно, как её физически кинуть на приличное (метров 50) расстояние.

У вас с компом будет связан один центральный контроллер, который хоть по USB хоть по СОМ порту будет передавать/принимать отчёты от Компа. Т.е. У вас будет как бы две шины переферийная и компьютерная.

Прикол заключается в том, что пока мы "разговариваем" с одним датчиком, захотеть "тоже поговорить" может не одно, а сразу несколько устройств. Да, они без проблем могут дождаться окончания обмена по шине. Но вот как научить их потом "высказываться по очереди"? Опять будет коллизия.
Я когда думал на эту тему, рассматривал вариант введения задержки перед началом "беседы", пропорциональной номеру устройства. Грубо говоря, устройство 1 начало бы вызывать мастера не ранее чем через 1 мкс, устройство 2 - через 2 мкс ну и т.п. Соответственно если у устройств 1 и 9 одновременно есть сообщения, то первым начнет вещать устройство 1, а устройство 9 будет молчать, не дождавшись положенной ему тишины в 9 мкс. Когда устройство 1 закончит, устройство 9 опять подождёт 9 мкс, и если никто больше не хочет "высказаться", приступит к обмену.
Однако этот вариант явно проигрышный, поэтому я даже не пытался его реализовать. А проигрышный он потому, что:
• искусственно замедляет и без того медленный обмен по шине и
• у устройств получаются искусственно назначенные приоритеты, которые создают уязвимость: в верхнем примере если устройство 1 захочет постоянно что-то передавать, то устройство 9 никогда не дождётся своей очереди.

Ну во первых датчиков предполагается не много в основном это управляемые устройства. Во вторых тут надо всё продумать. У меня тоже возникали такие мысли.
Ваш вариант с задержкой от адреса тоже не плох, но всё-же надо и его продумать.
И ещё в моей шине передающее устройство поднимает шину и ждёт активности от контроллера, а контроллер подавая CLK считывает данные с устройства. Т.е всем управляет Master.

Вот это я не понял, куда его нужно добавлять. По идее, если успешный обмен состоялся, то никаких доп. подтверждений уже не надо? Ведомый вызвал мастера, мастер ответил считыванием инфы – вот и подтверждение. Если считывания нет, вызываем снова.
А 9-й бит я хотел задействовать для реализации Multi-Processor Communication Mode, конструктивно предусмотренного в AVR. Это опознавательный бит байта адреса.

Вы знаете шину I2C там 9бит как раз бит подтверждения приёма пакета данных. Пакет можно сделать 8ми 10ти 16ти битным - зависит от того сколько адресов и данных в нём передаётся.
И как вы узнаете успешно приём состоялся или нет СМ. выше я писал.
А с Atmel я не дружу. Всё больше на PICах.
Неохота переходить на Atmel также как вам на PIC.

Кстати, а может вместо CLK и DATA лучше сделать линии RXD/TXD? Хотя проблему с трафиком на шине это не снимает, ну может хоть скорость будет повыше...

Разница в том, что одна шина принимает другая передаёт и всё по одному проводу та что это однопроводная система на двух проводах только по одному проводу идёт приём (RXD), а по другому передача (TXD).

К стати если вам скорость не критична можно сделать всё на 1wire благо там выбор огромный. Например DS2405 - адресуемый ключ можно как писать, так и читать снего 1бит.
www.maxim-ic.com

Чтобы исключить всякие косяки лучше конечно устроить постоянный опрос датчиков. Устройства управляющие камерами можно постоянно не опрашивать, но после записи в них необходимо их читать, чтобы удостовериться в срабатывании той или иной камеры.

[Секретный кот]

Попробуйте вариант с ИК. датчиком или лазерным лучом.

ИК датчик – это пиросенсор? Так ему линза нужна, а она немаленькая. А если просто делать пересечение луча (ИК или лазерного), то это уже получается самопал.

Тогда вам нечего волноваться если никто не знает где выключается свет.

Гораздо проще разбить или просто выкрутить лампочку, тем более что в основном они доставаемы рукой. Но не суть.

Да, но надо всё равно рассчитывать питание минимум с тройным запасом, а то вдруг релюха видео отключит, а камеру контроллер не выключит.

Скажу по секрету: я рассчитываю коммутировать и то, и другое одним реле

А если при фонящей шине (Например в этот момент произошёл запуск компрессора холодильника) вы недополучите пару бит или неверно получите. Можно для проверки запустить опрос этого устройства ещё раз и при несовпадении ещё раз - опять тормоза.

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

Мне бы использовать какой-нибудь стандартный (желательно аппаратный) порт, имеющийся на борту МК.

У вас с компом будет связан один центральный контроллер, который хоть по USB хоть по СОМ порту будет передавать/принимать отчёты от Компа. Т.е. У вас будет как бы две шины переферийная и компьютерная.

Про комп сейчас пока вообще речи нет, я имел в виду порт на МК, из которого будет условно выходить шина системы. Хотелось бы использовать нечто аппаратное (Serial, SPI, I2C/TWI), чтобы не заморачиваться с низкоуровневым обработчиком протоколов.
Потом можно действительно прицепить комп, по любому порту, это далеко не первоочередная задача.

Ну во первых датчиков предполагается не много в основном это управляемые устройства.

Наоборот, управляющие. То есть устройства, которые могут сами генерировать события. Если посмотреть, то не так их уж будет и мало: выключатели света, любые датчики, часы, приёмники ИК ДУ. Хотя всё это конечно будет сгруппировано в нескольких более крупных устройствах, опрашивать-то всё равно придётся каждый датчик индивидуально.
У меня предварительно запланировано так: первый байт, посылаемый мастером - адрес (т.е. 9 битный всегда с первой единицей). Если второй бит равен 1, то обращение к датчику, если 0 - выдача команды на исполнительное устройство. Таким образом имеем до 128 датчиков и до 128 исполнительных устройств. Думаю, для моих целей хватит. С каждым адресом мы теоретически можем обмениваться любым количеством байтов данных, но лучше конечно не нагромождать. Ориентировочно 2-4+CRC.

Ваш вариант с задержкой от адреса тоже не плох, но всё-же надо и его продумать.

Очень смущают тормоза. Всё зависит от единицы задержки, чем она больше, тем больше тормозов (т.к. последний датчик будет вынужден ждать аж 128 единиц!). А она сама зависит от скорости безглючного обмена по шине, которую надо устанавливать экспериментально. А то где-то видел, что она будет не выше 1200 б/с, это просто беда. Получится эстоооонский умный дом какой-то.

И ещё в моей шине передающее устройство поднимает шину и ждёт активности от контроллера, а контроллер подавая CLK считывает данные с устройства. Т.е всем управляет Master.

Так это всё-таки SPI у вас, или я чего-то не понимаю?

Вы знаете шину I2C там 9бит как раз бит подтверждения приёма пакета данных. Пакет можно сделать 8ми 10ти 16ти битным - зависит от того сколько адресов и данных в нём передаётся.

Я не очень вникал в этот протокол, т.к. он реализуется на AVR аппаратно Но видимо 9-й бит выполняет функцию 1-битового CRC? В таком случае гарантии успешного приёма он не даёт, просто чуть повышает вероятность. Да и 8-битовый CRC тоже конечно ничего не гарантирует на 100%, но вероятность всё же существенно повышает.

А с Atmel я не дружу. Всё больше на PICах.
Неохота переходить на Atmel также как вам на PIC.

В свете тех материй, которые мы тут обсуждаем, конкретная железяка уже не очень важна. Всё это можно и на КР580 при желании замутить

Кстати, а может вместо CLK и DATA лучше сделать линии RXD/TXD? Хотя проблему с трафиком на шине это не снимает, ну может хоть скорость будет повыше...

Разница в том, что одна шина принимает другая передаёт и всё по одному проводу та что это однопроводная система на двух проводах только по одному проводу идёт приём (RXD), а по другому передача (TXD).

Не совсем так, т.к. при таком раскладе можно передавать и принимать одновременно (фулл дуплекс). По сравнению с однопроводной системой это вдвое быстрее. Только над протоколом конечно придётся попотеть.

К стати если вам скорость не критична можно сделать всё на 1wire благо там выбор огромный. Например DS2405 - адресуемый ключ можно как писать, так и читать снего 1бит.
www.maxim-ic.com

Нет я всё-таки хочу сделать однопроводку попроще, т.к. не очень представляю, как цеплять к далласам внешние устройства (те же датчики и пр.), да и недешево это выйдет.
Сейчас весь вопрос в том, какую практическую скорость удастся выжать из шины. Вот немного появится времени, замучу первые 2 устройства, повешу на концы шины и буду гонять данные с разной скоростью. Потоковый звук, наверно, для этого идеально подойдёт Вот и посмотрим на CRC с учётом искрящего холодильника и прочих мешающих факторов

[SLvik]

ИК датчик – это пиросенсор? Так ему линза нужна, а она немаленькая. А если просто делать пересечение луча (ИК или лазерного), то это уже получается самопал.

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

Скажу по секрету: я рассчитываю коммутировать и то, и другое одним реле

Камеру лучше включать ключом, хотя если релюха с двойной парой, то неважно.

Про комп сейчас пока вообще речи нет, я имел в виду порт на МК, из которого будет условно выходить шина системы. Хотелось бы использовать нечто аппаратное (Serial, SPI, I2C/TWI), чтобы не заморачиваться с низкоуровневым обработчиком протоколов.
Потом можно действительно прицепить комп, по любому порту, это далеко не первоочередная задача.

Да, чуть-чуть недопонял,- бывает.

Наоборот, управляющие. То есть устройства, которые могут сами генерировать события. Если посмотреть, то не так их уж будет и мало: выключатели света, любые датчики, часы, приёмники ИК ДУ. Хотя всё это конечно будет сгруппировано в нескольких более крупных устройствах, опрашивать-то всё равно придётся каждый датчик индивидуально.

А зачем ИК д.у. если не секрет. Ну часы можно и бортовые сделать. Т.е. на самом контроллере.

У меня предварительно запланировано так: первый байт, посылаемый мастером - адрес (т.е. 9 битный всегда с первой единицей). Если второй бит равен 1, то обращение к датчику, если 0 - выдача команды на исполнительное устройство. Таким образом имеем до 128 датчиков и до 128 исполнительных устройств. Думаю, для моих целей хватит. С каждым адресом мы теоретически можем обмениваться любым количеством байтов данных, но лучше конечно не нагромождать. Ориентировочно 2-4+CRC.

Лучше сначала адрес передавать, чтобы к передаче действия или команды остальные устройства уже отфильтровались.
Ещё неплохо бы иметь группу общих адресов например на группу выключателей даёшь адрес группы и что группа должна сделать, например выключить везде свет. Так съэкономите время от выключения скажем каждого МК поотдельности.

И ещё в моей шине передающее устройство поднимает шину и ждёт активности от контроллера, а контроллер подавая CLK считывает данные с устройства. Т.е всем управляет Master.

Так это всё-таки SPI у вас, или я чего-то не понимаю?

Да, похоже, но упрощённо ибо в обоих системах передачу/приём ведёт Master выдавая CLK.
Очень неудобно будет, кода каждое устройство будет генерить свой CLK.

Вы знаете шину I2C там 9бит как раз бит подтверждения приёма пакета данных. Пакет можно сделать 8ми 10ти 16ти битным - зависит от того сколько адресов и данных в нём передаётся.

Я не очень вникал в этот протокол, т.к. он реализуется на AVR аппаратно Но видимо 9-й бит выполняет функцию 1-битового CRC? В таком случае гарантии успешного приёма он не даёт, просто чуть повышает вероятность. Да и 8-битовый CRC тоже конечно ничего не гарантирует на 100%, но вероятность всё же существенно повышает..

В I2C девятый бит просто показывает успешное завершение передачи/приёма 8ми битного слова. Не растерялись ли где биты по дороге или Slave принял 8бит с ошибкой или просто нет устройства приёма.

Не совсем так, т.к. при таком раскладе можно передавать и принимать одновременно (фулл дуплекс). По сравнению с однопроводной системой это вдвое быстрее. Только над протоколом конечно придётся попотеть.

Да это надо продумать, но идея хорошая, но как быть с адресом. Ведь сначала его всё равно надо передавать, а потом обмениваться данными. Но и в этой системе Master будет вести шину. Например передача/приём будет вестись с одинаковой частотой и синхронизироваться по полжительному фронту с TXD Master`a. Т.е. мастер ставит 1цу в шину Slave тоже ставит 1цу далее если передаётся 0 Master убирает шину в 0 если 1, то задерживает на некоторое время, потом для следующего строба убирает шину в 0.
Тоже повторяет Slave, только в обратку.
Получается какбы 1wire, но двухсторонняя.

Сейчас весь вопрос в том, какую практическую скорость удастся выжать из шины. Вот немного появится времени, замучу первые 2 устройства, повешу на концы шины и буду гонять данные с разной скоростью. Потоковый звук, наверно, для этого идеально подойдёт Вот и посмотрим на CRC с учётом искрящего холодильника и прочих мешающих факторов

По однопроводной шине не сделать высокую скорость. Как не крути придёшь к 1wire, но разве что без генерации Start/Presence pulse.

[S.T.A.L.K.E.R.]

ЭЭЭЭЭЭЭ, нифига се обсуждение, я не могу стока прочитать!!!!
так кто нить чё нить придумал как сделать чтоб.....(написано в моем предыд посте а то уже руки флудить устали....)
а кстате а как вам идея привода видеокамеры???

[Секретный кот]

Скажу по секрету: я рассчитываю коммутировать и то, и другое одним реле

Камеру лучше включать ключом, хотя если релюха с двойной парой, то неважно.

Я выбрал реле с двойными контактами, но лучше было бы взять вообще с тройными, чтобы коммутировать ещё и аудиосигнал. Но по аудио я решил включать всё просто параллельно, благо там сопротивления сравнительно высокие.

А зачем ИК д.у. если не секрет. Ну часы можно и бортовые сделать. Т.е. на самом контроллере.

Как зачем, это же "умный дом", а не просто охранная система. ИК ДУ для управления нагрузками, например регулировать яркость люстры
Бортовые часы – плохой вариант, во-первых у них с точностью проблемы, а во-вторых, гораздо удобнее использовать отдельную специальную микруху со своим питанием к тому же, я взял PCF8583. Она ещё и календарь ведёт.

У меня предварительно запланировано так: первый байт, посылаемый мастером - адрес (т.е. 9 битный всегда с первой единицей)

Лучше сначала адрес передавать, чтобы к передаче действия или команды остальные устройства уже отфильтровались.

Так он и передаётся первым. Причём в AVR есть аппаратные средства фильтрации адреса (то самое MPCM, которое я и хочу использовать).

Ещё неплохо бы иметь группу общих адресов например на группу выключателей даёшь адрес группы и что группа должна сделать, например выключить везде свет.

С этим конечно хуже, хотя конечно можно использовать в качестве адреса группы набор битов из индивидуальных адресов. Ну например, все устройства с адресом 0111ХХХХ считать принадлежащими к 7-й группе.
С реализацией групповой команды другая засада: получается, все реле должны сработать одновременно, а это резко увеличивает нагрузку на питание. Например, одно реле потребляет 25 мА, а 10 – соответственно уже 250. Я всё же планирую групповые команды реализовать через выдачу набора одиночных инструкций мастером. Хотя задержка некоторая и будет, но на глаз это будет едва заметно.
Плюсы тут такие: в группу можно объединять абсолютно любые адреса. Мастер, получив команду "выключить группу", просто переберёт их все и выдаст каждому устройству команду выключиться.

Не совсем так, т.к. при таком раскладе можно передавать и принимать одновременно (фулл дуплекс). По сравнению с однопроводной системой это вдвое быстрее. Только над протоколом конечно придётся попотеть.

Да это надо продумать, но идея хорошая, но как быть с адресом. Ведь сначала его всё равно надо передавать, а потом обмениваться данными. Но и в этой системе Master будет вести шину.

Всё правильно, просто передав адрес устройства, мастер может ожидать его ответа и при этом уже передавать следующий адрес, например.
Естественно, при этом нужно будет соединить TXD мастера с RXD всех слейвов, и TXD всех слейвов с RXD мастера.

По однопроводной шине не сделать высокую скорость. Как не крути придёшь к 1wire, но разве что без генерации Start/Presence pulse.

Ну хотя бы без этой фигни, и то хорошо, к тому же адреса всех устройств на шине мастер будет знать заранее.

кстате а как вам идея привода видеокамеры???

Которая?

[SLvik]

Но по аудио я решил включать всё просто параллельно, благо там сопротивления сравнительно высокие.

Правильно. Я бы тоже так сделал.

А зачем ИК д.у. если не секрет. Ну часы можно и бортовые сделать. Т.е. на самом контроллере.

Как зачем, это же "умный дом", а не просто охранная система. ИК ДУ для управления нагрузками, например регулировать яркость люстры

Ну включение выключателя от ИК будет заниматься контроллер установленный в данной комнате. А в шину он будет передавать только включили ли его или выключили, ну или спрашивать у Mastera можно включить по ИК или нельзя, Правда в таком случае включение произойдёт с задержкой. Пока Master доберётся до него, потом на следующем кругу пока ответит.
Поэтому я и ЗА возможность запросов к Master`у со стороны Slave`a.

Бортовые часы – плохой вариант, во-первых у них с точностью проблемы, а во-вторых, гораздо удобнее использовать отдельную специальную микруху со своим питанием к тому же, я взял PCF8583. Она ещё и календарь ведёт.

Ну так ведь это я и имел ввиду, просто я подумал, что вы хотите подвести шину к часам на стене.
Рекомендую мс DS1340 у неё кроме календаря есть коррекция +/- 32 импульса/сек. по моему, ну или более дешёвые PCF8583 или DS1307.
И те и другие я использовал, хотя они отличаются друг от друга.
Сейчас остановился на DS1340, хотя коррекцию можно и программно замутить.

Так он и передаётся первым. Причём в AVR есть аппаратные средства фильтрации адреса (то самое MPCM, которое я и хочу использовать).

Я просто подумал, что первым битом у вас идёт режим запись/чтение.
А потом адрес.

Ещё неплохо бы иметь группу общих адресов например на группу выключателей даёшь адрес группы и что группа должна сделать, например выключить везде свет.

С этим конечно хуже, хотя конечно можно использовать в качестве адреса группы набор битов из индивидуальных адресов. Ну например, все устройства с адресом 0111ХХХХ считать принадлежащими к 7-й группе.

Да, но 7-й группе необходим отдельный адрес, поэтому я и говорю, что каждое устройство должно иметь как-бы два адреса - свой адрес и адрес группы к которой оно принадлежит.
Т.е. Master может обратиться к конкретной группе, например, выключателей и послать команду выключения и все Slave`ы принадлежащие к одной группе выполнят эту команду.
Естесственно это не относится к чтению устройств ибо на выходе получите лог. ИЛИ всех устройств и скорее всего это будут н0000000ли.

С реализацией групповой команды другая засада: получается, все реле должны сработать одновременно, а это резко увеличивает нагрузку на питание. Например, одно реле потребляет 25 мА, а 10 – соответственно уже 250. Я всё же планирую групповые команды реализовать через выдачу набора одиночных инструкций мастером. Хотя задержка некоторая и будет, но на глаз это будет едва заметно.
Плюсы тут такие: в группу можно объединять абсолютно любые адреса.

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

Мастер, получив команду "выключить группу", просто переберёт их все и выдаст каждому устройству команду выключиться.

Это займёт кучу времени, а если у вас 200 выключателей и вы каждый перебором выключаете, да и ещё не забывайте про проверку действий контроллера. А вдруг глюк на шине и какое-то устройство из 200 не сработает.
А так Master передаёт адрес группы и команду и вся группа отключается за время в 200 раз меньшее, чем вам потребовалось бы перебором.
А для уверенности можно пропустить команду группы два раза.
Ну или потом по кольцу опросить каждый датчик, даже при этом скорость повысится в два рвза ибо по кольцу идёт только проверка, но не включение.

Всё правильно, просто передав адрес устройства, мастер может ожидать его ответа и при этом уже передавать следующий адрес.

А как же CRC? Ведь адрес следующего устройства уже был передан, а данные не прошли проверку и в результате получаем данные с другого устройства либо останавливаем шину и обращаемся конкретно к устройству либо запоминаем его и после прохождения по кругу его отдельно опрашиваем. Опять тормоза.

Нет надо продумать арбитраж между устройствами, чтобы они передавали данные Master`у.

кстате а как вам идея привода видеокамеры???

Которая?

Ну он имеет ввиду управление этой камерой по вашей шине. Т.е. вращение камеры и подъём/опускание объектива, ну и возможно zoom.
Насколько я понял, но эта идея скорее всего не для вас. Т.к. вы не рискнёте подъвесить такую, немаленькую, камеру под потолком.

[Секретный кот]

Ну включение выключателя от ИК будет заниматься контроллер установленный в данной комнате. А в шину он будет передавать только включили ли его или выключили, ну или спрашивать у Mastera можно включить по ИК или нельзя

В том-то и дело, что обо всём должен быть в курсе Мастер. Даже если его разрешение не требуется. Т.к. Мастер ведёт журнал всех событий в системе. Соответственно датчики генерируют события, а Мастер на их основе принимает решения, кому что нужно делать.

Ну так ведь это я и имел ввиду, просто я подумал, что вы хотите подвести шину к часам на стене.

Вовсе нет Я просто имел в виду, что часы могут быть выполнены в виде отдельного от Мастера устройства, соответственно каждую минуту они будут должны генерировать свои события на шине. Для управления по времени например.

Рекомендую мс DS1340

Я уже купил PCF8583 Но буду иметь в виду, спасибо.

Я просто подумал, что первым битом у вас идёт режим запись/чтение. А потом адрес.

Не совсем так. Первый бит в 9-битной посылке определяет адрес/данные. Данные игнорируются slave-устройствами, а адрес проверяется на совпадение с собственным. Если совпадает, то следующая посылка данных принимается. В общем, тот самый режим MPCM.

например, все устройства с адресом 0111ХХХХ считать принадлежащими к 7-й группе.

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

Так тут и получается, что у устройства есть свой адрес, например 0111 0001 и адрес группы: 0111. Соответственно, всем устройствам, которые мы хотим причислить к этой группе, мы должны присвоить адрес вида 0111.

С реализацией групповой команды другая засада: получается, все реле должны сработать одновременно

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

Да опять же, камеры тут уже не очень причём, если мы например включаем группу светильников, то все их реле одновременно подключатся к питанию. Что может вызвать перегруз. А насчёт камер – так включаем по одной и всё ОК.

Это займёт кучу времени, а если у вас 200 выключателей

Ну да, это конечно смущает несколько, зато адресация получится единообразная. К тому же придётся использовать такое понятие как сценарий (программируемый пользователем). Это когда любой набор нагрузок назначается на включение "одной кнопкой", причём кроме параметра "включён-выключен" ещё используются параметры типа "уровень мощности, %" или "отправляемая ИК команда, адрес/данные". Гибко переназначать адреса групп всё равно не получится, ну или вводить дополнительный байт во все адреса.

А как же CRC? Ведь адрес следующего устройства уже был передан,

Нет, постойте. CRC всегда проверяется на приёмном конце. То есть мастер шлёт пакет данных + CRC к нему, а слейв принимает всё это и проверяет на совпадение. Если совпадения нет, то команда просто отбрасывается до следующего сеанса связи. Можно сделать также контроль мастером исполнения его команд через опрос состояния исполнительных устройств.

он имеет ввиду управление этой камерой по вашей шине. Т.е. вращение камеры и подъём/опускание объектива, ну и возможно zoom.
Насколько я понял, но эта идея скорее всего не для вас. Т.к. вы не рискнёте подъвесить такую, немаленькую, камеру под потолком.

Такая готовая камера стоит около 40 штук, так что этот вариант для подъездного использования точно отпадает А вообще нет никаких проблем для управления любыми приводами по шине, только вот точность позиционирования будет наверно не очень. Лучше для этой цели взять специальную IP-камеру с полноценным PTZ приводом, ну при желании можно найти тыщ за 6.

[SLvik]

В том-то и дело, что обо всём должен быть в курсе Мастер. Даже если его разрешение не требуется. Т.к. Мастер ведёт журнал всех событий в системе. Соответственно датчики генерируют события, а Мастер на их основе принимает решения, кому что нужно делать.

Master по любому будет знать состояние всех датчиков. Ведь он их опрашивает по кругу.

Я просто имел в виду, что часы могут быть выполнены в виде отдельного от Мастера устройства, соответственно каждую минуту они будут должны генерировать свои события на шине. Для управления по времени например.

Я думаю не стоит делать часы отдельно от контроллера. Во первых это лишний раз нагрузит шину. Во вторых к PCF8583 можно параллельно подцепить память 24С512 где вести журнал.
К томуже шина I2C в несколько десятков раз скоростнее, чем будет ваша переферийная.

Не совсем так. Первый бит в 9-битной посылке определяет адрес/данные. Данные игнорируются slave-устройствами, а адрес проверяется на совпадение с собственным. Если совпадает, то следующая посылка данных принимается. В общем, тот самый режим MPCM.

Совершенно лишний бит т.к. и так понятно чей адрес был первый того и данные последующие за ним.

Так тут и получается, что у устройства есть свой адрес, например 0111 0001 и адрес группы: 0111. Соответственно, всем устройствам, которые мы хотим причислить к этой группе, мы должны присвоить адрес вида 0111.

Вы хотите сделать первый полубайт адресом группы? Если так то в группе будет только 16 устройств.
Я имел ввиду:
У вас есть адреса устройств 00...FF т.е. 256 адресов. из этих 256ти адресов мы выделяем например 7 адресов для 7ми групп (F9...FF).
И каждое устройство будет иметь два адреса например 01 его индивидуальный адрес, а FA адрес группы к которой это устройство принадлежит. Т.е. при индивидуальном обращении Master передаёт индивидуальный адрес устройства(00...F8), а при групповом обращении адрес группы(F9...FF). Устройства принявшие адрес группы(например FE) опознают его как свой и выполнят одно и тоже действие.

С реализацией групповой команды другая засада: получается, все реле должны сработать одновременно
включаем группу светильников, то все их реле одновременно подключатся к питанию. Что может вызвать перегруз. А насчёт камер – так включаем по одной и всё ОК..

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

Ну да, это конечно смущает несколько, зато адресация получится единообразная. К тому же придётся использовать такое понятие как сценарий (программируемый пользователем). Это когда любой набор нагрузок назначается на включение "одной кнопкой", причём кроме параметра "включён-выключен" ещё используются параметры типа "уровень мощности, %" или "отправляемая ИК команда, адрес/данные". Гибко переназначать адреса групп всё равно не получится, ну или вводить дополнительный байт во все адреса.

Вы определите для начала сколько будет групп.
Например:
Камеры,
Выключатели,
Ну и ещё чего там Мне чтото кроме двух групп не хватает фантазии.

Нет, постойте. CRC всегда проверяется на приёмном конце. То есть мастер шлёт пакет данных + CRC к нему, а слейв принимает всё это и проверяет на совпадение. Если совпадения нет, то команда просто отбрасывается до следующего сеанса связи. Можно сделать также контроль мастером исполнения его команд через опрос состояния исполнительных устройств.

Непонятки получатся устройство сработает с задержкой(На втором круге).

[Секретный кот]

Master по любому будет знать состояние всех датчиков. Ведь он их опрашивает по кругу.

Ну значит всё-таки будем кольцевой трафик гонять. Я-то думал, мы ищем вариант, как обойтись без этого

Я думаю не стоит делать часы отдельно от контроллера.

Возможно вы и правы. Только хватит ли мастеру ресурсов для постоянного опроса шины, обработки запросов, да ещё и заглядывания в календарь с попутным формированием сценариев? Первоначально я хотел сделать мастера тупым «регулировщиком на перекрёстке», а чтобы все мозги были в другом контроллере (а к нему уже и часы, и клавиатуру, и комп, короче говоря мозг системы).

Во первых это лишний раз нагрузит шину. Во вторых к PCF8583 можно параллельно подцепить память 24С512 где вести журнал.

Часы и память совершенно независимо можно прицепить к любому устройству в системе. У метеостанции, например, будет свой журнал (из-за специфики её событий).

К томуже шина I2C в несколько десятков раз скоростнее, чем будет ваша переферийная.

Это понятно, но для управления по часам нам не нужна точность в тысячные доли секунды

Не совсем так. Первый бит в 9-битной посылке определяет адрес/данные.

Совершенно лишний бит т.к. и так понятно чей адрес был первый того и данные последующие за ним.

Он отнюдь не лишний! Вот представьте, устройству 1 мы шлём например 3 байта, а затем устройству 2 - 2 байта, ну и т.п. Каким образом следующее устройство поймёт, что мы уже шлём его адрес, а не очередные данные для предыдущего? Первый бит как раз служит для выделения адреса. Главная прелесть этого метода заключается в том, что он реализован в AVR аппаратно. Можно запустить МК в такой режим, когда он реагирует только на адресные посылки, а чужой поток данных пропускает мимо. Это очень экономит ресурсы локальных устройств, им нет необходимости постоянно анализировать обмен на шине.

Вы хотите сделать первый полубайт адресом группы? Если так то в группе будет только 16 устройств.

Совершенно верно. При таком раскладе получается 8 групп по 16 адресов (с учётом, что остальные 128 адресов будут заняты датчиками).

Я имел ввиду:
У вас есть адреса устройств 00...FF т.е. 256 адресов. из этих 256ти адресов мы выделяем например 7 адресов для 7ми групп (F9...FF).
И каждое устройство будет иметь два адреса

А, я понял. Ну в принципе такое тоже можно сделать. Надо просто прописать соответствующую двойную таблицу адресов каждому исполнительному устройству.

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

А кто заставляет использовать релюхи без фиксации? Этак сама система начнёт жрать несколько десятков ватт, причём совершенно впустую.

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

Хотелось бы ограничить её на уровне хотя бы 500 мА на всю шину. Если использовать простые реле, то это всего 20 одновременно включенных каналов (причём не считая потребления самих контроллеров, всяких там LEDов для красоты и пр.).

К тому-же для изменения яркости и включения можно использовать симистор. (С люминесцентными лампами это не пройдёт).

Почему, для включения вполне должно пройти. А диммирование люма вообще песня, там простейший низковольтный интерфейс. У меня свет в основном люминесцентный будет (точнее, уже есть ).

Вы определите для начала сколько будет групп.
Например: Камеры, Выключатели,
Ну и ещё чего там Мне чтото кроме двух групп не хватает фантазии.

А зачем камеры объединять в группу, если мы всё равно их включаем по одной? Группы же будут такие: например, "весь свет в гостиной", "подсветка подоконников во всём доме", "монитор + видак в прихожей", ну и т.п. В идеале хотелось бы их сделать гибко переназначаемыми прямо через шину (чтобы не тыкать каждый раз во все устройства программатором ).
К тому же надо не забыть про очень нужную группу "Всё выключено" (когда уходишь из дома, тыкаешь единственную кнопочку и все забытые утюги отключаются ).

Нет, постойте. CRC всегда проверяется на приёмном конце.

Непонятки получатся устройство сработает с задержкой(На втором круге).

Правильно, но думаю это всё же лучше, чем будут хаотично срабатывать не те устройства

[SLvik]

Ну значит всё-таки будем кольцевой трафик гонять. Я-то думал, мы ищем вариант, как обойтись без этого

Не знаю, но вы всё больше к этому ведёте.
Я всёже склоняюсь к возможности контролерам датчиков самим инициировать шину. Решить вот только проблему с арбитражом устройств.

Возможно вы и правы. Только хватит ли мастеру ресурсов для постоянного опроса шины, обработки запросов, да ещё и заглядывания в календарь с попутным формированием сценариев? Первоначально я хотел сделать мастера тупым «регулировщиком на перекрёстке», а чтобы все мозги были в другом контроллере (а к нему уже и часы, и клавиатуру, и комп, короче говоря мозг системы).

Т.е. вы хотите разграничить обязанности чтобы, например, через каждое полное кольцо контроллер выдавал отчёт главному МК.

К томуже шина I2C в несколько десятков раз скоростнее, чем будет ваша переферийная.

Это понятно, но для управления по часам нам не нужна точность в тысячные доли секунды

Да, но это избавляет и без того перегруженную шину от лишнего устройства. Или вам нехватает портов МК.

Вот представьте, устройству 1 мы шлём например 3 байта, а затем устройству 2 - 2 байта, ну и т.п. Каким образом следующее устройство поймёт, что мы уже шлём его адрес, а не очередные данные для предыдущего? Первый бит как раз служит для выделения адреса. Главная прелесть этого метода заключается в том, что он реализован в AVR аппаратно. Можно запустить МК в такой режим, когда он реагирует только на адресные посылки, а чужой поток данных пропускает мимо. Это очень экономит ресурсы локальных устройств, им нет необходимости постоянно анализировать обмен на шине.

Но предполагается, что между пачками данных будет либо небольшая пауза в три такта или надо делать некое СТАРТ условие.
А если данные будут идти сплошным потоком, то устройство глюканувшее или пропустившее такт не правильно распознает бит адрес/данные.
Надо исходить из наихудших условий на шине, ведь мы будем передавть не модулированную "цифру" со всеми шумами которые она соберёт по дороге.
И ещё если интерфейс уже зашит аппаратно, то смысл что-нибудь изобретать когда всё уже строго зашито в МК.

При таком раскладе получается 8 групп по 16 адресов (с учётом, что остальные 128 адресов будут заняты датчиками).

А сколько вообще предполагается датчиков и какого рода.
Если не секрет.

А кто заставляет использовать релюхи без фиксации?

Чёт не слышал про такие релюхи можно поподробнее.
Вообще как я себе представляю выключатель:
Пластиковая накладка на коробку с одно/двумя/тремя (Зависит сколько каналов у люстры) кнопками с подсветкой светодиодами.
Кнопки без фиксации идут на МК. А МК управляет релюхами и передаёт в общую шину, что чтото включили.
Ну и возможные дополнения типа ИК.

Хотелось бы ограничить её на уровне хотя бы 500 мА на всю шину. Если использовать простые реле, то это всего 20 одновременно включенных каналов (причём не считая потребления самих контроллеров, всяких там LEDов для красоты и пр.).

Боюсь не хватит реле нужно брать из рассчёта напряжения и нагрузки.
Если взять хлипкое, то оно будет быстро обгарать и придётся раз в год его менять.
Я больше склоняюсь к применению симисторов - до 40W без радиатора и никаких контактов.

Группы же будут такие: например, "весь свет в гостиной", "подсветка подоконников во всём доме", "монитор + видак в прихожей", ну и т.п. В идеале хотелось бы их сделать гибко переназначаемыми прямо через шину (чтобы не тыкать каждый раз во все устройства программатором ).
К тому же надо не забыть про очень нужную группу "Всё выключено" (когда уходишь из дома, тыкаешь единственную кнопочку и все забытые утюги отключаются ).

Да и при этом отключаются все забытые холодильники и часы.
Вы каждую розеку хотите отключать, тогда вам 500ма не хватит.
Посчитайте сколько у вас будет устройств. Например у меня наберётся десятка три включая датчики.

Прямо через шину можно переназначить адрес только в том случае если у него есть индивидуальный адрес (Наподобие МАС адреса модема или сетевухи). Назначать через шину скорее всего придётся только адреса групп.

[Секретный кот]

Не знаю, но вы всё больше к этому ведёте.
Я всёже склоняюсь к возможности контролерам датчиков самим инициировать шину. Решить вот только проблему с арбитражом устройств.

Ну в принципе можно будет потом и поменять протокол обмена, не меняя сам интерфейс шины.

Т.е. вы хотите разграничить обязанности чтобы, например, через каждое полное кольцо контроллер выдавал отчёт главному МК.

Ну примерно так, скажем засылаем собранную инфу с датчиков "мозгу", а он думает и скидывает обратно "ценные указания". Плюс мозг имеет дружественный интерфейс (клавиатуру для ввода и редактирования команд, красивый ЖКИ ну и т.п.). В идеале конечно совместить бы всё в одном устройстве, но вот хватит ли производительности (даже на 20 МГц) – непонятно.

Да, но это избавляет и без того перегруженную шину от лишнего устройства. Или вам нехватает портов МК.

Ну на центральных устройствах портов может и хватит, а вот на периферийных будет в основном всё занято, практически полностью.

И ещё если интерфейс уже зашит аппаратно, то смысл что-нибудь изобретать когда всё уже строго зашито в МК.

Дело в том, что аппаратно присутствует целая куча интерфейсов (о которых я писал выше), а опцию адресного бита можно использовать, а можно не использовать. Мне лично кажется, что это целесообразно.

А сколько вообще предполагается датчиков и какого рода.
Если не секрет.

Какого рода: ИК приёмники, PIR датчики, датчик внешней освещённости, датчики температур, датчик влажности, датчик задымления, акустический датчик, кнопка звонка, контактные датчики (охрана).
Общее количество: требуется уточнить (план ещё не полностью утверждён ), но в любом случае в пределах 128.

А кто заставляет использовать релюхи без фиксации?

Чёт не слышал про такие релюхи можно поподробнее.

Не может быть, наверняка слышали. Для переключения такого реле достаточно подать только разовый импульс тока.
http://www.atof.ru/pea/relay/rl_097.shtml
http://www.atof.ru/pea/relay/rl_098.shtml
А вот примеры реальных реле:
http://www.eltis.ua/russian/news/list/showpage_221.html
http://www.abbelectro.ru/index.php?main ... _id=219919 (хотя второе, возможно, бесконтактное – тогда не годится).

Вообще как я себе представляю выключатель:
Пластиковая накладка на коробку с одно/двумя/тремя (Зависит сколько каналов у люстры) кнопками с подсветкой светодиодами.
Кнопки без фиксации идут на МК. А МК управляет релюхами и передаёт в общую шину, что чтото включили.
Ну и возможные дополнения типа ИК.

Ну так и есть. Это слаботочная часть. Кстати кнопки могут висеть на одном модуле (например на ATTiny каком-нить), а реле подключаться к другому (например, расположенному в щитке). Между ними – шина.

Боюсь не хватит реле нужно брать из рассчёта напряжения и нагрузки.
Если взять хлипкое, то оно будет быстро обгарать и придётся раз в год его менять.

Дык нет, хлипкость реле никак не связана с его потреблением от системы. Вот приведённое выше, например. Потребляет около 30 мА от 12 В, и коммутирует до 8 А/250 В.

Я больше склоняюсь к применению симисторов - до 40W без радиатора и никаких контактов.

Главное их преимущество – конечно, тишина Но вообще 40 W это очень мало, у меня немного найдётся нагрузок такой мощности. А с радиатором эта конструкция получится уже размером с реле, если не больше.

К тому же надо не забыть про очень нужную группу "Всё выключено"

Да и при этом отключаются все забытые холодильники и часы.

Ну с тем же успехом можно тогда просто вводной рубильник дёргать Зачем включать часы, холодильники и автоответчики через умный дом? Осталось тогда только БП самой системы включить через неё же

Вы каждую розеку хотите отключать, тогда вам 500ма не хватит.
Посчитайте сколько у вас будет устройств. Например у меня наберётся десятка три включая датчики.

Предел адресов – 128, а на данный момент реально набралось около 80 управляемых единиц. Только причём тут 500 мА? Я и говорил, что дёргать релюшки надо не одновременно. Например, если мы хотим перекинуть сразу все 80 адресов, то это нужно делать по 8-10 за раз, тогда в 500 мА уложимся с запасом. Задержка между включаемыми кусками должна быть равна времени коммутирующего импульса, то есть всего десятки миллисекунд. На глаз почти незаметно.

Прямо через шину можно переназначить адрес только в том случае если у него есть индивидуальный адрес (Наподобие МАС адреса модема или сетевухи). Назначать через шину скорее всего придётся только адреса групп.

Во! У меня в проекте физические адреса каналов так и называются MAC'ами, вы прямо мысли читаете Я собственно и предлагал переназначать только группы по шине. Таким образом у каждого канала будет 2 адреса: уникальный физический (в PROM) и "виртуальный" – адрес группы (в EEPROM). Далее просто предусматриваем шинную команду типа "адресу XX назначить группу YY".

[SLvik]

но вот хватит ли производительности (даже на 20 МГц) – непонятно.

Хватит с ушами. Мне 10Мгц на PIC хватало, а там команды выполняются каждые 4 такта. т.е. 10/4=2,5 милл. инструкций в сек.
У Atmel, насколько я знаю, инструкция выполняется каждый такт. т.е. скорость в 4 раза выше чем у PIC.

Ну на центральных устройствах портов может и хватит, а вот на периферийных будет в основном всё занято, практически полностью.

Так часы и должны висеть либо на центральном либо на "Шинном"контроллере. Ведь кроме мастера время никому не нужно и вешать его как ещё одно устройство не стоит.

Для переключения такого реле достаточно подать только разовый импульс тока.:

Про принцип работы я сообразил когда читал предъидущий пост, просто я правда с ними не сталкивался. Но весчь прикольная, главное есть небольшие размеры.
Возьму на заметку.

Но вообще 40 W это очень мало, у меня немного найдётся нагрузок такой мощности. А с радиатором эта конструкция получится уже размером с реле, если не больше.

Да, радиатор будет не маленький зависит от мощности.

В обшем попробуйте собрать два датчика и устроить им "Весёлую жизнь" по шине разместите одно на самом дальнем конце шины другое в середине и посмотрите сколько будет ошибок (Неправильно принятых данных) на разных скоростях подберите наиболее устойчивую частоту шины, а потом можно будет судить об общёй скорости системы в целом.

[Секретный кот]

У Atmel, насколько я знаю, инструкция выполняется каждый такт. т.е. скорость в 4 раза выше чем у PIC.

Это да – большинство инструкций за такт. Видеовывод в реальном времени даже на 8 МГц тянет Но всё равно как-то страшновато. В общем, будем пробовать.

Но весчь прикольная, главное есть небольшие размеры.
Возьму на заметку.

Не очень дёшево выходит, конечно, правда сопоставимо с совецкими РЭС22 (на которых я когда-то хотел всё делать, до сих пор полно валяется). Я уже закупил 100 реле.

В обшем попробуйте собрать два датчика и устроить им "Весёлую жизнь" по шине разместите одно на самом дальнем конце шины другое в середине и посмотрите сколько будет ошибок (Неправильно принятых данных) на разных скоростях подберите наиболее устойчивую частоту шины, а потом можно будет судить об общёй скорости системы в целом.

Это очень хорошая идея, я так и сделаю, жалко что пока работа не даёт совсем свободного времени, смогу заняться недели через 2 минимум. Вообще мы как-то нехорошо зафлудили чужую тему, к тому же про домофон, наверно лучше будет создать что-то отдельное и там общаться. По результатам экспериментов наверно будет полезная информация. А вы тоже собираетесь делать умный дом или это пока наброски на неопределённое будущее?

[S.T.A.L.K.E.R.]

... Вообще мы как-то нехорошо зафлудили чужую тему, к тому же про домофон, ......

та есть маленько...
так мне никто и не ответил насчет моих импульсов

[SLvik]

а кто знает как сделатьчтоб:
имеем релюху с переключающими контактами, которая будет включена когда кто то стоит перед дверью,и выключаться через определенное время,

Ну чтобы определить что ктото стоит перед дверью нужно как минимум датчик либо движеия либо емкостной либо лазерный (На просвет жертвы).

и два канала управления видиком, чтоб началась запись надо подать импульс на 1 канал,через 2-2,5 сек. на 2, чтоб остановить запись нада подать импульс на 1 канал, как это сделать???

Или на логике (Генератор>счётчик>дешифратор).
Или на микроконтроллере.

[SLvik]

to Секретный кот
Я тут подумывал насчёт арбитража в моей шине тут возможен единственный вариант.
В этом варианте каждое устройство которое передаёт данные по шине одновременно побитно следит за шиной.
Т.е.
Допустим два или более устройства начнут передавать данные одновременно.
Первое поставило 0 и второе 0 оба проверили, да, передан 0.
Второй бит одно поставило 0 другое 1. То которое поставило 1 проверяет шину, а на ней 0 - значит какое-то устройство тоже передаёт данные. Это устройство отключается давая возможность устройствам поставившим 0 продолжать "соревнование" до последнего вылетевшего из передачи устройства.
Устройства выбывшие ждут до освобождения шины и начинают передавать снова и так до последнего.
Т.е. передача ведётся всеми сработавшими устройствами до первого 0ля на шине затем устройства постепенно самоустраняются ожидая освобождения шины потом они опять начинают передавать до тех пор пока каждое устройство не отправит свои данные.

Я думаю, что не будет такой ситуации когда одновременно включаются больше трёх устройств - постараться надо.
А с учётом разгруженной шины эти три устройства влёт передадут по очереди свои данные и не надо будет ждать целый круг и опрашивать каждый датчик. Ибо каждый датчик сам передаст в шину, что чтото поменялось.

[Секретный кот]

SLvik
Это конечно тоже вариант, одно непонятно: пока устройства будут как вы говорите "соревноваться", что за инфу будет считывать мастер? И как ему понять, что "соревнование" закончилось и начался нормальный обмен.

В случае 1-wire шины всё даже попроще, потому что мы можем одновременно передавать и читать. Если считанный байт не совпадает с переданным, значит кто-то ещё в данный момент передаёт. Вот только проблема с "вконец запутанным" мастером остаётся. Он же тоже всю эту белиберду считывать будет.

Хотя... тут есть о чём подумать. Если например принять фиксированный формат посылки от датчика типа "адрес + CRC адреса + N байт данных + CRC данных", то возможно арбитраж получится. Причём всё будет не так уж медленно работать, по сравнению с циклическим опросом.
Схема будет такая: засылаем мастеру адрес и сразу сличаем с реально передаваемым на шине. Если мы вещаем одни, то эти байты совпадут, и тогда мы засылаем следом CRC адреса. Теперь мастер точно знает, что мы к нему обращаемся с правильного адреса. Ну или вместо CRC можно даже использовать простой повтор первого байта.

Если на момент передачи шина была занята, то мы считываем ошибочную инфу вместо нашего адреса. Следовательно вместо CRC мы засылаем мастеру, например, все нули и отключаемся до освобождения шины. Мастер таким образом гарантированно видит, что предыдущий байт ошибочный.
Что касается очередности повторных попыток, то для прикола можно сделать вычисление адреса конфликтующего устройства (сравнением реальных данных на шине и того байта, который мы пытались послать), и чтобы "младшее" уступало "старшему" (ну или наоборот) . Вот и весь арбитраж.

Однако в такой системе как-то страшновато, если одному из девайсов снесёт крышу и он полностью захватит обмен по шине. Например, пока мы будем держать нажатой кнопку звонка, больше ни один датчик до мастера не достучится. Разумеется, всё это можно как-то решить программно (в каждом девайсе отдельно), но в целом протокол высокого уровня усложняется.

[Кашпо]

Или на логике (Генератор>счётчик>дешифратор).
Или на микроконтроллере.

думаю следующим вопросом будет "а как на логике (микроконтроллере)"
так мы постепенно дойдём до вопросов
"а вот кто может нарисовать схему ?"
и
"а вот кто может её спаять?"

[SLvik]

SLvik
Это конечно тоже вариант, одно непонятно: пока устройства будут как вы говорите "соревноваться", что за инфу будет считывать мастер? И как ему понять, что "соревнование" закончилось и начался нормальный обмен.

Вы не поняли принцип.
Каждое устройство передающее бит следит за реальной шиной
Допустим два устройства одновременно начали передавать свой адрес:
1)10110101 b5
2)10110011 b3
Два устройства одновременно передают адрес проверяя шину и.
Устройство №1 дойдя до 6го бита обнаруживает на шине вместо 1цы 0ль и отключается позволяя устройству №2 закончить передачу.
А устройство №1 попытается опять передать в следующей пачке.
В результате Master получит данные с устройства №2. А устройство №1 передаст свои данные в следующей пачке.

В случае 1-wire шины всё даже попроще, потому что мы можем одновременно передавать и читать. Если считанный байт не совпадает с переданным, значит кто-то ещё в данный момент передаёт. Вот только проблема с "вконец запутанным" мастером остаётся. Он же тоже всю эту белиберду считывать будет.

Ну если придерживаться формата: Адрес>Команда>Данные>Общее CRC. То любая шина попрёт.

Хотя... тут есть о чём подумать. Если например принять фиксированный формат посылки от датчика типа "адрес + CRC адреса + N байт данных + CRC данных", то возможно арбитраж получится. Причём всё будет не так уж медленно работать, по сравнению с циклическим опросом.
Схема будет такая: засылаем мастеру адрес и сразу сличаем с реально передаваемым на шине. Если мы вещаем одни, то эти байты совпадут, и тогда мы засылаем следом CRC адреса. Теперь мастер точно знает, что мы к нему обращаемся с правильного адреса. Ну или вместо CRC можно даже использовать простой повтор первого байта.

Если на момент передачи шина была занята, то мы считываем ошибочную инфу вместо нашего адреса. Следовательно вместо CRC мы засылаем мастеру, например, все нули и отключаемся до освобождения шины. Мастер таким образом гарантированно видит, что предыдущий байт ошибочный.
Что касается очередности повторных попыток, то для прикола можно сделать вычисление адреса конфликтующего устройства (сравнением реальных данных на шине и того байта, который мы пытались послать), и чтобы "младшее" уступало "старшему" (ну или наоборот) . Вот и весь арбитраж.

Опять таки если оба сразу начнут передавать, то на шине получится логическое "И" всех устройств начавших передавать в шину.

Однако в такой системе как-то страшновато, если одному из девайсов снесёт крышу и он полностью захватит обмен по шине. Например, пока мы будем держать нажатой кнопку звонка, больше ни один датчик до мастера не достучится. Разумеется, всё это можно как-то решить программно (в каждом девайсе отдельно), но в целом протокол высокого уровня усложняется.

Ну тут как раз всё просто:
Нажали кнопку звонка - датчик передал в шину, что кнопку нажали.
Отпустили кнопку звонка - датчик передал, что кнопку отпустили.
Хотя можно обойтись без второго,- просто нажатиями.

К стати забыл сказать что для обеих шин необходима пауза между пачками импульсов минимум в три шинных такта иначе как определить когда передача началась, а когда закончилась.
Да и Master должен в этих промежутках обрабатывать принятые данные.

[Секретный кот]

Вы не поняли принцип.
Каждое устройство передающее бит следит за реальной шиной

А, ну то есть побитово сравнивать в реальном времени? Чтобы сразу "выиграл сильнейший"? Ну да. Только в этом случае аппаратным serial-портом уже не воспользоваться, т.к. он шлёт целыми байтами сразу.

если придерживаться формата: Адрес>Команда>Данные>Общее CRC. То любая шина попрёт.

Это конечно можно, только больше времени на арбитраж придётся тратить. А так сначала проверяем валидность короткого адреса по его собственному CRC, а затем уже получаем с этого адреса пакет данных (для которого своё CRC, строго говоря, уже необязательно – по крайней мере, к арбитражу оно уже не имеет отношения).

Опять таки если оба сразу начнут передавать, то на шине получится логическое "И" всех устройств начавших передавать в шину.

Правильно! Но если вторым байтом мы передаём обязательное CRC, то в описанном мной случае он всегда будет равен нулю. Так как любое устройство, обнаружив несовпадение переданного и принятого байтов с шины, выставит вторым байтом ноль. Это будет знаком мастеру, что посланный перед этим адрес был "шуткой"

Однако в такой системе как-то страшновато, если одному из девайсов снесёт крышу и он полностью захватит обмен по шине.

Ну тут как раз всё просто:
Нажали кнопку звонка - датчик передал в шину, что кнопку нажали.
Отпустили кнопку звонка - датчик передал, что кнопку отпустили.

Ну в данном случае это понятно. Я просто пример наверно не очень удачный выбрал. Просто могут быть накладки, например та же кнопка звонка окажется с дребезгом. И вместо одного нажатия вдруг окажется сотня. Пока они все не передадутся по шине, часть остальных устройств (с меньшим адресом, например) будет вынуждена ждать. Вдобавок на шине наступит "пробка" из-за арбитража коллизий на каждом пакете, т.е. всё будет работать ещё медленнее.
Ну и примеров таких нештатных ситуаций можно придумать массу, например глюки датчиков температуры, колебания освещённости около заданного порога, да и просто недочёты в программах (ловить их по всей системе будет трудновато).

К стати забыл сказать что для обеих шин необходима пауза между пачками импульсов минимум в три шинных такта иначе как определить когда передача началась, а когда закончилась.

Я бы сказал, что три такта это голодный минимум. Хотя при использовании аппаратного порта можно с задержками вообще не париться, т.к. всё будет работать по прерываниям. Вроде даже можно организовать софтовый буфер приёма, т.е. сразу принимать/передавать целиком пакет данных в виде одной символьной переменной.

SLvik, я смотрю эта тема больше особо никому не интересна, предлагаю продолжить в личке! А лучше даже мылом. Тем более что меня, например, также интересует тематика часов на ИНках, с удовольствием задал бы вам пару вопросов по питанию. Заодно буду ставить эксперименты с первыми блоками и шиной, смогу поделиться результатами из первых рук. Можно будет кстати сразу несколько протоколов попробовать на устойчивость.