BRPI0410885B1 - Gerar e implementar um protocolo de sinal e interface para taxas de dados mais altas - Google Patents

Gerar e implementar um protocolo de sinal e interface para taxas de dados mais altas Download PDF

Info

Publication number
BRPI0410885B1
BRPI0410885B1 BRPI0410885-0A BRPI0410885A BRPI0410885B1 BR PI0410885 B1 BRPI0410885 B1 BR PI0410885B1 BR PI0410885 A BRPI0410885 A BR PI0410885A BR PI0410885 B1 BRPI0410885 B1 BR PI0410885B1
Authority
BR
Brazil
Prior art keywords
data
host
link
mddi
package
Prior art date
Application number
BRPI0410885-0A
Other languages
English (en)
Inventor
Jon Anderson James
Steele Brian
A. Wiley George
Shekhar Shashank
Original Assignee
Qualcomm Incorporated
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Incorporated filed Critical Qualcomm Incorporated
Publication of BRPI0410885A publication Critical patent/BRPI0410885A/pt
Publication of BRPI0410885B1 publication Critical patent/BRPI0410885B1/pt

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/14—Digital output to display device ; Cooperation and interconnection of the display device with other functional units
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056—Systems characterized by the type of code used
    • H04L1/0061—Error detection codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/24—Testing correct operation
    • H04L1/245—Testing correct operation by using the properties of transmission codes
    • 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
    • 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/70—Media network packetisation
    • 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/03—Protocol definition or specification 
    • 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/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • 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/22—Parsing or analysis of headers
    • 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/24—Negotiation of communication capabilities
    • 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/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L7/00—Arrangements for synchronising receiver with transmitter
    • H04L7/04—Speed or phase control by synchronisation signals
    • H04L7/10—Arrangements for initial synchronisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4122—Peripherals receiving signals from specially adapted client devices additional display device, e.g. video projector
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H04N21/43632—Adapting the video stream to a specific local network, e.g. a Bluetooth® network involving a wired protocol, e.g. IEEE 1394
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L7/00—Arrangements for synchronising receiver with transmitter
    • H04L7/0008—Synchronisation information channels, e.g. clock distribution lines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L7/00—Arrangements for synchronising receiver with transmitter
    • H04L7/04—Speed or phase control by synchronisation signals
    • H04L7/048—Speed or phase control by synchronisation signals using the properties of error detecting or error correcting codes, e.g. parity as synchronisation signal
    • 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
    • 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)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Human Computer Interaction (AREA)
  • Communication Control (AREA)
  • Information Transfer Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)
  • Control Of Indicators Other Than Cathode Ray Tubes (AREA)
  • Computer And Data Communications (AREA)

Abstract

"gerar e implementar um protocolo de sinal e interface para taxas de dados mais elevadas". uma interface de dados para transferência de dados digitais entre um hospedeiro (100) e um cliente (104, 108) através de uma trajetória de comunicação (110) utilizando estruturas de pacotes ligadas juntas para formar um protocolo de comunicação a fim de comunicar um conjunto pré-selecionado de dados de apresentação e controle digitais. o protocolo de sinal é utilizado por controladores de link configurados para gerar, transmitir e receber pacotes formando o protocolo de comunicação, e formar dados digitais em um ou mais tipos de pacotes de dados, com pelo menos um residindo no mecanismo hospedeiro (100) e sendo acoplado ao cliente (104, 108) através da trajetória de comunicação (110) a interface provê um mecanismo de transferência de dados em alta taxa, bidirecional, de baixa energia, eficaz em termos de custo através de um link de dados do tipo 'serial' de pequeno alcance, que se presta à implementação com conectores em miniatura e cabos flexíveis, delgados os quais são especialmente úteis na conexão de mecanismos de display como micro-displays (104) utilizáveis para computadores portáteis (100) e mecanismos de comunicação sem fio (102).

Description

