[jcxz 241]

4 минуты назад, x893 сказал:

В жизни есть протоколы (canopen/ isobus / ...), для коня в вакууме делайте как хотите.

Судя по сообщениям ТС, он изобретает свой велосипед. И ему все эти канопены с их проблемами - не указ.  

1 минуту назад, dimka76 сказал:

Заюзайте CAN-FD, а лучше CAN-XL

Вот уж точно - такое есть не в каждом МК. Тем более. Не то что FIFO.....

53 минуты назад, adnega сказал:

Можно часть ID выделить под счетчик (размером не менее числа mailbox на приемной стороне). Если протокол позволяет)

А ещё можно - часть ID под данные кадра. И тем - повысить плотность потока.  

Хотя степени двойки конечно уже не будет....

[dimka76 63]

On 7/22/2024 at 4:42 PM, jcxz said:

А ещё можно - часть ID под данные кадра. И тем - повысить плотность потока.  

Особенно, если Ext ID задействовать.

[x893 60]

Так как вопрос изначально был некорректным, то и дальнейшее обсуждение не имеет смысла.

[Arlleex 187]

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

А кто мешает?

В смысле кто? Отведенные 8 байтов максимум в кадре CAN.

Задействование других каких-то ID недопустимо.
 

20 минут назад, dimka76 сказал:

Заюзайте CAN-FD, а лучше CAN-XL

Не, FD не во всех железяках в наличии.

[jcxz 241]

49 минут назад, Arlleex сказал:

В смысле кто? Отведенные 8 байтов максимум в кадре CAN.

Задействование других каких-то ID недопустимо.

Так вы же вроде свой протокол ваяете? Почему тогда для передачи мультикадров выделили только один адрес (CAN-ID)? Почему не выделить например - 16 последовательных адресов?

 

Когда-то также пилил свой протокол поверх CAN. С передачей мультикадров. Просто выделил для него 16 последовательных адресов (CAN-ID). И передавал мультикадр так: вырезАл очередные <=8*15 байт данных (из передаваемого массива данных); пристыковывал к нему заголовок мультикадра (с необходимой инфой: индексом мультикадра в потоке, количеством кадров в мультикадре, CRC и т.п.). Затем нарезал тело мультикадра по 8 байт и передавал начиная от хвоста с нарастающим адресом:

Цитата

размер тела мультикадра (кол-во кадров в нём): NF = (размер_данных_мультикадра - 1) / 8 + 1

CAN_ID 1-го кадра = базовый_CAN_ID + 15 - NF

...

CAN_ID NF-го кадра = базовый_CAN_ID + 15 - 1

CAN_ID последнего кадра (заголовок мультикадра) = базовый_CAN_ID + 15

В таком случае FIFO не нужно - каждый кадр попадает в свой MO. И для отправки не нужна возможность в МК задавать порядок отправки: можно по порядку CAN-ID передавать - заголовочный CAN-ID всегда придёт последним. И прерывание нужно только одно - для заголовочного (последнего кадра); кадры тела принимаются/передаются без прерываний.

Так сделал на всякий случай - хотя у меня был XMC4700 с аппаратными FIFO и множеством MO, но на всякий случай, если нужно будет подключать к шине МК с CAN-контроллером послабее.

[adnega 11]

8 минут назад, jcxz сказал:

тогда для передачи мультикадров выделили только один адрес

Полностью согласен. ID и его администрирование дает очень много полезных возможностей. Нельзя к нему так упрощенно относиться. Это и адресация, и фильтрация, и приоритеты, и какие-то поля данных.

[Arlleex 187]

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

Так вы же вроде свой протокол ваяете? Почему тогда для передачи мультикадров выделили только один адрес (CAN-ID)? Почему не выделить например - 16 последовательных адресов?

Наверное, Вы правы, можно было бы выделить десяток ID. Но проблема в том, что для поддержания нескольких "виртуальных интерфейсов" придется иметь несколько таких десятков ID. Посчитал, что это довольно расточительно, даже с точки зрения учета и администрирования этих самых ID. Но тут правильно заметили (а я и задумался, что такое может быть), что в CAN действительно у меня могут быть шлюзы (специфика такая), где кадры могут улетать за пределы локальной CAN-шины в другую, а потом прибегать обратно.

[jcxz 241]

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

Но проблема в том, что для поддержания нескольких "виртуальных интерфейсов" придется иметь несколько таких десятков ID. 

Зачем? У меня эти 16 адресов использовались всеми участниками CAN-сети. Типа - как параллельная шина. Самый старший адрес (базовый_CAN_ID + 15) - для передачи кадров управления (заголовки мультикадров и различные команды управления этой "шиной"). Точнее - старший адрес у каждого устройства был свой, а вот остальные 15 адресов - общие (для передачи тела данных мультикадров). Хотя наверное всё-таки = было 16 адресов для тела данных, а адреса управления - отдельно, у каждого устройства свой.

