CAN шина и Linux

При переключении контекста процессор не выполняет никакой полезной нагрузки и в нашем случае 79 микросекунд из 100 он будет выполнять бесполезную работу - о чем тут дальше говорить ? процессор на 80 % занят бесполезной нагрузкой

Тут много зависит от состояния кэша

Но, практика - критерий истины

root@rt:~# cat /proc/cpuinfo 
processor	: 0
model name	: ARMv7 Processor rev 0 (v7l)
Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 
...
processor	: 1
...
Hardware	: Xilinx Zynq Platform

root@rt:~# uname -v -r
3.12.24-rt38-yocto-standard #1 SMP PREEMPT RT Wed Jul 22 15:16:10 CEST 2015

Для сравнения:
root@rt:~# dd if=/dev/zero of=/dev/null bs=1K &

root@rt:~# top -b -n1 |head -n 6
Mem: 61168K used, 190480K free, 0K shrd, 1292K buff, 34260K cached
CPU:   4% usr  50% sys   0% nic  45% idle   0% io   0% irq   0% sirq
Load average: 1.00 0.99 0.78 2/88 1931
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1905  1813 root     R     2752   1%   0  50% dd if /dev/zero of /dev/null bs 1K
 1930  1813 root     R     2752   1%   1   5% top -b -n1

Включаем железный генератор CAN трафика (1mbit 8000 msg/sec) и candump:
root@rt:~# candump -td can0 >/tmp/dump.txt

Смотрим что получилось:
root@rt:~# head /tmp/dump.txt 
 (000.000000)  can0  100   [7]  01 02 03 04 05 06 07
 (000.000129)  can0  100   [7]  01 02 03 04 05 06 07
 (000.000129)  can0  100   [7]  01 02 03 04 05 06 07
 (000.000129)  can0  100   [7]  01 02 03 04 05 06 07
 (000.000111)  can0  100   [7]  01 02 03 04 05 06 07
 (000.000111)  can0  100   [7]  01 02 03 04 05 06 07
 (000.000129)  can0  100   [7]  01 02 03 04 05 06 07
 (000.000129)  can0  100   [7]  01 02 03 04 05 06 07
 (000.000129)  can0  100   [7]  01 02 03 04 05 06 07
 (000.000129)  can0  100   [7]  01 02 03 04 05 06 07

root@rt:~# top -b -n1 |head -n 8
Mem: 43888K used, 207760K free, 0K shrd, 1292K buff, 17128K cached
CPU:  23% usr  58% sys   0% nic  17% idle   0% io   0% irq   0% sirq
Load average: 1.57 1.34 1.03 2/89 1958
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1905  1813 root     R     2752   1%   1  27% dd if /dev/zero of /dev/null bs 1K
 1109     2 root     SW       0   0%   0  24% [irq/60-e0008000]
 1952  1838 root     S     1544   1%   1  16% candump can0
 1957  1813 root     R     2752   1%   0   8% top -b -n1

Без dd:
root@rt:~# top -b -n1 |head -n 7
Mem: 42968K used, 208680K free, 0K shrd, 1292K buff, 13156K cached
CPU:   8% usr  25% sys   0% nic  66% idle   0% io   0% irq   0% sirq
Load average: 0.88 0.90 1.00 2/88 2021
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 2017  1838 root     R     1544   1%   1  14% candump -td can0
 1109     2 root     RW       0   0%   0  12% [irq/60-e0008000]
 1113     2 root     SW       0   0%   1   5% [irq/83-e0009000]

Для моих usecases этого вполне хватает. Если надо еще рилтаймовей - у Zynq'а есть вмонтированная FPGA

Если ты из современного топового процессора делаешь контроллер CAN то ты извини дебил.

Если это решит проблему заказчика в кратчайшие сроки то мне с большим сожалением придется проигнорировать мнение анонимуса по этому поводу

Брат анонимус не шибко прав, но твой способ оверкил. Хотя кто я, чтоб тебя судить, заказчик доволен и чудно.
А вот с прерываниями интересней, можно cat /proc/interrupts ?

Брат анонимус не шибко прав, но твой способ оверкил.

какой нафик оверкилл - тест ниочем

А вот с прерываниями интересней, можно cat /proc/interrupts ?

