Предотвращение сбоя .net serialport при отключении USB-устройства FTDI

Question

У меня есть приложение, которое должно обмениваться данными с несколькими пользовательскими устройствами, некоторые из которых используют FTDI-преобразователи USB-to-serial, а некоторые используют TCP. Приложение должно иметь возможность принимать данные в любое время с устройств, которые могут быть подключены или отключены в любое время; приложение служит мостом между устройствами и базой данных.

Похоже, что когда устройство отключено от сети, оно часто приводит к тому, что класс SerialPort генерирует исключение в потоке BackgroundWorker и завершает работу приложения.

Мое настоящее решение, которое, вероятно, нелепо сложно, состоит в том, чтобы приложение-помощник отправляло / получало данные последовательного порта и передавало их в / из сокета TCP. Когда мое основное приложение обнаруживает, что USB-устройство подключено, оно запускает это другое приложение и затем использует сокет TCP для связи с ним. Если подключено несколько USB-устройств, для каждого из них будет запущен отдельный экземпляр вспомогательного приложения. Когда USB-порт отключен, вспомогательное приложение аварийно завершает работу, но сообщение «Неожиданное отключение» будет подавлено.

Этот подход работает, но кажется крайне неудовлетворительным. Должен быть лучший способ.

Answer 1

У меня были те же проблемы с .NET 2.0, и я вернулся к использованию оболочки FTDI dll: http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/CSharp/FTD2XX_NET_1010.zip

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

Я написал свой собственный класс для обнаружения событий отключения, перехватывая событие FT_IO_ERROR при попытке прочитать данные. Это не совсем удовлетворительно: поймать ошибку и заявить, что это отключение. Но это работает.

Я говорил об этом с FTDI, и недавно они выпустили новую заметку о применении: http://ftdichip.com/Support/Documents/AppNotes/AN_152_Detecting_USB_%20Device_Insertion_and_Removal.pdf

При этом используется событие WM_DEVICECHANGE для обнаружения отсоединения USB. Также работает, но есть небольшой улов. Поскольку это сообщение окна, оно работает только в том случае, если у вас есть графический интерфейс, и в некоторых случаях событие не поступит в ваше приложение, если другое приложение работает и перехватывает событие, прежде чем вы сможете его обработать.

Последний вариант - использовать WMI для обнаружения. Вы можете использовать ManagementEventWatcher создать слушателя на создание и удаление. Это также работает, однако на моем ноутбуке было несколько USB-портов, где драйвер FTDI не возвращал правильный COM-порт и идентификатор местоположения (на самом деле, вообще ничего), и это информация, которую я мог прочитать из WMI, поэтому я не смог связать событие WMI с подключенным устройством в оболочке DLL.

Я сообщил об этой проблеме в FTDI в июне / июле 2010 года, и предположительно проблемы GetCOMportNumber и Location ID были исправлены в их версии драйвера 2.08.02 (август), но у меня не было времени, чтобы перепроверить это.

Пока что мой опыт с адом USB ...

Answer 2

Я тестировал удаление адаптера USB-последовательный порт во время использования в .Net 4.0. Это не вызывает сбои приложения, как это было в предыдущих версиях .Net. Кроме того, в предыдущих версиях не только происходило аварийное завершение работы приложения, но иногда приходилось перезагружаться, чтобы заставить порт работать вообще.