Перейти к содержанию
    

STM32 & ISO-TP стратегия

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

 

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

 

Приглянулась реализация ISO-TP но исходников нема.

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

 

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

А с прерываниями как-то оч сложно представляется, нужно очень много флагов разных... )))

Палка о двух концах...

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Успехов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А какого рода данные транспортируются?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...