Антология USB: другая версия

Универсальность USB — в спо­соб­но­с­ти об­слу­жи­вать по­то­ки дан­ных раз­лич­ной при­ро­ды. Для ини­ци­а­ли­за­ции пе­ри­фе­рий­но­го уст­рой­ст­ва, ус­та­нов­ки опе­ра­ци­он­ных па­ра­мет­ров и оп­ро­са ста­ту­са ис­поль­зу­ет­ся ре­жим Cont­rol Mode — раз­вет­в­лен­ный на­бор ко­рот­ких ди­рек­тив, оперативно доставляемых потребителю. Медиа-ин­фор­ма­ция хо­ро­шо тран­сли­ру­ет­ся в изо­хрон­ном ре­жи­ме (Isochronous Mode): скорость пе­ре­да­чи имеет зна­че­ние, а потери — нет, никто и не за­ме­тит ис­ка­же­ния од­но­го бита, пока этот процесс не станет лавиной, пре­ры­ва­ю­щий звуковой сигнал артефактами. Кстати, Interrupt Mode тоже есть в поддержке стека протоколов USB-шины: он нужен для того, чтобы от­сле­жи­вать на­жа­тие кла­виш USB-клавиатуры и USB-мышки. Осо­бая гор­дость уни­вер­саль­ной по­сле­до­ва­тель­ной шины — Bulk Mode — ре­жим пе­ре­да­чи огромных мас­си­вов дан­ных, в процессе которого недопустимы ни искажения, ни потери. Это и по­нят­но: ес­ли под­ме­ну пик­се­ля на эк­ра­не никто не заметит, то за ошибками в передаче файлов зорко следит кон­т­роль­ная сум­ма.

Оценкой производительности Bulk Mode служит скорость передачи данных без ошибок, т.е. с пов­то­ра­ми и пе­ре­по­сыл­ка­ми, коль скоро они понадобятся для результативного завершения передачи информации. С этого бы и сто­и­ло на­чи­нать, когда речь зашла о причинах появления USB 2.0. Про­из­во­ди­тель­ность USB 1.1 даже при самом ско­рост­ном со­е­ди­не­нии Full-Speed на рубеже веков не со­от­вет­ст­во­ва­ла духу времени: IT-ин­дус­т­рия тре­бо­ва­ла большего.

Причины появления USB 2.0

История USB 2.0 в обратном порядке

Понять все проблемы внедрения USB 2.0 проще всего на примере самого последнего нов­ше­ст­ва в ре­а­ли­за­ции этой вер­сии уни­вер­саль­ной последовательной шины. Обратная хронология дает возможность по­нять, какие про­бле­мы не ре­ши­ли раз­ра­бот­чи­ки EHCI — Enhanced Host Controller Interface, возложив их на поль­зо­вателя.

Итак, первую премию за оригинальное решение шины USB 2.0 получает RMH — Rate Matching Hub. Вкратце, его идея со­сто­ит в отказе от использования двух контроллеров, обслуживающих один USB-порт (и разъем!). Вмес­то это­го по­ток дан­ных, со­от­вет­ст­ву­ю­щих тре­бо­ва­ни­ям USB 1.1 инкапсулируется силами RMH и об­слу­жи­ва­ет­ся EHCI-контроллером.

Преимущества очевидны: производство USB-контроллера в связке с RMH, но без контроллеров-компаньонов OHCI или UHCI, необходимых для совместимости с USB 1.1, дешевле за счет экономии места на кристалле, а ис­поль­зо­ва­ние всей кон­ст­рук­ции проще с программной точки зрения. К сожалению, эту «идеальную» ар­хи­тек­ту­ру USB 2.0 компания Intel смогла предложить только в своих финальных чипсетах накануне стар­та продаж системной логики с поддержкой USB 3.0.

Кстати, обратная совместимость, с легкостью реализованная силами RMH, заложит основы для успешного и бес­про­б­лем­но­го продвижения USB 3.0, а отсутствие таковой было камнем преткновения для огромного чис­ла поль­зо­ва­те­лей, по­я­вив­шей­ся в 2000 году шины USB 2.0.

USB 2.0: каноническая версия

До появления RMH-хаба USB-шина представляла немыслимое ранее в х86-архитектуре на­гро­мож­де­ние кон­т­рол­ле­ров, об­слу­жи­ва­ю­щих один и тот же USB-порт.

Перед разработчиками комбинированной реализации USB-подсистемы стояла следующая задача. Ком­му­ни­ка­ции на ско­ро­с­тях Low Speed (1.5 Mbps) и Full Speed (12 Mbps) требовали кон­т­рол­ле­ров UHCI/OHCI, а вы­со­ко­ско­рост­ные USB 2.0 High Speed-устройства (480 Mbps) необходимо было под­клю­чать уже к EHCI-контроллерам. Ком­му­та­то­ры, обес­пе­чи­ва­ю­щие решение этой задачи, образуют об­особ­лен­ную под­сис­те­му Port Rout­ing Logic, входящую в состав ар­хи­тек­ту­ры EHCI и на­хо­дя­щу­ю­ся под про­г­рам­мным кон­т­ро­лем драйвера EHCI.

