Comments 12
хм… я вот в прнципе понимаю, можно запрограммировать хост контроллер и выполнить какую-то операцию, например прочитать DeviceDescriptor. А вот дальше что?
Нужны ведь драйвера устройств? Ну хотя бы некоторых классов устройств.
Даже простой HID класс не так просто сделать — так как нужно парсить ReportDescriptor и он может быть довольно сложным — некоторые мыши посылают репорт 4 байта, некоторые 5 или 6. У клавиатур так же заморочки — переменное число светодиодов LED или вот разный набор multimedia кнопок. А еще джойстики, трекболы, тачпады, тачскрины — и все это HID. Неужели вы все это реализовали?
А другие классы? Тот же Storage?
И вот еще неприятная часть в USB стеке — scheduler транзакций. Когда много устройств подключены через хаб все ходят доступа к шине и как их запросы уместить во фреймы и микрофреймы наиболее оптимальным образом?
В общем поражает объем работы, который нужно выполнить, чтобы система как-то зажила с этим…
Нужны ведь драйвера устройств? Ну хотя бы некоторых классов устройств.
Даже простой HID класс не так просто сделать — так как нужно парсить ReportDescriptor и он может быть довольно сложным — некоторые мыши посылают репорт 4 байта, некоторые 5 или 6. У клавиатур так же заморочки — переменное число светодиодов LED или вот разный набор multimedia кнопок. А еще джойстики, трекболы, тачпады, тачскрины — и все это HID. Неужели вы все это реализовали?
А другие классы? Тот же Storage?
И вот еще неприятная часть в USB стеке — scheduler транзакций. Когда много устройств подключены через хаб все ходят доступа к шине и как их запросы уместить во фреймы и микрофреймы наиболее оптимальным образом?
В общем поражает объем работы, который нужно выполнить, чтобы система как-то зажила с этим…
Spoiler alert!
KolibriOS WebSVN: USB HID, USB Storage
p.s. Мультимедиа-кнопки — это, как правило, «отдельное устройство» внутри «обычной» клавиатуры.
KolibriOS WebSVN: USB HID, USB Storage
p.s. Мультимедиа-кнопки — это, как правило, «отдельное устройство» внутри «обычной» клавиатуры.
В принципе, в анонсе заявлены были:
Клавиатуры (USB keyboard)
Мышки (USB mouse)
Флешки (USB flash disk / USB thumb-drive)
Хабы (USB hub)
В приведенном выше коде тоже кроме этого ничего нет.
Клавиатуры (USB keyboard)
Мышки (USB mouse)
Флешки (USB flash disk / USB thumb-drive)
Хабы (USB hub)
В приведенном выше коде тоже кроме этого ничего нет.
я не спорю, что работа проделана большая и героическая.
Но вот взять например HID:
mov edx, [esp+12]
push ebx; save used register to be stdcall
mov cx, word [edx+interface_descr.bInterfaceSubClass]
; 1b. For boot protocol, subclass must be 1 and protocol must be either 1 for
; a keyboard or 2 for a mouse. Check.
cmp cx, 0x0101
jz .keyboard
cmp cx, 0x0201
jz .mouse
; 1c. If the device is neither a keyboard nor a mouse, print a message and
; go to 6c.
DEBUGF 1,'K: unknown HID device\n'
jmp .nothing
То есть джойстики, тачскрины и прочее HID пока не работают.
Вот еще фрагмент:
; Parse the packet, comparing with the previous packet.
; For boot protocol, USB keyboard packet consists of the first byte
; with status keys that are currently pressed. The second byte should
; be ignored, and other 5 bytes denote keys that are currently pressed.
push esi ebx; save used registers to be stdcall
; 2. Process control keys.
; 2a. Initialize before loop for control keys. edx = mask for control bits
; that were changed.
mov ebx, [esp+20+8]
movzx edx, byte [ebx+device_data.packet]; get state of control keys
xor dl, byte [ebx+keyboard_data.prevpacket]; compare with previous state
У меня есть клавиатура у которой пакет выглядит не так. Формат другой. То есть она работать не будет.
Вся подлость USB вообще — чтобы убедиться в работоспособности системы нужно брать 50 разных моделей и тестировать.
За это я ее (USB) и не люблю. Вроде и стандарты есть, но многие их по своему интерпретируют и получаются странные вещи.
Поэтому я и говорю, что сделать USB — это нереально сложная задача. Героическая.
А проекту, конечно, пожелаю удачи.
Но вот взять например HID:
mov edx, [esp+12]
push ebx; save used register to be stdcall
mov cx, word [edx+interface_descr.bInterfaceSubClass]
; 1b. For boot protocol, subclass must be 1 and protocol must be either 1 for
; a keyboard or 2 for a mouse. Check.
cmp cx, 0x0101
jz .keyboard
cmp cx, 0x0201
jz .mouse
; 1c. If the device is neither a keyboard nor a mouse, print a message and
; go to 6c.
DEBUGF 1,'K: unknown HID device\n'
jmp .nothing
То есть джойстики, тачскрины и прочее HID пока не работают.
Вот еще фрагмент:
; Parse the packet, comparing with the previous packet.
; For boot protocol, USB keyboard packet consists of the first byte
; with status keys that are currently pressed. The second byte should
; be ignored, and other 5 bytes denote keys that are currently pressed.
push esi ebx; save used registers to be stdcall
; 2. Process control keys.
; 2a. Initialize before loop for control keys. edx = mask for control bits
; that were changed.
mov ebx, [esp+20+8]
movzx edx, byte [ebx+device_data.packet]; get state of control keys
xor dl, byte [ebx+keyboard_data.prevpacket]; compare with previous state
У меня есть клавиатура у которой пакет выглядит не так. Формат другой. То есть она работать не будет.
Вся подлость USB вообще — чтобы убедиться в работоспособности системы нужно брать 50 разных моделей и тестировать.
За это я ее (USB) и не люблю. Вроде и стандарты есть, но многие их по своему интерпретируют и получаются странные вещи.
Поэтому я и говорю, что сделать USB — это нереально сложная задача. Героическая.
А проекту, конечно, пожелаю удачи.
Спасибо за пожелания. Автор USB-подсистемы проводила тестирование в течении очень длительного времени, последние полгода было открытое тестирование. Если ваша клавиатура не работает — я думаю, стоит помочь разработке хотя бы баг-репортами.
Будет. При инициализации текущий драйвер выставляет Set_Protocol(Boot Protocol). Структура данных в Boot Protocol и Report Protocol может отличаться; если вы смотрели на пакеты, читая передачи по шине USB под управлением Windows или Linux, то вы видели структуру Report Protocol.
Вы совершенно правы, но несколько опережаете события. К сожалению, уместить всё в одну статью не представляется возможным из-за размера, поэтому о всех этих вещах я буду рассказывать в следующих частях.
Про планировщик транзакций будет раньше остального — это уровень поддержки каналов, так что будет либо в следующей статье вместе с кодом поддержки хост-контроллеров, либо через одну. Если вкратце — непериодические транзакции планирует сам контроллер в round-robin стиле и как-либо проконтролировать это невозможно. Для периодических транзакций планировщик действительно есть.
Из классов, не считая хабов, сейчас поддерживаются основные варианты HID и Storage. Про HID будет отдельная статья, если вкратце:
* для базовой функциональности мышек и клавиатур есть Boot Protocol, при использовании которого парсить Report Descriptor не нужно; прямо сейчас на svn лежит именно этот вариант, поддержку Report Protocol я написала наполовину и никуда ещё не коммитила, следите за обновлениями;
* HID класс неоднороден, поддержка мышек не зависит от поддержки джойстиков. В Report Descriptor каждое поле данных передачи снабжено комментарием Usage, описывающем назначение поля. Каждый подкласс устройств интерпретирует только «свои» поля, для поддержки мыши не нужно ничего знать о джойстике.
Про планировщик транзакций будет раньше остального — это уровень поддержки каналов, так что будет либо в следующей статье вместе с кодом поддержки хост-контроллеров, либо через одну. Если вкратце — непериодические транзакции планирует сам контроллер в round-robin стиле и как-либо проконтролировать это невозможно. Для периодических транзакций планировщик действительно есть.
Из классов, не считая хабов, сейчас поддерживаются основные варианты HID и Storage. Про HID будет отдельная статья, если вкратце:
* для базовой функциональности мышек и клавиатур есть Boot Protocol, при использовании которого парсить Report Descriptor не нужно; прямо сейчас на svn лежит именно этот вариант, поддержку Report Protocol я написала наполовину и никуда ещё не коммитила, следите за обновлениями;
* HID класс неоднороден, поддержка мышек не зависит от поддержки джойстиков. В Report Descriptor каждое поле данных передачи снабжено комментарием Usage, описывающем назначение поля. Каждый подкласс устройств интерпретирует только «свои» поля, для поддержки мыши не нужно ничего знать о джойстике.
Да, это поражает!
А я-то думал, что USB достаточно высокоуровневый протокол и железками обеспечивается. А, оказывается…
Спасибо за статьи!
P.S. Неужели за это время не могли ничего более щадящего с точки зрения программирования придумать?
А я-то думал, что USB достаточно высокоуровневый протокол и железками обеспечивается. А, оказывается…
Спасибо за статьи!
P.S. Неужели за это время не могли ничего более щадящего с точки зрения программирования придумать?
Rate Matching Hub (RMH), а контроллеру оставила только два порта, к одному из которых всегда подключён хаб. Назначение второго порта, к сожалению, мне выяснить не удалось.
Второй порт EHCI — Debug port. Многие лета моему слоупочению.
И спасибо за статьи, кстати, да.
Сейчас пытаюсь отреверсить-разобраться, как в ECHI на интеловском 5-м поколении подключаются/отключаются в BIOS USB в нотнике.
В даташитах написано как инициализировать, Tianocore — показывает как правильно.
Но вот как ОТКЛЮЧАЮТСЯ в EHCI отдельные USB порты — на каком этапе, в каком модуле — как-то не накопалось ничего, пока что в IdaPro копаюсь, но там чем дальше в лес, тем толще партизаны, конечно.
Sign up to leave a comment.
Поддержка USB в KolibriOS: что внутри? Часть 2: основы работы с хост-контроллерами