Texas instruments ohci compliant ieee 1394a host controller что это

9

texas instruments ohci compliant ieee 1394a host controller что это такое

Вот так, вы сможете исправить ошибки, связанные с ohci1394.sys

Информация о файле ohci1394.sys

Процесс 1394 OpenHCI Port Driver или AGERE OHCI Compliant IEEE (версия 1394 Host Controller) или Texas Instruments OHCI Compliant IEEE (версия 1394 Host Controller) принадлежит программе AGERE OHCI Compliant IEEE (версия 1394 Host Controller) или Texas Instruments OHCI Compliant IEEE (версия 1394 Host Controller) или VIA OHCI Compliant IEEE (версия 1394 Host Controller) или OHCI Compliant IEEE (версия 1394 Host Controller) или 1394 OHCI Compliant Host Controller (Legacy) или NEC FireWarden OHCI Compliant IEEE (версия 1394 Host Controller) от Microsoft (www.microsoft.com).

Важно: Некоторые вредоносные программы маскируют себя как ohci1394.sys, особенно, если они расположены не в каталоге C:\Windows\System32\drivers. Таким образом, вы должны проверить файл ohci1394.sys на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера.

Комментарий пользователя

Лучшие практики для исправления проблем с ohci1394

Если у вас актуальные проблемы, попробуйте вспомнить, что вы делали в последнее время, или последнюю программу, которую вы устанавливали перед тем, как появилась впервые проблема. Используйте команду resmon, чтобы определить процесс, который вызывает проблемы. Даже если у вас серьезные проблемы с компьютером, прежде чем переустанавливать Windows, лучше попробуйте восстановить целостность установки ОС или для Windows 8 и более поздних версий Windows выполнить команду DISM.exe /Online /Cleanup-image /Restorehealth. Это позволит восстановить операционную систему без потери данных.

ohci1394 сканер

Security Task Manager показывает все запущенные сервисы Windows, включая внедренные скрытые приложения (например, мониторинг клавиатуры или браузера, авто вход). Уникальный рейтинг надежности указывает на вероятность того, что процесс потенциально может быть вредоносной программой-шпионом, кейлоггером или трояном.

Бесплатный aнтивирус находит и удаляет неактивные программы-шпионы, рекламу, трояны, кейлоггеры, вредоносные и следящие программы с вашего жесткого диска. Идеальное дополнение к Security Task Manager.

SpeedUpMyPC бесплатное сканирование, очистка, восстановление и оптимизация вашей системы.

Архитектура ЭВМ

Компоненты ПК

Интерфейсы

Мини блог

Самое читаемое

Как рассчитать количество дезинфицирующего средства на помещение repair-school.com. Подшипник роликовый конический размеры: подбор подшипников по размерам sf2v.ru.

Шина IEEE 1394 — FireWire

«Открытый» хост-контроллер IEEE 1394 — OHCI

Общая информация об «открытом» хост-контроллере IEEE 1394 — OHCI

Со стороны шины 1394 хост — узел с контроллером OHC — выглядит как обычный узел шины, способный выполнять функции мастера циклов и диспетчера изохронных ресурсов. Контроллер позволяет хосту быть инициатором любых транзакций шины 1394 и отвечать на любые транзакции, адресованные узлу хоста.В адресном пространстве этого узла расположены архитектурные регистры CSR и память конфигурации; большая часть пространства доступна для обращений в виде обычных транзакций шины. Часть пространства узла может отображать пространство физических адресов памяти хоста. Часть обращений к хосту может отрабатываться исключительно аппаратными средствами контроллера; остальные обращения хост отрабатывает программно. Принимаемые пакеты запросов для программной отработки OHC своими каналами DMA помещает в буферы, размещенные в памяти хоста. Пакеты ответов программа размещает в других буферах, из которых OHC организует их передачу в шину, опять же с помощью каналов DMA.

Для асинхронных транзакций контроллер обеспечивает чтение пакетов из системной памяти хоста и их передачу в шину; пакеты, принимаемые из шины, контроллер записывает в системную память. Обмен производится с помощью каналов DMA. Контроллер может функционировать и как шинный мост, аппаратно отрабатывая запросы транзакций чтения и записи шины 1394 как обращения к пространству памяти хоста.

Для изохронных операций OHC может исполнять роль мастера циклов, синхронизируясь от внутреннего генератора синхронизации или (необязательно) от внешнего источника. Если OHC не исполняет роль мастера циклов, то он поддерживает синхронизацию внутреннего таймера циклов с таймером узла-мастера циклов (по приему пакетов начала цикла). Для изохронных операций OHC имеет два контроллера DMA — для приема и для передачи данных. Каждый из этих контроллеров может поддерживать до 32 каналов DMA, называемых контекстами DMA. Передающий контроллер в каждом цикле может передавать данные из каждого контекста для связанного с ним изохронного канала. Принимающий контроллер способен в каждом цикле принимать данные в каждый контекст из связанного с ним канала. Кроме того, один из принимающих контекстов может быть настроен на прием данных из множества каналов.

По обнаружении сброса на шине OHC автоматически очищает все очереди асинхронных пакетов для передачи; прием пакетов не прерывается, но в потоке пакетов запросов появляется маркер, индицирующий факт сброса. Новый физический идентификатор узла (PHY_ID), получаемый от PHY, контроллер записывает в соответствующий регистр. Контроллер возобновит асинхронные передачи только по указанию программы, при этом повторное использование старых запросов в общем случае невозможно: физический идентификатор узла назначения может измениться. Изохронный прием и передача по сбросу не прекращаются — они возобновляются сразу по завершении инициализации.

Устройство контроллера OHC

Упрощенная структурная схема OHC приведена на рисунке.

Интерфейс системной шины (Host Bus Interface) обеспечивает взаимодействие с контроллером в двух режимах:

Контроллеры DMA обеспечивают обмен данными между шиной и системной памятью. В OHC имеются семь типов контроллеров DMA:

равляющих работой канала и выборкой запросов из списков, расположенных в системной памяти. Контроллеры асинхронной передачи и приема имеют отдельные контексты для запросов и ответов шинных транзакций. Контроллеры изохронного приема и передачи могут иметь до 32 контекстов каждый. Назначение и работа контроллеров подробно описано ниже.

LINK-уровень OHC передает пакеты из FIFO-буферов передающих каналов и отдает в FIFO принятые пакеты с корректным адресом, предназначенные данному узлу. Уровень выполняет следующие действия:

Буферы FIFO, находящиеся между каналами DMA и LINK-уровнем, выполняют промежуточную буферизацию данных, считываемых из системной памяти для передачи в шину и принятых из шины для записи в память. Буферы FIFO обеспечивают и согласование выравнивания данных, побайтного для хоста и поквадлетного для шины 1394. При необходимости буферы FIFO вставляют байты-заполнители, выравнивающие данные до границ квадлетов. Переполнение (overflow) или переопустошение (underrun) буферов (по вине интерфейса системной шины и памяти), приводящее к потерям принимаемых или передаваемых пакетов, контролируется аппаратными средствами OHC.

Буферы могут «на лету» выполнять преобразование форматов представления квадлетов. Шина IEEE 1394 и, соответственно, LINK-eровень работают с квадлетами, представленными в формате Big Еndian (старший байт передается первым). Передача данных через хост-интерфейс может выполняться по выбору:

Для поддержки функций управления OHC имеет 64-битный регистр уникального идентификатора (GUID, он же IEEE EUI-64), автоматически загружаемый из энергонезависимой памяти по сбросу контроллера (или однократно программируемый в самом контроллере).

Для выполнения функций диспетчера изохронных ресурсов контроллер имеет четыре автономных регистра, реализующих блокированные операции (compare_swap) как со стороны шины, так и со стороны хоста.

Контроллеры DMA

Контроллеры DMA OHC по способу управления разделяются на два типа:

Контроллер асинхронной передачи (Asynchronous Transmit), AT DMA, имеет по одному контексту для передачи запросов (AT Request) и ответов (AT Responce). Для каждого отправленного пакета контроллер ожидает пакет квитирования; в случае получения квитанции ack_busy (занято) контроллер организует программно заданное число попыток повтора. Контроллер может реализовать однофазный или двухфазный протокол повторов. Если контроллер реализует изменение порядка исполнения, то он в случае занятости узла-получателя может продвигаться дальше по контекстной программе, возвращаясь к повтору данного пакета позже. Контроллер AT DMA отвечает и за ответы на запросы к физической памяти, обнаруженные принимающим контроллером DMA.

Прием асинхронных пакетов выполняют блок физических запросов и контроллер асинхронного приема.

Блок физических запросов, Physical Request Unit, включается в работу, когда приходит пакет запроса одного из трех типов:

Остальные асинхронные пакеты обслуживает контроллер асинхронного приема (Asynchronous Receive), AR DMA, который имеет по одному контексту для приема запросов (AR Request) и ответов (AR Responce). Этот же контроллер обслуживаети запросы блокированных транзакций, адресованных не к регистрам изохронных ресурсов, помещая их в контекст AR Request.

Контроллер DMA изохронной передачи (Isochronous Transmit), IT DMA, поддерживает от 4 до 32 контекстов, каждый из которых обеспечивает передачу одного канала.

Контроллер DMA изохронного приема (Isochronous Receive) поддерживает от 4 до 32 контекстов, каждый из которых обеспечивает прием одного канала. Один из контекстов можно запрограммировать на прием множества каналов.

Специальный контроллер, Self_ID DMA, принимает пакеты самоидентификации и укладывает их последовательно в один выделенный буфер. После каждого обнаруженного сброса контроллер начинает укладку пакетов с начала буфера, затирая предыдущие пакеты.

Фильтрация асинхронных запросов

