Порекомендуйте бюджетное готовое решение или открытую платформу.

Требуется самый простой мост Ethernet-CAN.
При беглом поиске обнаружено:
Импортное - цена под 400 Евро (HD67048 и т.п.)
Отечественное - 6500 р. ( http://zaozmi.ru/catalog/ethernet_can_shluz.html )

Может существует более дешёвый вариант, корпус не требуется.

Видел информацию по ARMGeoSpyder - слишком избыточен.


Благодарю.

А стандарта-то, как такового, по нижним уровням OSI, не существует. И общих решений тут быть не может. Поправьте меня, если я неправ.

Разработка на этапе эскизов.
Поэтому пока жёстких требований ни по физическому уровню, ни по уровню транслирования CAN<>Ethernet нет.

Предварительно остановились на варианте от завода мехатронных изделий.
Но может существует ещё более бюджетное решение.

Целесообразность собственной разработки (время и ресурсы) пока под вопросом.

самый простой мост Ethernet-CAN - микроконтроллер с двумя аппаратными интерфейсами.
возможность использовать для своих нужд готовые чужие изделия- звучит сомнительно. инкапсуляция кадров CAN в кадрах Ethernet не стандартизована.


а обратная задача - передача произвольных кадров Ethernet по сети CAN, т.е. Ethernet -CAN-Ethernet выглядит еще загадочнее.

Какие вообще Вы придумали "проблемы" и какие требуются "решения" для инкапсуляции одного пакетного протокола в другой?



С какого перепуга Вы решили, что Автору нужно, например, по электрониксу через CAN бродить? Хотя и с этим проблема стемится к 0, ибо задача уж явно не стоит связаться с неведомым CAN устройством неведомого производителя у которого с другой стороны торчит какой то Ethernet. Так какая проблема бить те-же Ethenet фреймы на фреймы меньшего размера?

Я довольно быстро сделал WiFi-CAN на основе ESP8266 (модуль ESP-01) и STM32.
Гонять маленькие кадры CAN по Ethernet/WiFi не очень, т.к. возникают вопросы с буферизацией, таймаутами.
Но мой протокол CAN не особо к этому чувствителен.
Если интересно - могу безвозмездно поделиться. Планирую в будущем сделать проект WiFi-CAN свободным.

С какого перепуга Вы решили, что автору это не нужно?
С какого перепуга Вы решили, что купленное автором чужое устройство, решающее вполне определенный круг задач, справится с неизвестной вам задачей автора?

Разбить и передать и не потерять поток 100Мбит с кадрами 1500+байт по сети до 1Мбит 8 байт - никаких проблем нет? рад за вашего работодателя, отличного специалиста держит.

Почему 100? Нынче гигабиты десятками на дворе.

Да, буфер должен быть, как и управление потоком.

Никаких. Хоть азбукой морзе на 50 бод. Это все уже давным давно отработанные вещи - в еще менее скоростные каналы и в синхронные и асинхронные. Разнообразные каналы и протоколы передачи данных существоали и, что характерно были много проработаннее, чем Ethernet cо всякими IP, задолго до их появления. Так что через что только в последствии Ethernet фреймы не предавались и не передаются.

А уж как я рад, что я у себя такой есть

Вроде есть такая прога - HORCH называется. https://sourceforge.net/projects/horch/
Она может напрямую подключаться к CAN Level 2 и выдавать сообщения в виде ASCII через свой Telnet сервер. Также можно обратно слать сообщения путем набора в консоли или TCP/IP сообщениями
Вроде как легко запускается на Raspberry PI с любой CAN мордой типа PiCAN2 - вот вам и дешевенький CAN<->TCP/IP гейтвей.

У нас есть такое устройство в серийном производстве. Габариты платы примерно 50х20 мм. Протокол - самый тупой, LLC. Контроля соединения нет. Квитирования нет. Трансформаторов для ethernet на плате тоже нет :-) . Если интересно - пишите в ЛП.

В линукс есть готовые тилиты для работы с CAN: candump, cansend
Можете взять мой: http://open-plc.com/can_gate.zip
Открытые исходники, через USB-UART можно подцепить к чему угодно. Работа текстом, внешне похоже на candump, cansend, но в "одном флаконе".