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

[Artemizus]

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

[редактор]

Если сообщение принято (нет ошибок) тогда можно считать ID. Иначе зачем вообще такой модкль

[Artemizus]

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

[редактор]

я делал так

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

  
  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]

Наивный вопрос по КАНу в 1921ВК035. Согласно РП_1921ВК035_201219.pdf в таблице 2.1 указаны выводы для двух КАНов 0 и 1. По факту КАН скорее один (к вопросу о качестве документации). Какой из них использовать (0 или 1)? Скорее 0, а что тогда на ногах первого (кроме функций порта)? Ни перефирийной библиотеки на КАН, ни примеров ждать не стоит?

[dav]

Наивный вопрос по КАНу в 1921ВК035. Согласно РП_1921ВК035_201219.pdf в таблице 2.1 указаны выводы для двух КАНов 0 и 1. По факту КАН скорее один (к вопросу о качестве документации). Какой из них использовать (0 или 1)? Скорее 0, а что тогда на ногах первого (кроме функций порта)? Ни перефирийной библиотеки на КАН, ни примеров ждать не стоит?

Доброго времени суток!
В микроконтроллере 1921ВК035 один модуль CAN с двумя узлами. Каждый узел работает не зависимо от другого и использует различные объекты сообщений.

[smispp]

Подскажите, а есть ли работающий порт FreeRTOS на данный микроконтроллер? И будет ли работать вот этот
FreeRTOS-Kernel/portable/RVDS/арм_CM4F/

[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__]

Наивный вопрос по КАНу в 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)

[__Max__]

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