Jump to content

    

геннадий75

Участник
  • Content Count

    11
  • Joined

  • Last visited

Community Reputation

0 Обычный

About геннадий75

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

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