геннадий75

Всё правильно в бот указывается битовая скорость потока , включая старт бит и стоп бит . Соответственно на скорости 9600 бод/с можно передать 7680 бит/с .

Если захочешь V3 диагностировать старые подогреватели , в лучшем случае увидишь такую заставку .

Тоже , не отказался бы , от отломанной V3 под обычный k-line . Но в свободном доступе их пока нет .

Минимально работающий USB/ k-line для Webasto Thermo Test V3 на PIC18F2550. pic18F2550.HEX

Насчёт двух моторов в одной машине тоже не видел . А два ,не зависимых друг от друга блока управления двигателя с 2000 года, притеняются в авто . Причём он может быть как master так и scave и иметь разные ID .

Почему , считают что в CAN, все устройства должны постоянно стучать в шину . Можно назначить одно устройство мастером , и оно будет периодически отправлять сообщения например с ID 0x01 , и первый байт данных 01 затем 02 потом 03 итак далее в зависимости от количества узлов . Остальные узлы настроены на приём IDx01 , и соответственно принимают все запросы мастера . После приёма сравнивают первый байт данных со своим уникальным номером , и если он совпадает ,один узел отправляет одно сообщение мастеру с другим ID например 02 и любых 8 байт данных о своём состояний . Мастер принимает эти данные , и решает продолжать обмен с этим узлом или перейти к следующему .

В CDC нужны минимум 4 точки .Две нулевых по ним идёт служебная информация . И две рабочие, одна для приёма и одна для передачи данных.

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

Семь и более единиц подряд окончание пакета . Нулевой бит начало пакета ,дальше не забываем после 5 нулей или единиц про врезки потом подсчёт CRC и бит подтверждения приёма другими узлами.

Как то у вас всё просто . При добавлений двух байт в подсчёт CRC добавляется не одна операция XOR с полиномом а 16 . И нули никогда не получишь . Проверяется легко в онлайн калькуляторах . https://crccalc.com

Последний два байта также участвуют в подсчёте CRC , соответственно 0х0000 не получишь.

1E1 и есть 11 битный идентификатор . 0х не важно.

Если отправляешь 65 байт должно дойти именно 65 , но в два захода сначала первый пакет 64 байта, затем второй 1 байт . Нулевой или не полный пакет (менее 64 байт ) говорит об окончаний запроса . Если сделаешь размер точки 8 байт , то уйдёт 8 пакетов по 8 байт и 9 пакет 1 байт.

Если интересна работа CAN на физическом уровне , видеть как идёт подсчёт CRC , бит подтверждения , битые сообщения . Собираешь адаптер на PIC18f2550 или PIC24FJ64GB002 . CAN.rar

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

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

Также нужно было увидеть весь поток CAN сообщений (в том числе битые сообщения,шесть нулей на шине) написал программу, которая сохраняет весь поток на диске и потом его можно проанализировать. CAN.rar

Перегонял данные в ПК на скоростях 1 мбод ,2 мбод ,4 мбод с помощью переходника USB-COM собраном на PL2303HX.Для этого в своё время, писалась терминальная программа, для обработки больших объёмов данных.

В дескрипторе задан размер нулевой точки 64 байта.Поэтому на запрос setup GET_DESCRIPTOR( 80 06 00 01 00 00 12 00 )data0 отправляй сразу 18 байт дескриптора data1 и жди следующий запрос.

А почему сразу баг. Если вы передаёте пакеты по 64 байта, драйвер их собирает и ждёт окончания запросов (неполный пакет или нулевой пакет) если его небудет он заполнит свой буфер (по умолчанию 4к) и только после этого отдаст данные в windows. Данные нужно выставлять на отправку сразу после пакета sof и заканчивать нулевым пакетом в пределах кадра.