Желающим USB под ДОС , Welcome!!!

[zakharo]

Не понял про конечные точки??? Это основное понятие всех устройств USB. Каждое устройство представляется как набор конечных точек - endpoint, каждая из которых может выполнять какую-либо специфическую функцию. Все транзакции адресуются двумя параметрами - адрес устройства и адрес конечной точки. Например, устройства с протоколом Bulk-Only Mass-Storage представляются чаще всего в виде трех конечных точек - управляющая (Control endpoint), она всегда имеет адрес 0, и две bulk-only: bulk-in и bulk-out, их адреса указываются в дескрипторе конфигурации. На Control endpoint идут всякие управляющие пакеты, типа начальной конфигурации и еще там в процессе работы могут быть сбросы состояния STALL для других конечных точек, а на bulk-only идут собственно команды и данные.
А вот, например, флоппи-диск работает по протоколу Control-Bulk-Interrupt, и там у него есть 4 конечные точки - на Control идут все команды, на две bulk (in и out) - данные, а состояние читается с 4-й конечной точки типа Interrupt. Но это так, к слову.
Короче, endpoint - это те приемники/передатчики информации, с которыми ты непосредственно работаешь.

Добавлено 27.07.12, 13:05
А всякие строковые дескрипторы можно смело игнорировать - они нужны только для информации.

Сообщение отредактировано: zakharo - 27.07.12, 13:06

[StasNewOs]

А понял

Добавлено 27.07.12, 13:37
Дескриптор устройства 18 байт был в примере проги перед номерацией и после, потом был дескриптор конфигурации в 9 байт в котором было поле wTotalLength 39 bytes и потом в дескрипторе конфигурации была инфа о ендпоинт

[StasNewOs]

Кстати в вашей первой транзакции 80080181=1 000000000011000 0 000 00 01 10000001, т.е зачем первый бит и зачем последний бит dt[31]?

Сообщение отредактировано: StasNewOs - 27.07.12, 14:38

[zakharo]

С нулевым битом я как-то не до конца разобрался. Это PING STATE, я с ним экпериментировал, да и бросил - не увидел никаких отличий. Это такие тонкости USB 2.0, которые, видимо, проявляются при наличии многих устройств одновременно. При установке этого бита контроллер перед транзакцией OUT пингует устройство, если же он установлен в 0, то сразу выполняет транзакцию.
А DT (бит 31) - это очень важно. Первая транзакция SETUP всегда идет с DT=0, а дальше все транзакции IN/OUT должны начинаться с DT=1. Если размер данных больше, чем maxPacketSize (есть у меня устройства с maxPacketSize=32, и дескриптор конфигурации там не умещается в одну транзакцию), EHC делает несколько транзакций сам, и уже сам там дальше отслеживает DT, но начинаться эти транзакции должны с DT=1.
Кроме того, впоследствии при работе с bulk-in и bulk-out endpoit'ами надо будет для каждой из них независимо отслеживать состояние DT и строго чередовать его.

[StasNewOs]

Да DT это важно, т.к я вернул первоначальные настройки для нумерации с которыми не проходил второй qTD и добавил этот бит, и это было именно то, что не хватало.
Кстати дескриптор устройства прошёл с тремя qTD размером 8 байт и передал мне размер максимального пакета, и протокол устройства вошёл, он у флешки и камеры разный, кстати у мышек он тоже другой(он показывает, что мыш это Hub (Find out more online) 9)
Дескриптор конфигурации ещё не отладил(тоже не проходит вторая и третья) для него ставлю номер устройства и пакет максимальный пишу из прошлого дескриптора.

Сообщение отредактировано: StasNewOs - 28.07.12, 02:54

[zakharo]

Цитата StasNewOs @ 28.07.12, 00:06

и протокол устройства вошёл, он у флешки и камеры разный, кстати у мышек он тоже другой(он показывает, что мыш это Hub (Find out more online) 9)

Разумеется, разный. Только не протокол, а класс. На usb.org есть документ, в котором перечислены классы USB-устройств.
9 - это хаб, да. Но нормальная мышь не должна определяться, как хаб. Хотя, не исключено, что там просто встроен хаб - я уже писал здесь, что сталкивался с флешкой, у которой был встроенный хаб на 1 порт. Чтоб там добраться до устройства, надо проделать всю инициализацию хаба.

Добавлено 28.07.12, 07:47

Цитата StasNewOs @ 28.07.12, 00:06

Дескриптор конфигурации ещё не отладил(тоже не проходит вторая и третья) для него ставлю номер устройства и пакет максимальный пишу из прошлого дескриптора.

А ты уже присвоил адрес устройству? Для простоты на первом этапе можно присвоить, скажем, 1 (главное - не 0). Тогда устройство начнет работать в полную силу.

Сообщение отредактировано: zakharo - 28.07.12, 07:49

