Информационные технологииStfw.Ru 🔍
Релиз сетевого анализатора Wireshark 1.2
  • 🕛 17 июня, 03:41
Увидел свет первый релиз новой стабильной ветки сетевого анализатора Wireshark - 1.2.0.
Поддержка USB 3.0 прежде всего появится в Linux
  • 🕛 16 июня, 04:04
Операционные системы на основе ядра Linux станут первыми программными платформами с поддержкой интерфейса USB 3.0, известного также как SuperSpeed USB.
Другие последовательные шины и беспроводные каналы связи.
  • 🕛 15 июня, 09:28
Предшествующие реализации.
Поддержка Fire Wire, USB различными платформами
  • 🕛 15 июня, 09:27
Ни смотря на то, что в настоящее время USB устройства являются достсточно распространенными, поддержка их различными ОС несколько отставала от успехов производителей соответствующего "железа". Так, например, если возможность работать напрямую с собственным устройством, подключенным к последовательному порту RS232 при помощи стандартного компонента из программы Visual Basic или Delphi является весьма обычным делом, то это вряд ли можно сказать про USB, а тем более Fire Wire.
Существуют два осовных способа работы прикладной программы с USB/FireWire устройствами: первый - обращение к специализированным API драйверов верхнего уровня, которые обеспечивают доступ к абстрактному устройству (сканеру, принтеру, диску и.т.п.), скрывая при этом от программы детали, связанные с работой последовательной шины и второй способ, когда используется API нижнего уровня, предоставляющее доступ непосредственно к шине на уровне пакетов, каналов передачи, регистров CSR и.т.п.
Аппаратные решения для устройств Fire Wire
  • 🕛 15 июня, 09:25
Аппаратные интерфейсы шины ШЕЕ 1394 в отличие от USB не разделяются на хосты и устройства, однако существуют комплекты микросхем предназначенные для сложных полнофункциональных устройств, таких как например компьютеры, и для более узкоспециализированных, например видеокамер.
Аппаратные решения для устройств USB
  • 🕛 15 июня, 09:24
Производители электронных компонентов выпускают специализированные микросхемы, реализующие протоколы USB хоста и устройства. С использованием этих микросхем можно реализовать собственные аппаратные решения для шины USB. Кроме того, для реализации каких-либо дополнительных возможностей не предусмотренных производителями можно воспользоваться микросхемами программируемой логики (PLIS), в качеств отправной точки для этого можно воспользоваться например VHDL прошивками USB драйверов доступными на сайте www.opencores.org. Последнее может быть интересно так же с точки зрения изучения электрического протокола шины.
Configuration ROM
  • 🕛 15 июня, 09:23
Для регистров Configuration ROM предусмотрен минимальный формат, который содержит только 24 битовый VendorlD и общий формат, представляющий собой набор директорий, содержащих специфическую информацию. Минимальный формат имеет следующий вид
PHY Registers и Configuration ROM.
  • 🕛 15 июня, 09:22
Регистры PHY обеспечивают низкоуровневый интерфейс к шине, они могут быть прочитаны другими устройствами, желающими получит информацию о числе портов, максимальной скорости передачи, версии поддерживаемого стандарта IEEE 1394 и.т.п., поддерживаемых данным устройством. Некоторые из этих регистров могут быть изменены при помощи посылки пакетов PHY Configuration. Например можно дать устройству комнаду задержать свое участие в процедуре Tree Identification на 167 микросекунд, с тем чобы оно не смогло получить роль менеджера шины.
Unit registers
  • 🕛 15 июня, 09:21
Начиная со смещения 0x800 от начала Initial Units Registers располагаются регистры Unit
registers, наиболее важными из которых являются
TOPOLOGYMAP (диапазон адресов 0xl000-0xl3FC)
SPEEDMAP (диапазон адресов 0x2000 - 0x2FFC)
Устройство, которое оказывается менеджером шины, запоминает первые 4 байта из SelflD
пакетов, в том порядке в котором их посылают устройства во время процедуры Self
Identification.
На основании этой информации любое устойство, которому это потребуется может
восстановить топологию шины.
Формат TOPOLOGYMAP следующий:
16 бит длина всей таблицы.
16 6HTCRC.
32 бит generationnumber - количество раз, которое менеджер шины генерировал карту
топологии шины.
16 бит число подключенных устройств
16 бит selfidcount - общее число SelflD пакетов, посланных устройствами.
Дальше сдедуют 4 байтовые фрагменты SelflD пакетов в количестве selfidcount.
Регистр SPEEDMAP содержит от 0 до 4029 чисел, определяющих максимальную скорость. передачи между каждой парой устройств. Заголовок такой же в регистре TOPOLOGYMAP, в след за которым размещены однобайтовые элементы (симметричной) матрицы скоростей.
Мы собираемся кратко описать назначение основных регистров.
  • 🕛 15 июня, 09:20
