При приеме данных длиной более 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 пакетов при свободной шине или есть есть еще накладные расходы, которые я забыл учесть?
Это время планирую использовать в приемнике как таймаут ожидания следующего пакета.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"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 клоков после завершения передачи узла с более высоким приоритетом

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

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

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