SocketCAN поддерживает поллинг и в таком тесте пакеты принимаются без всякой обработки - кучей за одно прерывание. На реальной задаче когда пакеты в стопку не сложишь все будет гораздо печальней. Собственно не зря сейчас в тренде гибридные процессоры - толстенький ARM cortex-a + микроконтроллерное ядро для RT задач.

Ядра два, хочу посмотреть, работает балансинг или нет, судя по шуму в инетах лучше бы не работал. Собственно за тем и попросил

И та, задачу не описали, может только лог и драть с шины ни на что другое ресурсы не тратятся

А вот с прерываниями интересней, можно cat /proc/interrupts ?

root@rt:~# cat /proc/interrupts          
           CPU0       CPU1       
 29:      16620      15642       GIC  29  twd
 35:          0          0       GIC  35  f800c000.ps7-ocmc
 39:          2          0       GIC  39  f8007100.ps7-xadc
 40:          0          0       GIC  40  f8007000.ps7-dev-cfg
 41:          0          0       GIC  41  f8005000.ps7-wdt
 43:      42849          0       GIC  43  ttc_clockevent
 45:          0          0       GIC  45  f8003000.ps7-dma
 46:          0          0       GIC  46  f8003000.ps7-dma
 47:          0          0       GIC  47  f8003000.ps7-dma
 48:          0          0       GIC  48  f8003000.ps7-dma
 49:          0          0       GIC  49  f8003000.ps7-dma
 51:          3          0       GIC  51  e000d000.ps7-qspi
 53:         27          0       GIC  53  ehci_hcd:usb1
 54:     731009          0       GIC  54  eth0
 56:       1724          0       GIC  56  mmc0
 57:          0          0       GIC  57  xi2cps
 59:        580          0       GIC  59  xuartps
 60:     827842          0       GIC  60  e0008000.ps7-can
 72:          0          0       GIC  72  f8003000.ps7-dma
 73:          0          0       GIC  73  f8003000.ps7-dma
 74:          0          0       GIC  74  f8003000.ps7-dma
 75:          0          0       GIC  75  f8003000.ps7-dma
 77:          0          0       GIC  77  eth1
 80:         12          0       GIC  80  xi2cps
 83:     827844          0       GIC  83  e0009000.ps7-can
IPI1:          0        320  Timer broadcast interrupts
IPI2:      28976    1017765  Rescheduling interrupts
IPI3:          0          0  Function call interrupts
IPI4:          6          5  Single function call interrupts
IPI5:          0          0  CPU stop interrupts
Err:          0

Динамика при тех же самых 8000 msg/sec

root@rt:~# while true; do cat /proc/interrupts|grep can;  date "+------ %H:%M:%S"; sleep 1; done
 60:     109606          0       GIC  60  e0008000.ps7-can
 83:     109608          0       GIC  83  e0009000.ps7-can
------ 10:22:35
 60:     118258          0       GIC  60  e0008000.ps7-can
 83:     118263          0       GIC  83  e0009000.ps7-can
------ 10:22:36
 60:     126772          0       GIC  60  e0008000.ps7-can
 83:     126773          0       GIC  83  e0009000.ps7-can
------ 10:22:37
 60:     135002          0       GIC  60  e0008000.ps7-can
 83:     135002          0       GIC  83  e0009000.ps7-can
------ 10:22:38
 60:     143213          0       GIC  60  e0008000.ps7-can
 83:     143214          0       GIC  83  e0009000.ps7-can
------ 10:22:39
 60:     151461          0       GIC  60  e0008000.ps7-can
 83:     151462          0       GIC  83  e0009000.ps7-can
------ 10:22:40
 60:     159756          0       GIC  60  e0008000.ps7-can
 83:     159757          0       GIC  83  e0009000.ps7-can
------ 10:22:41
 60:     168018          0       GIC  60  e0008000.ps7-can
 83:     168019          0       GIC  83  e0009000.ps7-can

но твой способ оверкил

Если посмотреть на вывод последнего топа, то можно заметить «66% idle»

Я не сторонник делать «из современного топового процессора контроллер CAN», но иногда возможность быстро представить работающее решение очень важна

Да, чтобы было более понятно со счетчиками прерываний, железный генератор CAN трафика реализован в FPGA и юзает high-priority transmit buffer одного контроллера, на втором крутится candump

И та, задачу не описали, может только лог и драть с шины ни на что другое ресурсы не тратятся

Такое железо используется для различных специализированных гейтвеев, логгеров, restbus simulation и data acquisition