Согласно алгоритму работы Port Routing Logic, начальное подключение периферийного USB-устройства про­ис­хо­ди­ло к ско­рост­но­му контроллеру EHCI (Enhanced Host Controller Interface USB 2.0). Если в процессе «пе­ре­го­во­ров» (hand­shake) ока­зы­ва­лось, что периферия не поддерживает режим High Speed, драйвер EHCI формировал команду для Port Routing Logic. Она обеспечивала передачу устройства в распоряжение кон­т­рол­ле­ра-ком­па­ньо­на (операция EHCI Hand Off). Ввиду того, что управление коммутаторами находится под контролем программного обес­пе­че­ния, ряд ре­а­ли­за­ций BIOS/UEFI предусматривали небольшую кас­то­ми­за­цию этой стандартной по­сле­до­ва­тель­но­с­ти, что ино­г­да мож­но ви­деть, изучая набор опций CMOS Setup.

Использование Port Routing Logic для коммутации USB устройства к контроллеру EHCI (режим USB2.0) или контроллеру-компаньону (режим USB1.1)

Очевидно, эволюция хост-контроллеров USB происходила не изолированно, а в тесной связке с раз­ви­ти­ем пер­со­наль­ных плат­форм. Одной из осо­бен­нос­тей контроллера EHCI является опциональная поддержка 64-битной ад­ре­са­ции па­мя­ти при­ме­ни­тель­но к режиму bus master. Это означает, что для передачи поль­зо­ва­тель­ских данных между кон­т­рол­ле­ром и сис­тем­ным ОЗУ, а также размещения служебных структур в опе­ра­тив­ной памяти (рас­пи­са­ние транз­ак­ций) можно использовать память, расположенную выше 4GB. На­бор регистров управления и ста­ту­са кон­т­рол­ле­ра (EHCI me­mo­ry-map­ped IO) также опционально допускает раз­ме­ще­ние вы­ше 4GB, хотя этот факт в боль­шей сте­пе­ни на­хо­дит­ся под контролем PCI-спецификации, чем спецификации EHCI.

Настало время подчеркнуть еще одно неочевидное преимущество связки EHCI+RMH перед при­ме­не­ни­ем кон­т­рол­ле­ров-ком­па­ньо­нов UHCI/OHCI. Если контроллер EHCI поддерживает 64-битную адресацию, то пе­ре­да­ча ин­фор­ма­ции между пе­ри­фе­рий­ным устройством и любой областью памяти выполняется од­ной bus-master операцией контроллера. В то время как контроллеры UHCI/OHCI, использующие 32-битную ад­ре­са­цию могли вести обмен только с ди­а­па­зо­на­ми па­мя­ти, расположенными ниже границы 4 GB (2 в 32 степени байт), а если целевой учас­ток па­мя­ти на­хо­дит­ся выше 4GB, требуется промежуточный буфер и вме­ша­тель­ство центрального процессора для тран­зит­но­го ко­пи­ро­ва­ния дан­ных.

Вместе с тем, надо признать, что недостаточный уровень оптимизации программных стеков ОС то­го вре­ме­ни ни­ве­ли­ро­вал аргументы выше приведенных рассуждений и реальным фактором повышения про­из­во­ди­тель­но­с­ти рас­смот­рен­ное обстоятельство, увы, не стало. Кроме того, будучи опциональной, поддержка 64-бит­ной адресации для EHCI ока­за­лась несколько преждевременной — контроллер вошел в состав сис­те­м­ной логики еще во времена гос­под­ст­ва 32-битных CPU.

Слово за производителями

Как правило, EHCI-контроллеры использовались в виде интегрированных в чипсет подсистем. Такой была сис­тем­ная ло­ги­ка In­tel, NVIDIA, SiS, AMD/ATi, VIA, ALi/ULi. Но два последних производителя выпускали и диск­рет­ные EHCI-чипы, которые вызывали справедливые нарекания пользователей: работа подключенных USB-уст­ройств зачастую бы­ла не­ста­биль­ной, пе­ри­фе­рия иногда «исчезала», а затем снова «находилась» опе­ра­ци­он­ной системой.

Дискретные контроллеры продавались вяло, их использование диктовалось спросом на ап­грейд на­столь­ных сис­тем, ог­ра­ни­чен­ных воз­мож­но­стя­ми USB 1.1. Если требовался качественный и надежный EHCI-кон­т­рол­лер, сим­па­тии поль­зо­ва­те­лей бесспорно указывали на чипы от NEC.

Одним из самых продаваемых дискретных решений оказался USB-контроллер NEC720101

Первенцем был NEC uPF720101, который получил наибольшее распространение, несмотря на то, что в даль­ней­шем по­я­ви­лись и доработанные версии этого EHCI-контроллера (с 2010 года NEC Electronic принадлежит ком­па­нии Re­ne­sas Tech­no­logy). Не случайно адаптер с чипом uPF702101 в данной статье фигурирует на фо­не IEEE1394-адап­те­ра, также созданного на компонентах NEC (чип uPF72873), — USB 2.0 своим по­яв­ле­ни­ем оз­на­ме­но­вал пол­ную по­бе­ду над кон­ку­ри­ру­ю­щей шиной FireWire.