Каждый приходящий асинхронный запрос, не относящийся к 1-килобайтной области памяти конфигурации, фильтруется трехступенчатым фильтром. Первая ступень фильтра по идентификатору узла-источника определяет судьбу запроса:

Запросы чтения памяти конфигурации принимаются от любых источников и отрабатываются аппаратно (если в хост-контроллере определен корректный образ памяти конфигурации).

Фильтрацией асинхронных запросов управляют 64-битные регистры AsynchronousRequestFilter и PhysicalRequestFilter, каждый из которых представлен регистрами установки и сброса старшей (Hi) и младшей (Lo) половин. Первая ступень фильтрации выполняется в соответствии с содержимым регистра AsynchronousRequestFilter. В этом 64-битном регистре единица в старшем бите (asynReqResourceAll) разрешает отработку асинхронных запросов от всех источников. При его нулевом значении остальные биты разрешают отработку запросов от узлов с PHY_ID, соответствующих номерам бит (младший бит соответствует PHY_ID = 0). Управление данным фильтром осуществляется через регистры AsynchronousRequestFilterHiSet (100h), AsynchronousRequestFilterHiClear (104h), AsynchronousRequestFilterLoSet (108h), AsynchronousRequestFilterLoClear (10Ch).

Вторая ступень фильтрует прошедшие запросы по адресу смещения, указанному в пакете запроса. Кандидатами на физическую отработку являются запросы, адресованные к нижней области памяти и к автономным регистрам. Граница нижней области задается регистром PhysicalUpperBound (120h) — в нем содержатся старшие 32 бита 48-разрядного адреса начала средней области памяти, которая уже не попадает в кандидаты на физическую отработку запросов. Младшие 16 бит считаются нулевыми. Если данный регистр отсутствует в OHC, то его чтение дает нули, что должно трактоваться как указание на размер нижней области 4 Гбайт.

Последний фильтр, управляемый регистром PhysicalRequestFilter, определяет способ обработки запроса-кандидата на физическую обработку. В этом 64-битном регистре единица в старшем бите (physReqResourceAllBuses) разрешает физическую обработку запросов от узлов всех шин. Остальные биты относятся к узлам локальной шины (на которой находится узел с OHC), они разрешают физическую отработку запросов от узлов с соответствующими номерами. Запросы, не прошедшие через данный фильтр, направляются в контекст AR_Request DMA и обрабатываются программно. Управление данным фильтром осуществляется через регистры PhysicalRequestFilterHiSet (110h), PhysicalRequestFilterHi-Clear (114h), PhysicalRequestFilterLoSet (118h), PhysicalRequestFilter-LoClear (11Ch).

Контексты DMA

Контекст DMA, образующий независимый канал DMA, состоит из контекстной программы и регистров контроллера. Контекстная программа — это список команд, отрабатываемых контроллером для передачи и приема пакетов данных. Каждый контекст DMA представлен в контроллере своим блоком регистров, в который входят регистры ContextControl (управление и состояние) и CommandPtr (указатель на команду). В дополнение к этому контексты изохронного приема имеют свои регистры шаблонов совпадений ContextMatch и общий регистр масок мультиканального приема. В последующем описании указывается смещение регистров относительно начального адреса своего блока регистров.

Управляющий регистр ContextControl контекста представлен парой регистров ContextControlSet (+0h) и ContextControlClear (+4h), обеспечивающих установку, сброс и чтение битов и полей. Формат регистра для асинхронных контекстов приведен на рисунке ниже, форматы регистров для изохронных контекстов описаны в соответствующем разделе. Назначение полей, используемых в регистрах всех контекстов, приведено далее:

Таблица. Коды событий для контекстов DMA

Регистр CommandPtr (+Ch) содержит указатель на блок дескрипторов (старшие 28 бит адреса в поле descriptorAddress) и индикатор длины этого блока (поле Z). Длина (поле Z) указывается в 16-байтных блоках; дескрипторы выровнены по границе параграфа (младшие 4 бита — нулевые). Индикатор Z = 0 означает недействительность указателя — признак окончания контекстной программы. Допустимое число блоков в дескрипторе зависит от типа контекста. При инициализации контекста в регистр заносится указатель на начальный блок дескрипторов и их число в блоке. Дальнейшая программная модификация регистра допустима лишь при нулевом значении признаков run и active. Чтение регистра, в зависимости от состояния признаков run, dead, active и wake, дает различные значения указателей:

Инициализация контекста начинается с проверки состояния — биты run, active и dead должны быть сброшены. При этом условии в регистр CommandPtr помещается указатель на блок дескрипторов (и длина блока), после чего можно программно установить бит run.

Добавление дескрипторов в список возможно в любое время. Для этого в памяти формируется дескриптор или связанный список дескрипторов, и указатель на него (и поле Z) помещается в адрес перехода, находящийся в последнем дескрипторе прежнего списка. После этого необходимо программно установить бит wake — указать контроллеру на обновление списка.

Остановка контекста выполняется программным сбросом бита wake, но это может и не привести к немедленной остановке. Признаком остановки контекста после сброса run является обнуленный бит active.

1394 Ohci совместимый хост контроллер windows 7

Подробнее о пакете драйверов:

OHCI Compliant IEEE 1394 Host Controller. Характеристики драйвера

Драйвер OHCI Compliant IEEE 1394 Host Controller для Windows от Microsoft. Ручная установка драйвера.

Внимание! Перед установкой драйвера OHCI Compliant IEEE 1394 Host Controller рекомендутся удалить её старую версию. Удаление драйвера особенно необходимо – при замене оборудования или перед установкой новых версий драйверов для видеокарт. Узнать об этом подробнее можно в разделе FAQ.

Файлы для скачивания (информация)

Рейтинг: 2.9/5 ( Проголосовало: 18 чел.)

Драйверы для VIA 1394 OHCI Compliant Host Controller собраны с официальных сайтов компаний-производителей и других проверенных источников. Официальные пакеты драйверов помогут исправить ошибки и неполадки в работе VIA 1394 OHCI Compliant Host Controller (устройства ввода). Скачать последние версии драйверов на VIA 1394 OHCI Compliant Host Controller для компьютеров и ноутбуков на Windows.

Windows Driver Download Center

Use the links on this page to download the latest version of LSI 1394 OHCI Compliant Host Controller drivers. All drivers available for download have been scanned by antivirus program. Please choose the relevant version according to your computer’s operating system and click the download button.

Your machine is currently running: Windows (Detect)

LSI 1394 OHCI Compliant Host Controller Drivers Download

Please enter verification code, then click the download button.

Please enter verification code, then click the download button.

Please enter verification code, then click the download button.

Please enter verification code, then click the download button.

Please enter verification code, then click the download button.

Texas instruments ohci compliant ieee 1394a host controller что это такое

Загрузить драйверы
TI VIA OHCI Compliant IEEE 1394 Host Controller

Инструкции по обновлению драйвера VIA OHCI Compliant IEEE 1394 Host Controller вручную:

Эти стандартные драйверы VIA OHCI Compliant IEEE 1394 Host Controller можно найти в %%os%% или загрузить из обновления Windows®. Встроенные драйверы будут поддерживать основные функциональные возможности вашего Disk Controller, но, как правило, не более расширенные функции. Наши инструкции по обновлению драйверов Texas Instruments содержат все необходимые шаги.

Порядок выполнения автоматической загрузки и обновления:

Самым большим преимуществом использования DriverDoc является доступ к более 2 150 000 драйверов (база пополняется на ежедневной основе), благодаря чему вы можете быть уверены, что все драйверы (не только Контроллер диска) на вашем ПК обновляются на постоянной основе.

OHCI Compliant IEEE 1394 Host Controller Часто задаваемые вопросы относительно обновления

Какие операционные системы работают с драйверами OHCI Compliant IEEE 1394 Host Controller?

OHCI Compliant IEEE 1394 Host Controller полностью поддерживается Windows.

Что может пойти не так, обновление драйверов OHCI Compliant IEEE 1394 Host Controller и почему это сделать?

Многие люди не видят необходимости обновления драйверов устройств OHCI Compliant IEEE 1394 Host Controller, поэтому они никогда не обновляются.

Как узнать, когда обновлять драйверы OHCI Compliant IEEE 1394 Host Controller?

Мы рекомендуем периодически обновлять драйверы устройств OHCI Compliant IEEE 1394 Host Controller, обычно не реже нескольких раз в год.

Какова функция драйверов Контроллер диска TI?

Вашей операционной системе необходим способ взаимодействия с OHCI Compliant IEEE 1394 Host Controller, и именно эту роль выполняют данные крошечные программные приложения.

Осложнения обслуживания водителей

Ошибки VIA OHCI Compliant IEEE 1394 Host Controller могут быть коренятся в устаревший или поврежденный драйвер устройства. Когда операционная система, от которой зависит ваше устройство, получает обновление, драйверы могут внезапно перестать работать с ней. Вы не должны беспокоиться, потому что вы можете обновить драйверы Контроллер диска в качестве меры предотвращения.

Это может быть трудно найти точные драйверы, совместимые с вашим VIA OHCI Compliant IEEE 1394 Host Controller. Тем не менее, даже если вы хорошо найдете, устанавливаете и обновляете драйверы для VIA OHCI Compliant IEEE 1394 Host Controller, вы все равно можете тратить много времени и быть очень разочарованы этим начинанием. Установка неправильного драйвера или просто несовместимой версии правильного драйвера может усугубить ваши проблемы.

Чтобы оставаться в курсе всех основных новых функций драйверов, мы предлагаем пойти с программой обновления драйверов. Средство обновления драйверов гарантирует наличие правильных версий драйверов для оборудования, а также создает резервную копию текущих драйверов перед внесением каких-либо изменений. Вы уверены, что можете вернуться к более ранней версии, если вы столкнулись с некоторыми проблемами с вашим драйвером.

