3m (27.03.2024 18:10, просмотров: 110) ответил Eddy_Em на Я точно знаю, что в моих задачах никогда не будет нужды даже в половине этих причуд,
заложенных в CANopen. У меня простой протокол, 8 байт делятся
напополам: в первой половине 2 байта - код команды, 1 байт - код
параметра (почти как в canopen с option/suboption), 1 байт - код
ошибки; вторая половина трактуется уже по протоколу (и как один
int32_t или uint32_t, и как два-четыре более мелких). В общем,
вполне могу на своем протоколе сделать подобие CANopen, но не
забивая-
- Если мне вдруг захочется, чтобы одна железка начала что-то делать,
когда другая пошлет нужное сообщение в шину, то никакой угребищный
CANopen мне для этого не понадобится! За глаза хватит моего
протокола!!! Просто этот пакет пойдет "широковещательным" - с
нулевым идентификатором (который читают абсолютно все). - Eddy_Em(27.03.2024 18:18)
- Вы бы голову включали хотя бы изредка. Условных "концевиков" и
"моторов" может быть много. Кто кому будет широковещать по нулевому
идентификатору ? - 3m(27.03.2024 18:26)
- Аналогично отвечу: вы бы читали, что я пишу. - Eddy_Em(27.03.2024 19:33)
- Вы бы голову включали хотя бы изредка. Условных "концевиков" и
"моторов" может быть много. Кто кому будет широковещать по нулевому
идентификатору ? - 3m(27.03.2024 18:26)
- Если мне вдруг захочется, чтобы одна железка начала что-то делать,
когда другая пошлет нужное сообщение в шину, то никакой угребищный
CANopen мне для этого не понадобится! За глаза хватит моего
протокола!!! Просто этот пакет пойдет "широковещательным" - с
нулевым идентификатором (который читают абсолютно все). - Eddy_Em(27.03.2024 18:18)