Jump to content

    

пару вопросов про CAN

Recommended Posts

go2winner

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

 

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

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

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

...

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

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

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

Edited by yuravg

Share this post


Link to post
Share on other sites

syoma

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

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

 

Share this post


Link to post
Share on other sites

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

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

 

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

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

Edited by go2winner

Share this post


Link to post
Share on other sites

RoadRunner

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

 

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

 

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

 

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

 

 

Edited by RoadRunner

Share this post


Link to post
Share on other sites

AlexRayne

Пове

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

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

 

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

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

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

Edited by AlexRayne

Share this post


Link to post
Share on other sites

RoadRunner
Just now, AlexRayne said:

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

RoadRunner
37 minutes ago, AlexRayne said:

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

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

 

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

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

 

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

 

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

Edited by RoadRunner

Share this post


Link to post
Share on other sites

AlexRayne

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

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

 

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

Share this post


Link to post
Share on other sites

RoadRunner
1 hour ago, AlexRayne said:

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

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

 

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

 

1 hour ago, AlexRayne said:

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

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

Edited by RoadRunner

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

RoadRunner

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.