сетевой адаптер 1394 windows xp что это такое

Порт 1394: что можно подключить к нему на ноутбуке в 2019 году

1394 — это быстрый последовательный порт для подключения видеокамер, быстрых винчестеров, выведенный на рынок компанией Apple в 1995 под фирменным названием FireWire. Большинство современных внешних накопителей подключаются по USB или Serial ATA. Может стоит просто забыть про архаичный 1394? Но нам удалось найти, для чего можно использовать этот порт.

История FireWire

С появлением видеокамер высокого разрешения потребовался порт для их подключения. Имевшийся на то время универсальный USB не годился. Его пропускная способность составляла всего 12 Мбит/с в стандарте Full-Speed. Спецификация USB 2.0 с более высокой скоростью до 480 Мбит/с появилась только в 2000 году.

Порт ATA также имел свои неудобства. В нем ограничена длина кабеля 18 дюймов, около 45,7 см. И много ножек в самом разъеме, что неудобно для мобильных устройств.

Apple предложила новый стандарт и реализовала его в своих устройствах. Слово Fire в названии означает, что новые гаджеты и накопители можно подключать «на лету», без перезагрузки компьютера.

Что подключить к разъему 1394 в 2019 году

Новые устройства с таким портом практически не выпускаются. Стандарт вытеснен USB 3.0 и Serial-ATA. Тем не менее, кое что совместимое для этого гнезда ноутбука найти удалось.

Внешний дисковод на 2 Тб

Вот такой WD My book удалось найти в объявлениях о продаже. Если хотите украсить рабочий стол оригинальной штуковиной, то такой винт вполне сгодится.

Как и многие другие внешние накопители, My Book поддерживает и USB.

Видеокамера

Можно взять недорогую видеокамеру, которая сможет подключаться по FireWire. В этом качестве IE 1394 в свое время получил распространение. Камеру можно было подключать к компьютеру на большом расстоянии, что хорошо для студий.Нам удалось найти вот такую, от Samsung за 3500 рублей.

DVD-рекордер

Если на вашем ноутбуке скопились видеозаписи, и нужно записать их на DVD, можно купить за 1000 рублей вот такой комбайн с DVD-приводом. У него есть вход IE 1394.

Крутая внешняя звуковая карта

Из ноутбука можно сделать диджейский пульт с помощью вот такой стильной внешней аудиокарты. Объявление о ее продаже висит за 3000 рублей. Попробуйте поторговаться.

Правда, автор объявления предупреждает, что если у вас 4-пин разъем, то питание на карту надо подавать от внешнего адаптера.

СОБЕРИ САМ

FireWire IEEE 1394b и драйверы под Windows XP

Слепо верить не стоит

В следующем сравнении мы привели значения пропускной способности по данным OrangeWare и Unibrain и сравнили производительность работы драйвера ubCore под Windows XP SP1 и Windows XP SP2 с результатами драйверов OrangeWare и стека Windows XP (как с SP2, так и без него).

По заявлению Unibrain, лабораторное тестирование наглядно демонстрирует преимущество драйверов ubCore над стеком драйверов Windows XP с Service Pack 2.

Помимо этого, у нас возникли проблемы с установкой различных антивирусных приложений и межсетевых экранов. Даже Service Pack 2 оказался очень нестабильным и дал ровные результаты тестов только после нескольких попыток.

Service Pack 2: Microsoft «нажала на тормоз»

Как мы полагаем, приведённые значения стали результатом «сырого» состояния Service Pack 2 и стабильно хорошей производительности драйверов OHCI Windows (SP1). Также здесь видно, что драйверы Unibrain и OrangeWare практически не дают прироста производительности.

Тестовая конфигурация

Для соединения двух тестовых ПК мы использовали кабель FireWire длиной 4,5 метра (6-контактные вилки на обоих концах), а также кабель IEEE 1394b от Hama такой же длины. Пропускная способность измерялась с помощью SiSoft Sandra 2004 и NetIO. Поскольку все эти тесты являются синтетическими, мы решили провести тестирование, более близкое к жизни. Для этого мы скопировали образ DVD объёмом 7,65 Гбайт с одного компьютера на другой, вооружившись секундомером.

Windows XP и сети 1394

Во время нашего тестирования драйвер Texas Instruments, который Windows автоматически привязала к адаптеру 1394, пришлось заменить на драйвер OHCI от VIA, который позволил обеспечить стабильное сетевое соединение по IEEE 1394a (!) на скорости 400 Мбит/с. Иногда при этом приходится отключать другие сетевые соединения (к примеру, Ethernet), так как могут возникнуть конфликты при выделении IP-адресов. Мы просто отключили компьютеры от локальной сети.

Ассортимент драйверов

В теории, Windows XP не понимает IEEE 1394b. Поэтому система не может обеспечить подходящего надёжного драйвера. В то же время, Windows XP распознала карту Trust как адаптер IEEE 1394 и присвоила ему стандартный драйвер OHCI. Хотя система ещё не готова к «b», Windows создала сетевое соединение, отобразив скорость 800 Мбит/с, даже с меньшими проблемами, чем стандартное подключение FireWire IEEE 1394a! Работа такой сети и наши измерения прошли гладко.

С текущей версией Release Candidate 2 пакета обновления Service Pack 2 для Windows XP ситуация вообще иная: с драйверами IEEE 1394b в SP2 производительность снизилась примерно в 2-3 раза. Судя по значениям, драйверы в SP2 слишком «сырые». Это предположение мы смогли подтвердить, установив драйверы Unibrain под Windows XP с SP2. К сожалению, они нарушили стабильность системы. Драйверы Unibrain можно было устанавливать только после полной переустановки XP с SP2. Хотя сходных проблем с драйверами OrangeWare под Windows XP SP2 не произошло, пропускная способность снизилась до уровня драйверов Unibrain. Драйверы OrangeWare под Windows XP SP1 пришлось устанавливать вручную, при этом они работали безупречно. В то же время, они не показали прироста производительности в сравнении с драйверами Windows OHCI.

ubCore от Unibrain: не всё так легко

Сначала мы установили драйвер Unibrain ubCore Version 3.2 под Windows XP с Service Pack 1. Начнём с того, что сетевое соединение 1394 просто исчезло. Это оказалась не программная ошибка, как мы поначалу предположили, а подход Unibrain: компания предусматривает ручную установку сетевого соединения, которая весьма скудно описана в онлайновом руководстве. Необходимо перегрузить соответствующие драйверы из подкаталога ubCore «Firenet» с помощью Мастера установки оборудования Windows. После этого сеть появится.

FireWire против гигабитного Ethernet

Новую высокоскоростную версию IEEE1394 любят называть FireWire-800 или FireWire-b. Но вряд ли это будет корректным, поскольку стандарт требует аккуратного обращения. Официально новая версия называется «IEEE 1394b». Помимо новых разъёмов, которые спереди выглядят как увеличенная версия вилки i.Link (больше примерно в три раза), она обеспечивает прирост производительности. Максимальная пропускная способность в идеальных условиях составляет около 100 Мбайт/с (800 Мбит/с). На практике средняя скорость работы с внешними устройствами типа жёстких дисков составляет половину от максимальной (50 Мбайт/с), а при прямом соединении двух компьютеров пользователь получит только четверть (25 Мбайт/с).

Сети гигабитного Ethernet позволяют получить эффективную скорость передачи в 70-80 Мбайт/с, несмотря на технологию с вероятностью коллизий.

Заключение

По сравнению с ещё не готовым Service Pack 2 для Windows XP, драйверы Unibrain и OrangeWare обеспечивают прирост скорости, хотя и не такой большой, какой обещали оба производителя. Если же сравнить с драйвером OHCI под Windows XP с SP1, то никакого заметного прироста драйверы сторонних разработчиков не дают. До выпуска Service Pack 2 Microsoft имеет достаточно времени, чтобы оптимизировать свои драйверы или заменить их на лучшие. Мы ещё вернёмся к этому вопросу после выхода SP2.

Как мы считаем, FireWire 800 найдёт себе место в области хранения данных, хотя в сетях, не считая небольших групп пользователей, эта технология вряд ли завоюет массовый рынок. Сегодня гигабитный Ethernet достаточно распространился, да и продукты на 10 Гбит/с уже находятся на горизонте. Похоже, здесь победит количество, а не качество, и FireWire проиграет гигабитному Ethernet из-за недостаточной проработанности. В любом случае, FireWire найдёт свою нишу в индустрии, к примеру, для связи различной бытовой техники. Посмотрим.

IEEE 1394 (Firewire) — новая последовательная шина

Введение

IEEE 1394 или Firewire — это последовательная высокоскоростная шина, предназначенная для обмена цифровой информацией между компьютером и другими электронными устройствами. Благодаря невысокой цене и большой скорости передачи данных эта шина становится новым стандартом шины ввода-вывода для персонального компьютера. Ее изменяемая архитектура и одноранговая топология делают Firewire идеальным вариантом для подключения жестких дисков и устройств обработки аудио- и видеоинформации. Эта шина также идеально подходит для работы мультимедийных приложений в реальном времени. В этом материале приведены некоторые общие сведения о стандарте IEEE 1394.

Зачем нужен новый интерфейс

Прежде всего, посмотрите на заднюю стенку своего компьютера. Там можно найти множество всяких разъемов: последовательный порт для модема, принтерный порт для принтера, разъемы для клавиатуры, мыши и монитора, SCSI-интерфейс, предназначенный для подключения внешних носителей информации и сканеров, разъемы для подключения аудио и MIDI устройств, а также для устройств захвата и работы с видеоизображениями. Это изобилие сбивает с толка пользователей и создает беспорядок из соединительных кабелей. Причем, нередко производители ноутбуков используют и другие типы коннекторов.

