jcxz 232 22 июля Опубликовано 22 июля · Жалоба 4 минуты назад, x893 сказал: В жизни есть протоколы (canopen/ isobus / ...), для коня в вакууме делайте как хотите. Судя по сообщениям ТС, он изобретает свой велосипед. И ему все эти канопены с их проблемами - не указ. 1 минуту назад, dimka76 сказал: Заюзайте CAN-FD, а лучше CAN-XL Вот уж точно - такое есть не в каждом МК. Тем более. Не то что FIFO..... 53 минуты назад, adnega сказал: Можно часть ID выделить под счетчик (размером не менее числа mailbox на приемной стороне). Если протокол позволяет) А ещё можно - часть ID под данные кадра. И тем - повысить плотность потока. Хотя степени двойки конечно уже не будет.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimka76 59 22 июля Опубликовано 22 июля · Жалоба On 7/22/2024 at 4:42 PM, jcxz said: А ещё можно - часть ID под данные кадра. И тем - повысить плотность потока. Особенно, если Ext ID задействовать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 51 22 июля Опубликовано 22 июля · Жалоба Так как вопрос изначально был некорректным, то и дальнейшее обсуждение не имеет смысла. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 173 22 июля Опубликовано 22 июля · Жалоба 1 час назад, jcxz сказал: А кто мешает? В смысле кто? Отведенные 8 байтов максимум в кадре CAN. Задействование других каких-то ID недопустимо. 20 минут назад, dimka76 сказал: Заюзайте CAN-FD, а лучше CAN-XL Не, FD не во всех железяках в наличии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 232 22 июля Опубликовано 22 июля · Жалоба 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 22 июля Опубликовано 22 июля · Жалоба 8 минут назад, jcxz сказал: тогда для передачи мультикадров выделили только один адрес Полностью согласен. ID и его администрирование дает очень много полезных возможностей. Нельзя к нему так упрощенно относиться. Это и адресация, и фильтрация, и приоритеты, и какие-то поля данных. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 173 22 июля Опубликовано 22 июля · Жалоба 1 час назад, jcxz сказал: Так вы же вроде свой протокол ваяете? Почему тогда для передачи мультикадров выделили только один адрес (CAN-ID)? Почему не выделить например - 16 последовательных адресов? Наверное, Вы правы, можно было бы выделить десяток ID. Но проблема в том, что для поддержания нескольких "виртуальных интерфейсов" придется иметь несколько таких десятков ID. Посчитал, что это довольно расточительно, даже с точки зрения учета и администрирования этих самых ID. Но тут правильно заметили (а я и задумался, что такое может быть), что в CAN действительно у меня могут быть шлюзы (специфика такая), где кадры могут улетать за пределы локальной CAN-шины в другую, а потом прибегать обратно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 232 22 июля Опубликовано 22 июля · Жалоба 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 этого протокола. Как видно - ресурсов шины он требует немного. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться