[adnega 10]

34 минуты назад, haker_fox сказал:

@esaulenka, @PeterAwsmtek, спасибо! А то сейчас используем RS-485. И многие вещи приходится делать ручками, но зато привычно и годами откатано. А за CAN браться боязно, ибо: нет опыта, пугает мультимастер и т.п.

Мультимастер должен не пугать, а привлекать. Меня в CAN больше всего напрягает максимальный размер пакета в 8 байт - чтобы передать что-то длиннее нужно придумывать какой-то транспорт.

[PeterAwsmtek 0]

40 minutes ago, haker_fox said:

спасибо! А то сейчас используем RS-485. И многие вещи приходится делать ручками, но зато привычно и годами откатано. А за CAN браться боязно, ибо: нет опыта, пугает мультимастер и т.п.

Страх перед изменениями - враг инженера. Выделите время под эксперименты, обкатайте все на отладке, а когда будете уверены - меняйте свою основную продукцию.

5 minutes ago, adnega said:

Меня в CAN больше всего напрягает максимальный размер пакета в 8 байт - чтобы передать что-то длиннее нужно придумывать какой-то транспорт.

Для этого есть стек протоколов CANopen. В нем успешно решается большинство проблем.

В базовой версии мне нравится смотреть на CAN как на систему Pub/Sub. Ибо ID CAN это не совсем те адреса, как в Modbus например.

[jcxz 184]

2 часа назад, Ioann_II сказал:

пока что нигде этой конкретики не встречал. В т.ч. в указанном Вами источнике.

Странно, а я смог прочитать "в указанном мной источнике":

 

"При свободной шине любой узел может начинать передачу в любой момент. В случае одновременной передачи кадров двумя и более узлами проходит арбитраж доступа: передавая идентификатор, узел одновременно проверяет состояние шины. Если при передаче рецессивного бита принимается доминантный — считается, что другой узел передаёт сообщение с большим приоритетом, и передача откладывается до освобождения шины. Таким образом, в отличие, например, от Ethernet в CAN не происходит непроизводительной потери пропускной способности канала при коллизиях. Цена этого решения — возможность того, что сообщения с низким приоритетом никогда не будут переданы".

 

Что означает, что: В начале CAN-кадра, каждый узел, желающий передать кадр в шину, начинает передачу своего адреса назначения (каждый узел передаёт свой адрес назначения). И одновременно с передачей каждый передающий узел также и принимает биты с шины, для контроля. И как только видит, что передаваемое им рецессивное значение бита не соответствует читаемому с шины значению бита (значит кто-то в данный момент выставил для этого бита доминантное значение) - то такой узел прекращает передачу. Это называется: "Данный узел проиграл арбитраж". Дальше этот узел-передатчик только принимает оставшийся хвост кадра. Чтобы увидеть его конец, выдержать паузу, и заново повторить попытку передачи. Выигрывает арбитраж тот передатчик, у которого среди первых бит адреса идёт больше доминантных бит (т.е. - у которого адрес назначения - минимальный из всех пытающихся передать). У такого узла во всех битах адреса будет совпадать выставляемое им значение на шину с читаемым.

Это легко представить по аналогии если бы все передатчики имели выход ОК (открытый коллектор) и доминантное состояние == лог.0. Т.е. -каждый ставит очередной свой бит, и если среди них есть лог.0 - тот и выиграет. И одновременно каждый передатчик читает каждый бит, и как только видит проигрыш в очередном бите - прекращает передачу.

Никаких ретрансмиссий тут не надо. Зачем они? Ведь пока передатчик не выиграл арбитраж, он не стартует передачу кадра. А значит и повторять нечего.

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

1 час назад, esaulenka сказал:

1) Да. Потеря арбитража - совершенно штатное явление в сколь-нибудь нагруженной шине.

А что такое "потеря арбитража" в CAN? Не знаю такого понятия. Есть понятия "выигрыш арбитража для данного кадра" или "проигрыш арбитража для данного кадра". Если узел выиграл арбитраж, разве он может его потом потерять? В каких случаях? А если проиграл арбитраж - так значит он его и не получил для данного кадра. О какой тогда потере может идти речь?

"Потеря" - это разве что сам факт проигрыша....

Ну или возможно что если в процессе передачи, узел поймает помеху и какое-то из рецессивных состояний бит передаваемых им, заменится на доминантное из-за помехи - может это потеря арбитража?

1 час назад, haker_fox сказал:

Можно попутный вопрос: как исключить ситуацию полной потери данных в какой-либо системе от критичного датчика? Только грамотным проектированием, распределением приоритетов и мониторингом шины? Или есть ещё какие-то аппаратные фишечки для этого?

В CAN каждый передающий узел одновременно и принимает этот же самый кадр (для контроля). Кроме того он принимает ACK в конце кадра (если есть хоть один приёмник на линии). Т.е. - он в любой момент знает - принялись данные удалённой стороной или нет. Как он может эти данные потерять?

[PeterAwsmtek 0]

12 minutes ago, jcxz said:

у или возможно что если в процессе передачи, узел поймает помеху и какое-то из рецессивных состояний бит передаваемых им, заменится на доминантное из-за помехи - может это потеря арбитража?

Это не потеря, это сбой в передаче, и на этот случай есть контрольная сумма кадра.

А вообще вы цепляетесь к словам. Все поняли что имелось ввиду.

[jcxz 184]

1 час назад, PeterAwsmtek сказал:

Если у вас детерминированное время передачи данных, то обеспечте только один передатчик на шине, тогда никто не будет мешать и никакие данные не потеряются.

Достаточно правильно спланировать бюджет линии (посчитать сколько бит в заданный интервал времени можно передать на заданной скорости). Так чтобы его заведомо хватало всегда. И не передавать нескольким узлам одновременно на один и тот же адрес.

13 минут назад, PeterAwsmtek сказал:

А вообще вы цепляетесь к словам. Все поняли что имелось ввиду.

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

1 час назад, haker_fox сказал:

пугает мультимастер и т.п

А что в нём страшного? Это же аппаратно организуется. Со стороны ПО ничего как раз делать не надо.

40 минут назад, adnega сказал:

Меня в CAN больше всего напрягает максимальный размер пакета в 8 байт - чтобы передать что-то длиннее нужно придумывать какой-то транспорт.

Можно пропихнуть чуть больше. Если вспомнить про запасные 18 бит адреса. И выставить соответствующим образом фильтрацию на приём. Получится в сумме = 98 полезных бит  

[PeterAwsmtek 0]

8 minutes ago, jcxz said:

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

Я думаю он имел ввиду именно проигрыш арбитража. С повторной передачей как следствие. Ну да ладно.

 

9 minutes ago, jcxz said:

Достаточно правильно спланировать бюджет линии (посчитать сколько бит в заданный интервал времени можно передать на заданной скорости). Так чтобы его заведомо хватало всегда. И не передавать нескольким узлам одновременно на один и тот же адрес.

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

[jcxz 184]

10 минут назад, PeterAwsmtek сказал:

Я думаю он имел ввиду именно проигрыш арбитража. С повторной передачей как следствие. Ну да ладно.

Так нет повторной. Пока узел не выиграл - он ничего не передаёт. А значит и повторов не надо.

[PeterAwsmtek 0]

1 hour ago, jcxz said:

Пока узел не выиграл - он ничего не передаёт.

Арбитраж шины это часть передачи. Это начало передачи. Кто выиграл, тот ее продолжает, а кто проиграл - прекращает.

Вот в случае проигрыша - есть повторная попытка или нет?

Насколько я знаю сообщение остается в мэйлбоксе. И должно само отправиться, когда шина освободится (если не произойдет еще одна коллизия и арбитраж снова не будет проигран).

[jcxz 184]

2 часа назад, PeterAwsmtek сказал:

Вот в случае проигрыша - есть повторная попытка или нет?

Конечно - как только закончится передача текущего фрейма и пройдёт межфреймовая пауза - будут пытаться выиграть следующий фрейм те, кому надо передавать.

Я писал об этом выше.

[PeterAwsmtek 0]

48 minutes ago, jcxz said:

Конечно - как только закончится передача текущего фрейма и пройдёт межфреймовая пауза - будут пытаться выиграть следующий фрейм те, кому надо передавать.

Это мы и называем повтором передачи )

[yes 5]

9 hours ago, haker_fox said:

Можно попутный вопрос: как исключить ситуацию полной потери данных в какой-либо системе от критичного датчика? Только грамотным проектированием, распределением приоритетов и мониторингом шины? Или есть ещё какие-то аппаратные фишечки для этого?

ну так если какой-либо узел (любой, не обязательно приемник, он и не известен на этом уровне, единственно, что этот узел не отрубился из-за своих error counter-ов) не поймал правильного сообщения (ошибка и т.п.), то он дает error frame и передатчик должен повторить

 

[Ioann_II 0]

20 часов назад, jcxz сказал:

Странно, а я смог прочитать "в указанном мной источнике":

Как функционирует сам арбитраж мне вполне ясно. Но вопрос заключался в "сделает повторную попытку только при автоматической ретрансмиссии?". Этот момент в источнике не освещён. PeterAwsmtek ответил "Да". Вы пишите, что и без автоматических ретрансмиссий отправится при освобождении шины.

Т.е. ретрансмисси предназначены не для случаев проигрыша арбитража, а для случаев искажения данных? Или ещё для каких-то случаев?

[Arlleex 131]

В CAN реализован метод не деструктивного арбитража. И, вроде как, на самом деле арбитраж происходит по всему сообщению CAN, а не только по идентификатору.

Повторные передачи входят составной частью протокола CAN как такового: в случае обнаружения ошибки передачи или приема, узел будет пытаться осуществить повторную транзакцию.

Конкретная реализация зависит от железа: в большинстве МК есть биты управления авторетрансмиссиями. По-хорошему, она должна быть всегда включена для соответствия спецификации Bosh.

На практике же делают по-разному с учетом первостепенности передаваемых данных.

 

haker_fox, попробуйте CAN - это очень удобная шина. Очень много вопросов костыльно-велосипедного способа изобретения очередного протокола обмена отпадают сами собой. Для себя отметил пока один недостаток - в CAN (не FD) максимальный пэйлоад 8 байт, что как бы не густо. Но тут можно прибегнуть к CANOpen (например, прикрутив стек CAN Festival).

 

14 минут назад, Ioann_II сказал:

Т.е. ретрансмисси предназначены не для случаев проигрыша арбитража, а для случаев искажения данных? Или ещё для каких-то случаев?

Да. Потеря арбитража это не ошибочная ситуация, а вполне корректная.

[jcxz 184]

16 минут назад, Arlleex сказал:

В CAN реализован метод не деструктивного арбитража. И, вроде как, на самом деле арбитраж происходит по всему сообщению CAN, а не только по идентификатору.

Вполне возможно. Но я не видел документов однозначно это подтверждающих.

Цитата

Конкретная реализация зависит от железа: в большинстве МК есть биты управления авторетрансмиссиями. По-хорошему, она должна быть всегда включена для соответствия спецификации Bosh.

Не обязательно. Зависит от протокола прикладного уровня (поверх CAN).

Вот я сейчас обдумываю протокол обзора сети устройств на шине, адреса которых заранее не известны. И как раз думаю использовать возможность однократной отправки только одного кадра для случая если несколько устройств хотят передать на один адрес. Чтобы отправился только один кадр из всех пытающихся.

30 минут назад, Ioann_II сказал:

Т.е. ретрансмисси предназначены не для случаев проигрыша арбитража, а для случаев искажения данных? Или ещё для каких-то случаев?

Они предназначены (имхо) для случаев, когда передающий узел не получил ACK на свой переданный кадр ни от одного из устройств на шине. Искажения входят в число этих случаев. Но не только они.

[haker_fox 60]

17 minutes ago, Arlleex said:

haker_fox, попробуйте CAN - это очень удобная шина.

Обязательно) С каждым разом у меня всё меньше и меньше сомнений остаётся) Видимо, уже давно пора.