Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.145.156.46] |
|
Страницы: (51) [1] 2 3 ... 50 51 ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Я звметил, что тема работы с USB флешками под ДОС довольно часто поднимается.
Давайте в этой теме, что ли, будем делиться имеющейся информацией и опытом! Для начала расскажу о том, какие основные моменты я уяснил спустя пол года мороки с этим вопросом: есть еще много всего, но сейчас писать лень Мне удалось заставить работать USB флешки под ДОС на материнке с OHC хост контроллером. Так же есть опыт (были только пробы) работы с UHC контроллером. В частности, я тут видел, поднимался вопрос о том, почему UHC не работает с USB 2.0 устройствами. Отвечу: потому что на этой материнке установлен EHC контроллер. А в его состав входит несколько UHC контроллеров. И при подключенни устройства у порту специальная логика сама определяет, к какому контроллеру дать управление этим устройством. Ну так вот! Давайте сдесь задавать свои вопросы и обсуждать решения! P.S. Рекомендую почитать Кулакова "Программирование на аппаратном уровне 2-е издание", у него очень не плохо освещена тема работы с UHC контроллером. |
Сообщ.
#2
,
|
|
|
У меня задача такая - Необходимо распознавать USB Flash диски в DOS-е и поддерживать hot swapping без перезагрузки компа.
Спасибо за приведенные тобой ссылки. Придеться изучать документацию, хотья это не тривиальная задача. Сможешь ли ты поделится своими наработками по этому вопросу? |
Сообщ.
#3
,
|
|
|
Irakli911
Что имеется в виду под наработками??? Если исходники, то у меня они в виде сырых классов и без коментариев, а тестовая программа есть как экзешник... Все это адоптировано под OHC контроллер. В настоящий момент я перехожу к созданию полноценного драйвера под ДОС (в виде резидентной проги). Так что все что было, буду переписывать... А ты что-нибудь начинал? Если нет, то сначала почитай Кулакова или Агурова, а то без представления, чем оперирует контроллер в исходник без коментариев врубиться не получится В общем, я приложу класс, который работает с OHC контроллером и asm файлы с функциями для перехода в режим линейной адресации и чтения памяти далеко за 1-ым мегабайтом (это взято из книги Кулакова). Прикреплённый файлUSB_CLASS.zip (10.61 Кбайт, скачиваний: 1047) |
Сообщ.
#4
,
|
|
|
Ссылку взял. Пойду почитаю доки и через несколько дней опять появлюсь. Спасибо
|
Сообщ.
#5
,
|
|
|
Gerret, может, статью в FAQ напишешь?
|
Сообщ.
#6
,
|
|
|
Уже были мысли тока я ни разу не пробовал статьи писать...
Но я думаю, что когда я свой проект завершу, обязательно займусь |
Сообщ.
#7
,
|
|
|
Привет Garret, извиняюсь за задержку. Докумертацию по OHC и Агурова вроде освоил. Появилось масса вопросов. Во первых в ссылке USB_CLASS.ZIP не хватает несколько .h фаилов. Также не смог понять почему в конструкторе TOHCI написано PutToOpRegister(0x100,0), вроде в адресном пространстве со смещением 256 регистров нету. Тамже Off=0x210 - что это? Не очень понял назначение регистра HCCA.
Если можно выложи полную ссылку. Заранее спасибо |
Сообщ.
#8
,
|
|
|
Цитата Irakli911 @ не хватает несколько .h фаилов Потому, что я тебе дал только один класс, который, собственно, и работает с OHC контроллером. Цитата Irakli911 @ почему в конструкторе TOHCI написано PutToOpRegister(0x100,0) Это отключение Legacy Support. В самом конце документации про это написано. Цитата Irakli911 @ Тамже Off=0x210 - что это? Это смещение относительно начала области данных контроллера, в которую я складываю дескрипторы конечных точек и дескрипторы передачи для SETUP транзакций. Цитата Irakli911 @ Не очень понял назначение регистра HCCA. В этом регистре лежит адрес структуры HCCA. Про нее подробно написано в разделе 4.4 Host Controller Comunication Area. |
Сообщ.
#9
,
|
|
|
Крутая отечественная инфа по делу:
Павел Агуров. "Интерфейс USB. Практика использования и программирования" http://depositfiles.com/files/52364/156.rar.html или http://rapidshare.de/files/20318919/usb.zip.html |
Сообщ.
#10
,
|
|
|
Я из под ДОСа OHCI мучаю уже месяц, и, в принципе, многое понятно.
В спецификациях все разжовано, вот только проблема, что читать нуна, на английском не особо удобно, особенно не владея английским. И вот что не понятно имено мне: Я определяю наличие коннекта (по регистру HcRhPortStatus[NP]), включаю порт, проверяю питание и т.д. потом (интерфейс OHCI), наскока понял, надо послать запрос Get_Status, да? Посылаю. девайсы, питающиеся от собственного источника (например, винт с usb-интерфейсом) отвечают на запрос нормально. флэшки, супер линки и т.д., питающиеся от шины, на запрос Get_Status, возвращают DeviceNotResponding (При отсутствии вобще каких либо устройств на портах возвращается тот же ответ). И вот не понятно, то ли принудительно при обнаружении коннекта надо сбрасывать порт, а может запросы посылать не в той последовательности, послать, например, Set_Feature, ведь при этом запросе хаб посылает reset в соответствующий порт, а вдруг надо делать задержку. И еще один момент, для всего выше перечисленного использую Control transfer. Не затрагивает ли этот трансфер поле HCCAInterruptTable области HCCA, можно ли обойтись без использования этой таблицы? И вобще, каким макароном эта таблица работает? |
Сообщ.
#11
,
|
|
|
Цитата Barbosman @ И вот не понятно, то ли принудительно при обнаружении коннекта надо сбрасывать порт, а может запросы посылать не в той последовательности... Что подразумевается под сбрасыванием порта? Установка PortResetStatus бита? Если да, то надо обязательно. Цитата Barbosman @ потом (интерфейс OHCI), наскока понял, надо послать запрос Get_Status, да? А какое отношение интерфейс OHCI имеет к Get_Status? Get_status это вроде команда USB протокола... До установки адреса устройства можно запросить у него первые 8 байт дескриптора устройства, на этот запрос обязаны отвечать любые устройства. По поводу Get_Status не знаю, не использовал. Цитата Barbosman @ Не затрагивает ли этот трансфер поле HCCAInterruptTable области HCCA Нет не затрагивает. Цитата Barbosman @ можно ли обойтись без использования этой таблицы? Ну не использовать ее можно, но не определять ее адрес в регистре контроллера нельзя. Ее можно просто не заполнять. Цитата Barbosman @ И вобще, каким макароном эта таблица работает? Сам я ее не использовал, но насколько понял она используется для передач по прерываниям. Т.е. в ней лежат адреса дескрипторов конечных точек. Контроллер в определенное время (см. 3.3.2 Data Structures. Figure 3-4: Interrupt ED Structure) вытаскивает из таблицы адрес Interrupt ED и выполняет передачу. Дальше - ХЗ... не пробовал. P.S. Если что не так понял... извените P.P.S. С хабами я вообще пока не сталкивался |
Сообщ.
#12
,
|
|
|
ну по поводу Get_Status:
описалово этого запроса я взял из Агурова "Интерфейс USB", несмотря на то ,что там описывается UHCI (а у меня OHCI), оттуда взял коды этого запроса, оформил TD для пакета Setup, потом TD для приема считанной инфы, ну и TD для ответа (конца транзакции). С девайсиной, что питается от своего источника запрос прошел успешно, а с суперлинком, который мне как раз нужен - трабл. Т. е., насколько я понял мысль, последовательность при обнаружении коннекта следующая: сбросить порт установкой соответствующего бита в HcRhPortStatus[NP], потом послать ему Get_Descriptor, на что будут получены первые 8 байт стандартного дескриптора устройства, так получается? А как расшифровывать значения этих 8-ми байт? ну и в конце концов присвоить устройству адрес с помощью Set_Adress. правильно я понял? Добавлено эти 8 байт соответствуют первым 8-ми байтам стандартного дескриптора? Он то целых 18 весит |
Сообщ.
#13
,
|
|
|
Цитата Barbosman @ А как расшифровывать значения этих 8-ми байт? Странный вопрос для человека читавшего Агурова... (см. стр. 106 - Дескриптор устройства). Собственно самое ченное в этих 8-и байтах это максимальный размер пакета для 0-й конечной точки устройства. Вот последовательность, по которой я инициализирую устройства на шине USB: Шаг 1: Получаем 8 байт дескриптора устройства Шаг 2: Устанавливаем адрес устройства Шаг 3: Если надо, можно запросить полностью весь дескриптор устройства. Надо если у устройства может быть несколько конфигураций и для возможности считать строки с описанием изготовителя и продукта. Шаг 4: Запрашиваем первые 8 байт дескриптора конфигурации. Из него берем полную длину конфигурации устройства. (см. Агурова) Шаг 5: Запрашиваем всю конфигурацию устройства (на этот запрос пролучим все дескрипторы интерфейсов и конечных точек для данной конфигурации). Шаг 6: Из дескриптора интерфейса узнаем тип устройства и если он нам подходит то выполняем SET_CONFIGURATION в качестве параметра которого выступает байт bConfigurationValue из дескриптора конфигурации. Собственно SET_CONFIGURATION и есть так называемое конфигурирование (инициализация) устройства. P.S. Все эти запросы к конкретным USB контроллерам отношения не имеют. Они одинаковы и для UHC, и для OHC, и для EHC. P.P.S. А что такое суперлинк? |
Сообщ.
#14
,
|
|
|
ну, суперлинк, это возможно чисто жаргонное слово, употребляемое мной и некоторыми моими коллегами, это кабель типа host-to-host, тобишь связь двух компов через USB.
|
Сообщ.
#15
,
|
|
|
Цитата Gerret @ Вот последовательность, по которой я инициализирую устройства на шине USB: Шаг 1: Получаем 8 байт дескриптора устройства Шаг 2: Устанавливаем адрес устройства А разве Кулаков учит не наоборот??? |