Новый интерфейс призван избавить пользователей от этой мешанины и к тому же имеет полностью цифровой интерфейс. Таким образом, данные с компакт-дисков и цифровых магнитофонов смогут передаваться без искажений, потому что в настоящее время эти данные сначала конвертируются в аналоговый сигнал, а затем обратно оцифровываются устройством-получателем сигнала. Кабельное телевидение, радиовещание и видео CD передают данные также в цифровом формате.

Цифровые устройства генерируют большие объемы данных, необходимые для передачи качественной мультимедиа-информации. Например:

Высококачественное видео
Цифровые данные = (30 frames / second) (640 x 480 pels) (24-bit color / pel) = 221 Mbps

Видео среднего качества
Цифровые данные = (15 frames / second) (320 x 240 pels) (16-bit color / pel) = 18 Mbps

Высококачественное аудио
Цифровые данные = (44,100 audio samples / sec) (16-bit audio samples) (2 audio channels for stereo) = 1.4 Mbps

Аудио среднего качества
Цифровые данные = (11,050 audio samples / sec) (8-bit audio samples) (1 audio channel for monaural) = 0.1 Mbps

Обозначение Mbps — мегабит в секунду.

Для решения всех этих проблем и высокоскоростной передачи данных была разработана шина IEEE 1394 (Firewire).

IEEE 1394 — высокоскоростная последовательная шина

Стандарт поддерживает пропускную способность шины на уровнях 100, 200 и 400 Мбит/с. В зависимости от возможностей подключенных устройств одна пара устройств может обмениваться сигналами на скорости 100 Мбит/с, в то время как другая на той же шине — на скорости 400 Мбит/с. В начале следующего года будут реализованы две новые скорости — 800 и 1600 Мбит/с, которые в настоящее время предлагаются как расширение стандарта. Такие высокие показатели пропускной способности последовательной шины практически исключают необходимость использования параллельных шин, основной задачей которых станет передача потоков данных, например несжатых видеосигналов, внутри компьютера.

Таким образом, Firewire удовлетворяет всем вышеперечисленным требованиям, включая:

Благодаря этому шина IEEE 1394 может использоваться с:

Простейшая система для видеоконференций, построенная на шине IEEE 1394, использующая два 15 fps аудио/видео канала загрузит всего третью часть 100Mbps интерфейса 1394. Но, в принципе, для этой задачи возможно и использование 400Mbps интерфейса.

Кабель IEEE 1394

Шесть контактов FireWire подсоединены к двум проводам, идущим к источнику питания, и двум витым парам сигнальных проводов. Каждая витая пара и весь кабель в целом экранированы.

Провода питания рассчитаны на ток до 1,5 А при напряжении от 8 до 40 В, поддерживают работу всей шины, даже когда некоторые устройства выключены. Они также делают ненужными кабели питания во многих устройствах. Не так давно инженеры Sony разработали еще более тонкий четырехпроводный кабель, в котором отсутствуют провода питания. (Они намерены добавить свою разработку к стандарту.) Этот так называемый AV-разъем будет связывать небольшие устройства, как «листья» с «ветками» 1394.

Гнездо разъема имеет небольшие размеры. Ширина его составляет 1/10 ширины гнезда разъема SCSI, у него всего шесть контактов (у SCSI — 25 или 50 разъемов).

К тому же кабель 1394 тонкий — приблизительно в три раза тоньше, чем кабель SCSI. Секрет тут прост — ведь это последовательная шина. Все данные посылаются последовательно, а не параллельно по разным проводам, как это делает шина SCSI.

Топология

Стандарт 1394 определяет общую структуру шины, а также протокол передачи данных и разделения носителя. Древообразная структура шины всегда имеет «корневое» устройство, от которого происходит ветвление к логическим «узлам», находящимся в других физических устройствах.

Корневое устройство отвечает за определенные функции управления. Так, если это ПК, он может содержать мост между шинами 1394 и PCI и выполнять некоторые дополнительные функции по управлению шиной. Корневое устройство определяется во время инициализации и, будучи однажды выбранным, остается таковым на все время подключения к шине.

Сеть 1394 может включать до 63 узлов, каждый из которых имеет свой 6-разрядный физический идентификационный номер. Несколько сетей могут быть соединены между собой мостами. Максимальное количество соединенных шин в системе — 1023. При этом каждая шина идентифицируется отдельным 10-разрядным номером. Таким образом, 16-разрядный адрес позволяет иметь до 64449 узлов в системе. Поскольку разрядность адресов устройств 64 бита, а 16 из них используются для спецификации узлов и сетей, остается 48 бит для адресного пространства, максимальный размер которого 256 Терабайт (256х1024 4 байт) для каждого узла.

Однако есть несколько ограничений. Между любыми двумя узлами может существовать не больше 16 сетевых сегментов, а в результате соединения устройств не должны образовываться петли. К тому же для поддержки качества сигналов длина стандартного кабеля, соединяющего два узла, не должна превышать 4,5 м.

Протокол

Интерфейс позволяет осуществлять два типа передачи данных: синхронный и асинхронный. При асинхронном методе получатель подтверждает получение данных, а синхронная передача гарантирует доставку данных в необходимом объеме, что особенно важно для мультимедийных приложений.

Протокол IEEE 1394 реализует три нижних уровня эталонной модели Международной организации по стандартизации OSI: физический, канальный и сетевой. Кроме того, существует «менеджер шины», которому доступны все три уровня. На физическом уровне обеспечивается электрическое и механическое соединение с коннектором, на других уровнях — соединение с прикладной программой.

На физическом уровне осуществляется передача и получение данных, выполняются арбитражные функции — для того чтобы все устройства, подключенные к шине Firewire, имели равные права доступа.

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

На сетевом уровне поддерживается асинхронный протокол записи, чтения и блокировки команд, обеспечивая передачу данных от отправителя к получателю и чтение полученных данных. Блокировка объединяет функции команд записи/чтения и производит маршрутизацию данных между отправителем и получателем в обоих направлениях.

«Менеджер шины» обеспечивает общее управление ее конфигурацией, выполняя следующие действия: оптимизацию арбитражной синхронизации, управление потреблением электрической энергии устройствами, подключенными к шине, назначение ведущего устройства в цикле, присвоение идентификатора синхронного канала и уведомление об ошибках.

Чтобы передать данные, устройство сначала запрашивает контроль над физическим уровнем. При асинхронной передаче в пакете, кроме данных, содержатся адреса отправителя и получателя. Если получатель принимает пакет, то подтверждение возвращается отправителю. Для улучшения производительности отправитель может осуществлять до 64 транзакций, не дожидаясь обработки. Если возвращено отрицательное подтверждение, то происходит повторная передача пакета.

В случае синхронной передачи отправитель просит предоставить синхронный канал, имеющий полосу частот, соответствующую его потребностям. Идентификатор синхронного канала передается вместе с данными пакета. Получатель проверяет идентификатор канала и принимает только те данные, которые имеют определенный идентификатор. Количество каналов и полоса частот для каждого зависят от приложения пользователя. Может быть организовано до 64 синхронных каналов.

Шина конфигурируется таким образом, чтобы передача кадра начиналась во время интервала синхронизации. В начале кадра располагается индикатор начала и далее последовательно во времени следуют синхронные каналы 1, 2… На рисунке изображен кадр с двумя синхронными каналами и одним асинхронным.

Оставшееся время в кадре используется для асинхронной передачи. В случае установления для каждого синхронного канала окна в кадре шина гарантирует необходимую для передачи полосу частот и успешную доставку данных.

Резюме

Таким образом, в скором будущем, на задней панели компьютера можно будет увидеть выходы всего двух последовательных шин: USB для низкоскоростных применений и Firewire — для высокоскоростных. Причем путь в жизнь у шины IEEE 1394 произойдет гораздо быстрее, чем у USB. В этом случае производители программных продуктов и аппаратуры действуют сообща. Уже сейчас доступны различные виды устройств с шиной Firewire, поддержка этой шины будет встроена в операционную систему Windows 98 и в ближайшем будущем ведущие производители чипсетов для PC встроят поддержку этой шины в свои продукты. Так что 1998 год станет годом Firewire.

Дополнительная информация

Дополнительную информацию о шине IEEE 1394 можно получить на сайтах:

IEEE 1394 хост контроллеры → Microsoft

Самая популярная марка:
ATI

Самая популярная модель:
NVIDIA GeForce 9800 GT

Сетевые адаптеры в диспетчере устройств Windows

В диспетчере устройств Windows есть отдельный раздел «Сетевые адаптеры», в котором отображаются все сетевые адаптеры, которые установлены в системе. Чаще всего это сетевая карта (LAN), Wi-Fi адаптер (WLAN), устройства Bluetooth, и системные: TAP-Windows Adapter, Microsoft Virtual Wi-Fi, Microsoft Wi-Fi Direct, WAN Miniport и т. д.

В этой статье я хочу рассказать об этих адаптерах. За что они отвечают и как работают. Какие сетевые адаптеры должны быть диспетчере устройств Windows. Как их туда добавлять и удалять. Почему сетевые адаптеры не отображаются в диспетчере устройств, не удаляются, не работают, не видят Wi-Fi и интернет. В том же диспетчере устройств эти адаптеры не редко отображаются с ошибками. Например, «код 31». Бывает, что возле адаптера отображается восклицательный знак, стрелочка, или сама иконка прозрачная. Это означает, что в работе этого устройства есть ошибки, оно работает неправильно, или отключено.

У меня раздел «Сетевые адаптеры» в диспетчере устройств выглядит вот так (в Windows 10) :

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

Так же там может отображаться «Виртуальный адаптер Wi-Fi Direct (Майкрософт)», «Виртуальный адаптер размещенной сети (Майкрософт)», «Сетевой адаптер с отладкой ядра (Майкрософт)». Все это системные адаптеры, которые нужны для работы определенных функций. Чаще всего это функция раздачи Wi-Fi через командную строку, или мобильны хот-спот в Windows 10.

Как управлять сетевыми адаптерами в Windows?

Можно нажать на «Вид» и поставить галочку возле «Показывать скрытые устройства». После этого появляться все отключенные адаптеры, которые раньше были подключены и настроены.

Возле адаптера так же может быть желтый восклицательный знак. Это значит что адаптер работает не правильно. Нажмите на него правой кнопкой мыши и выберите «Свойства». Там будет отображаться «Состояние устройства». Может быть сообщение об ошибке и код ошибки, по которому можно найти решение.

Нажав правой кнопкой мыши на адаптер, можно обновить его драйвера, отключить, или удалить из системы. А так же открыть свойства (как я показывал выше) и изменить необходимые параметры на соответствующих вкладках.

Думаю, что нет смысла рассматривать все свойства и параметры каждого адаптера, да и они конечно же будут отличаться.

Можно открыть параметры каждого адаптера, отключить его, удалить, обновить драйвера, посмотреть состояние, ошибки и т. д. Именно это я хотел показать в данной статье. Если у вас остались какие-то вопросы, то задавайте их в комментариях.

Компьютерная Энциклопедия

Как рассчитать количество дезинфицирующего средства на помещение repair-school.com. Подшипник роликовый конический размеры: подбор подшипников по размерам sf2v.ru.

Шина IEEE 1394 — FireWire

«Открытый» хост-контроллер IEEE 1394 — OHCI

Общая информация об «открытом» хост-контроллере IEEE 1394 — OHCI

«Открытый» хост-контроллер (OHC 1394) представляет собой реализацию канального уровня (LINK) шины IEEE 1394 с дополнительными средствами поддержки уровней транзакций и управления шиной. Для высокопроизводительного обмена данными OHC содержит контроллеры прямого доступа к памяти (DMA). Контроллер поддерживает все типы пакетов, передаваемых по шине 1394. Данное описание основано на спецификации 1394 Open Host Controller Interface Specification, версия 1.1, 2000 год .

Со стороны шины 1394 хост — узел с контроллером OHC — выглядит как обычный узел шины, способный выполнять функции мастера циклов и диспетчера изохронных ресурсов. Контроллер позволяет хосту быть инициатором любых транзакций шины 1394 и отвечать на любые транзакции, адресованные узлу хоста.В адресном пространстве этого узла расположены архитектурные регистры CSR и память конфигурации; большая часть пространства доступна для обращений в виде обычных транзакций шины. Часть пространства узла может отображать пространство физических адресов памяти хоста. Часть обращений к хосту может отрабатываться исключительно аппаратными средствами контроллера; остальные обращения хост отрабатывает программно. Принимаемые пакеты запросов для программной отработки OHC своими каналами DMA помещает в буферы, размещенные в памяти хоста. Пакеты ответов программа размещает в других буферах, из которых OHC организует их передачу в шину, опять же с помощью каналов DMA.

Для асинхронных транзакций контроллер обеспечивает чтение пакетов из системной памяти хоста и их передачу в шину; пакеты, принимаемые из шины, контроллер записывает в системную память. Обмен производится с помощью каналов DMA. Контроллер может функционировать и как шинный мост, аппаратно отрабатывая запросы транзакций чтения и записи шины 1394 как обращения к пространству памяти хоста.

Для изохронных операций OHC может исполнять роль мастера циклов, синхронизируясь от внутреннего генератора синхронизации или (необязательно) от внешнего источника. Если OHC не исполняет роль мастера циклов, то он поддерживает синхронизацию внутреннего таймера циклов с таймером узла-мастера циклов (по приему пакетов начала цикла). Для изохронных операций OHC имеет два контроллера DMA — для приема и для передачи данных. Каждый из этих контроллеров может поддерживать до 32 каналов DMA, называемых контекстами DMA. Передающий контроллер в каждом цикле может передавать данные из каждого контекста для связанного с ним изохронного канала. Принимающий контроллер способен в каждом цикле принимать данные в каждый контекст из связанного с ним канала. Кроме того, один из принимающих контекстов может быть настроен на прием данных из множества каналов.

По обнаружении сброса на шине OHC автоматически очищает все очереди асинхронных пакетов для передачи; прием пакетов не прерывается, но в потоке пакетов запросов появляется маркер, индицирующий факт сброса. Новый физический идентификатор узла (PHY_ID), получаемый от PHY, контроллер записывает в соответствующий регистр. Контроллер возобновит асинхронные передачи только по указанию программы, при этом повторное использование старых запросов в общем случае невозможно: физический идентификатор узла назначения может измениться. Изохронный прием и передача по сбросу не прекращаются — они возобновляются сразу по завершении инициализации.

Устройство контроллера OHC

Упрощенная структурная схема OHC приведена на рисунке.

Интерфейс системной шины (Host Bus Interface) обеспечивает взаимодействие с контроллером в двух режимах:

• ведомый режим (PCI Target), обеспечивающий программный доступ к регистрам контроллера со стороны центрального процессора хоста;
• ведущий режим (PCI Bus Master), обеспечивающий контроллеру возможность прямого доступа к системной памяти хоста. В этом режиме интерфейс системной шины должен выдерживать поток данных, по крайней мере, базовой скорости S100 (100 Мбит/с) с накладными расходами на организацию прямого доступа к памяти.

Контроллеры DMA обеспечивают обмен данными между шиной и системной памятью. В OHC имеются семь типов контроллеров DMA:

• контроллер асинхронной передачи (AT DMA);
• контроллер асинхронного приема (AR DMA);
• блок физических запросов, в который входят два контроллера:
  ——контроллер приема аппаратно-обрабатываемых запросов (Physical Receive);
  ——контроллер ответов для аппаратно-обрабатываемых запросов (Physical Response);
• контроллер изохронной передачи (IT DMA);
• контроллер изохронного приема (IR DMA);
• контроллер приема пакетов самоидентификации (Self_ID DMA).

равляющих работой канала и выборкой запросов из списков, расположенных в системной памяти. Контроллеры асинхронной передачи и приема имеют отдельные контексты для запросов и ответов шинных транзакций. Контроллеры изохронного приема и передачи могут иметь до 32 контекстов каждый. Назначение и работа контроллеров подробно описано ниже.

LINK-уровень OHC передает пакеты из FIFO-буферов передающих каналов и отдает в FIFO принятые пакеты с корректным адресом, предназначенные данному узлу. Уровень выполняет следующие действия:

• передает и принимает пакеты форматов IEEE 1394;
• генерирует соответствующие пакеты квитирования для принятых асинхронных пакетов, отрабатывая однофазный или двухфазный протокол повторов;
• выполняет функции мастера циклов;
• генерирует и проверяет корректность 32-битных CRC-кодов;
• обнаруживает пропуски пакетов начала цикла;
• взаимодействует с регистрами PHY;
• принимает изохронные пакеты (все время);
• игнорирует асинхронные пакеты во время изохронной фазы цикла.

Буферы FIFO, находящиеся между каналами DMA и LINK-уровнем, выполняют промежуточную буферизацию данных, считываемых из системной памяти для передачи в шину и принятых из шины для записи в память. Буферы FIFO обеспечивают и согласование выравнивания данных, побайтного для хоста и поквадлетного для шины 1394. При необходимости буферы FIFO вставляют байты-заполнители, выравнивающие данные до границ квадлетов. Переполнение (overflow) или переопустошение (underrun) буферов (по вине интерфейса системной шины и памяти), приводящее к потерям принимаемых или передаваемых пакетов, контролируется аппаратными средствами OHC.

Буферы могут «на лету» выполнять преобразование форматов представления квадлетов. Шина IEEE 1394 и, соответственно, LINK-eровень работают с квадлетами, представленными в формате Big Еndian (старший байт передается первым). Передача данных через хост-интерфейс может выполняться по выбору:

• в формате Big Endian, используемом на платформах фирмы Apple;
• в формате Little Endian (младший байт передается первым), используемом на платформах фирмы Intel.

Для поддержки функций управления OHC имеет 64-битный регистр уникального идентификатора (GUID, он же IEEE EUI-64), автоматически загружаемый из энергонезависимой памяти по сбросу контроллера (или однократно программируемый в самом контроллере).

Для выполнения функций диспетчера изохронных ресурсов контроллер имеет четыре автономных регистра, реализующих блокированные операции (compare_swap) как со стороны шины, так и со стороны хоста.

Контроллеры DMA

Контроллеры DMA OHC по способу управления разделяются на два типа:

• контроллеры, работающие по программам контекстов. Программа контекста DMA — это связанный список дескрипторов, описывающих команды и связанные с ними буферы данных. Программу контекста, расположенную в системной памяти хоста, формирует программа (драйвер), исполняемая процессором хоста. По контекстным программам работают контроллеры асинхронной передачи и приема, обслуживающие пакеты запросов и ответов, генерируемые и отрабатываемые программой хоста. По контекстным программам работают и контроллеры изохронного приема и передачи. Управление каждым контекстом (фактически — каналом DMA) производится с помощью своего блока регистров;
• Контроллеры, обслуживающие аппаратно обрабатываемые внешние запросы к узлу. Эти контроллеры управляются регистрами; никаких контекстных программ для них не создается. К данному типу относятся следующие контроллеры:
  ——контроллеры блока физических запросов на внешние обращения к памяти хоста и автономым регистрам OHC;
  ——контроллер записи пакетов самоидентификации.

