Патент на изобретение №2341906

(54) ИНТЕРФЕЙС ВЫСОКОСКОРОСТНОЙ ПЕРЕДАЧИ ДАННЫХ С УЛУЧШЕННЫМ УПРАВЛЕНИЕМ СОЕДИНЕНИЕМ

(57) Реферат:

Изобретение относится к протоколу обмена цифровыми сигналами и процессу обмена или передачи сигналов между устройством-хостом и клиентским устройством с высокими скоростями передачи данных. Техническим результатом является повышение эффективности каналов связи и повышение пропускной способности каналов связи. Предложен интерфейс данных для передачи цифровых данных между хостом и клиентом по каналу связи с использованием пакетных структур, связанных друг с другом для формирования протокола связи для передачи заранее определенного набора цифровых данных управления и представления. Протокол сигналов используется канальными контроллерами, выполненными с возможностью генерации, передачи и приема пакетов, образующих протокол связи, и для формирования цифровых данных в виде одного или нескольких типов пакетов данных, причем, по меньшей мере, один из них находится на устройстве-хосте и подключен к клиенту посредством канала связи. Интерфейс обеспечивает двусторонний высокоскоростной механизм передачи данных по «последовательной» линии связи малой дальности. 6 н. и 9 з.п. ф-лы, 101 ил. 17 табл.

Притязание на приоритет по §119 35 U.S.C.

Настоящая заявка на патент притязает на приоритет предварительной заявки на патент 60/519833, озаглавленной “Swithable threshold differential interface”, поданной 12 ноября 2003 г., права на которую принадлежат правообладателю настоящей заявки и которая включена в настоящее описание во всей своей полноте в качестве ссылки.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ НАСТОЯЩЕЕ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

Компьютеры, продукция, связанная с электронными играми, и различные видеотехнологии (например, DVD и кассетные видеомагнитофоны высокой четкости) в последние несколько лет существенно усовершенствовались в отношении предоставления для просмотра конечному пользователю таких устройств неподвижных изображений, видеоизображений, видео по требованию и другой графики, даже некоторых типов текста. Эти достижения, в свою очередь, открыли возможность использования электронных устройств просмотра повышенного разрешения, например видеомониторов высокого разрешения, ТВЧ-мониторов или специальных элементов проецирования изображений. Объединение таких визуальных изображений с аудиоданными высокого разрешения или качества, например, с использованием звуковоспроизведения типа CD, DVD, окружающего звука, применяется для создания более реалистичного, содержательного или правдивого мультимедийного восприятия для конечного пользователя, кроме того, высокомобильные высококачественные акустические системы и музыкальные транспортные механизмы, например MP3-проигрыватели, были разработаны для представления конечным пользователям только аудио. Это привело к повышению требований типичных пользователей к коммерческим электронным устройствам, от компьютеров до телевизоров и даже телефонов, привыкших и ожидающих выхода высокого или высшего качества.

В типичном сценарии представления видео с использованием электронного изделия видеоданные обычно переносятся с использованием современных технологий со скоростью, которую уместно назвать низкой или средней и которая составляет порядка от одного до десяти килобайт в секунду. Затем эти данные либо буферизуются, либо сохраняются в устройствах кратковременного или долговременного хранения для задержанного (позднейшего) воспроизведения на нужном устройстве просмотра. Например, изображения могут переноситься “по Интернету” или с использованием Интернета с помощью программы, установленной на компьютере, имеющем модем или устройство интернет-соединения другого типа, для приема или передачи данных, полезных для цифрового представления изображения. Аналогичный перенос может иметь место с использованием беспроводных устройств, например, портативных компьютеров, снабженных беспроводными модемами, или беспроводных карманных персональных компьютеров (КПК) или беспроводных телефонов.

Принятые данные локально хранятся в элементах, схемах или устройствах памяти, например ОЗУ или флэш-памяти, включая внутренние или внешние запоминающие устройства, например жестких дисках малого размера, для воспроизведения. В зависимости от объема данных и разрешения изображения воспроизведение может начаться сравнительно быстро или со значительно задержкой. Таким образом, в некоторых случаях представление изображения допускает в определенной степени воспроизведение в реальном времени для очень маленьких изображений или изображений с низким разрешением, для которых не требуется много данных, или с использованием буферизации того или иного типа, так что после небольшой задержки некоторый материал представляется, в то время как дальнейший материал переносится. При условии, что на линии передачи данных не происходит прерываний и отсутствуют помехи от других систем или пользователей по отношению к используемому каналу передачи, после начала представления, передача является достаточно прозрачной для конечного пользователя устройства просмотра. Естественно, когда множественные пользователи совместно используют один канал связи, например проводное интернет-соединение, передача может прерываться или ее скорость может оказаться ниже желаемой.

Данные, используемые для создания неподвижных или движущихся изображений, часто сжимаются с использованием одного из нескольких общеизвестных методов, например, установленных Joint Photographic Experts Group (JPEG), Motion Picture Experts Group (MPEG) и другими известными организациями или компаниями в областях массовой информации, компьютерной техники и связи, для ускорения передачи данных по каналу связи. Это позволяет быстрее передавать изображения или данные с использованием меньшего количества битов для передачи данного объема информации.

После передачи данных на “локальное” устройство, например компьютер, имеющий механизм хранения, например память или магнитные или оптические элементы хранения, или на другие устройства-получатели, результирующая информация подвергается снятию сжатия (или воспроизводится с использованием специальных декодирующих проигрывателей) и при необходимости декодированию и подготавливается для надлежащего представления в зависимости от соответствующего доступного разрешения представления и элементов управления. Например, видеоразрешение обычного компьютера в отношении разрешения экрана, выражаемого как X на Y пикселей, обычно бывает низким (480 пикселей), средним (600) или высоким (1024), хотя, в принципе, возможны различные другие разрешения, при желании или необходимости.

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

Из вышеприведенных значений следует, что данное экранное изображение может потребовать передачи примерно от 2,45 мегабит (Мбит) до 33,55 Мбит данных в диапазоне от самого низкого до самого высокого из обычных разрешений и насыщенности соответственно. При просмотре видео или движущихся изображений с частотой 30 кадров в секунду необходимый объем данных составляет примерно от 73,7 до 1,006 мегабит данных в секунду (Мбит/с) или примерно от 9,21 до 125,75 мегабайт в секунду (МБ/с). Кроме того, может стоять задача представления аудиоданных совместно с изображениями, например, для мультимедийного представления, или отдельного представления аудио с высоким разрешением, например, музыки CD-качества. Также могут использоваться дополнительные сигналы, связанные с интерактивными командами, системой управления или сигнализации. Каждая из этих возможностей добавляет дополнительные данные, подлежащие передаче. Кроме того, новейшие технологии связи, включающие в себя телевидение высокой четкости (ТВЧ) и видеозаписи, могут добавлять еще больше данных и информации управления. В любом случае при необходимости передавать данные изображения высокого качества или высокого разрешения и высококачественную аудиоинформацию или сигналы данных конечному пользователю для создания содержательного восприятия необходима линия связи с высокой скоростью передачи данных между элементами представления и источником или устройством-хостом, которое предназначено для обеспечения таких типов данных.

Некоторые современные последовательные интерфейсы обычно способны работать на скоростях передачи данных около 115 килобайт в секунду (кБ/с) или 920 килобит в секунду (кбит/с). Другие интерфейсы, например последовательные интерфейсы USB, могут осуществлять передачу данных на скоростях 12 МБ/с, и специальные высокоскоростные линии связи, например, отвечающие стандарту Institute of Electrical and Electronics Engineers (IEEE) 1394, могут работать на скоростях порядка от 100 до 400 МБ/с. К сожалению, этих скоростей недостаточно для вышеупомянутых высоких скоростей передачи данных, необходимых для использования в будущих устройствах беспроводной передачи данных и других службах для обеспечения выходных сигналов высокого разрешения, насыщенных содержанием, для работы портативных видеодисплеев или аудиоустройств. Это могут быть компьютеры для деловых или иных представлений, игровые устройства и т.п., кроме того, эти интерфейсы требуют для работы использования значительного объема программного обеспечения хоста или системы и клиента. Их программные стеки протоколов также создают нежелательно большой объем служебной нагрузки, особенно применительно к мобильным беспроводным устройствам или телефонам. Такие устройства имеют существенные ограничения по памяти и энергопотреблению, а также предоплаченный объем трафика. Кроме того, некоторые из этих интерфейсов используют громоздкие кабели, которые слишком тяжелы и не удовлетворяют эстетическим требованиям мобильной связи, сложные разъемы, добавляющие стоимость, или просто потребляют слишком много энергии.

Имеются другие известные интерфейсы, например, Analog Video Graphics Adapter (VGA), Digital Video Interactive (DVI) или Gigabit Video Interface (GVIF). Первые два из них являются интерфейсами параллельного типа, которые обрабатывают данные на более высоких скоростях передачи данных, но могут использовать слишком тяжелые кабели и потреблять большую мощность, порядка нескольких ватт. Ни одна из этих характеристик не годится для использования в портативных бытовых электронных приборах. Даже третий интерфейс потребляет слишком большую мощность и использует дорогостоящие или громоздкие разъемы.

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

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

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

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

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

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

Заявители предложили такие новые механизмы передачи в патентной заявке США №№ 10/020520 и 10/236657, озаглавленных “Generating And Implementing A Communication Protocol And Interface For High Data Rate Signal Transfer”, сейчас разрешенных, которые присвоены правообладателю настоящего изобретения и включены сюда посредством ссылки. Кроме того, заявка за № 10/860116, озаглавленная “Generating and Implementing a Signal Protocol and Interface for Higher Data Rates”. Подходы, рассмотренные в этих заявках, могут значительно повысить скорость передачи данных для больших объемов данных в высокоскоростных сигналах данных. Однако потребности в увеличении скоростей передачи данных, особенно в связи с представлениями видео, продолжают расти. Даже с учетом современных разработок в области технологии передачи данных по-прежнему необходимо прилагать усилия по увеличению скоростей передачи данных, повышению эффективности каналов связи и повышению пропускной способности каналов связи. Поэтому существует постоянная необходимость в разработке нового или усовершенствованного механизма передачи, который нужен для повышения пропускной способности канала связи между устройствами хоста и клиента.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

Варианты осуществления изобретения предусматривают Mobile Data Digital Interface (MDDI) (мобильный интерфейс передачи цифровых данных) для передачи цифровых данных на высокой скорости между устройством-хостом и устройством-клиентом по каналу связи, в котором применяется совокупность или последовательность пакетных структур для формирования протокола связи для передачи заранее выбранного набора цифровых данных управления и представления между устройствами хоста и клиента. Протокол передачи сигналов или канальный уровень используется физическим уровнем канальных контроллеров хостов или клиентов. По меньшей мере, один канальный контроллер, присутствующий на устройстве-хосте, подключается к устройству-клиенту по каналу или линии связи и предназначен для генерации, передачи и приема пакетов, образующих протокол связи, и для формирования цифровых данных представления в виде пакетов данных одного или нескольких типов. Интерфейс обеспечивает двустороннюю передачу информации между хостом и клиентом, которые могут размещаться в общем корпусе или опорной структуре.

Практически вся реализация имеет цифровую природу за исключением дифференциальных драйверов и приемников, которые легко можно реализовать на микросхеме цифровых КМОП; требует всего 6 сигналов и работает почти на любой скорости передачи данных, удобной для разработчика системы. Простой протокол физического и канального уровня допускает простую интеграцию, и эта простота плюс неактивное состояние позволяет портативной системе иметь очень низкое энергопотребление системы.

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

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

Пакеты группируются совместно с медиакадрами, которые передаются между устройствами хоста и клиента и имеют заранее заданную фиксированную длину, с заранее определенным количеством пакетов, имеющих разные переменные длины. Каждый пакет содержит поле длины пакета, одно или несколько полей данных пакета и поле проверки циклической избыточности. Пакет Sub-frame Header Packet (пакет заголовка подкадра) передается или позиционируется в начале передачи других пакетов от канального контроллера хоста. Один или несколько пакетов типа Video Stream (видеопоток) и пакетов типа Audio Stream (аудиопоток) используются протоколом связи для передачи данных типа видео и данных типа аудио соответственно от хоста на клиент по прямой линии связи для представления пользователю устройства-клиента. Один или несколько пакетов типа Reverse Link Encapsulation (пакет инкапсуляции обратной линии связи) используются протоколом связи для передачи данных от устройства-клиента на канальный контроллер хоста. Эта передача согласно некоторым вариантам осуществления включает в себя передачу данных от внутренних контроллеров, имеющих, по меньшей мере, одно устройство MDDI, на внутренние видеоэкраны. Другие варианты осуществления предусматривают передачу на внутренние акустические системы и передачу от различных устройств ввода, включая джойстики и сложные клавиатуры на внутренние устройства-хосты.

Пакеты типа Filler (заполнитель) генерируются канальным контроллером хоста для заполнения периодов передачи прямой линии связи, которые не имеют данных. Совокупность других пакетов используется протоколом связи для передачи видеоинформации. Такие пакеты включают в себя пакеты типа Color Map (карта цветов), Bit Block Transfer (передача блока битов), Bitmap Area Fill (заполнение области битовой карты), Bitmap Pattern Fill (заполнение шаблона битовой карты) и Transparent Color Enable (разрешение прозрачного цвета). Пакеты типа User-Defined Stream (поток, заданный пользователем) используются протоколом связи для передачи интерфейсных/заданных пользователем данных. Пакеты типа Keyboard Data (данные клавиатуры) и Pointing Device Data (данные указательного устройства) используются протоколом связи для передачи данных на и от пользовательских устройств ввода, связанных с устройством-клиентом. Пакет типа Link Shutdown (блокирование линии связи) используется протоколом связи для окончания передачи данных в любом направлении по каналу связи.

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

Канальный контроллер хоста запрашивает информацию возможностей дисплея от устройства-клиента, чтобы определить, с каким типом данных и на каких скоростях передачи данных клиент может работать на интерфейсе. Канальный контроллер клиента передает возможности отображения или представления на канальный контроллер хоста с использованием, по меньшей мере, одного пакета типа Client Capability (возможности клиента). Протокол связи использует множественные режимы передачи, каждый из которых позволяет параллельно передавать различные максимальные количества битов данных в течение данного периода времени, причем каждый режим выбирается путем согласования между канальными контроллерами хоста и клиента. Эти режимы передачи динамически регулируются в ходе передачи данных, и на обратной линии связи не обязательно использовать тот же режим передачи, что и прямой линии связи.

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

Фиг.1В – основная среда, в которой могут работать варианты осуществления изобретения, включая использование миниатюрного устройства отображения или проектора и элементов представления аудио, используемых совместно с беспроводным приемопередатчиком.

Фиг.1С – основная среда, в которой могут работать варианты осуществления изобретения, включая использование внутренних устройств отображения или представления аудио, используемых в портативном компьютере.

Фиг.1D – основная среда, в которой могут работать варианты осуществления изобретения, включая использование внутренних устройств отображения или представления аудио, используемых в беспроводным приемопередатчике.

Фиг.2 – общая концепция интерфейса Mobile Digital Data Interface между хостом и клиентом.

Фиг.3 – структура пакета, полезного для реализации передачи данных от устройства-клиента на устройство-хост.

Фиг.4 – использование канального контроллера MDDI и типов сигналов, передаваемых между хостом и клиентом по проводникам физической линии передачи данных для интерфейса 1 типа.

Фиг.5 – использование канального контроллера MDDI и типов сигналов, передаваемых между хостом и клиентом по проводникам физической линии передачи данных для интерфейсов 2, 3 и 4 типов.

Фиг.6 – структура кадров и подкадров, используемых для реализации протокола интерфейса.

Фиг.7 – общая структура пакетов, используемых для реализации протокола интерфейса.

Фиг.8 – формат пакета Sub-frame Header Packet.

Фиг.9 – формат и содержимое пакета Filler Packet.

Фиг.10 – формат пакета Video Stream Packet.

Фиг.11А-11Е – формат и содержимое поля Video Data Format Descriptor, используемого на фиг.10.

Фиг.12 – использование упакованных и неупакованных форматов данных.

Фиг.13 – формат пакета Audio Stream Packet.

Фиг.14 – использование выровненных по границе байта и упакованных форматов ИКМ для данных.

Фиг.15 – формат пакета User-Defined Stream Packet.

Фиг.16 – формат пакета Color Map Packet.

Фиг.17 – формат пакета Reverse Link Encapsulation Packet.

Фиг.18 – формат пакета Client Capability Packet.

Фиг.19 – формат пакета Keyboard Data Packet.

Фиг.20 – формат пакета Pointing Device Data Packet.

Фиг.21 – формат пакета Link Shutdown Packet.

Фиг.22 – формат пакета Client Request and Status Packet

Фиг.23 – формат пакета Bit Block Transfer Packet.

Фиг.24 – формат пакета Bitmap Area Fill Packet.

Фиг.25 – формат пакета Bitmap Pattern Fill Packet.

Фиг.26 – формат пакета Communication Link Data Channel Packet.

Фиг.27 – формат пакета Interface Type Handoff Request Packet.

Фиг.28 – формат пакета Interface Type Acknowledge Packet.

Фиг.29 – формат пакета Perform Type Handoff Packet.

Фиг.30 – формат пакета Forward Audio Channel Enable Packet.

Фиг.31 – формат пакета Reverse Audio Sample Rate Packet.

Фиг.32 – формат пакета Digital Content Protection Overhead Packet.

Фиг.33 – формат пакета Transparent Color Enable Packet.

Фиг.34 – формат пакета Round Trip Delay Measurement Packet.

Фиг.35 – хронирование событий в пакете Round Trip Delay Measurement Packet.

Фиг.36 – иллюстративная реализация блока генерации и проверки CRC, полезного для реализации изобретения.

Фиг.37А – хронирование сигналов CRC для устройства, показанного на фиг.36, при передаче пакетов данных.

Фиг.37В – хронирование сигналов CRC для устройства, показанного на фиг.36, при приеме пакетов данных.

Фиг.38 – этапы обработки типичного служебного запроса без конфликтов.

Фиг.39 – этапы обработки типичного служебного запроса, поданного после начала последовательности перезапуска линии связи, конфликтующего с запуском канала.

Фиг.40 – иллюстрирует, как можно передавать последовательность данных с использованием кодирования DATA-STB.

Фиг.41 – схема, полезная для генерации сигналов DATA и STB из входных данных на хосте с последующим восстановлением данных на клиенте.

Фиг.42 – драйверы и нагрузочные резисторы, полезные для реализации одного варианта осуществления.

Фиг.43 – этапы и уровни сигнала, применяемые клиентом для получения услуги от хоста и хостом для обеспечения такой услуги.

Фиг.44 – относительный разнос между переходами на линии данных Data0, других линиях данных (DataX) и линиях стробирующего сигнала (Stb).

Фиг.45 – иллюстрирует наличие задержки в отклике, которая может возникнуть, когда хост отключает драйвер хоста после передачи пакета.

Фиг.46 – иллюстрирует наличие задержки в отклике, которая может возникнуть, когда хост включает драйвер хоста для передачи пакета.

Фиг.47 – соотношение на входе приемника хоста между хронированием передаваемых данных и передними и задними фронтами стробирующих импульсов.

Фиг.48 – характеристики переключения и соответствующая задержка на выходе клиента, обусловленная обратным хронированием данных.

Фиг.49 – обобщенная схема этапов обработки сигнала и условий, позволяющих реализовать синхронизацию с использованием конечного автомата.

Фиг.50 – типичные величины задержки, имеющие место при обработке сигнала на прямой и обратной линиях связи в системе с применением MDDI.

Фиг.51 – измерение пограничной двусторонней задержки.

Фиг.52 – изменения скорости передачи данных на обратной линии связи.

Фиг.53 – график зависимости значения Reverse Rate Divisor от скорости передачи данных на прямой линии связи.

Фиг.54А и 54В – этапы работы интерфейса.

Фиг.55 – общая схема устройства интерфейса для обработки пакетов.

Фиг.56 – формат пакета Forward Link Packet.

Фиг.57 – типичные значения задержки и рассогласования при распространении в интерфейсе линии связи 1 типа.

Фиг.58 – Data, Stb и Clock Recovery Timing на линии связи 1 типа для иллюстративной обработки сигнала посредством интерфейса.

Фиг.59 – типичные значения задержки и рассогласования при распространении в интерфейсах линии связи 2, 3 и 4 типов.

Фиг.60A, 60B и 60C – различные возможности хронирования двух сигналов данных и MDDI_Stb относительно друг друга, а именно идеальная, с опережением и с задержкой соответственно.

Фиг.61 – иллюстративные разводки контактов разъемов интерфейса, используемых в интерфейсах 1 и 2 типов.

Фиг.62A и 62B – возможные формы сигнала для DDI_Data и MDDI_Stb для интерфейсов 1 и 2 типов соответственно.

Фиг.63 – обобщенная схема альтернативных этапов обработки сигнала и условий, позволяющих реализовать синхронизацию с использованием конечного автомата.

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

Фиг.65 – иллюстративная обработка переноса кода ошибки.

Фиг.66 – устройство, полезное для обработки переноса кода ошибки.

Фиг.67А – обработка переноса кода ошибки для перегрузки кода.

Фиг.67В – обработка переноса кода ошибки для приема кода.

Фиг.68А – этапы обработки для активизации, инициированной хостом.

Фиг.68В – этапы обработки для активизации, инициированной клиентом.

Фиг.68C – этапы обработки для активизации, инициированной хостом и клиентом.

Фиг.69 – формат пакета Request VCP Feature Packet.

Фиг.70 – формат пакета VCP Feature Reply Packet.

Фиг.71 – формат поля VCP Feature Reply List.

Фиг.72 – формат пакета Set VCP Feature Packet.

Фиг.73 – формат пакета Request Valid Parameter Packet.

Фиг.74 – формат пакета Valid Parameter Reply Packet.

Фиг.75 – формат пакета Alpha-Cursor Image Capability Packet.

Фиг.76 – формат пакета Alpha-Cursor Transparency Map Packet.

Фиг.77 – формат пакета Alpha-Cursor Image Offset Packet.

Фиг.78 – формат пакета Alpha-Cursor Video Stream Packet.

Фиг.79 – формат пакета Scaled Video Stream Capability Packet.

Фиг.80 – формат пакета Scaled Video Stream Setup Packet.

Фиг.81 – формат пакета Scaled Video Stream Acknowledgement Packet.

Фиг.82 – формат пакета Scaled Video Stream Packet.

Фиг.83 – формат пакета Request Specific Status Packet.

Фиг.84 – формат пакета Valid Status Reply List Packet.

Фиг.85А – формат пакета Packet Processing Delay Parameters Packet.

Фиг.85В – формат элемента списка Delay Parameters List

Фиг.86 – формат пакета Personal Display Capability Packet.

Фиг.87А – формат пакета Client Error Report Packet.

Фиг.87В – формат элемента списка Error Report List.

Фиг.88 – формат пакета Client Identification Packet.

Фиг.89 – формат пакета Alternate Display Capability Packet.

Фиг.90 – формат пакета Register Access Packet.

Фиг.91А-91С – использование двух буферов дисплея для уменьшения видимых артефактов.

Фиг.92 – два буфера с обновлением дисплея более быстрым, чем передача изображения.

Фиг.93 – два буфера с обновлением дисплея более медленным, чем передача изображения.

Фиг.94 – два буфера с обновлением дисплея значительно более быстрым, чем передача изображения.

Фиг.95 – три буфера с обновлением дисплея более быстрым, чем передача изображения.

Фиг.96 – три буфера с обновлением дисплея более медленным, чем передача изображения.

Фиг.97 – один буфер с обновлением дисплея более быстрым, чем передача изображения.

Фиг.98 – соединение хост-клиент посредством гирляндной цепи и концентратора.

Фиг.99 – устройства-клиенты, подключенные посредством комбинации концентраторов и гирляндных цепей.

Фиг.100 – карта цветов.

Фиг.101 – анализ тока утечки.

ПОДРОБНОЕ ОПИСАНИЕ

I. Обзор

Общей задачей изобретения является обеспечение вышеописанного интерфейса Mobile Display Digital Interface (MDDI), который обеспечивает экономичный механизм передачи с низким энергопотреблением, который позволяет передавать данные на высокой или очень высокой скорости по линии связи малой дальности между устройством-хостом и устройством-клиентом, например, элементом отображения, с использованием линии или канала передачи данных “последовательного” типа. Этот механизм базируется на реализации миниатюрных разъемов и тонких гибких кабелей, которые особенно полезны при подключении внутренних (по отношению к корпусу или опорному каркасу) элементов отображения или устройств ввода к центральному контроллеру или внешних элементов или устройств отображения, например переносных микродисплеев (солнцезащитных очков или проекторов) к портативным компьютерам, беспроводным устройствам связи или развлекательным устройствам.

Хотя в название протокола входят слова Mobile и Display, следует понимать, что они включены в него только для удобства, чтобы иметь стандартное название, легко понятное специалистам, работающим с интерфейсом и протоколом. Однако ознакомившись с представленными ниже вариантами осуществления, можно без труда понять, что этот протокол и соответствующую структуру интерфейса можно с успехом применять в областях, не связанных с мобильной связью и дисплеями, и ярлык MDDI не призван налагать какие-либо ограничения на сущность или область применения изобретения или различные варианты его осуществления.

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

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

Характеристики или атрибуты MDDI таковы, что они не зависят от конкретной технологии отображения или представления. Это весьма гибкий механизм передачи данных на высокой скорости безотносительно ко внутренней структуре этих данных, а также к функциональным аспектам реализующих их данных или команд. Это позволяет регулировать хронирование передаваемых пакетов данных для адаптации к индивидуальным особенностям конкретных устройств-клиентов, например уникальным требованиям к отображению для определенных устройств, или для удовлетворения требований комбинированного аудио и видео для некоторых A-V систем или для определенных устройств ввода, например джойстиков, сенсорных панелей и т.п. Интерфейс, а также выбранный протокол, по которому он работает, скрыт от элемента отображения или устройства-клиента. Кроме того, совокупные данные последовательной линии связи или скорость передачи данных может разниться на несколько порядков величины, что позволяет конструктору системы связи или устройства-хоста оптимизировать стоимость, требования к мощности, сложность устройства-клиента и частоту обновления устройства-клиента.

Интерфейс данных представлен в основном для использования при передаче больших объемов данных с высокой скоростью по “проводной” сигнальной линии или небольшому кабелю. Однако в некоторых вариантах применения может быть выгодно применять беспроводную линию связи, в том числе оптические линии связи, с условием, что они приспособлены для использования тех же структур пакетов и данных, которые разработаны для протокола интерфейса, и могут поддерживать нужный уровень передачи при достаточно низком энергопотреблении или сложности, чтобы оставаться практически применимыми.

II. Окружение

Типичное приложение можно видеть на фиг.1А и 1В, где показано, что портативный компьютер 100 и беспроводной телефон или устройство КПК 102 обмениваются данными с устройствами отображения 104 и 106 соответственно совместно с системами 108 и 112 аудиовоспроизведения. Кроме того, на фиг.1а показаны возможные соединения с более крупным дисплеем, или экраном 114, или проектором 116 изображения, которые для ясности показаны только на одной фигуре, но также имеют возможность подключения к беспроводному устройству 102. Беспроводное устройство может в данный момент принимать данные или иметь ранее сохраненный определенный объем данных мультимедийного типа в элементе или устройстве памяти для дальнейшего представления для просмотра и/или прослушивания конечным пользователем беспроводного устройства. Поскольку типичное беспроводное устройство используется для передачи голоса и простого текста в течение большей части времени, оно имеет достаточно малый экран дисплея и простую аудиосистему (громкоговорители) для передачи информации пользователю устройства 102.

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

Это делает представление более сложных или “богатых” данных менее полезным или приятным. Поэтому промышленность развивает другие механизмы и устройства для представления информации конечным пользователям и обеспечения минимального уровня желательного удовольствия или положительных ощущений.

Согласно рассмотренному выше в настоящее время разработано или разрабатывается несколько типов устройств отображения для представления информации конечным пользователям устройства 100. Например, одна или несколько компаний разработали комплекты солнцезащитных очков, которые проецируют изображение перед глазами пользователя устройства для представления визуального отображения. Будучи надлежащим образом размещены, такие устройства эффективно “проецируют” виртуальное изображение, например, воспринимаемое глазами пользователя, которое значительно больше элемента, обеспечивающего визуальный выход. Таким образом, очень маленький проекционный элемент позволяет глазу(ам) пользователя “видеть” изображения в значительно большем масштабе, чем позволяют обычные экраны ЖКД и т.п. Использование крупных виртуальных экранных изображений также позволяет использовать изображения значительно более высокого разрешения, чем позволяют более ограниченные экранные дисплеи ЖКД. Другие устройства отображения могут включать в себя, но без ограничения малые экраны ЖКД или различные элементы индикаторной панели, проекционные линзы и драйверы дисплея для проецирования изображений на поверхность и т.п.

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

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

Для звуковоспроизведения на фиг.1А показаны внешние громкоговорители 114, которые могут быть дополнены дополнительными элементами, например сабвуферами или громкоговорителями “окружающего звука” для переднего и заднего излучения звука. В то же время громкоговорители или наушники 108 показаны как встроенные в опорный каркас или механизм миниатюрного устройства отображения 106, показанного на фиг.1В. Следует знать, что можно использовать другие элементы аудио- или звуковоспроизведения, в том числе усиления или формирования звукового сигнала.

В любом случае, как рассмотрено выше, при необходимости передавать данные изображения высокого качества или высокого разрешения и высококачественную аудиоинформацию или сигналы данных от источника данных конечному пользователю по одной или нескольким линиям связи 110 требуется высокая скорость передачи данных. Таким образом, линия связи 110 с очевидностью является потенциальным “узким местом” при передаче данных, которая рассмотрена выше, и ограничивает производительность системы, поскольку современные механизмы передачи не достигают высоких скоростей передачи данных, которые обычно требуются. В рассмотренном выше примере для более высоких разрешений изображения, например 1024 на 1024 пикселей с насыщенностью цветов 24-32 бита на пиксель и при скоростях передачах данных 30 кадров/с скорости передачи данных могут достигать свыше 755 Мбит/с или выше. Кроме того, такие изображения могут быть представлены как часть мультимедийного представления, которое включает в себя аудиоданные и, возможно, дополнительные сигналы, связанные с интерактивными играми или передачами, или различные команды, информация управления или сигналы, дополнительно увеличивающие объем данных и скорость передачи данных.

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

Еще одно типичное приложение, связанное со многими из вышеперечисленных и других усовершенствований видеоэкранов и прочих устройств ввода и вывода, показано на фиг.1С и 1D, где показано, что портативный компьютер 130 и беспроводной телефон или устройство КПК 140 обмениваются данными со “внутренними” устройствами отображения 134 и 144 соответственно, а также с системами 136 и 146 звуковоспроизведения.

На фиг.1С и 1D участки, показанные частично в разрезе, электронных устройств или изделий в целом используются для демонстрации местонахождения одного или нескольких внутренних хостов и контроллеров в одной части устройства с обобщенной линией связи, в данном случае 138 и 148 соответственно, подключающей их к элементам или экранам видеодисплея, имеющим соответствующие клиенты, через поворотное соединение некоторого известного типа, широко используемого в современной электронике. Можно видеть, что объем данных, участвующих в этих передачах, требует большого количества проводников, образующих линии связи 138 и 148. Подсчитано, что такие линии связи должны содержать 90 или более проводников, чтобы удовлетворять современным растущим потребностям в использовании развитых цветных и графических интерфейсов, элементов отображения на таких устройствах ввиду известных типов параллельных и других интерфейсов, имеющихся для передачи таких данных.

К сожалению, необходимые скорости передачи данных не обеспечиваются современными технологиями передачи данных. Это относится как к объему “необработанных” данных, подлежащих передаче в единицу времени, так и к простым в изготовлении, экономичным физическим механизмам передачи.

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

III. Архитектура системы высокоскоростного цифрового интерфейса данных

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

А. Обзор

Устройства, подключенные или осуществляющие связь посредством линии связи MDDI, называются хостом и клиентом, причем клиентом обычно является устройство отображения того или иного типа, хотя возможны другие устройства ввода и вывода. Данные от хоста на дисплей переносятся в прямом направлении (так называемый прямой трафик или прямая линия связи), а данные от клиента на хост переносятся в обратном направлении (обратный трафик или линия связи) по команде хоста. Это показано в виде основной конфигурации на фиг.2. Согласно фиг.2 хост 202 подключен к клиенту 204 с использованием двустороннего канала связи 206, который, как показано, содержит прямую линию связи 208 и обратную линию связи 210. Однако эти каналы образованы общим набором проводников, передача данных по которым эффективно переключается между операциями прямой или обратной линии связи. Это позволяет значительно сократить количество проводников, тем самым кардинально решив одну из многих проблем, связанных с современными подходами к высокоскоростной передаче данных в маломощных средах, например мобильных электронных устройствах.

Согласно описанному в другом месте хост содержит несколько типов устройств, которые могут воспользоваться настоящим изобретением. Например, хост 202 может представлять собой портативный компьютер в виде карманного, переносного или аналогичного мобильного вычислительного устройства. Это также может быть карманный персональный компьютер (КПК), пейджер или любой из многих беспроводных телефонов или модемов. Альтернативно хост 202 может быть портативным устройством для развлечения или представления, например портативным проигрывателем DVD или CD или игровым устройством.

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

В то же время клиент 204 может содержать разнообразные устройства, полезные для представления информации конечному пользователю или для представления информации от пользователя хосту. Например, микродисплей, встроенный в солнцезащитные или обычные очки, проекционное устройство, встроенное в шляпу или шлем, маленький экран или даже голографический элемент, установленный в автомобиле, например в окне или ветровом стекле, или различные громкоговорители, наушники или акустические системы для представления высококачественного звука или музыки. Другие устройства представления включают в себя проекторы или проекционные устройства, используемые для представления информации для встреч или для кино и телевизионных изображений. Другой пример это использование сенсорных панелей или чувствительных устройств, устройств ввода с функцией распознавания речи; сканеры системы безопасности и т.п., к которым можно обращаться для переноса значительного объема информации от пользователя устройства или системы с помощью небольшого фактического “ввода”, отличного от прикосновения или звука от пользователя. Кроме того, базовые блоки для компьютеров и автомобильные комплекты или настольные комплекты и держатели для беспроводных телефонов могут действовать как устройства интерфейса к конечным пользователям или к другим устройствам и оборудованию и использовать либо клиенты (устройства ввода или вывода, например, мыши) или хосты для помощи в передаче данных, особенно с использованием высокоскоростных сетей.

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

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

Совокупная скорость передачи данных на последовательной линии связи на каждой сигнальной паре, используемой этой структурой интерфейса, может варьироваться на много порядков величины, что позволяет конструктору системы или устройства легко оптимизировать стоимость, мощность, сложность реализации и частоту обновления дисплея для данного применения или данной цели. Атрибуты MDDI не зависят от технологии дисплея или другого устройства представления (клиента назначения). Хронирование пакетов данных, передаваемых по интерфейсу, можно легко адаптировать к характерным особенностям конкретных клиентов, как-то устройств отображения, акустических систем, элементов памяти и управления или комбинированным требованиям хронирования аудиовидеосистем. Хотя это позволяет иметь систему с очень малым энергопотреблением, для использования протокола MDDI на, по меньшей мере, некотором уровне не требуется, чтобы различные клиенты имели кадровые буферы.

В. Типы интерфейсов

Интерфейс MDD рассматривается как относящийся к, по меньшей мере, четырем, а возможно, и более чем-то отличающимся физическим типам интерфейсов, используемым в области связи и в компьютерной области. Они называются просто тип 1, тип 2, тип 3 и тип 4, хотя специалисты в данной области могут применять другие ярлыки или обозначения в зависимости от конкретных областей их применения или промышленности, с которой они связаны. Например, простые аудиосистемы используют меньше соединений, чем более сложные мультимедийные системы и могут иначе ссылаться на такие особенности, как “каналы”, и т.д.

Интерфейс 1 типа имеет конфигурацию из 6 проводов или проводников или проводящих элементов другого типа, что делает этот интерфейс пригодным для мобильных или беспроводных телефонов, КПК, электронных игр и портативных медиапроигрывателей, например проигрывателей CD или проигрывателей MP3 и аналогичных устройств или устройств, используемых на аналогичных типах бытовой электроники. Согласно одному варианту осуществления интерфейс может иметь конфигурацию из 8 проводов (проводников), которая более пригодна для персональных компьютеров типа лэптоп, ноутбук или настольных компьютеров и аналогичных устройств или применений, которые не требуют быстрого обновления данных и которые не имеют встроенного канального контроллера MDDI. Этот тип интерфейса также отличается использованием дополнительного двухпроводного интерфейса универсальной последовательной шины (Universal Serial Bus (USB)), что чрезвычайно полезно для работы в существующих операционных системах или с программным обеспечением, имеющимся на большинстве персональных компьютерах.

Интерфейсы 2, 3 и 4 типов пригодны для высокопроизводительных клиентов или устройств и используют гораздо более сложные кабели с дополнительными проводниками типа витой пары для обеспечения надлежащего экранирования и передачи сигналов данных с низкими потерями.

Интерфейс 1 типа передает сигналы, которые могут содержать визуальную, звуковую, управляющую и ограниченную сигнальную информацию, и обычно используется для мобильных клиентов или устройств-клиентов, которые не требуют полноскоростных видеоданных высокого разрешения. Интерфейс 1 типа легко может поддерживать разрешение SVGA на 30 кадр/с плюс 5.1-канальное аудио и в минимальной конфигурации может использовать всего три пары проводов, две пары для передачи данных и одну пару для подачи питания. Этот тип интерфейса предназначен в основном для таких устройств, как мобильные беспроводные устройства, где USB-хост обычно не присутствует в таком устройстве для связи и передачи сигналов. В этой конфигурации мобильное беспроводное устройство является устройством-хостом MDDI и действует как ведущее устройство, которое управляет линией связи от хоста, по которой в общем случае осуществляется передача данных на клиент (прямой трафик или прямая линия связи) для представления, отображения или воспроизведения.

В этом интерфейсе хост разрешает прием передаваемых данных на хосте от клиента (обратный трафик или обратная линия связи) путем передачи особой команды или типа пакета на клиент, которая(ый) позволяет ему владеть шиной (линией связи) в течение заданного времени и передавать данные на хост в виде пакетов обратной линии связи. Это показано на фиг.3, где тип пакета, именуемый пакетом инкапсуляции (рассмотрен ниже) используется для передачи пакетов обратной линии связи по линии связи, создания обратной линии связи. Интервал времени, выделенный хосту для опроса клиента на предмет данных, заранее задается хостом и зависит от требований каждого конкретного варианта применения. Этот тип полудуплексной двусторонней передачи данных особенно полезен, когда порт USB недоступен для передачи информации или данных от клиента.

Высокопроизводительные дисплеи с высоким разрешением, обеспечивающим ТВЧ или аналогичные форматы, требуют потоки данных со скоростью около 1,5 Гбит/с для поддержки видео кинематографического качества. Интерфейс 2 типа поддерживает высокие скорости передачи данных благодаря параллельной передаче 2 битов, 3 типа – параллельной передаче 4 битов и 4 типа – параллельной передаче 8 битов. Интерфейсы 2 и 3 типов используют те же кабель и разъем, что и интерфейс 1 типа, но могут работать на вдвое и вчетверо более высокой скорости передачи данных для поддержки более высокопроизводительных видеоприложений на портативных устройствах. Интерфейс 4 типа пригоден для клиентов или дисплеев с очень высокой производительностью и требует несколько больший кабель, который содержит дополнительные витые пары для передачи сигналов данных.

Протокол, используемый в MDDI, позволяет хосту 1, 2, 3 или 4 типа в общем случае связываться с любым клиентом 1, 2, 3 или 4 типа, согласуя наивысшую скорость передачи данных, которую можно использовать. Для задания производительности линии связи используются возможности или доступные особенности так называемого наиболее слабого устройства. Как правило, даже для систем, где и хост, и клиент способны использовать интерфейсы 2, 3 или 4 типа, оба начинают работать как на интерфейсе 1 типа. Затем хост определяет возможности клиента назначения и согласовывает переход или реконфигурацию в любой из режимов работы 2, 3 или 4 типа в зависимости от конкретного применения.

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

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

Нередко пользователи протокола MDDI могут различать “внешний” режим и “внутренний” режим. Внешний режим описывает использование протокола и интерфейса для подключения хоста в одном устройстве к клиенту вне этого устройства, который находится на расстоянии примерно 2 метра или около того от хоста. В этом случае хост может также подавать питание на внешний клиент, чтобы оба устройства могли легко работать в мобильной среде. Внутренний режим описывает случай, когда хост подключен к клиенту, содержащемуся в том же устройстве, например в общем корпусе или опорном каркасе или структуре того или иного вида. Примерами являются применения в беспроводном телефоне или другом беспроводном устройстве или портативном компьютере или игровом устройстве, где клиентом является дисплей или драйвер дисплея, или устройство ввода, например клавиатура или сенсорная панель, или акустическая система, и хостом является центральный контроллер, графическая машина или элемент ЦП. Поскольку в применениях внутреннего режима клиент размещается гораздо ближе к хосту, чем в применениях внешнего режима, то в таких конфигурациях обычно отсутствуют требования, рассмотренные для подачи питания на клиент.

С. Физическая структура интерфейса

На фиг.4 и 5 показана общая конфигурация устройства или канального контроллера для установления связи между устройствами хоста и клиента. Согласно фиг.4 и 5 канальный контроллер MDDI 402 и 502 установлены в устройстве-хосте 202 и канальный контроллер MDDI 404 и 504 установлены в устройстве-клиенте 204. Как и раньше, хост 202 подключен к клиенту 204 с использованием двустороннего канала связи 406, содержащего несколько проводников. Согласно рассмотренному ниже канальные контроллеры хоста и клиента могут быть изготовлены в виде интегральной схемы с использованием единой конструкции схемы, которую можно настраивать, регулировать или программировать либо как контроллер хоста (драйвер), либо как контроллер клиента (приемник). Это обеспечивает снижение стоимости благодаря более массовому производству единого устройства схемы.

Согласно фиг.5 канальный контроллер MDDI 502 установлен в устройстве-хосте 202′ и канальный контроллер MDDI 504 установлен в устройстве-клиенте 204′. Как и раньше, хост 202′ подключен к клиенту 204′ с использованием двустороннего канала связи 506, содержащего несколько проводников. Согласно рассмотренному выше канальные контроллеры хоста и клиента могут быть изготовлены с использованием единой конструкции схемы.

На фиг.4 и 5 показаны также сигналы, передаваемые между хостом и клиентом, например, устройством отображения, по линии связи MDDI, или используемые физические проводники. Согласно фиг.4 и 5 главный канал или механизм для передачи данных по MDDI использует сигналы данных, обозначенные MDDI_Data0+/- и MDDI_Stb+/-. Каждый из них представляет собой низковольтный сигнал данных, передаваемый по дифференциальной паре проводов в кабеле. На каждой из пар MDDI_Data0 и MDDI_Stb может быть только один переход для каждого бита, передаваемого по интерфейсу. Этот механизм передачи основан на напряжениях, а не на токах, поэтому потребление тока покоя близко к нулю. Хост направляет сигналы MDDI_Stb на дисплей клиента.

Хотя данные могут течь по парам MDDI_Data в прямом и обратном направлениях, т.е. это двусторонний канал связи, хост является ведущим устройством или контроллером линии передачи данных. Сигнальные каналы MDDI_Data0 и MDDI-Stb работают в дифференциальном режиме максимальной помехоустойчивости. Скорость передачи данных на этих линиях определяется частотой тактового сигнала, выдаваемого хостом, и варьируется в диапазоне примерно от 1 кбит/с до 400 Мбит/с или более.

Интерфейс 2 типа содержит дополнительную пару данных или проводники или каналы по сравнению с типом 1, а именно MDDI_Data11+/-. Интерфейс 3 типа содержит две дополнительные пары данных или сигнальных канала по сравнению с интерфейсом 2 типа, именуемые MDDI_Data2+/- и MDDI_Data3+/-. Интерфейс 4 типа содержит еще четыре пары данных или сигнальных канала по сравнению с интерфейсом 3 типа, именуемые: MDDI_data4+/-, MDDI_Data5+/-, MDDIJData6+/- и MDDI_Data7+/- соответственно. В каждой из вышеперечисленных конфигураций интерфейса хост может подавать питание на клиент или дисплей с использованием проводной пары или сигналов, обозначаемых HOST_Pwr и HOST_Gnd. Согласно дополнительно рассмотренному ниже, подачу питания также можно осуществлять при желании в некоторых конфигурациях по проводникам MDDI_data4+/-, MDDI_Data5+/-, MDDI_Data6+/- или MDDI_Data7+/-, когда используется тип интерфейса, который использует меньше проводников, чем доступно или имеется в наличии для других режимов. Эта подача питания обычно применяется для внешних режимов, а для внутренних режимов в общем случае не нужна, хотя некоторые применения могут отличаться.

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

Заметим также, что соединения HOST_Pwr/Gnd для передачи от хоста обеспечены в общем случае для внешних узлов. Внутренние приложения или режимы работы в общем случае имеют клиенты, которые отбирают мощность непосредственно из других внутренних ресурсов и не используют MDDI для управления распределением мощности, что очевидно для специалистов в данной области, поэтому такое распределение далее подробно не рассматривается. Однако несомненно, допустимо распределение мощности через интерфейс MDDI для обеспечения, например, некоторых видов управления мощностью, синхронизации или удобства взаимосоединения, что очевидно для специалистов в данной области.

Кабели, обычно используемые для реализации вышеописанной структуры и работы, номинально имеют порядка 1,5 метра в длину, в общем случае 2 метра или менее и содержат три витые пары проводников, каждая из которых является многожильным проводом 30 AWG. Фольговое экранирующее покрытие намотано или иначе сформировано поверх трех витых пар в качестве дополнительного провода заземления. Витые пары и экранирующих проводник заземления оканчиваются в соединителе клиента, причем экран соединен с экраном клиента, и имеется изолирующий слой, покрывающий весь кабель, общеизвестный в технике. Провода образуют следующие пары: HOST_Gnd и HOST_Pwr; MDDI_Stb+ и MDDI_Stb-; MDDI_Data0+ и MDDI_Data0-; MDDI_Data1+ и MDDI_Data1-; и т.д. Однако для реализации вариантов осуществления изобретения можно использовать различные проводники и кабели, известные в технике, в зависимости от конкретных применений. Например, для защиты кабеля в некоторых вариантах применения можно использовать утяжеленные внешние покрытия или даже металлические слои, тогда как в других вариантах применения пригодны более тонкие структуры типа расплющенной проводящей ленты.

D. Типы данных и скорости передачи данных

Для получения полезного интерфейса для широкого спектра пользовательских впечатлений и приложений Mobile Digital Data Interface (MDDI) обеспечивает поддержку различных клиентов и информации отображения, преобразователей аудиосигнала, клавиатуры, указательные устройства и многие другие устройства ввода и вывода, которые могут быть интегрированы в или работать совместно с мобильным устройством отображения, совместно с информацией управления, и их комбинации. Интерфейс MDD предназначен для работы с различными возможными типами потоков данных, идущих между хостом и клиентом в направлениях прямой или обратной линии связи с использованием минимального количества кабелей или проводников. Поддерживаются как изохронные потоки, так и асинхронный поток (обновления). Возможны многие комбинации типов данных, пока совокупная скорость передачи данных меньше или равна максимальной желательной скорости линии связи MDDI, которая ограничена максимальной последовательной скоростью и количеством используемых пар данных. Это могут быть, помимо прочего, элементы, перечисленные в нижеследующих таблицах II и III.

Интерфейс не является фиксированным, но имеет возможность расширения, поэтому он может поддерживать передачу различных “типов” информации, которые включают в себя данные, определенные пользователем, для гибкости системы в будущем. Приведем конкретные примеры данных, с которыми можно работать: видео кинематографического качества в виде либо полей битовой карты, занимающих весь экран или часть экрана, либо сжатого видео; статические растровые изображения на низких скоростях для экономии мощности и сокращения расходов на реализацию; аудиоданные, подвергнутые ИКМ или сжатию, с различными разрешениями или скоростями; позиция и выделение указательного устройства и данные, определяемые пользователем для возможностей, которые подлежат заданию в будущем. Такие данные также можно передавать совместно с информацией управления или статуса для выявления возможностей устройства или набора рабочих параметров.

Варианты осуществления изобретения обеспечивают преимущества над уровнем техники в отношении использования при передаче данных, которые включают в себя, но без ограничения: просмотр кинофильма (видеодисплей и аудио); использование персонального компьютера с ограниченным персональным просмотром (графический дисплей, иногда в сочетании с видео и аудио); игра в видеоигры на ПК, приставке или персональном устройстве (графический дисплей с визуализацией движения или синтетические видео и аудио); “лазанье” по Интернету с использованием устройств в виде видеотелефона (двусторонняя низкоскоростная передача видео и аудио), камера для неподвижных цифровых снимков или видеокамера для съемки цифровых видеоизображений; использование телефона, компьютера или КПК, связанного с проектором для обеспечения представления или связанного с настольным базовым блоком, подключенным к видеомонитору, клавиатуре и мыши; и использование для повышения производительности или развлечения с сотовыми телефонами, смартфонами или КПК, включая данные беспроводных указательных устройств и клавиатуры.

Рассматриваемый ниже высокоскоростной интерфейс данных представлен применительно к обеспечению больших объемов данных типа A-V по линии связи или передачи, которая обычно выполнена в виде проводной или кабельной линии. Однако очевидно, что структура сигнала, протоколы, хронирование или механизм передачи можно приспособить к обеспечению линии связи в виде оптической или беспроводной среды, если она может поддерживать нужный уровень передачи данных.

Сигналы интерфейса MDD используют концепцию, именуемую Common Frame Rate (CFR) (частота общего кадра) для основного(й) протокола или структуры сигналов. Идея, лежащая в основе Common Frame Rate, состоит в обеспечении импульса синхронизации для одновременных изохронных потоков данных. Устройство-клиент может использовать эту общую частоту кадров в качестве эталона времени. При низкой частоте CF эффективность канала повышается благодаря снижению служебной нагрузки для передачи заголовка подкадра. С другой стороны, при высокой частоте CF увеличивается латентность и можно использовать меньший эластичный буфер данных для выборок аудиосигнала. Частота CF интерфейса, отвечающего настоящему изобретению, динамически программируется и может быть задана равной одному из многих значений, пригодных для изохронных потоков, используемых в конкретном варианте применения. Таким образом, при желании выбирается значение CF, наилучшим образом подходящее для данной конфигурации клиента и хоста.

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

Дробные значения количества байтов на подкадр легко получаются с использованием простой структуры программируемого счетчика M/N. Например, количество 26-2/3 байтов на CF реализуется путем передачи 2 кадров по 27 байт каждый, после которых следует один подкадр в 26 байтов. Меньшую частоту CF можно выбрать для обеспечения целого числа байтов на подкадр. Однако вообще говоря, для аппаратной реализации простого счетчика M/N потребуется меньшая площадь на кристалле интегральной схемы или на электронном модуле, используемом для реализации части или всех вариантов осуществления изобретения, чем площадь, необходимая для более крупного буфера FIFO выборок аудиосигнала.

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

Если предположить, что частота общего кадра равна 300 Гц, то каждый подкадр будет состоять из: 92160 байтов видеоконтента и 588 байтов аудиоконтента (на основе 147 16-битовых выборок, в случае стереосигнала) по прямой линии связи на устройство-клиент отображения, и в среднем 26,67 (26-2/3) байтов голоса передаются обратно от микрофона на мобильный аппарат Karaoke. Асинхронные пакеты передаются между хостом и дисплеем, возможно, установленным на голове. Они включают в себя самое большее 768 байтов графических данных (высота четверти экрана) и менее чем около 200 байтов (несколько) байтов для смешанного управления и команд статуса.

В таблице V показано, как выделяются данные в подкадре на примере Karaoke. Используемая суммарная скорость выбрана равной около 279 Мбит/с. Чуть большая скорость 280 Мбит/с позволяет передавать еще около 400 байтов данных на подкадр, что позволяет использовать нерегулярное управление и сообщения статуса.

III. (Продолжение) Архитектура системы высокоскоростного цифрового интерфейса данных

Е. Канальный уровень

Данные, передаваемые с использованием высокоскоростных последовательных сигналов интерфейса MDD, состоят из потока мультиплексированных по времени пакетов, связанных друг с другом. Даже когда передающее устройство не имеет данных для передачи, канальный контроллер MDDI в общем случае автоматически передает пакеты-заполнители, тем самым поддерживая поток пакетов. Использование простой пакетной структуры гарантирует надежное изохронное хронирование видео- и аудиосигналов или потоков данных.

Группы пакетов содержатся в элементах или структурах сигнала, именуемых подкадрами, и группы подкадров содержатся в элементах или структурах сигнала, именуемых медиакадром. Подкадр содержит один или несколько пакетов в зависимости от их соответствующего размера и используемой скорости передачи данных, и медиакадр содержит один или несколько подкадров. Наибольший подкадр, обеспечиваемый протоколом, применяемым в представленных здесь вариантах осуществления, имеет размер порядка 2³²-1, или 4294967295 байтов, и тогда наибольший размер медиакадра составляет порядка 2¹⁶-1, или 65535 подкадров.

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

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

Подкадры позволяют системе обеспечивать передачу высокоприоритетных пакетов на периодической основе. Это позволяет одновременным изохронным пакетам сосуществовать с минимальным объемом буферизации данных. Это одно преимущество, которое обеспечивают варианты осуществления для процесса отображения, позволяющее множественным потокам данных (высокоскоростная передача видео, голоса, команд управления, информации статуса, данных указательного устройства и т.д.) по существу совместно использовать общий канал. Информация переносится с использованием сравнительно небольшого количества сигналов. Также возможно существование действий, зависящих от технологии дисплея, например импульсов горизонтальной синхронизации и интервалов гашения для монитора на основе ЭЛТ, или других действий, зависящих от технологии клиента.

F. Канальный контроллер

Канальный контроллер MDDI, показанный на фиг.4 и 5, изготавливается или собирается в полностью цифровой реализации за исключением дифференциальных приемников линии, которые используются для приема данных MDDI и стробирующих сигналов. Однако даже дифференциальные драйверы и приемники линии можно реализовать в одних цифровых интегральных схемах с канальным контроллером, например при изготовлении ИС типа КМОП. Для восстановления битов или для реализации оборудования канального контроллера не требуются аналоговые функции или системы фазовой автоподстройки частоты (ФАПЧ). Канальные контроллеры хоста и клиента содержат весьма сходные функции за исключением клиентского интерфейса, который содержит конечный автомат для синхронизации линии связи. Поэтому варианты осуществления изобретения обеспечивают практическое преимущество, заключающееся в возможности создавать единую конструкцию или схему контроллера, которую можно настраивать как хост либо как клиент, что может в целом снижать производственные затраты на канальные контроллеры.

IV. Канальный протокол интерфейса

А. Структура кадра

Протокол сигналов или структура кадра, используемые для реализации связи на прямой линии связи для передачи пакетов, показаны на фиг.6. Согласно фиг.6 информация или цифровые данные группируются в элементы, именуемые пакетами. Множественные пакеты, в свою очередь, группируются в форму, которая называется “подкадром”, и множественные подкадры, в свою очередь, группируются в форму “медиакадра”. Для управления формированием кадров и передачи подкадров каждый подкадр начинается с особого заранее определенного пакета, именуемого Sub-frame Header Packet (SHP) (пакет заголовка подкадра).

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

Принимающее устройство-клиент, предназначенное для работы или способное работать с MDDI или протоколом сигналов, отвечающим изобретению, может запрашиваться хостом для определения максимальной или максимальной в данное время скорости передачи данных, которую оно может использовать, или может использоваться принятая по умолчанию более медленная минимальная скорость, а также поддерживаемых используемых типов данных и особенностей. Эта информация может передаваться с использованием Client Capability Packet (DCP) (пакета способности клиента), дополнительно рассмотренного ниже. Устройство-клиент отображения способно передавать данные или поддерживать связь с другими устройствами с использованием интерфейса на заранее выбранной минимальной скорости передачи данных или в пределах диапазона минимальной скорости передачи данных, и хост будет осуществлять запрос с использованием скорости передачи данных в этом диапазоне для определения полных способностей устройств-клиентов.

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

Хост передает пакеты-заполнители, когда в текущем подкадре (больше) нет пакетов данных, подлежащих передаче или когда хост не может передавать на скорости, достаточной для согласования со скоростью передачи данных, выбранной для прямой линии связи. Поскольку каждый подкадр начинается с пакета заголовка подкадра, конец предыдущего подкадра содержит пакет (скорее всего, пакет-заполнитель), который в точности заполняет предыдущий подкадр. В случае недостатка места для самих пакетов, несущих данные, пакет-заполнитель, скорее всего, будет последним пакетом в подкадре или в конце следующего предыдущего подкадра и до пакета заголовка подкадра. Задачей операций управления в устройстве-хосте является обеспечение гарантии, что в подкадре останется достаточно места для каждого пакета, подлежащего передаче в этом подкадре. В то же время после того как устройство-хост инициирует передачу пакета данных, хост должен иметь возможность успешно завершить пакет этого размера в кадре, не создавая условия недогрузки данными.

В одном аспекте вариантов осуществления передача подкадров имеет два режима. Один режим – это периодический режим подкадров или периодические эпохи хронирования, используемые для передачи потоков видео и аудио в прямом эфире. В этом режиме длина подкадра задается не равной нулю. Второй режим – это асинхронный или непериодический режим, в котором кадры используются для предоставления клиенту при наличии новой информации. Этот режим определяется заданием длины подкадра, равной нулю, в пакете Sub-frame Header Packet. При использовании периодического режима прием пакета подкадра может начаться, когда клиент синхронизирован со структурой кадра прямой линии связи. Это соответствует состояниям “в синхронизме”, определенным согласно диаграмме состояний, рассмотренной ниже со ссылкой на фиг.49 или 63. В асинхронном непериодическом режиме подкадров прием начинается после приема первого пакета заголовка подкадра.

В. Пакетная структура в целом

Формат или структура пакетов, используемых для формирования протокола связи или сигналов или способов или средств для передачи данных, реализованные посредством вариантов осуществления, представлены ниже с учетом того, что интерфейс является расширяемым и при желании в него можно добавить дополнительные пакетные структуры. Пакеты обозначаются в соответствии или делятся на различные “типы пакетов” в отношении их функции в интерфейсе, т.е. команд, информации, значения или данных, которые они переносят или которые связаны с ними. Поэтому каждый тип пакета обозначается заранее определенную пакетную структуру для данного пакета, которая используется при манипулировании передаваемыми пакетами и данными. Очевидно, что пакеты могут иметь заранее выбранные длины или могут иметь переменные или динамически изменяемые длины в зависимости от их соответствующих функций. Пакеты также могут иметь разные имена, в то же время реализуя одну и ту же функцию, что может происходить при изменении протоколов во время включения их в стандарт. Байты или значения байтов, используемые в различных пакетах, имеют конфигурацию многобитовых (8- или 16-битовых) беззнаковых целых. Сущность пакетов, используемых совместно с обозначением их “типа”, перечисленными в порядке типа, показана в таблицах с IV-1 по VI-4.

Каждая таблица представляет общий “тип” пакета в пакетной структуре в целом для простоты иллюстрации и понимания. Эти группировки не предусматривают и не выражают никакого ограничения или другого влияния на изобретение, и при желании пакеты можно организовать многими другими способами. Также отмечено направление, в котором передача пакета считается действительной.

Из других рассмотрений в этом тексте следует, что хотя каждый из пакетов Reverse Encapsulation Packet, Client Capability Packet, and Client Request and Status Packet считается очень важным или даже необходимым во многих вариантах осуществления интерфейсов связи для внешнего режима работы, но для внутреннего режима работы они могут или с большой вероятностью могут считаться необязательными. В результате возникает еще один тип Протокола интерфейса MDD, который допускает передачу данных на очень высоких скоростях с сокращенным набором пакетов связи и соответственно упрощение управления и хронирования.

Пакеты имеют общую базовую структуру или общий набор минимальных полей, содержащих поле Packet Length (длина пакета), поле Packet Type (тип пакета), поле(я) Data Bytes (байты данных) и поле CRC, как показано на фиг.7. Согласно фиг.7 поле Packet Length содержит информацию в виде многобитового или многобайтового значения, которая указывает полное количество битов в пакете или его длину между полем длины пакета и полем CRC. Согласно одному варианту осуществления поле длины пакета содержит 16-битовое или 2-байтовое беззнаковое целое, которое указывает длину пакета. Поле Packet Type это еще одно многобитовое поле, которое обозначает тип информации, содержащейся в пакете, согласно иллюстративному варианту осуществления, это 16-битовое или 2-байтовое значение в виде 16-битового беззнакового целого и указывает такие типы данных, как возможности дисплея, переход, видео- или аудиопотоки, статус и т.п.

Третье поле – это поле Data Bytes, которое содержит биты или данные, переносимые или передаваемые между устройствами хоста и клиента как часть пакета. Формат данных задан конкретно для каждого типа пакета в соответствии с конкретным типом передаваемых данных и может быть разделен на несколько дополнительных полей, каждое из которых имеет собственные требования к формату. Таким образом, каждый тип пакета имеет заданный формат для этой части или поля. Последним полем является поле CRC, которое содержит результаты проверки с помощью 16-битового циклического избыточного кода, производимой над полями Data Bytes, Packet Type и Packet Length, которое используется для подтверждения целостности информации в пакете, иными словами, производимой над каждым пакетом за исключением самого поля CRC. Клиент в общем случае поддерживает суммарное количество обнаруженных ошибок CRC и передает это количество обратно на хост в пакете Client Request and Status Packet (см. подробности ниже).

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

Во время передачи пакетов поля передаются начиная с самого младшего бита (LSB) и заканчивая самым старшим битом (MSB). Параметры, имеющие длину более одного бита, передаются с использованием сначала самого младшего бита, в результате чего для параметра длиной свыше 8 битов используется тот же шаблон передачи битов, который используется для более короткого параметра, когда первым передается LSB. Поля данных каждого пакета в общем случае передаются в том порядке, в каком они заданы в нижеследующих разделах, причем первое из перечисленных полей передается первым и последнее из описанных полей передается последним. Данные на канале сигнала MDDI_Data0 выровнены с битом ‘0’ байтов, передаваемых по интерфейсу в любом из режимов, типа 1, типа 2, типа 3 или типа 4.

При манипулировании данными для дисплеев данные для массивов пикселей передаются сначала строками, затем столбцами, как традиционно делается в электронной технике. Другими словами, все пиксели, которые появляются в одной и той же строке битовой карты, передаются по порядку, причем самый левый пиксель передается первым и самый правый пиксель передается последним. После передачи самого правого пикселя строки передача продолжается с самого левого пикселя следующей строки. Строки пикселей обычно передаются в сверху вниз для большинства дисплеев, хотя при необходимости можно использовать и другие конфигурации. Кроме того, при обработке битовых карт традиционный подход, которому мы будем следовать ниже, предусматривает задание точки отсчета путем сопоставления верхнему левому углу битовой карты положения или смещения “0,0.” Координаты X и Y, используемые для задания или определения позиции в битовой карте, возрастают при приближении к правой и нижней стороне битовой карты соответственно. Первая строка и первый столбец (верхний левый угол изображения) начинаются со значением индекса, равным нулю. Величина координаты X возрастает по направлению к правой стороне изображения, и величина координаты Y возрастает по направлению к нижнему краю изображения, рассматриваемого пользователем дисплея.

Окно дисплея – это видимая часть битовой карты, часть пикселей битовой карты, которую пользователь может видеть на физическом носителе дисплея. Часто бывает так, что окно дисплея и битовая карта имеют одинаковый размер. Верхний левый угол окна дисплея всегда отображает положение ‘0,0’ пикселя битовой карты. Ширина окна дисплея соответствует оси X битовой карты, и ширина окна дисплея для этого варианта осуществления меньше или равна ширине соответствующей битовой карты. Высота окна соответствует оси Y битовой карты, и высота окна дисплея для этого варианта осуществления меньше или равна высоте соответствующей битовой карты. Само окно дисплея не является адресуемым в протоколе, поскольку оно определено как видимая часть битовой карты.

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

С. Определения пакетов

1. Пакет Sub-Frame Header

Пакет Sub-Frame Header (заголовок подкадра) – это первый пакет каждого подкадра, базовая структура которого изображена на фиг.8. Пакет Sub-Frame Header Packet используется для синхронизации хост-клиент, причем каждый хост должен иметь возможность генерировать этот пакет и каждый клиент должен иметь возможность принимать и интерпретировать этот пакет. Из фиг.8 видно, что согласно одному варианту осуществления структура этого типа пакета предусматривает наличие полей Packet Length (длина пакета), Packet Type (тип пакета), Unique Word (уникальное слово), Reserved 1 (резервное 1), Sub-Frame Length (длина подкадра), Protocol Version (версия протокола), Sub-Frame Count (счетчик подкадров) и Media-frame Count (счетчик медиакадров) в общем случае в этом порядке. Согласно одному варианту осуществления этот тип пакета в общем случае идентифицируется как пакет типа 15359 (0x3bff в шестнадцатеричной системе счисления) и использует заранее выбранную фиксированную длину 20 байтов, не включая поле длины пакета.

Поле Packet Type и поле Unique Word использует 2-байтовое значение (16-битовое беззнаковое целое). 4-байтовая комбинация этих двух полей образует 32-битовое уникальное слово с хорошей автокорреляцией. Согласно одному варианту осуществления фактическое уникальное слово равно 0x005a3bff, причем 16 младших битов передаются первыми в качестве поля Packet Type и затем передаются 16 старших битов.

Поле Reserved 1 содержит 2 байта, которые зарезервированы для использования в будущем и в общем случае в настоящее время имеют конфигурацию, в которой все биты заданы равными нулю. Одной целью этого поля является выравнивание последующих 2-байтовых полей с 16-битовым словом адреса и выравнивание 4-байтовых полей с 32-битовым словом адреса. Самый младший байт зарезервирован для указания, что хост способен работать только с одним устройством-клиентом.

Поле Sub-frame Length содержит 4 байта информации или значение, которое указывает количество байтов на подкадр. Согласно одному варианту осуществления длина этого поля может быть задана равной нулю для указания, что только один подкадр будет передан хостом до того, как линия связи будет переведена в ждущее состояние. Значение этого поля может динамически изменяться “на лету” при переходе от одного подкадра к следующему. Эта возможность полезна для осуществления вспомогательных регулировок хронирования синхроимпульсов для работы с изохронными потоками данных. Если CRC пакета Sub-frame Header недействителен, то канальный контроллер должен использовать поле Sub-frame Length предыдущего пакета Sub-frame Header, про который известно, что он хороший, для оценки длины текущего подкадра.

Поле Protocol Version содержит 2 байта, которые указывают версию протокола, используемую хостом. Поле Protocol Version может быть задано равным ‘0’ для указания первой или текущей версии используемого протокола. Это значение будет изменяться с течением времени по мере создания новых версий и уже обновлено до значения ‘1’ для некоторых полей версий. Значения версии будут, вероятно или в общем случае, следовать текущему номеру версии для утвержденного документа стандартов, который охватывает такие интерфейсы, как MDDI, что известно.

Поле Sub-frame Count содержит 2 байта, которые указывают порядковый номер, который указывает количество подкадров, которое было передано с начала медиакадра. Первый подкадр медиакадра имеет поле Sub-frame Count, равное нулю. Последний подкадр медиакадра имеет значение n-1, где n – количество подкадров на медиакадр. Значение поля Sub-frame Count равно значению Sub-frame Count, переданного в предыдущем пакете подкадра, плюс 1, за исключением первого подкадра медиакадра, который будет иметь счетчик, равный нулю. Заметим, что, если поле Sub-frame Length задано равным нулю (указывающее непериодический подкадр), то счетчик подкадров также задан равным нулю.

Поле Media-frame Count содержит 4 байта (32-битовое беззнаковое целое), которое указывает порядковый номер, который указывает количество подкадров, которое было передано с начала передаваемого(ых) в настоящее время элемента или данных мультимедиа. Первый медиакадр элемента мультимедиа имеет поле Media-frame Count, равное нулю. Значение Media-frame Count увеличивается сразу перед первым подкадром каждого медиакадра и возвращается к нулю после использования максимального значения Media-frame Count (например, количества медиакадров 2³²-1 = 4294967295). Значение Media-frame Count может быть сброшено хостом в общем случае в любое время для удовлетворения нужд конечного приложения.

2. Пакет Filler

Пакет-заполнитель – это пакет, который передается на устройство-клиент или от него в отсутствие информации, подлежащей передаче по прямой или обратной линии связи. Рекомендуется, чтобы пакеты-заполнители имели минимальную длину для обеспечения максимальной гибкости при передаче других пакетов при необходимости. В самом конце подкадра или пакета инкапсуляции обратной линии связи (см. ниже), канальный контроллер задает размер пакета-заполнителя для заполнения оставшегося места для поддержки целостности пакета. Пакет Filler Packet полезен для поддержания хронирования на линии связи, когда хост или клиент не имеет информации для передачи или обмена. Каждый хост и клиент должен иметь возможность передавать и принимать этот пакет для эффективного использования интерфейса.

Иллюстративный вариант осуществления формата и содержимого пакета Filler Packet показаны на фиг.9. Согласно фиг.9, структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, Filler Bytes, и CRC. Согласно одному варианту осуществления этот тип пакета в общем случае идентифицируется как тип 0, что указано в 2-байтовом поле Type (тип). Биты или байты в поле Filler Bytes (байты заполнителя) содержат переменное количество полностью нулевых битовых значений, чтобы пакет-заполнитель мог иметь нужную длину. Наименьший пакет-заполнитель не содержит байтов в этом поле. То есть пакет содержит только длину пакета, тип пакета и CRC и согласно одному варианту осуществления использует заранее выбранную фиксированную длину 6 байтов или значение Packet Length, равное 4. Значение CRC определяется для всех байтов в пакете, включая Packet Length, которое может быть исключено в некоторых других типах пакета.

3. Пакет Video Stream

Пакеты Video Stream переносят видеоданные для обновления обычно прямоугольных областей устройства отображения. Размер этой области может минимально составлять один пиксель и максимально распространяться на весь дисплей. Одновременно может отображаться почти неограниченное количество потоков, которое ограничивается системными ресурсами, поскольку весь контекст, необходимый для отображения потока, содержится в пакете Video Stream Packet. Формат пакета Video Stream Packet согласно одному варианту осуществления показан на фиг.10. Из фиг.10 следует, что, согласно одному варианту осуществления структура этого типа пакета предусматривает наличие полей Packet Length (2 байта), Packet Type, bClient ID, Video Data Descriptor, Pixel Display Attributes, X Left Edge, Y Top Edge, X Right Edge, Y Bottom Edge, X and Y Start, Pixel Count, Parameter CRC, Pixel Data и Pixel Data CRC. Этот тип пакета в общем случае идентифицируется как тип 16, что указано в 2-байтовом поле Type. Согласно одному варианту осуществления клиент указывает способность принимать пакет Video Stream Packet с использованием полей RGB, Monochrome и Y Cr Cb Capability пакета Client Capability Packet.

Согласно одному варианту осуществления поле bClient ID содержит 2 байта информации, зарезервированные для ID клиента. Поскольку это вновь разработанный протокол связи, фактические ID клиентов пока не известны или не могут в достаточной степени передаваться. Поэтому биты в этом поле в общем случае задаются равными нулю, пока не станут известны такие значения ID, после чего значения ID можно будет вставлять, что очевидно специалистам в данной области. Тот же процесс в общем случае применим к полям ID клиента, рассмотренным ниже.

Рассмотренная выше концепция общего кадра является эффективным способом минимизации размера аудиобуфера и снижения латентности. Однако для видеоданных может потребоваться распространять пиксели одного видеокадра по множественными пакетам Video Stream в медиакадре. Также весьма вероятно, что пиксели в одном пакете Video Stream не будут полностью соответствовать совершенному прямоугольному окну на дисплее. Для иллюстративной частоты видеокадров, равной 30 кадров в секунду, будет 300 подкадров в секунду, что дает 10 подкадров на медиакадр. Если в каждом кадре имеется 480 строк пикселей, то каждый пакет Video Stream Packet в каждом подкадре будет содержать 48 строк пикселей. В других случаях пакет Video Stream Packet может не содержать целого числа строк пикселей. Это справедливо для других размеров видеокадра, где количество подкадров на медиакадр не делится нацело на количество строк (также именуемых строками развертки) на видеокадр. Для эффективной работы каждый пакет Video Stream Packet в общем случае должен содержать целое число пикселей, несмотря на то что он может не содержать целого числа строк пикселей. Это важно, если каждый пиксель имеет размер свыше одного байта или если они находятся в упакованном формате, показанном на фиг.12.

Формат и содержимое, используемые для реализации работы иллюстративного поля Video Data Descriptor, упомянутого выше, показаны на фиг.11A-11E. Согласно фиг.11A-11E, поле Video Data Format Descriptor (описатель формата видеоданных) содержит 2 байта в виде 16-битового беззнакового целого, которое указывает формат каждого пикселя в поле Pixel Data в данном потоке в данном пакете. Возможно, что пакеты Video Stream могут использовать разные форматы пиксельных данных, т.е. использовать другое значение в поле Video Data Format Descriptor, и аналогично поток (область дисплея) может оперативно изменять свой формат данных. Формат пиксельных данных должен согласовываться с, по меньшей мере, одним из действительных форматов для клиента, заданных в пакете Client Capability Packet. Поле Video Data Format Descriptor задает формат пикселя только для данного пакета, что не предполагает продолжение использования постоянного формата на протяжении конкретного видеопотока.

На фиг.11А-11D показано, как кодируется поле Video Data Format Descriptor. Согласно этим фигурам и этому варианту осуществления, когда биты [15:13] равны ‘000’, как показано на фиг.11А, видеоданные состоят из массива монохромных пикселей, где число битов на пиксель задано битами с 3-го по 0-й слова Video Data Format Descriptor. Биты с 11 по 4 в общем случае зарезервированы для будущего использования или применения и заданы равными нулю в данном случае. Если же биты [15:13] равны значениям ‘001’, как показано на фиг.11В, видеоданные состоят из массива цветных пикселей, каждый из которых задает цвет посредством карты цветов (палитры). В этом случае биты с 5-го по 0-й слова Video Data Format Descriptor задают число битов на пиксель, и биты с 11-го по 6-й в общем случае зарезервированы для будущего использования или применения и заданы равными нулю. Если же биты [15:13] равны значениям ‘010’, как показано на фиг.11С, видеоданные состоят из массива цветных пикселей, где число битов на пиксель красного цвета задано битами с 11-го по 8-й, число битов на пиксель зеленого цвета задано битами с 7-го по 4-й, и число битов на пиксель синего цвета задано битами с 3-го по 0-й. В этом случае суммарное число битов в каждом пикселе равно сумме количеств битов, используемых для красного, зеленого и синего цветов.

Если же биты [15:13] равны значениям или строке ‘011’, как показано на фиг.11D, видеоданные состоят из массива видеоданных в формате 4:2:2 Y Cb Cr с информацией яркости и цветности, где число битов на пиксель для яркости (Y) задано битами с 11-го по 8-й, число битов компонента Cb задано битами с 7-го по 4-й и число битов компонента Cr задано битами с 3-го по 0-й. Суммарное число битов в каждом пикселе равно сумме количеств битов, используемых для красного, зеленого и синего цветов. Компоненты Cb и Cr передаются на половинной скорости как Y. Кроме того, выборки видеосигнала в части Pixel Data этого пакета организованы следующим образом: Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3,…, где Cbn и Crn связаны с Yn и Yn+1, и Cbn+2 и Crn+2 связаны с Yn+2 и Yn+3, и т.д.

Yn, Yn+1, Yn+2 и Yn+3 – это значения яркости четырех последовательных пикселей в одной строке слева направо. При наличии нечетного числа пикселей в строке (X Right Edge – X Left Edge + 1) в окне, указанном пакетом Video Stream Packet, за значением Y, соответствующим последнему пикселю в каждой строке, будет следовать значение Cb первого пикселя следующей строки, и значение Cr не передается для последнего пикселя в строке. Рекомендуется, чтобы окна, использующие формат Y Cb Cr, имели ширину, равную четному числу пикселей. Поле Pixel Data в пакете должно содержать четное число пикселей. Оно может содержать нечетное или четное число пикселей в случае, когда последний пиксель в поле Pixel Data соответствует последнему пикселю строки в окне, заданном в заголовке пакета Video Stream Packet, т.е. когда положение X последнего пикселя в поле Pixel Data равно X Right Edge.

Если же биты [15:13] равны значениям ‘100’, видеоданные состоят из массива пикселей Байера, где число битов на пиксель задано битами с 3-го по 0-й слова Video Data Format Descriptor. Поле Pixel Group Pattern задано битами 5 и 4, как показано на фиг.11Е. Порядок пиксельных данных может быть горизонтальным или вертикальным, и пиксели в строках или столбцах могут передаваться в прямом или обратном порядке и задаваться битами с 8-го по 6-й. Биты с 11-го по 9-й должны быть заданы равными нулю. Группа из четырех пикселей в группе пикселей в формате Байера напоминает то, что часто называют единым пикселем в некоторых технологиях отображения. Однако один пиксель в формате Байера – это только один из четырех окрашенных пикселей мозаичной картины группы пикселей.

Для всех пяти форматов, показанных на фигурах, бит 12, обозначенный как “P”, указывает, являются ли выборки поля Pixel Data упакованными или выровненными по границе байта пиксельными данными. Значение ‘0’ в этом поле указывает, что каждый пиксель в поле Pixel Data выровнен по границе байта с границей байта интерфейса MDD. Значение ‘1’ указывает, что каждый пиксель и каждый цвет в каждом пикселе в поле Pixel Data упакован относительно предыдущего пикселя или цвета в пикселе без оставшихся неиспользованных битов. Различие между выровненным по границе байта и упакованным форматами пиксельных данных более подробно показана на фиг.12, где ясно видно, что данные, выровненные по границе байта, могут оставлять неиспользованные части подкадра данных, в отличие от упакованного пиксельного формата, в котором этого нет.

Первый пиксель в первом пакете видеопотока медиакадра для конкретного окна дисплея пойдет в верхний левый угол окна потока, заданный посредством X Left Edge и Y Top Edge, и следующий полученный пиксель размещается в следующем месте для пикселя в той же строке и т.д. В этом первом пакете медиакадра начальное значение X будет обычно равно X Left Edge и начальное значение Y будет обычно равно Y Top Edge. В последующих пакетах, соответствующих тому же окну экрана, начальные значения X и Y будут обычно заданы в соответствии с положением пикселя в окне экрана, которое обычно следует за последним пикселем, переданным в пакете Video Stream Packet, который был передан в предыдущем подкадре.

4. Пакет Audio Stream

Пакеты аудиопотока переносят аудиоданные, подлежащие воспроизведению через аудиосистему клиента, или для автономного устройства представления аудио. Разные потоки аудиоданных могут выделяться отдельным аудиоканалам в акустической системе, например: левый передний, правый передний, центральный, левый задний и правый задний в зависимости от типа используемой аудиосистемы. Полный комплект аудиоканалов обеспечивается для головных телефонов, которые содержат усовершенствованную пространственную обработку акустических сигналов. Клиент указывает способность принимать пакет Audio Stream Packet с использованием полей Audio Channel Capability и Audio Sample Rate пакета Client Capability Packet. Формат пакетов Audio Stream проиллюстрирован на фиг.13.

Согласно фиг.13 этот тип пакета имеет структуру, которая согласно одному варианту осуществления содержит поля Packet Length, Packet Type, bClient ID, Audio Channel ID, Reserved 1, Audio Sample Count, Bits Per Sample and Packing, Audio Sample Rate, Parameter CRC, Digital Audio Data и Audio Data CRC. Согласно одному варианту осуществления этот тип пакета в общем случае идентифицируется как пакет типа 32.

Поле bClient ID содержит 2 байта информации, которые зарезервированы для ID клиента, который использовался ранее. Поле Reserved 1 содержит 2 байта, которые зарезервированы для использования в будущем и в общем случае в настоящее время имеют конфигурацию, в которой все биты заданы равными нулю.

Поле Bits Per Sample and Packing содержит 1 байт в виде 8-битового беззнакового целого, которое задает формат упаковки аудиоданных. Формат, который обычно используется, выражается битами с 4-го по 0-й для задания числа битов на выборку аудиосигнала в режиме ИКМ. Бит 5 указывает, упакованы ли выборки в поле Digital Audio Data. Разница между упакованными и выровненными по границе байта выборками аудиосигнала, в данном случае 10-битовыми выборками, проиллюстрирована на фиг.14. Значение ‘0’ указывает, что каждая выборка аудиосигнала в режиме ИКМ в поле Digital Audio Data выровнена по границе байта с границей байта интерфейса MDDI, и значение ‘1’ указывает, что каждая последующая выборка аудиосигнала в режиме ИКМ упакована относительно предыдущей выборки аудиосигнала. Этот бит в общем случае эффективен, только когда значение, заданное в битах с 4-го по 0-й (число битов на выборку аудиосигнала в режиме ИКМ) не является кратным восьми. Биты с 7-го по 6-й зарезервированы для использования в будущем и в общем случае заданы равными нулю.

5. Зарезервированные пакеты потока

Согласно одному варианту осуществления типы пакета 1-15, 18-31 и 33-55 зарезервированы для пакетов потока, подлежащих определению для использования в будущих версиях или вариациях пакетных протоколов, необходимых для различных вариантов применения. Опять же, это делает интерфейс MDD более гибким и полезным в условиях постоянно изменяющихся конструкций технологии и системы по сравнению с другими методами.

6. Пакеты потока, заданные пользователем

Восемь типов потоков данных, известных как типы 56-63, зарезервированы для использования в собственнических применениях, которые могут быть заданы изготовителями оборудования для использования с линией связи MDDI. Они известны как пакеты потока, заданные пользователем. Такие пакеты можно использовать в любых целях, но хост и клиент должны использовать такие пакеты только в ситуациях, когда результат такого использования очень хорошо понятны или известны. Конкретное определение параметров потока и данных для этих типов пакета остается за конкретными производителями оборудования или разработчиками интерфейса, реализующими такие типы пакета или ищущих их использование. Некоторые иллюстративные варианты использования пакетов потока, заданных пользователем, состоят в переносе параметров тестирования и результатов тестирования, данных заводской калибровки и собственные данные особого использования. Формат пакетов потока, заданных пользователем, используемый согласно одному варианту осуществления, проиллюстрирован на фиг.15. Согласно фиг.15 структура этого типа пакета предусматривает наличие полей Packet Length (2 байта), Packet Type, число bClient ID, Stream Parameters, Parameter CRC, Stream Data и Stream Data CRC.

7. Пакеты Color Map

Пакеты карты цветов указывают содержимое поисковой таблицы карты цветов, используемой для представления цветов для клиента. Для некоторых приложений может требоваться карта цветов, которая больше, чем объем данных, которые можно передать в одном пакете. В этих случаях множественные пакеты Color Map могут передаваться, каждый с разным подмножеством карты цветов, с использованием описанных ниже полей смещения и длины. Формат пакета Color Map Packet согласно одному варианту осуществления проиллюстрирован на фиг.16. Согласно фиг.16 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, Color Map Item Count, Color Map Offset, Parameter CRC, Color Map Data и Data CRC. Согласно одному варианту осуществления этот тип пакета в общем случае идентифицируется как пакет типа 64 (Video Data Format и Color Map Packet) заданный в поле Packet Type (2 байта). Клиент указывает возможность принимать пакеты Color Map с использованием полей Color Map Size и Color Map Width пакета Client Capability Packet.

8. Пакеты Reverse Link Encapsulation

Согласно иллюстративному варианту осуществления данные передаются в обратном направлении с использованием пакета Reverse Link Encapsulation Packet. Пакет прямой линии связи передается, и операция линии связи MDDI (направление передачи) изменяется или оборачивается в середине этого пакета, что позволяет передавать пакеты в обратном направлении. Формат пакета Reverse Link Encapsulation согласно одному варианту осуществления проиллюстрирован на фиг.17. Согласно фиг.17 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, Reverse Link Flags, Reverse Rate Divisor, Turn-Around 1 Length, Turn-Around 2 Length, Parameter CRC, All Zero 1, Turn-Around 1, Reverse Data Packets, Turn-Around 2 b All Zero 2. Согласно одному варианту осуществления этот тип пакета в общем случае идентифицируется как пакет типа 65. Для внешнего режима каждый хост должен быть способен генерировать этот пакет и принимать данные и каждый клиент должен быть способен принимать и передавать данные на хост, чтобы эффективно использовать нужный протокол и результирующую скорость. Реализация этого пакета необязательна для внутреннего режима, но пакет Reverse Link Encapsulation Packet используется хостом для приема данных от клиента.

Канальный контроллер MDDI ведет себя особым образом, передавая пакет Reverse Link Encapsulation Packet. Интерфейс MDD имеет стробирующий сигнал, который в общем случае всегда возбуждается хостом в качестве контроллера линии связи. Хост ведет себя, как если бы в каждом бите частей Turn-Around и Reverse Data Packets пакета Reverse Link Encapsulation передавался нуль. Хост переключает сигнал MDDI_Strobe на каждой границе бита в течение двух времен реверсирования и в течение времени, выделенного для обратных пакетов данных. (Это такое же поведение, как при передаче полностью нулевых данных.)

Хост отключает свои драйверы линии сигнала данных MDDI в течение периода времени, указанного полем Turn-Around 1, и клиент повторно включает свои драйверы линии в течение поля Driver Re-enable, следующего за периодом времени, заданным полем Turn-Around 2. Клиент считывает параметр Turn-Around Length и направляет сигналы данных на хост сразу после последнего бита в поле Turn-Around 1. То есть клиент тактирует новые данные в линию связи на определенных растущих фронтах стробирующего сигнала MDDI, указанного в содержимом пакета, описанном ниже, и в другом месте. Клиент использует параметры Packet Length и Turn-Around Length, чтобы узнать продолжительность времени, которое он имеет для передачи пакетов на хост. Клиент может передавать пакеты-заполнители или переводить линии данных в нулевое состояние, когда не имеет данных для передачи на хост. Если линии данных переведены на нуль, хост интерпретирует это как пакет нулевой длины (неправильной длины) и хост больше не принимает пакеты от клиента в течение текущего пакета Reverse Link Encapsulation Packet.

Хост переводит сигналы MDDI_Data на уровень логического нуля в течение поля All Zero 1, и клиент переводит линии данных MDDI на уровень логического нуля за, по меньшей мере, один период тактового сигнала обратной линии связи до начала поля Turn Around 2, т.е. в течение периода поля All Zero 2. Это поддерживает линии данных в детерминистическом состоянии в течение периода времени полей Turn Around 1 и Turn Around 2. Если клиент больше не имеет пакетов для передачи, он может даже отключить линии данных после перевода их на уровень логического нуля, поскольку резисторы смещения неактивного режима (рассмотрены в другом месте) поддерживают линии данных на уровне логического нуля в течение остатка поля Reverse Data Packets или на протяжении около 16 или более байтов прямой линии связи.

Согласно одному варианту осуществления поле Reverse Link Request пакета Client Request and Status Packet можно использовать для информирования хоста о количестве байтов, которые нужны клиенту в пакете Reverse Link Encapsulation Packet для передачи данных обратно на хост. Хост пытается удовлетворить запрос, выделяя, по меньшей мере, это количество байтов в пакете Reverse Link Encapsulation Packet. Хост может передавать более одного пакета Reverse Link Encapsulation Packet в подкадре. Клиент может передавать пакет Client Request and Status Packet почти в любое время, и хост будет интерпретировать параметр Reverse Link Request как полное количество байтов, запрошенных в одном подкадре.

9. Пакеты Client Capability

Хосту нужно знать возможность клиента (дисплея), с которым он поддерживает связь, с целью оптимальной в общем смысле или специальной настройки линии связи хост-клиент. Рекомендуется, чтобы дисплей передавал пакет Client Capability Packet на хост после достижения синхронизации прямой линии связи. Передача такого пакета считается необходимой по запросу хоста с использованием поля Reverse Link Flags в пакете Reverse Link Encapsulation Packet. Пакет Client Capability Packet используется для информирования хоста о возможностях клиента. Для внешнего режима каждый хост должен быть способен принимать этот пакет и каждый клиент должен быть способен передавать этот пакет, чтобы полностью использовать этот интерфейс и протокол. Реализация этого пакета оптимальна для внутреннего режима, поскольку возможности клиента, например дисплея, клавиатуры или другого устройства ввода/вывода, в этой ситуации уже должны быть четко определены и известны хосту на время изготовления или сборки в единый компонент или блок некоторого типа.

Формат пакета Client Capability согласно одному варианту осуществления проиллюстрирован на фиг.18. Согласно фиг.18 для этого варианта осуществления, структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, зарезервированный cClientID, Protocol Version, Min Protocol Version, Data Rate Capability, Interface Type Capability, Number of Alt Displays, Reserved 1, Bitmap Width, Bitmap Height, Display Window Width, Display Window Height. Color Map Size, Color Map RGB Width, RGB Capability, Monochrome Capability, Reserved 2, Y Cr Cb Capability, Bayer Capability, Alpha-Cursor Image Planes, Client Feature Capability, Max Video Frame Rate, Min Video Frame Rate, Min Sub-frame rate, Audio Buffer Depth, Audio Channel Capability, Audio Sample Rate Capability, Audio Sample Resolution, Mic Audio Sample Resolution, Mic Sample Rate Capability, Keyboard Data Format, Pointing Device Data Format, Content Protection Type, Mfr. Name, Product Code, Reserved 3, Serial Number, Week of Mfr., Year of Mfr. и CRC. Согласно иллюстративному варианту осуществления этот тип пакета в общем случае идентифицируется как пакет типа 66.

10. Пакеты Keyboard Data

Пакет данных клавиатуры используется для передачи данных клавиатуры от устройства-клиента на хост. Беспроводную (или проводную) клавиатуру можно использовать совместно с различными дисплеями или аудиоустройствами, включая, но без ограничения установленное на голове устройство видеодисплея/представления аудио. Пакет Keyboard Data Packet переносит данные клавиатуры, полученные от одного из нескольких известных клавиатуроподобных устройств, на хост. Этот пакет также можно использовать на прямой линии связи для передачи данных на клавиатуру. Клиент указывает возможность передачи и приема пакетов Keyboard Data с использованием поля Keyboard Data Format в пакете Client Capability Packet.

Формат пакета Keyboard Data Packet показан на фиг.19 и содержит переменное количество байтов информации от или для клавиатуры. Согласно фиг.19 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, bClient ID, Keyboard Data Format, Keyboard Data и CRC. Здесь этот тип пакета в общем случае идентифицируется как пакет типа 61.

Поле bClient ID является резервным полем, как и раньше, и CRC осуществляется для всех байтов пакета. Поле Keyboard Data Format содержит 2-байтовое значение, которое описывает формат данных клавиатуры. Биты с 6-го по 0-й должны быть идентичны полю Keyboard Data Format в пакете Client Capability Packet. Это значение не равно 127. Биты с 15-го по 7-й зарезервированы для использования в будущем и поэтому в настоящее время заданы равными нулю.

11. Пакеты Pointing Device Data

Пакет данных указательного устройства используется в качестве метода, структуры или средства для передачи информации позиции от беспроводной мыши или другого указательного устройства с клиента на хост. Данные также можно передавать на указательное устройство по прямой линии связи с использованием этого пакета. Иллюстративный формат пакета Pointing Device Data Packet показан на фиг.20 и содержит переменное количество байтов информации от или для указательного устройства. Согласно фиг.20 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, bClient ID, Pointing Device Format, Pointing Device Data и CRC. Согласно иллюстративному варианту осуществления этот тип пакета в общем случае идентифицируется как пакет типа 68 в 1-байтовом поле типа.

12. Пакеты Link Shutdown

Пакет Link Shutdown Packet передается от хоста на клиент в качестве метода или средства указания, что данные и стробирующий сигнал MDDI будут отключены и перейдут в “неактивное” состояние с низким энергопотреблением. Этот пакет полезен для отключения линии связи и экономии мощности после передачи статических битовых карт от мобильного устройства связи на дисплей, или когда в данное время больше нет информации для передачи с хоста на клиент. Нормальная работа возобновляется, когда хост снова передает пакеты. Первым пакетом, отправленным после неактивного режима, является пакет заголовка подкадра. Формат пакета Client Status Packet согласно одному варианту осуществления показан на фиг.21. Согласно фиг.21 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, CRC и All Zeros. Согласно одному варианту осуществления этот тип пакета в общем случае идентифицируется как пакет типа 69 в 1-байтовом поле типа.

Поле длины пакета использует 2 байта для установления общего количества байтов в пакете, не включая поле длины пакета. В одном из вариантов осуществления Packet Length такого пакета зависит от Interface Type или режима линии связи по существу в момент передачи пакета Link Shutdown. Следовательно, обычная длина пакета составляет 20 байт для режима линии связи типа 1 (всего 22 байта в пакете), 36 байтов для режима линии связи типа 2 (всего 38 байт в пакете), 68 байт для режима линии связи типа 3 (всего в пакете 70 байт) и 132 байта для режима линии связи типа 4 (всего в пакете 134 байт).

Поле All Zeros использует переменное количество битов, чтобы гарантировать, что сигналы MDDI данных находятся на уровне логического нуля в течение достаточного количества времени, чтобы позволить клиенту начать восстановление тактового сигнала, используя только MDDI_Stb, до остановки драйверов линии связи хоста. Длина поля All Zeros зависит от Interface Type или режима работы линии связи по существу в момент передачи пакета Link Shutdown. Длина поля All Zeros предназначена для формирования 64 импульсов в MDDI_Stb для любой установки Interface Type. Следовательно, длина All Zeros для каждого типа интерфейса составляет 16 байтов для типа 1, 32 байта для типа 2, 64 байта для типа 3 и 128 байтов для типа 4.

Поле CRC использует 2 байта, которые содержат 16-битовый CRC байтов из пакета Packet Length в пакете Packet Type.

В состоянии с низким потреблением драйвер MDDI_Data0 находится в неактивном состоянии с высоким импендансом, начиная с 16 и по 48 MDDI_Stb цикл после последнего бита поля All Zeros. Для линий связи тип 2, тип 3 или тип 4 сигналы от MDDI_Data1 до MDDI_DataPwr7 также переводится в состояние с высоким импедансом в то же самое время, когда драйвер MDDI_Data0 деактивируется. Либо хост, либо клиент могут вызвать “пробуждение” линии связи MDDI из деактивированного состояния, как это хорошо известно, что является ключевым преимуществом настоящего изобретения.

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

13. Пакеты Client Request and Status

Хосту необходим малый объем информации от клиента для, в целом, оптимальной настройки линии связи хост-клиент. Рекомендуется, чтобы клиент передавал на хост один пакет Client Request and Status Packet в каждом подкадре. Клиент должен передавать этот пакет как первый пакет в пакете Reverse Link Encapsulation Packet, чтобы гарантировать его надежную доставку на хост. Передача этого пакета также осуществляется по запросу хоста с использованием поля Reverse Link Flags в пакете Reverse Link Encapsulation Packet. Пакет Client Request and Status Packet используется для информирования хоста об ошибках и статусе. В режиме внешней работы каждый хост должен быть способен принимать этот пакет и каждый клиент должен быть способен передавать этот пакет для правильного или оптимального использования протокола интерфейса MDD. Несмотря на рекомендацию об обязательной поддержке встроенных операций, т.е. встроенных хостов и встроенных клиентов, для этих пакетов в этом нет необходдимости.

Формат пакета Client Request and Status Packet показан на фиг.22. Согласно фиг.22 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, cClient ID, Reverse Link Request, Capability Change, Graphics Bugs, CRC Error Count и CRC. Этот тип пакета в общем случае идентифицируется как пакет типа 70 в 1-байтовом поле типа, и обычно использует заранее выбранную фиксированную длину 12 байтов.

Поле Reverse Link Request может использоваться для информирования хоста о количестве байтов, которые нужны клиенту в пакете Reverse Link Encapsulation Packet для передачи данных обратно на хост. Хост должен пытаться удовлетворить запрос, выделяя, по меньшей мере, это количество байтов в пакете Reverse Link Encapsulation Packet. Хост может передавать более одного пакета Reverse Link Encapsulation Packet в подкадре для размещения данных. Клиент может передавать пакет Client Request and Status Packet в любое время, и хост будет интерпретировать параметр Reverse Link Request как полное количество байтов, запрошенных в одном подкадре. Дополнительные детали и конкретные примеры того, как данные обратной линии связи передаются обратно на хост, показаны ниже.

14. Пакеты Bit Block Transfer

Пакет Bit Block Transfer Packet обеспечивает средство, структуру или метод для прокрутки областей дисплея в любом направлении. Дисплеи, имеющие такую возможность, будут сообщать об этой возможности в бите 0 поля Display Feature Capability Indicators пакета Client Capability Packet. Формат пакета Bit Block Transfer Packet согласно одному варианту осуществления показан на фиг.23. Согласно фиг.23 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, Upper Left X Value, Upper Left Y Value, Window Width, Window Height, Window X Movement, Window Y Movement и CRC. Этот тип пакета в общем случае идентифицируется как пакет типа 71 и согласно одному варианту осуществления использует заранее выбранную фиксированную длину 15 байтов.

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

15. Пакеты Bitmap Area Fill

Пакет Bitmap Area Fill Packet обеспечивает средство, структуру или способ для простой инициализации области дисплея на один цвет. Дисплеи, имеющие такую возможность, будут сообщать об этой возможности в бите 1 поля Client Feature Capability Indicators пакета Client Capability Packet. Один вариант осуществления формата пакета Bitmap Area Fill Packet показан на фиг.24. Согласно фиг.24 в этом случае структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, Upper Left X Value, Upper Left Y Value, Window Width, Window Height, Data Format Descriptor, Pixel Area Fill Value и CRC. Этот тип пакета в общем случае идентифицируется как пакет типа 72 в 1-байтовом поле типа и использует заранее выбранную фиксированную длину 17 байтов.

16. Пакеты Bitmap Pattern Fill

Пакет Bitmap Pattern Fill Packet обеспечивает средство или структуру для простой инициализации области дисплея на заранее выбранный шаблон. Дисплеи, имеющие такую возможность, будут сообщать об этой возможности в бите 2 поля Client Feature Capability пакета Client Capability Packet. Верхний левый угол шаблона заполнения выравнивается с верхним левым углом окна, подлежащего заполнению, пока горизонтальное или вертикальное смещение шаблона не станет равно нулю. Если окно, подлежащее заполнению, шире или выше шаблона заполнения, то шаблон можно повторить по горизонтали или вертикали несколько раз, чтобы заполнить окно. При необходимости последний повторенный шаблон обрезается справа или снизу. Если окно меньше шаблона заполнения, то шаблон заполнения можно обрезать справа или снизу для подгонки к окну.

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

Один вариант осуществления формата пакета Bitmap Pattern Fill Packet показан на фиг.25. Согласно фиг.25 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, Upper Left X Value, Upper Left Y Value, Window Width, Window Height, Pattern Width, Pattern Height, Horizontal Pattern Offset, Vertical Pattern Offset, Data Format Descriptor, Parameter CRC, Pattern Pixel Data и Pixel Data CRC. Согласно некоторым вариантам осуществления этот тип пакета в общем случае идентифицируется как пакет типа 73 в 1-байтовом поле типа.

17. Пакеты Communication Link Data Channel

Пакет Communication Link Data Channel Packet обеспечивает структуру, средство или способ для клиента с возможностью вычислений на высоком уровне, например, КПК, для связи с беспроводным приемопередатчиком, например сотовым телефоном или с устройством беспроводного порта данных. В этом случае линия связи MDDI действует как удобный высокоскоростной интерфейс между мобильным дисплеем, где этот пакет переносит данные на канальном уровне операционной системы устройства. Например, этот пакет можно использовать, если в мобильный дисплей встроен веб-браузер, клиент электронной почты или целый КПК. Дисплеи, имеющие такую возможность, будут сообщать об этой возможности в бите 3 поля Client Feature Capability пакета Client Capability Packet.

Формат варианта осуществления пакета Communication Link Data Channel Packet показан на фиг.26. Согласно фиг.26 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, Parameter CRC, Communication Link Data и Communication Data CRC. Согласно одному варианту осуществления этот тип пакета в общем случае идентифицируется как пакет типа 74 в поле типа.

18. Пакеты Interface Type Handoff Request

Пакет Interface Type Handoff Request Packet обеспечивает средство, метод или структуру, которое/ый/ая позволяет хосту запрашивать, чтобы клиент или дисплей перешел из существующего или текущего режима в режимы типа 1 (последовательный), типа 2 (2-битовый параллельный), типа 3 (4-битовый параллельный) или типа 4 (8-битовый параллельный). Прежде чем хост запросит конкретный режим, он должен удостовериться, что клиент способен работать в нужном режиме, проверив биты 6 и 7 поля Display Feature Capability Indicators пакета Client Capability Packet. Один вариант осуществления формата пакета Interface Type Handoff Request Packet показан на фиг.27. Согласно фиг.27 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, Interface Type, Reserved 1 и CRC. Этот тип пакета в общем случае идентифицируется как пакет типа 75 и использует заранее выбранную фиксированную длину 4 байта.

19. Пакеты Interface Type Acknowledge

Пакет Interface Type Acknowledge Packet передается клиентом и обеспечивает средство, метод или структуру, которое/ый/ая позволяет клиенту подтвердить получение пакета Interface Type Handoff Packet. Запрашиваемый режим типа 1 (последовательный), типа 2 (2-битовый параллельный), типа 3 (4-битовый параллельный) или типа 4 (8-битовый параллельный), возвращается на хост в качестве параметра этого пакета. Формат одного варианта осуществления пакета Interface Type Acknowledge Packet показан на фиг.28. Согласно фиг.28 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, cClient ID, Interface Type, Reseerved 1 и CRC. Этот тип пакета в общем случае идентифицируется как пакет типа 76 и использует заранее выбранную фиксированную длину 4 байта.

20. Пакеты Perform Type Handoff

Пакет Perform Type Handoff Packet – это средство, структура или метод для хоста, чтобы отдавать команду клиенту перейти в режим, указанный в этом пакете. Это должен быть то же режим, который был ранее запрошен и подтвержден посредством пакетов Interface Type Handoff Request Packet и Interface Type Acknowledge Packet. Хост и клиент должны переключаться в согласованный режим после передачи этого пакета. Клиент может потерять и восстановить синхронизацию линии связи во время смены режима. Формат одного варианта осуществления для пакета Perform Type Handoff Packet показан на фиг.29. Согласно фиг.29 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, Packet Type, Reserve 1 и CRC. Этот тип пакета в общем случае идентифицируется как пакет типа 77 в 1-байтовом поле типа и использует заранее выбранную фиксированную длину 4 байта.

21. Пакеты Forward Audio Channel Enable

Этот пакет обеспечивает структуру, метод или средство, которая/ый/ое позволяет хосту включать или отключать аудиоканалы на клиенте. Эта возможность полезна потому, что клиент (например, дисплей) может отключать усилители аудиосигнала или аналогичные элементы схемы для экономии мощности, когда хост не выдает аудиосигналов. Это значительно труднее реализовать полностью, просто используя наличие или отсутствие аудиопотоков в качестве индикатора. Состояние по умолчанию, когда система клиента включена, предусматривает, что все аудиоканалы включены. Формат одного варианта осуществления пакета Forward Audio Channel Enable Packet показан на фиг.30. Согласно фиг.30 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, Audio Channel Enable Mask и CRC. Этот тип пакета в общем случае идентифицируется как пакет типа 78 в 1-байтовом поле типа и использует заранее выбранную фиксированную длину 4 байта.

22. Пакеты Reverse Audio Sample Rate

Этот пакет позволяет хосту включать или отключать аудиоканал обратной линии связи и задавать частоту дискретизации аудиоданных этого потока. Хост выбирает частоту дискретизации, которая задается действительной в пакете Client Capability Packet. Если хост выбирает неверную частоту дискретизации, то клиент не будет передавать аудиопакет на хост и соответствующая ошибка, значение ошибки или сигнал ошибки может передаваться на хост в пакете Client Error Report Packet. Хост может заблокировать аудиопоток обратной линии связи, задав частоту дискретизации равной 255. Состояние по умолчанию, предполагаемое, когда система клиента первоначально включена или подключена, предусматривает, что аудиопоток обратной линии связи заблокирован. Формат одного варианта осуществления для пакета Reverse Audio Sample Rate Packet показан на фиг.31. Согласно фиг.31 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, Audio Sample Rate, Reserved 1 и CRC. Этот тип пакета в общем случае идентифицируется как пакет типа 79 и использует заранее выбранную фиксированную длину 4 байта.

23. Пакеты Digital Content Protection Overhead

Этот пакет обеспечивает структуру, метод или средство, которая/ый/ое позволяет хосту и клиенту обмениваться сообщениями, связанными с используемым методом защиты цифрового контента. В настоящее время известны два типа защиты контента, Digital Transmission Content Protection (DTCP) и High-bandwidth Digital Content Protection System (HDCP), причем зарезервировано место для будущих альтернативных обозначений схемы защиты. Используемый метод задается параметром Content Protection Type в этом пакете. Формат варианта осуществления пакета Digital Content Protection Overhead Packet показан на фиг.32. Согласно фиг.32 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, bClient ID, Content Protection Type, Content Protection Overhead Messages и CRC. Этот тип пакета в общем случае идентифицируется как пакет типа 80.

24. Пакеты Transparent Color Enable

Пакет Transparent Color Enable Packet – это структура, метод или средство, которая/ый/ое используется для указания, какой цвет является прозрачным в дисплее, и для включения или отключения использования прозрачного цвета для отображения изображений. Дисплеи, имеющие эту возможность, будут сообщать об этой возможности в бите 4 поля Client Feature Capability пакета Client Capability Packet. Когда пиксель со значением для прозрачного цвета записан в битовую карту, цвет не изменяется по сравнению с первоначальным значением. Формат пакета Transparent Color Enable Packet показан на фиг.33. Как показано на фиг.33, согласно одному варианту осуществления структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, Transparent Color Enable, Reserved 1, Alpha-Cursor Identifier, Data Format Descriptor, Transparent Pixel Value и CRC. Этот тип пакета в общем случае идентифицируется как пакет типа 81 в 1-байтовом поле типа и использует заранее выбранную фиксированную длину 10 байтов.

25. Пакеты Round Trip Delay Measurement

Пакет Round Trip Delay Measurement Packet обеспечивает структуру, метод или средство, которая/ый/ое используется для измерения задержки на распространение от хоста к клиенту плюс задержка от клиента (дисплея) обратно на хост. Это измерение по природе своей включает в себя задержки, которые существуют в драйверах и приемниках линии и в подсистеме взаимосоединения. Это измерение используется для задания параметров задержки реверсирования и делителя скорости передачи данных на обратной линии связи в пакете Reverse Link Encapsulation Packet, в целом описанном ниже. Этот пакет наиболее полезен, когда линия связи MDDI работает на максимальной скорости, предназначенной для конкретного применения. Пакет может передаваться в режиме типа 1 и на более низкой скорости передачи данных для увеличения диапазона измерения двусторонней задержки. Сигнал MDDI_Stb ведет себя как при передаче всех нулей в следующих полях: обоих полях Guard Time, All Zero и Measurement Period. В результате MDDI_Stb включается на половине скорости передачи данных, поэтому его можно использовать в качестве периодического тактового сигнала на клиенте в течение поля Measurement Period.

В одном из вариантов осуществления клиент в общем случае указывает возможность поддерживать пакет Round Trip Delay Measurement Packet путем использования бита 18 поля Client Feature Capability Indicators пакета Client Capability Packet. Рекомендуется, чтобы все клиенты поддерживали измерение двусторонней задержки, но возможно, чтобы хост знал наихудшую двустороннюю задержку на основании максимальной задержки кабеля и максимальных задержек драйвера и приемника. Хост также может заранее знать двустороннюю задержку для линии связи MDDI, используемой во внутреннем режиме, поскольку это аспект известных конструктивных элементов (длины проводников, тип схемы и особенности и т.д.) устройства, в котором используется интерфейс.

Формат пакета Round Trip Delay Measurement Packet показан на фиг.34. Как показано на фиг.34, согласно одному варианту осуществления структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, Parameter CRC, Guard Time 1, Measurement Period, All Zero и Guard Time 2. Этот тип пакета в общем случае идентифицируется как пакет типа 82 и использует заранее выбранную фиксированную длину 159 битов.

На фиг.35 показано хронирование событий в пакете Round Trip Delay Measurement Packet. Согласно фиг.35 хост передает пакет Round Trip Delay Measurement Packet, в котором, как показано, имеются поля Parameter CRC и Strobe Alignment, за которыми следуют поля All Zero и Guard Time 1. Задержка 3502 происходит до того, как пакет достигает устройства отображения или обрабатывающей схемы клиента. Когда клиент принимает пакет, он передает байты 0xff, 0xff и 30 шаблонов 0х0 в начале поля Measurement Period с точностью, определяемой клиентом из практических соображений. Фактическое время, когда клиент начинает передавать эту последовательность, имеет задержку после начала поля Measurement Period с точки зрения хоста. Величина этой задержки по существу равна времени распространения пакета через драйверы и приемники линии и в подсистему взаимосоединения (кабели, проводники). Аналогичная величина задержки 3504 привносится в шаблон для распространения от клиента обратно на хост.

Для точного определения времени двусторонней задержки для сигналов, проходящих на клиент и от него, хост подсчитывает количество битовых периодов времени прямой линии связи от начала поля Measurement Period, пока не будет зарегистрировано начало байтов 0xff, 0xff и последовательности из 30 0x0 после поступления. Эта информация используется для определения времени двустороннего прохождения сигнала от хоста на клиент и обратно. Затем около половины этого времени приписывается задержке, создаваемой при одностороннем прохождении на клиент.

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

26. Пакет Forward Link Skew Calibration

Пакет Forward Link Skew Calibration Packet позволяет клиенту настраиваться на различия в задержке на распространение сигналов MDDI_Data относительно сигнала MDDI_Stb. Без компенсации рассогласования задержки максимальная скорость передачи данных обычно ограничивается величиной потенциального наихудшего изменения в этих задержках. В общем случае этот пакет передается, только когда скорость передачи данных на прямой линии связи настроена на скорость около 50 Мбит/с или ниже. После передачи этого пакета для калибровки дисплея скорость передачи данных можно ступенчато увеличивать свыше 50 Мбит/с. Если скорость передачи данных задана слишком высокой во время процесса калибровки рассинхронизации, дисплей может синхронизироваться с псевдонимом битового периода, из-за чего настройка компенсации рассогласования задержки может быть отключена более чем на один битовый период, что приводит к ошибочному тактированию данных. Тип интерфейса с наивысшей скоростью передачи данных или наибольший возможный тип интерфейса выбирается до передачи пакета Forward Link Skew Calibration Packet, что обеспечивает калибровку всех существующих битов данных.

Один из вариантов осуществления формата пакета Forward Link Skew Calibration Packet показан на фиг.56. Согласно фиг.56 структура этого типа пакета предусматривает наличие полей Packet Length (2 байта), Packet Type, hClient ID, Parameter CRC, All Zero, Calibration Data Sequence и CRC. Этот тип пакета в общем случае идентифицируется как пакет типа 83 в поле типа и согласно одному варианту осуществления имеет заранее выбранную длину 515.

Виртуальная панель управления

Использование виртуальной панели управления (Virtual Control Panel (VCP)) позволяет хосту задавать определенные пользовательские сигналы управления на клиенте. Благодаря тому что хост может регулировать эти параметры, пользовательский интерфейс на клиенте можно упростить, поскольку экраны, которые позволяют пользователю регулировать такие параметры, как громкость звука или яркость дисплея, могут генерироваться программным обеспечением хоста, а не одним или более микропроцессорами на клиенте. Хост имеет возможность считывать настройки параметров на клиенте и определять диапазон правильных значений для каждого сигнала управления. Клиент обычно имеет возможность сообщать хосту, какие параметры управления можно регулировать.

Коды управления (коды VCP) и соответствующие значения данных обычно указываются и используются для задания сигналов управления и настроек на клиенте. Коды VCP в спецификации MDDI расширены до 16 битов для сохранения надлежащего выравнивания полей данных в определениях пакетов и в будущем для поддержки дополнительных значений, которые уникальны для этого интерфейса или будущих усовершенствований.

27. Пакет Request VCP Feature

Пакет Request VCP Feature Packet обеспечивает средство, механизм или метод для хоста, чтобы запрашивать текущую настройку конкретного параметра управления или всех действительных параметров управления. В общем случае в ответ на пакет VCP клиент передает соответствующую информацию в пакете VCP Feature Reply Packet. Согласно одному варианту осуществления клиент указывает возможность поддерживать пакет Request VCP Feature Packet с использованием бита 13 поля Client Feature Capability Indicators пакета Client Capability Packet.

Формат пакета Request VCP Feature Packet согласно одному варианту осуществления показан на фиг.69. Согласно фиг.69 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, MCCS VCP code и CRC. Этот тип пакета в общем случае идентифицируется согласно одному варианту осуществления как тип 128, что указано в 2-байтовом поле типа. Длина пакета, которая указывает полное количество байтов в пакете, не включая поле длины пакета, обычно является фиксированной для этого типа пакета и имеет длину 8 байтов.

Поле hClient ID зарезервировано для использования в качестве ID клиента в будущих реализациях и обычно задано равным нулю. Поле MCCS VCP Code содержит 2 байта информации, которая указывает MCCS VCP Control Code Parameter. Значение находится в диапазоне от 0 до 255, в результате чего пакет VCP Feature Reply Packet возвращается, имея в поле VCP Feature Reply List единственный элемент, соответствующий указанному коду MCCS. Код MCCS VCP Code, равный 65535 (0xffff), запрашивает пакет VCP Feature Reply Packet, в котором поле VCP Feature Reply List содержит элемент Feature Reply List Item для каждого сигнала управления, поддерживаемого клиентом. Значения с 256 по 65534 для этого поля зарезервированы для использования в будущем и в настоящее время не используются.

28. Пакет VCP Feature Reply

Пакет VCP Feature Reply Packet обеспечивает средство, механизм или метод для клиента, чтобы отвечать на запрос хоста, сообщая ему текущие настройки конкретного параметра управления или всех действительных параметров управления. В общем случае клиент передает пакет VCP Feature Reply Packet в ответ на пакет Request VCP Feature Packet. Этот пакет полезен для определения текущей настройки конкретного параметра, для определения правильного диапазона для конкретного сигнала управления, для определения, поддерживает ли клиент конкретный сигнал управления, или для определения набора сигналов управления, поддерживаемых клиентом. Если передан пакет Request VCP Feature, указывающий на конкретный сигнал управления, который не реализован на клиенте, то возвращается пакет VCP Feature Reply Packet, имеющий единственный элемент поля VCP Feature Reply List, соответствующий нереализованному сигналу управления, который содержит соответствующий код ошибки. Согласно одному варианту осуществления клиент указывает возможность поддерживать пакет VCP Feature Reply Packet с использованием бита 13 поля Client Feature Capability пакета Client Capability Packet.

Формат пакета VCP Feature Reply Packet согласно одному варианту осуществления показан на фиг.70. Согласно фиг.70 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, cClient ID, MCCS Version, Reply Sequence Number, VCP Feature Reply List и CRC. Этот тип пакета в общем случае идентифицируется согласно одному варианту осуществления как тип 129, что указано в 2-байтовом поле типа.

Поле cClient ID содержит информацию, зарезервированную для ID клиента. Это поле зарезервировано для использования в будущем и в общем случае задано равным нулю. Поле MCCS Version содержит 2 байта информации, которая указывает версию спецификации VESA MCCS Specification, реализованную на клиенте.

2-байтовое поле Reply Sequence Number содержит информацию или данные, где указан порядковый номер пакетов VCP Feature Reply, возвращенных клиентом. Клиент возвращает в ответ на пакет Request VCP Feature Packet один или более пакетов VCP Feature Reply, в которых значение MCCS Control Code равно 65535. Клиент может распространять ответный список особенностей на множественные пакеты VCP Feature Reply. В этом случае клиент присваивает порядковый номер каждому последовательному пакету, и порядковые номера пакетов VCP Feature Reply, переданных в ответ на один пакет Request VCP Feature Packet, начинаются с нуля и увеличиваются на единицу. Последний элемент VCP Feature List Item в последнем пакете VCP Feature Reply Packet должен содержать значение MCCS VCP Control Code, равное 0xffff, указывающее, что пакет является последним и содержит наибольший порядковый номер группы возвращенных пакетов. Если в ответ на пакет Request VCP Feature Packet передан только один пакет VCP Feature Reply Packet, то номер Reply Sequence Number в этом одном пакете равен нулю и поле VCP Feature Reply List содержит запись, где значение MCCS VCP Control Code равно 0xffff.

Поле Number of Features in List содержит 2 байта, которые указывают количество элементов VCP Feature List Item, присутствующих в поле VCP Feature Reply List этого пакета, а поле VCP Feature Reply List – это группа байтов, которые содержат один или несколько элементов VCP Feature Reply List Item. Формат одного элемента VCP Feature Reply List Item согласно одному варианту осуществления показан на фиг.71.

Согласно фиг.71 каждый элемент VCP Feature Reply List Item имеет длину 12 байтов и содержит поля MCCS VCP Code, Result Code, Maximum Value и Present Value. 2-байтовое поле MCCS VCP Code содержит данные или информацию, указывающую параметр MCCS VCP Control Code Parameter, связанный с этим элементом списка. Согласно этому варианту осуществления действительными считаются только значения Control Code, определенные во 2-й или более поздней версии спецификации VESA MCCS Specification. 2-байтовое поле Result Code содержит информацию, которая указывает код ошибки, связанный с запросом информации, касающейся указанного MCCS VCP Control. Значение ‘0’ означает отсутствие ошибки, а значение ‘1’ означает, что конкретный сигнал управления не реализован на клиенте. Другие значения этого поля со 2-го по 65535 в настоящее время зарезервированы для использования в будущем и реализации другого приложения, предусмотренного в области техники, но в настоящее время не используются.

4-байтовое поле Maximum Value содержит 32-битовое беззнаковое целое, которое указывает наибольшее возможное значение, равное которому можно задать указанный MCCS Control. Если запрашиваемый сигнал управления не реализован на клиенте, то это значение задается равным нулю. Если возвращенное значение имеет длину менее 32 битов (4 байтов), то значение приводят к 32-битовому целому, оставляя старшие (неиспользованные) байты равными нулю. 4-байтовое поле Present Value содержит информацию, которая указывает текущее значение указанного непрерывного (C) или прерывистого (NC) сигнала управления MCCS VCP. Если запрашиваемый сигнал управления не реализован на клиенте или если сигнал управления реализован, но относится к типу табличных данных (Т), то это значение задается равным нулю. Если возвращенное значение имеет длину меньше 32 битов (4 байтов) на спецификацию VESA MCCS, то значение приводят к 32-битовому целому, оставляя старшие (неиспользованные) байты равными нулю.

29. Пакет Set VCP Feature

Пакет Set VCP Feature Packet обеспечивает средство, механизм или метод для хоста, чтобы задавать значения сигнала управления VCP для непрерывных и прерывистых сигналов управления на клиенте. Согласно одному варианту осуществления клиент указывает возможность поддерживать пакет Set VCP Feature Packet с использованием бита 13 поля Client Feature Capability пакета Client Capability Packet.

Формат пакета Set VCP Feature Packet согласно одному варианту осуществления показан на фиг.72. Согласно фиг.72 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, MCCS VCP Code, Number of Values in List, Control Value List и CRC. Этот тип пакета в общем случае идентифицируется как a тип 130, что указано в 2-байтовом поле типа, и имеет длину 20 байтов, исключая поле Packet Length.

Поле hClient ID опять же использует 2-байтовое значение для указания или действия в качестве ID клиента. Это поле зарезервировано для использования в будущем и в настоящее время задано равным нулю. Поле MCCS VCP Code использует 2 байта информации или значений для указания параметра MCCS VCP Control Code Parameter, подлежащего регулировке. 2-байтовое поле Number of Values in List содержит информацию или значения для указания количества 16-битовых значений, которые существуют в поле Control Value List. Поле Control Value List обычно содержит один элемент, если значение MCCS Control Code не связано с таблицей на клиенте. В случае сигналов управления, не связанных с таблицей, поле Control Value List будет содержать значение, указывающее новое значение, подлежащее записи в параметр сигнала управления, указанный в поле MCCS VCP Code. Для сигналов управления, связанных с таблицей, формат данных в поле Control Value List задается описанием параметра указанного MCCS VCP Code. Если список содержит значения, которые больше одного байта, то сначала передается самый младший байт согласно методу, описанному в другом месте. Наконец, 2-байтовое поле CRC содержит 16-битовый CRC всех байтов в пакете, включая Packet Length.

30. Пакет Request Valid Parameter

Пакет Request Valid Parameter Packet используется как средство или структура, полезная для запроса, чтобы клиент возвратил пакет Valid Parameter Reply Packet, содержащий список параметров, поддерживаемых конкретным прерывистым (NC) или табличным (T) сигналом управления. Этот пакет должен задавать только прерывистые сигналы управления или сигналы управления, связанные с таблицей на клиенте, и не должен указывать значение MCCS VCP Code, равное 65535 (0xffff), задающее все сигналы управления. В случае указания неподдерживаемого или недействительного MCCS VCP Code в пакете Valid Parameter Reply Packet возвращается соответствующее значение ошибки. Согласно одному варианту осуществления клиент указывает возможность поддерживать Request Valid Parameter Packet с использованием бита 13 поля Client Feature Capability пакета Display Capability Packet.

Формат пакета Request Valid Parameter Packet согласно одному варианту осуществления показан на фиг.73. Согласно фиг.73 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ID, MCCS VCP Code и CRC. Этот тип пакета в общем случае идентифицируется согласно одному варианту осуществления как тип 131, что указано в 2-байтовом поле типа.

Длина пакета, указанная в 2-байтовом поле Packet Length, в общем случае, задана равной полному количеству байтов в пакете, не включая поле длины пакета длиной, что составляет 8 байтов. Поле hClient ID опять же задает ID клиента, но в настоящее время зарезервировано для использования в будущем, что очевидно специалистам в данной области, и задано равным нулю. 2-байтовое поле MCCS VCP Code содержит значение, указывающее запрашиваемый параметр прерывистого сигнала управления MCCS VCP Control Code Parameter. Значение этого поля должно соответствовать прерывистому сигналу управления, реализованному на клиенте. Значения с 256 по 65535 (0xffff) обычно зарезервированы или считаются неправильными и рассматриваются как нереализованный сигнал управления в сообщении об ошибке.

31. Пакет Valid Parameter Reply

Пакет Valid Parameter Reply Packet передается в ответ на пакет Request Valid Parameter Packet. Он используется в качестве средства, метода или структуры для идентификации правильных настроек для прерывистого сигнала управления MCCS VCP или сигнала управления, который возвращает содержимое таблицы. Если сигнал управления относится к таблице на клиенте, то поле VCP Parameter Reply List просто содержит конкретный список последовательных табличных значений, которые были запрошены. Если содержимое таблицы не вписывается в пакет Valid Parameter Reply Packet, то клиент может передать множественные пакеты с последовательными номерами Reply Sequence Number. Согласно одному варианту осуществления клиент указывает возможность поддерживать пакет Valid Parameter Reply Packet с использованием бита 13 поля Client Feature Capability пакета Client Capability Packet.

Хост может запросить содержимое таблицы следующим образом: хост передает пакет Set VCP Feature Packet, содержащий необходимые или желательные параметры, например параметр чтения записи, смещение LUT и выбор RGB; затем хост передает пакет Request Valid Parameter Packet, который указывает нужный сигнал управления; затем клиент возвращает один или несколько пакетов Valid Parameter Reply, содержащий(е) табличные данные. Эта последовательность операций осуществляет функцию, сходную с функциями чтения таблицы, описанными в рабочей модели MCCS.

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

Формат пакета Valid Parameter Reply Packet согласно одному варианту осуществления показано на фиг.74. Согласно фиг.74 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, cClient ID, MCCS VCP Code, Response Code, Reply Sequence Number, Number Values in List, VCP Parameter Reply List и CRC. Этот тип пакета в общем случае идентифицируется согласно одному варианту осуществления как тип 132, что указано в 2-байтовом поле типа.

Поле cClient ID зарезервировано для будущего ID клиента согласно указанному выше, тогда как 3-байтовое поле MCCS VCP Code Packet содержит значение, указывающее параметр прерывистого сигнала управления MCCS VCP Control Code Parameter, описанный этим пакетом. Если в пакете Request Valid Parameter Packet указан неверный код MCCS VCP Control Code, то такое же неверное значение параметра будет указано в этом поле с соответствующим значением в поле Response Code. Если код MCCS Control Code неверен, то поле VCP Parameter Reply List будет иметь нулевую длину.

Поле Response Code содержит 2 байта информации или значений, которые указывают характер ответа, связанного с запросом информации, касающейся указанного MCCS VCP Control. Если значение в этом поле равно 0, то считается, что для этого типа данных нет никакой ошибки, и передается последний пакет Valid Parameter Reply Packet в последовательности, имеющий наибольший номер Reply Sequence Number. Если значение в этом поле равно 1, то считается, что ошибки нет, но будут переданы другие пакеты Valid Parameter Reply, имеющие более высокие порядковые номера. Если значение в этом поле равно 2, то считается, что указанный сигнал управления не реализован на клиенте. Если значение этого поля равно 3, то указанный сигнал управления является прерывистым сигналом управления (он является непрерывным сигналом управления, который всегда имеет правильный набор всех значений от нуля до максимального значения). Значения этого поля от 4 до 65535 зарезервированы для использования в будущем и обычно не используются.

2-байтовое поле Reply Sequence Number указывает порядковый номер пакетов Valid Parameter Reply, возвращаемых клиентом. Клиент возвращает один или несколько пакетов Valid Parameter Reply в ответ на пакет Request Valid Parameter Packet. Клиент может распределить поле VCP Parameter Reply List по множественным пакетам Valid Parameter Reply Packets. В этом случае клиент может присвоить порядковый номер каждому последовательному пакету и задать Response Code равным 1 во всех пакетах последовательности, кроме последнего. Последний пакет Valid Parameter Reply Packet в последовательности будет иметь наивысший номер Reply Sequence Number и Response Code содержит значение 0.

2-байтовое поле Number of Values in List указывает количество 16-битовых значений, существующих в поле VCP Parameter Reply List. Если Response Code не равен нулю, то параметр Number of Values in List равен нулю. Поле VCP Parameter Reply List содержит список от 0 до 32760 2-байтовых значений, которые указывают набор правильных значений для прерывистого сигнала управления, указанного в поле MCCS Control Code. Определения кодов прерывистого сигнала управления заданы в спецификации VESA MCCS Specification. Наконец, согласно данному варианту осуществления поле CRC содержит 16-битовый CRC всех байтов в пакете, включая Packet Length.

Изображения альфа-курсора

Интерфейс MDD и соответствующий протокол, отвечающий изобретению, и механизмы передачи данных по линии связи обеспечивают поддержку множественных плоскостей изображения, которые перекрываются друг с другом и могут иметь различную степень прозрачности. Аппаратный курсор можно реализовать с использованием перекрывающего изображения, которое имеет переменное смещение X-Y. Ниже приведен обзор функциональных возможностей и соответствующей протокольной поддержки альфа-курсора. Возможность поддерживать пакеты изображения альфа-курсора задана в пакете Alpha-Cursor Image Capability Packet, который передается в ответ на пакет Request Specific Status Packet.

32. Пакет Alpha-Cursor Image Capability

Пакет Alpha-Cursor Image Capability Packet используется для задания характеристик изображения альфа-курсора и соответствующих карт прозрачности на клиенте. Согласно одному варианту осуществления клиент указывает возможность поддерживать пакет Alpha-Cursor Image Capability Packet с использованием значения параметра 133 в поле Valid Parameter Reply List пакета Valid Status Reply List Packet. Длина пакета, указанная в поле длины пакета, задана равной фиксированному значению 20 согласно одному варианту осуществления, не включая поле длины пакета.

Формат пакета Alpha-Cursor Image Capability Packet согласно одному варианту осуществления показан на фиг.75. Согласно фиг.75 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, cClient ID, Alpha-Cursor Identifier, Alpha-Cursor Bitmap Width, Alpha-Cursor Bitmap Height, RGB Capability, Monochrome Capability, Reserved 1, Y Cr Cb Capability, Transparency Map Res., Capability Bits и CRC. Поле cClient ID обычно зарезервировано для использования в будущем как ID клиента и в настоящее время задано равным нулю.

Поле Alpha Cursor Identifier (2 байта) содержит значение, которое идентифицирует конкретную плоскость альфа-курсора. Если клиент поддерживает n плоскостей изображения альфа-курсора, то поле Alpha-Cursor Identifier имеет верный диапазон от 0 до n-1. Согласно одному варианту осуществления значение n задано в поле Alpha-Cursor Image Planes пакета Client Capability Packet. Клиент возвращает уникальный пакет Alpha-Cursor Image Capability Packet для каждой плоскости изображения альфа-курсора.

2-байтовое значение поля Alpha-Cursor Bitmap Width указывает ширину растрового изображения альфа-курсора, выраженную числом пикселей, а 2-байтовое значение поля Alpha-Cursor Bitmap Height указывает высоту растрового изображения альфа-курсора, выраженную числом пикселей.

Поле RGB Capability использует 2 байта для задания числа битов разрешения, которое может отображаться в формате RGB. Если клиент не может использовать формат RGB, то это значение равно нулю. Слово RGB Capability состоит из трех отдельных значений, которые согласно одному варианту осуществления реализованы следующим образом: биты с 3-го по 0-й задают максимальное число битов синего цвета (интенсивность синего цвета) в каждом пикселе; биты с 7-го по 4-й задают максимальное число битов зеленого цвета (интенсивность зеленого цвета) в каждом пикселе; биты с 11-го по 8-й задают максимальное число битов красного цвета (интенсивность красного цвета) в каждом пикселе; и биты с 15 по 12 зарезервированы для использования в будущем в представлении информации возможностей RGB, поэтому в настоящее время обычно заданы равными нулю.

1-байтовое поле Monochrome Capability используется для задания числа битов разрешения, которое может отображаться в монохромном формате. Если клиент не может использовать монохромный формат, то это значение задано равным нулю. Биты с 7-го по 4-й зарезервированы для использования в будущем и потому обычно заданы равными нулю. Биты с 3-го по 0-й задают максимальное число битов градации серого, которая может существовать в каждом пикселе. Эти четыре бита позволяют указывать, что каждый пиксель состоит из 1 ˜ 15 битов. Если значение равно нулю, значит, монохромный формат не поддерживается клиентом.

1-байтовое поле Reserved 1 содержит значение, в общем случае зарезервированное для использования в будущем, и поэтому все биты в этом поле заданы равными нулю. Это обуславливает выравнивание следующих 2-байтовых полей с 16-битовым словом адреса и выравнивание 4-байтовых полей с 32-битовым словом адреса.

2-байтовое поле Y Cb Cr Capability содержит значения или информацию, которая задает число битов разрешения, которое может отображаться в формате Y Cb Cr. Если клиент не может использовать формат Y Cb Cr, то это значение равно нулю. В общем случае согласно одному варианту осуществления слово Y Cb Cr Capability состоит из трех отдельных значений, где: биты с 3-го по 0-й указывают максимальное число битов, задающих выборку Cr; биты с 7-го по 4-й указывают максимальное число битов, задающих выборку Cb; биты с 11-го по 8-й указывают максимальное число битов, задающих выборку Y; и биты с 15-го по 12-й зарезервированы для использования в будущем при представлении информации или значений возможностей Y Cb Cr, но в настоящее время заданы равными нулю.

1-байтовое поле Transparency Map Resolution содержит значения или информацию, которая задает число битов (насыщенность) в положении каждого пикселя карты прозрачности изображения альфа-курсора. Это значение может составлять от 1 до 8. Если значение равно нулю, значит, карта прозрачности не поддерживается для этого буфера изображения альфа-курсора (буфера, заданного полем Alpha-Cursor Identifier).

1-байтовое поле Capability Bits обеспечивает значения или информацию, которая содержит набор флагов, указывающих возможности, связанные с буфером изображения альфа-курсора. Согласно одному варианту осуществления флаги определены следующим образом: бит 0 служит для выбора пиксельных данных в пакете Alpha-Cursor Video Stream Packet для нахождения в упакованном формате. Бит 1 служит для показа, что данные карты прозрачности в пакете Alpha-Cursor Transparency Packet находятся в упакованном формате. Пример выровненных по границе байта и упакованных данных карты прозрачности приведен на фиг.76. Бит 2 служит для показа, что плоскость изображения альфа-курсора поддерживает возможность смещения изображения с использованием пакета Alpha-Cursor Image Offset Packet. Бит 3 служит для показа, что плоскость изображения альфа-курсора может поддерживать формат данных карты цветов. Для плоскостей изображения альфа-курсора используется та же таблица карты цветов, что и для главного буфера изображения и масштабированных видеопотоков. Карта цветов сконфигурирована с использованием пакета Color Map Packet, описанного в другом месте.

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

33. Пакет Alpha-Cursor Transparency Map

Пакет Alpha-Cursor Transparency Map Packet определяет содержимое карты прозрачности изображения для указанной плоскости изображения альфа-курсора. Для некоторых приложений может требоваться карта прозрачности, которая больше, чем объем данных, которые можно передать в одном пакете. В таких случаях могут передаваться множественные пакеты Alpha-Cursor Transparency Map, каждый из которых имеет отдельный поднабор карты прозрачности, с использованием полей Transparency Map X и Y Start, описанных ниже. Эти поля действуют аналогично полям X Start и Y Start пакета Video Stream Packet. Клиент указывает возможность поддерживать пакет Alpha-Cursor Transparency Map Packet согласно одному варианту осуществления с использованием поля Transparency Map Resolution пакета Alpha-Cursor Image Capability Packet для каждой конкретной плоскости альфа-курсора, заданной полем Alpha-Cursor Identifier пакета Alpha-Cursor Image Capability Packet. Поля длины пакета и ID клиента действуют, как и раньше, для других пакетов, рассмотренных выше. Согласно одному варианту осуществления значение 134 в поле Packet Type используется для идентификации пакета как пакета Alpha-Cursor Transparency Map Packet.

Формат пакета Alpha-Cursor Transparency Map Packet согласно одному варианту осуществления показана на фиг.76. Согласно фиг.76 структура этого типа пакета предусматривает наличие полей Packet Length, Packet Type, hClient ED, Alpha-Cursor Identifier, Transparency Map X Start, Transparency Map Y Start, Transparency Map Resolution, Reserved 1, Parameter CRC, Transparency Map Media и Transparency Map Data CRC.

2-байтовое поле Alpha Cursor Identifier имеет значение, которое идентифицирует конкретную плоскость альфа-курсора. Если клиент поддерживает n плоскостей изображения альфа-курсора, то поле Alpha-Cursor Identifier имеет верный диапазон от 0 до n-1.

2-байтовые поля Transparency Map X и Y Start задают абсолютные координаты X и Y, где точкой (Transparency Map X Start, Transparency Map Y Start) является первый пиксель в рассмотренном ниже поле Transparency Map Data.

Поле Transparency Map Resolution (1 байт) содержит значение, которое указывает разрешение карты прозрачности и упакованы ли данные. Согласно одному варианту осуществления этого поля биты с 3-по по 0-й задают число битов разрешения, которые существуют во всех элементах таблицы карты прозрачности. Верные значения указывают ширину в пределах от 1 до 8 битов. Значения 0 и с 9 по 15 считаются неверными. Это значение должно совпадать со значением, возвращенным клиентом в поле Transparency Map Resolution пакета Alpha-Cursor Image Capability Packet. Биты с 6-го по 4-й зарезервированы для использования в будущем и потому в настоящее время обычно заданы равными логическому нулю. Бит 7 этого байта указывает, находится ли поле Transparency Map Data в упакованной или выровненной по границе байта форме. Если бит 7 равен ‘1’, то поле Transparency Map Data находится в упакованной форме, а если ‘0’, то данные выровнены по границе байта. Пример упакованных и выровненных по границе байта данных карты прозрачности приведен в другом месте. Значение этого бита совпадает со значением бита 1 поля Capability Bits пакета Alpha-Cursor Image Capability Packet.

1-байтовое поле Reserved 1 зарезервировано для использования в будущем, поэтому все биты в этом поле в общем случае установлены на уровень логического нуля. Одной целью этого поля является выравнивание всех последующих 2-байтовых полей с 16-битовым словом адреса и выравнивание 4-байтовых полей с 32-битовым словом адреса. Поле Parameter CRC содержит 16-битовый CRC всех байтов от поля Packet Length до поля Reserved 1. Если контроль CRC не проходит, то весь пакет отбрасывается.

Для поля Transparency Map Data каждое место в карте прозрачности имеет от 1 до 8 битов в ширину. Если одна карта прозрачности не помещается в один Alpha and Cursor Transparency Map Packet, то всю карту прозрачности можно задать, передавая множественные пакеты с разными значениями Transparency Map Data и Transparency Map X и Y Start в каждом пакете.

2-байтовое поле Transparency Map Data CRC содержит 16-битовый CRC только для поля Transparency Map Data. Если этот контроль CRC не проходит, то поле Transparency Map Data все же можно использовать, но счетчик ошибок CRC получает приращение.

34. Пакет Alpha-Cursor Image Offset

Пакет Alpha-Cursor Image Offset задает смещение курсора по X и Y относительно верхнего левого угла главного изображения дисплея. Формат пакета Alpha-Cursor Image Offset Packet проиллюстрирован на фиг.77. Как показано на фиг.77, согласно одному варианту осуществления структура пакета Alpha-Cursor Image Offset Packet содержит поля Packet Length, Packet Type, hClient ID, Alpha-Cursor X Offset, Alpha-Cursor Y Offset и CRC. Согласно одному варианту осуществления клиент указывает возможность поддерживать пакет Alpha-Cursor Image Offset Packet с использованием бита 2 поля Capability Bits пакета Alpha-Cursor Image Capability Packet для каждой конкретной плоскости альфа-курсора, заданной полем Alpha-Cursor Identifier пакета Alpha-Cursor Image Capability Packet. Согласно одному варианту осуществления длина пакета фиксирована и равна 10, что указано в 2-байтовом поле Packet Length. Согласно одному варианту осуществления поле Packet Type, равное 135, идентифицирует пакет как пакет Alpha-Cursor Image Offset Packet.

2-байтовые поля Alpha-Cursor X и Y Offset содержат значения, которые указывают смещение по горизонтали и вертикали соответственно самого левого столбца и верхней строки соответственно пикселей изображения курсора относительно левого верхнего угла главного изображения. 2-байтовое поле hClient ID содержит 16-битовое беззнаковое целое, зарезервированное для ID клиента. Это поле зарезервировано для использования в будущем и обычно установлено на уровни или значения логического нуля для битов.

35. Пакет Alpha-Cursor Video Stream

Пакет Alpha-Cursor Video Stream переносит видеоданные для обновления прямоугольной области плоскости изображения альфа-курсора. Эта область может быть размером в один пиксель или во весь дисплей. Формат пакета Alpha-Cursor Video Stream Packet проиллюстрирован на фиг.78. Как показано на фиг.78, согласно одному варианту осуществления структура пакета Alpha-Cursor Video Stream Packet содержит поля Packet Length, Packet Type, bClient ID, Video Data Format Attributes, X Left Edge, Y Top Edge, X Rigth Edge, Y Bottom Edge, X Start, Y Start, Pixel Count, Parameter Crc Pixel Data и Pixel Data CRC. Согласно одному варианту осуществления клиент указывает возможность поддерживать пакет Alpha-Cursor Video Stream Packet и связанные с ним параметры с использованием пакета Alpha-Cursor Image Capability Packet для каждой конкретной плоскости альфа-курсора, заданной полем Alpha-Cursor Identifier пакета Alpha-Cursor Image Capability Packet, и значение 17 в поле типа пакета указывает или идентифицирует пакет как пакет Alpha-Cursor Video Stream Packet. Поле hClient ID (2 байта) зарезервировано для использования в будущем как ID клиента и в настоящее время в общем случае задано равным нулю, что очевидно специалистам в данной области.

2-байтовое поле Video Data Format Descriptor содержит информацию или значение, которое указывает формат каждого пикселя в поле Pixel Data в данном потоке в данном пакете. Формат пиксельных данных должен согласовываться с, по меньшей мере, одним из действительных форматов для плоскости изображения альфа-курсора, заданной в пакете Alpha-Cursor Image Capability Packet. Поле Video Data Format Descriptor содержит значение, которое задает формат пикселя только для текущего пакета и не предусматривает, что постоянный формат будет непрерывно использоваться на протяжении времени жизни конкретного видеопотока. На вышеописанной фиг.11 показано, как кодируется поле Video Data Format Descriptor.

Формат таков:

Согласно одному варианту осуществления, когда биты [15:13] равны ‘000’, видеоданные состоят из массива монохромных пикселей, где число битов на пиксель задано битами с 3-го по 0-й слова Video Data Format Descriptor. Биты с 11-го по 4-й заданы равными нулю. Когда биты [15:13] равны ‘001’, видеоданные состоят из массива цветных пикселей, каждый из которых задает цвет посредством карты цветов (палитры). Биты с 5-го по 0-й слова Video Data Format Descriptor задают число битов на пиксель, и биты с 11-го по 6-й заданы равными нулю. Когда биты [15:13] равны ‘010’, видеоданные состоят из массива цветных пикселей в формате необработанного RGB, где число битов на пиксель красного цвета задано битами с 11-го по 8-й, число битов на пиксель зеленого цвета задано битами с 7-го по 4-й, и число битов на пиксель синего цвета задано битами с 3-го по 0-й. Суммарное число битов в каждом пикселе равно сумме количеств битов, используемых для красного, зеленого и синего цветов.

Когда биты [15:13] равны ‘011’, видеоданные состоят из массива видеоданных в формате 4:2:2 Y Cb Cr с информацией яркости и цветности. Число битов на пиксель для яркости (Y) задано битами с 11-го по 8-й, число битов компонента Cb задано битами с 7-го по 4-й, и число битов компонента Cr задано битами с 3-го по 0-й. Компоненты Cb и Cr передаются на половинной скорости как Y. Выборки видеосигнала в части Pixel Data этого пакета будут организованы следующим образом: Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3,…, где Cbn и Crn связаны с Yn и Yn+1, и Cbn+2 и Crn+2 связаны с Yn+2 и Yn+3, и т.д. Yn, Yn+1, Yn+2 и Yn+3 – это значения яркости четырех последовательных пикселей в одной строке слева направо. Упорядочение цветовых компонентов такое же, как в формате Microsoft UYVY FOURCC. При наличии нечетного числа пикселей в строке (X Right Edge – X Left Edge + 1) в окне, указанном пакетом Video Stream Packet, за значением Cb, соответствующим последнему пикселю в каждой строке, будет следовать значение Y первого пикселя следующей строки.

Рекомендуется, чтобы окна, использующие формат Y Cb Cr, имели ширину, равную четному числу пикселей. Поле Pixel Data в пакете содержит нечетное количество пикселей. Оно может содержать нечетное или четное число пикселей в случае, когда последний пиксель в поле Pixel Data соответствует последнему пикселю строки в окне, заданном в заголовке пакета Video Stream Packet, т.е. когда положение X последнего пикселя в поле Pixel Data равно X Right Edge.

Для всех пяти форматов бит 12 (обозначенный “P” на фигурах) указывает, упакованы ли выборки в поле Pixel Data. Когда значение бита 12 равно ‘0’, каждый пиксель и каждый цвет в каждом пикселе в поле Pixel Data выровнен по границе байта границей байта интерфейса MDDI. Когда значение бита 12 равно ‘1’, каждый пиксель и каждый цвет в каждом пикселе в поле Pixel Data упакован относительно предыдущего пикселя или цвета в пикселе без оставшихся неиспользованных битов.

Согласно одному варианту осуществления поле Pixel Data Attributes (2 байта) имеет ряд битовых значений, которые интерпретируются следующим образом. Биты 1 и 0 выбирают, как маршрутизируются пиксельные данные дисплея. Для битовых значений ’11’ данные отображаются для обоих глаз, для битовых значений ’10’ данные маршрутизируются только в левый глаз, и для битовых значений ’01’, данные маршрутизируются только в правый глаз.

Бит 2 поля Pixel Data Attributes указывает, представлено ли поле Pixel Data в чересстрочном формате, причем значение ‘0’ означает, что пиксельные данные присутствуют в стандартном прогрессивном формате и что номер строки (координата Y пикселя) увеличивается на 1 при переходе от одной строки к следующей. Когда этот бит имеет значение ‘1’, пиксельные данные находятся в чересстрочном формате и номер строки увеличивается на 2 при переходе от одной строки к следующей. Бит 3 указывает, что поле Pixel Data находится в формате чередования пикселей. Это аналогично стандартному режиму интерфейса, обеспечиваемому битом 2, за исключением того, что чередование осуществляется по вертикали, а не по горизонтали. Когда бит 3 равен ‘0’, поле Pixel Data находится в стандартном прогрессивном формате и номер столбца (координата X пикселя) увеличивается на 1 при приеме каждого последующего пикселя. Когда бит 3 равен ‘1’, поле Pixel Data находится в формате чередования пикселей и номер столбца увеличивается на 2 при приеме каждого пикселя.

Бит 4 поля Pixel Data Attributes указывает, относятся ли пиксельные данные к дисплею или к камере, когда данные переносятся на внутренний дисплей или от него для беспроводного телефона, или аналогичного устройства, или даже портативного компьютера, или других таких устройств, рассмотренных выше, или когда данные переносятся на или от камеры, встроенной или непосредственно подключенной к устройству. Когда бит 4 равен ‘0’, пиксельные данные переносятся в кадровый буфер дисплея или из него. Когда бит 4 равен ‘1’, пиксельные данные переносятся на или от камеры или видеоустройства того или иного типа, каковые устройства хорошо известны в технике.

Бит 5 поля Pixel Data Attributes зарезервирован для использования или применения в будущем интерфейса MDD и поэтому обычно задан равным нулевому значению или ‘0’.

Биты 7 и 6 поля Pixel Data Attributes представляют собой биты обновления дисплея, которые задают кадровый буфер для записи пиксельных данных. Более конкретные эффекты рассмотрены в другом месте. Для битовых значений ’01’ пиксельные данные записываются в автономный буфер изображения. Для битовых значений ’00’ пиксельные данные записываются в буфер изображения, используемый для обновления дисплея. Для битовых значений ’11’ пиксельные данные записываются во все буферы изображения. Битовые значения или комбинация ’10’ рассматривается как неверное значение или обозначение и пиксельные данные игнорируются и не записываются ни в один из буферов изображения. Это значение можно использовать для будущих применений интерфейса. Биты с 8-го по 15-й поля Pixel Data Attributes зарезервированы для использования в будущем и поэтому обычно заданы равными нулю.

Согласно одному варианту осуществления 2-байтовые поля X Start и Y Start указывают абсолютные координаты X и Y точки (X Start, Y Start) для первого пикселя в поле Pixel Data. 2-байтовые поля X Left Edge и Y Top Edge указывают координату X левого края и координату Y верхнего края окна изображения альфа-курсора, заполненного полем Pixel Data, а поля X Right Edge и Y Bottom Edge указывают координату X правого края и координату Y нижнего края обновляемого окна изображения альфа-курсора.

Поле Pixel Count (2 байта) указывает число пикселей в поле Pixel Data, что рассмотрено ниже. 2-байтовое поле Parameter CRC содержит CRC всех байтов от поля Packet Length до поля Pixel Count. Если этот контроль CRC не проходит, то весь пакет отбрасывается.

Поле Pixel Data содержит необработанную видеоинформацию, подлежащую отображению, которая форматирована согласно описанному полем Video Data Format Descriptor. Данные передаются “построчно”, что рассмотрено в другом месте. Поле Pixel Data CRC (2 байта) содержит 16-битовый CRC только для поля Pixel Data. Если проверка CRC этого значения не проходит, то поле Pixel Data все же можно использовать, но счетчик ошибок CRC получает приращение.

Изображения масштабированного видеопотока

Интерфейс MDD или механизм, структура, средства или метод протокола обеспечивает поддержку изображений масштабированного видеопотока, которые позволяют хосту передавать на клиент изображение, увеличенное или уменьшенное относительно исходного изображения, и масштабированное изображение копируется в главный буфер изображения. Далее обеспечен обзор функциональных особенностей масштабированного видеопотока и соответствующей протокольной поддержки. Возможность поддерживать масштабированные видеопотоки заданы в пакете Scaled Video Stream Capability Packet, который передается в ответ на пакет Request Specific Status Packet.

36. Пакет Scaled Video Stream Capability

Пакет Scaled Video Stream Capability Packet определяет характеристики исходного изображения масштабированного видеопотока на клиенте или используемого клиентом. Формат пакета Scaled Video Stream Capability Packet в общем виде показан на фиг.79. Как показано на фиг.79 согласно одному варианту осуществления, структура пакета Scaled Video Stream Capability Packet содержит поля Packet Length, Packet Type, cClient ID, Max Number of Streams, Source Max X Size, Source Max Y size, RGB Capability, Monochrome Capability, Reserved 1, Y Cr Cb Capability, Reserved 2 и CRC. Длина пакета согласно одному варианту осуществления выбирается фиксированной и равной 20 байтам, что показано в поле длины, включая 2-байтовое поле cClient ID, которое зарезервировано для использования в качестве ID клиента, иначе задано равным нулю, и поле CRC. Согласно одному варианту осуществления клиент указывает возможность поддерживать пакет Scaled Video Stream Capability Packet с использованием значения параметра 143 в поле Valid Parameter Reply List пакета Valid Status Reply List Packet.

2-байтовое поле Maximum Number of Streams содержит значение для идентификации максимального количества одновременных масштабированных видеопотоков, которые могут быть выделены в одно время. Согласно одному варианту осуществления клиент должен отклонять запрос на выделение масштабированного видеопотока, если максимальное количество масштабированных видеопотоков уже выделено. Если выделено менее максимального количества масштабированных видеопотоков, клиент может также отклонять запрос выделения на основании других ресурсных ограничений на клиенте.

Поля Source Maximum X Size и Y Size (2 байта) задают значения максимальной ширины и высоты соответственно исходного изображения масштабированного видеопотока, выраженные количеством пикселей.

Поле RGB Capability использует значения для указания количества битов разрешения, которое может отображаться в формате RGB. Если масштабированный видеопоток не может использовать формат RGB, то это значение задано равным нулю. Слово RGB Capability состоит из трех отдельных беззнаковых значений, в которых: биты с 3-го по 0-й задают максимальное число битов синего цвета (интенсивность синего цвета) в каждом пикселе, биты с 7-го по 4-й задают максимальное число битов зеленого цвета (интенсивность зеленого цвета) в каждом пикселе, и биты с 11-го по 8-й задают максимальное число битов красного цвета (интенсивность красного цвета) в каждом пикселе, а биты с 15-го по 12-й зарезервированы для использования в будущем в будущих определениях возможностей и обычно заданы равными нулю.

1-байтовое поле Monochrome Capability содержит значение, которое задает число битов разрешения, которое может отображаться в монохромном формате. Если масштабированный видеопоток не может использовать монохромный формат, то это значение задано равным нулю. Биты с 7-го по 4-й зарезервированы для использования в будущем и поэтому должны быть заданы равными нулю (‘0’) для текущих приложений, хотя это может изменяться с течением времени, что очевидно специалистам в данной области. Биты с 3-го по 0-й задают максимальное число битов градации серого, которые могут существовать в каждом пикселе. Эти четыре бита позволяют указывать, что каждый пиксель содержит от 1 до 15 битов. Если значение равно нулю, значит, монохромный формат не поддерживается масштабированным видеопотоком.

Поле Reserved 1 (здесь 1 байт) зарезервировано для использования в будущем при обеспечении значений, относящихся к информации или данным Scaled Video Stream Packet. Поэтому в настоящее время все биты в этом поле установлены на логический ‘0’. Одной целью этого поля является выравнивание всех последующих 2-байтовых полей с 16-битовым словом адреса и выравнивание 4-байтовых полей с 32-битовым словом адреса.

2-байтовое поле Y Cb Cr Capability содержит значения, которые указывают число битов разрешения, которое может отображаться в формате Y Cb Cr. Если масштабированный видеопоток не может использовать формат Y Cb Cr, то это значение равно нулю. Слово Y Cb Cr Capability состоит из трех отдельных беззнаковых значений, в которых биты с 3-го по 0-й задают максимальное число битов, которое указывает выборку Cb; биты с 7-го по 4-й задают максимальное число битов, которое указывает выборку Cb; биты с 11-го по 8-й задают максимальное число битов, которое указывает выборку Y; и биты с 15-го по 12-й зарезервированы для использования в будущем и, в общем случае, задано равным нулю.

1-байтовое поле Capability Bits содержит набор флагов, которые указывают возможности, связанные с масштабированным видеопотоком. Флаги заданы следующим образом: бит 0 охватывает пиксельные данные в пакете Scaled Video Stream Packet, которые могут быть в упакованном формате. Пример упакованных и выровненных по границе байта пиксельных данных показан ранее на фиг.12. Бит 1 зарезервирован для использования в будущем и в общем случае задан равным нулю; бит 2 также зарезервирован для использования в будущем и задан равным нулю; бит 3 охватывает масштабированные видеопотоки, которые могут быть заданы в формате данных карты цветов. Для масштабированных видеопотоков используется та же таблица карты цветов, что и для главного буфера изображения и плоскостей изображения альфа-курсора. Карта цветов сконфигурирована с использованием пакета Color Map Packet, описанного в другом месте; и биты с 7-го по 4-й зарезервированы для использования в будущем и обычно заданы равными нулю.

Поле Reserved 2 (здесь 1 байт) зарезервирован для использования в будущем при обеспечении значений, относящихся к информации или данным Scaled Video Stream Packet. Поэтому в настоящее время все биты в этом поле установлены на логический ‘0’. Одной целью этого поля является выравнивание всех последующих 2-байтовых полей с 16-битовым словом адреса и выравнивание 4-байтовых полей с 32-битовым словом адреса.

37. Пакет Scaled Video Stream Setup

Пакет Scaled Video Stream Setup Packet используется для задания параметров масштабированного видеопотока, и клиент использует информацию для выделения внутреннего хранилища для буферизации и масштабирования изображения. Выделение потока может быть отменено путем передачи этого пакета, в котором поля X Image Size и Y Image Size равны нулю. Масштабированные видеопотоки, выделение которых было отменено, могут быть повторно выделены позже с теми же или другими параметрами потока. Согласно одному варианту осуществления клиент указывает возможность поддерживать пакет Scaled Video Stream Setup Packet с использованием значения параметра 143 в поле Valid Parameter Reply List пакета Valid Status Reply List Packet и с использованием ненулевого значения в поле Maximum Number of Streams пакета Scaled Video Stream Capability Packet.

Формат пакета Scaled Video Stream Setup Packet в общем виде показан на фиг.80. Как показано на фиг.80 согласно одному варианту осуществления структура пакета Scaled Video Stream Setup Packet содержит поля Packet Length Packet Type, hClient, Stream ID, Visual Data Format Descriptor, Pixel Data Attributes, X Left Edge, Y Top Edge, X Right Edge, Y Bottom Edge, X Image Size, Y Image Size и CRC.

2-байтовое поле Packet Length указывает полное количество байтов в пакете не включая поле длины пакета. Согласно одному варианту осуществления эта длина пакета фиксирована и равна 24. 2-байтовое поле Packet Type использует значение 136 для идентификации пакета как пакета Scaled Video Stream Setup Packet. 2-байтовое поле hClient ID зарезервировано для использования в будущем в качестве ID клиента и в настоящее время в общем случае все его биты имеют значение логического нуля, или пока пользователь протокола не определит, какие значения ID нужно использовать, что должно быть известно.

Поле Stream ID использует 2 байта для задания уникального идентификатора для ID потока. Это значение присваивается хостом и может принимать значение от нуля до максимального значения ID потока, указанного в пакете Client Capability Packet. Хост должен тщательно управлять использованием значений Stream ID, чтобы гарантировать, что каждому активному потоку присвоено уникальное значение и что потоки, которые больше не активны, подверглись снятию выделения или повторному присвоению.

Согласно одному варианту осуществления поле Video Data Format Descriptor использует 2 байта для указания формата каждого пикселя в пиксельных данных данного потока в текущем пакете. Формат пиксельных данных должен полностью согласовываться с, по меньшей мере, одним из действительных форматов для плоскости изображения альфа-курсора, заданным в пакете Alpha-Cursor Image Capability Packet. Video Data Format Descriptor задает формат пикселя только для текущего пакета и не предусматривает, что постоянный формат будет непрерывно использоваться на протяжении времени жизни конкретного видеопотока. На фиг.11 показан вариант осуществления кодирования поля Video Data Format Descriptor согласно рассмотренному выше для других пакетов.

2-байтовое поле Pixel Data Attributes имеет значения, которые интерпретируются следующим образом:

Биты 1 и 0 выбирают дисплей, на который нужно маршрутизировать пиксельные данные.

Биты [1:0] = 11 или 00 – данные отображаются на оба глаза

Биты [1:0] = 10 – данные маршрутизируются только на левый глаз

Биты [1:0] = 01 – данные маршрутизируются только на правый глаз

Бит 2 указывает, находится ли поле Pixel Data в чересстрочном формате. Когда бит 2 равен 0, поле Pixel Data находится в стандартном прогрессивном формате. Номер строки (координата Y пикселя) увеличивается на 1 при переходе от одной строки к следующей. Когда бит 2 равен 1, поле Pixel Data находится в чересстрочном формате. Номер строки (координата Y пикселя) увеличивается на 2 при переходе от одной строки к следующей.

Бит 3 указывает, находится для поле Pixel Data в формате чередования пикселей. Это аналогично стандартному режиму интерфейса, обеспечиваемому битом 2, за исключением того, что чередование осуществляется по вертикали, а не по горизонтали. Когда бит 3 равен 0, поле Pixel Data находится в стандартном прогрессивном формате. Номер столбца (координата X пикселя) увеличивается на 1 при приеме каждого следующего пикселя. Когда бит 3 равен 1, поле Pixel Data находится в формате чередования пикселей. Номер столбца (координата X пикселя) увеличивается на 2 при приеме каждого пикселя.

Бит 4 указывает, относятся ли пиксельные данные к дисплею или камере. Когда бит 4 равен 0, пиксельные данные передаются в или из кадрового буфера дисплея. Когда бит 4 равен 1, пиксельные данные передаются в или из камеры. Бит 5 зарезервирован для использования в будущем и поэтому обычно задан равным нулю.

Биты 7 и 6 представляют собой биты обновления дисплея, которые указывают кадровый буфер для записи пиксельных данных. Эффекты битов обновления кадра более подробно описаны ниже. Когда биты [7:6] равны ’01’, пиксельные данные записываются в автономный буфер изображения. Когда биты [7:6] равны ’00’, пиксельные данные записываются в буфер изображения, используемый для обновления дисплея. Когда биты [7:6] равны ’11’, пиксельные данные записываются во все буферы изображения. Если биты [7:6] равны ’10’, это считается неверным значением. Эти биты в настоящее время зарезервированы для использования в будущем. В этой ситуации пиксельные данные будут проигнорированы и не будут записаны ни в один буфер изображения.

Биты с 8-го по 15-й зарезервированы для использования в будущем и в общем случае установлены на уровень или значения логического нуля.

38. Пакет Scaled Video Stream Acknowledgement

Пакет Scaled Video Stream Acknowledgement Packet позволяет клиенту подтвердить прием пакета Scaled Video Stream Setup Packet. Клиент может указать возможность поддерживать пакет Scaled Video Stream Acknowledgement Packet посредством значения параметра 143 в поле Valid Parameter Reply List пакета Valid Status Reply List Packet и посредством ненулевого значения в поле Maximum Number of Streams пакета Scaled Video Stream Capability Packet.

Формат пакета Scaled Video Stream Acknowledgement Packet в общем виде показан на фиг.81. Как видно из фиг.81, согласно одному варианту осуществления структура пакета Scaled Video Stream Acknowledgement Packet имеет поля Packet Length, Packet Type, cClient, Stream ID, ACK Code и CRC. 2-байтовое поле Packet Length используется для указания полного количества байтов, исключая поле длины пакета со значением 10 для этого типа пакета, а значение 137 поля Packet Type идентифицирует пакет как пакет Scaled Video Stream Acknowledgement Packet.

2-байтовое поле cClient ID зарезервирован для использования в будущем для ID клиента и в общем случае задано равным нулю. 2-байтовое поле Stream ID задает уникальный идентификатор для ID потока. Это то же значение, которое присвоено хостом в пакете Scaled Video Stream Setup Packet.

2-байтовое поле Ack Code обеспечивает значения, содержащие код, который описывает исход попытки обновления указанного масштабированного видеопотока, согласно одному варианту осуществления заданы следующие коды:

0 – попытка выделения потока была успешной.

1 – попытка отмены выделения потока была успешной.

2 – безуспешная попытка выделить ID потока, который уже был выделен.

3 – безуспешная попытка отмены выделения ID потока, выделение которого уже было отменено.

4 – клиент не поддерживает масштабированные видеопотоки.

5 – параметры потока не согласуются с возможностями клиента.

6 – значение ID потока больше максимального значения, разрешенного клиентом.

7 – клиент имеет недостаточно ресурсов для выделения указанного потока.

2-байтовое поле CRC содержит CRC всех байтов в пакете, включая Packet Length.

39. Пакет Scaled Video Stream

Пакет Scaled Video Stream Packet используется для передачи пиксельных данных, связанных с конкретным масштабированным видеопотоком. Размер области, на которую ссылается этот пакет, задан пакетом Scaled Video Stream Setup Packet. Клиент может указать возможность поддержки пакета Scaled Video Stream Packet посредством значения параметра 143 в поле Valid Parameter Reply List пакета Valid Status Reply List Packet и с использованием уведомления об успешном выделении масштабированного видеопотока в поле Ack Code пакета Scaled Video Stream Acknowledgement Packet.

Формат одного варианта осуществления пакета Scaled Video Stream Packet показан в общем виде на фиг.82. Согласно фиг.82 структура пакета Scaled Video Stream Packet имеет поля Packet Length, Packet Type, hClient ID, Stream ID, Parameter CRC, Pixel Count, Pixel Data и Pixel Data CRC. 2-байтовое поле Packet Type использует значение 18 для идентификации пакета как пакета Scaled Video Stream Packet. Поле hClient ID зарезервировано для ID клиента и в общем случае задано равным нулю. Как и раньше, 2-байтовое поле Stream ID задает уникальный идентификатор для ID потока. Это значение указывается хостом в пакете Scaled Video Stream Setup Packet и подтверждается в пакете Scaled Video Stream Acknowledgement Packet.

2-байтовое поле Pixel Count указывает число пикселей в поле Pixel Data согласно описанному ниже. 2-байтовое поле Parameter CRC имеет CRC всех байтов от поля Packet Length до поля Pixel Count. Если этот контроль CRC не проходит, то весь пакет отбрасывается. 2-байтовое поле Pixel Data содержит необработанную видеоинформацию, подлежащую масштабированию с последующим отображением. Данные форматированы так, как описано полем Video Data Format Descriptor. Данные передаются построчно в ранее указанное время.

2-байтовое поле Pixel Data CRC содержит CRC только поля Pixel Data. Если этот контроль CRC не проходит, то поле Pixel Data все же можно использовать, но счетчик ошибок CRC получает приращение.

40. Пакет Request Specific Status

Пакет Request Specific Status Packet обеспечивает средство, механизм или метод для хоста, чтобы запрашивать у клиента передачу пакета способности или статуса обратно на хост, как указано в этом пакете. Клиент возвращает пакет заданного типа в следующем пакете Reverse Link Encapsulation Packet. Клиент будет обычно передавать бит 17 в поле Client Feature Capability пакета Client Capability Packet, если клиент имеет возможность отвечать на пакет Request Specific Status Packet. Хост может воспользоваться удобным методом определения всех типов пакетов статуса, на которые клиент может отвечать, заключающимся в использовании пакета Valid Status Reply List Packet, описанного в другом месте. Клиент может указать возможность выдавать в ответ пакет Valid Status Reply List Packet с использованием бита 21 поля Client Feature Capability пакета Client Capability Packet.

Формат одного варианта осуществления пакета Request Specific Status Packet показан в общем виде на фиг.83. Согласно фиг.83 структура пакета Request Specific Status Packet имеет поля Packet Length, Packet Type, hClient ID, Status Packet ID и CRC. Поле Packet Length указывает полное количество байтов в пакете, не включая поле длины пакета, и обычно имеет фиксированное значение 10 для этого типа пакета. Значение 138 поля Packet Type идентифицирует этот пакет как пакет Request Specific Status Packet. Поле hClient ID (2 байта) зарезервировано для использования в будущем как ID клиента и в настоящее время задано равным нулю, а 2-байтовое поле Status Packet ID указывает тип пакета возможности или статуса, который клиент собирается передавать на хост. Типичные типы пакета таковы:

66 – пакет Client Capability Packet передан клиентом.

133 – пакет Alpha-Cursor Image Capability Packet передан клиентом.

139 – передан пакет Valid Status Reply List Packet, который идентифицирует конкретные типы пакетов возможности и статуса, которые может передавать клиент.

140 – пакет Packet Processing Delay Parameters Packet передан клиентом.

141 – пакет Personal Client Capability Packet передан клиентом.

142 – пакет Client Error Report Packet передан клиентом.

143 – пакет Scaled Video Stream Capability Packet передан клиентом.

144 – пакет Client Identification Packet передан клиентом.

Значения поля Packet Type с 56 по 63 можно использовать под идентификаторы возможности и статуса, зависящие от производителя.

Поле CRC, опять же, содержит CRC всех байтов в пакете, включая Packet Length.

41. Пакет Valid Status Reply List

Пакет Valid Status Reply List Packet обеспечивает структурой, средством или методом, чтобы иметь список пакетов возможности и статуса, на которые клиент может отвечать. Клиент может указывать возможность поддержки пакета Valid Status Reply List Packet с использованием бита 21 поля Client Feature Capability пакета Client Capability Packet.

Формат одного варианта осуществления пакета Valid Status Reply List Packet показан в общем виде на фиг.84. Согласно фиг.84 структура пакета Valid Status Reply List Packet имеет поля Packet Length, Packet Type, cClient ID, Number of Values in List, Valid Parameter Reply List и CRC. Длина пакета для этого типа пакета обычно имеет фиксированное значение, равное 10, и значение типа 139 идентифицирует пакет как пакет Valid Status Reply Packet. Поле cClient ID зарезервировано для использования в будущем как ID клиента и обычно задано равным нулю. 2-байтовое поле Number of Values in List указывает количество элементов в следующем поле Valid Parameter Reply List.

Поле Valid Parameter Reply List содержит список 2-байтовых параметров, которые указывают типы пакетов возможности или статуса, которые клиент может передавать на хост. Если клиент указал, что он может отвечать на пакет Request Specific Status Packet (с использованием бита 21 поля Client Feature Capability в пакете Client Capability Packet), значит, он способен передавать, по меньшей мере, пакет Client Capability Packet (Packet Type = 66) и пакет Valid Status Reply List Packet (Packet Type = 139). Типы пакетов, которые может передавать клиент и которые могут быть включены в этот список, совместно с соответствующими присвоениями в целях данного варианта осуществления, таковы:

66 – Client Capability Packet.

133 – Alpha-Cursor Image Capability Packet.

139 – Valid Status Reply List Packet, который идентифицирует конкретные типы пакетов возможности и статуса, которые может передавать клиент.

140 – Packet Processing Delay Parameters Packet.

141 – Personal Display Capability Packet.

142 – Client Error Report Packet.

143 – Scaled Video Stream Capability Packet.

144 – Client Identification Packet.

145 – Alternate Display Capability Packet.

Значения поля Packet Type с 56 по 63 можно использовать под идентификаторы возможности и статуса, зависящие от производителя.

Поле CRC опять же содержит CRC всех байтов в пакете, включая Packet Length.

42. Пакет Packet Processing Delay Parameters

Пакет Packet Processing Delay Parameters Packet обеспечивает набор параметров, позволяющих хосту вычислять время, необходимое для выполнения обработки, связанной с приемом конкретного типа пакета. Некоторые команды, переданные хостом, не могут быть выполнены клиентом за нулевое время. Хост может опрашивать биты статуса в пакете Client Request and Status Packet для определения, выполнил ли клиент определенные функции, или хост может вычислять время выполнения с использованием параметров, возвращенных клиентом в пакете Packet Processing Delay Parameters Packet. Клиент может указать возможность поддержки пакета Packet Processing Delay Parameters Packet с использованием значения параметра 140 в поле Valid Parameter Reply List пакета Valid Status Reply List Packet.

Формат одного варианта осуществления пакета Packet Processing Delay Parameters Packet показан в общем виде на фиг.85А. Согласно фиг.85А структура пакета Packet Processing Delay Parameters Packet имеет поля Packet Length, Packet Type, cClient ID, Number of List Items, Delay Parameters List и CRC. Длина пакета для этого типа пакета обычно имеет фиксированное значение, равное 10, и значение типа 140 идентифицирует пакет как пакет Packet Processing Delay Parameters Packet. Поле cClient ID зарезервировано для использования в будущем как ID клиента и обычно задано равным нулю. 2-байтовое поле Number of List Items указывает количество элементов в следующем поле Valid Parameter Reply List.

Поле Delay Parameters List представляет собой список, содержащий один или несколько элементов поля Delay Parameter List. Формат согласно одному варианту осуществления одного элемента поля Delay Parameters List показан на фиг.85В, где показаны поля Packet Type for Delay, Pixel Delay, Horizontal Pixel Delay, Vertical Pixel Delay и Fixed Delay.

Каждый элемент Delay Parameters List Item в общем случае ограничен 6 байтами в длину и дополнительно задан следующим образом. 2-байтовое поле Packet Type for Delay указывает тип пакета, для которого применяются следующие параметры задержки. Поле Pixel Delay (1 байт) содержит индекс для значения задержки. Значение, считанное из таблицы, умножается на полное количество пикселей в поле назначения пакета. Полное количество пикселей равно ширине, умноженной на высоту области назначения битовой карты, на которую ссылается пакет. 1-байтовое поле Horizontal Pixel Delay содержит значение, которое является индексом для таблицы значений задержки (такой же таблицы, как DPVL). Значение, считанное из таблицы, умножается на ширину (в пикселях) поля назначения пакета. 1-байтовое поле Vertical Pixel Delay содержит значение, которое является индексом для таблицы значений задержки (обычно использует такую же таблицу, как DPVL). Значение, считанное из таблицы, умножается на высоту (в пикселях) поля назначения пакета.

Поле Fixed Delay использует 1 байт в качестве индекса для таблицы значений задержки (такой же таблицы, как DPVL). Значение, считанное из таблицы, является параметром фиксированной задержки, который представляет время, необходимое для обработки пакета, который не связан ни с какими значениями параметра, указанными в пакете. Полная задержка или время задержки на выполнение обработки пакета определяется согласно соотношению:

Delay = (PacketProcessingDelay(PixelDelay)-TotalPixels)+

(PacketProcessingDelay(HorizontalPixelDelay)-Width)+

(PacketProcessingDelay(VerticalPixelDelay)-Height)+

PacketProcessingDelay(FixedDelay)

Для некоторых пакетов величины Total Pixels, Width или Height не применяются, поскольку эти параметры не указаны в соответствующем пакете. В этих случаях соответствующий параметр Pixel Delay обычно задан равным нулю.

43. Пакет Personal Display Capability

Пакет Personal Display Capability Packet обеспечивает набор параметров, которые описывают возможности персонального устройства отображения, например дисплей, установленный на голове, или очки с дисплеем. Это позволяет хосту настраивать информацию дисплея согласно конкретным возможностям клиента. С другой стороны, клиент указывает возможность передавать пакет Personal Display Capability Packet с использованием соответствующего параметра в поле Valid Parameter Reply List пакета Valid Status Reply List Packet.

Формат одного варианта осуществления пакета Personal Display Capability Packet показан в общем виде на фиг.86. Согласно фиг.86 структура пакета Personal Display Capability Packet имеет поля Packet Length, Packet Type, cClient ID, Sub-Pixel Layout, Pixel Shape, Horizontal Field of View, Vertical Field of View, Visual Axis Crossing, Lft./Rt. Image, See Through, Maximum Brightness, Optical Capability, Minimum IPD, Maximum IPD, Points of IFeld of Curvature List и CRC. Согласно одному варианту осуществления значение поля Packet Length является фиксированной величиной 68. Значение поля Packet Type, равное 141, идентифицирует пакет как пакет Personal Display Capability Packet. Поле cClient ID зарезервировано для использования в будущем и в настоящее время в общем случае задано равным нулю.

Поле Sub-Pixel Layout задает физическую схему суб-пикселей сверху вниз и слева направо с использованием значений: 0 для указания, что схема суб-пикселей не задана; 1 для указания красно-зелено-синей полосы; 2 для указания сине-зелено-красной полосы; 3 для указания квадрапикселя, имеющего размещение суб-пикселей 2, в котором красный находится в верхнем левом углу, синий – в нижнем правом углу и два зеленых – в нижнем левом и верхнем правом углах; 4 для указания квадрапикселя, имеющего размещение суб-пикселей 2, в котором красный находится в нижнем левом углу, синий – в верхнем правом и два зеленых – в верхнем левом и нижнем правом углах; 5 – для указания дельты (триады); 6 – для указания мозаики, в котором красный, зеленый и синий перекрываются (например, дисплей LCOS с чередованием полей); значения с 7 по 255 в общем случае зарезервированы для использования в будущем.

Поле Pixel Shape задает форму каждого пикселя, состоящего из суб-пикселей конкретной конфигурации с использованием значений: 0 для указания, что форма суб-пикселя не задана; 1 для указания круга; 2 для указания квадрата; 3 для указания прямоугольника; 4 для указания овала; 5 для указания эллипса; и значения с 6 по 255 зарезервированы для использования в будущем для указания нужных форм, что очевидно специалисту в данной области.

1-байтовое поле Horizontal Field of View (HFOV) задает горизонтальное поле зрения в приращениях 0,5 градуса (например, если HFOV равно 30 градусам, то это значение равно 60). Если это значение равно нулю, значит, HFOV не задано.

1-байтовое поле Vertical Field of View (VFOV) задает вертикальное поле зрения в приращениях 0,5 градуса (например, если VFOV равно 30 градусам, то это значение равно 60). Если это значение равно нулю, значит, VFOV не задано.

1-байтовое поле Visual Axis Crossing задает пересечение зрительных осей в приращениях 0,01 диоптрии (1/м) (например, если пересечение зрительных осей равно 2,22 метра, то это значение равно 45). Если это значение равно нулю, значит, пересечение зрительных осей не задано.

1-байтовое поле Left/Right Image Overlap задает процент перекрытия левого и правого изображений. Допустимый диапазон перекрытия изображений в процентах составляет от 1 до 100. Значения от 101 до 255 являются неверными и обычно не используются. Если это значение равно нулю, значит, перекрытие изображений не задано.

1-байтовое поле See Through задает процент прозрачности изображения. Допустимый диапазон прозрачности в процентах составляет от 1 до 100. Значения от 101 до 254 являются неверными и не используются. Если это значение равно 255, значит, процент прозрачности не задан. 1-байтовое поле Maximum Brightness задает максимальную яркость в приращениях 20 нит (например, если максимальная яркость равна 100 нит, то это значение равно 5). Если это значение равно нулю, значит, максимальная яркость не задана.

2-байтовое поле Optical Capability Flags содержит различные поля, которые задают оптические возможности дисплея. Эти битовые значения в общем случае присваиваются следующим образом:

Биты с 15-го по 5-й зарезервированы для использования в будущем и обычно устанавлены в состояние логического нуля.

Бит 4 определяет значение Eye Glass Focus Adjustment, причем значение ‘0’ означает, что дисплей не имеет регулировки фокуса окуляра, и значение ‘1’ означает, что дисплей имеет регулировку фокуса окуляра.

Биты с 3-го по 2-й определяют значение Binocular Function следующим образом: значение 0 означает, что дисплей является бинокулярным и может отображать только 2-мерные (2D) изображения; значение 1 означает, что дисплей является бинокулярным и может отображать 3-мерные (3D) изображения; 2 означает, что дисплей является монокулярным, и 3 зарезервировано для использования в будущем.

Биты с 1-го по 0-й определяют значение Left-Right Field Curvature Symmetry, причем значение 0 означает, что кривизна поля не задана. Если это поле равно нулю, то все значения кривизны поля от A1 до E5 заданы равными нулю за исключением точки C3, которая задает фокусное расстояние дисплея или задано равным нулю для указания, что фокусное расстояние не задано. Значение 1 означает, что левый и правый дисплеи имеют одинаковую симметрию; значение 2 означает, что левый и правый дисплеи зеркально симметричны относительно вертикальной оси (столбец С); и 3 зарезервировано для использования в будущем.

1-байтовое поле Inter-Pupillary Distance (IPD) Minimum задает минимальное межзрачковое расстояние в миллиметрах (мм). Если это значение равно нулю, значит, минимальное межзрачковое расстояние не задано. 1-байтовое поле Inter-Pupillary Distance (IPD) Maximum задает максимальное межзрачковое расстояние в миллиметрах (мм). Если это значение равно нулю, значит, максимальное межзрачковое расстояние не задано.

Поле Points of Field Curvature List содержит список из 25 2-байтовых параметров, которые указывают фокусное расстояние в тысячных диоптрии (1/м) в диапазоне от 1 до 65535 (например, 1 – это 0,001 диоптрии, и 65535 – это 65,535 диоптрии). 25 элементов в поле Points of Field Curvature List обозначены с A1 по E5, как показано ниже. Точки должны быть равномерно распределены по активной области дисплея. Столбец С соответствует вертикальной оси дисплея, и строка 3 соответствует горизонтальной оси дисплея, соответственно. Столбцы А и Е соответствуют левому и правому краям дисплея соответственно. Строки 1 и 5 соответствуют верхнему и нижнему краям дисплея соответственно. Порядок среди 25 точек в списке такой: A1, B1, C1, D1, E1, A2, B2, C2, D2, E2, A3, B3, C3, D3, E3, A4, B4, C4, D4, E4, A5, B5, C5, D5, E5.

Поле CRC содержит CRC всех байтов в пакете, включая Packet Length.

44. Пакет Client Error Report

Пакет Client Error Report Packet действует как механизм или средство, позволяющее клиенту предоставлять хосту список ошибочных операций. Клиент может регистрировать широкий диапазон ошибок в ходе нормальной работы в результате приема определенных команд от хоста. Примеры этих ошибок включают в себя: клиент может получить команду работать в режиме, который он не поддерживает, клиент может получить пакет, содержащий определенные параметры, выходящие за пределы диапазона или за пределы возможностей клиента, клиент может получить команду войти в режим в неправильной последовательности. Пакет Client Error Report Packet можно использовать для регистрации ошибок в ходе нормальной работы, но он наиболее полезен разработчику и сборщику системы для выявления проблем при разработке и сборке систем хоста и клиента. Клиент указывает возможность передачи пакета Client Error Report Packet с использованием значения параметра 142 в поле Valid Parameter Reply List пакета Valid Status Reply List Packet.

Формат одного варианта осуществления пакета a Client Error Report Packet показан в общем виде на фиг.87A. Согласно фиг.87А структура пакета Client Error Report Packet имеет поля Packet Length, Packet Type, cClient ID, Number of List Items, Error Code List и CRC. Значение 142 поля Packet Type идентифицирует пакет как пакет Client Error Report Packet. Поле cClient ID зарезервировано для использования в будущем и в настоящее время в общем случае задано равным нулю. Поле Number of List Items (2 байта) задает количество элементов в следующем поле Error Code List. Поле Error Code List (здесь, 8 байтов) представляет собой список, содержащий один или несколько элементов Error Report List Item. Формат одного элемента Error Report List Item показан на фиг.87В.

Согласно одному варианту осуществления и как показано на фиг.87В, каждый элемент Error Report List Item имеет длину ровно 4 байта и структуру согласно одному варианту осуществления, содержащую: 2-байтовое поле Display Error Code, которое указывает тип ошибки, о которой сообщается, 2-байтовое поле Error Sub-code, которое задает более высокий уровень детализации по отношению к ошибке, определенной в пакете Client Error Code. Конкретное определение каждого пакета Client Error Code задается изготовителем клиента. Поле Error Sub-code не обязательно задавать для каждого поля Display Error Code, и в тех случаях, когда поле Error Sub-code не задано, его значение задается равным нулю. Конкретное определение каждого поля Error Sub-code задается изготовителем клиента.

45. Пакет Client Identification

Пакет Client Identification Packet позволяет клиенту возвращать данные идентификации в ответ на пакет Request Specific Status Packet. Согласно одному варианту осуществления клиент указывает возможность передачи пакета Client Identification Packet с использованием значения параметра 144 в поле Valid Parameter Reply List пакета Valid Status Reply List Packet. Для хоста полезно иметь возможность определять имя изготовителя и номер модели устройства-клиента, считывая эти данные с клиента. Информацию можно использовать для определения, имеет ли клиент особые возможности, которые не описаны в пакете Client Capability Packet. Потенциально существуют два метода, средства или механизма для считывания идентификационной информации с клиента. Один из них предусматривает использование пакета Client Capability Packet, который содержит поля, аналогичные полям базовой структуры EDID. Другой метод предусматривает использование пакета Client Identification Packet, который содержит более обширный набор информации по сравнению с аналогичными полями в пакете Client Capability Packet. Это позволяет хосту идентифицировать производителей, которым присвоен 3-символьный код EISA, и допускает серийные номера, содержащие буквенно-цифровые символы.

Формат одного варианта осуществления пакета Client Identification Packet показан в общем виде на фиг.88. Согласно фиг.88 структура пакета Client Identification Packet имеет поля Packet Length, Packet Type, cClient ID, Week of Mfr, Year of Mfr., Length of Mfr Name, Length of Product Name, Length of Serial Number, Manufacturer Name String, Product Name String, Serial Number String и CRC.

2-байтовое поле Packet Type содержит значение, которое идентифицирует пакет как пакет Client Identification Packet. Это значение согласно одному варианту осуществления выбрано равным 144. Поле cClient ID (2 байта) опять же зарезервировано для использования в будущем как ID клиента и в общем случае задано равным нулю. Поле CRC (2 байта) содержит 16-битовый CRC всех байтов в пакете, включая Packet Length.

1-байтовое поле Week of Manufacture содержит значение, указывающее неделю изготовления дисплея. Согласно, по меньшей мере, одному варианту осуществления это значение находится в пределах от 1 до 53, если клиент его поддерживает. Если это поле не поддерживается клиентом, оно обычно задано равным нулю. 1-байтовое поле Year of Manufacture содержит значение, которое указывает год изготовления клиента (дисплея). Это значение является смещением относительно 1990 года, выбранного в качестве точки отсчета, хотя можно использовать и другие базовые года. В этом поле можно выразить года в диапазоне от 1991 до 2245. Пример: год 2003 соответствует значению поля Year of Manufacture, равному 13. Если это поле не поддерживается клиентом, то оно должно быть задано равным нулю.

Каждое из полей Length of Mfr Name, Length of Product Name и Length of Serial Number содержит 2-байтовое значение, которое указывает длину поля Manufacturer Name String, включая любые пустые символы конца строки или заполнения, длину поля Product Name String, включая любые пустые символы конца строки или заполнения и длину поля Serial Number String, включая любые пустые символы конца строки или заполнения, соответственно.

Каждое из полей Manufacturer Name String, Product Name String и Serial Number String содержит переменное количество байтов, указанное в поле Length of Mfr Name, Length of Product Name и Length of Serial Number соответственно, которые представляют собой строки ASCII, указывающие имя изготовителя, название изделия и буквенно-цифровой серийный номер дисплея соответственно. Каждая из этих строк заканчивается, по меньшей мере, одним пустым символом.

46. Пакет Alternate Display Capability

Пакет Alternate Display Capability Packet указывает возможность альтернативных дисплеев, подключенных к контроллеру клиента MDDI. Он передается в ответ на пакет Request Specific Status Packet. По запросу устройство-клиент передает пакет Alternate Display Capability Packet для каждого альтернативного дисплея, который он поддерживает. Клиент может указать возможность передачи пакета Alternate Display Capability Packet посредством значения 145 параметра в поле Valid Parameter Reply List пакета Valid Status Reply List Packet.

Для систем MDDI, работающих во внутреннем режиме, может быть обычным делом наличие более одного дисплея, подключенного к контроллеру клиента MDDI. Иллюстративным вариантом применения является мобильный телефон с большим дисплеем на внутренней стороны крышки и малым дисплеем на внешней стороне. Клиент, работающий во внутреннем режиме, не обязан возвращать пакет Alternate Display Capability Packet по двум возможным причинам. Во-первых, хост уже может быть запрограммирован или иначе проинформирован о возможностях в процессе изготовления, поскольку они используются в общем устройстве или корпусе. Во-вторых, вследствие их интеграции клиент непросто отключить или отсоединить от хоста, и хост может содержать зашитую копию возможностей клиента или, по меньшей мере, знать, что они не изменяются при изменении клиента, как могло бы произойти в другом случае.

Поле Number of Alt Displays пакета Client Capability Packet используется для сообщения о подключении более одного дисплея, и пакет Alternate Display Capability Packet сообщает о возможностях каждого альтернативного дисплея. Пакет видеопотока содержит 4 бита в поле Pixel Data Attributes для обращения к каждому альтернативному дисплею в устройстве-клиенте.

Формат одного варианта осуществления пакета Alternate Display Capability Packet показан в общем виде на фиг.89. Согласно фиг.89 структура пакета Alternate Display Capability Packet имеет поляPacket Length, Packet Type, cClient ID, Alt Display Number, Reserved 1, Bitmap Width, Bitmap Height, Окно дисплея Width, Окно дисплея Height, Color Map RGB Width, RGB Capability, Monochrome Cpability, Reserved 2, Y Cb Cr Capability, Display Feature Capability, Reserved 3 и CRC. Значение 145 поля Packet Type идентифицирует пакет как пакет Alternate Display Capability Packet. Поле cClient ID зарезервировано для ID клиента для использования в будущем и в общем случае задано равным нулю.

Поле Alt Display Number использует 1 байт для идентификации альтернативного дисплея посредством целого числа в диапазоне от 0 до 15. Первый альтернативный дисплей обычно обозначается номером 0, а другие альтернативные дисплеи идентифицируются уникальными значениями поля Alt Display Number большей величины, вплоть до полного количества альтернативных дисплеев минус 1. Значения, превышающие полное количество альтернативных дисплеев минус 1, не используются. Пример: мобильный телефон, имеющий главный дисплей и дисплей идентификации звонящего, подключенные к клиенту MDDI, имеет один альтернативный дисплей, поэтому значение поля Alt Display Number для дисплея идентификации звонящего равно нулю, и поле Number of Alt Displays пакета Client Capability Packet имеет значение 1.

Поле Reserved 1 (1 байт) зарезервировано для использования в будущем. Все биты в этом поле заданы равными нулю. Одной целью этого поля является выравнивание всех последующих 2-байтовых полей с 16-битовым словом адреса и выравнивание 4-байтовых полей с 32-битовым словом адреса.

Поле Bitmap Width использует 2 байта, которые указывают ширину титульной битовой карты, выраженную числом пикселей. Поле Bitmap Height использует 2 байта, которые указывают высоту битовой карты, выраженную числом пикселей. Поле Display Window Width использует 2 байта, которые указывают ширину окна дисплея, выраженную числом пикселей. Поле Display Window Height использует 2 байта, которые указывают высоту окна дисплея, выраженную числом пикселей.

Поле Color Map RGB Width использует 2 байта, которые указывают число битов красного, зеленого и синего цветовых компонентов, которые могут отображаться в режиме отображения карты цветов (палитры). Можно использовать максимум 8 битов для каждого цветового компонента (красного, зеленого, синего). Хотя в пакете Color Map Packet передается 8 битов для каждого цветового компонента, используются только несколько младших битов каждого цветового компонента, заданного в этом поле. Если дисплей-клиент использует формат карты цветов (палитры), то это значение равно нулю. Слово Color Map RGB Width состоит из трех отдельных беззнаковых значений:

Биты с 3-го по 0-й задают максимальное число битов синего цвета в каждом пикселе, причем действительными считаются значения от 0 до 8. Биты с 7-го по 4-й задают максимальное число битов зеленого цвета в каждом пикселе, причем действительными считаются значения от 0 до 8. Биты с 11-го по 8-й задают максимальное число битов красного цвета в каждом пикселе, причем действительными считаются значения от 0 до 8. Биты с 14-го по 12-й зарезервированы для использования в будущем и обычно заданы равными нулю. Бит 15 используется для указания возможности клиента принимать пиксельные данные карты цветов в упакованном или неупакованном формате. Когда бит 15 установлен на уровень логической единицы, это указывает, что клиент может принимать данные карты цветов в упакованном или неупакованном формате. Если бит 15 установлен на уровень логического нуля, это указывает, что клиент может принимать данные карты цветов только в неупакованном формате.

Поле RGB Capability использует 2 байта для задания числа битов разрешения, которое может отображаться в формате RGB. Согласно одному варианту осуществления, если клиент не может использовать формат RGB, то это значение задано равным нулю. Слово RGB Capability состоит из трех отдельных беззнаковых значений: биты с 3-го по 0-й задают максимальное число битов синего цвета (интенсивность синего цвета) в каждом пикселе, биты с 7-го по 4-й задают максимальное число битов зеленого цвета (интенсивность зеленого цвета) в каждом пикселе и биты с 11-го по 8-й задают максимальное число битов красного цвета (интенсивность красного цвета) в каждом пикселе. Биты с 14-го по 12-й зарезервированы для использования в будущем и заданы равными нулю. Бит 15 используется для указания возможности клиента принимать RGB пиксельные данные в упакованном или неупакованном формате. Когда бит 15 установлен на уровень логической единицы, это указывает, что клиент может принимать пиксельные данные RGB в упакованном или неупакованном формате. Если бит 15 установлен на уровень логического нуля, это указывает, что клиент может принимать пиксельные данные RGB только в неупакованном формате.

1-байтовое поле Monochrome Capability содержит значение или информацию для задания количества битов разрешения, которое может отображаться в монохромном формате. Если клиент не может использовать монохромный формат, то это значение задано равным нулю. Биты с 6-го по 4-й зарезервированы для использования в будущем и обычно заданы равными нулю. Биты с 3-го по 0-й задают максимальное число битов градации серого, которые могут существовать в каждом пикселе. Эти четыре бита позволяют указывать, что каждый пиксель содержит от 1 до 15 битов. Если значение равно нулю, значит, монохромный формат не поддерживается клиентом. Бит 7, будучи задан равным единице, указывает, что клиент может принимать монохромные пиксельные данные в упакованном или неупакованном формате. Если бит 7 задан равным нулю, это указывает, что клиент может принимать монохромные пиксельные данные только в неупакованном формате.

Поле Reserved 2 представляет собой поле шириной в 1 байт, зарезервированное для использования в будущем, и обычно все биты в этом поле установлены на уровень логического нуля. Согласно одному варианту осуществления одной целью этого поля является выравнивание всех последующих 2-байтовых полей с 16-битовым словом адреса и выравнивание 4-байтовых полей с 32-битовым словом адреса.

2-байтовое поле Y Cb Cr Capability задает число битов разрешения, которое может отображаться в формате Y Cb Cr. Если клиент не может использовать формат Y Cb Cr, то это значение равно нулю. Слово Y Cb Cr Capability состоит из трех отдельных беззнаковых значений: биты с 3-го по 0-й задают максимальное число битов, которые указывают выборку Cb, биты с 7-го по 4-й задают максимальное число битов, которые указывают выборку Cr, биты с 11-го по 8-й задают максимальное число битов, которые указывают выборку Y, и биты с 14-го по 12-й зарезервированы для использования в будущем и заданы равными нулю. Бит 15, будучи задан равным единице, указывает, что клиент может принимать пиксельные данные Y Cb Cr в упакованном или неупакованном формате. Если бит 15 задан равным нулю, это указывает, что клиент может принимать пиксельные данные Y Cb Cr только в неупакованном формате.

1-байтовое поле Bayer Capability задает число битов разрешения, группу пикселей и порядок пикселей, которые можно передавать в формате Байера. Если клиент не может использовать the Bayer format, то это значение задано равным нулю. Поле Bayer Capability состоит из следующих значений: биты с 3-го по 0-й задают максимальное число битов интенсивности, которые существуют в каждом пикселе, биты с 5-го по 4-й задают шаблон группы пикселей, который может потребоваться, биты с 8-го по 6-й задают необходимый порядок пикселей, и биты с 14-го по 9-й зарезервированы для использования в будущем и заданы равными нулю. Бит 15, будучи задан равным единице, указывает, что клиент может принимать пиксельные данные Байера в упакованном или неупакованном формате. Если бит 15 равен нулю, это указывает, что клиент может принимать пиксельные данные Байера только в неупакованном формате.

2-байтовое поле CRC содержит 16-битовый CRC всех байтов в пакете, включая Packet Length.

47. Пакет Register Access

Пакет Register Access Packet обеспечивает либо хост, либо клиент средством, механизмом или методом для доступа к регистрам конфигурации и статуса на противоположном конце линии связи MDDI. Эти регистры, вероятно, будут уникальными для каждого дисплея или контроллера устройства. Эти регистры уже существуют во многих дисплеях, для которых требуются конфигурации настройки, режимы работы, и имеют другие полезные и необходимые настройки. Пакет Register Access Packet позволяют хосту или клиенту MDDI или обоим производить запись в регистр и запрашивать чтение регистра с использованием линии связи MDDI. Когда хост или клиент запрашивает чтение регистра, противоположный конец должен ответить, отправив данные регистра в пакете некоторого типа, а также указав, что это данные, считанные из конкретного регистра, с использованием поля Read/Write Info. Пакет Register Access Packet можно использовать для чтения или записи множественных регистров путем задания счетчика регистров более 1. Клиент указывает возможность поддерживать пакет Register Access Packet с использованием бита 22 поля Client Feature Capability пакета Client Capability Packet.

Формат одного варианта осуществления пакета Register Access Packet показан в общем виде на фиг.90. Согласно фиг.90 структура пакета Register Access Packet имеет поля Packet Length, Packet Type, bClient ID, Read/Write Flags, Register Address, Parameter CRC, Register Data List и Register Data CRC. Значение 146 поля Packet Type идентифицирует пакет как пакет Register Access Packet. Поле bClient ID зарезервировано для использования в будущем и в настоящее время в общем случае задано равным нулю.

2-байтовое поле Read/Write Flags задает конкретный пакет либо как пакет записи, либо как пакет чтения, либо как пакет ответа на чтение, и обеспечивает счетчик значений данных.

Биты с 15-го по 14-й действует как поле Read/Write Flags. Если биты [15:14] равны ’00’, то этот пакет содержит данные, подлежащие записи в регистр, адресуемый полем Register Address. Данные, подлежащие записи в конкретные регистры, содержатся в поле Register Data List. Если биты [15:14] равны ’10’, то это запрос данных из одного или более регистров, адресуемых полем Register Address. Если биты [15:14] равны ’11’, то этот пакет содержит данные, которые были запрошены в ответ на пакет Register Access Packet, имеющий биты 15:14 поля Read/Write Flags, заданные равными ’10’. Поле Register Address содержит адрес регистра, соответствующего первому элементу Register Data List Item, и поле Register Data List содержит данные, считанные из адреса или адресов. Если биты [15:14] равны ’01’, это рассматривается как неверное значение, это значение зарезервировано для использования в будущем и не используется.

Биты 13:0 используют 14-битовое беззнаковое целое для задания количества 32-битовых элементов регистровых данных, подлежащих передаче в поле Register Data List. Если биты 15:14 равны ’00’, то биты 13:0 задают количество 32-битовых элементов регистровых данных, подлежащих передаче в поле Register Data List, которые содержатся в поле Register Data List, подлежащих записи в регистры, начиная с регистров, указанных в поле Register Address. Если биты 15:14 равны ’10’, то биты 13:0 задают количество 32-битовых элементов регистровых данных, подлежащих передаче в поле Register Data List, которые принимающее устройство передает на устройство, запрашивающее чтение регистров. Поле Register Data List в этом пакете не содержит элементов и имеет нулевую длину. Если биты 15:14 равны ’11’, то биты 13:0 задают количество 32-битовых элементов регистровых данных, подлежащих передаче в поле Register Data List, которые были считаны из регистров, которые содержатся в поле Register Data List. Биты 15:14 в настоящее время не задают равными ’01’, каковое значение считается неверным, и в ином случае зарезервированы для будущих целей или использования.

Поле Register Address использует 4 байта для указания адреса регистра для записи или чтения. Для адресации регистров, адресация которых менее 32 битов, старшие биты заданы равными нулю.

2-байтовое поле Parameter CRC содержит CRC всех байтов от поля Packet Length до поля Register Address. Если этот контроль CRC не проходит, то весь пакет отбрасывается.

Поле Register Data List содержит список 4-байтовых значений регистровых данных, подлежащих записи в регистры клиента, или значений, считанных из регистров устройства-клиента.

2-байтовое поле Register Data CRC содержит CRC только для поля Register Data List. Если этот контроль CRC не проходит, то поле Register Data все же можно использовать, но счетчик ошибок CRC получает приращение.

D. Пакет CRC

Поля CRC появляются в конце пакетов и иногда после некоторых более критических параметров в пакетах, которые могут иметь поле данных значительного размера и, таким образом, повышенную вероятность ошибки при передаче. В пакетах, имеющих два поля CRC, генератор CRC, когда используется только один, повторно инициализируется после первого CRC, так что вычисления CRC, следующие после длинного поля данных, не зависят от параметров в начале пакета.

Согласно иллюстративному варианту осуществления многочлен, используемый для вычисления CRC, называется CRC-16 или X16+X15+X2+X0. Иллюстративная реализация блока 3600 генерации и проверки CRC, полезная для реализации изобретения, показана на фиг.36. Согласно фиг.36 регистр 3602 CRC инициализируется до значения 0x0001 непосредственно до передачи первого бита пакета, который поступает по линии Tx_MDDI_Data_Before_CRC, затем байты пакета сдвигаются в регистр, начиная с LSB. Заметим, что количества битов регистра на этой фигуре соответствует порядку используемого многочлена, но не битовым позициям, используемым в MDDI. Эффективнее сдвигать регистр CRC в одном направлении, в результате чего бит 15 CRC появляется в битовой позиции 0 поля MDDI CRC, а бит 14 регистра CRC – в битовой позиции 1 поля MDDI CRC и т.д. до битовой позиции 14 MDDI.

Например, если содержимое пакета для пакетов Client Request and Status таково: 0x000c, 0x0046, 0x000, 0x0400, 0x00, 0x00, 0x0000 (или представлено в виде последовательности следующих байтов: 0x0c, 0x00, 0x46, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00), и подается с использованием входов мультиплексоров 3604 и 3606 и логического элемента NAND 3608, результирующий CRC, выводимый по линии Tx_MDDI_Data_With_CRC, равен 0xd9aa (или представлен в виде последовательности 0xaa, 0xd9).

Когда блок 3600 генерации и проверки CRC имеет конфигурацию блока проверки CRC, CRC, поступающий по линии Rx_MDDI_DATA, поступает в мультиплексор 3604 и логический элемент NAND 3608 и побитово сравнивается со значением, найденным в регистре CRC с использованием логического элемента NOR 3610, логического элемента исключающего ИЛИ (XOR) 3612 и логического элемента AND 3614. В случае наличия ошибок на выходе логического элемента AND 3614 CRC получает приращение один раз для каждого пакета, который содержит ошибку CRC, благодаря подключению выхода логического элемента 3614 ко входу регистра 3602. Заметим, что иллюстративная схема, показанная на фиг.36, может выводить более одного сигнала ошибки CRC в данном окне CHECK_CRC_NOW (см. фиг.37В). Поэтому счетчик ошибок CRC в общем случае подсчитывает только первый экземпляр ошибки CRC в каждом интервале, где окно CHECK_CRC_NOW активно. При конфигурации генератора CRC CRC тактируется из регистра CRC во время, совпадающее с концом пакета.

Хронирование входных и выходных сигналов, а также сигналов включения графически проиллюстрировано на фиг.37А и 37В. Генерация CRC и передача пакета данных показаны на фиг.37А посредством состояния (0 или 1) сигналов Gen_Reset, Check_CRC_Now, Generate_CRC_Now и Sending_MDDI_Data, а также сигналов Tx_MDDI_Data_Before_CRC и Tx_MDDI_Data_With_CRC. Прием пакета данных и проверка значения CRC показаны на фиг.37В посредством состояния сигналов Gen_Reset, Check_CRC_Now, Generate_CRC_Now и Sending_MDDI_Data, а также сигналов Rx_MDDI_Data и CRC_Error.

Е. Перегрузка кода ошибки для CRC пакета

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

Для использования согласно одному варианту осуществления была разработана новая техника, в которой часть CRC пакетов используется для передачи информации кода ошибки. Это в общем виде показано на фиг.65. Таким образом, один или несколько кодов ошибки генерируются процессорами или устройствами, манипулирующими передачей данных, которые указывают конкретные заранее определенные ошибки или неполадки, которые могут возникнуть при обработке связи или на линии связи. При возникновении ошибки соответствующий код ошибки генерируется и передается с использованием битов для CRC пакета. Таким образом, значение CRC перегружается или переписывается с нужным кодом ошибки, который можно обнаружить на приемном конце посредством монитора ошибок или блока проверки, который отслеживает значение поля CRC. В случаях, когда код ошибки по некоторой причине совпадает со значением CRC, для предотвращения недоразумения передается дополнение ошибки.

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

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

На фиг.66 показано, что механизм или устройство 6600 перезаписи CRC использует блок или средство 6602 обнаружения ошибки, который может составлять часть другой ранее описанной или известной схемы, обнаруживает наличие или существование ошибок на линии связи или в процессе передачи данных. Генератор или средство генерации 6604 кода ошибки, который может составлять часть другой схемы или использовать такие средства, как поисковые таблицы для сохранения заранее выбранных сообщений об ошибке, генерирует один или несколько кодов ошибки для указания конкретных заранее определенных ошибок или неполадок, обнаруженных при возникновении. Очевидно, что устройства 6602 и 6604 при желании могут быть выполнены в виде единой схемы или устройства или других известных процессоров и элементов.

Показаны компаратор или средство сравнения 6606 значения CRC для проверки совпадения выбранного кода или кодов ошибки с передаваемым значением CRC, в случае когда генератор или средство или устройство генерации дополнительного кода используется для обеспечения дополнения кодов ошибки, чтобы не перепутать с исходным шаблоном или значением CRC и не ввести в заблуждение схему обнаружения и не затруднить ее работу. Затем блок или средство или элемент или устройство 6610 выбора кода ошибки выбирает код или значение ошибки, которое нужно вставить или переписать, или, при необходимости, его соответствующее дополнение. Блок или механизм или средство 6612 перезаписи CRC с кодом ошибки – это устройство, которое принимает поток данных, пакеты и коды, которые нужно вставить, и переписывает соответствующие или надлежащие значения CRC для передачи нужных кодов ошибки на принимающее устройство.

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

Общая обработка механизма перезаписи, показанного на фиг.66, реализуется, как показано более подробно на фиг.67A и 67B. Согласно фиг.67А ошибка, одна или более, обнаруживается на этапе 6702 в данных или процессе связи, и код ошибки выбирается на этапе 6704 для указания этого условия. В то же время или в надлежащий момент значение CRC, подлежащее замене, проверяется на этапе 6706 и сравнивается с нужным кодом ошибки на этапе 6708. Результатом этого сравнения согласно рассмотренному выше является определение, совпадает ли нужный код или другие представительные значения с текущим значением CRC. Если это так, то обработка переходит к этапу 6712, на котором дополнительное или в некоторых случаях другое представительное значение по желанию выбираются в качестве кода для вставки. Если определенно, что коды или значения ошибки подлежат вставке, то на этапах 6710 и 6714 выбирается соответствующий код для вставки. Эти этапы проиллюстрированы для ясности отдельными, но, в общем случае представляют единый выбор на основании результата этапа 6708 принятия решения. Наконец, на этапе 6716 соответствующие значения переписываются в место размещения CRC для передачи с пакетами, являющимися целью процесса.

На стороне приема пакета, как показано на фиг.67В, значения CRC пакетов отслеживаются на этапе 6722. В общем случае значения CRC отслеживаются одним или несколькими процессорами в системе для определения, произошла ли ошибка при передаче данных и нужно ли запросить повторную передачу пакета или пакетов или заблокировать дальнейшие операции и т.д., некоторые из которых рассмотрены выше. В порядке такого мониторинга можно также использовать информацию для сравнения значений с известными или заранее выбранными кодами ошибки или представительными значениями и обнаружения наличия ошибок. Альтернативно можно реализовать процесс обнаружения ошибок и монитор отдельно. Если оказывается, что присутствует код, он извлекается или иначе помечается на этапе 6724 для дальнейшей обработки. На этапе 6726 может производиться определение, является ли он фактическим кодом или дополнением, и в последнем случае используется дополнительный этап 6728 для преобразования значения в нужное значение кода. В любом случае результирующий извлеченный код, дополнение или другие выявленные значения используются для обнаружения, какая ошибка произошла, из переданного кода на этапе 6730.

V. Деактивация линии связи

Линия связи MDDI может быстро входить в неактивное состояние и быстро выходить из неактивного состояния. Эта реактивность позволяет системе или устройству связи часто деактивировать линия связи MDDI для снижения энергопотребления, поскольку ее можно очень быстро вновь активировать. Согласно одному варианту осуществления когда клиент, работающий во внешнем режиме, первый раз выходит из неактивного состояния, он делает это на скорости передачи данных и с хронированием стробирующего импульса, которое согласуется со скоростью 1 Мбит/с, т.е. пара MDDI_Stb должна переключаться с частотой 500 кГц. После того как характеристики клиента выявлены хостом или переданы на хост, хост может активировать линию связи в общем случае на любой скорости от 1 Мбит/с до максимальной скорости, на которой может работать клиент. Клиенты, работающие во внутреннем режиме, могут активироваться на любой скорости, на которой могут работать хост и клиент. Это также в общем случае применимо к случаю, когда клиент, работающий во внутреннем режиме, активируется в первый раз.

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

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

Для ввода в неактивное состояние хост передает 64 периода сигнала MDDI_Stb после CRC пакета Link Shutdown Packet. Хост отключает выход MDDI_Data0 хоста на протяжении от 16 до 56 периодов MDDI_Stb (включая задержки на распространение отключения выхода) после CRC. Хост заканчивает передачу 64 периодов MDDI_Stb после CRC пакета Link Shutdown, прежде чем инициировать последовательность активации. Согласно одному варианту осуществления активизация, инициированная хостом, определяется как активация, при которой хост вынужден ждать, по меньшей мере, 100 нс после того, как MDDI_Data0 достигнет действительного уровня логической единицы, прежде чем запустить импульсы на MDDI_Stb. Согласно одному варианту осуществления клиент ожидает, по меньшей мере, 60 периодов MDDI_Stb после CRC пакета Link Shutdown Packet, прежде чем перевести MDDI_Data0 на уровень логической единицы для попытки активировать хост.

Для “вывода” из неактивного состояния выполняется ряд действий или процессов. Когда клиент, в данном случае дисплей, нуждается в услуге данных или связи от хоста, он переводит линию MDDI_Data0 в состояние логической единицы на время от 70 до 1000 мкс, когда MDDI_Stb неактивна, и поддерживает MDDI_Data0 на уровне логической единицы в течение около 70 периодов MDDI_Stb (в пределах от 60 до 80) после активации MDDI_Stb, хотя при желании можно использовать другие периоды. Затем клиент отключает драйвер MDDI_Data0, переводя его в высокоомное состояние.

Если MDDI_Stb активна во время неактивного состояния, хотя это маловероятно, то клиент может только поддерживать MDDI_Data0 в состоянии логической единицы в течение около 70 периодов MDDI_Stb (в пределах от 60 до 80). Это действие заставляет хост запустить или перезапустить трафик данных на прямой линии связи (208) и опрашивать клиент на предмет его статуса.

Хост должен обнаружить наличие импульса запроса и начинает последовательность запуска, прежде всего переводя MDDI_Stb на уровень логического нуля и MDDI_Data0 на высокий логический уровень на, по меньшей мере, около 100 нс. И затем, переключая MDDI_Stb, продолжать переводить MDDI_Data0 на уровень логической единицы на около 150 периодов MDDI_Stb (в пределах от 140 до 160) и на уровень логического нуля на около 50 периодов MDDI_Stb. Клиент не должен передавать импульс услуги запроса, если он обнаруживает MDDI_Data0 в состоянии логической единицы на протяжении более 80 периодов MDDI_Stb. Если клиент обнаруживал MDDI_Data0 на уровне логической единицы на протяжении от 60 до 80 периодов MDDI_Stb, он начинает поиск интервала, в котором хост переводит MDDI_Data0 на уровень логического нуля на протяжении 50 периодов MDDI_Stb. После того как хост переведет MDDI_Data0 на уровень логического нуля на срок 50 периодов MDDI_Stb, хост начинает передавать пакеты по линии связи. Первым передается пакет Sub-frame Header Packet. Клиент начинает поиск пакета Sub-frame Header Packet после того, как MDDI_Data0 находится на уровне логического нуля в течение 50 периодов MDDI_Stb. Характер выбора времен и допусков интервалов времени, связанных с обработкой деактивации и последовательностью запуска, дополнительно рассмотрен ниже (см. фиг.68А-С ниже).

Хост может инициировать активацию, прежде всего включив MDDI_Stb и одновременно переведя его на уровень логического нуля. MDDI_Stb не следует переводить на уровень логической единицы до вывода импульсов согласно описанному ниже. После того как MDDI_Stb достигнет действительного уровня логического нуля, хост включает MDDI_Data0 и одновременно переводит его на уровень логической единицы. MDDI_Data0 не следует переводить на уровень логического нуля, пока интервал, в течение которого он будет находиться на уровне логического нуля, не достигнет 50 импульсов MDDI_Stb, как описано ниже. Хост должен ждать, по меньшей мере, 100 нс после того, как MDDI_Data0 достигнет действительного уровня логической единицы, прежде чем запустить импульсы на MDDI_Stb. Эта закономерность хронирования имеет место с учетом наихудших задержек включения выхода. По существу это гарантирует, что клиент имеет достаточно времени, чтобы полностью включить свой приемник MDDI_Stb после активации уровнем логической единицы на MDDI_Data0, на который эту линию перевел хост.

Пример этапов обработки для типичного события 3800 запроса клиента на обслуживание без конфликтов проиллюстрирован на фиг.38, где события для удобства иллюстрации помечены буквами A, B, C, D, E, F и G. Процесс начинается в точке А, где хост передает пакет Link Shutdown Packet на устройство-клиент, чтобы проинформировать его о том, что линия связи перейдет в неактивное состояние низкой мощности. На следующем этапе хост входит в неактивное состояние низкой мощности, отключая драйвер MDDI_Data0 и устанавливая драйвер MDDI_Stb на уровень логического нуля, как показано в точке В. MDDI_Data0 переводится на уровень логического нуля посредством высокоомной цепи смещения. По прошествии некоторого периода времени клиент передает на хост импульс запроса услуги, переводя MDDI_Data0 на уровень логической единицы, как показано в точке С. Хост по-прежнему устанавливает уровень логического нуля с использованием высокоомной цепи смещения, но драйвер на клиенте переводит линию на уровень логической единицы. В течение 50 мкс хост распознает импульс запроса услуги и устанавливает уровень логической единицы на MDDI_Data0, включая ее драйвер, как показано в точке D. Затем клиент прекращает попытки выдавать импульс запроса услуги, и клиент переводит свой драйвер в высокоомное состояние, как показано в точке Е. Хост переводит MDDI_Data0 на уровень логического нуля на 50 мкс, как показано в точке F, а также начинает генерировать MDDI_Stb в соответствии с уровнем логического нуля на MDDI_Data0. Клиент начинает поиск пакета Sub-frame Header Packet после того, как MDDI_Data0 находился в состоянии логического нуля в течение 40 периодов MDDI_Stb. После установления MDDI_Data0 на уровень логического нуля и возбуждения MDDI_Stb в течение 50 мкс хост начинает передавать данные по прямой линии связи, передавая пакет Sub-frame Header Packet, как показано в точке G.

Аналогичный пример проиллюстрирован на фиг.39, где запрос услуги выдается после начала последовательности перезапуска линии связи и события снова помечены буквами A, B, C, D, E, F, и G. Здесь представлен наихудший сценарий, когда импульс или сигнал запроса от клиента поступает ближе всего, что повреждает пакет Sub-frame Header Packet. Процесс начинается в точке А, где хост опять же передает пакет Link Shutdown Packet на устройство-клиент, чтобы проинформировать его о том, что линия связи перейдет в неактивное состояние низкой мощности. На следующем этапе хост входит в неактивное состояние низкой мощности, отключая драйвер MDDI_Data0 и устанавливая драйвер MDDI_Stb на уровень логического нуля, как показано в точке В. Как и раньше, MDDI_Data0 переводится на уровень логического нуля посредством высокоомной цепи смещения. По прошествии периода времени хост начинает последовательность перезапуска линии связи, переводя MDDI_Data0 на уровень логической единицы в течение 150 мкс, как показано в точке С. До истечения 50 мкс после начала последовательности перезапуска линии связи дисплей также устанавливает MDDI_Data0 в течение 70 мкс, как показано в точке D. Это происходит потому, что дисплею нужно запросить услугу от хоста и дисплей не понимает, что хост уже начал последовательность перезапуска линии связи. Затем клиент прекращает попытки выдавать импульс запроса услуги и клиент переводит свой драйвер в высокоомное состояние, как показано в точке Е. Хост продолжает переводить MDDI_Data0 на уровень логической единицы. Хост переводит MDDI_Data0 на уровень логического нуля на 50 мкс, как показано в точке F, а также начинает генерировать MDDI_Stb в соответствии с уровнем логического нуля на MDDI_Data0. После установления MDDI_Data0 на уровень логического нуля и возбуждения MDDI_Stb в течение 50 мкс хост начинает передавать данные по прямой линии связи, передавая пакет Sub-frame Header Packet, как показано в точке G.

Из вышеприведенного рассмотрения следует, что согласно предыдущему решению хост проходит через два состояния в порядке последовательности активации. Для первого состояния хост задает сигнал MDDI_Data0 высоким на 150 мкс, а затем задает сигнал MDDI_Data0 низким на 50 мкс, в то же время активируя линию MDDI_Stb, и затем начинает передавать пакеты MDDI. Этот процесс хорошо работает по сравнению с уровнем техники в отношении скоростей передачи данных, достижимых с использованием устройства и способов MDDI. Однако согласно вышесказанному более высокая скорость в отношении сокращенного времени реакции на условия или способности быстрее выбирать следующий этап или процесс – это возможность упрощения обработки или элементов, что всегда необходимо.

Заявители открыли новый подход, отвечающий изобретению, к обработке и хронированию активации, когда хост использует хронирование на основе периода тактового сигнала для переключения сигналов. В этой конфигурации хост начинает переключать MDDI_Stb от 0 до 10 мкс после того, как хост устанавливает сигнал MDDI_Data0 высоким в начале последовательности активации, и не ждет, пока сигнал перейдет на низкий уровень. Во время последовательности активации хост переключает MDDI_Stb, тогда как сигнал MDDI_Data0 всегда остается на уровне логического нуля. Это эффективно устраняет концепцию времени со стороны клиента, и хост меняет прежние периоды в 150 мкс и 50 мкс для первых двух состояний на 150 периодов тактового сигнала и 50 периодов тактового сигнала соответственно.

Теперь хост должен перевести эту линию данных на высокий уровень и в течение 10 периодов тактового сигнала начать передачу стробирующего сигнала, как если бы линия данных была на нулевом уровне. После того как хост поддерживал линию данных на высоком уровне в течение 150 периодов тактового сигнала, хост переводит линию данных на низкий уровень в течение 50 периодов тактового сигнала, продолжая передавать стробирующий сигнал. После того как он завершит оба эти процесса, хост может начать передавать первый пакет заголовка подкадра.

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

Реализация клиента согласно изобретению для вывода из неактивного состояния, инициированного хостом, весьма похожа на случай начальной активации за исключением того, что тактовая частота не задается первоначально равной 1 Мбит/с, как рассмотрено ранее. Вместо этого тактовая частота может быть задана так, чтобы возвратиться к любой предыдущей частоте, которая имела место при переходе линии связи в неактивное состояние. Если хост начинает передачу стробирующего сигнала, как описано выше, то клиент должен иметь возможность вновь отсчитать, по меньшей мере, 150 периодов тактового сигнала подряд на линии данных, находящейся на высоком уровне, а затем, по меньшей мере, 150 периодов тактового сигнала подряд на линии данных, находящейся на низком уровне. Когда эти два условия выполнены, клиент может начать поиск уникального слова.

Реализация клиента согласно изобретению для вывода из неактивного состояния, инициированного клиентом, аналогична активации, инициированной хостом, за исключением того, что она начинается с возбуждения линии данных клиентом. Клиент может асинхронно возбуждать линию данных без тактового сигнала для активации хоста. Когда хост обнаруживает, что клиент перевел линию данных на высокий уровень, он может начать свою последовательность активации. Клиент может отсчитать количество периодов тактового сигнала, генерируемых хостом с начала или в ходе его процесса активации. Отсчитав 70 периодов тактового сигнала подряд, в течение которых данные находятся на высоком уровне, клиент может перестать поддерживать линию данных на высоком уровне. В этот момент хост, в свою очередь, должен перевести линию данных на высокий уровень. Затем клиент отсчитать еще 80 периодов тактового сигнала подряд на линии данных, находящейся на высоком уровне, чтобы достигнуть 150 периодов тактового сигнала, в течение которых линия данных находится на высоком уровне, а затем искать 50 периодов тактового сигнала, в течение которых линия данных находится на низком уровне. Когда эти три условия выполнены, клиент может начать поиск уникального слова.

Преимущество этой новой реализации обработки активации состоит в том, что она устраняет необходимость в устройстве измерения времени. Клиент больше не нуждается ни в каких внешних устройствах, будь то генератор или емкостная цепь, для определения условий запуска. Это позволяет сэкономить деньги и площадь схемы при реализации контроллеров, счетчиков и т.д. на плате устройства-клиента. Хотя это может не быть столь выгодно для клиента, но для хоста этот подход также обеспечивает возможность упрощения за счет использования логики очень высокой плотности (VHDL) для основной схемы. Энергопотребление вследствие использования линий данных и стробирующего сигнала в качестве источника извещения активации и измерения также будет снижено, поскольку для основных элементов, ожидающих активации, инициированной хостом, не потребуется работы никаких внешних схем. Используемое количество периодов тактового сигнала является иллюстративным, и можно использовать другие количества периодов, что очевидно специалистам в данной области.

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

Для пояснения и иллюстрации действия этой новой техники хронирование MDDI_Data0, MDDI_Stb и различных операций относительно периодов тактового сигнала показаны на фиг.68A, 68B и 68C.

Пример этапов обработки для типичной активизации, инициированной хостом, без конфликтов проиллюстрирован на фиг.68А, где события, опять же для удобства иллюстрации, помечены буквами A, B, C, D, E, F и G. Процесс начинается в точке А, где хост передает пакет Link Shutdown Packet на устройство-клиент, чтобы проинформировать его о том, что линия связи перейдет в неактивное состояние низкой мощности. На следующем этапе, в точке В, хост переключает MDDI_Stb в течение примерно 64 периодов (или в соответствии с конструкцией системы), чтобы клиент мог завершить обработку до остановки переключения MDDI_Stb, что останавливает восстановленный тактовый сигнал на устройстве-клиенте. Хост также сначала обычно устанавливает MDDI_Data0 на уровень логического нуля, а затем отключает выход MDDI_Data0 в пределах от 16 до 48 периодов (обычно, включая задержки на распространение отключения выхода) после CRC. Может быть желательно перевести высокоскоростные приемники для MDDI_Data0 и MDDI_Stb на клиенте в состояние низкой мощности через некоторое время по истечении 48 периодов после CRC и до следующей стадии (С). Клиент переводит свои высокоскоростные приемники для MDDI_Data0 и MDDI_Stb в неактивное состояние в любое время после нарастающего фронта 48-го периода MDDI_Stb после поля CRC пакета Link Shutdown Packet. Рекомендуется, чтобы клиент переводил свои высокоскоростные приемники для MDDI_Data0 и MDDI_Stb в неактивное состояние до нарастающего фронта 64-го периода MDDI_Stb после поля CRC пакета Link Shutdown Packet.

Хост входит в неактивное состояние низкой мощности в точке или на этапе С, отключая драйверы MDDI_Data0 и MDDI_Stb и переводя контроллер хоста в неактивное состояние низкой мощности. Также можно, по желанию, установить драйвер MDDI_Stb на уровень логического нуля (используя высокоомную цепь смещения) или продолжить переключение в неактивном состоянии. Клиент также находится в неактивном состоянии с низким уровнем мощности.

Спустя некоторый период времени хост начинает последовательность перезапуска линии связи в точке D, включая выход драйверов MDDI_Data0 и MDDI_Stb. Хост устанавливает MDDI_Data0 на уровень логической единицы и MDDI_Stb на уровень логического нуля на столько времени, сколько необходимо драйверам для полного разблокирования своих соответствующих выходов. Хост обычно ожидает около 200 наносекунд после того, как эти выходы достигнут нужных логических уровней, прежде чем запустить импульсы на MDDI_Stb. Это дает клиенту время на подготовку к приему.

Когда драйверы хоста включены и MDDI_Data0 установлена на уровень логической единицы, хост начинает переключать MDDI_Stb в течение 150 периодов MDDI_Stb, как показано в точке Е. Хост переводит MDDI_Data0 на уровень логического нуля в течение 50 периодов, как показано в точке F, и клиент начинает искать пакет Sub-frame Header Packet после того, как MDDI_Data0 находится на уровень логического нуля в течение 40 периодов MDDI_Stb. Хост начинает передавать данные по прямой линии связи, передавая пакет Sub-frame Header Packet, как показано в точке G.

Пример этапов обработки для типичной активизации, инициированной клиентом, без конфликтов проиллюстрирован на фиг.68В, где события, опять же для удобства иллюстрации, помечены буквами A, B, C, D, E, F, G, H и I. Как и прежде, процесс начинается в точке А, где хост передает пакет Link Shutdown Packet, чтобы информировать клиента о том, что линия связи будет переведена в состояние низкой мощности.

В точке В хост переключает MDDI_Stb в течение примерно 64 периодов (или в соответствии с конструкцией системы), чтобы клиент мог завершить обработку до остановки переключения MDDI_Stb, что останавливает восстановленный тактовый сигнал на устройстве-клиенте. Хост также сначала обычно устанавливает MDDI_Data0 на уровень логического нуля, а затем отключает выход MDDI_Data0 в пределах от 16 до 48 периодов (обычно включая задержки на распространение отключения выхода) после CRC. Может быть желательно перевести высокоскоростные приемники для MDDI_Data0 и MDDI_Stb на клиенте в состояние низкой мощности через некоторое время по истечении 48 периодов после CRC и до следующей стадии (С).

Хост входит в неактивное состояние низкой мощности в точке или на этапе С, отключая драйверы MDDI_Data0 и MDDI_Stb и переводя контроллер хоста в неактивное состояние низкой мощности. Также можно по желанию установить драйвер MDDI_Stb на уровень логического нуля (используя высокоомную цепь смещения) или продолжить переключение в неактивном состоянии. Клиент также находится в неактивном состоянии с низким уровнем мощности.

Спустя некоторый период времени клиент начинает последовательность перезапуска линии связи в точке D, включая приемник MDDI_Stb, а также разрешая смещение на приемнике MDDI_Stb, чтобы гарантировать, что состояние принятого варианта MDDI_Stb является уровнем логического нуля на клиенте, до того как клиент включит свой драйвер MDDI_Stb. Для клиента может быть желательно разрешать смещение немного до включения приемника, чтобы гарантировать прием правильного дифференциального сигнала и подавление ошибочных сигналов по желанию. Клиент включает драйвер MDDI_Data0, в то же время переводя линию MDDI_Data0 на уровень логической единицы. Допустимо одновременное включение MDDI_Data0 и MDDI_Stb, если время на разрешение смещения и включение стандартного дифференциального приемника MDDI_Stb меньше 100 нс.

В течение около 1 мс, точка Е, хост распознает импульс запроса услуги от клиента, и хост начинает последовательность перезапуска линии связи, путем разблокировки выходов драйверов MDDI_Data0 и MDDI_Stb. Хост устанавливает MDDI_Data0 на уровень логической единицы и MDDI_Stb на уровень логического нуля на столько времени, сколько необходимо драйверам для разблокирования своих соответствующих выходов. Хост обычно ожидает около 200 наносекунд после того, как эти выходы достигнут нужных логических уровней, прежде чем запустить импульсы на MDDI_Stb. Это дает клиенту время на подготовку к приему.

Когда драйверы хоста включены и MDDI_Data0 установлена на уровень логической единицы, хост начинает выдавать импульсы на MDDI_Stb в течение 150 периодов MDDI_Stb, как показано в точке F. Когда клиент распознает первый импульс на MDDI_Stb, он запрещает смещение на приемнике MDDI_Stb. Клиент продолжает поддерживать MDDI_Data0 на уровне логической единицы в течение 70 периодов MDDI_Stb и отключает свой драйвер MDDI_Data0 в точке G. Хост продолжает поддерживать MDDI_Data0 на уровне логической единицы в течение 80 дополнительных импульсов MDDI_Stb, а в точке Н переводит MDDI_Data0 на уровень логического нуля.

Как показано в точках G и H, хост переведет MDDI_Data0 на уровень логического нуля в течение 50 периодов, и клиент начинает искать пакет Sub-frame Header Packet после того, как MDDI_Data0 находится на уровень логического нуля в течение 40 периодов MDDI_Stb. После удержания MDDI_Stb течение 40 периодов хост начинает передавать данные по прямой линии связи, передавая пакет Sub-frame Header Packet, как показано в точке I.

Пример этапов обработки для типичной активизации, инициированной хостом, с конфликтами с клиентом, т.е. когда клиент тоже хочет активировать линию связи, проиллюстрирован на фиг.68С. События, опять же для удобства иллюстрации, помечены буквами A, B, C, D, E, F, G, H и I. Как и прежде, процесс начинается в точке А, где хост передает пакет Link Shutdown Packet, чтобы информировать клиента о том, что линия связи будет переведена в состояние низкой мощности, переходит в точку В, где MDDI_Stb переключается в течение около 64 периодов (или в соответствии с конструкцией системы), чтобы клиент мог завершить обработку, затем к точке С, где хост входит в неактивное состояние низкой мощности, отключая драйверы MDDI_Data0 и MDDI_Stb и переводя контроллер хоста в неактивное состояние низкой мощности. Спустя некоторый период времени хост начинает последовательность перезапуска линии связи в точке D, включая выход драйверов MDDI_Data0 и MDDI_Stb, и начинает переключать MDDI_Stb в течение 150 периодов MDDI_Stb, как показано в точке Е.

Вплоть до 70 периодов MDDI_Stb после точки Е, в данном случае в точке F, клиент еще не распознал, что хост переводит MDDI_Data0 на уровень логической единицы, поэтому клиент также переводит MDDI_Data0 на уровень логической единицы. Это происходит здесь потому, что клиент имеет желание запросить услугу, но не понимает, что хост, с которым он пытается связаться, уже начал последовательность перезапуска линии связи. В точке G клиент прекращает возбуждать MDDI_Data0 и переводит свой драйвер в высокоомное состояние, блокируя его выход. Хост продолжает поддерживать MDDI_Data0 на уровне логической единицы в течение еще 80 периодов.

Хост переводит MDDI_Data0 на уровень логического нуля в течение 50 периодов, как показано в точке Н, и клиент начинает искать пакет Sub-frame Header Packet после того, как MDDI_Data0 находится на уровень логического нуля в течение 40 периодов MDDI_Stb. Хост начинает передавать данные по прямой линии связи, передавая пакет Sub-frame Header Packet, как показано в точке I.

VI. Электрические спецификации интерфейса

В иллюстративных вариантах осуществления данные в формате Non-Return-to-Zero (NRZ) (без возврата к нулю) кодируются с использованием сигнала данных-стробирования или формата DATA-STB, что позволяет внедрять информацию тактового сигнала в сигналы данных и стробирования. Тактовый сигнал восстанавливается без сложной схемы фазовой автоподстройки частоты. Данные переносятся по двусторонней дифференциальной линии связи, обычно реализованной с использованием проводного кабеля, хотя можно использовать и другие проводники, например печатные проводники или элементы переноса, о чем было заявлено раньше. Стробирующий сигнал (STB) передается по односторонней линии связи, возбуждаемой только хостом. Стробирующий сигнал переключает значение (0 или 1) всякий раз в компенсационном состоянии, 0 или 1, которое остается постоянным на Линия данных или сигнале.

Пример того, как последовательность данных, например биты “1110001011” можно передать с использованием кодирования DATA-STB, графически показан на фиг.40. На фиг.40 сигнал DATA 4002 показан на верхней линии временной диаграммы сигнала и сигнал STB 4004 показан на второй линии, причем они синхронизированы (общая точка отсчета). По прошествии времени, когда на линии DATA 4002 (сигнале) происходит изменение состояния, линия STB 4004 (сигнал) сохраняет предыдущее состояние, таким образом, первое состояние ‘1’ сигнала DATA коррелирует с первым состоянием ‘0’ сигнала STB, его начальным значением. Однако если или когда состояние, уровень сигнала DATA не изменяется, сигнал STB переключается в противоположное состояние или ‘1’ в данном примере, как в случае, показанном на фиг.40, где DATA обеспечивает другое значение ‘1’. Таким образом, существует один и только один переход на битовый период между DATA и STB. Поэтому сигнал STB переходит на этот раз к ‘0’, когда сигнал DATA остается на ‘1’, и поддерживает этот уровень или значение, когда сигнал DATA меняет уровень на ‘0’. Когда сигнал DATA остается на ‘1’, сигнал STB переходит в противоположное состояние, в данном пример ‘1’, и т.д., когда сигнал DATA меняет или поддерживает уровни или значения.

После приема этих сигналов над сигналами DATA и STB осуществляется операция исключающее ИЛИ (XOR) для формирования тактового сигнала 4006, который показан в нижней части временной диаграммы для относительного сравнения с сигналами полезных данных и стробирования. Пример схемы, полезной для генерации выходов или сигналов DATA и STB из входных данных на хосте и последующего восстановления или извлечения данных из сигналов DATA и STB на клиенте, показан на фиг.41.

Согласно фиг.41 передающая часть 4100 используется для генерации и передачи исходных сигналов DATA и STB по промежуточному сигнальному каналу 4102, а приемная часть 4120 используется для приема сигналов и восстановления данных. Согласно фиг.41 при передаче данных от хоста на клиент сигнал DATA поступает на два триггерных элемента 4104 и 4106 типа D совместно с тактовым сигналом для переключения триггеров. Затем два выходных сигнала Q триггеров разделяются с образованием дифференциальной пары сигналов MDDI_Data0+, MDDI_Data0- и MDDI_Stb+, MDDI_Stb- соответственно с использованием двух дифференциальных драйверов линии 4108 и 4110 (режим напряжения). Вентиль, схема или логический элемент 4112 исключающее НЕ-ИЛИ (XNOR) с тремя входами принимает сигнал DATA и выходные сигналы обоих триггеров и генерирует выходной сигнал, который обеспечивает ввод данных во второй триггер, который в свою очередь генерирует сигналы MDDI_Stb+, MDDI_Stb-. Для удобства логический элемент XNOR имеет инвертирующий вход, обозначенный кружочком, чтобы указывать, что он эффективно инвертирует выходной сигнал Q триггера, генерирующего стробирующий сигнал.

В приемной части 4120, показанной на фиг.41, сигналы MDDI_Data0+, MDDI_Data0- и MDDI_Stb+, MDDI_Stb- поступают на каждый из двух дифференциальных приемников линии 4122 и 4124, которые генерируют одинарные выходные сигналы из дифференциальных сигналов. Выходные сигналы усилителей поступают на каждый из входов вентиля, схемы или логического элемента 4126 исключающего ИЛИ 4126 с двумя входами, который формирует тактовый сигнал. Тактовый сигнал используется для переключения двух триггеров 4128 и 4130 типа D, которые принимают задержанный вариант сигнала DATA через элемент задержки 4132, причем один из них (4128) генерирует значения ‘0’ данных, а другой (4130) – значения ‘1’ данных. Кроме того, тактовый сигнал независимо выводится из логического элемента XOR. Поскольку информация тактового сигнала распределяется между линиями DATA и STB, переходы между состояниями сигнала не происходят чаще половины тактовой частоты. Поскольку тактовый сигнал воспроизводится с использованием обработки исключающим ИЛИ сигналов DATA и STB, система эффективно выдерживает двойную величину рассинхронизации между входными данными и тактовым сигналом по сравнению со случаем, когда тактовый сигнал передается непосредственно по одной выделенной линии данных.

Пары MDDI_Data, сигналы MDDI_Stb+ и MDDI_Stb- используются в дифференциальном режиме для максимизации устойчивости к негативному влиянию шума. Каждая дифференциальная пара шунтирована характеристическим импедансом кабеля или проводника, используемого для передачи сигналов. В общем случае все шунты находятся на устройстве-клиенте. Это близко к дифференциальному приемнику для прямого трафика (данных, передаваемых с хоста на клиент), но это на возбуждающем конце кабеля или других проводников или элементов переноса для обратного трафика (данных, передаваемых с клиента на хост). Для обратного трафика сигнал возбуждается клиентом, отражается высокоомным приемником на хосте и завершается на клиенте. Это избавляет от необходимости двойного завершения, которое привело бы к увеличению потребления тока. Это также выполняется на скоростях передачи данных, превышающих величину, обратную двусторонней задержке в кабеле. Проводники или сигналы MDDI_Stb+ и MDDI_Stb- возбуждаются только хостом.

Иллюстративная конфигурация элементов, полезных для формирования драйверов, приемников и оконечных нагрузок для передачи сигналов применительно к интерфейсу MDD, отвечающему изобретению, показана на фиг.42. Этот иллюстративный интерфейс использует низковольтное считывание, в данном случае 200 мВ, с колебаниями напряжения питания менее 1 вольта и низким энергопотреблением. Драйвер каждой сигнальной пары имеет дифференциальный выход по току. При приеме пакетов MDDI пары MDDI_Data и MDDI_Stb используют традиционный дифференциальный приемник с пороговым напряжением нуль вольт. В неактивном состоянии выходы драйвера блокируются и шунтирующие резисторы снижают напряжение на каждой сигнальной паре до нуля вольт. В неактивном режиме особый приемник на паре MDDI_Data0 имеет входной порог смещения плюс 125 мВ, вследствие чего приемник линии в неактивном состоянии интерпретирует невозбужденную сигнальную пару как уровень логического нуля.

Иногда хост или клиент одновременно переводят дифференциальную пару на уровень логической единицы или уровень логического нуля, чтобы гарантировать правильный логический уровень на паре при изменении направления переноса данных (от хоста к клиенту или от клиента к хосту). Диапазон выходного напряжения и выходные спецификации по-прежнему согласуются с одновременно возбуждаемыми выходами, установленными на один и тот же логический уровень. В некоторых системах может понадобиться запускать малый ток в шунтированную дифференциальную пару для создания малого напряжения смещения в определенные моменты в неактивном состоянии и при выходе линии связи из неактивного состояния. В таких случаях схемы смещения для разрешенного тока смещения возбуждают уровни тока, обозначаемые следующим образом: I_ESD-and-Rx – ESD-диод и вход дифференциального приемника, обычно I_ESD-and-Rx 1 мкА; I_TX-IN-Z – выход дифференциального драйвера в высокоомном состоянии, обычно I_TX-IN-Z 1 мкА; и I_external-ESD – ток утечки через внешние диоды ESD-защиты, обычно I_external-ESD 3 мкА.

Каждый из этих токов утечки проиллюстрирован на фиг.101. Повышающие и понижающие цепи должны достигать минимального дифференциального напряжения в наихудших условиях утечки, описанных выше, когда все происходит одновременно. Суммарная утечка 4 мкА для внутреннего режима без внешних диодов ESD-защиты и 10 мкА для внешнего режима с внешней ESD-защитой.

Электрические параметры и характеристики дифференциальных драйверов линии и приемников линии описаны в таблице VIII. С функциональной точки зрения, драйвер преобразует логический уровень на входе непосредственно в положительный выходной сигнал и обратное значение на входе в отрицательный выходной сигнал. Задержка от входа до выходов хорошо согласуется с дифференциальной линией, которая возбуждается дифференциально. В большинстве реализаций перепад напряжения на выходах меньше перепада на входе для минимизации энергопотребления и электромагнитного излучения. В таблице VIII приведен минимальный перепад напряжения около 0,5 В. Однако можно использовать и другие значения, что известно специалистам в данной области, и изобретатели предусматривают меньшее значение согласно некоторым вариантам осуществления в зависимости от конструктивных ограничений.

Дифференциальные приемники линии имеют такую же характеристику, как высокоскоростной компаратор напряжения. На фиг.41 вход без кружочка – это положительный вход, а вход с кружочком – отрицательный вход. Выход равен логической единице, если: (Vinput+)-(Vinput-) больше нуля. То же самое можно описать с помощью дифференциального усилителя с очень большим (практически бесконечным) коэффициентом усиления, выход которого обрезан до уровней напряжения логического 0 и логической 1.

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

На фиг.42 показано, что контроллер 4202 хоста и контроллер 4204 клиента или дисплея передают пакеты по линии связи 4206. Контроллер хоста использует последовательность из трех драйверов 4210, 4212 и 4214 для приема сигналов DATA и STB хоста, подлежащих передаче, а также для приема сигналов данных клиента, подлежащих передаче, тогда как клиент использует три драйвера 4230, 4232 и 4234. Драйвер, отвечающий за передачу DATA хоста (4212), использует вход разрешающего сигнала, чтобы разрешать активацию линии связи, только когда передача с хоста на клиент нужна. Поскольку сигнал STB образует часть передачи данных, для драйвера (4212) не используется никакой дополнительный разрешающий сигнал. Входы каждого из приемников клиента для DATA и STB (4132, 4230) имеют импедансы или резисторы 4218 и 4220 оконечной нагрузки, соответственно установленные поперек их. Драйвер 4234 в контроллере клиента используется для подготовки сигналов данных, передаваемых от клиента на хост, причем драйвер 4214 на входной стороне обрабатывает данные.

Особые приемники (драйверы) 4216 и 4236 подключены к линиям DATA и генерируют или используют рассмотренное выше напряжение смещения 125 мВ в порядке рассмотренного в другом месте управления деактивацией. Благодаря смещениям приемники линии в неактивном состоянии интерпретируют невозбужденные сигнальные пары как уровень логического нуля.

Вышеописанные драйверы и импедансы могут быть выполнены в виде дискретных компонентов или в виде части схемного модуля или специализированной интегральной схемы (ASIC), которая действует как более экономичное решение кодера или декодера.

Легко видеть, что питание подается на устройство-клиент или дисплей с устройства-хоста с использованием сигналов, обозначенных как HOST_Pwr и HOST_Gnd, по паре проводников. Часть HOST_Gnd сигнала действует как базовое заземление и путь или сигнал возврата питания для устройства-клиента. Сигнал HOST_Pwr действует как источник питания устройства-клиента, который возбуждается хостом. В иллюстративной реализации для маломощных приложений устройству-клиенту разрешено потреблять до 500 мА. Сигнал HOST_Pwr можно обеспечивать из портативных источников питания, например, но без ограничения батареи или батарейного источника питания литий-ионного типа, размещенного на устройстве-хосте, и может варьироваться от 3,2 до 4,3 вольт относительно HOST_Gnd.

VII. Характеристики хронирования

Этапы и уровни сигналов, применяемые клиентом для обеспечения услуги от хоста и хостом для обеспечения такой услуги, проиллюстрированы на фиг.43. На фиг.43 первая часть иллюстрируемых сигналов демонстрирует перенос пакета Link Shutdown Packet от хоста, после чего линия данных переходит в состояние логического нуля с использованием высокоомной схемы смещения. Никакие данные не передаются дисплеем клиента или хостом, драйвер которого отключен. Последовательность стробирующих импульсов для сигнала MDDI_Stb можно видеть в нижней части, поскольку MDDI_Stb активна на протяжении пакета Link Shutdown Packet. После того как этот пакет заканчивается и логический уровень меняется на нуль, когда хост запускает схему смещения и переводит логический уровень на нуль, сигнальная линия MDDI_Stb также переходит на уровень логического нуля. Это выражает окончание последнего переноса сигнала или услуги от хоста и могло произойти в любой момент в прошлом и включено для демонстрации предыдущего прекращения обслуживания и состояния сигналов до начала обслуживания. При желании такой сигнал можно передавать просто для переустановки линии связи в надлежащее состояние без “известной” предыдущей связи, которую осуществляло это устройство-хост.

Согласно фиг.43, сигнал на выходе клиента первоначально установлен на нулевой логический уровень. Другими словами, выход клиента имеет высокий импеданс и драйвер отключен. При запросе услуги клиент включает свой драйвер и передает запрос услуги на хост в течение периода времени, обозначенного t_service, когда линия переведена на уровень логической единицы. Прежде чем хост обнаружит запрос, проходит или может быть необходимо определенное количество времени, обозначаемое t_host-detect, после чего хост отвечает посредством последовательности запуска линии связи, переводя сигнал на уровень логической единицы. В этот момент клиент отменяет запрос и отключает драйвер запроса услуги, в результате чего выходная линия клиента вновь переходит на уровень логического нуля. В это время сигнал MDDI_Stb находится на уровне логического нуля.

Хост переводит выходные данные хоста на уровень ‘1’ на период времени, обозначенный t_restart-high, после чего хост переводит логический уровень на нуль и активирует MDDI_Stb на период, обозначенный t_restart-low, после чего первый прямой трафик начинается с пакета Sub-Frame Header Packet, а затем передаются пакеты прямого трафика. Сигнал MDDI_Stb активен в течение периода t_restart-low и последующего пакета Sub-Frame Header Packet.

В таблицах VII и VIII показаны репрезентативные времена или периоды обработки для длины различных периодов, рассмотренных выше, и соотношение с иллюстративными минимальной и максимальной скоростями передачи данных, где:

, где Link_Data_Rate – это битовая скорость одной пары данных.

Специалистам в данной области очевидно, что функции отдельных элементов, проиллюстрированных на фиг.41 и 42, общеизвестны, и функции элементов, показанных на фиг.42, подтверждаются временной диаграммой, показанной на фиг.43. Детали, касающиеся ряда оконечных нагрузок и резисторов деактивации, показанных на фиг.42, были опущены на фиг.41, поскольку эта информация не нужна для описания того, как осуществляется кодирование Data-Strobe и восстановление из него тактового сигнала.

В. Прямая линия связи с хронированием Data-Strobe

Характеристики переключения для передачи данных по прямой линии связи с выхода драйвера хоста показана в таблице IX. В таблице IX показаны в табличной форме нужные минимум и максимум в зависимости от типичных времен, когда происходят определенные переходы сигнала. Например, типичная продолжительность времени для перехода от начального значения данных к конечному (выход ‘0’ или ‘1’), переход от Data0 к Data0, обозначенная t_{tdd-(host-output)}, это t_tbit, тогда как минимальное время составляет около t_tbit-0.5 нс, и максимум составляет около t_tbit+0,5 нс. Относительное разнесение между переходами на Data0, других линиях данных (DataX) и линиях стробирующего сигнала (Stb) проиллюстрировано на фиг.44, где показаны переходы от Data0 к Strobe, от Strobe к Strobe, от Strobe к Data0, от Data0 к non-Data0, от non-Data0 к non-Data0, от non-Data0 к Strobe и от Strobe к non-Data0, которые обозначены как t_{tds-(host-output)}, t_{tss-(host-output)}, t_{tsd-(host-output)}, t_{tddx-(host-output)}, t_{tdxdx-(host-output)}, t_{tdxs-(host-output)} и t_{tsdx-(host-output)} соответственно.

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

На фиг.45 и 46 показано наличие задержки, которая может произойти, когда хост отключает или включает драйвер хоста соответственно. В случае когда хост передает определенные пакеты, например Reverse Link Encapsulation Packet или Round Trip Delay Measurement Packet, хост отключает драйвер линии после передачи нужных пакетов, например пакетов Parameter CRC, Strobe Alignment и All Zero, передача которых показана на фиг.45. Однако, как показано на фиг.45, состояние линии не обязательно мгновенно переключается от ‘0’ до нужного более высокого значения, хотя это потенциально достижимо при наличии определенных управляющих или схемных элементов, но занимает период времени, именуемый периодом задержки отключения драйвера хоста, для ответа. Хотя это может происходить практически мгновенно, так что этот период времени равен 0 наносекунд (нс), его легче расширить на некоторый более долгий период в пределах 10 нс, который является желательным максимальным периодом, который имеет место на протяжении периодов пакета Guard Time 1 или Turn Around 1.

Из фиг.46 следует, что изменение уровня сигнала происходит, когда драйвер хоста включается для передачи пакета, например пакета Reverse Link Encapsulation Packet или Round Trip Delay Measurement Packet. При этом после периодов пакета Guard Time 2 или Turn Around 2 драйвер хоста включается и начинает выводить уровень, в данном случае ‘0’, каковое значение достигается в течение периода времени, именуемого периодом Host Driver Enable Delay, что происходит в течение периода Driver Re-enable (повторного включения драйвера), прежде чем будет передан первый пакет.

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

C. Обратная линия связи с хронированием Data-Strobe

Характеристики переключения и соотношения хронирования для сигналов данных и стробирующих сигналов, используемых для передачи данных по обратной линии связи с выхода драйвера клиента, показаны на фиг.47 и 48. Ниже рассмотрены типичные времена для определенных переходов сигналов. На фиг.47 показано соотношение на входе приемника хоста между хронированием передаваемых данных и передними и задними фронтами стробирующих импульсов. То есть тем, что называется временем установления для нарастающего или переднего фронта стробирующих сигналов, t_su-sr и временем установления для спадающего или заднего фронта стробирующих сигналов, t_su-sf. Типичная продолжительность времени для этих периодов установления составляет порядка минимум 8 наносекунд.

На фиг.48 показаны характеристики коммутации и соответствующая задержка на выходе клиента, обусловленная обратным хронированием данных. Из фиг.48 следует соотношение между хронированием передаваемых данных и передними и задними фронтами стробирующих импульсов с учетом привнесенной задержки. То есть тем, что называется задержкой на распространение между нарастающим или передним фронтом стробирующих сигналов и данными (действительными), t_pd-sr, и задержкой на распространение между данными и задним или спадающим фронтом стробирующих сигналов, t_pd-sf. Типичная продолжительность времени для этих периодов задержки на распространение составляет порядка 8 наносекунд.

VIII. Реализация управления линией связи (работа канального контроллера)

А. Процессор пакетов конечного автомата

Пакеты, передаваемые по линии связи MDDI, диспетчеризуются очень быстро, обычно с скоростью порядка 300 Мбит/с или более, например 400 Мбит/с, хотя при желании можно, конечно, работать на более низких скоростях. Скорость этого типа шины или линии связи слишком велика для того, чтобы коммерчески доступные в настоящее время (экономических) микропроцессоры общего назначения и т.п. могли управлять ею. Поэтому практическая реализация для осуществления этого типа переноса сигнала предусматривает использование программируемого конечного автомата для анализа входного потока пакетов с целью формирования пакетов, переносимых или перенаправляемых в соответствующую аудиовизуальную подсистему, для которой они предназначены. Такие устройства общеизвестны и используют схемы, в целом предназначенные для ограниченного количества операций, функций или состояний для обеспечения работы на нужной высокой или очень высокой скорости.

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

Функцию процессора общего назначения можно реализовать согласно некоторым вариантам осуществления, используя мощность обработки или дополнительные циклы, доступные для микропроцессоров (ЦП), применительно к компьютеру, или контроллеров, процессоров, цифровых сигнальных процессоров (ЦСП), специализированных схем или ASIC, применительно к беспроводным устройствам, во многом таким же образом, как некоторые модемы или графические процессоры используют мощность обработки ЦП, находящихся в компьютерах, для осуществления некоторых функций и уменьшения сложности оборудования и стоимости. Однако это совместное использование циклов может негативно сказываться на скорости обработки, хронировании или работе в целом таких элементов, поэтому во многих вариантах применения для этой общей обработки предпочтительны специализированные схемы или элементы.

Чтобы данные изображения можно было наблюдать на дисплее (микродисплее) или чтобы можно было надежно принимать все пакеты, передаваемые устройством-хостом, обработка сигналов клиента синхронизируется с хронированием каналов прямой линии связи. То есть сигналы, поступающие на клиент и схемы клиента, должны быть, по существу, синхронизированы по времени для правильной обработки сигналов. Высокоуровневая диаграмма состояний сигнала согласно одному варианту осуществления представлена на фиг.49. На фиг.49 показано, что возможная синхронизация “состояний” конечного автомата 4900 на прямой линии связи показана в виде одного состояния ASYNC FRAMES 4904, двух состояний ACQUIRING SYNC 4902 и 4906 и трех состояний IN-SYNC 4908, 4910 и 4912.

Как показано на начальном этапе или состоянии 4902, дисплей или клиент, например устройство представления, начинает с заранее выбранного состояния “NO SYNC” (отсутствия синхронизации) и ищет уникальное слово в первом обнаруженном пакете заголовка подкадра. Заметим, что это состояние отсутствия синхронизации представляет настройку минимальной связи или настройку “fall-back”, в которой выбран интерфейс 1 типа. После отыскания уникального слова в результате поиска клиент сохраняет поле длины подкадра. При обработке этого первого кадра или до получения синхронизации не производится проверки битов CRC. Если длина этого подкадра равна нулю, то обработка состояния синхронизации переходит соответственно в состояние 4904, обозначенное как состояние “async frames” (асинхронные кадры), которое указывает, что синхронизация еще не достигнута. Этот этап обработки помечен на фиг.49 как имеющий предъявленное условие 3. В противном случае, если длина кадра больше нуля, то обработка состояния синхронизации переходит в состояние 4906, где состояние интерфейса задано как “found one sync frame” (найден один синхронный кадр). Этот этап обработки помечен на фиг.49 как имеющий предъявление условия 5. Кроме того, если конечный автомат видит пакет заголовка кадра и определение хорошего CRC для длины кадра, большей нуля, то обработка переходит в состояние “found one sync frame”. Это помечено на фиг.46 как выполнение условия 6.

В каждом случае, когда система находится в состоянии, отличном от “NO SYNC”, при обнаружении пакета с хорошим результатом CRC состояние интерфейса меняется на состояние “IN-SYNC” (синхронизации) 4908. Этот этап обработки помечен на фиг.49 как имеющий предъявленное условие 1. Если же CRC в любом пакете неверен, то обработка состояния синхронизации переходит или возвращается к состоянию интерфейса 4902, т.е. состоянию “NO SYNC FRAME” (отсутствия синхронных кадров). Эта часть обработки помечена на диаграмме состояний фиг.49 как предъявление условия 2.

В. Время вхождения в синхронизм

Интерфейс может быть приспособлен учитывать определенное количество “ошибок синхронизации”, прежде чем решать, что синхронизация потеряна и возвращаться в состояние “NO SYNC FRAME”. На фиг.49 после того как конечный автомат перешел в состояние “IN-SYNC STATE” и никаких ошибок не обнаружено, он постоянно получает результат условия 1 и остается в состоянии “IN-SYNC”. Однако после обнаружения результата условия 2 обработка меняет состояние на состояние 4910 “one-sync-error” (одна ошибка синхронизации). При этом если обработка приводит к обнаружению еще одного результата условия 1, то конечный автомат возвращается в состояние “IN-SYNC” (синхронизация), в противном случае он получает еще один результат условия 2 и переходит в состояние “TWO-SYNC-ERRORS” (две ошибки синхронизации) 4912. Опять же, при наступлении условия 1 обработка возвращает конечный автомат в состояние “IN-SYNC”. В противном случае возникает еще одно условие 2 и конечный автомат возвращается в состояние “NO-SYNC”. Также понятно, что, если интерфейс получает “пакет блокировки линии связи”, это приводит к прекращению передачи данных на линии связи и возврату в состояние “NO-SYNC FRAME” (отсутствие синхронных кадров), поскольку синхронизировать нечего, что обозначается на диаграмме состояний фиг.49 как выполнение условия 4.

Очевидно, возможно существование повторяющейся “ложной копии” уникального слова, которая может появляться в некотором фиксированном положении в подкадре. В таком случае весьма маловероятно, что конечный автомат будет синхронизироваться с подкадром, поскольку CRC в пакете заголовка подкадра также будет верным при обработке, с целью перехода обработки интерфейса MDD в состояние “IN SYNC”.

Длина подкадра в пакете заголовка подкадра может быть задана равной нулю для указания, что хост передаст только один подкадр до блокировки линии связи, и интерфейс MDD помещается или конфигурируется в ждущее неактивное состояние. В этом случае клиент может сразу же принимать пакеты по прямой линии связи после обнаружения пакета заголовка подкадра, поскольку только один подкадр передается до перехода линии связи в ждущее состояние, в обычных или типичных операциях длина подкадра не равна нулю и клиент обрабатывает только пакеты прямой линии связи, тогда как интерфейс в этих состояниях, в целом, показан в виде состояний “IN-SYNC” на фиг.49.

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

С. Инициализация

Согласно вышеописанному во время “запуска”, хост настраивает прямую линию связи на работу на необходимой или желательной минимальной скорости передачи данных 1 Мбит/с или ниже и настраивает длину подкадра и частоту медиакадров в соответствии с данным приложением. Таким образом, прямая и обратная линии связи начинают работать с использованием интерфейса 1 типа. Эти параметры обычно предполагается использовать временно, пока хост определяет возможности или желаемую конфигурацию дисплея клиента (или устройства-клиента другого типа). Хост посылает или передает пакет заголовка подкадра по прямой линии связи, после чего следует пакет Reverse Link Encapsulation Packet (пакет инкапсуляции обратной линии связи), в котором бит ‘0’ поля Request Flags имеет значение единица (1), для запроса, чтобы дисплей или клиент передал в ответ пакет Client Capability Packet. После того как дисплей войдет в синхронизм на прямой линии связи (или с ней), он передает пакеты Client Capability Packet и Client Request and Status Packet по обратной линии связи или каналу.

Хост проверяет содержимое пакета Client Capability Packet, чтобы определить, как перенастроить линию связи для оптимального или желаемого уровня производительности. Хост проверяет поля Protocol Version и Minimum Protocol Version для подтверждения, что хост и клиент используют совместимые друг с другом версии протокола. Версии протокола обычно остаются как первые два параметра пакета возможностей клиента, что позволяет определить совместимость даже, когда другие элементы протокола могут быть несовместимыми или считаться не полностью совместимыми.

D. Обработка CRC

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

Е. Альтернативная проверка потери синхронизации

В то время как вышеописанная совокупность этапов или состояний призвана обеспечивать повышенные скорости передачи данных или пропускную способность, Заявители обнаружили, что альтернативная конфигурация или изменение условий, которые клиент использует, чтобы объявить о потере синхронизации с хостом, можно эффективно использовать для достижения повышенных скоростей передачи данных или пропускной способности. Новый вариант осуществления имеет такую же основную структуру, но с измененными условиями смены состояний. Дополнительно, реализован новый счетчик, помогающий проверять синхронизацию подкадров. Эти этапы и условия представлены на фиг.63, которая иллюстрирует ряд состояний и условий, полезных для задания операций способа или конечного автомата. Для ясности показаны только области состояний “ACQUIRING-SYNC STATES” и “IN-SYNC STATES”. Кроме того, поскольку результирующие состояния, по существу, одинаковы, как и сам конечный автомат, они имеют такую же нумерацию. Однако условия смены состояний (и операции конечного автомата) несколько отличаются, поэтому они перенумерованы для ясности между двумя фигурами (1, 2, 3, 4, 5 и 6 против 61, 62, 63, 64 и 65), для удобства указания различий. Поскольку состояние ASYNC FRAME здесь не рассматривается, одно состояние (4904) и условие (6) уже не используется на этой фигуре.

Согласно фиг.63 система или клиент (для отображения или представления) начинает с того, что конечный автомат 5000 находится в заранее выбранном состоянии 4902 “NO SYNC”, как на фиг.49. Первая смена состояний для перехода из состояния 4902 отсутствия синхронизации происходит при условии 64, т.е. обнаружении шаблона синхронизации. Предполагая, что CRC заголовка подкадра передается в этом пакете (выполняется условие 61), состояние конечного автомата процессора пакетов может меняться на состояние синхронизации 4908. Ошибка синхронизации, условие 62, вызовет переход конечного автомата в состояние 4910, а второе наступление этого условия – в состояние 4912. Однако было обнаружено, что любой отрицательный результат CRC пакета MDDI приведет к выходу конечного автомата из состояния синхронизации 4908 в состояние 4910 одной ошибки синхронизации. Еще один отрицательный результат CRC пакета MDDI приведет к переходу в состояние 4912 двух ошибок синхронизации. Пакет, декодированный с правильным значением CRC, обуславливает возврат конечного автомата в состояние синхронизации 4908.

Изменение касается использования значения CRC или определения для “каждого” пакета. То есть чтобы конечный автомат просматривал значение CRC для каждого пакета для определения потери синхронизации, а не просто рассматривал пакеты заголовка подкадров. В этой конфигурации или процессе потеря синхронизации не определяется с использованием уникального слова и просто значений CRC заголовков подкадров.

Эта новая реализация интерфейса позволяет линии связи интерфейса MDD быстрее распознавать сбои в синхронизации и, следовательно, быстрее восстанавливать ее.

Чтобы система была более устойчивой, клиент должен также добавлять или применять счетчик подкадров. Затем клиент проверяет наличие уникального слова во время его ожидаемого поступления или появления в сигнале. Если уникальное слово не появилось в надлежащее время, клиент может понять, что произошел сбой синхронизации, быстрее, чем если бы он ожидал несколько(в данном случае) три периода пакета, что продолжительнее длины подкадра. Если проверка наличия уникального слова указывает его отсутствие, иными словами, что хронирование неверно, то клиент может сразу же объявить о потере синхронизации на линии связи и перейти в состояние отсутствия синхронизации. Процесс проверки наличия уникального слова добавляет в уникальное слово условие 65, говорящее о том, что уникальное слово неверно. Если на клиенте ожидается прием пакета подкадра, но этого не происходит, клиент может немедленно перейти в состояние 4902 отсутствия синхронизации, экономя дополнительное время ожидания множественных ошибок синхронизации (условие 62), которое обычно предъявляется при переходе через состояния 4910 и 4912.

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

IX. Обработка пакетов

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

Х. Снижение скорости передачи данных обратной линии связи

Изобретатели обнаружили, что определенные параметры, используемые для канального контроллера хоста, можно регулировать или конфигурировать определенным образом для достижения максимальной или более оптимальной (масштаб) скорости передачи данных обратной линии связи, что очень желательно. Например, в течение времени, используемого для передачи поля Reverse Data Packets пакета Reverse Link Encapsulation Packet, сигнальная пара MDDI_Stb переключается для создания периодического тактового сигнала данных на половине скорости передачи данных на прямой линии связи. Это происходит потому, что канальный контроллер хоста генерирует сигнал MDDI_Stb, который соответствует сигналу MDDI_Data0, как если бы передавались все нули. Сигнал MDDI_Stb передается от хоста на клиент, где он используется для генерации тактового сигнала для передачи данных обратной линии связи от клиента обратно на хост. Иллюстрация типичных величин задержки, возникающих при передаче сигнала и обработке сигнала на прямой и обратной линиях связи в системе с применением MDDI, показана на фиг.50. На фиг.50 ряд значений задержки 1,5 нс, 8,0 нс, 2,5 нс, 2,0 нс, 1,0 нс, 1,5 нс, 8,0 нс и 2,5 нс, показаны вблизи участков обработки для генерации Stb+/-, кабеля для передачи на клиент, приемника клиента, генерации тактового сигнала, тактирования сигнала, генерации Data0+/-, кабеля для передачи на хост и приемных каскадов хоста соответственно.

В зависимости от скорости передачи данных на прямой линии связи и привнесенных задержек обработки сигнала может потребоваться больше времени, чем один период сигнала MDDI_Stb для выполнения этого “двустороннего” эффекта или набора событий, что приводит к потреблению нежелательных количеств времени или периодов. Чтобы избежать этой проблемы, Reverse Rate Divisor позволяет времени одного бита на обратной линии связи охватывать множественные периоды сигнала MDDI_Stb. Это значит, что скорость передачи данных обратной линии связи меньше скорости прямой линии связи.

Заметим, что фактическая длительность задержек сигнала через интерфейс может отличаться в зависимости от каждой конкретной системы хост-клиент или использования оборудования. Хотя это и не требуется, каждая система может быть выполнена так, чтобы работать лучше, благодаря использованию пакета Round Trip Delay Measurement Packet для измерения фактической задержки в системе, что позволяет задавать Reverse Rate Divisor равным оптимальному значению. Хост может поддерживать либо базовую дискретизацию данных, которая проще, но работает на более низкой скорости, либо усовершенствованную дискретизацию данных, которая сложнее, но поддерживает более высокие скорости передачи данных на обратной линии связи. Рассматривается возможность клиента поддерживать оба метода.

Двусторонняя задержка измеряется благодаря тому, что хост передает пакет Round Trip Delay Measurement Packet на клиент. Клиент отвечает на этот пакет, передавая последовательность единиц обратно на хост внутри или в течение заранее выбранного окна измерения в этом пакете, именуемого полем Measurement Period. Хронирование этого измерения было подробно описано выше. Двусторонняя задержка используется для определения частоты, на которой можно безопасно дискретизировать данные обратной линии связи.

Измерение двусторонней задержки состоит в определении, обнаружении или подсчете количества интервалов тактового сигнала данных прямой линии связи, имеющих место между началом поля Measurement Period и началом периода времени, когда ответная последовательность 0xff, 0xff, 0x00 возвращается обратно на хост от клиента. Упомянем возможность того, что ответ клиента может быть принят в течение малой части периода тактового сигнала прямой линии связи до того, как отсчет измерения будет готов к увеличению. Если это неизмененное значение используется для вычисления Reverse Rate Divisor, это может привести к битовым ошибкам на обратной линии связи вследствие ненадежной дискретизации данных. Пример этой ситуации проиллюстрирован на фиг.51, где в графическом виде показаны сигналы, представляющие MDDI_Data на хосте, MDDI_Stb на хосте, тактовая частота данных прямой линии связи в хосте и Delay Count (счетчик задержки). Согласно фиг.51 ответная последовательность была принята от клиента в течение малой части периода тактового сигнала прямой линии связи до того, как Delay Count был готов к увеличению от 6 до 7. Если предположить, что задержка равна 6, то хост будет дискретизировать данные обратной линии связи сразу после битового перехода или, возможно, в середине битового перехода. По этой причине измеренная задержка обычно должна увеличиться на единицу до того, как она будет использована для вычисления Reverse Rate Divisor.

Reverse Rate Divisor – это число периодов MDDI_Stb, в течение которых хост должен ожидать до дискретизации данных обратной линии связи. Поскольку MDDI_Stb периодичны с частотой, равной половине скорости прямой линии связи, скорректированное измерение двусторонней задержки нужно разделить на 2, а затем округлить в большую сторону до следующего целого числа. Это соотношение можно выразить следующей формулой:

В данном примере получается:

Если бы измерение двусторонней задержки, используемое в этом примере, было 7, а не 6, то Reverse Rate Divisor также будет равно 4.

Данные обратной линии связи дискретизируются хостом на нарастающем фронте сигнала Reverse Link Clock. Имеется счетчик или подобная известная схема или устройство, присутствующее на хосте и клиенте (дисплее), для генерации сигнала Reverse Link Clock. Счетчики инициализируются так, чтобы первый нарастающий фронт сигнала Reverse Link Clock приходился на начало первого бита в поле Reverse Link Packets пакета Reverse Link Encapsulation. Это проиллюстрировано для примера, приведенного ниже, на фиг.52. Счетчики получают приращение на каждом нарастающем фронте сигнала MDDI_Stb, и число отсчетов до реверсирования задано параметром Reverse Rate Divisor в пакете Reverse Link Encapsulation Packet. Поскольку сигнал MDDI_Stb переключается на половине скорости прямой линии связи, то скорость обратной линии связи равна половине скорости прямой линии связи, деленной на Reverse Rate Divisor. Например, если скорость прямой линии связи равна 200 Мбит/с и Reverse Rate Divisor равен 4, то скорость передачи данных обратной линии связи выражается следующим образом:

Пример, показывающий хронирование сигнальных линий MDDI_Data0 и MDDI_Stb в пакете Reverse Link Encapsulation Packet, показан на фиг.52, где параметры пакета, используемые для иллюстрации, имеют значения:

Пакетные данные между полями Packet Length и Parameter CRC равны:

0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, 0xdb, 0x00,…

Первый пакет обратной линии связи, возвращенный от клиента – это пакет Client Request and Status Packet, имеющий поле Packet Length = 7 и Packet Type = 70. Этот пакет начинается с байтовых значений 0x07, 0x00, 0x46,…, и т.д. Однако на фиг.52 виден только первый байт (0x07). На фигуре показано, что этот первый пакет обратной линии связи сдвинут по времени примерно на один период тактового сигнала обратной линии связи, чтобы проиллюстрировать фактическую задержку обратной линии связи. Идеальная форма волны с нулевой двусторонней задержкой от хоста к клиенту показана пунктирной линией.

За типом пакета передается поле Parameter CRC, а затем поле всех нулей. Стробирующий сигнал от хоста переключается от единицы к нулю и обратно к единице, когда данные от хоста меняет уровень, образуя более широкие импульсы. Когда данные переходят к нулю, стробирующий сигнал переключается на более высокой скорости, только изменение данных на линии данных вызывает изменение вблизи конца поля выравнивания. Стробирующий сигнал переключается на более высокой скорости на протяжении остатка фигуры вследствие фиксированных уровней 0 или 1 сигнала данных для расширенных периодов времени, и переходы, падающие на шаблоне импульса (фронте).

Тактовый сигнал обратной линии связи для хоста находится на нулевом уровне до конца периода Turn Around 1, когда тактовый сигнал начинается для работы с пакетами обратной линии связи. Стрелки в нижней части фигуры указывают, когда данные дискретизируются, что явствует из остальной части раскрытия. Показано, что первый байт передаваемого поля пакета (в данном случае 11000000) начинается после поля Turn Around 1 и уровень линии стабилизируется после отключения драйвера хоста. Задержка при прохождении первого бита, и, как видно для бита три, показана пунктирными линиями для сигнала данных.

На фиг.53 можно видеть типичные значения Reverse Rate Divisor в зависимости от скорости передачи данных на прямой линии связи. Фактическое значение Reverse Rate Divisor определяется как результат измерения двусторонней линии связи, чтобы гарантировать правильную работу обратной линии связи. Первая область 5302 соответствует области безопасной работы, вторая область 5304 соответствует области пограничной производительности, а третья область 5306 указывает настройки, которые вряд ли обеспечат правильную работу.

Измерение двусторонней задержки и задание Reverse Rate Divisor одинаковы при работе с любыми настройками прямой или обратной линии связи, поскольку они выражаются и используются в единицах фактических периодов тактового сигнала, а не в количествах передаваемых или принимаемых битов.

XI. Времена реверсирования и защиты

Согласно рассмотренному выше поле Turn Around 1 в пакете Reverse Link Encapsulation Packet и поле Guard Time 1 в пакете Round Trip Delay Measurement Packet указывают значения для промежутков времени, в течение которых драйверы интерфейса хоста могут быть отключены до того, как будут включены драйверы интерфейса клиента. Поля Turn Around 2 и Guard Time 2 обеспечивают значения времени, в течение которых драйверы клиента могут быть отключены до того, как будут включены драйверы хоста. Поля Guard Time 1 и Guard Time 2 в общем случае заполнены заранее заданными или заранее выбранными значениями для длительностей, которые не предусматривают регулировки. В зависимости от используемого оборудования интерфейса эти значения могут быть получены с использованием эмпирических данных и, в некоторых случаях регулироваться для улучшения работы.

На определение длины поля Turn Around 1 влияет несколько факторов, а именно скорость передачи данных на прямой линии связи и максимальное время отключения драйверов линии MDDI_Data на хосте. Максимальное время отключения драйвера хоста указано в таблице XI, где показано, что для отключения драйверов требуется около 10 нс, а для их включения требуется около 2 нс. Максимальное количество тактовых импульсов прямой линии связи, необходимое для отключения драйвера хоста, выражается следующим соотношением:

Допустимый диапазон значений поля Turn Around 1 выражается следующим соотношением:

где Interface Type Factor равен 1 для типа 1, 2 для типа 2, 4 для типа 3 и 8 для типа 4.

Объединяя два вышеприведенные уравнения, можно сократить член Interface Type Factor и выразить Turn Around 1 в виде:

Например, прямая линия связи 3 типа со скоростью 1500 Мбит/с будет использовать задержку Turn Around 1, равную

При возрастании двусторонней задержки граница хронирования увеличивается от момента времени, когда отключается хост, до момента времени, когда включается клиент.

Факторы, определяющие продолжительность времени, обычно используемую для Turn Around 2, – это скорость передачи данных на прямой линии связи, максимальное время отключения драйверов MDDI_Data на клиенте и двусторонняя задержка линии связи. Вычисление времени, необходимого для отключения драйвера клиента, по существу, такое же, как рассмотренное выше для драйвера хоста, и задается следующим соотношением:

и допустимый диапазон значений для Turn Around 2 задается как:

Например, прямая линия связи 3 типа со скоростью 1500 Мбит/с и двусторонней задержкой 10 периодов тактового сигнала прямой линии связи использует задержку Turn Around 2 порядка

XII. Альтернативное хронирование обратной линии связи

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

Согласно представленному выше предыдущий подход к хронированию обратной линии связи предусматривает, что количество периодов тактового сигнала подсчитывается от последнего бита поля Guard Time 1 пакета хронирования обратной линии связи до выборки первого бита на нарастающем фронте тактового сигнала ввода/вывода. Это тактовый(е) сигнал(ы), используемые для хронирования входов и выходов интерфейса MDD. Вычисление делителя скорости обратной линии связи производится по формуле:

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

Это обеспечивается за счет того, что хост подсчитывает количество периодов тактового сигнала, пока не будет выбрана единица, но хост дискретизирует линию данных на нарастающем и спадающем фронтах в течение пакета хронирования обратной линии связи. Это позволяет хосту выбирать наиболее полезную или даже оптимальную точку дискретизации в бите обратной линии связи, чтобы гарантировать стабильность бита. То есть чтобы найти наиболее полезный или оптимальный нарастающий фронт для дискретизации данных для пакетов инкапсуляции обратной линии связи обратного трафика. Оптимальная точка дискретизации зависит от делителя обратной линии связи и от того, была ли первая из них обнаружена на нарастающем фронте или спадающем фронте. Новый способ хронирования позволяет хосту просто искать первый фронт шаблона 0xFF 0xFF 0x00, переданного клиентом для хронирования обратной линии связи, чтобы определить, где производить дискретизацию в пакете инкапсуляции обратной линии связи.

Примеры прихода обратного бита и того, как этот бит будет выглядеть для различных делителей скорости обратной линии связи, проиллюстрированы на фиг.64 совместно с количеством периодов тактового сигнала, появившихся после последнего бита поля Guard Time 1. Из фиг.64 следует, что, если первый фронт возникает между нарастающим и спадающим фронтом (помечен как рост/спад), для делителя скорости обратной линии связи, равного единице, оптимальной точкой дискретизации является фронт тактового импульса, помеченный ‘b’, поскольку это единственный нарастающий фронт, возникающий в течение периода бита обратной линии связи. Для делителя скорости обратной линии связи, равного двум, оптимальной точкой дискретизации, вероятно, по-прежнему будет передний фронт ‘b’ тактового импульса, поскольку фронт импульса ‘c’ ближе к фронту бита, чем ‘b’. Для делителя скорости обратной линии связи, равного четырем, оптимальной точкой дискретизации, вероятно, будет фронт ‘d’ тактового импульса, поскольку он ближе к заднему фронту бита обратной линии связи, где значение, вероятно, стабилизировалось.

Если же согласно фиг.64 первый фронт возникает между спадающим и нарастающим фронтом (помеченным как спад/рост), оптимальной точкой дискретизации для делителя скорости обратной линии связи, равного единице, является точка дискретизации фронта ‘a’ тактового импульса, поскольку это единственный нарастающий фронт в битовом периоде времени обратной линии связи. Для делителя скорости обратной линии связи, равного двум, оптимальной точкой дискретизации является фронт ‘b’, и для делителя скорости обратной линии связи, равного четырем, оптимальной точкой дискретизации является фронт ‘c’.

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

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

После того как хост выбрал или определил количество периодов тактового сигнала, он может “исследовать” различные делители скорости обратной линии связи с клиентом для определения, будет ли работать конкретный делитель скорости обратной линии связи. Хост (и клиент) может начать с делителя, равного единице, и проверить CRC пакета статуса обратной линии связи, принятого от клиента, чтобы определить, правильно ли функционирует эта скорость обратной линии связи для передачи данных. Если CRC поврежден, вероятно, имеется ошибка дискретизации, и хост может увеличить делитель скорости обратной линии связи и попытаться снова запросить пакет статуса. Если второй запрошенный пакет поврежден, можно снова делитель увеличить и снова сделать запрос. Если этот пакет декодирован правильно, то этот делитель скорости обратной линии связи можно использовать для всех будущих пакетов обратной линии связи.

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

Похоже, эта реализация лучше работает для данных обратной линии связи типа 1, но может представлять проблемы для данных обратной линии связи типа 2-4 вследствие того, что рассогласование между линиями данных потенциально слишком велика, чтобы линия связи могла работать на скорости, наилучшей для только одной пары данных. Однако скорость передачи данных, вероятно, не нужно снижать до предыдущего способа даже для работы с типами 2-4. Этот способ также может работать наилучшим образом в случае дублирования на каждой линии данных для выбора идеального или оптимального места выборки в тактовом сигнале. Этот метод продолжает работать в случае одного и того же времени выборки для каждой пары данных. При наличии разных периодов дискретизации можно использовать два разных подхода. Первый состоит в выборе желаемого или более оптимизированного места выборки для каждой точки данных, даже если оно не одинаково для каждой пары данных. Затем хост может реконструировать поток данных после выборки всех битов из набора пар данных: два бита для типа 2, четыре бита для типа 3 и восемь битов для типа 4. Другой вариант предусматривает, что хост увеличивает делитель скорости обратной линии связи, в результате чего биты данных для каждой пары данных можно выбирать на одном и том же фронте тактового сигнала.

XIII. Эффекты задержки и рассогласования линии связи

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

А. Анализ хронирования линии связи с ограничением вследствие рассогласования (тип 1 MDDI)

1. Пример задержки и рассогласования линии связи типа 1

Типичная схема интерфейса, аналогичная показанному на фиг.41, показана на фиг.57 для работы на линии связи с интерфейсом 1 типа. На фиг.57 иллюстративные или типичные значения задержки на распространение и рассогласования показаны для каждого нескольких каскадов обработки или интерфейса для MDDI типа 1 прямой линии связи. Рассогласование в задержке между MDDI_Stb и MDDI_Data0 приводит к искажению рабочего цикла выходного тактового сигнала. Данные на входе D триггерного каскада приемника (RXFF), в котором используются триггеры 5728, 5732, мало изменяются после фронта тактового сигнала, что позволяет надежно их дискретизировать. На фигуре показаны два каскада линий задержки 5732a и 5732b, которые используются для разрешения разных проблем путем создания этого временного соотношения. В фактической реализации они могут быть объединены в один элемент задержки.

На фиг.58 показано хронирование восстановления сигналов Data, Stb и Clock на линии связи типа 1 для иллюстративной обработки сигнала через интерфейс.

Полное рассогласование задержки, имеющее значительную величину, получается из суммы рассогласований на следующих каскадах: триггерном каскаде передатчика (TXFF) с триггерами 5704, 5706; драйверном каскаде передатчика (TXDRVR) с драйверами 5708, 5710; кабеле CABLE 5702; каскаде приемников линии приемника (RXRCVR) с приемниками 5722, 5724; и логике XOR приемника (RXXOR). Элемент Delay1 5732a должен обеспечивать задрежку, равную или превышающую задержку вентиля XOR 5736 на каскаде RXXOR, что определено соотношением:

Желательно, чтобы это требование выполнялось, чтобы вход D триггеров 5728, 5732 приемника не изменялся до ввода его тактового сигнала. Это справедливо, если время удержания RXFF равно нулю.

Целью функции Delay2 является компенсация времени удержания триггера RXFF согласно соотношению:

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

Наибольшее рассогласование на каскаде XOR приемника привносится в случае, когда Delay1 имеет максимальное значение и выходной тактовый сигнал вентиля XOR поступает с максимальным опережением согласно соотношению:

В этой ситуации данные могут изменяться между двумя битовыми периодами, n и n+1, очень близко ко времени, когда бит n+1 тактируется в триггер приемника.

Максимальная скорость передачи данных (минимальный битовый период) линии связи MDDI типа 1 является функцией максимального рассогласования, накопленного на всех драйверах, кабеле и приемниках на линии связи MDDI плюс совокупное задание данных в каскад RXFF. Суммарное рассогласование задержки на линии связи до выхода каскада RXRCVR можно выразить как:

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

В примере, показанном на фиг.57 для внешнего режима, t_{SKEW-max(LINK)} = 1000 пс, и минимальный битовый период можно выразить как:

t_BIT-min=1000+2·125+625+125+200+0+100=2300 пс

или задано как приблизительно 434 Мбит/с.

В. Анализ хронирования линии связи для MDDI типа 2, 3 и 4

Типичная схема интерфейса, аналогичная показанной на фиг.41 и 57, показана на фиг.59 для работы на линиях связи с интерфейсом типа 2, 3 и 4. В каскадах TXFF (5904), TXDRVR (5908), RXRCVCR (5922) и RXFF (5932, 5928, 5930) используются дополнительные элементы для обеспечения обработки дополнительных сигналов. На фиг.59 иллюстративные или типичные значения задержки на распространение и рассогласования показаны для каждого нескольких каскадов обработки или интерфейса для MDDI типа 2 прямой линии связи. Помимо рассогласования задержки между MDDI_Stb и MDDI_Data0, влияющей на рабочий цикл выходного тактового сигнала, имеется также рассогласование между обоими из этих двух сигналов и другими сигналами MDDI_Data. Данные на входе D триггерного каскада В приемника (RXFFB), состоящего из триггеров 5928 и 5930, мало изменяются после фронта тактового сигнала, что позволяет надежно их дискретизировать. Если сигнал MDDI_Data1 приходит раньше, чем MDDI_Stb или MDDI_Data0, то MDDI_Data1 нужно задерживать для дискретизации на, по меньшей мере, величину рассогласования задержки. С этой целью данные задерживаются линией задержки Delay3. Если сигнал MDDI_Data1 приходит позже, чем MDDI_Stb и MDDI_Data0 и также задерживается элементом Delay3, то точка, где MDDI_Data1 изменяется, перемещается ближе к следующему фронту тактового сигнала. Это процесс определяет верхний предел скорости передачи данных линии связи MDDI типа 2, 3 или 4. Некоторые иллюстративные различные возможности для соотношения хронирования или рассогласования двух сигналов данных и MDDI_Stb относительно друг друга проиллюстрированы на фиг.60A, 60B и 60C.

Чтобы надежно дискретизировать данные на RXFFB, когда MDDI_DataX приходит с максимальным опережением, задержка Delay3 задается согласно соотношению:

Максимальная скорость линии связи определяется минимально допустимым битовым периодом. Это наиболее критично, когда MDDI_DataX поступает с максимальным отставанием. В этом случае минимально допустимый битовый период задается формулой:

Тогда верхняя граница скорости линии связи будет

и с учетом этой гипотезы:

В вышеприведенном примере нижняя граница минимального битового периода задается соотношением:

t_{BIT-min(lower-bound)} = 2·(1000+2·125+625+200)+1500+100+0 = 5750 пс,

что приблизительно равно 174 Мбит/с.

Это значительно меньше максимальной скорости передачи данных, которая используется на линии связи типа 1. Функция автоматической компенсации рассогласования задержки MDDI значительно уменьшает влияние рассогласования задержки на фактор максимальной скорости линии связи находится непосредственно на фронте правильного задания данных. Калиброванное рассогласование между MDDI_Data0 и MDDI_Stb таково:

и минимальный битовый период таков:

В примере, показанном на фиг.8-5, t_{SKEW-max(Data0-Stb-Calibrated)} = 300 пс и минимальный битовый период:

t_{BIT-min-Calibrated} = 300+2·125+625+200+175+100 = 1650 пс,

что приблизительно 606 Мбит/сек.

Чтобы надежно дискретизировать данные на RXFFB, когда MDDI_Data1 приходит с максимальным опережением, соответствующая программируемая задержка регулируется до оптимальной настройки с точностью одного отвода, и дополнительная задержка отвода добавляется для безопасности. Максимальная скорость линии связи определяется минимально допустимым битовым периодом. Это наиболее критично, когда MDDI_Data1 поступает с максимальным отставанием. В этом случае минимально допустимый битовый период задается формулой:

В примере, приведенном на фиг.8-5, нижняя граница минимального битового периода на основе дискретизации MDDI_Data1 такова:

t_{BIT-min-Data1-Calibrated} = 2·150+2·125 = 550 пс.

XIV. Описание соединений физического уровня

Физические соединения, полезные для реализации интерфейса, отвечающего настоящему изобретению, можно реализовать с использованием коммерчески доступных деталей, например детали под номером 3260-8S2(01) производства Hirose Electric Company Ltd. на стороне хоста и детали под номером 3240-8P-C производства Hirose Electric Company Ltd. на стороне устройства-клиента. Иллюстративная разводка контактов или “цоколевка” для таких соединителей, используемых в интерфейсах типа 1 и 2, приведена в таблице XIII и проиллюстрирована на фиг.61.

Экран подключен к HOST_Gnd в интерфейсе хоста, и провод заземления экрана в кабеле подключен к экрану соединителя клиента. Однако экран и провод заземления не подключены к заземлению схемы внутри клиента.

Соединительные элементы или устройства выбираются или конструируются так, чтобы они были достаточно малы, чтобы их можно было использовать в устройствах мобильной связи и вычислительных устройствах, например КПК и беспроводных телефонах или портативных игровых устройствах, чтобы они не были заметными или неэстетичными по сравнению с относительным размером устройства. Любые соединители и кабели должны быть достаточно долговечными для использования в типичных бытовых условиях и должны иметь малый размер, особенно кабели, и относительно низкую стоимость. Элементы переноса должны иметь возможность работы с данными и стробирующими сигналами, которые являются дифференциальными данными NRZ, имеющими скорость передачи данных до около 450 Мбит/с для типа 1 и типа 2 и до 3,6 Гбит/с для 8-битовой параллельной версии типа 4.

Для применений внутреннего режима либо нет соединителей в смысле используемых проводников либо такие соединительные элементы имеют очень малые размеры. Одним примером является “гнезда” нулевой силы вставки для приема интегральных схем или элементов, заключающих в себе хост или клиент. Другим примером является случай, когда хост и клиент размещается на печатных платах с различными соединительными проводниками и имеет “ножки” или контакты, выступающие из корпусов, которые припаяны к контактам на проводниках для взаимосоединения интегральных схем.

XV. Принцип работы

Сводка общих этапов обработки данных и пакетов в ходе работы интерфейса с использованием вариантов осуществления изобретения показана на фиг.54A и 54B, совместно с обзором устройства интерфейса, обрабатывающего пакеты, на фиг.55. На этих фигурах процесс начинается на этапе 5402 с определения, соединены ли клиент и хост с использованием канала связи, в данном случае кабеля. Это может осуществляться с использованием периодического опроса, выполняемого хостом, с использованием программного обеспечения или оборудования, которое обнаруживает наличие соединителей или кабелей или сигналов на входах хоста (например, как в интерфейсах USB) или другими известными средствами. Если оказывается, что к хосту не подключено ни одного клиента, то он может просто войти в ждущее состояние на некоторый заранее определенный период в зависимости от приложения, перейти в неактивный режим или быть деактивирован для ожидания будущего использования, для чего может потребоваться, чтобы пользователь повторно активировал хост. Например, когда хост находится в устройстве типа компьютера, пользователь может кликнуть по экранной иконке или вызвать программу, которая активирует обработку хоста для поиска клиента. Опять же простое подключение соединителя типа USB может активировать обработку хоста в зависимости от возможности и конфигурации хоста или программного обеспечения, установленного на хосте.

Когда клиент подключен к хосту или наоборот или обнаружено его присутствие, клиент или хост передает соответствующие пакеты, запрашивающие услугу, на этапах 5404 и 5406. Клиент может посылать пакеты Client Service Request или Status на этапе 5404. Заметим, что линия связи согласно рассмотренному выше может быть ранее заблокирована или находиться в неактивном режиме, поэтому далее может не произойти полной инициализации линии связи. Когда линия связи синхронизирована и хост пытается связаться с клиентом, клиент также выдает на хост пакет Client Capabilities на этапе 5408. После этого хост может начать определять тип поддержки, включая скорости передачи данных, адекватный клиенту.

В общем случае хост и клиент могут согласовывать тип (частоту/скорость) режима обслуживания, подлежащего использованию, например тип 1, тип 2 и т.д., на этапе 5410. После того как тип обслуживания установлен, хост может начать передавать информацию. Кроме того, хост может использовать пакеты Round Trip Delay Measurement для оптимизации хронирования линий связи параллельно с другой обработкой сигналов, как показано на этапе 5411.

Согласно вышеописанному все передачи начинаются с пакета Sub-Frame Header Packet, передача которого показана на этапе 5412, после чего на этапе 5414 осуществляется передача разных типов данных, в данном случае пакетов видео- и аудиопотоков и пакетов-заполнителей. Аудио- и видеоданные предварительно подготавливаются или отображаются в пакеты, и пакеты-заполнители вставляются при необходимости или желании для заполнения нужного числа битов для медиакадров. Хост может посылать такие пакеты, как Forward Audio Channel Enable, для активации звуковых устройств. Кроме того, хост может передавать команды и информацию с использованием других типов пакета, рассмотренных выше, в данном случае Color Map, Bit Block Transfer или других пакетов на этапе 5416. Кроме того, хост и клиент могут обмениваться данными, относящимися к клавиатуре или указательным устройствам, с использованием соответствующих пакетов.

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

Если эти или другие типы известных условий возникают или изменяются, хост или клиент может обнаружить их и попытаться повторно согласовать режим интерфейса. Это показано на этапе 5420, где хост передает на клиент пакеты Interface Type Handoff Request, запрашивающие переход в другой режим, клиент передает на хост пакеты Interface Type Acknowledge, подтверждающие, что изменение желательно, и хост передает пакеты Perform Type Handoff, чтобы произвести переход в нужный режим.

Хотя, не требуя конкретного порядка обработки, клиент и хост могут также обмениваться пакетами, относящимися к данным, предназначенным для или полученным от указательных устройств, клавиатур или других типов устройств пользовательского ввода, связанных в основном с клиентом, такие элементы также могут присутствовать на стороне хоста. Эти пакеты обычно обрабатываются с использованием элемента типа процессора общего назначения, а не конечного автомата (5502). Кроме того, некоторые из рассмотренных выше команд также будут обрабатываться общим процессором (5504, 5508).

После осуществления обмена данными и командами между хостом и клиентом в некоторый момент принимается решение, нужно ли передавать дополнительные данные или же хост или клиент собирается прекратить обслуживание передачи. Это показано на этапе 5422. Если линия связи должна войти в неактивное состояние или должна быть полностью заблокирована, хост передает на клиент пакет Link Shutdown и обе стороны заканчивают передавать данные.

Пакеты, передаваемые в вышеописанных операциях обработки, будут передаваться с использованием драйверов и приемников, рассмотренных ранее в связи с контроллерами хоста и клиента. Эти драйверы линии и другие логические элементы подключены к рассмотренным выше конечному автомату и общим процессорам, как показано в общей схеме на фиг.55. Согласно фиг.55 конечный автомат 5502 и общие процессоры 5504 могут быть дополнительно подключены к другим элементам, которые не показаны, например, специализированному интерфейсу USB, элементам памяти или другим компонентам, размещенным вне канального контроллера, с которым они взаимодействуют, включая, но без ограничения источник данных и микросхемы управления видео для устройств визуального отображения.

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

XVI. Кадровые буферы дисплея

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

При отображении видео кинематографического качества (почти каждый пиксель на дисплее меняется с каждым медиакадром), обычно предпочтительно сохранять входные пиксельные данные в одном кадровом буфере, а обновлять изображение на дисплее из второго кадрового буфера. Для исключения зрительных артефактов можно использовать более двух буферов дисплея, что описано ниже. Когда все изображение поступило в один кадровый буфер, буферы могут меняться ролями, и затем вновь принятое изображение используется для обновления дисплея, и другой буфер заполняется следующим кадром изображения. Эта концепция проиллюстрирована на фиг.91А, где пиксельные данные записываются в автономный буфер изображения путем задания битов обновления дисплея равными “01”.

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

В приложениях, которые имеют неподвижное изображение с малым видеоокном, легче всего записать неподвижное изображение в оба буфер (биты обновления дисплея равны “11”), как показано на фиг.91С, и затем записать пиксели движущегося изображения в автономный буфер, установив биты обновления дисплея равными “01”.

Следующие правила описывают полезную манипуляцию указателей буфера при одновременной записи новой информации на клиент и обновлении дисплея. Существует три указателя буфера: current_fill указывает на буфер, который в данный момент заполняется данными по линия связи MDDI; just_filled указывает на буфер, который был только что заполнен; being_displayed указывает на буфер, который в данный момент используется для обновления дисплея. Все три указателя буфера могут содержать значения от 0 до N-1, где N – число буферов дисплея, и N>2. Арифметические действия над указателями буфера выполняются по модулю N, например, когда N=3 и current_fill=2, приращение current_fill приводит к тому, что current_fill будет равен 0. В простом случае, когда N=2, just_filled всегда является дополнением к current_fill. На границе каждого медиакадра MDDI (пакет Sub-frame Header Packet с полем Sub-frame Count, равным нулю) осуществляются следующие операции по порядку: задают just_filled равным current_fill и задают current_fill равным current_fill+1.

Пакеты Video Stream MDDI обновляют буферы согласно структуре или методологии: когда биты обновления дисплея равны ’01’, пиксельные данные записываются в буфер, указанный current_fill; когда биты обновления дисплея равны ’00’, пиксельные данные записываются в буфер, указанный just_filled; и когда биты обновления дисплея равны “11”, пиксельные данные записываются во все буферы. Дисплей обновляется из буфера, указанного указателем being_displayed. После того как дисплей обновит последний пиксель в одном периоде обновления кадра и прежде, чем он начнет обновлять первый пиксель в следующем периоде обновления кадра, процесс обновления дисплея осуществляет операцию задания being_refreshed равным just_filled.

Пакет Video Stream содержит пару битов обновления дисплея, которые указывают кадровый буфер, куда нужно записать пиксельные данные. Пакет Client Capability Packet имеет три дополнительных бита, которые указывают, какие комбинации битов обновления дисплея поддерживаются на клиенте. Комбинации Display Update Bit “00” и “11” поддерживают этот режим работы, в котором пиксельные данные записываются в отображаемый кадровый буфер или в оба кадровых буферов.

При работе с видеоизображениями на фиг.92 показано, как видеоизображения отображаются с использованием пары кадровых буферов, когда видеоданные передаются по линии связи MDDI с битами обновления дисплея, равными “01”. После обнаружения границы медиакадра на линии связи MDDI процесс обновления дисплея начнется с обновления из следующего кадрового буфера, когда завершается процесс обновления кадра, обновляемого в настоящий момент.

Важное предположение, связанное с фиг.92, состоит в том, что изображение поступает от хоста в виде непрерывного потока пикселей, которые передаются в том же порядке, в котором их использует клиент для чтения пикселей из кадрового буфера для обновления дисплея (обычно с верхнего левого угла, построчно, к нижнему правому углу экрана). Это важная подробность в случаях, когда операции Display Refresh и Image Transfer опираются на один и тот же кадровый буфер.

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

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

Использование трех кадровых буферов на клиенте разрешит проблему малого окна конфликта для доступа к кадровому буферу, как показано на фиг.95.

Однако все же возникает проблема, если частота обновления дисплея меньше частоты медиакадров по линии связи MDDI, как показано на фиг.96.

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

XVII. Таблица значений задержки

Пакет Packet Processing Delay Parameters Packet использует функцию поисковой таблицы для вычисления прогнозируемой задержки для обработки определенных команд на клиенте. Значения в таблице увеличиваются по логарифмическому закону для обеспечения очень широкого динамического диапазона значений задержки. Иллюстративная таблица значений задержки, полезная для реализации вариантов осуществления изобретения, приведена ниже в качестве таблицы XX, в которой значениям индекса сопоставлены значения задержки.

Задержка вычисляется с использованием поисковой таблицы с использованием указанного параметра в качестве индекса в таблице. Это значит, что задержка равна PacketProcessingTable(index). Например: если один из параметров из элемента Delay Parameters List Item является 8-битовым значением, равным 134, то задержка равна PacketProcessingTable(134), т.е. 16 мкс. Значение 255 указывает, что время выполнения команды нельзя определить путем вычисления и что хост будет проверять поле Graphics Busy Flags в пакете Client Request and Status Packet или параметр MCCS VCP Control Parameter B7h.

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

XVIII. Поддержка множественных клиентов

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

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

XVIII. Дополнение

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

А. Для пакетов Video Stream

Согласно одному варианту осуществления поле Pixel Data Attributes (2 байта) имеет ряд битовых значений, которые интерпретируются следующим образом. Биты 1 и 0 определяют, как маршрутизируются пиксельные данные дисплея. Для битовых значений ’11’ данные отображаются в оба глаза или для двух глаз, для битовых значений ’10’ данные маршрутизируются только в левый глаз, и для битовых значений ’01’ данные маршрутизируются только в правый глаз, и для битовых значений ’00’ данные маршрутизируются на альтернативный дисплей, который может быть указан битами с 8-го по 11-й, рассмотренными ниже.

Бит 2 указывает, представлено ли поле Pixel Data в чересстрочном формате, причем значение ‘0’ означает, что пиксельные данные присутствуют в стандартном прогрессивном формате, и что номер строки (координата Y пикселя) увеличивается на 1 при переходе от одной строки к следующей. Когда этот бит имеет значение ‘1’, пиксельные данные находятся в формате интерфейса и номер строки увеличивается на 2 при переходе от одной строки к следующей. Бит 3 указывает, что поле Pixel Data находится в альтернативном формате пикселя. Это аналогично стандартному режиму интерфейса, обеспечиваемому битом 2, за исключением того, что чередование осуществляется по вертикали, а не по горизонтали. Когда бит 3 равен ‘0’, поле Pixel Data находится в стандартном прогрессивном формате и номер столбца (координата X пикселя) увеличивается на 1 при приеме каждого последующего пикселя. Когда бит 3 равен ‘1’, поле Pixel Data находится в альтернативном формате пикселя и номер столбца увеличивается на 2 при приеме каждого пикселя.

Бит 4 указывает, относятся ли пиксельные данные к дисплею или камере, когда данные переносятся на внутренний дисплей или от него для беспроводного телефона или аналогичного устройства или даже портативного компьютера, или других таких устройств, рассмотренных выше, или когда данные переносятся на или от камеры, встроенной или непосредственно подключенной к устройству. Когда бит 4 равен ‘0’, пиксельные данные переносятся в кадровый буфер дисплея или из него. Когда бит 4 равен ‘1’, пиксельные данные переносятся на или от камеры или видеоустройства того или иного типа, каковые устройства хорошо известны в технике.

Бит 5 используется для указания, когда пиксельные данные содержат следующую по порядку строку пикселей на дисплее. Это справедливо, когда бит 5 задан равным ‘1’. Когда бит 5 равен ‘1’, параметры X Left Edge, Y Top Edge, X Right Edge, Y Bottom Edge, X Start и Y Start не заданы и игнорируются клиентом. Когда бит 15 установлен на уровень логической единицы, это указывает, что пиксельные данные в этом пакете являются последней строкой пикселей в изображении. Бит 8 поля Client Feature Capability Indicators пакета Client Capability Packet указывает, поддерживается ли эта особенность.

Биты 7 и 6 представляют собой биты обновления дисплея, которые задают кадровый буфер для записи пиксельных данных. Более конкретные эффекты рассмотрены в другом месте. Для битовых значений ’01’ пиксельные данные записываются в автономный буфер изображения. Для битовых значений ’00’ пиксельные данные записываются в буфер изображения, используемый для обновления дисплея. Для битовых значений ’11’ пиксельные данные записываются во все буферы изображения. Битовые значения или комбинация ’10’ рассматривается как неверное значение или обозначение, и пиксельные данные игнорируются и не записываются ни в один из буферов изображения. Это значение можно использовать для будущих применений интерфейса.

Биты с 8-го по 11-й образуют 4-битовое беззнаковое целое, которое указывает альтернативный дисплей или местоположение дисплея, куда нужно маршрутизировать пиксельные данные. Биты 0 и 1 задают равными ’00’, чтобы дисплей-клиент интерпретировал биты с 8-го по 11-й как номер альтернативного дисплея. Если биты 0 и 1 не равны ’00’, то биты с 8-го по 11-й устанавливают на уровень логического нуля.

Биты с 12-го по 14-й зарезервированы для использования в будущем и обычно установлены на уровень логического нуля. Бит 15 согласно рассмотренному выше используется совместно с битом 5, и бит 15, равный логической единице, указывает, что строка пикселей в поле Pixel Data является последней строкой пикселей в кадре данных. Следующий пакет Video Stream, в котором бит 5 равен логической единице, будет соответствовать первой строке пикселей следующего видеокадра.

2-байтовые поля X Start и Y Start указывают абсолютные координаты X и Y точки (X Start, Y Start) для первого пикселя в поле Pixel Data. 2-байтовые поля X Left Edge и Y Top Edge указывают координату X левого края и координату Y верхнего края экранного окна, заполненного полем Pixel Data, а поля X Right Edge и Y Bottom Edge указывают координату X правого края и координату Y нижнего края обновляемого окна.

Поле Pixel Count (2 байта) указывает число пикселей в описанном ниже поле Pixel Data.

Поле Parameter CRC (2 байта) содержит CRC всех байтов от поля Packet Length до поля Pixel Count. Если этот контроль CRC не проходит, то весь пакет отбрасывается.

Поле Pixel Data содержит необработанную видеоинформацию, подлежащую отображению, которая форматирована согласно описанному полем Video Data Format Descriptor. Данные передаются “построчно”, что рассмотрено в другом месте. Когда бит 5 поля Pixel Data Attributes установлен на уровень логической единицы, то поле Pixel Data содержит в точности одну строку пикселей, причем первым передается самый левый пиксель и последним передается самый правый пиксель.

Поле Pixel Data CRC (2 байта) содержит 16-битовый CRC только для поля Pixel Data. Если проверка CRC этого значения не проходит, то поле Pixel Data все же можно использовать, но счетчик ошибок CRC получает приращение.

В. Для пакетов Audio Stream

Согласно одному варианту осуществления поле Audio Channel ID (1 байт) использует 8-битовое беззнаковое целое значение для идентификации конкретного аудиоканала, на который устройство-клиент направляет аудиоданные. Физические аудиоканалы задаются в или отображаются в физические каналы этим полем как значения 0, 1, 2, 3, 4, 5, 6 или 7, которые указывают левый передний, правый передний, левый задний, правый задний, передний центральный, сабвуфер, окружающий левый и окружающий правый каналы, соответственно. Значение ID аудиоканала, равное 254, указывает, что единый поток цифровых выборок аудиосигнала направляется одновременно на левый передний и правый передний каналы. Это упрощает связь для таких приложений, где стереонаушники используются для голосовой связи, приложения повышения производительности используются на КПК, или других приложений, где простой пользовательский интерфейс генерирует тональные сигналы предупреждения. Значения поля ID в диапазоне от 8 до 253 и 255 в настоящее время зарезервированы для использования, где новые конструкции требуют дополнительных обозначений, что очевидно специалистам в данной области.

Поле Reserved 1 (1 байт) в общем случае зарезервировано для использования в будущем, и все биты в этом поле заданы равными нулю. Одной функцией этого поля является выравнивание всех последующих 2-байтовых полей с 16-битовым словом адреса и выравнивание 4-байтовых полей с 32-битовым словом адреса.

Поле Audio Sample Count (2 байта) указывает количество выборок аудиосигнала в этом пакете.

Поле выборки аудиосигнала содержит 1 байт, который указывает формат упаковки аудиоданных. Согласно одному варианту осуществления формат, который обычно используется, выражается битами с 4-го по 0-й для задания числа битов на выборку аудиосигнала в режиме ИКМ. Бит 5 указывает, упакованы ли выборки в поле Digital Audio Data. Как отмечено выше, на фиг.12 показана разница между упакованными и выровненными по границе байта выборками аудиосигнала. Значение ‘0’ для бита 5 указывает, что каждая выборка аудиосигнала в режиме ИКМ в поле Digital Audio Data выровнена по границе байта с границей байта интерфейса, и значение ‘1’ указывает, что каждая последующая выборка аудиосигнала в режиме ИКМ упакована относительно предыдущей выборки аудиосигнала. Этот бит эффективен, только когда значение, заданное в битах с 4-го по 0-й (число битов на выборку аудиосигнала в режиме ИКМ) не является кратным восьми. Биты с 7-го по 6-й зарезервированы для использования, где конструкции системы требуют дополнительных обозначений, и в общем случае заданы равными нулю.

Поле Audio Sample Rate (1 байт) задает частоту дискретизации ИКМ аудиосигнала. Используемый формат предусматривает, что значение 0 указывает частоту 8000 выборок в секунду (sps), значение 1 указывает 16000 sps, значение 2 – 24000 sps, значение 3 – 32000 sps, значение 4 – 40000 sps, значение 5 – 48000 sps, значение 6 – 11025 sps, значение 7 – 22050 sps и значение 8 – 44100 sps соответственно, а значения с 9 по 255 зарезервированы для использования в будущем, поэтому в настоящее время заданы равными нулю.

Поле Parameter CRC (2 байта) содержит 16-битовый CRC всех байтов от поля Packet Length до поля Audio Sample Rate. Если не удается надлежащим образом проверить этот CRC, то весь пакет отбрасывается. Поле Digital Audio Data содержит необработанные выборки аудиосигнала, подлежащие воспроизведению, и обычно в форме линейного формата как беззнаковые целые. Поле Audio Data CRC (2 байта) содержит 16-битовый CRC только для поля Audio Data. Если этот CRC не удается проверить, то Audio Data все же можно использовать, но счетчик ошибок CRC получает приращение.

С. Для пакетов User-Defined Stream

Согласно одному варианту осуществления 2-байтовое поле Stream ID Number используется для идентификации конкретного потока, заданного пользователем. Содержимое полей Stream Parameters и Stream Data обычно задается изготовителем оборудования MDDI. 2-байтовое поле Stream Parameter CRC содержит 16-битовый CRC всех байтов параметров потока начиная с поля Packet Length до байта Audio Coding. Если этот CRC не удается проверить, то весь пакет отбрасывается. Оба поля Stream Parameters и Stream Parameter CRC могут быть отброшены, если они не требуются конечному приложению интерфейса MDD, т.е. они считаются необязательными. 2-байтовое поле Stream Data CRC содержит CRC только для поля Stream Data. Если не удается надлежащим образом проверить этот CRC, то использование Stream Data является необязательным в зависимости от требований приложения. Использование данных потока в зависимости от того, хорош ли CRC, в общем случае требует буферизации данных потока, пока не будет подтверждено, что CRC хороший. Счетчик ошибок CRC получает приращение, если проверка CRC не проходит.

D. Для пакетов Color Map

2-байтовое поле hClient ID содержит информацию или значения, которые зарезервированы для ID клиента, как использовалось ранее. Поскольку это поле в общем случае зарезервировано для использования в будущем, текущее значение задано равным нулю путем задания битов равными ‘0’.

2-байтовое поле Color Map Item Count использует значения для указания полного количества 3-байтовых элементов карты цветов, которые содержатся поле Color Map Data, или элементов таблица карты цветов, которые существуют в поле Color Map Data этого пакета. Согласно этому варианту осуществления число байтов в поле Color Map Data в 3 раза больше, чем в поле Color Map Item Count. Поле Color Map Item Count задается равным нулю, чтобы не передавать никаких данных карты цветов. Если поле Color Map Size равно нулю, то значение Color Map Offset в общем случае все же можно передавать, но оно игнорируется дисплеем. Поле Color Map Offset (4 байта) задает смещение поля Color Map Data в этом пакете от начала таблицы карты цветов на устройстве-клиенте.

2-байтовое поле Parameter CRC содержит CRC всех байтов от поля Packet Length до байта Audio Coding. Если этот контроль CRC не проходит, то весь пакет отбрасывается.

Для поля Color Map Data ширина каждого положения карты цветов задается полем Color Map Item Size, где согласно одному варианту осуществления первая часть задает величину синего, вторая часть задает величину зеленого и третья часть задает величину красного. Поле Color Map Size указывает количество 3-байтовых элементов таблицы карты цветов, которые существуют в поле Color Map Data. Если единичная карта цветов не влезает в один пакет Video Data Format and Color Map Packet, то всю карту цветов можно задать, передавая множественные пакеты с разными полями Color Map Data и Color Map Offset в каждом пакете. Число битов синего, зеленого и красного в каждом элементе данных карты цветов в общем случае одинаково, что указано в поле Color Map RGB Width пакета Display Capability Packet.

2-байтовое поле Color Map Data CRC содержит CRC только для поля Color Map Data. Если этот CRC не удается проверить, то поле Color Map Data все же можно использовать, но счетчик ошибок CRC получает приращение.

Каждый элемент данных карты цветов подлежит передаче в порядке: синий, зеленый, красный, причем первым передается самый младший бит каждого компонента. Компоненты красного, зеленого и синего каждого элемента карты цветов упаковываются по отдельности, но каждый элемент карты цветов (самый младший бит синего компонента) должен быть выровнен по границе байта. На фиг.100 показан пример элементов данных карты цветов с 6 битами синего, 8 битами зеленого и 7 битами красного. В этом примере поле Color Map Item Size пакета Color Map Packet равно 21 и поле Color Map RGB Width пакета Client Capability Packet равно 0x0786.

Е. Для пакетов Reverse Link Encapsulation

Поле Parameter CRC (2 байта) содержит 16-битовый CRC всех байтов от поля Packet Length до поля Turn-Around Length. Если этот CRC не удается проверить, то весь пакет отбрасывается.

Согласно одному варианту осуществления поле Reverse Link Flags (1 байт) содержит набор флагов для запроса информации у клиента. Если бит (например, бит 0) установлен на уровень логической единицы, то хост запрашивает указанную информацию у дисплея с использованием пакета Client Capability Packet. Если бит установлен на уровень логического нуля, то хосту не нужна информация от клиента. Остальные биты (здесь биты с 1-го по 7-й) зарезервированы для использования в будущем и заданы равными нулю. Однако при желании можно использовать больше битов для задания флагов для обратной линии связи.

Поле Reverse Rate Divisor (1 байт) указывает количество периодов MDDI_Stb, которые имеют место в связи с тактовой частотой данных обратной линии связи. Тактовая частота данных обратной линии связи равна тактовой частоте данных прямой линии связи, деленной на удвоенный Reverse Rate Divisor. Скорость передачи данных обратной линии связи связана с тактовой частотой данных обратной линии связи и типом интерфейса на обратной линии связи. Согласно этому варианту осуществления для интерфейса 1 типа скорость передачи данных обратной линии связи равна тактовой частоте данных обратной линии связи, для интерфейсов типа 2, 3 и 4 скорость передачи данных обратной линии связи в два, четыре и восемь раз больше тактовой частоты данных обратной линии связи, соответственно.

Поле All Zero 1 содержит группу байтов, в данном случае 8, имеющих нулевое значение за счет того, что биты установлены на уровень логического нуля, и используется, чтобы гарантировать, что все сигналы MDDI_Data находятся на уровне логического нуля на протяжении достаточного времени, чтобы клиент мог начать восстановление тактового сигнала с использованием только MDDI_Stb до отключения драйверов линии хоста в течение поля Turn-Around 1. Согласно одному варианту осуществления длина поля All Zero 1 больше или равна числу периодов передачи байта на прямой линии связи в двусторонней задержке кабеля.

Поле Turn-Around 1 Length (1 байт) указывает полное количество байтов, выделенных для поля Turn-Around 1, устанавливающего первый период реверсирования. Байты в количестве, заданном параметром Turn-Around 1 Length, выделяются, чтобы драйверы линии MDDI_DATA на клиенте могли включиться до отключения драйверов линии на хосте. Клиент включает свои драйверы линии MDDI_DATA в течение бита 0 поля Turn-Around 1, и хост отключает свои выводы, чтобы они были полностью отключены до последнего бита поля Turn-Around 1. Хронирование процессов включения драйвера клиента и отключения драйвер хоста таково, что один или оба переводят сигналы MDDI_Data на уровень логического нуля на протяжении Turn Around 1, что видят приемники линии на хосте. Сигнал MDDI_Stb ведет себя так, как будто MDDI_Data0 находится на уровне логического нуля в течение всего периода Turn Around 1. Более полное описание задания Turn Around 1 приведено выше.

Поле Reverse Data Packets содержит ряд пакетов данных, передаваемых от клиента на хост. Клиент может передавать пакеты-заполнители или переводить линии MDDI_DATA в состояние или на уровень логического нуля, когда у него нет данных для передачи на хост. Согласно этому варианту осуществления если линии MDDI_DATA переведены на нуль, хост будет интерпретировать это как пакет нулевой длины (неправильной длины) и хост не будет принимать никаких других пакетов от клиента в течение данного пакета Reverse Link Encapsulation Packet.

Поле Turn-Around 2 Length (1 байт) указывает полное количество байтов, выделенных для поля Turn-Around 2, для установления второго периода реверсирования. Байты в количестве, заданном параметром Turn-Around Length, выделяются, чтобы драйверы линии MDDI_DATA на хосте могли включиться до отключения драйверов линии на клиенте. Хост включает свои драйверы линии MDDI_DATA в течение бита 0 первого байта в поле Turn-Around 2, и клиент отключает свои выводы, чтобы они были полностью отключены до последнего бита поля Turn-Around 2. Хронирование процессов отключения драйвера клиента и включения драйвер хоста таково, что один или оба переводят сигналы MDDI_Data на уровень логического нуля на протяжении или в течение всего периода Turn Around 2, что видят приемники линии на хосте. Сигнал MDDI_Stb ведет себя так, как будто MDDI_Data0 находится на уровне логического нуля в течение по существу всего периода Turn Around 2. Описание задания Turn Around 2 приведено выше.

Поле Reverse Data Packets содержит ряд пакетов данных, передаваемых с клиента на хост. Согласно вышесказанному пакеты-заполнители передаются для заполнения оставшегося места, которое не используется пакетами других типов.

Поле All Zero 2 содержит группу байтов (8 согласно этому варианту осуществления), имеющих нулевое значение за счет того, что биты установлены на уровень логического нуля, и используется, чтобы гарантировать, что все сигналы MDDI_Data находятся на уровне логического нуля на протяжении достаточного времени, чтобы клиент мог начать восстановление тактового сигнала с использованием обоих сигналов MDDI_Data0 и MDDI_Stb после включения драйверов линии хоста после поля Turn-Around 2.

F. Для пакетов Client Capability

Как проиллюстрировано согласно одному варианту осуществления, поле Protocol Version использует 2 байта для указания версии протокола, используемой клиентом. Начальная версия в настоящее время задана равной 1 и будет изменяться со временем по мере появления новых версий, тогда как поле Minimum Protocol Version использует 2 байта для указания минимальной версии протокола, которую клиент может использовать или интерпретировать. В этом случае нулевое значение также является пригодным значением. Поле Data Rate Capability (2 байта) указывает максимальную скорость передачи данных, которую клиент может принимать на каждой паре данных по прямой линии связи интерфейса, и указывает ее в мегабитах в секунду (Мбит/с). Поле Interface Type Capability (1 байт) указывает типы интерфейса, поддерживаемые на прямой и обратной линиях связи. Бит, заданный равным ‘1’, указывает, что данный тип интерфейса поддерживается, и бит, заданный равным ‘0’, указывает, что данный тип интерфейса не поддерживается. Хосты и клиенты должны поддерживать, по меньшей мере, тип 1 на прямой и обратной линиях связи. Нет необходимости поддерживать весь диапазон типов интерфейса. Например, достаточно поддерживать только тип 1 и тип 3, но не тип 3 и тип 4 в интерфейсе. Также нет необходимости, чтобы прямая и обратная линии связи работали с одним и тем же типом интерфейса. Однако когда линия связи выходит из неактивного состояния, прямая и обратная линии связи должны начинать работу с режиме типа 1, пока другие режимы не будут согласованы, выбраны или иначе утверждены для использования хостом и клиентом.

Поддерживаемые интерфейсы указываются согласно одному варианту осуществления путем выбора бита 0, бита 1 или бита 2 для выбора режима типа 2 (2 бит), типа 3 (4 бит) или типа 4 (8 бит) на прямой линии связи соответственно; и бита 3, бита 4 или бита 5 для выбора режима типа 2, типа 3 или типа 4 на обратной линии связи соответственно; при этом биты 6 и 7 зарезервированы и в общем случае заданы равными нулю в настоящее время. Поля Bitmap Width и Bitmap Height, в данном случае имеющие размер 2 байта, указывают ширину и высоту битовой карты соответственно в пикселях.

Поле Monochrome Capability (1 байт) используется для указания количества битов разрешения, которое может отображаться в монохромном формате. Если дисплей не может использовать монохромный формат, то это значение задано равным нулю. Биты с 7-го по 4-й зарезервированы для использования в будущем и, таким образом, заданы равными нулю. Биты с 3-го по 0-й задают максимальное число битов градации серого, которые могут существовать для каждого пикселя. Эти четыре бита позволяют задавать значения с 1 по 15 для каждого пикселя. Если значение равно нулю, значит, монохромный формат не поддерживается дисплеем.

Поле Bayer Capability использует 1 байт, чтобы задавать число битов разрешения, группу пикселей и порядок пикселей, которые можно передавать в формате Байера. Если клиент не может использовать формат Байера, то это значение задано равным нулю. Поле Bayer Capability состоит из следующих значений: биты с 3-го по 0-й задают максимальное число битов интенсивности, которые существуют в каждом пикселе, биты с 5-го по 4-й задают шаблон группы пикселей, который требуется, биты с 8-го по 6-й задает необходимый порядок пикселей; а биты с 14-го по 9-й зарезервированы для использования в будущем и в общем случае заданы равными нулю в настоящее время. Бит 15, будучи установлен на уровень логической единицы, указывает, что клиент может принимать пиксельные данные Байера в упакованном или неупакованном формате. Если бит 15 задан равным нулю, это указывает, что клиент может принимать пиксельные данные Байера только в неупакованном формате.

Поле Color Map Capability (3 байта) указывает максимальное количество элементов таблицы, которые существуют в таблице карты цветов на дисплее. Если дисплей не может использовать формат карты цветов, то это значение задано равным нулю.

Поле RGB Capability (2 байта) указывает количество битов разрешения, которое может отображаться в формате RGB. Если дисплей не может использовать формат RGB, то это значение равно нулю. Слово RGB Capability состоит из трех отдельных беззнаковых значений, где: биты с 3-го по 0-й задают максимальное число битов синего цвета, биты с 7-го по 4-й задают максимальное число битов зеленого цвета, и биты с 11-го по 8-й задают максимальное число битов красного цвета в каждом пикселе. Биты с 14-го по 12-й зарезервированы для использования в будущем и в общем случае заданы равным нулю. Бит 15, будучи установлен на уровень логической единицы, указывает, что клиент может принимать пиксельные данные RGB в упакованном или неупакованном формате. Если бит 15 установлен на уровень логического нуля, это указывает, что клиент может принимать пиксельные данные RGB только в неупакованном формате.

Поле Y Cr Cb Capability (2 байта) указывает число битов разрешения, которое может отображаться в формате Y Cr Cb. Если дисплей не может использовать формат Y Cr Cb, то это значение задано равным нулю. Слово Y Cr Cb Capability состоит из трех отдельных беззнаковых значений, где: биты с 3-го по 0-й задают максимальное число битов в выборке Cb, биты с 7-го по 4-й задают максимальное число битов в выборке Cr, биты с 11-го по 8-й задают максимальное число битов в выборке Y и биты с 15-го по 12-й настоящее время зарезервированы для использования в будущем и заданы равными нулю.

Поле Client Feature Capability использует 4 байта, которые содержат флаги, указывающие конкретные особенности, поддерживаемые на клиенте. Бит, установленный на уровень логической единицы, указывает, что возможность поддерживается, а бит, установленный на уровень логического нуля, указывает, что возможность не поддерживается. Согласно одному варианту осуществления значение бита 0 указывает, поддерживается ли пакет Bitmap Block Transfer Packet (тип пакета 71). Значения битов 1, 2 и 3 указывают, поддерживаются ли пакеты Bitmap Area Fill Packet (тип пакета 72), Bitmap Pattern Fill Packet (тип пакета 73) и Communication Link Data Channel Packet (тип пакета 74) соответственно. Значение бита 4 указывает, имеет ли клиент возможность сделать один цвет прозрачным с использованием пакета Transparent Color Enable Packet, тогда как значения битов 5 и 6 указывают, может ли клиент принимать в упакованном формате видеоданные или аудиоданные соответственно, и значение бита 7 указывает, может ли клиент передавать видеопоток обратной линии связи от камеры. Значение бита 8 указывает, может ли клиент принимать сплошную линию пиксельных данных и игнорировать адресацию дисплея, указанную битом 5 поля Pixel Data Attributes пакета Video Stream Packet, и клиент также может обнаруживать синхронизацию или конец кадра для данных видеокадра с использованием бита 15 поля Pixel Data Attributes.

Значение битов 11 и 12 указывают, когда клиент осуществляет связь с указательным устройством и может передавать и принимать пакеты Pointing Device Data, или же с клавиатурой и может передавать и принимать пакеты Keyboard Data соответственно. Значение бита 13 указывает, может ли клиент задавать один или несколько параметров аудио или видео благодаря поддержке пакетов VCP Feature: Request VCP Feature Packet, VCP Feature Reply Packet, Set VCP Feature Packet, Request Valid Parameter Packet, и Valid Parameter Reply Packet. Значение бита 14 указывает, может ли клиент записывать пиксельные данные в автономный кадровый буфер дисплея. Если этот бит установлен на уровень логической единицы, то биты обновления дисплея (биты 7 и 6 поля Pixel Data Attributes пакета Video Stream Packet) могут быть заданы равными значениям ’01’.

Значение бита 15 указывает, когда клиент имеет возможность записывать пиксельные данные только в кадровый буфер дисплея, который в настоящее время используется для обновления изображения на дисплее. Если этот бит задан равным единице, то биты обновления дисплея (биты 7 и 6 поля Pixel Data Attributes пакета Video Stream Packet) могут быть заданы равными значениям ’00’. Значение бита 16 указывает, когда клиент имеет возможность записывать пиксельные данные из одного пакета Video Stream Packet во все кадровые буферы дисплея. Если этот бит задан равным единице, то биты обновления дисплея (биты 7 и 6 поля Pixel Data Attributes пакета Video Stream Packet) могут быть заданы равными значениям ’11’.

Значение бита 17 указывает, когда клиент имеет возможность отвечать на пакет Request Specific Status Packet, значение бита 18 указывает, когда клиент имеет возможность отвечать на пакет Round Trip Delay Measurement Packet, и значение бита 19 указывает, когда клиент имеет возможность отвечать на пакет Forward Link Skew Calibration Packet.

Значение бита 21 указывает, когда клиент имеет возможность интерпретировать пакет Request Specific Status Packet и передавать в ответ пакет Valid Status Reply List Packet. Клиент указывает возможность возвращать дополнительный статус в поле Valid Parameter Reply List пакета Valid Status Reply List Packet, как описано в другом месте.

Значение бита 22 указывает, когда клиент имеет возможность отвечать на пакет Register Access Packet. Биты 9, 10, 20 и с 22 по 31 настоящее время зарезервированы для использования в будущем или альтернативных обозначений, полезных для разработчиков системы, и в общем случае заданы равными нулю.

Поле Display Video Frame Rate Capability (1 байт) указывает максимальную возможность обновления видеокадров дисплея, выражаемую в кадрах в секунду. Хост может выбрать обновление изображения на меньшей частоте, чем значение, указанное в этом поле.

Поле Audio Buffer Depth (2 байта) указывает глубину эластичного буфера в дисплее, который выделяется для каждого аудиопотока.

Поле Audio Channel Capability (2 байта) содержит группу флагов, которые указывают, какие аудиоканалы поддерживаются клиентом или устройством, подключенным к клиенту. Бит, заданный равным единице, указывает, что канал поддерживается, а бит, заданный равным нулю, указывает, что канал не поддерживается. Битовые позиции присваиваются разным каналам, например битовые позиции 0, 1, 2, 3, 4, 5, 6 и 7 согласно одному варианту осуществления указывают левый передний, правый передний, левый задний, правый задний, передний центральный, сабвуфер, окружающий левый и окружающий правый каналы соответственно. Биты с 8-го по 14-й настоящее время зарезервированы для использования в будущем и обычно заданы равными нулю. Согласно одному варианту осуществления бит 15 используется для указания, обеспечивает ли клиент поддержку пакета Forward Audio Channel Enable Packet. Если да, то бит 15 устанавливают на уровень логической единицы. Если же клиент не может отключать аудиоканалы в результате пакета Forward Audio Channel Enable Packet или если клиент не поддерживает никаких аудиовозможностей, то этот бит устанавливают на уровень или значение логического нуля.

2-байтовое поле Audio Sample Rate Capability для прямой линии связи содержит набор флагов для указания возможности частоты дискретизации аудиосигнала устройства-клиента. Битовые позиции присваиваются разным частотам соответственно, например биты 0, 1, 2, 3, 4, 5, 6, 7 и 8 присваиваются 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050 и 44100 выборкам в секунду (SPS) соответственно, а биты с 9-го по 15-й зарезервированы на будущее или для альтернативных частот, по желанию, поэтому в настоящее время они заданы равными ‘0’. Задание битового значения для одного из этих битов равным ‘1’, указывает, что поддерживается данная конкретная частота дискретизации, и задание бита равным ‘0’ указывает, что данная конкретная частота дискретизации не поддерживается.

Поле Minimum Sub-frame Rate (2 байта) задает минимальную частоту подкадров, выражаемую в кадрах в секунду. Минимальная частота подкадров поддерживает частоту обновления статуса клиента достаточной для считывания определенных датчиков или указательных устройств на клиенте.

2-байтовое поле Mic Sample Rate Capability для обратной линии связи содержит набор флагов, которые указывают возможность частоты дискретизации аудиосигнала микрофона на устройстве-клиенте. Для целей MDDI микрофон устройства-клиента настроен для минимальной поддержки частоты, по меньшей мере, 8000 выборок в секунду. Битовые позиции для этого поля присваиваются разным частотам, причем битовые позиции 0, 1, 2, 3, 4, 5, 6, 7 и 8, например, используются для представления 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050 и 44100 выборок в секунду (SPS) соответственно, а биты с 9-го по 15-й зарезервированы на будущее или для альтернативных частот, по желанию, поэтому в настоящее время они заданы равными ‘0’. Задание битового значения для одного из этих битов равным ‘1’ указывает, что поддерживается данная конкретная частота дискретизации, и задание бита равным ‘0’ указывает, что данная конкретная частота дискретизации не поддерживается. Если микрофон не подключен, то каждый бит поля Mic Sample Rate Capability задан равным нулю.

Поле Keyboard Data Format (здесь, 1 байт) указывает, подключена ли клавиатура к системе клиента, и тип подключенной клавиатуры. Согласно одному варианту осуществления значение, установленное битами с 6-го по 0-й, используется для задания типа подключенной клавиатуры. Если значение равно нулю (0), то тип клавиатуры считается неизвестным. Для значения 1 формат данных клавиатуры рассматривается как стандартный стиль PS-2. В настоящее время значения в диапазоне от 2 до 125 не используются, будучи зарезервированы для использования разработчиками системы и специалистами по внедрению интерфейса или продвижению продукта для задания конкретных клавиатур или устройств ввода для использования с интерфейсом MDD и соответствующими клиентами или хостами. Значение 126 используется для указания, что формат данных клавиатуры задан пользователем, а значение 127 используется для указания, что клавиатуру нельзя подключить к этому клиенту. Кроме того, бит 7 можно использовать для указания, может ли клавиатура осуществлять связь с клиентом. Этот бит предполагается использовать для указания, когда клавиатура может осуществлять связь с клиентом с использованием беспроводной линии связи. Бит 7 будет установлен на нулевой уровень, если биты с 6-го по 0-й указывают, что клавиатура не может подключаться к клиенту. Поэтому согласно одному варианту осуществления когда значение бита 7 равно 0, клавиатура и клиент не могут поддерживать связь, а когда значение бита 7 равно 1, клавиатура и клиент подтверждают, что они могут поддерживать связь друг с другом.

Поле Pointing Device Data Format (здесь, 1 байт) указывает, подключено ли указательное устройство к системе клиента, и тип подключенного указательного устройства. Согласно одному варианту осуществления значение, установленное битами с 6-го по 0-й, используется для задания типа подключенного указательного устройства. Если значение равно нулю (0), то тип указательного устройства считается неизвестным. Для значения 1 формат данных указательного устройства рассматривается как стандартный стиль PS-2. В настоящее время значения в диапазоне от 2 до 125 не используются, будучи зарезервированы для использования разработчиками системы и специалистами по внедрению интерфейса или продвижению продукта для задания конкретных указательных устройств или устройств ввода для использования с интерфейсом MDD и соответствующими клиентами или хостами. Значение 126 используется для указания, что формат данных указательного устройства задан пользователем, а значение 127 используется для указания, что указательное устройство нельзя подключить к этому клиенту. Кроме того, бит 7 можно использовать для указания, может ли указательное устройство осуществлять связь с клиентом. Этот бит предполагается использовать для указания, когда клавиатура может осуществлять связь с клиентом с использованием беспроводной линии связи. Бит 7 будет установлен на нулевой уровень, если биты с 6-го по 0-й указывают, что указательное устройство не может подключаться к клиенту. Поэтому согласно одному варианту осуществления когда значение бита 7 равно 0, указательное устройство и клиент не могут поддерживать связь, а когда значение бита 7 равно 1, указательное устройство и клиент подтверждают, что они могут поддерживать связь друг с другом.

Поле Content Protection Type (2 байта) содержит набор флагов, которые указывают тип защиты цифрового контента, поддерживаемый дисплеем. В настоящее время битовая позиция 0 используется для указания, когда поддерживается DTCP, и битовая позиция 1 используется для указания, когда поддерживается HDCP, а битовые позиции со 2-й по 15-ю зарезервированы для использования другими схемами защиты, желаемыми или имеющимися, поэтому в настоящее время заданы равными нулю.

Поле Mfr Name (здесь, 2 байта) содержит 3-символьный ID изготовителя в стандарте EISA, упакованный в три 5-битовых символа таким же образом, как в спецификации VESA EDID. Символ ‘A’ представлен в двоичном виде как 00001, символ ‘Z’ представлен в двоичном виде как 11010, и все буквы между ‘A’ и ‘Z’ представлены последовательными двоичными значениями, которые соответствуют алфавитной последовательности между ‘A’ и ‘Z’. Самый старший бит поля Mfr Name не используется и обычно задан равным логическому нулю в настоящее время с учетом использования в будущих реализациях. Пример: изготовитель, представленный строкой “XYZ”, будет иметь значение Mfr Name, равное 0x633a. Если это поле не поддерживается клиентом, оно обычно задано равным нулю. Поле Product Code использует 2 байта для вмещения кода изделия, присвоенного изготовителем дисплея. Если это поле не поддерживается клиентом, оно обычно задано равным нулю.

Поля Reserved 1, Reserved 2 и Reserved 3 (здесь, 2 байта каждое) зарезервированы для использования в будущем при сообщении информации. Все биты этого поля в общем случае установлены на уровень логического нуля. Целью таких полей в настоящее время является выравнивание всех последующих 2-байтовых полей с 16-битовым словом адреса и выравнивание 4-байтовых полей с 32-битовым словом адреса.

Поле Serial Number использует 4 байта согласно этому варианту осуществления для задания серийного номера дисплея в числовом виде. Если это поле не поддерживается клиентом, оно обычно задано равным нулю. Поле Week of Manufacture использует 1 байт для указания недели изготовления дисплея. Это значение обычно находится в диапазоне от 1 до 53, если поддерживается клиентом. Если это поле не поддерживается клиентом, оно задано равным нулю. Поле Year of Manufacture это 1 байт, который указывает год изготовления дисплея. Это значение представляет собой смещение относительно 1990 года. Это поле позволяет выражать года в диапазоне от 1991 до 2245. Пример: год 2003 соответствует значению Year of Manufacture, равному 13. Если это поле не поддерживается клиентом, оно задано равным нулю.

Поле CRC (здесь 2 байта) содержит 16-битовый CRC всех байтов в пакете, включая Packet Length.

G. Для пакетов Client Request and Status

Поле Reverse Link Request (3 байта) задает количество байтов, необходимых клиенту на обратной линии связи в следующем подкадре, чтобы передать информацию на хост.

Поле CRC Error Count (1 байт) указывает, сколько ошибок CRC произошло с начала медиакадра. Счетчик CRC сбрасывается при передаче пакета заголовка подкадра, в котором поле Sub-frame Count равно нулю. Если фактическое количество ошибок CRC превышает 255, то это значение в общем случае достигает насыщения при 255.

Поле Capability Change использует 1 байт для указания изменения возможностей дисплея. Это может произойти, если пользователь подключает периферийное устройство, например микрофон, клавиатуру или дисплей, или по какой-либо другой причине. Если биты [7:0] равны нулю, значит, возможности не изменились после отправки последнего пакета Client Capability Packet. Если же биты [7:0] равны от 1 до 255, значит, возможности изменились. Пакет Client Capability Packet проверяется для определения новых характеристик дисплея.

Поле Client Busy Flags использует 2 байта для указания того, что клиент выполняет специфическую функцию и еще не готов принять другой пакет, относящийся к такой функции. Бит, установленный на уровне или в значении логического нуля, указывает на то, что в данный момент времени клиентом выполняется конкретная функция и что соответствующая функция у клиента занята. Если соответствующая функция у клиента готова, то бит устанавливают на уровне логического нуля. Клиент должен вернуть состояние “занято” (бит устанавливается на единицу) для всех функций, которые не поддерживаются клиентом.

В одном из вариантов осуществления эти байты интерпретируются в соответствии со следующими соотношениями: если бит 0 равен Т, то функция передачи блоков растрового изображения является занятой, в то время как если бит 1 равен ‘1’, то занята функция заполнения области растрового изображения, и если бит 2 равен ‘1’, то занята функция заполнения шаблона растрового изображения. Теперь биты 3-15 остаются резервными для дальнейшего использования и обычно устанавливаются на уровень или в состояние логической единицы для указания статуса “занято” в случае, если эти биты далее определены.

H. Для пакетов Bit Block Transfer

Поля Window Upper Left Coordinate X Value и Window Upper Left Coordinate Y Value используют каждые 2 байта для задания значений координат X и Y верхнего левого угла окна, подлежащего перемещению. Поля Window Width и Window Height используют каждое 2 байта для задания ширины и высоты окна, подлежащего перемещению. Поля Window X Movement и Window Y Movement используют каждое 2 байта для задания числа пикселей, на которое нужно переместить окно по горизонтали и вертикали соответственно. Обычно эти координаты сконфигурированы так, что положительные значения Х соответствуют перемещению окна вправо, а отрицательные значения Х соответствуют перемещению окна влево, положительные значения Y соответствуют перемещению окна вниз, а отрицательные значения Y соответствуют перемещению окна вверх.

I. Для пакетов Bitmap Area Fill

Поля Window Upper Left Coordinate X Value и Window Upper Left Coordinate Y Value используют каждое 2 байта для задания значений координат X и Y верхнего левого угла окна, подлежащего заполнению. Поля Window Width и Window Height (2 байта каждое) указывают ширину и высоту окна, подлежащего заполнению. Поле Video Data Format Descriptor (2 байта) задает формат поля Pixel Area Fill Value. Формат такой же, как для такого же поля в пакете Video Stream Packet. Поле Pixel Area Fill Value (4 байта) содержит значение пикселя для заполнения окна, заданного полями, рассмотренными выше. Формат этого пикселя задан в поле Video Data Format Descriptor.

J. Для пакетов Bitmap Pattern Fill

Поля Window Upper Left Coordinate X Value и Window Upper Left Coordinate Y Value используют каждое 2 байта для задания значений координат X и Y верхнего левого угла окна, подлежащего заполнению. Поля Window Width и Window Height (2 байта каждое) указывают ширину и высоту окна, подлежащего заполнению. Поля Pattern Width и Pattern Height (2 байта каждое) указывают ширину и высоту соответственно шаблона заполнения. Поле Horizontal Pattern Offset (2 байта) задает горизонтальное смещение шаблона пиксельных данных от левого края указанного окна, подлежащего заполнению. Указанное значение должно быть меньше значения в поле Pattern Width. Поле Vertical Pattern Offset (2 байта) задает вертикальное смещение шаблона пиксельных данных от верхнего края указанного окна, подлежащего заполнению. Указанное значение должно быть меньше значения в поле Pattern Height.

2-байтовое поле Video Data Format Descriptor указывает формат поля Pixel Area Fill Value. На фиг.11 показано, как кодируется поле Video Data Format Descriptor. Формат такой же, как у такого же поля в пакете Video Stream Packet.

Поле Parameter CRC (2 байта) содержит CRC всех байтов от поля Packet Length до поля Video Format Descriptor. Если этот контроль CRC не проходит, то весь пакет отбрасывается. Поле Pattern Pixel Data содержит необработанную видеоинформацию, которая задает шаблон заполнения в формате, указанном в поле Video Data Format Descriptor. Данные упакованы в байты, и первый пиксель каждой строки должен быть выровнен по границе байта. Данные шаблона заполнения передаются построчно. Поле Pattern Pixel Data CRC (2 байта) содержит CRC только для поля Pattern Pixel Data. Если этот контроль CRC не проходит, то поле Pattern Pixel Data все же можно использовать, но счетчик ошибок CRC получает приращение.

K. Пакеты Communication Link Data Channel

Поле Parameter CRC (2 байта) содержит 16-битовый CRC всех байтов от поля Packet Length до поля Packet Type. Если этот контроль CRC не проходит, то весь пакет отбрасывается.

Поле Communication Link Data содержит необработанные данные из канала связи. Эти данные просто передаются на вычислительное устройство в дисплее.

Поле Communication Link Data CRC (2 байта) содержит 16-битовый CRC только для поля Communication Link Data. Если этот контроль CRC не проходит, то поле Communication Link Data все же используется или полезно, но счетчик ошибок CRC получает приращение.

L. Для пакетов Interface Type Handoff Request

Поле Interface Type (1 байт) указывает новый тип интерфейса для использования. Значение этого поля указывает тип интерфейса следующим образом. Если значение в бите 7 равно ‘0’, то запрос изменения типа предназначен для прямой линии связи, а если он равен ‘1’, то запрос изменения типа предназначен для обратной линии связи. Биты с 6-го по 3-й зарезервированы для использования в будущем и обычно заданы равными нулю. Биты со 2-го по 0-й используются для задания типа интерфейса, подлежащего использованию, и значение 1 означает переход в режим типа 1, значение 2 – переход в режим типа 2, значение 3 – переход в режим типа 3 и значение 4 – переход в режим типа 4. Значения ‘0’ и 5-7 зарезервированы для будущего обозначения альтернативных режимов или комбинаций режимов.

M. Для пакетов Interface Type Acknowledge

Поле Interface Type (1 байт) имеет значение, подтверждающее использование нового типа интерфейса. Значение в этом поле указывает тип интерфейса следующим образом. Если бит 7 равен ‘0’, то запрос изменения типа предназначен для прямой линии связи, а если он равен ‘1’, то запрос изменения типа предназначен для обратной линии связи. Битовые позиции с 6-й по 3-ю в настоящее время зарезервированы для использования при обозначении других типов перехода по желанию и обычно заданы равными нулю. Однако битовые позиции со 2-й по 0-ю используются для задания типа интерфейса для использования, при этом значение ‘0’ указывает отрицательное квитирование или что запрашиваемый переход нельзя осуществить, и значения ‘1’, ‘2’, ‘3’ и ‘4’ указывают переход в режимы типа 1, типа 2, типа 3 и типа 4 соответственно. Значения 5-7 зарезервированы для использования с альтернативными обозначениями режимов по желанию.

N. Для пакетов Perform Type Handoff

1-байтовое поле Interface Type указывает новый тип интерфейса для использования. Значение, присутствующее в этом поле, указывает тип интерфейса, причем сначала используется значение бита 7 для определения, предназначен ли переход типа для прямой или обратной линии связи. Значение ‘0’ указывает, что запрос изменения типа предназначен для прямой линии связи, а значение ‘1’ указывает, что запрос изменения типа предназначен для обратной линии связи. Биты с 6-го по 3-й зарезервированы для использования в будущем и поэтому заданы равными нулю. Однако биты со 2-го по 0-й используются для задания типа интерфейса для использования, при этом значения 1, 2, 3 и 4 указывают использование перехода в режимы типа 1, типа 2, типа 3 и типа 4 соответственно. Значения 0 и 5-7 этих битов зарезервированы для использования в будущем.

O. Для пакетов Forward Audio Channel Enable

Поле Audio Channel Enable Mask (1 байт) содержит группу флагов, которые указывают, какие аудиоканалы должны быть включены на клиенте. Бит, заданный равным единице, включает соответствующий канал, и бит, заданный равным нулю, отключает соответствующий канал. Биты с 0-го по 5-й обозначают каналы с 0-го по 5-й, которые соответствуют левому переднему, правому переднему, левому заднему, правому заднему, левому заднему, переднему центральному каналу и сабвуферу соответственно. Биты 6 и 7 зарезервированы для использования в будущем и в настоящее время обычно заданы равными нулю.

P. Для пакетов Reverse Audio Sample Rate

Поле Audio Sample Rate (1 байт) указывает частоту дискретизации цифрового аудиосигнала. Значения этого поля присвоены различным частотам, причем значения 0, 1, 2, 3, 4, 5, 6, 7 и 8 используются для обозначения 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050 и 44100 выборок в секунду (SPS) соответственно, и значения 9-254 зарезервированы для использования с альтернативными частотами по желанию, поэтому в настоящее время они заданы равными ‘0’. Значение 255 используется для отключения аудиопотока обратной линии связи.

Поле Sample Format (1 байт) указывает формат выборок цифрового аудиосигнала. Когда биты [1:0] равны ‘0’, выборки цифрового аудиосигнала находятся в линейном формате, когда они равны 1, выборки цифрового аудиосигнала находятся в формате -закона, а когда они равны 2, выборки цифрового аудиосигнала находятся в формате А-закона. Биты [7:2] зарезервированы для альтернативного использования при обозначении аудиоформатов, по желанию, и обычно заданы равными нулю.

Q. Для пакетов Digital Content Protection Overhead

Поле Content Protection Type (1 байт) указывает используемый метод защиты цифрового контента. Значение ‘0’ указывает Digital Transmission Content Protection (DTCP), а значение 1 указывает High-bandwidth Digital Content Protection System (HDCP). Диапазон значений 2-255 в настоящее время не задан, но зарезервирован для использования с альтернативными схемами защиты по желанию. Поле Content Protection Overhead Messages – это поле переменной длины, содержащее сообщения защиты контента, передаваемыми между хостом и клиентом.

R. Для пакетов Transparent Color Enable

Поле Transparent Color Enable (1 байт) указывает, включен или отключен режим прозрачного цвета. Если бит 0 равен 0, значит, режим прозрачного цвета отключен, а если он равен 1, значит, режим прозрачного цвета включен, и прозрачный цвет задается следующими двумя параметрами. Биты с 1-го по 7-й зарезервированы для использования в будущем и обычно заданны равными нулю.

Поле Video Data Format Descriptor (2 байта) указывает формат параметра Pixel Area Fill Value. На фиг.11 показано, как кодируется Video Data Format Descriptor. Формат в общем случае такой же, как у такого же поля в пакете Video Stream Packet.

Поле Pixel Area Fill Value использует 4 байта, выделенных для значения пикселя для заполнения указанного выше окна. Формат этого пикселя задан в поле Video Data Format Descriptor.

S. Для пакетов Round Trip Delay Measurement

2-байтовое поле Packet Length указывает полное количество байтов в пакете, не включая поле длины пакета и согласно одному варианту осуществления выбирается так, чтобы иметь фиксированную длину 159. 2-байтовое поле Packet Type, которое указывает этот тип пакета с помощью значения 82, идентифицирует пакет как пакет Round Trip Delay Measurement Packet. Поле hClient ID, как указано выше, зарезервировано для использования в будущем в качестве ID клиента и в общем случае задано равным нулю.

Согласно одному варианту осуществления поле Parameter CRC (2 байта) содержит 16-битовый CRC всех байтов от поля Packet Length до поля Packet Type. Если этот контроль CRC не проходит, то весь пакет отбрасывается.

Поле Guard Time 1 (здесь, 64 байта) используется, чтобы драйверы линии MDDI_DATA на клиенте могли включиться до отключения драйверов линии на хосте. Клиент включает свои драйверы линии MDDI_DATA в течение бита 0 поля Guard Time 1, и хост отключает свои драйверы линии, чтобы они были полностью отключены до последнего бита поля Guard Time 1. Хост и клиент переходят на уровень логического нуля в течение Guard Time 1, когда они не отключены. Другая цель этого поля состоит в том, чтобы гарантировать, что все сигналы MDDI_Data находятся на уровне логического нуля в течение достаточного времени, чтобы клиент мог начать восстановление тактового сигнала с использованием только MDDI_Stb до отключения драйверов линии хоста.

Поле Measurement Period это 64-байтовое окно, используемое для того, чтобы клиент мог ответить посредством двух байтов 0xff и 30 байтов 0x0 на половине скорости передачи данных, используемых на прямой линии связи. Эта скорость передачи данных соответствует значению Reverse Link Rate Divisor, равному 1. Клиент возвращает свой ответ, как только воспринимает начало поля Measurement Period. Этот ответ от клиента будет принят на хосте с точностью до двусторонней задержки линии связи плюс задержка логики на клиенте после начала первого бита поля Measurement Period на хосте.

Поле All Zero 1 (2 байта) содержит нули, чтобы драйверы линии MDDI_DATA на хосте и клиенте могли перекрываться и, таким образом, линия MDDI_Data всегда была возбуждена. Хост включает драйверы линии MDDI_DATA в течение бита 0 поля Guard Time 2, и клиент также переводин сигнал на уровень логического нуля, как он делал в конце поля Measurement Period.

Значение поля Guard Time 2 (64 байта) допускает перекрытие поля Measurement Period, возбуждаемого клиентом, когда двусторонняя задержка имеет максимальную величину, которая может быть измерена в течение периода измерения. Клиент отключает свои драйверы линии в течение бита 0 поля Guard Time 2, и хост включает свои драйверы линии сразу после последнего бита поля Guard Time 2. Хост и клиент переходят на уровень логического нуля в течение Guard Time 2, когда они не отключены. Другая цель этого поля состоит в том, чтобы гарантировать, что все сигналы MDDI_Data находятся на уровне логического нуля в течение достаточного времени, чтобы клиент мог начать восстановление тактового сигнала с использованием MDDI_Data0 и MDDI_Stb после включения драйверов линии на хосте.

T. Для пакетов Forward Link Skew Calibration

Согласно одному варианту осуществления поле Parameter CRC (2 байта) содержит 16-битовый CRC всех байтов от поля Packet Length до поля Packet Type. Если этот контроль CRC не проходит, то весь пакет отбрасывается.

Поле All Zero 1 использует 1 байт, чтобы гарантировать, что на линии MDDI_Stb будут переходы в конце поля Parameter CRC.

Поле Calibration Data Sequence содержит последовательность данных, которая заставляет сигналы MDDI_Data переключаться в каждый период данных. Длина поля Calibration Data Sequence определяется интерфейсом, используемым на прямой линии связи. В ходе обработки поля Calibration Data Sequence контроллер хоста MDDI передает все сигналы MDDI_Data, равные стробирующему сигналу. Схема восстановления тактового сигнала клиента должна использовать только MDDI_Stb, а не MDDI_Stb Xor MDDI_Data0 для восстановления тактового сигнала данных, когда поле Calibration Data Sequence поступает на дисплей клиента. В зависимости от конкретной фазы сигнала MDDI_Stb в начале поля Calibration Data Sequence последовательность калибровочных данных будет иметь следующий вид в зависимости от типа интерфейса, используемого при передаче пакета:

Тип I – (64-байтовая последовательность данных) 0xaa, 0xaa… или 0x55, 0x55…

Тип II – (128-байтовая последовательность данных) 0xcc, 0xcc… или 0x33, 0x33…

Тип III -(256-байтовая последовательность данных) 0xf0, 0xf0… или 0x0f, 0x0f…

Тип IV – (512-байтовая последовательность данных) 0xff, 0x00, 0xff, 0x00… или 0x00, 0xff, 0x00, 0xff…

Примеры возможных форм волны сигналов MDDI_Data и MDDI_Stb для интерфейсов типа 1 и типа 2 показаны на фиг.62A и 62B соответственно.

XVII. Заключение

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

Формула изобретения

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

2. Способ по п.1, в котором упомянутый первый заданный диапазон циклов строба содержит от ста сорока пяти до ста пятидесяти пяти циклов строба.

3. Способ по п.1, в котором упомянутый второй заданный диапазон циклов строба содержит от сорока до шестидесяти циклов строба.

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

5. Система по п.4, в котором упомянутый первый заданный диапазон циклов строба содержит от ста сорока пяти до ста пятидесяти пяти циклов строба.

6. Система по п.4, в котором упомянутый второй заданный диапазон циклов строба содержит от сорока до шестидесяти циклов строба.

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

8. Машиночитаемый носитель по п.7, причем упомянутый первый заданный диапазон циклов строба содержит от ста сорока пяти до ста пятидесяти пяти циклов строба.

9. Машиночитаемый носитель по п.7, причем упомянутый второй заданный диапазон циклов строба содержит от сорока до шестидесяти циклов строба.

10. Способ добавления поля статуса клиента в пакет Client Request and Status системы мобильного интерфейса передачи цифровых данных (MDDI), при этом способ содержит этапы, на которых: обеспечивают бит Возможности Клиента в поле статуса клиента для индикации того, изменилось ли клиентское устройство с момента последней передачи пакета Client Request and Status, причем данный этап содержит обеспечение первого индикатора изменения в клиентском устройстве и второго индикатора отсутствия изменений в клиентском устройстве; и обеспечивают бит Ошибка Обработки в поле статуса клиента для индикации того, была ли обнаружена ошибка при обработке принятого пакета клиентским устройством устройство с момента последней передачи пакета Client Request and Status.

11. Способ по п.10, в котором поле статуса клиента для индикации того, изменилось ли клиентское устройство, содержит поле статуса клиента для индикации того, изменилось ли по меньшей мере одна возможность клиентского устройства.

12. Система для добавления поля статуса клиента в пакет Client Request and Status системы мобильного интерфейса передачи цифровых данных (MDDI), содержащая: средство обеспечения бита Возможности Клиента в поле статуса клиента для индикации того, изменилось ли клиентское устройство с момента последней передачи пакета Client Request and Status, причем данный этап содержит обеспечение первого индикатора изменения в клиентском устройстве и второго индикатора отсутствия изменений в клиентском устройстве; и средство обеспечения бита Ошибка Обработки в поле статуса клиента для индикации того, была ли обнаружена ошибка при обработке принятого пакета клиентским устройством устройство с момента последней передачи пакета Client Request and Status.

13. Система по п.12, в которой поле статуса клиента для индикации того, изменилось ли клиентское устройство, содержит поле статуса клиента для индикации того, изменилось ли по меньшей мере одна возможность клиентского устройства.

14. Машиночитаемый носитель, содержащий инструкции, которые при выполнении их компьютером приводят к реализации способа добавления поля статуса клиента в пакет Client Request and Status системы мобильного интерфейса передачи цифровых данных (MDDI), при этом упомянутые инструкции включают в себя: инструкции для включения бита Возможности Клиента в поле статуса клиента для индикации того, изменилось ли клиентское устройство с момента последней передачи пакета Client Request and Status, причем данный этап содержит обеспечение первого индикатора изменения в клиентском устройстве и второго индикатора отсутствия изменений в клиентском устройстве; инструкции для включения бита Ошибка Обработки в поле статуса клиента для индикации того, была ли обнаружена ошибка при обработке принятого пакета клиентским устройством устройство с момента последней передачи пакета Client Request and Status.

15. Машиночитаемый носитель по п.14, причем поле статуса клиента для индикации того, изменилось ли клиентское устройство, содержит поле статуса клиента для индикации того, изменилось ли по меньшей мере одна возможность клиентского устройства.

РИСУНКИ