1921DR035 CAN ID принимаемого сообщения

32-разрядные микроконтроллеры разработки АО "НИИЭТ"

Модераторы: ea, dav, bkolbov, Alis, pip, _sva_

Artemizus
Сообщения: 2
Зарегистрирован: 19 авг 2022, 07:50
Предприятие: РЕЛЕРО

1921DR035 CAN ID принимаемого сообщения

Сообщение Artemizus »

Здравствуйте. Существует ли способ узнать идентификатор принимаемого сообщения по CAN? В старом устройстве есть завязка на него, хотелось бы иметь совместимость.
редактор
Сообщения: 27
Зарегистрирован: 08 ноя 2016, 09:10

Re: 1921DR035 CAN ID принимаемого сообщения

Сообщение редактор »

Если сообщение принято (нет ошибок) тогда можно считать ID. Иначе зачем вообще такой модкль :lol:
Artemizus
Сообщения: 2
Зарегистрирован: 19 авг 2022, 07:50
Предприятие: РЕЛЕРО

Re: 1921DR035 CAN ID принимаемого сообщения

Сообщение Artemizus »

А в каком регистре его можно увидеть? MOAR - исходящий, MOAMR - маска. Единственной возможностью я вижу через шлюз прокинуть ID на другой объект сообщения и там считать с MOAR. Кстати, это получилось, но возникли другие сложности.
редактор
Сообщения: 27
Зарегистрирован: 08 ноя 2016, 09:10

Re: 1921DR035 CAN ID принимаемого сообщения

Сообщение редактор »

я делал так

Код: Выделить всё

  
  data = (int*)(Msg.DataBuf);
  data[0] = cur_msg->MODATAL;
  data[1] = cur_msg->MODATAH;
  Msg.Flags = cur_msg->MOFCR_bit.DLC; // количество байт данных
  if (cur_msg->MOAR_bit.IDE) // расширенное сообщение
    { Msg.CanID = cur_msg->MOAR_bit.ID;
      Msg.Flags |= canEXT_MSG; 
     }
  else // принято стандартное сообщение
    { Msg.CanID = (cur_msg->MOAR_bit.ID >> 18);
     }
  cur_msg->MOCTR = (1<<CANMSG_Msg_MOCTR_RESRXPND_Pos) | // RXPND = 0;
                                (1<<CANMSG_Msg_MOCTR_RESNEWDAT_Pos); // NEWDAT = 0;
но это было в рамках тестов, в реальных проектах не использовали.
smispp
Сообщения: 15
Зарегистрирован: 28 ноя 2022, 10:30
Предприятие: оао нпк спп

Re: 1921DR035 CAN ID принимаемого сообщения

Сообщение smispp »

Наивный вопрос по КАНу в 1921ВК035. Согласно РП_1921ВК035_201219.pdf в таблице 2.1 указаны выводы для двух КАНов 0 и 1. По факту КАН скорее один (к вопросу о качестве документации). Какой из них использовать (0 или 1)? Скорее 0, а что тогда на ногах первого (кроме функций порта)? Ни перефирийной библиотеки на КАН, ни примеров ждать не стоит?
dav
Сообщения: 209
Зарегистрирован: 14 дек 2015, 09:21
Предприятие: АО НИИЭТ
Откуда: АО НИИЭТ, Воронеж

Re: 1921DR035 CAN ID принимаемого сообщения

Сообщение dav »

smispp писал(а): 20 дек 2022, 10:41 Наивный вопрос по КАНу в 1921ВК035. Согласно РП_1921ВК035_201219.pdf в таблице 2.1 указаны выводы для двух КАНов 0 и 1. По факту КАН скорее один (к вопросу о качестве документации). Какой из них использовать (0 или 1)? Скорее 0, а что тогда на ногах первого (кроме функций порта)? Ни перефирийной библиотеки на КАН, ни примеров ждать не стоит?
Доброго времени суток!
В микроконтроллере 1921ВК035 один модуль CAN с двумя узлами. Каждый узел работает не зависимо от другого и использует различные объекты сообщений.
smispp
Сообщения: 15
Зарегистрирован: 28 ноя 2022, 10:30
Предприятие: оао нпк спп

Re: 1921DR035 CAN ID принимаемого сообщения

Сообщение smispp »

Подскажите, а есть ли работающий порт FreeRTOS на данный микроконтроллер? И будет ли работать вот этот
FreeRTOS-Kernel/portable/RVDS/арм_CM4F/
smispp
Сообщения: 15
Зарегистрирован: 28 ноя 2022, 10:30
Предприятие: оао нпк спп

Re: 1921DR035 CAN ID принимаемого сообщения

Сообщение smispp »

Помогите. Может найдется, кто ответит на следующие вопросы.

1. Настроил N ящиков (объектов сообщения) на прием и M ящиков на передачу с общим прерыванием. Как в прерывании определить какой ящик вызвал прерывание?
Не перебирать же все ящики в прерывании на предмет NewDat.

2. Может кто объяснит этот текст стр 155 (ошибки техписателя?)
Состояние регистров объекта сообщения, передающего сообщение удаленного запроса
"У объекта сообщения, передающего сообщение удаленного запроса,
в регистре MOSTAT(??? может MOCTR) должен быть сброшен(???) бит DIR (объект передает сообщение данных ???)
и установлены биты TXEN0, TXEN1, MSGVAL и TXRQ. Значение идентификатора в регистре MOAR передающего объекта сообщения
должно быть равно значению идентификатора принимающего объекта сообщения
(или совместно с регистром MOAMR обеспечивать успешное прохождение фильтрации),
чтобы сообщение удаленного запроса было принято принимающим объектом другого узла.
Само сообщение удаленного запроса должно содержать идентификатор принимающего объекта сообщения,
поэтому значение регистра MODATAL(??? При чем тут MODATAL) передающего объекта сообщения должно быть равно
значению регистра MOAR принимающего объекта."

