[jcxz 184]

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

один недостаток - в CAN (не FD) максимальный пэйлоад 8 байт, что как бы не густо.

Как я уже писал выше: можно немножко увеличить этот размер, за счёт части неиспользуемых адресных бит.  

[haker_fox 60]

19 minutes ago, Arlleex said:

CANOpen (например, прикрутив стек CAN Festival).

Гм... про Festival слышу неоднократно. Вы его рекомендуете?

[Arlleex 131]

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

Вполне возможно. Но я не видел документов однозначно это подтверждающих.

Видел такую инфу в некоторых источниках (конечно же, не 100% достоверных). Но механизмы арбитража немного наводят на такие мысли.

 

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

Не обязательно. Зависит от протокола прикладного уровня (поверх CAN).

Да, по сути, я это и имел ввиду: только разработчику видно, как ему строить модель взаимодействия узлов.

 

Цитата

Они предназначены (имхо) для случаев, когда передающий узел не получил ACK на свой переданный кадр ни от одного из устройств на шине. Искажения входят в число этих случаев. Но не только они.

К слову сказать, конкретно ошибка по отсутствию ACK имеет немного другое влияние на счетчики ошибок передачи, в отличие от всех других ошибок. В целом CAN, как по мне, это простой интерфейс, но со своими подводными тараканами.

 

3 часа назад, haker_fox сказал:

Гм... про Festival слышу неоднократно. Вы его рекомендуете?

Мы его просто используем Я погрузился в него ровно настолько, насколько нужно для его запуска.

Не могу сказать о нем ничего плохого (да и хорошего). Работает и работает вполне нормально.

[jcxz 184]

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

Видел такую инфу в некоторых источниках (конечно же, не 100% достоверных). Но механизмы арбитража немного наводят на такие мысли.

Меня тоже они навели на аналогичные мысли.   Но я не видел документов 100%-но подтверждающих это. Причём - подтверждающих это именно для протокола шины CAN, а не для какой-то конкретной его реализации в каком-то чипе.

Цитата

К слову сказать, конкретно ошибка по отсутствию ACK имеет немного другое влияние на счетчики ошибок передачи, в отличие от всех других ошибок.

Это тоже логично, так как передатчик сам тоже отслеживает поток передаваемых им на шину бит, и может отличить случай искажения передаваемого потока и отсутствия ACK. И случай неискажения, а просто отсутствия ACK.

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

Мы его просто используем Я погрузился в него ровно настолько, насколько нужно для его запуска.

Интересно: А в нём есть механизм обзора сети одним мастером и перечисления устройств в сети, в случае если все эти устройства одинаковые, не имеют никакой своей инфы чтобы занять один адрес CAN (чтобы не конфликтовать друг с другом), но имеют уникальный длинный (64 бит) номер?

Читать описание мне лень, может быстро подскажете?  

А то свой лисапед изобретаю  

[Arlleex 131]

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

Читать описание мне лень, может быстро подскажете?

Использование CANOpen подразумевает, что сеть будет состоять из узлов с уникальными ID.

В начале инициализации стека выполняется этап идентификации и нумерации устройств мастером.

Если честно, протокол этот так себе. Понять что такое словарь объектов и как его правильно использовать, понять всю динамику этого протокола сходу будет сложновато, ИМХО.

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

[jcxz 184]

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

Использование CANOpen подразумевает, что сеть будет состоять из узлов с уникальными ID.

Под "ID" Вы имеете в виду - CAN-адреса? Т.е. которые 11 или 29 бит длиной? Или ID может быть бОльшей длины?

[adnega 10]

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

И, вроде как, на самом деле арбитраж происходит по всему сообщению CAN, а не только по идентификатору.

Это называется BIT ERROR

Цитата

BIT ERROR
A unit that is sending a bit on the bus also monitors the bus. A BIT ERROR has to
be detected at that bit time, when the bit value that is monitored is different from the
bit value that is sent. An exception is the sending of a ’recessive’ bit during the
stuffed bit stream of the ARBITRATION FIELD or during the ACK SLOT. Then no
BIT ERROR occurs when a ’dominant’ bit is monitored. A TRANSMITTER sending
a PASSIVE ERROR FLAG and detecting a ’dominant’ bit does not interpret this as
a BIT ERROR.

