BRPI0116157B1 - geração e implementação de um protocolo e uma interface de comunicação para transferência de sinal com alta taxa de dados - Google Patents

Abstract

"geração e implementação de um protocolo e uma interface de comunicação para transferência de sinal com alta taxa de dados". uma interface de dados para transferência de dados digitais entre um host e um cliente através de uma via de comunicação, usando estruturas de pacotes ligadas para formar um protocolo de comunicações para comunicar um conjunto pré-selecionado de dados digitais de controle e apresentação. o protocolo de sinal é usado por controladores de link configurados para gerar, transmitir e receber pacotes formando o protocolo de comunicações e para formar dados digitais em um ou mais tipos de pacotes de dados, com pelo menos um residindo no dispositivo host e estando acoplado ao cliente através da via de comunicação. a interface propicia um mecanismo de transferência de dados de alta velocidade, bidirecional, de baixa potência e eficaz em termos de custo através de um link de dados de curto alcance do tipo "serial", que se presta à implementação com conectores miniatura e cabos flexíveis finos, os quais são especialmente úteis para conexão de elementos de display tais como micro-displays de uso pessoal (wearable) para computadores portáteis e dispositivos de comunicação sem fio.

Description

Relatório Descritivo da Patente de Invenção: GERAÇÃO E IMPLEMENTAÇÃO DE UM PROTOCOLO E UMA INTERFACE DE COMUNICAÇÃO PARA TRANSFERÊNCIA DE SINAL COM ALTA TAXA DE DADOS.

HISTÓRICO DA INVENÇÃO I. Campo da Invenção. A presente invenção está relacionada a um protocolo de sinal digital e um processo para a comunicação de sinais entre um dispositivo de comunicação host e um dispositivo de apresentação de áudio/visual cliente em altas taxas de dados. Mais especificamente, a presente invenção está relacionada a uma técnica para a transferência de sinais multimídia e outros tipos de sinais digitais a partir de um dispositivo sem fio para uma unidade de micro-display ou outro dispositivo de apresentação usando um mecanismo de transferência com alta taxa de dados e baixa energia. II. Técnica Correlacionada.

Os computadores, os produtos relacionados a jogos eletrônicos e várias tecnologias de vídeo (por exemplo, DVDs e VCRs de alta definição) progrediram de forma significativa durante os últimos anos, propiciando a apresentação de imagens estáticas, de vídeo, de vídeo sob demanda e gráficas com resolução cada vez maior, mesmo quando da inclusão de alguns tipos de texto, para os usuários finais de tais equipamentos. Tais progressos por sua vez exigiram o uso de dispositivos eletrônicos de visualização de maior resolução, tais como monitores de vídeo de alta definição, monitores HDTV, ou elementos de projeção de imagens especializados. A combinação de tais imagens visuais com dados de áudio de alta definição ou qualidade, tal como ocorre quando do uso de reprodução de sons do tipo CD, DVDs e outros dispositivos que também possuem saídas de sinais de áudio associadas, é usada para criar uma experiência mais realista, rica em conteúdo, ou verdadeiramente multimídia para um usuário final. Além disso, foram desenvolvidos sistemas de som de altas qualidade e mobilidade e para transporte de músicas, tais como reprodutores MP3, para apresentações apenas de áudio para os usuários finais.

Em um típico cenário de apresentação de vídeo, dados de vídeo são tipicamente transferidos usando-se as técnicas correntes em uma taxa que poderia ser melhor denominada como lenta ou média, sendo da ordem de um a dezenas de quilobits por segundo. Tais dados são a seguir acumulados (buffered) ou armazenados em dispositivos de memória transiente ou de longo prazo para reprodução retardada (posterior) através de um dispositivo de reprodução desejado. Como exemplo, imagens podem ser transferidas "através da" ou usando-se a Internet, por meio de um programa residente em um computador que possui um modem ou dispositivo de conexão à Internet, para receber ou transmitir dados úteis para a representação digital de uma imagem. Uma transferência similar pode ocorrer usando-se dispositivos sem fio tais como computadores portáteis equipados com modems sem fio, ou assistentes de dados pessoais (PDAs - Personal Data Assistants) sem fio, ou telefones sem fio.

Uma vez recebidos, os dados são armazenados localmente em elementos, circuitos ou dispositivos de memória, tais como uma memória RAM ou flash, incluindo dispositivos de armazenamento externos, para reprodução. Dependendo da quantidade de dados e da resolução da imagem, a reprodução poderia se iniciar de forma relativamente rápida, ou ser apresentada com um retardo de tempo mais longo. Isto é, em alguns casos a apresentação da imagem permite um certo grau de reprodução em tempo real para imagens de resolução muito baixa ou baixa que não requerem muitos dados, ou o uso de algum tipo de acumulação (buffering), de forma a que após um pequeno retardo, algum material é apresentado enquanto mais material está sendo transferido. Contanto que não ocorram interrupções no link de transferência, uma vez iniciada a apresentação, a transferência fica razoavelmente transparente para o usuário final do dispositivo de apresentação.

Os dados usados para criar ou imagens estáticas ou vídeo com movimentos são amiúde comprimidos usando-se uma dentre várias técnicas bem conhecidas, tais como aquelas especificadas pelo Joint Photographic Experts Group (JPEG) , o Motion Pictures Experts Group (MPEG) e outros órgãos normativos ou companhias bem conhecidas das indústrias de mídia, computadores e comunicações, para acelerar a transferência de dados através de um link de comunicação. Isto permite a transferência de imagens ou dados mais rapidamente pelo uso de um menor número de bits para transferir uma dada quantidade de informações.

Uma vez transferidos os dados para um dispositivo "local", tal como um computador ou outro dispositivo, as informações resultantes são descomprimidas (ou reproduzidas usando-se reprodutores decodificadores especiais) e preparadas para apresentação apropriada com base nos correspondentes elementos de resolução e controle de apresentação disponíveis. Como exemplo, uma típica resolução de vídeo de computador em termos de uma resolução de tela de X por Y pixels varia tipicamente de 480x640 a 600x800 e 1024x1024, apesar de uma diversidade de outras resoluções, serem de um modo geral possíveis, seja por desejo ou necessidade. A apresentação das imagens é também afetada pelo conteúdo da imagem e pela capacidade de certos controladores de vídeo de manipular a imagem em termos de certos níveis de cor predefinidos ou profundidade (bits por pixel usados para gerar as cores) e intensidades de cor, bem como quaisquer bits adicionais de overhead sendo empregados. Como exemplo, uma típica apresentaçao em computador demandaria qualquer coisa em torno de 8 a 32, ou mais, bits por pixel para representar várias cores (matizes e tons), apesar de poderem ser encontrados outros valores.

Pelos valores acima, pode-se perceber que uma dada imagem na tela irá requerer a transferência de algo entre 2,45 megabytes (Mb) e cerca de 33,55 Mb de dados na faixa de resolução e profundidade mais baixa a mais alta, respectivamente. Ao se assistir a imagens de vídeo ou filme a uma taxa de 30 frames por segundo, a quantidade de dados necessária fica 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 disso, pode-se desejar apresentar dados de áudio em conjunto com imagens, tal como para uma apresentação multimídia, ou na forma de uma apresentação separada de áudio de alta resolução, tal como música com qualidade de CD. Podem também ser empregados sinais adicionais referentes a comandos interativos, controles ou outros sinais. Cada uma de tais opções adicionando ainda mais dados a serem transferidos. De qualquer forma, quando se deseja transferir dados de imagens de alta qualidade ou alta resolução e informações de áudio ou sinais de dados de alta qualidade para um usuário final para criar uma experiência rica em conteúdo, é requerido um link de alta taxa de transferência de dados entre os elementos de apresentação e o dispositivo fonte ou host que está configurado para prover tais tipos de dados.

Taxas de dados em torno de 115 quilobytes (Kbps) ou 920 quilobits por segundo (Kbps) podem ser rotineiramente gerenciadas pelas interfaces seriais modernas. Outras interfaces, tais como as interfaces seriais USB, podem acomodar transferências de dados em taxas de até 12 MBps e transferências especializadas de alta velocidade, tais como aquelas configuradas pelo uso do padrão IEEE (Institute of Electrical and Electronics Engineers) 1394, podem ocorrer em taxas da ordem de 50 a 100 MBps. Infelizmente, tais taxas não alcançam as taxas de dados elevadas desejadas acima mencionadas, as quais são contempladas para uso com os futuros dispositivos e serviços de dados sem fio para prover sinais de saída de alta resolução, ricos em conteúdo, para acionar displays de vídeo ou dispositivos de áudio portáteis. Além disso, tais interfaces requerem o uso de uma quantidade significativa de software do host ou sistema e do cliente para operar. Suas pilhas de protocolo de software também criam uma quantidade indesejavelmente grande de overhead, especialmente quando são consideras as aplicações em telefones ou dispositivos móveis sem fio. Ademais, algumas de tais interfaces utilizam cabos volumosos, que são muito pesados e não satisfatórios para aplicações móveis orientadas por uma estética elevada, conectores complexos que aumentam os custos, ou simplesmente consomem muita energia.

Existem outras interfaces conhecidas, tais como a interface de arranjo gráfico de vídeo (VGA - Video Graphics Array) analógico, a interface de vídeo digital (DVI Digital Video Interactive) ou a interface de vídeo gigabit (GVIF - Gigabit Video Interface). As duas primeiras são interfaces do tipo paralelo, que processam dados com taxas de transferência mais altas, mas também empregam cabos pesados e consomem grandes quantidades de potência, da ordem de vários watts. Nenhuma de tais características é apropriada para o uso com dispositivos eletrônicos portáteis para consumidores. Mesmo a terceira interface consome muita energia e utiliza conectores caros ou volumosos.

Para algumas das interfaces acima, bem como outros sistemas/protocolos de dados com taxa muito alta ou mecanismos de transferência associados a transferências de dados para equipamentos de computação de instalação fixa, existe mais uma desvantagem. Para acomodar as taxas de transferência de dados desejadas são também requeridas quantidades substanciais de potência e/ou operação com altos níveis de corrente. Isto reduz em muito a utilidade de tais técnicas para produtos orientados para consumidores de alta mobilidade.

De um modo geral, para acomodar tais taxas de transferência de dados usando alternativas tais como conexões e elementos de transferência do tipo fibras ópticas, também requer um número de conversores e elementos adicionais que introduzem muito mais complexidade e custo do que é desejado para um produto comercial verdadeiramente orientado para consumidor. Além da natureza de um modo geral custosa dos sistemas ópticos até o presente, suas demanda de energia e complexidade impedem seu uso geral para aplicações portáteis de baixo peso e pouca energia. O que falta na indústria para aplicações portáteis ou móveis é uma técnica para prover uma experiência de apresentação com alta qualidade, seja ela baseada em áudio, vídeo, ou multimídia, para usuários finais 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 correntes sendo utilizados simplesmente não podem disponibilizar a saída com o nível de alta qualidade desejado. Freqüentemente, a qualidade percebida que está ausente é resultado de altas taxas de dados que não podem ser obtidas para a transferência dos dados de apresentação de alta qualidade. Portanto, é necessário um novo mecanismo de transferência para elevar o ritmo de transferência (throughput) de dados entre os dispositivos host que provêm os dados e os dispositivos ou elementos de display cliente apresentando uma saída ou emissão para os usuários finais.

RESUMO

As limitações acima, bem como outras, existentes na técnica são solucionadas por modalidades da presente invenção, em que foram desenvolvidos novos protocolo e mecanismo para transferência de dados entre um dispositivo host e um dispositivo receptor cliente com altas taxas de dados.

Uma vantagem das modalidades da invenção é a de que é provida uma técnica para transferência de dados que é menor em complexidade, baixo custo, possuindo alta confiabilidade, que se adapta bem ao ambiente de uso e é muito robusta, permanecendo todavia muito flexível.

As modalidades da invenção estão direcionadas a uma interface móvel para dados digitais (MDDI - Mobile Digital Data Interface) para a transferência de dados digitais em uma alta taxa entre um dispositivo host e um dispositivo cliente através de uma via de comunicação que emprega uma pluralidade ou série de estruturas de pacotes ligadas entre si para formar um protocolo de comunicações para a comunicação de um conjunto pré-selecionado de dados digitais de controle e apresentação entre os dispositivos host e cliente. O protocolo de comunicações ou camada de enlace de sinal é usado por uma camada física de controladores de link de host ou cliente. Pelo menos um controlador de link residente no dispositivo host está acoplado ao dispositivo cliente através da via de comunicação e está configurado para gerar, transmitir e receber pacotes formando o protocolo de comunicações e para formar dados de apresentação digital em um ou mais tipos de pacotes de dados. A interface propicia a transferência bidirecional de informações entre o host e o cliente.

Em outros aspectos de modalidades da invenção, pelo menos um controlador de link de cliente, ou receptor cliente, está disposto no dispositivo cliente e está acoplado ao dispositivo host através da via de comunicação. O controlador de link de cliente está também configurado para gerar, transmitir e receber pacotes formando o protocolo de comunicações e para formar os dados digitais de apresentação em um ou mais tipos de pacotes de dados. De um modo geral, o controlador de host ou link emprega uma máquina de estado (state machine) para o processamento de pacotes de dados usados em comandos ou certos tipos de preparação de sinais e processamento de questionamentos, porém pode usar um processador de uso geral mais lento para manipular dados e alguns dos pacotes menos complexos usados no protocolo de comunicações. 0 controlador de host compreende um ou mais drivers de linha diferencial, enquanto que o receptor cliente compreende um ou mais receptores de linha diferencial acoplados à via de comunicação.

Os pacotes são agrupados dentro de frames de mídia que são comunicados entre os dispositivos host e cliente possuindo um comprimento fixo predefinido com um número predeterminado de pacotes possuindo comprimentos diferentes variáveis. Cada um dos pacotes compreende um campo comprimento de pacote, um ou mais campos dados de pacotes e um campo verificação por redundância cíclica. Um pacote de cabeçalho de subframe é transferido ou posicionado no início de transferências de outros pacotes a partir do controlador de link de host. Um ou mais pacotes do tipo de fluxo (stream) de vídeo e pacotes do tipo de fluxo de áudio são usados pelo protocolo de comunicações para a transferência de dados tipo vídeo e dados tipo áudio, respectivamente, do host para o cliente, através de um link de emissão, para apresentação a um usuário do dispositivo cliente. Um ou mais pacotes do tipo de encapsulamento de link reverso são usados pelo protocolo de comunicações para a transferência de dados do dispositivo cliente para o controlador de link de host.

Os pacotes do tipo preenchimento (filler) são gerados pelo controlador de link de host para ocupar períodos de transmissão do link de emissão que não possuem dados. Uma pluralidade de outros pacotes é usada pelo protocolo de comunicações para a transferência de informações de vídeo. Tais pacotes incluem pacotes do tipo de mapa de cores, transferência de blocos de bits, preenchimento de área de bitmap (bitmap), preenchimento padrão de bitmap e habilitação de cor transparente. Os pacotes do tipo fluxos definidos pelo usuário são usados pelo protocolo de comunicações para a transferência de dados definidos por interface - usuário. Os pacotes do tipo dados de teclado e dados de dispositivo apontador (pointing) são usados pelo protocolo de comunicações para a transferência de dados de ou para dispositivos de entrada de usuário associados ao dispositivo cliente. Um pacote do tipo desativação de link (link shutdown) é usado pelo protocolo de comunicações para terminar a transferência de dados em qualquer das direções através da via de comunicação. A via de comunicação compreende, de um modo geral, um cabo possuindo uma série de quatro ou mais condutores e uma cobertura (shield). Em algumas modalidades, os controladores de link compreendem uma interface de dados USB e o cabo usa uma interface tipo USB juntamente com os outros condutores. Além disso, podem ser usados fios impressos ou condutores flexíveis, conforme desejado. O controlador de link de host requisita informações de capacidades de display a partir do dispositivo cliente de modo a determinar qual tipo de dados e taxas de dados o cliente é capaz de acomodar através da interface. O controlador de link de cliente comunica as capacidades de display ou apresentação ao controlador de link de host usando pelo menos um pacote do tipo capacidade de display. Múltiplos modos de transferência são usados pelo protocolo de comunicações, com cada um permitindo a transferência de diferentes números máximos de bits de dados em paralelo dentro de um dado período de tempo, com cada modo podendo ser selecionado por negociação entre os controladores de link de host e de cliente. Tais modos de transferência são dinamicamente ajustados durante a transferência de dados e o mesmo modo usado no link de emissão não necessita ser usado no link reverso.

Em outros aspectos de algumas modalidades da invenção, o dispositivo host compreende um dispositivo de comunicação sem fio, tal como um telefone sem fio, um PDA sem fio, ou um computador portátil possuindo um modem sem fio nele disposto. Um típico dispositivo cliente compreende um display de vídeo portátil, tal como um dispositivo de micro-display, e/ou um sistema portátil de apresentação de áudio. Além disso, o host pode usar dispositivos ou elementos de armazenamento para armazenar dados de apresentação ou multimídia a serem transferidos para serem apresentados a um usuário de um dispositivo cliente.

BREVE DESCRIÇÃO DOS DESENHOS

Outras características e vantagens da presente invenção, bem como a estrutura e operação de várias modalidades da mesma, estão descritas em detalhes a seguir, com referência aos desenhos anexos. Nos desenhos, referências numéricas similares identificam de um modo geral elementos ou etapas de processamento idênticos, funcionalmente similares e/ou elementos ou etapas de processamento estruturalmente similares, e o desenho em que o elemento aparece pela primeira vez é indicado pelo(s) dígito(s) mais à esquerda na referência numérica. A Figura la ilustra um ambiente básico no qual a presente invenção podería operar, incluindo o uso de um dispositivo de micro-display usado em conjunto com um computador portátil. A Figura lb ilustra um ambiente básico no qual a presente invenção podería operar, incluindo o uso de um dispositivo de micro-display e elementos de apresentação de áudio usados em conjunto com um transceptor sem fio. A Figura 2 ilustra o conceito geral de uma interface móvel para dados digitais com uma interconexão entre host e cliente. A Figura 3 ilustra a estrutura de um pacote útil para realizar transferências de dados de um dispositivo cliente para um dispositivo host. A Figura 4 ilustra o uso de um controlador de link MDDI e os tipos de sinais passados entre um host e um cliente através dos condutores físicos de link de dados para interfaces tipo I e tipo U. A Figura 5 ilustra o uso de um controlador de link MDDI e os tipos de sinais passados entre um host e um cliente através dos condutores físicos de link de dados para interfaces tipos II, II e IV. A Figura 6 ilustra a estrutura de frames e subframes usados para implementar o protocolo de interface. A Figura 7 ilustra a estrutura geral de pacotes usados para implementar o protocolo de interface. A Figura 8 ilustra o formato de um pacote de cabeçalho de subframe. A Figura 9 ilustra o formato e o conteúdo de um pacote de preenchimento. A Figura 10 ilustra o formato de um pacote de fluxo de vídeo. A Figura 11 ilustra o formato e o conteúdo para o descritor (decriptor) de formato de dados de vídeo da Figura 10. A Figura 12 ilustra o uso de formatos empacotados e não empacotados para dados. A Figura 13 ilustra o formato de um pacote de fluxo de áudio. A Figura 14 ilustra o uso de formatos PCM para dados alinhados por byte e empacotados. A Figura 15 ilustra o formato de um pacote de fluxo definido por usuário. A Figura 16 ilustra o formato de um pacote de mapa de cores. 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 dados de teclado. A Figura 20 ilustra o formato de um pacote de dados de dispositivo apontador. A Figura 21 ilustra o formato de um pacote de desativação de link. A Figura 22 ilustra o formato de um pacote de requisição e estado 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 preenchimento de área de bitmap. A Figura 25 ilustra o formato de um pacote de preenchimento padrão de bitmap. A Figura 26 ilustra o formato de um pacote de canal de dados de link de comunicação. A Figura 27 ilustra o formato de um pacote de requisição de transferência (handoff) de tipo de interface. A Figura 28 ilustra o formato de um pacote de confirmação (acknowledge) de tipo de interface A Figura 29 ilustra o formato de um pacote de transferência de tipo de performance. A Figura 30 ilustra o formato de um pacote de habilitação de canal de áudio de emissão. A Figura 31 ilustra o formato de um pacote de taxa de amostras de áudio reverso. A Figura 32 ilustra o formato de um pacote de overhead de proteção ao 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 o timing (temporização) de eventos durante o pacote de medição de retardo de ida-e-volta . A Figura 36 ilustra uma amostra de implementação de um gerador de CRC e um verificador útil para a invenção. A Figura 37a ilustra o timing de sinais de CRC para o equipamento da Figura 36 quando enviando pacotes de dados. A Figura 37b ilustra o timing de sinais de CRC para o equipamento da Figura 36 quando recebendo pacotes de dados. A Figura 38 ilustra as etapas de processamento para uma típica requisição de serviço sem qualquer conflito (contention). A Figura 39 ilustra as etapas de processamento para uma típica requisição de serviço confirmada após o início da sequência de reinicialização de link, conflitando com o início de link. A Figura 4 0 ilustra como uma sequência de dados pode ser transmitida usando-se codificação DATA-STB. A Figura 41 ilustra circuitos úteis para a geração dos sinais DATA e STB a partir de dados de entrada no host e a seguir recuperação dos dados no cliente. A Figura 42 ilustra drivers e resistores terminais úteis para a implementação de uma modalidade da invenção. A Figura 43 ilustra etapas e níveis de sinal empregados por um cliente para obter serviço seguro a partir do host e pelo host para prover tal serviço. A Figura 44 ilustra o espaçamento relativo entre transições na linha DataO, outras linhas de dados (DataX) e linhas de estrobo (strobe) (Stb). A Figura 4 5 ilustra a presença de um retardo em resposta que pode ocorrer quando um host desabilita o driver de host após a transferência de um pacote. A Figura 46 ilustra a presença de um retardo em resposta que pode ocorrer quando um host habilita o driver de host para a transferência de um pacote. A Figura 47 ilustra a relação na entrada do receptor de host entre o timing dos dados sendo transferidos e as bordas de inicial (leading) e final (trailing), dos pulsos de estrobo. A Figura 48 ilustra as características de comutação e o correspondente retardo de saída de cliente desenvolvido pelo timing de dados reversos. A Figura 49 ilustra um diagrama de alto nível das etapas de processamento de sinais pelas quais pode ser implementada a sincronização para a presente invenção usando-se uma máquina de estado. A Figura 50 ilustra as quantidades típicas de retardo encontradas para o processamento de sinais através das vias de emissão e reversa em um sistema que emprega a MDDI . A Figura 51 ilustra a medição do retardo de ida-e-volta marginal. A Figura 52 ilustra mudanças de taxa de dados do link reverso. A Figura 53 ilustra uma representação gráfica de valores do divisor de taxa reversa versus a taxa de dados do link de emissão.

As Figuras 54a e 54b ilustram as etapas encetadas na operação de uma interface. A Figura 55 ilustra uma visão geral dos drivers, receptores, processadores e uma máquina de estado para a implementação de modalidades da invenção. DESCRIÇÃO DETALHADA DAS MODALIDADES I. Visão Geral.

Uma meta geral da invenção consiste em prover uma interface digital de display móvel (MDDI), tal como descrita mais adiante, que resulta em, ou provê, um mecanismo de transferência eficaz em termos de custos, de baixo consumo de energia, que permite a transferência de dados em velocidade alta ou muito alta através de um link de comunicação de curto alcance entre um dispositivo host e um dispositivo de display, usando um tipo "serial" de link ou canal de dados. Tal mecanismo se presta à implementação com conectores miniaturizados e cabos flexíveis delgados, os quais são especialmente úteis para a conexão de elementos ou dispositivos de display, tais como micro-displays de uso pessoal (óculos ou projetores) para computadores portáteis, dispositivos de comunicação sem fio, ou dispositivos de entretenimento. A presente invenção pode ser usada em uma diversidade de situações para comunicação ou transferência de grandes quantidades de dados, de um modo geral para aplicações de áudio, vídeo, ou multimídia, a partir de um dispositivo host ou fonte onde tais dados são gerados ou armazenados, para um display de cliente ou dispositivo de apresentação, em uma alta taxa. Uma aplicação típica que será comentada mais adiante, é a transferência de dados a partir de um computador portátil ou um telefone ou modem sem fio para um dispositivo de display visual, tal como uma pequena tela de vídeo, ou um aparelho de micro-display de uso pessoal (wearable) , tal como na forma de óculos ou capacetes contendo pequenas lentes e telas de projeção.

As características ou atributos da MDDI são tais que eles são independentes da tecnologia específica de display. Este é um mecanismo altamente flexível para a transferência de dados em uma alta taxa sem considerações quanto à estrutura interna de tais dados, nem quanto aos aspectos funcionais dos dados ou comandos que eles implementam. Isto permite que o timing de pacotes de dados sendo transferidos seja ajustado para se adaptar às idiossincrasias de dispositivos de display específicos, ou desejos de apresentação exclusivos para certos dispositivos, ou para atender aos requerimentos de áudio e vídeo combinados para alguns sistemas A-V. A interface é bastante agnóstica em termos do elemento de display ou dispositivo cliente, contanto que o protocolo selecionado seja seguido. Além disso, os dados de link serial agregados ou a taxa de dados podem variar dentro de várias ordens de magnitude, o que permite a um projetista de sistemas de comunicação ou do dispositivo host otimizar o custo, demanda de energia (power), complexidade do dispositivo cliente e taxas de atualização do dispositivo de display. A interface de dados é apresentada primariamente para uso na transferência de grandes quantidades de dados de alta taxa através de um link de sinal por cabo (wired) ou fio curto. No entanto, algumas aplicações podem utilizar também um link sem fio, incluindo links de base óptica, contanto que eles estejam configurados para usar as mesmas estruturas de pacotes e dados desenvolvidas para o protocolo de interface e possam sustentar o nível de transferência desejado com consumo de energia ou complexidade baixos o suficiente para permanecerem práticos. II. Ambiente.

Uma aplicação típica pode ser vista nas Figuras la e 1b, onde um computador portátil ou laptop 100 e um telefone ou dispositivo PDA sem fio 102 são mostrados em comunicação de dados com os dispositivos de display 104 e 106, respectivamente, em conjunto com o sistema de reprodução de áudio 108 e 110 . O dispositivo sem fio pode estar recebendo dados correntemente ou ter anteriormente armazenado uma certa quantidade de dados do tipo multimídia em um elemento ou dispositivo de memória para apresentação posterior para visão e/ou audição por um usuário final do dispositivo sem fio. Uma vez que um típico dispositivo sem fio é usado para comunicações de voz e texto simples na maior parte do tempo, ele possui uma tela de display bastante pequena e um sistema de áudio (alto falantes) simples para a comunicação de informações para o usuário do dispositivo 102. O computador 100 possui uma tela muito maior, porém um sistema de som externo ainda inadequado, ficando ainda abaixo, em termos de qualidade, de outros dispositivos de apresentação multimídia, tais como a televisão de alta definição ou telas para filmes. O computador 100 é usado com o propósito de ilustração, podendo outros tipos de processadores, vídeo games interativos, ou dispositivos eletrônicos para consumidores também serem usados com a invenção. O computador 100 pode empregar, porém sem estar a eles ou por eles limitado, um modem sem fio ou outro dispositivo embutido para comunicações sem fio, ou ser conectado a tais dispositivos pelo uso de um link por cabo ou sem fio, conforme desejado.

