Eddy_Em (27.03.2024 14:06, просмотров: 152) ответил Adept на ну удвойте сумму и сроки для приличия штоль, чтоб eddy-em.livejournal.com github.com/eddyem
-
- проприетарные решения часто максимально эффективны для решения конкретных задач. Стандартные - более понятны другим (что не всегда плюс), зачастую надёжнее, т.к. разрабатывались большими коллективами инженеров, но есть и минусы, - громоздкость, отсутствие патентной чистоты, завышенные требования к аппаратуре, и прочее вроде "натягивание совы на глобус" в попытках "применить стандартное" там, где оно не очень-то и лезет. - Adept(27.03.2024 15:37)
- Вы точно изучили все спецификации DS*** комитета CANopen прежде чем
заявлять о его "убогости" ? - 3m(27.03.2024 14:49)
- Я точно знаю, что в моих задачах никогда не будет нужды даже в половине этих причуд,
заложенных в CANopen. У меня простой протокол, 8 байт делятся
напополам: в первой половине 2 байта - код команды, 1 байт - код
параметра (почти как в canopen с option/suboption), 1 байт - код
ошибки; вторая половина трактуется уже по протоколу (и как один
int32_t или uint32_t, и как два-четыре более мелких). В общем,
вполне могу на своем протоколе сделать подобие CANopen, но не
забивая Eddy_Em(46 знак., 27.03.2024 16:15)
- Вот вы и расписались в полной некомпетентности! Если бы изучили в
полном объеме спецификации 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)
- Вы бы голову включали хотя бы изредка. Условных "концевиков" и
"моторов" может быть много. Кто кому будет широковещать по нулевому
идентификатору ? - 3m(27.03.2024 18:26)
- Если мне вдруг захочется, чтобы одна железка начала что-то делать,
когда другая пошлет нужное сообщение в шину, то никакой угребищный
CANopen мне для этого не понадобится! За глаза хватит моего
протокола!!! Просто этот пакет пойдет "широковещательным" - с
нулевым идентификатором (который читают абсолютно все). - Eddy_Em(27.03.2024 18:18)
- и шо, пакетный обмен (тем более на "длинные дистанции", а не внутри
прибора) без контрольных сумм ?? прикрутите хотя б 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)
- ну он же ж (CRC) есть ! :) хоть и "мимо Вас" :)) И да, ежели везде
будет
- Ну, ладно, объясняю: у меня есть исключительно 2 способа
подключения железяки к компутеру: либо по USB, либо по CAN. В
первом случае по понятным причинам CRC не нужна. Во втором случае
она аппаратная. Я не вижу смысла серьезно использовать RS-232 или
RS-485, когда даже на 30-рублевых МК есть CAN! - Eddy_Em(27.03.2024 19:35)
- контрольные суммы есть везде, в любых протоколах транспортного
уровня, в том или ином виде, и не важен ни носитель,ни среда
распространения. Это как бы "культура использования цифровой
среды". Без этого ничего нормально не работает, или работает "до
поры до времени" а потом почему-то "спутники падаютЬ" :)) - Adept(27.03.2024 18:39)
- Если вдруг мне понадобится засунуть МК в шкаф, полный
высоковольтных искрящихся НËХ, я, скорей, перейду на оптику (заодно
и гальваноразвязка на мегавольты), нежели буду выдумывать нафиг не
нужные CRC! - Eddy_Em(27.03.2024 18:20)
- ну я как бы отвлечённо рассуждаю, касательно транспортного уровня,
а не логического, потому по CAN-конкретно и не думал даже. А по
поводу ошибок - зря "не паритесь". Хуже, если будет ситуация
исполнения не той команды вместо простого игнорирования
неизвестной. - Adept(27.03.2024 18:08)
- Вот вы и расписались в полной некомпетентности! Если бы изучили в
полном объеме спецификации CANopen вам стало бы понятно что
нахуевертили там для того чтобы устройства взаимодействовали друг с
другом напрямую, без участия мастера. То есть концевик по шине шлет
сообщение и на него подписан привод мотора который выключает
лебедку по срабатыванию концевика. И тому подобное. Если в полном
объеме реализован Canopen то мастер нужен только для первоначальной
настройки ну и 3m(143 знак., 27.03.2024 18:10)
- Я точно знаю, что в моих задачах никогда не будет нужды даже в половине этих причуд,
заложенных в CANopen. У меня простой протокол, 8 байт делятся
напополам: в первой половине 2 байта - код команды, 1 байт - код
параметра (почти как в canopen с option/suboption), 1 байт - код
ошибки; вторая половина трактуется уже по протоколу (и как один
int32_t или uint32_t, и как два-четыре более мелких). В общем,
вполне могу на своем протоколе сделать подобие CANopen, но не
забивая Eddy_Em(46 знак., 27.03.2024 16:15)
- ну CAN вроде как раз под подобные задачи создавался, так что да,
всё должно получиться хорошо (производлители автоэлоектроники не
дадут соврать :) Но "за три дня" - эт вы "махнули" конечно :)) Adept(168 знак., 27.03.2024 14:18)
- Хорошо, что я все в ЖЖшке документирую. Eddy_Em(995 знак., 27.03.2024 14:46, ссылка, ссылка)
- Ну, смотря что за железка, опять же! Eddy_Em(1083 знак., 27.03.2024 14:28, ссылка, ссылка)