Контроллер асинхронной передачи (Asynchronous Transmit), AT DMA, имеет по одному контексту для передачи запросов (AT Request) и ответов (AT Responce). Для каждого отправленного пакета контроллер ожидает пакет квитирования; в случае получения квитанции ack_busy (занято) контроллер организует программно заданное число попыток повтора. Контроллер может реализовать однофазный или двухфазный протокол повторов. Если контроллер реализует изменение порядка исполнения, то он в случае занятости узла-получателя может продвигаться дальше по контекстной программе, возвращаясь к повтору данного пакета позже. Контроллер AT DMA отвечает и за ответы на запросы к физической памяти, обнаруженные принимающим контроллером DMA.

Прием асинхронных пакетов выполняют блок физических запросов и контроллер асинхронного приема.

Блок физических запросов, Physical Request Unit, включается в работу, когда приходит пакет запроса одного из трех типов:

• запрос к системной памяти хоста, доступной для узлов шины (лежащий в диапазоне нижних адресов);
• запрос блокированной транзакции (compare_swap), адресованный к одному из автономных регистров (для диспетчера изохронных ресурсов);
• запрос по адресу памяти конфигурации.

Остальные асинхронные пакеты обслуживает контроллер асинхронного приема (Asynchronous Receive), AR DMA, который имеет по одному контексту для приема запросов (AR Request) и ответов (AR Responce). Этот же контроллер обслуживаети запросы блокированных транзакций, адресованных не к регистрам изохронных ресурсов, помещая их в контекст AR Request.

Контроллер DMA изохронной передачи (Isochronous Transmit), IT DMA, поддерживает от 4 до 32 контекстов, каждый из которых обеспечивает передачу одного канала.

Контроллер DMA изохронного приема (Isochronous Receive) поддерживает от 4 до 32 контекстов, каждый из которых обеспечивает прием одного канала. Один из контекстов можно запрограммировать на прием множества каналов.

Специальный контроллер, Self_ID DMA, принимает пакеты самоидентификации и укладывает их последовательно в один выделенный буфер. После каждого обнаруженного сброса контроллер начинает укладку пакетов с начала буфера, затирая предыдущие пакеты.

Фильтрация асинхронных запросов

Каждый приходящий асинхронный запрос, не относящийся к 1-килобайтной области памяти конфигурации, фильтруется трехступенчатым фильтром. Первая ступень фильтра по идентификатору узла-источника определяет судьбу запроса:

• запрос игнорируется (без посылки каких-либо пакетов квитирования);
• запрос направляется на вторую и третью ступени фильтрации, где по адресу памяти и идентификатору источника определяется способ обработки:
  ——аппаратный, без привлечения программы хоста;
  ——программный, помещением запроса в контекст асинхронного приема и дальнейшей обработкой программой хоста.

Запросы чтения памяти конфигурации принимаются от любых источников и отрабатываются аппаратно (если в хост-контроллере определен корректный образ памяти конфигурации).

Фильтрацией асинхронных запросов управляют 64-битные регистры AsynchronousRequestFilter и PhysicalRequestFilter, каждый из которых представлен регистрами установки и сброса старшей (Hi) и младшей (Lo) половин. Первая ступень фильтрации выполняется в соответствии с содержимым регистра AsynchronousRequestFilter. В этом 64-битном регистре единица в старшем бите (asynReqResourceAll) разрешает отработку асинхронных запросов от всех источников. При его нулевом значении остальные биты разрешают отработку запросов от узлов с PHY_ID, соответствующих номерам бит (младший бит соответствует PHY_ID = 0). Управление данным фильтром осуществляется через регистры AsynchronousRequestFilterHiSet (100h), AsynchronousRequestFilterHiClear (104h), AsynchronousRequestFilterLoSet (108h), AsynchronousRequestFilterLoClear (10Ch).

Вторая ступень фильтрует прошедшие запросы по адресу смещения, указанному в пакете запроса. Кандидатами на физическую отработку являются запросы, адресованные к нижней области памяти и к автономным регистрам. Граница нижней области задается регистром PhysicalUpperBound (120h) — в нем содержатся старшие 32 бита 48-разрядного адреса начала средней области памяти, которая уже не попадает в кандидаты на физическую отработку запросов. Младшие 16 бит считаются нулевыми. Если данный регистр отсутствует в OHC, то его чтение дает нули, что должно трактоваться как указание на размер нижней области 4 Гбайт.

Последний фильтр, управляемый регистром PhysicalRequestFilter, определяет способ обработки запроса-кандидата на физическую обработку. В этом 64-битном регистре единица в старшем бите (physReqResourceAllBuses) разрешает физическую обработку запросов от узлов всех шин. Остальные биты относятся к узлам локальной шины (на которой находится узел с OHC), они разрешают физическую отработку запросов от узлов с соответствующими номерами. Запросы, не прошедшие через данный фильтр, направляются в контекст AR_Request DMA и обрабатываются программно. Управление данным фильтром осуществляется через регистры PhysicalRequestFilterHiSet (110h), PhysicalRequestFilterHi-Clear (114h), PhysicalRequestFilterLoSet (118h), PhysicalRequestFilter-LoClear (11Ch).

Контексты DMA

Контекст DMA, образующий независимый канал DMA, состоит из контекстной программы и регистров контроллера. Контекстная программа — это список команд, отрабатываемых контроллером для передачи и приема пакетов данных. Каждый контекст DMA представлен в контроллере своим блоком регистров, в который входят регистры ContextControl (управление и состояние) и CommandPtr (указатель на команду). В дополнение к этому контексты изохронного приема имеют свои регистры шаблонов совпадений ContextMatch и общий регистр масок мультиканального приема. В последующем описании указывается смещение регистров относительно начального адреса своего блока регистров.

Управляющий регистр ContextControl контекста представлен парой регистров ContextControlSet (+0h) и ContextControlClear (+4h), обеспечивающих установку, сброс и чтение битов и полей. Формат регистра для асинхронных контекстов приведен на рисунке ниже, форматы регистров для изохронных контекстов описаны в соответствующем разделе. Назначение полей, используемых в регистрах всех контекстов, приведено далее:

• run — программное разрешение (1) и запрет (0) отработки дескрипторов;
• wake — семафор, установкой которого программа уведомляет о добавлении нового дескриптора в контекст. Хост-контроллер обнуляет бит после выборки каждого дескриптора;
• dead — хост-контроллер устанавливает этот бит, обнаружив фатальную ошибку. Программный сброс бита run сбрасывает и этот бит;
• active — признак обработки дескрипторов (управляется хост-контроллером);
• spd — скорость, на которой был принят пакет (только для контекстов приема). Значение некорректно, если установлен бит wake или active;
• event_code — код события, раскрытый в таблице ниже.

Таблица. Коды событий для контекстов DMA

Регистр CommandPtr (+Ch) содержит указатель на блок дескрипторов (старшие 28 бит адреса в поле descriptorAddress) и индикатор длины этого блока (поле Z). Длина (поле Z) указывается в 16-байтных блоках; дескрипторы выровнены по границе параграфа (младшие 4 бита — нулевые). Индикатор Z = 0 означает недействительность указателя — признак окончания контекстной программы. Допустимое число блоков в дескрипторе зависит от типа контекста. При инициализации контекста в регистр заносится указатель на начальный блок дескрипторов и их число в блоке. Дальнейшая программная модификация регистра допустима лишь при нулевом значении признаков run и active. Чтение регистра, в зависимости от состояния признаков run, dead, active и wake, дает различные значения указателей:

• указывает на последний исполненный, текущий или следующий дескриптор;
• указывает на блок с Z = 0, вызвавший прекращение активности контекста или блок, вызвавший фатальную ошибку.

Инициализация контекста начинается с проверки состояния — биты run, active и dead должны быть сброшены. При этом условии в регистр CommandPtr помещается указатель на блок дескрипторов (и длина блока), после чего можно программно установить бит run.

Добавление дескрипторов в список возможно в любое время. Для этого в памяти формируется дескриптор или связанный список дескрипторов, и указатель на него (и поле Z) помещается в адрес перехода, находящийся в последнем дескрипторе прежнего списка. После этого необходимо программно установить бит wake — указать контроллеру на обновление списка.

Остановка контекста выполняется программным сбросом бита wake, но это может и не привести к немедленной остановке. Признаком остановки контекста после сброса run является обнуленный бит active.

1394 ohci совместимый хост контроллер что это

Вот так, вы сможете исправить ошибки, связанные с ohci1394.sys

Информация о файле ohci1394.sys

Процесс 1394 OpenHCI Port Driver или AGERE OHCI Compliant IEEE (версия 1394 Host Controller) или Texas Instruments OHCI Compliant IEEE (версия 1394 Host Controller) принадлежит программе AGERE OHCI Compliant IEEE (версия 1394 Host Controller) или Texas Instruments OHCI Compliant IEEE (версия 1394 Host Controller) или VIA OHCI Compliant IEEE (версия 1394 Host Controller) или OHCI Compliant IEEE (версия 1394 Host Controller) или 1394 OHCI Compliant Host Controller (Legacy) или NEC FireWarden OHCI Compliant IEEE (версия 1394 Host Controller) от Microsoft (www.microsoft.com).

Важно: Некоторые вредоносные программы маскируют себя как ohci1394.sys, особенно, если они расположены не в каталоге C:\Windows\System32\drivers. Таким образом, вы должны проверить файл ohci1394.sys на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера.

Комментарий пользователя

Лучшие практики для исправления проблем с ohci1394

Если у вас актуальные проблемы, попробуйте вспомнить, что вы делали в последнее время, или последнюю программу, которую вы устанавливали перед тем, как появилась впервые проблема. Используйте команду resmon, чтобы определить процесс, который вызывает проблемы. Даже если у вас серьезные проблемы с компьютером, прежде чем переустанавливать Windows, лучше попробуйте восстановить целостность установки ОС или для Windows 8 и более поздних версий Windows выполнить команду DISM.exe /Online /Cleanup-image /Restorehealth. Это позволит восстановить операционную систему без потери данных.

