Перейти к содержанию
    

Упорядочены ли кадры с одним и тем же CAN ID?

Можно ли гарантировать, что отправляя друг за другом кадры с одним и тем же ID, все участники сети будут получать их в том же самом порядке, в котором отправитель их отправлял?

В случае, если у отправителя несколько разных CAN ID - там понятно, нет гарантий. А если ID один и тот же?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 7/22/2024 at 2:29 PM, Arlleex said:

Можно ли гарантировать, что отправляя друг за другом кадры с одним и тем же ID, все участники сети будут получать их в том же самом порядке, в котором отправитель их отправлял?

В случае, если у отправителя несколько разных CAN ID - там понятно, нет гарантий. А если ID один и тот же?

А почему нет ? Кто их перемешает ?
В CAN сети же нет сетевых коммутаторов как в Ethernet.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

А почему нет ? Кто их перемешает ?

А вот кто его знает, кто. В контроллерах вон, есть же биты, в каком порядке выставлять кадры на шину - и я вполне допускаю, что чисто в теории могут быть варианты, когда эстафету "проигравший" арбитраж мэйлбокс передает следующему, даже если в нем такой же ID. Есть опасения, что такое возможно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 7/22/2024 at 3:08 PM, Arlleex said:

А вот кто его знает, кто. В контроллерах вон, есть же биты, в каком порядке выставлять кадры на шину - и я вполне допускаю, что чисто в теории могут быть варианты, когда эстафету "проигравший" арбитраж мэйлбокс передает следующему, даже если в нем такой же ID. Есть опасения, что такое возможно.

Например, в STM32F407 написано

Quote

The transmit mailboxes can be configured as a transmit FIFO by setting the TXFP bit in the CAN_MCR register. In this mode the priority order is given by the transmit request order. This mode is very useful for segmented transmission
 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Прочитайте настройки контроллера КАН, там буквами написано. Как настроете так и будет

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Прочитайте настройки контроллера КАН, там буквами написано. Как настроете так и будет

Мне надо разработать протокол для пока еще сферического проца/МК, я не знаю возможностей CAN для него.

И либо закладываться на гарантию очередности, даваемую самим CAN, либо нет. Это и хочу выяснить.
 

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

Например, в STM32F407 написано

Для STM-ок понятно. Не понятно в целом - на куче разных МК разных производителей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Можно ли гарантировать, что отправляя друг за другом кадры с одним и тем же ID, все участники сети будут получать их в том же самом порядке, в котором отправитель их отправлял?

Если вы их уже отправили, то как они могут поменять порядок будучи уже отправленными? Странный вопрос....

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

А вот кто его знает, кто. В контроллерах вон, есть же биты, в каком порядке выставлять кадры на шину - и я вполне допускаю, что чисто в теории могут быть варианты, когда эстафету "проигравший" арбитраж мэйлбокс передает следующему, даже если в нем такой же ID. Есть опасения, что такое возможно.

Может вы всё-таки неверно сформулировали вопрос и он касается очередности выставления для участия в арбитраже для отправки на шину кадров из мэйл-боксов готовых к передаче? А не уже отправленных кадров.

Порядок отправки зависит от вашего контроллера - он может отправлять как угодно, совершенно никак не связывая это с CAN-ID. Почитайте мануал на него. Для XMC4xxx например можно задать порядок отправки. И там есть несколько возможных режимов отправки. Постановка на арбитраж (для отправки) никак не связана с CAN-ID.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 7/22/2024 at 3:13 PM, Arlleex said:

И либо закладываться на гарантию очередности, даваемую самим CAN, либо нет. Это и хочу выяснить.

Насколько я знаю (а знаю я не очень хорошо :blush:), в CANopen, для отправки блока данных, в теле пакета один байт отводится под номер последовательности.

Можете сами почитать CiA301, раздел про SDO.

Наверное это сделано как раз на случай, если данные где-то перемешиваются.

 

On 7/22/2024 at 3:21 PM, jcxz said:

Если вы их уже отправили, то как они могут поменять порядок будучи уже отправленными? Странный вопрос....

