Перекрестные ссылки на родственные заявки
Настоящая заявка на патент претендует на приоритет по отношению к предварительной заявке № 60/502056 «Switchable Threshold Differential Interface», поданной 10 сентября 2003 года, права на которую принадлежат заявителю настоящего изобретения и содержание которой специально включено сюда по ссылке.
Область техники, к которой относится изобретение
Варианты осуществления изобретения в этом описании относятся к протоколу и процессу обработки цифровых сигналов для передачи или пересылки сигналов между хост-устройством и клиентским устройством высокоскоростными передачами данных. В частности, здесь раскрыт способ пересылки мультимедийных цифровых сигналов и сигналов других типов от хост-устройства или управляющего устройства на клиентское устройство для представления или отображения их конечному пользователю с использованием потребляющего малую мощность механизма пересылки высокоскоростной передачи данных, имеющего внутренние и внешние приложения для устройств.
Уровень техники
За последние несколько лет достигнуты значительные успехи в сфере компьютеров, продуктов, относящихся к электронным играм, и в сфере различных видеотехнологий (например, видеомагнитофоны (VCR) для дисков DVD и видеомагнитофоны высокой четкости) для обеспечения представления конечным пользователям указанного оборудования неподвижных изображений, видеоизображений, «видео по запросу» и графических изображений с все более высоким разрешением при включении в них текста определенных типов. В свою очередь, эти достижения открыли возможность использования электронных просмотровых устройств с более высоким разрешением, таких как видеомониторы высокой четкости, телевизионные мониторы высокой четкости (HDTV) или специализированные элементы для проецирования изображений. Для создания более реалистичного, содержательного или правильного восприятия мультимедийного продукта у конечного пользователя используется комбинирование указанных визуальных изображений с аудиоданными высокой четкости или высокого качества, например, при использовании устройств для воспроизведения звука с компакт-дисков типа CD, DVD, устройств воспроизведения объемного звука и других устройств, имеющих также соответствующие выходы для аудиосигналов. Вдобавок разработаны высокомобильные высококачественные аудиосистемы и механизмы передачи музыки, такие как MP3 плееры, для представления конечному пользователю только звука. Это привело к тому, что у обычных пользователей коммерческих электронных устройств, от компьютеров до телевизоров и даже телефонов, появились повышенные ожидания, поскольку они привыкли к высокому, а то и к высочайшему качеству выходного продукта.
В типовом сценарии представления видео, затрагивающем радиоэлектронную аппаратуру, видеоданные обычно пересылаются с использованием существующих технологий со скоростью, которая может быть лучше всего определена термином «низкая» или «средняя», то есть порядка от единиц до десятков килобит в секунду. Затем эти данные буферизируются или запоминаются в устройствах временной или долговременной памяти для их воспроизведения с задержкой (позднее) на желаемом просмотровом устройстве. Например, изображения могут пересылаться напрямую или с использованием сети Интернет с помощью программы, находящейся в компьютере, который имеет модем или устройство другого типа для подсоединения к сети Интернет для приема или передачи данных, пригодное для цифрового представления изображения. Аналогичную пересылку можно выполнить, используя беспроводные устройства, такие как портативные компьютеры, оборудованные беспроводными модемами, беспроводные персональные цифровые секретари (PDA) или беспроводные телефоны.
Как только данные приняты, они запоминаются локально в элементах, схемах или устройствах памяти, таких как ОЗУ или флэш-память, в том числе во внутренних или внешних запоминающих устройствах, таких как малогабаритные накопители на жестком диске, для последующего воспроизведения. В зависимости от объема данных и разрешающей способности изображения воспроизведение может начаться с относительно небольшой или с более длительной задержкой. То есть в некоторых случаях представление изображений открывает возможность воспроизведения до некоторой степени в реальном времени для изображений с очень малым или низким разрешением, когда не требуется большой объем данных, или с использованием буферизации того или иного типа, когда некоторая часть материала представляется с небольшой задержкой, а параллельно продолжается пересылка другого материала. Если в линии связи, используемой при пересылке, отсутствует прерывание или помехи от других систем или пользователей, связанных с используемым каналом пересылки, то, как только начинается представление данных, пересылка становится вполне прозрачной для конечного пользователя просмотрового устройства. Естественно, что при совместном использовании единого канала связи многими пользователями, например проводного соединения Интернет, пересылки могут прерываться или осуществляться медленнее, чем бы хотелось.
Данные, используемые для создания неподвижных изображений или движущихся видеоизображений, часто сжимают, используя одну из нескольких известных технологий, таких как технологии, определенные стандартом Объединенной группы экспертов по машинной обработке фотографических изображений (JPEG), стандартом экспертной группой по вопросам движущегося изображения (MPEG) и стандартами других известных организаций или компаний, занимающихся стандартизацией в медийной и компьютерной индустрии, а также индустрии связи, для ускорения пересылки данных по линии связи. Эти стандарты позволяют пересылать изображения или данные быстрее, используя меньшее количество бит для пересылки данного количества информации.
Как только осуществлена пересылка данных на «локальное» устройство, такое как компьютер, имеющий запоминающий механизм, такой как память или магнитные или оптические запоминающие элементы, или на другие приемные устройства, результирующая информация распаковывается (или воспроизводится с использованием специальных декодирующих плееров), декодируется, если это необходимо, и готовится для адекватного представления на основе соответствующей доступной разрешающей способности и имеющихся управляющих элементов. Например, разрешение типового компьютерного видео в единицах разрешения экрана Х на Y пикселей обычно составляет от 480×640 пикселей, 600×800 пикселей и до 1024×1024 пикселей, хотя в общем случае возможно множество других значений разрешения по желанию либо по мере необходимости.
На представление изображения также влияет контент изображения, а также способность данных видеоконтроллеров манипулировать изображением с точки зрения некоторых заранее установленных цветовых уровней или глубины цвета (бит на пиксель, используемых для создания цветов) и интенсивностей, а также любых используемых дополнительных служебных битов. Например, типовое компьютерное представление предполагает использование от 8 до 32 или более бит на пиксель для представления различных цветов (теней и оттенков), хотя встречаются и другие значения.
Исходя из вышеуказанных значений понятно, что данное экранное изображение потребует пересылки примерно от 2,45 Мегабит (Мбит) до 33,50 Мбит данных в диапазоне типовых значений разрешающей способности и глубины от минимального до максимального значения соответственно. При просмотре видео или движущихся изображений со скоростью 30 кадров в секунду требуемое количество данных составит примерно от 73,7 до 1006 Мегабит в секунду (Мбит/с) или примерно от 9,21 до 125,75 Мегабайт в секунду (Мбайт/с). Вдобавок вместе с изображениями может потребоваться представление аудиоданных, например, при мультимедийном представлении, или отдельное представление аудиоданных с высоким разрешением, как, например, при воспроизведении высококачественной музыки на CD. Также могут быть использованы дополнительные сигналы, связанные с интерактивными командами, управляющими командами или сигналами. Каждая из этих опций еще более увеличивает количество данных, подлежащих пересылке. Кроме того, новейшие технологии передачи, в том числе телевидение высокой четкости (HD) и записи кинофильмов, могут потребовать дополнительного увеличения объема данных и управляющей информации. В любом случае, если требуется переслать данные изображений с высоким качеством или высоким разрешением, а также сигналы, несущие высококачественную аудиоинформацию или аудиоданные, то для обеспечения высококачественного восприятия этих данных конечным пользователем между элементами представления и источником или хост-устройством, которое выполнено с возможностью обеспечения данных указанных типов, потребуется линия связи для высокоскоростной пересылки данных.
Ряд современных последовательных интерфейсов способны выполнять обработку со скоростями передачи данных порядка 115 килобайт в секунду (Кбайт/с) или 920 килобит в секунду (Кбит/с). Другие интерфейсы, такие как последовательные интерфейсы USB, могут пересылать данные со скоростями до 12 Мбайт/с, а также могут выполнять специальные высокоскоростные пересылки, например сконфигурированные с использованием Стандарта 1394 Института инженеров по электротехнике и электронике (IEEE), со скоростями примерно от 100 до 400 Мбайт/с. К сожалению, эти скорости не соответствуют желаемым высокоскоростным передачам данных, обсужденным выше, которые предполагается использовать с будущими беспроводными устройствами передачи данных и для других услуг, обеспечивающих содержательные выходные сигналы с высоким разрешением, которые приводят в действие портативные видеодисплеи или аудиоустройства. Сюда относятся компьютеры для деловых операций и других представлений, игровые устройства и т.д. Вдобавок эти интерфейсы для своей работы требуют использования значительного объема программных средств хоста или системы, а также клиента. Стеки протоколов также создают недопустимо большой объем служебной информации, особенно если речь идет о мобильных беспроводных устройствах или телефонных приложениях. Указанные устройства имеют серьезные ограничения на объем памяти и потребляемую мощность, если учесть, что вычислительные возможности уже практически исчерпаны. Кроме того, некоторые из этих интерфейсов используют громоздкие кабели, которые слишком тяжелы и не подходят для мобильных приложений, ориентированных на высокий эстетический уровень, а также сложные разъемы, которые повышают стоимость, или просто потребляют слишком большую мощность.
Имеются и другие известные интерфейсы, такие как аналоговый видеографический адаптер (VGA), интерактивное цифровое видео (DVI) или гигабитный видеоинтерфейс (GVIF). Первые два из них являются интерфейсами параллельного типа, которые обрабатывают данные с более высокими скоростями пересылки, но в них также используются тяжелые кабели и потребляется большая мощность, порядка нескольких ватт. Ни одна из этих характеристик не подходит для использования с портативными пользовательскими электронными устройствами. Даже третий интерфейс потребляет слишком большую мощность и использует дорогие или громоздкие разъемы.
У некоторых из вышеуказанных интерфейсов и других систем/протоколов для высокоскоростной передачи данных или механизмов пересылки, связанных с пересылками данных для стационарно установленного компьютерного оборудования, имеется еще один главный недостаток. Для обеспечения желаемых скоростей пересылки данных требуется значительная мощность и/или работа с большими значениями тока. Это значительно снижает пригодность указанных технологий для изделий, ориентированных на высокомобильного пользователя.
В общем случае для приспособления к указанным скоростям пересылки данных с использованием таких альтернатив, как оптоволоконные соединения и элементы, также потребуется ряд дополнительных преобразователей и элементов, которые значительно усложнят систему и увеличат ее стоимость, что совершенно нежелательно для продукта, действительно ориентированного на массового потребителя. Помимо высокой стоимости, присущей в общем случае современным оптическим системам, их требования к мощности и сложность препятствуют их широкому использованию для легких маломощных портативных прикладных систем.
Чего не хватает в индустрии портативных, беспроводных или мобильных приложений, так это технологии, обеспечивающей высокомобильным конечным пользователям высококачественное представление, будь то на основе аудио, видео или мультимедийного продукта. То есть при использовании портативных компьютеров, беспроводных телефонов, PDA или других высокомобильных устройств или оборудования связи современные системы или устройства представления видео- и аудиоданных просто не могут обеспечить выходной сигнал на желаемом высококачественном уровне. Часто недостаток качества восприятия является результатом того, что невозможно обеспечить скорости передачи данных, необходимые для пересылки данных для высококачественного представления. Это может относиться к пересылке данных на более эффективные, продвинутые или функционально насыщенные внешние устройства для их представления конечному пользователю или к пересылке между хостами и клиентскими устройствами, являющимися внутренними по отношению к портативным устройствам, таким как компьютеры, игровые автоматы, и беспроводными устройствами, такими как мобильные телефоны.
В последнем случае достигнут большой прогресс в повышении разрешающей способности внутренних видеоэкранов и других специализированных устройств ввода и/или вывода, а также соединений с беспроводными устройствами, подобными телефонам так называемого третьего поколения, и так называемым компьютерам типа «лэптоп». Однако внутренние шины данных и соединения, которые могут включать в себя установку соединения через поворачивающиеся или скользящие шарнирные или шарнирно-образные конструкции, которые поддерживают или соединяют видеоэкраны или другие элементы с основным корпусом, где находятся хост и/или различные другие управляющие элементы и выходные компоненты. Очень трудно построить интерфейсы для пересылки данных с высокой пропускной способностью, используя известные способы, в которых для достижения желаемой пропускной способности может потребоваться до 90 или более проводников, например, в беспроводном телефоне. Это порождает множество проблем, связанных с изготовлением, недопустимо высокими затратами и надежностью, которые требуют своего решения.
Указанные проблемы и требования также характерны и для стационарных установок, где коммуникационные или вычислительные устройства сопрягаются, например, с бытовой техникой и другими бытовыми устройствами для обеспечения расширенных возможностей обработки данных, Интернет-соединений и соединений для пересылки данных или для встроенной развлекательной среды. В качестве другого примера можно привести самолеты и автобусы, где экраны для индивидуального представления видео и аудио смонтированы на спинках сидений. Однако в этих случаях часто бывает, что удобнее, эффективнее и легче с точки зрения обслуживания, чтобы основные управляющие элементы, выполняющие функции памяти, обработки и связи, находились на расстоянии от видимых экранов или аудиовыходов при обеспечении соединительной линии связи или канала для представления информации. Эта линия связи необходима для обработки значительного объема данных, чтобы обеспечить желаемую пропускную способность, как обсуждалось выше.
Таким образом, необходим новый механизм пересылки для увеличения пропускной способности при пересылке данных между хост-устройствами, обеспечивающими эти данные, и клиентскими устройствами или элементами отображения, представляющими выходной продукт конечным пользователям.
Заявители предложили такие новые механизмы пересылки в акцептованных патентных заявках США № 10/020520 и № 10/236657 «Generating And Implementing A Communication Protocol аnd Interface For High Data Rate Signal Transfer», права на которые принадлежат заявителю настоящего изобретения и содержание которых включено сюда по ссылке. Также имеется заявка № 10/860116 «Generating and Implementing a Signal Protocol and Interface for Higher Data Rates». Способы, обсужденные в этих заявках, могут значительно увеличить скорость пересылки больших объемов данных в сигналах высокоскоростной передачи данных. Однако потребности в постоянно растущих скоростях передачи данных, особенно когда это касается представления видеоданных, продолжают расти. Даже применительно к другим действующим разработкам все еще необходимо добиваться более высоких скоростей пересылки, повышать эффективность линий связи и их мощность. Следовательно, не отпала необходимость в разработке нового или улучшенного механизма пересылки, необходимого для увеличения пропускной способности при передаче данных между хост-устройствами и клиентскими устройствами.
Сущность изобретения
Варианты осуществления изобретения нацелены на устранение вышеуказанного и других недостатков, присущих современному уровню техники, причем в этих вариантах предложены новое средство, способ и механизм протоколирования и пересылки данных для пересылки данных между хост-устройством и приемным клиентским устройством с высокоскоростными передачами данных.
Варианты изобретения направлены на создание мобильного интерфейса цифровых данных (MDDI) для высокоскоростной пересылки цифровых данных между хост-устройством и клиентским устройством по каналу связи, который использует множество или ряд пакетных структур, связанных вместе для формирования коммуникационного протокола для передачи предварительно выбранного набора цифровых данных управления и представления между хост-устройством и клиентским устройством. Сигнальный коммуникационный протокол или канальный уровень используется физическим уровнем контроллеров линии связи хоста или клиента. По меньшей мере один контроллер линии, находящийся в хост-устройстве, соединен с клиентским устройством через канал или линию связи и выполнен с возможностью создания, передачи и приема пакетов, формирующих коммуникационный протокол, и для формирования цифровых данных представления в пакетах данных одного или нескольких типов. Интерфейс обеспечивает двунаправленную пересылку информации между хостом и клиентом, который может находиться в общей конструкции, выполняющей функцию корпуса или опорной конструкции.
Обычно все это реализуется в цифровом виде за исключением дифференциальных драйверов и приемников, которые можно легко реализовать на цифровой КМОП-микросхеме, причем для этого потребуется всего 6 сигналов, причем функционирование может происходить практически с любой скоростью передачи данных, которая удобна для разработчика системы. Простой протокол физического и канального уровня облегчает интеграцию, и такое простое решение плюс наличие состояния бездействия позволяет получить портативную систему с очень низким энергопотреблением.
Принятию и использованию этого интерфейса способствует то, что он незначительно повышает стоимость устройства, потребляет очень мало мощности при возможности питания дисплеев через этот же интерфейс с использованием стандартных напряжений батарей и может быть приспособлен к устройствам, имеющим форм-фактор, подходящий для карманного варианта. Интерфейс имеет возможность масштабирования для поддержания значений разрешения сверх разрешения HDTV, он поддерживает одновременно стерео, видео и аудио 7.1 для устройства отображения, выполняет условные обновления для любой области экрана и поддерживает множество типов данных в обоих направлениях.
Согласно дополнительным аспектам вариантов изобретения по меньшей мере один клиентский контроллер или клиентский приемник линии связи расположен в клиентском устройстве и соединен с хост-устройством через канал или линию связи. Клиентский контроллер линии связи также выполнен с возможностью создания, передачи и приема пакетов, формирующих коммуникационный протокол, и формирования цифровых данных представления в пакетах данных одного или нескольких типов. В общем случае хост-контроллер или контроллер линии связи использует конечный автомат для обработки пакетов данных, используемых в командах, или подготовки сигнала и обработки запросов определенных типов, но может использовать более медленный процессор общего назначения для манипулирования данными и рядом менее сложных пакетов, используемых в коммуникационном протоколе. Хост-контроллер содержит один или несколько дифференциальных драйверов линии, в то время как клиентский приемник содержит один или несколько дифференциальных приемников линии, соединенных с каналом связи.
Пакеты группируют вместе в медиакадры, которые передаются между хост-устройством и клиентским устройством, причем они имеют заранее определенную фиксированную длину с заранее определенным количеством пакетов, имеющих разную переменную длину. Каждый из пакетов содержит поле длины пакета, одно или несколько полей пакетных данных и поле контроля с помощью циклического избыточного кода. Пакет заголовка субкадра пересылается или позиционируется в начале пересылок других пакетов хост-контроллера линии связи. Один или несколько пакетов типа видеопоток и пакетов типа аудиопоток используются коммуникационным протоколом для пересылки данных типа видео и данных типа аудио соответственно от хоста к клиенту по прямой линии связи для представления пользователю клиентского устройства. Один или несколько пакетов типа инкапсуляция обратной линии связи используется коммуникационным протоколом для пересылки данных от клиентского устройства на хост-контроллер линии связи. Эти пересылки в некоторых вариантах включают в себя пересылку данных от внутренних контроллеров, имеющих по меньшей мере одно устройство MDDI, на внутренние видеоэкраны. Другие варианты включают в себя пересылку на внутренние акустические системы и пересылки от различных устройств ввода, включая джойстики и комплексные клавиатуры для внутренних хост-устройств.
Пакеты типа заполнитель создаются хост-контроллером линии связи для занятия периодов передачи по прямой линии связи, которые не содержат данных. Для пересылки видеоинформации коммуникационный протокол использует множество других пакетов. Такие пакеты включают в себя пакеты типа цветовая карта, пересылка блока бит, заполнение областей битовой карты, заполнение шаблона битовой карты и разрешение прозрачного цвета. Пакеты типа поток, определенный пользователем, используются коммуникационным протоколом для пересылки данных, определенных пользователем интерфейса. Для пересылки данных на или от устройств ввода пользователя, связанных с клиентским устройством, коммуникационный протокол использует пакеты типа данные клавиатуры и данные указательного устройства. Для завершения пересылки данных по каналу связи в любом направлении коммуникационный протокол использует пакет типа отключение линии связи.
Канал связи обычно содержит или использует кабель, имеющий набор из четырех или более проводников, а также экран. Вдобавок можно использовать, если это необходимо, печатные провода или проводники, причем некоторые из них находятся на гибких подложках.
Хост-контроллер линии связи запрашивает информацию о возможностях отображения у клиентского устройства, чтобы определить, какой тип данных и какие скорости передачи данных способен обеспечить клиент через указанный интерфейс. Контроллер линии связи клиента передает на хост-контроллер линии связи информацию о возможностях отображения или представления, используя по меньшей мере один пакет типа возможности клиента. Коммуникационный протокол использует множество режимов пересылки, причем каждый из них допускает пересылку различных максимальных количеств битов данных одновременно в течение заданного периода времени, при этом каждый режим можно выбрать путем согласования между контроллером линии связи хоста и контроллером линии связи клиента. Эти режимы пересылки динамически настраиваются во время пересылки данных, причем в обратной линии связи не обязательно использовать тот же режим, который используется в прямой линии связи.
Согласно другим аспектам некоторых вариантов изобретения хост-устройство содержит устройство беспроводной связи, такое как беспроводный телефон, беспроводный PDA или портативный компьютер с размещенным в нем беспроводным модемом. Типовое клиентское устройство содержит портативный видеодисплей, например микродисплейное устройство, и/или портативную систему представления аудиоданных. Кроме того, хост может использовать средства или элементы памяти для запоминания данных представления или мультимедийных данных, подлежащих пересылке для представления пользователю клиентского устройства.
Согласно еще одним аспектам некоторых вариантов изобретения хост-устройство содержит контроллер или управляющее устройство линии связи с драйверами, описанными ниже, которые находятся в портативном электронном устройстве, таком как устройство беспроводной связи, например беспроводный телефон, беспроводный PDA или портативный компьютер. В этой конфигурации типовое клиентское устройство содержит клиентскую схему, или интегральную схему, или модуль, соединенный с хостом и находящийся в том же устройстве и связанный с внутренним видеодисплеем, таким как экран с высоким разрешением для мобильного телефона, и/или портативная система представления аудиоданных, или в системе или устройстве ввода некоторого альтернативного типа.
Краткое описание чертежей
Далее со ссылками на сопроводительные чертежи подробно описаны дополнительные признаки и преимущества изобретения, а также структура и функционирование различных вариантов изобретения. На этих чертежах одинаковые ссылочные позиции обычно указывают на идентичные, функционально подобные и/или структурно подобные элементы или этапы обработки, а чертеж, на котором элемент появляется впервые, указывается крайней левой значащей цифрой (цифрами) в ссылочной позиции.
Фиг.1А - базовая среда, в которой могут функционировать варианты изобретения, включая использование микродисплейного устройства или проектора в сочетании с портативным компьютером или другим устройством обработки данных;
Фиг.1В - базовая среда, в которой могут функционировать варианты изобретения, включая использование микродисплейного устройства или проектора и элементы аудиопредставления, используемые в сочетании с беспроводным приемопередатчиком;
Фиг.1С - базовая среда, в которой могут функционировать варианты изобретения, включая использование внутренних устройств отображения или аудиопредставления, используемых в портативном компьютере;
Фиг.1D - базовая среда, в которой могут функционировать варианты изобретения, включая использование внутренних элементов отображения или аудиопредставления, используемых в беспроводном приемопередатчике;
Фиг.2 - иллюстрация общей концепции мобильного интерфейса цифровых данных (MDDI) с соединениями между хостом и клиентом;
Фиг.3 - иллюстрация структуры пакета, полезного для реализации пересылок данных от клиентского устройства на хост-устройство;
Фиг.4 - иллюстрация использования контроллера линии связи MDDI и типов сигналов, передаваемых между хостом и клиентом по проводникам физической линии связи для передачи данных для интерфейса типа 1;
Фиг.5 - иллюстрация использования контроллера линии связи MDDI и типов сигналов, проходящих между хостом и клиентом по проводникам физической линии связи для передачи данных для интерфейсов типов 2,3 и 4;
Фиг.6 - иллюстрация структуры кадров и субкадров, используемых для реализации протокола интерфейса;
Фиг.7 - иллюстрация общей структуры пакетов, используемых для реализации протокола интерфейса;
Фиг.8 - иллюстрация формата пакета заголовка субкадра;
Фиг.9 - иллюстрация формата и контента пакета заполнителя;
Фиг.10 - иллюстрация формата пакета видеопотока;
Фиг.11А-11Е - иллюстрации формата и контента для дескриптора формата видеоданных, использованного на фиг.10;
Фиг.12 - иллюстрация использования упакованных и неупакованных форматов для данных;
Фиг.13 - иллюстрация формата пакета аудиопотока;
Фиг.14 - иллюстрация использования формата с байтовым выравниванием и упакованного формата PCM для данных;
Фиг.15 - иллюстрация формата пакета потока, определенного пользователем;
Фиг.16 - иллюстрация формата пакета цветовой карты;
Фиг.17 - иллюстрация формата пакета инкапсуляции обратной линии связи;
Фиг.18 - иллюстрация формата пакета возможностей клиента;
Фиг.19 - иллюстрация формата пакета данных клавиатуры;
Фиг.20 - иллюстрация формата пакета данных указательного устройства;
Фиг.21 - иллюстрация формата пакета отключения линии связи;
Фиг.22 - иллюстрация формата пакета клиентского запроса и состояния;
Фиг.23 - иллюстрация формата пакета пересылки блока бит;
Фиг.24 - иллюстрация формата пакета заполнения области битовой карты;
Фиг.25 - иллюстрация формата пакета заполнения шаблона битовой карты;
Фиг.26 - иллюстрация формата пакета канала данных линии связи;
Фиг.27 - иллюстрация формата пакета запроса на переключение типа интерфейса;
Фиг.28 - иллюстрация формата пакета подтверждения типа интерфейса;
Фиг.29 - иллюстрация формата пакета переключения типа исполнения;
Фиг.30 - иллюстрация формата пакета разблокирования прямого аудиоканала;
Фиг.31 - иллюстрация формата пакета частоты выборки обратного аудиосигнала;
Фиг.32 - иллюстрация формата пакета служебных данных для защиты цифрового контента;
Фиг.33 - иллюстрация формата пакета разблокирования прозрачного цвета;
Фиг.34 - иллюстрация формата пакета измерения задержки передачи в прямом и обратном направлениях;
Фиг.35 - временная диаграмма событий при прохождении пакета измерения задержки при передаче в прямом и обратном направлениях;
Фиг.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 - графическое представление значений делителя скорости в обратной линии связи в функции скорости передачи данных по прямой линии связи;
Фиг.54А и 54В - этапы, выполняемые при работе интерфейса;
Фиг.55 - общий вид устройства интерфейса, обрабатывающего пакеты;
Фиг.56 - иллюстрация формата пакета прямой линии связи;
Фиг.57 - типовые значения для задержки распространения и асимметрии в интерфейсе линии связи типа 1;
Фиг.58 - временные диаграммы для данных, стробирующих импульсов (STB) и восстановления тактовых импульсов в линии связи типа 1 для примерной обработки сигналов через интерфейс;
Фиг.59 - типовые значения для задержки распространения и асимметрии в интерфейсах линии связи типа 2, типа 3 или типа 4;
Фиг.60А, 60В и 60С - иллюстрации различных возможных вариантов временных диаграмм двух сигналов данных и сигналов MDDI_Stb друг относительно друга для идеального случая, а также при запоздалом и преждевременном поступлении соответственно;
Фиг.61 - примеры интерфейсных разъемов, используемых с интерфейсами типа 1/типа 2, с распределением контактов по линиям;
Фиг.62А и 62В - возможные временные диаграммы сигналов MDDI_Data и DDI_Stb для интерфейсов типа 1 и типа 2 соответственно;
Фиг.63 - диаграмма высокого уровня, иллюстрирующая альтернативные этапы обработки сигналов и условия, при которых может быть реализована синхронизация с использованием конечного автомата;
Фиг.64 - примеры относительных временных диаграмм для ряда тактовых периодов и временные соотношения для бит различных пакетов обратной линии связи и значений делителя;
Фиг.65 - пример обработки пересылки кода ошибки;
Фиг.66 - устройство, полезное для обработки пересылки кода ошибки;
Фиг.67А - обработка пересылки кода ошибки для кодовой перегрузки;
Фиг.67В - обработка пересылки кода ошибки для приема кода;
Фиг.68А - этапы обработки для запуска, инициированного хостом;
Фиг.68В - этапы обработки для запуска, инициированного клиентом;
Фиг.68С - этапы обработки для запуска, инициированного хостом и клиентом при конфликтной ситуации;
Фиг.69 - иллюстрация формата пакета запроса характеристик VCP;
Фиг.70 - иллюстрация формата ответного пакета характеристик VCP;
Фиг.71 - иллюстрация формата ответного списка характеристик VCP;
Фиг.72 - иллюстрация формата установки пакета характеристик VCP;
Фиг.73 - иллюстрация формата пакета запроса действительных параметров;
Фиг.74 - иллюстрация формата ответного пакета действительных параметров;
Фиг.75 - иллюстрация формата пакета возможностей изображения альфа-курсора;
Фиг.76 - иллюстрация формата пакета карты прозрачности альфа-курсора;
Фиг.77 - иллюстрация формата пакета сдвига изображения альфа-курсора;
Фиг.78 - иллюстрация формата пакета видеопотока альфа-курсора;
Фиг.79 - иллюстрация формата пакета возможностей масштабированного видеопотока;
Фиг.80 - иллюстрация формата пакета настройки масштабированного видеопотока;
Фиг.81 - иллюстрация формата пакета подтверждения масштабированного видеопотока;
Фиг.82 - иллюстрация формата пакета масштабированного видеопотока;
Фиг.83 - иллюстрация формата пакета запроса конкретного состояния;
Фиг.84 - иллюстрация формата пакета ответного списка действительных состояний;
Фиг.85А - иллюстрация формата пакета параметров задержки обработки пакета;
Фиг.85В - иллюстрация формата пункта списка параметров задержки;
Фиг.86 - иллюстрация формата пакета возможностей персонального дисплея;
Фиг.87А - иллюстрация формата пакета клиентского сообщения об ошибках;
Фиг.87В - иллюстрация формата пункта списка сообщений об ошибках;
Фиг.88 - иллюстрация формата пакета идентификации клиента;
Фиг.89 - иллюстрация формата пакета возможностей альтернативного дисплея;
Фиг.90 - иллюстрация формата пакета доступа к регистру;
Фиг.91А-91С - иллюстрации использования двух дисплейных буферов для уменьшения видимых артефактов;
Фиг.92 - иллюстрация двух буферов, где обновление дисплея выполняется быстрее, чем пересылка изображения;
Фиг.93 - иллюстрация двух буферов, где обновление дисплея выполняется медленнее, чем пересылка изображения;
Фиг.94 - иллюстрация двух буферов, где обновление дисплея выполняется гораздо быстрее, чем пересылка изображения;
Фиг.95 - иллюстрация трех буферов, где обновление дисплея выполняется быстрее, чем пересылка изображения;
Фиг.96 - иллюстрация трех буферов, где обновление дисплея выполняется медленнее, чем пересылка изображения;
Фиг.97 - иллюстрация одного буфера, где обновление дисплея выполняется быстрее, чем пересылка изображения;
Фиг.98 - иллюстрация соединения хост-клиент через последовательное подключение и концентратор;
Фиг.99 - иллюстрация клиентских устройств, подсоединенных через комбинацию концентраторов и последовательных подключений;
Фиг.100 - иллюстрация цветовой карты.
Подробное описание вариантов осуществления изобретения
I. Обзор
Общей целью изобретения является создание мобильного дисплейного цифрового интерфейса (MDDI), обсуждаемого ниже, который в результате обеспечивает экономически эффективный механизм пересылки с низким энергопотреблением, позволяющий осуществлять пересылку данных с высокой или сверхвысокой скоростью по ближней линии связи между хост-устройством и клиентским устройством, таким как дисплейный элемент, с использованием линии связи или канала данных «последовательного типа». Этот механизм хорошо подходит для реализации с миниатюрными разъемами и тонкими гибкими кабелями, которые особенно полезны при подсоединении внутренних (по отношению к корпусу или поддерживающей раме) дисплейных элементов или устройств ввода к центральному контроллеру, или внешних дисплейных элементов или устройств, таких как носимые микродисплеи (специальные очки или проекторы) для портативных компьютеров, устройства беспроводной связи или развлекательные устройства.
Хотя термины «мобильный» и «дисплей»» связаны с названием протокола, должно быть понятно, что это сделано только для удобства терминологии, чтобы иметь стандартное название, без труда понятное специалистам в данной области техники, работающим с таким интерфейсом и протоколом. Однако после просмотра вариантов изобретения, представленных ниже, станет ясно, что от применения этого протокола и результирующей структуры интерфейса пользу получат и многочисленные немобильные приложения и приложения, не имеющие отношения к дисплеям, причем аббревиатура MDDI не претендует на какие-либо ограничения характера или полезности изобретения или его различных вариантов.
Преимуществом вариантов изобретения является то, что предложен способ пересылки данных, который не отличается сложностью, имеет низкую стоимость, высокую надежность, хорошо вписывается в используемую среду и является весьма устойчивым, оставаясь при этом очень гибким.
Варианты изобретения можно использовать в самых разных ситуациях для осуществления связи или пересылки с высокой скоростью больших объемов данных, обычно для аудио, видео или мультимедийных приложений от хост-устройства или устройства-источника, где создаются или хранятся указанные данные, на клиентское устройство отображения или представления. Типовым применением, обсуждаемым ниже, является пересылка данных от портативного компьютера или беспроводного телефона или модема на устройство визуального отображения, такое как небольшой видеоэкран или переносное микродисплейное устройство, например, в виде защитных очков или касок, содержащих маленькие проекционные линзы и экраны, или от хоста на клиентское устройство в указанных компонентах. То есть от процессора на внутренний экран или другой элемент представления, а также от различных внутренних или внешних устройств ввода, используемых клиентом, к расположенному внутри (вместе в одном и том же корпусе или поддерживающей конструкции) хосту.
Характеристики или атрибуты MDDI таковы, что они не зависят от конкретной технологии отображения или представления. Этот интерфейс является очень гибким механизмом для пересылки данных с высокой скоростью независимо от внутренней структуры этих данных и функциональных аспектов данных или команд, которые он реализует. Это позволяет осуществлять временную настройку пересылаемых пакетов данных для адаптации к индивидуальным отличительным особенностям конкретных клиентских устройств, таких как уникальные требования по отображению для некоторых устройств, или для удовлетворения требований к комбинированному аудио и видео для некоторых аудиовизуальных систем или для некоторых устройств ввода, таких как джойстики, сенсорные панели и т.д. Интерфейс практически не заметен для дисплейного элемента или клиентского устройства, пока тот следует выбранному протоколу. Вдобавок совокупные данные последовательной линии связи либо скорость передачи данных могут меняться на несколько порядков, что позволяет разработчику системы связи или хост-устройства оптимизировать стоимость, требования к мощности, сложность клиентского устройства и частоту обновления клиентского устройства.
Интерфейс данных предложен в основном для использования при пересылке больших объемов данных с высокоскоростной по «проводной» линии передачи сигналов или по небольшому кабелю. Однако в некоторых приложениях может оказаться выгодным использовать беспроводную линию связи, включая также оптические линии связи, при условии если такая линия связи выполнена с возможностью для использования одних и тех же пакетов и структур данных, разработанных для указанного протокола интерфейса, и может поддерживать требуемый уровень пересылки с достаточно низким потреблением мощности или уровнем сложности, приемлемым для практического использования.
II. Среда
На фиг.1А и 1В показано типовое применение, где портативный компьютер 100, или лэптоп, и беспроводный телефон, или устройство PDA 102 осуществляют обмен данными с дисплейными устройствами 104 и 106 соответственно, наряду с системами 108 и 112 воспроизведения аудиосигналов. Вдобавок на фиг.1А показаны возможные соединения с более крупным дисплеем или экраном 114 или проектором 116 изображений, которые для ясности показаны только на одной фигуре, но также имеют возможность соединения с беспроводным устройством 102. Беспроводное устройство может осуществлять текущий прием данных или иметь некоторое количество ранее запомненных данных мультимедийного типа в элементе или устройстве памяти для последующего представления в целях просмотра и/или прослушивания конечным пользователем беспроводного устройства. Поскольку типовое беспроводное устройство используют большую часть времени для передачи речи и простых текстов, оно имеет достаточно маленький дисплейный экран и простую аудиосистему (динамики) для передачи информации пользователю устройства 102.
Компьютер 100 имеет гораздо больший экран, но все же неадекватную внешнюю аудиосистему, и ему не хватает других устройств мультимедийного представления, таких как телевизоры высокой четкости или киноэкраны. Компьютер 100 используют в иллюстративных целях, а в изобретении можно также использовать процессоры других типов, интерактивные видеоигры или бытовые электронные устройства. Компьютер 100 может использовать, но не только, беспроводный модем или другое встроенное устройство для беспроводной связи, либо он может быть подсоединен к указанным устройствам с использованием кабеля или беспроводной линии связи, если это желательно.
Это обеспечивает представление более сложных или «богатых по содержанию» данных. Поэтому промышленность разрабатывает другие механизмы и устройства для представления информации конечному пользователю и обеспечивает минимальный уровень удовольствия или положительных ощущений.
Как обсуждалось выше, в настоящее время имеются или разрабатываются дисплейные устройства нескольких типов для представления информации конечным пользователям устройства 100. Например, одна или несколько компаний разработали комплекты специальных очков, которые проецируют изображение перед глазами пользователя устройства для представления визуального отображения. При правильном расположении указанные устройства эффективно «проецируют» виртуальное изображение, воспринимаемое глазами пользователя, то есть делают его гораздо большим, чем элемент, обеспечивающий визуальный выходной сигнал. Иными словами, очень маленький проекционный элемент позволяет глазу (глазам) пользователя «видеть» изображения в гораздо большем масштабе, чем это возможно на типовых жидкокристаллических (LCD) экранах и т.п. Использование более крупных виртуальных экранных изображений позволяет также использовать изображение с гораздо большей разрешающей способностью, чем та, которая возможна на более ограниченных экранных жидкокристаллических дисплеях. Другие устройства отображения могут включать в себя, но не только: небольшие жидкокристаллические экраны или различные плоские панельные элементы отображения, проекционные линзы и драйверы дисплеев для проецирования изображений на поверхность и т.д.
Возможно также использовать дополнительные элементы, подсоединенные или связанные с использованием беспроводного устройства 102 или компьютера 100, для представления выходного сигнала другому пользователю или другому устройству, которое в свою очередь пересылает эти сигналы куда-либо еще или запоминает их. Например, данные могут запоминаться во флэш-памяти в оптической форме, например, с использованием записываемого носителя CD или магнитного носителя, такого как носитель в магнитофоне с магнитной лентой и аналогичных устройствах, для дальнейшего использования.
Вдобавок многие беспроводные устройства и компьютеры имеют теперь встроенные возможности декодирования музыки в стандарте MP3, а также другие усовершенствованные звуковые декодеры и системы. Портативные компьютеры используют, как правило, возможности воспроизведения дисков CD и DVD, а некоторые имеют небольшие специализированные устройства считывания флэш-памяти для приема предварительно записанных аудиофайлов. Проблема наличия указанных возможностей состоит в том, что цифровые музыкальные файлы предполагают улучшенное богатое по содержанию восприятие, но только если процесс декодирования и воспроизведения может поддерживать нужный темп. Сказанное верно и для цифровых видеофайлов.
На фиг.1А показаны внешние динамики 116 для звукового воспроизведения, которые также могут быть дополнены такими элементами, как низкочастотные колонки или динамики «объемного звука» для распространения звука вперед и назад. В то же время показано, что динамики и наушники 108 встроены в опорную конструкцию или механизм микродисплейного устройства 106 на фиг.1В. Как известно, могут быть использованы и другие элементы аудио или звукового воспроизведения, включая устройства для усиления мощности или формирования звука.
В любом случае, как обсуждалось выше, при необходимости пересылки данных изображения высокого качества или с высоким разрешением и информационных аудиосигналов или сигналов аудиоданных высокого качества от источника данных конечному пользователю по одной или нескольким линиям 110 связи потребуется высокоскоростная передача данных. То есть линия 110 пересылки, несомненно, является потенциально узким местом в процессе передачи данных, как обсуждалось выше, и ограничивает эффективность системы, поскольку современные механизмы пересылки не обеспечивают высокоскоростные передачи данных, которые обычно требуются. Как в качестве примера обсуждалось выше, для высоких значений разрешающей способности изображения, например 1024 на 1024 пикселя с глубиной цвета 24-32 бит на пиксель и скоростью передачи данных 30 кадров/с, скорости передачи данных могут достичь значений, превышающих 755 Мбит/с или выше. Вдобавок указанные изображения могут быть представлены как часть мультимедийного представления, которое включает в себя аудиоданные и, возможно, дополнительные сигналы, относящиеся к интерактивным играм или интерактивной связи, либо различные команды, управляющие воздействия или сигналы, дополнительно увеличивающие объем данных и скорость передачи данных.
Также очевидно, что меньшее количество кабелей или соединений между элементами, необходимых для установки линии передачи данных, означает, что соответствующие мобильные устройства будет легче использовать, и возрастает вероятность охвата большего числа пользователей. Это особенно верно, когда множество устройств используют вместе для достижения полноценного аудиовизуального впечатления и, в частности, особенно когда уровень качества дисплеев и устройств вывода аудиосигналов возрастает.
Другое типичное применение, связанное со многими из вышеуказанных и других усовершенствований видеоэкранов и других устройств вывода или ввода, можно видеть на фиг.1С и 1D, где показано, что портативный компьютер 130, или лэптоп, и беспроводный телефон, или устройство PDA 140, обмениваются данными с «внутренними» устройствами 134 и 144 отображения соответственно наряду с системами 136 и 146 воспроизведения аудиосигналов.
На фиг.1С и 1D в разрезе представлены электронные устройства или изделия, причем здесь показано местоположение одного или нескольких внутренних хостов или контроллеров в одной части устройства с общей линией связи (здесь это 138 и 148 соответственно), соединяющей их с дисплейными элементами или экранами, имеющими соответствующих клиентов, через поворотное соединение известного типа, используемое сегодня повсеместно в электронной индустрии. Понятно, что объем данных, вовлеченных в эти пересылки, требует большого количества проводников для образования линий 138 и 148. По некоторым оценкам, чтобы удовлетворить постоянно растущие потребности использования в этих устройствах усовершенствованных цветовых и графических интерфейсов и дисплейных элементов, указанные линии связи имеют до 90 или более проводников из-за использования известных интерфейсных технологий параллельного или иного типа, доступных для пересылки таких данных.
К сожалению, более высокоскоростные передачи данных превышают возможности современной технологии, имеющейся на сегодняшний день для пересылки данных. Это верно как с точки зрения объема необработанных данных, подлежащих пересылке в единицу времени, так и с точки зрения изготовления надежных, экономически эффективных физических механизмов пересылки.
Таким образом, существует потребность в способе пересылки данных с более высокими скоростями для линии пересылки данных или канала связи между элементами представления и источником данных, который позволяет, насколько это возможно, обеспечить маломощную (менее мощную), облегченную, простую и экономически выгодную кабельную структуру. Заявители разработали новый способ и устройство для достижения указанных и других целей, чтобы дать возможность комплекту мобильных, портативных или даже стационарных устройств пересылать данные на нужные дисплеи, микродисплеи или элементы пересылки аудиоданных высокоскоростными передачами данных при поддержании требуемого низкого энергопотребления и уровня сложности.
III. Архитектура системы высокоскоростного интерфейса передачи цифровых данных
Для создания и эффективного использования нового интерфейса устройств разработана архитектура протокола обмена сигналами и системы, которая обеспечивает очень высокоскоростную пересылку данных с использованием маломощных сигналов. Протокол основан на структуре пакетов и общих кадров или структурах, связанных вместе для формирования протокола для передачи заранее выбранного набора данных или типов данных вместе с командной или операционной структурой, наложенной на интерфейс.
А. Обзор
Устройства, соединенные линией MDDI или осуществляющие по ней связь, называются хостом и клиентом, причем клиентом обычно является дисплейное устройство некоторого типа, хотя это могут быть и другие устройства вывода и ввода. Данные из хоста на дисплей идут в прямом направлении (это называется «прямой трафик», или «прямая линия связи»), а данные от клиента к хосту идут в обратном направлении («обратный трафик», или «обратная линия связи»), когда это разрешено хостом. Все это показано в базовой конфигурации на фиг.2. На фиг.2 хост 202 соединен с клиентом 204 с использованием двунаправленного канала 206 связи, который, как показано, содержит прямую линию 208 связи и обратную линию 210 связи. Однако эти каналы формируются с помощью общего набора проводников, где при пересылке данных осуществляется эффективное переключение с работы по прямой линии связи на работу по обратной линии связи и наоборот. Это позволяет значительно сократить количество проводников, решая сразу одну из множества проблем, присущих современным подходам к высокоскоростной пересылке данных в маломощных средах, таких как мобильные электронные устройства.
Как обсуждалось выше, хост содержит одно из устройств нескольких типов, которые могут получить выгоду от использования настоящего изобретения. Например, хост 202 может представлять собой портативный компьютер в виде лэптопа или аналогичного мобильного вычислительного устройства. Также это может быть персональный цифровой секретарь (PDA), пейджинговое устройство или один из множества беспроводных телефонов или модемов. В альтернативном варианте хост 202 может представлять собой портативное развлекательное устройство или устройство представления, такое как портативный DVD- или CD-плеер либо игровое устройство.
Кроме того, хост в качестве хост-устройства или управляющего элемента может находиться во множестве различных других широко используемых или запланированных к производству коммерческих продуктов, для которых желательно со стороны клиента иметь высокоскоростную линию связи. Например, хост можно использовать для пересылки данных с высокими скоростями от устройства видеозаписи на клиентское устройство, обеспеченное памятью, для повышения быстродействия или на более крупный экран с высоким разрешением для представления видеоданных. Бытовой прибор, например холодильник, который имеет встроенную инвентаризационную или вычислительную систему и/или соединения Bluetooth с другими домашними устройствами, может обладать расширенными возможностями отображения при работе в режиме межсетевого соединения или Bluetooth или иметь уменьшенную потребность в проводах для дисплеев в дверце (клиент) и клавиатур или сканеров (клиент), в то время как компьютер или системы управления (хост) находятся где-то в корпусе. В общем, специалистам в данной области техники очевидно, что использование этого интерфейса может оказаться полезным для множества различных современных электронных устройств и бытовых приборов, а также, что открывается возможность модификации устаревших устройств, если дать им возможность передавать информацию с более высокой скоростью, используя ограниченное количество проводников, имеющихся во вновь добавленных или существующих разъемах или кабелях.
В то же время клиент (устройство) 204 может содержать множество различных устройств, пригодных для представления информации конечному пользователю или представления информации от пользователя к хосту. Это могут быть, например, микродисплей, встроенный в специальные или обычные очки, проекционное устройство, встроенное в шапку или каску, маленький экран или даже голографический элемент, установленный в автомобиле, например, на окне или ветровом стекле, или различные системы динамиков наушников или акустические системы для представления высококачественного звука или музыки. Другие устройства представления включают в себя проекторы или проекционные устройства, используемые для представления информации во время собраний или для кино- и телевизионного показа. Другим примером является использование сенсорных панелей или сенсорных устройств, устройств ввода на основе распознавания речи, сканеров безопасности и т.д., которые могут быть задействованы для пересылки значительного объема информации от пользователя устройства или системы с минимальным «вводом» данных, отличным от касания пальцем или звука, исходящего от пользователя. Вдобавок функцию интерфейсов для конечных пользователей или других устройств и оборудования могут выполнять установочные станции для компьютеров и автомобильные комплекты или настольные комплекты или держатели для беспроводных телефонов, причем они могут использовать другие клиентские устройства (устройства вывода или ввода, например мышь) или хосты в помощь пересылке данных, особенно тогда, когда задействованы высокоскоростные сети.
Однако специалистам в данной области техники должно быть ясно, что настоящее изобретение не ограничивается этими устройствами и что на рынке имеется множество других устройств и предложений для обеспечения конечных пользователей высококачественными изображениями и звуком в плане запоминания и транспортировки либо в плане представления при воспроизведении. Настоящее изобретение полезно, когда необходимо увеличить пропускную способность при передаче данных между различными элементами или устройствами, чтобы обеспечить высокоскоростную передачу данных, необходимую для реализации пользовательского восприятия на желаемом уровне.
Предложенные в изобретении интерфейс MDDI и коммуникационный протокол обмена сигналами можно использовать для упрощения соединений между, например, хост-процессором, контроллером или схемной компонентой и дисплеем в устройстве или корпусе или конструкции устройства (так называемый «внутренний режим»), чтобы уменьшить затраты или сложность и снизить соответствующие требования к мощности и управлению или ослабить ограничения на эти соединения, а также повысить надежность, причем не только для соединений с внешними элементами, устройствами или оборудованием (так называемый «внешний режим»).
Общая скорость передачи данных последовательной линии связи в каждой сигнальной паре, используемой этой интерфейсной структурой, может изменяться на много порядков, что позволяет разработчику системы или устройства легко оптимизировать стоимость, мощность, сложность реализации и частоту обновления дисплея для данного приложения или данной цели. Атрибуты интерфейса MDDI не зависят от технологии дисплея или другого устройства представления (целевой клиент). Временные соотношения пакетов данных, пересылаемых через интерфейс, можно легко отрегулировать для адаптации к индивидуальным особенностям конкретных клиентов, таких как устройства отображения, акустические системы, элементы памяти и управления, или приспособить к комбинированным требованиям к временным характеристикам аудио- видеосистем. Хотя это позволяет получить систему с очень маленьким энергопотреблением, использовать протокол MDDI на по меньшей мере некотором уровне нет необходимости для того, чтобы различные клиенты имели буферы кадров.
В. Типы интерфейса
Предполагается, что интерфейс MTDI может иметь по меньшей мере четыре, а потенциально больше отдельных физических типов, используемых в индустрии связи и компьютерной индустрии. Их можно обозначить просто как тип 1, тип 2, тип 3 и тип 4, хотя специалисты в данной области техники могут использовать другие метки или обозначения в зависимости от конкретных приложений, где они используются, или индустрии, с которой они связаны. Например, в простых аудиосистемах используется меньше соединений, чем в более сложных мультимедийных системах, и можно дифференцировано ссылаться на такие признаки, как «каналы», и т.д.
Интерфейс типа 1 сконфигурирован в виде 6-проводного или иного проводника или проводящего элемента или интерфейса, который подходит для мобильных или беспроводных телефонов, PDA, электронных игр и портативных медийных плееров, таких как CD-плееры или MP3-плееры, и аналогичных устройств либо устройств, используемых в бытовой электронике аналогичных типов. В одном варианте интерфейс может быть сконфигурирован в виде 8-проводного (проводникового) интерфейса, который больше подходит для лэптопов, ноутбуков или настольных персональных компьютеров, и аналогичных устройств или бытовых приборов, не требующих быстрого обновления данных и которые не имеют встроенный контроллер линии связи MDDI. Этот тип интерфейса также отличается использованием дополнительного двухпроводного интерфейса на основе универсальной последовательной шины (USB), который весьма полезен при адаптации существующих операционных систем или программной поддержки, имеющихся на большинстве персональных компьютеров.
Интерфейсы типа 2, типа 3 и типа 4 подходят для высокоэффективных клиентов или устройств и используют гораздо более сложную систему кабелей с дополнительными проводниками типа скрученных пар для обеспечения соответствующего экранирования и пересылки сигналов данных с низкими потерями.
Интерфейс типа 1 проводит сигналы, которые могут содержать информацию для отображения, аудиоинформацию, управляющую информацию и ограниченную информацию для обмена сигналами, причем этот интерфейс, как правило, используется для мобильных клиентов или клиентских устройств, которые не требуют данных с высоким разрешением, передающихся на полной скорости. Интерфейс типа 1 может легко поддерживать разрешение SVGA при скорости 30 кадров/с плюс аудиоканал 5.1, а при минимальной конфигурации может использовать только три проводные пары: две пары для передачи данных и одну пару для подачи питания. Интерфейс этого типа предназначен в основном для таких устройств, как мобильные беспроводные устройства, где USB хост обычно недоступен в указанном устройстве для соединения и пересылки сигналов. В этой конфигурации мобильное беспроводное устройство является хост-устройством MDDI, которое действует в качестве «мастера», управляющего линией связи из хоста, который обычно посылает клиенту данные (прямой трафик или прямая линия связи) для представления, отображения или воспроизведения.
В этом интерфейсе хост разрешает прием данных связи на хосте от клиента (обратный трафик или обратная линия связи) путем посылки клиенту специальной команды или пакета определенного типа, который позволяет занять шину (линию связи) в течение заданного времени и послать данные на хост в виде обратных пакетов. Это показано на фиг.3, где тип пакета названный пакетом инкапсуляции (обсуждается ниже), используется для обеспечения пересылки обратных пакетов по линии пересылки, создающей обратную линию связи. Временной интервал, выделенный хосту для запроса данных у клиента, определяется хостом заранее и основан на требованиях каждого конкретного приложения. Этот тип полудуплексной двунаправленной пересылки данных дает особые преимущества, когда порт USB недоступен для пересылки информации или данных от клиента.
Для высокоэффективных дисплеев, способных работать с системами типа HDTV или с высоким разрешением аналогичного уровня, для поддержки видео с полноценным движением требуются потоки данных со скоростью порядка 1,5 Гбит/с. Интерфейс типа 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 метров от хоста. В этой ситуации хост также может обеспечивать питание внешнего клиента, так что оба устройства могут легко работать в мобильной среде. Внутренний режим описывает ситуацию, когда хост подсоединен к клиенту, находящемуся внутри того же устройства, например в общем корпусе или опорной конструкции некоторого типа. Примером этого являются приложения в беспроводном телефоне или другом беспроводном устройстве или портативный компьютер или игровое устройство, где клиентом является дисплей или драйвер дисплея, либо устройство ввода, такое как клавиатура или сенсорная панель, или звуковая система, а хост является центральным контроллером, графическим процессором или элементом центрального процессора (CPU). Поскольку в приложениях внутреннего режима клиент расположен гораздо ближе к хосту, чем в приложениях внешнего режима, в таких конфигурациях обычно не предъявляются обсужденные требования к подсоединению питания к клиенту.
С. Физическая структура интерфейса
На фиг.4 и 5 показано общее расположение устройства или контроллера линии связи для установки связи между хост-устройством и клиентским устройством. На фиг.4 и 5 показано, что контроллер 402 и 502 линии связи MDDI установлен в хост-устройстве 202, а контроллер 404 и 504 линии связи MDDI установлен в клиентском устройстве 204. Как и раньше, хост 202 соединен с клиентом 204 с использованием двунаправленного канала 406 связи, содержащего ряд проводников. Как обсуждается ниже, контроллеры линии связи хоста и клиента могут быть изготовлены в виде интегральной схемы с использованием единого схемного решения, причем они могут быть установлены, настроены или запрограммированы так, чтобы реагировать в качестве хост-контроллера (драйвера) или клиентского контроллера (приемника). Это обеспечивает меньшие расходы благодаря крупносерийному производству единого схемного устройства.
На фиг.5 показано, что контроллер 502 линии связи MDDI установлен в хост-устройстве 202', а контроллер 504 линии связи MDDI установлен в клиентском устройстве 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 содержит две дополнительные пары или сигнальных тракта, обозначенные как MDDI_Data2+/- и MDDI_Data3+/- в дополнение к тому, что содержит интерфейс типа 2. Интерфейс типа 4 в дополнение к тому, что содержит интерфейс типа 3, имеет еще четыре пары данных или сигнальных тракта, которые обозначены как: MDDI_Data4+/-, MDDI_Data5+/-, MDDI_Data6+/- и MDDI_Data7+/- соответственно. В каждой из вышеописанных конфигураций интерфейса хост может подавать питание на клиентское оборудование или дисплей, используя проводную пару или сигналы, обозначенные как HOST_Pwr и HOST_Gnd. Как обсуждается ниже, в некоторых конфигурациях передача питания также может обеспечиваться, если это потребуется, по проводникам MDDI_Data4+/-, MDDI_Data5+/-, MDDI_Data6+/- или MDDI_Data7+/-, когда используется тот тип интерфейса, где применяется меньше проводников, чем предусмотрено для других режимов. Такая передача питания обычно используется для внешних режимов, при этом для внутренних режимов в этом обычно нет необходимости, хотя некоторые приложения могут варьироваться.
Ниже в таблице I показаны все сигналы, проходящие между хостом и клиентом (дисплей) через линию связи MDDI, для различных режимов в соответствии с типом интерфейса.
Также заметим, что соединения 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. Типы и скорости передачи данных
Для обеспечения универсального интерфейса для всех возможных приложений и широкого диапазона пользовательского восприятия мобильный интерфейс цифровых данных (MDDI) обеспечивает поддержку различных клиентов и отображаемой информации, аудиопреобразователей, клавиатур, указательных устройств и многих других устройств ввода или вывода, а также их комбинаций, которые могут быть интегрированы или согласованно работать с мобильным устройством отображения вместе с управляющей информацией. Интерфейс MDDI разработан для того, чтобы обеспечить прохождение потоков данных самых разных типов между хостом и клиентом в прямом или обратном направлениях по линии связи с использованием минимального количества кабелей или проводников. Поддерживаются как изохронные потоки, так и асинхронный поток (обновления). Возможно множество комбинаций типов данных, до тех пор пока совокупная скорость передачи данных меньше или равна максимальной требуемой скорости для линии связи MDDI, которая ограничена максимальной последовательной скоростью и количеством пар, используемых для передачи данных. Они могут включать в себя, но не только, варианты, перечисленные ниже в таблицах II и III.
Интерфейс не является жестко фиксированным, а является расширяемым, так что он может поддерживать пересылку различных «типов» информации, включая данные, определенные пользователем, обеспечивая гибкость будущей системы. Конкретными примерами данных, с которыми может работать интерфейс, являются: видео с полноценным движением либо в виде полей полной или частичной экранной битовой карты, либо в виде сжатого видео; статические битовые карты с низкими скоростями для экономии мощности и уменьшения затрат на реализацию; PCM (импульсно-кодовая модуляция) или сжатые аудиоданные с различными разрешениями или скоростями; данные о положении и выборе указательного устройства и данные, определяемые пользователем для возможностей, которые еще подлежат определению. Указанные данные могут также пересылаться вместе с управляющей информацией или информацией о состоянии для определения возможностей устройства или установки рабочих параметров.
Варианты изобретения развивают данную область техники для использования при пересылках данных, которые включают в себя, но не только: просмотр кинофильма (видеоотображение и звук); использование персонального компьютера с ограниченным персональным просмотром (графическое отображение, иногда в сочетании с видео и аудио); видеоигра на персональном компьютере, консоли или персональном устройстве (движущееся графическое отображение или синтетическое видео и звук); «серфинг» по Интернету с использованием устройства в виде видеотелефона (двунаправленное низкоскоростное видео и аудио); камера для фиксации неподвижных цифровых изображений или записывающая видеокамера для фиксации цифровых видеоизображений; использование телефона, компьютера или PDA, сопряженного с проектором для представления данных или сопряженного с настольной установочной станцией, соединенной с видеомонитором, клавиатурой и мышью; а также для эффективной модернизации или использования с развлекательными целями с сотовыми телефонами, смартфонами или PDA, включая данные беспроводных указательных устройств и клавиатуры.
Интерфейс высокоскоростной передачи данных, обсуждаемый ниже, представлен с точки зрения передачи больших объемов данных типа аудио-видео по линии связи или пересылки, которая обычно сконфигурирована в виде проводной линии или кабельной линии. Однако легко понять, что структура сигналов, протоколы, временные характеристики или механизм пересылки могут быть настроены так, чтобы обеспечить связь через оптическую или беспроводную среду, если она может поддерживать требуемый уровень пересылки данных.
Сигналы интерфейса MDDI используют концепцию, известную как «частота общих кадров (CFR)», для базового сигнального протокола или структуры. Идея, лежащая в основе использования частоты общих кадров, состоит в создании импульсов синхронизации для одновременных изохронных потоков данных. Клиентское устройство может использовать эту частоту общих кадров как эталон времени. Низкая частота общих кадров увеличивает эффективность канала благодаря уменьшению объема служебных данных для передачи заголовка субкадра. С другой стороны, высокая частота общих кадров уменьшает задержку и позволяет использовать менее эластичный буфер данных для аудиовыборок. Частоту общих кадров в интерфейсе по настоящему изобретению можно динамически программировать и установить равной одному из множества значений, которые подходят для изохронных потоков, используемых в конкретном приложении. То есть значение частоты общих кадров выбирается так, чтобы она наилучшим образом подошла к данной конфигурации клиента и хоста.
Количество байт, обычно необходимых для одного субкадра (его можно настраивать или программировать), для изохронных потоков данных, которые наиболее пригодны для использования с приложением, например, с видео или микродисплеем, показано в таблице IV.
Дробные отсчеты байт на субкадр легко получить, используя простую программируемую структуру счетчика M/N. Например, отсчет 26-2/3 байт на субкадр реализуется путем пересылки двух кадров из 27 байт каждый, за которым следует один субкадр из 26 байт. Можно выбрать меньшую частоту общих кадров, чтобы получить целое число байт на субкадр. Однако вообще-то говоря, для аппаратной реализации простого M/N счетчика необходима меньшая площадь в интегральной схеме или электронном модуле, используемом для реализации части или всех вариантов изобретения, чем площадь, необходимая для более крупного буфера обратного магазинного типа (FIFO) для аудиовыборки.
Примером приложения, который иллюстрирует влияние различных скоростей пересылки данных и типов данных, является система караоке. В этой системе конечный пользователь или пользователи поют в сопровождении музыкальной видеопрограммы. Слова песни отображаются в каком-либо месте, обычно в нижней части экрана, чтобы пользователь знал, какие слова петь, а также примерные такты данной песни. Для этого приложения требуется видеоотображение с нечастыми графическими обновлениями и смешивание голоса или голосов пользователей со стереоаудиопотоком.
Если предположить, что частота общих кадров составляет 300 Гц, то тогда каждый субкадр будет состоять из 92160 байт видеоконтента и 588 байт аудиоконтента (на основе 147 16-разрядных выборок в стерео) при передаче по прямой линии связи на клиентский дисплей, а в среднем на мобильный аппарат караоке от микрофона посылается 26,67 (26-2/3) байта речи. Асинхронные пакеты посылаются между хостом и дисплеем, возможно, шлемом-дисплеем. Они включают в себя не более 768 байт графических данных (в четверть высоты экрана) и не более порядка 200 байт для смешанных команд управления и состояния.
В таблице V показано распределение данных в субкадре на примере караоке. В качестве общей используемой скорости выбрана скорость порядка 279 Мбит/с. Чуть большая скорость 280 Мбит/с позволяет пересылать еще порядка 400 байт данных на субкадр, что дает возможность использовать нерегулярные управляющие сообщения и сообщения о состоянии.
III. (Продолжение) Архитектура системы высокоскоростного интерфейса передачи цифровых данных
E. Канальный уровень
Данные, пересылаемые с использованием сигналов последовательных данных высокоскоростного интерфейса MDDI, состоят из потока мультиплексированных во времени пакетов, которые идут друг за другом. Даже тогда, когда передающее устройство не имеет данных для посылки, контроллер линии связи MDDI обычно автоматически посылает пакеты заполнителя, поддерживая тем самым поток пакетов. Использование простой пакетной структуры обеспечивает надежные изохронные временные соотношения для потоков видео и аудиосигналов или данных.
Группы пакетов находятся в сигнальных элементах или структурах, называемых «субкадры», а группы субкадров содержатся в сигнальных элементах или структурах, называемых «медиакадры». Субкадр содержит один или несколько пакетов в зависимости от размера и назначения пересылки данных, а медиакадр содержит один или несколько субкадров. Самый большой субкадр, предусмотренный протоколом, который используется в представленных здесь вариантах изобретения, имеет порядка
232-1 или 4294967295 байт, и тогда самый большой размер медиакадра составит порядка 216-1 или 65535 субкадров.
Специальный пакет заголовка субкадра содержит уникальный идентификатор, который появляется в начале каждого субкадра, как обсуждается ниже. Идентификатор также используется для получения временных соотношений для кадра в клиентском устройстве, когда инициирована связь между хостом и клиентом. Процесс получения временных соотношений для линии связи более подробно обсуждается ниже.
Как правило, дисплейный экран обновляется один раз за медиакадр при отображении видео с полноценным движением. Частота дисплейных кадров такая же, как частота медийных кадров. Протокол линии связи поддерживает видео с полноценным движением на всем дисплее или только в небольшой области видеоконтента с полноценным движением, окруженной статическим изображением, в зависимости от требуемого приложения. В некоторых маломощных мобильных приложениях, таких как просмотр Web-страниц или электронной почты, обновление дисплейного экрана может потребоваться только от случая к случаю. В этих ситуациях выгодно передавать один субкадр, а затем отключать или выводить из работы линию связи для минимизации энергопотребления. Интерфейс также поддерживает такие эффекты, как стереоскопическое отображение, и обрабатывает графические примитивы.
Субкадры позволяют системе разрешать передачу высокоприоритетных пакетов на периодической основе. Это дает возможность одновременным изохронным потокам существовать вместе при минимальном объеме буферизированных данных. Одним из преимуществ является то, что варианты изобретения обеспечивают процесс отображения, позволяющий множеству потоков данных (высокоскоростная передача видео, речи, управления, состояния, данных указательного устройства и т.д.) по существу совместно использовать общий канал. При такой пересылке информации используется относительно мало сигналов. Это также позволяет активировать такие специфические для дисплея средства, как горизонтальные синхроимпульсы и интервалы гашения для монитора с электроннолучевой трубкой или другие операции, специфичные для клиентского оборудования.
F. Контроллер линии связи
Контроллер линии связи MDDI, показанный на фиг.4 и 5, изготовлен или собран полностью на цифровой основе за исключением дифференциальных приемников линии, которые используются для приема данных MDDI и стробирующих сигналов. Однако дифференциальные драйверы и приемники линии также могут быть реализованы в тех же цифровых интегральных схемах вместе с контроллером линии связи, например, при производстве интегральной схемы типа КМОП. Для восстановления битов или реализации аппаратных средств для контроллера линии связи не требуются ни аналоговые функции, ни система фазовой автоподстройки частоты (PLL). Контроллеры линии связи хоста и клиента имеют очень похожие функции за исключением клиентского интерфейса, который содержит конечный автомат для синхронизации линии связи. Таким образом, варианты изобретения дают практическое преимущество, позволяющее создать единое проектное решение или схему контроллера, которая может быть сконфигурирована либо для хоста, либо для клиента, что потенциально снижает затраты на изготовление контроллеров линии связи в целом.
IV. Протокол линии связи интерфейса
А. Структура сигнального протокола или кадра, используемая для реализации связи по прямой линии для пересылки пакетов, показана на фиг.6. Как показано на фиг.6, информация или цифровые данные сгруппированы в элементы, известные как пакеты. В свою очередь, множество пакетов сгруппированы вместе, образуя то, что называется здесь «субкадром», а множество субкадров, в свою очередь, группируют вместе для формирования «медиакадра». Для управления формированием кадров и пересылкой субкадров каждый субкадр начинается с заранее определенного специального пакета, называемого пакетом заголовка субкадра (SHP).
Хост-устройство выбирает скорость передачи данных, подлежащую использованию для данной пересылки. Эта скорость может динамически изменяться хост-устройством на основе максимальных возможностей хоста по пересылке или на основе данных, извлекаемых хостом из источника, а также максимальных возможностей клиента или другого устройства, на которое пересылаются данные.
Приемное клиентское устройство, разработанное для или способное работать с MDDI или предложенным в изобретении сигнальным протоколом, способно отвечать на запросы хоста, чтобы определить максимальную или текущую максимальную скорость пересылки данных, которую оно может использовать, или по умолчанию может быть использована более низкая минимальная скорость, а также определить используемые типы данных и поддерживаемые функции. Эту информацию можно переслать с использованием пакета возможностей пользователя (DCP), обсуждаемого ниже. Клиентское устройство отображения способно пересылать данные или осуществлять связь с другими устройствами, используя интерфейс с предварительно выбранной минимальной скоростью передачи данных или в минимальном диапазоне скоростей передачи данных, а хост выполнит запрос, используя скорость передачи данных в этом диапазоне, чтобы определить все возможности клиентских устройств.
Другую информацию о состоянии, определяющую особенности битовой карты и возможности клиента с точки зрения скорости передачи видеокадров можно пересылать в пакете состояния на хост, так что хост может сконфигурировать интерфейс, который будет эффективным или оптимальным и в то же время практичным в рамках любых системных ограничений.
Хост посылает пакеты заполнителя, когда нет (больше нет) пакетов данных, подлежащих пересылке в текущем субкадре, или когда хост не может выполнять пересылку со скоростью, достаточной для того, чтобы не отклоняться от скорости передачи данных, выбранной для прямой линии связи. Поскольку каждый субкадр начинается с пакета заголовка субкадра, конец предыдущего субкадра содержит пакет (вероятнее всего, пакет заполнителя), который точно заполняет предыдущий субкадр. В случае нехватки места собственно для пакетов, несущих данные, пакет заполнителя, скорее всего, будет последним пакетом в субкадре или находиться в конце следующего предыдущего субкадра и перед пакетом заголовка субкадра. Задачей операций управления в хост-устройстве является обеспечение достаточного пространства, оставшегося в субкадре для каждого пакета, подлежащего передаче в субкадре. В то же время, как только хост-устройство инициирует посылку пакета данных, хост должен иметь возможность успешно завершить пакет этого размера в кадре без того, чтобы имела место недогрузка.
Согласно одному аспекту вариантов изобретения передача субкадра может осуществляться в двух режимах. Один режим - это режим периодических субкадров, или периодически следующих сверхкадров, используемых для передачи видео и аудиопотоков в реальном времени. В этом режиме длина субкадра определяется как ненулевая. Второй режим является асинхронным или непериодическим режимом, в котором кадры используются для предоставления клиенту данных битовой карты только тогда, когда имеется новая информация. Этот режим определяется путем установки длины субкадра в нуль в пакете заголовка субкадра. При использовании периодического режима прием пакета субкадра может начинаться, когда клиент выполнил синхронизацию со структурой кадра прямой линии связи. Это соответствует так называемым «синхронным» состояниям, определенным в соответствии с диаграммой состояний, которая обсуждается ниже в связи с фиг.49 или фиг.63. В асинхронном непериодическом режиме субкадров прием начинается после получения первого пакета заголовка субкадра.
В. Полная структура пакета
Ниже представлен формат или структура пакетов, используемых для построения сигнального протокола, реализованного в вариантах изобретения, в предположении, что интерфейс является расширяемым, и могут быть добавлены дополнительные пакетные структуры, если это потребуется. Пакеты обозначены или разделены на различные «типы пакета» в зависимости их функции в интерфейсе, то есть в зависимости от команд или данных, которые они пересылают. Таким образом, каждый тип пакета обозначает заранее определенную пакетную структуру для данного пакета, которая используется при манипулировании пакетами и пересылаемыми данными. Из дальнейшего описания станет ясно, что пакеты могут иметь заранее выбранную длину или иметь переменную или динамически изменяемую длину в зависимости от их функций. Пакеты также могут иметь разные имена, реализуя одну и ту же функцию, что может случиться, когда протоколы изменяются во время принятия стандарта. Байты или байтовые значения, используемые в различных пакетах, сконфигурированы в виде многоразрядных (8- или 16-разрядных) целых чисел без знака. Списки пакетов, используемых вместе с обозначениями их «типа», показаны в таблицах с VI-1 по VI-4.
Каждая таблица представляет общий «тип» пакета в полной пакетной структуре для облегчения демонстрации и понимания. Изобретение не накладывает каких-либо ограничений или других условий на группировку пакетов, то есть пакеты могут быть организованы любым другим образом, если это потребуется. В таблицах также отмечено направление, в котором пересылка пакета считается действительной.
Из обсуждений, приведенных в данном описании, ясно, что, хотя каждый из пакетов: пакет инкапсуляции обратной линии связи, пакет возможностей клиента и пакет клиентского запроса и состояния, считается очень важным или даже необходимым для работы во внешнем режиме, их можно считать необязательными для работы во внутреннем режиме. Это создает еще один тип протокола интерфейса MDDI, который позволяет осуществлять передачу данных с очень высокими скоростями с сокращенным набором пакетов передачи и соответствующим упрощением управления и привязки во времени.
Пакеты имеют общую базовую структуру или полный набор минимальных полей, содержащий поле длины пакета, поле типа пакета, поле (поля) байтов данных и поле CRC, показанные на фиг.7. Как показано на фиг.7, поле длины пакета содержит информацию в виде многоразрядного или многобайтового значения, которое задает общее количество бит в пакете или его длину между полем длины пакета и полем CRC. В одном варианте поле длины пакета содержит 16-разрядное или 2-байтовое целое число без знака, задающее длину пакета. Поле типа пакета является еще одним многобитовым полем, которое обозначает тип информации, содержащейся в пакете. В приведенном в качестве примера варианте это 16-разрядное или 2-байтовое значение в виде 16-разрядного целого числа без знака, которое задает такие типы данных, как возможности дисплея, переключение типа, видео или аудиопотоки, состояние и т.д.
Третье поле - это поле байтов данных, которое содержит биты или данные, пересылаемые или посылаемые между хост-устройством и клиентским устройством, как часть данного пакета. Формат данных определяется отдельно для каждого типа пакета в соответствии с определенным типом пересылаемых данных и может быть выделен в ряд дополнительных полей, к каждому из которых предъявляются собственные требования относительно формата. То есть каждый тип пакета будет иметь заданный формат для данного участка или поля. Последним полем является поле CRC, которое содержит результаты 16-разрядной проверки с помощью избыточного циклического кода, вычисленной на основе полей байтов данных, типа пакета и длины пакета, причем указанная проверка используется для подтверждения целостности информации в пакете. Другими словами, вычисляется по всему пакету за исключением самого поля CRC. Клиент обычно ведет общий подсчет обнаруженных ошибок CRC и сообщает результат этого подсчета обратно на хост в пакете клиентского запроса и состояния (см. ниже).
В общем случае организация и ширина этих полей рассчитаны таким образом, чтобы поддерживать 2-байтовые поля, выровненные по границе четных байтов, и 4-байтовые поля, выровненные по 4-байтовым границам. Это позволяет легко встроить пакетные структуры в пространство основной памяти хоста и клиента (или связанной с ними памяти) без нарушения правил выравнивания по типу данных, используемых в большинстве обычно используемых процессорах или схемах управления.
Во время пересылки пакетов передача полей начинается с младшего значащего бита (LSB) и заканчивается старшим значащим битом (MSB), передаваемым последним. Параметры, имеющие длину более одного байта, передают, используя вначале младший значащий байт, что дает один и тот же битовый шаблон передачи, используемый для параметра с длиной, превышающей 8 бит, как это используется для более короткого параметра, где первым передается LSB. Поля данных каждого пакета обычно передают в порядке, в котором они определены в последующих разделах, причем первое поле в списке передается первым, а последнее описанное поле передается последним. Данные в тракте сигнала MDDI_Data0 выравниваются по биту '0' байтов, переданных по интерфейсу в любом из режимов типа 1, типа 2, типа 3 или типа 4.
При манипулировании данными для дисплеев данные для матриц пикселей передаются сначала по строкам, а затем по столбцам, как это обычно делается в электронной технике. Другими словами, все пиксели, появляющиеся в одной и той же строке на битовой карте, передаются в следующем порядке: первым передается самый левый пиксель, а последним самый правый пиксель. После передачи самого правого пикселя строки следующим пикселем в последовательности становится самый левый пиксель следующей строки. Для большинства дисплеев строки пикселей обычно передаются в порядке сверху вниз, хотя, если это необходимо, можно обеспечить и другие конфигурации. Кроме того, при обработке битовых карт стандартный подход, изложенный ниже, состоит в определении опорной точки путем присвоения левому верхнему углу битовой карты значений координат, или сдвига, равных «0,0». Значения координат X и Y, используемых для задания или определения положения на битовой карте, возрастают при приближении к правому краю и нижней части битовой карты соответственно. Первая строка и первый столбец (левый верхний угол изображения) начинаются со значения индекса, равного нулю. Значение координаты Х возрастает по мере приближения к правому краю изображения, а значение координаты Y возрастает по мере приближения к низу изображения, видимого пользователю дисплея.
Дисплейное окно является видимой частью битовой карты, то есть частью пикселей на битовой карте, которые может видеть пользователь на физическом носителе дисплея. Часто случается, что окно дисплея и битовая карта имеют один и тот же размер. Левый верхний угол окна дисплея всегда отображает координаты 0,0 пикселя битовой карты. Ширина окна дисплея соответствует оси Х битовой карты, причем ширина окна дисплея должна быть меньше или равна ширине соответствующей битовой карты. Высота окна соответствует оси Y битовой карты, причем высота окна дисплея должна быть меньше или равна высоте соответствующей битовой карты. Само окно дисплея не является адресуемым в протоколе, поскольку оно определяется только как видимая часть битовой карты.
Взаимосвязь между битовыми картами и дисплейными окнами хорошо известна специалистам в области компьютеров, электроники, Интернет-связи и других смежных областях. Поэтому обсуждение и демонстрация этих принципов далее здесь не предусмотрены.
С. Определения пакетов
1. Пакет заголовка субкадра
Пакет заголовка субкадра является первым пакетом каждого субкадра и имеет базовую структуру, показанную на фиг.8. Пакет заголовка субкадра используют для синхронизации пары «хост-клиент», причем возможность создания этого пакета должен иметь каждый хост, в то время как каждый клиент должен быть способен принять и интерпретировать этот пакет. Как можно видеть из одного варианта на фиг.8, структура этого типа пакета имеет поля: длины пакета, типа пакета, уникального слова, поле Резервное 1, длины субкадра, версии протокола, отсчета субкадров и отсчет медиакадров, причем обычно они расположены в указанном порядке. В одном варианте этот тип пакета обычно идентифицируется как пакет типа 15359 (0x3bff в шестнадцатиричном исчислении), и использует предварительно выбранную фиксированную длину, равную 20 байт, куда не входит поле длины пакета.
В поле типа пакета и поле уникального слова используется 2-байтовое значение (16-разрядное целое число). 4-байтовая комбинация этих двух полей формирует 32-разрядное уникальное слово с хорошей автокорреляцией. В одном варианте действительным уникальным словом является слово 0x005a3bff, где сначала в качестве типа пакета передаются младшие 16 бит, а затем передаются 16 старших бит.
Поле резервное 1 содержит 2 байта, образующие резервное пространство для будущего использования, причем в этом месте все биты обычно устанавливают равными нулю. Это поле предназначено для того, чтобы вызвать выравнивание последующих 2-байтовых полей до адреса 16-разрядного слова и выравнивание 4-байтовых полей до адреса 32-разрядного слова. Младший значащий байт зарезервирован для индикации о том, что хост способен обращаться по адресам множества клиентских устройств. Нулевое значение зарезервировано для индикации о том, что хост способен работать только с одним клиентским устройством.
Поле длины субкадра содержит 4 байта информации или значений, которые задают количество байтов на субкадр. В одном варианте длина этого поля может быть установлена равной нулю для индикации о том, что хост передаст только один субкадр, перед переключением линии связи в состояние ожидания. Значение этого поля может динамически изменяться «в процессе работы в реальном времени» при переходе с одного субкадра на следующий. Эта возможность полезна для выполнения ограниченных настроек временных параметров в синхроимпульсах для обеспечения изохронных потоков данных. Если проверка CRC пакета заголовка субкадра дает отрицательный результат, то тогда контроллер канала связи для оценки длины текущего субкадра должен использовать длину субкадра из предыдущего известного пакета заголовка субкадра.
Поле версии протокола содержит 2 байта, которые задают версию протокола, используемую хостом. Поле версии протокола устанавливают в '0' для задания первой или текущей версии используемого протокола. Это значение со временем изменится при создании новых версий.
Поле отсчета субкадров содержит 2 байта, которые задают последовательное число, указывающее количество субкадров, переданных от начала медиакадра. Первый субкадр медиакадра имеет нулевое значение отсчета субкадров. Последний субкадр медиакадра имеет значение, равное n-1, где n - количество субкадров на медиакадр. Заметим, что, если длина субкадра установлена равной нулю (что указывает на непериодический субкадр), то тогда значение отсчета субкадров также должно быть установлено равным нулю.
Поле отсчета медиакадров содержит 4 байта (32-разрядное целое число без знака), которые задают последовательное число, указывающее количество медиакадров, переданных от начала пересылаемого в настоящий момент медийного продукта или медийных данных. Первый медиакадр медийного продукта имеет нулевое значение отсчета медиакадров. Отсчет медиакадров увеличивается на единицу перед первым субкадром каждого медиакадра и возвращается в нуль после достижения максимального используемого значения отсчета медиакадров (например, количество медиакадров 232-1=4294967295). Значение отсчета медиакадров может быть установлено хостом в нуль в общем случае в любой момент времени в соответствии с требованиями конечного приложения.
2. Пакет заполнения
Пакет заполнения - это пакет, который пересылается на или от клиентского устройства, когда отсутствует иная информация, подлежащая пересылке по прямой или обратной линии связи. Рекомендуется, чтобы пакеты заполнения имели минимальную длину с целью обеспечения максимальной гибкости при посылке других пакетов, когда это потребуется. В самом конце субкадра или пакета инкапсуляции обратной линии связи (см. ниже) контроллер канала связи устанавливает размер пакета заполнения для заполнения оставшегося пространства, чтобы сохранить целостность пакета. Пакет заполнения полезен для поддержки временных соотношений в канале связи, когда хост и клиент не имеют информации для посылки или обмена. Необходимо, чтобы как хост, так и клиент имели возможность посылки и приема этого пакета для обеспечения эффективного использования интерфейса.
Формат и контент пакета заполнения показаны на фиг.9. Как показано на фиг.9, структура этого типа пакета имеет поля длины пакета, типа пакета, байтов заполнения и CRC. В одном варианте этот тип пакета обычно идентифицируется как тип 0, что указано в 2-байтовом поле типа. Биты или байты в поле байтов заполнения содержат переменное количество нулевых значений битов, чтобы иметь возможность установки желаемого значения длины пакета заполнения. Минимальный пакет заполнения не содержит байтов в этом поле. То есть пакет состоит только из длины пакета, типа пакета и CRC, причем в одном варианте используется предварительно выбранная фиксированная длина, равная 6 байтам, или значение длины пакета, равное 4. Значение CRC определяется для всех байтов в пакете, включая длину пакета, которая может быть исключена в ряде других типов пакета.
3. Пакет видеопотока
Пакеты видеопотока несут видеоданные для обновления обычно прямоугольных областей дисплейного устройства. Минимальный размер этой области может составить 1 пиксель, а максимальный размер - весь дисплей в целом. Количество одновременно отображаемых потоков может быть практически любым и ограничивается только системными ресурсами, поскольку весь контекст, требуемый для отображения потока, содержится в пакете видеопотока. Формат одного варианта пакета видеопотока (дескриптор формата видеоданных) показан на фиг.10. Как видно из фиг.10, в одном варианте структура этого типа пакета имеет поля длины пакета (2 байта), типа пакета, идентификатора (ID) b-клиента, дескриптора видеоданных, атрибутов отображения пикселей, левого края Х, верхнего края Y, правого края Х, нижнего края Y, начала Х и Y, отсчета пикселей, CRC параметра, пиксельных данных и CRC пиксельных данных. Этот тип пакета обычно идентифицируется как тип 16, который указан в 2-байтовом поле типа. В одном варианте клиент указывает возможность приема пакета видеопотока, используя поля RGB (красный, зеленый, синий), монохромного формата и возможностей Y Cr Cb в пакете возможностей клиента.
В одном варианте поле идентификатора b-клиента содержит 2 байта информации, которые зарезервированы для ID клиента. Поскольку это заново разработанный коммуникационный протокол, действительные ID клиента еще не известны или недостаточно распространены. Таким образом, биты в этом поле обычно устанавливаются равными нулю, пока неизвестно, когда указанные значения ID могут быть введены или использованы, как очевидно специалистам в данной области техники. Аналогичный процесс обычно подходит для полей ID клиента, обсуждаемых ниже.
Обсужденная выше концепция общих кадров является эффективным способом минимизации размера аудиобуфера и уменьшения задержки. Однако для видеоданных может понадобиться распределить пиксели одного видеокадра по множеству пакетов видеопотока в одном медиакадре. Также весьма вероятно, что пиксели в одном пакете видеопотока не будут точно соответствовать абсолютно прямоугольному окну на дисплее. Для приведенной в качестве примера частоте видеокадров, равной 30 кадров в секунду, частота субкадров составит 300 субкадров в секунду, в результате чего на медиакадр придется 10 субкадров. Если имеется 480 строк пикселей в каждом кадре, то каждый пакет видеопотока в каждом субкадре будет содержать 48 строк пикселей. В других ситуациях пакет видеокадра может не содержать целое число строк пикселей. Это верно и для других размеров видеокадра, когда количество субкадров на один медиакадр не делится точно на количество строк (известных также как видеостроки). Каждый пакет видеокадра обычно должен содержать целое число пикселей, даже если он может не содержать целое число строк пикселей. Это важно, если каждый пиксель представлен более чем одним байтом или если они имеют упакованный формат, как показано на фиг.12.
Формат и контент, используемые для реализации приведенного в качестве примера вышеупомянутого поля дескриптора видеоданных, показаны на фиг.11А-11Е. На фиг.11А-11Е поле дескриптора формата видеоданных содержит 2 байта в виде 16-разрядного целого числа без знака, которое задает формат каждого пикселя в данных пикселей в текущем потоке в текущем пакете. Не исключено, что разные пакеты видеопотока могут использовать разные форматы данных пикселей, то есть использовать разное значение в дескрипторе формата видеоданных, и аналогичным образом поток (область дисплея) может оперативно изменить свой формат данных в процессе работы. Формат данных пикселей должен соответствовать по меньшей мере одному из действительных форматов для клиента, определенных в пакете возможностей клиента. Дескриптор формата видеоданных определяет только формат пикселей для данного пакета, что не предполагает использование постоянного формата в течение всего времени существования конкретного видеопотока.
На фиг. с 11А по 11D показано, как кодируется дескриптор формата видеоданных. На этих фигурах и в этом варианте, когда биты [15:13] равны '000', как показано на фиг.11А, видеоданные состоят из набора монохромных пикселей, где количество бит на пиксель определяется битами с 3 по 0 слова дескриптора формата видеоданных. Биты с 11 по 4 обычно резервируют для будущего использования или приложений и в данной ситуации устанавливают равными нулю. Когда биты [15:13] равны '001', как показано на фиг.11В, то видеоданные состоят из набора цветовых пикселей, каждый из которых задает цвет посредством цветовой карты (палитры). В этой ситуации биты с 5 по 0 слова дескриптора формата видеоданных определяют количество бит на пиксель, а биты с 11 по 6 обычно резервируются для будущего использования или приложений и устанавливаются равными нулю. Если же биты [15:13] равны '010', как показано на фиг.11С, то видеоданные состоят из набора цветовых пикселей, где количество бит на пиксель красного цвета определяется битами с 11 по 8, количество бит на пиксель зеленого цвета определяется битами с 7 по 4, а количество бит на пиксель синего цвета определяется битами с 3 по 0. В этой ситуации суммарное количество бит на каждый пиксель является суммой бит, использованных для красного, зеленого и синего цветов.
Однако в случае, когда биты [15:13] равны '011', как показано на фиг.11D, то видеоданные состоят из набора видеоданных в формате 4:2:2 YCbCr с информацией о яркости и информацией о цветности, где количество бит на пиксель яркости (Y) определяется битами с 11 по 8, количество бит компоненты Cb определяется битами с 7 по 4, а количество бит компоненты Cr определяется битами с 3 по 0. Суммарное количество бит в каждом пикселе определяется суммой бит, использованных для красного, зеленого и синего цветов. Компоненты Cb и Cr посылаются с половинной скоростью от скорости компоненты Y. Вдобавок видеовыборки в части для пиксельных данных этого пакета упорядочены следующим образом: 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 являются значениями яркости для четырех последовательных пикселей в одной сроке слева направо. Если в строке (Х правый край - Х левый край +1) в окне, к которому обращается пакет видеопотока, имеется нечетное количество пикселей, то тогда за значением Y, соответствующим последнему пикселю в каждой строке, будет следовать значение Cb первого пикселя следующей строки, а для последнего пикселя в этой строке значение Cr не посылается. Рекомендуется, чтобы окна, использующие формат Y Cb Cr, имели ширину, равную четному числу пикселей. Данные пикселей в пакете должны содержать четное количество пикселей. Они могут содержать нечетное или четное количество пикселей в случае, когда последний пиксель в пиксельных данных соответствует последнему пикселю строки в окне, заданном в заголовке пакета видеопотока, то есть когда координата Х последнего пикселя в пиксельных данных равна значению Х для правого края.
Когда биты [15:13] равны '100', то видеоданные состоят из набора пикселей в формате Bayer, где количество бит на пиксель определяется битами с 3 по 0 слова дескриптора формата видеоданных. Шаблон группы пикселей определяется битами 5 и 4, как показано на фиг.11Е. Пиксельные данные могут быть расположены в горизонтальном или вертикальном порядке, а пиксели в строках или столбцах могут посылаться в прямом или обратном порядке, что определяется битами с 8 по 6. Биты с 11 по 9 должны быть установлены в нуль. Группа из четырех пикселей в пиксельной группе в формате Bayer подобна тому, что часто называют «единым пикселем» в некоторых дисплейных технологиях. Однако один пиксель в формате Bayer является лишь одним из четырех цветовых пикселей мозаичного шаблона группы пикселей.
Для всех пяти форматов, показанных на упомянутых фигурах, бит 12, обозначенный как «Р», определяет, являются ли выборки пиксельных данных упакованными или являются пиксельными данными с байтовым выравниванием. Значение '0' в этом поле указывает, что каждый пиксель в поле данных пикселей выровнен по границе байта интерфейса MDDI. Значение '1' указывает, что каждый пиксель и каждый цвет в каждом пикселе в пиксельных данных упакован впритык к предыдущему пикселю или цвету в пикселе, так что не остается неиспользованных битов. Различие между форматом пиксельных данных с байтовым выравниванием и упакованным форматом пиксельных данных более подробно показано на фиг. 12, из которой ясно видно, что при применении данных с байтовым выравниванием части субкадра данных могут остаться неиспользованными в отличие от упакованного формата пикселей, где этого не происходит.
Первый пиксель в первом пакете видеопотока медийного кадра для конкретного дисплейного окна попадет в левый верхний угол потокового окна, определяемый левым краем Х и верхним краем Y, а следующий принятый пиксель находится в месте следующего пикселя в той же строке и т.п. В этом первом пакете медийного кадра начальное значение Х обычно равно значению Х для левого края, а начальное значение Y обычно равно значению Y для верхнего края. В последующих пакетах, соответствующих тому же экранному окну, начальные значения Х и Y обычно устанавливаются равными значениям координат пикселя в экранном окне, которые обычно следуют после последнего пикселя, посланного в пакете видеопотока, который был передан в предыдущем субкадре.
4. Пакет аудиопотока
Пакеты аудиопотока несут аудиоданные, воспроизводимые через аудиосистему клиента или предназначенные для автономного устройства представления аудиоданных. Разные потоки аудиоданных могут распределяться по отдельным аудиоканалам в аудиосистеме, например: передний левый, передний правый, центральный, задний левый и задний правый, в зависимости от типа используемой аудиосистемы. Полный комплект аудиоканалов предусмотрен для наушников, которые поддерживают расширенную обработку пространственного акустического сигнала. Клиент указывает, что способен принимать пакет аудиопотока, используя поля возможностей аудиоканала и частоты аудиовыборок в пакете возможностей клиента. Формат пакетов аудиопотока показан на фиг.13.
Как показано на фиг.13, структура пакета этого типа в одном варианте изобретения имеет поля длины пакета, типа пакета, ID b-клиента, ID аудиоканала, резервное 1, отсчета аудиовыборок, количества битов на выборку и упаковки, частоты аудиовыборок, CRC параметра, цифровых аудиоданных и CRC аудиоданных. В одном варианте изобретения этот тип пакета в общем случае идентифицируется как пакет типа 32.
Поле ID b-клиента содержит 3 байта информации, которые зарезервированы для ID клиента, как и ранее. Поле резервное 1 содержит 2 байта, которые зарезервированы для будущего использования, и в обычной конфигурации в данный момент все биты устанавливаются в нуль.
Поле количества битов на выборку и упаковки содержит 1 байт в виде 8-разрядного целого числа без знака, которое задает формат упаковки аудиоданных. Обычно используемый формат содержит биты с 4 по 0 для задания количества битов на аудиовыборку PCM (импульсно-кодовая модуляция). Далее бит 5 определяет, упакованы ли выборки цифровых аудиоданных. Различие между упакованными и выровненными по байтам аудиовыборками (здесь используются 10-битовые выборки) показано на фиг.14. Значение '0' указывает на то, что каждая аудиовыборка PCM в поле цифровых аудиоданных выровнена по байтовой границе интерфейса MDDI, а значение '1' указывает на то, что каждая последующая аудиовыборка PCM упакована впритык с предыдущей аудиовыборкой. Этот бит обычно имеет силу только тогда, когда значение, определенное битами с 4 по 0 (количество бит на аудиовыборку PCM), не кратно восьми. Биты 7 и 6 зарезервированы для будущего использования, и обычно их значения установлены в нуль.
5. Резервные потоковые пакеты
В одном варианте изобретения типы пакетов с 2 по 15, с 18 по 31 и с 33 по 55 зарезервированы для потоковых пакетов, определенных для использования в будущих версиях или вариантах пакетных протоколов, которые могут потребоваться для различных приложений. К тому же это делает интерфейс MDDI более гибким и полезным по сравнению с другими способами в условиях непрекращающихся изменений в технологии и системном проектировании.
6. Потоковые пакеты, определенные пользователем
Восемь типов потока данных, известные как типы с 56 по 63, зарезервированы для использования в патентованных приложениях, которые могут быть определены производителями оборудования для использования с линией связи MDDI. Эти пакеты известны как пакеты потока, определенного пользователем. Указанные пакеты могут использоваться для любой цели, но хост и клиент должны использовать указанные пакеты только в тех ситуациях, когда результат использования до конца понятен или известен. Конкретное определение параметров потока и данных для этих типов пакетов остается за изготовителями специализированного оборудования, реализующими указанные типы пакетов или стремящимися их использовать. Некоторыми примерами использования пакетов потока, определенного пользователем, являются передача параметров и результатов тестирования, заводских данных калибровки и специальных эксплуатационных данных. Формат пакетов потока, определенного пользователем, использованных в одном варианте изобретения, показан на фиг.15. Как показано на фиг.15, структура пакета этого типа имеет поля длины пакета (2 байта), типа пакета, идентификационного номера b-клиента, параметров потока, CRC параметра, потоковых данных и CRC потоковых данных.
7. Пакеты цветовой карты
Пакеты цветовой карты задают контент справочной таблицы цветовой карты, используемой для представления цветов для клиента. Для некоторых приложений может потребоваться цветовая карта, превышающая объем данных, которые можно передать в одном пакете. В этих случаях можно переслать множество пакетов цветовой карты, каждый из которых содержит разный поднабор цветовой карты, путем использования полей сдвига и длины, описанных ниже. Формат пакета цветовой карты по одному варианту изобретения показан на фиг.16. Как показано на фиг.16, структура пакета этого типа имеет поля длины пакета, типа пакета, ID h-клиента, отсчета цветовой карты, сдвига цветовой карты, CRC параметра, данных цветовой карты и CRC данных. В одном варианте этот тип пакета обычно идентифицируется как тип 64 (пакет формата видеоданных и цветовой карты), заданный в поле типа пакета (2 байта).
Клиент указывает, что способен принимать пакеты цветовой карты, используя поля размера цветовой карты и ширины цветовой карты в пакете возможностей клиента.
8. Пакеты инкапсуляции обратной линии связи
В примерном варианте данные пересылаются в обратном направлении с использованием пакета инкапсуляции обратной линии связи. Посылается пакет прямой линии связи, после чего функционирование линии связи MDDI (направление пересылки) изменяется или реверсируется в середине этого пакета, так что пакеты могут пересылаться в обратном направлении. Формат пакета инкапсуляции обратной линии связи по одному варианту изобретения показан на фиг.17. Как показано на фиг.17, структура этого типа пакета имеет поля длины пакета, типа пакета, ID h-клиента, флагов обратной линии связи, делителя обратной скорости, длительности реверсирования 1, длительности реверсирования 2, CRC параметра, поле все нули 1, поле Реверсирование 1, поле обратных пакетов данных, поле реверсирование 2 и поле все нули 2. В одном варианте пакет этого типа обычно идентифицируется как пакет типа 65. Для внешнего режима каждый хост должен иметь возможность создать этот пакет и принимать данные, а каждый клиент должен быть способен принимать и посылать данные на хост. Реализация этого пакета не обязательна для внутреннего режима.
Контроллер канала связи MDDI при посылке пакета инкапсуляции обратной линии связи функционирует особым образом. Интерфейс MDDI имеет стробирующий сигнал, который в общем случае всегда возбуждается хостом как контроллером канала связи. Хост функционирует, как будто бы он передает ноль для каждого бита из частей пакетов реверсирования и обратных данных в пакете инкапсуляции обратной линии связи. Хост переключает сигнал MDDI_Strobe на границе каждого бита в течение двух реверсирований и в течение времени, выделенного для пакетов обратных данных. (Хост действует так, как будто он передает данные со всеми нулями).
Хост блокирует свои драйверы линии для сигналов данных MDDI во время периода, определенного полем реверсирование 1, а клиент вновь включает свои драйверы линии во время поля повторного включения драйвера, следующего за временным периодом, заданным полем реверсирование 2. Клиент считывает параметр длительность реверсирования и направляет сигналы данных в хост сразу после последнего бита в поле реверсирование 1. То есть клиент запускает новые данные в линию связи по определенным передним фронтам стробирующего импульса MDDI, как определено ниже в описании контента пакета. Клиент использует параметры длина пакета и длительность реверсирования, чтобы узнать длину временного интервала, который доступен ему для посылки пакетов на хост. Клиент может послать пакеты заполнения или перевести линии передачи данных в нулевое состояние, когда у него нет данных для посылки на хост. Если линии передачи данных установлены в нулевое состояние, хост интерпретирует это как пакет нулевой длины (нет действительной длины) и хост на интервале пакета инкапсуляции обратной линии связи больше не принимает никаких пакетов от клиента.
Хост устанавливает сигналы MDDI_Data на уровень логического нуля во время поля все нули 1, а клиент устанавливает линии передачи данных MDDI на уровень логического нуля в течение по меньшей мере одного тактового периода обратной линии связи перед началом поля реверсирование 2, то есть на интервале поля все нули 2. Это поддерживает линии передачи данных в детерминированном состоянии на временном интервале полей реверсирование 1 и реверсирование 2. Если у клиента больше нет пакетов для посылки, он может заблокировать линии передачи данных после установки их на уровень логического нуля, поскольку резисторы смещения для режима бездействия (обсуждаемые в другом месте) удерживают линии передачи данных на уровне логического нуля для оставшейся части поля пакетов обратных данных или на интервале примерно 16 или более байт прямой линии связи.
В одном варианте поле запроса обратной линии связи в пакете клиентского запроса и состояния может быть использовано для информирования хоста о количестве байт, которое необходимо клиенту в пакете инкапсуляции обратной линии связи для посылки данных обратно на хост. Хост пытается предоставить запрос путем распределения по меньшей мере указанного количества байт в пакете инкапсуляции обратной линии связи. Хост может послать в одном субкадре более одного пакета инкапсуляции обратной линии связи. Клиент может послать пакет запроса и состояния клиента практически в любой момент, а хост будет интерпретировать параметр запроса обратной линии связи как суммарное количество байтов, запрошенных в одном субкадре.
9. Пакеты возможностей клиента
Хосту необходимо знать возможности клиента (дисплея), с которым он осуществляет связь, чтобы сконфигурировать линию связи хост-клиент оптимальным или желаемым образом. Рекомендуется, чтобы дисплей посылал на хост пакет возможностей клиента после выполнения синхронизации прямой линии связи. Считается, что передача указанного пакета необходима при запросе со стороны хоста с использованием флагов обратной линии связи в пакете инкапсуляции обратной линии связи. Пакет возможностей клиента используется для информирования хоста о возможностях клиента. Для внешнего режима каждый хост должен иметь возможность приема этого пакета, а каждый клиент должен иметь возможность посылки этого пакета для полного использования данного интерфейса и протокола. Реализация этого пакета не обязательна для внутреннего режима, поскольку возможности клиента, такого как дисплей, в этой ситуации должны быть четко определены и известны хосту на момент изготовления или сборки в единой компоненте или блоке некоторого типа.
Формат пакета возможностей клиента в одном варианте изобретения показан на фиг.18. Как показано на фиг.18, структура пакета этого типа имеет поля длины пакета, типа пакета, ID с-клиента, версии протокола, минимальной версии протокола, возможностей по скорости передачи данных, возможностей по типу интерфейса, количества альтернативных дисплеев, поле резервное 1, а также поля ширины битовой карты, высоты битовой карты, ширины дисплейного окна, высоты дисплейного окна, размера цветовой карты, ширины RGB, возможностей RGB, возможностей монохромного формата, поле резервное 2, и поля возможностей Y Cr Cb, возможностей формата Bayer, плоскостей изображения альфа-курсора, возможностей клиента, максимальной частоты видеокадров, минимальной частоты видеокадров, минимальной частоты субкадров, глубины аудиобуфера, возможностей аудиоканала, возможностей по частоте аудиовыборки, разрешающей способности аудиовыборки, разрешающей способности микрофона, возможностей по частоте микрофона, формата данных клавиатуры, формата данных указательного устройства, типа защиты контента, имени изготовителя, кода продукта, поле резервное 4, поля порядкового номера, недели изготовления, года изготовления, и CRC. В приведенном в качестве примера варианте пакет этого типа обычно идентифицируется как пакет типа 66.
10. Пакеты данных клавиатуры
Пакет данных клавиатуры используется для посылки данных клавиатуры от клиентского устройства на хост. Беспроводная (или проводная) клавиатура может быт использована вместе с различными дисплеями или аудиоустройствами, в том числе, но не только, со смонтированным на голове устройством видеоотображения/аудиопредставления. Пакет данных клавиатуры передает данные клавиатуры, полученные от одного из ряда известных клавиатурных устройств, на хост. Этот пакет можно также использовать в прямой линии связи для посылки данных на клавиатуру. Клиент указывает, что способен посылать и принимать пакеты данных клавиатуры, используя поле данных клавиатуры в пакете возможностей клиента.
Формат пакета данных клавиатуры показан на фиг.19 и содержит переменное количество байтов информации, идущей от или направляемой на клавиатуру. Как показано на фиг.19, структура пакета этого типа имеет поля длины пакета, типа пакета, ID b-клиента, формата данных клавиатуры, данных клавиатуры и CRC. Здесь пакет этого типа в общем случае идентифицирован как пакет типа 67.
ID b-клиента, как и ранее, является резервным полем, а проверка CRC выполняется по всем байтам пакета. Поле формата данных клавиатуры содержит 2-байтовое значение, описывающее формат данных клавиатуры. Биты с 6 по 0 должны быть идентичны полю формата данных клавиатуры в пакете возможностей клиента. Это значение не равно 127. Биты с 15 по 7 зарезервированы для будущего использования и поэтому в данный момент установлены в нуль.
11. Пакеты данных указательного устройства
Пакет данных указательного устройства используют для посылки информации о положении от беспроводной мыши или другого указательного устройства клиента на хост. Используя этот пакет, данные можно также посылать на указательное устройство по прямой линии связи. Пример формата пакета данных указательного устройства показан на фиг.20, причем он содержит переменное количество байтов информации, получаемых от или направляемых на указательное устройство. Как показано на фиг.20, структура пакета этого типа имеет поля длины пакета, типа пакета, ID b-клиента, формата указательного устройства, данных указательного устройства и CRC. В приведенном в качестве примера варианте пакет этого типа обычно идентифицируется как пакет типа 68 в 1-байтовом поле типа.
12. Пакеты отключения линии связи
Пакет отключения линии связи посылается от хоста клиенту, чтобы указать на то, что данные и стробирующие импульсы MDDI будут отключены и произойдет переход в состояние «бездействия» с низким энергопотреблением. Этот пакет полезен для отключения линии связи и экономии энергии, после того как из устройства мобильной связи на дисплей посланы статические битовые карты или когда больше нет информации для пересылки от хоста клиенту в текущее время. Нормальная работа возобновляется, когда хост вновь посылает пакеты. Первым пакетом, посылаемым после бездействия, является пакет заголовка субкадра. Формат пакета состояния клиента показан на фиг.21. Как показано на фиг.21, структура пакета этого типа имеет поля длины пакета, типа пакета, CRC и поле все нули. В одном варианте пакет этого типа в общем случае идентифицируется как пакет типа 69 в 1-байтовом поле типа, причем в этом типе используется заранее выбранная фиксированная длина, равная 3 байтам.
В состоянии бездействия с низким энергопотреблением драйвер MDDI_Data переводится в состояние с высоким импедансом, а сигналы MDDI_Data устанавливаются в состояние логического нуля с использованием цепи смещения с высоким импедансом, которая может быть перевозбуждена клиентом. Стробирующий сигнал, используемый интерфейсом, устанавливается в состоянии бездействия на уровень логического нуля для минимизации энергопотребления. Хост или клиент может вызвать переход линии связи MDDI из состояния бездействия в активное состояние, как описано в другом месте, что является ключевым улучшением и преимуществом настоящего изобретения.
13. Пакеты клиентского запроса и состояния
Хосту, для того чтобы он смог сконфигурировать линию связи «хост-клиент» в общем случае оптимальным образом, требуется получить от клиента информацию в небольшом объеме. Рекомендуется, чтобы клиент посылал хосту один пакет клиентского запроса и состояния в каждом субкадре. Клиент должен послать этот пакет в качестве первого пакета в пакете инкапсуляции обратной линии связи для обеспечения его надежной доставки хосту. Посылка этого пакета выполняется также при запросе со стороны хоста с использованием флагов обратной линии связи в пакете инкапсуляции обратной линии связи. Пакет клиентского запроса и состояния используется для передачи хосту сообщения об ошибках и состоянии. Каждый хост должен иметь возможность принять этот пакет, а каждый клиент должен иметь возможность послать этот пакет, чтобы правильно или оптимально использовать протокол интерфейса MDDI.
Формат пакета клиентского запроса и состояния показан на фиг.22. Как показано на фиг.22, структура пакета этого типа имеет поля длины пакета, типа пакета, ID c-клиента, запроса обратной линии связи, изменения возможностей, графических дефектов, отсчета ошибок CRC и поле CRC. Пакет этого типа обычно идентифицируется как пакет типа 70 в 1-байтовом поле типа и, как правило, использует предварительно выбранную фиксированную длину, равную 12 байт.
Поле запроса обратной линии связи можно использовать для информирования хоста о количестве байтов, необходимых клиенту в пакете инкапсуляции обратной линии связи для посылки данных обратно на хост. Хост должен попытаться предоставить запрос путем распределения по меньшей мере указанного количества байтов в пакете инкапсуляции обратной линии связи. Хост может послать в одном субкадре более одного пакета инкапсуляции обратной линии связи для размещения данных. Клиент может послать пакет клиентского запроса и состояния в любое время, а хост будет интерпретировать параметр запроса обратной линии связи как суммарное количество байт, запрошенных в одном субкадре. Дополнительные подробности и специальные примеры, касающиеся того, как данные обратной линии связи посылаются назад хосту, приведены ниже.
14. Пакеты пересылки блоков бит
Пакет пересылки блоков бит обеспечивает средство для прокрутки областей дисплея в любом направлении. Дисплеи, которые имеют эту возможность, сообщают о ней в бите 0 поля индикаторов характеристик дисплея в пакете возможностей клиента. Формат пакета пересылки блоков бит показан на фиг.23. Как показано на фиг.23, структура пакета этого типа имеет поля длины пакета, типа пакета, ID h-клиента, левого верхнего значения Х, левого верхнего значения Y, ширины окна, высоты окна, перемещения окна по Х, перемещения окна по Y и поле CRC. Пакет этого типа идентифицируется обычно как пакет типа 71, причем здесь используется предварительно выбранная фиксированная длина, равная 15 байт.
Указанные поля используются для задания значений координат Х и Y левого верхнего угла окна, подлежащего перемещению, ширины и высоты окна, подлежащего перемещению, и количества пикселей, на которое должно быть перемещено окно по горизонтали и вертикали соответственно. Положительные значения для двух последних полей вызывают перемещение окна вправо и вниз, а отрицательные значения вызывают перемещение влево и вверх соответственно.
15. Пакеты заполнения площади битовой карты
Пакет заполнения площади битовой карты обеспечивает средство для простой инициализации области дисплея одного цвета. Дисплеи, которые имеют эту возможность, сообщают о ней в бите 1 поля индикаторов характеристик клиента в пакете возможностей клиента. Формат пакета заполнения площади битовой карты показан на фиг.24. Как показано на фиг.24, структура пакета этого типа имеет поля длины пакета, типа пакета, ID h-клиента, левого верхнего значения Х, левого верхнего значения Y, ширины окна, высоты окна, дескриптора формата данных, значения заполнения площади пикселей и поле CRC. Пакет этого типа обычно идентифицируется как пакет типа 72 в 1-байтовом поле типа, причем здесь используется предварительно выбранная фиксированная длина, равная 17 байт.
16. Пакеты заполнения шаблона битовой карты
Пакет заполнения шаблона битовой карты обеспечивает средство для простой инициализации области дисплея с заранее выбранным шаблоном. Дисплеи, имеющие эту возможность, сообщают о ней в бите 2 поля характеристик клиента в пакете возможностей клиента. Левый верхний угол заполненного шаблона выравнивается по левому верхнему углу заполняемого окна. Если заполняемое окно шире или выше полного шаблона, то тогда шаблон можно повторить по горизонтали или вертикали несколько раз, чтобы заполнить окно. Правая или нижняя часть последнего повторенного шаблона усекается, если это необходимо. Если окно меньше полного шаблона, то тогда правая сторона или нижняя часть полного шаблона может быть усечена, чтобы поместиться в окне.
Формат пакета заполнения шаблона битовой карты показан на фиг.25. Как показано на фиг.25, структура пакета этого типа имеет поля длины пакета, типа пакета, ID h-клиента левого, верхнего значения Х, левого верхнего значения Y, ширины окна, высоты окна, ширины шаблона, высоты шаблона, дескриптора формата данных, CRC параметра, пиксельных данных шаблона и поле CRC пиксельных данных. Пакет этого типа обычно идентифицируется как пакет типа 73 в 1-байтовом поле типа.
17. Пакеты канала данных линии связи
Пакет канала данных линии связи обеспечивает клиента вычислительными возможностями высокого уровня, такого как PDA, средством для осуществления связи с беспроводным приемопередатчиком, таким как сотовый телефон или беспроводное устройство с портом данных. В этой ситуации линии связи MDDI действует как удобный высокоскоростной интерфейс между устройством связи и вычислительным устройством с мобильным дисплеем, где описываемый пакет транспортирует данные на канальном уровне операционной системы для устройства. Например, этот пакет может быть использован, если в мобильный дисплей были встроены Web-браузер, почтовый клиент или целый PDA. Дисплеи, которые имеют эту возможность, сообщают о ней в бите 3 поля характеристик клиента в пакете возможностей клиента.
Формат пакета канала данных линии связи показан на фиг.26. Как показано на фиг.26, структура пакета этого типа имеет длину пакета, тип пакета, ID h-клиента,
CRC параметра, данных линии связи и CRC данных связи. Пакет этого типа обычно идентифицируется как пакет типа 74 в поле типа.
18. Пакеты запроса переключения типа интерфейса
Пакет запроса переключения типа интерфейса позволяет хосту сделать запрос на переключение клиента или дисплея с существующего или текущего режима на режим типа 1 (последовательный), типа 2 (2-битовый параллельный), типа 3 (4-битовый параллельный) или типа 4 (8-битовый параллельный). Прежде чем хост делает запрос конкретного режима, необходимо подтвердить, что клиент способен работать в требуемом режиме путем оценки битов 6 и 7 поля индикаторов характеристик дисплея в пакете возможностей клиента. Формат пакета запроса переключения типа интерфейса показан на фиг.27. Как показано на фиг.27, структура пакета этого типа имеет поля длины пакета, типа пакета, типа интерфейса, поле резервное 1 и поле CRC. Пакет этого типа обычно идентифицируется как пакет типа 75, который использует заранее выбранную фиксированную длину, равную 4 байтам.
19. Пакеты подтверждения типа интерфейса
Пакет подтверждения типа интерфейса посылается клиентом для подтверждения приема пакета переключения типа интерфейса. Запрошенный режим: типа 1 (последовательный), типа 2 (2-битовый параллельный), типа 3 (4-битовый параллельный) или типа 4 (8-битовый параллельный), возвращаются назад хосту в виде параметра в этом пакете. Формат пакета подтверждения типа интерфейса показан на фиг.28. Как показано на фиг.28, структура пакета этого типа имеет поля длины пакета, типа пакета, ID c-клиента, типа интерфейса, поле резервное 1 и поле CRC. Пакет этого типа обычно идентифицируется как пакет типа 76, который использует заранее выбранную фиксированную длину, равную 4 байтам.
20. Пакеты переключения типа выполнения
Пакет переключения типа исполнения является средством, позволяющим хосту дать клиенту команду переключиться на режим, заданный в этом пакете. Это должен быть тот же режим, который был ранее запрошен и подтвержден пакетом запроса переключения типа интерфейса и пакетом подтверждения типа интерфейса. Хост и клиент после посылки этого пакета должны переключиться на согласованный режим. Клиент может потерять и снова восстановить синхронизацию линии связи во время изменения режима. Формат пакета переключения типа выполнения показан на фиг.29. Как показано на фиг.29, структура пакета этого типа имеет поля длины пакета, типа пакета, поле резервное 1 и поле CRC. Пакет этого типа обычно идентифицируется как пакет типа 77 в 1-байтовом поле типа, который использует заранее выбранную фиксированную длину, равную 4 байтам.
21. Пакеты разблокирования прямого аудиоканала
Этот пакет позволяет хосту разблокировать или блокировать аудиоканалы у клиента. Эта возможность является весьма полезной, так как клиент (например, дисплей) может отключить питание аудиоусилителей или аналогичных схемных элементов для экономии энергии, когда отсутствуют аудиоданные, выводимые хостом. Гораздо труднее реализовать это в неявном виде, просто используя в качестве индикатора наличие или отсутствие аудиопотоков. По умолчанию, когда система клиента подключена к питанию, все аудиоканалы разблокированы. Формат пакета разблокирования прямого аудиоканала показан на фиг.30. Как показано на фиг.30, структура пакета этого типа имеет поля длины пакета, типа пакета, ID h-клиента, маски разблокирования аудиоканала и поле CRC. Пакет этого типа обычно идентифицируется как пакет типа 78 в 1-байтовом поле типа, который использует заранее выбранную фиксированную длину, равную 4 байтам.
22. Пакеты частоты выборки обратного аудиосигнала
Этот пакет позволяет хосту разблокировать или блокировать аудиоканал обратной линии связи и устанавливать частоту выборки аудиоданных этого потока. Хост выбирает частоту выборки, которая определяется в качестве действительной в пакете возможностей клиента. Если хост выбирает ошибочную частоту выборки, то клиент не будет посылать аудиопоток на хост, а хосту может быть послано сообщение о соответствующей ошибке в пакете клиентского сообщения об ошибке. Хост может заблокировать аудиопоток обратной линии связи, установив значение частоты выборки, равное 255. По умолчанию считается, что, когда клиентская система изначально подсоединена или подключена к питанию, то аудиопоток обратной линии связи заблокирован. Формат пакета частоты выборки обратного аудиосигнала показан на фиг.31. Как показано на фиг.31, структура пакета этого типа имеет поля длины пакета, типа пакета, ID h-клиента, частоты выборки аудиосигнала, поле резервное 1 и поле CRC. Пакет этого типа обычно идентифицируется как пакет типа 79, который использует заранее выбранную фиксированную длину, равную 4 байтам.
23. Пакеты служебных данных защиты цифрового контента
Этот пакет позволяет хосту и клиенту обмениваться сообщениями, относящимися к используемому способу защиты цифрового контента. В настоящее время рассматриваются два типа защиты контента: система защиты цифрового контента передачи (DTCP) или сверхширокополосная система защиты цифрового контента (HDCP), причем зарезервировано место для названий будущих альтернативных схем защиты. Используемый способ задается параметром тип защиты контента в этом пакете. Формат пакета служебных данных защиты цифрового контента показан на фиг.32. Как показано на фиг.32, структура пакета этого типа имеет поля длины пакета, типа пакета, ID b-клиента, типа защиты контента, служебных сообщений о защите контента и поле CRC. Пакет этого типа обычно идентифицируется как пакет типа 80.
24. Пакеты разрешения прозрачного цвета
Пакет разрешения прозрачного цвета используется для того, чтобы задать на дисплее тот или иной прозрачный цвет и чтобы разрешить или не разрешить использование прозрачного цвета для отображаемых изображений. Дисплеи, имеющие эту возможность, сообщают о ней в бите 4 поля отличительных возможностей клиента в пакете возможностей клиента. Когда пиксель со значением для прозрачного цвета записывается в битовую карту, цвет не изменяется относительно предыдущего значения. Формат пакета разрешения прозрачного цвета показан на фиг.33. Как показано на фиг.33, структура пакета этого типа имеет поля длины пакета, типа пакета, ID h-клиента, разрешения прозрачного цвета, поле резервное 1, поля идентификатора альфа-курсора, дескриптора формата данных, значения прозрачного пикселя и поле CRC. Пакет этого типа обычно идентифицируется как пакет типа 81 в 1-байтовом поле типа, который использует предварительно выбранную фиксированную длину, равную 10 байт.
25. Пакеты измерения задержки при передаче в прямом и обратном направлениях
Пакет измерения задержки при передаче в прямом и обратном направлениях используется для измерения задержки распространения от хоста к клиенту (дисплей) плюс задержки распространения от клиента (дисплей) обратно к хосту. Это измерение по сути включает в себя задержки, которые существуют в драйверах и приемниках линий и подсистеме соединений между отдельными элементами интерфейса. Это измерение используется для установки задержки на реверсирование и параметров делителя скорости передачи по обратной линии связи в пакете инкапсуляции обратной линии связи, описанного в целом выше. Описываемый пакет наиболее полезен тогда, когда линия связи MDDI работает с максимальной скоростью, предусмотренной для конкретного приложения. Сигнал MDDI_Stb действует, как будто бы в последующих полях (оба поля защитных интервалов, поле все нули и поле период измерения) посылаются данные со всеми нулями. Это заставляет MDDI_Stb переключиться при половинной скорости передачи данных, так что это событие можно использовать как периодический тактовый сигнал у клиента в течение периода измерения.
В одном варианте клиент обычно указывает, что способен поддерживать пакет измерения задержки на передачу в прямом и обратном направлениях посредством использования бита 18 поля индикаторов отличительных возможностей клиента в пакете возможностей клиента. Рекомендуется, чтобы измерение задержки на передачу в прямом и обратном направлениях поддерживали все клиенты, но хост может иметь информацию о наихудшем значении задержки на передачу в прямом и обратном направлениях на основе максимальной задержки в кабелях и максимальных задержек в драйвере и приемнике. Хост может также заранее знать значение задержки на передачу в прямом и обратном направлениях для линии связи MDDI, используемой во внутреннем режиме, поскольку это относится к расчетным параметрам известных элементов (длина проводников, тип схемы, характеристики элементов и т.д.) устройства, в котором используется интерфейс.
Формат пакета измерения задержки на передачу в прямом и обратном направлениях показан на фиг.34. Как показано на фиг.34, структура пакета этого типа имеет поля длины пакета, типа пакета, ID h-клиента, CRC параметра, защитного интервала 1, периода измерения, поля все нули и поле защитного интервала 2. Пакет этого типа обычно идентифицируется как пакет типа 82, который использует предварительно выбранную фиксированную длину, равную 533 бита.
Временные соотношения между событиями, которые происходят по ходу пакета измерения задержки на передачу в прямом и обратном направлениях, показаны на фиг.35. На фиг.35 хост передает пакет измерения задержки на передачу в прямом и обратном направлениях, показанный присутствием полей CRC параметра и выравнивания стробирующего сигнала, за которыми следуют поле все нули и поле защитного интервала 1. Задержка 3502 появляется, прежде чем пакет достиг клиентского устройства отображения или схем обработки. Когда клиент принимает пакет, он передает 0хff, 0хff и 30 байт шаблона 0×0 с точностью, целесообразной для использования в начале периода измерения, которая определяется клиентом. С точки зрения хоста действительный момент времени, с которого клиент начинает передачу этой последовательности, задерживается относительно начала периода измерения. Величина этой задержки по существу представляет собой время, затраченное на прохождение пакета через драйверы и приемники линии и систему соединений (кабели, проводники). Подобная величина задержки 3504 имеет место для шаблона при передаче от клиента обратно на хост.
Для точного определения длительности задержки на передачу в прямом и обратном направлениях для сигналов, идущих к и от клиента, хост подсчитывает количество битовых интервалов по прямой линии связи, появляющихся после начала периода измерения, пока не будет обнаружено поступление 0xff, 0хff и 30 байтов последовательности 0x0. Эту информацию используют для определения времени, необходимого сигналу для прохождения в прямом и обратном направлениях от хоста к клиенту и от клиента назад к хосту. Затем около половины этой величины определяют как задержку, создаваемую во время прохождения однонаправленного сигнала к клиенту.
Хост и клиент поддерживают линию на уровне логического нуля в течение обоих защитных интервалов, чтобы поддерживать линии MDDI_Data в заданном состоянии. Нагрузочные и согласующие резисторы в состоянии бездействия (см. фиг.42) обеспечивают удержание сигналов MDDI_Data на действительном низком уровне на тех интервалах, где драйверы линии заблокированы как в хосте, так и у клиента.
26. Пакет калибровки асимметрии прямой линии связи
Пакет калибровки асимметрии прямой линии связи позволяет клиенту или дисплею самому откалибровать различия в задержке распространения сигналов MDDI_Data относительно сигнала MDDI_Stb. Без компенсации асимметрии задержки максимальная скорость передачи данных обычно ограничивается, чтобы учесть потенциально худшее отклонение в этих задержках. Обычно этот пакет посылают только тогда, когда скорость передачи данных по прямой линии связи установлена равной порядка 50 Мбит/с или ниже. После посылки этого пакета для калибровки дисплея скорость передачи данных может быть поднята выше 50 Мбит/с. Если скорость передачи данных установлена слишком высокой в ходе процесса калибровки асимметрии, то дисплей может синхронизироваться по паразитному сигналу битового периода, который может вызвать отключение компенсации асимметрии задержки более чем на один битовый интервал, что приедет к ошибочному тактированию данных. Интерфейс, относящийся к типу, обеспечивающему максимальную скорость передачи данных или к высшему типу, выбирают до посылки пакета калибровки асимметрии прямой линии связи, так чтобы калибровка выполнялась для всех существующих битов данных.
Формат пакета калибровки асимметрии прямой линии связи показан на фиг.56. Как показано на фиг.56, структура пакета этого типа имеет поля длины пакета (2 байта), типа пакета, CRC параметра, последовательности данных калибровки и поле CRC. Пакет этого типа обычно идентифицируется как пакет типа 83 в поле типа и имеет предварительно выбранную длину 515.
Виртуальная панель управления
Использование виртуальной панели управления (VCP) позволяет хосту установить некоторые пользовательские средства управления у клиента. Благодаря возможности настройки этих параметров хостом пользовательский интерфейс у клиента может быть упрощен, поскольку экраны, которые позволяют пользователю настраивать параметры, такие как громкость звука или яркость отображения, могут быть созданы программным обеспечением хоста, а не одним или несколькими микропроцессорами у клиента. Хост способен считывать настройки параметров у клиента и определять диапазон действительных значений для каждого управляющего элемента. Клиент имеет возможность сообщить хосту, какие управляющие параметры можно настроить.
Для задания управляющих элементов и настроек у клиента используют управляющие коды (коды VCP) и соответствующие, обычно заданные значения данных. Коды VCP в спецификации MDDI расширены до 16 бит для сохранения правильного выравнивания полей данных в определениях пакетов, а в будущем для поддержки дополнительных значений, являющихся уникальными для данного интерфейса или будущих усовершенствованных вариантов.
27. Пакет запроса характеристик VCP
Пакет запроса характеристик VCP обеспечивает средство, механизм или способ запроса хостом текущей настройки определенного параметра управления или всех действительных параметров управления. В общем случае клиент реагирует на пакет VCP, передавая соответствующую информацию в ответном пакете характеристик VCP. В одном варианте клиент указывает на возможность поддержки пакета характеристик VCP, используя бит 20 поля индикаторов отличительных возможностей клиента в пакете возможностей клиента.
Формат пакета характеристик VCP в одном варианте показан на фиг.69. Как показано на фиг.69, структура пакета этого типа имеет поля длины пакета, типа пакета, ID h-клиента, кода MCCS VCP, а также поле CRC. Пакет этого типа обычно идентифицируется в одном варианте как пакет типа 128, который указан в 2-байтовом поле типа. Длина пакета, которая задает общее количество байтов в пакете, не считая поля длины пакета, как правило, для пакета этого типа является фиксированной и составляет 8 байт.
Поле ID h-клиента содержит 16-разрядное целое число без знака, зарезервированное для ID клиента. Это поле зарезервировано для будущего использования и обычно установлено в нуль. Поле кода MCCS VCP содержит 2 байта информации, которая задает параметр управляющего кода MCCS VCP. Значение в диапазоне от 0 до 255 вызывает возвращение ответного пакета характеристик VCP с одним пунктом в ответном списке характеристик VCP, соответствующем заданному коду MCCS. Код MCCS VCP равный 65535 (0хffff) запрашивает ответный пакет характеристик VCP с ответным списком VCP, содержащим пункт ответного списка для каждого управляющего элемента, поддерживаемого клиентом. Значения от 256 до 65534 для этого поля зарезервированы для будущего использования и в настоящее время не используются.
28. Ответный пакет характеристик VCP
Ответный пакет характеристик VCP обеспечивает средство, механизм или способ реакции клиента на запрос хоста с текущей настройкой определенного параметра управления или всех действующих параметров управления. Обычно клиент посылает ответный пакет характеристик VCP в ответ на пакет характеристик VCP. Этот пакет нужен для того, чтобы определить текущую настройку определенного параметра, определить действительный диапазон для определенного параметра, определить, поддерживается ли клиентом определенный управляющий элемент, или определить набор управляющих элементов, который поддерживается клиентом. Если послан пакет с запросом характеристик VCP, который ссылается на определенный управляющий элемент, не реализуемый клиентом, то тогда ответный пакет характеристик VCP возвращается с единственным пунктом в ответном списке характеристик VCP, соответствующим нереализованному управляющему элементу, и с соответствующим кодом ошибки. В одном варианте клиент указывает, что он способен поддерживать ответный пакет характеристик VCP, используя бит 20 поля индикаторов отличительных возможностей дисплея в пакете возможностей клиента.
Формат ответного пакета характеристик VCP в одном варианте показан на фиг.70. Как показано на фиг.70, структура пакета этого типа имеет поля длины пакета, типа пакета, ID с-клиента, версии MCCS, номера ответной последовательности, ответного списка характеристик VCP, а также поле CRC. Пакет этого типа обычно идентифицируется в одном варианте как пакет типа 129, как показано в 2-байтовом поле типа.
Поле ID c-клиента содержит информацию, зарезервированную для ID клиента. Это поле зарезервировано для будущего использования и обычно устанавливается в нуль. Поле версии MCCS содержит 2 байта информации, которая задает версию спецификации VESA MCCS, реализованную клиентом.
2-байтовое поле порядкового номера ответа содержит информацию или данные, которые задают порядковый номер ответных пакетов характеристик VCP, возвращенных клиентом. Клиент возвращает один или несколько ответных пакетов характеристик VCP в ответ на пакет запроса характеристик VCP со значением управляющего кода MCCS равным 65535. Клиент может расширить ответный список характеристик на множество ответных пакетов VCP. В этом случае клиент присваивает каждому последовательному пакету порядковый номер, и порядковые номера ответных пакетов характеристик VCP, посланные в ответ на один пакет запроса характеристик VCP, начинается с нуля и возрастает на единицу. Последний пункт списка характеристик VCP в ответном пакете характеристик VCP должен содержать значение управляющего кода MCCS VCP, равное 0xffff, для идентификации того, что пакет является последним и содержит максимальный порядковый номер группы возвращенных пакетов. Если в ответ на пакет запроса характеристик VCP посылается только один ответный пакет характеристик VCP, то тогда порядковый номер ответа в этом одном пакете равен нулю, а список ответов с характеристиками VCP содержит запись, имеющую управляющий код MCCS VCP, равный 0xffff.
Количество характеристик в поле списка содержит 2 байта, которое задает количество пунктов списка характеристик VCP, которые имеются в ответном списке характеристик VCP в этом пакете, в то время как поле ответного списка характеристик VCP представляет собой группу байтов, содержащую один или несколько пунктов ответного пакета характеристик VCP. Формат одного пункта ответного списка характеристик VCP по одному варианту изобретения показан на фиг.71.
Как показано на фиг.71, каждый пункт ответного списка характеристик VCP имеет точно 12 байт в длину и содержит поля кода MCCS VCP, результирующего кода, максимального значения и текущего значения. 2-байтовое поле кода MCCS VCP содержит данные или информацию, которая задает параметр управляющего кода MCCS VCP, связанный с этим пунктом списка. Действительными считаются только значения управляющего кода, определенные в версии 2 спецификации VESA MCCS и более поздних версиях. 2-байтовое поле результирующего кода содержит информацию, которая задает код ошибки, относящийся к запросу информации, касающейся заданного управляющего элемента MCCS VCP. Значение '0' в этом поле означает отсутствие ошибки, в то время как значение '1' означает, что заданный управляющий элемент у клиента не реализован. Дополнительные значения для этого поля от 2 до 65535 зарезервированы в настоящее время для будущего использования и реализации другого предполагаемого приложения, и сейчас использоваться не должны.
4-байтовое поле максимального значения содержит 32-разрядное целое число без знака, задающее максимально возможное значение, которое можно установить для заданного управляющего элемента MCCS. Если запрошенный управляющий элемент у клиента не реализован, это значение устанавливают в нуль. Если возвращаемое значение по длине меньше 32 бит (4 байта), то тогда это значение приводится в виде 32-разрядного целого числа, где старшие значащие (неиспользованные) байты установлены в нуль. 4-байтовое поле текущего значения содержит информацию, задающую текущее значение заданного непрерывного (С) или дискретного (NC) управляющего элемента MCCS VCP. Если запрошенный управляющий элемент у клиента не реализован или если этот управляющий элемент реализован, но относится к типу табличных (Т) данных, то это значение устанавливают в нуль. Если возвращаемое значение по длине меньше 32 бит (4 байта) согласно спецификации VESA MCCS, то тогда это значение приводится в виде 32-разрядного целого числа, где старшие значащие (неиспользованные) байты установлены в нуль.
29. Пакет установки характеристик VCP
Пакет установки характеристик VCP обеспечивает средство, механизм или способ, позволяющий хосту установить значения управляющих элементов VCP как для непрерывных, так и для дискретных управляющих элементов у клиента. В одном варианте клиент указывает, что он способен поддерживать пакет установки характеристик VCP, используя бит 20 поля индикаторов отличительных возможностей дисплея в пакете возможностей клиента.
Формат пакета установки характеристик VCP в одном варианте изобретения показан на фиг.72. Как показано на фиг.72, структура пакета этого типа имеет поля длины пакета, типа пакета, ID h-клиента, кода MCCS VCP, количества значений в списке, списка значений для управляющих элементов и поле CRC. Пакет этого типа обычно идентифицируется как пакет типа 130, указанный в 2-байтовом поле типа, и имеет длину 20 байт, исключая поле длины пакета.
Поле ID h-клиента также использует 2-байтовое значение для задания или действия в качестве ID клиента. Это поле зарезервировано для будущего использования и в настоящее время установлено в нуль. Поле кода MCCS VCP использует 2 информационных байта или значения для задания параметра кода управляющего элемента MCCS VCP, подлежащего настройке. 2-байтовое количество значений в поле списка содержит информацию или значение, задающее количество 16-разрядных значений, имеющихся в списке значений для управляющих элементов. Список значений для управляющих элементов обычно содержит один пункт, если код управляющего элемента MCCS не относится к таблице у клиента. В случае когда управляющие элементы не относятся к таблице, список значений управляющих элементов будет содержать значение, которое задает новое значение, подлежащее записи в параметре управляющего элемента, заданном полем кода MCCS VCP. Для управляющих элементов, относящихся к таблице, формат данных в списке значений управляющих элементов задается описанием параметров в заданном коде MCCS VCP. Если список содержит значения, большие одного байта, то тогда младший значащий байт передается первым согласно способу, описанному в другом месте. Наконец, 2-байтовое поле CRC содержит 16-разрядную проверку CRC всех байтов в пакете, включая длину пакета.
30. Пакет запроса действительных параметров
Пакет запроса действительных параметров используется как средство или механизм запроса у клиента ответного пакета с действительными параметрами, содержащего список параметров, поддерживаемых определенным дискретным (NC) или табличным (Т) управляющим элементом. Этот пакет должен задавать только дискретные управляющие элементы или управляющие элементы, относящиеся к таблице у клиента, и не должен задавать значение кода MCCS VCP, равное 65535 (0xffff), для задания всех управляющих элементов. Если задан неподдерживаемый или недействительный код MCCS VCP, то тогда в ответном пакете с действительными параметрами возвращается значение соответствующей ошибки. В одном варианте клиент указывает, что способен поддерживать пакет запроса действительных параметров, используя бит 20 поля индикаторов отличительных возможностей дисплея в пакете возможностей дисплея.
Формат пакета запроса действительных параметров по одному варианту изобретения показан на фиг.73. Как показано на фиг.73, структура пакета этого типа имеет поля длины пакета, типа пакета, ID h-клиента, кода MCCS VCP, а также поле CRC. Пакет этого типа обычно идентифицируется в одном варианте изобретения как пакет типа 131, указанный в 2-байтовом поле типа.
Длина пакета, указанная в 2-байтовом поле длины пакета, обычно устанавливается равной общему количеству байт в пакете, не включая поле длины пакета, равное 8. ID h-клиента опять же задает ID клиента, но в настоящее время зарезервирован для будущего использования, как очевидно специалистам в данной области техники, и установлен в нуль. 2-байтовое поле кода MCCS VCP содержит значение, задающее запрашиваемый параметр кода управляющего элемента MCCS VCP. Значение в этом поле должно соответствовать дискретному управляющему элементу, реализованному у клиента. Значения с 256 по 65535 (0xffff) обычно резервируются или считаются недействительными, а также интерпретируются как нереализованный управляющий элемент в ответном сообщении об ошибке.
31. Ответный пакет с действительными параметрами
Ответный пакет с действительными параметрами посылается в ответ на пакет запроса действительных параметров. Он используется как средство, способ или механизм идентификации действительных настроек для дискретного управляющего элемента MCCS VCP или управляющего элемента, который возвращает контент таблицы. Если управляющий элемент относится к таблице у клиента, то тогда ответный список параметров VCP просто содержит определенный список последовательных табличных значений, которые запрашивались. Если контент таблицы не может поместиться в один ответный пакет действительных параметров, то тогда клиент может послать несколько пакетов с последовательными порядковыми номерами ответов. В одном варианте клиент указывает, что способен поддерживать ответный пакет действительных параметров, используя бит 20 поля индикаторов отличительных возможностей дисплея в пакете возможностей дисплея.
Хост может запросить контент таблицы следующим образом: хост посылает пакет установки характеристик VCP, содержащий необходимые или желаемые параметры, такие как параметр считывания/записи, сдвиг LUT (справочная таблица) и выбор RGB; затем хост посылает пакет запроса действительных параметров, который задает желаемый управляющий элемент; после этого клиент возвращает один или несколько ответных пакетов с действительными параметрами, содержащих табличные данные. Эта последовательность операций выполняет ту же функцию, что и функции считывания таблицы, описанные в операционной модели MCCS.
Если конкретный параметр клиентом не поддерживается, то тогда согласно одному варианту соответствующее поле этого пакета будет содержать значение 255. Для параметров, используемых у клиента, соответствующее поле должно содержать значение этого параметра у клиента.
Формат ответного пакета с действительными параметрами для одного варианта изобретения показан на фиг.74. Как показано на фиг.74, структура пакета этого типа имеет поля длины пакета, типа пакета, ID с-клиента, кода MCCS VCP, ответного кода, порядкового номера ответа, значений номеров в списке, ответного списка параметров VCP, а также поле CRC. Пакет этого типа обычно идентифицируется для одного варианта изобретения как пакет типа 132, указанный в 2-байтовом поле типа.
Поле ID c-клиента зарезервировано для будущего ID клиента, как это известно из предыдущего обсуждения, в то время как 3-байтовый пакет кода MCCS VCP содержит значение, задающее параметр кода дискретного управляющего элемента MCCS VCP, который описывается этим пакетом. Если пакетом запроса действительных параметров задается недействительный код управляющего элемента MCCS VCP, то тогда в этом поле будет задано аналогичное недействительное значение параметра с соответствующим значением в поле ответного кода. Если код управляющего элемента MCCS является недействительным, то тогда ответный список параметров VCP будет иметь нулевую длину.
Поле ответного кода содержит 2 информационных байта или значения, которые определяют характер ответа, связанного с запросом информации, касающейся заданного управляющего элемента MCCS VCP. Если значение в этом поле равно 0, то тогда считается, что для этого типа данных нет ошибки, и в этой последовательности посылается ответный пакет с действительными параметрами, имеющий самый большой порядковый номер ответа. Если значение в этом поле равно 1, то тогда считается, что ошибки нет, но будут посылаться другие ответные пакеты с действительными параметрами, имеющие более высокие порядковые номера. Если значение в этом поле равно 2, то тогда считается, что заданный управляющий элемент не реализован у клиента. Если значение в этом поле равно 3, то тогда заданный управляющий элемент не является дискретным (является непрерывным управляющим элементом, который всегда имеет действительный набор всех значений от нуля до максимального значения). Значения для этого поля, равные от 4 до 65535, зарезервированы для будущего использования и в общем случае не используются.
2-байтовое поле порядкового номера ответа задает порядковый номер ответных пакетов с действительными параметрами, возвращенных клиентом. Клиент возвращает один или несколько ответных пакетов с действительными параметрами в ответ на пакет запроса действительных параметров. Клиент может расширить ответный список параметров VCP на множество ответных пакетов с действительными параметрами. В последнем случае клиент будет присваивать порядковый номер каждому последующему пакету и установит ответный код в 1 во всех пакетах в последовательности, кроме последнего. Последний ответный пакет с действительными параметрами в этой последовательности будет иметь самый большой порядковый номер ответа, а ответный код содержит значение 0.
2-байтовое количество значений в поле списка задает количество 16-разрядных значений, которые имеются в ответном списке параметров VCP. Если ответный код не равен нулю, то количество значений в параметре списка равно нулю. Поле ответного списка параметров VCP содержит список 2-байтовых значений от 0 до 32760, которые указывают набор действительных значений для дискретного управляющего элемента, заданного полем кода управляющего элемента MCCS. Определения кодов дискретных управляющих элементов заданы в Спецификации VESA MCCS. Наконец, в этом варианте поле CRC содержит 16-разрядную CRC всех байтов в пакете, включая длину пакета.
Изображения альфа-курсора
Интерфейс MDDI вместе с соответствующим предложенным в изобретении протоколом и механизмами для обмена данными по линии связи обеспечивает поддержку множества плоскостей изображения, которые перекрывают друг друга и могут иметь различные степени прозрачности. Можно реализовать аппаратный курсор, используя перекрывающееся изображение с переменным сдвигом X-Y. Далее следует обзор функциональных возможностей альфа-курсора и поддержки соответствующего протокола. Способность поддерживать пакеты изображения альфа-курсора определена в пакете возможностей изображения альфа-курсора, который посылается в ответ на пакет запроса конкретного состояния.
32. Пакет возможностей изображения альфа-курсора
Пакет возможностей изображения альфа-курсора используется для определения характеристик изображения альфа-курсора и соответствующих карт прозрачности у клиента. В одном варианте клиент указывает, что способен поддерживать пакет возможностей изображения альфа-курсора, используя значение параметра, равное 133, в ответном списке с действительными параметрами в пакете ответного списка действительных состояний. Длина пакета, заданная в поле длины пакета, устанавливается для одного варианта изобретения равной фиксированному значению 20, не включая поле длины пакета.
Формат пакета возможностей изображения альфа-курсора для одного варианта показан на фиг.75. Как показано на фиг.75, структура пакета этого типа имеет поля длины пакета, типа пакета, ID с-клиента, идентификатора альфа-курсора, ширины битовой карты альфа-курсора, высоты битовой карты альфа-курсора, возможностей RGB, возможностей монохромного формата, поле pезервное 1, поле возможностей Y Cr Cb, резервное поле карты прозрачности, поле битов возможностей и поле CRC. Поле ID c-клиента обычно зарезервировано для использования будущего ID клиента и в настоящее время установлено в нуль.
Поле идентификатора альфа-курсора (2 байта) содержит значение, которое идентифицирует определенную плоскость альфа-курсора. Если клиент поддерживает n плоскостей изображения альфа-курсора, то тогда действительный диапазон идентификатора альфа-курсора находится в пределах от 0 до n-1. В одном варианте значение n задается полем плоскостей изображения альфа-курсора в пакете возможностей дисплея. Клиент возвращает уникальный пакет возможностей изображения альфа-курсора для каждой плоскости изображения альфа-курсора.
2-байтовое значение поля ширины битовой карты альфа-курсора задает ширину изображения битовой карты альфа-курсора, выраженную в количестве пикселей, в то время как 2-байтовое значение поля высоты битовой карты альфа-курсора задает высоту изображения битовой карты альфа-курсора, выраженную в количестве пикселей.
Поле возможностей RGB использует 2 байта для задания количества бит разрешения, которое может отображаться в формате RGB. Если клиент не может использовать формат RGB, то тогда это значение равно нулю. Слово возможностей RGB состоит из трех отдельных значений, которые в одном варианте изобретения реализованы таким образом, что: биты с 3 по 0 определяют максимальное количество бит синего цвета (интенсивность синего) в каждом пикселе; биты с 7 по 4 определяют максимальное количество бит зеленого цвета (интенсивность зеленого) в каждом пикселе; биты с 11 по 8 определяют максимальное количество бит красного цвета (интенсивность красного) в каждом пикселе; а биты с 15 по 12 зарезервированы для будущего использования при представлении информации о возможностях RGB, так что в настоящее время их обычно устанавливают в нуль.
1-байтовое поле возможностей монохромного формата используется для задания количества бит разрешения, которое может отображаться в монохромном формате. Если клиент не может использовать монохромный формат, то тогда это значение устанавливают в нуль. Биты с 7 по 4 зарезервированы для будущего использования, и, следовательно, их обычно устанавливают в нуль. Биты с 3 по 0 определяют максимальное количество бит серой шкалы, которое может находиться в каждом пикселе. Эти четыре бита позволяют задать каждый пиксель в составе от 1 до 15 бит. Если это значение равно нулю, значит монохромный формат клиентом не поддерживается.
1-байтовое поле резервное 1 содержит значение, обычно зарезервированное для будущего использования, и поэтому все биты в этом поле устанавливают в нуль. Это вызывает выравнивание последующих 2-байтовых полей по 16-разрядному адресу слова и выравнивание 4-байтовых полей по 32-разрядному адресу слова.
2-байтовое поле возможностей Y Cb Cr содержит значения или информацию, задающую количество бит разрешения, которое может быть отображено в формате Y Cb Cr. Если клиент не может использовать формат Y Cb Cr, то тогда это значение равно нулю. Обычно в одном варианте изобретения слово возможностей Y Cb Cr составлено из трех отдельных значений, где: биты с 3 по 0 определяют максимальное количество бит, которые задают выборку Cr; биты с 7 по 4 определяют максимальное количество бит, которые задают выборку Cb; биты с 11 по 8 определяют максимальное количество бит, которые задают выборку Y; а биты с 15 по 12 зарезервированы для будущего использования при представлении информации или значений о возможностях Y Cb Cr, причем в настоящее время они установлены в нуль.
1-байтовое поле разрешения карты прозрачности содержит значения или информацию, которая задает количество бит (глубину) по месту каждого пикселя на карте прозрачности изображения альфа-курсора. Это значение может находиться в диапазоне от 1 до 8. Если это значение равно нулю, то тогда карта прозрачности для буфера изображения альфа-курсора (буфер, заданный полем идентификатора альфа-курсора) не поддерживается.
1-байтовое поле битов возможностей обеспечивает значения или информацию, которая содержит набор флагов, задающих возможности, связанные с буфером изображения альфа-курсора. В одном варианте флаги определены так, что бит 0 предназначен для выбора пиксельных данных в пакете видеопотока альфа-курсора в упакованном формате. Бит 1 предназначен для того, чтобы показать, что данные карты прозрачности в пакете прозрачности альфа-курсора находятся в упакованном формате. Пример данных карты прозрачности с байтовым выравниванием и упакованных данных карты прозрачности показан на фиг.76. Назначение бита 2 - показать, что плоскость изображения альфа-курсора поддерживает возможности сдвига изображения с использованием пакета сдвига изображения альфа-курсора. Бит 3 предназначен для показа того, что плоскость изображения альфа-курсора может поддерживать формат данных цветовой карты. Для плоскостей изображения альфа-курсора используется та же таблица цветовой карты, что и для буфера основного изображения и масштабированных видеопотоков. Цветовая карта конфигурируется с использованием пакета цветовой карты, описанного в другом месте.
Биты с 7 по 4 зарезервированы для будущего использования, и поэтому обычно установлены в нулевое значение или на нулевой логический уровень.
33. Пакет карты прозрачности альфа-курсора
Пакет карты прозрачности альфа-курсора определяет контент карты прозрачности изображения для заданной плоскости изображения альфа-курсора. Для некоторых приложений может понадобиться карта прозрачности, большая, чем объем данных, который может быть передан в одном пакете. В этих случаях может посылаться множество пакетов карты прозрачности альфа-курсора, каждый из которых имеет разный поднабор карты прозрачности, путем использования описанных ниже полей начала Х и начала Y карты прозрачности. Эти поля действуют таким же образом, как поля начала Х и начала Y в пакете видеопотока. Клиент в одном варианте изобретения указывает, что способен поддерживать пакет карты прозрачности альфа-курсора, используя поле разрешения карты прозрачности в пакете возможностей изображения альфа-курсора для каждой конкретной плоскости альфа-курсора, заданной полем идентификатора альфа-курсора в пакете возможностей изображения альфа-курсора. Поля длины пакета и ID клиента имеют то же назначение, что и раньше для других вышеописанных пакетов. В одном варианте для идентификации пакета как пакета карты прозрачности альфа-курсора используют значение 134 в поле типа пакета.
Формат пакета карты прозрачности альфа-курсора для одного варианта изобретения показан на фиг.76. Как показано на фиг.76, структура пакета этого типа имеет поля длины пакета, типа пакета, ID h-клиента, идентификатора альфа-курсора, начала Х карты прозрачности, начала Y карты прозрачности, разрешения карты прозрачности, поле резервное 1, поля CRC параметра, данных карты прозрачности и поле CRC данных карты прозрачности.
2-байтовое поле идентификатора альфа-курсора имеет значение, идентифицирующее определенную плоскость альфа-курсора. Если клиент поддерживает n плоскостей изображения альфа-курсора, то тогда идентификатор альфа-курсора имеет диапазон действующих значений от 0 до n-1.
2-байтовые поля начала Х и начала Y карты прозрачности задают каждое абсолютные координаты Х и Y, где точкой (начало Х карты прозрачности, начало Y карты прозрачности) является первый пиксель в поле данных карты прозрачности, описанном ниже.
Поле разрешения карты прозрачности (1 байт) содержит значение, задающее разрешение карты прозрачности, и определяет, упакованы ли данные. В одном варианте этого поля биты с 3 по 0 определяют количество бит разрешения, которое находится во всех элементах таблицы карты прозрачности. Действительные значения задают ширину от 1 до 8 бит. Значения 0, а также с 9 по 15 считаются недействительными. Указанное значение должно совпадать со значением, возвращенным клиентом в поле разрешения карты прозрачности в пакете возможностей изображения альфа-курсора. Биты с 6 по 4 зарезервированы для будущего использования, и поэтому в настоящее время обычно должны быть установлены в логический нуль. Бит 7 этого байта определяет, содержатся ли данные карты прозрачности в упакованном виде или с байтовым выравниванием. Если бит 7 равен '1', то тогда данные карты прозрачности находятся в упакованном виде, а если '0', то данные представлены с байтовым выравниванием. Пример упакованных данных карты прозрачности и данных карты прозрачности с байтовым выравниванием показан в другом месте. Значение этого бита должно совпадать со значением бита 1 в поле битов возможностей в пакете возможностей изображения альфа-курсора.
1-байтовое поле резервное 1 зарезервировано для будущего использования, и поэтому все биты в этом поле обычно устанавливают равными уровню логического нуля. Это поле предназначено для того, чтобы обеспечить выравнивание всех последовательных 2-байтовых полей по 16-разрядному адресу слова и выравнивание 4-байтовых полей по 32-разрядному адресу слова.
Поле CRC параметра содержит 16-разрядную проверку CRC всех байтов, начиная с поля длины пакета и до поля резервное 1. Если проверка CRC дает отрицательный результат, то весь пакет должен быть отброшен.
Для поля данных карты прозрачности каждое место карты прозрачности имеет по ширине от 1 до 8 бит. Если одна карта прозрачности не может поместиться в пакет карты прозрачности альфа-курсора, то тогда вся карта прозрачности может быть задана путем посылки нескольких пакетов с разными значениями данных карты прозрачности и начала Х и Y карты прозрачности в каждом пакете.
2-байтовое поле CRC данных карты прозрачности содержит 16-разрядную проверку CRC только данных карты прозрачности. Если эта проверка CRC дает отрицательный результат, то тогда данные карты прозрачности еще можно использовать, но должен быть увеличен на единицу отсчет ошибок CRC.
34. Пакет сдвига изображения альфа-курсора
Пакет сдвига изображения альфа-курсора задает сдвиг по Х и Y курсора от левого верхнего угла основного дисплейного изображения. Формат пакета сдвига изображения альфа-курсора показан на фиг.77. Как показано на фиг.77, в одном варианте структура пакета сдвига изображения альфа-курсора имеет поля длины пакета, типа пакета, ID h-клиента, сдвига по Х альфа-курсора, сдвига по Y альфа-курсора и поле CRC. В одном варианте клиент указывает, что способен поддерживать пакет сдвига изображения альфа-курсора, используя бит 2 поля битов возможностей в пакете возможностей изображения альфа-курсора для каждой определенной плоскости альфа-курсора, заданной полем идентификатора альфа-курсора в пакете возможностей изображения альфа-курсора. В одном варианте длина пакета является фиксированной и равна 10, как показано в 2-байтовом поле длины пакета. В одном варианте тип 135 идентифицирует пакет как пакет сдвига изображения альфа-курсора.
2-байтовые поля сдвига по Х и Y альфа-курсора содержат значения, задающие соответственно горизонтальный и вертикальный сдвиг самого левого столбца и верхней строки пикселей изображения курсора относительно левого края и верхнего края основного изображения соответственно. ID h-клиента имеет 2 байта, содержащие 16-разрядное целое число без знака, зарезервированное для ID клиента. Это поле зарезервировано для будущего использования и должно быть установлено в нуль.
35. Пакет видеопотока альфа-курсора
Пакет видеопотока альфа-курсора несет видеоданные для обновления прямоугольной области на плоскости изображения альфа-курсора. Минимальный размер этой области может соответствовать одному пикселю, а максимальный размер достигать размера всего дисплея. Формат пакета видеопотока альфа-курсора показан на фиг.78. Как показано на фиг.78, структура пакета видеопотока альфа-курсора в одном варианте имеет поля длины пакета, типа пакета, ID b-клиента, атрибутов формата видеоданных, левого края Х, верхнего края Y, правого края Х, нижнего края Y, начала Х, начала Y, отсчета пикселей, поле CRC параметра, поле пиксельных данных, и поле CRC пиксельных данных. В одном варианте клиент указывает, что способен поддерживать пакет видеопотока альфа-курсора и связанные с ним параметры, используя пакет возможностей изображения альфа-курсора для каждой определенной плоскости альфа-курсора, заданной полем идентификатора альфа-курсора в пакете возможностей изображения альфа-курсора, а значение 17 в поле типа пакета указывает или идентифицирует пакет как пакет видеопотока альфа-курсора. Поле ID h-клиента (2 байта) зарезервировано для будущего использования в качестве ID клиента и обычно устанавливается в нуль, что должно быть очевидно специалистам в данной области техники.
2-байтовое поле дескриптора формата видеоданных содержит информацию или значение, задающее формат каждого пикселя в пиксельных данных в текущем потоке в текущем пакете. Формат пиксельных данных должен соответствовать по меньшей мере одному из действительных форматов для плоскости изображения альфа-курсора, определенному в пакете возможностей изображения альфа-курсора. Поле дескриптора формата видеоданных содержит значение, которое определяет формат пикселей только для текущего пакета и не предполагает, что в течение времени существования конкретного видеопотока будет использоваться постоянный формат. Выше на фиг.11 было показано, как кодируется дескриптор формата видеоданных. Этот формат выглядит следующим образом.
В одном варианте, когда биты [15:13] равны '000', то тогда видеоданные состоят из матрицы монохромных пикселей, где количество бит на пиксель определяется битами с 3 по 0 слова дескриптора формата видеоданных. Далее биты с 11 по 4 установлены в нуль. Когда биты [15:13] равны '001', то тогда видеоданные состоят из матрицы цветных пикселей, каждый из которых задает цвет посредством цветовой карты (палитра). Биты с 5 по 0 слова дескриптора формата видеоданных определяют количество бит на пиксель, а биты с 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 и Сr посылаются с половинной скоростью по сравнению с Y. Видеовыборки в части этого пакета, относящейся к пиксельным данным, будут организованы следующим образом: 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. Если в строке имеется нечетное количество пикселей (правый край Х - левый край Х +1) в окне, на которое ссылается пакет видеопотока, то тогда за значением Cb, соответствующим последнему пикселю в каждой строке, будет следовать значение Y первого пикселя следующей строки.
Рекомендуется, чтобы окна, использующие формат Y Cb Cr, имели ширину, равную четному числу пикселей. Пиксельные данные в пакете должны содержать четное количество пикселей. Они могут содержать нечетное или четное количество пикселей в том случае, когда последний пиксель пиксельных данных соответствует последнему пикселю строки в окне, заданном в заголовке пакета видеопотока, то есть когда положение по Х последнего пикселя в пиксельных данных равно Х правого края.
Для всех пяти форматов бит 12 (обозначенный на фигурах как «Р») определяет, упакованы ли выборки пиксельных данных. Когда значение бита 12 равно '0', тогда каждый пиксель и каждый цвет в каждом пикселе в поле пиксельных данных выравнивается по байтам с байтовой границей интерфейса MDDI. Когда значение бита 12 равно '1', тогда каждый пиксель и каждый цвет в каждом пикселе в пиксельных данных упаковывается впритык к предыдущему пикселю или цвету в пикселе, не оставляя неиспользованных бит.
В одном варианте поле атрибутов пиксельных данных (2 байта) имеет ряд битовых значений, которые интерпретируются следующим образом. Биты 1 и 0 выбирают вариант маршрутизации пиксельных данных дисплея. Для значений бит '11' данные отображаются на оба глаза, для битовых значений '10' данные направляются только в левый глаз, а для битовых значений '01' данные направляются только в правый глаз.
Бит 2 указывает, присутствуют ли пиксельные данные в чересстрочном формате со значением '0', означающим, что пиксельные данные находятся в стандартном прогрессивном формате и что номер строки (координата Y пикселя) увеличивается на 1 при продвижении с одной строки на следующую. Когда этот бит имеет значение '1', пиксельные данные находятся в чересстрочном формате и номер строки увеличивается на 2 при переходе с одной строки на следующую. Бит 3 указывает, что пиксельные данные находятся в альтернативном пиксельном формате. Он аналогичен стандартному чересстрочному режиму, разрешаемому битом 2, но чередование выполняется не по горизонтали, а по вертикали. Когда бит 3 равен '0', пиксельные данные находятся в стандартном прогрессивном формате и номер столбца (координата Х пикселя) увеличивается на 1 при приеме каждого последующего пикселя. Когда бит 3 равен '1' пиксельные данные находятся в альтернативном пиксельном формате и номер столбца увеличивается на 2 с приемом каждого пикселя.
Бит 4 указывает, относятся ли пиксельные данные к дисплею или камере и куда пересылаются данные: на или от внутреннего дисплея для беспроводного телефона или аналогичного устройства или даже портативного компьютера, или других указанных устройств, обсужденных выше, либо данные пересылаются на или от камеры, встроенной или непосредственно соединенной с устройством. Когда бит 4 равен '0', пиксельные данные пересылаются в или из буфера дисплейных кадров. Когда бит 4 равен '1' пиксельные данные пересылаются в или из камеры или видеоустройства некоторого типа, причем указанные устройства хорошо известны специалистам в данной области техники.
Бит 5 зарезервирован для будущего использования или приложений интерфейса MDDI и поэтому обычно устанавливается в нулевое значение или '0'.
Биты 7 и 6 являются битами обновления дисплея, которые определяют буфер кадров, в который должны быть записаны пиксельные данные. Более детальные действия обсуждаются в другом месте. Для битовых значений '01' пиксельные данные записываются в автономный буфер изображения. Для битовых значений '00' пиксельные данные записываются в буфер изображения, используемый для обновления дисплея. Для битовых значений '11' пиксельные данные записываются во все буферы изображения. Битовые значения или комбинация '10' считается недействительным значением или обозначением, и пиксельные данные игнорируются и не записываются ни в один из буферов изображения. Это значение можно использовать для будущих приложений интерфейса.
Биты с 8 по 15 зарезервированы для будущего использования, и поэтому их обычно устанавливают в нуль.
В одном варианте 2-байтовые поля начала Х и начала Y задают абсолютные координаты Х и Y точки (начало Х, начало Y) для первого пикселя в поле пиксельных данных. 2-байтовые поля левого края Х и верхнего края Y задают координату Х левого края и координату Y верхнего края окна изображения альфа-курсора, заполненного полем пиксельных данных, в то время как поля правого края Х и нижнего края Y задают координату Х правого края и координату Y нижнего края, обновляемого окна изображения альфа-курсора.
Поле отсчета пикселей (2 байта) задает количество пикселей в поле пиксельных данных, указанном ниже.
2-байтовое поле CRC параметра содержит CRC всех байтов от длины пакета до отсчета пикселей. Если проверка CRC дает отрицательный результат, то весь пакет отбрасывается.
Поле пиксельных данных содержит исходную видеоинформацию, подлежащую отображению, и способ форматирования, описанный полем дескриптора формата видеоданных. Данные передаются одной «построчно», как описано в другом месте.
Поле CRC пиксельных данных (2 байта) содержит 16-разрядную CRC только пиксельных данных. Если проверка CRC для этого значения дает отрицательный результат, то тогда пиксельные данные еще можно использовать, но к отсчитанному значению ошибок CRC прибавляется единица.
Изображения масштабированного видеопотока
Предложенный интерфейс MDDI, механизм протокола или способ обеспечивает поддержку изображений масштабированного видеопотока, что позволяет хосту посылать клиенту изображение, которое имеет больший или меньший масштаб, чем исходное изображение, причем масштабированное изображение копируется в основной буфер изображения. Обзор функциональных возможностей масштабированного видеопотока и соответствующей протокольной поддержки представлен в другом месте. Возможность поддержки масштабированных видеопотоков определяется пакетом возможностей масштабированного видеопотока, который посылается в ответ на пакет запроса конкретного состояния.
36. Пакет возможностей масштабированного видеопотока
Пакет возможностей масштабированного видеопотока определяет характеристики исходного изображения масштабированного видеопотока, используемого клиентом. Формат пакета возможностей масштабированного видеопотока показан для общего случая на фиг.79. Как показано на фиг.79, в одном варианте структура пакета возможностей масштабированного видеопотока имеет поля длины пакета, типа пакета, ID с-клиента, максимального количества потоков, максимального размера Х источника, максимального размера Y источника, возможностей RGB, возможностей монохромного формата, поле резервное 1, поле возможностей Y Cb Cr, поле резервное 2, а также поле CRC. В одном варианте длина пакета выбирается с фиксированным значением 20 байт, как показано в поле длины, включая 2-байтовое поле ID c-клиента, которое зарезервировано для использования для ID клиента (в ином случае устанавливается в нуль), и поле CRC. В одном варианте клиент указывает, что способен поддерживать пакет возможностей масштабированного видеопотока, используя значение параметра, равное 143, в ответном списке действительных параметров пакета ответного списка действительных состояний.
2-байтовое поле максимального количества потоков содержит значение, идентифицирующее максимальное количество одновременных масштабированных видеопотоков, которые могут распределяться одновременно. В одном варианте клиент должен отвергнуть запрос на распределение масштабированного видеопотока, если максимальное количество масштабированных видеопотоков уже распределено. Если распределено количество масштабированных видеопотоков, меньшее максимального, то клиент также может отвергнуть запрос на распределение на основе других ресурсных ограничений у клиента.
Поля максимального исходного размера Х и максимального исходного размера Y (2 байта) задают соответственно значения для максимальной ширины и высоты исходного изображения масштабированного видеопотока, которые выражены в количестве пикселей.
Поле возможностей RGB использует значения, задающие количество бит разрешения, которые могут отображаться в формате RGB. Если масштабированный видеопоток не может использовать формат RGB, то тогда это значение устанавливают равным нулю. Слово возможностей RGB составлено из трех отдельных значений без знака, причем: биты с 3 по 0 определяют максимальное количество бит синего цвета (интенсивность синего) в каждом пикселе, биты с 7 по 4 определяют максимальное количество бит зеленого цвета (интенсивность зеленого) в каждом пикселе, а биты с 11 по 8 определяют максимальное количество бит красного цвета (интенсивность красного) в каждом пикселе, в то время как биты с 15 по 12 зарезервированы для будущего использования в определениях будущих возможностей, и их обычно устанавливают в нуль.
1-байтовое поле возможностей монохромного формата содержит значение, задающее количество бит разрешения, которое может отображаться в монохромном формате. Если масштабированный видеопоток не может использовать монохромный формат, то тогда это значение устанавливают в нуль. Биты с 7 по 4 зарезервированы для будущего использования и поэтому для текущих приложений должны быть установлены в нуль ('0'), хотя это может со временем измениться, как очевидно специалистам в данной области техники. Биты с 3 по 0 определяют максимальное количество бит серой шкалы, которое может находиться в каждом пикселе. Эти четыре бита дают возможность задать каждый пиксель в составе от 1 до 15 бит. Если указанное значение равно нулю, то тогда монохромный формат масштабированным видеопотоком не поддерживается.
Поле резервное 1 (здесь 1 байт) зарезервировано для будущего использования при обеспечении значений, относящихся к информации или данным пакета масштабированного видеопотока. Таким образом, в настоящее время все биты в этом поле устанавливаются в логический '0'. Это поле предназначено для того, чтобы обеспечить выравнивание всех последующих 2-байтовых полей по 16-разрядному адресу слова и выравнивание всех 4-байтовых полей по 32-разрядному адресу слова.
2-байтовое поле возможностей Y Cb Cr содержит значения, задающие количество бит разрешения, которое может отображаться в формате Y Cb Cr. Если масштабированный видеопоток не может использовать формат Y Cb Cr, то тогда это значение равно нулю. Слово возможностей Y Cb Cr составлено из трех отдельных значений без знака, причем: биты с 3 по 0 определяют максимальное количество бит, задающих выборку Cr; биты с 7 по 4 определяют максимальное количество бит, задающих выборку Cb; биты с 11 по 8 определяют максимальное количество бит, задающих выборку Y, а биты с 15 по 12 зарезервированы для будущего использования и обычно установлены в нуль.
1-байтовое поле битов возможностей содержит набор флагов, которые задают возможности, связанные с масштабированным видеопотоком. Флаги определяются следующим образом: бит 0 относится к пиксельным данным в пакете масштабированного видеопотока, которые могут содержаться в упакованном формате. Пример упакованных пиксельных данных и пиксельных данных с байтовым выравниванием был показан ранее на фиг.12. Бит 1 зарезервирован для будущего использования и должен быть установлен в нуль; бит 2 зарезервирован для будущего использования и должен быть установлен в нуль; бит 3 относится к масштабированным видеопотокам, которые могут быть заданы в формате данных цифровой карты. Для масштабированных видеопотоков используется та же таблица цветовой карты, что и для буфера основного изображения и плоскостей изображения альфа-курсора. Цветовая карта конфигурируется с использованием пакета цветовой карты, описанного в другом месте, а биты с 7 по 4 зарезервированы для будущего использования и обычно установлены в нуль.
Поле pезервное 2 (здесь 1 байт) зарезервировано для будущего использования при обеспечении значений, относящихся к информации или данным пакета масштабированного видеопотока. Следовательно, в данный момент все биты в этом поле установлены в логический '0'. Это поле предназначено для того, чтобы обеспечить выравнивание всех последующих 2-байтовых полей по 16-разрядному адресу слова и выравнивание всех 4-байтовых полей по 32-разрядному адресу слова.
37. Пакет настройки масштабированного видеопотока
Пакет настройки масштабированного видеопотока используют для определения параметров масштабированного видеопотока, а клиент использует эту информацию для распределения внутренней памяти для буферизации и масштабирования изображения. Распределение потока может не состояться, если этот пакет послан с полями размера изображения по Х и Y, равными нулю. Масштабированные видеопотоки, которые не были распределены, позднее можно повторно распределить с теми же или другими параметрами потока. В одном варианте клиент указывает, что способен поддерживать пакет настройки масштабированного видеопотока, используя значение параметра, равное 143, в ответном списке действительных параметров в пакете ответного списка действительных состояний и используя ненулевое значение в поле максимального количества потоков в пакете возможностей масштабированного видеопотока.
Формат пакета настройки масштабированного видеопотока показан для общего случая на фиг.80. Как показано на фиг.80, в одном варианте структура пакета настройки масштабированного видеопотока имеет поля длины пакета, типа пакета, ID h-клиента, ID потока, дескриптора формата визуальных данных, атрибутов пиксельных данных, левого края Х, верхнего края Y, правого края Х, нижнего края Y, размера изображения по Х, размера изображения по Y, а также поле CRC.
3-байтовое поле длины пакета задает общее количество байт в пакете, исключая поле длины пакета. В одном варианте длина этого пакета является фиксированной и равна 24. 2-байтовое поле типа пакета использует значение 136 для идентификации пакета в качестве пакета настройки масштабированного видеопотока. 2-байтовое поле ID h-клиента зарезервировано для будущего использования в качестве ID клиента и обычно установлено на данный момент со всеми нулевыми значениями или до тех пор, пока пользователь протокола не определит, какие значения ID должны быть использованы, когда те станут известны.
Поле ID потока использует 2 байта для задания уникального идентификатора для ID потока. Это значение присваивается хостом и должно изменяться от нуля до максимального значения ID потока, заданного в пакете возможностей дисплея. Хост должен очень точно распоряжаться использованием значений ID потока, обеспечивая присваивание уникального значения каждому активному потоку и отменяя или освобождая от идентификаторов те потоки, которые больше не активны.
В одном варианте поле дескриптора формата видеоданных использует 2 байта для задания формата каждого пикселя в пиксельных данных в текущем потоке в настоящем пакете. Формат пиксельных данных должен соответствовать по меньшей мере одному из действительных форматов для плоскости изображения альфа-курсора, определенных в пакете возможностей изображения альфа-курсора. Дескриптор формата видеоданных определяет формат пикселей только для текущего пакета и не предполагает, что в течение времени существования конкретного видеопотока будет использоваться постоянный формат. На фиг.11 показан способ кодирования дескриптора формата видеоданных, обсужденный выше для других пакетов.
2-байтовое поле атрибутов пиксельных данных имеет значения, которые интерпретируются следующим образом:
Бит 1 и 0 выбирает дисплей, на который должны быть направлены пиксельные данные.
Биты [1:0]=11 или 00 - данные отображаются в оба глаза.
Биты [1:0]=10 - данные направляются только в левый глаз.
Биты [1:0]=01 - данные направляются только в правый глаз.
Бит 2 указывает, находятся или нет пиксельные данные в чересстрочном формате. Когда бит 2 равен 0, тогда пиксельные данные находятся не в стандартном прогрессивном формате. Номер строки (координата Y пикселя) должен быть увеличен на 1 при переходе с одной строки на следующую. Когда бит 2 равен 1, тогда пиксельные данные находятся в чересстрочном формате. Номер строки (координата Y пикселя) должен быть увеличен на 2 при переходе с одной строки на следующую.
Бит 3 указывает, находятся или пиксельные данные в альтернативном пиксельном формате. Это аналогично стандартному чересстрочному режиму, разрешаемому битом 2, но чередование выполняется по вертикали, а не по горизонтали. Когда бит 3 равен 0, пиксельные данные находятся в стандартном прогрессивном формате. Номер столбца (координата Х пикселя) должен быть увеличен на 1 при приеме каждого последующего пикселя. Когда бит 3 равен 1, пиксельные данные находятся в альтернативном пиксельном формате. Номер столбца (координата Х пикселя) должен быть увеличен на 2 при приеме каждого пикселя.
Бит 4 указывает, относятся ли пиксельные данные к дисплею или к камере. Когда бит 4 равен 0, пиксельные данные поступают в буфер кадров дисплея или от него. Когда бит 4 равен 1, пиксельные данные поступают в камеру или от нее.
Бит 5 зарезервирован для будущего использования и поэтому обычно устанавливается в нуль.
Биты 7 и 6 являются битами обновления дисплея, которые определяют буфер кадров, в который должны быть записаны пиксельные данные. Функции битов обновления кадра более подробно описаны в другом месте. Когда биты [7:6] равны '01', то пиксельные данные записываются в автономный буфер изображения. Когда биты [7:6] равны '00', то пиксельные данные записываются в буфер изображения, используемый для обновления дисплея. Когда биты [7:6] равны '11', то пиксельные данные записываются во все буферы изображения. Если биты [7:6] равны '10', это интерпретируется как недействительное значение. В данный момент эти биты зарезервированы для будущего использования. В этой ситуации пиксельные данные будут проигнорированы и не будут записаны ни в один из буферов изображения.
Биты с 8 по 15 зарезервированы для будущего использования и должны быть установлены в нуль.
2-байтовые поля левого края Х, верхнего края Y, правого края Х, нижнего края Y задают координату Х левого края, координату Y верхнего края, координату Х правого края и координату Y нижнего края назначенного изображения соответственно. Двухбайтовые поля размера изображения по Х и размера изображения по Y задают соответственно ширину и высоту исходного изображения. Поле CRC опять же содержит CRC всех байтов в пакете, включая длину пакета.
38. Пакет подтверждения масштабированного видеопотока
Пакет подтверждения масштабированного видеопотока позволяет клиенту подтвердить прием пакета настройки масштабированного видеопотока. Клиент должен указать, что он способен поддерживать пакет подтверждения масштабированного видеопотока посредством значения параметра, равного 143, в ответном списке действительных параметров в пакете ответного списка действительных состояний посредством ненулевого значения в поле максимального количества потоков в пакете возможностей масштабированного видеопотока.
Формат пакета подтверждения масштабированного видеопотока показан в общем виде на фиг.81. Как показано на фиг.81, в одном варианте структура пакета подтверждения масштабированного видеопотока имеет поля длины пакета, типа пакета, ID с-клиента, ID потока, код подтверждения (ACK), а также поле CRC. 2-байтовое поле длины пакета используется для задания общего количества байтов за исключением поля длины пакета со значением 10 для этого типа пакета, в то время как тип пакета 137 идентифицирует пакет как пакет подтверждения масштабированного видеопотока.
2-байтовое поле ID c-клиента зарезервировано для будущего использования для ID клиента и обычно установлено в нуль. 2-байтовое поле ID потока задает уникальный идентификатор для ID потока. Это то же самое значение, которое присвоено хостом в пакете настройки масштабированного видеопотока.
2-байтовое поле кода Ack обеспечивает значения, содержащие код, который описывает результат попытки обновления заданного масштабированного видеопотока. В одном варианте эти коды определены следующим образом:
0 - попытка распределения потоков была успешной.
1 - попытка освобождения ресурсов для потока была успешной.
2 - недействительная попытка распределения ID потока, который уже был распределен.
3 - недействительная попытка освобождения ресурсов для ID потока, который уже распределен.
4 - клиент не поддерживает масштабированные видеопотоки.
5 - параметры потока не соответствуют возможностям клиента.
6 - значение ID потока больше максимального значения, разрешенного клиентом.
7 - у клиента недостаточно ресурсов для распределения заданного потока.
2-байтовое поле CRC содержит CRC всех байтов в пакете, включая длину пакета.
39. Пакет масштабированного видеопотока
Пакет масштабированного видеопотока используется для передачи пиксельных данных, связанных с определенным масштабированным видеопотоком. Размер области, к которой обращается этот пакет, определяется пакетом настройки масштабированного видеопотока. Клиент должен указать, что способен поддерживать пакет масштабированного видеопотока через значение параметра, равное 143, в ответном списке действительных параметров в пакете ответного списка действительных состояний, используя ответ об успешном распределении масштабированного видеопотока в поле кода Ack в пакете подтверждения масштабированного видеопотока.
Формат одного варианта пакета масштабированного видеопотока показан в общем виде на фиг.82. Как показано на фиг.82, структура пакета масштабированного видеопотока имеет поля длины пакета, типа пакета, ID h-клиента, ID потока, CRC параметра, отсчета пикселей, пиксельных данных и CRC пиксельных данных. 2-байтовое поле типа пакета использует значение 18 для идентификации пакета в качестве пакета масштабированного видеопотока. Поле ID h-клиента зарезервировано для ID клиента и обычно установлено в нуль. Как и раньше, 2-байтовое поле ID потока задает уникальный идентификатор для ID потока. Это значение задается хостом в пакете настройки масштабированного видеопотока и подтверждается в пакете подтверждения масштабированного видеопотока.
2-байтовое поле отсчета пикселей задает количество пикселей в описанном ниже поле пиксельных данных. 2-байтовое поле CRC параметра имеет CRC всех байтов от длины пакета до отсчета пикселей. Если результат проверки CRC отрицательный, то тогда весь пакет будет отброшен. 2-байтовое поле пиксельных данных содержит исходную видеоинформацию, которая должна быть масштабирована, а затем отображена. Данные форматируются таким образом, как это описано в поле дескриптора формата видеоданных. Данные передаются построчно, как было определено ранее.
2-байтовое поле CRC пиксельных данных содержит CRC только пиксельных данных. Если эта проверка CRC дает отрицательный результат, то тогда пиксельные данные еще будут использоваться, но значение отсчета ошибок CRC должно быть увеличено на единицу.
40. Пакет запроса конкретного состояния
Пакет запроса конкретного состояния обеспечивает средство, механизм или способ, позволяющий хосту сделать запрос о том, чтобы клиент послал обратно хосту пакет возможностей или состояния, как определено в этом пакете. Клиент возвращает пакет заданного типа в следующем пакете инкапсуляции обратной линии связи. Клиент посылает бит 17 в поле отличительных возможностей клиента в пакете возможностей клиента, если клиент имеет возможность ответа на пакет запроса конкретного состояния. Клиент должен указать, что способен поддерживать пакет запроса конкретного состояния, используя бит 21 поля отличительных возможностей клиента в пакете возможностей клиента.
Формат одного варианта пакета запроса конкретного состояния показан для общего случая на фиг.83. Как показано на фиг.83, структура пакета запроса конкретного состояния имеет поля длины пакета, типа пакета, ID h-клиента, ID пакета состояния и поле CRC. Поле длины пакета задает общее количество байтов в пакете, за исключением поля длины пакета, причем это поле обычно является фиксированным со значением 10 для этого типа пакета. Тип пакета 138 определяет пакет как пакет запроса конкретного состояния.
Поле ID h-клиента (2 байта) зарезервировано для будущего использования для ID клиента, а теперь установлено в нуль.
2-байтовое поле ID пакета состояния задает тип пакета возможностей или состояния, который клиент собирается послать хосту, следующим образом:
66 - Клиент должен послать пакет возможностей клиента.
133 - Клиент должен послать пакет возможностей изображения альфа-курсора.
139 - Необходимо послать пакет ответного списка действительных состояний, идентифицирующий точные типы пакетов возможностей и состояния, которые может послать клиент.
140 - Клиент должен послать пакет параметров задержки обработки пакета.
141 - Клиент должен послать пакет возможностей персонального отображения.
142 - Клиент должен послать пакет с сообщением об ошибках отображения.
143 - Клиент должен послать пакет возможностей масштабированного видеопотока.
144 - Клиент должен послать пакет идентификации дисплея.
Значения с 56 по 63 - можно использовать для идентификаторов возможностей и состояния, привязанных к конкретному производителю.
Поле CRC опять же содержит CRC всех байтов в пакете, включая длину пакета.
41. Пакет ответного списка действительных состояний
Пакет ответного списка действительных состояний обеспечивает хост списком пакетов состояния и возможностей, на которые клиент имеет возможность реагировать. Клиент может указать, что способен поддерживать пакет ответного списка действительных состояний, используя бит 21 поля отличительных возможностей клиента в пакете возможностей клиента.
Формат одного варианта пакета ответного списка действительных состояний показан в общем виде на фиг.84. Как показано на фиг.84, структура пакета ответного списка действительных состояний имеет поля длины пакета, типа пакета, ID с-клиента, количества значений в списке, ответного списка действительных параметров и поле CRC. Длина пакета для этого типа пакета обычно является фиксированной со значением 10, а значение типа, равное 139, идентифицирует пакет как ответный пакет действительных состояний. Поле ID клиента зарезервировано для будущего использования в качестве ID клиента и обычно устанавливается в нуль. 2-байтовое поле количества значений в списке задает количество пунктов в последующем ответном списке действительных параметров.
Поле ответного списка действительных параметров содержит список 2-байтовых параметров, задающие типы пакетов возможностей или состояния, которые клиент может послать на хост. Если клиент указал, что он может отреагировать на пакет запроса конкретного состояния (используя бит 21 поля отличительных возможностей клиента в пакете возможностей клиента), то тогда он может послать по меньшей мере пакет возможностей клиента (тип пакета=66) и пакет ответного списка действительных состояний (тип пакета=139). Типы пакетов, которые может послать клиент и которые могут быть включены в этот список, вместе с соответствующими присваиваниями применительно к одному варианту перечислены ниже:
66 - Пакет возможностей клиента.
133 - Пакет возможностей изображения альфа-курсора.
139 - Пакет ответного списка действительных состояний, идентифицирующий точные типы пакетов возможностей и состояния, которые может послать клиент.
140 - Пакет параметров задержки обработки пакетов.
141 - Пакет возможностей персонального дисплея.
142 - Пакет клиента с сообщением об ошибках.
143 - Пакет возможностей масштабированного видеопотока.
144 - Пакет идентификации клиента.
Значения с 56 по 63 - можно использовать для идентификаторов возможностей и состояния, привязанных к изготовителю.
Поле CRC содержит CRC всех байтов в пакете, включая длину пакета.
42. Пакет параметров задержки обработки пакетов
Пакет параметров задержки обработки пакетов обеспечивает набор параметров, позволяющих хосту вычислить время, которое требуется для завершения обработки, связанной с приемом пакета определенного типа. Некоторые команды, посланные хостом, не могут быть окончательно выполнены клиентом за нулевое время. Хост может опросить биты состояния в пакете запроса и состояния дисплея, чтобы определить, закончил ли клиент выполнение некоторых функций, либо хост может вычислить время завершения, используя параметры, возвращенные клиентом в пакете параметров задержки обработки пакетов. Клиент должен указать, что способен поддерживать пакет параметров задержки обработки пакетов, используя значение параметра, равное 140, в ответном списке действительных параметров пакета из ответного списка действительных состояний.
Формат одного варианта пакета параметров задержки обработки пакетов показан в общем виде на фиг.85А. Как показано на фиг.85А, структура пакета параметров задержки обработки пакетов имеет поля длины пакета, типа пакета, ID с-клиента, количества пунктов в списке, списка параметров задержки и поле CRC. Длина пакета для пакета этого типа обычно является фиксированной со значением 10, а значение типа, равное 140, идентифицирует пакет как пакет параметров задержки обработки пакетов. Поле ID с-клиента зарезервировано для будущего использования в качестве ID клиента и обычно устанавливается в нуль. 2-байтовое поле количества пунктов в списке задает количество пунктов в последующем ответном списке действительных параметров.
Поле списка параметров задержки является списком, содержащим один или несколько пунктов списка параметров задержки. Формат для одного варианта одного пункта списка параметров задержки показан на фиг.85В, где показаны поля типа пакета для задержки, задержки пикселя, задержки горизонтальных пикселей, задержки вертикальных пикселей и фиксированной задержки.
Каждый пункт списка параметров задержки обычно строго ограничен 6 байтами в длину и дополнительно определен следующим образом:
2-байтовое поле типа пакета для задержки задает тип пакета, для которого применяются последующие параметры задержки.
Поле задержки пикселя (1 байт) содержит индекс для значения задержки. Значение, считанное из таблицы, умножается на общее количество пикселей в адресуемом поле пакета. Общее количество пикселей равно ширине адресуемой зоны битовой карты, к которой обращается пакет, умноженной на ее высоту.
1-байтовое поле задержки горизонтальных пикселей содержит значение, равное индексу для таблицы значений задержек (таблица, аналогичная DPVL). Значение, считанное из таблицы, умножается на ширину (в пикселях) адресуемого поля пакета.
1-байтовое поле задержки вертикальных пикселей содержит значение, равное индексу для таблицы значений задержек (таблица, аналогичная DPVL). Значение, считанное из таблицы, умножается на высоту (в пикселях) адресуемого поля пакета.
Поле фиксированной задержки использует 1 байт в качестве индекса для таблицы значений задержки (таблица, аналогичная DPVL). Значение, считываемое из этой таблицы, является фиксированным параметром задержки, который представляет время, необходимое для обработки пакета, не относящегося к значениям параметров, заданных в пакете. Общая задержка, или временная задержка на завершение обработки пакета, определяется в соответствии со следующим соотношением:
Для некоторых пакетов параметры «Общее количество пикселей», «Ширина» или «Высота» не используются, поскольку на эти параметры нет ссылок в соответствующем пакете. В этих случаях соответствующий параметр задержки пикселя обычно устанавливают равным нулю.
43. Пакет возможностей персонального дисплея
Пакет возможностей персонального дисплея обеспечивает набор параметров, который описывает возможности персонального дисплейного устройства, такого как дисплей, смонтированный на голове, или дисплейные очки. Это позволяет хосту согласовать дисплейную информацию со специфическими возможностями клиента. С другой стороны, клиент указывает, что способен послать пакет возможностей персонального дисплея, используя соответствующий параметр в ответном списке действительных параметров в пакете ответного списка действительных состояний.
Формат одного варианта пакета возможностей персонального дисплея показан в общем виде на фиг.86. Как показано на фиг.86, структура пакета возможностей персонального дисплея имеет поля длины пакета, типа пакета, ID с-клиента, компоновки субпикселя, формы пикселей, горизонтального поля вида, вертикального поля вида, скрещивания визуальной оси, перекрытия левого/правого изображения, сквозного просмотра, максимальной яркости, оптических возможностей, минимального IPD, максимального IPD, точек I поля списка кривизны, а также поле CRC. В одном варианте значение поля длины пакета является фиксированным и равно 68. Значение типа пакета, равное 141, идентифицирует пакет как пакет возможностей персонального дисплея. Поле ID c-клиента зарезервировано для будущего использования и в настоящее время обычно устанавливается в нуль.
Поле компоновки субпикселя задает физическую компоновку субпикселя сверху вниз и слева направо с использованием следующих значений: 0 - для указания того, что компоновка субпикселя не определена; 1 - для указания красно-зелено-синий полосы; 2 - для указания сине-зелено-красной полосы; 3 - для указания счетверенного пикселя, имеющего расположение субпикселей 2 по 2 красного наверху слева, синего внизу справа и двух зеленых субпикселей, один внизу слева, а другой внизу справа; 4 - для указания счетверенного пикселя с расположением субпикселей красного 2 по 2 внизу слева, синего вверху справа и двух зеленых субпикселей, один наверху слева, а другой внизу справа; 5 - для указания треугольника (триада); 6 - для указания мозаики с наложением красного, зеленого и синего цветов (например, дисплей LCOS с последовательной передачей цветов по полям); причем значения с 7 по 255 в общем случае зарезервированы для будущего использования.
Поле формы пикселя задает форму каждого пикселя, которая составляется из определенной комбинации субпикселей с использованием следующих значений: 0 - для указания о том, что форма субпикселя не определена; 1 - для указания круга; 2 - для указания квадрата; 3 - для указания прямоугольника; 4 - для указания овала; 5 - для указания эллипса; при этом значения с 6 по 255 зарезервированы для будущего использования при индикации желаемых форм, как очевидно специалистам в данной области техники.
1-байтовое поле горизонтального поля вида (HFOV) задает горизонтальное поле вида с этапом 0,5 градуса (например, если HFOV равно 30 градусов, то значение этого поля равно 60). Если это значение равно нулю, то тогда HFOV не задано.
1-байтовое поле вертикального поля вида (VFOV) задает вертикальное поле вида с этапом 0,5 градуса (например, если VFOV равно 30 градусов, то значение этого поля равно 60). Если это значение равно нулю, то тогда VFOV не задано.
1-байтовое поле скрещивания визуальной оси задает скрещивание визуальной оси с этапом 0,01 диоптрии (1/м) (например, если скрещивание визуальной оси равно 2,22 м, значение этого поля равно 45). Если это значение равно нулю, то тогда скрещивание визуальной оси не задано. (Примечание: подходит ли спецификация этого параметра для диапазона, требуемого в большинстве приложений?).
1-байтовое поле перекрытия левого/правого изображения задает процент перекрытия левого и правого изображения. Допустимый диапазон перекрытия изображения в процентах составляет от 1 до 100. Значения от 101 до 255 являются недействительными и использоваться не должны. Если указанное значение равно нулю, то тогда перекрытие изображения не задано.
1-байтовое поле сквозного просмотра задает процент сквозного просмотра изображения. Допустимый диапазон сквозного просмотра в процентах составляет от 0 до 100. Значения от 101 до 254 являются недействительными и использоваться не должны. Если указанное значение равно 255, то процент сквозного просмотра не задан.
1-байтовое поле максимальной яркости задает максимальную яркость с этапом 20 нит (например, если максимальная яркость равна 100 нит, значение этого поля равно 5). Если это значение равно нулю, то тогда максимальная яркость не задана.
2-байтовое поле флагов оптических возможностей содержит различные поля, которые задают оптические возможности дисплея. Битовые значения обычно присваиваются согласно следующему варианту:
Биты с 15 по 5 зарезервированы для будущего использования и должны быть установлены в нуль.
Бит 4 выбирает регулировку фокуса очков, причем значение '0' означает, что дисплей не имеет регулировку фокуса очков, а значение '1' означает, что дисплей имеет регулировку фокуса очков.
Биты с 3 по 2 выбирают бинокулярную функцию согласно следующему: значение 0 означает, что дисплей бинокулярный и может отображать только 2-мерные (2D) изображения; 1 означает, что дисплей бинокулярный и может отображать 3-мерные (3D) изображения; 2 означает, что дисплей монокулярный, а 3 зарезервировано для будущего использования.
Биты с 1 по 0 выбирают симметрию кривизны левого-правого поля, причем значение 0 означает, что кривизна поля не определена. Если это поле равно нулю, то тогда все значения кривизны полей от А1 до Е5 должны быть установлены в нуль, кроме точки С3, которая должна задавать фокусное расстояние дисплея, или быть установлены в нуль, чтобы указать на то, что фокусное расстояние не задано. Значение 1 означает, что левый и правый дисплеи имеют одинаковую симметрию; 2 означает, что левый и правый дисплеи симметричны относительно вертикальной оси (столбец С), а значение 3 зарезервировано для будущего использования.
1-байтовое поле минимального межзрачкового расстояния (IPD) задает минимальное межзрачковое расстояние в миллиметрах (мм). Если это значение равно нулю, то тогда минимальное межзрачковое расстояние не задано. 1-байтовое поле максимального межзрачкового расстояния (IPD) задает максимальное межзрачковое расстояние в миллиметрах (мм). Если это значение равно нулю, то тогда максимальное межзрачковое расстояние не задано.
Точки поля списка кривизны поля содержат список из 25 2-байтовых параметров, которые задают фокусное расстояние в тысячах диоптрий (1/мм) в диапазоне от 1 до 65535 (например, 1 - это 0,001 диоптрии, а 65535 - это 65,535 диоптрий). 25 элементов в списке точек кривизны поля обозначены символами с А1 по Е5, как показано ниже. Точки должны быть равномерно распределены по активной зоне дисплея. Столбец С соответствует вертикальной оси дисплея, а строка 3 соответствует горизонтальной оcи дисплея. Столбцы А и Е соответствуют левому и правому краям дисплея соответственно. Строки 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 всех байтов в пакете, включая длину пакета.
44. Пакет клиента с сообщением об ошибках
Пакет клиента с сообщением об ошибках действует в качестве механизма или средства, позволяющего клиенту предоставить хосту список рабочих ошибок. Клиент может обнаружить широкий диапазон ошибок в ходе своей нормальной работы в результате приема некоторых команд от хоста. Примеры этих ошибок включают в себя следующие ситуации: клиенту может быть дана команда работать в режиме, который он не поддерживает; клиент может принять пакет, содержащий некоторые параметры, лежащие вне диапазона или за пределами возможностей клиента; клиенту может быть дана команда войти в режим в неправильной последовательности. Пакет клиента с сообщением об ошибках может быть использован для обнаружения ошибок во время нормальной работы, но очень полезной для разработчика и компоновщика системы является возможность диагностирования проблем при разработке и интеграции систем хоста и клиента. Клиент указывает, что способен посылать пакет клиента с сообщением об ошибках, используя значение параметра, равное 142, в ответном списке действительных параметров в пакете ответного списка действительных состояний.
Формат одного варианта пакета клиента с сообщением об ошибках показан для общего случая на фиг.87А. Как показано на фиг.87А, структура пакета клиента с сообщением об ошибках имеет поля длины пакета, типа пакета, ID с-клиента, количества пунктов в списке, списка кодов ошибок и поле CRC. Значение типа пакета, равное 142, идентифицирует пакет как пакет клиента с сообщением об ошибках. Поле ID с-клиента зарезервировано для будущего использования и в данный момент обычно установлено в нуль. Поле количества элементов в списке (2 байта) задает количество пунктов в последующем списке кодов ошибок. Поле списка кодов ошибок (здесь 8 байт) является списком, содержащим один или несколько пунктов списка сообщения об ошибках. Формат одного пункта списка сообщения об ошибках показан на фиг.87В.
В одном варианте, как показано на фиг.87В, каждый элемент списка сообщений об ошибках имеет ровно 4 байта в длину и в одном варианте имеет структуру, содержащую: 2-байтовое поле кода ошибки дисплея, которое задает тип сообщаемой ошибки; 2-байтовое поле субкода ошибки, задающее более высокий уровень детализации, относящийся к ошибке, определенной пакетом кодов ошибок клиента. Специальное описание каждого кода ошибки клиента определено изготовителем оборудования клиента. Субкод ошибки не должен быть определен для каждого кода ошибки дисплея, а в тех случаях, когда субкод ошибки не определен, указанное значение устанавливают в нуль. Специальное описание каждого субкода ошибки определяется изготовителем оборудования клиента.
45. Пакет идентификации клиента
Пакет идентификации клиента позволяет клиенту вернуть идентифицирующие данные в ответ на пакет запроса конкретного состояния. В одном варианте клиент указывает, что способен послать пакет идентификации дисплея, используя значение параметра, равное 144, в ответном списке действительных параметров в пакете ответного списка действительных состояний. Полезно, чтобы хост имел возможность определить имя изготовителя клиентского устройства и номер модели путем считывания этих данных у клиента. Эту информацию можно использовать, чтобы определить, имеет ли клиент специальные возможности, которые не могут быть описаны в пакете возможностей клиента. Имеется два потенциальных способа, средства или механизма для считывания идентифицирующей информации от клиента. Один из них связан с использованием пакета возможностей клиента, который содержит поля, аналогичные полям в базовой структуре EDID. Другой способ основан на использовании пакета идентификации клиента, который содержит более богатый информационный набор по сравнению с аналогичными полями в пакете возможностей клиента. Это позволяет хосту идентифицировать изготовителей, которым не был присвоен 3-символьный код EISA, и допускает использование в порядковых номерах алфавитно-цифровых символов.
Формат одного варианта пакета идентификации клиента показан в целом на фиг.88. Как показано на фиг.88, структура пакета идентификации клиента имеет поля длины пакета, типа пакета, ID с-клиента, недели изготовления, года изготовления, длины имени изготовителя, длины названия продукта, длины порядкового номера, строки имени изготовителя, строки названия продукта, строки порядкового номера и поле CRC.
2-байтовое поле типа пакета содержит значение, идентифицирующее пакет в качестве пакета идентификации дисплея. В одном варианте это значение выбрано равным 144. Поле ID с-клиента (2 байта) опять же зарезервировано для будущего использования для ID клиента и обычно установлено в нуль. Поле CRC (2 байта) содержит 16-разрядную проверку CRC всех байтов в пакете, включая длину байта.
1-байтовое поле недели изготовления содержит значение, которое определяет неделю изготовления дисплея. По меньшей мере в одном варианте это значение находится в диапазоне от 1 до 53, если это поле поддерживается клиентом. Если оно не поддерживается клиентом, то тогда оно обычно устанавливается в нуль. 1-байтовое поле года изготовления содержит значение, определяющее год изготовления клиентского дисплея. Это значение отсчитывается в виде сдвига относительно 1990 года как начальной точки, хотя можно использовать другие базовые годы. В этом поле могут быть представлены годы в диапазоне от 1991 до 2245. Например: год 2003 соответствует значению года изготовления, равному 13. Если это поле не поддерживается клиентом, его значение следует установить в нуль.
Каждое из полей длины имени изготовителя, длины названия продукта и длины порядкового номера содержит 2-байтовое значение, которое задает длину поля строки имени изготовителя, включающее любые символы, заканчивающиеся символом конца строки или нулевым заполняющим символом, длину поля строки названия продукта, включающую в себя любые символы, заканчивающиеся символом конца строки или нулевым заполняющим символом, и длину поля строки порядкового номера, включающую в себя любые символы, заканчивающиеся символом конца строки или нулевым заполняющим символом, соответственно.
Каждое из полей строки имени изготовителя, строки названия продукта и строки порядкового номера содержит переменное количество байтов, заданных полями длины имени изготовителя, названия продукта и порядкового номера соответственно, которое содержит строку ASCII, задающую соответственно изготовителя, название продукта и алфавитно-цифровой порядковый номер дисплея. Каждая из этих строк заканчивается по меньшей мере одним нулевым символом.
46. Пакет возможностей альтернативного дисплея
Пакет возможностей альтернативного дисплея указывает возможности альтернативных дисплеев, закрепленных за контроллером клиента MDDI. Он посылается в ответ на пакет запроса конкретного состояния. Клиентское устройство по запросу посылает пакет возможностей альтернативного дисплея для каждого альтернативного дисплея, который поддерживается. Клиент должен указать, что способен послать пакет возможностей альтернативного дисплея через значение параметра, равное 145, в ответном списке действительных параметров в пакете ответного списка действительных состояний.
Для систем MDDI, работающих во внутреннем режиме, возможно, что к контроллеру клиента MDDI подсоединено более одного дисплея. Примером такого приложения является мобильный телефон с большим дисплеем на внутренней стороне раскладного телефона, а меньшим дисплеем снаружи. Поле количества альтернативных дисплеев в пакете возможностей клиента используется для сообщения о том, что имеется более одного дисплея, а пакет возможностей альтернативного дисплея сообщает о возможностях каждого альтернативного дисплея. Пакет видеопотока содержит 4 бита в поле атрибутов пиксельных данных для адресации каждого альтернативного дисплея в клиентском устройстве.
Формат одного варианта пакета возможностей альтернативного дисплея показан для общего случая на фиг.89. Как показано на фиг.89, структура пакета возможностей альтернативного дисплея имеет поля длины пакета, типа пакета, ID с-клиента, номера альтернативного дисплея, поле pезервное 1, поля ширины битовой карты, высоты битовой карты, ширины окна дисплея, высоты окна дисплея, ширины цветовой карты RGB, возможностей RGB, возможностей монохромного формата, поле pезервное 2, поля возможностей Y Cb Cr, отличительных возможностей дисплея, поле резервное 3, а также поле CRC. Значение типа пакета, равное 145, идентифицирует пакет в качестве пакета возможностей альтернативного дисплея. Поле ID с-клиента зарезервировано для ID клиента для будущего использования и обычно устанавливается в нуль.
Поле номера альтернативного дисплея использует 1 байт для указания идентичности альтернативного дисплея целым числом в диапазоне от 0 до 15. Первый альтернативный дисплей должен иметь номер 0, а другие альтернативные дисплеи должны идентифицироваться по уникальным значениям номера альтернативного дисплея, причем максимальным используемым значением является общее количество альтернативных дисплеев минус 1. Значения, превышающие общее количество альтернативных дисплеев минус 1, использоваться не должны. Например, мобильный телефон, имеющий главный дисплей и дисплей идентификации вызывающего абонента, подсоединенный к клиенту MDDI, имеет один альтернативный дисплей, так что номером альтернативного дисплея для дисплея, идентифицирующего вызывающего абонента, будет нулевой номер, а поле количества альтернативных дисплеев в пакете возможностей дисплея будет иметь значение, равное 1.
Поле резервное 1 (1 байт) зарезервировано для будущего использования. Все биты в этом поле установлены в ноль. Это поле предназначено для того, чтобы обеспечить выравнивание всех последующих 2-байтовых полей по 16-разрядному адресу слова и обеспечить выравнивание всех 4-байтовых полей по 32-разрядному адресу слова.
Поле ширины битовой карты использует 2 байта, которые задают ширину битовой карты, выраженную количеством пикселей. Поле высоты битовой карты использует 2 байта, задающие высоту битовой карты, выраженную в количестве пикселей. Поле ширины дисплейного окна использует 2 байта, которые задают ширину дисплейного окна, выраженную количеством пикселей. Поле высоты дисплейного окна использует 2 байта, которые задают высоту дисплейного окна, выраженную количеством пикселей.
Поле ширины цветовой карты RGB использует два байта, которые задают количество бит красной, зеленой и синей цветовой компоненты, которые могут отображаться в режиме отображения цветовой карты (палитры). Для каждой цветовой компоненты (красная, зеленая и синяя) можно использовать максимум 8 бит. Хотя в пакете цветовой карты посылается ровно 8 бит каждой цветовой компоненты, используется только несколько младших значащих бит каждой цветовой компоненты, определенной в этом поле. Если клиент дисплея не может использовать формат цветовой карты (палитры), то тогда значение обсуждаемого поля равно нулю. Слово ширины цветовой карты RGB состоит из трех отдельных значений без знака:
Биты с 3 по 0 определяют максимальное количество бит синего цвета в каждом пикселе, причем действительными считаются значения от 0 до 8. Биты с 7 по 4 определяют максимальное количество бит зеленого цвета в каждом пикселе, причем действительными считаются значения от 0 до 8. Биты с 11 по 8 определяют максимальное количество бит красного цвета в каждом пикселе, причем действительными считаются значения от 0 до 8. Биты с 14 по 12 зарезервированы для будущего использования, и обычно устанавливаются в нуль. Бит 15 используется для индикации возможности клиента принимать пиксельные данные цветовой карты в упакованном или неупакованном формате. Когда бит 15 установлен на уровень логической единицы, это указывает на то, что клиент может принимать пиксельные данные цветовой карты в упакованном или неупакованном формате. Если бит 15 установлен на уровень логического нуля, это указывает на то, что клиент может принимать пиксельные данные цветовой карты только в неупакованном формате.
Поле возможностей RGB использует 2 байта для задания количества бит разрешения, которое может отображаться в формате RGB. В одном варианте, если клиент не может использовать формат RGB, то это значение устанавливают равным нулю. Слово возможностей RGB состоит из трех отдельных значений без знака: биты с 3 по 0 определяют максимальное количество бит синего цвета (интенсивность синего в каждом пикселе), биты с 7 по 4 определяют максимальное количество бит зеленого цвета (интенсивность зеленого в каждом пикселе), а биты с 11 по 8 определяют максимальное количество бит красного цвета (интенсивность красного в каждом пикселе). Биты с 14 по 12 зарезервированы для будущего использования и установлены в нуль. Бит 15 используют для указания способности клиента принимать пиксельные данные RGB в упакованном или неупакованном формате. Когда бит 15 установлен на уровень логической единицы, это указывает на то, что клиент может принимать пиксельные данные RGB в упакованном или неупакованном формате. Если бит 15 установлен на уровень логического нуля, это указывает на то, что клиент может принимать пиксельные данные RGB только в неупакованном формате.
1-байтовое поле возможностей монохромного формата содержит значение или информацию для задания количества бит разрешения, которое может быть отображено в монохромном формате. Если клиент не может использовать монохромный формат, то тогда это значение устанавливают равным нулю. Биты с 6 по 4 зарезервированы для будущего использования и обычно устанавливаются в ноль. Биты с 3 по 0 определяют максимальное количество бит серой шкалы, которое может находиться в каждом пикселе. Эти четыре бита позволяют задать каждый пиксель в составе от 1 до 15 бит. Если указанное значение равно нулю, то тогда монохромный формат клиентом не поддерживается. Бит 7, установленный в единицу, указывает на то, что клиент может принимать монохромные пиксельные данные в упакованном или неупакованном формате. Если бит 7 установлен в нуль, это указывает на то, что клиент может принимать монохромные пиксельные данные только в неупакованном формате.
Поле резервное 2 имеет ширину 1 байт и зарезервировано для будущего использования, причем обычно все биты в этом поле установлены на уровне логического нуля. В одном варианте это поле предназначено для того, чтобы обеспечить выравнивание всех последующих 2-байтовых полей по 16-разрядному адресу слова и выравнивание всех 4-байтовых полей по 32-разрядному адресу слова.
2-байтовое поле возможностей Y Cb Cr задает количество бит разрешения, которое может быть отображено в формате Y Cb Cr. Если клиент не может использовать формат Y Cb Cr, то тогда это значение равно нулю. Слово возможностей Y Cb Cr состоит из трех отдельных значений без знака: биты с 3 по 0 определяют максимальное количество бит, которые задают выборку Cb, биты с 7 по 4 определяют максимальное количество бит, которые задают выборку Cr, биты с 11 по 8 определяют максимальное количество бит, которые задают выборку Y, а биты с 14 по 12 зарезервированы для будущего использования и установлены в нуль. Когда бит 15 установлен в 1, это указывает на то, что клиент может принимать пиксельные данные Y Cb Cr в упакованном или неупакованном формате. Если бит 15 установлен в нуль, это указывает на то, что клиент может принимать пиксельные данные Y Cb Cr только в неупакованном формате.
1-байтовое поле возможностей формата Bayer задает количество бит разрешения, пиксельную группу и порядок пикселей, которые могут пересылаться в формате Bayer. Если клиент не может использовать формат Bayer, то тогда это значение устанавливают в нуль. Поле возможностей формата Bayer состоит из следующих значений: биты с 3 по 0 определяют максимальное количество бит интенсивности, которые имеются в каждом пикселе, биты с 5 по 4 определяют шаблон пиксельной группы, который может потребоваться, биты с 8 по 6 определяют требуемый порядок пикселей, а биты с 14 по 9 зарезервированы для будущего использования и устанавливаются в ноль. Когда бит 15 установлен в единицу, это указывает на то, что клиент может принимать пиксельные данные формата Bayer в упакованном или неупакованном формате. Если бит 15 установлен в нуль, это указывает на то, что клиент может принимать пиксельные данные формата Bayer только в неупакованном формате.
2-байтовое поле CRC содержит 16-разрядную проверку CRC всех байтов в пакете, включая длину пакета.
47. Пакет доступа к регистрам
Пакет доступа к регистрам обеспечивает хост или клиента средством, механизмом или способом доступа к регистрам конфигурации и состояния на противоположном конце линии связи MDDI. Скорее всего, эти регистры являются уникальными для каждого контроллера дисплея или устройства. Эти регистры уже существуют во многих дисплеях, которые требуют настройки конфигураций, режимов работы и имеют другие полезные и необходимые настройки. Пакет доступа к регистрам позволяет хосту или клиенту MDDI делать запись в регистр и запрашивать считывание регистра, используя линию связи MDDI. Когда хост или клиент запрашивает считывание регистра, на противоположном конце должна последовать реакция в виде посылки данных регистра в том же типе пакета, но также с индикацией о том, что это данные, считанные из конкретного регистра с использованием поля считывания/записи информации. Пакет доступа к регистрам можно использовать для считывания или записи в множестве регистров путем задания отсчета регистров, большего 1. Клиент указывает на возможность поддержки пакета доступа к регистрам, используя бит 22 поля отличительных возможностей клиента в пакете возможностей клиента.
Формат одного варианта пакета доступа к регистрам показан в общем виде на фиг.90. Как показано на фиг.90, структура пакета доступа к регистрам имеет поля длины пакета, типа пакета, ID b-клиента, флагов считывания/записи, адреса регистра, CRC параметра, списка данных регистра и CRC данных регистра. Значение типа пакета, равное 146, идентифицирует пакет как пакет доступа к регистрам. Поле ID b-клиента зарезервировано для будущего использования и в настоящее время обычно устанавливаются в ноль.
2-байтовое поле флагов считывания/записи задает определенный пакет либо записи, либо считывания или ответ на считывание и обеспечивает отсчет значений данных.
Биты с 15 по 14 действуют как флаги считывания/записи. Если биты [15:14] равны '00', то тогда этот пакет содержит данные, подлежащие записи в регистр, адресуемый полем адреса регистра. Данные, подлежащие записи в определенные регистры, содержатся в поле списка данных регистра. Если биты [15:14] равны '10', то тогда это означает запрос данных из одного или нескольких регистров, адресуемых полем адреса регистра. Если биты [15:14] равны '11', то тогда этот пакет содержит данные, запрошенные в ответ на пакет доступа к регистрам, имеющий биты [15:14] флагов считывания/записи, установленные в '10'. Поле адреса регистра содержит адрес регистра, соответствующего первому пункту списка данных регистра, а поле списка данных регистра должно содержать данные, считанные с упомянутого адреса или адресов. Если биты [15:14] равны '01', то тогда это трактуется как недействительное значение, при этом указанное значение зарезервировано для будущего использования и обычно сейчас не используется.
Биты 13:0 используют 14-разрядное целое число без знака для задания количества 32-разрядных пунктов данных регистра, подлежащих пересылке в поле списка данных регистра. Если биты 15:14 равны '00', то тогда биты 13:0 задают количество 32-разрядных пунктов данных регистра, которые содержатся в поле списка данных регистра, подлежащем записи в регистры, начиная с регистра, заданного полем адреса регистра. Если биты 15:14 равны '10', то тогда биты 13:0 задают количество 32-разрядных пунктов данных регистра, которые приемное устройство посылает на устройство, запрашивающее считывание с этих регистров. Поле списка данных регистра в этом пакете не содержит пунктов и имеет нулевую длину. Если биты 15:14 равны '11', то тогда биты 13:0 задают количество 32-разрядных пунктов данных регистра, которые были считаны из регистров и которые содержатся в поле списка данных регистра. Биты 15:14 в настоящее время не установлены равными '01', что считается недействительным значением, и зарезервированы для будущих обозначений или использования.
Поле адреса регистра использует 4 байта для указания адреса регистра, куда производится запись или откуда выполняется считывание. Для адресации регистров, чьи адреса составляют меньше 32 бит, старшие биты устанавливают в нуль.
2-байтовое поле CRC параметра содержит CRC всех байт от длины пакета до адреса регистра. Если эта проверка CRC дала отрицательный результат, то тогда весь пакет отбрасывается.
Поле списка данных регистра содержит список 4-байтовых значений данных регистра, подлежащих записи в регистры клиента, или значения, которые были считаны из регистров клиентского устройства.
2-байтовое поле CRC данных регистра содержит CRC только данных регистра. Если эта проверка CRC дала отрицательный результат, то данные регистра еще можно использовать, но значение отсчета ошибок CRC увеличивается на единицу.
D. CRC пакета
Поля CRC появляются в конце пакетов, а иногда после некоторых более критических параметров в пакетах, которые могут иметь значительно большее поле данных и, следовательно, повышенную вероятность ошибок во время пересылки. В пакетах, которые имеют два поля CRC, генератор CRC, когда он используется в единственном числе, вновь инициализируется после первой CRC, так что вычисления CRC, следующие после длинного поля данных, не зависят от параметров в начале пакета.
В приведенном в качестве примера варианте полином, используемый для вычисления CRC, известен как CRC-16 или Х16+Х15+Х2+Х0. На фиг.36 показан простой вариант реализации генератора и проверочного блока CRC 3600, полезного для реализации изобретения. На фиг.36 регистр CRC 3602 инициализируется со значением 0x0001 как раз перед пересылкой первого бита пакета, который вводится по линии Tx_MDDI_Data_Before_CRC, затем байты пакета сдвигаются в регистре, начиная с первого младшего значащего бита (LSB). Заметим, что номера бит регистра на этой фигуре соответствуют порядку используемого полинома и не соответствуют позициям бит, используемых интерфейсом MDDI. Более эффективно сдвигать регистр CRC в одном направлении, что приводит к появлению бита 15 CRC на битовой позиции 0 поля MDDI CRC, и бита 14 регистра CRC в битовой позиции 1 поля MDDI CRC и так далее, пока не будет достигнута битовая позиция 14 MDDI.
Например, если контент пакета для пакетов запроса и состояния дисплея представляет собой: 0x07, 0x46, 0x000400, 0x00 (или представлен в виде последовательности байт: 0x07, 0x00, 0x46, 0x00, 0x04, 0x00, 0x00) и представлен с использованием входов мультиплексоров 3604 и 3606 и логического элемента И-НЕ 3608, результирующий выход CRC по линии Tx_MDDI_Data_With_CRC составит 0x0еа1 (или будет представлен в виде последовательности 0xа1, 0x0е).
Когда генератор и проверочный блок CRC 3600 сконфигурирован в виде проверочного блока CRC, проверка CRC, которая принимается по линии Rx_MDDI_Data, вводится в мультиплексор 3604 и логический элемент И-НЕ (NAND) 3608 и сравнивается бит за битом со значением, найденным в регистре CRC с использованием логического элемента ИЛИ-НЕ (NOR) 3610, логическом элементе «исключающее ИЛИ» (XOR) 3612 и логическом элементе И (AND) 3614. Если есть какие-либо ошибки на выходе логического элемента И 3614, то CRC увеличивается на единицу для каждого пакета, который содержит ошибку CRC, благодаря соединению выхода логического элемента 3614 с входом регистра 3602. Заметим, что пример схемы, показанной на фиг.36, может выдавать более одного сигнала ошибки CRC в заданном окне Check_CRC_Now (см. фиг.37В). Следовательно, счетчик ошибок CRC обычно считает только первый случай ошибки CRC в каждом интервале, где Check_CRC_Now активен. Если устройство 3600 сконфигурировано в виде генератора 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.
E. Перегрузка кода ошибки для CRC пакета
Всякий раз, когда между хостом и клиентом пересылаются только пакеты данных и CRC, коды ошибок не предоставляются. Единственная ошибка, о которой становится известно, - это потеря синхронизации. В ином случае необходимо ждать простоя из-за отсутствия хорошего тракта или конвейера для пересылки данных с последующей установкой в исходное состояние и продолжением работы. К сожалению, на это расходуется время и снижается эффективность.
В одном варианте для использования был разработан новый способ, в котором часть CRC пакетов используется для пересылки информации о коде ошибки. В общем виде это показано на фиг.65. То есть процессоры или устройства, обрабатывающие пересылку данных, создают один или несколько кодов ошибок, указывающих на конкретные предварительно определенные ошибки или дефекты, которые могут появиться при обработке или в линии связи. Когда возникает ошибка, создается соответствующий код ошибки, который пересылается с использованием бит для CRC пакета, то есть значение CRC перегружается или перезаписывается с требуемым кодом ошибки, который может быть обнаружен на приемном конце блоком, контролирующим ошибки, или проверочным блоком, контролирующим значения поля CRC. Для случаев, при которых код ошибки по какой-то причине совпадает со значением CRC, во избежание путаницы пересылается дополнение ошибки.
В одном варианте для обеспечения надежной системы предупреждения и обнаружения ошибок код ошибки может пересылаться несколько раз с использованием ряда пакетов, обычно всех, которые пересылаются или посылаются после того, как ошибка была обнаружена. Это происходит, пока точка, в которой условие, создающее ошибку, больше не присутствует в системе, в момент, когда регулярные биты CRC пересылаются без перегрузки на другое значение.
Этот способ перегрузки значения CRC обеспечивает гораздо более быструю реакцию на системные ошибки при использовании минимального количества дополнительных бит или полей.
Как показано на фиг.66, механизм или устройство 6600 перезаписи CRC использует детектор или средство 6602 обнаружения ошибок, которое может формировать часть других ранее описанных или известных схем, причем устройство 6602 обнаруживает наличие или существование ошибок в линии или процессе передачи данных. Генератор или средство 6604 создания кода ошибки, которое может быть сформировано как часть других схем или использовать такие способы, как справочные таблицы, для запоминания предварительно выбранных сообщений об ошибке, создает один или несколько кодов ошибки для указания специфических предварительно определенных ошибок или дефектов, которые были обнаружены при их появлении. Очевидно, что устройства 6602 и 6604 можно по желанию сформировать в виде единой схемы или устройства либо в виде части последовательности программных этапов для других известных процессоров и элементов.
Компаратор или средство 6606 сравнения значений CRC служит для проверки того, совпадает ли выбранный код или коды ошибки с аналогичным кодом в виде пересылаемого значения CRC. Если это именно так, то тогда для обеспечения дополнения кодов ошибки используют генератор или средство или устройство создания дополнения кода, с тем чтобы не ошибиться относительно исходной комбинации или значения CRC и не запутать или усложнить схему обнаружения. Затем селектор, элемент выбора или устройство 6610 выбора кода ошибки выбирает код или значение ошибки, которое требуется, для ввода или перезаписи либо выбирает соответствующие дополнения в зависимости от того, что лучше подходит. Блок перезаписи, механизм перезаписи или средство перезаписи 6612 CRC кода ошибки является устройством, которое принимает поток данных, пакеты и требуемые коды, подлежащие вводу, и перезаписывает соответствующие или подходящие значения CRC, чтобы переслать требуемые коды ошибки в приемное устройство.
Как упоминалось выше, код ошибки может пересылаться несколько раз с использованием ряда пакетов, так что блок 6612 перезаписи может использовать элементы памяти для поддержки копий кодов во время обработки или повторно вызывать эти коды из предыдущих элементов или других известных ячеек памяти, которые можно использовать для запоминания или хранения их значений, если это необходимо или желательно.
Общая обработка, которая реализуется механизмом перезаписи по фиг.66, подробно показана на фиг.67А и 67В. На фиг.67А на этапе 6702 обнаруживается одна или несколько ошибок в данных или процессе передачи, а на этапе 6704 выбирается код ошибки, указывающий это состояние. Одновременно или в подходящий момент на этапе 6706 проверяется значение CRC, подлежащее подстановке, а на этапе 6708 выполняется его сравнение с желаемым кодом ошибки. Результат этого сравнения, как обсуждалось выше, определяет, совпадает ли желаемый код или другие репрезентативные значения с текущим значением CRC. Если это так, то процесс обработки переходит к этапу 6712, где в качестве кода для ввода выбирается дополнение или в некоторых случаях другое репрезентативное значение по желанию. Как только определено, что коды или значения ошибок должны быть введены на этапах 6710 и 6714, выбирается соответствующий код для ввода. Эти этапы показаны для ясности отдельно, но в общем случае они представляют единый выбор на основе результата решения на этапе 6708. Наконец, на этапе 6716 соответствующие значения перезаписываются по месту CRC для пересылки с предназначенными пакетами.
Как показано на фиг.67В, на приемной стороне значения CRC пакета контролируются на этапе 6722. Обычно значения CRC контролируются одним или несколькими процессами в системе, чтобы определить, появилась ли ошибка при пересылке данных и надо ли запрашивать повторную передачу пакета или пакетов или запретить дальнейшие операции и т.д., что частично обсуждалось выше. Как часть указанного контроля, эта информация также может быть использована для сравнения значений с известными или предварительно выбранными кодами ошибок или репрезентативными значениями и обнаружения наличия ошибок. В альтернативном варианте может быть реализован отдельный процесс обнаружения ошибок и контроль. Если появляется код для представления, он выделяется или отмечается иным образом на этапе 6724 для дальнейшей обработки. На этапе 6726 можно определить, является ли он действительным кодом или дополнением, и в случае если это дополнение, то используют дополнительный этап 6728 для преобразования этого значения в желаемое значение кода. В любом случае результирующий выделенный код, дополнение или другие восстановленные значения используются затем на этапе 6730 для определения на основе переданного кода того, какая ошибка появилась.
V. Повторный запуск линии связи из состояния бездействия
Когда хост повторно запускает прямую линию связи из состояния бездействия, он поддерживает MDDI_Data в состоянии логической единицы примерно для 150 периодов MDDI_Stb, а затем поддерживает MDDI_Data0 в состоянии логического нуля для 50 периодов MDDI_Stb, после чего запускает трафик прямой линии связи, посылая пакет заголовка субкадра. В общем случае это позволяет разрешить конфликтные ситуации в шине перед посылкой пакета заголовка субкадра в результате того, что обеспечивается достаточное время установления между сигналами. Когда хост приводит MDDI_Data0 в состояние логической единицы, он также активизирует MDDI_Stb, чтобы обеспечить тактовый импульс для активизации логических схем у клиента.
Когда клиент, здесь это дисплей, нуждается в данных, связи или услуге от хоста, он поддерживает линию MDDI_Data0 в состоянии логической единицы в течение примерно от 70 до 1000 мкс, в то время как активизированы MDDI_Stb плюс 70 периодов MDDI_Stb, после того как MDDI_Stb становятся активной (хотя при желании могут быть использованы другие периоды), а затем блокирует драйвер, переводя его в высокоимпедансное состояние. Если MDDI_Stb активна в период бездействия, хотя это маловероятно, то тогда клиент может поддерживать в состоянии логической единицы только MDDI_Data0 в течение 70 периодов MDDI_Stb. Это действие заставляет хост запустить или повторно запустить трафик данных по прямой линии связи (208) и запросить клиента о его состоянии. Хост должен обнаружить наличие ответного импульса в течение 50 периодов MDDI_Stb, а затем он инициирует последовательность запуска, поддерживающую MDDI_Data0 в состоянии логической единицы в течение 150 периодов MDDI_Stb и в состоянии логического нуля в течение 50 периодов MDDI_Stb. Дисплей не должен посылать импульс запроса обслуживания, если он определит, что MDDI_Data0 находится в состоянии логической единицы в течение более 50 мкс. Характер выбора моментов времени и допустимых отклонений временных интервалов, связанных с обработкой состояния бездействия и последовательностью запуска, подробно обсуждается ниже (см. фиг.68А-С).
Пример этапов обработки для случая 3800 типового клиентского запроса обслуживания без конфликтной ситуации показан на фиг.38, где события для удобства иллюстрации помечены буквами A, B, C, D, E, F и G. Процесс начинается в точке А, когда хост посылает на клиентское устройство пакет отключения линии связи, чтобы проинформировать его о том, что линия связи перейдет в состояние бездействия с низким энергопотреблением. На следующем этапе хост переходит в состояние бездействия с низким энергопотреблением путем блокирования драйвера MDDI_Data0 и установки драйвера MDDI_Stb в логический ноль, как показано в точке В. MDDI_Data0 переводится на уровень логического нуля высокоимпедансной цепью смещения. По истечении некоторого времени клиент посылает импульс запроса обслуживания на хост, переводя MDDI_Data0 на уровень логической единицы, как показано в точке С. Хост все еще поддерживает уровень логического нуля, используя высокоимпедансную цепь смещения, но драйвер у клиента принудительно переводит линию на уровень логической единицы. В течение 50 мкс хост обнаруживает импульс запроса обслуживания и подтверждает уровень логической единицы для MDDI_Data0, включая свой драйвер, как показано в точке D. Затем клиент прекращает попытки подтверждения импульса запроса обслуживания и приводит свой драйвер в состояние с высоким импедансом, как показано в точке Е. Хост переводит MDDI_Data0 на уровень логического нуля в течение 50 мкс, как показано в точке F, а также начинает генерировать импульсы MDDI_Stb, согласуясь с уровнем логического нуля на MDDI_Data0. После установки MDDI_Data0 на уровень логического нуля и возбуждения MDDI_Stb в течение 50 мкс хост начинает передачу данных по прямой линии связи, посылая пакет заголовка субкадра, как показано в точке G.
Аналогичный пример показан на фиг.39, где запрос обслуживания утверждается после начала последовательности повторного запуска линии связи, причем события опять же помечены буквами A, B, C, D, E, F и G. Здесь представлен наихудший сценарий, когда импульс или сигнал запроса от клиента поступает очень близко к моменту разрушения пакета заголовка субкадра. Процесс начинается в точке А, когда хост вновь посылает на клиентское устройство пакет отключения линии связи, чтобы проинформировать его о том, что линия связи перейдет в состояние бездействия с низким энергопотреблением. На следующем этапе хост входит в состояние бездействия с низким энергопотреблением, блокируя драйвер 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 мкс хост начинает передавать данные по прямой линии связи, посылая пакет заголовка субкадра, как показано в точке 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 непрерывных тактовых периодов для линии данных, находящейся на высоком уровне, за которыми следует по меньшей мере 50 непрерывных тактовых периодов для линии данных, находящейся на низком уровне. Как только оба эти условия выполнены, клиент может начать поиск уникального слова первого субкадра. Прерывание в этой комбинации используется в качестве причины для возврата счетчиков в начальное состояние, при котором клиент снова просматривает первые 150 непрерывных тактовых периодов линии данных, находящейся на высоком уровне.
Клиентская реализация изобретения для хоста на основе выхода из состояния бездействия очень похожа на случай первоначального запуска за исключением того, что частота тактовых импульсов не должна форсированно начинаться с 1 Мбит/с, как обсуждалось ранее. Вместо этого тактовая частота может быть установлена для возобновления с какого-то предыдущего значения, когда линия связи перешла в состояние бездействия. Если хост начинает передачу стробирующего сигнала, как было описано выше, клиент должен быть способен вновь отсчитать по меньшей мере 150 непрерывных тактовых периодов линии данных, находящейся на высоком уровне, за которыми следует по меньшей мере 50 непрерывных тактовых импульсов линии данных, находящейся на низком уровне. Как только эти два условия соблюдены, клиент может начать поиск уникального слова.
Клиентская реализация изобретения для клиента на основе выхода из состояния бездействия аналогична реализации для хоста на основе активизации за исключением того, что она начинается с возбуждения клиентом линии данных. Клиент может асинхронно возбуждать линию данных без тактового импульса, чтобы активизировать хост-устройство. Как только хост узнает, что линия данных установлена клиентом на высоком уровне, он может начать свою последовательность активизации. Клиент может подсчитать количество тактовых периодов, созданных хостом, в начале или во время процесса активизации. Как только клиент отсчитал 70 непрерывных тактовых периодов данных на высоком уровне, он может прекратить поддержку линии данных на высоком уровне. В этот момент хост должен уже поддерживать линию данных на высоком уровне. Затем клиент может отсчитать еще 80 непрерывных тактовых периодов линии данных на высоком уровне, чтобы достичь 150 тактовых периодов линии данных на высоком уровне, а затем может просмотреть 50 тактовых периодов линии данных на низком уровне. Поскольку эти три условия выполнены, клиент может начать поиск уникального слова.
Преимущество этой новой реализации обработки активизации состоит в том, что устраняется необходимость в устройстве для измерения времени. Будь это осциллограф, схема разряда конденсатора или другие известные устройства такого рода, клиент больше не нуждается в таких внешних устройствах для определения условий запуска. Это экономит деньги и схемную площадь при реализации контроллеров, счетчиков и т.д. на плате клиентского устройства. Хотя это может и не являться преимуществом для клиента, но для хоста этот способ должен также потенциально упростить хост с точки зрения логических схем сверхвысокой плотности (VHDL), используемых в базовых схемах. Энергопотребление при использовании линий данных и стробирующих сигналов в качестве источника уведомлений и измерения также снизится, поскольку не будет необходимости в работе внешних схем для базовых элементов в ожидании активизации на основе хоста.
Количество используемых периодов или тактовых периодов приведено здесь только в качестве примера, и специалистам в данной области техники должно быть очевидно, что можно использовать другое количество периодов.
Преимущества этой новой реализации обработки активизации состоит в том, что устраняется необходимость в устройстве для измерения времени. Будь это осциллограф, схема разряда конденсатора или другие известные устройства такого рода, клиент больше не нуждается в таких внешних устройствах для определения условий запуска. Это экономит деньги и схемную площадь при реализации контроллеров, счетчиков и т.д. на плате клиентского устройства. Хотя это может и не являться преимуществом для клиента, но для хоста этот способ должен также потенциально упростить хост с точки зрения логических схем сверхвысокой плотности (VHDL), используемых в базовых схемах. Энергопотребление при использовании линий данных и стробирующих сигналов в качестве источника уведомлений и измерения также снизится, поскольку не будет необходимости в работе внешних схем для базовых элементов в ожидании активизации на основе хоста.
Для разъяснения и иллюстрации действия этого нового способа на фиг.68А, 68В и 68С показаны временные диаграммы для MDDI_Data0, MDDI_Stb, а также различные операции, привязанные к тактовым периодам.
Пример этапов обработки для типовой активизации, инициированной хостом, без конфликтной ситуации показан на фиг.68А, где события опять же помечены для удобства демонстрации буквами A, B, C, D, E, F и G. Процесс начинается в точке А, когда хост посылает на клиентское устройство пакет отключения линии связи, чтобы проинформировать его о том, что линия связи перейдет в состояние бездействия с низким энергопотреблением. На следующем этапе (точка В) хост переключает 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_Data0 и MDDI_Stb. Хост переводит MDDI_Data0 на уровень логической единицы, а MDDI_Stb на уровень логического нуля на время, которое понадобится драйверу для полного разблокирования своих соответствующих выходов. Хост обычно ожидает порядка 200 наносекунд после того, как эти выходные сигналы достигнут желаемых логических уровней перед возбуждением импульсов по линии MDDI_Stb. Это дает клиенту время на подготовку к приему.
При том что драйверы хоста разблокированы и MDDI_Data0 установлена на уровень логической единицы, хост приступает к переключению MDDI_Stb в течение 150 периодов MDDI_Stb, как показано в точке Е. Хост поддерживает MDDI_Data0 на уровне логического нуля в течение 50 периодов, как показано в точке F, а клиент начинает поиск пакета заголовка субкадра, после того как MDDI_Data0 находится на уровне логического нуля в течение 40 периодов MDDI_Stb. Хост начинает передачу данных по прямой линии связи, посылая пакет заголовки субкадра, как показано в точке G.
Пример этапов обработки для типовой активизации, инициированной клиентом, без конфликтной ситуации показан на фиг.68В, где события опять же помечены для удобства демонстрации буквами A, B, C, D, E, F, G, H и I. Как и раньше, процесс начинается в точке А, когда хост посылает пакет отключения линии связи, чтобы проинформировать клиента о том, что линия связи перейдет в состояние с низким энергопотреблением.
В точке В хост переключает 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 на уровень логической единицы.
В течение примерно 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.
Как видно из этой фигуры, в точках G и H хост держит MDDI_Data0 на уровне логического нуля в течение 50 периодов, а клиент начинает поиск пакета заголовка субкадра, после того как MDDI_Data0 находится на уровне логического нуля в течение 40 периодов MDDI_Stb. Хост начинает передачу данных по прямой линии связи, посылая пакет заголовка субкадра, как показано в точке I.
Пример этапов обработки для типовой активизации, инициированной хостом, при конфликтной ситуации из-за клиента, то есть когда клиент также хочет активизировать линию связи, показан на фиг.68С. События опять же помечены для удобства демонстрации буквами A, B, C, D, E, F, G, H и I. Как и раньше, процесс начинается в точке А, когда хост посылает пакет отключения линии связи, чтобы проинформировать клиента о том, что линия связи перейдет в состояние с низким энергопотреблением, продолжается до точки В, где MDDI_Stb переключается примерно в течение 64 периодов (или как это потребуется согласно проекту системы), чтобы дать возможность клиенту выполнить обработку, которая должна закончиться, а затем процесс переходит в точку С, где хост входит в состояние бездействия с низким энергопотреблением. После некоторого периода времени хост начинает последовательность повторного запуска линии связи в момент 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 периодов, как показано в точке H, а клиент начинает поиск пакета заголовка субкадра после того, как MDDI_Data0 остается на уровне логического нуля в течение 40 периодов MDDI_Stb. Хост начинает передачу данных по прямой линии связи, посылая пакет заголовка субкадра, как показано в точке I.
VI. Электрические спецификации интерфейса
В предложенных в качестве примера вариантах данные в формате «без возврата к нулю» (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 изменяется или удерживает свои уровни или значения.
После приема этих сигналов с ними выполняется операция «логическое ИЛИ (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 подсоединен для приема сигнала DATA и выходных сигналов обоих триггеров, при этом он создает выходной сигнал, обеспечивающий ввод данных для второго триггера, который, в свою очередь, создает сигналы MDDI_Stb+, и MDDI_Stb-. Для удобства вентиль «исключающее ИЛИ-НЕ» имеет инверсный кружок, чтобы указать, что он инвертирует выходной сигнал Q триггера, который создает стробирующий сигнал.
В приемной части 4120 по фиг.41 сигналы MDDI_Data0+, MDDI_Data0- и MDDI_Stb+, MDDI_Stb- принимаются каждый двумя дифференциальными приемниками 4122 и 4124, которые создают единые выходные сигналы из дифференциальных сигналов. Затем выходные сигналы усилителей подаются на входы двухвходового вентиля, схемы или логического элемента «исключающее ИЛИ (XOR)» 4126, который создает тактовый сигнал. Тактовый сигнал используется для переключения каждой из двух триггерных схем 4128 и 4130 типа D, которые принимают задержанную версию сигнала DATA через элемент 4132 задержки, один из которых (4128) создает значения '0' данных, а другой (4130) значения '1' данных. Тактовый сигнал также выводится независимо из логического элемента «исключающее ИЛИ». Поскольку тактовая информация распределяется между линиями DATA и STB, ни один сигнал не переходит из одного состояния в другое быстрее, чем с половиной тактовой частоты. Поскольку тактовые сигналы воспроизводятся с использованием операции «исключающее ИЛИ» с сигналами DATA и STB, система допускает практически удвоенную асимметрию между входными данными и тактовыми сигналами по сравнению с ситуацией, когда тактовый сигнал посылается непосредственно по единственной выделенной линии данных.
Пары MDDI Data и сигналы MDDI_Stb+ и MDDI_Stb- работают в дифференциальном режиме для обеспечения максимальной устойчивости к отрицательным воздействиям шума. Каждая часть тракта дифференциального сигнала имеет оконечную нагрузку, равную половине характеристического импеданса кабеля или проводника, используемого для пересылки сигналов. Пары MDDI Data имеют оконечную нагрузку на обоих концах: хоста и клиента. Поскольку в данный момент времени активизирован только один из этих двух драйверов, оконечная нагрузка постоянно существует в источнике для линии пересылки. Сигналы MDDI_Stb+ и MDDI_Stb- возбуждаются только хостом.
Пример конфигурации элементов, пригодных для обеспечения драйверов, приемников и оконечной нагрузки для пересылки сигналов как часть предложенного в изобретении интерфейса MDDI, показан на фиг.42, в то время как соответствующие электрические характеристики (постоянного тока) для MDDI_Data и MDDI_Stb показаны в таблице VII. В этом примере интерфейса используется низковольтное считывание (здесь 200 мВ), с перепадами питания менее 1 В и низким энергопотреблением.
Электрические параметры и характеристики дифференциальных драйверов линии и приемников линии описаны в таблице VIII. С функциональной точки зрения драйвер пересылает логический уровень на входе непосредственно на положительный выход, а инверсию входа на отрицательный выход. Задержка от входа к выходам точно согласована с дифференциальной линией, которая возбуждается дифференциально. В большинстве реализаций перепад напряжения на выходах меньше перепада на входах для минимизации энергопотребления и электромагнитного излучения. В таблице VII минимальный перепад напряжения представлен величиной порядка 0,5 В. Однако, как известно специалистам в данной области техники, можно использовать другие значения, и авторы изобретения предполагают использование меньшего значения в некоторых вариантах в зависимости от проектных ограничений.
Дифференциальные приемники линии имеют такие же характеристики, как высокоскоростной компаратор напряжения. На фиг.41 вход без кружочка является положительным входом, а вход с кружочком - отрицательным входом. Выход равен логической единице, если (Vinput+)-(Vinput-) больше нуля. Другим вариантом для этой операции является дифференциальный усилитель с очень большим (теоретически бесконечным) коэффициентом усиления и выходным сигналом, ограниченным уровнями напряжения, соответствующими логическому 0 и логической 1.
Асимметрия задержки между разными парами должна быть минимизирована, чтобы дифференциальная система передачи работала с максимально возможной скоростью.
На фиг.42 показаны контроллер 4202 хоста и контроллер 4204 клиента или дисплея, которые пересылают пакеты по линии 4206 связи. Контроллер хоста использует набор из трех драйверов 4210, 4212 и 4214 для приема сигналов DATA и STB хоста, подлежащих пересылке, а также для приема сигналов DATA клиента, подлежащих пересылке. Драйвер, ответственный за посылку DATA хоста использует вход для сигнала разрешения, позволяющего активизировать линию связи в общем случае только тогда, когда требуется пересылка от хоста к клиенту. Поскольку сигнал STB формируется как часть пересылки данных, дополнительный сигнал разрешения для этого драйвера (4212) не используется. Выходы каждого из драйверов DATA и STB подсоединены к оконечным импедансам или резисторам 4216а, 4216b, 4216с и 4216d соответственно.
Оконечные резисторы 4216а и 4216b также действуют в качестве импедансов на входе приемника 4220 на стороне клиента для обработки сигнала STB, в то время как дополнительные оконечные резисторы 4216е и 4216f включены последовательно с резисторами 4216с и 4216d соответственно на входе приемника 4222 обработки данных клиента. Шестой драйвер 4226 в контроллере клиента используется для подготовки сигналов данных, пересылаемых от клиента хосту, где драйвер 4214 через оконечные резисторы 4216с и 4216d на входной стороне обрабатывает данные для пересылки на хост для обработки.
Между оконечными резисторами и землей и источником 4220 напряжения помещены два дополнительных резистора 4218а и 4218b соответственно, как часть управления режимом бездействия, обсуждаемого в другом месте. Источник напряжения используется для установки линий пересылки на высокий или низкий уровни, как обсуждалось выше, для управления потоком данных.
Вышеуказанные драйверы и импедансы могут быть сформированы в виде дискретных компонент или в виде части схемного модуля или специализированной интегральной схемы (ASIC), которая является более экономичной в качестве кодера или декодера.
Из фигуры видно, что питание на клиентское устройство или дисплей от хост-устройства подается по паре проводников с использованием сигналов, обозначенных HOST_Pwr и HOST_Gnd. Часть HOST_Gnd сигнала выполняет функцию базового заземления и обратного тракта или сигнала источника питания для дисплейного устройства. Сигнал HOST_Pwr выполняет функцию питания дисплейного устройства, которое возбуждается хост-устройством. В приведенной в качестве примера конфигурации для маломощных приложений дисплейное устройство может потреблять до 500 мА. Сигнал HOST_Pwr может подаваться от портативных источников питания, таких как, но не только, ионно-литиевая аккумуляторная батарея или батарейный блок, находящаяся в хост-устройстве, причем напряжение этого сигнала может находиться в диапазоне от 3,2 до 4,3 вольт относительно HOST_Gnd.
VII. Временные характеристики
А. Обзор
Этапы и уровни сигналов, используемые клиентом для поддержки обслуживания от хоста и хостом для предоставления указанного обслуживания, показаны на фиг.43. На фиг.43 первая часть иллюстрируемых сигналов показывает пакет отключения линии связи, пересылаемый от хоста, после чего линия данных переводится в состояние логического нуля с использованием высокоимпедансной схемы смещения. Данные не передаются клиентским дисплеем или хостом, если его драйвер заблокирован. В нижней части фиг.43 показан ряд стробирующих импульсов для линии сигналов MDDI_Stb, поскольку MDDI_Stb активизирована в течение пакета отключения линии связи. Как только этот пакет заканчивается и логический уровень переходит в нуль, когда хост переводит схему смещения и логику в нуль, сигнальная линия MDDI_Stb также переводится на уровень логического нуля. На фигуре представлено завершение последней пересылки сигнала или услуги от хоста, которое могло бы появиться в любой момент в прошлом, и приведено, чтобы показать предыдущее прекращение услуги и состояние сигналов перед началом услуги. Если это необходимо, то сигнал может быть послан, например, для установки линии связи в правильное состояние без «известной» предыдущей передачи, предпринятой этим хост-устройством.
Как показано на фиг.43, сигнал, выходящий от клиента, первоначально установлен на уровне логического нуля. Другими словами, выход клиента имеет высокий импеданс и драйвер заблокирован. При запросе услуги клиент выполняет разблокирование своего драйвера и посылает на хост запрос услуги, который осуществляется в период времени, обозначенный tservice, во время которого линия поддерживается на уровне логической единицы. Затем проходит некоторое время, обозначенное thost-detect, возможно, необходимое перед тем, как хост обнаружит запрос, после чего хост отвечает на него, выдавая последовательность запуска линии связи путем приведения сигнала на уровень логической единицы. В этот момент клиент отменяет запрос и блокирует драйвер запроса услуги, так что выходная линия от клиента снова переходит на уровень логического нуля. В течение этого времени сигнал MDDI_Stb находится на уровне логического нуля.
Хост поддерживает выходной сигнал данных хоста на уровне '1' в течение периода, обозначенного trestart-high, после чего хост устанавливает логический уровень в нуль и активизирует MDDI_Stb в течение периода, обозначенного trestart-low, после которого начинается первый прямой трафик с пакета заголовка субкадра, а затем пересылаются пакеты прямого трафика. Сигнал MDDI_Stb активизирован в течение периода
trestart-low и последующего пакета заголовка субкадра.
В таблице VIII показаны временные интервалы для различных периодов, обсужденных выше, а также соотношение для примерных минимальной и максимальной скорости передачи данных, где:
Специалистам в данной области техники очевидно, что функции отдельных элементов, показанных на фиг.41 и 42, хорошо известны, а функция элементов на фиг.42 раскрывается с помощью временной диаграммы на фиг.43. Подробности, касающиеся последовательных оконечных нагрузок и резисторов для режима бездействия, показанных на фиг.42, на фиг.41, опущены, поскольку эта информация не обязательна для описания того, каким образом выполняется кодирование Data-Strobe и восстановление из них тактовых импульсов.
В. Временные соотношения Data-Strobe для прямой линии связи
Характеристики переключения для пересылки данных по прямой линии связи с выхода драйвера хоста показаны в таблице IX. В таблице IX представлены минимальные и максимальные интервалы времени, необходимые для переходов сигналов из состояния в состояние, относительно их типовых значений. Например, типовой интервал времени для перехода, возникающего от начала до конца значения данных (выход, равный '0' или '1'), перехода Data0 в Data0, обозначенного
ttdd-(host-autput), представляет собой Ttbit, в то время как минимальное время составляет порядка Ttbit-0,5 нс, а максимальное время составляет примерно Ttbit+0,5 нс. Относительный промежуток между переходами на линии Data0, другой линии данных (DataХ) и линиях (Stb) стробирующих импульсов показан на фиг.44, где показаны переходы Data0-Strobе, Strobе- Strobе, Strobе-Data0, Data0-не Data0, не Data0-не Data0, не Data0-Strobе и Strobе-не Data0, которые обозначены как
Ttds-(host-output), Ttss-(host-output), Ttsd-(host-output), Ttddx-(host-output), Ttdxdx-(host-output), Ttdxs-(host-output) и
Ttsdx-(host-output) соответственно.
Типовые требования к временным параметрам MDDI для входа клиентского приемника для одинаковых сигналов, пересылающих данные по прямой линии связи, показаны в таблице Х. Поскольку рассматриваются одинаковые сигналы, но с временной задержкой, для иллюстрации характеристик сигналов или значения соответствующих обозначений новый чертеж не потребуется, как очевидно специалистам в данной области техники.
На фиг.45 и 46 показана задержка реакции, которая может появиться, когда хост блокирует или включает драйвер хоста соответственно. В случае когда хост отправляет определенные пакеты, такие как пакет инкапсуляции обратной линии связи или пакет измерения задержки при передаче в прямом и обратном направлениях, хост блокирует драйвер линии, после того как желаемые пакеты направлены, например, пакеты CRC параметра, выравнивания стробирующего сигнала и пакет Все нули, которые на фиг.45 показаны в процессе пересылки. Однако, как показано на фиг.45, не обязательно мгновенно переключать состояние линии из '0' на более высокое значение, хотя это потенциально достижимо с некоторыми имеющимися управляющими или схемными элементами, при этом период времени, затраченный на такое переключение, обозначен как период задержки блокирования драйвера хоста. Хотя теоретически это может произойти мгновенно, так что этот период времени составит 0 наносекунд (нс), его можно расширить до 10 нс как желательного максимума, который появляется в течение периодов прохождения пакета защитный интервал 1 или реверсирование 1.
Обратимся к фиг.46, где показано, что изменение уровня сигнала происходит тогда, когда драйвер хоста разблокирован для пересылки пакета, такого как пакет инкапсуляции обратной линии связи или пакет измерения задержки при передаче в прямом и обратном направлениях. Здесь после периодов пакета защитный интервал 2 или реверсирование 2 драйвер хоста включается и начинает возбуждать уровень, в данном случае '0', значение которого достигается через интервал времени, обозначенный как период задержки включения драйвера хоста, который появляется во время периода повторного включения драйвера перед тем, как будет посылаться первый пакет.
Аналогичный процесс происходит для драйверов и пересылок сигналов для клиентского устройства, здесь это дисплей. Общие рекомендации для длины этих периодов и соответствующие взаимосвязи показаны ниже в таблице XI.
С. Временные соотношения Data-Strobe для обратной линии связи
Характеристики переключения и временные взаимосвязи для сигналов данных и стробирующих сигналов, используемых для пересылки данных по обратной линии связи с выхода драйвера клиента, показаны на фиг.47 и 48. Ниже обсуждаются типовые интервалы для некоторых переходов сигналов из состояния в состояние. На фиг.47 показана взаимосвязь на входе приемника хоста между временными параметрами пересылаемых данных и передним и задним фронтами стробирующих импульсов. То есть то, что называют временем установки для нарастающего или переднего фронта стробирующих сигналов, обозначенного tsu-sr, и временем установки для заднего фронта или среза стробирующих сигналов, обозначенного tsu-sf. Типовой интервал времени для этих периодов установки в минимальном случае составляет примерно 8 наносекунд.
На фиг.48 показаны характеристики переключения и соответствующая задержка выходного сигнала клиента, которая появляется как результат временных соотношений при передаче обратных данных. На фиг.48 показана взаимосвязь между временными параметрами пересылаемых данных и передним и задним фронтами стробирующих импульсов с учетом наведенной задержки. То есть той задержки, которая называется задержкой распространения tpd-sr между нарастающим, или передним фронтом стробирующих сигналов и данными (действительными), и задержки распространения tpd-sf между данными и задним, или спадающим фронтом стробирующих сигналов. Типовой максимальный интервал времени для этих задержек распространения составляет порядка 8 наносекунд.
VII. Реализация управления линией связи (работа контроллера линии связи)
А. Процессор пакетов конечного автомата
Пакеты, пересылаемые по линии связи MDDI, отправляются очень быстро, обычно со скоростью порядка 300 Мбит/с или больше, например 400 Мбит/с, хотя, конечно, допустимы более низкие скорости, если это необходимо. Этот тип шины или скорость пересылки по линии связи слишком велика для серийно выпускаемых в настоящее время микропроцессоров общего назначения или т.п. Следовательно, практическая реализация такой пересылки сигналов заключается в использовании программируемого конечного автомата для анализа потока входных пакетов, чтобы создать пакеты, которые пересылаются или переадресуются в соответствующую аудио-визуальную подсистему, для которой они предназначены. Указанные устройства хорошо известны, и в них используются схемы, предназначенные обычно для ограниченного количества операций, функций или состояний, обеспечивающих работу с требуемой высокой или сверхвысокой скорости.
Контроллеры, процессоры или обрабатывающие элементы общего назначения можно использовать для соответствующих операций действий или манипуляций с некоторой информацией, такой как пакеты управления или состояния, которые имеют более низкие требования по скорости. При приеме таких пакетов (пакеты управления, состояния или другие заранее определенные пакеты) конечный автомат должен провести их через буфер данных или аналогичный обрабатывающий элемент в процессор общего назначения, так чтобы на пакеты можно было воздействовать соответствующим для обеспечения желаемого результата (эффекта), в то время когда аудио- и визуальные пакеты пересылаются соответствующему адресату для воспроизведения. Если в будущем будут производиться микропроцессоры или другие контроллеры, процессоры или обрабатывающие элементы общего назначения с возможностями обработки данных с более высокой скоростью, то тогда состояния или конечный автомат, обсуждаемые ниже, также можно реализовать с использованием программного управления указанными устройствами, обычно в виде программ, хранящихся в элементе памяти или запоминающей среде.
Функция процессора общего назначения в некоторых вариантах может быть реализована путем использования вычислительной мощности или избыточных циклов, доступных для микропроцессоров (CPU) в компьютерных приложениях, или контроллеров, процессоров, процессоров цифровых сигналов (DSP), специализированных схем или ASIC, находящихся в беспроводных устройствах, во многом таким образом, как некоторые модемы или графические процессоры используют вычислительную мощность CPU, находящихся в компьютерах, для выполнения некоторых функций и упрощения аппаратного обеспечения и снижения затрат. Однако это совместное использование циклов может негативно повлиять на скорость обработки, временные соотношения или на общее функционирование указанных элементов, так что во многих приложениях для указанной общей обработки предпочтительно использовать специализированные схемы и элементы.
Для данных изображения, подлежащих выводу на дисплей (микродисплей), или для надежного приема всех пакетов, посланных хост-устройством, обработка дисплейного сигнала синхронизируется с временными соотношениями в канале прямой линии связи. То есть сигналы, поступающие на дисплей, и схемы дисплея в основном должны быть синхронизированы во времени для обеспечения правильной обработки сигналов. Диаграмма состояний высокого уровня, которые обеспечиваются этапами обработки сигналов, или способ, с помощью которого такая синхронизация может быть реализована, представлен на фиг.49. На фиг.49 возможные состояния синхронизации прямой линии связи для конечного автомата 4900 показаны в виде таких категорий, как одно состояние ASINC FRAMES STATE (состояние «асинхронные кадры») 4904, два состояния ACQUIRING SYNC STATES (состояния вхождения в синхронизм) 4902 и 4906 и три состояния IN-SYNC STATES (синхронные состояния) 4908, 4910 и 4912.
Как показано на начальном этапе или состоянии 4902, дисплей или клиент, такой как устройство представления, начинает действовать в предварительно выбранном «несинхронном» состоянии и ищет уникальное слово в первом обнаруженном пакете заголовка субкадра. Следует заметить, что это несинхронное состояние представляет минимальную настройку связи или «аварийную настройку», при которой выбирается интерфейс типа 1. Когда в ходе поиска найдено уникальное слово, дисплей сохраняет поле длины субкадра. При обработке на этом первом кадре или пока не достигнута синхронизация, проверка CRC не выполняется. Если длина этого субкадра равна нулю, то обработка синхронного состояния продолжается в соответствии с состоянием 4904, помеченном здесь как состояние «асинхронные кадры», которое указывает на то, что синхронизация еще не достигнута. На фиг.49 отмечено, что этот этап обработки связан с cond 3, или условием 3. В противном случае, если длина кадра больше нуля, то тогда обработка синхронного кадра переходит в состояние 4906, где состояние интерфейса устанавливается как состояние «найден один синхронный кадр». На фиг.49 отмечено, что этот этап обработки связан с cond 5, или условием 5. Вдобавок, если конечный автомат находит пакет заголовка кадра и определяет положительный результат проверки CRC для длины кадра, большей нуля, то обработка переходит в состояние «найден один синхронный кадр». На фиг.49 это показано как удовлетворение cond 6, или условия 6.
В любой ситуации, когда система находится в состоянии, отличном от «несинхронного», и обнаружено уникальное слово, а также определен положительный результат проверки CRC для пакета заголовка субкадра, причем длина субкадра больше нуля, тогда состояние интерфейса изменяется на «синхронное» состояние 4908. На фиг.49 показано, что этот этап обработки связан с cond 1, или условием 1. С другой стороны, если уникальное слово недействительно или проверка CRC в пакете заголовка субкадра дала отрицательный результат, то тогда обработка синхронного состояния продолжается или происходит возврат к состоянию 4902 «NO SYNC FRAME» (несинхронный кадр). На диаграмме состояний по фиг.49 показано, что этот этап обработки связан с cond 2, или условием 2.
В. Время вхождения в синхронизм
Интерфейс может быть сконфигурирован так, чтобы допускать некоторое количество «ошибок синхронизации», прежде чем принять решение о том, что синхронизация потеряна, и вернуться в состояние «NO SYNC FRAME». На фиг.49, как только конечный автомат достиг состояния «IN-SYNC STATE» и ошибки не обнаружены, он непрерывно находится под воздействием cond 1 и остается в состоянии «IN-SYNC STATE». Однако, как только обнаружен один результат действия cond 2, состояние обработки изменяется на состояние 4910 «одна ошибка синхронизации». В этот момент, если обработка приводит к обнаружению выполнения еще одного условия cond 1, то тогда конечный автомат возвращается в «синхронное» состояние, в противном случае он обнаруживает выполнение другого условия cond 2 и переходит в состояние 4912 «две ошибки синхронизации». Опять же, если появляется cond 1, то обработка возвращает конечный автомат в «синхронное» состояние. В противном случае обнаруживается другое условие cond 2 и конечный автомат возвращается в «несинхронное» состояние. Также понятно, что необходимо, чтобы интерфейс обнаружил пакет отключения линии связи, что заставит линию связи прекратить пересылку данных и вернуться в состояние «несинхронный кадр», когда не с чем выполнять синхронизацию, что определено как выполнение cond 4, или условия 4, в диаграмме состояний на фиг.49.
Понятно, что существует вероятность наличия повторяющейся «фальшивой копии» уникального слова, которая может появляться в каком-то фиксированном месте в субкадре. В этом случае весьма маловероятно, что конечный автомат синхронизируется по этому субкадру, поскольку CRC в этом пакете заголовка субкадра также должна быть действительной при обработке, чтобы обработка MDDI продолжалась в «синхронном» состоянии.
Длина субкадра в пакете заголовка субкадра может быть установлена в нуль для указания о том, что хост передаст только один субкадр перед отключением линии связи, и интерфейс MDDI устанавливается или конфигурируется в незанятом состоянии (бездействие). В этом случае дисплей должен немедленно принять пакеты по прямой линии связи после обнаружения пакета заголовка субкадра, поскольку перед переходом линии связи в незанятое состояние послан только один субкадр. При нормальных или типовых операциях длина субкадра не равна нулю, а дисплей обрабатывает только пакеты прямой линии связи, в то время как интерфейс находится в состояниях, показанных вместе в виде «синхронных» состояний на фиг.49.
Время, необходимое дисплею для синхронизации по сигналу прямой линии связи, является переменной величиной, зависящей от размера субкадра и скорости передачи данных по прямой линии связи. Вероятность обнаружения «фальшивой копии» уникального слова как части, состоящей из случайных или более случайных данных в прямой линии связи, тем больше, чем больше размер субкадра. В то же время возможности восстановления исходя из фальшивого обнаружения меньше, а время, необходимое для этого, будет больше при меньшей скорости передачи данных по прямой линии связи.
С. Инициализация
Как было установлено выше, во время «запуска» хост конфигурирует прямую линию связи для работы с минимальной требуемой или желаемой скоростью передачи данных, равной 1 Мбит/с, или с меньшей скоростью и конфигурирует длину субкадра и частоту медийных кадров в соответствии с данным приложением. То есть и прямая, и обратная линии связи начинают работу, используя интерфейс типа 1. Эти параметры обычно будут использоваться временно, в то время когда хост определяет возможности или желаемую конфигурацию для клиентского дисплея (или клиентского устройства другого типа). Хост пересылает пакет заголовка субкадра по прямой линии связи, за которым следует пакет инкапсуляции обратной линии связи, имеющий бит '0' флагов запроса, установленный в значение единица (1) для выполнения запроса дисплею или клиенту, с тем чтобы тот отреагировал, прислав пакет возможностей дисплея. Как только дисплей входит в синхронизм с прямой линией связи, он посылает пакет возможностей дисплея и пакет запроса и состояния дисплея по обратной линии или каналу связи. Хост анализирует контент пакета возможностей дисплея, чтобы определить, каким образом реконфигурировать линию связи для обеспечения оптимального или желаемого уровня эффективности.
Хост анализирует поля версии протокола и минимальной версии протокола для подтверждения того, что хост и дисплей используют версии протокола, совместимые друг с другом. Эти версии протокола обычно остаются в качестве первых двух параметров пакета возможностей дисплея, так что совместимость можно определить даже тогда, когда другие элементы протокола, возможно, не совместимы или нет полной ясности по поводу их совместимости.
D. Обработка CRC
Для всех типов пакетов конечный автомат процессора пакетов обеспечивает соответствующее или правильное управление блоком проверки CRC. Он также увеличивает значение счетчика ошибок CRC, когда анализ CRC приводит к обнаружению одной или нескольких ошибок, и сбрасывает счетчик CRC в начале каждого обрабатываемого субкадра.
Е. Альтернативная проверка потери синхронизации
Хотя вышеописанная последовательность этапов или состояний обеспечивает более высокоскоростные передачи данных или более высокую пропускную способность, заявители обнаружили, что альтернативная компоновка или изменение условий, которые использует клиент для сообщения о том, что произошла потеря синхронизации с хостом, могут быть эффективно использованы для достижения еще более высокоскоростной передачи данных или пропускной способности. Новый вариант изобретения имеет ту же базовую структуру, но с измененными условиями для изменения состояний. Вдобавок реализован новый счетчик, способствующий выполнению проверок синхронизации субкадров. Эти этапы и условия представлены на фиг.63, которая иллюстрирует ряд состояний и условий, полезных при установке операций способа или конечного автомата. Для ясности здесь показаны только две части: «состояния вхождения в синхронизм» и «синхронные состояния». Вдобавок поскольку результирующие состояния по существу те же, что и состояния самого конечного автомата, для них использована одинаковая нумерация. Однако условия для изменения состояний (и работы конечного автомата) несколько изменяются, так что для ясности они перенумерованы (1, 2, 3, 4, 5 и 6 на 61, 62, 63, 64 и 65), что удобно при определении различий. Поскольку состояние «асинхронный кадр» в данном обсуждении не рассматривается, на этой фигуре одно состояние (4904) и условие (6) больше не используются.
На фиг.63 система или клиент (для отображения или представления) запускают конечный автомат 5000 с предварительно выбранного «несинхронного» состояния 4902, показанного на фиг.49. Первое изменение состояния при переходе из несинхронного состояния 4902 происходит при условии 64, которое представляет собой обнаружение синхронизирующей комбинации. Если предположить, что CRC заголовка субкадра также проходит в этом пакете (удовлетворяется условие 61), то состояние конечного автомата процессора пакетов может измениться на синхронное состояние 4908. Ошибка синхронизации (условие 62) заставит конечный автомат перейти в состояние 4910, а второе ее появление - в состояние 4912. Однако было обнаружено, что любой отрицательный результат проверки CRC пакета MDDI заставит конечный автомат выйти из синхронного состояния 4908 и перейти в состояние 4910 «одна ошибка синхронизации». Еще один отрицательный результат проверки CRC пакета MDDI вызовет переход в состояние 4912 «две ошибки синхронизации». Пакет, декодированный с правильным значением CRC, вызовет возврат конечного автомата в синхронное состояние 4908.
Происшедшее изменение необходимо для использования значения CRC или определения для «каждого пакета», то есть чтобы конечный автомат просматривал значение CRC для каждого пакета с целью определения потери синхронизации вместо простого просмотра пакетов заголовка субкадра. В этой конфигурации или процессе потеря синхронизации не определяются с использованием уникального слова, а только по значениям CRC заголовка субкадра.
Эта новая реализация интерфейса позволяет линии связи интерфейса MDDI выявлять отказы синхронизации гораздо быстрее и, следовательно, гораздо быстрее восстанавливать синхронизацию.
Чтобы сделать эту систему более надежной, клиент должен также предусмотреть или использовать счетчик субкадров. Тогда клиент проверяет наличие уникального слова во время, когда ожидается его появление в сигнале. Если уникальное слово не появилось в нужный момент времени, клиент может констатировать, что произошел отказ синхронизации, гораздо быстрее, чем если бы пришлось ждать в течение нескольких (здесь трех) интервалов или периодов прохождения пакета, которые в сумме были бы больше, чем длина субкадра. Если проверка уникального слова показывает, что оно отсутствует, другими словами, что временные соотношения неправильные, то тогда клиент может немедленно заявить о потере синхронизации линии связи и перейти в несинхронное состояние. Процесс проверки наличия правильного уникального слова добавляет состояние 65 (cond 65) для конечного автомата, говорящее о том, что уникальное слово является неправильным. Если клиент ожидает приема пакета субкадра и его не дождался, он может немедленно перейти в несинхронное состояние 4902, экономя дополнительное время на ожидание множества ошибок синхронизации (условие 62), что обычно происходит через состояния 4910 и 4912.
В этом измененном варианте используется дополнительный счетчик или функция отсчета в ядре клиента для отсчета длины субкадра. В одном варианте используется функция обратного счета и пересылка любого пакета, который был правильно обработан, прерывается, чтобы проверить уникальное слово субкадра, если время отсчета счетчика истекло. В альтернативном варианте счетчик может вести отсчет в прямом направлении, причем значение счетчика сравнивается с заданным максимальным или конкретным значением, и в этот момент проверяется текущий пакет. Этот процесс защищает клиента от декодирования тех пакетов, которые были приняты им неправильно (пакеты имели недопустимую длину). Если счетчик длины субкадра должен прерывать какой-то другой пакет, который декодировался, может быть определена потеря синхронизации, поскольку ни один пакет не должен пересекать границу субкадра.
IX. Обработка пакета
Для каждого обсужденного выше типа пакета, который принимается конечным автоматом, конечный автомат выполняет конкретный этап или ряд этапов обработки для реализации операции интерфейса. Пакеты прямой линии связи обычно обрабатываются согласно приведенному в качестве примера процессу обработки, который показан ниже в таблице XII.
X. Уменьшение скорости передачи данных в обратной линии связи
Заявитель обнаружил, что некоторые параметры для контроллера линии связи хоста можно определенным образом отрегулировать или сконфигурировать, чтобы обеспечить максимальную или более оптимальную (масштабированную) скорость передачи данных обратной линии связи, что весьма желательно. Например, в течение времени, используемого для пересылки обратных пакетов данных в пакете инкапсуляции обратной линии связи, пара сигналов 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, для указанного эффекта «передачи в прямом и обратном направлении» или установки событий, подлежащих завершению, что приводит к нежелательному расходу времени или циклов. Чтобы не сталкиваться с этой проблемой, делитель обратной скорости позволяет в течение времени одного бита в обратной линии связи отмерить множество периодов сигнала MDDI_Stb. Это означает, что скорость передачи данных по обратной линии связи меньше, чем скорость по прямой линии связи.
Следует заметить, что действительная длительность задержек сигнала через интерфейс может отличаться в зависимости от каждой конкретной системы хост-клиент или используемого аппаратного обеспечения. Хотя это не требуется, каждая система может быть улучшена путем использования пакета измерения задержки на передачу в прямом и обратном направлениях для измерения действительной задержки в системе, так что делитель обратной скорости может быть установлен с оптимальным значением.
Задержка на передачу в прямом и обратном направлениях измеряется путем посылки хостом на дисплей пакета измерения задержки на передачу в прямом и обратном направлениях. Дисплей реагирует на этот пакет, посылая последовательность единиц обратно на хост, или во время предварительно выбранного окна измерения в этом пакете, названного полем периода измерения. Подробные временные соотношения для этого измерения были описаны ранее. Задержка на передачу в прямом и обратном направлениях используется для определения частоты, с которой могут надежно отбираться данные обратной линии связи.
Измерение задержки на передачу в прямом и обратном направлениях состоит из определения, обнаружения или подсчета количества тактовых интервалов данных в прямой линии связи, появляющихся между началом поля периода измерения и началом периода, когда от клиента в хосте принимается ответная последовательность 0хff, 0xff, 0x00. Заметим, что ответ от клиента возможно может быть принят на небольшом фрагменте тактового периода прямой линии связи перед тем, как увеличится отсчет измерения. Если для вычисления делителя обратной скорости используется это немодифицированное значение, то возможно появление битовых ошибок в обратной линии связи из-за ненадежной выборки данных. Пример этой ситуации показан на фиг.51, где в графической форме показаны сигналы, представляющие MDDI_Data в хосте, MDDI_Stb в хосте, тактовые импульсы данных прямой линии связи в хосте и отсчет задержки. На фиг.51 ответная последовательность была принята от дисплея на фрагменте тактового периода прямой линии связи, перед тем как отсчет задержки увеличился с 6 до 7. Если предположить, что задержка равна 6, то тогда хост отбирает обратные данные сразу после битового перехода или, возможно, в середине битового перехода. Это может привести к ошибочной выборке в хосте. По этой причине измененную задержку, как правило, следует увеличить на единицу, прежде чем использовать ее для вычисления делителя обратной скорости.
Делитель обратной скорости представляет собой количество периодов MDDI_Stb, на протяжении которых хост должен ждать перед выборкой данных обратной линии связи. Поскольку периодический сигнал MDDI_Stb имеет частоту, составляющую половину частоты прямой линии связи, скорректированное измерение задержки на передачу в прямом и обратном направлениях необходимо разделить на 2, а затем округлить до следующего целого числа. Это соотношение выражается формулой:
Для данного примера это составит:
Если измерение задержки на передачу в прямом и обратном направлениях, использованное в этом примере, дало бы значение 7, а не 6, то делитель обратной скорости был бы равен 4.
Данные обратной линии связи отбираются хостом по переднему фронту тактовых импульсов обратной линии связи. Для генерации тактовых импульсов обратной линии связи имеются счетчики или аналогичная схема или устройство, имеющиеся как в хосте, так и клиенте (дисплей). Счетчики инициализируются так, что первый передний фронт тактового импульса обратной линии связи появляется в начале первого бита в поле пакетов обратной линии связи в пакете инкапсуляции обратной линии связи. Для примера, приведенного ниже, это показано на фиг.52. Счетчики увеличивают на единицу свое значение с каждым передним фронтом сигнала MDDI_Stb, а количество отсчетов, появляющихся пока не произошел циклический возврат, устанавливается параметром делителя обратной скорости в пакете инкапсуляции обратной линии связи. Поскольку сигнал MDDI_Stb переключается с половинной скоростью обратной линии связи, то скорость обратной линии связи составляет половину скорости прямой линии связи, деленной на делитель обратной скорости. Например, если скорость прямой линии связи составляет 200 Мбит/с, а делитель обратной скорости равен 4, то тогда скорость передачи данных по обратной линии связи выражается как:
Пример, демонстрирующий временные соотношения между линиями сигналов MDDI_Data0 и MDDI_Stb в пакете инкапсуляции обратной линии связи, показан на фиг.52, где параметры пакета, используемые для иллюстрации, имеют следующие значения:
0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, 0xdb, 0x00, …
Первый пакет обратной линии связи, возвращенный от дисплея, является дисплейным пакетом запроса и состояния, имеющим длину пакета, равную 7, и тип пакета, равный 70. Этот пакет начинается с байтовых значений 0x07, 0x00, 0x46, … и т.д. Однако на фиг.52 можно видеть только первый байт (0x07). Этот первый пакет обратной линии связи сдвинут на фигуре во времени почти на один тактовый период обратной линии связи, чтобы показать действительную задержку в обратной линии связи. Идеальная форма сигнала с нулевой задержкой для передачи в обоих направлениях от хоста к дисплею показана пунктирной линией.
Старший значащий байт поля CRC параметра пересылается с предшествующим типом пакета, а затем следует поле все нули. Стробирующий сигнал от хоста переключается с единицы на ноль и обратно в единицу, когда данные от хоста изменяют свой уровень, формируя более широкие импульсы. Когда данные переходят в ноль, стробирующие импульсы переключаются с более высокой частотой, и только изменение данных в линии данных вызывает изменение в конце поля выравнивания. Стробирующие импульсы переключаются с более высокой частотой в оставшейся части фигуры благодаря фиксированным уровням (0 или 1) сигнала данных для расширенных периодов времени и переходов, попадающих на данную комбинацию импульсов (край).
Тактовые импульсы обратной линии связи находятся на нуле до периода реверсирование 1, когда запускаются тактовые импульсы для обеспечения пакетов обратной линии связи. Стрелки в нижней части фигуры указывают на моменты отбора данных, как будет ясно из дальнейшей части обсуждения. Здесь показано, что первый байт пересылаемого поля пакета (здесь 11000000) начинается после периода реверсирование 1, а уровень линии стабилизируется из-за блокировки драйвера хоста. Задержка прохождения первого бита (и, как это видно для бита три) показана на линии для сигнала данных пунктиром.
На фиг.53 показаны типовые значения делителя обратной скорости в зависимости от скорости передачи данных по прямой линии связи. Действительный делитель обратной скорости определяется в результате измерения при передаче в прямом и обратном направлениях, чтобы гарантировать правильную работу обратной линии связи. Первая область 5302 соответствует зоне безопасной работы, вторая область 5304 соответствует зоне предельных характеристик, в то время как третья область 5306 указывает настройки, которые вряд ли обеспечат правильное функционирование.
Измерение задержки при передаче в прямом и обратном направлениях и установка делителя обратной скорости выполняются так же, как при работе с любой из настроек типа интерфейса в прямой или обратной линии связи, поскольку они выражены и действуют в единицах действительных тактовых периодов, а не в количествах передаваемых или принимаемых бит.
ХI. Интервалы реверсирования и защитные интервалы
Как обсуждалось ранее, поле реверсирование 1 в пакете инкапсуляции обратной линии связи и поле защитный интервал 1 в пакете измерения задержки на передачу в прямом и обратном направлениях определяют значения для интервалов времени, позволяющих блокировку драйверов интерфейса хоста до разблокирования драйверов интерфейса дисплея. Поля реверсирование 2 и защитный интервал 2 обеспечивают значения времени, позволяющие блокирование драйверов дисплея до разблокирования драйверов хоста. Поля защитный интервал 1 и защитный интервал 2 обычно заполнены предварительно установленными или предварительно выбранными значениями для интервалов, на которых регулировка не предполагается. В зависимости от используемого аппаратного обеспечения интерфейса эти значения могут быть получены с использованием эмпирических данных и в некоторых случаях могут регулироваться для улучшения функционирования.
Некоторые факторы способствуют определению длины поля реверсирование 1, причем к ним относятся скорость передачи данных по прямой линии связи и максимальное время блокировки драйверов MDDI в хосте. Максимальное время блокировки драйверов хоста задано в таблице XI, где показано, что драйверам требуется максимум 10 нс для блокировки и около 2 нс для разблокирования. Минимальное количество тактовых импульсов прямой линии связи, необходимых для блокирования драйвера хоста, выражается следующим соотношением:
Допустимый диапазон значений для поля реверсирование 1 выражается согласно следующему соотношению:
где коэффициент типа интерфейса равен 1 для типа 1, 2 - для типа 2, 4 - для типа 3 и 8 - для типа IV.
Комбинирование вышеуказанных двух уравнений показывает, что член, относящийся к коэффициенту типа интерфейса, сокращается, и реверсирование 1 определяется как:
Например, прямая линия связи типа 3 со скоростью 1500 Мбит/с использует задержку реверсирования 1:
Так как задержка при передаче в прямом и обратном направлениях возрастает, увеличивается запас времени с момента, когда хост заблокирован, до момента времени, когда хост разблокирован.
Факторами, которые определяют интервал времени, обычно используемый для реверсирования 2, являются скорость передачи данных по прямой линии связи, максимальное время блокировки драйверов MDDI_Data0 в дисплее и задержка при передаче в прямом и обратном направлениях в линии связи. Вычисление времени, необходимого для блокирования драйвера дисплея, по существу выполняется так же, как и для драйвера хоста, обсужденного выше, и определяется согласно соотношению:
,
а диапазон допустимых значений для поля реверсирование 2 выражается в виде:
Например, прямая линия связи типа 3 со скоростью 1500 Мбит/с при задержке при передаче в прямом и обратном направлениях 10 тактовых импульсов прямой линии связи обычно использует задержку для реверсирование 2 порядка:
XII. Альтернативные временные соотношения для обратной линии связи
Хотя использование временных соотношений и защитных интервалов, обсужденных выше, способствует созданию интерфейса с высокоскоростной пересылкой данных, заявители разработали способ, позволяющий изменять значения длины бит, которые короче времени передачи в прямом и обратном направлениях, путем изменения процедуры отыскания временных соотношений для обратной линии связи.
Как было представлено выше, предыдущий подход к временным соотношениям в обратной линии связи основан на том, что количество тактовых импульсов отсчитывается с последнего бита защитного интервала 1 обратного хронирующего пакета, пока не будет отобран первый бит по переднему фронту тактового импульса ввода-вывода (IO). Это является тактовым сигналом (сигналами), используемым для распределения во времени входных и выходных сигналов для интерфейса MDDI. Тогда вычисление делителя обратной скорости задается уравнением:
Это обеспечивает ширину бита, равную задержке при передаче в прямом и обратном направлениях, что обеспечивает в результате очень надежную обратную линию связи. Однако было показано, что обратная линия связи способна работать быстрее, или с более высокоскоростной пересылкой, а именно этого заявители и хотели добиться в качестве преимущества. Новый способ, предложенный в изобретении, позволяет использовать дополнительные возможности интерфейса для достижения более высоких скоростей.
Это достигается благодаря тому, что хост подсчитывает количество тактовых импульсов, пока один не будет отобран, но при этом производит выборку в линии данных как по переднему, так и заднему фронтам во время обратного хронирующего пакета. Это позволяет хосту поймать самый пригодный или оптимальный момент выборки в обратном бите, обеспечивая его стабильность, то есть находит самый пригодный или оптимальный передний фронт для выборки данных для пакетов инкапсуляции обратного трафика. Оптимальная точка выборки зависит как от делителя обратной линии, так и от того, был ли обнаружен первый бит по переднему фронту или по заднему фронту. Новый способ установки временных соотношений позволяет хосту сразу найти первый фронт комбинации 0xFF0xFF0x00, посланной клиентом для установки временных соотношений для обратной линии связи, чтобы определить, где делать выборку в пакете инкапсуляции обратной линии связи.
Примеры поступления обратного бита и того, как для этого бита подбираются различные делители обратной скорости, показаны на фиг.64, где наряду с этим показано несколько тактовых периодов, которые появились с момента последнего бита защитного интервала 1. На фиг.64 показано, что, если первый фронт появляется между передним и задним фронтом (обозначены как передний/задний), оптимальным моментом выборки для делителя обратной скорости, равного единице, является фронт тактового периода, обозначенный как 'b', то есть единственный передний фронт, появляющийся в периоде обратного бита. Для делителя обратной скорости, равного двум, оптимальным моментом выборки все еще вероятно является передний фронт 'b' тактового импульса, так как конец периода 'c' ближе к концу бита, чем 'b'. Для делителя обратной скорости, равного четырем, оптимальным моментом выборки вероятней всего будет конец 'd' тактового импульса, так как он ближе к заднему краю обратного бита, где его значение, скорее всего, стабилизировалось.
Обратимся к фиг.64, где, если первый фронт тем не менее появляется между передним и задним фронтом (отмеченными как задний/передний), возможная точка выборки для делителя обратной скорости, равного единице, является фронт 'a' тактового периода, поскольку это единственный передний фронт в периоде обратного бита. Для делителя обратной скорости, равного двум, возможной точкой выборки является фронт 'b', а для делителя обратной скорости, равного четырем, оптимальной точкой выборки является фронт 'c'.
Из фигуры видно, что с ростом значения делителя обратной скорости оптимальную точку выборки устанавливать или выбирать становится все легче, так как она должна представлять собой передний фронт, ближайший к середине.
Хост может использовать этот способ нахождения передних тактовых фронтов перед просмотром переднего фронта пакетных данных по линии данных. Затем он на основе того, появился ли фронт между передним и задним фронтом или между задним и передним фронтом, и на основе значения делителя обратной скорости может решить, сколько дополнительных тактовых периодов надо добавить к значению счетчика, чтобы всегда выбирался тот бит, который ближе всего к середине.
Как только хост выбрал или определил количество тактовых периодов, он может проанализировать различные значения делителя обратной скорости с клиентом, чтобы определить, подойдет ли то или иное конкретное значение делителя обратной скорости. Хост (и клиент) может начать с делителя, равного единице, и проверить CRC обратного пакета состояния, принятого от клиента, чтобы определить, подходит ли эта обратная скорость для пересылки данных. Если проверка CRC дает отрицательный результат, то вероятно наличие ошибки выборки и хост может увеличить значение делителя обратной скорости и вновь попытаться запросить пакет состояния. Если второй запрошенный пакет также окажется с нарушением, то значение делителя вновь может быть увеличено и запрос выполняется снова. Если пакет декодирован правильно, то это значение делителя обратной скорости можно использовать для всех будущих обратных пакетов.
Этот способ эффективен и полезен, поскольку временные соотношения для обратной передачи не должны зависеть от оценки начальных временных параметров при передаче в прямом и обратном направлении. Если прямая линия связи стабильна, клиент должен продолжать декодировать пакеты прямой линии связи, даже если имеются отказы в обратной линии связи. Конечно, хост все еще отвечает за установку делителя обратной линии связи для линии связи, поскольку этот способ не гарантирует совершенную обратную линию связи. Вдобавок значение упомянутого делителя будет зависеть в основном от качества тактовых импульсов, которые используются для создания тактовых импульсов ввода-вывода (IO). Если эти тактовые импульсы имеют значительное дрожание фазы, существует большая вероятность ошибки выборки. Вероятность этой ошибки возрастает с числом тактовых импульсов в задержке при передаче в прямом и обратном направлениях.
Этот вариант реализации лучше всего подходит для обратных данных типа 1, но может вызвать проблемы для обратных данных типа 2, 3 или 4 из-за асимметрии между линиями данных, которая потенциально может быть слишком большой для работы линии связи со скоростью, которая является оптимальной только для одной пары данных. Однако согласно предыдущему способу скорость передачи данных, возможно, уменьшать не придется даже в случае данных типа 2, 3 или 4. Этот способ также может оказаться оптимальным при его повторении по каждой линии данных для выбора идеальной или оптимальной точки выборки тактового импульса. Если для каждой пары данных выборка происходит в одно и то же время, этот способ продолжает работать. Если это происходит в разные периоды выборки, то можно использовать два различных подхода. Первый состоит в выборе желаемого или более оптимального места выборки для каждой точки данных, даже если оно не одно и то же для каждой пары данных. Затем хост может восстановить поток данных после выборки всех битов из набора пар данных: два бита для типа 2, четыре бита для типа 3 и восемь бит для типа IV. Другой возможный вариант для хоста - увеличить значение делителя обратной скорости, так что биты данных для каждой пары данных могут выбираться по одному и тому же фронту тактового импульса.
XIII. Эффекты задержки и асимметрии линии связи
Асимметрия задержки по прямой линии связи между парами MDDI_Data и MDDI_Stb может ограничить максимально возможную скорость передачи данных, если не использовать компенсацию асимметрии задержки. Различия в задержке, которые вызывают асимметрию временных соотношений, появляются из-за логических схем контроллера, драйверов и приемников линии, а также кабелей и разъемов, как подчеркнуто ниже.
А. Анализ временных соотношений линии связи ограничено асимметрией (MDDI типа 1)
1. Пример задержки и асимметрии линии связи типа 1
Типовая схема интерфейса, аналогичная показанной на фиг.41, представлена на фиг.57 и предназначена для обеспечения линии связи интерфейса типа 1. На фиг.57 показаны примерные или типовые значения для задержки распространения и асимметрии для каждой из нескольких стадий обработки или сопряжения для прямой линии связи MDDI типа 1. Асимметрия в задержке между MDDI_Stb и MDDI_Data0 вызывает искажение рабочего периода выходного тактового импульса. Данные на входе D-триггерной части (RXFF) приемника, использующей триггеры 5728, 5732, должны слегка измениться после фронта тактового импульса, так чтобы можно было реализовать надежную выборку. На фигуре показаны две каскадно включенные линии 5732а и 5732b задержки, используемые для решения двух разных проблем при формировании этих временных соотношений. При действительной реализации они могут быть объединены в единый элемент задержки.
Данные, Stb и временные соотношения при восстановлении тактовых импульсов на линии связи типа 1 для примерного процесса обработки сигналов через интерфейс показаны на фиг.58.
Общая асимметрия задержки, которая является значительной, появляется или складывается в виде суммарной асимметрии в следующих ступенях: триггерная ступень (TXFF) передатчика с триггерами 5704, 5706; драйвер (TXDRVR) передатчика с драйверами 5708, 5710; кабель 5702; приемник (RXRCVR) приемной линии с приемниками 5722, 5724; и логическая схема XOR (RXXOR) приемника. Задержка 1 5732а должна совпадать или превосходить задержку логического элемента XOR 5736 в ступени RXXOR, которая определяется соотношением:
Желательно, чтобы это требование удовлетворялось, с тем чтобы входной сигнал D триггеров 5728, 5732 приемника не изменялся до прихода тактового импульса. Это действительно, если время удержания триггерной схемы RXFF равно нулю.
Назначением или функцией задержки 2 является компенсация времени удержания триггерной схемы RXFF согласно соотношению:
Во многих системах эта величина будет равна нулю, поскольку время удержания равно нулю, и в этом случае максимальное значение для задержки 2, конечно, также будет равно нулю.
Наихудший вариант с точки зрения асимметрии в ступени XOR приемника будет в случае прихода данных позже стробирующего импульса, когда задержка 1 имеет максимальное значение и тактовый импульс, выходящий из логического элемента XOR, приходит раньше всего согласно соотношению:
В этой ситуации изменение в данных может произойти между двумя битовыми периодами n и n+1, очень близко к тому моменту, когда триггер приемника запускает бит n+1.
Максимальная скорость передачи данных (минимальный битовый период) линии связи MDDI типа 1 является функцией максимальной асимметрии, возникающей при прохождении через все драйверы, кабель и приемники в линии связи MDDI плюс общая установка данных в ступени RXFF. Общая асимметрия задержки в линии связи вплоть до выходного сигнала в ступени RXRCVR может быть выражена как:
а минимальный битовый период задается выражением:
В примере, показанном на фиг.57, 
а минимальный битовый период может быть выражен как:
или установлен в соответствии со скоростью, примерно равной 416 Мбит/с.
B. Анализ временных соотношений в линии связи для 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) триггеров B приемника, состоящей из триггеров 5928 и 5930, изменяются после фронта тактового импульса незначительно, так что их можно надежно отбирать. Если MDDI_Data1 поступают раньше, чем MDDI_Stb или MDDI_Data0, то тогда MDDI_Data1 должны быть задержаны для выборки по меньшей мере на величину асимметрии задержки. Для выполнения этого данные задерживаются с использованием линии задержки задержка 3. Если MDDI_Data1 поступают позднее, чем MDDI_Stb и MDDI_Data0 и также задерживаются линией задержки задержка 3, то тогда точка изменений MDDI_Data1 перемещается ближе к следующему фронту тактового импульса. Этот процесс определяет верхнюю границу скорости передачи данных для линии связи MDDI типа 2, 3 или 4. На фиг.60А, 60В и 60С показаны в качестве примера различные варианты для временных соотношений или асимметрии для двух сигналов данных и MDDI_Stb друг относительно друга.
Для надежной выборки данных в RXFFB, когда MDDI_DataХ поступают как можно раньше, значение задержки 3 устанавливается согласно соотношению:
Максимальная скорость в линии связи определяется минимально допустимым битовым периодом. Эта зависимость максимально проявляется, когда MDDI_DataХ поступают как можно позже. В этом случае минимально допустимое время периода задается как:
Тогда верхняя граница скорости в линии связи составит:
в предположении, что:
В приведенном выше примере нижняя граница минимального битового периода задается соотношением:
что составляет примерно 208 Мбит/с.
Это гораздо медленнее, чем максимальная скорость передачи данных, которую можно использовать с линией связи типа 1. Возможность автоматической компенсации асимметрии задержки у интерфейса MDDI значительно уменьшает влияние асимметрии задержки на максимальную скорость передачи по линии связи.
XIV. Описание межкомпонентных соединений на физическом уровне
Физические соединения, пригодные для реализации интерфейса согласно настоящему изобретению, можно реализовать, используя такие компоненты, как компонента под номером 3260-8S2(01), производимая Hirose Electric Company Ltd, - на стороне хоста и компоненту под номером 3240-8P-C, производимую Hirose Electric Company Ltd, - на стороне дисплейного устройства. Пример распределения штырей или «схемы расположения выводов» интерфейса для указанных разъемов, используемых с интерфейсами типа 1/типа 2, показан в таблице XII и на фиг.61.
Экран подсоединен к HOST_Gnd в интерфейсе хоста, а разрядный провод экрана в кабеле соединен с экраном разъема дисплея. Однако экран и разрядный провод не подсоединены к заземлению схемы внутри дисплея.
Элементы или устройства для межкомпонентных соединений выбираются или разрабатываются достаточно малогабаритными, чтобы их можно было использовать с мобильными коммутационными и вычислительными устройствами, такими как PDA и беспроводные телефоны или портативные игровые устройства, и чтобы они имели эстетичный вид с учетом размеров самого устройства. Разъемы и кабели должны быть относительно недорогими и рассчитаны на достаточно длительное использование в типовом пользовательском оборудовании, а также иметь небольшие размеры, особенно если речь идет о кабелях. Элементы пересылки должны обеспечивать пересылку данных и стробирующих сигналов являющимися дифференциальными данными NRZ, которые имеют скорость пересылки вплоть до 450 Мбит/с для типа 1 и типа 2 и до 3,6 Гбит/с для 8-битовой параллельной версии типа 4.
Для приложений, работающих во внутреннем режиме, ни разъемы, ни соответствующие им проводники не используются, а если используются, то в сверхминиатюрном исполнении. Одним из примеров этого являются «гнезда» с нулевым усилием вставки для размещения интегральных схем или элементов, размещаемых в хосте или клиентском устройстве. Другим примером является случай, когда хост и клиент находятся на печатных платах с различными соединительными проводниками между ними и имеют «штыри» или контакты, выступающие из корпусов, которые припаяны к контактам на проводниках для соединения между собой интегральных схем.
XV. Функционирование
Описание общих этапов, предпринимаемых при обработке данных и пакетов во время работы интерфейса с использованием вариантов осуществления изобретения, представлено на фиг.54А и 54В вместе с обзором устройства интерфейса, обрабатывающего пакеты, на фиг.55. На этих фигурах процесс начинается на этапе 5402 с определения того, соединены ли клиент и хост с использованием канала связи (здесь это кабель). Этот этап может выполняться путем периодического опроса хостом с использованием программного или аппаратного обеспечения, которое обнаруживает наличие разъемов или кабелей либо сигналов на входах в хост (например, как здесь показано для интерфейсов USB), или других известных способов. Если соединение клиента с хостом отсутствует, тогда клиент может просто перейти в состояние ожидания в течение предварительно определенного интервала в зависимости от приложения, перейти в режим бездействия или оставаться неактивизированным, ожидая будущее использование, которое может потребоваться пользователю, чтобы предпринять некоторое действие для повторной активизации хоста. Например, когда хост находится в компьютерном устройстве, пользователь может щелкнуть по пиктограмме на экране или запросить программу, которая активизирует операции хоста по поиску клиента. Опять же обработка, выполняемая хостом, может быть активизирована простым включением соединения типа USB в зависимости от возможностей и конфигурации хоста или резидентного программного обеспечения хоста.
Как только клиент подсоединился к хосту или наоборот, либо обнаружено наличие такого соединения, клиент или хост на этапах 5404 и 5406 посылает соответствующие пакеты, запрашивающие обслуживание. Клиент на этапе 5404 может послать пакеты запроса обслуживания или состояния дисплея. Заметим, что, как обсуждалось выше, линия связи могла быть ранее отключена или находится в режиме бездействия, так что это может не привести к полной инициализации линии связи, которая произойдет позже. Как только линия связи синхронизируется и хост попытается связаться с клиентом, клиент на этапе 5408 передаст хосту пакет возможностей дисплея. Теперь хост может начать определение типа поддержки, включая скорости пересылки, которые клиент может обеспечить.
Обычно хост и клиент на этапе 5410 также согласовывают тип (частота/скорость) используемого режима обслуживания, например тип 1, тип 2 и т.д. Как только установлен тип обслуживания, хост может начать пересылку информации. Вдобавок хост для оптимизации временных соотношений в линиях связи параллельно с другой обработкой сигналов может использовать пакеты измерения задержки при передаче в прямом и обратном направлениях, как показано на этапе 5411.
Как было установлено ранее, все пересылки начинаются с пакета заголовка субкадра, показанного в состоянии передачи на этапе 5412, после чего следует тип данных, здесь это пакеты видео- и аудиопотока, и пакеты заполнителя, передаваемые на этапе 5414. Аудио- и видеоданные предварительно подготовлены или преобразованы в пакеты, а пакеты заполнителя вводятся, когда это необходимо или желательно для заполнения требуемого количества бит для медийных кадров. Хост может посылать на активные звуковые устройства такие пакеты, как пакеты разблокирования прямого аудиоканала. Вдобавок хост может пересылать команды и информацию, используя другие типы пакетов, обсужденные выше, причем здесь на этапе 5416 показана пересылка пакетов цветовой карты, пересылки битовых блоков или других пакетов. Кроме того, хост и клиент, используя соответствующие пакеты, могут обмениваться данными, относящимися к клавиатуре или указательным устройствам.
Во время работы может возникнуть одна из несколько различных ситуаций, которая приведет к тому, что хост или клиент потребуют другую скорость передачи данных или другой тип режима интерфейса. Например, компьютер или другое устройство, передающее данные, может столкнуться при обработке данных с такими условиями нагрузки, которые вызовут замедление подготовки или представления пакетов. Дисплей, принимающий данные, может переключиться со специализированного источника питания переменного тока на более ограниченный источник батарейного питания и не сможет пересылать данные также быстро, как обрабатывать команды, или не сможет использовать ту же степень разрешения или глубину цвета при более ограниченных параметрах питания. В альтернативном варианте ограничивающее условие может быть ослаблено или исчезнуть, что позволит любому устройству пересылать данные с более высокими скоростями. Это более желательно, в связи с чем может быть сделан запрос на переход в режим с более высокой скоростью пересылки.
Если появляются или изменяются эти либо другие типы известных условий, то хост или клиент могут их обнаружить и попытаться вновь согласовать режим интерфейса. Это показано на этапе 5420, где хост посылает клиенту пакеты запроса на переключение типа интерфейса, запрашивающие переключение на другой режим, клиент посылает пакеты подтверждения типа интерфейса, подтверждающие попытку изменения, а хост посылает пакеты переключения типа выполнения, чтобы изменить заданный режим.
Хотя конкретный порядок обработки не требуется, клиент и хост могут также обмениваться пакетами, относящимися к данным, которые предназначены для или принимаются от указательных устройств, клавиатур или других пользовательских устройств ввода, связанных в основном с клиентом, хотя указанные элементы могут также присутствовать и на стороне хоста. Эти пакеты обычно обрабатываются с использованием элемента типа общего процессора, а не конечного автомата (5502). Вдобавок некоторые из команд, описанных выше, также обрабатываются общим процессором (5504, 5508).
После обмена данными и командами между хостом и клиентом в некоторый момент принимается решение, пересылать или нет дополнительные данные, либо хост или клиент собираются прекратить обслуживание пересылки. Это показано на этапе 5422. Если линия связи должна перейти в режим бездействия или быть полностью отключена, хост посылает клиенту пакет отключения линии связи и обе стороны прекращают пересылку данных.
Пакеты, пересылаемые при обработке вышеуказанных операций, пересылаются с использованием драйверов и приемников, обсужденных ранее в связи с контроллерами хоста и клиента. Эти драйверы линий и другие логические элементы подсоединены к конечному автомату и общим процессорам, обсужденным выше, как показано на общем виде на фиг.55. На фиг.55 конечный автомат 5502 и общие процессоры 5504 и 5508 могут быть соединены дополнительно с другими непоказанными элементами, такими как специализированный интерфейс USB, элементы памяти или другие компоненты, находящиеся вне контроллера линии связи, с которыми они взаимодействуют, включая, но не только, источник данных и микросхемы управления видеоданными для просмотра дисплейных устройств.
Процессоры и конечный автомат обеспечивают управление включением и блокированием драйверов, как обсуждалось выше в связи с защитными интервалами, и т.д. для обеспечения эффективной установки или оконечной нагрузки линии связи и пересылки пакетов.
XVI. Буферы дисплейных кадров
Требования к буферизации видеоданных для движущихся видеоизображений отличаются от компьютерной графики. Чаще всего пиксельные данные запоминаются в локальном буфере кадров у клиента, с тем чтобы можно было локально обновлять изображение на дисплее.
При отображении видео с полноценным движением (почти каждый пиксель на дисплее изменяет каждый медийный кадр) обычно предпочтительно запоминать входящие пиксельные данные в одном буфере кадров, в то время как изображение на дисплее обновляется из второго буфера кадров. Для исключения визуальных артефактов, как было описано ниже, можно использовать более двух дисплейных буферов. Когда в одном буфере кадров принято все изображение, роли буферов могут поменяться местами, и тогда вновь принятое изображение используется для обновления дисплея, а другой буфер заполняется следующим кадром изображения. Эта концепция показана на фиг.91А, где пиксельные данные записываются в автономный буфер изображения путем установки битов обновления дисплея в '01'.
В других приложениях хосту необходимо обновлять только малую часть изображения без необходимости повторного отображения всего изображения. В этом случае желательно записывать новые пиксели непосредственно в буфер, используемый для обновления дисплея, как подробно показано на фиг.91В.
В приложениях, где имеется фиксированное изображение с небольшим видеоокном, легче всего записать фиксированное изображение в оба буфера (биты обновления дисплея равны '11'), как показано на фиг.91С, и затем записать пиксели движущегося изображения в автономный буфер путем установки битов обновления дисплея в '01'.
Последующие правила описывают манипуляцию указателями буферов, используемую при одновременной записи новой информации для клиента и обновлении дисплея. Имеется три буферных указателя: current_fill указывает на буфер, заполняемый в данный момент данными по линии MDDI; just_filled указывает на буфер, который заполнен последним; being_displayed указывает на буфер, используемый в данный момент для обновления дисплея. Все три буферных указателя могут содержать значения от 0 до N-1, где N - количество буферов дисплея, причем N ≥2. С буферными указателями выполняется операция mod N, например, когда N=3, а current_fill=2, приращение current_fill вызывает установку current_fill в 0. В простом случае, когда N=2, just_filled всегда является дополнением current_fill. На каждой границе медийного кадра MDDI (пакет заголовка субкадра с полем отсчета субкадров, равным нулю) выполняются следующие операции в заданном порядке: установка just_filled равным current_fill и установка current_fill равным current_fill+1.
Пакеты видеопотока MDDI обновляют буферы согласно следующей структуре или методике: когда биты обновления дисплея равны '01', пиксельные данные записываются в буфер, заданный указателем current_fill; когда биты обновления дисплея равны '00', пиксельные данные записываются в буфер, заданный указателем just_filled; а когда биты обновления дисплея равны '11', пиксельные данные записываются во все буферы. Дисплей обновляется из буфера, заданного указателем being_displayed. После того как дисплей обновил последний пиксель в одном сверхкадре обновления кадра и перед началом обновления первого пикселя в следующем сверхкадре обновления кадра, процесс обновления дисплея выполняет операцию установки указателя being_refreshed равным just_filled.
Пакет видеопотока содержит пару бит обновления дисплея, которые задают буфер кадров, куда должны быть записаны пиксельные данные. Пакет возможностей дисплея имеет три дополнительных бита, указывающие, какие комбинации битов обновления дисплея поддерживаются клиентом. Во многих случаях изображения, созданные компьютером, необходимо поэтапно обновлять на основе ввода пользователя или извлекать из информации, принятой из компьютерной сети. Комбинации '00' и '11' битов обновления дисплея поддерживают этот режим работы, вызывая запись пиксельных данных в буфер кадров с указателем being_displayed или в оба буфера кадров.
На фиг.92 показано, как видеоизображения отображаются с использованием пары буферов кадров, когда видеоданные передаются по линии связи MDDI с битами обновления дисплея, равными '01'. После обнаружения в линии связи MDDI границы медийного кадра процесс обновления дисплея запускает обновление из следующего буфера кадров, когда закончился процесс обновления для кадра, обновляемого в данный момент.
Важным допущением, связанным с фиг.92, является то, что изображение принимается от хоста в виде непрерывного потока пикселей, которые передаются в том же порядке, в каком их использует клиент для считывания из буфера кадров для обновления дисплея (считывание обычно выполняется с левого верхнего угла по строкам до нижнего правого угла экрана). Это является очень важной деталью в случаях, когда операции обновления дисплея и пересылки изображения обращаются к одному и тому же буферу кадров.
Это необходимо для того, чтобы частота кадров при обновлении дисплея была больше, чем частота кадров при пересылке изображения во избежание отображения неполных изображений. На фиг.93 показано, каким образом при низкой частоте обновления изображения может появиться фрагментация изображения, то есть обновление дисплея происходит медленнее, чем пересылка изображения.
В изображении, которое содержит комбинацию компьютерных графических изображений и движущихся видеоизображений, пиксельные видеоданные могут занимать небольшую часть медийного кадра. Это может быть существенно в ситуациях, когда операция обновления дисплея и пересылки изображения обращаются к одному и тому же буферу кадров. Эти ситуации показаны на фиг.94 с помощью сетчатого затенения, где пиксели, считанные из буфера для обновления дисплея, могут являться пикселями, записанными в буфер два кадра назад, или они могут соответствовать кадру, записываемому сразу в тот же буфер кадров.
Использование трех буферов кадров у клиента решит проблему маленького окна, порождающего конфликтную ситуацию при доступе к буферу кадров, как показано на фиг.95.
Однако имеется еще одна проблема, если частота обновления дисплея меньше частоты медийных кадров по линии связи MDDI, как показано на фиг.96.
Использование одного буфера для движущихся видеоизображений достаточно проблематично, как показано на фиг.97. Когда дисплей обновляется быстрее, чем пересылается изображение в буфер, обновляемое изображение иногда будет показывать верхнюю часть записываемого кадра, а нижняя часть изображения будет представлять ранее переданный кадр. Когда дисплей обновляется быстрее, чем пересылается изображение (предпочтительный режим работы), будут более часто возникать случаи, когда кадры имеют аналогичное расщепленное изображение.
XVII. Таблица значений задержки
Пакет параметров задержки обработки пакета для вычисления прогнозируемой задержки для обработки некоторых команд у клиента использует справочную таблицу. Значения в этой таблице возрастают в логарифмическом масштабе, обеспечивая очень широкий динамический диапазон значений задержки. Пример таблицы значений задержки, пригодных для реализации вариантов осуществления изобретения, приведен ниже в таблице XX с соответствующими значениями индексов напротив значений задержек.
Задержка вычисляется путем просмотра таблицы с использованием заданного параметра в качестве индекса в таблице. Это значит, что задержка равна PacketProcessingTable (индекс). Например: если один из параметров из пункта списка параметров задержки является 8-разрядным значением, равным 134, то тогда задержка равна PacketProcessingTable (134), что составляет 16 мкс. Значение 255 указывает, что время завершения команды не может быть определено в результате вычисления и что хост должен проверить флаги занятости графики в дисплейном пакете запроса и состояния или параметр В7h управления MCCS VCP.
В некоторых случаях эта задержка умножается на высоту, ширину или количество пикселей в назначенном изображении и добавляется к другим задержкам для вычисления общей задержки обработки пакета.
XVIII. Поддержка множества клиентов
Текущая версия протокола не предназначена для непосредственной поддержки множества клиентских устройств. Однако многие пакеты содержат поле резервного ID клиента, которое можно использовать для адресации конкретных клиентских устройств в системе с множеством клиентов. В настоящее время для многих приложений этот ID клиента или эти ID клиента установлены в нуль. Пакет заголовка субкадра также содержит поле, указывающее, поддерживает ли хост систему с множеством клиентов. Таким образом, имеется способ, при котором в будущих приложениях интерфейса или протокола MDDI могут быть подсоединены и иметь адреса множество клиентских устройств, что поможет разработчикам системы спланировать будущие возможности с множеством хостов и клиентов.
В системах, имеющих множество клиентов, полезно, чтобы клиенты были подсоединены к хосту последовательно или с использованием концентраторов, как показано на фиг.98, или с использованием комбинации этих способов, как показано на фиг.99.
XIХ. Дополнения
Вдобавок к форматам, структурам и контенту, обсужденным выше для различных пакетов, используемых для реализации архитектуры и протокола для вариантов изобретения, здесь представлены более подробный контент или операции для некоторых типов пакетов. Они представлены здесь для пояснения их использования или выполняемых операций, что позволит специалистам в данной области техники без труда понять и использовать изобретение для множества различных приложений. Далее здесь обсуждается несколько полей, которые еще не рассматривались. Вдобавок эти поля представлены вместе с примерными определениями и значениями применительно к выше представленным вариантам. Однако указанные значения не должны рассматриваться как ограничения изобретения; они представляют один или несколько вариантов, пригодных для реализации интерфейса и протокола, причем не все варианты должны быть практически реализованы вместе или одновременно. Как очевидно специалистам в данной области техники, в других вариантах для достижения желаемого представления данных или результатов скоростной пересылки данных в других вариантах могут быть использованы и другие значения.
А. Для пакетов видеопотока
В одном варианте поле атрибутов пиксельных данных (2 байта) имеет ряд битовых значений, которые интерпретируются следующим образом. Биты 1 и 0 выбирают способ маршрутизации дисплейных пиксельных данных. Для битовых значений '11' данные отображаются для обоих глаз, для битовых значений '10' данные направляются только в левый глаз, для битовых значений '01' данные направляются только в правый глаз, а для битовых значений '00' данные направляются на альтернативный дисплей, что может быть задано битами с 8 по 11, обсуждаемыми ниже.
Бит 2 указывает, представлены ли пиксельные данные в формате интерфейса, причем значение '0' означает, что пиксельные данные находятся в стандартном прогрессивном формате и что номер строки (координата Y пикселя) увеличивается на 1 при переходе с одной строки на следующую. Когда этот бит имеет значение '1', пиксельные данные находятся в чересстрочном формате и номер строки увеличивается на 2 при переходе с одной строки на следующую. Бит 3 указывает на то, что пиксельные данные находятся в альтернативном пиксельном формате. Это аналогично стандартному чересстрочному режиму, разрешаемому битом 2, но чередование производится по вертикали, а не по горизонтали. Когда бит 3 равен '0', пиксельные данные находятся в стандартном прогрессивном формате и номер столбца (координата Х пикселя) увеличивается на 1 с каждым последующим принимаемым пикселем. Когда бит 3 равен '1', пиксельные данные находятся в альтернативном пиксельном формате и номер столбца увеличивается на 2 с каждым принимаемым пикселем.
Бит 4 указывает, относятся ли пиксельные данные к дисплею или камере, на который(ую) или от которого(ой) пересылаются данные: на внутренний дисплей или от него, - для беспроводного телефона или аналогичного устройства либо даже портативного компьютера, или других устройств, как обсуждалось выше, либо данные пересылаются на или от камеры, встроенной в устройство или непосредственно подсоединенной к нему. Когда бит 4 равен '0', пиксельные данные пересылаются в или из дисплейного буфера кадров. Когда бит 4 равен '1', пиксельные данные пересылаются на или от камеры или видеоустройства определенного типа вроде устройств, хорошо известных в данной области техники.
Бит 5 используется для указания о том, что пиксельные данные содержат следующую последовательную строку пикселей в дисплее. В этом случае бит 5 устанавливается равным '1'. Когда бит 5 установлен в '1', параметры левый край Х, верхний край Y, правый край Х, нижний край Y, начало Х и начало Y не определены и клиентом игнорируются. Когда бит 15 установлен на уровне логического нуля, это указывает на то, что пиксельные данные в пакете представляют собой последнюю строку пикселей в изображении. Бит 8 поля индикаторов отличительных возможностей клиента в пакете возможностей клиента указывает, поддерживается ли этот признак.
Биты 7 и 6 являются битами обновления дисплея, задающими буфер кадров, куда должны быть записаны пиксельные данные. Более конкретные эффекты обсуждаются в другом месте. Для битовых значений '01' пиксельные данные записываются в автономный буфер изображения. Для битовых значений '00' пиксельные данные записываются в буфер изображения, используемый для обновления дисплея. Для битовых значений '11' пиксельные данные записываются во все буферы изображения. Битовые значения или комбинация '10' трактуется как недействительное значение или обозначение, и тогда пиксельные данные игнорируются и не записываются ни в один из буферов изображения. Это значение можно использовать для будущих приложений интерфейса.
Биты с 8 по 11 образуют 4-разрядное целое число без знака, которое задает альтернативный дисплей или местоположение дисплея, куда должны быть направлены пиксельные данные. Биты 0 и 1 устанавливают равными '00', чтобы клиент дисплея интерпретировал биты с 8 по 11 как номер альтернативного дисплея. Если биты 0 и 1 не равны '00', то тогда биты с 8 по 11 устанавливают на уровни логического нуля.
Биты с 12 по 14 зарезервированы для будущего использования и обычно установлены на уровни логического нуля. Как обсуждалось выше, бит 15 используют вместе с битом 5, а установка бита 15 в логический нуль указывает, что строка пикселей в поле пиксельных данных является последней строкой пикселей в кадре данных. Следующий пакет видеопотока, имеющий бит 5, установленный в логический нуль, будет соответствовать первой строке пикселей следующего видеокадра.
2-байтовые поля начала Х и начала Y задают абсолютные координаты Х и Y точки (начала Х, начла Y) для первого пикселя в поле пиксельных данных. 2-байтовые поля левого края Х и верхнего края Y задают координату Х левого края и координату Y верхнего края окна экрана, заполненного полем пиксельных данных, в то время как поля правого края Х и нижнего края Y задают координату Х правого края и координату Y нижнего края обновляемого окна.
Поле отсчета пикселей (2 байта) задает количество пикселей в поле пиксельных данных, указанном ниже.
Поле CRC параметра (2 байта) содержит CRC всех байтов от длины пакета до отсчета пикселей. Если эта проверка CRC дает отрицательный результат, то весь пакет отбрасывается.
Поле пиксельных данных содержит исходную видеоинформацию, которая должна отображаться и которая сформатирована так, как описано в поле дескриптора формата видеоданных. Данные передаются «построчно», как обсуждается в другом месте.
Поле CRC пиксельных данных (2 байта) содержит 16-разрядную CRC только пиксельных данных. Если проверка этого значения CRC дает отрицательный результат, то тогда пиксельные данные еще можно использовать, но отсчет ошибок CRC увеличивается на единицу.
B. Для пакетов аудиопотока
В одном варианте поле ID аудиоканала (1 байт) использует 8-разрядное целое значение без знака для идентификации конкретного аудиоканала, в который клиентское устройство посылает аудиоданные. Физические аудиоканалы заданы или преобразуются в физические каналы указанным полем в виде значений 0, 1, 2, 3, 4, 5, 6 или 7, которые указывают левый передний, правый передний, левый задний, правый задний, передний центральный, низкочастотный, круговой левый и круговой правый каналы соответственно. Значение 254 ID аудиоканала указывает, что на левый передний и правый передний каналы посылается единый поток цифровых аудиовыборок. Это упрощает передачу для таких приложений, где для речевой связи используются стереонаушники, там, где в PDA используются приложения, повышающие производительность, или в других приложениях, где пользовательский интерфейс создает предупредительные звуковые сигналы. Значения для поля ID, находящиеся в диапазоне от 8 до 253, а также 255 в настоящее время зарезервированы для использования там, где для новых проектов требуются дополнительные обозначения, что очевидно специалистам в данной области техники.
Поле резервное 1 (1 байт) обычно зарезервировано для будущего использования, и все биты этого поля установлены в нуль. Одной из функций этого поля является обеспечение выравнивания последующих 2-байтовых полей по 16-разрядному адресу слова и выравнивания 4-байтовых полей по 32-разрядному адресу слова.
Поле отсчета аудиовыборок (2 байта) задает количество аудиовыборок в этом пакете.
Поле количества бит на выборку и пакетирования содержит 1 байт, который задает формат пакетирования аудиоданных. В одном варианте обычно используется нижеописанный формат, в котором биты с 4 по 0 определяют количество бит на одну аудиовыборку PCM. Далее бит 5 задает, являются ли выборки цифровых аудиоданных пакетированными. Как упоминалось выше, на фиг.12 показано различие между пакетированными аудиовыборками и аудиовыборками с байтовым выравниванием. Значение '0' для бита 5 указывает, что каждая аудиовыборка PCM в поле цифровых аудиоданных имеет байтовое выравнивание по байтовой границе интерфейса, а значение '1' указывает, что каждая последующая аудиовыборка PCM упаковывается впритык к предыдущей аудиовыборке. Этот бит действует только тогда, когда значение, определенное в битах с 4 по 0 (количество бит на одну аудиовыборку PCM), не кратно восьми. Биты с 7 по 6 зарезервированы для использования тогда, когда разработчики системы хотят иметь дополнительные обозначения, и обычно установлены со значением, равным нулю.
Поле частоты аудиовыборок (1 байт) задает частоту аудиовыборок PCM. В используемом формате значение 0 указывает частоту, равную 8000 выборок в секунду (выб./с), значение 1 указывает 16000 выб./с, значение 2 указывает 24000 выб./с, значение 3 указывает 32000 выб./с, значение 4 указывает 40000 выб./с, значение 5 указывает 48000 выб./с, значение 6 указывает 11025 выб./с, значение 7 указывает 22050 выб./с, а значение 8 указывает 44100 выб./с соответственно, причем значения с 9 по 255 зарезервированы для будущего использования, поэтому в данный момент они установлены в нуль.
Поле CRC параметра (2 байта) содержит 16-разрядную CRC всех байтов от длины пакета до частоты аудиовыборок. Если проверка CRC дает отрицательный результат, то тогда весь пакет отбрасывается. Поле цифровых аудиоданных содержит исходные аудиовыборки, подлежащие воспроизведению, которые обычно представлены в линейном формате как целые числа без знака. Поле CRC аудиоданных (2 байта) содержит 16-разрядную CRC только аудиоданных. Если проверка CRC дает отрицательный результат, то тогда аудиоданные еще можно использовать, но отсчет ошибок CRC увеличивается на единицу.
С. Для потоковых пакетов, определенных пользователем
В одном варианте 2-байтовое поле идентификационного номера потока используется для идентификации потока, определенного конкретным пользователем. Содержание полей параметров потока и потоковых данных обычно определяется производителем оборудования MDDI. 2-байтовое поле CRC параметров потока содержит 16-разрядную CRC всех байтов параметров потока, начиная с длины пакета и заканчивая байтом аудиокодирования. Если эта проверка CRC дает отрицательный результат, то весь пакет отбрасывается. Конечное приложение интерфейса MDDI может отбросить оба поля: параметров потока и CRC параметров потока, если в них нет необходимости, то есть если они считаются необязательными. 2-байтовое поле CRC потоковых данных содержит CRC только потоковых данных. Если эта проверка CRC дает отрицательный результат, тогда использование потоковых данных является необязательным, что зависит от требований данного приложения. Использование потоковых данных в зависимости от положительного результата проверки CRC обычно требует буферизации потоковых данных, пока не будет подтвержден положительный результат CRC. Если результат проверки CRC отрицательный, то отсчет ошибок CRC увеличивается на единицу.
D. Для пакетов цветовой карты
2-байтовое поле ID h-клиента содержит информацию или значения, которые зарезервированы для ID клиента, использованного ранее. Поскольку это поле обычно зарезервировано для будущего использования, его текущее значение установлено в нуль путем установки битов в '0'.
2-байтовое поле отсчета элементов цветовой карты использует значения для задания общего количества 3-байтовых элементов цветовой карты, которые содержатся в поле данных цветовой карты, или записи таблицы цветовой карты, которые существуют в данных цветовой карты в этом пакете. В данном варианте количество байтов в данных цветовой карты равно тройному значению отсчета элементов цветовой карты. Отсчет элементов цветовой карты устанавливается равным нулю, чтобы не посылать данные цветовой карты. Если размер цветовой карты равен нулю, то тогда значение сдвига цветовой карты обычно еще посылается, но оно дисплеем игнорируется. Поле сдвига цветовой карты (4 байта) задает сдвиг данных цветовой карты в пакете относительно начала таблицы цветовой карты в клиентском устройстве.
2-байтовое поле CRC параметра содержит CRC всех байтов от длины пакета до байта аудиокодирования. Если эта проверка CRC дает отрицательный результат, то весь пакет отбрасывается.
Для поля данных цветовой карты ширина каждой ячейки цветовой карты задается полем размера элемента цветовой карты, где в одном варианте первая часть задает уровень синего цвета, вторая часть задает уровень зеленого цвета, а третья часть задает уровень красного цвета. Поле размера цветовой карты задает количество 3-байтовых элементов таблицы цветовой карты, которые существуют в поле данных цветовой карты. Если одну цветовую карту нельзя подогнать под один формат видеоданных и пакет цветовой карты, то тогда вся цветовая карта может быть задана путем посылки множества пакетов с разными данными цветовой карты и сдвигами цветовой карты в каждом пакете. Количество бит синего, зеленого и красного цветов в каждом элементе цветовой карты должно быть таким же, какое задано в поле ширины цветовой карты RGB в пакете возможностей дисплея.
2-байтовое поле CRC данных цветовой карты содержит CRC только данных цветовой карты. Если эта проверка CRC дает отрицательный результат, то данные цветовой карты могут еще использоваться, но отсчет ошибок CRC увеличивается на единицу.
Каждый элемент данных цветовой карты должен передаваться в следующем порядке: синий, зеленый, красный, причем первым передается младший значащий бит каждой компоненты. Отдельные красная, зеленая и синяя компоненты каждого элемента цветовой карты должны быть упакованы, а каждый элемент цветовой карты (младший значащий бит синей компоненты) должен иметь байтовое выравнивание. На фиг.100 показан пример элементов данных цветовой карты, с 6 битами синего, 8 битами зеленого и 7 битами красного цвета. Для этого примера размер элемента цветовой карты в пакете цветовой карты равен 21, а поле ширины RGB цветовой карты в пакете возможностей дисплея равно 0x0786.
Е. Для пакетов инкапсуляции обратной линии связи
Поле CRC параметра (2 байта) содержит 16-разрядную CRC всех байтов от длины пакета до длины реверсирования. Если эта проверка CRC дает отрицательный результат, то весь пакет отбрасывается.
В одном варианте поле флагов обратной линии связи (1 байт) содержит набор флагов для запроса информации от клиента. Если бит (например, бит 0) установлен в единицу, то тогда хост запрашивает от дисплея заданную информацию, используя пакет возможностей клиента. Если указанный бит равен нулю, тогда хост не нуждается в информации от клиента. Остальные биты (здесь это биты с 1 по 7) резервируются для будущего использования и установлены в ноль. Однако для установки флагов для обратной линии связи можно использовать больше битов, если это необходимо.
Поле делителя обратной скорости (1 байт) задает количество периодов MDDI_Stb, которые появляются в связи с тактовыми импульсами данных обратной линии связи. Тактовый импульс данных обратной линии связи равен тактовому импульсу данных прямой линии связи, деленному на удвоенный делитель обратной скорости. Скорость передачи данных по обратной линии связи связана с тактовыми импульсами данных обратной линии связи и типом интерфейса в обратной линии связи. Для интерфейса типа 1 скорость передачи данных по обратной линии связи соответствует тактовым импульсам данных обратной линии связи, а для интерфейсов типа 2, типа 3 и типа 4 скорость передачи данных по обратной линии связи соответствует удвоенным, учетверенным и восьмикратным тактовым импульсам данных обратной линии связи соответственно.
Поле все нули 1 содержит группу байтов, здесь это 8 байтов, которая устанавливается равной нулю путем установки бит на уровень логического нуля, причем это поле используется для обеспечения установки сигналов MDDI_Data на уровне логического нуля в течение времени, достаточного для того, чтобы дать возможность клиенту начать восстановление тактовых импульсов, используя только MDDI_Stb, до блокирования драйверов линии хоста в течение поля реверсирование 1. В одном варианте длина поля все нули больше или равна количеству передач байтов по прямой линии связи в течение задержки в кабеле при передаче в прямом и обратном направлении.
Поле длины реверсирования 1 (1 байт) задает общее количество байтов, которое распределяется для реверсирования 1, устанавливая первый период реверсирования. Количество байтов, заданное параметром длины реверсирования 1 распределяется, чтобы дать возможность драйверам линии MDDI_Data у клиента включиться в работу, прежде чем будут заблокированы драйверы линии в хосте. Клиент выполняет разблокирование своих драйверов линии MDDI_Data во время бита 0 реверсирования 1, а хост блокирует свои выходы, с тем чтобы была полная блокировка до последнего бита реверсирования 1. Временные соотношения разблокирования драйвера клиента и блокирования драйвера хоста таковы, что один или оба поддерживают сигналы MDDI_Data на уровне логического нуля на всем интервале реверсирования 1, о чем известно приемникам в хосте. Сигнал MDDI_Stb ведет себя, как будто MDDI_Data0 находится на уровне логического нуля в течение всего периода реверсирования 1. Более полное описание установки реверсирования 1 было дано выше.
Поле пакетов обратных данных содержит ряд пакетов данных, пересылаемых от клиента хосту. Клиент может послать пакеты заполнителя или перевести линии MDDI_Data в нулевое состояние, когда отсутствуют данные для посылки на хост. Если линии MDDI_Data установлены в нуль, то хост будет интерпретировать это как пакет с нулевой длиной (недействительная длина) и хост не примет дополнительных пакетов от клиента в течение текущего пакета инкапсуляции обратной линии связи.
Поле длины реверсирования 2 (1 байт) задает общее количество байт, которое распределяется для реверсирования 2, для установки второго периода реверсирования. Количество байт задается параметром длины реверсирования, чтобы дать возможность драйверам линии MDDI_Data в хосте включиться в работу, прежде чем драйверы линии у клиента будут заблокированы. Хост выполняет разблокирование драйверов линии MDDI_Data в течение бита 0 первого байта в реверсировании 2, а клиент блокирует свои выходы, так чтобы они были полностью заблокированы до последнего бита реверсирования 2. Временные соотношения блокирования драйвера клиента и разблокирования процессов драйвера хоста таковы, что один или оба поддерживают сигналы MDDI_Data на уровне логического нуля в течение всего периода реверсирования 2, о чем известно приемникам линии в хосте. Сигнал MDDI_Stb ведет себя так, как будто бы MDDI_Data0 была бы на уровне логического нуля в течение всего периода реверсирования 2. Описание установки реверсирования 2 дано ниже.
Поле пакетов обратных данных содержит ряд пакетов данных, пересылаемых от клиента к хосту. Как было установлено ранее, пакеты заполнителя посылаются для заполнения оставшегося пространства, которое не используется другими типами пакетов.
Поле все нули 2 содержит группу байт (в этом варианте 8 байт), которые устанавливаются равными нулю путем установки бит на уровень логического нуля, и используется для поддержания всех сигналов MDDI_Data на уровне логического нуля в течение времени, достаточного для того, чтобы дать возможность клиенту начать восстановление тактовых импульсов MDDI_Data0 и MDDI_Stb после разблокирования драйверов линии хоста после поля реверсирования 2.
F. Для пакетов возможностей клиента
Как показано для одного варианта, поле версии протокола использует 2 байта для задания версии протокола, используемой клиентом. Начальная версия устанавливается равной нулю, в то время как поле минимальной версии протокола использует 2 байта для задания минимальной версии протокола, которую клиент может использовать или интерпретировать. Поле возможностей по скорости передачи данных (2 байта) задает максимальную скорость передачи данных, с которой клиент может принимать данные по прямой линии связи интерфейса, причем скорость задается в мегабитах в секунду (Мбит/с). Поле возможностей по типу интерфейса (1 байт) задает типы интерфейса, которые поддерживаются в прямой и обратной линиях связи. В настоящее время это указывается путем выбора бита 0, бита 1 или бита 2 для выбора любого из режимов типа 2, типа 3 или типа 4 в прямой линии связи соответственно; и бита 3, бита 4 или бита 5 для выбора любого из режимов типа 2, типа 3 или типа 4 в обратной линии связи соответственно; при этом биты 6 и 7 являются резервными и установлены в ноль. Поля ширины и высоты битовой карты (2 байта) задают соответственно ширину и высоту битовой карты в пикселях.
Поле возможностей монохромного формата (1 байт) используется для задания количества бит разрешения, которое может отображаться в монохромном формате. Если дисплей не может использовать монохромный формат, то тогда это значение устанавливают в ноль. Биты с 7 по 4 зарезервированы для будущего использования и поэтому установлены в ноль. Биты с 3 по 0 определяют максимальное количество бит серой шкалы, которое может существовать для каждого пикселя. Эти четыре бита позволяют задать значения от 1 до 15 для каждого пикселя. Если это значение равно нулю, то тогда монохромный формат дисплеем не поддерживается.
Поле возможностей формата Bayer использует 1 байт для задания количества бит разрешения, пиксельной группы и порядка пикселей, которые могут пересылаться в формате Bayer. Если клиент не может использовать формат Bayer, то тогда это значение равно нулю. Поле возможностей формата Bayer состоит из следующих значений: биты с 3 по 0 определяют максимальное количество бит интенсивности, которые существуют в каждом пикселе, в то время как биты с 5 по 4 определяют требуемый шаблон группы пикселей, а биты с 8 по 6 определяют требуемый порядок пикселей; при этом биты с 14 по 9 зарезервированы для будущего использования и обычно устанавливаются в ноль. Когда бит 15 установлен в единицу, это указывает на то, что клиент может принимать пиксельные данные Bayer в упакованном или неупакованном формате, если бит 15 установлен в нуль, это указывает, что клиент может принимать пиксельные данные Bayer только в неупакованном формате.
Поле возможностей цветовой карты (3 байта) задает максимальное количество пунктов таблицы, которые существуют в таблице цветовой карты в дисплее. Если дисплей не может использовать формат цветовой карты, то тогда это значение устанавливают в нуль.
Поле возможностей RGB (2 байта) задает количество бит разрешения, которое может отображаться в формате RGB. Если дисплей не может использовать формат RGB, то тогда это значение равно нулю. Слово возможностей RGB состоит из трех отдельных значений без знака, где: биты с 3 по 0 определяют максимальное количество бит синего цвета, биты с 7 по 4 определяют максимальное количество бит зеленого цвета, а биты с 11 по 8 определяют максимальное количество бит красного цвета в каждом пикселе. В настоящее время биты с 14 по 12 зарезервированы для будущего использования и обычно установлены в ноль. Когда бит 15 установлен в единицу, это указывает на то, что клиент может принимать пиксельные данные либо в упакованном, либо в неупакованном формате. Если бит 15 установлен в нуль, это указывает, что клиент может принимать пиксельные данные только в неупакованном формате.
Поле возможностей Y Cr Cb (2 байта) задает количество бит разрешения, которое может быть отображено в формате Y Cr Cb. Если дисплей не может использовать формат Y Cr Cb, то это значение устанавливают равным нулю. Слово возможностей Y Cr Cb состоит из трех отдельных значений без знака, где биты с 3 по 0 определяют максимальное количество бит в выборке Cb, биты с 7 по 4 определяют максимальное количество бит в выборке Сr, биты с 11 по 8 определяют максимальное количество бит в выборке Y, а биты с 15 по 12 в данное время зарезервированы для будущего использования и установлены в ноль.
Поле отличительных возможностей клиента использует 4 байта, которые содержат набор флагов, указывающих на поддерживаемые специфические признаки в дисплее. Бит, установленный в единицу, указывает, что возможности поддерживаются, а бит, установленный в нуль, указывает, что возможности не поддерживаются. Значение бита 0 указывает на то, поддерживается ли пакет пересылки блоков битовой карты (тип пакета 71). Значение для битов 1, 2 и 3 указывает, поддерживается ли пакет заполнения области битовой карты (пакет типа 72), пакет заполнения шаблона битовой карты (пакет типа 73) или пакет канала данных линии связи (пакет типа 74) соответственно. Значение для бита 4 указывает, имеет ли клиент возможность сделать один цвет прозрачным, в то время как значения для битов 5 и 6 указывают, может ли клиент принять соответственно видеоданные или аудиоданные в упакованном формате, а значение для бита 7 указывает, может ли клиент послать видеопоток по обратной линии связи из камеры. Значение для бита 8 указывает, имеет ли клиент возможность приема полной строки пиксельных данных и игнорировать адресацию дисплея, как это задано битом 5 поля атрибутов пиксельных данных в пакете видеопотока, причем клиент может также обнаружить синхронизацию кадров или конец данных видеокадра через бит 15 поля атрибутов пиксельных данных.
Значение для битов 11 и 12 указывает, когда клиент осуществляет связь соответственно с указательным устройством и может посылать и принимать пакеты данных указательного устройства или с клавиатурой и может посылать и принимать пакеты данных клавиатуры. Значение для бита 13 указывает, имеет ли клиент возможность устанавливать один или несколько аудио или видеопараметров путем поддержки пакетов характеристик VCP: пакет запроса характеристик VCP, ответный пакет характеристик VCP, пакет установки характеристик VCP, пакет запроса действительных параметров и ответный пакет действительных параметров. Значение для бита 14 указывает, имеет ли клиент возможность записи пиксельных данных в автономный буфер дисплейных кадров. Если этот бит установлен на уровне логической единицы, то тогда биты обновления дисплея (биты 7 и 6 поля атрибутов пиксельных данных в пакете видеопотока) могут быть установлены в'01'. Значение для бита 22 указывает, имеет ли клиент возможность ответа на пакет доступа к регистру. Биты с 9 по 10 и с 23 по 31 зарезервированы в настоящее время для будущего использования или для альтернативных целей, полезных для разработчиков системы, и обычно установлены равными нулю.
Поле возможностей по частоте видеокадров дисплея (1 байт) задает максимальную частоту обновления видеокадров дисплея в кадрах в секунду. Хост может выбрать для обновления изображения более низкую частоту, чем значение, заданное в этом поле.
Поле глубины аудиобуфера (2 байта) задает глубину эластичного буфера в дисплее, который выделен для каждого аудиопотока.
Поле возможностей по аудиоканалам (2 байта) содержит группу флагов, которые указывают, какие аудиоканалы поддерживаются дисплеем (клиентом). Когда бит установлен в единицу, это указывает на то, что канал поддерживается, а бит, установленный в нуль, указывает, что канал не поддерживается. Позиции битов присваиваются разным каналам, например битовые позиции 0, 1, 2, 3, 4, 5, 6 и 7 указывают левый передний, правый передний, левый задний, правый задний, передний центральный, низкочастотный, круговой левый и круговой правый каналы соответственно. Биты с 8 по 15 в настоящее время зарезервированы для будущего использования и обычно установлены в ноль.
2-байтовое поле возможностей по частоте аудиовыборки для прямой линии связи содержит набор флагов, указывающих возможности клиентского устройства по частоте аудиовыборки. Битовые позиции присваиваются разным частотам соответственно, например биты 0, 1, 2, 3, 4, 5, 6, 7 и 8 присваиваются значениям 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050 и 44100 выборок в секунду (SPS) соответственно, причем биты с 9 по 15 зарезервированы для будущих или альтернативных частот, если это потребуется, но в настоящее время они установлены в '0'. Установка значения для одного из этих бит в '1' указывает, что поддерживается конкретная частота выборки, а установка бита в '0', указывает что данная частота выборки не поддерживается.
Поле минимальной частоты субкадров (2 байта) задает минимальную частоту субкадров в кадрах в секунду. Минимальная частота субкадров поддерживает частоту обновления состояния дисплея, достаточную для считывания данных с некоторых датчиков или указательных устройств на дисплее.
2-байтовое поле возможностей по частоте выборки с микрофона для обратной линии связи содержит набор флагов, указывающих возможности микрофона по частоте аудиовыборки в этом клиентском устройстве. Для целей 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', указывает что данная частота выборки не поддерживается. Если микрофон не подсоединен, то тогда каждый из бит возможностей частоты выборки с микрофона установлен равным нулю.
Поле типа защиты контента (2 байта) содержит набор флагов, которые указывают тип защиты цифрового контента, поддерживаемый дисплеем. В настоящее время битовая позиция 0 используется для указания того, когда поддерживается DTCP, а битовая позиция 1 используется для указания того, когда поддерживается HDCP, при этом битовые позиции с 2 по 15 зарезервированы для использования с другими схемами защиты, если это необходимо или имеет место, но в настоящее время они установлены в 0.
G. Для пакетов запроса и состояния клиента
Поле запроса обратной линии связи (3 байта) задает количество байт, необходимых клиенту в обратной линии связи в следующем субкадре для посылки информации хосту.
Поле отсчета ошибок CRC (1 байт) указывает, сколько ошибок CRC появилось с начала медийного кадра. Отсчет CRС сбрасывается в ноль, когда посылается пакет заголовка субкадра с отсчетом субкадров. Если действительное количество ошибок CRC превышает 255, то тогда это значение обычно оставляют равным 255.
Поле изменения возможностей использует 1 байт для указания изменения возможностей дисплея. Такая ситуация может возникнуть, если пользователь подсоединяет периферийное устройство, такое как микрофон, клавиатура или дисплей, либо по какой-то другой причине. Когда биты [7:0] равны 0, тогда возможности не изменяются, поскольку был послан последний пакет возможностей клиента. Однако когда биты [7:0] равны от 1 до 255, возможности изменились. Пакет возможностей клиента анализируется, чтобы определить новые характеристики дисплея.
H. Для пакетов пересылки блоков бит
Поля значения координаты Х и координаты Y верхнего левого угла окна используют 2 байта каждый для задания значений Х и Y координат верхнего левого угла окна, подлежащего перемещению. Поля ширины и высоты окна используют 2 байта каждый для задания ширины и высоты перемещаемого окна. Поля перемещения окна по Х и перемещения окна по Y используют 2 байта каждый для задания количества пикселей, на которое окно должно переместиться по горизонтали и вертикали соответственно. Как правило, эти координаты сконфигурированы так, что положительные значения Х вызывают перемещение окна вправо, а отрицательные значения вызывают перемещение влево, в то время как положительные значения Y вызывают перемещение окна вниз, а отрицательные значения вызывают перемещение окна вверх.
I. Для пакетов заполнения области битовой карты
Поля значения координаты Х и координаты Y верхнего левого угла окна используют 2 байта каждый для задания значений Х и Y координат верхнего левого угла окна, подлежащего заполнению. Поля ширины и высоты окна 2 байта каждый задают ширину и высоту окна, подлежащего заполнению. Поле дескриптора формата видеоданных (2 байта) задает формат значения заполнения пиксельной области. Этот формат такой же, как аналогичное поле в пакете видеопотока. Поле значения заполнения пиксельной области (4 байта) содержит пиксельное значение, заполняемое в окне, заданном обсужденными выше полями. Формат этого пикселя задается в поле дескриптора формата видеоданных.
J. Для пакетов заполнения шаблона битовой карты
Поля значения координаты Х и координаты Y верхнего левого угла окна используют 2 байта каждый для задания значений Х и Y координат верхнего левого угла окна, подлежащего заполнению. Поля ширины и высоты окна 2 байта каждый задают ширину и высоту окна, подлежащего заполнению. Поля ширины и высоты шаблона (2 байта каждый) задают соответственно ширину и высоту шаблона заполнения. 2-байтовое поле дескриптора формата видеоданных задает формат значения заполнения пиксельной области. На фиг.11 показано, как кодируется дескриптор формата видеоданных. Этот формат такой же, как аналогичное поле в пакете видеоданных.
Поле CRC параметра (2 байта) содержит CRC всех байтов от длины пакета до дескриптора видеоформата. Если эта проверка CRC дает отрицательный результат, то тогда весь пакет отбрасывается. Поле пиксельных данных шаблона содержит исходную видеоинформацию, которая задает шаблон заполнения в формате, заданном дескриптором формата видеоданных. Данные упакованы в байты, а первый пиксель каждой строки должен быть выровнен по байту. Данные шаблона заполнения передаются построчно. Поле CRC пиксельных данных шаблона (2 байта) содержит CRC только пиксельных данных шаблона. Если проверка CRC дает отрицательный результат, то тогда пиксельные данные шаблона еще могут использоваться, но отсчет ошибок CRC увеличивается на единицу.
K. Пакеты канала данных линии связи
Поле CRC параметра (2 байта) содержит 16-разрядную CRC всех байтов от длины пакета до типа пакета. Если эта проверка CRC дает отрицательный результат, то тогда весь пакет отбрасывается.
Поле данных линии связи содержит исходные данные из канала связи. Эти данные просто проходят на вычислительное устройство в дисплее.
Поле CRC данных линии связи (2 байта) содержит 16-разрядную CRC только данных линии связи. Если эта проверка CRC дает отрицательный результат, то данные линии связи еще используются или пригодны для использования, но отсчет ошибок CRC увеличивается на единицу.
L. Для пакетов запроса переключения типа интерфейса
Поле типа интерфейса (1 байт) задает новый тип интерфейса для использования. Значение в этом поле задает тип интерфейса следующим образом. Если значение в бите 7 равно '0', то запрос на переключение типа предназначен для прямой линии связи, а если оно равно '1', то запрос на переключение типа относится к обратной линии связи. Биты с 6 по 3 зарезервированы для будущего использования и обычно установлены в ноль. Биты с 2 по 0 используются для определения типа интерфейса, подлежащего использованию, причем значение 1 означает переключение на режим типа 1, значение 2 - переключение на режим типа 2, значение 3 означает переключение на режим типа 3, а значение 4 - переключение на режим типа 4. Значения '0' и с 5 по 7 зарезервированы для обозначения будущих альтернативных режимов или комбинаций режимов.
M. Для пакетов подтверждения типа интерфейса
Поле типа интерфейса (1 байт) имеет значение, подтверждающее новый тип интерфейса для использования. Значение в этом поле задает тип интерфейса следующим образом. Если бит 7 равен '0', то запрос на переключение типа относится к прямой линии связи, в альтернативном случае, если он равен '1', то запрос на переключение типа предназначен для обратной линии связи. Битовые позиции с 6 по 3 на данный момент зарезервированы для обозначения других типов переключения, если это потребуется, и в настоящее время установлены в нуль. Однако битовые позиции с 2 по 0 используются для определения типа интерфейса, подлежащего использованию, причем значение '0' указывает отрицательное подтверждение, или что запрошенное переключение не может быть выполнено, а значения '1', '2', '3' и '4' указывают на переключение в режимы типа 1, типа 2, типа 3 и типа 4 соответственно. Значения с 5 по 7 зарезервированы для использования с альтернативными обозначениями режимов, если это потребуется.
N. Для пакетов переключения типа выполнения
1-байтовое поле типа интерфейса указывает новый тип интерфейса для использования. Значение, представленное в этом поле, задает тип интерфейса сначала путем использования значения бита 7 для определения того, предназначено ли переключение типа для прямой или обратной линии связи. Значение '0' указывает, что запрос переключения типа относится к прямой линии связи, а значение '1' к обратной линии связи. Биты с 6 по 3 зарезервированы для будущего использования и обычно установлены в ноль. В то же время биты с 2 по 0 используются для определения типа интерфейса, подлежащего использованию, причем значения 1, 2, 3 и 4 задают переключение на режимы типа 1, типа 2, типа 3 и типа 4 соответственно. Значения 0 и с 5 по 7 для этих бит зарезервированы для будущего использования.
O. Для пакетов разблокирования прямого аудиоканала
Поле маски разблокирования аудиоканала (1 байт) содержит группу флагов, которые указывают, какие аудиоканалы должны быть разблокированы у клиента. Бит, установленный в единицу, включает соответствующий канал, а бит, установленный в 0, блокирует соответствующий канал. Биты с 0 по 5 обозначают каналы с 0 по 5, которые относятся к левому переднему, правому переднему, левому заднему, правому заднему, переднему центральному и низкочастотному каналам соответственно. Биты 6 и 7 зарезервированы для будущего использования и обычно установлены в ноль.
P. Для обратных пакетов частоты аудиовыборки
Поле частоты аудиовыборки (1 байт) задает частоту цифровой аудиовыборки. В этом поле различным частотам присваивают значения 0, 1, 2, 3, 4, 5, 6, 7 и 8, которые используют для обозначения соответствующих частот, равных 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050 и 44100 выборок в секунду (SPS), при этом значения с 9 по 254 зарезервированы для использования с альтернативными частотами, если это потребуется, но в настоящее время они установлены в '0'. Значение 255 используется для блокирования аудиопотока обратной линии связи.
Поле формата выборки (1 байт) задает формат цифровых аудиовыборок. Когда биты [1:0] равны '0', цифровые аудиовыборки находятся в линейном формате, когда эти биты равны 1, то цифровые аудиовыборки находятся в формате µ-типа, а когда они равны 2, то цифровые аудиовыборки находятся в формате А-типа. Биты [7:2] зарезервированы для альтернативного использования при обозначении аудиоформатов, если это потребуется, и обычно установлены в ноль.
Q. Для пакетов служебных данных защиты цифрового контента
Поле типа защиты контента (1 байт) задает используемый способ защиты цифрового контента. Значение '0' указывает на защиту DTCP (защита цифрового контента передачи), в то время как значение 1 указывает на защиту HDCP (сверхширокополосная система защиты цифрового контента). Диапазон значений от 2 до 255 в настоящее время не задан, а зарезервирован для использования с альтернативными схемами защиты, если это потребуется. Поле сообщений со служебными данными защиты контента имеет переменную длину и содержит сообщения для защиты контента, посылаемые между хостом и клиентом.
R. Для пакетов разрешения прозрачного цвета
Поле разрешения прозрачного цвета (1 байт) задает условие разрешения или блокирования режима прозрачного цвета. Если бит 0 равен 0, то режим прозрачного цвета заблокирован, а если он равен 1, то режим прозрачного цвета разрешен, причем прозрачный цвет задается следующими двумя параметрами. Биты с 1 по 7 этого байта зарезервированы для будущего использования и обычно установлены в ноль.
Поле дескриптора формата видеоданных (2 байта) задает формат значения заполнения пиксельной области. На фиг.11 показано, как кодируется дескриптор формата видеоданных. Этот формат обычно такой же, как аналогичное поле в пакете видеопотока.
Поле значения заполнения пиксельной области использует 4 байта, распределенные для заполнения значения пикселя в окне, заданном выше. Формат этого пикселя задается в поле дескриптора формата видеоданных.
S. Для пакетов измерения задержки при передаче в прямом и обратном направлениях
2-байтовое поле длины пакета задает общее количество байт в пакете, исключая поле длины пакета, и в одном варианте выбирается с фиксированной длиной 159. 2-байтовое поле типа пакета, которое определяет тип этого пакета со значением 82, идентифицирует пакет как пакет измерения задержки при передаче в прямом и обратном направлениях. Поле ID h-клиента, как и раньше, зарезервировано для будущего использования в качестве ID клиента и обычно устанавливается в нуль.
В одном варианте поле CRC параметра (2 байта) содержит 16-разрядную CRC всех битов от длины пакета до типа пакета. Если результат проверки CRC отрицательный, то весь пакет отбрасывается.
Поле защитного интервала 1 (здесь 64 байта) используется, чтобы дать возможность драйверам линии MDDI_Data у клиента включится, прежде чем будут заблокированы драйверы линии в хосте. Клиент включает драйверы линии MDDI_Data во время бита 0 защитного интервала 1, а хост блокирует свои драйверы линии, так чтобы обеспечить полную блокировку до последнего бита защитного интервала 1. Хост и клиент поддерживают уровень логического нуля в течение защитного интервала 1, когда они не заблокированы. Другим назначением этого поля является обеспечение того, чтобы сигналы MDDI_Data были на уровне логического нуля в течение времени, достаточного для того, чтобы дать возможность клиенту начать восстановление тактовых импульсов или тактовых сигналов с использованием только MDDI_Stb до блокирования драйверов линии хоста.
Поле периода измерения представляет собой 64-байтовое окно, используемое для того, чтобы дать возможность клиенту откликнуться двумя байтами 0xff и 30 байтами 0x0 со скоростью, составляющей половину от скорости передачи данных, используемой в прямой линии связи. Эта скорость передачи данных соответствует делителю скорости обратной линии связи, равному 1. Клиент возвращает этот ответ немедленно в момент приема, то есть в начале периода измерения. Этот ответ клиента будет принят хостом с точностью до задержки при передаче в прямом и обратном направлениях плюс логическая задержка у клиента после начала первого бита периода измерения у хоста.
Поле все нули (2 байта) содержит нули, чтобы дать возможность драйверам линии MDDI_Data в хосте и у клиента работать с перекрытием, так чтобы линия MDDI_Data была всегда возбуждена. Хост включает драйверы линии MDDI_Data во время бита 0 защитного интервала 2, а клиент также устанавливает сигнал на уровень логического нуля, как он делал это в конце периода измерения.
Значение в поле защитного интервала 2 (64 байта) позволяет обеспечить перекрытие периода измерения, поддерживаемого клиентом, когда задержки при передаче в прямом и обратном направлениях составляет максимальную величину, которая может быть измерена за период измерения. Клиент блокирует свои драйверы линии во время бита 0 защитного интервала 2, а хост включает свои драйверы линии сразу после последнего бита защитного интервала 2. Хост и клиент поддерживают уровень логического нуля в течение защитного интервала 2, когда они не заблокированы. Другим назначением этого поля является обеспечение того, чтобы все сигналы MDDI_Data были на уровне логического нуля в течение времени, достаточного для того, чтобы дать возможность клиенту начать восстановление тактовых сигналов с использованием MDDI_Data и MDDI_Stb после включения драйверов линии для хоста.
T. Для пакетов калибровки асимметрии прямой линии связи
В одном варианте поле CRC параметра (2 байта) содержит 16-разрядную CRC всех байтов от длины пакета до типа пакета. Если эта проверка CRC дает отрицательный результат, то весь пакет отбрасывается.
Поле последовательности данных калибровки содержит 512-байтовую последовательность данных, которая заставляет сигналы MDDI_Data переключаться с каждым периодом данных. Во время обработки последовательности данных калибровки контроллер хоста MDDI устанавливает все сигналы MDDI_Data, равными стробирующему сигналу. Схема восстановления тактовых импульсов дисплея должна использовать только MDDI_Stb, а не MDDI_Stb XOR MDDI_Data0 для восстановления тактовых импульсов, в то время когда дисплей клиента принимает поле последовательности данных калибровки. В зависимости от точной фазы сигнала MDDI_Stb в начале поля последовательности данных калибровки последовательность данных калибровки обычно будет представлять собой одну из следующих последовательностей в зависимости от типа интерфейса, используемого, когда этот пакет был послан:
Тип I - 0xaa, 0xaa… или 0х55, 0х55…
Тип II - 0хсс, 0хсс… или 0х33, 0х33…
Тип III - 0xf0, 0xf0… или 0x0f, 0x0f…
Тип IV - 0xff, 0x00, 0xff, 0x00… или 0x00, 0xff, 0x00, 0xff…
Примеры возможных форм сигналов MDDI_Data и MDDI_Stb для интерфейсов типа 1 и типа 2 показаны на фиг.62А и 62В соответственно.
XX. Заключение
Хотя выше были описаны различные варианты настоящего изобретения, следует понимать, что они были представлены только в качестве примера, а не как ограничение. Таким образом, рамки и объем настоящего изобретения не должны ограничиваться ни одним из вышеописанных вариантов, а должны определяться только в соответствии с нижеследующей формулой изобретения и ее эквивалентами.
| название | год | авторы | номер документа |
|---|---|---|---|
| ИНТЕРФЕЙС С ВЫСОКОЙ СКОРОСТЬЮ ПЕРЕДАЧИ ДАННЫХ | 2004 |
|
RU2371872C2 |
| ИНТЕРФЕЙС ВЫСОКОСКОРОСТНОЙ ПЕРЕДАЧИ ДАННЫХ С УЛУЧШЕННЫМ УПРАВЛЕНИЕМ СОЕДИНЕНИЕМ | 2004 |
|
RU2341906C2 |
| ИНТЕРФЕЙС С ВЫСОКОЙ СКОРОСТЬЮ ПЕРЕДАЧИ ДАННЫХ | 2004 |
|
RU2331160C2 |
| УСТРОЙСТВО И СПОСОБ РЕАЛИЗАЦИИ ИНТЕРФЕЙСА ВЫСОКОСКОРОСТНОЙ ПЕРЕДАЧИ ДАННЫХ | 2005 |
|
RU2353066C2 |
| УСТРОЙСТВО И СПОСОБ ДЛЯ РЕАЛИЗАЦИИ ИНТЕРФЕЙСА С ВЫСОКОЙ СКОРОСТЬЮ ПЕРЕДАЧИ ДАННЫХ | 2005 |
|
RU2337497C2 |
| УСТРОЙСТВО И СПОСОБ ИНТЕРФЕЙСА С ВЫСОКОЙ СКОРОСТЬЮ ПЕРЕДАЧИ ДАННЫХ | 2005 |
|
RU2355121C2 |
| БЕСПРОВОДНАЯ АРХИТЕКТУРА ДЛЯ ТРАДИЦИОННОГО ПРОВОДНОГО ПРОТОКОЛА | 2008 |
|
RU2485726C2 |
| ПЕРЕДАЧА ДАННЫХ 3D ИЗОБРАЖЕНИЯ | 2010 |
|
RU2536388C2 |
| ПЕРЕДАЧА ДАННЫХ 3D ИЗОБРАЖЕНИЯ | 2010 |
|
RU2538333C2 |
| УСТРОЙСТВО ПЕРЕДАЧИ, СПОСОБ ПЕРЕДАЧИ, УСТРОЙСТВО ПРИЕМА И СПОСОБ ПРИЕМА | 2014 |
|
RU2657473C2 |
Изобретение относится к интерфейсу данных для пересылки цифровых данных между хостом и клиентом по каналу связи с использованием пакетных структур, связанных вместе для формирования коммуникационного протокола для передачи предварительно выбранного набора цифровых данных управления и представления. Техническим результатом является повышение пропускной способности при пересылке данных между хост-устройствами, обеспечивающими эти данные, и клиентскими устройствами. Сигнальный протокол используется для контроллеров линии связи, выполненных с возможностью создания, передачи и приема пакетов, формирующих коммуникационный протокол, и формирования цифровых данных в пакетах одного или нескольких типов, причем по меньшей мере, один из них находится в хост- устройстве и связан с клиентом через канал связи. Интерфейс обеспечивает экономически эффективный потребляющий малую мощность двунаправленный механизм для высокоскоростной пересылки данных по линии связи для ближней «последовательной» передачи, который подходит для реализации с миниатюрными разъемами и тонкими гибкими кабелями, особенно полезными при соединении дисплейных элементов, таких как переносные микродисплеи для портативных компьютеров и устройств беспроводной связи. 6 н. и 21 з.п. ф-лы, 115 ил., 20 табл.
1. Способ повторного определения первого логического порога и второго логического порога для состояния бездействия системы связи с интерфейсом цифровых данных, содержащий этапы, на которых осуществляют:
отправку пакета отключения линии связи от хоста к клиенту, причем первый логический уровень и второй логический уровень определяют первый логический порог по меньшей мере одного приемника данных;
блокирование по меньшей мере одного драйвера данных и установку его выхода в высокоимпедансное состояние при помощи хоста, причем третий логический уровень и четвертый логический уровень определяют второй логический порог по меньшей мере одного бездействующего приемника, и при этом четвертый логический уровень создается по меньшей мере одним заблокированным драйвером данных в высокоимпедансном состянии;
передачу сигнала пробуждения к по меньшей мере одному бездействующему приемнику, причем сигнал пробуждения содержит вывод третьего логического уровня; и обнаружение сигнала пробуждения по меньшей мере одним бездействующим приемником.
2. Способ по п.1, в котором этап блокирования дополнительно содержит блокирование по меньшей мере одного приемника различных высокоскоростных пакетов данных.
3. Способ по п.1, в котором этап передачи сигнала пробуждения содержит передачу хостом сигнала пробуждения.
4. Способ по п.1, в котором этап передачи сигнала пробуждения содержит передачу клиентом сигнала пробуждения.
5. Способ по п.1, в котором первый логический уровень равен третьему логическому уровню.
6. Система для повторного определения первого логического порога и второго логического порога для состояния бездействия системы связи с интерфейсом цифровых данных, при этом система содержит:
средство для отправки пакета отключения линии связи от хоста к клиенту, причем первый логический уровень и второй логический уровень определяют первый логический порог по меньшей мере одного приемника данных;
средство для блокирования по меньшей мере одного драйвера данных и установки его выхода в высокоимпедансное состояние при помощи хоста, причем третий логический уровень и четвертый логический уровень определяют второй логический порог по меньшей мере одного бездействующего приемника, и при этом четвертый логический уровень создается по меньшей мере одним заблокированным драйвером данных в высокоимпедансном состянии;
средство для передачи сигнала пробуждения к по меньшей мере одному бездействующему приемнику, причем сигнал пробуждения содержит вывод третьего логического уровня; и
средство для обнаружения сигнала пробуждения по меньшей мере одним бездействующим приемником.
7. Система по п.6, в которой средство для блокирования дополнительно содержит средство для блокирования по меньшей мере одного приемника различных высокоскоростных пакетов данных.
8. Система по п.6, в которой средство для передачи сигнала пробуждения содержит сигнал пробуждения передаваемый хостом.
9. Система по п.6, в которой средство для передачи сигнала пробуждения содержит сигнал пробуждения передаваемый клиентом.
10. Система по п.6, в которой первый логический уровень равен третьему логическому уровню.
11. Компьютерно-читаемый носитель с компьютерным программным продуктом, содержащим выполняемый компьютерно-читаемый программный код, вызывающий повторное определение первого логического порога и второго логического порога для состояния бездействия системы связи с интерфейсом цифровых данных, причем упомянутый компьютерно-читаемый код содержит:
код, вызывающий отправку пакета отключения линии связи от хоста к клиенту, причем первый логический уровень и второй логический уровень определяют первый логический порог по меньшей мере одного приемника данных;
код, вызывающий блокирование по меньшей мере одного драйвера данных и установку его выхода в высокоимпедансное состояние при помощи хоста, причем третий логический уровень и четвертый логический уровень определяют второй логический порог по меньшей мере одного бездействующего приемника, и при этом четвертый логический уровень создается по меньшей мере одним заблокированным драйвером данных в высокоимпедансном состянии;
код, вызывающий передачу сигнала пробуждения к по меньшей мере одному бездействующему приемнику, причем сигнал пробуждения содержит вывод третьего логического уровня; и
код, вызывающий обнаружение сигнала пробуждения по меньшей мере одним бездействующим приемником.
12. Компьютерно-читаемый носитель по п.11, в котором код, вызывающий блокирование по меньшей мере одного драйвера данных дополнительно содержит код, вызывающий блокирование по меньшей мере одного приемника различных высокоскоростных пакетов данных.
13. Компьютерно-читаемый носитель по п.11, в котором код, вызывающий передачу сигнала пробуждения содержит код, вызывающий передачу хостом сигнала пробуждения.
14. Компьютерно-читаемый носитель по п.11, в котором код, вызывающий передачу сигнала пробуждения содержит код, вызывающий передачу клиентом сигнала пробуждения.
15. Компьютерно-читаемый носитель по п.11, в котором первый логический уровень равен третьему логическому уровню.
16. Способ передачи от клиента на хост выбора частоты выборки недействительных данных для обратного потока аудиоданных в системе связи с цифровым интерфейсом для мобильных дисплеев (MDDI), содержащий этапы, на которых осуществляют:
отправляют обратный пакет инкапсуляции от хоста к клиенту;
отправляют пакет сообщения об ошибке от клиента к хосту, причем пакет сообщения об ошибке содержит индикатор того, что клиент не поддерживает частоту выборки недействительных данных;
запрашивают при помощи хоста пакет возможностей клиента, содержащий запрос на предмет данных поддержки аудиопотока; и
отправляют к хосту пакет возможностей клиента, причем пакет возможностей клиента содержит данные поддержки аудиопотока.
17. Способ по п.16, в котором данные поддержки аудиопотока содержат индикатор того, что клиент не поддерживает обратный поток аудиоданных.
18. Способ по п.16, в котором данные поддержки аудиопотока содержат индикатор того, что клиент поддерживает по меньшей мере одну скорость передачи данных.
19. Способ по п.18, дополнительно содержащий этап выбора хостом рабочей скорости передачи данных из по меньшей мере одной скорости передачи данных.
20. Система передачи от клиента на хост выбора частоты выборки недействительных данных для обратного потока аудиоданных в системе связи с цифровым интерфейсом для мобильных дисплеев (MDDI), причем система содержит:
средство для отправки обратного пакета инкапсуляции от хоста к клиенту;
средство для отправки пакета сообщения об ошибке от клиента к хосту, причем пакет сообщения об ошибке содержит индикатор того, что клиент не поддерживает частоту выборки недействительных данных;
средство для запроса при помощи хоста пакета возможностей клиента, содержащего запрос на предмет данных поддержки аудиопотока;
и средство для отправки к хосту пакета возможностей клиента, причем пакет возможностей клиента содержит данные поддержки аудиопотока.
21. Система по п.20, в которой данные поддержки аудиопотока содержат индикатор того, что клиент не поддерживает обратный поток аудиоданных.
22. Система по п.20, в которой данные поддержки аудиопотока содержат индикатор того, что клиент поддерживает по меньшей мере одну скорость передачи данных.
23. Способ по п.22, дополнительно содержащий средство для выбора хостом рабочей скорости передачи данных из по меньшей мере одной скорости передачи данных.
24. Компьютерно-читаемый носитель с компьютерным программным продуктом, содержащим выполняемый компьютерно-читаемый программный код, вызывающий передачу от клиента на хост выбора частоты выборки недействительных данных для обратного потока аудиоданных в системе связи с цифровым интерфейсом для мобильных дисплеев (MDDI), причем упомянутый компьютерно-читаемый код содержит:
код, вызывающий отправку обратного пакета инкапсуляции от хоста к клиенту;
код, вызывающий отправку пакета сообщения об ошибке от клиента к хосту, причем пакет сообщения об ошибке содержит индикатор того, что клиент не поддерживает частоту выборки недействительных данных;
код, вызывающий запрашивание при помощи хоста пакета возможностей клиента, содержащего запрос на предмет данных поддержки аудиопотока; и
код, вызывающий отправку к хосту пакета возможностей клиента, причем пакет возможностей клиента содержит данные поддержки аудиопотока.
25. Компьютерно-читаемый носитель по п.24, в котором данные поддержки аудиопотока содержат индикатор того, что клиент не поддерживает обратный поток аудиоданных.
26. Компьютерно-читаемый носитель по п.24, в котором данные поддержки аудиопотока содержат индикатор того, что клиент поддерживает по меньшей мере одну скорость передачи данных.
27. Компьютерно-читаемый носитель по п.26, дополнительно содержащий код, вызывающий выбор хостом рабочей скорости передачи данных из по меньшей мере одной скорости передачи данных.
| СИСТЕМА СВЯЗИ С КОЛЛЕКТИВНЫМ ДОСТУПОМ И КОДОВЫМ РАЗДЕЛЕНИЕМ КАНАЛОВ (СДМА), СИСТЕМА СВЯЗИ АБОНЕНТОВ С ПОМОЩЬЮ БАЗОВОЙ СТАНЦИИ С АБОНЕНТАМИ УДАЛЕННОЙ СИСТЕМЫ, СИСТЕМА МЕСТНОЙ СВЯЗИ И СПОСОБ СОЗДАНИЯ МНОГОЛУЧЕВОГО РАСПРОСТРАНЕНИЯ ПЕРЕДАВАЕМЫХ СИГНАЛОВ СДМА В СИСТЕМЕ СВЯЗИ | 1991 |
|
RU2111619C1 |
| МНОГОРЕЖИМНОЕ УСТРОЙСТВО РАДИОСВЯЗИ И МНОГОРЕЖИМНЫЙ СОТОВЫЙ РАДИОТЕЛЕФОН | 1993 |
|
RU2128886C1 |
| US 5751951 A, 12.05.1998 | |||
| Переносная печь для варки пищи и отопления в окопах, походных помещениях и т.п. | 1921 |
|
SU3A1 |
