SLvik писал(а):Есть маленькие датчики движения можно в стену вмуровать.
Ну, совсем скрытые датчики движения мне неизвестны

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

Кстати поставить камеру тоже не так просто. Если будут винты, то их сможет отвернуть любой желающий. А если сделать например заклёпки, то сам потом намучаешься открывать. Причём открывать может понадобиться раньше, чем сломается камера – нужно ведь учитывать любителей засовывать спички в любые pinhole отверстия
SLvik писал(а):Вот и я о том-же. У нас когда срабатывает датчик освещённости закорачивается подъездный выключатель и выключить свет просто нереально, разве что лампочки побить.
А, вот вы о чём. Ну так у нас в подъезде просто нет выключателей, свет включается во всём доме централизованно. Точнее, включался (в одном из подъездов стояло фотореле), а последние лет пять горит круглосуточно.
SLvik писал(а):Для ИК диодов тоже желательно датчики освещённости повесить, чтобы днём не горели.
Так они и так по любому горят только во время работы камеры, то есть кратковременно.
SLvik писал(а):Секретный кот писал(а):если обмен по шине будет слишком интенсивный, напруга может упасть чуть ли не вдвое
Не понял.

Какая напруга может упасть, ведь питание на устройства идёт отдельно?
Я говорил про вариант с одним кабелем, как вы предлагали. Когда по одному проводу идёт видеосигнал, а по второму шина + питание (совмещенная). Или я не так понял?
SLvik писал(а):Звук конечно будет, только скорее всего с наводками от стен, вашей шины и т.п.
Да, кстати точно шина будет фонить, правда есть ещё шанс выбрать ультразвуковую скорость обмена (если заработает конечно)
SLvik писал(а):Если вы питание кидаете по витой паре, то лучше запараллелить две или три. Одна, боюсь, все камеры не потянет.
В том-то и прелесть, что они и не будут работать все одновременно

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

Это конечно правильно, но про эти датчики я уже написал свои соображения, а для запуска камеры на двери можно так же использовать к примеру акустический датчик (шум на площадке или на поверхности двери – очень хорошо срабатывает), ну или датчик прикосновения к двери (ручка металлическая).
SLvik писал(а):Ваш алгоритм сильно нагружает шину ибо опрашивает все устройства постоянно.
Согласен. К тому же он нагружает и все устройства, у которых могут быть и другие, автономные функции. Например, метеостанция. Хотя особых проблем с производительностью это не создаст, другое дело – фонящая шина
SLvik писал(а):А если делать с битом подтверждения приёма данных с опрашиваемого (Зависшего или нерабочего) устройства,- вообще зависнет.
Почему? Я вообще планировал реализовать подтверждение через ответ ведомого устройства. Грубо говоря, мастер "выкрикивает" его адрес, а в ответ получает набор битов, соответствующих состоянию каналов или коду события. Если в ответ ничего нет, мастер зажигает индикатор Error XX и исключает устройство из дальнейшего обмена "до устранения".
SLvik писал(а):Шину делайте двухпроводную.- Одну витую пару на CLK другую на DAT во много раз выиграете в скорости по сравнению с 1wire.
Мне бы использовать какой-нибудь стандартный (желательно аппаратный) порт, имеющийся на борту МК. Такая шина – это видимо SPI? Не очень понятно, как её физически кинуть на приличное (метров 50) расстояние.
SLvik писал(а):Я вот как хотел в своё время сделать:
Почитал ваш алгоритм. Я задумывался о чём-то подобном, правда хотел реализовать это через то же 1-wire. Однако упёрся в проблему разрешения коллизий, у вас она кстати тоже не решена.
SLvik писал(а):Устройство которое хочет активироваться (Скажем датчик) поднимает шину через резистор на 5v (Или другое напряжение лог. 1).
Представим, что одновременно сработало 2 устройства. С учётом высокой скорости шины такое конечно маловероятно, но возможно.
SLvik писал(а):В центральном контроллере срабатывает прерывание и он даёт импульс старта на шину после чего сработавшее устройство передаёт свой адрес и байт состояния и освобождает шину
Оба устройства передадут свою инфу, в итоге контроллер считает белиберду. Но этот случай даже не самый неприятный. Самый неприятный далее:
SLvik писал(а):Но если в это время произойдёт срабатывание другого (Ведомого) датчика, тот ждёт освобождения шины, после чего сам её занимает и передаёт свои данные.
Прикол заключается в том, что пока мы "разговариваем" с одним датчиком, захотеть "тоже поговорить" может не одно, а сразу несколько устройств. Да, они без проблем могут дождаться окончания обмена по шине. Но вот как научить их потом "высказываться по очереди"? Опять будет коллизия.
Я когда думал на эту тему, рассматривал вариант введения задержки перед началом "беседы", пропорциональной номеру устройства. Грубо говоря, устройство 1 начало бы вызывать мастера не ранее чем через 1 мкс, устройство 2 - через 2 мкс ну и т.п. Соответственно если у устройств 1 и 9 одновременно есть сообщения, то первым начнет вещать устройство 1, а устройство 9 будет молчать, не дождавшись положенной ему тишины в 9 мкс. Когда устройство 1 закончит, устройство 9 опять подождёт 9 мкс, и если никто больше не хочет "высказаться", приступит к обмену.
Однако этот вариант явно проигрышный, поэтому я даже не пытался его реализовать. А проигрышный он потому, что:
• искусственно замедляет и без того медленный обмен по шине и
• у устройств получаются искусственно назначенные приоритеты, которые создают уязвимость: в верхнем примере если устройство 1 захочет постоянно что-то передавать, то устройство 9 никогда не дождётся своей очереди.
SLvik писал(а):При такой системе все контроллеры устройств будут выполнены по одной схеме и будут только разные адреса.
Ну, это будет и в случае с 1-wire, и с RS-485.
SLvik писал(а):Шина абсолютно не занята постоянными опросами, что благоприятно скажется на звуке.
Разрешить бы коллизии, тогда конечно это наилучший вариант. Большую часть времени шина будет просто "спать", полезный обмен предполагается редкий и маленькими порциями.
SLvik писал(а):Не плохо было бы добавить такие нюансы как 9й бит подтверждения приёма от мастера/ведомого.
Вот это я не понял, куда его нужно добавлять. По идее, если успешный обмен состоялся, то никаких доп. подтверждений уже не надо? Ведомый вызвал мастера, мастер ответил считыванием инфы – вот и подтверждение. Если считывания нет, вызываем снова.
А 9-й бит я хотел задействовать для реализации Multi-Processor Communication Mode, конструктивно предусмотренного в AVR. Это опознавательный бит байта адреса.
Кстати, а может вместо CLK и DATA лучше сделать линии RXD/TXD? Хотя проблему с трафиком на шине это не снимает, ну может хоть скорость будет повыше...