Устройства, использующие изохронную передачу обязаны иметь эти регистры. Содержимое регисттров обновляется с частотой 24.576МГц, отчитывая 125 микросекундные интервалы (тайм слоты).
Работа программы (или драйвера) с шиной FireWire
  • 🕛 15 июня, 09:02
Взаимодействие ПО с шиной происходит как на уровне транзакций (Transaction layer) так и на уровне связи (Link layer) для чего определены понятия программных интерфейсов FireWire: интерфейс асинхронных транзакций, интерфейс изохронной передачи, минующий уровень транзакций и обращающийся напрямую к Link layer, а так же интерфейс управления шиной (Bus management interface). Каждый из этих программных интерфейсов как правило обеспечивается отдельным драйверов ядре ОС. Эти интерфейсы используют прикладные драйверы устройств, например таких как внешний накопитель FireWire.
Работа программы (или драйвера) с шиной USB
  • 🕛 15 июня, 09:01
USB обеспечивает более высокий уровень протокола передачи данных, при написании программы (или драйвера) в большинстве случаев не следует заботиться о размере пакетов и порядке передачи данных.
Устройства потребители
  • 🕛 15 июня, 08:58
Потребители очевидно имеют 6 контактные разъемы и POWERCLASS равный 4,6 или 7. Для поддержания уровня PHY активным таким устройствам требуется не более 3 ватт, После получения PHY пакета link-on, такие устройства могут потреблять дополнительную энергию для работы уровня LINK. Если требования устройству к потреблению питания не укладываются полностью ни в один POWERCLASS, то директории Configuration ROM содержат дополлнительную информацию.
Управление питанием Fire Wire
  • 🕛 15 июня, 08:58
В отличие от USB, устройства Fire Wire могут не только иметь собственный источник питания, но и поставлять питающе напряжение через шину другим устройствам. Стандарт ШЕЕ 1394 определяет целую систему упреждающего оповещения о возможной потере тем или иным устройством способности поставлять питающее напряжение в шину.
Управление питанием USB
  • 🕛 15 июня, 08:56
Для классификации USB устройств по отношению к питающему напряжению вводится единица нагрузки по току величиной в 100 миллиампер (в зависимоти от условий питающее напряжение в разных частях шины может окахываться в диапазоне от 4.40 до 5.25 вольт).
Электрические характеристики, передача сигналов USB.
  • 🕛 15 июня, 08:55
Для передачи битов данных USB использует NRZI кодирование (для сравнения FireWire использует NRZ), смысл использования таких кодировок состоит в упрощении синхронизации передающих и приемных цепей устройств друг с другом. Подобные кодировки обеспечивают повышенное количество переходов между уровнями логического нуля и единицы по сравнению с непосредственной передачей битовой последовательности.
Уровни протокола FireWire
  • 🕛 15 июня, 08:43
Спецификация FireWrare определяет для протокола обмена данными следующие уровни
Isochron транзакции
  • 🕛 15 июня, 08:39
Хост передает устройству IN/OUT token пакет и вслед за ним принимает пакет данных isochron. Никакого handshake, никакой повторной передачи. Доставка данных не гарантирована, однако хост инициирует передачу пакетов с достаточной частотой и регулярностью, что каждый изохронный канал получает определенную (заявленную устройством) полосу пропускания для передачи. При этом максимальная латентность при передаче определяется только длительностью таймслота, которая составляет 1 миллисекунда для USB1.0 и 125 микросекунд для USB2.0.
Interrupt транзакции
  • 🕛 15 июня, 08:39