Их не отправили, а положили в почтовый ящик для отправки. А почтовых ящиков может быть несколько.

On 7/22/2024 at 3:21 PM, jcxz said:

Постановка на арбитраж (для отправки) никак не связана с CAN-ID.

Отучаемся говорить за всех.

Для STM32F407

Quote

Transmit priority

By identifier

When more than one transmit mailbox is pending, the transmission order is given by the identifier of the message stored in the mailbox. The message with the lowest identifier value has the highest priority according to the arbitration of the CAN protocol. If the identifier values are equal, the lower mailbox number will be scheduled first.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Их не отправили, а положили в почтовый ящик для отправки. А почтовых ящиков может быть несколько.

Из исходного поста следует, что именно отправили:

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

все участники сети будут получать их в том же самом порядке, в котором отправитель их отправлял?

а не просто "положили в ящик". Почему я и попросил уточнения.

 

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

Не понятно в целом - на куче разных МК разных производителей.

Насчёт порядка отправки готовых для отправки MO, то в XMC4xxx вроде как порядок такой отправки (выхода MO на фазу TX-арбитража) вообще не зависит от CAN-ID кадра. А зависит только от положения MO в списке MO для данной ноды и поля приоритета, прописанного в свойствах MO.

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

И либо закладываться на гарантию очередности, даваемую самим CAN, либо нет. Это и хочу выяснить.

Нет такой гарантии. Или о чём вы тут говорите?

Сам CAN описывает только фазу арбитража. А выставлять или нет на него кадр - решает CAN-контроллер МК. Решает в общем случае - никак не согласуясь с CAN-ID.

 

Более того: CAN XMC4xxx позволяет программисту определять: участвовать ли готовому к отправке кадру в повторном TX-арбитраже, если он проиграл предыдущий арбитраж или нет? Программист может указать как действовать для каждого конкретного кадра.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

16 minutes ago, dimka76 said:

Можете сами почитать CiA301, раздел про SDO.

Это если SDO blob transfer. Остальные пакеты однокадровые, им пофиг какой порядок.

+ есть всякие retransmission и прочая лабуда.

Поэтому 50% что будет в том порядке как положили.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Может вы всё-таки неверно сформулировали вопрос и он касается очередности выставления для участия в арбитраже для отправки на шину кадров из мэйл-боксов готовых к передаче? А не уже отправленных кадров.

Да, очередность выставления для арбитража и т.д.

Мне надо передавать данные для записи в массив памяти (программируемой флешки).

Я хотел сократить оверхед и задействовать все 8 байтов под куски записи.

Хотел друг за другом отправлять массив в килобайт, а потом (через другие ID) проверять, все записались или нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Да, очередность выставления для арбитража и т.д.

Ну тогда - для XMC4xxx: раздел "Transmit Acceptance Filtering". Но вкратце - нет никакой обязательной связи CAN-ID с порядком выставления на арбитраж. Порядок задаётся другими инструментами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Хреновенько. Жаль. Тогда буду отводить байт под некий счетчик последовательности и остальные 7:sad: байт юзать под данные.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Я хотел сократить оверхед и задействовать все 8 байтов под куски записи.

Лучше так не делать. Сам сталкиваюсь с тем, что при плотном потоке, даже если они все будут успешно отправлены в нормальном порядке, нет гарантий, что на приемной стороне этот порядок можно будет выстроить, т.к. они там тоже залетают в почтовые ящики)

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

отводить байт под некий счетчик последовательности

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Я хотел сократить оверхед и задействовать все 8 байтов под куски записи.

А кто мешает?

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

Хотел друг за другом отправлять массив в килобайт, а потом (через другие ID) проверять, все записались или нет.

Не очень понятно - что мешает отправить в нужном порядке? :wacko2:

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

Лучше так не делать. Сам сталкиваюсь с тем, что при плотном потоке, даже если они все будут успешно отправлены в нормальном порядке, нет гарантий, что на приемной стороне этот порядок можно будет выстроить, т.к. они там тоже залетают в почтовые ящики)

Приёмная сторона примет их точно в том порядке, в котором они будут передаваться по шине. Ибо - другое невозможно по определению.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...