ohci1394 сканер

Security Task Manager показывает все запущенные сервисы Windows, включая внедренные скрытые приложения (например, мониторинг клавиатуры или браузера, авто вход). Уникальный рейтинг надежности указывает на вероятность того, что процесс потенциально может быть вредоносной программой-шпионом, кейлоггером или трояном.

Бесплатный aнтивирус находит и удаляет неактивные программы-шпионы, рекламу, трояны, кейлоггеры, вредоносные и следящие программы с вашего жесткого диска. Идеальное дополнение к Security Task Manager.

SpeedUpMyPC бесплатное сканирование, очистка, восстановление и оптимизация вашей системы.

Архитектура ЭВМ

Компоненты ПК

Интерфейсы

Мини блог

Самое читаемое

Как рассчитать количество дезинфицирующего средства на помещение repair-school.com. Подшипник роликовый конический размеры: подбор подшипников по размерам sf2v.ru.

Шина IEEE 1394 — FireWire

«Открытый» хост-контроллер IEEE 1394 — OHCI

Общая информация об «открытом» хост-контроллере IEEE 1394 — OHCI

Со стороны шины 1394 хост — узел с контроллером OHC — выглядит как обычный узел шины, способный выполнять функции мастера циклов и диспетчера изохронных ресурсов. Контроллер позволяет хосту быть инициатором любых транзакций шины 1394 и отвечать на любые транзакции, адресованные узлу хоста.В адресном пространстве этого узла расположены архитектурные регистры CSR и память конфигурации; большая часть пространства доступна для обращений в виде обычных транзакций шины. Часть пространства узла может отображать пространство физических адресов памяти хоста. Часть обращений к хосту может отрабатываться исключительно аппаратными средствами контроллера; остальные обращения хост отрабатывает программно. Принимаемые пакеты запросов для программной отработки OHC своими каналами DMA помещает в буферы, размещенные в памяти хоста. Пакеты ответов программа размещает в других буферах, из которых OHC организует их передачу в шину, опять же с помощью каналов DMA.

Для асинхронных транзакций контроллер обеспечивает чтение пакетов из системной памяти хоста и их передачу в шину; пакеты, принимаемые из шины, контроллер записывает в системную память. Обмен производится с помощью каналов DMA. Контроллер может функционировать и как шинный мост, аппаратно отрабатывая запросы транзакций чтения и записи шины 1394 как обращения к пространству памяти хоста.

Для изохронных операций OHC может исполнять роль мастера циклов, синхронизируясь от внутреннего генератора синхронизации или (необязательно) от внешнего источника. Если OHC не исполняет роль мастера циклов, то он поддерживает синхронизацию внутреннего таймера циклов с таймером узла-мастера циклов (по приему пакетов начала цикла). Для изохронных операций OHC имеет два контроллера DMA — для приема и для передачи данных. Каждый из этих контроллеров может поддерживать до 32 каналов DMA, называемых контекстами DMA. Передающий контроллер в каждом цикле может передавать данные из каждого контекста для связанного с ним изохронного канала. Принимающий контроллер способен в каждом цикле принимать данные в каждый контекст из связанного с ним канала. Кроме того, один из принимающих контекстов может быть настроен на прием данных из множества каналов.

По обнаружении сброса на шине OHC автоматически очищает все очереди асинхронных пакетов для передачи; прием пакетов не прерывается, но в потоке пакетов запросов появляется маркер, индицирующий факт сброса. Новый физический идентификатор узла (PHY_ID), получаемый от PHY, контроллер записывает в соответствующий регистр. Контроллер возобновит асинхронные передачи только по указанию программы, при этом повторное использование старых запросов в общем случае невозможно: физический идентификатор узла назначения может измениться. Изохронный прием и передача по сбросу не прекращаются — они возобновляются сразу по завершении инициализации.

Устройство контроллера OHC

Упрощенная структурная схема OHC приведена на рисунке.

Интерфейс системной шины (Host Bus Interface) обеспечивает взаимодействие с контроллером в двух режимах:

Контроллеры DMA обеспечивают обмен данными между шиной и системной памятью. В OHC имеются семь типов контроллеров DMA:

равляющих работой канала и выборкой запросов из списков, расположенных в системной памяти. Контроллеры асинхронной передачи и приема имеют отдельные контексты для запросов и ответов шинных транзакций. Контроллеры изохронного приема и передачи могут иметь до 32 контекстов каждый. Назначение и работа контроллеров подробно описано ниже.

LINK-уровень OHC передает пакеты из FIFO-буферов передающих каналов и отдает в FIFO принятые пакеты с корректным адресом, предназначенные данному узлу. Уровень выполняет следующие действия:

Буферы FIFO, находящиеся между каналами DMA и LINK-уровнем, выполняют промежуточную буферизацию данных, считываемых из системной памяти для передачи в шину и принятых из шины для записи в память. Буферы FIFO обеспечивают и согласование выравнивания данных, побайтного для хоста и поквадлетного для шины 1394. При необходимости буферы FIFO вставляют байты-заполнители, выравнивающие данные до границ квадлетов. Переполнение (overflow) или переопустошение (underrun) буферов (по вине интерфейса системной шины и памяти), приводящее к потерям принимаемых или передаваемых пакетов, контролируется аппаратными средствами OHC.

Буферы могут «на лету» выполнять преобразование форматов представления квадлетов. Шина IEEE 1394 и, соответственно, LINK-eровень работают с квадлетами, представленными в формате Big Еndian (старший байт передается первым). Передача данных через хост-интерфейс может выполняться по выбору:

Для поддержки функций управления OHC имеет 64-битный регистр уникального идентификатора (GUID, он же IEEE EUI-64), автоматически загружаемый из энергонезависимой памяти по сбросу контроллера (или однократно программируемый в самом контроллере).

Для выполнения функций диспетчера изохронных ресурсов контроллер имеет четыре автономных регистра, реализующих блокированные операции (compare_swap) как со стороны шины, так и со стороны хоста.

Контроллеры DMA

Контроллеры DMA OHC по способу управления разделяются на два типа:

Контроллер асинхронной передачи (Asynchronous Transmit), AT DMA, имеет по одному контексту для передачи запросов (AT Request) и ответов (AT Responce). Для каждого отправленного пакета контроллер ожидает пакет квитирования; в случае получения квитанции ack_busy (занято) контроллер организует программно заданное число попыток повтора. Контроллер может реализовать однофазный или двухфазный протокол повторов. Если контроллер реализует изменение порядка исполнения, то он в случае занятости узла-получателя может продвигаться дальше по контекстной программе, возвращаясь к повтору данного пакета позже. Контроллер AT DMA отвечает и за ответы на запросы к физической памяти, обнаруженные принимающим контроллером DMA.

Прием асинхронных пакетов выполняют блок физических запросов и контроллер асинхронного приема.

Блок физических запросов, Physical Request Unit, включается в работу, когда приходит пакет запроса одного из трех типов:

Остальные асинхронные пакеты обслуживает контроллер асинхронного приема (Asynchronous Receive), AR DMA, который имеет по одному контексту для приема запросов (AR Request) и ответов (AR Responce). Этот же контроллер обслуживаети запросы блокированных транзакций, адресованных не к регистрам изохронных ресурсов, помещая их в контекст AR Request.

Контроллер DMA изохронной передачи (Isochronous Transmit), IT DMA, поддерживает от 4 до 32 контекстов, каждый из которых обеспечивает передачу одного канала.

Контроллер DMA изохронного приема (Isochronous Receive) поддерживает от 4 до 32 контекстов, каждый из которых обеспечивает прием одного канала. Один из контекстов можно запрограммировать на прием множества каналов.

Специальный контроллер, Self_ID DMA, принимает пакеты самоидентификации и укладывает их последовательно в один выделенный буфер. После каждого обнаруженного сброса контроллер начинает укладку пакетов с начала буфера, затирая предыдущие пакеты.

Фильтрация асинхронных запросов

Каждый приходящий асинхронный запрос, не относящийся к 1-килобайтной области памяти конфигурации, фильтруется трехступенчатым фильтром. Первая ступень фильтра по идентификатору узла-источника определяет судьбу запроса:

Запросы чтения памяти конфигурации принимаются от любых источников и отрабатываются аппаратно (если в хост-контроллере определен корректный образ памяти конфигурации).

Фильтрацией асинхронных запросов управляют 64-битные регистры AsynchronousRequestFilter и PhysicalRequestFilter, каждый из которых представлен регистрами установки и сброса старшей (Hi) и младшей (Lo) половин. Первая ступень фильтрации выполняется в соответствии с содержимым регистра AsynchronousRequestFilter. В этом 64-битном регистре единица в старшем бите (asynReqResourceAll) разрешает отработку асинхронных запросов от всех источников. При его нулевом значении остальные биты разрешают отработку запросов от узлов с PHY_ID, соответствующих номерам бит (младший бит соответствует PHY_ID = 0). Управление данным фильтром осуществляется через регистры AsynchronousRequestFilterHiSet (100h), AsynchronousRequestFilterHiClear (104h), AsynchronousRequestFilterLoSet (108h), AsynchronousRequestFilterLoClear (10Ch).

Вторая ступень фильтрует прошедшие запросы по адресу смещения, указанному в пакете запроса. Кандидатами на физическую отработку являются запросы, адресованные к нижней области памяти и к автономным регистрам. Граница нижней области задается регистром PhysicalUpperBound (120h) — в нем содержатся старшие 32 бита 48-разрядного адреса начала средней области памяти, которая уже не попадает в кандидаты на физическую отработку запросов. Младшие 16 бит считаются нулевыми. Если данный регистр отсутствует в OHC, то его чтение дает нули, что должно трактоваться как указание на размер нижней области 4 Гбайт.

