Перейти к содержанию

Alex_2015

Участник
  • Публикаций

    14
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный
  1. сниффер ком порта

    Попробовал DeviceIoControl попользовать. Ожидаемого результата не увидел. Видимо не реализована она на уровне драйвера или чтобы она работала правильно, надо что то ещё допилить, но пока не нашёл. А можно ли запрячь драйвер, чтобы он возвращал явном виде о событии Idle в линии данных. То есть об отсутствии данных судить не по отсутствию Rxchar, а чтоб драйвер об этом сообщил. Есть такая программка - Modbus Poll. Вот она как-то умудряется по паузам между сообщениями работать, причём при обработке сообщений, не являющимися в чистом виде Модбасовскими. Вот как она это делает, мне очень интересно.
  2. сниффер ком порта

    В моём случае пауза определяется временем опроса драйвера виртуального порта системой. Это время составляет 1 мс. Вот 2 мс это и есть граница. Если система будет загружена выполнением большого количества дополнительных задач, то в таком случае спайки и на 30 мс неожиданностью не станут. Особенность в том, что DeviceIoControl позволяет добавлять в поток дополнительные данные о статусе устройства. Делается это на уровне драйвера, как мне удалось понять. Но повторюсь, информация очень скудная и будет ли в ней прок, хотел посоветоваться со знающими людьми. Может быть и другим интересно будет. Упоминания об использовании этой функции в связке с IOCTL_SERIAL_LSRMST_INSERT находил преимущественно на зарубежных сайтах. У нас как-то об этом не упоминают или ни кто не пробовал с ней работать.
  3. сниффер ком порта

    День добрый всем. У меня появилась возможность вернуться к решению задачи о построении сниффера и частично я её решил. 2 мс между посылками в компьютерной программе ловлю на ура. Причём не пришлось повышать приоритеты ни процесса, ни потока. Теперь хочу закрепить результат и поймать паузы менее 2 мс. В связи с чем вопрос - с функцией DeviceIoControl применительно к виртуальному порту кто-нибудь упражнялся. А то на всех ресурсах описание её очень скудное. В выходные попробую реализовать и посмотреть её результат. Но может кто что скажет из опыта работы с ней.
  4. сниффер ком порта

    Я всё-таки внесу некоторые дополнения. Использую преобразователь USB-RS485. Провёл несколько экспериментов и выяснил, что данные из порта читаются пачками по 4-16 байт. Причём начало запроса всегда читается с начала, начало ответа читается вместе с хвостом запроса. Эксперименты с таймаутами мало что меняют. Здесь, я думаю, большую роль играет характер устройства (виртуальный порт). Так случилось, что преобразователь построен на основе FTDI микросхемы. У неё есть возможность работы через D2XX драйвер, который, если верить описанию, в большей степени позволяет мониторить события железки. Если кто работал с ним, насколько это так. Сейчас вынужден временно переключиться на другую задачу, поэтому по этой буду только инфу изучать в свободное время.
  5. сниффер ком порта

    Я не утверждаю, что MSDN врёт. Просто констатирую факты. Возможно ошибка есть более глубоко в моём коде и я её пока не вижу. Поэтому пытаюсь освежить информацию по работе с портом, возможно пока та самая ошибка не проявлялась за несколько лет работы проги.
  6. сниффер ком порта

    Читал я MSDN в своё время, когда осваивал программирование ком порта. Но это ни чего не даёт. Когда драйвер захочет вернуть данные пользовательской программе, тогда и вернёт. И совсем не в режиме реального времени. А с таймоутами я экспериментировал, результат далёк от желаемого.
  7. сниффер ком порта

    На тему конвертора мысли были. Но только на самый крайний случай. Сейчас пока используется модифицированный модбас, в котором есть признаки, позволяющие однозначно определять начало и конец посылок. Есть потребность перейти к стандартному модбасу и будет нужна прога, которая позволит в реальном времени отслеживать обмен между устройствами в целях отладки. Сегодня перечитывал старую информацию, которую использовал при освоении программирования ком порта и нашёл то, что пропустил. Есть в структуре DCB символ XOFCHAR, который позволяет определить конец посылки. Осталось непонятным, его записывает драйвер в массив приёма или этот символ должен быть записан передатчиком в конец сообщения. Интернет по этому поводу подробностей пока не дал. Буду пробовать экспериментально. Была ещё мысль отслеживать событие DCD data carrier detect, но боюсь оно ожидаемого результата не даст. Была мысль алгоритмически ловить конец посылки через подсчёт CRC, но вариант не самый красивый. Хотя должен привести к результату.
  8. сниффер ком порта

    Такой вариант я рассматривал, но здесь ключевая фраза, если принята без ошибок. Самый надёжный способ - именно ловить паузы. Эксперименты с таймаутом особо не помогают. При скорости 115200 время передачи байта составляет 95мкс, а таймауты устанавливаются в миллисекундах. Основную проблему я вижу в том, что драйвер подбирает у системы данные с некоторым периодом. Программа у драйвера запрашивает данные тоже с каким-то периодом. За это время фактически драйвер может взять у системы несколько байт. Причём может схватить хвост запроса и начало ответа. Отсюда и лезут проблемы.
  9. сниффер ком порта

    Всем доброго дня. Есть сеть устройств, работающих по протоколу модбас через RS485. Необходимо написать перехватчик сообщений для ком порта, способный ловить паузы между сообщениями. Вот как поймать паузы, пока не соображу. Драйвер возвращает пачки по несколько байт, но поймать получается только длинные паузы (между запросами), а вот разделить запрос-ответ пока не могу. Есть программы снифферы, которые как-то реализуют такую возможность. Надо написать свою, в которой данные преобразовать в удобоваримый вид, удобный для отладки работы сети устройств. В винде это наверное тяжело будет сделать, но может есть способ, о котором я пока не знаю.
  10. aduc845 и PSEN

    День добрый! Проблема решилась. По всем признакам, формировался резет из-за многочисленных помех (устройство-мощное ЗУ) и проц уходил в загрузчик или что-то похожее (по косвенным признакам). Добавили кучу фильтров в питание и разделили по питанию процессор и перефирию, скорректировали трассировку нулевого провода. Хотя на удивление предыдущая версия прибора при тех же технических характеристиках и похожей трассировке платы проблем не доставляла. Всем спасибо.
  11. aduc845 и PSEN

    День добрый. Хотелось бы в продолжение темы задать ещё один вопрос. Как мне казалось, с процессором я разобрался, первую версию изделия собрали уже в нескольких экземплярах и всё чудненько работает. Но не бывает всегда всё хорошо. Сейчас делаем обновлённую версию и я достаточно серьёзно перепахал программу с целью ввести дополнительны возможности в прибор. И на столе всё работает изумительно, а вот в приборе... Вопрос в следующем. В самом начале основного цикла вставил переключение состояния пина, управляющего светодиодом, для контроля перехода программы через нулевой адрес в процессе работы (было замечено, что при некоторых внешних условиях программа будто перезапускается) и светодиод действительно переключается. А вот теперь пытаюсь понять, что его на это сподвигает. Проблемы с кодом не вижу. Подскажите, кто сталкивался, какие внешние события могут приводить к подобному сбою. Быть может это POR так себя проявляет?
  12. aduc845 и PSEN

    Видимо это было у очень старых атмеловских процессоров или у 51 архитектуры. У арма я такое не припомню. Но пока я решил остановиться с копанием PSENа. Программа сейчас работает без сбоев и надо уже по основным изменениям отработать. А времени, как всегда, мало, а сделать надо много. Хотя подозрение возникло. Проверю его чуть позже. Некоторые моменты в описании структуры памяти не совсем однозначно можно толковать. За подсказки спасибо.
  13. aduc845 и PSEN

    Спасибо за подсказку. Так случилось, что именно в этом направлении я сегодня и копал. Пришёл к этому решению, вспомнив выдержку из даташита о том, что aduc поддерживает работу с внешней памятью и поковыряв стартаповский файл понял, что настройки по умолчанию предопределяют работу именно с внешней памятью, подключаемой через порт 2. А у меня на нём светодиоды зацеплены. Ситуацию с переходом процессора в "не понятный режим" устранил. Но с PSEN пока непонятка осталась. Буду более подробно изучать организацию памяти. Потому, как на ALE наблюдаю генерацию с изменяемой частотой, будто он на самом деле пытается общаться с внешней памятью. Надо разделение памяти подкорректировать. Там ещё возможна нестыковка с учётом структуры программы.
  14. aduc845 и PSEN

    Всем доброго дня. Досталась плата на основе aduc845 для модификации изделия. Пишу свою простенькую программу для попробовать и всё здорово работает, но не более часа. Спустя примерно час с момента подачи питания процессор входит в не понятный для меня режим, а именно на PSEN появляется 1 и прекращается генерация кварца. С некоторой периодичностью (примерно 100мс) PSEN сбрасывается в ноль на короткое время и кварц начинает генерить. PSEN восстанавливается в 1, генерация прекращается. Программа при этом не работает. Что это за режим такой и что его может вызывать? Причём от сложности программы ни чего не зависит. Даже примитивная программа с миганием светодиодом в основном цикле ведёт себя точно также. Работаю с процессором пока второй день, опыта с ним маловато. Всё больше AVR. Смущает ещё тот факт, что судя п описанию при работе с внутренней памятью на PSEN должна быть 1, а я наблюдаю 0 при работе программы. Быть может вокруг этого искать надо. Возможно если при таких условиях он словит помеху по резету, то может свалиться в режим загрузки программы.