caxapa.ru :: Я точно знаю, что в моих задачах никогда не будет нужды даже в половине этих причуд, заложенных в CANopen. У меня простой протокол, 8 байт делятся напополам: в первой половине 2 байта - код команды, 1 байт - код параметра (почти как в canopen с option/suboption), 1 байт - код ошибки; вторая половина трактуется уже по протоколу (и как один int32_t или uint32_t, и как два-четыре более мелких). В общем, вполне могу на своем протоколе сделать подобие CANopen, но не забивая

Eddy_Em (27.03.2024 16:15, просмотров: 146) ответил 3m на Вы точно изучили все спецификации DS*** комитета CANopen прежде чем заявлять о его "убогости" ?

Я точно знаю, что в моих задачах никогда не будет нужды даже в половине этих причуд, заложенных в CANopen. У меня простой протокол, 8 байт делятся напополам: в первой половине 2 байта - код команды, 1 байт - код параметра (почти как в canopen с option/suboption), 1 байт - код ошибки; вторая половина трактуется уже по протоколу (и как один int32_t или uint32_t, и как два-четыре более мелких). В общем, вполне могу на своем протоколе сделать подобие CANopen, но не забивая

огромное количество идентификаторов без толку.

eddy-em.livejournal.com github.com/eddyem

Ответить

- Вот вы и расписались в полной некомпетентности! Если бы изучили в полном объеме спецификации CANopen вам стало бы понятно что нахуевертили там для того чтобы устройства взаимодействовали друг с другом напрямую, без участия мастера. То есть концевик по шине шлет сообщение и на него подписан привод мотора который выключает лебедку по срабатыванию концевика. И тому подобное. Если в полном объеме реализован Canopen то мастер нужен только для первоначальной настройки ну и 3m(143 знак., 27.03.2024 18:10)
  - Если мне вдруг захочется, чтобы одна железка начала что-то делать, когда другая пошлет нужное сообщение в шину, то никакой угребищный CANopen мне для этого не понадобится! За глаза хватит моего протокола!!! Просто этот пакет пойдет "широковещательным" - с нулевым идентификатором (который читают абсолютно все). - Eddy_Em(27.03.2024 18:18)
    - Вы бы голову включали хотя бы изредка. Условных "концевиков" и "моторов" может быть много. Кто кому будет широковещать по нулевому идентификатору ? - 3m(27.03.2024 18:26)
      - Аналогично отвечу: вы бы читали, что я пишу. - Eddy_Em(27.03.2024 19:33)
- и шо, пакетный обмен (тем более на "длинные дистанции", а не внутри прибора) без контрольных сумм ?? прикрутите хотя б CRC8, а лучше CRC16 так же рекомендую сделать стартовое синхрослово или синхробайт. В условиях интенсивного обмена и интенсивных помех без этого вообще ничего не будет корректно работать, например. - Adept(27.03.2024 17:51)
  - О, еще один вылез позориться. RTFM!!! - 3m(27.03.2024 18:11)
  - CRC обеспечивает CAN на аппаратном уровне. Стыдно об этом не знать! Eddy_Em(129 знак., 27.03.2024 18:00)
    - ну я как бы отвлечённо рассуждаю, касательно транспортного уровня, а не логического, потому по CAN-конкретно и не думал даже. А по поводу ошибок - зря "не паритесь". Хуже, если будет ситуация исполнения не той команды вместо простого игнорирования неизвестной. - Adept(27.03.2024 18:08)
      - Если вдруг мне понадобится засунуть МК в шкаф, полный высоковольтных искрящихся НËХ, я, скорей, перейду на оптику (заодно и гальваноразвязка на мегавольты), нежели буду выдумывать нафиг не нужные CRC! - Eddy_Em(27.03.2024 18:20)
        
        контрольные суммы есть везде, в любых протоколах транспортного уровня, в том или ином виде, и не важен ни носитель,ни среда распространения. Это как бы "культура использования цифровой среды". Без этого ничего нормально не работает, или работает "до поры до времени" а потом почему-то "спутники падаютЬ" :)) - Adept(27.03.2024 18:39)
        
        Ну, ладно, объясняю: у меня есть исключительно 2 способа подключения железяки к компутеру: либо по USB, либо по CAN. В первом случае по понятным причинам CRC не нужна. Во втором случае она аппаратная. Я не вижу смысла серьезно использовать RS-232 или RS-485, когда даже на 30-рублевых МК есть CAN! - Eddy_Em(27.03.2024 19:35)
        
        ну он же ж (CRC) есть ! :) хоть и "мимо Вас" :)) И да, ежели везде будет ~~"сплошное телевидение"~~ CAN, конечно, пихать CRC в пакеты не надь. Просто читая ветку, это было неочевидно, что только CAN и никак иначе :) - Adept(27.03.2024 19:43)
        
        А, тогда сорян. Ну, а вообще, по тому же USB у меня чисто текстовый протокол - каждая строка заканчивается '\n', а потом парсится МК. Если б таки делал на 485 или 232, ничего бы и не менял: как вообще воткнуть CRC в "человекописуемый" протокол? Я что, должен сидеть и на каждую строчку высчитывать контрольную сумму? Делать нечего… Понятно, что после отладки всем занимается комп, но все равно смысла нет на линиях длиной метр-два вне всякой искряще-шумящей гадости. А линии Eddy_Em(425 знак., 27.03.2024 19:51)

Схемы, платы, компоненты