У меня в сети были мастер и много слэйвов. Инициатива обмена мультикадром (на ввод или вывод) - всегда по инициативе мастера. Поэтому все слэйвы по дефолту держат свои 16 MO тела данных в режиме приёма; мастер - в режиме передачи. В прерывании выигрыша арбитража (вроде так) адреса управления мастер переключает свои 16 MO данных на приём (так как в этот момент все MO данных гарантированно уехали в шину); потом передаётся собственно кадр из MO управления. Один из слэйвов (который получил в свой адрес управления) финальный управляющий кадр; перед ответом переключает 16 MO данных на передачу; передаёт ответный мультикадр (или короткий ACK через адрес управления; если тело данных не нужно) и также в прерывании выигрыша арбитража на передачу заголовка переключает свои 16 MO данных на приём. Так нет коллизий (нет двух наборов MO данных одновременно настроенных на передачу в разных устройствах).

Вобщем - такая себе полудуплексная квази-параллельная шина из 16 MO данных и одного MO управления. С одним прерыванием на передачу мультикадра и одним - на приём. Всего у нас устройств в шине планировалось - до 33 шт. Значит для всего интерфейса нужно: 16+33 шт. адресов. Вроде как не особо много. Требования по ресурсу CPU - очень низкие получились, практически незаметные на общей загрузке CPU Cortex-M4 144MHz.

Только надо добавить небольшие защитные паузы перед переключением MO данных на передачу. Чтобы другая сторона гарантированно успела переключить свои на приём. Чтобы не мешали задержки входа в ISR на разных участниках обмена.

 

ЗЫ: Глянул в исходники: всё-таки наврал - ширина шины у меня == 8 MO. Но задаётся дефайном, так что можно поменять в любой момент.

#define CAN_NSLAVES     32     //макс.кол-во слэйвов
#define CAN_UG_D_WIDTH  8      //кол-во MO (и адресов) используемых для отправки тела UG-кадра

//Распределение адресов (11-битных) на внутренней CAN-шине. Адрес == смещению от начала ICanAddrSpace.
struct ICanAddrSpace {
  char unuse0[16];
  char obReset;                //адрес сброс-сообщения (протокол обзора + UG)
  char unuse1[15];
  char torque;                 //адрес рассылки задания крутящего момента
  char unuse2[32];
  char obData;                 //протокол обзора. данные
  char obCmd;                  //протокол обзора. команды
  char obGarbage;              //протокол обзора. сбор мусора
  char obScan[4];              //протокол обзора. сканирование серийных номеров
  char obInfo;                 //протокол обзора. информация о совместимости прошивок
  char unuse3[7];
  char ugData[CAN_UG_D_WIDTH]; //адреса тела UG-кадра
  struct {
    char master;               //адрес UG-master
    char slave[CAN_NSLAVES];   //адрес UG-slave
  } ugCtl;
};

//Распределение CAN.MO. Номер MO == смещению от начала CanMoSpace.
//Чем больше смещение - тем ниже приоритет при отправке на передачу.
struct CanMoSpace {
  struct T_ug {                //MO UG-протокола. Использование мастером и слэйвом:
    char data[CAN_UG_D_WIDTH]; //все: приём/передача тела UG-кадра
    char ctlRx;                //все: приём заголовков
    char ctlTx;                //все: отправка заголовков; мастер: отправка сброс-сообщений
    struct Observe {           //MO протокола обзора. Использование MO мастером и слэйвом:
      char data;               //мастер: отправка тела команды (свой UID); слэйв: приём тела команды (UID мастера)
      char cmd;                //мастер: отправка заголовка команды; слэйв: приём заголовка команды
      char scanRx;             //мастер: приём ответов от слэйва на проверку живости UID (в OBF_DELAY3); слэйв: приём RTR-запросов сканирования
      char scanTx;             //слэйв: отправка ответов на RTR-запросы сканирования
      char misc;               //мастер: приём информационных кадров (в OBF_SCAN0); слэйв: отправка ответов на проверки живости UID
    } observe;
    char reset;                //все: приём сброс-сообщения
  } ug;
  struct T_ecan {
    char tele[CfgTele::STREAM_N];   //телеметрия
    char remote[CfgRemote::ITEM_n]; //дистанционное управление
  } ecan;
};

ICanAddrSpace::ugCtl - как раз адреса интерфейса передачи мультикадров.

CanMoSpace::data, CanMoSpace::ctlRx, CanMoSpace::ctlTx - MO этого протокола.

Как видно - ресурсов шины он требует немного.