3. стр153. "Флаги RXUPD и NEWDAT позволяют произвести чтение корректных данных из объекта сообщения
во время текущих операций контроллера CAN.
Рекомендуемая последовательность действий следующая:
- сброс флага NEWDAT;
- чтение данных (идентификатор, данные и т. д.) из объекта сообщения;
- проверка флагов NEWDAT и RXUPD – оба флага должны быть сброшены.
В случае невыполнения этого условия – возвращение к первому действию;
- если флаги NEWDAT и RXUPD сброшены, то содержимое объекта сообщения корректно
и не используется контроллером CAN в течение операции чтения.
Поведение флагов RXUPD, NEWDAT и MSGLST идентично как для сообщений данных,
так и для сообщений удаленных запросов."

Странная логика. Видим установленный NEWDAT, сбрасываем его,
читаем данные пишем их куда-то, проверяем NEWDAT и RXUPD,
если сброшены, то хорошо, а если нет то крутимся в прерывании, как долго и что это было???
А в это время не корректные данные уже переписаны по назначению!!!
__Max__
Сообщения: 10
Зарегистрирован: 01 ноя 2022, 22:49
Предприятие: Cyberdyne Systems

Re: 1921DR035 CAN ID принимаемого сообщения

Сообщение __Max__ »

smispp писал(а): 20 дек 2022, 10:41 Наивный вопрос по КАНу в 1921ВК035. Согласно РП_1921ВК035_201219.pdf в таблице 2.1 указаны выводы для двух КАНов 0 и 1. По факту КАН скорее один (к вопросу о качестве документации). Какой из них использовать (0 или 1)? Скорее 0, а что тогда на ногах первого (кроме функций порта)? Ни перефирийной библиотеки на КАН, ни примеров ждать не стоит?
Потому что библиотека и документация уже существуют давно =) ... Как я понял это Infineon XMC4000 MultiCAN/TwinCAN:
оригинальные документы:
https://www.infineon.com/cms/en/product ... f8b7bc6d13

https://www.infineon.com/dgdl/Infineon- ... 1d6be32110
https://www.infineon.com/dgdl/Infineon- ... 80fa1c226b

https://www.infineon.com/dgdl/Infineon- ... 49fb915be3
https://www.infineon.com/dgdl/Infineon- ... e8f66b5e19

оригинальная библиотека:
https://www.keil.com/dd2/pack/ - Infineon.XMC4000_DFP.2.14.0.pack (Infineon XMC4000 Series Device Support, Drivers and Examples)
после установки пака -
библиотека - C:\Keil_v5\арм\Packs\Infineon\XMC4000_DFP\2.14.0\Device\XMClib - в src и inc - xmc_can,
примеры - C:\Keil_v5\арм\Packs\Infineon\XMC4000_DFP\2.14.0\Device\XMClib\examples\XMC4500_series\CAN.

Во вложении два файла, переделанные для 1921ВК035, настройка выводов CAN и шинного тактирования/сброса модуля CAN делать отдельно. На плате 1921ВК01Т (если поменять название модуля, регистров и масок) работали пример передачи и внутренней петли с прерыванием.

В переделанных файлах добавлена функция прямого указания частоты тактирования CAN_InitReg () вместо связки автоподбора
/*Configure CAN Module*/
XMC_CAN_Init(CAN, CAN_FREQUENCY);
/*Configure CAN Node baudrate*/
XMC_CAN_NODE_NominalBitTimeConfigure(CAN_NODE2, &baud);, а также переделаны всякие дефайны MultiCanPlus и добавлен SystemCoreClockUpdate, где необходимо.

По поводу RXUPD и NEWDAT - в библиотеке Infineon используется блокирующий приём данных do-while, как и в руководстве на 1921ВК035...imho может приводить к зацикливанию основной программы, если постоянно будет приходить фрейм. В переделанных файлах добавил неблокирующий приём (закомментированные функции) - может приводить к неприёму фрейма вообще. Как правильно делать, пока не нашёл ответ.....

По поводу двойного модуля (TwinCAN), imho надо вообще так определять:

#define CAN_BASE 0x40020000UL
#define CAN_NODE0_BASE 0x40020200UL
#define CAN_NODE1_BASE 0x40020300UL
#define CANMSG_BASE 0x40021000UL

#define CAN ((CAN_TypeDef *) CAN_BASE)
#define CAN_NODE0 ((_CAN_Node_TypeDef *) CAN_NODE0_BASE)
#define CAN_NODE1 ((_CAN_Node_TypeDef *) CAN_NODE1_BASE)
#define CANMSG ((CANMSG_TypeDef *) CANMSG_BASE)
Вложения
xmc_can.zip
(24.2 КБ) 53 скачивания
__Max__
Сообщения: 10
Зарегистрирован: 01 ноя 2022, 22:49
Предприятие: Cyberdyne Systems

Re: 1921DR035 CAN ID принимаемого сообщения

Сообщение __Max__ »

РефГайд тут https://www.keil.com/dd/docs/datashts/i ... 500_um.pdf - раздел 18 Controller Area Network Controller (MultiCAN), страница 1778.
Ответить

Вернуться в «32-разрядные микроконтроллеры»