Pull to refresh

Comments 49

Мама кушать зовет — это хорошо. Жаль, что так рано) Только разогнался)
Познавательно, с юморком, спасибо.

у кана только 1 достоінство — аппаратная реализация,
хотя если есть дма, то и в уарт пакеты кидаются с одного пинка.

а из недостатков — на загруженной шине время ответа самого низкоприоритетного устройства будет большим. также и высокие накладные расходы на передачу
image
Ну что значит «аппаратная реализация», ведь и про UART можно сказать, что у него аппаратная реализация — ведь биты кадра (старт, данные, четность, стоп) формируются не программно.

Аппаратный арбитраж же.
Каковой и позволяет перейти от двухуровневой иерархии «один ведущий, остальные — ведомые» (причём ведомые без команды ведущего вякнуть не смеют) к многоуровневой по приоритетам сообщений (и все могут по своей инициативе начинать передачу).

Ну а приоритет = срочность, да. Но вопрос задержки низкоприоритетных — это вопрос пропускной способности, это должно учитываться при проектировании сети. Если загруженность настолько высока, что задержки становятся критичными — стоит или повысить скорость передачи (если позволяет размер линии), или разбивать на отдельные домены с шлюзованием.
ага, сначала создадим универсальный протокол, чтобы все работало вместе. потом увидев результат, выделим критично важные устройства в отдельную сеть. чтобы другие не мешали работать.
Серебряной пули не существует, как и универсального протокола, применимого во всех мыслимых случаях. Всегда есть какие-то ограничения.
Дело не в ДМА, по сравнению с уартом (485), достоинство кана в разруливании коллизий на физическом уровне, благодаря несимметричным 0/1 на линии.
Если два устройства начнут что-то слать одновременно, тот, у которого адрес менее приоритетный, может понять, что он пытается говорить одновременно с кем-то другим и перестать это делать, не мешая при этом более высокоприоритетному участнику, и его сообщение при этом не испортится.

В этом же и недостаток, все должны быть на расстоянии распространения 1 бита туда/обратно. А 485 можно с правильным драйвером и десятки МБит на сотни метров запустить, но коллизии/арбитраж шины разруливать придётся самому на уровнях выше.

А накладные расходы будут и у 485, если на шине больше чем 2 участника и нужна адресация и хоть какой-то протокол поверх.
ну если гонять большие пакеты, пусть 64 байта, то расходы на заголовок и контролльную сумму будет не так много занимать как в случае 8 байт данных.
ну и +20, а то и 30% оверхэда на старт/стоп биты у уарта.
UFO just landed and posted this here
UART это поток, где как-то прилется реализвывать определение начала и конца сообщений, наличие несколькоих устройств на шине итд. CAN все это делает за вас. А если учесть, что есть еще и CAN-FD с размером пакета 64 байта, и устройства с 8-ю а то и 16-ю канами то становится все очень неплохо
У CANa три достоинства: аппаратное разруливание коллизий, мультимастерность и встроенный CRC.
UFO just landed and posted this here
Вдруг кому пригодится (или кто-то улучшит или найдёт ошибки). Вот мои драйвера для плат CAN 527D и PCI7841 для QNX 6:
CAN527D
PCI7841

А мне лично CAN в промышленных ПЛК не особо понравился — начиная с оконечных терминаторов, которые выглядят «колхозом» заканчивая ограниченной длинной линии. Проще унифицироваться через industrial Ethernet в его модификациях.

Ethernet требует свитча, ну и топология звезда а не шина. Хотя сейчас появляется автомобильный по одной паре с полным дуплексом

100base-t1, он хоть и по одной паре, но всё равно звезда и свичи. csma/cd там не предусмотрен.

etherCAT, топология кольцо, провод условно один, от соседа к соседу, но вот количество приёмо-передатчиков удваивается.

Сейчас разрабатывается ещё 10base-t1s (несколько устройств на одной паре), и 10base-t1l — 1 км по одной паре

ещё бы и цену за карточку как у обычных… уух!
не прошло и 10 лет как 10base2 выкинули из 802.3 за ненадобностью и вот он — технологический прорыв — 10мбитный multidrop, теперь до 15м и до шести устройств на шине.

