Какова максимальная пауза между 2-мя пакетами? Опции

[Yaumen]

При приеме данных длиной более 8-ми байт, передающая сторона разбивает их на несколько пакетов, в каждом из которых передается по 8-м байт. Передача ведется последовательно пакет за пакетом. Однако каждый CAN пакет имеет целый набор дополнительных полей, который практически удваивает объем передаваемой информации:
1) 8 байт данных + 4 байта ID + 1 байт DLC + 2 байта CRC + 1 байт EOF = 16 байт
2) Каждый байт передается с помощью 10-ти бит (8 бит данных + Старт бит + Стоп бит)
3) Итого передача одного пакета занимает 16*10 = 160 бит.
4) Для скорости 1 Мбит это означает 160 мкс на одну посылку.

Можно ли утверждать, что полученное время и есть минимальное время следования CAN пакетов при свободной шине или есть есть еще накладные расходы, которые я забыл учесть?
Это время планирую использовать в приемнике как таймаут ожидания следующего пакета.

[Andrew2000]

2) Каждый байт передается с помощью 10-ти бит (8 бит данных + Старт бит + Стоп бит)

+ bit stuffing - после пяти одинаковых бит будет вставлен один инверсный (кажется, пять - уточните)

[Yaumen]

+ bit stuffing - после пяти одинаковых бит будет вставлен один инверсный (кажется, пять - уточните)

Да конечно, еще Bit Stuffing для 160 бит - их 32 бита (4 байта).

Больше ничего нет? Просто у меня реально работающий таймаут на порядок больше получается, что странно!!!!

[cant]

если есть возможность, лучше не таймаут использовать, а фильтры. с учетом протокола вы по таймауту не будете попадать в 70% передач. а так в адрес забили свой протокол (типа это первый, это второй а это последний пакет) и ответ на все с программной проверкой адреса.

ошибка не ответ а прием всех пакетов.

Сообщение отредактировал cant - Jul 8 2010, 07:20

[Yaumen]

если есть возможность, лучше не таймаут использовать, а фильтры. с учетом протокола вы по таймауту не будете попадать в 70% передач. а так в адрес забили свой протокол (типа это первый, это второй а это последний пакет) и ответ на все с программной проверкой адреса.

ошибка не ответ а прием всех пакетов.

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

Но вопрос был в другом. Меня смущает большие цифры получившегося рабочего таймаута. Одно успокаивает, что передатчик писал не я и вообще не наша контора, поэтому возможно там выполняется какая-то логика перед отправкой очередного CAN пакета, отсюда и задержки. Если в своих расчетах я учел все аспекты, то пора браться за осцилограф

[редактор]

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

[Yaumen]

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

Все верно, но сейчас тест идет только между двумя устройствами и других устройств в сети нет, поэтому, и провожу исследование на правильность функционирования.

[Andrew2000]

тогда только осциллограф - передатчик-то не свой

[bookevg]

При приеме данных длиной более 8-ми байт, передающая сторона разбивает их на несколько пакетов, в каждом из которых передается по 8-м байт. Передача ведется последовательно пакет за пакетом. Однако каждый CAN пакет имеет целый набор дополнительных полей, который практически удваивает объем передаваемой информации:
1) 8 байт данных + 4 байта ID + 1 байт DLC + 2 байта CRC + 1 байт EOF = 16 байт
2) Каждый байт передается с помощью 10-ти бит (8 бит данных + Старт бит + Стоп бит)
3) Итого передача одного пакета занимает 16*10 = 160 бит.
4) Для скорости 1 Мбит это означает 160 мкс на одну посылку.

Можно ли утверждать, что полученное время и есть минимальное время следования CAN пакетов при свободной шине или есть есть еще накладные расходы, которые я забыл учесть?
Это время планирую использовать в приемнике как таймаут ожидания следующего пакета.

А зачем ожидать - применение бит-стаффинга гарантирует, что пауза между сообщения будет короткая и составляет минимум - 5бит+1бит

[Yaumen]

А зачем ожидать - применение бит-стаффинга гарантирует, что пауза между сообщения будет короткая и составляет минимум - 5бит+1бит

На приемной стороне всегда приходится ждать, тут уж ничего не поделаешь!!!

[Andrew2000]

А зачем ожидать - применение бит-стаффинга гарантирует, что пауза между сообщения будет короткая и составляет минимум - 5бит+1бит

а это вообще что такое написано?

"Each DATA FRAME and REMOTE FRAME is delimited by a flag sequence consisting
of seven ’recessive’ bits"

посмотрел старые зарисовки - на скорости 250k период can-телеграмм (от начала одной до начала след.) плавает где-то от 540 до 560 мкс

[bookevg]

а это вообще что такое написано?

"Each DATA FRAME and REMOTE FRAME is delimited by a flag sequence consisting
of seven ’recessive’ bits"

посмотрел старые зарисовки - на скорости 250k период can-телеграмм (от начала одной до начала след.) плавает где-то от 540 до 560 мкс

Давайте не будем путать структуру FRAME и паузу между сообщениями. То что Вы привели относится к структуре FRAME.
На читаем на wiki (и я с этим согласен - т.к. если CAN делать на FPGA, то надо задавать четко все временные):
http://en.wikipedia.org/wiki/Controller_area_network
So, if you are transmitting a recessive bit, and someone sends a dominant bit, you see a dominant bit, and you know there was a collision. (All other collisions are invisible.) A dominant bit is asserted by creating a voltage across the wires while a recessive bit is simply not asserted on the bus. If any node sets a voltage difference, all nodes will see it. Thus there is no delay to the higher priority messages, and the node transmitting the lower priority message automatically attempts to re-transmit 6 bit clocks after the end of the dominant message.
Как я понимаю этот текст - после того, как сообщение с более высоким приоритетом было отправлено, узел с более низким приоритетом начнет передачу после 6 клоков после завершения передачи узла с более высоким приоритетом

