Хост контроллер что это
Что такое Хост контроллер?
Передачи больших объемов данных между устройством на шине USB и драйвером устройства делятся на множество пакетов хост-контроллером или драйвером HC.
Запросы устройства (управляющие передачи) к конечных точкам, используемым по умолчанию, являются специальными. Они состоят из двух или трех фаз: SETUP, DATA (oпциональная) и STATUS. Начтроечный пакет посылается устройству. Если есть фаза данных, то направление пакетов (или пакета) данных дается в настроечном пакете. Направление в фазе статуса противоположно направлению во время фазы данных. или IN если не было фазы данных. Оборудование хост-контроллера также дает регистры с текущим статусом корневых портов и изменений, которые случились с момента последнего сброса регистра изменения статуса. Доступ к этим регистрам дается через виртуализированных разветвитель, как и предполагается по спецификации USB [ 2]. Виртуальный разветвитель должен работать вместе с классом устройств-разветвителей, который описывается в 11 главе той спецификации. Он должен давать канал, испольщуемый по умолчанию, через который запросы устройств могут ему посылаться. Он возвращает набор дескрипторов, стандартных и специфичных для класса разветвителя. Он должен также давать канал прерываний, который сообщает об изменениях, произошедших на его портах. На данный момент для хост-контроллеров существуют две спецификации: Universal Host Controller Interface (UHCI; Intel) и Open Host Controller Interface (OHCI; Compaq, Microsoft, National Semiconductor). Спецификация UHCI разработана для уменьшения аппаратной сложности, требуя от драйвера хост-контроллера поддержки полного распределения передач для каждого кадра. Контроллеры типа OHCI гораздо более независимы, и дают более абстрактный интерфейс, выполняя много работы самостоятельно.
UHCI, или самый первый USB
Доброго времени суток, дорогой читатель! Меня просили написать про UHCI — хорошо, пишу.
Возможно, вам пригодиться эта статья, если, к примеру, вы не имеете достаточных навыков написания драйверов и чтение документации к хардвейру. Простой пример: хотите написать свою ОС для мини-ПК, дабы какая-нибудь винда или очередной дистрибутив линукса не загружали железо, и вы использовали всю его мощь исключительно в своих целях.
Что такое UHCI?
Думаю, чтобы еще раз не распыляться на тему что и зачем, просто оставлю ссылку на мою предыдущую статью про EHCI. Тык сюда
UHCI — Universal Host Controller Interface, работает как PCI-устройство, но, в отличии от EHCI использует порты заместо MMIO(Memory-Mapped-IO).
Термины, которые будут использованы далее
Типы передачи данных
Isochronous — изосинхронная передача, которая имеет заданную частоту передачи данных. Может быть использована, к примеру, для USB-микрофонов и т.п.
Interrupt — Небольшие, спонтанные передачи данных с устройства. Тип передачи прерывания поддерживает устройства, которые требуют предсказуемого интервала обслуживания, но не обязательно обеспечивают предсказуемый поток данных. Обычно используются для таких устройств, как клавиатуры и указательные устройства, которые могут не выдавать данные в течение длительных периодов времени, но требуют быстрого ответа, когда у них есть данные для отправки.
Control — Тип передачи информации о состоянии устройства, состоянии и конфигурации. Тип передачи Control используется для обеспечения канала управления с устройств Host to USB. Control-передачи всегда состоят из фазы настройки и нуля или более фаз данных, за которыми следует фаза состояния. Крайне важно, чтобы передача управления в заданную конечную точку обрабатывалась в режиме FIFO. Если управление передается на одну и ту же конечную точку, чередование может привести к непредсказуемому поведению.
Bulk — тип передачи массивов данных. Используется, к примеру в MassStorage-устройствах.
Вот так выглядит распределение 1мс времени — обработка одного фрейма.
Распределение времени
Контроллер хоста поддерживает доставку данных в реальном времени, генерируя пакет Start Of Frame (SOF) каждые 1 мс. SOF-пакет генерируется, когда истекает счетчик SOF в хост-контроллере (рис. 3). Контроллер хоста инициализирует счетчик SOF для времени кадра 1 мс. Могут быть внесены небольшие изменения в это значение (и, следовательно, период времени кадра) путем программирования регистра изменения SOF. Эта функция позволяет внести незначительные изменения в период времени кадра, если это необходимо, для поддержания синхронизации в реальном времени во всей системе USB.
Контроллер хоста включает в себя номер кадра в каждом SOF-пакете. Этот номер кадра однозначно определяет период кадра в реальном времени. Условие окончания кадра (EOF) возникает в конце временного интервала 1 мс, когда хост-контроллер начинает следующее время кадра, генерируя еще один SOF-пакет с соответствующим номером кадра. В течение периода кадра данные передаются в виде пакетов информации. Период времени кадра строго соблюдается хост-контроллером, а пакеты данных в текущем кадре не могут выходить за пределы EOF (см. Главу 11 в спецификации USB). Контроллер хоста поддерживает синхронизацию передачи данных между кадрами в реальном времени, привязывая номер кадра к выполнению конкретной записи в списке кадров. Счетчик кадров хост-контроллера генерирует номер кадра (11-битное значение) и включает его в каждый пакет SOF. Счетчик программируется через регистры и увеличивается каждый период кадра. Контроллер хоста использует младшие 10 бит номера кадра в качестве индекса в списке кадров с 1024 фреймами, который хранится в системной памяти. Таким образом, поскольку счетчик кадров управляет выбором записи из списка кадров, хост-контроллер обрабатывает каждую запись в списке в заданный период кадра. Контроллер хоста увеличивается до следующей записи в списке кадров для каждого нового кадра. Это гарантирует, что изохронные передачи выполняются в определенном кадре.
UHCI структуры
Тут всё точно так же, как и с EHCI. Пример запросов к HC:
Настройка и доступ к UHCI
И так, как я уже и сказал ранее, UHCI работает через порты, значит от PCI нам надо узнать базу регистров UHCI.
По смещению 0x20 лежит 4 байта — IO Base. Относительно IO Base мы можем воспользоваться следующими регистрами:
Регистры UHCI
Структуры
Frame List Pointer
Transfer Descrptor
TD CONTROL AND STATUS
TD Token
Queue Head
Инициализация и настройка HC:
Запросы к конечным точкам и управляющие запросы:
14.2 Хост-контроллеры
Пакет SOF используется для синхронизации начала кадра и отслеживания количества кадров. Пакеты передаются с каждым кадром, как от хоста к устройству (исходящие), так и от устройства к хосту (входящие). Передачи всегда инициируются хостом (запрошенные передачи). В силу этого может быть только один хост на шине USB. Каждая передача пакета имеет период статуса, в котором сторона, принимающая данные, может возвратить ACK (подтверждение приема), NAK (повтор), STALL (условная ошибка) или ничего (потерянный период данных, недоступное устройство или отсоединение). Раздел 8.5 Спецификации USB детально описывает пакеты. На шине USB могут произойти четыре различных типа передач: управляющая, основная, прерывание и изохронная. Типы передач и их характеристики описаны ниже (подраздел `Каналы’).
Передачи больших объемов данных между устройством на шине USB и драйвером устройства делятся на множество пакетов хост-контроллером или драйвером HC.
Запросы устройства (управляющие передачи) к конечных точкам, используемым по умолчанию, являются специальными. Они состоят из двух или трех фаз: SETUP, DATA (oпциональная) и STATUS. пакет посылается устройству. Если есть фаза данных, то направление пакетов (или пакета) данных дается в настроечном пакете. Направление в фазе статуса противоположно направлению во время фазы данных. или IN если не было фазы данных. Оборудование хост-контроллера также дает регистры с текущим статусом корневых портов и изменений, которые случились с момента последнего сброса регистра изменения статуса. Доступ к этим регистрам дается через виртуализированных разветвитель, как и предполагается по спецификации USB [ 2]. Виртуальный разветвитель должен работать вместе с классом устройств-разветвителей, который описывается в 11 главе той спецификации. Он должен давать канал, используемый по умолчанию, через который запросы устройств могут ему посылаться. Он возвращает набор дескрипторов, стандартных и специфичных для класса разветвителя. Он должен также давать канал прерываний, который сообщает об изменениях, произошедших на его портах. На данный момент для хост-контроллеров существуют две спецификации: Universal Host Controller Interface (UHCI; Intel) и Open Host Controller Interface (OHCI; Compaq, Microsoft, National Semiconductor). Спецификация UHCI разработана для уменьшения аппаратной сложности, требуя от драйвера хост-контроллера поддержки полного распределения передач для каждого кадра. Контроллеры типа OHCI гораздо более независимы, и дают более абстрактный интерфейс, выполняя много работы самостоятельно.
14.2.1 UHCI
Каждая передача состоит из одного или большего количества пакетов. Драйвер UHCI разделяет большие объемы передач на множество пакетов. Для каждой передачи, за исключением изохронных передач, формируется QH. Для каждого типа передачи эти QH объединяются в QH для этого типа. Изохронные передачи выполняются в первую очередь из-за фиксированных требований к устойчивости и непосредственно ссылается по указателю на список кадров. Последний изохронный TD ссылается на QH для передачи прерываний для этого кадра. Все QH для передач прерываний указывают на QH для управляющих передач, которые, в свою очередь, указывают на QH для основных передач. Следующая диаграмма дает графическое представление этого:
Это приводит к следующему сценарию, запускаемому в каждом кадре. После получения указателя на текущий кадр из списка кадров контроллер сначала выполняет TD для всех изохронных пакетов в этом кадре. Последний из этих TD ссылается на QH для передач прерываний для этого кадра. Хост-контроллер затем спускается от этого QH к QH для отдельных передач прерываний. После завершения работы этой очереди QH для прерванных передач будет отсылать контроллер на QH для всех управляющих передач. Он будет выполнять все под-очереди, здесь запланированные, за которыми следуют все передачи, поставленные в очередь в массовые QH. Для облегчения обработки законченных или завершившихся неудачно передач аппаратурой генерируется различные типы прерываний в конце каждого кадра. В последнем TD для передачи бит Interrupt-On Completion (прерывание при завершении) устанавливается драйвером HC для вызова прерывания после окончания передачи. Прерывание ошибки устанавливается, если TD достиг своего максимального количества ошибок. Если в TD установлен бит обнаружения короткого пакета, и передается пакет, размером меньшим, чем установлено, устанавливается это прерывание для оповещения драйвера контроллера о завершении передачи. Задачей драйвера хост-контроллера является нахождение того, какая передача была завершена или выдача ошибки. При вызове прерывания вспомогательная подпрограмма найдет все завершенные передачи и вызовет их подпрограммы.
Более детальное описание находится в спецификации на UHCI.
14.2.2 OHCI
framelist interruptisochronous control bulk
Распределение, выполняемое хост-контроллером в каждом кадре, имеет следующий вид. Контроллер сначала выполняет очереди непериодичного управления и обычную очередь, до момента времени, устанавливаемого драйвером HC. Затем выполняются прерванные передачи для этого количества кадров, используя младшие пять бит номера кадра в качестве индекса в уровне 0 дерева прерываний ED. В конце этого дерева подключаются изохронные ED и они выполняются последовательно. Изохронные TD содержат номер первого кадра, с которого должна начаться передача. После выполнения всех периодических передач, снова обрабатываются управляющая и обычная очереди. Периодически вызывается подпрограмма обслуживания прерываний для обработки очереди выполненного и вызова соответствующих функций для каждой передачи и перепланирования изохронных конечных точек и прерываний.
Более детальное описание есть в спецификации OHCI. Средний уровень услуг дает доступ к устройству в смысле управления и отслеживает ресурсы, используемые различными драйверами и уровнями услуг. Уровень отвечает за следующие вопросы:
Информация о настройке устройства
Каналы коммуникаций с устройством
Распознавание, подключение и отключение от устройства.
USB Host контроллер VinculumII. Запись на Flash.
Что такое USB Host контроллер?
Связь по USB происходит по принципу Главный-Подчинённый. В качестве подчиненных (USB Slave) обычно выступают периферийные устройства такие ка флешки, принтеры, клавиатуры, разрабатываемые электронщиками устройства и прочее. В качестве Главного (USB Host) обычно выступают компьютеры.
Если нам нужно передать информацию от нашего устройства на компьютер, то для реализации USB протокола подойдут как внешние микросхемы преобразователей, так и собственные средства самого контроллера. Но вот если данные нужно передать на флешку, то тут уже необходимо воспользоваться USB-Host контроллером. Можно воспользоваться контроллерами с внутренним USB-Host (например PIC24), ну или воспользоваться специальной микросхемой. Одну такую микросхему и рассмотрим — FTDI VinculumII.
Здесь хотелось бы поподробнее остановиться на мультиплексоре выводов микросхемы. Он позволяет подключать интерфейсные линии от различных протоколов к различным ногам контроллера (например одну и туже линию можно подключить с разных сторон контроллера). Это очень упрощает разводку платы. Да и к тому же если каждую интерфейсную линию выводить на отдельную ногу, то понадобилось бы слишком много ног, учитывая обилие интерфейсов в данном контроллере. Второй особенностью мультиплексора является работа с портами ввода-вывода, которые можно настроить не только как вход/выход, но и установить рабочий ток вывода, Pull-up или Pull-down, и даже Триггер Шмидта.
Что же имеем в сухом остатке. Отличная микросхема имеющая большОе количество различных интерфейсов, позволяющая построить различные комбинации преобразователей (мостов) интерфейсов. Главная особенность микросхемы наличие USB-Host, позволяющей работать с флешками.
И вот теперь, когда мы такие радостные, думаем сколько удивительных девайсов можно на ней сделать, пора вкусить правду-матку.
Первый сюрприз который нас ожидает — микросхема поставляется БЕЗ ПРОШИВКИ (NOTE: VNC2 devices are supplied unprogrammed). Для того что прошить микросхему необходим специальный VNC2 Debug Module. Здесь есть выбор либо купить фирменный (около 1100 руб), или же изготовить самостоятельно, ибо схема есть в даташите. Я решил взять готовый модуль (хорошо что деньги не мои ;)))
Выглядит вот так.
Тут нужно упомянуть еще один момент — модуль имеет выходной разъем PBS-2.0, а на своей плате я использовал более родной PLS-2.54. Поэтому пришлось изготовить небольшой переходник.
Изолентой заклеен один маленький, но ОЧЕНЬ мерзкий светодиодик.
Сюрприз номер два — микруха работает на собственной операционной системе реального времени (RTOS VOS), соответственно и все прошивки для нее необходимо писать с использованием этой RTOS.
Сюрпризик номер три — напрямую работать с ресурсам и контроллера не возможно. Чтобы обратиться к чему либо необходимо использовать API-функции и драйверы, поставляемые производителем в закрытом виде. Все что нам доступно — это файлы инклудов, в которых можно посмотреть какие есть функции и как к ним обратиться.
Ну и самый большой сюрприз (и самый большой минус) это среда разработки (IDE). Более убогой, тупой, и неудобной среды я не видел уже давно. Если бы компания FTDI располагалась в России, то «программистами» там бы работали внучатые племянники главного бухгалтера и начальника отдела кадров, этакие «супер-пупер-школоло-программеры». Это отличный пример того как хорошую аппаратную часть наглухо губит программное обеспечение. Сам от себя не ожидал сколько новых матерных оборотов могу я придумать пока не увидел ЭТО IDE.
Плюсуем сюда еще кучу мелких и тупых недочетов на которые уже тупо забиваеш со временем.
Вот такая вот «среда разработки».
Просто эксперимент.
Перед началом хотелось рассказать еще об одной забавной фиче. Не буду рассказывать как я дошел до проведения данного опыта, но я решил проверить реальную частоту работы ядра микросхемы.
Для примера возьмём контроллер PIC16F876A, с внешним кварцем на 16 МГц. Как известно PIC16 делит внешнюю частоту на 4. Получаем частоту работы ядра — 4 МГц.
Закинем в контроллер программу-мигалку:
Подключив осциллограф к RB2 получим вот такую картинку.
Частота переключений светика — 666653 Гц. Получается что на переключение требуется 6 тактов, Ну или 24 относительно кварца на 16 МГц.
Тот же самый опыт проведем с VinculumII.
Внешний кварц 12 МГц. Внутренняя частота 48 МГц.
Программка-мигалка:
Получаем частоту переключений светика — 126142 Гц. Уж не знаю делит ли VinculumII частоту или нет, но получается что относительно внутренней частоты в 48 МГц на мигалку требуется 380 тактов О_о. Даже если рассчитывать относительно внешнего кварца в 12 МГц то потребуется 95 тактов. Это просто «ППЦ» какой-то.
После данного опыта отпал вопрос «Почему на такой большой скорости работы минимальная функция временной задержки 1 мС?».
Так что не только «средство разработки» тормозное, но и сам контроллер, по крайней мере в вопросе выполнения программы. Возможно аппаратные средства интерфейсов не такие тормознутые.
Пишем Firmware.
Первоначально я бы посоветовал пройти на сайт http://www.ftdichip.com/ и накачать оттуда даташитов, апнотов, примеров и прочего. Оттуда же тянем Vinculum II Toolchain 2.0 (SP1).
Для первоначального вкатывания в тему разберем процесс создания нового проекта и опробуем процесс записи на флешку на примере HelloWorld.
Для начала рассмотрим процесс создания нового проекта.
Во вкладке New Project указываем Название проекта, Папку для сохранения, И название прибора (допустим).
На вкладке Driver подключаем необходимые драйвера — USBHost2, GPIO Port A, FAT File System, BOMS (USBHost 2), stdio, string.
А вот и самая интересная вкладка IOMUX — управление мультиплексором портов. Выводы USB портов и питания помечены серым и не могут быть изменены. А вот линии портов или же каких-нибудь интерфейсов могут быть распределены по соответствующим ногам микросхемы.
Для примера закинем PORT_A.0 на 23 ногу, а PORT_A.2 на 31. Обе ноги настроим на выход (к ним подключены светодиоды) и подключим Pull-Up. Кроме направления здесь также можно задать его рабочий ток, скорость переключения, триггер Шмидта, подтяжки к питанию.
ВАЖНО. Лучше всего сразу все настроить правильно и не открывать больше данного Wizard’а. Так как если переоткрыть программу и зайти сюда опять, то все настройки портов сбрасываются и придется все настраивать заново. ХОТЯ ВСЕ ЭТИ НАСТРОЙКИ СОХРАНЯЮТСЯ В ОТДЕЛЬНЫЙ ФАЙЛ.
На вкладке Kernel ничего не трогаем. Объяснение здешних параметров есть в указанных ранее русскоязычных статьях.
Один момент — параметр CPU Speed устанавливает внутреннюю частоту микрухи. Основное назначение снижения внутренней частоты — это снижение тока потребления.
На вкладке Threads опять же ничего не трогаем.
Так как внутренняя RTOS многозадачная, то тут можно создать потоки и настроить из приоритет.
На вкладке Summary отображается результат всех наших действий.
Нажимаем кнопку Finish.
Если по какой то причине вы решите все же еще раз попасть в Wizard, то это можно сделать нажав кнопку Modify на панели File.
После того как отработает Wizard в окне Project Manager (слева) отобразиться куча файлов драйверов, автоматически подключенных к проекту. Здесь нас интересуют 3 последних файла.
В файле Project_2_iomux.c хранятся настройки портов.
В файлах Project_2.h и Project_2.c и будет содержаться наша программа.
Открыв файл Project_2.c мы увидим ОЧЕНЬ много автоматически сгенерированного кода, созданного на основе настроек Wizard’a. Если вкратце то автоматом создаются функции настройки RTOS, создания потоков, настройка периферии, работы с драйверами. Некоторое объяснение можно найти в упомянутых статьях.
ВАЖНО: Important: Sections between markers «FTDI:S*» and «FTDI:E*» will be overwritten by the Application Wizard.
Это означает, что нельзя ничего писать между тегами «/* FTDI:S* */» и «/* FTDI:E* */» ибо все что находится между ними может в любой момент переписано Wizard’ом. По личному опыту скажу что не только им — я так однажды большого куска кода недосчитался, хотя wizard я не запускал и код был расположен за пределами данных тегов.
Сейчас нас интересует место в конце файла.
Именно в этой функции будет располагаться наш код. Название функции firmware() может быть и другим, оно указывается в wizard’е на вкладке Threads в столбце function.
Для начала переопределим переменную tx_buf, заменив на:
Ну вот потому что надо мне записывать по 65 байт )))). Вы можете это и не делать.
На основе примера HelloWorld запишем следующее содержание функции. От оригинала она будет отличаться только работой со светодиодами и дополнительными комментариями.
Ах да! Тут нас ожидает первый прикол – хотя мы и настроили направление выводов без команды:
они останутся работать на вход. И ДА это не опечатка 0-вход, 1-выход.
Компилируем, запускаем, проверяем, радуемся процессу, проверяем более углубленно, недоумеваем, тупим, разбираемся.
А разбираться приходится вот в чем — если подключить флешку и дождаться прохождения 1 цикла записи, и сразу отключить, то выясняется что файл создался только вот записей в нем нет. После десяти таких проверок файл был по-прежнему пуст.
Пробуем держать флешку дольше, процесс контролируем по светику или по осциллографу.
Как видно из рисунка — после компиляции (первый широкий импульс), было проделано ПЯТЬ записей в файл. НО открыв файл в нем обнаружилось только ЧЕТЫРЕ записи.
Можно конечно долго рассказывать как именно я извращался над программой, но не буду. Важно то, что удалось выяснить. А именно то не записывается именно первая строчка, а точнее она записывается только при следующем проходе цикла (это удалось выяснить только запись номера строки в файл). Опять же путем долгих и неистовых пыток программно-аппаратных средство получилось что хоть как то гарантировать только путем ПОВТОРНОГО ПЕРЕМОНТИРОВАНИЯ BOMS. Однако хоть это и редкостная тупость, но пришлось добавить в код вот такие вот две строки:
Ок! С тупостью разобрались, переходим к маразму.
Для записи информации в файл существует несколько функций. Одна из них — fwrite() — была рассмотрена в примере. Но дабы познать все прелести форматированного вывода строк в библиотеке имеется такая замечательная функция как fprintf(), кстати именно с ее помощью удалось вывести нумерованные строки и определить «тупость». Эта функция так же была подвержена «тупости», но сейчас не об этом.
Индикация процесса записи была сделана тоже не просто так! Чисто эксперимента ради, было записано время записи функцией fwrite() и fprintf(), дабы определить самую быструю (потому что так надо)))).
Первый график показывает процесс записи с помощью функции fwrite().
Как видно все пики одинаковые и длительность записи (65 байт) составляет 4-6 мС. Для сравнения широкий импульс слева это тот самый импульс в 100 мС в конце цикла.
Вторая группа графиков показывает процесс записи с помощью функции fprintf() (те же 65 байт).
Вот тут то маразм крепчает. Из графиков видно, что импульсы записи не равномерны, каждый пятый импульс в 8.5 раз шире других. А именно обычный процесс записи длится 300 мС. А каждый пятый цикл записи длится
2.5 СЕКУНДЫ. Повторюсь за один цикл записывается строка длинной 65 байт. Для сравнения импульс слева это тот самый импульс в 100 мС в конце цикла.
Что это за маразм такой и как он лечится я так и не понял, скажу только то что эти опыты повторялись неоднократно и с различным временем подключения флешки. Результаты были идентичные.
Вот так вот весело и неоднозначно происходит запись информации на флешку с помощью микросхемы VinculumII.
Еще небольшая ложка дегтя в бочку дегтя!
В другом примере обработка подключения флешки производилась только в начале программы и больше туда не возвращалась — в итоге повторно вставив флешку ничего не происходило. Чтобы добиться от этого примера хоть какой то внятной работы пришлось в конец программы добавить варварский сброс программы при извлечении флешки (vos_reset_vnc2();).
Так же чего мне никак до сих пор не удалось добиться — так это передачи от SPI_Slave, хотя прием вроде работает. Опять же в примерах SPI_Slave описан только для приема, а для передачи по SPI есть пример только для SPI_Master. От Slave не удалось добиться хоть какого нибудь дерганья ножками. Пока буду обходиться без него, ибо задачи позволяют.
Так что приводимые производителем примеры можно рассматривать ТОЛЬКО КАК ОЗНАКОМИТЕЛЬНЫЕ.
Вот такой вот обзор!
Казалось по описанию — мощная микросхема с кучей всяких крутых фишек, а на деле оказывается не все так просто.