Isto torna a apresentação de dados mais complexos ou "ricos" uma experiência menos que útil ou agradável. Portanto, a indústria está desenvolvendo outros mecanismos e dispositivos para apresentação de informações aos usuários finais e para prover um nível mínimo desejado de prazer ou experiências positivas.

Como foi acima descrito, vários tipos de dispositivos de display foram ou estão sendo atualmente desenvolvidos para apresentação de informações aos usuários finais do dispositivo 100. Como exemplo, uma ou mais companhias desenvolveram conjuntos de óculos que projetam uma imagem à frente dos olhos de um usuário do dispositivo para a apresentação de um display visual. Quando posicionados corretamente, tais dispositivos efetivamente "projetam" uma imagem virtual, tal como percebida pelos olhos do usuário, que é muito maior que o elemento que provê a saida ou emissão 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 a possível com o uso de típicas telas de LCD e similares. O uso de imagens de tela virtual maiores também permite o uso de imagens de resolução muito mais alta do que possível com displays mais limitados de tela LCD. Outros dispositivos de display poderíam incluir, porém também não ficam limitados a, pequenas telas LCD ou vários elementos de display de painéis planos, lentes de projeção e drivers de display para a projeção de imagens sobre uma superfície e assim por diante.

Podem também existir elementos adicionais conectados ou associados ao uso do dispositivo sem fio 102 ou computador 100 para apresentar uma saída para outro usuário, ou para outro dispositivo o qual, por sua vez, transfere os sinais para outro local ou os armazena. Como exemplo, os dados podem ser armazenados em memória flash, em forma óptica, por exemplo pelo uso de mídia de CD gravável, ou em mídia magnética, tal como em um gravador de fita magnética e dispositivos similares, para uso posterior.

Além disso, vários dispositivos sem fio e computadores possuem agora capacidades embutidas de decodificação de música MP3, bem como outros decodificadores e sistemas de som avançados. Os computadores portáteis utilizam as capacidades de reprodução de CDs e DVDs como uma regra geral e alguns possuem pequenos leitores de memória flash exclusivos para recepção de arquivos de áudio pré-gravados. A questão de possuir tais capacidades é a de que os arquivos digitais de música prometem uma rica experiência com recursos altamente ampliados, porém apenas se os processos de decodificação e reprodução puderem se manter emparelhados. Isto é também verdadeiro para os arquivos de video digitais.

Para auxiliar à reprodução sonora, alto falantes externos 108 são mostrados na Figura la, os quais poderiam também estar acompanhados por elementos adicionais, tais como alto falantes "subwoofers" ou de "som surround" para projeção sonora frontal e posterior. Da mesma forma, alto falantes ou fones de ouvido 110 são indicados como embutidos na estrutura de suporte ou mecanismo do dispositivo de micro-display 106 da Figura lb. Como é sabido, outros elementos de reprodução de áudio ou som podem ser usados incluindo dispositivos de amplificação de potência ou equalização de som.

De qualquer forma, tal como foi acima mencionado, quando se deseja transferir dados de imagem de alta qualidade ou alta resolução e informações de áudio de alta qualidade ou sinais de dados provenientes de uma fonte de dados para um usuário final através de um ou mais links de comunicação 112, é requerida uma alta taxa de dados. Isto é, o link de transferência 112 constitui claramente um "gargalo" para a comunicação de dados, tal como foi acima descrito, e está limitando o desempenho do sistema, uma vez que os mecanismos atuais de transferência não alcançam as elevadas taxas de dados tipicamente desejadas. Como exemplo, como foi acima mencionado, para resoluções de imagem mais elevadas, tais como 1024 por 1024 pixels, com profundidades ou matizes de cor de 24 a 32 bits por pixel e em taxas de dados de 3 0 fps, as taxas de dados podem se aproximar de taxas acima de 336 Mbps ou mais. Além disso, tais imagens podem ser apresentadas como parte de uma apresentação multimídia que inclui dados de áudio e potencialmente sinais adicionais tratando de jogos interativos ou comunicações, ou vários comandos, controles, ou sinais, aumentando ainda mais a quantidade de dados e a taxa de dados.

Fica também claro que um menor número de cabos ou interconexões requeridos para estabelecer um link de dados, significa que dispositivos móveis associados a um display são de uso mais fácil e de adoção mais provável por uma maior base de usuários. Tal é especialmente verdadeiro quando múltiplos dispositivos são comumente usados para estabelecer uma completa experiência áudio visual e mais especialmente a medida que aumenta o nível de qualidade dos displays e dispositivo de saída de áudio.

Infelizmente, as taxas de dados mais altas superam a tecnologia atualmente disponível para a transferência de dados. O que se necessita é uma técnica para a transferência de dados com taxas mais altas para o link de transferência de dados ou via de comunicação entre elementos de apresentação e a fonte de dados, que possibilite, consistentemente, baixa ou menor consumo de energia, baixo peso e uma estrutura de cabos tão simples e econômica quanto possível. A Requerente desenvolveu novos método ou técnica e equipamento para atingir estas e outras metas, para permitir que um arranjo ou conjunto de dispositivos móvel, portátil ou de localização fixa transfira dados para displays, micro-displays, ou elementos de transferência de áudio desejados, com taxas muito elevadas de dados, mantendo os desejados baixos consumo de energia e complexidade. III. Estrutura do sistema de interface de dados digitais com alta taxa.

Para criar e usar eficientemente uma nova interface de dispositivo, foram formulados um protocolo de sinal e uma estrutura de sistema que propiciam uma taxa muito alta de transferência de dados, usando sinais de baixa potência. O protocolo se baseia em uma estrutura ou estruturas de pacotes e frames comuns ligados entre si para formar um protocolo para a comunicação de um conjunto pré-selecionado de dados ou tipos de dados juntamente com uma estrutura de comandos ou operacional imposta à interface. A. Visão geral.

Os dispositivos conectados ou em comunicação através do link MDDI são denominados como host e cliente, com o cliente sendo tipicamente um dispositivo de display de algum tipo. Os dados provenientes do host para o display viajam na direção de emissão (designados como tráfego ou link de emissão) e os dados provenientes do display para o host viajam na direção reversa (tráfego ou link reverso), conforme habilitado pelo host. Isto está ilustrado na configuração básica apresentada na Figura 2. Na Figura 2, um host 202 é conectado a um cliente 204 usando-se um canal de comunicação bidirecional 206, que está ilustrado como compreendendo um link de emissão 208 e um link reverso 210. No entanto, tais canais são formados por um conjunto comum de condutores, cuja transferência de dados é efetivamente comutada entre as operações de link de emissão ou reverso.

Como foi acima mencionado, o host compreende um dentre vários tipos de dispositivos que podem se beneficiar a partir do uso da presente invenção. Como exemplo, o host 202 podería ser um computador portátil, na forma de um dispositivo de computação móvel portátil, laptop, ou similar, podería ser um PDA, um dispositivo de paging, ou um dentre vários telefones ou modems sem fio. Concomitantemente o cliente 204 podería consistir de uma diversidade de dispositivos úteis para a apresentação de informações a um usuário final. Como exemplo, um micro-display incorporado a óculos ou visores, um dispositivo de projeção embutido em um capacete ou chapéu, uma pequena tela ou elemento holográfico embutido em um veículo, tal como em uma janela ou pára-brisas, ou vários sistemas de som de alto falantes, fones de ouvido para a apresentação de sons ou música de alta qualidade. No entanto, os técnicos na área notarão prontamente que a presente invenção não fica limitada a tais dispositivos, podendo existir vários dispositivos no mercado, ou propostos para uso, que se destinam a prover a usuários finais imagens e som com alta qualidade, seja em termos de armazenamento e transporte, ou em termos de apresentação quando da reprodução. A presente invenção é útil para aumentar o ritmo de transferência de dados entre vários dispositivos para acomodar as altas taxas de dados necessárias para efetivar a desejada experiência para o usuário. B. Tipos de interfaces. A interface MDD é considerada como incluindo cinco ou mais tipos físicos distintos de interfaces encontrados nas industrias de comunicação e computação. Elas são designadas, neste ponto, simplesmente como tipo I, tipo II, tipo III, tipo IV e tipo U. A interface tipo I é configurada na forma de uma interface de 6 fios (condutores) , o que a torna adequada para telefones móveis ou sem fio, PDAs, e-Books, jogos eletrônicos e reprodutores de mídia portáteis, tais como reprodutores de CDs ou reprodutores MP3 e dispositivos de tipos similares de tecnologia eletrônica para consumidores. A interface tipo U é configurada na forma de uma interface de 8 fios (condutores) que é mais adequada para computadores pessoais do tipo laptop, notebooks, ou desktop e dispositivos ou aplicações similares que não requerem que o display seja atualizado rapidamente e não possuem um controlador de link MDDI embutido. Tal tipo de interface pode também ser distinguido pelo uso de uma interface de barramento serial universal (USB - Universal Serial Bus) com dois cabos adicionais, o que é extremamente útil para acomodar os sistemas operacionais existentes ou suportes de software encontrados na maioria dos computadores pessoais. As interfaces tipo U podem também ser usadas em um modo USB exclusivo, em que o display simplesmente possui um conector USB que se conecta a uma porta USB padrão em um computador ou dispositivo similar por exemplo.

As interfaces tipo II, tipo III e tipo IV são adequadas para displays ou dispositivos de alto desempenho e usam cabeamento maior e mais complexo, com condutores adicionais do tipo par trançado (twisted), para prover a cobertura adequada e transferências de baixa perda para sinais de dados. A interface tipo I transporta sinais que podem compreender informações de display, áudio, controle e sinalização limitada e é tipicamente usada para dispositivos que não requerem dados de vídeo de alta resolução e taxa total . Tal tipo de interface se destina principalmente para dispositivos, tais como dispositivos sem fio móveis, em que um host USB não está tipicamente disponível no interior do dispositivo para conexão e transferência de sinais. Em tal configuração, o dispositivo móvel é um dispositivo host MDDI e atua como o "mestre" que controla o link de comunicação proveniente do host, que de um modo geral envia dados de display para o cliente {tráfego ou link de emissão).

Em tal interface, um host habilita a recepção de dados de comunicação no host provenientes do cliente (tráfego ou link reverso) pelo envio de um comando ou tipo de pacote especial para o cliente que permite que ele se aposse do barramento por uma duração especificada e envie dados para o host como pacotes reversos. Isto está ilustrado na Figura 3, em que um tipo de pacote designado como um pacote de encapsulamento (descrito mais adiante) é usado para acomodar a transferência de pacotes reversos através do link de tráfego, criando o link reverso. O intervalo de tempo alocado para que o host pesquise o display quanto a dados é predeterminado pelo host e se baseia nos requerimentos de cada aplicação especificada. Tal tipo de transferência de dados half-duplex bidirecional é especialmente vantajosa quando uma porta USB não está disponível para a transferência de informações ou dados provenientes do cliente. A interface tipo U transfere sinais que são bem adequados para uso em aplicações de laptop e desktop em que uma interface USB é amplamente suportada por muitas placas mãe e outros hardware e por software de sistema operacional. O uso de uma interface USB adicional permite o uso com recursos "plug-and-play" e configuração de aplicações fácil. A inclusão da USB também permite o fluxo bidirecional de uso geral de dados de comandos, estado, áudio e assim por diante, enquanto que os dados de vídeo e áudio destinados ao dispositivo cliente podem ser transferidos usando-se os pares trançados em baixa potência e alta velocidade. A potência pode ser transferida usando-se outros fios, tal como comentado mais adiante. As modalidades da invenção que usam uma interface USB permitem transferências de alta velocidade através de um conjunto de condutores, implementando principalmente a sinalização e controle na conexão USB, a qual pode ser desativada quando fora de uso e que consome pouca energia. A interface USB constitui um padrão extensamente usado para equipamentos modernos de computação pessoal e os detalhes de uma interface USB e sua operação, são bem conhecidos pelos técnicos na área, não sendo portanto explanados aqui. Para a interface USB, a comunicação entre o host e o display ocorre de acordo com a Universal Serial Bus Specification, Revision 2.0. Nas aplicações que usam a interface tipo U, em que o USB é o canal de sinalização principal e possivelmente um canal de retorno de voz, é opcional para o host pesquisar o cliente através dos sinais de dados seriais MDDI.

Os displays de alto desempenho, capazes de altas resoluções do tipo HDTV ou similares, requerem fluxos de dados em torno de 1,5 Gbps de taxa, de modo a suportar video com total movimentação. A interface tipo II suporta altas taxas de dados pela transmissão de 2 bits em paralelo, a tipo III pela transmissão de 4 bits em paralelo e a interface tipo IV transfere 8 bits em paralelo. O protocolo usado pela MDDI permite que cada host do tipo I, II, III, ou IV se comunique com qualquer cliente ou display tipo I, II, III, ou IV por negociação de qual é a maior taxa de dados que pode ser usada. As capacidades ou recursos disponíveis do que pode ser designado como o dispositivo menos capaz, são usadas para ajustar o desempenho do link. Como uma regra, mesmo para sistemas em que o host e o cliente são ambos capazes de uso da interface tipo II, tipo III, ou tipo IV, ambos iniciam a operação como uma interface tipo I . O host a seguir determina a capacidade do cliente ou display meta, e negocia uma transferência ou operação de reconfiguração para ou o modo tipo II, tipo III, ou tipo IV, conforme apropriado para a aplicação específica. É de um modo geral possível para o host utilizar o protocolo da camada de enlace apropriado (adicionalmente comentado mais adiante) e em qualquer momento rebaixar ou novamente reconfigurar a operação para um modo mais lento para economizar energia, ou elevar para um modo mais rápido para suportar transferências de maior velocidade, tais como para maiores resoluções de conteúdo de display. Como exemplo, um host pode mudar os modos de display quando o sistema de display se comuta de uma fonte de energia tal como baterias, para fonte CA, ou quando a fonte de mídia de display se comuta para um formato de resolução mais baixa ou mais alta, ou uma combinação de tais ou outras condições ou eventos pode ser considerada como uma base para mudar um modo de display ou transferência de dados. É também possível para um sistema comunicar dados usando um modo em uma direção e outro modo na outra direção. Como exemplo, um modo de interface tipo IV poderia ser usado para transferência de dados para um display em uma alta taxa, enquanto um modo tipo I ou tipo U é usado quando da transferência de dados para um dispositivo host a partir de dispositivos periféricos, tais como um teclado ou um dispositivo apontador. C. Estrutura de interface física. A disposição geral de um dispositivo ou controlador de link para estabelecer comunicações entre dispositivos de host e cliente é apresentada nas Figuras 4 e 5. Nas Figuras 4 e 5 é mostrado um controlador de link MDDI 402 instalado em um dispositivo host 202 e é mostrado um controlador de link MDDI 404 instalado em um dispositivo cliente 204. Como antes, o host 202 está conectado a um cliente 2 04 pelo uso de um canal de comunicação bidirecional 406 compreendendo uma série de condutores. Como será comentado mais adiante, ambos os controladores de link de host e de cliente podem ser fabricados na forma de um circuito integrado usando um único desenho de circuito que pode ser configurado, ajustado, ou programado para responder como um controlador de host (driver) ou um controlador de cliente (receptor). Isto propicia custos mais baixos devido a maior escala de produção de um único dispositivo de circuito.

Na Figura 4, são também mostrados um dispositivo host USB 4 01 e um dispositivo cliente USB 410 para uso na implementação de versões de interface tipo U da MDDI. Os circuitos e dispositivos para a implementação de tais funções são bem conhecidos pelos técnicos na área e não serão aqui descritos em maiores detalhes.

Na Figura 5 são mostrados um controlador de link MDDI 502 instalado em um dispositivo host 2 02' e um controlador de link MDDI 5 04 instalado em um dispositivo cliente 2 04' . Como antes, o host 2 02' está conectado a um cliente 204' pelo uso de um canal de comunicação bidirecional 506 compreendendo uma série de condutores. Como foi acima descrito, ambos os controladores de link de host e de cliente podem ser produzidos usando-se um único projeto de circuito.

Os sinais que passam entre um host e um cliente, tais como um dispositivo de display, através do link MDDI, ou dos condutores físicos usados, estão também ilustrados nas Figuras 4 e 5. Como pode ser visto nas Figuras 4 e 5, a trajetória ou mecanismo primário para transferência de dados através da MDDI usa sinais de dados referidos como MDDI_DataO+/- e MDDI_Stb+/-. Cada um destes consiste de sinais de dados de baixa tensão que são transferidos através de um par diferencial de fios em um cabo. Ocorre somente uma transição ou no par MDDI_DataO ou no par MDDI_Stb para cada bit enviado através da interface. Este constitui um mecanismo de transferência baseado em tensão e não baseado em corrente, de forma que o consumo de corrente estática é próximo de zero. O host aciona os sinais MDDI_Stb para o display de cliente.

Enquanto os dados puderem fluir tanto na direção de emissão como na reversa através dos pares MDDI_Data, isto é, em uma via de transferência bidirecional, o host será o mestre ou controlador do link de dados. As trajetórias de sinal MDDI_DataO e MDDI_Stb são operadas em um modo diferencial para maximizar a imunidade a ruídos. A taxa de dados para sinais nestas linhas é determinada pela taxa do clock enviada pelo host e é variável dentro de uma faixa de cerca de 1 kbps a 400 Mbps ou mais. A interface tipo II contém um par de dados adicional, ou condutores ou vias adicionais, além daqueles do tipo I, referido como MDDI_Datal + /- . A interface tipo III contém dois pares de dados ou trajetórias de sinais adicionais além dos da interface tipo II referidos como MDDI_Data2+/- e MDDI_Data3+/-. A interface tipo IV contém mais quatro pares de dados ou trajetórias de sinal além dos da interface tipo III referidos como MDDI_Data4+/-, MDDI_Data5 + /- , MDDI_Data6 + /- e MDDI_Data7 + /- , respectivamente. Em cada uma das configurações de interface acima, um host envia energia para o cliente ou display usando o par de fios ou sinais referridos como MDDI_Pwr e MDDI_Gnd.

Um tipo de transferência, de um modo geral, tornada disponível somente para a configuração do tipo U é a conexão ou trajetória de sinal MDDI USB. A conexão MDDI USB compreende uma trajetória secundária para comunicação entre um host e um display de cliente. Em certas aplicações pode ser mais vantajoso enviar certas informações em uma taxa de dados relativamente baixa entre um host e um cliente. O uso de link de transferência USB permite a dispositivos sem um controle de link MDDI que possuem um host USB ou capacidade de host limitada, se comunicarem com um cliente ou display compatível com MDDI equipado com a interface tipo U. Os exemplos de informações que podem ser transferidas de forma útil através de uma interface USB para um display incluem: bitmaps estáticos, fluxos de áudio digital, dados de dispositivo apontador, dados de teclado e informações de controle e estado. Todas as funcionalidades suportadas através da interface USB podem também ser implementadas usando-se a trajetória de dados serial MDDI de alta velocidade. Apesar de os dados (ver pacotes a seguir) acima definidos poderem ser enviados através de uma interface tipo USB, os requerimentos para encadear dados na forma de pacotes lado a lado não se aplicam a tal interface USB, nem o uso de pacotes que suportam a transferência tipo MDDI .

Um resumo dos sinais que passam entre o host e o cliente (display) através do link MDDI está ilustrado na Tabela I a seguir, de acordo com o tipo de interface: TABELA I

TIPO-7 TIPO-// TIPO -III TIPO-ZV MDDLPwr/Gnd MDDI_Pwr/Gnd MDDI_Pwr/Gnd MDDI_Pwr/Gnd MDDI_Stb+/- MDDI_Stb+/- MDDI_Stb+/- MDDI_Stb+/- MDDI_DataO+/- MDDI_DataO+/- MDDIJDataO+/- MDDI_DataO+/- MDDI_Datal+/- MDDI_Datal +/- MDDI_Datal+/-MDDI_Data2+/- MDDI_Data2+/-TlPO-t/ MDDI_Data3 +/- MDDI_Data3+/- MDDIJPwr/Gnd MDDIJData4+/- MDDI_Stb+/- MDDI_Data5+/- MDDI_DataO+/- MDDI_Data6+/- MDDI_USB+/- ____________________________ MDDI_Data7-f/- O cabeamento, de um modo geral usado para implementar as estrutura e operação acima, é nominalmente da ordem de 1,5 metros de comprimento e contém três pares trançados de condutores, cada um por sua vez sendo de fio multifilamentar (multi strand) 30 AWG. Uma cobertura laminada é enrolada, ou de outra forma aplicada, acima de três pares torcidos, assim como um fio adicional de escoamento. Os pares torcidos e o condutor dreno de cobertura terminam no conector de display com a cobertura conectada â cobertura do display (cliente), e existe uma camada isolante que cobre todo o cabo, como é do conhecimento dos técnicos na área. Os fios são emparelhados da seguinte forma: MDDI_Gdn com MDDI_Pwr, MDDI_Stb+ com MDDI_Stb-, MDDI_DataO+ com MDDI_DataO-, MDDI_Datal+ com MDDI_Datal- e assim por diante. O diâmetro nominal do cabo é da ordem de 3,0 mm com uma impedância nominal de 85 ohms ± 10 % e resistência DC nominal de aproximadamente 361 ohms por quilômetro de comprimento (110 ohms/1000 pés). A velocidade de propagação do sinal deve ser nominalmente de 0,66c, com um retardo máximo através do cabo menor que cerca de 8,0 ns. D. Tipos e taxas de dados.

Para obtenção de uma interface útil para uma gama completa de experiências e aplicações de usuário, a interface móvel para dados digitais (MDDI) propicia suporte para uma variedade de displays e informações de display, transdutores de áudio, teclados, dispositivos apontadores e vários outros dispositivos de entrada que poderíam ser integrados ou que venham a trabalhar em conjunto com um dispositivo de display móvel, juntamente com informações de controle e combinações de tais. A interface MDD é projetada para ser capaz de acomodar uma diversidade de tipos potenciais de fluxos de dados viajando entre o host e o cliente, nas direções dos links de emissão e reverso, usando um número mínimo de cabos ou condutores. São suportados ambos os fluxos isócronos e assíncronos (atualizações). Várias combinações de tipos de dados são possíveis, contanto que a taxa de dados total seja menor ou igual à taxa do link MDDI máxima desejada. Elas podem incluir, porém não se limitam a, aqueles itens listados nas Tabelas II e III a seguir.

Tabela II

Tabela III A interface não é fixa mas sim expansível de forma a suportar a transferência de uma diversidade de "tipos" de informações, o que inclui dados definidos por usuário, para futura flexibilidade do sistema. Os exemplos específicos de dados a serem acomodados incluem: vídeo com movimentação total, seja na forma de campos de bitmap de tela total ou parcial ou vídeo comprimido, bitmaps estáticos em taxas baixas para economizar energia e reduzir custos de implementação, dados PCM ou de áudio comprimidos em uma variedade de resoluções ou taxas, posição e seleção de dispositivo apontador e dados definidos pelo usuário para capacidades a serem ainda definidas. Tais dados podem também ser transferidos juntamente com informações de controle ou estado para detectar capacidades do dispositivo ou ajustar parâmetros de operação. A presente invenção inova a técnica para uso em transferências de dados que incluem, porém não se limitam a, assistir a um filme (apresentação de vídeo e áudio), uso de um computador pessoal com observação pessoal limitada (apresentação de elementos gráficos, algumas vezes combinados a vídeo e áudio), jogar um vídeo game em um PC, console, ou dispositivo pessoal (apresentação de elementos gráficos em movimento, ou vídeo e áudio sintéticos), "navegação" na Internet, uso de. dispositivos na forma de um vídeo fone (vídeo e áudio bidirecionais de baixa taxa), uma câmera para fotos digitais estáticas, ou uma vídeo câmera para gravação de imagens de vídeo digitais e para uso em melhoria de produtividade ou entretenimento, com telefones celulares, telefones inteligentes, ou PDAs. A interface de dados móvel, tal como será descrito mais adiante, é apresentada em termos do provimento de grandes quantidades de dados tipo A/V através de um link de comunicação ou transferência, o qual está de um modo geral configurado como um link do tipo linha de fios ou cabo. No entanto, ficará prontamente claro que a estrutura dos sinais, protocolos, timing, ou mecanismo de transferência podería ser ajustada para prover um link na forma de um meio óptico ou sem fio, caso eles possam sustentar o nível desejado de transferência.

Os sinais da interface MDD usam um conceito conhecido como o frame comum (CF - Common Frame) para o protocolo ou estrutura de sinal básico. A idéia por traz do uso de um frame comum é a de prover um pulso de sincronização paro fluxos de dados isócronos simultâneos. Um dispositivo de display pode usar tal taxa de frames comum como uma referência de tempo. Uma baixa taxa CF eleva a eficiência do canal por reduzir o overhead para transmissão do cabeçalho (header) de subframe. Por outro lado, uma taxa CF elevada reduz a latência e permite um menor buffer de dados elástico para as amostras de áudio. A taxa CF da interface da presente invenção pode ser dinamicamente programada e pode ser ajustada para um dos muitos valores que são apropriados para os fluxos síncronos usados em uma aplicação específica. Isto é, o valor CF é selecionado para melhor se adequar aos dados dispositivo de display e configuração de host, conforme desejado. O número de bytes, em geral, requerido por frame comum, o qual pode ser ajustado ou programado para os fluxos de dados isócronos mais prováveis de serem usados com uma aplicação, tal como para um micro-display montado na cabeça (head-mounted), está na Tabela IV.

Tabela IV

Contagens fracionárias de bytes por frame comum podem ser facilmente obtidas usando-se uma estrutura de contador M/N programável simples. Como exemplo, uma contagem de 26-2/3 bytes por CF é implementada pela transferência de 2 frames de 27 bytes seguidos, cada um, por um frame de 26 bytes. Uma taxa CF menor pode ser selecionada para produzir um número inteiro de bytes por CF. No entanto, falando de um modo geral, para implementar um contador M/N simples em hardware deve requerer menos área dentro de um chip de circuito integrado usado para implementar parte ou a totalidade da invenção que a área necessária para um buffer FIFO de amostras de áudio maior.

Uma aplicação exemplar que ilustra o impacto de diferentes taxas de transferência de dados e tipos de dados consiste de um sistema Karaoke. Para o Karaoke, um usuário do sistema canta junto com um programa de video de música. Os versos da canção (lyric) são apresentados na parte inferior de uma tela para que o usuário saiba a letra a ser cantada e, grosseiramente, o ritmo da canção. Tal aplicação requer um display de video com atualizações gráficas com pouca freqüência e mixagem da voz do usuário com um fluxo de áudio estéreo.

Caso se presuma uma taxa de frame comum de 3 00 Hz, então cada CF irá consistir de: 92.160 bytes de conteúdo de vídeo e 588 bytes de conteúdo de áudio (com base em 147 amostras de 16 bits em estéreo) através do link de emissão para o dispositivo de display, e uma média de 29,67 (26 2/3) de bytes de voz é enviada de volta a partir de um microfone para o equipamento de Karaoke móvel. Pacotes assíncronos são enviados entre o host e o display. Isto inclui no máximo 768 bytes de dados gráficos (um quarto de altura de tela) e menos que cerca de 200 bytes (ou vários bytes) para comandos de controle e estado misturados. A Tabela V mostra como os dados são alocados dentro de um frame comum para o exemplo do Karaoke. A taxa total sendo usada é selecionada como sendo de cerca de 225 Mbps. Uma taxa ligeiramente maior de 226 Mbps permite que cerca de mais de 400 bytes de dados por subframe sejam transferidos, o que permite o uso de mensagens ocasionais de controle e estado.

Tabela V Ξ. Camada de enlace.