[galjoen]

2) Каждый байт передается с помощью 10-ти бит (8 бит данных + Старт бит + Стоп бит)

Вы бы хоть немного описание протокола CAN почитали - тогда многие вопросы сами-собой отпадут.

[Andrew2000]

Как я понимаю этот текст - после того, как сообщение с более высоким приоритетом было отправлено, узел с более низким приоритетом начнет передачу после 6 клоков после завершения передачи узла с более высоким приоритетом

Я про фразу "применение бит-стаффинга гарантирует, что пауза между сообщения будет" при чем тут бит-стаффинг? он к паузам никакого отношения не имеет.
Изначально вопрос был про таймаут, т.е. не минимум интересен, а максимум.
Кстати, на максимум могут повлиять и Error frame при плохой связи.

[bookevg]

Я про фразу "применение бит-стаффинга гарантирует, что пауза между сообщения будет" при чем тут бит-стаффинг? он к паузам никакого отношения не имеет.
Изначально вопрос был про таймаут, т.е. не минимум интересен, а максимум.
Кстати, на максимум могут повлиять и Error frame при плохой связи.

Как я понял постановка задачи была следующая:
Зная время передачи пакета, использовать его в приемнике как таймаут ожидания следующего пакета.
Уточняющий вопрос: в какой момент собираются запускать таймер таймаут - в момент приема новой посылки или после завершения приема пакета?
1.
В случае, если если пакет запускается в момент приема новой посылки, то т.к. время передачи пакета невозможно четко определить на стороне приемника в момент начала приема пакета, то может получится ситуация, когда произойдет потеря следующего пакета, если время таймаут рассчитано на пакет, в котором одни нули. А пакет с передатчика может пойти сразу же, т.к. существуют контроллеры, у которых несколько mailbox по CAN, которые могут сконфигурироваться одновременно на передачу.
2.В случае, если если пакет запускается после завершения приема пакета, то это делать некорректно ,т.к. нарушает спецификация по CAN

[Andrew2000]

прежде чем писать - читайте стандарт, лежит тут
http://www.can-cia.de/index.php?id=441

[bookevg]

прежде чем писать - читайте стандарт, лежит тут

Если вы умный, то сразу приводите выписки из стандарта, а не ссылки. Моя ошибка заключается в том, что я неправильно указал число клоков.
Согласно стандарту пауза между DATA FRAMEs and REMOTE FRAMEs может составлять от 2клоков и более
Специально для Вас (не касаемся OVERLOAD FRAME):
1.
DATA FRAMEs and REMOTE FRAMEs can be used both in Standard Frame Format and Extended Frame Format; they are separated from preceding frames by an INTERFRAME SPACE.
2.
DATA FRAMEs and REMOTE FRAMEs are separated from preceding frames whatever type they are (DATA FRAME, REMOTE FRAME, ERROR FRAME, OVERLOAD
FRAME) by a bit field called INTERFRAME SPACE. In contrast, OVERLOAD FRAMEs and ERROR FRAMEs are not preceded by an INTERFRAME SPACE and
multiple OVER-LOAD FRAMEs are not separated by an INTERFRAME SPACE.
INTERFRAME SPACE
contains the bit fields INTERMISSION and BUS IDLE and, for ’error passive’ stations, which have been TRANSMITTER of the previous message, SUSPEND TRANSMISSION.
INTERFRAME SPACE contains the bit fields INTERMISSION and BUS IDLE and, for ’error passive’ stations, which have been TRANSMITTER of the previous message, SUSPEND TRANSMISSION.
2.1.INTERMISSION
consists of three ’recessive’ bits.
During INTERMISSION the only action to be taken is signalling an OVERLOAD condition
and no station is allowed to actively start a transmission of a DATA FRAME or REMOTE
FRAME.
Note:
If a CAN node has a message waiting for transmission and it samples a dominant bit at the third bit of INTERMISSION, it will interpret this as a START OF FRAME bit,
and, with the next bit, start transmitting ist message with the first bit of its IDENTIFIER without first transmitting a START OF FRAME bit and without becoming receiver.
2.2.BUS IDLE
The period of BUS IDLE may be of arbitrary length. The bus is recognized to be free and any station having something to transmit can access the bus. A message, which is pending for transmission during the transmission of another message, is started in the first bit following INTERMISSION.
The detection of a ’dominant’ bit on the bus is interpreted as START OF FRAME.
2.3.SUSPEND TRANSMISSION
After an ’error passive’ station has transmitted a message, it sends eight ’recessive’ bits following INTERMISSION, before starting to transmit a further message or recognizing the bus to be idle. If meanwhile a transmission (caused by another station) starts, the station will become receiver of this message.

[cant]

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

Но вопрос был в другом. Меня смущает большие цифры получившегося рабочего таймаута. Одно успокаивает, что передатчик писал не я и вообще не наша контора, поэтому возможно там выполняется какая-то логика перед отправкой очередного CAN пакета, отсюда и задержки. Если в своих расчетах я учел все аспекты, то пора браться за осцилограф

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