Хост посылает IN-token и устройство в ответ возвращает либо пакет данных, либо NACK (если данные не готовы), либо STALL (если данные не готовы). Получив пакет хост так же отвечает устройству АСК.
Процедура аналогична bulk транзакции типа IN, включая гарантированную доставку данных от устройства к хосту. Таким образом interrupt транзакция предназначена для передачи небольшого количества данных, например для использования в качестве канала обратной связи например при передаче данных по изохронному каналу. При этом поскольку хост опрашивает устройство с частотой, которое указало само устройство, interrupt передача может оказаться более оперативной чем bulk.
Для lowspeed устройств USB1.0 разрешенными типами передачи являются control и interrupt и поэтому производители устройств нередко используют interrupt для асинхронной передачи данных от устройства к хосту. Примером такого устройства может служить ридер чиповых карт ACE30U (производства Advanced Card Systems), для передачи данных от хоста к устройству в данном случае используется control передача.
В более поздних версиях спецификации (USB1.1) добавлено понятие interrupt передачи типа OUT. Повидимому это было сделано для того, чтобы обеспечить более удобный способ работы для медленных устройств с тем, чтобы вместо единственного канала для передачи от хоста к устройству типа control можно было использовать и другие каналы. В частности такой способ может использоваться устройствами, реализующими поверх USB прикладной протокол HID. HID - переводится как Human Interface Dvice и формализует некоторые общие свойства медленных устройств типа мышей и джойстиков.
Control транзакции
  • 🕛 15 июня, 08:38
Транзакция control состоит из трех этапов: setup, data и status. Хост начинает транзакцию посылкой пакета SETUP, при этом передается информация о направлении передачи (IN или OUT) и предполагаемое количество байт данных. На этапе data (таковой может отсутствовать если нет данных для передачи) передаются данные в выбранном направлении, возможно количество данных будет больше заявленного и тогда этот этап будет содержать один или несколько дополнительных пакетов данных. Третий этап staus -передача пакета, содержащего ответ, в обратном направлении. Завершает весь процесс обычная handshake процедура (NACK означает что устройство не готово, a STALL означает ошибку).
Устройство, получившее token пакет SETUP в котором указан номер default endpoint (или номер любого другого control endpoint-a) в качестве номера endpoint-a обязано принять этот пакет (handshake ответы от устройства NACK и STALL не предполагаются, в случае ошибки устройство не возвращает никакого handshake пакета), если в качестве номера указан номер endpoint-a неподходящего типа, устройство должно проигнорировать пакет. Передача может быть разбита на несколько пакетов, но при этом IN и OUT пакеты никогда не смешиваются пока не закончится транзакция (за исключением пакета, передаваемого а этапе status). Фактически это означает что хост не потребует от устройства передачи данных (IN) через control endpoint до тех пор пока сам не завершит передачу (OUT).
Тип передачи control предназначается не для потоковой, а для пакетной передачи, поэтому пакеты control имеют определенную стандартом структуру, включающую информацию о направлении передачи, назначении пакета, длине вложенных данных и.т.п. Существует целый ряд служебных команд, которые могут быть переданы через default endpoint.
Bulk транзакции
  • 🕛 15 июня, 08:38
Bulk обеспечивает передачу данных с подтверждением и повторной передачей в случае возникновения ошибок (гарантированная доставка). При этом данные передаются потоком один пакет вслед за другим. Каждый bulk endpoint в устройстве имеет тип IN либо OUT и соответственно предназначен для передачи данных только в одном направлении. Ответ NACK от устройства на token пакет означает что пакет получен без ошибок оно еще не готово к приему или передаче данных и поэтому хосту следует повторить попытку через некоторе время.
Описание транзакций для разных типов передачи данных USB (bulk, isochron, control, interrupt)
  • 🕛 15 июня, 08:37
Для каждого типа передачи выделяют два типа транзакций IN (передача пакетов от устройства к хосту) и OUT (передача данных от хоста к устройству). Однако в зависимости от типа (bulk, isochron, control, interrupt) протокол обмена пакетами данных может существенно отличаться. Рассмотрим подробнее каждый из типов.
Split-транзакции
  • 🕛 15 июня, 08:36
Split-транзакции в USB предназначены для использования между хостом и HUB устройствами.
Структура и типы используемых пакетов
  • 🕛 15 июня, 08:36
Все пакеты начинаются с поля SYNC, которое служит для того, чтобы устройства могли синхронизировать свой внутренний счетчик битов с передаваемым пакетом. Для этого используется последовательность, содержащая максимальное количество переходов между уровнями логических нуля и единицы. Для используемой NRZI кодировки при передаче байтов (подробнее в главе про электрические характеристики) в качестве такой последовательности используется строка "KJKJKJKK".
Кроме того каждый пакет в зависимости от типа (и соответственно назначения) может содержать следующую информацию: 4-х битовый идентификатор пакета (PID), семибитный адрес устройства, четырехбитовый номер логического канала (endpoint), данные содержимого пакета, контрольную сумму CRC, одиннадцатибитовый циклический номер фрейма (только для SOF пакетов).
Идентификатор пакета всегда следует за SYNC и является обязательным атрибутом пакета. Вслед за PID предается его собственная (независимая от CRC) четырехбайтовая контрольная сумма. В зависимости от типа пакета и версии реализации USB, возможные значения PID
High-Speed Isochronous Data Payload
  • 🕛 15 июня, 08:35