Os dados transferidos usando-se a interface MDD com sinais de dados em série de alta velocidade consistem de um fluxo de pacotes multiplexados no tempo que estão ligados uns após os outros. Mesmo quando um dispositivo transmissor não possui dados para enviar, um controlador de link MDDI envia automaticamente pacotes de preenchimento, dessa forma, mantendo um fluxo de pacotes. O uso de uma estrutura de pacotes simples assegura timing isócrono confiável para sinais de vídeo e áudio ou fluxos de dados.

Os grupos de pacotes estão contidos em elementos ou estruturas de sinal, designados como subframes; e os grupos de subframes estão contidos dentro de elementos ou estruturas de sinal, designados como um frame de mídia. Um subframe contém um ou mais pacotes, dependendo de seu respectivo tamanho e uso para transferência de dados, e um frame de mídia deve conter um ou mais subframes. O maior subframe provido pelo protocolo empregado pela presente invenção está na ordem de 232-l ou 4.294.967.295 bytes, e o maior tamanho de frame de mídia portanto é da ordem de 216-1 ou 65.535 subframes.

Um pacote de cabeçalho especial que contém um único identificador que aparece no início de cada subframe será comentado a seguir. Tal identificador é também usado para captar o timing de frames no dispositivo cliente quando é iniciada a comunicação entre o host e o display. A captação do timing do link será descrita em maiores detalhes mais adiante.

Tipicamente, uma tela de display é atualizada uma vez por frame de mídia que está sendo apresentado a um vídeo de movimento total. A taxa de frames de display é a mesma que a taxa de frames de mídia. O protocolo de link suporta vídeo de movimento total por todo display, ou apenas uma pequena região de conteúdo de vídeo com movimento total circundada por uma imagem estática, dependendo da aplicação desejada. Em algumas aplicações móveis de baixa energia, tais como navegação por páginas da web ou e-mail, a tela do display pode necessitar de atualização apenas ocasional. Em tais situações é vantajosa a transmissão de um único subframe e a seguir interrupção do link para minimizar o consumo de energia. A interface também suporta efeitos tais como visão espacial e lida com formas geométricas gráficas (primitivas).

Os subframes existem para permitir a transmissão de pacotes de alta prioridade em uma base periódica. Isto permite que fluxos síncronos simultâneos coexistam com uma quantidade mínima de acumulação (buffering) de dados. Isto é uma vantagem que a presente invenção propicia ao processo de display, permitindo que múltiplos fluxos de dados (comunicação em alta velocidade de vídeo, voz, controle, estado, dispositivo apontador, etc.) essencialmente compartilhem um canal em comum. Ela transfere informações usando relativamente poucos sinais. Ela também permite a existência de ações específicas para a tecnologia do display, tais como pulsos sincronizados horizontais e intervalos de ocultação (blanking) para um monitor CRT. F. Controlador de link. O controlador de link MDDI apresentado nas Figuras 4 e 5 é produzido ou montado para constituir uma implementação completamente digital com a exceção dos receptores de linha diferencial que são usados para receber dados da MDDI e sinais de estrobo. Não são requeridas quaisquer funções analógicas ou loops travados por fase (PLLs - Phase Lock Loops) para implementar o hardware para o controlador de link. Os controladores de link de host e display 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 permite a vantagem prática de ser capaz de criar um projeto ou circuito de controlador único que pode ser configurado ou como um host ou como cliente, o que pode reduzir os custos de produção para os controladores de link como um todo. IV. Protocolo de link de interface. A. Estrutura de frame. O protocolo de sinal ou estrutura de frame usado para implementar a comunicação de link de emissão para a transferência de pacotes está ilustrado na Figura 6. Como mostrado na Figura 6, informações ou dados digitais são agrupados em elementos conhecidos como pacotes. Múltiplos pacotes são, por sua vez, agrupados para formar o que é referido como um "subframe" e múltiplos subframes são, por sua vez, agrupados para formar um frame de "mídia". Para controlar a formação de frames e a transferência de subframes, cada subframe se inicia com um pacote especialmente predefinido referido como um pacote de cabeçalho de subframe (SHP - Subframe Header Packet). O dispositivo host seleciona a taxa de dados a ser usada para uma dada transferência. Tal taxa pode ser mudada dinamicamente pelo dispositivo host com base na capacidade máxima de transferência do host, ou dos dados sendo recuperados a partir de uma fonte pelo host, e a capacidade máxima do display, ou outro dispositivo para o qual os dados estão sendo transferidos.

Um dispositivo receptor cliente projetado para, ou capaz de, trabalhar com o protocolo MDDI ou de sinal da presente invenção está habilitado a ser questionado pelo host para determinar a taxa de transferência de dados máxima, ou máxima atual que ele pode usar, ou pode ser usada uma taxa mínima mais lenta padrão, bem como tipos de dados e recursos usáveis suportados. Tais informações poderíam ser transferidas usando-se um pacote de capacidade de display (DCP - Display Capability Packet) tal como descrito mais adiante. O dispositivo de display de cliente é capaz de transferir dados ou se comunicar com outros dispositivos usando a interface com uma taxa de dados mínima pré-selecionada ou dentro de uma faixa de taxas de dados mínima, e o host irá efetuar um questionamento usando uma taxa de dados dentro de tal faixa para determinar as capacidades totais dos dispositivos de cliente.

Outras informações de estado, definindo a natureza do bitmap e as capacidades de taxa de frames de vídeo do display, podem ser transferidas em um pacote de estado para o host de forma a que o host possa configurar a interface para ser tão eficiente ou ideal quanto for prático ou desejado dentro de certas restrições do sistema. O host envia pacotes de preenchimento quando não existirem (mais) pacotes de dados a serem transferidos no presente subframe, ou quando o host não puder transferir a uma taxa suficiente para manter o ritmo com a taxa de transmissão de dados escolhida para o link de emissão. Uma vez que cada subframe se inicia com um pacote de cabeçalho de subframe, o final do subframe anterior contém um pacote (mais provavelmente um pacote de preenchimento) que preenche exatamente o subframe anterior. No caso de uma falta de espaço para os pacotes portando dados per se, um pacote de preenchimento provavelmente será o último pacote em um subframe, ou no final de um próximo subframe anterior e antes de um pacote de cabeçalho de subframe. Constitui a tarefa das operações de controle em um dispositivo host assegurar que existe suficiente espaço restante em um subframe para cada pacote a ser transmitido dentro de tal subframe. Ao mesmo tempo, uma vez que um dispositivo host inicie o envio de um pacote de dados, o host deve ser capaz de completar com sucesso um pacote de tal tamanho dentro de um frame sem incorrer em uma condição de sub-operação (under-run) de dados.

Em um aspecto de modalidades da invenção, a transmissão de subframes possui dois modos. Um modo é um modo de subframe periódico, usado para a transmissão de fluxo de video e áudio ao vivo. Neste modo, o comprimento de subframe é definido como sendo diferente de zero. O segundo modo é um modo assincrono ou não periódico, em que os frames são usados para prover dados de bitmap para um dispositivo de display somente quando estão disponíveis novas informações. Tal modo é definido pelo ajuste do comprimento de subframe para zero no pacote de cabeçalho de subframe. Ao usar o modo periódico, a recepção de pacotes de subframes pode começar quando o display tiver se sincronizado à estrutura de frames do link de emissão. Isto corresponde aos estados "em-sincronização" definidos de acordo com o diagrama de estado comentado mais adiante com relação à Figura 49. No modo de subframe não periódico assíncrono, a recepção começa após ser recebido o primeiro pacote de cabeçalho de subframe. B. Estrutura geral dos pacotes. O formato ou estrutura dos pacotes usados para formular o protocolo de sinalização implementado pela presente invenção serã apresentado a seguir, mantendo-se em mente que a interface é ampliável e que estruturas de pacotes adicionais podem ser adicionadas conforme desejado. Os pacotes estão referidos como, ou divididos em, diferentes "tipos de pacotes" em termos de sua função na interface, isto é, comandos ou dados que eles transferem. Portanto, cada tipo de pacote denota uma estrutura de pacote predefinida para um dado pacote, que é usada para manipular os pacotes e dados sendo transferidos. Como ficará prontamente claro, os pacotes podem ter comprimentos pré-selecionados ou possuir comprimentos variáveis ou dinamicamente modificáveis, dependendo de suas respectivas funções. Os bytes, ou valores de bytes, usados nos diversos pacotes são configurados na forma de números inteiros não-designados de múltiplos bits (8 ou 16 bits) . Um resumo dos pacotes sendo empregados, juntamente com suas designações de "tipo", listadas por ordem de tipo, é apresentado na Tabela VI. A direção em que a transferência de um pacote é considerada válida é também notada, juntamente com o fato de eles serem ou não usados para uma interface tipo U.

Tabela VI

Os pacotes possuem uma estrutura básica comum ou um conjunto geral de campos mínimos compreendendo um campo comprimento de pacote, um campo tipo de pacote, campo(s) bytes de dados e um campo CRC, que está ilustrado na Figura 7. Como mostrado na Figura 7, o campo 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 comprimento de pacote e o campo CRC. Em uma modalidade preferida do presente exemplo, 0 campo comprimento de pacote contém um número inteiro não-designado (unsigned) de 16 bits ou 2 bytes de largura que especifica o comprimento do pacote. O campo tipo de pacote é outro campo de múltiplos bits que designa o tipo de informações que estão contidas no pacote. Na modalidade exemplar do presente exemplo, este é um valor de 8 bits ou 1 byte de largura, na forma de um número inteiro não designado de 8 bits, e especifica tais tipos de dados como capacidades de display, transferência, fluxos de vídeo ou áudio, estado e assim por diante.

Um terceiro campo é o de bytes de dados que contém os bits ou dados que estão sendo transferidos ou enviados entre o host e dispositivos clientes como parte do pacote. O formato dos dados é definido especificamente para cada tipo de pacote de acordo com o tipo específico de dados sendo transferidos, podendo ser separado em uma série de campos adicionais, cada um com seus próprios requerimentos de formato. Isto é, cada tipo de pacote terá um formato definido para tal porção ou campo. O último campo é o campo CRC que contém os resultados de uma verificação por redundância cíclica de 16 bits calculada sobre os campos bytes de dados, tipo de pacote e comprimento de pacote, que é usada para confirmar a integridade das informações no pacote. Em outras palavras, calculada sobre todo o pacote exceto pelo próprio campo CRC. O cliente de um modo geral mantém uma contagem total dos erros de CRC detectados, e reporta tal contagem de volta ao host no pacote de requisição e estado de display (descrito mais adiante).

Durante a transferência dos pacotes, os campos são transmitidos iniciando-se pelo bit menos significativo (LSB - least significant bit) e terminando com o bit mais significativo (MSB - most significant bit) transmitido por último. Os parâmetros que possuem mais de um byte de comprimento são transmitidos usando-se primeiro o byte menos significativo, o que resulta no uso do mesmo padrão de transmissão de bits para um parâmetro maior que 8 bits de comprimento, tal como é usado para um parâmetro mais curto em que o LSB é transmitido em primeiro lugar. Os dados na trajetória de sinal MDDI_DataO são alinhados com o bit 0 dos bytes transmitidos através da interface em qualquer dos modos, tipo I, tipo II, tipo III, ou tipo IV.

Quando da manipulação de dados para displays, os dados para os arranjos de pixels são transmitidos por filas em primeiro lugar, depois colunas, tal como é feito tradicionalmente na área de eletrônica. Dito de outra forma, todos os pixels que aparecem na mesma fila em um bitmap são transmitidos em ordem, com o pixel mais à esquerda sendo transmitido em primeiro lugar e o pixel mais à direita sendo transmitido por último. Após o pixel mais â direita de uma fileira ser transmitido, o próximo pixel na seqüência é o pixel mais à esquerda da fileira seguinte. As filas de pixels são de um modo geral transmitidas em ordem, do topo para o fundo, pela maioria dos displays, apesar de outras configurações poderem ser acomodadas conforme a necessidade. Além disso, ao lidar com bitmap, a estratégia convencional que é seguida aqui, é a de definir um ponto de referência marcando o canto esquerdo superior de um bitmap como a localização ou offset "0,0". As coordenadas X e Y usadas para definir ou determinar uma posição no bitmap aumentam em valor a medida que se aproxima da direita e do fundo do bitmap, respectivamente. A primeira fileira e a primeira coluna se iniciam com um valor índice de zero. C. Definições de pacotes. 1. Pacote de cabeçalho de subframe. 0 pacote de cabeçalho de subframe é o primeiro pacote de todos os subframe e possui uma estrutura básica tal como ilustrada ná Figura 8. Como pode ser visto na Figura 8, tal tipo de pacote é estruturado para apresentar campos de comprimento de pacote, tipo de pacote, palavra exclusiva, comprimento de subframe, versão de protocolo, contagem de subframe e contagem de frame de midia, em geral nesta ordem. Tal tipo de pacote ê de um modo geral identificado como um pacote tipo 255 (Oxff hexadecimal) e usa um comprimento fixo pré-selecionado de 17 bytes.

Apesar do campo tipo de pacote utilizar um valor de 1 byte, o campo palavra exclusiva (unique word) usa um valor de 3 bytes. A combinação de 4 bytes desses dois campos juntos forma uma palavra exclusiva de 32 bits com boa auto-correlação. A palavra exclusiva real ê 0x005a3bff em que os 8 bits mais baixos são transmitidos em primeiro lugar na forma do tipo de pacote e os 24 bits mais significativos são transmitidos a seguir. O campo comprimento de subframe contém 4 bytes de informações que especificam o número de bytes por subframe. O comprimento deste campo pode ser ajustado como igual a zero para indicar que somente um subframe será transmitido pelo host antes que o link seja desativado para um estado inativo (idle). O valor deste campo pode ser dinamicamente mudado "em curso" ao se passar de um subframe para o próximo. Tal capacidade é útil para efetuar pequenos ajustes de timing nos pulsos de sincronização para acomodar fluxos de dados isócronos. Caso a CRC do pacote de cabeçalho de subframe não seja válida, o controlador de link deve usar o comprimento de subframe do pacote de cabeçalho de subframe bem conhecido anterior para estimar o comprimento do corrente subframe. O campo versão de protocolo contém 2 bytes que especificam a versão de protocolo usada pelo host. O campo versão de protocolo é ajustado para "0" para especificar a primeira ou a corrente versão do protocolo como sendo a utilizada. Tal valor irá mudar ao longo do tempo a medida que novas versões forem criadas. O campo contagem de subframes contém 2 bytes que especificam um número seqüencial que indica o número de subframes que foram transmitidos desde o início do frame de mídia. O primeiro subframe do frame de mídia possui uma contagem de subframe de zero. O último subframe do frame de mídia possui um valor de n-1, em que n é o número de subframes por frame de mídia. Note-se que se o comprimento de subframe for ajustado para zero (indicando um subframe não periódico) então a contagem de subframes também deve ser ajustada para zero. O campo contagem de frames de mídia contém 3 bytes que especificam um número seqüencial que indica o número de frames de mídia que foram transmitidos desde o início do presente item ou dados de mídia sendo transferidos. O primeiro frame de mídia de um item de mídia possui uma contagem de frame de mídia de zero. A contagem de frames de mídia cresce imediatamente antes do primeiro subframe de cada frame de mídia e volta a zero após a contagem máxima de frame de mídia (número de frame de mídia 224 -1 = 16.777.216) ser usada. O valor de contagem de frames de mídia pode ser, de um modo geral, reajustado ou resetado a qualquer momento pelo host para atender âs necessidades de uma aplicação final. 2. Pacote de preenchimento.

Um pacote de preenchimento é um pacote que é transferido para, ou a partir de, um dispositivo cliente quando nenhuma outra informação está disponível para ser enviada através do link de emissão ou do link reverso. É recomendado que os pacotes de preenchimento possuam um comprimento mínimo de modo a permitir a maior flexibilidade no envio de outros pacotes quando requerido. Bem no final de um subframe ou de um pacote de encapsulamento de link reverso (ver a seguir), um controlador de link ajusta o tamanho do pacote de preenchimento para preencher o espaço restante para manter a integridade do pacote. O formato e conteúdo de um pacote de preenchimento são mostrados na Figura 9. Como mostrado na Figura 9, tal tipo de pacote é estruturado de modo a possuir campos de comprimento de pacote, tipo de pacote, bytes de preenchimento e CRC. Tal tipo de pacote é de um modo geral identificado como um Tipo 0, o que é indicado no campo do tipo de 1 byte. Os bits ou bytes no campo bytes de preenchimento compreendem um número variável de valores de bit todos de zero para permitir que o pacote de preenchimento possua o comprimento desejado. O menor pacote de preenchimento não contém quaisquer bytes neste campo. Isto é, o pacote consiste apenas do comprimento de pacote, tipo de pacote e CRC, e usa um comprimento fixo pré-selecionado de 3 bytes. 3 . Pacote de fluxo de vídeo.

Os pacotes de fluxo de video portam dados de vídeo para atualizar uma região atipicamente retangular de um dispositivo de display. O tamanho de tal região pode ser tão pequeno quanto um único pixel, ou tão grande quanto todo o display. Pode existir um número quase ilimitado de fluxos apresentados simultaneamente, limitado pelos recursos do sistema, pois todo o contexto requerido para apresentar um fluxo está contido no pacote de fluxo de vídeo. O 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, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, descritor de dados de vídeo, atributos de display, borda esquerda X, borda superior Y, borda direita X, borda inferior Y, início de X e Y, contagem de pixels, CRC de parâmetro, dados de pixels e CRC. Tal tipo de pacote é de um modo geral identificado como um tipo 1, o que é indicado no campo tipo 1 byte. O conceito de frame comum acima descrito constitui uma forma eficaz de minimizar o tamanho do buffer de áudio e reduzir a latência. No entanto, para dados de vídeo pode ser necessário espalhar os pixels de um frame de vídeo através de múltiplos pacotes de fluxo de vídeo dentro de um frame de mídia. É também muito provável que os pixels em um único pacote de fluxo de vídeo não irão corresponder exatamente a uma janela retangular perfeita no display. Para a taxa de frames de vídeo exemplar de 3 0 frames por segundo, ocorrem 300 subframes por segundo, o que resulta em 10 subframes por frame de mídia. Caso existam 480 filas de pixels em cada frame, cada pacote de fluxo de vídeo em cada subframe irá conter 480 filas de pixels. Em outras situações, o pacote de fluxo de vídeo podería não conter um número inteiro de filas de pixels. Isto é verdadeiro para outros tamanhos de frames de vídeo em que o número de subframes por frame de mídia não pode ser dividido sem resto pelo número de filas (também conhecidas como linhas de vídeo) por frame de vídeo. Cada pacote de fluxo de vídeo deve conter um número inteiro de pixels, mesmo que ele não possa conter um número inteiro de filas de pixels. Isto é importante caso os pixels tenham mais de um byte cada um, ou caso eles estejam em um formato empacotado tal como mostrado na Figura 12. O formato e o conteúdo empregados para efetuar a operação do campo descritor de dados de vídeo acima mencionado são apresentados nas Figuras 11a a lld. Nas Figuras 11a a lld, o campo descritor de formato de dados de vídeo contém 2 bytes na forma de um número inteiro não designado de 16 bits que especifica o formato de cada pixel nos dados de pixels no fluxo atual no pacote atual. É possível que diferentes fluxos (designados pelo campo ID de fluxo) possam usar diferentes formatos de dados de pixels, isto é, usar um valor diferente no descritor de formato de dados de vídeo e, de modo similar, qualquer fluxo pode mudar seu formato de dados "em curso" . O descritor de formato de dados de vídeo define o formato de pixels para o presente pacote somente, o que não implica em que um formato constante deverá continuar a ser usado por toda a vida de um fluxo de vídeo específico.

As Figuras 11a a lld ilustram como o descritor de formato de dados de vídeo é codificado. Tal como utilizado em tais figuras, quando os bits [15:13] são iguais a "000", tal como mostrado na Figura 11a, os dados de vídeo consistem de um arranjo de pixels monocromáticos em que o número de bits por pixel é definido pelos bits 3 a 0 da palavra do descritor de formato de dados de vídeo. Os bits 11 a 4 são ajustados para zero em tal situação. Quando os bits [15:13] forem iguais a "001", tal como mostrado na Figura 11b, então os dados de vídeo consistem de um arranjo de pixels coloridos que especificam cada um, uma cor através de um mapa de cores. Em tal situação, os bits 5 a 0 da palavra do descritor de formato de dados de vídeo definem o número de bits por pixel e os bits 11 a 6 são ajustados para zero. Quando os bits [15:13] forem iguais a "010", tal como mostrado na Figura 11c, então os dados de vídeo consistem de um arranjo de pixels coloridos em que o número de bits por pixel de vermelho é definido pelos bits 11 a 8, o número de bits por pixel de verde é definido pelos bits 7 a 4 e o número de bits por pixel de azul é definido pelos bits 3 a 0. Em tal situação, o número total de bits em cada pixel é a soma do número de bits usados para o vermelho, o verde e o azul.

No entanto, quando os bits [15:13] forem iguais a "011", tal como mostrado na Figura lld, os dados de vídeo consistem de um arranjo de dados de vídeo no formato 4:2:2 com informações de luminância e crominância, em que o número de bits por pixel de luminância (Y) é definido pelos bits 11 a 8, o número de bits da componente Cr é definido pelos bits 7 a 4 e o número de bits da componente Cb é definido pelos bits 3 a 0. O número total de bits em cada pixel é a soma do número de bits usados para o vermelho, o verde e o azul. As componentes Cr e Cb são enviadas em meia taxa como Y. Além disso, as amostras de vídeo na porção de dados de pixels deste pacote são organizadas da seguinte forma: Yn, Crn, Cbn, Yn+i, Yn+2, Crn+2, Cbn+2, Yn+3, ·-·, em que Crn e Cbn estão associadas a Yn e Yn+i e Crn+2 e Cbn+2 estão associadas a Yn+2 e Yn+3 e assim por diante. Caso exista um número ímpar de pixels em uma fileira (X borda direita - X borda esquerda + 1) no presente fluxo então o valor Cb correspondente ao último pixel em cada fileira será seguido pelo valor Y do primeiro pixel da próxima fileira.

Para todos os quatro formatos mostrados nas figuras, o bit 12, que é designado como "P" especifica se ou não as amostras de dados de pixels são empacotadas ou dados de pixels alinhados por byte. Um valor de "0" neste campo indica que cada pixel e cada cor dentro de cada pixel no campo dados de pixels estão alinhados por byte com um limite de byte de interface MDDI. Um valor de "1" indica que cada pixel e cada cor dentro de cada pixel nos dados de pixels estão empacotados juntos ao pixel ou cor anterior dentro de um pixel, não deixando quaisquer bits sem uso. O primeiro pixel no primeiro pacote de fluxo de vídeo para uma janela de display específica irá para o canto superior esquerdo da janela do fluxo definido por um offset X e um offset Y, e o próximo pixel recebido é posicionado na próxima localização de pixel na mesma fileira e assim por diante. Para facilitar tal operação, o display mantém um contador de "próxima fileira e coluna de pixel" associado a cada ID de fluxo de vídeo ativa. 4. Pacote de fluxo de áudio.

Os pacotes de fluxo de áudio portam dados de áudio para serem reproduzidos através do sistema de áudio do display, ou para um dispositivo de apresentação de áudio isolado. Diferentes fluxos de dados de áudio podem ser alocados para canais de áudio separados em um sistema de som, por exemplo: esquerdo-frontal, direito-frontal, central, esquerdo-posterior e direito-posterior, dependendo do tipo de sistema de áudio sendo usado. Um conjunto completo de canais de áudio é provido para fones de ouvidos que contêm processamento ampliado acústico espacial de sinais. O formato dos pacotes de fluxo de áudio está ilustrado na Figura 13. Como mostrado na Figura 13, tal tipo de pacote está estruturado para possuir campos de comprimento de pacote, tipo de pacote, ID de canal de áudio, contagem de amostras de áudio, bits por amostra e empacotamento, taxa de amostras de áudio, CRC de parâmetro, dados de áudio digital e CRC de dados de áudio. Tal tipo de pacote é em geral identificado como um pacote tipo 2. O campo bits por amostra e empacotamento contém 1 byte na forma de um número inteiro não designado de 8 bits que especifica o formato de empacotamento de dados de áudio. O formato geralmente empregado é para os bits 4 a 0 para definir o número de bits por amostra de áudio PCM. O bit 5, então, especifica se as amostras de dados de áudio digital estão ou não empacotadas. A diferença entre as amostras de áudio empacotadas e alinhadas em byte está ilustrada na Figura 14 . Um valor de "0" indica que cada amostra de áudio PCM no campo dados de áudio digital está alinhada em byte com um limite de byte de interface MDDI, e um valor de "1" indica que cada amostra de áudio PCM sucessiva está empacotada junto à amostra de áudio anterior. Este bit é efetivo apenas quando o valor definido nos bits 4 a 0 (o número de bits por amostra de áudio PCM) não for um múltiplo de oito. Os bits 7 e 6 são reservados para uso futuro e são de um modo geral ajustados para um valor de zero. 5. Pacotes de fluxo reservados.

Os tipos de pacote 3 a 55 ficam reservados para pacotes de fluxos a serem definidos para uso em futuras versões ou variações dos protocolos de pacotes, conforme desejado para várias aplicações encontradas. Novamente, isto faz parte de se tornar a interface MDD mais flexível e útil face à tecnologia e aos projetos de sistemas em contínua mutação, em comparação a outras técnicas. 6. Pacotes de fluxo definidos pelo usuário.

Oito tipos de fluxos de dados, conhecidos como tipos 56 a 63, são reservados para uso em aplicações proprietárias que podem ser definidas por fabricantes de equipamentos para uso com um link MDDI. Eles são conhecidos como pacotes de fluxos definidos pelo usuário. Os pacotes de fluxo de vídeo portam dados de vídeo para atualizar (ou não) uma região retangular do display. A definição dos parâmetros de fluxo e os dados para tais tipos de pacotes são deixados a cargo dos fabricantes de equipamentos específicos que necessitem utilizá-los. O formato dos pacotes de fluxos definidos pelo usuário está ilustrado na Figura 15. Como mostrado na Figura 15, tal tipo de pacote está estruturado para apresentar campos de comprimento de pacote, tipo de pacote, número de ID de fluxo, parâmetros 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 especificam o conteúdo de uma tabela de consulta de mapa de cores usada para apresentar cores para um display. Algumas aplicações podem requerer um mapa de cores que é maior que a quantidade de dados que pode ser transmitida em um único pacote. Nesses casos, podem ser transferidos múltiplos pacotes de mapa de cores, cada um com um subconjunto diferente do mapa de cores, pelo uso dos campos de offset (deslocamento) e comprimento descritos a seguir. O formato do pacote de mapa de cores está ilustrado na Figura 16 . Como mostrado na Figura 16, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, tamanho de dados do mapa de cores, offset do mapa de cores, CRC de parâmetro, dados de mapa de cores e CRC de dados. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 64. 8. Pacotes de encapsulamento de link reverso.

