Serial Comms умирает в WinXP - PullRequest
       22

Serial Comms умирает в WinXP

4 голосов
/ 19 февраля 2009

Немного истории: у нас есть приложение, которое изначально было написано много лет назад (1998 год - первое свидание в PVCS, но приложение примерно на 5 лет старше, чем оно изначально было программой DOS). Это приложение связывается с частью оборудования через последовательный порт. Когда мы добрались до Windows XP, мы начали получать сообщения о смерти приложения после короткого времени работы. Кажется, что последовательная связь просто «умерла», и приложение осталось в застрявшем состоянии. Единственный способ выхода из этой ситуации - перезапустить приложение.

Единственной информацией, которую я могу найти относительно этой проблемы, было, очевидно, то, что система сообщений Windows пропустит получение этой информации, заполнит буфер и система зависнет. Этот фрагмент информации был оставлен в старом текстовом документе, но нет никаких доказательств, подтверждающих это. Также упоминается, что это распространено только на высоких скоростях передачи (115200+).

Решением было предоставить клиентам USB-> последовательные преобразователи вместе с аппаратным обеспечением.

Сегодня: мы работаем над новой версией оборудования, которое будет работать как по сети, так и по последовательным портам. Поэтому, чтобы я мог работать с сетевым кодом, за исключением реального оборудования, которое мы используем, устройство VSCOM NetCom113 . Он также устанавливает виртуальный коммуникационный порт на компьютере пользователя (то есть: мой).

Теперь у меня есть сетевой код, интегрированный с приложением. Похоже, что устройство NetCom демонстрирует то же поведение, что и физическое устройство. Это нежелательно, так как мне нужно, чтобы приложение работало дольше, чем ~ 30 секунд.

Google обнаруживает ноль проблем, с которыми мы сталкиваемся.

Мне было интересно:

  • Кто-нибудь испытывал это раньше? Если да, что вы сделали, чтобы исправить / обойти проблему?
  • Есть ли у кого-нибудь какие-либо предложения относительно правильности первоначального автора документа и что я могу сделать, чтобы проверить теорию?

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

Обновление:

  • Код написан с использованием подпрограмм Win32 Comm - поэтому я использую CreateFile, ReadFile. Также есть разумные вызовы GetOverlappedResult.
  • Оно не висит само по себе, просто прекращается связь. Вы можете получить доступ к меню, нажать кнопки, но ничто не может взаимодействовать с подключенным оборудованием. Используя realterm , вы можете видеть, что данные не поступают и не выходят.
  • Я думаю, что ссылка на сообщение Windows заключается в том, что проблема связана с Windows. Данные поступили, но ядро ​​пропустило их и, таким образом, не сообщило об этом остальной системе.
  • Управление потоком не используется.
  • Написание «простого» теста затруднительно из-за того, что код тесно связан, а базовый протокол довольно сложен и потребует много работы.

Ответы [ 4 ]

2 голосов
/ 19 февраля 2009

Используете ли вы последовательный код в стиле DOS или подход Win32 CreateFile?

Если первое, будьте очень подозрительны: если это вообще возможно, я перейду на второе.

Если последнее, вы знаете, на каком системном вызове он висит? Вы находитесь в режиме блокировки чтения? или перекрывающийся вызов ввода / вывода? или ждать события? (Я не уверен, что у меня достаточно опыта, чтобы помочь, но такие вопросы приходят на ум)

Вы также можете проверить размер очереди, который вы можете установить с помощью функции SetupComm .

Я не покупаю "систему сообщений Windows" - она ​​звучит подозрительно; Вы можете написать хороший код последовательного ввода-вывода Win32, который никогда не использует сообщения Windows.

edit: использует ли ваш перекрывающийся ввод-вывод события? Кажется, я помню кое-что о событиях автоматического сброса, иногда пропускающих их триггер ... очень внимательно проверяйте ваши перекрывающиеся вызовы ввода-вывода, чтобы увидеть, правильно ли вы обрабатываете возможные результаты. Возможно, есть способ сделать ваш код более устойчивым, автоматически отменяя перекрывающийся ввод-вывод и перезапуская другое чтение. (Я предполагаю, что проблема в половине чтения, а не в половине записи?)

edit 2: Предложение: если сторона win32 пропустила байт или пакет, и ваши устройства находятся в тупике, потому что они оба ожидают, что они ответят на что-то, можете ли вы настроить другого сторона последовательного ввода-вывода, чтобы регулярно посылать какой-то тип «ping» -пакета с инкрементным счетчиком? (и регистрируйте ping-пакеты на стороне ПК; таким образом вы сможете увидеть, пропустили ли вы какие-либо)

1 голос
/ 19 февраля 2009

Вы уверены, что правильно настроили управление потоком? DTR, RTS и т.д ...

-Adam

0 голосов
/ 24 июня 2009

Не уверен, что это возможно для вас, но если бы вы могли переписать код, используя C # .NET, у вас был бы доступ к классу SerialPort там. Это может исправить вашу проблему. Я знаю много унаследованного кода, основанного на Win32 API для аппаратных портов ввода / вывода, который обычно имел сбой в XP из-за синхронизации (имел небольшой опыт работы с MIDI).

Кроме того, я не знаю, можете ли вы использовать метод Win32 для доступа к последовательному порту в Vista, что может помешать будущим ОС MS использовать ваш код.

0 голосов
/ 21 февраля 2009

Я написал приложения, использующие последовательные порты USB / Bluetooth, и у меня никогда не было проблем. с Bluetooth я видел битрейты (устойчивые) 800 000 бит / с в течение длительных периодов времени. большинство людей неправильно реализуют порт.

Мой последовательный порт

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...