ИСПОЛЬЗУЮ ISP1183. КОД ПИШУ НА ОСНОВЕ ПРИМЕРА ПРЕДСТАВЛЕННОГО НА САЙТЕ ПРОИЗВОДИТЕЛЯ ДЛЯ ЭТОЙ М/С
ПРОБЛЕМА В СЛЕДУЮЩЕМ, НЕ СТАБИЛЬНО ПРОХОДЯТ ТЕСТЫ CHAP9, ПОДКЛЮЧАЮ ЧЕРЕЗ ХАБ2.0, ТЕСТИРУЮ С ПОМОЩЬЮ USBCV13
ТО ЕСТЬ РАЗ НА РАЗ НЕ ПРИХОДИТСЯ, ИНОГДА ВСЕ ПРОХОДИТ НА УРА, НО ЧАЩЕ НЕТ. В ОСНОВНОМ НЕ ПРОХОДИТ 150 ПОВТОРЕНИЙ ТЕСТА НУМЕРАЦИИ УСТРОЙСТВА
В ИНТЕРНЕТЕ, НА КАКОМ ТО ФОРУМЕ, У ЧЕЛОВЕКА БЫЛИ ТОЧНО ТАКИЕЖЕ ПРОБЛЕМЫ С PDIUSBD12 - НЕ ДО КОНЦА ПРОХОДИЛА НУМЕРАЦИИ УСТРОЙСТВА.

НЕ ЗНАЮ, ЧТО ДЕЛАТЬ... ЗАДАЛ ВОПРОС ТОМУ У КОГО ТАКИЕ ПРОБЛЕМЫ БЫЛИ, ОН МНЕ НАПИСАЛ В ОТВЕТ: "У Philips нашел пример для него, где четко отслеживались все состояния, в котором пребывает контроллер при процессе enumeration. Там была куча тонкостей, как и когда он должен посылать в ответ. Проблема enumeration состоит в том, что со стороны PC это все организовано мягко говоря странно. Посылается запрос, а ответ читается только частично, снова возобновляется и так несколько раз. Соответственно из-за этого шараханья все проблемы и происходят."
И ПРИЛАЖИЛ ПРИМЕР (ТОЧНО РАБОТАЮЩИЙ) ДЛЯ PDIUSBD12. НО Я БОРИСЬ С ПРИМЕРОМ D13, А ЭТО НЕМНОГО ДРУГОЙ КОД
ПОДСКАЖИТЕ, ЧТО МОЖЕТ БЫТЬ.

ОШИБКУ, КОТОРАЯ ЕСТЬ В ПРИМЕРАХ D12 И D13 ИСПРАВИЛ, ТАМ БУФЕР ДЛЯ ПРИЕМА ТОЧКОЙ 0 ИМЕЕТ ФЕКСИРОВАННЫЙ РАЗМЕР, А СЧИТЫВАЕМЫЕ В НЕГО ДАННЫЕ МОГУТ ПРЕВЫШАТЬ ЕГО, НО ОШИБКА НЕ В ЭТОМ...
ПО ПИТАНИЮ ТОЖЕ ВСЕ ВРОДЕ ВПОРЯДКЕ, КОНДЕНСАТОРОВ ХВАТАЕТ...

Я НЕ ИСПОЛЬЗУЮ НОЖКУ М/С, ГОВОРЯЩУЮ О ВОЗНИКНОВЕНИИ ПРЕРЫВАНИЯ, Я ПЕРЕОДИЧЕСКИ ОПРАШИВУЮ РЕГИСТР ПРЕРЫВАНИЯ, ПРЕДВАРЕТЕЛЬНО РАЗРЕШАЯ ЗАПИСЬ В ЕЕ РЕГИСТРЫ, ДАВАЯ КОМАНДУ LockDevice, МОЖЕТ ДЕЛО В ЭТОМ, ISP1183, НЕ УСПЕВАЕТ ПОГАСИТЬ В РЕГИСТРЕ ПРЕРЫВАНИЯ, ХОТЯ В РЯД ЛИ....
УЖЕ МЕСЯЦ БЬЮСЬ, НИЧЕГО НЕ ВЫХОДИТ....

С энумерацией, а именно с командой SET_ADDRESS у многих проблеммы. Даже у серийных девайсов. Встречали такие случаи, что комп со вставленным в USB девайсом грузится перестаёт? Я встречал. Так это из-за того, что энумерация, а именно SET_ADDRESS, не проходит. Во время работы из-под биоса. Там биос такой. Слишком правильный. Он такие ошибки со стороны устройства не понимает и виснет. А таймаута у него нет. А когда ОС работает, там уже всё нормально. Будет пытаться до победного. Несмотря на все глюки. Оттуда и "посылается, частично читается"... В том случае адрес девайса не своевременно с 0-го на установленный в сетупном пакете переключается. Или это в дескрипторе CONFIGURATION в первый раз м.б. его длина читается. Но в любом случае такого советчика гнать надо.
Рекомендую разобраться в описании и сделать самому, а не слушать советы. А примеры - они примеры и есть. Делать так, как в них, в реальных девайсах нельзя ни в коем случае.

Не использовать прерывания, на мой взгляд, неразумно. Лучше это активировать. Размер буфера приема для EP0 и должен быть такого же размера, как это описывается в USB descriptor (обычно 8 бит). Для всех задача по enumeration этого достаточно. Нет ни одной команды длиннее. Заметил, что многие примеры от производителей расчитаны на некоторые теоретически правильный процесс enumeration, а как я писал и предыдущий автор заметил, это на практике не совсем так. Поэтому и приходится вводит некоторую машину состояний в работу с контроллером, для защиты прикладного обеспечения от всяческих бяк. Процесс доводки usb до ума занимает довольно много времени. У нас на работе серийные устройства без проблем работают с PC на win2000, XP и Vista, но есть один компер с vist'ой, на которой совершенно спорадически бывают разовые сбои, причем при reset'е устройство тут же снова нормально распознается. Как-то на американском форуме пару лет тому читал заметки одного специалиста, он писал, что их фирма серийно выпускает устройства с usb, так на некоторых изделиях тоже наблюдаются сбои, которые он, несмотря на наличие логических анализаторов, специальных аппаратных usb-анализаторов, так и не смог локализовать.

а что в таком случае делать? где ставить задержку, повтор или что? у меня бывает так, что только самый первый тест DeviceDescriptorTest_DeviceConfigured (в программе USB Command verifier), например, не проходит, а EnumerationTest проходит.
может ссылку на статьи на сей счет подскажите

Во первых нужно главы 8 и 9 описания USB изучить. Я уже перевод здесь выкладывал, только он не очень.
Во вторых сниффером смотреть, что там при ошибках происходит.
А по опыту - больше всего глюков с обработкой запроса SET_ADDRESS бывает. Вот его досконально изучить нужно. Важно в какой момент адрес с 0-го на установленный менять нужно. Обычно это аппаратно в микросхемах поддерживается, т.к. процессор не успевает. Т.е. описание микросхемы на эту тему почитать. И проверить соответствие железа и программы.


Попробуйте у него снуппер на хаб науськать. По симптомам это хаб виснет, а не ваш девайс. И никакой анализатор этого не покажет. В параллельной ветке это обсуждалось.
А вот размер буфера EP0 наоборот рекомендую 64 байта делать (если железо поддерживает), конечно и в дескрипторе DEVICE - соответственно. Это позволит через контрольный канал быстро с девайсом общаться.