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

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

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

 

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

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

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

 

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

 

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

 

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

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


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

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

...

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

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

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

Изменено пользователем yuravg

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


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

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

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

 

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


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

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

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

 

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

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

Изменено пользователем go2winner

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


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

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

 

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

 

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

 

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

 

 

Изменено пользователем RoadRunner

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


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

Пове

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

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

 

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

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

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

Изменено пользователем AlexRayne

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


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

Just now, AlexRayne said:

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

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

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

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

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


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

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

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

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

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

 

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

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


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

37 minutes ago, AlexRayne said:

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

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

 

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

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

 

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

 

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

Изменено пользователем RoadRunner

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


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

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

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

 

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

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


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

1 hour ago, AlexRayne said:

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

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

 

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

 

1 hour ago, AlexRayne said:

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

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

Изменено пользователем RoadRunner

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


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

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

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


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

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

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

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

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


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

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

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


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

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

 

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


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

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

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

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

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

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

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

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

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