Нагрузка обычно до 2000 сообщений/сек по нескольким шинам + логика обработки сигналов + логгинг на SD-card + мониторинг на PC over Ethernet

По своему опыту могу сказать что загрузку системы больше 30% в реальном использовании пока не видел, хотя не сомневаюсь что могут попасться задачи гораздо более требовательные к ресурсам

Аха, поглядел. В топе irq can на первое ядро попалось, но спит и выгружено, в самих прерывалках только на нулевом. Похоже не зря бугуртят, балансировку и правда лучше отключить, да подвязать все к ядрам ручками. Благодарствую

Среды разработки/Дебагер

в основном работаю с PIC'ами

Если думаете использовать PIC, то следует смотреть в сторону PIC18F458 и подобных. Это хороший и надёжный МК, который имеет аппаратную поддержку CAN.

Для PIC портирована на Linux официальная IDE от Microchip MPLAB-X, но она на Java, так что это изделие на любителя. Я предпочитаю использовать только компилятор C18 и работаю с ним через обычные Makefile'ы. Ещё есть компилятор XC-8 . Оба компилятора закрытые. Для прошивки через командную строку при помощи программатора PicKit2 служит утилита pk2cmd.

Раньше была open-source IDE PiKDev, но она скончалась вскоре после выхода KDE4.

Но! Сейчас я бы не советовал связываться с PIC, а смотреть в сторону MSP430 и STM32.

Компиляторы С для PIC очень недружелюбны к пользователю по сравнению с таковыми для MSP430 и STM32. Оба компилятора C18 и XC-8 не основаны на GCC, следовательно имеют свои уникальные ни с чем не совместимые багофичи, которые придётся изучать. Библиотека, прилагаемая к компилятору C18 забагованная. Также PIC в несколько раз дороже, чем MSP430 и STM32. Разумеется, MSP430 и STM32 имеют тулчейны для Linux.

Кроме программных средств для работы с CAN ещё понадобятся аппаратные средства. В частности какой-либо переходник USB<->CAN. Он позволит подцепить к компу наше устройство и смотреть обмен по CAN, аналогично тому как мы используем терминальную программу для отладки устройства с UART. Например, может подойти вот такая штука: http://www.fischl.de/usbtin/

Proteus

Аналога Протеуса для Linux нет. Был проект KTechLab, в котором можно было симулировать PIC-контроллер. Но проект умер около 2009 года в связи с выходом KDE4. Сейчас существует SimulAVR.

TkGate позволяет симулировать в интерактивном режиме цифровые схемы, в том числе с модулями Verilog.

Я тоже в студенческие годы использовал Протеус, но потом после того как несколько раз искал несуществующие баги у себя в проекте от его использования отказался. Перешёл на использование осциллографа и отладочных плат.

Большинство проблем с прошивками для МК возникают из-за взаимодействия с периферией. А здесь симулятор не поможет, так как в нём невозможно предусмотреть все возможные модели периферии. Так что разработку для МК вполне можно вести без симулятора. Намного полезнее будет осциллограф.

Я предпочитаю использовать только компилятор C18 и работаю с ним через обычные Makefile'ы. Ещё есть компилятор XC-8 . Оба компилятора закрытые.

А есть еще замечательный открытый SDCC который уже давно пользуют все нормальные люди для PIC10/12/16/18 вместо всякой непонятной глюкоты.

SDCC не тестировал. Если опять надо будет что-то делать на PIC'е, то попробую его.

Кстати, ещё забыл написать про открытый ассебмлер для PIC gpasm

Эндрю Триджел зимой рассказывал про применение PREEMPT_RT https://www.youtube.com/watch?v=2Twl2mQAh6g

Демонстрация нормальной работы стабилизации при 100% загрузке процессора мне особенно понравилась.

лол, на армах никогда и не было балансировки прерываний, все роутится на бут цпу... хочется балансировкт гугли irqbalance

Иди погугли сам чтоль. Не я понимаю, что это не работает, но маркетойды втирать не прекращают. Собственно я все уже посмотрел, так что и тебе не хворать.

Плохому учишь, плохому. 32 ую надо советовать. Например ознакомиться с этим - http://microchip.wikidot.com/32bit:mz-arch-isa-cpu-shadow-registers

http://www.microchip.com/pagehandler/en_us/devtools/mplabharmony/home.html

