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

[StasNewOs]

А понятно, ну мне пока для флешек хватит READ10 и INQUIRY чтобы хоть как то работали.

[shm]

Цитата StasNewOs @ 30.07.12, 10:43

ну мне пока для флешек хватит READ10 и INQUIRY чтобы хоть как то работали.

Не хватит. Работать будут далеко не все.

[StasNewOs]

Понимаю, причём нужны ещё функции reset, CLEAR_FEATURE, REQUEST_SENSE и обработку ошибок, но зато все порты работают и все устройства выдают стандартную инфу и флешки выдают сектора и идёт работа с файлами на ровне с диском, а по извлечению устройства оно по прерыванию удаляется и добавляется по её вводу в разъём.
Кстати у меня вебкамера имеет 14 конечных точек и размер конфигурации 592, хотя мне веб камеры не нужны, вот мышку попробую завести.

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

[zakharo]

Мышка точно не будет работать - это же low-speed устройство. EHCI сам не работает с low-speed, а отдает их компаньонам (в зависимости от производителя мамки м.б. OHCI или UHCI). Как вариант мышка может работать через хаб, тогда хаб сам делает преобразование скорости, но тогда тебе надо делать работу с хабом.

[StasNewOs]

Это знаю, уже писали. Я попробую через OHCI, у меня их 4 на ноуте. Принцип работы с юсб понял, так что буду думать и об этом со временем.

[StasNewOs]

INQUIRY состоит из 3 qTD в первой OUT мы отправляем 31байт, во второй IN мы получаем данные 36 байт, и в третей IN мы получаем 13 байт статус, так чтоли.
у SCSI устройств INQUIRY считается стандартным запросом инфы устройства.
В первой qTD я отправляю, кстати Tag может быть любым?
mov dword[ebx],0x43425355 ;Signature 'USBC'
mov dword[ebx+4],0x82BFDD18 ;Tag
mov dword[ebx+8],36 ;
mov byte[ebx+12],128 ;bmRequestType Device-to-host
mov byte[ebx+13],0
mov byte[ebx+14],6 ;Command Block Length

mov byte[ebx+15],12h ;Operation Code INQUIRY сведения об устройстве SCSI
mov byte[ebx+16],0
mov byte[ebx+17],0
mov byte[ebx+18],0
mov byte[ebx+19],36 ;Allocation Length запрашиваем размер данных
mov dword[ebx+20],0
mov dword[ebx+24],0
mov dword[ebx+28],0

READ10 и INQUIRY Функции сделал но не работают, наверно есть ньюансы по заполнению qTD, там нужны dt

Сообщение отредактировано: StasNewOs - 31.07.12, 03:56

[zakharo]

Tag может быть любым, да. Он нужен, чтобы после приема CSW система могла понять, к какому CBW он относится.
Что касается DT, то я уже говорил - для каждой endpoint надо хранить текущее значение DT. Все начинается с DT=0. После каждого принятого или переданного пакета значение DT меняется на противоположное. То есть, например, при INQUIRY мы должны поставить DT=0 для передачи CBW, DT=0 для приема данных и DT=1 для приема CSW. Для следующей команды с приемом данных будет DT=1 для CBW, DT=0 для данных и DT=1 для CSW. То есть значение DT меняется от пакета к пакету НЕЗАВИСИМО для каждой endpoit. Для отслеживания всех этих дел я у себя веду структуры-описатели конечных точек, которые состоят из адреса точки, максимальной длины пакета и текущего значения DT. После каждой транзакции новое значение DT я беру из последнего успешно выполненного qTD (его там может изменить контроллер - оно зависит от того, на сколько пакетов контроллер разобьет транзакцию: блоки данных для флешек - 512 байт, конечно, умещаются в одну транзакцию, но, например, сектора компакт-дисков имеют длину 2048 байт - тогда сам контроллер разбивает операцию на несколько транзакций). В общем. смотри п.4.10 описания EHCI. И не забыть это значение DT перед следующим использованием проинвертировать.
А еще после чтения всех конфигураций до выдачи первой команды SCSI надо давать SET_CONFIGURATION с параметром, взятым из bConfigurationValue дескриптора конфигурации, иначе флешка скорее всего работать не будет (некоторые работают, но это - скорее исключение). Есть граф состояний устройств USB, в соответствии с ним до команды SET_CONFIGURATION устройство находится в состоянии конфигурирования и имеет полное право не работать.

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

[StasNewOs]

А в конфигурации списки конечных точек, их нужно как то использовать, например in out для SCSI имеют какие то параметры. Мне кажется нужно ставить номер конечной точки в qTD, хотя там вреде некуда.
Ещё обычно после SetConfiguration идёт GetMaxLun зачемто.
SetConfiguration у меня прошло, тока почемуто bConfigurationValue=0 у меня.

Сообщение отредактировано: StasNewOs - 01.08.12, 04:32

[zakharo]

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

А в конфигурации списки конечных точек, их нужно как то использовать, например in out для SCSI имеют какие то параметры. Мне кажется нужно ставить номер конечной точки в qTD, хотя там вреде некуда.

А зачем по-твоему, в QH есть поле EndPt? П.3.6 спецификации EHCI.

GetMaxLun возвращает максимальный номер LUN в устройстве. Для флешек эта команда не имеет смысла - там все равно один Logic Unit. Поэтому она либо возвращает 0, либо не поддерживается вообще - устройство выставляет STALL. А вот для картридеров со многими окошками она имеет очень даже большой смысл. Обращение к разным окошкам картридера идет как к разным LUNам. А поскольку мы не знаем заранее, что за устройство подключено к порту, то спрашиваем еще и таким образом.