Os dados são transferidos na direção reversa usando-se um pacote de encapsulamento de link reverso. Um pacote de link de emissão é enviado e a operação de link MDDI (direção de transferência) é mudada ou invertida no meio deste pacote de forma a que pacotes possam ser enviados na direção reversa. O formato do pacote de encapsulamento de link reverso está ilustrado na Figura 17. Como mostrado na Figura 17, tal tipo de pacote está estruturado para possuir campos de comprimento de pacote, tipo de pacote, flags de link reverso, comprimento de inversão (turn-around), CRC de parâmetro, inversão 1, pacotes de dados reversos e inversão 2. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 65. O controlador de link MDDI se comporta de uma maneira especial enquanto envia um pacote de encapsulamento de link reverso. A interface MDD possui um sinal de estrobo que é sempre acionado pelo host. O host se comporta como se ele estivesse transmitindo um zero para cada bit das porções, inversão e pacotes de dados reversos, do pacote de encapsulamento de link reverso. O host inverte (toggle) o sinal MDDI_Strobe em cada limite de bit durante as duas ocorrências de inversão e durante o tempo alocado para os pacotes de dados reversos (este é o mesmo comportamento como se ele estivesse transmitindo todos dados iguais a zero) . O host desabilita seus drivers de linha de sinal de dados MDDI durante o período de tempo especificado pela inversão 1 e o cliente reabilita seus drivers de linha durante o campo reabilitação de driver após o período de tempo especificado pelo campo inversão 2. O display lê o parâmetro de comprimento de inversão e aciona os sinais de dados em direção ao host imediatamente após o último bit no campo inversão 1. O display usa os parâmetros de comprimento de pacote e comprimento de inversão para conhecer o período de tempo que ele tem disponível para enviar pacotes ao host. O cliente pode enviar pacotes de preenchimento ou acionar as linhas de dados para um estado zero quando ele não possui dados para enviar ao host. Caso as linhas de dados sejam acionadas para zero, o host interpreta isto como um pacote com comprimento zero (não é um comprimento válido) e o host não mais aceita quaisquer pacotes provenientes do cliente durante o período do pacote de encapsulamento de link reverso corrente. O display aciona as linhas de dados MDDI para o nível zero por pelo menos um período de clock de link reverso antes do início do campo inversão 2. Isto mantém as linhas de dados em um estado determinístico durante o período de tempo de inversão 2 . Caso o cliente não possua mais pacotes para enviar, ele pode até desabilitar as linhas de dados após acioná-las para um nível zero, pois os resistores de bias de hibernação (descritos mais adiante) mantêm as linhas de dados em um nível zero para o restante do campo pacotes de dados reversos. O campo requisição de link reverso do pacote de requisição e estado de display pode ser usado para informar ao host sobre o número de bytes que o display necessita no pacote de encapsulamento de link reverso para enviar dados de volta ao host. 0 host tenta atender à requisição alocando pelo menos o número de bytes no pacote de encapsulamento de link reverso. O host pode enviar mais de um pacote de encapsulamento de link reverso em um subframe. O display pode enviar um pacote de requisição e estado de display quase que em qualquer momento e o host irá interpretar o parâmetro de requisição de link reverso como o número total de bytes requisitados em um subframe. 9. Pacotes de capacidade de display.

Um host precisa conhecer a capacidade do display (cliente) com o qual está se comunicando de modo a configurar o link host/display de uma maneira geralmente ideal ou desejada. É recomendado que um display envie um pacote de capacidade de display para o host após ser captada a sincronização do link de emissão. A transmissão de tal pacote é considerada requerida quando requisitada pelo host usando os flags de link reverso no pacote de encapsulamento de link reverso. O formato do pacote de capacidade de display está ilustrado na Figura 18. Como mostrado na Figura 18, tal tipo de pacote é estruturado de modo a possuir campos de comprimento de pacote, tipo de pacote, versão de protocolo, versão de protocolo mínima, largura de bitmap, altura de bitmap, capacidade monocromática, capacidade de mapa de cores, capacidade RGB, capacidade Y Cr Cb, capacidade de recursos de display, capacidade de taxa de dados, capacidade de taxa de frames, profundidade de buffer de áudio, capacidade de fluxo de áudio, capacidade de taxa de áudio, taxa de subframes mínima e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 66. 10. Pacotes de dados de teclado.

Um pacote de dados de teclado é usado para enviar dados de teclado a partir do dispositivo cliente para o host. Um teclado sem fio (ou com cabo) pode ser usado em conjunto com vários displays ou dispositivos de áudio, incluindo, porém não limitados a, um dispositivo de apresentação de display de vídeo/áudio montado na cabeça. O pacote de dados de teclado repassa dados de teclado recebidos a partir de um dentre vários dispositivos similares a teclados conhecidos para o host. Tal pacote pode também ser usado através do link de emissão para enviar dados ao teclado. O formato de um pacote de dados de teclado é apresentado 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, tal tipo de pacote está estruturado para possuir campos de comprimento de pacote, tipo de pacote, dados de teclado e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 67. 11. Pacotes de dados de dispositivo apontador.

Um pacote de dados de dispositivo apontador é usado para enviar informações de posição a partir de um mouse sem fio ou outro dispositivo apontador, do display para o host. Os dados também podem ser enviados para o dispositivo apontador através do link de emissão usando-se tal pacote. O formato de um pacote de dados de dispositivo apontador é apresentado na Figura 20 e contém um número variável de bytes de informações provenientes de, ou destinados a, um dispositivo apontador. Como mostrado na Figura 20, tal tipo de pacote está estruturado para possuir campos de comprimento de pacote, tipo de pacote, dados de dispositivo apontador e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 6 8 no campo tipo 1 byte. 12. Pacotes de desativação de link.

Um pacote de desativação (shutdown) de link é enviado do host para o display de cliente para indicar que os dados MDDI e o estrobo serão desativados e passarão a um estado de "hibernação" de baixo consumo de energia. Tal pacote é útil para desativar o link e economizar energia após bitmaps estáticos serem enviados de um dispositivo de comunicação móvel para o display, ou quando não existem mais informações para transferência de um host para o cliente no momento. A operação normal é retomada quando o host envia pacotes novamente. O primeiro pacote enviado após a hibernação é um pacote de cabeçalho de subframe. O formato de um pacote de estado de display é apresentado na Figura 21. Como mostrado na Figura 21, tal tipo de pacote é estruturado possuindo campos de comprimento de pacote, tipo de pacote e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 69 no campo tipo 1 byte e usa um comprimento fixo pré-selecionado de 3 bytes.

No estado de hibernação de baixa energia, o driver MDDI_Data é desabilitado em um estado de alta impedância e os sinais MDDI_Data são puxados para um estado de zero lógico usando-se uma rede bias de alta impedância que pode ser sobre acionada (overdriven) pelo display. O sinal de estrobo usado pela interface ê ajustado para um nível zero lógico no estado de hibernação para minimizar o consumo de energia. O host ou o display pode levar o link MDDI a "acordar" do estado de hibernação, tal como descrito mais adiante, o que constitui um aperfeiçoamento chave e uma vantagem da presente invenção. 13. Pacotes de requisição e estado de display . O host necessita uma pequena quantidade de informações provenientes do display para que ele possa configurar o link host/display de uma maneira ideal. É recomendado que o display envie um pacote de estado de display para o host em cada subframe. O display deve enviar tal pacote como o primeiro pacote no pacote de encapsulamento de link reverso para assegurar que ele seja levado de forma confiável ao host. O formato de um pacote de estado de display é apresentado na Figura 2 2 . Como mostrado na Figura 22, tal tipo de pacote está estruturado para possuir campos de comprimento de pacote, tipo de pacote, requisição de link reverso, contagem de erros de CRC e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 70 no campo tipo 1 byte e usa um comprimento fixo pré-selecionado de 7 bytes. O campo requisição de link reverso pode ser usado para informar o host sobre o número de bytes que o display necessita no pacote de encapsulamento de link reverso para enviar dados de volta ao host. O host deve tentar atender à requisição alocando pelo menos o número de bytes no pacote de encapsulamento de link reverso. O host pode enviar mais de um pacote de encapsulamento de link reverso em um subframe de modo a acomodar dados. O display pode enviar um pacote de requisição e estado de display em qualquer momento e o host irá interpretar o parâmetro de requisição de link reverso como o número total de bytes requisitado em um subframe. Detalhes adicionais e exemplos específicos de como os dados de link reverso são enviados de volta ao host serão apresentados mais adiante. 14. Pacotes de transferência de blocos de bits. O pacote de transferência de bloco de bits propicia um meio para "fazer rolar" (scroll) regiões do display em qualquer direção. Os displays que possuem tal capacidade reportarão a capacidade no bit 0 do campo indicadores de capacidade de recursos de display no pacote de capacidade de display. O formato de um pacote de transferência de blocos de bits é apresentado na Figura 23. Como mostrado na Figura 23, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, valor de X superior esquerdo, valor de Y superior esquerdo, largura de janela, altura de janela, movimento X de janela, movimento Y de janela e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 71 e usa um comprimento fixo pré-selecionado de 15 bytes.

Os campos são usados para especificar os valores X e Y da coordenada do canto superior esquerdo da janela a ser movida, a largura e altura de janela a ser movida e o número de pixels em que a janela deve ser movida horizontal e verticalmente, respectivamente. Valores positivos para os dois últimos campos levam a janela a ser movida para a direita e para baixo, enquanto que valores negativos causam o movimento para a esquerda e para cima, respectivamente. 15. Pacotes de preenchimento de área de bitmap. O pacote de preenchimento de área de bitmap propicia um meio para inicializar facilmente uma região do display em uma única cor. Os displays que possuem tal capacidade irão reportar a capacidade no bit 1 do campo indicadores de capacidade de recursos do display do pacote de capacidade de display. O formato de um pacote de preenchimento de área de bitmap é apresentado na Figura 24. Como mostrado na Figura 24, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, valor X superior esquerdo, valor Y superior esquerdo, largura de janela, altura de janela, descritor de formato de dados, valor de preenchimento de área de pixels e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 72 no campo tipo 1 byte e usa um comprimento fixo pré-selecionado de 17 bytes. 16. Pacotes de preenchimento padrão de bitmap. O pacote de preenchimento padrão de bitmap propicia um meio de inicializar facilmente uma região do display em um padrão pré-selecionado. Os displays que possuem tal capacidade irão reportar a capacidade no bit 2 do campo indicadores de capacidade de recursos do display do pacote de capacidade de display. O canto superior esquerdo do padrão de preenchimento é alinhado com o canto superior esquerdo da janela a ser preenchida. Caso a janela a ser preenchida seja mais larga ou mais alta que o padrão de preenchimento, o padrão pode ser repetido horizontal ou verticalmente pelo número de vezes para preencher a janela. A direita ou o fundo do último padrão repetido é truncado conforme a necessidade. Caso a janela seja menor que o padrão de preenchimento, o lado direito ou o fundo do padrão de preenchimento podem ser truncados para se ajustar à janela. O formato de um pacote de preenchimento padrão de bitmap é apresentado na Figura 25. Como mostrado na Figura 25, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, valor X superior esquerdo, valor Y superior esquerdo, largura de janela, altura de janela, largura padrão, altura padrão, descritor de formato de dados, CRC de parâmetro, dados de pixels padrão e CRC de dados de pixels. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 73 no campo tipo 1 byte. 17. Pacotes de canal de dados de link de comunicação. 0 pacote de canal de dados de link de comunicação provê um meio para um display com capacidade de computação de alto nível, tal como um PDA, se comunicar com um transceptor sem fio, tal como um telefone celular ou um dispositivo de porta de dados sem fio. Em tal situação, o link 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, em que tal pacote transporta dados em uma camada de enlace de dados de um sistema operacional para o dispositivo. Como exemplo, tal pacote podería ser usado caso um web browser, um cliente de e-mail, ou todo um PDA fosse embutido em um display móvel. Os displays que possuem tal capacidade reportarão a capacidade no bit 3 do campo indicadores de capacidade de recursos do display do pacote de capacidade de display. O formato de um pacote de canal de dados de link de comunicação é apresentado na Figura 25. Como mostrado na Figura 26, tal tipo de pacote é estruturado para possuir 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. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 74 no campo tipo. 18. Pacotes de requisição de transferência de tipo de interface. O pacote de requisição de transferência de tipo de interface habilita o host a requisitar que o cliente ou display mude de um modo existente ou corrente para os modos tipo I (serial) , tipo II (2 bits, paralelo) , tipo III (4 bits, paralelo), ou tipo IV (8 bits, paralelo). Antes que o host requisite um modo específico ele deve confirmar que o ) display é capaz de operar no modo desejado pelo exame dos bits 6 e 7 do campo indicadores de capacidade de recursos de display do pacote de capacidade de display. O formato de um pacote de requisição de transferência de tipo de interface é apresentado na Figura 27. Como mostrado na Figura 27, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, tipo de interface e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 75 e usa um comprimento fixo pré-selecionado de 4 bytes. 19. Pacotes de confirmação de tipo de interface. O pacote de confirmação de tipo de interface é enviado pelo display para confirmar a recepção do pacote de transferência de tipo de interface. O modo requisitado, tipo I (serial) , tipo II (2 bits, paralelo) , tipo III (4 bits, paralelo), ou tipo IV (8 bits, paralelo) é repassado de volta ao host na forma de um parâmetro neste pacote. O formato de um pacote de confirmação de tipo de interface é apresentado na Figura 28. Como mostrado na Figura 28, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, tipo de interface e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 76 e usa um comprimento fixo pré-selecionado de 4 bytes. 20. Pacotes de transferência de tipo de desempenho. O pacote de transferência de tipo de desempenho é um meio para o host comandar o display para transferir para o modo especificado em tal pacote. Este deve ser o mesmo modo que foi anteriormente requisitado e confirmado pelo pacote de requisição de transferência de tipo de interface e pelo pacote de confirmação de tipo de interface. O host e o display devem se comutar para o modo acordado após tal pacote ser enviado. O display pode perder e recapturar a sincronização de link durante a mudança de modo. O formato de um pacote de transferência de tipo de desempenho é apresentado na Figura 29. Como mostrado na Figura 29, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, tipo de pacote e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 77 no campo tipo 1 byte e usa um comprimento fixo pré-selecionado de 4 bytes. 21. Pacotes de habilitação de canal de áudio de emissão.

Tal pacote permite ao host habilitar ou desabilitar canais de áudio no display. Tal capacidade é útil para que o display (cliente) possa desligar amplificadores de áudio ou elementos de circuito similares para economizar energia quando não existe áudio para ser emitido pelo host. Isto é de implementação significativamente mais difícil pelo simples uso da presença ou ausência de fluxos de áudio como um indicador. O estado padrão (default) quando o sistema de display é ligado é o de que todos os canais de áudio sejam habilitados. O formato de um pacote de habilitação de canal de áudio de emissão é apresentado na Figura 30. Como mostrado na Figura 30, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, máscara de habilitação de canal de áudio e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 7 8 no campo tipo 1 byte e usa um comprimento fixo pré-selecionado de 4 bytes. 22 . Pacotes de taxa de amostra de áudio reverso.

Tal pacote permite ao host habilitar ou desabilitar o canal de áudio de link reverso e ajustar a taxa de amostras de dados de áudio de tal fluxo. O host seleciona uma taxa de amostras que seja definida como válida no pacote de capacidade de display. Caso o host selecione uma taxa de amostras não válida, o display não irá enviar um fluxo de áudio para o host. O host pode desabilitar o fluxo de áudio de link reverso ajustando a taxa de amostras para 255. O estado padrão assumido quando o sistema de display é inicialmente ligado ou conectado está com o fluxo de áudio de link reverso desabilitado. O formato de um pacote de taxa de amostras de áudio reverso é apresentado na Figura 31. Como mostrado na Figura 31, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, taxa de amostras de áudio e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 79 e usa um comprimento fixo pré-selecionado de 4 bytes. 23. Pacotes de overhead de proteção ao conteúdo digital.

Tal pacote permite ao host e a um display trocar mensagens relacionadas ao método de proteção ao conteúdo digital sendo usado. Atualmente são contemplados dois tipos de proteção ao conteúdo, a proteção ao conteúdo de transmissão digital (DTCP - Digital Transmission Content Protection), ou o sistema de proteção ao conteúdo digital de largura de banda elevada (HDCP - High-bandwidth Digital Content Protection), com espaço reservado para futuras designações de esquemas de proteção alternativos. O método sendo usado é especificado por um parâmetro de tipo de proteção ao conteúdo em tal pacote. O formato de um pacote de overhead de proteção ao conteúdo digital é apresentado na Figura 32. Como mostrado na Figura 32, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, tipo de proteção ao conteúdo, mensagens de overhead de proteção ao conteúdo e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 80. 24 . Pacotes___de____habilitação____de____cor transparente. O pacote de habilitação de cor transparente é usado para especificar qual cor é transparente em um display e para habilitar ou desabilitar o uso de uma cor transparente para a apresentação de imagens. Os displays que possuem tal capacidade irão reportar tal capacidade no bit 4 do campo indicadores de capacidade de recursos de display do pacote de capacidade de display. Quando um pixel com o valor para cor transparente é escrito no bitmap, a cor não se modifica do valor anterior. O formato de um pacote de habilitação de cor transparente é apresentado na Figura 33. Como mostrado na Figura 33, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, habilitação de cor transparente, descritor de formato de dados, valor de pixel transparente e CRC. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 81 no campo tipo 1 byte e usa um comprimento fixo pré-selecionado de 10 bytes. 25. Pacotes de medição de retardo de ida-e- volta. O pacote de medição de retardo de ida-e-volta é usado para medir o retardo de propagação do host para um cliente (display) mais o retardo do cliente (display) de volta ao host. Tal medição inclui inerentemente os retardos que existem nos drivers de linha e receptores e um subsistema interconectado. Tal medição é usada para ajustar os parâmetros de retardo de inversão e divisor de taxa de link reverso no pacote de encapsulamento de link reverso acima descrito de forma geral . Tal pacote é mais útil quando o link MDDI está operando na velocidade máxima desejada para uma aplicação específica. O sinal MDDI_Stb se comporta como se dados todo de zeros estivessem sendo enviados durante os seguintes campos: todo de zeros, ambos os tempos de guarda e o período de medição. Isto leva o MDDI_Stb a se comutar na metade da taxa de dados de forma a que possa ser usado como um clock 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 é apresentado na Figura 34. Como mostrado na Figura 34, tal tipo de pacote é estruturado para possuir campos de comprimento de pacote, tipo de pacote, CRC de parâmetro, alinhamento ao estrobo, todo de zeros, tempo de guarda 1, período de medição, tempo de guarda 2 e reabilitação de driver. Tal tipo de pacote é de um modo geral identificado como um pacote tipo 82 e usa um comprimento fixo pré-selecionado de 535 bits.

Os eventos de timing que ocorrem durante o pacote de medição de retardo de ida-e-volta estão ilustrados na Figura 35. Na Figura 35, o host transmite o pacote de medição de retardo de ida-e-volta, mostrado pela presença dos campos de CRC de parâmetro e alinhamento ao estrobo seguidos pelos campos todo de zeros e tempo de guarda 1. Um retardo 3502 ocorre antes que o pacote alcance o dispositivo de display de cliente ou circuitos de processamento. A medida que o display recebe o pacote, ele transmite o padrão Oxff, Oxff, 0x0 de forma tão precisa quanto possível no início do período de medição tal como determinado pelo display. O momento real em que o display inicia a transmissão desta seqüência é retardado do início do período de medição a partir do ponto de vista do host. A quantidade de tal retardo é precisamente o tempo necessário para que o pacote se propague através dos drivers de linha e receptores e o subsistema de interconexão. Uma quantidade similar de retardo 3504 ocorre para que o padrão se propague do display de volta ao host.

Para determinar acuradamente o tempo de retardo de ida-e-volta para sinais indo e vindo do cliente, o host conta o número de períodos de tempo de bits que ocorrem apôs o início do período de medição até que o início da seqüência Oxff, Oxff, 0x0 seja detectado na chegada. Tal informação é usada para determinar a quantidade de tempo para que um sinal de ida e volta passe do host para o cliente e volte. A seguir, cerca de metade de tal quantidade é atribuída ao retardo criado pela passagem em um sentido de um sinal para o cliente. O display desabilita seus drivers de linha de forma substancialmente imediata após o envio do último bit do padrão Oxff, Oxff, 0x0. O tempo de guarda 2 dá tempo para que os drivers de linha do display passem completamente para o estado de alta impedância antes que o host transmita o comprimento de pacote do próximo pacote. Os resistores de ativação e desativação (pull-up e pull-down) da hibernação (ver Figura 42) asseguram que os sinais MDDI_Data sejam mantidos em um nível baixo válido nos intervalos em que os drivers de linha são desabilitados em ambos o host e o display. D. CRC do pacote.

Os campos CRC aparecem no final dos pacotes e algumas vezes após certos parâmetros mais críticos em um pacote que pode ter um campo de dados significativamente grande e, portanto, uma maior probabilidade de erros durante a transferência. Nos pacotes que possuem dois campos CRC, o gerador de CRC, quando somente um é usado, é reinicializado após a primeira CRC de forma que as computações de CRC que se seguem a um campo de dados longo não sejam afetadas pelos parâmetros no início do pacote.

Em uma modalidade exemplar da invenção, o polinômio usado para o cálculo de CRC é conhecido como CRC-16, ou X16 + X15 + X2 + Xo. Uma implementação amostra de um gerador de CRC e um verificador 3600 útil para a implementação da invenção é apresentada na Figura 36. Na Figura 36 um registrador de CRC 3602 é inicializado em um valor de 0x0001 imediatamente antes da transferência do primeiro bit de um pacote que é inserido na linha Tx_MDDI_Data_before_CRC, a seguir os bytes do pacote são deslocados para o registrador iniciando com o LSB. Note-se que os números de bits do registrador nesta figura correspondem à ordem do polinômio sendo usado e não às posições de bits usadas pela MDDI. É mais eficiente deslocar o registrador de CRC em uma única direção e isto resulta no bit CRC-15 aparecendo na posição de bit 0 do campo CRC MDDI, e o bit de registrador de CRC-14 no campo CRC MDDI posição de bit 1 e assim por diante até que seja alcançada a posição de bit 14 na MDDI.

Como um exemplo, se os conteúdos de pacote para os pacotes de requisição e estado de display são: 0x07, 0x46, 0x000400, 0x00 (ou representados como uma seqüência de bytes como: 0x07, 0x00, 0x46, 0x00, 0x04, 0x00, 0x00) e são submetidos usando-se as entradas dos multiplexadores 3604 e 3606 e a porta NAND 3608, a saída CRC resultante na linha Tx_MDDI_Data_with_CRC é OxOeal (ou representada como uma seqüência como Oxal, OxOe).

Quando o gerador de CRC e o verificador 3600 estão configurados como um verificador de CRC, o CRC que é recebido na linha Rx_MDDI_Data é inserido no multiplexador 3604 e porta NAND 3608 e é comparado, bit a bit, com o valor encontrado no registrador de CRC usando a porta NOR 3610, a porta OU-exclusiva (XOR) 3612 e a porta AND 3614. Caso exista qualquer erro, tal como emitido pela porta AND 3614, a CRC é incrementada uma vez a cada pacote que contenha um erro de CRC pela conexão da saída da porta 3614 â entrada do registrador 3602. Note-se que o exemplo de circuito mostrado no diagrama da Figura 36 pode emitir mais de um sinal de erro de CRC dentro de uma dada janela CHECK_CRC_NOW (ver Figura 3 7b) . Portanto, o contador de erros de CRC irá contar somente o primeiro caso de erro de CRC dentro de cada intervalo em que CHECK_CRC_NOW esteja ativo. Caso configurada como um gerador de CRC, a CRC é temporizada na saída do registrador de CRC no momento coincidente com o final do pacote. 0 timing para os sinais de entrada e saída e os sinais de habilitação, está graficamente ilustrado nas Figuras 37a e 37b. A geração de uma CRC e a transmissão de um pacote de dados são apresentadas na Figura 3 7a com o estado (o ou 1) dos sinais Gen_reset, Check_CRC_now, Generate_CRC_now e Sending_MDDI_Data, juntamente com os sinais Tx_MDDI_Data_Before_CRC e Tx_MDDI_Data_With CRC. A recepção de um pacote de dados e a verificação do valor de CRC são apresentadas na Figura 37b, com o estado dos sinais Gen_Reset, Check_CRC_Now, Generate_CRC_NOw, e Sending_MDDI_Data, juntamente com sinais Rx_MDDI_Data e erro de CRC. V. Reinicialização de link a partir da hibernação.

Quando o host reinicializa o link de emissão a partir de um estado de hibernação ele passa MDDI_Data para um estado de um lógico por cerca de 150 μθ, e a seguir ativa MDDI_Stb e simultaneamente leva MDDI_Data para um estado de zero lógico por 50 μβ, e a seguir inicia o tráfego de link de emissão pelo envio de um pacote de cabeçalho de subframe. Isto de um modo geral permite que conflitos de barramento sejam resolvidos antes que o pacote de cabeçalho de subframe seja enviado por prover tempo de estabilização suficiente entre sinais.

Quando o cliente, no caso um display, necessita de dados ou comunicação provenientes do host ele passa a linha MDDI_DataO para um estado de um lógico por cerca de 70 μθ, apesar de outros períodos poderem ser usados como desejado, e a seguir desabilita o driver colocando em um estado de alta impedância. Esta ação leva o host a iniciar ou reiniciar o tráfego de dados no link de emissão (208) e pesquisar o cliente quanto a seu estado. O host deve detectar a presença do pulso de requisição dentro de 50 μθ e a seguir iniciar a seqüência de partida (startup) de passar MDDI_DataO para um lógico por 150 με e para zero lógico por 50 μ3. O display não deve mandar um pulso de requisição de serviço caso ele detecte MDDI_DataO no estado de um lógico um por mais de 50 με. A natureza da seleção dos tempos e tolerâncias de intervalos de tempo relacionada ao processamento de hibernação e a seqüência de partida serão adicionalmente comentadas mais adiante.

Um exemplo das etapas de processamento para um típico evento de requisição de serviço 3800 sem conflitos está ilustrado na Figura 38, em que os eventos são referidos por conveniência de ilustração usando-se as letras A, B, C, D, E, F e G. O processo começa no ponto A quando o host envia um pacote de desativação de link para o dispositivo cliente para informá-lo de que o link irá passar para um estado de hibernação de baixa energia. Em uma próxima etapa, o host entra no estado de hibernação de baixa energia ao desabilitar o driver MDDI_Data0 e passar o driver MDDI_Stb para um zero lógico, tal como mostrado no ponto B. MDDI_Data0 é passado para um nível zero por uma rede bias de alta impedância. Após um certo período de tempo, o cliente envia um pulso de requisição de serviço para o host passando MDDI_Data0 para um nível um lógico tal como visto no ponto C. O host ainda confirma o nível zero usando a rede bias de alta impedância, porém o driver no cliente força a linha para um nível um lógico. Dentro de 50 ps o host reconhece o pulso de requisição de serviço e confirma um nível um lógico em MDDI_DataO ao habilitar seu driver, como visto no ponto D. O cliente a seguir pára de tentar confirmar o pulso de requisição de serviço e o cliente coloca seu driver em um estado de alta impedância, como visto no ponto E. O host passa MDDI_DataO para um nível zero lógico por 50 μ3, como mostrado no ponto F e também inicia a geração de MDDI_Stb de uma maneira consistente com o nível zero lógico na MDDI_DataO. Após confirmar MDDI_DataO em um nível zero e acionar MDDI_Stb por 50 ps, o host inicia a transmissão de dados no link de emissão pelo envio de um pacote de cabeçalho de subframe, tal como mostrado no ponto G.