http://www.microchip.com/pagehandler/en_us/devtools/code_configurator/home.html

Да много чего нового и полезного появилось за последние пару лет

А подскажите, пожалуйста, название какого-нибудь мало-мальски хорошего-удобного usb-can адаптера, который нормально заводиться под linux'ами

Честно говоря я их только один щупал: http://www.systec-electronic.com/en/products/industrial-communication/interfa... Завелся с полпинка (драйвер накатить, да в udev правила переписать правильно из доки).

Нашел вот такую штуку.Может беглым взглядом глаз зацепиться почему этот адаптер НЕ стоит покупать?

http://www.amazon.com/KEDSUM-Converter-Adapter-Dual-channel-Interface/dp/B00D...

А вот тут даже про Малину сказано:

http://www.amazon.com/ViewTool-Raspberry-Connector-Analyzer-Compatible/dp/B00...

не вижу ни одной причины не покупать представленные образцы.

Хотя прежде чем покупать неплохо бы с их офсайта качнуть драйвера и попробовать их собрать и установить на своей системе. Бывает, что они для весьма старых ядер, и напрямую воткнуть их не получится (или придется погрузиться в розовые сопли разработки дров для линукса)

Хотя прежде чем покупать неплохо бы с их офсайта качнуть драйвера и попробовать их собрать и установить на своей системе

Так и поступим, спасибо

Если нет необходимости точно следовать какому-нибудь CANopen, крайне рекомендую не тратить деньги на НĒХ, а сделать свой переходничок.

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

Ну, а с самопалом достаточно просто: мелкоконтроллер по USB-CDC подключается к компьютеру и фактически эмулирует последовательный порт, а уж протокол общения, думаю, освоишь быстро. Правда, скажем, какой-нибудь дешевенький STM32 на cortex-M3 использовать не получится (там одновременно USB и CAN не живут), нужно хотя бы M4.

А не вкурсе, можно ли подключить CAN к cubieboard? Прогуглив не нашел однозначного ответа

На aliexpress я видел платки CAN-SPI.

Не вкурсе, а с точки зрения ОС шина все равно будет видна как can0 ?

Не в курсе. Я через них хотел контроллеры цеплять, а на основном компьютере использовать CAN-USB.

Да, можно. http://sourceforge.net/projects/can4linux/ CAN контроллер Allwinner'а там есть. Нужно только какой-нибудь тупой CAN трансивер типа SN65HVD230 на ноги PH20(CAN_TX) и PH21(CAN_RX) (на всех популярных одноплатниках, в том числе и на кубике они выведены как GPIO на разъём) прицепить и всё.

В тырнетах пишут что на A10 не получается получить стабильных результатов, т.к. не хватает документации. Если компильнуть can4linux есть ли возможность поднять can0 без дополнительного девайса и прогнать какой-нибудь самый простой тест на то, что оно хотя бы планирует работать?

can4linux - это совсем не то, что в ванильном ядре, которое для Allwinner'а ещё не готово. Это типа костыль такой отдельный. Никакого сетевого интерфейса can0 не будет, будет /dev/can0 в которое можно писать и из которого можно читать. Пока ядро не допилили это единственное что работает на Allwinner'ах с ядром 3.4 при сохранении всех ништяков SoC. У A10 и A20 одинаковые CAN-контроллеры, если чо.

В общем, сюда читай: http://www.can-wiki.info/can4linux/man/index.html

Блин, а существует ли такая девайсина, которую тыкнул в компьютер - и все само подтянулось, точно так же как Ethernet. Очень уж не хочется заморачиваться на второстепенных задачах. В принципе одним из критериев, почему я отказался от 1-wire было то, что оно работало не стабильно. От can очень хочется стабильности

1-wire
работало не стабильно

???

От can очень хочется стабильности

???

Еще раз: свой велосипед решает все проблемы! Открываем /dev/ttyACM0, читаем-пишем, а оно уже по CAN принимает/отправляет данные. Единственное простейшее универсальное решение «на коленке за гроши».

Использовал 1wire достаточно долго. Постоянно отваливались девайсы, owfs с какими то не понятными оверетлаии, чтение с датчиков температуры зачастую выдаёт 85*. Вобщем от одно провода сплошной негатив. +очень слабая помехозащишенность (доходило до смешного, когда сеть отваливались, когда рядом с линией включались реле )