[StasNewOs]

Да прошла нумерация и дескриптор устройства(принял от устройства его максимальный размер пакета, правда поставил его перед номерацией, как в вашем примере)
А у вас нету примера случайно для дескриптора конфигурации, который после нумерации?

Добавлено 28.07.12, 08:25
QH после нумерации идёт с номером устройства и размером максимального пакета

[zakharo]

Пример дам в понедельник. Все на работе. Хотя по сути с точки зренимя цепочки qTD операция там ничем не отличается от приема дескриптора устройства. Разница только в самом запросе (REQUEST).

[StasNewOs]

Сам запрос вроде правильный
mov byte[ebx],128 ;bmRequestType Device-to-host
mov byte[ebx+1],6 ;bRequest GET_DESCRIPTOR
mov word[ebx+2],256 ;wValue Descriptor Index Descriptor Type
mov word[ebx+4],0 ;wIndex
mov word[ebx+6],8 ;wLength
и
mov byte[ebx],128 ;bmRequestType Device-to-host
mov byte[ebx+1],6 ;bRequest GET_DESCRIPTOR
mov word[ebx+2],512 ;wValue Descriptor Index Descriptor Type
mov word[ebx+4],0 ;wIndex
mov word[ebx+6],18 ;wLength

[StasNewOs]

дескриптор конфигурации прошёл и строковый тоже, я там перепутал в заполнении QH занёс номер устройства и номер устройства в максимальный пакет тоже вместо самого размера. Осталось отладить чтение секторов у флешек, для этого нужно допроектировать мой объект ЮСБ устройства, туда нужно записывать инфу о конечных точках. Хотя для чтения сектора можно эту инфу не хранить, а просто по её присутствии продолжить установку функции чтения сектора в объект.

Добавлено 28.07.12, 14:30
После создании последней функции мои флешечные объекты автоматом подцепяться к файловым системам и будет список файлов в обзоре файлов
Прикреплённый файл1.jpg (50,31 Кбайт, скачиваний: 464)

Кстати почему строковый дескриптор выводит инфу не понятную, мне вообще нужно имя устройство а не тупое масс стораж или какойто лтд

Сообщение отредактировано: StasNewOs - 28.07.12, 14:55

[zakharo]

Строковый дескриптор я никогда не беру - он бесполезен.
Понятная инфа получится по команде INQUIRY (уровень SCSI). Особенно для картридеров - там устройство-то одно, а LUNов (LOGIC UNIT) - много, и для каждого LUNа будет свое имя.

Сообщение отредактировано: zakharo - 29.07.12, 18:47

[StasNewOs]

я выводил iProduct, ещё есть iManufacturer, дескриптор устройства хранит наличие их или отсутствие.
Точно, INQUIRY выводит строку поудачнее, там через comand transport как read10, которую сейчас пытаюсь разберать.
Все флешки через read10 могут работать?

[zakharo]

У меня пока все работают по READ10. Я другие виды READ даже и не использую.
А INQUIRY еще одну ценную вещь выводит - там в начале есть байт, по которому можно отличить флешку от компакт-диска. Многие компакт-диски работают по SCSI, как и флешки, так что отличить их по INQUIRY - единственный способ.

[StasNewOs]

READ10 и INQUIRY работают если в дескрипторе конфигурации bInterfaceSubClass SCSI transparent command set=6
Получение их через Command Transport с qTD OUT, потом Data Transport с qTD IN, и Status Transport с qTD IN
У вас нет примерчика рабочего.

Сообщение отредактировано: StasNewOs - 30.07.12, 09:52

[zakharo]

Не только 6, но и 2 (MMC, ATAPI). И bInterfaceProtocol = 50h (Bulk-Only Transport).
Там все стандартно - выдаем команду в виде CBW на bulk-out endpoint, получаем данные c bulk-in endpoint, потом получаем CSW с bulk-in endpoint. Может быть масса ошибочных ситуаций - например, устройство не готово (в картридере нет карточки или же устройство только что включено и выставило сигнал ATTENTION, который надо снять). Разные устройства по-разному уведомляют об этих ошибках. Стандартный путь - когда устройство вместо данных выставляет состояние STALL. Тогда надо снимать это состояние через CLEAR_FEATURE, потом получать CSW с кодом завершения (д.б. bCSWStatus=1) и уточнять причину ошибки через REQUEST_SENSE (там еще есть огромная таблица разных причин ошибок). Если ошибка простенькая, типа неготовности по включению (ATTENTION), то надо просто повторить команду. Если посложнее - то, возможно, придется делать Mass-Storage Reset или даже полную переинициализацию устройства.
А есть еще устройства, которые не выставляют STALL, а просто вместо данных выдают CSW. Я распознаю это по длине пакета (13 байт вместо запрошенного количества) и по результатам анализа самого пакета. В общем, там все не так просто...