Um exemplo similar está ilustrado na Figura 39 em que uma requisição de serviço é confirmada após o início da seqüência de reinicio de link e os eventos são novamente - referidos usando-se .as letras A, B, C. D, E, F e G. Isto representa uma situação de pior caso, em que um pulso de requisição proveniente do cliente fica mais próximo de corromper o pacote de cabeçalho de subframe. O processo se inicia no ponto A quando o host novamente envia um pacote de desativação de link para o dispositivo cliente para informá-lo de que o link irá passar para um estado de hibernação de baixa energia. Em uma próxima etapa, o host entra no estado de hibernação de baixa energia ao desabilitar o driver MDDI_DataO e ajustar o driver MDDI_Stb para um zero lógico, tal como mostrado no ponto B. Como antes, MDDI_DataO é levado a um nível zero por uma rede bias de alta impedância. Após um período de tempo, o host inicia a seqüência de reinicio de link levando MDDI_DataO para um nível um lógico por 15 0 ps como visto no ponto C. Antes que passem 50 ps após o início da seqüência de reinicio de link o display também aciona MDDI_Data0 por uma duração de 70 μθ, como visto no ponto D. Isto ocorre porque o display necessita requisitar serviço a partir do host e não reconhece que o host já iniciou a sequência de reinicio de link. O cliente, a seguir, cessa as tentativas de acionar o pulso de requisição de serviço e o cliente coloca seu driver em um estado de alta impedância, tal como visto no ponto E. O host continua a levar MDDI_DataO para um nível lógico um. O host leva MDDI_DataO para um nível lógico zero por 50 μθ, tal como mostrado no ponto F e também começa a gerar MDDI_Stb de uma maneira consistente com o nível lógico zero na MDDI_DataO. Após levar MDDI_DataO para um nível zero e acionar MDDI_Stb por 50 μβ, o host inicia a transmissão de dados através do link de emissão pelo envio de um pacote de cabeçalho de subframe, como mostrado no ponto G. VI. Especificações elétricas da interface.

Nas modalidades exemplares da presente invenção, dados em um formato não-retorna-zero (NRZ - Non-Return-to-Zero) são codificados usando-se um sinal de dados estrobo ou formato DATA-STB, que permite que informações de clock sejam embutidas nos sinais de dados e estrobo. 0 clock pode ser recuperado sem circuitos complexos de loop travado por fase (PLL - Phase Lock Loop). Os dados são portados através de um link diferencial bidirecional, implementado de um modo geral pelo uso de um cabo de fios, apesar de outros condutores, fios impressos, ou elementos de transferência poderem ser usados, como foi acima mencionado. O sinal de estrobo (STB) é portado através de um link unidirecional que é acionado apenas pelo host. 0 sinal de estrobo muda o valor (0 ou 1) sempre que existe um estado lado a lado (back-to-back) , 0 ou 1, que permanece o mesmo na linha ou sinal de dados. É apresentado em forma gráfica na Figura 40 um exemplo de como uma seqüência de dados, tal como os bits ”1110001011", pode ser transmitida usando-se codificação DATA-STB. Na Figura 40, um sinal DATA 4002 é mostrado na linha superior de um gráfico de timing de sinal e um sinal STB 4004 é mostrado em uma segunda linha, cada um alinhado em tempo conforme apropriado (ponto inicial comum). A medida que o tempo passa, quando ocorre uma mudança de estado na linha DATA 4002 (sinal), a linha STB 4004 (sinal) mantém um estado anterior, dessa forma o primeiro estado ”1" do sinal DATA se correlaciona ao primeiro estado ”0" para o sinal STB, seu valor inicial. No entanto, se ou quando o estado, nível, do sinal DATA não muda, o sinal STB se comuta para o estado oposto ou ”1" no presente exemplo, como ocorre na Figura 40, em que DATA está provendo outro valor ”1". Isto é, existe sempre uma e apenas uma transição por ciclo de bit entre DATA e STB. Portanto, o sinal STB muda novamente, desta vez para ”0" enquanto o sinal DATA permanece em ”1" e mantém este nível ou valor quando o sinal DATA muda o nível para "0" . Quando o sinal DATA permanece em "1", o sinal STB muda para o estado oposto, ou ”1" no presente exemplo, e assim por diante, a medida que o sinal DATA muda ou mantém os níveis ou valores.

Ao receber tais sinais, é efetuada uma operação OU-exclusiva (XOR) sobre os sinais DATA e STB para produzir um sinal de clock 4006, que é mostrado no fundo do gráfico de timing para comparação relativa com os sinais de dados e estrobo desejados. Um exemplo de circuitos úteis para gerar as saídas ou sinais DATA e STB a partir de dados de entrada no host e a seguir recuperação ou recaptura de dados a partir dos sinais DATA e STB no cliente, é apresentado na Figura 41.

Na Figura 41, uma porção de transmissão 4100 é usada para gerar e transmitir os sinais DATA e STB originais através de uma trajetória de sinal intermediária 4102, enquanto uma porção de recepção 412 0 é usada para receber os sinais e recuperar os dados. Como mostrado na Figura 41, para transferir dados de um host para um cliente, o sinal DATA é enviado a dois elementos de circuito flip-flop tipo D 4104 e 4106 juntamente com um sinal de clock para acionar os circuitos. As duas saídas (Q) dos circuitos flip-flop são a seguir divididas em um par diferencial de sinais MDDI_DataO+, MDDI_DataO- e MDDI_Stb+, MDDI_Stb-, respectivamente, usando-se dois drivers de linha diferencial 4108 e 4110 (modo de tensão). Uma porta NOR-exclusiva (XNOR) de três entradas, circuito ou elemento lógico 4112 é conectado para receber DATA de as saídas de ambos os flip-flops, e gera uma saída que propicia a entrada de dados para o segundo flip-flop, que por sua vez gera os sinais MDDI_Stb+, MDDI_Stb-. Por conveniência, a porta XNOR possui a bolha (bubble) de inversão posicionada para indicar que ela está efetivamente invertendo a saída Q do flip-flop que gera o estrobo.

Na porção de recepção 412 0 da Figura 41, os sinais MDDI_DataO +, MDDI_Data0- e MDDI_Stb+, MDDI_Stb- são recebidos por cada um de dois receptores de linha diferencial 4122 e 4124, que geram saídas únicas a partir dos sinais diferenciais. As saídas dos amplificadores são a seguir inseridas em cada uma das entradas de uma porta 0U-exclusiva (XOR) de duas entradas, circuito, ou elemento lógico 4126 que produz o sinal de clock. O sinal de clock é usado para acionar cada um de dois circuitos flip-flop tipo D 412 8 e 413 0, que recebem uma versão retardada do sinal DATA, através do elemento de retardo 4123, um dos quais (4128) gera valores de dados "0" e o outro (4130), valores de dados "1". O clock possui também uma saída independente proveniente da lógica XOR. Uma vez que as informações de clock estão distribuídas entre as linhas DATA e STB, nenhum sinal muda de estado mais rapidamente que metade da taxa de clock. Uma vez que o clock é reproduzido usando-se o processamento OU-exclusivo dos sinais DATA e STB, o sistema efetivamente tolera duas vezes a quantidade de oscilação entre a entrada de data e clock em comparação à situação em que um sinal de clock é enviado diretamente através de uma única linha de dados dedicada.

Os sinais MDDI_Data+, MDDI_Data- e MDDI_Stb+, MDDI_Stb- são operados em um modo diferencial para maximizar a imunidade dos efeitos negativos do ruido. Cada porção da trajetória de sinal diferencial termina na fonte com metade da impedância característica do cabo ou condutor sendo usado para a transferência dos sinais. MDDI_Data+ e MDDI_Data- terminam na fonte tanto na extremidade do host como do cliente. Uma vez que somente um desses dois drivers está ativo em um determinado momento, existe sempre uma terminação na fonte para o link de transferência. Os sinais MDDI_Stb+ e MDDI_Stb- são acionados apenas pelo host.

Uma configuração exemplar de elementos úteis para se conseguir os drivers, receptores e terminações para transferência de sinais como parte da interface MDD da invenção é mostrada na Figura 42, enquanto as correspondentes especificações elétricas de CC de MDDI_Data e MDDI_Stb estão apresentadas na Tabela VII. Tal interface exemplar usa sensoriamento de baixa tensão, no caso 200 mV, com oscilações de tensão de menos de 1 volt e baixo consumo de energia.

Tabela VII

Os parâmetros elétricos e características dos drivers de linha diferencial e receptores de linha estão na Tabela VIII. Funcionalmente, o driver transfere o nível lógico na entrada diretamente para uma saída positiva e o inverso da entrada para uma saída negativa. O retardo da entrada para as saídas está bem combinado â linha diferencial que é acionada diferencialmente. Na maioria das implementações, a oscilação de tensão nas saídas é menor que a oscilação na entrada para minimizar o consumo de energia e emissões eletromagnéticas. A Tabela VIII apresenta um mínimo de oscilação de tensão em torno de 0,8 V. No entanto, podem ser usados outros valores, como é do conhecimento dos técnicos na área e a Requerente contempla um valor menor, da ordem de 0,5 ou 0,6 V em algumas modalidades, dependendo de restrições de projeto.

Os receptores de linha diferencial possuem a mesma característica que um comparador de tensão de 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 1 lógico caso: (Ventrada+) - (Ventrada-) seja maior que zero. Outra forma de descrever isto consiste de um amplificador diferencial com ganho muito grande (virtualmente infinito) com a saída mantida em níveis de tensão de 1 e 0 lógicos. A distorção (skew) de retardo entre diferentes pares deve ser minimizada para operar o sistema de transmissão diferencial na velocidade potencial mais elevada.

Na Figura 42, um controlador de host 4202 e um controlador de cliente ou display 4204 são mostrados transferindo pacotes através do link de comunicação 4206. O controlador de host emprega uma série de três drivers 4210, 4212 e 4214 para receber os sinais DATA e STB do host a serem transferidos, bem como para receber os sinais DATA do cliente a serem transferidos. O driver responsável pela passagem do DATA do host emprega uma entrada de sinal de habilitação (enable signal) para permitir a ativação do link de comunicação somente quando for desejada a transferência do host para o cliente. Uma vez que o sinal STB é formado como parte da transferência de dados, não é empregado qualquer sinal adicional de habilitação para tal driver (4212). As saídas de cada um dos drivers DATA e STB estão conectadas a impedâncias ou resistores de terminação 4216a, 4216b, 4216c e 4216d, respectivamente.

Os resistores de terminação 4216a e 4216b também atuarão como impedâncias na entrada do receptor no lado do cliente 4220 para o processamento do sinal STB, enquanto que resistores de terminação adicionais 4216e e 4216f são colocados em série com os resistores 4216c e 4216d, respectivamente, na entrada do receptor de processo de dados do cliente 4222. Um sexto driver 4226 no controlador de cliente é usado para preparar os sinais de dados sendo transferidos do cliente para o host, em que o driver 4214, através dos resistores de terminação 4216c e 4216d, no lado de entrada, processa os dados para transferência para o host para processamento.

Dois resistores adicionais 4218a e 4218b são colocados entre os resistores de terminação e o terra e uma fonte de tensão 4220, respectivamente, como parte do controle de hibernação descrito em outro local. A fonte de tensão é usada para acionar as linhas de transferência para o nível alto ou baixo acima descrito para gerenciar o fluxo de dados.

Os drivers e impedâncias acima podem ser formados como componentes separados ou como parte de um circuito integrado de aplicação específica (ASIC) que atua como uma solução de codificador ou decodificador mais eficaz em termos de custos.

Poderá ser prontamente notado que a energia é transferida para o dispositivo cliente, ou display, a partir do dispositivo host usando-se os sinais referidos como MDDI_Pwr e MDDI_Gnd através de um par de condutores. A porção MDDI_Gnd do sinal atua como o terra (ground) de referência e a trajetória ou sinal de retorno do suprimento de energia para o dispositivo de display. O sinal MDDI_Pwr atua como o suprimento de energia do dispositivo de display, que é acionado pelo dispositivo host. Em uma configuração exemplar, para aplicações de baixa energia, o dispositivo de display pode puxar até 500 mA. O sinal MDDI_Pwr pode ser provido a partir de fontes de energia portáteis, tais como, porém não limitadas a, uma bateria ou conjunto de baterias do tipo íons de lítio residente no dispositivo host, podendo variar de 3,2 a 4,3 volts com relação a MDDI_Gnd. VII. Características de timing. A. Visão geral.

As etapas e níveis de sinal, empregadas por um cliente para assegurar serviço a partir do host e pelo host para prover tal serviço, estão ilustradas na Figura 43. Na Figura 43, a primeira parte dos sinais ilustrados mostra um pacote de desativação de link sendo transferido a partir do host e a linha de dados é a seguir acionada para um estado de zero lógico usando-se o circuito de bias de alta impedância. Nenhum dado está sendo transmitido pelo display de cliente, ou host, o qual tem seu driver desabilitado. Uma série de pulsos de estrobo para a linha do sinal MDDI_Stb pode ser vista no fundo, uma vez que MDDI_Stb está ativo durante o pacote de desativação de link. Uma vez que termine tal pacote e o nível lógico mude para zero, quando o host mudar o circuito de bias e a lógica para zero, a linha de sinal MDDI_Stb também mudará para um nível zero. Isto representa o término da última transferência de sinal ou serviço a partir do host e poderia ter ocorrido em qualquer momento anterior e é incluído para mostrar o cessar de serviço anterior e o estado dos sinais antes do início dos serviços. Caso desejado, tal sinal pode ser enviado apenas para resetar ou reajustar o link de comunicação para o estado apropriado sem que uma comunicação anterior "conhecida" tenha sido encetada por tal dispositivo host.

Como mostrado na Figura 43, o sinal emitido a partir do cliente é inicialmente ajustado em um nível zero lógico. Dito de outra forma, a saída do cliente está em uma impedância elevada e o driver está desabilitado. Quando o serviço está sendo requerido, o cliente habilita seu driver e envia uma requisição de serviço para o host, o que constitui um período de tempo, designado por tserviço/ durante o qual a linha é passada para um nível um lógico. A seguir, se passa uma certa quantidade de tempo, ou ela pode ser necessária, antes que o host detecte a requisição, designada como tdetecção-host, após o que, o host responde com uma seqüência de início ou partida de link, levando o sinal para um nível um lógico. Neste ponto, o cliente cancela a requisição e desabilita o driver de requisição de serviço de forma a que a linha de saída a partir do cliente passe novamente para o nível zero lógico. O host aciona a saída de dados do host no nível "1" por um período de tempo denominado treinicia-aito, após o que, o host passa o nível lógico para zero e ativa MDDI_Stb por um período denominado treinicia-baixo/ após o que o primeiro tráfego de emissão se inicia com um pacote de cabeçalho de frame, e os pacotes de tráfego de emissão são a seguir transferidos. O sinal MDDI_Stb está ativo durante o período treinicia-baixo e o subseqüente pacote de cabeçalho de frame. A Tabela VIII mostra tempos representativos para a duração dos vários períodos acima descritos e a relação com taxas de dados mínima e máxima exemplares, em que Tabela VIII

Os técnicos na área notarão prontamente 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 timing na Figura 4 3 . Os detalhes sobre as terminações em série e resistores de hibernação que são mostrados na Figura 42 foram omitidos na Figura 41 pois tais informações são desnecessárias para uma descrição de como efetuar a codificação de dados - estrobo e recuperar o clock a partir da mesma. B. Link de emissão de timing de dados estrobo.