Т.е. все что пишем необходимо читать и сравнивать. Несовпадения допускаются только в полях арбитража и подтверждения.

Если арбитраж выигран, данные отправляются (но, видимо, несколькими узлами), то в какой-то момент произойдет ошибка бита.

Передатчик это обнаруживший должен отправить рецессивную ошибку, которая второму передатчику никак не помешает.

Видимо, счетчик ошибок передачи должен подрасти. Видимо, какое-то событие контроллер can в МК тоже может получить.

Например, у stm32 такие ошибки:

Цитата

                switch((CAN1->ESR >> CAN_ESR_LEC) & 7)
                {
                    case 0:    con_str("no_error");    break;
                    case 1:    con_str("stuff");            break;
                    case 2:    con_str("form");            break;
                    case 3:    con_str("ack");                break;
                    case 4:    con_str("bitr");            break;
                    case 5:    con_str("bitd");            break;
                    case 6:    con_str("crc");                break;
                    case 7:    con_str("sw");                break;
                }

 

Я всегда считал, что несколько узлов на шине с одним и тем же ID - трагедия, чреватая BUSOFF-ами.

Насчет повторной передачи:

Цитата

Transmitter:
The message is valid for the transmitter, if there is no error until the end of END OF
FRAME. If a message is corrupted, retransmission will follow automatically and
according to prioritization. In order to be able to compete for bus access with other
messages, retransmission has to start as soon as the bus is idle.

Если передача закончилась успехом, то все ок. Иначе - автоматическая повторная посылка.

В контроллере can в МК это может гибко настраиваться: отключаться, перепосылаться уже с учетом порядка и приоритетов в мэйлбоксах и т.п.

[Arlleex 131]

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

Под "ID" Вы имеете в виду - CAN-адреса? Т.е. которые 11 или 29 бит длиной? Или ID может быть бОльшей длины?

ID - именно CAN-идентификаторы сообщений, да.

И так называемые объекты данных в словаре имеют жестко фиксированную карту адресов; то есть в CANOpen нельзя использовать и назначать CAN-ID как угодно и как хочется - есть жесткие правила их генерации при инициализации мастера.

В CANOpen есть еще, в некотором смысле, стратегии передачи данных - это механизмы heartbeats-ов, node-guarding-ов и т.д., что заставляет вас плясать под дудку этого стека. Контроль узлов, emergency-сообщения, аварийные сообщения, sync-службы - все только через стек; это, конечно, круто, но ни шагу влево-вправо. Еще, выбирая CANOpen, нужно понимать, что придется определиться с оптимальной стратегией самого обмена - клиент-серверная схема это, или же какая-то другая, их там тоже несколько.

Более того, составление словаря объектов - это то еще увлекательное занятие, отнимающее немало времени. Формировать его лучше вообще каким-нибудь скриптом-генератором.

Короче, CANOpen сам по себе мне не понравился. Это реально протокол для тех, кто его придумал...

[jcxz 184]

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

ID - именно CAN-идентификаторы сообщений, да.

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

Я всегда считал, что несколько узлов на шине с одним и тем же ID - трагедия, чреватая BUSOFF-ами.

Вы вместе с adnega вносите путаницу. Я долго не мог понять, о чём идёт речь про "ID узла CAN". 

ID - это именно "ID сообщения CAN". Узел (node) CAN может принимать/отправлять сообщения с разными ID. ID к узлу никак не относится.

 

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

Короче, CANOpen сам по себе мне не понравился. Это реально протокол для тех, кто его придумал...

Ясно. Тогда в сад его. Нам такие овраги на ровном поле не нужны. Мы и сами их наворотим.  

[adnega 10]

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

Вы вместе с adnega вносите путаницу. Я долго не мог понять, о чём идёт речь про "ID узла CAN". 

ID - это именно "ID сообщения CAN". Узел (node) CAN может принимать/отправлять сообщения с разными ID. ID к узлу никак не относится.

