Eddy_Em (26.03.2024 21:46, просмотров: 183) ответил Aleksey_75 на 20К за работу ? вы серьезно ? а так, их есть у нас)))eddy-em.livejournal.com github.com/eddyem
-
- ну удвойте сумму и сроки для приличия штоль, чтоб
"не сбивать цену на рынке":)) "не попасть в просак". По опыту работы - если изначально "с ходу" видится 3 дня - то минимум неделю кладите (с учётом отладки" и прочих непредвиденных моментов. тока схему-плату сваять пара дней нужна плотной работы, а Adept(3295 знак., 27.03.2024 14:03 - 14:15, ссылка, ссылка)- Интересно. Все время слышал про "железный треугольник", а тут вдруг Эпштейн, Гейзенберг... Впрочем, и сам треугольник немного видоизменился... RxTx(1 знак., 27.03.2024 21:36, картинка)
- Проприетарщина не пугает, а вызывает рвотный рефлекс - ни в коем
случае!!! Eddy_Em(231 знак., 27.03.2024 14:06)
- проприетарные решения часто максимально эффективны для решения конкретных задач. Стандартные - более понятны другим (что не всегда плюс), зачастую надёжнее, т.к. разрабатывались большими коллективами инженеров, но есть и минусы, - громоздкость, отсутствие патентной чистоты, завышенные требования к аппаратуре, и прочее вроде "натягивание совы на глобус" в попытках "применить стандартное" там, где оно не очень-то и лезет. - 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, ссылка, ссылка)
- А чего там рисовать-то? Один модуль нарисовал - размножил на 8…
Максимум два часа с нуля уйдет, чтобы плату с 8 входами и 8
выходами нарисовать. Дальше - трассировка. Если пытаться ужаться в
очень маленький корпус, возможно, придется даже четырехслойку
лепить, но если есть возможность не впихивать все в размер пары
спичечных коробков, а чуть больше - хватит двухслойки. Такая
простая разводится за 8 часов максимум. Eddy_Em(777 знак., 27.03.2024 14:04)
- "блажен кто верует" :))) из практики время проектирования коррелирует со степенью
"двойки": от идеи до "наколенного образца" - одна дистанция, от
"наколенного образца" до инженерной версии - 2X, от инженерной
версии до предсерийного образца 4X (ну и ещё столько же -
устранение косяков постановки на производство и создание средств
ОТК, и полной техдокументации, включая ведомости закупок, сервисные
и пользовательские мануалы). ровно то же самое и с ПО. Основная Adept(152 знак., 27.03.2024 15:13 - 15:18)
- У нас работа просто распределяется: я разрабатываю электронику и прошивки для нее, инженер паяет (возможно, в будущем ему и отладку можно будет поручить - толковый парень, хоть и вендузятник), ведущий инженер рисует глобальные схемы и вносит предложения (заодно следит, чтобы мы дурь какую не вытворили). А вот кто будет на ПК писать софт - пока еще не очень решено, я очень надеюсь, что не я (меня на все не хватит). - Eddy_Em(27.03.2024 16:22)
- Все не учтешь :) - Гyдвин(27.03.2024 15:17)
- в достаточной степени приближения к желаемому, получается (со
сроками 2x..4x от изначально планируемых, в зависимости от желаемой
степени приближения к идеалу :) Впрочем, есть одно хорошее
средство: волшебное слово "насрать" - решает очень многие вопросы, основная проблема только
договориться с самим собой :)) - Adept(27.03.2024 15:21)
- Без этого волшебного слова - никуда. Eddy_Em(398 знак., 27.03.2024 16:26)
- в достаточной степени приближения к желаемому, получается (со
сроками 2x..4x от изначально планируемых, в зависимости от желаемой
степени приближения к идеалу :) Впрочем, есть одно хорошее
средство: волшебное слово "насрать" - решает очень многие вопросы, основная проблема только
договориться с самим собой :)) - Adept(27.03.2024 15:21)
- "блажен кто верует" :))) из практики время проектирования коррелирует со степенью
"двойки": от идеи до "наколенного образца" - одна дистанция, от
"наколенного образца" до инженерной версии - 2X, от инженерной
версии до предсерийного образца 4X (ну и ещё столько же -
устранение косяков постановки на производство и создание средств
ОТК, и полной техдокументации, включая ведомости закупок, сервисные
и пользовательские мануалы). ровно то же самое и с ПО. Основная Adept(152 знак., 27.03.2024 15:13 - 15:18)
- Да мне кажется по нынешним временам лучше на оптоволокно сажать - scorpion(26.03.2024 21:52)
- На оптоволокне только p2p, шину не сделать. Но вот модули между собой при большом расстоянии (или если на улицу надо) - только в путь. Если китайцы начнут делать компактные приемопередатчики, можно будет прямо в свои железки встраивать, а не использовать дорогущие переходники 485-оптика. - Eddy_Em(26.03.2024 22:00)
- ну удвойте сумму и сроки для приличия штоль, чтоб