А расскажите об этом велосипеде поподробнее пожалуйста (как это реализовать?)

А что можете сказать об http://www.amazon.com/gp/product/B0152VCIA6?psc=1&redirect=true&ref_=...

?

Постоянно отваливались девайсы

Значит, хреново с питанием было. Либо слишком длинная линия. Проверка контрольной суммы + медианная фильтрация — вот решение проблем. Во всяком случае, я гонял 8 датчиков 18x20 на одной шине (питание активное), проблем не наблюдал.

как это реализовать?

Да элементарно. Я, собственно, когда-то подобное на пиках делал. Сейчас бы сделал, скажем, на STM32 (у какого-нибудь F407 хватит ресурсов, чтобы одновременно и CAN, и USB, и ethernet работали).

Кстати, ethernet на МК — классная вещь! Совершенно не надо париться при необходимости линий связи в несколько километров.

Зачем, если на борту есть «железный» CAN? Нужно лишь прикупить конвертер уровней. Дешевые конвертеры нуждаются в дополнительном (правда, копеечном) обвесе, дорогие в обвесе не нуждаются.

Блин, а существует ли такая девайсина, которую тыкнул в компьютер - и все само подтянулось, точно так же как Ethernet.

Существует. Это Ethernet.

Вообще, на самом деле все эти ублюдочные USB, FireWire и прочий шлак вроде CAN или RS485 должны были быть давно заменены на Ethernet. Для подключения мышей/клавиатур и всяких прочих флешек есть PoE. Но, сцуко, USB запихать в дохленький микропроцессор микрухоклепателям не западло, а Ethernet обязательно только, сцуко, в многоногом чудовище должен быть. Хотя минимальная, но более чем достаточная для мелких вещей реализация 10-ки, например (энкодер, декодер, PHY и тупенький DMA к буферу в памяти, точно такой же, как для USB, а не то кромешное говно, что микрочип нагородил в ENC28J60), требует чуть ли не в 3 раза меньше элементов чем USB со всеми его безумными control registers и прочей шнягой. Для 10ки вообще никаких регистров кроме парочки адресов буферов не нужно. И какой-нибудь несложный обмен по UDP реализуется в коде в разы проще, чем самый элементарный USBшный bulk с его дурацкими control endpoint, дескрипторами и прочей гадостью.

В качестве «конвертера» может выступать mcp2515?

Ты хотел сказать mcp2551? Да, хватит за глаза. А всякие извраты вроде 2515 нужны для мелкосхем, у которых железного CAN нет. Но нафига мучить софтовую часть, если можно сделать аппаратно?

// кстати, некоторые извращенцы умудряются, допустим, на STM32 1-wire ногодрыгом реализовать, хотя там элементарно делается почти аппаратное решение на таймере и ПДП.

Если все же есть возможность- расскажите поподробнее. Какая программная часть необходима? Модули ядра? Манипуляции с самими линуксами?

Какая программная часть необходима?

В минимуме — хватит screen или minicom/com/самопальный терминальный клиент.

Модули ядра?

Везде есть CDC-ACM и сопутствующие.

Но да, это — не как в CANopen или CAN4linux.

Еще раз. У вас есть плата с линуксом у которой есть какие-то аппаратные интерфейсы среди которых CAN нет. Так? Вы хотите подключить к нему CAN. Точней вам нужен некий конвертер интерфейсов (например SPI-CAN или USB-CAN). Так? Самый беспроблемный это USB-CAN. Скорей всего есть драйвера и т.д. Хотя лично мне больше нравиться какой-нидь SPI интерфейс (работать по прерываниям лучше чем по опросу). Но подключить через него CAN в линуксе скорей всего геморно (хотя и могу ошибаться).

http://www.amazon.com/gp/product/B0152VCIA6?psc=1&redirect=true&ref_=...

Этот вариант мне нравится именно тем что SPI и что там есть выход прерывания. Но как это впердолить в линукс я не знаю (явно нужен спец драйвер).

Привет вам.

Итак, пришло таки устройство http://www.amazon.com/gp/product/B0152VCIA6?psc=1&redirect=true&ref_=...

Затем, я собрал себе чистенький Дебиан на мэинстримовском ядре. Делал я по вот этому мануалу http://linux-sunxi.org/Manual_build_howto

И возникла вот такая неприятная проблема: почему-то нет устройства SPI. При конфигурации устройства я сделал вот так:

