CANOPEN драйвер

[Rine]

Здравствуйте! Да, мы используем Ваш can драйвер. При подаче питания мы видим heartbeat посылку с данными 127, потом в данных 5(operational). Так и должно быть(при подачи питания приходит посылка с данными 127)?

[Лашкевич Максим]

Так и должно быть.

[aeu!]

Добрый день!
Столкнулся с проблемой. В новой партии плат на 1921ВК028 (схема близка к MotorControlBoard3) поставили кварц 16 МГц вместо 12 МГц.
Присвоил OSECLK_VAL соответствующее значение. Все работает, кроме прошивки из UniCON.
При запуске прошивки получаю сообщение "Ошибка получения ответа VERSION. dll недоступна."
На плате, изготовленной в 2020 году по той же документации, но с кварцем 12 МГц прошивка из UniCON идет нормально.

[Disona]

Добрый день!
Столкнулся с проблемой. В новой партии плат на 1921ВК028 (схема близка к MotorControlBoard3) поставили кварц 16 МГц вместо 12 МГц.
Присвоил OSECLK_VAL соответствующее значение. Все работает, кроме прошивки из UniCON.
При запуске прошивки получаю сообщение "Ошибка получения ответа VERSION. dll недоступна."
На плате, изготовленной в 2020 году по той же документации, но с кварцем 12 МГц прошивка из UniCON идет нормально.

Добрый день.

Это связано с тем, что при переходе в режим прошивки по CAN, настройки тактирования в контроллере перенастраиваются, и делается это исходя из предположения, что стоит 12 МГц кварц.

Мы постараемся сделать для вас прошивальщик под 16 МГц в ближайшее время.

Не подскажете, какие вы значения делителей для PLL используете, чтобы получить 100 МГц?

[Disona]

Добрый день!
Столкнулся с проблемой. В новой партии плат на 1921ВК028 (схема близка к MotorControlBoard3) поставили кварц 16 МГц вместо 12 МГц.
Присвоил OSECLK_VAL соответствующее значение. Все работает, кроме прошивки из UniCON.
При запуске прошивки получаю сообщение "Ошибка получения ответа VERSION. dll недоступна."
На плате, изготовленной в 2020 году по той же документации, но с кварцем 12 МГц прошивка из UniCON идет нормально.

Вот, попробуйте использовать вот этот файл:

X_CANFlashProgDataM4F_1921VK028_16MHz.zip

(17.42 КБ) 98 скачиваний

Вам нужно будет заменить файл "Vsrc/X_CANFlashProgDataM4F_1921VK028.c" на файл из архива.
Единственная проблема, у нас не на чем его проверить, поэтому не могу гарантировать на 100%, что всё получится.
И хорошо, если есть возможность прошить контроллер через JTAG на всякий случай

Ждём обратную связь.

[aeu!]

Добрый день!
Огромное спасибо за помощь! Новый прошивальщик работает на плате с кварцем 16 МГц.

[Rine]

Здравствуйте, сколько используется буферов на отправку и приём в can драйвере на 1921вк01т? Возможна ли такая ситуация - если были запросы на чтение , а контроллер не успел ответить , тк can сеть забита на 100%(буферы на отправку забились, тк ответить нет возможности из-за загрузки can сети) , и вдруг приходит команда стоп, дойдёт ли эта команда, если буферы на отправку все заняты у микроконтроллера

[Disona]

Здравствуйте, сколько используется буферов на отправку и приём в can драйвере на 1921вк01т? Возможна ли такая ситуация - если были запросы на чтение , а контроллер не успел ответить , тк can сеть забита на 100%(буферы на отправку забились, тк ответить нет возможности из-за загрузки can сети) , и вдруг приходит команда стоп, дойдёт ли эта команда, если буферы на отправку все заняты у микроконтроллера

Добрый день.

В сети CAN отправка сообщений определяется идентификатором сообщения - чем ниже идентификатор, тем выше приоритет. Сообщение с более высоким приоритетом всегда выиграет арбитраж и будет отправлено первым. В драйвере CANopen есть куча разных сервисов (SDO, PDO, Heartbeat и т.д.). Каждый сервис характеризуется своим диапазоном идентификаторов CAN сообщений и, соответственно, сервисы имеют разные приоритеты. Всего драйвер использует для своих сервисов на отправку и прием 32 мэйлбокса (буфера, применительно к вашему вопросу).

Из вашего вопроса непонятно что за запросы на чтение, что за команда стоп и кем они посылаются. Если речь идет про взаимодействие нашего контроллера с программой UniCON, то это взаимодействие строится на базе сервиса SDO. Этот сервис устроен так, что ответ на запрос всегда имеет больший приоритет, чем приоритет запроса. Поэтому ситуация, когда ответы "копятся" и не отправляются из-за вновь отправляемых запросов на чтение невозможна. Тем не менее, следует учитывать, что сам по себе сервис SDO далеко не самый приоритетный. Если какой-то более приоритетный сервис (например PDO) забивает линию на 100%, то сервис SDO, имея более низкий приоритет, действительно не сможет пробиться - в этом случае и запросы и ответы будут ждать, когда линия освободится. Также не будут функционировать все остальные сервисы, имеющие приоритет ниже, чем у сервиса PDO.

P.S.:
Сама ситуация, что линия CAN загружена на 100% неправильная. Такая линия уже не может считаться линией реального времени, так как не гарантирует доставку сообщений за установленное время. Такую ситуацию лучше не допускать. Нормальным считается загружать линию CAN процентов на 50-60, что гарантирует, что все сообщения (даже имеющие низкий приоритет) будут отправлены. Если загрузка выше, то логично подумать об увеличении скорости обмена.

[Rine]

Я имею ввиду какую ситуацию- блоку приходят запросы от верхнего уровня, ответить он не успевает, буферы заполняются сообщениями на ответ(но отправки нет, тк линия занята), что с приёмом в этой ситуации(может ли контроллер принимать посылки в такой ситуации, если он заполнил буферы на ответ и ждёт когда сеть разгрузится, чтоб отвечать)? Буферы на отправку и приём общие или они разделены?
Или перефразирую так - при заполненных буферах на ответ, сможет ли контроллер читать сообщения в линии , если 32 буфера общие и они заполнены сообщениями на отправку, то пакеты в линии прочитать невозможно, или все же буферы на приём и передачу разделены?

[Disona]

Я имею ввиду какую ситуацию- блоку приходят запросы от верхнего уровня, ответить он не успевает, буферы заполняются сообщениями на ответ(но отправки нет, тк линия занята), что с приёмом в этой ситуации(может ли контроллер принимать посылки в такой ситуации, если он заполнил буферы на ответ и ждёт когда сеть разгрузится, чтоб отвечать)? Буферы на отправку и приём общие или они разделены?
Или перефразирую так - при заполненных буферах на ответ, сможет ли контроллер читать сообщения в линии , если 32 буфера общие и они заполнены сообщениями на отправку, то пакеты в линии прочитать невозможно, или все же буферы на приём и передачу разделены?

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

Чтобы ответить детально нужно больше информации.
Не могли бы вы предоставить больше конкретики?
В рамках какого сервиса верхний уровень шлет запросы (какой идентификатор у CAN сообщений от верхнего уровня)?
Каким образом контроллер отвечает (какой сервис, какой идентификатор)?