Я изучаю, будет ли шина CAN работать для проектов, которые я создаю в данный момент.
Я хочу создать группу контроллеров ввода/вывода, которые будут принимать/буферизировать команды, выполнять их и затем сообщать о ходе выполнения. Мне кажется, что установка ведущего и ведомого не подойдет для проекта лучше всего, но я не уверен, что шина CAN работает по такому принципу.
Шина CAN является мультимастерной и автоматически свободна от арбитража. Все дело в том, что вам не нужен один главный или главный контроллер, чтобы заботиться обо всем. Каждое отправленное сообщение имеет приоритет, а сообщения с более высоким приоритетом превосходят сообщения с более низким приоритетом (сообщение с более низким приоритетом будет ждать до тех пор, пока не будет отправлено сообщение с более высоким приоритетом). Так что рабов нет. Это похоже на одноранговую сеть тем, что она децентрализована. Причина, по которой это делается, состоит в том, чтобы уменьшить точки отказа. Если выйдет из строя один главный контроллер, то выйдет из строя и вся сеть. Если нет центрального контроллера, один компонент может выйти из строя, а остальная часть системы продолжит работу.
Для вашей сети вы должны назначить приоритет каждой отправляемой команде в зависимости от того, что является наиболее важным. Статья в Википедии на самом деле неплохая.
CAN — это протокол низкого уровня, находящийся где-то на уровне канала передачи данных модели OSI (уровень 2). Таким образом, он касается только передачи общих кадров данных. CAN не определяет ни топологию сети, ни способ передачи данных, ни характер данных и т.д.
Таким образом, CAN не является протоколом ведущий/ведомый по той же причине, что и UART.
Помимо стандартных кадров протокола CAN, вам нужны более высокие уровни, которые определяют связь. Наиболее распространенными для CAN являются:
Они работают совершенно по-разному.
CANopen, например, не определяет мастер в отношении трафика данных. Обмен данными между узлами на шине касается только задействованных узлов: нет главного управляющего трафиком данных, и каждый узел может быть настроен так, чтобы говорить/слушать любой другой узел.
Но CANopen определяет мастера «сетевого менеджера», который отвечает за надзор за узлами на шине: следит за тем, чтобы они запускались правильно, оставались живыми и функциональными и т. д.
CAN имеет только мастеров. Один узел передает за раз — если несколько узлов осуществляют передачу примерно в одно и то же время, они столкнутся, и узел, передающий самый низкий идентификатор, выиграет арбитраж. Другие узлы будут слушать сообщение победившего узла, а затем, после некоторого времени задержки, повторно попытаются передать свои собственные сообщения.
И, конечно же, ничто не мешает вам создать какой-нибудь протокол ведущий/подчиненный поверх низкоуровневого перемещения сообщений, которое предоставляет вам CAN.
Олин Латроп