"
Сейчас в современном мире информационных технологий без USB-кабеля просто не обойтись. Только представьте себе, как стало проще заряжать необходимые мобильные устройства, когда есть единый стандарт. В будущем планируется создать интерфейс, который использовался бы для питания более мощных, чем смартфоны и планшеты, устройств. USB Power Delivery – вот та технология, которую сейчас разрабатывают для обеспечения нужд всего человечества. Читать полностью »
Появившаяся в Интернете информация указывает на то, что скоро можно будет зарядить ноутбуки через порты USB.
Что лежит в основе этого революционного решения?
Одной из главных проблем для любителей и мелких компаний, занимающихся продажей «железок» с USB-портом, сегодня является USB Implementers Forum (USB-IF) — организация, занимающаяся разработкой спецификаций на шину USB; в ней принимают участие такие компании, как Intel, Microsoft и Hewlett-Packard.
Суть этой проблемы в следующем. Каждое продающееся устройство с USB требует сертификации на соответствие требованиям USB, для чего ему необходимо иметь ID вендора (vendor ID, VID) и ID изделия (product ID, PID). Крупные игроки любительского рынка — вроде Sparkfun или Adafruit — давно заплатили USB-IF за получение USB VID; вся беда в том, что и любому умельцу, смастерившему в своем гараже устройство с USB и надеющемуся продавать его — пусть и продастся от силы десяток-сотня штук — тоже приходится оплачивать его получение.
В качестве решения этой проблемы компания Arachnid Labs предложила интересную мысль: поскольку отдельные производители USB-устройств (вроде Microchip или FTDI) раздают некоторое количество своих USB PID бесплатно, можно было бы создать собственную некоммерческую организацию, которая бы купила один VID и раздавала PID своим участникам, занимающимся разработкой открытого аппаратного обеспечения. В результате, множество устройств, изготовленных любителями, получили бы статус USB-совместимых.
Читать полностью »
Пару дней назад купил я себе внешнюю звуковую карту e-mu 0204. Купил с рук, за 2 т.р. Владелец был счастлив, я то же. Оба думали, что надули друг друга. Стоит железка в магазине 4,5 т.р. Принес домой подрубил, звук сказочный. Но, обнаружился косяк. В непредсказуемые моменты времени слышны были тихие пощелкивания и перерывы звука. У меня отличные наушники ATH-SJ55. Соответствуют карточке по уровню, непонятно почему это вдруг началось. Разбираемся как исправить.
Читать полностью »
Рассказ об уровне взаимодействия с хост-контроллерами растянулся на две статьи и всё равно оставил за кадром некоторые детали — которые, как я надеюсь, заинтересованный читатель может восполнить непосредственно из исходников. Уровень поддержки каналов куда проще и в основном занят тем, что преобразует вызовы API для вышележащих уровней в нужную последовательность действий, включая блокировки, с нужным хост-контроллером.
Функция USBOpenPipe из API, названная usb_open_pipe в коде pipe.inc, открывает новый канал по указанным характеристикам канала и «родительскому» каналу, где записаны характеристики устройства. Для этого она:
*hci_pipe+usb_pipe, описывающих канал и выравненных на контроллеро-специфичную границу, вызовом контроллеро-специфичной функции usb_hardware_func.AllocPipe;*hci_gtd+usb_gtd, описывающих пустой дескриптор передачи и выравненных на контроллеро-специфичную границу, вызовом контроллеро-специфичной функции usb_hardware_func.AllocTD;usb_hardware_func.InitPipe, охраняемую мьютексом, глобальным для контроллера;
Контроллеро-специфичная инициализация последним действием добавляет новый канал в соответствующий список. Для управляющих каналов, равно как и для каналов массивов данных, есть всего один список, а вот для каналов прерываний нужно ещё выбрать один из нескольких вариантов.
Здесь в игру вступает планировщик scheduler.inc. Он как раз и выбирает один из списков каналов прерываний, а также убеждается, что для нового канала «достаточно места». Я напомню, что в каждом фрейме FullSpeed-шины под периодические передачи нельзя использовать более 90% времени, а в каждом микрофрейме HighSpeed-шины — более 80% времени.
Здесь я должна отметить, что если вы зачем-то пишете реализацию USB, которая должна работать в ваших условиях, на планировщике можно серьёзно сэкономить. Вам придётся в том или ином виде реализовать всё остальное, что описано в этой серии статей, но при отсутствии большой нагрузки можно вместо полного дерева обойтись всего одним списком каналов прерываний, обрабатываемым каждый фрейм/микрофрейм. Чуть более экономная схема, не слишком усложняющая реализацию, — один список каналов для каждого интервала обработки 1, 2, 4, 8, 16, 32 фреймов. Пока не нужно одновременно обрабатывать более одного устройства с большим трафиком на один хост-контроллер, такой подход ничем не уступает полноценному планировщику. Простая схема «сломается» в некоторых специфичных конфигурациях с двумя или более изохронными каналами FullSpeed-устройств или тремя или более изохронными каналами HighSpeed-устройств, но, быть может, никто и не будет запускать вашу реализацию в столь специфичных условиях?
Если же вы пишете реализацию USB, которая должна работать везде и всегда, планировщик вам тоже придётся написать.
Читать полностью »
Уровень поддержки хост-контроллеров, как я писала в общем обзоре, должен вызывать вышележащие уровни при наступлении некоторых событий и предоставлять функции, необходимые вышележащим уровням для работы.
Для удобства восприятия я буду рассказывать о различных элементах кода поддержки в том порядке, в котором они получают управление.
Подсистема USB запускается вызовом usb_init из init.inc в ходе загрузки системы.
К моменту запуска USB уже подготовлен список найденных PCI-устройств pcidev_list. USB-контроллеры опознаются среди всех PCI-устройств по коду класса, подкласса и интерфейса:
| Тип | Класс | Подкласс | Интерфейс |
|---|---|---|---|
| UHCI | 0Ch | 03h | 00h |
| OHCI | 0Ch | 03h | 10h |
| EHCI | 0Ch | 03h | 20h |
| XHCI | 0Ch | 03h | 30h |
usb_init проходит по списку PCI-устройств несколько раз, каждый раз выделяя USB-контроллеры.
Некоторые BIOS умеют обрабатывать USB-мыши, USB-клавиатуры и USB-флешки, предоставляя данные для операционных систем, не знающих про USB. Данные от мышей и клавиатур преобразуются в формат PS/2 и тем или иным способом доводятся до операционной системы так же, как если бы в системе существовала настоящая PS/2-мышь и/или клавиатура. USB-флешка представляется жёстким диском с точки зрения int 13h — такая поддержка встречается куда чаще поддержки мышей, ибо необходима для загрузки с флешек.
Операционная система может использовать любой режим процессора и самостоятельно обрабатывать любые прерывания. Чтобы BIOS в таких условиях всё же могла получать управление с предсказуемым окружением, ещё в районе 486-х (начиная со специальной версии i386SL, если точно) Intel придумала специальный режим процессора System Management Mode (SMM), в котором и работает BIOS, прерывая операционную систему. В SMM невозможно попасть средствами самого процессора; процессор попадает в этот режим, когда железо материнской платы подаёт специальный сигнал System Management Interrupt (SMI). USB-контроллеры, встроенные в чипсет, как правило, могут генерировать SMI вместо прерывания в зависимости от настроек.
Флешка Leef Bridge позиционируется китайским производителем как средство обмена файлами между обычными ПК и мобильными устройствами без использования проводов и (или) беспроводных соединений. Тем не менее, возможность и простого расширения памяти в тех устройствах, в которых SD-карты не предусмотрены, выглядит немаловажным фактором.
Механика простая: флешка одновременно имеет USB-коннектор, благодаря которому её можно подключить в обычный USB-порт, и micro USB, за счёт чего её можно вставить и в соответствующий порт смартфона или планшета (в котором нет OTG). Ключевым моментом является то, что оба порта записывают данные в одну и ту же память, так что доступ к файлам можно получить с любого устройства, куда флешка подключена в данный момент.
Видео-презентация под катом:
Читать полностью »
Добрый день, уважаемый Хабровчанин. Хочу рассказать тебе о своей работе, которой обычно занимаются студенты последних курсов технических ВУЗов (да-да, именно то нехорошее слово на букву «Д»).
Целью работы была разработка системы очувствления и управления мобильным роботом. За сими громкими словами стоит не очень большая, но для меня интересная задача.
Ближе к сути. Имеем микропроцессор, пачку датчиков, шаговый движок и необходимо, чтобы микропроцессор считывал данные с датчиков (акселерометры и гироскопы), отсылал данную информацию на ПК, принимал с компьютера команду управления движком, вращал движок.
Читать полностью »
Прежде, чем объяснять код поддержки хост-контроллеров, необходимо рассказать о некоторых принципах работы железа, а также об используемых структурах данных. Как я выяснила при написании текста, одна статья обо всём уровне поддержки хост-контроллеров получилась бы слишком большой, поэтому вторая часть цикла — которую вы сейчас читаете — рассказывает о том, что необходимо знать для понимания кода, а описание действий, происходящие в коде, я отложу до следующей части.
Хост-контроллеры оповещают софт о происходящих событиях, генерируя прерывания. Прерывание может прийти и оторвать процессор от текущей задачи в любой момент времени; это накладывает жёсткие требования на обработчик прерывания. Обработчик прерывания не может захватывать никакие блокировки — ведь вполне возможно, что прерванный код как раз завладел блокировкой и уже не сможет её освободить. Единственным исключением является вариант спинлока, запрещающий прерывания на время блокировки, но из-за глобальности эффекта спинлок стоит применять пореже и для очень коротких участков кода. На однопроцессорных конфигурациях такой вариант вырождается в пару cli/sti без собственно спинлока, на многопроцессорных внутри cli/sti остаётся обычный спинлок. Кроме того, контроллер прерываний во время обработки одного прерывания блокирует остальные с тем же или более низким приоритетом.
По этим двум причинам в KolibriOS обработчики прерываний от хост-контроллеров USB передают основную часть работы в выделенный под USB поток ядра, а сами ограничиваются сообщением хост-контроллеру «спасибо, сигнал принят». Сам USB-поток имеет наивысший приоритет, чтобы задумавшиеся пользовательские приложения не мешали обработке. Все функции вышележащих уровней, которые вызываются из уровня поддержки хост-контроллера, работают в контексте потока USB и, как следствие, вполне могут использовать примитивы синхронизации. Приятным побочным эффектом является автоматическая сериализация вызовов: ни обработчик завершения второй передачи из очереди канала, ни функция DeviceDisconnected не будут вызваны, пока не закончит работу обработчик завершения первой передачи из очереди канала, что есть логичное требование к API.
Поток USB также иногда просыпается для обработки событий, отложенных по времени. Пример, о котором я позже расскажу подробнее: после события подключения устройства нужно выждать 100 миллисекунд перед дальнейшей обработкой. В этом случае поток проснётся при обнаружении подключения устройства и запланирует следующее пробуждение через 100 миллисекунд, уже не связанное с пробуждением из-за прерывания.
Читать полностью »
Для тех, кто интересуется проектом KolibriOS, у нас очень хорошая новость — ровно 1 неделю назад в нашем проекте в ночных сборках появилась поддержка USB. В лучших традициях проекта, код полностью написан на ассемблере FASM. Причём он всё ещё влазит на одну дискету занимает 1MB, включая программы и игры. И, в отличие от нашего прародителя MenuetOS, у нас даже работает USB hot-plug. Разработчики QNX Demo Disk нервно курят в сторонке.
Читать полностью »