ID - это

Цитата

IDENTIFIER
IDENTIFIER -
Standard Format
The IDENTIFIER’s length is 11 bits and corresponds to the Base ID in Extended
Format. These bits are transmitted in the order from ID-28 to ID-18. The least
significant bit is ID-18. The 7 most significant bits (ID-28 - ID-22) must not be all
’recessive’.
IDENTIFIER -
Extended Format
In contrast to the Standard Format the Extended Format consists of 29 bits. The
format comprises two sections:
Base ID with 11 bits and the
Extended ID with 18 bits

Никакой путаницы быть не может.

Видимо, вам под ID хочется понимать "какой-нить адрес" или "какой-нить серийник". Дык, и называйте это адресами или серийниками.

Я, например, поле ID использую для приоритетов сообщений и адресации источника. Фильтрация софтовая, аппаратные фильтры не использую.

У узла есть серийник. Зная серийник, можно задать/поменять адрес узла (т.е. часть поля ID).

[jcxz 184]

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

Видимо, вам под ID хочется понимать "какой-нить адрес" или "какой-нить серийник". Дык, и называйте это адресами или серийниками.

Я, например, поле ID использую для приоритетов сообщений и адресации источника. Фильтрация софтовая, аппаратные фильтры не использую.

У узла есть серийник. Зная серийник, можно задать/поменять адрес узла (т.е. часть поля ID).

Это Вы вот понимаете под ID какие-то свои объекты в своём протоколе/устройстве. А я говорю о самом протоколе CAN.

В CAN говорится об ID CAN-кадра. У узлов нет никакого ID. Любой узел (участник) CAN сети может принимать/отправлять сообщения с любыми ID. Эти ID кадров на уровне CAN никак не относятся к узлам. На прикладном уровне поверх CAN конечно можно для себя для частного случая определить какую-то зависимость.

[Arlleex 131]

А в терминах CANOpen вообще применяется COB-ID. Это идентификатор объекта. Этот идентификатор как раз привязывается к 11-битному (не знаю насчет 29-битных, может и такие поддерживаются) физическому ID CAN-сообщения.

И вот этот COB-ID разбивается на 2 части - младшие 7 бит адресуют узел сети, а старшие 4 бита - код выполняемой функции (ну типа формализуют конкретно сообщение - менеджмент сети, emergency-сообщения и т.д.).

Так вот в CANOpen CAN-ID сообщения практически непосредственно адресует узел, несмотря на топологию CAN и отсутствие адресации в этой шине как таковой.

[haker_fox 60]

Коллеги, позвольте ещё уточняющий вопрос: если я возьму трансиверы (PHY) CAN с питанием 5 В, и питанием 3 В, я же могу их подключить к одной шине при условии, что земли связаны?

[Arlleex 131]

19 минут назад, haker_fox сказал:

...если я возьму трансиверы (PHY) CAN с питанием 5 В, и питанием 3 В, я же могу их подключить к одной шине...?

Да. Земли объединять вовсе не обязательно.

[Ioann_II 0]

6 часов назад, jcxz сказал:

Как я уже писал выше: можно немножко увеличить этот размер, за счёт части неиспользуемых адресных бит

А подскажите, а то пока что, как новичок в этом интерфейсе, не соображу, как прочитать эти адресные биты?

Прошу сильно не ругать - только начинаю с ним работать.

6 часов назад, Arlleex сказал:

конкретно ошибка по отсутствию ACK имеет немного другое влияние на счетчики ошибок передачи, в отличие от всех других ошибок.

В чём заключается отличие? У меня в макете с 1 МК при отсутствии ACK счётчик ошибок увеличивался каждый раз на 8 - это оно?

6 часов назад, Arlleex сказал:

Мы его просто используем Я погрузился в него ровно настолько, насколько нужно для его запуска.

Не могу сказать о нем ничего плохого (да и хорошего). Работает и работает вполне нормально.

Про CanFestival - а где его скачать  и посмотреть? Поиск даёт или битые ссылки или что-то не похожее...