basil пишет:

Утверждается, что на 115200 работает (это esp8266).

ESP вы программируете по всей видимости. Зачем вам тогда canny? Возьмите специально для этого предназначенную готовую плату MCP2515 и работайте с ней по мегабиту spi.

Canny привлек внимание тем, что уже адаптирован под физическое подключение к автомобилю. Т.е. в нем реализованы необходимые обвязки для работы с 12/24V напряжением, были примеры его использования, какие-то отладочные инструменты (тот же CCM). Ну и добавилось к этому отсутствие каких-то специальных знаний (с той же MCP2515 в теории познакомился уже позже Canny). При всем при этом я еще и наступил на достаточное количество граблей при интеграции контроллеров (но вряд ли это у Canny вопрос).

Соответственно, на Canny удалось создать некоторый прототип, работающий при некоторых ограничениях (или еще до конца неработающий ). Ну и этот прототип показал недостатки Canny персонально для меня. На текущий момент - это невозможность разработки на C. Язык функциональных диаграмм наверное удобен для относительно простых задач, но мне удобным он не показался. Думаю, что коллеги-разработчики нисколько не потеряют, дав возможность разрабатывать в других средах. И в этом отношении Canny7 могло бы быть аналогом отладочных плат https://www.chipdip.ru/product/stm32f407g-disc1-2.

А что касается ESP8266, то с ним тоже не все гладко Не очень ясно, подойдет ли он.

Утверждается, что на 115200 работает (это esp8266).

ESP вы программируете по всей видимости. Зачем вам тогда canny? Возьмите специально для этого предназначенную готовую плату MCP2515 и работайте с ней по мегабиту spi.

и

Думаю что вам можно попытаться. И наверное стоит брать CANNY 7, потребуется производительность - диаграмма будет большой.

Вам потребуется организовать отбор и запоминание в группе D-триггеров факта прихода и пришедшие данные CAN по каждому известному ID + факт прихода и если нужно данные неизветного ID. И должен быть организован асинхронный цикл по передаче последовательно данных всех D-триггеров управляемый Регистром переполнения UART или подогнанным под время заведомо большее чем время передачи одного сообщения UART генератором импульсов.

Для простоты, чтобы проверить идею и обойтись без каскадирования коммутаторов, я бы сделал диаграмму для 15 известных ID, не более.

С CANNY 7 это будет работать, только если в CAN проходит не более 1 сообщения в ~10 миллисекунд.

Если решать вашу задачу штатными средствами с минимальными потерями данных, то в случае CANNY 7 это будет работать, только если в CAN проходит не более 1 сообщения в ~10 миллисекунд. Если в списке будет не более 16 CAN ID, то это требование можно будет слегка ослабить благодаря наличию в  CANNY 7 16 аппаратных фильтров CAN.

В целом по решению задачи в общем виде (поток на входе превышает поток на выходе):

Боюсь, что мне нечего вам предложить. Полагаю, что для её решения вам потребуется Гранд-отель: https://ru.wikipedia.org/wiki/%D0%9F%D0 … 1%8C%C2%BB

Для вас критично использовать CANNY7 или подойдет и CANNY 5 nano? Вопрос связан с тем, что у CANNY 5 nano быстродействие физических каналов ввода-вывода выше, да и уровни согласовать будет проще.

Нет, не критично. Canny7 был выбран исходя из "максимальности" характеристик.

Какова максимальная скорость UART сопрягаемого устройства?

Утверждается, что на 115200 работает (это esp8266).

Сейчас используется разделитель. Таймаут показался не очень удачной идеей.

Разумно

Задача сплошной ретрансляции трафика CAN на любой из интерфейсов контроллера в общем случае не решается диаграммой достаточно эффективно. Именно поэтому, для CANNY CAN/LIN-monitor используется специализированное системное ПО.

http://forum.canny.ru/viewtopic.php?id=402

Для вас критично использовать CANNY7 или подойдет и CANNY 5 nano? Вопрос связан с тем, что у CANNY 5 nano быстродействие физических каналов ввода-вывода выше, да и уровни согласовать будет проще.

Какова максимальная скорость UART сопрягаемого устройства?

Если вы смиритесь с потенциальной потерей данных, то задача вполне реализуема. 

Если я буду понимать, что данные потерялись, то да, на текущем этапе это устроит.

Эти порядка 10 ID - их точное число и значения будут известны на момент составления диаграммы?

В настоящий момент - да, я их вижу в CCM, они мне известны, но точно появятся новые и переделывать диаграмму очень бы не хотелось (будут сложности с ее обновлением). В идеале конечно было бы здорово иметь возможность накапливать данные по неограниченному числу типов CAN-пакетов, но временно подойдет вариант, когда можно будет работать с 30-50 типами с сигнализацией о том, что пришел пакет с типом, не влезающим в этот список.

В общем случае данные в UART могут идти сплошным потоком. Как вы планируете разделять сообщения UART на принимающей стороне - использовать разделитель вроде '/n' или отслеживая паузы между сообщениями (таймаут)?

Сейчас используется разделитель. Таймаут показался не очень удачной идеей.

Функционально, система должна работать так же как Ваш CCM.exe. Только не в компьютер через USB, а в другое устройство, подключенное через UART (у Вас USB-же тоже наверняка не очень честный, а скорее аналог UART-а).
Меня бы даже наверное устроил бы вариант, когда я бы загрузил Вашу прошивку, работающую с CCM, и выдающую данные не в USB-порт, а в UART порты Canny. Но сейчас есть сложности с настройкой скорости CAN-шины, потому что подключенное через UART устройство не может писать в Canny (электрическая проблема, нужно согласовывать уровни напряжения). А эта прошивка у Вас на чем написана, на диаграммах?

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

Эти порядка 10 ID - их точное число и значения будут известны на момент составления диаграммы?

В общем случае данные в UART могут идти сплошным потоком. Как вы планируете разделять сообщения UART на принимающей стороне - использовать разделитель вроде '/n' или отслеживая паузы между сообщениями (таймаут)?

Проблема в том, что шина работает на скорости 500kbps, а UART на Canny7 - максимум на 57600, что приводит к переполнению (с учетом того, что в UART передаются еще и дополнительные данные). Пакеты приходят с частотой 50 или 100шт/с и их порядка 10 типов (10 разных ID), т.е. их довольно много.

При использовании CCM периодически возникает сообщение COVF (CAN overflow, по всей видимости).

Как правильно на языке функциональных диаграмм реализовать следующую логику: запоминать предыдущее сообщение с таким же ID и в UART отправлять только изменения или делать это 1 раз в секунду? Таким образом, для каждого типа сообщения в UART отправляться данные 1 раз в секунду или изменения. Этого должно быть сильно меньше, CCM - же справляется.  Ситуация осложняется тем, что заранее типы сообщений CAN неизвестны, но можно ограничиться каким-то разумным числом запоминаемых типов сообщений.

По сути - это будет некоторый аналог CCM.