Здравствуйте, форумчане! Решил я тут "от безделия" познакомиться с автомобильной CAN шиной. На мое счастье у меня имеется стенд (а-ля авто на столе) одной компании, занимающейся производством CAN-адаптеров. Подключил AVRку через TJA1040. Пытаюсь просто поглядеть, что происходит в шине. Ну и самый интересный пока пакет (двери и т.п.) вызывает настороженность. Сразу оговорюсь: описанные ниже данные точно истинные (их "видит" моя мега... их же вижу на выходе TJA1040 осциллографом). Итак:
0 - старт бит
00010000100 - ID (как я понимаю, 0x084)
0 - RTR (стало быть, DATA FRAME)
а вот дальше "чудеса"...:
001011 - CONTROL FIELD (4 младших байта "дают" 0xB = 11, что явно противоречит всем перелопаченным докам... максимум ведь - 8 должно быть)
ну а далее идут 75 бит. В том смысле, что 75-й - это последний "нулевой" бит. Далее "единицы" (которых "полезных явно должно быть 7 или 8 штук, в зависимости от состояния второго бита ACK... но это сейчас и не важно).
Так вот вопрос: почему я вижу такую странную длину поля данных... Или все таки я что то не так парсю?
Спасибо.

Вы, случайно, не запутались: Standard format / Extended format ?

Ура! Я не один! Спасибо за реакцию. Нет, не запутался. Под 29-битный ID пакет тоже не попадает... Очень хочется приложить данный пакет. Выкладываю (все, что видит мега и осциллограф... так что ошибка исключена). В последовательности абсолютно все биты (начиная и заканчивая "нулями" - старт-бит то, понятно, полезный. а вот после "моего" последнего нулевого бита явно еще сидят минимум штук 9 единиц (кусок ACK, 7 бит конца фрейма...), которые, естественно, сливаются на осциллограмме с межпакетной паузой.
00001000010000010110000010000010000010000010000010000010000010000010000010000111
10000110111110
разбираем:
0 - старт-бит
00010000100 - ID (0x084)
0 - RTR (стало быть, это data frame). И раз уж он нулевой, стало быть это обычный формат...
001011 - контрол филд... вот здеся и засада началась... 1011... по моим долгим и упорным переводам в десятичную ситстему дает результат - 11, что никак не имеет право на жизнь...
Да и любое другое количество байт данных ну никак не "подгоняется" по эту строку...
Еще раз спасибо. Что скажете?
Единственное: родилась мысль: а вдруг производитель кан-адаптеров (и стенда) для своего стенда "придумал" какой то уникальный протокол (использующий CAN только на физическом уровне). Но ведь вряд ли... Зачем так извращаться, когда кан-адаптер поддерживает почти все возможные модели авто, заставлять его еще спариваться со стендом на уникальном протоколе...

Про битстаффинг не забываем, выделенные цветом единички лишние.

Надеюсь, ногами пинать не будете, но про такой термин впервые слышу... Сразу погуглил...
Получается, что если подряд идут 5 "0" или "1", то следующий бит игнорируем/пропускаем мимо ушей (какой бы он ни был)?
Буду пытаться снова разобрать пакет по косточкам... Только вот как же так получается, что ни в одной увиденной мной доке по CAN не упомянуто о битстаффинге...

На всякий случай спрошу (самый конец моего пакета):
.......111110
получается, что последний "0" я тоже должен пропустить? то есть конец пакета уже превращается в:
.......11111111111111111111далее начинается уже следующий пакет ?

http://en.wikipedia.org/wiki/CAN_bus#Bit_stuffing
http://ru.wikipedia.org/wiki/Controller_Ar....B1.D0.BE.D0.BA

Спасибо. Дали пищу мозгу. Начинаю вникать...

Если дружите с английским, очень поможет оригинальная спецификация на протокол от Bosch -> http://www.semiconductors.bosch.de/media/p...ur/can2spec.pdf

Думал, что эту доку изучил... Оказывается, читал через строку.
Процесс пошел. Сейчас начну думать над функцией рассчета crc (всегда с контрольной суммой у меня был затык).
Всем отозвавшимся огромное спасибо!!!