Хост инициирует передачу данных устройствам (OUT) или от устройств (IN) при помощи специального пакета, называемого Token-пакет. Этот пакет содержит адрес устройства которое должно получить или передать данные и номер логического канала (endpoint-a) внутри этого устройства. Устройство может подтвердить готовность при помощи пакета АСК (acknowledge) или сообщить хосту том, что оно еще не готово для передачи или приема очередного пакета. В случае если требуется получить данные от устройства (IN-транзакция), хост может попытаться сделать это еще раз позднее. При передаче данных от хоста к устройству (OUT-транзакция) если по причине неготовности принять данные устройство вернет NACK, хост должен будет повторить псосылку пакета через некоторое время. В случае USB1.0 если устройство окажется неготово несколько раз подряд, каждый раз хост будет передавать последний непринятый этим устройством пакет, тем самым занимая время от таймслота, которое могло бы быть использовано для связи с другим устройствами! В USB2.0 эта проблема решается при помощи Ping-пакетов, позволяющих узнать готово ли устройство к приему данных для выбранного логического канала без передачи самих данных. Эта особенность относится в первую очередь к асинхронной передаче bulk, для изохронной передачи (isochron) в силу того, что нет подтверждения передачи (handshake) подобная ситуация возникнуть не может.
Низкоскоростные устройства (low speed 1.5Mbit/sec) могут использовать только control и interrupt транзакции, которые в целом ведут себя аналогично OUT и IN транзакциям типа bulk. При передаче пакетов для более быстрых устройств (full speed USB 1.0 и high speed USB2.0) HUB-устройства не передают эти пакеты через порты, к которым подключены low speed устройства. При этом когда передаются данные для самих low speed устройств в составе пакетов используется еще специальный префикс, позволяющий HUB-ам определить что пакет следует ретранслировать на низкой скорости.
Подтверждение передачи происходит при помощи handshake пакетов: АСК, NACK, STALL. Хост никогда не может послать устройству NACK, вместо этого он просто не посылает никакого handshake пакета! Устройство может вернуть пакет STALL если произошла ошибка, требующая вмешательства хоста для переинициализации какого-либо ресурса в этом устройстве, связанного с логическим каналом в устройстве, для которого предназначался пакет.
Таймслоты, совместимость стандартов, транзакции.
  • 🕛 15 июня, 08:35
Передача всех пакетов по шине USB, как уже говорилось, происходит по команде хоста, начало каждого таймслота, называемого frame, маркируется посылкой хостом специального пакета SOF (statrt of frame). Подключенные к шине устройства могут использовать SOF для коррекции свомх внутренних часов. Длительность таймслота (фрейма) USB1.0 составляет 1 миллисекунду, таймслоты USB2.0 принято называть микрофреймами (microframe), их длительность составляет 125 микросекунд. Для достижения совместимости обоих стандартов HUB-устройства USB2.0 и используют механизм конверсии транзакция при передаче данных между хостом и устройствами USB1.0 (то есть устройствами использующими скорости low spee и full speed).
FireWire Self identification
  • 🕛 15 июня, 08:34
В результате процедуры Tree identification происходит локальное определение топологии шины, то есть устанавливаются связи соседних узлов и ля каждого узла задается направление к вершине дерева в сторону одного из соседних узлов.
FireWire Tree Identification.
  • 🕛 15 июня, 08:33
При передаче сигналов по шине IEEE 1394 все устройства используют механизм арбитража, реализованный на аппаратном уровне. Таким образом достигается разделение между ними проводного канала связи по времени.
Рассмотрим процесс управления шиной FireWire более подробно.
  • 🕛 15 июня, 08:31
В отличие от USB шина IEEE 1394 не имеет заранее выделенного управляющего узла и функции такового после того как шина окажется сконфигурированной могут быть распределены между несколькими устройствами на шине. Важно отметить то, что в случае отсутствия устройств,
способных выполнять некоторый функции сама шина останется работоспособной, но эти функции останутся недоступными. Так же важен то факт что любое подключение или отключение устройства способно разрешить или наоборот запретить выполнение той или иной функции каким-либо из подключенных устройств. Поэтому шина должна автоматически перераспределить функции управления ей самой между имеющимися устройствами.

Новости IT-технологий

IT-технологии - портал содержит статьи и обзоры из всех областей компьютерных событий.