bConfigurationValue вполне может быть 0. Там важен сам факт прохождения команды SET_CONFIGURATION - это означает завершение этапа конфигурирования и переход в рабочий режим.

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

[StasNewOs]

В QH да есть EndPt ну а при INQUIRY или READ10 мы должны его запрлнять?
Я с конфигурированием разобрался и реализовал, кстати получается, что все устройства конфигурируются по одинаковому, а потом при работе с ним используются EndPt и уже идёт реализация второго персонального драйвера для конкретного устройства.

Сообщение отредактировано: StasNewOs - 01.08.12, 11:25

[zakharo]

Цитата StasNewOs @ 01.08.12, 11:02

В QH да есть EndPt ну а при INQUIRY или READ10 мы должны его запрлнять?

А как же.. Для каждой конечной точки делается свой QH. То есть как поле в памяти он может быть один, но для каждой bulk-транзакции он заполняется заново. Туда надо записать адрес устройства (ведь к USB можно подключить сразу много устройств), адрес конечной точки и максимальный размер пакета для этой конечной точки (это ответ на еще один твой вопрос - максимальный размер пакета в QH надо ставить из дескриптора EP, он не зависит от того, сколько тебе конкретно надо получить или передать за транзакцию).
Для транзакции типа bulk-out в QH записываются параметры bulk-out endpoint, для bulk-in - соответственно, параметры bulk-in endpoint.
А до сих пор ты работал c Control Endpoint, адрес которой - всегда 0, поэтому у тебя все проходило.

Добавлено 01.08.12, 11:38

Цитата StasNewOs @ 01.08.12, 11:02

Я с конфигурированием разобрался и реализовал, кстати получается, что все устройства конфигурируются по одинаковому, а потом при работе с ним используются EndPt и уже идёт реализация второго персонального драйвера для конкретного устройства.

Ну да. При начальном конфигурировании присваивается адрес и выясняется класс устройства, а затем начинает работать драйвер конкретного класса.

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

[StasNewOs]

Для INQUIRY в QH EndPt надо in 129 ставить, а она всегда =129 и out = 2 всегда?
А понял, прочитал usbmassbulk_10, кстати там всё так понятно стало, у in 8?h, так что не 129, а 1, вообще из всей инфы нужно брать из байта bEndpointAddress 4 бита и wMaxPacketSize, для in и out, к bulk больше ничего не пригодиться.
Никак не пойму как заполнить QH qTD для INQUIRY

Сообщение отредактировано: StasNewOs - 02.08.12, 04:43

[zakharo]

Старший бит в номере Endpoint означает направление. 1 - (похожа на букву I в слове IN) означает направление от устройства к хосту, 0 (как буква O в слове Out) - от хоста к устройству. В QH под адрес конечной точки отведено всего 4 бита. И при заполнении QH используются младшие 4 бита из номера. Таким образом, если номер in-endpoint = 129, т.е. 81h, в QH надо записать просто 1.
И, конечно, далеко не всегда номера конечных точек - такие, как у тебя. Но это не должно нас смущать - мы же берем их их дескриптора конфигурации.
Полные же номера конечных точек, вместе со старшим битом, используются только для сброса состояния STALL.

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

[StasNewOs]

У bulk всего две конечных точек и этот бит единственное отличие, у меня под рукой три разные флешки и у них в конфигурации тока две эти точки от bulk, мы прочитаем 4 бита для in и out, будем записывать их в QH, но как сформировать QH и qTD, для INQUIRY, это единственное, что мне нужно доделать, чтобы работать с флешкой.

Сообщение отредактировано: StasNewOs - 02.08.12, 12:34

[zakharo]

У меня есть флешка с тремя конечными точками (кроме 0-й). 3-я имеет тип INTERRUPT, зачем она нужна при протоколе Bulk-Only - мне непонятно. Поэтому из дескриптора конфигурации я вытаскиваю точки только типа BULK (специально проверяю тип), и, конечно, определяю IN или OUT по старшему биту номера.
В принципе, формирование QH и TD для bulk-транзакций не отличается от формирования для control. Ты указываешь параметры нужной конечной точки в QH и ставишь соответствующий тип транзакции в qTD. Про Data Toggle (DT) я уже объяснял. Начинается все с 0, а дальше строго чередуется (после успешных транзакций), независимо для каждой конечной точки.
Вот цепочка для 1-го Inquiry. Только QH и TD, без самих данных. Одна операция Bulk-out (посылка команды) и две - Bulk-in (прием данных и CSW). В конце написано, что именно получено в данных.

Скрытый текст

BULK_OUT
QH 6300:0C80 physaddr=00063c80
00063c80 02006101 40000000 00063d00
TD 0 6300:0D00 physaddr=00063d00
00000001 00000001 001f0080 00066800
00000000 00000000 00000000 00000000
BULK_IN
QH 6300:0C80 physaddr=00063c80
00063c80 02006201 40000000 00063d00
TD 0 6300:0D00 physaddr=00063d00
00000001 00000001 00240d80 00066000
00000000 00000000 00000000 00000000
BULK_IN
QH 6300:0C80 physaddr=00063c80
00063c80 02006201 40000000 00063d00
TD 0 6300:0D00 physaddr=00063d00
00000001 00000001 800d0d80 00066840
00000000 00000000 00000000 00000000

LUN0 Inquiry "JetFlashTS4GJF160 0.00"

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