Реализация фильтрации CAN сообщений и памяти

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

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

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

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

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

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

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

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

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

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

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

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

Однако, при условии:

и

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

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

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

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

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

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