Comments 50
Мама кушать зовет — это хорошо. Жаль, что так рано) Только разогнался)
Познавательно, с юморком, спасибо.
хотя если есть дма, то и в уарт пакеты кидаются с одного пинка.
а из недостатков — на загруженной шине время ответа самого низкоприоритетного устройства будет большим. также и высокие накладные расходы на передачу
Аппаратный арбитраж же.
Каковой и позволяет перейти от двухуровневой иерархии «один ведущий, остальные — ведомые» (причём ведомые без команды ведущего вякнуть не смеют) к многоуровневой по приоритетам сообщений (и все могут по своей инициативе начинать передачу).
Ну а приоритет = срочность, да. Но вопрос задержки низкоприоритетных — это вопрос пропускной способности, это должно учитываться при проектировании сети. Если загруженность настолько высока, что задержки становятся критичными — стоит или повысить скорость передачи (если позволяет размер линии), или разбивать на отдельные домены с шлюзованием.
Если два устройства начнут что-то слать одновременно, тот, у которого адрес менее приоритетный, может понять, что он пытается говорить одновременно с кем-то другим и перестать это делать, не мешая при этом более высокоприоритетному участнику, и его сообщение при этом не испортится.
В этом же и недостаток, все должны быть на расстоянии распространения 1 бита туда/обратно. А 485 можно с правильным драйвером и десятки МБит на сотни метров запустить, но коллизии/арбитраж шины разруливать придётся самому на уровнях выше.
А накладные расходы будут и у 485, если на шине больше чем 2 участника и нужна адресация и хоть какой-то протокол поверх.
А мне лично CAN в промышленных ПЛК не особо понравился — начиная с оконечных терминаторов, которые выглядят «колхозом» заканчивая ограниченной длинной линии. Проще унифицироваться через industrial Ethernet в его модификациях.
etherCAT, топология кольцо, провод условно один, от соседа к соседу, но вот количество приёмо-передатчиков удваивается.
этого провода для машины надо 15м — о чём намекает максимальная длина нового 10base-t1s. Да и «без экрана» для машины тоже так себе идея.
А первый попавшийся в интернете магазин предложил купить rg-58 за 50 европейских копеек/м. витая пара в розницу настолько дешевле?
Коннекторы подороже немного, но всё равно копейки по сравнению с ценой самого сетевого оборудования.
Да и сделать выход диффернциальным, а не single-ended на коаксиал, оставив всё остальное как есть, тоже конечно задача стоящая десятилетий разработок новых стандартов.
Да, я понимаю что они вроде хотят скрестить этот новый езернет с кэном, чтобы как у него коллизии и арбитраж сделать на физическом уровне, а всё что выше оставить совместимым с обычным езернетом.
Но кто мешает это делать уровнями повыше, например есть тот же 1588 для синхронизации, чтобы избегать коллизий и всевозможный QoS для резервирования полосы/арбитража.
Можно было бы что-нибудь попроще по мотивам изобразить.
Один из плюсов кана — 3 провода на ворох узлов, а в вариации с лампочками так сам бог велел, только я не совсем понял чего автор на каждый узел повесил всего 4 лампочки.
А если это не щит где места вагон, а автомобиль, где короткие сообщения уровня поверни зеркало, включи обогрев стекла?
А колхоз в виде терминаторов — один джампер на конечной и начальной плате, где там колхоз?
Но опять же, всё зависит от задачи, не надо пихать кан туда где ему не место.
теперь оно называется CAN_FDА почему через подчеркивание?
как обеспечить связь ПК:Ethernet — Контроллер:CAN.
Без конвертера Ethernet<->CAN — никак. Но что мешает воткнуть в компьютер плату CAN типа PCI7841?
Просто хочу влезть в тему разработки элементов промышленной автоматики (различные реле параметров электрической сети, терморегуляторы и т.д.). Беглый анализ рунета в этой сфере, наталкивает на мысль, что надо учить разработку на базе STM32, (как лучших по цене/функционал/производительность). Но что мне уже хочется чтобы мои устройства умели общатся мжду собой и по scada. С протоколом Modbus, уже более менее поработал (как пользователь устройств), и вот я увидел что не малая часть чипов STM32, аппаратно поддерживают CAN. Про этот протокол слышал лишь краем уха, да и встречал его в некоторых немецких станках кои приходилось налаживать. вот и начал собирать информацию на русском по этой теме, в частности попал на эту статью автора. Потому если делать поддерку протокла CAN, то интересует все сферы его использования, и главное общение с ПК. Особенно как отдавать и получать комманды из приложений написанных под windows. Также интересует в какой, среде лучше кодировать прошивку Stm32 с учетом поддержки RS485 и CAN?
Что значит «лучше»? Я как‐то писал прошивку как раз для общения компьютера с Windows с «чем угодно» через CAN, в качестве переходника CANUART (в планах как‐нибудь сделать CANUSB, но до этого пока не дошло). У меня прошивка создавалась в Neovim на языке Rust, ответная часть на LabVIEW. Neovim — потому что *vim мне нравится, а привыкать к какой‐либо IDE, даже если бы я имел такое желание, в нашей компании не имеет смысла. Rust — потому что интересно изучить. Более того, данная прошивка вообще была первым моим проектом на Rust (и даже не первым сколько‐либо серьёзным, а вообще первым). LabVIEW — потому что почти всю автоматизацию в компании мы пишем на нём.
Замечу, что даже несмотря на высокую незрелость экосистемы Rust для микроконтроллеров (прошивка писалась вроде где‐то полтора года назад) и отсутствие опыта в написании программ на Rust, основные проблемы с прошивкой были только в плане ошибок при использовании регистров специального назначения — в общем, то, что вы получите, если будете работать без HAL. Уже тогда присутствовали крейты для создания асинхронных прошивок для stm32 на Rust, включавшие в себя reentrant очередь, раскладывание нужных переходов по векторам прерываний, критические секции, генерацию условно безопасных API низкого уровня для доступа к регистрам специального назначения по файлам описания микроконтроллеров. Сейчас со всем должно быть получше — как минимум, насколько мне известно, более не требуется ночная сборка компилятора Rust.
CANUART (в планах как‐нибудь сделать CANUSBА UART прямо вот RS232, втыкаемый в аппаратный COM-порт на компе? Или с еще одним переходником USB-UART?
Стоит заметить, цепочка CAN — UART- USB вполне пригодна для такой задачи, UART что в большинстве МК, что в микросхемах USB-UART может раскочегариваться до мегабода а то и двух. Соответственно, можно работать с CAN на скоростях до 500 К — 1 М.
Я когда-то делал подобный адаптер на AT90CAN128 и FT245. Программа на компе взаимодействовала с драйвером через D2XX API вместо виртуального COM-порта.
С переходником USB⇔UART. COM порт на плате тоже есть, но у переходника, как и у USB, имеется одно преимущество: оба предоставляют питание. USB так и не сделал, поскольку быть первопроходцем нет желания, готового шаблона «как сделать виртуальный COM порт на Rust и STM32» я до сих пор не видел, а вариант с переходником уже нормально работает.
Потому если делать поддерку протокла CAN, то интересует все сферы его использования, и главное общение с ПК.
У нас CAN используется для связи с устройствами комплекса в реальном времени. Когда надо — с PC (под ОС QNX 6.3), когда надо с центральной ЭВМ на базе миландровских микроконтроллеров. В отличие от Ethernet, CAN работает в реальном времени и позволяет организовать обмен с устройствами, разнесённый с точностью до долей миллисекунды. Для PC используются платы CAN 527 D (она ISA), PCI7841 (она, ожидаемо, PCI — мне больше всех нравится) и sysWORXX USB-CANmodul (этот в USB вставляется — его не рекомендую, проблемы с ним есть при долговременной работе в нагруженной сети).
1--Как определить сколько time quantum (Tq) следует выделить пред делителем для одного CAN бита? 10? 20? 40? Проще говоря, какое разрешение нужно для одного CAN бита? Это можно как-то математически рассчитать? На сколько квантов разбить один бит?
2--Как распределить кванты на интервалы sync, prop, seg1 и seg2?
CAN или не CAN? Или зачем мне сеть микроконтроллеров?