RU2353066C2 - Устройство и способ реализации интерфейса высокоскоростной передачи данных - Google Patents
Устройство и способ реализации интерфейса высокоскоростной передачи данных Download PDFInfo
- Publication number
- RU2353066C2 RU2353066C2 RU2006147230/09A RU2006147230A RU2353066C2 RU 2353066 C2 RU2353066 C2 RU 2353066C2 RU 2006147230/09 A RU2006147230/09 A RU 2006147230/09A RU 2006147230 A RU2006147230 A RU 2006147230A RU 2353066 C2 RU2353066 C2 RU 2353066C2
- Authority
- RU
- Russia
- Prior art keywords
- packet
- data
- client
- client device
- data rate
- Prior art date
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 184
- 238000000034 method Methods 0.000 title claims abstract description 129
- 230000002441 reversible effect Effects 0.000 claims abstract description 364
- 238000005259 measurement Methods 0.000 claims abstract description 72
- 238000004891 communication Methods 0.000 claims description 231
- 230000006854 communication Effects 0.000 claims description 231
- 230000004044 response Effects 0.000 claims description 128
- 238000012546 transfer Methods 0.000 claims description 90
- 238000005538 encapsulation Methods 0.000 claims description 60
- 238000005070 sampling Methods 0.000 claims description 50
- 238000000262 chemical ionisation mass spectrometry Methods 0.000 claims description 18
- 230000007246 mechanism Effects 0.000 abstract description 33
- 230000008054 signal transmission Effects 0.000 abstract description 33
- 230000000694 effects Effects 0.000 abstract description 13
- 239000000126 substance Substances 0.000 abstract 1
- 239000000872 buffer Substances 0.000 description 165
- 238000012545 processing Methods 0.000 description 97
- 230000008859 change Effects 0.000 description 62
- 239000000523 sample Substances 0.000 description 58
- 230000007704 transition Effects 0.000 description 42
- 230000008569 process Effects 0.000 description 39
- 239000004020 conductor Substances 0.000 description 38
- 230000006870 function Effects 0.000 description 35
- 238000010586 diagram Methods 0.000 description 26
- 238000004519 manufacturing process Methods 0.000 description 21
- 230000000630 rising effect Effects 0.000 description 21
- 239000000047 product Substances 0.000 description 19
- 230000001934 delay Effects 0.000 description 15
- 238000005516 engineering process Methods 0.000 description 14
- 238000012795 verification Methods 0.000 description 14
- 229920001690 polydopamine Polymers 0.000 description 13
- 238000003860 storage Methods 0.000 description 13
- 230000008901 benefit Effects 0.000 description 12
- 238000013461 design Methods 0.000 description 12
- 230000000007 visual effect Effects 0.000 description 12
- 230000002618 waking effect Effects 0.000 description 12
- 238000009434 installation Methods 0.000 description 11
- 238000012790 confirmation Methods 0.000 description 10
- 230000000737 periodic effect Effects 0.000 description 10
- 230000008929 regeneration Effects 0.000 description 10
- 238000011069 regeneration method Methods 0.000 description 10
- 230000006266 hibernation Effects 0.000 description 9
- 230000003287 optical effect Effects 0.000 description 8
- 230000008093 supporting effect Effects 0.000 description 8
- 230000009471 action Effects 0.000 description 7
- 238000013459 approach Methods 0.000 description 7
- 230000003111 delayed effect Effects 0.000 description 7
- 238000001514 detection method Methods 0.000 description 7
- 238000005265 energy consumption Methods 0.000 description 7
- 239000011521 glass Substances 0.000 description 7
- 239000010410 layer Substances 0.000 description 7
- 230000033001 locomotion Effects 0.000 description 7
- 230000001681 protective effect Effects 0.000 description 7
- 238000011084 recovery Methods 0.000 description 7
- 230000006399 behavior Effects 0.000 description 6
- 239000000945 filler Substances 0.000 description 6
- 230000007958 sleep Effects 0.000 description 6
- 230000001360 synchronised effect Effects 0.000 description 6
- 125000004122 cyclic group Chemical group 0.000 description 5
- 238000009826 distribution Methods 0.000 description 5
- 230000005284 excitation Effects 0.000 description 5
- 230000001976 improved effect Effects 0.000 description 5
- 230000003139 buffering effect Effects 0.000 description 4
- 230000006872 improvement Effects 0.000 description 4
- 230000002452 interceptive effect Effects 0.000 description 4
- 238000010295 mobile communication Methods 0.000 description 4
- 230000008447 perception Effects 0.000 description 4
- 230000000750 progressive effect Effects 0.000 description 4
- 230000002829 reductive effect Effects 0.000 description 4
- 230000005236 sound signal Effects 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 239000003086 colorant Substances 0.000 description 3
- 238000011049 filling Methods 0.000 description 3
- 238000003780 insertion Methods 0.000 description 3
- 230000037431 insertion Effects 0.000 description 3
- 230000011664 signaling Effects 0.000 description 3
- 238000010200 validation analysis Methods 0.000 description 3
- 241000238876 Acari Species 0.000 description 2
- 101001053395 Arabidopsis thaliana Acid beta-fructofuranosidase 4, vacuolar Proteins 0.000 description 2
- 230000007175 bidirectional communication Effects 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 2
- 238000005352 clarification Methods 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 230000007547 defect Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 238000000802 evaporation-induced self-assembly Methods 0.000 description 2
- 238000003384 imaging method Methods 0.000 description 2
- 238000012432 intermediate storage Methods 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 238000003032 molecular docking Methods 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 238000004806 packaging method and process Methods 0.000 description 2
- 238000012856 packing Methods 0.000 description 2
- 230000036961 partial effect Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 238000013139 quantization Methods 0.000 description 2
- 230000004043 responsiveness Effects 0.000 description 2
- 101001053401 Arabidopsis thaliana Acid beta-fructofuranosidase 3, vacuolar Proteins 0.000 description 1
- HBBGRARXTFLTSG-UHFFFAOYSA-N Lithium ion Chemical compound [Li+] HBBGRARXTFLTSG-UHFFFAOYSA-N 0.000 description 1
- 101100345589 Mus musculus Mical1 gene Proteins 0.000 description 1
- 241001538234 Nala Species 0.000 description 1
- XUIMIQQOPSSXEZ-UHFFFAOYSA-N Silicon Chemical compound [Si] XUIMIQQOPSSXEZ-UHFFFAOYSA-N 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000033228 biological regulation Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 239000003990 capacitor Substances 0.000 description 1
- 238000012512 characterization method Methods 0.000 description 1
- 238000000576 coating method Methods 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 230000007123 defense Effects 0.000 description 1
- 238000006073 displacement reaction Methods 0.000 description 1
- 230000005670 electromagnetic radiation Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000011152 fibreglass Substances 0.000 description 1
- 239000011888 foil Substances 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 230000012010 growth Effects 0.000 description 1
- 210000003128 head Anatomy 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000036039 immunity Effects 0.000 description 1
- 239000003112 inhibitor Substances 0.000 description 1
- 230000002401 inhibitory effect Effects 0.000 description 1
- 230000005764 inhibitory process Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 229910001416 lithium ion Inorganic materials 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 239000002184 metal Substances 0.000 description 1
- 229910044991 metal oxide Inorganic materials 0.000 description 1
- 150000004706 metal oxides Chemical class 0.000 description 1
- 238000002156 mixing Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000013021 overheating Methods 0.000 description 1
- 238000004445 quantitative analysis Methods 0.000 description 1
- 230000005855 radiation Effects 0.000 description 1
- 230000007420 reactivation Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000001172 regenerating effect Effects 0.000 description 1
- 239000012557 regeneration buffer Substances 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 239000012723 sample buffer Substances 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
- 238000012216 screening Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 229910052710 silicon Inorganic materials 0.000 description 1
- 239000010703 silicon Substances 0.000 description 1
- 239000002356 single layer Substances 0.000 description 1
- 239000000758 substrate Substances 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/75—Indicating network or usage conditions on the user display
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
- H04M1/724—User interfaces specially adapted for cordless or mobile telephones
- H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
- H04M1/72409—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
- H04L2012/6483—Video, e.g. MPEG
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
- H04M1/724—User interfaces specially adapted for cordless or mobile telephones
- H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
- H04M1/72409—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
- H04M1/72412—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories using two-way short-range wireless interfaces
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Human Computer Interaction (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
- Control Of Indicators Other Than Cathode Ray Tubes (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Information Transfer Systems (AREA)
- Dc Digital Transmission (AREA)
- Telephone Function (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Controls And Circuits For Display Device (AREA)
- Optical Communication System (AREA)
- Cable Transmission Systems, Equalization Of Radio And Reduction Of Echo (AREA)
- Small-Scale Networks (AREA)
Abstract
Изобретение относится к способу передачи мультимедийных сигналов от ведущего устройства или устройства контроллера на клиентское устройство для отображения конечному пользователю, используя механизм высокоскоростной передачи данных с малой потребляемой мощностью. Техническим результатом является увеличение пропускной способности системы при передаче данных между клиентскими устройствами и ведущим устройством. Предложен интерфейс передачи данных, причем посылают импульс внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях к ведущему устройству от клиентского устройства для каждого канала данных; измеряют задержку прохождения сигнала в прямом и обратном направлениях системы с цифровым интерфейсом мобильной системы передачи данных (ЦИМС) посредством обнаружения импульса, посланного внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях, для каждого канала данных; определяют фазу посланного импульса; сохраняют измеренную задержку прохождения сигнала в прямом и обратном направлениях каждого канала; определяют время для начала выборки данных обратной передачи, посланных клиентским устройством, на основании измеренной задержки прохождения сигнала в прямом и обратном направлениях каждого канала данных и фазы посланного импульса, посланного в ответ клиентским устройством относительно границы бита в окне измерения. 14 н. и 16 з.п. ф-лы, 99 ил., 17 табл.
Description
Испрашивание приоритета согласно параграфу 119 раздела 35 Свода Законов США
Настоящая заявка испрашивает приоритет заявок на патент США № 60/577500 "Switchable Threshold Differential Interface", поданной 4 июня 2004 г., и 60/577793 "Switchable Threshold Differential Interface", поданной 7 июня 2004 г., которые обе переданы заявителю настоящей заявки и тем самым явно включены по ссылке.
Область техники
Варианты осуществления изобретения в настоящем описании относятся к протоколу цифрового сигнала, процессу, этапам способа и устройству, включая интегральные схемы и один или более электронных компонентов, для выполнения обменов или передачи сигналов между ведущим (главным) устройством и клиентским устройством с высокой скоростью передачи данных. Более конкретно, настоящее раскрытие относится к способу передачи мультимедийных и других типов цифровых сигналов от ведущего устройства или устройства контроллера на клиентское устройство для представления или отображения конечному пользователю, используя механизм высокоскоростной передачи данных с малой потребляемой мощностью, имеющий прикладные программы внутренних и внешних устройств.
Уровень техники
Продукты, относящиеся к компьютерам, электронным играм и различные технологии видео (например, цифровые универсальные диски (DVD) и видеомагнитофоны высокой четкости) получили значительное развитие за последние несколько лет, чтобы обеспечить представление со значительно более высоким разрешением неподвижных изображений, видео, "видео по требованию" и графических изображений, даже когда включены некоторые типы текста, конечным пользователям такого оборудования. Эти усовершенствования, в свою очередь, позволили использовать электронные устройства воспроизведения более высокого разрешения, например видеомониторы высокой четкости, мониторы телевидения повышенной четкости (HDTV), или специализированные элементы проецирования изображений. Объединение таких визуальных изображений с аудиоданными высокой резкости или "качества", например, при использовании воспроизведения звука типа компакт-диска (CD), DVD, окружающего звука и других устройств, также имеющих ассоциированные выходные аудиосигналы, используется для создания более реалистического, богатого по содержанию или истинного восприятия мультимедийной информации для конечного пользователя.
Кроме того, высоко мобильные звуковые системы высокого качества и механизмы транспортировки музыки, такие как MP3 плееры, были разработаны для представления конечным пользователям только аудио. Это привело к увеличению типичными пользователями ожидания коммерческих электронных устройств, от компьютеров до телевидения и даже телефонов, теперь приспособленных к и ожидающих высоко качественного или с улучшенным качеством выходного сигнала. Кроме того, теперь предложены различные переносные устройства и беспроводные приемники для воспроизведения задержанных или представленных в реальном времени изображений от провайдеров контента, например телевидения или киностудий и спортивных привилегированных организаций или средств.
В типичном сценарии представления видео, использующем изделия электроники, видеоданные обычно передаются с использованием известных методов со скоростью, которая в наилучшем случае может быть названа как медленная или средняя, составляющая значение порядка от одного до десятков килобит в секунду. Эти данные затем или буферизуются, или сохраняются в основанных на переходных периодах (динамических) или долговременных запоминающих устройствах для отсроченного (более позднего) воспроизведения на требуемом воспроизводящем устройстве. Например, изображения могут быть переданы "через" или используя Интернет, используя программу, резидентную на компьютере, имеющем модем или другой тип устройства подключения к Интернет, чтобы принимать или передавать данные, полезные при представлении изображения в цифровой форме. Аналогичная передача может иметь место с использованием беспроводных устройств, например переносных компьютеров, оборудованных беспроводными модемами, или беспроводных персональных цифровых ассистентов (PDA, ПЦА), или радиотелефонах.
После приема данные сохраняют локально в элементах, схемах или устройствах памяти, например оперативной памяти (RAM) или флэш-памяти, включая внутренние или внешние запоминающие устройства, например жесткие диски небольшого размера, для воспроизведения. В зависимости от количества данных и разрешения изображения воспроизведение может начинаться относительно быстро или быть представлено с длительной задержкой. То есть в некоторых случаях представление изображения учитывает некоторую степень воспроизведения в режиме реального времени для изображений очень малого или низкого разрешения, не требующих большого количества данных, или используя некоторый тип буферизации, так чтобы после малой задержки некоторые данные были представлены, в то время как дополнительные данные передаются. Если не имеется никаких прерываний в линии связи или помех от других систем или пользователей относительно используемого канала передачи, как только начинается представление, передача является довольно прозрачной конечному пользователю воспроизводящего устройства. Естественно, когда многие пользователи совместно используют единственный тракт связи, например проводное подключение к Интернет, передачи могут быть прерваны или быть медленнее, чем желательно.
Данные, используемые для создания или неподвижных изображений, или видеофильмов, часто сжимают, используя один из нескольких хорошо известных методов, например указанный объединенной группой экспертов в области фотографии метод сжатия изображений (JPEG), экспертной группой по движущимся изображениям (MPEG) и другими известными организациями стандартов или компаний в мультимедиа, компьютерах и отраслях промышленности связи, чтобы ускорить передачу данных по линии связи. Это позволяет передавать изображения или данные быстрее, используя меньшее число битов для передачи заданного количества информации.
Как только данные переданы "локальному" устройству, такому как компьютер, имеющему механизм хранения, такой как запоминающее устройство, или магнитные или оптические запоминающие элементы, или другие приемные устройства, полученная информация декомпрессируется (или воспроизводится, используя специальные декодирующие устройства воспроизведения) и декодируется, если необходимо, и подготавливается для соответствующего представления на основании соответствующего доступного разрешения представления и элементов управления. Например, разрешение видеоизображения для типового компьютера в терминах экранного разрешения X на Y пикселей обычно изменяется от такого малого, как 480×640 пикселей, через 600×800 до 1024×1024, хотя ряд других значений разрешения обычно возможны, или желательны, или необходимы.
На представление изображения также влияет содержимое (контент) изображения и способность заданных видеоконтроллеров управлять изображением в терминах некоторых заранее определенных уровней цвета или глубины цвета (битов на пиксель, используемых для формирования цвета) и интенсивности и используя любые дополнительные служебные биты. Например, обычное компьютерное представление ожидается составляющим приблизительно от 8 до 32 или больше битов на пиксель для представления различных цветов (теней и оттенков), хотя встречаются и другие значения.
Из вышеупомянутых значений можно видеть, что заданное отображаемое изображение может требовать передачи приблизительно от 2,45 Мегабит (МБ) до приблизительно 33,55 МБ данных в диапазоне от самых низких до самых высоких типовых значений разрешения и глубины соответственно. При просмотре изображений типа видео или кино со скоростью 30 кадров в секунду количество требуемых данных равно приблизительно от 73,7 до 1006 Мегабит данных в секунду (Мбит/с) или приблизительно от 9,21 до 125,75 Мегабайт в секунду (МБ/с). Кроме того, можно пожелать представлять аудиоданные вместе с изображениями, например, для мультимедийного представления или как отдельное звуковое представление с высоким разрешением, например музыку с качеством CD. Дополнительные сигналы, связанные с интерактивными командами, средствами управления или сигналами также могут использоваться. Каждый из этих параметров добавляет еще больше данных к тем, что должны быть переданы. Кроме того, более новые методы передачи, включающие HDTV и записи кинофильмов, могут добавлять еще больше данных и информации управления. В любом случае, когда кто-то желает передавать данные изображения с высоким качеством или с высоким разрешением и высоко качественные аудиоинформацию или сигналы данных конечному пользователю, чтобы создать богатый контент, требуется линия связи с высокой скоростью передачи данных между элементами представления и исходным или ведущим устройством, которое сконфигурировано так, чтобы обеспечить такие типы данных.
Скорости передачи данных приблизительно 115 килобайт (КБ/с) или 920 килобит в секунду (Кбит/с) могут обычно обрабатываться некоторыми современными последовательными интерфейсами. Другие интерфейсы, такие как последовательные интерфейсы USB, могут реализовывать передачи данных со скоростями, такими же высокими, как 12 МБ/с, а специализированные высокоскоростные передачи, такие как те, что сконфигурированы с использованием стандарта 1394 Института инженеров по электротехнике и электронике (IEEE), могут происходить при скоростях порядка от 100 до 400 МБ/с. К сожалению, эти скорости не соответствуют желательным высоким скоростям передачи данных, описанным выше, которые рассматриваются в качестве возможных для использования с будущими беспроводными устройствами передачи данных и другими услугами для обеспечения выходных сигналов с высоким разрешением и богатых по содержанию для управления переносными видеодисплеями или аудиоустройствами. Это справедливо для компьютеров для бизнеса и других представлений, игровых устройств и т.д. Кроме того, эти интерфейсы требуют использования существенной части программного обеспечения ведущего устройства или системы и клиента для работы. Их программные стеки протоколов также создают нежелательное большое количество служебной информации, особенно когда рассматриваются мобильные беспроводные устройства или телефонные прикладные программы. Такие устройства имеют жесткие требования к памяти и ограничения потребляемой мощности, так же как уже оплаченную вычислительную способность. Кроме того, некоторые из этих интерфейсов используют объемные кабели, которые являются слишком тяжелыми и неудовлетворительными для ориентированных на высоко эстетических мобильных применений, сложные соединители, которые увеличивают стоимость или просто потребляют слишком много мощности.
Имеются другие известные интерфейсы, например Аналоговый видеографический адаптер (AVGA), интерфейсы интерактивного цифрового видео (DVI) или гигабитный видеоинтерфейс (GVIF). Первые два из них являются интерфейсами параллельного типа, которые обрабатывают данные при более высоких скоростях передачи, но также используют тяжелые кабели и потребляют большую мощность, порядка нескольких ватт. Ни одна из этих характеристик не может быть скорректирована для использования с переносными электронными устройствами потребителя. Даже третий интерфейс потребляет слишком много мощности и использует дорогие или большие соединители.
Для некоторых из вышеупомянутых интерфейсов и других очень высокоскоростных систем/протоколов передачи и обработки данных или механизмов передачи, связанных с передачами данных для оборудования компьютера с фиксированной установкой, существует другой главный недостаток. Приспособление к желательным скоростям передачи данных также требует значительной мощности и/или работы на высоких уровнях тока. Это сильно уменьшает полноценность таких методов для продуктов, ориентируемых на высоко мобильного потребителя.
В общем случае, чтобы реализовать такие скорости передачи данных, используя альтернативы, такие как, скажем, например, стекловолоконные соединения и элементы передачи, также требуется ряд дополнительных преобразователей и элементов, которые вносят намного большую сложность и стоимость, чем желательно для продукта, ориентируемого на истинно коммерческого потребителя. В дополнение к нынешней обычно еще дорогой природе оптических систем их требования к мощности и сложность мешают общему использованию для легких, маломощных переносных примеров применения.
Что недостает в промышленности для переносных, беспроводных или мобильных приложений - это методика, которая обеспечит представление высокого качества, будь то аудио, видео или основанное на мультимедиа, для высокомобильных конечных пользователей. То есть при использовании переносных компьютеров, беспроводных телефонов, PDA или других высокомобильных устройств связи или оборудования современные используемые системы или устройства представления видео и аудио просто не могут выдавать выходной сигнал на желательном уровне с высоким качеством. Часто воспринимаемое качество, которого недостает, является результатом недоступных высоких скоростей передачи данных, необходимых для передачи данных представления высокого качества. Это может включать в себя как передачу для более эффективного, усовершенствованного или имеющего богатые функциональные возможности внешнего устройства для представления конечному пользователю или передачу между главными компьютерами и клиентами, являющимися внутренними для переносных устройств, таких как компьютеры, игровые автоматы и беспроводные устройства типа мобильных телефонов.
В этом последнем случае имеются большие успехи, достигнутые при добавлении внутренних видеоэкранов все более и более высокого разрешения и устройств ввода и/или вывода другой специализации и соединений к беспроводным устройствам, подобным так называемым телефонам третьего поколения, и к так называемым портативным компьютерам. Однако внутренние шины данных и соединения могут включать в себя соединения через вращающийся стержень, или стержень-подобные структуры, или структуры со скользящим контактом, которые крепят или подсоединяют видеоэкраны или другие элементы к главному корпусу, где находятся ведущее устройство и/или различные другие управляющие элементы и компоненты вывода. Существуют обычно широкополосные или высоко производительные интерфейсы. Очень трудно сконструировать высоко производительные интерфейсы передачи данных, используя предшествующие методы, которые могут требовать до 90 проводников или более для достижения требуемой производительности на, скажем, беспроводном телефоне, например. Современные решения обычно включают в себя использование параллельных интерфейсов, например, с относительно высокими уровнями сигналов, которые могут сделать подключение более дорогостоящим, менее надежным и потенциально генерировать излучаемое излучение, которые могут интерферировать с функциями устройства. Это представляет много производственных, стоимостных проблем и проблем надежности, которые нужно преодолеть.
Такие проблемы и требования также можно видеть на устройствах стационарного расположения, где устройства для связи или вычислений в качестве примера добавляются к приборам и другим устройствам потребителя, чтобы обеспечить усовершенствованные возможности передачи данных, соединения с Интернет и линии передачи данных, или встроенные в развлечения. Другим примером могут быть самолеты и автобусы, где индивидуальные экраны видео и аудиопредставления установлены в месте для сидения. Однако в этих ситуациях часто более удобно, эффективно и более просто для обслуживания иметь элементы основного хранения, обработки или управления обменом, расположенные на расстоянии от видимых экранов или аудиовыводов с линией межсоединения или каналом для представления информации. Эта линия связи должна обработать значительное количество данных, чтобы достичь требуемой производительности, как описано выше.
Поэтому необходим новый механизм передачи, чтобы увеличить пропускную способность передачи данных между ведущими устройствами, обеспечивающими данные, и клиентскими устройствами отображения или элементами, представляющими выходной сигнал конечным пользователям.
Заявители предложили такие новые механизмы передачи в заявке на патент США № 10/020,520, поданной 14 декабря 2001, теперь патент США № 6,760,772, выданный 6 июля 2004 Zou и другим, и заявке на патент США № 10/236,657, поданной 6 сентября 2002 "Generating And Implementing A Communication Protocol And Interface For High Data Rate Signal Transfer", права на обе из которых переданы заявителю настоящего изобретения и включены здесь по ссылке, а также заявке на патент США № 10/860,116, поданной 2 июня 2004 г. "Generating and Implementing a Signal Protocol and Interface for Higher Data Rates." Способы, описанные в этих заявках, могут значительно увеличивать скорость передачи для больших объемов данных в сигналах высокоскоростной передачи данных. Однако требования к все увеличивающейся скорости передачи данных, в особенности что касается представления видео, продолжают расти. Даже при появляющихся других событиях в технологии передачи сигнала данных имеется постоянная потребность бороться за еще более быстрые скорости передачи, улучшенную эффективность линии связи и более мощные линии связи. Поэтому имеется настоятельная потребность разработать новый или улучшенный механизм передачи, который необходим, чтобы увеличить пропускную способность данных между клиентскими устройствами и ведущим устройством.
Сущность изобретения
Вышеупомянутый недостаток, а также другие, существующие в данной области техники, преодолеваются вариантами осуществления изобретения, в котором были разработаны новый протокол и средства передачи данных, способ и механизм для передачи данных между ведущим устройством и клиентским устройством получателя при высоких скоростях передачи данных.
Варианты осуществления изобретения относятся к цифровому интерфейсу мобильной системы передачи данных (ЦИМС, MDDI) для передачи цифровых данных с высокой скоростью передачи данных между ведущим устройством и клиентским устройством по тракту связи, который использует множество или последовательность пакетных структур, чтобы сформировать протокол обмена для обмена заранее выбранного набора цифровых данных управления и представления между ведущим и клиентским устройствами. Протокол обменов сигналами или уровень линии связи используются физическим уровнем контроллеров, приемников или задающих устройств линии связи ведущего устройства или клиентского устройства. По меньшей мере один контроллер или задающее устройство линии связи, постоянно находящееся в ведущем устройстве, подсоединены к клиентскому устройству через коммуникационный тракт или линию связи и сконфигурированы так, чтобы сгенерировать, передавать и принимать пакеты, формирующие протокол связи (обмена), и сформировать цифровые данные представления в пакеты данных одного или более типов. Этот интерфейс обеспечивает двунаправленную передачу информации между ведущим и клиентским устройством, которая может осуществляться в обычном общем корпусе или поддерживающей структуре.
Вся реализация обычно является цифровой по природе за исключением дифференциальных задающих устройств (устройств возбуждения) и приемников, которые могут быть легко реализованы на цифровых микросхемах комплементарной металл-оксидной полупроводниковой технологии (CMOS), требует несколько, например 6, сигналов и работает на почти любой скорости передачи данных, которая является удобной для системного проектировщика. Простой протокол физического уровня и уровня линии связи делает его легким для интеграции, и эта простота плюс состояние ожидания дают возможность портативной системе иметь очень низкую потребляемую мощность системы.
Для облегчения использования и принятия интерфейс очень незначительно увеличит стоимость устройства, учтет потребление очень небольшой мощности, в то же время будет способен подавать питание на дисплеи через интерфейс, используя стандартные напряжения батареи, и может обеспечить размещение устройств, имеющих карманный форм-фактор. Интерфейс является масштабируемым, чтобы поддерживать разрешения помимо HDTV, поддерживать одновременное стерео видео и 7.1 аудио для устройства отображения, выполняет обычные обновления для любой экранной области и поддерживает множество типов данных в обоих направлениях.
В дополнительных аспектах вариантов осуществления изобретения по меньшей мере один контроллер линии связи клиента, приемник, устройство или задающее устройство расположены в клиентском устройстве и подсоединены к ведущему устройству через коммуникационный тракт или линию связи. Контроллер линии связи клиента также сконфигурирован так, чтобы генерировать, передавать и принимать пакеты, формирующие протокол обмена, и формировать цифровые данные представления в один или более типов пакетов данных. Обычно контроллер ведущего устройства или контроллер линии связи использует конечный автомат для обработки пакетных данных, используемых в командах или некоторых типах процедур подготовки сигнала и обработки запроса, но могут использовать более медленный универсальный (общего назначения) процессор, чтобы управлять данными и некоторыми из менее сложных пакетов, используемых в протоколе обмена. Контроллер ведущего устройства содержит один или более дифференциальных устройств возбуждения линии; в то время как приемник пользователя содержит один или более дифференциальных приемников линии, подсоединенных к коммуникационному тракту.
Пакеты сгруппированы вместе в пределах кадров мультимедийной информации, которыми обмениваются между ведущим устройством и клиентскими устройствами, имеющими заранее определенную фиксированную длину с заранее определенным количеством пакетов, имеющих различные переменные длины. Каждый из этих пакетов содержит поле длины пакета, одно или более полей пакетных данных и поле циклического контроля избыточности. Пакет "Заголовок под-кадра" передается или позиционируется в начале передачи других пакетов от контроллера линии связи ведущего устройства. Один или более пакетов типа «Поток видео» и пакетов типа «Поток аудио» используются в соответствии с протоколом обмена, чтобы передавать данные типа видео и данные типа аудио соответственно от ведущего устройства к клиенту по прямой линии связи для представления пользователю клиентского устройства. Один или более пакетов типа пакета «Инкапсуляция обратной линии связи» используются в соответствии с протоколом обмена, чтобы передавать данные от клиентского устройства на контроллер линии связи ведущего устройства. Эта передача в некоторых вариантах осуществления включает в себя передачу данных от внутренних контроллеров, имеющих по меньшей мере одно устройство MDDI, к внутренним видеоэкранам. Другие варианты осуществления включают в себя передачу к внутренним звуковым системам и передачи от различных устройств ввода данных, включающих в себя джойстики и сложные клавиатуры, на внутренние ведущие устройства.
Пакеты типа «Заполнитель» формируются контроллером линии связи ведущего устройства, чтобы заполнить периоды передачи прямой линии связи, которые не имеют данных. Множество других пакетов используется в соответствии с протоколом обмена, чтобы передавать видеоинформацию. Такие пакеты включают в себя пакеты типа "Карта цвета", "Поблочная пересылка битовой карты", "Заполнение области битовой карты", "Заполнение шаблона битовой карты" и "Разрешение прозрачного цвета". Пакеты типа "Определяемый пользователем поток" используются в соответствии с коммуникационным протоколом, чтобы передавать данные, определяемые пользователем интерфейса. Пакеты типа "Данные клавиатуры" и "Данные устройства указания" используются в соответствии с коммуникационным протоколом, чтобы передавать данные к или от устройств ввода данных пользователя, связанных с упомянутым клиентским устройством. Пакет типа "Завершение работы линии связи" используется в соответствии с протоколом обмена, чтобы завершить передачу данных в любом направлении по упомянутому коммуникационному тракту.
Пакеты "Состояние управления питанием дисплея" формируются, чтобы обеспечить структуру, средства или способ для перевода конкретных аппаратных средств контроллера дисплея в состояние малого потребления мощности, когда клиент, например дисплей, не используется или не находится в текущем активном использовании, чтобы минимизировать потребляемую мощность системы или непроизводительные расходы системных ресурсов. В одном варианте осуществления клиент указывает способность ответить на пакеты "Состояние управления питанием дисплея", используя бит 9 поля Client Feature Capability Indicators (Индикаторы возможностей характеристик клиента) в пакете "Возможности пользователя".
Согласно формату в одном варианте осуществления в отношении пакета "Состояние управления питанием дисплея" этот тип пакета структурирован так, что имеет поля «Длина пакета» (Packet Length), «Тип пакета» (Packet Type), «Идентификатор клиента» (hClient ID), «Состояние управления питанием» (Power State) и «CRC» (контроль при помощи циклического избыточного кода - ЦИК). Этот тип пакета обычно идентифицируется как пакет Типа 75 в 2-байтовом поле типа. 2-байтовое поле hClient ID содержит информацию или значения, которые зарезервированы для идентификатора пользователя. Поле Power State определяет информацию, используемую для перевода конкретного дисплея в указанное состояние потребления мощности согласно значению некоторых предварительно выбранных битов. 2-байтовое поле CRC определяет или содержит CRC-код всех байтов в пакете, включая «Длина пакета».
Коммуникационный тракт обычно содержит или использует кабель, имеющий набор из четырех или более проводников и экранирующий провод. Кроме того, при необходимости могут использоваться печатные провода или проводники, причем некоторые могут находиться на гибких подложках.
Контроллер линии связи ведущего устройства запрашивает информацию о функциональных возможностях дисплея от клиентского устройства, чтобы определить какие данные и скорости передачи данных упомянутый клиент способен обеспечить через упомянутый интерфейс. Контроллер линии связи клиента сообщает о функциональных возможностях дисплея или представления на контроллер линии связи ведущего устройства, используя по меньшей мере один пакет типа «Возможности клиента». Множество режимов передачи используются в соответствии с протоколом обмена (коммуникационным протоколом), причем каждый из них разрешает передачу различного максимального количества битов данных параллельно в течение заданного периода времени, каждый режим может быть выбран посредством проведения согласования ("переговоров") между контроллерами линии связи ведущего устройства и клиента. Эти режимы передачи являются динамически корректируемыми в течение передачи данных, и один и тот же режим не должен использоваться на обратной линии связи, когда он используется на прямой линии связи.
В других аспектах некоторых вариантов осуществления изобретения ведущее устройство содержит беспроводное устройство связи, такое как беспроводный телефон, беспроводный PDA или портативный компьютер, имеющий беспроводный модем, расположенный в нем. Типичное клиентское устройство содержит портативный видеодисплей, такой как устройство микроотображения (микродисплей), и/или переносную систему представления аудио. Кроме того, ведущее устройство может использовать средства хранения или элементы для сохранения представления или мультимедийных данных, которые должны быть переданы, чтобы быть представленными пользователю клиентского устройства.
В других аспектах некоторых вариантов осуществления ведущее устройство содержит контроллер или устройство управления коммуникационной линией связи с задающими устройствами, как описано ниже, постоянно находящимися в портативном электронном устройстве, таком как беспроводное устройство связи, например беспроводный телефон, беспроводный PDA или портативной компьютер. Типичное клиентское устройство в этой конфигурации содержит клиентскую схему, или интегральную схему, или модуль, подсоединенный к ведущему устройству и постоянно находящийся в одном и том же устройстве и к внутреннему видеодисплею, например экрану с высоким разрешением для мобильного телефона, и/или портативной системе представления аудио, или, альтернативно, системе или устройству ввода некоторого типа.
Краткое описание чертежей
Дополнительные признаки и преимущества, а также структура и работа различных вариантов осуществления изобретения описаны подробно ниже со ссылками на сопроводительные чертежи. На чертежах аналогичные ссылочные позиции обычно указывают идентичные, функционально подобные и/или структурно подобные элементы или этапы обработки.
Фиг.1A иллюстрирует основную среду, в которой варианты осуществления изобретения могут работать, включая использование устройства микроотображения, или проектора, вместе с портативным компьютером или другим устройством обработки данных.
Фиг.1B - основную среду, в которой варианты осуществления изобретения могут работать, включая использование устройства микроотображения или проектора и элементов аудиопредставления, используемых вместе с беспроводным приемопередатчиком.
Фиг.2A - основную среду, в которой варианты осуществления изобретения могут работать, включая использование внутреннего дисплея или устройств представления аудио, используемых в портативном компьютере.
Фиг.2B - основную среду, в которой варианты осуществления изобретения могут работать, включая использование внутреннего дисплея или элементов представления аудио, используемых в беспроводном приемопередатчике.
Фиг.3 - общую концепцию MDDI с обменом или соединением ведущего устройства и клиента.
Фиг.4 - структуру пакета, полезного для реализации передач данных с клиентского устройства на ведущее устройство.
Фиг.5 - использование контроллера линии связи MDDI и типы сигналов, передаваемых между ведущим устройством и клиентом по физическим проводникам линии передачи данных для интерфейса Типа 1.
Фиг.6 - использование контроллера линии связи MDDI и типы сигналов, передаваемых между ведущим устройством и клиентом по физическим проводникам линии передачи данных для интерфейсов Типов 2, 3 и 4.
Фиг.7 - структуру кадров и под-кадров, используемых для осуществления протокола интерфейса.
Фиг.8 - общую структуру пакетов, используемых для осуществления протокола интерфейса.
Фиг.9 - формат пакета "Заголовок под-кадра".
Фиг.10 - формат и содержание пакета «Заполнитель».
Фиг.11 - формат пакета «Поток видео».
ФИГ. 12A-12E иллюстрируют формат и содержание для «Дескриптора формата видеоданных», используемого на Фиг.11.
Фиг.13 иллюстрирует использование упакованных и распакованных форматов для данных.
Фиг.14 - формат пакета «Поток аудио».
Фиг.15 - использование выровненных по границе байтов и упакованных форматов PCM для данных.
Фиг.16 - формат пакета «Определяемый пользователем поток».
Фиг.17 - формат пакета «Карта цвета».
Фиг.18 - формат пакета «Инкапсуляция обратной линии связи».
Фиг.19 - формат пакета «Возможности пользователя».
Фиг.20 - формат пакета «Данные клавиатуры».
Фиг.21 - формат пакета «Данные устройства указания».
Фиг.22 - формат пакета «Завершение работы линии связи».
Фиг.23 - формат пакета «Запрос клиента и состояния».
Фиг.24A - формат пакета «Поблочная пересылка битовой карты».
Фиг.24B - последовательность операций примерной растровой операции, полезной для осуществления вариантов осуществления изобретения.
Фиг.25 - формат пакета «Заполнитель области битовой карты».
Фиг.26 - формат пакета «Заполнитель шаблона битовой карты».
Фиг.27 - формат пакета «Буфер считывания кадра».
Фиг.28 - формат пакета «Состояние управления питанием дисплея».
Фиг.29 - формат пакета «Выполнение передачи обслуживания в режим определенного типа».
Фиг.30 - формат пакета «Разрешение прямого канала аудио».
Фиг.31 - формат пакета «Частота выборки аудио обратной линии связи».
Фиг.32 - формат пакета «Служебные данные цифровой защиты контента».
Фиг.33 - формат пакета «Установка прозрачного цвета и маски».
Фиг.34 - формат пакета «Измерение задержки прохождения сигнала в прямом и обратном направлениях».
ФИГ.35 - временную диаграмму событий для пакета «Измерение задержки прохождения сигнала в прямом и обратном направлениях».
Фиг.36 - типовое выполнение генератора кода CRC и устройства проверки, полезного для осуществления изобретения.
Фиг.37A - временную диаграмму сигналов кода CRC для устройства согласно Фиг.36 при посылке пакетов данных.
Фиг.37B - временную диаграмму сигналов кода CRC для устройства согласно Фиг.36 при приеме пакетов данных.
Фиг. 38A и 38B иллюстрируют примерное поведение специального маломощного дифференциального приемника по сравнению со стандартным дифференциальным приемником.
Фиг.39A иллюстрирует этапы обработки для типичного запроса на обслуживание без состязаний.
Фиг.39B - этапы обработки для типичного запроса на обслуживание, выданного после того, как началась последовательность рестарта линии связи, состязающаяся со стартом линии связи.
Пример этапов обработки для типичного события 3800 запроса на обслуживание клиента без состязаний иллюстрируется на Фиг.39A.
Аналогичный пример проиллюстрирован на Фиг.39B, где запрос на обслуживание выдан после того, как началась последовательность рестарта линии связи, и события помечены заново.
Фиг.40 иллюстрирует, как последовательность данных может быть передана, используя кодирование DATA-STB.
Фиг.41 - схему, полезную для формирования сигналов DATA и STB из входных данных в ведущем устройстве и затем восстановления данных на клиенте.
Фиг.42A - задающие устройства и устройства-терминаторы для передачи сигналов, полезных для осуществления одного варианта осуществления.
Фиг.42B - блок-схему задающего устройства в режиме с дифференциальными токами.
Фиг. 43A-43C иллюстрируют этапы и уровни сигналов, используемых клиентом, чтобы обеспечить защиту услуги от ведущего устройства и ведущим устройством, чтобы предоставить такую услугу.
Фиг.44 иллюстрирует относительные интервалы между переходами на линиях Data0, других линиях данных (DataX) и линиях Стробирования (Stb).
Фиг.45 - присутствие задержки в ответе, которая может происходить, когда ведущее устройство отключает задающее устройство ведущего устройства после передачи пакета.
Фиг.46 - присутствие задержки в ответе, которая может происходить, когда ведущее устройство разрешает задающему устройству ведущего устройства передавать пакет.
Фиг.47 - анализ токов утечки.
Фиг.48 - характеристики переключения и относительные временные зависимости для времени разрешения и запрещения выходного сигнала ведущего и клиентского устройств.
Фиг.49 - укрупненную диаграмму этапов обработки сигналов и состояний, посредством которых может быть осуществлена синхронизация, используя конечный автомат.
Фиг.50 - типичные значения задержки, которые имеют место при обработке сигналов на прямом и обратном трактах в системе, использующей MDDI.
Фиг.51 - измерение предельной задержки прохождения сигнала в прямом и обратном направлениях.
Фиг.52A - изменения скорости передачи данных по обратной линии связи.
Фиг.52B - пример усовершенствованной выборки данных обратной линии связи.
Фиг.53 - графическое представление значений делителя скорости передачи по обратной линии связи в зависимости от скорости передачи данных по прямой линии связи.
Фиг. 54A и 54B иллюстрируют этапы, предпринимаемые в работе интерфейса.
Фиг.55 иллюстрирует обзор устройства интерфейса, обрабатывающего пакеты.
Фиг.56 - формат пакета прямой линии связи.
Фиг.57 - типичные значения для задержки распространения и сдвига во времени в интерфейсе линии связи Типа 1.
Фиг.58 - сигналы данных (Data), стробирования (Stb) и временную диаграмму восстановления синхронизации на линии связи Типа 1 для примерной обработки сигналов в интерфейсе.
Фиг.59 - типичные значения для задержки распространения и сдвига во времени в интерфейсах линии связи Типа 1, Типа 2, Типа 3 или Типа 4.
Фиг. 60A, 60B и 60C иллюстрируют различные возможности для временной диаграммы двух сигналов данных и MDDI_Stb относительно друг друга, являющихся идеальными, ранними и запаздывающими соответственно.
Фиг.61 иллюстрирует типичную прямую линию связи Типа 2 со схемой компенсации сдвига во времени задержки для примерной обработки сигналов в интерфейсе.
Фиг. 62A и 62B иллюстрируют возможные формы сигналов MDDI_Data и MDDI_Stb для обоих интерфейсов Типа 1 и Типа 2 соответственно.
Фиг.63 иллюстрирует укрупненную диаграмму альтернативных этапов обработки сигналов и состояний, посредством которых может быть осуществлена синхронизация, используя конечный автомат.
Фиг.64 - примерную относительную временную диаграмму между последовательностью тактовых циклов и распределением во времени различных битов пакетов обратной линии связи и значений делителя.
Фиг.65 - примерную обработку передачи кода ошибки.
Фиг.66 - устройство, полезное для обработки передачи кода ошибки.
Фиг.67A - обработку передачи кода ошибки для переопределения кода.
Фиг.67B - обработку передачи кода ошибки для приема кода.
Фиг.68A - этапы обработки для инициированного ведущим устройством "пробуждения".
Фиг.68B - этапы обработки для инициированного клиентом "пробуждения".
Фиг.68C - этапы обработки для инициированного ведущим устройством и клиентом "пробуждения" с состязаниями.
Фиг.69 - формат пакета «Запрос характеристик виртуальной панели управления (VCP)».
Фиг.70 - формат пакета «Ответ с характеристиками VCP».
Фиг.71 - формат «Списка с ответом с характеристиками VCP».
Фиг.72 - формат пакета «Установка характеристик VCP».
Фиг.73 - формат пакета «Запрос действительного параметра».
Фиг.74 - формат пакета «Ответ о действительном параметре».
Фиг.75 - формат пакета «Возможности масштабируемого потока видео».
Фиг.76 - формат пакета «Установка масштабируемого потока видео».
Фиг.77 - формат пакета «Подтверждение масштабируемого потока видео».
Фиг.78 - формат пакета «Масштабируемый поток видео».
Фиг.79 - формат пакета «Запрос конкретного состояния».
Фиг.80 - формат пакета «Список с ответом о действительном состоянии».
Фиг.81 - формат пакета «Возможности персонального дисплея».
Фиг.82 - элементы в «Списке точек кривизны поля».
Фиг.83 - формат пакета «Отчет об ошибках клиента».
Фиг.84 - формат элемента «Списка сообщения об ошибках».
Фиг.85 - формат пакета «Идентификационная информация клиента».
Фиг.86 - формат пакета «Возможности альтернативного дисплея».
Фиг.87 - формат пакета «Доступ к регистру».
Фиг. 88A-88C иллюстрируют использование двух буферов дисплеев, чтобы уменьшить видимые артефакты.
Фиг.89 иллюстрирует два буфера с обновлением дисплея, более быстрым, чем передача изображения.
Фиг.90 - два буфера с обновлением дисплея, более медленным, чем передача изображения.
Фиг.91 - два буфера с обновлением дисплея, намного более быстрым, чем передача изображения.
Фиг.92 - три буфера с обновлением дисплея, более быстрым, чем передача изображения.
Фиг.93 - три буфера с обновлением дисплея, более медленным, чем передача изображения.
Фиг.94 - один буфер с обновлением дисплея, более быстрым, чем передача изображения.
Фиг.95 - соединение ведущее устройство - клиент с использованием последовательного соединения и концентратора.
Фиг.96 - клиентские устройства, соединенные через комбинацию концентраторов и последовательных соединений.
Фиг.97 - карту цвета.
Фиг.98 - использование более одного клиента в конфигурации передачи данных.
Фиг.99 - приложение для использования нагрузок без оконечной нагрузки на линиях передачи с двумя клиентами.
Подробное описание
I. Краткий обзор
Общее назначение изобретения состоит в том, чтобы обеспечить MDDI (цифровой интерфейс мобильной системы передачи данных), как описано ниже, который предоставляет или обеспечивает эффективный по стоимости с малым потреблением энергии механизм передачи, который разрешает высокую или очень высокую скорость передачи данных по коммуникационной линии связи на малых расстояниях между ведущим устройством и клиентским устройством, таким как элемент отображения, используя "последовательный" тип линии или канала связи. Этот механизм применим для реализации с использованием миниатюрных соединителей и тонких гибких кабелей, которые являются особенно полезными в соединениях внутри (внутренней области относительно корпуса или поддерживающей конструкции) дисплея, или элементов, или устройств вывода данных, или устройств ввода данных на центральный контроллер, или коммуникационный элемент, или устройство. Кроме того, этот механизм соединения очень полезен для подсоединения внешних элементов или устройств отображения, например, пригодных для ношения микродисплеев (дисплейные очки или проекторы) или других типов визуальных, слышимых, тактильных (осязательных) устройств представления информации, к портативным компьютерам, устройствам беспроводной связи или устройствам для развлечения.
Хотя термины "мобильный" и "дисплей" ассоциированы с наименованием протокола, должно быть понятно, что это используется только для удобства в терминах наличия стандартного имени, легко понятного для специалистов в данной области техники, работающих с интерфейсом и протоколом. Это относится к стандарту Ассоциации по стандартам в области видеоэлектроники (VESA) и различным применениям этого стандарта. Однако, как очевидно, после рассмотрения обзора вариантов осуществления, представленных ниже, что много приложений, не связанных с мобильностью и с дисплеями, извлекут выгоду из применения этого протокола, реализуя структуру интерфейса или механизм передачи, и обозначение MDDI не предназначено, чтобы подразумевать какие-либо ограничения на характер или полноценность изобретения или его различные варианты осуществления.
Преимущество вариантов осуществления изобретения состоит в том, что обеспечивается методика для передачи данных, которая является низкой по сложности, низкой по стоимости, имеет высокую надежность, приспосабливается хорошо в среде использования и является очень устойчивой (робастной), в то же время сохраняя большую гибкость.
Варианты осуществления изобретения могут использоваться в ряде ситуаций, чтобы выполнять обмен или передавать большие объемы данных, обычно для аудио, видео или мультимедийных приложений от ведущего устройства или устройства-источника, где такие данные генерируются, ими манипулируют, например, для передачи на конкретные устройства, или иначе обрабатывают или сохраняют, пользователю или приемному устройству, такому как видеодисплей или элемент проецирования, аудиодинамики или другое устройство представления с высокой скоростью передачи данных. Типичным применением, которое описано ниже, является передача данных или от портативного компьютера, или от беспроводного телефона, или модема на устройство визуального отображения, например маленький видеоэкран или пригодный для ношения прибор с микродисплеем, например, в форме дисплейных очков или шлемов, содержащих маленькие проекционные линзы и экраны, или от ведущего устройства на клиентское устройство в таких компонентах. То есть от процессора или контроллера к внутреннему экрану или другому элементу представления, а также от различных внутренних или внешних устройств ввода данных, используемых клиентом, к внутренне расположенному (находящемуся в одном и том же корпусе устройства или поддерживающей конструкции) ведущему устройству или соединенному с ним кабелем или проводниками.
Характеристики или атрибуты MDDI являются такими, что они являются независимыми от конкретного дисплея или технологии представления. Это есть высоко гибкий механизм для передачи данных с высокой скоростью передачи данных безотносительно к внутренней структуре этих данных и функциональным аспектам данных или команд, которые он реализует. Это позволяет корректировать синхронизацию передаваемых пакетов данных, чтобы адаптироваться к особенностям конкретных устройств клиента, например, для уникальных требований к отображению для некоторых устройств, или для удовлетворения требований комбинирования аудио и видео для некоторых аудио-визуальных (A-V) систем, или для некоторых устройств ввода данных, таких как джойстики, сенсорные контактные площадки и т.д. Интерфейс является очень агностическим для элемента отображения или клиентского устройства, пока выбранный протокол поддерживается. Кроме того, агрегатированные данные последовательной линии связи или скорость передачи данных могут меняться на более чем на несколько порядков по величине, что позволяет проектировщику системы связи или ведущего устройства оптимизировать требования стоимости, мощности, сложности клиентского устройства и частоту обновления клиентского устройства.
Этот интерфейс данных представлен прежде всего для использования при передаче больших объемов высокоскоростных данных по "проводной" линии связи сигналов или малому кабелю. Однако некоторые применения могут также воспользоваться преимуществом беспроводной линии связи, включая основанные на оптической передаче линии связи, если она сконфигурирована для использования одних и тех же структур пакета и данных, разработанных для этого протокола интерфейса, и могут поддерживать требуемый уровень передачи при достаточно низкой потребляемой мощности или сложности, чтобы оставаться практически реализуемой.
II. Среда
Типичное применение может быть видно на Фиг. 1А и 1B, где портативный или настольный компьютер 100 и беспроводный телефон или устройство 102 PDA (персональный цифровой ассистент, ПЦА) показаны обменивающимися данными с устройствами 104 и 106 отображения соответственно, а также с системами 108 и 112 воспроизведения аудио. Кроме того, Фиг.1A иллюстрирует возможные подсоединения к большему дисплею, или экрану 114, или проектору 116 изображения, которые для ясности показаны только на одном чертеже, но также могут подсоединяться к беспроводному устройству 102. Беспроводное устройство может в настоящее время принимать данные или предварительно хранить некоторое количество данных мультимедийного типа в элементе или устройстве памяти для более позднего представления для просмотра и/или прослушивания конечным пользователем беспроводного устройства. Так как типичное беспроводное устройство большую часть времени используется для речевого и простого текстового обмена, оно имеет довольно маленький экран дисплея и простую аудиосистему (динамики) для передачи информации на устройство 102 пользователя.
Компьютер 100 имеет намного больший экран, но все еще неадекватную внешнюю аудиосистему, и все еще не соответствует другим мультимедийным устройствам представления, например телевидению повышенной четкости или киноэкрану. Компьютер 100 используется с целью иллюстрации, и совместно с настоящим изобретением могут также использоваться другие типы процессоров, интерактивных видеоигр или устройств бытовой электроники. Компьютер 100 может использовать, но не ограничивается ими, беспроводный модем или другое встроенное устройство для беспроводной связи, или быть связанным с такими устройствами, используя кабель или беспроводную линию, как требуется.
Это делает представление более сложных или "богатых" данных менее удобными или приятными для восприятия. Поэтому промышленность разрабатывает другие механизмы и устройства, чтобы представить информацию конечным пользователям и обеспечить минимальный уровень желаемого удовольствия или положительного восприятия.
Как предварительно описано выше, несколько типов устройств отображения имеются или развиваются в настоящее время для представления информации конечным пользователям устройства 100. Например, одна или более компаний разработали наборы пригодных для ношения дисплейных очков, которые проецируют изображение перед глазами пользователя устройства, чтобы представлять визуальное отображение. При правильной установке такие устройства эффективно "проецируют" виртуальное изображение, как оно воспринимается глазами пользователя, которое является намного большим, чем элемент, обеспечивающий визуальный выход. То есть очень маленький проекционный элемент позволяет глазу(ам) пользователя "видеть" изображения в намного большем масштабе, чем это возможно с обычным дисплеем на жидких кристаллах (ЖК, LCD) и т.п. Использование больших виртуальных отображаемых изображений также позволяет использовать изображения с намного более высоким разрешением, чем это возможно с более ограниченными дисплеями с LCD экраном. Другие устройства отображения могут включать в себя, но не ограничиваются ими, маленькие LCD экраны или различные плоскопанельные элементы отображения, проецирующие линзы и задающие устройства дисплея для проецирования изображений на поверхность и т.д.
Могут также присутствовать дополнительные элементы, связанные с или ассоциированные с использованием беспроводного устройства 102 или компьютера 100, для представления выходного сигнала другому пользователю или на другое устройство, которое в свою очередь передает сигналы в другое место или сохраняет их. Например, данные могут быть сохранены во флэш-памяти, в оптической форме, например используя записываемые CD-носители, или на магнитных носителях, таких как в видеомагнитофоне и подобных устройствах, для последующего использования.
Кроме того, многие беспроводные устройства и компьютеры теперь имеют встроенные функциональные возможности (элементы) декодирования MP3 музыки, а также другие усовершенствованные звуковые декодеры и системы. Портативные компьютеры используют функциональные возможности воспроизведения CD и DVD по общему правилу, и некоторые имеют малые специализированные считывающие устройства флэш-памяти для приема заранее записанных аудиофайлов. Проблема с наличием таких возможностей заключается в том, что цифровые музыкальные файлы обещают особенно богатое восприятие, но только если декодирование и процесс воспроизведения могут поддерживать скорость. То же самое остается справедливым для цифровых видеофайлов.
Чтобы способствовать звуковому воспроизведению, внешние динамики 114 иллюстрируются на Фиг.1А, которые могут также дополняться дополнительными элементами, например саб-вуферными громкоговорителями, или динамиками "окружающего звука" для переднего и заднего проецирования звука. В то же время динамики или наушники 108 показаны как встроенные для поддерживающей конструкции или механизма устройства 106 микроотображения на Фиг.1B. Как может быть известно, могут использоваться другие элементы воспроизведения аудио или звука, включая устройства усиления мощности или формирования звука.
В любом случае, как описано выше, когда кто-то желает передавать высококачественные или с высоким разрешением данные изображения и высококачественную звуковую информацию или сигналы данных от источника данных до конечного пользователя по одной или более коммуникационным линиям 110 связи, требуется высокая скорость передачи данных. То есть линия 110 передачи является явным потенциально узким местом при обмене данных, как описано ранее, и ограничивает эффективность системы, так как современные механизмы передачи не достигают обычно желательных высоких скоростей передачи данных. Как описано выше, например, для изображений с более высокими значениями разрешения, такими как 1024×1024 пикселей с глубиной цвета 24-32 бит на пиксель, и при скоростях передачи данных 30 кадров/с скорости передачи данных могут достигать значений 755 Мбит/с или больше. Кроме того, такие изображения могут быть представлены как часть мультимедийного представления, которое включает в себя аудиоданные и, возможно, дополнительные сигналы, относящиеся к интерактивной игре или обменам, или различные команды, средства управления или сигналы, еще более увеличивая количество или данные и скорость передачи данных.
Также ясно, что меньшее количество кабелей или межсоединений, требуемых для установления канала связи, означает, что мобильные устройства, связанные с дисплеем, являются более легкими для использования, и более вероятно, что будут приняты большим количеством пользователей. Это особенно верно для случая, когда обычно используется множество устройств для установления полного аудиовизуального восприятия и, более того, уровень качества дисплеев и устройств вывода аудио повышается.
Другое типичное применение, относящееся ко многим из вышеупомянутых и других усовершенствований видеоэкранов и других устройств вывода или ввода данных, может быть видно из Фиг. 1C и 1D, где иллюстрируются портативный или настольный компьютер 130 и беспроводный телефон или устройство 140, обменивающиеся данными с "внутренними" устройствами 134 и 144 отображения соответственно, наряду с системами 136 и 146 воспроизведения аудио.
На Фиг. 2A и 2B используются маленькие, размером с визитку, части полных электронных устройств или продуктов, чтобы показать расположение одного или более внутренних ведущих устройств и контроллеров в одной части устройства с обобщенной линией связи, здесь 138 и 148 соответственно, подсоединяющие их к элементам видеоотображения или экранам, имеющим соответствующих клиентов, относительно вращающегося соединения некоторого известного типа, сегодня повсюду используемого в промышленности электроники. Можно видеть, что количество данных, включенных в эти передачи, требует большого количества проводников, чтобы содержать линии 138 и 148 связи. Очевидно, что такие коммуникационные линии связи содержат приблизительно 90 или более проводников, чтобы удовлетворить сегодняшние потребности роста при использовании усовершенствованных цветных и графических интерфейсов, элементов отображения на таких устройствах из-за наличия параллельных или других известных методов взаимодействия, доступных для передачи таких данных.
К сожалению, более высокие скорости передачи данных превышают сегодняшнюю технологию, доступную для передачи данных. И в терминах необработанного количества данных, которые должны быть переданы в единицу времени, и в терминах изготовления надежных, эффективных по стоимости физических механизмов передачи.
Необходима методика, структура, средства или способ для передачи данных на более высоких скоростях для линии передачи данных или коммуникационного тракта между элементами представления и источником данных, которые единообразно применяют (более) низкую потребляемую мощность, более легкий вес и настолько простую и экономичную структуру соединений, насколько возможно. Заявители разработали новую методику, или способ и устройство, для достижения этих и других целей, чтобы позволить массе мобильных, портативных или даже стационарно расположенных устройств передавать данные к желаемым дисплеям, микродисплеям или элементам передачи аудио на очень высоких скоростях передачи данных, в то же время обеспечивая потребление желательно малой мощности и имеющие малую сложность.
III. Архитектура интерфейсной системы высокоскоростной передачи цифровых данных
Чтобы создать и эффективно использовать новый интерфейс, была сформулирована архитектура системы и протокола передачи сигнала, которая обеспечивает очень высокую скорость передачи данных, используя сигналы малой мощности. Протокол основан на пакетной и структуре общего кадра, или структурах, связанных вместе, чтобы сформировать протокол для выполнения обмена набора предварительно выбранных данных или типов данных, наряду с командной или операционной структурой, наложенной на интерфейс.
A. Краткий обзор
Устройства, соединенные или обменивающиеся по линии связи MDDI, называются ведущим устройством и клиентом, причем клиентом обычно является устройство отображения некоторого типа, хотя рассматриваются и другие устройства вывода и ввода данных. Данные с ведущего устройства на дисплей передают в прямом направлении (называемом как прямой трафик или прямая линия связи), а данные от клиента к ведущим устройствам передаются в обратном направлении (обратный трафик или обратная линия связи), когда разрешается ведущим устройством. Это проиллюстрировано в основной конфигурации, показанной на Фиг.3. На Фиг.3 ведущее устройство 202 соединено с клиентом 204, используя двунаправленный канал 206 связи, который иллюстрируется как содержащий прямую линию 208 связи и обратную линию 210 связи. Однако эти каналы сформированы обычным набором проводников, передача данных по которым эффективно переключается между операциями прямой или обратной линий связи. Это позволяет использовать значительно меньшее количество проводников, немедленно решая одну из многих проблем, с которыми встречаются в текущих подходах к высокоскоростной передаче данных в средах малой мощности, таких как мобильные электронные устройства.
Как описано в настоящем описании, ведущее устройство содержит одно из нескольких типов устройств, которые могут извлекать выгоду из использования настоящего изобретения. Например, ведущее устройство 202 может быть портативным компьютером в форме карманного компьютера, ноутбука или подобного мобильного компьютера. Им также может быть PDA, пейджинговое устройство или один из многих беспроводных телефонов или модемов. Альтернативно, ведущее устройство 202 может быть портативным устройством для развлечения или презентации, таким как портативный DVD или CD плеер или игровое устройство.
Кроме того, ведущее устройство может постоянно находиться как ведущее устройство или управляющий элемент в ряде других широко используемых или планируемых коммерческих продуктах, для которых желателен высокоскоростной обмен по линии связи с клиентом. Например, ведущее устройство может использоваться для передачи данных с высокой скоростью от устройства видеозаписи к клиенту, основанному на устройстве хранения для улучшенного ответного действия, или к большему экрану с высоким разрешением для презентаций. Бытовой электроприбор, такой как холодильник, который содержит встроенную или вычислительную систему и/или Bluetooth-соединения к другим домашним устройствам, может улучшать возможности отображения при работе в режиме соединения с Интернет или Bluetooth или иметь уменьшенные потребности в проводах во встроенных в дверь дисплеях (клиент) и вспомогательных клавиатурах или сканерах (клиент), в то время как электронный компьютер или системы управления (ведущее устройство) постоянно находятся в другом месте в корпусе. Вообще, специалистам в данной области техники очевидно широкое разнообразие современных электронных устройств и бытовых электроприборов, которые могут быть выгодно применены при использовании этого интерфейса, так же как и способность модифицировать более старые устройства более высокой скоростью передачи данных информации, используя ограниченное количество проводников, доступных или в недавно добавленных или в существующих соединителях или кабелях.
В то же самое время клиент 204 может содержать разнообразные устройства, необходимые для представления информации конечному пользователю или представления информации от пользователя на ведущее устройство. Например, микродисплей, встроенный в дисплейные очки или очки, устройство проецирования, встроенное в шляпу или шлем, маленький экран или даже голографический элемент, встроенный в транспортное средство, например, в окне или ветровом стекле, или различные динамики, наушники, или звуковые системы для представления звука высокого качества или музыки. Другие устройства представления включают в себя проекторы или устройства проецирования, используемые для представления информации для собраний или для кино- и телевизионных изображений. Другим примером может быть использование сенсорных контактных площадок или сенсорных устройств, устройств ввода распознавания голоса, сканеров защиты и т.д., которые могут быть призваны передавать существенное количество информации от пользователя устройства или системы с небольшим фактическим "вводом", отличным от касания или звука от пользователя. Кроме того, установочные (docking) станции для компьютеров и автомобильные комплекты или настольные комплекты и держатели для беспроводных телефонов могут действовать как интерфейсные устройства к конечным пользователям или к другим устройствам и оборудованию, и использовать или клиентов (устройства вывода или ввода данных, например мышь), или ведущие устройства, чтобы помочь в передаче данных, особенно когда используются высокоскоростные сети.
Однако специалисты в данной области техники легко поймут, что настоящее изобретение не ограничено этими устройствами, что существует много других устройств на рынке и предложено для использования, которые предназначены для обеспечения конечных пользователей изображениями и звуком высокого качества, или в смысле хранения и передачи, или в терминах представления при воспроизведении. Настоящее изобретение является полезным при увеличении пропускной способности данных между различными элементами или устройствами, чтобы использовать высокие скорости передачи данных, необходимые для реализации требуемого восприятия пользователя.
Предлагаемый MDDI и протокол сигнала связи могут использоваться, чтобы упростить межсоединение между ведущим процессором, контроллером или схемным компонентом (например), и дисплеем в пределах устройства или корпуса устройства или структуры (называемое как внутренний режим), чтобы уменьшить стоимость или сложность и связанные с этим мощность и требования к управлению или ограничения для этих соединений и улучшить надежность не только для подсоединения к или для внешних элементов, устройств или оборудования (называемое как внешний режим).
Совокупная (агрегатированная) скорость передачи данных последовательной линии связи в каждой сигнальной паре, используемой этой интерфейсной структурой, может меняться в пределах многих порядков по величине, что позволяет проектировщику системы или устройства легко оптимизировать стоимость, мощность, сложность реализации и скорость обновления дисплея для данного применения или цели. Атрибуты MDDI являются независимыми от технологии дисплея или другого устройства представления (целевого клиента). Синхронизация (тактирование) пакетов данных, переданных через интерфейс, может быть легко откорректирована, чтобы адаптироваться к индивидуальным отличительным особенностям конкретных клиентов, таких как устройства отображения, звуковые системы, запоминающие устройства и элементы управления, или объединенных требованиями синхронизации аудио-видео систем. Хотя это дает возможность иметь систему с очень маленькой потребляемой мощностью, не является требованием различных клиентов иметь буферы кадров, чтобы использовать протокол MDDI по меньшей мере на некотором уровне.
B. Типы интерфейса
MDDI рассматривается как адресующий по меньшей мере четыре, а возможно и больше, немного отличающихся физических типов интерфейсов, применяемых в отраслях промышленности связи и компьютеров. Они обозначены просто как Тип 1, Тип 2, Тип 3 и Тип 4, хотя другие метки или обозначения могут применяться специалистами в данной области техники в зависимости от конкретных приложений, для которых они используются, или промышленности, с которой они связаны. Например, простые аудиосистемы используют меньшее количество соединений, чем более сложные мультимедийные системы, и могут ссылаться на особенности, такие как "каналы", по-разному и т.д.
Интерфейс Типа 1 сконфигурирован как имеющий 6 проводов или проводников или проводящих элементов другого типа интерфейс, что делает его подходящим для мобильных или беспроводных телефонов, PDA, электронных игр и портативных медиаплееров, например CD-плееров или MP3-плееров, и аналогичных устройств или устройств, используемых на аналогичных типах технологии потребительской электроники. В одном варианте осуществления интерфейс может быть сконфигурирован как 8-проводной (с проводниками) интерфейс, который является более подходящим для ноутбука, портативного компьютера или настольных персональных компьютеров и аналогичных устройств или приложений, не требующих быстрых обновлений данных и которые не имеют встроенного контроллера линии связи MDDI. Этот тип интерфейса также отличается использованием дополнительного двухпроводного интерфейса Универсальной Последовательной Шины (USB), который является чрезвычайно полезным в существующих операционных системах или средствах программной поддержки, имеющихся на большинстве персональных компьютеров.
Интерфейсы Типа 2, Типа 3 и Типа 4 являются подходящими для высокопроизводительных клиентов или устройств и используют более сложные кабельные соединения с дополнительными проводниками типа витой пары, чтобы обеспечить соответствующее экранирование и передачи с низкими потерями для сигналов данных.
Интерфейс Типа 1 пропускает сигналы, которые могут содержать информацию отображения, аудио, управления и ограниченную информацию сигнализации, и обычно используется для мобильных клиентов или клиентских устройств, которые не требуют полноскоростных видеоданных с высоким разрешением. Интерфейс Типа 1 может легко поддерживать разрешение (стандарта SVGA) с 30 кадрами/с плюс 5.1 канальное аудио и в минимальной конфигурации может использовать всего только три проводных пары, две пары - для передачи данных и одну пару - для обеспечения питания. Этот тип интерфейса предназначен прежде всего для устройств, таких как мобильные беспроводные устройства, где ведущее устройство USB обычно не доступно в пределах такого устройства для соединения и передачи сигналов. В этой конфигурации мобильное беспроводное устройство является ведущим устройством MDDI и выступает как "основное" (master), которое управляет коммуникационной линией связи от ведущего устройства, которое обычно посылает данные пользователю (прямой трафик или прямая линия связи) для представления, отображения или воспроизведения.
В этом интерфейсе ведущее устройство разрешает прием данных обмена в ведущем устройстве от клиента (обратный трафик или обратная линия связи) посредством посылки специальной команды или типа пакета клиенту, который позволяет ему занимать шину (линию связи) в течение заданной длительности и посылать данные на ведущее устройство в качестве пакетов обратной линии связи. Это иллюстрируется на Фиг.4, где используется тип пакета, называемый как пакет инкапсуляции (описанный ниже), чтобы разместить в себе пакеты обратной линии связи по линии передачи, создавая обратную линию связи. Интервал времени, распределенный для ведущего устройства, чтобы опрашивать в определенном порядке клиентов о наличии данных, заранее определен ведущим устройством и основан на требованиях каждого конкретного приложения. Этот тип полудуплексной двунаправленной передачи данных особенно выгоден, когда USB-порт не доступен для передачи информации или данных от клиента.
Высокопроизводительные дисплеи, способные обеспечивать тип HDTV или аналогичные значения высокого разрешения, требуют потоков данных со скоростью передачи приблизительно 1,5 Гбит/с, чтобы поддерживать полномасштабное видео. Интерфейс Типа 2 поддерживает высокие скорости передачи данных, передавая 2 бита параллельно, Тип 3 - передавая 4 бита параллельно, и интерфейс Типа 4 передает 8 битов параллельно. Интерфейсы Типа 2 и Типа 3 используют тот же кабель и соединитель, что и Тип 1, но могут работать на удвоенной и учетверенной скорости передачи данных, чтобы поддерживать высокопроизводительные приложения видео на портативных устройствах. Интерфейс Типа 4 подходит для очень высокопроизводительных клиентов или дисплеев и требует немного больше кабельных соединений, которые содержат дополнительные сигналы данных витой пары.
Протокол, используемый MDDI, позволяет каждому ведущему устройству Типа 1, 2, 3 или 4 обычно обмениваться с любым клиентом Типа 1, 2, 3 или 4 посредством согласования - какова самая высокая возможная скорость передачи данных, которая может использоваться. Эти возможности или доступные характеристики того, что может быть названо как устройство с наименьшими функциональными возможностями, используются, чтобы установить производительность линии связи. Как правило, даже для систем, где ведущее устройство и клиент оба способны использовать интерфейс Типа 2, Типа 3 или Типа 4, оба начинают работу как интерфейс Типа 1. Ведущее устройство затем определяет производительность целевого клиента и согласовывает передачу обслуживания или операцию реконфигурации с режимом или Типа 2, Типа 3 или Типа 4 как соответствующим конкретному приложению.
Обычно для ведущего устройства возможно использовать надлежащий протокол уровня линии связи (описанный дополнительно ниже) и понижать, или заново реконфигурировать, работу обычно в любое время к более медленному режиму, чтобы сохранить мощность, или перейти к более быстрому режиму, чтобы поддержать более высокие скорости передачи, например, для контента дисплея с более высоким разрешением. Например, ведущее устройство может изменять типы интерфейса, когда система переключается от источника питания, такого как батарея, к источнику питания переменного тока, или когда источник отображения аудиовизуальной информации переключается к формату с более низким или более высоким разрешением, или их комбинации, или другие условия или события могут рассматриваться как основание для изменения типа интерфейса или режима передачи.
Также возможно для системы обмениваться данными, используя один режим в одном направлении и другой режим в другом направлении. Например, режим интерфейса Типа 4 может использоваться, чтобы передавать данные на дисплей с высокой скоростью передачи данных, в то время как режим Типа 1 используется при передаче данных на ведущее устройство от периферийных устройств, таких как клавиатура или устройство указания. Специалисту данной области техники очевидно, что ведущие устройства и клиенты могут обмениваться исходящими данными на различных скоростях передачи.
Часто пользователи протокола MDDI могут различаться между "внешним" режимом и "внутренним" режимом. Внешний режим описывает использование протокола и интерфейса для подключения ведущего устройства в одном устройстве к клиенту вне этого устройства, которое находится вплоть до приблизительно 2 метров или около этого от ведущего устройства. В этой ситуации ведущее устройство может также посылать энергию внешнему пользователю так, чтобы оба устройства могли легко работать в мобильной среде. Внутренний режим описывает, когда ведущее устройство соединено с клиентом, содержащимся внутри одного и того же устройства, например, в пределах общего корпуса или поддерживающей конструкции или структуры некоторого вида. Примером могут быть приложения в пределах беспроводного телефона, или другого беспроводного устройства, или портативного компьютера, или игрового устройства, где клиентом является дисплей, или задающее устройство дисплея, или устройство ввода данных, такое как вспомогательная клавиатура, или сенсорная контактная площадка, или звуковая система, а ведущим устройством является центральный контроллер, графическая система или элемент центрального процессора (ЦПУ). Так как клиент расположен намного ближе к ведущему устройству в приложениях для внутреннего режима в противоположность приложениям для внешнего режима, обычно не имеется никаких требований, описываемых для передачи энергии к пользователю в таких конфигурациях.
C. Физическая структура интерфейса
Общее расположение устройства или контроллера линии связи для установления связи между ведущим и клиентским устройствами показано на Фиг. 5 и 6. На Фиг. 5 и 6 контроллер 402 и 502 линии связи с MDDI показан установленным в ведущем устройстве 202, а контроллер 404 и 504 линии связи с MDDI показан установленным в клиентском устройстве 204. Как и прежде, ведущее устройство 202 соединено с клиентом 204 с использованием двунаправленного канала 406 связи, содержащего набор проводников. Как описано ниже, контроллеры линии связи и ведущего устройства и клиента могут быть изготовлены как интегральные схемы, используя единую схемную структуру, которая может быть установлена, настроена или запрограммирована, чтобы отвечать или как контроллер ведущего устройства (задающее устройство), или контроллер клиента (приемник). Это обеспечивает более низкие затраты при большем масштабе производства отдельного схемного устройства.
На Фиг.6 контроллер 502 линии связи с MDDI показан установленным в ведущем устройстве 202', а контроллер 504 линии связи с MDDI показан установленным в клиентском устройстве 204'. Как и прежде, ведущее устройство 202' соединено с клиентом 204' с использованием двунаправленного канала 506 связи, содержащим набор проводников. Как описано выше, контроллеры линии связи и ведущего устройства и клиента могут быть изготовлены с использованием единой схемной структуры.
Сигналы, проходящие между ведущим устройством и клиентом, например устройством отображения, по используемым линиям связи с MDDI или физическим проводникам, также проиллюстрированы на Фиг. 5 и 6. Как видно на Фиг. 5 и 6, первичный тракт или механизм для передачи данных через MDDI использует сигналы данных, обозначенные как MDDI_Data0+/- и MDDI_Stb+/-. Каждый из них является сигналом данных низкого напряжения, которые передаются по дифференциальной паре проводов в кабеле. Имеется только один переход или на паре MDDI_Data0 или паре MDDI_Stb для каждого бита, посланного через интерфейс. Это является механизмом передачи, основанным на напряжении, а не основанным на токе, так что потребляемый ток в статике является почти нулевым. Ведущее устройство выдает сигналы MDDI_Stb на дисплей клиента.
В то время как данные могут передаваться в обоих - прямом и обратном - направлениях по парам MDDI_Data, то есть это является двунаправленным трактом передачи, ведущее устройство является основным (master) или контроллером канала связи. Тракты передачи сигналов MDDI_Data0 и MDDI-Stb используются в дифференциальном режиме, чтобы максимизировать помехоустойчивость. Скорость передачи данных для сигналов на этих линиях связи определяется частотой сигнала синхронизации, посланного ведущим устройством, и является изменяемым в диапазоне от приблизительно 1 кбит/с до 400 Мбит/с или более.
Интерфейс Типа 2 содержит одну дополнительную пару данных или проводников, или трактов, кроме таковых в интерфейсе Типа 1, называемых как MDDI_Data1+/-. Интерфейс Типа 3 содержит две дополнительных пары данных, или трактов передачи сигналов, кроме таковых в интерфейсе Типа 2, называемых как MDDI_Data2+/- и MDDI_Data3+/-. Интерфейс Типа 4 содержит еще четыре пары данных или трактов передачи сигналов, кроме таковых в интерфейсе Типа 3, называемых как MDDI_Data4+/-, MDDI_Data5+/-, MDDI_Data6+/- и MDDI_Data7+/- соответственно. В каждой из вышеупомянутых конфигураций интерфейса ведущее устройство может посылать энергию клиенту или дисплею, используя проводную пару, или сигналы, обозначенные как HOST_Pwr и HOST_Gnd. Как описано дополнительно ниже, передача энергии может также быть приспособлена, если требуется, в некоторых конфигурациях по проводникам MDDI_Data4+/-, MDDI_Data5+/-, MDDI_Data6+/- или MDDI_Data7+/-, когда используется "Тип" интерфейса, который использует меньшее количество проводников, чем доступно или существует для других режимов. Эта передача энергии обычно используется для внешних режимов, обычно не является нужной во внутренних режимах, хотя некоторые приложения могут отличаться.
Суммированная информация о сигналах, передаваемых между ведущим устройством и клиентом (дисплеем) по линии связи MDDI для различных режимов, иллюстрируется в Таблице I ниже, в соответствии с типом интерфейса.
| Таблица I | |||
| Тип 1 HOST_Pwr/Gnd MDDI_Stb+/- MDDI_Data0+/- Необязат.питание Необязат.питание Необязат.питание Необязат.питание |
Тип 2 HOST_Pwr/Gnd MDDI_Stb+/- MDDI_Data0+/- MDDI_Data1+/- Необязат.питание Необязат.питание Необязат.питание Необязат.питание |
Тип 3 HOST_Pwr/Gnd MDDI_Stb+/- MDDI_Data0+/- MDDI_Data1+/- MDDI_Data2+/- MDDI_Data3+/- Необязат.питание Необязат.питание Необязат.питание Необязат.питание |
Тип 4 HOST_Pwr/Gnd MDDI_Stb+/- MDDI_Data0+/- MDDI_Data1+/- MDDI_Data2+/- MDDI_Data3+/- MDDI_Data4+/- MDDI_Data5+/- MDDI_Data6+/- MDDI_Data7+/- |
Также следует заметить, что соединения HOST_Pwr/Gnd для передачи от ведущего устройства обеспечиваются обычно для внешних режимов. Внутренние приложения или режимы работы обычно имеют клиентов, которые используют энергию непосредственно от других внутренних ресурсов, и не используют MDDI для управления распределением питания, как может быть очевидно специалистам в данной области техники, так что такое распределение ниже более подробно не описывается. Однако, конечно, возможно позволить распределять энергию через MDDI, чтобы учесть некоторые виды регулирования мощности, синхронизации или удобства межсоединений, например, как может быть понятно специалисту данной области техники.
Кабельное соединение, обычно используемое для осуществления вышеупомянутой структуры и работы, номинально составляет порядка 1,5 метров в длину, обычно 2 метра или меньше, и содержит три витых пары проводников многожильного провода. Хотя размер провода не ограничивается конкретным размером, электрические спецификации или ограничения должны быть удовлетворены в смысле максимального полного "сквозного" сопротивления, максимальной емкости на фут, полного сопротивления (импеданса) каждой пары и перекрестных помех.
Охватывающий экран из фольги оборачивают или иначе формируют вокруг всего набора или группы, здесь из трех, витых пар и провода утечки в качестве дополнительного провода утечки. Витые пары и экранирующий проводник утечки (экран) заканчиваются в соединителе клиента, при этом экран соединен с экраном для клиента, и имеется изолирующий слой, покрывающий весь кабель, как известно в данной области техники. Провода объединены в пары: HOST_Gnd с HOST_Pwr; MDDI_Stb+ с MDDI_Stb-; MDDI_Data0+ с MDDI_Data0-; MDDI_Data1+ с MDDI_Data1- и т.д. Однако множество проводников и соединений могут использоваться, как понятно специалисту в данной области техники, чтобы реализовать варианты осуществления изобретения в зависимости от конкретных приложений. Например, более тяжелые внешние покрытия или даже металлические слои могут использоваться, чтобы защитить кабель в некоторых приложениях, в то время как более тонкие однослойные структуры ленточного типа могут хорошо подходить для других применений.
При использовании во "внутреннем режиме" в качестве внутреннего соединения или межсоединения, режима, устройства, протокола, устройства или способа для передачи данных, как описано дополнительно ниже, возможно, что более одного клиента могут быть соединены с единственным ведущим устройством. Для работы во внутреннем режиме допустимо иметь этот тип конфигурации. Однако в этой ситуации только один клиент может быть конфигурирован или быть способным устанавливать (возбуждать) сигналы для интерфейса MDDI, сигналы MDDI_Data назад на ведущее устройство. В этом случае другой клиент или клиенты могут только действовать в качестве приемника для сигналов от ведущего устройства и не действовать в качестве источника или задающего устройства для сигналов данных MDDI.
Одно из применений для использования множества клиентов с единственным ведущим устройством находится в области панелей видео- или визуального отображения, таких как панелей LCD (ЖК), на беспроводном устройстве, аналогичном портативному телефону. Много таких беспроводных устройств разрабатываются с двумя панелями LCD, причем одна используется в качестве главного или первичного большего дисплея для отображения информации или изображений, и меньшим, используемым для индикации состояния телефона, идентификатора вызывающего абонента, времени дня или других функций, обычно в то время, когда главный или первичный дисплей не находится в использовании, например когда телефон находится в спящем или неактивном режиме, ожидающем вызов, который должен быть направлен на телефон, или альтернативно для пользователя телефона, чтобы активизировать исходящий вызов.
Здесь каждая LCD панель может содержать или быть соединена с клиентом MDDI, который соединен с ведущим устройством MDDI. Главная LCD панель может быть способна посылать пакеты назад на ведущее устройство, а вторичная LCD панель - только принимать пакеты от ведущего устройства. Так как это является применением внутреннего режима, не обязательно, чтобы вторичная панель была способна посылать информацию о своих возможностях или состоянии назад на ведущее устройство, потому что ведущее устройство будет уже знать характеристики клиентских устройств заранее.
Пример использования более одного клиентов в конфигурации передачи данных, в этом случае - двух клиентов, показывается на Фиг.98. На Фиг.98 ведущее устройство 9800 подсоединено посредством проводников, кабелей или шин 9802 и 9804 к клиентам 9806 и 9808 соответственно. Каждая пара MDDI_Data и MDDI_Stb ведет себя так, как описано в другом месте в настоящем описании, и способна использовать описываемый предлагаемый сигнальный протокол, имеющий пакеты и соотношения передачи и механизмы, описанные ниже для передачи данных с высокой скоростью передачи, а также передавать некоторые команды или параметры настройки или запрашивать информацию от клиента для установления возможностей ее представления и т.д. В этом варианте осуществления клиент 9806 связан с, сформирован как часть или находится на, или соединен с устройством LCD дисплея или панелью некоторого типа, которое выступает как "первичная" или главная панель отображения для некоторого типа бытового электроприбора, оборудования или устройства, использующего ведущее устройство или иллюстрированные ведущее устройство и клиенты. Клиент 9808, с другой стороны, сформирован как часть или находящийся на, или соединен с устройством LCD дисплея или панелью некоторого типа, которое действует как "первичная" или главная панель отображения для некоторого устройства, использующего ведущее устройство или иллюстрированные ведущее устройство и клиенты.
Должно быть понятно, что эти два элемента отображения или устройства не должны быть идентичными или быть даже одного и того же типа или природы, что и просто отдельные устройства отображения, для которых использование желательно. Например, они могут быть различными типами LCD панелей или могут быть элементами отображения на основе LCD, в то время как другие используют другой тип технологии отображения от электронно-лучевой трубки до биолюминисцентной, как требуется. На Фиг.98 каждый клиент показан обменивающимся по другой шине или набору 9810 и 9812 проводников соответственно, чтобы передавать информацию и/или команды или управляющую информацию или сигналы к соответствующим элементам отображения или панелям. Как указано выше, клиент может быть сформирован как часть схемы, используемой для реализации контроллера 9814 и 9816 панели, или иначе прикреплен к или сформирован как часть схемы, проводников или элементов на или в области панели.
Имеются несколько возможных сценариев для размещения такого клиента на панели, или посредством формирования соответствующих транзисторов для других элементов при формировании схемы или элементов панели, или посредством более позднего присоединения схемного модуля, или такого, который может быть очевиден специалисту в данной области техники. Кроме того, клиент сам по себе и контроллер панели могут быть отдельными элементами в некоторых применениях или могут рассматриваться или сформированы как отдельный модуль или компонент, устройство или элемент интегральной схемы - в других применениях. Пиксели или элементы отображения изображения, установленные в физической матрице в панели, затем формируют то, что названо на чертежах как LCD панель, одна из этих двух панелей выступает как главная или первичная LCD панель, и другая - как вторичная, дополнительная или вспомогательная панель (может быть резервной, если это желательно для избыточности). Поэтому имеются первичный (или главный) и вторичный клиенты. В любой заданный момент времени или период времени только один клиент передает информацию или передает сигналы назад главному компьютеру. В противном случае ведущее устройство точно не знает, что информация исходит от различных клиентов или какой клиент ее формирует. Дополнительные версии протокола могут использовать идентификаторы или идентифицирующие обозначения клиента некоторым способом, чтобы обеспечить более совершенный контроль клиентов или переключение между клиентами, как требуется. Имеются много зарезервированных частей идентификатора в пакетах, как представлено здесь. Как правило, использование, применяемое во вторичных панелях, не требует или использует один и тот же тип обратных сигналов или обмена с ведущим устройством в это время. Однако изобретение не препятствует такому управлению или изменению первичного и вторичного состояния, например, в течение некоторых периодов времени, в ответ на команду, или в режиме отказа, или в аналогичных случаях, как требуется. Кроме того, когда это применяется для внутренних режимов работы, характеристики элементов отображения обычно известны заранее и обмен информацией по обратной линии связи просто не является необходимым со стороны вторичного дисплея, если только он не выбран как новый первичный, в этом случае предыдущий первичный более не используется в этом режиме.
D. Типы данных и скоростей передачи
Чтобы создать полезный интерфейс для всего разнообразия восприятия пользователя и приложений, MDDI обеспечивает поддержку для множества клиентов и информации отображения, аудиопреобразователей, клавиатур, устройств указания и многих других устройств ввода или вывода, которые могут быть интегрированы в или работать совместно с мобильными коммуникациями, вычислением или устройством отображения, наряду с информацией управления и их комбинациями. MDDI сконструирован так, что способен включать в себя ряд потенциальных типов потоков данных, передающихся между ведущим устройством и клиентом по любой из прямой или обратной линий связи, используя минимальное количество кабелей или проводников. Поддерживаются как изохронные потоки, так и асинхронный поток (обновления). Возможны многие комбинации типов данных, пока совокупная (агрегатированная) скорость передачи данных является меньшей чем или равной максимальной требуемой скорости передачи линии связи MDDI, которая ограничена максимальной последовательной скоростью передачи и числом используемых пар данных. Они могут включать в себя, но не ограничиваются ими, те элементы, которые перечислены в Таблицах II и III ниже.
| Таблица II | ||
| Передача от ведущего устройства клиенту | ||
| Изохронные видеоданные | 720×480, 12 бит, 30 кадров/с | ~124,5 Мбит/с |
| Изохронные стерео аудиоданные | 44,1 кГц, 16 бит, стерео | ~1,4 Мбит/с |
| Асинхронные графические данные | 800×600, 12 бит, 10 кадров/с, стерео | ~115,2 Мбит/с |
| Асинхронное управление | Минимальное | <<1,0 Мбит/с |
| Таблица III | ||
| Передача от клиента ведущему устройству | ||
| Изохронные речевые данные | 8 кГц, 8 бит | <<1,0 Мбит/с |
| Изохронные видеоданные | 640×480, 12 бит, 24 кадров/с | ~88,5 Мбит/с |
| Асинхронное состояние, ввод пользователя и т.д. | Минимальное | <<1,0 Мбит/с |
Интерфейс не является фиксированным, но является расширяемым так, чтобы он мог поддерживать передачу множества "типов" информации, которые включают в себя определяемые пользователем данные, для обеспечения гибкости будущей системы. Конкретными примерами данных, которые должны быть размещены (включены), являются полномасштабное видео или в форме полей битовых карт полного или частичного экрана или сжатое видео; статические битовые карты с низкой частотой, чтобы сэкономить энергию и уменьшить затраты на реализацию; ИКМ (кодово-импульсно модулированные) или сжатые аудиоданные, имеющие множество значений разрешения или частот; позиция и выбор устройства указания и определяемые клиентом данные для функциональных возможностей, еще не определенных. Такие данные могут также быть переданы наряду с информацией управления или о состоянии, чтобы определить функциональные возможности устройства или установить операционные параметры.
Варианты осуществления изобретения вносят вклад в уровень техники для использования при передачах данных, которые включают в себя, но не ограничиваются ими, следующее: просмотр кинофильма (отображение видео и аудио); использование персонального компьютера с ограниченным персональным просмотром (графический дисплей, иногда объединяемый с видео и аудио); воспроизведение видеоигры на персональном компьютере, консоли или персональном устройстве (графический дисплей движения или синтетическое видео и аудио); "серфинг" Интернет, использование устройств в форме видеотелефона (двунаправленное видео с низкой скоростью передачи и аудио), фотоаппарат для неподвижных цифровых изображений или видеокамеры для фиксации цифровых видеоизображений; использование телефона, компьютера или PDA, состыкованными с проектором, чтобы обеспечить представление, или состыкованными с настольным стыковочным узлом, соединенным с видеомонитором, клавиатурой и мышью; и для повышения производительности или развлечения, используемых с сотовыми телефонами, "интеллектуальными" телефонами (смартфонами), или PDA, включая беспроводные устройства указания и данные клавиатуры.
Интерфейс высокоскоростной передачи данных, который описан ниже, представлен в терминах обеспечения больших объемов данных A-V типа по коммуникационной линии связи или линии передачи, которая обычно конфигурируется как имеющая тип проводной линии связи или кабельной линии связи. Однако очевидно, что структура сигнала, протоколы, синхронизация или механизм передачи могут быть откорректированы, чтобы обеспечить линию связи в форме оптических или беспроводных носителей, если они могут поддерживать требуемый уровень передачи данных.
Сигналы MDDI используют концепцию, известную как Общая частота кадров (ОЧК, CFR) для основных сигналов или структуры протокола. Идея, лежащая в основе использования Общей частоты кадров, состоит в том, чтобы обеспечить импульс синхронизации для одновременных изохронных потоков данных, посылая Sub-frame Header Packets (пакеты «Заголовок под-кадра») с частотой, которая может быть использована, чтобы получить из нее сигналы синхронизации или сигналы тактирования кадров для множества потоков. Частота, с которой передаются пакеты «Заголовок под-кадра», называется Общей частотой кадров (Common Frame Rate, CFR).
Клиентское устройство может использовать эту Общую частоту кадров как привязку во времени (опорный синхросигнал). Низкая CFR увеличивает производительность канала посредством уменьшения накладных расходов (служебных сигналов) для передачи подзаголовка под-кадра. С другой стороны, высокая CFR уменьшает время ожидания и позволяет использовать менее гибкий буфер данных для выборок аудио. CFR в настоящем предлагаемом интерфейсе является динамически программируемой и может быть установлена равной одному из многих значений, которые являются подходящими для изохронных потоков, используемых в конкретном приложении. То есть значение CFR выбрано так, чтобы наилучшим образом подходить данному клиенту и конфигурации ведущего устройства, как требуется.
Число байтов, обычно требуемых в расчете на под-кадр, которое является настраиваемым или программируемым, для изохронных потоков данных, которые наиболее вероятно должны использоваться с приложением, например, для видео- или микродисплея, иллюстрируются в Таблице IV.
| Таблица IV | |||||||
| Общая частота кадров (CFR) = 300 Гц | |||||||
| X | Y | Бит | Частота кадров | Канал | Скорость передачи (Мбит/с) | Байтов/ под-кадр |
|
| Компьютерная игра | 720 | 480 | 24 | 30 | 1 | 248,832 | 103680 |
| Компьютерная графика | 800 | 600 | 24 | 10 | 1 | 115,200 | 48000 |
| Видео | 640 | 480 | 12 | 29,97 или 30 | 1 | 221,184 | 92160 |
| CD-аудио | 1 | 1 | 16 | 44100 | 2 | 1,4112 | 588 |
| Речь | 1 | 1 | 8 | 8000 | 1 | 0,064 | 26-2/3 |
Дробные значения подсчета байтов в расчете на под-кадр легко получаются, используя простую программируемую структуру счетчика M/N. Например, значение количества байтов 26-2/3 на под-кадр получают, передавая 2 под-кадра, содержащие 27 байт каждый, с последующим одним под-кадром, содержащим 26 байт. Меньшая CFR может быть выбрана, чтобы получить целое число байтов на под-кадр. Однако, вообще говоря, для реализации простого счетчика M/N аппаратными средствами должна требоваться меньшая область на кристалле интегральной схемы или электронном модуле, используемом для осуществления части или всех вариантов осуществления изобретения, чем область, необходимая для большего буфера FIFO (первый пришел - первый ушел) для выборки аудио.
Примерным применением, которое иллюстрирует влияние различных частот передачи данных и типов данных, является система караоке. В караоке системе конечный пользователь, или пользователи, поет одновременно с музыкальной видеопрограммой. Слова песни отображаются в каком-либо месте экрана, обычно внизу, так что пользователь знает слова, которые должны быть спеты, и грубую привязку во времени для песни. Это применение требует видеодисплея с нечастыми графическими обновлениями и микшированием голоса пользователя, или голосов, со стерео аудиопотоком.
Если принять общую частоту передачи кадров равной 300 Гц, то каждый под-кадр будет состоять из 92160 байт видеоконтента и 588 байтов аудиоконтента (на основании 147 16-битовых выборок в стерео) на прямой линии связи к клиенту и в среднем 26,67 байтов (26-2/3) речи, посланных назад с микрофона на мобильную караоке машину. Асинхронные пакеты передаются между ведущим устройством и клиентом, возможно устанавливаемым на голове пользователя дисплеем. Это включает в себя обновление нижней четверти экрана текстом слов с частотой 1/30 вторых интервалов или периодов и других команд смешанного управления и состояния, посылаемых в под-кадрах, когда текст слов не обновляется.
Таблица V показывает, как данные распределяются в пределах под-кадра для примера с караоке. Общая используемая скорость передачи выбрана равной приблизительно 279 Мбит/с. Немного более высокая скорость передачи, равная 280 Мбит/с, позволяет передавать другие приблизительно 400 байтов данных в расчете на под-кадр, что обеспечивает использование нерегулярных сообщений управления и состояния.
| Таблица V | ||
| Скорость передачи элементов | Служебных байтов на под-кадр | Байтов аудио-визуальной информации на под-кадр |
| Музыкальное видео при 640×480 пикселей и 30 кадров/с | 2 * 28 = 56 | 92160 |
| Текст слов при 640×120 пикселей и 1 кадр/с, обновляемый в 10 под-кадрах, 1/30 секунды | 28 | 23040 |
| CD Аудио при 44100 выборок/с, стерео, 16-бит | 2 * 16 = 32 | 588 |
| Голос при 8000 выборок/с, моно, 8-бит | 28+8+8+(4*16)+(3*27) =125 | 26,67 (27 макс) |
| Заголовок под-кадра | 22 | |
| Всего байт/CF | 263 | 115815 |
| Общая скорость (Мбит/с) | (263+115815)*8*300 = 278,5872 | |
III. (Продолжение) Архитектура интерфейсной системы высокоскоростной передачи цифровых данных
E. Уровень линии связи
Данные, передаваемые с использованием последовательных сигналов данных высокоскоростного MDDI, состоят из потока мультиплексированных во времени пакетов, которые связаны один за другим. Даже когда передающее устройство не имеет никаких данных для передачи, контроллер линии связи MDDI обычно автоматически посылает пакеты-заполнители, таким образом поддерживая поток пакетов. Использование простой структуры пакета гарантирует надежное изохронное тактирование для видео- или аудиосигналов или потоков данных.
Группы пакетов содержатся в элементах сигнала или структурах, называемых под-кадрами, а группы под-кадров содержатся в элементах сигнала или структурах, называемых медиакадрами (кадрами аудио-визуальной информации). Под-кадр содержит один или более пакетов, в зависимости от их соответствующего размера и использования в передаче данных, и медиакадр содержит один или более под-кадров. Самый большой под-кадр, обеспечиваемый в соответствии с настоящим протоколом, используемый в вариантах осуществления, представленных здесь, составляет порядка 232-1 или 4294967295 байт, а самый большой размер медиакадра тогда становится равным порядка 216-1 или 65535 под-кадров.
Специальный пакет "Заголовок под-кадра" содержит уникальный идентификатор, который появляется в начале каждого под-кадра, как описано ниже. Этот идентификатор также используется для захвата синхронизации кадра в клиентском устройстве, когда инициализируется обмен между ведущим устройством и клиентом. Захват синхронизации линии связи описан более подробно ниже.
Как правило, экран отображения обновляется один раз в расчете на медиакадр, когда отображается полномасштабное видео. Скорость передачи кадров отображения является такой же, как скорость передачи медиакадров. Протокол линии связи поддерживает полномасштабное видео по всему дисплею или только малой области контента полномасштабного видео, окруженного статическим изображением, в зависимости от требуемого приложения. В некоторых маломощных мобильных приложениях, например, для просмотра web-страниц или электронной почты экран отображения может быть необходимо обновлять только иногда. В этих ситуациях выгодно передавать единственный под-кадр и затем завершать работу или деактивировать линию связи, чтобы минимизировать потребляемую мощность. Интерфейс также поддерживает эффекты, такие как стереозрение, и обрабатывает графические примитивы.
Под-кадры позволяют системе разрешать передачу высокоприоритетных пакетов на периодической основе. Это позволяет одновременным изохронным потокам сосуществовать с минимальной степенью буферизации данных. Это является одним из выгодных вариантов осуществления, обеспеченных для процесса отображения, позволяющим множеству потоков данных (высокоскоростная передача видео, голоса, управления, состояния, данных устройства указания и т.д.) по существу совместно использовать общий канал. Передача информации осуществляется, используя относительно малое количество сигналов. Это также обеспечивает возможность существования действий, "специфичных для технологии отображения", например импульсов строчной (горизонтальной) развертки и интервалов гашения для электронно-лучевой трубки или для других действий, специфичных для технологии клиента.
F. Контроллер линии связи
Контроллер линии связи MDDI, показанный на Фиг.5 и 6, изготавливается или собирается как полностью цифровая реализация за исключением дифференциальных приемников линии, которые используются для приема данных MDDI и стробирующих сигналов. Однако даже дифференциальные задающие устройства и приемники линии могут быть осуществлены на тех же самых цифровых интегральных схемах с контроллером линии связи, например, при производстве ИС типа CMOS (КМОП). Никаких аналоговых функций или схем фазовой автоподстройки частоты (ФАПЧ, PLL) не требуется для восстановления битов или для реализации аппаратных средств для контроллера линии связи. Контроллеры линии связи ведущего устройства и клиента содержат очень похожие функции, за исключением клиентского интерфейса, который содержит конечный автомат для синхронизации линии связи. Поэтому варианты осуществления настоящего изобретения обеспечивают возможность практического преимущества создавать конструкцию отдельного контроллера или схемы, которая может быть конфигурирована или как ведущее устройство, или клиент, что может уменьшать производственные затраты на контроллеры линии связи в целом.
IV. Протокол интерфейсной линии связи
A. Структура кадра
Структура кадра или протокол сигнала, используемые для осуществления обмена по прямой линии связи для передачи пакета, иллюстрируются на Фиг.7. Как показано на Фиг.7, информация или цифровые данные группируются в элементы, известные в качестве пакетов. Множество пакетов, в свою очередь, группируются вместе, чтобы сформировать то, что называется "под-кадром", и множество под-кадров, в свою очередь, сгруппированы вместе, чтобы сформировать "медиакадр". Чтобы управлять формированием кадров и передачей под-кадров, каждый под-кадр начинается со специального заранее определенного пакета, называемого Sub-Frame Header Packet (SHP) (пакет "Заголовок под-кадра").
Ведущее устройство выбирает скорость передачи данных, которую нужно использовать для заданной передачи. Эта скорость передачи может быть динамически изменена ведущим устройством на основании как способности ведущего устройства по максимальной передаче или данных, извлеченных из источника ведущим устройством, так и максимальной способности клиента или другого устройства, к которому передаются данные.
Клиентское устройство получателя, предназначенное для или способное к, работы с MDDI или предлагаемым протоколом передачи сигналов, может быть запрошено ведущим устройством, чтобы определить максимальную или текущую максимальную скорость передачи данных, которую оно может использовать, или может использоваться заданная по умолчанию более медленная минимальная скорость передачи, так же как используемые типы данных и поддерживаемые особенности. Эта информация может быть передана, используя Client Capability Packet (пакет "Возможности клиента") (CCP), как дополнительно описано ниже. Клиентское устройство отображения способно передавать данные или выполнять обмены с другими устройствами, используя интерфейс с заранее выбранной минимальной скоростью передачи данных или в пределах диапазона минимальной скорости передачи данных, и ведущее устройство будет выполнять запрос, используя скорость передачи данных в пределах этого диапазона, чтобы определить все возможности клиентских устройств.
Другая информация о состоянии, определяющая характер битовой карты и возможности клиента в отношении скорости передачи кадров видео, может быть передана в пакете состояния ведущему устройству, так чтобы ведущее устройство могло конфигурировать интерфейс, чтобы он был таким же эффективным или оптимальным при практической реализации или требуемым в пределах любых системных ограничений.
Ведущее устройство посылает пакеты-заполнители, когда не имеется (больше) пакетов данных, которые должны быть переданы в текущем под-кадре, или когда ведущее устройство не может осуществлять передачу со скоростью передачи, достаточной для сохранения темпа при скорости передачи данных, выбранной для прямой линии связи. Так как каждый под-кадр начинается с пакета "Заголовок под-кадра", конец предыдущего под-кадра содержит пакет (наиболее вероятно пакет-заполнитель), который точно заполняет предыдущий под-кадр. В случае недостатка памяти для пакетов как таковых, несущих данных, пакет-заполнитель будет наиболее вероятно последним пакетом в под-кадре или находиться в конце следующего предыдущего под-кадра и перед пакетом заголовка под-кадра. Задачей операций управления в ведущем устройстве является обеспечение гарантий, что имеется пространство, оставшееся в под-кадре, достаточное для каждого пакета, который должен быть передан в пределах этого под-кадра. В то же самое время, как только ведущее устройство инициирует посылку пакета данных, ведущее устройство должно быть способно успешно заполнить пакет этого размера в пределах кадра без того, чтобы подвергать данные условию, определяемому выполнением.
В одном аспекте вариантов осуществления передача под-кадров имеет два режима. Одним режимом является режим периодических под-кадров, или периодических периодов синхронизации, используемых для передачи видео- и аудиопотоков в реальном времени. В этом режиме длина под-кадра определяется как ненулевая. Второй режим - асинхронный, или непериодический, режим, в котором кадры используются для предоставления клиенту данных битовой карты, когда новая информация является доступной. Этот режим определяется установкой длины под-кадра равной нулю в Sub-Frame Header Packet. При использовании периодического режима прием пакета под-кадра может начинаться, когда клиент синхронизирован со структурой кадра прямой линии связи. Это соответствует состоянию "в синхронизме", определенному согласно диаграмме состояний, описанной ниже со ссылками на Фиг.49 или Фиг.63. В асинхронном непериодическом режиме под-кадров прием начинается после того, как принят первый пакет "Заголовок под-кадра" (Sub-Frame Header Packet).
B. Общая структура пакета
Формат или структура пакетов, используемых для формулирования протокола обмена или передачи сигналов, или способ или средства для передачи данных, реализуемых вариантами осуществления, представлены ниже, имея в виду, что интерфейс является расширяемым, и дополнительные структуры пакета могут быть добавлены при необходимости. Пакеты помечены как, или разделены на, различные "типы пакета" в смысле их функций в интерфейсе, то есть командные, информационные, значений или данных, которые они передают или с которыми ассоциированы. Поэтому каждый тип пакета обозначает заранее определенную структуру пакета для заданного пакета, которая используется при манипулировании пакетами и передаваемыми данными. Как очевидно, пакеты могут иметь заранее выбранные длины или иметь переменные или динамически изменяемые длины в зависимости от их соответствующих функций. Пакеты могут также иметь отличающиеся имена, хотя одна и та же функция все еще реализуется, что может иметь место, когда протоколы изменялись во время включения в стандарт. Байты или байтовые значения, используемые в различных пакетах, конфигурируются как многоразрядные (8- или 16-битовые) целые числа без знака. Суммированные данные о пакетах, используемых наряду с обозначениями их "типа", перечисленными по порядку типа, иллюстрируются в Таблицах VI-1 - VI-4.
Каждая таблица представляет общий "тип" пакета в пределах общей структуры пакета для облегчения иллюстрации и понимания. Не имеется никакого ограничения или другого влияния, подразумеваемого или выражаемого для настоящего изобретения этими группировками, и пакеты могут быть организованы многими другими способами при необходимости. Направление, в котором передача пакета рассматривается как действительная, также отмечено.
| Таблица VI-1 Пакеты управления линией связи |
|||
| Имя пакета | Тип пакета | Действителен на прямой линии связи | Действителен на обратной линии связи |
| Пакет "Заголовок под-кадра" | 15359 | x | |
| Пакет-заполнитель | 0 | x | x |
| Пакет «Инкапсуляции обратной линии связи" | 65 | x | |
| Пакет «Завершение работы линии связи» | 69 | x | |
| Пакет «Состояние управления питанием дисплея" | 75 | x | |
| Пакет «Разрешение канала аудио прямой линии связи» | 78 | x | |
| Пакет «Выполнение передачи обслуживания в режим определенного типа» | 77 | x | |
| Пакет «Измерение задержки передачи сигнала в прямом и обратном направлениях» | 82 | x | |
| Пакет «Калибровка сдвига во времени прямой линии связи» | 83 | x | |
| Таблица VI-2 Пакеты основных медиа потоков |
|||
| Имя пакета | Тип пакета | Действителен на прямой линии связи | Действителен на обратной линии связи |
| Пакет «Поток видео» | 16 | x | x |
| Пакет «Поток аудио» | 32 | x | x |
| Пакеты «Зарезервированный поток» | 1-15 18-31 33-55 |
x | x |
| Пакеты «Определяемый пользователем поток» | 56-63 | x | x |
| Пакет «Карта цвета» | 64 | x | x |
| Пакет «Частота выборок аудио обратной линии связи» | 79 | x | |
| Пакет «Установка прозрачного цвета и маски» | 81 | x | |
| Таблица VI-3 Пакеты управления и состояния клиента |
|||
| Имя пакета | Тип пакета | Действителен на прямой линии связи | Действителен на обратной линии связи |
| Пакет "Возможности клиента" | 66 | x | |
| Пакет «Данные клавиатуры» | 67 | x | x |
| Пакет «Данные устройства указания» | 68 | x | x |
| Пакеты «Запрос и состояние клиента» | 70 | x | |
| Служебный пакет «Защита цифрового контента» | 80 | x | x |
| Пакет «Запрос характеристик VCP» | 128 | x | |
| Пакет «Ответ с характеристиками VCP» | 129 | x | |
| Пакет «Установка характеристик VCP» | 130 | x | |
| Пакет «Запрос действительного параметра» | 131 | x | |
| Пакет «Ответ о действительном параметре» | 132 | x | |
| Пакет «Запрос конкретного состояния» | 138 | x | |
| Пакет «Список ответа о действительном состоянии» | 139 | x | |
| Пакет «Возможности персонального дисплея» | 141 | x | |
| Пакет «Отчет об ошибках клиента» | 142 | x | |
| Пакет «Возможности масштабируемого потока видео» | 143 | x | |
| Пакет «Идентификационная информация клиента» | 144 | x | |
| Пакет «Возможности альтернативного дисплея» | 145 | x | |
| Пакет «Доступ к регистру» | 146 | x | x |
| Таблица VI-4 Пакеты усовершенствованной графики и отображения |
|||
| Имя пакета | Тип пакета | Действителен на прямой линии связи | Действителен на обратной линии связи |
| Пакет «Поблочная передача битовой карты» | 71 | x | |
| Пакет «Заполнитель области битовой карты» | 72 | x | |
| Пакет «Заполнитель шаблона битовой карты» | 73 | x | |
| Пакет «Буфер считывания кадра» | 74 | x | |
| Пакет «Возможности масштабируемого потока видео» | 143 | x | |
| Пакет «Установка масштабируемого потока видео» | 136 | x | |
| Пакет «Подтверждение масштабируемого потока видео» | 137 | x | |
| Пакет «Масштабируемый поток видео» | 18 | x | |
То, что ясно из других описаний в пределах настоящего текста, - это то, что каждый из под-кадров заголовка, заполнения, инкапсуляции обратной линии связи, завершения работы линии связи, возможностей клиента и запрос клиента и пакеты состояния рассматриваются очень важными или даже требуемыми для многих вариантов осуществления интерфейсов обмена для работы во внешнем режиме (External Mode). Однако пакеты «Инкапсуляция обратной линии связи», «Завершение работы линии связи», «Возможности клиента» и «Запрос клиента и состояния» могут быть или, что более вероятно, должны рассматриваться как необязательные для операции во внутреннем режиме (Internal Mode). Это создает еще один тип протокола MDDI, который разрешает обмен данными на очень высоких скоростях с сокращенным набором пакетов связи и соответствующее упрощение управления и синхронизации.
Пакеты имеют общую основную структуру или полный набор минимальных полей, содержащих поле Packet Length (длина пакета), поле Packet Type (тип пакета), поле(я) Data Bytes (байты данных), поле CRC (контроля с помощью циклического избыточного кода), который иллюстрируется на Фиг.8. Как показано на Фиг.8, поле Packet Length содержит информацию в форме многобитового или "байтового" значения, которое задает общее количество битов в пакете или его длину между полем «Длина пакета» и полем «CRC». В одном варианте осуществления поле «Длина пакета» имеет 16-битовое или 2-байтовое целое число без знака, которое определяет длину пакета. Поле «Тип пакета» - другое многобитовое поле, которое задает тип информации, которая содержится в пределах пакета. В примерном варианте осуществления оно является 16-разрядным или 2-байтовым значением в виде 16-разрядного целого числа без знака и определяет такие типы данных как возможности дисплея, передача обслуживания, видео- или аудиопотоки, состояние и т.д.
Третье поле - это поле «Байты данных», которое содержит биты или данные, передаваемые или посылаемые между ведущим устройством и клиентскими устройствами в качестве части этого пакета. Формат этих данных задается конкретно для каждого типа пакета согласно специфическому типу передаваемых данных и может быть разделен на последовательность дополнительных полей, каждое со своими собственными требованиями к формату. То есть каждый тип пакета будет иметь определенный формат для этой части или поля. Последним полем является поле CRC, которое содержит результаты контроля циклическим избыточным 16-разрядным кодом, вычисленным по полям Data Bytes, Packet Type и Packet Length, которое используется для подтверждения целостности информации в пакете. Другими словами, вычисленный по полному пакету, за исключением непосредственно поля CRC. Клиент обычно сохраняет полное количество обнаруженных ошибочных кодов CRC и сообщает о этом количестве назад на ведущее устройство в Client Request and Status Packet (пакете «Запрос клиента и состояния») (см. далее ниже).
Обычно ширина и организация этих полей предназначены, чтобы хранить 2-байтовые поля, выровненные по границе четного байта, и 4-байтовые поля, выровненные по 4-байтовым границам. Это позволяет легко встраивать структуры пакета в область главной памяти ведущего устройства и клиента или связанного с ним(и) без нарушения правил выравнивания типа данных, с которыми сталкиваются большинство или обычно используемых процессоров или схем управления.
Во время передачи пакетов поля передают, начиная с передачи первым младшего значащего бита (МЗБ, LSB) и заканчивая старшим значащим битом (СЗБ, MSB), передаваемым последним. Параметры, которые имеют более одного байта в длину, передают с использованием первого самого младшего байта, что приводит к тому же самому шаблону передачи битов, используемому для параметра, большего чем 8 бит в длину, который используется для более короткого параметра, когда первым передают МЗБ. Поля данных каждого пакета обычно передаются в порядке, в котором они определены в последующих разделах ниже, причем первое приведенное в списке поле передается первым, а последнее описанное поле передается последним. Данные на тракте MDDI_Data0 передачи сигналов являются выровненными с '0' битом из байтов, передаваемых по интерфейсу в любом из режимов Тип 1, Тип 2, Тип 3 или Тип-4.
При манипулировании данными для дисплеев данные массивов пикселей передают в порядке - сначала строки, затем столбцы, как традиционно выполняется в области электроники. Другими словами, все пиксели, которые появляются в одной и той же строке в битовой карте, передают в порядке: наиболее левый пиксель передают первым и наиболее правый пиксель передают последним. После того как передан наиболее правый пиксель строки, затем следующий пиксель в последовательности является наиболее левым пикселем следующей строки. Строки пикселей обычно передаются в порядке сверху вниз для большинства дисплеев, хотя могут быть приспособлены другие конфигурации, при необходимости. Кроме того, при обработке битовых карт обычный подход, который представлен ниже, состоит в том, чтобы определить опорную точку, маркируя левый верхний угол битовой карты как местоположение или смещение "0,0". Координаты X и Y, используемые для определения или задания позиции в битовой карте, увеличиваются по своему значению при приближении к правому и нижнему углу битовой карты соответственно. Первая строка и первый столбец (верхний левый угол изображения) начинаются со значения индекса, равного нулю. Значение координаты X увеличивается по направлению к правой стороне изображения, и значение координаты Y увеличивается к нижней части изображения при просмотре дисплея клиентом.
Окно отображения является видимой частью битовой карты, частью пикселей в битовой карте, которая может быть видима клиентом на физическом носителе отображения. Часто имеет место случай, что окно отображения и битовая карта имеют один и тот же размер. Левый верхний угол окна отображения всегда отображает положение '0,0' пикселя битовой карты. Ширина окна отображения соответствует оси Х битовой карты, и ширина окна отображения для этого варианта осуществления меньше или равна ширине соответствующей битовой карты. Высота окна соответствует оси Y битовой карты, и высота окна отображения для этого варианта осуществления является меньшей или равной высоте соответствующей битовой карты. Само окно отображения не адресуется в протоколе, так как оно определяется только как видимая часть битовой карты.
Соотношение между битовыми картами и окнами отображения известны в компьютерной, электронной технике, Интернет-коммуникациях и других связанных с электроникой областях техники. Поэтому дополнительного описания или иллюстрации этих принципов здесь не приводится.
C. Определения пакетов
1. Пакет "Заголовок под-кадра"
Пакет "Заголовок под-кадра" (Sub-frame Header Packet) является первым пакетом каждого под-кадра и имеет основную структуру, как иллюстрируется на Фиг.9. "Заголовок под-кадра" используется для синхронизации ведущее устройство - клиент, каждое ведущее устройство должно быть способно генерировать этот пакет, в то время как каждый клиент должен быть способен принимать и интерпретировать этот пакет. Как можно видеть в одном варианте осуществления согласно Фиг.9, этот тип пакета структурирован так, что имеет поля Packet Length (Длина пакета), Packet Type (Тип пакета), Unique Word (Уникальное слово), Reserved 1 (Зарезервированное 1), Sub-frame Length (Длина под-кадра), Protocol Version (Версия протокола), Sub-frame Count (Количество под-кадров) и Media-frame Count (Количество медиакадров) обычно в этом порядке. В одном варианте осуществления этот тип пакета обычно идентифицируется как пакет Типа 15359 (0x3bff в шестнадцатеричном виде) и использует заранее выбранную фиксированную длину в 20 байтов, не включая поля длины пакета.
Поле «Тип пакета» и поле «Уникальное слово» каждое используют 2-байтное значение (16-разрядное целое число без знака). 4-байтовая комбинация этих двух полей вместе формирует 32-разрядное уникальное слово с хорошей автокорреляцией. В одном варианте осуществления фактическим уникальным словом является 0x005a3bff, где младшие 16 битов передаются первыми как «Тип пакета» и наиболее старшие 16 битов передаются позже.
Поле Reserved 1 (Зарезервированное 1) содержит 2 байта, которые являются зарезервированной областью для будущего использования, и обычно конфигурируется в настоящее время со всеми установленными в нуль битами. Одна из задач этого поля состоит в том, чтобы выровнять последующие 2-байтовые поля по 16-битовому адресу слова и выровнять 4-байтовые поля по 32-битовому адресу слова. Самый младший значащий байт зарезервирован, чтобы указать, действительно ли ведущее устройство способно адресовать множество клиентских устройств. Значение, равное нулю, для этого байта зарезервировано для указания того, что ведущее устройство способно оперировать только с единственным клиентским устройством.
Поле «Длина под-кадра» содержит 4 байта информации, или значений, которые определяют число байтов в расчете на под-кадр. В одном варианте осуществления длина этого поля может быть установлена равной нулю для указания того, что только один под-кадр будет передан ведущим устройством, прежде чем линия связи будет завершена (переведена) в состояние "не активно". Значение в этом поле может быть динамически изменено "на лету" при переходе от одного под-кадра к следующему. Эта возможность полезна для выполнения меньшей настройки синхронизации в синхронизирующих импульсах для приспособления изохронных потоков данных. Если код CRC пакета "Заголовок под-кадра" является недостоверным, то контроллер линии связи должен использовать «Длина под-кадра» предыдущего заведомо исправного пакета "Заголовок под-кадра", чтобы оценить длину текущего под-кадра.
Поле Protocol Version содержит 2 байта, которые определяют версию протокола, используемую ведущим устройством. Поле Protocol Version может быть установлено в '0', чтобы задать первую или текущую версию протокола, которая использовалась. Это значение будет изменяться через какое-то время, поскольку создаются новые версии, и уже модернизируется в значение '1' для некоторых полей версии. Значения версии будут вероятно или обычно следовать за текущим номером версии для одобренного документа стандартов, который охватывает интерфейсы, такие как MDDI, как может быть известно.
Поле «Количество под-кадров» (Sub-frame Count) содержит 2 байта, которые задают порядковый номер, который указывает количество под-кадров, которые были переданы, начиная с начала медиакадра. Первый под-кадр медиакадра имеет значение Sub-frame Count, равное нулю. Последний под-кадр медиакадра имеет значение, равное n-1, где n - число под-кадров в медиакадре. Значение поля Sub-frame Count равно значению Sub-frame Count, посланному в предыдущем пакете под-кадра плюс 1, за исключением первого под-кадра медиакадра, который должен иметь индекс, равный нулю. Следует заметить, что если значение Sub-frame Length установлено равным нулю (указывая непериодический под-кадр), то Sub-frame Count также установлено равным нулю.
Поле Media-frame Count (Количество медиакадров) содержит 4 байта (32-разрядное целое число без знака), определяющие порядковый номер, который указывает количество медиакадров, которые были переданы, начиная с начала текущего элемента или данных передаваемой аудио-визуальной информации (медиа-элемента). Первый медиакадр элемента аудио-визуальной информации имеет значение Media-frame Count, равное нулю. Значение Media-frame Count увеличивается непосредственно перед первым под-кадром каждого медиакадра и возвращается назад к значению, равному нулю, после максимального значения Media-frame Count (например, медиакадра номер 232-1 = 4294967295), которое используется. Значение Media-frame Count может быть сброшено обычно в любое время ведущим устройством, чтобы удовлетворить потребности конечного применения.
2. Пакет-заполнитель
Пакет «Заполнитель» (Filler Packet) является пакетом, который передается к или от клиентского устройства, когда никакая другая информация не доступна для пересылки или по прямой или по обратной линии связи. Рекомендуется, чтобы пакеты-заполнители имели минимальную длину, чтобы обеспечить максимальную гибкость при посылке других пакетов, когда необходимо. В самом конце под-кадра или пакета инкапсуляции пакета обратной линии связи (см. ниже) контроллер линии связи устанавливает размер пакета-заполнителя, чтобы заполнить остающийся интервал для поддержания целостности пакета. Пакет-заполнитель полезен для поддержания синхронизации на линии связи, когда никакое ведущее устройство или клиент не имеют информации для посылки или обмена. Каждое ведущее устройство и клиент должны быть способны посылать и принимать этот пакет, чтобы обеспечить эффективное использование интерфейса.
Примерный вариант осуществления формата и содержания пакета-заполнителя иллюстрируется на Фиг.10. Как показано на Фиг.10, этот тип пакета структурирован так, что имеет поля Packet Length (Длина пакета), Packet Type (Тип пакета), Filter Bytes (Байты заполнителя) и CRC. В одном варианте осуществления этот тип пакета обычно идентифицируется как Тип 0, который указан в 2-байтовом поле Type. Биты или байты в поле «Байты заполнителя» содержат переменное количество всех нулевых значений битов, чтобы обеспечить требуемую длину пакета-заполнителя. Самый маленький пакет-заполнитель не содержит байтов в этом поле. То есть пакет состоит только из длины пакета, типа пакета и CRC и в одном варианте осуществления использует заранее выбранную фиксированную длину в 6 байт или значение Packet Length, равное 4. Значение CRC определено для всех байтов в пакете, включая поле Packet Length, которое может быть исключено в некоторых других типах пакета.
3. Пакет «Поток видео»
Пакеты «Поток видео» (Video Stream Packets) несут видеоинформацию для обновления обычно прямоугольных областей устройства отображения. Размер этой области может быть всего в один пиксель или иметь такой размер, как весь экран дисплея. Может существовать почти неограниченное количество потоков, отображаемых одновременно, ограниченное системными ресурсами, так как весь контекст, требуемый для отображения потока, содержится в пределах пакета «Поток видео». Формат одного варианта осуществления «Потока видео» (Video Data Format Descriptor - Дескриптор формата данных видео) показан на Фиг.11. Как видно на Фиг.11, в одном варианте осуществления этот тип пакета структурирован так, чтобы иметь поля Packet Length (Длина пакета) (2 байта), Packet Type (Тип пакета), bClient ID (Идентификатор клиента), Video Data Descriptor (Дескриптор данных видео), Pixel Display Attributes (Атрибуты отображения пикселей), X Left Edge (Х левой границы), Y Top Edge (Y верхней границы), X Right Edge (X правой границы), Y Bottom Edge (Y нижней границы), X and Y Start (X и Y начала), Pixel Count (Количество пикселей), Parameter CRC (Параметр CRC), Pixel Data (Пиксельные данные) и Pixel Data CRC (CRC пиксельных данных). Этот тип пакета обычно идентифицируется как Тип 16, который указывается в 2-байтовом поле Type. В одном варианте осуществления клиент указывает способность принять пакет потока видео, используя поля "красный-зеленый-синий" (RGB), монохромный и Y Cr Cb Capability (Возможности Y Cr Cb) пакета «Возможности клиента».
В одном варианте осуществления поле «Идентификатор клиента» содержит 2 байта информации, которые зарезервированы для идентификатора клиента. Так как коммуникационный протокол является недавно разработанным, идентификаторы фактических клиентов еще не известны или недостаточно открыты. Поэтому биты в этом поле обычно устанавливаются равными нулю, до тех пор пока такие значения идентификаторов не станут известны, причем в этот момент времени значения идентификаторов могут быть вставлены или использоваться, как очевидно для специалистов в данной области техники. Тот же самый процесс будет обычно справедлив для полей идентификаторов клиента, описанных ниже.
Формат и содержимое, используемое для реализации работы примерного поля «Дескриптор данных видео», которое упомянуто выше, иллюстрируются на Фиг. 12A-12E. На Фиг. 12A-12E поле «Дескриптор формата данных видео» содержит 2 байта в форме 16-битового целого числа без знака, которое определяет формат каждого пикселя в пиксельных данных в текущем потоке в текущем пакете. Возможно, что различные пакеты потока видео могут использовать различные форматы пиксельных данных, то есть использовать отличное значение в «Дескрипторе формата данных видео», и аналогично, поток (область дисплея) может изменять свой формат данных "на лету". Формат пиксельных данных должен подчиняться по меньшей мере одному из действительных форматов для клиента, как определено в пакете "Возможности клиента". Дескриптор формата данных видео определяет только такой пиксельный формат для текущего пакета, который не подразумевает, что постоянный формат будет продолжать использоваться в течение срока «жизни» конкретного потока видео.
Фиг. 12A-12D иллюстрируют, как кодируется «Дескриптор формата данных видео». Как используется на этих чертежах и в этом варианте осуществления, когда биты [15:13] равны '000', как показано на Фиг.12A, тогда видеоданные состоят из массива одноцветных (монохромных) пикселей, где число битов на пиксель определяется битами 3-0 слова «Дескриптора формата данных видео». Биты 11-4 обычно резервируются для будущего использования или приложений и установлены равными нулю в этой ситуации. Когда биты [15:13] вместо этого равны значениям '001', как показано на Фиг.12B, тогда видеоданные состоят из массива цветных пикселей, каждый определяет цвет посредством карты цвета (палитры). В этой ситуации биты 5-0 слова «Дескриптора формата данных видео» определяют число битов в расчете на пиксель и биты 11-6 обычно резервируются для будущего использования или приложений и устанавливаются равными нулю. Когда биты [15:13] вместо этого равны значениям '010', как показано на Фиг.12C, тогда видеоданные состоят из массива цветных пикселей, где количество битов в расчете на пиксель красного цвета определяется битами 11-8, количество битов в расчете на пиксель зеленого цвета определяется битами 7-4 и количество битов в расчете на пиксель синего цвета определяется битами 3-0. В этой ситуации общее количество битов в каждом пикселе равно сумме числа битов, используемых для красного, зеленого и синего цветов.
Однако, когда биты [15:13] вместо этого равны значениям или строке '011', как показано на Фиг.12D, тогда видеоданные состоят из массива видеоданных в формате 4:2:2 Y Cb Cr с информацией о яркости и цветности, где количество битов в расчете на пиксель сигнала яркости (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 являются значениями яркости четырех последовательных пикселей в отдельной строке слева направо. Если имеется нечетное число пикселей в строке (X Right Edge - X Left Edge + 1) в окне, указываемом пакетом «Поток видео», тогда за значением Y, соответствующим последнему пикселю в каждой строке, будет следовать значение Cb первого пикселя следующей строки, и значение Cr не посылается для последнего пикселя в строке. Рекомендуется, чтобы окна, использующие формат Y Cb Cr, имели ширину, которая является четным количеством пикселей. Пиксельные данные в пакете должны содержать четное количество пикселей. Они могут содержать нечетное или четное количество пикселей в случае, когда последний пиксель пиксельных данных соответствует последнему пикселю строки в окне, указанном в заголовке пакета «Поток видео», т.е. когда местоположение X последнего пикселя в пиксельных данных равно X Right Edge (X правой границы).
Когда биты [15:13] вместо этого равны значениям '100', тогда видеоданные состоят из массива пикселей в формате Байера (Bayer), где количество битов в расчете на пиксель определяется битами 3-0 слова «Дескриптор формата данных видео». «Шаблон группы пикселей» (Pixel Group Pattern) определяется битами 5 и 4, как показано на Фиг.12E. Порядок пиксельных данных может быть горизонтальным или вертикальным, и пиксели в строках или столбцах могут быть представлены в прямом или обратном порядке, и определяется битами 8-6. Биты 11-9 должны быть установлены равными нулю. Группа из четырех пикселей в группе пикселей в формате Байера походит на то, что часто называют как единственным пикселем в некоторых технологиях отображения. Однако один пиксель в формате Байера является только одним из четырех цветных пикселей мозаичного шаблона группы пикселей.
Для всех пяти форматов, показанных на чертежах, бит 12, который обозначен как "P", определяет, упакованы ли выборки «Пиксельные данные» или являются выровненными по границе байта пиксельными данными. Значение '0' в этом поле указывает, что каждый пиксель в поле «Пиксельные данные» является выровненным по границе байта MDDI. Значение '1' указывает, что каждый пиксель и каждый цвет в каждом пикселе в поле «Пиксельные данные» упакованы вместе с предыдущим пикселем или цветом в пикселе, не оставляя неиспользованных битов. Различие между выровненным по границе байта и упакованным форматом пиксельных данных показан более подробно на Фиг.13, где можно ясно видеть, что выровненные по границе байта данные могут оставлять неиспользованные части под-кадра данных в противоположность упакованному формату пикселя, в котором этого не имеется.
4. Пакет «Поток аудио»
Пакеты аудиопотока переносят аудиоданные, которые должны быть воспроизведены аудиосистемой клиента или для автономного устройства представления аудио. Различные потоки аудиоданных могут быть назначены для отдельных аудиоканалов в звуковой системе, например: левый - передний, правый - передний, центральный, левый - задний и правый - задний, в зависимости от типа используемой аудиосистемы. Полный комплект аудиоканалов обеспечивается для головных телефонов, которые содержат средства для расширенной пространственно-акустической обработки сигналов. Клиент указывает способность принять пакет «Поток аудио», используя поля Audio Channel Capability (Возможность канала аудио) и Audio Sample Rate (Частота выборок аудио) пакета Client Capability Packet ("Возможности клиента"). Формат пакетов потока аудио проиллюстрирован на Фиг.14.
Как показано на Фиг.14, этот тип пакета структурирован в одном варианте осуществления так, что имеет поля Packet Length (Длина пакета), Packet Type (Тип пакета), bClient ID (Идентификатор клиента), Audio Channel ID (Идентификатор аудиоканала), Reserved 1 (Зарезервированное 1), Audio Sample Count (Количество выборок аудио), Bits Per Sample and Packing (Битов на выборку и упаковку), Audio Sample Rate (Частота выборок аудио), Parameter CRC (Параметр CRC), Digital Audio Data (Данные цифрового аудио), Audio Data CRC (код CRC аудиоданных). В одном варианте осуществления этот тип пакета обычно идентифицируется как пакет Типа 32.
Поле "Идентификатор клиента" содержит 2 байта информации, которые зарезервированы для идентификатора клиента, как указано выше. Поле "Зарезервированное 1" содержит 2 байта, которые зарезервированы для будущего использования и обычно конфигурируются в настоящий момент времени со всеми битами, установленными равными нулю.
Поле "Битов на выборку и упаковку" содержат 1 байт в форме 8-битового целого числа без знака, которое определяет упакованный формат аудиоданных. Этот формат обычно используется для битов 4-0, чтобы определить количество битов в расчете на ИКМ-выборку (выборку согласно импульсно-кодовой манипуляции) аудио. Бит 5 тогда определяет, упакованы ли выборки Digital Audio Data (Данные цифрового аудио). Различие между упакованными и выровненными по границе байта выборками аудио, здесь используя 10-битовые выборки, проиллюстрировано на Фиг.15. Значение '0' указывает, что каждая ИКМ-выборка аудио в поле "Данные цифрового аудио" является выровненной по границе байта с границей байта MDDI, а значение '1' указывает, что каждая последующая ИКМ-выборка аудио является упакованной вместе (рядом) с предыдущей выборкой аудио. Этот бит обычно эффективен только тогда, когда значение, определенное в битах 4-0 (количество битов в ИКМ-выборке аудио), не является кратным восьми. Биты 7-6 зарезервированы для будущего использования и обычно устанавливаются равными нулю.
5. Пакеты зарезервированного потока
В одном варианте осуществления типы 1-15, 18-31 и 33-55 пакетов зарезервированы для пакетов потока, которые должны быть определены для использования в будущих версиях или вариациях протоколов пакета, как требуется для различных встречающихся применений. Вновь это является частью для создания MDDI более гибким и полезным перед лицом когда-либо изменяющейся технологии и конструкций систем по сравнению с другими методами.
6. Пакеты "Определяемый пользователем поток"
Восемь типов потоков данных, известных как Типы 56-63, зарезервированы для использования в частных приложениях, которые могут быть определены изготовителями оборудования для использования с линиями связи с MDDI. Они известны как пакеты "Определяемый пользователем поток". Такие пакеты могут использоваться для любой цели, но ведущее устройство и клиент должны только использовать такие пакеты в ситуациях, когда результат такого использования очень хорошо понятен или известен. Конкретное определение параметров потока и данных для этих типов пакета предоставлено изготовителям конкретного оборудования или проектировщикам интерфейса, реализующим такие типы пакета или поиск их использования. Некоторые примеры использования пакетов "Определяемый пользователем поток" должны передать тестовые параметры и результаты тестирования, заводские данные калибровки и данные частного специального использования. Формат пакетов "Определяемый пользователем поток", который используется в одном варианте осуществления, проиллюстрирован на Фиг.16. Как показано на Фиг.16, этот тип пакета структурирован так, что имеет поля Длина Пакета (2 байта), Тип Пакета, номер bClient ID (Номер идентификатора клиента), Stream Parameters (Параметры потока), Parameter CRC (Параметр CRC), Stream Data (Данные потока) и Stream Data CRC (CRC данных потока).
7. Пакеты "Карта цвета"
Пакеты "Карта цвета" (Color Map Packets) задают содержимое таблицы поиска карты цвета, используемой для представления цвета для клиента. Некоторые приложения могут требовать карты цвета, которая является большей, чем количество данных, которые могут быть переданы в одном пакете. В этих случаях может быть передано множество пакетов "Карта цвета", каждый с различным поднабором карты цвета, используя поля смещения и длины, описанные ниже. Формат пакета "Карта цвета" в одном варианте осуществления проиллюстрирован на Фиг.17. Как показано на Фиг.17, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Color Map Item Count (Количество элементов карты цвета), Color Map Offset (Смещение карты цвета), Parameter CRC (Параметр CRC), Color Map Data (Данные карты цвета) и Data CRC (CRC данных). В одном варианте осуществления этот тип пакета обычно идентифицируется как пакет Типа 64 (пакет "Формат данных видео и карта цвета"), как задано в поле "Тип пакета" (2 байта). Клиент указывает способность принимать пакеты "Карта цвета", используя поля Color Map Size (Размер карты цвета) и Color Map Width (Ширина карты цвета) в пакете "Возможности клиента".
8. Пакеты "Инкапсуляция обратной линии связи"
В примерном варианте осуществления данные передают в обратном направлении, используя Reverse Link Encapsulation Packet (пакет "Инкапсуляция (формирования пакета) обратной линии связи"). Пакет прямой линии связи посылают, и работа линии связи с MDDI (направление передачи) изменяется или изменяется на противоположное в середине этого пакета так, что пакеты могут быть посланы в обратном направлении. Формат пакета "Инкапсуляция обратной линии связи" в одном варианте осуществления проиллюстрирован на Фиг.18. Как показано на Фиг.18, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hCLient ID (Идентификатор клиента), Reverse Link Flags (Флаги обратной линии связи), Reverse Link Divisor (Делитель скорости передачи обратной линии связи), Turn-Around 1 Length (Длина изменения на противоположное 1), Turn-Around 2 Length (Длина изменения на противоположное 2), CRC параметр, All Zero 1 (Все нули 1), Turn-Around 1 (Изменение на противоположное 1), Reverse Data Packets ("Пакеты данных обратной линии связи"), Turn-Around 2 (Изменение на противоположное 2) и All Zero 2 (Все нули 2). В одном варианте осуществления этот тип пакета обычно идентифицируется как пакет Типа 65. Для внешнего режима каждое ведущее устройство обязано быть способно генерировать этот пакет и принимать данные и каждый клиент обязан быть способен принимать и посылать данные на ведущее устройство, чтобы эффективно использовать требуемый протокол и результирующую скорость. Реализация этого пакета является необязательной для внутреннего режима, но пакет "Инкапсуляция обратной линии связи" используется для ведущего устройства, чтобы принимать данные от клиента.
Контроллер линии связи MDDI ведет себя особым образом при посылке пакета "Инкапсуляция обратной линии связи". MDDI имеет стробирующий сигнал, который обычно всегда задается (возбуждается, устанавливается) ведущим устройством в качестве контроллера линии связи. Ведущее устройство ведет себя так, как будто оно передало нуль для каждого бита частей Turn-Around и Reverse Data Packets пакета "Инкапсуляция обратной линии связи". Ведущее устройство переключает сигнал MDDI_Strobe на каждой битовой границе в течение двух моментов изменения на противоположное и в течение времени, назначенного для пакетов данных обратной линии связи. То есть ведущее устройство переключает MDDI_Stb с начала поля All Zero 1 к концу поля All Zero 2. (Это представляет собой то же самое поведение, как если бы были переданы все нулевые данные.)
Ведущее устройство отключает (запрещает) свои задающие устройства сигнальной линии данных MDDI и обычно обеспечивает, чтобы они были полностью запрещены до последнего бита поля Turn-Around 1, затем повторно разрешает свои задающие устройства линии в течение поля Turn-Around 2 и обычно обеспечивает, что задающие устройства полностью повторно разрешены до последнего бита поля Turn-Around 2. Клиент считывает параметр Turn-Around Length (Длина изменения на противоположное) и устанавливает сигналы данных к ведущему устройству немедленно после последнего бита в поле Turn-Around 1. То есть клиент синхронизирует новые данные в линии связи по некоторым нарастающим фронтам строба MDDI, как указано в описании содержимого пакета ниже и в другом месте настоящего описания. Клиент использует параметры Packet Length (Длина пакета) и Turn-Around Length, чтобы знать отрезок времени, который доступен для того, чтобы послать пакеты ведущему устройству. Клиент может посылать пакеты-заполнители или устанавливать линии данных в нулевое состояние, когда он не имеет никаких данных для посылки ведущему устройству. Если линии данных устанавливаются в нуль, ведущее устройство интерпретирует это как пакет с нулевой длиной (недействительная длина) и ведущее устройство больше не принимает пакеты от клиента в течение длительности текущего пакета "Инкапсуляция обратной линии связи".
В одном варианте осуществления поле Reverse Link Request (Запрос обратной линии связи) пакета Client Request and Status Packet (пакет "Запрос клиента и состояния") может использоваться для того, чтобы информировать ведущее устройство о количестве байтов, которые требуются клиенту в пакете "Инкапсуляция обратной линии связи», чтобы послать данные назад ведущему устройству. Ведущее устройство пытается предоставлять запрос посредством выделения по меньшей мере этого количества байтов в пакете "Инкапсуляция обратной линии связи». Ведущее устройство может посылать больше чем один пакет "Инкапсуляция обратной линии связи» в под-кадре. Клиент может посылать пакет "Запрос клиента и состояния" почти в любое время, и ведущее устройство интерпретирует параметр "Запрос обратной линии связи" как общее количество байтов, запрошенных в одном под-кадре.
9. Пакеты "Возможности клиента"
Ведущее устройство должно знать функциональные возможности клиента (дисплея), с которым оно обменивается, с тем чтобы конфигурировать линию связи "ведущее устройство - клиент" обычно оптимальным или требуемым образом. Рекомендуется, чтобы дисплей посылал пакет "Возможности клиента" (Client Capability Packet) ведущему устройству после того, как захвачена синхронизация прямой линии связи. Передача такого пакета рассматривается требуемой, когда запрошена ведущим устройством, используя "Флаги обратной линии связи" (Reverse Link Flags) в пакете "Инкапсуляция обратной линии связи». Пакет "Возможности клиента" используется, чтобы информировать ведущее устройство о функциональных возможностях клиента. Во внешнем режиме каждое ведущее устройство должно быть способно принять этот пакет, и каждый клиент должен быть способен послать этот пакет, чтобы полностью использовать этот интерфейс и протокол. Реализация этого пакета является необязательной для внутреннего режима, так как возможности клиента, такие как дисплей, клавиатура или другое устройство ввода-вывода, в этой ситуации должны уже быть хорошо определены и известны на ведущем устройстве во время изготовления или сбора в единый компонент или модуль некоторого типа.
Формат пакета "Возможности клиента" в одном варианте осуществления проиллюстрирован на Фиг.19. Как показано на Фиг.19, для этого варианта осуществления этот тип пакета структурирован так, что имеет поля Packet Length (Длина пакета), Packet Type (Тип пакета), cClient ID (Идентификатор клиента), Protocol Version (Версия протокола), Min Protocol Version (Минимальная версия протокола), Pre-Calibration Data Rate Capability (Возможность скорости передачи данных перед калибровкой), Interface Type Capability (Возможность типа интерфейса), Number of Alt Displays (Количество альтернативных дисплеев), Post-Calibration Data Rate Capability (Возможность скорости передачи данных после калибровки), Bitmap Width (Ширина битовой карты), Bitmap Height (Высота битовой карты), Display Window Width (Ширина окна отображения), Display Window Height (Высота окна отображения), Color Map Size (Размер карты цвета), Color Map RGB Width (Ширина карты цвета RGB), RGB Capability (Возможность RGB), Monochrome Capability (Возможность монохромного изображения), Reserved 1 (Зарезервированное 1), Y Cr Cb Capability (Возможность Y Cr Cb), Bayer Capability (Возможность формата Байера), Reserved 2 (Зарезервированное 2), Client Feature Capability (Возможность характеристики клиента), Max Video Frame Rate (Максимальная скорость передачи видеокадров), Min Video Frame Rate (Минимальная скорость передачи видеокадров), Min Sub-frame rate (Минимальная скорость передачи под-кадров), Audio Buffer Depth (Глубина буфера аудио), Audio Channel Capability (Возможность канала аудио), Audio Sample Rate Capability (Возможность частоты выборки аудио), Audio Sample Resolution (Разрешение аудиовыборки), Mic Sample Resolution (Разрешение выборки микрофона), Mic Sample Rate Capability (Возможность частоты выборки микрофона), Keyboard Data Format (Формат данных клавиатуры), Pointing Device Data Format (Формат данных устройства указания), Content Protection Type (Тип защиты контента), Mfr. Name (Название производителя), Product Code (Код продукта), Reserved 3 (Зарезервированное 3), Serial Number (Серийный номер), Week of Mfr. (Неделя изготовления), Year of Mfr. (Год изготовления) и CRC (Контроль при помощи циклического избыточного кода). В примерном варианте осуществления этот тип пакета обычно идентифицируется как пакет Типа 66.
10. Пакеты "Данные клавиатуры"
Пакет "Данные клавиатуры" (Keyboard Data Format) используется, чтобы послать данные клавиатуры от клиентского устройства на ведущее устройство. Беспроводная (или проводная) клавиатура может использоваться вместе с различными дисплеями или аудиоустройствами, включая в себя, но не ограничиваясь ими, устанавливаемое на голове устройство представления с видеодисплеем/аудио. Пакет "Данные клавиатуры" передает данные клавиатуры, принятые от одного из нескольких известных устройств, аналогичных клавиатуре, на ведущее устройство. Этот пакет может также использоваться на прямой линии связи, чтобы посылать данные к клавиатуре. Клиент указывает способность посылать и принимать пакеты "Данные клавиатуры", используя поле "Данные клавиатуры" в пакете "Возможности клиента".
Формат пакета "Данные клавиатуры" иллюстрируется на Фиг.20 и содержит переменное число байтов информации от или для клавиатуры. Как показано на Фиг.20, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, bClient ID (Идентификатор клиента), Keyboard Data Format (Формат данных клавиатуры), Keyboard Data (Данные клавиатуры) и CRC. Здесь этот тип пакета обычно идентифицируется как пакет Типа 67.
"Идентификатор клиента" является зарезервированным полем, как и прежде, и CRC выполняется по всем байтам пакета. Поле "Формат данных клавиатуры" содержит 2 байтовое значение, которое описывает формат данных клавиатуры. Биты 6-0 должны быть идентичны полю "Формат данных клавиатуры" в пакете "Возможности клиента". Это значение не должно быть равно 127. Биты 15-7 зарезервированы для будущего использования и поэтому в настоящее время установлены равными нулю.
11. Пакеты "Данные устройства указания"
Пакет "Данные устройства указания" используется как способ, структура или средство для посылки информации о позиции от беспроводной мыши или другого устройства указания от клиента на ведущее устройство. Данные также могут быть посланы устройству указания по прямой линии связи, используя этот пакет. Примерный формат пакета "Данные устройства указания" иллюстрируется на Фиг.21 и содержит переменное количество байтов информации от или для устройства указания.
Как показано на Фиг.21, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, bClient ID (Идентификатор клиента), Pointing Device Format (Формат устройства указания), Pointing Device Data (Данные устройства указания) и CRC. В примерном варианте осуществления этот тип пакета обычно идентифицируется как пакет Типа 68 в 1-байтовом поле типа.
12. Пакеты "Завершение работы линии связи"
Пакет "Завершение работы линии связи" (Link Shutdown Packet) посылает от ведущего устройства к клиенту в качестве способа или средства для указания того, что данные MDDI и строб будут сняты и необходимости перехода в состояние "бездействия" с малым потреблением энергии. Этот пакет полезен для отключения линии связи и сохранения мощности после того, как статические битовые карты посылают с устройства мобильной связи на дисплей, или когда в настоящее время не имеется никакой дополнительной информации для передачи от ведущего устройства к клиенту. Нормальная работа продолжается, когда ведущее устройство посылает пакеты заново. Первым пакетом, посланным после бездействия, является пакет "Заголовок под-кадра". Формат пакета "Состояние клиента" (Client Status Packet) для одного варианта осуществления иллюстрируется на Фиг.22. Как показано на Фиг.22, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, CRC и All Zeros (все нули). В одном варианте осуществления этот тип пакета обычно идентифицируется как пакет Типа 69 в 1-байтовом поле типа.
Поле Длина пакета использует 2 байта, чтобы определить общее количество байтов в пакете, не включая поле Длина пакета. В одном варианте осуществления "Длина пакета" этого пакета зависит от Типа Интерфейса (Interface Type) или режима линии связи, действующих в момент времени, когда посылают пакет "Завершение работы линии связи". Поэтому типичная длина пакета становится равной 20 байт для режима Типа 1 (общее количество 22 байта в пакете), 36 байтов для режима Типа 2 (общее количество 38 байт в пакете), 68 байтов для линии связи режима Типа 3 (общее количество 70 байт в пакете) и 132 байтах для режима Типа 4 (с общим количеством 134 байт в пакете).
Поле All Zeros (Все нули) использует переменное количество байтов, чтобы гарантировать, что сигналы MDDI_Data установлены в уровень логического нуля в течение достаточного времени, чтобы разрешить клиенту начать восстановление синхронизации, используя только MDDI_Stb до отключения задающих устройств линии ведущего устройства. Длина поля All Zeros зависит от Типа Интерфейса или рабочего режима линии связи, действующих в момент, когда посылают пакет "Завершение работы линии связи". Длина поля All Zeros предназначена для формирования 64 импульсов на MDDI_Stb для любой настройки Типа Интерфейса. Поэтому длина All Zeros для каждого типа интерфейса становится равной 16 байт для Типа 1, 32 байта для Типа 2, 64 байта для Типа 3 и 128 байт для Типа 4.
Поле CRC использует 2 байта, которые содержат 16-битовый CRC для байтов от Длины Пакета до Типа Пакета.
В состоянии бездействия с потреблением малой мощности задающее устройство MDDI_Data0 отключается в состояние с высоким сопротивлением, начиная после 16-го до 48-го такта или импульса MDDI_Stb после последнего бита поля "Все нули". Для линий связи Типа-2, Типа-3 или Типа-4 сигналы MDDI_Data1 - MDDI_DataPwr7 также переводятся в состояние с высоким сопротивлением, в то время когда задающее устройство MDDI_Data0 отключено. Или ведущее устройство или клиент может вынудить линию связи MDDI "пробудиться" из состояния бездействия, как описано в настоящем описании, что является ключевым усовершенствованием и преимуществом настоящего изобретения.
Как описано в определении поля "Все нули", MDDI_Stb переключается в течение 64 тактов после MSB (младшего значащего бита) поля CRC пакета "Завершение работы линии связи", чтобы облегчить правильное отключение в контроллере клиента. Одним тактом является переход от низкого уровня к высокому с последующим переходом от высокого к низкому или переход от высокого к низкому с последующим переходом от низкого к высокому. После того как поле All Zeros послано, задающее устройство сигнала MDDI_Stb в ведущем устройстве блокируется (запрещается).
13. Пакеты "Запрос и состояние клиента"
Ведущее устройство нуждается в малом количестве информации от клиента, так что оно может конфигурировать линию связи "ведущее устройство - клиент" обычно оптимальным способом. Рекомендуется, чтобы клиент посылал один пакет "Запрос и состояние клиента" (Client Request and Status Packet) на ведущее устройство каждый под-кадр. Обычно рекомендуется, чтобы клиент посылал этот пакет в качестве первого пакета в пакете "Инкапсуляция обратной линии связи», чтобы гарантировать, что он надежно доставлен ведущему устройству. Передача этого пакета также выполняется, когда запрашивается ведущим устройством, используя "Флаги обратной линии связи" в пакете "Инкапсуляция обратной линии связи». Пакет "Запрос и состояние клиента" используются, чтобы сообщить об ошибках и состоянии на ведущее устройство. Для работы во внешнем режиме каждое ведущее устройство должно быть способно принять этот пакет и каждый клиент должен быть способен послать этот пакет, чтобы должным образом или оптимально использовать протокол MDDI. Хотя и рекомендуется, чтобы для внутренних операций, т.е. внутренних ведущих устройств и внутренних клиентов, имелась поддержка для этого пакета, это не требуется.
Формат пакета "Запрос и состояние клиента" иллюстрируется на Фиг.23. Как показано на Фиг.23, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, cClient ID (идентификатор клиента), Reverse Link Request (Запрос обратной линии связи), Capability Change (Изменение возможностей), Client Busy (Занятый клиент), CRC Error Count (Количество ошибочных кодов CRC) и CRC. Этот тип пакета обычно идентифицируется как пакет Типа 70 в 1-байтовом поле типа и обычно использует предварительно выбранную фиксированную длину, равную 12 байтам.
Поле "Запрос обратной линии связи" может использоваться для информирования ведущего устройства о количестве байтов, в которых нуждается клиент, в пакете "Инкапсуляция обратной линии связи», для посылки данных назад ведущему устройству. Ведущее устройство должно пытаться выдавать этот запрос посредством назначения по меньшей мере этого количества байтов в пакете "Инкапсуляция обратной линии связи». Ведущее устройство может посылать более чем один пакет "Инкапсуляция обратной линии связи» в под-кадре, чтобы разместить данные. Клиент может посылать пакет "Запрос и состояние клиента" в любое время, и ведущее устройство будет интерпретировать параметр "Запрос обратной линии связи" как общее количество байтов, запрошенных в одном под-кадре. Дополнительные подробности и конкретные примеры того, как данные обратной линии связи посылают назад ведущему устройству, представлены ниже.
14. Пакеты "Поблочная пересылка карты цвета"
Пакет "Поблочная пересылка карты цвета" обеспечивает средства, структуру или способ для пролистывания областей дисплея в любом направлении, обычно копируя блок пикселей одной прямоугольной области в другую. Клиенты, которые имеют эту возможность, будут сообщать об этой возможности в бите 0 поля Display Feature Capability Indicators (Индикаторы возможностей характеристик дисплея) в пакете "Возможности клиента". Формат для одного варианта осуществления пакета "Поблочная пересылка карты цвета" иллюстрируется на Фиг.24. Как показано на Фиг.24, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Pixel Data Attributes (Атрибуты пиксельных данных), Raster Operation (Растровая операция), Upper Left X Value (Значение X верхнего левого угла), Upper Left Y Value (значение Y верхнего левого угла), Window Width (Ширина окна), Window Height (Высота окна), Window X Movement (Перемещение окна по Х), Window Y Movement (Перемещение окна по Y) и CRC. Этот тип пакета обычно идентифицируется как пакет Типа 71, и в одном варианте осуществления использует предварительно выбранную фиксированную длину в 15 байтов. 2-байтовое поле hClient ID содержит информацию или значения, которые зарезервированы для идентификатора клиента, как описано в настоящем описании. Так как это поле обычно резервируется для будущего использования, текущее значение обычно устанавливается равным нулю посредством установки битов в уровень логического нуля, хотя оно может быть установлено равным другим значениям или использоваться специалистами в данной области техники, чтобы передать требуемую информацию.
В одном варианте осуществления 2-байтовое поле "Атрибуты пиксельных данных" имеет значения, которые задают, где пиксельные данные должны быть обновлены, причем биты 1 и 0 выбирают дисплей, где пиксельные данные должны быть обновлены. Если первичный дисплей в клиенте не поддерживает стереоизображения, то клиент может воздействовать на пиксельные данные в первичном дисплее для одной из битовых комбинаций из 01, 10 или 11. Рекомендуется, чтобы значение 11 использовалось для адресации первичного дисплея в клиентах, которые не поддерживают функциональную возможность стереодисплея. Когда биты [1:0] имеют значения 11 (двойная логическая единица), пиксельные данные обновляются в буфере кадра как левого, так и правого глаза, если биты [1:0] имеют значения 10 (логическая единица, логический ноль), пиксельные данные обновляются в буфере кадра только левого глаза. Когда биты [1:0] имеют значения 01 (логический ноль, логическая единица), пиксельные данные обновляются в буфере кадра только правого глаза. Когда биты [1:0] имеют значения 00 (двойной логический ноль), пиксельные данные обновляются в буфере кадра альтернативного (дополнительного) дисплея, указанного битами 8-11, описанными ниже.
В одном варианте осуществления бит 2 поля "Атрибуты пиксельных данных" определяет, действительно ли буфер для левого глаза или правого глаза является источником изображения для этой операции. Бит 2 применяется, только когда биты [1:0] не равны 00, что обычно реализуется для обозначения того, что это не поддерживает данные источника из основного буфера изображения, когда местом назначения (адресатом) изображения является один из альтернативных дисплеев. Бит 2 используется, чтобы различать или задавать как между буферами кадра левого и правого глаза, так и источник данных. Когда бит 2 равен 0, тогда буфер кадра левого глаза является источником данных, но когда бит 2 равен 1, тогда буфер кадра правого глаза является источником данных.
Бит 3 поля "Атрибуты пиксельных данных" определяет, должен ли буфер, используемый для обновления дисплея, или автономный буфер изображения, быть источником изображения для этой операции. Бит 3 может также применяться к альтернативному дисплею, если альтернативный дисплей использует автономный буфер изображения. Однако он не поддерживает данные источника, являющиеся из основного буфера изображения, когда местом назначения изображения является альтернативный дисплей, или наоборот. Когда бит 3 равен значению 0 или имеет уровень логического нуля, то буфер изображения, используемый для обновления дисплея, является источником данных. Когда бит 3 равен значению 1 или имеет уровень логической единицы, автономный буфер изображения является источником данных.
Биты 7 и 6 поля "Атрибуты пиксельных данных" служат в качестве битов "Обновление дисплея", которые определяют буфер кадра, где пиксельные данные должны быть обновлены или записаны. Воздействие "Битов обновления кадра" описаны более подробно ниже. Когда биты [7:6] равны '01' (логический нуль, логическая единица), пиксельные данные записывают в автономный буфер изображения. Когда биты [7:6] равны '00' (два логических нуля), пиксельные данные записывают в буфер изображения, используемый для обновления (регенерации) дисплея. Когда биты [7:6] равны '11' (две логические единицы), пиксельные данные записывают во все буферы изображения. Если биты [7:6] равны '10', эта комбинация обрабатывается как недействительное значение. Эти биты в настоящее время зарезервированы для будущего использования. В этой ситуации вся команда игнорируется, и никакие буферы изображения не обновляются.
Биты 11-8 поля "Атрибуты пиксельных данных" формируют 4-битовое целое число без знака, которое определяет альтернативный дисплей или альтернативное место назначения (адресата) клиента, где пиксельные данные должны быть обновлены. Биты 0 и 1 установлены равными значению 00 (двум логическим нулям) для того, чтобы клиент интерпретировал биты 11-8 как номер альтернативного дисплея. Если биты 1 и 0 не равны 00, то биты 8-11 обычно устанавливаются равными значению или уровню логического нуля. Биты 4-5 и 12-15 зарезервированы для будущего использования и обычно устанавливаются равными значению или уровню логического нуля.
В одном варианте осуществления 2-х байтовое поле Raster Operation (Растровая операция) определяет, как объединять пиксели в источнике и местах назначения, чтобы сформировать новые пиксельные значения, которые должны быть записаны в место назначения изображения. Растровые операции определяют, как исходная область и область места назначения равного размера в буфере изображения объединены в области места назначения (адресате). Поток обработки для данных в растровой операции или растровых операциях проиллюстрирован на Фиг.24B. Если клиент не поддерживает поле "Растровая операция", как определено в пакете "Возможности клиента", тогда ведущее устройство обычно посылает этот пакет с битами 3-0, равными 3, и клиент игнорирует биты 3-0.
В одном варианте осуществления биты 3-0 используются, чтобы задать фактическую растровую операцию посредством использования или установки их равными одному из значений, указанных в Таблице VII, приведенной ниже, для выбора соответствующей операции, показанной рядом с этим значением. То есть каждое заданное значение битов [3:0], перечисленное в первом столбце, приводит к операции, указанной во втором столбце, и дополнительно определяется здесь для пояснения в третьем столбце.
| Таблица VII | ||
| Значение битов [3:0] | Значения, сохраненные в месте назначения | Определение |
| 0 | 0 | |
| 1 | источник & место назначения | логическая операция И |
| 2 | источник & ~ место назначения | источник И (не место назначения) |
| 3 | источник | |
| 4 | ~ источник & место назначения | (не источник) И место назначения |
| 5 | место назначения | нет операции |
| 6 | источник ^ место назначения | логическая операция ИСКЛЮЧАЮЩЕЕ ИЛИ |
| 7 | источник | место назначения | логическая операция ИЛИ |
| 8 | ~ (источник | место назначения) | не (источник ИЛИ место назначения) |
| 9 | ~ (источник ^ место назначения) | не (источник ИСКЛЮЧАЮЩЕЕ ИЛИ место назначения) |
| 10 | ~ (место назначения) | не (место назначения) |
| 11 | источник | ~ место назначения | источник ИЛИ (не место назначения) |
| 12 | ~ источник | не источник |
| 13 | ~ источник | место назначения | (не источник) ИЛИ место назначения |
| 14 | ~ (источник & место назначения) | не (источник И место назначения) |
| 15 | Все единицы | |
Биты 9-8 используются, чтобы определить, записаны или нет пиксели в места назначения (адресат), когда они относятся к прозрачному цвету. Бит 4 поля Client Feature Capability Indicators (Индикаторы возможностей характеристик дисплея) в пакете "Возможности клиента" указывает, поддерживается ли клиентом возможность прозрачного цвета и прозрачной маски. Точно так же бит 4 поля "Индикаторы возможностей характеристик дисплея" в пакете "Возможности альтернативного дисплея" (Alternate Display Capability Packet) указывает, поддерживается ли возможность прозрачного цвета и прозрачной маски указанным альтернативным дисплеем. Когда прозрачный цвет и прозрачная маска не поддерживаются, тогда растровая операция ведет себя так, как будто биты [9:8] были установлены равными '00'. Операция, указанная битами [9:8], применяется, поддерживается ли растровая операция клиентским устройством. Если клиент не поддерживает растровые операции, тогда результирующее значение пикселя адресата (места назначения), которое должно быть рассмотрено для операции, определенной битами [9:8], равно только значению пикселя источника. Это поведение является таким же, как если биты [3:0] установлены равными 3.
Когда значение битов [9:8] равно 00, тогда прозрачный цвет не используется. Результирующий пиксель адресата записан в местоположение пикселя адресата без рассмотрения значения прозрачного цвета или прозрачной маски. Прозрачный цвет определяется пакетом "Установка прозрачного цвета и маски" (Transparent Color and Mask Setup Packet). Значение битов [5:4], равное '01', в настоящее время зарезервировано для будущего использования и обычно не используется, хотя доступно для специалистов в данной области техники установить его для соответствующего использования. Когда значение битов [5:4] равно '10', результирующий пиксель не записывают в местоположение пикселя адресата, если результирующий пиксель адресата, вычисленный растровой операцией, результат операции И над исходным пикселем и прозрачной маской, равен прозрачному цвету. В противном случае его записывают в местоположение пикселя адресата. Когда значение битов [9:8] равно '11', результирующий пиксель записывают в местоположение пикселя адресата, если результирующий пиксель адресата, вычисленный растровой операцией, равен прозрачному цвету. В противном случае результирующий пиксель не записывают в местоположение пикселя адресата.
Биты 15-10 и 7-4 зарезервированы для будущего использования и поэтому обычно устанавливаются равными значению или уровню логического нуля.
Оставшиеся поля используются для определения значений координат X и Y верхнего левого угла окна, которое должно быть перемещено, ширины и высоты окна, которое должно быть перемещено, и количества пикселей, на которые окно должно быть перемещено по горизонтали и вертикали соответственно. Положительные значения для последних двух полей приводят к перемещению окна вправо и вниз, а отрицательные значения приводят к перемещению окна влево и вверх соответственно. Поле CRC (здесь 2 байта) содержит 16-битовый код CRC всех байтов в пакете, включая Длину Пакета.
15. Пакеты "Заполнение области битовой карты"
Пакет "Заполнение области битовой карты" (Bitmap Area Fill Packet) обеспечивает средства, структуру или способ для простой инициализации области отображения в один цвет. Дисплеи, которые имеют эту возможность, сообщают об этой возможности в бите 1 поля Client Feature Capability Indicators ("Индикаторы возможностей характеристик клиента") в пакете "Возможности клиента". Один вариант осуществления для формата пакета "Заполнение области битовой карты" иллюстрируется на Фиг.25. Как показано на Фиг.25, в этом случае этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Video Data Format Descriptor (Дескриптор формата данных видео), Pixel Data Attributes (Атрибуты пиксельных данных), Raster Operation (Растровая операция), Upper Left X Value (Значение X верхнего левого угла), Upper Left Y Value (Значение Y верхнего левого угла), Window Width (Ширина окна), Window Height (Высота окна), Pixel Area Fill Value (Значение заполнения пиксельной области) и CRC. Этот тип пакета обычно идентифицируется как пакет Типа 72 в 2-байтовом поле типа.
2-байтовое поле hClient ID содержит информацию или значения, которые зарезервированы для идентификатора клиента, как описано в настоящем описании. Так как это поле обычно резервируется для будущего использования, текущее значение обычно устанавливается равным нулю, устанавливая биты равными уровню логического нуля, хотя они могут быть установлены равными другим значениям или использоваться специалистами в данной области техники, чтобы передавать требуемую информацию.
Поле Video Data Format Descriptor, в этом варианте осуществления использующее 2 байта, определяет формат "Значения заполнения пиксельной области" (Pixel Area Fill Value). Этот формат является аналогичным такому же полю в пакете "Поток видео", которое описано и проиллюстрировано выше. Поле Pixel Area Fill Value ("Значения заполнения пиксельной области") (4 байта) содержит значение пикселя, которым должно быть заполнено окно, указанное параметрами в этом пакете. Формат этого пикселя определяется в поле "Дескриптор формата данных видео". Пример пиксельных форматов для "Значения заполнения пиксельной области" является таким же, как показано ранее. Если выбран формат Y Cb Cr, то прозрачный цвет и прозрачная маска должны включать в себя подполя для пикселя 1 & 2 Cb, пикселя 1 Y, пикселя 1 & 2 Cr и пикселя 2 Y точно, как показано. Количество байтов, выделенных для Transparent Color Value (Значения прозрачного цвета), определяется полем "Дескриптор формата данных видео".
Функции полей "Атрибуты пиксельных данных" и "Растровая операция" аналогичны тем же самым полям в пакете "Поблочная пересылка битовой карты", описанном выше, и представлены более подробно ниже.
Оставшиеся поля используются, чтобы определить значения координат X и Y верхнего левого угла окна, которое должно быть перемещено. Поля значений X и Y верхнего левого угла окна используют 2 байта каждое, чтобы определить значения координат X и Y верхнего левого угла окна, которое должно быть заполнено. Поля Ширина и Высота окна (2 байта каждое) определяют ширину и высоту окна, которое должно быть заполнено.
Поле CRC (здесь 2 байта) содержит 16-битовый CRC всех байтов в пакете, включая Длину Пакета.
16. Пакеты "Заполнение шаблона битовой карты"
Пакет "Заполнение шаблона битовой карты" обеспечивает средство или структуру, чтобы легко инициализировать область дисплея равным предварительно выбранному шаблону. Клиенты, которые имеют эту возможность, сообщают об этой возможности в бите 2 поля Client Feature Capability (Возможности характеристик клиента) в пакете "Возможности клиента". Верхний левый угол шаблона заполнения выровнен с верхним левым углом окна, которое должно быть заполнено, если только горизонтальное или вертикальное смещение шаблона равно нулю. Если окно, которое должно быть заполнено, шире или выше, чем шаблон заполнения, то шаблон может повторяться по горизонтали или по вертикали несколько раз, чтобы заполнить окно. Правая часть или нижняя часть последнего повторяющегося шаблона усекаются по мере необходимости. Если окно меньше, чем шаблон заполнения, то правая сторона или нижняя часть шаблона заполнения могут быть усечены, чтобы вписаться в окно.
Если горизонтальное смещение шаблона ненулевое, то пиксели между левой стороной окна и левой стороной плюс горизонтальное смещение шаблона заполняются наиболее правыми пикселями шаблона. Горизонтальное смещение шаблона должно быть меньше, чем ширина шаблона. Аналогично, если вертикальное смещение шаблона ненулевое, то пиксели между верхней стороной окна и верхней стороной плюс вертикальное смещение шаблона заполняются самыми нижними пикселями шаблона. Вертикальное смещение шаблона должно быть меньше, чем высота шаблона.
Один вариант осуществления для формата пакета "Заполнение шаблона битовой карты" иллюстрируется на Фиг.26. Как показано на Фиг.26, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Video Data Format Descriptor (Дескриптор формата данных видео), Атрибуты пиксельных данных, Растровая операция, Значение X верхнего левого угла, Значение Y верхнего левого угла, Ширина окна, Высота окна, Pattern Width (Ширина шаблона), Pattern Height (Высота шаблона), Horizontal Pattern Offset (горизонтальное смещение шаблона), Vertical Pattern Offset (Вертикальное смещение шаблона), Параметр CRC, Pattern Pixel Data (Пиксельные данные шаблона) и Pixel Data CRC (CRC пиксельных данных). В некоторых вариантах осуществления этот тип пакета обычно идентифицируется как пакет Типа 73 в 1-байтовом поле типа.
2-байтовое поле hClient ID содержит информацию или значения, которые зарезервированы для идентификатора клиента, как описано в настоящем описании. Так как это поле обычно резервируется для будущего использования, текущее значение обычно устанавливается равным нулю, устанавливая биты равными уровню логического нуля.
2-байтовое поле "Дескриптор формата данных видео" определяет формат "Значения заполнения пиксельной области" (Pixel Area Fill Value). Фиг.11 иллюстрирует, как кодируется Дескриптор формата данных видео. Формат является таким же самым, как то же самое поле в пакете "Поток видео".
Функция полей "Атрибуты пиксельных данных" и "Растровая операция" аналогична тем же самым полям в пакете "Поблочная пересылка битовой карты", описанном выше, и представлена ниже более подробно.
Оставшиеся поля пакета "Заполнение шаблона битовой карты" используются, чтобы определить значения координат X и Y верхнего левого угла окна, которое должно быть заполнено, ширины и высоты окна, которое должно быть заполнено, ширины и высоты шаблона, который нужно использовать в качестве шаблона заполнения, и горизонтальные и вертикальные смещения шаблона пиксельных данных от левой и верхней границ соответственно указанного окна, которое должно быть заполнено. Поле CRC шаблона (здесь 2 байта) содержит 16-битовый код CRC всех байтов в пакете от поля Длина Пакета до Дескриптора формата видео. Если этот CRC при проверке выдает ошибку, тогда весь пакет должен быть отвергнут. Поле CRC пиксельных данных шаблона содержит 16-битовый код CRC только пиксельных данных шаблона. Если этот CRC при проверке выдает ошибку, тогда пиксельные данные шаблона могут все еще использоваться, но значение подсчета ошибок кода CRC должно быть увеличено. Поле «Пиксельные данные шаблона" содержит информацию необработанного видео, которая определяет шаблон заполнения в формате, указанном "Дескриптором формата данных видео".
17. Пакеты "Буфер кадра считывания"
Пакет "Буфер кадра считывания" (Read Frame Buffer Packet) обеспечивает структуру, средство или способ для выбора, обнаружения или задания прямоугольной области буфера кадра в клиенте, который должен быть передан назад на ведущее устройство по обратной линии связи. Формат возвращенных пиксельных данных находится в родном формате дисплея, и этот формат обычно определяется в поле Data Format Descriptor (Дескриптор формата данных) в пакетах «Поток видео», посылаемых по обратной линии связи на ведущее устройство. Пиксельные данные, которые возвращают ведущему устройству, выдают из буфера изображения, данные которого в настоящее время отображаются. Клиент обычно использует столько пакетов «Поток видео» в стольких пакетах «Инкапсуляция обратной линии связи», которые необходимы для того, чтобы возвратить область дисплея, указанную пакетом "Буфер кадра считывания". Клиенты, которые имеет эту возможность, могут указывать ее или сообщать об этой возможности, используя бит 3 поля Client Feature Capability Indicators (Индикаторы возможностей характеристик клиента) в пакете "Возможности клиента".
Формат варианта осуществления для пакета "Буфер кадра считывания" иллюстрируется на Фиг.27. Как показано на Фиг.27, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Display Data Attributes (Атрибуты данных дисплея), X Left Edge (X левой границы), Y Tope Edge (Y верхней границы), X Right Edge (X правой границы), Y Bottom Edge (Y нижней границы) и CRC. В одном варианте осуществления этот тип пакета обычно идентифицируется как пакет Типа 74 в поле типа.
2-байтовое поле Длина Пакета (Packet Length) определяет общее количество байтов в пакете, не включая поле длины пакета. В одном варианте осуществления эта длина пакета установлена равной 16. 2-байтовое поле hClient ID содержит информацию или значения, которые зарезервированы для идентификатора клиента, как используется выше. Так как это поле обычно резервируется для будущего использования, текущее значение установлено равным нулю, устанавливая биты в '0' (уровень или состояние логического нуля), хотя оно может использоваться специалистами в данной области техники, чтобы передавать требуемую информацию.
В одном варианте осуществления 2-байтовое поле Display Data Attributes имеет значения, которые определяют, где пиксельные данные должны быть считаны, при этом бит 0 выбирает буфер кадра, из которого пиксельные данные должны быть считаны. Когда бит 0 равен значению 0 (логический нуль), пиксельные данные считываются из буфера кадра дополнительного (альтернативного) дисплея, указанного битами 8-11, как описано ниже. Когда бит 0 равен значению 1 (логическая единица), пиксельные данные считываются из буфера кадра первичного дисплея.
В одном варианте осуществления бит 2 поля Display Data Attributes определяет, является ли буфер для буфера кадра для левого глаза или правого глаза источником данных, которые нужно считывать. Обычно бит 2 может применяться, только когда первичный дисплей поддерживает стереоизображения. Когда бит 2 равен 0 (уровень логического нуля), тогда буфер кадра левого глаза является источником данных, но когда бит 2 равен 1 (уровень логической единицы), тогда буфер кадра правого глаза является источником данных.
Бит 3 поля Display Data Attributes определяет, какой буфер - используемый для обновления (регенерации) дисплея или автономный буфер изображения - должен быть источником изображения для этой операции. Бит 3 может также применяться к альтернативному дисплею, если альтернативный дисплей использует автономный буфер изображения. Однако в этом случае не поддерживается источник данных из основного буфера изображения, когда адресатом изображения является альтернативный дисплей, или наоборот. Когда бит 3 равен значению 0 или уровню логического нуля, буфер изображения, используемый для регенерации дисплея, является источником данных. Когда бит 3 равен значению 1 или уровню логической единицы, автономный буфер изображения является источником данных.
Биты 11-8 поля Display Data Attributes определяют дисплей или альтернативное местоположение клиента, где пиксельные данные должны считываться. Бит 0 установлен равным значению 0 (логический нуль), чтобы клиент интерпретировал биты 11-8 как номер альтернативного дисплея. Если бит 0 не равен 0, тогда биты 8-11 обычно устанавливаются равным значению или уровню логического нуля. Биты 1, 4-7 и 12-15 зарезервированы для будущего использования и обычно устанавливаются равными уровням логического нуля или нулевым значениям.
В одном варианте осуществления 2-байтовые поля X Left Edge и Y Top Edge задают (определяют) координату X левой границы и координату Y верхней границы окна на экране, заполненного полем «Пиксельные данные», в то время как поля X Right Edge и Y Bottom Edge определяют координату X правой границы и координату Y нижней границы обновляемого окна.
В одном варианте осуществления 2-байтовое поле CRC определяет или содержит CRC всех байтов в пакете, включая поле «Длина пакета».
18. Пакеты «Состояние потребления энергии дисплеем»
Пакет «Состояние потребления энергии дисплеем» (Display Power State Packet) обеспечивает структуру, средства или способ для перевода управляемого конкретным клиентом, или относящегося или соединенного с клиентом, или аппаратного контроллера в состояние потребления малой мощности, когда клиент, такой как дисплей, не используется или не находится в текущем активном использовании, чтобы минимизировать потребляемую мощность системы или потребление системных ресурсов. Пакет этого типа наиболее полезен для применений интерфейса или интерфейсных структуры и протокола для конфигураций или операций внешнего режима. В таких применениях более вероятно, что внешнее устройство работает на ресурсах ограниченной мощности, например батареях, или имеет другие ограничения мощности и требования, например перегрев в ограниченных пространствах и т.д., так что желательны минимальные эксплуатационные условия в течение периодов или неактивности, или неиспользования. В одном варианте осуществления клиент указывает способность отвечать на пакеты «Состояние потребления энергии дисплеем» (Display Power State Packets), используя бит 9 поля Client Feature Capability Indicators (Индикаторы возможностей характеристик клиента) в пакете "Возможности клиента".
Формат одного варианта осуществления для пакета «Состояние потребления энергии дисплеем» иллюстрируется на Фиг.28. Как показано на Фиг.28, в одном варианте осуществления этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Power State (Состояние потребления энергии) и CRC. Этот тип пакета обычно идентифицируется как пакет Типа 75 в 2-байтовом поле типа и использует предварительно выбранную фиксированную длину 8 байтов. 2-байтовое поле hClient ID содержит информацию или значения, которые зарезервированы для идентификатора клиента, как используется выше. Так как это поле обычно резервируется для будущего использования, текущее значение установлено равным нулю, устанавливая биты в '0' (уровень или состояние логического нуля), хотя может использоваться специалистами в данной области техники для передачи требуемой информации.
Поле Power State, здесь длиной 2 байта, определяет информацию, используемую для перевода конкретного устройства, части аппаратных средств или оборудования, ассоциированного с клиентом, например дисплея, в указанное состояние потребления энергии. При использовании в отношении дисплеев бит 0 этого поля определяет, применяется ли пакет к основному дисплею или альтернативному дисплею. Если бит 0 равен 1, тогда пакет применяется к основному дисплею. Если бит 0 равен 0, тогда пакет применяется альтернативному дисплею, указанному битами 11-8. Бит 1 зарезервирован для будущего использования и обычно устанавливается равным нулю.
Биты 3-2 поля Power State определяют состояние потребления энергии дисплеем, выбранным битами 11-8 и битом 0. Когда биты [3:2] имеют значение '00', выбранный дисплей не подсвечивается и должен потреблять минимальное количество мощности и не гарантируется, что содержание буфера кадра будет сохранено в течение этого состояния. Когда биты [3:2] имеют значение '01', выбранный дисплей не подсвечивается и потребляет относительное минимальное количество мощности и гарантируется, что содержание буфера кадра будет сохранено в течение этого состояния. Дисплей может потреблять больше мощности в этом состоянии, чем в состоянии 00. Клиент может указывать способность поддерживать состояние 01, используя бит 10 поля Client Feature Capability Indicators (Индикаторы возможностей характеристик клиента) в пакете "Возможности клиента". Когда биты [3:2] поля Power State имеют значение '10', выбранный дисплей подсвечивается и отображает изображение из соединенного с ним буфера кадра. Значение '11' для битов [3:2] является зарезервированным значением или состоянием для будущего использования и не используется.
Специалистам в данной области техники понятно, что хотя наиболее полезное для применения в отношении дисплея, в соответствии с настоящим изобретением использование этого пакета не ограничено только дисплеями и могут существовать другие применения, конфигурации или ситуации, в которых регулирование потребления энергии может быть необходимо или требоваться в отношении других аппаратных элементов, с которыми используется MDDI или для которых клиент является управляемым или обменивающимся по линии связи. В этих ситуациях биты, раскрытые выше, могут иметь аналогичные функции, но могут активизировать главные и вторичные такие элементы или настройки уровней мощности и т.д., как будет понятно.
В одном варианте осуществления биты 11-8 поля Power State формируют 4-битовое целое число без знака, которое определяет альтернативный дисплей, к которому применяется состояние потребления энергии. Бит 0 установлен равным значению логического нуля, чтобы клиент интерпретировал биты 11-8 как номер альтернативного дисплея. Если бит 0 равен 1, то биты 11-8 равны нулю.
Биты 7-4 и биты 15-12 зарезервированы для будущего использования и обычно должны быть установлены равными уровню или значению логического нуля для текущих приложений или проектов.
2-байтовое поле CRC определяет или содержит CRC всех байтов в пакете, включая Длину Пакета.
Суммированная информация о том, состояние потребления энергии какого дисплея обычно поддерживаются структурой интерфейса или протоколом, представлено в Таблице VIII ниже. Как может быть видно, различные комбинации битов 10 и 9 «Возможности характеристик клиента» (Client Feature Capability) используются, чтобы установить, настроить или инициировать различные из требуемых состояний мощности. Метка, присутствующая в заданной позиции строки и столбца, указывает, что состояние потребления энергии дисплеем, указанное сверху этого столбца, поддерживается для указанной комбинации битов в поле Client Feature Capability Indicators. Можно видеть, что первая и третья строки Таблицы VIII указывают, что только состояние потребления энергии "10" разрешено, когда клиент не имеет способности поддерживать пакет «Состояние потребления энергии дисплеем». Даже хотя состояние потребления энергии дисплеем не может быть послано дисплею, отдельная метка указывает, что дисплей находится в состоянии "всегда включен" и не может быть помещен в состояние потребления малой мощности с использованием этого набора битов.
| Таблица VIII | |||
| Биты 9 и 10 Индикатора возможностей характеристик клиента | Состояние потребления энергии = 00 | Состояние потребления энергии = 01 | Состояние потребления энергии = 10 |
| Бит 9 = 0 и бит 10 = 0 | Х | ||
| Бит 9 = 1 и бит 10 = 0 | Х | Х | |
| Бит 9 = 0 и бит 10 = 1 | Х | ||
| Бит 9 = 1 и бит 10 = 1 | Х | Х | Х |
19. Пакеты «Выполнение передачи обслуживания в режим определенного типа»
Пакет «Выполнение передачи обслуживания в режим определенного типа» (Perform Type Handoff Packet) является средством, структурой или способом для ведущего устройства, чтобы использовать с целью выдавать команды клиенту для переключения в режим, указанный в этом пакете. Должен существовать один параметр настройки типа интерфейса, поддерживаемый клиентом, как описано в пакете "Возможности клиента". Ведущее устройство и клиент должны переключиться на указанный тип интерфейса прямой и обратной линии связи сразу после того, как этот пакет послан. Формат одного варианта осуществления для пакета «Выполнение передачи обслуживания в режим определенного типа» иллюстрируется на Фиг.29. Ведущие устройства и клиенты, которые поддерживает тип интерфейса, отличный от Типа 1, должны обеспечить поддержку для этого пакета. Обычно рекомендуется, чтобы ведущее устройство считывало пакет «Запрос клиента и состояния» непосредственно прежде, чем оно пошлет пакет «Выполнение передачи обслуживания в режим определенного типа», чтобы подтвердить, что клиент находится в синхронизме с ведущим устройством.
Как показано на Фиг.29, в одном варианте осуществления этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, Interface Type (Тип интерфейса), Reserved 1 (Зарезервированное 1), Delay Filler (Заполнитель задержки) и CRC. Этот тип пакета обычно идентифицируется как пакет Типа 77 в 2-байтовом поле типа.
В одном варианте осуществления поле “Тип интерфейса” использует 1-байтовое значение, чтобы подтвердить новый тип интерфейса, который нужно использовать или используется для линии связи. Значение в этом поле определяет или представляет тип интерфейса следующим образом. Биты 2-0 определяют тип интерфейса, который нужно использовать на прямой линии связи, причем значение 1 означает или определяет передачу обслуживания в режим Типа 1; значение 2 - передачу обслуживания в режим Типа 2, значение 3 - передачу обслуживания в режим Типа 3 и значение 4 - передачу обслуживания в режим Типа 4. Биты 5-3 определяют Тип интерфейса, который нужно использовать на обратной линии связи, причем значение 1 означает или определяет передачу обслуживания в режим Типа 1, значение 2 - передачу обслуживания в режим Типа 2, значение 3 - передачу обслуживания в режим Типа 3 и значение 4 - передачу обслуживания в режим Типа 4. Значения 0, 5-7 в настоящее время зарезервированы для будущего использования.
Поле Delay Filler (Заполнитель задержки) было создано как средство, структура или способ для обеспечения достаточного времени со стороны системы для того, чтобы клиент подготовился или был сконфигурирован для переключения, чтобы использовать или установить для использования настройки нового типа интерфейса в начале пакета, который немедленно следует за пакетом «Выполнение передачи обслуживания в режим определенного типа». Это поле содержит группу байтов или 8-битовых значений, которые все установлены или равны уровню или значению логического нуля. Количество байтов, используемых в этом поле, выбрано таким, что это приводит к тому, что поле является эквивалентом длины 64 тактов MDDI_Stb. Длина поля Delay Filer основана на настройке типа интерфейса прямой линии связи, которая равна 16 байтов для Типа 1 интерфейса прямой линии связи, 32 байта для Типа 2 интерфейса, 64 байта для Типа 3 интерфейса и 128 байтов при определении или использовании Типа 4 интерфейса прямой линии связи.
Поле Зарезервированное 1 (здесь 1 байт) зарезервировано для будущего использования при передаче информации. Уровень всех битов в этом поле обычно устанавливается равным логическому нулю. Задача таких полей в настоящее время состоит в том, чтобы выровнять все последующие 2-байтовые поля до 16-битового адреса слова и выровнять 4-байтовые поля до 32-битового адреса слова. Поле CRC (здесь 2 байта) содержит 16-битовый код CRC всех байтов в пакете, включая поле Длина Пакета.
20. Пакеты «Разрешение прямого канала аудио»
Этот пакет (Forward Audio Channel Enable Packet) обеспечивает структуру, способ или средство, которое позволяет ведущему устройству разрешать или запрещать (отключать) аудиоканалы в клиенте. Эта функциональная возможность полезна тем, что клиент (дисплей, например) может отключать энергию от усилителей аудиосигнала или аналогичных элементов схемы, чтобы экономить энергию, когда не имеется никакого аудиосигнала для вывода посредством ведущего устройства. Это значительно более трудно осуществить неявно, просто используя наличие или отсутствие аудиопотоков в качестве индикатора. Заданное по умолчанию состояние, когда клиентская система включается, является таким, что все аудиоканалы разрешены. Формат одного варианта осуществления пакета «Разрешение прямого канала аудио» иллюстрируется на Фиг.30. Как показано на Фиг.30, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Audio Channel Enable Mask (Маска разрешения канала аудио) и CRC. Этот тип пакета обычно идентифицируется как пакет Типа 78 в 1-байтовом поле типа и использует заранее выбранную фиксированную длину в 4 байта.
21. Пакеты «Частота выборки аудио обратной линии связи»
Этот тип пакета (Reverse Audio Sample Rate Packet) обеспечивает структуру, способ или средство, которое позволяет ведущему устройству разрешать или отключать аудиоканалы в клиенте. Эта возможность полезна тем, что клиент может отключать энергию от усилителей аудио, чтобы сохранять энергию, когда не имеется никакого аудиосигнала для вывода ведущим устройством. Это значительно более трудно осуществить, неявно используя наличие или отсутствие аудиопотоков. Заданное по умолчанию состояние, когда клиентская система включена или подсоединена к ведущему устройству, является таким, что все аудиоканалы разрешены. Аудиосистема, соединенная с ведущим устройством и клиентом, должна быть готова или способна выводить сигналы аудио назначенным или требуемым способом в пределах приблизительно 100 мс или меньше после того, как клиент принимает пакет «Частота выборки аудио обратной линии связи», имеющий по меньшей мере один из битов в поле Audio Channel Enable Mask (Маска разрешения канала аудио), который переходит из состояния или значения нуля в единицу. Клиент указывает возможность отвечать на пакет «Частота выборки аудио обратной линии связи», используя набор значений для бита 15 поля Audio Channel Capability (Возможности канала аудио) в пакете "Возможности клиента".
Этот пакет позволяет ведущему устройству разрешать или отключать аудиоканал обратной линии связи и устанавливать частоту выборки аудиоданных этого потока. Ведущее устройство выбирает частоту выборки, которая определяется так, чтобы быть действительной, в пакете "Возможности клиента". Если ведущее устройство выбирает недействительную частоту выборки, то клиент не будет посылать аудиопоток ведущему устройству и соответствующая ошибка, значение ошибки или сигнал ошибки, может быть послана ведущему устройству в пакете «Отчет об ошибках клиента» (Client Error Report Packet). Ведущее устройство может запрещать аудиопоток обратной линии связи, устанавливая частоту выборки равной значению 255. Заданное по умолчанию состояние принимается, когда клиентская система первоначально включается или подсоединяется при запрещенном аудиопотоке обратной линии связи. Формат в одном варианте осуществления для пакета «Частота выборки аудио обратной линии связи» иллюстрируется на Фиг.31. Как показано на Фиг.31, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Audio Sample Rate (Частота выборки аудио), Зарезервированное 1 и CRC. Этот тип пакета обычно идентифицируется как пакет Типа 79 и использует предварительно выбранную фиксированную длину, равную 4 байтам.
22. Служебные пакеты «Защита цифрового контента»
Этот пакет (Digital Content Protection Overhead Packet) обеспечивает структуру, способ или средство, которые позволяют ведущему устройству и клиенту обмениваться сообщениями, относящимися к способу защиты цифрового контента. В настоящее время рассматриваются два типа защиты контента - Система цифровой защиты передачи контента (Digital Transmission Content Protection, DTCP) или Широкополосная цифровая защита контента (High-bandwidth Digital Content Protection, HDCP) с объемом памяти, зарезервированным для будущих альтернативных схем защиты. Используемый способ задается параметром Content Protection Type (Тип защиты контента) в этом пакете. Формат варианта осуществления служебного пакета «Защита цифрового контента» иллюстрируется на Фиг.32. Как показано на Фиг.32, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, bClient ID (Идентификатор клиента), Content Protection Type (Тип защиты контента), Content Protection Overhead Messages (Служебные сообщения защиты контента) и CRC. Этот тип пакета обычно идентифицируется как пакет Типа 80.
23. Пакеты «Установка прозрачного цвета и маски»
Пакет «Установка прозрачного цвета и маски» (Transparent Color and Mask Setup Packet) является структурой, способом или средством, которое используется для определения, какой цвет является прозрачным, и для того, чтобы разрешать или запрещать (отключать) использование прозрачного цвета для отображения изображений. В одном варианте осуществления клиенты или дисплеи, которые имеют эту возможность, будут сообщать об этой возможности, используя бит 4 поля Client Feature Capability (Возможность характеристик клиента) в пакете "Возможности клиента". Когда пиксель со значением для прозрачного цвета записан в битовую карту, цвет не изменяется по сравнению с предыдущим значением. Формат пакета «Установка прозрачного цвета» иллюстрируется на Фиг.33. Как показано на Фиг.33, в одном варианте осуществления этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Атрибуты данных дисплея, Зарезервированное 1, Дескриптор формата данных, Transparent Color Value (Значение прозрачного цвета), Transparent Mask Value (Значение прозрачной маски) и CRC. Этот тип пакета обычно идентифицируется как пакет Типа 81 в 1-байтовом поле типа и использует предварительно выбранную фиксированную длину 16 байтов.
Поле hClient ID зарезервировано для использования в качестве идентификатора клиента в будущих реализациях и обычно устанавливается равным нулевому значению (битам логического нуля).
В одном варианте осуществления 2-байтовое поле Display Data Attributes (Атрибуты данных отображения) имеет значения, которые определяют, где прозрачный цвет пикселя должен быть применен, причем бит 0 выбирает дисплей, в котором прозрачный цвет пикселя должен быть применен. Когда бит 0 равен значению 0 (логический нуль), прозрачный цвет пикселя применяется в альтернативном дисплее, указанном битами 8-11, как описано ниже. Когда бит 0 равен значению 1 (логическая единица), прозрачный цвет пикселя применяется в первичном дисплее.
В одном варианте осуществления бит 1 выбирает или определяет, содержит ли поле Transparent Color or Mask (Прозрачный цвет или маска) прозрачный цвет или прозрачную маску. Когда бит 0 равняется 0 (логический нуль), поле «Прозрачный цвет или маска» содержит значение прозрачного цвета, который нужно использовать в последующих растровых операциях или при декодировании пакета «Поток видео» или пакета «Масштабируемый поток видео». Когда бит 0 равен 1 (логическая единица), поле «Прозрачный цвет или маска» содержит значение прозрачной маски, которое нужно использовать в последующих растровых операциях или при декодировании пакета «Поток видео» или пакета «Масштабируемый поток видео».
Биты 11-8 поля Display Data Attributes (Атрибуты данных отображения) определяют дисплей или альтернативное местоположение клиента, к которому прозрачный цвет пикселя должен быть применен. Бит 0 установлен равным значению 0 (логический нуль), чтобы клиент интерпретировал биты 11-8 как номер альтернативного дисплея. Если бит 0 не равен 0, то биты 8-11 обычно устанавливаются равным значению или уровню логического нуля и игнорируются.
Биты 7-2 и 15-12 поля Display Data Attributes зарезервированы для будущего использования и обычно устанавливаются равными уровню логического нуля или нулевому значению.
Поле "Зарезервированное 1" из 2 байтов зарезервировано для будущего использования. Все биты в этом поле обычно устанавливаются равными нулю (уровень или состояние логического нуля). В одном варианте осуществления одна из целей этого поля состоит в том, чтобы выровнять все последующие 2-байтовые поля до 16-битового адреса слова и выровнять 4-байтовые поля до 32-битового адреса слова.
В одном варианте осуществления поле Video Data Format Descriptor (Дескриптор формата данных видео) в пакете «Разрешение прозрачного цвета» использует 2 байта, чтобы определить формат значения прозрачного цвета. Фиг.11 иллюстрирует, как закодирован «Дескриптор формата данных видео». Этот формат является обычно таким же, как то же самое поле в пакете «Поток видео».
В одном варианте осуществления поле Transparent Color Value (Значение прозрачного цвета) используется, чтобы определить или назначить несколько байтов (в этом примере определены как Длина пакета - 12 для не "значащих" полей и поделено на 2, чтобы совместно использовать с полем «Прозрачная маска») для значения пикселя, которое нужно использовать в качестве значения прозрачного цвета в последующих растровых операциях или при декодировании пакета «Поток видео» или пакета «Масштабируемый поток видео». Формат этого значения задан в поле «Дескриптор формата данных видео». Примеры пиксельных форматов для прозрачного цвета являются такими же, как показано выше. Если выбран формат Y Cb Cr, то прозрачный цвет и прозрачная маска обычно включают в себя подполя для Пикселя 1 и 2 Cb, Пикселя 1 Y, Пиксель 1 и 2 Cr и Пикселя 2 Y точно, как показано ранее. Количество байтов, назначенных для «Значение прозрачного цвета», определяется полем «Дескриптор формата данных видео».
В одном варианте осуществления поле Transparent Mask Value (Значение прозрачного цвета) используется, чтобы определить или назначить несколько байтов (в этом примере определены как Длина пакета - 12 для не "значащих" полей и поделено на 2, чтобы совместно использовать с полем «Прозрачная маска») для пиксельного значения, которое нужно использовать в качестве прозрачной маски в последующих растровых операциях или при декодировании пакета «Поток видео» или пакета «Масштабируемый поток видео». Формат этого значения идентичен формату «Значение прозрачного цвета», который определяется в поле «Дескриптор формата данных видео». Количество байтов, распределенных для этого поля, определяется полем «Дескриптор формата данных видео». Длина этого поля идентична длине поля «Значение прозрачного цвета».
В одном варианте осуществления поле «Значение прозрачного цвета или маски» использует или назначает 4 байта для пиксельного значения, которое нужно использовать в качестве значения или прозрачного цвета или прозрачной маски, как определяется битом 1 поля Display Data Attributes. Формат этого пикселя определяется в поле «Дескриптор формата данных видео».
Поле CRC использует 2 байта, чтобы содержать или выразить CRC для всех байтов в пакете, включая Длину Пакета.
24. Пакеты "Измерение задержки прохождения сигнала в прямом и обратном направлениях"
Пакет "Измерение задержки прохождения сигнала в прямом и обратном направлениях" (Round Trip Delay Measurement Packet) обеспечивает структуру, способ или средство, которые используются, чтобы измерить задержку распространения от ведущего устройства до клиента (дисплея) плюс задержку от клиента (дисплея) назад на ведущее устройство. Это измерение неотъемлемо включает в себя задержки, которые существуют в задающих устройствах и приемниках линии и подсистеме межсоединений. Это измерение используется, чтобы установить задержку полного изменения и параметров делителя скорости передачи обратной линии связи в пакете "Инкапсуляция обратной линии связи», описанном в общем виде выше. Этот пакет наиболее полезен, когда линия связи MDDI запускается при максимальной скорости передачи, предназначенной для конкретного приложения. Этот пакет может быть послан в режиме Типа 1 и при более низкой скорости передачи данных, чтобы увеличить диапазон измерения задержки прохождения сигнала в прямом и обратном направлениях. Сигнал MDDI_Stb ведет себя так, как если бы все нулевые данные были посланы в следующих полях: оба Guard Times (Защитных интервала времени), All Zero (Все нули) и Measurement Period (Период измерения). Это заставляет MDDI_Stb переключаться с половинной скоростью передачи данных, так что он может использоваться в качестве сигнала периодической синхронизации в клиенте в течение Периода измерения.
В одном варианте осуществления клиент обычно указывает способность поддерживать пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях" посредством использования бита 18 поля Client Feature Capability Indicators (Индикаторы возможностей характеристик клиента) в пакете "Возможности клиента". Рекомендуется, чтобы все клиенты поддерживали измерение задержки прохождения сигнала в прямом и обратном направлениях, но для ведущего устройства возможно знать наихудший случай задержки прохождения сигнала в прямом и обратном направлениях на основании максимальной задержки в кабеле и максимальных задержках задающего устройства и приемника. Ведущее устройство может также знать задержку прохождения сигнала в прямом и обратном направлениях заранее для линии связи MDDI, используемой во внутреннем режиме, так как это является аспектом известных элементов конструкции (длины проводников, типа схем и характеристик и т.д.) устройства, в котором используется этот интерфейс.
Формат пакета "Измерение задержки прохождения сигнала в прямом и обратном направлениях" иллюстрируется на Фиг.34. Как показано на Фиг.34, в одном варианте осуществления этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Параметр CRC, Guard Time 1 (Защитный интервал времени 1), Период измерения, Все нули и Guard Time 2 (Защитный интервал времени 2). Этот тип пакета обычно идентифицируется как пакет Типа 82 и использует предварительно выбранную фиксированную длину, равную 200 битам.
Временная диаграмма событий, которые имеют место в течение пакета "Измерение задержки прохождения сигнала в прямом и обратном направлениях", иллюстрируется на Фиг.35. На Фиг.35 ведущее устройство передает пакет "Измерение задержки прохождения сигнала в прямом и обратном направлениях", показанный наличием полей Параметр CRC и Strobe Alignment (Выравнивание строба) с последующими полями "Все нули 1" и "Защитный интервал времени 1". Задержка 3502 имеет место прежде, чем пакет достигает устройства отображения клиента или схемы обработки. Когда клиент принимает этот пакет, он передает 0xff, 0xff и 30 байтов шаблона 0x00 точно так, как практически реализовано в начале "Периода измерения", как определено клиентом. Фактический момент времени, когда клиент начинает передавать эту последовательность, является отсроченным с начала "Периода измерения" с точки зрения ведущего устройства. Величина этой задержки является, по существу, временем, которое требуется для распространения пакета через задающие устройства и приемники линии и подсистему межсоединений (кабели, проводники). Аналогичная величина задержки 3504 испытывается шаблоном для распространения от клиента назад на ведущее устройство.
Чтобы точно определить задержку времени прохождения сигнала в прямом и обратном направлениях, для сигналов, проходящих к и от клиента, ведущее устройство подсчитывает количество периодов времени передачи бита по прямой линии связи, встречающихся после начала "Периода измерения", пока не будет обнаружено начало последовательности 0xff, 0xf и 30 байтов 0x00 после их поступления. Эта информация используется для определения промежутка времени для прохождения сигнала в прямом и обратном направлениях, когда он проходит от ведущего устройства до клиента и обратно назад. Когда используются режимы или обратные линии связи Типов 2-4, ведущее устройство измеряет и сохраняет значение времени прохождения сигнала в прямом и обратном направлениях всех пар MDDI_Data в случае, если скорость передачи данных и сдвиг во времени задержки прохождения сигнала в прямом и обратном направлениях являются достаточно большими, чтобы повлиять на время прибытия каждого бита по отдельности.
Ведущее устройство и клиент оба устанавливают на линии уровень логического нуля в течение обоих защитных интервалов времени, чтобы сохранить линии MDDI_Data в определенном состоянии. Времена разрешения и отключения (запрещения) ведущего устройства и клиента в течение обоих защитных интервалов времени являются такими, что сигналы MDDI_Data имеют всегда действительный низкий уровень для любого действительного времени прохождения сигнала в прямом и обратном направлениях.
Ведущее устройство и клиент оба устанавливают на линии уровень логического нуля в течение обоих защитных интервалов времени, чтобы сохранить линии MDDI_Data в определенном состоянии. Времена разрешения и отключения (запрещения) ведущего устройства и клиента в течение обоих защитных интервалов времени являются такими, что сигналы MDDI_Data имеют действительные низкие уровни для любого действительного времени прохождения сигнала в прямом и обратном направлениях.
25. Пакет "Калибровка сдвига во времени прямой линии связи"
В одном варианте осуществления пакет "Калибровка сдвига во времени прямой линии связи" (Forward Link Skew Calibration Packet) позволяет клиенту или дисплею калибровать самого себя для разностей в задержке распространения сигналов MDDI_Data относительно сигнала MDDI_Stb. Без компенсации сдвига во времени задержки максимальная скорость передачи данных обычно является ограниченной, чтобы учесть потенциальные изменения в наихудшем случае этих задержек. Обычно рекомендуется, чтобы этот пакет был послан, только когда скорость передачи данных прямой линии связи задана как скорость передачи, приблизительно равная 50 Мбит/с или ниже. После посылки этого пакета для калибровки дисплея скорость передачи данных может быть увеличена более 50 Мбит/с. Если скорость передачи данных установлена слишком высокой в течение процесса калибровки сдвига во времени, клиент может синхронизироваться к смещению периода битов, который вероятно приведет к установке компенсации сдвига задержки, которая будет "уходить" более, чем на период одного бита, приводя к ошибочной синхронизации данных. Наивысший тип скорости передачи данных интерфейса или наибольший возможный Тип интерфейса выбирают до посылки пакет "Калибровка сдвига во времени прямой линии связи", так чтобы все существующие информационные биты были калиброваны. Клиент указывает способность поддерживать пакет "Калибровка сдвига во времени прямой линии связи", используя бит 19 поля "Индикаторы возможностей характеристик клиента" в пакете "Возможности клиента".
До выполнения калибровки сдвига во времени ведущее устройство не должно посылать данные быстрее, чем скорость передачи, указанная полем Pre-calibration Data Rate Capability (Возможность скорости передачи данных до калибровки) в пакете "Возможности клиента". Однако после того, как калибровка выполнена, ведущее устройство может посылать данные со скоростью передачи, определяемой полем Post-calibration data rate Capability (Возможность скорости передачи данных после калибровки). Рекомендуется, чтобы ведущее устройство посылало пакет "Калибровка сдвига во времени прямой линии связи" через регулярные интервалы времени, чтобы корректировать изменения в относительной задержке между различными парами сигналов из-за изменений температуры.
Один вариант осуществления формата пакета "Калибровка сдвига во времени прямой линии связи" иллюстрируется на Фиг.56. Как показано на Фиг.56, этот тип пакета структурирован так, что имеет поля Длина Пакета (2 байта), Тип Пакета, hClient ID (Идентификатор клиента), Параметр CRC, Все Нули 1, Calibration Data Sequence (Последовательность данных калибровки) и Все Нули 2. Этот тип пакета обычно идентифицируется как пакет Типа 83 в поле типа.
Виртуальная панель управления
Использование VCP (Виртуальной панели управления) позволяет ведущему устройству устанавливать некоторые средства управления клиентом в клиенте. Разрешая корректировку этих параметров с помощью ведущего устройства, пользовательский интерфейс в клиенте может быть упрощен, так как экранные изображения, которые позволяют пользователю корректировать параметры, такие как уровень аудио или яркость дисплея, могут быть сформированы программным обеспечением ведущего устройства, а не одним или более микропроцессорами в клиенте. Ведущее устройство имеет способность считывать настройки параметров в клиенте и определять диапазон действительных значений для каждого средства управления. Клиент обычно имеет функциональную возможность сообщить назад на ведущее устройство, какие параметры управления могут быть откорректированы.
Управляющие коды (коды VCP) и ассоциированные значения данных, обычно указанные, используются для конкретного задания средств управления и параметров настройки в клиенте. Коды VCP в спецификации MDDI расширены до 16 битов, чтобы сохранить надлежащее выравнивание полей данных в определениях пакета и в будущем поддерживать дополнительные значения, которые являются уникальными для этого интерфейса или будущих расширений.
26. Пакет "Запрос характеристик VCP"
Пакет "Запрос характеристик VCP" (Request VCP Feature Packet) обеспечивает средства, механизм или способ для ведущего устройства, чтобы запрашивать текущие установки (параметры настройки) конкретного параметра управления или всех действительных параметров управления. Обычно клиент отвечает на Пакет VCP соответствующей информацией в пакете "Ответ с характеристиками VCP" (VCP Feature Reply Packet). В одном варианте осуществления клиент указывает способность поддерживать пакет "Запрос характеристик VCP", используя бит 13 поля "Индикаторы возможностей характеристик клиента" в пакете "Возможности клиента".
Формат пакета "Запрос характеристик VCP" в одном варианте осуществления иллюстрируется на Фиг.69. Как видно на Фиг.69, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Display Selector (Выбор дисплея), Monitor Control Command Set (MCCS) VCP code (код VCP набора команд управления монитором (MCCS)) и CRC. Этот тип пакета обычно идентифицируется в одном варианте осуществления как Тип 128, который указывается в 2-байтовом поле типа. Длина пакета, которая определяет общее количество байтов в пакете, не включая поле длины пакета, обычно устанавливается для этого типа пакета равной длине 10 байт.
Поле hClient ID зарезервировано для использования в качестве идентификатора клиента в будущих реализациях и обычно устанавливается равным нулю.
В одном варианте осуществления 2-байтовое поле Display Selector (Выбор дисплея) в пакете "Ответ с характеристиками VCP" определяет дисплей, где должен быть применен Пакет VCP. Бит 0 поля Display Selector выбирает дисплей, к которому применяется пакет VCP. Когда бит 0 равен 0, пакет VCP применяется к альтернативному дисплею, указанному битами 11-8 ниже. Если, с другой стороны, бит 0 равен 1, уровню логической единицы, то пакет VCP применяется к первичному дисплею. В настоящее время биты 7-1 поля Display Selector зарезервированы для будущего использования и обычно устанавливаются равными нулевому значению, или биты установлены равными уровню логического нуля.
Биты 11-8 поля Display Selector используют 4-битовое целочисленное значение без знака, чтобы определить альтернативный дисплей, к которому пакет VCP будет применен. Когда бит 0 поля Display Selector равен 0 (уровень логического нуля) клиент интерпретирует биты 11-8 как номер альтернативного дисплея. Если бит 0 не равен 0, тогда биты 11-8 установлены равными нулю и будут игнорироваться. Биты 15-12 зарезервированы для будущего использования и обычно устанавливаются в нулевое значение, или уровень каждого бита установлен в логический нуль.
В одном варианте осуществления поле MCCS VCP Code содержит 2 байта информации, которая определяет "Параметр кода управления VCP MCCS" (MCCS VCP Control Code Parameter). Значение в диапазоне от 0 до 255 приводит к возвращению пакета "Ответ с характеристиками VCP", который должен быть возвращен с единственным элементом в "Списке ответа с характеристиками VCP" (VCP Feature Reply List), соответствующим указанному коду MCCS. Код VCP MCCS, равный 65535 (0xffff), запрашивает пакет "Ответ с характеристиками VCP" со "Списком ответа с характеристиками VCP", содержащим элемент "Список ответа с характеристиками" для каждого средства управления, поддерживаемого клиентом. Значения от 256 до 65534 для этого поля зарезервированы для будущего использования и в настоящее время не используются.
2-байтовое поле CRC содержит CRC всех байтов в пакете, включая поле "Длина пакета".
27. Пакет "Ответ с характеристиками VCP"
Пакет "Ответ с характеристиками VCP" (VCP Feature Reply Packet) обеспечивает средства, механизм или способ, чтобы клиент отвечал на запрос ведущего устройства текущими настройками (параметрами) конкретного параметра управления или всеми действительными параметрами управления. Обычно клиент посылает пакет "Ответ с характеристиками VCP" в ответ на пакет "Запрос характеристик VCP". Этот пакет полезен для определения текущих настроек конкретного параметра, для определения действительного диапазона для конкретного (средства) управления, для определения, поддерживается ли конкретное (средство) управления клиентом, или для определения набора средств управления, который поддерживается клиентом. Если послан "Запрос характеристик VCP", который ссылается на конкретное (средство) управления, которое не реализовано в клиенте, тогда возвращают пакет "Ответ с характеристиками VCP" с единственным элементом "Список ответа с характеристиками VCP", соответствующим нереализованному средству управления, который содержит соответствующий код ошибки. В одном варианте осуществления клиент указывает способность поддерживать пакет "Ответ с характеристиками VCP", используя бит 13 поля Client Feature Capability (Возможности характеристик клиента) в пакете "Возможности клиента".
Формат пакета "Ответ с характеристиками VCP" в одном варианте осуществления иллюстрируется на Фиг.70. Как видно из Фиг.70, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, cClient ID, Display Selector (Выбор дисплея), MCCS Version (Версия MCCS), Reply Sequence Number (Порядковый номер ответа), VCP Feature Reply List (Список ответа с характеристиками VCP) и CRC. Этот тип пакета обычно идентифицируется в одном варианте осуществления как Тип 129, как указано в 2-байтовом поле типа.
Поле cClient ID содержит информацию, зарезервированную для идентификатора клиента. Это поле зарезервировано для будущего использования и обычно устанавливается равным нулю.
В одном варианте осуществления 2-байтовое поле "Выбор дисплея" в пакете "Ответ с характеристиками VCP" определяет дисплей, где следует применить Пакет VCP. Бит 0 поля "Выбор дисплея" выбирает дисплей, к которому применяется Пакет VCP. Когда бит 0 равен 0, Пакет VCP применяется к альтернативному дисплею, указанному битами 11-8 ниже. Если, с другой стороны, бит 0 равен 1, уровню логической единицы, то Пакет VCP применяется к первичному дисплею. В настоящее время биты 7-1 поля "Выбор дисплея" зарезервированы для будущего использования и обычно устанавливаются равными нулевому значению, или биты установлены равными уровню логического нуля.
Биты 11-8 поля "Выбор дисплея" используют 4-битовое целочисленное значение без знака, чтобы определить альтернативный дисплей, к которому применяется Пакет VCP. Когда бит 0 поля "Выбор дисплея" равен 0 (уровню логического нуля), клиент интерпретирует биты 11-8 как номер альтернативного дисплея. Если бит 0 не равен 0, тогда биты 11-8 установлены равными нулю и будут игнорироваться. Биты 15-12 зарезервированы для будущего использования и обычно устанавливаются в нулевое значение, или каждый бит установлен равным уровню логического нуля.
Поле MCCS Version содержит 2 байта информации, которые определяют версию спецификации VESA MCCS, реализуемую клиентом.
2-байтовое поле Reply Sequence Number (Порядковый номер ответа) в пакете "Ответ с характеристиками VCP" содержит информацию или данные, которые определяют порядковый номер пакетов "Ответ с характеристиками VCP", возвращаемых клиентом. Клиент возвращает один или более пакетов "Ответ с характеристиками VCP" в ответ на пакет "Запрос характеристик VCP" со значением кода управления MCCS (MCCS control code), равным 65535. Клиент может распространять или передавать список ответа с характеристиками во множестве пакетов "Ответ с характеристиками VCP". В этом случае клиент должен назначить порядковый номер или идентификатор каждому последовательному пакету, и порядковые номера пакетов "Ответ с характеристиками VCP", посланных в ответ на один пакет "Запрос характеристик VCP", обычно начинаются с нуля и увеличиваются на один. Последний элемент "Списка ответа с характеристиками VCP" в последнем пакете "Ответ с характеристиками VCP" должен содержать значение кода управления MCCS VCP, равное 0xffff, чтобы идентифицировать, что этот пакет является последним и содержит наибольший порядковый номер группы возвращенных пакетов. Если послан только один пакет "Ответ с характеристиками VCP" в ответ на пакет "Запрос характеристик VCP", то "Порядковый номер ответа" в этом одном пакете обычно устанавливается равным нулю и "Список ответа с характеристиками VCP" содержит элемент списка, имеющий код VCP MCCS в элементе "Списка ответа с характеристиками VCP", равный 0xffff. Поля Maximum Value (Максимальное значение) и Present Value (Текущее значение) (Фиг.71) в пакете элемента "Списка ответа с характеристиками VCP" установлены равными нулю, когда код управления MCCS VCP равен 0xffff.
Количество характеристик в поле List (Список) содержит 2 байта, которые определяют число элементов "Списка ответа с характеристиками VCP", которые находятся в "Списке ответа с характеристиками VCP" в этом пакете, в то время как поле "Список ответа с характеристиками VCP" является группой байтов, которая содержат один или более элементов "Списка ответа с характеристиками VCP". Формат одного элемента "Списка ответа с характеристиками VCP" в одном варианте осуществления иллюстрируется на Фиг.71.
Как показано на Фиг.71, каждый элемент "Списка ответа с характеристиками VCP" имеет длину 12 байтов и содержит поля MCCS VCP Code (Код VCP MCCS), Result Code (код результата), Maximum Value (Максимальное Значение) и Present Value (Текущее значение). 2-байтовое поле Код VCP MCCS содержит данные или информацию, которая определяет MCCS VCP Control Code Parameter (Параметр кода управления VCP MCCS), ассоциированный с этим элементом списка. Только значения кода управления, определенные в версии 2 спецификации VESA MCCS и более поздних, рассматриваются как действительные для этого варианта осуществления. 2-байтовое поле "Код результата" содержит информацию, которая определяет код ошибки, относящийся к запросу информации относительно указанного Управления VCP MCCS. Значение '0' в этом поле означает, что ошибки нет, в то время как значение '1' означает, что указанное управление не реализовано в клиенте. Другие значения от 2 - 65535 для этого поля в настоящее время зарезервированы для будущего использования и реализации другого применения, рассматриваемого в уровне техники, но пока не используются.
4-байтовое поле "Максимальное значение" определяет наибольшее возможное значение, в которое может быть установлено указанное поле "Управление MCCS". Если требуемое управление не реализовано в клиенте, это значение установлено равным нулю. Если возвращенное значение меньше 32 битов (4 байта) в длину, то значение приводится к 32-битовому целому числу, оставляя старшие значимые байты (неиспользованные) установленными равными нулю. 4-байтовое поле Present Value (Текущее значение) содержит информацию, которая определяет текущее значение указанного Непрерывного (C) или прерывистого управления (NC) VCP MCCS (MCCS VCP Continuous (C) or Non-Continuous (NC) control). Если запрошенное управление не реализовано в клиенте или если такое управление реализовано, но является типом данных "Таблица (T)", то это значение установлено равным нулю. Если возвращенное значение меньше 32 битов (4 байта) в длину, чем в спецификации MCCS VESA, то это значение приводится к 32-битовому целому числу, оставляя старшие значимые (неиспользованные) байты установленными равными нулю. Если указанный код VCP MCCS соответствует прерывистому управлению или типу данных "таблица", то поле Maximum Value устанавливается или выбирается равным нулю.
28. Пакет "Установка характеристик VCP"
Пакет "Установка характеристик VCP" (Set VCP Feature Packet) обеспечивает средства, механизм или способ для ведущего устройства, чтобы установить значения управления VCP как для непрерывного, так и для прерывистого управления в клиенте. В одном варианте осуществления клиент указывает эту способность поддерживать пакет "Установка характеристик VCP", используя бит 13 поля Client Feature Capability в пакете "Возможности клиента".
Формат пакета "Установка характеристик VCP" в одном варианте осуществления иллюстрируется на Фиг.72. Как можно видеть из Фиг.72, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Display Selector (Выбор дисплея), VCP MCCS Code, Number of Values in List (Число значений в списке), Control Value List (Список управляющих значений) и CRC. Этот тип пакета обычно идентифицируется как пакет Типа 130, как обозначено в 2-байтовом поле типа, длиной 20 байтов, исключая поле Packet Length.
В одном варианте осуществления поле hClient ID снова использует 2-байтовое значение, чтобы задать или выступать в качестве идентификатора клиента. Это поле зарезервировано для будущего использования и в настоящее время установлено в нулевое значение.
В одном варианте осуществления 2-байтовое поле Display Selector (Выбор дисплея) в пакете "Установка характеристик VCP" определяет, где применять Пакет VCP. Бит 0 поля "Выбор дисплея" выбирает дисплей, к которому применяется Пакет VCP. Когда бит 0 равен 0, Пакет VCP применяется к альтернативному дисплею, указанному битами 11-8 ниже. Если, с другой стороны, бит 0 равен 1, уровню логической единицы, то Пакет VCP применяется к первичному дисплею. В настоящее время биты 7-1 поля "Выбор дисплея" зарезервированы для будущего использования и обычно устанавливаются равными нулевому значению, или биты установлены равными логическому нулю.
Биты 11-8 поля "Выбор дисплея" определяют альтернативный дисплей, к которому Пакет VCP будет применяться. Когда бит 0 поля "Выбор дисплея" равен 0 (уровень логического нуля) клиент интерпретирует биты 11-8 как номер альтернативного дисплея. Если бит 0 не равен 0, тогда биты 11-8 установлены в нуль и будут игнорироваться. Биты 15-12 зарезервированы для будущего использования и обычно устанавливаются в нулевое значение, или каждый бит установлен равным уровню логического нуля.
Поле MCCS VCP Code для пакета "Установка характеристик VCP" использует 2 байта информации или значений, чтобы определить Параметр кода управления VCP MCCS, который должен быть настроен. 2-байтовое поле "Число значений в списке" содержит информацию или значения, которые задают число 16-битовых значений, которые существуют в поле "Списке управляющих значений". "Список управляющих значений" обычно содержит один элемент, если только Код управления MCCS не относится к таблице в клиенте. В случае средства управления, не связанного с таблицей, "Список управляющих значений" будет содержать значение, которое определяет новое значение, которое должно быть записано в параметр управления, указанный полем MCCS VCP Code. Для относящихся к таблице средств управления формат данных в "Списке управляющих значений" определяется описанием параметра указанного Кода VCP MCCS. Если этот список содержит значения, которые являются большими, чем один байт, то первым передают наименьший значащий байт таким способом, который совместим со способом, определенным в другом месте настоящего описания. Наконец, 2-байтовое поле CRC содержит 16-битовый CRC всех байтов в пакете, включая поле Длина пакета.
29. Пакет "Запрос действительных параметров"
Пакет "Запрос действительных параметров" (Request Valid Parameter Packet) используется как средство или структура, используемая для запроса, чтобы клиент возвратил пакет "Ответ о действительных параметрах" (Valid Parameter Reply Packet), содержащий список параметров, поддерживаемых указанным NC (прерывистым) или Табличным (T) средством управления. Этот пакет должен определить только прерывистые (не непрерывные) средства управления или средства управления, которые относятся к таблице в клиенте, и не задают значение 65535 (0xffff) кода VCP MCCS для задания всех средств управления. Если задан не поддерживаемый или недействительный Код VCP MCCS, тогда соответствующее значение ошибки возвращается в пакете "Ответ о действительных параметрах". В одном варианте осуществления клиент указывает способность поддерживать пакет "Запрос действительных параметров", используя бит 13 поля Client Feature Capability "Возможности характеристик клиента" в пакете "Возможности дисплея".
Формат пакета "Запрос действительных параметров" в одном варианте осуществления иллюстрируется на Фиг.73. Как можно видеть из Фиг.73, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Выбор дисплея, Код VCP MCCS и CRC. Этот тип пакета обычно идентифицируется в одном варианте осуществления как Тип 131, как обозначено в 2-байтовом поле типа.
Длина пакета, которая указана в 2-байтовом поле Длина пакета, обычно устанавливается так, чтобы иметь общее количество байтов в пакете, не включая поле длины пакета, равное 8. Поле hClient ID снова определяет идентификатор клиента, но в настоящее время зарезервировано для будущего использования, как очевидно для специалиста в данной области техники, и установлено в нулевое значение или уровень логического нуля.
В одном варианте осуществления 2-байтовое поле Display Selector (Выбор дисплея) в пакете "Запрос действительных параметров" определяет, где применить Пакет VCP. Бит 0 поля "Выбор дисплея" выбирает дисплей, к которому применяется Пакет VCP. Когда бит 0 равен 0, Пакет VCP применяется к альтернативному дисплею, указанному битами 11-8 ниже. Если, с другой стороны, бит 0 равен 1, уровень логической единицы, то Пакет VCP применяется к первичному дисплею. В настоящее время биты 7-1 поля "Выбор дисплея" зарезервированы для будущего использования и обычно устанавливаются равными нулевому значению, или биты установлены равными логическому нулю.
Биты 11-8 поля "Выбор дисплея" определяют альтернативный дисплей, к которому Пакет VCP будет применяться. Когда бит 0 поля "Выбор дисплея" равен 0 (уровень логического нуля) клиент интерпретирует биты 11-8 как номер альтернативного дисплея. Если бит 0 не равен 0, тогда биты 11-8 установлены в нуль и будут игнорироваться. Биты 15-12 зарезервированы для будущего использования и обычно устанавливаются равными нулевому значению, или каждый бит установлен равным уровню логического нуля.
2-байтовое поле кода VCP MCCS для пакета "Запрос действительных параметров" содержит значение, которое определяет, что Параметр кода прерывистого управления VCP MCCS должен быть запрошен. Значение в этом поле должно соответствовать не непрерывному (прерывистому) управлению, которое осуществляется в клиенте. Значения 256-65535 (0xffff) обычно резервируются или рассматриваются как недействительные, и рассматриваются как нереализованное управление в ответе об ошибке. Поле CRC, здесь 2-байтовое, содержит CRC всех байтов в пакете, включая поле Длина пакета.
30. Пакет "Ответ о действительных параметрах"
Пакет "Ответ о действительных параметрах" (Valid Parameter Reply Packet) посылают в ответ на пакет "Запрос действительных параметров". Он используется как средство, способ или структура, чтобы идентифицировать действительные параметры настройки для прерывистого управления VCP MCCS или управления, которое возвращает содержание таблицы. Если управление относится к таблице в клиенте, то "Список ответа о параметрах VCP" просто содержит заданный список последовательных табличных значений, которые были запрошены. Если содержание таблицы не может быть вписано в единственный пакет "Ответ о действительных параметрах", то клиентом может быть послано множество пакетов с последовательными значениями "Порядковый номер ответа". В одном варианте осуществления клиент указывает способность поддерживать пакет "Ответ о действительных параметрах", используя бит 13 поля "Возможности характеристик клиента" в пакете "Возможности клиента".
Ведущее устройство может запрашивать содержание таблицы следующим образом: ведущее устройство посылает пакет "Установка характеристик VCP", содержащий необходимые или требуемые параметры, такие как параметр считывания/записи, смещение Таблицы поиска (ТП) и выбор RGB; затем пакет "Запрос действительных параметров", который определяет требуемое управление, посылается ведущим устройством; затем клиент возвращает один или более пакетов "Ответ о действительных параметрах", содержащие табличные данные. Эта последовательность операций выполняет аналогичную функцию, как и функции считывания таблицы, описанные в операционной модели MCCS.
Если конкретный параметр клиента не поддерживается клиентом, тогда в одном варианте осуществления соответствующее поле этого пакета будет содержать значение 255. Для параметров, которые используются в клиенте, соответствующее поле должно содержать значение этого параметра в клиенте.
Формат пакета "Ответ о действительных параметрах" для одного варианта осуществления иллюстрируется на Фиг.74. Как можно видеть из Фиг.74, этот тип пакета структурирован так, что имеет поля Длина Пакета, Тип Пакета, cClient ID, Выбор дисплея, Код VCP MCCS, Response Code (Код Ответа), Reply Sequence Number (Порядковый номер ответа), Number Values in List (количество значений в списке), VCP Parameter Reply List (Список ответа о параметрах VCP) и CRC. Этот тип пакета обычно идентифицируется для одного варианта осуществления как Тип 132, как обозначено в 2-байтовом поле типа.
Поле cClient ID зарезервировано для будущего идентификатора клиента, как известно из приведенного выше описания.
В одном варианте осуществления 2-байтовое поле "Выбор дисплея" содержит информацию относительно того, где применять Пакет VCP. Бит 0 поля "Выбор дисплея" выбирает дисплей, к которому применяется Пакет VCP. Если бит 0 равен 0, Пакет VCP применяется к альтернативному дисплею, указанному битами 11-8 ниже. Если, с другой стороны, бит 0 равен 1, уровень логической единицы, то Пакет VCP применяется к первичному дисплею. В настоящее время биты 7-1 поля "Выбор дисплея" зарезервированы для будущего использования и обычно устанавливаются равными нулевому значению, или биты установлены равными логическому нулю.
Биты 11-8 поля "Выбор дисплея" определяют альтернативный дисплей, к которому Пакет VCP должен применяться. Когда бит 0 равен 0 (уровень логического нуля) клиент интерпретирует биты 11-8 как номер альтернативного дисплея. Если бит 0 не равен 0, тогда биты 11-8 установлены равными нулю и будут игнорироваться. Биты 15-12 зарезервированы для будущего использования и обычно устанавливаются в нулевое значение, или каждый бит имеет уровень логического нуля.
В одном варианте осуществления 3-байтовый пакет "Код VCP MCCS" (MCCS VCP Code Packet) содержит значение, которое определяет не непрерывный "Параметр кода управления VCP MCCS", который описан этим пакетом. Если недействительный код управления VCP MCCS задается пакетом "Запрос действительных параметров", тогда то же самое недействительное значение параметра будет определено в этом поле с соответствующим значением в поле Response Code (Код ответа). Если "Код управления MCCS" является недействительным, тогда "Список ответа о параметрах VCP" будет иметь нулевую длину.
Поле "Код ответа" содержит 2 байта информации или значений, которые задают характер ответа, относящегося к запросу информации относительно указанного "Управления VCP MCCS". Если значение в этом поле равно 0, то рассматривается, что ошибки нет для этого типа данных, и посылают последний пакет "Ответ о действительных параметрах" в последовательности, имеющий самый высокий "Порядковый номер ответа". Если значение в этом поле равно 1, то рассматривается, что ошибка отсутствует, но будут посланы другие пакеты "Ответ о действительных параметрах", которые имеют большие порядковые номера. Если значение в этом поле равно 2, то указанное управление рассматривается как не реализованное в клиенте. Если значение в этом поле равняется 3, то указанное управление не является не непрерывным (прерывистым) управлением (оно является непрерывным управлением, которое всегда имеет действительный набор всех значений от нуля до его максимального значения). Значения для этого поля, установленные равными от 4 до 65535, зарезервированы для будущего использования и обычно не используются.
2-байтовое поле Reply Sequence Number (Порядковый номер ответа) определяет порядковый номер пакетов "Ответ о действительных параметрах", возвращенных клиентом. Клиент возвращает один или более пакетов "Ответ о действительных параметрах" в ответ на пакет "Запрос действительных параметров". Клиент может распространять "Список ответа о параметрах VCP" во множестве пакетов "Ответ о действительных параметрах". В этом последнем случае клиент будет назначать порядковый номер каждому последовательному пакету и устанавливать "Код ответа" равным 1 для всех, кроме последнего пакета в последовательности. Последний пакет "Ответ о действительных параметрах" в последовательности будет иметь самый большой "Порядковый номер ответа", и "Код ответа" содержит значение 0.
2-байтовое поле "Число значений в списке" определяет количество 16-битовых значений, которые существуют в "Списке ответа о параметрах VCP". Если "Код ответа" не равен нулю, то параметр "Число значений в списке" равно нулю. Поле "Список ответа о параметрах VCP" содержит список от 0 до 32760 2-байтовых значений, которые указывают набор действительных значений для не непрерывного управления, указанного полем "Код управления MCCS". Определения кодов не непрерывного управления заданы в спецификации MCCS VESA. Наконец, в этом варианте осуществления поле CRC содержит 16-битовый код CRC всех байтов в пакете, включая поле "Длина пакета".
Изображения масштабируемого потока видео
MDDI или механизм протокола, структура, средство или способ обеспечивают поддержку для изображений масштабируемого потока видео, которые позволяют ведущему устройству посылать изображение пользователю, которое масштабируется как большее или меньшее, чем первоначальное изображение, и масштабируемое изображение копируется в основной буфер изображения. Краткий обзор функциональных возможностей «Масштабируемого потока видео» и связанной поддержки протокола обеспечивается в другом месте настоящего описания. Способность поддерживать масштабируемые потоки видео определяется посредством или в самом пакете «Возможности масштабируемого потока видео» (Scaled Video Stream Capability Packet), который посылают в ответ на пакет «Запрос конкретного состояния» (Request Specific Status Packet).
Заголовок пакета «Масштабируемый поток видео», описанного ниже, немного отличается от более простого пакета «Поток видео», чей заголовок содержит полный контекст, необходимый для отображения изображения. Пакет «Масштабируемый поток видео» использует пакет установки, чтобы определить параметры размера окна и позиции в источнике и адресате, и отдельный пакет «Масштабируемый поток видео», чтобы передавать пиксельные данные. Клиент распределяет внутреннюю память, ассоциированную с каждым потоком, чтобы сохранить параметры потока из пакета установки и часть пиксельных данных, ассоциированных с каждым потоком. Объем памяти, требуемой для каждого потока, будет меняться в зависимости от размера изображений источника и адресата и значений, указанных в пакете установки. По этой причине протокол разработан так, чтобы разрешить клиенту осуществлять динамическое распределение памяти для выделения памяти, ассоциированной с каждым масштабируемым потоком видео.
Полезно посылать поток видеодисплею, имеющему размер, присущий источнику программы, и иметь масштаб и позицию изображения на дисплее для отображения изображения способом, подходящим для конкретного конечного применения. Осуществление масштабирования в реальном масштабе времени множества видеоизображений является достаточно сложным, чтобы поддерживать эту особенность необязательной в клиенте.
31. Пакет «Возможности масштабируемого потока видео»
Пакет «Возможности масштабируемого потока видео» определяет характеристики изображения источника масштабируемого потока видео в клиенте или используемый клиентом. Формат пакета «Возможности масштабируемого потока видео» показан в общем виде на Фиг.75. Как можно видеть из Фиг.75, в одном варианте осуществления пакет «Возможности масштабируемого потока видео» структурирован так, что имеет поля Длина Пакета, Тип Пакета, cClient ID (Идентификатор клиента), Max Number of Streams (максимальное количество потоков), Source Max X Size (максимальный размер по Х источника), Source Max Y size (максимальный размер по Y источника), RGB Capability (Возможность RGB), Monochrome Capability (Возможность монохромного представления), Зарезервированное 1, Возможность Y Cr Cb, Зарезервированное 2, и CRC. Длина пакета в одном варианте осуществления выбирается фиксированной и равной 20 байтам, как указано в поле длины, включая 2-байтовое поле cClient 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. Если масштабируемый поток видео не может использовать формат YCb Cr, тогда это значение нулевое. Слово «Возможности Y Cb Cr» состоит из трех отдельных значений без знака: биты 3-0 определяют максимальное количество битов, которые задают выборку Cr; биты 7-4 определяют максимальное количество битов, которые задают выборку Cb; биты 11-8 определяют максимальное количество битов задают выборку Y; и биты 15-12 зарезервированы для будущего использования и обычно устанавливаются равными нулю.
1-байтовое поле Capability bits (Биты возможностей) содержит набор флагов, которые определяют возможности, ассоциированные с масштабируемым потоком видео. Эти флаги определяются следующим образом: бит 0 охватывает пиксельные данные в пакете «Масштабируемый поток видео», которые могут быть в упакованном формате. Пример упакованных и выровненных по границе байта пиксельных данных показан выше на Фиг.13. Бит 1 зарезервирован для будущего использования и обычно устанавливается равным нулю; бит 2 также зарезервирован для будущего использования и установлен равным нулю; бит 3 охватывает масштабированные потоки видео, которые могут быть заданы в формате данных карты цвета. Та же самая таблица карты цвета используется для тех масштабируемых потоков видео, что используются для основного буфера изображения и плоскостей изображения с алфавитным курсором. Карта цвета является конфигурированной с использованием пакета «Карта цвета», описанного в другом месте настоящего описания; и биты 7-4 зарезервированы для будущего использования и обычно устанавливаются равными нулю.
Поле «Зарезервированное 2» (здесь 1 байт) зарезервировано для будущего использования для обеспечения значений, относящихся к информации или данным пакета «Масштабируемый поток видео». Поэтому в настоящее время все биты в этом поле установлены равными логическому '0'. Одна цель этого поля состоит в том, чтобы выровнять все последующие 2-байтовые поля до 16-битового адреса слова и выровнять 4-байтовые поля до 32-битового адреса слова.
32. Пакет «Установка масштабируемого потока видео»
Пакет «Установка масштабируемого потока видео» (Scaled Video Stream Setup Packet) обеспечивает средство, структуру или способ, используемые для определения параметров масштабируемого потока видео, и клиент использует эту информацию, чтобы выделить оперативную память для буферизации и масштабирования изображения. Поток может быть освобожден (дераспределен), посылая этот пакет с полями «Размер изображения по X» и «Размер изображения по Y», равными нулю. Масштабируемые потоки видео, которые были освобождены, могут быть повторно распределены позже с теми же или отличными параметрами потока. В одном варианте осуществления клиент указывает способность поддерживать пакет "Установка масштабируемого потока видео», используя значение 143 параметра в «Списке ответа о действительном параметре» в пакете «Список ответа о действительном состоянии» и используя ненулевое значение в поле «Максимальное количество потоков» в пакете «Возможности масштабируемого потока видео».
Формат пакета «Установка масштабируемого потока видео» показывается в общем виде на Фиг.76. Как можно видеть из Фиг.76, в одном варианте осуществления пакет «Установка масштабируемого потока видео» структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient, Stream ID (Идентификатор потока), Video Data Format Descriptor (Дескриптор формата данных видео), Pixel Data Attributes (Атрибуты пиксельных данных), X Left Edge (X левой границы), Y Top Edge (Y верхней границы), X Right Edge (X правой границы), Y Bottom Edge (Y нижней границы), X Image Size (Размер изображения по X), Y Image Size (Размер изображения по Y) и CRC.
2-байтовое поле «Длина пакета» определяет общее количество байтов в пакете, не включая поле длины пакета. В одном варианте осуществления эта длина пакета установлена равной 24. 2-байтовое поле «Тип пакета» использует значение 136, чтобы идентифицировать пакет как пакет «Установка масштабируемого потока видео». 2-байтовое поле hClient ID зарезервировано для будущего использования в качестве идентификатора клиента, и обычно все биты устанавливаются в логическое нулевое значение в настоящее время или до тех пор, пока пользователь протокола не определяет, какие значения идентификатора должны использоваться, как может быть известно.
Поле «Идентификатор потока» использует 2 байта, чтобы задать уникальный идентификатор для идентификатора потока. Это значение назначается ведущим устройством и имеет значения от нуля до максимального значения «Идентификатора потока», указанного в пакете "Возможности клиента". Ведущее устройство должно тщательно контролировать использование значений «Идентификатор потока», чтобы гарантировать, что каждому активному потоку назначено уникальное значение и что потоки, которые больше не являются активными, были освобождены или переназначены.
В одном варианте осуществления поле «Дескриптор формата данных видео» использует 2 байта, чтобы задать формат каждого пикселя в пиксельных данных в текущем потоке в текущем пакете. Формат пиксельных данных должен подчиняться по меньшей мере одному из действительных форматов для плоскости изображения с алфавитным курсором, который может быть определен в пакете «Возможности изображения алфавитного курсора» или другом заранее определенном шаблоне изображения, который обычно определяется в других пакетах, описанных выше. «Дескриптор формата данных видео» задает пиксельный формат только для текущего пакета и не подразумевает, что постоянный формат продолжит использоваться в течение срока жизни конкретного потока видео. Фиг.12 иллюстрирует вариант осуществления того, как закодирован «Дескриптор формата данных видео», и как описано выше для других пакетов.
Например, как можно видеть из Фиг. 12A-12D и для использования в одном варианте осуществления, когда биты [15:13] равны '000', то видеоданные состоят из массива одноцветных пикселей, где количество битов в расчете на пиксель определяется битами 3-0 слова «Дескриптора формата видеоданных». Биты 11-4 обычно резервируются для будущего использования или приложений и установлены равными нулю в этой ситуации. Когда биты [15: 13] вместо этого равны значениям '001', тогда видеоданные состоят из массива цветных пикселей, где каждый задает цвет из карты цвета (палитры). В этой ситуации биты 5-0 слова «Дескриптор формата видеоданных» определяют количество битов в расчете на пиксель, и биты 11-6 обычно резервируются для будущего использования или приложений и установлены равными нулю. Когда биты [15:13] вместо этого равны значениям '010', тогда видеоданные состоят из массива цветных пикселей, где количество битов в расчете на пиксель красного цвета определяется битами 11-8, количество битов в расчете на пиксель зеленого цвета определяется битами 7-4 и количество битов в расчете на пиксель синего цвета определяется битами 3-0. В этой ситуации общее количество битов в каждом пикселе равно сумме количества битов, используемых для красного, зеленого и синего цветов.
Однако, когда биты [15:13] вместо этого равны значениям или строке '011', как показано на Фиг.12D, тогда видеоданные состоят из массива видеоданных в формате YCbCr 4:2:2 с информацией яркости и цветности, где количество битов в расчете на пиксель сигнала яркости (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 и Cm ассоциированы с Yn и Yn+1, и Cbn+2 и Crn+2 ассоциированы с Yn+2 и Yn+3, и так далее. Yn, Yn+1, Yn+2 и Yn+3 являются значениями яркости четырех последовательных пикселей в одной строке слева направо.
Для всех четырех форматов, описанных выше, бит 12, который обозначен как "P" на чертежах, задает, действительно ли выборки «Пиксельные данные» являются упакованными или выровненными по границе байта пиксельными данными. Значение '0' в этом поле указывает, что каждый пиксель в поле «Пиксельные данные» является выровненным по границе байта с границей байта MDDI. Значение '1' указывает, что каждый пиксель и каждый цвет в каждом пикселе в «Пиксельных Данных» являются упакованными рядом с предыдущим пикселем или цветом в пикселе, не оставляя никаких неиспользованных битов.
В одном варианте осуществления 2-байтовое поле «Атрибуты пиксельных данных» имеет значения, которые интерпретируются следующим образом: биты 1 и 0 зарезервированы для будущего использования, пока установлены равными логическому нулю, и бит 2 указывает, действительно ли «Пиксельные данные» находятся в чересстрочном формате. Когда бит 2 равен 0, тогда «Пиксельные данные» находятся в стандартном прогрессивном формате. Номер строки (Координата Y пикселя) увеличивается на 1 при переходе от одной строки к следующей. Когда бит 2 равен 1, тогда «Пиксельные данные» находятся в чересстрочном формате. Номер строки (Координата Y пикселя) увеличивается на 2 при переходе от одной строки к следующей.
В одном варианте осуществления бит 3 указывает, находятся ли «Пиксельные данные» в альтернативном пиксельном формате. Это аналогично стандартному чересстрочному режиму, разрешенному битом 2, но с чередованием по вертикали вместо чередования по горизонтали. Когда бит 3 равен 0, «Пиксельные данные» формируются или помещаются в стандартном прогрессивном формате. Номер столбца (Координата X пикселя) увеличивается на 1, когда принимают каждый последовательный пиксель. Когда бит 3 равен 1, тогда «Пиксельные данные» формируются или помещаются в альтернативном пиксельном формате. Номер столбца (Координата X пикселя) увеличивается на 2, когда принимают каждый пиксель.
Биты 4-15 также зарезервированы для будущего использования, и обычно установлены в уровень или значение логического нуля для текущих приложений или конструкций.
33. Пакет «Подтверждение масштабируемого потока видео»
Пакет «Подтверждение масштабируемого потока видео» (Scaled Video Stream Acknowledgement Packet) позволяет пользователю подтверждать прием пакета «Установка масштабируемого потока видео». Клиент может указывать способность поддерживать пакет «Подтверждение масштабируемого потока видео» посредством значения 143 параметра в «Списке ответа о действительном параметре» в пакете «Список ответа о действительном состоянии» и посредством ненулевого значения в поле «Максимальное количество потоков» в пакете «Возможности масштабируемого потока видео».
Формат пакета «Подтверждение масштабируемого потока видео» показывается в общем виде на Фиг.77. Как можно видеть из Фиг.77, в одном варианте осуществления пакет «Подтверждение масштабируемого потока видео» структурирован так, что имеет поля Длина Пакета, Тип Пакета, cClient ID (Идентификатор клиента), Stream ID (Идентификатор потока), ACK Code (Код ACK) и CRC. 2-байтовое поле "Длина пакета" используется, чтобы определить общее количество байтов, исключая поле длины пакета, со значением 10 для этого типа пакета, в то время как значение 137 поля «Тип Пакета» идентифицирует пакет как пакет «Подтверждение масштабируемого потока видео».
2-байтовое поле cClient ID (идентификатор клиента) зарезервировано для будущего использования для идентификатора клиента и обычно устанавливается равным нулю. 2-байтовое поле «Идентификатор потока» определяет уникальный идентификатор для идентификатора потока. Оно является тем же самым значением, назначенным ведущим устройством в пакете «Установка масштабируемого потока видео».
2-байтовое поле Ack Code обеспечивает значения, содержащие код, который описывает результат попытки обновить указанный масштабируемый поток видео. В одном варианте осуществления эти коды определяются следующим образом:
0 - попытка назначения потока была успешна.
1 - попытка освобождения потока была успешна.
2 - недействительная попытка назначить Идентификатор потока, который уже был распределен.
3 - недействительная попытка освободить Идентификатор потока, который уже освобожден.
4 - клиент не поддерживает масштабируемые потоки видео.
5 - параметры потока несовместимы с возможностью клиента.
6 - значение «Идентификатора потока» больше, чем максимальное значение, разрешенное клиентом.
7 - недостаточно ресурсов, доступных в клиенте, чтобы назначить указанный поток.
2-байтовое поле CRC содержит CRC всех байтов в пакете, включая поле "Длина пакета".
34. Пакет «Масштабируемый поток видео»
Пакет «Масштабируемый поток видео» используется, чтобы передавать пиксельные данные, ассоциированные с конкретным масштабируемым потоком видео. Размер области, указываемой этим пакетом, определяется пакетом «Установка масштабируемого потока видео». Клиент может указывать способность поддерживать пакет «Масштабируемый поток видео», используя значения 143 параметра в «Списке ответа о действительном параметре» в пакете «Список ответа о действительном состоянии» и используя ответ об успешном назначении масштабируемого потока видео в поле Ack Code (код подтверждения) пакета «Подтверждение масштабируемого потока видео».
Формат одного варианта осуществления пакета «Масштабируемый поток видео» показывается в общем виде на Фиг.78. Как можно видеть из Фиг.78, пакет «Масштабируемый поток видео» структурирован так, что имеет поля Длина Пакета, Тип Пакета, hClient ID (Идентификатор клиента), Идентификатор потока, Pixel Data Attributes (Атрибуты пиксельных данных), Pixel Count (Подсчет пикселей), Параметр CRC, Пиксельные данные и CRC Пиксельных данных. 2-байтовое поле «Тип Пакета» использует значение 18, чтобы идентифицировать пакет как пакет «Масштабируемый поток видео». Поле hClient ID зарезервировано для идентификатора клиента и обычно устанавливается равным нулю. Как и прежде, 2-байтовое поле «Идентификатор потока» определяет уникальный идентификатор для идентификатора потока. Это значение указанно ведущим устройством в пакете «Установка масштабируемого потока видео» и подтверждено в пакете «Подтверждение масштабируемого потока видео».
В одном варианте осуществления 2-байтовое поле «Атрибуты пиксельных данных» имеет значения, которые определяют маршрутизацию пиксельных данных и обновление дисплея или местоположения буферов. Эти значения в одном варианте осуществления интерпретируются следующим образом: биты 1 и 0 выбирают дисплей, куда пиксельные данные должны быть маршрутизированы. Для битовых значений '11' или '00' пиксельные данные направляются к или отображаются для обоих глаз, для битовых значений '10' пиксельные данные направляются только к левому глазу, и для битовых значений '01' пиксельные данные направляются только к правому глазу.
Биты 7 и 6 являются битами «Обновление дисплея», которые определяют буфер изображения, куда пиксельные данные должны быть записаны. Влияние «Битов обновления кадра» описаны более подробно в другом месте описания. Когда биты [7:6] равны '01', пиксельные данные записывают в автономный буфер изображения. Когда биты [7:6] равны '00', пиксельные данные записывают в буфер изображения, используемый для регенерации дисплея. Когда биты [7:6] равны '11', пиксельные данные записывают во все буферы изображения. Если биты [7:6] равны '10', это обрабатывается как недействительное значение. Эти биты в настоящее время зарезервированы для будущего использования. В этой ситуации пиксельные данные будут игнорироваться и не будут записаны в какой-либо из буферов изображения. Биты 15-14 и 11-8 зарезервированы для будущего использования и обычно установлены в уровень или значение логического нуля.
В одном варианте осуществления биты [13:12], или 13 и 12, используются, чтобы определить, должны ли быть записаны пиксели адресата (места назначения) в местоположение назначения, когда они относятся к прозрачному цвету и прозрачной маске. Когда биты [13:12] равны значению или значениям 00, тогда прозрачный цвет не используется. Результирующий пиксель адресата записывается в местоположение пикселя адресата без рассмотрения значения прозрачного цвета или прозрачной маски. Прозрачный цвет определяется пакетом «Установка прозрачного цвета и маски». Значение или значения 01 для битов [13:12] зарезервированы для будущего использования и обычно не используются или не рассматриваются как достоверное состояние. Когда биты [13:12] равны значению или значениям 10, пиксели адресата записывают в местоположение адресата, если только результат операции «логическое И» пикселя изображения источника и прозрачной маски не равен прозрачному цвету, в этом случае результирующий пиксель не записывают в местоположение пикселя адресата. Когда биты [13:12] равны значению или значениям 11, пиксели адресата не записывают в местоположение пикселя адресата, если только результат операции «логическое И» пикселя изображения источника и прозрачной маски не равен прозрачному цвету, в этом случае результирующий пиксель записывают в местоположение пикселя адресата.
2-байтовое поле «Количество пикселей» определяет число пикселей в поле «Пиксельные данные» ниже. 2-байтовое поле «Параметр CRC» имеет код CRC всех байтов от "Длина пакета" до «Количество пикселей». Если это поле CRC дает ошибку при проверке, тогда весь пакет отвергают. 2-байтовое поле «Пиксельные данные» содержит необработанную информацию видео, которая должна быть масштабирована и затем отображена. Данные форматируют способом, описанным полем Video Data Format Descriptor. Данные передают по строкам за раз как определено выше.
2-байтовое поле «CRC пиксельных данных» содержит CRC только поля «Пиксельные данные». Если это поле CRC дает ошибку при проверке, тогда «Пиксельные данные» могут быть все еще использованы, но значение счетчика ошибок кода CRC увеличивается.
35. Пакет «Запрос конкретного состояния»
Пакет «Запрос конкретного состояния» (Request Specific Status Packet) обеспечивает средство, механизм или способ для ведущего устройства запрашивать, чтобы клиент послал пакет о возможностях или состоянии назад на ведущее устройство, как задано в этом пакете. Клиент возвращает пакет указанного типа в следующем пакете "Инкапсуляция обратной линии связи». Клиент будет обычно устанавливать бит 17 в поле Client Feature Capability (Функциональные возможности клиента) в пакете "Возможности клиента", если клиент имеет возможность ответить на пакет «Запрос конкретного состояния». Удобный способ для ведущего устройства для того, чтобы определить все типы пакетов состояния, которые клиент может возвращать или передавать, состоит в том, чтобы использовать пакет «Список ответа о действительном состоянии», описанный в другом месте описания. Клиент может указывать способность ответить пакетом «Список ответа о действительном состоянии», используя бит 21 поля "Возможности характеристик клиента" в пакете "Возможности клиента".
Формат одного варианта осуществления пакета «Запрос конкретного состояния» показывается в общем виде на Фиг.79. Как можно видеть из Фиг.79, пакет «Запрос конкретного состояния" структурирован так, что имеет поля "Длина пакета", «Тип Пакета», hClient ID (Идентификатор клиента), Status Packet ID (Идентификатор пакета состояния) и CRC.
Поле «Длина пакета» определяет общее количество байтов в пакете, не включая поле длины пакета, и обычно устанавливается в значение 10 для этого типа пакета. Тип Пакета, равный 138, идентифицирует пакет как пакет «Запрос конкретного состояния». Поле «Идентификатор клиента» (2 байта) зарезервировано для будущего использования для идентификатора клиента и пока установлено равным нулю, в то время как 2-байтовое поле «Идентификатор пакета состояния» определяет тип пакета о функциональной возможности или состояния, который клиент собирается посылать ведущему устройству. Типичными типами пакетов являются:
66 - Пакет "Возможности клиента" послан клиентом.
133 - Пакет «Возможности изображения алфавитного курсора» послан клиентом.
139 - Пакет «Список ответа о действительном состоянии» послан клиентом, который идентифицирует точные типы пакетов возможностей и состояния, которые клиент может посылать.
141 - Пакет «Персональные возможности клиента» послан клиентом.
142 - Пакет «Отчет об ошибках клиента» послан клиентом.
143 - Пакет «Возможности масштабируемого потока видео» послан клиентом.
144 - Пакет «Идентификационная информация клиента» послан клиентом.
Типы Пакета 56-63 могут использоваться для идентификаторов определенной изготовителем возможности и состояния.
Поле CRC снова содержит CRC всех байтов в пакете, включая Длину Пакета.
36. Пакет «Список ответа о действительном состоянии»
Пакет «Список ответа о действительном состоянии» (Valid Status Reply List Packet) обеспечивает ведущее устройство структурой, средством или способом иметь пакеты со списком состояния и о возможностях, которые клиент имеет возможность возвращать. Клиент может указывать способность поддерживать пакет «Список ответа о действительном состоянии», используя бит 21 поля "Возможности характеристик клиента" в пакете "Возможности клиента".
Формат одного варианта осуществления пакета «Список ответа о действительном состоянии» показывается в общем виде на Фиг.80. Как можно видеть из Фиг.80, пакет «Список ответа о действительном состоянии» структурирован так, что имеет поля Длина Пакета, Тип Пакета, cClient ID, Number of Values in List (Количество значений в списке), Valid Parameter Reply List (Список ответа о действительных параметрах) и CRC. Длина пакета для этого типа пакета обычно устанавливается равной значению 10, и значение типа, равное 139, идентифицирует пакет как пакет «Ответ о действительном состоянии». Поле cClient ID зарезервировано для будущего использования как идентификатор клиента и обычно установлено равным нулю. 2-байтовое поле «Количество значений в списке» определяет число элементов в следующем «Списке ответа о действительных параметрах».
Поле Valid Parameter Reply List (Список ответа о действительных параметрах) содержит список 2-байтовых параметров, которые задают типы пакетов о функциональных возможностях или состоянии, которые клиент может посылать ведущему устройству. Если клиент указал, что может ответить на пакет «Запрос конкретного состояния» (используя бит 21 поля «Возможности характеристик клиента» в пакете "Возможности клиента"), тогда он способен посылать по меньшей мере пакет "Возможности клиента" (Тип Пакета = 66) и пакет «Список ответа о действительном состоянии» (Тип Пакета = 139). Типами пакета, которые могут быть посланы клиентом и могут быть включены в этот список, вместе с их соответствующими назначениями для целей одного варианта осуществления, являются следующие:
66 - Пакет "Возможности клиента".
133 - Пакет «Возможности изображения алфавитного курсора».
139 - Пакет «Список ответа действительного состояния», который идентифицирует точные типы пакетов возможностей и состояния, которые клиент может посылать.
141- Пакет «Возможности персонального дисплея».
142 - Пакет «Отчет об ошибках клиента».
143 - Пакет «Возможности масштабируемого потока видео».
144 - Пакет «Идентификационная информация клиента».
145 - Пакет «Возможности альтернативного дисплея».
Типы Пакета, равные 56-63, могут использоваться для идентификаторов определенных изготовителем возможностей и состояния.
Поле CRC содержит CRC всех байтов в пакете, включая Длину Пакета.
37. Пакет «Возможности персонального дисплея»
Пакет «Возможности персонального дисплея» (Personal Display Capability Packet) обеспечивает набор параметров, которые описывают возможности персонального устройства отображения, такого как установленный на голове дисплей или дисплейные очки. Это дает возможность ведущему устройству настраивать информацию о дисплее согласно конкретным возможностям клиента. Клиент, с другой стороны, указывает способность послать пакет «Возможности персонального дисплея», используя соответствующий параметр в «Списке ответа о действительных параметрах» в пакете «Список ответа о действительных параметрах».
Формат одного варианта осуществления пакета «Возможности персонального дисплея» показывается в общем виде на Фиг.81. Как можно видеть из Фиг.81, пакет «Возможности персонального дисплея» структурирован так, что имеет поля Длина Пакета, Тип Пакета, cClient ID, Sub-Pixel Layout (Расположение под-пикселя), Pixel Shape (Форма пикселя), Horizontal Field of View (Поле зрения по горизонтали), Vertical Field of View (Поле зрения по вертикали), Visual Axis Crossing (Пересечение визуальной оси), Lft./Rt. Image (Перекрытие левого/правого изображения), See Through (Прозрачность), Maximum Brightness (Максимальная яркость), Optical Capability (Оптическая возможность), Minimum IPD (Минимальное IPD), Maximum IPD (Максимальное IPD), Points of IFeld of Curvature List (Список точек поля кривизны) и CRC. В одном варианте осуществления значение поля Длина Пакета установлено равным 68. Значение Тип Пакета, равное 141, идентифицирует пакет как пакет «Возможности персонального дисплея». Поле cClient ID зарезервировано для будущего использования и пока установлено равным нулю.
В одном варианте осуществления поле «Расположение под-пикселя» определяет физическое размещение под-пикселя сверху до низу и слева направо, используя значения: 0 - для указания, что размещение под-пикселя не определено; 1 - для указания красной, зеленой, синей полосы; 2 - для указания синей, зеленой, красной полосы; 3 - для указания счетверенного пикселя, имеющего компоновку 2-на-2 под-пикселей с красным слева сверху, синим справа внизу, и двумя зелеными под-пикселями, один слева внизу и другой вверху справа; 4 - для указания счетверенного пикселя, имеющего компоновку 2-на-2 под-пикселей с красным под-пикселем слева внизу, синим сверху справа, и двумя зелеными под-пикселями, один сверху слева и другим - справа внизу; 5 - для указания Дельты (Триады); 6 - для указания мозаики с перекрывающимися красным, зеленым и синим (например, жидкокристаллический дисплей на кремнии (LCOS) с чередующимся по полям цветом); и со значениями от 7 до 255, обычно зарезервированными для будущего использования.
В одном варианте осуществления поле Pixel Shape (Форма пикселя) определяет форму каждого пикселя, который состоит из под-пикселей конкретной конфигурации, используя значение: 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-байтовое поле Left/Right Image Overlap (Перекрытие левого/правого изображения) определяет процент перекрытия левого и правого изображения. Допустимый диапазон перекрытия изображения в процентах - от 1 до 100. Значения от 101 до 255 недействительны и обычно не должны использоваться. Если это значение нулевое, то перекрытие изображения не определено.
В одном варианте осуществления 1-байтовое поле See Through (Прозрачность) определяет процент прозрачности изображения. Допустимый диапазон прозрачности в проценте - от 0 до 100. Значения от 101 до 254 недействительны и не должны использоваться. Если это значение равно 255, то процент прозрачности не определен. 1-байтовое поле Maximum Brightness (Максимальная яркость) определяет максимальную яркость с приращениями 20 нит (например, если максимальная яркость равна 100 нит, это значение равно 5). Если это значение нулевое, тогда максимальная яркость не определена.
В одном варианте осуществления 2-байтовое поле «Флаги оптической возможности» содержат различные поля, которые определяют оптические возможности дисплея. Эти битовые значения обычно являются назначенными с битами 15-5, зарезервированными для будущего использования и обычно установлены в состояние логического нуля. Бит 4 выбирает Eye Glass Focus Adjustment (Настройка фокуса очков для глаз) со значением '0', означающим, что дисплей не имеет никакой настройки фокуса очков для глаз, и значением '1', означающим, что дисплей имеет настройку фокуса очков для глаз. Биты 3-2 выбирают Binocular Function (Функцию Бинокля) согласно следующему: значение 0 означает, что дисплей является биноклем и может отображать только 2-мерные (2D) изображения; 1 означает, что дисплей является биноклем и может отображать 3-размерные (3D) изображения; 2 означает, что дисплей является монокуляром, и 3, зарезервированным для будущего использования. Биты 1-0 выбирают «Симметрию кривизны поля слева/справа» (Left-Right Field Curvature Symmetry) со значением 0, означающем, что искривление поля не определено. Если это поле нулевое, тогда все значения искривления поля от A1 до E5 установлены равными нулю, за исключением точки C3, которая определяет фокусное расстояние дисплея, или должно быть установлено равным нулю для указания того, что фокусное расстояние не определено. Значение 1 означает, что Левый и Правый дисплеи имеют одну и ту же симметрию; 2 означает, что Левый и Правый дисплеи являются зеркальными относительно вертикальной оси (столбец C); и 3 зарезервировано для будущего использования.
В одном варианте осуществления 1-байтовое поле Inter-Pupillary Distance (IPD) Minimum (Минимальное межзрачковое расстояние (МЗР, IPD)) определяет минимальное межзрачковое расстояние в миллиметрах (мм). Если это значение нулевое, тогда минимальное межзрачковое расстояние не определено. 1-байтовое поле Inter-Pupillary Distance (IPD) Maximum (Максимальное межзрачковое расстояние (МЗР, IPD)) определяет максимальное межзрачковое расстояние в миллиметрах (мм). Если это значение нулевое, тогда максимальное межзрачковое расстояние не определено.
Поле Points of Field Curvature List (Список точек кривизны поля) содержит список из 25 2-байтовых параметров, которые определяют фокусное расстояние в тысячных долях диоптрии (1/м) в диапазоне от 1 до 65535 (например, 1 составляет 0,001 диоптрии, и 65535 - 65,535 диоптрии). Эти 25 элементов в «Списке точек кривизны поля» помечены A1-E5, как показано на Фиг.82. Точки должны быть равномерно распределены по активной области дисплея. Столбец C соответствует вертикальной оси дисплея, и строка 3 соответствует горизонтальной оси дисплея. Столбцы А и E соответствуют левой и правой границам дисплея соответственно. И строки 1 и 5 соответствуют верхней и нижней границам дисплея соответственно. Порядок из 25 точек в списке таков: A1, B1, C1, D1, Е1, A2, B2, C2, D2, E2, A3, B3, C3, D3, E3, A4, B4, C4, D4, E4, A5, B5, C5, D5, E5.
Поле CRC содержит CRC всех байтов в пакете, включая поле "Длина пакета".
38. Пакет «Отчет об ошибках клиента»
Пакет «Отчет об ошибках клиента» (Client Error Report Packet) выступает как механизм или средство, чтобы разрешать клиенту выдавать на ведущее устройство список операционных ошибок. Клиент может обнаруживать широкий диапазон ошибок в ходе его нормальной работы в результате приема некоторых команд от ведущего устройства. Примеры этих ошибок включают в себя: клиенту, возможно, дали команду работать в режиме, который он не поддерживает, клиент, возможно, принял пакет, содержащий некоторые параметры, которые находятся вне набора или вне возможностей клиента, клиенту, возможно, дали команду войти в режим в неправильной последовательности. Пакет «Отчет об ошибках клиента» может использоваться, чтобы обнаружить ошибки в течение нормальной работы, но наиболее полезен для проектировщика и интегратора системы, чтобы диагностировать проблемы в разработке и интеграции систем клиента и ведущего устройства. Клиент указывает свою способность посылать пакет «Отчет об ошибках клиента», используя значение параметра, равное 142 в «Списке ответа о действительных параметрах» в пакете «Список ответа о действительных параметрах».
Формат одного варианта осуществления пакета «Отчет об ошибках клиента» иллюстрируется в общем виде на Фиг.83. Как можно видеть из Фиг.83, пакет «Отчет об ошибках клиента» структурирован так, что имеет поля Длина Пакета, Тип Пакета, cClient ID, Число элементов списка, Error Code List (Список кодов ошибки) и CRC. Значение Тип Пакета, равное 142, идентифицирует пакет как пакет «Отчет об ошибках клиента». Поле cClient ID зарезервировано для будущего использования и пока обычно устанавливается равными нулю. Поле «Число элементов списка» (2 байта) определяет количество элементов в следующем «Списке кодов ошибки». Поле «Список кодов ошибки» (здесь 8 байтов) является списком, содержащим один или более элементов «Списка с отчетом об ошибке». Формат одного элемента «Список с отчетом об ошибке» иллюстрируется на Фиг.84.
В одном варианте осуществления, как показано на Фиг.84, каждый элемент «Списка с отчетом об ошибке» имеет точно 4 байта в длину и имеет структуру в одном варианте осуществления, содержащую: 2-байтовое поле Display Error Code (Код ошибки дисплея), которое определяет тип сообщаемой ошибки, 2-байтовое поле Error Sub-code (Под-код ошибки), определяет больший уровень детализации относительно ошибки, определенной пакетом «Код ошибки клиента». Конкретное определение каждого «Кода ошибки клиента» определяется производителем клиента. Под-код ошибки не должен быть определен для каждого «Кода ошибки дисплея», и в тех случаях, когда «Под-код ошибки» не определен, это значение установлено равным нулю. Конкретное определение каждого «Под-кода ошибки» определяется производителем клиента.
39. Пакет «Идентификационная информация клиента»
Пакет «Идентификационная информация клиента» (Client Identification Packet) позволяет пользователю возвращать данные идентификации в ответ на пакет «Запрос конкретного состояния». В одном варианте осуществления клиент указывает способность посылать пакет «Идентификационная информация клиента», используя значение параметра, равное 144, в «Списке ответа о действительных параметрах» в пакете «Список ответа о действительных параметрах». Это полезно для того, чтобы ведущее устройство было способно определить название производителя клиентского устройства и номер модели, считывая эти данные от клиента. Эта информация может использоваться для определения, имеет ли клиент специальные возможности, которые не могут быть описаны в пакете "Возможности клиента". Существуют возможно два способа, средства или механизма для считывания идентификационной информации от клиента. Один из них - использование пакета «Возможности клиента», который содержит поля, аналогичные полям в базовой структуре EDID (поддержка дисплеев с расширенной системой идентификации). Другой способ - использование пакета «Идентификационная информация клиента», который содержит более богатый набор информации по сравнению с аналогичными полями в пакете "Возможности клиента". Это позволяет ведущему устройству идентифицировать производителей, которым не был назначен 3-символьный код EISA, и позволяет включать в серийные номера алфавитно-цифровые символы.
Формат одного варианта осуществления пакета «Идентификационная информация клиента» иллюстрируется в общем виде на Фиг.85. Как можно видеть из Фиг.85, пакет «Идентификационная информация клиента» структурирован так, что имеет поля Длина Пакета, Тип Пакета, cClient ID, Week of Mfr (Неделя изготовления), Year of Mfr. (Год изготовления), Length of Mfr Name (Длина названия производителя), Length of Product Name (Длина названия продукта), Length of Serial Number (Длина серийного номера), Manufacturer Name String (Строка названия производителя), Product Name String (Строка названия продукта), Serial Number String (Строка серийного номера) и CRC.
2-байтовое поле Длина Пакета содержит значение, которое идентифицирует пакет как пакет «Идентификационная информация клиента». Это значение выбрано равным 144 в одном варианте осуществления. Поле cClient ID (2 байта) вновь зарезервировано для будущего использования для идентификатора клиента и обычно устанавливается равным нулю. Поле CRC (2 байта) содержит 16-битовый CRC всех байтов в пакете, включая поле "Длина пакета".
1-байтовое поле «Неделя изготовления» содержит значение, которое определяет неделю изготовления дисплея. В по меньшей мере одном варианте осуществления это значение находится в диапазоне от 1 до 53, если это поддерживается клиентом. Если это поле не поддерживается клиентом, то оно обычно устанавливается равным нулю. 1-байтовое поле «Год изготовления» содержит значение, которое определяет год изготовления клиента (дисплея). Это значение равно смещению с 1990 года в качестве исходной точки, хотя могут использоваться другие базовые годы. Годы в диапазоне от 1991 до 2245 могут быть выражены этим полем. Пример: год 2003 соответствует значению 13 «Года изготовления». Если это поле не поддерживается клиентом, оно должно быть установлено равным значению нуля.
Поля «Длина названия производителя», «Длина названия продукта» и «Длина серийного номера» каждое содержит 2-байтовые значения, которые определяют длину поля «Строка названия производителя», включающего в себя любое нулевое завершение или пустые символы-заполнители, длину поля «Строка названия продукта», включающего в себя любое нулевое завершение или пустые символы-заполнители, и длину поля «Строка серийного номера», включающего в себя любое нулевое завершение или пустые символы-заполнители соответственно.
Поля «Строка названия производителя», «Строка названия продукта» и «Строка серийного номера» каждое содержит переменное количество байтов, указанных полями «Длина названия производителя», «Название продукта» и «Серийный номер» соответственно, которые содержат строку ASCII-символов, которые определяют производителя, название продукта и алфавитно-цифровой серийный номер дисплея соответственно. Каждая из этих строк завершается по меньшей мере одним символом пробела.
40. Пакет «Возможность альтернативного дисплея»
Пакет «Возможность альтернативного дисплея» (Alternate Display Capability Packet) используется как средство, структура или способ указать возможность альтернативных дисплеев, подсоединенных к контроллеру клиента MDDI. Он посылается в ответ на пакет «Запрос конкретного состояния». После запроса клиентское устройство посылает пакет «Возможность альтернативного дисплея» для каждого альтернативного дисплея, который поддерживается. Если клиент имеет более одного альтернативного дисплея, то клиент должен послать, сформировать или обеспечить множество пакетов «Возможность альтернативного дисплея», по одному для каждого дисплея, в ответ на единственный пакет «Запрос конкретного состояния», хотя некоторые конфигурации могут использовать множество пакетов «Запрос конкретного состояния» при необходимости, хотя это менее эффективно. Клиент может посылать пакет «Возможность альтернативного дисплея» таким образом, который может быть назван "непоследовательный порядок" на основании значения поля «Количество альтернативных дисплеев». Клиент может указывать способность послать пакет «Возможность альтернативного дисплея» посредством значения параметра 145 в «Списке ответа о действительных параметрах» в пакете «Список ответа о действительных параметрах».
Для систем MDDI, используемых во внутреннем режиме, может быть общим правилом иметь более одного дисплея, соединенного с контроллером клиента MDDI. Примером применения является мобильный телефон с большим дисплеем на внутренней части откидной крышки и меньшим дисплеем на внешней стороне. Для внутреннего клиента режима не является необходимым возвращать пакет «Возможность альтернативного дисплея» по двум возможным причинам. Первая - ведущее устройство может быть уже запрограммировано или иначе информировано об этих возможностях при изготовлении, так как они используются в обычном устройстве или корпусе. Вторая - из-за сборки этих двух частей клиент не может быть легко разъединен или отсоединен от соединения с ведущим устройством, и ведущее устройство может содержать жестко закодированную копию возможностей клиента или по меньшей мере знать, что они не изменяются при замене в клиенте, как иначе могло бы происходить.
Поле «Количество альтернативных дисплеев» в пакете "Возможности клиента" используется для сообщения, что присоединены более одного дисплея, и пакет «Возможность альтернативного дисплея» сообщает о возможности каждого дополнительного дисплея. Пакет потока видео содержит 4 бита в поле Pixel Data Attributes (Атрибуты пиксельных данных), чтобы адресовать каждый альтернативный дисплей в клиентском устройстве.
Формат одного варианта осуществления пакета «Возможность альтернативного дисплея» иллюстрируется в общем виде на Фиг.86. Как можно видеть из Фиг.86, пакет «Возможность альтернативного дисплея» структурирован так, что имеет поля Длина Пакета, Тип Пакета, cClient ID, Alt Display Number (Количество альтернативных дисплеев), Зарезервированное 1, Bitmap Width (Ширина битовой карты), Bitmap Height (Высота битовой карты), Display Window Width (Ширина окна на дисплее), Display Window Height (Высота окна на дисплее), Color Map RGB Width (Ширина карты цвета RGB), RGB Capability (Возможность RGB), Monochrome Capability (Возможность монохромного отображения), Зарезервированное 2, Возможность Y Cb Cr, Bayer Capability (Возможность формата Байера), Зарезервированное 3, Display Feature Capability (Возможность характеристик дисплея) и CRC. Значение «Тип Пакета» 145 идентифицирует пакет как пакет «Возможность альтернативного дисплея». Поле cClient ID в настоящее время зарезервировано для идентификатора клиента для будущего использования и обычно установлено равным нулевому значению, обычно устанавливая биты в уровень логического нуля.
Поле «Количество альтернативных дисплеев» использует 1 байт для указания идентификационной информации альтернативного дисплея с целым числом в диапазоне от 0 до 15. Первый альтернативный дисплей обычно обозначается номером 0, и другие альтернативные дисплеи идентифицируются уникальными значениями «Количество альтернативных дисплеев», причем наибольшее используемое значение является общим количеством альтернативных дисплеев минус 1. Значения, большие, чем общее количество альтернативных дисплеев минус 1, не используются. Пример: мобильный телефон, имеющий первичный дисплей и дисплей идентификатора вызывающего абонента, соединенный с клиентом MDDI, имеет один альтернативный дисплей, так что «Количество альтернативных дисплеев» для отображения идентификатора вызывающего абонента равно нулю и поле «Количество альтернативных дисплеев» в пакете "Возможности клиента" имеет значение 1.
Поле «Зарезервированное 1» (1 байт) зарезервировано для будущего использования. Поэтому все биты в этом поле в настоящее время установлены равными нулю или равными уровню логического нуля. В одном варианте осуществления одна цель наличия этого поля, присутствующего в пакете, состоит в том, чтобы выровнять все последующие 2-байтовые поля к 16-битовому адресу слова и выровнять все 4-байтовые поля к 32-битовому адресу слова.
Поле «Ширина битовой карты» использует 2 байта, которые определяют ширину битовой карты, выраженную как количество пикселей. Поле «Высота битовой карты» использует 2 байта, которые определяют высоту битовой карты, выраженную как количество пикселей. Поле «Ширина окна на дисплее» использует 2 байта, которые определяют ширину окна на экране дисплея, выраженную как количество пикселей. Поле «Высота окна на дисплее» использует 2 байта, которые определяют высоту окна на экране дисплея, выраженную как количество пикселей.
Поле «Ширина карты цвета RGB» использует 2 байта, которые определяют количество битов красного, зеленого и синего цветных компонентов, которые могут быть отображены в режиме визуального отображения «Карты цвета» (палитры). Максимум 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» определяет количество битов разрешения, которые могут быть отображены в формате YCb Cr. Если клиент не может использовать формат YCb Cr, тогда это значение нулевое. Слово «Возможность Y Cb Cr» состоит из трех отдельных значений без знака: биты 3-0 задают максимальное количество битов, которые определяют выборку Cb, биты 7-4 задают максимальное количество битов, которые определяют выборку Cr, биты 11-8 задают максимальное количество битов, которые определяют выборку Y, и биты 14-12 зарезервированы для будущего использования и установлены равными нулю. Бит 15, когда установлен в единицу, указывает, что клиент может принимать пиксельные данные Y Cb Cr или в упакованном или неупакованном формате. Если бит 15 установлен равными нулю, это указывает, что клиент может принимать пиксельные данные Y Cb Cr только в неупакованном формате.
2-байтовое поле "Возможность формата Байера" определяет количество битов разрешения, группу пикселей и порядок пикселя, которые могут быть переданы в формате Байера. Если клиент не может использовать формат Байера, тогда это значение установлено в нуль. Поле "Возможность формата Байера" состоит из следующих значений: биты 3-0 определяют максимальное количество битов интенсивности (яркости), которые существуют в каждом пикселе, биты 5-4 определяют шаблон группы пикселей, который может требоваться. Биты 8-6 определяют упорядоченность пикселей, который требуется, и биты 14-9 зарезервированы для будущего использования и установлены равными нулю. Бит 15, когда установлен в единицу, указывает, что клиент может принимать пиксельные данные в формате Байера или в упакованном или неупакованном формате. Если бит 15 установлен равным нулю, это указывает, что клиент может принимать пиксельные данные в формате Байера только в неупакованном формате.
Поле «Зарезервированое 3», здесь 2 байта, зарезервировано для будущего использования. Все биты в этом поле поэтому обычно установлены или равны уровню логического нуля или значению 0. В одном варианте осуществления текущая цель наличия этого поля в пакете состоит в том, чтобы выровнять последующие 2-байтовые поля к 16-битовому адресу слова и выровнять 4-байтовые поля к 32-битовому адресу слова.
Поле Display Feature Capability Indicators (Индикаторы возможностей характеристик дисплея), здесь использующее 4 байта, содержит набор флагов, которые указывают, поддерживаются ли конкретные особенности (возможности) в альтернативном дисплее. Бит, установленный в единицу, указывает, что специфическая или заранее установленная возможность поддерживается, и бит, установленный равным нулю, указывает, что возможность не поддерживается.
В одном варианте осуществления поле «Возможности характеристик дисплея» использует 4 байта, которые содержат набор флагов, которые указывают специфические особенности в альтернативном дисплее, которые поддерживаются. Бит, установленный в уровень логической единицы, указывает, что данная возможность поддерживается, в то время как бит, установленный в уровень логического нуля, указывает, что возможность не поддерживается. В одном варианте осуществления значение для бита 0 указывает, поддерживается ли пакет «Поблочная пересылка битовой карты» (тип пакета 71). Значение для битов 1, 2 и 3 указывает, поддерживаются ли пакет «Заполнение области битовой карты» (тип пакета 72), пакет «Заполнение шаблона битовой карты» (тип пакета 73) или пакет «Буфер кадра считывания» (тип пакета 74) соответственно. Значение для бита 4 указывает, имеет ли альтернативный дисплей возможность делать один цвет прозрачным, используя пакет «Разрешение прозрачного цвета».
В этом варианте осуществления значение бита 10 поля «Возможность характеристик дисплея» указывает, имеет ли альтернативный дисплей способность поддерживать состояние 01 потребления энергии дисплеем. Состояние потребления энергии дисплея устанавливают, используя биты [3:2] поля Power State (Состояние потребления энергии) пакета «Состояние потребления энергии дисплеем», описанного выше. Состояние 01 потребления энергии дисплеем является состоянием, когда выбранный дисплей не подсвечивается и потребляет минимальное количество мощности, если вообще потребляет, и содержание буфера кадра обычно гарантируется или разумно обеспечивается так, чтобы быть сохраненным в течение этого состояния.
Значение для бита 13 поля «Возможность характеристик дисплея» указывает, имеет ли альтернативный дисплей способность установить один или более параметров видео, поддерживая пакеты характеристик VCP: пакет "Запрос характеристик VCP», пакет "Ответ с характеристиками VCP», пакет «Установка характеристик VCP», пакет «Запрос действительных параметров» и пакет «Ответ о действительных параметрах». Значение для бита 14 указывает, имеет ли альтернативный дисплей способность записывать пиксельные данные в автономный буфер кадра отображения, что иллюстрируется на Фиг.88A. Если этот бит установлен равным уровню логической единицы, тогда биты обновления дисплея (биты 7 и 6 поля «Атрибуты пиксельных данных» в пакете «Поток видео») могут быть установлены равным значению '01'.
Значение для бита 15 поля «Возможность характеристик дисплея» указывает, когда альтернативный дисплей имеет способность записывать пиксельные данные только в буфер кадра дисплея, в настоящее время используемый, чтобы регенерировать отображаемое изображение, как проиллюстрировано на Фиг.88B. Если этот бит установлен в логическую единицу, тогда биты «Обновление дисплея» (биты 7 и 6 из поля «Атрибуты пиксельных данных» в пакете «Поток видео») могут быть установлены равными значению '00'. Значение для бита 16 указывает, когда альтернативный дисплей имеет способность записывать пиксельные данные из единственного пакета «Поток видео» во все буферы кадра дисплея, что проиллюстрировано на Фиг.88C. Если этот бит установлен равным уровню логической единицы, тогда биты «Обновление дисплея» (биты 7 и 6 из поля «Атрибуты пиксельных данных» в пакете «Поток видео») могут быть установлены равными значению '11'.
В одном варианте осуществления значение для бита 21 поля «Возможность характеристик дисплея» указывает, когда альтернативный дисплей имеет способность использовать поле «Растровая операция» в пакете «Поблочная пересылка битовой карты» (тип пакета 71), пакете «Заполнение области битовой карты» (тип пакета 72), и пакете «Заполнение шаблона битовой карты» (тип пакета 73), если эти пакеты поддерживаются альтернативным дисплеем, как определяется битами 0, 1 и 2 или этим полем. В одном варианте осуществления, если бит 21 имеет уровень или значение логического нуля и пакеты поддерживаются, то альтернативный дисплей не имеет способности использовать поле «Растровая операция» и альтернативный дисплей обычно имеет возможность только копировать или осуществлять запись в пиксельные местоположения, указанные этими пакетами.
В одном варианте осуществления биты 9-5, 11, 12, 20-17 и 31-22 поля «Возможность характеристик дисплея» в настоящее время зарезервированы для будущего использования или альтернативных целей, полезных для проектировщиков системы, и обычно устанавливаются равными нулевому значению или уровню логического нуля.
В одном варианте осуществления 2-байтовое поле CRC содержит 16-битовый CRC всех байтов в пакете, включая поле "Длина пакета".
41. Пакеты «Доступ к регистрам»
Пакет «Доступ к регистрам» (Register Access Packet) обеспечивает или ведущее устройство или клиента средством, механизмом или способом обращаться к конфигурации и регистрам состояния на противоположном конце линии связи MDDI. Регистры, вероятно, будут уникальными для каждого дисплея или контроллера устройства. Эти регистры уже существуют во многих дисплеях, которые требуют конфигураций параметров установки, режимов работы и имеют другие полезные и необходимые параметры настройки. Пакет «Доступ к регистрам» позволяет ведущему устройству или клиенту MDDI и записывать в регистр, и запрашивать считывание регистра, используя линию связи MDDI. Когда ведущее устройство или клиент запрашивает считывание регистра, противоположный конец должен ответить посредством посылки данных регистра в пакете того же самого типа, но также и посредством указания, что они являются данными, считанными из конкретного регистра с использованием поля Read/Write Info (Информация считывания/записи). Пакет «Доступ к регистрам» может использоваться для считывания или записи множества регистров, задавая индекс регистра большим чем 1. Клиент указывает способность поддерживать пакет «Доступ к регистрам», используя бит 22 поля Client Feature Capability (Возможность характеристик клиента) в пакете "Возможности клиента". Клиент будет использовать пакет инкапсуляции, чтобы послать пакет «Доступ к регистрам», таким образом представляя то, что проявляется как пакет в пределах конфигурации или структуры пакета.
Формат одного варианта осуществления пакета «Доступ к регистрам» иллюстрируется в общем виде на Фиг.87. Как можно видеть из Фиг.87, пакет «Доступ к регистрам» структурирован так, что имеет поля Длина Пакета, Тип Пакета, bClient ID, Read/Write Info or information (Информация считывания/записи или информация), Register Address (Адрес регистра), Параметр CRC, Register Data List (Список данных регистра) и Register Data CRC (CRC данных регистра). Значение Тип Пакета 146 идентифицирует пакет как пакет «Доступ к регистрам». Поле bClient ID зарезервировано для будущего использования и в настоящее время обычно устанавливается равным нулю.
В одном варианте осуществления 2-байтовое поле «Информация считывания/записи» служит как механизм для задания конкретного пакета или как тип пакета для записи, или чтения, или ответа на чтение и обеспечивает индекс (счетчик) значений данных.
Биты 15-14 действуют как «Флаги считывания/записи» (Read/Write Flags). Если эти биты [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 на пакете с ошибками приближается к 7,6x10-6 на очень длинных пакетах, содержащих много ошибок. В соответствии с конструкцией линия связи MDDI будет иметь очень низкий или нулевой коэффициент ошибок. CRC предназначен, чтобы использоваться для контроля "здоровья" линии связи, и не предназначен, чтобы обнаруживать ошибки на конкретных пакетах, чтобы определить, должны ли быть пакеты повторно переданы.
В примерном варианте осуществления полином, используемый для вычисления кода CRC, известен как CRC-16, или X16 + X15 + X2 + X0. Типовая реализация генератора кода CRC и блока 3600 проверки, применяемого для осуществления изобретения, иллюстрируется на Фиг.36. На Фиг.36 регистр 3602 CRC инициализируют значением 0x0001 только до передачи первого бита пакета, который является входным на линии Tx_MDDI_Data_Before_CRC, тогда байты пакета сдвигаются в регистр, начиная с первого младшего значащего бита. Следует заметить, что количество битов регистра на этом чертеже соответствуют порядку используемого полинома, а не позиции битов, используемых MDDI. Более эффективным является сдвигать регистр кода CRC в одном направлении, и это приводит к тому, что бит 15 кода CRC появляется в битовой позиции 0 поля CRC MDDI и бит 14 кода CRC-регистра в битовой позиции 1 поля CRC MDDI и т.д., пока не будет достигнута битовая позиция 14 MDDI.
Например, если содержанием пакета для пакета «Запрос клиента и состояния» является: 0x000c, 0х0046, 0х000, 0х0400, 0х00, 0х00, 0х0000 (или представленный как последовательность байтов: 0x0c, 0х00, 0х46, 0х00, 0х00, 0х00, 0х00, 0х04, 0х00, 0х00, 0х00, 0х00), и подаются, используя входы мультиплексоров 3604 и 3606 и схему 3608 И, результирующим выходным кодом CRC на линии Tx_MDDI_Data_With_CRC является 0xd9aa (или представленный как последовательность 0xaa, 0xd9).
Когда генератор кода CRC и блок 3600 проверки сконфигурирован как блок проверки CRC, то код CRC, который получен на линии Rx_MDDI_Data, подают на мультиплексор 3604 и логический элемент 3612 "ИСКЛЮЧАЮЩЕЕ ИЛИ" (XOR), и является битом, и сравнивается бит-за-битом со значением, найденным в регистре кода CRC, используя логический элемент 3610 ИЛИ-НЕ, логический элемент 3608 И и логический элемент 3614 И. Если имеются какие-либо ошибки, которые выводятся логическим элементом 3614 И, CRC увеличивается однократно для каждого пакета, который содержит ошибку кода CRC, посредством подключения выхода логического элемента 3614 к входу регистра 3602. Следует заметить, что примерная схема, показанная на диаграмме на Фиг.36, может выдавать более одного сигнала ошибочного кода CRC в пределах заданного окна CHECK_CRC_NOW (см. Фиг.37B). Поэтому счетчик ошибок кода CRC обычно только подсчитывает первый случай ошибки CRC в пределах каждого интервала, когда CHECK_CRC_NOW является активным. Если сконфигурирован как генератор кода CRC, CRC заканчивает работу регистра кода CRC во время совпадения с концом пакета.
Синхронизация для сигналов ввода и вывода и сигналов разрешения иллюстрируется графически на Фиг. 37A и 37B. Формирование кода CRC и передача пакета данных иллюстрируется на Фиг.37A с состоянием (0 или 1) сигналов Gen_Reset, Check_CRC_Now, Generate_CRC_Now и Sending_MDDI_Data вместе с сигналами Tx_MDDI_Data_Before_CRC и Tx_MDDI_Data_With_CRC. Прием пакета данных и проверка значения CRC иллюстрируется на Фиг.37B с состоянием сигналов Gen_Reset, Check_CRC_Now, Generate_CRC_Now и Sending_MDDI_Data вместе с сигналами ошибки CRC и RX_MDDI_DATA.
E. "Перегрузка" кода ошибки для кода CRC пакета
Всякий раз, только когда пакеты данных и CRC передаются между ведущим устройством и клиентом, никаких кодов ошибки не обеспечивается. Единственной ошибкой является потеря синхронизации. В противном случае необходимо ожидать в течение простоя линии связи из-за недостатка хорошего тракта передачи данных или конвейера и затем устанавливать линию связи в исходное состояние и продолжать работу. К сожалению, это требует большого времени и является отчасти неэффективным.
Для использования в одном варианте осуществления была разработана новая методика, в которой часть CRC для пакетов используется для передачи информации о коде ошибок. Это показано в общем виде на Фиг.65. То есть один или более кодов ошибки формируются процессорами или устройствами, обрабатывающими передачу данных, которые указывают конкретные заранее определенные ошибки или дефекты, которые могут происходить при обработке обмена или линии связи. Когда встречаются с ошибкой, соответствующий код ошибки формируется и передается, используя биты для кода CRC пакета. То есть значение CRC перегружается, или перезаписывается, требуемым кодом ошибки, который может быть обнаружен на приемном конце посредством блока мониторинга ошибок или блока проверки, который контролирует значения поля CRC. Для тех случаев, в которых код ошибки совпадает со значением CRC по некоторым причинам, передают дополнение ошибки, чтобы предотвратить путаницу.
В одном варианте осуществления, чтобы обеспечить устойчивую систему предупреждения и обнаружения ошибки, код ошибки может быть передан несколько раз, используя последовательность пакетов, обычно все, которые были переданы или посланы после того, как ошибка была обнаружена. Это происходит до тех пор, пока условие (состояние), создающее ошибку, не будет удалено из системы, в этот момент правильные CRC биты передают без обременения (перегрузки) другим значением.
Эта методика "перегрузки" значения CRC обеспечивает намного более быстрый ответ на системные ошибки при использовании минимального количества дополнительных битов или полей.
Как показано на Фиг.66, механизм или устройство 6600 перезаписи CRC показаны, используя детектор или средство 6602 обнаружения сигнала ошибки, которое может образовывать часть другой схемы, описанной выше или известной, которая обнаруживает присутствие или существование ошибок в коммуникационной линии связи или процессе обмена. Генератор или средство 6604 формирования кода ошибки, который может быть образован как часть другой схемы или использует методику, например таблицу просмотра, для сохранения предварительно выбранных сообщений об ошибках, формирует один или более кодов ошибки, чтобы указать специфические заранее определенные ошибки или дефекты, которые были обнаружены как имеющие место. Может быть легко понято, что устройства 6602 и 6604 могут быть сформированы как единая схема или устройство, как требуется, или как часть запрограммированной последовательности этапов для других известных процессоров и элементов.
Компаратор или средство 6606 сравнения значения CRC показано для проверки того, является ли выбранный(е) код или коды ошибки теми же самыми, что и передаваемое значение CRC. Если это имеет место, тогда генератор или средство формирования или устройство дополнения кода используется, чтобы обеспечить дополнение кодов ошибки, в отношении того, чтобы не была сделана ошибка в качестве первоначального шаблона или значения кода CRC, и не спутать или не усложнить работу схемы обнаружения. Блок выбора или элемент средства или устройство 6610 выбора кода ошибки затем выбирает код ошибки или значение, которое требуется вставить, или записать поверх, или их соответствующее дополнение, соответствующим образом. Блок перезаписи или средство 6612 или механизм перезаписи кода CRC ошибки является устройством, которое принимает поток данных, пакеты и требуемые коды, которые должны быть вставлены, и перезаписывает соответствующие или подходящие значения CRC, чтобы передать требуемые коды ошибки к приемному устройству.
Как упомянуто выше, код ошибки может быть передан несколько раз, используя последовательность пакетов, так что блок 6612 перезаписи может использовать элементы памяти, чтобы поддерживать копии кодов в течение обработки или выбирать эти коды из предыдущих элементов или других известных ячеек памяти, которые могут быть использованы для хранения или удержания их значений необходимым образом, или как требуется.
Обобщенная обработка, которая реализуется в механизме перезаписи согласно Фиг.66, показывается более подробно на Фиг. 67A и 67B. На Фиг.67A ошибка, одна или более, обнаруживается на этапе 6702 в данных или процессе обмена, и код ошибки выбирается на этапе 6704, чтобы указать это состояние. В то же самое время или в соответствующий момент времени значение CRC, которое должно быть заменено, проверяется на этапе 6706 и сравнивается с требуемым кодом ошибки на этапе 6708. Результат этого сравнения, как описано выше, является определением относительно того, является ли этот требуемый код или другие характерные (представляющие) значения тем же самым, как текущее значение CRC. Если это так, то обработка переходит к этапу 6712, где дополнение, или в некоторых случаях другое представляющее значение, которое требуется, выбирается в качестве кода для вставки. Когда определено, какие коды ошибки или значения должны быть вставлены на этапах 6710 и 6714, этот соответствующий код выбирается для вставки. Эти этапы иллюстрируются как отдельные с целью ясности, но обычно представляют собой единственный выбор на основании результата этапа 6708 принятия решения. Наконец, на этапе 6716 соответствующие значения перезаписывают в местоположение кода CRC для передачи с пакетами, являющимися объектом обработки.
На стороне приема пакета, как показано на Фиг.67B, значения CRC пакета контролируются на этапе 6722. Обычно значения CRC контролируются одним или более процессами в системе для определения, произошла ли ошибка при передаче данных и нужно ли запрашивать повторную передачу пакета или пакетов или запретить дальнейшие операции и т.д., некоторые из которых описаны выше. В качестве части такого контроля эта информация может также использоваться для сравнения значений с известными или предварительно выбранными кодами ошибки или представляющими значениями и обнаружения присутствия ошибок. Альтернативно, может быть осуществлен отдельный процесс обнаружения и мониторинга ошибок. Если окажется, что код присутствует, он извлекается или иначе регистрируется на этапе 6724 для дальнейшей обработки. На этапе 6726 может быть сделано определение относительно того, действительно ли он является фактическим кодом или дополнением, в этом случае используется дополнительный этап 6728, чтобы преобразовать это значение к требуемому значению кода. В любом случае результирующий извлеченный код, дополнение или другие восстановленные значения затем используются для обнаружения, какая произошла ошибка, из переданного кода на этапе 6730.
V. Бездействие линии связи
Линия связи MDDI может входить в состояние бездействия (режим "спячки") быстро и пробуждаться от бездействия быстро. Эта быстрота реагирования (оперативность) позволяет коммуникационной системе или устройству вводить линию связи MDDI в состояние бездействия часто, чтобы уменьшить потребляемую мощность, так как она может очень быстро заново пробуждаться для использования. В одном варианте осуществления, когда клиент во внешнем режиме пробуждается из бездействия впервые, он делает это на скорости передачи данных и со стробирующими синхроимпульсами, что является совместимым со скоростью передачи 1 Мбит/с, т.е. пара MDDI_Stb должна переключаться с частотой 500 кГц. Как только характеристики клиента были обнаружены или сообщены на ведущее устройство, тогда ведущее устройство может пробуждать линию связи обычно до любой скорости передачи - от 1 Мбит/с до максимальной скорости передачи, с которой клиент может работать. Клиенты во внутреннем режиме могут пробуждаться на любой частоте, с которой и ведущее устройство и клиент могут работать. Это также обычно применимо к первому разу, когда пробуждается клиент во внутреннем режиме.
В одном варианте осуществления, когда линия связи пробуждается от бездействия, ведущее устройство и клиент обмениваются последовательностью импульсов. Эти импульсы могут быть обнаружены, используя низкоскоростные приемники линии, которые потребляют только часть тока, которая требуется дифференциальным приемникам, чтобы принять сигналы при максимальной скорости работы линии связи. Линию связи могут пробуждать или ведущее устройство, или клиент, так что протокол пробуждения предназначен для обработки возможного состязания, которое может происходить, если и ведущее устройство, и клиент пытаются пробуждаться одновременно.
В течение состояния бездействия дифференциальные задающие устройства MDDI_Data и MDDI_Stb заблокированы (запрещены) в высокоимпедансном состоянии, и дифференциальное напряжение по всем дифференциальным парам равно нулю вольт, в то время как линия связи находится или остается в бездействии. Дифференциальные приемники линии, используемые для обнаружения последовательности импульсов во время пробуждения из бездействия, имеют заданное смещение по напряжению. В одном варианте осуществления порог между уровнями логической единицы и логического нуля в этих приемниках составляет приблизительно 125 мВ. Это вынуждает невозбужденную дифференциальную пару рассматривать как имеющую уровень логического нуля в течение последовательности пробуждения линии связи. Однако, как понятно специалисту, нормальный уровень логической единицы, обеспечиваемый дифференциальным задающим устройством, все еще интерпретируется как уровень логической единицы дифференциальными приемниками, имеющими смещение 125 мВ. Пример поведения специального маломощного дифференциального приемника со смещением 125 мВ по сравнению со стандартным дифференциальным приемником с нулевым входным смещением иллюстрируется на Фиг.38. Форма сигнала не является представляющей типичный сигнал MDDI, а представлена здесь только для разъяснения или иллюстрации различия между двумя типами дифференциальных приемников.
Чтобы войти в Состояние Бездействия (Hibernation State), ведущее устройство посылает 64 такта MDDI_Stb после кода CRC для пакета "Завершение работы линии связи". Ведущее устройство блокирует (запрещает) выходной сигнал MDDI_Data0 ведущего устройства в диапазоне от 16 до 56 тактов MDDI_Stb (включая задержки распространения запрещения выходного сигнала) после кода CRC. Ведущее устройство заканчивает посылку 64 тактов MDDI_Stb после кода CRC для пакета "Завершение работы линии связи" прежде, чем оно инициирует последовательность пробуждения. В одном варианте осуществления инициированное ведущим устройством пробуждение определяется, когде ведущее устройство вынуждено ожидать по меньшей мере 100 нс после того, как MDDI_Data0 достигает достоверного уровня логической единицы, перед возбуждением импульса на MDDI_Stb. В одном варианте осуществления клиент ожидает по меньшей мере 60 тактов MDDI_Stb после кода CRC для пакета "Завершение работы линии связи" прежде, чем оно возбуждает MDDI_Data0 до уровня логической единицы, чтобы попытаться пробудить ведущее устройство.
Чтобы "пробудиться" из Состояния Бездействия, предпринимаются несколько действий или процессов. Когда клиент, здесь дисплей, нуждается в данных или обмене, услуге, от ведущего устройства, он генерирует импульс запроса, возбуждая линию MDDI_Data0 до состояния логической единицы в течение приблизительно от 70 до 1000 мкс, в то время как MDDI_Stb является неактивным, и сохраняет MDDI_Data0 в состоянии уровня логической единицы в течение приблизительно 70 тактов MDDI_Stb (в диапазоне от 60 до 80) после того, как MDDI_Stb становится активным, хотя при необходимости могут использоваться другие периоды. Клиент затем отключает (блокирует) задающее устройство MDDI_Data0, переводя его в высокоимпедансное состояние.
Если MDDI_Stb активен в течение бездействия, хотя это маловероятно, то клиент может только устанавливать MDDI_Data0 в состояние логической единицы в течение приблизительно 70 тактов MDDI_Stb (в диапазоне от 60 до 80). Это действие заставляет ведущее устройство начинать или выполнять рестарт трафика данных на прямой линии связи (208) и запрашивать клиента о его состоянии.
Ведущее устройство должно обнаружить присутствие импульса запроса от клиента (используя маломощный дифференциальный приемник со смещением +125 мВ) и начинает последовательность запуска, сначала устанавливая MDDI_Stb до уровня логического нуля и MDDI_Data0 до уровня высокого логического уровня в течение по меньшей мере приблизительно 200 нс. И затем во время переключения MDDI_Stb продолжает возбуждать MDDI_Data0 до уровня логической единицы в течение приблизительно 150 тактов MDDI_Stb (диапазон от 140 до 160) и до логического нуля в течение приблизительно 50 тактов MDDI_Stb. Клиент не должен посылать импульс запроса на обслуживание, если он обнаруживает MDDI_Data0 в состоянии логической единицы в течение более чем 80 тактов MDDI_Stb. Когда клиент обнаружил MDDI_Data0 на уровне логической единицы в течение от 60 до 80 тактов MDDI_Stb, он начинает искать интервал, где ведущее устройство возбуждает MDDI_Data0 до уровня логического нуля в течение 50 тактов MDDI_Stb. После того как ведущее устройство возбуждает MDDI_Data0 до уровня логического нуля в течение длительности 50 тактов MDDI_Stb, тогда ведущее устройство начинает посылать пакеты по линии связи. Первым посланным пакетом является пакет "Заголовок под-кадра". Клиент начинает просматривать пакет "Заголовок под-кадра" после того, как MDDI_Data0 находится на уровне логического нуля в течение 40 тактов MDDI_Stb в интервале 50 тактов. Характер выбора времен и допусков интервалов времени, относящихся к обработке бездействия, и последовательность запуска описаны ниже. (См. Фиг. 68A-C ниже.)
Ведущее устройство может инициировать пробуждение, сначала разрешая MDDI_Stb и одновременно возбуждая его до уровня логического нуля. MDDI_Stb не должен быть установлен равным уровню логической единицы, до тех пор пока импульсы не будут выданы, как описано ниже. После того как сигнал MDDI_Stb достигает уровня логического нуля, ведущее устройство разрешает MDDI_Data0 и одновременно устанавливает его в уровень логической единицы. MDDI_Data0 не должен быть установлен равным уровню логического нуля в течение процесса пробуждения вплоть до интервала, где он устанавливается в уровень логического нуля в течение интервала в 50 импульсов MDDI_Stb, как описано ниже. Ведущее устройство должно ожидать по меньшей мере 200 нс после того, как MDDI_Data0 достигает достоверного уровня логической единицы перед выдачей импульсов на MDDI_Stb. Эта временная зависимость происходит во время рассмотрения задержек разрешения выходного сигнала в наихудшем случае. Это по существу гарантирует, что клиент имеет достаточное время, чтобы полностью разрешить свой MDDI_Stb приемник, после того как он будет пробужден уровнем логической единицы на MDDI_Data0, который устанавливается ведущим устройством.
Пример этапов обработки для типичного события 3800 запроса на обслуживание клиента без состязания проиллюстрирован на Фиг.39A, где события помечены для удобства иллюстрации с использованием символов A, B, C, D, E, F и G. Процесс начинается в точке А, когда ведущее устройство посылает пакет "Завершение работы линии связи" клиентскому устройству, чтобы сообщить ему, что линия связи будет переходить в состояние бездействия с малым потреблением мощности. На следующем этапе ведущее устройство входит в состояние бездействия с малым потреблением мощности посредством запрещения задающего устройства MDDI_Data0 и устанавливая задающее устройство MDDI_Stb в состояние логического нуля, как показано в точке B. MDDI_Data0 возбуждается до уровня логического нуля посредством высокоимпедансной схемы смещения. После некоторого периода времени клиент посылает импульс запроса на обслуживание ведущему устройству, возбуждая MDDI_Data0 до уровня логической единицы, как можно видеть в точке C. Ведущее устройство все еще выдает уровень логического нуля, используя высокоимпедансную схему смещения, но задающее устройство в клиенте устанавливает линию связи на уровень логической единицы. В течение 50 мкс ведущее устройство распознает импульс запроса на обслуживание и выдает уровень логической единицы на MDDI_Data0 посредством разрешения своего задающего устройства, как можно видеть в точке D. Клиент затем прекращает попытки выдавать импульс запроса на обслуживание, и клиент переводит свое задающее устройство в высокоимпедансное состояние, как можно видеть в точке E. Ведущее устройство возбуждает MDDI_Data0 до уровня логического нуля в течение 50 мкс, как показано в точке F, и также начинает генерировать MDDI_Stb способом, совместимым с уровнем логического нуля, на MDDI_Data0. Клиент начинает просматривать пакет "Заголовок под-кадра" после того, как MDDI_Data0 равно логическому нулю в течение 40 тактов MDDI_Stb. После установки MDDI_Data0 в уровень логического нуля и установления MDDI_Stb в течение 50 мкс, ведущее устройство начинает передавать данные по прямой линии связи, посылая пакет "Заголовок под-кадра", как показано в точке G.
Аналогичный пример проиллюстрирован на Фиг.39B, где запрос на обслуживание выдается после того, как началась последовательность рестарта линии связи, и события заново помечаются, используя символы A, B, C, D, E, F и G. Это представляет сценарий наихудшего случая, где импульс или сигнал запроса от клиента прибывают наиболее близко для повреждения пакета "Заголовок под-кадра". Процесс начинается в точке А, когда ведущее устройство заново посылает пакет "Завершение работы линии связи" клиентскому устройству, чтобы сообщить ему, что линия связи будет переходить в состояние бездействия с малым потреблением мощности. На следующем этапе ведущее устройство входит в состояние бездействия с малым потреблением мощности посредством отключения задающего устройства MDDI_Data0 и установкой задающего устройства MDDI_Stb в уровень логического нуля, как показано в точке B. Как и прежде, MDDI_Data0 возбуждается до уровня логического нуля высокоимпедансной схемой смещения. После некоторого периода времени ведущее устройство начинает последовательность рестарта (повторного инициирования) линии связи посредством возбуждения MDDI_Data0 до уровня логической единицы в течение 150 мкс, как можно видеть в точке C. До истечения 50 мкс, проходящих после рестарта линии связи, дисплей также выставляет MDDI_Data0 в течение длительности 70 мкс, как можно видеть в точке D. Это происходит потому, что дисплей имеет потребность запросить услугу от ведущего устройства и не распознает, что ведущее устройство уже начало последовательность рестарта линии связи. Клиент затем прекращает попытки устанавливать импульс запроса на обслуживание, и клиент переводит его задающее устройство в высокоимпедансное состояние, как можно видеть в точке E. Ведущее устройство продолжает возбуждать 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), используемой для основных схем. Потребляемая мощность использования данных и линий строба в качестве уведомления о пробуждении и источника измерения также будет более низкой, так как никакие внешние схемы не должны работать в качестве основных элементов, чтобы ожидать пробуждения, основанного на ведущем устройстве. Число циклов или используемых тактов является примерным, и другие периоды могут использоваться, как очевидно специалистам в данной области техники.
Чтобы пояснить и проиллюстрировать работу этой новой методики, синхронизация MDDI_Data0, MDDI_Stb и различные операции в отношении тактовых циклов показаны на Фиг.68A, 68B и 68C.
Пример этапов обработки для типичного Инициированного ведущим устройством пробуждения без конфликтов (состязаний) иллюстрируется на Фиг.68A, где события снова помечены для удобства иллюстрации, используя символы A, B, C, D, E, F и G. Процесс начинается в точке А, когда ведущее устройство посылает пакет "Завершение работы линии связи" клиентскому устройству, чтобы сообщить ему, что линия связи будет переходить в состояние бездействия с малым потреблением мощности. На следующем этапе, точке B, ведущее устройство переключает MDDI_Stb в течение приблизительно 64 тактов (или как требуется для системной конструкции), чтобы разрешить проведение обработки клиентом, которая должна быть закончена до прекращения переключения MDDI_Stb, которая останавливает восстановленный сигнал синхронизации в клиентском устройстве. Ведущее устройство также первоначально устанавливает MDDI_Data0 в уровень логического нуля и затем отключает выдачу MDDI_Data0 в диапазоне от 16 до 48 тактов (обычно включая в себя задержку распространения отключения выходного сигнала) после кода CRC. Может потребоваться перевести высокоскоростные приемники для MDDI_Data0 и MDDI_Stb в клиенте в состояние потребления малой мощности некоторое время спустя после 48 циклов после кода CRC и до следующего этапа (C). Клиент переводит свои высокоскоростные приемники для MDDI_Data0 и MDDI_Stb в состояние бездействия в любое время после нарастающего фронта 48-го такта MDDI_Stb после кода CRC в пакете «Завершение работы линии связи». Рекомендуется, чтобы клиент перевел свои высокоскоростные приемники для MDDI_Data0 и MDDI_Stb в состояние бездействия перед нарастающим фронтом 64-го такта MDDI_Stb после кода CRC в пакете «Завершение работы линии связи».
Ведущее устройство входит в состояние бездействия с потреблением малой мощности в точке или на этапе С посредством отключения задающих устройств MDDI_Data0 и MDDI_Stb и переводя контроллер ведущего устройства в состояние бездействия с потреблением малой мощности. Можно также устанавливать задающее устройство MDDI_Stb в уровень логического нуля (с использованием высокоимпедансной схемы смещения) или продолжать выполнение переключения в течение состояния бездействия, как требуется. Клиент находится также в состоянии бездействия с уровнем потребления малой мощности.
После некоторого периода времени ведущее устройство начинает последовательность перезагрузки (рестарта) линии связи в точке D, разрешая выходные сигналы задающего устройства MDDI_Data0 и MDDI_Stb. Ведущее устройство возбуждает (устанавливает) MDDI_Data0 до уровня логической единицы и MDDI_Stb до уровня логического нуля в течение такого длительного времени, которое должно потребоваться для задающих устройств, чтобы полностью разрешить их соответствующие выходные сигналы. Ведущее устройство обычно ожидает приблизительно 200 наносекунд после того, как выходные сигналы достигнут требуемых логических уровней (MDDI_Data0 достигнет достоверного уровня логической единицы и MDDI_Stb достигнет достоверного уровня логического нуля) перед выдачей импульсов на MDDI_Stb. Это предоставляет клиенту время подготовиться к приему высокоскоростных импульсов на MDDI_Stb. Клиент сначала обнаруживает импульс пробуждения, используя маломощный дифференциальный приемник, имеющий входное напряжение смещения +125 мВ.
После того как задающие устройства ведущего устройства разрешены и MDDI_Data0 доведено до уровня логической единицы, ведущее устройство начинает переключать MDDI_Stb в течение длительности 150 тактов MDDI_Stb, как можно видеть в точке E. Ведущее устройство возбуждает MDDI_Data0 до логического нулевого уровня в течение 50 тактов, как показано в точке F, и клиент начинает искать пакет "Заголовок под-кадра", после того как MDDI_Data0 находится в логическом нуле в течение 40 тактов MDDI_Stb. Ведущее устройство начинает передавать данные по прямой линии связи, посылая пакет "Заголовок под-кадра", как показано в точке G.
Пример этапов обработки для типичного инициированного клиентом пробуждения без состязаний проиллюстрирован на Фиг.68B, где события вновь помечены для удобства в иллюстрации, используя символы A, B, C, D, E, F, G, H и I. Как и прежде, процесс начинается в точке А, когда ведущее устройство посылает пакет «Завершение работы линии связи», чтобы сообщить клиенту, что линия связи будет переходить в состояние с потреблением малой мощности.
В точке B ведущее устройство переключает MDDI_Stb в течение приблизительно 64 тактов (или как требуется для конструкции системы), чтобы разрешить выполнение обработки клиентом, которая должна быть закончена до остановки переключения MDDI_Stb, что останавливает восстановленную синхронизацию в клиентском устройстве. Ведущее устройство также первоначально устанавливает MDDI_Data0 в уровень логического нуля и затем отключает выходной сигнал MDDI_Data0 в диапазоне от 16 до 48 тактов (обычно включая в себя задержку распространения отключения выходного сигнала) после кода CRC. Может быть необходимо переводить высокоскоростные приемники для MDDI_Data0 и MDDI_Stb в клиенте в состояние потребления малой мощности некоторое время спустя после 48 тактов после кода CRC и до следующего этапа (C).
Ведущее устройство входит в состояние бездействия с потреблением малой мощности в точке или этапе С посредством отключения задающих устройств MDDI_Data0 и MDDI_Stb и переводя контроллер ведущего устройства в состояние бездействия с потреблением малой мощности. Можно также устанавливать задающее устройство MDDI_Stb в уровень логического нуля (используя высокоимпедансную схему смещения) или продолжать переключать в течение состояния бездействия, как требуется. Клиент находится также в состоянии бездействия с уровнем потребления малой мощности.
После некоторого периода времени клиент начинает последовательность перезагрузки (рестарта) линии связи в точке D посредством разрешения приемника MDDI_Stb и также обеспечивая смещение в приемнике MDDI_Stb, чтобы гарантировать, что состояние принятой версии MDDI_Stb является уровнем логического нуля в клиенте, прежде чем ведущее устройство разрешит (разблокирует) свое задающее устройство MDDI_Stb. Для клиента требуется разрешить смещение немедленно перед разрешением приемника, чтобы гарантировать прием достоверного дифференциального сигнала и запретить ошибочные сигналы, как требуется. Клиент разрешает (разблокирует) задающее устройство MDDI_Data0, в то же время устанавливая на линии MDDI_Data0 логический уровень единицы. Допускается для MDDI_Data0 и MDDI_Stb быть разрешенными одновременно, если время для разрешения смещения и разрешения стандартного дифференциального приемника MDDI_Stb составляет менее 200 нс.
В пределах приблизительно 1 мс, точка E, ведущее устройство распознает импульс запроса на обслуживание от клиента, и ведущее устройство начинает последовательность перезагрузки (рестарта) линии связи посредством разрешения выходных сигналов задающего устройства MDDI_Data0 и MDDI_Stb. Ведущее устройство устанавливает MDDI_Data0 на уровень логической единицы и MDDI_Stb на уровень логического нуля до тех пор, пока потребуется для задающих устройств разрешить свои соответствующие выходные сигналы. Ведущее устройство обычно ожидает приблизительно 200 наносекунд после того, как эти выходные сигналы достигнут требуемых логических уровней, перед выдачей импульсов на MDDI_Stb. Это предоставляет клиенту время для подготовки к приему.
Когда задающие устройства ведущего устройства разрешены и MDDI_Data0 установлены до уровня логической единицы, ведущее устройство начинает выдачу импульсов на MDDI_Stb в течение длительности 150 тактов MDDI_Stb, как можно видеть в точке F. Когда клиент распознает первый импульс на MDDI_Stb, он отключает смещение в своем приемнике MDDI_Stb. Клиент продолжает возбуждать MDDI_Data0 до уровня логической единицы в течение 70 тактов MDDI_Stb и отключает свое задающее устройство MDDI_Data0 в точке G. Ведущее устройство продолжает возбуждать MDDI_Data0 до уровня логической единицы в течение длительности 80 дополнительных импульсов MDDI_Stb и в точке H устанавливает MDDI_Data0 в уровень логического нуля.
Как можно видеть в точках G и H, ведущее устройство устанавливает MDDI_Data0 в уровень логического нуля в течение 50 тактов, и клиент начинает искать пакет "Заголовок под-кадра" после того, как MDDI_Data0 равно логическому нулю в течение 40 тактов MDDI_Stb. После установления MDDI_Stb в течение длительности в 50 тактов ведущее устройство начинает передавать данные по прямой линии связи, посылая пакет "Заголовок под-кадра", как показано в точке I.
Пример этапов обработки для типичного инициированного ведущим устройством пробуждения с состязанием со стороны клиента, который является клиентом, который также хочет "пробудить" линию связи, проиллюстрирован на Фиг.68C. События вновь помечены для удобства иллюстрации, используя символы A, B, C, D, E, F, G, H и I. Как и прежде, процесс начинается в точке А, когда ведущее устройство посылает пакет «Завершение работы линии связи», чтобы сообщить клиенту, что линия связи будет переходить в состояние потребления малой мощности, переходит к этапу B, где MDDI_Stb переключается в течение приблизительно 64 тактов (или как требуется для конструкции системы), чтобы разрешить обработку, проводимую клиентом, которая должна быть завершена, и затем - к точке С, где ведущее устройство входит в состояние бездействия с малой мощностью потребления посредством отключения задающих устройств MDDI_Data0 и MDDI_Stb и переводя контроллер ведущего устройства в состояние бездействия с малой мощностью потребления. После некоторого периода времени ведущее устройство начинает последовательность рестарта линии связи в точке D, разрешая выходной сигнал задающего устройства MDDI_Data0 и MDDI_Stb, и начинает переключать MDDI_Stb в течение длительности 150 тактов MDDI_Stb, как можно видеть в точке E.
В течение до 70 тактов MDDI_Stb после точки E, здесь точка 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 показан во второй строке, каждый раз выровненный соответствующим образом (общая начальная точка). С течением времени, когда имеется изменение состояния, имеющего место на линии 4002 DATA (сигнал), то 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) над сигналами DATA и STB, чтобы сформировать синхросигнал (тактовый сигналл) 4006, который показан внизу временной диаграммы для относительного сравнения с требуемыми сигналами данными и стробирования. Пример схемы, используемой для формирования выходных сигналов DATA и STB или сигналов из входных данных в ведущем устройстве и затем восстановления или повторного захвата данных из сигналов DATA и STB в клиенте, иллюстрируется на Фиг.41.
Если имеется изменение состояния, встречающегося на DATA, то STB сохраняет свое предыдущее состояние. Однако STB переключается в противоположное состояние, если DATA не изменяется. Другими словами, между DATA и STB имеется тракт MDDI_Data0+/- и всегда один и только один переход на битовый такт. На приемном конце связи тактовый сигнал (сигнал CLK на Фиг.40) формируется посредством выполнения операции "ИСКЛЮЧАЮЩЕЕ ИЛИ" над DATA и STB. Использование кодирования данные-строб имеет преимущество перед обычными системами, которые используют данные и сигнал синхронизации, так как кодированные сигналы данные-строб являются приблизительно вдвое более терпимыми к задержке сдвига по сравнению с системами, использующими данные и сигнал синхронизации. Сдвиг во времени в MDDI_Stb+/- может быть вызван различиями в задержках на тракте через задающие устройства и приемники в ведущем устройстве и клиенте, а также различиями в задержках через соединения MDDI_Data0+/- и MDDI_Stb+/-. Количественный анализ тактирования, на которое воздействует сдвиг во времени, и другие недостатки в трактах MDDI_Data0+/- и MDDI_Stb+/- описаны более подробно ниже.
Для режимов Типа 2, Типа 3 и Типа 4 MDDI_Data0+/- и MDDI_Stb+/- работает тем же самым способом, как с Типом 1, где они имеют свойство наличия одного и только одного перехода на битовый такт. Другие сигналы MDDI_Data передают данные с идентичной скоростью передачи и фазой, что и MDDI_Data0. Восстановленная синхронизация в клиенте, созданная после операции ИСКЛЮЧАЮЩЕЕ ИЛИ для MDDI_Data0+/- и MDDI_Stb+/-, также используется, чтобы выполнять выборку MDDI_Data1+/- - MDDI_Data7+/-.
Примерная схема, используемая для формирования 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 линии (режим напряжения). Трехвходовая схема "ИСКЛЮЧАЮЩЕЕ НЕ - ИЛИ" (XNOR), схема или логический элемент 4112 подсоединена, чтобы принимать DATA и выходные сигналы обоих триггеров, и генерирует выходной сигнал, который обеспечивает входные данные для второго триггера, который, в свою очередь, формирует сигналы MDDI_Stb+, MDDI_Stb-. Для удобства логический элемент XNOR имеет кружок инверсии для указания того, что он на самом деле инвертирует выходной сигнал Q триггера, который формирует Строб.
В принимающей части 4120 на Фиг.41 сигналы MDDI_Data0+, MDDI_Data0- и MDDI_Stb+, MDDI_Stb- принимают каждым из двух дифференциальных приемников 4122 и 4124 линии, которые генерируют единственные выходные сигналы из дифференциальных сигналов. Выходные сигналы усилителей затем подают на каждый из входов двухвходовых элементов XOR, схемы или логического элемента 4126, который формирует тактовый сигнал. Этот тактовый сигнал используется для переключения каждой из двух схем 4128 и 4130 D-триггера, которые принимают задержанную версию сигнала DATA через элемент 4132 задержки, один из которых (4128) формирует значения '0' данных и другой (4130) - значения '1' данных. Синхросигнал также имеет независимый выход из логического элемента XOR. Так как информация синхронизации распределена между линиями DATA и STB, никакие переходы сигнала между состояниями не происходят быстрее, чем за половину такта синхросигнала. Так как синхронизация воспроизводится с использованием обработки сигналов DATA и STB посредством "ИСКЛЮЧАЮЩЕЕ ИЛИ", система по существу допускает приблизительно двойную величину сдвига во времени между входными данными и сигналом синхронизации по сравнению с ситуацией, когда синхросигнал посылают непосредственно по единственной выделенной линии данных.
Элементы задержки в схеме восстановления данных, проиллюстрированной на Фиг.41 или Фиг.57, являются более стимулирующими для реализации, чем синхронная схема сбора данных, обычно используемая для обычной коммуникационной линии связи данные-синхронизация, но кодирование данные-строб позволяет приблизительно удвоить скорость передачи данных без необходимости использовать калибровку сдвига задержки во времени. Критические задержки распространения элементов схемы восстановления данных являются простыми для достижения, так как они являются относительными по отношению к другим задержкам в той же схеме. Это может легко быть реализовано в заказной схеме, например, с простыми логическими элементами в схеме клавишной панели ввода/вывода, так как необходимо только создать задержки некоторых трактов, которые являются большими, чем задержки на другом тракте.
Пары MDDI_Data0, сигналы MDDI_Stb+ и MDDI_Stb- используются в дифференциальном режиме, чтобы максимизировать устойчивость к негативному воздействию шума. Каждая дифференциальная пара завершается параллельным терминатором (оконечной нагрузкой) с волновым сопротивлением кабеля или проводника, используемого для передачи сигналов. Обычно все параллельные терминаторы постоянно находятся в клиентском устройстве. Они находятся около дифференциального приемника для трафика прямой линии связи (данных, посылаемых от ведущего устройства к клиенту), но они находятся на задающем конце кабеля или других проводников или передающих элементов для обратного трафика (данных, посылаемых от клиента на ведущее устройство). Для обратного трафика сигнал выдается клиентом, отражается приемником с высоким полным сопротивлением (импедансом) в ведущем устройстве и завершается в клиенте. Как описано в настоящем описании, обратные данные или данные по обратной линии связи могут быть переданы или посланы на скоростях передачи данных, больших, чем обратная величина "времени передачи сигнала в прямом и обратном направлениях" в кабеле. Проводники или сигналы MDDI_Stb+ и MDDI_Stb- выдаются только ведущим устройством.
Примерная конфигурация элементов, используемых для реализации задающих устройств, приемников и терминаторов (оконечных нагрузок) для передачи сигналов в качестве части предлагаемого MDDI иллюстрируется на Фиг.42A. Этот примерный интерфейс использует чувствительность к малому напряжению, равному здесь 200 мВ, с размахом колебаний мощности меньше 1 В и потреблением малой мощности. Задающее устройство каждой сигнальной пары имеет дифференциальный токовый выход. При приеме пакетов MDDI, пары MDDI_Data и MDDI_Stb использует обычный дифференциальный приемник с дифференциальным порогом напряжения ноль вольт. В состоянии бездействия выходы этого задающего устройства запрещены, и резисторы параллельной оконечной нагрузки "понижают" дифференциальное напряжение на каждой сигнальной паре до нуля вольт. Во время состояния бездействия специальный приемник на паре MDDI_Data0 имеет пороговое напряжение положительного смещения дифференциального входа, равное 125 мВ, которое заставляет приемник линии в состоянии бездействия интерпретировать невозбуждаемую сигнальную пару как уровень логического нуля.
Дифференциальное напряжение дифференциальной пары определяется как разность напряжения на положительном (+) сигнале минус напряжение на отрицательном (-) сигнале. Названия сигналов дифференциальной пары оканчиваются или "+" или "-", что указывает положительный или отрицательный сигнал пары соответственно. Ток на выходе задающего устройства дифференциальной пары определяется как ток, вытекающий из положительного (+) выхода. Ток, проходящий через отрицательный (-) выход дифференциального задающего устройства, всегда равен по величине, но противоположен по направлению по сравнению с током, протекающим через положительный (+) вывод того же самого дифференциального задающего устройства.
Схематическая примерная диаграмма задающего устройства в режиме дифференциальных токов, используемого для осуществления некоторых вариантов осуществления изобретения, иллюстрируется на Фиг.42B. Переключаемый дифференциальный выходной каскад "направляет" источник тока или к положительному, или отрицательному выходному сигналу задающего устройства. Источник напряжения 0,35 В сохраняет выходное напряжение, измеренное относительно земли всегда равным 0,35 В или больше.
Иногда ведущее устройство или клиент могут одновременно возбуждать дифференциальную пару до уровня логической единицы или уровня логического нуля, чтобы гарантировать действительный логический уровень на паре, когда направление потока данных изменяется (от ведущего устройства к клиенту или от клиента к ведущему устройству). Диапазон выходного напряжения и технические требования выходного сигнала все еще удовлетворяются при одновременно возбуждаемых выходных сигналах, которые возбуждаются до одного и того же логического уровня. В некоторых системах может быть необходимо возбуждать малый ток в дифференциальную пару с оконечной нагрузкой, чтобы создать малое напряжение смещения в некоторые моменты времени в течение состояния бездействия и когда линия связи пробуждается из состояния бездействия. В этих ситуациях разрешенные цепи смещения со смещением по току возбуждают уровни тока, называемые как: IESD-and-Rx - входной ток внутреннего диода защиты от электростатического разряда (ESD-диода) дифференциального приемника с типичным значением IESD-and-Rx ≤ 1 мкА; ITx-Hi-Z- дифференциальный выходной сигнал задающего устройства в высокоимпедансном состоянии с типичным значением ITx-Hi-z ≤ 1 мкА; и Iexternal-ESD - утечка через внешние ESD диоды защиты с типичным значением Iexternal-ESD ≤ 3 мкА.
Каждый из этих токов утечки иллюстрируется на Фиг.47. Схемы для "повышения" напряжения и "понижения" напряжения должны достичь минимального дифференциального напряжения в состояниях утечки в наихудших случаях, описанных выше, когда все они происходят одновременно. Полная утечка тока равна ≤ 4 мкА для внутреннего режима без внешних ESD-диодов защиты и ≤ 10 мкА для внешнего режима с внешней ESD-защитой (от электростатического разряда).
Электрические параметры и характеристики дифференциальных задающих устройств линии и приемников линии описаны для одного примерного варианта осуществления в Таблицах IXa-IXd. Функционально задающее устройство передает логический уровень на входе непосредственно к положительному выводу и инверсный сигнал входа - к отрицательному выводу. Задержка от входа до выходов является хорошо согласованной с дифференциальной линией, которая возбуждается дифференциально. В большинстве реализаций размах напряжения на выходах является меньшим, чем размах на входе, чтобы минимизировать потребляемую мощность и электромагнитные излучения. В одном варианте осуществления имеется минимальный размах напряжения приблизительно 0,5 В. Однако могут использоваться другие значения, как может быть известно специалистам в данной области техники, и изобретатели ожидают и меньшее значение в некоторых вариантах осуществления в зависимости от конструктивных ограничений.
Дифференциальные приемники линии имеют ту же характеристику, что и быстродействующий компаратор напряжения. На Фиг.41 входом без кружка обозначен положительный вход, и входом с кружком - отрицательный вход. Выход является логической единицей, если: (Vinput+)-(Vinput-) больше нуля. Другим способом описания этого является дифференциальный усилитель с очень большим (фактически бесконечным) коэффициентом усиления с выходным сигналом, срезанным на уровнях напряжения логических 0 и 1.
Сдвиг задержки во времени между различными парами должен быть минимизирован, чтобы использовать систему дифференциальной передачи на самой высокой потенциальной скорости.
| Таблица IXa Электрические спецификации передатчика ведущего устройства |
||||
| Параметр | Описание | Мин | Макс | Ед. |
| Voutput-Range | Разрешенный диапазон выходного напряжения задающего устройства ведущего устройства по отношению к земле ведущего устройства | 0,35 | 1,6 | В |
| IOD+ | Ток высокого уровня дифференциального выходного сигнала задающего устройства, соответствующий уровню логической единицы (во время возбуждения линии передачи с оконечной нагрузкой) | 2,5 | 4,5 | мА |
| IOD- | Ток низкого уровня дифференциального выходного сигнала задающего устройства, соответствующий уровню логического нуля (во время возбуждения линии передачи с оконечной нагрузкой) | -4,5 | -2,5 | мА |
| tRise-Fall | Время нарастания и спада (между 20% и 80% амплитуды) выходного сигнала задающего устройства, измеренное в дифференциальном режиме | 425 | Примечание 1 | пс |
| tсдвиг-пара | Сдвиг между положительным и отрицательным выходными сигналами одной и той же дифференциальной пары (сдвиг во времени внутри пары) | 125 | пс | |
| tдифференциальный-сдвиг | Пиковый сдвиг во времени задержки между одной дифференциальной парой и любой другой дифференциальной парой | См. выше | пс | |
| tдрожание-ведущее устройство | Максимальное дрожание генератора синхросигнала в ведущем устройстве, которое используется для генерации выходных сигналов MDDI_Data и MDDI_Stb | 0,21*tBIT | ||
| tA | Дрожание, битовая граница до центральной отметки | 0 | tB -283 | пс |
| tВ-TPO-DRVR | Дрожание, битовая граница до минимального уровня выходного сигнала | 0 | См. выше | пс |
| Примечание 1: Максимальное время нарастания и спада является наименьшим значением из или 30% интервала для передачи одного бита по одной дифференциальной паре или 100 нс | ||||
| Таблица IXb Электрические спецификации передатчика клиента |
||||
| Параметр | Описание | Мин | Макс | Ед. |
| Voutput-Range Внешн | Разрешенный диапазон выходного напряжения клиента по отношению к земле клиента (внешний режим) | 0 | 1,25 | В |
| Voutput-Range Внутр | Разрешенный диапазон выходного напряжения клиента по отношению к земле клиента (внутренний режим) | 0.11 | 1,6 | В |
| IOD+ | Ток высокого уровня дифференциального выходного сигнала задающего устройства, соответствующий уровню логической единицы (во время возбуждения эквивалентных "повышающих напряжение" и "понижающих напряжение" схем, которые существуют в ведущем устройстве и клиенте) | 2,5 | 4,5 | мА |
| IOD- | Ток низкого уровня дифференциального выходного сигнала задающего устройства, соответствующий уровню логического нуля (во время возбуждения эквивалентных "повышающих напряжение" и "понижающих напряжение" схем, которые существуют в ведущем устройстве и клиенте) | -4,5 | -2,5 | мА |
| Zout-клиент | Минимальный дифференциальный выходной импеданс задающих устройств MDDI_Data в клиентском устройстве (Примечание 2) | 1,0 | кОм | |
| tRise-Fall | Время нарастания и спада (между 20% и 80% амплитуды) выходного сигнала задающего устройства, измеренное в дифференциальном режиме | 425 | Примечание 1 | пс |
| tсдвиг-пара | Сдвиг во времени между положительным и отрицательным выходными сигналами одной и той же дифференциальной пары (сдвиг внутри пары) | 125 | пс | |
| tдифференциальный-сдвиг | Пиковый сдвиг во времени задержки между одной дифференциальной парой и любой другой дифференциальной парой | См. выше | пс | |
| tA | Дрожание, битовая граница до центральной отметки | 0 | tB -283 | пс |
| tВ-TP4-DRVR | Дрожание, битовая граница до минимального уровня выходного сигнала | 0 | См. выше | пс |
| Примечание 2: Минимальный импеданс задающего устройства клиента задается, так как импеданс задающего устройства является параллельным к дифференциальному резистору 100 Ом оконечной нагрузки (терминатору) в ТР4 (контрольной точке 4), что воздействует на общий импеданс оконечной нагрузки кабеля, когда клиент посылает данные на ведущее устройство. | ||||
| Таблица IXc Электрические спецификации приемника клиента |
|||||
| Параметр | Описание | Мин | Тип. | Макс | Единица |
| VIT+ | Высокое пороговое дифференциальное входное напряжение приемника. Выше этого дифференциального напряжения входной сигнал интерпретируется как уровень логической единицы. | 0 | 50 | мВ | |
| VIT- | Низкое пороговое дифференциальное входное напряжение приемника. Ниже этого дифференциального напряжения входной сигнал интерпретируется как уровень логического нуля. | -50 | 0 | мВ | |
| VIT+ | Высокое пороговое дифференциальное входное напряжение приемника (смещение для пробуждения из режима бездействия (спячки)). Выше этого дифференциального напряжения входной сигнал интерпретируется как уровень логической единицы. | 125 | 175 | мВ | |
| VIT- | Низкое пороговое дифференциальное входное напряжение приемника (смещение для пробуждения из режима бездействия (спячки)). Ниже этого дифференциального напряжения входной сигнал интерпретируется как уровень логического нуля. | 75 | 125 | мВ | |
| VInput-Range | Разрешенный диапазон входного напряжения приемника по отношению к земле клиента | 0 | 1,65 | В | |
| Rterm | Значение параллельного сопротивления оконечной нагрузки | 98 | 100 | 102 | Ом |
| Iin | Входной ток утечки | -10 | 10 | мкА | |
| Cpad | Емкость контактной площадки относительно земли клиента (Примечание 1) | 5 | пФ | ||
| Cdiff | Емкость между двумя сигналами дифференциальной пары (Примечание 1) | 1 | пФ | ||
| tskew-pair-INT | Сдвиг во времени, вызванный дифференциальным приемником между положительным и отрицательным входами дифференциального приемника одной и той же дифференциальной пары (сдвиг внутри пары). Внутренний режим | 250 | пс | ||
| tskew-pair-EXT | Сдвиг во времени внутри пары, внешний режим | 50 | пс | ||
| tдифференциальный-сдвиг | Пиковый сдвиг во времени задержки между одной дифференциальной парой и любой другой дифференциальной парой | См. выше | пс | ||
| tA | Дрожание, битовая граница до центральной отметки | tB -38,5 | пс | ||
| tВ-TP4-RCVR-INT | Дрожание, битовая граница до минимального уровня входного сигнала. (Внутренний режим) | 0 | См. выше | пс | |
| tВ-TP4-RCVR-EXT | Дрожание, битовая граница до минимального уровня входного сигнала. (Внешний режим) | 0 | См. выше | пс | |
| Таблица IXd Электрические спецификации приемника ведущего устройства |
|||||
| Параметр | Описание | Мин | Тип. | Макс | Единица |
| VIT+ | Высокое пороговое дифференциальное входное напряжение приемника (не смещенное). Выше этого дифференциального напряжения входной сигнал интерпретируется как уровень логической единицы. | 0 | 50 | мВ | |
| VIT- | Низкое пороговое дифференциальное входное напряжение приемника (не смещенное). Ниже этого дифференциального напряжения входной сигнал интерпретируется как уровень логического нуля. | -50 | 0 | мВ | |
| VIT+ | Высокое пороговое дифференциальное входное напряжение приемника (смещение для пробуждения из режима бездействия (спячки)). Выше этого дифференциального напряжения входной сигнал интерпретируется как уровень логической единицы. | 125 | 175 | мВ | |
| VIT- | Низкое пороговое дифференциальное входное напряжение приемника (смещение для пробуждения из режима бездействия (спячки)). Ниже этого дифференциального напряжения входной сигнал интерпретируется как уровень логического нуля. | 75 | 125 | мВ | |
| VInput-Range | Разрешенный диапазон входного напряжения приемника по отношению к земле ведущего устройства | 0 | 1,65 | В | |
| Iin | Входной ток утечки (исключая смещение в режиме бездействия) | -10 | 10 | мкА | |
| Cpad | Емкость контактной площадки относительно земли ведущего устройства | 5 | пФ | ||
| Cdiff | Емкость между двумя сигналами дифференциальной пары | 1 | пФ | ||
| tskew-pair | Сдвиг во времени, вызванный дифференциальным приемником между положительным и отрицательным входами дифференциального приемника одной и той же дифференциальной пары (сдвиг внутри пары). | 250 | пс | ||
| tskew-pair-EXT | Сдвиг внутри пары, внешний режим | 50 | пс | ||
| tA | Дрожание, битовая граница до центральной отметки | tB -38,5 | пс | ||
| tВ-TP0-RCVR-INT | Дрожание, битовая граница до минимального уровня входного сигнала. (Внутренний режим) | См. выше | пс | ||
| tВ-TP0-RCVR-EXT | Дрожание, битовая граница до минимального уровня входного сигнала. (Внешний режим) | См. выше | пс | ||
На Фиг.42 контроллер 4202 ведущего устройства и клиент или контроллер 4204 дисплея показаны передающими пакеты по коммуникационной линии 4206 связи. Контроллер ведущего устройства использует последовательность из трех задающих устройств 4210, 4212 и 4214, чтобы принять сигналы DATA и STB ведущего устройства, которые должны быть переданы, а также принять сигналы данных клиента, которые должны быть переданы, в то время как клиент использует три задающих устройства 4230, 4232 и 4234. Задающее устройство, ответственное за прохождение DATA (4212) ведущего устройства, использует входной сигнал разрешения, чтобы разрешить активацию коммуникационной линии связи, обычно только когда требуется передача от ведущего устройства к клиенту. Так как сигнал STB формируется как часть передачи данных, никакой дополнительный сигнал разрешения не используется для этого задающего устройства (4212). Входы каждого из приемников клиентских сигналов DATA и STB (4232, 4230) имеют импедансы (полные сопротивления) оконечных нагрузок или резисторов 4218 и 4220, соответственно включенных в них. Задающее устройство 4234 в контроллере клиента используется для подготовки сигналов данных, передаваемых от клиента на ведущее устройство, где задающее устройство 4214 на входной стороне обрабатывает данные.
Специальные приемники (задающие устройства) 4216 и 4236 соединены или подсоединены к линиям DATA и генерируют или используют смещение напряжения, равное 125 мВ, описанное выше, как часть управления состоянием бездействия, описанного в другом месте описания. Смещения заставляют приемники линии в бездействии интерпретировать невозбужденные сигнальные пары как уровень логического нуля.
Вышеупомянутые задающие устройства и полные сопротивления могут быть сформированы как дискретные компоненты или как часть схемного модуля, или специализированные интегральные схемы (ASIC), которые выступают как более эффективные по стоимости решения кодера или декодера.
Может быть легко замечено, что мощность передается к клиентскому устройству, или дисплею, от ведущего устройства, используя сигналы, помеченные HOST_Pwr и HOST_Gnd по паре проводников. Часть HOST_Gnd сигнала действует как опорная земля и обратный тракт или сигнал питания для клиентского устройства. Сигнал HOST_Pwr действует как источник питания клиентского устройства, которое возбуждается ведущим устройством. В примерной конфигурации для приложений с малой потребляемой мощностью клиентскому устройству разрешается потреблять 500 мА. Сигнал HOST_Pwr может быть обеспечен от портативных источников питания, таких как, но не ограничиваясь ими, батареи или пакет батарей литий - ионного типа, постоянно находящихся в ведущем устройстве, и может изменяться в диапазоне от 3,2 до 4,3 В по отношению к HOST_Gnd.
VII. Временные характеристики
A. Краткий обзор
Этапы и уровни сигналов, используемые для входа в состояние бездействия (спячки) (никакая услуга не запрашивается, не желается или не требуется) и обеспечения услуги для клиента от ведущего устройства, инициированной или ведущим устройством, или клиентом, иллюстрируются на Фиг. 43A, 43B и 43C соответственно. На Фиг. 43A, 43B и 43C первая часть иллюстрируемых сигналов показывает пакет «Завершение работы линии связи», передаваемый от ведущего устройства, и линия данных затем устанавливается в состояние логического нуля, используя цепь смещения с высоким полным сопротивлением. Никакие данные не передаются клиентом или ведущим устройством, которые имеют свое задающее устройство отключенным (блокированным). Последовательность стробирующих импульсов для MDDI_Stb сигнальной линии можно видеть внизу, так как MDDI_Stb является активным в течение пакета "Завершение работы линии связи". Как только этот пакет завершается, логический уровень изменяется на нулевой, так как ведущее устройство возбуждает цепь смещения и логику в ноль. Это представляет собой завершение передачи предыдущего сигнала или услуги от ведущего устройства, могло произойти в любое время в прошлом и включено для того, чтобы показать прекращение предшествующей услуги и состояния сигналов до начала услуги. Если требуется, например, сигнал может быть послан, только чтобы установить коммуникационную линию связи в надлежащее состояние без 'известного' предшествующего обмена, предпринятого этим ведущим устройством.
Как показано на Фиг.43A и описано выше для пакета "Завершение работы линии связи", в состоянии бездействия с малым потреблением мощности задающее устройство MDDI_Data0 заблокировано в состоянии с высоким импедансом, начиная после 16-го до 48-го тактов или импульсов MDDI_Stb после последнего бита поля All Zeros (Все нули) в пакете «Завершение работы линии связи». Для линий связи Типа-2, Типа-3 или Типа-4 сигналы MDDI_Data1 - MDDI_DataPwr7 также переводятся в состояние с высоким импедансом в то же самое время, когда задающее устройство MDDI_Data0 запрещается (блокируется). Как описано в определении поля All Zeros, MDDI_Stb переключается в течение 64 циклов (или как требуется для конструкции системы) после младшего значащего бита поля CRC пакета "Завершение работы линии связи", чтобы разрешить клиенту завершить обработку, которая должна быть завершена, и облегчает упорядоченное завершение работы в контроллере клиента. Один такт является переходом от низкого к высокому с последующим переходом от высокого к низкому или переходом от высокого к низкому с последующим переходом от низкого к высокому. После того как поле All Zeros послано, задающие устройства MDDI_Stb и NMDI_DATA0 в ведущем устройстве запрещаются и ведущее устройство входит в состояние бездействия с малым потреблением мощности. После истечения некоторого периода времени ведущее устройство начинает последовательность перезагрузки (рестарта) линии связи, как показано на Фиг. 43B и 43C, посредством разрешения линий или выходных сигналов задающих устройств MDDI_Data0 и MDDI_Stb, и начинает переключать MDDI_Stb как часть инициированного или в ведущем устройстве или клиенте запроса пробуждения.
Как показано на Фиг.43B, после того как пройдет некоторое время и при запрещенных выходных сигналах от задающих устройств для MDDI_Data0 и MDDI_Stb, ведущее устройство инициализирует услугу или пробуждение из состояния бездействия посредством разрешения своего задающего устройства MDDI_Stb в течение времени, обозначенного tstb-data-enbl, в течение которого линия возбуждается до уровня логического нуля, до тех пор пока она не будет полностью разрешена и затем разрешая свое задающее устройство MDDI_Data0. Ведущее устройство сохраняет MDDI_Stb на уровне логического нуля после того, как MDDI_Data0 достигает высокого уровня или уровня логической единицы, что происходит в течение периода времени, обозначенного tclient-startup. В конце периода времени tclient-startup ведущее устройство затем переключает сигнал или линию MDDI_Stb. Ведущее устройство устанавливает линию MDDI_Data0 в высокий уровень, уровень логической единицы, в то время как клиент не возбуждает MDDI_Data0 в течение периода времени, обозначенного trestart-high, и затем устанавливает MDDI_Data0 в низкий уровень, или в уровень логического нуля, в течение периода времени, обозначенного trestart-low. После этого трафик прямой линии связи сначала начинается с пакета "Заголовок под-кадра" и затем передаются пакеты трафика прямой линии связи. Сигнал MDDI_Stb является активным в течение периода времени trestart-low и последующего пакета "Заголовок под-кадра".
Как показано на Фиг.43C, после истечения некоторого периода времени при запрещенном выходном сигнале от задающих устройств для MDDI_Data0 и MDDI_Stb клиент инициализирует запрос на обслуживание или пробуждение из состояния бездействия посредством разрешения смещения в приемнике или выходном сигнале MDDI_Stb в течение времени, обозначенного tstb-data-enbl, как описано выше, прежде чем ведущее устройство разрешит свое задающее устройство MDDI_Stb. Клиент затем разрешает свое задающее устройство MDDI_Data0 в течение времени, обозначенного thost-detect, в течение которого линия установлена в уровень логического нуля, перед тем как ведущее устройство MDDI_Stb начинает переключение.
Некоторый период времени проходит или может быть необходим, прежде чем ведущее устройство обнаруживает запрос в течение thost-detect, после которого ведущее устройство отвечает посредством удержания MDDI_Stb на уровне логического нуля в течение периода, обозначенного tstb-startup, прежде чем ведущее устройство начинает переключать MDDI_Stb с помощью последовательности запуска линии связи посредством возбуждения MDDI_Data0 до уровня логической единицы или высокого уровня в течение периода времени trestart-high. Когда клиент распознает первый импульс на MDDI_Stb, он запрещает смещение в своем приемнике MDDI_Stb. Клиент продолжает возбуждать MDDI_Data0 до уровня логической единицы в течение периода, обозначенного tclient-detect, до тех пор пока он не обнаруживает ведущее устройство, возбуждающее линию. В этот момент клиент снимает запрос и запрещает свое задающее устройство MDDI_Data0, так чтобы выходной сигнал от клиента вновь рос до уровня логического нуля, и ведущее устройство является возбуждающим MDDI_Data0. Как и прежде, ведущее устройство продолжает возбуждать MDDI_Data0 до уровня логической единицы в течение периода времени trestart-high и затем устанавливает MDDI_Data0 линию связи в низкий уровень в течение периода времени trestart-low, после которого трафик прямой линии связи начинается сначала с пакета "Заголовок под-кадра". Сигнал MDDI_Stb является активным в течение периода времени trestart-low и последующего пакета "Заголовок под-кадра".
Таблица X показывает характерные моменты времени или периоды обработки в течение различных периодов, описанных выше, и соотношения для примерных минимальной и максимальной скоростей передачи данных, где:
tбит = 1/(Скорость передачи данных линии связи), где Скорость передачи данных линии связи - скорость передачи информации в битах одной пары данных.
| Таблица X | |||||
| Параметр | Описание | Мин | Тип. | Макс | Ед. измерения |
| 1/tBIT-min-perf | Скорость передачи данных для устройства минимального быстродействия | 0,001 | 1,1 | Мбит/с | |
| 1/tBIT-max-perf | Максимальный диапазон скорости передачи данных линии связи для устройства, внешний | 0,001 | 400 | Мбит/с | |
| 1/tBIT-max-perf | Максимальный диапазон скорости передачи данных линии связи для устройства, внутренний | 0,001 | 550 | Мбит/с | |
| Скорость передачи данных обратной линии связи | 0,0005 | 50 | Мбит/с | ||
| tBIT | Период одного бита данных прямой линии связи, внешний режим | 2,5 | 106 | нс | |
| tBIT | Период одного бита данных прямой линии связи, внутренний режим | 1,8 | 106 | нс | |
| trestart-high | Длительность высокого уровня импульса рестарта линии связи ведущего устройства | 140 | 150 | 160 | Тактов Stb |
| trestart-low | Длительность низкого уровня импульса рестарта линии связи ведущего устройства | 50 | 50 | 50 | Тактов Stb |
| tstb-data-enabl | MDDI_Stb полностью разрешен до MDDI_Data0 разрешенной последовательности рестарта линии связи | 0 | мкс | ||
| tclient-startup | Время для ведущего устройства для удержания MDDI_Stb на уровне логического нуля после достижения MDDI_Data0 высокого логического уровня | 200 | нс | ||
| thost-detect | Время от высокого уровня MDDI_Data0 до переключения MDDI_Stb | 0 | 1000 | мкс | |
| tclient-detect | Время для клиента для обнаружения MDDI_Data0 на устройстве выполнения при высоком логическом уровне | 60 | 80 | Тактов Stb | |
| tstb-startup | Время для ведущего устройства для удержания MDDI_Stb на уровне логического нуля, прежде чем ведущее устройство начинает переключать MDDI_Stb | 200 | нс | ||
Специалистам в данной области техники очевидно, что функции отдельных элементов, проиллюстрированных на Фиг. 41 и 42, являются хорошо известными, и функция элементов на Фиг.42A подтверждается временной диаграммой на Фиг. 43A, 43B и 43C. Подробности относительно последовательностей оконечных нагрузок и резисторов для состояния бездействия, которые иллюстрируются на Фиг.42A, были опущены на Фиг.41, так как эта информация не является необходимой для описания того, как выполнять кодирование данные-строб и восстанавливать синхронизацию из него.
B. Временные диаграммы данные-строб прямой линии связи
Характеристики переключения для передачи данных по прямой линии связи от задающего устройства, возбуждающего выходной сигнал, показаны в Таблице XI-1. Таблица XI представляет табличную форму требуемых минимальных и максимальных значений, которые должны иметь место в зависимости от типичных времен для некоторых переходов сигнала. Например, типичный отрезок времени для перехода от начала до конца значения данных (выход '0' или '1'), переход от Data0 к Data0, названный ttdd-(host-output) (выходной сигнал ведущего устройства), равен ttbit, в то время как минимальное время приблизительно равно ttbit-0,5 нс, а максимальное - приблизительно ttbit+0,5 нс. Относительный промежуток между переходами на Data0, других линий данных (DataX) и линий строба (Stb) проиллюстрирован на Фиг.44, где показываются переходы Data0 в Строб, Строба в Строб, Строба в Data0, Data0 в не-Data0, не-Data0 в не-Data0, не-Data0 в Строб и Строба в не-Data0, которые обозначены как ttds-(host-output), ttss-(host-output), ttsd-(host-output), ttddx-(host-output), ttdxdx-(host-output), ttdxs-(host-output) и ttsdx-(host-output) соответственно.
| Таблица XI-1 | |||||
| Параметр | Описание | Мин | Тип. | Макс | Единица |
| ttdd-(host-output) | Переход Data0 в Data0 | ttbit-0,5 | ttbit | ttbit+0,5 | нс |
| ttds-(host-output) | Переход Data0 в Строб | ttbit-0,8 | ttbit | ttbit+0,8 | нс |
| ttss-(host-output) | Переход Строб в Строб | ttbit-0,5 | ttbit | ttbit+0,5 | нс |
| ttsd-(host-output) | Переход Строб в Data0 | ttbit-0,8 | ttbit | ttbit+0,8 | нс |
| ttddx-(host-output) | Переход Data0 в не-Data0 | ttbit | нс | ||
| ttdxdx-(host-output) | Переход не-Data0 в не-Data0 | ttbit-0,5 | ttbit | ttbit+0,5 | нс |
| ttdxs-(host-output) | Переход не-Data0 в Строб | ttbit | нс | ||
| ttsdx-(host-output) | Переход Строб в не-Data0 | ttbit | нс | ||
Типовые требования к временной диаграмме MDDI для входного сигнала приемника клиента для одних и тех же сигналов, передающих данные по прямой линии связи, показаны в Таблице XI-2. Так как описываются одни и те же сигналы, но с задержкой во времени, не требуется нового чертежа, чтобы проиллюстрировать характеристики сигнала или значение соответствующих обозначений, как понятно специалистам в данной области техники.
| Таблица XI-2 | |||||
| Параметр | Описание | Мин | Тип. | Макс | Ед. |
| ttdd-(client-input) | Переход Data0 в Data0 | ttbit-1,0 | ttbit | ttbit+1,0 | нс |
| ttds-(client -input) | Переход Data0 в Строб | ttbit-1,5 | ttbit | ttbit+1,5 | нс |
| ttss-(client -input) | Переход Строб в Строб | ttbit-1,0 | ttbit | ttbit+1,0 | нс |
| ttsd-(client -input) | Переход Строб в Data0 | ttbit-1,5 | ttbit | ttbit+1,5 | нс |
| ttddx-(client-output) | Переход Data0 в не-Data0 | ttbit | нс | ||
| ttdxdx-(client-output) | Переход не-Data0 в не-Data0 | ttbit | нс | ||
| ttdxs-(host-output) | Переход не-Data0 в Строб | ttbit | нс | ||
| ttsdx-(host-output) | Переход Строб в не-Data0 | ttbit | нс | ||
Фиг. 45 и 46 иллюстрируют наличие задержки в ответе, которая может происходить, когда ведущее устройство отключает или разрешает задающее устройство ведущего устройства соответственно. В случае, когда ведущее устройство направляет некоторые пакеты, например пакет "Инкапсуляция обратной линии связи» или пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях», ведущее устройство отключает задающее устройство линии после того, как требуемые пакеты отправлены, такие пакеты как «Параметр CRC», «Выравнивание строба» и «Все Нули», проиллюстрированные на Фиг.45 в качестве переданных. Однако, как показано на Фиг.45, состояние линии не обязательно мгновенно переключается от '0' к требуемому высокому значению, хотя это является потенциально достижимым при наличии некоторых схем или элементов схемы управления, но требует периода времени, названного периодом "задержки запрещения задающего устройства ведущего устройства" для выдачи ответа. В то время как это может происходить фактически немедленно, так что этот период времени составляет 0 наносекунд (нс), он может с легкостью быть растянут в течение несколько более длинного периода времени с 10 нс в качестве требуемого максимальной длительности периода времени, что имеет место в течение периодов пакетов «Защитный интервал времени 1» или «Изменение на противоположное 1».
Из Фиг.46 можно видеть изменение уровня сигнала, которое происходит, когда задающее устройство ведущего устройства разрешено (разблокировано) для передачи пакета, такого как пакет "Инкапсуляция обратной линии связи» или пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях". Здесь после периодов пакетов "Защитный интервал времени 2" или "Изменение на противоположное 2" задающее устройство ведущего устройства разблокируется и начинают устанавливать уровень, здесь '0', причем к этому значению приближаются или достигают в течение времени, названного периодом "Задержка разрешения задающего устройства ведущего устройства", которое имеет место в течение периода повторного разрешения задающего устройства до первого посылаемого пакета.
Аналогичный процесс имеет место для задающих устройств и передач сигнала для клиентского устройства, здесь - дисплея. Общие рекомендации для длительности этих периодов и их соответствующих соотношений иллюстрируются в таблице XII ниже.
| Таблица XII | |||
| Описание | Мин | Макс | Единица |
| Задержка запрещения задающего устройства ведущего устройства | 0 | 10 | нс |
| Задержка разрешения задающего устройства ведущего устройства | 0 | 2,0 | нс |
| Задержка запрещения задающего устройства дисплея | 0 | 10 | нс |
| Задержка разрешения задающего устройства дисплея | 0 | 2,0 | нс |
C. Времена разрешения и запрещения выходного сигнала ведущего устройства и клиента
Характеристики переключения и относительные временные соотношения для времени разрешения и запрещения выходного сигнала ведущего устройства и клиента или операции, относящиеся к структуре и периоду пакета «Инкапсуляция обратной линии связи», иллюстрируются на Фиг.48. Функции или операции выходного сигнала задающего устройство помечены как: thost-enable для времени разрешения выходного сигнала ведущего устройства, thost-disable для времени запрещения выходного сигнала ведущего устройства, tclient-enable для времени разрешения выходного сигнала клиента и tclient-disable для времени запрещения выходного сигнала клиента. Типичные времена для переходов некоторых сигналов описаны ниже. Минимальный период для этих операций может быть равен нулю наносекунд, с типичным или максимальным значениями, определенными исходя из конструкции системы, использующей интерфейс, возможно порядка 8 наносекунд или больше.
Общие рекомендации для длительности этих периодов (времена разрешения/запрещения ведущего устройства и клиента) и их соответствующие соотношения иллюстрируются ниже в Таблице XIII.
| Таблица XIII | |||||
| Параметр | Описание | Мин | Тип. | Макс | Ед. |
| thost-enable | Время разрешения выходного сигнала ведущего устройства | 0 | 24*tBIT | нс | |
| thost-disable | Время запрещения выходного сигнала ведущего устройства, общая длительность поля Изменение на противоположное 1 | 0 | 24*tBIT | нс | |
| tclient-enable | Время разрешения выходного сигнала клиента, общая длительность поля "Изменение на противоположное 1" | 0 | 24*tBIT | нс | |
| tclient-disable | Время запрещения выходного сигнала клиента, измеренное от конца последнего бита поля "Изменение на противоположное 2" | 0 | 24*tBIT | нс | |
VIII. Реализация управления линией связи (работа контроллера линии связи)
A. Процессор пакета конечного автомата
Пакеты, передаваемые по линии связи MDDI, отправляются очень быстро, обычно со скоростью передачи порядка 300 Мбит/с или более, например 400 Мбит/с, хотя при необходимости более низкие скорости, конечно, являются допустимыми. Этот тип шины или линии связи для передачи является слишком большим для того, чтобы управлять в настоящее время коммерчески (экономически) доступными микропроцессорами общего назначения или подобными. Поэтому практическая реализация для выполнения этого типа передачи сигнала должна использовать программируемый конечный автомат, чтобы анализировать входной поток пакетов, чтобы сформировать пакеты, которые передаются или перенаправляются для соответствующей аудиовизуальной подсистемы, для которой они предназначены. Такие устройства хорошо известны и используют схемы, обычно специализированные для ограниченного количества операций, функций или состояний, чтобы достичь требуемой высокой скорости или очень высокоскоростного выполнения операции.
Универсальные (общего назначения) контроллеры, процессоры или обрабатывающие элементы могут использоваться так, чтобы более подходящим образом выполнять действия над или манипулировать некоторой информацией, такой как управление или состояние пакетов, которые требуют более низкой скорости. Когда такие пакеты (управления, состояния или другие заранее определенные пакеты) принимаются, рекомендуется, чтобы конечный автомат передавал их через буфер данных или аналогичный обрабатывающий элемент на процессор общего назначения, так чтобы на пакеты можно было воздействовать для обеспечения требуемого результата (эффекта), в то время как аудио и визуальные пакеты передаются их соответствующему адресату для выполнения действий. Если в будущем микропроцессоры или другие универсальные контроллеры, процессоры или обрабатывающие элементы будут произведены, чтобы достичь возможностей обработки более высоких скоростей передачи данных, то состояния или конечный автомат, описанные ниже, могут также быть осуществлены, используя программное управление в отношении таких устройств, обычно такое как программы, сохраненные на запоминающих элементах или средствах.
Функция процессора общего назначения может быть реализована в некоторых вариантах осуществления, используя преимущество мощности обработки или избыточные такты, доступные для микропроцессоров (центральных процессоров) в компьютерных приложениях или контроллерах, процессорах, цифровых сигнальных процессорах (ЦСП, DSP), специализированных схемах или специализированных интегральных схемах (ASIC), имеющихся в беспроводных устройствах, аналогичным образом тому, как некоторые модемы или графические процессоры используют мощность обработки центральных процессоров, имеющихся в компьютерах, чтобы выполнять некоторые функции и уменьшить сложность и затраты аппаратного обеспечения. Однако такое совместное использование или применение такта может негативно воздействовать на быстродействие обработки, синхронизацию или всю работу таких элементов, так что во многих применениях для такой общей обработки предпочтительными являются специализированные схемы или элементы.
Для того чтобы данные изображения, которые должны быть просмотрены на дисплее (микродисплее), или для надежного приема всех пакетов, посланных ведущим устройством, обработка сигналов клиента является синхронизированной с тактированием канала прямой линии связи. То есть сигналы, достигающие клиента и схем клиента, должны быть по существу синхронизированы во времени для того, чтобы произошла надлежащая обработка сигналов. Укрупненная диаграмма состояний, достигаемая сигналом, для одного варианта осуществления представлена на иллюстрации согласно Фиг.49. На Фиг.49 возможные "состояния" синхронизации прямой линии связи для конечного автомата 4900 показаны разделенными на категории, такие как одно ASYNC FRAMES STATE 4904 (состояние асинхронных кадров), два ACQUIRING SYNC STATES 4902 и 4906 (состояния захвата синхронизации) и три IN-SYNC STATES 4908, 4910 и 4912 (состояния в синхронизме).
Как показано начальным этапом или состоянием 4902, дисплей или клиент, такой как устройство представления, начинает работу в предварительно выбранном состоянии "нет синхронизации" и производит поиск уникального слова в первом пакете «Заголовок под-кадра», который обнаружен. Следует отметить, что это состояние без синхронизации представляет установку (настройку) минимального обмена или установку (настройку) "перехода на аварийный режим", в котором выбирается интерфейс Типа 1. Когда уникальное слово найдено во время поиска, клиент сохраняет поле длины под-кадра. Не проводится никакой проверки битов кода CRC для обработки в отношении этого первого кадра или до тех пор, пока не будет получена синхронизация. Если длина этого под-кадра равна нулю, то обработка состояния синхронизации соответственно переходит к состоянию 4904, отмеченному здесь как состояние "асинхронные кадры", которое указывает, что синхронизация еще не была достигнута. Этот этап в обработке помечен как встретившееся условие cond 3, или состояние 3, на Фиг.49. В противном случае, если длина кадра больше нуля, то обработка состояния синхронизации переходит к состоянию 4906, где состояние интерфейса установлено как "найден один кадр синхронизации". Этот этап обработки помечен как встретившееся условие cond 5, или состояние 5, на Фиг.49. Кроме того, если конечный автомат видит пакет заголовка кадра и хорошее определение кода CRC для длины кадра большей нуля обработка переходит к состоянию "найден один кадр синхронизации". Это помечено как встретившееся условие cond 6, или состояние 6, на Фиг.49.
В каждой ситуации, в которой система находится в состоянии, отличном от "нет синхронизации", если обнаружен пакет с хорошим результатом кода CRC, то состояние интерфейса изменяется в состояние 4908 "в синхронизме". Этот этап обработки помечен как встретившееся условие cond 1, или состояние 1, на Фиг.49. С другой стороны, если CRC в каком-либо пакете является некорректным, то обработка состояния синхронизации переходит или возвращается к состоянию 4902 интерфейса "NO SYNC FRAME" (нет кадра синхронизации). Эта часть обработки помечена на диаграмме состояний Фиг.49 как встретившееся условие cond 2, или состояние 2.
B. Захват времени для синхронизации
Интерфейс может быть сконфигурирован так, чтобы разместить (включить) некоторое количество "ошибок синхронизации" перед принятием решения, что синхронизация потеряна и возвратом в состояние "NO SYNC FRAME". Согласно Фиг.49, как только конечный автомат достиг состояния "IN-SYNC STATE" и никакие ошибки не найдены, это означает непрерывное получение результата cond 1, и остается в состоянии "IN-SYNC". Однако, как только обнаружен один результат cond 2, обработка изменяет состояние в состояние 4910 "one-sync-error" (одна ошибка синхронизации). В этот момент если обработка приводит к обнаружению другого результата cond 1, тогда конечный автомат возвращается к состоянию "in-sync" (в синхронизме), иначе он встречает другой результат cond 2 и переходит в состояние 4912 "TWO-SYNC-ERRORS" (две ошибки синхронизации). Снова, если имеет место cond 1, обработка возвращает конечный автомат в состояние "IN-SYNC". Иначе, при встрече другого состояния cond 2 конечный автомат возвращается в состояние "no-sync" (нет синхронизации). Также понятно, что если интерфейс должен встретить пакет «Завершение работы линии связи", то это вынудит линию связи завершить передачи данных и вернуться к состоянию "no-sync frame" (нет кадра синхронизации), в котором не имеется ничего, с чем необходимо синхронизироваться, что помечено как встречающееся условие cond 4, или состояние 4, на диаграмме состояний согласно Фиг.49.
Понятно, что возможны повторяющиеся "ложные копии" уникального слова, которые могут появляться в некотором фиксированном местоположении в пределах под-кадра. В этой ситуации очень маловероятно, что конечный автомат будет синхронизироваться с под-кадром, так как CRC по пакету «Заголовок под-кадра» должен также быть достоверным при обработке, для того чтобы обработка MDDI перешла в состояние "IN-SYNC" (в синхронизме).
Длина под-кадра в пакете «Заголовок под-кадра» может быть установлена равной нулю для указания того, что ведущее устройство будет передавать только один под-кадр, прежде чем работа линии связи будет завершена, и MDDI будет переведен или конфигурирован в неактивное состояние бездействия. В этом случае клиент должен немедленно принять пакеты по прямой линии связи после обнаружения пакета "Заголовок под-кадра", так как только единственный под-кадр послан перед переходом линии связи в состояние бездействия. При нормальных или типичных операциях длина под-кадра ненулевая, и клиент только обрабатывает пакеты прямой линии связи, в то время как интерфейс находится в тех состояниях, которые все вместе показаны как состояния "IN-SYNC" на Фиг.49.
Клиентское устройство во внешнем режиме может быть подсоединено к ведущему устройству, в то время как ведущее устройство уже передает последовательность данных по прямой линии связи. В этой ситуации клиент должен синхронизироваться к ведущему устройству. Время, требуемое для клиента, чтобы синхронизироваться к сигналу прямой линии связи, является переменным в зависимости от размера под-кадра и скорости передачи данных по прямой линии связи. Вероятность обнаружения "ложной копии" уникального слова в качестве части случайных, или более случайных, данных в прямой линии связи является большей, когда размер под-кадра является большим. В то же время способность восстановления после ложного обнаружения ниже, и время, необходимое для выполнения этого, является большим, когда скорость передачи данных по прямой линии связи является меньшей.
Для одного или более вариантов осуществления рекомендуется или понимается, что ведущее устройство MDDI должно выполнить некоторые дополнительные шаги, чтобы гарантировать, что обратная линия связи MDDI является устойчивой, прежде чем оно останавливает передачу по прямой линии связи для перехода к режиму потребления малой мощности или чтобы полностью завершить работу линии связи.
Одна из проблем, которая может иметь место, заключается в том, что, если ведущее устройство использует некорректное измерение значения времени передачи сигнала в прямом и обратном направлениях, это может вызвать сбой всей впоследствии принятой передачи данных по обратной линии связи от клиента, даже если прямая линия связи кажется "очень хорошей". Это может случиться, если ведущее устройство пытается посылать пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях", когда клиент не находится в синхронизме с прямой линией связи или из-за критического изменения окружающей температуры, которое вызывает соответствующее большое изменение в задержке распространения дифференциальных задающих устройств и приемников, что воздействует на задержку прохождения сигнала в прямом и обратном направлениях. Неустойчивый контакт кабеля или соединителя может также заставить клиента временно терять синхронизацию и затем восстанавливать синхронизацию, причем в течение этого времени он может пропустить прием пакета «Измерение задержки прохождения сигнала в прямом и обратном направлениях". Последующие пакеты обратной линии связи не смогут быть декодированы ведущим устройством должным образом.
Другой тип проблемы, которая может произойти, заключается в случае, когда клиент временно теряет синхронизацию, а ведущее устройство посылает пакет «Завершение работы линии связи" прежде, чем клиент способен восстановить синхронизацию. Ведущее устройство будет в бездействии, в то время как клиент неспособен войти в состояние бездействия, так как он не принял пакет «Завершение работы линии связи» и не имеет сигнала синхронизации, так как линия связи находится в бездействии.
Одна методика или вариант осуществления, используемый для преодоления таких проблем, заключается в том, чтобы иметь ведущее устройство, которое гарантирует, что клиент находится в синхронизме с прямой линией связи перед переходом линии связи в состояние бездействия. Если ведущее устройство MDDI неспособно обеспечить это или не имеет такой возможности, так что, когда оно "теряет" питание, или линия связи внезапно прерывается, или возникает сбой из-за разделения, разрыва или разъединения кабеля, проводника или соединителя, происходящего во время работы, то ведущее устройство должно сначала попытаться обеспечить, чтобы клиент находился в синхронизации перед началом процесса измерения времени передачи сигнала в прямом и обратном направлениях или посылки пакета «Инкапсуляция обратной линии связи".
Ведущее устройство может наблюдать поле CRC Error Count (количество ошибок кода CRC) в пакете «Запрос клиента и состояния», посланном клиентом, чтобы определить целостность прямой линии связи. Этот пакет запрашивается ведущим устройством от клиента. Однако в случае серьезного отказа или сбоя связи этот запрос будет наиболее вероятно оставлен без ответа, так как клиент не будет способен должным образом декодировать этот пакет или, возможно, даже принять его в целом. Запрос на получение CRC Error Count, используя посылку пакета «Запрос клиента и состояния», посланного в пакете "Инкапсуляция обратной линии связи»", действует в качестве первой проверки целостности, своего рода первой линией защиты. Кроме того, ведущее устройство может посылать пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях", чтобы подтвердить, является или нет действительным предположение относительно клиента, утратившего синхронизацию. Если клиент не отвечает на пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях", ведущее устройство заключает, что клиент находится вне синхронизма, и может затем начинать процесс возврата в синхронизм.
Обычно рекомендуется, чтобы ведущее устройство непрерывно контролировало значение CRC Error Count в клиенте посредством периодической посылки пакета «Инкапсуляция обратной линии связи» клиенту с битом 1 поля "Флаги обратной линии связи", установленным в 1, для того чтобы требовать, чтобы клиент возвратил пакет «Запрос клиента и состояния» на ведущее устройство.
Как только ведущее устройство заключает, что клиент наиболее вероятно потерял синхронизацию с прямой линией связи, оно ожидает следующего заголовка под-кадра перед попыткой послать какие-либо пакеты, отличные от пакетов-заполнителей. Это делается для того, чтобы предоставить клиенту достаточно времени для обнаружения или поиска одного уникального слова, содержащегося в пакете «Заголовок под-кадра». После этого ведущее устройство может предположить, что клиент перевел себя в исходное состояние, так как он не смог найти уникальное слово в правильном местоположении. В этот момент ведущее устройство может отслеживать пакет "Заголовок под-кадра" с пакетом «Измерение задержки прохождения сигнала в прямом и обратном направлениях". Если клиент все еще не отвечает корректно на пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях", ведущее устройство может повторить процесс повторной синхронизации. Корректным ответом является тот, в котором клиент посылает заданную последовательность назад ведущему устройству в поле "Период измерения" пакета «Измерение задержки прохождения сигнала в прямом и обратном направлениях». Если эта последовательность не принята, то попытки принимать данные обратной линии связи в пакете "Инкапсуляция обратной линии связи» будут терпеть неудачу. Длительный отказ такого характера может указывать на некоторую другую системную ошибку, которая должна быть решена некоторым другим способом, и не является частью синхронизации линии связи в этот момент.
Однако, если после успешного пакета «Измерение задержки прохождения сигнала в прямом и обратном направлениях" ведущее устройство все еще видит поврежденные данные или отсутствие ответа в пакетах «Инкапсуляция обратной линии связи", рекомендуется, чтобы ведущее устройство подтвердило, что выборка данных обратной линии связи является корректной, заново посылая пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях". Если это является неудачным после ряда попыток, рекомендуется в одном варианте осуществления, чтобы ведущее устройство уменьшило скорость передачи данных обратной линии связи, увеличивая значение делителя скорости передачи обратной линии связи.
Рекомендуется, чтобы ведущее устройство выполнило Обнаружение неисправности линии связи и, возможно, этапы повторной синхронизации линии связи, описанные выше, перед переводом линии связи MDDI в состояние бездействия. Это будет обычно гарантировать, что пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях", выполненный, когда для линии связи позже выполнен рестарт, является успешным. Если ведущее устройство не имеет причин подозревать отказ линии связи и клиентом сообщены корректный ответ на пакет "Инкапсуляция обратной линии связи» и нулевое значение количество ошибок кода CRC прямой линии связи, ведущее устройство может предполагать, что все работает или функционирует соответствующим или подходящим образом (нет отказа в линии связи, например), и продолжить процесс снижения потребления мощности/бездействия.
Другой способ, согласно которому ведущее устройство может проверять синхронизацию, предназначен для ведущего устройства, чтобы оно послало пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях" и подтвердило надлежащий ответ от клиента. Если надлежащий ответ принят ведущим устройством, разумно предположить, что клиент успешно интерпретирует пакеты прямой линии связи.
C. Инициализация
Как описано выше, во время "запуска" ведущее устройство конфигурирует прямую линию связи так, чтобы она работала на или ниже требуемой минимальной, или желательной, скорости передачи данных, равной 1 Мбит/с, и конфигурирует длину под-кадра и скорость передачи медиакадров соответствующим образом для данного приложения. То есть и прямая и обратная линии связи начинают работу, используя интерфейс Типа 1. Эти параметры обычно предполагается использовать только временно, в то время как ведущее устройство определяет возможность или требуемую конфигурацию для дисплея клиента (или клиентского устройства другого типа). Ведущее устройство посылает или передает пакет "Заголовок под-кадра" по прямой линии связи с последующим пакетом «Инкапсуляция обратной линии связи», который имеет бит '0' "Запроса флагов", установленный равным значению единицы (1), чтобы запросить, чтобы дисплей или клиент ответил пакетом «Возможности клиента». Как только дисплей захватывает синхронизацию на (или с) прямой линии(ей) связи, он посылает пакет "Возможности клиента" и пакет «Запрос клиента и состояния" по обратной линии связи или каналу.
Ведущее устройство проверяет содержание пакета «Возможности клиента», чтобы определить, как реконфигурировать линию связи для оптимального или требуемого уровня эффективности. Ведущее устройство проверяет поля Protocol Version (Версия протокола) и Minimum Protocol Version (Минимальная версия протокола), чтобы подтвердить, что ведущее устройство и клиент используют версии протокола, которые являются совместимыми друг с другом. Версии протокола обычно сохраняются в качестве первых двух параметров пакета «Возможности клиента» так, чтобы совместимость могла быть определена, даже когда другие элементы протокола не могут быть совместимы или полностью поняты как совместимые.
Во внутреннем режиме ведущее устройство может знать параметры клиента заранее без необходимости в приеме пакета "Возможности клиента". Линия связи может запускаться на любой скорости передачи данных, при которой ведущее устройство и клиент могут работать оба. Во многих вариантах осуществления проектировщик системы наиболее вероятно выберет возможность запускать линию связи при максимальной достижимой скорости передачи данных, чтобы ускорить передачу данных, однако этого не требуется и во многих ситуациях может не использоваться. Для работы во внутреннем режиме частота стробирующих импульсов, используемых во время рестарта линии связи из последовательности бездействия, будет обычно совместима с этой требуемой скоростью передачи.
D. Обработка кода CRC
Для всех типов пакета конечный автомат обработки пакетов гарантирует, что блок проверки кода CRC управляется соответствующим или должным образом. Это также приводит к увеличению значения счетчика ошибок кода CRC, когда сравнение кода CRC приводит к обнаружению одной или более ошибок, и он сбрасывает счетчик кода CRC в исходное состояние в начале каждого обрабатываемого под-кадра.
E. Альтернативная проверка потери синхронизации
В то время как вышеописанные последовательности этапов или состояний работают так, чтобы обеспечивать более высокие скорости передачи данных или скорость работы, заявители обнаружили, что альтернативная компоновка или изменение в условиях, которые клиент использует для объявления, что имеется потеря синхронизации с ведущим устройством, могут быть эффективно использованы, чтобы достичь еще более высоких скоростей передачи данных или производительности. Новый предлагаемый вариант осуществления имеет ту же самую основную структуру, но с измененными условиями изменения состояний. Дополнительно реализуется новый счетчик, чтобы помочь в осуществлении проверки синхронизации под-кадра. Эти этапы и условия представлены со ссылками на Фиг.63, на которой иллюстрируется ряд состояний и условий, используемых в установлении операций способа или конечного автомата. Только части "ACQUIRING-SYNC STATES" (состояния захвата синхронизации) и "IN-SYNC STATES" (систояния в синхронизме) показаны для ясности. Кроме того, так как результирующие состояния по существу являются такими же, как непосредственно сам конечный автомат, они используют ту же самую нумерацию. Однако условия для изменения состояний (и работа конечного автомата) несколько изменяются, так чтобы все были перенумерованы для ясности между двумя фигурами (1, 2, 3, 4, 5 и 6 по сравнению с 61, 62, 63, 64 и 65) для удобства при идентификации различий. Так как состояние ASYNC FRAME (асинхронный кадр) не рассматривается в этом описании, одно состояние (4904) и одно состояние (6) больше не используются на чертеже.
На Фиг.63 система или клиент (для дисплея или представления) начинает работу, когда конечный автомат 5000 находится в предварительно выбранном состоянии 4902 "нет синхронизации", как на Фиг.49. Первое изменение состояния для изменения состояний из состояния 4902 "нет синхронизации" происходит в условии 64, которое является обнаружением шаблона синхронизации. Предполагая, что CRC заголовка под-кадра также передается в этом пакете (выполняется условие 61), состояние конечного автомата обработки пакета может быть изменено к состоянию 4908 "in-sync" (в синхронизме). Ошибка синхронизации, условие 62, заставит конечный автомат перейти в состояние 4910, и второе появление для состоянияе 4912. Однако было обнаружено, что любая ошибка кода CRC пакета MDDI заставит конечный автомат перейти из состояния 4908 (в синхронизме) в состояние 4910 с одной ошибкой синхронизации. Другая ошибка при получении кода CRC любого пакета MDDI вызовет переход в состояние 4912 с двумя ошибками синхронизации. Пакет, декодированный с корректным значением CRC, вынудит конечный автомат возвратиться к состоянию 4908 "in-sync" (в синхронизме).
Было изменено то, что необходимо использовать значение CRC или обнаружение для "каждого" пакета. То есть необходимо, чтобы конечный автомат просматривал значение CRC для каждого пакета, чтобы обнаружить потерю синхронизации вместо только наблюдения пакетов "Заголовок под-кадра". В этой конфигурации или процессе потеря синхронизации не обнаруживается с использованием уникального слова и только значения CRC заголовка под-кадра.
Это новая реализация интерфейса позволяет линии связи MDDI распознавать отказы синхронизации намного быстрее и поэтому также восстанавливаться из них более быстро.
Чтобы сделать эту систему более робастной (устойчивой), клиент должен также добавить или использовать счетчик под-кадров. Клиент затем проверяет присутствие уникального слова в момент, когда он, как ожидается, прибудет или произойдет в сигнале. Если уникальное слово не найдено в нужный момент времени, клиент может распознавать, что произошел отказ синхронизации, намного быстрее, чем если бы он был вынужден ждать несколько интервалов времени или периодов (здесь трех) пакета, которые были большие, чем длина под-кадра. Если проверка на уникальное слово указывает, что оно не присутствует, другими словами, что синхронизация некорректна, то клиент может немедленно объявлять потерю синхронизации линии связи и перейти в состояние no-sync (нет синхронизации). Процесс проверки наличия надлежащего уникального слова добавляет условие 65 (cond 65) к конечному автомату, свидетельствующее, что уникальное слово является некорректным. Если пакет под-кадра, как ожидается, будет принят на клиенте и не совпадает, клиент может немедленно перейти в состояние 4902 "нет синхронизации", экономя дополнительное время, ожидая множества ошибок синхронизации (условие 62), обычно встречающихся при переходе через состояния 4910 и 4912.
Это изменение использует дополнительный счетчик или функцию подсчета в ядре клиента для подсчета длины под-кадра. В одном варианте осуществления используется функция обратного счета, и передача любого пакета, который в настоящее время обрабатывался, прерывается, чтобы проверить уникальное слово под-кадра, если значение счетчика обнулилось. Альтернативно, счетчик может подсчитывать с увеличением значения счета, при этом это значение сравнивается с требуемым максимальным или конкретным требуемым значением в тот момент, когда текущий пакет проверяется. Этот процесс предотвращает клиента от декодирования пакетов, которые некорректно приняты в клиенте с необычно большими значениями длин пакетов. Если счетчик длины под-кадра должен прервать некоторый другой пакет, который декодируется, может быть определена потеря синхронизации, так как никакой пакет не должен пересекать границу под-кадров.
IX. Обработка пакета
Для каждого типа пакета, описанного выше, который принимает конечный автомат, он предпринимает конкретный этап обработки или последовательность этапов, чтобы реализовать работу интерфейса. Пакеты прямой линии связи обычно обрабатываются согласно примерной обработке, приведенной в Таблице XIV ниже.
| Таблица XIV | |
| Тип пакета | Ответ конечного автомата обработки пакета |
| Sub-Frame Header (Заголовок под-кадра, SH) | Подтверждает хороший пакет, захватывает поле длины под-кадра и посылает параметры пакета к процессору общего назначения. |
| Filler (Заполнитель, F) | Игнорирует данные |
| Video Stream (Поток видео, VS) | Интерпретирует "Дескриптор формата данных видео" и другие параметры, распаковывает упакованные пиксельные данные, когда необходимо, преобразует пиксели в карте цветов, если необходимо, и записывает пиксельные данные в соответствующие местоположения в битовой карте |
| Audio Stream (Поток Аудио, AS) | Посылает настройки частоты выборки аудио на генератор синхронизации выборок аудио, выделяет аудиовыборки заданного размера, распаковывает данные выборки аудио, когда необходимо, и маршрутизирует выборки аудио к соответствующему буферу FIFO выборок аудио |
| Color Map (Карта цвета, CM) | Считывает размер и параметры смещения карты цвета и записывает данные карты цвета в память карты цвета или местоположение хранения. |
| Reverse Link Encapsulation (Инкапсуляция обратной линии связи, REL) | Облегчает посылку пакетов в обратном направлении в соответствующее время. Флаги обратной линии связи проверяются и пакеты «Возможности Клиента» посылают, при необходимости. Пакеты «Запрос Клиента и Состояния» также посылают при необходимости. |
| Client Capability (Возможности клиента, СС) | Посылает этот тип пакета, когда запрошен ведущим устройством, с использованием поля "Флаги обратной линии связи" пакета «Инкапсуляция обратной линии связи». |
| Keyboard (Клавиатура, K) | Передает эти пакеты к и от процессору(а) общего назначения, который обменивается с устройством типа клавиатуры, если оно присутствует, и использует, как требуется. |
| Pointing Device (Устройство указания, PD) | Передает эти пакеты к и от процессору(а) общего назначения, который обменивается устройством типа устройства указания, если оно присутствует, и использует, как требуется. |
| Link Shutdown (Завершение работы линии связи, LS) | Записывает, что фактическая линия связи завершает работу и информирует процессор общего назначения. |
| Client Request and Status (CRS, Запрос клиента и состояния) | Посылает этот пакет в качестве первого пакета в пакете "Инкапсуляция обратной линии связи». |
| Bitmap Block Transfer (BPT, Поблочная передача битовой карты) | Интерпретирует параметры пакета, такие как "Дескриптор формата данных видео", определяет, какие пиксели передавать первыми, и передает пиксели в битовой карте требуемым образом. |
| Bitmap Area Fill (BAF, Заполнитель области битовой карты) | Интерпретирует параметры пакета, преобразует пиксели в карте цветов, если необходимо, и записывает пиксельные данные в соответствующие места в битовой карте. |
| Bitmap Pattern Fill (BPF, Заполнитель шаблона битовой карты) | Интерпретирует параметры пакета, распаковывает упакованные пиксельные данные, если необходимо, преобразует пиксели в карте цветов, если необходимо, и записывает пиксельные данные в соответствующие места в битовой карте. |
| Communication Link Channel (CLC, Канал коммуникационной линии связи) | Посылает эти данные непосредственно на процессор общего назначения. |
| Wake-up from hibernation (Пробуждение из бездействия) | Конечный автомат специального назначения управляет функциями низкого уровня по посылке и обнаружению последовательности пробуждения. |
| Perform Type Handoff, Выполнение переключения обслуживания типа интерфейса (PTH) | Может действовать на такие пакеты или непосредственно, или посредством передачи их на процессор общего назначения, также выдавая команду аппаратному обеспечению подчиниться изменению режима. |
X. Уменьшение скорости передачи данных по обратной линии связи
Заявители наблюдали, что некоторые параметры, используемые для контроллера линии связи ведущего устройства, могут быть откорректированы или конфигурированы некоторым образом, чтобы достичь максимальной или более оптимизированной (масштабированной) скорости передачи данных по обратной линии связи, которая является очень желательной. Например, в течение времени, используемого для передачи поля Reverse Data Packets ("Пакеты данных обратной линии связи») пакета «Инкапсуляция обратной линии связи», пара сигналов 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. Это означает, что скорость передачи данных обратной линии связи меньше, чем скорость передачи по прямой линии связи.
Должно быть отмечено, что фактическая длительность задержек прохождения сигнала через интерфейс может отличаться в зависимости от каждой конкретной системы "ведущее устройство - клиент" или используемых аппаратных средств. Хотя и не требуется, каждая система может обычно быть сделана так, чтобы работать лучше, используя пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях" для измерения фактической задержки в системе, так чтобы делитель скорости передачи обратной линии связи мог быть установлен равным оптимальному значению. Ведущее устройство может поддерживать или основную частоту выборки данных, что является более простым, но работает с более медленной скоростью, или усовершенствованную частоту выборки данных, которая является более сложной, но поддерживает более высокие скорости передачи данных обратной линии связи. Возможность клиента поддерживать оба способа рассматривается как одинаковая.
Задержка времени передачи в прямом и обратном направлениях измеряется, когда ведущее устройство посылает пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях" клиенту. Клиент отвечает на этот пакет посылкой последовательности единиц назад на ведущее устройство внутри, или в течение, предварительно выбранного окна измерения в этом пакете, называемом полем Measurement Period (Период измерения). Подробная временная диаграмма этого измерения была описана выше. Задержка времени передачи сигнала в прямом и обратном направлениях используется, чтобы определить скорость передачи, с которой данные обратной линии связи могут быть безопасно выбраны.
Измерение задержки времени передачи сигнала в прямом и обратном направлениях состоит из определения, обнаружения или подсчета числа интервалов синхронизации данных прямой линии связи, имеющих место между началом поля Measurement Period и началом периода времени, когда ответная последовательность 0xff, 0xff, 0x00 принимается назад в ведущем устройстве от клиента. Следует заметить, что возможно, что ответ от клиента может быть получен на малую часть периода синхронизации прямой линии связи прежде, чем значение счета измерения собирается увеличиться. Если это немодифицированное значение используется для вычисления делителя скорости передачи обратной линии связи, это может вызвать битовые ошибки на обратной линии связи из-за ненадежной выборки данных. Пример этой ситуации проиллюстрирован на Фиг.51, где сигналы, представляющие MDDI_Data в ведущем устройстве, MDDI_Stb в ведущем устройстве, синхронизацию данных прямой линии связи внутри ведущего устройства и подсчет задержки, затем записывают результирующий пиксель в местоположение пикселя адресата, проиллюстрированное в графической форме. На Фиг.51 ответная последовательность была принята от клиента на часть такта прямой линии связи прежде, чем подсчет задержки собирался увеличиться с 6 до 7. Если задержка принимается равной 6, то ведущее устройство будет производить выборку данных обратной линии связи только после битового перехода или возможно в середине битового перехода. Это может приводить к ошибочному осуществлению выборки в ведущем устройстве. По этой причине рекомендуется, чтобы измеренная задержка обычно была увеличена на единицу прежде, чем она используется для вычисления делителя скорости передачи обратной линии связи.
Делитель скорости передачи обратной линии связи есть количество тактов MDDI_Stb, которое ведущее устройство должно ждать перед осуществлением выборки данных обратной линии связи. Так как MDDI_Stb тактируется со скоростью передачи, которая является половинной скоростью передачи по прямой линии связи, скорректированное измерение задержки времени передачи сигнала в прямом и обратном направлениях должно быть разделено на 2 и затем округлено до следующего большего целого числа. Выраженное в виде формулы это отношение выглядит как:
Для данного примера, это равно:
Если измерение задержки прохождения сигнала в прямом и обратном направлениях, используемое в этом примере, было равно 7 в противоположность 6, то делитель скорости передачи обратной линии связи будет также равен 4.
Данные обратной линии связи выбираются ведущим устройством на нарастающем фронте сигнала синхронизации обратной линии связи. Имеется счетчик или аналогичная известная схема или устройства, присутствующие и в ведущем устройстве, и клиенте (дисплее), чтобы сформировать сигнал синхронизации обратной линии связи. Счетчики инициализированы так, чтобы первый нарастающий фронт сигнала синхронизации обратной линии связи произошел в начале первого бита в поле Reverse Link Packets (Пакеты обратной линии связи) пакета «Инкапсуляция обратной линии связи». Это проиллюстрировано для примера, данного ниже, на Фиг.52A. Значения счетчиков увеличиваются по каждому нарастающему фронту сигнала MDDI_Stb, и количество значений счета, встречающихся до тех пор, пока они не сбросятся в начальное состояние, установлено параметром Reverse Rate Divisor (делитель скорости передачи обратной линии связи) в пакете "Инкапсуляция обратной линии связи". Так как сигнал MDDI_Stb переключается с половинной частотой передачи прямой линии связи, то скорость передачи обратной линии связи равна половине скорости передачи прямой линии связи, деленной на делитель скорости передачи обратной линии связи. Например, если скорость передачи прямой линии связи равна 200 Мбит/с и делитель скорости передачи обратной линии связи равен 4, тогда скорость передачи данных обратной линии связи выражается как:
Пример, показывающий синхронизацию линий сигналов MDDI_Data0 и MDDI_Stb в пакете "Инкапсуляция обратной линии связи»", иллюстрируется на Фиг.52, где параметры пакета, используемые для иллюстрации, имеют значения:
| Длина пакета = 1024 (0х0400) | Длина поля "Изменение на противоположное 1" = 1 |
| Тип пакета = 65 (0х41) | Длина поля "Изменение на противоположное 2 = 1 |
| Флаги обратной линии связи = 0 | Делитель скорости передачи обратной линии связи = 2 |
| CRC Параметра = 0xdb43 | Все нули равны 0х00 |
Данные пакета между полями "Длина пакета" и "Параметр CRC":
0х00, 0х04, 0х41, 0х00, 0х02, 0х01, 0х01, 0х43, 0xdb, 0х00, …
Первым пакетом обратной линии связи, возвращенным от клиента, является пакет «Запрос клиента и состояния", имеющий Длину Пакета 7 и Тип пакета 70. Этот пакет начинается со значений 0×00, 0×46 … байтов и т.д. Однако только первый байт (0×07) представлен на Фиг.52. Этот первый пакет обратной линии связи является сдвинутым во времени почти на один такт обратной линии связи на чертеже, чтобы иллюстрировать фактическую задержку обратной линии связи. Идеальная форма сигнала с нулевой задержкой во времени передачи сигнала в прямом и обратном направлениях между ведущим устройством и клиентом показывается пунктирной линией.
Младший значащий байт поля "Параметр CRC" передается с предшествующим типом пакета, а затем поле "Все нули". Строб от ведущего устройства переключается из единицы в ноль и обратно в единицу, когда уровень данных от ведущего устройства изменяется, формируя более широкие импульсы. Когда данные переключаются в ноль, строб переключается с более высокой частотой, только изменение в данных на линии данных вызывает изменение около конца поля выравнивания. Строб переключается с более высокой частотой в течение оставшейся части чертежа из-за фиксированных уровней 0 или 1 сигнала данных в течение расширенных периодов времени и переходов, падающих на шаблон импульса (фронт).
Синхросигнал обратной линии связи для ведущего устройства остается в нуле до конца периода "Изменение на противоположное 1", когда синхросигнал начинается для размещения пакетов обратной линии связи. Стрелки в нижней части чертежа указывают, когда данные выбираются, как станет очевидно из оставшейся части описания. Первый байт передаваемого поля пакета (здесь 11000000) показан начинающимся после поля "Изменение на противоположное 1", и уровень сигнала в линии стабилизирован от запрещения (блокировки) задающего устройства ведущего устройства. Задержку в прохождении первого бита, и как видно для третьего бита, можно видеть в пунктирных линиях для сигнала данных (Data).
На Фиг.53 можно видеть типичные значения делителя скорости передачи обратной линии связи на основании скорости передачи данных прямой линии связи. Фактический делитель скорости передачи обратной линии связи определяется в результате измерения для линии связи передачи сигнала в прямом и обратном направлениях, чтобы гарантировать правильную работу обратной линии связи. Первая область 5302 соответствует области безопасной работы, вторая область 5304 соответствует области граничной эффективности, в то время как третья область 5306 указывает параметры настройки, при которых вряд ли будет обеспечено функционирование должным образом.
Измерение задержки во времени передачи сигнала в прямом и обратном направлениях и параметры установки делителя скорости передачи обратной линии связи являются теми же самыми, что и при работе с любым из параметров настройки "Тип Интерфейса" или на прямой, или на обратной линии связи, так как они выражаются и используются в количестве единиц фактических периодов синхронизации, вместо числа переданных или принятых битов.
Как правило, наибольший возможный делитель скорости передачи обратной линии связи равен половине числа битов, которые могут быть посланы в окне измерения в пакете "Измерение задержки прохождения сигнала в прямом и обратном направлениях», используя интерфейс Типа 1, или для этого примера:
Усовершенствованный способ выборки данных обратной линии связи может также использоваться в качестве альтернативы, что позволяет времени обратной передачи бита быть меньшим, чем время передачи сигнала в прямом и обратном направлениях. Для этой методики ведущее устройство не только измеряет время передачи сигнала в прямом и обратном направлениях, но и может также определять сдвиг во времени (фазу) ответа от клиента относительно "идеальной" границы бита клиента и линии связи с нулевой задержкой. Зная фазу ответа клиентского устройства, ведущее устройство может определять относительно безопасное время, чтобы произвести выборку битов данных обратной линии связи от клиента. Измерение задержки во времени передачи сигнала в прямом и обратном направлениях указывает ведущему устройству местоположение первого бита данных обратной линии связи относительно начала поля Reverse Data Packets ("Пакеты данных обратной линии связи»).
Один вариант осуществления примера усовершенствованной выборки данных обратной линии связи иллюстрируется в графической форме на Фиг.52B. Идеальный сигнал данных обратной линии связи с нулевым временем передачи сигнала в прямом и обратном направлениях показывается как пунктирная форма сигнала. Фактическое время прохождения сигнала в прямом и обратном направлениях между 3,5 и 4 тактами MDDI_Stb может наблюдаться как разность в задержке между сплошной линией формы сигнала и идеальной. Это есть та же самая задержка, которая может быть измерена, используя пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях", и может быть измеренным значением времени передачи сигнала в прямом и обратном направлениях, равным 7 временам передачи бита прямой линии связи. В этом варианте осуществления битами данных обратной линии связи являются 2 импульса MDDI_Stb длительностью, которая равна 4 временам передачи бита прямой линией связи, что соответствует делителю скорости передачи обратной линии связи, равному 2. Для усовершенствованной выборки данных обратной линии связи удобно использовать предварительно выбранный делитель скорости передачи обратной линии связи, равный 2, вместо его вычисления, как описано в настоящем описании. Это представляется по существу оптимальным выбором для усовершенствованной выборки данных обратной линии связи, так как идеальная точка выборки может быть легко определена, используя обычные измерения, описанные выше.
Идеальная точка выборки для данных обратной линии связи может быть легко вычислена, принимая оставшуюся часть полного времени передачи сигнала в прямом и обратном направлениях, разделенную на количество тактов прямой линии связи в расчете на бит обратной линии связи, или задержку времени передачи сигнала в прямом и обратном направлениях по модулю количества тактов прямой линии связи в расчете на бит обратной линии связи. Затем вычитают или 1, или 2, чтобы получить безопасную точку, удаленную от перехода данных. В этом примере 7 mod 4 = 3, затем 3-1 = 2 или 3-2 = 1. Безопасная точка выборки есть или 1, или 2 времени передачи бита прямой линии связи от фронта "идеальной" битовой границы для нулевого времени передачи сигнала в прямом и обратном направлениях. Чертеж показывает точку осуществления выборки в 2 периодах передачи бита прямой линии связи от идеальной границы бита, как обозначено последовательностью вертикальных стрелок внизу временной диаграммы. Первая точка осуществления выборки есть первая идеальная граница бита после измеренной задержки передачи сигнала в прямом и обратном направлениях плюс смещение для безопасного осуществления выборки. В этом примере измерение задержки прохождения сигнала в прямом и обратном направлениях равно 7, так что следующая идеальная граница бита есть время передачи 8-го бита, затем плюс или 1, или 2 для точки безопасной выборки, так что первый бит должен быть выбран или в 9, или 10 время передачи бита прямой линии связи после начала поля "Пакеты данных обратной линии связи»
XI. Изменение на противоположное и защитные интервалы времени
Поле "Изменение на противоположное 1" в пакете "Инкапсуляция обратной линии связи» позволяет одновременно разрешить время для запрещения (отключения) задающих устройств ведущего устройства и разрешения задающих устройств клиента. Поле «Защитный интервал времени 1» в пакете «Измерение задержки прохождения сигнала в прямом и обратном направлениях» разрешает перекрытие ведущего устройства и клиента, так задающие устройства клиента могут быть разрешены прежде, чем будут запрещены задающие устройства ведущего устройства интерфейса. Поле "Изменение на противоположное 2" в пакете "Инкапсуляция обратной линии связи» позволяет полностью передать данные в предыдущем поле от клиента прежде, чем задающие устройства ведущего устройства будут разрешены. Поле "Защитный интервал времени 2" обеспечивает значение времени или период, который позволяет задающим устройствам клиента и ведущего устройства возбуждаться одновременно до уровня логического нуля. Поля "Защитный интервал времени 1" и "Защитный интервал времени 2" обычно заполняются предварительно установленными или предварительно выбранными значениями в течение длительностей периодов времени, которые, как предполагается, не должны быть откорректированы. В зависимости от используемых аппаратных средств интерфейса эти значения могут быть разработаны, используя эмпирические данные, и настроены в некоторых случаях, чтобы улучшить работу.
"Изменение на противоположное 1"
Несколько факторов способствуют определению длины поля Turn-Around 1 (Изменение на противоположное 1), и ими являются скорость передачи данных прямой линии связи, максимальное время запрещения задающих устройств MDDI_Data в ведущем устройстве и время разрешения задающего устройства клиента, которое является обычно тем же самым, что и время запрещения ведущего устройства. Длина поля "Изменение на противоположное 1" выбрано равным 24*tBIT (Table XIII). Длина в количестве байтов прямой линии связи (ПЛС) поля Turn-Around 1 определяется, используя фактор "Тип Интерфейса", и вычисляется, используя соотношение:
где ФакторТипаИнтерфейса есть 1 для Типа 1, 2 для Типа 2, 4 для Типа 3 и 8 для Типа 4.
"Изменение на противоположное 2"
Факторами, которые определяют отрезок времени, обычно используемый для "Изменение на противоположное 2", являются задержка времени передачи сигнала в прямом и обратном направлениях коммуникационной линии связи, максимальное время запрещения задающих устройств MDDI_Data в клиенте и время разрешения задающего устройства в ведущем устройстве, которое задается как такое же, как время запрещения задающего устройства клиента. Максимальное время разрешения задающего устройства в ведущем устройстве и время запрещения задающего устройства клиента определяется в другом месте описания. Задержка времени передачи сигнала в прямом и обратном направлениях измеряется в единицах tBIT. Минимальная длина, указанная в количестве байтов прямой линии связи поля "Изменение на противоположное 2" вычисляется согласно соотношению:
Например, прямая линия связи Типа 3 с задержкой времени передачи сигнала в прямом и обратном направлениях, равной 10 тактам прямой линии связи, обычно использует задержку "Изменение на противоположное 2" порядка:
XII. Альтернативные временные соотношения обратной линии связи
В то время как использование синхронизации и защитных интервалов, описанных выше, предназначено для получения интерфейса с высокой скоростью передачи данных, заявители обнаружили способ для учета длин битов обратной линии связи, которые являются меньшими, чем время прохождения сигнала в прямом и обратном направлениях, посредством изменения обнаружения тактирования обратной линии связи.
Как представлено выше, предыдущий подход к распределению временных интервалов обратной линии связи выполнен так, что количество тактовых циклов подсчитывается от последнего бита "Защитного интервала времени 1" пакета тактирования обратной линии связи, до тех пор, пока первый бит не будет выбран по нарастающему фронту синхросигнала ввода/вывода. Он (они) является(ются) синхросигналом(ами) для момента времени ввода и вывода для MDDI. Вычисление делителя скорости передачи обратной линии связи тогда задается выражением:
Это выполняется при наличии ведущего устройства, подсчитывающего количество тактовых циклов, пока единица не будет выбрана, но при этом ведущее устройство производит выборку линии данных и по нарастающему и спадающему фронту во время пакета тактирования обратной линии связи. Это позволяет ведущему устройству выбирать наиболее полезную или даже оптимальную точку осуществления выборки в пределах бита обратной линии связи, чтобы гарантировать, что бит является устойчивым. То есть, чтобы найти наиболее полезный или оптимальный нарастающий фронт, чтобы производить выборку данных в течение пакетов инкапсуляции обратной линии связи обратного трафика. Оптимальная точка осуществления выборки зависит и от делителя обратной линии связи и от того, была ли первая единица обнаружена по нарастающему фронту или спадающему фронту. Новый способ тактирования позволяет ведущему устройству только искать первый фронт шаблона 0×FF 0×FF 0×00, посланного клиентом для тактирования обратной линии связи, чтобы определить, где произвести выборку в пакете «Инкапсуляция обратной линии связи».
Примеры прибывающего бита обратной линии связи и того, как этот бит будет искать различные делители скорости передачи обратной линии связи, иллюстрируются на Фиг.64, наряду с рядом тактовых циклов, которые имели место от последнего бита "Защитного интервала времени 1". На Фиг.64 можно видеть, что, если первый фронт имеет место между нарастающим фронтом и спадающим фронтом (помеченный как нарастающий/спадающий), оптимальная точка осуществления выборки для делителя скорости передачи обратной линии связи, равного единице, оптимальной точкой выборки является фронт тактового цикла, помеченный 'b', поскольку это есть единственный нарастающий фронт, встречающийся в пределах периода бита обратной линии связи. Для делителя скорости передачи обратной линии связи, равного двум, оптимальной точкой осуществления выборки является, вероятно, все еще передний фронт тактового цикла 'b', поскольку фронт 'c' такта ближе к битовой границе, чем 'b'. Для делителя скорости передачи обратной линии связи, равного четырем, оптимальной точкой осуществления выборки является, вероятно, фронт 'd' тактового цикла, поскольку он ближе к заднему фронту бита обратной линии связи, где значение, вероятно, было стабилизировано.
Возвращаясь Фиг.64, если, однако, первый фронт имеет место между спадающим и нарастающим фронтом (помеченный как спадающий/нарастающий), оптимальной точкой осуществления выборки для делителя скорости передачи обратной линии связи, равного одному, есть фронт 'a' выборки периода синхросигнала, поскольку имеется единственный нарастающий фронт в пределах периода времени передачи бита обратной линии связи. Для делителя скорости передачи обратной линии связи, равного двум, оптимальной точкой осуществления выборки является фронт 'b', и для делителя скорости передачи обратной линии связи, равного четырем, оптимальной точкой осуществления выборки является фронт 'c'.
Можно видеть, что, когда делители скорости передачи обратной линии связи становятся больше и больше, становится проще установить или выбрать оптимальную точку осуществления выборки, так как это должен быть нарастающий фронт, который является самым близким к середине.
Ведущее устройство может использовать эту методику, чтобы найти число нарастающих фронтов синхроимпульса, прежде чем нарастающий фронт данных пакетных данных синхронизации будет наблюдаться на линии данных. Затем может быть решено на основании того, имеет ли место фронт между нарастающим и спадающим фронтом или между спадающим и нарастающим фронтом и каков делитель скорости передачи обратной линии связи, сколько дополнительных тактовых циклов нужно добавить к счетчику количества, чтобы разумно гарантировать, что этот бит всегда выбирается настолько близко к середине, насколько возможно.
Как только ведущее устройство выбрало или определило число тактовых циклов, оно может "исследовать" различные делители скорости передачи обратной линии связи с клиентом, чтобы определить, будет ли конкретный делитель скорости передачи обратной линии связи работать хорошо. Ведущее устройство (и клиент) может начинать с делителя, равного одному, и проверять CRC пакета состояния обратной линии связи, принятого от клиента, чтобы определить, функционируют ли эти скорости передачи обратной линии связи подходящим образом для передачи данных. Если CRC дает ошибку, вероятно, имеется ошибка квантования (выборки) и ведущее устройство может увеличивать делитель скорости передачи обратной линии связи и пробовать заново запросить пакет состояния. Если второй запрошенный пакет был поврежден, делитель может быть увеличен снова и запрос сделан опять. Если этот пакет декодирован корректно, этот делитель скорости передачи обратной линии связи может использоваться для всех будущих пакетов обратной линии связи.
Этот способ является эффективным и полезным, так как тактирование обратной линии связи не должно измениться от начальной оценки тактирования прохождения сигнала в прямом и обратном направлениях. Если прямая линия связи устойчива, клиент должен продолжить декодировать пакеты прямой линии связи, даже если имеются отказы обратной линии связи. Конечно, это все еще является ответственностью ведущего устройства установить делитель обратной линии связи для линии связи, так как этот способ не гарантирует обратную линию связи с хорошими характеристиками. Кроме того, делитель будет зависеть прежде всего от качества синхронизации, которая используется, чтобы сгенерировать синхросигнал ввода/вывода. Если этот синхросигнал имеет существенную величину дрожания, имеется большая вероятность ошибки квантования. Эта вероятность ошибки увеличивается с количеством тактовых циклов в задержке прохождения сигнала в прямом и обратном направлениях.
Это выполнение, как представляется, работает лучше всего для данных обратной линии связи Типа 1, но может представлять проблемы для данных обратной линии связи Типа 2 - Тип 4 из-за сдвига во времени между линиями данных, возможно, являющегося слишком большим, чтобы запустить линию связи со скоростью передачи, которая работает лучше всего только для одной пары данных. Однако скорость передачи данных, вероятно, не должна быть снижена до предыдущего способа даже для Типов 2 - Тип 4 в течение работы. Этот способ может также работать наилучшим образом, если дублируется на каждой линии данных, чтобы выбрать идеальное или оптимальное местоположение выборки синхронизации. Если они происходят в один и тот же момент выборки для каждой пары данных, этот способ может продолжать работать. Если они происходят в различных периодах выборки, могут использоваться два различных подхода. Первый должен выбрать требуемое или более оптимизированное местоположение выборки для каждой точки данных, даже если оно не является одним и тем же для каждой пары данных. Ведущее устройство может затем восстановить поток данных после осуществления выборки всех битов из набора пар данных: два бита для Типа 2, четыре бита для Типа 3 и восемь битов для Типа 4. Другая возможность заключается в том, чтобы для ведущего устройства увеличить делитель скорости передачи обратной линии связи, так что биты данных для каждой пары данных могут быть выбраны по одному и тому же фронту синхроимпульса.
XIII. Эффекты задержки и сдвига во времени линии связи
Сдвиг задержки на прямой линии связи между парами MDDI_Data и MDDI_Stb может ограничивать максимальную возможную скорость передачи данных, если компенсация сдвига во времени задержки не используется. Разности в задержке, которые вызывают сдвиг во времени тактирования из-за логики контроллера, задающих устройств и приемников линии и кабелей и соединителей, описаны ниже.
A. Анализ временной диаграммы линии связи, ограниченный сдвигом во времени (MDDI Типа -1)
1. Пример задержки и сдвига во времени линии связи Типа 1
Типичная схема интерфейса, аналогичная показанной на Фиг.41, иллюстрируется на Фиг.57 для линии связи интерфейса Типа 1. На Фиг.57 примерные или типовые значения для задержки распространения и сдвига во времени показываются для каждого из нескольких этапов обработки или взаимодействия для интерфейса прямой линии связи MDDI Типа 1. Сдвиг в задержке между MDDI_Stb и MDDI_Data0 вызывает искажение рабочего цикла выходного синхросигнала, как показано на Фиг.58. В некоторых случаях это делает время установки для каскада RXFF очень малым. Данные на входе D-триггера триггерного каскада (RXFF) приемника, использующего триггеры 5728, 5732, немного изменяются после фронта синхроимпульса так, чтобы они могли быть надежно выбраны. Этот чертеж показывает две каскадированных линии 5732a и 5732b задержки, используемых для решения двух различных проблем с созданием этой временной зависимости. При фактической реализации они могут быть объединены в единственный элемент задержки.
Временная диаграмма данных, Stb, и восстановления синхронизации на линии связи Типа 1 для примерной обработки сигналов посредством интерфейса иллюстрируются на Фиг.58.
Полный сдвиг во времени задержки, который является существенным, обычно возникает или происходит из суммы сдвига во времени в следующих каскадах: триггер (TXFF) передатчика с триггерами 5704, 5706; задающее устройство (TXDRVR) передатчика с задающими устройствами 5708, 5710; кабель 5702; приемник (RXRCVR) линии в приемнике с приемниками 5722, 5724; и логическая схема ИСКЛЮЧАЮЩЕЕ ИЛИ (RXXOR) приемника. Задержка 1 5732a должна совпадать или превышать задержку логического вентиля ИСКЛЮЧАЮЩЕЕ ИЛИ 5736 в каскаде RXXOR, которая определяется соотношением:
tPD-min(Задержка 1) ≥ tPD-max(XOR)
Желательно выполнить это требование, так чтобы входной сигнал D-триггера 5728, 5732 приемника не изменялся до подачи на него входного сигнала синхронизации. Это выполняется, если время промежуточного хранения RXFF равно нулю.
Задача или функция Задержки 2 состоит в том, чтобы компенсировать время промежуточного хранения триггера RXFF согласно соотношению:
tPD-min(Задержка 2) = tH (RXFF)
Во многих системах это время будет равно нулю, так как время промежуточного хранения нулевое и, конечно, в этом случае максимальная задержка "Задержка 2" также может быть нулевой.
Наихудший случай вклада в сдвиг во времени в каскаде XOR приемника имеет место в случае опоздания данных/ранний приход строба, где Задержка 1 равна максимальному значению и выходной сигнал синхронизации из логического вентиля XOR прибывает как можно раньше, согласно соотношению:
tSKEW-max(RXXOR) = tPD-max(Задержка 1) - tPD-min( XOR)
В этой ситуации данные могут изменяться между двумя битовыми периодами n и n+1 очень близко к моменту времени, когда бит n+1 синхронизируется в триггере приемника.
Максимальная скорость передачи данных (минимальный период бита) линии связи MDDI Типа 1 является функцией максимального сдвига во времени, который происходит во всех задающих устройствах, кабеле и приемниках в линии связи MDDI плюс полная установка данных в каскаде RXFF. Полный сдвиг задержки в линии связи вплоть до выхода каскада RXRCVR может быть выражен как:
tSKEW-max(LINK) = tSKEW-max(TXFF)+ tSKEW-max(TXDRVR) + tSKEW-max(кабель)+tSKEW-max(RXRCVR)
где "кабель" представляет множество проводников, или межсоединений, или проводов и соответствующую задержку, и минимальный битовый период задается как:
tBIT-min = tSKEW-max(ЛИНИЯ СВЯЗИ)+ 2*tB-TP4 + tAsymmetry + tSKEW-max(RXXOR) + tдрожание-вед.устройство + tPD-max(Задержка 2) + tSU(RXFF)
В примере, проиллюстрированном на Фиг.57 для внешнего режима, tSKEW-max(ЛИНИЯ СВЯЗИ) = 1000 пс и минимальный битовый период может быть выражен как:
tBIT-min = 1000 + 2*125 + 625 + 125 + 200 + 0 + 100 = 2300 пс
или составляет приблизительно 434 Мбит/с. В примере, показанном на Фиг.57 для внутреннего режима, tSKEW-max(ЛИНИЯ СВЯЗИ) = 500 пс и минимальный битовый период может быть выражен как:
tBIT-min = 500+2 *125+625+125+200+0+100=1800 пс
или составляет приблизительно 555 Мбит/с.
Если ведущее устройство использует пакет «Калибровка сдвига во времени задержки", тогда имеются дополнительные требования к асимметрии задержки, сдвигу во времени задержки и дрожанию сигнала синхронизации в ведущем устройстве, которые определяются требованием к максимальной асимметрии задержки и дрожанию сигнала синхронизации для ведущего устройства с калибровкой ассиметрии:
tAsymmerty-TXFF + tAsymmetry-TXDRVR + tдрожание-вед.устройство ≤ 1000 пс, и
требование к максимальному сдвигу во времени задержки для ведущего устройства с калибровкой сдвига во времени:
tSkew-TXFF + tSkew-TXDRVR ≤ 1000 пс
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-входе каскада B (RXFFB) приемника, состоящего из триггеров 5928 и 5930, изменяются сразу после фронта синхроимпульса, так что они могут быть надежно выбраны. Если MDDI_Data1 прибывает ранее чем MDDI_Stb или MDDI_Data0, тогда MDDI_Data1 должны быть задержаны, чтобы они могли быть выбраны по меньшей мере на величину сдвига во времени задержки.
Чтобы выполнять это, данные задерживают, используя линию задержки Задержка 3. Если MDDI_Data1 прибывают позже, чем MDDI_Stb и MDDI_Data0, и они также задерживаются посредством Задержки 3, тогда точка, где MDDI_Data1 изменяются, перемещается ближе к следующему фронту синхроимпульса. Этот процесс определяет верхний предел скорости передачи данных линии связи MDDI Типа 2, 3 или 4. Некоторые примерные различные возможности для временного соотношения или сдвига во времени двух сигналов данных и MDDI_Stb относительно друг друга иллюстрируются на Фиг.60A, 60B и 60C.
Чтобы надежно произвести выборку данных в RXFFB, когда MDDI_DataX прибывает так рано, как это возможно, Задержка 3 устанавливается согласно соотношению:
tPD-min (Задержка 3) ≥ tSKEW-max(ЛИНИЯ СВЯЗИ) + tH(RXFFB) + tPD-max (XOR)
Максимальная скорость линии связи определяется минимально разрешимым битовым периодом. На нее больше всего оказывается воздействие, когда MDDI_DataX прибывает настолько поздно, насколько это возможно. В этом случае минимально разрешаемое время такта (цикла) задается соотношением:
tBIT-min = tSKEW-max(ЛИНИЯ СВЯЗИ)+ tPD-max(Задержка 3) + tSU(RXFFB) +tPD-min (XOR)
Верхняя граница скорости линии связи тогда равна:
tPD-max (Задержка 3) = tPD-min (Задержка 3)
и, учитывая это предположение, получают:
tBIT-min(нижняя граница) = 2*tSKEW-max(ЛИНИЯ СВЯЗИ)+tPD-max(XOR)+tSU(RXFFB) + tH(RXFFB)
В примере, данном выше, нижняя граница минимального битового периода задается соотношением:
tBIT-min(нижняя граница) = 2*(1000+2*125+625+200)+1500+100+0=5750 пс,
что составляет приблизительно 174 Мбит/с.
Это намного медленнее, чем максимальная скорость передачи данных, которая может использоваться с линией связи Типа 1. Функциональная возможность автоматической компенсации сдвига во времени для задержки MDDI значительно уменьшающее воздействие, которое этот сдвиг во времени задержки оказывает на фактор максимальной скорости передачи линии связи, является как раз "на фронте" установки достоверных данных. Калиброванный сдвиг между MDDI_Data0 и MDDI_Stb равен:
tSKEW-max(калиброванный) = 2*tTAP-SPACING-max,
и минимальный битовый период равен:
tBIT-min-Калиброванный = tSKEW-max(Калиброванный) + 2*tB-TP4 + tAsymmetry + tдрожание-ведущее устройство + tSKEW-максимальный (RXAND+RXXOR) + tSU(RXFF)
где "TB" или tB представляет дрожание (смещение) сигнала от битовой границы до минимального выходного уровня. Асимметрия просто относится к асимметричной природе внутренней задержки через или самих дифференциальных приемников. "TP4" ассоциирован с или эффективно определен для целей электрической характеристики и тестирования в качестве соединения или интерфейса (выводы (пины) устройства контроллера MDDI в клиенте) для дифференциальных задающих устройств и приемников линии для клиента. Это представляет удобную или заранее определенную точку, от которой задержка сигнала измеряется и характеризуется для линии связи в остальной части системы. В одном варианте осуществления максимальное значение параметра tB в TP4 определяется соотношением tDifferential-Skew-TP4-DRVR-EXT = 0,3*tBIT для внешнего режима и tDifferential-Skew-TP4-DRVR-INT=0,6*tBIT для внутреннего режима для передатчиков клиента; и tB-TP4-RCVR-EXT = 0,051*tBIT + 175 пс для внешнего режима для приемников клиента.
Метка TP4 является просто полезной в нумерации различных контрольных точек (TP) в интерфейсе и линиях связи. В одном варианте осуществления это местоположение контрольной точки определяется как одно и то же и для внутреннего и внешнего режимов. Имеется соответствующая контрольная точка "TP0" для, или ассоциированная с, выводов (штырьков) соединения или интерфейса устройства контроллера MDDI в ведущем устройстве, которое содержит дифференциальные задающие устройства и приемники линии связи. В этом варианте осуществления максимальное значение параметра TB в TP0 определяется отношением tB-TP0-RCVR-INT = 0,051*tBIT+50 пс для внутреннего режима, и tB-TP0-RCVR-EXT =0,051*tBIT + 175 пс для внешнего режима для приемников ведущего устройства; и tB-TP0 =0,102*tBIT для передатчиков ведущего устройства.
В примере, показанном на Фиг.59, tSKEW-max(Data0-Stb-Calibrated) = 300 пс и минимальный битовый период равен:
tBIT-min-Calibrated = 300 + 2*125 + 625 + 200 + 175 + 100 =1650 пс,
что составляет приблизительно 606 Мбит/с.
Чтобы надежно производить выборку данных в RXFFB, когда MDDI_Data1 прибывает так рано, как возможно, ассоциированная программируемая задержка настраивается к оптимальным параметрам с точностью одного элемента, и дополнительная задержка в один элемент добавляется для обеспечения безопасности. Максимальное быстродействие линии связи определяется минимально разрешимым битовым периодом. Оно больше всего подвергается воздействию, когда MDDI_Data1 прибывает настолько поздно, насколько возможно. В этом случае минимальное допустимое время цикла (такта) равно:
tBIT-min-Data1-Calibrated = 2*tTAP-Spacing-max + 2*tTA-TP4,
где "TA" или tA представляет дрожание сигнала от битовой границы до срединной линии.
В примере, приведенном на Фиг.59, нижняя граница минимального битового периода, основанного на выборке MDDI_Data1, равна:
tBIT-min-Data1-Calibrated = 2 * 150 + 2 * 125 = 550 пс.
В одном варианте осуществления типовое полное время задержки для сдвига во времени задержки, асимметрии задержки и дрожания сигнала синхронизации в передатчике ведущего режима для внутреннего режима может быть определено как:
tAsymmerty-TXFF + tAsymmetry-TXDRVR + tSkew-TXFF + tSkew-TXDRVR +
+ tдрожание-ведущее устройство = 0,467 * (tBIT - 150 пс),
и для внешнего режима как:
tAsymmerty-TXFF + tAsymmetry-TXDRVR + tSkew-TXFF + tSkew-TXDRVR +
+ tдрожание-ведущее устройство = 0,TBD*(tBIT -150TBD пс),
в то время как типичное полное время задержки для сдвига во времени задержки, асимметрии задержки и времени установки в клиентском устройстве (tB-TP4) для внутреннего режима равно:
tAsymmerty-RXRCVR + tAsymmetry-RXXOR + tSkew-RXRCVR + tSkew-RXXOR +tsetup-RXFF = 0,307 * (tBIT -150 пс),
и для внешнего режима:
tAsymmerty-RXRCVR + tAsymmetry-RXXOR + tSkew-RXRCVR + tSkew-RXXOR + tsetup-RXFF - 0,TBD* (tBIT -TBD пс),
где термин TBD есть "гибкая" метка для помещения места для определенных в будущем значений, которые должны зависеть от множества хорошо понятных характеристик и операционных требований для соединений внешнего режима.
Типичная схема интерфейса для варианта осуществления для прямой линии связи MDDI Типа 2, аналогичная таковой согласно Фиг.59, со схемой компенсации сдвига во времени задержки иллюстрируется на Фиг.61. Дополнительные элементы используются после каскада RXRCVCR, а именно выбираемые элементы 6102 и 6104 задержки наряду с задающими устройствами 6106 и 6108 ввода калибровки, которые соединены с логическими вентилями И 6112 и 6114 соответственно, чьи выходы, в свою очередь, соединены с логическим вентилем XOR (ИСКЛЮЧАЮЩЕЕ ИЛИ) 6116. Логический вентиль XOR 616 затем обеспечивает входной сигнал для каскада RXFFA, как показано. Эти элементы используются, чтобы осуществить дополнительную обработку сигналов. Задающие устройства 6108 и 6106 учитывают калибровку для трактов передачи сигналов, в то время как элементы 6102 и 6104 задержки учитывают выбираемые величины задержки, которая должна быть введена или использована для трактов передачи сигнала для выходных сигналов задающих устройств 5724 и 5924 соответственно.
В этом примере переменные задержки 6102 и 6104 используются, чтобы подстроить относительное время поступления сигналов строба и данных. Выравнивание времени поступления этих сигналов позволяет установить заранее данные на входе D-триггеров (5728, 5730, 5928, 5930) в приемнике. Когда клиентское устройство принимает поле Calibration Data Sequence (последовательность данных калибровки) пакета «Калибровка сдвига во времени прямой линии связи", простой конечный автомат может проверять одновременные переходы на всех дифференциальных парных сигналах, чтобы определить оптимальные параметры настройки регулируемой задержки. Конечный автомат может использовать алгоритм последовательного приближения для коррекции переменных задержек, чтобы найти точку, в которой данные могут быть выбраны безопасно, и затем корректировать задержку на один элемент наиболее безопасным параметрам настройки, чтобы гарантировать надежную работу (может быть на один элемент меньше на тракте MDDI_Stb и на один элемент больше на тракте MDDI_Data). Поле Calibration Data Sequence содержит большое количество одновременных переходов на всех дифференциальных парах, чтобы облегчить эту операцию.
В примере, приведенном на Фиг.61, нижняя граница минимального битового периода, основанного на выборке MDDI_Data1, равна:
tBIT-min-Data1-Calibrated = 2*150 + 2*125 = 550 пс
Это является значительным усовершенствованием по сравнению с тактированием некалиброванной линии связи для MDDI_Data1. Однако один потенциальный определяющий фактор для максимальной скорости передачи данных в отношении линии связи с калиброванным временным сдвигом задержки будет обычно ограничиваться способностью согласования задержки между MDDI_Stb и MDDI_Data0, как можно видеть в приведенном выше примере. Существует много возможных усовершенствований в архитектуре компенсации задержки, описанной выше, такой как обеспечение точной настройки для Задержки 5 на Фиг.61.
Когда используется компенсация сдвига во времени задержки, обычно имеется верхний предел величины дифференциального сдвига во времени, который разрешается или является разрешенным на выходе задающего устройства ведущего устройства. Это определено выше и для внутреннего, и для внешнего режимов. Без этого ограничения может существовать чрезвычайно большой диапазон для величины дифференциального сдвига во времени, который требует коррекции в клиентском устройстве для ведущих устройств, которые работают на очень низких скоростях передачи данных. Так как первичное использование компенсации сдвига во времени заключается в уменьшении сдвига задержки, чтобы позволить устройствам работать на более высоких скоростях, максимальный предел сдвига во времени задержки обычно определяется системой или проектировщиками устройства для ведущих устройств, которые используют компенсацию сдвига во времени задержки. Общая величина компенсации сдвига во времени, которая используется в клиентском устройстве, является суммой следующих трех параметров. Максимальный дифференциальный сдвиг во времени на выходе задающего устройства ведущего устройства, который является максимальным сдвигом во времени задержки для каскадов TXFF + TXDRVR на Фиг.61; максимальный дифференциальный сдвиг во времени в подсистеме межсоединений от TP0 (контрольной точки 0) до TP4 (контрольной точки 4), который является максимальным сдвигом во времени задержки в кабельном каскаде стадии на Фиг.61; и максимальный дифференциальный сдвиг во времени в клиенте между входами дифференциального приемника и схемой выборки данных. Этот последний параметр является максимальным сдвигом во времени задержки от входов каскадов RXRCVR до входов каскадов RXFFA и RXFFB на Фиг.61.
XIV. Описание межсоединений физического уровня
Физические соединения, используемые для осуществления интерфейса согласно настоящему изобретению, могут быть реализованы, используя коммерчески доступные компоненты, такие как номер компонента 3260-8S2 (01), который изготавливает Hirose Electric Company Ltd., на стороне ведущего устройства, и номер компонента 3240-8P-C, который изготавливает Hirose Electric Company Ltd., на стороне клиентского устройства. Примерное назначение выводов интерфейса или схема расположения выводов для таких соединителей, используемых с интерфейсами Тип-1/Тип-2, перечислены в Таблице XV.
| Таблица XV | |||
| Название сигнала | Номер вывода | Название сигнала | Номер вывода |
| MDDI_Pwr | 1 | MDDI_Gnd | 11 |
| MDDI_Stb+ | 2 | MDDI_Stb- | 12 |
| MDDI_Data0+ | 4 | MDDI_Data0- | 14 |
| MDDI_Data1+ | 6 | MDDI_Data1- | 16 |
| MDDI_Data2+ | 8 | MDDI_Data2- | 18 |
| MDDI_Data3+ | 10 | MDDI_Data3- | 20 |
| MDDI_Data4+ | 9 | MDDI_Data4- | 19 |
| MDDI_Data5+ | 7 | MDDI_Data5- | 17 |
| MDDI_Data6+ | 5 | MDDI_Data6- | 15 |
| MDDI_Data7+ | 3 | MDDI_Data7- | 13 |
| Экран | |||
Экран соединен с HOST_Gnd в интерфейсе ведущего устройства, и провод стока экрана в кабеле соединен с экраном соединителя в клиенте. Однако экран и провод стока не соединены с землей схемы внутри клиента.
Элементы или устройства межсоединений выбирают или разрабатывают так, чтобы они были достаточно малыми для использования с мобильными коммуникационными или вычислительными устройствами, такими как PDA и беспроводные телефоны или портативные игровые устройства, чтобы они не были навязчивыми или неэстетичными по сравнению с относительным размером устройства. Любые соединители и кабельные соединения должны быть достаточно длительны в использовании в типичной среде потребителя и учитывать небольшой размер, особенно для кабельного соединения, и иметь относительно низкую стоимость. Элементы передачи должны обеспечивать данные и сигналы строба, которые являются дифференциальными данными NRZ (без возвращения к нулю), имеющими скорость передачи вплоть до приблизительно 450 Мбит/с для Типа 1 и Типа 2 и вплоть до 3,6 Гбит/с для версии 8-битового параллельного Типа 4.
Для приложений внутреннего режима или не имеется соединителей в том же смысле, что для используемых проводников, или такие соединительные элементы имеют тенденцию быть очень миниатюризированными. Одним из примеров являются "разъемы" с нулевой силой вставки для приема интегральных схем или элементов, размещающих или клиентское устройство, или ведущее устройство. Другим примером является тот, когда ведущее устройство и клиент постоянно находятся на сетевых печатных платах с различными проводниками соединений и имеют "штырьки" или контакты, выступающие из корпусов, которые припаяны к контактам на проводниках для взаимных соединений интегральных схем.
При взгляде на соединение двух клиентов, например, для ранее описанного внутреннего режима внимание должно быть обращено на разводку кабелей, соединения и некоторые факторы в размещении первичного клиента для более подходящей передачи данных и обмена. Соединения или кабели, соединяющие клиентов, формируют линии передачи, которые являются по существу не имеющими оконечных нагрузок, как проиллюстрировано в конфигурации, иллюстрируемой на Фиг.99. На Фиг.99 ведущее устройство 9902 показано соединенным через проводник 9904, который разветвляется на две оконечных нагрузки, здесь оконечная нагрузка 1 и оконечная нагрузка 2, которые подают или передают сигналы от ведущего устройства к клиентам в местоположениях А и B соответственно. Снова исключительно с целью иллюстрации, а не как ограничение каких-либо вариантов осуществления или применения изобретения клиенты показаны здесь как являющиеся частью, подсоединенной к ассоциированной с или иным образом обменивающейся с контроллерами LCD или LCD-элементами отображения или панелями. Когда эти два клиентских устройства соединены во внутреннем режиме, устройство первичного клиента, которое и принимает, и передает сигналы на пары MDDI_Data и расположено совместно с нагрузочными резисторами (полными сопротивлениями), должно быть расположено или подсоединено "в конце" кабеля, что указано здесь на Фиг.99 как "Местоположение А" и с длиной 
меньшей или равной длине 
Другой клиент (или клиенты в некоторых случаях) тогда расположены или подсоединены "в конце" ответвления от кабеля, которое расположено между концом и ведущим устройством, что указано здесь на Фиг.99 как "Местоположение В". Фиг.99 также показывает в общем виде, как такие оконечные нагрузки линии передачи определяются для использования в вариантах осуществления специалистами в данной области техники. Те, кто использует устройство или способы различных вариантов осуществления изобретения, должны реализовать такие конфигурации посредством ограничения длины оконечных нагрузок в линии передачи, чтобы в общем случае гарантировать, что качество сигнала удовлетворяет любым ограничениям или требованиям, чтобы поддерживать соответствующую высокоскоростную операцию и свободную от ошибок (или с минимальным их количеством) линию связи при рассмотрении минимального времени нарастания выходного сигнала задающего устройства и скоростного фактора линий передачи.
XV. Работа
Суть общих этапов, предпринимаемых при обработке данных и пакетов во время работы интерфейса, используя варианты осуществления настоящего изобретения, иллюстрируется на Фиг.54А и 54B, вместе с кратким обзором аппаратуры интерфейса, обрабатывающего пакеты, согласно Фиг.55. На этих чертежах процесс начинается на этапе 5402 с определения того, подсоединены ли клиент и ведущее устройство, используя коммуникационный тракт, здесь - кабель. Это может быть выполнено с помощью выполнения ведущим устройством периодического опроса, используя программное обеспечение или аппаратные средства, которые обнаруживают присутствие соединителей или кабелей или сигналов на входах на ведущем устройстве (как это видно для интерфейсов USB), или других известных методов. Если не имеется клиента, соединенного с ведущим устройством, тогда оно может просто входить в состояние ожидания некоторой заранее определенной длительности, в зависимости от применения, входить в режим бездействия (спячки), или быть деактивированным в ожидании будущего использования, которое может требовать, чтобы клиент принял меры для "повторной активации ведущего устройства. Например, когда ведущее устройство постоянно находится на устройстве типа компьютера, пользователю может придется нажать на экранный значок или запросить программу, которая активизирует обработку в ведущем устройстве, чтобы искать клиента. Снова простая вставка в соединения типа USB может активизировать обработку ведущего устройства в зависимости от возможностей и конфигурации ведущего устройства или резидентного программного обеспечения ведущего устройства.
Как только клиент подсоединен к ведущему устройству или наоборот, или обнаружен как присутствующий, или клиент или ведущее устройство посылают соответствующие пакеты, требующие обслуживания, на этапах 5404 и 5406. Клиент может посылать или пакет "Запрос на обслуживание клиента", или пакет Состояния на этапе 5404. Следует отметить, что работа линии связи, как описано выше, может быть предварительно завершена или она может находиться в режиме бездействия, так что это может не быть полной инициализацией коммуникационной линии связи, которая следует за этим. Как только коммуникационная линия связи синхронизирована, и ведущее устройство пробует обмениваться с клиентом, клиент также обеспечивает пакет "Возможности клиента" на ведущее устройство, как на этапе 5408. Ведущее устройство может теперь начинать определение типа поддержки, включая скорости передачи, которые клиент может обеспечивать.
Обычно ведущее устройство и клиент также согласуют тип (частоту/скорость) режима обслуживания, который нужно использовать, например Тип 1, Тип 2 и т.д., на этапе 5410. Как только тип обслуживания установлен, ведущее устройство может начинать передавать информацию. Кроме того, ведущее устройство может использовать пакеты "Измерение задержки прохождения сигнала в прямом и обратном направлениях", чтобы оптимизировать синхронизацию коммуникационной линии связи параллельно с другой обработкой сигналов, как показано на этапе 5411.
Как описано выше, все передачи начинаются с пакета "Заголовок под-кадра", показанного как передаваемый на этапе 5412, с последующим типом данных, здесь - пакеты потоков видео и аудио и пакеты-заполнители, показанные как передаваемые на этапе 5414. Аудио- и видеоданные должны быть предварительно подготовлены или преобразованы в пакеты, и пакеты-заполнители вставлены где необходимо, или желательно должны заполнить требуемое количество битов для медиакадров. Ведущее устройство может посылать пакеты, такие как пакет "Разрешение канала аудио прямой линии связи", чтобы активизировать звуковые устройства. Кроме того, ведущее устройство может передавать команды и информацию, используя другие типы пакета, описанные выше, здесь показанные как передача пакетов "Карта цвета", "Поблочная пересылка битовой карты" или других, на этапе 5416. Кроме того, ведущее устройство и клиент могут обмениваться данными, относящимися к клавиатуре или устройствам указания, используя соответствующие пакеты.
Во время работы может происходить одно из нескольких различных событий, которые приведут к тому, что ведущее устройство или клиент потребуют различную скорость передачи данных или тип режима интерфейса. Например, компьютер или другое устройство, обменивающееся данными, может сталкиваться с загрузкой условий при обработке данных, что вызывает медленное снижение в подготовке или представлении пакетов. Клиентское устройство, принимающее данные, могло сменить специализированный источник питания переменного тока на более ограниченный источник питания от батареи и или не быть способным перейти так быстро к данным, командам обработки с легкостью, или не быть способным использовать ту же самую степень разрешения или глубину цвета при более ограниченных параметрах настройки в отношении мощности. Альтернативно, ограничивающее условие может быть уменьшено или исчезнуть, разрешая любому устройству передавать данные при более высоких скоростях. Если это является более желательным, запрос может быть сделан на изменение к режиму с более высокой скоростью передачи.
Если эти или другие типы известных условий имеют место или изменяются, ведущее устройство или клиент может обнаруживать их и пробовать повторно согласовать режим интерфейса. Это показано на этапе 5420, где ведущее устройство посылает пакеты "Запрос передачи обслуживания в режим определенного типа" клиенту, запрашивающему передачу обслуживания к другому режиму, клиент посылает пакеты "Подтверждение типа интерфейса", подтверждающие, что изменение ищется, и ведущее устройство посылает пакеты «Выполнение передачи обслуживания в режим определенного типа», чтобы выполнить изменение к указанному режиму.
Хотя и не требуя специфического порядка обработки, клиент и ведущее устройство могут также обмениваться пакетами, относящимися к данным, предназначенным для или принятых от устройств указания, клавиатур или других устройств ввода данных пользовательского типа, ассоциированных прежде всего с клиентом, хотя такие элементы могут также присутствовать на стороне ведущего устройства. Эти пакеты обычно обрабатываются, используя элемент типа процессора общего назначения, а не конечный автомат (5502). Кроме того, некоторые из команд, описанных выше, также будут обрабатываться процессором общего назначения (5504, 5508).
После того как состоялся обмен данными и командами между ведущим устройством и клиентом, в некоторый момент времени принимается решение относительно того, должны ли быть дополнительные данные переданы или ведущее устройство или клиент собирается прекращать обслуживать передачу. Это показано на этапе 5422. Если линия связи должна войти или в состояние бездействия, или ее работа должна быть полностью завершена, ведущее устройство посылает пакет "Завершение работы линии связи" клиенту и обе стороны завершают передачу данных.
Пакеты, передаваемые посредством вышеупомянутой обработки операций, будут переданы, используя задающие устройства и приемники, описанные выше в отношении контроллеров клиента и ведущего устройства. Эти задающие устройства линии и другие логические элементы подсоединены к конечному автомату и процессорам общего назначения, описанными выше, как иллюстрируется в кратком обзоре со ссылками на Фиг.55. На Фиг.55 конечный автомат 5502 и процессоры 5504 и 5508 общего назначения могут быть дополнительно соединены с другими не показанными элементами, например специализированным интерфейсом USB, элементами памяти или другими компонентами, постоянно находящимися вне контроллера линии связи, с которым они взаимодействуют, включая в себя, но не ограничиваясь ими, источник данных и микросхемы управления видео для устройств отображения вида.
Эти процессоры и конечный автомат обеспечивают управление разрешением и запрещением задающих устройств, как описано выше в отношении защитных интервалов времени и т.д., чтобы гарантировать эффективное установление или прерывание работы коммуникационной линии связи и передачи пакетов.
XVI. Буферы кадра отображения
Требования буферизации видеоданных являются отличными для движущихся изображений видео по сравнению с компьютерной графикой. «Пиксельные данные» наиболее часто сохраняются в локальном буфере кадров в клиенте, так что изображение на клиенте может быть регенерировано локально.
Когда полномасштабное видео отображается (почти каждый пиксель в дисплее изменяется в каждом медиакадре), обычно является предпочтительным сохранять входящие пиксельные данные в одном буфере кадра, в то время как изображение на дисплее регенерируется из второго буфера кадра. Могут использоваться более двух дисплейных буферов, чтобы устранить видимые артефакты, как описано ниже. Когда полное изображение было принято в одном буфере кадра, тогда роли буферов могут меняться, и затем недавно принятое изображение используется для регенерации (обновления) дисплея, и другой буфер заполняется следующим кадром изображения. Эта концепция иллюстрируется на Фиг.88A, где пиксельные данные записывают в автономный буфер изображения посредством установки битов "Обновление дисплея" равными "01".
В других приложениях ведущее устройство должно модифицировать только малую часть изображения без необходимости перерисовывать все изображение. В этой ситуации желательно записывать новые пиксели непосредственно в буфер, используемый для обновления дисплея, как подробно иллюстрируется на Фиг.88B.
В применениях, которые имеют фиксированное изображение с малым окном видео, самое простое - записать это фиксированное изображение в оба буфера (биты обновления дисплея равны "11"), как показано на Фиг.88C, и впоследствии записывать пиксели движущегося изображения в автономный буфер посредством установки битов обновления дисплея равными "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 (пакет "Заголовок под-кадра" с полем Sub-frame Count ("количество под-кадров"), равным нулю) выполняются следующие операции в указанном порядке: just_filled устанавливают равным current_fill и устанавливают current_fill равным current_fill + 1.
Пакеты "Поток видео MDDI" обновляют буферы согласно следующей структуре или методологии: когда биты "Обновление дисплея" равны '01', пиксельные данные записывают в буфер, указанный current_fill; когда биты "Обновление дисплея" равны '00', пиксельные данные записывают в буфер, заданный посредством just_filled; и когда биты "Обновление дисплея" равны "11", пиксельные данные записывают во все буферы. Дисплей регенерируется из буфера, указанного указателем being_displayed. После того как дисплей регенерировал последний пиксель в одном периоде обновления кадра и прежде чем он начинает регенерировать первый пиксель в следующем периоде регенерации кадра, процесс обновления дисплея выполняет операцию установки значения being_displayed равным значению just_filled.
Пакеты с полем Pixel Data Attribute ("Атрибуты пиксельных данных") содержат пару битов "Обновление дисплея", которые задают буфер кадров, куда пиксельные данные должны быть записаны. Пакет "Возможности клиента" имеет три дополнительных бита, которые указывают, какие комбинации битов "Обновление дисплея" поддерживаются в клиенте. Во многих случаях создаваемые компьютером изображения должны быть с приращением обновлены на основании введенной пользователем или выведенной (полученной) из информации, принятой из компьютерной сети. Комбинации "00" и "11" битов "Обновление дисплея" поддерживают этот режим работы, приводя к тому, что пиксельные данные должны быть записаны в отображаемый буфер кадра или в оба буфера кадра.
При размещении изображений видео, Фиг.89 иллюстрирует, как изображения видео отображаются с использованием пары буферов кадра, когда видеоданные передаются по линии связи MDDI с битами "Обновление дисплея", равными "01". После того как граница медиакадра обнаружена на линии связи MDDI, процесс регенерации дисплея будет начинать регенерацию со следующего буфера кадра, когда процесс регенерации для кадра, регенерируемого в настоящее время, завершен.
Важным предположением, относящимся к Фиг.89, является то, что изображение принимается от ведущего устройства в качестве непрерывного потока пикселей, которые передаются в том же самом порядке, который клиент использует, чтобы считывать пиксели из буфера кадра для регенерации дисплея (обычно сверху - слева, считывая строку за строкой, в нижний правый угол экрана). Это является важной деталью в случаях, когда операции "Регенерация Дисплея" и "Передача изображения" ссылаются на один и тот же буфер кадра.
Необходимо, чтобы частота кадров регенерации дисплея была больше, чем частота кадров передачи изображения, чтобы избежать отображения частичных изображений. На Фиг.90 показано, как фрагментация изображения может происходить при медленной частоте регенерации дисплея, то есть регенерация дисплея является более медленной, чем передача изображения.
В изображении, которое содержит комбинацию изображений компьютерной графики и картинок двигающегося видео, пиксельные данные видео могут занимать малую часть медиакадра. Это может быть существенно в ситуациях, когда операция по регенерации дисплея и передача изображения ссылаются на один и тот же буфер кадра. Эти ситуации показаны заштрихованным затенением на Фиг.91, где пикселями, считываемыми из буфера для регенерации дисплея, могут быть пиксели, записанные в буфер два кадра назад, или они могут соответствовать кадру, немедленно записываемому в тот же самый буфер кадра.
Использование трех буферов кадра в клиенте решит проблему маленького окна при состязании за доступ к буферу кадра, как показано на Фиг.92.
Однако еще остается проблема, если частота регенерации дисплея меньше, чем скорость передачи медиакадров по линии связи MDDI, как показано на Фиг.93.
Использование единственного буфера для движущихся видеоизображений является несколько проблематичным, как показано на Фиг.94. При регенерации дисплея быстрее, чем передача изображения в буфер, обновляемое изображение иногда будет показывать верхнюю часть записываемого кадра, а нижняя часть изображения будет кадром, переданным ранее. При регенерации дисплея быстрее, чем передача изображения (предпочтительный режим работы), будут встречаться более частые случаи кадров, показывающих аналогичное разбиение изображения.
XVII. Поддержка множества клиентов
Текущая версия протокола показана как непосредственно не поддерживающая множество клиентских устройств. Однако большинство пакетов содержит зарезервированное поле «Идентификатор клиента», которое может использоваться, чтобы адресовать конкретные клиентские устройства в системе с множеством клиентов. В настоящее время для многих приложений этот Идентификатор клиента или эти Идентификаторы клиента установлены равными нулю. Пакет «Заголовок под-кадра» также содержит поле, чтобы указать, поддерживает ли ведущее устройство систему с множеством клиентов. Поэтому существует способ, в котором множество клиентских устройств могут быть вероятно соединены и адресованы в будущих применениях MDDI или протокола, чтобы помочь системным проектировщикам планировать будущую совместимость с множеством ведущих устройств клиента и клиентами.
В системах, имеющих множество клиентов, для клиентов удобно быть соединенными с ведущим устройством, используя последовательное соединение клиентов, или используя концентраторы, как показано на Фиг.95, или используя комбинацию этих методов, как показано на Фиг.96. Для ведущего устройства также может быть полезно отображать некоторые сообщения об ошибках, чтобы управлять соединенными клиентами, например сообщения об ошибках, когда один или более клиентов, требующих адрес 0, соединены, что не должно иметь место для систем с множеством клиентов, когда такие дисплеи ожидают, что будут установлены или уже установлены для работы в качестве единственного клиента.
XIII. Приложение
В дополнение к форматам, структурам и содержанию, описанным выше для различных пакетов, используемых для реализации архитектуры и протокола для вариантов осуществления изобретения, более подробное содержание полей или операции представлены ниже для некоторых типов пакетов. Они представлены здесь, чтобы дополнительно пояснить их соответствующее использование или операции, чтобы дать возможность специалистам в данной области техники проще понять и использовать изобретение для множества приложений. Только несколько из полей, еще не описанных, описаны ниже. Кроме того, эти поля представлены с примерными определениями и значениями в отношении вариантов осуществления, представленных выше. Однако такие значения не должны быть восприняты как ограничения изобретения, но должны представлять один или более вариантов осуществления, используемых для реализации интерфейса и протокола, и не все варианты осуществления должны быть осуществлены вместе или одновременно. В других вариантах осуществления могут использоваться другие значения, чтобы достичь требуемого представления данных или результатов передачи скорости передачи данных, как должно быть понятно специалистам в данной области техники.
A. Для пакетов «Поток Видео»
В одном варианте осуществления поле Pixel Data Attributes (Атрибуты пиксельных данных), здесь 2 байта, имеют последовательность битовых значений, которые интерпретируются следующим образом. Биты 1 и 0 выбирают, как маршрутизируются пиксельные данные дисплея. Для битовых значений '11' пиксельные данные отображаются к или для обоих глаз, для битовых значений '10' пиксельные данные направляются только к левому глазу, и для битовых значений '01' пиксельные данные направляются только к правому глазу, а для битовых значений '00' пиксельные данные направляются на альтернативный дисплей, как может быть задано битами 8-11, описанными ниже. Если первичный дисплей или находящийся в использовании или над которым производятся манипуляции клиентом, не поддерживает стереоизображения или отображения в некоторой форме, то эти команды не могут быть эффективно внедрены, чтобы иметь воздействие, как требуется дисплеем. В этой ситуации или конфигурации клиент должен направить пиксельные данные на первичный дисплей независимо от битовых значений или для любой из комбинаций битов '01', '10' или '11', так как результирующие команды или управление не смогут быть выполнены дисплеем. Рекомендуется, но не требуется в вариантах осуществления, что значение '11' используется для адресации первичного дисплея для тех клиентов, которые не поддерживают возможность стереоотображения.
Бит 2 указывает, представлены ли пиксельные данные в формате чересстрочной развертки со значением '0', означающим, что пиксельные данные находятся в стандартном формате прогрессивной развертки и что номер строки (координата Y пикселей) увеличивается на 1 при переходе от одной строки к следующей. Когда этот бит имеет значение '1', пиксельные данные находятся в чересстрочном формате, и номер строки увеличивается на 2 при переходе от одной строки к следующей. Бит 3 указывает, что пиксельные данные находятся в чередующемся (дополнительном) пиксельном формате. Это аналогично стандартному чересстрочному режиму, разрешенному битом 2, но чередование является вертикальным вместо горизонтального. Когда бит 3 равен '0', пиксельные данные находятся в стандартном прогрессивном формате, и номер столбца (координата X пикселей) увеличивается на 1, когда принимается каждый последующий пиксель. Когда бит 3 равен '1', пиксельные данные находятся в дополнительном пиксельном формате, и номер столбца увеличивается на 2, когда принимается каждый пиксель.
Бит 4 указывает, относятся ли пиксельные данные к дисплею или камере, как когда данные передаются к или от внутреннего дисплея для беспроводного телефонного или аналогичного устройства или даже портативного компьютера, или таким другим устройствам, как описано выше, или данные передаются к или от камере(ы), встроенной или непосредственно подсоединенной к устройству. Когда бит 4 равен '0', пиксельные данные передаются к или от буфера кадра дисплея. Когда бит 4 равен '1', пиксельные данные передаются к или от камере(ы) или устройства видео некоторого типа, такие устройства известны в данной области техники.
Бит 5 используется, чтобы указать, когда пиксельные данные содержат следующую последовательную строку пикселей в дисплее. Здесь рассматривается случай, когда бит 5 установлен равным '1'. Когда бит 5 установлен в '1', тогда параметры X Левой границы, Y Верхней границы, X Правой границы, Y нижней границы, X Начала и Y Начала не определены и игнорируются клиентом. Когда бит 15 установлен равным уровню логической единицы, это указывает, что пиксельные данные в этом пакете являются последней строкой пикселей в этом изображении. Бит 8 поля Client Feature Capability Indicators (Индикаторы возможностей характеристик клиента) в пакете «Возможности клиента» указывает, поддерживается ли эта особенность.
Биты 7 и 6 являются битами «Обновление дисплея», которые задают буфер изображения, куда пиксельные данные должны быть записаны. Более конкретные действия описаны в другом месте описания. Для битовых значений '01' пиксельные данные записываются в автономный буфер изображения. Для битовых значений '00' пиксельные данные записываются в буфер изображения, используемый для регенерации дисплея. Для битовых значений '11' пиксельные данные записываются во все буферы изображения. Битовые значения или комбинация '10' обрабатываются как недействительное значение или обозначение, и пиксельные данные игнорируются и не записываются в какой-либо из буферов изображения. Это значение может быть использовано для будущих применений интерфейса.
Биты 8-11 используются, чтобы определить альтернативный дисплей или местоположение дисплея, куда пиксельные данные должны быть направлены. Биты 0 и 1 установлены равными '00' для того, чтобы клиент дисплея интерпретировал биты 8-11 как номер альтернативного дисплея. Если биты 0 и 1 не равны '00', тогда биты 8-11 установлены равными уровню логического нуля.
Биты 13 и 12 используются, чтобы определить, должны ли быть пиксели адресата записаны в местоположения адресата, когда они относятся к прозрачному цвету и прозрачной маске. Для битов [13:12], имеющих значение или равных 00 (два уровня логического нуля), прозрачный цвет не используется. Результирующий пиксель адресата записывают в местоположение пикселя адресата без рассмотрения значения прозрачного цвета или прозрачной маски. Прозрачный цвет определяется пакетом «Разрешение прозрачного цвета», описанным в другом месте. Значение 01 (уровни логический нуль, логическая единица) для битов [13:12] представляет или является зарезервированным значением, отложенным в настоящее время для будущего использования, и обычно не используется. Когда биты [13:12] имеют значение 10 (уровни логическая единица, логический нуль), результирующий пиксель адресата записывают в местоположение пикселя адресата, если только результат выполнения логической операции И над пикселем изображения источника и прозрачной маской не равен прозрачному цвету, тогда результирующий пиксель не записывают в местоположение пикселя адресата. Когда биты [13:12] имеют значение 11 (две логические единицы), результирующий пиксель адресата не записывают в местоположение пикселя адресата, если только результат выполнения логической операции И над пикселем изображения источника и прозрачной маской не равен прозрачному цвету, в этом случае результирующий пиксель записывают в местоположение пикселя адресата.
Бит 14 зарезервирован для будущего использования и обычно устанавливается равным уровню логического нуля. Бит 15, как описано, используется вместе с битом 5, и установка бита 15 в логическую единицу указывает, что строка пикселей в поле «Пиксельные данные» является последней строкой пикселей в кадре данных. Следующий пакет «Поток Видео», имеющий бит 5, установленный равным логической единице, будет соответствовать первой строке пикселей следующего кадра видео.
2-байтовые поля "X Начала" и "Y Начала" определяют абсолютные координаты X и Y точки (X Начала, Y Начала) для первого пикселя в поле «Пиксельные данные». 2-байтовые поля "X Левой границы", "Y Верхней границы" определяют координату X левой границы и координату Y верхней границы экранного окна, заполненного полем «Пиксельные данные», в то время как поля "X Правой границы" и "Y нижней границы" определяют координату X правой границы и координату Y нижней границы обновляемого окна.
Поле Pixel Count (Количество пикселей) (2 байта) задает число пикселей в поле «Пиксельные данные» ниже.
Поле «Параметр CRC» (2 байта) содержит CRC всех байтов от "Длина пакета" до «Количество Пикселей». Если этот CRC дает сбой при проверке, тогда весь пакет отвергается.
Поле «Пиксельные данные» содержит необработанную информацию видео, которая должна быть отображена и которая отформатирована способом, описанным полем Video Data Format Descriptor (Дескриптор формата данных видео). Данные передают по одной "строке" за раз, как описано в настоящем описании. Когда бит 5 поля Pixel Data Attributes установлен равным уровню логической единицы, тогда поле «Пиксельные данные» содержит точно одну строку пикселей, причем первый передаваемый пиксель соответствует наиболее левому пикселю и последний передаваемый пиксель соответствует наиболее правому пикселю.
Поле «CRC пиксельных данных» (2 байта) содержит 16-битовый CRC только пиксельных данных. Если проверка кода CRC для этих значений дает ошибку, тогда пиксельные данные все еще могут использоваться, но значение подсчета ошибочных кодов CRC увеличивается.
B. Для пакетов «Поток аудио»
В одном варианте осуществления поле Audio Channel ID (Идентификатор канала аудио) (1 байт) использует 8 битовое целое значение без знака, чтобы идентифицировать конкретный аудиоканал, к которому аудиоданные посылают клиентским устройством. Физические аудиоканалы заданы в или отображены на физические каналы с помощью этого поля как значения 0, 1, 2, 3, 4, 5, 6 или 7, которые указывают левый передний, правый передний, левый задний, правый задний, передний центральный, суб-вуферный громкоговоритель, левый окружающего звука и правый окружающего звука каналы соответственно. Значение 254 "Идентификатора канала аудио" указывает, что единственный поток выборок цифровых аудиовыборок послан и в левый передний, и правый передний каналы. Это упрощает обмены для приложений типа таких, где головной стереотелефон используется для речевого обмена, применения расширения производительности, которые используются на PDA, или других применений, где простой пользовательский интерфейс генерирует сигналы предупреждения. Значения для поля идентификатора, изменяющиеся в пределах от 8 до 253 и 255, в настоящее время зарезервированы для использования, где новые конструктивные решения требуют дополнительных обозначений, как предполагается специалистами в данной области техники.
Поле "Зарезервированное 1" (1 байт) обычно резервируется для будущего использования и имеет все биты в этом поле, установленные равными нулю. Одна из функций этого поля должна заставить все последующие 2-байтовые поля быть выровненными к 16-битовому адресу слова и заставить 4-байтовые поля быть выровненными к 32-битовому адресу слова.
Поле Audio Sample Count (Количество выборок аудио) (2 байта) определяет количество выборок аудио в этом пакете.
Поле "Битов на выборку и упаковку" содержат 1 байт, который определяет формат упаковки аудиоданных. В одном варианте осуществления формат, обычно используемый, предназначен для битов 4-0, которые должны определить количество битов в расчете на ИКМ выборку аудио. Бит 5 затем задает, упакованы или нет выборки "Цифровые данные аудио". Как упомянуто выше, Фиг.12 иллюстрирует различие между упакованными и выровненными по границе байта выборками аудио. Значение '0' для бита 5 указывает, что каждая ИКМ выборка аудио в поле "Цифровые данные аудио" является выровненной по границе байте с границей байта интерфейса, и значение '1' указывает, что каждая последующая ИКМ выборка аудио является упакованной рядом с предыдущей аудиовыборкой. Этот бит является действующим, только когда значение, определенное в битах 4-0 (количество битов в расчете на ИКМ выборку аудио), не является кратным восьми. Биты 7-6 зарезервированы для использования, где конструкции систем требуют дополнительных обозначений, и обычно устанавливаются равными значению нуля.
Поле Audio Sample Rate "Частота аудиовыборки" (1 байт) задает частоту ИКМ выборки аудио. Этот используемый формат имеет значение 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 увеличивается.
C. Для пакетов "Поток, определяемый пользователем"
В одном варианте осуществления 2-байтовое поле "Номер идентификатора потока" (Stream ID Number) используется, чтобы идентифицировать конкретный определяемый пользователем поток. Содержание полей "Параметры потока" и "Данные потока" обычно определяется изготовителем оборудования MDDI. 2-байтовое поле "CRC параметра потока" содержит 16-битовый CRC всех байтов параметров потока, начиная от "Длина пакета" до байта "Кодирование аудио". Если этот CRC дает ошибку при проверке, то весь пакет отвергается. Оба поля "Параметры потока" и "CRC параметра потока" могут быть отвергнуты, если не являются необходимыми конечному приложению MDDI, то есть они рассматриваются необязательными. 2-байтовое поле "CRC данных потока" содержит CRC только данных потока. Если этот CRC дает ошибку при проверке соответственно, то использование данных потока необязательно, в зависимости от требований приложения. Использование совокупности данных потока в отношении CRC, который является хорошим, обычно требует, чтобы данные потока были буферизированы, пока CRC не будет подтвержден как хороший. Значение подсчета ошибочных кодов CRC увеличивается, если CRC выдает ошибку.
D. Для пакетов "Карта Цвета"
2-байтовое поле hClient ID ("Идентификатор клиента") содержит информацию или значения, которые зарезервированы для идентификатора клиента, как используется выше. Так как это поле обычно резервируется для будущего использования, текущее значение установлено равным нулю посредством установки битов в '0'.
2-байтовое поле Color Map Item Count ("Количество элементов карты цвета") использует значения для задания общего количества 3-байтовых элементов карты цвета, которые содержатся в поле "Данные карты цвета" или записях таблицы карты цвета, которые существуют в "Данных карты цвета" в этом пакете. В этом варианте осуществления количество байтов в "Данных карты цвета" равно 3х кратному значению " Количество элементов карты цвета". Значение "Количество элементов карты цвета" установлено равным нулю, чтобы не посылать данных карты цвета. Если "Размер карты цвета" равен нулю, тогда значение Color Map Offset ("Смещение карты цвета") обычно все еще посылается, но оно игнорируется дисплеем. Поле "Смещение карты цвета" (4 байта) определяет смещение "Данных карты цвета" в этом пакете от начала таблицы карты цвета в клиентском устройстве.
2-байтовое поле "Параметр CRC" содержит CRC всех байтов от "Длина пакета" до байта "Кодирование аудио". Если этот CRC дает ошибку при проверке, то весь пакет отвергается.
Для поля "Данные карты цвета" ширина каждого местоположения карты цвета указывается полем Color Map Item Size ("Размер элемента карты цвета"), где в одном варианте осуществления первая часть определяет значение синего, вторая часть определяет значение зеленого и третья часть определяет значение красного. Поле Color Map Size ("Размер карты цвета") задает количество 3-байтовых элементов таблицы карты цвета, которые существуют в поле "Данные карты цвета". Если одна карта цвета не может быть вписана в один пакет "Формат видеоданных и карты цвета", то полная карта цвета может быть определена, посылая множество пакетов с различными "Данными карты цвета" и "Смещение карты цвета" в каждом пакете. Количество битов синего, зеленого и красного в каждом элементе данных карты цвета обычно является таким же, как определено в поле "Ширина Карты цвета RGB" в пакете "Возможности дисплея".
2-байтовое поле "CRC Данных карты цвета" содержит CRC только "Данных карты цвета". Если этот CRC дает ошибку при проверке, то "Данные карты цвета" все еще могут использоваться, но значение подсчета ошибочных кодов CRC увеличивается.
Каждый элемент данных карты цвета должен быть передан в порядке: синий, зеленый, красный, причем наименьший значащий бит каждого компонента передается первым. Отдельные красные, зеленые и синие компоненты каждого элемента карты цвета упакованы, но каждый элемент карты цвета (наименьший значащий бит компонента синего) должен быть выровненным по границе байта. Фиг.97 иллюстрирует пример элементов данных карты цвета с 6 битами синего, 8 битами зеленого и 7 битами красного. Для этого примера "Размер элемента карты цвета" в пакете «Карта цвета» равен 21 и поле "Ширина карты цвета RGB" в пакете "Возможности клиента" равно 0x0786.
E. Для пакетов «Инкапсуляция обратной линии связи»
Поле "Параметр CRC" (2 байта) содержит 16-битовый CRC всех байтов от "Длина пакета" до "Длина изменения на противоположное". Если этот CRC дает ошибку при проверке, то весь пакет отвергается.
В одном варианте осуществления поле "Флаги обратной линии связи" (1 байт) содержат набор флагов, чтобы запросить информацию от клиента и определить тип обратной линии связи. Если бит (например, бит 0) установлен равным уровню логической единицы, то ведущее устройство запрашивает указанную информацию от клиента, но если бит установлен равным уровню логического нуля, тогда ведущее устройство не нуждается в информации от клиента. Бит 0 используется, чтобы указать, когда ведущее устройство требует пакет «Возможности клиента», который обычно посылается клиентом ведущему устройству в поле Reverse Data Packets ("Пакеты данных обратной линии связи»). Бит 1 используется, чтобы указать, когда ведущее устройство требует пакет «Запрос клиента и состояния", который посылается клиентом ведущему устройству в поле Reverse Data Packets. Оставшиеся биты (здесь биты 2-7) зарезервированы для будущего использования и установлены равными нулю. Однако может использоваться больше битов при необходимости, чтобы установить флаги для обратной линии связи.
Поле Reverse Rate Divisor (Делитель скорости передачи обратной линии связи) (1 байт) определяет количество тактов MDDI_Stb, которые имеют место в отношении синхросигнала данных обратной линии связи. Частота синхронизации данных обратной линии связи равна частоте синхронизации данных прямой линии связи, деленной на удвоенный Делитель скорости передачи обратной линии связи. Скорость передачи данных обратной линии связи относится к частоте синхронизации данных обратной линии связи и типу интерфейса на обратной линии связи. В этом варианте осуществления для интерфейса Типа 1 скорость передачи данных обратной линии связи равняется такту синхронизации обратной линии связи, для интерфейсов Типа 2, Типа 3 и Типа 4 скорости передачи данных обратной линии связи равняются удвоенному, учетверенному и умноженному на восемь сигналу синхронизации данных обратной линии связи соответственно.
Поле "Все нули 1" содержит группу байтов, здесь 8, значение которых установлено равным нулю посредством установки битов равными логическому нулю, и используется, чтобы гарантировать, что все сигналы MDDI_Data имеют уровень логического нуля в течение достаточного времени, чтобы разрешить клиенту начинать восстанавливать синхронизацию, используя только MDDI_Stb, до отключения задающих устройств линии ведущего устройства в течение поля Turn-Around 1. В одном варианте осуществления длина поля "Все нули 1" больше или равна числу времен передачи байта по прямой линии связи при задержке во времени передачи сигнала в прямом и обратном направлениях по кабелю.
Поле "Длина Изменение на противоположное 1" (1 байт) задает общее количество байтов, которые выделены для поля Turn-Around 1 ("Длина Изменения на противоположное 1"), устанавливая первый период изменения на противоположное. Поле "Turn-Around 1" использует количество байтов, заданных параметром "Длина изменения на противоположное 1", которые назначены, чтобы позволить разрешить задающие устройства линии MDDI_Data в клиенте, прежде чем задающие устройства линии в ведущем устройстве будут запрещены. Клиент разрешает свои задающие устройства линии MDDI_Data в течение бита 0 поля Turn-Around 1, и ведущее устройство отключает свои выходные сигналы так, чтобы быть полностью запрещенным до последнего бита поля Turn-Around 1. Сигнал MDDI_Stb ведет себя, как если бы MDDI_Data0 имели уровень логического нуля в течение всего периода Turn-Around 1. Более полное описание процедуры установки поля Turn-Around 1 приведено выше.
Поле Reverse Data Packets ("Пакеты данных обратной линии связи") содержит последовательность пакетов данных, переданных от клиента на ведущее устройство. Клиент может посылать пакеты-заполнители или возбуждать линии MDDI_Data до состояния или уровня логического нуля, когда он не имеет никаких данных для посылки ведущему устройству. В этом варианте осуществления, если линии MDDI_Data возбуждаются до уровня нуля, ведущее устройство интерпретирует это как пакет с нулевой длиной (недействительная длина) и ведущее устройство не принимает никаких дополнительных пакетов от клиента в течение длительности текущего пакета «Инкапсуляция обратной линии связи».
Поле "Длина Изменения на противоположное 2" (Turn-Around 2) (1 байт) определяет общее количество байтов, которые распределены для Turn-Around 2, для установления второго периода Изменения на противоположное. Рекомендуемая длина Turn-Around 2 равно количеству байтов, требуемых для задержки прохождения сигнала в прямом и обратном направлениях плюс время, требуемое ведущему устройству, чтобы разрешить его задающие устройства MDDI_Data. "Длина Изменение на противоположное 2" может быть также значением, большим, чем минимально требуемое или вычисленное значение, чтобы обеспечить достаточное время для обработки пакетов обратной линии связи в ведущем устройстве.
Поле Turn-Around 2 (Изменение на противоположное 2) состоит из количества байтов, которое задано параметром "Длина Изменения на противоположное 2". Ведущее устройство ожидает по меньшей мере время задержки прохождения сигнала в прямом и обратном направлениях, прежде чем оно разрешает свои задающие устройства линии MDDI_Data в течение Turn-Around 2. Ведущее устройство разрешает свои задающие устройства линии MDDI_Data так, что они обычно полностью разрешены до последнего бита Turn-Around 2, и клиент запрещает свои выводы так, чтобы они обычно были полностью запрещены до последнего бита Turn-Around 2. Цель поля Turn-Around 2 состоит в том, чтобы разрешить передачу или передать оставшееся количество данных поля Reverse Data Packets от клиента. При изменениях в различных системах, реализующих интерфейс, и в величине распределенного коэффициента запаса, возможно, что ни ведущее устройство, ни клиент не будет возбуждать сигналы MDDI_Data до уровня логического нуля в течение некоторых частей периода поля Turn-Around 2, как можно видеть, посредством приемников линии в или на ведущем устройстве. Сигнал MDDI_Stb ведет себя так, как если бы MDDI_Data0 был равен уровню логического нуля в течение по существу всего периода Turn-Around 2. Описание установки Turn-Around 2 приведено выше.
Поле Reverse Data Packets ("Пакеты данных обратной линии связи") содержит последовательность пакетов данных, передаваемых от клиента на ведущее устройство. Как указано выше, пакеты-заполнители посылают, чтобы заполнить остающееся пространство, которое не используется другими типами пакета.
Поле All Zeros 2 (Все нули 2) содержит группу байтов (8 в этом варианте осуществления), значения которых установлены равными нулю посредством установки битов равными логическому нулю, и используется, чтобы гарантировать, что все сигналы MDDI_Data равны логическому нулю в течение достаточного времени, чтобы разрешить клиенту начать восстанавливать синхронизацию, используя оба MDDI_Data0 и MDDI_Stb после разрешения задающих устройств линии ведущего устройства после поля Turn-Around 2.
F. Для пакетов «Возможности клиента»
Как иллюстрировано для одного варианта осуществления, поле Protocol Version (Версия протокола) использует 2 байта, чтобы задать версию протокола, используемую клиентом. Начальная версия в настоящее время установлена равной единице и будет изменена через какое-то время, поскольку создаются новые версии, как может быть известно, в то время как поле Minimum Protocol Version (Минимальная версия протокола) использует 2 байта, чтобы задать минимальную версию протокола, которую клиент может использовать или интерпретировать. В этом случае нулевое значение также является действительным значением. Поле Pre-Calibration Data Rate Capability (Возможность скорости передачи данных до калибровки) (2 байта) задает максимальную скорость передачи данных, с которой клиент может принимать на каждой паре данных по прямой линии связи до выполнения калибровки сдвига во времени прямой линии связи, и задается в форме миллионов бит в секунду (Мбит/с). Если клиент поддерживает пакет «Калибровка сдвига во времени прямой линии связи", тогда значение в поле Post-Calibration Data Rate Capability указывает скорость передачи данных, которую клиент способен обеспечить после выполнения калибровки сдвига во времени.
В одном варианте осуществления поле Interface Type Capability (Возможность типа интерфейса) (1 байт) задает типы интерфейса, которые поддерживаются на прямой и обратной линиях связи. Бит, установленный в '1', указывает, что заданный тип интерфейса поддерживается, и бит, установленный в '0', указывает, что заданный тип не поддерживается. Ведущие устройства и клиенты должны поддерживать по меньшей мере Тип 1 на прямой и обратной линиях связи. Не имеется никаких требований поддерживать непрерывный диапазон типов интерфейса. Например, может быть совершенно действительным, чтобы поддерживать только Тип 1 и Тип 3, но не Тип 3 и Тип 4 в интерфейсе. Также не является необходимым для прямой и обратной линий связи работать с одним и тем же типом интерфейса. Однако, когда линия связи выходит из состояния бездействия, и прямая, и обратная линии связи должны начать работу в режиме Типа 1, пока другие режимы не могут быть согласованы, выбраны или иным образом одобрены для использования и ведущим устройством и клиентом.
Поддерживаемые интерфейсы обозначены в одном варианте осуществления посредством выбора бита 0, бита 1 или бита 2 для выбора режима или Типа 2 (2 бит), Типа 3 (4 бит) или Типа 4 (8 бит) на прямой линии связи соответственно; и бита 3, бита 4 или бита 5 для выбора режима или Типа 2, Типа 3 или Типа 4 на обратной линии связи соответственно; с битами 6 и 7, зарезервированными и обычно установленными равными нулю в настоящее время.
В одном варианте осуществления поле Number Alt Displays (Количество альтернативных дисплеев) в пакете "Возможности клиента"" использует 1 байт, значение которого может изменяться от 0 до 16, со значениями от 17 - 255, обычно зарезервированными для будущего использования и не используемыми, чтобы указывать или сообщать, что подключено более одного дисплея, и пакет «Возможности альтернативного дисплея" сообщает о возможности каждого дополнительного дисплея. Поле Number Alt Displays использует 1 байт, чтобы указать идентификационную информацию альтернативного дисплея, причем первый альтернативный дисплей обычно обозначается как номер 0, а другие альтернативные дисплеи идентифицируются уникальными значениями поля Alt Display Number, где наибольшее используемое значение является общим количеством альтернативных дисплеев минус 1 (начиная со значения 0).
Поле Post-Calibration Data Rate Capability (Возможность скорости передачи данных после калибровки) использует 2 байта в одном варианте осуществления, чтобы задать максимальную скорость передачи данных, с которой клиент может осуществлять прием на каждой паре данных на прямой линии связи MDDI после выполнения калибровки сдвига во времени прямой линии связи. Эта скорость передачи также определяется в миллионах битов в секунду (Мбит/с). Если клиентское устройство не поддерживает пакет «Калибровка сдвига во времени прямой линии связи», тогда это поле установлено равным нулевому значению.
Поля Bitmap Width и Height (Высота и ширина битовой карты), здесь каждое имеющее 2 байта, определяют ширину и высоту битовой карты, соответственно, в пикселях. Поле Display Window Width (Ширина окна дисплея) использует 2 байта, которые определяют ширину окна на экране дисплея, выраженную как количество пикселей.
Поле Display Window Height (Высота окна дисплея) использует 2 байта, которые задают высоту окна на экране дисплея, выраженную как количество пикселей.
Поле Color Map Size (Размер карты цвета) использует 4 байта для задания максимального количества элементов таблицы, которые существуют в таблице карты цвета в клиенте. Если клиент не может использовать формат карты цвета, тогда это значение установлено равным нулю.
Поле Color Map RGB Width (Ширина карты цвета RGB) использует 2 байта, которые задают количество битов компонентов красного, зеленого и синего цвета, которые могут быть отображены в режиме отображения Карты цвета (палитры). Максимум 8 битов для каждого компонента цвета (красного, зеленого и синего) может использоваться. Даже при том, что 8 битов компонента каждого цвета посылают в пакете «Карта цвета», используется только ряд наименьших значащих битов компонента каждого цвета, определенного в этом поле. Если клиент дисплея не может использовать формат карты цвета (палитры), тогда это значение равно нулю.
Поле RGB Capability (Возможность RGB) (2 байта) определяет количество битов разрешения, которые могут быть отображены в формате RGB. Если дисплей не может использовать формат RGB, тогда это значение равно нулю. Слово RGB Capability состоит из трех отдельных значений без знака, где: биты 3-0 задают максимальное количество битов синего, биты 7-4 определяют максимальное количество битов зеленого и биты 11-8 определяют максимальное количество битов красного в каждом пикселе. В настоящее время биты 14-12 зарезервированы для будущего использования и обычно устанавливаются равными нулю. Биты 14-12 зарезервированы для будущего использования и обычно устанавливают равными нулю. Бит 15, когда установлен равным уровню логической единицы, указывает, что клиент может принимать пиксельные данные RGB или в упакованном, или неупакованном формате. Если бит 15 установлен равным уровню логического нуля, это указывает, что клиент может принимать RGB пиксельные данные только в неупакованном формате.
Поле Monochrome Capability (Возможность монохромного изображения) (1 байт) используется в одном варианте осуществления для того, чтобы определить количество битов разрешения, которые могут быть отображены в одноцветном (монохромном) формате. Если дисплей не может использовать одноцветный формат, тогда это значение установлено в нуль. Биты 7-4 зарезервированы для будущего использования и, таким образом, установлены равными нулю. Биты 3-0 определяют максимальное количество битов полутонов, которые могут существовать для каждого пикселя. Эти четыре бита дают возможность задать значения от 1 до 15 для каждого пикселя. Если это значение нулевое, тогда одноцветный формат не поддерживается дисплеем.
Поле Y Cr Cb Capability (Возможность Y Cr Cb - представления) (2 байта) определяет количество битов разрешения, которые могут быть отображены в формате Y Cr Cb. Если дисплей не может использовать формат YCr Cb, тогда это значение установлено равным нулю. Слово Y Cr Cb Capability состоит из трех отдельных значений без знака, где: биты 3-0 определяют максимальное количество битов в выборке Cb, биты 7-4 определяют максимальное количество битов в выборке Cr, биты 11-8 определяют максимальное количество битов в выборке Y, и биты 15-12 в настоящее время зарезервированы для будущего использования и установлены равными нулю.
Поле Bayer Capability (Возможность формата Байера) использует 1 байт, чтобы определить количество битов разрешения, группы пикселей и порядок пикселей, которые могут быть переданы в формате Байера. Если клиент не может использовать формат Байера, тогда это значение нулевое. Поле "Возможность формата Байера" состоит из следующих значений: биты 3-0 определяют максимальное количество битов интенсивности (яркости), которые существуют в каждом пикселе, в то время как биты 5-4 определяют шаблон группы пикселей, который требуется, в то время как биты 8-6 задают упорядоченность пикселей, который требуется; причем биты 14-9 зарезервированы для будущего использования и обычно устанавливают равными нулю в настоящее время. Бит 15, когда установлен равным уровню логической единицы, указывает, что клиент может принимать пиксельные данные Байера или в упакованном или неупакованном формате. Если бит 15 установлен равным нулю, это указывает, что клиент может принимать пиксельные данные Байера только в неупакованном формате.
В одном варианте осуществления поле Client Feature Capability (Возможности характеристик клиента) использует 4 байта в одном варианте осуществления, которые содержат набор флагов, которые указывают конкретные особенности в клиенте, которые поддерживаются. Бит, установленный равным уровню логической единицы, указывает, что эта возможность поддерживается, в то время как бит, установленный равным уровню логического нуля, указывает, что эта возможность не поддерживается. В одном варианте осуществления значение для бита 0 указывает, поддерживается ли пакет «Поблочная пересылка битовой карты» (тип пакета 71). Значение для битов 1, 2 и 3 указывает, поддерживаются ли пакет «Заполнение области битовой карты» (тип пакета 72), пакет «Заполнение шаблона битовой карты» (тип пакета 73) или пакет «Буфер кадра считывания» (тип пакета 74) соответственно. Значение для бита 4 указывает, имеет ли клиент возможность поддерживать пакет «Установка прозрачного цвета и маски», в то время как значения для битов 5 и 6 указывают, может ли клиент принимать аудиоданные в распакованном или упакованном формате соответственно, и значение для бита 7 указывает, может ли клиент посылать поток видео обратной линии связи от камеры. Значение для бита 8 указывает, имеет ли клиент функциональную возможность принимать полную строку пиксельных данных и игнорировать адресацию дисплея, которая определяется битом 5 поля Pixel Data Attributes (Атрибуты пиксельных данных) в пакете «Поток видео», и клиент может также обнаруживать синхронизацию кадра или конец данных кадра видео, используя бит 15 поля «Атрибуты пиксельных данных».
Значение бита 9 указывает, имеет ли клиент способность интерпретировать пакет «Запрос конкретного состояния» и отвечать пакетом «Список ответа о действительном состоянии». Клиент может указывать способность возвратить дополнительный статус в поле «Список ответа о действительных параметрах» в пакете «Список ответа о действительном состоянии», как описано выше. Значение бита 10 указывает, имеет ли клиент способность поддерживать состояние 1 потребления мощности дисплеем. Состояние потребления энергии дисплеем устанавливается с использованием битов [3:2] поля Power State (Состояние потребления энергии) пакета «Состояние потребления мощности дисплеем», описанного выше. Состояние 1 потребления мощности дисплеем является состоянием, когда выбранный дисплей не подсвечивается и потребляет минимальное количество мощности, если таковое обычно имеется, и обычно гарантируется, что содержание буфера кадра будет сохранено в течение этого состояния.
Значение для битов 11 и 12 указывает, когда клиент обменивается или с устройством указания и может посылать и принимать пакеты «Данные устройства указания», или с клавиатурой и может посылать и принимать пакеты «Данные клавиатуры» соответственно. Значение для бита 13 указывает, имеет ли клиент способность установить один или более параметров аудио или видео, поддерживая пакеты с характеристиками VCP: пакет «Запрос характеристик VCP, пакет "Ответ с характеристиками VCP, пакет "Установка характеристик VCP", пакет «Запрос действительных параметров» и пакет «Ответ о действительных параметрах». Значение для бита 14 указывает, имеет ли клиент способность записывать пиксельные данные в автономный буфер кадров дисплея, который проиллюстрирован на Фиг.88A. Если этот бит установлен равным уровню логической единицы, тогда биты «Обновление дисплея» (биты 7 и 6 поля Pixel Data Attributes в пакете «Поток видео») могут быть установлены равными значению '01'.
Значение для бита 15 указывает, когда клиент имеет способность записывать пиксельные данные только в буфер кадра дисплея, в настоящее время используемый, чтобы обновить отображаемое изображение, что проиллюстрировано на Фиг.88B. Если этот бит установлен в логическую единицу, тогда биты «Обновление дисплея» (биты 7 и 6 из поля Атрибуты пиксельных данных в пакете «Поток видео») могут быть установлены равными значению '00'. Значение для бита 16 указывает, когда клиент имеет способность записывать пиксельные данные из единственного пакета «Поток видео» во все буферы кадра дисплея, что проиллюстрировано на Фиг.88C. Если этот бит установлен равным уровню логической единицы, тогда биты обновления дисплея (биты 7 и 6 из поля Атрибуты пиксельных данных в пакете «Поток видео») могут быть установлены равными значению '11'.
В одном варианте осуществления значение для бита 17 указывает, когда клиент имеет способность ответить на пакет «Запрос конкретного состояния», значение для бита 18 указывает, когда клиент имеет способность ответить на пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях", и значение для бита 19 указывает, когда клиент имеет способность ответить на пакет «Калибровка сдвига во времени прямой линии связи». В одном варианте осуществления значение для бита 20 указывает, когда клиент имеет способность отвечать на пакет «Состояние потребления мощности дисплеем».
В одном варианте осуществления значение для бита 21 указывает, когда клиент имеет способность использовать поле Raster Operation (Растровая операция) пакет «Заполнение области битовой карты» (тип пакета 72), пакет «Заполнение шаблона битовой карты» (тип пакета 73) или пакет «Буфер кадра считывания» (тип пакета 74), если эти пакеты поддерживаются клиентом, как задано битами 0, 1 и 2 или этим полем. В одном варианте осуществления, если бит 21 имеет уровень или значение логического нуля и пакеты поддерживаются, то клиент не обладает способностью использовать поле Raster Operation и клиент только обладает способностью копировать или осуществлять запись в местоположения пикселей, указанные этими пакетами.
Значение для бита 22 указывает, имеет ли клиент способность отвечать на пакет «Доступ к регистрам». Биты 23-31 в настоящее время зарезервированы для будущего использования или альтернативных обозначений, используемых для системных проектировщиков, и обычно устанавливаются равными нулевому значению или уровню логического нуля.
Поле Minimum Sub-frame Rate (Минимальная частота под-кадров) (2 байта) определяет минимальную частоту под-кадров в кадрах в секунду. Минимальная частота под-кадров сохраняет период обновления состояния клиента, достаточный для считывания некоторых датчиков или устройств указания в клиенте.
Поле Audio Buffer Depth (Глубина аудиобуфера) (2 байта) определяет глубину адаптируемого буфера в дисплее, который выделен каждому аудиопотоку.
Поле Audio Channel Capability (Возможность аудиоканала), в этом варианте осуществления использующее 2 байта, содержит группу флагов, которые указывают, какие аудиоканалы поддерживаются клиентом или соединенным с клиентом устройством. Бит, установленный равным единице, указывает, что канал поддерживается, и бит, установленный равными нулю, указывает, что канал не поддерживается. Битовые позиции назначены различным каналам, например, битовые позиции 0, 1, 2, 3, 4, 5, 6 и 7 в одном варианте осуществления указывают левый передний, правый передний, левый задний, правый задний, передний центральный, суб-вуферный, левый окружающего звука и правый окружающего звука каналы соответственно. Биты 8-14 в настоящее время зарезервированы для будущего использования и обычно устанавливаются равными нулю. В одном варианте осуществления бит 15 используется, чтобы указать, обеспечивает ли клиент поддержку пакета «Разрешение канала аудио прямой линии связи". В этом случае бит 15 установлен равным уровню логической единицы. Если, однако, клиент не способен к запрещению аудиоканалов в результате пакета «Разрешение канала аудио прямой линии связи" или если клиент не поддерживает аудиовозможность, то этот бит установлен равным уровню или значению логического нуля.
2-байтовое поле Audio Sample Rate Capability (Возможность частоты выборки аудио) для прямой линии связи содержит набор флагов, чтобы указать возможность клиентского устройства в отношении частоты выборки аудио. Битовые позиции назначены различным скоростям соответственно, например, биты 0, 1, 2, 3, 4, 5, 6, 7 и 8 назначены частоте 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050 и 44100 выборок в секунду (в/с) соответственно, причем биты 9-15 зарезервированы для будущих или альтернативных применений частоты, как требуется, так что они в настоящее время установлены равными '0'. Установка значения бита для одного из этих битов в '1' указывает, что эта конкретная частота выборки поддерживается, и установка бита в '0' указывает, что эта конкретная частота выборки не поддерживается.
2-байтовое поле Audio Sample Resolution (Разрешение аудиовыборки) для прямой линии связи определяет количество битов на выборку аудио, которые посланы клиенту в пакете «Поток аудио".
2-байтовое поле Mic Audio Sample Resolution (Разрешение аудиовыборки микрофона) для обратной линии связи задает количество битов на аудиовыборки, которые посланы ведущему устройству микрофоном в пакете «Поток аудио».
2-байтовое поле Mic Sample Rate Capability (Возможность частоты выборки микрофона) для обратной линии связи содержит набор флагов, которые указывают на возможность, относящуюся к частоте выборки аудиомикрофона в клиентском устройстве. Для целей MDDI микрофон клиентского устройства конфигурирован так, чтобы минимально поддерживать по меньшей мере частоту 8000 выборок в секунду. Битовые позиции для этого поля назначены различным частотам с битовыми позициями 0, 1, 2, 3, 4, 5, 6, 7 и 8, например, используемыми, чтобы представить 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050 и 44100 выборок в секунду (в/с) соответственно, при этом биты 9-15 зарезервированы для будущих или альтернативных применений частоты, как требуется, так что они в настоящее время установлены равными '0'. Установка значения бита для одного из этих битов в '1' указывает, что эта конкретная частота выборки поддерживается, и установка бита в '0' указывает, что эта конкретная частота выборки не поддерживается. Если никакой микрофон не подсоединен, тогда каждый из битов Mic Sample Rate Capability установлен равным нулю.
Поле Keyboard Data Format (Формат данных клавиатуры) (здесь 1 байт) определяет, соединена ли клавиатура с клиентской системой, и тип клавиатуры, которая подсоединена. В одном варианте осуществления значение, установленное битами 6-0, используется для определения типа клавиатуры, которая подсоединена. Если значение равно нулю (0), тогда тип клавиатуры рассматривается как неизвестный. Для значения 1 формат данных клавиатуры рассматривается как стандартный тип PS-2. В настоящее время значения в диапазоне от 2 до 125 не используются, будучи зарезервированными для использования системными проектировщиками и разработчиками интерфейса или разработчиками продуктов, чтобы определить конкретную клавиатуру или устройства ввода данных для использования с MDDI и соответствующими клиентами или ведущими устройствами. Значение 126 используется для указания, что формат данных клавиатуры является задаваемым клиентом, в то время как значение 127 используется для указания, что клавиатура не может быть соединена с этим клиентом. Кроме того, бит 7 может использоваться для указания, может ли клавиатура обмениваться с клиентом. Предназначенное использование этого бита должно указать, когда клавиатура может обмениваться с клиентом, используя беспроводную линию. Бит 7 может быть установлен равным нулевому уровню, если биты 6-0 указывают, что клавиатура не может быть соединена с клиентом. Поэтому для одного варианта осуществления, когда значение бита 7 есть 0, клавиатура и клиент не могут обмениваться, в то время как если значение бита 7 есть 1, клавиатура и клиент подтверждают, что они могут связываться друг с другом.
Поле Pointing Device Data Format (Формат данных устройства указания) (здесь 1 байт) определяет, соединено ли устройство указания с клиентской системой, и тип устройства указания, которое подсоединено. В одном варианте осуществления значение, установленное битами 6-0, используется, чтобы определить тип устройства указания, которое подсоединено. Если это значение нулевое (0), тогда тип устройства указания рассматривается как неизвестный. Для значения 1 формат данных устройства указания рассматривается как являющийся стандартным типом PS-2. В настоящее время значения в диапазоне от 2 до 125 не используются, будучи зарезервированными для использования системными проектировщиками и разработчиками интерфейса или разработчиками продуктов, чтобы определить конкретное устройство указания или устройство ввода данных для использования с MDDI и соответствующими клиентами или ведущими устройствами. Значение 126 используется для указания того, что формат данных устройства указания определяем клиентом, в то время как значение 127 используется для указания того, что устройство указания не может быть соединено с этим клиентом. Кроме того, бит 7 может использоваться, чтобы указать, может ли устройство указания обмениваться с клиентом. Назначенное использование этого бита должно указывать, когда клавиатура может обмениваться с клиентом, используя беспроводную линию. Бит 7 может быть установлен равным нулевому уровню, если биты 6-0 указывают, что устройство указания не может быть соединено с клиентом. Поэтому для одного варианта осуществления, когда значение бита 7 есть 0, устройство указания и клиент не могут обмениваться, в то время как, если значение бита 7 есть 1, устройство указания и клиент подтверждают, что они могут обмениваться друг с другом.
Поле Content Protection Type (Тип защиты контента) (2 байта) содержит набор флагов, которые указывают тип цифровой защиты контента, которая поддерживается дисплеем. В настоящее время битовая позиция 0 используется для указания, когда поддерживается DTCP, и битовая позиция 1 используется для указания, когда поддерживается HDCP, при этом битовые позиции 2-15 зарезервированы для использования с другими схемами защиты, как это требуется или доступно, так что они в настоящее время установлены равными нулю.
Поле Mfr Name (Наименование производителя) (здесь 2 байта) содержит 3-символьный EISA-идентификатор производителя, упакованного в три 5-битовых символа таким же образом, как в спецификации EDID VESA. Буква 'A' представлена как 00001 в двоичном виде, буква 'Z' представлена как 11010 в двоичном виде, и все буквы между 'А' и 'Z' представлены как последовательные двоичные значения, которые соответствуют алфавитной последовательности между 'А' и 'Z'. Старший значащий бит поля Mfr Name является неиспользуемым и обычно устанавливается в настоящее время в логический нуль, до тех пор пока не будет использован в будущих реализациях. Например, изготовитель, представленный строкой "XYZ", будет иметь значение Mfr Name, равное 0x633a. Если это поле не поддерживается клиентом, оно обычно устанавливается равным нулю. Поле Product Code (код продукта) использует 2 байта, содержащие код продукта, назначенный производителем дисплея. Если это поле не поддерживается клиентом, оно обычно устанавливается равным нулю.
Поля Зарезервированное 1, Зарезервированное 2 и Зарезервированное 3 (здесь 2 байта каждое) зарезервированы для будущего использования при передаче информации. Все биты в этом поле в настоящее время установлены равными уровню логического нуля. Цель таких полей в настоящее время состоит в том, чтобы выровнять все последующие 2-байтовые поля к 16-битовому адресу слова и выровнять 4-байтовые поля к 32-битовому адресу слова.
Поле Serial Number (Серийный номер) использует 4 байта в этом варианте осуществления, чтобы задать серийный номер дисплея в числовой форме. Если это поле не поддерживается клиентом, оно обычно устанавливается равным нулю. Поле Week Manufacture (Неделя изготовления) использует 1 байт, чтобы определить неделю изготовления дисплея. Это значение обычно находится в диапазоне от 1 до 53, если оно поддерживается клиентом. Если это поле не поддерживается клиентом, оно установлено равным нулю. Поле Year Manufacture (год изготовления) имеет 1 байт, который определяет год изготовления дисплея. Это значение равно смещению от 1990 года. Годы в диапазоне от 1991 до 2245 могут быть выражены этим полем. Пример: год 2003 соответствует значению 13 поля Year Manufacture. Если это поле не поддерживается клиентом, оно установлено равным нулю.
Поле CRC (здесь 2 байта) содержит 16-битовый CRC всех байтов в пакете, включая поле "Длина пакета".
G. Для пакетов «Запрос клиента и состояния»
Поле Reverse Link Request (Запрос обратной линии связи) (3 байт) задает количество байтов, которые требуются клиенту в обратной линии связи в следующем под-кадре, чтобы послать информацию на ведущее устройство.
Поле CRC Error Count (Количество ошибок кода CRC) (1 байт) указывает, сколько ошибочных значений кода CRC имели место, начиная с начала медиакадра. Значение кода CRC сбрасывается, когда посылается пакет "Заголовок под-кадра" со значением под-кадров, равным нулю. Если фактическое число ошибок кода CRC превышает 255, тогда эти значения обычно насыщаются значением 255.
Поле Capability Change (Изменение возможностей) использует 1 байт для указания изменения в возможностях клиента. Это может происходить, если клиент подсоединяет периферийное устройство, такое как микрофон, клавиатура или дисплей, или по некоторой другой причине. Когда биты [7:0] равны 0, тогда возможность не изменилась, так как последний пакет "Возможности клиента" был послан. Однако, когда биты [7:0] равны от 1 до 255, возможность изменилась. Пакет "Возможности клиента" проверяется, чтобы обнаружить новые характеристики дисплея.
Поле Client Busy Flags (Флаги занятости клиента) использует 2 байта для указания того, что клиент выполняет конкретную функцию и не готов еще принять другой пакет, относящийся к этой функции. Бит, установленный равным уровню или значению логической единицы, указывает, что конкретная функция в настоящее время выполняется клиентом и что соответствующая функция в клиенте является занятой. Если соответствующая функция в клиенте готова, бит установлен в логический нуль. Клиент должен возвратить состояние занятости (множество битов равных единице) для всех функций, которые не поддерживаются в клиенте.
В одном варианте осуществления эти байты интерпретируются согласно следующим соотношениям. Если бит 0 равен '1', тогда функция поблочной пересылки битовой карты занята, в то время как если бит 1 равен '1', то функция заполнения области битовой карты занята, и если бит 2 равен '1', то функция заполнения шаблона битовой карты занята. В то же самое время, если бит 3 равен '1', тогда графическая подсистема занята выполнением операции, которая требует использования буфера кадра в клиенте. Другие графические функции, которые требуют использования буфера кадра, не могут начинаться, пока этот бит не будет установлен в логическую единицу.
В настоящее время биты 4-15 остаются зарезервированными для будущего использования и обычно устанавливаются в уровень логической единицы или состояние для указания занятого состояния в случае, если эти биты будут назначены в будущем.
H. Для пакетов «Поблочная пересылка битовой карты»
Поля Window Upper Left Coordinate X Value и Y Value (значение X и значение Y левой верхней координаты окна) использует 2 байта каждое, чтобы задать значение X и Y координат верхнего левого угла окна, которое должно быть перемещено. Поля Window Width и Height (Ширина и высота окна) используют 2 байта каждое, чтобы определить ширину и высоту окна, которое должно быть перемещено. Поля Window X Movement и Y Movement (Перемещение окна по X и Y) использует 2 байта каждое, чтобы задать число пикселей, на которое окно должно быть перемещено по горизонтали и вертикали соответственно. Как правило, эти координаты конфигурированы так, что положительные значения для X заставляют окно перемещаться вправо и отрицательные значения вызывают перемещение влево, в то время как положительные значения для Y заставляют окно перемещаться вниз, а отрицательные значения вызывают движение вверх.
I. Для пакетов «Заполнение области битовой карты»
В одном варианте осуществления 2-байтовое поле Pixel Data Attributes имеет значения, которые определяют, где пиксельные данные должны быть обновлены, причем биты 1 и 0 выбирают дисплей, где пиксельные данные должны быть обновлены. Если первичный дисплей в клиенте не поддерживает стереоизображения, тогда клиент может влиять на пиксельные данные в первичном дисплее для одной из битовых комбинаций 01, 10 или 11. Рекомендуется, чтобы значение 11 использовалось для адресации первичного дисплея в клиентах, которые не поддерживают возможность стереодисплея. Когда биты [1:0] имеют значения 11 (логическая единица, логическая единица), пиксельные данные обновляются в буфере кадра как левого, так и правого глаза, если биты [1:0] имеют значения 10 (логическая единица, логический нуль), пиксельные данные обновляются только в буфере кадра левого глаза. Когда биты [1:0] имеют значения 01 (логический нуль, логическая единица), пиксельные данные обновляются только в буфере кадра правого глаза. Когда биты [1:0] имеют значения 00 (сдвоенный логический нуль), пиксельные данные обновляются в буфере кадра альтернативного дисплея, указанного битами 8-11 ниже.
В одном варианте осуществления бит 4 поля Pixel Data Attributes определяет, является ли буфер для левого глаза или правого глаза источником изображения для этой операции. Бит 4 применяется, только когда биты [1:0] не равны 00, которые обычно реализованы, чтобы означать, что не поддерживается источник данных от главного буфера кадра, когда адресатом изображения является один из альтернативных дисплеев. Бит 4 используется, чтобы различать или назначать между левым и правым глазом буферы кадра в качестве источника данных. Применение бита 4 также ограничено тем, когда клиент поддерживает растровые операции в отношении указанных дисплеев, как указано битом 21 поля Client Feature Capability Indicators в пакете "Возможности клиента" или битом 21 поля Display Feature Capability Indicators в пакете "Возможности альтернативного дисплея". Во время использования если бит 4 равен 0 (уровень логического нуля), то буфер кадра левого глаза является источником данных, но когда бит 2 равен 1 (уровень логической единицы), тогда буфер кадра правого глаза является источником данных.
Бит 5 поля Pixel Data Attributes определяет, используется ли буфер для регенерации дисплея, или автономный буфер изображения собирается быть входом для растровой операции в качестве изображение адресата для этой операции. Бит 5 может также применяться к альтернативному дисплею, если альтернативный дисплей использует автономный буфер изображения. Однако не поддерживается источник данных от главного буфера изображения, когда адресатом изображения является альтернативный дисплей, или наоборот. При использовании, если бит 5 равен значению 0 или уровню логического нуля, буфер изображения, используемый для регенерации дисплея является источником данных. Когда бит 5 равен значению 1 или уровню логической единицы, автономный буфер изображения является источником данных.
Биты 7 и 6 поля Pixel Data Attributes действуют как биты "Обновление дисплея", которые задают буфер кадра, куда пиксельные данные должны быть обновлены или записаны. Влияние битов "Обновление кадра" описано более подробно выше. Когда биты [7:6] равны '01' (логический нуль, логическая единица), пиксельные данные записывают в автономный буфер кадра. Когда биты [7:6] равны '00' (сдвоенный логический нуль), пиксельные данные записывают в буфер кадра, используемый для регенерации дисплея. Когда биты [7:6] равны '11' (две логические единицы), пиксельные данные записывают во все буферы кадра. Если биты [7:6] равны '10', это обрабатывается как недействительное значение. Эти биты в настоящее время зарезервированы для будущего использования. В этой ситуации вся команда игнорируется и никакие буферы кадра не обновляются.
Биты 11-8 поля Pixel Data Attributes задают альтернативный дисплей или местоположение альтернативного клиента, где пиксельные данные должны быть обновлены. Биты 0 и 1 установлены равными значению 00 (сдвоенный логический нуль) для того, чтобы клиент интерпретировал биты 11-8 как номер альтернативного дисплея. Если биты 1 и 0 не равны 00, тогда биты 8-11 обычно устанавливаются равными значению или уровню логического нуля. Биты 2 и 3 и 12-15 зарезервированы для будущего использования и обычно должны быть установлены в уровень или значение логического нуля.
В одном варианте осуществления 2-байтовое поле Raster Operation (Растровая операция) определяет, как комбинировать пиксели в местоположениях источника и адресата, чтобы сформировать новые пиксельные значения, которые должны быть записаны в местоположение изображения адресата. Растровые операции определяют, как две различных прямоугольных области равного размера в буфере кадра объединяются вместе. Область изображения адресата является также одним из двух изображений, которые объединяются вместе. Второе из двух изображений называется исходным изображением (источником). Если клиент не поддерживает поле Raster Operation, которое определено в пакете "Возможности клиента", тогда ведущее устройство обычно посылает этот пакет с битами 3-0, равными 3, и клиент игнорирует биты 3-0.
В одном варианте осуществления биты 3-0 используются, чтобы задать фактическую растровую операцию, используя или устанавливая их равными одному из значений, показанных в Таблице XVI ниже, чтобы выбрать соответствующую операцию, указанную рядом с этим значением. То есть каждое указанное значение битов [3:0], приведенное в первом столбце, приводит к операции, указанной во втором столбце, и дополнительно определяется в третьем столбце для разъяснения.
| Таблица XVI | ||
| Значение битов [3:0] | Значения, сохраненные в месте назначения | Определение |
| 0 | 0 | |
| 1 | источник & место назначения | логическая операция И |
| 2 | источник & ~ место назначения | источник И (не место назначения) |
| 3 | источник | |
| 4 | ~ источник & место назначения | (не источник) И место назначения |
| 5 | место назначения | нет операции |
| 6 | источник ^ место назначения | логическая операция ИСКЛЮЧАЮЩЕЕ ИЛИ |
| 7 | источник | место назначения | логическая операция ИЛИ |
| 8 | ~ (источник | место назначения) | не (источник ИЛИ место назначения) |
| 9 | ~ (источник ^ место назначения) | не (источник ИСКЛЮЧАЮЩЕЕ ИЛИ место назначения) |
| 10 | ~ (место назначения) | не (место назначения) |
| 11 | источник | ~ место назначения | источник ИЛИ (не место назначения) |
| 12 | ~ источник | не источник |
| 13 | ~ источник | место назначения | (не источник) ИЛИ место назначения |
| 14 | ~ (источник & место назначения) | не (источник И место назначения) |
| 15 | Все единицы | |
Биты 9-8 используются, чтобы задать, записывать ли пиксели адресата (места назначения) в местоположения адресата, когда они относятся к прозрачному цвету. Бит 4 поля Client Feature Capability Indicators (Индикаторы возможностей характеристик клиента) в пакете "Возможности клиента" указывает, поддерживается или нет возможность прозрачного цвета и прозрачной маски клиентом. Точно так же бит 4 поля Display Feature Capability Indicators в пакете "Возможности альтернативного дисплея" указывает, поддерживается ли возможность прозрачного цвета и прозрачной маски указанным альтернативным дисплеем. Когда прозрачный цвет и прозрачная маска не поддерживается, тогда растровая операция ведет себя так, как будто биты [9:8] были установлены в 00. Операция, указанная битами [9:8], применяется, поддерживается или нет растровая операция клиентским устройством. Если клиент не поддерживает растровые операции, то результирующее значение пикселя адресата, которое должно быть рассмотрено для операции, определенной битами [9:8], равно только значению исходного пикселя. Это поведение является таким же при наличии битов [3:0], установленных в 3.
Когда значение битов [9:8] равно 00, тогда прозрачный цвет не используется. Результирующий пиксель адресата записывается в местоположение пикселя адресата без рассмотрения значения прозрачного цвета или прозрачной маски. Прозрачный цвет определяется пакетом "Установка прозрачного цвета и маски". Значение битов [5:4], равное 01, в настоящее время зарезервировано для будущего использования и обычно не используется. Когда значение битов [5:4] равно 10, результирующий пиксель не записывается в местоположение пикселя адресата, если результирующий пиксель адресата, вычисленный с помощью растровой операции, результат выполнения логического И исходного пикселя с прозрачной маской, равен прозрачному цвету. Иначе он записывается в местоположение пикселя адресата. Когда значение битов [9:8] равно 11, результирующий пиксель записывается в местоположение пикселя адресата, если результирующий пиксель адресата, вычисленный растровой операцией, равен прозрачному цвету. Иначе результирующий пиксель не записывается в местоположение пикселя адресата.
Биты с 15 по 10 и с 7 по 4 зарезервированы для будущего использования и поэтому обычно установлены равными значению или уровню логического нуля.
J. Для пакетов "Заполнение шаблона битовой карты"
В одном варианте осуществления поля Window Upper Left Coordinate X Value и Y Value (значение X и значение Y левой верхней координаты окна) в пакете "Заполнение шаблона битовой карты" использует 2 байта каждое, чтобы задать значение X и Y координат верхнего левого угла окна, которое должно быть заполнено. Поля Window Width и Height (Ширина и высота окна) используют 2 байта каждое, чтобы определить ширину и высоту окна соответственно шаблона заполнения. Поле Horizontal Pattern Offset (Смещение шаблона по горизонтали) (2 байта) определяет горизонтальное смещение шаблона пиксельных данных от левой границы указанного окна, которое должно быть заполнено. Задаваемое значение должно быть меньше, чем значение в поле "Ширина шаблона". Поле Vertical Pattern Offset (Смещение шаблона по вертикали) (2 байта) определяет вертикальное смещение шаблона пиксельных данных от верхней границы указанного окна, которое должно быть заполнено. Задаваемое значение должно быть меньше, чем значение в поле Pattern Height ("Высота шаблона").
В одном варианте осуществления 2-байтовое поле Pixel Data Attributes имеет значения, которые задают, где пиксельные данные собираются быть обновлены, причем биты 1 и 0 выбирают дисплей, где пиксельные данные должны быть обновлены. Если первичный дисплей в клиенте не поддерживает стереоизображения, тогда клиент может воздействовать на пиксельные данные в первичном дисплее для одной из битовых комбинаций 01, 10 или 11. Рекомендуется, чтобы значение 11 использовалось для адресации первичного дисплея в клиентах, которые не поддерживают возможность стереодисплея. Когда биты [1:0] имеют значения 11 (логическая единица, логическая единица), пиксельные данные обновляются в буфере кадра и левого, и правого глаза, если биты [1:0] имеют значения 10 (логическая единица, логический нуль), пиксельные данные обновляются в буфере кадра только левого глаза. Когда биты [1:0] имеют значения 01 (логический нуль, логическая единица), пиксельные данные обновляются в буфере кадра только правого глаза. Когда биты [1:0] имеют значения 00 (сдвоенный логический нуль), пиксельные данные обновляются в буфере кадра альтернативного дисплея, указанного битами 8-11 ниже.
Биты 3-2 зарезервированы для будущего использования и должны быть установлены равными нулю.
Бит 4 определяет, является ли буфер для левого глаза или правого глаза входными данными для растровой операции в качестве изображения адресата для этой операции. Бит 4 применяется, только когда биты [1:0] не равны 00, означая, что не поддерживаются исходные данные из главного буфера изображения, когда адресат этого изображения - один из альтернативных дисплеев. Бит 4 обычно также применяется, только когда клиент поддерживает растровые операции на заданных дисплеях, как обозначено битом 21 поля Client Feature Capability Indicators в пакете "Возможности клиента" или битом 21 поля Display Feature Capability Indicators в пакете "Возможности альтернативного дисплея". Когда бит 4 равен 0, буфер кадра левого глаза является источником данных, и когда бит 4 равен 1, буфер кадра правого глаза является источником данных.
Бит 5 определяет, используется ли буфер для регенерации дисплея или автономный буфер изображения действует как входные данные для растровой операции в качестве изображение адресата для этой операции. Бит 5 может также применяться к альтернативному дисплею, если альтернативный дисплей использует автономный буфер изображения. Это не поддерживается для исходных данных от главного буфера изображения, когда адресатом изображения является один из альтернативных дисплеев, или наоборот. Когда бит 5 равен 0, буфер изображения, используемый для обновления дисплея, является источником данных, и когда бит 5 равен 1, автономный буфер изображения является источником данных.
Биты 7 и 6 из поля Pixel Data Attributes действуют как биты "Обновление дисплея", которые определяют буфер изображения, где пиксельные данные должны быть обновлены или записаны. Влияние битов обновления кадра описано более подробно выше. Когда биты [7:6] равны '01' (логический нуль, логическая единица), пиксельные данные обновляются в автономном буфере изображения. Когда биты [7:6] равны '00' (два логических нуля), пиксельные данные записывают в буфер изображения, используемый для обновления изображения дисплея. Когда биты [7:6] равны '11' (две логические единицы), пиксельные данные обновляются во всех буферах изображения. Если биты [7:6] равны '10', это обрабатывается как недействительное значение. Эти биты в настоящее время зарезервированы для будущего использования. В этой ситуации вся команда игнорируется и никакие буферы кадров не обновляются.
Биты 11-8 поля Pixel Data Attributes определяют дисплей или местоположение (адрес) альтернативного клиента, где пиксельные данные должны быть обновлены. Биты 0 и 1 установлены равными значению 00 (сдвоенный логический нуль) для клиента, чтобы интерпретировать биты 11-8 как номер альтернативного дисплея. Если биты 1 и 0 не равны 00, тогда биты 8-11 обычно устанавливаются равными значению или уровню логического нуля. Биты 3 и 2 и с 12 по 15 зарезервированы для будущего использования и обычно установлены в уровень или значение логического нуля.
В одном варианте осуществления 2-байтовое поле Raster Operation определяет, как комбинировать пиксели в источнике и местоположениях адресата (места назначения), чтобы сформировать новые пиксельные значения, которые должны быть записаны в местоположение изображения адресата. Растровые операции определяют, как две различные прямоугольные области равного размера в буфере кадра объединяются вместе. Область изображения адресата является также одним из двух изображений, которые объединяются вместе. Второе из двух изображений называется изображением источника. Если клиент не поддерживает поле Raster Operation, как определено в пакете "Возможности клиента", тогда ведущее устройство обычно посылает этот пакет с битами 3-0, равными 3, и клиент игнорирует биты 3-0.
В одном варианте осуществления биты 3-0 используются, чтобы определить фактическую растровую операцию, с помощью использования или установления их равными одному из значений, показанных в Таблице XVII ниже, чтобы выбрать соответствующую операцию, показанную рядом с этим значением. То есть каждое указанное битами [3:0] значение, перечисленное в первом столбце, приводит к операции, указанной во втором столбце, и дополнительно определяется здесь для разъяснения в третьем столбце.
| Таблица XVII | ||
| Значение битов [3:0] | Значения, сохраненные в месте назначения | Определение |
| 0 | 0 | |
| 1 | источник & место назначения | логическая операция И |
| 2 | источник & ~ место назначения | источник И (не место назначения) |
| 3 | источник | |
| 4 | ~ источник & место назначения | (не источник) И место назначения |
| 5 | место назначения | нет операции |
| 6 | источник ^ место назначения | логическая операция ИСКЛЮЧАЮЩЕЕ ИЛИ |
| 7 | источник | место назначения | логическая операция ИЛИ |
| 8 | ~ (источник | место назначения) | не (источник ИЛИ место назначения) |
| 9 | ~ (источник ^ место назначения) | не (источник ИСКЛЮЧАЮЩЕЕ ИЛИ место назначения) |
| 10 | ~ (место назначения) | не (место назначения) |
| 11 | источник | ~ место назначения | источник ИЛИ (не место назначения) |
| 12 | ~ источник | не источник |
| 13 | ~ источник | место назначения | (не источник) ИЛИ место назначения |
| 14 | ~ (источник & место назначения) | не (источник И место назначения) |
| 15 | Все единицы | |
Биты 9-8 используются, чтобы задать, записывать ли пиксели адресата (места назначения) в местоположения адресата, когда они относятся к прозрачному цвету. Бит 4 поля Client Feature Capability Indicators (Индикаторы возможностей характеристик клиента) в пакете "Возможности клиента" указывает, поддерживается или нет возможность прозрачного цвета и прозрачной маски клиентом. Аналогично бит 4 поля Display Feature Capability Indicators в пакете "Возможности альтернативного дисплея" указывает, поддерживается ли возможность прозрачного цвета и прозрачной маски указанным альтернативным дисплеем. Когда прозрачный цвет и прозрачная маска не поддерживается, тогда растровая операция ведет себя так, как будто биты [9:8] были установлены в 00. Операция, указанная битами [9:8], применяется, поддерживается или нет растровая операция клиентским устройством. Если клиент не поддерживает растровые операции, то результирующее значение пикселя адресата, которое должно быть рассмотрено для операции, определенной битами [9:8], равно только значению исходного пикселя. Это поведение является таким же при наличии битов [3:0], установленных в 3.
Когда значение битов [9:8] равно 00, тогда прозрачный цвет не используется. Результирующий пиксель адресата записывается в местоположение пикселя адресата без рассмотрения значения прозрачного цвета или прозрачной маски. Прозрачный цвет определяется пакетом "Установка прозрачного цвета и маски". Значение битов [5:4], равное 01, в настоящее время зарезервировано для будущего использования и обычно не используется, хотя доступно для установления специалистами в данной области техники при соответствующем использовании. Когда значение битов [5:4] равно 10, результирующий пиксель не записывается в местоположение пикселя адресата, если результирующий пиксель адресата, вычисленный с помощью растровой операции - результат выполнения логического И исходного пикселя с прозрачной маской - равен прозрачному цвету. Иначе он записывается в местоположение пикселя адресата. Когда значение битов [9:8] равно 11, результирующий пиксель записывается в местоположение пикселя адресата, если результирующий пиксель адресата, вычисленный растровой операцией, равен прозрачному цвету. Иначе результирующий пиксель не записывается в местоположение пикселя адресата.
Биты с 15 по 10 и с 7 по 4 зарезервированы для будущего использования и поэтому обычно установлены равными значению или уровню логического нуля.
В одном варианте осуществления 2-байтовое поле "Параметр CRC" в пакете "Заполнение шаблона битовой карты" содержит CRC всех байтов от "Длина пакета" до "Дескриптор формата видео". Если этот CRC дает ошибку при проверке, тогда весь пакет отвергается. Поле «Пиксельные данные шаблона» содержит необработанную информацию видео, которая задает шаблон заполнения в формате, указанном "Дескриптор формата данных видео". Данные упакованы в байты, и первый пиксель каждой строки должен быть выровненным по границе байта. Данные шаблона заполнения передаются по строке за раз. Поле "CRC пиксельных данных шаблона" для пакета "Заполнение шаблона битовой карты" использует 2 байта, которые содержат CRC только пиксельных данных шаблона. Если этот CRC дает ошибку при проверке, тогда пиксельные данные шаблона могут все еще использоваться, но подсчет ошибочных кодов CRC должен быть увеличен.
K. Для пакетов "Разрешение прямого аудиоканала"
Поле Audio Channel Enable Mask (Маска разрешения аудиоканала) (1 байт) содержит группу флагов, которые указывают, какие аудиоканалы должны быть разрешены в клиенте. Бит, установленный равным единице, разрешает соответствующий канал, и бит, установленный равным нулю, отключает (запрещает) соответствующий канал. Биты 0-5 определяют каналы 0-5, которые адресуют левый передний, правый передний, левый задний, правый задний, передний центральный и саб-вуферный каналы соответственно. Биты 6 и 7 зарезервированы для будущего использования и пока обычно устанавливаются равными нулю.
L. Для пакетов "Частота выборки аудио обратной линии связи"
Поле Audio Sample Rate (Частота выборки аудио) (1 байт) задает частоту выборки цифрового аудио. Значения для этого поля назначены различным скоростям со значениями 0, 1, 2, 3, 4, 5, 6, 7 и 8, используемыми, чтобы обозначить 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050 и 44100 выборок в секунду (в/с) соответственно, при этом биты 9-254 зарезервированы для использования с альтернативными частотами, как требуется, так что они в настоящее время установлены равными '0'. Значение 255 используется, чтобы запретить аудиопоток обратной линии связи.
Поле Sample Format (Формат выборки) (1 байт) определяет формат цифровых выборок аудио. Когда биты [1:0] равны '0', цифровые выборки аудио находятся в линейном формате, когда они равны 1, цифровые выборки аудио находятся в формате μ-Закона, и когда они равны 2, цифровые выборки аудио находятся в формате А-Закона. Биты [7:2] зарезервированы для альтернативного использования в обозначении аудиоформатов, как требуется, и обычно устанавливаются равными нулю.
M. Для служебных пакетов "Защита цифрового контента"
Поле Content Protection Type (Тип защиты контента) (1 байт) определяет способ защиты цифрового контента, который используется. Значение '0' указывает Цифровую защиту контента передачи (DTCP), в то время как значение 1 указывает Широкополосную систему защиты цифрового контента (HDCP). Диапазон значений от 2 до 255 в настоящее время не задан, но зарезервирован для использования с альтернативными схемами защиты, как требуется. Поле Content Protection Overhead Messages (Служебные сообщения защиты контента) - это поле переменной длины, содержащее сообщения защиты контента, посылаемые между ведущим устройством и клиентом.
N. Для пакетов "Измерение задержки прохождения сигнала в прямом и обратном направлениях"
2-байтовое поле Packet Length (Длина пакета) определяет общее количество байтов в пакете, не включая в себя поле длины пакета, и в одном варианте осуществления выбрано имеющим фиксированную длину, равную 159. 2-байтовое поле Packet Type (Тип пакета), которое идентифицирует этот тип пакета со значением 82, идентифицирует пакет как пакет «Измерение задержки прохождения сигнала в прямом и обратном направлениях". Поле hClient ID (Идентификатор клиента), как и прежде, зарезервировано для будущего использования в качестве идентификатора клиента и обычно устанавливается равным нулю.
В одном варианте осуществления поле "Параметр CRC" (2 байта) содержит 16-битовый CRC всех байтов от "Длина пакета" до "Тип пакета". Если этот CRC при проверке выдает ошибку, тогда весь пакет отвергается.
Поле "Защитный интервал времени 1" (здесь 64 байта) используются, чтобы позволить разрешать задающие устройства линии MDDI_Data в клиенте прежде, чем задающие устройства линии в ведущем устройстве будут запрещены. Клиент разрешает свои задающие устройства линии MDDI_Data в течение бита 0 "Защитного интервала времени 1", и ведущее устройство снимает разрешение своих задающих устройств линии, чтобы быть полностью запрещенными, до последнего бита "Защитного интервала времени 1". Ведущее устройство и клиент оба возбуждают (устанавливают) уровень логического нуля в течение "Защитного интервала времени 1", когда они не запрещены. Другая цель этого поля состоит в том, чтобы гарантировать, что все сигналы MDDI_Data равны логическому нулю в течение достаточного времени, чтобы позволить пользователю начать восстанавливать синхронизацию или синхросигнал, используя только MDDI_Stb, до отключения задающих устройств линии ведущего устройства.
Поле Measurement Period (Период измерения) - это окно в 64 байта, используемое для того, чтобы разрешить пользователю отвечать двумя байтами 0xff и 30 байтами 0x00 на половине скорости передачи данных, используемой на прямой линии связи. Эта скорость передачи данных соответствует Делителю скорости передачи обратной линии связи, равному 1. Клиент возвращает этот ответ немедленно в момент, когда он воспринимает начало поля "Период измерения". Этот ответ от клиента будет принят в ведущем устройстве в точности равным задержке прохождения сигнала в прямом и обратном направлениях связи плюс логическая задержка в клиенте после начала первого бита поля "Период измерения" в ведущем устройстве.
Поле "Все нули 1" (2 байта) содержит нули, чтобы разрешить перекрытие (наложение) задающих устройств линии MDDI_Data в ведущем устройстве и клиенте, так что MDDI_Data всегда возбуждаются (установлены). Ведущее устройство разрешает задающие устройства линии MDDI_Data в течение бита 0 поля "Все нули 1", и клиент также продолжает возбуждать сигнал до уровня логического нуля, как он это делал в конце поля "Период измерения".
Значение поля "Защитный интервал времени 2" (64 байта) разрешает перекрытие поля "Период измерения", устанавливаемого клиентом, когда задержка прохождения сигнала в прямом и обратном направлениях равна максимальной величине, которая может быть измерена в "Периоде измерения". Клиент отключает свои задающие устройства линии в течение бита 0 "Защитного интервала времени 2", и ведущее устройство разрешает свои задающие устройства линии немедленно после последнего бита "Защитного интервала времени 2". Ведущее устройство и клиент оба устанавливают уровень логического нуля в течение "Защитного интервала времени 2", когда они не заблокированы. Другая цель этого поля состоит в том, чтобы гарантировать, что все сигналы MDDI_Data равны логическому нулю в течение достаточного времени, чтобы разрешить пользователю начинать восстанавливать синхросигнал, используя и MDDI _DATA0 и MDDI_Stb после разрешения задающих устройств линии для ведущего устройства.
O. Для пакетов «Калибровка сдвига во времени прямой линии связи»
В одном варианте осуществления поле Параметр CRC (2 байта) содержит 16-битовый CRC всех байтов от "Длина пакета" до "Тип пакета". Если этот CRC при проверке выдает ошибку, тогда весь пакет отвергают.
Поле "Все нули 1" использует 8 байтов, чтобы гарантировать, что будут иметь место переходы на MDDI_Stb в начале поля Calibration Data Sequence (Последовательность данных калибровки). Обычно эти байты используют 8-битовые целые числа без знака, равные нулю. Оно также обеспечивает достаточное время для базовой логики клиента, чтобы изменить режим схемы восстановления синхросигнала от использования ИСКЛЮЧАЮЩЕЕ ИЛИ (XOR) для MDDI_0 и MDDI_Stb к простому использованию MDDI_Stb или MDDI_Stb сигнала в качестве восстановленного сигнала синхронизации.
Поле Calibration Data Sequence (Последовательность данных калибровки) содержит последовательность данных, которая заставляет сигналы MDDI_Data переключаться в каждом периоде данных. Длина поля Calibration Data Sequence определяется интерфейсом, используемым на прямой линии связи. В течение обработки последовательности данных калибровки контроллер ведущего устройства MDDI устанавливает все сигналы MDDI_Data равными сигналу строба. Схема восстановления сигнала синхронизации клиента должна использовать только MDDI_Stb вместо MDDI_Stb XOR MDDI_Data0, чтобы восстановить синхронизацию данных, в то время как поле Calibration Data Sequence принимается клиентом. В зависимости от точной фазы сигнала MDDI_Stb в начале поля Calibration Data Sequence (Последовательность данных калибровки) эта "Последовательность данных калибровки" будет обычно одной из следующих на основании используемого Типа интерфейса, когда этот пакет послан:
Тип 1 - (последовательность данных 64 байта) 0xaa, 0xaa … или 0х55, 0х55 …
Тип 2 - (последовательность данных 128 байтов) 0xcc, 0xcc … или 0х33, 0х33 …
Тип 3 - (последовательность данных 256 байтов) 0xf0,0xf0 … или 0x0f, 0x0f …
Тип 4 - (последовательность данных 512 байтов) 0xff, 0х00, 0xff, 0х00 … или 0х00, 0xff, 0х00, 0xff …
Поле "Все нули 2" использует 8 байтов, чтобы обеспечить достаточное время для базовой логики клиента, чтобы изменить режим схемы восстановления синхронизации назад к первоначальному состоянию, от использования сигнала MDDI_Stb в качестве сигнала восстановленной синхронизации к использованию результата операции XOR для MDDI_0 и MDDI_Stb. Обычно эти байты используют 8-битовые целые числа без знака, равные нулю.
Пример возможных форм сигналов MDDI_Data и MDDI_Stb для интерфейса как Типа 1, так и Типа 2 иллюстрируется на Фиг.62A и 62B соответственно.
XIX. Заключение
В то время как различные варианты осуществления настоящего изобретения были описаны выше, должно быть понятно, что они были представлены только в качестве примера, а не ограничения. Таким образом, широта и объем настоящего изобретения не должны быть ограничены каким-либо из описанных выше примерных вариантов осуществления, но должны определяться только в соответствии с нижеследующей формулой изобретения и ее эквивалентами.
Claims (30)
1. Способ выборки данных обратной передачи для каждого канала данных из множества каналов данных в системе с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI), причем способ содержит этапы:
посылают пакет измерения задержки прохождения сигнала в прямом и обратном направлениях от ведущего устройства клиентскому устройству;
посылают импульс внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях к ведущему устройству от клиентского устройства для каждого канала данных;
измеряют задержку прохождения сигнала в прямом и обратном направлениях системы ЦИМС посредством обнаружения импульса, посланного внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях, для каждого канала данных;
определяют фазу посланного импульса;
сохраняют измеренную задержку прохождения сигнала в прямом и обратном направлениях каждого канала;
определяют время для начала выборки данных обратной передачи, посланных клиентским устройством, на основании измеренной задержки прохождения сигнала в прямом и обратном направлениях каждого канала данных и фазы посланного импульса, посланного в ответ клиентским устройством относительно границы бита в окне измерения.
посылают пакет измерения задержки прохождения сигнала в прямом и обратном направлениях от ведущего устройства клиентскому устройству;
посылают импульс внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях к ведущему устройству от клиентского устройства для каждого канала данных;
измеряют задержку прохождения сигнала в прямом и обратном направлениях системы ЦИМС посредством обнаружения импульса, посланного внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях, для каждого канала данных;
определяют фазу посланного импульса;
сохраняют измеренную задержку прохождения сигнала в прямом и обратном направлениях каждого канала;
определяют время для начала выборки данных обратной передачи, посланных клиентским устройством, на основании измеренной задержки прохождения сигнала в прямом и обратном направлениях каждого канала данных и фазы посланного импульса, посланного в ответ клиентским устройством относительно границы бита в окне измерения.
2. Способ по п.1, в котором этап измерения задержки прохождения сигнала в прямом и обратном направлениях содержит измерение задержки распространения от ведущего устройства к клиентскому устройству и от клиентского устройства к ведущему устройству.
3. Способ по п.1, дополнительно содержащий определение делителя скорости передачи по линии связи в пакете инкапсуляции обратной линии связи на основании измеренной задержки прохождения сигнала в прямом и обратном направлениях.
4. Система выборки данных обратной передачи для каждого канала данных из множества каналов данных в системе с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI), содержащая:
средство для посылки пакета измерения задержки прохождения сигнала в прямом и обратном направлениях от ведущего устройства клиентскому устройству;
средство для посылки импульса внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях к ведущему устройству от клиентского устройства для каждого канала данных;
средство для измерения задержки прохождения сигнала в прямом и обратном направлениях в системе ЦИМС посредством обнаружения импульса, посланного внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях для каждого канала данных;
средство для определения фазы посланного импульса;
средство для сохранения измеренной задержки прохождения сигнала в прямом и обратном направлениях каждого канала;
средство для определения времени начала выборки данных обратной передачи, посланных клиентским устройством, на основании измеренной задержки прохождения сигнала в прямом и обратном направлениях каждого канала данных и фазы посланного импульса, посланного в ответ клиентским устройством, относительно границы бита в окне измерения.
средство для посылки пакета измерения задержки прохождения сигнала в прямом и обратном направлениях от ведущего устройства клиентскому устройству;
средство для посылки импульса внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях к ведущему устройству от клиентского устройства для каждого канала данных;
средство для измерения задержки прохождения сигнала в прямом и обратном направлениях в системе ЦИМС посредством обнаружения импульса, посланного внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях для каждого канала данных;
средство для определения фазы посланного импульса;
средство для сохранения измеренной задержки прохождения сигнала в прямом и обратном направлениях каждого канала;
средство для определения времени начала выборки данных обратной передачи, посланных клиентским устройством, на основании измеренной задержки прохождения сигнала в прямом и обратном направлениях каждого канала данных и фазы посланного импульса, посланного в ответ клиентским устройством, относительно границы бита в окне измерения.
5. Система по п.4, в которой средство для измерения задержки прохождения сигнала в прямом и обратном направлениях содержит средство для измерения задержки распространения от ведущего устройства к клиентскому устройству и от клиентского устройства к ведущему устройству.
6. Система по п.4, дополнительно содержащая средство для определения делителя скорости передачи по линии связи в пакете инкапсуляции обратной линии связи на основании измеренной задержки прохождения сигнала в прямом и обратном направлениях.
7. Процессор для выборки данных обратной передачи для каждого канала данных из множества каналов данных в системе с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI), выполненный с возможностью:
посылки пакета измерения задержки прохождения сигнала в прямом и обратном направлениях от ведущего устройства к клиентскому устройству;
посылки импульса внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях клиентским устройством к ведущему устройству для каждого канала данных;
измерения задержки прохождения сигнала в прямом и обратном направлениях в системе ЦИМС посредством обнаружения импульса, посланного внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях для каждого канала данных;
определения фазы посланного импульса;
сохранения измеренной задержки прохождения сигнала в прямом и обратном направлениях каждого канала;
определения времени начала выборки данных обратной передачи, посланных клиентским устройством, на основании сохраненной задержки прохождения сигнала в прямом и обратном направлениях каждого канала данных.
посылки пакета измерения задержки прохождения сигнала в прямом и обратном направлениях от ведущего устройства к клиентскому устройству;
посылки импульса внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях клиентским устройством к ведущему устройству для каждого канала данных;
измерения задержки прохождения сигнала в прямом и обратном направлениях в системе ЦИМС посредством обнаружения импульса, посланного внутри окна измерения в пакете измерения задержки прохождения сигнала в прямом и обратном направлениях для каждого канала данных;
определения фазы посланного импульса;
сохранения измеренной задержки прохождения сигнала в прямом и обратном направлениях каждого канала;
определения времени начала выборки данных обратной передачи, посланных клиентским устройством, на основании сохраненной задержки прохождения сигнала в прямом и обратном направлениях каждого канала данных.
8. Процессор по п.7, в котором процессор дополнительно выполнен с возможностью измерения задержки распространения от ведущего устройства к клиентскому устройству и от клиентского устройства к ведущему устройству.
9. Процессор по п.7, процессор дополнительно выполнен с возможностью определения делителя скорости передачи по линии связи в пакете инкапсуляции обратной линии связи на основании измеренной задержки прохождения сигнала в прямом и обратном направлениях.
10. Способ определения скорости передачи данных между ведущим устройством и клиентским устройством в системе с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI), причем способ содержит этапы:
выбирают минимальную скорость передачи данных предварительной калибровки, которую может поддерживать клиентское устройство;
запрос пакета возможностей клиента ведущим устройством от клиентского устройства,
выполнение калибровки сдвига во времени прямой линии связи для оптимизации линии связи для работы на упомянутой скорости передачи данных;
определение максимальной скорости передачи данных на основании значения скорости передачи данных в пакете возможностей клиента и калибровки сдвига во времени прямой линии связи и
функционирование на определенной максимальной скорости передачи данных.
выбирают минимальную скорость передачи данных предварительной калибровки, которую может поддерживать клиентское устройство;
запрос пакета возможностей клиента ведущим устройством от клиентского устройства,
выполнение калибровки сдвига во времени прямой линии связи для оптимизации линии связи для работы на упомянутой скорости передачи данных;
определение максимальной скорости передачи данных на основании значения скорости передачи данных в пакете возможностей клиента и калибровки сдвига во времени прямой линии связи и
функционирование на определенной максимальной скорости передачи данных.
11. Система определения скорости передачи данных между ведущим устройством и клиентским устройством в системе с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI), содержащая:
средство для выбора минимальной скорости передачи данных предварительной калибровки, которую может поддерживать клиентское устройство;
средство для запроса пакета возможностей клиента ведущим устройством от клиентского устройства,
средство для выполнения калибровки сдвига во времени прямой линии связи для оптимизации линии связи для работы на упомянутой скорости передачи данных;
средство для определения максимальной скорости передачи данных на основании значения скорости передачи данных в пакете возможностей клиента и калибровки сдвига во времени прямой линии связи и
средство для функционирования на определенной максимальной скорости передачи данных.
средство для выбора минимальной скорости передачи данных предварительной калибровки, которую может поддерживать клиентское устройство;
средство для запроса пакета возможностей клиента ведущим устройством от клиентского устройства,
средство для выполнения калибровки сдвига во времени прямой линии связи для оптимизации линии связи для работы на упомянутой скорости передачи данных;
средство для определения максимальной скорости передачи данных на основании значения скорости передачи данных в пакете возможностей клиента и калибровки сдвига во времени прямой линии связи и
средство для функционирования на определенной максимальной скорости передачи данных.
12. Процессор для выборки данных обратной передачи для каждого канала данных из множества каналов данных в системе с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI), выполненный с возможностью:
определения оптимальной скорости передачи данных между ведущим устройством и клиентским устройством в системе с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI);
выбора минимальной скорости передачи данных предварительной калибровки, которую может поддерживать клиентское устройство;
запроса пакета возможностей клиента ведущим устройством от клиентского устройства,
выполнения калибровки сдвига во времени прямой линии связи для оптимизации линии связи для работы на упомянутой скорости передачи данных;
определения максимальной скорости передачи данных на основании значения скорости передачи данных в пакете возможностей клиента и
принуждения системы функционировать на определенной максимальной скорости передачи данных.
определения оптимальной скорости передачи данных между ведущим устройством и клиентским устройством в системе с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI);
выбора минимальной скорости передачи данных предварительной калибровки, которую может поддерживать клиентское устройство;
запроса пакета возможностей клиента ведущим устройством от клиентского устройства,
выполнения калибровки сдвига во времени прямой линии связи для оптимизации линии связи для работы на упомянутой скорости передачи данных;
определения максимальной скорости передачи данных на основании значения скорости передачи данных в пакете возможностей клиента и
принуждения системы функционировать на определенной максимальной скорости передачи данных.
13. Устройство для подсоединения двух клиентских устройств к ведущему устройству во внутреннем режиме системы с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI), содержащее:
первую оконечную нагрузку в первом местоположении на конце кабеля с первой длиной, равной Lstub1;
первое клиентское устройство, имеющее возможности передачи и приема в упомянутом первом местоположении;
вторую оконечную нагрузку во втором местоположении на упомянутом кабеле со второй длиной, равной Lstub2;
второе клиентское устройство, содержащее только возможности приема в упомянутом втором местоположении, причем первая длина и вторая длина определены на основании минимального времени нарастания выходного сигнала задающего устройства и скоростного фактора по меньшей мере одной линии передачи.
первую оконечную нагрузку в первом местоположении на конце кабеля с первой длиной, равной Lstub1;
первое клиентское устройство, имеющее возможности передачи и приема в упомянутом первом местоположении;
вторую оконечную нагрузку во втором местоположении на упомянутом кабеле со второй длиной, равной Lstub2;
второе клиентское устройство, содержащее только возможности приема в упомянутом втором местоположении, причем первая длина и вторая длина определены на основании минимального времени нарастания выходного сигнала задающего устройства и скоростного фактора по меньшей мере одной линии передачи.
14. Способ подсоединения двух клиентских устройств к ведущему устройству во внутреннем режиме системы с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI), содержащий этапы:
обеспечение первой оконечной нагрузки в первом местоположении на конце кабеля с первой длиной, равной Lstub1;
подсоединение первого клиентского устройства, имеющего возможности передачи и приема, в упомянутом первом местоположении;
обеспечение второй оконечной нагрузки во втором местоположении на упомянутом кабеле со второй длиной, равной Lstub2;
подсоединение второго клиентского устройства, содержащего только возможности приема, в упомянутом втором местоположении, причем первая длина и вторая длина определены на основании минимального времени нарастания выходного сигнала задающего устройства и скоростного фактора по меньшей мере одной линии передачи.
обеспечение первой оконечной нагрузки в первом местоположении на конце кабеля с первой длиной, равной Lstub1;
подсоединение первого клиентского устройства, имеющего возможности передачи и приема, в упомянутом первом местоположении;
обеспечение второй оконечной нагрузки во втором местоположении на упомянутом кабеле со второй длиной, равной Lstub2;
подсоединение второго клиентского устройства, содержащего только возможности приема, в упомянутом втором местоположении, причем первая длина и вторая длина определены на основании минимального времени нарастания выходного сигнала задающего устройства и скоростного фактора по меньшей мере одной линии передачи.
15. Способ по п.14, дополнительно содержащий оптимизацию первой длины и второй длины для заранее определенного сигнала качества.
16. Способ определения максимальной скорости передачи данных предварительной калибровки сдвига во времени в системе связи с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI), причем способ содержит этапы:
работают на первой рабочей скорости передачи данных между клиентским устройством и ведущим устройством, причем первая рабочая скорость передачи данных является безопасной рабочей скоростью передачи данных,
посылают пакет инкапсуляции обратной линии связи от ведущего устройства к клиентскому устройству, запрашивающему пакет возможностей клиентского устройства;
передают пакет возможностей клиентского устройства от клиентского устройства к ведущему устройству, при этом пакет возможностей клиентского устройства содержит значение максимальной скорости передачи данных предварительной калибровки сдвига во времени, и
работают посредством ведущего устройства на второй рабочей скорости передачи данных, при этом вторая рабочая скорость передачи данных является скоростью передачи данных, равной или ниже максимальной скорости передачи данных предварительной калибровки сдвига во времени.
работают на первой рабочей скорости передачи данных между клиентским устройством и ведущим устройством, причем первая рабочая скорость передачи данных является безопасной рабочей скоростью передачи данных,
посылают пакет инкапсуляции обратной линии связи от ведущего устройства к клиентскому устройству, запрашивающему пакет возможностей клиентского устройства;
передают пакет возможностей клиентского устройства от клиентского устройства к ведущему устройству, при этом пакет возможностей клиентского устройства содержит значение максимальной скорости передачи данных предварительной калибровки сдвига во времени, и
работают посредством ведущего устройства на второй рабочей скорости передачи данных, при этом вторая рабочая скорость передачи данных является скоростью передачи данных, равной или ниже максимальной скорости передачи данных предварительной калибровки сдвига во времени.
17. Способ по п.16, в котором первой рабочей скоростью передачи данных является скорость передачи данных, равная или меньшая безопасной рабочей скорости передачи данных.
18. Способ по п.16, в котором значение безопасной рабочей скорости передачи данных находится в диапазоне от 0,001 и 1 Мбит/с.
19. Система для определения максимальной скорости передачи данных предварительной калибровки сдвига во времени в системе связи с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI), содержащая:
средство для работы на первой рабочей скорости передачи данных между клиентским устройством и ведущим устройством, причем первая рабочая скорость передачи данных является безопасной рабочей скоростью передачи данных,
средство для посылки пакета инкапсуляции обратной линии связи от ведущего устройства к клиентскому устройству, запрашивающему пакет возможностей клиентского устройства;
средство для передачи пакета возможностей клиентского устройства от клиентского устройства к ведущему устройству, при этом пакет возможностей клиентского устройства содержит значение максимальной скорости передачи данных предварительной калибровки сдвига во времени, и
средство для работы посредством ведущего устройства на второй рабочей скорости передачи данных, при этом вторая рабочая скорость передачи данных является скоростью передачи данных, равной или ниже максимальной скорости передачи данных предварительной калибровки сдвига во времени.
средство для работы на первой рабочей скорости передачи данных между клиентским устройством и ведущим устройством, причем первая рабочая скорость передачи данных является безопасной рабочей скоростью передачи данных,
средство для посылки пакета инкапсуляции обратной линии связи от ведущего устройства к клиентскому устройству, запрашивающему пакет возможностей клиентского устройства;
средство для передачи пакета возможностей клиентского устройства от клиентского устройства к ведущему устройству, при этом пакет возможностей клиентского устройства содержит значение максимальной скорости передачи данных предварительной калибровки сдвига во времени, и
средство для работы посредством ведущего устройства на второй рабочей скорости передачи данных, при этом вторая рабочая скорость передачи данных является скоростью передачи данных, равной или ниже максимальной скорости передачи данных предварительной калибровки сдвига во времени.
20. Система по п.19, в которой первой рабочей скоростью передачи данных является скорость передачи данных, равная или меньшая безопасной рабочей скорости передачи данных.
21. Система по п.19, в которой значение безопасной рабочей скорости передачи данных находится в диапазоне от 0,001 и 1 Мбит/с.
22. Процессор, выполненный с возможностью:
определения максимальной скорости передачи данных предварительной калибровки сдвига во времени в системе связи с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI),
вынуждать упомянутую систему работать на первой рабочей скорости передачи данных между клиентским устройством и ведущим устройством, причем первая рабочая скорость передачи данных является безопасной рабочей скоростью передачи данных,
реализовывать посылку пакета инкапсуляции обратной линии связи от ведущего устройства к клиентскому устройству, запрашивающему пакет возможностей клиентского устройства;
реализовывать передачу пакета возможностей клиентского устройства от клиентского устройства к ведущему устройству, при этом пакет возможностей клиентского устройства содержит значение максимальной скорости передачи данных предварительной калибровки сдвига во времени, и
вынуждать упомянутую систему посредством ведущего устройства работать на второй рабочей скорости передачи данных, при этом вторая рабочая скорость передачи данных является скоростью передачи данных, равной или меньшей максимальной скорости передачи данных предварительной калибровки сдвига во времени.
определения максимальной скорости передачи данных предварительной калибровки сдвига во времени в системе связи с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI),
вынуждать упомянутую систему работать на первой рабочей скорости передачи данных между клиентским устройством и ведущим устройством, причем первая рабочая скорость передачи данных является безопасной рабочей скоростью передачи данных,
реализовывать посылку пакета инкапсуляции обратной линии связи от ведущего устройства к клиентскому устройству, запрашивающему пакет возможностей клиентского устройства;
реализовывать передачу пакета возможностей клиентского устройства от клиентского устройства к ведущему устройству, при этом пакет возможностей клиентского устройства содержит значение максимальной скорости передачи данных предварительной калибровки сдвига во времени, и
вынуждать упомянутую систему посредством ведущего устройства работать на второй рабочей скорости передачи данных, при этом вторая рабочая скорость передачи данных является скоростью передачи данных, равной или меньшей максимальной скорости передачи данных предварительной калибровки сдвига во времени.
23. Процессор по п.22, в котором первой рабочей скоростью передачи данных является скорость передачи данных, равная или меньшая безопасной рабочей скорости передачи данных.
24. Процессор по п.22, в котором значение безопасной рабочей скорости передачи данных находится в диапазоне от 0,001 и 1 Мбит/с.
25. Способ определения максимальной рабочей скорости передачи данных после калибровки сдвига во времени в системе связи с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI), причем способ содержит этапы:
посылают пакет калибровки сдвига во времени от ведущего устройства к клиентскому устройству;
выполняют регулировку калибровки сдвига во времени посредством клиентского устройства;
посылают пакет возможностей клиентского устройства от клиентского устройства к ведущему устройству, при этом пакет возможностей клиентского устройства содержит значение максимальной рабочей скорости передачи данных после калибровки сдвига во времени, и
выбирают рабочую скорость передачи данных посредством ведущего устройства, при этом рабочая скорость передачи данных является скоростью передачи данных, равной или меньшей максимальной рабочей скорости передачи данных после калибровки сдвига во времени.
посылают пакет калибровки сдвига во времени от ведущего устройства к клиентскому устройству;
выполняют регулировку калибровки сдвига во времени посредством клиентского устройства;
посылают пакет возможностей клиентского устройства от клиентского устройства к ведущему устройству, при этом пакет возможностей клиентского устройства содержит значение максимальной рабочей скорости передачи данных после калибровки сдвига во времени, и
выбирают рабочую скорость передачи данных посредством ведущего устройства, при этом рабочая скорость передачи данных является скоростью передачи данных, равной или меньшей максимальной рабочей скорости передачи данных после калибровки сдвига во времени.
26. Способ по п.25, дополнительно содержащий этап посылки ведущим устройством пакета инкапсуляции обратной линии связи к клиентскому устройству, запрашивающему пакет возможностей клиентского устройства.
27. Система для определения максимальной рабочей скорости передачи данных после калибровки сдвига во времени в системе связи с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI), причем система содержит:
средство для посылки пакета калибровки сдвига во времени от ведущего устройства к клиентскому устройству;
средство для выполнения регулировки калибровки сдвига во времени посредством клиентского устройства;
средство для посылки пакета возможностей клиентского устройства от клиентского устройства к ведущему устройству, при этом пакет возможностей клиентского устройства содержит значение максимальной рабочей скорости передачи данных после калибровки сдвига во времени, и
средство для выбора рабочей скорости передачи данных посредством ведущего устройства, при этом рабочая скорость передачи данных является скоростью передачи данных, равной или меньшей максимальной рабочей скорости передачи данных после калибровки сдвига во времени.
средство для посылки пакета калибровки сдвига во времени от ведущего устройства к клиентскому устройству;
средство для выполнения регулировки калибровки сдвига во времени посредством клиентского устройства;
средство для посылки пакета возможностей клиентского устройства от клиентского устройства к ведущему устройству, при этом пакет возможностей клиентского устройства содержит значение максимальной рабочей скорости передачи данных после калибровки сдвига во времени, и
средство для выбора рабочей скорости передачи данных посредством ведущего устройства, при этом рабочая скорость передачи данных является скоростью передачи данных, равной или меньшей максимальной рабочей скорости передачи данных после калибровки сдвига во времени.
28. Система по п.27, дополнительно содержащая средство для посылки ведущим устройством пакета инкапсуляции обратной линии связи к клиентскому устройству, запрашивающему пакет возможностей клиентского устройства.
29. Процессор, выполненный с возможностью:
определения максимальной рабочей скорости передачи данных после калибровки сдвига во времени в системе связи с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI),
реализовывать посылку пакета калибровки сдвига во времени от ведущего устройства к клиентскому устройству;
реализовывать выполнение регулировки калибровки сдвига во времени посредством клиентского устройства;
реализовывать посылку пакета возможностей клиентского устройства от клиентского устройства к ведущему устройству, при этом пакет возможностей клиентского устройства содержит значение максимальной рабочей скорости передачи данных после калибровки сдвига во времени, и
реализовывать выбор рабочей скорости передачи данных посредством ведущего устройства, при этом рабочая скорость передачи данных является скоростью передачи данных, равной или меньшей максимальной рабочей скорости передачи данных после калибровки сдвига во времени.
определения максимальной рабочей скорости передачи данных после калибровки сдвига во времени в системе связи с цифровым интерфейсом мобильной системы передачи данных (ЦИМС, MDDI),
реализовывать посылку пакета калибровки сдвига во времени от ведущего устройства к клиентскому устройству;
реализовывать выполнение регулировки калибровки сдвига во времени посредством клиентского устройства;
реализовывать посылку пакета возможностей клиентского устройства от клиентского устройства к ведущему устройству, при этом пакет возможностей клиентского устройства содержит значение максимальной рабочей скорости передачи данных после калибровки сдвига во времени, и
реализовывать выбор рабочей скорости передачи данных посредством ведущего устройства, при этом рабочая скорость передачи данных является скоростью передачи данных, равной или меньшей максимальной рабочей скорости передачи данных после калибровки сдвига во времени.
30. Процессор по п.29, в котором процессор дополнительно выполнен с возможностью реализовывать посылку ведущим устройством пакета инкапсуляции обратной линии связи к клиентскому устройству, запрашивающему пакет возможностей клиентского устройства.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US57750004P | 2004-06-04 | 2004-06-04 | |
| US60/577,500 | 2004-06-04 | ||
| US57779304P | 2004-06-07 | 2004-06-07 | |
| US60/577,793 | 2004-06-07 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| RU2006147230A RU2006147230A (ru) | 2008-07-20 |
| RU2353066C2 true RU2353066C2 (ru) | 2009-04-20 |
Family
ID=34972038
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2006147230/09A RU2353066C2 (ru) | 2004-06-04 | 2005-06-03 | Устройство и способ реализации интерфейса высокоскоростной передачи данных |
Country Status (14)
| Country | Link |
|---|---|
| US (2) | US8630305B2 (ru) |
| EP (6) | EP1978693A3 (ru) |
| JP (3) | JP4664360B2 (ru) |
| KR (2) | KR100926658B1 (ru) |
| CN (3) | CN1993948A (ru) |
| AT (3) | ATE518343T1 (ru) |
| AU (4) | AU2005253592B2 (ru) |
| BR (1) | BRPI0511783A (ru) |
| CA (1) | CA2569106C (ru) |
| IL (1) | IL179712A0 (ru) |
| MX (1) | MXPA06014097A (ru) |
| RU (1) | RU2353066C2 (ru) |
| TW (1) | TWI357247B (ru) |
| WO (1) | WO2005122509A1 (ru) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2574859C2 (ru) * | 2011-08-10 | 2016-02-10 | Зте Корпорейшн | Способ и устройство для реализации автоматической компенсации асимметричной задержки линии связи, соответствующей стандарту 1588 |
| RU2589341C2 (ru) * | 2011-11-08 | 2016-07-10 | Телефонактиеболагет Л М Эрикссон (Пабл) | Размер элемента мозаичного изображения при кодировании видео |
| RU2617927C2 (ru) * | 2012-10-19 | 2017-04-28 | Самсунг Электроникс Ко., Лтд. | Устройство отображения и его способ управления |
| RU2632152C2 (ru) * | 2013-06-03 | 2017-10-02 | Хуавэй Текнолоджиз Ко., Лтд. | Сетевое устройство и способ управления процессом службы |
| RU2718269C1 (ru) * | 2019-11-27 | 2020-04-01 | Светлана Игоревна Рычкова | Способ восстановления и развития стереозрения |
| RU2733109C1 (ru) * | 2019-12-11 | 2020-09-29 | Общество с ограниченной ответственностью «Интерра» | Способ обмена данными между удаленным устройством и главной ЭВМ |
Families Citing this family (136)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6760772B2 (en) | 2000-12-15 | 2004-07-06 | Qualcomm, Inc. | Generating and implementing a communication protocol and interface for high data rate signal transfer |
| US8812706B1 (en) | 2001-09-06 | 2014-08-19 | Qualcomm Incorporated | Method and apparatus for compensating for mismatched delays in signals of a mobile display interface (MDDI) system |
| KR100884956B1 (ko) * | 2002-08-14 | 2009-02-23 | 엘지전자 주식회사 | 비대칭 양방향 패킷데이터 송수신 방법 및 시스템 |
| ATE517500T1 (de) | 2003-06-02 | 2011-08-15 | Qualcomm Inc | Erzeugung und umsetzung eines signalprotokolls und schnittstelle für höhere datenraten |
| EP2363992A1 (en) | 2003-08-13 | 2011-09-07 | Qualcomm Incorporated | A signal interface for higher data rates |
| AU2004303402A1 (en) | 2003-09-10 | 2005-03-24 | Qualcomm Incorporated | High data rate interface |
| EP1680904A1 (en) | 2003-10-15 | 2006-07-19 | QUALCOMM Incorporated | High data rate interface |
| KR100827573B1 (ko) | 2003-10-29 | 2008-05-07 | 퀄컴 인코포레이티드 | 높은 데이터 레이트 인터페이스 |
| US8606946B2 (en) | 2003-11-12 | 2013-12-10 | Qualcomm Incorporated | Method, system and computer program for driving a data signal in data interface communication data link |
| KR20060096161A (ko) | 2003-11-25 | 2006-09-07 | 콸콤 인코포레이티드 | 향상된 링크 동기화를 제공하는 고속 데이터 레이트인터페이스 |
| EP2247070B1 (en) | 2003-12-08 | 2013-09-25 | QUALCOMM Incorporated | High data rate interface with improved link synchronization |
| CN100584124C (zh) * | 2003-12-19 | 2010-01-20 | 诺基亚公司 | 用于在无线通信设备中选择无线电资源的方法和设备 |
| EP1733537A1 (en) | 2004-03-10 | 2006-12-20 | Qualcomm, Incorporated | High data rate interface apparatus and method |
| CA2560067C (en) | 2004-03-17 | 2011-08-23 | Qualcomm Incorporated | High data rate interface apparatus and method |
| US8650304B2 (en) | 2004-06-04 | 2014-02-11 | Qualcomm Incorporated | Determining a pre skew and post skew calibration data rate in a mobile display digital interface (MDDI) communication system |
| CA2569106C (en) | 2004-06-04 | 2013-05-21 | Qualcomm Incorporated | High data rate interface apparatus and method |
| KR101092438B1 (ko) * | 2004-08-05 | 2011-12-13 | 엘지전자 주식회사 | 케이블 방송 수신기 및 그의 진단 방법 |
| US20060103871A1 (en) * | 2004-11-16 | 2006-05-18 | Erwin Weinans | Methods, apparatus and computer program products supporting display generation in peripheral devices for communications terminals |
| US8873584B2 (en) | 2004-11-24 | 2014-10-28 | Qualcomm Incorporated | Digital data interface device |
| US8539119B2 (en) | 2004-11-24 | 2013-09-17 | Qualcomm Incorporated | Methods and apparatus for exchanging messages having a digital data interface device message format |
| US8692838B2 (en) | 2004-11-24 | 2014-04-08 | Qualcomm Incorporated | Methods and systems for updating a buffer |
| US20060161691A1 (en) * | 2004-11-24 | 2006-07-20 | Behnam Katibian | Methods and systems for synchronous execution of commands across a communication link |
| US8723705B2 (en) | 2004-11-24 | 2014-05-13 | Qualcomm Incorporated | Low output skew double data rate serial encoder |
| US8667363B2 (en) | 2004-11-24 | 2014-03-04 | Qualcomm Incorporated | Systems and methods for implementing cyclic redundancy checks |
| US8699330B2 (en) | 2004-11-24 | 2014-04-15 | Qualcomm Incorporated | Systems and methods for digital data transmission rate control |
| WO2006131021A1 (en) * | 2005-06-07 | 2006-12-14 | Intel Corporation | Error detection and prevention in acoustic data |
| KR100685664B1 (ko) * | 2005-08-12 | 2007-02-26 | 삼성전자주식회사 | 호스트 및 클라이언트로 구성된 데이터 통신 시스템 및데이터 통신 시스템의 작동 방법 |
| US8730069B2 (en) | 2005-11-23 | 2014-05-20 | Qualcomm Incorporated | Double data rate serial encoder |
| US8692839B2 (en) | 2005-11-23 | 2014-04-08 | Qualcomm Incorporated | Methods and systems for updating a buffer |
| US7477526B1 (en) * | 2005-12-29 | 2009-01-13 | Co Ramon S | Branching fully-buffered memory-module with two downlink and one uplink ports |
| US20070153824A1 (en) * | 2005-12-31 | 2007-07-05 | Hong Wong | Uniform corporate client (UCC) usage model |
| US7583320B2 (en) * | 2006-02-13 | 2009-09-01 | Darrell Griffin | Digital image display system |
| US9198084B2 (en) | 2006-05-26 | 2015-11-24 | Qualcomm Incorporated | Wireless architecture for a traditional wire-based protocol |
| JP2009539330A (ja) * | 2006-05-26 | 2009-11-12 | クゥアルコム・インコーポレイテッド | 従来方式の有線ベースのプロトコルのための無線アーキテクチャ |
| US7840732B2 (en) * | 2006-09-25 | 2010-11-23 | Honeywell International Inc. | Stacked card address assignment |
| JP2008085789A (ja) * | 2006-09-28 | 2008-04-10 | Olympus Corp | モバイル機器システムおよびモバイル機器 |
| KR100917889B1 (ko) * | 2006-11-01 | 2009-09-16 | 삼성전자주식회사 | 무선 통신 장치 및 방법 |
| US8565519B2 (en) * | 2007-02-09 | 2013-10-22 | Qualcomm Incorporated | Programmable pattern-based unpacking and packing of data channel information |
| US20080267362A1 (en) * | 2007-04-30 | 2008-10-30 | Lukasik Derek J | Selecting a remote session audio stream sent to a receiving station from one of a plurality of sending stations |
| US8356331B2 (en) * | 2007-05-08 | 2013-01-15 | Qualcomm Incorporated | Packet structure for a mobile display digital interface |
| US8855719B2 (en) * | 2009-05-08 | 2014-10-07 | Kopin Corporation | Wireless hands-free computing headset with detachable accessories controllable by motion, body gesture and/or vocal commands |
| US8667144B2 (en) * | 2007-07-25 | 2014-03-04 | Qualcomm Incorporated | Wireless architecture for traditional wire based protocol |
| WO2009019767A1 (ja) * | 2007-08-08 | 2009-02-12 | Fujitsu Limited | 通信システム、呼制御装置、基地局装置及びコンピュータプログラム |
| US8031626B2 (en) * | 2007-11-13 | 2011-10-04 | Qualcomm Incorporated | Packet structure for a mobile display digital interface |
| US9886231B2 (en) | 2008-03-28 | 2018-02-06 | Kopin Corporation | Head worn wireless computer having high-resolution display suitable for use as a mobile internet device |
| US8811294B2 (en) | 2008-04-04 | 2014-08-19 | Qualcomm Incorporated | Apparatus and methods for establishing client-host associations within a wireless network |
| US9398089B2 (en) | 2008-12-11 | 2016-07-19 | Qualcomm Incorporated | Dynamic resource sharing among multiple wireless devices |
| US8102849B2 (en) | 2009-02-12 | 2012-01-24 | Qualcomm, Incorporated | Association procedure to enable multiple multicast streams |
| JP5521366B2 (ja) * | 2009-03-19 | 2014-06-11 | 日本電気株式会社 | 制御回路及び回路間通信方法 |
| JP5332854B2 (ja) * | 2009-04-20 | 2013-11-06 | ソニー株式会社 | 無線送信機、無線送信方法、無線受信機および無線受信方法 |
| JP5448558B2 (ja) * | 2009-05-01 | 2014-03-19 | ソニー株式会社 | 送信装置、立体画像データの送信方法、受信装置、立体画像データの受信方法、中継装置および立体画像データの中継方法 |
| CN102460349A (zh) * | 2009-05-08 | 2012-05-16 | 寇平公司 | 使用运动和语音命令对主机应用进行远程控制 |
| US9264248B2 (en) | 2009-07-02 | 2016-02-16 | Qualcomm Incorporated | System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment |
| CN103139819B (zh) | 2009-08-28 | 2016-03-30 | 华为技术有限公司 | 确定搜索空间、候选控制信道资源的方法及装置 |
| FR2952463B1 (fr) * | 2009-11-06 | 2012-12-21 | Somfy Sas | Communication d'ordres dans un reseau domotique et entre reseaux domotiques. |
| US9582238B2 (en) | 2009-12-14 | 2017-02-28 | Qualcomm Incorporated | Decomposed multi-stream (DMS) techniques for video display systems |
| TW201122898A (en) * | 2009-12-18 | 2011-07-01 | Hannstar Display Corp | Digital data management system and method. |
| US20110167187A1 (en) * | 2010-01-06 | 2011-07-07 | Apple Inc. | Connectors in a portable device |
| JP5663037B2 (ja) | 2010-01-12 | 2015-02-04 | シリコン イメージ，インコーポレイテッド | 映像および音声用デジタル相互インターフェース（ＤｉｉＶＡ）上のマルチメディアＵＳＢデータ転送 |
| JP5606746B2 (ja) * | 2010-01-27 | 2014-10-15 | 京セラ株式会社 | 携帯端末装置 |
| US8583836B2 (en) * | 2010-02-03 | 2013-11-12 | Stmicroelectronics, Inc. | Packet-based digital display interface signal mapping to bi-directional serial interface signals |
| CN102195665B (zh) * | 2010-03-19 | 2013-12-04 | 奇景光电股份有限公司 | 收发装置及其相关的收发系统 |
| JP5577789B2 (ja) * | 2010-03-25 | 2014-08-27 | ソニー株式会社 | 画像データ送信装置、画像データ送信方法および画像データ受信装置 |
| US8892118B2 (en) | 2010-07-23 | 2014-11-18 | Qualcomm Incorporated | Methods and apparatuses for use in providing position assistance data to mobile stations |
| US8818401B2 (en) | 2010-07-30 | 2014-08-26 | Qualcomm Incorporated | Methods and apparatuses for use in determining that a mobile station is at one or more particular indoor regions |
| US9148763B2 (en) | 2010-07-30 | 2015-09-29 | Qualcomm Incorporated | Methods and apparatuses for mobile station centric determination of positioning assistance data |
| US8706170B2 (en) * | 2010-09-20 | 2014-04-22 | Kopin Corporation | Miniature communications gateway for head mounted display |
| US10013976B2 (en) | 2010-09-20 | 2018-07-03 | Kopin Corporation | Context sensitive overlays in voice controlled headset computer displays |
| US9122307B2 (en) | 2010-09-20 | 2015-09-01 | Kopin Corporation | Advanced remote control of host application using motion and voice commands |
| US8862186B2 (en) * | 2010-09-21 | 2014-10-14 | Kopin Corporation | Lapel microphone micro-display system incorporating mobile information access system |
| KR20120035755A (ko) * | 2010-10-06 | 2012-04-16 | 삼성전기주식회사 | 적응형 지연 조절 기능이 구비된 데이터 인터페이스 장치 |
| RU2550149C2 (ru) | 2010-10-13 | 2015-05-10 | Телефонактиеболагет Л М Эрикссон (Пабл) | Определение асимметрий в сети связи |
| CN102479493B (zh) * | 2010-11-30 | 2014-12-10 | 安凯(广州)微电子技术有限公司 | 一种lcd转换器及基于lcd转换器的数据显示方法 |
| US8964783B2 (en) | 2011-01-21 | 2015-02-24 | Qualcomm Incorporated | User input back channel for wireless displays |
| US9413803B2 (en) | 2011-01-21 | 2016-08-09 | Qualcomm Incorporated | User input back channel for wireless displays |
| US9787725B2 (en) | 2011-01-21 | 2017-10-10 | Qualcomm Incorporated | User input back channel for wireless displays |
| US10135900B2 (en) | 2011-01-21 | 2018-11-20 | Qualcomm Incorporated | User input back channel for wireless displays |
| US9065876B2 (en) | 2011-01-21 | 2015-06-23 | Qualcomm Incorporated | User input back channel from a wireless sink device to a wireless source device for multi-touch gesture wireless displays |
| US9582239B2 (en) | 2011-01-21 | 2017-02-28 | Qualcomm Incorporated | User input back channel for wireless displays |
| US8674957B2 (en) | 2011-02-04 | 2014-03-18 | Qualcomm Incorporated | User input device for wireless back channel |
| US9503771B2 (en) | 2011-02-04 | 2016-11-22 | Qualcomm Incorporated | Low latency wireless display for graphics |
| US10108386B2 (en) | 2011-02-04 | 2018-10-23 | Qualcomm Incorporated | Content provisioning for wireless back channel |
| KR101766835B1 (ko) * | 2011-05-04 | 2017-08-09 | 에스프린팅솔루션 주식회사 | 화상형성장치 및 그 제어 방법 |
| US10627860B2 (en) | 2011-05-10 | 2020-04-21 | Kopin Corporation | Headset computer that uses motion and voice commands to control information display and remote devices |
| US20120324302A1 (en) * | 2011-06-17 | 2012-12-20 | Qualcomm Incorporated | Integrated circuit for testing using a high-speed input/output interface |
| KR101857811B1 (ko) * | 2011-11-16 | 2018-05-15 | 엘지디스플레이 주식회사 | ｅＤＰ 인테페이스 장치와 그를 포함한 표시장치 |
| RU2477928C1 (ru) * | 2011-12-15 | 2013-03-20 | Федеральное государственное военное образовательное учреждение высшего профессионального образования "Военный авиационный инженерный университет" (г. Воронеж) Министерства обороны Российской Федерации | Способ оценки информационной эффективности системы связи |
| CN106406818B (zh) * | 2011-12-22 | 2020-06-16 | 英特尔公司 | 打包数据操作掩码串接处理器、方法、系统及指令 |
| WO2013101438A1 (en) | 2011-12-29 | 2013-07-04 | Kopin Corporation | Wireless hands-free computing head mounted video eyewear for local/remote diagnosis and repair |
| US9525998B2 (en) | 2012-01-06 | 2016-12-20 | Qualcomm Incorporated | Wireless display with multiscreen service |
| US8929954B2 (en) | 2012-04-25 | 2015-01-06 | Kopin Corporation | Headset computer (HSC) as auxiliary display with ASR and HT input |
| WO2013163293A1 (en) | 2012-04-25 | 2013-10-31 | Kopin Corporation | Instant translation system |
| US9442290B2 (en) | 2012-05-10 | 2016-09-13 | Kopin Corporation | Headset computer operation using vehicle sensor feedback for remote control vehicle |
| US9059811B2 (en) * | 2012-05-16 | 2015-06-16 | Microsemi Semiconductor Ulc | Method of adjusting a local clock in asynchronous packet networks |
| US10999171B2 (en) | 2018-08-13 | 2021-05-04 | Accedian Networks Inc. | Method for devices in a network to participate in an end-to-end measurement of latency |
| US8830860B2 (en) * | 2012-07-05 | 2014-09-09 | Accedian Networks Inc. | Method for devices in a network to participate in an end-to-end measurement of latency |
| TWI484333B (zh) * | 2012-07-12 | 2015-05-11 | Phison Electronics Corp | 彈性緩衝器模組及傳輸介面之彈性緩衝方法 |
| US9116639B2 (en) | 2012-12-18 | 2015-08-25 | Apple Inc. | Maintaining synchronization during vertical blanking |
| US9301085B2 (en) | 2013-02-20 | 2016-03-29 | Kopin Corporation | Computer headset with detachable 4G radio |
| US10601943B2 (en) * | 2013-02-27 | 2020-03-24 | Pavlov Media, Inc. | Accelerated network delivery of channelized content |
| US20140269296A1 (en) * | 2013-03-13 | 2014-09-18 | Cox Communications, Inc. | Systems and Methods of Bundled Label Switch Path for Load Splitting |
| US9529749B2 (en) * | 2013-03-15 | 2016-12-27 | Qualcomm Incorporated | Data bus inversion (DBI) encoding based on the speed of operation |
| JP6253307B2 (ja) * | 2013-08-21 | 2017-12-27 | キヤノン株式会社 | 撮像装置、外部装置、撮像システム、撮像装置の制御方法、外部装置の制御方法、撮像システムの制御方法、及びプログラム |
| MY173962A (en) * | 2014-03-19 | 2020-02-28 | Intel Corp | Method, apparatus and system for single-ended communication of transaction layer packets |
| MY187344A (en) | 2014-03-20 | 2021-09-22 | Intel Corp | Method, apparatus and system for configuring a protocol stack of an integrated circuit chip |
| US10129318B2 (en) * | 2014-05-06 | 2018-11-13 | Lattice Semiconductor Corporation | Media stream data and control parameter synchronization |
| US9652816B1 (en) | 2014-09-29 | 2017-05-16 | Apple Inc. | Reduced frame refresh rate |
| KR102237026B1 (ko) * | 2014-11-05 | 2021-04-06 | 주식회사 실리콘웍스 | 디스플레이 장치 |
| US9495926B2 (en) | 2014-12-01 | 2016-11-15 | Apple Inc. | Variable frame refresh rate |
| TWI568224B (zh) * | 2015-04-29 | 2017-01-21 | 財團法人資訊工業策進會 | 異質性網路系統、網路裝置及其聚合路徑選擇方法 |
| US10706825B2 (en) | 2015-09-29 | 2020-07-07 | Apple Inc. | Timestamp based display update mechanism |
| JP6790435B2 (ja) * | 2016-04-20 | 2020-11-25 | ソニー株式会社 | 受信装置、送信装置、および通信システム、ならびに、信号受信方法、信号送信方法、および通信方法 |
| CN107046631A (zh) * | 2017-03-28 | 2017-08-15 | 深圳广世创科技有限公司 | 一种可同时编码2路和以上流媒体的多人无线会议室演示的方法和系统 |
| US20180324061A1 (en) * | 2017-05-03 | 2018-11-08 | Extrahop Networks, Inc. | Detecting network flow states for network traffic analysis |
| RU2685030C2 (ru) * | 2017-07-25 | 2019-04-16 | Федеральное государственное казенное военное образовательное учреждение высшего образования "Военный учебно-научный центр Военно-воздушных сил "Военно-воздушная академия имени профессора Н.Е. Жуковского и Ю.А. Гагарина" (г. Воронеж) Министерства обороны Российской Федерации | Способ оценки эффективности информационного обмена системы связи |
| RU2671623C1 (ru) * | 2017-07-25 | 2018-11-02 | Федеральное государственное казенное военное образовательное учреждение высшего образования "Военный учебно-научный центр Военно-воздушных сил "Военно-воздушная академия имени профессора Н.Е. Жуковского и Ю.А. Гагарина" (г. Воронеж) Министерства обороны Российской Федерации | Устройство оценки эффективности информационного обмена системы связи |
| PL3665935T3 (pl) * | 2017-08-11 | 2024-01-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Węzeł sieci radiowej, urządzenie bezprzewodowe oraz sposoby w nich wykonywane |
| CN107885645B (zh) * | 2017-10-31 | 2020-06-23 | 阿里巴巴集团控股有限公司 | 计算页面首屏渲染时长的方法、装置及电子设备 |
| CN109871856B (zh) * | 2017-12-04 | 2022-03-04 | 北京京东尚科信息技术有限公司 | 一种优化训练样本的方法和装置 |
| US10484165B2 (en) * | 2017-12-19 | 2019-11-19 | Stmicroelectronics International N.V. | Latency buffer circuit with adaptable time shift |
| CN107948188B (zh) * | 2017-12-19 | 2020-07-10 | 中航洛阳光电技术有限公司 | 一种arinc818-dvi协议转换方法 |
| KR102471492B1 (ko) * | 2017-12-27 | 2022-11-28 | 삼성전자 주식회사 | 디스플레이장치 및 그 제어방법 |
| CN110321742B (zh) * | 2018-03-30 | 2021-04-09 | 华为技术有限公司 | 一种检测电子标签的方法及检测装置 |
| RU2691384C1 (ru) * | 2018-07-23 | 2019-06-13 | Акционерное общество "Концерн "Созвездие" | Способ передачи информации широкополосными сигналами |
| CN109407656B (zh) * | 2018-12-29 | 2021-04-09 | 深圳市道通科技股份有限公司 | 车辆中的电子控制单元的扫描方法及其汽车诊断设备 |
| US10862666B2 (en) * | 2019-01-14 | 2020-12-08 | Texas Instruments Incorporated | Sampling point identification for low frequency asynchronous data capture |
| US11165823B2 (en) | 2019-12-17 | 2021-11-02 | Extrahop Networks, Inc. | Automated preemptive polymorphic deception |
| US11175463B2 (en) | 2020-02-21 | 2021-11-16 | Mobix Labs, Inc. | Extendable optical-based data communication cable assembly |
| US11177855B2 (en) * | 2020-02-21 | 2021-11-16 | Mobix Labs, Inc. | Extendable wire-based data communication cable assembly |
| US11165500B2 (en) | 2020-02-21 | 2021-11-02 | Mobix Labs, Inc. | Cascadable data communication cable assembly |
| CN112422360A (zh) * | 2020-10-14 | 2021-02-26 | 锐捷网络股份有限公司 | 一种报文采样方法、装置、设备及介质 |
| CN112558905B (zh) * | 2020-12-09 | 2023-11-10 | 深圳乐播科技有限公司 | 一种投屏方法、设备和系统 |
| CA3221085A1 (en) * | 2021-06-01 | 2022-12-08 | Repairify, Inc. | Remote vehicle communications bitrate determination |
| CN113242194B (zh) * | 2021-06-17 | 2024-07-19 | 浙江地芯引力科技有限公司 | 一种连接装置、耳机及连接转换器 |
| KR20230021258A (ko) * | 2021-08-05 | 2023-02-14 | 삼성전자주식회사 | 외부 전자 장치의 성능 정보에 기반하여 인터페이스의 동작 모드를 설정하는 전자 장치 및 전자 장치의 동작 방법 |
| CN114564099B (zh) * | 2022-01-20 | 2024-06-04 | 珠海亿智电子科技有限公司 | 一种降低usb传输功耗的方法及电子装置 |
Family Cites Families (468)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US2052001A (en) | 1936-02-17 | 1936-08-25 | Leland H Platt | Machine for washing and grading vegetables, fruits or the like |
| US7274652B1 (en) | 2000-06-02 | 2007-09-25 | Conexant, Inc. | Dual packet configuration for wireless communications |
| US3594304A (en) | 1970-04-13 | 1971-07-20 | Sun Oil Co | Thermal liquefaction of coal |
| US4042783A (en) | 1976-08-11 | 1977-08-16 | International Business Machines Corporation | Method and apparatus for byte and frame synchronization on a loop system coupling a CPU channel to bulk storage devices |
| US4393444A (en) | 1980-11-06 | 1983-07-12 | Rca Corporation | Memory addressing circuit for converting sequential input data to interleaved output data sequence using multiple memories |
| US4363123A (en) | 1980-12-01 | 1982-12-07 | Northern Telecom Limited | Method of and apparatus for monitoring digital transmission systems in which line transmission errors are detected |
| JPS57136833A (en) * | 1981-02-17 | 1982-08-24 | Sony Corp | Time-division multiplex data transmitting method |
| US4660096A (en) * | 1984-12-11 | 1987-04-21 | Rca Corporation | Dividing high-resolution-camera video signal response into sub-image blocks individually raster scanned |
| DE3531809A1 (de) * | 1985-09-06 | 1987-03-26 | Kraftwerk Union Ag | Katalysatormaterial zur reduktion von stickoxiden |
| US4769761A (en) | 1986-10-09 | 1988-09-06 | International Business Machines Corporation | Apparatus and method for isolating and predicting errors in a local area network |
| JPS63226762A (ja) | 1987-03-16 | 1988-09-21 | Hitachi Ltd | デ−タ処理方式 |
| US4764805A (en) | 1987-06-02 | 1988-08-16 | Eastman Kodak Company | Image transmission system with line averaging preview mode using two-pass block-edge interpolation |
| US4821296A (en) * | 1987-08-26 | 1989-04-11 | Bell Communications Research, Inc. | Digital phase aligner with outrigger sampling |
| US5227783A (en) | 1987-10-13 | 1993-07-13 | The Regents Of New Mexico State University | Telemetry apparatus and method with digital to analog converter internally integrated within C.P.U. |
| JPH0727571B2 (ja) | 1987-10-26 | 1995-03-29 | テクトロニックス・インコーポレイテッド | ラスタ走査表示装置及び図形データ転送方法 |
| US5155590A (en) | 1990-03-20 | 1992-10-13 | Scientific-Atlanta, Inc. | System for data channel level control |
| US4891805A (en) | 1988-06-13 | 1990-01-02 | Racal Data Communications Inc. | Multiplexer with dynamic bandwidth allocation |
| US5167035A (en) | 1988-09-08 | 1992-11-24 | Digital Equipment Corporation | Transferring messages between nodes in a network |
| US5136717A (en) | 1988-11-23 | 1992-08-04 | Flavors Technology Inc. | Realtime systolic, multiple-instruction, single-data parallel computer system |
| US5079693A (en) * | 1989-02-28 | 1992-01-07 | Integrated Device Technology, Inc. | Bidirectional FIFO buffer having reread and rewrite means |
| US6014705A (en) * | 1991-10-01 | 2000-01-11 | Intermec Ip Corp. | Modular portable data processing terminal having a higher layer and lower layer partitioned communication protocol stack for use in a radio frequency communications network |
| US5224213A (en) | 1989-09-05 | 1993-06-29 | International Business Machines Corporation | Ping-pong data buffer for transferring data from one data bus to another data bus |
| US5495482A (en) | 1989-09-29 | 1996-02-27 | Motorola Inc. | Packet transmission system and method utilizing both a data bus and dedicated control lines |
| US5543939A (en) | 1989-12-28 | 1996-08-06 | Massachusetts Institute Of Technology | Video telephone systems |
| US5138616A (en) | 1990-03-19 | 1992-08-11 | The United States Of America As Represented By The Secretary Of The Army | Continuous on-line link error rate detector utilizing the frame bit error rate |
| US5111455A (en) | 1990-08-24 | 1992-05-05 | Avantek, Inc. | Interleaved time-division multiplexor with phase-compensated frequency doublers |
| US5131012A (en) | 1990-09-18 | 1992-07-14 | At&T Bell Laboratories | Synchronization for cylic redundancy check based, broadband communications network |
| GB2249460B (en) | 1990-09-19 | 1994-06-29 | Intel Corp | Network providing common access to dissimilar hardware interfaces |
| GB2250668B (en) | 1990-11-21 | 1994-07-20 | Apple Computer | Tear-free updates of computer graphical output displays |
| IL100213A (en) | 1990-12-07 | 1995-03-30 | Qualcomm Inc | Mikrata Kedma phone system and its antenna distribution system |
| US5359595A (en) | 1991-01-09 | 1994-10-25 | Rockwell International Corporation | Skywave adaptable network transceiver apparatus and method using a stable probe and traffic protocol |
| US5345542A (en) | 1991-06-27 | 1994-09-06 | At&T Bell Laboratories | Proportional replication mapping system |
| US5231636A (en) | 1991-09-13 | 1993-07-27 | National Semiconductor Corporation | Asynchronous glitchless digital MUX |
| AU664864B2 (en) * | 1991-10-01 | 1995-12-07 | Broadcom Corporation | A radio frequency local area network |
| US5396636A (en) * | 1991-10-21 | 1995-03-07 | International Business Machines Corporation | Remote power control via data link |
| US5751445A (en) | 1991-11-11 | 1998-05-12 | Canon Kk | Image transmission system and terminal device |
| JPH05199387A (ja) * | 1992-01-22 | 1993-08-06 | Fujitsu Ltd | 通信開始速度制御方法 |
| CA2064541C (en) | 1992-03-31 | 1998-09-15 | Thomas A. Gray | Cycling error count for link maintenance |
| US5331642A (en) | 1992-09-01 | 1994-07-19 | International Business Machines Corporation | Management of FDDI physical link errors |
| JP3305769B2 (ja) | 1992-09-18 | 2002-07-24 | 株式会社東芝 | 通信装置 |
| JPH06124147A (ja) | 1992-10-13 | 1994-05-06 | Sanyo Electric Co Ltd | 情報処理装置 |
| GB9222282D0 (en) * | 1992-10-22 | 1992-12-09 | Hewlett Packard Co | Monitoring network status |
| US5513185A (en) * | 1992-11-23 | 1996-04-30 | At&T Corp. | Method and apparatus for transmission link error rate monitoring |
| US5867501A (en) * | 1992-12-17 | 1999-02-02 | Tandem Computers Incorporated | Encoding for communicating data and commands |
| US5619650A (en) * | 1992-12-31 | 1997-04-08 | International Business Machines Corporation | Network processor for transforming a message transported from an I/O channel to a network by adding a message identifier and then converting the message |
| GB9304638D0 (en) * | 1993-03-06 | 1993-04-21 | Ncr Int Inc | Wireless data communication system having power saving function |
| JPH06332664A (ja) | 1993-03-23 | 1994-12-02 | Toshiba Corp | 表示制御システム |
| US5418452A (en) | 1993-03-25 | 1995-05-23 | Fujitsu Limited | Apparatus for testing integrated circuits using time division multiplexing |
| CA2160679A1 (en) | 1993-04-16 | 1994-10-27 | Donald F. Anderson | Liquid stabilizer comprising metal soap and solubilized metal perchlorate |
| JP3197679B2 (ja) | 1993-04-30 | 2001-08-13 | 富士写真フイルム株式会社 | 写真撮影システムおよび方法 |
| US5420858A (en) | 1993-05-05 | 1995-05-30 | Synoptics Communications, Inc. | Method and apparatus for communications from a non-ATM communication medium to an ATM communication medium |
| US5519830A (en) | 1993-06-10 | 1996-05-21 | Adc Telecommunications, Inc. | Point-to-multipoint performance monitoring and failure isolation system |
| JP2768621B2 (ja) | 1993-06-25 | 1998-06-25 | 沖電気工業株式会社 | 分散送信される畳み込み符号の復号装置 |
| US5477534A (en) | 1993-07-30 | 1995-12-19 | Kyocera Corporation | Acoustic echo canceller |
| US5430486A (en) | 1993-08-17 | 1995-07-04 | Rgb Technology | High resolution video image transmission and storage |
| US5426694A (en) | 1993-10-08 | 1995-06-20 | Excel, Inc. | Telecommunication switch having programmable network protocols and communications services |
| US5490247A (en) * | 1993-11-24 | 1996-02-06 | Intel Corporation | Video subsystem for computer-based conferencing system |
| US5510832A (en) * | 1993-12-01 | 1996-04-23 | Medi-Vision Technologies, Inc. | Synthesized stereoscopic imaging system and method |
| US5583562A (en) * | 1993-12-03 | 1996-12-10 | Scientific-Atlanta, Inc. | System and method for transmitting a plurality of digital services including imaging services |
| US5565957A (en) | 1993-12-27 | 1996-10-15 | Nikon Corporation | Camera |
| US5724536A (en) * | 1994-01-04 | 1998-03-03 | Intel Corporation | Method and apparatus for blocking execution of and storing load operations during their execution |
| US5844606A (en) | 1994-03-03 | 1998-12-01 | Fuji Photo Film Co., Ltd. | Videocamera having a multiconnector connectable to a variety of accessories |
| JP2790034B2 (ja) | 1994-03-28 | 1998-08-27 | 日本電気株式会社 | 非運用系メモリ更新方式 |
| US5483185A (en) * | 1994-06-09 | 1996-01-09 | Intel Corporation | Method and apparatus for dynamically switching between asynchronous signals without generating glitches |
| JP3329076B2 (ja) | 1994-06-27 | 2002-09-30 | ソニー株式会社 | ディジタル信号伝送方法、ディジタル信号伝送装置、ディジタル信号受信方法及びディジタル信号受信装置 |
| US5560022A (en) | 1994-07-19 | 1996-09-24 | Intel Corporation | Power management coordinator system and interface |
| US5748891A (en) | 1994-07-22 | 1998-05-05 | Aether Wire & Location | Spread spectrum localizers |
| WO1996003837A1 (de) | 1994-07-25 | 1996-02-08 | Siemens Aktiengesellschaft | Verfahren zum verbindungsaufbau und zum steuern der bildtelefonkommunikation |
| US5664948A (en) | 1994-07-29 | 1997-09-09 | Seiko Communications Holding N.V. | Delivery of data including preloaded advertising data |
| US5733131A (en) * | 1994-07-29 | 1998-03-31 | Seiko Communications Holding N.V. | Education and entertainment device with dynamic configuration and operation |
| JP3592376B2 (ja) | 1994-08-10 | 2004-11-24 | 株式会社アドバンテスト | 時間間隔測定装置 |
| KR100188990B1 (ko) | 1994-09-27 | 1999-06-01 | 이리마지리 쇼우이치로 | 데이타 중계 장치 및 이것을 이용한 비디오 게임 장치 |
| GB2296123B (en) * | 1994-12-13 | 1998-08-12 | Ibm | Midi playback system |
| US5559459A (en) | 1994-12-29 | 1996-09-24 | Stratus Computer, Inc. | Clock signal generation arrangement including digital noise reduction circuit for reducing noise in a digital clocking signal |
| FR2729528A1 (fr) | 1995-01-13 | 1996-07-19 | Suisse Electronique Microtech | Circuit de multiplexage |
| GB2298109B (en) | 1995-02-14 | 1999-09-01 | Nokia Mobile Phones Ltd | Data interface |
| US5530704A (en) | 1995-02-16 | 1996-06-25 | Motorola, Inc. | Method and apparatus for synchronizing radio ports in a commnuication system |
| US5646947A (en) | 1995-03-27 | 1997-07-08 | Westinghouse Electric Corporation | Mobile telephone single channel per carrier superframe lock subsystem |
| US6117681A (en) | 1995-03-29 | 2000-09-12 | Bavarian Nordic Research Inst. A/S | Pseudotyped retroviral particles |
| US6400392B1 (en) | 1995-04-11 | 2002-06-04 | Matsushita Electric Industrial Co., Ltd. | Video information adjusting apparatus, video information transmitting apparatus and video information receiving apparatus |
| US5521907A (en) | 1995-04-25 | 1996-05-28 | Visual Networks, Inc. | Method and apparatus for non-intrusive measurement of round trip delay in communications networks |
| SE506540C2 (sv) | 1995-06-13 | 1998-01-12 | Ericsson Telefon Ab L M | Synkronisering av överföring av data via en dubbelriktad länk |
| US5963564A (en) | 1995-06-13 | 1999-10-05 | Telefonaktiebolaget Lm Ericsson | Synchronizing the transmission of data via a two-way link |
| JPH0923243A (ja) | 1995-07-10 | 1997-01-21 | Hitachi Ltd | 電子紙面情報配信システム |
| US6055247A (en) * | 1995-07-13 | 2000-04-25 | Sony Corporation | Data transmission method, data transmission apparatus and data transmission system |
| JPH0936871A (ja) | 1995-07-17 | 1997-02-07 | Sony Corp | データ伝送システムおよびデータ伝送方法 |
| US5604450A (en) * | 1995-07-27 | 1997-02-18 | Intel Corporation | High speed bidirectional signaling scheme |
| JPH0955667A (ja) * | 1995-08-10 | 1997-02-25 | Mitsubishi Electric Corp | マルチプレクサ，及びデマルチプレクサ |
| US5742840A (en) | 1995-08-16 | 1998-04-21 | Microunity Systems Engineering, Inc. | General purpose, multiple precision parallel operation, programmable media processor |
| KR100272472B1 (ko) * | 1995-09-19 | 2000-11-15 | 씨. 필립 채프맨 | 디지탈 프로그램가능 임계 레벨을 가진 마이크로컨트롤러 재작동 기능 |
| US5748642A (en) | 1995-09-25 | 1998-05-05 | Credence Systems Corporation | Parallel processing integrated circuit tester |
| US5732352A (en) * | 1995-09-29 | 1998-03-24 | Motorola, Inc. | Method and apparatus for performing handoff in a wireless communication system |
| US5550489A (en) | 1995-09-29 | 1996-08-27 | Quantum Corporation | Secondary clock source for low power, fast response clocking |
| US5818255A (en) | 1995-09-29 | 1998-10-06 | Xilinx, Inc. | Method and circuit for using a function generator of a programmable logic device to implement carry logic functions |
| US5751951A (en) | 1995-10-30 | 1998-05-12 | Mitsubishi Electric Information Technology Center America, Inc. | Network interface |
| TW316965B (ru) | 1995-10-31 | 1997-10-01 | Cirrus Logic Inc | |
| US5958006A (en) | 1995-11-13 | 1999-09-28 | Motorola, Inc. | Method and apparatus for communicating summarized data |
| US7003796B1 (en) * | 1995-11-22 | 2006-02-21 | Samsung Information Systems America | Method and apparatus for recovering data stream clock |
| US5844918A (en) | 1995-11-28 | 1998-12-01 | Sanyo Electric Co., Ltd. | Digital transmission/receiving method, digital communications method, and data receiving apparatus |
| US5790551A (en) | 1995-11-28 | 1998-08-04 | At&T Wireless Services Inc. | Packet data transmission using dynamic channel assignment |
| US6865610B2 (en) * | 1995-12-08 | 2005-03-08 | Microsoft Corporation | Wire protocol for a media server system |
| EP0781068A1 (en) | 1995-12-20 | 1997-06-25 | International Business Machines Corporation | Method and system for adaptive bandwidth allocation in a high speed data network |
| JP3427149B2 (ja) | 1996-01-26 | 2003-07-14 | 三菱電機株式会社 | 符号化信号の復号回路及びその同期制御方法， 同期検出回路及び同期検出方法 |
| US5903281A (en) | 1996-03-07 | 1999-05-11 | Powertv, Inc. | List controlled video operations |
| US6243596B1 (en) | 1996-04-10 | 2001-06-05 | Lextron Systems, Inc. | Method and apparatus for modifying and integrating a cellular phone with the capability to access and browse the internet |
| US5815507A (en) | 1996-04-15 | 1998-09-29 | Motorola, Inc. | Error detector circuit for digital receiver using variable threshold based on signal quality |
| US6130602A (en) | 1996-05-13 | 2000-10-10 | Micron Technology, Inc. | Radio frequency data communications device |
| JPH09307457A (ja) | 1996-05-14 | 1997-11-28 | Sony Corp | パラレルシリアル変換回路 |
| US5982362A (en) | 1996-05-30 | 1999-11-09 | Control Technology Corporation | Video interface architecture for programmable industrial control systems |
| US5983261A (en) | 1996-07-01 | 1999-11-09 | Apple Computer, Inc. | Method and apparatus for allocating bandwidth in teleconferencing applications using bandwidth control |
| GB9614561D0 (en) | 1996-07-11 | 1996-09-04 | 4Links Ltd | Communication system with improved code |
| US6298387B1 (en) | 1996-07-12 | 2001-10-02 | Philips Electronics North America Corp | System for detecting a data packet in a bitstream by storing data from the bitstream in a buffer and comparing data at different locations in the buffer to predetermined data |
| KR100221028B1 (ko) | 1996-07-23 | 1999-09-15 | 윤종용 | 그래픽 가속기 및 이를 이용한 메모리 프리패치 방법 |
| US6886035B2 (en) | 1996-08-02 | 2005-04-26 | Hewlett-Packard Development Company, L.P. | Dynamic load balancing of a network of client and server computer |
| US6185601B1 (en) * | 1996-08-02 | 2001-02-06 | Hewlett-Packard Company | Dynamic load balancing of a network of client and server computers |
| US5969750A (en) | 1996-09-04 | 1999-10-19 | Winbcnd Electronics Corporation | Moving picture camera with universal serial bus interface |
| CA2214743C (en) | 1996-09-20 | 2002-03-05 | Ntt Mobile Communications Network Inc. | A frame synchronization circuit and communications system |
| US5990852A (en) | 1996-10-31 | 1999-11-23 | Fujitsu Limited | Display screen duplication system and method |
| US5864546A (en) * | 1996-11-05 | 1999-01-26 | Worldspace International Network, Inc. | System for formatting broadcast data for satellite transmission and radio reception |
| US6308239B1 (en) | 1996-11-07 | 2001-10-23 | Hitachi, Ltd. | Interface switching apparatus and switching control method |
| US6078361A (en) | 1996-11-18 | 2000-06-20 | Sage, Inc | Video adapter circuit for conversion of an analog video signal to a digital display image |
| US6002709A (en) | 1996-11-21 | 1999-12-14 | Dsp Group, Inc. | Verification of PN synchronization in a direct-sequence spread-spectrum digital communications system |
| KR100211918B1 (ko) | 1996-11-30 | 1999-08-02 | 김영환 | 비동기식전송모드셀 경계 식별장치 |
| US5862160A (en) * | 1996-12-31 | 1999-01-19 | Ericsson, Inc. | Secondary channel for communication networks |
| US5995512A (en) | 1997-01-17 | 1999-11-30 | Delco Electronics Corporation | High speed multimedia data network |
| US6064649A (en) | 1997-01-31 | 2000-05-16 | Nec Usa, Inc. | Network interface card for wireless asynchronous transfer mode networks |
| US6081513A (en) | 1997-02-10 | 2000-06-27 | At&T Corp. | Providing multimedia conferencing services over a wide area network interconnecting nonguaranteed quality of services LANs |
| EP0859326A3 (en) | 1997-02-14 | 1999-05-12 | Canon Kabushiki Kaisha | Data transmission apparatus, system and method, and image processing apparatus |
| US6584144B2 (en) | 1997-02-24 | 2003-06-24 | At&T Wireless Services, Inc. | Vertical adaptive antenna array for a discrete multitone spread spectrum communications system |
| US6359923B1 (en) | 1997-12-18 | 2002-03-19 | At&T Wireless Services, Inc. | Highly bandwidth efficient communications |
| DE19733005B4 (de) | 1997-03-12 | 2007-06-21 | Storz Endoskop Gmbh | Einrichtung zur zentralen Überwachung und/oder Steuerung wenigstens eines Gerätes |
| US6480521B1 (en) | 1997-03-26 | 2002-11-12 | Qualcomm Incorporated | Method and apparatus for transmitting high speed data in a spread spectrum communications system |
| US7143177B1 (en) | 1997-03-31 | 2006-11-28 | West Corporation | Providing a presentation on a network having a plurality of synchronized media types |
| US5963557A (en) | 1997-04-11 | 1999-10-05 | Eng; John W. | High capacity reservation multiple access network with multiple shared unidirectional paths |
| US6405111B2 (en) | 1997-05-16 | 2002-06-11 | Snap-On Technologies, Inc. | System and method for distributed computer automotive service equipment |
| JP3143079B2 (ja) | 1997-05-30 | 2001-03-07 | 松下電器産業株式会社 | 辞書索引作成装置と文書検索装置 |
| US5867510A (en) * | 1997-05-30 | 1999-02-02 | Motorola, Inc. | Method of and apparatus for decoding and processing messages |
| KR100550190B1 (ko) * | 1997-06-03 | 2006-04-21 | 소니 가부시끼 가이샤 | 휴대용정보처리장치의제어방법,및휴대용정보처리장치 |
| US6236647B1 (en) | 1998-02-24 | 2001-05-22 | Tantivy Communications, Inc. | Dynamic frame size adjustment and selective reject on a multi-link channel to improve effective throughput and bit error rate |
| US6314479B1 (en) | 1997-08-04 | 2001-11-06 | Compaq Computer Corporation | Universal multi-pin plug and display connector for standardizing signals transmitted between a computer and a display for a PC theatre interconnectivity system |
| WO1999010719A1 (en) | 1997-08-29 | 1999-03-04 | The Regents Of The University Of California | Method and apparatus for hybrid coding of speech at 4kbps |
| US6288739B1 (en) | 1997-09-05 | 2001-09-11 | Intelect Systems Corporation | Distributed video communications system |
| US6470386B1 (en) | 1997-09-26 | 2002-10-22 | Worldcom, Inc. | Integrated proxy interface for web based telecommunications management tools |
| ATE429080T1 (de) | 1997-10-14 | 2009-05-15 | Cypress Semiconductor Corp | Digitaler funksendeempfänger |
| US6574211B2 (en) | 1997-11-03 | 2003-06-03 | Qualcomm Incorporated | Method and apparatus for high rate packet data transmission |
| US6894994B1 (en) | 1997-11-03 | 2005-05-17 | Qualcomm Incorporated | High data rate wireless packet data communications system |
| TW408315B (en) | 1997-11-07 | 2000-10-11 | Sharp Kk | Magnetic recording device, magnetic recording and reproducing device, and magnetic recording method |
| US6246876B1 (en) | 1997-11-13 | 2001-06-12 | Telefonaktiebolaget L M Ericsson (Publ) | Synchronization messages for hand-off operations |
| US6091709A (en) | 1997-11-25 | 2000-07-18 | International Business Machines Corporation | Quality of service management for packet switched networks |
| US20010012293A1 (en) | 1997-12-02 | 2001-08-09 | Lars-Goran Petersen | Simultaneous transmission of voice and non-voice data on a single narrowband connection |
| US6049837A (en) * | 1997-12-08 | 2000-04-11 | International Business Machines Corporation | Programmable output interface for lower level open system interconnection architecture |
| US6393008B1 (en) | 1997-12-23 | 2002-05-21 | Nokia Movile Phones Ltd. | Control structures for contention-based packet data services in wideband CDMA |
| KR100286080B1 (ko) | 1997-12-30 | 2001-04-16 | 윤종용 | 데이터링크를이용한데이터송신및수신방법 |
| KR100251963B1 (ko) * | 1997-12-31 | 2000-04-15 | 윤종용 | 종합정보통신망과 연동 가능한 비동기전송모드 망 접속영상전화 단말장치 |
| TW459184B (en) | 1998-01-23 | 2001-10-11 | Shiu Ming Wei | Multimedia message processing system |
| US6833863B1 (en) | 1998-02-06 | 2004-12-21 | Intel Corporation | Method and apparatus for still image capture during video streaming operations of a tethered digital camera |
| EP1057070B1 (en) | 1998-02-20 | 2011-03-02 | PureDepth Limited | A multi-layer display and a method for displaying images on such a display |
| JP3004618B2 (ja) | 1998-02-27 | 2000-01-31 | キヤノン株式会社 | 画像入力装置及び画像入力システム及び画像送受信システム及び画像入力方法及び記憶媒体 |
| JPH11249987A (ja) | 1998-03-05 | 1999-09-17 | Nec Corp | メッセージ処理装置およびその方法ならびにメッセージ処理制御プログラムを格納した記憶媒体 |
| EP1064767B8 (en) | 1998-03-16 | 2007-06-27 | Jazio Inc. | High speed signaling for interfacing vlsi cmos circuits |
| DE69927198T2 (de) | 1998-03-19 | 2006-06-29 | Hitachi, Ltd. | Rundfunk-Informationsversorgungssystem |
| US6243761B1 (en) | 1998-03-26 | 2001-06-05 | Digital Equipment Corporation | Method for dynamically adjusting multimedia content of a web page by a server in accordance to network path characteristics between client and server |
| US6199169B1 (en) * | 1998-03-31 | 2001-03-06 | Compaq Computer Corporation | System and method for synchronizing time across a computer cluster |
| CN1327630C (zh) | 1998-04-01 | 2007-07-18 | 松下图像通信系统公司 | 带有隐式信道探头的多种xDSL调制解调器的启动 |
| US6252888B1 (en) | 1998-04-14 | 2001-06-26 | Nortel Networks Corporation | Method and apparatus providing network communications between devices using frames with multiple formats |
| US6101601A (en) | 1998-04-20 | 2000-08-08 | International Business Machines Corporation | Method and apparatus for hibernation within a distributed data processing system |
| US6430196B1 (en) | 1998-05-01 | 2002-08-06 | Cisco Technology, Inc. | Transmitting delay sensitive information over IP over frame relay |
| KR100413417B1 (ko) | 1998-05-04 | 2004-02-14 | 엘지전자 주식회사 | 이동통신시스템에서 단말기의 호 접속 제어 방법. |
| US6611503B1 (en) | 1998-05-22 | 2003-08-26 | Tandberg Telecom As | Method and apparatus for multimedia conferencing with dynamic bandwidth allocation |
| JP3792894B2 (ja) | 1998-05-27 | 2006-07-05 | キヤノン株式会社 | 固体撮像素子及び固体撮像装置 |
| US6043693A (en) | 1998-06-01 | 2000-03-28 | 3Dfx Interactive, Incorporated | Multiplexed synchronization circuits for switching frequency synthesized signals |
| US6850282B1 (en) * | 1998-06-02 | 2005-02-01 | Canon Kabushiki Kaisha | Remote control of image sensing apparatus |
| JP3475081B2 (ja) | 1998-06-03 | 2003-12-08 | 三洋電機株式会社 | 立体映像再生方法 |
| US6092231A (en) | 1998-06-12 | 2000-07-18 | Qlogic Corporation | Circuit and method for rapid checking of error correction codes using cyclic redundancy check |
| JP4267092B2 (ja) | 1998-07-07 | 2009-05-27 | 富士通株式会社 | 時刻同期方法 |
| US6510503B2 (en) | 1998-07-27 | 2003-01-21 | Mosaid Technologies Incorporated | High bandwidth memory interface |
| US6359479B1 (en) * | 1998-08-04 | 2002-03-19 | Juniper Networks, Inc. | Synchronizing data transfers between two distinct clock domains |
| US6532506B1 (en) * | 1998-08-12 | 2003-03-11 | Intel Corporation | Communicating with devices over a bus and negotiating the transfer rate over the same |
| US6728263B2 (en) | 1998-08-18 | 2004-04-27 | Microsoft Corporation | Dynamic sizing of data packets |
| JP2002525913A (ja) | 1998-09-11 | 2002-08-13 | シェアウェーブ・インコーポレーテッド | コンピュータ・ネットワーク内の通信を制御するための方法および装置 |
| JP2000188626A (ja) | 1998-10-13 | 2000-07-04 | Texas Instr Inc <Ti> | 一体のマイクロコントロ―ラ・エミュレ―タを有するリンク／トランザクション層コントロ―ラ |
| US6259745B1 (en) | 1998-10-30 | 2001-07-10 | Broadcom Corporation | Integrated Gigabit Ethernet transmitter architecture |
| US7180951B2 (en) * | 1998-10-30 | 2007-02-20 | Broadcom Corporation | Reduction of aggregate EMI emissions of multiple transmitters |
| US6421735B1 (en) | 1998-10-30 | 2002-07-16 | Advanced Micro Devices, Inc. | Apparatus and method for automatically selecting a network port for a home network station |
| TW466410B (en) | 2000-06-16 | 2001-12-01 | Via Tech Inc | Cache device inside peripheral component interface chipset and data synchronous method to externals |
| US6836829B2 (en) | 1998-11-20 | 2004-12-28 | Via Technologies, Inc. | Peripheral device interface chip cache and data synchronization method |
| US6545979B1 (en) | 1998-11-27 | 2003-04-08 | Alcatel Canada Inc. | Round trip delay measurement |
| US6363439B1 (en) * | 1998-12-07 | 2002-03-26 | Compaq Computer Corporation | System and method for point-to-point serial communication between a system interface device and a bus interface device in a computer system |
| US6791379B1 (en) | 1998-12-07 | 2004-09-14 | Broadcom Corporation | Low jitter high phase resolution PLL-based timing recovery system |
| KR100315670B1 (ko) | 1998-12-07 | 2001-11-29 | 윤종용 | 부호분할다중접속 통신시스템의 단속 송신장치 및 방법 |
| US6297684B1 (en) | 1998-12-14 | 2001-10-02 | Seiko Epson Corporation | Circuit and method for switching between digital signals that have different signal rates |
| JP3557975B2 (ja) | 1998-12-14 | 2004-08-25 | セイコーエプソン株式会社 | 信号切り替え回路及び信号切り替え方法 |
| US6252526B1 (en) | 1998-12-14 | 2001-06-26 | Seiko Epson Corporation | Circuit and method for fast parallel data strobe encoding |
| JP2000196986A (ja) | 1998-12-25 | 2000-07-14 | Olympus Optical Co Ltd | 電子的撮像装置 |
| US6950428B1 (en) | 1998-12-30 | 2005-09-27 | Hewlett-Packard Development Company, L.P. | System and method for configuring adaptive sets of links between routers in a system area network (SAN) |
| US6549538B1 (en) | 1998-12-31 | 2003-04-15 | Compaq Information Technologies Group, L.P. | Computer method and apparatus for managing network ports cluster-wide using a lookaside list |
| JP3635614B2 (ja) | 1999-01-26 | 2005-04-06 | 株式会社リコー | 機械音処理装置 |
| US6836469B1 (en) | 1999-01-15 | 2004-12-28 | Industrial Technology Research Institute | Medium access control protocol for a multi-channel communication system |
| JP2000216843A (ja) | 1999-01-22 | 2000-08-04 | Oki Electric Ind Co Ltd | デジタル復調器 |
| US6636508B1 (en) | 1999-02-12 | 2003-10-21 | Nortel Networks Limted | Network resource conservation system |
| US6493824B1 (en) | 1999-02-19 | 2002-12-10 | Compaq Information Technologies Group, L.P. | Secure system for remotely waking a computer in a power-down state |
| US6199099B1 (en) | 1999-03-05 | 2001-03-06 | Ac Properties B.V. | System, method and article of manufacture for a mobile communication network utilizing a distributed communication network |
| EP1163607A2 (en) | 1999-03-05 | 2001-12-19 | Accenture LLP | Method and apparatus for creating an information summary |
| JP4181685B2 (ja) * | 1999-03-12 | 2008-11-19 | 富士通株式会社 | 電力制御方法及び電子機器並びに記録媒体 |
| US6429867B1 (en) | 1999-03-15 | 2002-08-06 | Sun Microsystems, Inc. | System and method for generating and playback of three-dimensional movies |
| US6636922B1 (en) | 1999-03-17 | 2003-10-21 | Adaptec, Inc. | Methods and apparatus for implementing a host side advanced serial protocol |
| US6609167B1 (en) | 1999-03-17 | 2003-08-19 | Adaptec, Inc. | Host and device serial communication protocols and communication packet formats |
| FI107424B (fi) | 1999-03-22 | 2001-07-31 | Nokia Mobile Phones Ltd | Menetelmä ja järjestelmä multimediaan liittyvän informaation välittämiseen valmistautumiseksi pakettikytkentäisessä solukkoradioverkossa |
| JP2000278141A (ja) | 1999-03-26 | 2000-10-06 | Mitsubishi Electric Corp | マルチプレクサ |
| KR100350607B1 (ko) | 1999-03-31 | 2002-08-28 | 삼성전자 주식회사 | 음성 및 화상 송수신을 위한 휴대용 복합 통신단말기 및 그 동작방법과 통신시스템 |
| US6222677B1 (en) * | 1999-04-12 | 2001-04-24 | International Business Machines Corporation | Compact optical system for use in virtual display applications |
| JP2000358033A (ja) | 1999-06-14 | 2000-12-26 | Canon Inc | データ通信システム及びデータ通信方法 |
| US6618360B1 (en) | 1999-06-15 | 2003-09-09 | Hewlett-Packard Development Company, L.P. | Method for testing data path of peripheral server devices |
| US6457090B1 (en) | 1999-06-30 | 2002-09-24 | Adaptec, Inc. | Structure and method for automatic configuration for SCSI Synchronous data transfers |
| JP2001025010A (ja) | 1999-07-09 | 2001-01-26 | Mitsubishi Electric Corp | マルチメディア情報通信装置およびその方法 |
| US6865609B1 (en) * | 1999-08-17 | 2005-03-08 | Sharewave, Inc. | Multimedia extensions for wireless local area network |
| US6597197B1 (en) | 1999-08-27 | 2003-07-22 | Intel Corporation | I2C repeater with voltage translation |
| KR20010019734A (ko) | 1999-08-30 | 2001-03-15 | 윤종용 | 유무선 통신을 이용한 컴퓨터 교육용 시스템 |
| US7010607B1 (en) * | 1999-09-15 | 2006-03-07 | Hewlett-Packard Development Company, L.P. | Method for training a communication link between ports to correct for errors |
| JP3116090B1 (ja) | 1999-09-17 | 2000-12-11 | 郵政省通信総合研究所長 | 通信システム、送信装置、受信装置、送信方法、受信方法、および、情報記録媒体 |
| JP4207329B2 (ja) * | 1999-09-20 | 2009-01-14 | 富士通株式会社 | フレーム同期回路 |
| US6782277B1 (en) | 1999-09-30 | 2004-08-24 | Qualcomm Incorporated | Wireless communication system with base station beam sweeping |
| US6678751B1 (en) | 1999-10-15 | 2004-01-13 | Micro Motion, Inc. | System for setting frame and protocol for transmission in a UART device |
| US6643787B1 (en) | 1999-10-19 | 2003-11-04 | Rambus Inc. | Bus system optimization |
| US6662322B1 (en) | 1999-10-29 | 2003-12-09 | International Business Machines Corporation | Systems, methods, and computer program products for controlling the error rate in a communication device by adjusting the distance between signal constellation points |
| WO2001035544A1 (de) | 1999-11-11 | 2001-05-17 | Ascom Powerline Communications Ag | Kommunikationssystem insbesondere für den indoor-bereich |
| US6438363B1 (en) | 1999-11-15 | 2002-08-20 | Lucent Technologies Inc. | Wireless modem alignment in a multi-cell environment |
| EP1232604B1 (en) | 1999-11-16 | 2003-10-15 | Broadcom Corporation | Method and network switch with data serialization using hazard-free multilevel glitchless multiplexing |
| WO2001038982A1 (en) | 1999-11-22 | 2001-05-31 | Seagate Technology Llc | Peer to peer interconnect diagnostics |
| TW513636B (en) | 2000-06-30 | 2002-12-11 | Via Tech Inc | Bus data interface for transmitting data on PCI bus, the structure and the operating method thereof |
| US6804257B1 (en) | 1999-11-25 | 2004-10-12 | International Business Machines Corporation | System and method for framing and protecting variable-lenght packet streams |
| JP4058888B2 (ja) * | 1999-11-29 | 2008-03-12 | セイコーエプソン株式会社 | Ｒａｍ内蔵ドライバ並びにそれを用いた表示ユニットおよび電子機器 |
| JP4191869B2 (ja) | 1999-12-20 | 2008-12-03 | 富士フイルム株式会社 | ディジタルカメラを用いたコンピュータシステム |
| US7383350B1 (en) | 2000-02-03 | 2008-06-03 | International Business Machines Corporation | User input based allocation of bandwidth on a data link |
| US6778493B1 (en) | 2000-02-07 | 2004-08-17 | Sharp Laboratories Of America, Inc. | Real-time media content synchronization and transmission in packet network apparatus and method |
| JP3490368B2 (ja) | 2000-02-07 | 2004-01-26 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 信号出力装置、ドライバ回路、信号伝送システム、および信号伝送方法 |
| JP2001236304A (ja) | 2000-02-21 | 2001-08-31 | Mitsubishi Electric Corp | マイクロコンピュータ |
| JP4449141B2 (ja) | 2000-02-22 | 2010-04-14 | ソニー株式会社 | 電源制御装置、電源制御システム |
| US6477150B1 (en) | 2000-03-03 | 2002-11-05 | Qualcomm, Inc. | System and method for providing group communication services in an existing communication system |
| EP2273812B1 (en) | 2000-03-03 | 2012-07-18 | Qualcomm Incorporated | Method and apparatus for synchronizing encryption and decryption of a data frame in a communication network |
| JP2001282714A (ja) | 2000-03-30 | 2001-10-12 | Olympus Optical Co Ltd | マルチカメラデータ転送方式及びデータ転送方式 |
| JP2001292146A (ja) | 2000-04-07 | 2001-10-19 | Sony Corp | 電子機器およびディジタルシリアルデータのインタフェース装置のバス初期化フェーズにおける処理方法 |
| US6882361B1 (en) | 2000-04-19 | 2005-04-19 | Pixelworks, Inc. | Imager linked with image processing station |
| JP2001306428A (ja) | 2000-04-25 | 2001-11-02 | Canon Inc | ネットワーク機器、ネットワークシステム、通信方法及び記録媒体 |
| JP2001319745A (ja) | 2000-05-08 | 2001-11-16 | Honda Tsushin Kogyo Co Ltd | 変換用アダプタ |
| JP2001320280A (ja) * | 2000-05-10 | 2001-11-16 | Mitsubishi Electric Corp | 並列−直列変換回路 |
| US6760722B1 (en) | 2000-05-16 | 2004-07-06 | International Business Machines Corporation | Computer implemented automated remote support |
| JP4292685B2 (ja) | 2000-05-23 | 2009-07-08 | 日本電気株式会社 | データ転送システム、データ送受信システム、データ送受信方法、フォーマット変換装置、フォーマット変換方法およびフォーマット変換プログラムを記録したコンピュータ読み取り可能な記録媒体 |
| KR100360622B1 (ko) | 2000-06-12 | 2002-11-13 | 주식회사 문화방송 | 엠펙 데이터 프레임과 이를 이용한 송수신 시스템 |
| US6754179B1 (en) | 2000-06-13 | 2004-06-22 | Lsi Logic Corporation | Real time control of pause frame transmissions for improved bandwidth utilization |
| JP3415567B2 (ja) | 2000-06-21 | 2003-06-09 | エヌイーシーマイクロシステム株式会社 | Ｕｓｂ転送制御方法およびｕｓｂコントローラ |
| US6714233B2 (en) * | 2000-06-21 | 2004-03-30 | Seiko Epson Corporation | Mobile video telephone system |
| US6999432B2 (en) | 2000-07-13 | 2006-02-14 | Microsoft Corporation | Channel and quality of service adaptation for multimedia over wireless networks |
| US20020080166A1 (en) | 2000-08-08 | 2002-06-27 | Sweatt Millard E. | Method and system for remote television replay control |
| JP4825372B2 (ja) | 2000-08-09 | 2011-11-30 | エスケーテレコム株式会社 | 逆方向同期伝送方式を支援する無線通信システムにおけるハンドオーバ方法 |
| US6784941B1 (en) | 2000-08-09 | 2004-08-31 | Sunplus Technology Co., Ltd. | Digital camera with video input |
| JP2002062990A (ja) | 2000-08-15 | 2002-02-28 | Fujitsu Media Device Kk | インターフェイス装置 |
| US6725412B1 (en) | 2000-08-15 | 2004-04-20 | Dolby Laboratories Licensing Corporation | Low latency data encoder |
| US6721810B2 (en) * | 2000-08-31 | 2004-04-13 | Siemens Energy & Automation | Universal controller expansion module system, method and apparatus |
| GB2366926A (en) | 2000-09-06 | 2002-03-20 | Sony Uk Ltd | Combining material and data |
| US6747964B1 (en) | 2000-09-15 | 2004-06-08 | Qualcomm Incorporated | Method and apparatus for high data rate transmission in a wireless communication system |
| US7138989B2 (en) | 2000-09-15 | 2006-11-21 | Silicon Graphics, Inc. | Display capable of displaying images in response to signals of a plurality of signal formats |
| US7466978B1 (en) | 2000-09-18 | 2008-12-16 | International Business Machines Corporation | Telephone network node device |
| JP4146991B2 (ja) | 2000-09-18 | 2008-09-10 | キヤノン株式会社 | 電子カメラシステム、電子カメラ及び電子カメラシステムの制御方法 |
| US6760882B1 (en) | 2000-09-19 | 2004-07-06 | Intel Corporation | Mode selection for data transmission in wireless communication channels based on statistical parameters |
| CA2319985A1 (en) * | 2000-09-20 | 2002-03-20 | Cervelo Cycles Inc. | Aerodynamic bicycle frame |
| US6738344B1 (en) | 2000-09-27 | 2004-05-18 | Hewlett-Packard Development Company, L.P. | Link extenders with link alive propagation |
| US7336613B2 (en) * | 2000-10-17 | 2008-02-26 | Avaya Technology Corp. | Method and apparatus for the assessment and optimization of network traffic |
| US6690655B1 (en) | 2000-10-19 | 2004-02-10 | Motorola, Inc. | Low-powered communication system and method of operation |
| US7869067B2 (en) | 2000-10-20 | 2011-01-11 | Visioneer, Inc. | Combination scanner and image data reader system including image management and software |
| US7278069B2 (en) | 2000-10-31 | 2007-10-02 | Igor Anatolievich Abrosimov | Data transmission apparatus for high-speed transmission of digital data and method for automatic skew calibration |
| US8996698B1 (en) | 2000-11-03 | 2015-03-31 | Truphone Limited | Cooperative network for mobile internet access |
| JP3714933B2 (ja) | 2000-11-17 | 2005-11-09 | サムスン エレクトロニクス カンパニー リミテッド | 狭帯域時分割デュプレキシング符号分割多重接続移動通信システムにおける伝播遅延測定装置及び方法 |
| US7464877B2 (en) | 2003-11-13 | 2008-12-16 | Metrologic Instruments, Inc. | Digital imaging-based bar code symbol reading system employing image cropping pattern generator and automatic cropped image processor |
| FI115802B (fi) | 2000-12-04 | 2005-07-15 | Nokia Corp | Kuvakehyksien päivittäminen muistillisessa näytössä |
| GB2397733B (en) | 2000-12-06 | 2004-10-06 | Fujitsu Ltd | Clock recovery circuitry |
| US6973039B2 (en) | 2000-12-08 | 2005-12-06 | Bbnt Solutions Llc | Mechanism for performing energy-based routing in wireless networks |
| KR100944843B1 (ko) * | 2000-12-15 | 2010-03-04 | 콸콤 인코포레이티드 | 높은 데이터 레이트의 신호 전송을 위한 통신 프로토콜 및 인터페이스의 형성과 구현 |
| US6760772B2 (en) * | 2000-12-15 | 2004-07-06 | Qualcomm, Inc. | Generating and implementing a communication protocol and interface for high data rate signal transfer |
| US7023924B1 (en) | 2000-12-28 | 2006-04-04 | Emc Corporation | Method of pausing an MPEG coded video stream |
| JP2002208844A (ja) | 2001-01-12 | 2002-07-26 | Nec Eng Ltd | グリッチ除去回路 |
| US6947436B2 (en) | 2001-02-01 | 2005-09-20 | Motorola, Inc. | Method for optimizing forward link data transmission rates in spread-spectrum communications systems |
| US7301968B2 (en) | 2001-03-02 | 2007-11-27 | Pmc-Sierra Israel Ltd. | Communication protocol for passive optical network topologies |
| KR20020071226A (ko) | 2001-03-05 | 2002-09-12 | 삼성전자 주식회사 | 이동통신 시스템에서 역방향 링크 송신 제어 장치 및 방법 |
| JP4106226B2 (ja) | 2001-03-26 | 2008-06-25 | 松下電器産業株式会社 | 電源制御装置 |
| CN1165141C (zh) | 2001-03-27 | 2004-09-01 | 华为技术有限公司 | 路由器接口驱动数据转发过程的方法 |
| JP2002300299A (ja) | 2001-03-29 | 2002-10-11 | Shunichi Toyoda | 携帯電話材のメモリを利用した情報端末装置による教育システム |
| JP2002359774A (ja) | 2001-03-30 | 2002-12-13 | Fuji Photo Film Co Ltd | 電子カメラ |
| CN1159935C (zh) | 2001-03-30 | 2004-07-28 | 华为技术有限公司 | 一种提高市区环境下蜂窝移动台定位精度的方法和装置 |
| JP3497834B2 (ja) | 2001-03-30 | 2004-02-16 | 株式会社東芝 | ルートリピータ、ｕｓｂ通信システム、ｕｓｂ通信制御方法 |
| US7068667B2 (en) | 2001-04-27 | 2006-06-27 | The Boeing Company | Method and system for path building in a communications network |
| US6889056B2 (en) | 2001-04-30 | 2005-05-03 | Ntt Docomo, Inc. | Transmission control scheme |
| JP3884322B2 (ja) | 2001-05-16 | 2007-02-21 | 株式会社リコー | ネットワークインターフェース |
| US7392541B2 (en) | 2001-05-17 | 2008-06-24 | Vir2Us, Inc. | Computer system architecture and method providing operating-system independent virus-, hacker-, and cyber-terror-immune processing environments |
| US7420602B2 (en) | 2001-05-29 | 2008-09-02 | Samsung Semiconductor Israel R&D Center (Sirc) | Cmos imager for cellular applications and methods of using such |
| JP2002351689A (ja) | 2001-05-30 | 2002-12-06 | Nec Corp | データ転送システム |
| US7191281B2 (en) * | 2001-06-13 | 2007-03-13 | Intel Corporation | Mobile computer system having a navigation mode to optimize system performance and power management for mobile applications |
| US7165112B2 (en) * | 2001-06-22 | 2007-01-16 | Motorola, Inc. | Method and apparatus for transmitting data in a communication system |
| JP2003006143A (ja) | 2001-06-22 | 2003-01-10 | Nec Corp | バス共有化システムと装置及び方法 |
| US6745364B2 (en) | 2001-06-28 | 2004-06-01 | Microsoft Corporation | Negotiated/dynamic error correction for streamed media |
| JP2003046595A (ja) | 2001-07-06 | 2003-02-14 | Texas Instruments Inc | データ通信の方法および装置 |
| US7051218B1 (en) | 2001-07-18 | 2006-05-23 | Advanced Micro Devices, Inc. | Message based power management |
| KR100895559B1 (ko) | 2001-07-23 | 2009-04-29 | 파나소닉 주식회사 | 정보기록매체, 정보기록매체에 정보를 기록하는 장치 및방법 |
| US7184408B2 (en) * | 2001-07-31 | 2007-02-27 | Denton I Claude | Method and apparatus for programmable generation of traffic streams |
| US8407292B2 (en) * | 2001-07-31 | 2013-03-26 | Comverse, Ltd. | E-mail protocol optimized for a mobile environment and gateway using same |
| JP2003044184A (ja) | 2001-08-01 | 2003-02-14 | Canon Inc | データ処理装置及び電力制御方法 |
| GB2415314B (en) * | 2001-08-08 | 2006-05-03 | Adder Tech Ltd | Video switch |
| US6758678B2 (en) * | 2001-08-14 | 2004-07-06 | Disney Enterprises, Inc. | Computer enhanced play set and method |
| JP4733877B2 (ja) | 2001-08-15 | 2011-07-27 | 富士通セミコンダクター株式会社 | 半導体装置 |
| JP2003069544A (ja) | 2001-08-23 | 2003-03-07 | Hitachi Kokusai Electric Inc | 通信制御方法及び通信制御装置 |
| JP4322451B2 (ja) | 2001-09-05 | 2009-09-02 | 日本電気株式会社 | Ｄｓｐメモリ間あるいはｄｓｐメモリとｃｐｕ用メモリ（ｄｐｒａｍ）間データ転送方式 |
| BR0212361A (pt) | 2001-09-06 | 2006-11-07 | Qualcomm Inc | geração e implementação de um protocolo de comunicação e interface para transferência de sinais de taxa de dados elevada |
| US8812706B1 (en) * | 2001-09-06 | 2014-08-19 | Qualcomm Incorporated | Method and apparatus for compensating for mismatched delays in signals of a mobile display interface (MDDI) system |
| DE10145722A1 (de) | 2001-09-17 | 2003-04-24 | Infineon Technologies Ag | Konzept zur sicheren Datenkommunikation zwischen elektronischen Bausteinen |
| US20030061431A1 (en) * | 2001-09-21 | 2003-03-27 | Intel Corporation | Multiple channel interface for communications between devices |
| KR100408299B1 (ko) | 2001-09-29 | 2003-12-01 | 삼성전자주식회사 | 모드 판단 장치 및 방법 |
| JP3633538B2 (ja) | 2001-10-02 | 2005-03-30 | 日本電気株式会社 | 輻輳制御システム |
| US7570668B2 (en) | 2001-10-03 | 2009-08-04 | Nokia Corporation | Data synchronization |
| EP1309133A1 (de) * | 2001-10-31 | 2003-05-07 | Siemens Aktiengesellschaft | Verfahren, Empfangseinrichtung und Sendeeinrichtung zur Bestimmung des schnellsten Nachrichtenpfades ohne Uhrensynchronisation |
| KR100408525B1 (ko) | 2001-10-31 | 2003-12-06 | 삼성전자주식회사 | 네트워크에 적응적인 실시간 멀티미디어 스트리밍 시스템및 방법 |
| US20030125040A1 (en) | 2001-11-06 | 2003-07-03 | Walton Jay R. | Multiple-access multiple-input multiple-output (MIMO) communication system |
| US7126945B2 (en) | 2001-11-07 | 2006-10-24 | Symbol Technologies, Inc. | Power saving function for wireless LANS: methods, system and program products |
| US6990549B2 (en) * | 2001-11-09 | 2006-01-24 | Texas Instruments Incorporated | Low pin count (LPC) I/O bridge |
| US7536598B2 (en) | 2001-11-19 | 2009-05-19 | Vir2Us, Inc. | Computer system capable of supporting a plurality of independent computing environments |
| US6891545B2 (en) | 2001-11-20 | 2005-05-10 | Koninklijke Philips Electronics N.V. | Color burst queue for a shared memory controller in a color sequential display system |
| GB2382502B (en) | 2001-11-23 | 2005-10-19 | Actix Ltd | Network testing systems |
| JP2003167680A (ja) | 2001-11-30 | 2003-06-13 | Hitachi Ltd | ディスク装置 |
| US20030112758A1 (en) | 2001-12-03 | 2003-06-19 | Pang Jon Laurent | Methods and systems for managing variable delays in packet transmission |
| US7486693B2 (en) | 2001-12-14 | 2009-02-03 | General Electric Company | Time slot protocol |
| US6993393B2 (en) * | 2001-12-19 | 2006-01-31 | Cardiac Pacemakers, Inc. | Telemetry duty cycle management system for an implantable medical device |
| JP2003198550A (ja) | 2001-12-25 | 2003-07-11 | Matsushita Electric Ind Co Ltd | 通信装置及び通信方法 |
| KR100428767B1 (ko) | 2002-01-11 | 2004-04-28 | 삼성전자주식회사 | 트래픽 정보를 이용한 가입자 라우팅 설정 방법 및 이를위한 기록매체 |
| US20050120208A1 (en) | 2002-01-25 | 2005-06-02 | Albert Dobson Robert W. | Data transmission systems |
| US20030144006A1 (en) | 2002-01-25 | 2003-07-31 | Mikael Johansson | Methods, systems, and computer program products for determining the location of a mobile terminal based on delays in receiving data packets from transmitters having known locations |
| US6690201B1 (en) * | 2002-01-28 | 2004-02-10 | Xilinx, Inc. | Method and apparatus for locating data transition regions |
| US7145411B1 (en) | 2002-03-18 | 2006-12-05 | Applied Micro Circuits Corporation | Flexible differential interconnect cable with isolated high frequency electrical transmission line |
| US7336139B2 (en) * | 2002-03-18 | 2008-02-26 | Applied Micro Circuits Corporation | Flexible interconnect cable with grounded coplanar waveguide |
| US6867668B1 (en) * | 2002-03-18 | 2005-03-15 | Applied Micro Circuits Corporation | High frequency signal transmission from the surface of a circuit substrate to a flexible interconnect cable |
| US6797891B1 (en) | 2002-03-18 | 2004-09-28 | Applied Micro Circuits Corporation | Flexible interconnect cable with high frequency electrical transmission line |
| US20030185220A1 (en) | 2002-03-27 | 2003-10-02 | Moshe Valenci | Dynamically loading parsing capabilities |
| US7425986B2 (en) | 2002-03-29 | 2008-09-16 | Canon Kabushiki Kaisha | Conversion apparatus for image data delivery |
| US7310535B1 (en) | 2002-03-29 | 2007-12-18 | Good Technology, Inc. | Apparatus and method for reducing power consumption in a wireless device |
| US7430001B2 (en) | 2002-04-12 | 2008-09-30 | Canon Kabushiki Kaisha | Image sensing system, communication apparatus and image sensing apparatus having remote control function, and their control method |
| TWI235917B (en) | 2002-04-15 | 2005-07-11 | Via Tech Inc | High speed data transmitter and transmission method thereof |
| US7158539B2 (en) * | 2002-04-16 | 2007-01-02 | Microsoft Corporation | Error resilient windows media audio coding |
| US7599689B2 (en) | 2002-04-22 | 2009-10-06 | Nokia Corporation | System and method for bookmarking radio stations and associated internet addresses |
| JP4029390B2 (ja) | 2002-04-23 | 2008-01-09 | ソニー株式会社 | 情報処理システム、情報処理装置および方法、プログラム格納媒体、並びにプログラム |
| US7284181B1 (en) | 2002-04-24 | 2007-10-16 | Juniper Networks, Inc. | Systems and methods for implementing end-to-end checksum |
| US7206516B2 (en) * | 2002-04-30 | 2007-04-17 | Pivotal Decisions Llc | Apparatus and method for measuring the dispersion of a fiber span |
| US7574113B2 (en) | 2002-05-06 | 2009-08-11 | Sony Corporation | Video and audio data recording apparatus, video and audio data recording method, video and audio data reproducing apparatus, and video and audio data reproducing method |
| US20050091593A1 (en) | 2002-05-10 | 2005-04-28 | General Electric Company | Method and system for coordinated transfer of control of a remote controlled locomotive |
| US6886067B2 (en) | 2002-05-23 | 2005-04-26 | Seiko Epson Corporation | 32 Bit generic asynchronous bus interface using read/write strobe byte enables |
| US7269153B1 (en) | 2002-05-24 | 2007-09-11 | Conexant Systems, Inc. | Method for minimizing time critical transmit processing for a personal computer implementation of a wireless local area network adapter |
| US7036066B2 (en) | 2002-05-24 | 2006-04-25 | Sun Microsystems, Inc. | Error detection using data block mapping |
| US7543326B2 (en) | 2002-06-10 | 2009-06-02 | Microsoft Corporation | Dynamic rate control |
| JP2003098583A (ja) | 2002-06-10 | 2003-04-03 | Nikon Corp | 書換え可能なメモリを使用するカメラ |
| JP2004021613A (ja) * | 2002-06-17 | 2004-01-22 | Seiko Epson Corp | データ転送制御装置、電子機器及びデータ転送制御方法 |
| DE60212104T2 (de) | 2002-06-18 | 2006-10-19 | Matsushita Electric Industrial Co., Ltd., Kadoma | Auf Empfänger basierte Umlaufzeitmessung in TCP |
| KR100469427B1 (ko) * | 2002-06-24 | 2005-02-02 | 엘지전자 주식회사 | 이동통신 시스템의 동영상 재생 방법 |
| US7486696B2 (en) | 2002-06-25 | 2009-02-03 | Avaya, Inc. | System and method for providing bandwidth management for VPNs |
| JP4175838B2 (ja) | 2002-07-09 | 2008-11-05 | 三菱電機株式会社 | 待機モード付情報処理装置およびその待機モード開始方法と待機モード解除方法 |
| DE10234991B4 (de) * | 2002-07-31 | 2008-07-31 | Advanced Micro Devices, Inc., Sunnyvale | Hostcontrollerdiagnose für einen seriellen Bus |
| US7403511B2 (en) | 2002-08-02 | 2008-07-22 | Texas Instruments Incorporated | Low power packet detector for low power WLAN devices |
| US6611221B1 (en) | 2002-08-26 | 2003-08-26 | Texas Instruments Incorporated | Multi-bit sigma-delta modulator employing dynamic element matching using adaptively randomized data-weighted averaging |
| MXPA05002511A (es) * | 2002-09-05 | 2005-08-16 | Agency Science Tech & Res | Un metodo y un aparato para controlar la velocidad de una secuencia de video; un dispositivo que codifica un video. |
| US20040140459A1 (en) | 2002-09-13 | 2004-07-22 | Haigh Scott D. | Enhanced shadow reduction system and related techniques for digital image capture |
| US7257087B2 (en) | 2002-10-04 | 2007-08-14 | Agilent Technologies, Inc. | System and method to calculate round trip delay for real time protocol packet streams |
| CN1266976C (zh) | 2002-10-15 | 2006-07-26 | 华为技术有限公司 | 一种移动台定位方法及其直放站 |
| US20040082383A1 (en) | 2002-10-24 | 2004-04-29 | Motorola, Inc | Methodology and wireless device for interactive gaming |
| JP4028356B2 (ja) | 2002-10-31 | 2007-12-26 | 京セラ株式会社 | 通信システム、無線通信端末、データ配信装置及び通信方法 |
| US7949777B2 (en) | 2002-11-01 | 2011-05-24 | Avid Technology, Inc. | Communication protocol for controlling transfer of temporal data over a bus between devices in synchronization with a periodic reference signal |
| GB0226014D0 (en) | 2002-11-08 | 2002-12-18 | Nokia Corp | Camera-LSI and information device |
| US7336667B2 (en) * | 2002-11-21 | 2008-02-26 | International Business Machines Corporation | Apparatus, method and program product to generate and use CRC in communications network |
| US7327735B2 (en) * | 2002-11-27 | 2008-02-05 | Alcatel Canada Inc. | System and method for detecting lost messages transmitted between modules in a communication device |
| JP3642332B2 (ja) | 2002-12-20 | 2005-04-27 | 松下電器産業株式会社 | 折り畳み式携帯電話装置 |
| US7191349B2 (en) | 2002-12-26 | 2007-03-13 | Intel Corporation | Mechanism for processor power state aware distribution of lowest priority interrupt |
| US6765506B1 (en) | 2003-01-06 | 2004-07-20 | Via Technologies Inc. | Scrambler, de-scrambler, and related method |
| GB2397709B (en) | 2003-01-27 | 2005-12-28 | Evangelos Arkas | Period-to-digital converter |
| US7047475B2 (en) | 2003-02-04 | 2006-05-16 | Hewlett-Packard Development Company, L.P. | CRC encoding scheme for conveying status information |
| JP4119764B2 (ja) | 2003-02-13 | 2008-07-16 | 京セラ株式会社 | カメラ付き携帯端末 |
| US20040176065A1 (en) | 2003-02-20 | 2004-09-09 | Bo Liu | Low power operation in a personal area network communication system |
| US7787886B2 (en) * | 2003-02-24 | 2010-08-31 | Invisitrack, Inc. | System and method for locating a target using RFID |
| US6944136B2 (en) | 2003-02-28 | 2005-09-13 | On-Demand Technologies, Inc. | Two-way audio/video conferencing system |
| US20040184450A1 (en) | 2003-03-19 | 2004-09-23 | Abdu H. Omran | Method and system for transport and routing of packets over frame-based networks |
| JP4112414B2 (ja) | 2003-03-28 | 2008-07-02 | 京セラ株式会社 | 携帯端末装置 |
| US7260087B2 (en) | 2003-04-02 | 2007-08-21 | Cellco Partnership | Implementation methodology for client initiated parameter negotiation for PTT/VoIP type services |
| JP2004309623A (ja) | 2003-04-03 | 2004-11-04 | Konica Minolta Opto Inc | 撮像装置及び携帯端末並びに撮像装置製造方法 |
| JP4288994B2 (ja) * | 2003-04-10 | 2009-07-01 | 株式会社日立製作所 | 端末装置、配信サーバ、映像データの受信方法及び映像データの送信方法 |
| JP2006523980A (ja) * | 2003-04-17 | 2006-10-19 | トムソン ライセンシング | データ要求装置、データ送信装置、およびそのプロセスならびに対応する製品 |
| US20040221315A1 (en) | 2003-05-01 | 2004-11-04 | Genesis Microchip Inc. | Video interface arranged to provide pixel data independent of a link character clock |
| US6895410B2 (en) | 2003-05-02 | 2005-05-17 | Nokia Corporation | Method and apparatus for providing a multimedia data stream |
| US7477604B2 (en) | 2003-05-14 | 2009-01-13 | Ntt Docomo, Inc. | Packet communications system |
| US7580380B2 (en) | 2003-05-28 | 2009-08-25 | Artimi Ltd | Communications systems and methods |
| US7110420B2 (en) | 2003-05-30 | 2006-09-19 | North Carolina State University | Integrated circuit devices having on-chip adaptive bandwidth buses and related methods |
| JP4278439B2 (ja) | 2003-06-02 | 2009-06-17 | パイオニア株式会社 | 情報通信装置、そのシステム、その方法、そのプログラム、および、そのプログラムを記録した記録媒体 |
| US6975145B1 (en) | 2003-06-02 | 2005-12-13 | Xilinx, Inc. | Glitchless dynamic multiplexer with synchronous and asynchronous controls |
| ATE517500T1 (de) * | 2003-06-02 | 2011-08-15 | Qualcomm Inc | Erzeugung und umsetzung eines signalprotokolls und schnittstelle für höhere datenraten |
| US20040260823A1 (en) | 2003-06-17 | 2004-12-23 | General Instrument Corporation | Simultaneously transporting multiple MPEG-2 transport streams |
| JP3834819B2 (ja) * | 2003-07-17 | 2006-10-18 | 船井電機株式会社 | プロジェクタ |
| KR100538226B1 (ko) | 2003-07-18 | 2005-12-21 | 삼성전자주식회사 | 복수의 아날로그 입력 신호를 고속으로 처리하는아날로그/디지털 변환 장치 및 이를 이용한 디스플레이 장치 |
| US7526350B2 (en) * | 2003-08-06 | 2009-04-28 | Creative Technology Ltd | Method and device to process digital media streams |
| EP2363992A1 (en) | 2003-08-13 | 2011-09-07 | Qualcomm Incorporated | A signal interface for higher data rates |
| US7467202B2 (en) * | 2003-09-10 | 2008-12-16 | Fidelis Security Systems | High-performance network content analysis platform |
| AU2004303402A1 (en) * | 2003-09-10 | 2005-03-24 | Qualcomm Incorporated | High data rate interface |
| US7015838B1 (en) * | 2003-09-11 | 2006-03-21 | Xilinx, Inc. | Programmable serializing data path |
| KR20050028396A (ko) | 2003-09-17 | 2005-03-23 | 삼성전자주식회사 | 멀티 세션 방식을 이용한 데이터 기록 방법 및 그정보저장매체 |
| JP2005107683A (ja) | 2003-09-29 | 2005-04-21 | Sharp Corp | 通信コントローラ、通信システム、通信機器、および通信方法 |
| ATE387824T1 (de) * | 2003-10-08 | 2008-03-15 | Research In Motion Ltd | Verfahren und vorrichtung zur dynamischen paketübertragung in cdma2000 netzwerken |
| EP1680904A1 (en) | 2003-10-15 | 2006-07-19 | QUALCOMM Incorporated | High data rate interface |
| KR100827573B1 (ko) | 2003-10-29 | 2008-05-07 | 퀄컴 인코포레이티드 | 높은 데이터 레이트 인터페이스 |
| US8606946B2 (en) | 2003-11-12 | 2013-12-10 | Qualcomm Incorporated | Method, system and computer program for driving a data signal in data interface communication data link |
| US7143207B2 (en) | 2003-11-14 | 2006-11-28 | Intel Corporation | Data accumulation between data path having redrive circuit and memory device |
| US7219294B2 (en) | 2003-11-14 | 2007-05-15 | Intel Corporation | Early CRC delivery for partial frame |
| US7447953B2 (en) | 2003-11-14 | 2008-11-04 | Intel Corporation | Lane testing with variable mapping |
| KR20060096161A (ko) | 2003-11-25 | 2006-09-07 | 콸콤 인코포레이티드 | 향상된 링크 동기화를 제공하는 고속 데이터 레이트인터페이스 |
| EP2247070B1 (en) | 2003-12-08 | 2013-09-25 | QUALCOMM Incorporated | High data rate interface with improved link synchronization |
| US7451362B2 (en) | 2003-12-12 | 2008-11-11 | Broadcom Corporation | Method and system for onboard bit error rate (BER) estimation in a port bypass controller |
| US7340548B2 (en) * | 2003-12-17 | 2008-03-04 | Microsoft Corporation | On-chip bus |
| US20050163085A1 (en) | 2003-12-24 | 2005-07-28 | International Business Machines Corporation | System and method for autonomic wireless presence ping |
| US7317754B1 (en) * | 2004-01-12 | 2008-01-08 | Verizon Services Corp. | Rate agile rate-adaptive digital subscriber line |
| US7158536B2 (en) * | 2004-01-28 | 2007-01-02 | Rambus Inc. | Adaptive-allocation of I/O bandwidth using a configurable interconnect topology |
| WO2005073955A1 (en) | 2004-01-28 | 2005-08-11 | Koninklijke Philips Electronics N.V. | Displaying on a matrix display |
| US7868890B2 (en) * | 2004-02-24 | 2011-01-11 | Qualcomm Incorporated | Display processor for a wireless device |
| JP3786120B2 (ja) | 2004-03-09 | 2006-06-14 | セイコーエプソン株式会社 | データ転送制御装置及び電子機器 |
| EP1733537A1 (en) | 2004-03-10 | 2006-12-20 | Qualcomm, Incorporated | High data rate interface apparatus and method |
| CA2560067C (en) | 2004-03-17 | 2011-08-23 | Qualcomm Incorporated | High data rate interface apparatus and method |
| JP5032301B2 (ja) | 2004-03-24 | 2012-09-26 | クゥアルコム・インコーポレイテッド | 高データレートインターフェース装置および方法 |
| DE102004014973B3 (de) | 2004-03-26 | 2005-11-03 | Infineon Technologies Ag | Parallel-Seriell-Umsetzer |
| CN100590983C (zh) | 2004-04-21 | 2010-02-17 | 三星电子株式会社 | 无线终端中多数据处理装置和方法 |
| US20050265333A1 (en) | 2004-06-01 | 2005-12-01 | Texas Instruments Incorporated | Method for enabling efficient multicast transmission in a packet-based network |
| US7091911B2 (en) | 2004-06-02 | 2006-08-15 | Research In Motion Limited | Mobile wireless communications device comprising non-planar internal antenna without ground plane overlap |
| CA2569106C (en) | 2004-06-04 | 2013-05-21 | Qualcomm Incorporated | High data rate interface apparatus and method |
| US8650304B2 (en) * | 2004-06-04 | 2014-02-11 | Qualcomm Incorporated | Determining a pre skew and post skew calibration data rate in a mobile display digital interface (MDDI) communication system |
| US20060034301A1 (en) * | 2004-06-04 | 2006-02-16 | Anderson Jon J | High data rate interface apparatus and method |
| US7383399B2 (en) * | 2004-06-30 | 2008-06-03 | Intel Corporation | Method and apparatus for memory compression |
| US7095435B1 (en) | 2004-07-21 | 2006-08-22 | Hartman Richard L | Programmable multifunction electronic camera |
| WO2006008067A1 (en) | 2004-07-22 | 2006-01-26 | Ucb, S.A. | Indolone derivatives, processes for preparing them and their uses |
| CN101041989A (zh) | 2004-08-05 | 2007-09-26 | 邱则有 | 一种钢筋砼立体承力结构楼盖 |
| KR100604323B1 (ko) | 2004-08-28 | 2006-07-24 | 삼성테크윈 주식회사 | 내장형 카메라 장치 및 이를 구비한 휴대폰 |
| KR100624311B1 (ko) | 2004-08-30 | 2006-09-19 | 삼성에스디아이 주식회사 | 프레임 메모리 제어 방법 및 그것을 이용한 표시 장치 |
| US7161846B2 (en) * | 2004-11-16 | 2007-01-09 | Seiko Epson Corporation | Dual-edge triggered multiplexer flip-flop and method |
| US6990335B1 (en) * | 2004-11-18 | 2006-01-24 | Charles G. Shamoon | Ubiquitous connectivity and control system for remote locations |
| JP2008522496A (ja) | 2004-11-24 | 2008-06-26 | クゥアルコム・インコーポレイテッド | 通信リンクの両端でコマンドを同期実行するための方法およびシステム |
| US8723705B2 (en) * | 2004-11-24 | 2014-05-13 | Qualcomm Incorporated | Low output skew double data rate serial encoder |
| CA2651781C (en) | 2004-11-24 | 2012-10-09 | Qualcomm Incorporated | Systems and methods for digital data transmission rate control |
| US8699330B2 (en) * | 2004-11-24 | 2014-04-15 | Qualcomm Incorporated | Systems and methods for digital data transmission rate control |
| US8667363B2 (en) | 2004-11-24 | 2014-03-04 | Qualcomm Incorporated | Systems and methods for implementing cyclic redundancy checks |
| US7315265B2 (en) * | 2004-11-24 | 2008-01-01 | Qualcomm Incorporated | Double data rate serial encoder |
| US8692838B2 (en) | 2004-11-24 | 2014-04-08 | Qualcomm Incorporated | Methods and systems for updating a buffer |
| US20060161691A1 (en) | 2004-11-24 | 2006-07-20 | Behnam Katibian | Methods and systems for synchronous execution of commands across a communication link |
| US8873584B2 (en) | 2004-11-24 | 2014-10-28 | Qualcomm Incorporated | Digital data interface device |
| US8539119B2 (en) | 2004-11-24 | 2013-09-17 | Qualcomm Incorporated | Methods and apparatus for exchanging messages having a digital data interface device message format |
| KR100672987B1 (ko) | 2004-12-20 | 2007-01-24 | 삼성전자주식회사 | 고속 아날로그 인벨롭 디텍터 |
| JP2006211394A (ja) | 2005-01-28 | 2006-08-10 | Toshiba Corp | 折り畳み型携帯端末装置 |
| US7412642B2 (en) | 2005-03-09 | 2008-08-12 | Sun Microsystems, Inc. | System and method for tolerating communication lane failures |
| JP4428272B2 (ja) | 2005-03-28 | 2010-03-10 | セイコーエプソン株式会社 | 表示ドライバ及び電子機器 |
| US7605837B2 (en) | 2005-06-02 | 2009-10-20 | Lao Chan Yuen | Display system and method |
| JP2007012937A (ja) | 2005-06-30 | 2007-01-18 | Seiko Epson Corp | 表示ドライバ |
| JP4756950B2 (ja) | 2005-08-08 | 2011-08-24 | キヤノン株式会社 | 撮像装置及びその制御方法 |
| US7302510B2 (en) * | 2005-09-29 | 2007-11-27 | International Business Machines Corporation | Fair hierarchical arbiter |
| US8692839B2 (en) | 2005-11-23 | 2014-04-08 | Qualcomm Incorporated | Methods and systems for updating a buffer |
| US8730069B2 (en) | 2005-11-23 | 2014-05-20 | Qualcomm Incorporated | Double data rate serial encoder |
| US7813451B2 (en) | 2006-01-11 | 2010-10-12 | Mobileaccess Networks Ltd. | Apparatus and method for frequency shifting of a wireless signal and systems using frequency shifting |
| US7893990B1 (en) | 2006-07-31 | 2011-02-22 | Cisco Technology, Inc. | Digital video camera with retractable data connector and resident software application |
| JP4250648B2 (ja) | 2006-09-21 | 2009-04-08 | 株式会社東芝 | 情報処理装置 |
| US7912503B2 (en) | 2007-07-16 | 2011-03-22 | Microsoft Corporation | Smart interface system for mobile communications devices |
| JP2009284281A (ja) | 2008-05-23 | 2009-12-03 | Nec Electronics Corp | 無線通信機器、及び無線通信状態表示方法 |
| KR200469360Y1 (ko) | 2008-12-26 | 2013-10-11 | 대성전기공업 주식회사 | 시트 온도 조절 스위치 장치 |
-
2005
- 2005-06-03 CA CA2569106A patent/CA2569106C/en not_active Expired - Fee Related
- 2005-06-03 RU RU2006147230/09A patent/RU2353066C2/ru not_active IP Right Cessation
- 2005-06-03 AT AT08013163T patent/ATE518343T1/de not_active IP Right Cessation
- 2005-06-03 EP EP08013164A patent/EP1978693A3/en not_active Withdrawn
- 2005-06-03 EP EP10161865A patent/EP2211510B1/en not_active Not-in-force
- 2005-06-03 US US11/145,357 patent/US8630305B2/en active Active
- 2005-06-03 MX MXPA06014097A patent/MXPA06014097A/es unknown
- 2005-06-03 AU AU2005253592A patent/AU2005253592B2/en not_active Ceased
- 2005-06-03 EP EP08020169A patent/EP2020790B1/en not_active Not-in-force
- 2005-06-03 TW TW094118438A patent/TWI357247B/zh not_active IP Right Cessation
- 2005-06-03 EP EP08013165A patent/EP1978694B1/en not_active Not-in-force
- 2005-06-03 KR KR1020087018473A patent/KR100926658B1/ko not_active IP Right Cessation
- 2005-06-03 EP EP08013163A patent/EP1978692B1/en not_active Not-in-force
- 2005-06-03 WO PCT/US2005/019530 patent/WO2005122509A1/en active Application Filing
- 2005-06-03 JP JP2007515605A patent/JP4664360B2/ja not_active Expired - Fee Related
- 2005-06-03 AT AT08013165T patent/ATE511282T1/de not_active IP Right Cessation
- 2005-06-03 AT AT10161865T patent/ATE523009T1/de not_active IP Right Cessation
- 2005-06-03 CN CNA2005800261956A patent/CN1993948A/zh active Pending
- 2005-06-03 BR BRPI0511783-6A patent/BRPI0511783A/pt not_active IP Right Cessation
- 2005-06-03 KR KR1020087018472A patent/KR100914420B1/ko not_active IP Right Cessation
- 2005-06-03 CN CN201110189164XA patent/CN102316052A/zh active Pending
- 2005-06-03 CN CN201010126783XA patent/CN101800711B/zh not_active Expired - Fee Related
- 2005-06-03 EP EP05757983A patent/EP1751938A1/en not_active Withdrawn
-
2006
- 2006-11-29 IL IL179712A patent/IL179712A0/en unknown
-
2008
- 2008-12-04 AU AU2008255141A patent/AU2008255141A1/en not_active Abandoned
- 2008-12-04 AU AU2008255142A patent/AU2008255142A1/en not_active Abandoned
- 2008-12-04 AU AU2008255140A patent/AU2008255140A1/en not_active Abandoned
-
2010
- 2010-01-29 US US12/696,272 patent/US8630318B2/en active Active
- 2010-04-08 JP JP2010089293A patent/JP5237320B2/ja not_active Expired - Fee Related
- 2010-04-08 JP JP2010089292A patent/JP5275284B2/ja not_active Expired - Fee Related
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2574859C2 (ru) * | 2011-08-10 | 2016-02-10 | Зте Корпорейшн | Способ и устройство для реализации автоматической компенсации асимметричной задержки линии связи, соответствующей стандарту 1588 |
| RU2589341C2 (ru) * | 2011-11-08 | 2016-07-10 | Телефонактиеболагет Л М Эрикссон (Пабл) | Размер элемента мозаичного изображения при кодировании видео |
| RU2617927C2 (ru) * | 2012-10-19 | 2017-04-28 | Самсунг Электроникс Ко., Лтд. | Устройство отображения и его способ управления |
| RU2632152C2 (ru) * | 2013-06-03 | 2017-10-02 | Хуавэй Текнолоджиз Ко., Лтд. | Сетевое устройство и способ управления процессом службы |
| US10425510B2 (en) | 2013-06-03 | 2019-09-24 | Huawei Technologies Co., Ltd. | Service process control method and network device |
| US11233884B2 (en) | 2013-06-03 | 2022-01-25 | Huawei Technologies Co., Ltd. | Service process control method and network device |
| US11700322B2 (en) | 2013-06-03 | 2023-07-11 | Huawei Technologies Co., Ltd. | Service process control method and network device |
| RU2718269C1 (ru) * | 2019-11-27 | 2020-04-01 | Светлана Игоревна Рычкова | Способ восстановления и развития стереозрения |
| RU2733109C1 (ru) * | 2019-12-11 | 2020-09-29 | Общество с ограниченной ответственностью «Интерра» | Способ обмена данными между удаленным устройством и главной ЭВМ |
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2353066C2 (ru) | Устройство и способ реализации интерфейса высокоскоростной передачи данных | |
| RU2355121C2 (ru) | Устройство и способ интерфейса с высокой скоростью передачи данных | |
| RU2337497C2 (ru) | Устройство и способ для реализации интерфейса с высокой скоростью передачи данных | |
| JP5453197B2 (ja) | 高データレートインターフェース装置および方法 | |
| JP4902355B2 (ja) | 改良されたリンク同期を備えた高速データレートインタフェース | |
| JP4782694B2 (ja) | 改善されたリンク制御を有する高速データレートインタフェース | |
| JP5237319B2 (ja) | 高速データレートインタフェース | |
| US8650304B2 (en) | Determining a pre skew and post skew calibration data rate in a mobile display digital interface (MDDI) communication system | |
| JP2007512785A (ja) | 改良されたリンク同期を備えた高速データレートインタフェース | |
| KR100882166B1 (ko) | 고 데이터 레이트 인터페이스 장치 및 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MM4A | The patent is invalid due to non-payment of fees |
Effective date: 20150604 |