Kiruxa писал(а): Пн мар 18, 2019 3:43 pm
почему не использовать CAN с CAN трансивером на низкой скорости? Где то эта идея поднималась давно, ее разнесли в пух и прах, хотя там и доминантность передающего и контрольная сумма на аппаратном уровне, но длинна всего 8 Байт.
Вполне нормальное решение. Так сделана
бельгийская система Velbus: нормальный CAN, но на скорости 19.2 kbps. Я именно с этого и начинал несколько лет назад, использовал CAN контроллер
MCP2515, естественно, с CAN трансивером. Но за счет CAN контроллера все получалось в разы сложнее чем то, что я делаю сейчас, и железо, и софт. Я это забросил, когда CAN у меня заработал, но для дальнейшего развития надо было или осваивать CANopen/
CanFestival, или делать нечто подобное ему самостоятельно.
Вообще, "верхний уровень" софта является самым большим камнем преткновения, но в HBus он решается тривиально просто за счет JSON, MQTT и возможности настройки узлов путем написания Ардуино скетчей под задачу. В "фирменных" системах автоматизации, KNX, C-Bus, Velbus и т.п., об этом даже мечтать не приходится, все ПО закрытое и для применения настраивается специальными программами. Поэтому ПО сложное и дорогое, а узлы не очень-то универсальные. Из-за этого все очень дорого получается, шутка ли, содержать такую ораву разработчиков и программистов. И за счет сложности использования без профессионального инсталятора не всякий решится такую систему установить, а это еще цену увеличивает раза в полтора, наверное, или даже более того. Для тех, кто умеет паять и писать Ардуино скетчи, система HBus обойдется, я думаю, более чем на порядок дешевле, чем "фирменная", при сопоставимых свойствах и возможностях. На CAN такого достичь не удастся, все будет дороже и намного сложнее.
"Доминантность" определяется физическим уровнем, а не протоколом. Поскольку на физическом уровне я использую приемопередатчики (трансиверы) CAN, то, соответственно, в HBus и "доминантность" есть, и вообще все свойства физического уровня CAN, а там еще много чего хорошего. Вместо контрольной суммы и CAN, и HBus используют
CRC. Вычисление CRC в HBus сделано программно и не занимает много места или времени.
Я не вижу, в чем HBus уступал бы "настоящему CAN" для своей области применения - автоматизации дома. CAN быстрее, но для дома это не достоинство, а недостаток: при скоростях 1 Mbps нельзя делать длинный кабель, нельзя использовавать свободную топологию прокладки кабеля, нельзя делать большие ответвления, надо обязательно ставить терминаторы с обих сторон. Тогда как опыт Velbus показывает, что при 19.2 kbps физический уровень CAN позволяет использовать частичное терминирование и свободную топологию с суммарной длиной кабеля до 1 км. Еще CAN в принципе позволяет обеспечить более устойчивую работу в условиях сильных помех. Однако контроллер CAN сложен, в нем огромное количество всяких регистров, что чрезмерно раздувает сложность ПО.
И наоборот, в родной для CAN области применения, в автомобилях, применять HBus было бы довольно глупо. Вот там вся эта система обработки ошибок, быстрой пересылки коротких сообщений, автоматической выборки нужных сообщений из потока, и т.п. - играют во всей красе, несмотря на сложность ПО. Для автомобилей это оправдано, в критической ситуации такая система управления мотором и т.п. не подведет, а от этого может зависеть жизнь. Ну а в доме все это зачем? C-Bus и KNX, гораздо более простые и медленные чем CAN, прекрасно справляются со своими задачами.
Kiruxa писал(а): Пн мар 18, 2019 3:43 pm
Как в Вашей сети реализовано разрешение коллизий? Одновременная передача по уарт и прием, т.е. полчение результата об успешной передаче только после отправки хотя бы одного байта? Как дальше действуют узлы?
Два варианта. Дешевые узлы используют обнаружение коллизий, CSMA/CD. При передаче узел все время слушает шину, если эхо не совпало с переданным байтом - выключает передатчик. Более дорогое решение - избегание коллизий, CSMA/CA. Для этого использован внешний арбитр на микроконтроллере PIC16. Арбитр на битовом уровне слушает передаваемый и принимаемый сигналы и блокирует передачу при несовпадении.
После обнаружения коллизии передающий узел выдерживает случайную паузу 2...12 мс, и, если на шине в течении 2 мс нет сигналов, повторяет попытку передачи. Сейчас узел делает до 3-х попыток, даже не пытаясь увеличивать свой приоритет передачи, после чего "сдается".