Седой

Я уже тут писал, что проблема в драйверах этих устройств или настройках драйверов или в самих устройствах, ведь переход в suspend не изменяет device state и после resume реэнумерация не нужна.

Работает также как и IOCTL_INTERNAL_USB_CYCLE_PORT, вызванный из драйвера. Как написано в комментарии usbioctl.h: " This IOCTL will simulate a plug/unplug on the drivers upstream port. The device will be removed and re-added by PnP. " В драйвер менеджере вижу удаление и появление драйвера. В устройстве вижу полный цикл энумерации. Проверил на MT-Link, USB-COM (один свой на CP2103, второй покупной на Prolific), своих двух платах(одна на С8051F326, вторая PDIUSBD + AVR), на Olimex LPC-P2148 и MLPC2368 от StarterKit. Следует обратить внимание, что документирован этот запрос неверно, делать нужно как написано в usbioctl.h, а именно: 1. Вызывать для драйвера хаба, а не хоста. 2. Передавать в качестве входного параметра указатель на DWORD c номером порта, начинающегося с 1.

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

Пока проверил только IOCTL_USB_HUB_CYCLE_PORT - detach и последующий attach устройства - прекрасно работает из UserMode c драйвером хаба. Остальное проверю позже, как будет время.

Если нет, тогда вы правы. Ну тогда отловить программно такую ситуацию довольно просто - обработкой сообщения WM_DEVICE. А вот у него и спросим. Тогда эта возможность не была документирована.

Ну зачем вы делаете скоропалительные выводы - см. http://msdn.microsoft.com/en-us/library/aa476347.aspx

А ResetPort пробовали. А может просто драйвера не отрабатывают соответсвующие IO. Можно впрямую послать запрос в endpoint0.И в другие тоже, только предварительно открыв. Да попробуйте любое, главное чтобы устройство определилось. Хаб не замечает, а компьютер замечает, ну вы даете. Открыть драйвер менеджер и посмотреть есть ли там "замеченное","выдернутое" устройство ...

Вот кстати из реального suspend вывести как раз можно, как и ввести. А то что описали вы - это хаб обнаруживает ошибку и просто отключает порт, а не производит selective suspend. Я как раз и указал псевдокоманду запроса перевода в suspend порта хаба - SetPortFeature(PORT_SUSPEND). К хосту, кстати, доступ из UserMode тоже есть - пример из DDK usbview.

Меньше возможность уткнуться в чужую ошибку. В вашем случае я бы использовал winusb от Microsoft.

IAD должен быть один на 2 интерфейса СDC.

Нижний драйвер и есть драйвер композитного устройства и с точки зрения вашего драйвера устройства ему все равно, какой драйвер является нижним, разницы в запросах дескрипторов нет, просто драйвер композитного устройства сформирует дескриптор на основе прочитанного из самого устройства. Поэтому и спросил про функцию. При использовании драйвера для устройства в составе композита может быть типичная ошибка (кстати wizard от DriverStudio грешит этим) - просмотрите код и обратите внимание на номер используемого интерфейса, если интерфейсы СDC первые, то ваш должен быть 2. Да, если у CDC два интерфейса, то должен быть прописан IAD. PS. Драйвер композита хитрая штука, например, запрос SetConfiguration от вашего драйвера до устройства не дойдет. Запрос SetConfiguration в устройство направляет драйвер композита.

Это вам кажется - затраченное время на стартапе с лихвой окупается в дальнейшем. Драйвер можно не писать, воспользоваться готовым, если устраивают его возможности. А как без знаний!!!???? По поводу Агурова - ответил в соседней ветке. Вы же изучаете работу конкретного чипа по его документации (data sheet) от производителя, а не по книжкам.

А что это за функция DoCallUSBD? Если новичок в драйверописательстве - в топку все книжки типа Агурова (единственная достойная - Programming the Microsoft Windows Driver Model от Walter Oney), скачайте WDK и пишите в KMDF, а возможно достаточно будет готового WinUSB.

Из документации производителя OS http://msdn.microsoft.com/en-us/library/ms681382(VS.85).aspx Если делаете USB-DMX под серию и выбрали AVR - посмотрите в сторону AT90USB162, получится и надежней и дешевле. Мы сделали мультипротокольный (DMX тоже поддерживает) USB-RS485 на C8051F326, драйвер свой, проблем с наводками нет. Лежит у меня на столе, заканчиваю документацию на ПО.

Сейчас просмотрел документацию на драйвера FTDI. Можно же работать не через COM порт, а через D2XX интерфейс и попробовать воспользоваться функцией FT_ResetPort (FT_ResetDevice,FT_CyclePort) для выхода из ошибочного состояния.

Что значит откуда? А причем тут развязка. Посмотрите http://caxapa.ru/lib/emc_immunity.html

Хост кстати ответил правильно - ошибкой транзакции и драйвер FTDI должен адекватно отреагировать на эту ситуацию, мог бы сделать ResetPort или по крайней мере установить флаг, чтобы при вызове CloseHandle не входить в ступор. PS.Нужно посмотреть по спецификации USB правила работы хоста и устройства в таких ситуациях.

Эта ошибка ERROR_GEN_FAILURE - A device attached to the system is not functioning. Вот теперь понятно, что чип коряво отрабатывает такую ситуацию. Но передергивать устройство тоже не дело. Попробуйте после такой ошибки вызвать CancelIO или CancelIOEx, а потом уже CloseHandle - проверим корявость драйвера. Он должен также вполне законно "заснуть" при получение команды Suspend от хоста.

Скорее всего не виснет, а ждет завершения передачи, т.е. Port.WriteData(TX_Buf) не возвращается? Да и установите timeouts для записи.

Забыл вам сказать, что функцию GetLastError нужно вызывать в контексте того потока, значение ошибки которого вы хотите получить.

На первый взгляд все нормально. Давайте попробуем отловить ошибку, для этого переделайте немного вызов генераторов исключений Вместо XXX_ComPort_Error.Create("Сообщение об ошибке") Вызывать XXX_ComPort_Error.CreateFmt("Сообщение об ошибке %x",[GetLastError]) И сообщите значение GetLastError.

Давайте все-таки код посмотрим, а то может быть глюк и в драйвере.

Если не сильно вдаваться в детали вызов функции CloseHandle обрабатывается нормальным драйвером следующим образом 1. Драйвер должен отменить все операции ввода/вывода. 2. Освободить ресурсы (память и т.д.), захваченные при обработке CreateFile. 3. ... Если этого не сделать, последующий вызов CreateFile вернет ошибку. Поэтому и приходиться освобождать ресурсы жестким образом - "передергивать шнур USB". Почему BC и Delphi - в определенных ситуациях RTL вызвает TerminateThread, что приводит к тому, что ранее запрошенный потоком I/O запрос в драйвер продолжает работать, он не отменяется, как при нормальном завершении потока вызовом ExitThread - и опять приходится "передергивать шнур USB". Я сейчас точно не помню, где мне приходилось править RTL в D5, это было году в 2000, c тех пор ее и пользуюсь для написания dll для железа.

Симптомы понятны, нет нормального вызова CloseHandle. Работаете скорее всего с BC или Delphi. Ошибка в программе, а не в железе.

Что за исключение? ( exeption)