As características de comutação para a transferência de dados através do link de emissão a partir da saída de driver do host estão na Tabela IX. A Tabela IX apresenta uma forma tabular dos mínimo e máximo desejados versus tempos típicos para que ocorram certas transições de sinal. Como exemplo, a típica duração de tempo para que ocorra uma transição do início até o final de um valor de dados (saída de um "0" ou "1") , uma transição DataO para DataO, denominada ttdd- (saída-host> , é ttbit/ sendo o tempo mínimo de cerca de ttbit-0,5 ns e o máximo de cerca de ttbit+0,5 ns. O espaçamento relativo entre transições no DataO, outras linhas de dados (DataX) e as linhas de estrobo (Stb) , está ilustrado na Figura 44, em que são mostradas 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, que são designadas como ttds- (saída-host) , ttSs-(saída- host) r t-tsd-(saída-host) / t-tddx-(saída-host) , ttdxdx-(saída-host) , ttdxs-(saída-host) e ttsdx-(saída-host) / respectivamente.

Tabela IX

Os típicos requerimentos de timing MDDI para a entrada do receptor de cliente para os mesmos sinais transferindo dados no link de emissão estão na Tabela X. Uma vez que os mesmos sinais estão sendo descritos, porém retardados no tempo, nenhuma nova figura é necessária para ilustrar as características de sinal ou o significado das respectivas designações, como será entendido pelos técnicos na área.

Tabela X

As Figuras 45 e 46 ilustram a presença de um retardo em resposta que pode ocorrer quando o host desabilita ou habilita o driver de host, respectivamente. No caso de um host repassando certos pacotes, tais como o pacote de encapsulamento de link reverso ou o pacote de medição de retardo de ida-e-volta, o host desabilita o driver de linha após os pacotes desejados serem repassados, tais como a CRC de parâmetro, alinhamento ao estrobo e os pacotes todo de zeros ilustrados na Figura 4 5 como tendo sido transferidos. No entanto, como mostrado na Figura 45, o estado da linha não se comuta necessariamente de "0" para um valor mais alto desejado instantaneamente, apesar do mesmo poder ser potencialmente obtido com certos elementos de controle ou circuito presentes, porém é necessário um período de tempo denominado como o período de retardo de desabilitação de driver de host para a resposta. Enquanto ele puder ocorrer de forma virtualmente instantânea, de tal modo que tal período de tempo seja de 0 nanossegundos (ns) de duração, ele podería mais facilmente se estender por um período mais longo, com 10 ns sendo um período de duração máxima desejado, o que ocorre durante os períodos do pacote de tempo de guarda 1 ou de inversão 1.

Observando a Figura 46, pode-se ver a mudança de nível de sinal que ocorre quando o driver de host é habilitado para a transferência de um pacote tal como o pacote de encapsulamento de link reverso ou o pacote de medição de retardo de ida-e-volta. Neste ponto, após os períodos dos pacotes de tempo de guarda 2 ou de inversão 2, o driver de host é habilitado e começa a acionar um nível, no caso "0", valor este que é aproximado ou alcançado durante um período de tempo denominado como o período de retardo de habilitação de driver de host, o que ocorre durante o período de reabilitação de driver, antes que o primeiro pacote seja enviado.

Um processo similar ocorre para os drivers e transferências de sinal para o dispositivo cliente, no caso um display. Os princípios gerais para a duração de tais períodos, e suas respectivas relações, estão na Tabela XI a seguir.

Tabela XI C. Link reverso de timing de dados - estrobo.

As características de comutação e relações de timing para os sinais de dados e estrobo usados para a transferência de dados no link reverso a partir da saída do driver de cliente são apresentadas nas Figuras 4 7 e 48. Os tempos típicos para certas transições de sinais serão descritos a seguir. A Figura 47 ilustra a relação na entrada do receptor de host entre o timing dos dados sendo transferidos e as bordas inicial (leading) e final (trailing) dos pulsos de estrobo. Isto é, o que é designado como o tempo de set-up ou ajuste para a borda ascendente ou inicial dos sinais de estrobo, tsu-sr, e o tempo de ajuste para a borda final ou descendente dos sinais de estrobo, tsu-sf· Uma típica duração de tempo para tais períodos de ajuste é da ordem de 8 nanossegundos. A Figura 48 ilustra as características de comutação e o correspondente retardo de saída do cliente desenvolvido pelo timing de dados reversos. Na Figura 48, pode-se ver a relação entre o timing dos dados sendo transferidos e as bordas inicial e final dos pulsos de estrobo responsáveis pelo retardo induzido. Isto é, o que é referido como o retardo de propagação entre a borda ascendente ou inicial dos sinais de estrobo e os dados, tp<j-sr, e o retardo de propagação entre os dados e a borda final ou descendente dos sinais de estrobo, tPd-Sf· Uma duração de tempo típica para tais períodos de retardo de propagação é da ordem de 8 nanossegundos. VIII. Implementação de controle de link (Operação do controlador de link). A. Processador de pacotes de máquina de estado.

Os pacotes sendo transferidos através de um link MDDI são despachados muito rapidamente, tipicamente em uma taxa da ordem de 3 00 Mbps ou mais, apesar de taxas mais baixas serem certamente acomodadas, conforme desejado. Tal tipo de velocidade do barramento ou link de transferência é muito grande para controle pelos microprocessadores ou similares atualmente disponíveis comercialmente (econômicos) de uso geral. Portanto, uma implementação prática para obtenção de tal tipo de transferência de sinal é a de utilizar uma máquina de estado programável para dividir (parse) o fluxo de pacotes de entrada para produzir pacotes que são transferidos ou redirecionados para o subsistema áudio visual apropriado para o qual eles se destinam.

Controladores, processadores, ou elementos de processamento de uso geral podem ser usados para atuar mais apropriadamente sobre, ou para manipular, algumas informações tais como pacotes de controle ou estado, que apresentam demandas de velocidade mais baixas. Quando tais pacotes (controle, estado, ou outros pacotes predefinidos) são recebidos, a máquina de estado deve passá-los através de um buffer ou elemento de processamento similar para o processador de uso geral, para que os pacotes possam ser modificados para prover um resultado (efeito) desejado, enquanto que os pacotes de áudio e visual são transferidos para seu destino apropriado para ação. A função do processador de uso geral pode ser efetuada em algumas modalidades aproveitando-se a energia de processamento, ou excesso de ciclos disponível para microprocessadores (CPUs) em aplicações de computador, ou processadores, processadores de sinais digitais (DSPs -Digital Signal Processors), ou ASICs encontrados nos dispositivos sem fio, da mesma forma que alguns modems ou processadores gráficos utilizam a capacidade de processamento de CPUs em computadores para efetuar certas funções e reduzir a complexidade e custos do hardware. No entanto, isto pode influenciar negativamente a velocidade de processamento, o timing, ou a operação geral de tais elementos, portanto, em muitas aplicações, são preferidos circuitos ou elementos exclusivos para tal processamento geral.

Para que os dados de imagem sejam vistos em um display (micro-display), ou para receber confiavelmente todos os pacotes enviados pelo host, o processamento de sinais de display deve ser sincronizado com o timing do canal de link de emissão. Isto é, os sinais que chegam no display e os circuitos do display devem estar sincronizados no tempo para que ocorra um processamento de sinais apropriado. Um diagrama de alto nível dos estados atingidos pelas etapas de processamento de sinais, ou um método pelo qual tal sincronização pode ser implementada, é apresentado na ilustração da Figura 49. Na Figura 49, são apresentados os possíveis "estados" de sincronização do link de emissão para uma máquina de estado 4900, sendo categorizados como um estado de frames assíncronos 4904, dois estados de aquisição de sincronia 4902 e 4906, e três estados em-sincronização 4908, 4910 e 4912.

Como mostrado na etapa ou estado inicial 4902, o display inicia em um estado pré-selecionado "sem-sincronização" e procura por uma palavra exclusiva no primeiro pacote de cabeçalho de subframe que é detectado. Deve ser notado que tal estado sem sincronização representa o ajuste de comunicação mínimo ou "ajuste de recuo" (fall-back) em que é selecionada uma interface tipo I. Quando a palavra exclusiva é encontrada durante a pesquisa, o display grava o campo comprimento de subframe. Não ocorre conferência dos bits de CRC para o processamento neste primeiro frame, ou até que a sincronização seja obtida. Caso o comprimento deste subframe seja zero, prossegue-se o processamento de estado de sincronização de acordo com o método para o estado 4 904 aqui designado como o estado de "frames assíncronos", que indica que a sincronização ainda não foi obtida. Tal etapa no processamento está marcada como encontrando cond 3 ou condição 3, na Figura 49. Caso contrário, se o comprimento do trame for maior que zero, o processamento de estado de sincronização passa a um estado 4906 em que o estado da interface é ajustado como "encontrado um frame de sincronização". Tal etapa no processamento está marcada como encontrando cond 5 ou condição 5, na Figura 49. Além disso, caso a máquina de estado encontre um pacote de cabeçalho de frame e boa determinação de CRC para um comprimento de frame maior que zero, o processamento passa ao estado "encontrado um frame de sincronização". Isto está referido como encontrando cond 6, ou condição 6, na Figura 49.

Em cada situação em que 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 subframe, e o comprimento de subframe for mais que zero, o estado da interface é mudado para o estado "em-sincronização" 4908. Tal etapa no processamento está marcada como encontrando cond 1, ou condição 1, na Figura 49. Por outro lado, caso a palavra exclusiva ou a CRC no pacote de cabeçalho de subframe não esteja correta, o processamento de estado de sincronização passa ou retorna para o estado de interface 4902 do estado "sem frame de sincronização". Esta porção do processamento está marcada 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 se decidir que a sincronização foi perdida e retornar para o estado de "sem frame de sincronização". Na Figura 49, uma vez que a máquina de estado alcance o "estado em-sincronização" e nenhum erro seja encontrado, está se encontrando continuamente um resultado de cond 1, permanecendo no estado "em-sincronização". No entanto, uma vez detectado um resultado de cond 2, o processamento muda o estado para um estado de "um erro de sincronização" 4910. Neste ponto, caso o processamento resulte na detecção de outro resultado de cond 1, a máquina de estado retorna ao estado "em-sincronização", caso contrário ela encontra outro resultado de cond 2 e passa a um estado de "dois erros de sincronização" 4912. Novamente, caso ocorra uma cond 1, o processamento retorna a máquina de estado para o estado "em-sincronização". Caso contrário, é encontrada outra cond 2 e a máquina de estado retorna para o estado "sem-sincronização". Ê também óbvio que o encontro de um "pacote de desativação de link" irá levar o link a terminar as transferências de dados e retornar para o estado "sem frame de sincronização" uma vez que não há nada com o que se sincronizar, o que é referido como encontrando cond 4, ou condição 4, no diagrama de estado da Figura 49.

Deve ficar claro que é possível a existência de uma "cópia falsa" repetida da palavra exclusiva, que pode aparecer em algum local fixo dentro do subframe. Em tal situação, é altamente improvável que a máquina de estado irá se sincronizar ao subframe pois a CRC no pacote de cabeçalho de subframe deve também ser válida quando processado de modo a que o processamento da interface MDD prossiga para o estado "em-sincronização". O comprimento de subframe no pacote de cabeçalho de subframe pode ser ajustado para zero para indicar que o host irá transmitir somente um subframe antes que o link seja desativado e a interface MDD é colocada, ou configurada, em um estado de hibernação inativo (idle). Neste caso, o display deve imediatamente receber pacotes através do link de emissão após detectar o pacote de cabeçalho de subframe pois somente um único subframe é enviado antes que o link passe ao estado inativo. Em operações normais ou típicas, o comprimento de subframe é diferente de zero e o display só processa pacotes do link de emissão enquanto a interface está naqueles estados coletivamente apresentados como estados "EM_SINCRONIZAÇÃO" na Figura 49. O tempo requerido para que um display se sincronize ao sinal do link de emissão é variável, dependendo do tamanho de subframe e da taxa de dados do link de emissão. A probabilidade de detecção de uma "cópia falsa" da palavra exclusiva como parte dos dados aleatórios, ou mais aleatórios, no link de emissão é maior quando o tamanho do subframe for maior. Ao mesmo tempo, a capacidade de recuperação a partir de uma detecção falsa é mais baixa, e o tempo necessário para tal é mais longo, quando uma taxa de um link de emissão for mais lenta. C. Inicialização.

Como foi acima mencionado, no momento da partida (start-up) , o host configura o link de emissão para operar em, ou abaixo de, uma taxa de dados mínima requerida, ou desejada de 1 Mbps e configura o comprimento de subframe e a taxa mídia/frame apropriadamente para uma dada aplicação. Isto é, ambos os links de emissão e reverso iniciam a operação usando a interface tipo I. Tais parâmetros só serão de um modo geral usados temporariamente enquanto o host determina a capacidade ou configuração desejada para o display de cliente (ou outro dispositivo). O host envia ou transfere um pacote de cabeçalho de subframe através do link de emissão seguido por um pacote de encapsulamento do link reverso, o qual possui o bit "0" dos flags de requisição ajustado para um valor de um (1) , de modo a requisitar que o display responda com um pacote de capacidade de display. Uma vez que o display adquira a sincronização no (ou com o) link de emissão, ele envia um pacote de capacidade de display e um pacote de requisição e estado de display através do link ou canal reverso. O host examina o conteúdo do pacote de capacidade de display de modo a determinar como reconfigurar o link para um nível de desempenho ideal ou desejado. O host examina os campos versão de protocolo e versão de protocolo minima para confirmar se o host e o display usam versões do protocolo que são compatíveis entre si. As versões de protocolo permanecem como os dois primeiros parâmetros do pacote de capacidade de display de forma a que a compatibilidade possa ser determinada mesmo quando outros elementos do protocolo possam não ser compatíveis ou completamente 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 ou verificador de CRC seja apropriadamente controlado. Ela também incrementa um contador de erros de CRC quando uma comparação de CRC resulta na detecção de um ou mais erros, e ela reseta o contador de CRC no inicio de cada subframe sendo processado. IX. Processamento de pacotes.

Para cada tipo de pacote que foi acima descrito, recebido pela máquina de estado, ela responsabiliza-se por uma etapa de processamento especifica, ou uma série de etapas, para implementar a operação da interface. Os pacotes de link de emissão são de um modo geral processados de acordo com o processamento exemplar listado na Tabela XII a seguir.

Tabela XII X. Redução da taxa de dados do link reverso.

Foi observado pela Requerente que certos parâmetros usados para o controlador de link de host podem ser ajustados ou configurados de uma certa maneira de modo a se obter uma taxa de dados de link reverso (em escala) máxima ou mais otimizada, o que é muito desejável. Como exemplo, durante o tempo usado para a transferência do campo pacotes de dados reversos do pacote de encapsulamento de link reverso, o par de sinais MDDI_Stb inverte o valor (toggle) para criar um clock de dados periódico com metade da taxa de dados do link de emissão. Isto ocorre porque o controlador de link de host gera o sinal MDDI_Stb que corresponde ao sinal MDDI_DataO como se ele estivesse enviando somente zeros. O sinal MDDI_Stb é transferido do host para um display onde ele é usado para gerar um sinal de clock para a transferência de dados do link reverso a partir do display, com o qual os dados reversos são enviados de volta ao host. Uma ilustração das quantidades típicas de retardo encontradas para a transferência e processamento do sinal nas trajetórias de emissão e reversa em um sistema empregando a MDDI é apresentada na Figura 50. Na Figura 50, é apresentada 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, próxima a porções de processamento para a geração de Stb + /-, transferência para display por cabo, receptor de display, geração de clock, timing de sinal, geração de Data0+/-, transferência para host por cabo e estágios de receptor de host, respectivamente.

Dependendo da taxa de dados do link de emissão e dos retardos de processamento de sinais encontrados, pode ser requerido mais tempo do que um ciclo no sinal MDDI_Stb para que tal efeito de "ida e volta" ou conjunto de eventos seja completado, o que resulta no consumo de quantidades indesejáveis de tempo ou ciclos. Para contornar tal problema, o divisor de taxa reversa torna possível para o tempo de um bit no link reverso abranger múltiplos ciclos do sinal MDDI_Stb. Isto significa que a taxa de dados do link reverso é menor que a taxa do link de emissão.

Deve ser notado que a duração real dos retardos de sinal através da interface podem diferir dependendo de cada sistema host - cliente ou hardware específicos sendo utilizados. Cada sistema pode de um modo geral ser levado a um melhor desempenho pelo uso do pacote de medição do retardo de ida-e-volta para medir o retardo real em um sistema de modo a que o divisor de taxa reversa possa ser ajustado para um valor ideal.

Um retardo de ida-e-volta é medido através do envio pelo host de um pacote de medição de retardo de ida-e-volta para o display. O display responde a este pacote pelo envio de uma sequência de uns de volta ao host dentro de, ou durante, uma janela de medição pré-selecionada em tal pacote denominada como campo de período de medição. O timing detalhado de tal medição foi acima descrito. O retardo de ida-e-volta é usado para determinar a taxa na qual os dados do link reverso podem ser amostrados com segurança. A medição do retardo de ida-e-volta consiste da determinação, detecção, ou contagem do número de intervalos de clock de dados de link de emissão que ocorrem entre o inicio do campo do período de medição e o início do período de tempo em que a seqüência de resposta Oxff, Oxff, 0x00, é recebida de volta no host a partir do display. Note-se que é possível que a resposta proveniente do display seja recebida em uma pequena fração de um período de clock do link de emissão antes que a contagem de medição esteja prestes a ser incrementada. Caso tal valor não modificado seja usado para calcular o divisor de taxa reversa ele podería causar erros de bits no link reverso devido à amostragem de dados não confiável. Um exemplo de tal situação está ilustrado na Figura 51, em que sinais representando MDDI_Data no host, MDDI_Stb no host, clock de dados de link de emissão no interior do host e uma contagem de retardo estão ilustrados em forma gráfica. Na Figura 51, a seqüência de resposta foi recebida a partir do display em uma fração de um período de clock do link de emissão antes que a contagem de retardo estava para ser incrementada de 6 para 7. Caso o retardo seja considerado como sendo 6, o host irá sempre amostrar os dados reversos logo após uma transição de bit ou possivelmente no meio de uma transição de bit. Isto poderia resultar em amostragem errônea no host. Por tal razão, o retardo medido deve ser tipicamente incrementado em um antes de ser usado para calcular o divisor de taxa reversa. O divisor de taxa reversa é o número de ciclos MDDI_Stb que o host deve aguardar antes de amostrar os dados de link reverso. Uma vez que MDDI_Stb é reciclado em uma taxa que é metade da taxa do link de emissão, a medição de retardo de ida-e-volta corrigida deve ser dividida por 2 e a seguir arredondada para o próximo número inteiro. Expressada na forma de uma fórmula, tal relação fica: Divisor_taxa_reversa = arredonda_próximo_inteiro Para o exemplo apresentado ela se torna: Divisor_taxa_reversa - arredonda_próximo_inteiro Caso, a medição de retardo de ida-e-volta usada neste exemplo, fosse 7 e não 6, o divisor de taxa reversa também seria igual a 4.

Os dados de link reverso são amostrados pelo host na borda ascendente do clock de link reverso. Existe um contador ou um circuito ou dispositivo similar conhecido presente em ambos o host e o cliente (display) para gerar o clock de link reverso. Os contadores são inicializados de forma a que a primeira borda ascendente do clock de link reverso ocorra no inicio do primeiro bit no campo pacotes de link reverso do pacote de encapsulamento de link reverso. Isto está ilustrado, para o exemplo apresentado abaixo, na Figura 52. Os contadores são incrementados em cada borda ascendente do sinal MDDI_Stb e o número de contagens que ocorrem até que eles retornem é ajustado pelo parâmetro de divisor de taxa reversa no pacote de encapsulamento de link reverso. Uma vez que o sinal MDDI_Stb muda em metade da taxa do link de emissão, a taxa do link reverso é metade da taxa do link de emissão dividida pelo divisor de taxa reversa. Como exemplo, caso a taxa do link de emissão seja de 200 Mbps e o divisor de taxa reversa seja 4, então a taxa de dados do link reverso é expressa por: Um exemplo mostrando o timing das linhas de sinais MDDI_DataO e MDDI_Stb em um pacote de encapsulamento de link reverso é apresentado na Figura 52, onde os parâmetros de pacote usados para ilustração possuem os valores: comprimento de pacote = 1024 comprimento de inversão 1=1 (0x0400) tipo de pacote = 65 (0x41) comprimento de inversão 2 = 1 flags de link reverso = 0 divisor de taxa reversa = 2 CRC de parâmetro = 0xdb43 todo de zeros é 0x00 alinhamento ao estrobo é 0x00, 0x00, 0x60 os dados de pacote entre os campos comprimento de pacote e CRC de parâmetro são: 0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, Oxdb, 0x00, 0x00, 0x60, 0x00, ... O primeiro pacote de link reverso que volta proveniente do display é o pacote de requisição e estado de display, possuindo um comprimento de pacote de 7 e um tipo de pacote de 70 . Tal pacote se inicia com os valores de byte 0x07, 0x00, 0x46, ... e assim por diante. No entanto, somente o primeiro byte (0x07) está visível na Figura 52. Este primeiro pacote de link reverso está temporalmente deslocado em quase um período de clock de link reverso na figura para ilustrar um retardo de link reverso real. Uma forma de onda ideal com zero retardo de ida-e-volta do host para o display é mostrada na forma de um traço de linha pontilhada. O byte MS do campo CRC de parâmetro é transferido seguido pelos bytes de alinhamento ao estrobo, seguindo-se o campo todo de zeros. O estrobo proveniente do host está se comutando de um para zero e de volta a um a medida que os dados provenientes do host mudam de nível formando pulsos mais longos. A media que os dados tendem a zero, o estrobo se comuta na taxa mais elevada, somente a mudança nos dados na linha de dados causa uma mudança próxima ao final do campo alinhamento. O estrobo se comuta na taxa mais elevada pelo restante da figura devido aos níveis fixos de 0 ou 1 do sinal de dados por períodos de tempo longos e as transições caindo no padrão de pulsos (borda). O clock de link reverso para o host fica em zero até o final do período de inversão 1, quando o clock é inicializado para acomodar os pacotes de link reverso. As setas na porção inferior da figura indicam quando os dados são amostrados, como ficará claro pelo restante da descrição. O primeiro byte do campo pacote sendo transferido (no caso 11000000) é mostrado se iniciando após a inversão 1 e o nível da linha se estabilizou pelo fato do driver de host ser desabilitado. Õ retardo na passagem do primeiro bit, e tal como visto para o bit três, pode ser observado nas linhas pontilhadas para o sinal de dados.

Na Figura 53, podem ser observados valores típicos do divisor de taxa reversa com base na taxa de dados do link de emissão. O divisor de taxa reversa real é determinado como um resultado de uma medição de ida e volta do link para garantir a operação apropriada 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 que uma terceira região 5306 indica ajustes que provavelmente não funcionarão apropriadamente. A medição do retardo de ida-e-volta e o ajuste do divisor de taxa reversa são os mesmos enquanto operando com qualquer ajuste de tipo de interface no link de emissão ou reverso pois eles são expressos e operados em termos de unidades de períodos de clock reais em lugar de número de bits transmitidos ou recebidos. XI. Tempos de inversão (turn-around) e guarda.

Como foi acima mencionado, o campo inversão 1 no pacote de encapsulamento de link reverso e o campo tempo de guarda 1 no pacote de medição de retardo de ida-e-volta, designam valores para durações de tempo que permitem que os drivers de interface de host sejam desabilitados antes que os drivers de interface de display sejam habilitados. Os campos inversão 2 e tempo de guarda 2 propiciam valores de tempo que permitem que os drivers de display sejam desabilitados antes que os drivers de host sejam habilitados. Os campos tempo de guarda 1 e tempo de guarda 2 são de um modo geral preenchidos com valores predeterminados ou pré-selecionados para comprimentos que não devem ser ajustados. Dependendo do hardware de interface sendo usado, tais valores podem ser desenvolvidos usando-se dados empíricos e ajustados em alguns casos para melhorar a operação. Vários fatores contribuem para uma determinação do comprimento de inversão 1 e eles incluem a taxa de dados do link de emissão e o tempo máximo de desabil itação dos drivers MDDI_Data no host. O tempo máximo de desabilitação dos drivers de host está especificado na Tabela XI, onde é mostrado que os drivers levam no máximo cerca de 10 ns para serem desabilitados e cerca de 2 ns para serem habilitados. O número mínimo de clocks de link de emissão necessários para que o driver de host seja desabilitado é expresso de acordo com a relação: A faixa de valores permitida para inversão 1 é expressa de acordo com a relação: Inversão 1 > arredonda próximo inteiro Em que o fator de tipo de interface é 1 para o tipo I, 2 para o tipo 2, 4 para o tipo III e 8 para o tipo IV.

Combinando-se as duas equações acima, podemos ver que o termo fator de tipo de interface se cancela e a inversão 1 é definida por: Inversão 1 = arxedcnda próximo inteiro Como exemplo, um link de emissão do tipo III de 1500 Mbps iria utilizar um retardo de inversão 1 de: Inversão 1 = arredonda próximo inteiro À medida que o retardo de ida-e-volta aumenta, a margem de timing melhora a partir do ponto no tempo em que o host é desabilitado até o momento em que o display é habilitado.

Os fatores que determinam a duração de tempo de um modo geral utilizada para a inversão 2 são a taxa de dados do link de emissão, o tempo máximo de desabilitação dos drivers MDDI_Data no display e o retardo de ida-e-volta do link de comunicação. O cálculo do tempo requerido para desabilitar o driver de display é essencialmente o mesmo que aquele para o driver de host acima descrito e é definido de acordo com a relação: . retardo desabilitação driver de display^ E a faixa de valores permitidos para inversão 2 é expressa por: Inversão 2 > arredcnda próximo inteiro Como exemplo, um link de emissão do tipo III de 1500 Mbps com um retardo de ida-e-volta de 10 clocks de link de emissão usa tipicamente um retardo de inversão 2 da ordem de: Inversão 2 > arredcnda próximo inteiro XII. Descrição de interconexão da camada física.

As conexões físicas úteis para implementação de uma interface de acordo com a presente invenção podem ser efetuadas usando-se peças comercialmente disponíveis tais como a peça N2 3260-8S2(01), produzida pela Hirose Electric Company Ltd. no lado do host e a peça N2 3240-8P-C, produzida pela Hirose Electric Company Ltd. no lado do dispositivo de display. Um exemplo de designação de pinos (pins) de interface tipo I ou "pinout" para tais conectores usados com uma interface tipo I está na Tabela XIII.

Tabela XIII

Os elementos ou dispositivos de interconexão são escolhidos ou projetados de forma a serem pequenos o suficiente para uso com dispositivos de comunicação móvel e computação, tais como PDAs, e telefones sem fio, ou dispositivo de jogos portáteis, sem que obstruam ou sejam pouco estéticos em comparação ao tamanho relativo do dispositivo. Quaisquer conectores e cabeamento devem ser duráveis o suficiente para uso em um típico ambiente de consumidor e permitirem um tamanho pequeno, especialmente para o cabeamento, e de custo relativamente baixo. Os elementos de transferência devem acomodar sinais de dados e estrobo que sejam dados NRZ diferenciais possuindo uma taxa de transferência de até cerca de 450 Mbps para as versões do tipo I e tipo II e até 3,6 Gbps para a versão tipo IV paralela de 8 bits. XIII. Operação.

Um resumo das etapas gerais encetadas no processamento de dados e pacotes durante a operação de uma interface usando modalidades da invenção é apresentado nas Figuras 54a e 54b, juntamente com uma visão geral do processamento pelo equipamento de interface dos pacotes na Figura 55. Nestas figuras, o processo se inicia em uma etapa 5402 com uma determinação sobre se o cliente e o host estão ou não conectados usando uma via de comunicação, no caso um cabo. Isto pode ocorrer através do uso de pesquisa periódica pelo host, software ou hardware que detecta a presença de conectores ou cabos nas entradas para o host (tal como visto para interfaces USB) , ou outras técnicas conhecidas. Caso não exista um cliente conectado ao host, ele pode simplesmente entrar em um estado de espera de uma certa duração predeterminada, dependendo da aplicação, passar a um modo de hibernação, ou ser desativado para aguardar um uso futuro que possa requerer que um usuário aja para reativar o host. Como exemplo, quando um host reside em um dispositivo do tipo computador, um usuário podería ter que "clicar" sobre um ícone em uma tela ou requisitar um programa que ative o processamento do host para procurar pelo cliente. Novamente, a simples conexão de um terminal do tipo USB, tal como aquele usado pela interface tipo U, poderia ativar o processamento do host.

Uma vez que um cliente seja conectado ao host, ou vice versa, ou detectado como estando presente, o cliente ou o host envia pacotes apropriados requisitando serviço nas etapas 5404 e 5406. O cliente poderia enviar pacotes de requisição de serviço ou de estado de display na etapa 5404. Note-se que o link, tal como foi acima mencionado, poderia estar anteriormente desativado, ou estar no modo de hibernação, de forma a que não seja uma inicialização completa do link de comunicação que se segue. Uma vez que o link de comunicação esteja sincronizado e o host esteja tentando se comunicar com o cliente, o cliente também deve prover um pacote de capacidades do display para o host, como na etapa 5408. O host pode agora iniciar a determinação do tipo de suporte, incluindo as taxas de transferência, que o cliente pode acomodar.

De um modo geral, o host e o cliente também negociam o tipo (taxa/velocidade) do modo de serviço a ser usado, por exemplo, tipo I, tipo U, tipo II e assim por diante, em uma etapa 5410. Uma vez estabelecido o tipo de serviço, o host pode iniciar a transferência de informações. Além disso, o host pode usar pacotes de medição do retardo de ida-e-volta para otimizar o timing dos links de comunicação em paralelo com outros processamentos de sinais, tal como mostrado na etapa 5411.

Como acima mencionado, todas as transferências começam com um pacote de cabeçalho de subframe, mostrado como sendo transferido na etapa 5412, seguido pelo tipo de dados, no caso pacotes de fluxos de video e áudio, e pacotes de preenchimento, mostrados em transferência na etapa 5414. Os dados de áudio e vídeo terão sido previamente preparados ou mapeados em pacotes e os pacotes de preenchimento são inseridos conforme a necessidade para preencher o número requerido de bits para os frames de mídia. O host pode enviar pacotes tais como os pacotes de habilitação de canal de áudio de emissão para ativar o dispositivo de som, ou, adicionalmente, o host pode transferir comandos e informações usando outros tipos de pacotes acima mencionados, aqui mostrados na forma de transferência do mapa de cores, transferência de bloco de bits, ou outros pacotes, na etapa 5416. Além disso, o host e o cliente podem trocar dados relacionados a dispositivos de teclado ou apontadores usando os pacotes apropriados.

Pode ocorrer, durante a operação, um dentre vários eventos que leva o host ou o cliente a desejar uma taxa de dados ou tipo de modo de interface diferente. Como exemplo, um computador ou outro dispositivo comunicando dados podería encontrar condições de carga no processamento dos dados que causam uma redução de velocidade na preparação ou apresentação de pacotes. Um display recebendo os dados poderia mudar de uma fonte de energia de CA exclusiva para uma fonte de energia de baterias mais limitada e não seria capaz de transferir dados tão rapidamente, processar comandos tão prontamente, ou não ser capaz de usar o mesmo grau de resolução ou profundidade de cor sob os parâmetros de energia mais limitados. Alternativamente, uma condição restritiva poderia ser reduzida ou desaparecer, permitindo que um dos dispositivos transferisse dados em taxas mais elevadas. Caso isto seja mais desejável, pode ser feita uma requisição para a mudança para um modo de taxa de transferência mais elevada.

Caso estes ou outros tipos de condições conhecidos ocorram ou mudem, o host ou o cliente pode detectá-los e tentar renegociar o modo da interface. Isto é mostrado na etapa 5420, em que o host envia pacotes de requisição de transferência de tipo de interface para o cliente requisitando uma transferência para outro modo; o cliente envia pacotes de confirmação de tipo de interface confirmando que uma mudança é desejada e o host envia pacotes de transferência de tipo de desempenho para efetuar a mudança para o modo especificado.

Apesar de não requerer uma ordem específica de processamento, o cliente e o host podem também trocar pacotes relacionados a dados destinados para, ou recebidos a partir de, dispositivos apontadores, teclados, ou outros dispositivos de entrada do tipo usuário associados principalmente com o cliente, apesar de tais elementos poderem também estar presentes no lado do host. Tais pacotes são tipicamente processados usando-se um processo geral ou elemento tipo e não a máquina de estado 5502. Além disso, alguns dos comandos acima descritos também serão processados pelo processador geral 5504, 5508.

Após os dados e comandos terem sido trocados entre o host e o cliente, e algum ponto é efetuada uma decisão sobre se dados adicionais devem ou não ser transferidos ou se o host ou o cliente irá cessar o serviço de transferência. Isto é mostrado na etapa 5422. Caso o link deve entrar em um estado de hibernação ou ser desativado completamente, o host envia um pacote de desativação de link para o cliente e ambos os lados terminam a transferência de dados.

Os pacotes sendo transferidos no processamento das operações acima serão transferidos usando-se os drivers e receptores acima descritos com relação aos controladores de host e cliente. Tais drivers de linha e outros elementos lógicos estão conectados à máquina de estado e aos processadores gerais acima descritos, tal como ilustrado na visão geral da Figura 55. Na Figura 55, uma máquina de estado 5502 e os processadores gerais 5504 e 5508 podem também estar conectados a outros elementos não mostrados, tal como uma interface USB dedicada, elementos de memória, ou outros componentes residentes fora do controlador de link com o qual eles interagem, incluindo, porém não limitados a, fonte de dados e chips de controle de vídeo para dispositivo de display de visão.

Os processadores e a máquina de estado propiciam controle sobre a habilitação e desabilitação dos drivers, tal como foi acima descrito com relação a tempos de guarda e assim por diante, para assegurar o estabelecimento eficiente ou término do link de comunicação e a transferência de pacotes. XIV. Adendo.

Além dos formatos, estruturas e conteúdos acima descritos para os vários pacotes usados para implementar a estrutura e protocolo para modalidades da invenção, conteúdos de campos ou operações mais detalhados são aqui apresentados para alguns dos tipos de pacotes. Eles são aqui apresentados para melhor esclarecer seus respectivos uso ou operações para permitir aos técnicos na área, uma melhor compreensão e utilização da invenção para uma variedade de aplicações. Somente alguns dos campos que já não foram aqui descritos serão adicionalmente detalhados a seguir. A. Para Pacotes de fluxo de vídeo. O campo atributos de display (1 byte) possui uma série de valores de bits que são interpretados como se segue. Os bits 1 e 0 selecionam como os dados de pixels do display são orientados. Para valores de bit de "00" ou "11", os dados são apresentados para ambos os olhos, para valores de bits "10" os dados são direcionados somente para o olho esquerdo e para valores de bits "01", os dados são direcionados somente para o olho direito. O bit 2 indica se os dados de pixels são ou não apresentados em um formato de interface, com um valor de "0" significando que o dado de pixel está no formato progressivo padrão e que o número de fileira (coordenada Y do pixel) é incrementado em 1 ao avançar de uma fileira para a próxima. Quando tal bit possui um valor de "1", o dado de pixel está em um formato entrelaçado e o número de fileira é incrementado em 2 ao avançar de uma fileira para a próxima. O bit 3 indica que os dados de pixels estão em um formato de pixel alternativo. Isto ê similar ao modo de entrelace (interlace) padrão habilitado pelo bit 2, porém o interlaçamento é vertical em lugar de horizontal. Quando o bit 3 for 0 os dados de pixel estão no formato progressivo padrão e o número da coluna (coordena X dos pixels) é incrementado em 1 a medida que cada pixel sucessivo é recebido. Quando o bit 3 for 1, os dados de pixel estão em um formato de pixels alternativo e o número da coluna é incrementado em 2 a medida que cada pixel for recebido. Os bits 7 a 4 ficam reservados para uso futuro e são, de um modo geral, ajustados para zero.

Os campos X Start e Y Start de 2 bytes especificam as coordenadas X e Y absolutas do ponto (X Start, Y Start) para o primeiro pixel no campo dados de pixels. Os campos de 2 bytes X Left Edge e Y top Edge especificam a coordenada X da borda esquerda (left edge) e a coordenada Y da borda superior da janela da tela preenchida pelo campo dados de pixels, enquanto que os campos X Right Edge e Y Bottom Edge especificam a coordenada X da borda direita e a coordenada Y da borda inferior da janela que está sendo atualizada. O campo contagem de pixels (2 bytes) especifica o número de pixels no campo dados de pixels abaixo. O campo CRC de parâmetro (2 bytes) contém um CRC de todos os bytes desde o comprimento do pacote até a contagem de pixels. Caso tal CRC falhe na conferência, então todo o pacote é descartado. O campo dados de pixels contém as informações de vídeo não processadas (raw) que devem ser apresentadas e que estão formatadas da maneira descrita pelo campo descritor de formato de dados de vídeo. Os dados são transmitidos em uma "fileira" de cada vez, tal como foi acima descrito. O campo CRC de dados de pixels (2 bytes) contém uma CRC de 16 bits apenas dos dados de pixels. Caso uma verificação de CRC de tal valor falhe, então os dados de pixels podem ainda ser usados, porém a contagem de erros de CRC é incrementada. B. Para pacotes de fluxo de áudio. O campo ID de canal de áudio (1 byte) identifica um canal de áudio específico ao qual dados de áudio são enviados pelo dispositivo cliente. Os canais físicos de áudio são especificados ou mapeados por tal campo na forma de valores de 0, 1, 2, 3, 4, 5, 6, ou 7, que indicam respectivamente os canais frontal-esquerdo, frontal-direito, posterior-esquerdo, posterior-direito, central-frontal, sub-woofer, surround-esquerdo e surround-direito. Um valor de ID de canal de áudio de 254 indica que o fluxo único de amostras de áudio digital deve ser enviado para os canais frontal-esquerdo e frontal-direito. Isto simplifica as aplicações em que um fone de ouvido estéreo é usado para comunicação de voz em apps de ampliação de produtividade em um PDA, ou qualquer aplicação em que uma interface de usuário simples gere tons de alerta. Os valores para o campo ID variando de 8 a 253 e 255 são atualmente reservados para uso em que novos projetos necessitem designações adicionais. O campo contagem de amostras de áudio (2 bytes) especifica o número de amostras de áudio neste pacote. O campo bits por amostra e pacote contém 1 byte que especifica o formato de empacotamento de dados de áudio. O formato em geral empregado é o de que os bits 4 a 0 definem o número de bits por amostra de áudio PCM. O bit 5 especifica se as amostras de dados de áudio digital estão ou não empacotadas. Como foi acima mencionado, a Figura 12 ilustra a diferença entre amostras de áudio empacotadas e alinhadas em byte. Um valor de "0" para o bit 5 indica que cada amostra de áudio PCM no campo dados de áudio digital está alinhada em bytes com o limite de byte da interface, enquanto que um valor de "1" indica que cada amostra de áudio PCM sucessiva está empacotada contra a amostra de áudio anterior. Tal bit é efetivo somente quando o valor definido nos bits 4 a 0 (o número de bits por amostra de áudio PCM) não for um múltiplo de oito. Os bits 7 a 6 ficam reservados para uso em projetos de sistemas que desejem designações adicionais e são em geral ajustados para um valor de zero. O campo taxa de amostras de áudio (1 byte) especifica a taxa de amostras PCM de áudio. O formato empregado é para que um valor de 0 indique uma taxa de 8.0 00 amostras por segundo (SPS - samples per second) , um valor de 1 indica 16.000 SPS, o valor de 2 indica 24.000 SPS, o valor de 3 indica 32.000 SPS, o valor de 4 indica 40.000 SPS, o valor de 5 indica 48.000 SPS, o valor de 6 indica 11.025 SPS, o valor de 7 indica 22.050 SPS e o valor de 8 indica 44.100 SPS, respectivamente, com os valores de 9 a 15 ficando reservados para uso futuro, sendo portanto atualmente ajustados para zero. O campo CRC de parâmetro (2 bytes) contém uma CRC de 16 bits de todos os bytes do comprimento de pacote à taxa de amostras de áudio. Caso esta CRC falhe na conferência, todo o pacote é descartado. O campo dados de áudio digital contém as amostras de áudio não processadas a serem reproduzidas e está usualmente na forma de um formato linear como números inteiros não-designados (unsigned). O campo CRC de dados de áudio (2 bytes) contém uma CRC de 16 bits apenas dos dados de áudio. Caso tal CRC falhe na conferência, os dados de áudio podem ainda ser usados porém a contagem de erros de CRC é incrementada. C. Para Pacotes de fluxo definidos pelo usuário. O campo número de ID de fluxo de 2 bytes é usado para identificar um fluxo de vídeo específico. O conteúdo dos campos parâmetros de fluxo e dados de fluxo é definido pelo fabricante do equipamento MDDI. O campo CRC de parâmetro de fluxo de 2 bytes contém uma CRC de 16 bits de todos os bytes dos parâmetros de fluxo do comprimento de pacote até o byte de codificação de áudio. Caso esta CRC falhe na conferência todo o pacote é descartado. O campo CRC de dados de fluxo de 2 bytes contém uma CRC somente dos dados de fluxo. Caso esta CRC falhe na conferência apropriada então o uso dos dados de fluxo é opcional, dependendo dos requerimentos da aplicação. O uso dos dados de fluxo contingente da CRC ser válida, geralmente requer que os dados de fluxo sejam acumulados até que a CRC seja confirmada como válida. A contagem de erros de CRC é incrementada caso a CRC não confira. D. Para pacotes de mapa de cores. O campo tamanho de dados de mapa de cor (2 bytes) especifica o número total de entradas na tabela de mapa de cores que existem nos dados de mapa de cor neste pacote. O número de bytes nos dados de mapa de cor é três vezes o tamanho do mapa de cores. O tamanho do mapa de cores é ajustado em zero para não enviar quaisquer dados de mapa de cores. Caso o tamanho do mapa de cores seja zero, então um valor de offset de mapa de cores é ainda enviado porém é ignorado pelo display. O campo offset de mapa de cores (2 bytes) especifica o offset dos dados de mapa de cores em tal pacote do inicio da tabela de mapa de cores no dispositivo de display.

Um campo CRC de parâmetro de 2 bytes contém uma CRC de todos os bytes do comprimento de pacote até o byte de codificação de áudio. Caso esta CRC falhe na conferência, então todo o pacote é descartado.

Para o campo dados de mapa de cores, cada local do mapa de cores é um valor de 3 bytes, em que o primeiro byte especifica a magnitude do azul, o segundo byte especifica a magnitude do verde e o terceiro especifica a magnitude do vermelho. O campo tamanho de mapa de cores especifica o número de itens da tabela de mapa de cores de 3 bytes que existe no campo dados de mapa de cores. Caso um único mapa de cores não se ajuste em um formato de dados de video e pacote de mapa de cores então todo o mapa de cores pode ser especificado pelo envio de múltiplos pacotes com diferentes dados de mapa de cores e offsets de mapa de cores em cada pacote.

Um campo CRC de mapa dados de cores de 2 bytes contém uma CRC apenas dos dados de mapa de cores. Caso tal CRC falhe na conferência, então os dados do mapa de cores podem ainda ser usados, porém a contagem de erros de CRC é incrementada. E. Para pacotes de encapsulamento de link reverso. O campo flags de link reverso (1 byte) contém um conjunto de flags para requisitar informações a partir do display. Caso um bit (no caso o bit 0) seja ajustado para um, então, o host requisita as informações especificadas a partir do display usando o pacote de capacidade de display. Caso o bit seja zero então o host não necessita das informações do display. Os bits restantes (no caso bits 1 a 7) ficam reservados para uso futuro e são ajustados para zero. O campo divisor de taxa reversa (1 byte) especifica o número de ciclos de MDDI_Stb que ocorrem em relação ao clock de dados de link reverso. O clock de dados de link reverso é igual ao clock de dados de link de emissão dividido por duas vezes o divisor de taxa reversa. A taxa de dados do link reverso está relacionada ao clock de dados de link reverso e ao tipo de interface no link reverso. Para uma interface tipo I a taxa de dados reversa é igual ao clock de dados de link reverso, para as interfaces tipo II, tipo III e tipo IV as taxas de dados reversos são iguais a duas vezes, quatro vezes e oito vezes o clock de dados de link reverso, respectivamente. O campo comprimento de inversão 1 (turn around) (1 byte) especifica o número total de bytes que são alocados para a inversão 1. O comprimento recomendado de inversão 1 é o número de bytes requerido para que os drivers MDDI_Data em um host tenham as saídas desabilitadas. Isto se baseia no tempo de desabilitação de saída acima descrito, na taxa de dados do link de emissão e na seleção de tipo de interface de link de emissão sendo usadas. Uma descrição mais completa do ajuste de inversão 1 foi apresentada acima. O campo comprimento de inversão 2 (1 byte) especifica o número total de bytes que são alocados para inversão (turn around). O comprimento recomendado de inversão 2 é o número de bytes requerido para que os drivers MDDI_Data no display desabilitem suas saídas mais o retardo de ida-e-volta. Uma descrição do ajuste de inversão 2 foi apresentada acima. O campo CRC de parâmetro (2 bytes) contém uma CRC de 16 bits de todos os bytes desde o comprimento do pacote até o comprimento da inversão. Caso esta CRC falhe na conferência então todo o pacote é descartado. O campo alinhamento ao estrobo (3 bytes) contém um valor tal que o sinal MDDI_Stb efetue uma transição de baixo a alto no limite de bits entre o último bit do campo todo de zeros e o primeiro bit do campo pacotes de dados reversos. Isto assegura que o sinal MDDI_Stb se comporte de uma maneira consistente com referência aos limites de byte no campo pacotes de dados reversos. O campo todo de zeros (1 byte) é ajustado como igual a zero e é usado para assegurar que todos os sinais MDDI_Data estejam no estado zero antes de desabilitar os drivers de linha durante o primeiro periodo de tempo de guarda. O campo inversão 1 é usado para estabelecer o primeiro periodo de inversão. O número de bytes especificado pelo parâmetro de comprimento de inversão é alocado por este campo para permitir que os drivers de linha MDDI_Data no host sejam desabilitados antes que os drivers de linha no cliente (display) sejam habilitados. O host desabilita seus drivers de linha MDDI_Data durante o bit 0 do inversão 1 e o cliente (display) habilita seus drivers de linha imediatamente após o último bit do inversão 1. O sinal MDDI_Stb se comporta como se o período de inversão fosse todo de zeros. O campo pacotes de dados reversos contém uma série de pacotes de dados sendo transferidos do cliente para um host. Como acima mencionado, pacotes de preenchimento são enviados para preencher o espaço restante que não é usado por outros tipos de pacotes. O campo inversão 2 é usado para estabelecer o segundo período de inversão. O número de bytes especificado pelo parâmetro de comprimento de inversão é alocado por este campo. O campo reabilitação de driver usa 1 byte que é igual a zero para assegurar que todos os sinais MDDI_Data sejam reabilitados antes do campo comprimento de pacote do próximo pacote. F. Para pacotes de capacidade de display. O campo versão de protocolo usa dois bytes para especificar uma versão de protocolo usada pelo cliente. A versão inicial é ajustada como igual a zero, enquanto que o campo versão de protocolo mínima usa 2 bytes para especificar a versão de protocolo mínima que o cliente pode empregar ou interpretar. O campo capacidade de taxa de dados de display (2 bytes) especifica a taxa de dados máxima que o display pode receber no link de emissão da interface e é especificado na forma de megabits por segundo (Mbps) . O campo capacidade de tipo de interface (1 byte) especifica os tipos de interface que são suportados nos links de emissão e reverso. Isto é atualmente indicado pela seleção do bit 0, bit 1, ou bit 2 para selecionar um modo do tipo II, tipo III, ou tipo IV no link de emissão, respectivamente, e o 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 ficando reservados e sendo ajustados para zero. Os campos largura e altura de bitmap (2 bytes) especificam a largura e altura do bitmap em pixels. O campo capacidade monocromática (1 byte) é usado para especificar o número de bits de resolução que podem ser apresentados em um formato monocromático. Caso um display não possa usar um formato monocromático então tal valor é ajustado para zero. Os bits 7 a 4 ficam reservados para uso futuro e, portanto, são ajustados para zero. Os bits 3 a 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. Caso o valor seja zero então o formato monocromático não é suportado pelo display. O campo capacidade de mapa de cor (3 bytes) especifica o número máximo de itens da tabela que existem na tabela de mapa de cores no display. Caso o display não possa usar o formato do mapa de cores, então este valor é zero. O campo capacidade RGB (2 bytes) especifica o número de bits de resolução que podem ser apresentados no formato RGB. Caso o display não possa usar o formato RGB então este valor é zero. A palavra de capacidade RGB é composta por três valores não-designados separados em que: os bits 3 a 0 definem o número máximo de bits de azul, os bits 7 a 4 definem o número máximo de bits de verde e os bits de 11 a 8 definem o número máximo de bits de vermelho em cada pixel. Atualmente, os bits 15 a 12 ficam reservados para uso futuro e são de um modo geral ajustados para zero. O campo capacidade Y Cr Cb (2 bytes) especifica o número de bits de resolução que podem ser apresentados no formato Y Cr Cb. Caso o display não possa usar o formato Y Cr Cb então este valor é zero. A palavra de capacidade Y Cr Cb é composta por três valores não-designados separados, em que: os bits 3 a 0 definem o número máximo de bits na amostra Cb, os bits 7 a 4 definem o número máximo de bits na amostra Cr, os bits 11 a 8 definem o número máximo de bits na amostra Y e os bits 15 a 12 estão atualmente reservados para uso futuro e são ajustados para zero. O campo indicadores de capacidade de recursos de display usa 4 bytes que contêm um conjunto de flags que indicam recursos específicos no display que são suportados. Um bit ajustado para um indica que a capacidade é suportada e um bit ajustado para zero indica que a capacidade não é suportada. O valor para o bit 0 indica se o pacote de transferência de bloco de bitmap (pacote tipo 71) é ou não suportado. O valor para os bits 1, 2 e 3, indica se o pacote de preenchimento de área de bitmap (pacote tipo 72), o pacote de preenchimento padrão de bitmap (pacote tipo 73) , ou o pacote de canal de dados de link de comunicação (pacote tipo 74), respectivamente, são ou não suportados. O valor para o bit 4 indica se o display possui ou não a capacidade de tornar uma cor transparente, enquanto que os valores para os bits 5 e 6 indicam se o display pode aceitar dados de vídeo ou dados de áudio em formato empacotado, respectivamente, e o valor para o bit 7 indica se o display pode enviar um fluxo de vídeo de link reverso a partir de uma câmera. O valor para os bits 11 e 12 indica quando o cliente está se comunicando ou com um dispositivo apontador e pode enviar e receber pacotes de dados de dispositivo apontador, ou com um teclado e pode enviar e receber pacotes de dados de teclado, respectivamente. Os bits 13 a 31 estão atualmente reservados para uso futuro ou designações alternativas úteis para os projetistas de sistema e são de um modo geral ajustado como iguais a zero. O campo capacidade de taxa de frame de vídeo de display (1 byte) especifica a capacidade máxima de atualização de frames de vídeo do display em frames por segundo. Um host pode escolher atualizar a imagem em uma taxa mais lenta que o valor especificado em tal campo. O campo profundidade de buffer de áudio (2 bytes) especifica a profundidade do buffer elástico em um display que está 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 ajustado para um indica que o canal é suportado e um bit ajustado para zero indica que tal canal não é suportado. As posições de bits são designadas para os diferentes canais de tal forma que as posições de bits 0, 1, 2, 3, 4, 5, 6e7 indicam respectivamente os canais frontal-esquerdo, frontal-direito, posterior-esquerdo, posterior-direito, central-frontal, sub-woofer, surround-esquerdo e surround-direito.

Os bits 8 a 15 estão atualmente reservados para uso futuro e são de um modo geral ajustados para zero.

Um campo capacidade de taxa de amostras de áudio de 2 bytes, para o link de emissão, contém um conjunto de flags para indicar a capacidade de taxa de amostras de áudio do dispositivo cliente. As posições de bits são designadas para as diferentes taxas, sendo os bits 0, 1, 2, 3, 4, 5, 6, 7 e 8 designados respectivamente para 8.000, 16.000, 24.000, 32.000, 40.000, 48.000, 11.025, 22.050 e 44.100 amostras por segundo (SPS) , com os bits 9 a 15 ficando reservados para uso futuro ou de taxas alternativas, conforme desejado, sendo portanto atualmente ajustados para "0". O ajuste de um valor de bit para um desses bits para "1" indica que aquela taxa de amostras específica é suportada, enquanto que o ajuste do bit para "0" indica que a taxa de amostras não é suportada. O campo taxa de subframes mínima (2 bytes) especifica a taxa de subframes mínima em frames por segundo. A taxa de subframes mínima mantém a taxa de atualização de estado de display suficiente para leitura de certos sensores ou dispositivos apontadores no display.

Um campo capacidade de taxa de amostras mic de 2 bytes, para o link reverso, contém um conjunto de flags que indicam a capacidade de taxa de amostras de áudio de um microfone no dispositivo cliente. Para os propósitos da MDDI, um microfone de dispositivo cliente é configurado para suportar no mínimo uma taxa de 8.000 amostras por segundo. As posições de bits para este campo são designadas para as diferentes taxas com as posições de bits 0, 1, 2, 3, 4, 5, 6, 7 e 8 usadas 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 os bits 9 a 15 ficando reservados para usos futuros ou de taxas alternativas, conforme desejado, sendo eles atualmente ajustados para "0' . Ajustar um valor de bit de um destes bits para "1" indica que aquela taxa de amostras específica é suportada, enquanto que o ajuste do bit para "0" indica que a taxa de amostras não é suportada. Caso nenhum microfone seja conectado então cada um dentre os bits de capacidade de taxa de amostras mic é ajustado como zero. O campo tipo de proteção ao conteúdo (2 bytes) contém um conjunto de flags que indicam o tipo de proteção ao conteúdo digital que é suportado pelo display. Atualmente, a posição do bit 0 é usada para indicar quando a DTCP é suportada, e a posição de bit 1 é usada para indicar quando HDCP é suportada com as posições de bits 2 a 15 ficando reservadas para uso com outros esquemas de proteção conforme desejado ou disponível, de forma que eles são atualmente ajustados para zero. <3. Para Pacotes de requisição e estado de display . O campo requisição de link reverso (3 bytes) especifica o número de bytes que o display necessita no link reverso no próximo subframe para enviar informações para o host. O campo contagem de erros de CRC (1 byte) indica quantos erros de CRC ocorreram desde o início do frame de mídia. A contagem de CRC é resetada quando um pacote de cabeçalho de subframe com uma contagem de subframes de zero é enviado. Caso o número real de erros de CRC supere 2 55 este valor se satura em 255.

O campo mudança de capacidade usa 1 byte para indicar uma mudança na capacidade do display. Isto podería ocorrer caso um usuário conecte um dispositivo periférico tal como um microfone, teclado, ou display, ou por alguma outra razão. Quando os bits [7:0] são iguais a 0, então a capacidade não mudou desde que o último pacote de capacidade de display foi enviado. No entanto, quando os bits [7:0] forem iguais de 1 a 255, a capacidade mudou. O pacote de capacidade de display é examinado para determinar as novas características do display. H. Para pacotes de transferência de blocos de bits.

Os campos valor X e valor Y de coordenada esquerda superior da janela usam 2 bytes cada um para especificar o valor X e Y das coordenadas do canto superior esquerdo da janela a ser movida. Os campos largura e altura de janela usam 2 bytes cada um para especificar a largura e altura de janela a ser movida. Os campos movimento X e movimento Y da janela usam 2 bytes cada um para especificar o número de pixels que a janela deve ser movida horizontal e verticalmente, respectivamente. Valores positivos para X levam a janela a ser movida para a direita e valores negativos levam o movimento para a esquerda, enquanto que valores positivos para Y levam a janela a ser movida para baixo e valores negativos levam o movimento para cima. I. Para pacotes de preenchimento de ãrea de bitmap.

Os campos valor X e valor Y de coordenada esquerda superior da janela usam 2 bytes cada um para especificar o valor X e Y das coordenadas do canto superior esquerdo da janela a ser preenchida. Os campos largura e altura de janela (2 bytes cada um) especificam a largura e altura de janela a ser preenchida. O campo descritor de formato de dados de vídeo (2 bytes) especifica o formato do valor de preenchimento de área de pixels. O formato é o mesmo que o mesmo campo no pacote de fluxo de vídeo. 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 acima descritos. O formato de tal pixel está especificado no campo descritor de formato de dados de vídeo. J. Para pacotes de preenchimento padrão de bitmap.

Os campos valor X e valor Y de coordenada superior esquerda da janela usam 2 bytes cada um para especificar o valor X e Y das coordenadas do canto superior esquerdo da janela a ser preenchida. Os campos largura e altura de janela (2 bytes cada um) especificam a largura e altura de janela a ser preenchida. Os campos largura padrão e altura padrão (2 bytes cada um) especificam a largura e a altura, respectivamente, do padrão de preenchimento. 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 é o mesmo que o mesmo campo no pacote de fluxo de vídeo. O campo CRC de parâmetro (2 bytes) contém uma CRC de todos os bytes a partir do comprimento de pacote até o descritor de formato de vídeo. Caso esta CRC falhe na conferência, então todo o pacote é descartado. O campo dados de pixels padrão contém informações de vídeo não processadas 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 fila deve estar alinhado em bytes. Os dados de padrão de preenchimento são transmitidos em uma fila de cada vez. O campo CRC de dados de pixels padrão (2 bytes) contém uma CRC somente dos dados de pixels padrão. Caso esta CRC falhe na conferência, então os dados de pixel padrão podem ainda ser usados mas a contagem de erros de CRC deve ser incrementada. K. Pacotes de canal de dados de link de comunicação. O campo CRC de parâmetro (2 bytes) contém uma CRC de 16 bits de todos os bytes do comprimento de pacote até o tipo de pacote. Caso esta CRC falhe na conferência, então todo o pacote é descartado. O campo dados de link de comunicação contém os dados não processados provenientes do canal de comunicação. Tais dados são simplesmente passados para o dispositivo de computação no display. O campo CRC de dados de link de comunicação (2 bytes) contém uma CRC de 16 bits somente dos dados do link de comunicação. Caso esta CRC falhe na conferência, então os dados do link de comunicação são ainda usados ou úteis, mas a contagem de erros de CRC deve ser incrementada. L. Para pacotes de requisição de transferência de tipo de interface. O campo tipo de interface (1 byte) especifica o novo tipo de interface a ser usado. O valor neste campo especifica o tipo de interface da seguinte maneira. Caso o valor no bit 7 seja igual a 0 a requisição de transferência de tipo é para o link de emissão, se ele for igual a 1, então a requisição de transferência de tipo é para o link reverso. Os bits 6 a 3 ficam reservados para uso futuro e são de um modo geral ajustados para zero. Os bits 2 a 0 são usados para definir o tipo de interface a ser usado, com um valor de 1 significando uma transferência para o modo tipo I, o valor de 2 uma transferência para o modo tipo II, um valor de 3 uma transferência para o modo tipo III e um valor de 4 uma transferência para o modo tipo IV. Os valores de 0 e 5 a 7 ficam reservados para designação futura de modos alternativos ou combinações de modos. M. Para pacotes de confirmação de tipo de interface. O campo tipo de interface (1 byte) possui um valor que confirma o novo tipo de interface a ser usado. O valor neste campo especifica o tipo de interface da seguinte maneira. Caso o valor no bit 7 seja igual a 0 a requisição de transferência de tipo é para o link de emissão, alternativamente, se ele for igual a 1, a requisição de transferência de tipo é para o link reverso.

As posições de bits 6 a 3 ficam atualmente reservadas para uso na designação de outros tipos de transferência, conforme desejado, e são de um modo geral ajustados para zero. No entanto, as posições de bits 2 a 0 são usadas para definir o tipo de interface a ser usado, com um valor de 0 indicando uma confirmação negativa, ou que a transferência requisitada não pode ser efetuada, os valores de 1, 2, 3 e 4 indicando transferências para os modos tipo I, tipo II, tipo III e tipo IV, respectivamente. Os valores de 5 a 7 ficam reservados para uso futuro com designações alternativas de modos conforme desejado. N. Para pacotes de transferência de tipo de desempenho. O campo tipo de interface de 1 byte indica o novo tipo de interface a ser usado. O valor presente neste campo especifica o tipo de interface usando primeiramente o valor do bit 7 para determinar se a transferência de tipo é ou não para os links de emissão e reverso. Um valor de "0" indica que a requisição de transferência de tipo é para o link de emissão e um valor de "1" para o link reverso. Os bits 6 a 3 ficam reservados para uso futuro, sendo assim são de um modo geral ajustados para um valor de zero. No entanto, os bits de 2 a 0 são usados para definir o tipo de interface a ser usado, os valores de 1, 2, 3 e 4 indicando transferências para os modos tipo I, tipo II, tipo III e tipo IV, respectivamente. O uso de valores de 5 a 7 para estes bits fica reservado para o futuro. O. Para pacotes de habilitação de canal de áudio de emissão. O campo máscara de habilitação de canal de áudio (1 byte) contém um grupo de flags que indicam quais canais de áudio devem ser habilitados em um cliente. Um bit ajustado para um habilita o canal correspondente e um bit ajustado para zero desabilita o canal correspondente. Os bits 0 a 5 designam os canais 0 a 5 que designam os canais frontal-esquerdo, frontal-direito, posterior-esquerdo, posterior-direito, central-frontal e sub-woofer, respectivamente. Os bits 6 e 7 estão reservados para uso futuro e por enquanto são ajustados para zero. P. Para pacotes de taxa de amostras de áudio reverso· O campo taxa de amostras de áudio (1 byte) especifica a taxa de amostras de áudio digital. Os valores para este campo são designados para as diferentes taxas com valores de 0, 1, 2, 3, 4, 5, 6, 7 e 8 sendo usados 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 os valores de 9 a 254 ficando reservados para uso com taxas alternativas, conforme desejado, sendo portanto atualmente ajustados para "0". Um valor de 255 é usado para desabilitar o fluxo de áudio de link reverso. O campo formato de amostras (1 byte) especifica o formato das amostras de áudio digital. Quando os bits [1:0] forem iguais a 0, as amostras de áudio digital estão em formato linear, quando eles são iguais a 1, as amostras de áudio digital estão em formato Lei-μ e quando eles são iguais a 2, as amostras de áudio digital estão em formato Lei-A. Os bits [2:7] ficam reservados para uso alternativo na designação de formatos de áudio, conforme desejado e são de um modo geral ajustados como iguais a zero. Q. Para os pacotes de overhead de proteção ao conteúdo digital. O campo tipo de proteção ao conteúdo (1 byte) especifica o método de proteção ao conteúdo digital que é usado. Um valor de 0 indica proteção ao conteúdo de transmissão digital (DTCP), enquanto que um valor de 1 indica um sistema de proteção ao conteúdo digital de alta largura de banda (HDCP). A faixa de valores de 2 a 255 não está especificada no momento porém está reservada para uso com esquemas de proteção alternativos conforme desejado. O campo mensagens de overhead de proteção ao conteúdo é um campo de comprimento variável contendo mensagens de proteção enviadas entre o host e o cliente. R. Para os pacotes de habilitação de cor transparente. 0 campo habilitação de cor transparente (1 byte) especifica quando o modo de cor transparente está habilitado ou desabilitado. Caso o bit 0 seja igual a 0 então o modo de cor transparente está desabilitado, se for igual alo modo de cor transparente está habilitado e a cor transparente é especificada pelos dois parâmetros seguintes. Os bits 1 a 7 deste byte estão reservados para uso futuro e são ajustados para zero. 0 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 é de um modo geral o mesmo que o mesmo campo no pacote de fluxo de vídeo. O campo valor de preenchimento de área de pixels usa 4 bytes alocados para o valor de pixels a ser preenchido na janela especificada acima. O formato deste pixel está especificado no campo descritor de formato de dados de vídeo. S. Para os pacotes de medição de retardo de ida- e-volta. O campo CRC de parâmetro (2 bytes) contém uma CRC de 16 bits de todos os bytes do comprimento de pacote até o tipo de pacote. Caso esta CRC falhe na conferência, então todo o pacote é descartado. O campo alinhamento ao estrobo (2 bytes) contém um valor tal que o sinal MDDI_Stb efetua uma transição de baixo para alto no limite de bits imediatamente antes do primeiro bit do campo todo de zeros deste pacote. Isto assegura que o sinal MDDI_Stb se comporte de uma maneira consistente com referência aos limites de byte no período de medição a qualquer momento que este pacote seja enviado. O campo todo de zeros (1 byte) contém zeros para assegurar que todos os sinais MDDI_Data estão no estado zero antes de desabilitar os drivers de linha durante o primeiro período de tempo de guarda. O campo tempo de guarda 1 (8 bytes) é usado para permitir que os drivers de linha MDDI_Data no host sejam desabilitados antes que os drivers de linha no cliente (display) sejam habilitados. O host desabilita seus drivers de linha MDDI_Data durante o bit 0 do 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 usada para permitir que o display responda com uma Oxff, Oxff, 0x0, em metade da taxa de dados usada no link de emissão. Tal taxa corresponde a um divisor de taxa de link reverso de 1. O display retorna tal resposta imediatamente no início do período de medição. Tal resposta será recebida em um host precisamente no retardo de ida-e-volta do link após o início do primeiro bit do período de medição no host. Os drivers de linha MDDI_Data no display são desabilitados imediatamente antes e imediatamente após a resposta Oxff, Oxff, 0x0, proveniente do display. O valor no campo tempo de guarda 2 (8 bytes) permite que os drivers de linha MDDI_Data do cliente sejam desabilitados antes que os drivers de linha no host sejam habilitados. O tempo de guarda 2 está sempre presente, porém só é requerido quando o retardo de ida-e-volta está na quantidade máxima que pode ser medida no período de medição. O cliente desabilita seus drivers de linha durante o bit 0 do tempo de guarda 2 e o host habilita seus drivers de linha imediatamente após o último bit do tempo de guarda 2 . O campo reabilitação de driver (1 byte) é ajustado como igual a zero para assegurar que todos os sinais MDDI_Data sejam reabilitados antes do campo comprimento de pacote no próximo pacote. XV. Conclusão.

Apesar de várias modalidades da presente invenção terem sido acima descritas, deve ficar claro que elas são apresentadas apenas como exemplo e não limitação. Dessa forma, a amplitude e escopo da presente invenção não devem ser limitados por quaisquer das modalidades exemplares acima descritas, devendo ser definidos somente de acordo com as reivindicações que se seguem e seus equivalentes.

REIVINDICAÇÕES

Claims (106)

1. Interface de dados digitais para a transferência de dados digitais de apresentação em uma alta taxa entre um dispositivo host (202) e um dispositivo cliente (204) através de um link de comunicação (406), a interface é CARACTERIZADA pelo fato de que compreende: uma pluralidade de estruturas de pacote ligadas entre si para formar um protocolo de comunicação para comunicação de um conjunto pré-selecionado de dados digitais de controle e apresentação entre um host (202) e um cliente (204) através do link de comunicação (406); e pelo menos um controlador de link (402, 404, 502, 504) residente no dispositivo host (202) acoplado ao cliente (204) através do link de comunicação (406), sendo configurado para gerar, transmitir e receber pacotes formando o protocolo de comunicação, e para formar dados digitais de apresentação em um ou mais tipos de pacotes de dados.

2. Interface, de acordo com a reivindicação 1, CARACTERI ΖΑΡΑ pelo fato de que compreende também o agrupamento dos pacotes dentro de frames de midia que são comunicados entre o host (202) e o cliente (204), possuindo um comprimento fixo predefinido com um número predeterminado dos pacotes possuindo comprimentos diferentes e variáveis.

3. Interface, de acordo com a reivindicação 1, CARACTERIZADA pelo fato de que compreende também um pacote de cabeçalho de subframe posicionado no inicio das transferências de pacotes a partir do host (202).

4. Interface, de acordo com a reivindicação 1, CARACTERI ZADA pelo fato de que compreende também a transferência bidirecional de informações entre o host (202) e o cliente (204) através do link de comunicação (406).

5. Interface, de acordo com a reivindicação 1, CARACTERIZADA pelo fato de que o controlador de link (402, 404, 502, 504) é um controlador de link de host (402, 502), e compreendendo também pelo menos um controlador de link de cliente (404, 504) residente no dispositivo cliente (204) acoplado ao host (202) através do link de comunicação (406), sendo configurado para gerar, transmitir e receber pacotes formando o protocolo de comunicação, e para formar dados digitais de apresentação em um ou mais tipos de pacotes de dados.

6. Interface, de acordo com a reivindicação 5, CARACTERI ZADA pelo fato de que o controlador de link de host (402, 502) compreende um ou mais drivers de linha diferencial (4108, 4110); e o controlador de link de cliente (404, 504) compreende um ou mais receptores de linha diferencial (4122, 4124) acoplados ao link de comunicação (406).

7. Interface, de acordo com a reivindicação 1, CARACTERIZADA pelo fato de que compreende também um ou mais pacotes de fluxo de video para dados tipo video e pacotes de fluxo de áudio para dados tipo áudio para a transferência de dados a partir do host (202) para o cliente (204) através de um link de emissão para apresentação a um usuário cliente.

8. Interface, de acordo com a reivindicação 1, CARACTERIZADA pelo fato de que compreende também um ou mais pacotes de encapsulamento de link reverso para que o cliente (204) transfira dados para o host (202) .

9. Interface, de acordo com a reivindicação 1, CARACTERI ZADA pelo fato de que o controlador de link de host (402, 502) requisita informações sobre capacidades de display a partir do dispositivo cliente (204) de forma a determinar qual tipo de dados e taxas de dados que o dispositivo cliente (204) é capaz de acomodar através da interface.

10. Interface, de acordo com a reivindicação 9, CARACTERIZADA pelo fato de que um controlador de link de cliente (404, 504) comunica capacidades de display ou apresentação ao controlador de link de host (402, 502) usando pelo menos um pacote de capacidade de display.

11. Interface, de acordo com a reivindicação 1, CARACTERI ZADA pelo fato de que o link de comunicação (40 6) compreende um cabo possuindo uma série de quatro ou mais condutores e uma cobertura.

12. Interface, de acordo com a reivindicação 1, CARACTERI ZADA pelo fato de que os controladores de link de host (402, 502) compreendem uma interface de dados USB operando como uma parte do link de comunicação (406).

13. Interface, de acordo com a reivindicação 1, CARACTERI ZADA pelo fato de que o dispositivo host (202) compreende um dispositivo de comunicação sem fio (102) .

14. Interface, de acordo com a reivindicação 1, CARACTERI ZADA pelo fato de que o dispositivo host (202) compreende um computador portátil (100) possuindo um modem sem fio nele disposto.

15. Interface, de acordo com a reivindicação 1, CARACTERI ZADA pelo fato de que o dispositivo cliente (204) compreende um display de video portátil (104, 106) .

16. Interface, de acordo com a reivindicação 14, CARACTERI ZADA pelo fato de que o display de video portátil (104, 106) compreende um dispositivo de micro-display.

17. Interface, de acordo com a reivindicação 1, CARACTERI ZADA pelo fato de que o dispositivo cliente (204) compreende um sistema de apresentação de áudio portátil.

18. Interface, de acordo com a reivindicação 1, CARACTERIZADA pelo fato de que o host (202) compreende dispositivo para armazenar dados multimídia para serem transferidos para o dispositivo cliente (204) .

19. Interface, de acordo com a reivindicação 1, CARACTERIZADA pelo fato de que os pacotes compreendem, cada um, um campo comprimento de pacote, um ou mais campos dados de pacote e um campo verificação por redundância cíclica.

20. Interface, de acordo com a reivindicação 2, CARACTERIZADA pelo fato de que compreende também: uma pluralidade de modos de transferência, cada um permitindo a transferência de diferentes números máximos de bits de dados em paralelo durante um dado período de tempo, com cada modo sendo selecionável por negociação entre os drivers de link de host e cliente; e em que os modos de transferência podem ser dinamicamente ajustados entre os modos durante a transferência de dados.

21. Interface, de acordo com a reivindicação 1, CARACTERI ZADA pelo fato de que compreende também uma pluralidade de pacotes que podem ser usados para a transferência de informações de vídeo escolhidos a partir do grupo de pacotes do tipo mapa de cores, transferência de blocos de bits, preenchimento de área de bitmap, preenchimento padrão de bitmap e habilitação de cor transparente.

22. Interface, de acordo com a reivindicação 1, CARACTERIZADA pelo fato de que compreende também pacotes do tipo preenchimento gerados pelo host (202) para ocupar períodos de transmissão do link de emissão que não possuem dados.

23. Interface, de acordo com a reivindicação 1, CARACTERIZADA pelo fato de que compreende também pacotes do tipo fluxo definido pelo usuário para a transferência de dados definidos por interface - usuário.

24. Interface, de acordo com a reivindicação 1, CARACTERIZADA pelo fato de que compreende também pacotes do tipo dados de teclado e dados de dispositivo apontador para transferência de dados de ou para dispositivos de entrada de usuário associados ao dispositivo cliente (204) .

25. Interface, de acordo com a reivindicação 1, CARACTERI ZADA pelo fato de que compreende também um pacote do tipo desativação de link para transmissão pelo host (202) para o cliente (204) para terminar a transferência de dados em qualquer das direções através do link de comunicação (406).

26. Método para a transferência de dados digitais em uma alta taxa entre um dispositivo host (202) e um dispositivo cliente (204) através de um link de comunicação (406) para apresentação a um usuário, o método é CARACTERIZADO pelo fato de que compreende: gerar uma ou mais dentre uma pluralidade de estruturas de pacotes predefinidas e ligá-las umas às outras para formar um protocolo de comunicação predefinido; comunicar um conjunto pré-selecionado de dados digitais de controle e apresentação entre os dispositivos host (202) e cliente (204) através do link de comunicação (406) usando o protocolo de comunicação; acoplar pelo menos um controlador de link de host (402, 502) residente no dispositivo host ao dispositivo cliente (204) através do link de comunicação (406), o controlador de link de host (402, 502) sendo configurado para gerar, transmitir e receber pacotes que formam o protocolo de comunicação, e para formar dados digitais de apresentação em um ou mais tipos de pacotes de dados; e transferir dados na forma de pacotes através do link de comunicação (406) usando os controladores de link.

27. Método, de acordo com a reivindicação 26, CARACTERIZADO pelo fato de que compreende também o agrupamento dos pacotes dentro de frames de midia para comunicação entre o host (202) e o cliente (204), os frames de midia possuindo um comprimento fixo predefinido com um número predeterminado dos pacotes possuindo comprimentos diferentes e variáveis.

28. Método, de acordo com a reivindicação 26, CARACTERI ZADO pelo fato de que compreende também iniciar a transferência de pacotes a partir do host (202) com um pacote do tipo cabeçalho de subframe.

29. Método, de acordo com a reivindicação 26, CARACTERI ZADO pelo fato de que compreende também a transferência bidirecional de informações entre o host (202) e o cliente (204) através do link de comunicação (406).

30. Método, de acordo com a reivindicação 26, CARACTERIZADO pelo fato de que compreende também pelo menos um controlador de link de cliente (404, 504) residente no dispositivo cliente (204) acoplado ao dispositivo host (202) através do link de comunicação (406), sendo configurado para gerar, transmitir e receber pacotes formando o protocolo de comunicação, e para formar dados digitais de apresentação em um ou mais tipos de pacotes de dados.

31. Método, de acordo com a reivindicação 30, CARACTERI ZADO pelo fato de que o controlador de link de host (402, 502) compreende um ou mais drivers de linha diferencial (4108, 4110); e o controlador de link de cliente (404, 504) compreende um ou mais receptores de linha diferencial (4122, 4124) acoplados ao link de comunicação (406).

32. Método, de acordo com a reivindicação 26, CARACTERIZADO pelo fato de que compreende também a transferência de dados a partir do host (202) para o cliente (204) para apresentação a um usuário cliente usando um ou mais pacotes do tipo fluxo de video para dados tipo video e pacotes do tipo fluxo de áudio para dados tipo áudio.

33. Método, de acordo com a reivindicação 26, CARACTERI ZADO pelo fato de que compreende também a transferência de dados a partir do cliente (204) para o host (202) usando um ou mais pacotes do tipo encapsulamento de link reverso.

34. Método, de acordo com a reivindicação 26, CARACTERI ZADO pelo fato de que compreende também a requisição de informações sobre capacidades de display a partir do cliente por um controlador de link de host (402, 502) de forma a determinar qual tipo de dados e taxas de dados o cliente é capaz de acomodar através da interface.

35. Método, de acordo com a reivindicação 34, CARACTERI ZADO pelo fato de que compreende também a comunicação de capacidades de display ou apresentação a partir de um controlador de link de cliente (404, 504) para o controlador de link de host (402, 502) usando pelo menos um pacote do tipo capacidade de display.

36. Método, de acordo com a reivindicação 26, CARACTERI ZADO pelo fato de que o link de comunicação (40 6) compreende um cabo possuindo uma série de quatro ou mais condutores e uma cobertura.

37. Método, de acordo com a reivindicação 26, CARACTERIZADO pelo fato de que compreende também a operação de uma interface de dados USB por cada um dos controladores de link como uma parte do link de comunicação (406).

38. Método, de acordo com a reivindicação 26, CARACTERIZADO pelo fato de que o host (202) compreende um dispositivo de comunicação sem fio (102) .

39. Método, de acordo com a reivindicação 26, CARACTERI ZADO pelo fato de que o host (202) compreende um computador portátil (100) possuindo um modem sem fio nele disposto.

40. Método, de acordo com a reivindicação 26, CARACTERI ZADO pelo fato de que o dispositivo cliente (204) compreende um display de video portátil (104, 106) .

41. Método, de acordo com a reivindicação 40, CARACTERI ZADO pelo fato de que o display de video portátil (104, 106) compreende um dispositivo de micro-display.

42. Método, de acordo com a reivindicação 26, CARACTERI ZADO pelo fato de que o dispositivo cliente (204) compreende um sistema de apresentação de áudio portátil.

43. Método, de acordo com a reivindicação 26, CARACTERIZADO pelo fato de que compreende também armazenar dados multimídia a serem transferidos para o dispositivo cliente (204) no host (202) .

44. Método, de acordo com a reivindicação 26, CARACTERI ZADO pelo fato de que cada um dos pacotes compreende um campo comprimento de pacote, um ou mais campos dados de pacote e um campo verificação por redundância cíclica.

45. Método, de acordo com a reivindicação 27, CARACTERIZADO pelo fato de que compreende também: negociar entre os drivers de link de host e de cliente o uso de um dentre uma pluralidade de modos de transferência em cada direção, cada um permitindo a transferência de diferentes números máximos de bits de dados em paralelo durante um dado período de tempo; e ajustar, dinamicamente, entre os modos de transferência durante a transferência de dados.

46. Método, de acordo com a reivindicação 26, CARACTERIZADO pelo fato de que compreende também o uso de um ou mais dentre uma pluralidade de pacotes para a transferência de informações de vídeo escolhidos a partir do grupo de pacotes do tipo de mapa de cores, transferência de blocos de bits, preenchimento de área de bitmap, preenchimento padrão de bitmap e habilitação de cor transparente.

47. Método, de acordo com a reivindicação 26, CARACTERI ZADO pelo fato de que compreende também a geração de pacotes do tipo preenchimento pelo host (202) para ocupar períodos de transmissão do link de emissão que não possuem dados.

48. Método, de acordo com a reivindicação 26, CARACTERI ZADO pelo fato de que compreende também a transferência de dados definidos por interface - usuário pelo uso de pacotes do tipo fluxo definidos pelo usuário.

49. Método, de acordo com a reivindicação 26, CARACTERI ZADO pelo fato de que compreende também a transferência de dados de e para dispositivos de entrada de usuário associados ao dispositivo cliente (204) usando pacotes do tipo dados de teclado e dados de dispositivo apontador.

50. Método, de acordo com a reivindicação 26, CARACTERIZADO pelo fato de que compreende também terminar a transferência de dados em qualquer das direções através do link de comunicação (406) usando um pacote do tipo desativação de link para transmissão pelo host (202) para o cliente (204) .

51. Equipamento para a transferência de dados digitais em uma alta taxa entre um dispositivo host (202) e um dispositivo cliente (204) através de um link de comunicação (406) para apresentação a um usuário, o equipamento é CARACTERIZADO pelo fato de que compreende: pelo menos um controlador de link de host (402, 502) disposto no dispositivo host (202) para gerar uma ou mais dentre uma pluralidade de estruturas de pacote predefinidas e liga-las umas às outras para formar um protocolo de comunicação predefinido, e para comunicar um conjunto pré-selecionado de dados digitais de controle e apresentação entre os dispositivos host (202) e cliente (204) através do link de comunicação (406) usando o protocolo de comunicação; pelo menos um controlador de cliente disposto no dispositivo cliente (204) e acoplado ao controlador de link de host (402, 502) através do link de comunicação (406); e cada controlador de link sendo configurado para gerar, transmitir e receber pacotes formando o protocolo de comunicação, e para formar dados digitais de apresentação em um ou mais tipos de pacotes de dados.

52. Equipamento, de acordo com a reivindicação 51, CARACTERI ZADO pelo fato de que o controlador de host compreende uma máquina de estado.

53. Equipamento, de acordo com a reivindicação 51, CARACTERI ZADO pelo fato de que o controlador de host compreende um processador de sinal de uso geral.

54. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que os pacotes são agrupados dentro de frames de midia para comunicação entre o host (202) e o cliente (204), os frames de midia possuindo um comprimento fixo predefinido com um número predeterminado dos pacotes possuindo comprimentos diferentes e variáveis.

55. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que compreende também um pacote do tipo cabeçalho de subframe no inicio da transferência de pacotes a partir do host (202) .

56. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que os controladores de link estão configurados para transferir de forma bidirecional informações entre os dispositivos host (202) e cliente (204) através do link de comunicação (406).

57. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que o controlador de cliente compreende um receptor de cliente acoplado ao dispositivo cliente (204) .

58. Equipamento, de acordo com a reivindicação 57, CARACTERI ZADO pelo fato de que o controlador de host compreende um ou mais drivers de linha diferencial (4108, 4110) ; e o receptor de cliente compreende um ou mais receptores de linha diferencial (4122, 4124) acoplados ao link de comunicação (406).

59. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que compreende também pacotes do tipo fluxo de video para dados tipo video e pacotes do tipo fluxo de áudio para o tipo de áudio quando da transferência de dados a partir do host (202) para o cliente (204) para apresentação a um usuário cliente.

60. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que compreende também um ou mais pacotes do tipo encapsulamento de link reverso para a transferência de dados a partir do cliente (204) para o host (202) .

61. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que o controlador de link de host (402, 502) está configurado para requerer informações de capacidades de display a partir do cliente (204) de forma a determinar qual tipo de dados e taxas de dados o cliente (204) é capaz de acomodar através da interface.

62. Equipamento, de acordo com a reivindicação 61, CARACTERIZADO pelo fato de que compreende também pelo menos um pacote do tipo capacidade de display para comunicar as capacidades de display ou apresentação a partir de um controlador de link de cliente (404, 504) para o controlador de link de host (402, 502).

63. Equipamento, de acordo com a reivindicação 51, CARACTERI ZADO pelo fato de que o link de comunicação (406) compreende um cabo possuindo uma série de quatro ou mais condutores e uma cobertura.

64. Equipamento, de acordo com a reivindicação 63, CARACTERI ZADO pelo fato de que o cabo compreende seis condutores e uma cobertura.

65. Equipamento, de acordo com a reivindicação 63, CARACTERI ZADO pelo fato de que o cabo compreende oito condutores e uma cobertura.

66. Equipamento, de acordo com a reivindicação 63, CARACTERI ZADO pelo fato de que o link de comunicação (406) compreende um cabo contendo quatro condutores, uma interface tipo USB e uma cobertura.

67. Equipamento, de acordo com a reivindicação 63, CARACTERI ZADO pelo fato de que cada um dos condutores de cabo compreende um fio de múltiplos filamentos com uma resistência em torno de 361 ohms por quilômetro de comprimento (110 ohms/1000 pés), uma velocidade de propaqação de sinal em torno de 0,66c, um retardo máximo através do cabo menor que cerca de 8,0 nanossequndos, e uma cobertura.

68. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que o dispositivo host (202) compreende um dispositivo de comunicação sem fio (102) .

69. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que o dispositivo host (202) compreende um computador portátil (100) possuindo um modem sem fio nele disposto.

70. Equipamento, de acordo com a reivindicação 51, CARACTERI Z ADO pelo fato de que o dispositivo cliente (204) compreende um display de video portátil (104, 106) .

71. Equipamento, de acordo com a reivindicação 70, CARACTERI ZADO pelo fato de que o display de video portátil (104, 106) compreende um dispositivo de micro- display.

72. Equipamento, de acordo com a reivindicação 51, CARACTERI ZADO pelo fato de que o dispositivo cliente (204) compreende um sistema de apresentação de áudio portátil.

73. Equipamento, de acordo com a reivindicação 51, CARACTERI ZADO pelo fato de que compreende também o armazenamento de dados para conter dados multimídia a serem transferidos para o dispositivo cliente (204) pelo host (202) .

74. Equipamento, de acordo com a reivindicação 51, CARACTERI ZADO pelo fato de que cada um dos pacotes compreende um campo comprimento de pacote, um ou mais campos dados em pacote e um campo verificação por redundância cíclica.

75. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que os controladores de link de host (402, 502) e de cliente (404, 504) são configurados para usar um dentre uma pluralidade de modos de transferência em cada direção, cada um permitindo a transferência de diferentes números máximos de bits de dados em paralelo durante um dado período de tempo, e sendo capazes de ser dinamicamente ajustados entre os modos de transferência durante a transferência de dados.

76. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que compreende também um ou mais dentre uma pluralidade de pacotes para a transferência de informações de vídeo sendo escolhidos a partir do grupo de pacotes do tipo mapa de cores, transferência de blocos de bits, preenchimento de área de bitmap, preenchimento padrão de bitmap e habilitação de cor transparente.

77. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que compreende também pacotes do tipo preenchimento para transferência pelo host (202) para ocupar períodos de transmissão do link de emissão que não possuem dados.

78. Equipamento, de acordo com a reivindicação 51, CARACTERIZADO pelo fato de que compreende também pacotes do tipo dados de teclado e dados de dispositivo apontador para transferência de dados de ou para dispositivos de entrada de usuário associados ao dispositivo cliente (204).

79. Equipamento, de acordo com a reivindicação 51, CARACTERI ZADO pelo fato de que o controlador de host está configurado para transmitir um pacote do tipo desativação de link para os dispositivos de cliente (204) para terminar a transferência de dados em qualquer direção através do link de comunicação (406).

80. Equipamento para a transferência de dados digitais em uma alta taxa entre um dispositivo host (202) e um dispositivo cliente (204) através de um link de comunicação (406) para apresentação a um usuário, o equipamento é CARACTERIZADO pelo fato de que compreende: dispositivo para gerar uma ou mais dentre uma pluralidade de estruturas de pacotes predefinidas e ligá-las umas às outras para formar um protocolo de comunicação predefinido; dispositivo para comunicar um conjunto pré-selecionado de dados digitais de controle e apresentação entre os dispositivos host (202) e cliente (204) através do link de comunicação (406) usando o protocolo de comunicação; dispositivo para acoplar pelo menos dois controladores de link (402, 404, 502, 504) através do link de comunicação (406), um em cada um dentre o host (202) e o cliente (204), e cada um sendo configurado para gerar, transmitir e receber pacotes que formam o protocolo de comunicação, e para formar dados digitais de apresentação em um ou mais tipos de pacotes de dados; e dispositivo para transferir dados na forma de pacotes através do link de comunicação (406) usando os controladores de link (402, 404, 502, 504).

81. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que compreende também dispositivo para agrupar os pacotes dentro de frames de midia para comunicação entre o host e o cliente, os frames de midia possuindo um comprimento fixo predefinido com um número predeterminado dos pacotes possuindo comprimentos diferentes e variáveis.

82. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que compreende também dispositivo para iniciar a transferência de pacotes a partir do host (202) com um pacote do tipo cabeçalho de subframe.

83. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que compreende também dispositivo para transferir, de forma bidirecional, informações entre o host (202) e o cliente (204) através do link de comunicação (406).

84. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que um controlador de link compreende um controlador de link de host (402, 502) acoplado ao dispositivo host (202), e o segundo controlador de link compreende um receptor de cliente acoplado ao dispositivo cliente (204) .

85. Equipamento, de acordo com a reivindicação 84, CARACTERIZADO pelo fato de que o controlador de link de host (402, 502) compreende um ou mais drivers de linha diferencial (4108, 4110) e o receptor de cliente compreende um ou mais receptores de linha diferencial (4122, 4124) acoplados ao link de comunicação (406).

86. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que compreende também dispositivo para transferir dados a partir do host (202) para o cliente (204) para apresentação a um usuário cliente usando um ou mais pacotes do tipo fluxo de video para dados tipo video, e pacotes do tipo fluxo de áudio para dados tipo áudio.

87. Equipamento, de acordo com a reivindicação 80, CARACTERI ZADO pelo fato de que compreende também dispositivo para transferir dados a partir do cliente (204) para o host (202) usando um ou mais pacotes do tipo encapsulamento de link reverso.

88. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que compreende também dispositivo para requisitar informações de capacidades de display a partir do cliente (204) por um controlador de link de host (402, 502) de forma a determinar quais tipos de dados e taxas de dados que o cliente (204) é capaz de acomodar através da interface.

89. Equipamento, de acordo com a reivindicação 88, CARACTERIZADO pelo fato de que compreende também dispositivo para comunicar capacidades de display ou apresentação a partir de um controlador de link de cliente (404, 504) para o controlador de link de host (402, 502) usando pelo menos um pacote do tipo capacidade de display.

90. Equipamento, de acordo com a reivindicação 80, CARACTERI ZADO pelo fato de que o link de comunicação (406) compreende um cabo possuindo uma série de quatro ou mais condutores e uma cobertura.

91. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que compreende também dispositivo para operar uma interface de dados USB por cada um dentre os controladores de link como uma parte do link de comunicação (406).

92. Equipamento, de acordo com a reivindicação 80, CARACTERI ZADO pelo fato de que o host (202) compreende um dispositivo de comunicação sem fio (102).

93. Equipamento, de acordo com a reivindicação 80, CARACTERI ZADO pelo fato de que o host compreende um computador portátil (100) possuindo um modem sem fio nele disposto.

94. Equipamento, de acordo com a reivindicação 80, CARACTERI ZADO pelo fato de que o dispositivo cliente (204) compreende um display de video portátil (104, 106) .

95. Equipamento, de acordo com a reivindicação 94, CARACTERI ZADO pelo fato de que o display de video portátil (104, 106) compreende um dispositivo de micro- display.

96. Equipamento, de acordo com a reivindicação 80, CARACTERI ZADO pelo fato de que o dispositivo cliente (204) compreende um sistema de apresentação de áudio portátil.

97. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que compreende também dispositivo para armazenar dados multimídia a serem transferidos para o dispositivo cliente (204) no host (202) .

98. Equipamento, de acordo com a reivindicação 80, CARACTERI ZADO pelo fato de que cada um dos pacotes compreende um campo comprimento de pacote, um ou mais campos dados de pacote e um campo verificação por redundância cíclica.

99. Equipamento, de acordo com a reivindicação 81, CARACTERIZADO pelo fato de que compreende também: dispositivo para negociar, entre os drivers de link de host e de cliente, o uso de um dentre uma pluralidade de modos de transferência em cada direção, cada um permitindo a transferência de diferentes números máximos de bits de dados em paralelo durante um dado período de tempo; e dispositivo para ajustar, de forma dinâmica, entre os modos de transferência durante a transferência de dados.

100. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que compreende também dispositivo para usar um ou mais dentre uma pluralidade de pacotes para a transferência de informações de vídeo escolhidos a partir do grupo de pacotes do tipo mapa de cores, transferência de blocos de bits, preenchimento de área de bitmap, preenchimento padrão de bitmap, e habilitação de cor transparente.

101. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que compreende também dispositivo para gerar pacotes do tipo preenchimento pelo host (202) para ocupar periodos de transmissão do link de emissão que não possuem dados.

102. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que compreende também dispositivo para transferir dados definidos por interface -usuário usando pacotes do tipo fluxo definidos pelo usuário.

103. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que compreende também dispositivo para transferir dados de ou para dispositivo de entrada de usuário associado ao dispositivo cliente (204) usando pacotes do tipo dados de teclado e dados de dispositivo apontador.

104. Equipamento, de acordo com a reivindicação 80, CARACTERIZADO pelo fato de que compreende também dispositivo para terminar a transferência de dados em qualquer direção através do link de comunicação (406) usando um pacote do tipo desativação de link para transmissão pelo host (202) para o cliente (204) .

105. Processador (5504) para uso em um sistema eletrônico para a transferência de dados digitais em uma alta taxa entre um dispositivo host (202) e um dispositivo cliente (204) através de um link de comunicação (406), o processador é CARACTERI ZADO pelo fato de que é configurado para gerar uma ou mais dentre uma pluralidade de estruturas de pacotes predefinidas e ligá-las umas às outras para formar um protocolo de comunicação predefinido; para formar dados digitais de apresentação em um ou mais tipos de pacotes de dados; comunicar um conjunto pré-selecionado de dados digitais de controle e apresentação entre os dispositivos host (202) e de cliente (204) através do link de comunicação (406) usando o protocolo de comunicação; e transferir dados na forma de pacotes através do link de comunicação (406).

106. Máquina de estado (5502) para uso na obtenção de sincronização em um sistema eletrônico transferindo dados digitais em uma alta taxa entre um dispositivo host (202) e um dispositivo cliente (204) através de um link de comunicação (406), a máquina de estado é CARACTERIΖΑΡΑ pelo fato de que é configurada para possuir pelo menos um estado de sincronização de estado de frames assíncrono, pelo menos dois estados de sincronização de estados de aquisição de sincronia e pelo menos três estados de sincronização de estados em-sincronização.