Linux Kernel Configuration
     Device Drivers
        SPI support
           Utilites for Bitbanging SPI masters
           GPIO-based bitbanging SPI Master
           Allwinner A10
           Allwinner A31
     Networking support
        CAN bus subsystem support
           CAN device drivers
               Virtual Local CAN Interface (vcan)
               Platform CAN drivers with Netlink support
                 CAN bit-timing calculation
                 #?? Enable LED triggers for Netlink based drivers
                 TI High End CAN controller (HECC)
                 Allwinner A10 CAN controller
                 CAN SPI Interface 
                    Microchip MCP251x SPI CAN controller
                 #?? CAN device debugging messages

Вот dmesg загрузки http://pastie.org/10574380

Что бы вам было удобнее, и не пришлось всматриваться в полотно:

root@aaa:/# uname -a
Linux aaa 4.3.0-12225-g0ca9b67 #1 SMP Sun Nov 22 19:24:09 MSK 2015 armv7l GNU/Linux
root@aaa:/# dmesg | grep spi
root@aaa:/# dmesg | grep can
[    0.961232] can: controller area network core (rev 20120528 abi 9)
[    0.971960] can: raw protocol (rev 20120528)
[    0.976249] can: broadcast manager protocol (rev 20120528 t)
[    0.981910] can: netlink gateway (rev 20130117) max_hops=1
[    1.065338] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP
[    1.072852] ahci-sunxi 1c18000.sata: SSS flag set, parallel bus scan disabled

Полагаю, что проблема может быть в dts (device tree source). Логично было бы предположить, что устройство просто не объявлено там. однако:

cat /usr/src/u-boot/arch/arm/dts/sun4i-a10-cubieboard.dts
.....
&spi0 {
        pinctrl-names = "default";
        pinctrl-0 = <&spi0_pins_a>,
                    <&spi0_cs0_pins_a>;
        status = "okay";
};
.....

Так же обратил внимание, что у меня есть 2 файла:

/usr/src/u-boot/arch/arm/dts/sun4i-a10-cubieboard.dts
/usr/src/linux/arch/arm/boot/dts/sun4i-a10-cubieboard.dts

Вобщем, подскажите что-нибудь, пожалуйста

http://www.amazon.com/gp/product/B0152VCIA6?psc=1&redirect=true&ref_=...

$8.99

Епануццо! Этому девайсу красная цена 2$ с доставкой.

Хм. Конкретно ничего не подскажу. Но в целом вы мыслите верно. Сначала надо SPI поднять нормально, а потом уже все остальное. Предлагаю для начала какую-нибудь spi-флешку подключить, что бы отладить работу SPI в ядре. А потом уже CAN прилаживать. Ну и начать поиск работоспособных сборок ядра под вашу платформу с вашей периферией. Так как тут много всяких железяк участвует, да еще ядро надо конфигурить, ошибиться можно где угодно. Поэтому действовать надо по шагам, фиксирую на каждом шаге результат. Сначала просто ядро собрать, потом включить SPI и добиться его работы на какой-то заранее работоспособной периферии. А потом уже двигаться дальше.

А не проще было сделать на STM32 каком-нибудь нормальный преобразователь USB<->CAN?

Еще как вариант — софтовый CAN поверх двухбаксового преобразователя RS485<->USB.

Софтовый CAN делаться совсем не хочется. А по поводу STM32 расскажите, пожалуйста, поподробнее, поиск на всяких алиэкспресс ничего вменяемого не показал (либо я чего-то недопонимаю?)

Берем для начала мои велосипеды, но делаем транспорт в CAN. CAN на STM32 есть. Т.е. в минимуме для разработки понадобятся: простая девборда STM32 и спаянный модуль преобразования уровней. Потом уже можно будет в кикаде развести платку и сделать «как у людей».

Правда, реализовать полноценную железку, которую компьютер будет как USB-CAN видеть (чтобы через canOpen какой-нибудь работать) будет сложно. А вот свой протокол — в легкую!

З.Ы. Если тебе не нужно 100500 устройств на линию связи вешать, можешь тупо 485-й интерфейс использовать, повесив на него псевдо-CAN (я так на 232 делал: у каждого устройства можно было перемычками выставить адрес, общение шло в 9 битном режиме — если 9-й бит 0, то устройство слушало адрес и отвечало, если он совпадает; все остальное общение — только с 1)