(54) Título: GERAR E IMPLEMENTAR UM PROTOCOLO DE SINAL E INTERFACE PARA TAXAS DE DADOS MAIS ALTAS (51) lnt.CI.: H04L 29/06; H04L 12/64; G06F 3/14 (30) Prioridade Unionista: 02/06/2003 US 60/475,459 (73) Titular(es): QUALCOMM INCORPORATED (72) Inventor(es): JAMES JON ANDERSON; BRIAN STEELE; GEORGE A. WILEY; SHASHANK SHEKHAR
GERAR E IMPLEMENTAR UM PROTOCOLO DE SINAL E INTERFACE PARA
TAXAS DE DADOS MAIS ALTAS
FUNDAMENTOS DA INVENÇÃO
T. Campo da Invenção
Ά presente invenção refere-se a um protocolo de sinal digital e processo para comunicar ou transferir sinais entre um dispositivo hospedeiro e um dispositivo de apresentação áudio/visual cliente em taxas de dados altas. Mais especificamente, a presente invenção refere-se a uma técnica para transferir multimídia e outros tipos de sinais digitais de um dispositivo sem fio para uma unidade de microdisplay ou outro dispositivo de apresentação utilizando um mecanismo de transferência de alta taxa de dados de baixa energia.
II. lecnica relacionada
Computadores, produtos relacionados a jogos eletrônicos, e diversas tecnologias de video (por exemplo, DVD's e VCRs de Alta Definição) avançaram significativamente durante os últimos anos para fornecer apresentação de imagens fixas, de vídeo, vídeo em demanda, e processos gráficos com resolução cada vez mais alta, mesmo ao incluir alguns tipos de textos, para usuários finais desses equipamentos. Esses avanços por sua vez determinam a utilização de dispositivos de visualização eletrônicos com resolução mais alta como monitores de vídeo de alta definição, monitores HDTV, ou dispositivos de projeção de imagem especializados. A combinação dessas imagens visuais com dados de áudio com alta definição ou qua]idade, como quando se usa reprodução de som tipo CD, DVDs, e outros dispositivos também tendo associadas saídas de sinal de áudio, é utilizada para criar uma experiência de multimídia mais realista, rica em conteúdo ou verdadeira
2/161 τ~ΐο para um usuário final. Além disso, sistemas de som de qualidade alta, altamente móveis e mecanismos de transporte de música, como tocadores de MP3, foram desenvolvidos para apresentações somente de áudio para usuários finais.
Em um cenário de apresentação de vídeo típico, dados de vídeo são tipicamente transferidos utilizando técnicas atuais em uma taxa que podería ser melhor denominada como lenta ou média, sendo da ordem de um a dezenas de kilobits por segundo. Esses dados são então armazenados em buffer (buffered) ou armazenados em dispositivos de memória transientes ou de duração mais longa, para reprodução retardada (posterior) em um dispositivo de visualização desejado. Por exemplo, imagens podem ser transferidas através ou utilizando a Internet gue utiliza um programa residente em um computador tendo um modem ou dispositivo de conexão da Internet, para receber ou transmitir dados úteis em representar digitalmente uma imagem. Uma transferência similar pode ocorrer utilizando dispositivos sem fio como computadores portáteis equipados com modems sem fio, ou Assistentes Pessoais de Dados (PDAs) sem fio, ou telefones sem fio.
Após recebimento, localmente em dispositivos disposi tivos, os dados são armazenados de memória, circuitos ou memória flash, incluindo como RAM ou dispositivos de armazenagem externos, para reprodução. Dependendo da quantidade de dados e da resolução de imagem, a reprodução podería iniciar relativamente rápido, ou ser apresentada com retardo de duração mais longa. Isto é, em algumas ocorrências, a apresentação de imagem permite um certo grau de reprodução em tempo real para imagens de resolução muito pequenas ou baixas não exigindo muitos dados, ou utilizando algum tipo de armazenamento (buffering) de modo que após um pequeno retardo, algum
I
3/161 material é apresentado enquanto mais material está sendo transferido. Desde que não haja interrupções no link de transferência, após inicio da apresentação a transferência é razoavelmente transparente para o usuário final do dispositivo de visualização.
Os dados utilizados para criar imagens fixas ou movimento de video são frequentemente comprimidos utilizando uma de várias técnicas bem conhecidas como aquelas especificadas pelo Joint Photographic Experts Group (JPEG) , o Motion Picture Experts Group (MPEG) e outras organizações ou companhias de padrões bem conhecidas nas indústrias de mídia , computador e comunicações para acelerar a transferência de dados através de um link de comunicação. Isto permite transferência de imagens ou dados mais rápida utilizando um número menor de bits para transferir uma determinada quantidade de informações.
Após transferência dos dados para um dispositivo locai como um computador ou outro dispositivo destinatário, as informações resultantes são não comprimidas (ou reproduzidas utilizando tocadores de decodificação especiais) e decodificadas se necessário, e preparadas para apresentação apropriada com base nos elementos de controle e resolução de apresentação disponíveis, correspondentes. Por exemplo, uma resolução de video de computador típica em termos de uma resolução de tela de X por Y pixels varia tipicamente de tão baixo quanto 480x640 pixels, através de 600x800 até 1024x1280, embora uma variedade de outras resoluções seja geralmente possível, como desejado cu necessário.
A apresentação de imagens também é afetada pelo conteúdo de imagens e a capacidade de controladores de vídeo dados de manipular a imagem em termos de certos níveis de cor predefinidos ou profundidade de cor (bits por
4/161 pixel utilizados para gerar cores) e intensidade, e quaisquer bits overhead adicionais sendo empregados. Por exemplo, uma apresentação de computador típico anteveria em qualquer lugar em torno de 8 a 32, ou mais, bits por pixel para representar diversas cores (tons e matizes), embora outros valores sejam encontrados.
Dos valores acima, pode-se ver que uma dada imagem de tela vai necessitar da transferência de algum lugar de 2,45 Megabits (Mb) até em torno de 33,55 Mb de dados através da faixa das resoluções típicas mais baixas até as mais altas e profundidade, respectivamente. Ao visualizar imagens do tipo movimento ou vídeo em uma taxa de 30 quadros por segundo, a quantidade de dados necessária é em torno de 73,7 a 1.006 Megabits de dados por segundo (Mbps), ou em torno de 9,21 a 125,75 Megabytes por segundo (MBps). Além disse, pode-se desejar apresentar dados de áudio em combinação com imagens, como para uma apresentação de multimídia, ou como uma apresentação de áudio de alta resolução separada, como música de qualidade de CD. Sinais adicionais que lidam com comandos interativos, controles, ou sinais também podem ser empregados. Cada uma dessas opções acrescentando ainda mais dados a serem transferidos. Em qualquer caso, quando se deseja transferir dados de imagem de alta resolução ou alta qualidade e sinais de dados ou informações de áudio de alta qualidade para um usuário final para criar uma experiência rica em conteúdo, um link de taxa de transferência de dados alta é necessário entre os elementos de apresentação e a fonte ou dispositivo hospedeiro que é configurado para fornecer esses tipos de dados.
Taxas de dados em torno de 115 Kilobytes (K3ps) ou 920 Kilobits por segundo (Kbps) podem ser rotineiramente manipuladas por interfaces seriais modernas. Outras
5/161
IV interfaces como interfaces seriais USB, podem acomodar transferências de dados em taxas tão altas quanto 12 MBps, e transferências de alta velocidade especializada como aquelas configuradas utilizando o padrão 1394 do Institute of Electrical and Electronics Engineers (IEEE), podem ocorrer em taxas da ordem 100 a 400 MBps. Infelizmente, essas taxas não alcançam as taxas de dados altas desejadas discutidas acima que são consideradas para utilização com dispositivos e serviços de dados sem fio futuros para fornecer sinais de saída ricos em conteúdo, de alta resolução para acionar dispositivos de áudio ou displays de vídeo portáteis. Além disso, essas interfaces exigem a utilização de uma quantidade significativa de software de cliente e de sistema ou de hospedeiro e para operação. Suas pilhas de protocolo de software também criam uma quantidade indesejavelmente grande de overhead, em especial onde dispositivos sem fio móveis ou aplicações de telefone são considerados. Tais dispositivos tom limitações severas de consumo de energia e memória, bem como capacidade computacional já estabelecida. Além disso, algumas dessas interfaces utilizam cabos volumosos que são demasiadamente pesados e insatisfatórios para aplicações móveis orientadas altamente estéticas, conectores complexos que aumentam custo ou simplesmente consomem energia em demasia.
Há outras interfaces conhecidas como o Adaptador de Gráfico de Vídeo analógico (VGA), interfaces de Interativo de vídeo digital (DVI) ou Interface de vídeo gigabit (GVIF). Os dois primeiros desses são interfaces do tipo paralela que processam dados em taxas de transferência mais altas, porém também empregam cabos pesados e consomem grandes quantidades de energia, da ordem de muitos watts. Nenhuma dessas características é favorável à utilização com dispositivos eletrônicos portáteis de consumidor. Mesmo a
6/161 terceira interface consome energia em demasia e utiliza conectores onerosos ou volumosos.
Para algumas das interfaces acima, e outros sistemas/protocolos de dados de taxa muito alta ou mecanismos de transferência associados a transferências de dados para equipamento de computador de instalação fixa, há outra grande desvantagem. Para acomodar as taxas de transferência de dados desejadas exige-se também quantidades substanciais de energia e/ou operação em altos níveis de corrente. Isto reduz muito a utilidade dessas técnicas para produtos orientados para o consumidor altamente móveis.
Geralmente, para acomodar essas taxas de transferência de dados utilizando alternativas como digamos conexões do tipo de fibra óptica e elementos de transferência, também requer diversos conversores e elementos adicionais que introduzem complexidade e custo muito maiores, do que desejado para um produto orientado para o consumidor verdadeiramente comercial. Além da natureza geralmente onerosa de sistemas ópticos até agora, suas exigências de energia e complexidade evitam utilização geral para aplicações portáteis, de baixa potência e leve.
O que está faltando na indústria para aplicações portáteis ou móveis, é uma técnica para fornecer uma experiência de apresentação de alta qualidade, quer seja áudio, vídeo, ou baseada em multimídia, para usuários finai3 altamente móveis. Isto é, ao utilizar computadores portáteis, telefones sem fio, PDAs, ou outros dispositivos ou equipamentos de comunicação altamente móveis, os sistemas ou dispositivos de apresentação de vídeo e áudio atuais sendo utilizados não podem simplesmente fornecer saída no nível de alta qualidade desejado. Frequentemente, a qualidade percebida que está faltando é o resultado de
27/
7/161 taxas de dados altas não obteníveis necessárias para transferir os dados de apresentação de alta qualidade. Portanto, é necessário um novo mecanismo de transferência para aumentar capacidade de transmissão de dados entre dispositivos hospedeiros que fornecem os dados e dispositivos ou elementos de display de cliente apresentando uma saída para usuários finais.
Os requerentes propuseram esses novos mecanismos de transferência nos pedidos de patente US N°. de série 10/020.520 e 10/236.657, ambos intitulados Generating and Implementing a Communication Protocol and Interface for High Data Rate Signal Transfer, que são cedidos à cessionária da presente invenção e incorporados aqui a título de referência. As técnicas discutidas nesses pedidos podem melhorar muito a taxa de transferência para grandes quantidades de dados em sinais de dados de alta velocidade. Entretanto, as demandas para taxas de dados cada vez mais crescentes, em especial como relacionado a apresentações de vídeo, continuam a crescer. Mesmo com outros desenvolvimentos contínuos em tecnologia de sinais de dados, há ainda necessidade de se esforçar por taxas de transferência ainda mais rápidas. Portanto, há uma necessidade contínua de se desenvolver um mecanismo de transferência novo ou aperfeiçoado que é necessário para aumentar capacidade de transmissão (throughput) de dados entre dispositivos hospedeiros e de cliente.
SUMÁRIO
A desvantagem acima e outras existentes na técnica são tratadas pelas modalidades da presente invenção na qual um novo mecanismo de transferência de dados e protocolo foi desenvolvido para transferir dados entre um dispositivo hospedeiro e um dispositivo cliente destinatário em taxas de dados altas.
7/
8/161
As modalidades para a invenção são dirigidas a uma Interface Digital de Dados Móvel (MDDI) para transferir dados digitais em uma alta taxa entre um dispositivo hospedeiro e um dispositivo cliente através de um percurso de comunicação que emprega uma pluralidade ou série de estruturas de pacotes ligadas juntas para formar um protocolo de comunicação para comunicar um conjunto préselecionado de dados de apresentação e controle digitais entre os dispositivos hospedeiro e cliente. A camada de link ou protocolo de comunicações de sinal é utilizada por uma camada física de controladores de link de hospedeiro ou de cliente. Pelo menos um controlador de link residindo no dispositivo hospedeiro é acoplado ao dispositivo cliente através do link ou percurso de comunicação, e é configurado para gerar, transmitir e receber pacotes que formam o protocolo de comunicação, e formar dados de apresentação digitais em um ou mais tipos de pacotes de dados. A interface provê transferência bidirecional de informações entre o hospedeiro e o cliente.
Em aspectos adicionais de modalidades da invenção, pelo menos um controlador de link de cliente, ou receptor cliente, é disposto no dispositivo clienre e é acoplado ao dispositivo hospedeiro através do link ou percurso de comunicação. O controlador de link de cliente também é configurado para gerar, transmitir e receber pacotes formando o protocolo de comunicação e para formar dados de apresentação digitais em um ou mais tipos de pacotes de dados. Geralmente, o controlador de link ou hospedeiro emprega uma máquina de estado para processar pacotes de dados utilizados em comandos ou certos tipos de preparação de sinal e processamento de consulta, porém pode utilizar um processador de finalidade geral mais lento para manipular dados e alguns dos pacotes menos complexos
9/161 utilizados no protocolo de comunicação. O controlador hospedeiro compreende um ou mais acionadores (drivers) de linha de diferencia); enquanto o receptor de cliente compreende um ou mais receptores de linha de diferencial acoplados ao percurso de comunicação.
Os pacotes são agrupados juntos em quadros de mídia que são comunicados entre os dispositivos hospedeiro e cliente tendo um comprimento fixo predefinido com um número predeterminado de pacotes tendo comprimentos
1C variáveis diferentes. Os pacotes compreendem, individualmente, um campo de comprimento de pacote, um ou mais campos de dados de pacotes, e um campo de verificação de redundância cíclica. Um Pacote de Cabeçalho de Subquadro é transferido ou posicionado no início de transferências de outros pacotes do controlador de link de hospedeiro. Um ou mais pacotes do tipo de Fluxo de vídeo e pacotes do tipo Fluxo de Áudio são utilizados pelo protocolo de comunicação para transferir dados do tipo vídeo e dados do tipo áudio, respectivamente, do hospedeiro para o cliente através de um link direto para apresentação a um usuário de dispositivo cliente. Um ou mais pacotes do tipo Encapsulamento de Link reverso são utilizados pelo protocolo de comunicação para transferir dados do dispositivo cliente para o controlador de link de hospedeiro.
Pacotes dc tipo preenchedor são gerados pelo controlador de link de hospedeiro para ocupar períodos de transmissão de link direto que não têm dados. Uma pluralidade de outros pacotes é utilizada pelo protocolo de comunicação para transferir informações de vídeo. Tais pacotes incluem Mapa de Cores, Transferência de Bloco de Bits, Preenchimento de Área de Mapa de Bits, Preenchimento de Padrão de Mapa de Bits, e pacotes do tipo Habilitar Cor Transparente. Pacotes do tipo Fluxo definido pelo usuário
10/161
2// são utilizados pelo protocolo de comunicação para transferir dados definidos pelo usuário-interface. Pacotes do tipo Dados de Teclado e Dados de Dispositivo de Apontamento são utilizados pelo protocolo de comunicação para transferir dados para ou dos dispositivos de entrada de usuário associados ao referido dispositivo cliente. Um pacote do tipo Desligamento de Link é utilizado pelo protocolo de comunicação para terminar a transferência de dados em qualquer direção através do referido percurso de comunicação.
O percurso de comunicação compreende ou emprega geralmente um cabo tendo uma série de quatro ou mais condutores e uma blindagem. Em algumas modalidades os controladores de link compreendem uma interface de dados USB e o cabo utiliza uma interface do tipo USB juntamente com os outros condutores. Além disso, fios impressos ou condutores flexíveis podem ser utilizados, como desejado.
O controlador de link de hospedeiro solicita informações de capacidades de exibição do dispositivo ciiente para determinar qual tipo de dados e taxas de dados o referido cliente é capaz de acomodar através da referida interface. O controlador de link de cliente comunica capacidades de exibição ou apresentação para o controlador de link de hospedeiro utilizando pelo menos um pacote do tipo de Capacidade de Exibição. Múltiplos modos de transferência são utilizados pelo protocolo de comunicação com cada um permitindo a transferência de números máximos diferentes de bits de dados em paralelo através de um dado período de tempo, com cada modo selecionável por negociação entre os controladores de link de hospedeiro e cliente. Esses modos de transferência são dinamicamente ajustáveis durante transferência de dados, e o mesmo modo não
11/161
2/9 necessita ser utilizado no link reverso como utilizado no link direto.
Em outros aspectos de algumas modalidades da invenção, c dispositivo hospedeiro compreende um dispositivo de comunicação sem fio, como um telefone sem fio, um PDA sem fio, ou um computador portátil tendo um modem sem fio disposto no mesmo. Um dispositivo cliente típico compreende um display de vídeo portátil como um dispositivo micro-display e/ou um sistema de apresentação de áudio portátil. Alèm disso, o hospedeiro pode utilizar elementos ou meios de armazenagem para armazenar dados de apresentação ou multimídia a serem transferidos para serem apresentados a um usuário de dispositivo cliente.
BREVE DESCRIÇÃO DOS DESENHOS
Aspectos e vantagens adicionais da invenção, bem como a estrutura e operação de diversas modalidades da invenção, são descritos em detalhes abaixo com referência aos desenhos em anexo. Nos desenhos, números de referência similares indicam geralmente elementos ou etapas de processamento idênricos, funcionalmente similares, e/ou estruturalmente similares, e o desenho no qual um elemento primeiramente aparece é indicado pelo(s) dígito(s) mais à esquerda no número de referência.
A figura IA ilustra um ambiente básico no qual modalidades da invenção poderíam operar incluindo a utilização de um dispositivo de micro-display utilizado em combinação com um computador portátil.
A figura IS ilustra um ambiente básico no qual
modalidades da invenção poderíam operar incluindo a
utilização de um dispositivo de micro-display e
dispositivos de apresentação de áudio utilizados em
combinação ccm um transceptor sem fio.
12/161 ζ^
Ά figura 2 ilustra ο conceito geral de uma Interface de Dados Digitais Móvel com uma interconexão de cliente e hospedeiro.
A figura 3 ilustra a estrutura de um pacote útil para realizar transferências de dados de um dispositivo cliente para um dispositivo hospedeiro.
A figura 4 ilustra a utilização de um controlador de link MDDI e os tipos de sinais passados entre um hospedeiro e um cliente através dos condutores de link de dados físicos para as inrerfaces do Tipo I e Tipo U.
A figura 5 ilustra a utilização de um controlador de link MDDI e os tipos de sinais passados entre um hospedeiro e um cliente através dos condutores de link de dados físicos para as interfaces Tipos II, III e IV.
A figura 6 ilustra a estrutura de quadros e subquadros utilizados para implementar o protocolo de interface.
A figura 7 iiustra a estrutura geral de pacotes utilizados para implementar o protocolo de interface.
A figura 8 ilustra Cabeçalho de Subquadro. o formato de um Pacote de
A figura 9 ilustra o formato e conteúdo de um
Pacote Preenchedor.
A figura 10 ilustra o formato de um Pacote de
Fluxo de Vídeo.
A figura 11 ilustra o formato e conteúdo para o
Descritor de Formato de dados dc vídec da figura 10.
A fiqura 12 ilustra a utilização de formatos empacotados e desempacotados para dados.
A figura 13 ilustra o formato de um Pacote de
Fluxo de Áudio.
A figura 14 ilustra a utilização de formatos PCM empacotados e alinhados em byte para dados.
13/161
A figura 15 ilustra o formato de um Pacote de
Fluxo Definido pelo Usuário.
A figura 16 ilustra o formato de um Pacote de
Mapa de Cores.
5 A figura 17 ilustra o formato de um Pacote de
Encapsulamento de Link Reverso.
A figura 18 ilustra o formato de um Pacote de
Capacidade de Display.
A figura 19 ilustra o formato de um Pacote de
10 Dados de Teclado.
A figura 20 ilustra o formato de um Pacote de
Dados de Dispositivo de Apontamento.
A figura 21 ilustra o formato de um Pacote de
Desligamento de Link.
15 A figura 22 ilustra o formato de um Pacote de
Status e Solicitação de Display •
A figura 23 ilustra o formato de um Pacote de
Transferência de Bloco de Bits.
A figura 24 ilustra o formato de um Pacote de
20 Preenchimento de Área de Mapa de Bits.
A figura 25 ilustra o formato de um Pacote de
Preenchimento de Padrão de Mapa de Bits.
A figura 26 ilustra o formato de um Pacote de
Canal de Dados de Link de Comunicação.
25 A figura 27 ilustra o formato de um Pacote de
Solicitação de Handoff do Tipo de Interface.
A figura 28 ilustra o formato de um Pacote de
Confirmação de Tipo de Interface.
A figura 29 ilustra o formato de um Pacote de
30 Handoff do Tipo Executar.
A figura 30 ilustra o formato de um Pacote de
Habilitar Canal de Áudio Direto.
14/161
A figura 31 ilustra o formate de um pacote de Taxa de Amostra de Áudio Reverso.
A figura 32 ilustra o formato de um Pacote Overhead para Proteção de Conteúdo Digital.
A figura 33 ilustra o formato de um Pacote de Habilitação de Cor Transparente.
A figura 34 ilustra o formato de um Pacote de Medição de Retardo de Ida e Volta.
A figura 35 ilustra a temporização de eventos durante o Pacote de Medição de Retardo de Ida e Volta.
A figura 36 ilustra uma implementação de amostra de um gerador CRC e verificador útil para implementar a invenção.
A figura 37A ilustra a temporização de sinais CRC para o aparelho da figura 36 ao enviar pacotes de dados.
A figura 37B ilustra a temporização de sinais CRC para o aparelho da figura 36 ao receber pacotes de dados.
A figura 38 ilustra etapas de processamento para uma solicitação típica de serviço sem contenção.
A figura 39 ilustra etapas de processamento para uma solicitação típica de serviço determinada após início da seqüência de reiniciar link, com contenção com início de link.
A figura 40 ilustra como uma seqüência de dados pede ser transmitida utilizando codificação DATA-STB.
A figura 41 ilustra conjunto de circuitos útil para gerar os sinais DATA e STB dos dados de entrada no hospedeiro, e a seguir recuperar os dados do cliente.
A figura 42 ilustra drivers e resistores de terminação úteis para implementar uma modalidade.
A figura 43 ilustra etapas e níveis de sinais empregados por um cliente para assegurar serviço do hospedeiro e pelo hospedeiro para fornecer esse serviço.
15/161
A figura 44 ilustra espaçamento relativo entre transições no DataO, outras linhas de dados (DataX) e as linhas de estrobo (Stb).
A figura 45 ilustra a presença de um retardo em resposta que pode ocorrer quando um hospedeiro desabilita o driver hospedeiro após transferir um pacote.
A figura 46 ilustra a presença de um retardo em resposta que pode ocorrer guando um hospedeiro habilita o driver hospedeiro a transferir um pacote.
A figura 47 ilustra a relação na entrada de receptor hospedeiro entre a temporização dos dados sendo transferidos e as bordas dianteira e traseira dos pulsos de estrobo.
A figura 48 ilustra características de comutação e retardo de saída de cliente correspondente desenvolvidos pela temporização de dados reversos.
A figura 49 ilustra um diagrama de nível alto de etapas de processamento de sinais e condições pelas quais a sincronização pode ser implementada utilizando uma máquina de estado.
A figura 50 ilustra quantidades típicas de retardo encontradas para processamento de sinais nos percurso direto e reverso em um sistema empregando o MDDI.
A figura 51 ilustra medição de retardo de ida e volta marginal.
A figura 52 ilustra alterações de taxas de dados de Link Reverso.
A figura 53 ilustra uma representação gráfica de valores do Divisor de Taxa Reversa versus a taxa de dados de link direto.
As figuras 54A e 54B ilustram etapas empreendidas na operação de uma interface.
16/161
Z)i1
A figura 55 ilustra uma visão geral dos pacotes de processamento do aparelho de interface.
A figura 56 ilustra o formato de um Pacote de Link direto.
A figura 57 ilustra valores típicos para retardo de propagação e distorção em uma interface de Link Tipo-I.
A figura 58 ilustra Dados, Stb e Temporização de recuperação de relógio em um Link Tipo-I para processamento exemplar de sinais através da interface.
A figura 59 ilustra valores típicos para retardo de propagação e distorção em interfaces de Link Tipo-II, Tipo-III ou Tipo-IV.
As figuras 60A, 60B e 60C ilustram diferentes possibilidades para a temporização de dois sinais de dados em MDDI_Stb um em relação ao outro, sendo ideal, cedo e tarde, respectivamente.
A figura 61 ilustra conectores exemplares de atribuições de pino de interface utilizados com interfaces Tipo I/Tipo II.
As figuras 62A e 62B ilustram possíveis formas de onda MDDI_Data e MDDI_Stb para ambas as Interfaces Tipo I e Tipo II, respectivamente.
A figura 63 ilustra um diagrama de nível alto de etapas e condições de processamento de sinais alternativos pelos quais a sincronização pode ser implementada utilizando uma máquina de estado.
A figura 64 ilustra temporização relativa exemplar entre uma série de ciclos de relógio e a temporização de diversos bits de pacotes de link reverso e valores divisores.
A figura 65 ilustra processamento exemplar de transferência de código de erro.
ΖΎ 5
17/161
Ά figura 66 ilustra aparelho útil para processamento de transferência de código de erro.
A figura 67A ilustra processamento de transferência de código de erro para sobrecarga de código.
A figura 67B ilustra processamento de transferência do código de erre para recepção de código.
A figura 68A ilustra etapas de processamento para um despertar (wake-up) iniciado por hospedeiro.
A figura 68B ilustra etapas de processamento para um despertar iniciado por cliente.
A figura 68C ilustra etapas de processamento para despertar iniciado por hospedeiro e cliente com contenção.
DESCRIÇÃO DETALHADA DAS MODALIDADES
I. Visão Geral
Uma intenção geral da invenção é fornecer uma Interface Digital de Display Móvel (MDDI), como discutido abaixo, que resulta em ou fornecer um mecanismo de transferência com baixo consumo de energia, eficaz em termos de custo que permite transferência de dados em velocidade alta ou muito alta através de um link de comunicação de curto alcance entre um dispositivo hospedeiro e um dispositivo de display utilizando um tipo serial de link de dados ou canal. Esse mecanismo se presta à implementação com conectores em miniatura e cabos flexíveis delgados que são especialmente úteis na conexão de elementos ou dispositivos de display como micro-displays utilizáveis (óculos ou projetores) para computadores portáteis, dispositivos de comunicação sem fio ou dispositivos de entretenimento.
Uma vantagem das modalidades da invenção é que uma técnica é fornecida para transferência de dados que é de baixa complexidade, baixo custo, tem alta custo,
18/161
2ÍZ confiabilidade, adapta-se bem no ambiente deutilização, e é muito robusta, embora permaneça muito flexível.
A presente invenção pode ser utilizada em uma variedade de situações para comunicar ou transferir grandes quantidades de dados, geralmente para aplicações de áudio, vídeo ou multimídia de um dispositivo de fonte ou hospedeiro, onde tais dados são gerados ou armazenados, para um dispositivo de apresentação ou display de cliente a uma taxa alta. Uma aplicação típica, que é discutida abaixo, é a transferência de dados de um computador portátil ou um telefone sem fio ou modem para um dispositivo de display visual como uma pequena tela de vídeo ou um aparelho de micro-display utilizável, como na forma de óculos ou capacetes contendo pequenas lentes de projeção e telas, ou de um hospedeiro para dispositivo cliente em tais componentes. Isto é, de um processador para uma tela interna ou outro elemento de apresentação.
As caracter!sticas ou atributos da MDDI são tais que são independentes de tecnologia de display específica. Este é um mecanismo altamente flexível para transferência de dados a uma taxa alta sem considerar à estrutura interna daqueles dados, nem os aspectos funcionais dos dados ou comandos que implementa. Isto permite que a temporizaçào de pacotes de dados, sendo transferidos, seja ajustada para adaptar-se às idiossincrasias de dispositivos de display específicos, ou desejos de display exclusivos para certos dispositivos, ou para atender as exigências dc áudio e vídeo combinados para alguns sistemas A-V. A interface é muito agnóstica a dispositivo cliente ou dispositivo de display, desde que o protocolo selecionado seja seguido. Além disso, os dados de link seriais agregados ou taxa de dados podem variar através de várias ordens de magnitude que permita a um projetista de dispositivo hospedeiro cu
19/161 /37· sistema de comunicação otimizar o custo, exigências de potência, complexidade do dispositivo cliente, e taxas de atualização de dispositivo de display.
A interface de dados é apresentada principalmente para utilização na transferência de grandes quantidades de dados em taxa alta através de um pequeno cabo ou link de sinal com fio. Entretanto, algumas aplicações podem tirar proveito também de um link sem fio, incluindo links de base óptica, desde gue seja configurado para utilizar as mesmas estruturas de dados e pacote desenvolvidas para o protocolo de interface, e possa sustentar o nível desejado de transferência em complexidade ou consumo de potência baixo o suficiente para permanecer prático.
II. Ambiente
Uma aplicação típica pode ser vista nas figuras IA e 1B, onde um computador laptop ou portátil 10C e telefone sem fio ou dispositivo PDA 102 são mostrados comunicando dados com dispositivo de display 104 e 106, respectivamente, juntamente com sistemas de reprodução de áudio 108 e 112. Além disso, a figura IA mostra conexões em potencial a uma tela ou display maior 114 ou um projetor de imagem 116, gue são mostrados somente em uma figura para clareza, porém são conectáveis também ao dispositivo sem fio 102. O dispositivo sem fio pode estar atualmente recebendo dados ou ter previamente armazenada uma certa quantidade de dados do tipo multimídia em um dispositivo ou elemento de memória para apresentação posterior para visualização e/ou escuta por um usuário final do dispositivo sem fio. Uma vez que um dispositivo sem fio típico é utilizado para voz e comunicações de texto simples grande parte do tempo, o mesmo tem uma tela de display bem pequena e sistema de áudio simples (alto-falantes) para comunicar informações para o usuário do dispositivo 102.
20/161 ϊίΤ
Ο computador 100 tem uma tela muito maior, porém ainda um sistema de som externo inadequado, e ainda não alcança outros dispositivos de apresentação de multimídia como uma televisão de alta definição ou telas de cinema. 0 computador 100 é utilizado para fins de ilustração e outros tipos de processadores, jogos de vídeo interativos, ou dispositivos eletrônicos de consumidor também podem ser utilizados com a invenção. O computador 100 pode empregar, porém não é limitado a ou por, um modem sem fio ou outro dispositivo incorporado para comunicação sem fio, ou ser conectado a tais dispositivos utilizando um link sem fio ou cabo, como desejado.
Isto torna a apresentação de dados mais complexos ou ricos uma experiência menos útil ou desfrutável. Portanto, a indústria está desenvolvendo outros mecanismos e dispositivos para apresentar as informações para usuários finais e fornecer um nível mínimo de experiência positiva ou prazer desejável.
Como anteriormente discutido acima, vários tipos de dispositivos de display têm ou estão sendo atualmente desenvolvidos para apresentar informações para usuários finais do dispositivo 100. Por exemplo, uma ou mais companhias desenvolveram conjuntos de óculos utilizáveis gue projetam uma imagem na frente dos olhos do usuário de um dispositivo para apresentar um display visual. Quando posicionados corretamente tais dispositivos projetam eficazmente uma imagem virtual, como percebido pelos olhos de um usuário, que é muito maior do que o elemento que fornece a saída visual. Isto é, um elemento de projeção muito pequeno permite que o(s) olho(s) do usuário veja(m) imagens em uma escala muito maior do que possível com telas LCD típicas e similares. A utilização de imagens de tela virtual maiores permite também a utilização de imagens de
21/161 resolução muito mais alta do que seria possível com displays de tela LCD mais limitados. Outros dispositivos de display poderíam incluir, porém não são limitados a, pequenas telas LCD ou diversos dispositivos de display de painel plano, lentes de projeção e acionadores (drivers) de display para projetar imagens em uma superfície, e assim por diante.
Pode haver também elementos adicionais conectados a ou associados à utilização de dispositivo sem fio 102 ou computador 100 para apresentar uma saída para outro usuário, ou para outro dispositivo que por sua vez transfere os sinais para outro lugar ou armazena os mesmos. Por exemplo, dados podem ser armazenados em memória flash, em forma óptica, por exemplo, utilizando uma mídia CD gravável ou em mídia magnética como em um gravador de fita magnética e dispositivos similares, para utilização posterior.
Além disso, muitos dispositivos sem fio e computadores têm agora capacidades de decodificação de música MP3 incorporadas, bem como outros sistemas e decodificadores de som diretos. Computadores portáteis utilizam capacidades de reprodução de DVD e CD como regra geral, e alguns têm pequenas leitoras de memória flash dedicadas para receber arquivos de áudio pré-gravadcs. A questão com o fato de se ter essas capacidades é que arquivos de música digitais prometem uma experiência rica em características altamente aumentadas, porém somente se o processo de decodificação e reprodução puder acompanhar o passo. 0 mesmo é verdadeiro para os arquivos de vídeo digitais.
Para auxiliar com reprodução de som, altofalantes externos 114 são mostrados na figura ia, os quais também poderíam ser acompanhados por elementos de adição
Figure BRPI0410885B1_D0001
22/161 como sub-woofers, ou alto-falantes surround-sound para projeção de som frontal e traseira. Ao mesmo tempo, altofalantes ou fones de ouvido 108 são indicados como incorporados no quadro de suporte ou mecanismo de dispositivo de micro-display 106 da figura lb. Como seriam conhecidos, outros elementos de reprodução de áudio ou som podem ser utilizados incluindo dispositivos de formatação de som ou amplificação de potência.
Em qualquer caso, como discutido acima, quando se deseja transferir informações de áudio de alta qualidade e dados de imagem de alta resolução ou alta qualidade ou sinais de dados de uma fonte de dados para um usuário final através de um ou mais links de comunicação 110, é necessária uma taxa de dados alta. Isto é, o link de transferência 110 é claramente um gargalo potencial na comunicação de dados como discutido anteriormente, e limita desempenho do sistema, uma vez que mecanismos de transferência de corrente não obtêm as altas taxas de dados tipicamente desejadas. Como discutido acima, por exemplo, para resoluções de imagem mais altas como 1024 por 1024 pixels, com profundidades de cores de 24-32 bits per pixel e em taxas de dados de 30 fps, as taxas de dados podem se aproximar de taxas em excesso de 755 Mbps ou mais. Além disso, tais imagens podem ser apresentadas como parte de uma apresentação de multimídia que inclui dados de áudio e potencialmente sinais adicionais que lidam com comunicações ou jogos interativos, ou diversos comandos, controles ou sinais, aumentando ainda mais a quantidade ou dados e a taxa de dados.
Também é evidente que um número menor de cabos ou interconexões necessários para estabelecer um link de dados significa que os dispositivos móveis associados a um display são mais fáceis de se usar, e mais prováveis de
23/161 serem adotados por uma base maior de usuário. Isto é especialmente verdadeiro, onde múltiplos dispositivos sào comumente utilizados para estabelecer uma experiência audiovisual completa, e mais especiaimente quando o nível de qualidade dos displays e dispositivos de saída de áudio aumenta.
Infelizmente, as taxas de dados mais altas excedem tecnologia atual disponível para transferência de dados. O que é necessário é uma técnica para transferir dados em taxas mais altas para o link de transferência de dados ou percurso de comunicação entre elementos de apresentação e a fonte de dados, que permite potência consistentemente baixa (mais baixa), peso leve, e uma estrutura de cabeamento tão simples e econômica quanto possível. Os requerentes desenvolveram uma nova técnica, ou método e equipamento, para obter esses e outros objetivos a fim de permitir que um arranjo de dispositivos de localização móvel, portátil ou mesmo fixa transfira dados para displays, micro-displays ou elementos de transferência de áudio desejado, em taxas de dados muito altas, enquanto mantém um baixo consumo de potência e complexidade desejadas.
III. Arquitetura do Sistema de Interface de Dados Digitais de Taxa Alta
A fim de criar e utilizar eficientemente uma nova interface de dispositivo, uma arquitetura de sistema e protocolo de sinal foi formulada que provê uma taxa de transferência de dados muito alta utilizando sinais de baixa energia. 0 protocolo se baseia em uma estrutura de quadro comum e pacote, ou estruturadas ligadas juntas para formar um protocolo para comunicar um conjunto préselecionadc de dados ou tipos de dados juntamente com uma
24·Λ
24/161 conectado a um cliente comunicacâo bidirecional estrutura operacional ou de comando imposta sobre a interface.
A. Visão Geral
Os dispositivos conectados por ou se comunicando através do link MDDI sâo denominados hospedeiro e cliente, com o cliente sendo tipicamente um dispositivo de display de algum tipo. Os dados do hospedeiro para o display viajam na direção direta (mencionada como link ou tráfego direto) e os dados do display para o hospedeiro viajam na direção reversa (link ou tráfego reverso) como habilitados pelo hospedeiro. Isto é ilustrado na configuração básica mostrada na figura 2. Na figura 2, um hospedeiro 202 é 204 utilizando um canal de 206 que é ilustrado como compreendendo um link direto 208 e um link reverso 210. Entretanto, esses canais sâo formados por um conjunto comum de condutores cuja transferência de dados é comutada eficazmente entre as operações de link direto ou reverso.
Como discutido em outra parte, o hospedeiro compreende um de vários tipos de dispositivos que podem se beneficiar da utilização da presente invenção. Por exemplo, o hospedeiro 202 poderia ser um computador portátil na forma de um dispositivo de computação móvel, portátil, laptop, ou similar, poderia ser um PDA, um dispositivo de paging, ou um de muitos modems ou telefones sem fio. Alternativamente, o hospedeiro 202 poderia ser um dispositivo de entretenimento ou apresentação portátil como um tocador de CD ou DVD portátil, ou um dispositivo de jogos. Ao mesmo tempo, o cliente 204 poderia compreender uma variedade de dispositivos úteis para apresentar informações para um usuário final. Por exemplo, um microdisplay incorporado em óculos ou lentes, um dispositivo de projeção embutido em um chapéu ou capacete, uma tela
25/161 pequena ou mesmo elemento hclográfico embutido em um veículo, como em uma janela ou pára-brisa, ou diversos sistemas de alto-falante, fone de cabeça, ou som para apresentar música ou som de alta qualidade. Entretanto, aqueles versados na técnica facilmente reconhecerão que a presente invenção não é limitada a esses dispositivos, havendo muitos outros dispositivos no mercado, e propostos para utilização, que pretendem fornecer aos usuários finais com som e imagens de alta qualidade, quer em termos de armazenagem e transporte ou em termos de apresentação na reprodução. A presente invenção é útil para aumentar a capacidade de transmissão (tnroughput) de dados entre diversos dispositivos para acomodar as taxas de dados altas necessárias para realizar a experiência desejada pelo usuário.
B. Tipos de Interface
A Interface KDD é considerada como tratando cinco ou mais tipos físicos de um certo modo distintos de interfaces encontradas nas indústrias de computador e comunicações. Essas são rotuladas nesse ponto simplesmente como Tipo—I, Tipo-II, Tipo-lII, Tipo-IV e Tipo-U.
A interface do Tipo-I é configurada como uma interface de 6 fios (condutores) que a torna apropriada para telefones móveis ou sem fio, PDAs, e-Books, jogos eletrônicos, e media players portáteis, como tocadores de CD, ou tocadores de MP3, e dispositivos em tipos similares de tecnologia eletrônica de consumidor. A interface Tipo-U é configurada como uma interface de 8 fios (condutores) gue é mais apropriada para computadores pessoais de laptcp, notebook, ou de mesa e dispositivos ou aplicações similares, que não exigem que o display seja atualizado rapidamente e não têm um controlador de link MDDI incorporado. Esse tipo de interface também é distinguível
2V
26/161 pela utilização de uma interface de Barramento Serial Universal (USB) de dois fios, adicional, que é extremamente útil para acomodar sistemas operacionais existentes ou suporte de software encontrado na maioria dos computadores pessoais. As interfaces Tipo-U também podem ser utilizadas em um modo USB somente onde o display simplesmente tem um conector USB que se conecta em uma porta USB padrão em um computador ou dispositivo similar, por exemplo, um dispositivo eletrônico de consumidor equipado com essa porta, como câmaras digitais ou video players.
As interfaces Tipo-II, Tipo-III e Tipo-IV são apropriadas para dispositivos ou displays de alto desempenho e utilizam cabeamento maior e mais complexo com condutores do tipo de pares trançados adicionais para fornecer a blindagem apropriada e baixas transferências de perda para sinais de dados.
A Interface Tipo-I passa sinais que podem compreender tanto as informações de display, áudio, controle e sinalização limitada, e é tipicamente utilizada para dispositivos que não exigem dados de vídeo de taxa total e alta resolução. Esse tipo de interface é destinado principalmente a dispositivos, como dispositivos sem fio móveis, onde um hospedeiro USB é tipicamente não disponível no dispositivo para conexão e transferência de sinais. Nessa configuração, o dispositivo móvel é um dispositivo hospedeiro MDDI, e atua como o mestre que controla o link de comunicação do hospedeiro, que geralmente envia dados de display para o cliente (link ou tráfego direto).
Nessa interface, um hospedeiro permite recebimento de dados de comunicação no hospedeiro proveniente do cliente (link ou tráfego reverso) pelo envio de um tipo de pacote ou comando especial para o cliente que permite que o mesmo assuma o barramento (link) por uma
Figure BRPI0410885B1_D0002
27/161 duração especificada e envie dados para o hospedeiro como pacotes reversos. Isto é ilustrado na figura 3, onde um tipo de pacote mencionado como um pacote de encapsulamento (discutido abaixo) é utilizado para acomodar a transferência de pacotes reversos através do link de transferência, criando o link reverso. O intervalo de tempo alocado para o hospedeiro para interrogar o display para dados é predeterminado pelo hospedeiro, e se baseia nas exigências de cada aplicação especificada. Esse tipo de transferência de dados bidirecional half-duplex é especialmente vantajosa onde uma porta USB não está disponível para transferência de informações ou dados do cliente.
A interface Tipo-U transfere sinais que são bem apropriados para utilização em aplicações de laptop e de mesa onde uma interface USB é amplamente suportada por extensas quantidades de placas-mãe ou outro hardware, e por software de sistema operacional. A utilização de uma interface USB adicionada permite a utilização com recursos de plug-and-piay e configuração de aplicação fácil. A inclusão de USB também permite fluxo bidirecional de finalidade geral de comandos, status, dados de áudio e assim por diante enquanto dados de áudio e vídeo destinados ao dispositivo cliente podem ser transferidos utilizando os pares trançados em baixa potência e alta velocidade. A potência pode ser transferida utilizando outros fios, como discutido abaixo. As modalidades da invenção utilizando uma interface USB permitem transferências em alta velocidade através de um conjunto de condutores enquanto implementa principalmente sinalização e controle através da conexão USB, que pode ser desligada quando não em utilização e consome pouca potência.
28/161
A interface USB é um padrão extensair.er.te utilizado para equipamentos de computador pessoal modernos, e os detalhes de uma interface USB e sua operação são bem conhecidos na técnica, desse modo não são explicados aqui. Para a interface USB, a comunicação entre o hospedeiro e dispiay estão em conformidade com a Especificação de barramento Serial Universal, Revisão 2.0. Em aplicações utilizando a interface Tipo-U onde USB é o canal de sinalização primário e possivelmente um canal de retorno de voz, é opcional para o hospedeiro checar o cliente através dos sinais de dados seriais de MDDI.
Displays de aluo desempenho capazes de resoluções altas do tipo HDTV ou similares exigem fluxos de dados com taxa em torno de 1,5 Gbps a fim de suportar vídeo de movimento completo. A interface Tipo-II suporta taxas de dados altas pela transmissão de 2 bits em paralelo, o TipoIII pela transmissão de 4 bits em paralelo, e a interface Tipo IV transfere 8 bits em paralelo. O protocolo utilizado pela MDDI permite que cada hospedeiro do Tipo I, II, IIT ou
IV comunique geraimente com qualquer cliente ou dispiay do tipo I, II, III ou IV pela negociação de qual é a taxa mais alta de dados possível que pode ser utilizada. As capacidades ou recursos disponíveis do que se pode referir como o dispositivo com capacidade mínima são utilizados para definir o desempenho do link. Como regra, mesmo para sistemas onde c hospedeiro e cliente são ambos capazes utilizando interfaces do Tipo II, Tipo III ou Tipo IV, ambos iniciam a operação como uma Interface do Tipo I. O hospedeiro determina então a capacidade do dispiay ou cliente alvo, e negocia uma operação de hand-off ou reconfiguraçâo para o modo Tipo II, Tipo III ou Tipo IV, como apropriado para a aplicação específica.
Figure BRPI0410885B1_D0003
29/161
É geralmente possível que o hospedeiro utilize o protocolo de camada de link adequado (discutido adicionalmente abaixo) e a qualquer momento reduza cu reconfigure novamer.te a operação em um modo mais lento para poupar energia ou acelerar para um modo mais rápido para suportar transferências de velocidade mais alta, como para conteúdo de exibição de resolução mais alta. Por exemplo, um hospedeiro pode alterar modos de display quando o sistema de display comuta de uma fonte de energia como uma
1C batería para energia CA, ou quando a fonte das mídias de display comuta para um formato de resolução mais baixo ou mais alto, ou uma combinação dessas ou de outras condições ou eventos pode ser considerada como base para alterar um display ou modo de transferência de dados.
Também é possível para um sistema comunicar dados utilizando um modo em uma direção e outro modo em outra direção. Por exemplo, um modo de interface do Tipo IV poderia ser utilizado para transferir dados para um display em uma taxa alta, enquanto um modo Tipo T ou Tipo U é utilizado ao transferir dados para um dispositivo hospedeiro de dispositivos periféricos como um teclado ou um dispositivo de apontamento.
C. Estrutura de Interface Física
A disposição geral de um dispositivo ou controlador de link para estabelecer comunicações entre dispositivos hospedeiros e cliente é mostrada nas figuras 4 e 5. Na figura 4 e 5, um controlador de link MDDI 402 o 502 é mostrado instalado em um dispositivo hospedeiro 202 e um controlador de link MDDI 404 e 504 é mostrado instalado em um dispositivo cliente 204. Como anteriormente, o hospedeiro 202 é conectado a um cliente 204 utilizando um canal de comunicação bidirecional 406 compreendendo uma série de condutores. Como discutido abaixo, os
Como
30/161
Ζ47 controladores de link tanto hospedeiro como de cliente podem ser fabricados como um circuito integrado utilizando um único desenho de circuito que pode ser definido, ajustado ou programado para responder como um controlador de hospedeiro (acionador) ou um controlador de cliente (receptor). Isto provê custos mais baixos devido à fabricação em maior escala de um único dispositivo de circuito.
Na figura 4, um dispositivo hospedeiro USB 408 e um dispositivo cliente USB 410 são também mostrados para utilização na implementação de versões de interface Tipo U do MDDI. Os circuitos e dispositivos para implementar essas funções são bem conhecidos na técnica, e não são descritos em detalhes adicionais aqui.
Na figura 5, um controlador de link MDDI 502 é mostrado instalado em um dispositivo hospedeiro 202' e um controlador de link MDDI 504 é mostrado instalado em um dispositivo cliente 204'. Como anteriormente, o hospedeiro 202' é conectado a um cliente 204' utilizando um canal de comunicação bidirecional 506 compreendendo uma série de condutores. Como discutido anteriormente, os controladores de link tanto de hospedeiro como de cliente podem ser fabricados utilizando um projeto de circuito único.
Os sinais passados entre um hospedeiro e um cliente, como um dispositivo de display, através do link MDDI, ou os condutores físicos utilizados, também são ilustrados nas figuras 4 e 5. Como visto nas figuras 4 e 5, o percurso principal ou mecanismo para transferir dados através da MDDI utiliza sinais de dados rotulados como MDDI_Data0+/- e MDDI_Stb+/-. Cada um desses são sinais de dados de baixa tensão que são transferidos através de um par diferencial de fies em um cabo. Há somente uma Lransição no par MDDI_DataO ou par MDDI_Stb para cada bit
Figure BRPI0410885B1_D0004
31/161 enviado través da interface. Esse é um mecanismo de transferência baseado em tensão não baseado em corrente, desse modo o consumo de corrente estática é quase zero. 0 hospedeiro aciona os sinais MDDI_Stb para o display de cliente.
Embora os dados possam fluir nas direções tanto direta como reversa através dos pares de MDDI_Daca, isto é, é um percurso de transferência bidirecional, o hospedeiro é o mestre ou controlador do link de dados. Os percursos de sinais MDDI_DataO e MDDI_Stb são operados em um modo diferencial para maximizar imunidade a ruído. A taxa de dados para sinais nessas linhas é determinada pela taxa do relógio enviado pelo hospedeiro, e é variável através de uma faixa de aproximadamente 1 kbps até 400 Mbps ou mais.
A interface Tipo-IT contém um par de dados adicionais ou condutores ou percursos além daquele do TipoI, mencionado como MDDI_Datal+/-. A interface Tipo-III contém dois pares de dados adicionais ou percursos de sinais além daquele da Interface Tipo-II mencionada como MDDI_Data2 + /- e MDDI_Data3+/-. A interface Tipo-IV cor.rém mais quatro pares de dados ou percursos de sinais além daquele da interface Tipo-III mencionados como: MDDI_data4+/-, MDDI_Data5+/-, MDDI_Data6+/- e MDDI_Data7+/respectivamente. Em cada uma das configurações de interface acima, um hospedeiro pode enviar energia para o cliente ou display utilizando o par de fios ou sinais designado como MDDI_?wr e MDDI_Gnd.
Um tipo de transferência tornada geralmente disponível somente para a configuração Tipo-U é a conexão USB MDDI ou percurso de sinal. A conexão USB MDDI compreende um percurso secundário para comunicação entre um display de hospedeiro e um de cliente. Em certas aplicações pode ser mais vantajoso enviar certas informações em uma
32/161
2// taxa de dados relativamente lenta entre um hospedeiro e cliente. A utilização do link de transferência USB permite que dispositivos sem um Controlador de Link MDDI que têm um hospedeiro USB ou capacidade limitada de hospedeiro se comuniquem com um cliente compatível com MDDI ou display equipado com a interface do Tipo-U. Os exemplos de informações que podem ser transferidas de forma útil através de uma interface USB para um display são: mapas de bits estáticos, fluxos de áudio digitais, dados de dispositivo de apontamento, dados de teclado, e informações de status e controle. A funcional idade suportada através da interface de USB também pode ser implementada utilizando o percurso de dados seriais de alta velocidade de MDDI principal. Embora os dados (vide os pacotes abaixo) definidos acima possam ser enviados através de uma interface do tipo USB, as exigências para encadear dados na forma de pacotes back-to-back não se aplicam a essa interface de USB, nem a utilização de pacotes que suportam handoff do Tipo MDDI.
Um sumário dos sinais passados entre o hospedeiro e cliente (display) através do link MDDI é ilustrado na Tabela I, abaixo, de acordo com o tipo de interface.
Tabela I
Tipo-I Tipo-IT Tipo-III Tipo-IV
MDDI Pwr/Gnd MDDI_Pwr/Gnd MDDI_Pwr/Gnd MDDI_Pwr/Gnd
MDDI_Stb+/- MDDI_Stb+/- MDDI_Stb+/- MDDI_Stb+/-
MDDI_DataO+/- MDDI_DataO+/- MDDI_DataO+/- MDDT_DataO+/-
MDDI_Data1+/- MDDT_Datal+/- MDDI_Data 1 +/-
Tipo-U MDDI_Data2+/- MDDI_Data2+/-
MDDI_Pwr/Gnd MDDI_Data3+/- MDDI_Data3+/-
MDDI_Gtbl/- MDDI_Data4+/-
MDDI_DataOf/- MDDI_Data5+/-
MDDI_USB+/- MDDI_Data6+/-
MDDI_Data7+/-
33/161
O cabeamento geralmente utilizado para implementar a estrutura e operação acima é nominaimente da ordem de 1,5 metros em comprimento e contém três pares trançados de condutores, cada um por sua vez sendo fio AWG 30 multifilar (multi-strand). Uma cobertura de blindagem de folha é envolta ou de outro modo formada acima dos três pares trançados, como um fio de dreno adicional. Os pares trançados e condutor de dreno de blindagem terminam no conector de display com a blindagem conectada à blindagem para o display (cliente) , e há uma câmara de isolamento, cobrindo todo o cabo, como seria bem conhecido na técnica. Os fios são emparelhados como: MDDI_Gnd com MDDI_Pwr; MDDI_Stb+ com MDDI_Stb-; MDDI_DataO+ com MDDI_DataO-; MDDI_Dtal+ com MDDI_Datal-; e assim por diante. O diâmetro de cabo nominal é da ordem de 3,0 mm com uma impedância nominal de 85 ohms ± 104, e resistência DC nominalmente de 110 ohms por 304,8 metros. A taxa de propagação de sinal deve ser nominalmente 0,66c, com um retardo máximo através do cabo menor do que aproximadamente 8,0 ns.
D. Taxas e Tipos de Dados
Para obter uma interface útil para uma gama total de aplicações e experiências de usuários, a Interface de Dados Digitais Móveis (MDDI) provê suporte para uma variedade de displays e informações de display, transdutcres de áudio, teclados, dispositivos de apontamento, e muitos outros dispositivos de entrada que poderíam ser integrados em ou trabalhando em combinação com um dispositivo de display móvel, juntamente com informações de controle e combinações dos mesmos. A interface de MDD é projetada para ser capaz de acomodar uma variedade de tipos em potencial de fluxos de dados atravessando entre o hospedeiro e cliente nas direções de link direto ou reverso utilizando um número mínimo de cabos ou condutores. Tanto
34/161
Joj, fluxos isócronos como fluxos assincronos (atualizações) são suportados. Muitas combinações de tipos de dados são possíveis desde que a taxa de dados agregados seja menor ou igual à taxa máxima de link de MDDI desejada. Esses poderíam incluir, porém não são limitados aos itens listados nas Tabelas II e III abaixo.
Tabela II
Transferência de Hospedeiro para Cliente
dados de vídeo isócronos 720x480, 12bit, 30f/s ~124,5 Mbps
dados de áudio estéreo isócronos 44,1kHz, 16bit, estéreo ~1,4 Mbps
dados gráficos isócronos 800x600, 12bit, lOf/s, estéreo ~115,2 Mbps
controle assincrono mínimo «1,0 Mbps
Tabela III
Transferência de Cliente para Hospedeiro
dados de voz isócronos 8 kHz, 8bit « 1,0 Mbps
dados de vídeo isócronos 640x480, 12bit, 24f/s ~88,5 Mbps
status assíncrona, entrada de usuário, etc. mínimo « 1,0 Mbps
A interface não é fixa, porém extensível de modo que possa suportar a transferência de uma variedade de tipos de informações que inclui dados definidos pelo usuário, para flexibilidade futura de sistema. Exemplos específicos de dados a serem acomodados são: vídeo de movimento total, na forma de campos de mapas de bits total ou parcial ou vídeo comprimido; mapas de bits estáticos em baixas taxas para conservar energia e reduzir custos de implementação; PCM ou dados de áudio comprimidos em uma variedade de resoluções ou taxas; posição e seleção de
35/161 dispositivo de apontamento, e dados definíveis pelo usuário para capacidades ainda a serem definidas. Tais dados também podem ser transferidos juntamente com informações de status ou controle para detectar capacidade de dispositivo cu definir parâmetros operacionais.
A presente invenção avança a técnica para utilização em transferências de dados que incluem, porém não são limitados a, assistir a um filme (áudio e display de vídeo), usar um computador pessoal com visualização pessoal limitada (exibição gráfica, às vezes combinada com vídeo e áudio) , jogar um videogame em um PC, console ou dispositivo pessoal (display gráfico de movimento, ou áudio e video sintético), navegar na Internet, utilizar dispositivos na forma de um vídeo fone (áudio e vídeo de baixa taxa bidirecional), uma câmera para imagens digitais fixas, ou uma filmadora para capturar imagens de vídeo digitais, e para aumento de produtividade ou utilização de entretenimento com telefones celulares, telefones inteligentes, ou PDAs.
A interface de dados móveis como discutido abaixo é apresentada em termos de fornecer grandes quantidades de dados do tipo A-V através de um link de transferência ou comunicação que é geraimente configurado como um link do tipo cabo ou de ligação de fio. Entretanto, será facilmente evidente que a estrutura de sinal, protocolos, temporização ou mecanismo de transferência poderia ser ajustada para fornecer um link na forma de uma mídia óptica ou sem fio, se puder manter o nível· desejado de transferência de dados.
Os sinais de interface de MDD utilizam um conceito conhecido como o Quadro Comum (CF) para a estrutura ou protocolo de sinal básico. A idéia por trás da utilização de um Quadro Comum é fornecer um pulso de sincronização para fluxos de dados isócronos simultâneos.
36/161
Um dispositivo de display pode utilizar essa taxa de quadro comum como uma referência de tempo. Uma baixa taxa de CF aumenta a eficiência de canal pela diminuição de overhead para transmitir o cabeçalho de subquadro. Por outro lado, uma alta taxa de CF diminui a latência, e permite um buffer (armazenador) de dados elástico menor para amostras de áudio. A taxa de CF da presente interface inventiva é dinamicamente programável e pode ser definida em um de muitos valores que são apropriados para os fluxos isócronos utilizados em uma aplicação específica. Isto é, o valor CF é selecionado para melhor adeguar-se ao dispositivo de display dado e configuração de hospedeiro, como desejado.
O número de bytes geralmente exigido por quadro comum, que é ajustável ou programável, para fluxos de dados isócronos que são mais prováveis de serem utilizados com uma aplicação, como para um microdisplay montado em cabeçote é mostrado na Tabela IV.
Tabela IV
Taxa de Quadro Comum (CFR) = 1200 Hz
X Y Bit Taxa de quadro Canal Taxa (Mbps) Byte/ CFR
Filme de DVD 720 480 12 30 1 124,4 12960
Gráficos estéreos 800 600 12 10 2 115, 2 12000
Camcorder 640 480 12 24 1 88,5 9216
Áudio de CD 1 1 16 44100 2 1,4 147
Voz 1 1 8 8000 1 0,1 6,7
Contagens fracionais de bytes por quadro comum são facilmente obtidas utilizando uma estrutura de contador M/N programável, simples. Por exemplo, uma contagem de 2 62/3 bytes por CF é implementada pela transferência de 2 quadros de 27 bytes cada seguido por um quadro de 26 bytes.
37/161 ?<J'7
Uma taxa de CF menor pode ser selecionada para produzir um número inteiro de bytes por CF. Entretanto, dito em termos gerais, para implementar um contador M/N simples em hardware deve exigir menos área em um chip de circuito integrado ou módulo eletrônico utilizado para implementar parte ou toda a invenção do que a área necessária para um armazenador FIFO de amostra de áudio maior.
Uma aplicação exemplar que ilustra o impacto de diferentes taxas de transferência de dados e tipos de dados é um sistema Karaokê. Para Karaokê, um usuário do sistema canta com um programa de video de música. As letras das canções são exibidas na parte inferior de uma tela de modo que o usuário saiba as palavras a serem cantadas, e aproximadamente a temporização da canção. Essa aplicação requer um display de video com atualizações gráficas não frequentes, e mistura da voz do usuário com um fluxo de áudio estéreo.
Se for assumida uma taxa de quadros comuns de 300 Hz, então cada CF consistirá em: 92.160 bytes de conteúdo de video e 588 bytes de conteúdo de áudio (com base em 147 amostras de 16 bits, em estéreo) através do link direto para o dispositivo de display, e uma média de 29,67 (262/3) bytes de voz é enviada de volta de um microfone para a máquina de Karaokê móvel. Pacotes assincronos são enviados entre o hospedeiro e o display. Isso inclui no máximo 768 bytes de dados qráficos (altura de quarto de tela), e menos de aproximadamente 200 bytes (vários) para diversos comandos de status e controle.
A Tabela V mostra como os dados são alocados em um Quadro Comum para o exemplo de Karaokê. A taxa total sendo utilizada é selecionada para ser aproximadamente 225 Mbps. Uma taxa levemente mais alta de 226 Mbps permite que aproximadamente outros 400 bytes de dados por subquadro
38/161 sejam transferidos o que permite a utilização de mensagens de status e controle ocasionais.
Tabela V
Taxa de elemento Bytes/CF
Vídeo de música a 640 x 480 pixels e 30 fps 92160
Texto de letra a 640 x 120 pixels e 1 fps 768
Áudio de CD a 44.100 sps, estéreo, 16 bits 588
Voz a 8.000 sps, mono, 8 bits 26, 67
Cabeçalho de Subquadro 19
Overhead de Link Reverso 26,67+2*9+20
Total de bytes/CF 93626.33
Taxa total (Mbps) 224,7032
III. Arquitetura do Sistema de Interface de Dados Digitais de Alta Taxa
E. Camada de Link
Dados transferidos utilizando os sinais de dados seriais de alta velocidade de interface de MDD consistem em um fluxo de pacotes multiplexados em tempo que são ligados um após o outro. Mesmo guando um dispositivo de transmissão não tem dados para enviar, um controlador de link de MDDI envia geralmente de forma automática pacotes preenchedores, desse modo mantendo um fluxo de pacotes. A utilização de uma estrutura de pacote simples assegura temporizaçào isócrona segura para sinais de vídeo e áudio ou fluxos de dados.
Grupos de pacotes esrão contidos nas estruturas ou elementos de sinais mencionados como subquadros, e grupos de subquadros estão contidos em estruturas ou elementos de sinais mencionados como um quadro de mídia. Um
39/161 subquadro contém um ou mais pacotes, dependendo de seu tamanho respectivo e utilizações de transferência de dados e um quadro de mídia contém mais um subquadro. O maior subquadro fornecido pelo protocolo empregado pela presente invenção é da ordem de 232-1 ou 4.294.967.295 bytes, e o maior tamanho de quadro de mídia se torna então da ordem de 216-1 ou 65.535 subquadros.
Um pacote de cabeçalho especial contém um identificador exclusivo que aparece no início de cada subquadro, como discutido abaixo. Esse identificador também é utilizado para adquirir a temporização de quadros no dispositivo cliente quando a comunicação entre o hospedeiro e cliente é iniciada. A aquisição de temporização de link é discutida em mais detalhes abaixo.
Tipicamente, uma tela de display é atualizada uma vez por quadro de mídia quando vídeo de movimento total está sendo exibido. A taxa de quadro de display é igual à taxa de quadro de mídia. 0 protocolo de link suporta vídeo de movimento total através de um display inteiro, ou apenas uma pequena região de conteúdo de vídeo de movimento total circundada por uma imagem estática, dependendo da aplicação desejada. En algumas aplicações móveis de baixa potência, como visualizar web pages ou emaii, a tela de display pode necessitar ser atualizada semente ocasionalmente. Nessas situações, é vantajoso transmitir um único subquadro e a seguir desligar ou inativar o link para minimizar o consumo de energia. A interface também suporta efeitos como visão de estéreo, e lida com primitivos gráficos.
Subquadros existem para permitir a transmissão de pacotes de alta prioridade em uma base periódica. Isto permite que fluxos isócronos simultâneos coexistam com uma quantidade mínima de armazenagem de dados. Esta é uma vantagem que a presente invenção provê para o processo de
40/161 display, permitindo que múltiplos fluxos de dados (comunicação em alta velocidade de vídeo, voz, controle, status, dados de dispositivo de apontamento, etc.) compartilhem essencialmente um canal comum. Transfere informações utilizando relativamente poucos sinais. Também permite que ações específicas de tecnologia de display existam, como pulsos de sincronização horizontal e intervalos de bloqueio para um monitor CRT.
F. Controlador de Link
O controlador de link MDDI mostrado nas figuras 4 e 5 é fabricado ou montado para ser uma implementação totalmente digital com a exceção dos receptores de linha de diferencial que são utilizados para receber dados MDDI e sinais de estrobo. Entretanto, mesmo os drivers e receptores de linha de diferencial podem ser implementados nos mesmos circuitos integrados digitais com o controlador de link. Não é necessária nenhuma função analógica ou elos de sincronismo de fase (PLLs) para implementar o hardware para o controlador de link. Os controladores de link de cliente e hospedeiro contêm funções muito similares, com a exceção da interface de display que contém uma máquina de estado para sincronização de link. Portanto, a presente invenção permire a vantagem prática de ser capaz de criar um único circuito ou desenho de controlador que possa ser configurado como um hospedeiro ou cliente, que possa reduzir custos de fabricação para os controladores de link, como um todo.
IV. Protocolo de Link de Interface
A. Estrutura de Quadro
A estrutura de quadro ou protocolo de sinal utilizada para implementar a comunicação de link direto para transferência de pacotes é ilustrada na figura 6. Como mostrado na figura 6, informações ou dados digitais são
41/161 agrupados em elementos conhecidos como pacotes. Múltiplos pacotes são por sua vez agrupados juntos para formar o que é mencionado como um subquadro, e múltiplos subquadros são por sua vez agrupados juntos para formar um quadre de midia. Para controlar a formação de quadros e transferência de subquadros, cada subquadro começa com um pacote especialmenze predefinido mencionado como um Pacote de Cabeçalho de Subquadro (SHP).
O dispositivo hospedeiro seleciona a taxa de dados a ser utilizada para uma dada transferência. A taxa pode ser alterada dinamicamente pelo dispositivo hospedeiro com base tanto na capacidade de transferência máxima do hospedeiro, ou os dados sendo recuperados de uma fonte pelo hospedeiro, como a capacidade máxima do display ou outro dispositivo para o qual os dados estão sendo transferidos.
Um dispositivo cliente destinatário projetado para, ou capaz de trabalhar com a MDDI ou protocolo de sinal inventivo é capaz de ser consultado pelo hospedeiro a fim de determinar a taxa de transferência de dados máxima ou máxima atual que pode utilizar, ou uma taxa mínima mais lenta default pode ser utilizada, bem como tipos de dados utilizáveis e recursos suportados. Essas informações poderíam ser transferidas utilizando um Pacote de Capacidade dc Display (DCP), como discutido adicionalmente abaixo. 0 dispositivo de display cliente é capaz de transferir dados ou comunicar-se com outros dispositivos utilizando a interface e uma taxa de dados niinima préselecionada ou em uma faixa de taxas de dados mínima, e o hospedeiro executará uma consulta utilizando uma taxa de dados compreendida nessa faixa para determinar as capacidades totais dos dispositivos clientes.
Outras informações de status definindo a natureza de mapa e de bits e capacidades de taxa de quadro de vídeo
42/161 do display podem ser transferidas em um pacote de status para o hospedeiro de modo que o hospedeiro possa configurar a interface como sendo tàc eficiente ou ótima como prática, ou desejada em quaisquer limitações de sistema.
hospedeiro envia pacotes preenchedores quando não há (mais) pacotes de dados a serem transferidos no presente subquadro, ou quando o hospedeiro não pode transferir em uma taxa suficiente para acompanhar o ritmo da taxa de transmissão de dados escolhida para o link direto. Uma vez que cada subquadro inicia com um pacote de cabeçalho de subquadro, o fim do subquadro anterior contém um pacote (mais provavelmente um pacote preenchedor) que preenche exatamente o subquadro anterior. No caso de falta de espaço para pacotes contendo dados por si, um pacote preenchedor será mais provavelmente o último pacote em um subquadro, ou no término de um subquadro anterior seguinte e antes de um pacote de cabeçalho de subquadro. É a tarefa das operações de controle em um dispositivo hospedeiro assegurar que haja espaço suficiente restando em um subquadro para cada pacote a ser transmitido naquele subquadro. Ao mesmo tempo, após um dispositivo hospedeiro iniciar o envio de um pacote de dados, o hospedeiro deve ser capaz de concluir com sucesso um pacote daquele tamanho em um quadro sem incorrer em uma condição de prolongamento de dados.
Em um aspecto das modalidades, a transmissão de subquadro tem dois modos. Um modo é um modo de subquadro periódico para transmitir fluxos de áudio e vídeo ao vivo. Nesse modo, o comprimento de Subquadro é definido como sendo não zero. O segundo modo é um modo assíncrono ou nào periódico no qual quadros são utilizados para fornecer dados de mapas de bits para um dispositivo de display somente quando novas informações são disponíveis. Esse modo
43/161 é definido pela definição do comprimento de subquadro em zero no Pacote de Cabeçalho de Subquadro. Ao utilizar o modo periódico, o recebimento de pacote de subquadro pode iniciar quando o display sincronizou com a estrutura de quadro de link direto. Isto corresponde aos estados em sincronização definidos de acordo com o diagrama de estados discutido abaixo com relação à figura 49 ou figura 63. No modo de subquadro não periódico assincrono, o recebimento inicia após recebimento do primeiro pacote de
Cabeçalho de Subquadro.
B. Estrutura Geral de Pacotes formato ou estrutura de pacotes utilizados para formular o protocolo de sinalização implementado pela presente invenção é apresentado abaixo, tendo em mente que a interface é extensível e estruturas de pacotes adicionais podem ser acrescentadas conforme desejado. Os pacotes são rotulados como, ou divididos em, diferentes tipos de pacotes em termos de sua função na interface, isto é, comandos ou dados que transferem. Portanto, cada tipo de pacote indica uma estrutura de pacote predefinida para um dado pacote que é utilizado na manipulação dos pacotes e dados sendo transferidos. Como será facilmente evidente, os pacotes podem ter comprimentos pré-selecionados ou ter comprimentos variáveis ou dinamicamente alteráveis dependendo de suas respectivas funções. Os pacotes também poderiam ter nomes diferentes, embora a mesma função seja ainda rvalizadd, como pode ocorrer quando protocolos são mudados durante aceite em um padrão. Os bytes ou valores de bytes utilizados nos diversos pacotes são configurados como números inteiros sem sinal de múltiplos bits (3 ou 16 bits) . Um sumário dos pacotes sendo empregados juntamente com suas designações de tipo, listadas em ordem de tipo, é mostrado na Tabela VI. A direção na qual a transferência
44/161 de um pacote é considerada válida também é mencionada, juntamente com o fato de se eles são ou nào utilizados para uma interface do Tipo U.
Tabela VI
Nome do Pacote Tipo de Pacote Válido na Direção
Direta Reversa Tipc-U
Pacote de Cabeçalho de Subquadro 255 x X
Pacote Preenchedor 0 x X
Pacote de Fluxo de Vídeo 1 X X X
Pacote de Fluxo de Áudio 2 X X X
Pacotes de Fluxo P.oservado 3-55
Pacotes de Fluxo Definido pelo Usuário 56 - 63 X X X
Pacote de Mapa de Cores 64 X X X
Pacote de Encapsulamento de Link Reverso 65 X
Pacote de Capacidade de Display 66 X X
Pacote de Dados de Teclado 67 X X X
Nome do Pacote Tipo de Pacote Válido na Direção
Direta Reversa Tipo-U
Pacote de Dados de Dispositivo de Apontamento 68 X X X
45/161
Pacote de Desligamento de Link 69 X
Pacote de Status e Solicitação de Display 70 X X
Pacote de Transferência de Bloco de Birs 71 X X
Pacote de Preenchimento de área de Mapa de bits 72 X X
Pacote de Preenchimento de Padrão de Mapa de bits 73 X X
Pacote de Canal de Dados de Link de Comunicação 74 X X X
Pacote de Solicitação de Handoff do Tipo de Interface 75 X
Pacote de Confirmação do Tipo de Interface 76 X
Pacote de Handoff do 1 Tipo de Execução 77 X
Pacote de Habilitar canal de Áudio Direto 78 X X
Pacote de Taxa de Amostra de Áudio Reverso 79 X X
46/161
Pacote de Overhead de Proteção de Conteúdo Digital 80 X X X
Pacote de Habilitar cor Transparente 81 X X
Pacote de Medição de Retardo de Ida e Volta 82 X
Pacote de Calibragem de Distorção de Link Direto 83 X
Os pacotes têm uma estrutura básica comum ou conjunto global de campos mínimos compreendendo um campo de Comprimento de Pacote, um campo do Tipo de Pacote, campo(s) de Bytes de dados, e um campo CRC que é ilustrado na figura 7. Como mostrado na figura 7, o campo de Comprimento de Pacote contém informações, na forma de um valor de múltiplos bits ou bytes, que especifica o número total de bits no pacote, ou seu comprimento entre o campo de comprimento de pacote e o campo CRC. Em uma modalidade, o campo de comprimento de pacote contém um número inteiro sem sinal com largura de 2 bytes ou 16 bits, que especifica o comprimento do pacote. O campo do Tipo de Pacote é outro campo de múltiplos bits que designa o tipo de informações que estão contidas no pacote. Em uma modalidade exemplar, esse é um valor com largura de 8 bits ou 1 byte, na forma de um número inteiro sem sinal de 8 bits, e especifica tais tipos de dados como capacidades de dispiay, handoff, fluxos de áudio ou vídeo, status e assim por diante.
Um terceiro campo é o campo de Bytes de Dados, que contém os bits ou dados sendo transferidos ou enviados entre os dispositivos hospedeiros e cliente como parte
47/161 daquele pacote. O formato dos dados é definido especificamente para cada tipo de pacote de acordo com o tipo específico de dados sendo transferidos, e pode ser separado em uma série de campos adicionais, cada um com suas próprias exigências de formato. Isto é, cada tipo de pacote terá um formato definido para essa porção ou campo. O último campo é o campo CRC que contém os resultados de um verificação de redundância cíclica de 16 bits calculado através dos campos de Bytes de Dados, Tipo de Pacote e Comprimento de Pacote, que é utilizado para confirmar a integridade das informações no pacote. Em outras palavras, calculado sobre o pacote inteiro exceto pelo próprio campo CRC. 0 cliente mantém geralmente uma contagem total dos erros de CRC detectados, e reporta essa contagem de volta para o hospedeiro no Pacote de Status e Solicitação de Display (vide adicionalmente abaixo).
Durante transferência dos pacotes, os campos são transmitidos iniciando com o Bit Menos Significativo (LSB) primeiro e terminando com o Bit Mais Significativo (MSB) transmitido por último. Os parâmetros que têm mais de um byte de comprimento são transmitidos utilizando o byte menos significativo primeiro, que resulta no mesmo padrão de transmissão de bits sendo utilizado para um parâmetro maior do que 8 bits de comprimento, como utilizado para um parâmetro mais curto onde o LSB é transmitido primeiramente. Os dados no percurso de sinal MDDI_DataO são alinhados com bit '0' de bytes transmitidos na interface em qualquer um dos modos, Tipo-I, Tipo-II, Tipo-III ou TipoIV.
Ao manipular dados para displays, os dados para arranjos de pixels são transmitidos por linhas primeiramente, a seguir colunas, como é tradicionalmente feito na técnica de eletrônica. Em outras palavras, todos
48/161 os pixels que aparecem na mesma linha em um mapa de bits são transmitidos em ordem com o pixel mais à esquerda transmitido primeiramente e o pixel mais à direita transmitido por último. Após o pixel mais à direita de uma linha ser transmitido então o pixel seguinte na seqüência é o pixel mais à esquerda da linha seguinte. As linhas de pixels são geralmente transmitidas em ordem de parte superior para parte inferior para a maioria dos displays, embora outras configurações possam ser acomodadas conforme necessário. Além disso, ao manipular mapas de bits, a abordagem convenciona], que é seguida aqui, é definir um ponto de referência pela rotulação do canto superior esquerdo de um mapa de bits como local ou offset 0,0. As coordenadas X e Y utilizadas para definir ou determinar uma posição no mapa de bits aumentam em valor à medida que se aproximam da direita e parte inferior do mapa de bits, respectivamente. A primeira linha e primeira coluna iniciam com um valor de índice de zero.
C. Definições de Pacotes
1. Pacote de Cabeçalho de Subquadro
O pacote de cabeçalho de subquadro é o primeiro pacote de cada subquadro, e tem uma estrutura básica como ilustrado na figura 8. Como pode ser visto na figura 8, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacore, Tipo de Pacote, Palavra Exclusiva, Comprimento de Subquadro, Versão de Protocolo, Contagem de Subquadro, e Contagem de Quadro de Mídia, geralmente nessa ordem. Esse tipo de pacote é geralmente identificado como um pacote Tipo 255 (Oxff hexadecimal) e utiliza um comprimento fixo pré-selecionado de 17 bytes.
Embora o campo do Tipo de Pacote utilize um valor de 1 byte, c campo de Palavra Exclusiva utiliza um valor de 3 bytes. A combinação de 4 bytes desses dois campos forma
49/161 juntos uma palavra exclusiva de 32 bits com boa autocorrelacão. Em uma modalidade exemplar, a palavra exclusiva real é 0x005a3bff onde os 8 bits inferiores são transmitidos primeiro como o Tipo de Pacote, e os 24 bits mais significativos são transmitidos posteriormente.
O campo de Comprimento de Subquadro contém quatro bytes de informações que especificam o número de bytes por subquadro. 0 comprimento desse campo pode ser definido igual a zero para indicar que somente um subquadro será transmitido pelo hospedeiro antes do link ser desligado em um estado ocioso (idle). O valor nesse campo pode ser dinamicamente alterado em movimento ao fazer a transição de um subquadro para o seguinte. Essa capacidade é útil para fazer ajustes de temporização secundários nos pulsos de sincronização a fim de acomodar fluxos de dados isócronos. Se o CRC do pacote de Cabeçalho de Subquadro não for válido então o controlador de link deve utilizar o Comprimento dc Subcuadro do pacote de Cabeçalho de Subquadro conhecido bom anterior para estimar o comprimento do subquadro atual.
O campo de Versão de Protocolo contém dois bytes que especificam a versão de protocolo utilizada pelo hospedeiro. O campo de Versão de Protocolo é definido para '0' a fim de especificar a primeira versão ou versão atual do protocolo como sendo utilizado. Esse valor mudará com o passar do tempo à medida que novas versões são criadas. O campo de Contagem de Subquadro contém dois bytes que especificam um número de seqüôncia que indica o número de subquadros que foram transmitidos após o inicio do quadro de mídia. O primeiro subquadro do quadro de mídia tem uma Contagem de Subquadro de zero. O último subquadro do quadro de mídia tem um valor de n-1, onde n é o número de subquadros por quadro de mídia. Observe que se o
50/161
Comprimento de Subquadro for definido igual a zero (indicando um subquadro não periódico) então a contagem de Subquadro deve ser também definida igual a zero.
O campo de Contagem de quadro de mídia contém 3 bytes que especificam um número de sequência que indica o número de quadros de mídia que foram transmitidos desde o início do presente item de mídia ou dados sendo transferidos. 0 primeiro quadro de mídia de um item de mídia tem uma Contagem de Quadro de Mídia de zero. A Contagem de Quadro de Mídia incrementa pouco antes do primeiro subquadro de cada quadro de mídia e retorna para zero após a Contagem de Quadro de Mídia máxima (por exemplo, número de quadro de mídia 224-1 = 16.777.215) ser utilizada. 0 valor de Contagem de Quadro de Mídia pede ser redefinido geralmente a qualquer momento pelo Hospedeiro para adequar-se às necessidades de uma aplicação final.
2. Pacote Preenchedor
Um pacote preenchedor é um pacote que é transferido para, ou de um dispositivo cliente quando nenhuma outra informação está disponível para ser enviada no link direto ou reverso. Recomenda-se que pacotes preenchedores renham um comprimento mínimo para permitir flexibilidade máxima no envio de outros pacotes quando necessário. No final de urr. subquadro ou um pacote de encapsulamento de link reverso (vide abaixo), um controlador de link define o tamanho do pacote preenchedor para preencher o espaço restante a fim de manter integridade de pacote.
O formato e conteúdo de um Pacote Preenchedor são mostrados na figura 9. Como mostrado na figura 9, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Bytes de Preenchedor e CRC. Esse tipo de pacote é geralmente identificado como um Tipo 0,
51/161
Figure BRPI0410885B1_D0005
que é indicado no campo do tipo de um byte. Os bits ou bytes no campo de Bytes de Preenchedor compreendem um número variável de valores de bit todos zero para permitir que o pacote preenchedor seja do comprimento desejado. O menor pacote preenchedor nâo contém bytes nesse campo. Isto é, o pacote consiste somente no comprimento de pacote, tipo de pacote e CRC e utiliza um comprimento fixo préselecionado de três bytes.
3. Pacote de Fluxo de Video
Pacotes de Fluxo de Vídeo contêm dados de vídeo para atualizar regiões tipicamente retangulares de um dispositivo de display. O tamanho dessa região pode ser tão pequeno quanto um único pixel ou tão grande quanto o display inteiro. Pode haver um número quase ilimitado de fluxos exibidos simultaneamente, limitado por recursos de sistema, porque todo contexto necessário para exibir um fluxo está contido no Pacote de Fluxo de vídeo. 0 formato do pacote de fluxo de vídeo (Descritor de Formato de Dados de Vídeo) é mostrado na figura 10. Como visto na figura 10, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote (dois bytes), Tipo de Pacote, Descritor de Dados de Vídeo, Atributes de Display, Borda Esquerda X, Borda Superior Y, Borda Direita X, Borda Inferior Y, Inicio X e Y, Contagem de Pixels, CRC de Parâmetro, Dados de Pixel e CRC. Esse tipo de pacote é qeralmente identificado como um Tipo 1, que é indicado no campo do tipo de 1 byte.
conceito de quadro comum discutido acima é um modo eficaz para minimizar o tamanho de buffer de áudio e diminuir latência. Entretanto, para dados de vídeo pode ser necessário espalhar os pixels de um quadro de vídeo através de múltiplos Pacotes de Fluxo de vídeo em um quadre de mídia. Também é muito provável que os pixels em um único
52/161
3Π
Pacote de Fluxo de vídeo não correspondam exatamente com uma janela retangular perfeita no display. Para a taxa de quadro de vídeo exemplar de 30 quadros por segundo, há 300 subquadros por segundos, que resulta em 10 subquadros por quadro de mídia. Se houver 480 linhas de pixels em cada quadro, cada Pacote de Fluxo de Vídeo em cada subquadro conterá 48 linhas de pixels. Em outras situações, o Pacote de Fluxo de Vídeo poderia não conter um número inteiro de linhas de pixels. Isto é verdadeiro para outros tamanhos de quadro de vídeo onde o número de subquadros por quadro de mídia não divide uniformemente no número de linhas (também conhecidas como linhas de vídeo) por quadro de vídeo. Cada
Pacote de Fluxo de Video deve conter geralmente um numero \
inteiro de pixels, embora poderia não conter um número
inteiro de linhas de pixels. Isto é importante se pixels
tiverem mais de um byte cada, ou se estiverem em um formato empacotado como mostrado na figura 12.
O formato e conteúdo empregado para realizar a operação de um campo exemplar de Descritor de Dados de Vídeo, como mencionado acima, são mostrados nas figuras lla-lld. Nas figuras lla-lld, o campo de Descritor de Formato de Dados de Vídeo contém dois bytes na forma de um número inteiro sem sinal de 16 bits que especifica o formato de cada pixel nos Dados de Pixel no presente fluxo no presente pacote. Ê possível que diferentes pacotes de Fluxo de Vídeo possam utilizar diferentes formatos de dados de pixel, isto é, utilizar um valor diferente no Descritor de Formato de Dados de Vídeo, e similarmente, um fluxo (região do display) pode alterar seu formato de dados em movimento. 0 Descritor de Formato de Dados de Vídeo define o formato de pixel para o presente pacote somente o que não quer dizer que um formato constante continuará a ser
53/161 utilizado pela vida inteira de um. fluxo de video específico.
As figuras 11a até lld ilustram como o Descritor de Formato de dados de video é codificado. Como utilizado nessas figuras, e nessa modalidade, quando bits [15:13] são iguais a '000', como mostrado na figura 11a, então os dados de video consistem em um arranjo de pixels de monocromo onde o número de bits por pixel é definido por bits 3 até 0 da palavra de Descritor de Formato de Dados de Vídeo. Os bits 11 até 4 são definidos para zero nessa situação. Quando bits [15:13] são em vez disso iguais a '001', como mostrado na figura 11b, então os dados de vídeo consistem em um arranjo de pixels de cores que cada um especifica uma cor através de um mapa de cores. Nessa situação, bits 5 até 0 da palavra de Descritor de Formato de Dados de Vídeo definem o número de bits por pixel, e bits 11 até 6 são definidos igual a zero. Quando os bits [15:13] são em vez disso iguais a '010', como mostrado na figura 11c, então os dados de vídeo consistem em um arranjo de pixels de cores onde o número de bits por pixel de vermelho é definido por bits 11 até 8, o número de bits por pixel de verde é definido por bits 7 até 4, e o número de bits por pixel de azul é definido por bits 3 até 0. Nessa situação, o número total de bits em cada pixel é a soma do número de bits utilizados para vermelho, verde e azul.
Entretanto, quando bits [15:13] são em vez disso iguais a '011', como mostrado na figura lld, então os dados de vídeo consistem em um arranjo de dados de vídeo em formato 4:2:2 com informações de luminância e crominância, onde o número de bits por pixel de luminância (Y) é definido por bits 11 até 8, o número de bits do componente Cr é definido por bits 7 até 4, e o número de bits do componente Cb é definido por bits 3 até 0. O número total
54/161 de bits em cada pixel é a soma do número de bits utilizados para vermelho, verde e azul . Os componentes Cr e Cb são enviados em metade da taxa como Y. Além disso, as amostras de vídeo na porção de Dados de pixel desse pacote são organizadas como a seguir: Yn, Crn, Cbn, Yn+1, Yn+2, Crn+2, Cbn+2, Yn+3, ... Onde Crn e Cbn são associados a Yn e Yn+1, e Crn + 2 e Cbn+2 são associados a Yn+2 e Yn + 3, e assim por diante. Se houver um número ímpar de pixels em uma linha (Borda Direita X - 3orda Esquerda X + 1) no presente fluxo, então o valor Cb correspondendo ao último pixel em cada linha será seguido pelo valor Y do primeiro pixel da linha seguinte.
Para todos os quatro formatos mostrados nas figuras, bit 12, que é designado como P, especifica se as amostras de Dados de Pixel são ou não empacotadas, ou dados de pixel alinhados por byte. Um valor de '0' nesse campo indica que cada pixel e cada cor em cada pixel no campo de Dados de Pixel é alinhado por bytes com uma fronteira de byte de interface de MDD. Um valor de '1' indica que cada pixel e cada cor em cada pixel nos Dados de Pixel é empacotado contra a cor ou pixel anterior em um pixel não deixando bits não usados.
O primeiro pixel no primeiro pacote de fluxo de video de um quadro de mídia para uma janela de display específica entrará no canto esquerdo superior da janela de fluxo definida por uma Borda Esquerda X e uma Borda Superior Y, e o próximo pixel recebido é colocado no próximo local de pixel na mesma linha, e assim por diante. Nesse primeiro pacote de um quadro de mídia, o valor de início X será normalmente igual à Borda Esquerda X, e o valor de início Y será normalmente igual à Borda Superior Y. Em pacotes subseqüentes correspondendo à mesrr.a janela de tela, os valores de início X e Y serão normalmente
55/161 definidos para o local de pixel r.a janela de tela que seguiría normalmente após o último pixel enviado nc Pacote de fluxo de vídeo que foi transmitido no subquadro anterior.
4. Pacote de Fluxo de Áudio
Os pacotes de fluxo de áudio carregam dados de áudio a serem reproduzidos através do sistema de áudio do display, ou para um dispositivo de apresentação de áudio independente. Fluxos de dados de áudio diferentes podem ser alocados para canais de áudio separados em um sistema de som, por exemplo: esquerda-fronta1, direita-frontal, centro, esquerda-traseira, e direita-traseira, dependendo do tipo de sistema de áudio sendo utilizado. Um complemento total de canais de áudio é fornecido para receptores de telefonia que contêm processamento de sinal acústico espacial aperfeiçoado. O formato de Pacotes de Fluxo de Áudio é ilustrado na figura 13. Como mostrado na figura 13, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, ID de Canal de Áudio, Contagem de Amostra de Áudio, Bits por Amostra e Empacotamento, Taxa de Amostra de Áudio, CRC de Parâmetro, Dados de Áudio Digitais e CRC de Dados de Áudio. Em uma modalidade, esse tipo de pacote é geralmente identificado como um pacote tipo 2.
O campo Bits por Amostra e Empacotamento contém 1 byte na forma de um número inteiro sem sinal de 8 bis que especifica o formato de empacotamento de dados de áudio. 0 formato geralmente empregado é para Bits 4 até 0 para definir o número de bits por amostra de áudio de PCM. 0 bit 5 então especifica se as amostras de Dados de Áudio Digitais são ou não empacotadas. A diferença entre amostras de áudio empacotadas e alinhadas por bytes é ilustrada na figura 14. Um valor de '0' indica que cada amostra de áudio
56/161
PCM no campo de Dados de Áudio Digitais é alinhada por bytes com um limiLe de byte de interface de MDDI, e um valor de '1' indica que cada amostra de áudio PCM sucessiva é empacotada contra a amostra de áudio anterior. Esse bit é eficaz somente quando o valor definido em bits 4 até 0 (o número de bits por amostra de áudio PCM) nào è um múltiplo de oito. Bits 7 até 6 sâo reservados para utilização futura e sâo geralmente definidos em um valor de zero.
5. Pacotes de Fluxo Reservados
Em uma modalidade, pacote tipos 3 a 55 são reservados para pacotes de fluxo a serem definidos para utilização em versões futuras ou variações dos protocolos de pacote, como desejado para diversas aplicações encontradas. Novamente, isto é parte de tornar a interface de MDD mais flexível e útil à face de tecnologia sempre mutável e projetos de sistema como comparado com outras técnicas.
6. Pacotes de Fluxo Definido pelo Usuário
Oito tipos de fluxos de dados, conhecidos como Tipos 56 a 63, são reservados para utilização em aplicações de propriedade que podem ser definidas por fabricantes de equipamentos para utilização com um link de MDDI. Esses são conhecidos como Pacotes de Fluxo definido pelo usuário. Os pacotes de fluxo de vídeo contêm dados de vídeo para atualizar (ou não) uma região retangular do display. A definição dos parâmetros de fluxo e dados para esses tipos de pacotes é deixada para os fabricantes de equipamentos específicos que buscam sua utilização. O formato dos pacotes de fluxo definido pelo usuário é ilustrado na figura 15. Como mostrado na figura 15, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote (2 bytes) , Tipo de Pacote, Número de ID de Fluxo, Parâmetros
57/161 >2Λ
de Fluxo, CRC de Parâmetro, Dados de Fluxo e CRC de Dados
de Fluxo. 7 . Pacotes de Mapa de Cores
Os pacotes de mapa de cores especifi cam o
conteúdo de uma tabela de consulta de mapa de cores
utilizada para apresentar cores para um display. Algumas aplicações podem exigir um mapa de cores que seja maior do que a quantidade de dados que pode ser transmitida em um único pacote. Nesses casos, múltiplos pacotes de Mapa de Cores podem ser transferidos, cada um com um subconjunto diferente do mapa de cores pela utilização dos campos de comprimento e offset descritos abaixo. O formato do pacote de Mapa de Cores é ilustrado na figura 16. Como mostrado na figura 16, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Tamanho de Dados de Mapa de Cores, Offset de Mapa de Cores, CRC de Parâmetro, Dados de Mapa de Cores, e CRC de dados. Esse tipo de pacote é geralmente identificado como um pacote do Tipo 64.
8. Pacotes de Encapsulamento de Link Reverso Em uma modalidade exemplar, dados são transferidos na direção reversa utilizando um Pacote de Encapsulamento de Link Reverso. Um pacote de link direto é enviado e a operação de link de MDDI (direção de transferência) é mudada ou retornada dentre esse pacote de modo que os pacotes possam ser enviados na direção reversa. 0 formato do pacote de Encapsulamento de Link Reverso é ilustrado na figura 17. Como mostrado na figura 17, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Flags de Link Reverso, Comprimento para Reversão de Sentido (Turn-Around Length), CRC de Parâmetro, Reversão de Sentido 1, pacotes de Dados
58/161 ιι5
Reversos, e Reversão de Sentido 2. Esse tipo de pacote é geralmente identificado como pacote do Tipo 65.
O controlador de link de MDDI se comporta em um modo especial enquanto envia um Pacote de Encapsulamento de Link Reverso. A interface de MDD tem um sinal de estrobo que é sempre acionado pelo hospedeiro. O hospedeiro se comporta como se estivesse transmitindo um zero para cada bit das porções de Pacotes de Dados Reversos e Reversão de Sentido do pacote de Encapsulamento de Link Reverso. O hospedeiro alterna um sinal MDDI_Strobe em cada limite de bit durante os dois tempos de reversão de sentido (turnaround time) e durante o tempo alocado para pacotes de dados reversos. (Esse é o mesmo comportamento como se estivesse transmitindo dados todos zero). 0 hospedeiro desabilita seus drivers de linha de sinal de dados de MDDI durante o período de tempo especificado por Reversão de Sentido 1, e o cliente reabilita seus drivers de linha durante o campo de Reabilitar Driver após o período de tempo especificado pelo campo Reversão de Sentido 2. O display lê o parâmetro de Comprimento de Reversão de Sentido e aciona os sinais de dados em direção ao hospedeiro imediatamente após o úlrimo bit no campo de
Reversão de Sentido 1. O display utiliza os parâmetros de
Comprimento de Pacote e Comprimento de Reversão de Sentido para saber a extensão de tempo que tem disponível para enviar pacotes para o hospedeiro. 0 cliente pode enviar pacotes preenchedores ou acionar as linhas de dados para um estado zero quando não tem dados para enviar para o hospedeiro. Se as linhas de dados forem acionadas para zero, o hospedeiro interpreta isto como um pacote com um comprimento zero (não um comprimento válido) e o hospedeiro não aceita mais pacotes do cliente pela duração do Pacote de Encapsulamento de Link Reverso atual.
59/161 display de cliente aciona as linhas de dados de MDDI para o nível zero por pelo menos um período de relógio de link reverso antes do início do campo de Reversão de Sentido 2. Isto mantém as linhas de dados em um estado determinista durante o período de tempo de Reversão de Sentido 2. Se o cliente não tiver mais pacotes para enviar, pode até mesmo desabilitar as linhas de dados após acionar as mesmas para um nível zero porque os resistores de polarização de hibernação (discutidos em outra parte) mantêm as linhas de dados em um nível zero para o restante do campo de Pacotes de Dados Reversos.
O campo de Solicitação de Link Reverso do Pacote de Status e Solicitação de Display pode ser utilizado para informar ao hospedeiro sobre o número de bytes que o display necessita no Pacote de Encapsulamento de Link Reverso para enviar dados de volta para o hospedeiro. 0 hospedeiro tenta conceder a solicitação pela alocação pelo menos daquele número de bytes no Pacote de Encapsulamento de Link Reverso. O hospedeiro pode enviar mais de um Pacote
2C de Encapsulamento de Link Reverso em um subquadro. O display pode enviar um pacote de Status e Solicitação de Display quase a qualquer momento, e o hospedeiro interpretará o parâmetro de Solicitação de Link Reverso como o número total de bytes solicitados em um subquadro.
9. Pacotes de Capacidade de Display
Um hospedeiro necessita conhecer a capacidade do display (cliente) com o qual está se comunicando a fim de configurar o link de hospedeiro-para-display em um modo geralmente ótimo ou desejado. Recomenda-se que um display envie um Pacote de Capacidade de display para o hospedeiro após adquirir sincronização de link direto. A transmissão de tal pacote é considerada necessária quando solicitada pelo hospedeiro utilizando os Flags de Link Reverso no
60/161
Figure BRPI0410885B1_D0006
Pacote de Encapsulamento de Link Reverso. O formato do pacote de Capacidade de Display é ilustrado na figura 18. Como mostrado na figura 18, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Versão de Protocolo, Versão Mínima de Protocolo, Largura de Mapa de 3its, Altura de Mapa de Bits, Capacidade de Monocromo, Capacidade de Mapa de Cores, Capacidade de RGB, Capacidade Y Cr Cb, Capacidade de Recurso de Display, Capacidade de Taxa de Dados, Capacidade de Taxa de Quadro, Profundidade de Buffer de Áudio, Capacidade de Fluxo de Áudio, Capacidade de Taxa de Áudio, Taxa de Subquadro Mínima, e CRC. Em uma modalidade exemplar, esse tipo de pacote é geraimente identificado como um pacote do Tipo 66.
10. Pacotes de Dados de Teclado
Um pacote de dados de teclado é utilizado para enviar dados de teclado do dispositivo cliente para o hospedeiro. Um teclado sem fio (cu com fio) pode ser utilizado cm combinação com diversos displays ou dispositivos de áudio, incluindo, porém não limitados a um dispositivo de apresentação de áudio/display de vídeo montado em cabeçote. O Pacote de Dados de Teclado transmite dados de teclado recebidos de um de vários dispositivos semelhantes a teclado, conhecidos, para o hospedeiro. Esse pacote pode ser utilizado também no link direto para enviar dados para o teclado. O formato de um Pacote de Dados de Teclado é mostrado na figura 19, e contém um número variável de bytes de informações de ou para um teclado. Como mostrado na figura 19, esse tipo de pacoLe é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Dados de Teclado e CRC. Aqui, esse tipo de pacote é geralmente identificado como um pacote do Tipo 67.
11. Pacotes de Dados de Dispositivo de
Apontamento
61/161
Figure BRPI0410885B1_D0007
Um pacote de dados de dispositivo de apontamento é utilizado para enviar informações de posição de um mouse sem fio ou outro dispositivo de apontamento do display para o hospedeiro. Os dados também podem ser enviados para o dispositivo de apontamento no link direto utilizando esse pacote. Um formato exemplar de um pacote de Dados de Dispositivo de Apontamento é mostrado na figura 20, e contém um número variável de bytes de informações de ou para um dispositivo de apontamento. Como mostrado na figura 20, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Dados de Dispositivo de Apontamento e CRC. Em uma modalidade exemplar, esse tipo de pacote é geralmente identificado como um pacote do Tipo 68 no campo do tipo de 1-byte.
12. Pacotes de Desligamento de Link
Um Pacote de Desligamento (Shutdown) de Link é enviado do hospedeiro para o display de cliente a fim de indicar que os dados de MDDI e estrobo serão desligados e entrarão em um estado de hibernação de baixo consumo de energia. Esse pacote é útil para desligar o link e conservar energia após envio de mapas de bits de um dispositivo de comunicação móvel para o display, ou quando nâo há informações adicionais para transferir de um hospedeiro para um cliente no presente momento. A operação normal é reiniciada quando o hospedeiro envia pacotes novamente. O primeiro pacote enviado após hibernação é uni pacote de cabeçalho de subquadro. O formato de um Pacote de Status de Display é mostrado na figura 21. Como mostrado na figura 21, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote e CRC. Em uma modalidade, esse tipo de pacote é geralmente identificado como um pacote do Tipo 69 no campo do tipo de
727
62/161
1-byte, e utiliza um comprimento fixo pré-selecionado de 3 bytes.
No estado de hibernação de baixa energia, o driver de MDDI_Data é desabilitado em um estado de alta impedância, e os sinais de MDDT_Data são puxados para um estado de lógica zero utilizando uma rede de polarização de alta impedância que pode ser acionada em excesso pelo display. O sinal de estrobo utilizado pela interface é definido em um nível de lógica zero no estado de hibernação para minimizar consumo de energia. O hospedeiro ou o cliente pode fazer com que o link de MDDI desperte do estado de hibernação como descrito em outra parte, que é um avanço principal para e vantagem da presente invenção.
13. Pacotes de Status e Solicitação de Display
O hospedeiro necessita uma pequena quantidade de informações do display de modo que possa configurar o link de hospedeiro-para-display em um modo geralmente ótimo. Recomenda-se que o display envie um Pacote de Status de Display para cada subquadro do hospedeiro. O display deve enviar esse pacote como o primeiro pacote no Pacote de Encapsulamento de Link Reverso para assegurar gue seja fornecido de forma segura para o hospedeiro. C formato de um Pacote de Status de Display é mostrado na figura 22. Como mostrado na figura 22, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Solicitação de Link Reverso, Contagem de Erro CRC e CRC. Esse tipo de pacote é geralmente identificado como um pacote do Tipo 70 no campo do tipo de 1-byte, e utiliza um comprimento fixo pré-selecionado de 8 bytes.
O campo de Solicitação de Link Reverso pode ser utilizado para informar o hospedeiro sobre o número de bytes que o display necessita no Pacote de Encapsulamento de link reverso para enviar dados de volta para o
63/161 hospedeiro. O hospedeiro deve tentar conceder a solicitação pela alocação pelo menos daquele número de bytes no Pacote de Encapsulamento de Link Reverso. O hospedeiro pode enviar mais de um Pacote de Encapsulamento de Link Reverso em um subquadro para acomodar dados. O cliente pode enviar um Pacote de Status e Solicitação de dispiay a qualquer momento e o hospedeiro interpretará o parâmetro de Solicitação de Link Reverso como o número total de bytes solicitados em um subquadro. Detalhes adicionais e exemplos específicos de como os dados de link reverso são enviados de volta para o hospedeiro sãc mostrados abaixo.
14. Pacotes de Transferência de Bloco de Bits
O Pacote de transferência de bloco de bits provê um dispositivo para rolar regiões do dispiay em qualquer direção. Displays que têm essa capacidade reportarão a capacidade no bit 0 do campo de Indicadores de Capacidade de Recurso de dispiay do Pacote de Capacidade de dispiay. O formato de um Pacote de Transferência de Bloco de bits é mostrado na figura 23. Como mostrado na figura 23, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Valor X Esquerdo Superior, Valor Y Esquerdo Superior, Largura de Janela, Altura de Janela, Movimento X de Janela, Movimento Y de Janela e CRC. Esse tipo de pacote é geraimente identificado como um pacote do tipo 71, e utiliza um comprimento fixo pré-selecicnado de 15 bytes.
Os campos são utilizados para especificar os valores X e Y da coordenada do canto esquerdo superior da janela a ser movida, a larqura e altura da janela a ser movida, e o número de pixels que a janela deve ser movida horizontal e verticalmente respectivamente. Valores positivos para os dois campos mencionados por último fazem com que a janela seja movida para a direita, e para baixo,
64/161 e valores negativos causam movimento para a esquerda e para cima, respectivamente.
15. Pacotes de Preenchimento de Área de Mapa de
Bits
Pacote de Preenchimento de Área de Mapa de Bits provê um dispositivo para facilmente inicializar uma região do display para uma única cor. Displays que têm essa capacidade reportarão a capacidade no bit 1 do campo de Indicadores de Capacidade de Recurso de display do Pacote de Capacidade de Display. O formato de um Pacote de preenchimento de área de mapa de bits é mostrado na figura 24. Como mostrado na figura 24, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Valor X Esquerdo Superior, Valor Y Esquerdo Superior, Largura de Janela, Altura de Janela, Descritor de Formato de Dados, Valor de Preenchimento de Área de Pixel e CRC. Esse tipo de pacote é geralmente identificado como um pacote do Tipo 72 no campo do tipo 1-byte, e utiliza um comprimento fixo pré-selecionado de 17 bytes.
16. Pacotes de Preenchimento de Padrão de Mapa de
Bits
O pacote de Preenchimento de Padrão de Mapa de Bits provê um dispositivo para facilmente inicializar uma região do display para um padrão pré-selecionado. Displays que têm essa capacidade reportarão a capacidade no bit 2 do campo de Indicadores de Capacidade de Recurso de Display do Pacote de Capacidade de Display. 0 canto esquerdo superior do padrão de preenchimento é alinhado com o canto esquerdo superior da janela a ser preenchida. Se a janela a ser preenchida for mais larga ou mais alta do que o padrão de preenchimento, então c padrão pode ser repetido horizontal ou verticalmente um número de vezes para preencher a janela. O direito ou inferior do último padrão repetido é
65/161
Ζ.
truncado conforme necessário. Se a janela for menor do que o padrão de preenchimento, então o lado direito ou inferior do padrão de preenchimento pode ser truncado para adaptarse na janela.
O formato de um Pacote de Preenchimento de Padrão de Mapa de Bits é mostrado na figura 25. Como mostrado na figura 25, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Valor X Esquerdo Superior, Valor Y Esquerdo Superior, Largura de Janela, Altura de Janela, Largura de Padrão, Altura de Padrão, Descritor de Formato de Dados, CRC de Parâmetro, Dados de Pixel de Padrão e CRC de Dados de Pixel. Esse tipo de pacote é geralmente identificado como um pacote do tipo 73 no campo do tipo 1-byte.
17. Pacotes de Canal de Dados de Link de Comunicação
O Pacote de Canal de Dados de Link de Comunicação provê urr. dispositivo para um display com capacidade de comutação de nível elevado, como um PDA, para comunicar-se com um transceptor sem fio como um telefone celular ou dispositivo de porta de dados sem fio. Nessa situação, o link de MDDI está atuando como uma interface de alta velocidade conveniente entre o dispositivo de comunicação e o dispositivo de computação com o display móvel, onde esse pacote transporta dados em uma Camada de Link de Dados de um sistema operacional para o dispositivo. Por exemplo, esse pacote podería ser utilizado se um navegador (browser) de web, cliente de email, ou um PDA inteiro fosse embutido em um display móvel. Displays que têm essa capacidade reportarão a capacidade no bit 3 do campo de Indicadores de Capacidade de Recurso de Display do Pacote de Capacidade de Display.
66/161
O formato de um Pacote de Canal de Dados de Link de Comunicação é mostrado na figura 26. Como mostrado na figura 26, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, CRC de Parâmetro, Dados de Link de Comunicação, e CRC de Dados de Comunicação. Esse tipo de pacote é geralmente identificado como um pacote do tipo 74 no campo do tipo.
18. Pacotes de Solicitação de Handoff do Tipo
Interface
O Pacote de Solicitação de Handoff do Tipo Interface habilita o hospedeiro para que solicite que o cliente ou display mude de um modo existente ou atual para os modos Tipo-I (serial), Tipo II (paralelo 2 bits), Tipo III (paralelo 4 bits) ou Tipo IV (paralelo 8 bits) . Antes do hospedeiro solicitar um modo específico deve confirmar que o display é capaz de operar no modo desejado pelo exame de bits 6 e 7 do campo de Indicadores de Capacidade de Recurso de Display do Pacote de Capacidade de Display. 0 formato de um Pacote de Solicitação de Handoff do Tipo Interface é mostrado na figura 27. Como mostrado na figura 27, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Tipo de Interface e CRC. Esse tipo de pacote é geralmente identificado como um pacote do Tipo 75, e utiliza um comprimento fixo préselecionado de 4 bytes.
19. Pacotes de Confirmação do Tipo de Interface
O Pacote de Confirmação do Tipo de Interface é enviado pelo display para confirmar recebimento do Pacote de Handoff do Tipo de Interface. O modo solicitado, modo Tipo-I (serial), Tipo-II (paralelo 2 bits), Tipo-III (paralelo 4 bits) ou Tipo-IV (paralelo 8 bits) é ecoado de volta para o hospedeiro como um parâmetro nesse pacote. O formato de um Pacote de Confirmação do Tipo de Interface é
67/161 mostrado na figura 28. Como mostrado na figura 28, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Tipo de interface e CRC. Esse tipo de pacote é geralmente identificado como um pacote do Tipo 76, e utiliza um comprimento fixo pré-selecionado de 4 bytes.
20. Pacotes de Handoff do Tipo Executar
Pacote de Handoff do Tipo Executar é um dispositivo para o hospedeiro comandar o display a handoff para o modo especificado nesse pacote. Esse deve ser o mesmo modo que foi previamente solicitado e confirmado pelo Pacote de Solicitação de Handoff do Tipo de Interface e Pacote de Confirmação do Tipo de Interface. O hospedeiro e display devem comutar para o modo em acordo após esse pacote ser er.viadc. 0 display pode perder e ganhar novamente sincronização de link, durante a mudança de modo. O formato de um Pacote de Handoff do Tipo Executar é mostrado na figura 29. Como mostrado na figura 29, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Tipo de Pacote e CRC. Esse tipo de pacote é geralmente identificado como um pacote do Tipo 77 no campo do tipo 1-byte, e utiliza um comprimento fixo pré-selecionado de 4 bytes.
21. Pacotes de Habilitar Canal de Áudio Direto
Esse pacote permite que o hospedeiro habilite ou desabilite canais de áudio no display. Essa capacidade é útil de modo que o display (cliente) possa desligar amplificadores de áudio ou elementos de circuito similares para poupar energia quando não há áudio a ser transmitido pelo hospedeiro. Isto é significativamente mais difícil de se implementar implicitamente simplesmente utilizando a presença ou ausência de fluxos de áudio como um indicador. O estado default quando o sistema de display é ligado é que
68/161
3^ todos os canais de áudio sejam habilitados. O formato de um Pacote de Habilitação de Canal de áudio direto é mostrado na figura 30. Como mostrado na figura 30, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Máscara de Habilitação de Canal de Áudio e CRC. Esse tipo de pacote é geralmente identificado como um pacote do Tipo 78 no campo do tipo 1-byte, e utiliza um comprimento fixo pré-selecionado de 4 bytes.
22. Pacotes de Taxa de Amostra de Áudio Reverso
Esse pacote permite ao hospedeiro habilitar ou desabilitar o canal de áudio de link reverso e definir a r.axa de amostra de dados de áudio desse fluxo. O hospedeiro seleciona uma taxa de amostra que é definida para ser válida no Pacote de Capacidade de Display. Se o hospedeiro selecionar uma taxa de amostra inválida então o display não enviará um fluxo de áudio para o hospedeiro. 0 hospedeiro pode desabilitar o fluxo de áudio de link reverso pela definição da taxa de amostra em 255. O estado default assumido quando o sistema de display é inicialmente ligado ou conectado é com o fluxo de áudio de link reverso desabilitado. O formato de um Pacote de Taxa de amostra de áudio reverso é mostrado na figura 31. Como mostrado na figura 31, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Taxa de Amostra de Áudio e CRC. Esse ripo de pacote é geralmente identificado como um pacote do Tipo 79, e utiliza um comprimento fixo pré-selecionado de 4 bytes.
23. Pacotes Overhead de Proteção de Conteúdo
Digital
Esse pacote permite que o hospedeiro e um display troquem mensagens relacionadas ao método de proteção de conteúdo digital sendo utilizado. Atualmente dois tipos de proteção de conteúdo são considerados, Proteção de Conteúdo
69/161
35/ de Transmissão Digital (DTCP), ou Sistema de Proteção de Conteúdo Digital de Largura de Faixa Alta (HDCP), com espaço reservado para designações de esquema de proteção alternativo futuro. 0 método sendo utilizado é especificado por um parâmetro do Tipo de Proteção de Conteúdo nesse pacote. 0 formato de um Pacote de Overhead de Proteção de Conteúdo Digital é mostrado na figura 32. Como mostrado na figura 32, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Tipo de Proteção de Conteúdo, Mensagens Overhead de Proteção de Conteúdo e CRC. Esse tipo de pacote é geralmente identificado como um pacote do Tipo 80.
24. Pacotes de Habilitação de Cor Transparente
O Pacote de Habilitação de Cor Transparente é utilizado para especificar qual cor é transparente em um display e habilitar ou desabilitar a utilização de uma cor transparente para exibição de imagens. Displays que têm essa capacidade reportarão essa capacidade no bit 4 do campo de Indicadores de Capacidade de Recurso de Display do Pacote de Capacidade de Display. Quando um pixel com o valor para cor transparente é gravado no mapa de bits, a cor não muda do valor anterior. O formato de um Pacote de Habilitação de Cor Transparente é mostrado na figura 33. Como mostrado na figura 33, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, Habilitação de Cor Transparente, Descritor de Formato de Dados, Vale de Pixel Transparente e CRC. Esse tipo de pacote é geralmente identificado como um pacote do Tipo 81 no campo do tipo de 1-byte, e utiliza um comprimento fixo pré-selecionado de 10 bytes.
25. Pacotes de Medição de Retardo de Ida e Volta
C Pacote de Medição de Retardo de Ida e Volta é utilizado para medir o retardo de propagação do hospedeiro
70/161
Τ para um cliente (display) mais o Retardo do cliente (display) de volta para o hospedeiro. Essa medição inclui inerentemente os retardos que existem nos receptores e drivers de linha, e um subsistema de interconexão. Essa medição é utilizada para definir os parâmetros de divisor de taxa de link reverso e retardo de reversão de sentido no Pacote de Encapsulamento de link reverso, descrito geralmente acima. Esse pacote é mais útil quando o link de MDDI está operando na velocidade máxima pretendida para uma aplicação específica. O sinal MDDI_Stb se comporta como se dados todos zero estivessem sendo enviados durante os seguintes campos: Todos Zero, os dois Tempos de Guarda e o Período de Medição. Isto faz com que MDDI_Stb alterne na metade da taxa de dados de modo que possa ser utilizado como relógio periódico no display durante o Período de Medição.
O formato de um Pacote de Medição de Retardo de Ida e Volta é mostrado na figura 34. Como mostrado na figura 34, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote, Tipo de Pacote, CRC de Parâmetro, Todos Zero, Tempo de Guarda 1, Período de Medição, Tempo de Guarda 2, e Reabilitação de Driver. Esse tipo de pacote é geralmente identificado como um pacote do Tipo 82, e utiliza um comprimento fixo pré-selecionado de 533 bits.
A temporização de eventos que ocorrem durante o Pacote de Medição de Retardo de Ida e Volta é ilustrada na figura 35. Na figura 35, o hospedeiro transmite o Pacote de Medição de Retardo de Ida e Volta, mostrado pela presença dos campos de Alinhamento de Varredura e CRC de Parâmetro seguidos pelos campos de Todos Zero e Tempo de Guarda 1. Um retardo 3502 ocorre antes do pacote atingir o dispositivo de display do cliente ou conjunto de circuitos de
71/161
Figure BRPI0410885B1_D0008
processamento. À medida que o display recebe o pacote, transmite o padrão Oxff, Oxff, 0x0 de forma tão precisa quanto prática no início do Período de Medição como determinado pelo display. O tempo efetivo em que o display começa a transmitir essa seqüência é retardado do início do Período de Medição do ponto de vista do hospedeiro. A. proporção desse retardo é substancialmente o tempo que leva para o pacote se propagar através dos receptores e drivers de linha e subsistema de interconexão. Uma proporção
similar de retardo 3504 é incorrida para o padrão se
propagar do display de volta para o hospedeiro.
Para determinar de forma precisa o tempo de
retardo de ida e volta para os sinais que passam para e do
cliente, o hospedeiro conta o número de períodos de tempo de bit aue ocorre após o início do Período de Medição até o início da seqüência Oxff, Oxff, 0x0 ser detectada após chegada. Essas informações são utilizadas para determinar a proporção de tempo para que um sinal de ida e volta passe do hospedeiro para o cliente e de volta novamente. Então, aproximadamente metade dessa proporção é atribuída a um retardo criado para a passagem de um sentido de um sinal para o cliente.
O display desabilita seus drivers de linha substancialmente imediatamente após envio do último bit do padrão Oxff, Oxff, 0x0. 0 Tempo de Guarda 2 permite tempo para que os drivers de linha do display vão completamente para o estado de impedância alta antes do hospedeiro transmitir o Comprimento de Pacote do pacote seguinte. Os resistoros pull-up e puii-down de hibernação (vide a figura 42) asseguram que os sinais MDDI_Data sejam mantidos em um nível baixo válido nos intervalos onde os drivers de linha são desabi1itados tanto no hospedeiro como no display.
33/
72/161
26. Pacote de Calibragem de Distorção de Link
Direto
Pacote de Calibragem de Distorção (Skew) de Link Direto permite que um cliente ou Display calibre ele próprio diferenças no retardo de propagação dos sinais de MDDI_Data com relação ao sinal de MDDI_Stb. Sem compensação de distorção de retardo, a taxa máxima de dados é geralmente limitada para responder pela variação potencial de pior caso nesses retardos. Geralmente, esse pacote é somente enviado quando a taxa de dados de link direto é configurada para uma taxa em torno de 50 Mbps ou mais baixa. Após enviar esse pacote para calibrar o display, a taxa de dados pode ser elevada acima de 50 Mbps. Se a taxa de dados for definida demasiadamente elevada durante o processo de calibragem de distorção, o display poderia sincronizar em um desalinhamento (alias) do período de bits que poderia fazer com que a definição de compensação de distorção de retardo estivesse desligada por um tempo maior do gue um bit, resultando em sincronização de dados errôneos. O tipo de interface com taxa mais alta de dados ou Tipo de Interface maior possível é selecionado antes de enviar o Pacote de Calibragem de Distorção de Link Direto de modo que todos os bits de dados existentes sejam calibrados.
O formato de um Pacote de Calibragem de Distorção de Link Direto é mostrado na figura 56. Como niosLiado na figura 56, esse tipo de pacote é estruturado para ter campos de Comprimento de Pacote (2 bytes), Tipo de Pacote, CRC de Parâmetro, Seqüência de Dados de Calibragem e CRC. Esse tipo de pacote é geralmente identificado como um pacote do Tipo 83 no campo de tipo, e tem um comprimento pré-selecionado de 515.
D. CRC de Pacote
73/161 y\b
Os campos de CRC aparecem no final dos pacotes e às vezes após certos parâmetros mais críticos em um pacote que pode ter um campo de dados significativamente grande, e desse modo, uma probalidade aumentada de erros durante transferência. Em pacotes que têm dois campos de CRC, o gerador de CRC, quando somente um é utilizado, é reinicia 1 i zado após o primeiro CRC de modo que as computações de CRC após um campo de dados longos não são afetadas pelos parâmetros no início do pacote.
Em uma modalidade exemplar, o polinômio utilizado para o cálculo de CRC é conhecido como CRC-16, ou X16 + X15 + X2 + XO. Uma implementação de amostra de um gerador e verificador de CRC 3600 útil para implementar a invenção é mostrada na figura 36. Na figura 36, um registrador de CRC 3602 é iniciaiizado em um valor de 0x0001 pouco antes da transferência do primeiro bit de um pacote que é entrado na linha Tx_MDDI_Data_Before_CRC, então os bytes do pacote são deslocados para o registrador iniciando primeiramente com o LS3. Observe que os números de bit do registrador nessa figura correspondem à ordem do polinômio sendo utilizado, e não às posições de bit utilizadas pelo MDDI. É mais eficiente comutar o registrador de CRC em uma única direção, e isto resulta em se ter o bit 15 do CRC aparecendo na posição de bit 0 do campo de CRC de MDDI, e o bit 14 do registrador de CRC na posição 1 do bit. de campo de MDDI CRC, e assim por diante até se alcançar a posição 14 de bit de MDDI.
Como exemplo, se os conteúdos do pacote para os Pacotes de Status e Solicitação de Display forem: 0x07, 0x46, 0x000400, 0x00 (ou representado como uma seqüência de bytes como: 0x07, 0x00, 0x46, 0x00, 0x04, 0x00, 0x00) e são submetidos utilizando as entradas dos multiplexadores 3604 e 3606, e a porta NAND 3608, a saída de CRC resultante na
74/161 linha Tx_MDDI_Data_With_CRC é OxOeal (ou representado como uma seqüência como Oxal, OxOe).
Quando o gerador e verificador de CRC 3600 é configurado como um verificador de CRC, o CRC que é recebido na linha Rx_MDDI_Data é entrado no multiplexador 3606 e porta NAND 3608, e é comparado bit a bit com o valor encontrado no registrador de CRC utilizando a porta NOR 3610, porta OR-exclusiva (XOR) 3612, e porta AND 3614. Se houver algum erro, como transmitido pela porta AND 3614, o CRC é incrementado uma vez para cada pacote que contém um erro de CRC pela conexão da saída da porta 3614 à entrada do registrador 3602. Observe que o circuito de exemplo mostrado no diagrama da figura 36 pode transmitir mais de um sinal de erro de CRC em uma janela CHECK_CRC_NOW dada (vide a figura 37B). Portanto, o contador de erros de CRC geralmente conta somente a primeira ocorrência de erro de CRC em cada intervalo onde CHECK_CRC_NOW está ativo. Se configurado como um gerador de CRC, o CRC é sincronizado do registrador de CRC no tempo que coincide ccm o fim do pacote.
A temporização para os sinais de entrada e saída, e os sinais de habilitação, é ilustrada graficamente nas figuras 37A e 37B. A geração de um CRC e transmissão de um pacote de dados são mostradas na figura 37A com o estado (0 ou 1) dos sinais Gen_Reset, Check_CRC_Now, Generate_CRC_Now, e Sending_MDDT_Data, juntamer.te com os sinais Tx_MDDI_Data_Before_CRC e Tx_MDDI_Data_With_CRC. O recebimento de um pacote de dados e verificação do valor de CRC são mostrados na figura 37B, com o estado dos sinais Gen_Reset, Check_CRC_Now, Generate_CRC_Now e Sending_MDDI_Data, juntamente com os sinais de erro CRC e Rx_MDDI_Data.
75/161
37Ζ,
Ε. Sobrecarga de Código de Erro para CRC de
Pacote
Sempre que somente pacotes de dados e CRC estiverem sendo transferidos entre o hospedeiro e o cliente, não há códigos de erros sendo acomodados. 0 único erro é uma perda de sincronização. De outro modo, tem de se esperar que o link tenha um intervalo de uma taita de um bom percurso ou canalização de transferência de dados e a seguir redefina o link e prossiga. Infelizmente, isso é
1C demorado e de um certo modo ineficiente.
Para utilização em uma modalidade, uma nova técnica foi desenvolvida na qual a porção CRC de pacotes é utilizada para transferir informações de código de erro. Isto é geralmente mostrado na visão geral da figura 65, e em mais detalhes nas figuras 66A, 66B e 6/. Isco é, um ou mais códigos de erro são gerados pelos processadores ou dispositivos os quais manipulam a transferência de dados que indicam erros ou falhas predefinidos específicos que poderíam ocorrer no link ou processamento de comunicação.
Quando um erro é encontrado, o código de erro apropriado é gerado e transferido utilizando os bits para o CRC de um pacote. Isto é, o valor de CRC é sobrecarregado, ou sobreescrito, com o código de erro desejado, ou algum outro valor pré-selecionado para representar a presença de um erro, que pode ser detectada na extremidade de recebimento por um verificador ou monitor de erro que monitora os valores do campo de CRC. Para aqueles casos nos quais o código de erro corresponde ao valor de CRC por algum motivo, c complemento do erro é transferido para evitar confusão.
Em uma modalidade, para fornecer um sistema de alerta e detecção de erro robusto, o código de erro pode ser transferido várias vezes, utilizando uma série de >73
76/161 pacotes, geralmente todos, que são transferidos ou enviados após a detecção do erro. Isto ocorre até o ponto no qual a condição que cria o erro é apagada do sistema, em cujo ponto os bits de CRC regulares são transferidos sem sobrecarga por outro valor.
Essa técnica de sobrecarregar o valor de CRC provê uma resposta muito mais rápida aos erros do sistema enquanto utiliza uma quantidade mínima de campos ou bits extras.
Como mostrado na figura 66, um equipamento ou mecanismo de sobreescrita CRC 6600 é mostrado utilizando meios de detecção ou detector de erro 6602, que pode fazer parte de outro conjunto de circuitos previamente descrito ou conhecido, detecta a presença ou existência de erros no processo ou link de comunicação. Um dispositivo ou gerador de código de erro 6604, que pode ser formado como parte de outro conjunto de circuitos ou utiliza técnicas como tabelas de consulta para armazenar mensagens de erro préselecicnadas, gera um ou mais códigos de erro para indicar erros ou falhas predefinidos específicos que foram detectados como ocorrendo. É facilmente entendido que os dispositivos 6602 e 6604 podem ser formados como um único circuito ou dispositivo como desejado, ou como parte de uma seqüência programada de etapas para outros processadores e elementos conhecidos.
Um comparador ou meios de comparação de valor de CRC 6606 é mostrado para verificação para ver se o(s) código ou códigos de erro selecionados são iguais ao valor de CRC sendo transferido. Se esse for o caso então um gerador ou dispositivo ou meios de geração de complemento de código é utilizado para fornecer o complemento dos códigos de erro de modo a não ser confundido com o valor ou padrão de CRC original e confundir ou complicar o esquema
77/161 de detecção. Um dispositivo ou elemento de meios de seleção ou seletor de código de erro 6610 seleciona então o código de erro ou valor que deseja inserir ou scbreescrever, ou seus respectivos complementos como apropriado. Um mecanismo ou meios de sobreescrita ou sobreescritor de CRC de código de erro 6612 é um dispositivo que recebe o fluxo de dados, pacotes, e os códigos desejados a serem inseridos e sobreescreve os valores de CRC correspondentes ou apropriados, a fim de transferir os códigos de erro desejados para um dispositivo de recepção.
Como mencionado, o código de erro pode ser transferido várias vezes, utilizando uma série de pacotes, de modo que o sobreescritor 6612 possa utilizar elementos de armazenagem em memória para manter cópias dos códigos durante processamento ou relembrar esses códigos de elementos anteriores ou outros locais de armazenagem conhecidos que podem ser utilizados para armazenar ou manter seus valores conforme necessário, ou como desejado.
O processamento geral que o mecanismo de sobreescrita da figura 66 está implementado é mostrado em detalhe adicional nas figuras 67A e 67B. Em 67A um erro, um ou mais, é detectado na etapa 6702 nos dados de comunicação ou processo e um código de erro é selecionado na etapa 6704 para indicar essa condição. Ao mesmo tempo, ou em um ponto apropriado, o valor de CRC a ser substituído é verificado em uma etapa 6706, e comparado com o código de erro desejado na etapa 6708. O resultado dessa comparação, como discutido anteriormente, é uma determinação com relação ao fato de se o código desejado, ou outros valores representativos será ou nâo igual ao valor de CRC presente. Se esse for o caso, então o processamento prossegue em uma etapa 6712 onde o complemento, ou em alguns casos outro valor representativo, como desejado, é selecionado como o
78/161
Figure BRPI0410885B1_D0009
código para inserção. Após determinação de quais códigos de erro ou valores devem ser inseridos nas etapas 6710 e 6714, aquele código apropriado é selecionado para inserção. Essas etapas são ilustradas como separadas para fins de clareza, porém geraimente representam uma única escolha com base na saida da decisão da etapa 6708. Finalmente, na etapa 6716 os valores apropriados são sobreescritos no local de CRC para transferência com os pacotes sendo direcionados pelo processo.
No lado de recepção de pacote, como mostrado na figura 67B, os valores de CRC de pacote estão sendo monitorados em uma etapa 6722. Geraimente, os valores de CRC estão sendo monitorados por um ou mais processos no sistema para se determinar se um erro em transf erência de dados ocorreu e se deve ou não solicitar uma retransmissão do pacote os pacotes ou inibir operações adicionais e assim per diante, algumas das quais são discutidas acima. Como parte dessa monitoração as informações também podem ser utilizadas para comparar valores com códigos de erro conhecidos ou pré-selecionados, ou valores representativos e detectar a presença de erros. Alternativamente, um processo de detecção de erro separado e um monitor podem ser implementados. Se parecer que um código está presente, o mesmo é extraído ou de outro modo anotado na etapa 6724 para processamento adicional. Pode-se fazer uma determinação na etapa 6726 com relação ao fato de se esse é ou não o código efetivo ou um complemento, em cujo caso uma etapa adicional 6728 é utilizada para converter o valor em um valor de código desejado. Em qualquer caso o código extraído resultante, complemento ou outros valores recuperados são então utilizados para detectar qual erro ocorreu do código transmitido na etapa 6730.
V. Reinicio de Link a partir da Hibernação
79/161
Quando ο hospedeiro reinicia o link direto de um estado de hibernação aciona MDDI_Data para um estado de lógica um por aproximadamente 150 ps e então ativa MDDI_Stb e simultaneamente aciona MDDI_Data para um estado de lógica zero por 50 lis, e então inicia tráfego de link direto pelo envio de um pacote de cabeçalho de subquadro. Isto permite geralmente que contenções de barramento sejam resolvidas antes que o pacote de cabeçalho de subquadro seja enviado pela provisão de tempo de assentamento suficiente entre os sinais.
Quando o cliente, aqui um display, necessita de dados ou comunicação do hospedeiro ele aciona a linha MDDI_Data0 para um estado de lógica um por aproximadamente 70 ps, embora outros períodos possam ser utilizados como desejado, e então desabilita o driver colocando o mesmo em um estado de alta impedância. Essa ação faz com que o hospedeiro inicie ou reinicie tráfego de dados no link direto (208) e interrogue o cliente por seu status. O hospedeiro deve detectar a presença do pulso de solicitação em 50 ps e então iniciar a sequência de partida de acionar MDDI_Data0 para lógica um por 150 ps e para lógica zero por 50 ps. O display não deve enviar um pulso de solicitação de serviço se detectar MDDI_DataO no estado de lógica um por mais de 50 ps. A natureza de seleção dos tempos e tolerâncias de intervalos de tempo relacionados à sequência de processamento de hibernação e partida são discutidas abaixo.
Um exemplo das etapas de processamento para um evento de solicitação de serviço típico sem contenção é ilustrado na figura 38, onde os eventos são rotulados por conveniência na ilustração utilizando as letras A, 3, C, D, E, F e G. O processo inicia no ponto A quando o hospedeiro
80/161 envia um Pacote de Desligamento de Link para o dispositivo cliente a fim de informar o mesmo de que o link fará transição para um estado de hibernação de baixa energia. Em uma etapa seguinte, o hospedeiro entra no estado de hibernação de baixa energia pela desabilitação do driver de MDDI_DataO e definição do driver de MDDI_Stb em uma lógica zero, como mostrado no ponto B. MDDI_DataO é acionado para um nível zero por uma rede de polarização de impedância alta. Após um certo período de tempo, o cliente envia um pulso de solicitação de serviço para o hospedeiro acionando MDDI_DataO para um nível de lógica um como visto no ponto C. O hospedeiro ainda determina o nível zero utilizando a rede de polarização de impedância alta, porém o driver no cliente força a linha para um nível de lógica um. Em 50 ps, o hospedeiro reconhece o pulso de solicitação de serviço, e determina um nível de lógica um no MDDI_DataO pela habilitação de seu driver, como visto no ponto D. O cliente cessa então de tentar determinar o pulso de solicitação de serviço, e o cliente coloca seu driver em um estado de impedância alta, como visto no ponto E. O hospedeiro aciona MDDI_Data0 para um nível de lógica zero por 50 ps, como mostrado no ponto F, e também começa a gerar MDDI_Stb em um modo compatível com o nível de lógica zero em MDDI_Data0. Após determinação de MDDI_DataO em um nível zero e acionar
MDDI_Stb por 50 ps, o hospedeiro começa a transmitir dados no link direto pelo envio de um Pacote de Cabeçalho de Subquadro, como mostrado no ponto G.
Um exemplo similar é ilustrado na figura 39 onde uma solicitação de serviço é determinada após início da seqüência de reinicio de link, e os eventos são novamente rotulados utilizando as letras A, B, C, D, E, F e G. Isto representa um cenário de pior caso onde um pulso de
81/161
3Ϊ5 solicitação ou sinal do cliente se aproxima mais do dano do Pacote de Cabeçalho de Subquadro. O processo começa no ponto A quando o hospedeiro envia novamente um Pacote de Desligamento de Link para o dispositivo cliente a fim de informar ao mesmo que o link fará transição para um estado de hibernação de baixa energia. Em uma etapa seguinte, o hospedeiro entra no estado de hibernação de baixa energia pela desabilitação do driver de MDDI_DataO e definição do driver de MDDI_Stb em um zero lógico, como mostrado no ponto B. Como anteriormente, MDDI_DataO é acionado para um nível zero por uma rede de polarização de impedância alta. Após um período de tempo, o hospedeiro começa a seqüência de reinicio de link pelo acionamento de MDDI_DataO para um nível um lógico por 150 ps como visto no ponto C. Antes de passar 50 ps após começo da seqüência de reinicio de link o display também determina MDDI_Data0 por uma duração de 70 ps, como visto no ponto D. Isto acontece porque o display tem necessidade de solicitar serviço do hospedeiro e não reconhece que o hospedeiro já começou a seqüência de reinicio de link. O cliente cessa então de tentar determinar o pulso de solicitação de serviço, e o cliente coloca seu driver em um estado de impedância alta, como visto no ponto E. 0 hospedeiro continua a acionar MDDI_Data0 para um nível lógico um. 0 hospedeiro aciona MDDI_Data0 para um nível lógico zero de por 50 ps, como mostrado no ponto F, e também começa a gerar MDDI_Stb em um modo compatível com o nível de lógica zero em MDDI_Data0. Após determinar MDDI_DataO em um nível zero, e acionar MDDI_Stb por 50 ps, o hospedeiro começa a transmitir dados no link direto pelo envio de um Pacote de Cabeçalho de Subquadro, como mostrado no ponto G.
82/161
14?
Da discussão acima, vê-se que a solução anterior envolveu a passagem do hospedeiro através de dois estados como parte de uma seqüência de despertar. Para o primeiro estado, o hospedeiro aciona o sinal MDDI_DataO elevado por 150 lis, e então aciona o sinal MDDI_DataO baixo por 50ps enquanto ativa a linha MDDI_Stb, e então começa a transmitir pacotes de MDDI. Esse processo funciona bem para avançar o estado da técnica em termos de taxas de dados obteníveis utilizando os métodos e equipamentos de MDDI. Entretanto, como dito anteriormente, mais taxa em termos de tempos de resposta reduzido a condições ou a capacidade de selecionar mais rapidamente a próxima etapa ou processo, ou a capacidade de simplificar processamento ou elementos, estão sempre em demanda.
Os requerentes descobriram uma nova abordagem inventiva para processamento e temporização de despertar na qual o hospedeiro utiliza uma temporização baseada em ciclo de relógio para a alternação de sinais. Nessa configuração, o hospedeiro começa a alternar MDDI_Stb de 0 a 10 ps após c hospedeiro acionar o sinal de MDDI_Data0 elevado no início da seqüência de despertar, e não espera até que o sinal seja acionado baixo. Durante uma seqüência de despertar, c hospedeiro alterna MDDI_Stb como se o sinal de MDDI_Data0 estivesse sempre em um nível lógico zero. Isto efetivamente remove o conceito de tempo do lado do cliente, e o hospedeiro muda dos peiíodos anteriores de 150 ps e 50 ps para os dois primeiros estados, para 150 ciclos de relógio e 50 ciclos de relógio, para esses períodos.
O hospedeiro se torna agora responsável por acionar a linha de dados de aita, e em 10 ciclos de relógio começa a transmitir um sinal de estrobo como se a linha de dados fosse zero. Após o hospedeiro ter acionado a linha de
83/161 dados alta para 150 ciclos de relógio, o hospedeiro aciona a linha de dados baixa para 50 ciclos de relógio enquanto continua a transmitir o sinal de estrobo. Após ter concluído esses dois processos, o hospedeiro pode começar a transmitir o primeiro pacote de cabeçalho de subquadro.
No lado de cliente, a implementação de cliente pode usar agora o relógio gerado para calcular o número de ciclos de relógio que a linha de dados é primeiramente alta e então baixa. O número de ciclos de relógio que necessita ocorrer no estado alto acionado por linha de dados é 150 e no estado baixo acionado por linha de dados é 50. Isto significa que para uma sequência de despertar adequada, o cliente deve estar apto a contar pelo menos 150 ciclos de relógio contínuos da linha de dados sendo alta, seguido por pelo menos 50 ciclos de relógio contínuos da linha de dados sendo baixa. Após cumprimento dessas duas condições, o cliente pode começar a buscar a palavra exclusiva do primeiro subquadro. Uma ruptura nesse padrão é utilizada como base para retornar os contadores para um estado inicial no qual o cliente novamente procura os 150 primeiros ciclos de relógio contínuos da linha de dados sendo alta.
Uma implementação da invenção pelo cliente para despertar de hibernação baseado em hospedeiro é muito similar ao caso de partida inicial exceto que a taxa do relógio não é forçada a iniciar em 1 Mbps, como discutido anteriormente. Em vez disso a taxa do relógio pode ser definida para reiniciar em qualquer taxa anterior que estava ativa quando o link de comunicação entrou em hibernação. Se o hospedeiro começar a transmissão de um sinal de estrobo como descrito acima, o cliente deve estar apto a novamente contar pelo menos 150 ciclos de relógio contínuos da linha de dados sendo alta, seguido por pelo
84/161 menos 50 ciclos de relógio contínuos da linha de dados sendo baixa. Após cumprimento dessas duas condições, o cliente pode começar a buscar a palavra exclusiva.
Uma implementação da invenção pelo cliente para despertar de hibernação baseado em cliente é similar ao despertar baseado em hospedeiro exceto que começa pelo cliente acionando a linha de dados. O cliente pode acionar assincronamente a linha de dados sem um relógio para despertar o dispositivo hospedeiro. Após o hospedeiro reconhecer que a linha de dados está sendo acionada alta pelo cliente, pode começar sua sequência de despertar. O cliente pode contar o número de ciclos de relógio gerados pelo início do hospedeiro ou durante seu processo de despertar. Após o cliente contar 70 ciclos de relógio contínuos dos dados sendo alto, pode parar de acionar a linha de dados alta. Nesse ponto, o hospedeiro já deve estar acionando também a linha de dados alta. O cliente pode então contar mais 80 ciclos de relógio contínuos da iinha de dados sendo alta para atingir os 150 ciclos de relógio da linha de dados sendo alta, e pode então procurar 50 ciclos de relógio da linha de dados sendo baixa. Após cumprimento dessas três condições o cliente pode começar a procurar a palavra exclusiva.
Uma vantagem dessa nova implementação de processamento de despertar é que remove a necessidade de um dispositivo de medição de tempo. Quer esse seja um oscilador ou circuito de descarga de capacitor, ou outros dispositivos conhecidos, o cliente não mais necessita desses dispositivos externos para determinar as condições de partida. Isto poupa dinheiro e área de circuito ao implementar controladores, contadores, e assim por diante em um painel do dispositivo cliente. Embora isso possa não ser tão vantajoso para o cliente, para o hospedeiro, essa
85/161 técnica também deve simplificar potencialmente o hospedeiro em termos de lógica de densidade muito alta (VHDL) sendo utilizada para conjunto de circuitos de núcleo. O consumo de energia de utilizar as linhas de estrobo e dados como a fonte de medição e notificação de despertar também será mais baixo uma vez que nenhum conjunto de circuitos externo necessitará estar operando para os elementos de núcleo esperando por um despertar baseado em hospedeiro.
O número de ciclos ou períodos de relógio utilizados são exemplares e outros períodos podem ser utilizados como será evidente para uma pessoa versada na técnica.
Para clarificar e ilustrar a operação dessa técnica nova, a temporização de MDDI_DataO, MDDI_Stb, e várias operações relativas aos ciclos de relógio são mostradas nas figuras 68A, 68B e 68C.
Um exemplo das etapas de processamento para um Despertar iniciada por Hospedeiro típico sem contenção é ilustrado na figura 68A, onde os eventos são novamente rotulados para conveniência em ilustração utilizando as letras A, B, C, D, E, F e G. O processo inicia no ponto A quando o hospedeiro envia um Pacote de Desligamento de Link para o dispositivo cliente a fim de informar ao mesmo que o link fará transição para um estado de hibernação de baixa energia. Em uma etapa seguinte, ponto B, o hospedeiro alterna MDDI_Stb por aproximadamente 64 ciclos (ou como desejado para projeto de sistema) para permitir que processamento pelo cliente seja concluído antes de parar a alternaçSo do MDDI_Stb, que pára o relógio recuperado no dispositivo clier.te. 0 hospedeiro também define inicialmente MDDI_DataO para nível de lógica zero e então desabilita a saída de MDDI_DataO na faixa de 16 a 48 ciclos (geralmente incluindo retardos de propagação de habilitação
86/161 de saída) após o CRC. Pode ser desejável colocar os receptores de alta velocidade para MDDI_DataO e MDDI_Stb do cliente em um estado de baixa energia algum momento após cs 48 ciclos após o CRC e antes do próximo estágio (C).
O hospedeiro entra no estado de hibernação de baixa energia no ponto ou etapa C, desabilitando os drivers MDDI_DataO e MDDI_Stb e colocando um controlador hospedeiro em um estado de hibernação de baixa energia. Pode-se também definir o driver MDDI_Stb em um nível lógico zero (utilizando uma rede de polarização de alta impedância) ou continuar a alternação durante hibernação, como desejado. O cliente também está em um estado de hibernação de nível de baixa energia.
Após algum período de tempo, o hospedeiro começa a seqüência de reinicio de link no ponto D, habilitando a saída de driver MDDI_DataO e MDDI_Stb. O hospedeiro adiciona MDDI_DataO para um nível lógico um e MDDI_Stb para um nível lógico zero enquanto demora para que os drivers habilitem totalmente suas respectivas saídas. 0 hospedeiro espera tipicamente em torno de 200 nanossegundos após essas saldas atingirem níveis lógicos desejados antes de acionar pulsos em MDDI_Stb. Isto permite tempo ao cliente para preparar para receber.
Com os drivers de hospedeiro habilitados e MDDI_Dta0 sendo acionados para um nível lógico um, o hospedeiro começa a alternar MDDI_Stb peia duração de 150 ciclos de MDDI_Stb, como viste no ponto Ε. O hospedeiro aciona MDDI_Data0 para um nível lógico zero por 50 ciclos, como mostrado no ponto F, e o cliente começa a procurar o Pacote de Cabeçalho de Subquadro após MDDI_Data0 estar em um nível lógico zero por 40 ciclos de MDDI_Stb. 0 hospedeiro começa a transmitir dados no link direto pelo envio de um Pacote de Cabeçalho de Subquadro, como mostrado no ponto G.
87/161
Figure BRPI0410885B1_D0010
Um exemple das etapas de processamento para uma Despertar iniciada por Cliente típico sem contenção é ilustrado na figura 683, onde os eventos são novamente rotulados por conveniência na ilustração utilizando as letras A, B, C, D, Ξ, F, G, Hei. Como anteriormente, o processo inicia no ponto A quando o hospedeiro envia um Pacote de Desligamento de Link para informar ao cliente que o link fará transição para o estado de baixa energia.
No ponto B, o hospedeiro alterna MDDI_Stb por aproximadamente 64 ciclos (ou como desejado para o projeto do sistema) para permitir conclusão do processamento pelo cliente antes de parar a alternação do MDDI_Stb, que pára o relógio recuperado no dispositivo cliente. O hospedeiro também define inicialmente MDDI_DataO para um nível lógico zero e então desabilita a saída de MDDI_DataO na faixa de 16 a 48 ciclos (geraimente incluindo retardos de propagação de desabilitaçâo de saída) após o CRC. Pode ser desejável colocar receptores de alta velocidade para MDDI_DataO e MDDI_Stb do cliente em um estado de baixa energia algum tempo após os 48 ciclos após o CRC e antes do estágio seguinte (C).
O hospedeiro entra no estado de hibernação de baixa energia no ponto ou etapa C, pela desabilitaçâo dos drivers de MDDI_DataO e MDDI_Stb e colocação de um controlador de hospedeiro em um estado de hibernação de baixa energia. Pode-se definir também o driver de MDDI_Stb para um nível de lógica zero (utilizando uma rede de polarização de impedância alta) ou continuar a alternação durante hibernação, como desejado. 0 cliente também está em um estado de hibernação de nível de baixa energia.
Após um certo período de tempo, o cliente começa a sequência de reinicio de link no ponto D, pela habilitação do receptor de MDDI_Stb, e também habilitação
88/161
Figure BRPI0410885B1_D0011
de um offset no receptor de MDDI_Stb para garantir que o estado da versão recebida de MDDI_Stb seja um nível lógico zero no cliente antes do hospedeiro habilitar seu driver MDDI_Stb. Pode ser desejável que o cliente habilite o offset ligeiramente antes de habilitar o receptor para assegurar a recepção de um sinal de diferencial válido e inibir sinais errôneos, como desejado. 0 Cliente habilita o driver de MDDI_DataO enquanto aciona a linha de MDDI_Data0 para um nível lógico um.
Em aproximadamente 1 ms, ponto Ξ, o hospedeiro reconhece o pulso de solicitação de serviço do cliente, e o hospedeiro começa a sequência de reinicio de link pela habilitação das saídas de driver de MDDI_DataO e MDDI_Stb. O hospedeiro aciona MDDI_DataO para um nível lógico um e
MODI_Stb para um nível lógico zero pelo tempo que demorar para os drivers habilitarem suas respectivas saídas. 0 hospedeiro tipicamente espera em torno de 200 nanossegundos após essas saídas atingirem níveis lógicos desejados antes de acionar os pulsos em MDDI_Stb. Isto permite tempo para o cliente preparar para receber.
Com os drivers de hospedeiro habilitados e
MDDI_DataO sendo acionados para um nível lógico um, o hospedeiro começa a transmissão de pulsos em MDDI_Stb por uma duração de 150 ciclos de MDDI_Stb, como visto no ponto
F. Quando o cliente reconhece o primeiro pulso em MDDI_Stb desabilita o offset em seu receptor de MDDI_Stb. O cliente continua a acionar MDDI_Dara0 para um nível lógico um por 70 ciclos de MDDI_Stb, e desabilita seu driver de MDDI_Data0 no ponto G.
Como visto nos pontos G e Η, o hospedeiro aciona
MDDI_Data0 para um nível lógico zero por 50 ciclos, e o cliente começa a procurar o Pacote de Cabeçalho de Subquadro após MDDl_Data0 estar em um nível lógico zero por
89/161 ciclos de MDDI_Stb. O hospedeiro começa a transmissão de dados no link direto pelo envio de um Pacote de Cabeçalho de Subquadro, como mostrado no ponto I.
Um exemplo das etapas de processamento para um Despertar iniciado por Hospedeiro tipicc com contenção do cliente, isto é o cliente também deseja despertar o link, é ilustrado na figura 68C. Os eventos são novamente rotulados por conveniência em ilustração utilizando as letras A, 3,
C, D, E, E, G, Hei. Como anteriormente, o processo começa no ponto A quando o hospedeiro envia um Pacote de Desligamento de Link para informar ao cliente que o link fará transição para o estado de energia baixa, prossegue para o ponto B onde MDDI_Stb é alternado por aproximadamente 64 ciclos (ou como desejado para o desenho do sistema) a fim de permitir que o processamento pelo cliente seja concluído, e então para o ponto C, onde o hospedeiro entra no estado de hibernação de baixa energia, pela desabilitaçâo des drivers de MDDI_DataO e MDDI_Stb e colocação de um controlador de hospedeiro em um estado de hibernação de baixa energia. Após algum período de tempo, o hospedeiro começa a sequência de reinicio de link no ponto
D, pela habilitação da saída de driver de MDDI_DataO e MDDI_Stb, e começa a alternar MDDI_Stb pela duração de 150 ciclos de MDDI_Stb, como visto no ponto E.
Até 70 ciclos de MDDI_Stb após o ponto E, aqui o ponto F, c cliente não reconheceu ainda que o hospedeiro está acionando MDDI_Data0 para um nível de lógica um de modo que o cliente também aciona MDDI_Data0 para um nível lógico um. Isto ocorre aqui porque o cliente tem um desejo de solicitar serviço, porérr. não reconhece que o hospedeiro com c qual está tentando comunicar-se já começou a sequência de reinicio de link. No ponto G, c cliente cessa de acionar MDDI DataO e coloca seu driver em um estado de
90/161 impedância alta pela desabilitaçãc de sua saída. O hospedeiro continua a acionar MDDI_Data0 para um nível lógico um por 80 ciclos adicionais.
O hospedeiro aciona MDDI_DataO para um nível lógico zero por 50 ciclos, como mostrado no ponto H, e o cliente começa a procurar o Pacote de Cabeçalho de Subquadro após MDDI_Data0 estar em um nível lógico zero por 40 ciclos de MDDI_Stb. O hospedeiro começa a transmissão de dados no lir.k direto pelo envio de um Pacote de Cabeçalho de Subquadro, como mostrado no ponto I.
VI. Especificações Elétricas de Interface
Kas modalidades de exemplo, Dados em um formato de Não Retorna a Zero (NRZ) são codificados utilizando um sinal de estrobo-dados ou formato DADOS-STB, que permite que informações de relógio sejam incorporadas nos sinais de estrobo e dados. C relógio pode ser recuperado sem conjunto de circuitos de elo de sincronismo de fase complexo. Os dados são transportados através de um link diferencial bidirecional, geraimente implementado utilizando um cabo de ligação, embora outros condutores, fios impressos, ou elementos de transferência possam ser utilizados, como dito anteriormente. O sinal de estrobo (ST3) é transportado através de um link unidirecional que é acionado somente pelo hospedeiro. 0 sinal de estrobo alterna valor (0 ou 1) que sempre que houver um estado back-to-back, 0 permaneça igual no sinal ou linha de Dados.
Um exemplo de como uma seqüência de dados como bits 1110001011 pode ser transmitida utilizando codificação DADOS-STB c mostrado em forma gráfica na figura 40. Na figura 40, um sinal DADOS 4002 é mostrado na linha superior de um gráfico de temporização de sinais e um sinal STB 4004 é mostrado em uma segunda linha, cada tempo alinhado como apropriado (ponto de partida comum). À medida
91/161 que o tempo passa, quando há alteração de estado ocorrendo na linha DADOS 4002 (sinal) então a linha STB 4004 (sinai) mantém um estado anterior, desse modo, o primeiro estado '1' do sinal DADOS correlaciona com o primeiro estado '0' para o sinal STB, seu valor de partida. Entretanto, se ou quando o estado, nível, do sinal DADOS não mudar então o sinal STB alterna para o estado oposto ou '1' no presente exemplo, como é o caso na figura 40 onde DADOS está fornecendo outro valor '1'. Isto é, há uma e somente uma transição por ciclo de bit entre DADOS e STB. Portanto, o sinal STB faz transição novamente, dessa vez para '0' à medida que o sinal DADOS permanece em '1' e mantém esse nível ou valer à medida que o sinal DADOS muda o nível para '0' . Quando o sinal DADOS permanece em '1', o sinal STB alterna para o estado oposto ou '1' no presente exemplo, e assim por diante, à medida que o sinal DADOS muda ou mantém os níveis ou valores.
Após rcccbcr esses sinais, uma operação ORexclusiva (XOR) é executada nos sinais DADOS e STB para produzir um sinal de relógio 4006, que é mostrado na parte inferior do gráfico de temporização para comparação relativa com os sinais de dados e estrobo desejados. Um exemplo de conjunto de circuitos útil para gerar as saídas de DADOS e STB ou sinais dos dados de entrada no hospedeiro, e então recuperar ou recapturar os dados dos sinais DADOS e STB no cliente, é mostrado na figura 41.
Na figura 41, uma porção de transmissão 4100 é utilizada para gerar e transmitir os sinais DADOS e STB originais através de um percurso de sinal intermediário 4102, enquanto uma porção de recepção 4120 é utilizada para receber os sinais e recuperar os dados. Como mostrado na figura 41, a fim de transferir dados de um hospedeiro para um cliente, o sinal DADOS é entrado em dois elementos de
92/161
Figure BRPI0410885B1_D0012
circuito flip-flop tipo D, 4104 e 4106 juntamente com um sinal de relógio para disparar os circuitos. As duas saídas de circuito fiip-flop (Q) são então divididas em um par diferencial de sinais MDDI_Data0-u, MDDI_Data0-, e MDDI_Stb4, MDDI_Stb-, respectivamente, utilizando dois drivers de linha de diferencial 4108 e 4110 (modo de tensão). Um elemento lógico, circuito ou porta NORexclusiva (XNOR) 4112 é conectado para receber DADOS e saídas dos dois flip-flops, e gera uma saída que provê a entrada de dados para o segundo fiip-flop, que por sua vez gera os sinais MDDI_Stb-*-, MDDI_Stb-. Por conveniência, a porta XNOR tem a bolha de inversão colocada para indicar que está invertendo eficazmente a saída Q do flip-flop gue gera o Estrobo.
Na porção de recepção 4120 da figura 41, os sinais MDDI_Data0+, MDDI_Data0- e MDDI_Stb+, MDDI_Stb- são recebidos por cada um dos dois receptores de linha de diferencial 4122 e 4124, que geram saídas individuais dos sinais de diferencial. As saídas dos amplificadores sâo então entradas em cada uma das entradas de um elemento lógico, circuito ou porta OR-exclusiva (XOR) de duas entradas, 4126, que produz o sinal de relógio. O sinal de relógio é utilizado para disparar cada um dos dois circuitos de flip-flop tipo D 4128 e 4130 que recebem uma versão retardada do sinal DADOS, através do elemento de retardo 4132, um dos quais (4128) gera valores '0' de dados e o outro (4130) valores '1' de dados. O relógio tem uma saída independente da lógica XOR também. Uma vez que as informações de relógio são distribuídas entre as linhas DADOS e STB, nenhum sinal faz transição entre estados mais rápido do que metade da taxa do relógio. Uma vez que o relógio é reproduzido utilizando o processamento ORexclusivo dos sinais de DADOS e STB, o sistema tolera
93/161 eficazmente duas vezes a quantidade de distorção entre os dados de entrada e relógio em comparação com a situação quando um sinal de relógio é enviado diretamente através de uma única linha de dados dedicada.
Os pares de MDDI Data, sinais MDDI_Stb+ e MDDI_Stb- são operados em um modo diferencial para maximizar imunidade dos efeitos negativos de ruído. Cada porção do percurso de sinal diferencial é terminada em fonte com metade da impedância característica do cabo ou condutor sendo utilizado para transferir sinais. Pares de MDDI_Data são terminados em fonte nas extremidades tanto de hospedeiro como de cliente. Uma vez que somente um desses dois drivers está ativo em um determinado momento, existe continuamente uma terminação na fonte para o link de transferência. Os sinais MDDI_Stb+ e MDDI_Stb- são somente acionados pelo hospedeiro.
Uma configuração exemplar de elementos úteis para obter os drivers, receptores e terminações para transferir sinais como parte da interface de MDD inventivo é mostrada na figura 42, enquanto especificações elétricas de CC correspondentes de MDDI_Data e MDDI_3tb são mostradas na Tabela VII. Essa interface exemplar utiliza percepção de baixa tensão, aqui 200 mV, com oscilações de energia menores do que 1 volt e dreno dc baixa energia.
Tabela VII
Parâmetro Descrição Min. Tip. Máx. Unida- des
R,_.... .. Terminação de Série 41,3 42,2 43,0 Ohms
R Terminação de polarização dc Estado de Hibernação 8 10 12 K-Ohms
V * ·; i .. a , α Tensão de circuito aberto de Estado de Hibernação 0, 5 2,8 V
94/161
V:.i Faixa permissivel de tensão de saída de driver com relação a GND 0 2,8 V
V , . Tensão alta de saída de diferencial de driver 0, 5 V
V Tensão baixa de saída de diferencial de driver -0,5 V
Vl;. Tensão limiar alta de entrada de diferencial de receptor 10 mV
V . Tensão limiar baixa de entrada de diferencial de receptor -10 mV
V: Faixa permissivel de tensão de entrada de receptor com relação a GND 0 3,0 V
Γ, Corrente de vazamento de entrada (excluindo polarização de hibernação) -25 25 μΑ
As características e parâmetros elétricos dos receptores de linha e drivers de linha de diferencial sâo descritos na Tabela VIII. Funcionalmente, o driver transfere o nível lógico na entrada diretamente para uma saída positiva, e o reverso da entrada para uma saída negativa. 0 retardo de entraaa para saídas é bem correspondido com a linha de diferencial que é acionada de modo diferencial. Na maioria das implementações, a oscilação de tensão nas saídas é menor do gue a oscilação na entrada para minimizar consumo de energia e emissões eletromagnéticas. A Tabela VIII apresenta uma oscilação de tensão mínima em torno de 0,5V. Entretanto, outros valores podem ser utilizados, como sabido por aqueles
95/161 versados na técnica, e os inventores consideram um valor menor em algumas modalidades, dependendo de limitações de projeto.
Os receptores de linha de diferencial têm a mesma característica que um comparador de tensão em alta velocidade. Na figura 41, a entrada sem a bolha é a entrada positiva e a entrada com a bolha é a entrada negativa. A saída é um lógico se: (Ventrada+) (Ventrada-) for maior do que zero. Outro modo para descrever isto é um amplificador de diferencial com ganho muito grande (virtualmente infinito) com a saída limitada nos níveis de tensão lógicos 0 e 1.
A distorção (skew) de retardo entre pares diferentes deve ser minimizada para operar o sistema de transmissão de diferencial na velocidade potencial mais alta.
Na figura 42, um controlador de hospedeiro 4202 e um controlador de display ou cliente 4204 são mostrados transferindo pacotes através do link de comunicação 4206. O controlador de hospedeiro emprega uma série de três drivers 4210, 4212 e 4214 para receber os sinais DADOS e STB de hospedeiro a serem transferidos, bem como para receber os sinais de Dados de cliente a serem transferidos. O driver responsável pela passagem de DADOS de hospedeiro emprega uma entrada de sinal de habilitação para permitir ativação do link de comunicação geralmente somente quando se deseja transferência do hospedeiro para o cliente. Uma vez que o sinal STB é formado como parte da transferência de dados, nenhum sinal de habilitação adicional é empregado para aquele driver (4212). As saídas de cada um dos drivers de DADOS e STB são conectadas a resistores ou impedâncias de terminação 4216a, 4216b, 4216c e 4216d, respectivamente.
96/161
Resistores de terminação 4216a e 4216b também atuarão como impedâncias na entrada do receptor do lado de cliente 4230 para o processamento de sinais de STB enquanto resistores de terminação adicionais 4216e e 4216f são colocados em série com resistores 4216c e 4216d, respectivamente na entrada do receptor de processamento de dados de cliente 4232. Um sexto driver 4234 no controlador de cliente é utilizado para preparar os sinais de dados sendo transferidos do cliente para o hospedeiro, onde o driver 4214, através dos resistores de terminação 4216c e 4216d, no lado de entrada, processa os dados para transferir para o hospedeiro para processamento.
Dois resistores adicionais 4218a e 4218b são colocados entre os resistores de terminação e terra e uma fonte de tensão 4220, respectivamente, como parte do controle de hibernação discutido em outro lugar. A fonte de tensão é utilizada para acionar as linhas de transferência para os níveis alto ou baixo previamente discutidos para gerenciar o fluxo de dados.
Os drivers e impedâncias acima podem ser formados como componentes distintos ou como parte de um módulo de circuito, ou um circuito integrado de aplicação específica (ASIC) gue atua como uma solução de codificador ou decodificador mais eficaz em termos de custo.
Pode ser facilmente visto que a energia é transferida para o dispositivo cliente, ou display, proveniente do dispositivo hospedeiro utilizando os sinais
rotulados MDDI Pwr e MDDI_Gnd através de um pa r de
condutores. A porção de MDDI_Gnd do sinal a Lua como terra
de referência e o sinal ou percurso de retorno de
fornecimento de energia para o dispositivo de display. 0
sinal MDDI Pwr atua como o fornecimento de energia de
dispositivo de display que é acionado pelo dispositivo
97/161 hospedeiro. Em uma configuração exemplar, para aplicações de baixa energia, permite-se que o dispositivo de display puxe até 500 mA. O sinal MDDl_Pwr pode ser fornecido das fontes de energia portáteis, como porém não limitados a, uma bateria do tipo de ion-lítio ou grupo de bateria localizado no dispositivo hospedeiro, e pode variar de 3,2 a 4,3 volts com relação a MDDI_Gnd.
VII. Características de Temporização
Λ. Visão Geral
As etapas e níveis de sinal empregados por um cliente para assegurar serviço do hospedeiro e pelo hospedeiro para fornecer esse serviço, são ilustrados na figura 43. Na figura 43, a primeira parte dos sinais sendo ilustrada mostra um Pacote de Desligamento de Link sendo transferido do hospedeiro e a linha de dados é então acionada para um estado de lógica zero utilizando o circuito de polarização de impedância alta. Nenhum dado está sendo transmitido pelo display de cliente ou hospedeiro, que tem seu driver desabilitado. Uma série de pulsos de estrobo para a linha de sinal MDDI_Stb pode ser vista na parte inferior, uma vez que MDDI_Stb está ativo durante o Pacote de Desligamento de Link. Após esse pacote terminar e o nível lógico mudar para zero à medida que o hospedeiro aciona o circuito de polarização e lógica para zero, a linha de sinal MDDI_Stb muda também para um nível zero. Isto representa a terminação da última transferência de sinal ou serviço do hospedeiro, e poderia ter ocorrido a qualquer momento no passado, e está incluído para mostrar a cessação prévia de serviço, e o estado dos sinais antes do início do serviço. Se desejado, tal sinal pode ser enviado apenas para redefinir o link de comunicação para o estado adequado sem uma comunicação prévia 'conhecida' ter sido feita por esse dispositivo hospedeiro.
98/161
Como mostrado na figura 43, o sinal transmitido do cliente é inicialmente definido em um nível lógico zero. Em outras palavras, a saída do cliente está em uma impedância alta, e o driver é desabilitado. Quando serviço está sendo solicitado, o cliente habilita seu driver e envia uma solicitação de serviço para o hospedeiro, que é um período de tempo, designado tserviço, duranre o qual a linha é acionada para um nível lógico um. Um certo período de tempo passa então ou pode ser necessário antes do hospedeiro detectar a solicitação, denominado thospedeirodetecçâo, após o que o hospedeiro responder com uma sequência de inicialização de link, pelo acionamento do sinal para um nível lógico um. Nesse ponto, o cliente nega a solicitação, e desabilita o driver de solicitação de serviço de modo que a linha de saída do cliente vai novamente para um nível lógico zero. Durante esse tempo, o sinal MDDI_Stb está em um nível lógico zero.
hospedeiro aciona a saída de dados de hospedeiro no nível '1' por um período denominado treir.ício-alto, após o que o hospedeiro aciona o nível lógico para zero e ativa MDDi_Stb por um período denominado treinício-baixo, após o que o primeiro tráfego direto começa com um Pacote de Cabeçalho de Subquadro, e os pacotes de tráfego direto são então transferidos. O sinal MDDI_Stb é ativo durante o período treinício-baixo e o Pacote de Cabeçalho de Subquadro subsequente.
A Tabela VIII mostra tempos representativos para a extensão dos diversos períodos discutidos acima, e a reiaçào para taxas de dados mínima e máxima exemplares, onde:
tbit —
Taxa_Dados_Lir.k
99/161
Tabela VIII
Parâmetro Descrição Min. Tip. Máx. Unida- des
t=.. ... Duração de pulso de solicitação de serviço de display 60 70 80 ps
t ic- jj Duração de pulso alto de reinicio de link de hospedeiro 140 150 160 ps
t„ i- - 1 . Duração de pulso baixo de reinicio de link de hospedeiro 40 50 60 ps
t. , ... a - : Tempo para o display detectar sequência de reinicio de link 1 50 ps
t . .·;·,· 1 . - - ’.· * · ·· n- Tempo para o hospedeiro detectar pulso de solicitação de serviço 1 50 ps
l/t^-r:-- Taxa de dados de link para um dispositivo de desempenho mínimo 0,001 1 Mbps
1/t,.. U’ --rc' Ti·.·. Faixa máxima de taxa de dados de link para um dispositivo 0,001 450 Mbps
Taxa de dados de link reverso 0,0005 50 Mbps
t, ; . Período de um bit de dados de link direto 2,2 10' ns
Aqueles versados na técnica facilmente compreenderão que as funções dos elementos individuais ilustrados nas figuras 41 e 42 são bem conhecidas, e a função dos elementos na figura 42 é confirmada pelo diagrama de temporização na figura 43. Os detalhes sobre as
100/161 terminações em série e os resistores de hibernação que são mostrados na figura 42 foram omitidos da figura 41 porque essas informações são desnecessárias para uma descrição sobre como executar a codificação de Estrobo-Dados e recuperar o relógio da mesma.
B. Link Direto de Temporização de Estrobo-Dados As características de comutação para a transferência de dados no link direto da saída de driver de hospedeiro são mostradas na Tabela IX. A Tabela IX apresenta uma forma tabular dos tempos mínimo e máximo desejados, versus típicos para que ocorram certas transições de sinais. Por exemplo, o período de tempo típico para que ocorra uma transição do início ao término de um valor de dados (saída de um '0' ou '1'), uma transição de DataO para DataO, denominada tt.d<i- hospedeiro-saida t é t-bi- enquanto o tempo mínimo é aproximadamente ttbii.-0,5 ns, e o máximo é aproximadamente trbit+0/5 ns. O espaçamento relativo entre transições no DataO, outras linhas de dados (DataX), e as linhas de estrobo (Stb), é ilustrado na figura 44 onde as transições DataO para Estrobo, Estrobo para Estrobo, Estrobo para DataO, DataO para não-DataO, não-DataO para não-DataO, não DataO para Estrobo, e Estrobo para não-DataO são mostradas, que são mencionadas como ttds'hospedeirc-Faida » tts·.1-'hospedeiro-saida > , ttsj— ( hospedei ro — Sa í da ) , tr dd::-' hospede. ro-sa:.da ’ / ttdxdx- (hospedeiro-satda) , t tdxs- ;hospedeiro-salda , 6 t-sdx-1hospede·.ro-saida' > respectivamente.
Tabela IX
Parâmetro Descrição Min. Tip. Màx. Uni- da- des
t - · ,,.·.. Transição de DataO para DataO t'Ci· t-t .· t·,.' · , ns
101/161
Figure BRPI0410885B1_D0013
t JS- :.:v·· 3·-' - * n 1 . Transição de DataO para Estrobo f t-rir t-r.- - . ns
t. ;- - ; ir Transição de Estrobo para Estrobo t-f .· t-r.·. ns
t-s,. Ig Transição de Estrobo para DataO t f l» ; , w t-.ci; t-rir . , ns
t: ÍX - ' -1 .· » i .3 '· Transição de DataO para não- DataO ns
t.,.1,- Transição não- DataO para não- DataO 11 bi: t ’, t-r.,. t-,ci · ♦ · . ’ ns
t-1,.5- íf- i~l: - .<>; t.· Transição de nâo- DataO para Estrobo t-c·.- ns
t·-;.- zt» l· . t ” Transição de Estrobo para não- DataO tU: ns
As exigências típicas de temporização de MDDI para a entrada de receptor de cliente para os mesmos sinais de transferência de dados no link direto são mostradas na
Tabela X. Uma vez que os mesmos sinais estão sendo discutidos porém retardados em tempo, nenhuma figura nova é necessária para ilustrar as características de sinal ou significado dos rótulos respectivos, como seria entendido por aqueles versados na técnica.
Tabela X
Parâmetro Descrição Min. Tip. Máx. Uni- dades
ay- Transição DataO para DataO t-.,;, - 1,0 t-r.;· t,, - + 1,0 ns
102/161
Figure BRPI0410885B1_D0014
t- -?r. - r«dú Transição de DataO para Estrobo t,s·.. - 1,5 t-f·· f t-c.. + 1,5 ns
t. .... , • rui/ Transição de Estrobo para Estrobo t·,. -1,0 t i t,çl, + 1,0 ns
t· • T. · . 4 . Transição de Estrobo para DataO 11.1 ; i — 1,5 t-r,l· t-.tí· + I > 5 ns
t. • ..,-t-.· : i . Transição de DataO para não- DataO trt.- ns
t-1 í - Transição de não-DataO para não-DataO t rl. ns
t- :b :*·>·': • , í . * Transição de não-DataO para Estrobo t-r:· ns
t-.: ·. : ♦. i t : . 1 - Transição de Estrobo para não-DataO t,r, ns
As figuras 45 e 46 ilustram a presença de um retardo na resposta que pode ocorrer quando o hospedeiro desabiiita ou habilita o driver hospedeiro, respectivamente. No caso de um hospedeiro que envia certos pacotes, como o Pacote de Encapsulamento de Link Reverso ou o Pacote de Medição de Retardo de Ida e Volta, o hospedeiro desabiiita o driver de linha após envio dos pacotes desejados, como os pacotes de CRC de Parâmetro, Alinhamento de Estrobo e Todos Zero ilustrados na figura 45 como tendo sido transferidos. Entretanto, como mostrado na figura 45, o estado da linha não desloca necessariamente de '0' para um valor mais elevado desejado instantaneamente, embora isso seja potencialmente obtenível com certo controle ou
103/161 elementos de circuitos presentes, porém demora um período de tempo denominado o período de Retardo de Desabilitação de Driver hospedeiro para responder. Embora poderia ocorrer virtualmente instantaneamente de tal modo que esse período de tempo seja 0 nanossegundos (ns) em extensão, poderia estender-se mais facilmente sobre algum período mais longo com 10 ns segundo uma extensão de período máximo desejado, gue ocone duranLe os períodos de pacote de Tempo de Guarda 1 ou Reversão de Sentido 1.
Observando a figura 46, observa-se a alteração de nível de sinal realizada guando c Driver hospedeiro é habilitado para transferir um pacote como o Pacote de Encapsulamento de Link Reverso ou Pacote de Medição de Retardo de Ida e Volta. Aqui, após os períodos de pacote de Tempo de Guarda 2 ou Reversão de Sentido 2, o driver hospedeiro é habilitado e começa a acionar um nível, aqui '0' , cujo valor é aproximado ou atingido durante um período de tempo denominado o período de Retardo de Habilitar Driver Hospedeiro, que ocorre durante o período de Reabilitar Driver, antes do envio do primeiro pacote.
Um processo similar ocorre para os drivers e transferências de sinais para o dispositivo cliente, aqui um display. As diretrizes gerais para a extensão desses períodos, e suas respectivas relações são mostradas na Tabela XI abaixo.
Tabela XI
Descrição Min. Máx. Unidades
Retardo de Desabilitar Driver Hospedeiro 0 10 ns
Retardo de Habilitar Driver Hospedeiro 0 2,0 ns
Retardo de Desabilitar Driver de display 0 10 ns
104/161
3#
Retardo de Habilitar Driver de 0 2,0 I ns
display
C. Link Reverso de Temporização de Dados-Estrobo
As características de comutação e relações de temporização para os sinais de dados e estrobo utilizados para transferir dados no link reverso da saída de driver de cliente são mostradas ns figuras 47 e 48. Os tempos típicos para certas transições de sinais são discutidos abaixo. A figura 47 ilustra a relação na entrada de receptor de hospedeiro entre a temporização dos dados sendo transferidos e as bordas dianteira e traseira dos pulsos de estrobo. Isto é, o que é referido como o tempo de configuração para a borda de subida ou dianteira dos sinais de estrobo, tsu.sr e o tempo de configuração para a borda traseira ou de descida dos sinais de estrobo, t^^-sf. Uma extensão de tempo típica para esses períodos de configuração é da ordem de um mínimo de 8 nanossegundos.
A figura 48 ilustra as características de comutação e retardo de saída de cliente correspondente desenvolvidos pela temporização de dados reversos. Na figura 48, pode-se ver a relação entre a temporização dos
2C dados sendo transferidos e as bordas dianteira e traseira dos pulsos de estrobo respondendo por retardo induzido. Isto é, o que é referido como o retardo de propagação entre a borda dianteira ou de subida dos sinais de estrobo e os dados (válidos), tpd.sr, e o retardo de propagação entre os dados e a borda traseira cu de descida dos sinais de estrobo, tpcj-Sf· Uma extensão de tempo máxima, típica para esses períodos de retardo de propagação é da ordem 8 nanossegundos.
VIII. Implementação do Controle de Link (Operação de
Controlador de Link)
A. Processador de Pacote de Máquina de Estado
105/161
3/>
Os pacotes sendo transferidos através de um link de MDDI são despachados muito rapidamente, tipicamente em uma taxa da ordem de 300 Mbps ou maior, como 4 00 Mbps, embora taxas mais baixas sejam certamente acomodadas, como desejado. Esse tipo de velocidade de link de transferência ou barramento é demasiadamente grande para controle por microprocessadores de finalidade geral atualmente disponíveis comercialmente (econômicos) ou similares. Portanto, uma implementação prática para realizar esse tipo de transferência de sinais é utilizar uma máquina de estado programável para analisar o fluxo de pacote de entrada a fim de produzir pacotes que são transferidos ou redirecionados para o subsistema audiovisual apropriado para o qual são destinados. Tais dispositivos são bem conhecidos e utilizam circuitos geraimente dedicados a um número limitado de operações, funções, ou estados a fim de obter uma operação de velocidade muito alta ou velocidade alta desejada.
Controladores de finalidade geral, processadores ou elementos de processamento podem ser utilizados para mais apropriadamente influenciar ou manipular algumas informações como pacotes de estado ou controle, que têm demandas de velocidade mais baixa. Quando aqueles pacotes (controle, estado ou outros pacotes predefinidos) são recebidos, a máquina de estado deve passar os mesmos através de um buffer de dados ou elemento de processamento similar para o processador de finalidade geral de modo que os pacotes possam ser influenciados a fim de fornecer um resultado (efeito) desejado enquanto cs pacotes de áudio e visual são transferidos para seu destino apropriado para ação. Se microprocessadores ou outros controladores de finalidade geral, processadores ou elementos de processamento futuros forem fabricados para obter
373
106/161 capacidades de processamento de taxa mais alta de dados, então os estados ou máquina de estado discutidos abaixo poderiam também ser implementados utilizando controle de software desses dispositivos, tipicamente como programas armazenados em um elemento ou mídia de armazenagem.
A função de processador de finalidade geral pode ser realizada em algumas modalidades tirando proveito da potência de processamento ou ciclos em excesso disponíveis para microprocessadores (CPUs) em aplicações de computador, ou controladores, processadores, processadores de sinais digitais (DSPs), circuitos especializados, ou ASICs encontrados em dispositivos sem fio, do mesmo modo .que alguns modems ou processadores gráficos utilizam a potência de processamento de CPUs encontrados em computadores para executar algumas funções e reduzir custos e complexidade de hardware. Entretanto, essa utilização ou compartilhamento de ciclos pode impactar negativamente a velocidade de processamento, temporização ou operação elementos, então em muitas aplicações, elementos dedicados são preferidos para esse processamento geral.
geral desses circuites ou
Para que os dados de imagem sejam visualizados em um display (micro-display) , ou recebam de forma segura todos os pacotes enviados pelo dispositivo hospedeiro, o processamento de sinal de display é sincronizado com a temporização de canais de link direto. Isto é, os sinais gue chegam no display e circuitos de display necessitam ser substancialmente sincronizados em tempo para que ocorra processamento apropriado de sinais. Um diagrama de estados de alto nível obtido pelas etapas de processamento de sinais ou um método pelo qual essa sincronização possa ser implementada é apresentado na ilustração da figura 49. Na figura 49, os possíveis estados de sincronização de link
Figure BRPI0410885B1_D0015
107/161 direto para uma máquina de estado 4900 são mostrados sendo categorizados como um ESTADO DE QUADROS ASSÍNCRONOS 4904, dois ESTADOS DE AQUISIÇÃO DE SINCRONIZAÇÃO 4902 e 4906, e três ESTADOS EM SINCRONIZAÇÃO 4908, 4910 e 4912.
Como mostrado pela etapa inicial ou estado 4902, o display ou cliente, como um dispositivo de apresentação, inicia em um estado sem sincronização pré-selecionado, e busca uma palavra exclusiva no primeiro pacote de cabeçalho de subquadro que é detectado. Deve ser observado que esse estado Sem Sincronização representa o ajuste de comunicação mínima ou ajuste de retroceder (fall-back) no qual uma interface do Tipo 1 é selecionada. Quando a palavra exclusiva é encontrada durante a busca, o display salva o campo de comprimento de subquadro. Não há verificação dos bits de CRC em relação a processamento nesse primeiro quadro, ou até obtenção de sincronização. Se esse comprimento de subquadro for zero, então o processamento de estado de sincronização prossegue de acordo até um estado 4904 rotulado aqui como o estado Quadros Assíncronos que indica que a sincronização não foi ainda obtida. Essa etapa no processamento é rotulada como tendo encontrado cond 3, ou condição 3, na figura 49. De outro modo, se o comprimento de quadro for maior do que zero, então o processamento de estado de sincronização prossegue para um estado 4906 onde o estado de interface é definido como Encontrou Um Quadro De Sincronização Essa etapa no processamento é rotulada como encontrando cond 5, ou condição 5, na figura 49. Além disso, se a máquina de estado vê um pacote de cabeçalho de quadro e boa determinação de CRC para um comprimento de quadro maior do que zero, o processamento prossegue para o estado Encontrou Um Quadro De Sincronização. Isto é rotulado como encontrando cond 6 ou condição 6, na figura 49.
Figure BRPI0410885B1_D0016
108/161
Em cada situação na qual o sistema está em um estado diferente de sem sincronização, quando a palavra exclusiva é detectada e um bom resultado de CRC é determinado para o pacote de cabeçalho de subquadro, e o comprimento de subquadro é maior do que zero, então o estado de interface é mudado para o estado em sincronização 4908. Essa etapa no processamento é rotulada como tendo encontrado cond 1, ou condição 1, na figura 49. Por outro lado, se a palavra exclusiva ou o CRC no Pacote de Cabeçalho de Subquadro não estiver correto, então o processamento de estado de sincronização prossegue ou retorna ao estado de interface 4902 do estado QUADRO SEM SINCRONIZAÇÃO. Essa porção do processamento é rotulada como encontrando cond 2 ou condição 2, no diagrama de estado da figura 49.
B. Tempo de Aquisição Para Sincronização
A interface pode ser configurada para acomodar um certo número de erros de sincronização antes de decidir que a sincronização é perdida e retornar ao estado QUADRO SEM SINCRONIZAÇÃO. Na figura 49, após a máquina de estado ter atingido ESTADO EM SINCRONIZAÇÃO e nenhum erro ser encontrado, está encontrando continuamente um resultado de cond 1, e permanece no estado EM SINCRONIZAÇÃO. Entretanto após detectar um resultado de cond 2, o processamento muda o estado para um estado um erro de sincronização 4910. Nesse ponto, se o processamento resultar em detecção de outro resultado de cond 1, er.tào a máquina de estado retorna para o estado em sincronização, de outro modo encontra outro resultado de cond 2, e se move para um. estado DOIS ERROS DE SINCRONIZAÇÃO 4912. Novam.ente, se ocorrer uma cond 1, o processamento retorna a máquina de estado para o estado EM SINCRONIZAÇÃO. De outro modo, outra cond 2 é encontrada e a máquina de estado
Figure BRPI0410885B1_D0017
109/161 retorna para o estado sem sincronização. Também é compreensível que caso a interface encontre um pacote de desligamento de link, então isto fará com que o link termine as transferências de dados e retorne para o estado quadro sem sincronização visto que não nada para sincronizar, que é mencionado como encontrando a cond 4 ou condição 4, no diagrama de estado da figura 49.
É entendido que é possível que haja uma falsa cópia de repetição da palavra exclusiva que pode aparecer em algum local fixo no subquadro. Nessa situação, é muito improvável que a máquina de estado sincronize com o subquadro porque o CRC no Pacote de Cabeçalho de Subquadro deve ser também válido quando processado para que o processamento de interface de MDD prossiga para o estado EM SINCRONIZAÇÃO.
O comprimento de subquadro no Pacote de Cabeçalho de Subquadro pode ser definido em zero para indicar que o hospedeiro transmitirá somente um subquadro antes do link ser desligado, e a interface de MDD é colocada em ou configurada em um estado ocioso de hibernação. Nesse caso, o display deve receber imediatamente pacotes através do link direto após detectar o Pacote de Cabeçalho de Subquadro porque somente um único subquadro é enviado antes que o link faça transição para o estado ocioso. Em operações normais ou típicas, o comprimento de subquadro é nâo zero e o display processa somente pacotes de link direto enquanto a interface está naqueles estados coletivamente mostrados como estados EM SINCRONIZAÇÃO na figura 49.
O tempo necessário para que um display sincronize com o sinal de link direto é variável dependendo do tamanho de subquadro e da taxa de dados de link direto. A probabilidade de detectar uma falsa cópia da palavra
110/161
37Λ exclusiva como parte dos dados aleatórios ou mais aleatórios no link direto é maior do que quando o tamanho do subquadro é maior. Ao mesmo tempo, a capacidade de recuperar de uma detecção falsa é inferior, e o tempo que demora para fazer isso é mais longo, quando uma taxa de dados de link direto é mais lenta.
C. Inicialização
Como dito anteriormente, no momento de início, o hospedeiro configura o link direto para operar em ou abaixo de uma taxa de dados mínima exigida, ou desejada, de 1 Mbps, e configura o comprimento de subquadro e taxa de quadro de mídias apropriadamente para uma dada aplicação. Tsto é, os links tanto direto quanto reverso começam a operação utilizando a interface do Tipo I. Esses parâmetros serão geralmente somente para ser utilizados temporariamente enquanto o hospedeiro determina a capacidade ou configuração desejada para o display de cliente (ou outro tipo de dispositivo cliente). O hospedeiro envia ou transfere um Pacote de Cabeçalho de subquadro através do link direto seguido por um Pacote de Encapsulamento de Link Reverso que tem bit '0' dos Elags de Solicitação definido para um valor de um (1), a fim de solicitar que o display ou cliente responda com um Pacote de Capacidade de Display. Após o display adquirir sincronização em (ou com) o link direto, envia um Pacote de Capacidade de Display e um Pacote de Status e Solicitação de Display através do canal ou link reverso.
hospedeiro examina o conteúdo do Pacote de Capacidade de Display a fim de determinar como reconfigurar o link para nível de desempenho ótimo ou desejado. 0 hospedeiro examina os campos de Versão de protocolo e Versão de Protocolo mínimo para confirmar que o hospedeiro e display utilizam versões do protocolo que são compatíveis
111/161
W entre si. As versões de protocolo permanecem geraimente como os dois primeiros parâmetros do Pacote de Capacidade de Dispiay de modc que a compatibilidade possa ser determinada mesmo quando outros elementos do protocolo poderíam não ser compatíveis ou tctalmente compreendidos como sendo compatíveis.
D. Processamento de CRC
Para todos os tipos de pacotes, a máquina de estado do processador de pacotes assegura que o verificador de CRC é controlado de forma apropriada ou adequada. Também incrementa um contador de erro de CRC quando uma comparação de CRC resulta em detecção de um ou mais erros, e reajusta o contador de CRC no início de cada subquadro sendo processado.
E. Perda Alternativa de Verificação de Sincronização
Embora a série de etapas ou estados acima funcione para produzir taxas de dados mais altas ou velocidade de capacidade de transmissão, os Requerentes descobriram que um arranjo alternativo ou alteração nas condições que o cliente utiliza para declarar que há perda de sincronização com o hospedeiro, pode ser utilizado de forma eficaz para obter capacidade de transmissão ou taxas de dados ainda mais altas. A nova modalidade inventiva tem a mesma estrutura básica, porém com as condições para mudar estados alterados. Adicionalmente um novo contador é implementado para auxiliar a fazer verificações para sincronização de subquadro. Essas etapas e condições são apresentadas em relação à figura 63, que ilustra uma série de estados e condições úteis para estabelecer as operações do método ou máquina de estado. Somente as porções ESTADO DE AQUISIÇÃO DE SINCRONIZAÇÃO e ESTADOS EM SINCRONIZAÇÃO são mostradas para clareza. Além disso, uma vez que os
112/161 resultados resultantes são substancialmente iguais, como é a própria máquina de estado, eles utilizam a mesma numeração. Entretanto, as condições para alterar estados (e a operação de máquina de estado) variam de um certo modo, de modo que todos sejam renumerados para clareza entre as duas figuras (1, 2, 3, 4, 5, e 6, versus 61, 62, 63, 64 e 65) como conveniência na identificação de diferenças. Uma vez que o estado QUADRO ASSÍNCRONO não é considerado nessa discussão, um estado (4904) e condição (6) não mais são utilizados na figura.
Na figura 63, o sistema ou cliente (para display ou apresentação) inicia com a máquina de estado 5000 no estado sem sincronização pré-selecionado 4902, como na figura 49. A primeira alteração de estado para alterar estados da condição sem sincronização 4902 está na condição 64 que é a descoberta do padrão de sincronização Considerando que o CRC do cabeçalho de subquadro também passe nesse pacote (atenda a condição 61), o estado da máquina de estado de processador de pacote pode ser alterado para o estado em sincronização 4908. Um erro de sincronização, condição 62, fará com que a máquina de estado comute para o estado 4910, e uma segunda ocorrência para o estado 4912. Entretanto, foi descoberto que qualquer falha de CRC de um pacote MDDI fará com que a máquina de estado se mova para fora do estado em sincronização 4908, para o estado de um erro de sincronização 4910. Outra falha de CRC de qualquer pacote MDDI causará um deslocamento para o estado de duas falhas de sincronização 4912. Um pacote decodificado com um valor de CRC correto fará com que a máquina de estado retorne para o estado em sincronização 4908.
O que foi alterado é a utilização do valor de CRC ou determinação para 'todo' pacote. Isto é, fazer com que a
Figure BRPI0410885B1_D0018
113/161 máquina de estado olhe o valor de CRC para todo pacote a fim de determinar uma perda de sincronização em vez de apenas observar pacotes de cabeçalho de subquadro. Nessa configuração ou processo, uma perda de sincronização não é determinada utilizando a palavra exclusiva e apenas valores de CRC de cabeçalho de subquadro.
Essa nova implementação de interface permite que o link de interface de MDD reconheça falhas de sincronização muito mais rapidamente, e, portanto, se recupere também muito rapidamente das mesmas.
Para tornar esse sistema mais robusto, o cliente também deve acrescentar ou utilizar um contador de subquadros. C cliente verifica então em relação à presença da palavra exclusiva no tempo em que espera chegar ou ocorrer em um sinal. Se a palavra exclusiva não ocorrer no tempo correto, o cliente pode reconhecer que uma falha de sincronização ocorreu muito mais rapidamente do que se tivesse de esperar vários (aqui três) tempos ou períodos de pacote que eram maiores do que um comprimento de subquadro. Se o teste para a palavra exclusiva indicar que ela não está presente, em outras palavras que a temporização está incorreta, então o cliente pode declarar imediatamente uma perda de sincronização de link e mover para o estado sem sincronização. O processo de verificação em relação â presença adequada de palavra exclusiva acrescenta uma condição 65 (cond 65) à máquina de estado dizendo que a palavra exclusiva está incorreta. Se for esperado que um pacote de subquadro seja recebido no cliente e não combine, o cliente poce imediatamente ir para o estado sem sincronização 4902, poupando tempo adicionai esperando por múltiplos erros de sincronização (condição 62) normalmente encontrados ao atravessar estados 4910 e 4912.
Figure BRPI0410885B1_D0019
114/161
Essa alteração utiliza um contador ou função de contagem adicional no núcleo do cliente para contar comprimento de subquadro. Em uma modalidade, uma função de contagem regressiva e a transferência de qualquer pacote que estava sendo atualmente processado é interrompida para verificar em reiaçào à palavra exclusiva de subquadro se o contador expirou. Alternativamente, o contador pode contar ascendentemente, com a contagem sendo comparada com um valor desejado específico ou máximo desejado, em cujo ponto o pacote atual é verificado. Esse processo protege o cliente contra decodificação de pacotes que sejam incorretamente recebidos no cliente com comprimentos de
Se contador de pacote extraordinariamente longos, comprimento de subquadro necessitou interromper algum outro pacote que estava sendo decodificado, uma perda de sincronização pode ser determinada uma vez que nenhum pacote deve cruzar uma fronteira de subquadro.
IX. Processamento de Pacotes
Para cada tipo de pacote discutido acima que a máquina de estado recebe, realiza uma etapa ou série de etapas de processamento específica para implementar a operação da interface. Os pacotes de link direto são geralmente processados de acordo com o processamento exemplar listado na Tabela XII abaixo.
Tabela XII
Tipo de pacote Resposta de máquina de estado do processador de pacote
Cabeçalho de Subquadro (SH) Confirma pacote bom, captura campo de comprimento de subquadro, e envia parâmetros de pacotes para um processador de finalidade geral
115/161
3Ϊ^
Preenchedor (F) Ignora dados
Fluxo de Vídeo (VS) Interpreta o Descritor de Formato de Dados de Vídeo e outros parâmetros, desempacota dados de pixel empacotados quando necessário, traduz pixels através do mapa de cores se necessário, e escreve dados de pixel em locais apropriados no mapa de bits
Fluxo de Áudio (AS) Envia definição de taxa de amostra de áudio para gerador de relógio de amostra de áudio, separa amostras de áudio de tamanho especificado, desempacota dados de amostra de áudio quando necessário, e roteia amostras de áudio para FIFO de amostra de áudio apropriado
Mapa de Cores (CM) Lê parâmetros de offset e tamanho de mapa de cores, e grava os dados de mapa de cores em um local de armazenagem ou memória de mapa de cores.
Encapsulamento de Link Reverso (REL) Facilita envio de pacotes em direção reversa no momento apropriado. Flags de link reverso são examinados, e pacotes de Capacidade de Display são enviados como necessário. Pacotes de Status e Solicitação de Display são também enviados como apropriado.
Figure BRPI0410885B1_D0020
116/161
Capacidade de Display (DC) Envia esse tipo de pacote quando solicitado por um hospedeiro utilizando o campo de flags de link reverso do Pacote de Encapsulamento de Link Reverso
Teclado (K) Passa esses pacotes para e de um processador de finalidade geral cue se comunica com um dispositivo do tipo teclado, se um estiver presente, e utilização é desejável.
Dispositivo de Apontamento (PD) Passa esses pacotes para e de um processador de finalidade gerai que se comunica com um dispositivo do tipo de apontamento, se um estiver presente, e utilização é desejável.
Desligamento de Link (LS) Registra que link de fato está desligado e informa a um processador de finalidade geral
Status e Solicitação de Serviço de Display (DSRS) Envia esse pacote como o primeiro pacote no pacote de Encapsulamento de Link Reverso.
Transferência de bloco de bits (BPT) Interpreta parâmetros de pacote, como Descritor de Formato de Dados de Video, determina quais pixels devem se mover primeiramente, e move pixels no mapa de bits conforme exigido.
Preenchimento de Área de Mapa de Sits (BAF) Interpreta parâmetros de pacote, traduz pixels através do mapa de cores se necessário,
Figure BRPI0410885B1_D0021
117/161
e grava dados de pixel em locais apropriados no mapa de bits
Prenchimento de Padrão de Mapa de Bits (BPF) Interpreta parâmetros de pacote, desempacota dados de pixel empacotados se necessário, traduz pixels através do mapa de cores se necessário, e escreve dados de pixel em locais apropriados no mapa de bits.
Canal de Link de Comunicação (CLC) Envia esses dados diretamente para um processador de finalidade geral.
Solicitação de Serviço de Display (DSR) durante hibernação 0 processador de finalidade geral controla as funções de baixo nível de enviar solicitação e detecta contenção com reinicio de link sozinho.
Solicitação de Handoff do Tipo Interface (ITHR) e Confirmação do Tipo de Interface (ITA) Pode passar esses pacotes para e do processador de finalidade geral. A lógica para receber esse tipo de pacote e formular uma resposta com uma confirmação é substancialmente mínima. Portanto, essa operação também podería ser implementada na máquina de estado do processador de pacote. A handoff resultante ocorre como uma ação de cama da física de baixo nível e não é provável de afetar a funcionalidade ou funcionamento do processador de finalidade geral.
118/161
Handoff do Tipo Execução (PTH) Pode atuar sobre esses pacotes diretamente ou pela transferência dos mesmos para o processador de finalidade geral, também comandando hardware a ser submetido a uma alteração de modo.
X. Redução da Taxa de Dados de Link Reverso
Foi observado pelos inventores que cerios parâmetros utilizados para o controlador de link de hospedeiro podem ser ajustados ou configurados em um certo modo para obter uma taxa máxima ou mais otimizada (escala) de dados de link reverso, que é muito desejável. Por exemplo, durante o tempo utilizado para transferir o campo de Pacotes de Dados reversos do Pacote de Encapsulamento de Link Reverso, o par de sinais MDDI_Stb alterna para criar um relógio de dados periódico na metade da taxa de dados de link direto. Isto ocorre porque o controlador de link de hospedeiro gera o sinal MDDI_Stb que corresponde ao sinal MDDI_DataO como se estivesse enviando todos os zeros. O sinal MDDI_Stb é transferido do hospedeiro para um cliente onde é utilizado para gerar um sinal de relógio para transferir dados de link reverso do display, com o qual dados reversos sâo enviados de volta para c hospedeiro. Uma ilustração de proporções típicas de retardo encontrado para a transferência e processamento de sinais nos percurso
direto e reverso em um sistema empregando o MDDI, é
mostrada na figura 50. Na figura 50, uma série de valores
de retardo 1,5 ns, 8,0 ns, 2,5 ns, 2,0 ns, 1,0 ns, 1,5 ns,
8,0 ns, e 2,5 ns, sâo mostrados próximo a porções de processamento para a geração de Stb+/-, cabo trar.sf erênciapara-display, receptor de display, geração de relógio, sincronização de sinais, geração de Data0+/-, cabo
Figure BRPI0410885B1_D0022
119/161 de clienteEmbora não transferência-para-hospedeiro, e estágios de receptor de hospedeiro, respectivamente.
Dependendo dos retardos de processamento de sinais e taxa de dados de link direto encontrados, pode exigir mais tempo do que um ciclo no sinal de MDDI_Stb para esse efeito de ida e volta ou conjunto de eventos ser concluído, o que resulta no consumo de proporções indesejáveis de tempo ou ciclos. Para evitar esse problema, o Divisor de Taxa Reversa torna possível para um tempo de bit no link reverso cobrir múltiplos ciclos do sinal MDDI_Stb. Isto significa que a taxa de dados de link reverso é menor do que a taxa de link direto.
Deve ser observado que o comprimento efetivo de retardos de sinais através da interface pode diferir dependendo de cada hardware ou sistema hospedeiro específico sendo utilizado, necessário, cada sistema pode ser geraimente feito para ter melhor desempenho pela utilização do Pacote de Medição de Retardo de Ida e Volta para medir o retardo efetivo em um sistema de modo que o Divisor de Taxa Reversa possa ser definido em um valor ótimo.
Um retardo de ida e volta é medido fazendo com que o hospedeiro envie um Pacote de Medição de Retardo de ida e volta para o display. 0 display responde a esse pacote enviando uma sequência de uns de volta para o hospedeiro dentro de, ou durante uma janela de medição préselecionada naquele pacote denominado campo de Período de Medição. A temporização detalhada dessa medição foi descrita anteriormente. 0 retardo de ida e volta é utilizado para determinar a taxa na qual os dados de link reverso podem ser amostrados de forma segura.
A medição de retardo de ida e volta consiste em determinar, detectar ou contar o número de intervalos de
120/161 relógio de dados de link direto que ocorrem entre o início do campo do Período de Medição e o início do período de tempo quando a seqüência de resposta Oxff, Oxff, 0x00 é recebida de voita no hospedeiro proveniente do cliente. Observe que é possível que a resposta do cliente pudesse ser recebida uma pequena fração de um período de relógio de link direto antes que a contagem de medição estivesse para incrementar. Se esse valor não modificado for utilizado para calcular o Divisor de Taxa reversa podería ocasionar erros de bit no link reverso devido à amostragem não segura de dados. Um exemplo dessa situação é ilustrado na figura 51, onde sinais que representam MDDI_Data no hospedeiro, MDDI_Stb no hospedeiro, relógio de dados de link direto dentro do hospedeiro, e uma Contagem de Retardo são ilustrados em forma gráfica. Na figura 51, a seqüência de resposta foi recebida do display uma fração de urr. período de reiógio de link direto antes que a Contagem de Retardo estivesse para aumentar de 6 para 7 . Se o retardo for considerado como sendo 6, então o hospedeiro amostrará os dados reversos logo após uma transição de bits ou possivelmente entre uma transição de bits. Isto poderia resultar em amostragem errônea no hospedeiro. Por esse motivo, o retardo medido deve ser tipicamente incrementado por um antes de ser utilizado para calcular o Divisor de Taxa Reversa.
O Divisor de Taxa reversa é o número de ciclos MDI_Stb que o hospedeiro deve esperar antes da amostragem dos dados de link reverso. Uma vez que MDDI_Stb é ciclado em uma taxa que é metade da taxa de link direto, a medição de retardo de ida e volta corrigida necessita ser dividida por 2 e então arredondada para o próximo número inteiro. Expresso como uma fórmula, essa relação é:
Figure BRPI0410885B1_D0023
121/161 divisor taxa reversa=
ArredondarParaPróximoInteiro (retardo ida e volta + I |
Para o exemplo dado, isso se torna: divisor taxa reversa=
ArredondarParaPróximoInteiro
Figure BRPI0410885B1_D0024
a =4
Se o campo de medição de retardo de ida e volta nesse exemplo fosse 7 ao contrário de 6, então o Divisor de Taxa Reversa também seria igual a 4.
Os dados de link reverso são amostrados pelo hospedeiro na borda de subida do Relógio de Link Reverso. Há um contador ou dispositivo ou circuito conhecido similar presente tanto no hospedeiro como no cliente (display) para gerar o Relógio de Link Reverso. Os contadores são inicializados de modo que a primeira borda de subida do Relógio de Link Reverso ocorra no início do primeiro bit no campo de Pacotes de Link Reverso do pacote de Encapsulamento de Link Reverso. Isto é ilustrado, para o exemplo dado abaixo, na figura 52. Os contadores incrementam em cada borda de subida do sinal de MDDI_Stb, e o número de contagens que ocorrem até que eles circulem é definido pelo parâmetro de Divisor de Taxa Reversa no Pacote de Encapsulamento de Link Reverso. Uma vez que o sinal de MDDI_Stb alterna em metade da taxa de link direto, então a taxa de link direto é metade da taxa de link direto
dividida pelo Divisor de Taxa Reversa. Por exemplo, se a
taxa de link direto for 200 Mbps e o Divisor de Taxa
Reversa for 4 então a taxa de dados de link reverso é
expressa como:
lOO.UA/zs
25Mbps
Figure BRPI0410885B1_D0025
122/161
Um exemplo que mostra a temporização das linhas de sinais MDDI_DataO e MDDI_Stb em um Pacote de Encapsulamento de Link Reverso é mostrado na figura 52, onde os parâmetros de pacote utilizados para ilustração têm os valores:
Comprimento de pacote = 0124 (x0400)
Tipo de pacote = 65 (0x41)
Flags de link reverso = 0
CRC de Parâmetro = 0xdb43
Comprimento de Reversão de Sentido 1=1
Comprimento de Reversão de Sentido 2=1
Divisor de taxa reversa = 2
Todos zero é 0x00
Dados de pacote entre os campos de Comprimento de Pacote e CRC de Parâmetro são:
0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, Oxdb, 0x00,...
O primeiro pacote de link reverso retornado do display é o Pacote de Status e Solicitação de display tendo um Comprimento de Pacote de 7 e um tipo de pacote de 70. Esse pacote começa com os valores de byte de 0x07, 0x00,
0x46, ... e assim por diante. Entretanto, somente o primeiro byte (0x07) é visível na figura 52. Esse primeiro pacote de link reverso é comutado em tempo por quase um período de relógio de link reverso na figura a fim de ilustrar um retardo de link reverso efetivo. Uma forma de onda ideal com hospedeiro zero para exibir retardo de ida e volta é mostrada como um traço de linha pontilhada.
MS byte do campo de CRC de Parâmetro é transferido, precedido pelo tipo de pacote, então o campo todos zero. 0 estrobo do hospedeiro está comutando de um para zero e de volta para um à medida que os dados dos hospedeiro mudam de nível, formando pulsos mais largos. À
123/161 medida que os dados vão para zero, o estrobo comuta na taxa mais alta, somente a alteração nos dados na linha de dados causa uma alteração próximo ao término do campo de alinhamento. 0 estrobo comuta na taxa mais alta para o restante da figura devido aos níveis 0 ou 1 fixos do sinal de dados por períodos de tempo estendidos, e as transições compreendidas no padrão de pulso (borda).
O relógio de link reverso para o hospedeiro está em zero até o final do período de Reversão de Sentido 1, quando o relógio é iniciado para acomodar os pacotes de link reverso. As setas na porção inferior da figura indicam quando os dados são amostrados, como seria evidente a partir do restante da revelação. O primeiro byte do campo de pacote sendo transferido (aqui 11000000) é mostrado começando após Reversão de Sentido 1, e o nível de linha estabilizou do driver hospedeiro sendo desabilitado. O retardo na passagem do primeiro bit, e como visto para bit três, pode ser visto nas linhas pontilhadas para o sinal de Dados.
Na figura 53, pode-se observar valores típicos do Divisor de Taxa reversa com base na taxa de dados de link direto. 0 Divisor de Taxa Reversa real é determinado como resultado de uma medição de link de ida e volta para garantir operação adequada do link reverso. Uma primeira região 5302 corresponde a uma área de operação segura, uma segunda região 5304 corresponde a uma área de desempenho marginal, enquanto uma terceira região 5306 indica ajustes que são improváveis de funcionar adequadamente.
A medição de retardo de ida e volta e ajuste de Divisor de Taxa Reversa é igual enquanto opera com quaisquer dos ajustes do Tipo de Interface no link direto ou reverso porque são expressos e operados em termos de
124/161 yü'' unidades de períodos de relógio efetivos em vez de números de bis transmitidos ou recebidos.
XI. Tempos de Guarda e Reversão de Sentido
Como discutido anteriormente, o campo de Reversão de Sentido 1 no Pacote de Encapsulamento de Link reverso e o campo de Tempo de Guarda 1 no Pacote de Medição de retardo de ida e volta designam valores para extensões de tempo gue permitem que cs drivers de interface de hospedeiro sejam desabilitados antes da habilitação dos drivers de interface de display. Os campos de Reversão de Sentido 2 e Tempo de Guarda 2 fornecem valores de tempo que permitem desabilitaçâo dos drivers de display antes da habilitação dos drivers de hospedeiro. Os campos de Tempo de Guarda 1 e Tempo de Guarda 2 são geralmente cheios de valores predefinidos ou pré-selecionados para comprimentos que nâo pretendem ser ajustados. Dependendo do hardware de interface sendo utilizado, esses valores podem ser desenvolvidos utilizando dados empíricos e ajustados em algumas instâncias para melhorar a operação.
Vários fatores contribuem para uma determinação da extensão de Reversão de Sentido 1 e esses são a taxa de dados de link direto, e o tempo de desabilitaçâo máximo des drivers de MDDI_Data no hospedeiro. O tempo de desabilitaçâo máximo de driver de hospedeiro é especificado na Tabela XI, onde mostra que os drivers demoram aproximadamente 10 ns no máximo para desabilitar e aproximadamente 2 ns para habilitar. 0 número mínimo de relógios de link direto exigido para o driver de hospedeiro a ser desabilitado é expresso de acordo com a relação:
Relógios_para_desabilitarTAi
Re tardodeDriver Hospede iroDesabiiitadOjr.a
TaxadeLinkDirelo FalorTipohtlcrface t. I( n
125/161
3/2
A faixa de valor permitido de Reversão de Sentido 1 é expressa de acordo com a relação:
Retardo ReversàodeSentido 1 > ArredondarParaPróximoInteiro
Relógios para desabilitar™. ,
-= =-FatorTipoInter facen.p) onde o Fator do tipo Interface é 1 para Tipo-1, 2 ou Tipo-II, 4 para Tipo-III e 8 para Tipo-IV.
Combinando as duas equações acima, pode-se ver que o termo de Fator de Tipo de Interface cancela e Reversão de Sentido 1 é definido como:
Retardo_ReversãodeSentido_l > ArredondarParaPróximoInteiro l' Taxaik’Diiilo.\ileLiiikDireto. Rtil(ir(/odeDriwrilospei/eiroDesahiiiíaí/omaK '
Pçr exemplo, um Mbps usaria um retardo de Retardo_ReversãodeSentido_
5ΟΟ.Λ/Λ/λ\. 10/7% >
= 2Bytes link direto do Tipo-III de 1500 Reversão de Sentido 1 de:
> ArredondarParaPróximoInteiro
À medida que o retardo de ida e volta aumenta, a margem de temporização melhora do ponto em tempo guando o hospedeiro é desabilitado para o tempo em que o display é habilitado.
Os fatores que determinam a extensão de tempo geralmente utilizado para Reversão de Sentido 2 são a taxa de dados de link direto, o tempo de desabilitar máximo dos drivers de MDDI_Data no display, e c retardo de ida e volta do link de comunicação. O cálculo do tempo necessário para desabilitar o driver de display é essencialmente igual àquele para o driver de hospedeiro discutido acima, e é definido de acordo com a relação:
126/161
3/3
Taxodcí.inkDifeto
Relógios para_desabilitarTA2 = -.
Fator Tipo h ireijí tce lin,
RetardodeDriverdeDisplayDesabilitadOrr.s;.;
e a faixa de valor permitido para Reversão de
Sentido 2 é expressa como:
Retardo_ReversâodeSentido_2 > ArredondarParaPróximoInteiro / \
Re lógio _ para _ desahililar, , + rcturdo _ ido e volto + 1 í 8
FaiorTipoInterface, ?
Por exemplo, um link direto do Tipo III de 1500 Mbps com um retardo de ida e volta de 10 relógios de link direto utiliza tipicamente um retardo de Reversão de Sentido 2 cia ordem de:
Relógios_para_desabilitar7A2 = . lOns
3,75
Retardo ReversãodeSentido 2 > ArredondarParaPróximoInteiro
3.75 + 10+1 8 4
XII. Temporização de Link Reverso Alternativa
Embora a utilização de bandas de guarda e temporização discutidas acima funcione para obter uma interface de taxa de transferência de dados alta, os inventores descobriram uma técnica para permitir comprimentos de bit reverso que são mais curtos do que o tempo de ida e volta, mudando a descoberta de temporização reversa.
Como apresentado acima, a abordagem anterior à temporização do link reverso é configurada de tal modo que o número de ciclos de relógio seja contado do último bit do Tempo de Guarda 1 de um pacote de temporização reversa até
127/161
Figure BRPI0410885B1_D0026
o primeiro bit ser amostrado na borda de subida de um relógio IO. Isto é o(s) sinal(is) de relógio utilizado(s) para sincronizar as entradas e saídas para a interface de MDD. O cálculo para c divisor de taxa reversa é então fornecido por:
divisor_taxa_reversa = ArredondarParaPróximoInteiro ( retardo _ ida e volta + 1 l 2
Isto provê uma largura de bit igual ao retardo de ida e volta que resulta em um link reverso muito confiável. Entretanto, o link reverso foi mostrado como sendo capaz de rodar mais rápido ou em uma taxa mais alta de transferência de dados, a qual os inventores desejam tirar proveito. Uma nova técnica inventiva permite a utilização de capacidades adicionais da interface para atingir taxas mais altas.
Isto é realizado fazendo com que o hospedeiro conte o número de ciclos de relógio até que um seja amostrado, porém com o hospedeiro amostrando a linha de dados nas bordas tanto de subida como de descida durante c pacote de temporização reverso. Isto permite ao hospedeiro pegar o ponto de amostragem mais útil ou mesmo ótimo no link reverso para assegurar que o bit seja estável. Isto é, encontrar a borda de subida mais útil ou ótima para amostrar dados para pacotes de encapsulamento reverso de tráfego reverso. O ponto de amostragem ótima depende tanto do divisor de link reverso o se o primeiro um toi detectado em uma borda de subida ou uma borda de descida. O novo método de temporização permite que o hospedeiro procure a primeira borda do padrão OxFF OxFF 0x00 enviado pelo cliente para temporização de link reverso a fim de determinar onde amostrar em um pacote de encapsulamento reverso.
128/161
Figure BRPI0410885B1_D0027
Os exemplos do bit reverso que chega e como aquele bit procuraria diversos divisores de taxa reversa, são ilustrados na figura 64, juntamente com um número de ciclos de relógio que ocorreram desde o último bit de Tempo de Guarda 1. Na figura 64, pode-se ver que se a primeira borda ocorrer entre uma borda de subida e de descida (rotulada como subida/descida), o ponto de amostragem ótima para um divisor de taxa reversa de um, o ponto de amostra ótimo é uma borda de ciclo de relógio rotulado 'b' , visto gue essa e a única borda de subida que ocorre no período dc bit reverso. Para um divisor de taxa reversa de dois, o ponto de amostragem ótimo é provavelmente ainda borda dianteira de ciclo de relógio 'b' visto que a borda de ciclo 'c' está mais próxima a uma borda de bit do que 'b'. Para um divisor de taxa reversa de quatro, o ponto de amostragem ótimo é provavelmente a borda de ciclo de relógio 'd' , visto que está mais próximo à borda traseira do bit reverso onde o valor provavelmente estabilizou.
Voltando à figura 64, se, entretanto, a primeira borda ocorrer entre uma borda de descida e de subida (rotulada como de descida/de subida), o ponto de amostragem ótimo para um divisor de taxa reversa de um é borda de ciclo de relógio de ponto de amostragem 'a', visto que é a única borda de subida no período de tempo de bit reverso. Para um divisor de taxa reversa de dois, o ponto de amostragem ótimo é borda 'b' e para um divisor de taxa reversa de quatro o ponto de amostragem ótimo é borda 'c'.
Pode-se ver que à medida que os divisores de taxa reversa ficam cada vez maiores, o ponto de amostragem ótima se torna mais fácil de determinar ou selecionar, pois deve ser a borda de subida que está mais próxima ao centro.
hospedeiro pode utilizar essa técnica para encontrar o número de bordas de relógio de subida antes que
129/161 a borda de dados de subida dos dados de pacote de temporização seja observada na linha de dados. Pode decidir então, com base no fato de se a borda ocorre entre uma borda de subida e de descida ou entre uma borda de descida e de subida, e qual é o divisor de taxa reversa, quantos ciclos de relógio adicionais acrescentar em um contador de números, a fim de assegurar razoavelmente que o bit é sempre amostrado tão próximo ao centro quanto possível.
Após o hospedeiro ter selecionado ou determinado o número de ciclos de relógio, pode explorar vários divisores de taxa reversa com c cliente para determinar se um divisor de taxa reversa específico funcionará. O hospedeiro (e cliente) pode iniciar com um divisor de um e verificar o CRC do pacote de status reversa recebido do cliente para determinar se essa taxa reversa funciona apropriadamente para transferir dados. Se o CRC for danificado, há provavelmente um erro de amostragem, e o hospedeiro pode aumentar o divisor de taxa reversa e tentar solicitar novamente um pacote de status. Se o segundo pacote solicitado for corrompido, o divisor pode ser aumentado novamente e a solicitação feita novamente. Se esse pacote for decodificado corretamente, esse divisor de taxa reversa pode ser utilizado para todos os pacotes reversos futuros.
Esse método é eficaz e útil porque a temporização reversa nào deve mudar da estimativa de temporização de ida e volta inicial. Se o link direto for estável, o cliente deve continuar a decodificar pacotes de link direto mesmo se houver falhas de link reverso. Evidentemente, é ainda responsabilidade do hospedeiro definir um divisor de link reverso para o link, uma vez que esse método não garante um link reverso perfeito. Além disso, o divisor dependerá principalmente da qualidade do relógio que é utilizado para
130/161 gerar um relógio 10. Se aquele relógio tiver uma quantidade significativa de instabilidade, há uma probabilidade maior de um erro de amostragem. Esse erro aumenta provavelmente com a quantidade de ciclos de relógio no retardo de ida e vol La.
Essa implementação parece funcionar melhor para os dados reversos do Tipo-I, porém pode apresentar problemas para os dados reversos do Tipo-II até Tipo-IV devido à distorção entre linhas de dados sendo potencialmente grandes em demasia para rodar o link na taxa em que funciona melhor para somente um par de dados. Entretanto, a taxa de dados provavelmente não necessita ser reduzida ao método anterior mesmo com Tipo-II até Tipo-IV para operação. Esse método também pode funcionar melhor se duplicado em cada linha de dados a fim de selecionar o local de amostra de relógio ideal ou um ótimo. Se estiverem no mesmo tempo de amostra para cada par de dados, esse método continuaria a funcionar. Se estiverem em períodos de amostra diferentes, duas abordagens diferentes podem ser utilizadas. A primeira é selecionar um local de amostra desejado ou mais otimizado para cada ponto de dados, mesmo se não for o mesmo para cada par de dados. O hospedeiro pode reconstruir então o fluxo de dados após amostragem de todos os bits do conjunto de pares de dados: dois bits para Tipo-II, quatro bits para Tipo-III e oito bits para TipoIV. A outra opção é para o hospedeiro aumentar o divisor de taxa reversa de tal modo que os bits de dados para cada par de dados possam ser amostrados na mesma borda de relógio.
XIII. Efeitos de Distorção e Retardo de Link
Distorção de retardo no link direto entre os pares de MDDI_Data e MDDI_Stb pode limitar a raxa de dados máxima possível a menos que se utilize compensação de distorção de retardo. As diferenças em retardo que causam
131/161
3/ l distorção de temporizaçào são devido à lógica do controlador, drivers de linha e receptores, e ao cabo e conectores como delineado abaixo.
A. Análise de Temporizaçào de Link por Distorção (MDDI Tipo-I)
1. Exemplo de Distorção e Retardo de um Link Tipo-I
Um circuito de interface típico similar àquele mostrado na figura 41, é mostrado na figura 57 para acomodar um link de interface do Tipo I. Na figura 57, valores típicos ou exemplares para retardo de propagação e distorção são mostrados para cada um de vários estágios de interface ou processamento de um link direto de MDDI TipoI. Distorção no retardo entre MDDI^Stb e MDDI_DataO faz com que o ciclo de trabalho do relógio de saída seja distorcido. Os dados na entrada D do estágio de flip-flop de receptor (RXFF) utilizando flip-flops 5728, 5732, devem alterar levemente após a borda de relógio de modo que possam ser amostrados de forma segura. A figura mostra duas linhas de retardo em cascata 5732a e 5732b sendo utilizadas para resolver dois problemas diferentes com a criação dessa relação de temporizaçào. Na implementação efetiva essas podem ser combinadas em um único elemento de retardo.
Dados, Stb e Temporizaçào de Recuperação de Relógio em um Link Tipo-I para processamento de sinais exemplar através da interface são ilustrados na figura 58.
A distorção de retardo total que é significativa surge geralmente ou vem da soma da distorção nos seguintes estágios: flip-flop de transmissor (TXFF) com flip-flops 5704, 5706; driver de transmissor (TXDRVR) com drivers 5708, 5710; o CA3LE 5702; receptor de linha de receptor (RXRCVR) com receptores 5722, 5724; e lógica XOR de receptor (RXXOR). O Retardol 5732a deve casar ou exceder o
132/161
Figure BRPI0410885B1_D0028
retardo da porta XOR 5736 no estágio RXXOR que é determinado pela relação:
tpD - min' Retardo ll — tp^ - max [XOR)
É desejável atender essa exigência de modo que a entrada D do flip-flop dê receptor 5728, 5730 não mude antes de sua entrada de relógio. Isto é válido se o tempo de retenção do RXFF for zero.
A finalidade ou função de Retardo2 é compensar pelo tempo de retenção do flip-flop RXFF de acordo com a relação:
tpD - miniRetarcio 2) ~ ta(RXFF)
Em muitos sistemas isto será zero porque o tempo de retenção é zero, e evidentemente nesse caso o retardo máximo de Retardo2 também pode ser zero.
A contribuição de pior caso para distorção no estágio XOR de receptor está no caso dadosatrasados/estrobo-antecipado onde Retardol está em um valor máximo e a saída de relógio da porta XOR vem tão cedo quanto possível de acordo com a relação:
toiSTORÇÃC - max (RXXOR) = tPD - ma:·: (Retardo . i - tpo - niníXORi
Nessa situação, os dados podem mudar entre dois períodos de bits, n e n+1, muito próximo ao tempo onde o bit n+1 é sincronizado no flip-flop de receptor.
A taxa máxima de dados (período de bit mínimo) de um link MDDI Tipo-I é uma função da distorção máxima encontrada através de todos os drivers, cabo e receptores no link de MDDI mais a configuração total de dados no estágio de RXFF. A distorção de retardo total no link até a saída dc estágio RXRCVR pode ser expresso como:
t-Distorcâo - max(LINK) = tDist;Orcao _ maxlTXFF) + trjistcrção max (TXDP.VRl * t Drstoxçao-max (CASO) + taistorçao - max (RXRCVR) e o período de bit mínimo é dado por:
133/161 \cfi tõlT-nin — t-istorcâo - ira:·: :l,IKK: + ^Distorção - tr.ax (RXX0F.) + t?Dtr.s:·: (RPtarric 2: + tgu (rxfF:
No exemplo mostrado na figura 57, tDistorçàomax(LINK) = 1,4 ns e o período de bit mínimo pode ser expresso como:
tBtT-min = 1/4 + 0,3 + 0,2 + 0,5 = 2,4ns, ou dito como aproximadamente 416 Mbps.
B. Análise de Temporização de Link para MDDI Tipo-II, III e IV
Um circuito de interface típico similar àquele mostrado nas figuras 41 e 57 é mostrado na figura 59 para acomodar links de interface do Tipo-II, III e IV. Elementos adicionais são utilizados nos estágios TXFF (5904), TXDRVR (5908), RXRCVCR (5924) e RXFF (5932, 5928, 5930) para acomodar o processamento de sinais adicional. Na figura 59, valores exemplares ou típicos para retardo de propagação e distorção são mostrados para cada um dos vários estágios de interface ou processamento de um link direto de MDDI TipoII. Além de distorção no retardo entre MDDI_Stb e MDDI_Data0 que afetam o ciclo de trabalho do relógio de saída, há também distorção entre ambos esses dois sinais e os outros sinais de MDDI_Data. Os dados na entrada D do estágio de flip-flop de receptor B (RXFFB) consistindo nos flip-flops 5928 e 5930, são mudados levemente após a borda de relógio de modo que possam ser amostrados de forma segura. Se MDDI_Datal chegar mais cedo do que MDDl_Stb ou MDDI_Data0 então MDDI_Dtal deve ser retardado para ser amostrado pelo menos pela quantidade da distorção de retardo. Para realizar isto, dados são retardados utilizando a linha de retardo Retardo3. Se MDDI_Datai chegar depois de MDDI_Stb e MDDI_Data0 e também forem retardados pelo Retardo3 então o ponto onde MDDI_Datal muda é rnovido mais próximo à próxima borda de relógio. Esse
134/161 processo determina um limite superior da taxa de dados de um link MDDI Tipo-II, III ou IV. Algumas possibilidades diferentes exemplares para o temporização ou relação de distorção dos dois sinais de dados e MDDI_Stb um em relação ao outro são ilusLradas nas figuras 60A, 60B e 60C.
A fim de amostrar os dados de forma segura em RXFFB quando MDDI_DataX chega tão cedo quanto possível, Retardo3 é definido de acordo com a relação:
tpp-mir. 'FetarrioB; — t.-;st«.uçâo-nia:-: .LINK) + tHiRXFFB) + t?D-ir.ax (XCP.
A taxa máxima de link é determinada pelo período de bit mínimo permissível. Isto é mais afetado quando MDDIDataX chega tão tarde quanto possível. Nesse caso, o tempo de ciclo mínimo permissível é dado por:
tsrr-mm = tfostorc.So-ma;·: (LIMFI +t ρο-η-3:< :Rprarrto3) +tsv. RXFF3) -t?D-n-;n :XOP;
O limite superior de taxa de link é então: t ?d ira:·: ‘ Retardo? = tp-.-n-.in P=rardo3. e dada aquela assunção:
t BIT-irin ·· linu te-ir.ferior ' = 2 . t pistorcàt—raax 1LÍHK! + IpL-ma:·; ;.;orj +1 s” I R>; FFB · +111, RX FF31
No exemplo dado acima, o limite inferior dc período mínimo de bit é dado pela relação:
t3IT-rr.irj (r.ivel-ir. fer i or; = 2.1,4 + 1,5 + 0,5 + 0,1= 4,8ns, que é aproximadamente 208 Mbps.
Isto é muito mais lento do que a taxa máxima de dados que pode ser utilizada com um link do Tipo-I. A capacidade de compensação automática de distorção de retardo de MDDI reduz significativamente o efeito que distorção de retardo tem sobre a taxa máxima de link.
XIV. Descrição de Interconexão de Camada Física
Conexões físicas úteis para implementar uma interface de acordo com a presente invenção podem ser realizadas utilizando partes comercialmente disponíveis como parte número 3260-8S2 (01) como fabricado por Hirose
135/161
Electric Company Ltd. no lado do hospedeiro, e parte número 3240-8P-C como fabricado por Hirose Electric Company Ltd. no lado de dispositivo de display. Uma atribuição de pino de interface exemplar ou pinagem para esses conectores utilizados com interfaces do Tipo-I/Tipo-II é listada na Tabela XIII, e ilustrada na figura 61.
Tabela XIII
Nome do Sinal Número do Pino Cor Nome do Sinal Número dc Pino Cor
MDDI_Pwr 1 Vermelho MDDI_Gnd 2 Preto unido com vermelho
MDDI_Stb- 3 Verde MDDI_Stb- 4 Preto unido com verde
MDDI DataO+ 5 Azul MDDI DataO- 6 Preto unido com azul
MDDl_Datal+ 7 Branco MDDI_Datal- 8 Preto unido com branco
Blindagem
A blindagem é conectada ao MDDI_Gnd na interface
de hospedeiro, e um fio-dreno de blindagem no cabo é
conectado à blindagem do conector de display. Entretanto, a
blindagem e fio-dreno não são conectados à terra do
circuito dentro de um display.
Dispositivos ou elementos de interconexão são escolhidos ou projetados para serem pequenos o suficiente 15 para utilização com dispsitivos de computação e comunicação móveis, como PDAs e telefones sem fio, ou dispsitivos de jogos portáteis, sem serem importunos ou não estéticos em comparação com c tamanho relativo do dispsitivo. Quaisquer conectores e cabeamer.to devem ser duráveis o suficiente
Figure BRPI0410885B1_D0029
136/161 para utilização no ambiente típico do consumidor e permitir tamanho pequeno, em especial para o cabeamento e custo relativamente baixo. Os elementos de transferência devem acomodar sinais de estrobo e dados que são dados NRZ diferenciais tendo uma taxa de transferência até em torno de 450 Mbps para Tipo-I e 7ipo-IT e até 3,6 Gbps para a versão do Tipo-IV paralela de 8 bits.
XV. Operação
Um sumário das etapas gerais empreendidas no processamento de dados e pacotes durante operação de uma interface utilizando modalidades da invenção é mostrado nas figuras 54A e 54B, juntamente com uma visão geral do equipamento de interface que processa os pacotes na figura 55. Nessas figuras, o processo se inicia em uma etapa 5402 com uma determinação com relação a se o cliente e hospedeiro estão ou não conectados utilizando um percurso de comunicação, aqui um cabo. Isto pode ocorrer através da utilização de interrogação periódica pelo hospedeiro, utilizando software ou hardware que detecta a presença de conectores ou cabos ou sinais nas entradas para o hospedeiro (como é visto para as interfaces USB), ou outras técnicas conhecidas. Se não houver cliente conectado ao hospedeiro, então pode simplesmente entrar em um estado de espera de algum período predeterminado, dependendo da aplicação, enrrar em um modo de hibernação, ou ser inativado para esperar utilização futura que poderia exigir que um usuário tome medida para reativar o hospedeiro. Por exemplo, quando um hospedeiro reside em um dispsitivo do tipo computador, um usuário poderia ter de clicar em um ícone de tela ou solicitar um programa que ative o processamento de hospedeiro para procurar o cliente. Novamente, o simples encaixe de uma conexão do tipo USB, como utilizado para a interface do Tipo-U, poderia ativar o
Figure BRPI0410885B1_D0030
137/161 processamento de hospedeiro, dependendo das capacidades e configuração do hospedeiro ou software de hospedeiro residente.
Após conexão de um cliente ao hospedeiro, ou vice versa, ou detecção da mesma como estando presente, o cliente ou o hospedeiro envia pacotes apropriados que solicitam serviço nas etapas 5404 e 5406. 0 cliente poderia enviar pacotes de Status ou Solicitação de Serviço de Display na etapa 5404. Observa-se que o link, como discutido acima, poderia ter sido previamente desligado ou estar no modo de hibernação então isso pode não ser uma inicialização completa do link de comunicação que segue. Após o link de comunicação ser sincronizado e o hospedeiro estar tentando comunicar-se com o cliente, o cliente também provê um pacote de Capacidades de Display para o hospedeiro, como na etapa 5408. O hospedeiro pode agora começar a determinar o tipo de suporte, incluindo taxas de transferência, que o cliente pode acomodar.
Geralmente, o hospedeiro e cliente também negociam o tipo (taxa/velocidade) de modo de serviço a ser utilizado, por exemplo, Tipo-I, Tipo-U, Tipo-II, e assim por diante, em uma etapa 5410. Após estabelecimento do tipo de serviço o hospedeiro pode iniciar a transferência de informações. Além disso, o hospedeiro pode utilizar Pacotes de Medição de Retardo de Ida e Volta para otimizar a temporização dos links de comunicação em paralelo corr. outro processamento de sinais, como mostrado na etapa 5411.
Como dito anteriormente, todas as transferências começam com um Pacote de Cabeçalho de Subquadro, mostrado sendo transferido na etapa 5412, seguido pelo tipo de dados, aqui pacotes de fluxo de vídeo e áudio, e pacotes preenchedores, mostrados sendo transferidos na etapa 5414. Os dados de áudio e vídeo terão sido previamente preparados
Figure BRPI0410885B1_D0031
138/161 ou mapeados em pacotes, e os pacotes preenchedores são inseridos conforme necessário ou desejado para preencher um número exigido de bits para os quadros de mídias. O hospedeiro pode enviar pacotes como os Pacotes de Habilitar canal de áudio direto a fim de ativar dispsitivos de som. Além disso, o hospedeiro pede transferir comandos e informações utilizando outros tipos de pacotes discutidos acima, aqui mostrados como a transferência de Mapa de Cores, Transferência de Bloco de Bits ou outros pacotes na etapa 5416. Além disso, o hospedeiro e cliente podem trocar dados referentes a um teclado ou dispsitivos de apontamento utilizando os pacotes apropriados.
Durante operação, um de vários eventos diferentes pode ocorrer que levam ao hospedeiro ou cliente que deseja uma taxa de dados ou tipo de modo de interface diferente. Por exemplo, um computador ou outro dispsitivo comunicando dados poderia encontrar condições de carregamento em dados de processamento que causa uma redução de taxa na preparação ou apresentação de pacotes. Um display que recebe os dados poderia mudar de uma fonte de energia CA dedicada para uma fonte de energia de bateria mais limitada, e não ser capaz de transferir dados tão rapidamente, processar comandos tác facilmente, ou não ser capaz de utilizar o mesmo grau de resolução ou profundidade de cor de acordo com os ajustes de energia mais limitados. Alternativamente, uma condição restritiva poderia ser eliminada ou desaparecería permitindo que qualquer dispsitivo transferisse dados em taxas mais altas. Isto sendo mais desejável, uma solicitação pode ser feita para alterar para um modo de taxa de transferência mais alta.
Se esses ou outros tipos de condições conhecidas ocorressem ou mudassem, o hospedeiro ou cliente pode detectar os mesmos e tentar renegociar o modo de interface.
139/161
Isto é mostrado na etapa 5420, onde o hospedeiro envia Pacotes de Solicitação de Handoff do tipo de interface para o cliente solicitando uma handoff para outro modo, o cliente envia Pacotes de Confirmação do tipo de interface confirmando que se busca uma mudança, e o hospedeiro envia Pacotes de Handoff do tipo Executar para fazer a alteração para modo especificado.
Embora não exigindo uma ordem específica de processamento, o cliente e hospedeiro podem também trocar pacotes referentes a dados destinados a ou recebidos de dispsitivos de apontamento, teclados ou outros dispsitivos de entrada do tipo de usuário associados principalmente ao cliente, embora tais elementos também possam estar presentes no lado de hospedeiro. Esses pacotes são tipicamente processados utilizando um elemento do tipo de processador geral e não a máquina de estado (5502) . Além disso, alguns dos comandos discutidos acima também serão processados pelo processador geral. (5504, 5508).
Após troca de dados e comandos entre o hospedeiro e cliente, em algum ponto toma-se uma decisão com relação a se dados adicionais devem ou não ser transferidos ou o hospedeiro o cliente vai cessar de atender a transferência. Isto é mostrado na etapa 5422. Se o link deve entrar em um estado de hibernação ou ser totalmente desligado, o hospedeiro envia um pacote de Desligamento de Link para o cliente, e os dois lados terminam a Lransferência de dados.
Os pacotes sendo transferidos no processamento de operações acima serão transferidos utilizando os drivers e receptores previamente discutidos em relação aos controladores de cliente e hospedeiro. Esses drivers de linha e outros elementos lógicos são conectados à máquina de estado e processadores gerais discutidos acima, como ilustrado na visão geral da figura 55. Na figura 55, uma
140/161 ko^ máquina de estado 5502 e processadores gerais 5504 e 5508 podem ser adicionalmente conectados a outros elementos não mostrados como uma interface USB dedicada, elementos de memória, ou outros componentes residindo fora do controlador de link com os quais eles interagem, incluindo, porém não limitado a, fonte de dados, e chips de controle de vídeo para dispsitivos de display de visualização.
Os processadores, e máquina de estado fornecem controle sobre a habilitação e desabilitação dos drivers
1C como discutido acima em relação a tempos de guarda, e assim por diante, para assegurar estabelecimento ou terminação eficiente de link de comunicação e transferência de pacotes.
XVI. Adendo
Além dos formatos, estruturas e conteúdos discutidos acima para os diversos pacotes utilizados para implementar a arquitetura e protocolo para modalidades da invenção, operações ou conteúdos de campo mais detalhados são apresentados aqui para alguns dos tipos de pacote.
Esses são apresentados aqui para esclarecer adicionalmente sua respectiva utilização ou operações para permitir que aqueles versados na técnica entendam mais facilmente e façam utilização da invenção para uma variedade de aplicações. Somente alguns dos campos não discutidos ainda são discutidos adicional mente aqui. ALém disso, esses campos são apresentados com definições e valores exemplares em relação às modalidades apresentadas acima. Entretanto, esses valores não devem ser tomados como limitações da invenção, porém representam uma ou mais modalidades úteis para implementar a interface e protocolo, e nem todas as modalidades necessitam ser postas em prática juntas ou ao mesmo tempo. Outros valores podem ser utilizados em outras modalidades para obter a apresentação desejada de dados ou
141/161
Figure BRPI0410885B1_D0032
resultados de transferência de taxa de dados, como será entendido por aqueles versados na técnica.
A. Para Pacotes de Fluxo de Vídeo
Em uma modalidade, o campo de atributos de Dispiay (1 byte) tem uma série de valores de bits que são interpretados como a seguir. Os bits 1 e 0 selecionados como os dados de pixel de dispiay são roteados. Para valores de bits de '00' ou '11' dados são exibidos para ambos os olhos, para valores de bits '10', os dados são roteados somente para o olho esquerdo, e para os valores de bits '01', os dados são roteados somente para o olho direito. O bit 2 indica se os Dados de Pixel são ou não apresentados em um formato de entrelaçamento, com um valor de '0' significando que os dados de pixel estão no formato progressivo padrão, e que o número de linha (coordenada de pixel Y) é incrementado em 1 ao avançar de uma linha para a seguinte. Quando esse bit tem um valor de '1', os dados de pixel estão no formato de entrelaçamento, e o número de linha é incrementado em 2 ao avançar de uma linha para a seguinte. O bit 3 indica que os Dados de Pixel estão em formato de pixel alternado. Isto é similar ao modo de interface padrão habilitado pelo bit 2, porém o entrelaçamento é vertical em vez de horizontal . Quando o Bit 3 é 0 os Dados de Pixel estão no formato progressivo padrão, e o número de coluna (coordenada de pixel X) é
incrementado em 1 à medida que cada pixel sucessivo é
recebido. Quando o Bit 3 é 1 os Dados de Pixel estão em
formato de pixel alternado , e o número de coluna é
incrementado em 2 à medida que cada pixel é recebido. Os
bits 7 até 4 são reservados para utilização futura e são
geraimente definidos como zero.
Os campos Iniciar Y e Iniciar X de 2 byt es
especificam as coordenadas X e Y absolutas do ponto
142/161
Figure BRPI0410885B1_D0033
(Iniciar X, Iniciar Y) para o primeiro pixel no campo de Dados de Pixel . Os campos de Borda Superior Y e Borda Esquerda X de 2 bytes especificam a coordenada X da borda esquerda e coordenada Y da borda superior da janela da tela cheia com o campo de Dados de Pixel, enquanto os campos de Borda Inferior Y e Borda Direita X especificam a coordenada X da borda direita, e a coordenada Y da borda inferior da janela sendo atualizada.
O campo de Contagem de Pixel (2 bytes) especifica o número de pixels no campo de Dados de Pixel abaixo.
O campo CRC de Parâmetro (2 bytes) contém um CRC de todos os bytes do Comprimento de Pacote para a Contagem de Pixel. Se esse CRC falhar para verificar então o pacote inteiro é descartado.
O campo de Dados de Pixel contém as informações de video brutas que devem ser exibidas e que são formadas no modo descrito pelo campo Descritor de Formato de Dados de video. Os dados são transmitidos uma linha de cada vez como discutido em outra parte.
O campo CRC de Dados de Pixel (2 bytes) contém um CRC de 16 bits somente dos Dados de Pixel. Se uma verificação de CRC desse valor falhar então os Dados de Fixei ainda podem ser utilizados, porém a contagem de erro de CRC é incrementada.
B. Para Pacotes de Fluxo de Áudio
Em uma modalidade, o campo ID de Canal de áudio (1 byte) identifica um canal de áudio especifico para o qual dados de áudio são enviados pelo dispsitivo cliente. Os canais de áudio físicos são especificados em ou mapeados por esse campo como valores de 0, 1, 2, 3, 4, 5, 6 ou 7 que indicam os canais frontal esquerdo, frontal direito, traseiro esquerdo, traseiro direito, centro frontal, subwoofer, surround left e surround right, respectivamente. Um
143/161 valor de ID de canal de áudio de 254 indica que o único fluxo de amostras de áudio digitais é enviado para os canais canto frontal esquerdo como frontal direito. Isto simplifica as aplicações onde um receptor de telefonia estéreo é utilizado para comunicação de voz, apps de aumento de produtividade são utilizados em um PDA, ou outras aplicações onde uma Interface de Usuário simples gera tons de alerta. Os valores para o campo de ID variando de 8 até 254, e 255 são atualmente reservados para utilização onde novos desenhos desejam designações adicionais.
O campo Contagem de Amostra de áudio (2 bytes) especifica o número de amostras de áudio nesse pacote.
O campo Empacotamento e Bits por Amostra contém 1 15 byte que especifica o formato de medição a passos de dados de áudio. 0 formato geralmente empregado é para Bits 4 até 0 para definir o número de bits por amostra de áudio PCM. O bit 5 especifica então se as amostras de Dados de áudio digitais são ou não empacotadas. Como mencionado acima, a figura 12 ilustra a diferença entre amostras de áudio empacotadas e alinhadas em bytes. Um valor de '0' para o 3it 5 indica que cada amostra de áudio PCM no campo de Dados de Áudio digitais é alinhada em bytes com o limite de byte de interface, e um valor de '1'indica que cada amostra de áudio PCM sucessiva é empacotada contra a amostra de áudio anterior. Esse bit è eficaz somente quando o valor definido em bits 4 até 0 (o número de bits por amostra de áudio PCM) não é um múltiplo de oito. Bits 7 até 6 são reservados para utilização onde desenhos de sistema desejam designações adicionais e são geralmente definidos em um valor de zero.
O campo Taxa de Amostra de Áudio (1 byte) especifica a taxa de amostra PCM de áudio. O formato
144/161 empregado é para um valor de 0 a fim de indicar uma taxa de 8.000 amostras por segundo (sps), um valor de 1 indica
16.000 sps, valor de 2 para 24.000 sps, valor de 3 pa ra
32.000 sps, valor de 4 para 40.000 sps, valor de 5 para
48.000 sps, valor de 6 para 11.025 sps, valor de 7 para
22.050 sps, e valor de 8 para 44.100 sps, respectivamente,
com va lores de 9 até 15 sendo reservados para utilização
futura, desse modo são atualmente definidos em zero.
O campo CRC de Parâmetro (2 bytes) contém um CRC de 16 bits de todos os bytes do Comprimento de Pacote para a Taxa de Amostra de Áudio. Se esse CRC falhar em verificar apropriadamente, então o pacote inteiro é descartado. O campo Dados de áudio Digitais contém as amostras de áudio brutas a serem reproduzidas, e tem normalmente a forma de um formato linear como números inteiros sem sinal. O campo CRC de Dados de áudio (2 byte) contém CRC de 16 bits somente dos Dados de áudio. Se esse CRC falhar em verificar então os Dados de áudio ainda podem ser utilizados, porém a contagem de erro de CRC é incrementada.
C. Para Pacotes de Fluxo Definidos pelo Usuário Em uma modalidade, o campo Número de ID de Fluxo de 2 byte é utilizado para identificar um fluxo específico definido pelo usuário. Os conteúdos dos campos Dados de Fluxo e Parâmetros de Fluxo são tipicamente definidos pelo fabricante do equipamento MDDI. O campo CRC de Parâmetro de fluxo de 2 bytes contém um CRC de 16 bits de todos os bytes dos parâmetros de fluxo iniciando do Comprimento de Pacote até o byte de Codificação de Áudio. Se esse CRC falhar em verificar então o pacote inteiro é descartado. O campo CRC de Dados de fluxo de 2 bytes contém um CRC somente dos Dados de fluxo. Se esse CRC falhar em verificar apropriadamente, então a utilização dos Dados de Fluxo é opcional, dependendo das exigências da aplicação. A
145/161 utilização dos dados de fluxo contingente no CRC sendo bom, requer geraimente que os dados de fluxo sejam armazenados até que o CRC seja confirmado como sendo bom. A contagem de erro de CRC é incrementada se o CRC não verificar.
D. Para Pacotes de Mapa de Cores
O campo de Tamanho de Dados de Mapa de Cores (2 bytes) especifica o número total de entradas de tabela de mapa de cores que existem nos Dados de Mapa de cores nesse pacote. Nessa modalidade, o número de bytes nos Dados de Mapa de Cores é 3 vezes o Tamanho do Mapa de Cores. O Tamanho de Mapa de Cores é definido igual a zero para não enviar dados de mapa de cores. Se o Tamanho de Mapa de Cores for zero então um valor de Offset de Mapa de cores é geraimente ainda enviado, porém é ignorado pelo display. 0 campo Offset de Mapa de Cores (2 bytes) especifica o Offset dos Dados de Mapa de Cores nesse pacote do início da tabela de mapa de cores no dispsitivo de display.
Um campo CRC de Parâmetro de 2 bytes contém um CRC de todos os bytes do Comprimento de Pacote até o byte de Codificação de Áudio. Se esse CRC falhar em verificar então o pacote inteiro é descartado.
Para o campo Dados de Mapa de Cores, cada local de mapa de cores é um valor de 3 bytes, onde o primeiro byte especifica a magnitude de azul, o segunde byte especifica a magnitude de verde e o terceiro byte especifica a magnitude de vermelho. O campo Tamanho de Mapa de cores especifica o número de itens de tabela de mapa de cores de 3 bytes que existem no campo Dados de Mapa de Cores. Se um mapa de cor única não puder adaptar-se em um Formato de Dados de vídeo e Pacote de Mapa de cores, então o mapa de cores inteiro pode ser especificado enviando múltiplos pacotes com diferentes Dados de Mapa de cores e Offset de Mapa de cores em cada pacote.
Figure BRPI0410885B1_D0034
146/161
Um campo CRC de Dados de Mapa de cores de 2 bytes contém urr. CRC somente dos Dados de Mapa de cores. Se esse CRC falhar em verificar então os Dados de Mapa de cores podem ainda ser utilizados, porém a contagem de erro de CRC é incrementada.
E. Para Pacotes de Encapsulamento de Link Reverso
Em uma modalidade, o campo Flags de Link reverso (1 byte) contém um conjunto de flags para solicitar informações do display. Se um bit (por exemplo, Bit 0) é definido em um então o hospedeiro solicita as informações especifiçadas do display utilizando o Pacote de Capacidade de display. Se o bit for zero então o hospedeiro não necessita das informações do display. Os bits restantes (agui Bits 1 até 7) são reservados para utilização futura e são definidos em zero. Entretanto, mais bits podem ser utilizados como desejado para definir flags para o link reverso.
O campo Divisor de Taxa Reversa (1 byte) especifica o número de ciclos MDDI_Stb que ocorrem em relação ao relógio de dados de link reverso. O relógio de dados de link reverso é igual ao relógio de dados de link direto dividido por duas vezes o Divisor de Taxa reversa. A taxa de dados de link reverso é relacionada ao relógio de dados de link reverso e o Tipo de Interface no link reverso. Para uma interface Tipo-I a taxa de dados reversa é igual ao relógio de dados de link reverso para, interfaces Tipo-II, Tipo-III e Tipo-IV as taxas de dados reversas são iguais a duas vezes, quatro vezes e oito vezes o relógio de dados de link reverso, respectivamente.
O campo de Comprimento de Reversão de Sentido 1 (1 byte) especifica o número total de bytes que são alocados para Reversão de Sentido 1. O comprimento recomendado de Reversão de Sentido 1 é o número de bytes
147/161
Figure BRPI0410885B1_D0035
necessário para que os drivers MDDl_Data em um hospedeiro tenham as saídas desabilitadas. Isto se baseia no tempo de desabiiitaçào de saída discutido acima, a taxa de dados de link direto, e a seleção de Tipo de Interface de Link direto sendo utilizada. Uma descrição mais completa do ajuste de Reversão de Sentido 1 é fornecida acima.
O campo Comprimento de Reversão de Sentido 2 (1 byte) especifica o número total de bytes que são alocados para Reversão de Sentido. 0 comprimento recomendado de Reversão de Sentido 2 é o número de bytes necessário para que os drivers MDDI_Data no Display desabilitem suas saídas mais o retardo ida e volta. Uma descrição do ajuste de Reversão de Sentido 2 é dada acima.
O campo CRC de Parâmetro (2 bytes) contém um CRC de 16 bits de todos os bytes do Comprimento de Pacote para o Comprimento de Reversão de Sentido. Se esse CRC falhar em verificar então o pacote inteiro é descartado.
O campo Todos Zero (1 byte) é definido igual a zero, e é utilizado para assegurar que todos os sinais MDDI_Data estejam no estado zero antes de desabilitar os drivers de linha durante o primeiro período de Tempo de Guarda.
O campo Reversão de Sentido 1 é utilizado para estabelecer o primeiro período de reversão de sentido. O número de bytes especificado pelo parâmetro de Comprimento de Reversão de Sentido è alocado por esse campo para permitir gue os drivers de linha de MDDI_Data no hospedeiro desabilitem antes dos drivers de linha no cliente (display) serem habilitados. 0 hospedeiro desabilita seus drivers de linha MDDI_Data durante bit 0 de Reversão de Sentido 1 e o cliente (display) habilita seus drivers de linha imediatamente após o último bit de Reversão de Sentido 1. O
Figure BRPI0410885B1_D0036
148/161 sinal MDDI_Stb se comporta como se o período de Reversão de Sentido fosse todos zero.
O campo Pacotes de Dados reversos contém uma série de pacotes de dados sendo transferidos do cliente para um hospedeiro. Como dito anteriormente, os pacotes Preenchedores são enviados para encher o espaço restante que não é utilizado por outros tipos de pacotes.
O campo Reversão de Sentido 2 é utilizado para estabelecer o segundo período de reversão de sentido. O número de bytes especificado pelo parâmetro de Comprimento de Reversão de Sentido é alocado por esse campo.
O campo Reabilitar Driver utiliza 1 byte que é igual a zero para assegurar que todos os sinais MDDI_Data sejam reabilitados antes do Campo de Comprimento de pacote do próximo pacote.
F. Para Pacotes de Capacidade de Display
Em uma modalidade, o campo Versão de Protocolo utiliza 2 bytes para especificar uma versão de protocolo utilizada pelo cliente. A versão inicial é definida igual a zero, enquanto o campo Versão de Protocolo Mínimo utiliza 2 bytes para especificar a versão de protocolo mínimo que o cliente pode empregar ou interpretar. O campo Capacidade de Taxa de Dados de Display (2 bytes) especifica a taxa máxima de dados que o display pode receber no link direto da interface, e é especificado na forma de Megabits por segundo (Mbps). O campo Capacidade do Tipo de Interface (1 byte) especifica os tipos de interface gue sâo suportados nos links direto e reverso. Isto é atualmente indicado pela seleção de Bit 0, Bit 1 ou Bit 2 para selecionar um modo do Tipc-II, Tipo-III ou Tipo-IV no link direto, respectivamente, e Bit 3, Bit 4 ou Bit 5 para selecionar um modo do Tipo-II, Tipo-III ou Tipo-IV no link reverso, respectivamente; com os Bits 6 e 7 sendo reservados e
149/161
definidos em zero. Os campos Altura e Largura do mapa de
bits (2 bytes) especificam a largura e altura do mapa de
bits em pixels.
0 campo Capacidade de monocromo (1 byte) é
utilizado para especificar o número de bits de resolução
que podem ser exibidos em um formato de monocromo. Se um display não puder utilizar um formato de monocromo então esse valor é definido em zero. Os bits 7 até 4 são reservados para utilização futura e são, desse modo, definidos como zero. Os bits 3 até 0 definem o número máximo de bits de escala de cinza que podem existir para cada pixel. Esses quatro bits tornam possível especificar valores de 1 a 15 para cada pixel . Se o valor for zero então o formato de monocromo não é suportado pelo display.
0 campo Capacidade de mapa de cores (3 bytes) especifica o número máximo de itens de tabela que existem na tabela de mapa de cores no display. Se o display não puder utilizar o formato de mapa de cores então esse valor é zero.
O campo Capacidade RGB (2 bytes) especifica o número de bits de resolução que podem ser exibidos no formato RGB. Se o display não puder utilizar o formato RGB então esse valor é igual a zero. A palavra Capacidade RGB é composta de três valores sem sinal separados onde: os bits
3 até 0 definem o número máximo de bits de azul, Bits 7 até definem o número máximo de bits de verde, e os Bits 11 até 8 definem o número máximo de bits de vermelho em cada pixel. Atualmente, os Bits 15 até 12 são reservados para utilização futura e são geralmente definidos em zero.
O campo Capacidade Y Cr Cb (2 bytes) especifica o número de bits de resolução que pode ser exibido no formato Y Cr Cb. Se o display não puder utilizar o formato Y Cr Cb então esse valor é definido igual a zero. A palavra de
150/161
7/7
Capacidade Y Cr Cb é composta de três valores sem sinal separados onde: os Bits 3 até 0 definem o número máximo de bits na amostra Cb, os Bits 7 até 4 definem o número máximo de bits na amostra Cr, os Bits 11 até 8 definem o número máximo de bits na amostra Y, e os Bits 15 até 12 são atualmente reservados para utilização futura e sãc definidos em zero.
O campo Indicadores de Capacidade de Recurso de display utiliza 4 bytes que contêm um conjunto de flags que indicam recursos específicos no display que são suportados. Um bit definido em um indica que a capacidade é suportada, e um bit definido em zero indica que a capacidade não é suportada. O valor para Bit 0 indica se o Pacote de Transferência de bloco de mapa de bits (pacote tipo 71) é ou não suportado. O valor para os Bits 1, 2 e 3 indicam se o Pacote de Preenchimento de área de mapa de bits (pacote tipo 72), Pacote de preenchimento de padrão do mapa de bits (pacote tipo 73) , ou Pacote de canal de dados de link de comunicação (pacote tipo 74), respectivamente, são ou não suportados. 0 valor para Bit 4 indica se o display tem ou não a capacidade de tornar uma cor transparente, enquanto os valores para os Bits 5 e 6 indicam se o display pode aceitar dados de video ou dados de áudio no formato empacotado, respectivamente, e o valor para Bit 7 indica se o display pode enviar um fluxo de vídeo de link reverso de uma câmara. 0 valor para os Bits ii e 12 indicam quando o cliente está se comunicando com um dispsitivo de apontamento e pode enviar e receber Pacotes de Dados de Dispositivo de Apontamento, ou com um teclado e pode enviar e receber Pacotes de Dados de teclado, respectivamente. Os bits 13 até 31 são atualmente reservados para utilização futura ou designações alternativas úteis para projetistas de sistemas e são geralmente definidos iguais a zero.
151/161
Figure BRPI0410885B1_D0037
frontal esquerdo, traseiro direito,
O campo Capacidade de Taxa de quadro de vídeo de display (1 byte) especifica a capacidade de atualização de quadro de vídeo máxima do display em quadros por segundo. Um hospedeiro pode escolher atualizar a imagem em uma taxa mais lenta do que o valor especificado nesse campo.
O campo Profundidade de Buffer de Áudio (2 bytes) especifica a profundidade do buffer elástico em um Display que é dedicado a cada fluxo de áudio.
O campo Capacidade de Canal de áudio (2 bytes) contém um grupo de flags que indicam quais canais de áudio são suportados pelo display (cliente). Um bit definido em um indica que o canal é suportado, e um bit definido em zero indica que o canal não é suportado. As posições de Bits são atribuídas aos canais diferentes, por exemplo, posições de Bit 0, 1, 2, 3, 4, 5, 6 e 7 indicam os canais frontal direito, traseiro esquerdo, centro frontal, sub-woofer, esquerdo surround e direito surround, respectivamente. Os bits 8 até 15 são atualmente reservados para utilização futura, e são geralmente definidos em zero.
Um campo Capacidade de Taxa de amostra de áudio de 2 bytes, para c link direto, contém um conjunto de flags para indicar a capacidade de taxa de amostra de áudio do dispsitivo cliente. Posições de bits são atribuídas às diferentes taxas, por conseguinte, como Bits 0, 1, 2, 3, 4, 5, 6, / e 8 sendo atribuidas a 8.000, 16.000, 24.000,
32.000, 40.000, 48.000, 11.025, 22.050 e 44.100 amostras por segundo (SPS) respectivamente, com Bits 9 até 15 sendo reservados para utilizações de taxa futuras ou alternativas, como desejado, de modo que são atualmente definidos em '0'. A definição de um valor de bit para um desses bits em '1' indica que aquela taxa de amostra
152/161 específica é suportada, e a definição do bit em '0' indica que a taxa de amostra não é suportada.
campo Taxa de Subquadro Mínimo (2 bytes) especifica a taxa mínima de subquadro em quadros por segundo. Ά taxa mínima de subquadro mantém a taxa de atualização de status de display suficiente para ler certos sensores ou dispsitivos de apontamento no display.
Um campo Capacidade de Taxa de Amostra Mic de 2 bytes, para o link reverso, que contém um conjunto de flags que indicam a capacidade de taxa de amostra de áudio de um microfone no dispsitivs cliente. Para fins do MDDI, um microfone de dispsitivo cliente é configurado para suportar de forma mínima pelo menos uma taxa de 8.000 amostras por segundo. Posições de bit para esse campo são atribuídas às diferentes taxas com posições de bits 0, 1, 2, 3, 4, 5, 6, 7 e 8, por exemplo, sendo utilizadas para representar 8.000, 16.000, 24.000, 32.000, 40.000, 48.000, 11.025, 22.050 e 44.100 amostras por segundo (SPS), respectivamente, com Bits 9 até 15 sendo reservados para utilizações de taxas futuras ou alternativas, como desejado, de modo que os mesmos atualmente definidos em '0'. A definição de um valor de bit para um desses bits em '1' indica que aquela taxa de amostra específica é suportada, e a definição do bit em '0' indica que a taxa de amostra não é suportada. Se nenhum microfone for conectado então cada um dos bits de Capacidade de Taxa de Amostra Mic é definido igual a zero.
O campo Tipo de Proteção de conteúdo (2 bytes) contém um conjunto de figas que indicam o tipo de proteção de conteúdo digital que é suportado pelo Display. Atualmente, a posição de bit 0 é utilizada para indicar quando DTCP é suportado e a posição de bit 1 é utilizada para indicar quando HDCP é suportado, com as posições de
153/161 bits 2 até 15 sendo reservadas para utilização com outros esquemas de proteção como desejado ou disponível, de modo que os mesmos sejam atualmente definidos em zero.
G. Para Pacotes de Status e Solicitação de
Display
O campo Solicitação de Link Reverso (3 bytes) especifica o número de bytes que o display necessita no link reverso no próximo subquadro para enviar informações para o hospedeiro.
O campo Contagem de Erro de CRC (1 byte) indica quanto erros de CRC ocorreram desde o início do guadromídia. A contagem de CRC é redefinida quando um pacote de cabeçalho de subquadro com uma Contagem de Subquadro de zero é enviada. Se o número efetivo de erros de CRC exceder 255 então esse valor geralmente satura em 255.
O campo Mudança de Capacidade utiliza 1 byte para indicar uma mudança na capacidade do display. Isto podería ocorrer se um usuário conectar um dispsitivo periférico como um microfone, teclado ou display ou por algum outro motivo. Quando Bits p:0] são iguais a 0, então a capacidade não foi alterada desde que o último Pacote de Capacidade de Display foi enviado. Entretanto, quando os Bits[7:0] são iguais a 1 até 255, a capacidade mudou. O Pacote de Capacidade de Display é examinado para determinar as novas características de display.
H. Para Pacotes de Transferência de Bloco de Bits
Os campos Valor Y e Valor X de Coordenada esquerda superior da janela utilizam 2 bytes cada para especificar o valor X e Y das coordenadas do canto esquerdo superior da janela a ser movida. Os campos Altura e Largura de Jar.ela utilizam 2 bytes cada para especificar a largura e altura da janela a ser movida. Os campos Movimento Y e Movimento X da Janela utilizam 2 bytes cada para
154/161
Figure BRPI0410885B1_D0038
especificar o número de pixels que a janela deve ser movida horizontal e verticalmente, respectivamente. Tipicamente, essas coordenadas são configuradas de tal modo que valores positivos para X fazem com que a janela seja movida para a direita, e valores negativos causam movimento para a esquerda, enquanto valores positivos para Y fazem com que a janela seja movida para baixo e valores negativos causam movimento para cima.
I. Para Pacotes de Preenchimento de Área de Mapa de Bits
Os campos Valor Y e Valor X da Coordenada esquerda superior da janela utilizam 2 bytes cada para especificar o valor X e Y das coordenadas do canto esquerdo superior da janela a ser preenchida. Os campos Altura e Largura da janela (2 bytes cada) especificam a largura e altura da janela a ser preenchida. O campo Descritor de Formato de dados de video (2 bytes) especifica o formato do Valor de preenchimento de área de pixel. O formato é igual ao mesmo campo no Pacote de Fluxo de Video. O campo Valor de Preenchimento de Área de Pixel (4 bytes) contém o valor de pixel a ser preenchido na janela especificada pelos campos discutidos acima. O formato desse pixel é especificado no campo Descritor de Formato de dados de video.
J.
Para Pacotes de Preenchimento de
Padrão de
Mapa de Bits
Os campes Valor Y e Valor X de Coordenada Esquerda superior da Janela utilizam 2 bytes cada para especificar o valor X e Y das coordenadas do canto esquerdo superior da janela a ser preenchida. Os campos Altura e Largura de janela (2 bytes cada) especificam a largura e altura da janela a ser preenchida. Os campos Altura de Padrão e Largura de padrão (2 bytes cada) especificam a
155/161 largura e altura, respectivamente, do padrão de preenchimento. O campo Descritor de Formato de Dados de vídeo especifica o formato do valor de Preenchimento de área de pixel. A figura 11 ilustra como o Descritor de Formato de dados de vídeo é codificado. O formato é igual ac mesmo campo no Pacote de fluxo de vídeo.
O campo CRC de Parâmetro (2 bytes) contém um CRC de todos os bytes do Comprimento de Pacote para o Descritor de formato de vídeo. Se esse CRC falhar em verificar então o pacote inteiro é descartado. O campo Dados de pixel de padrão contém informações de vídeo brutas que especificam o padrão de preenchimento no formato especificado pelo Descritor de formato de dados de vídeo. Os dados são empacotados em bytes, e o primeiro pixel de cada linha deve ser alinhado em bytes. Os dados de padrão de preenchimento são transmitidos uma linha de cada vez. O campo CRC de Pixel de Padrão (2 bytes) contém um CRC somente dos Dados de Pixel de padrão. Se esse CRC falhar em verificar então os Dados de pixel de padrão podem ser ainda utilizados, porém a contagem de erro de CRC é incrementada.
K. Pacotes de Canal de Dados de Link de Comunicação
O campo CRC de Parâmetro (2 bytes) contém um CRC de 16 bits de todos os bytes do Comprimento de Pacote para o Tipo de Pacote. Se esse CRC falhar em verificar então o pacote inteiro é descartado.
O campo Dados de Link de Comunicação contém os dados brutos do canal de comunicação. Esses dados são simplesmente passados para o dispsitivo de computação no dispiay.
campo CRC de dados de link de Comunicação (2 bytes) contém um CRC de 16 bits somente dos Dados de Link de comunicação. Se esse CRC falhar em verificar então cs
156/161
Dados de Link de comunicação ainda são utilizados ou úteis, porém a contagem de erro CRC é incrementada.
L. Para Pacotes de Solicitação de Handoff Tipo de
Interface
O campo Tipo de Interface (1 byte) especifica o novo tipo de interface a se utilizar. O valor nesse campo especifica o tipo de interface do seguinte modo. Se o valor no Bit 7 for igual a '0' a solicitação de handoff de Tipo é para o link direto, se for igual a '1', então a solicitação de handoff de Tipo é para o link reverso. Bits 6 até 3 são reservados para utilização futura, e são geralmente definidos em zero. Os Bits 2 até 0 são utilizados para definir o Tipo de Interface a ser utilizado, com um valor de 1 significando um handoff para o modo Tipo-I, valor de 2 um handoff para o modo Tipo-II, um valer de 3 um handoff para o modo Tipo-III, e um valor de 4 um handoff para o modo Tipo-IV. Os valores de '0' e 5 até 7 são reservados para designação futura de modos alternativos ou combinações de modos.
M. Para Pacotes de Confirmação do Tipo de
Interface
O campo Tipo de Interface (1 byte) tem um valor que confirma o novo tipo de interface a utilizar. O valor nesse campo especifica o tipo de interface do seguinte modo. Se o Bit 7 for igual a '0' a solicitação de handoff do Tipo é para o link direto, alternativamente, se for igual a '1' a solicitação de handoff do Tipo é para o link reverso. As posições de bit 6 até 3 são atualmente reservadas para utilização na designação de outros tipos de handoff, como desejado, e são geralmente definidas em zero. Entretanto, as posições de bit 2 até 0 são utilizadas para definir o Tipo de interface a ser utilizado com um valor de '0' indicando uma confirmação negativa, ou que handoff
157/161
Π solicitado não pode ser executado, os valores de '1', '2' , '3' e '4' indicando handoff para os modos do Tipo-I, TipoII, Tipo-III e Tipo-IV, respectivamente. Os valores de 5 até 7 são reservados para utilização com designações alternativas de modos, conforme desejado.
N. Para Pacotes de Handoff do Tipo de Execução
O campo Tipo de Interface de 1 byte indica o novo tipo de interface a utilizar. O valor presente nesse campo especifica o tipo de interface primeiramente utilizando o valor de Bit 7 para determinar se o handoff de Tipo é ou nãc para os links direto ou reverso. Um valor de '0' indica que a solicitação de handoff de Tipo é para o link direto, e um valor de '1' o link reverso. Os bits 6 até 3 são reservados para utilização futura, e como tal são geralmente definidos em um valor de zero. Entretanto, os bits 2 até 0 são utilizados para definir o Tipo de interface a ser utilizado, com os valores 1, 2, 3 e 4 especificando a utilização de handoff para os modos Tipo-I, Tipo-II, Tipo-III e Tipo-IV, respectivamente. A utilização de valores 0 e 5 até 7 para esses bits é reservado para utilização futuro.
O. Para pacotes de Habilitação de Canal de Áudio
Direto
O campo Máscara de habilitação de canal de (1 byte) contém um grupo de flags que indicam quais canais de áudio devem ser habilitados em um cliente. Um bit definido em um habilita o canal correspondente, e um bit definido em zero desabilita o canal correspondente. Os bits 0 até 5 designam os canais 0 até 5 que tratam dos canais frontal esquerdo, frontal direito, traseiro esquerdo, traseiro direito, centro frontal e sub-woofer, respectivamente. Os bits 6 e 7 são reservados para utilização futura, e enquanto isso são geralmente definidos iguais a zero.
Figure BRPI0410885B1_D0039
158/161
P. Para Pacotes de Taxa de Amostra de Áudio
Reversa campo Taxa de Amostra de Áudio (1 byte) especifica a taxa de amostra de áudio digital. Os valores para esse campo são atribuídos às diferentes taxas com valores de 0, 1, 2, 3, 4, 5, 6, 7 e 8 sendo utilizados para designar 8.000, 16.000, 24.000, 32.000, 40.000, 48.000,
11.025, 22.050, e 44.100 amostras por segundo (SPS), respectivamente com valores de 9 até 254 sendo reservados para utilização com taxas alternativas, como desejado, de modo que são atualmente definidos em '0' . Um valor de 255 é utilizado para desabilitar o fluxo de áudio de link reverso.
O campo Formato de Amostra (1 byte) especifica o formato das amostras de áudio digitais. Quando Bits[l:0] são iguais a '0' , as amostras de áudio digitais estão no formato linear, quando são iguais a 1, as amostras de áudio digitais estão no formato Lei-μ e quando são iguais 2, as amostras de áudio digitais estão no formato Lei-A. Bits [7:2] são reservados para utilização alternada na designação de formatos de áudio, como desejado, e são geraimente definidos iguais a zero.
Q. Para os Pacotes de Overhead de Proteção de Conteúdo Digital
O campo Tipo de Proteção de Conteúdo (1 byte) especifica o método de proteção de conteúdo digital que é utilizado. Um valor '0' indica Proteção de Conteúdo de Transmissão Digital (DTCP) enquanto um valor 1 indica Sistema de Proteção de conteúdo digital com largura de banda alta (HDCP) . A faixa de valores de 2 até 255 não é atualmente especificada porém é reservada para utilização com esquemas de proteção alternativos como desejado. 0 campo Mensagens Overhead de Proteção de Conteúdo é um campo de comprimento variável contendo mensagens de proteção de conteúdo enviadas entre o hospedeiro e o cliente.
Figure BRPI0410885B1_D0040
159/161
R. Para os Pacotes de Habilitação de Cor
Transparente
Campo Habilitação de Cor Transparente (1 byte) especifica quando o modo de cor transparente é habilitado ou desabilitado. Sc o Bit 0 for igual a 0 então o modo de cor transparente é desabilitado, se for igual a 1 então o modo de cor transparente é habilitado e a cor transparente é especificada pelos dois parâmetros gue se seguem. Os bits 1 até 7 desse byte são reservados para utilização futura e são tipicamente definidos iguais a zero.
O campo Descritor de Formato de Dados de vídeo (2 bytes) especifica o formato do Valor de Preenchimento de área de pixels. A figura 11 ilustra como o Descritor de Formato de dados de vídeo é codificado. O formato é geralmente igual ao mesmo campo no Pacote de fluxo de video.
O campo Valor de Preenchimento de área de pixels utiliza 4 bytes alocados para o valor de pixel a ser preenchido na janela especificada acima. O formato desse pixel é especificado no campo Descritor de Formato de Dados de vídeo.
S. Para Os Pacotes de Medição de Retardo de Ida e
Volta
3C
Em uma modalidade, o campo CRC de Parâmetro (2 bytes) contém um CRC de 16 bits de todos os bytes do Comprimento de Pacote para o Tipo de Pacote. Se esse CRC falhar em verificar então o pacote intei.ro é descartado.
campo Todos Zero (1 byte) contém zeros para assegurar que todos os sinais de MDDI_Data estejam no estado zero antes da desabiiitaçào dos drivers de linha durante o primeiro período de Tempo de Guarda.
campo Tempo de Guarda 1 (8 bytes) é utilizado para permitir que os drivers de linha MDDI Data no
Figure BRPI0410885B1_D0041
16C/161 hospedeiro desabilitem antes da habilitação dos drivers de linha no cliente (display). O hospedeiro desabilita seus drivers de linha MDDI_Data durante bit 0 de Tempo de Guarda 1 e o Display habilita seus drivers de linha imediatamente após o último bit do Tempo de Guarda 1.
O campo Período de Medição é uma janela de 512 bytes utilizada para permitir que o Display responda com Oxff, Oxff, 0x0 na metade da taxa de dados utilizada no link direto. Essa taxa corresponde a um Divisor de Taxa de Link reverso de 1. Essa resposta será recebida em um hospedeiro precisamente no retardo de ida e volta do link após o início do primeiro bit do Período de Medição no hospedeiro. Os drivers de linha MDDI_Data no Display sãc desabilitados imediatamente antes e imediatamente após a resposta Oxff, Oxff, 0x00 do Display.
O valor no campo Tempo de Guarda 2 (8 bytes) permite que os drivers de linha MDDI_Data do Cliente desabilitem antes da habilitação dos drivers de linha no Hospedeiro. O Tempo de Guarda 2 está sempre presente porém somente é necessário quando o retardo de ida e volta está na proporção máxima que pode ser medida no Período de Medição. O Cliente desabilita seus drivers de linha durante bit 0 do Tcmpc de Guarda 2 e o Hospedeiro habilita seus drivers de linha imediatamente após o último bit do Tempo de Guarda 2.
O campo Reabilitar Driver (1 byte) é definido igual a zero, para assegurar que todos os sinais MDDl_Data sejarr. reabilitados antes do Campo Comprimento de Pacote do próximo pacote.
T. Para os Pacotes de Calibragem de Distorção de Link Direto
Em uma modalidade, o campo CRC de Parâmetro (2 bytes) contém um CRC de 16 bits de todos os bytes do
161/161
Μ A
Comprimento de Pacote para o Tipo de Pacote. Se esse CRC falhar em verificar então o pacote inteiro é descartado.
O campo Seqüência de Dados de calibragem contém uma seqüência de 512 bytes que faz com que os sinais
todo período de dados. Durante o
ência de Dados de calibragem, o
de MDDI define todos os sinais
sinal de estrobo 0 circuito de
> de displ ay deve utilizar somente
MDDI_Stb em vez de MDDI_Stb Xor MDDI_DataO para recuperar o relógio de dados enquanto o campo Seqüência de Dados de calibragem está sendo recebido pelo Display do cliente. Dependendo da fase exata do sinal MDDI_Stb no início do campo de Seqüência de Dados de calibragem, a Seqüência de Dados de calibragem será geralmente uma das seguintes com base no Tipo de interface sendo utilizado quando esse pacote é enviado:
Tipo-I - Oxaa, Oxaa... ou 0x55, 0x55...
Tipo-II - Oxcc, Oxcc...
Tipo-III - OxfO, OxfO..
Tipo-IV - Oxff, 0x00, Oxff, 0x00... ou 0x00, Oxff, 0x00, Oxff...
ou 0x33, 0x33.. . ou OxOf, OxOf
Um exemplo das formas de onda MDDI_Data e MDDI_Stb para as interfaces tanto Tipo-I como Tipo-II é mostrado nas figuras 62A e 62B, respectivamente.
XVII. Conclusão
Embora várias modalidades da presente invenção tenham sido descritas acima, deve ser entendido que elas foram apresentadas somente como exemplo, e não limitação. Desse modo, a amplitude e escopo da presente invenção não devem ser limitados por nenhuma das modalidades exemplares acirr.a descritas, porém devem ser definidas somente de acordo com as seguintes reivindicações e seus equivalentes.
1/4

Claims (13)

  1. REIVINDICAÇÕES
    1. Aparelho (4900, 6300) para obter sincronização em um sistema eletrônico transferindo dados digitais a uma alta taxa entre um dispositivo hospedeiro (202) e um
    5 dispositivo cliente (204) através de um percurso de comunicação (206), o aparelho (4900, 6300) caracterizado pelo fato de ser configurado para possuir pelo menos um estado de sincronização dentre Estados de Aquisição de Sincronização (4902, 4906), e pelo menos dois estados de
    10 sincronização dentre Estados Em Sincronização (4908, 4910, 4912), em que uma condição para se deslocar de um Estado Em Sincronização para um Estado de Aquisição de Sincronização (4902, 4906) é detectar a presença de um valor de CRC ruim em uma série de pacotes e em que uma condição para se
    15 deslocar entre dois Estados de Aquisição de Sincronização (4902, 4906) é detectar a presença de um padrão de sincronização no link de comunicação e em que uma condição para se deslocar de um Estado de Aquisição de Sincronização (4902, 4906) para um Estado Em Sincronização é detectar a
    20 presença de um pacote de cabeçalho de subquadro e valor de CRC bom em uma fronteira de subquadro.
  2. 2. Aparelho, de acordo com a reivindicação 1, caracterizado pelo fato de que uma condição para se deslocar de um Estado Em Sincronização para um Estado de
    25 Aquisição de Sincronização (4902, 4906) é detectar a presença de um padrão sem sincronização ou um valor de CRC ruim em uma fronteira de subquadro.
  3. 3. Aparelho, de acordo com a reivindicação 1, caracterizado pelo fato de que uma condição para se
    30 deslocar de um Estado Em Sincronização para um segundo Estado Em Sincronização é detectar a presença de um padrão sem sincronização ou um valor de CRC ruim em uma fronteira de subquadro.
    Petição 870170085029, de 06/11/2017, pág. 6/11
    2/4
  4. 4. Aparelho, de acordo com a reivindicação 1, caracterizado pelo fato de que uma condição para se deslocar de um Estado de Aquisição de Sincronização (4902, 4906) para um Estado Em Sincronização ao detectar a
  5. 5 presença de um padrão de sincronização no link de comunicação compreende ainda detectar a presença de um valor de CRC de pacote bom.
    5. Aparelho, de acordo com a reivindicação 1, caracterizado pelo fato de que uma condição para se
    10 deslocar de um Estado Em Sincronização para um Estado de Aquisição de Sincronização (4902, 4906) é detectar a presença de um valor de CRC ruim em um pacote.
  6. 6. Aparelho, de acordo com a reivindicação 1, caracterizado pelo fato de que uma condição para se
    15 deslocar diretamente de um Estado Em Sincronização para um Estado de Aquisição de Sincronização (4902, 4906) é detectar quando uma palavra exclusiva não ocorre em um momento em que é esperado chegar.
  7. 7. Método de transferir dados digitais a uma taxa
    20 alta entre um dispositivo hospedeiro (202) e um dispositivo cliente (204) através de um percurso de comunicação (206) para apresentação a um usuário, o método compreendendo as etapas de:
    gerar uma ou mais dentre uma pluralidade de
    25 estruturas de pacote predefinidas e ligar as mesmas entre si para formar um protocolo de comunicação predefinido;
    comunicar um conjunto pré-selecionado de dados de apresentação e controle digitais entre os dispositivos cliente e hospedeiro através do percurso de comunicação
    30 utilizando o protocolo de comunicação;
    acoplar pelo menos um controlador de link de hospedeiro residindo no dispositivo hospedeiro ao dispositivo cliente através do percurso de comunicação, o
    Petição 870170085029, de 06/11/2017, pág. 7/11
    3/4 controlador de link de hospedeiro sendo configurado para gerar, transmitir e receber pacotes formando o protocolo de comunicação, e formar dados de apresentação digitais em um ou mais tipos de pacotes de dados;
    transferir dados na forma de pacotes através do percurso de comunicação utilizando os controladores de link;
    o método caracterizado por:
    despertar um link de comunicação acionando uma linha de dados para um estado de alta por pelo menos 150 ciclos de relógio; e começar a transmitir um sinal de estrobo como se a linha de dados fosse zero, por meio do hospedeiro.
  8. 8. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que compreende adicionalmente acionar a linha de dados baixa por 50 ciclos de relógio pelo hospedeiro enquanto continuando a transmitir um sinal de estrobo após o hospedeiro ter acionado a linha de dados alta por 150 ciclos de relógio.
  9. 9. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que compreende adicionalmente começar a transmitir o primeiro pacote de cabeçalho de subquadro por meio do hospedeiro.
  10. 10. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que compreende adicionalmente contar pelo menos 150 ciclos de relógio contínuos da linha de dados em estado de alta, seguido por pelo menos 50 ciclos de relógio contínuos da linha de dados em estado de baixa, por meio do cliente.
  11. 11. Método, de acordo com a reivindicação 10, caracterizado pelo fato de que compreende adicionalmente buscar pela palavra exclusiva do primeiro subquadro por meio do cliente.
    Petição 870170085029, de 06/11/2017, pág. 8/11
    Μ 4
  12. 12. Método, de acordo com a reivindicação 10, caracterizado pelo fato de que compreende adicionalmente parar de acionar a linha de dados alta por meio do cliente após o cliente contar 70 ciclos de relógio contínuos dos
    5 dados em estado de alta.
  13. 13. Método, de acordo com a reivindicação 12, caracterizado pelo fato de que compreende adicionalmente contar outros 80 ciclos de relógio contínuos da linha de dados em estado de alta para alcançar os 150 ciclos de
    10 relógio da linha de dados em estado de alta por meio do cliente, e procurar 50 ciclos de relógio da linha de dados em estado de baixa e procurar a palavra exclusiva.
    Petição 870170085029, de 06/11/2017, pág. 9/11
    1/53
    CL
    Ο
    α.
    <
    C£
    Ο
    Ο <
    ΙΟ α_
BRPI0410885-0A 2003-06-02 2004-06-02 Gerar e implementar um protocolo de sinal e interface para taxas de dados mais altas BRPI0410885B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US47545903P 2003-06-02 2003-06-02
US60/475,459 2003-06-02
PCT/US2004/017579 WO2004110021A2 (en) 2003-06-02 2004-06-02 Generating and implementing a signal protocol and interface for higher data rates

Publications (2)

Publication Number Publication Date
BRPI0410885A BRPI0410885A (pt) 2006-08-29
BRPI0410885B1 true BRPI0410885B1 (pt) 2018-01-30

Family

ID=33511679

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0410885-0A BRPI0410885B1 (pt) 2003-06-02 2004-06-02 Gerar e implementar um protocolo de sinal e interface para taxas de dados mais altas

Country Status (12)

Country Link
US (3) US8705579B2 (pt)
EP (3) EP2045994B1 (pt)
JP (2) JP4777882B2 (pt)
KR (3) KR101166734B1 (pt)
CN (4) CN103220282B (pt)
AT (3) ATE517500T1 (pt)
BR (1) BRPI0410885B1 (pt)
DE (1) DE602004030236D1 (pt)
ES (1) ES2357234T3 (pt)
IL (1) IL172106A0 (pt)
TW (1) TWI374635B (pt)
WO (1) WO2004110021A2 (pt)

Families Citing this family (84)

* Cited by examiner, † Cited by third party
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
ATE517500T1 (de) 2003-06-02 2011-08-15 Qualcomm Inc Erzeugung und umsetzung eines signalprotokolls und schnittstelle für höhere datenraten
EP2363990B1 (en) 2003-08-13 2018-03-07 Qualcomm Incorporated A signal interface for higher data rates
BRPI0414229A (pt) * 2003-09-10 2006-10-31 Qualcomm Inc interface de elevada taxa de dados
KR100882164B1 (ko) 2003-10-15 2009-02-06 퀄컴 인코포레이티드 높은 데이터 레이트 인터페이스
CN1902880A (zh) 2003-10-29 2007-01-24 高通股份有限公司 高数据速率接口
JP4782694B2 (ja) * 2003-11-12 2011-09-28 クゥアルコム・インコーポレイテッド 改善されたリンク制御を有する高速データレートインタフェース
MXPA06006012A (es) * 2003-11-25 2006-08-23 Qualcomm Inc Interfase de indice de datos alto con sincronizacion de enlace mejorada.
CA2731265A1 (en) * 2003-12-08 2005-06-23 Qualcomm Incorporated High data rate interface with improved link synchronization
KR100919761B1 (ko) 2004-03-10 2009-10-07 퀄컴 인코포레이티드 고 데이터 레이트 인터페이스 장치 및 방법
EP1735986B1 (en) * 2004-03-17 2013-05-22 Qualcomm, Incorporated High data rate interface apparatus and method
AU2005227500B2 (en) * 2004-03-24 2008-12-04 Qualcomm Incorporated High data rate interface apparatus and method
AU2005253592B2 (en) 2004-06-04 2009-02-05 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
JPWO2006006388A1 (ja) * 2004-07-08 2008-04-24 松下電器産業株式会社 ホスト機器、記憶装置、及び記憶装置へのアクセス方法
US8723705B2 (en) 2004-11-24 2014-05-13 Qualcomm Incorporated Low output skew double data rate serial encoder
US8873584B2 (en) 2004-11-24 2014-10-28 Qualcomm Incorporated Digital data interface device
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
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
KR100923170B1 (ko) * 2004-11-24 2009-10-22 콸콤 인코포레이티드 디지털 데이터 인터페이스 장치
US20060161691A1 (en) * 2004-11-24 2006-07-20 Behnam Katibian Methods and systems for synchronous execution of commands across a communication link
JP2006236159A (ja) * 2005-02-25 2006-09-07 Toshiba Corp 情報処理装置及びその省電力制御方法
US8705550B2 (en) * 2005-08-08 2014-04-22 Qualcomm Incorporated Device interface architecture and protocol
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
EP1992118B1 (fr) 2006-03-07 2011-09-14 Thomson Licensing Dispositif de communication et base pour un affichage evolue
US20070257923A1 (en) * 2006-03-15 2007-11-08 Colin Whitby-Strevens Methods and apparatus for harmonization of interface profiles
US8032672B2 (en) 2006-04-14 2011-10-04 Apple Inc. Increased speed of processing of audio samples received over a serial communications link by use of channel map and steering table
US7702832B2 (en) * 2006-06-07 2010-04-20 Standard Microsystems Corporation Low power and low pin count bi-directional dual data rate device interconnect interface
US20090274254A1 (en) * 2006-06-16 2009-11-05 Panasonic Corporation Data transmitting device and data transmitting method
US9058032B2 (en) * 2006-09-29 2015-06-16 Rockwell Automation Technologies, Inc. Hosting requirements for services
US7924181B1 (en) * 2006-10-20 2011-04-12 Nvidia Corporation System, method, and computer program product for digitally estimating a clock signal associated with an audio signal
KR100917889B1 (ko) * 2006-11-01 2009-09-16 삼성전자주식회사 무선 통신 장치 및 방법
US8356331B2 (en) * 2007-05-08 2013-01-15 Qualcomm Incorporated Packet structure for a mobile display digital interface
KR20090008045A (ko) * 2007-07-16 2009-01-21 삼성전자주식회사 디스플레이장치, 호스트 장치 및 그 제어방법
KR101478240B1 (ko) * 2008-05-06 2015-01-06 삼성전자주식회사 무선 통신 시스템의 자원 할당 방법 및 이를 위한 무선통신 시스템
US8572459B2 (en) * 2008-10-16 2013-10-29 Codman Neuro Sciences Sárl Insuring proper communication with chosen implant among multiple implants in proximity to one another
CN101729652A (zh) * 2008-10-31 2010-06-09 深圳富泰宏精密工业有限公司 具有多媒体功能的便携式电子装置
KR20100109462A (ko) * 2009-03-31 2010-10-08 삼성전자주식회사 디바이스들간의 통신 링크 생성 방법 및 그 장치
US8437721B2 (en) 2009-04-26 2013-05-07 Qualcomm Incorporated Jammer detection based adaptive PLL bandwidth adjustment in FM receiver
US8706124B2 (en) * 2009-09-17 2014-04-22 Nokia Corporation Data path transfer for multiband communication
US8937621B2 (en) 2009-10-22 2015-01-20 Ati Technologies Ulc Method and system for display output stutter
US8188764B2 (en) * 2010-03-18 2012-05-29 Sandisk Technologies Inc. Efficient electrical hibernate entry and recovery
TWI497307B (zh) * 2010-04-21 2015-08-21 Via Tech Inc 通用串列匯流排事務轉譯器及通用串列匯流排傳輸轉譯方法
US9089002B2 (en) 2010-05-16 2015-07-21 Qualcomm Incorporated Efficient group ID management for wireless local area networks (WLANs)
CN101887403B (zh) * 2010-06-25 2012-06-27 钰创科技股份有限公司 节省usb协议中存封包的存储器的数据传输方法及装置
US8462815B2 (en) * 2010-09-02 2013-06-11 Juniper Networks, Inc. Accurate measurement of packet size in cut-through mode
US8918645B2 (en) 2010-09-24 2014-12-23 Amazon Technologies, Inc. Content selection and delivery for random devices
US8886710B2 (en) 2010-09-24 2014-11-11 Amazon Technologies, Inc. Resuming content across devices and formats
US20120079606A1 (en) * 2010-09-24 2012-03-29 Amazon Technologies, Inc. Rights and capability-inclusive content selection and delivery
US8971841B2 (en) 2010-12-17 2015-03-03 Microsoft Corporation Operating system supporting cost aware applications
JP5850224B2 (ja) * 2011-02-28 2016-02-03 株式会社リコー 管理システム、及びプログラム
TWI507702B (zh) * 2011-10-07 2015-11-11 Silicon Image Inc 測試系統、識別待測裝置中缺陷之方法、電腦可讀儲存媒體、高速輸出入裝置及其測試方法
US9341676B2 (en) * 2011-10-07 2016-05-17 Alcatel Lucent Packet-based propagation of testing information
US8938551B2 (en) * 2012-04-10 2015-01-20 Intel Mobile Communications GmbH Data processing device
JP6362277B2 (ja) * 2012-06-01 2018-07-25 ブラックベリー リミテッドＢｌａｃｋＢｅｒｒｙ Ｌｉｍｉｔｅｄ マルチフォーマットオーディオシステムにおけるロック保証のための確率的方法に基づく汎用同期エンジン
CN103780741B (zh) * 2012-10-18 2018-03-13 腾讯科技（深圳）有限公司 提示网速的方法和移动设备
JP2016536695A (ja) * 2013-08-22 2016-11-24 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 通信方法、クライアント、及び端末
EP3080675A4 (en) * 2013-12-13 2017-09-27 Intel Corporation Data receiver circuit with offset edge samplers
US10298360B2 (en) * 2014-02-17 2019-05-21 Yonsei University Wonju Industry-Academic Cooperation Foundation Method and device for determining toggle sequence and error pattern based on soft decision
US9843518B2 (en) 2014-03-14 2017-12-12 International Business Machines Corporation Remotely controlled message queue
US10361721B1 (en) * 2014-05-01 2019-07-23 Marvell International Ltd. Methods and network device for uncoded bit protection in 10GBASE-T Ethernet
JPWO2016042731A1 (ja) * 2014-09-19 2017-07-06 日本電気株式会社 無線制御システム、及び、無線リンクのエラー監視方法
TWI536819B (zh) 2014-12-23 2016-06-01 宏正自動科技股份有限公司 通訊認證系統及使用其之方法
US11238533B2 (en) * 2015-08-19 2022-02-01 Chicago Mercantile Exchange Inc. Optimized electronic match engine with external generation of market data using a minimum data set
US10379747B2 (en) * 2015-12-21 2019-08-13 Western Digital Technologies, Inc. Automated latency monitoring
BR102016008802B1 (pt) * 2016-04-20 2022-10-11 Manoel Henrique Da Silva Aperfeiçoamentos introduzidos em medidor de umidade portátil para uso remoto
DE102016114669A1 (de) * 2016-08-08 2018-02-08 Volkswagen Aktiengesellschaft Verfahren und Bedienvorrichtung zum Bedienen einer Einrichtung
CN107885645B (zh) * 2017-10-31 2020-06-23 阿里巴巴集团控股有限公司 计算页面首屏渲染时长的方法、装置及电子设备
US10642519B2 (en) 2018-04-06 2020-05-05 Western Digital Technologies, Inc. Intelligent SAS phy connection management
US10937434B2 (en) * 2018-05-17 2021-03-02 Mediatek Inc. Audio output monitoring for failure detection of warning sound playback
TWI695205B (zh) * 2018-08-10 2020-06-01 友達光電股份有限公司 影像感測顯示裝置以及影像處理方法
CN109526023B (zh) * 2019-01-02 2021-09-07 上海第二工业大学 一种数据包的封装及校验方法
CN109975649B (zh) * 2019-03-29 2021-06-18 上海剑桥科技股份有限公司 USB Type-C设备类型的检测电路及电源适配器
WO2020256631A1 (en) * 2019-06-18 2020-12-24 Razer (Asia-Pacific) Pte. Ltd. Method and apparatus for optimizing input latency in a wireless human interface device system
KR20210045009A (ko) 2019-10-16 2021-04-26 삼성전자주식회사 인터페이싱 장치, 인터페이싱 장치를 포함하는 반도체 장치 및 반도체 장치의 통신 방법
DE102019128649A1 (de) 2019-10-23 2021-04-29 Infineon Technologies Ag Konzept zur kommunikation zwischen einem mikrocontroller und wenigstens einem sensorchip
CN112402983A (zh) * 2020-08-03 2021-02-26 上海幻电信息科技有限公司 游戏成绩验证方法及系统
TWI793912B (zh) * 2020-12-14 2023-02-21 瑞士商艾姆微體電子 馬林公司 用於感測指向裝置之位移的方法
JPWO2023281665A1 (pt) * 2021-07-07 2023-01-12

Family Cites Families (471)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US5530619A (en) * 1989-06-07 1996-06-25 Norand Corporation Hand-held data capture system with interchangeable modules and side-mounted function key
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
EP0606396B1 (en) * 1991-10-01 2002-06-12 Norand 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
CA2064541C (en) 1992-03-31 1998-09-15 Thomas A. Gray Cycling error count for link maintenance
JPH0637848A (ja) * 1992-07-14 1994-02-10 Hitachi Ltd シリアル通信方式、及びシリアル通信装置
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
US5745523A (en) 1992-10-27 1998-04-28 Ericsson Inc. Multi-mode signal processing
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
WO1994024200A1 (en) 1993-04-16 1994-10-27 Akzo Nobel N.V. 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
KR100370665B1 (ko) 1994-07-25 2004-07-19 지멘스 악티엔게젤샤프트 비디오폰통신의접속및제어방법
US5733131A (en) * 1994-07-29 1998-03-31 Seiko Communications Holding N.V. Education and entertainment device with dynamic configuration and operation
US5664948A (en) 1994-07-29 1997-09-09 Seiko Communications Holding N.V. Delivery of data including preloaded advertising data
JP3592376B2 (ja) 1994-08-10 2004-11-24 株式会社アドバンテスト 時間間隔測定装置
WO1996010230A1 (fr) 1994-09-27 1996-04-04 Sega Enterprises, Ltd. Dispositif de transfert de donnees et jeux video utilisant ce dispositif
GB2296123B (en) * 1994-12-13 1998-08-12 Ibm Midi playback system
US5495469A (en) 1994-12-16 1996-02-27 Chrysler Corporation Communications network, state machine therefor
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
KR100411372B1 (ko) 1995-04-11 2004-05-06 마츠시타 덴끼 산교 가부시키가이샤 비디오정보조정장치,비디오정보송신장치및비디오정보수신장치
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
US5963564A (en) * 1995-06-13 1999-10-05 Telefonaktiebolaget Lm Ericsson Synchronizing the transmission of data via a two-way link
SE506540C2 (sv) 1995-06-13 1998-01-12 Ericsson Telefon Ab L M Synkronisering av överföring av data via en dubbelriktad länk
JPH0923243A (ja) 1995-07-10 1997-01-21 Hitachi Ltd 電子紙面情報配信システム
WO1997003508A1 (fr) * 1995-07-13 1997-01-30 Sony Corporation Procede, appareil et systeme de transmission de donnees
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
WO1997011428A1 (en) * 1995-09-19 1997-03-27 Microchip Technology Incorporated Microcontroller wake-up function having digitally programmable threshold
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
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
US5550489A (en) 1995-09-29 1996-08-27 Quantum Corporation Secondary clock source for low power, fast response clocking
US5751951A (en) 1995-10-30 1998-05-12 Mitsubishi Electric Information Technology Center America, Inc. Network interface
EP0772119A3 (en) 1995-10-31 1997-12-29 Cirrus Logic, Inc. Automatic graphics operation
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 윤종용 그래픽 가속기 및 이를 이용한 메모리 프리패치 방법
US6185601B1 (en) * 1996-08-02 2001-02-06 Hewlett-Packard Company Dynamic load balancing of a network of client and server computers
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
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
US6359923B1 (en) 1997-12-18 2002-03-19 At&T Wireless Services, Inc. Highly bandwidth efficient communications
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
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
US5867510A (en) * 1997-05-30 1999-02-02 Motorola, Inc. Method of and apparatus for decoding and processing messages
JP3143079B2 (ja) 1997-05-30 2001-03-07 松下電器産業株式会社 辞書索引作成装置と文書検索装置
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
US6490620B1 (en) 1997-09-26 2002-12-03 Worldcom, Inc. Integrated proxy interface for web based broadband telecommunications management
ATE429080T1 (de) 1997-10-14 2009-05-15 Cypress Semiconductor Corp Digitaler funksendeempfänger
US6894994B1 (en) 1997-11-03 2005-05-17 Qualcomm Incorporated High data rate wireless packet data communications system
US6574211B2 (en) 1997-11-03 2003-06-03 Qualcomm Incorporated Method and apparatus for high rate packet data transmission
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
ATE500532T1 (de) 1998-02-20 2011-03-15 Puredepth Ltd Mehrschichtige anzeigevorrichtung und verfahren zur darstellung von bildern auf einer solchen anzeigevorrichtung
JP3004618B2 (ja) 1998-02-27 2000-01-31 キヤノン株式会社 画像入力装置及び画像入力システム及び画像送受信システム及び画像入力方法及び記憶媒体
JPH11249987A (ja) 1998-03-05 1999-09-17 Nec Corp メッセージ処理装置およびその方法ならびにメッセージ処理制御プログラムを格納した記憶媒体
DE69936097T2 (de) 1998-03-16 2008-01-17 Jazio Inc., San Jose Hochgeschwindigkeitssignalisierung zur schnittstellenbildung von vlsi cmos-schaltungsanordnungen
DE69927198T2 (de) 1998-03-19 2006-06-29 Hitachi, Ltd. Rundfunk-Informationsversorgungssystem
US6330614B1 (en) * 1998-03-20 2001-12-11 Nexabit Networks Llc Internet and related networks, a method of and system for substitute use of checksum field space in information processing datagram headers for obviating processing speed and addressing space limitations and providing other features
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
EP1414180A3 (en) 1998-04-01 2004-05-06 Matsushita Graphic Communication Systems, Inc. Activation of multiple xDSL modems with implicit channel probe
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> 一体のマイクロコントロ―ラ・エミュレ―タを有するリンク／トランザクション層コントロ―ラ
US7180951B2 (en) * 1998-10-30 2007-02-20 Broadcom Corporation Reduction of aggregate EMI emissions of multiple transmitters
EP1125401B1 (en) 1998-10-30 2005-06-08 Broadcom Corporation Internet gigabit ethernet transmitter architecture
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
CN1240198C (zh) 1998-12-07 2006-02-01 三星电子株式会社 在码分多址移动通信系统中用于选通发送的设备和方法
US6791379B1 (en) 1998-12-07 2004-09-14 Broadcom Corporation Low jitter high phase resolution PLL-based timing recovery system
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
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
CA2365750A1 (en) 1999-03-05 2000-09-14 Accenture Llp A system, method and article of manufacture for advanced mobile communication
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
US6609167B1 (en) 1999-03-17 2003-08-19 Adaptec, Inc. Host and device serial communication protocols and communication packet formats
US6636922B1 (en) 1999-03-17 2003-10-21 Adaptec, Inc. Methods and apparatus for implementing a host side advanced serial protocol
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
EP1228578A1 (de) 1999-11-11 2002-08-07 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
DE60005993T2 (de) 1999-11-16 2004-07-29 Broadcom Corp., Irvine Verfahren und netzwerkvermittlungsstelle mit datenserialisierung durch gefahrlose mehrstufige störungsfreie multiplexierung
DE10085218T1 (de) 1999-11-22 2002-10-31 Seagate Technology Llc Shakope Peer-To-Peer-Zwischenschaltungsdiagnostik
AU7728300A (en) 1999-11-22 2001-06-04 Ericsson Inc. Buffer memories, methods and systems for buffering having seperate buffer memories for each of a plurality of tasks
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 富士フイルム株式会社 ディジタルカメラを用いたコンピュータシステム
US7373650B1 (en) 2000-02-01 2008-05-13 Scientific-Atlanta, Inc. Apparatuses and methods to enable the simultaneous viewing of multiple television channels and electronic program guide content
US7383350B1 (en) 2000-02-03 2008-06-03 International Business Machines Corporation User input based allocation of bandwidth on a data link
JP3490368B2 (ja) 2000-02-07 2004-01-26 インターナショナル・ビジネス・マシーンズ・コーポレーション 信号出力装置、ドライバ回路、信号伝送システム、および信号伝送方法
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
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
CA2813651C (en) 2000-03-03 2014-07-08 Qualcomm Incorporated Method and apparatus for participating in group communication services in an existing communication system
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
US6714233B2 (en) * 2000-06-21 2004-03-30 Seiko Epson Corporation Mobile video telephone system
JP3415567B2 (ja) 2000-06-21 2003-06-09 エヌイーシーマイクロシステム株式会社 Ｕｓｂ転送制御方法およびｕｓｂコントローラ
US6999432B2 (en) * 2000-07-13 2006-02-14 Microsoft Corporation Channel and quality of service adaptation for multimedia over wireless networks
US7917602B2 (en) 2000-08-08 2011-03-29 The Directv Group, Inc. Method and system for remote television replay control
US6784941B1 (en) 2000-08-09 2004-08-31 Sunplus Technology Co., Ltd. Digital camera with video input
CN1252954C (zh) 2000-08-09 2006-04-19 Sk泰力康姆株式会社 支持上行链路同步传输方案的无线电信系统切换方法
US6725412B1 (en) 2000-08-15 2004-04-20 Dolby Laboratories Licensing Corporation Low latency data encoder
JP2002062990A (ja) 2000-08-15 2002-02-28 Fujitsu Media Device Kk インターフェイス装置
GB2366926A (en) 2000-09-06 2002-03-20 Sony Uk Ltd Combining material and data
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
US6747964B1 (en) 2000-09-15 2004-06-08 Qualcomm Incorporated Method and apparatus for high data rate transmission in a wireless communication system
JP4146991B2 (ja) * 2000-09-18 2008-09-10 キヤノン株式会社 電子カメラシステム、電子カメラ及び電子カメラシステムの制御方法
US7466978B1 (en) 2000-09-18 2008-12-16 International Business Machines Corporation Telephone network node device
US6760882B1 (en) 2000-09-19 2004-07-06 Intel Corporation Mode selection for data transmission in wireless communication channels based on statistical parameters
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
CN1214553C (zh) 2000-11-17 2005-08-10 三星电子株式会社 在窄带时分双工码分多址移动通信系统中测量传播延迟的设备和方法
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ä
GB2397675B (en) 2000-12-06 2004-09-29 Fujitsu Ltd Verification circuitry
US6973039B2 (en) 2000-12-08 2005-12-06 Bbnt Solutions Llc Mechanism for performing energy-based routing in wireless networks
US6760772B2 (en) 2000-12-15 2004-07-06 Qualcomm, Inc. Generating and implementing a communication protocol and interface for high data rate signal transfer
CA2431492C (en) * 2000-12-15 2011-09-27 Qualcomm Incorporated 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 携帯電話材のメモリを利用した情報端末装置による教育システム
JP3497834B2 (ja) 2001-03-30 2004-02-16 株式会社東芝 ルートリピータ、ｕｓｂ通信システム、ｕｓｂ通信制御方法
CN1159935C (zh) 2001-03-30 2004-07-28 华为技术有限公司 一种提高市区环境下蜂窝移动台定位精度的方法和装置
JP2002359774A (ja) 2001-03-30 2002-12-13 Fuji Photo Film Co Ltd 電子カメラ
US20040004966A1 (en) 2001-04-27 2004-01-08 Foster Michael S. Using virtual identifiers to route transmitted data through a 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
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
WO2003010766A1 (en) 2001-07-23 2003-02-06 Matsushita Electric Industrial Co., Ltd. Information recording medium, and apparatus and method for recording information on information recording medium
WO2003013080A1 (en) * 2001-07-31 2003-02-13 Comverse Ltd. Email protocol for a mobile environment and gateway using same
US7184408B2 (en) * 2001-07-31 2007-02-27 Denton I Claude Method and apparatus for programmable generation of traffic streams
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 日本電気株式会社 Ｄｓｐメモリ間あるいはｄｓｐメモリとｃｐｕ用メモリ（ｄｐｒａｍ）間データ転送方式
CA2459941C (en) * 2001-09-06 2013-09-17 Qiuzhen Zou 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
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
KR100408525B1 (ko) 2001-10-31 2003-12-06 삼성전자주식회사 네트워크에 적응적인 실시간 멀티미디어 스트리밍 시스템및 방법
EP1309133A1 (de) 2001-10-31 2003-05-07 Siemens Aktiengesellschaft Verfahren, Empfangseinrichtung und Sendeeinrichtung zur Bestimmung des schnellsten Nachrichtenpfades ohne Uhrensynchronisation
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
US20030110234A1 (en) 2001-11-08 2003-06-12 Lightsurf Technologies, Inc. System and methodology for delivering media to multiple disparate client devices based on their capabilities
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 삼성전자주식회사 트래픽 정보를 이용한 가입자 라우팅 설정 방법 및 이를위한 기록매체
US20030135863A1 (en) 2002-01-17 2003-07-17 Koninklijke Philips Electronics N.V. Targeted scalable multicast based on client bandwidth or capability
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
US7336139B2 (en) * 2002-03-18 2008-02-26 Applied Micro Circuits Corporation Flexible interconnect cable with grounded coplanar waveguide
US7145411B1 (en) 2002-03-18 2006-12-05 Applied Micro Circuits Corporation Flexible differential interconnect cable with isolated high frequency electrical transmission line
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
US7036066B2 (en) 2002-05-24 2006-04-25 Sun Microsystems, Inc. Error detection using data block mapping
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
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 データ転送制御装置、電子機器及びデータ転送制御方法
EP1376945B1 (en) 2002-06-18 2006-06-07 Matsushita Electric Industrial Co., Ltd. Receiver-based RTT measurement 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.
AU2003272468A1 (en) 2002-09-13 2004-04-30 Digimarc Id Systems, Llc 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 撮像装置及び携帯端末並びに撮像装置製造方法
US7403487B1 (en) 2003-04-10 2008-07-22 At&T Corporation Method and system for dynamically adjusting QOS
JP4288994B2 (ja) * 2003-04-10 2009-07-01 株式会社日立製作所 端末装置、配信サーバ、映像データの受信方法及び映像データの送信方法
WO2004093452A2 (en) * 2003-04-17 2004-10-28 Thomson Licensing Data requesting and transmitting devices and processes
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 パイオニア株式会社 情報通信装置、そのシステム、その方法、そのプログラム、および、そのプログラムを記録した記録媒体
ATE517500T1 (de) * 2003-06-02 2011-08-15 Qualcomm Inc Erzeugung und umsetzung eines signalprotokolls und schnittstelle für höhere datenraten
US6975145B1 (en) 2003-06-02 2005-12-13 Xilinx, Inc. Glitchless dynamic multiplexer with synchronous and asynchronous controls
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
EP2363990B1 (en) 2003-08-13 2018-03-07 Qualcomm Incorporated A signal interface for higher data rates
BRPI0414229A (pt) * 2003-09-10 2006-10-31 Qualcomm Inc interface de elevada taxa de dados
US7467202B2 (en) * 2003-09-10 2008-12-16 Fidelis Security Systems High-performance network content analysis platform
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 通信コントローラ、通信システム、通信機器、および通信方法
US7315520B2 (en) * 2003-10-08 2008-01-01 Research In Motion Limited Method and apparatus for dynamic packet transport in CDMA2000 networks
KR100882164B1 (ko) 2003-10-15 2009-02-06 퀄컴 인코포레이티드 높은 데이터 레이트 인터페이스
CN1902880A (zh) 2003-10-29 2007-01-24 高通股份有限公司 高数据速率接口
JP4782694B2 (ja) 2003-11-12 2011-09-28 クゥアルコム・インコーポレイテッド 改善されたリンク制御を有する高速データレートインタフェース
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
MXPA06006012A (es) * 2003-11-25 2006-08-23 Qualcomm Inc Interfase de indice de datos alto con sincronizacion de enlace mejorada.
CA2731265A1 (en) 2003-12-08 2005-06-23 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
KR20060128982A (ko) 2004-01-28 2006-12-14 코닌클리즈케 필립스 일렉트로닉스 엔.브이. 디스플레이 방법 및 디스플레이 시스템
US7868890B2 (en) 2004-02-24 2011-01-11 Qualcomm Incorporated Display processor for a wireless device
JP3786120B2 (ja) 2004-03-09 2006-06-14 セイコーエプソン株式会社 データ転送制御装置及び電子機器
KR100919761B1 (ko) 2004-03-10 2009-10-07 퀄컴 인코포레이티드 고 데이터 레이트 인터페이스 장치 및 방법
EP1735986B1 (en) 2004-03-17 2013-05-22 Qualcomm, Incorporated High data rate interface apparatus and method
AU2005227500B2 (en) 2004-03-24 2008-12-04 Qualcomm Incorporated High data rate interface apparatus and method
DE102004014973B3 (de) 2004-03-26 2005-11-03 Infineon Technologies Ag Parallel-Seriell-Umsetzer
EP1745556A4 (en) 2004-04-21 2012-09-19 DEVICE AND METHOD FOR MULTI-DATA PROCESSING IN A WIRELESS TERMINAL
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
AU2005253592B2 (en) 2004-06-04 2009-02-05 Qualcomm Incorporated High data rate interface apparatus and method
US20060034301A1 (en) * 2004-06-04 2006-02-16 Anderson Jon J 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
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
DE602005023755D1 (de) 2004-07-22 2010-11-04 Ucb Pharma Sa Indolonderivate, verfahren zu deren herstellung und deren anwendungen
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
US7315265B2 (en) * 2004-11-24 2008-01-01 Qualcomm Incorporated Double data rate serial encoder
US8539119B2 (en) 2004-11-24 2013-09-17 Qualcomm Incorporated Methods and apparatus for exchanging messages having a digital data interface device message format
US20060161691A1 (en) 2004-11-24 2006-07-20 Behnam Katibian Methods and systems for synchronous execution of commands across a communication link
US8699330B2 (en) 2004-11-24 2014-04-15 Qualcomm Incorporated Systems and methods for digital data transmission rate control
US8873584B2 (en) 2004-11-24 2014-10-28 Qualcomm Incorporated Digital data interface device
US8692838B2 (en) 2004-11-24 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US8667363B2 (en) 2004-11-24 2014-03-04 Qualcomm Incorporated Systems and methods for implementing cyclic redundancy checks
KR100923170B1 (ko) 2004-11-24 2009-10-22 콸콤 인코포레이티드 디지털 데이터 인터페이스 장치
US8723705B2 (en) * 2004-11-24 2014-05-13 Qualcomm Incorporated Low output skew double data rate serial encoder
EP2479920A3 (en) 2004-11-24 2012-09-05 Qualcomm Incorporated Methods and systems for updating a buffer
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
US20070098002A1 (en) 2005-10-28 2007-05-03 Inventec Corporation Media center operating mode selection control method and system
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
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 대성전기공업 주식회사 시트 온도 조절 스위치 장치

Also Published As

Publication number Publication date
TW200511775A (en) 2005-03-16
EP2001192B1 (en) 2011-05-11
CN101938493B (zh) 2013-10-16
KR20060018875A (ko) 2006-03-02
EP2001192A2 (en) 2008-12-10
US20050021885A1 (en) 2005-01-27
CN1826786A (zh) 2006-08-30
EP2001192A3 (en) 2008-12-17
KR20110108423A (ko) 2011-10-05
US8705579B2 (en) 2014-04-22
US8681817B2 (en) 2014-03-25
ATE509459T1 (de) 2011-05-15
JP2011176810A (ja) 2011-09-08
CN105406947A (zh) 2016-03-16
EP2045994B1 (en) 2011-07-20
US8700744B2 (en) 2014-04-15
CN103220282B (zh) 2016-05-25
EP1629654B1 (en) 2010-11-24
TWI374635B (en) 2012-10-11
US20090055709A1 (en) 2009-02-26
KR101166734B1 (ko) 2012-07-19
KR101105175B1 (ko) 2012-01-12
WO2004110021A2 (en) 2004-12-16
JP4777882B2 (ja) 2011-09-21
ES2357234T3 (es) 2011-04-20
KR101168839B1 (ko) 2012-07-26
CN101938493A (zh) 2011-01-05
ATE489801T1 (de) 2010-12-15
DE602004030236D1 (de) 2011-01-05
JP5054213B2 (ja) 2012-10-24
KR20110067066A (ko) 2011-06-20
EP2045994A1 (en) 2009-04-08
IL172106A0 (en) 2011-08-01
US20090070479A1 (en) 2009-03-12
BRPI0410885A (pt) 2006-08-29
CN103220282A (zh) 2013-07-24
WO2004110021A3 (en) 2005-03-31
ATE517500T1 (de) 2011-08-15
JP2006526967A (ja) 2006-11-24
EP1629654A2 (en) 2006-03-01

Similar Documents

Publication Publication Date Title
BRPI0410885B1 (pt) Gerar e implementar um protocolo de sinal e interface para taxas de dados mais altas
US8635358B2 (en) High data rate interface
CA2725844C (en) Generating and implementing a communication protocol and interface for high data rate signal transfer
US6760772B2 (en) Generating and implementing a communication protocol and interface for high data rate signal transfer
TWI455539B (zh) 透過在一ｍｄｄｉ通訊系統中之一訊框同步訊包為同時間等時的資料流提供多媒體同步化之方法、裝置、與系統及其非過渡電腦可執行媒體
US8756294B2 (en) High data rate interface
US8694663B2 (en) System for transferring digital data at a high rate between a host and a client over a communication path for presentation to a user
KR100906319B1 (ko) 링크 동기화를 갖는 고 데이터 레이트 인터페이스
CA2459941C (en) Generating and implementing a communication protocol and interface for high data rate signal transfer
JP2007509533A (ja) 高速データレートインタフェース
JP2007511017A (ja) 改善されたリンク制御を有する高速データレートインタフェース

Legal Events

Date Code Title Description
B06A Patent application procedure suspended [chapter 6.1 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]
B21F Lapse acc. art. 78, item iv - on non-payment of the annual fees in time

Free format text: REFERENTE A 16A ANUIDADE.

B24J Lapse because of non-payment of annual fees (definitively: art 78 iv lpi, resolution 113/2013 art. 12)

Free format text: EM VIRTUDE DA EXTINCAO PUBLICADA NA RPI 2594 DE 24-09-2020 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDA A EXTINCAO DA PATENTE E SEUS CERTIFICADOS, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.