Кабели, разъемы, питание

High Speed, реализованный в USB 2.0 для обмена данными на скоростях до 480 Mbps стал не только бо­лее про­из­во­ди­тель­ным, но и ка­приз­ным по отношению к кабельному хозяйству. Формально, силовые ха­рак­те­рис­ти­ки USB 2.0 пор­та ос­та­лись преж­ни­ми, новая шина их унаследовала от предшественницы:

  • на этапе конфигурирования потребление тока не более 100 мА;
  • потребление не более 500 мА с одного порта для устройств Bus Powered;
  • напряжение питания в диапазоне от 4,40 В до 5,25 В.

Однако, согласно документу USB Cable Parameters, еще в рамках подготовки к спецификации USB 2.0 были оп­ре­де­ле­ны тре­бо­ва­ния к омическим и частотным свойствам кабелей, в частности:

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

Еще на этапе жизненного цикла USB 1.1 важно было заявить такие частотные требования, ко­то­рые ка­бель­ная ин­дус­т­рия смо­г­ла бы внедрить в производство до запуска USB 2.0. По этой причине маркировка ин­тер­фей­с­ных ка­бе­лей «USB 2.0 High Speed Compatible» выглядит неуклюжим маркетинговым ходом, рас­счи­тан­ным на простаков.

Диагностика USB

Пик популярности USB 2.0 совпал с расцветом настольных систем, для которых 8-10 портов уни­вер­саль­ной по­сле­до­ва­тель­ной ши­ны стали нормой. Половина из этого количества об­слу­жи­ва­лась впаянными разъемами, вто­рая по­ло­ви­на окан­чи­ва­лась гребенками разъемов. К ним под­клю­ча­лись ин­тер­фей­с­ные «ко­сич­ки», ве­ду­щие к кре­пеж­ным ско­бам (стойкам) с коннекторами USB-Af.

Тестирование USB-подсистемы

Отсутствие единого стандарта на разводку штыревых разъемов на материнской плате порождало хаос в ком­плек­та­ции стой­ка­ми USB-пор­тов. На повестке дня стояла диагностика подключения внешних разъемов. Обыч­но, эту про­це­ду­ру выполняли с помощью USB-накопителя. Риски его повреждения сборщики от­но­си­ли на свой счет.

Но были и оригинальные решения. В этой связи стоит вспомнить о диагностическом контроллере UTLite, спо­соб­но­го в счи­тан­ные секунды в полном объеме выполнить экстренную экспертизу USB-шины.

Универсальный тестер USB-шины UTLite, разработка и производство IC Book Labs

 

Практическая значимость этого прибора во многом была определена программным обеспечением, не по­те­ряв­шим ак­ту­аль­ность даже сейчас. Появился даже простейший драйвер для UTLite под Linux, способный вы­пол­нить иден­ти­фи­ка­цию уст­рой­ст­ва. Основная функ­ци­о­наль­ность USB-тестера реализуется De­vice Spe­ci­fic ко­ман­да­ми, под­держ­ку ко­то­рых, при на­ли­чии до­ку­мен­та­ции, заинтересованный читатель мо­жет реализовать самостоятельно. Из­ме­нив сле­ду­ю­щие па­ра­мет­ры в исходном тексте, реально использовать его для на­пи­са­ния драй­ве­ров других USB-устройств:

#define USB_VENDOR_ICBOOK 0xB00C   // IC Book USB Vendor ID
#define USB_DEVICE_UTLITE 0x0001   // UTLite USB tester Product ID

Однако, на этом поле уже давно появились более продвинутые решения, лучшее для Windows из которых — ути­ли­та Advanced USB Port Monitor.

Тестирование платформы

Еще одним аспектом диагностического применения USB стала попытка трансляции на нее POST-кодов. Эта идея при­над­ле­жа­ла IBM, но, как часто случается, за реализацию взялась компания Intel.

Для многих такое явление, как USB Debug Port, стало реальностью фантастики. Казалось, технологии не ско­ро при­бли­зят­ся к вне­д­ре­нию подобных решений. Действительность все расставила по местам, что, впро­чем, не до­ба­ви­ло жиз­нен­ных сил этому решению — с появлением USB 3.0 все виды диагностики са­мой шины и, с ее по­мо­щью ком­пью­тер­ной плат­фор­мы, перестали быть приоритетным направлением для массового при­ме­не­ния. Вместе с тем, раз­ра­бо­тан­ная в рам­ках третьего поколения универсальной по­сле­до­ва­тель­ной шины, ар­хи­тек­ту­ра XHCI Debug Port открывает прин­ци­пи­аль­но но­вые воз­мож­но­с­ти для про­ек­тов в рам­ках ис­сле­до­ва­тель­ских ла­бо­ра­то­рий, в том числе от­лад­ки про­грам­мн­ого обес­пе­че­ния с ис­поль­зо­ва­ни­ем целевой и ин­ст­ру­мен­таль­ной платформ.