sergeyklenov 0 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба Здравствуйте коллеги, хочу спросить совета у повидавших виды: стоит задача реализации отправки-приема больших пакетов по CAN. Приглянулась реализация ISO-TP но исходников нема. На сайте Техаса предлагают некую контору, которая продает такие исходники за $17500, на гитхабе какие-то недоделки ужасные покопал и понял, что лучше писать самому. Тут возник вопрос, коли отправляя пакет, нужно ждать подтверждения и затем решать - повторить его или дальше слать, или отмена. То по какому принципу делать? Использовать прерывания или писать тупо очередь в функции с ожиданием(типа отправил, таймаут, потом проверил не приходило ли чего, потом дальше. Но может я параноик, но мне кажется что в таком случае возможны пропуски пакетов) А с прерываниями как-то оч сложно представляется, нужно очень много флагов разных... ))) Палка о двух концах... А в современном мире как такие вещи делаются? Что посоветуете? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
let's see 0 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба Что посоветуете? Делюсь собственным опытом/мнением. Использую систему команда - статус, запрос - ответ. Обе стороны имеют тайм-аут, по-которому переходят в другой режим работы. Например, послана команда усановить какую-то величину на каком-то выходе. В ответ передатчику посылается статус приемника как подтверждение приема. Скорее всего, значениеуказанного выхода уже включено в статус устройства. Если нет, то посылается отдельный запрос на чтение данного значения. Про тайм-ауты я уже упоминал. Это все, наверное, очень просто и слишком в общем виде, ну так проработка деталей - Ваша работа. Данная методология отлично себя зарекомендовала на множестве проектов, в том числе и с коммуникацией по CAN с наличием более сотни устройств на одной шине и, соответственно, с коллизиями и потерями пакетов по различным причинам, которые необходимо анализировать и принимать меры. Запомните, потери неизбежны, а вот фиксирование таких потерь и устойчивость системы к ним - это уже другая история. Успехов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sergeyklenov 0 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба Делюсь собственным опытом/мнением... Спасибо! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dii# 0 16 мая, 2018 Опубликовано 16 мая, 2018 · Жалоба А какого рода данные транспортируются? Если они эфемерны, и имеют значение только в пределах одного цикла работы системы, то, возможно их лучше вообще не квитировать, чтобы магистраль ерундой не засорять, в следующем цикле все равно будут отправлены более свежие. Если их потеря приводит к стойкому ухудшению характеристик системы или аварии/неработоспособности - нужно делать все возможное для их доставки, возможно даже предусматривать резервный канал/способ. Это ж все спецификой задачи определяется ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
let's see 0 17 мая, 2018 Опубликовано 17 мая, 2018 · Жалоба А какого рода данные транспортируются? А кто как не разработчик должен это определять?! Не надо смешивать доставку данных с их содержанием. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alechek 0 18 мая, 2018 Опубликовано 18 мая, 2018 · Жалоба хочу спросить совета у повидавших виды: стоит задача реализации отправки-приема больших пакетов по CAN. Вопрос встречный: насколько больших? Мегабайты? Терабайты? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться