[go2winner 0]

Доброго времени суток.

 

Есть несколько вопросов, которые я не понимаю. ( немного конкретики , я использую контроллер mcp2515. )

1) Кадр удаленного запроса. Каким образом работает?

В частности, как происходит ответ на него? Контроллер сам отправляет содержимое буфера при получении запроса? или я, в роли управляющего звена, должен среагировать на флаг RTR и инициализировать запрос на передачу? (или зависит от контроллера? в описании mcp2515 ничего вроде не нашел по этому поводу, но знаю , что есть с автоответом )

 

Узел, который запрашивает данные (отправляет remote frame), в поле с идентификатором указывает идентификатор узла ,у которого хочет получить данные? Если да, то тогда узел, который отвечает на запрос заранее должен знать идентификатор куда отправить данные на запрос? Верно? А дальше всем узлам приходя данные и они в соответствии со своими настройками их принимают или нет.

 

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

 

Я имею общие представления о can (но пока хромаю ), если у Вас есть хорошие статьи или т.п. про can (настройка, обмен, и т.п.), приму с удовольствием.

[yuravg 0]

Доброго времени суток.

...

1) Вам самим надо инициализировать передачу. Бит rtr - это дополнительная информация о фрейме (Инициатор устанавливая rtr не передает данные)

2) Да. Надо знать какая у Вас будет сеть с протоколом. Если устройств много возможно удобней будет иметь один идентификатор для каждого устройства

(все идентификаторы например будут формироваться по правилу id11(стандартный идентификатор)=[тип_сообщения, id_source, id_recipient])

Изменено 8 июня, 2016 пользователем yuravg

[syoma 1]

По поводу 1) знаю, что у атмелов была когда-то такая фича, что если в буфере на отправление есть фрейм с таким же Id и он готов к посылке, то при получении такого же фрейма с RTR он будет отправлен автоматом.

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

 

[go2winner 0]

По поводу 1) знаю, что у атмелов была когда-то такая фича, что если в буфере на отправление есть фрейм с таким же Id и он готов к посылке, то при получении такого же фрейма с RTR он будет отправлен автоматом.

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

 

я тоже вот слышал краем уха, подумал может везде оно так (пока нигде этого не встречал в даташитах)

Теперь ситуация яснее стала. спасибо всем.

Изменено 8 июня, 2016 пользователем go2winner

[RoadRunner 0]

Всем доброго времени суток. 

 

Новую тему решил не создавать, попробую спросить тут.

 

Такой вопрос: как передатчик CAN определяет, когда можно передавать, а когда нет. Например, в шине CAN происходит обмен данными, кто-то что-то передает, и тут просыпается новый CAN-узел и решает что-нибудь послать. Что было до того, как он проснулся, он, ясен пень, не знает. Как он определит, что линия свободна и можно передавать?

 

Поделитесь соображениями. Спасибо.

 

 

Изменено 12 августа, 2020 пользователем RoadRunner

[AlexRayne 7]

Пове

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

Как он определит, что линия свободна и можно передавать?

 

поверьте, он это умеет. кан очень умный контроллер, иногда приходиться даже бороться с его интелектом, чтоб попроще было.

ваша забота - предоставить ему кадры с информацией. остальное его забота - как доставить. так он задуман.

да и не так легко усыпить ядро кана - то что у вас ядро проца в спячке, не значит что кан спит.

Изменено 12 августа, 2020 пользователем AlexRayne

[RoadRunner 0]

Just now, AlexRayne said:

поверьте, он это умеет. кан очень умный контроллер, иногда приходиться даже бороться с его интелектом, чтоб попроще было.

ваша забота - предоставить ему кадры с информацией.

да и не так легко усыпить ядро кана - то что у вас ядро проца в спячке, не значит что кан спит.

У меня задача - самому такой CAN-контроллер разработать, потому я и спрашиваю. Не просто ради любопытства.

[AlexRayne 7]

2 минуты назад, RoadRunner сказал:

самому такой CAN-контроллер разработать

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

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

 

Ну и стандарт то открытый, как вы его разработаете, не изучив стандарт? а там все написано - как запускается фрейм, детектируются коллизии и проч.

[RoadRunner 0]

37 minutes ago, AlexRayne said:

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

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

 

Ну и стандарт то открытый, как вы его разработаете, не изучив стандарт? а там все написано - как запускается фрейм, детектируются коллизии и проч.

Да я изучил, но вопросы остались.

 

Готовыми библиотеками я хз, как пользоваться, когда к ним нет доскональной документации и инструкции. Что я буду с этим кодом делать, когда он не заработает? Такого, чтобы прям "из коробки" работало, я не нашел.

 

З.Ы. Мне не обязательно реализовывать все прям до буквы как по стандарту. Основные вещи, чтобы просто корректно принимать и отправлять данные.

Изменено 12 августа, 2020 пользователем RoadRunner

[AlexRayne 7]

Если Вы на плис делаете - на опенкорах готовые ядра, открытые. Последнее что я видел -10к вннтилей занимало.

Если эмулируете на мк - это имхо нереальная задача, все ядро целиком надо положить под это - ибо отслеживать фронты, и подстраивать под них времянку - то еще удовольствие. Хотя на низких скоростях, проц помощнее потинет и это.

 

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

[RoadRunner 0]

1 hour ago, AlexRayne said:

Если Вы на плис делаете - на опенкорах готовые ядра, открытые. Последнее что я видел -10к вннтилей занимало.

На плис делаю. На опенкорах да, код есть, но документации к нему никакой. А если что-то не заработает, что мне с этим черным ящиком делать? Получается, как кота в мешке берешь, хоть и бесплатно.

 

Последний раз я оттуда брал TWI-ядро. Пришлось подправить в одном месте. Да, мелочь, но без этого не работало. Так это ладно TWI - он проще, да и исправление было очевидно - повезло. А если нет..

 

1 hour ago, AlexRayne said:

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

Вопрос в том, как определить, что идет передача пакета? Серию бит отслеживать без фронтов? Если да, то сколько бит? Вот это непонятно.

Изменено 12 августа, 2020 пользователем RoadRunner

[геннадий75 1]

Семь и более единиц подряд окончание пакета . Нулевой бит начало пакета ,дальше не забываем после 5 нулей или единиц про врезки потом подсчёт CRC  и бит подтверждения приёма другими узлами.

[RoadRunner 0]

18 hours ago, геннадий75 said:

Семь и более единиц подряд окончание пакета .

11 бит, судя по всему: ACK delimiter + EOF + Intermission. Или error/overload delimiter + intermission. Спасибо за подсказку.

[RoadRunner 0]

Народ, еще такой вопрос, может кто сможет помочь: при обнаружении ошибок в error frame посылается новый error frame? Если к примеру во время передачи error deliminer помехой или глючным передатчиком шину случайно на один-два бита утянет в доминантное состояние? Или при передаче active error flag на приеме обнаружится рецессивное состояние, т.е. bit error? Опять заново посылать error frame?

[геннадий75 1]

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