Здравствуйте коллеги,

хочу спросить совета у повидавших виды: стоит задача реализации отправки-приема больших пакетов по CAN.

Приглянулась реализация ISO-TP но исходников нема.
На сайте Техаса предлагают некую контору, которая продает такие исходники за $17500, на гитхабе какие-то недоделки ужасные покопал и понял, что лучше писать самому.

Тут возник вопрос, коли отправляя пакет, нужно ждать подтверждения и затем решать - повторить его или дальше слать, или отмена. То по какому принципу делать? Использовать прерывания или писать тупо очередь в функции с ожиданием(типа отправил, таймаут, потом проверил не приходило ли чего, потом дальше. Но может я параноик, но мне кажется что в таком случае возможны пропуски пакетов)
А с прерываниями как-то оч сложно представляется, нужно очень много флагов разных... )))
Палка о двух концах...

А в современном мире как такие вещи делаются?

Что посоветуете?

Делюсь собственным опытом/мнением. Использую систему команда - статус, запрос - ответ. Обе стороны имеют тайм-аут, по-которому переходят в другой режим работы. Например, послана команда усановить какую-то величину на каком-то выходе. В ответ передатчику посылается статус приемника как подтверждение приема. Скорее всего, значениеуказанного выхода уже включено в статус устройства. Если нет, то посылается отдельный запрос на чтение данного значения. Про тайм-ауты я уже упоминал. Это все, наверное, очень просто и слишком в общем виде, ну так проработка деталей - Ваша работа. Данная методология отлично себя зарекомендовала на множестве проектов, в том числе и с коммуникацией по CAN с наличием более сотни устройств на одной шине и, соответственно, с коллизиями и потерями пакетов по различным причинам, которые необходимо анализировать и принимать меры. Запомните, потери неизбежны, а вот фиксирование таких потерь и устойчивость системы к ним - это уже другая история.

Успехов.

Спасибо!

А какого рода данные транспортируются? Если они эфемерны, и имеют значение только в пределах одного цикла работы системы, то, возможно их лучше вообще не квитировать, чтобы магистраль ерундой не засорять, в следующем цикле все равно будут отправлены более свежие. Если их потеря приводит к стойкому ухудшению характеристик системы или аварии/неработоспособности - нужно делать все возможное для их доставки, возможно даже предусматривать резервный канал/способ. Это ж все спецификой задачи определяется )

А кто как не разработчик должен это определять?! Не надо смешивать доставку данных с их содержанием.

Вопрос встречный: насколько больших? Мегабайты? Терабайты?