Какой протокол выбрать для связи датчиков и сервера на avr или stm?

Question

[bycter]

Хочу сделать небольшую автоматизацию на садовом участке. Мне нужно связать несколько устройств в сеть, расстояние 15-20 метров. Это будут датчики, исполнительные устройства и сервер. Основу устройств хочу сделать на микроконтроллере (avr или stm). Посоветуйте протокол обмена между всем этим хозяйством. Знаю, что можно и беспроводную сеть замутить, например, на nRF24, но это запасной вариант. Modbus вроде не плохой протокол, но хотелось бы чтобы сеть сохраняла минимальный функционал, если сервер перестанет работать. Например, датчик влажности зафиксирует критический уровень влажности и даст команду включить полив.

Answer 1

[Александр Волков]

Если датчик может напрямую влиять на исполнителя команды, то какова роль сервера? Собирать данные? Управлять исполнителем вручную?
Если исполнитель может слушать датчики и распознавать их показания для совершения некоторых действий, то сервер, получается, либо только слушает состояние сети и так же может отдавать команды исполнителям и датчикам, либо абсолютно не нужен.
В сетях, где есть необходимость прослушивать сеть и изредка влиять на работу элементов сети, предпочтительней протоколы, которые работают аналогично TWI. Каждое устройство постоянно слушает сеть и при поступлении в сеть пакета с адресом устройства и запросом дожидается свободного окна в сети и транслирует или широковещательный ответ или ответ, предназначенный конкретному устройству в сети.
Физически такая сеть может быть реализована на RS-485, например. Или на любом другом физическом протоколе обмена, удовлетворяющем требования по дальности связи и помехозащищенности.

Comments

[bycter]

Сервер безусловно нужен, так как он будет выполнять определенную программу. А возможность датчику обратится к исполнительному устройству напрямую поможет избежать критических ситуаций. Я знаю про RS-485, протокол Modbus как раз на этой шине и работает, но он работает по принципу master-slave и, если в сети будет несколько мастеров, будут возникать коллизии при одновременной передаче. Нужен протокол, который избавлен от этого.

[Александр Волков]

bycter: "определенная программа" - это не ответ. Впрочем, дело ваше.
Прочтите про TWI и арбитраж между мастерами в сети, чтобы было понятно, как избегаются коллизии и попытки одновременной передачи от двух устройств в одной сети.

[bycter]

Хорошо, я поясню. Сервер, конечно же, будет выполнять основную работу (сбор инфы с датчиков, обработка и принятие решения) и, даже если он перестанет работать, вряд ли на садовом участке случится коллапс, когда вы там постоянно живете. А если это дача? Поэтому обеспечив бесперебойное питание, я хочу чтобы сеть могла сохранить некую работоспособность в отсутствии сервера (допустим я ошибку в прошивке допустил и прошивка "зависла"). Насчет TWI: это же тот же I2C только название атмеловское, там же маскимальная длина линии никак не 15-20 метров. Может быть CAN? Но реализация на аппаратном уровне на avr вроде бы нет, да и такая скорость этой шины мне ни к чему.

[Александр Волков]

bycter: я TWI привёл как пример реализации арбитража между master-устройствами в одной сети.

[follow39]

bycter: >>(допустим я ошибку в прошивке допустил и прошивка "зависла")
Для этого есть сторожевая собака.

Answer 2

[yakov_cyb]

Используйте modbus для опроса, всю логику вынести в МК. про tcp/ip на МК - забудьте. не нужно оно там, ресурсов нет в МК для этого.