Jump to content

    

геннадий75

Участник
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

0 Обычный

About геннадий75

  • Birthday 09/23/1975

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

883 profile views
  1. В CDC нужны минимум 4 точки .Две нулевых по ним идёт служебная информация . И две рабочие, одна для приёма и одна для передачи данных.
  2. Когда мониторишь CAN видно битые сообщения , без подтверждения , обрывающиеся на пол пути . Но при этом никогда нет шести нулей подряд . Если какой то узел решил что его обидели , или нет подтверждения его посылки , то он может выставить шесть нулей подряд остановив шину и попытаться опять отправить запрос . Но это критическая ситуация приводящая через несколько таких попыток к остановки обмена другими узлами .
  3. Семь и более единиц подряд окончание пакета . Нулевой бит начало пакета ,дальше не забываем после 5 нулей или единиц про врезки потом подсчёт CRC и бит подтверждения приёма другими узлами.
  4. Как то у вас всё просто . При добавлений двух байт в подсчёт CRC добавляется не одна операция XOR с полиномом а 16 . И нули никогда не получишь . Проверяется легко в онлайн калькуляторах . https://crccalc.com
  5. Последний два байта также участвуют в подсчёте CRC , соответственно 0х0000 не получишь.
  6. 1E1 и есть 11 битный идентификатор . 0х не важно.
  7. Если отправляешь 65 байт должно дойти именно 65 , но в два захода сначала первый пакет 64 байта, затем второй 1 байт . Нулевой или не полный пакет (менее 64 байт ) говорит об окончаний запроса . Если сделаешь размер точки 8 байт , то уйдёт 8 пакетов по 8 байт и 9 пакет 1 байт.
  8. Если интересна работа CAN на физическом уровне , видеть как идёт подсчёт CRC , бит подтверждения , битые сообщения . Собираешь адаптер на PIC18f2550 или PIC24FJ64GB002 . CAN.rar
  9. Многие CAN адаптеры не увидев сигнал подтверждения ACK выставляют на шину шесть нулей , типа перезапуск шины . И на многих машинах это приводит к отключению обмена.
  10. Программа считывает весь идущий поток данных, и уже его пытается собрать в CAN сообщения. Даже одиночный ноль на шине я увижу, также видно битые сообщения , видно правильно посчитан CRC если неверно программа покажет правильный, видно подтвердили другие блоки сообщение или нет ,сколько единиц между пакетами, также если приходят одинаковые CAN сообщения в правом окне программы не появляются . В правом окне видны только новые CAN сообщения, именно это помогало выдернуть из потока нужное CAN сообщение.
  11. Также нужно было увидеть весь поток CAN сообщений (в том числе битые сообщения,шесть нулей на шине) написал программу, которая сохраняет весь поток на диске и потом его можно проанализировать. CAN.rar
  12. Перегонял данные в ПК на скоростях 1 мбод ,2 мбод ,4 мбод с помощью переходника USB-COM собраном на PL2303HX.Для этого в своё время, писалась терминальная программа, для обработки больших объёмов данных.
  13. В дескрипторе задан размер нулевой точки 64 байта.Поэтому на запрос setup GET_DESCRIPTOR( 80 06 00 01 00 00 12 00 )data0 отправляй сразу 18 байт дескриптора data1 и жди следующий запрос.
  14. А почему сразу баг. Если вы передаёте пакеты по 64 байта, драйвер их собирает и ждёт окончания запросов (неполный пакет или нулевой пакет) если его небудет он заполнит свой буфер (по умолчанию 4к) и только после этого отдаст данные в windows. Данные нужно выставлять на отправку сразу после пакета sof и заканчивать нулевым пакетом в пределах кадра.