геннадий75
-
Постов
20 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные геннадий75
-
-
В 11.03.2024 в 02:01, girts сказал:
Чуть задумался...
Если задача запустить самый последний софтварь, но использовать для древних котлов начала 2000-х, то может оно и оправдано.
Только вот... А что же они там могли добавить?
Под винтаж?
И добавили ли?Если захочешь V3 диагностировать старые подогреватели , в лучшем случае увидишь такую заставку .
-
В 06.03.2024 в 20:42, Vasily_ сказал:
Всегда работало с любым k-line адаптером, сейчас что то изменилось ?
Тоже , не отказался бы , от отломанной V3 под обычный k-line . Но в свободном доступе их пока нет .
-
-
1
-
-
6 часов назад, AKK сказал:
(ни разу не видел автомобиль с двумя дизельными двигателями)
Насчёт двух моторов в одной машине тоже не видел . А два ,не зависимых друг от друга блока управления двигателя с 2000 года, притеняются в авто . Причём он может быть как master так и scave и иметь разные ID .
-
Почему , считают что в CAN, все устройства должны постоянно стучать в шину . Можно назначить одно устройство мастером , и оно будет периодически отправлять сообщения например с ID 0x01 , и первый байт данных 01 затем 02 потом 03 итак далее в зависимости от количества узлов . Остальные узлы настроены на приём IDx01 , и соответственно принимают все запросы мастера . После приёма сравнивают первый байт данных со своим уникальным номером , и если он совпадает ,один узел отправляет одно сообщение мастеру с другим ID например 02 и любых 8 байт данных о своём состояний . Мастер принимает эти данные , и решает продолжать обмен с этим узлом или перейти к следующему .
-
В CDC нужны минимум 4 точки .Две нулевых по ним идёт служебная информация . И две рабочие, одна для приёма и одна для передачи данных.
-
Когда мониторишь CAN видно битые сообщения , без подтверждения , обрывающиеся на пол пути . Но при этом никогда нет шести нулей подряд . Если какой то узел решил что его обидели , или нет подтверждения его посылки , то он может выставить шесть нулей подряд остановив шину и попытаться опять отправить запрос . Но это критическая ситуация приводящая через несколько таких попыток к остановки обмена другими узлами .
-
Семь и более единиц подряд окончание пакета . Нулевой бит начало пакета ,дальше не забываем после 5 нулей или единиц про врезки потом подсчёт CRC и бит подтверждения приёма другими узлами.
-
Как то у вас всё просто . При добавлений двух байт в подсчёт CRC добавляется не одна операция XOR с полиномом а 16 .
И нули никогда не получишь . Проверяется легко в онлайн калькуляторах .
-
Последний два байта также участвуют в подсчёте CRC , соответственно 0х0000 не получишь.
-
1E1 и есть 11 битный идентификатор . 0х не важно.
-
Если отправляешь 65 байт должно дойти именно 65 , но в два захода сначала первый пакет 64 байта, затем второй 1 байт . Нулевой или не полный пакет (менее 64 байт ) говорит об окончаний запроса . Если сделаешь размер точки 8 байт , то уйдёт 8 пакетов по 8 байт и 9 пакет 1 байт.
-
Если интересна работа CAN на физическом уровне , видеть как идёт подсчёт CRC , бит подтверждения , битые сообщения .
Собираешь адаптер на PIC18f2550 или PIC24FJ64GB002 .
-
Многие CAN адаптеры не увидев сигнал подтверждения ACK выставляют на шину шесть нулей , типа перезапуск шины . И на многих машинах это приводит к отключению обмена.
-
в битом кадре данные читаются - если у вас 0 то вы не доделали программу чтения битых кадров
Программа считывает весь идущий поток данных, и уже его пытается собрать в CAN сообщения. Даже одиночный ноль на шине я увижу, также видно битые сообщения , видно правильно посчитан CRC если неверно программа покажет правильный, видно подтвердили другие блоки сообщение или нет ,сколько единиц между пакетами, также если приходят одинаковые CAN сообщения в правом окне программы не появляются . В правом окне видны только новые CAN сообщения, именно это помогало выдернуть из потока нужное CAN сообщение.
-
Также нужно было увидеть весь поток CAN сообщений (в том числе битые сообщения,шесть нулей на шине) написал программу, которая сохраняет весь поток на диске и потом его можно проанализировать.
-
Перегонял данные в ПК на скоростях 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 и заканчивать нулевым пакетом в пределах кадра.
Перевод бод/сек в бит/сек
в AVR
Опубликовано · Пожаловаться
Всё правильно в бот указывается битовая скорость потока , включая старт бит и стоп бит . Соответственно на скорости 9600 бод/с можно передать 7680 бит/с .