Последний фильтр, управляемый регистром PhysicalRequestFilter, определяет способ обработки запроса-кандидата на физическую обработку. В этом 64-битном регистре единица в старшем бите (physReqResourceAllBuses) разрешает физическую обработку запросов от узлов всех шин. Остальные биты относятся к узлам локальной шины (на которой находится узел с OHC), они разрешают физическую отработку запросов от узлов с соответствующими номерами. Запросы, не прошедшие через данный фильтр, направляются в контекст AR_Request DMA и обрабатываются программно. Управление данным фильтром осуществляется через регистры PhysicalRequestFilterHiSet (110h), PhysicalRequestFilterHi-Clear (114h), PhysicalRequestFilterLoSet (118h), PhysicalRequestFilter-LoClear (11Ch).

Контексты DMA

Контекст DMA, образующий независимый канал DMA, состоит из контекстной программы и регистров контроллера. Контекстная программа — это список команд, отрабатываемых контроллером для передачи и приема пакетов данных. Каждый контекст DMA представлен в контроллере своим блоком регистров, в который входят регистры ContextControl (управление и состояние) и CommandPtr (указатель на команду). В дополнение к этому контексты изохронного приема имеют свои регистры шаблонов совпадений ContextMatch и общий регистр масок мультиканального приема. В последующем описании указывается смещение регистров относительно начального адреса своего блока регистров.

Управляющий регистр ContextControl контекста представлен парой регистров ContextControlSet (+0h) и ContextControlClear (+4h), обеспечивающих установку, сброс и чтение битов и полей. Формат регистра для асинхронных контекстов приведен на рисунке ниже, форматы регистров для изохронных контекстов описаны в соответствующем разделе. Назначение полей, используемых в регистрах всех контекстов, приведено далее:

Таблица. Коды событий для контекстов DMA

Регистр CommandPtr (+Ch) содержит указатель на блок дескрипторов (старшие 28 бит адреса в поле descriptorAddress) и индикатор длины этого блока (поле Z). Длина (поле Z) указывается в 16-байтных блоках; дескрипторы выровнены по границе параграфа (младшие 4 бита — нулевые). Индикатор Z = 0 означает недействительность указателя — признак окончания контекстной программы. Допустимое число блоков в дескрипторе зависит от типа контекста. При инициализации контекста в регистр заносится указатель на начальный блок дескрипторов и их число в блоке. Дальнейшая программная модификация регистра допустима лишь при нулевом значении признаков run и active. Чтение регистра, в зависимости от состояния признаков run, dead, active и wake, дает различные значения указателей:

Инициализация контекста начинается с проверки состояния — биты run, active и dead должны быть сброшены. При этом условии в регистр CommandPtr помещается указатель на блок дескрипторов (и длина блока), после чего можно программно установить бит run.

Добавление дескрипторов в список возможно в любое время. Для этого в памяти формируется дескриптор или связанный список дескрипторов, и указатель на него (и поле Z) помещается в адрес перехода, находящийся в последнем дескрипторе прежнего списка. После этого необходимо программно установить бит wake — указать контроллеру на обновление списка.

Остановка контекста выполняется программным сбросом бита wake, но это может и не привести к немедленной остановке. Признаком остановки контекста после сброса run является обнуленный бит active.

IEEE 1394 против USB 2.0: холодная война с огоньком

Там где есть две стороны и соперничество, конкуренция, конфликт между ними, обычно одна одерживает верх. Ситуации же паритета — или, правильнее сказать, холодной войны — сравнительно редки и нестабильны. Именно в таком состоянии находились до середины минувшего года два стандарта высокоскоростных последовательных шин — USB 2.0 (Hi-Speed USB) и IEEE 1394 (FireWire или i.LINK). Война потеплела после интеграции контроллеров USB 2.0 в чипсеты для PC, но победитель все равно не ясен. Не ясно даже, определится ли он в будущем.

Ретроспектива

В первую очередь, как к ветерану, обратимся к стандарту 1394 — ведь у него уже солидная 15-летняя история. Идея быстрой последовательной шины зародилась в 1986 г. в недрах корпорации Apple Computer. Интерфейс Ultra SCSI-1 (шина задумывалась, как альтернатива ему) мог обеспечить пиковую пропускную способность в 20 Мбайт/с, а разработка Apple позволяла улучшить этот показатель в два с половиной раза — до 400 Мбит/с (кроме того, были предусмотрены режимы 100 и 200 Мбит/с). Тогда же Apple зарегистрировала торговую марку «FireWire», под которой в настоящее время шина и известна больше всего. Уже через год была выпущена первая спецификация. Apple начала продвигать интерфейс на рынок в качестве мощного и простого в употреблении средства для подключения (главным образом, к компьютерам собственного производства) видеокамер, высокоскоростных принтеров, внешних жестких дисков и прочих устройств, требовательных к пропускной способности соединения. Шли годы, поддержка FireWire со стороны производители чипов и бытовой цифровой электроники медленно, но верно возрастала. В 1994 г. Apple и множество сочувствующих компаний объединились в консорциум, чуть доработали спецификацию, и она была официально принята IEEE в 1995 г. Так родился оригинальный стандарт 1394 (IEEE 1394-1995).

Первый блин, как и следовало ожидать, вышел комом: всплыли проблемы совместимости, особенно в разнородном стане PC. Что ж, такова судьба многих стандартов на первых порах: многое дается на откуп интерпретаторским талантам реализаторов, а реализаторы, не имея нот перед глазами, неизбежно поют вразнобой, не смотря на чуткое следование палочке дирижера. Поэтому, следующим шагом стала разработка новой редакции стандарта — IEEE 1394a (официально принята в 2000 г.). Она прояснила темные места, сделала обязательными некоторые опционные части и добавила детали, улучшившие производительность. Кроме того, появилась спецификация 1394 OHCI (Open Host Controller Interface), благодаря которой остались в прошлом несовместимые друг с другом проприетарные FireWire-карты. Это (и тот факт, что 1394 стал абсолютным стандартом для DV-камер) поспособствовало росту популярности шины в лагере PC (в мультимедиа-ориентированных настольных системах и ноутбуках).

Компания Intel никогда негативно не отзывалась о FireWire и даже, было такое время, активно поддерживала разработки, инвестируя Zayante. По слухам, внутри компании долгое время шли серьезные баталии по поводу того, начинать ли с FireWire войну, продвигая по всем фронтам Hi-Speed USB, или, наоборот, сдаться на милость победителя. В конце концов, компания решила поддерживать обе технологии (но предпочтение все равно отдается USB). Можно предположить, что в неуверенности Intel (или в нежелании преждевременно бить по другой перспективной шине) кроется причина странной задержки с интегрированием контроллеров USB 2.0 в чипсеты. Изначально это предполагалось сделать еще в i815, но первым чипсетом с USB 2.0 стал вышедший в середине прошлого года i845G. Сейчас практически все производители чипсетов для PC встраивают в южные мосты контролеры USB 2.0. и только один — SiS — еще и контроллеры 1394a.

Что лучше?

Несмотря на то, что интерфейсы изначально проектировались для разных целей (USB для подключения периферии к ПК, а FireWire для передачи массивных потоков аудио/видеоданных между устройствами), их распространенные сегодня инкарнации имеют более-менее похожие характеристики. Перед конечным пользователем (а, следовательно, и перед производителем оборудования) встает дилемма: какой интерфейс выбрать? Дать однозначный ответ для всех случаев невозможно даже сейчас, когда Hi-Speed USB получил массовое распространение. В какой-то мере отсутствие тотальной гегемонии одного стандарта даже хорошо — есть возможность использовать уникальные свойства каждого из них (чтобы не томить читателя, сразу заметим, два главных плюса USB 2.0 — это совместимость с USB 1.Х и низкая цена).

Комбинированный контроллер Adaptec DuoConnect USB 2.0 + IEEE 1394.

Теоретически, максимальная пропускная способность Hi-Speed USB — 480 Мбит/с — на 20% выше, чем у распространенного сегодня 1394a. С продвижением Hi-Speed USB на рынке стали появляться устройства (например, внешние жесткие диски) со сдвоенным интерфейсом или одни и те же модели с разными интерфейсами. Казалось бы, работать по USB они должны быстрее, но на практике не всё так просто: при прочих равных условиях, подключая устройство через FireWire, вы получаете лучшую производительность (и гораздо меньше проблем с горячей заменой), чем при подключении через USB 2.0. Причины этого, думается, в сырости технологии и драйверов: тут, как с первым поколением USB, нужно дождаться версии X.1 — она будет работать стабильней, полноценней и, не сглазить бы, наконец-то сравняется по производительности с шиной 1394a (которая к тому времени уже несколько устареет).

FireWire позволяет соединять устройства в произвольных ветвлениях, оборудование можно подключать (не требуется устанавливать никаких драйверов) или отключать в любое время (даже когда идет интенсивный обмен данными), при этом шина тут же автоматически перестраивается. Ей не нужно управление (работает по схеме peer-to-peer): узлы равноправны и обращаются друг к другу напрямую. Поэтому можно, например, подключить DV-камеру к приводу DVD-RAM без компьютера вообще. А если он и подсоединен к шине, информация с камеры все равно будет идти непосредственно на DVD-RAM без посредничества PC (но он может контролировать траффик, если это необходимо). Через FireWire можно соединить «как попало» (для удобства прикупив два-три хаба) несколько компьютеров, камер, принтеров, внешних CD-R и любое другое оборудование. Всё это без проблем станет функционировать с момента подключения, есть только три ограничения:
• не больше 63 устройств на одной шине (но с использованием мостов можно соединять до 1023 шин);
• между двумя устройствами не должно быть больше 16 сегментов;
• в результате соединения не должны образовываться петли (это ограничение снято в 1394b).