Тот был по дорогому коаксиалу, с дорогими разъёмами, т-коннекторами. А тут простая витая пара даже без экрана. То что нужно для машины

неубедительно.
этого провода для машины надо 15м — о чём намекает максимальная длина нового 10base-t1s. Да и «без экрана» для машины тоже так себе идея.
А первый попавшийся в интернете магазин предложил купить rg-58 за 50 европейских копеек/м. витая пара в розницу настолько дешевле?
Коннекторы подороже немного, но всё равно копейки по сравнению с ценой самого сетевого оборудования.
Да и сделать выход диффернциальным, а не single-ended на коаксиал, оставив всё остальное как есть, тоже конечно задача стоящая десятилетий разработок новых стандартов.

Да, я понимаю что они вроде хотят скрестить этот новый езернет с кэном, чтобы как у него коллизии и арбитраж сделать на физическом уровне, а всё что выше оставить совместимым с обычным езернетом.
Но кто мешает это делать уровнями повыше, например есть тот же 1588 для синхронизации, чтобы избегать коллизий и всевозможный QoS для резервирования полосы/арбитража.
Можно было бы что-нибудь попроще по мотивам изобразить.
ethercat работает по топологии шины
а это на смотря каком уровне на это смотреть
наверно не правильно выразился, в том смысле что не звездой а последовательно соединяются блоки. картинка потрясающая.
И прокладывать кабели толщиной в ногу? вы только представьте себе 100 кабелей индастриал изернета.
Один из плюсов кана — 3 провода на ворох узлов, а в вариации с лампочками так сам бог велел, только я не совсем понял чего автор на каждый узел повесил всего 4 лампочки.
А если это не щит где места вагон, а автомобиль, где короткие сообщения уровня поверни зеркало, включи обогрев стекла?

А колхоз в виде терминаторов — один джампер на конечной и начальной плате, где там колхоз?

Но опять же, всё зависит от задачи, не надо пихать кан туда где ему не место.
У автора есть вариант и на 64 «лампочки». В тот раз разбросано шибко было.

Для лампочек лучше использовать LIN. Там тоже есть CRC. И есть чипы с питанием от батареи и встроенным трансивером, и выходами к которым можно прямо светодиод цеплять

Лампочки были давно. Сейчас уже до фотодиодов дошло. Может, соберусь написать.

Рекомендую взглянуть на чип MLX81108. У него и ADC есть. Есть в soic. И вроде аналог в qfn20

Так в чём проблема. Ставьте CAN на оптике. Там всё также, как и на проводе — наличие света — доминантный уровень, отсутствие — рецессивный. Будет на километр бить без вопросов.

Так длина линии ограничена не тем, как далеко проходит сигнал, а тем, как быстро. Если мне не изменяет память, по оптоволокну сигнал идёт медленнее, чем по меди — если выбирать её с учётом коэффициента укорочения.

В отличиях, отчего-то, нет цены драйвера, хотя разница — существенная, раз в пять.
теперь оно называется CAN_FD
А почему через подчеркивание?
Дурная привычка. Не обращайте внимания.
Спасибо за статью. Как введение не плохо. К сожалению про CAN протокол мало информации, хотелось б spyfnm как обеспечить связь ПК:Ethernet — Контроллер:CAN. Есть ли библиотеки под С++/Delphi, для того чтобы мониторить, переменные состояния контролера из под ПК.
как обеспечить связь ПК: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.

Я в процессе проектирования и внедрения систем автоматики с CAN сталкивался и работал только с ПЛК Воронежского производителя. Для отладки и заливки программ там идет RS-485, для общения с сервером, АРМ — коммуникационный модуль CAN-Ethernet своего производства.
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 вставляется — его не рекомендую, проблемы с ним есть при долговременной работе в нагруженной сети).
неправда, время ответа в загруженной линии не гарантируется. особенно если общатся с покупным устройством.
А кто сказал, что у нас линия загружена? ;) У нас чёткая диаграмма обмена.
Sign up to leave a comment.

Articles