MXPA06006452A - Interfase de tasa alta de datos con sincronizacion de enlace mejorada. - Google Patents

Abstract

Una interfase de datos para transferir datos digitales entre un huesped y un cliente por una trayectoria de comunicaciones utilizando estructuras de paquete enlazadas conjuntamente para formar un protocolo de comunicaciones para comunicar un conjunto preseleccionado de datos digitales de control y de presentacion. El protocolo de senal es utilizado por los controladores de enlace configurados para generar, transmitir, y recibir paquetes que forman el protocolo de comunicaciones, y para formar datos digitales en uno o mas tipos de paquetes de datos, residiendo al menos uno en el dispositivo huesped y acoplandose al cliente mediante la trayectoria de comunicaciones. La interfase proporciona un mecanismo de transferencia de datos rentable, de bajo consume de potencia, bi-direccional y de alta velocidad sobre un enlace de datos de tipo `serial?? de rango corto, el cual se presta a si mismo a la implementacion con conectores de miniatura y cables flexibles delgados que son especialmente utiles para conectar elementos de visualizacion tales como micro-pantallas portatiles a computadoras portatiles y dispositivos de comunicaciones inalambricas.

Description

"INTERFASE DE TASA ALTA DE DATOS CON SINCRONIZACIÓN DE ENLACE MEJORADA" CAMPO DE LA INVENCIÓN Las modalidades de la invención en esta descripción se refieren a un protocolo de señales digitales y proceso para comunicar o transferir las señales entre un dispositivo huésped y un dispositivo cliente a altas tasas de datos. Más específicamente, la descripción se refiere a una técnica para transferir señales de multimedios y otros tipos de señales digitales provenientes de un dispositivo huésped o de controlador a un dispositivo cliente para la presentación o visualización a un usuario final que utiliza un mecanismo de transferencia de tasa alta de datos con bajo consumo de energía que tiene aplicaciones de dispositivo internos y externos.

ANTECEDENTES DE LA INVENCIÓN Las computadoras, productos relacionados con juegos electrónicos, y diversas tecnologías de video (por ejemplo, DVD' s y VCR' s de Alta Definición) han avanzado significativamente en el transcurso de los últimos años a fin de proporcionar una presentación de imágenes fijas, video, video bajo demanda e imágenes gráficas cada vez con mayor resolución, incluso cuando se incluye algunos tipos de texto, a los usuarios finales de tal equipo. Estos avances a su vez obligan al uso de dispositivos de visualización electrónicos de mayor resolución tales como los monitores de video de alta definición, monitores de HDTV (High Definition TV televisión de alta definición) , o elementos especializados para la proyección de imágenes. La combinación de tales imágenes visuales con datos de audio de alta definición o de alta calidad, tal como cuando se utiliza la reproducción de sonido de tipo CD, DVDs, sonido envolvente, y otros dispositivos que también tienen asociadas salidas de señal de audio, se utiliza para crear una experiencia de multimedios más real, rica en contenido, o verdadera para el usuario final. Además, los sistemas de sonido de alta calidad, altamente móviles, y los mecanismos de transporte de música, tal como los reproductores de MP3, se han desarrollado solamente para presentaciones de audio para los usuarios finales. Esto ha dado como resultado crecientes expectativas para los usuarios típicos de los dispositivos electrónicos comerciales, no es de computadoras hasta televisiones e incluso teléfonos, familiarizándose ahora con y esperando una salida de alta calidad.

En un escenario típico de presentación de video, que involucra un producto electrónico, típicamente se transfieren los datos de video utilizando técnicas actuales a una tasa que podria definirse mejor como lenta o intermedia, estando en el orden de una a decenas por segundo. Después, estos datos de memoria transitoria o de largo plazo, para su reproducción diferida (posterior) en un dispositivo de visualización deseado. Por ejemplo, pueden transferirse imágenes utilizando la Internet usando un programa residente en una computadora que tiene un módem u otro tipo de dispositivo de conexión de Internet, para recibir o transmitir datos útiles que representen digitalmente una imagen. Una transferencia similar puede tener lugar utilizando dispositivos inalámbricos tales co o computadoras portátiles equipadas ' con módems inalámbricos, o Asistentes de Datos Personales inalámbricos (PDAs - Personal Data Assistants) , o teléfonos inalámbricos. Una vez recibidos, los datos se almacenan localmente en elementos de memoria, circuitos, o dispositivos, tales como RAM o memoria instantánea, que incluyen dispositivos de de almacenamiento interno o externo tales como discos duros pequeños, para su reproducción. Dependiendo de la cantidad de datos y de la resolución de la imagen, la reproducción pudiese comenzar relativamente rápido, o presentarse con retrasos de largo plazo. Es decir, en algunos casos, la presentación de imágenes permite un cierto grado de reproducción en tiempo real para imágenes muy pequeñas o con una resolución baja que no requieren muchos datos, o utilizando algún tipo de memoria temporal, de manera que después de un pequeño retraso, se presente un poco de material mientras se transfiere más material. Visto que no existen interrupciones en el enlace de transferencia, o interferencia proveniente de otros sistemas o usuarios con relación al canal de transferencia que se utiliza, una vez que inicia la presentación la transferencia es razonablemente transparente para el usuario final del dispositivo de visualización. Naturalmente, cuando múltiples usuarios comparten una sola trayectoria de comunicaciones, tal como una conexión tableada de Internet, las transferencias pueden interrumpirse o pueden ser más lentas que lo deseado. Los datos utilizados para crear sea imágenes fijas o video en movimiento frecuentemente se comprimen utilizando una de varias técnicas conocidas tal como aquellas especificadas por el Grupo de Expertos Fotográficos (JPEG - Joint Photographic Experts Group), el Grupo de Expertos de Imágenes en Movimiento (MPEG -Motion Picture Experts Group) , y otras organizaciones o compañías de normas conocidas en las industrias de medios, computadoras, y comunicaciones a fin de acelerar la transferencia de datos a través de un enlace de comunicaciones. Esto permite transferir imágenes o datos más rápidamente que utilizando un número más pequeño de bits para transferir una determinada cantidad de información. Una vez que se transfieren los datos a un dispositivo "local" tal como una computadora que tiene un mecanismo de almacenamiento tal como una memoria, o elementos de almacenamiento magnéticos ópticos, o a otros dispositivos recipientes, la información resultante se descomprime (o se reproduce utilizando reproductores especiales de decodificación) , y se decodifica si es necesario, y se prepara para una presentación apropiada con base en los elementos de control y resolución de presentación disponibles correspondientes. Por ejemplo, una resolución de video de computadora típica en términos de una resolución de pantalla de X por Y pixeles oscila típicamente desde tan bajo como 480*640 pixeles, de 600*800 a 1024*1024, hasta una variedad de otras resoluciones generalmente posibles, según se desee o requiera.

La presentación de imágenes también se ve afectada por el contenido de imágenes y la capacidad de determinados controladores de video para manipular la imagen en términos de ciertos niveles de color de definidos o profundidad de color (bits por pixel utilizados para generar colores) e intensidades, y cualesquier bits adicionales de información complementaria que sean empleados. Por ejemplo, se prevé que una presentación tipica para computadora sea de alrededor de 8 a 32, o más, bits por pixel para representar diversos colores (sombras y tonos), aunque se encuentran otros valores. A partir de los valores anteriores, uno puede decir que una determinada imagen de pantalla va a requerir la transferencia de alrededor de 2.45 Megabits (Mb) a aproximadamente 33.55 Mb de datos sobre el rango desde las resoluciones típicas más bajas a más altas y profundidad, respectivamente. Cuando se visualiza video o imágenes de tipo movimiento a una velocidad de 30 tramas por segundo, la cantidad de datos requeridos es de aproximadamente 73.7 a 1,006 Megabits de datos por segundo (Mbps), o aproximadamente 9.21 a 125.75 Megabytes por segundo (MBps) . Además, uno puede desear presentar datos de audio junto con imágenes, tal como para una presentación de multimedios, o como una presentación de audio separada de alta resolución, tal como música con calidad de CD. También pueden emplearse señales adicionales relacionadas con comandos interactivos, controles, o señales. Cada una de estas opciones agrega aún más datos por transferirse. Además, las técnicas de transmisión más recientes que involucran televisión de Alta Definición (HD - High Definition) y grabaciones de películas pueden agregar aún más datos e información de control. En cualquier caso, cuando no desea transferir datos de imágenes de alta calidad o con alta resolución de información de audio de alta calidad o señales de datos a un usuario final para crear una experiencia de que contenido, se requiere un enlace de tasa alta de transferencia de datos entre los elementos de presentación y el dispositivo de fuente o huésped que se configura para proporcionar tales tipos de datos. Las tasas de datos de aproximadamente 115 ilobytes (KBps) o 920 Kilobits por segundo (Kbps) pueden manejarse rutinariamente por algunas interfases seriales de módems . Otras interfases tales como las interfases seriales de USB pueden alojar transferencia de datos a tasas tan altas como 12 MBps, y las transferencias de alta velocidad especializadas tales como aquellas configuradas utilizando la norma 1394 del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE - Institute of Electrical and Electronics Engineers) , puede ocurrir a tasas del orden de 100 a 400 MBps. Desafortunadamente, estas tasas se quedan cortas de las altas tasas de datos deseadas descritas con anterioridad las cuales se contemplan para su uso con futuros dispositivos inalámbricos de datos y otros servicios para proporcionar señales de salida de alta resolución, ricas en contenido, para accionar dispositivos de audio o dispositivos de video portátiles. Esto incluye computadoras para negocios y otras presentaciones, dispositivos para juegos, etcétera. Además, estas interfases requieren el uso de una cantidad significativa de huésped o software de sistema y cliente para operar. Sus pilas de protocolo de software crean también una gran cantidad indeseablemente de información complementaria, especialmente donde se contemplan los dispositivos inalámbricos móviles o aplicaciones telefónicas. Tales dispositivos tienen severas limitaciones de memoria y consumo de energía, asi como también la capacidad computacional ya tasada. Además, algunas de estas interfases utilizan cables voluminosos que son demasiado pesados e insatisfactorios para aplicaciones móviles orientadas altamente estéticas, conectores complejos los cuales añadirían costo, o que simplemente consumirían demasiada energía. Existen otras interfases conocidas tales como las interfases de Adaptador Gráfico de Video Análogo (AVGA - Analog Video Graphics Adapter) , Interactiva de Video Digital (DVI - Digital Video Interactive) o de Interfase de Video de Gigabit (GVIF - Gigabit Video Interface) . Las dos primeras de estas son interfases de tipo paralelo las cuales procesan los datos a tasas de transferencia más altas, pero también emplean cables pesados y consumen grandes cantidades de energía, del orden de varios vatios . Ninguna de estas características es fácil de utilizar con dispositivos electrónicos portátiles de consumidor. Incluso la tercera inferíase consume demasiada energía y utiliza conectores caros o voluminosos. Para algunas de las interfases anteriores, y otros sistemas/protocolos de datos de tasa muy alta o mecanismos de transferencia asociados con las transferencias de datos para equipos de computadora de instalación fija, existe otra desventaja principal. A fin de alojar las tasas de transferencia de datos deseadas se requiere también de cantidades sustanciales de energía y/o la operación a altos niveles de corriente. Esto reduce enormemente la utilidad de técnicas tales para productos orientados al consumidor altamente móviles. Generalmente, a fin de alojar tales tasas de transferencia de datos que utilizan alternativas tales como las conexiones de tipo fibra óptica y elementos de transferencia, se requiere también un cierto número de conversores adicionales y elementos que introducen mucha más complejidad y costo, que lo deseado para un producto verdaderamente comercial orientado al consumidor. Aparte de la naturaleza generalmente cara de los sistemas ópticos conocidos hasta ahora, sus requisitos de energía y complejidad evita el uso general para aplicaciones portátiles ligeras, portátiles, con bajo consumo de energía. Lo que ha faltado en la industria para aplicaciones portátiles, inalámbricas, o móviles, es una técnica que proporcione una experiencia de presentación de alta calidad, sea basada en audio, video, o multimedios, para usuarios finales altamente móviles. Es decir, cuando se utilizan computadoras portátiles, teléfonos inalámbricos, PDAs, u otros dispositivos o equipo de comunicaciones altamente móviles, los actuales sistemas o dispositivos de presentación de audio y video que se utilizan simplemente no pueden entregar una salida con un alto nivel de calidad deseada. Frecuentemente, la calidad percibida faltante es el resultado de altas tasas de datos inalcanzables necesarias para transferir los datos de presentación de alta calidad. Esto puede incluir tanto una transferencia a dispositivos externos más eficientes cargados con características avanzadas para la presentación a un usuario final, como la transferencia entre huéspedes y clientes internos a dispositivos portátiles tales como computadoras, máquinas para juegos, y dispositivos inalámbricos tales como teléfonos móviles. En este último caso, ha habido grandes pasos para añadir pantallas de video internas con más y más resolución, y otros dispositivos de entrada salida de especialidad y conexiones a dispositivos inalámbricos similares a los llamados teléfonos de tercera generación, y a las llamadas computadoras portátiles . Sin embargo, los buses de datos internos y conexiones que pueden incluir el puenteo a través de estructuras de tipo bisagra, o de bisagra deslizante o giratorias las cuales instalan o conectan pantallas de video u otros elementos al alojamiento principal donde residen el huésped y/o otros diversos elementos de control y componentes de salida. Estas son interfases de rendimiento de proceso y transferencia generalmente alto o con ancho de banda generalmente alto . Es muy difícil construir interfases de transferencias de datos de rendimiento de proceso y transferencia alto que utilizan técnicas anteriores las cuales pueden requerir hasta 90 conductores, o más, para alcanzar el rendimiento de proceso y transferencia deseado, por un teléfono inalámbrico, como ejemplo. Las soluciones actuales típicamente involucran emplear interfases de tipo paralelo con niveles de señal relativamente altos los cuales pueden ocasionar que la interconexión sea más costosa, menos confiable y que potencialmente genere emisiones radiadas que podrían interferir con funciones de dispositivo. Esto presenta muchos temas desafiantes de fabricación, costo, y confiabilidad a superar. Tales temas y requisitos también se ven en las instalaciones de ubicación fija donde los dispositivos de tipo comunicación o cómputo, como ejemplo, se añaden a aplicaciones y otros dispositivos de consumidor para proporcionar capacidades avanzadas de datos, conexiones de Internet y transferencia de datos, o entretenimiento incorporado. Otro ejemplo serian los aviones y autobuses donde las pantallas individuales para presentación de audio y video se instalan en la parte posterior de los asientos. Sin embargo, en estas situaciones frecuentemente es más conveniente, eficiente, y fácilmente aprovechable tener los elementos de control de almacenamiento principal, procesamiento, o de comunicaciones ubicados a una distancia desde las pantallas visibles o salidas de audio con un enlace de interconexión o canal para la presentación de información. Este enlace necesitará manejar una cantidad significativa de los datos para alcanzar el rendimiento de proceso y transferencia deseado, como se describe con anterioridad. Por lo tanto, se necesita un nuevo mecanismo de transferencia para incrementar el rendimiento de proceso y transferencia entre los dispositivos de huésped que proporcionan los datos y dispositivos o elementos de pantalla de datos y cliente que presentan una salida para los usuarios finales. Los solicitantes han propuesto tales mecanismos de transferencia nuevos en la Solicitud de Patente de E.U. No. de" Serie 10/020,520 presentada el 14 de Diciembre de 2001, ahora la Patente de E.U. No. 6,760,772, presentada el 6 de Julio de 2004 para Zou et. Al, y la Solicitud de Patente de E.U. No. de Serie 10/236,657 presentada el 6 de Septiembre de 2002, tituladas ambas "Generating And Implementing A Communication Protocol And Inferíase For High Data Rate Signal Transfer" ("Generar e implementar un protocolo de comunicaciones e interfase para transferencia de señales de tasa alta de datos") , ahora permitida, las cuales se ceden al cesionario de la presente invención e incorporadas en la presente para referencia. También, la Solicitud de Patente de E.U. No. de Serie 10/860,116 presentada el 2 de Junio de 2004 titulada "Generating and Implementing a Signal Protocol and Inferíase for Higher Data Rates" ("Generar e implementar un protocolo de señales e inferíase para tasas de datos más altos") . Las técnicas descritas en aquellas aplicaciones pueden mejorar enormemente la tasa de transferencia para grandes cantidades de datos en señales de datos de alta velocidad. Sin embargo, las demandas para tasas de datos siempre crecientes, especialmente como relacionadas con las presentaciones de video, continúan creciendo. Incluso con otros desarrollos en curso en la tecnología de señales de datos, aún existe la necesidad de esforzarse por tasas de transferencia aún más rápidas, eficiencias mejoradas de enlace de comunicación, y enlaces de comunicación más poderosos. Por lo tanto, existe una necesidad continua por desarrollar un mecanismo de transferencia nuevo o mejorado que sea necesario para incrementar el rendimiento de proceso y transferencia de datos entre los dispositivos huésped y cliente.

BREVE DESCRIPCIÓN DE LA INVENCIÓN Se abordan la desventaja anterior, y otras, existentes en la técnica anterior por las modalidades de la invención en las cuales se ha desarrollado un nuevo protocolo y medios de transferencia de datos, método y mecanismo para transferir los datos entre un dispositivo huésped y un dispositivo cliente recipiente a altas tasas de datos. Las modalidades para la invención se refieren a una Inferíase Móvil Digital de Datos (MDDI - Mobile Data Digital Inferíase) para transferir datos digitales a una tasa alta entre un dispositivo huésped y un dispositivo cliente sobre una trayectoria de comunicaciones que emplea una pluralidad de serie de estructuras de paquete para formar un protocolo de comunicaciones para comunicar un conjunto pre-seleccionado de datos de control digital y de presentación entre los dispositivos huésped y cliente. El protocolo de comunicaciones de señales o capa de enlace es utilizado por una capa física de los controladores de enlace de huésped o cliente, receptores, o manej adores. Al menos un controlador o mane ador de enlaces que reside en el dispositivo huésped se acopla al dispositivo cliente mediante la trayectoria o enlace de comunicaciones, y se configura para generar, transmitir, y recibir paquetes que forman el protocolo de comunicaciones, y para formar datos de presentación digital en uno o más tipos de paquetes de datos. La interfase proporciona transferencia bidireccional de información entre el huésped y el cliente, la cual puede residir dentro de un alojamiento o estructura de soporte general común. La implementación generalmente es de naturaleza totalmente digital con excepción de diferentes manej adores y receptores que pueden implementarse fácilmente en un chip de CMOS digital, requiere tan pocas comas 6 señales, y opera a casi cualquier tasa de datos que sea conveniente para el diseñador de sistemas. El protocolo sencillo de capa física y de enlace hace fácil la integración, y esta simplicidad más un estado de hibernación le permite al sistema portátil tener un consumo de energía de sistema muy baj o . Para ayudar al uso y aceptación, la interfase agregará muy poco al costo de un dispositivo, permitirá el consumo de muy poca energía mientras que es capaz de energizar pantallas mediante la interfase utilizando voltajes de baterías convencionales, y puede alojar dispositivos que tienen un factor de forma de bolsillo. La interfase es escalable para soportar las resoluciones más allá de HDTV, soporta video estéreo simultáneo y audio 7.1 para un dispositivo de visualización, realiza actualizaciones continuas en cualquier región de la pantalla, y soporta múltiples tipos de datos en ambas direcciones. En aspectos adicionales de las modalidades de la invención, se instala al menos un controlador de enlace de cliente, receptor, dispositivo, o manejador en el dispositivo cliente y se acopla al dispositivo huésped mediante la trayectoria o enlace de comunicaciones . El controlador de enlace de cliente se configura también para generar, transmitir, y recibir paquetes que forman el protocolo de comunicaciones, y para formar los datos de presentación digital en uno o más tipos de paquetes de datos. Generalmente, el controlador de huésped o de enlaces emplea una máquina de estaos para procesar los paquetes de datos utilizados en comandos o algunos tipos de preparación de señales y procesamiento de consultas, pero puede utilizar un procesador de propósito general más lento para manipular los datos y algunos de los paquetes menos complejos utilizados en el protocolo de comunicaciones. El controlador de huésped comprende uno más mane adores diferenciales de linea; aunque el receptor de cliente comprende uno o más recep'tores de linea diferenciales acoplados a la trayectoria de comunicaciones . Los paquetes se agrupan conjuntamente dentro de las tramas de medios que se comunican entre los dispositivos huésped y cliente que tienen un largo fijo pre-definido con un número pre-definido de paquetes que tienen diferentes largos variables. Cada uno de los paquetes comprende un campo de largo de paquete, uno o más campos de datos de paquete, y un campo de verificación de redundancia cíclica. Un Paquete de Cabecera de Sub-Trama se transfiere o coloca al inicio de las transferencias de otros paquetes desde el controlador de enlace de huésped. Uno o más paquetes de tipo de Flujo de Video y los paquetes de tipo de Flujo de Audio son utilizados por el protocolo de comunicaciones para transferir datos de tipo video y datos de tipo audio, respectivamente, desde el huésped al cliente por un enlace en avance para la presentación a un usuario de un dispositivo cliente. Uno o más paquetes de tipo Encapsulación de Enlace Inverso son utilizados por el protocolo de comunicaciones para transferir datos desde el dispositivo cliente al controlador de enlaces de huésped. Estas transferencias en algunas modalidades incluyen la transferencia de datos desde los controladores internos que tienen al menos un dispositivo de MDDI a las pantallas de video internas. Otras modalidades incluyen transferencias a sistemas de sonido internos, y transferencias desde diversos dispositivos de entrada que incluyen palancas de mando y teclados complejos para los dispositivos huésped internos. Los paquetes de tipo de relleno son generados por el controlador de enlace de huésped para ocupar períodos de transmisión de enlace en avance que no tienen datos. Una pluralidad de otros paquetes es utilizada por el protocolo de comunicaciones para transferir información de vídeo. Tales paquetes incluyen paquetes de tipo de Mapa de Colores, Transferencia de Bloque de Bits, Rellenar Área de Mapa de Bits, Rellenar Patrón de Mapa de Bits, y Habilitar Color Transparente. Los paquetes de tipo de Flujo Definido por el Usuario son utilizados por el protocolo de comunicaciones para transferir datos definidos por el usuario de interfase. Los paquetes de tipo de Datos de Teclado y Datos de Dispositivo de Señalización son utilizados por el protocolo de comunicaciones para transferir datos a órdenes de los dispositivos de entrada de usuarios asociados con dicho dispositivo cliente. Un paquete de tipo Desconexión de Enlace es utilizado por el protocolo de comunicaciones para terminar la transferencia de datos en cualquier dirección por dicha trayectoria de comunicaciones . La trayectoria de comunicaciones generalmente comprende o emplea un cable que tiene una serie de cuatro o más conductores y una protección. Además, puede utilizarse cables impresos o conductores, según se desee, con algunos de ellos residiendo sobre substratos flexibles. El controlador de enlace de huésped solicita información sobre las capacidades de visualización desde el dispositivo cliente con objeto de determinar qué tipo de datos y tasas de datos es capaz dicho cliente de alojar mediante dicha interfase. El controlador de enlace de cliente le comunica las capacidades de visualización o presentación al controlador de enlace de huésped utilizando al menos un paquete de tipo Capacidad de Cliente. El protocolo de comunicaciones utiliza múltiples modos de transferencia permitiendo cada uno de ellos la transferencia de diferentes números máximos de bits de datos en paralelo durante un cierto período de tiempo, seleccionable cada modo por negociación entre los controladores de enlace de huésped y de cliente. Estos modos de transferencia son ajustables dinámicamente durante la transferencia de datos, y no necesita utilizarse el mismo modo por el enlace inverso como es utilizado por el enlace en avance . En otros aspectos de algunas modalidades de la invención, el dispositivo huésped comprende un dispositivo de comunicaciones inalámbricas, tal como un teléfono inalámbrico, un PDA inalámbrico, o una computadora portátil que tenga un módem inalámbrico en su interior. Un dispositivo cliente tipico comprende una pantalla de vídeo portátil tal como un dispositivo de micro-pantalla, y/o un sistema portátil de presentación de audio. Además, el huésped puede utilizar medios o elementos de almacenamiento para almacenar datos de presentación o multimedios a ser transferidos para presentarse a un usuario de dispositivo cliente. Aún en otros aspectos de algunas modalidades, el dispositivo huésped comprende un controlador o dispositivo de control de enlace de comunicaciones con manej adores como los descritos a continuación que residen dentro de un dispositivo electrónico portátil tal como un dispositivo de comunicaciones inalámbricas, tal como un teléfono inalámbrico, un PDA inalámbrico, o una computadora portátil. Un dispositivo cliente típico en esta configuración comprende un circuito cliente o circuito integrado o módulo acoplado al huésped y que reside dentro del mismo dispositivo, y a una pantalla de vídeo interna tal como una pantalla de alta resolución para un teléfono móvil, y/o un sistema portátil de presentación de audio, o alternativamente algún tipo de sistema o dispositivo de entrada.

BREVE DESCRIPCIÓN DE LOS DIBUJOS A continuación se describen detalladamente algunas características y ventajas adicionales, así como también la estructura y operación de diversas modalidades de la invención con referencia a los dibujos acompañante. En los dibujos, los números de referencia similares generalmente indican elementos o pasos de procesamiento idénticos, funcionalmente similares, y/o estructuralmente similares, y el dibujo en el cual aparece un primer elemento es indicado por el (los) dígito (s) de la extrema izquierda en el número referencia. La Figura 1A ilustra un ambiente básico en el cual las modalidades de la invención deben operar incluyendo el uso de un dispositivo de micro-pantalla, o un proyector, en conjunto con una computadora portátil u otro dispositivo de procesamiento de datos.

La Figura IB ilustra un ambiente básico en el cual las modalidades de la invención deben operar incluyendo el uso de un dispositivo de micro-pantalla o un proyector, y elementos de presentación de audio utilizados en conjunto con un transceptor inalámbrico. La Figura 1C ilustra un ambiente básico en el cual las modalidades de la invención deben operar incluyendo el uso de dispositivos de visualización interna o de presentación de audio utilizados en una computadora portátil . La Figura ID ilustra un ambiente básico en el cual las modalidades de la invención deben operar incluyendo el uso de elementos de visualización interna o de presentación de audio utilizados en un transceptor inalámbrico. La Figura 2 ilustra el concepto general de una Inferíase Móvil de Datos Digitales con una interconexión de huésped y cliente. La Figura 3 ilustra la estructura de un paquete útil para realizar transferencias de datos desde un dispositivo cliente hacia un dispositivo huésped. La Figura 4 ilustra el uso de un controlador de enlace de MDDI y los tipos de señales pasadas entre un huésped y un cliente por los conductores de . enlace de datos físicos para una interfase de Tipo 1. La Figura 5 ilustra el uso de un controlador de enlace de MDDI y los tipos de señales pasadas entre huésped y un cliente por los conductores de enlace de datos físicos para las interfases de Tipos 2, 3, y 4. La Figura 6 ilustra la estructura de tramas y sub-tramas utilizadas para implementar el protocolo de interfase. La Figura 7 ilustra la estructura general de los paquetes utilizados para implementar el protocolo de interfase. La Figura 8 ilustra el formato de un Paquete de Cabecera de Sub-Trama. La Figura 9 ilustra el formato y contenido de un Paquete de Relleno. La Figura 10 ilustra el formato de un Paquete de Flujo de Video. Las Figuras 11A-11E ilustran el formato y contenido para el Descriptor de Formato de Datos de Vídeo utilizado en la Figura 10. La Figura 12 ilustra el uso de formatos empaquetado y no empaquetado para datos . La Figura 13 ilustra el formato de un Paquete de Flujos de Audio. La Figura 14 ilustra el uso de formatos de PCM de byte alineado y empaquetado para datos. La Figura 15 ilustra el formato de un Paquete de Flujo Definido por Usuario. La Figura 16 ilustra el formato de un Paquete de Mapa de Colores . La Figura 17 ilustra el formato de un Paquete de Encapsulación de Enlace Inverso. La Figura 18 ilustra el formato de un Paquete de Capacidad de Cliente. La Figura 19 ilustra el formato de un Paquete de Datos de Teclado. La Figura 20 ilustra el formato de un Paquete de Datos de Dispositivo de señalización. La Figura 21 ilustra el formato de un Paquete de Desconexión de Enlace. La Figura 22 ilustra el formato de un Paquete de Solicitud y Estado de Cliente. La Figura 23 ilustra el formato de un Paquete de Transferencia de Bloque de Bits. La Figura 24 ilustra el formato de un Paquete Rellenar Área de Mapa de Bits . La Figura 25 ilustra el formato de un Paquete Rellenar Patrón de Mapa de Bits. La Figura 26 ilustra el formato de un Paquete de Canal de Datos de Enlace de Comunicaciones.

La Figura 27 ilustra el formato de un Paquete de Solicitud de Transferencia de Tipo de Inferíase. La Figura 28 ilustra el formato de un Paquete de Reconocimiento de Tipo de Inferíase. La Figura 29 ilustra el formato de un Paquete de Transferencia de Tipo de Rendimiento. La Figura 30 ilustra el formato de un Paquete de Habilitación de Canal de Audio en Avance. La Figura 31 ilustra el formato de un Paquete de Tasa de Muestreo de Audio Inverso. La Figura 32 ilustra el formato de un Paquete de Información Complementaria de Protección de Contenido Digital. La Figura 33 ilustra el formato de un Paquete de Habilitación de Color Transparente. La Figura 34 ilustra el formato de un Paquete de Medición de Retraso de Viaje Redondo. La Figura 35 ilustra la sincronización de eventos durante el Paquete de Medición de Retraso de Viaje Redondo. La Figura 36 una implementación a manera de ejemplo de un generador de CRC y un verificador útil para implementar la invención. La Figura 37A ilustra la sincronización de señales de CRC para el aparato de la Figura 36 cuando se envían los paquetes de datos. La Figura 37B ilustra la sincronización de señales de CRC para el aparato de la Figura 36 cuando se reciben los paquetes de datos. La Figura 38 ilustra los pasos de procesamiento para una solicitud de servicio típico sin contención. La Figura 39 ilustra los pasos de procesamiento para una solicitud de servicio típico mantenida después de que ha comenzado la secuencia de reinicio de enlace, contendiendo con el inicio del enlace . La Figura 40 ilustra cómo puede transmitirse una secuencia de datos utilizando codificación de DATOS-STB. La Figura 41 ilustra la circuitería útil para generar las señales de DATOS y STB provenientes de los datos de entrada en el huésped, y para recuperar después los datos en el cliente. La Figura 42 ilustra mane adores y resistores de terminación útiles para implementar una modalidad. La Figura 43A-43C ilustran los pasos y niveles de señal empleados por un cliente para asegurar el servicio desde el huésped y por el huésped para proporcionar tal servicio.

La Figura 44 ilustra el espaciamiento relativo entre las transiciones en los DatosO, otras lineas de datos (DatosX) , y las líneas estroboscópicas (Stb) . La Figura 45 ilustra la presencia de un retraso en respuesta que puede ocurrir cuando un huésped deshabilita el manej ador de huésped después de transferir un paquete. La Figura 46 ilustra la presencia de un retraso en respuesta que puede ocurrir cuando un huésped habilita al manej ador de huésped para transferir un paquete. La Figura 47 ilustra el análisis de corriente de fuga. La Figura 48 ilustra las características de conmutación y relaciones de sincronización relativas para el tiempo de habilitación y deshabilitación de salida de huésped y cliente La Figura 49 ilustra un diagrama de alto nivel de pasos de procesamiento de señales y condiciones por las cuales puede i plementarse la sincronización utilizando una máquina de estados. La Figura 50 ilustra cantidades típicas de retraso encontradas para el procesamiento de señales por las trayectorias en avance e inversa en un sistema que emplea la MDDI . La Figura 51 ilustra la medición de retraso marginal de viaje redondo. La Figura 52A ilustra los cambios de tasa de datos de Enlace Inverso. La Figura 52B ilustra un ejemplo de uestreo de datos inverso avanzado. La Figura 53 ilustra una representación gráfica de los valores del Divisor de Tasa Inversa contra la tasa de datos de enlace en avance. Las Figuras 54A y 54B ilustran los pasos ejecutados en la operación de una interfase. La Figura 55 ilustra un resumen de los paquetes de procesamiento del aparato de interfase. La Figura 56 ilustra el formato de un Paquete de Enlace en Avance. La Figura 57 ilustra los valores típicos para el retraso de propagación y distorsión en una interfase de Enlace de Tipo 1. La Figura 58 ilustra los Datos, Stb, y Sincronización de Recuperación de Reloj en un Enlace de Tipo 1 para el procesamiento de señales a manera de ejemplo mediante la interfase. La Figura 59 ilustra valores típicos para el retraso de propagación y distorsión en las interfases de Tipo 2, Tipo 3 o Tipo 4. Las Figuras 60A, 60B, y 60C ilustran diferentes posibilidades para la sincronización de dos señales de datos y MDDI_Stb una con respecto a otra, siendo ideal, inicial, y posterior, respectivamente. La Figura 61 ilustra los conectores a manera de ejemplo de las asignaciones de patillas de interfase utilizados con interfases de Tipo I/Tipo 2. Las Figuras 62A y 62B ilustran posibles formas de onda de MDDI_Datos y MDDI_Stb tanto para las interfases de Tipo 1 como de Tipo 2, respectivamente. La Figura 63 ilustra un diagrama de alto nivel de pasos alternativos de procesamiento de señales y condiciones por las cuales puede implementarse la sincronización utilizando una máquina de estados. La Figura 64 ilustra la sincronización relativa a manera de ejemplo entre una serie de ciclos de reloj y la sincronización de diversos bits de paquetes de enlace inverso y valores de divisor. La Figura 65 ilustra el procesamiento de transferencia de código de error a manera de ejemplo. La Figura 66 ilustra un aparato útil para el procesamiento de transferencia de código de error. La Figura 67A ilustra el procesamiento de transferencia de código de error para la sobrecarga de código . La Figura 67B ilustra el procesamiento de transferencia de código de error para la recepción de código . La Figura 68A ilustra los pasos de procesamiento para un despertar iniciado por el huésped. La Figura 68B ilustra los pasos de procesamiento para un despertar iniciado por el cliente. La Figura 68C ilustra los pasos de procesamiento para un despertar con contención iniciado por el huésped y el cliente. La Figura 69 ilustra el formato de un Paquete Solicitar Características de VCP. La Figura 70 ilustra el formato de un Paquete de Respuestas de Características de VCP. La Figura 71 ilustra el formato de una Lista de Respuestas de Características de VCP. La Figura 72 ilustra el formato de un Paquete Establecer Características de VCP. La Figura 73 ilustra el formato de un Paquete Solicitar Parámetros Válidos. La Figura 74 ilustra el formato de un Paquete de Respuesta de Parámetros Válidos.

La Figura 75 ilustra el formato de un Paquete de Capacidad de Flujo de Video con Escala de Variación. La Figura 76 ilustra el formato de un Paquete de Configuración de Flujo de Video con Escala de Variación. La Figura 77 ilustra el formato de un Paquete de Reconocimiento de Flujo de Video con Escala de Variación. La Figura 78 ilustra el formato de un Paquete de Flujo de Video con Escala de Variación. La Figura 79 ilustra el formato de un Paquete de Estado Específico de Solicitud. La Figura 80 ilustra el formato de un Paquete de Lista de Respuestas de Estado Válido. La Figura 81A ilustra el formato de un Paquete de Parámetros de Retraso de Procesamiento de Paquetes . La Figura 8 IB ilustra el formato de un elemento de Lista de Parámetros de Retraso. La Figura 82 ilustra el formato de un Paquete de Capacidad de Visualización Personal. La Figura 83 ilustra los elementos en los Puntos de la Lista de Curvatura de Campo. La Figura 84A ilustra el formato de un Paquete de Reporte de Error de Cliente.

La Figura 84B ilustra - el formato de un elemento de Lista de Reporte de Error. La Figura 85 ilustra el formato de un Paquete de Identificación de Cliente. La Figura 86 ilustra el formato de un Paquete de Capacidad de Pantalla Alterna. La Figura 87 ilustra el formato de un Paquete de Acceso de Registro. Las Figuras 88A-88C ilustran el uso de dos memorias temporales de pantalla para reducir los artefactos visibles. • La Figura 89 ilustra dos memorias temporales con un refresco de pantalla más rápido que la transferencia de imágenes. La Figura 90 ilustra dos memorias temporales con un refresco de pantalla más lento que la transferencia de imágenes. La Figura 91 ilustra dos memorias temporales con un refresco de pantalla mucho más rápido que la transferencia de imágenes. La Figura 92 ilustra tres memorias temporales con un refresco de pantalla más rápido que la transferencia de imágenes . La Figura 93 ilustra tres memorias temporales con un refresco de pantalla más lento que la transferencia de imágenes. La Figura 94 ilustra una memoria temporal con un refresco de pantalla más rápido que la transferencia de imágenes . La Figura 95 ilustra la conexión huésped-cliente mediante una cadena tipo margarita y concentrador. La Figura 96 los dispositivos de cliente conectados mediante una combinación de concentradores y cadenas de tipo margarita. La Figura 97 ilustra un mapa de colores.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN I . Resumen Un intento general de la invención es proporcionar una Interfase Móvil Digital de Visualización (MDDI - Mobile Display Digital Inferíase) , como se describe a continuación, la cual da como resultado o proporciona un mecanismo rentable, de bajo consumo de energía, que permite la transferencia de datos de alta o muy alta velocidad por un enlace de comunicaciones de rango corto entre un dispositivo huésped y un dispositivo cliente, tal como un elemento de visualización, que utiliza un tipo "serial" de enlace o canal de datos. Este mecanismo se presta a si mismo a la implementación con conectores en miniatura y cables flexibles delgados los cuales son especialmente útiles para conectar elementos o dispositivos de visualización o de salida, o dispositivos de entrada a un controlador o elemento de comunicaciones o dispositivo central. Además, este mecanismo de conexión es muy útil para conectar los elementos o dispositivos de visualización externos tales como micro-pantallas portátiles (lentes o proyectores) u otros tipos de dispositivos de presentación de información visual, audible, táctil para computadoras portátiles, dispositivos de comunicaciones inalámbricas, o dispositivos de entretenimiento. Aunque los términos Móvil y Pantalla/Visualización se encuentran asociados con la denominación del protocolo, debe comprenderse que esto es por conveniencia solamente en términos de tener un nombre convencional fácilmente comprensible por aquellos expertos en la materia que trabajan con la interfase y el protocolo. Como se relacionará con la norma VESA y diversas aplicaciones de esta norma. Sin embargo, se comprenderá fácilmente que después de una revisión de las modalidades presentadas a continuación que muchas aplicaciones relacionadas no móviles y sin pantalla se beneficiarán de la aplicación de este protocolo, dando como resultado una estructura de interfase, o mecanismo de transferencia, y la etiqueta de MDDI no pretende implicar limitante alguna a la naturaleza o utilidad de la invención o sus diversas modalidades . Una ventaja de las modalidades de la invención es que se proporciona un técnica para la transferencia de datos que sea de una complejidad baja, de bajo costo, que tenga una confiabilidad alta, ajuste bien dentro del ambiente de uso, y que sea muy robusta, siendo a la vez muy flexible. Las modalidades de la invención pueden utilizarse en una variedad de situaciones para comunicar o transferir grandes cantidades de datos, generalmente para aplicaciones de audio, video, o multimedios provenientes de un dispositivo huésped o fuente donde se generan y se manipulan tales datos, tal como para la transferencia a dispositivos específicos, o de otra manera se procesan, o almacenan; a un dispositivo cliente o de recepción, tal como un elemento de visualización o de proyección de video, bocinas para audio, u otro dispositivo de presentación a una tasa alta. Una aplicación típica, que se describe a continuación, es la transferencia de datos provenientes sea de una computadora portátil o un teléfono o módem inalámbrico a un dispositivo de visualización tal como una pequeña pantalla de video o una aplicación de micro-pantalla portátil, tal como en forma de lentes o cascos que contienen pequeños lentes y pantallas de proyección, o desde un dispositivo huésped a un dispositivo cliente dentro de tales componentes. Es decir, desde un procesador o controlador hacia una pantalla interna u otro elemento de presentación, asi como también desde diversos dispositivos de entrada internos o externos que emplean un cliente a un huésped ubicado internamente (colocado dentro del mismo alojamiento de dispositivo o estructura de soporte) , o conectado al mismo por un cable o conductores . Las características o atributos de la MDDI son tale que son independientes de la tecnología de visualización o presentación específica. Este es un mecanismo altamente flexible para transferir datos a una tasa alta sin importar la estructura interna de esos datos, ni los aspectos funcionales de los datos o comandos que implementa. Esto permite que la sincronización de los paquetes de datos que se transfieren para ajustarse a fin de adaptarse a las idiosincrasias de dispositivos clientes particulares, tales como para lo deseos de visualización única para algunos dispositivos, o para cumplir los requisitos de audio y video combinado para algunos sistemas de A-V, o para algunos dispositivos de entrada tales como palancas de mando, pantallas táctiles, etcétera. La interfase es un elemento de visualización o dispositivo cliente agnóstico, siempre y cuando se siga el protocolo seleccionado. Además, los datos de enlace serial agregados, o tasa de datos, pueden variar en diversos órdenes de la magnitud que le permita al diseñador de sistemas de comunicaciones o dispositivo huésped optimizar el costo, requisitos de potencia, complejidad de dispositivo cliente, y tasas de actualización de dispositivo cliente. La interfase de datos se presenta básicamente para su uso en la transferencia de grandes cantidades de datos de tasa alta por un enlace de señal "cableado" o un pequeño cable. Sin embargo, algunas aplicaciones también pueden sacar ventaja de un enlace inalámbrico, incluyendo enlaces ópticos, puesto que se configura para utilizar el mismo paquete y estructuras de datos desarrolladas para el protocolo de interfase, y puede sostener el nivel deseado de transferencia en un consumo de potencia suficientemente bajo o que la complejidad siga siendo práctica.

II. Ambiente Una aplicación típica puede observarse en las Figuras 1A y IB donde una computadora portátil 100 y un teléfono inalámbrico o dispositivo 102 de PDA muestran la comunicación de datos con los dispositivos de visualización 104 y 106, respectivamente, junto con los sistemas de reproducción de audio 108 y 112. Además, la Figura ÍA muestra conexiones potenciales para una pantalla 114 más grande o un proyector 116 de imágenes, que se muestran solamente en un figura en aras de la claridad, pero son conectables también al dispositivo inalámbrico 102. El dispositivo inalámbrico puede estar recibiendo actualmente datos o tener previamente almacenados una cierta cantidad de datos de tipo multimedios en un elemento o dispositivo de memoria para la presentación posterior para visualización y/o escucha por un usuario final del dispositivo inalámbrico. Dado que se utiliza un dispositivo inalámbrico típico para las comunicaciones de voz y texto sencillo la mayor parte del tiempo, tiene una pantalla de visualización más bien pequeña y un sistema de audio sencillo (bocinas) para comunicarle la información al usuario del dispositivo 102. La computadora 100 tiene una pantalla mucho más grande, pero un sistema de sonido externo aún inadecuado, y se queda corta para otros dispositivos de presentación de multimedios tales como una televisión de alta definición, o pantallas para películas. La computadora 100 se utiliza para propósitos de ilustración y también pueden utilizarse con la invención otros tipos de procesadores, videojuegos interactivos, o dispositivos electrónicos para el consumidor. La computadora 100 puede emplear, pero no se limita a o por, un módem inalámbrico u otro dispositivo incorporado para comunicaciones inalámbricas, o conectarse a tales dispositivos que utilizan un cable o enlace inalámbrico, según se desee. Esto vuelve la presentación de datos más complejos o de "rica" en datos una experiencia poco útil o agradable. Por lo tanto, la industria se encuentra desarrollando otros mecanismos y dispositivos para presentar la información a los usuarios finales y proporcionar un nivel mínimo de experiencia de entretenimiento deseada o positiva. Como se describió con anterioridad, varios tipos de dispositivos de visualización han o se están encuentran desarrollando actualmente para presentarle la información a los usuarios finales del dispositivo 100. Por ejemplo, una o más compañías han desarrollado conjuntos de lentes portátiles que proyectan una imagen frente a los ojos de un usuario de dispositivo a fin de presentar una pantalla visual. Cuando tales dispositivos se encuentran colocados correctamente "proyectan" eficazmente una imagen virtual, como se percibe por los ojos de un usuario, que es mucho más grande que el elemento que proporciona la salida visual. Es decir, un elemento de proyección muy pequeño le permite a los ojos del usuario "ver" imágenes en una escala mucho mayor que lo posible con pantallas típicas de LCD y lo similar. El uso de imágenes de pantallas virtuales más grandes permite también el uso de imágenes con una resolución mucho mayor que lo posible con pantallas de LCD más limitadas. Otros dispositivos de visualización podrían incluir, pero no se limitan a, pequeñas pantallas de LCD o diversos elementos de visualización de panel plano, lentes de proyección y manejadores de pantalla para proyectar imágenes sobre una superficie, etcétera. También puede haber elementos adicionales conectados a o asociados con el uso del dispositivo inalámbrico 102 o la computadora 100 para presentarle una salida a otro usuario, o a otro dispositivo el cual transfiere a su vez las señales en cualquier otra parte o las almacena. Por ejemplo, los datos pueden almacenarse en memoria instantánea, en forma óptica, por ejemplo utilizando un medio de CD escribible o un medio magnético tal como en uns grabador de cinta magnética y dispositivos similares, para su uso posterior. Además, muchos dispositivos inalámbricos y computadoras han incorporado ahora capacidades de decodificación de música en MP3, asi como también otros avanzados decodificadores y sistemas de sonido. Las computadoras portátiles utilizan capacidades de reproducción de CD y DVD como regla general, y algunos tienen pequeños lectores de memorias instantáneas dedicadas para recibir archivos de audio pfe-grabados . El tema para tener tales capacidades es que los archivos de música digital prometen un experiencia rica en características altamente mejorada, pero solamente si el proceso de decodificación y reproducción pueden mantener el ritmo. Lo mismo es verdadero para los archivos de video digitales. A fin de contribuir a la reproducción de sonido, las bocinas externas 114 se muestran en la Figura ÍA, lo cual también podría ir acompañado de elementos de adición tales como subaltavoces para bajas frecuencias, o bocinas de "sonido envolvente" para la proyección del sonido frontal y posterior. Al mismo tiempo, las bocinas o audífonos 108 se indican por estar incorporados en la trama de soporte o mecani.s; o del dispositivo 106 de micro-pantalla de la Figura IB. Como se sabe, pueden utilizarse otros elementos de reproducción de audio o sonido incluyendo la amplificación de la potencia o los dispositivos de conformación de sonidos. En cualquier caso, como se describió con anterioridad, cuando uno desea transferir datos de imágenes de alta calidad con una resolución alta e información de audio o señales de datos de alta calidad provenientes de una fuente de datos a un usuario final por uno o más enlaces 110 de comunicaciones, se requiere una tasa alta de datos. Es decir, el enlace 110 de transferencia es evidentemente un cuello de botella potencial en la comunicación de datos como se describió con anterioridad, y está limitando el rendimiento del sistema, dado que los mecanismos de transferencia actuales no alcanzan las altas tasas de datos típicamente deseadas. Como se describió con anterioridad por ejemplo, para las resoluciones más altas de imágenes tales como 1024 por 1024 píxeles, con profundidades de color de 24-32 bits por píxel y a tasas de datos de 30 tps (tramas por segundo) , las tasas de datos pueden aproximarse a tasas en exceso de 755 Mbps o más. Además, tales imágenes pueden presentarse como parte de una presentación de multimedios la cual incluye datos de audio y potencialmente señales de audio que tienen que ver con juegos interactivos o comunicaciones, o diversos comandos, controles, o señales, que incrementan adicionalmente la cantidad o datos y la tasas de datos. También es evidente que se requieren menos cables o interconexiones para establecer un enlace de datos, lo que significa que los dispositivos móviles asociados con una pantalla son más fáciles de utilizar, y más propensos a ser adoptados por una base de usuario más grande. Esto es especialmente verdadero cuando se utilizan comúnmente múltiples dispositivos para establecer una experiencia audio-visual plena, y más especialmente a medida que se incrementa el nivel de calidad de las pantallas y dispositivos de salida de audio. Otra aplicación típica relacionada con muchas de las mejoras anteriores y otras en pantallas de video y pueden observarse otros dispositivos de entrada salida en las Figuras 1C y ID donde se muestran una computadora portátil 130 y un teléfono inalámbrico o dispositivo 140 de PDA comunicando datos con dispositivos 134 y 144 de visualización "interna", respectivamente, junto con los sistemas 136 y 146 de reproducción de audio . En las Figuras 1C y ID, se utilizan pequeñas secciones despiezadas de los dispositivos o productos electrónicos en general para mostrar la ubicación de uno o más huéspedes internos y controladores en una porción del dispositivo con un enlace de comunicaciones generalizado, aquí 138 y 148, respectivamente, conectándolos a los elementos de visualización de video o pantallas que tienen los clientes correspondientes, a través de una articulación giratoria de algún tipo conocido utilizado mediante la industria electrónica hoy en dia. Uno puede ver que la cantidad de datos involucrados en estas transferencias requiere un gran número de conductores para comprender los enlaces 138 y 148. Se calcula que tales enlaces de comunicaciones se encuentran próximos 90 o más conductores con objeto de satisfacer las crecientes necesidades hoy en día para utilizar interfases gráficas avanzadas y de colores, elementos de visualización, en tales dispositivos debido a los tipos de técnicas de interfases paralelas u otras técnicas conocidas disponibles para transferir tales datos. Desafortunadamente, las tasas de datos más altas exceden la tecnología actual disponible para transferencia de datos . Tanto en términos de la cantidad de datos sin procesar que necesitan transferirse por unidad de tiempo, como en términos de elaboración de mecanismos confiables de transferencia física rentable. Lo que se necesita es una técnica, una estructura, medio o método, para transferir datos a tasas más altos para el enlace de transferencia de datos o trayectoria de comunicaciones entre elementos de presentación y la fuente de datos, lo cual permite una estructura de cableado consistentemente de baja (o más baja) potencia, de peso ligero, y tan sencilla y económica como sea posible. Los solicitantes han desarrollado una nueva técnica, o método y aparato, para alcanzar estas y otras metas a fin de permitir un arreglo de dispositivos móviles, portátiles, o incluso fijos a fin de transferir datos a las pantallas, micro-pantallas, o elementos de transferencia de audio deseados, a tasas de datos muy altas, mientras se mantiene un consumo de potencia deseado y una complejidad deseadas.

III. Arquitectura de Sistema de Inferíase de Datos Digitales de Tasa Alta Con objeto de crear y utilizar eficazmente una nueva interfase de dispositivos, se ha formulado un protocolo de señales y arquitectura de sistema que proporciona una tasa de transferencia de datos muy alta utilizando señales de baja potencia. El protocolo se basa en una estructura de paquete y trama común, o estructuras enlazadas conjuntamente para formar un protocolo para comunicar un conjunto de datos o tipos de datos pre-seleccionados junto con un comando o estructura operacional impuesto a la interfase.

A. Resumen Los dispositivos conectados al comunicarse por el enlace de MDDI son llamados huésped y cliente, siendo típicamente el cliente un dispositivo de visualización de algún tipo, aunque se contemplan otros dispositivos de entrada y salida. Los datos provenientes del huésped hacia la pantalla viajan en la dirección en avance (con referencia al tráfico o enlace en avance) , y los datos provenientes del cliente al huésped viajan en dirección inversa (tráfico o enlace inverso) , según son habilitados por el huésped. Esto • se ilustra en la configuración básica mostrada en la Figura 2. En la Figura 2, se conecta un huésped 202 a un cliente 204 utilizando un canal 206 de comunicaciones bi-direccional el cual es ilustrado por comprender un enlace en avance 208 y un enlace inverso 210. Sin embargo, estos canales se forman por un conjunto común de conductores cuya transferencia de datos conmuta entre las operaciones de enlace en avance e inverso. Esto permite números de conductores enormemente reducidos, que abordan inmediatamente uno de los muchos problemas afrontados con los planteamientos actuales para transferir datos a alta velocidad en ambientes de baja potencia tales como dispositivos electrónicos móviles. Como se describió en otra parte, el huésped comprende uno de varios tipos de dispositivos que pueden beneficiarse de utilizar la presente invención. Por ejemplo, el huésped 202 podría ser una computadora portátil en forma de un dispositivo de cómputo manual, portátil o móvil similar. También podría ser un Asistente de Datos Personal (PDA) , un dispositivo de localización, o uno de muchos teléfonos o módems inalámbricos. Alternativamente, el huésped 202 podría ser un dispositivo de entretenimiento o presentación portátil tal como un reproductor portátil de DVD o CD, o un dispositivo de reproducción de juegos. Además, el huésped puede residir como un dispositivo huésped o elemento de control en una variedad de otros productos comerciales ampliamente utilizados o planeados para los cuales se desea un enlace de comunicaciones de alta velocidad con un cliente. Por ejemplo, podría utilizarse un huésped para transferir datos a tasas altas desde un dispositivo de grabación de video a un cliente basado en el almacenamiento para una respuesta mejorada, o a una pantalla más grande con alta resolución para presentaciones. Una aplicación tal como un refrigerador que incorpora un inventario o sistema de cómputo a bordo y/o conexiones Bluetooth a otros dispositivos para el hogar, puede tener capacidades de visualización mejoradas cuando se opera en un modo conectado a Internet o a un Bluetooth, o que tienen necesidades reducidas de cableado para pantallas de uso para interiores (un cliente) y teclados o lectores (cliente) mientras los sistemas de computadoras electrónicas o de control (huésped) residen en cualquier otra parte en el gabinete. En general, aquellos expertos en la materia apreciarán la amplia variedad de modernos dispositivos electrónicos y aplicaciones que pueden beneficiarse del uso de esta interfase, asi como también la capacidad de retroajustar dispositivos más viejos con un transporte de información de tasa de datos más alta que utiliza números limitados de conductores disponibles sea en los conectores o cables existentes o en aquellos recientemente agregados. Al mismo tiempo, el cliente 204 podria comprender una variedad de dispositivos útiles para presentar información a un usuario final, o presentar información desde un usuario al huésped. Por ejemplo, una micro-pantalla incorporada en lentes, un dispositivo de proyección incorporado en un sombrero o casco, una pequeña pantalla o incluso un elemento holográfico incorporado en un vehiculo, tal como en una ventana o en un parabrisas, o diversos sistemas de bocinas, audífonos, o de sonido para presentar sonido o música de alta calidad. Otros dispositivos de presentación incluyen proyectores o dispositivos de proyección utilizados para presentar información para reuniones, o para películas e imágenes de televisión. Otro ejemplo sería el uso de superficies táctiles o dispositivos sensibles, dispositivos de entrada de reconocimiento de voz, lectores de seguridad, y demás que pueden llamarse después para transferir una cantidad significativa de información desde un dispositivo o usuario de sistema con poca "entrada" actual diferente a la táctil o por sonido proveniente del usuario. Además, las estaciones de puertos para computadoras y juegos para automóvil o juegos para escritorio y sujetadores para teléfonos inalámbricos pueden actuar como dispositivos de interfase para los usuarios finales o para otros dispositivos y equipo, y emplear o clientes (dispositivos de entrada o salida tales como ratones) o huéspedes para contribuir a la transferencia de datos, especialmente cuando se encuentran involucradas redes de alta velocidad. Sin embargo, aquellos expertos en la materia reconocerán fácilmente que la presente invención no se encuentra limitada a estos dispositivos, pudiendo haber otros dispositivos en el mercado, y propuestos para su uso, que pretenden proporcionarle a los usuarios finales imágenes y sonido de alta calidad, sea en términos de almacenamiento y transporte o en términos de presentación en la reproducción. La presente invención es útil para incrementar el rendimiento de proceso y transferencia de datos entre diversos elementos o dispositivos para alojar las tasas altas de datos para realizar la experiencia de usuario deseada. El protocolo de MDDI y de señales de comunicaciones inventivo puede utilizarse para simplificar la interconexión entre un procesador huésped, controlador, o componente de circuito (por ejemplo) , y una pantalla dentro de un dispositivo o un alojamiento o estructura de dispositivo (referido como un modo interno) con objeto de reducir el costo o complejidad y requisitos asociados de potencia y de control o restricciones de estas conexiones, y mejorar la confiabilidad, no solo para la conexión con o para elementos, dispositivos, o equipo externo (referido como modo externo) . La tasa de datos de enlace serial agregado en cada par de señales utilizado por esta estructura de interfase puede variar en muchos órdenes de magnitud, lo cual le permite al diseñador de sistemas o dispositivos optimizar fácilmente el costo, la potencia, la complejidad de implementación, y la tasa de actualización de pantalla para una determinada aplicación o propósito. Los atributos de MDDI son independientes de la tecnología de la pantalla u otro dispositivo de presentación (cliente objetivo) . La sincronización de paquetes de datos transferidos mediante la interfase puede ajustarse fácilmente para adaptarse a las idiosincrasias de clientes particulares tales como dispositivos de visualización, sistemas de sonido, memoria y elementos de control, o requisitos de sincronización combinada de sistemas de audio-video. Aunque esto hace posible tener un sistema con un consumo de potencia muy bajo, no es un requisito de los diversos clientes tener memorias temporales de trama con objeto de hacer uso del protocolo de MDDI al menos en un cierto nivel.

B. Tipos de Inferíase La MDDI se contempla por abordar al menos cuatro, y potencialmente más, tipos físicos de interfases algo distintos encontrados en las industrias de las comunicaciones y computadoras . Estos se etiquetan simplemente como el Tipo 1, Tipo 2, Tipo 3, y Tipo 4, aunque pueden aplicarse otras etiquetas o designaciones por aquellos expertos en la materia dependiendo de las aplicaciones especificas utilizadas para la industria con la cual se encuentran relacionadas. Por ejemplo, los sistemas de audio sencillos utilizan menos conexiones que los sistemas de multimedios más complejos, y pueden referenciar características tales como "canales" dif rentemente, etcétera. La interfase de Tipo 1 se configura como una interfase de 6 cables, u otro tipo de conductor o elemento conductor, que es adecuada para teléfonos móviles o inalámbricos, PDAs, juegos electrónicos, y reproductores de medios portátiles, tales como reproductores de CD, o reproductores de MP3, y dispositivos similares o dispositivos utilizados en tipos similares de tecnología de consumidor en electrónica. En una modalidad, una interfase puede configurarse como una interfase de cable 8 (conductor) que sea más adecuada para computadoras portátiles, personales, y de escritorio y dispositivos o aplicaciones similares, que no requiere actualizaciones rápidas de datos y que no tienen un controlador de enlace de MDDI incorporado. Este tipo de interfase también es distinguible por el uso de una interfase adicional de Bus Serial Universal (USB - Universal Serial Bus) de dos cables, la cual es extremadamente útil para alojar los sistemas operativos existentes o el soporte de software encontrado en la mayoría de las computadoras personales. Las interfases de Tipo 2, Tipo 3, y Tipo 4 son adecuadas para clientes o dispositivos de alto rendimiento y utilizan un cableado más complejo y más largo con conductores adicionales de tipo par trenzado a fin de proporcionar la protección adecuada y transferencias con bajas pérdidas para señales de datos . La interfase de Tipo 1 pasa las señales que pueden comprender información de visualización, audio, control, y de señalización limitada, y se utiliza típicamente para clientes móviles o dispositivos cliente que no requieren datos de video de tasa completa de alta resolución. Una interfase de Tipo 1 puede soportar fácilmente la resolución de SVGA a 30 tps más 5.1 audio de canal, y en una configuración minima pudiese utilizar solamente tres pares de cable en total, dos pares para la transmisión de datos y un par para la transferencia de potencia. Este tipo de interfase se encuentra destinada básicamente para dispositivos, tales como dispositivos inalámbricos móviles, donde un huésped de USB típicamente no se encuentra disponible dentro de tal dispositivo para la conexión y transferencia de señales. En esta configuración, el dispositivo inalámbrico móvil es un dispositivo huésped de MDDI, y actúa como el "maestro" que controla el enlace de comunicaciones desde el huésped, lo cual generalmente le envía datos al cliente (tráfico o enlace en avance) para la presentación, visualización o reproducción. En esta inferíase, un huésped permite la recepción de datos de comunicaciones en el huésped desde el cliente (tráfico o enlace inverso) al enviar un comando o tipo de paquete especial al cliente que le permite tomar el bus (enlace) para una duración especificada y le envia datos al huésped como paquetes inversos. Esto se ilustra en la Figura 3, donde un tipo de paquete referido como paquete de encapsulación (descrito a continuación) es utilizado para alojar la transferencia de paquetes inversos por el enlace de transferencia, creando el enlace inverso. El intervalo de tiempo asignado para que el huésped consulte al cliente por los datos es pre-determinado por el huésped, y se basa en los requisitos de cada aplicación especificada. Este tipo de transferencia de datos bidireccional semi-dúplex es especialmente ventajosa cuando no se encuentra disponible un puerto de USB para la transferencia de información o de datos desde el cliente . Las pantallas de alto rendimiento que soportan resoluciones de tipo HDTV o altas resoluciones similares requieren aproximadamente flujos de datos con una tasa de 1.5 Gbps con objeto de soportar el video en movimiento total. La interfase de Tipo 2 soporta tasas altas de datos a transmitir 2 bits en paralelo, el Tipo 3 al transmitir 4 bits en paralelo, y la interfase de Tipo 4 transfiere 8 bits en paralelo. Las interfases de Tipo 2 y de Tipo 3 utilizan el mismo cable y conector que el Tipo 1 pero pueden operar al doble y cuádruple de la tasa de datos para soportar aplicaciones de video con un rendimiento más alto en dispositivos portátiles . Una interfase de Tipo 4 es adecuada para clientes o pantallas con muy alto rendimiento y requiere un cable más largo que contenga señales de datos adicionales de par trenzado. El protocolo utilizado por la MDDI permite que cada huésped de Tipo 1, 2, 3, o 4 se comunique generalmente con cualquier cliente de Tipo 1, 2, 3, o 4 al negociar lo que es la tasa de datos más alta posible que pueda utilizarse. Las capacidades de características disponibles de lo que puede ser referido como el dispositivo menos capaz se utilizan para establecer el rendimiento del enlace. Como regla, incluso para sistemas donde el huésped y el cliente son ambos capaces de utilizar las interfases de Tipo 2, Tipo 3, o Tipo 4, comienzan ambos la operación como una interfase de Tipo 1. El huésped determina después la capacidad del cliente objetivo, y negocia una operación de transferencia o de reconfiguración sea para el modo de Tipo 2, Tipo 3, o Tipo 4, según se apropiado para la aplicación particular. Generalmente es posible que el huésped utilice el protocolo apropiado de enlace-capa (descrito detalladamente a continuación) y baje o reconfigure nuevamente la operación generalmente en cualquier momento a un modo más lento para ahorrar energía o para subir a un modo más rápido a fin de soportar transferencias de velocidades más altas, tales como para un contenido de pantalla de resolución más alta. Por ejemplo, un huésped puede cambiar los tipos de interfase cuando el sistema conmuta de una fuente de energía tal como una batería a una energía de CA, o cuando la fuente de los medios de visualización conmutan a un formato de resolución más baja o más alta, o una combinación de estas u otras condiciones o eventos pueden considerarse como una base para cambiar un tipo de interfase, o modo de transferencia. También es posible que un sistema comunique datos utilizando un modo en una dirección y otro modo en otra dirección. Por ejemplo, podría utilizarse un modo de interfase de Tipo 4 para transferir datos a una pantalla a una tasa alta, mientras que un modo de Tipo 1 es utilizado cuando se transfieren datos a un dispositivo huésped desde dispositivos periféricos tales como un teclado o un dispositivo de señalización. El experto en la materia apreciará que los huéspedes y los clientes pueden comunicar datos salientes a tasas diferentes. Frecuentemente, los usuarios del protocolo de MDDI pueden distinguir entre un modo "externo" y un modo "interno". Un modo externo describe el uso del protocolo e interfase para conectar un huésped en un dispositivo con un cliente fuera de ese dispositivo que se encuentra a aproximadamente 2 metros o algo por el estilo desde el huésped. En esta situación, el huésped también puede enviarle energía al cliente externo de manera que ambos dispositivos puedan operar fácilmente en un ambiente móvil. Un modo interno describe cuándo se conecta el huésped a un cliente ubicado al interior del mismo dispositivo, tal como dentro de un alojamiento o trama de soporte o estructura común de alguna clase. Un ejemplo serian las aplicaciones en un teléfono inalámbrico u otro dispositivo inalámbrico, o una computadora portátil o dispositivo para juegos donde el cliente es una pantalla o manej ador de pantalla, o un dispositivo de entrada tal como un teclado o superficie táctil, o un sistema de sonido, y el huésped es un controlador central, motor de gráficas, o elemento de CPU. Dado que un cliente se encuentra ubicado mucho más cerca del huésped en aplicaciones de modo interno contrariamente a las aplicaciones de modo externo, generalmente no existen requisitos descritos para la conexión de energía al cliente en tales configuraciones.

C. Estructura de Inferíase Fisica La disposición general de un dispositivo o controlador de enlaces para establecer comunicaciones entre los dispositivos huésped y cliente se muestra en las Figuras 4 y 5. En las Figuras 4 y 5, un controlador de enlaces de MDDI 402 y 502 se muestra instalado en un dispositivo huésped 202 y un controlador de enlaces de MDDI 404 y 504 se muestra instalado en un dispositivo cliente 204. Como se mencionaba con anterioridad, el huésped 202 se conecta a un cliente 204 utilizando un canal 406 de comunicaciones bidireccional que comprende una serie de conductores. Como se describió anteriormente, tanto los controladores de enlaces de huésped como de cliente pueden elaborarse como un circuito integrado que utiliza un solo diseño de circuitos que puede establecerse, ajustarse, o programarse para responder sea como un controlador de huésped (manej ador) o un controlador de clientes (receptor) . Esto proporciona menores costos debido a una elaboración a mayor escala de un solo dispositivo de circuito. En la Figura 5, un controlador 502 de enlaces de MDDI se muestra instalado en un dispositivo huésped 202' y un controlador de 504 de enlaces de MDDI se muestra instalado en un dispositivo cliente 204' . Como se mencionaba con anterioridad, el huésped 202' se conecta a un cliente 204' utilizando un canal 506 de comunicación bidireccional que comprende una serie de conductores. Como se describió con anterioridad, tanto los controladores de enlaces de huésped como de cliente pueden elaborarse utilizando un solo diseño de circuito . Las señales pasadas entre un huésped y un cliente, tal como un dispositivo de visualización, por el enlace de MDDI, o los conductores físicos utilizados, también se ilustran en las Figuras 4 y 5. Como se observa en las Figuras 4 y 5, la trayectoria primaria o mecanismo para transferir datos mediante el MDDI utiliza señales de datos etiquetadas como MDDI_Datos0+/- y MDDI_Stb+/~. Cada una de estas son señales de dato de bajo voltaje que se transfieren por un par diferencial de cables en un cable. Solamente existe una transición en cualquiera del par de MDDI_Datos0 o el par de MDDI_Stb para cada bit enviado por la interfase. Este es un mecanismo de transferencia basado en el voltaje y no basado en la corriente, de manera que el consumo de corriente estática es prácticamente cero. El huésped maneja las señales de MDDI_Stb a la pantalla de cliente. Aunque los datos pueden fluir en ambas direcciones en avance e inversa por los pares de MDDI_Datos, es decir, es una trayectoria de transferencia bidireccional, el huésped es el maestro o controlador del enlace de datos. Las trayectorias de señales de MDDI_Datos y MDDI_Stb son operadas en un modo diferencial para maximizar la inmunidad al ruido. La tasa de datos para las señales en estas líneas se determina por la tasa de reloj enviada por el huésped, y es variable en un rango de aproximadamente 1 kbps hasta 400 Mbps o más. La interfase de Tipo 2 contiene un par de datos adicionales o conductores o trayectorias más allá del Tipo 1, referida como MDDI_Datosl+/-. La interfase de Tipo 3 contiene dos pares de datos o trayectorias de señal adicionales a las de la interfase de Tipo 2 referida como MDDI_Datos2+/-, y MDDI_Datos3+/- . La interfase de Tipo 4 contiene cuatro pares de datos o trayectorias de señal más que la interfase de Tipo 3 referida como: MDDI_Datos4+/-, MDDI_Datos5+/-, MDDI_Datos6+/-, y MDDI_Datos7+/-, respectivamente. En cada una de las configuraciones de interfase anteriores, un huésped puede enviarle energía al cliente o pantalla utilizando el par de cables o señales designadas como HOST_Pwr y HOST_Gnd. Como se describe detalladamente a continuación, también puede alojarse la transferencia de energía, si se desea, en algunas configuraciones en los conductores de MDDI Datos4+/-, MDDI Dat?s5+/-, MDDI Datos6+/-, o MDDI_Datos7+/- cuando se utiliza un "Tipo" de inferíase que emplea menos conductores que los que se encuentran disponibles o presentes para los demás modos. Esta transferencia de Energía generalmente se emplea para modos externos, no existiendo generalmente necesidad de modos internos, aunque algunas aplicaciones pueden diferir. En la Tabla I, a continuación, se ilustra un resumen de las señales pasadas entre el huésped y el cliente (pantalla) por el enlace de MDDI para diversos modos, de acuerdo con el tipo de interfase.

Tabla I Observe también que las conexiones de HOST_Pwr/Gnd para transferencia desde el huésped generalmente se proporcionan para modos externos . Las aplicaciones o modos de operación internos generalmente tienen clientes que extraen energía directamente de otros recursos internos, y no utilizan la MDDI para controlar la distribución de energía, como será aparente para el experto en la materia, de manera tal que la distribución no se describe detalladamente aquí. Sin embargo, ciertamente es posible permitir que la energía se distribuya a la MDDI para permitir algunas clases de control de energía, sincronización, o conveniencia de interconexión, por ejemplo, como comprenderá el experto en la materia. El cableado generalmente utilizado para implementar la estructura y operación anteriores se encuentra nominalmente en el orden de 1.5 metros de largo, generalmente 2 metros o menos, y contiene tres pares trenzados de conductores, siendo a su vez cada uno de ellos un cable de trenzado múltiple 30 AWG. Una cubierta de protección metálica envuelve o de otra manera se forma encima de los tres pares trenzados, como un cable de drenaje adicional. Los pares trenzados y el conductor de drenaje de protección terminan en el conector de cliente con la protección conectada a la protección para el cliente, y hay una capa aisladora, que cubre todo el cable, como se conocerla en la materia. Los cables se configuran en pares como HOST_Gnd con HOST_Pwr; MDDI_Stb+ con MDDI_Stb-; MDDI_Datos0+ con MDDI_DatosO-; MDDI_Datosl+ con MDDI_Datosl-; etcétera. Sin embargo, puede utilizarse una variedad de conductores y cableado, como se comprenderla en la materia, para implementar las modalidades de la invención, dependiendo de las aplicaciones específicas. Por ejemplo, pueden utilizarse recubrimientos exteriores más pesados o incluso capas metálicas para proteger el cable en algunas aplicaciones, mientras que las estructuras de tipo listón conductor más plano y más delgado pueden ser más convenientes a otras aplicaciones.

D. Tipos de Datos y Tasas A fin de alcanzar una interfase útil para un rango completo de experiencias y aplicaciones de usuario, la Inferíase Móvil de Datos Digitales (MDDI) proporciona soporte para una variedad de clientes e información de visualización, transductores de audio, teclados, dispositivos de señalamiento, y muchos otros dispositivos de entrada o salida que pudiesen integrarse a o que trabajan conjuntamente a un dispositivo de visualización móvil, junto con la información de control, y combinaciones de los mismos. La MDDI se encuentra diseñada para ser capaz de alojar una variedad de tipos potenciales de flujos de datos que se desplazan entre el huésped y el cliente en cualquiera de las direcciones de enlace en avance o inversa utilizando un número mínimo de cables o conductores. Se soportan tanto flujos (actualizaciones) sincrónicos como asincrónicos. Son posibles muchas combinaciones de tipos de datos siempre y cuando la tasa de datos agregada sea menor que o igual a la tasa de enlace de MDDI deseada máxima, la cual se encuentra limitada por la máxima tasa serial y el número de pares de datos empleados. Estos podrían incluir, pero no se limitan a, aquellos elementos listados en las Tablas II y II expuestas a continuación. Tabla II Tabla III La interfase no es fija sino extensible de manera que pueda soportar la transferencia de una variedad de "tipos" de información que incluye datos definidos por el usuario, para la flexibilidad del futuro sistema. Los ejemplos específicos de datos a alojarse son: video de movimiento total, sea en campos de forma de mapa de bits de pantalla completa o parcial o video comprimido; mapas de bit estáticos a tasas bajas para conservar energía y reducir los costos de implementación; PCM o datos de audio comprimido a una variedad de resoluciones o tasas; posición y selección de dispositivo de señalización, y datos definibles por el usuario para capacidades aún por definirse. Tales datos también pueden transferirse junto con la información de control o estado para detectar la capacidad de dispositivo o establecer otros parámetros. Las modalidades de la invención avanzan la materia para, su uso en transferencias de datos que incluyen, pero que no se limitan a: ver una película (pantalla de video y audio) ; utilizar una computadora personal con visualización personal limitada (pantalla de gráficas, algunas veces combinadas con audio y video) ; reproducir un videojuego en una PC, consola, o dispositivo personal (pantalla de gráficas en movimiento, o audio y video sintéticos) ; "navegar" por la Internet, utilizando dispositivos en forma de videoteléfono (audio y video bidireccional a tasa baja) , una cámara para imágenes digitales fijas, o una cámara de video para capturar imágenes de video digital; utilizar un teléfono, computadora, o PDA con puertos a un proyector a fin de entregar una presentación o con puertos a una estación de puertos de escritorio conectada a un monitor de video, teclado, y ratón; y para la mejora en la productividad o el uso en aplicaciones de entretenimiento con teléfonos celulares, teléfonos inteligentes, o PDAs, incluyendo dispositivos inalámbricos de señalamiento y datos de teclado . La interfase de datos de alta velocidad como se describió con anterioridad se presenta en términos de proporcionar grandes cantidades de datos de tipo A-V por un enlace de comunicaciones o de transferencia que generalmente se configura como un enlace cableado o de tipo cable. Sin embargo, será fácilmente aparente que la estructura de señal, protocolos, sincronización, o mecanismo de transferencia podrían ajustarse para proporcionar un enlace en forma de medios ópticos o inalámbricos, si puede sostener el nivel deseado de transferencia de datos. Las señales de MDDI utilizan un concepto conocido como la Tasa de Trama Común (CFR) para el protocolo o estructura básica de señales. La idea detrás de utilizar una Tasa de Trama Común es proporcionar un impulso de sincronización para flujos de datos sincrónicos simultáneos. Un dispositivo cliente puede utilizar esta tasa de trama común como una referencia de tiempo. Una tasa de CF baja incrementa la eficiencia de canal al disminuir la información complementaria para transmitir la cabecera de sub-trama. Por otra parte, una tasa de CF alta disminuye la latencia, y permite una memoria temporal más pequeña de datos elásticos para muestras de audio. La tasa de CF de la presente interfase inventiva es programable dinámicamente y puede establecerse en uno de muchos valores que son apropiados para los flujos sincrónicos utilizados en una aplicación particular. Es decir, el valor de CF se selecciona para adecuarse mejor a la configuración de cliente y huésped determinada, según se desee. El número de bytes generalmente requerido por sub-trama, que es ajustable o programable, para flujos de datos sincrónicos que son más propensos a ser utilizados con una aplicación, tal como para una micro- pantalla o pantalla de video se muestran en la Tabla IV. Tabla IV Las cuentas fraccionarias de bytes por sub- trama se obtienen fácilmente utilizando una simple estructura contadora programable de M/N. Por ejemplo, se implementa una cuenta de 26-2/3 bytes por CF al transferir 2 tramas de 27 bytes cada una seguida por una sub-trama de 26 bytes. Puede seleccionarse una tasa de CF más baja para producir un número entero de bytes por sub-trama. Sin embargo, hablando en términos generales, implementar un simple contador de M/N en hardware debe requerir menos área dentro de un chip de circuito integrado o módulo electrónico utilizado para implementar parte o todas las modalidades de la invención que necesita el área para una memoria temporal más grande de FIFO (first input first output -primero en entrar primero en salir) de muestra de audio. Una aplicación a manera de ejemplo que ilustra el impacto de diferentes tasas de transferencia de datos y tipos de datos es un sistema Karaoke. Por Karaoke se entiende un sistema donde un usuario final, o usuarios, canta (n) solo con un programa de video musical. Las letras de la canción se despliegan en alguna parte, típicamente en la parte inferior de una pantalla de manera que el usuario sepa las palabras a cantar, y a grandes rasgos la sincronización de la canción. Esta aplicación requiere una pantalla de video con actualizaciones infrecuentes de gráficas, y mezclar la voz o voces del usuario, con un flujo de audio estéreo. Si no supone una tasa de trama común de 300 Hz, entonces cada sub-trama consistirá de: 92,160 bytes de contenido de video y 588 bytes de contenido de audio (con base en 147 muestras de 16 bits, en estéreo) por el enlace en avance al dispositivo de pantalla de cliente, y un promedio de 26.67 (26-2/3) bytes de voz son enviados de regreso desde un micrófono a la máquina móvil de Karaoke. Los paquetes asincrónicos se envían entre el huésped y la pantalla, posiblemente instalados sobre la cabeza. Esta incluye a lo sumo 768 bytes de datos de gráficas (una altura de un cuarto de pantalla) , y menos de aproximadamente 200 bytes (varios) para comandos misceláneos de control y de estado . La Tabla V muestra cómo se asignan los datos en una sub-trama para el ejemplo del Karaoke. La tasa total utilizada se selecciona para ser aproximadamente de 279 Mbps. Una tasa ligeramente mayor de 280 Mbps permite aproximadamente otros 400 bytes de datos por sub-trama a transferirse lo cual permite el uso de mensajes ocasionales de control y estado.

Tabla V III. (Continuación) Arquitectura de Sistemas de Inferíase de Datos Digitales de Tasa Alta E. Capa de Enlace Los datos transferidos utilizando señales de datos seriales de alta velocidad de MDDI consistente en un flujo de paquetes multiplexados en el tiempo que se enlazan uno tras otro. Incluso cuando un dispositivo de transmisión no tiene datos por enviar, generalmente un controlador de enlaces de MDDI envia automáticamente paquetes de relleno, manteniendo asi un flujo de paquetes. El uso de una simple estructura de paquetes asegura una sincronización confiable sincrónica para las señales o flujos de datos de audio y video. Los grupos de paquetes se encuentran contenidos dentro de elementos o estructuras de señales referidas como sub-tramas, y los grupos de sub-tramas se encuentran contenidos en los elementos o estructuras de señal referidos como trama de medios. Una sub-trama contiene uno o más paquetes, dependiendo de su tamaño respectivo y buzos de transferencia de datos y una trama de medios contiene una o más sub-tramas. La sub-trama más grande proporcionada por el protocolo empleado por las modalidades aqui presentadas es del orden de 232-l o 4,294,967,295 bytes, y el tamaño de trama de medios más grandes se vuelve después del orden de 216-1 o 65,535 sub-tramas. Un paquete de cabecera de sub-trama especial contiene un identificar único que aparece al inicio de cada sub-trama, como se describe a continuación. Ese identificador se utiliza también para adquirir la sincronización de trama en el dispositivo cliente cuando se inicia la comunicación entre el huésped y el cliente. La adquisición de sincronización de enlace se describe más detalladamente a continuación. Típicamente, una pantalla de visualización es actualizada una vez por trama de medios cuando se está visualizando vídeo de movimiento total. La tasa de trama de visualización es la misma que la tasa de trama de medios. El protocolo de las soporta el video de movimiento total en una pantalla completa, o sólo una pequeña región de contenido de vídeo de movimiento total rodeado por una imagen estática, dependiendo de la aplicación deseada. En algunas aplicaciones móviles con bajo consumo de energía, tales como visualización de páginas web o correo electrónico, la pantalla de visualización solamente puede necesitar actualizarse ocasionalmente. En esas situaciones, es ventajoso transmitir una sola sub-trama y después a pagar o desactivar el enlace a fin de minimizar el consumo de energía. La interfase soporta también efectos tales como visión estéreo, y maneja primitivas gráficas. Las sub-tramas le permiten a un sistema habilitar la transmisión de paquetes de alta prioridad sobre una base periódica. Esto permite que coexistan flujos sincrónicos simultáneos con una cantidad minima de memoria temporal de datos. Esta es una modalidad ventajosa que se le proporciona al proceso de visualización, que le permite a múltiples flujos de datos (comunicación de alta velocidad de vídeo, voz, control, estado, datos de dispositivo de señalización, etc.) a fin de compartir esencialmente un canal común. Transfiere información utilizando relativamente pocas señales. También permite que existan acciones especificas de tecnología de visualización, tales como impulsos de sincronía horizontal y limpiar intervalos para un monitor de CRT, o para otras acciones especificas de tecnología de cliente.

F. Controlador de Enlaces El controlador de enlaces de MDDI mostraron las Figuras 4 y 5 se elabora o ensambla para ser una implementación completamente digital con excepción de los receptores de linea diferencial de los cuales son utilizados para recibir datos de MDDI y señales estroboscópicas . Sin embargo, incluso los manej adores y receptores de linea diferencial pueden implementarse en los mismos circuitos integrales digitales con el controlador de enlaces, tal como cuando se fabrica un IC (Integrated Circuit - Circuito Integrado) de tipo CMOS (Complementary Metal Oxide Semiconductor -Semiconductor de Óxido Metálico Complementario) . No se requiere ninguna función análoga o circuitos de bloqueo de fase (PLLs - phase lock loops) para la recuperación de bits o implementar el hardware para el controlador de enlaces . Los controladores de enlaces de cuesta y cliente contienen funciones muy similares, con excepción de la interfase de cliente la cual contiene una máquina de estados para la sincronización de enlaces. Por lo tanto, las modalidades de la invención permiten la ventaja práctica de ser capaces de crear un solo diseño o circuito controlador que pueda configurarse sea como huésped o como cliente, lo cual puede reducir los costos de fabricación para los controladores de enlaces, en su conjunto.

IV. Protocolo de Enlace de Inferíase A. Estructura de trama El protocolo de señales o estructura de tramas utilizada para implementar la comunicación de enlace en avance para la transferencia de paquetes se ilustra en la Figura 6. Como se muestra en la Figura 6, la información o datos digitales se agrupan en elementos conocidos como paquetes. A su vez, múltiples paquetes se agrupan conjuntamente para formar lo que se conoce como una "sub-tramas", y a su vez múltiples sub-tramas se agrupan conjuntamente para formar una trama de "medios". Para controlar la formación de tramas y transferencia de sub-tramas, cada sub-trama comienza con un paquete predefinido especialmente referido como Paquete de Cabecera de Sub-Trama (SHP - Sub-frame Header Packet) . El dispositivo huésped selecciona la tasa de datos a utilizarse para una determinada transferencia. Esta tasa puede ser cambiada dinámicamente por el dispositivo huésped con base tanto en la capacidad de transferencia máxima del huésped, como en los datos que se recuperan provenientes de una fuente por revueltas, y la capacidad máxima del cliente, u otro dispositivo al que se estén transfiriendo los datos. Un dispositivo cliente recipiente diseñado para, o capaz de, trabajar con la MDDI o el protocolo de señales inventivo es capaz de ser consultado por el huésped para determinar la tasa de transferencia de datos máxima, o máxima actual que puede utilizar, o puede utilizarse una tasa mínima más lenta por default, así como también los tipos de datos y características utilizables soportados. Esta información podría transferirse utilizando un Paquete de Capacidad de Cliente (CCP - Client Capability Packet) , como se describe detalladamente a continuación. El dispositivo de pantalla de cliente es capaz de transferir datos o comunicarse con otros dispositivos utilizando la interfase a una tasa de datos mínima preseleccionada o dentro de un rango de tasa de datos minima, y el huésped realizará una consulta utilizando una tasa de datos dentro de este rango a fin de determinar las capacidades totales de los dispositivos cliente. Otra información de estado que define la naturaleza de las capacidades de tasa de trama de vídeo y mapa de bits del cliente pueden transferirse en un paquete de estado al huésped de manera que el huésped pueda configurar la interfase para que sea tan eficiente u óptima como práctica, o como se desee dentro de cualesquier restricciones del sistema. El huésped envia paquetes de relleno cuando no hay (más) paquetes de datos por transferirse en la presente sub-trama, o cuando huésped no puede transferir a una tasa suficiente para mantener el ritmo con la tasa de transmisión de datos seleccionada para el enlace en avance. Dado que cada sub-trama comienza con una paquete de cabecera de sub-trama, el fin de la sub-trama anterior contiene un paquete (muy probablemente un paquete de relleno) que llena exactamente la sub-trama anterior. En el caso de falta de espacio para paquetes que llevan datos per se, muy probablemente un paquete de relleno será el último paquete en una sub-trama, o al final de una siguiente sub-trama anterior y antes de un paquete de cabecera de sub-trama. La tarea de las operaciones de control en un dispositivo huésped es asegurar que existe suficiente espacio en una sub-trama para cada paquete por transmitirse en esa sub-trama. Al mismo tiempo, una vez que un dispositivo huésped inicia el envío de un paquete de datos, el huésped debe ser capaz de completar exitosamente un paquete de ese tamaño en una trama sin incurrir en una condición de sub-ejecución de datos. En un aspecto de las modalidades, la transmisión de sub-trama tiene dos modos. Un modo es un modo de sub-trama periódico, o épocas de sincronización periódicas, utilizadas para transmitir flujos de audio y vídeo en vivo. En este modo, el largo del sub-trama se define por ser diferente a cero. El segundo modo es un modo asincrónico o no periódico en el cual las tramas son utilizados para proporcionar datos de mapa de bits a un cliente cuando no se encuentra disponible ninguna información. Este modo se definen al establecer el largo del sub-trama en cero en el Paquete de Cabecera de Sub-Trama. Cuando se utiliza el modo periódico, la recepción de paquete de sub-trama puede comenzar cuando el cliente se ha sincronizado con la estructura de tramas de enlace en avance. Esto corresponde con los estados "en sincronía" definidos de acuerdo con el diagrama de estados descrito a continuación con respecto a la Figura 49 o la Figura 63. En el modo de sub-trama no periódica asincrónica, la recepción comienza después de que se recibe el primer paquete de Cabecera de Sub-Trama.

B. Estructura de Paquete General A continuación se presentan el formato por estructura de paquetes utilizados para formular la comunicación o protocolo de señales, un método o medio para transferir datos, implementados por las modalidades, teniendo en mente que la interfase es extensible y que pueden agregarse estructuras de paquete adicionales como se desee. Los paquetes de etiquetan como, o se dividen en, diferentes "tipos de paquete" en términos de su función en la interfase, es decir, comandos, información, valor, o datos que transfieren poco los cuales se encuentran asociados. Por lo tanto, cada tipo de paquete denota una estructura de paquetes predefinida para un determinado paquete que se utiliza para manipular los paquetes y datos que son transferidos. Como será fácilmente aparente, los paquetes pueden tener largos preseleccionados o tener largos variables o que cambian dinámicamente dependiendo de sus respectivas funciones. Los paquetes también podrían soportar nombres diferentes, aunque aún se lleva a cabo la misma función, como puede ocurrir cuando los protocolos cambian durante su aceptación en norma. Los bytes o valores de bytes utilizados en los diversos paquetes se configuran como enteros sin signo de bits múltiples (8 o 16 bits) . En las Tablas VI-1 a VI- se muestra un resumen de los paquetes que se emplean junto con sus designaciones de "tipo", listadas en orden de tipo. Cada tabla representa un "tipo" general de paquete dentro de la estructura de paquete general para facilidad de ilustración y comprensión. No existen limitantes u otros impactos involucrados o expresados para la invención por estos agrupamientos, y los paquetes pueden organizarse en muchas otras maneras según se desee. También se observa la dirección en la cual la transferencia de un paquete se considera válida.

Tabla VI-1 Paquetes de Control de Enlace Tabla VI-2 Paquetes de Flujo de Medios Básicos Tabla VI-3 Paquetes de Estado de Cliente y Control 6 - 7 - Tabla VI-4 Paquetes de Visualización y Gráficas Avanzadas Algo que queda claro a partir de otras descripciones con este texto es que mientras el Paquete de Encapsulación Inversa, el Paquete de Capacidad de Cliente, y el Paquete de Solicitud y Estado de Cliente son considerados cada uno de ellos muy importantes para, o incluso requeridos en muchas modalidades de interfases de comunicación, para la operación en Modo Externo, mientras que pueden ser y más propensos a ser considerados opcionales para la operación en Modo Interno. Esto crea otro tipo de protocolo de MDDI del cual permite la comunicación de datos a velocidades muy altas con un conjunto reducido de paquetes de comunicaciones, y la simplificación correspondiente del control y la sincronización. Los paquetes tienen una estructura básica común o conjunto general de campos mínimos que comprende un campo de Largo de Paquete, un campo de Tipo de Paquete, campo (s) de Bytes de Datos, y un campo de CRC, el cual se ilustra en la Figura 7. Como se muestra la Figura 7, el campo Largo de Paquete contiene información, en forma de un valor de bit múltiple o de byte, que especifica el número total de bits en el paquete, un largo entre el campo de largo de paquete y el campo de CRC. En una modalidad, el campo del largo de paquete contiene un entero sin signo con un ancho de 16 bits o de 2 bytes, que especifica el largo de paquete. El campo de Tipo de Paquete es otro campo de bit múltiple que designa el tipo de información que se encuentra contenida en el paquete. En una modalidad a manera de ejemplo, este es un valor con un ancho de 16 bits o de 2 bytes, en forma de un entero signo de 16 bits, y especifica tales tipos de datos como capacidades de visualización, transferencia, flujos de audio o video, estado, etc. Un tercer campo es el campo de Bytes de Datos, el cual contiene los bits o datos que se transfieren o envían entre los dispositivos huésped y cliente como parte de ese paquete. El formato de los datos se define específicamente para cada tipo de paquete de acuerdo con el tipo especifico de datos que se transfieren, y pueden estar separados en una serie de campos adicionales, cada uno de ellos con sus propios requisitos de formato. Es decir, cada tipo de paquete tendrá un formato definido para esta porción o campo. El último campo es el campo de CRC el cual contiene los resultados de una verificación de redundancia cíclica de 16 bits calculadas sobre los campos de Bytes de Datos, Tipo de Paquete, y Largo de Paquete, el cual se utiliza para confirmar la integridad de la información en el paquete. En otras palabras, se calcula sobre todo el paquete excepto para el mismo campo de CRC. El cliente generalmente mantiene una cuenta total de los errores de CRC detectados, y reportes frecuentes de de regreso al huésped en el Paquete de Solicitud y Estado de Cliente (ver a continuación) . Generalmente, estos hechos de campo y la organización se encuentran diseñados para mantener cantos de 2 bytes alineados en un limite de bytes par, y campos de 4 de bytes en límites de 4 bytes. Esto le permite a las estructuras de paquete construirse fácilmente en un espacio de memoria principal de, o asociarse con, un huésped y un cliente sin violar las reglas de alineación de tipo de datos encontradas para la mayoría de o los procesadores o circuitos de control utilizados típicamente. Durante la transferencia de los paquetes, los campos se transmiten comenzando con el primer Bit Menos Significativo (LSB - Least Significant Bit) y terminando con el último Bit Más Significativo (MSB -Most Significant Bit) transmitido. Los parámetros que tienen más de un byte de largo se transmiten utilizando el primer byte menos significativo, lo cual da como resultado el mismo patrón de transmisión de bits utilizado para un parámetro mayor a los 8 bits del largo, como se utiliza para un parámetro más corto cuando se transmite primeramente el LSB. Los campos de datos de cada paquete generalmente se transmite en el orden en que se definen en las secciones subsecuentes detalladas a continuación, transmitiéndose primeramente el primer campo listado, y transmitiéndose al último el último campo descrito. Los datos por la trayectoria de señales MDDI_DatosO se alinean con el bit ?0' de los bytes transmitidos por la interfase en cualquiera de los modos, Tipo 1, Tipo 2, Tipo 3, o Tipo 4. Cuando se manipulan datos para pantallas, los datos para arreglos de pixeles se transmiten por hileras primeramente, después por columnas, como se hace tradicionalmente en la electrónica. En otras palabras, todos los píxeles que aparecen en la misma hilera en un mapa de bits se transmiten en orden transmitiéndose primeramente el píxel ubicado en la extrema izquierda y transmitiéndose en último término el píxel ubicado en la extrema derecha. Después de que se transmite el pixel ubicado en la extrema derecha de una hilera entonces el siguiente pixel en la secuencia es el píxel ubicado en la extrema izquierda de la siguiente hilera. Las hileras de pixeles generalmente se transmiten en orden de arriba hacia abajo para la mayoría de pantallas, aunque pueden alojarse otras configuraciones según se requiera. Además, para manejar mapas de bits, el planteamiento convencional, el cual se sigue en la presente, es definir un punto de referencia al etiquetar la esquina superior izquierda de un mapa de bits como la ubicación o variación "0, O". Las coordenadas X y Y utilizadas para definir o determinar una posición en el mapa de bits incrementan su valor a medida que uno se aproxima a la derecha y parte inferior del mapa de bits, respectivamente. La primera hilera y la primera columna (esquina superior izquierda de una imagen) comienzan con un valor índice de cero. La magnitud de la coordenada X se incrementa hacia el costado derecho de la imagen, y la magnitud de la coordenada Y se incrementa hacia la parte inferior de la imagen a medida que es visualizada por el usuario de la pantalla. Una ventana de pantalla es la porción visible de un mapa de bits, la porción de los píxeles en el mapa de bits que puede ser observada por el usuario en el medio de visualización fisica. Frecuentemente es el caso que la entrada de visualización y el mapa de bits son del mismo tamaño. La esquina superior y quiera de una ventana de pantalla siempre visualiza la ubicación de mapa de bits "0, 0". El ancho de la ventana de pantalla corresponde al eje X del mapa de bits, y el Ancho de Ventana de Pantalla para esta modalidad es menor que o igual al ancho del mapa de bits correspondiente. La altura de la ventana corresponde al eje Y del mapa de bits, y la Altura de Ventana de Pantalla para esta modalidad es menor que o igual a la altura del mapa de bits correspondiente. La misma ventana de pantalla no es direccionable en el protocolo debido a que solamente se define como la porción visible de un mapa de bits. La relación entre un mapa de bits y las ventanas de visualización es conocida en computación, electrónica, comunicaciones de Internet, y otras técnicas relacionadas con la electrónica. Por lo tanto, no se proporciona en la presente ninguna descripción o ilustración de estos principios.

C. Definiciones de Paquete 1. Paquete de Cabecera de Sub-Txama • El paquete de Cabecera de Sub-Trama es el primer paquete de cada sub-trama, y tiene una estructura básica como se ilustra en la Figura 8. El Paquete de Cabecera de Sub-Trama se utiliza para la sincronización de huésped-cliente, cada huésped debe ser capaz de generar este paquete, aunque cada cliente debe ser capaz de recibir e interpretar este paquete. Como puede observarse en una modalidad en la Figura 8, este tipo de paquete se encuentra estructurado para tener los campos Largo de Paquete, Tipo de Paquete, de Palabra Única, Reservado 1, Largo de Sub-Trama, Versión de Protocolo, Cuenta de Sub-Tramas y Cuenta de Trama de Medios, generalmente en ese orden. En una modalidad, este tipo de paquete generalmente se identifica como un paquete de Tipo 15359 (hexadecimal 0x3bff) y utiliza un largo fijo preseleccionados de 20 bytes, sin incluir el campo de largo de paquete. El campo de Tipo de Paquete y el campo de Palabra Única utilizan cada uno de ellos un valor de 2 bytes (entero sin signo de 16 bits) . La combinación de 4 bytes de estos dos campos forma conjuntamente una palabra única de 32 bits con una buena auto-correlación. En una modalidad, la palabra única actual es 0x005a3bff, donde los 16 bits menores se transmiten primeramente como el Tipo de Paquete, y después se transmiten los 16 bits más significativos. El campo Reservado 1 contiene 2 bytes que son espacio reservado para uso posterior, y generalmente se encuentra configurado en este punto con todos los bits establecidos en cero. Un propósito de este campo es ocasionar que los campos subsecuentes de 2 bytes se alineen en una dirección de palabra de 16 bits y ocasiona que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits. El byte menos significativo se reserva para indicar si un huésped es o no capaz de direccionar múltiples dispositivos cliente. Un valor de cero para este byte se reserva para indicar que el huésped es capaz de operar solamente con un solo dispositivo cliente. El campo Largo de Sub-Trama contiene 4 bytes de información, o valores, que especifican el número de bytes por sub-trama. En una modalidad, el largo de este campo puede ser igual a cero para indicar que solamente se transmitirá una sub-trama por el huésped antes de que se desconecte el enlace para un estado inactivo. El valor en este campo puede cambiarse dinámicamente "al vuelo" cuando se realice la transición de una sub-trama a la siguiente. Esta capacidad es útil con objeto de realizar ajustes menores de sincronización en los impulsos de sincronía para alojar flujos de datos sincrónicos. Si la CRC del paquete de Cabecera de Sub-Trama no es válido, entonces el controlador de enlaces debe utilizar el largo de sub-trama del paquete de cabecera de sub-trama bueno anterior para calcular el largo de la sub-trama actual. El campo de Versión de Protocolo contiene 2 byte que especifican la adhesión de protocolo utilizada por el huésped. El campo de Versión de Protocolo puede establecerse en "0" para especificar la primera versión o versión actual del protocolo que se está utilizando. Este valor cambiarán con el transcurso del tiempo a medida que se crean nuevas versiones, y ya se está actualizando a un valor de "1" para algunos campos de versión. Los valores de versión probablemente o generalmente seguirán un número de versión actual para un documento de normas aprobadas el cual cubre interfases tales como MDDI, como es conocido. El campo Cuenta de Sub-Tramas contiene 2 bytes que especifican un número de secuencia que indique el número de sub-trama que se han transmitido desde el inicio de la trama de medios. La primera sub-trama de la trama de medios tiene una Cuenta de Sub-Tramas de cero. La última sub-trama de la trama de medios tiene un valor de n-l, donde n es el número de sub-tramas por trama de medios. El valor del campo Cuenta de Sub-Tramas es igual a la Cuenta de Sub-Tramas enviado en el paquete anterior de Sub-Tramas más 1, excepto para una primera sub-trama de una trama de medios que tendrá una cuenta de cero. Observe que si el Largo de Sub-Trama se establece igual a cero (indicando una sub-trama no periódica) entonces la Cuenta de Sub-Tramas también se establece igual a cero. El campo Cuenta de trama de Medios contiene 4 bytes (entero sin signo de 32 bits) que especifican un número de secuencia que indique el número de trama de medios que se han transmitido desde el inicio del presente elemento del medios o datos que se transfieren. La primera trama de medios de un elemento de medios tiene una Cuenta de trama de Medios en cero. La Cuenta de trama de Medios se incrementa justo antes de la primera sub-trama de cada trama de medios y se regresa a cero después de que se utiliza la máxima Cuenta de trama de Medios (por ejemplo, número de trama de medios 23-l= 4,294,967,295). El valor de Cuenta de trama de Medios puede ser restablecido generalmente en cualquier momento por el huésped para adecuarse a las necesidades de una aplicación final. 2. Paquete de Relleno Un paquete de relleno es un paquete que se transfiere a, o desde, un dispositivo cliente cuando no se encuentra disponible ninguna otra información para ser enviada sea por el enlace en avance o el enlace inverso. Se recomienda que los paquetes de relleno tengan un largo mínimo con objeto de permitir una máxima flexibilidad al enviar otros paquetes cuando así se requiera. En el extremo de una sub-trama o un paquete de encapsulación de enlace inverso (de a continuación) , un controlador de enlace establece el tamaño del paquete de relleno a fin de rellenar el espacio restante para mantener la integridad del paquete. El Paquete de Relleno es útil para mantener la sincronización en el enlace cuando el huésped o cliente no tienen información para enviar o intercambiar. Cada huésped y cliente necesita ser capaz de enviar y recibir este paquete para hacer uso efectivo de la interfase. En la Figura 9 se muestra una modalidad a manera de ejemplo del formato y contenido de un paquete de relleno. Como se muestra en la Figura 9, este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, Bytes de Relleno, y CRC. En una modalidad, este tipo de paquete generalmente se identifica como Tipo 0, el Cuáles indicaron en el campo de Tipo de 2 bytes. Los bits o bytes en el campo Bytes de Relleno comprenden un número variable de valores de bits de sólo ceros para permitirle al paquete de relleno tener el largo deseado. El paquete de relleno más pequeño no contiene bytes en este campo. Es decir, el paquete consiste solamente del largo de paquete, tipo de paquete, y CRC, y en una modalidad elijan un largo fijo preseleccionado de 6 bytes o un valor de Largo de Paquete de 4. El valor de CRC se determina para todos los bytes en el paquete que incluye el Largo de Paquete, el cual puede excluirse en algunos otros tipos de paquete. 3. Paquete de Fl ujo de Vídeo Los Paquetes de Flujo de Video llevan datos de vídeo para actualizar las regiones típicamente rectangulares de un dispositivo de visualización. El tamaño de esta región puede ser tan pequeño como un solo pixel o tan grande como toda la pantalla. Puede haber un número prácticamente ilimitado de flujos visualizado simultáneamente, limitado por los recursos del sistema, debido a que todo el contexto requerido para visualizar un flujo se encuentra contenido dentro del Paquete de Flujo de Vídeo. El formato de una modalidad de un Paquete de Flujo de Video (Descriptor el Formato de Datos de Video) se muestra en la Figura 10. Como se observa en la Figura 10, en una modalidad, este tipo de paquete se estructura para tener los campos de Largo de Paquete (2 bytes) , Tipo de Paquete, ID de bCliente, Descriptor de Datos de Vídeo, Atributos de Visualización de Píxel, Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, Inicio X y Y, Cuenta de Píxel, CRC de Parámetro, Datos de Pixel, y CRC de Datos de Píxel. Este tipo de paquete generalmente se identifica como uno de Tipo 16, el cual se indican en el campo de Tipo de 2 bytes. En una modalidad, un cliente indica una capacidad para recibir un Paquete de Flujo de Video que utiliza los campos RGB, Monocromático, y Capacidad Y Cr Cb del Paquete de Capacidad de Cliente. En una modalidad, el campo de ID de bCliente contiene 2 bytes de información que se reservan para un ID de Cliente. Dado que este es un protocolo de comunicaciones recientemente desarrollado los IDs de clientes actuales aún no se conocen o no son suficientemente comunicables. Por lo tanto, los bits en este campo generalmente se establecen iguales a cero hasta que se conozcan tales valores de ID, momento en el cual pueden insertarse o utilizarse los valores de ID, como será aparente para aquellos expertos en la materia. El mismo proceso generalmente será verdadero para los campos de ID de cliente descritos a continuación. El concepto de trama común descrito con anterioridad es una manera eficaz para minimizar el tamaño de memoria temporal de audio y disminuir la latencia. Sin embargo, para datos de video puede ser necesario dispersar los pixeles de una trama de video en múltiples Paquetes de Flujo de Video dentro de una trama de medios. También es muy probable que los pixeles en un solo Paquete de Flujo de Video no correspondan exactamente a una ventana rectangular perfecta en la pantalla. Para la tasa de trama de vídeo a manera de ejemplo de 30 tramas por segundo, existen 300 sub-tramas por segundo, lo cual da como resultado 10 sub-tramas por trama de medios. Si existen 480 hileras de pixeles en cada trama, cada Paquete de Flujo de Video en cada sub-trama contendrá 48 hileras de pixeles. En otras situaciones, el Paquete de Flujo de Video pudiese no contener un número entero de hileras de píxeles. Esto es verdadero para otros tamaños de trama de video donde el número de sub-tramas por trama de medios no se divide uniformemente en el número de hileras (también conocido como lineas de video) por trama de video. Para una operación eficaz, cada Paquete de Flujo de Vídeo generalmente debe contener un número entero de píxeles, a pesar de que pudiese no contener un número entero de hileras de píxeles. Esto es importante si los pixeles tienen más de un byte cada uno, o si se encuentran en un formato empaquetado como se muestra en la Figura 12. El formato y contenido empleados para realizar la operación de un campo de Descriptor de Datos de Vídeo a manera de ejemplo, como se mencionó con anterioridad, se muestran en las Figuras 11A-11E. En las Figuras 11A-11E, el campo de Descriptor de Formato de Datos de Video contiene 2 bytes en forma de un entero sin signo de 16 bits que especifica el formato de cada pixel en el campo Datos de Píxel en el presente flujo en el presente paquete. Es posible que diferentes paquetes de Flujo de Vídeo puedan utilizar diferentes formatos de datos de píxel, es decir, utilizar un valor diferente en el Descriptor de Formato de Datos de Vídeo, y similarmente, un flujo (región de la pantalla) puede cambiar su formato de datos al vuelo. El formato de datos de píxel debe obedecer al menos uno de los formatos válidos para el cliente como se define en el Paquete de Capacidad de Cliente. El Descriptor de Formato de Datos de Video define el formato de píxel del presente paquete lo cual no implica que un formato constante continúe siendo utilizado durante la vida útil de un flujo de video particular en particular. Las Figuras HA a 11D ilustran cómo se codifica el Descriptor de Formato de Datos de Vídeo. Como se utiliza en estas figuras, y en esta modalidad, cuando los bits [15: 13] son iguales a "000", como se muestra en la Figura 11A, los datos de video consisten en un arreglo de píxeles monocromáticos donde el número de bits por píxel se define por los bits 3 a 0 de la palabra de Descriptor de Formato de Datos de Vídeo. Los Bits 11 a 4 generalmente se reservan para su uso posterior o futuras aplicaciones y se establecen en cero en esta situación. En cambio, cuando los bits [15:13] son iguales a los valores "001", como se muestra en la Figura 11B, los datos de vídeo consisten en un arreglo de píxeles de colores que especifican cada uno de ellos un color en un mapa de colores (paleta) . En esta situación, los bits 5 a 0 de la palabra de Descriptor de Formato de Datos de Vídeo definen el número de bits por píxel, y los bits 11 a 6 generalmente se reservan para su uso posterior o futuras aplicaciones y se establecen iguales a cero. En cambio, cuando los bits [15:13] son iguales a los valores de "010", como se muestra en la Figura 11C, entonces los datos de vídeo consisten en un arreglo de pixeles de color donde el número de bits por pixel de rojo se define por los bits 11 a 8, el número de bits por píxel de verde se define por los bits 7 a 4, y el número de bits por pixel de azul se define por los bits 3 a 0. En esta situación, el número total de bits en cada pixel es la suma del número de bits utilizados para rojo, verde, y azul. Sin embargo, cuando los bits [15: 13] son más bien iguales a los valores o cadena de "011", como se muestra en la Figura 11D, entonces los datos de video consisten en un arreglo de datos de video en el formato YCbCr 4:2:2 con información de luminancia y crominancia, donde el número de bits por pixel de luminancia (Y) se define por los bits 11 a 8, el número del bits del componente de Cb se define por los bits 7 a 4, y el número de bits del componente de Cr se define por los bits 3 a 0. El número total de bits en cada pixel es la suma del número de bits utilizados para rojo, verde, y azul. Los componentes de Cb y Cr se envían a la mitad de la tasa que Y. Además, las muestras de video en la porción de Datos de Pixel de este paquete se organicen como se explica a continuación: Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3, ... donde Cbn y Crn se encuentran asociados con Yn y Yn+1, y Cbn+2 y Crn+2 se encuentran asociados con Yn+2 y Yn+3, y asi sucesivamente. Yn, Yn+1, Yn+2, y Yn+3 son valores de luminancia de cuatro pixel consecutivos en una sola hilera de izquierda a derecha. Si hay un número impar de píxeles en una hilera (Borde Derecho X - Borde Izquierdo X + 1) en la ventana referida por el Paquete de Flujo de Vídeo entonces el valor Y correspondiente al último pixel en cada hilera será seguido por el valor de Cb del primer píxel de la siguiente hilera, y el valor de Cr no se envia para el último píxel en la hilera. Se recomienda que las ventanas que utilizan el formato de Y Cb Cr tengan un ancho que sea un número par de pixeles. Los Datos de Pixel en un paquete de contener un número par de píxeles. Puede contener un número par o impar de píxeles en caso de que el último píxel de los Datos de Píxel correspondan al último píxel de una hilera en la ventana especificada en la cabecera de Paquete de Flujo de Video, es decir, cuando la ubicación de X el último píxel en los Datos de Píxel sea igual al Borde Derecho X. En cambio, cuando los bits [15:13] son iguales a los valores de "100", entonces los datos de vídeo consisten en un arreglo de pixeles de Bayer donde el número de bits por píxel se define por los bits 3 a 0 de la palabra de Descriptor de Formato de Datos de Vídeo. El Patrón de Grupo de Píxel se define por los bits 5 y 4 como se muestra en la Figura HE. El orden de los datos de pixel puede ser horizontal o vertical, y los píxeles en las hileras o columnas pueden enviarse en avance o en retroceso y se define por los bits 8 a 6. Los bits 11 a 9 deben establecerse en cero. El grupo de cuatro píxeles en el grupo de píxel en el formato Bayer se asemeja a lo que frecuentemente es referido como un solo pixel en algunas tecnologías de visualización. Sin embargo, un píxel en el formato Bayer es solamente uno de los cuatro píxeles de colores del patrón de mosaico de grupo de píxel.

Para los cinco formatos mostrados en las figuras, el Bit 12, el cual es designado como "P", especifica si las muestras de Datos de Paquetes se encuentran empaquetadas o no, o si son datos de píxel alineados por byte. Un valor de "0" en este campo indica que cada píxel en el campo de Datos de Píxel se encuentra alineado por bytes con un limite de byte de MDDI. Un valor de "1" indica que cada pixel y cada color dentro de cada pixel en los Datos de Pixel se empaqueta contra el pixel o color anterior dentro de un píxel sin dejar bits sin utilizar. La diferencia entre el formato de datos Alineados por Byte y de Pixel Empaquetado se muestra más detalladamente en la Figura 12, donde uno puede ver claramente que los datos alineados por byte pueden dejar porciones no utilizadas de la sub-trama de datos, contrariamente al formato de pixel empaquetado que no lo hace asi . El primer pixel en el primer paquete de flujo de video de una trama de medios para una ventana de pantalla en particular irá en la esquina superior izquierda de la ventana de flujo definida por un Borde Izquierdo X y un Borde Superior Y, y el siguiente pixel recibido se coloca en la siguiente ubicación de píxel en la misma hilera, y así sucesivamente. En este primer paquete de una trama de medios, el valor inicial de X normalmente será igual a Borde Izquierdo X, y el valor inicial de Y normalmente será igual a Borde Superior Y. En los paquetes subsecuentes correspondientes a la misma ventana de pantalla, los valores iniciales de X y y normalmente se establecerán en la ubicación del pixel en la ventana de pantalla que seguirla normalmente después del último pixel enviado en el Paquete de Flujo de Vídeo que se transmitió en la sub-trama anterior. 4. Paquete de Fl uj o de Audio Los paquetes de flujo de audio llevan datos de audio para ser reproducidos por el sistema de audio del cliente, o para un dispositivo de presentación de audio independiente. Puede asignarse diferentes flujos de datos de audio para canales de audio separados en un sistema de sonido, por ejemplo: frontal izquierdo, frontal derecho, central, posterior izquierdo, y posterior derecho, dependiendo del tipo de sistema de audio que se utiliza. Se proporciona un complemento completo de canales de audio para audífonos que contienen un procesamiento de señales acústico-espacial mejorado. Un cliente indica una capacidad de recibir un Paquete de Flujo de Audio utilizando los campos de Capacidad de Canal de Audio y Tasa de muestreo de Audio del Paquete de Capacidad de Cliente. El formato de Paquetes de Flujo de Audio se ilustra en la Figura 13. Como se muestra en la Figura 13, este tipo de paquete se estructura en una modalidad para tener los campos de Largo de Paquete, Tipo de Paquete, ID de bCliente, ID de Canal de Audio, Reservado 1, Cuenta de Muestra de Audio, Bits por Muestra y Empaquetado, Tasa de muestreo de Audio, CRC de Parámetro, Datos de Audio Digital, y CRC de Datos de Audio. En una modalidad, este tipo de paquete generalmente se identifica como un paquete de Tipo 32. El campo de ID de bCliente contiene 2 bytes de información que se encuentran reservados para un ID de Cliente, como se utilizó con anterioridad. El campo Reservado 1 contiene 2 bytes que se encuentran reservados para un uso posterior, y generalmente se configuran en este punto con todos los bits establecidos en cero. El campo de Bits por Muestra y Empaquetado contiene 1 byte en forma de un entero sin signo de 8 bits que especifique el formato de empaquetado de los datos de audio. El formato generalmente empleado es para los Bits 4 a 0 a fin de definir el número de bits por muestra de audio de PCM. El Bit 5 especifica si se empaquetan o no las muestras de Datos de Audio Digital.

La diferencia entre las muestras de audio empaquetado y alineado por bytes, utilizan en la presente muestras de 10 bits, como se ilustra en la Figura 14. Un valor de "0" indica que cada muestra de audio de PCM en el campo de Datos de Audio Digital es alineado por bytes con un límite de byte de MDDI, y un valor de "1" indica que cada muestra de audio de PCM se empaqueta contra la muestra de audío anterior. Este bit generalmente es eficaz solamente cuando el valor definido en los bits 4 a 0 (el número de bits por muestra de audio de PCM) no es un múltiplo de ocho. Los bits 7 a 6 se encuentran reservados para su uso posterior y generalmente se establecen en un valor de cero.

. Paquetes de Fl ujo Reservado En una modalidad, los tipos de paquete 1 a 15, 18 a 31, y 33 a 55 se encuentran reservados o para paquetes de flujo a definirse para su uso en futuras versiones o variaciones de los protocolos de paquete, como se desea para diversas aplicaciones encontradas. Nuevamente, esto es parte de hacer la MDDI más flexible y útil ante los siempre cambiantes tecnología y diseños de sistema en comparación con otras técnicas. 6. Paquetes de Fl uj o Definidos por el Usuario Ocho tipos de flujo de datos, conocidos como los Tipos 56 a 63, se encuentran reservados para su uso en aplicaciones de propietario que pueden definirse por los fabricantes del equipo para su uso con un enlace de MDDI. Éstos son conocidos como Paquetes de Flujo definidos por el Usuario. Tales paquetes pueden utilizarse para cualquier propósito, pero el huésped y cliente solamente deben emplear tales paquetes en situaciones donde el resultado de tal uso se comprenda o conozca muy bien. La definición específica de los parámetros y datos de flujo para estos tipos de paquete se deja a los fabricantes de equipo específico o a los diseñadores de interfase que implementan al ex tipos de paquete o que hacen uso de ellos. Algunos usos a manera de ejemplo de los Paquetes de Flujo definidos por el Usuario son llevar parámetros de prueba y resultados de prueba, datos de calibración de fábrica, y datos de uso especial del propietario. El formato de los paquetes de flujo definidos por el usuario como se utilizan en una modalidad se ilustra en la Figura 15.

Como se muestra en la Figura 15, este tipo de paquete se estructura para tener los campos de Largo de Paquete (2 bytes) , Tipo de Paquete, número de ID de Cliente, Parámetros de Flujo, CRC de Parámetro, Datos de Flujo, y CRC de Datos de Flujo. 7. Paquetes de Mapa de Colores Los paquetes de mapa de colores especifican el contenido de una tabla de consulta de mapa de colores utilizada para presentarle colores a un cliente. Algunas aplicaciones pueden requerir un mapa de colores que sea más grande que la cantidad de datos que pueden transmitirse en un solo paquete. En estos casos, pueden transferirse múltiples paquetes de Mapa de Colores, cada uno de ellos con un subconjunto diferente del mapa de colores utilizando los campos de variación y largo descritos a continuación. El formato del Paquete de Mapa de Colores en una modalidad se ilustra en la Figura 16. Como se muestra en la Figura 16, este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, Cuenta de Elementos de Mapa de Colores, Variación de Mapa de Colores, CRC de Parámetro, Datos de Mapa de Colores, y CRC de Datos. En una modalidad, este tipo de paquete generalmente se identifica como un paquete de Tipo 64 (Formato de Datos de Vídeo y Paquete de Mapa de Colores) como se especifica en el Campo de Tipo de Paquete (2 bytes) . Un cliente indica una capacidad para recibir Paquetes de Mapa de Colores utilizando los campos de Tamaño de Mapa de Colores y Ancho de Mapa de Colores del Paquete de Capacidad de Cliente. 8. Paquetes de Encapsulación de Enlace Inverso En una modalidad a manera de ejemplo, los datos se transfieren en dirección inversa utilizando un Paquete de Encapsulación de Enlace Inverso. Se envía un paquete de enlace en avance y la operación de enlace de MDDI (dirección de transferencia) cambia o se invierte a la mitad de este paquete de manera que los paquetes pueden enviarse en dirección inversa. El formato del paquete de Encapsulación de Enlace Inverso en una modalidad se ilustra en la Figura 17. Como se muestra en la Figura 17, este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, Banderas de Enlace Inverso, Divisor de Tasa Inversa, Largo de Cambiar 1, Largo de Cambiar 2, CRC de Parámetro, Sólo Ceros 1, Cambiar 1, Paquetes de Datos Inversos, Cambiar 2, y Sólo Ceros 2. En una modalidad, este tipo de paquete generalmente se identifica como un paquete de Tipo 65. Para Modo Externo cada huésped debe ser capaz de generar este paquete y recibir datos, y cada cliente debe ser capaz de recibir y enviar datos al huésped con objeto de hacer uso eficaz del protocolo deseado y la velocidad resultante. La implementación de este paquete es opcional para el Modo Interno, pero el Paquete de Encapsulación de Enlace Inverso se utiliza para el huésped reciba datos del cliente. El controlador de enlace de MDDI se comporta de manera especial mientras envia un Paquete de Encapsulación de Enlace Inverso. El MDDI tiene una señal estroboscópica que generalmente es accionada por el huésped como controlador del enlace. El huésped se comporta como si estuviese transmitiendo un cero por cada bit de las porciones Cambiar y Paquetes de Datos inversos del paquete de Encapsulación de Enlace Inverso. El huésped alterna a una señal MDDI_Strobe (MDDI_Estroboscópica) en cada límite de bit durante los dos tiempos de cambio y durante el tiempo asignado para los paquetes de datos inversos. Es decir, el huésped alterna MDDI_Stb desde el inicio del campo Sólo Ceros 1 al final del campo Sólo Ceros 2. (Este es el mismo comportamiento que si estuviese transmitiendo datos de sólo ceros) . El huésped deshabilita sus mane adores de línea de señal de datos de MDDI y generalmente asegura que sean deshabilitar o completamente antes del último bit del campo Cambiar 1, y rehabilita después sus mane adores de linea durante el campo Cambiar 2, y generalmente aseguran que los manejadores se han rehabilitado completamente antes del último bit del campo Cambiar 2. El cliente lee el parámetro de Largo de Cambiar y acciona las señales de datos hacia el huésped inmediatamente después del último bit en el campo Cambiar 1. Es decir, el cliente sincronizar nuevos datos en el enlace en ciertos deportes de subida de la señal estroboscópica de MDDI como se especifica en la descripción del contenido de paquete expuesta a continuación, y en otros lugares. El cliente utiliza los parámetros de Largo de Paquete y Largo de Cambiar para saber la duración en que se encuentra disponible para enviarle paquetes al huésped. El cliente puede enviar paquetes de relleno o llevar las lineas de datos a un estado de cero cuando no tiene datos que enviarle al huésped. Si las lineas de datos son llevadas a cero, el huésped interpreta esto como un paquete con largo cero (no es un largo válido) y el huésped no acepta ningún paquete más proveniente del cliente para la duración del Paquete de Encapsulación de Enlace Inverso actual . En una modalidad, el campo de Solicitud de Enlace Inverso del Paquete de solicitud y estado de cliente puede utilizarse para informarle al huésped el número de bytes que necesita el cliente en el Paquete de Encapsulación de Enlace Inverso para enviar los datos de regreso al huésped. El huésped intenta conceder la solicitud asignando al menos es el número de bytes en el Paquete de Encapsulación de Enlace Inverso. El huésped puede enviar más de un Paquete de Encapsulación de Enlace Inverso en una sub-trama. El cliente puede enviar un Paquete de solicitud y estado de cliente en cualquier momento, y el huésped interpretará el parámetro de Solicitud de Enlace Inverso como el número total de bytes solicitado en una sub-trama. 9. Paquetes de Capacidad de Cliente Un huésped necesita saber la capacidad del cliente (pantalla) que está comunicando con objeto de configurar el enlace huésped a cliente de la manera generalmente óptima o deseada. Se recomienda que una pantalla le envíe un Paquete de Capacidad de Cliente algo huésped después de que se adquiere la sincronización de enlace en avance. La transmisión de tal paquete se considera solicitada cuando es solicitada por el huésped utilizando las Banderas de Enlace Inverso en el Paquete de Encapsulación de Enlace Inverso. El Paquete de Capacidad de Cliente se utiliza para informarle al huésped sobre las capacidades de un cliente. Para el Modo Externo, cada huésped debe ser capaz de recibir este paquete, y cada cliente debe ser capaz de enviar este paquete para utilizar completamente esta interferencia y protocolo. La implementación de este paquete es opcional para el Modo Interno, dado que las capacidades del cliente, tal como una pantalla, teclado u otro dispositivo de entrada/salida, en esta situación ya debe estar bien definida y conocida por el huésped al momento de la fabricación o ensamble en un solo componente o unida de algún tipo. El formato del paquete de Capacidad de Cliente en una modalidad se ilustra en la Figura 18. Como se muestra en la Figura 18, para esta modalidad, este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de cCliente, Versión de Protocolo, Versión de Protocolo Min, Capacidad de Tasa de Datos, Capacidad de Tipo de Inferíase, Número de Pantallas Alt, Reservado 1, Ancho de Mapa de Bits, Altura de Mapa de Bits, Ancho de Ventana de Pantalla, Altura de Ventana de Pantalla, Tamaño de Mapa de Colores, Ancho de RGB de Mapa de Colores, Capacidad de RGB, capacidad Monocromática, Reservado 2, Capacidad de Y Cr Cb, Capacidad de Bayer, Planos de Imagen de Alfa-Cursor, Capacidad de Características de Cliente, Tasa de Trama de Video Max, Tasa de Trama de Vídeo Min, Tasa de Sub-Trama Min, Profundidad de Memoria Temporal de Audio, Capacidad de Canal de Audio, Capacidad de Tasa de muestreo de Audio, Resolución de Muestra de Audio, Resolución de Muestra de Audio de Micrófono, Capacidad de Tasas de Muestra de Micrófono, Formato de Datos de Teclado, Formato de Datos de Dispositivo de Señalización, Tipo de Protección de Contenido, Nombre de Fab., Código de Producto, Reservado 3, Número de Serie, Semana de Fab., Año de Fab., y de CRC. En una modalidad a manera de ejemplo, este tipo de paquete generalmente se identifica como un paquete de Tipo 66.

. Paquetes de datos de teclado Un paquete de datos de teclado se utiliza para enviar datos de teclado desde el dispositivo cliente al huésped. Puede utilizarse un teclado inalámbrico (o cableado) en conjunto con diversos dispositivos de visualización o de audio, incluyendo, pero sin limitarse a, dispositivos de presentación de audio/de visualización de vídeo instalados sobre la cabeza. El Paquete de Datos de Teclado transmite datos de teclado recibidos desde uno de varios dispositivos de tipo teclado conocidos hacia el huésped. Este paquete también puede utilizarse por el enlace en avance para enviarle datos al teclado. Un cliente indica una capacidad de enviar y recibir Paquetes de Datos de Teclado utilizando el Campo de Datos de Teclado en el Paquete de Capacidad de Cliente. El formato de un Paquete de Datos de Teclado se muestra en la Figura 19, y contiene un número variable de bytes de información provenientes o para un teclado. Como se muestra en la Figura 19, este tipo de paquete está estructurado para tener los campos de Largo de Paquete, Tipo de Paquete, ID de bCliente, Formato de Datos de Teclado, Datos de Teclado, y CRC. Aqui, este tipo de paquete generalmente se identifica como un paquete de Tipo 67. El ID de bCliente es un campo reservado, como se explicó con anterioridad, y la CRC se ejecuta en todos los bytes del paquete. El campo de Formato de Datos de Teclado contiene un valor de 2 bytes que describe el formato de datos de teclado. Los bits 6 a 0 deben ser idénticos al campo de Formato de Datos de Teclado en el Paquete de Capacidad de Cliente. Este valor no es igual a 127. Los bits 15 a 7 se encuentran reservados para su uso posterior y, consecuentemente, se encuentran actualmente establecidos en cero. 11 . Paquetes de Datos de Dispositivo de Señalización Un paquete de datos de dispositivo de señalización se utiliza como un método, estructura, un medio para enviar información de posición desde un ratón inalámbrico u otro dispositivo de señalización del cliente al huésped. Los datos también pueden enviarse al dispositivo de señalización por el enlace en avance utilizando este paquete. Un formato a manera de ejemplo de un Paquete de Datos de Dispositivo de Señalización se muestra en la Figura 20, y contiene un número variable de bytes de información proveniente de o para un dispositivo de señalización. Como se muestra en la Figura 20, este tipo de paquete está estructurado para tener los campos de Largo de Paquete, Tipo de Paquete, ID de bCliente, Formato de Datos de Señalización, Datos de Dispositivo de Señalización, y CRC. En una modalidad a manera de ejemplo, este tipo de paquete generalmente se identifica como un paquete de Tipo 68 en el campo de Tipo de 1 byte. 12. Paquetes de Desconexi ón de Enlace Un paquete de desconexión de enlace se envía desde el huésped al cliente como un método o medio para indicar que los datos de MDDI y señal estroboscópica se desconectarán e irán a un estado de "hibernación" de bajo consumo de energía. Este paquete es útil para desconectar el enlace y conservar energía después de que los mapas de bits estáticos se envían de un dispositivo de comunicaciones móviles a la pantalla, o cuando no hay información adicional para transferir desde un huésped a un cliente para ese momento. La operación normal continúa cuando el huésped envía nuevamente los paquetes. El primer paquete enviado después de la hibernación es un paquete de cabecera de sub-trama. El formato de un Paquete de Estado de Cliente para una modalidad se muestra en la Figura 21. Como se muestra en la Figura 21, este tipo de paquete se encuentra estructurado para tener los campos Largo de Paquete, Tipo de Paquete, CRC y Sólo Ceros. En una modalidad, este tipo de paquete generalmente se identifica como un paquete de Tipo 69 en el campo de Tipo de 1 byte. El Campo de Largo de Paquete utiliza 2 bytes para especificar el número total de bytes en el paquete sin incluir el campo de largo de paquete. En una modalidad, el Largo de Paquete de este paquete es dependiente del Tipo de Inferíase o modo de enlace en efecto al momento cuando ese enviado el Paquete de Desconexión de Enlace. Por lo tanto, el largo de paquete típico se vuelve de 20 bytes para el modo de Tipo 1 (22 bytes en total en el paquete) , 36 bytes para un modo de Tipo 2 (38 bytes en total en el paquete) , 68 bytes para un enlace de modo de Tipo 3 (70 bytes en total en el paquete) , y 132 bytes para un modo de Tipo 4 (con 134 bytes en total en el paquete) . El campo Sólo Ceros utiliza un número variable de bytes para asegurar que las señales de MDDI_Datos se encuentran en un nivel de cero lógico para un tiempo suficiente que le permite al cliente comenzar a recuperar el reloj utilizando solamente MDDI_Stb antes deshabilitar los manej adores de linea del huésped. El largo del campo de Sólo Ceros es dependiente del Tipo de Inferíase o modo de operación de enlace en efecto al momento cuando se envia el Paquete de Desconexión de Enlace. El largo del campo de Sólo Ceros se encuentra diseñado para producir 64 impulsos en MDDI_Stb para cualquier configuración de Tipo de Inferíase. Por lo tanto, el campo de Sólo Ceros para cada tipo de interfase se vuelve de 16 bytes para el Tipo 1, 32 bytes para el Tipo 2, 64 bytes para el Tipo 3, y 128 bytes para el Tipo 4. El campo de CRC utiliza 2 bytes que contienen una CRC de 16 bits o bytes del Largo de Paquete al Tipo de Paquete. En el estado de hibernación de bajo consumo de energía, el manej ador MDDI_DatosO se deshabilita en un estado de alta impedancia comenzando después del 16° al 48° ciclo o impulso de MDDI_Stb después del último bit del campo de Sólo Ceros. Para los enlaces de Tipo 2, Tipo 3, o Tipo 4 las señales de MDDI_Datosl a MDDI_DatosPwr7 también se colocan en un estado de alta impedancia al mismo tiempo que el manej ador de MDDI_DatosO se deshabilita. Sea el huésped o el cliente puede hacer que el enlace de MDDI se "despierte" del estado de hibernación como se describe en otra parte, lo cual es un avance importante para y una ventaja de la presente invención. Como se describe en la definición del campo de Sólo Ceros, MDDI_Stb cambia durante 64 sitios después del MSB del campo de CRC del Paquete de Desconexión de Enlace a fin de facilitar un apagado correcto en el controlador de cliente. Un ciclo es una transición de bajo a alto seguida de una transición de alto a bajo, una transición de alto a bajo seguida por una transición de bajo a alto. Después de que se envía el campo de Sólo Ceros, se deshabilita el manej ador de MDDI_Stb en el huésped. 23. Paquetes de Solicitud y Estado de Cliente El huésped necesita una pequeña cantidad de información proveniente del cliente de manera que pueda configurar el enlace de la cliente de manera generalmente óptima. Se recomienda que el cliente envié un Paquete de Solicitud y Estado de Cliente al huésped en cada sub-trama. El cliente debe enviar este paquete como el primer paquete en el Paquete de Encapsulación de Enlace Inverso a fin de asegurar que se ha enviado confiablemente al huésped. El envió en avance de este paquete también se realiza cuando es solicitado por un huésped que utiliza las Banderas de Enlace Inverso en el Paquete de Encapsulación de Enlace Inverso. El Paquete de Solicitud y Estado de Cliente se utiliza para reportar errores y el estado al huésped. Para la operación en modo externo, para huésped debe ser capaz de recibir este paquete, y cada cliente de ser capaz de envia este paquete con objeto de emplear opina y apropiadamente el protocolo de MDDI . Aunque también se recomienda que para operaciones internas, es decir huéspedes internos y clientes internos, no se requiere que debe haber soporte para este paquete. El formato de un Paquete de Solicitud y Estado de Cliente se muestra en la Figura 22. Como se muestra en la Figura 22, este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de cCliente, Solicitud de Enlace Inverso, Cambio de Capacidad, Cliente Ocupado, Cuenta de Errores de CRC, y de CRC. Este tipo de paquete generalmente se identifica como un paquete de Tipo 70 en el campo de tipo de 1 byte, y utiliza típicamente un largo fijo pre-seleccionado de 12 bytes. El campo de Solicitud de Enlace Inverso puede utilizarse para informarle al huésped sobre el número de bytes que necesita el cliente en el Paquete de Encapsulación de Enlace Inverso para enviarle datos de regreso al huésped. El huésped debe intentar conceder la solicitud asignando al menos ese número de bytes en el Paquete de Encapsulación de Enlace Inverso. El huésped puede enviar más de un Paquete de Encapsulación de Enlace Inverso en una sub-trama con objeto de alojar los datos. El cliente puede enviar un Paquete de Solicitud y Estado de Cliente en cualquier momento y el huésped interpretará el parámetro de Solicitud de Enlace Inverso como el número total de bytes solicitados en una sub-trama. A continuación se muestran detalles adicionales y ejemplos específicos de cómo se envían los datos de enlace inverso al huésped. 14. Paquetes de Transferencia de Bloque de Bits El Paquete de Transferencia de Bloque de Bits proporciona un medio, estructura, o método para desplazarse por las regiones en cualquier dirección. Las pantallas que tienen esta capacidad reportarán la capacidad en el bit 0 del campo de Indicadores de Capacidad de Características de Pantalla del paquete de Capacidad de Cliente. El formato para una modalidad de un Paquete de Transferencia de Bloque de Bits se muestra en la Figura 23. Como se muestra en la Figura 23, este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, Valor Superior Izquierdo X, Valor Superior Izquierdo Y, Ancho de Ventana, Altura de Ventana, Movimiento de Ventana X, Movimiento de Ventana Y, y CRC. Este tipo de paquete generalmente se identifica como un paquete de Tipo 71, y en una modalidad utiliza un largo fijo preseleccionado de 15 bytes. Los campos se utilizan para especificar los valores de X y Y de la coordenada de la esquina superior izquierdo de la ventana por moverse, el ancho y altura de la ventana por moverse, y el número de pixeles que se mueve la ventana horizontalmente, y verticalmente, respectivamente. Los valores positivos para los dos últimos campos ocasionan que la ventana se mueva hacia la derecha, y abajo, y los valores negativos ocasionan el movimiento hacia la izquierda y arriba, respectivamente.

. Paquetes de Relleno de Área de Mapa de Bits El Paquete de Relleno de Área de Mapa de Bits proporciona un medio, estructura, o método para iniciar fácilmente una región de la pantalla en un solo color. Las pantallas que tienen esta capacidad reportarán la capacidad en el bit 1 del campo de Indicadores de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente. Una modalidad para el formato de un Paquete de Relleno de Área de Mapa de Bits se muestra en la Figura 24. Como se muestra en la Figura 24, en este caso este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, Valor Superior Izquierdo X, Valor Superior Izquierdo Y, Ancho de Ventana, Altura de Ventana, Descriptor el Formato de Datos, Valor de Relleno de Área de Pixel, y de CRC. Este tipo de paquetes se identifica generalmente como un paquete de Tipo 72 en el campo de tipo de 1 byte, y utiliza un largo fijo preseleccionado de 17 bytes. 16. Paquetes de Rellenar Patrón de Mapa de Bi ts El Paquete de Rellenar Patrón de Mapa de Bits proporciona un medio o estructura para inicializar fácilmente una región de la pantalla en un patrón preseleccionado. Las pantallas que tienen esta capacidad reportarán la capacidad del bit 2 del campo de Capacidad y Características de Cliente el Paquete de Capacidad de Cliente. La esquina superior izquierda del patrón de relleno se alinea con la esquina superior izquierda de la ventana por rellenarse, a menos de que la variación de patrón horizontal o vertical sea diferente de cero. Si la ventana por rellenarse es más ancha, o más alta que el patrón de relleno, entonces el patrón puede repetirse horizontalmente o verticalmente un cierto número de veces para llenar la ventana. La parte derecha o inferior del último patrón repetido se trunca según sea necesario. Si la ventana es más pequeña que el patrón de relleno, entonces la parte derecha o inferior del patrón de relleno puede truncarse para ajustarse a la ventana. Si la variación de patrón horizontal es diferente de cero, entonces los píxeles entre el costado izquierdo de la ventana y el costado izquierdo más la variación de patrón horizontal se rellenan con los píxeles ubicados a la extrema derecha del patrón. La variación de patrón horizontal va a ser menor que el ancho de patrón. De manera similar, si una variación de patrón vertical es diferente de cero, entonces los píxeles entre el costado superior de la ventana y la parte superior el costado más la variación de patrón vertical se rellenan con los píxeles de la parte más baja del patrón. La variación de patrón vertical va a ser menor que la altura de patrón. Una modalidad para el formato de un Paquete de Relleno Patrón de Mapa de Bits se muestra en la Figura 25. Como se muestra en la Figura 25, este tipo de paquetes estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, Valor Superior Izquierdo X, Valor Superior Izquierdo Y, 7Ancho de Ventana, Altura de Ventana, Ancho de Patrón, Altura de Patrón, Variación de Patrón Horizontal, Variación de Patrón Vertical, Descriptor de Formato de Datos, CRC de Parámetro, Datos de Píxel de Patrón, y CRC de Datos de Píxel. En algunas modalidades, este tipo de paquete generalmente se identifica como un paquete de Tipo 73 en el campo de tipo de 1 byte. 17. Paquetes de Canal de Datos de Enlace de Comunicaciones El Paquete de Canal de Datos de Enlace de Comunicaciones proporciona una estructura, medio, o método para un cliente con capacidad de cómputo de alto nivel, tal como un PDA, para comunicarse con un transductor inalámbrico tal como un teléfono celular o dispositivo inalámbrico de puerto de datos. En esta situación, el enlace de MDDI está actuando como una interfase conveniente de alta velocidad entre el dispositivo de comunicaciones y el dispositivo de cómputo con la pantalla móvil, donde este paquete transporta datos en la Capa de Enlace de Datos de un sistema operativo para el dispositivo. Por ejemplo, este paquete podria utilizarse si un explorador de web, cliente de correo electrónico, o todo un PDA donde se encuentra incorporado en una pantalla móvil. Las pantallas que tienen esta capacidad reportarán la capacidad en el bit 3 del campo de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente. El formato de una modalidad para un Paquete de Canal de Datos de Enlace de Comunicaciones se muestra en la Figura 26. Como se muestra en la Figura 26, este tipo de paquetes estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, CRC de Parámetro, Datos de Enlace de Comunicaciones, y CRC de Datos de Comunicaciones. En una modalidad, este tipo de paquete se identifica generalmente como un paquete de Tipo 74 en el campo de tipo . 18. Paquetes de Solici tud de Transferencia de Tipo de Interfase El Paquete de Solicitud de Transferencia de Tipo de Inferíase proporciona un medio, método o estructura que le permite al huésped solicitar el desplazamiento del cliente o de visualización de un modo existente o actual a los modos de Tipo 1 (serial) , Tipo 2 (paralelo de 2 bits) , Tipo 3 (paralelo de 4 bits) , o de Tipo 4 (paralelo de 8 bits) . Antes de que el huésped solicite un modo particular debe confirmar que el cliente es capaz de operar en el modo deseado al examinar los bits 6 y 7 del campo de Indicadores de Capacidad de Características de Pantalla del Paquete de Capacidad de Cliente. Una modalidad para el formato de un Paquete de Solicitud de Transferencia de Tipo de Inferíase se muestra en la Figura 27. Como se muestra la Figura 27, este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, Tipo de Inferíase, Reservado 1, y CRC. Este tipo de paquete generalmente se identifica como un paquete de Tipo 75, y utiliza un largo fijo preseleccionado de 4 bytes . 19. Paquetes de Reconocimiento de Tipo de Interfase El Paquete de Reconocimiento de Tipo de Inferíase se envia por un cliente y proporciona un medio, método o estructura que le permite a un cliente confirmar la recepción del Paquete de Transferencia de Tipo de Inferíase. El modo solicitado, el modo de Tipo 1 (serial) , Tipo 2 (paralelo de 2 bits) , Tipo 3 (paralelo de 4 bits) , o Tipo 4 (paralelo de 8 bits) se devuelve como eco al huésped como un parámetro en este paquete. El formato de una modalidad para un Paquete de Reconocimiento de Tipo de Inferíase se muestra en la Figura 28. Como se muestra la Figura 28, este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de cCliente, Tipo de Inferíase, Reservado 1 y CRC. Este tipo de paquete generalmente se identifica como un paquete de Tipo 76, utiliza un largo fijo preseleccionado de 4 bytes.

. Paquetes de Transferencia de Tipo de Rendimi ento El Paquete de Transferencia de Tipo de Rendimiento es un medio, estructura o método para que el huésped le ordene al cliente transferir al modo especificado en este paquete. Este va ser el mismo modo que se solicitó con anterioridad y que fue reconocido por el Paquete de Solicitud de Transferencia de Tipo de Inferíase y el Paquete de Reconocimiento de Tipo de Inferíase. El huésped y el cliente deben conmutar al modo acordado después de que se envia este paquete. El cliente puede perder y volver a obtener la sincronización de enlace durante el cambio de modo. El formato de una modalidad para un Paquete de Transferencia de Tipo de Rendimiento se muestra en la Figura 29. Como se muestra la Figura 29, este tipo de paquetes estructura para tener los campos de Largo de Paquete, Tipo de Paquete, Tipo de Paquete, Reservado 1, y CRC. Este tipo de paquete se identifica generalmente como un paquete de Tipo 77 en el campo de tipo de 1 byte, y utiliza un largo fijo preseleccionado de 4 bytes . 21 . Paquetes Habili tar Canal de Audio en Avance Este paquete proporciona una estructura, método, o medio que le permite a un huésped habilitar o deshabilitar canales de audio en un cliente. Esta capacidad es útil de manera que un cliente (una pantalla, por ejemplo) pueda apagar los amplificadores de audio o elementos de circuito similares a fin de ahorrar energía cuando no hay salida de audio por el huésped. Esto es significativamente más difícil de implementar implícitamente utilizando sólo la presencia o ausencia de flujos de avión como indicador. El estado default cuando se enciende el sistema de cliente es que todos los canales de audio están habilitados. El formato de una modalidad de un Paquete de Habilitación de Canal de Audio en Avance se muestra en la Figura 30. Como se la Figura 30, este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, Máscara de Habilitar Canal de Audio, y de CRC. Este tipo de paquete generalmente se identifica como un paquete de Tipo 78 en el campo de tipo de 1 byte, y utiliza un largo fijo preseleccionado de 4 bytes. 22. Paquetes de Tasa de Muestreo de Audio Inverso Este paquete le permite al huésped habilitar o deshabilitar el canal de audio de enlace inverso, y establecer la tasa de muestreo de datos de audio de este flujo. El huésped selecciona una tasa de muestreo que se define como válida en el Paquete de Capacidad y Cliente. Si el huésped selecciona una tasa de muestreo inválida entonces el cliente no enviará un flujo de audio al huésped, y una señal de error apropiado, valor de error, o señal de error, pueden de Argel muertos en el Paquete de Reporte de Error de Cliente. El huésped puede deshabilitar el flujo de audio de enlace inverso estableciendo la tasa de muestreo en un valor de 255. La tasa default supuesta cuando el sistema de cliente se enciende o conecta inicialmente es con el flujo de audio de enlace inverso deshabilitado. El formato de una modalidad para un Paquete de Tasa de Muestreo de Audio Inverso se muestra en la Figura 31. Como se muestra la Figura 31, este tipo de paquetes estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, Tasa de Muestreo de Audio, Reservado 1, y CRC. Este tipo de paquete generalmente se identifica como un paquete de Tipo 79, y utiliza un largo fijo preseleccionado de 4 bytes. 23. Paquetes de Informaci ón Complementaria de Protección de Contenido Digital Este paquete proporciona una estructura, método, o medio que le permite al huésped y a un cliente intercambiar mensajes relacionados con el método de protección de contenido digital que se está utilizando. Actualmente se contemplan dos tipos de protección de contenido, Protección de Contenido de Transmisión Digital (DTCP) , o Sistema de Protección de Contenido Digital de Ancho de Banda Alto (HDCP) , con espacio reservado para futuras designaciones alternas de esquema de protección. El método que se utiliza se especifica por un parámetro de Tipo de Protección de Contenido en este paquete. El formato de una modalidad de un Paquete de Información Complementaria de Protección de Contenido Digital se muestra en la Figura 32. Como se muestra en la Figura 32, este tipo de paquetes estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de bCliente, Tipo de Protección de Contenido, Mensajes de Información Complementaria de Protección de Contenido, y de CRC. Este tipo de paquete generalmente se identifica como un paquete de Tipo 80. 24. Paquetes de Habilitación de Color Transparente El Paquete de Habilitación de Color Transparente es una estructura, método, un medio que se utiliza para especificar qué color es transparente en una pantalla y para habilitar o deshabilitar el uso de un color transparente para imágenes que están siendo visualizadas. Las pantallas que tienen esta capacidad reportarán esa capacidad en el tipo 4 del campo Capacidad de Características de Cliente del Paquete de Capacidad de Cliente. Cuando un pixel con el valor para color transparente es escrito en el mapa de colores, el color no cambia del valor anterior. El formato de un Paquete de Habilitación de Color Transparente se muestra en la Figura 33. Como se muestra en la Figura 33, en una modalidad este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, Habilitar Color Transparente, Reservado 1, Identificador de alfa-Cursor, Descriptor de Formato de Datos, Valor de Píxel Transparente, y de CRC. Este tipo de paquete generalmente se identifica como un paquete de Tipo 81 en el campo de tipo de 1 byte, y utiliza un largo fijo preseleccionado de 10 bytes.

. Paquetes de Medición de Retraso de Viaje Redondo El Paquete de Medición de Retraso de Viaje Redondo proporciona una estructura, método, o medio que se utiliza para medir el retraso de propagación del huésped a un cliente (pantalla) mas el retraso derivado del cliente (pantalla) de regreso al huésped. Esta medición incluye inherentemente los retrasos que existen en los manej adores de linea y receptores, y un subsistema de interconexión. Esta medición se utiliza para establecer los parámetros de retraso de viaje redondo y de divisor de tasa de enlace inverso en el Paquete de Encapsulación de Enlace Inverso, descrito en términos generales con anterioridad. Este paquete es muy útil cuando el enlace de MDDI está funcionando a la máxima velocidad destinada para una aplicación en particular. El paquete puede verse en el modo de Tipo 1 y a una tasa de datos menor con objeto de incrementar el rango de la medición del retraso de viaje redondo. La señal de MDDI_Stb se comporta como si se estuviesen enviando datos de sólo cero durante los siguientes campos: ambos Tiempos de Guardia, Sólo Ceros, y el Periodo de Medición. Esto ocasiona que MDDI_Stb cambie a la mitad de la tasa de datos de modo que pueda utilizarse como reloj periódico en el cliente durante el Periodo de Medición. En una modalidad, un cliente generalmente indica una capacidad para soportar el Paquete de Medición de Retraso de Viaje Redondo mediante el uso del bit 18 del campo de Indicadores de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente. Se recomienda que todos los clientes soporten la medición de retraso de viaje redondo, pero es posible que el huésped conozca el retraso de viaje redondo del peor escenario con base en un retraso de cable máximo, y en los retrasos máximos de manej ador y receptor. El huésped también puede conocer el retraso de viaje redondo en avance para un enlace de MDDI utilizado en modo interno, dado que este es un aspecto de los elementos de diseño conocidos (largos de conductor, tipo de circuitería, y características, etc.) del dispositivo en el cual se está utilizando la interfase. El formato de un Paquete de Medición de Retraso de Viaje Redondo se muestra en la Figura 34. Como se muestra la Figura 34, en una modalidad este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, CRC de Parámetro, Tiempo de Guardia 1, Periodo de Medición, Sólo Ceros, y Tiempo de Guardia 2. Este tipo de paquete generalmente se identifica como un paquete de Tipo 82, y utiliza un largo fijo preseleccionado de 159 bits. La sincronización de eventos que tienen lugar durante el Paquete de Medición de Retraso de Viaje Redondo se ilustra en la Figura 35. En la Figura 35, el huésped transmite el Paquete de Medición de Retraso de Viaje Redondo, mostrado por la presencia de los campos de CRC de Parámetro y Alineación de Señal Estroboscópica seguidos por los campos de Sólo Ceros 1 y Tiempo de Guardia 1. Un retraso 3502 ocurre antes de que el paquete alcance el dispositivo de pantalla de cliente o circuitería de procesamiento. Dado que el cliente recibe el paquete, transmite Oxff, Oxff, y 30 bytes del patrón 0x00 de manera precisa y táctica como al inicio del Periodo de Medición como se determinó por el cliente. El momento actual en que el cliente comienza transmitir esta secuencia se retrasa del inicio del Periodo de Medición desde el punto de vista del huésped. La cantidad de este retraso es sustancialmente el tiempo que le lleva al paquete propagarse por los manej adores de linea y receptores y el subsistema de interconexión (cables', conductores) . Una cantidad similar de retraso 3504 se toma para el patrón a fin de propagarse de regreso desde el cliente al huésped. Con objeto de determinar con precisión el tiempo de retraso de viaje redondo para las señales que viajan a y desde el cliente, el huésped cuenta el número de periodos de tiempo de bit de enlace en avance y ocurren después del inicio del Periodo de Medición hasta que se detecta el inicio de Oxff, Oxff, y 30 bytes de la secuencia 0x00 tras su llegada. Esta información es utilizada para determinar la cantidad de tiempo en que una señal de viaje redondo pasa del huésped al cliente y de regreso nuevamente. Entonces, aproximadamente la mitad de esta cantidad se atribuye a un retraso creado para el paso en un solo sentido de una señal al cliente. El huésped y el cliente llevan ambos la línea a un nivel de cero lógico durante ambos tiempos de guardia para mantener las lineas MDDI_DATOS en un estado definido. Los tiempos de habilitación y de deshabilitación del huésped y el cliente durante ambos tiempos de guardia son de tal manera que las señales de MDDI_Datos se encuentran en un nivel de bajo válido para cualquier tiempo de retraso de viaje redondo válido . 26. Paquete de Calibración de Distorsión de Enlace en Avance El Paquete de Calibración de Distorsión de Enlace en Avance le permite a un cliente o pantalla calibrar por si mismos las diferencias en el retraso de propagación de las señales de MDDI_Datos con respecto a la señal MDDI_Stb. Sin compensación de distorsión de retraso, la tasa de datos máxima generalmente se encuentra limitada para representar la variación potencial del peor escenario en estos retrasos. Generalmente, este paquete se envia solamente cuando la tasa de datos de enlace en avance se encuentra configurada a una tasa de aproximadamente 50 Mbps o menos. Después de enviar este paquete para calibrar la pantalla, la tasa de datos puede ascender por encima de los 50 Mbps. Si la tasa de datos se establece demasiado alta durante el proceso de calibración de distorsión, la pantalla pudiese sincronizarse con un alias del periodo de bit lo cual podría ocasionar que la compensación de distorsión de retraso esté apagada por más de un tiempo de un bit, dando como resultado una sincronización de datos errónea. El tipo de interfase de tasa de datos más alta o el Tipo de Inferíase más grande posible se selecciona antes de enviar el Paquete de Calibración de Distorsión de Enlace en Avance de manera que se calibran todos los bits de datos existentes. En la Figura 56 se muestra una modalidad del formato de un Paquete de Calibración de Distorsión de Enlace en Avance. Como se muestra en la Figura 56, este tipo de paquete se estructura para tener los campos de Largo de Paquete (2 bytes), Tipo de Paquete, ID de hCliente, CRC de Parámetro, Sólo Ceros, Secuencia de Datos de Calibración, y de CRC. Este tipo de paquete generalmente se identifica como un paquete de Tipo 83 en el campo de tipo, y en una modalidad tiene un largo preseleccionado de 515.

Panel de Control Virtual El uso de un Panel de Control Virtual (VCP -Virtual Control Panel) le permite a un huésped establecer algunos controles de usuario en un cliente. Al permitir que estos parámetros sean ajustados por el huésped, la interfase de usuario en el cliente puede simplificarse debido a que las pantallas que le permiten a un usuario ajustar parámetros tales como volumen de audio o brillo de pantalla pueden generarse por software de huésped en lugar de por uno o más microprocesadores en el cliente. El huésped tiene la capacidad de leer los ajustes de parámetro en el cliente y determinar el rango de valores válidos para cada control. El cliente generalmente tiene la capacidad de reportar de regreso a los huéspedes cuáles parámetros de control pueden ajustarse. Los códigos de control (Códigos de VCP) y valores de datos asociados especificados en términos generales, se utilizan para especificar controles y configuraciones en el cliente. Los Códigos de VCP en la especificación de MDDI se expanden a 16 bits para preservar la alineación apropiada de campo de datos en las definiciones de paquete, y en el futuro para soportar valores complementarios que son únicos para esta interfase o futuras mejoras. 21. Paquete Solicitar Características de VCP El Paquete Solicitar Características de VCP proporcionó un medio, mecanismo, o método para que el huésped solicite el ajuste actual de un parámetro de control especifico o de todos los parámetros de control válidos. En términos generales, un cliente responde a un Paquete de VCP con la información apropiada en un Paquete de Respuestas de Características de VCP. En una modalidad, el cliente indica una capacidad de soportar el Paquete Solicitar Características de VCP utilizando el bit 13 del campo de Indicadores de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente. En la Figura 69 se muestra el formato del Paquete Solicitar Características de VCP en una modalidad. Como se observa la Figura 69, este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, Código de VCP de MCCS, y de CRC. Este tipo de paquete se identifique generalmente en una modalidad como un Tipo 128, el cual se indica en el campo de tipo de 2 bytes. El largo de paquete, que especifica el número total de bytes en el paquete no incluye el campo de largo de paquete, típicamente es fijo para este tipo de paquete con un largo de 8 bytes . El campo de hCliente se encuentra reservado para su uso como un ID de Cliente en futuras implementaciones y típicamente se establece en cero. El campo de código de VCP de MCCS comprende 2 bytes de información que especifican el Parámetro de Código de Control de VCP de MCCS. Un valor en el rango de 0 a 255 ocasiona que sea devuelto un Paquete de Respuestas de Características de VCP con un solo elemento en la Lista de Respuestas de Características de VCP correspondiente al código de MCCS especificado. Un código de VCP de MCCS de 65535 (Oxffff) solicita un Paquete de Respuestas de Características de VCP con una Lista de Respuestas de Características de VCP que contiene un elemento de Lista de Respuestas de Características para cada control soportado por el cliente. Los valores de 256 a 65534, para este campo se encuentran reservados para su uso posterior y actualmente no se encuentran en uso. 28. Paquete de Respuestas de Características de VCP El Paquete de Respuestas de Características de VCP proporciona un medio, mecanismo, o método para que un cliente responda a una solicitud de huésped con el ajuste actual de un parámetro de control específico o todos los parámetros de control válidos. En términos generales, un cliente envia el Paquete de Respuestas de Características de VCP en respuesta a un Paquete Solicitar Características de VCP. Este paquete es útil para determinar el ajuste actual de un parámetro especifico, determinar el rango válido de un control especifico, determinar si un control especifico es soportado por el cliente, o determinar el conjunto de controles que son soportados por el cliente. Si se envia un Paquete Solicitar Características de VCP que haga referencia a un control específico que no está implementado en el cliente, entonces Paquete de Respuesta de Características de VCP es devuelto con un solo elemento de Listas de Respuestas de Características de VCP correspondiente al control no implementado que contiene el código de error apropiado . En una modalidad, el cliente indica una capacidad para soportar Paquete de Respuestas de Características de VCP utilizando el bit 13 del campo de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente. En la Figura 70 se muestra el formato del Paquete de Respuestas de Características de VCP en una modalidad. Como se observa en la Figura 70, este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de cCliente, Versión de MCCS, Número de Secuencia de Respuesta, Lista de Respuestas de Características de VCP, y de CRC. Este tipo de paquete generalmente se identifica en una modalidad como un Tipo 129, como se indica en el campo de tipo de 2 bytes. El campo de ID de cCliente contiene información reservada para un ID de Cliente. Este campo está reservado para su uso posterior y generalmente se establecen cero. El campo de Versión de MCCS contiene 2 bytes de información que especifica la Versión de la Especificación de MCCS de VESA implementada por el cliente. El campo de Número de Secuencia de Respuesta de 2 bytes contiene información o datos que especifican el número de secuencia de los Paquetes de Respuesta de Características de VCP regresados por el cliente. El cliente regresa uno o más Paquetes de Respuesta de Características de VCP en respuesta a un Paquete Solicitar Características de VCP con un valor de Código de Control de MCCS de 65535. El cliente puede difundir la Lista de Respuestas de Características por múltiples Paquetes de Respuesta de Características de VCP. En este caso, el cliente asigna un número de secuencia a cada paquete sucesivo, y los números de secuencia de los Paquetes de Respuesta de Características de VCP enviados en respuesta a un solo Paquete Solicitar Características de VCP comienza en cero y se incrementa en uno. El último Elemento de Lista de Características de VCP en el último Paquete de Respuesta de Características de VCP debe contener un valor de Código de Control de VCP de MCCS igual a Oxffff para identificar que el paquete es el último y que contiene el número de secuencia más alto del grupo de paquetes regresados. Si solamente se envían un Paquete de Respuesta de Características de VCP en respuesta a un Paquete Solicitar Características de VCP entonces el Número de Secuencia de Respuesta en ese paquete individual es cero y la Lista de Respuestas de Características de VCP obtiene un registro que tiene un Código de Control de VCP de MCCS igual a Oxffff. El campo de Número de Características en Lista contiene 2 bytes que especifican el número de Elementos de Lista de Características de VCP que se encuentran en la Lista de Respuestas de Características de VCP en este paquete, mientras que el campo de Lista de Respuestas de Características de VCP es un grupo de bytes que contiene uno o más Elementos de Lista de Respuestas de Características de VCP. En una modalidad en la Figura 71 se muestra el formato de un solo Elemento de Lista de Respuestas de Características de VCP. Como se muestra en la Figura 71, cada Elemento de Lista de Respuestas de Características de VCP tiene 12 bytes de largo, y comprende los campos de Código de VCP de MCCS, Código de Resultado, Valor Máximo, y Valor Actual. El campo de código de VCP de MCCS de 2 bytes contiene datos o información que especifica el Parámetro de Código de Control de VCP de MCCS asociado con este elemento de lista. Solamente los valores de Código de Control definidos en la Especificación de MCCS de VESA versión 2 y posteriores son considerados válidos para esta modalidad. El campo de Código de Resultado de 2 bytes contiene información que especifica un código de error relacionado con la solicitud para información referente al control de VCP de MCCS especificado. Un valor de "0" en este campo significa que no existe error, mientras que un valor de "1" significa que el control especificado no se encuentra implementado en el cliente. Los valores adicionales para este campo de 2 a .65535 se encuentran actualmente reservados para su uso posterior e implementación de otra aplicación contemplada en la materia, pero no se van a utilizar por ahora. El campo de valor máximo de 4 bytes contiene un entero sin signo de 32 bits que especifica el valor más grande posible al cual puede establecerse el control de MCCS. Si el control solicitado no simplemente en el cliente, este valor se establece en cero. Si el valor regresado es menor que 32 bits (4 bytes) de largo, entonces el valor toma la forma de un entero de 32 bits dejando a los bytes más significativos (no utilizados) en cero. El campo de Valor Actual de 4 bytes contiene información que especifica el valor actual del control especificado de VCP de MCCS Continuo (C) o No Continuo (NC) . Si el control solicitado no se encuentra implementado en el cliente o si el control se encuentra implementado pero es un tipo de datos de tabla (T) , entonces este valor se establece en cero. Si el valor regresado es menor que 32 bits (4 bytes) de largo por la especificación de MCCS de VESA, entonces el valor toma la forma de un entero de 32 bits dejando los bytes más significativos (no utilizados) en cero. 29. Establecer Características de VCP El Paquete Establecer Características de VCP proporciona un medio, mecanismo, o método para que un huésped no establezca los valores de control de VCP para ambos controles continuo y no continuo en un cliente. En una modalidad, el cliente indique la capacidad para soportar el Paquete Establecer Características de VCP utilizando el de 13 del Campo de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente.

En una modalidad de la Figura 72 se muestra el formato del Paquete Establecer Características de VCP. Como se observa en la Figura 72, este tipo de paquete se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, Código de VCP de MCCS, Número de Valores en Lista, Lista de Valores de Control, y de CRC. Este tipo de paquete generalmente se identifica como un Tipo 130, como se indica en el campo de tipo de 2 bytes, es de 20 bytes de largo exclusivo del campo de Largo de Paquete. El campo de ID de hCliente utiliza nuevamente un valor de 2 bytes para especificar o actuar como un ID de Cliente. Este campo se encuentra reservado para su uso posterior y actualmente se encuentra establecido en cero. El campo de Código de VCP de MCCS utiliza 2 bytes de información o valores para especificar el Parámetro de Código de Control de VCP de MCCS por ajustarse. El campo de Número de Valores en Lista de 2 bytes contiene información o valores que especifican el número de valores de 16 bits que existen en la Lista de Valores de Control. La Lista de Valores de Control normalmente contendrá un elemento a menos que el código de control de MCCS se encuentra relacionado con una tabla en el cliente. En caso de controles que no estén relacionados con tablas, la Lista de Valores de Control contendrá un valor que especifica el nuevo valor por escribirse en el parámetro de control especificado por el campo de código de VCP de MCCS. Para controles relacionados con tablas, el formato de los datos en la Lista de Valores de Control se especifica por la descripción de parámetros del Código de VCP de MCCS especificado. Si la lista contiene valores mayores que un byte, entonces el bytes menos significativo se transmite primero, consistente con el método definido con anterioridad. Finalmente, el campo de CRC de 2 bytes contiene una CRC de 16 bits de todos los bytes en el paquete incluyendo el Largo de Paquete.

. Paquete Solici tar Parámetros Válidos El Paquete Solicitar Parámetros Válidos se utiliza como un medio o estructura útil para solicitar que un cliente regrese un Paquete de Respuesta de Parámetros Válidos que contiene una lista de parámetros soportados por el control especificado no continuo (NC) o de tabla (T) . Este paquete no solamente debe especificar controles no continuos o controles que estén relacionados con una tabla en el cliente, y no especifican un valor de Código de VCP de MCCS de 65535 (Oxffff) que especifica todos los controles. Si se especifica un Código de VCP de MCCS no soportado o inválido, entonces un valor de error apropiado es egresado en el Paquete de Respuesta de Parámetros Válidos. En una modalidad, el cliente indica una capacidad para soportar el Paquete Solicitar Parámetros Válidos utilizando el bit 13 del campo de Capacidad de Características de Cliente del Paquete de Capacidad de Visualización. En una modalidad de la Figura 73 se muestra el formato del Paquete Solicitar Parámetros Válidos. Como sincero en la Figura 73, este tipo de paquete que se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, Código de VCP de MCCS, y de CRC. Este tipo de paquete generalmente se identifica en una modalidad como un Tipo 131, como se indica en el campo de tipo de 2 bytes. El largo de paquete, como se indica en el campo del largo de paquete de 2 bytes generalmente se establece para tener un número total de bytes en el paquete, sin incluir el campo de largo de paquete de 8. El ID de hCliente especifica nuevamente el ID de Cliente, pero se encuentra actualmente reservado para su uso posterior, como será aparente para aquellos expertos en la materia, y se establece en cero. El campo de Código de VCP de MCCS de 2 bytes contiene un valor que especifica el Parámetro de Código de Control de VCP de MCCS no continuo por consultarse. El valor en este campo debe corresponder a un control no continuo que se incrementa en el cliente. Los valores 256 a 65535 (Oxffff) típicamente se encuentran reservados o son considerados inválidos, y se consideran como un control no implementado en la respuesta de error. 31 . Paquete de Respuesta de Parámetros Válidos Un Paquete de Respuesta de Parámetros Válidos se envia 'en respuesta a un Paquete Solicitar Parámetros Válidos. Se utiliza como un medio, método, o estructura para identificar los ajustes válidos para un control no continuos de VCP de MCCS o un control que regresa el contenido de una tabla. Si el control se encontrar relacionado con una tabla en el cliente, entonces la Lista de Respuestas de Parámetros de VCP simplemente contienen la lista especifica de valores de tabla secuenciales que fueron solicitados. Si el contenido de la tabla no puede caber en un solo Paquete de Respuesta de Parámetros Válidos, entonces el cliente puede enviar múltiples paquetes con Números de Secuencia de Respuesta secuenciales. En una modalidad, un cliente indica una capacidad para soportar un Paquete de Respuesta de Parámetros Válidos utilizando el bit 13 del campo de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente. Un huésped puede solicitar el contenido de una tabla de la siguiente manera: el huésped envia un Paquete Establecer Características de VCP que contiene los parámetros necesarios o deseados tales como un parámetro de lectura/escritura, variación de LUT (tabla de consultas) , y selección de RGB; después el huésped envia un Paquete Solicitar Parámetros Válidos que especifica el control deseado; después el cliente regresa uno o más Paquetes de Respuesta de Parámetros Válidos que contienen los datos de tabla. Esta secuencia de operaciones ejecuta una función similar como las funciones de lectura de tabla descritas en el modelo de operación de MCCS. Si un parámetro de cliente específico no está soportado por el cliente, entonces en una modalidad el campo correspondiente de este paquete contendrá un valor de 255. Para los parámetros que se utilizan en el cliente, el campo correspondiente debe contener un valor del parámetro en el cliente. El formato del Paquete de Respuesta de Parámetros Válidos para una modalidad se muestra en la Figura 74. Como se observa en la Figura 74, este tipo de paquetes estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de cCliente, Código de VCP de MCCS, Código de Respuesta, Número de Secuencia de Respuesta, Valores Numéricos en Lista, Lista de Respuestas de Parámetros de VCP, y de CRC. Este tipo de paquete generalmente se identifica para una modalidad como un Tipo 132, como se indica en el campo de tipo de 2 bytes . El campo de ID de cCliente se encuentra reservado para el futuro ID de Cliente, como se sabe a partir de las discusiones anteriores, mientras que el Paquete de Código de VCP de MCCS de 3 bytes contiene un valor que especifica un Parámetro de Código de Control de VCP de MCCS no continuo que este paquete describe. Si un código de control de VCP de MCCS inválido es especificado por un Paquete Solicitar Parámetros Válidos, entonces se especifica el mismo valor de parámetro inválido en este campo con el valor apropiado en el campo de Código de Respuesta. Si el Código de Control de MCCS es inválido, entonces la Lista de Respuestas de Parámetros de VCP tendrá un largo cero. El campo de Código de Respuesta contiene 2 bytes de información o valores que especifican la naturaleza de la respuesta relacionada con la solicitud para información referente al control de VCP de MCCS especificado. Si el valor en este campo es igual a 0, entonces no se considera error alguno presente para este tipo de datos, y es enviado el último Paquete de Respuesta de Parámetros Válidos en la secuencia, tiene el Número de Secuencia de Respuesta más alto. Si el valor en este campo es igual a 1, entonces no se considera presente error alguno, pero se enviarán otros Paquetes de Respuesta de Parámetros Válidos que tengan números de secuencia más altos. Si el valor en este campo es igual a 2, entonces el control especificado no se considera incrementado en el cliente. Si el valor en este campo es igual a 3, entonces el control especificado no es un control no continuo (es un control continuo que siempre tiene un conjunto válido de todos los valores desde cero hasta su valor máximo) . Los valores para este campo igual a 4 a 65535 se encuentran reservados para su uso posterior y generalmente no se van a utilizar. El campo de Número de Secuencia de Respuesta de 2 bytes especifique el número de secuencia de los Paquetes de Respuesta de Parámetros Válidos regresados por el cliente. El cliente regresa uno o más Paquetes de Respuesta de Parámetros Válidos en respuesta a un Paquete Solicitar Parámetros Válidos. El cliente puede difundir la Lista de Respuestas de Parámetros de VCP por múltiples Paquetes de Respuesta de Parámetros Válidos. En este último caso, el cliente asignarán. Número de secuencia a cada paquete sucesivo, y establecerá el Código de Respuesta en 1 en todos excepto el último paquete en la secuencia. El último Paquete de Respuesta de Parámetros Válidos en la secuencia tendrá el Número de Secuencia de Respuesta más alto y el Código de Respuesta contiene un valor de 0. El campo de Número de Valores en Lista de 2 bytes especifica el número de valores de 16 bits que existe en la Lista de Respuestas de Parámetros de VCP. Si el Código de Respuesta no es igual a cero entonces el parámetro de Número de Valores en Lista es cero. El campo de Lista de Respuestas de Parámetros de VCP contiene una lista de 0 a 32760 valores de 2 bytes que indican el conjunto de valores válidos para el control no continuo especificado por el campo de Código de Control de MCCS. Las definiciones de los códigos de control no continuo se especifican en la Especificación de MCCS de VESA. Finalmente, en esta modalidad, el campo de CRC contiene una CRC de 16 bits de todos los bytes en el paquete incluyendo el Largo de Paquete.

Imágenes de Flujo de Video con Escala de Variación El mecanismo de protocolo o MDDI, estructura, medio, o método proporciona soporte para imágenes de flujo de video con escala de variación que le permiten al huésped enviar una imagen al cliente con una escala de variación mayor o menor que la imagen original, y la imagen con escala de variación se copia a una memoria temporal de imagen principal . Un resumen de la funcionalidad de Flujo de Video con Escala de Variación y el soporte de protocolo asociado se proporciona en otra parte. Una capacidad para soportar flujos de video con escala de variación se define por o se encuentra dentro del Paquete de Capacidad de Flujo de Video con Escala de Variación, el cual se envia en respuesta a un Paquete de Solicitud de Estado Especifico . 32. Paquete de Capacidad de Fl uj o de Video con Escala de Variación El Paquete de Capacidad de Flujo de Video con Escala de Variación define las características de la imagen fuente de flujo de video con escala de variación utilizada por un cliente. El formato del Paquete de Capacidad de Flujo de Video con Escala de Variación se muestra en términos generales en la Figura 75. Como se observa en la Figura 75, en una modalidad, un Paquete de Capacidad de Flujo de Video con Escala de Variación se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de cCliente, Número Máx. de Flujos, Tamaño Máximo de X Fuente, Tamaño Máximo de Y Fuente, Capacidad de RGB, Capacidad Monocromática, Reservado 1, Capacidad de Y Cr Cb, Reservado 2, y de CRC. El largo de paquete, en una modalidad, se selecciona para ser un fijo de 20 bytes, como se muestra en el campo de largo, incluyendo el campo de ID de cCliente de 2 bytes, el cual se encuentra reservado para su uso para un ID de Cliente, de otra manera se establece en cero, y el campo de CRC. En una modalidad, el cliente indica una capacidad de soportar el Paquete de Capacidad de Flujo de Video con Escala de Variación utilizando un valor de parámetro de 143 en la Lista de Respuestas de Parámetros Válidos del Paquete de Lista de Respuestas de Estado Válido. El campo de Número Máximo de Flujos de 2 bytes contiene un valor para identificar el número máximo de flujos de video simultáneos con escala de variación que pueden asignarse en un momento. En una modalidad, un cliente debe negar una solicitud para asignar un flujo de video con una escala de variación si el número máximo de flujos de video con escala de variación ya se encuentra asignado. Si es menor que el número máximo de flujos de video con escala de variación que se han asignado el cliente también puede negar una solicitud de asignación con base en otras limitantes de recursos en el cliente. Los campos de Tamaño Máximo de X Fuente y Tamaño de Y (2 bytes) especifican valores para el máximo ancho y altura, respectivamente, de la imagen fuente de flujo de video con escala de variación expresados como un número de pixeles. El campo de Capacidad de RGB utiliza valores para especificar el número de bits de resolución que pueden visualizarse en formato de RGB. Si el flujo de video con escala de variación no puede utilizar el formatote RGB, entonces este valor se establece igual a cero. La palabra de Capacidad de RGB se encuentra compuesta de tres valores separados sin signos con: los bits 3 a 0 que definen un número máximo de bits de azul (la intensidad de azul) en cada píxel, los bits 7 a 4 que definen el número máximo de bits de verde (la intensidad de verde) , y los bits 11 a 8 que definen el número máximo de bits de rojo (la intensidad de rojo) en cada píxel, mientras que los bits 15 a 12 se encuentran reservados para su uso posterior en futuras definiciones de capacidad, y generalmente se establecen en cero . El campo de Capacidad Monocromática de 1 byte contiene un valor que especifica el número de bits de solución que pueden visualizarse en formato monocromático. Si el flujo de video con escala de variación no puede utilizar el formato monocromático, entonces este valor se establece en cero ( ?0' ) para las aplicaciones actuales, aunque esto puede cambiar con el transcurso del tiempo, como apreciarán aquellos expertos en la materia. Los bits 3 a 0 definen el número máximo de bits de escala de grises que pueden existir en cada píxel. Estos cuatro bits hacen posible especificar que cada píxel consiste en 1 a 15 bits. Si el valor es cero, entonces el formato monocromático no está soportado por el flujo de video con escala de variación. El campo Reservado 1 (aqui de 1 byte) se encuentra reservado para su uso posterior al proporcionar valores relacionados con la información o datos de Paquete de Flujo de Video con Escala de Variación. Por lo tanto, actualmente, todos los bits en este campo se establecen en un 0' lógico. Un propósito de este campo es ocasionar que todos los campos de 2 bytes subsecuentes se alineen a una dirección de palabra de 16 bits y ocasionen que los campos de 4 bytes se alineen con una dirección de palabra de 32 bits.

El campo de Capacidad de Y Cb Cr de 2 bytes contiene valores que especifican el número de bits de resolución que pueden visualizarse en el formato de Y Cb Cr. Si el flujo de video con escala de variación no puede utilizar el formato de Y Cb Cr entonces este valor es cero. La palabra de Capacidad de Y Cb Cr se encuentra compuesta de tres valores sin signo separados: los bits 3 a 0 que definen el número máximo de bits que especifican la muestra de Cr; los bits 7 a 4 que definen el número máximo de bits que especifican la muestra de Cb; los bits 11 a 8 que definen el número máximo de bits que especifican la muestra de Y; y los bits 15 a 12 reservados para su uso posterior y generalmente establecidos en cero. El campo de Bits de Capacidad de 1 byte contiene un conjunto de banderas que especifican las capacidades asociadas con el flujo de video con escala de variación. Las banderas se definen como se expresa a continuación: el bit 0 cubre los datos de Pixel en el Paquete de Flujo de Video con Escala de Variación que pueden estar en forma empaquetada. Un ejemplo de datos de pixel empaquetados y alineados por byte se muestra con anterioridad en la Figura 12. El bit 1 se encuentra reservado para su uso posterior y generalmente se establece en cero; el bit 2 se encuentra reservado también para su uso posterior y se establece en cero; el bit 3 cubre flujos de video con escala de variación que pueden especificarse en el formato de datos de mapa de colores. Se utiliza la misma tabla de mapa de colores para los flujos de video con escala de variación que la utilizada para la memoria temporal principal de imágenes y los planos de imágenes de alfa-cursor. El mapa de colores se encuentra configurado para utilizar el Paquete de Mapa de Colores descrito en otras partes; y los bits 7 a 4 se encuentran reservados para su uso posterior y generalmente se establecen en cero. El campo Reservado 2 (aquí de 1 byte) se encuentra reservado para su uso posterior para proporcionar valores relacionados con la información o datos del Paquete de Flujo de Video con Escala de Variación. Por lo tanto, actualmente, todos los bits en este campo se establecen en 0' lógico. Un propósito de este campo es ocasionar que todos los campos subsecuentes de 2 bytes se alineen con una dirección de palabra de 16 bits y ocasionen que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits. 33. Paquete de Configuración de Flujo de Video con Escala de Variación El Paquete de Configuración de Flujo de Video con Escala de Variación se utiliza para definir los parámetros del flujo de video con escala de variación y el cliente utiliza la información para asignar almacenamiento interno para colocación en memoria temporal y escala por variación de la imagen. Un flujo puede cancelar su asignación al enviar este paquete con los campos de Tamaño de Imagen X y Tamaño de Imagen Y iguales a cero. Los flujos de video con escala de variación que han cancelado su asignación pueden reasignarse posteriormente con los mimos parámetros de flujo o diferentes. En una modalidad, un cliente indica una capacidad para soportar el Paquete de Configuración de Flujo de Video con Escala de Variación utilizando un valor de parámetro de 143 en la Lista de Respuestas de Parámetros Válidos del Paquete de Lista de Respuestas de Estado Válido, y utilizando un valor diferente a cero en el campo de Número Máximo de Flujos del Paquete de Capacidad de Flujo de Video con Escala de Variación. El formato del Paquete de Configuración de Flujo de Video con Escala de Variación se muestra en términos generales en la Figura 76. Como se observa en la Figura 76, en una modalidad, un Paquete de Configuración de Flujo de Video con Escala de Variación se estructura para tener los campos de Largo de paquete, Tipo de Paquete, hCliente, ID de Flujo, Descriptor de Formato de Datos Visuales, Atributos de Datos de Pixel, Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde inferior Y, Tamaño de Imagen X, Tamaño de Imagen Y, y CRC. El campo de Largo de Paquete de 2 bytes especifica el número total de bytes en el paquete sin incluir el campo de largo de paquete. En una modalidad, este largo de paquete se fija en 24. El campo de Tipo de Paquete de 2 bytes emplea un valor de 136 para identificar al paquete como un Paquete de Configuración de Flujo de Video con Escala de Variación. El campo de ID de hCliente de 2 bytes está reservado para su uso posterior como un ID de Cliente, y generalmente se establece en un valor de cero lógico en todos los bits por el momento, o hasta que un usuario de protocolo determine qué valores de ID se van a utilizar, como se conocerá. El campo de ID de flujo utiliza 2 bytes para especificar un identificador único para el ID de Flujo. Este valor es asignado por el huésped y oscila en valor desde cero hasta el valor máximo de ID de Flujo especificado en el Paquete de Capacidad de Cliente. El huésped debe administrar el uso de valores de ID de Flujo cuidadosamente para asegurar que a cada flujo activo se le asigna un valor único, y que a los flujos que ya no se encuentran activos se les cancela su asignación o son reasignados. En una modalidad, el campo de Descriptor de Formato de Datos de Video utiliza 2 bytes para especificar el formato de cada pixel en los Datos de Pixel en el presente flujo en el presente paquete. El formato de datos de píxel debe cumplir con al menos uno de los formatos válidos para el plano de imagen de alfa-cursor como se define en el Paquete de Capacidad de Imagen de Alfa-Cursor. El Descriptor de Formato de Datos de Video define el formato de pixel solamente para el paquete actual y no implica que se continúe utilizando un formato constante durante la vida útil de un flujo de video en particular. La Figura 11 ilustra una modalidad de cómo se codifica el Descriptor de Formato de Datos de Video, y como se describió con anterioridad para otros paquetes. En una modalidad, el campo de Atributos de Datos de Pixel de 2 bytes tiene valores que son interpretados como se explica a continuación con los bits 1 y 0 seleccionando la pantalla donde van a direccionarse los datos de pixel. Para valores de bit ?ll' o x00' los datos de pixel se visualizan para ambos ojos, para los valore de bit 10' , los datos de píxel se direccionan solamente para el ojo izquierdo, y para valores de bit ?01' , los datos de píxel se direccionan solamente par el ojo derecho. El bit 2 indica si los Datos de Pixel se encuentran o no en formato entrelazado. Cuando el bit 2 es 0, entonces los Datos de Pixel se encuentran en el formato progresivo convencional . El número de hilera (coordenada Y de píxel) se incrementa en 1 cuando se avanza de una hilera a la siguiente. Cuando el bit 2 es 1, entonces los Datos de Píxel se encuentran en formato entrelazado. El número de hilera (coordenada Y de píxel) se incrementa en 2 cuando avanza de una hilera a la siguiente. El bit 3 indica si los Datos de Pixel se encuentran o no en formato de pixel alterno. Esto es similar al modo entrelazado convencional habilitado por el bit 2, pero el entrelazado es vertical en lugar de horizontal. Cuando el bit 3 es 0, los Datos de Pixel se encuentran en el formato progresivo convencional . El número de columna (coordenada X de pixel) se incrementa en 1 conforme se recibe cada pixel sucesivo. Cuando el Bit 3 es 1, entonces los Datos de Pixel se encuentran en formato de pixel alterno. El número de columna (coordenada X de píxel) se incrementa en 2 conforme se recibe cada píxel. El Bit 4 indica si los datos de Pixel se encuentran relacionados con la pantalla o la cámara. Cuando el Bit 4 es 0, los Datos de Pixel van o provienen a/de la memoria temporal de trama de visualización. Cuando el Bit 4 es 1, los Datos de Píxel van o provienen de la cámara. El Bit 5 se encuentra reservado para su uso posterior y, por lo tanto, generalmente se establece en cero. Los Bits 7 y 6 son los Bits de Actualización de Pantalla que especifican la memoria temporal de trama donde se van a escribir los datos de píxel. Los efectos de los Bits de Actualización de Trama se describen más detalladamente en otra parte. Cuando los bits [7:6] son ?01', los datos de Pixel se escriben en la memoria temporal de imagen fuera de linea. Cuando los bits [7:6] son 00', los datos de Pixel se escriben en la memoria temporal de imagen utilizada para refrescar la pantalla. Cuando los bits [7:6] son ?ll' , los datos de Pixel se escriben en todas las memorias temporales de imagen. Si los bits [7:6] son 10', se trata como un valor inválido. Esto bits se encuentran actualmente reservados para su uso posterior. En esta situación, los datos de Pixel se ignorarían y no se escribirían en ninguna de las memorias temporales de imagen. Los bits 8 a 15 se reservan para su uso posterior y generalmente se establecen en valores o niveles de cero lógico. 34. Paquete de Reconocimi ento de Fluj o de Video con Escala de Variaci ón El Paquete de Reconocimiento de Flujo de Video con Escala de Variación le permite a un cliente el acuse de recibo de un Paquete de Configuración de Flujo de Video con Escala de Variación. El cliente puede indicar una capacidad para soportar el Paquete de Reconocimiento de Flujo de Video con Escala de Variación mediante un valor de parámetros de 143 en la Lista de Respuestas de Parámetros Válidos del Paquete de Lista de Respuestas de Estado Válido y mediante un valor diferente de cero en el campo de Número Máximo de Flujos del Paquete de Capacidad de Flujo de Video con Escala de Variación. El formato del Paquete de Reconocimiento de Flujo de Video con Escala de Variación se muestra en términos generales en la Figura 77. Como se observa en la Figura 77, en una modalidad, un Paquete de Reconocimiento de Flujo de Video con Escala de Variación se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, cCliente, ID de Flujo, Código de ACK (Reconocimiento), y de CRC. El campo de Largo de Paquete de 2 bytes se utiliza para especificar el número total de bytes, excluyendo el campo de largo de paquete, con un valor de 10 para este tipo de paquete, mientras que un Tipo de paquete de 137 identifica un paquete como un Paquete de Reconocimiento de Flujo de Video con Escala de Variación. El campo de ID de cCliente de 2 bytes se encuentra reservado para su uso posterior para el ID de Cliente, y generalmente se establece en cero. El campo de ID de Flujo de 2 bytes especifica un identificador único para la ID de Flujo. Este es el mismo valor asignado por el huésped en el Paquete de Configuración de Flujo de Video con Escala de Variación. El campo de Código de Ack de 2 bytes proporciona valores que contienen un código que describe el resultado de un intento de actualizar el flujo de video con escala de variación especificada. En una modalidad, los códigos se definen como se explica a continuación: 0 - El intento de asignación de flujo fue exitoso. 1 - el intento de cancelación de asignación de flujo fue exitoso. 2 - intento inválido de asignar un ID de flujo que ya se habla asignado. 3 - intento inválido de cancelar la asignación de un ID de flujo que ya se habla asignado. 4 - el cliente no soporta flujos de video con escala de variación 5 - los parámetros de flujo son inconsistentes con la capacidad del cliente. 6 - valor de ID de flujo mayor que el valor máximo permitido por el cliente. 7 - recursos insuficientes disponibles en el cliente para asignar el flujo especificado. El campo de CRC de 2 bytes contiene la CRC de todos los bytes en el paquete incluyendo el Largo de Paquete.

. Paquete de Fl uj o de Video con Escala de Variación El Paquete de Flujo de Video con Escala de Variación se utiliza para transmitir los datos de pixel asociados con un flujo de video con escala de variación especificada. El tamaño de la referencia de región por este paquete se define por el Paquete de Configuración de Flujo de Video con Escala de Variación. El cliente puede indicar una capacidad de soportar el Paquete de Flujo de Video con Escala de Variación mediante un valor de parámetro de 143 en la Lista de Respuestas de Parámetros Válidos del Paquete de Lista de Respuestas de Estado Válido y mediante el uso de una respuesta de asignación de flujo de video con escala de variación exitosa en el campo de Código de Ack del Paquete de Reconocimiento de Flujo de Video con Escala de Variación. El formato de una modalidad del Paquete de Flujo de Video con Escala de Variación se muestra en términos generales en la Figura 78. Como se observa en la Figura 78, un Paquete de Flujo de Video con Escala de Variación se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, ID de Flujo, CRC de Parámetro, Cuenta de Pixel, Datos de Pixel, y CRC de Datos de Pixel. El campo de Tipo de Paquete de 2 bytes utiliza un valor de 18 para identificar un paquete como un Paquete de Flujo de Video con Escala de Variación. El campo de ID de hCliente se reserva para el ID de Cliente, y generalmente se establece en cero. Como antes, el campo de ID de Flujo de 2 bytes especifica un identificador único para el ID de Flujo. Este valor se especifica por el huésped en el Paquete de Configuración de Flujo de Video con Escala de Variación y se confirma en el Paquete de Reconocimiento de Flujo de Video con Escala de Variación. El campo de Cuenta de Píxel de 2 bytes especifica el número de píxeles en el campo de Datos de Píxel citado a continuación. El campo de CRC de Parámetro de 2 bytes tiene la CRC de todos los bytes provenientes del Largo de Paquete a la Cuenta de Pixel. Si esta CRC falla en la verificación, entonces se descarta todo el paquete. El campo de Datos de Pixel de 2 bytes contiene la información de video sin procesar que va a escalarse por variación y luego a visualizarse. Los datos se formatean de la manera descrita por el campo de Descriptor de formato de Datos de Video. Los datos se transmiten una hilera a la vez como se definió con anterioridad. El campo de CRC de Datos de Píxel de 2 bytes contiene una CRC solamente de los Datos de Píxel. Si esta CRC falla en la verificación, entonces aún pueden utilizarse los Datos de Pixel pero la Cuenta de Errores de CRC se incrementa. 36. Paquete de Estado Específico de Solicitud El Paquete de Estado Especifico de Solicitud proporciona un medio, mecanismo, o método para que un huésped le solicite al cliente enviar una capacidad o paquete de estado de regreso al huésped como se especifica en este paquete. El cliente regresa el paquete del tipo especificado en el siguiente Paquete de Encapsulación de Enlace Inverso. El cliente generalmente establecerá el bit 17 en el campo de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente si el cliente tiene la capacidad de responder al Paquete de Estado Especifico de Solicitud. Un método conveniente que el huésped utiliza para determinar todos los tipos de paquetes de estado al cual pueden responder el cliente es utilizar el Paquete de Lista de Respuestas de Estado Válido descrito en otra parte. El cliente puede indicar una capacidad para responder con el Paquete de Lista de Respuesta de Estado Válido utilizando el bit 21 del campo de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente. El formato de una modalidad de un Paquete de Estado Especifico de Solicitud se muestra en términos generales en la Figura 79. Como se observa en la Figura 79, un Paquete de Estado Especifico de Solicitud se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de hCliente, ID de Paquete de Estado, y de CRC. El campo de Largo de Paquete especifica el número total de bytes en el paquete sin incluir el campo de largo de paquete, y generalmente se fija en un valor de 10 para este tipo de paquete. Un Tipo de Paquete de 138 identifica el paquete como un Paquete de Estado Especifico de Solicitud. El campo de ID de hCliente (2 bytes) se encuentra reservado para su uso posterior para un ID de Cliente, y se establece en cero por ahora, mientras que un campo de ID de Paquete de Estado de 2 bytes especifica el tipo de capacidad o paquete de estado que el cliente va a enviarle al huésped. Los tipos de paquetes típicos son: 66 - el Paquete de Capacidad de Cliente es enviado por el cliente. 133 - el Paquete de Capacidad de Imagen de Alfa-Cursor es enviado por el cliente. 139 - el Paquete de Lista de Respuestas de Estado Válido es enviado e identifica los tipos exactos de paquetes de capacidad y estado que puede enviar el cliente. 140 - el Paquete de Parámetros de Retraso de Procesamiento de Paquetes es enviado por el cliente. 141 - el Paquete de Capacidad de Cliente Personal es enviado por el cliente. 142 - el Paquete de Reporte de Error de Cliente es enviado por el cliente. 143 - el Paquete de Capacidad de Flujo de Video con Escala de Variación es enviado por el cliente. 144 - el Paquete de Identificación de Cliente es enviado por el cliente. Los Tipos de Paquete 56 a 63 pueden utilizarse para los identificadores de estado y capacidad específica al fabricante. El campo de CRC contiene nuevamente una CRC de todos los bytes en el paquete incluyendo el Largo de Paquete. 37. Paquete de Lista de Respuestas de Estado Válido El Paquete de Lista de Respuestas de Estado Válido le proporciona al huésped con una estructura, medio, o método para tener una lista de paquetes de estado y capacidad a los cuales el cliente tiene la capacidad de responder. Un cliente puede indicar una capacidad de soportar el Paquete de Lista de Respuestas de Estado Válido utilizando el bit 21 del campo de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente. El formato de una modalidad de un Paquete de Lista de Respuestas de Estado Válido se muestra en términos generales en la Figura 80. Como se observa en la Figura 80, un Paquete de Lista de Respuestas de Estado Válido se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de cCliente, Número de Valores en Lista, Lista de Respuestas de Parámetros Válidos, y de CRC. El largo de paquete para este tipo de paquete generalmente se fija en un valor de 10, y un valor de tipo de 139 identifica el paquete como un Paquete de Respuestas de Estado Válido. El campo de ID de cCliente se reserva para su uso posterior como el ID de Cliente, y generalmente se establece en cero. El campo de Número de Valores en Lista de 2 bytes especifica el número de elemento en la siguiente Lista de Respuestas de Parámetros Válidos. El campo de Lista de Respuestas de Parámetros Válidos contiene una lista de parámetros de 2 bytes que especifican los tipos de capacidad o paquetes de estado que el cliente le puede enviar al huésped. Si el cliente ha indicado que puede responderle al Paquete de Estado Especifico de Solicitud (utilizando el bit 21 del campo de Capacidad de Características de Cliente en el Paquete de Capacidad de Cliente) entonces es capaz de enviar al menos el Paquete de Capacidad de Cliente (Tipo de Paquete = 66) y el Paquete de Lista de respuestas de Estado Válido (Tipo de Paquete = 139) .

Los Tipos de Paquete que pueden enviarse por el cliente y que pueden incluirse en la lista, junto con sus respectivas asignaciones para propósitos de la modalidad, son: 66 - Paquete de Capacidad de Cliente. 133 - Paquete de Capacidad de Imagen de Alfa-Cursor. 139 - Paquete de Lista de Respuestas de Estado Válido, que identifica los tipos exactos de los paquetes de capacidad y estado que puede enviar el cliente . 140 - Paquete de Parámetros de retraso de Procesamiento de Paquetes. 141 - Paquete de Capacidad de Visualización Personal . 142 - Paquete de Reporte de Error de Cliente. 143 - Paquete de Capacidad de Flujo de Video con Escala de Variación. 144 - Paquete de Identificación de Cliente. 145 - Paquete de Capacidad de Pantalla Alterna. Los Tipos de Paquete 56 a 63 pueden utilizarse para los identificadores de estado y capacidad especifica al fabricante. El campo de CRC contiene una CRC de todos los bytes en el paquete incluyendo el Largo de Paquete. 38. Paquete de Parámetros de Retraso de Procesamiento de Paquetes El Paquete de Parámetros de Retraso de Procesamiento de Paquetes proporciona un conjunto de parámetros para permitirle al huésped calcular el tiempo requerido para completar el procesamiento asociado con la recepción de un tipo de paquete especifico. Algunos comandos enviados por el huésped no pueden ser completados por el cliente en el tiempo cero. El huésped puede consultar los bits de estado en el Paquete de Solicitud y Estado de Cliente para determinar si el cliente ha completado algunas funciones, o si el huésped puede calcular el tiempo de terminación utilizando los parámetros devueltos por el cliente en el Paquete de Parámetros de Retraso de Procesamiento de Paquetes. El cliente puede indicar una capacidad de soportar el Paquete de Parámetros de Retraso de Procesamiento de Paquetes utilizando un valor de parámetro de 140 en la Lista de Respuestas de Parámetros Válidos del Paquete de Lista de Respuestas de Estado Válido. El formato de una modalidad de un Paquete de Parámetros de Retraso de Procesamiento de Paquetes se muestra en términos generales en la Figura 81A. Como se observa en la Figura 81A, un Paquete de Parámetros de Retraso de Procesamiento de Paquetes se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de cCliente, Número de Elementos de Lista, Lista de Parámetros de Retraso, y de CRC. El largo de paquete para este tipo de paquete generalmente se fija en un valor de 10, y un tipo de valor de 140 identifica el paquete como un Paquete de Parámetros de Retraso de Procesamiento de Paquetes. El campo de ID de cCliente se reserva para su uso posterior como el ID de Cliente, y generalmente se establece en cero. El campo de Número de Elementos de Lista de 2 bytes especifica el número de elementos en la siguiente Lista de Respuestas de Parámetros Válidos. El campo de Lista de Parámetros de Retraso es una lista que contiene uno o más elementos de Lista de Parámetros de Retraso. El formato para una modalidad de un solo elemento de Lista de Parámetros de Retraso se muestra en la Figura 81B, donde se muestran los campos de Tipo de Paquete para Retraso, Retraso de Pixel, Retraso de Pixel Horizontal, Retraso de Pixel Vertical, y Retraso Fijo. Cada Elemento de Lista de Parámetros de Retraso generalmente se encuentra restringido a 6 bytes de largo, y se define adicionalmente como se explica a continuación. El campo de Tipo de Paquete para Retraso de 2 bytes especifica el Tipo de Paquete para el cual aplican los siguientes parámetros de retraso. El campo de Retraso de Pixel (1 byte) comprende un índice a un valor de retraso. El valor leído desde la tabla se multiplica por el número total de pixeles en el campo destino del paquete. El número total de pixeles es el ancho por la altura del área destino del mapa de bits referido por el paquete. El campo de Retraso de Píxel Horizontal de 1 byte contiene un valor que es un Índice a una tabla de valores de retraso (la misma tabla que DPVL) . El valor leído de la tabla se multiplica por el ancho (en pixeles) del campo de destino del paquete. El campo de Retraso de Pixel Vertical de 1 byte contiene un valor que es un índice a una tabla de valores de retraso (generalmente utiliza la misma tabla que DPVL) . El valor leido de la tabla se multiplica por la altura (en pixeles) del campo destino del paquete . El campo de Retraso Fijo utiliza 1 byte como un índice a una tabla de valores de retraso (la misma tabla que DPVL) . El valor leido de la tabla es un parámetro de retraso fijo que representa un tiempo requerido para procesar el paquete que no está relacionado con ningún valor de parámetro especificado en el paquete. El retraso total, o retraso de tiempo de terminación de procesamiento de paquete, se determina de acuerdo con la relación: Retraso = (RetrasoProcesamientoPaquete (RetrasoPixel) «PíxelesTotales) + (RetrasoProcesa ientoPaguete (RetrasoPixelHorizontal) «Ancho) + (RetrasoProcesamientoPaquete (RetrasoPixelVertical) 'Altura) + RetrasoProcesamientoPaquete (RetrasoFi o) Para algunos paquetes, los parámetros Pixeles Totales, Ancho, o Altura no aplican debido a que no están referidos en el paquete correspondiente. En esos casos, el parámetro de Retraso de Píxel correspondiente generalmente se establece en cero. 39. Paquete de Capacidad de Visualización Personal El Paquete de Capacidad de Visualización Personal proporciona un conjunto de parámetros que describen las capacidades de un dispositivo de visualización personal, tal como una pantalla instalada sobre la cabeza o lentes de visualización. Esto le permite al huésped personalizar la información de visualización de acuerdo con las capacidades específicas de un cliente. Por otra parte, un cliente indica una capacidad de enviar el Paquete de Capacidad de Visualización Personal utilizando un parámetro correspondiente en la Lista de Respuestas de Parámetros Válidos del Paquete de Lista de Respuestas de Estado Válido . El formato de una modalidad de un Paquete de Capacidad de Visualización Personal se muestra en términos generales en la Figura 82. Como se observa en la Figura 82, un Paquete de Capacidad de Visualización Personal se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de cCliente, Capa de Sub-Píxel, Forma de Píxel, Campo de Vista Horizontal, Cruce de Eje Visual, Imagen Izq./Der., Ver, Brillo Máximo, Capacidad Óptica, IPD Mínima, IPD Máxima, Puntos de Campo de Lista de Curvatura y de CRC. En una modalidad, el valor de campo de Largo de Paquete se fija en 68. Un valor de Tipo de Paquete de 141 identifica un paquete como un Paquete de Capacidad de Visualización Personal. El campo de ID de cCliente se reserva para su uso posterior y generalmente se establece en cero por ahora. El campo de capa de Sub-Pixel especifica la capa física de un sub-píxel de arriba abajo y de izquierda a derecha, utilizando los valores de: 0 para indicar que no está definida una capa de sub-píxel; 1 para indicar una raya roja, verde y azul; 2 para indicar una raya azul, verde y roja; 3 para indicar un píxel cuádruple, que tiene una configuración de sub-pixel de 2 por 2 de rojo en la izquierda superior, azul en la derecha inferior, y dos sub-pixeles verdes, uno en la izquierda superior y el otro en la derecha inferior; 4 para indicar un píxel cuadrático, con una configuración de sub-píxel de 2 por 2 de rojo en la izquierda superior, azul en la derecha inferior, y dos sub-píxeles verdes, uno en la izquierda superior y el otro en la derecha inferior; 5 para indicar una Delta (Triad) ; 6 para indicar un mosaico cubierto con rojo, verde, y azul (por ejemplo, una pantalla LCOS con color secuencial de campo) ; reservándose generalmente los valores 7 a 255 para su uso posterior. El campo de Forma de Pixel especifica la forma de cada pixel que se encuentra compuesto de una configuración específica de sub-píxeles, utilizando un valor de: 0 para indicar que no está definido una forma de sub-pixel; 1 para indicar redonda; 2 para indicar cuadrada; 3 para indicar rectangular; 4 para indicar ovalada; 5 para indicar elíptica; y reservándose los valores 6 a 255 para su uso posterior indicando las formas deseadas, como puede apreciarse por el experto en la materia. Un Campo de Vista Horizontal de 1 byte (HFOV - Horizontal Field of View) especifica el campo de vista horizontal en incrementos de 0.5 grados (por ejemplo, si el HFOV es de 30 grados, este valor es 60) . Si este valor es cero, entonces no se especifica el HFOV. Un Campo de Vista Vertical de 1 byte (VFOV -Vertical Field of View) especifica el campo de vista vertical en incrementos de 0.5 grados (por ejemplo, si el VFOV es de 30 grados, este valor es 60) . Si este valor es cero, entonces no se especifica el VFOV. Un campo de Cruce de Eje Visual de 1 byte especifica el cruce de eje visual en incrementos de 0.01 dioptría (1/m) (por ejemplo, sin el cruce axial visual es de 2.22 metros, este valor es 45). Si este valor es cero, entonces no se especifica el Cruce de Eje Axial. Un campo de Sobreponer Imagen Izquierda/Derecha de 1 byte especifica el porcentaje de sobreposición de la imagen izquierda y derecha. El rango permisible de sobreposición de imagen en porcentaje es de 1 a 100 Los valores de 101 a 255 son inválidos y generalmente no se van a utilizar. Si este valor es cero, entonces no se especifica la sobreposición de imagen. Un campo de Vista de 1 byte especifica el porcentaje de vista de la imagen. El rango permisible de vista en porcentaje es de 0 a 100. Los valores de 101 a 254 son inválidos y no se van a utilizar. Si este valor es de 255, entonces no se especifica el porcentaje de vista. Un campo de Brillo Máximo de 1 byte especifica el brillo máximo en incrementos de 20 nits (por ejemplo, si el brillo máximo es de 100 nits, este valor es de 5) . Si este valor es cero, entonces no se especifica el brillo máximo. Un campo de Banderas de Capacidad Óptica de 2 bytes contiene diversos campos que especifican las capacidades ópticas de la pantalla. Estos valores de bit generalmente se asignan de acuerdo con: Los bits 15 a 5 se reservan para su uso posterior y generalmente se establecen en un estado de cero lógico. El bit 4 selecciona el Ajuste de Foco de Lentes, dando a entender un valor de 0' que la visualización no tiene ajustes de foco de lentes, y un valor de ?l' da a entender que la visualización tiene un ajuste de foco de lentes. Los bits 3 a 2 seleccionan una Función de Binoculares de acuerdo con: un valor de 0 significa que la visualización es binocular y puede despegar solamente imágenes en 2 dimensiones (2D) ; 1 significa que la visualización es binocular y puede desplegar imágenes en 3 dimensiones (3D) ; 2 significa que la visualización es monocular, y 3 se reserva para su uso posterior. Los bits 1 a 0 seleccionan la Simetría de Curvatura de Campo Izquierdo-Derecho, con un valor de 0 refiriéndose a una curvatura de Campo no definida. Si este campo es cero, entonces todos los valores de curvatura de campo de Al a E5 se establecen en cero excepto para el punto C3, el cual especifica una distancia focal de la visualización o se va a establecer en cero para indicar que la distancia focal no se encuentra especificada. Un valor de 1 significa que las visualizaciones Izquierda y Derecha tienen la misma simetría; 2 significa que las visualizaciones Izquierda y Derecha se reflejan en el eje vertical (columna C) ; y 3 se reserva para su uso posterior. El campo de Distancia Minima Inter-Pupilar (IPD)de 1 byte especifica la distancia minima inter-pupilar en milímetros (mm) . Si este valor es cero, entonces no se especifica la distancia minima inter-pupilar. El campo de Distancia Máxima Inter-Pupilar (IPD)de 1 byte especifica la distancia mínima inter-pupilar en milímetros (mm) . Si este valor es cero, entonces no se especifica la distancia inter-pupilar máxima . El campo de Puntos de Lista de Curvatura de Campo contiene una lista de 25 parámetros de 2 bytes que especifican la distancia focal en milésimos de una dioptría (1/m) con un rango de 1 a 65535 (por ejemplo, 1 es 0.001 dioptrías y 65535 es 65.535 dioptrías) . Los 25 elementos en la Lista de Curvatura de Campo se etiquetan como Al a E5 como se muestra en la Figura 83. Los puntos se van a distribuir uniformemente en el área activa de la pantalla. La columna C corresponde aleje vertical de la pantalla y la hilera 3 corresponde al eje horizontal de la pantalla. Las columnas A y E corresponden a los bordes izquierdo y derecho de la pantalla, respectivamente. Y las hileras 1 y 5 corresponden a los bordes superior e inferior de la pantalla, respectivamente. El orden de los 25 puntos en la lista es: Al, Bl, Cl, DI, El, A2, B2, C2, D2, E2, A3, B3, C3, D3, E3, A4, B4, C4, D4, E4, A5, B5, C5, D5, E5. El campo de CRC contiene una CRC de todos los bytes en el paquete incluyendo el Largo de Paquete. 40. Paquete de Reporte de Error de Cliente El Paquete de Reporte de Error de Cliente actúa como un mecanismo o medio que le permite proporcionarle al cliente proporcionar una lista de errores operativos. El cliente puede detectar un amplio rango de errores en el transcurso de su operación normal como resultado de la recepción de algunos comandos provenientes del huésped. Los ejemplos de estos errores incluyen: el cliente pudo haber recibido la orden de operar en un modo que no soporta, el cliente pudo haber recibido un paquete que contiene algunos parámetros que se encuentran fuera de rango o que están más allá de la capacidad del cliente, el cliente pudo haber recibido la orden de entrar a un modo en una secuencia inapropiada. Puede utilizarse el Paquete de Reporte de Error de Cliente para detectar los errores durante la operación normal, pero es más útil para el diseñador e integrador de sistemas diagnosticar problemas en el desarrollo e integración de los sistemas de huésped y cliente. Un cliente indica su capacidad de enviar un Paquete de Reporte de Error de Cliente utilizando un valor de parámetro de 142 en la Lista de Respuesta de Parámetros Válidos del Paquete de Lista de Respuestas de Estado Válido. El formato de una modalidad de un Paquete de Reporte de Error de Cliente se muestra en términos generales en la Figura 84A. Como se observa en la Figura 84A, un Paquete de Reporte de Error de Cliente se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de cCliente, Número de Elementos de Lista, Lista de Códigos de Error, y de CRC. Un valor de Tipo de Paquete de 142 identifica un paquete como un Paquete de Reporte de Error de Cliente. El campo de ID de cCliente se reserva para su uso posterior y generalmente se establece en cero por ahora. El campo de Número de Elementos de Lista (2 bytes) especifica el número de elementos en la siguiente Lista de Códigos de Error. El campo de Lista de Códigos de Error (aquí 8 bytes) es una lista que contiene uno o más elementos de Lista de Reporte de Error. El formato de un solo elemento de Lista de Reporte de error se muestra en la Figura 87B. En una modalidad, como se muestra en la Figura 87B, cada Elemento de Lista de Reporte de Error es de exactamente 4 bytes de largo, y tiene una estructura en una modalidad que comprende: un campo de Código de Error de Visualización de 2 bytes que especifica el tipo de error que se reporta, un campo de Sub-código de Error de 2 bytes especifica un mayor nivel de detalle respecto al error definido por el paquete de Código de Error de Cliente. La definición específica de cada Código de Error de Cliente se define por el fabricante del cliente. Un Sub-código de Error no tiene que definirse para cada Código de Error de Visualización, y en esos casos donde no se encuentra definido el Sub-código de Error, el valor se establece en cero. La definición de especificación de cada Sub-código de Error se define por el fabricante del cliente . 41 . Paquete de Identificación de Cliente El Paquete de Identificación de Cliente le permite al cliente regresar los datos de identificación en respuesta al Paquete de Solicitud de Estado Específico. En una modalidad, un cliente indica una capacidad de enviar el Paquete de Identificación de Cliente utilizando un valor de parámetro de 144 en la Lista de Respuestas de Parámetros Válidos del Paquete de Lista de Respuestas de Estado Válido. Es útil que el huésped sea capaz de determinar el nombre del fabricante del dispositivo cliente y número de modelo al leer estos datos provenientes del cliente. La información puede utilizarse para determinar si el cliente tiene capacidades especiales que no pueden describirse en el Paquete de Capacidad de Cliente. Existen potencialmente dos métodos, medios, o mecanismos para leer la información de identificación del cliente. Uno es mediante el uso del Paquete de Capacidad de Cliente, el cual contiene campos similares a aquellos en la estructura de EDID base. El otro método es mediante el uso del Paquete de Capacidad de Cliente que contiene un conjunto más rico de información en comparación con campos similares en el Paquete de Capacidad de Cliente. Esto le permite a un huésped identificar a los fabricantes a los que no se les ha asignado un código de EISA de 3 caracteres, y permite que los números de serie contengan caracteres alfanuméricos . El formato de una modalidad de un Paquete de Identificación de Cliente se muestra en términos generales en la Figura 85. Como se observa en la Figura 85, un Paquete de Identificación de Cliente se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de cCliente, Semana de fabricación, Año de Fabricación, Largo de Nombre de Fabricación, Largo de Nombre del Producto, Largo de Número de Serie, Cadena de Nombre del Fabricante, Cadena de Nombre del Producto, Cadena de Número de Serie, y de CRC. El campo de Tipo de Paquete de 2 bytes contiene un valor que identifica el paquete como un Paquete de Identificación de Cliente. Este valor se selecciona para que sea 144 en una modalidad. El campo de ID de cCliente (2 bytes) nuevamente se reserva para su uso posterior para el ID de Cliente, y generalmente se establece en cero. El campo de CRC (2 bytes) contiene una CRC de 16 bits de todos los bytes en el paquete incluyendo el Largo de Paquete. Un campo de Semana de Fabricación de 1 byte contiene un valor que define la semana de fabricación de la pantalla. Al menos en una modalidad, este valor se encuentra en el rango de 1 a 53 si es soportad por el cliente. Si este campo no es soportado por el cliente, entonces generalmente se establece en cero. Un campo de Año de fabricación de 1 byte contiene un valor que define el año de fabricación del cliente (pantalla) . Este valor es una variación del año 1990 como punto inicial, aunque pueden utilizarse otros años base. Pueden expresarse por este campo los años en el rango de 1991 a 2245. Ejemplo: el año 2003 corresponde a un valor de 13 de Año de Fabricación. Si este campo no es soportado por el cliente debe establecerse en un valor de cero . Cada uno de los campos de Largo de Nombre de Fabricante, Largo de Nombre del Producto, y Largo de Número de Serie contiene valores de 2 bytes que especifican el largo del campo de Cadena de Nombre del Fabricante incluyendo cualquier carácter de terminación nula o de relleno nulo, el largo del campo de Cadena de Nombre del Producto incluye cualquier carácter de terminación nula o de relleno nulo, y el largo del campo de Cadena de Número de Serie que incluye cualquier carácter de terminación nula o de relleno nulo, respectivamente. Cada uno de los campos de Cadena de Nombre del Fabricante, Cadena de Nombre del Producto, y Cadena de Número de Serie contiene un número variable de bytes especificados por los campos de Largo del Nombre del Fabricante, Nombre del Producto, y Número de Serie, respectivamente, que contienen una cadena de ASCII que especifica el fabricante, nombre del producto, y número de serie alfanumérico de la pantalla, respectivamente. Cada una de estas cadenas se termina por al menos un carácter nulo. 42. Paquete de Capacidad de Pantalla Alterna El Paquete de Capacidad de Pantalla Alterna indica la capacidad de las pantallas alternas anexas al controlador de clientes de MDDI. Se envía en respuesta a un Paquete de Solicitud de Estado Especifico. Cuando es invitado, un dispositivo cliente envía un Paquete de Capacidad de Pantalla Alterna para cada pantalla alterna soportada. El cliente puede indicar una capacidad de enviar el Paquete de Capacidad de Pantalla Alterna mediante un valor de parámetro de 145 en la Lista de Respuestas de Parámetros Válidos del Paquete de Lista de Respuestas de Estado Válido. Para los sistemas de MDDI operados en modo interno puede ser común el tener más de una pantalla conectada a un controlador de clientes de MDDI. Una aplicación a manera de ejemplo es un teléfono móvil con una pantalla grande al interior de la parte abatible y una pantalla más pequeña en el exterior. No es necesario para un modo interno que el cliente regrese un Paquete de Capacidad de Pantalla Alterna por dos razones potenciales. Primera, el huésped puede estar ya programado o de otra manera informado de las capacidades durante la fabricación dado que se utilizan en un dispositivo o alojamiento común. Segundo, debido al ensamble de las dos, el cliente no puede desconectarse o separarse fácilmente de una conexión al huésped, y el huésped puede contener una copia codificada de manera no flexible de las capacidades del cliente, o al menos saber que no cambian con un cambio en el cliente, como pudiese eventualmente ocurrir. El campo de Número de Pantallas del Paquete de Capacidad de Cliente se utiliza para reportar que se encuentra conectada más de una pantalla y el Paquete de Capacidad de Pantalla Alterna reporta la capacidad de cada pantalla alterna. El paquete de flujo de video contiene 4 bits en el campo de Atributos de Datos de Píxel para direccionar cada pantalla alterna en el dispositivo cliente. El formato de una modalidad de un Paquete de Capacidad de Pantalla Alterna se muestra en términos generales en la Figura 89. Como se observa en la Figura 86, un Paquete de Capacidad de Pantalla Alterna se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de cCliente, Número de Pantallas Alt, Reservado 1, Ancho de Mapa de Bits, Altura de Mapa de Bits, Ancho de Ventana de Pantalla, Altura de Ventana de Pantalla, Ancho de RGB de Mapa de Colores, Capacidad de RGB, Capacidad Monocromática, Reservado 2, Capacidad de Y Cb Cr, Capacidad de Características de Pantalla, Reservado 3, y de CRC. Un valor de tipo de paquete de 145 identifica un paquete como un Paquete de Capacidad de Pantalla Alterna. El campo de ID de cCliente se reserva para un ID de Cliente para su uso posterior y generalmente se establece en cero. El campo de Número de Pantallas Alt utiliza 1 byte para indicar la identidad de la pantalla alterna con un entero en el rango de 0 a 15. La primera pantalla alterna se designa típicamente como el 0 y las demás pantallas alternas se identifican con valores únicos del Número de Pantallas Alt con el valor más grande utilizado como el número total de pantallas alternas menos 1. Los valores mayores que el número total de pantallas alternas menos 1 no se utilizan. Ejemplo: un teléfono móvil que tiene una pantalla primaria y una pantalla de ID de la parte que llama conectada a un cliente de MDDI tiene una pantalla alterna, de manera que el Número de Pantallas Alt de la pantalla de ID de la parte que llama es cero y el campo de Número de Pantallas Alt del Paquete de Capacidad de Cliente tiene un valor de 1. El campo Reservado 1 (1 bytes) se reserva para su uso posterior. Todos los bits en este campo se establecen en cero. Un propósito de este campo es ocasionar que todos los campos subsecuentes de 2 bytes se alineen con una dirección de palabra de 16 bits y ocasionar que los campos de 4 bytes se alineen con una dirección de palabra de 32 bits. El campo de Ancho de Mapa de Bits utiliza 2 bytes que especifican el ancho del mapa de bits expresado como un número de pixeles. El campo de Altura de Mapa de Bits utiliza 2 bits que especifican la altura del mapa de bits expresada como un número de pixeles . El campo de Ancho de Ventana de Pantalla utiliza 2 bytes que especifican el ancho de la ventana de pantalla expresada como un número de pixeles. El campo de altura de ventana de pantalla utiliza 2 bytes que especifican la Altura de Ventana de Pantalla expresada como un número de pixeles. El campo de Ancho de RGB de Mapa de Colores utiliza 2 bytes que especifican el número de bits de los componentes de color rojo, verde, y azul que pueden visualizarse en el modo de visualización de mapa de colores (paleta) . Puede utilizarse un máximo de 8 bits para cada componente de color (rojo, verde, y azul) . A pesar de que se envían 8 bits de cada componente de color en el Paquete de Mapa de Colores, solamente se utiliza el número de bits menos significativos de cada componente de color definido en este campo. Si el cliente de pantalla no puede utilizar el formato de mapa de colores (paleta), entonces este valor es cero. La palabra de Ancho de RGB de mapa de colores se encuentra compuesta de tres valores separados sin signo : Los bits 3 a 0 definen el número máximo de bits de azul en cada píxel, considerándose los valores de 0 a 8 como válidos . Los bits 7 a 4 definen el número máximo de bits de verde en cada píxel, considerándose los valores de 0 a 8 como válidos. Los bits 11 a 8 definen el número máximo de bits de rojo en cada pixel, considerándose los valores de 0 a 8 como válidos. Los bits 14 a 12 se reservan para su uso posterior y generalmente se establecen en cero. El bit 15 se utiliza para indicar la capacidad de un cliente de aceptar los datos de píxel de Mapa de Colores en forma empaquetada o no empaquetada. Cuando el bit 15 se establece en un nivel de uno lógico, esto indica que el cliente puede aceptar los datos de píxel de Mapa de Colores sea en formato empaquetado o no empaquetado . Si el bit 15 se establece en un cero lógico, esto indica que el cliente puede aceptar datos de píxel de Mapa de Colores solamente en formato no empaquetado. El campo de Capacidad de RGB utiliza 2 bytes para especificar el número de bits de resolución que pueden visualizarse en formato de RGB. En una modalidad, si el cliente no puede utilizar el formato de RGB, entonces este valor se establece igual a cero. La palabra de capacidad de RGB está compuesta de tres valores sin signo separados: los Bits 3 a 0 definen el número máximo de bits de azul (la intensidad de azul) en cada pixel, los Bits 7 a 4 definen el número máximo de bits de desde (la intensidad de verde) en cada píxel, y los Bits 11 a 8 definen el número máximo de bits de rojo (la intensidad de rojo) en cada pixel. Los Bits 14 a 12 se reservan para su uso posterior y se establecen en cero. El Bit 15 se utiliza para indicar la capacidad de un cliente para aceptar los datos de pixel de RGB en formato empaquetado o no empaquetado. Cuando el bit 15 se establece en un nivel de uno lógico, esto indica que el cliente puede aceptar los datos de píxel de RGB sea en formato empaquetado o no empaquetado. Si el bit 15 se establece en un cero lógico, esto indica que el cliente puede aceptar los datos de pixel solamente en formato no empaquetado. El campo de Capacidad Monocromática de 1 byte contiene un valor o información para especificar el número de bits de resolución que pueden visualizarse en formato monocromático. Si el cliente no puede utilizar el formato monocromático, entonces este valor se establece igual a cero. Los bits 6 a 4 se encuentran reservados para su uso posterior y generalmente se establecen en cero. Los bits 3 a 0 definen el número máximo de bits de escala de grises que pueden existir en cada píxel. Estos cuatro bits hacen posible especificar que cada píxel consista de 1 a 15 bits. Si el valor es cero, entonces el formato monocromático no es soportado por el cliente. El bit 7 cuando se establece en uno indica que el cliente puede aceptar datos de pixel monocromático sea en formato empaquetado o no empaquetado. Si el bit 7 se establece en cero, esto indica que el cliente puede aceptar datos de pixel monocromático solamente en formato no empaquetado. El campo Reservado 2 es un campo con un ancho de 1 byte reservado para su uso posterior y generalmente tiene todos los bits en este campo establecidos a un nivel de cero lógico. En una modalidad, un propósito de este campo es ocasionar que todos los campos subsecuentes de 2 bytes se alineen con una dirección de palabra de 16 bits y ocasionar que los campos de 4 bytes se alineen con una dirección de palabra de 32 bits. Un campo de Capacidad en Y Cb Cr de 2 bytes especifica el número de bits de resolución que pueden visualizarse en el formato de Y Cb Cr. Si el cliente no puede utilizar el formato de Y Cb Cr, entonces este valor es cero. La palabra de Capacidad de Y Cb Cr se encuentra compuesta de tres valores sin signo separados : los bits 3 a 0 definen el número máximo de bits que especifican la muestra de Cb, los bits 7 a 4 definen el número máximo de bits que especifican la. muestra de Cr, a los bits 11 a 8 definen el número máximo de bits que especifican la muestra de Y, en los bits 14 a 12 se reservan para su uso posterior y se establecen en cero. Cuando el bit 15 se establece en uno indica que el cliente puede aceptar los datos de pixel de Y Cb Cr sea en formato empaquetado o no empaquetado. Si el bit 15 se establece en cero, esto indica que el cliente puede aceptar los datos de pixel de Y Cb Cr solamente en formato no empaquetado. Un campo de Capacidad de Bayer de 2 bytes especifica el número de bits de resolución, grupo de pixel, y orden de pixel que pueden transferirse en formato Bayer. Si el cliente no puede utilizar el formato Bayer, entonces este valor se establece en cero. El campo de Capacidad de Bayer se encuentra compuesto de los siguientes valores: los bits 3 a 0 definen el número máximo de bits de intensidad que existen en cada píxel, los bits 5 a 4 definen el patrón de grupo de píxel que puede requerirse, los bits 8 a 6 definen un orden de píxel requerido, y los bits 14 a 9 se reservan para su uso posterior y se establecen en cero. Cuando el bit 15 se establece en uno indica que el cliente puede aceptar los datos de píxel de Bayer sea en formato empaquetado o no empaquetado. Si el bit 15 se establece en cero, esto indica que el cliente puede aceptar los datos de pixel de Bayer solamente en formato no empaquetado. El campo de CRC que 2 bytes contiene una CRC de 16 bits de todos los bytes en el paquete incluyendo el Largo de Paquete. 43. Paquete de Acceso de Registro El Paquete de Acceso de Registro proporciona sea un huésped o un cliente con un medio, mecanismo, o método para accesar los registros de configuración y estado en el extremo opuesto del enlace de MDDI . Es probable que estos registros sean únicos para cada pantalla o controlador de dispositivo. Estos registros ya existen en muchas pantallas que requieren configuraciones de ajustes, modos de operación, y tener otras configuraciones útiles y necesarias. El paquete de acceso de registro le permite al huésped o cliente de MDDI o ambos escribir en un registro y solicitar la lectura de un registro utilizando el enlace de MDDI. Cuando el huésped o cliente solicita leer un registro el extremo opuesto de responder enviando los datos de registro en el mismo tipo de paquete, pero indicando también que estos son los datos leídos desde un registro particular con el uso del campo de Info Lectura/Escritura. El Paquete de Acceso de Registro puede utilizarse para leer o escribir múltiples registros especificando una cuenta de registro mayor que 1. Un cliente indica una capacidad para soportar el Paquete de Acceso de Registro utilizando el bit 22 del campo de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente.

El formato de una modalidad de un Paquete de Acceso de Registro se muestra en términos generales en la Figura 87. Como se observa en la Figura 87, un Paquete de Acceso de Registro se estructura para tener los campos de Largo de Paquete, Tipo de Paquete, ID de bCliente, Banderas de Lectura/Escritura, Dirección de Registro, CRC de Parámetro, Lista de Datos de Registro y CRC de Datos de Registro. Un valor de tipo de paquete de 146 identifica un paquete como el Paquete de Acceso de Registro. El campo de ID de bClíente se reserva para su uso posterior y generalmente se establece en cero por ahora. El campo de Banderas de Lectura/Escritura de 2 bytes especifica el paquete especifico como de lectura, o de escritura, o una respuesta a una lectura, y proporciona una cuenta de los valores de datos. Los bits 15 a 14 actúan como Banderas de Lectura/Escritura. Si los bits [15:14] son x00', entonces este paquete contiene datos por escribirse en un registro direccionado por el campo de Dirección de Registro. Los datos por escribirse en los registros especificados se encuentran contenidos en e'l campo de Lista de Datos de Registro. Si los bits [15:14] son 10', entonces esta es una solicitud para datos provenientes de uno o más registros direccionados por el campo de Dirección de Registro. Si los bits [15:14] son ll', entonces ese paquete contiene datos que fueron solicitados en respuesta a un Paquete de Acceso de Registro que tiene los bits 15:14 de las Banderas de Lectura/Escritura establecidas en 10' . El campo de Dirección de Registro contiene la dirección del registro correspondiente al elemento de Lista de Datos de Registro, y el campo de Lista de Datos de Registro contiene datos que fueron leídos desde la dirección o direcciones. Si los bits [15:14] son ?01', se trata como un valor inválido, este valor se reserva para su uso posterior y no se utiliza en este momento, pero aquellos expertos en la materia comprenderán como emplearlos para futuras aplicaciones . Los bits 13:0 utilizan un entero sin signo de 14 bits para especificar el número de elementos de Datos de Registro de 32 bits por transferirse en el campo de Lista de Datos de Registro. Si los bits 15:14 son iguales a ?00', entonces los bits 13:0 especifican el número de elementos de datos de registro de 32 bits que se encuentran contenidos en el campo de Lista de Datos de Registro por escribirse en los registros comenzando en el registro especificado por el campo de Dirección de Registro. Si los bits 15:14 son iguales a ?10', entonces los bits 13:0 especifican el número de elementos de datos de registro de 32 bits que el dispositivo de recepción le envía a un dispositivo que solicita la lectura de los registros. El campo de Lista de Datos de Registro en este paquete no contiene ningún elemento y tiene un largo de cero. Si los bits 15:14 son iguales a ?ll', entonces los bits 13:0 especifican el número de elementos de datos de registro de 32 bits que se han leido desde los registros que se encuentran contenidos en el campo de Lista de Datos de Registro. Los bits 15:14 actualmente no se encuentran establecidos como iguales a x01', el cual se considera un valor inválido, y de otra manera están reservados para designaciones o uso posteriores. El campo de Dirección de Registro utiliza 4 bytes para indicar la dirección de registro que será escrita o leída. Para los registros de direccionamiento cuyo direccionamiento es menor que 32 bits, los bits superiores se establecen en cero. El campo de CRC de Parámetro de 2 bytes contiene una CRC de todos los bytes desde el Largo de Paquete hasta la Dirección de Registro. Si esta CRC falla la verificación, entonces se descarta todo el paquete . El campo de Lista de Datos de Registro contiene una lista de valores de datos de registro de 4 bytes por escribirse en registros de cliente o valores que fueron leídos desde los registros de dispositivo cliente. El campo de CRC de Datos de Registro de 2 bytes contiene una CRC de solamente la Lista de Datos de Registro. Si esta CRC falla la verificación, entonces aún pueden utilizarse los Datos de registro, pero se incrementa la cuenta de errores de CRC.

D. CRC de Paquete Los campos de CRC aparecen al final de los paquetes y algunas veces después de ciertos parámetros más críticos en paquetes que pueden tener un campo de datos significativamente grande, y consecuentemente, una probabilidad incrementada de errores durante la transferencia. En los paquetes que tienen dos campos de CRC, el generador de CRC, cuando solamente se utiliza uno, se reinicializa después de la primera CRC de manera que los cálculos de CRC subsecuentes a un campo de datos grande no se ven afectados por los parámetros al inicio del paquete. En una modalidad a manera de ejemplo, el polinomio utilizado para el cálculo de CRC es conocido como CRC-16, o XI6 + X15 + X2 + XO . En la Figura 36 se muestra una implementación a manera de ejemplo de un generador y verificador 3600 de CRC útil para implementar a invención. En la Figura 36, se inicializa un registro 3602 de CRC en un valor de 0x0001 justo antes de la transferencia de primer bit de un paquete que se ingresa a la línea Tx_MDDI_Datos_Antes_CRC, después los bytes del paquete se desplazan al inicio del registro con el primer LSB. Observe que los números de bit de registro en esta figura corresponden al orden del polinomio utilizado, y no las posiciones de bit utilizadas por la MDDI. Es más eficiente desplazar el registro de CRC en una sola dirección, y esto da como resultado un bit 15 de CRC en la posición de bit 0 del campo de CRC de MDDI, y el bit 14 del registro de CRC en la posición de bit 1 del campo de CRC de MDDI, etcétera hasta que se alcanza la posición de bit 14 de MDDI. Como ejemplo, si el contenido del paquete para los Paquetes de Solicitud y Estado de Cliente es: 0x000c, 0x0046, 0x000, 0x0400, 0x00, 0x00, 0x000 (o se representan como una secuencia de bytes como: 0x0c, 0x00, 0x46, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00) , y se envian utilizando las entradas de los multiplexores 3604 y 3606, y la compuerta NAND 3608, la salida de CRC resultante en la línea Tx MDDI Datos Con CRC (Tx MDDI Data With CRC) es 0xd9aa (o se representa como una secuencia como Oxaa, 0xd9) . Cuando el generador y verificador de CRC 3600 se configura como un verificador de CRC, la CRC recibida en la linea Rx_MDDI__Datos se toma como entrada para el multiplexor 3604 y la compuerta OR exclusiva (XOR) 3612, y se compara bit por bit con el valor encontrado en el registro de CRC utilizando la compuerta ÑOR 3610, la compuerta AND 3608, y la compuerta AND 3614. Si existiese algún error, como salida por la compuerta de AND 3614, la CRC se incrementa una vez para cada paquete que contiene un error de CRC al conectar la salida de la compuerta 3614 con la entrada del registro 3602. Observe que el circuito a manera de ejemplo mostrado en el diagrama de la Figura 36 puede entregar como salida más de una señal de error de CRC en una ventana VERIFICAR_CRC_AHORA (CHECK_CRC_NO ) (ver la Figura 37B) . Por lo tanto, el contador de errores de CRC generalmente solo cuenta la primera instancia de error de CRC dentro de cada intervalo donde VERIFICAR_CRC_AHORA se encuentra activa. Si se configura como un generador de CRC, la CRC se sincroniza fuera del registro de CRC al momento de coincidir con el final del paquete. La sincronización para las señales de entrada y salida, y las señales de habilitación se ilustran gráficamente en las Figuras 37A y 37B. La generación de una CRC y la transmisión de un paquete de datos se muestra en la Figura 37A con el estado (0 o 1) de las señales Gen_Restablecer (Gen_Reset) , Verificar_CRC_Ahora (Check_CRC_Now) , Generar_CRC_Ahora (Generate_CRC_Now) , y Enviar_MDDI_Datos (Sending_MDDI_Datos) , junto con las señales Tx_MDDI_Datos_Antes_CRC (Tx_MDDI_Data_Before_CRC) y Tx_MDDI_Datos_Con_CRC (Tx_MDDI_Data_With_CRC) . La recepción de un paquete de datos y verificación del valor de CRC se muestran en la Figura 37B, con el estado de las señales Gen_Restablecer, Verificar_CRC_Ahora, Generar__CRC_Ahora, y Enviar_MDDI_Datos, junto con los Rx_MDDI_Datos y de error de CRC.

E. Sobrecarga de Código de Error para CRC de Paquete En cualquier momento que se transfieran solamente paquetes de datos y la CRC entre el huésped y el cliente, no se aloja ningún código de error. El único error es una pérdida de sincronización. De otra manera, uno tiene que esperar a que expire el enlace derivado de una falta de trayectoria o tubería de transferencia de datos buenos y reestablecer después el enlace y proceder. Desafortunadamente, esto requiere mucho tiempo y es un tanto ineficiente. Para su uso en una modalidad, se ha desarrollado una nueva técnica en la cual la porción de CRC de paquetes se utiliza para transferir información de código de error. Esto se muestra en términos generales en la Figura 65. Es decir, se generan uno o más códigos de error por los procesadores o dispositivos que manejan la transferencia de datos que indica errores o desperfectos predefinidos específicos que pudiesen ocurrir en el procesamiento de comunicaciones o enlace. Cuando se encuentra un error, el código de error apropiado se genera y se transfiere utilizando los bits para la CRC de un paquete. Es decir, el valor de CRC se sobrecarga, o sobrescribe, con el código de error deseado, el cual puede detectarse en el extremo receptor por un monitor o verificador de errores que monitorea los valores del campo de CRC. Para aquellos casos en los cuales el código de error corresponde con el valor de CRC por alguna razón, el cumplido del error se transfiere a fin de evitar la confusión. En una modalidad, proporcionar un sistema robusto de detección y notificación de errores, el código de error puede transferirse varias veces, utilizando una serie de paquetes, generalmente todos, que se transfieren o envían después de que se ha detectado el error. Esto ocurre hasta el punto en que la condición que crea el error se limpia del sistema, punto en el que los bits de CRC regular se transfieren sin sobrecarga por otro valor. Esta técnica para sobrecargar el valor de CRC proporciona una respuesta mucho más rápida a los errores del sistema aunque utiliza una cantidad mínima de bits o campos extras. Como se muestra en la Figura 66, se muestra un mecanismo o aparato 6600 de sobreescritura de CRC que utiliza un detector o medio 6602 de detección de errores, el cual puede formar parte de otra circuitería descrita o conocida con anterioridad, detecta la presencia o existencia de errores dentro del enlace o proceso de comunicaciones. Un generador o medio 6604 de código de error, el cual puede formarse como parte de otra circuitería o técnicas de uso tales como tablas de consulta que almacenen mensajes de error preseleccionados, genera uno o más códigos de error para indicar errores o desperfectos predefinidos específicos que se han detectado que ocurren. Se comprende fácilmente que los dispositivos 6602 y 6604 pueden formarse como un solo circuito o dispositivo según se desee, o como parte de una secuencia programada de pasos para otros procesadores y elementos conocidos . Un comparador o medio 6606 de comparación de valor de CRC se muestra para verificar si el código o códigos de error seleccionado (s) es (son) igual (es) al valor de CRC que se transfiere. Si este es el caso, entonces se utiliza un generador o medio de generación o dispositivo de cumplido de código para proporcionar el cumplido de los códigos de error a fin de no ser malinterpretados como el patrón o valor original de CRC ni de confundir o complicar el esquema de detección. Un selector de código de error o elemento o dispositivo 6610 de medio de selección selecciona después el código o valor de error que desea insertar o sobrescribir, o sus respectivos cumplimientos según sea apropiados. Un sobre-escritor de CRC de código de error o mecanismo o medio 6612 de sobre-escritura es un dispositivo que recibe el flujo, paquetes de datos, y los códigos deseados por insertarse y sobrescribe los valores de CRC correspondientes o apropiados, con objeto de transferirle los códigos de error deseados a un dispositivo de recepción. Como se mencionó, el código de error puede transferirse varias veces, utilizando una serie de paquetes, de manera que el sobre-escritor 6612 puede utilizar elementos de almacenamiento de memoria con objeto de mantener copias de los códigos durante el procesamiento o para volver a llamar a estos códigos desde elementos anteriores u otras ubicaciones de almacenamiento conocidas que puedan utilizarse par almacenar o mantener su valor según sea necesario, o como se desee. El procesamiento general del mecanismo de sobreescritura de la Figura 66 implementado se muestra detalladamente de manera adicional en las Figuras 67A y 67B. En la Figura 67A se detecta un error, uno o más, en el paso 6702 en los datos o proceso de comunicaciones y se selecciona un código de error en el paso 6704 para indicar esta condición. Al mismo tiempo, o en un punto apropiado, el valor de CRC por reemplazarse se verifica en un paso 6706, y se compara con el código de error deseado en el paso 6708. El resultado de esta comparación, como se describe con anterioridad, es una determinación sobre si el código deseado o no, u otros valores representativos, serán iguales al presente valor de CRC. Si este es el caso, entonces el procesamiento procede a un paso 6712 donde el complemento, o en algunos casos otro valor representativo, según se desee, se seleccione como el código por insertar. Una vez que se ha determinado que códigos de error o valores van a insertarse en los pasos 6710 y 6714, ese código apropiado es seleccionado para la inserción. Estos pasos se ilustran separados para propósitos de claridad pero generalmente representan una sola elección con base en la salida de la decisión del paso 6708. Finalmente, el paso 6716 los valores apropiados se sobrescriben en la ubicación de CRC para la transferencia con los paquetes seleccionados como objetivo por el proceso. En la parte de recepción del paquete, como se muestra en la Figura 67B, los valores de CRC de paquetes se monitorean en un paso 6722. En términos generales, los valores de CRC se monitorean por uno o más procesos dentro del sistema a fin de determinar si ha ocurrido un error en la transferencia de datos y si se solicita o no una retransmisión del paquete o paquetes, o se inhiben operaciones adicionales y demás, algunas de las cuales se describen con anterioridad. Como parte de tal monitoreo la información también puede utilizarse para comparar valores con códigos de error conocidos o preseleccionados, y detectar la presencia de errores. Alternativamente, puede implementarse un proceso y monitor separados de detección de errores. Si un código se encuentra presente se extrae o de otra manera se observa en el paso 6724 para su procesamiento adicional. Puede realizarse una determinación en el paso 6726 sobre si este es el código actual o un complemento, en cuyo caso se utiliza un paso adicional 6728 para traducir el valor con el valor de código deseado. En cualquier caso el código extraído resultante, complemento, u otros valores recuperados se utilizan después para detectar que error ha ocurrido a partir del código transmitido en el paso 6730.

V. Hibernación de Enlace El enlace de MDDI puede ingresar al estado de hibernación rápidamente y despertar de la hibernación rápidamente. Esta sensibilidad le permite a un sistema o dispositivo de comunicaciones forzar al enlace de MDDI a hibernación frecuentemente a fin de reducir el consumo de energía, dado que puede despertarse nuevamente para su uso muy rápidamente. En una modalidad, dado que un cliente de modo externo se despierta de la hibernación por primera vez lo hace a una tasa de datos y con una sincronización de impulsos estroboscópicas que es consistente con una tasa de 1 Mbps, es decir, el par MDDI_Stb debe cambiar a una tasa de 500 kHz. Una vez que las características del cliente han sido descubiertas o comunicadas al huésped, entonces el huésped puede despertar el enlace generalmente a cualquier casa desde 1 Mbps hasta la tasa máxima a la cual puede operar el cliente. Pueden despertar a cualquier tasa que pueda operar tanto en el huésped como el cliente. Generalmente esto también es aplicable para la primera vez que se despierta un cliente de modo interno. En una modalidad, cuando el enlace despierta de la hibernación el huésped y el cliente intercambian una secuencia de impulsos. Estos impulsos pueden detectarse utilizando receptores de linea de baja velocidad que consumen solamente una fracción de la actual como los receptores diferenciales requeridos para recibir las señales a la máxima velocidad operativa de enlace. El huésped o el cliente pueden despertar el enlace, de manera que el protocolo se encuentra diseñado para manejar posibles contenciones que pueden ocurrir si tanto el huésped como el cliente intentan despertar simultáneamente. Durante el estado de hibernación, se deshabilitan los manej adores diferenciales de MDDI_Datos y MDDI_Stb y el voltaje diferencial en todos los pares diferenciales es de cero voltios. Los receptores de linea diferencial utilizados para detectar la secuencia de impulsos durante el despertar de la hibernación tienen una variación de voltaje intencional. En una modalidad, el umbral entre un nivel de uno lógico y cero lógico en estos receptores es de aproximadamente 125 mV. Esto ocasiona un par diferencial no accionado por considerarse como un nivel de cero lógico durante la secuencia de despertar de enlace. Con objeto de ingresar a un Estado de Hibernación, el huésped envia 64 ciclos de MDDI Stb después de la CRC del Paquete de Desconexión de Enlace.

El huésped deshabilita la salida de MDDI_DatosO del huésped en el rango de 16 a *56 ciclos de MDDI_Stb (incluyendo los retrasos de propagación de deshabilitación entregados como salida) después de la CRC. El huésped termina enviando los 64 ciclos de MDDI_Stb después de la CRC del paquete de Desconexión de Enlace antes de que inicie la secuencia de despertar. En una modalidad, el despertar iniciado por el huésped se define como el huésped que tiene que esperar al menos 100 nseg después de que MDDI_DatosO alcanza un nivel de uno lógico válido antes de accionar los impulsos en MDDI_Stb. En una modalidad, el cliente espera al menos 60 ciclos de MDDI_Stb después de la CRC del Paquete de Desconexión de Enlace antes de que lleve a MDDI_DatosO a un nivel de uno lógico a intentar despertar al huésped. Con objeto de "despertar" de un Estado de Hibernación, se llevan a cabo varias acciones o procesos. Cuando el cliente, aquí una pantalla, necesita datos o comunicación, servicio, proveniente (s) de huésped lleva la linea de MDDI_DatosO a un estado de uno lógico durante aproximadamente 70 a 1000 µseg, mientras que MDDI_Stb está inactiva y mantiene a MDDI_DatosO en un nivel de uno lógico durante aproximadamente 70 ciclos de MDDI_Stb (durante un rango de 60 a 80) después de que MDDI_Stb se vuelve activa, aunque pueden utilizarse otros periodos según se desee. Después, el cliente deshabilita el manej ador de MDDI_DatosO colocándolo en un estado de alta impedancia. Si MDDI_Stb está activa durante la hibernación, aunque es improbable, entonces el cliente solamente podría llevar a MDDIJDatosO a un estado de uno lógico durante aproximadamente 70 ciclos de MDDI_Stb (durante un rango de 60 a 80) . Esta acción ocasiona que el huésped inicie o reinicie el tráfico de datos por el enlace en avance (208) y consulte el estado del cliente. El huésped de detectar la presencia del impulso de solicitud y comienza la secuencia de inicio llevando primeramente a MDDI_Stb a un nivel de cero lógico y a MDDIJDatosO a un nivel alto lógico durante al menos aproximadamente 200 nseg. Y después, aunque MDDI_Stb cambia, continúa llevando a MDDI_Datos0 a un nivel de uno lógico durante aproximadamente 150 ciclos de MDDI_Stb (un rango de 140 a 160) a cero lógico durante aproximadamente 50 ciclos de MDDI_Stb. El cliente no debe enviar un pulso de solicitud de servicio si detecta MDDI_Datos0 en el estado de uno lógico durante más de 80 ciclos de MDDI_Stb. Cuando el cliente ha detectado MDDI_DatosO en un nivel de uno lógico durante 60 a 80 cíelos de MDDI_Stb comienza a buscar el intervalo donde el huésped lleva a MDDI_DatosO a un nivel de cero lógico durante 50 ciclos de MDDI_Stb. Después de que el huésped lleva a MDDI_DatosO a un nivel de cero lógico durante 50 ciclos de MDDI_Stb, el huésped comienza entonces a enviar paquetes por el enlace. El primer paquete enviado es un Paquete de Cabecera de Sub-Trama. El cliente comienza a buscar el Paquete de Cabecera de Sub-Trama después de que MDDI__Datos0 se encuentra en un nivel de cero lógico durante 40 ciclos de MDDI_Stb del intervalo de 50 ciclos. La naturaleza de selección de los tiempos y tolerancias de los intervalos de tiempo relacionados con el procesamiento de hibernación y secuencia de inicio se describen detalladamente a continuación. (Ver las Figuras 68A-C mostradas a continuación) . El huésped puede iniciar el despertar habilitando primeramente MDDI__Stb y simultáneamente llevándola a un nivel de cero lógico. MDDI_Stb no debe llevarse a un nivel de uno lógico hasta que se hayan entregado como salida los impulsos como se describe a continuación. Después de que MDDI_Stb alcance un nivel de cero lógico, el huésped habilita MDDI_DatosO y simultáneamente la lleva a un nivel de uno lógico. MDDI__DatosO no debe llevarse a un nivel de cero lógico durante el proceso de despertar hasta el intervalo donde es llevada a un nivel de cero lógico durante un intervalo de 50 impulsos de MDDI_Stb. El huésped debe esperar al menos 200 nseg después de que MDDI_DatosO alcanza un nivel de uno lógico válido antes de accionar los impulsos en MDDI__Stb. Esta relación de sincronización ocurre mientras se consideran retrasos de habilitación de salida del peor escenario. Esto garantiza sustancialmente que un cliente tiene tiempo suficiente para habilitar totalmente su receptor de MDDI_Stb después de haberse despertado por un nivel de uno lógico en MDDI DatosO que fue accionado por el huésped. Un ejemplo de los pasos de procesamiento para un evento típico de solicitud de servicio de cliente 3800 sin contención se ilustra en la Figura 38, donde los eventos se etiquetan por conveniencia en ilustración utilizando las letras A, B, C, D, E, F, y G. El proceso comienza en el punto A cuando el huésped envía un Paquete de Desconexión de Enlace al dispositivo cliente a fin de informarle que el enlace realizará la transición a un estado de hibernación con bajo consumo de energía. En un siguiente paso, el huésped ingresa al estado de hibernación de bajo consumo de energía deshabilitando el mane ador de MDDI__DatosO y estableciendo el manejador de MDDI_Stb en un cero lógico, como se muestra en el punto B. MDDI_DatosO es llevada a un nivel de cero lógico por una red de polarización de alta impedancia. Después de algún periodo de tiempo, el cliente le envia un impulso de solicitud de servicio al huésped llevando MDDI_DatosO a un nivel de uno lógico como se observa en el punto C. El huésped mantiene el nivel de cero lógico utilizando la red de polarización de alta impedancia, pero el manej ador en el cliente forza la línea a un nivel de uno lógico. A los 50 µseg, el huésped reconoce el impulso de solicitud de servicio, y mantiene un nivel de uno lógico en MDDI_DatosO al habilitar su mane ador, como se observa en el punto D. Después, el cliente deja de intentar mantener el impulso de solicitud de servicio, y el cliente coloca su manejador en un estado de alta impedancia, como se observa en el punto E. El huésped lleva MDDI_DatosO a un nivel de cero lógico durante 50 µseg, como se muestra en el punto F, y comienza también a generar MDDI_Stb de manera consistente con el nivel de cero lógico en MDDI_Datos0. El cliente comienza a buscar el Paquete de Cabecera de Sub-Trama después de que MDDI_DatosO se encuentra en un nivel de cero lógico durante 40 ciclos de MDDI_Stb. Después de mantener MDDI_DatosO en un nivel de cero lógico y de llevar a MDDI_Stb durante 50 µseg, el huésped comienza a transmitir datos por el enlace en avance enviando un Paquete de Cabecera de Sub-Trama, como se muestra en el punto G . Un ejemplo similar se ilustra en la Figura 39 donde una solicitud de servicio se mantiene después de que ha comenzado la secuencia de reinicio de enlace, y los eventos se etiquetan nuevamente utilizando las letras A, B, C, D, E, F, y G. Esto representa el peor escenario donde un impulso o señal solicitada proveniente del cliente se acerca lo más que puede a corromper el Paquete de Cabecera de Sub-Trama. El proceso comienza en el punto A cuando el huésped envia nuevamente un Paquete de Desconexión de Enlace al dispositivo cliente para informarle que el enlace realizará la transición a un estado de hibernación con bajo consumo de energía. En un siguiente paso, el huésped ingresa al estado de hibernación con bajo consumo de energía deshabílitando el manejador de MDDI_DatosO y estableciendo el manejador de MDDI_Stb en un nivel de cero lógico, como se muestra en el punto B. Como se mencionó con anterioridad, MDDI_DatosO es llevada a un nivel de cero lógico por una red de polarización de alta impedancia. Después de un periodo de tiempo, el huésped comienza la secuencia de reinicio de enlace llevando a MDDI_DatosO a un nivel de uno lógico durante 150 µseg como se observa en el punto C. Antes de que pasen 50 µseg, comienza la secuencia de reinicio de enlace, la pantalla mantiene también MDDI_DatosO durante 70 µseg, como se observa en el punto D. Esto sucede debido a que la pantalla tiene la necesidad de solicitar el servicio proveniente del huésped y no reconoce que el huésped ya ha comenzado la secuencia de reinicio de enlace. Después, el cliente deja de intentar mantener el impulso de solicitud de servicio, y el cliente lleva a su manejador a un estado de alta impedancia, como se observa en el punto E. El huésped continúa llevando a MDDI_DatosO a un nivel de uno lógico. El huésped lleva a MDDI_DatosO a un nivel de cero lógico durante 50 µseg, como se muestra en el punto F, y comienza también a generar MDDI_Stb de manera consistente con el nivel de cero lógico en MDDI_DatosO. Después de mantener MDDI_DatosO en un nivel de cero lógico, y accionando MDDI_Stb durante 50 µseg, el huésped comienza transmitir los datos por el enlace en avance enviando un Paquete de Cabecera del Sub-Trama, como se muestra en el punto G. A partir de la descripción anterior, uno observa que la solución anterior implica que el huésped tenga que pasar por dos estados como parte de una secuencia de despertar. Para el primer estado, el huésped lleva la señal de MDDI_DatosO a • alto durante 150 µs, y después lleva la señal de MDDI_DatosO a bajo durante 50 us mientras activa la linea de MDDI_Stb, y después comienza a transmitir los paquetes de MDDI . Este proceso funciona bien para avanzar el estado de la materia en términos de tasas de Datos alcanzables utilizando los aparatos y métodos de MDDI. Sin embargo, como se comentó con anterioridad, más velocidad en términos de tiempo de respuesta reducido hace posible seleccionar más rápidamente el siguiente paso o proceso, con la capacidad de simplificar el procesamiento o los elementos, siempre en demanda. Los solicitantes han descubierto un nuevo planteamiento inventivo para el procesamiento de despertar y sincronización en el cual el huésped utiliza una sincronización basada en sitios de reloj para el cambio de señal. En esta configuración, el huésped comienza cambiando MDDI_Stb de 0 a 10 µseg después de que el huésped lleva a alto la señal de MDDI_DatosO al inicio de la secuencia de despertar, y no despierta hasta que la señal es llevada a bajo. Durante una secuencia de despertar, el huésped cambia MDDI_Stb como si la señal de MDDI_DatosO estuviese siempre en un nivel de cero lógico. Esto elimina eficientemente el concepto de tiempo en la parte del cliente, y el huésped cambia de los periodos anteriores de 150 µs y 50 µs para los primeros dos estados, a 150 ciclos de reloj y 50 ciclos de reloj, para estos periodos . El huésped se hace ahora responsable de llevar a alto a la linea de datos, y en 10 ciclos de reloj de comenzar a transmitir una señal estroboscópica como si la línea de datos fuese cero. Después de que el huésped ha llevado a alto a la linea de datos durante 150 ciclos de reloj, el huésped lleva a bajo a la linea de datos durante 50 ciclos de reloj mientras continúa transmitiendo la señal estroboscópica. Después de que ha completado ambos procesos, el huésped puede comenzar a transmitir el primer paquete de cabecera de sub-trama. En la parte del cliente, la implementación de cliente puede utilizar ahora el reloj generado para calcular el número de ciclos de reloj que la línea de datos tiene primero en alto, y después en bajo. El número de ciclos de reloj que necesita ocurrir en la línea de datos en estado alto es de 150 y en la línea de datos accionada en estado bajo es de 50. Esto significa que para una secuencia de despertar apropiada, el cliente debe ser capaz de contar al menos 150 ciclos de reloj continuos de la linea de datos que está en alto, seguidos por al menos 50 ciclos de reloj continuos de la linea de datos que está en bajo. Una vez que se cumplen estas dos condiciones, el cliente puede comenzar a buscar la palabra única de la primera sub-trama. Una ruptura en este patrón se utiliza como base para regresar los contadores a un estado inicial en el cual el cliente busca nuevamente los primeros 150 ciclos de reloj continuos de la linea de datos que está en alto. Una implementación de cliente de la invención para el despertar basado en huésped de la hibernación es muy similar al caso inicial de encendido excepto que la tasa de reloj no es forzada a comenzar en 1 Mbps, como se describió con anterioridad. En cambio, la tasa de reloj puede establecerse para continuar a cualquiera fuese la tasa anterior activa cuando el enlace de comunicaciones se fue a hibernación. Si el huésped comienza la transmisión de una señal estroboscópica como se describió con anterioridad, el cliente debe ser capaz de contar nuevamente al menos 150 ciclos de reloj continuos de la linea de datos que está en alto, seguidos por al menos 50 ciclos de reloj continuos en la linea de datos que está en bajo. Una vez que se han cumplido estas dos condiciones, el cliente puede comenzar la búsqueda de la palabra única. Una implementación de clientes de la invención para el despertar basado en cliente de la hibernación es similar al despertar basado en huésped excepto que el cliente comienza manejando la linea de datos. El cliente puede manejar asincrónicamente la línea de datos sin un reloj a fin de despertar al dispositivo huésped. Una vez que el huésped reconoce que la linea de datos se ha llevado a alto por el cliente, puede iniciar su secuencia de despertar. El cliente puede contar el número de sitios de relojes generados por el huésped de comenzando o durante su proceso de despertar. Una vez que el cliente cuenta 70 sitios de reloj continuos de la línea de datos que está en alto, puede dejar de manejar la línea de datos en alto. En este punto, el huésped ya debe estar manejando la línea de datos en alto también. Después, el cliente puede contar otros 80 sitios de reloj continuos de la linea de datos que está en alto para alcanzar los 150 ciclos de reloj de la linea de datos que está en alto, y después puede buscar 50 ciclos de reloj de la línea de datos que está en bajo. Una vez que se han cumplido estas tres condiciones, el cliente puede comenzar a buscar la palabra única. Una ventaja de esta nueva implementación de procesamiento de despertar es que elimina la necesidad de un dispositivo de medición de tiempo. Si este es un oscilador, o un circuito de descarga de capacitor, u otros dispositivos conocidos, el cliente ya no necesita de tales dispositivos externos para determinar las condiciones de encendido. Esto ahorra dinero y área de circuito cuando se implementan los controladores, contadores, y demás en una tarjeta de dispositivo cliente. Aunque esto puede ser no ventajoso para el cliente, para el huésped, esta técnica también debe simplificar potencialmente al huésped en términos de la lógica de muy alta densidad (VHDL - very high density logic) utilizada por la circuiteria principal. El consumo de energía para utilizar las lineas de datos y estroboscópica como la notificación de despertar y fuente de medición también serán más bajas dado que no se necesita utilizar ninguna circuiteria externa para los elementos principales que esperan un despertar basado en el huésped. El número de ciclos o periodos de reloj utilizados son a manera de ejemplo y pueden utilizarse otros períodos como será aparente para el experto en la materia. Una ventaja de esta nueva implementación de procesamiento de despertar es que elimina la necesidad de un dispositivo de medición de tiempo. Si este es un oscilador, o un circuito de descarga de capacitor, u otros dispositivos conocidos, el cliente ya no necesita de tales dispositivos externos para determinar las condiciones de encendido. Esto ahorra dinero y área de circuito cuando se implementan los controladores, contadores, y demás en una tarjeta de dispositivo cliente. Aunque esto puede ser no ventajoso para el cliente, para el huésped, esta técnica también debe simplificar potencialmente al huésped en términos de la lógica de muy alta densidad (VHDL - very high density logic) utilizada por la circuiteria principal. El consumo de energía para utilizar las líneas de datos y estroboscópica como la notificación de despertar y fuente de medición también serán más bajas dado que no se necesita utilizar ninguna circuitería externa para los elementos principales que esperan un despertar basado en el huésped. Para clarificar e ilustrar la operación de esta nueva técnica, en las Figuras 68A, 68B, y 68C se muestran la sincronización de MDDI_Datos0, MDDI_Stb, y de diversas operaciones relacionadas con los ciclos de reloj . Un ejemplo de los pasos de procesamiento para un Despertar iniciado por el Huésped sin contención se ilustra en la Figura 68A, donde los eventos se etiquetan nuevamente para conveniencia en ilustración utilizando las letras A, B, C, D, E, F, y G. El proceso comienza en el punto A donde el huésped envía un Paquete de Desconexión de Enlace al dispositivo cliente para informarle que el enlace realizará la transición a un estado de hibernación con bajo consumo de energía. En un siguiente paso, el punto B, el huésped cambia MDDI_Stb durante aproximadamente 64 ciclos (o según se desee para el diseño del sistema) a fin de permitir que el cliente complete el procesamiento antes de dejar de cambiar el valor de MDDl_Stb, lo cual detiene el reloj recuperado en el dispositivo cliente. El huésped también establece inicialmente MDDI_Datos0 en un nivel de cero lógico y deshabilita después la salida de MDDI__DatosO en el rango de 16 a 48 ciclos (incluyendo generalmente retrasos de propagación de deshabilitación entregados como salida) después de la CRC. Puede ser deseable colocar receptores de alta velocidad para MDDI__DatosO y MDDI_Stb en el cliente en un estado de bajo consumo de energía en algún momento después de los 48 ciclos después de la CRC y antes de la siguiente etapa (C) . El cliente coloca sus receptores de alta velocidad para MDDI_DatosO y MDDI_Stb en hibernación en cualquier momento después del borde de subida del 48° ciclo de MDDI_Stb después de la CRC del Paquete de Desconexión de Enlace. Se recomienda que el cliente coloque los receptores de alta velocidad para MDDI_DatosO y MDDI_Stb en hibernación antes del borde subida del 64° ciclo de MDDI_Stb después de la CRC del Paquete de Desconexión de Enlace. El huésped ingresa al estado de hibernación con bajo consumo de energía en el punto o paso C, deshabilitando los manej adores de MDDI_DatosO y MDDI__Stb y colocando un controlador de huésped en un estado de hibernación con bajo consumo de energía. Uno puede establecer también al manejador de MDDI_Stb en un nivel de cero lógico (utilizando una red de polarización de alta impedancia) o continuar cambiando durante la hibernación, según se desee. El cliente se encuentra también en un estado de hibernación con bajo consumo de energía. Después de algún periodo de tiempo, el huésped comienza la secuencia de reinicio de enlace en el punto D, habilitando la salida del manejador de MDDI_DatosO y MDDI_Stb. El huésped lleva a MDDI_Datos0 a un nivel de uno lógico y a MDDI_Stb a un nivel de cero lógico tanto como deba llevarlas para que los manej adores habiliten totalmente sus respectivas salidas. El huésped espera típicamente aproximadamente 200 nanosegundos después de que estas salidas alcanzan los niveles lógicos deseados antes de accionar los impulsos en MDDI_Stb. Esto le brinda al cliente tiempo para prepararse para la recepción. Con los mane adores de huésped habilitados y MDDI_DatosO llevada a un nivel de uno lógico, el huésped comienza a cambiar MDDI_Stb una duración de 150 ciclos de MDDI_Stb, como se observa en el punto E. El huésped lleva a MDDI_DatosO a un nivel de cero lógico durante 50 ciclos, como se observa en el punto F, y el cliente comienza a buscar el Paquete de Cabecera de Sub-Trama después de que MDDI_DatosO está en un nivel de cero lógico durante 40 ciclos de MDDI_Stb. El huésped comienza a transmitir datos por el enlace en avance enviando un Paquete de Cabecera de Sub-Trama, como se observa en el punto G. Un ejemplo de los pasos de procesamiento para un Despertar iniciado por el Cliente sin contención se ilustra en la Figura 68B, donde los eventos se etiquetan nuevamente por conveniencia en ilustración utilizando las letras A, B, C, D, E, F, G, H, e l. Como antes, el proceso comienza en el punto A cuando el huésped envía un Paquete de Desconexión de Enlace para informarle al cliente que el enlace realizará la transición al estado de bajo consumo de energía. En el punto B, el huésped cambia MDDI_Stb durante aproximadamente 64 ciclos (o según se desee para un diseño de sistema) para permitirle al cliente completar el procesamiento antes de dejar de cambiar los valores de MDDI_Stb, lo cual detiene al reloj recuperado en el dispositivo cliente. El huésped también establece inicialmente MDDI_DatosO en un nivel de cero lógico y deshabilita después la salida de MDDI_DatosO en el rango de 16 a 48 ciclos (incluyendo generalmente retrasos de propagación de deshabilitación entregados como salida) después de la CRC. Puede ser deseable colocar los receptores de alta velocidad para MDDI_DatosO y MDDI__Stb en el cliente en un estado de bajo consumo de energía un momento posterior a los 48 ciclos después de la CRC y antes de la siguiente etapa (C) . El huésped ingresa al estado de hibernación con bajo consumo de energía en el punto o paso C, deshabilitando los manej adores MDDI_DatosO y MDDI_Stb y colocando un controlador de huésped en un estado de hibernación con bajo consumo de energía. Uno puede establecer también al manejador de MDDI_Stb en un nivel de cero lógico (utilizando una red de polarización de alta impedancia) o continuar cambiando durante la hibernación, según se desee. El cliente se encuentra también en un estado de hibernación con bajo consumo de energía. Después de algún periodo de tiempo, el huésped comienza la secuencia de reinicio de enlace en el punto D, habilitando al receptor de MDDI_Stb, y permitiendo también una variación en el receptor de MDDI_Stb para garantizar que el estado de la versión recibida de MDDI_Stb es un nivel de cero lógico en el cliente antes de que el huésped habilite su manejador de MDDI_Stb. Puede ser deseable que el cliente habilite ligeramente la variación antes de habilitar al receptor para asegurar la recepción de una señal diferencial válida e inhibir las señales erróneas, según se desee. El Cliente habilita al manejador de MDDI_DatosO mientras lleva la línea de MDDI_DatosO a un nivel de uno lógico. Se le permite a MDDI_DatosO y MDDI_Stb habilitarse simultáneamente si el tiempo para habilitar la variación y habilitar al receptor diferencial convencional de MDDI_Stb es menor que 200 nseg. Aproximadamente en 1 mseg., en el punto E, el huésped reconoce el impulso de solicitud de servicio proveniente del cliente, y el huésped comienza la secuencia de reinicio de enlace habilitando las salidas de manejador de MDDI_DatosO y MDDI_Stb. El huésped lleva a MDDI_DatosO a un nivel de uno lógico y a MDDI_Stb a un nivel de cero lógico tanto como deba llevarlas para que los manej adores habiliten totalmente sus respectivas salidas. El huésped espera típicamente aproximadamente 200 nanosegundos después de que estas salidas alcanzan los niveles lógicos deseados antes de accionar los impulsos en MDDI_Stb. Esto le brinda al cliente tiempo para prepararse para la recepción. Con los manej adores de huésped habilitados y MDDI_DatosO llevada a un nivel de uno lógico, el huésped comienza a cambiar MDDI_Stb una duración de 150 ciclos de MDDI_Stb, como se observa en el punto F. Cuando el cliente reconoce el primer impulso en MDDI_Stb deshabilita la variación en su receptor de MDDI_Stb. El cliente continúa llevando MDDI_DatosO a un nivel de uno lógico durante 70 ciclos de MDDI_Stb, y deshabilita su manejador de MDDI_DatosO en el punto G. El huésped continúa accionando a MDDI__DatosO en un nivel de uno lógico una duración de 80 impulsos adicionales de MDDI_Stb, y en el punto H lleva a MDDI_DatosO a un nivel de cero lógico. Como se observa en los puntos G y H, el huésped lleva a MDDI_DatosO a un nivel de cero lógico durante 50 ciclos, y el cliente comienza a buscar el Paquete de Cabecera de Sub-Trama después de que MDDI_DatosO está en un nivel de cero lógico durante 40 ciclos de MDDI_Stb. Después de accionar MDDI_Stb durante 50 ciclos, el huésped comienza a transmitir datos por el enlace en avance enviando un Paquete de Cabecera de Sub-Trama, como se muestra en el punto I. Un ejemplo de los pasos de procesamiento para un Despertar típico iniciado por el Huésped sin contención proveniente del cliente, que es el cliente que también desea despertar al enlace, se ilustra en la Figura 68C. Los eventos se etiquetan nuevamente para conveniencia en ilustración, utilizando las letras A, B, C, D, E, F, G, H, e l. Como antes, el proceso comienza en el punto A cuando el huésped envía un Paquete de Desconexión de Enlace para informarle al cliente que el enlace realizará la transición al estado de bajo consumo de energía, procede al paso B donde MDDI_Stb cambia durante aproximadamente 64 ciclos (o según se desee para el diseño del sistema) para permitirle al cliente completar el procesamiento, y después al punto C, donde el huésped ingresa al estado de hibernación con bajo consumo de energía, deshabilitando los manej adores de MDDI_Datos0 y MDDI_Stb y colocando un controlador de huésped en un estado de hibernación con bajo consumo de energía. Después de un cierto periodo de tiempo, el huésped comienza la secuencia de reinicio de enlace en el punto D, habilitando las salidas del manejador de MDDI_DatosO y MDDI_Stb, y comienza a cambiar MDDI_Stb durante 150 ciclos de MDDI_Stb, como se observa en el punto E. Hasta 70 ciclos de MDDI_Stb después del punto E, aquí punto F, el cliente aún no ha reconocido que el huésped está llevando MDDI_DatosO a un nivel de uno lógico de manera que el cliente lleva también a MDDI_DatosO a un nivel de uno lógico. Esto ocurre aquí debido a que el cliente tiene el deseo de solicitar el servicio pero no reconoce que el huésped con el que está intentando comunicarse ya ha comenzado la secuencia de reinicio de enlace. En el punto G, el cliente deja de manejar a MDDI_DatosO, y coloca su manejador en un estado de alta impedancia deshabilitando su salida. El huésped continúa llevando MDDI_DatosO a un nivel de uno lógico durante 80 ciclos adicionales . El huésped lleva a MDDI_DatosO a un nivel de cero lógico durante 50 ciclos, como se observa en el punto H, y el cliente comienza a buscar el Paquete de Cabecera de Sub-Trama después de que MDDI_DatosO se encuentra en un nivel de cero lógico durante 40 ciclos de MDDI_Stb. El huésped comienza a transmitir los datos por el enlace en avance enviando un Paquete de Cabecera de Sub-Trama, como se muestra en el punto I.

VI. Especificaciones Eléctricas de Inferíase En las modalidades a manera de ejemplo, los Datos en un formato de No Retorno a Cero (NRZ - Non-Return-to-Zero) se codifican utilizando una señal estroboscópica-de datos o un formato de DATOS-STB, el cual permite incorporar la información de reloj en las señales de datos y estroboscópicas . El reloj puede recuperarse sin circuitería compleja de circuito de bloqueo de fase. Los datos se transportan por un enlace diferencial bi-direccional, generalmente implementado utilizando un cable, aunque pueden utilizarse otros conductores, cables impresos, o elementos de transferencia, como se expuso con anterioridad. La señal estroboscópica (STB) se transmite por un enlace uni-direccional el cual solamente es manejado por el huésped. La señal estroboscópica cambia de valor (0 o 1) en cualquier momento que existe un estado recíproco, 0 a 1, que permanece igual en la linea o señal de Datos. Un ejemplo de cómo puede transmitirse una secuencia de datos tal como los bits "1110001011" utilizando la codificación de DATOS-STB se muestra en forma gráfica en la Figura 40. En la Figura 40, se muestra una señal de DATOS 4002 en la linea superior de un diagrama de sincronización de señales y una señal STB 4004 se muestra en una segunda linea, alineado cada tiempo según sea apropiado (punto de inicio común) . Como el tiempo pasa, cuando ocurre un cambio de estado en la línea de DATOS 4002 (señal) , entonces la línea de STB 4004 (señal) mantiene un estado anterior, consecuentemente, el primer estado en l' de la señal de DATOS se correlaciona con el primer estado ?0' para la señal STB, su valor inicial. Sin embargo, si en el estado, el nivel de la señal de DATOS no cambia entonces la señal STB cambia al estado opuesto o ?l' en el presente ejemplo, como es el caso en la Figura 40 donde los DATOS proporcionar otro valor de l' . Es decir, existe una y solamente una transición por ciclo de bit entre DATOS y STB. Por lo tanto, la señal STB realiza nuevamente la transición, esta vez a 0' como la señal de DATOS permanece en ?l' y mantiene este nivel o valor a medida que la señal de DATOS cambia el nivel a ?0' . Cuando la señal de DATOS permanece en ?l', la señal STB cambia al estado opuesto o ?l' en el presente ejemplo, etcétera, la señal de DATOS cambia o mantiene los niveles o valores. Después de recibir estas señales, se lleva a cabo una operación OR exclusiva (XOR) en las señales de DATOS y STB para producir una señal 4006 de reloj, la cual se muestra en la parte inferior del diagrama de sincronización para la comparación relativa con las señales deseadas de datos y estroboscópica. Un ejemplo de la circuiteria útil para generar las salida de DATOS y STB o las señales provenientes de los datos de entrada en el huésped, y después recuperar o recapturar los datos provenientes de la señales de DATOS y STB en el cliente, se muestra en la Figura 41. En la Figura 41, se utiliza una porción 4100 de transmisión para generar y transmitir las señales originales de DATOS y STB por una trayectoria 4102 de señal intermediaria, mientras que se utiliza una porción 4120 de recepción para recibir las señales y recuperar los datos. Como se muestra en la Figura 41, con objeto de transferir datos de un huésped a un cliente, la señal de DATOS se toma como entrada a dos elementos 4104 y 4106 de circuito de multivibrador de tipo D junto con una señal de reloj para activar los circuitos. Las dos salidas del circuito de dos multivibradores (Q) se dividen después en un par diferencial de señales MDDI_Datos0+, MDDI_Datos0-, y MDDI_Stb+, MDDI_Stb-, respectivamente, utilizando dos manejadores 4108 y 4110 de linea diferenciales (modo de voltaje) . Una compuerta ÑOR exclusiva (XNOR) de tres entradas, circuito, o elemento lógico 4112 se conecta para recibir los DATOS y salidas de ambos multivibradores, y genera una salida que proporciona la entrada de dato para el segundo multivibrador, el cual a su vez genera las señales MDDI_Stb+, MDDI__Stb- . Por conveniencia, la compuerta XNOR tiene la burbuja de inversión colocada para indicar que efectivamente está invirtiendo la salida Q del multivibrador que genera la señal Estroboscópica. En la porción 4120 de recepción de la Figura 41, las señales de MDDI Datos0+, MDDI DatosO- y las señales MDDI_Stb+, MDDI_Stb- son recibidas por cada uno de los dos receptores de línea diferencial 4122 y 4124, que generan las salidas de señal de las señales diferenciales. Las salidas de los amplificadores se toman después como entrada para cada una de las entradas de una compuerta OR exclusiva (XOR) de dos entradas, circuito, o elemento lógico 4126 que produce la señal de reloj . La señal de reloj se utiliza para activar cada uno de los dos circuitos 4128 y 4130 de multivibrador de tipo D que reciben una versión retrasada de la señal de DATOS, mediante el elemento 4132 de retraso, uno de los cuales (4128) genera valores de datos 0' y el otro (4130) valores de datos l' . El reloj tiene también una salida independiente de la lógica XOR. Dado que la información de reloj se distribuye entre las lineas de DATOS y STB, ninguna señal realiza la transición entre los estados más rápido que la mitad de la tasa de reloj . Dado que el reloj se reproduce utilizando el procesamiento de OR-exclusivo de las señales de DATOS y STB, el sistema tolera eficientemente el doble de la cantidad de distorsión entre los datos de entrada y el reloj en comparación con la situación donde una señal de reloj se envía directamente por una sola línea de datos dedicada.

Los pares de Datos de MDDI, MDDI_Stb+, y MDDI_Stb- se operan en un modo diferencial para maximizar la inmunidad de los efectos negativos de ruido. Cada par diferencial es de terminación paralela con la impedancia característica dei cable o conductor que se utiliza para transferir señales. Generalmente, todas las terminaciones paralelas residen en el dispositivo cliente. Esto se encuentra cerca del receptor diferencial para el tráfico en avance (datos enviados del huésped al cliente) , pero se encuentra en el extremo de conducción del cable u otros conductores o elementos de transf rencia para el tráfico inverso (datos enviados del cliente al huésped) . Para el tráfico inverso, la señal es manejada por el cliente, se refleja por el receptor de alta impedancia en el huésped, y termina en el cliente. Esto evita la necesidad de una doble terminación que incrementaría el consumo de corriente. Funciona también a tasas de datos mayores que el recíproco del retraso de viaje redondo en el cable. Los conductores o señales de MDDI_Stb+ y MDDI_Stb- solamente son manejados por el huésped. Una configuración a manera de ejemplo de elementos útiles para alcanzar los manej adores, receptores, y terminaciones para transferir señales como parte de la MDDI inventiva se muestran en la Figura 42. Esta interfase a manera de ejemplo utiliza la detección de bajo voltaje, aqui 200 mV, con oscilaciones menores a 1 voltio y un bajo drenaje de energía. El manejador de cada par de señales tiene una salida de corriente diferencial. Mientras recibe los paquetes de MDDI, los pares de MDDI_Datos y MDDI_Stb utilizan un receptor diferencial convencional con un umbral de voltaje de cero voltios. En el estado de hibernación, se deshabilitan las salidas del manejador y los resistores de terminación paralela llevan el voltaje en cada par de señales a cero voltios. Durante la hibernación, un receptor especial por el par de MDDI_DatosO tiene un umbral de entrada de variación de 125 m V positivos, lo cual ocasiona que el receptor de línea de hibernación interprete el par de señal no accionada como un nivel de cero lógico. Algunas veces el huésped o el cliente manejan simultáneamente el par diferencial a un nivel de uno lógico o a un nivel de cero lógico para garantizar un nivel lógico válido en el par cuando cambia la dirección de flujo de datos (del huésped al cliente o del cliente al huésped) . El rango de voltaje de salida y las especificaciones de salida aún se cumplen con salidas accionadas simultáneamente llevadas a mismo nivel lógico. En algunos sistemas puede ser necesario manejar una pequeña corriente en el par diferencial terminado para crear un pequeño voltaje de equilibrio en ciertos momentos durante la hibernación y cuando el enlace se está despertando del estado de hibernación. En esas situaciones, los circuitos habilitados de polarización de corriente de equilibrio manejan los niveles de corriente referidos como: el diodo de ESD interno IESD-Y-RX Y Ia entrada de receptor diferencial con IesD-y-Rx =l µA, típicamente; la salida de manejador diferencial ITX-HÍ-Z en el estado de alta impedancia, con ITX-HÍ-Z = 1 µA, típicamente; e IesD-exsrno la fuga por los diodos de protección de ESD externo, con IesD-exteme = 3 µA, típicamente. Cada una de estas corrientes de fuga se ilustra en la Figura 47. Los circuitos de acoplamiento a positivo y de acoplamiento a negativo deben alcanzar el mínimo voltaje diferencial bajo las condiciones de fuga del peor escenario descritas con anterioridad cuando ocurren todas simultáneamente. La fuga total es de = 4 µA para el modo interno sin diodos de protección de ESD externo y 10 µA para el modo externo con protección de ESD externo. Los parámetros y características eléctricos de los manej adores de linea diferencial y de los receptores de línea se describen para una modalidad a manera de ejemplo en las Tablas VlIa-VIId. Funcionalmente, el manejador transfiere el nivel lógico en la entrada directamente a una salida positiva, y el inverso de la entrada en una salida negativa. El retraso de la entrada a las salidas se acopla bien a la linea diferencial que se maneja diferencialmente. En la mayoría de las implementaciones, la oscilación de voltaje en las salidas es menor que la oscilación en la entrada para minimizar el consumo de energía y las emisiones electromagnéticas. En una modalidad, existe una oscilación de voltaje minima de aproximadamente 0.5 V. Sin embargo, pueden utilizarse otros valores, como sería conocido por el experto en la materia, y los inventores contemplan un valor más pequeño en algunas modalidades, dependiendo de las restricciones de diseño . Los receptores de línea diferenciales tienen la misma característica que un comparador de voltaje de alta velocidad. En la Figura 41, la entrada sin burbuja es la entrada positiva y la entrada con burbuja es la entrada negativa. La salida es un uno lógico si: (Ventrada+) - (Ventrada-) es mayor que cero. Otra manera de describir esto es un amplificador diferencial con una ganancia muy grande (prácticamente infinita) con la salida mantenida en niveles de voltaje de 0 y 1 lógico. La distorsión de retraso entre pares diferentes debe minimizarse a fin de operar el sistema de transmisión diferencial a la velocidad potencia más alta.

Tabla Vlla Especificaciones Eléctricas del Transmisor de Huésped Parámetro Descripción Mín Máx. Unidad VRango-salida Rango permisible de voltaje de 0.35 1.60 V salida de manejador de huésped con respecto a la tierra del huésped I?D+ Corriente alta de salida 2.5 4.5 mA diferencial de manejador (mientras se maneja 1a línea de transmisión terminada) I?D- Voltaje bajo de salida -4.5 -2.5 mA diferencial de manejador (mientras se maneja 1a línea de transmisión terminada) Isubi a- Tiempo de subida y ba; ada (entre 425 Nota 1 pseg % y 80% de amplitud) de la Bajada salida del manejador, medido en modo diferencial Tpar- Distorsión entre las salidas 125 pseg positiva y negativa del mismo distorsi?n par diferencial distorsión intra-par) Tpistorsión- Distorsión de retraso pico entre Ver pseg un par diferencial y cualquier arriba Diferencial otro par diferencial tA Inestabilidad, límite de bit en 0 T&-283 pseg cruce central TE-TPO-DRVR Inestabilidad, límite de bit en 0 Ver pseg nivel de salida mínimo arriba Nota 1: El tiempo máximo de subida y bajada es 30% del intervalo para transmitir un bit en un par diferencial o 100 nseg, cualquiera que sea más pequeño.

Tabla Vllb Especificaciones Eléctricas del Transmisor de Cliente J-par- Distorsión entre las salidas 125 pseg positiva y negativa del mismo distorsion par diferencial (distorsión intra-par) J-Distcasion- Distorsión de retraso pico Ver pseg entre un par diferencial y arriba Diferencial cualquier otro par diferencial tA Inestabilidad, límite de bit TE-283 pseg en cruce central Tß-TP4-DRVR Inestabilidad, límite de bit Ver pseg en nivel de salida mínimo arriba Nota 1: El tiempo máximo de subida y bajada es 30% del intervalo para transmitir un bit en un par diferencial o 100 nseg, cualquiera que sea más pequeño.

Tabla VIIc Especificaciones Eléctricas del Receptor de Cliente Tabla Vlld Especificaciones Eléctricas del Receptor de Huésped En la Figura 42, se muestran un controlador de huésped 4202 y un controlador 4204 de cliente o de pantalla transfiriendo paquetes por el enlace 4206 de comunicaciones . EL controlador de huésped emplea una serie de tres manejadores 4210, 4212, y 4214 para recibir las señales de DATOS y STB de huésped por transferirse, así como también para recibir las señales de Datos de cliente por transferirse, mientras que el cliente emplea los tres manejadores 4230, 4232, y 4234. El manejador responsable del paso de los DATOS (4212) de huésped emplea una entrada de señal de habilitación para permitir la activación del enlace de comunicaciones generalmente solo cuando se desea la transferencia del huésped al cliente. Dado que la señal de STB forma parte de la transferencia de datos, no se emplea ninguna señal de habilitación adicional para ese manejador (4212) . Las entradas de cada uno de los receptores de DATOS de cliente y STB (4132, 4230) tienen resistores o i pedancías de terminación 4218 y 4220, respectivamente colocados entre ellas. El manejador 4234 en el controlador de cliente se utiliza para preparar las señales de datos que se transfieren del cliente al huésped, donde el manejador 4214 de la entrada procesa los datos. Los receptores especiales (manejadores) 4216 y 4236 se acoplan o conectan con las líneas de DATOS, y generan o utilizan la variación de voltaje de 125 mV descrita con anterioridad, como parte del control de hibernación descrito en otra parte. Las variaciones ocasionan que los receptores de línea de hibernación interpreten pares de señal no accionadas como un nivel de cero lógico. Los manejadores e impedancias anteriormente descritos pueden formarse como componentes discretos o como parte de un módulo de circuito, o un circuito integrado de aplicación específica (ASIC - application specific integrated circuit) que actúa como una solución de codificador o decodificador más rentable. Puede observarse fácilmente que la energía se transfiere al dispositivo cliente, o pantalla, desde el dispositivo huésped utilizando las señales etiquetadas HOST_Pwr (HUÉSPED_Ene) y HOST_Gnd (HUÉSPED_Gnd) sobre un par de conductores. La porción de HOST_Gnd de la señal actúa como la tierra de referencia y la trayectoria de retorno del suministro de energía o señal para el dispositivo cliente. La señal de HOST_Pwr actúa como el suministro de energía del dispositivo cliente que es manejado por el dispositivo huésped. En una configuración a manera de ejemplo, para aplicaciones con bajo consumo de energía, el dispositivo cliente drena hasta 500 mA. La señal de HOST_Pwr puede proporcionarse desde fuentes portátiles de energía, tales como pero sin limitarse a, una batería de tipo o paquete de baterías de ion de litio que reside en el dispositivo huésped, y puede oscilar de 3.2 a 4.3 voltios con respecto a HOST_Gnd.

VII. Características de Sincronización A. Resumen En las Figuras 43a, 43b, y 43c, se ilustran respectivamente los pasos y niveles de señal empleados para ingresar a un estado de hibernación (no se solicita, desea, o requiere ningún servicio) , y para asegurar el servicio para un cliente desde el huésped, sea por iniciación del huésped o el cliente. En las Figuras 43a, 43b, y 43c, la primera parte de las señales que se ilustran muestra cómo se transfiere un Paquete de Desconexión de Enlace desde el huésped y después la linea de datos de llegada a un estado de cero lógico utilizando el circuito de polarización de alta impedancia. No se transmite ningún dato por el cliente, o el huésped, que tienen deshabilitado su manejador. Una serie de impulsos estroboscópicos para la línea de señal de MDDI_Stb puede observarse en la parte inferior, dado que MDDI_Stb está activa durante el Paquete de Desconexión de Enlace. Una vez que termina este paquete, el nivel lógico cambia a cero dado que el huésped lleva el circuito de polarización y lógica a cero. Esto representa la terminación de la última transferencia de señal o servicio proveniente del huésped, y podria haber ocurrido en cualquier momento en el pasado, y se incluye para mostrar el cese de servicio anterior, y el estado de las señales antes del inicio del servicio. Si se desea, tal señal puede enviarse sólo para reestablecer el enlace de comunicaciones al estado apropiado sin una comunicación anterior "conocida" que ha sido emprendida por este dispositivo huésped. Como se muestra la Figura 43a, y se describe para el Paquete de Desconexión de Enlace anterior, en el estado de hibernación con bajo consumo de energía, el manejador MDDI_Datos0 se deshabilita en un estado de alta impedancia que comienza después de los ciclos o impulsos de MDDI_Stb 16° a 48° después del último byte del campo Sólo Ceros en el Paquete de Desconexión de Enlace. Para los enlaces de Tipo 2, Tipo 3, o Tipo 4 las señales de MDDI_Datosl a MDDI_DatosEne7 (MDDI_DataPwr7) se colocan también en un estado de alta impedancia al mismo tiempo que se deshabilita el manejador MDDI_Datos0. Como se describe en la definición del campo Sólo Ceros, MDDI_Stb cambia durante 64 ciclos (o como se desee para el diseño de sistema) posteriores al MSB del campo de CRC del Paquete de Desconexión de Enlace para permitir que el cliente complete el procesamiento y facilite un apagado ordenado en un controlador de cliente. Un ciclo es una transición de bajo a alto seguida por una transición de alto a bajo, o una transición de alto a bajo seguida por una transición de bajo a alto. Después de que se envía el campo Sólo Ceros, se deshabilitan los manejadores MDDI_Stb y MDDI_DatosO en el huésped, y el huésped ingresa al estado de hibernación con bajo consumo de energía. Después de un período de tiempo, el huésped comienza la secuencia de reinicio de enlace no se muestra en las Figuras 43b y 43c, habilitando las líneas de MDDI_DatosO y MDDI_Stb o salidas de manejadores, y comienza a cambiar MDDI_Stb, como parte de una solicitud de despertar iniciada por el huésped o el cliente. Como se muestra en la Figura 43b, después de que pasa un cierto tiempo con la salida de señal deshabilitada de los manejadores de MDDI_DatosO y MDDI_Stb, un huésped inicia el servicio o despertar de hibernación habilitando su manejador de MDDI_Stb para un periodo de tiempo designado t3tb-dagta-enbi/ durante el cual la línea se lleva a un nivel de cero lógico, hasta que es habilitada completamente y después habilita su manejador de MDDI_DatosO. El huésped mantiene MDDI_Stb en un nivel de cero lógico después de que MDDI_DatosO alcanza un nivel alto o de uno lógico del cual ocurre durante un periodo de tiempo designado tiniCi0-ciiente • Al final del periodo de tinií?o-eUsnts el huésped cambia después la señal o linea de MDDI_Stb. El huésped lleva a alto la linea de MDDI_DatosO, un nivel de uno lógico, mientras que el cliente no maneja MDDI DatosO, durante un periodo designado tCS?nicic-aio/ y después lleva a bajo la línea de MDDI_DatosO, o a un nivel de cero lógico, durante un periodo designado • Después de esto, el primer tráfico en avance comienza con un Paquete de Cabecera de Sub-Trama, y después se transfieren los paquetes de tráfico en avance. La señal MDDI_Stb se encuentra activa durante el periodo de trexnicio-bajo y el subsecuente Paquete de Cabecera de Sub-Trama. Como se muestra en la Figura 43c, después de que pasa un cierto tiempo con la salida de señal deshabilitada de los manejadores MDDI_DatosO y MDDI_Stb, un cliente inicia una solicitud de servicio o despertar de hibernación al habilitar una variación en el receptor de MDDI_Stb o señal de salida para un periodo de tiempo designado t3tt-dagta-enbi, como se describe con anterioridad, antes de que huésped habilite su manejador de MDDI_Stb. Después, el cliente habilita su manejador de MDDI__DatosO durante un periodo de tiempo designado t e;tr-nué?sd durante el cual la línea se lleva a un nivel de cero lógico, antes de que el huésped comience el cambio de MDDI_j3tb. Una cierta cantidad de tiempo pasa o puede ser necesaria antes de que el huésped detecte la solicitud durante tras, lo cual el huésped responde al mantener a MDDI_Stb en un nivel de cero lógico durante el periodo designado t?tb-inicio antes de que el huésped comience a cambiar MDDI_Stb con una secuencia de inicio de enlace al llevar a MDDI_DatosO a un nivel alto o de uno o lógico durante el periodo treinicio-aito- Cuando el cliente reconoce el primer impulso en MDDI_Stb deshabilita la variación en el receptor de MDDI_Stb. El cliente continúa llevando a MDDI_DatosO a un nivel de uno lógico durante un periodo designado tdetectar-ciiente hasta que detecta que el huésped maneja la linea. En este punto, el cliente cancela la asignación de solicitud, y deshabilita su manejador de MDDI_DatosO de manera que la salida proveniente del cliente se va nuevamente a un- nivel de cero lógico, y el huésped se encuentra manejando MDDI_DatosO. Como antes, el huésped continúa llevando a MDDI_DatosO a un nivel de uno lógico para el periodo treinicio-aito, y después lleva la linea de MDDI_DatosO a bajo para el periodo treinício-bajo/ tras lo cual comienza el primer tráfico en avance con un Paquete de Cabecera de Sub-Trama. La señal de MDDI_Stb se encuentra activa durante el periodo tLeini;i:- i; y el subsecuente Paquete de Cabecera de Sub-Trama. La Tabla VIII muestra tiempos representativos o períodos de procesamiento para el largo de los diversos periodos descritos con anterioridad, y la relación con las tasas de datos mínima y máxima a manera de ejemplo, en las que: 1 u = Tasa Datos Enlace donde la Tasa_Datos_Enblace es la tasa de bits de un solo par de datos.

Tabla VIII Aquellos expertos en la materia comprenderán fácilmente que las funciones de los elementos individuales ilustrados en las Figuras 41 y 42, son conocidas, y la función de los elementos en la Figura 42 se confirma por el diagrama de sincronización en las Figuras 43a, 43b, y 43c. Los detalles acerca de las terminaciones en serie y de los resistores de hibernación que se muestran en la Figura 42 se omitieron de la Figura 41 debido a que la información es innecesaria para una descripción sobre cómo realizar la codificación de Datos-Estroboscópica y recuperar el reloj de ella.

B. Enlace en Avance de Sincronización de Datos-Estroboscópica Las características de conmutación para la transferencia de datos por el enlace en avance desde la salida de manejador de huésped se muestran en la tabla IX-1. La Tabla IX presenta una forma tabular de los tiempos deseados mínimo y máximo, contra los tiempos típicos para algunas transiciones de señal por ocurrir. Por ejemplo, la duración tipica para que ocurra una transición desde el inicio hasta el fin de un valor de datos (salida de un "0" o "1"), una transición de DatosO a DatosO, defina ttdd_ (salida-huésped) , es ttbit mientras que el tiempo mínimo es de aproximadamente ttbit_0.5 nseg, y el máximo es de aproximadamente ttbit+0.5 nseg. El espaciamiento relativo entre las transiciones en los DatosO, otras lineas de datos (DatosX) , y las líneas estroboscópicas (Stb) , se ilustra en la Figura 44 donde se muestran las transiciones de DatosO a Estroboscópica, Estroboscópica a Estroboscópica, Estroboscópica a DatosO, DatosO a no DatosO, no DatosO a no DatosO, no DatosO a Estroboscópica, y Estroboscópica a no DatosO, las cuales son referidas respectivamente como tds-isaiida- huésped) , ttss- (salida-huésped) / ttsd- (salida-huésped) / ttddx- (salida- huésped)/ ttdxdx- ( salida-huésped ) / ttdxs- (salida-huésped) / y ttsdx- (salida- huésped) • Tabla IX-1 Los requisitos típicos de sincronización de MDDI para la entrada del receptor de cliente para las mismas señales que transmiten datos por el enlace en avance se muestran en la Tabla IX-2. Dado que las mismas señales que se describen se encuentran retrasadas en el tiempo, no se necesita ninguna figura nueva para ilustrar las características de señal o significado de las leyendas respectivas, como comprenderán aquellos expertos en la materia Las Figuras 45 y 46 ilustran la presencia de un retraso en respuesta que puede ocurrir cuando el huésped deshabilita o habilita el manejador de huésped, respectivamente. En el caso de que un huésped envié algunos paquetes, tal como el Paquete de Encapsulación de Enlace Inverso o el Paquete de Medición de Retraso de Viaje Redondo, el huésped deshabilita el manejador de línea después de enviar los paquetes deseados, tal como los paquetes CRC de Parámetro, Alineación Estroboscópica, y Sólo Ceros' ilustrados en la Figura 45 que han sido transferidos. Sin embargo, como se muestra en la Figura 45, el estado de la línea no necesariamente conmuta de 0' a un valor más alto deseado instantáneamente, aunque es potencialmente alcanzable con algún control o elementos de control presentes, pero le toma un periodo de tiempo para responder definido como periodo de Retraso de Deshabilitación de Manejador del huésped. Aunque podria ocurrir prácticamente instantáneamente de manera tal que este periodo de tiempo sea de 0 nanosegundos (nseg.) de duración, podria extenderse más fácilmente sobre algunos periodos más largos con 10 nseg. Como largo de periodo máximo deseado, lo cual ocurre durante los periodos de paquete de Tiempo de Guardia 1 o Cambiar 1.

Viendo la Figura 46, uno ve el cambio de nivel de señal experimentado cuando el Manejador de huésped se habilita para transferir un paquete de manera tal como el Paquete de Encapsulación de Enlace Inverso o el Paquete de Medición de Retraso de Viaje Redondo. Aquí, después de los periodos de paquete de Tiempo de Guardia 2 o Cambiar 2, se habilita el manejador y comienza a manejar un nivel, aqui ?0', cuyo valor se aproxima o alcanza durante un periodo de . tiempo definido como periodo de Retraso de Habilitación de Manejador de Huésped, el cual ocurre durante el periodo de Rehabilitación de Manejador, antes de enviar el primer paquete . Un proceso similar ocurre para los manejadores y transferencias de señal para el dispositivo cliente, aquí una pantalla. Las instrucciones generales para la duración de estos periodos, y sus respectivas relaciones se muestran en la Tabla X, mostrada a continuación. 20 Tabla X C. Tiempos de Habilitación y Deshabilitación de Salida de Huésped y de Cliente Las características de oscilaciones y las relaciones de sincronización relativa para los tiempos de habilitación y deshabilitación de salida de Huésped y de Cliente u operaciones con relación a la estructura y periodo del Paquete de Encapsulación de Enlace Inverso, se muestran en la Figura 48. Las funciones u operaciones de salida de manejador se etiquetan como: thabiiitar-huésped para el tiempo de deshabilitación de salida de Huésped, thabiiitación-ciiente para el tiempo de habilitación de salida de Cliente, y tdeshabiutaci?n-ciiente para el tiempo de deshabilitación de salida de Cliente. A continuación se describen los tiempos típicos para algunas transiciones de señal. El periodo máximo para estas operaciones seria de cero nanosegundos, con valores típicos o máximos determinados a partir del diseño de sistema que emplee la interfase, posiblemente del orden de 8 nanosegundos o más. Las instrucciones generales para la duración de estos periodos, (tiempos de habilitación/deshabilitación de huésped y cliente) y sus respectivas relaciones se muestran en la Tabla XI, mostrada a continuación Tabla XI VII. Implementación de Control de Enlace (Operación de Controlador de Enlace) A. Procesador de Paquetes de Máquina de Estados Los paquetes que se transfieren por un enlace de MDDI se despachan muy rápidamente, típicamente a una tasa del orden de 300 Mbps o más, tal como 400 Mbps, aunque ciertamente se alojan tasas menores, según se desee. Este tipo de velocidad de bus o enlace de transferencia es demasiado grande para los microprocesadores de propósito general actualmente disponibles comercialmente (económicos) o lo similar para control. Por lo tanto, una implementación práctica para realizar este tipo de transferencia de señal es utilizar una máquina de estados programable a fin de analizar el flujo de paquetes de entrada para producir paquetes que se transfieren o redirigen al subsistema audio-visual apropiado para el cual están destinados. Tales dispositivos son bien conocidos y utilizan circuitos generalmente dedicados a un número limitado de operaciones, funciones, o estados para alcanzar una operación de alta velocidad o de muy alta velocidad deseada. Los controladores, procesadores, o elementos de procesamiento de propósito general, pueden utilizarse para actuar más apropiadamente o manipular alguna información tal como paquetes de control o estado, los cuales tienen demandas de velocidad menores. Cuando se reciben estos paquetes (paquetes de control, estado, u otros predefinidos), la máquina de estados los debe pasar por una memoria temporal de datos o elemento de procesamiento similar al procesador de propósito general de manera que puedan activarse los paquetes para proporcionar un resultado deseado (efecto) mientras se transfieren los paquetes de audio y visuales a su destino de acción apropiado. Si en el futuro se fabrican microprocesadores u otros controladores, procesadores, o elementos de procesamiento de propósito general para alcanzar capacidades de procesamiento de tasas de datos más altas, entonces los estados o máquinas de estados descritos con anterioridad también deben implementarse utilizando control de software de tales dispositivos, típicamente como programas almacenados en un elemento o medio de almacenamiento. La función del procesador de propósito general sacando ventaja de la potencia del procesador, o de los ciclos en exceso disponibles para, microprocesadores (CPUs) en aplicaciones para computadoras, o controladores, procesadores, procesadores de señales digitales (DSP - digital signal processors) , circuitos especializados, o ASICs encontrados en los dispositivos inalámbricos, de la misma manera que algunos modelos o procesadores de gráficas utilizan la potencia de procesamiento de las CPUs en computadoras para ejecutar algunas funciones y reducir la complejidad y costos de hardware. Sin embargo, está con partición o uso de ciclos puede impactar negativamente sobre la velocidad de procesamiento, sincronización, de manera que en muchas aplicaciones, se prefieren circuitos o elementos dedicados para este procesamiento general. Con objeto de visualizar los datos de imagen en una pantalla (micro-pantalla) , o recibir confiablemente todos los paquetes enviados por el dispositivo huésped, el cliente se sincroniza con la sincronización de canal de enlace en avance. Es decir, las señales que llegan al cliente y los circuitos de cliente necesitan estar substancialmente sincronizados en el tiempo para que ocurra un procesamiento de señal apropiado. En la ilustración de la Figura 49 se presenta un diagrama de alto nivel de estados alcanzados por la señal para una modalidad. En la Figura 49, los posibles "estados" de sincronización de enlace en avance para una máquina 4900 de estados se muestran como un ESTADO DE TRAMAS ASINCRÓNICO 4904, dos ESTADOS SINCRÓNICOS DE ADQUISICIÓN 4902 y 4906, y tres ESTADOS EN SINCRONÍA 4908, 4910, y 4912. Como se muestra en el paso o estado de inicio 4902, la pantalla o cliente, tal como un dispositivo de presentación, comienza en un estado "sin sincronía" pre-seleccionado, y busca una palabra única en el primer paquete de cabecera de sub-trama que se detecta. Debe observarse que este estado sin sincronía representa el ajuste de configuración mínima o ajuste de "funcionamiento parcial" en el cual se selecciona una interfase de Tipo 1. Cuando se encuentra la palabra única durante la búsqueda, el cliente guarda el campo de largo de sub-trama. No hay verificación de los bits de CRC para procesar esta primera trama, o hasta que se obtiene la sincronización. Si este largo de sub-trama es cero, entonces el procesamiento de estado de sincronía procede convenientemente a un estado 4904 denominado aquí como el estado de "tramas asincrónicas", el cual indica que aún no se ha alcanzado la sincronización. Este paso en el procesamiento se etiqueta por haber encontrado la cond 3, en la Figura 49. De otra manera, si el largo de trama es mayor que cero, entonces el procesamiento de estado de sincronía procede a un estado 4906 donde el estado de interfase se establece como "encontró una trama de sincronía". Este paso en el procesamiento se etiqueta por haber encontrado la cond 5, o condición 5, en la Figura 49. Además, si la máquina de estados ve un paquete de cabecera de trama y una buena determinación de CRC para un largo de trama mayor que cero, el procesamiento procede al estado "encontró una trama de sincronía". Este se etiqueta como cond 6, o condición 6, en la Figura 49. En cada situación en la que el sistema se encuentre en un estado diferente a "sin sincronía", si se detecta un paquete con un buen resultado de CRC, entonces el estado de interfase cambia al estado "en sincronía" 4908. Este paso en el procesamiento se etiqueta por haber encontrado la cond 1, o condición 1, en la Figura 49. Por otra parte, si la CRC en cualquier paquete no es correcta, entonces el procesamiento de estado sincrónico procede o regresa al estado de interfase 4902 del estado "TRAMA SIN SINCRONÍA". Esta porción del procesamiento se etiqueta por haber encontrado la cond 2, o condición 2, en el diagrama de estados de la Figura 49.

B. Tiempo de Adquisición para Sincronía La interfase puede configurarse para alojar un cierto número de "errores de sincronía" antes de decidir que se ha perdido la sincronización y de regresar al estado de "TRAMA SIN SINCRONÍA". En la Figura 49, una vez que la máquina de estados ha alcanzado el "ESTADO EN SINCRONÍA" y que no ha encontrado error alguno, continuamente brinda un resultado de cond 1, y permanece en el estado "EN SINCRONÍA". Sin embargo, una . vez que se detecta el resultado de cond 2, el procesamiento cambia el estado a un estado "de un error de sincronía" 4910. En este punto, si el procesamiento da como resultado la detección de otro resultado de cond 1, entonces la máquina de estados regresa al estado "en sincronía", de otra manera encuentra otro resultado de cond 2, y se mueve a un estado de "DOS ERRORES DE SINCRONÍA" 4912. nuevamente, si ocurre una cond 1, el procesamiento regresa la máquina de estados al estado de "EN SINCRONÍA". De otra manera, se encuentra otra cond 2 y la máquina de estados regresa al estado "sin sincronía". También es comprensible que si la interfase encuentra un "paquete de desconexión de enlace", entonces esto ocasionará que el enlace termine las transferencias de datos y regrese al estado de "trama sin sincronía" dado que no hay nada con qué sincronizarse, lo cual es referido como cumplir la cond 4, o condición 4, en el diagrama de estados de la Figura 49. Se comprende que es posible que haya una "copia falsa" repetida de la palabra única la cual puede aparecer en alguna ubicación fija dentro de la sub-trama. En esa situación, es altamente improbable que la máquina de estados se sincronice con la sub-trama debido a que la CRC en el Paquete de Cabecera de sub-trama también debe ser válido cuando se procesa con objeto de que el procesamiento de MDDI procesa al estado "EN SINCRONÍA". El largo de sub-trama en el Paquete de Cabecera de sub-trama puede establecerse igual a cero para indicar que el huésped transmitirá solamente una sub-trama antes de que se desconecte el enlace, y la MDDI se coloca en o se configura en un estado de hibernación inactiva. En este caso, el cliente debe recibir inmediatamente los paquetes por el enlace en avance después de detectar el Paquete de Cabecera de sub-trama debido a que solamente se envia una sola sub-trama antes de las transiciones de enlace al estado inactivo. En operaciones normales o típicas, el largo de sub-trama es diferente de cero y el cliente solamente procesa los paquetes de enlace en avance mientras que la interfase se encuentra en aquellos estados mostrados colectivamente como estados "EN SINCRONÍA" en la Figura 49. Un dispositivo cliente de modo externo puede anexarse al huésped mientras que el huésped ya está transmitiendo una secuencia de datos de enlace en avance. En esta situación, el cliente debe sincronizarse con el huésped. El tiempo requerido para que un cliente se sincronice con la señal de enlace en avance es variable dependiendo del tamaño de sub-trama y la tasa de datos de enlace en avance. La probabilidad de detectar una "copia falsa" de la palabra única como parte de los datos aleatorios, o más aleatorios, en el enlace en avance es mayor que cuando el tamaño de sub-trama es más grande. Al mismo tiempo, la capacidad de recuperación de una detección falsa es menor, y el tiempo tomado para hacerlo es mayor, cuando una tasa de datos de enlace en avance es menor. Para una o más modalidades, se recomienda o comprende que un huésped de MDDI debe ejecutar algunos pasos adicionales para asegurar que el enlace inverso de MDDI es estable antes de que detenga a la transmisión de enlace en avance de ir a un modo de bajo consumo de energía o desconecte completamente el enlace. Un problema que puede ocurrir es que si un huésped utiliza una medición incorrecta del valor de retraso de viaje redondo, esto puede ocasionar que falle toda la transmisión de datos inversos recibida subsecuentemente proveniente del cliente incluso a pesar de que el enlace en avance parezca fino. Esto podría suceder si el huésped intenta enviar un Paquete de Medición de Retraso de Viaje Redondo cuando el cliente no se encuentra en sincronía con el enlace en avance, o debido a un cambio extremo en la temperatura ambiental que ocasiona un gran cambio correspondiente en el retraso de propagación de los manejadores y receptores diferenciales lo cual afecta el retraso de viaje redondo. Un cable intermitente o una falla de contacto de conector también podria ocasionar que el cliente pierda temporalmente la sincronización y después obtenga nuevamente la sincronización, tiempo durante el cual, puede fallar en la recepción de un Paquete de Medición de Retraso de Viaje Redondo. Los subsecuentes paquetes de enlace inverso no serán capaces de decodificarse apropiadamente por el huésped. Otro tipo de problema que puede ocurrir es que si el cliente pierde temporalmente la sincronía y el huésped envía un Paquete de Desconexión de Enlace antes de que el cliente sea capaz de obtener nuevamente la sincronía. El huésped estará en hibernación mientras que el cliente es incapaz de ingresar al estado de hibernación debido a que no recibió el Paquete de Desconexión de Enlace y no tiene un reloj debido a que el enlace se encuentra en hibernación. Una técnica o modalidad útil para superar tales problemas es asegurarle al huésped que el cliente se encuentra en sincronía con el enlace en avance antes de poner al enlace el estado de hibernación. Si el huésped de MDDI es incapaz de realizar esto o no tiene tal oportunidad, tal como cuando pierde energía o que el enlace se pierde o falla abruptamente debido a una separación, ruptura, o desconexión de cable, conductor, o conector que ocurra durante la operación, entonces el huésped primeramente debe intentar asegurarse de que el cliente se encuentra en sincronía antes de iniciar un proceso de medición de retraso de viaje redondo o de enviar un paquete de Encapsulación de Enlace Inverso. Un huésped puede observar el campo de Cuenta de Errores de CRC en un paquete de Solicitud y Estado de Cliente enviado por el cliente a fin de determinar la integridad de enlace en avance. Este paquete es solicitado por el huésped de parte del cliente. Sin embargo, en el caso de una falla o interrupción de enlace mayor, esta solicitud muy probablemente se quedará sin respuesta debido a que un cliente no será capaz de decodificar apropiadamente el paquete, o incluso de recibirlo conjuntamente. La solicitud para la Cuenta de Errores de CRC que utiliza el o de Cliente enviado en un Paquete de Encapsulación de Enlace Inverso actúa como una primera verificación de integridad, una especie de primera linea de defensa. Además, un huésped puede enviar un Paquete de Medición de Retraso de Viaje Redondo para confirmar si la suposición sobre que el cliente ha fallado en sincronía es válida o no . Si el cliente no responde a un Paquete de Medición de Retraso de Viaje Redondo, el huésped concluirá que el cliente se encuentra fuera de sincronía y después puede comenzar el proceso para recuperar la sincronía. Una vez que el huésped concluye que muy probablemente el cliente ha perdido la sincronización con el enlace en avance, espera hasta la siguiente cabecera de sub-trama antes de intentar enviar cualquier paquete diferente a los paquetes de relleno. Esto se realiza con objeto de permitirle al cliente suficiente tiempo para detectar o buscar una palabra única contenida en el paquete de cabecera de subtrama. Después de esto, el huésped puede suponer que el cliente habrá reestablecido por si mismo dado que no habría encontrado la palabra única en la ubicación correcta. En este punto, el huésped puede seguir el paquete de cabecera de subtrama con un Paquete de Medición de Retraso de Viaje Redondo. Si el cliente no responde aún correctamente al Paquete de Medición de Retraso de Viaje Redondo, el huésped puede repetir el proceso de resincronización. Una respuesta correcta es una en la cual el cliente envia la secuencia especificada de regreso al huésped en el Periodo de Medición del Paquete de Medición de Retraso de Viaje Redondo. Si esta secuencia no se recibe, entonces fallarán los intentos por recibir datos inversos en un Paquete de Medición de Retraso de Viaje Redondo. Las fallas continuas de esta naturaleza pueden indicar algún otro error de sistema que tendrá que direccionarse de alguna otra manera, y no es parte de la sincronización de enlace en este punto. Sin embargo, si después de un Paquete de Medición de Retraso de Viaje Redondo exitoso el huésped aún ve datos corrompidos o sin respuesta en los Paquetes de Encapsulación de Enlace Inverso, debe confirmar que el muestreo de datos inverso es correcto al reenviar un Paquete de Medición de Retraso de Viaje Redondo. Si esto no es exitoso después de un cierto número de intentos para una modalidad se recomienda que el huésped que reduzca la tasa de datos inverso incrementando el valor de visor de tasa inversa. El huésped debe realizar la Detección de Fallas de Enlace y posiblemente los pasos de Resincronización de Enlace descritos previamente antes de colocar al enlace de MDDI en estado de hibernación. Esto generalmente asegurará que el Paquete de Medición de Retraso de Viaje Redondo ejecutado cuando reinicia posteriormente el enlace será exitoso. Si el huésped no tiene razón de sospechar de una falla de enlace, y el cliente reporta una respuesta correcta a un Paquete de Encapsulación de Enlace Inverso y ningún error de CRC de enlace en avance, un huésped puede asumir que todo está operando o funcionando convenientemente o apropiadamente (sin fallas de enlace por ejemplo) y procede con el proceso de hibernación/sub potencia. Otra manera en la cual un huésped puede probar su sincronización es que el huésped envié el Paquete de Medición de Retraso de Viaje Redondo y confirme la respuesta apropiada proveniente del cliente. Si la respuesta apropiada es recibida por el huésped, puede suponerse razonablemente que el cliente interprete exitosamente los paquetes de enlace en avance .

C. Inicialización Como se especificó con anterioridad, al momento del "inicio", el huésped configura el enlace en avance para operar a o debajo de una tasa de datos mínima requerida, o deseada, de 1 Mbps, y configura el largo de sub-trama y de tasa de trama de medios apropiadamente para una determinada aplicación. Es decir, tanto los enlaces en avance como inverso comienzan la operación utilizando la interfase de Tipo 1. Estos parámetros generalmente se van a utilizar sólo temporalmente mientras el huésped determina la capacidad o configuración deseada para la pantalla de cliente (u otro tipo de dispositivo cliente) . El huésped envía o transfiere un Paquete de Cabecera de sub-trama por el enlace en avance seguido por un Paquete de Encapsulación de Enlace Inverso el cual tiene el bit "0" de las Banderas Solicitar establecidas en un valor de un (1) , con objeto de solicitar que la pantalla o cliente responda con un Paquete de Capacidad de Cliente. Una vez que la pantalla adquiere sincronización en (o con) el enlace en avance, envia un Paquete de Capacidad de Cliente y un Paquete de Solicitud y Estado de Cliente por el enlace o canal inverso . El huésped examina el contenido del Paquete de Capacidad de Cliente con objeto de determinar cómo reconfigurar el enlace para un nivel óptimo o deseado de rendimiento. El huésped examina los campos de Versión de Protocolo y Versión de Protocolo Minimo para confirmar que el huésped y el cliente que utilizan versiones del protocolo que sean compatibles una con otra. Las versiones de protocolo generalmente permanecen como los dos primeros parámetros del Paquete de capacidad de cliente de manera que puede determinarse la compatibilidad incluso cuando otros elementos del protocolo pudiesen no ser compatibles o comprenderse completamente como compatibles. En modo interno, el huésped puede conocer los parámetros del cliente por adelantado sin tener que recibir un Paquete de Capacidad de Cliente. El enlace puede iniciar a cualquier tasa de datos en la que puedan operar tanto el huésped como el cliente. En muchas modalidades, un diseñador de sistemas muy probablemente seleccionar a iniciar el enlace a la máxima casa de datos posible a fin de acelerar la transferencia de datos, sin embargo, esto no se requiere y puede no ser utilizado en muchas situaciones. Para la operación en modo interno, la frecuencia de los impulsos estroboscópicos utilizados durante el inicio de enlace provenientes de la secuencia de hibernación generalmente serán consistentes con esta tasa deseada.

D. Procesamiento de CRC Para todos los tipos de paquete, la máquina de estados del procesador de paquete asegura que el verificador de CRC sea controlado apropiadamente o correctamente. También incrementa un contador de errores de CRC cuando una comparación de CRC da como resultado uno o más errores detectados, y restablece el contador de CRC al inicio de cada sub-trama que se procesa.

E. Pérdida Alternativa de Verificación de Sincronización Aunque la serie de pasos o estados anteriores funcionan para producir tasas de datos más altas o una velocidad de rendimiento de proceso y transferencia mayor, los solicitantes han descubierto que una configuración alternativa o cambio en las condiciones que el cliente utiliza para declarar que existe una pérdida de sincronización con el huésped, puede utilizarse eficazmente para alcanzar tasas de datos o un rendimiento de proceso y transferencia aún mayores. La nueva modalidad inventiva tiene la misma estructura básica, pero con las condiciones para cambiar los estados que han cambiado. Adicionalmente se implementa un nuevo contador para ayudar a la realización de verificaciones para sincronización de sub-trama. Estos pasos y condiciones se presentan con relación a la Figura 63, la cual ilustra una serie de estados y condiciones útiles para establecer las operaciones del método o máquina de estados. Solamente se muestran por claridad las porciones de "ESTADOS EN ADQUISICIÓN DE SINCRONÍA" y "ESTADOS EN SINCRONÍA". Además, dado que los estados resultantes son substancialmente iguales, como lo es la máquina de estados misma, utilizan la misma numeración. Sin embargo, las condiciones para cambiar los estados (y la operación de la máquina de estados) varian un poco, de manera que se enumeran todas por claridad entre las dos figuras (1, 2, 3, 4, 5, y 6, contra 61, 62, 63, 64, y 65) , como una conveniencia para identificar las diferencias. Dado que el estado de TRAMA ASINCRÓNICA no se considera en esta descripción, ya no se utiliza un estado (4904) ni la condición (6) en la figura. En la Figura 63, el sistema o cliente (para visualización o presentación) comienza con la máquina de estados 5000 en el estado 4902 "sin sincronía" preseleccionado, como en la Figura 49. El primer cambio de estados para los estados que cambian de la condición sin sincronía 4902 se encuentra en la condición 64 la cual es el descubrimiento del patrón de sincronía. Suponiendo que la CRC de la cabecera de sub-trama también pasa en este paquete (se cumple la condición 61), el estado de la máquina de estados de procesador de paquetes puede cambiar al estado en sincronía 4908. Un error de sincronía, condición 62, ocasionará que la máquina de estados cambie al estado 4910, y una segunda ocurrencia al estado 4912. Sin embargo, se ha descubierto que cualquier falla de CRC de un paquete de MDDI ocasionará que la máquina de estados se salga del estado en sincronía 4908, hacia el estado de un error de sincronía 4910. Otra falla de CRC de cualquier paquete de MDDI ocasionará un movimiento hacia el estado de dos fallas de sincronía 4912. Un paquete de codificado con un valor correcto de CRC ocasionará que la máquina de estados regrese al estado en sincronía 4908. Lo que ha cambiado es utilizar el valor de CRC o determinación para "cada" paquete. Es decir, tener la vista de máquina de estados en el valor de CRC para cada paquete a fin de determinar una pérdida de sincronización en lugar de sólo observar los paquetes de cabecera de sub-trama. En esta configuración o proceso, no se determina una pérdida de sincronización utilizando la palabra única y sólo valores de CRC de cabecera de sub-trama. Esta nueva implementación de interfase le permite al enlace de MDDI reconocer las fallas de sincronización mucho más rápidamente, y por lo tanto, recuperarse de ellas más rápidamente también. Para ser más robusto este sistema, el cliente también debe agregar o utilizar un contador de sub-tramas. El cliente verifica después la presencia de la palabra única al momento en que se espera que llegue u ocurra en una señal. Si la palabra única no ocurre en el momento correcto, el cliente puede reconocer que ha ocurrido una falla de sincronización mucho más rápidamente que si hubiese tenido que esperar varios (aquí tres) tiempos o periodos de paquete que fuesen mayores a un largo de sub-trama. Si la prueba para la palabra única indica que no está presente, en otras palabras que la sincronización es incorrecta, entonces el cliente puede declarar inmediatamente una pérdida de enlace de sincronización y moverse al estado sin sincronía. El proceso para verificar la presencia de palabra única apropiada, añade una condición 65 (cond 65) a la máquina de estados diciendo que la palabra única es incorrecta. Si se espera recibir un paquete de sub-trama en el cliente y no corresponde, el cliente puede inmediatamente ir al estado sin sincronía 4902, ahorrando tiempo adicional para esperar múltiples errores de sincronía (condición 62) normalmente encontrados en los estados 4910 y 4912. Este cambio utiliza un contador adicional o función de contabilización adicional en el núcleo de cliente para contar el largo de sub-trama. En una modalidad, se utiliza una función de cuenta descendente y se interrumpe la transferencia de cualquier paquete que se haya estado procesando para verificar la palabra única de sub-trama si el contador ha expirado. Alternativamente, el contador puede contar ascendentemente, comparándose la cuenta con un valor máximo deseado o valor particular deseado, punto en el cual se verifica el paquete actual. Este proceso protege al cliente de los paquetes de decodificación que se reciben incorrectamente en el cliente con largos de paquete extraordinariamente largos. Si el contador de largo de sub-trama necesitase interrumpir algún otro paquete que se estuviese decodificando, puede determinarse una pérdida de sincronización dado que ningún paquete debe cruzar un límite de sub-trama.

IX. Procesamiento de Paquetes Para cada tipo de paquete descrito con anterioridad que recibe la máquina de estados, emprende un paso o serie de pasos de procesamiento particulares para implementar la operación de la interfase. Los paquetes de enlace en avance generalmente se procesan de acuerdo con el procesamiento a manera de ejemplo listado en la Tabla XII mostrada a continuación.

Tabla XII X. Reducir la Tasa de Datos de Enlace Inverso Los inventores han observado que ciertos parámetros utilizados para el controlador de enlace de huésped pueden ajustarse o configurarse de cierta manera con objeto de alcanzar una tasa de datos de enlace inverso (escala) máxima o más optimizada, lo cual es muy deseable. Por ejemplo, durante el tiempo utilizado para transferir el campo de Paquetes de Datos Inversos del Paquete de Encapsulación de Enlace Inverso, el par de señales de MDDI_Stb cambia para crear un reloj de datos periódico a la mitad de la tasa de datos de enlace en avance. Esto ocurre debido a que el controlador de enlace de huésped genera la señal de MDDI_Stb que corresponde . a la señal de MDDI_DatosO como si estuviese enviando solo ceros. La señal de MDDI_Stb se transfiere desde el huésped a un cliente donde se utiliza para generar una señal de reloj para transferir datos de enlace inverso provenientes del cliente, con la que los datos inversos se envían de regreso al huésped. Una ilustración de cantidades típicas de retraso encontradas para la transferencia de señal y el procesamiento en trayectorias en avance e inversa en un sistema que emplea la MDDI, se muestra en la Figura 50. En la Figura 50, una serie de valores de retraso de 1.5 nseg., 8.0 nseg., 2.5 nseg., 2.0 nseg., 1.0 nseg., 1.5 nseg., 8.0 nseg., y 2.5 nseg., se muestran cerca de la porciones de procesamiento para la generación de Stb+/, transferencia de cable a cliente, receptor de cliente, generación de reloj, sincronización de señal, generación de DatosO/-, transferencia de cable a huésped, y etapas de receptor de huésped, respectivamente. Dependiendo de la tasa de datos de enlace en avance y los retrasos de procesamiento de señal encontrados, puede requerir más de un ciclo en la señal de MDDI_Stb para este efecto de "viaje redondo" o conjunto de eventos por completarse, lo cual da como resultado el consumo de cantidades indeseables de tiempo o ciclos. Para evadir este problema, el Divisor de Tasa Inversa hace posible para un tiempo de un bit en el enlace inverso expandir múltiples ciclos de la señal de MDDI_Stb. Esto significa que la tasa de datos de enlace inverso es menor que la tasa de enlace en avance . Debe observarse que el largo actual de retrasos de señal por la interfase pueden diferir dependiendo de cada sistema de huésped-cliente específico o hardware que se utiliza. Aunque no se requiere, generalmente cada sistema puede elaborarse a fin de tener un funcionamiento mejor utilizando el Paquete de Medición de Retraso de Viaje Redondo para medir el retraso actual en un sistema de manera que el Divisor de Tasa Inversa puede establecerse en un valor óptimo. El huésped puede soportar sea un muestreo de datos básico que es más sencillo pero opera a una velocidad menor o a un muestreo de datos avanzado que es más complejo pero soporta tasas de datos inversas superiores. La capacidad de cliente para soportar ambos métodos se considera la misma. Un retraso de viaje redondo se mide cuando el huésped tiene que enviarle un Paquete de Medición de Retraso de Viaje Redondo al cliente. El cliente le responde a este paquete enviando una secuencia de unos de regreso al huésped al interior de, o durante, una ventana de medición preseleccionada en ese paquete llamado el campo de Periodo de Medición. La sincronización detallada de esta medición se describió con anterioridad. El retraso de viaje redondo se utiliza para determinar la tasa a la cual pueden muestrearse con seguridad los datos de enlace inverso. La medición de retraso de viaje redondo consiste para determinar, detectar, o contar el número de intervalos de reloj de datos de enlace en avance que ocurre entre el inicio del campo de Periodo de Medición y el inicio del periodo de tiempo cuando la secuencia de respuesta Oxff, Oxff, 0x00 es recibida de nueva cuenta en el huésped de parte del cliente. Observe que es posible que la respuesta proveniente del cliente pueda recibirse como una pequeña fracción de un periodo de reloj de enlace en avance antes de que la cuenta de medición estuviese próxima a incrementarse. Si este valor no modificado se utiliza para calcular el Divisor de Tasa Inversa podria ocasionar errores de bit en el enlace inverso debido a un muestreo de datos no confiable. Un ejemplo de esta situación se ilustra en la Figura 51, donde las señales que representan MDDI_Datos en el huésped, MDDI_Stb en el huésped, el reloj de datos de enlace en avance al interior del huésped, y una Cuenta de Retrasos se ilustran en forma gráfica. En la Figura 51, la secuencia de respuesta recibió de parte del cliente un fragmento de un periodo de reloj de enlace en avance antes de que la Cuenta de Retraso estuviese próxima a incrementarse de 6 a 7. Si se supone que el retraso es 6, entonces el huésped mue'streará los datos inversos justo después de una transición de bit o posiblemente en la parte intermedia de una transición de bit. Esto podría dar como resultado un muestreo erróneo en el huésped. Por esta razón, el retraso medido típicamente debe incrementarse en uno antes de ser utilizado para calcular el Divisor de Tasa Inversa. El Divisor de Tasa Inversa es el número de ciclos de MDDI_Stb que el huésped debe esperar antes de muestrear los datos de enlace inverso. Dado que MDDI_Stb se recicla a una tasa que es de la mitad de la tasa de enlace en avance, la medición de retraso de viaje redondo corregido necesita dividirse por 2 y redondearse después hasta el siguiente entero. Esta relación se expresa como una fórmula: divisor_tasa_inversa= (retraso viaje redondo + RedondearHaciaArribaAlSig .

Si la medición de retraso de viaje redondo utilizada en este ejemplo fuese 7 en lugar de 6, entonces el Divisor de Tasa Inversa sería igual a 4. Los datos de enlace inverso se muestrean por el huésped en el borde de subida del Reloj de Enlace Inverso. Existe un contador o circuito o dispositivo conocido similar presente tanto en el huésped como en el cliente (pantalla) para generar el Reloj de Enlace Inverso. Los contadores se inicializan de manera que el primer borde de subida del Reloj de Enlace Inverso ocurre al inicio del primer bit en el campo de Paquetes de Enlace Inverso del paquete de Encapsulación de Enlace Inverso. Esto se ilustra, para el ejemplo determinado a continuación, en la Figura 52A. Los contadores se incrementan en cada borde de subida de la señal de MDDI__Stb, y el número de cuentas que ocurren hasta que son envueltas alrededor se establece por el parámetro de Divisor de Tasa Inversa en el Paquete de Encapsulación de Enlace Inverso. Dado que la señal de MDDI_Stb cambia a una mitad de la tasa de enlace en avance, entonces la tasa de enlace inverso se encuentra a la mitad de la tasa de enlace en avance dividida por el Divisor de Tasa Inversa. Por ejemplo, si la tasa de enlace en avance es 200 Mbps y el Divisor de Tasa Inversa es 4 entonces la tasa de datos de enlace inverso se expresa como: 1 2QQMbps = 25Mbps 2 4 Un ejemplo que muestra la sincronización de las líneas de señal de MDDI_Datos0 y MDDI_Stb en un Paquete de Encapsulación de Enlace Inverso se muestra en la Figura 52, donde los parámetros de paquete utilizados para ilustración tienen los valores: Largo de Paquete = 1024 (0x0400) Largo de Cambiar 1 = 1 Tipo de Paquete = 65 (0x41) Largo de Cambiar 2 = 1 Banderas de Enlace Inverso = 0 Divisor de Tasa Inversa = 2 CRC de Parámetro = 0xdb43 Solo Ceros es 0x00 Datos de paquete entre los campos de Largo de Paquete y CRC de Parámetro son: 0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, Oxdb, 0x00... El primer paquete de enlace inverso regresado por el cliente es el Paquete de Solicitud y Estado de Cliente que tiene un Largo de Paquete de 7 y un tipo de paquete de 70. Este paquete comienza con los valores de byte 0x07, 0x00, 0x46, ... y demás. Sin embargo, solamente el primer byte (0x07) es visible en la Figura 52. El primer paquete de enlace inverso es variable en el tiempo en prácticamente un periodo de reloj de enlace inverso en la figura para ilustrar un retraso de enlace inverso actual. Una forma de onda ideal con un retraso cero de viaje redondo de huésped a cliente se muestra como una gráfica de linea punteada. El byte de MS del campo de CRC de Parámetro se transfiere, precede por el tipo de paquete, después del campo de solo ceros. La señal estroboscópica proveniente del huésped está cambiando de uno a cero y de regreso en uno a medida que los datos provenientes del huésped cambian de nivel, formando impulsos más anchos. A medida que los datos se van a cero, la señal estroboscópica a la tasa más alta, solo el cambio en los datos en la linea de datos ocasiona un cambio cerca del final del campo de alineación. La sonda conmuta a la tasa más alta para el resto de la figura debido a los niveles fijos de 0 o 1 de la señal de datos para periodos extendidos de tiempo, y las transiciones que caen en el patrón de impulsos (borde) . El reloj de enlace inverso para el huésped se encuentra en cero hasta el final del periodo Cambiar 1, cuando el reloj comienza a alojar los paquetes de enlace inverso. Las flechas en la porción inferior de la figura indican cuándo se muestrean los datos, como seria aparente a partir del resto de la descripción. El primer byte del campo de paquete que se transfiere (aquí 11000000) se muestra comenzando después de Cambiar 1, y el nivel de la linea se ha estabilizado desde el manejador de huésped que se deshabilita. El retraso en el paso del primer bit, y como se observa para el bit tres, puede observarse en las . lineas punteadas para la señal de Datos. En la Figura 53, uno puede observar valores típicos del Divisor de Tasa Inversa con base en la tasa de datos de enlace inverso. El Divisor de Tasa Inversa se determina como resultado de una medición de enlace de viaje redondo para garantizar la operación de enlace inverso apropiada. Una primera región 5302 corresponde a un área de operación segura, una segunda región 5304 corresponde a un área de rendimiento regional, mientras que una tercera región 5306 indica las configuraciones que son improbables de funcionar apropiadamente. La medición de retraso de viaje redondo y la configuración de Divisor de Tasa Inversa son las mismas mientras operan con cualquier configuración de Tipo de Inferíase sea por el enlace en avance o el enlace inverso debido a que se expresan u operan en términos de unidades de los periodos de reloj actuales en lugar del número de bits transmitidos o recibidos. Típicamente, el Divisor de Tasa Inversa más grande posible es la mitad del número de bits que puede enviarse en la ventana de medición del Paquete de Medición de Retraso de Viaje Redondo utilizando una Inferíase de Tipo I, o para este ejemplo: (5 Ylbytes - Sbits I byte) nr ? n v y- X-¿ = 2048 2 También puede emplearse un método avanzado de muestreo de datos inverso como una alternativa que le permite al tiempo de bit inverso ser más pequeño que el retraso de viaje redondo. Para esta técnica, un huésped no solamente mide el retraso de viaje redondo, sino que también puede determinar la fase de la respuesta proveniente del cliente con respecto a un límite de bit "ideal" de un cliente y enlace con retraso cero. Conociendo la fase de la respuesta del dispositivo cliente, un huésped puede determinar un tiempo relativamente seguro para muestrear los bits de datos inversos provenientes del cliente. La medición de retraso de viaje redondo le indica a un huésped la ubicación del primer bit de datos inversos con respecto al inicio del campo de Paquetes de Datos Inversos. Una modalidad de un ejemplo de muestreo avanzado de datos inversos se ilustra en forma gráfica en la Figura 52B. Una señal actual de datos inversos con un retraso de viaje redondo cero se muestra como una forma de onda de line discontinua. El retraso de viaje redondo actual, entre 3.5 y 4 ciclos de MDDI_Stb, puede observarse como la diferencia en retraso entre la forma de onda sólida y la ideal. Este es el mismo retraso que se medirla utilizando el Paquete de Medición de Retraso de Viaje Redondo, y seria un valor de retraso de viaje redondo medido igual a 7 tiempos el bit de enlace en avance. En esta modalidad, los bits de datos inversos son 2 impulsos de MDDI_Stb largos, los cuales son 4 tiempos de bit de enlace en avance, lo cual corresponde a un divisor de tasa inversa igual a 2. Para el muestreo avanzado de datos inversos, es conveniente utilizar un divisor de tasa inversa preseleccionado de 2 en lugar de calcularlo como se describió con anterioridad. Esto parece ser una elección substancialmente óptima para el muestreo avanzado de datos inverso debido a que el punto de muestreo ideal puede determinarse fácilmente utilizando las mediciones convencionales descritas con anterioridad. El punto de muestreo ideal para datos inversos puede calcularse fácilmente tomando el resto del retraso de viaje redondo total dividido por el número de relojes de enlace en avance por bit inverso, o el retraso de viaje redondo módulo relojes de enlace en avance por bit inverso. Después, se resta 1 o 2 para obtener un punto seguro retirado de la transición de datos. En este ejemplo, 7 mod 4 = 3, entonces 3 - 1 = 2, o 3 - 2 = 1. El punto de muestreo seguro es 1 o 2 tiempos de bit de enlace en avance desde el borde del limite de bit "ideal" para retraso cero de viaje redondo. La figura muestra el punto de muestreo en 2 tiempos de bit de enlace en avance a partir del límite de bit ideal, como se indica por la serie de flechas verticales en la parte inferior del diagrama de sincronización. El primer punto de muestreo es el primer límite de bit ideal después del retraso de viaje redondo medido, más la variación para el muéstreo seguro. En este ejemplo, la medición de retraso de viaje redondo es 7, de manera que el siguiente límite de bit ideal se encuentra en el 8° tiempo de bit, después se suma sea 1 o 2 para el punto de muestreo seguro, de manera que el primer bit deba muestrearse sea 9 o 10 tiempos de bit de enlace en avance después del inicio del Campo de Paquetes de Datos Inversos.

XI . Tiempos de Cambiar y de Guardia El campo Cambiar 1 en el Paquete de Encapsulación de Enlace Inverso brinda tiempo para deshabilitar los manejadores de huésped y para habilitar los manejadores de cliente simultáneamente. El campo Guardar 1 en el Paquete de Medición de Retraso de Viaje Redondo permite la superposición del huésped y el cliente, de manera que los manejadores de cliente pueden habilitarse antes de deshabilitar los manejadores de interfase de huésped. El campo Cambiar 2 en el Paquete de Encapsulación de Enlace Inverso le permite transmitir completamente los datos en el campo anterior del cliente antes de habilitar los manejadores de huésped. El campo de Tiempo de Guardia 2 proporciona un valor de tiempo o periodo el cual le permite a los manejadores de cliente y de huésped manejarse simultáneamente en un nivel de cero lógico. Los campos Tiempo de Guardia 1 y Tiempo de guardia 2 generalmente se rellenan con valores preestablecidos o preseleccionados para largos que no serán ajustados. Dependiendo del hardware de interfase que se utiliza, estos valores pueden desarrollarse utilizando datos empíricos y ajustarse en algunos casos para mejorar la operación.

Cambiar 1 Varios factores contribuyen a una determinación del largo de Cambiar 1 y estos son la tasa de datos de enlace en avance, el tiempo máximo de deshabilitación de los manejadores de MDDI_Datos en el huésped, y el tiempo de deshabilitación del manejador de cliente el cual generalmente es el mismo que el tiempo de deshabilitación de huésped. El largo del campo Cambiar 1 se selecciona para que sea 24*tB?t (Tabla XI) . El largo en el número de bytes de enlace en avance del campo Cambiar 1 se determina utilizando el Factor de Tipo de Inferíase, y se calcula utilizando la relación: 24 L arg oCambtar ! = • FaclorTipo Interfase AVA =3 - FactorTipo Interfase AVA 8b?ts I byte donde el Factor de Tipo de Inferíase es 1 para el Tipo 1, 2 para el Tipo 2, 4, para el Tipo 2, y 8 para el Tipo 4.

Cambiar 2 Los factores que determinan la duración utilizada generalmente por Cambiar 2 son, el retraso de viaje redondo del enlace de comunicaciones, el tiempo máximo de deshabilitación de los manejadores de MDDI_Datos en el cliente, y el tiempo de habilitación del manejador de huésped que se especifica es el mismo que el tiempo de deshabilitación de manejador de cliente. El tiempo máximo de habilitación de manejador de huésped y el tiempo de deshabilitación de manejador de cliente se especifica en ¡Error! ¡No se encontró la fuente de referencia! ¡Error! ¡No se encontró la fuente de referencia! El retraso de viaje redondo se mide en unidades de tB?t- El largo minimo especificado en el número de bytes de enlace en avance del campo Cambiar 2 se calcula de acuerdo con la relación: Por ej emplo , un enlace en avance de Tipo 3 con un retraso de viaje redondo de 10 relojes de enlace en avance utiliza típicamente un retraso de Cambiar 2 en el orden de : f11+24 ^ L argo Cambjar2 = RQ dondearHaciaAír i baSig. Entero 4 = \%bytes " 8 j XII. Sincronización de Enlace Inverso Alternativo Aunque el uso de bandas de sincronización y de guardia descrito con anterioridad funciona para lograr una interfase de alta tasa de transferencia de datos, los inventores han descubierto una técnica para permitir invertir los largos de bit que son más cortos que el tiempo de viaje redondo, cambiando el descubrimiento de sincronización inversa. Como se presentó con anterioridad, el planteamiento anterior para la sincronización del enlace inverso se configura de manera tal que el número de ciclos de reloj se cuenta desde el último bit del Tiempo de Guardia 1 de un paquete de sincronización inversa hasta que se muestrea el primer bit en el borde de subida de un reloj 10. Esa(s) es (son) la(s) señal (es) de reloj utilizada (s) para sincronizar la entradas y salidas para la MDDI. El cálculo para el divisor de tasa inversa se determina entonces por: .. . . p , , r r - ? -7 o- r* ( retraso viaje redondo + 1 divisor _ tasa _ inversa = Re do??dearnac?aArnbab>?g.hntero\ = — =—= Esto proporciona un ancho de bit igual al retraso de viaje redondo lo cual da como resultado un enlace inverso muy confiable. Sin embargo, el enlace inverso ha mostrado ser capaz de ejecutarse más rápidamente, o a una tasa de transferencia de datos más alta, a la que los inventores desean sacarle ventaja. Una nueva técnica inventiva permite utilizar capacidades adicionales de la inferíase a fin de alcanzar mayores velocidades. Esto se realiza al hacer que el huésped cuente el número de ciclos de reloj hasta que se muestrea un uno, pero con el huésped que muestrea la línea de datos en ambos bordes de subida y de bajada durante el paquete de sincronización inversa. Esto le permite al huésped recoger el punto de muestreo más útil o incluso óptimo dentro del bit inverso para asegurarse de que el bit es estable. Es decir, encontrar el borde de subida más útil u óptimo para muestrear datos para los paquetes de encapsulación inversa de tráfico inverso. El punto de muestreo óptimo depende tanto del divisor de enlace inverso como del primer uno que se detectó en un borde de subida o un borde de bajada. El nuevo método de sincronización le permite al huésped buscar el primer borde del patrón OxFF OxFF 0x00 enviado por el cliente para la sincronización de enlace inverso a fin de determinar dónde muestrear un paquete de encapsulación inversa. Los ejemplos del bit inverso entrante y de cómo ese bit buscaría diversos divisores de tasa inversa, se ilustran en la Figura 64, junto con un cierto número de ciclos de reloj que han ocurrido desde el último bit del Tiempo de Guardia 1. En la Figura 64, un puede observar que si el primer borde ocurre entre un borde de subida y de bajada (designado como subida/bajada) , el punto de muestreo óptimo para un divisor de tasa inversa de uno, el punto de muestra óptimo es un borde de ciclo de reloj designado b' , como lo es el único borde de subida que ocurre en el periodo del bit inverso. Para un divisor de tasa inversa de dos, el punto de muestreo óptimo probablemente es aún el borde principal b' de ciclo de reloj dado que el borde de ciclo ?c' se encuentra más cerca de un borde de bit que b' . Para un divisor de tasa inversa de cuatro, el punto de muestreo óptimo probablemente es el borde de ciclo de reloj ?d' , dado que se encuentra más cerca del borde posterior del bit inverso donde probablemente se ha estabilizado el valor. Sin embargo, regresando a la Figura 64, el primer borde ocurre entre un borde de subida y uno de bajada (designado como subida/bajada), el punto de muestreo óptimo para un divisor de tasa inversa de uno es el borde ?a' de ciclo de reloj del punto de muestreo, dado que es el único borde de subida en el periodo de tiempo del bit inverso. Para un divisor de tasa inversa de dos, el punto de muestreo óptimo es el borde xb' , y para un divisor de tasa inversa de cuatro el punto de muestreo óptimo es el borde c' . Uno puede ver que los divisores de tasa inversa se hacen más y más grandes, el punto de muestreo óptimo se vuelve más fácil de asegurar o seleccionar, dado que debe ser el borde de subida que se encuentra más cerca de la mitad. El huésped puede utilizar esta técnica para encontrar el número de bordes de reloj de subida antes de que se observe el borde de datos de subida de los datos de paquete de sincronización en la línea de datos. Después puede decidirse, con base en si ocurre el borde entre un borde subida y uno de bajada o entre un borde de bajada y uno de subida, y cuál es el divisor de tasa inversa, cuántos ciclos de reloj adicionales se añaden a un contador numérico, para asegurar razonablemente que el bit siempre se muestrea tan cerca de la mitad como es posible. Una vez que el huésped ha seleccionado o determinado el número de ciclos de reloj, puede "explorar" diversos divisores de tasa inversa con el cliente para determinar si funcionará un divisor de tasa inversa en particular. El huésped (y cliente) puede comenzar con un divisor de uno y verificar la CRC del paquete de estado inverso recibido desde el cliente para determinar si esta tasa inversa funciona apropiadamente para transferir datos. Si la CRC está corrupta, probablemente existe un error de muestreo, y el huésped puede incrementar el divisor de tasa inversa e intenta solicitar nuevamente un paquete de estado. Si el segundo paquete solicitado está corrupto, el divisor puede incrementarse nuevamente y puede realizarse nuevamente la solicitud. Si este paquete se decodifica correctamente, este divisor de tasa inversa puede utilizarse para todos los futuros paquetes inversos . Este método es efectivo y útil debido a que la sincronización inversa no debe cambiar el cálculo de sincronización de viaje redondo inicial. Si el enlace en avance es estable, el cliente debe continuar decodificando los paquetes de enlace en avance incluso si existen fallas de enlace inverso. Por supuesto, aún es responsabilidad del huésped establecer un divisor de enlace inverso para el enlace, dado que este método no garantiza un enlace inverso perfecto. Además, el divisor dependerá básicamente de la calidad del reloj que se utiliza para generar un reloj 10. Si ese reloj tiene una cantidad significativa de inestabilidad, existe una mayor posibilidad de un error de muestreo. Esta probabilidad de error se incrementa con la cantidad de ciclos de reloj en el retraso de viaje redondo . Esta implementación parece funcionar mejor para un ato inverso de Tipo 1, pero puede presentar problemas para los datos inversos de Tipo 2 a Tipo 4 debido a la distorsión entre las lineas de datos que potencialmente sean demasiado grandes para operar el enlace a la tasa que funcione mejor para solo un par de datos. Sin embargo, probablemente no necesita reducirse la tasa de datos al método anterior incluso con el Tipo 2 al Tipo 4 para su operación. Este método también puede funcionar mejor si se duplica en cada línea de datos para seleccionar la ubicación de muestra de reloj ideal u óptima. Si se encuentran en el mismo tiempo de muestreo para cada par de datos, este método seguirá funcionando. Si se encuentran en diferentes períodos de muestreo, pueden utilizarse dos planteamientos diferentes. Lo primero es seleccionar una ubicación de muestra deseada o más optimizada para cada punto de datos, incluso si no es la misma para cada par de datos. Después, el huésped puede reconstruir el flujo de datos después de muestrear todos los bits provenientes del conjunto de pares de datos: dos bits para el Tipo 2, cuatro bits para el Tipo 3, y ocho bits para el Tipo 4. La otra opción es que el huésped incremente el divisor de tasa inversa de manera tal que los bits de datos para cada par de datos puedan muestrearse en el mismo borde de reloj .

XIII. Efectos del Retraso de Enlace y Distorsión La distorsión de retraso en el enlace en avance entre los pares de MDDI_Datos y MDDI_Stb puede limitar la máxima tasa de datos posible a menos que se utilice una compensación de distorsión de retraso. Las diferencias en el retraso que ocasionan la distorsión de sincronización se deben a la lógica del controlador, los manejadores y receptores de linea, y el cable y conectores como se delinea a continuación.

A. Análisis de Sincronización de Enlace Limitado por Distorsión (MDDI de Tipo 1) 1 . Ejemplo de Retraso y Distorsión de un Enlace de Tipo 1 Un circuito de interfase típico similar al mostrado en la Figura 41, se muestra en la Figura 57 para alojar un enlace de interfase de Tipo 1. En la Figura 57, se muestran valores típicos o a manera de ejemplo para el retraso y distorsión de propagación para cada una de las etapas de procesamiento o de interfase de un enlace en avance de MDDI de Tipo 1. La distorsión en el retraso entre MDDI_Stb y MDDI_DatosO ocasiona que se distorsione el ciclo de trabajo del reloj de salida. Los datos en la entrada D de la etapa del multivibrador de receptor (RXFF - receiver flip-flops) que utiliza los multi-vibradores 5728, 5732, cambia ligeramente después del borde de reloj de manera que puede muestrearse confiablemente. La figura muestra dos lineas de retraso en cascada 5732a y 5732b que son utilizadas para solucionar dos problemas diferentes para crear esta relación de sincronización. En la implementación actual, estas pueden combinarse en un solo elemento de retraso. En la Figura 58 se ilustran Datos, Stb, y la Sincronización de Recuperación de Reloj en un Enlace de Tipo 1 para el procesamiento de señales a manera de ejemplo mediante la interfase. La distorsión de retraso total que es significativamente generalmente surge o proviene de la suma de la distorsión en las siguientes etapas: multivibrador de transmisor (TXFF - transmitter flip-flops) con multivibradores 5704, 5706; manejador de transmisor (TXDRVR - transmitter driver) con los manejadores 5708, 5710; el CABLE 5702; receptor de linea de receptor (RXRCVR) con los receptores 5722, 5724; y la XOR lógica de receptor (RXXOR) . Retrasol 5732a debe corresponder o exceder la compuerta XOR 5736 en la etapa RXXOR que se determina por la relación: t D-rt n l Retr as Jl l == tpD- rnáx (XOR ) Es deseable cumplir este requisito de manera que la entrada D del multivibrador de receptor 5728, 5732 no cambie antes de su entrada de reloj . Esto es válido si el tiempo de retención del RXFF es cero. El propósito o función de Retraso2 es compensar el tiempo de retención del multivibrador RXFF de acuerdo con la relación: tpß-min (Retraso21 = tp(RXFF) En muchos sistemas esto será cero debido a que el tiempo de retención es cero, y por supuesto en ese caso el máximo retraso de Retraso2 también puede ser cero. La contribución en el peor escenario es distorsión en la etapa de XOR de receptor es el caso de datos tardios/estroboscópica inicial donde Retrasol es un valor máximo y la salida de reloj proveniente de la compuerta XOR llega tan temprano como es posible de acuerdo con la relación: toiSTORSIótTmíy. í RXXOR > = £pd-máx ( Retrasol ) - tpD-min {XOFt) En esta situación, lo datos pueden cambiar entre dos periodos de bit, n y n+1, muy cerca del tiempo donde el bit n+1 se sincroniza en el multivibrador de receptor. La máxima tasa de datos (mínimo periodo de bit) de un enlace de MDD1 de Tipo 1 es una función de la máxima distorsión encontrada en todos los manejadores, cable, y receptores en el enlace de MDDI más la configuración de datos totales en la etapa de RXFF. La distorsión de retraso total en el enlace hasta la salida de la etapa de RXRCVR puede expresarse como : tDISTORSIÓN-máx (ENLACE) = tDISTOF?IÓN-máy. (TXFF) + tr)ISTORSIÓN-máx (TXDRVR) + tDISTORSIÓN-máx (CABLE) + tciSTCPSIÓN- áx (RXRCVP) representando el "cable" una variedad de conductores o interconexiones o cables y el retraso correspondiente, y el periodo de bit mínimo se determina por: tsiT-mln = tDIST0F3IQK-mí.-: (hi;L.-. E) + 2 • t¡¡-Z'F + tñsxmecrí? + tciSTORSIÓN- áx (RXXOR) + tj_nesta?:.j.ii¿?- a-h é.?e-5c¡ + tpe-miy. íRíi rasoj:) + sü íR FF) En el ejemplo mostrado en la Figura 57 para modo externo, t-vt«..r- ió¡¡-n--M(?iJi.ACE:= 1000 pseg y el periodo de bit mínimo puede expresarse como: ta? -p n = 1000 + 2-125 + 625 + 125 + 200 + 0 + 100 = 2300 pseg, o se establece como aproximadamente 434 Mbps. En el ejemplo mostrado en la Figura 57 para el modo interno, toisTORsióN-máxíENLRCE) = 500 pseg y el periodo de bit mínimo puede expresarse como: taiT-mir, = 500 + 2-125 + 625 + 125 + 200 + 0 + 100 = 1800 pseg, o se establece como aproximadamente 555 Mbps.

B. Análisis de Sincronización de Enlace para MDDI de Tipo 2, 3, y 4 Un circuito de interfase tipico similar al mostrado en las Figuras 41 y 57, se muestra en la Figura 59 alojando los enlaces de interfase de Tipo 2, 3, y 4. Se utilizan elementos adicionales en las etapas de TXFF (5904), TXDRVR (5908), RXRCVCR (5922) y RXFF (5932, 5928, 5930) para alojar el procesamiento adicional de señales. En la Figura 59, se muestran valores típicos o a manera de ejemplo para el retraso de propagación y distorsión para cada una de las diversas etapas de procesamiento o interfase de un enlace en avance de MDDI de Tipo 2. Además de la distorsión en el retraso entre MDDI_Stb y MDDI_DatosO que afecta el ciclo de trabajo del reloj de salida, también existe distorsión entre estas dos señales y las demás señales de MDDI_Datos . Los datos en la entrada D de la etapa del multivibrador B del receptor (RXFFB) consistente en los multivibradores 5928 y 5930, cambian ligeramente después del borde de reloj de manera que puedan muestrearse confiablemente. Si MDDI_Datosl llega antes que MDDI_Stb o MDDI_DatosO entonces MDDI_Datosl debe retrasarse para muestrearse por al menos la cantidad de distorsión de retraso. Para realizar esto, se retrasan los datos utilizando la línea de retraso Retraso3. Si MDDI_Datosl llega después de MDDI_Stb y MDDI_DatosO y también está retrasada por Retraso3 entonces el punto donde cambia MDDI_Datosl se mueve más cerca del siguiente borde de reloj . Este proceso determina un límite superior de la tasa de datos de un enlace de MDDI de Tipo 2, 3, o 4. Algunas posibilidades diferentes a manera de ejemplo para la sincronización o relación de distorsión de dos señales de datos y MDDI_Stb con respecto a la otra se ilustra en las Figuras 60A, 60B, y 60C. Con objeto de muestrear confiablemente los datos en RXFFB cuando MDDI_DatosX llega tan temprano como es posible, Retraso3 se establece de acuerdo con la relación: tpD- infRecr?S?3> - tps ir ?i- Ay-íErí A E) + ¿H (?? FB,) + t pjj-rnáx (XOR) La máxima velocidad de enlace se determina por el periodo de bit mínimo permisible. Este es afectado cuando MDDI_DatosX llega tan tarde como es posible. En ese caso, el tiempo de ciclo mínimo permisible se determina por: ¿BIT-min + tSiJ(pXFFB) ~ tpo-min (XOR) El límite superior de la velocidad de enlace es : tpD- á:-: (R traso3) ~ tpD-min (Retraso3) y dado el supuesto : tBIT-min (iimite-inf riarj = 2 • tuISTOR ? rc'.7-máx NLACE) + £ D-KÁ:-: (X?R) + t su (RXFFB) ~ ts (RXFFB) En el ejemplo determinado con anterioridad, el limite inferior del periodo de bit mínimo se determina por la relación: tBIT- ín (limite-inferior) = 2 • ( 1000 + 2 ' 125 + 625 + 200) + 1500 + 100 + 0 = 5750 pseg, que es aproximadamente 174 Mbps. Esto es mucho más lento que la máxima tasa de datos que puede utilizarse con un enlace de Tipo 1. La capacidad de compensación de distorsión de retraso automático de la MDDI reduce significativamente la afectación que tiene la distorsión de retraso sobre el factor de máxima tasa de enlace solo en el borde de la configuración de datos válido. La distorsión calibrada entre MDDI_DatosO y MDDI_Stb es: tDISTORSXÓN-mi:. •-. ^ . = 2 • t ES.-AC:.->í!lENTü-DEpn?CIÓN-mity. y el periodo de bit mínimo es : -BIT- ín-Calibrada = toiSTOPSIÓN-tiÁx (Calibrada) + 2 * tB_j-p + tñsimetría + tinestabilidad-huéspea + tcieT FSIÓN-mú>: ( RXAND+ PXXOR ) + t SU (RXFF) Donde "TB" o te representa la inestabilidad de la señal desde un límite de bit hasta un nivel mínimo de asimetría. Asimetría se refiere simplemente a la naturaleza asimétrica del retraso interno mediante o de los receptores diferenciales. "TP4" se encuentra asociado con o se define efectivamente para propósitos de caracterización eléctrica y prueba como la conexión o interfase (patillas del dispositivo de controlador de MDDI en el cliente) para los manejadores de línea diferenciales y receptores para el cliente. Representa un punto conveniente o predeterminado desde el cual se mide el retraso de señal y se caracteriza para el enlace a través del resto del sistema. En una modalidad, un valor máximo del parámetro tß en TP4 se define por la relación tDistz?:sxó -Difsrenciai-iP4-DRVíi-Ext = 0.3- t_Bit para el modo externo y t l storsión-D?facs ciai-tp-}-DRVR-INT = 0.6 • tB?t para el modo interno para los transmisores de cliente; y f -i..t = 0.051-tBir +175 ps para el modo externo para los receptores de cliente. La etiqueta TP4 que es bastante útil para numerar diversos puntos de prueba (TP - test points) en la interfase y enlaces . En una modalidad, esta ubicación de punto de prueba se define por ser la misma tanto para los modos internos como externos. Existe un punto de prueba "TPO" correspondiente para, o asociado con, las patillas de conexión o de interfase del dispositivo de controlador de MDDI en el huésped que contiene los manejadores y receptores de línea diferencial. En esta modalidad, un valor máximo del parámetro TB en TPO se define por la relación tB-tpo-RcvR-INT = 0.051- tBIT + 50ps, para el modo interno, y t3-.7Fo-R vR-SX = 0.051- tSy + 175ps, para el modo externo para los receptores de huésped; y tB-tP0 = 0 . 102 - tB?t para los transmisores de huésped. En el ejemplo mostrado en la Figura 59, tüjstoi?s?óN-má (Dato3Q- b-caiib aa i = 300 pseg y el periodo de bit mínimo: tBjT-min-Mib8*. = 300 +-2- 125 + 625 + 200 + 175 + 100 = 1650 pseg, aproximadamente 606 Mbps. Con objeto de muestrear los dato confiablemente en RXFFB cuando llega MDDl_Datosl tan temprano como es posible, el retraso programable asociado se ajusta a la configuración óptima con una precisión de una derivación, y se agrega un retraso de una derivación adicional por seguridad. La máxima velocidad de enlace se determina por el periodo de bit mínimo permisible. Ese se ve afectado cuando MDDI__Datosl llega tan tarde como es posible. En ese caso, el tiempo de ciclo mínimo permisible tBIT-min-Datosl-Calxi'i ? Í? = 2 ' tfi jci -ip -nco-DERIVACIÓN-max + 2 • t?A-TP4 donde "TA" o t? representa la inestabilidad de señal desde un limite de bit hasta un cruce central. En el ejemplo determinado en la Figura 59, el límite inferior del periodo de bit mínimo basado en MDDI_Datosl de muestreo es: tBit-mín-D cz«?-cu??>u.j = 2 -150 + 2 -125 = 550 pseg En una modalidad, un tiempo de retraso total típico para la distorsión de retraso, asimetría de retraso, e Inestabilidad de Reloj en el transmisor de huésped para el Modo Interno se definiría como: tAsimettíd-TXFF + Ff + tDisc isiSrs-'?XDRVf + = 0.467- {tSIT - 150 ps) , y para el modo externo es: -si. n-l FF + tD?sc:rsur-T?DRVfi + ~ O.TBD- (tan - 150 TBD ps) , mientras que un tiempo de retraso total típico para distorsión de retraso, asimetría de retraso, y el tiempo de configuración en el dispositivo cliente (tB-tp4) para modo interno es: tñsímetría-RXRCVR "^ CAsimet ri á-ft_\"XC>r. + tti scrrsián-P 'PCVJí + toiscorsión-RXXOR + tCenfiguración-?C:FF ~ 0 . 307 - ( t¡?JT — 150 ps ) , y para el modo externo : tAsimetría-RXRCVR "•" + t.Di.storsi?Ji-R?RCVR "t toistorsídn-RXXOR + tconriguración-R? F ~ 0 . TJ3 ' ( taiT ~ TBD ps ) , donde el término TBD es una etiqueta de mantenimiento de lugar flexible para valores a determinarse en el futuro los cuales dependerán de una variedad de características bien comprendidas y requisitos operacionales para las conexiones de modo externos.

XIV. Descripción de Interconexión de Capa Física Las conexiones físicas útiles para implementar una interfase de acuerdo con la presente invención pueden realizarse utilizando partes comercialmente disponibles tales como el número de parte 3260-8S2(01) fabricadas por Hirose Electric Company Ltd. por la parte del huésped y el número de parte 3240-8P-C fabricado por Hirose Electric Company Ltd. por la parte del dispositivo cliente. Una asignación de patillas de interfase a manera de ejemplo o "diagrama de patillas" para tales conectores utilizados con una interfase de Tipo I/Tipo 2 se lista en la Tabla XIII, y se ilustra en la Figura 61. Tabla XIII La protección se conecta con HUÉSPED_Gnd en la interfase de huésped, y se conecta un cable de drenaje de protección en el cable la protección del conector de cliente. Sin embargo, la protección y el cable de drenaje no se conectan a la tierra del circuito al interior de un cliente.

Los elementos o dispositivos de interconexión se seleccionan o diseñan con objeto de ser lo suficientemente pequeños para utilizarse con dispositivos móviles de comunicaciones y cómputo, tales como PDAs y teléfonos inalámbricos, o dispositivos portátiles para juegos, sin ser obstructivos o antiestéticos en comparación con el tamaño relativo del dispositivo. Cualquier conector y cableado debe ser lo suficientemente durable para su uso en un ambiente típicamente de consumidor y permitir un tamaño reducido, especialmente para el cableado, y de costo relativamente bajo. Los elementos de transferencia deben alojar señales de datos y estroboscópicas que son datos NRZ diferenciales que tienen una tasa de transferencia de hasta aproximadamente 450 Mbps para el Tipo 1 y el Tipo 2 y hasta 3.6 Gbps para la versión de Tipo 4 paralela de 8 bits. Para aplicaciones de modo interno ya no existen conectores en el mismo sentido que los conductores utilizados o tales elementos de conexión tienen a ser demasiado miniaturizados . Un ejemplo son los "receptáculos" de fuerza de inserción cero para recibir circuitos integrados o elementos que alojan al dispositivo huésped o cliente. Otro ejemplo es cuando el huésped y el cliente residen en tarjetas de circuito impreso con diversos conductores de interconexión, y tienen "patillas" o contactos que se extienden desde los alojamientos que se encuentran soldados a los contactos en los conductores para la interconexión de circuitos integrados .

XV. Operación En las Figuras 54A y 54B se muestra un resumen de los pasos generales realizados para procesar datos y paquetes durante la operación de una interfase utilizando modalidades de la invención, junto con un resumen del aparato de interfase que procesa los paquetes en la Figura 55. En esta figuras, el proceso inicia en un paso 5402 con una determinación referente a si el cliente y el huésped se conectan o no utilizando una trayectoria de comunicaciones, aquí es un cable. Esto puede ocurrir mediante el uso de consultas periódicas por el huésped, utilizando software o hardware que detecta la presencia de conectores o cables o señales en las entradas al huésped (tal como se ve para las ínterfases de USB) , u otras técnicas conocidas. Si no existe ningún cliente conectado al huésped, entonces simplemente puede ingresar a un estado de espera de alguna duración predeterminada, dependiendo de la aplicación, va a un modo de hibernación, o se desactiva para esperar el uso posterior que pudiese requerir un usuario como tomar acciones o reactivar al huésped. Por ejemplo, cuando un huésped reside en un dispositivo de tipo computadora, un usuario pudiese tener que hacer clic en un icono de pantalla o solicitarle a un programa que active el procesamiento de huésped para buscar al cliente. Nuevamente, el simple enchufe de la conexión de tipo USB podría activar el procesamiento del huésped, dependiendo de las capacidades y configuración del huésped o del software residente en el huésped. Una vez que el cliente se conecta al huésped, o viceversa, o que se detecta como presente, ya sea el cliente o el huésped envía paquetes apropiados que solicitan el servicio en los pasos 5404 y 5406. El cliente debe enviar sea los paquetes de Solicitud o Estado de Servicio de Cliente en el paso 5404. Debe observarse que el enlace, como se describió con anterioridad, podria haberse desconectado con anterioridad o estar en un modo de hibernación de modo que este puede no ser una inicialización completa del enlace de comunicaciones a continuación. Una vez que se sincroniza el enlace de comunicaciones y que el huésped está intentando comunicarse con el cliente, el cliente también le proporciona un paquete de Capacidades de Cliente al huésped, como en el paso 5408. El huésped puede comenzar ahora a determinar el tipo de soporte, incluyendo las tasas de transferencia, que puede alojar el cliente. En términos generales, el huésped y el cliente negocian también el tipo (tasa/velocidad) de modo de servicio por utilizarse, por ejemplo, Tipo 1, Tipo 2, etcétera, en un paso 5410. Una vez que se establece el tipo de servicio el huésped puede comenzar a transferir la información. Además, el huésped puede utilizar Paquetes de Medición de Retraso de Viaje Redondo para optimizar la sincronización de los enlaces de comunicación en paralelo con otros procesamientos de señal, como se muestra en el paso 5411. Como se declaró con anterioridad, todas las transferencias comienzan con un Paquete de Cabecera de Sub-Trama, mostradas en transferencia en el paso 5412, seguido del tipo de datos, aquí paquetes de flujo de audio y de video, y paquetes de relleno, mostrados en transferencia en el paso 5414. Los datos de audio y video se habrán preparado con anterioridad o mapeado en paquetes, y los paquetes de relleno se insertan según sea necesario o según se desee para llenar un número solicitado de bits para las tramas de medios. El huésped puede enviar paquetes tales como los Paquetes de Habilitación de Canal de Audio en Avance a fin de activar los dispositivos de sonido. Además, el huésped puede transferir comandos de información que utiliza otros tipos de paquete descritos con anterioridad, mostrados aquí como la transferencia de Mapa de Colores, Transferencia de Bloque de Bits u otros paquetes en el paso 5416. Además, el huésped y el cliente pueden intercambiar datos relacionados con un teclado o con dispositivos de señalización que utilizan los paquetes apropiados. Durante la operación, puede ocurrir uno de varios eventos diferentes lo cual lleva a que el huésped o cliente desee una tasa de datos o un tipo de modo de interfase diferente. Por ejemplo, una computadora u otro ato de comunicación de dispositivo podría encontrar condiciones de carga para procesar datos lo que ocasiona una disminución en la preparación o presentación de los paquetes. Un dispositivo cliente que recibe los datos podría cambiar de una fuente de energía de CA dedicada a una fuente de energía de baterías más limitada, y tampoco ser capaz de transferir datos tan rápidamente, o comandos de proceso tan fácilmente, o no es capaz de utilizar el mismo grado de resolución o profundidad de color bajo los ajustes de potencia más limitados. Alternativamente, T podría abatirse o desaparecer una condición restrictiva que le permite al dispositivo transferir datos a tasas más altas. Esto es -más deseable, puede realizarse una solicitud para cambiar a un modo de tasa de transferencia más alta. Si ocurren o cambian estos u otros tipos de condiciones conocidas, el huésped o el cliente pueden detectarlos e intentar renegociar el modo de interfase. Esto se muestra en el paso 5420, donde el huésped le envia los Paquetes de Solicitud de Transferencia de Inferíase al cliente que solicita una transferencia a otro modo, el cliente envía los Paquetes de Reconocimiento de Tipo de Inferíase que confirman la búsqueda de un cambio, y el huésped envía los Paquetes de Transferencia de Tipo de Rendimiento para realizar el cambio al modo especificado. Aunque no se requiere un orden de procesamiento en particular, el cliente y el huésped también pueden intercambiar paquetes que se refieren a los datos destinados para o recibidos de los dispositivos de señalización, teclados, u otros dispositivos de entrada de tipo de usuario asociados básicamente con el cliente, aunque tales elemento también pueden estar presentes en la parte del huésped. Estos paquetes se procesan típicamente utilizando un elemento de tipo procesador general y no la máquina de estados (5502) . Además, algunos de poscomandos descritos con anterioridad también serán procesados por el procesador general. (5504, 5508) Después de que se han intercambiado datos y comandos entre el huésped y el cliente, en el mismo punto se toma una decisión sobre si van a transferirse o no datos adicionales o el huésped o el cliente van a dejar de realizar la transferencia. Esto se muestra en el paso 5422. Si el enlace va a ingresar un estado de hibernación o va a desconectarse completamente, el huésped le envía un paquete de Desconexión de Enlace al cliente, y ambas partes terminan la transferencia de datos . Los paquetes que se transfieren en las operaciones anteriores de procesamiento se transferirán utilizando los manejadores y receptores anteriormente descritos con relación a los controladores de huésped y de cliente. Estos manejadores de lineas y otros elementos lógicos se conectan a la máquina de estados y a los procesadores generales descritos con anterioridad, como se ilustra en el resumen de la Figura 55. En la Figura 55, una máquina de estados 5502 y los procesadores generales 5504 y 5508 pueden conectarse adicionalmente a otro elemento no mostrados tales como una interfase de USB dedicada, elementos de memoria, u otros componentes que residen al exterior del controlador de enlace con el cual interactúan, incluyendo, pero sin limitarse a, la fuente de datos, y los chips de control de video para visualizar los dispositivos de visualización. Los procesadores, y la máquina de estados proporcionan control sobre la habilitación y deshabilitación de los manejadores como se describió con anterioridad con relación a los tiempos de guardia, etcétera, a fin de asegurar un eficiente establecimiento o terminación de enlace de comunicaciones, y transferencia de paquetes.

XIV. Memorias Temporales de Trama de Visualización Los requisitos de colocación en memoria temporal de datos de video son diferentes para mover imágenes de video en comparación con las gráficas de computadora. Los datos de píxel se almacenan muy frecuentemente en una memoria temporal de trama local en el cliente de manera que la imagen en el cliente pueda refrescarse localmente. Cuando se está visualizando video de movimiento total (prácticamente cada píxel en la pantalla cambia cada Trama de Medios) normalmente se prefiere almacenar los datos de pixel entrantes en una memoria temporal de trama mientras la imagen en la pantalla se refresca desde una segunda memoria temporal de trama. Pueden utilizarse más de dos memorias temporales para eliminar los artefactos visibles como se describe a continuación. Cuando se ha recibido una imagen completa en una memoria temporal de tramas, entonces pueden intercambiarse los roles de las memorias temporales, y la imagen recientemente recibida se utiliza después para refrescar la pantalla y la otra memoria temporal se llena con la siguiente trama de la imagen. Este concepto se ilustra en la Figura 88A, donde los datos de pixel se escriben en la memoria temporal desconectada estableciendo los bits de Actualización de Pantalla en "01". En otras aplicaciones, el huésped envía necesita actualizar solamente una pequeña porción de la imagen sin tener que volver a pintar toda la imagen. En esta situación, se desea escribir los nuevos pixeles directamente a la memoria temporal que se utiliza para refrescar la pantalla, como se ilustra detalladamente en la Figura 88B. En aplicaciones que tienen una imagen fija con una pequeña ventana de video es más fácil escribir la imagen fija en ambas memorias temporales (los bits de actualización de pantalla son iguales a "11") como se muestra en la Figura 88C, y subsecuentemente escribir los pixeles de la imagen en movimiento a la memoria temporal desconectada estableciendo los bits de actualización de pantalla en "01". Las siguientes reglas describen la manipulación útil de los apuntadores de memoria temporal mientras se escribe simultáneamente información nueva al cliente y se refresca la pantalla. Existen tres apuntadores de memoria temporal: current_fill (llenar_actual) apunta a la memoria temporal que actualmente se está rellenando con datos provenientes del enlace de MDDI. Just-filled (recién-llena) apunta a la memoria temporal que se llenó más recientemente. Being_displayed (desplegándose) apunta a la memoria temporal utilizada actualmente para refrescar la pantalla. Los tres apuntadores de memoria temporal pueden contener valores desde 0 hasta N-l donde N es el número de memorias temporales de pantalla, y N > 2. La aritmética en los apuntadores de memoria temporal es od (módulo) N, por ejemplo, cuando N= 3 y llenar__actual = 2, un incremento de llenar_actual ocasiona que llenar_actual se establezca en 0. En el simple caso donde N= 2, recién_llena siempre es el complemento de llenar_actual . En cada limite de Trama de Medios de MDDI (Paquete de Cabecera de Sub-trama con el campo de Cuenta de Sub-tramas igual a cero) se realizan las siguientes operaciones en el orden especificado: establecer recién_llena igual a llenar_actual, y establecer llena_actual igual a llenar_actual + 1. Los Paquetes de Flujo de Video de MDDI actualizan las memorias temporales de acuerdo con la estructura metodología de: cuando los Bits de Actualización de Pantalla son iguales a ?01', los datos de píxel se escriben en la memoria temporal especificada por llenar_actual; cuando los Bits de Actualización de Pantalla son iguales a ?00' , los datos de píxel se escriben en la memoria temporal especificada por recién_llena; y cuando los Bits de Actualización de Pantalla son iguales a "11", los datos de píxel se escriben en todas las memorias temporales. La pantalla se refresca a partir de la memoria temporal especificada por el apuntador 'desplegándose' . Después de que la pantalla refresca el último pixel en una época de refresco de tramas y antes de que comience a refrescar el primer píxel en la siguiente época de refresco de tramas el proceso de actualización de pantalla realiza la operación de establecimiento de desplegándose igual a recién_llena; El Paquete de Flujo de Video contiene un par de Bits de Actualización de Pantalla que especifican la memoria temporal de tramas donde van a escribirse los datos de pixel. El Paquete de Capacidad de Cliente tiene tres bits adicionales que indican cuáles combinaciones de Bits de Actualización de Pantalla son soportadas en el cliente. En muchos casos, las imágenes generadas por computadora necesitan actualizarse progresivamente con base en la entrada de usuario o se derivan de la información recibida desde una red de computadoras. Las combinaciones de Bits de Actualización de Pantalla "00" y "11" soportan este modo de operación al escribir los datos de pixel en la memoria temporal de tramas que se visualiza o ambas memorias temporales de tramas. Cuando se alojan imágenes de video, la Figura 89 ilustra cómo se despliegan las imágenes de video utilizando un par de memoria temporales de trama cuando se transmiten ato de video por el enlace de MDDI con los Bits de Actualización de Pantalla iguales a "01". Después de que se detecta un limite de trama de medios en el enlace de MDDI, el proceso de refresco de pantalla comenzará el refresco desde la siguiente memoria temporal de tramas cuando se completa el proceso de refresco para la trama que actualmente está siendo refrescada. Una suposición importante relacionada con la Figura 89 es que la imagen se recibe desde el huésped como un flujo continuo de píxeles que se transmiten en el mismo orden que utiliza el cliente para leer los píxeles desde la memoria temporal de trama para refrescar la pantalla (normalmente la esquina superior izquierda, leyendo hilera por hilera, hacia la esquina inferior derecha de la pantalla) . Este es un detalle importante en casos donde las operaciones de Refrescar Pantalla y Transferir Imagen hacen referencia a la misma memoria temporal de trama. Es necesario que la tasa de trama de refresco de pantalla sea mayor que la tasa de trama de transferencia de imágenes a fin de evitar la visualización de imágenes parciales. La Figura 90 muestra cómo puede ocurrir la fragmentación de imágenes con una tasa de refresco de pantalla lenta que es el refresco de pantalla más lento que la transferencia de imágenes . En una imagen que contiene una combinación de imágenes gráficas de computadora e imágenes de video en movimiento los datos de pixel de video pueden ocupar una pequeña porción de una trama de medios. Esto podria ser significativo en situaciones donde la operación de refresco de pantalla y la transferencia de imágenes hacen referencia a la misma memoria temporal de trama. Estas situaciones se muestran por un sombreado de cuadrícula en la Figura 91, donde los píxeles leídos desde la memoria temporal para refrescar la pantalla pueden ser los píxeles escritos en la memoria temporal dos tramas antes, o pueden corresponder a la trama que se escribe inmediatamente en la misma memoria temporal de trama. El uso de tres memorias temporales en el cliente resolverá el problema de la pequeña ventana de contenido para el acceso a una memoria temporal de trama como se muestra en la Figura 92. Sin embargo, aún existe un problema si la tasa de refresco de pantalla es menor que la tasa de trama de medios por el enlace de MDDI como se muestra en la Figura 93. El uso de una sola memoria temporal para mover imágenes de video es un tanto problemático como se muestra en la Figura 94. Con el refresco de pantalla más rápido que la transferencia de imágenes hacia la memoria temporal, la imagen que se refresca algunas veces mostrará la porción superior de la trama que se escribe y la porción inferior de la imagen será la trama transferida con anterioridad. Con el refresco de pantalla más rápido que la transferencia de imágenes (el modo de operación preferido) habrá instancias más frecuentes de las tramas que muestran una imagen dividida similar.

XVll. Tabla de Valores de Retraso El Paquete de Parámetros de Retraso de Procesamiento de Paquetes utiliza una función de tabla de consulta para calcular el retraso pronosticado a fin de procesar algunos comandos en el cliente. Los valores en la tabla se incrementan de manera logarítmica para proporcionar un rango dinámico muy amplio de valores de retraso. Una tabla a manera de ejemplo de valores de retraso útiles para implementar las modalidades de la invención se encuentra en la Tabla XX mostrada a continuación, con valores Índice correspondientes contra valores de retraso.

Tabla XX El retraso se calcula al realizar una consulta de tabla utilizando el parámetro especificado como un índice en la tabla. Esto significa un retraso igual a Pac etProcessingTable (index) (TablaProcesamientoPaquete (Índice) ) . Por ejemplo: si uno de los parámetros provenientes del Elemento de Lista de Parámetros de Retraso es un valor de 8 bits igual a 134, entonces el retraso es igual a la TablaProcesamientoPaquetes (134) que es de 16 µseg. El valor 255 indica que el tiempo de término de comando no puede determinarse por cálculo, y que el huésped verificará las Banderas Ocupadas de Gráficas en el Paquete de Solicitud y Estado de Cliente o Parámetro de Control VCP MCCS B7h. En algunos casos este retraso se multiplica por la altura, ancho, o número de píxeles en la imagen destino se añade a otros retrasos para calcular el retraso de procesamiento de paquete general.

XVIII. Soporte de Cliente Múltiple La versión de protocolo actual no parece soportar directamente dispositivos de cliente múltiple. Sin embargo, la mayoría de los paquetes contienen un campo reservado de ID de Cliente que puede utilizarse para direccional dispositivos cliente específicos en un sistema con múltiples clientes. Actualmente, para muchas aplicaciones esta ID de cliente o estas IDs de cliente se establecen en cero. El paquete de cabecera de sub-trama también contiene un campo para indicar si el huésped soporta o no un sistema de cliente múltiple. Por lo tanto, existe una manera en la que se conectan y direccional múltiples dispositivos cliente en futuras aplicaciones de la MDDI o protocolo para ayudarle a los diseñadores de sistema a planear su futura compatibilidad con múltiples huésped cliente y clientes . En los sistemas que tienen múltiples clientes es útil que los clientes se conecten con el huésped utilizando una cadena de tipo margarita de clientes, o que utilizan concentradores, como se muestra en la Figura 95, o utilizando una combinación de estas técnicas como se muestra en la Figura 96.

XIX. Apéndice Además de los formatos, estructuras, y contenido descritos con anterioridad para los diversos paquetes utilizados para implementar la arquitectura y protocolo para las modalidades de la invención, se presentan aquí un contenido u operaciones de campo más detalladas para algunos de los tipos de paquete. Estos se presentan aquí para clarificar adicionalmente su uso u operaciones respectivas para permitirle a los expertos en la materia comprender más fácilmente y hacer uso de la invención para una variedad de aplicaciones. Solamente se describen aquí adicionalmente unos cuantos campos aún no descritos . Además, estos campos se presentan con definiciones y valores a manera de ejemplo con relación a las modalidades presentadas con anterioridad. Sin embargo, tales valores no deben interpretarse como limitantes para la invención, sino que representan una ' o más modalidades útiles para implementar la interfase y protocolo, y no se necesita llevar a la práctica todas las modalidades conjuntamente o al mismo tiempo. Pueden utilizarse otros valores en otras modalidades para alcanzar la presentación deseada de datos o de resultados de transferencia de tasa de datos, como comprenderán aquellos expertos en la materia.

A. Para Paquetes de Flujo de Video En un modalidad, el campo de Atributos de Datos de Píxel (2 bytes) tiene una serie de valores de bit que se interpretan como se explica a continuación. Los bits 1 y 0 seleccionan cómo se direccionan los datos de pixel de pantalla. Para valores de bits de ll' se despliegan los datos de pixel para ambos ojos, para valores de bit 10' , los datos de pixel se direccional solamente para el ojo izquierdo, y para valores de bit ?01', los datos de pixel se direccional solamente para el ojo derecho, y para valores de bit de ?00' los datos de píxel se direccional para una pantalla alterna como puede especificarse por los bits 8 a 11 descritos a continuación. Si la pantalla principal utilizada u operada por un cliente no soporta imágenes estéreo o reflejo de imágenes de alguna forma, entonces estos comandos no pueden implantarse eficientemente para tener un impacto como es deseado por la pantalla. En esta situación o configuración, el cliente debe direccional los datos de pixel a una pantalla principal independientemente de los valores de bit o para cualquiera de las combinaciones de bit ?01' , 10' , o ll' , dado que los comandos o control resultantes no serán implementados por la pantalla. Se recomienda, pero no es requerido por las modalidades, utilizar el valor ?ll' para direccional la pantalla principal en aquellos clientes que no soporten capacidad de visualización estéreo. El Bit 2 indica si se presentan o no los Datos de Pixel en formato entrelazado, refiriéndose un valor de ?0' a que los datos de píxel se encuentran en formato progresivo convencional, y que el número de hilera (coordenada Y de píxel) se incrementa en 1 cuando avanza de una hilera a la siguiente. Cuando este bit tiene un valor de ?l', los datos de píxel se encuentran en formato entrelazado, y el número de hilera se incrementa en 2 cuando se avanza de una hilera a- la siguiente. El Bit 3 indica que los Datos de Pixel se encuentran en un formato de píxel alterno. Este es similar al modo entrelazado convencional habilitado por el Bit 2, pero el entrelazado es vertical en lugar de horizontal. Cuando el Bit 3 es 0' , los Datos de Píxel se encuentran en formato progresivo convencional, y el número de columna (coordenada X de píxel) se incrementa en 1 a medida que se recibe cada píxel sucesivo. Cuando el Bit 3 es ?l' , los Datos de Píxel se encuentran en formato de píxel alterno, y el número de columna se incrementa en 2 a medida que se recibe cada píxel sucesivo. El Bit 4 indica si los datos de Píxel se encuentran relacionados o no con una pantalla o una cámara, asi como adonde o de dónde son transferidos los datos una pantalla interna para una teléfono inalámbrico o un dispositivo similar o incluso una computadora portátil, o algunos otros dispositivos descritos con - anterioridad, o los datos son transferidos a o desde una cámara incorporada en o acoplada directamente al dispositivo. Cuando el Bit 4 es ?0' , los datos de Píxel se transfieren a o desde una memoria temporal de trama de visualización. Cuando el Bit 4 es l' , los datos de Pixel se transfieren a o desde una cámara o dispositivo de video de algún tipo, tales dispositivos son conocidos en la materia. El Bit 5 se utiliza para indicar cuándo los datos de píxel contienen la siguiente hilera de pixeles en la pantalla. Se considera que este es el caso cuando el Bit 5 se establece igual a l' . Cuando el bit 5 se establece en ?l' entonces no se definen los parámetros de Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, Inicio X, e Inicio Y y son ignorados por el cliente. Cuando el Bit 15 se establece en un nivel de uno lógico, esto indica que los datos de píxel en este paquete son la última hilera de píxeles en la imagen. El bit 8 del campo de Indicadores de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente indica si se soporta esta característica. Los Bits 7 y 6 son los Bits de Actualización de Pantalla que especifica una memoria temporal de trama a donde van a escribirse los datos de píxel. Los efectos más específicos se describen en otra parte. Para valores de bit de '01' los datos de Pixel se escriben en la memoria temporal de imagen desconectada. Para valores de bit de '00' los datos de Pixel se escriben en la memoria temporal de imagen utilizada para refrescar la pantalla. Para valores de bit de '11' los datos de Píxel se escriben en todas las memorias temporales de imagen. Los valores de bit o la combinación de '10' se tratan como un valor o designación inválido (a) y se ignoran los datos de Píxel y no se escriben en ninguna de las memorias temporales de imagen. Este valor puede tener uso para futuras aplicaciones de la interfase. Los Bits 8 a 11 forman un entero sin signo de 4 bits que especifica una pantalla o ubicación de visualización alterna a donde se direccional los datos de pixel. Los Bits 0 y 1 se establecen iguales a ^ 00' con objeto de de que el cliente de pantalla interprete los bits 8 a 11 como un número de pantalla alterna. Si los bits 0 y 1 no son iguales a '00' entonces los bits 8 a 11 se establecen en niveles de cero lógico. Los Bits 12 a 14 se encuentran reservados para su uso posterior y generalmente se establecen en niveles de cero lógico. El Bit 15, como se describe, se utiliza en conjunto con el bit 5, y establecer el bit 15 en uno lógico indica que la hilera de pixeles en el campo de Datos de Pixel es la última hilera de píxeles en una trama de datos. El siguiente Paquete de Flujo de Video que tiene el bit 5 establecido en uno lógico corresponderá a la primera hilera de pixeles de la siguiente trama de video. Los campos de Inicio X e Inicio Y de 2 bytes especifican las coordenadas absolutas de X y Y del punto (Inicio X, Inicio Y) para el primer píxel en el campo de Datos de Píxel. Los campos de 2 bytes de Borde Izquierdo X y de Borde Superior Y especifican la coordenada X del borde izquierdo y la coordenada Y del borde superior de la ventana de pantalla llena por el campo de Datos de Pixel, mientras que los campos de Borde Derecho X y Borde Inferior Y especifican la coordenada X del borde derecho, y la coordenada Y del borde inferior de la ventana se actualiza. El campo de Cuenta de Píxel (2 bytes) especifica el número de pixeles en el campo de Datos de Píxel a continuación.

El campo de CRC de Parámetro (2 bytes) contiene una CRC de todos los bytes desde el Largo de Paquete a la Cuenta de Pixel. Si falla la verificación de esta CRC entonces se descarta todo el paquete. El campo de Datos de Píxel contiene la información de video sin procesar que va a desplegarse, y que se formatea de la manera descrita por el campo de Descriptor de Formato de Datos de Video. Los datos se transmiten una "hilera" a la vez como se describió en ora parte. Cuando el Bit 5 del campo de Atributos de Dato de Píxel se establece en un nivel de uno lógico, entonces el campo de Datos de Pixel contiene exactamente una hilera de píxeles, transmitiéndose el primer píxel que corresponde al píxel ubicado en la extrema izquierda y transmitiéndose el último píxel correspondiente al píxel ubicado en la extrema derecha. El campo de CRC de Datos de Píxel (2 bytes) contiene una CRC de 16 bits solamente de los Datos de Píxel. Si falla una verificación de CRC de este valor entonces aún pueden utilizarse los Datos de Píxel, pero se incrementa la cuenta de error de CRC.

B. Para Paquetes de Flujo de Audio En una modalidad, el campo de ID de Canal de Audio (1 byte) utiliza un valor entero sin signo de 8 bits para identificar un canal de audio en particular al cual son enviados los datos de audio por el dispositivo cliente. Los canales de audio físicos se especifican en o se mapean en canales físicos por este campo como valores de 0, 1, 2, 3, 4, 5, 6, o 7 los cuales indican los canales frontal izquierdo, frontal derecho, posterior izquierdo, posterior derecho, central frontal, subaltavoz para bajas frecuencias, izquierdo envolvente, y derecho envolvente, respectivamente. Un valor de ID de canal de audio de 254 indica que el único flujo de muestras de audio digital se envia tanto a los canales frontal izquierdo como a frontal derecho . Esto simplifica las comunicaciones para aplicaciones tales como cuando se utilizan audífonos de estéreo para la comunicación de voz, se utilizan aplicaciones para incrementar la productividad en un PDA, u otras aplicaciones donde una simple Inferíase de Usuario genera tonos de advertencia. Los valores para el campo de ID que oscilan de 8 a 253, y 255 se encuentran reservados actualmente para su uso donde nuevos diseños desean dibujos adicionales, como anticipan los expertos en la materia. El campo Reservado 1 (1 byte) generalmente se encuentra reservado para su uso posterior, y tiene todos los bits en este campo establecidos en cero. Una función de este campo es hacer que todos los campos subsecuentes de 2 bytes se alinean a una dirección de palabra de 16 bits y hacer que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits. El campo de Cuenta de Muestras de Audio (2 bytes) especifica el número de muestras de audio en este paquete. El campo de Bits Por Muestra y Empaquetado contiene 1 byte que especifica el formato de empaquetamiento de los datos de audio. En una modalidad, el formato generalmente empleado es para que los Bits 4 a 0 definan el número de bits por muestra de audio de PCM. El Bit 5 especifica después si se empaquetan o no las muestras de Datos de Audio Digital. Como se mencionó con anterioridad, la Figura 12 ilustra la diferencia entre las muestras de audio empaquetadas y las alineadas por byte. Un valor de '0' para el Bit 5 indica que cada muestra de audio de PCM en el campo de Datos de Audio Digital se encuentra alineada por byte con el límite de byte de interfase, y un valor de '1' indica que cada muestra de audio de PCM sucesiva se empaqueta contra la muestra de audio anterior. Este bit es efectivo solamente cuando el valor definido en los bits 4 a 0 (el número de bits por muestra de audio de PCM) no es un múltiplo de ocho. Los Bits 7 a 6 se encuentran reservados para su uso donde los diseños de sistema desean designaciones adicionales y generalmente se establecen en un valor de cero. El campo de Tasa de muestreo de Audio (1 byte) especifica la tasa de muestreo de PCM de audio. El formato empleado es para un valor de 0 a fin de indicar una tasa de 8,000 muestras por segundo (sps -samples per second) , un valor de 1 indica 16,000 sps., el valor de 2 para 24,000 sps, el valor de 3 para 32,000 sps, el valor de 4 para 40,000 sps, el valor de 5 para 48,000 sps, el valor de 6 para 11,025 sps, el valor de 7 para 22,050 sps, y el valor de 8 para 44,100 sps, respectivamente, reservándose los valores de 9 a 255 para su uso posterior, dado que se establecen actualmente en cero. El campo de CRC de Parámetro (2 bytes) contiene una CRC de 16 bits de todos los bytes desde el Largo de Paquete a la Tasa de muestreo de Audio. Si falla la verificación de esta CRC apropiadamente, entonces se descarta todo el paquete. El campo de Datos de Audio Digital contiene las muestras de audio sin procesar por reproducirse, y normalmente se encuentra en forma de formato lineal como enteros sin signos. El campo de CRC de Datos de Audio (2 bytes) contiene una CRC de 16 bits de solamente los Datos de Audio. Si falla la verificación de esta CRC, entonces aún pueden utilizarse los Datos de Audio, pero se incrementa la cuenta de errores de CRC.

C. Para Paquetes de Flujo Definidos por el Usuario En una modalidad, el campo de Número de ID de Flujo de 2 bytes se utiliza para identificar un flujo definido por un usuario en particular. El contenido de los campos de Parámetros de Flujo y Datos de Flujo se define típicamente por la fabricante de equipo de MDDI. El campo de CRC de Parámetro de Flujo de 2 bytes contiene una CRC de 16 bits de todos los bytes de los parámetros de flujo comenzando desde el Largo de Paquete hasta el byte de Codificación de Audio. Si falla la verificación de esta CRC, entonces se descarta todo el paquete. Ambos campos de Parámetros de Flujo y de CRC de Parámetro de Flujo pueden descartarse si no son necesarios por una aplicación terminal de la MDDI, es decir, se consideran opcionales. El campo de CRC de Datos de Flujo de 2 bytes contiene una CRC solamente de los Datos de Flujos. Si falla la verificación de la CRC apropiadamente, entonces el uso de los Datos de Flujo son opcionales, dependiendo de los requisitos de la aplicación. El uso de los datos de flujo contingentes en la CRC buena, generalmente requiere que los datos de flujo se coloquen en memoria temporal hasta que se confirma que la CRC es buena. La cuenta de errores de CRC se incrementa si no se verifica esta CRC.

D. Paquetes de Mapa de Colores El campo de ID de hCliente de 2 bytes contiene información o valores que se reservan para una ID de Cliente, como se utilizó con anterioridad. Dado que este campo generalmente se encuentra reservado para su uso posterior, el valor actual se establece en cero, estableciendo los bits en '0' . El campo de Cuenta de Elementos de Mapa de Colores de 2 bytes utiliza valores para especificar el número total de los elementos de mapa de colores de 3 bytes que se encuentran contenidos en el campo de Datos de Mapa de Colores, o las entradas de tabla de mapa de colores que existen en los Datos de Mapa de Colores en este paquete. En esta modalidad, el número de bytes en los Datos de Mapa de Colores es 3 veces la Cuenta de Elementos de Mapa de Colores. La Cuenta de Elementos de Mapa de Colores se establece igual a cero para no enviar ningún dato de mapa de colores. Si el Tamaño de Mapa de Colores es cero, entonces un valor de Variación de Mapa de Colores generalmente se envia pero es ignorado por la pantalla. El campo de Variación de Mapa de Colores (4 bytes) especifica la variación de los Datos de Mapa de Colores en este paquete desde el inicio de la tabla de mapa de colores en el dispositivo cliente. Un campo de CRC de Parámetro de 2 bytes contiene una CRC de todos los bytes desde el Largo de Paquete hasta el byte de Codificación de Audio. Si falla la verificación de esta CRC entonces se descarta todo el paquete. Para el campo de Datos de Mapa de Colores, el ancho de cada ubicación de mapa de colores se especifica por el campo de Tamaño de Elementos de Mapa de Colores, donde en una modalidad la primera parte especifica la magnitud de azul, la segunda parte especifica la magnitud de verde, y la tercera parte especifica la magnitud de rojo. El campo de Tamaño de Elementos de Mapa de Colores especifica el número de elementos de tabla de mapa de colores de 3 bytes que existen en el campo de Datos de Mapa de Colores. Si un solo mapa de colores no puede caber en un Formato de datos de Video y Paquete de Mapa de Colores, entonces puede especificarse todo el mapa de colores enviando múltiples paquetes con diferentes Datos de Mapa de Colores y Variaciones de Mapa de Colores en cada paquete. El número de bits de azul, verde, y rojo en cada elemento de datos de mapa de colores generalmente es el mismo que el especificado en el campo de Ancho de RGB de Mapa de Colores del Paquete de Capacidad de Pantalla. Un campo de CRC de Datos de Mapa de Colores de 2 bytes contiene una CRC solamente de los Datos de Mapa de Colores. Si falla la verificación de esta CRC, entonces aún pueden utilizarse los Datos de Mapa de Colores pero se incrementa la cuenta de errores de CRC. Cada elemento de datos de mapa de colores va a transmitirse en el siguiente orden: azul, verde, rojo, con el bit menos significativo de cada componente transmitido primeramente. Los componentes individuales rojo, verde, y azul de cada elemento de mapa de colores se empaquetan, pero cada elemento de mapa de colores (el bit menos significativo del componente azul) debe estar alineado por byte. La Figura 97 ilustra un ejemplo de los elementos de datos de mapa de colores con 6 bits de azul, 8 bits de verde, y 7 bits de rojo. Para este ejemplo, el Tamaño de Elemento de Mapa de Colores en el Paquete de Mapa de Colores es igual a 21, y el campo de Ancho de RGB de Mapa de Colores del Paquete de Capacidad de Cliente es igual a 0x0786.

E. Para Paquetes de Encapsulación de Enlace Inverso El campo de CRC de Parámetro (2 bytes) contiene una CRC de 16 bits de todos los bytes desde el Largo de Paquete al Largo de Cambiar. Si falla la verificación de esta CRC, entonces se descarta todo el paquete . En una modalidad, el campo de Banderas de Enlace Inverso (1 byte) contiene un conjunto de banderas para solicitar la información proveniente del cliente. Si un bit (por ejemplo, el Bit 0) se establece en un nivel de uno lógico, entonces el huésped solicita la información especificada desde la pantalla utilizando el Paquete de Capacidad de Cliente. Si el bit se establece en un nivel de cero lógico, entonces el huésped no necesita información proveniente del cliente. Los bits restantes (aquí los Bits 1 a 7) se encuentran reservados para su uso posterior y se establecen en cero. Sin embargo, pueden utilizarse más bits según se desee para establecer banderas para el enlace inverso. El campo de Divisor de Tasa Inversa (1 byte) especifica el número de ciclos de MDDI Stb que ocurren en relación con el reloj de datos de enlace inverso. El reloj de datos de enlace inverso es igual al reloj de datos de enlace en avance dividido por dos veces el Divisor de Tasa Inversa. La tasa de datos de enlace inverso se relaciona con el reloj de datos de enlace inverso y el Tipo de Inferíase en el enlace inverso. En esta modalidad, para una interfase de Tipo 1 la tasa de datos inversa es igual al reloj de datos de enlace inverso, para las interfases de Tipo 2, Tipo 3, y Tipo 4 las tasas de datos inversas son iguales a dos veces, cuatro veces, y ocho veces el reloj de datos de enlace inverso, respectivamente. El campo de Sólo Ceros 1 contiene un grupo de bytes, aqui 8, que se establece igual a cero en valor estableciendo los bits en un nivel de cero lógico, y se utiliza para asegurar que todas las señales de MDDI_Datos se encuentran en un nivel de cero lógico durante un tiempo suficiente para permitirle al cliente comenzar a recuperar el reloj que utiliza solamente MDDI_Stb antes de deshabilitar a los manejadores de linea del huésped durante el campo de Cambiar 1. En una modalidad, el largo del campo de Sólo Ceros 1 es mayor que o igual al número de tiempos de transmisión de byte de enlace en avance en el retraso de viaje redondo del cable.

El campo de Largo de Cambiar 1 (1 byte) especifica el número total de bytes que se asignan para Cambiar 1, estableciendo el primer periodo de cambio. El campo de Cambiar 1 emplea el número de bytes especificado por el parámetro de Largo de Cambiar 1 que son asignados para permitirle la habilitación de los manejadores de línea de MDDI_Datos en el cliente, antes de que se deshabiliten los manejadores de linea en el huésped. El cliente habilita a sus manejadores de línea de MDDI_Datos durante el bit 0 de Cambiar 1 y el huésped deshabilita sus salidas a fin de deshabilitarse completamente antes del último bit de Cambiar 1. La señal de MDDI_Stb se comporta como si MDDI_Datos0 estuviese en un nivel de cero lógico durante todo el periodo de Cambiar 1. Una descripción más completa del establecimiento de Cambiar 1 se dio con anterioridad. El campo de Paquetes de Datos Inverso contiene una serie de paquetes de datos transferidos desde el cliente hacia el huésped. El cliente puede enviar paquetes de relleno o manejar las líneas de MDDI_Datos a un estado o nivel de cero lógico cuando no tiene ningún dato que enviarle al huésped. En esta modalidad, si las líneas de MDDI_Datos se llevan a cero, el huésped interpretará esto como un paquete con un largo de cero (sin un largo de válido) y el huésped no aceptará ningún paquete adicional proveniente del cliente para la duración del Paquete de Encapsulación de Enlace Inverso. El campo de Largo de Cambiar 2 (1 byte) especifica el número total de bytes que se asignan para Cambar 2, para establecer un segundo periodo de cambio. El largo recomendado de Cambiar 2 es el número de bytes requerido para el' retraso de viaje redondo más el tiempo requerido para que el huésped habilite sus manejadores de MDDI_Datos . El Largo de Cambiar 2 también puede ser un valor más grande que el valor mínimo requerido o calculado a fin de permitir tiempo suficiente para procesar los paquetes de enlace inverso en el huésped. El campo de Cambiar 2 consiste en el número de bytes según se especifica por el parámetro de Largo de Cambiar. El huésped espera durante al menos el tiempo de retraso de viaje redondo antes de habilitar sus manejadores de linea de MDDI_Datos durante Cambiar 2. El huésped habilita sus manejadores de línea de MDDI_Datos de manera que generalmente se encuentren completamente habilitados antes del último bit de Cambiar 2, y el cliente deshabilita sus salidas de manera que generalmente se encuentren completamente deshabilitadas antes del último bit de Cambiar 2. El propósito del campo de Cambiar 2 es permitirle a la cantidad restante de datos provenientes del campo de Paquetes de Datos Inversos transmitirse o transferirse desde el cliente. Son posibles las variaciones en diferentes sistemas que implementan la interfase y la cantidad de margen de seguridad asignado, haciendo posible que ni el huésped ni el cliente lleven las señales de MDDI_Datos a un nivel de cero lógico durante algunas partes del periodo de campo de Cambiar 2, como se observa por los receptores de linea en el huésped. La señal de MDDI_Stb se comporta como si los MDDI_Datos estuviesen en un nivel de cero lógico durante substancialmente todo el periodo de Cambiar 2. Anteriormente se ha brindado una descripción de la configuración de Cambiar 2. El campo de Paquetes de Datos Inversos contiene una serie de paquetes de datos que se transfieren del cliente al huésped. Como se declaró con anterioridad, los paquetes de Relleno se envían para llenar el espacio restante que no es utilizado por otros tipos de paquete. El campo de Sólo Ceros 2 contiene un grupo de bytes (8 en esta modalidad) que se establece igual a cero en valor al establecer los bits en un nivel de cero lógico, y se utiliza para asegurar que todas las señales de MDDI_Datos se encuentran en un nivel de cero lógico durante un tiempo suficiente para permitirle al cliente comenzar a recuperar el reloj utilizando tanto MDDI_Datos como MDDI_Stb después de habilitar los manejadores de línea del huésped después del campo de Cambiar 2.

F. Para Paquetes de Capacidad de Cliente Como se ilustra para una modalidad, el campo de Versión de Protocolo utiliza 2 bytes para especificar una versión de protocolo utilizada por el cliente. La versión inicial se encuentra establecida actualmente igual a uno, y se cambiará con el transcurso del tiempo dado que se generan nuevas versiones como se sabrá, mientras que el campo de Versión de Protocolo Mínimo utiliza 2 bytes para especificar la versión de protocolo mínimo que el cliente puede emplear o interpretar. En este caso, un valor de cero también es un valor válido. El campo de Capacidad de Tasa de Datos (2 bytes) especifica la máxima tasa de datos que puede recibir el cliente en cada par en el enlace en avance de la interfase, y se especifica en forma de megabits por segundo (Mbps) . El campo de Capacidad de Tipo de Inferíase (1 byte) especifica los tipos de interfase soportados por los enlaces en avance e inverso. Un bit establecido en '1' indica que se soporta un tipo de interfase especificada, y un bit establecido en '0' indica que no se soporta el tipo especificado. Los huéspedes y clientes deben soportar al menos el Tipo 1 en las líneas en avance e inversa. Esto no es requisito para soportar un rango contiguo de tipos de interfase. Por ejemplo, seria perfectamente válido soportar solamente el Tipo 1 y el Tipo 3, pero no el Tipo 3 y el Tipo 4 en una interfase. Tampoco es necesario que los enlaces en avance e inverso operen con el mismo tipo de interfase. Sin embargo, cuando un enlace sale de hibernación ambo enlaces en avance e inverso deben comenzar a operar en el modo de Tipo 1, hasta que puedan negociarse otros modos, seleccionarse, o de otra manera ser aprobados para su uso tanto por el huésped como por el cliente. Las interfases soportadas se indican en una modalidad al seleccionar el Bit 0, el Bit 1, o el Bit 2 para seleccionar entre un modo de Tipo 2 (2 bits), Tipo 3 (4 bits), o Tipo 4 (8 bits) en el enlace en avance, respectivamente; y el Bit 3, el Bit 4, o el Bit 5 para seleccionar un modo de Tipo 2, Tipo 3, o Tipo 4 por el enlace inverso, respectivamente; reservándose los Bits 6 y 7 y estableciéndose generalmente en cero en este momento. Los campos de 7?ncho y Altura de Mapa de Bits, siendo aquí cada uno de ellos 2 bytes, especifican el ancho y altura del mapa de bits, respectivamente, en pixeles . El campo de Capacidad Monocromática (1 byte) se utiliza para especificar el número de bits de resolución que pueden visualizarse en un formato monocromático. Si una pantalla no puede utilizar un formato monocromático entonces este valor se establece en cero. Los bits 7 a 4 se encuentran reservados para su uso posterior, y consecuentemente este valor se establece en cero. Los bits 3 a 0 definen el número máximo de bits de escala de grises que puede existir para cada píxel . Estos cuatro bits hacen posible especificar valores de 1 a 15 para cada pixel. Si el valor es cero entonces el formato monocromático no es soportado por la pantalla. El campo de Capacidad de Bayer utiliza 1 byte para especificar el número de bits de resolución, grupo de píxeles, y orden de píxeles que puede transferirse en formato de Bayer. Si el cliente no puede utilizar el formato de Bayer entonces este valor es cero. El campo de Capacidad de Bayer se encuentra compuesto de los siguientes valores: los Bits 3 a 0 definen el número máximo de bits de intensidad que existen en cada píxel, mientras que los Bits 5 a 4 definen el patrón de grupo de píxel requerido, mientras que los Bits 8 a 6 definen el orden de píxeles requerido; reservándose los Bits 14 a 9 para su uso posterior y generalmente se establecen en cero entretanto. El Bit 15, cuando se encuentra establecido en un nivel de uno lógico indica que el cliente puede aceptar los datos de pixel de Bayer sea en formato empaquetado o no empaquetado. Si el bit 15 se establece en cero esto indica que el cliente puede aceptar los datos de píxel de Bayer solamente en formato no empaquetado. El campo de Capacidad de Mapa de Colores (3 bytes) especifica el número máximo de elementos de tabla que existen en la tabla de mapa de colores en la pantalla. Si la pantalla no puede utilizar el formatote mapa de colores entonces este valor se estable en cero. El campo de Capacidad de RGB (2 bytes) especifica el número de bits de resolución que pueden visualizarse en formatote RGB. Sí la pantalla no pude utilizar el formato de RGB entonces este valor es igual a cero. La palabra de Capacidad de RGB se encuentra compuesta de tres valores separados sin signo donde: los Bits 3 a 0 definen el número máximo de bits de azul, los Bits 7 a 4 definen el número máximo de bits de verde, y los Bits 11 a 8 definen el número máximo de bits de rojo en cada píxel. Actualmente, los Bits 14 a 12 se encuentran reservados para su uso posterior y generalmente se establecen en cero. Los Bits 14 a 12 se encuentran reservados para su uso posterior y generalmente se establecen en cero. El Bit 15, cuando se establece en un nivel de uno lógico indica que el cliente puede aceptar datos de pixel de RGB sea en formato empaquetado o no empaquetado. Si el bit 15 se establece en un nivel de cero lógico, esto indica que el cliente puede aceptar los datos de pixel de RGB solamente en formato no empaquetado. El campo de Capacidad de Y Cr Cb (2 bytes) especifica el número de bits de resolución que pueden visualizarse en formato Y Cr Cb . Si la pantalla no puede utilizar el formato Y Cr ' Cb entonces este valor se establece igual a cero. La palabra de Capacidad de Y Cr Cb se encuentra compuesta de tres valores sin signo separados donde: los Bits 3 a 0 definen el número máximo de bits en la muestra de Cb, los Bits 7 a 4 definen el número máximo de bits en la muestra de Cr, los Bits 11 a 8 definen el número máximo de bits en la muestra de Y, y los Bits 15 a 12 se encuentran actualmente reservados para su uso posterior y se establecen en cero. El campo de Capacidad de Características de Cliente utiliza 4 bytes que contienen un conjunto de banderas que indican características específicas soportadas en el cliente. Un bit establecido en un nivel de uno lógico indica que se soporta la capacidad, mientras que un bit establecido en un nivel de cero lógico indica que no se soporta la capacidad. En una modalidad, el valor para el Bit 0 indica si se soporta o no el Paquete de Transferencia de Bloque de Mapa de Bits (paquete de tipo 71) . El valor para los Bits 1, 2, y 3 indica si se soportan o no el Paquete Rellenar Área de Mapa de Bits (paquete de tipo 72) , Paquete Rellenar Patrón de Mapa de Bits (paquete de tipo 73) , o el Paquete de Canal de Datos de Enlace de Comunicaciones (paquete de tipo 74), respectivamente. El valor para el Bit 4 indica si el cliente tiene o no la capacidad de volver transparente un color utilizando el Paquete de Habilitación de Color Transparente, mientras los valores para los Bits 5 y 6 indican si el cliente puede aceptar datos de video o datos de audio en formato empaquetado, respectivamente, y el valor para el Bit 7 indica si el cliente puede o no enviar un flujo de video de enlace inverso desde una cámara. El valor para el Bit 8 indica si el cliente tiene o no la capacidad de recibir una linea completa de datos de píxel e ignorar el direccionamiento de visualización según se especifica por el bit 5 del campo de Atributos de Datos de Pixel del Paquete de Flujo de Video, y el cliente puede detectar también la sincronía de trama o el fin de los datos de trama de video utilizando el bit 15 del Campo de Atributos de Datos de Píxel. El valor para los Bits 11 y 12 indican cuándo el cliente se está comunicando con un dispositivo de señalización y puede enviar y recibir Paquetes de Datos de Dispositivo de Señalización, o con un teclado y puede enviar y recibir Paquetes de Datos de Teclado, respectivamente. El valor para el Bit 13 indica si el cliente tiene o no la capacidad de establecer uno o más parámetros de audio o de video al soportar los paquetes de Características de VCP: Paquete Solicitar Características de VCP, Paquete de Respuestas de Características de VCP, Paquete Establecer Características de VCP, Paquete Solicitar Parámetros Válidos y Paquete de Respuesta de Parámetros Válidos. El valor para el Bit 14 indica si el cliente tiene o no la capacidad de escribir datos de píxel en la memoria temporal de trama de visualización desconectada. Si este bit se establece en un nivel de uno lógico, entonces los Bits de Actualización de Pantalla (bits 7 y 6 del campo de Atributos de Datos de Píxel del Paquete de Flujo de Video) pueden establecerse en los valores '01' . El valor para el Bit 15 indica cuándo el cliente tiene la capacidad de escribir datos de pixel solamente en la memoria temporal de trama de visualización actualmente en uso para refrescar la imagen de pantalla. Si este bit se establece en uno, entonces los Bits de Actualización de Pantalla (bits 7 y 6 del campo de Atributos de Datos de Pixel del Paquete de Flujo de Video) pueden establecerse a los valores '00' . El valor para el Bit 16 indica cuándo el cliente tiene la capacidad de escribir datos de pixel provenientes de un solo Paquete de Flujo de Video en todas las memorias temporales de trama de visualización. Si este bit se establece en uno entonces los Bits de Actualización de Pantalla (bits 7 y 6 del campo de Atributos de Datos de Píxel del Paquete de Flujo de Video) pueden establecerse al valor '11' . El valor para el Bit 17 indica cuándo un cliente tiene la capacidad de responder al Paquete de Solicitud de Estado Especifico, el valor para el Bit 18 indica cuándo el cliente tiene la capacidad de responder al Paquete de Medición de Retraso de Viaje Redondo, y el valor para el Bit 19 indica cuándo el cliente tiene la capacidad de responderle al Paquete de Calibración de Distorsión de Enlace en Avance. El valor para el Bit 21 indica cuándo el cliente tiene la capacidad de interpretar al Paquete de Solicitud de Estado Específico y de responder con el Paquete de Lista de Respuesta de Estado Válido. El cliente indica una capacidad de regresar al estado adicional en el campo de Lista de Respuesta de Parámetros Válidos del Paquete de Lista de Respuesta de estado Válido como se describe en cualquier otra parte. El valor para el Bit 22 indica cuándo el cliente tiene o no la capacidad de responderle al Paquete de Acceso de registro. Los Bits 9 a 10, 20, y 23 a 31 se encuentran reservados actualmente para su uso posterior o para designaciones alternas útiles para los diseñadores del sistema y generalmente se establecen en cero. El campo de Capacidad de Tasa de Trama de Video de Visualización (1 byte) especifica la capacidad máxima de actualización de trama de video de la visualización en tramas por segundo. Un huésped puede elegir actualizar la imagen a una tasa más lenta que el valor especificado en este campo. El campo de Profundidad de Memoria Temporal de Audio (2 bytes) especifica la profundidad de la memoria temporal elástica en una pantalla que se le dedica a cada flujo de audio. El campo de Capacidad de Canal de Audio (2 bytes) contiene un grupo de banderas que indican cuáles canales de audio son soportadas por el cliente o el dispositivo conectado al cliente. Un bit establecido en uno indica que el canal es soportado, y un bit establecido en cero indica que no se soporta el canal. Las posiciones de Bit se asignan a diferentes canales, por ejemplo, las posiciones de Bit 0, 1, 2, 3, 4, 5, 6, y 7 en una modalidad, indican los canales frontal izquierdo, frontal derecho, posterior izquierdo, posterior derecho, central frontal, subaltavoz para bajas frecuencias, izquierdo envolvente, y derecho envolvente, respectivamente. Los Bits 8 a 14 se encuentran reservados actualmente para su uso posterior, y generalmente se establecen en cero. En una modalidad, el Bit 15 se utiliza para indicar si el cliente proporciona soporte para el Paquete de Habilitación de Canal de Audio en Avance. Si es este el caso, el Bit 15 se establece en un nivel de uno lógico. Sin embargo, si el cliente no es capaz de deshabilitar los canales de audio como resultado del Paquete de Habilitación de Canal de Audio en Avance o si el cliente no soporta ninguna capacidad de audio, entonces este bit se establece a un nivel o valor de cero lógico. Un campo de Capacidad de Tasa de muestreo de Audio de 2 bytes, para el enlace en avance, contiene un conjunto de banderas para indicar la capacidad de tasa de muestreo de audio del dispositivo cliente. Las posiciones de bit se asignan a diferentes tasas consecuentemente, tales como los Bits 0, 1, 2, 3, 4, 5, 6, 7, y 8 que son asignados a 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, y 44,100 muestras por segundo (SPS), respectivamente, reservándose los Bits 9 a 15 para usos de tasa posteriores o alternos, como se desee, de manera que actualmente se establecen en O'~ Establecer un valor de bit para uno de estos bits en '1' indica que se soporta esa tasa de muestreo particular, y establecer el bit en '0' indica que no se soporta esa tasa de muestreo . El campo de Tasa de Sub-trama Minima (2 bytes) especifica la tasa de sub-trama minima en tramas por segundo. La tasa de sub-trama minima mantiene la tasa de actualización de estado de cliente suficiente para leer algunos sensores o dispositivos de señalización en el cliente. Un campo de Capacidad de Tasa de muestreo de Micrófono de 2 bytes, para el enlace inverso, contiene un conjunto de banderas que indican la capacidad de tasa de muestreo de audio de un micrófono en el dispositivo cliente. Para propósitos de la MDDI, se configura un micrófono de dispositivo cliente para soportar mínimamente una tasa de al menos 8,000 muestras por segundo. A las posiciones de bit para este campo se les asignan diferentes tasas con posiciones de bit 0, 1, 2, 3, 4, 5, 6, 7, y 8, por ejemplo, se utilizan para representar 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, y 44,100 muestras por segundo (SPS), respectivamente, reservándose los Bits 9 a 15 para usos posteriores o alternos, según se desea, de manera que se encuentran actualmente establecidos en '0' . Establecer un valor de bit para uno de estos bits en '1' indica que se soporta esa tasa de muestreo en particular, y establecer el bit en '0' indica que no se soporta esa tasa de muestreo. Si no se encuentra conectado ningún micrófono, entonces cada uno de los bits de Capacidad de Tasa de muestreo de Micrófono se establecen iguales a cero . El campo de Formato de Datos de Teclado (aquí de 1 byte) especifica si se encuentra conectado o no un teclado con el sistema de cliente y el tipo de teclado que se encuentra conectado . En una modalidad, el valor establecido por los Bits 6 a 0 se utiliza para definir el tipo de teclado que se encuentra conectado. Si el valor es cero (0) entonces el tipo de teclado se considera como desconocido. Para un valor de 1, se considera que el formato de datos de teclado es un estilo PS-2 convencional. Actualmente los valores en el rango de 2 a 125 no se encuentran en uso, reservándose para el uso de diseñadores de sistema y de incorporadores de interfase o desarrolladores de producto para definir dispositivos específicos de teclado o de entrada para su uso con la MDDI y los clientes o huéspedes correspondientes. Se utiliza un valor de 126 para indicar que el formato de datos de teclado es definido por el usuario, mientras se utiliza un valor de 127 para indicar que no puede conectarse un teclado con este cliente. Además, el Bit 7 puede utilizarse para indicar si el teclado puede comunicarse o no con el cliente. El uso destinado de este bit es indicar cuando puede comunicarse con el cliente utilizando un enlace inalámbrico. El Bit 7 se establecería en un nivel de cero si los bits 6 a 0 indican que no puede conectarse un teclado al cliente. Por lo tanto, para una modalidad, cuando el valor de Bit 7 es 0, el teclado y el cliente no pueden comunicarse, aunque sí el valor de . Bit 7 es 1, el teclado y el cliente han reconocido que pueden comunicarse uno con otro. El campo de Formato de Datos de Dispositivo de Señalización (aquí 1 byte) especifica si un dispositivo de señalización se encuentra o no conectado con el sistema de cliente y el tipo de dispositivo de señalización que se encuentra conectado. En una modalidad, el valor establecido por los Bits 6 a 0 se utiliza para definir el tipo de dispositivo de señalización que se encuentra conectado. Si el valor es cero (0) entonces el tipo de dispositivo de señalización se considera como desconocido. Para un valor de 1, se considera que el formato de datos de dispositivo de señalización es de estilo PS-2 convencional. Actualmente los valores en el rango de 2 a 125 no se encuentran en uso, reservándose para el uso de los diseñadores de sistema e incorporadores de inferíase o desarrolladores de producto para definir dispositivos específicos de dispositivo de señalización o de entrada para su uso con la MDDI y los clientes o huéspedes correspondientes. Se utiliza un valor de 126 para indicar que el formato de datos de dispositivo de señalización es definido por el usuario, mientras se utiliza un valor de 127 para indicar que no puede conectarse un dispositivo de señalización con este cliente. Además, el Bit 7 puede utilizarse para indicar si el dispositivo de señalización puede comunicarse o no con el cliente. El uso destinado de este bit es indicar cuándo puede el teclado comunicarse con el cliente utilizando un enlace inalámbrico. El Bit 7 se establecería en un nivel de cero si los bits 6 a 0 indican que no puede conectarse un dispositivo de señalización con el cliente. Por lo tanto, para una modalidad, cuando el valor de Bit 7 es 0, el dispositivo de señalización y el cliente no pueden comunicarse, aunque si el valor de Bit 7 es 1, el dispositivo de señalización y el cliente han reconocido que pueden comunicarse uno con otro. El campo de Tipo de Protección de contenido (2 bytes) contiene un conjunto de banderas que indican el tipo de protección de contenido digital soportado por la Pantalla. Actualmente, la posición de bit 0 se utiliza para indicar cuándo se soporta la DTCP y la posición de bit 1 se utiliza para indicar cuándo se soporta la HDCP, reservándose las posiciones de bit 2 a 15 para su uso con otros esquemas de protección según se desee o según haya disponibilidad, de manera que se establecen actualmente en cero. El campo de Nombre de Fbr. (aqui de 2 bytes) contiene el ID de 3 caracteres de EISA del fabricante, empaquetado en tres caracteres de 5 bits de la misma manera que en la especificación EDID de VESA. El carácter 'A' se representa como 00001 binario, el carácter 'Z' se representa como 11010 binario, y todas las letras entre 'A' y 'Z' se representan como valores binarios secuenciales que corresponden a la secuencia alfabética entre 'A' y 'Z' . El bit más significativo del campo de Nombre de Fbr. está inutilizado y generalmente se establece en cero lógico por ahora hasta que se hace uso en implementaciones posteriores. Ejemplo: un fabricante representado por la cadena "XYZ" tendría un valor de Nombre de Fbr. de 0x633a. Si este campo no es soportado por el cliente, generalmente se establece en cero. El campo de Código de Producto utiliza 2 bytes para contener un código de producto asignado por el fabricante de pantalla. Si este campo no es soportado por el cliente generalmente se establece en cero . Los campos de Reservado 1, Reservado 2, y Reservado 3 (aquí de 2 bytes cada uno) se encuentran reservados para su uso posterior al impartir información. Todos los bits en estos campos generalmente se establecen en un nivel de cero lógico. El propósito de tales campos es actualmente ocasionar que todos los campos subsecuentes de 2 bytes se alineen en una dirección de palabra de 16 bits y ocasionar que los campos de 4 bytes se alineen en una dirección de palabra de 32 bits. El campo de Número de Serie utiliza 4 bytes en esta modalidad para especificar el número de serie de la pantalla en forma numérica. Si este campo no es soportado por el cliente generalmente se establece en cero. El campo de Semana de Fabricación utiliza 1 byte para definir la semana de fabricación de la pantalla. Este valor se encuentra típicamente en el rango de 1 a 53 si es soportado por el cliente. Si este campo no es soportado por el cliente se establece en cero. El campo de Año de Fabricación es de 1 byte que define el año de fabricación de la pantalla. Este valor es una variación del año 1990. Los años en el rango de 1991 a 2245 pueden expresarse por este campo. Ejemplo: el año 2003 corresponde a un valor de Año de Fabricación de 13. Si este campo no es soportado por el cliente se establece en cero . El campo de CRC (aqui de 2 bytes) contiene una CRC de 16 bits de todos los bytes en el paquete incluyendo el Largo de Paquete .

G. Para Paquetes de Solicitud y Estado de Cliente El campo de Solicitud de Enlace Inverso (3 bytes) especifica el número de bytes que necesita el cliente en el enlace inverso en la siguiente sub-trama para enviarle información al huésped. El campo de Cuenta de Errores de CRC (1 byte) indica cuántos errores de CRC han ocurrido desde el inicio de la trama de medios . La cuenta de CRC se reestablece cuando se envía un paquete de cabecera de sub-trama con una Cuenta de Sub-trama de cero. Si el número actual de errores de CRC excede 255 entonces este valor generarme se satura en 255. El campo de Cambiar Capacidad utiliza 1 byte para indicar un cambio en la capacidad del cliente. Esto podría ocurrir si un usuario conecta un dispositivo periférico tal como un micrófono, teclado, o pantalla, o por alguna otra razón. Cuando los Bits [7:0] son iguales a 0, entonces la capacidad no ha cambiado desde que se envió el último Paquete de Capacidad de Cliente. Sin embargo, cuando los Bits [7:0] son iguales a l a 255, la capacidad ha cambiado. El Paquete de Capacidad de Cliente se examina para determinar las nuevas características de pantalla.

El campo de Banderas Ocupadas de Cliente utiliza 2 bytes para indicar que el cliente está ejecutando una función especifica y no se encuentra listo aún para aceptar otro paquete relacionado con esa función. Un bit establecido en un nivel o valor de uno lógico indica que la función particular se encuentra actualmente operada por el cliente y que la función relacionada en el cliente se encuentra ocupada. Si la función relacionada en el cliente está lista, el bit se establece en cero lógico. El cliente debe regresar a un estado ocupado (el bit se establece en uno) para todas las funciones que no son soportadas en el cliente. En una modalidad estos bytes se interpretan de acuerdo con la relación: si el Bit 0 es un '1' entonces la función de transferencia del bloque de mapa de bits se encuentra ocupada, mientras que si el Bit 1 es un '1', entonces una función de relleno de área de mapa de bits se encuentra ocupada, y si el Bit 2 es un '1', entonces una función de relleno de patrón de mapa de bits se encuentra ocupada. Actualmente, los Bits 3 a 15 permanecen reservados para su uso posterior y generalmente se establecen en un nivel o estado de uno lógico para indicar un estado ocupado en caso de que se asignen estos bits en el futuro.

H. Para Paquetes de Transferencia de Bloques de Bits Cada uno de los campos de Valor X y Valor Y de Coordenada Superior Izquierda de Ventana utiliza 2 bytes para especificar el valor X y Y de las coordenadas de la esquina superior izquierda de la ventana por moverse. Cada uno de los campos de Ancho y Altura de Ventana utiliza 2 bytes para especificar el ancho y altura de la ventana por moverse. Cada uno de los campos de Movimiento de X y Movimiento de Y de Ventana utiliza 2 bytes para especificar el número de píxeles que la ventana va a mover horizontalmente y verticalmente, respectivamente. Típicamente, estas coordenadas se encuentran configuradas de tal manera que los valores positivos para X ocasionan que la ventana se mueva a la derecha, y los valores negativos ocasionan que el movimiento sea a la izquierda, mientras que los valores positivos para Y ocasionan que la ventana se mueva hacia abajo, y los valores negativos ocasionan que el movimiento sea hacia arriba.

I. Para Paquetes de Rellenar Área de Mapa de Bits Cada uno de los campos de Valor X y Valor X de Coordenada Superior Izquierda de Ventana utiliza 2 bytes para especificar el valor X y Y de las coordenadas de la esquina superior izquierda de la ventana por rellenarse. Los campos de Ancho y Altura de Ventana (cada uno de 2 bytes) especifican el ancho y altura de la ventana por rellenarse. El campo de Descriptor de Formato de Datos de Video (2 bytes) especifica el formato del Valor de Relleno de Área de Pixel. El formato es el mismo que el mismo campo en el Paquete de Flujo de Video. El campo de Valor de Relleno de Área de Pixel (4 bytes) contiene el valor de pixel por rellenarse en la ventana especificada por los campos descritos con anterioridad. El formato de este píxel se especifica en el campo de Descriptor de Formato de Datos de Video.

J. Para Paquetes de Rellenar Patrón de Mapa de Bits Cada uno de los campos de Valor X y Valor Y de Coordenada Superior Izquierda de Ventana utiliza 2 bytes para especificar el valor X y Y de las coordenadas de la esquina superior izquierda de la ventana por rellenarse. Los campos de Ancho y Altura de Ventana (cada uno de 2 bytes) especifican el ancho y altura de la ventana por rellenarse. Los campos de Ancho de Patrón y Altura de Patrón (cada uno de 2 bytes) especifican el ancho y altura, respectivamente, del patrón de relleno. El campo de Variación de Patrón Horizontal (2 bytes) especifica una variación horizontal del patrón de datos de píxel derivado del borde izquierdo de la ventana especificada por rellenarse. El valor que se especifica es menor al valor en el Campo de Ancho de Patrón. El campo de Variación de Patrón Vertical (2 bytes) especifica una variación vertical del patrón de datos de píxel derivado del borde superior de la ventana especificada por rellenarse. El valor que se especifica es menor al valor en el Campo de Altura de Patrón. El campo de Descriptor de Formato de Datos de Video de 2 bytes especifica el formato del Valor de Relleno de Área de Pixel. La Figura 11 ilustra cómo se codifica el Descriptor de Formato de Datos de Video. El formato es el mismo que el mismo campo en el Paquete de Flujo de Video. El campo de CRC de Parámetro (2 bytes) contiene una CRC de todos los bytes desde el Largo de Paquete hasta el Descriptor de Formato de Video. Si falla la verificación de esta CRC entonces se descarta todo el paquete. El campo de Datos de Píxel de Patrón contiene información de video sin procesar que especifica el patrón de relleno en el formato especificado por el Descriptor de Formato de Datos de Video. Los datos se empaquetan en bytes, y el primer píxel de cada hilera es de byte alineado. Los datos de patrón de relleno se transmiten una hilera a la vez. El campo de CRC de Datos de Pixel de Patrón (2 bytes) contiene una CRC solamente de los Datos de Píxel de Patrón. Si falla la verificación de esta CRC entonces los Datos de Pixel de Patrón aún pueden utilizarse pero se incrementa la cuenta de errores de CRC.

K. Paquetes de Canal de Datos de Enlace de Comunicaciones El campo de CRC de Parámetro (2 bytes) contiene una CRC de 16 bits de todos los bytes desde el Largo de Paquete hasta el Tipo de Paquete. Si falla la verificación de CRC entonces se descarta todo el paquete . El campo de Datos de Enlace de Comunicaciones contiene los datos sin procesar provenientes del canal de comunicaciones. Estos datos se pasan simplemente al dispositivo de comunicaciones en la pantalla. El campo de CRC de Datos de Enlace de Comunicaciones (2 bytes) contiene una CRC de 16 bits solamente de los Datos de Enlace de Comunicaciones. Si falla la verificación de esta CRC entonces se utilizan o aún son útiles los Datos de Enlace de Comunicaciones, pero se incrementa la cuenta de errores de CRC.

L. Para Paquetes de Solicitud de Transferencia de Tipo de Inferíase El campo de Tipo de Inferíase (1 byte) especifica el nuevo tipo de interfase por utilizar. El valor en este campo especifica el tipo de interfase de la siguiente manera. Si el valor en el Bit 7 es igual a '0' la solicitud de transferencia de Tipo es para el enlace en avance, si es igual a '1', entonces la solicitud de transferencia de Tipo es para el enlace inverso. Los Bits 6 a 3 se encuentran reservados para su uso posterior, y generalmente se establecen en cero. Los Bits 2 a 0 se utilizan para definir el Tipo de interfase por utilizarse, refiriéndose un valor de 1 a una transferencia de modo Tipo 1, el valor de 2 a una transferencia al modo Tipo 2, un valor de 3 a una transferencia al modo Tipo 3, y un valor de 4 a una transferencia al modo Tipo 4. Los valores de '0' y 5 a 7 se encuentran reservados para su designación posterior de modos alternos o combinaciones de modos.

M. Para Paquetes de Reconocimiento de Tipo de Inferíase El campo de Tipo de Inferíase (1 byte) tiene un valor que confirma el nuevo tipo de interfase por utilizar. El valor en este campo especifica el tipo de interfase de la siguiente manera. Si el Bit 7 es igual a '0' la solicitud de transferencia de Tipo es para el enlace en avance, alternativamente, si es igual a '1' la solicitud de transferencia de Tipo es para el enlace inverso. Las posiciones de bit 6 a 3 actualmente se encuentran reservadas para su uso en la designación de otros tipos de transferencia, según se desea, y generalmente se establecen en cero. Sin embargo, las posiciones de bit 2 a 0 se utilizan para definir el Tipo de inferíase a utilizarse con un valor de '0' indicando un reconocimiento negativo, o que no puede realizarse la transferencia solicitada, indicando los valores de '1', '2', '3', y '4' la transferencia a los modos de Tipo 1, Tipo 2, Tipo 3, y Tipo 4, respectivamente. Los valores de 5 a 7 se encuentran reservados para su uso con designaciones alternas de modos, según se desee.

N. Para Paquetes de Transferencia de Tipo de Rendimiento El campo de Tipo de Interfase de 1 byte indica el nuevo tipo de interfase por utilizar. El valor presente en este campo especifica el tipo de interfase utilizando primeramente el valor del Bit 7 para determinar si la transferencia de Tipo es o no para los enlaces en avance o inverso. Un valor de '0' indica que la solicitud de transferencia de Tipo es para el enlace en avance, y un valor de '1' para el enlace inverso. Los bits 6 a 3 se encuentran reservados para su uso posterior, y como tal generalmente se establecen en un valor de cero. Sin embargo, los Bits 2 a 0 se utilizan para definir el Tipo de interfase por utilizarse, con los valores 1, 2, 3, y 4 que especifican el uso de transferencia a los modos de Tipo 1, Tipo 2, Tipo 3, y Tipo 4, respectivamente. El uso de valores 0 y 5 a 7 para estos bit se encuentran reservadas para su uso posterior.

O. Para Paquetes de Habilitación de Canal de Audio en Avance El campo de Máscara de Habilitación de Canal de Audio (1 byte) contiene un grupo de banderas que indican cuáles canales de audio van a habilitarse en un cliente. Un bit establecido en uno habilita el canal correspondiente, y un bit establecido en cero deshabilita el canal correspondiente. Los Bits 0 a 5 designan los canales 0 a 5 que direccionan los canales frontal izquierdo, frontal, derecho, posterior izquierdo, posterior derecho, central frontal, y de subaltavoz para bajas frecuencias, respectivamente. Los Bits 6 y 7 se encuentran reservados para su uso posterior, y entretanto se establecen generalmente iguales a cero.

P. Para Paquetes de Tasa de muestreo de Audio Inverso El campo de Tasa de muestreo de Audio (1 byte) especifica la tasa de muestreo de audio digital. A los valores para este campo se les asignan diferentes tasas con valores de 0, 1, 2, 3, 4, 5, 6, 7, y 8 utilizándose para designar 8,000, 16, OOO, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, y 44,100 muestras por segundo (SPS), respectivamente, reservándose los valores de 9 a 254 para su uso con tasas alternativas, según se desea, de manera que actualmente se establecen en '0' . Un valor de 255 se utiliza para deshabilitar el flujo de audio de enlace inverso. El campo de Formato de Muestra (1 byte) especifica el formato de las muestras de audio digital. Cuando los Bits [1:0] son iguales a '0', las muestras de audio digital se encuentran en formato lineal, cuando son iguales a 1, las muestras de audio digital se encuentran en formato de Ley de µ, y cuando son iguales a 2, las muestras de audio digital se encuentran en formato de Ley A. Los Bits [7:2] se encuentran reservados para su uso alterno en la designación de formatos de audio, según se desee, y generalmente se establecen iguales a cero.

Q. Para los Paquetes de Información Complementaria de Protección de Contenido Digital El campo de Tipo de Protección de Contenido (1 byte) especifica que se utiliza el método de protección de contenido digital. Un valor de '0' indica la Protección de Contenido de Transmisión Digital (DTCP) mientras que un valor de 1 indica un Sistema de Protección de Contenido Digital de Ancho de Banda Alta (HDCP) . El rango de valores de 2 a 255 no se encuentra actualmente especificado pero se encuentra reservado para su uso con esquemas de protección alternos según se desee. El campo de Mensajes de Información Complementaria de Protección de Contenido es un campo de largo variable que contiene mensajes de protección de contenido enviados entre el huésped y el cliente.

R. Para los Paquetes de Habilitación de Color Transparente El campo de Habilitación de Color Transparente (1 byte) especifica cuándo se encuentra habilitado o deshabilitado el modo de color transparente. Si el Bit 0 es igual a 0, entonces el modo de color transparente se encuentra deshabilitado, si es igual a 1 entonces el modo de color transparente se encuentra habilitado y el color transparente se especifica por los siguientes dos parámetros. Los Bits 1 a 4 de este byte se encuentran reservados para su uso posterior y típicamente se establecen iguales a cero. El campo de Descriptor de Formato de Datos de Video (2 bytes) especifica el formato del Valor de Relleno de Área de Píxel. La Figura 11 ilustra cómo se codifica el Descriptor de Formato de Datos de Video. El formato generalmente es el mismo que el mismo campo en el Paquete de Flujo de Video. El campo de Valor de Relleno de Área de Pixel utiliza 4 bytes asignados para el valor de píxel por rellenarse en la ventana especificada con anterioridad. El formato de este píxel se especifica en el campo de Descriptor de Formato de Datos de Video.

S. Para los Paquetes de Medición de Retraso de Viaje Redondo El campo de Largo de Paquete de 2 bytes especifica el número total de bytes en el paquete sin incluir el campo de largo de paquete, y en una modalidad se selecciona por tener un largo fijo de 159. El campo de Tipo de Paquete de 2 bytes que identifica este tipo de paquete con un valor de 82, identificando un paquete como un Paquete de Medición de Retraso de Viaje Redondo. El campo de ID de hCliente, como antes se encuentra reservado para su uso posterior como ID de Cliente, y generalmente se establece en cero. En una modalidad, el campo de CRC de Parámetro (2 bytes) contiene una CRC de 16 bits de todos los bytes desde el Largo de Paquete al Tipo de Paquete. Si falla la verificación de esta CRC entonces se descarta todo el paquete. El campo de Tiempo de Guardia 1 (aqui de 64 byte) se utiliza para permitir la habilitación de los manejadores de línea de MDDI_Datos en el cliente antes de que se deshabiliten los manejadores de linea. El cliente habilita a sus manejadores de linea de MDDI_Datos durante el bit 0 del Tiempo de Guardia 1 y el huésped deshabilita sus manejadores de línea a fin de deshabilitarse completamente antes del último bit del Tiempo de Guardia 1. El huésped y el cliente manejan ambos un nivel de cero lógico durante el Tiempo de Guardia 1 cuando no se encuentran deshabilitados. Otro propósito de este campo es asegurar que todas las señales de MDDI_Datos se encuentren en un nivel de cero lógico durante un tiempo suficiente para permitirle al cliente comenzar a recuperar un reloj o señal de reloj utilizando solamente MDDI_Stb antes de deshabilitar los manejadores de línea del huésped. El campo de Periodo de Medición es una ventana de 64 bytes utilizada para permitirle al cliente responder con dos bytes de Oxff, y 30 bytes de 0x00 a la mitad de la tasa de datos utilizada en el enlace en avance. Esta tasa de datos corresponde a un Divisor de Tasa de Enlace Inverso de 1. El cliente regresa esta respuesta inmediatamente en el momento en que percibe que es el inicio del Periodo de Medición. Esta respuesta proveniente del cliente será recibida en un huésped precisamente en el retraso de viaje redondo del enlace más el retraso lógico en el cliente después del inicio del primer bit del Periodo de Medición en el huésped. El campo de Sólo Ceros 1 (2 bytes) contiene ceros para permitirle a los manejadores de linea de MDDI_Datos en el huésped y el cliente sobreponerse de manera que siempre se maneja MDDI_Datos. El huésped habilita a los manejadores de linea de MDDI_Datos durante el bit 0 del campo Sólo Ceros 1, y el cliente continúa manejando también la señal en un nivel de cero lógico como lo hizo al final del Periodo de Medición. El valor en el campo de Tiempo de Guardia 2 (64 bytes) permite sobreponer el Periodo de Medición manejado por el cliente cuando el retraso de viaje redondo se encuentra en la máxima cantidad que puede medirse en el Periodo de Medición. El Cliente deshabilita a sus manejadores de linea durante el bit 0 del Tiempo de Guardia 2 y el Huésped habilita sus manejadores de línea inmediatamente después del último bit del Tiempo de Guardia 2. El huésped y el cliente manejan ambos un nivel de cero lógico durante el Tiempo de Guardia 2 cuando no se encuentran deshabilitados. Otro propósito de este campo es asegurar que todas las señales de MDDI_Datos se encuentran en un nivel de cero lógico durante un tiempo suficiente para permitirle al cliente comenzar a recuperar una señal de reloj utilizando tanto MDDI DatosO como MDDI Stb después de habilitar los manejadores de línea para un huésped.

T. Para los Paquetes de Calibración de Distorsión de Enlace en Avance En una modalidad, el campo de CRC de Parámetro (2 bytes) contiene una CRC de 16 bits de todos los bytes desde el Largo de Paquete al Tipo de Paquete. Si falla la verificación de esta CRC, entonces se descarta todo el paquete. El campo de Sólo Ceros 1 utiliza 1 byte para asegurar que habrá una transición en la MDDI_Stb al final del campo de CRC de Parámetro . El campo de Secuencia de Datos de Calibración contiene una secuencia de datos que ocasiona que las señales de MDDI_Datos cambien en cada periodo de datos . El largo del campo de Secuencia de Datos de Calibración se determina por la interfase que se utiliza en el enlace en avance. Durante el procesamiento de la Secuencia de Datos de Calibración, el controlador de huésped de MDDI establece todas las señales de MDDI_Datos iguales a la señal estroboscópica. El circuito de recuperación de reloj de cliente debe utilizar solamente MDDI_Stb en lugar de MDDI_Stb Xor MDDI_DatosO para recuperar el reloj de datos mientras que el campo de Secuencia de Datos de Calibración es recibido por la Pantalla de cliente. Dependiendo de la fase exacta de la señal de MDDI_Stb al inicio del campo de Secuencia de Datos de Calibración, la Secuencia de Datos de Calibración generalmente será una de las siguientes con base en el Tipo de interfase utilizado cuando se envía este paquete: Tipo 1 - (secuencia de datos de 64 bytes) Oxaa, Oxaa ... o 0x55, 0x55.. Tipo 2 - (secuencia de datos de 128 bytes) Oxee, Oxee ... o 0x33, 0x33.. Tipo 3 - (secuencia de datos de 256 bytes) OxfO, OxfO ... o OxOf, 0x0f.. Tipo 4 - (secuencia de datos de 512 bytes) Oxff, 0x00, Oxff, 0x00 ... o 0x00, Oxff, 0x00, Oxff... Un ejemplo de las posibles formas de onda de MDDI_Datos y MDDI_Stb para ambas Interfases de Tipo 1 y Tipo 2 se muestran en las Figuras 62A y 62B, respectivamente .

XX. Conclusión Aunque se han descrito con anterioridad diversas modalidades de la presente invención, debe comprenderse que se han presentado solamente a manera de ejemplo, y no como limitante. Consecuentemente, la extensión y el alcance de la presente invención no deben limitarse por ninguna de las modalidades a manera de ejemplo anteriormente descritas, pero deben definirse solamente de acuerdo con las siguientes reivindicaciones y sus equivalentes.

Claims (40)

1. NOVEDAD DE LA INVENCIÓN Habiéndose descrito la invención como antecedente, se reclama como propiedad lo contenido en las siguientes reivindicaciones:
2. REIVINDICACIONES 1. Una interfase de datos digital para transferir datos de presentación digital a una tasa alta entre un dispositivo huésped y un dispositivo cliente sobre una trayectoria de comunicaciones caracterizada porque comprende: una pluralidad de estructuras de paquete enlazada conjuntamente para formar un protocolo de comunicaciones para comunicar un conjunto pre-seleccionado de datos digitales de control y de presentación entre un huésped y un cliente por dicha trayectoria de comunicaciones; y al menos un controlador de enlace que reside en dicho dispositivo huésped acoplado a dicho cliente por dicha trayectoria de comunicaciones, configurándose para generar, transmitir, y recibir paquetes que forman dicho protocolo de comunicaciones, y para formar datos de presentación digital en uno o más tipos de paquetes de datos. 2. La interfase según la reivindicación 1, caracterizada además porque comprende dichos paquetes agrupados conjuntamente en tramas de medios que se comunican entre dicho huésped y cliente teniendo un largo fijo predefinido con un número pre-determinado de dichos paquetes que tienen largos diferibles y variables .
3. 3. La interfase según la reivindicación 1, caracterizada además porque comprende un Paquete de Cabecera de Sub-Trama colocada al inicio de las transferencias de paquetes provenientes de dicho huésped.
4. 4. La interfase según la reivindicación 1, caracterizada además porque dicho controlador de enlace es un controlador de enlace y que comprende además al menos un controlador de enlace de cliente que reside en dicho dispositivo cliente acoplado a dicho huésped mediante dicha trayectoria de comunicaciones, configurada para generar, transmitir, y recibir paquetes que forman dicho protocolo de comunicaciones, y para formar datos de presentación digital en uno o más tipos de paquetes de datos.
5. 5. La interfase según la reivindicación 2, caracterizada además porque comprende: una pluralidad de modos de transferencia, permitiendo cada uno de ellos la transferencia de diferentes números máximos de bits de datos en paralelo durante un determinado periodo de tiempo, seleccionable con cada modo por negociación entre dichos manejadores de enlace de huésped y cliente; y donde dichos modos de transferencia son dinámicamente ajustables entre dichos modos durante la transferencia de datos.
6. 6. La interfase según la reivindicación 1, caracterizada además porque comprende un paquete de tipo de Desconexión de Enlace para la transmisión por dicho huésped a dicho cliente a fin de terminar la transferencia de datos en cualquier dirección por dicha trayectoria de comunicaciones.
7. 7. La interfase según la reivindicación 1, caracterizada además porque comprende medios para que dicho cliente despierte a dicho huésped de un estado de hibernación.
8. 8. Un método para transferir datos digitales a una tasa alta entre un dispositivo huésped y un dispositivo cliente por una trayectoria de comunicaciones para la presentación a un usuario, caracterizado porque comprende: generar una o más pluralidades de estructuras de paquete predefinidas y enlazarlas conjuntamente para formar un protocolo de comunicaciones predefinidas; comunicar un conjunto predefinido de control digital y de datos de presentación entre dichos dispositivos huésped y cliente por dicha trayectoria de comunicaciones utilizando dicho protocolo de comunicaciones; acoplar al menos un controlador de enlace de huésped que reside en dicho dispositivo huésped a dicho dispositivo cliente mediante dicha trayectoria de comunicaciones, configurándose el controlador de enlace de huésped para generar, transmitir, y recibir paquetes que forman dicho protocolo de comunicaciones, y para formar datos de presentación digital en uno o más tipos de paquetes de datos; y transferir datos en forma de paquetes por dicha trayectoria de comunicaciones utilizando dichos controladores de enlace.
9. 9. El método según la reivindicación 8, caracterizado además porque comprende agrupar dichos paquetes conjuntamente en tramas de medios para la comunicación entre dicho huésped y cliente, teniendo las tramas de medios un largo fijo predefinido con un número predeterminado de dichos paquetes que tienen largos diferibles y variables.
10. 10. El método según la reivindicación 8, caracterizado además porque comprende comenzar la transferencia de paquetes provenientes de dicho huésped con un paquete de tipo de Cabecera de Sub-trama.
11. 11. El método según la reivindicación 8, caracterizado además porque comprende generar, transmitir, y recibir paquetes que forman dicho protocolo de comunicaciones mediante al menos un controlador de enlace de cliente que reside en dicho dispositivo cliente acoplado a dicho dispositivo huésped mediante dicha trayectoria de comunicaciones.
12. 12. El método según la reivindicación 11, caracterizado además porque comprende: negociar entre los manejadores de enlace huésped y cliente el uso de una pluralidad de modos de transferencia en cada dirección, permitiendo cada uno la transferencia de diferentes números máximos de bits de datos en paralelo por un determinado periodo de tiempo; y ajustar dinámicamente entre dichos modos de transferencia durante la transferencia de datos.
13. 13. El método según la reivindicación 8, caracterizado además porque comprende terminar la transferencia de datos en cualquier dirección por dicha trayectoria de comunicaciones utilizando un paquete de tipo de Desconexión de Enlace para la transmisión por dicho huésped a dicho cliente.
14. 14. El método según la reivindicación 8, caracterizado además porque comprende despertar dicho huésped de un estado de hibernación por la comunicación con dicho cliente.
15. 15. Aparato para transferir datos digitales a una tasa alta entre un dispositivo huésped y un dispositivo cliente por una trayectoria de comunicaciones para la presentación a un usuario, caracterizado porque comprende: al menos un controlador de enlace de huésped colocado en dicho dispositivo huésped para generar una o más pluralidades de estructuras de paquete predefinidas y enlazarlas conjuntamente para formar un protocolo de comunicaciones predefinidas, y para comunicar un conjunto preseleccionado de datos digitales de control y de presentación entre dichos dispositivos huésped y cliente por dicha trayectoria de comunicaciones utilizando dicho protocolo de comunicaciones ; al menos un controlador de cliente colocado en dicho dispositivo cliente y acoplado a dicho controlador de enlace de huésped mediante dicha trayectoria de comunicaciones; y configurándose cada controlador de enlace para generar, transmitir, y recibir paquetes que forman dicho protocolo de comunicaciones, y para formar datos de presentación digital en uno o más tipos de paquetes de datos.
16. 16. El aparato según la reivindicación 15, caracterizado además porque dicho controlador de huésped comprende una máquina de estados.
17. 17. El aparato según la reivindicación 15, caracterizado además porque un controlador de huésped comprende un procesador de señales de propósito general.
18. 18. El aparato según la reivindicación 15, caracterizado además porque comprende un paquete de tipo de Cabecera de Sub-trama al inicio de la transferencia de paquetes provenientes de dicho huésped.
19. 19. El aparato según la reivindicación 15, caracterizado además porque dicho controlador de huésped comprende uno o más manejadores de línea diferencial; y dicho receptor de cliente comprende uno o más receptores de línea diferencial acoplados a dicha trayectoria de comunicaciones.
20. 20. El aparato según la reivindicación 15, caracterizado porque dichos controladores de huésped y de enlace se encuentran configurados para utilizar un pluralidad de modos de transferencia en cada dirección, permitiendo cada uno de ellos la transferencia de diferentes números máximos de bits de datos en paralelo durante un determinado periodo de tiempo; y siendo capaces de ajustarse dinámicamente entre dichos modos de transferencia durante la transferencia de datos.
21. 21. El aparato según la reivindicación 15, caracterizado además porque dicho controlador de huésped se encuentra configurado para transmitirle un paquete de tipo de Desconexión de Enlace a dicho medio de cliente para terminar la transferencia de datos en cualquier dirección por dicha trayectoria de comunicaciones .
22. 22. Para su uso en un sistema electrónico para transferir datos digitales a una tasa alta entre un dispositivo huésped y un dispositivo cliente por una trayectoria de comunicaciones para la presentación a un usuario, un producto de programa de computadora caracterizado porque comprende: un medio utilizable por computadora que tiene un medio de código de programa legible por computadora incorporado a dicho medio para ocasionar que se ejecute un programa de aplicación en el sistema de computadora, comprendiendo dicho medio de código de programa legible por computadora : un primer medio de código de programa legible por computadora para ocasionar que el sistema de computadora genere una o más pluralidades de estructuras de paquete predefinidas y enlazarlas conjuntamente para formar un protocolo de comunicaciones predefinidas; un segundo medio de código de programa legible por computadora para ocasionar que el sistema de computadora comunique un conjunto preseleccionado de datos de control y presentación digital entre dichos dispositivos huésped y cliente por dicha trayectoria de comunicaciones utilizando dicho protocolo de comunicaciones; un tercer medio de código de programa legible por computadora para ocasionar que el sistema de computadora acople al menos un controlador de enlace colocado en dicho dispositivo huésped al menos a un controlador de cliente colocado en dicho dispositivo cliente mediante dicha trayectoria de comunicaciones, configurándose los controladores de enlace para generar, transmitir, y recibir paquetes que forman dicho protocolo de comunicaciones, y para formar datos de presentación digital en uno o más tipos de paquetes de datos; y un cuarto medio de código de programa legible por computadora para ocasionar que el sistema de computadora transfiera los datos en forma de paquetes por dicha trayectoria de comunicaciones utilizando dichos controladores de enlace.
23. 23. Un aparato para transferir datos digitales a una tasa alta entre un dispositivo huésped y un dispositivo cliente por una trayectoria de comunicaciones para la presentación a un usuario, caracterizado porque comprende: medios para generar una o más pluralidades de estructuras de paquete predefinidas y enlazarlas conjuntamente para formar un protocolo de comunicaciones predefinidas; medios para comunicar un conjunto preseleccionado de datos de control y presentación digital entre dichos dispositivos huésped y cliente por dicha trayectoria de comunicaciones utilizando dicho protocolo de comunicaciones; medios para acoplar al menos dos controladores de enlace conjuntamente mediante dicha trayectoria de comunicaciones, configurándose cada uno de ellos en dicho huésped y cliente para generar, transmitir, y recibir paquetes que forman datos de presentación digital en uno o más tipos de paquetes de datos; y medios para transferir datos en forma de paquetes por dicha trayectoria de comunicaciones utilizando dichos controladores de enlace.
24. 24. El aparato según la reivindicación 23, caracterizado además porque comprende medios para comenzar la transferencia de paquetes provenientes de dicho huésped con un paquete de tipo de Cabecera de Sub-trama.
25. 25. El aparato según la reivindicación 23, caracterizado además porque comprende medios para solicitar información de capacidades de pantalla provenientes del cliente por un controlador de enlace de huésped a fin de determinar qué tipo de datos y tasas de datos es capaz dicho cliente de alojar mediante dicha interfase.
26. 26. Un procesador para su uso en un sistema electrónico para transferir datos digitales a una tasa alta entre un dispositivo huésped y un dispositivo cliente por una trayectoria de comunicaciones, configurado el procesador para generar una o más pluralidades de estructuras de paquete predefinidas y enlazarlas conjuntamente para formar un protocolo de comunicaciones predefinido; formar datos digitales en uno o más tipos de paquetes de datos; comunicar un conjunto preseleccionado de datos de control y presentación digital entre dichos dispositivos huésped y cliente por dicha trayectoria de comunicaciones utilizando dicho protocolo de comunicaciones; y transferir datos en forma de paquetes por dicha trayectoria de comunicaciones .
27. 27. Una máquina de estados para su uso en la obtención de sincronización en un sistema electrónico que transfiere datos digitales a una tasa alta entre un dispositivo huésped y un dispositivo cliente por una trayectoria de comunicaciones, configurada la máquina de estados para tener al menos un estado de sincronización de Estado de Tramas Asincrónicas, al menos dos estados de sincronización de Adquirir Estados Sincrónicos, y al menos tres estados de sincronización de Estados En Sincronía.
28. 28. Una máquina de estados para su uso en la obtención de sincronización de un sistema electrónico que transfiere datos digitales a una tasa alta entre un dispositivo huésped y un dispositivo cliente por una trayectoria de comunicaciones, configurada la máquina de estados para tener al menos un estado de sincronización de Adquirir Estados Sincrónicos, y al menos dos estados de sincronización de Estados En Sincronía.
29. 29. La máquina de estados según la reivindicación 28, caracterizada porque una condición para cambiar entre un Estado de Adquirir Sincronía y un primer Estado En Sincronía es detectar la presencia de un patrón de sincronización en el enlace de comunicaciones .
30. 30. La máquina de estados según la reivindicación 28, caracterizada porque una segunda condición para cambiar entre un Estado de Adquirir Sincronía y un primer Estado En Sincronía es detectar la presencia de un paquete de cabecera de sub-trama y un valor de buena CRC en un limite de trama.
31. 31. La máquina de estados según la reivindicación 28, caracterizada porque una condición para cambiar entre un primer Estado En Sincronía y un Estado Adquirir Sincronía es detectar la presencia de ningún patrón de sincronización o un valor de mala CRC en un limite de sub-trama.
32. 32. La máquina de estados según la reivindicación 28, caracterizada porque una condición para cambiar entre un primer Estado En Sincronía y un segundo Estado En Sincronía es detectar la presencia de ningún patrón de sincronización o un valor de mala CRC en un limite de sub-trama.
33. 33. El método según la reivindicación 12, caracterizado porque comprende despertar un enlace de comunicaciones al llevar una linea de datos a un estado alto durante al menos 10 cíelos de reloj y comenzar a transmitir una señal estroboscópica como si la línea de datos fuese cero, por dicho huésped.
34. 34. El método según la reivindicación 33, caracterizado además porque comprende llevar la linea de datos a bajo para un número predeterminado de ciclos de reloj por dicho huésped mientras continúa transmitiendo una señal estroboscópica después de que el huésped ha llevado la linea de datos a alto durante aproximadamente 150 ciclos de reloj .
35. 35. El método según la reivindicación 33, caracterizado además porque comprende comenzar a transmitir el primer paquete de cabecera de sub-trama por dicho huésped.
36. 36. El método según la reivindicación 34, caracterizado además porque comprende contar al menos 150 ciclos de reloj continuos de la linea de datos que es alta, seguida de al menos 50 ciclos de reloj continuos de la linea de datos que es baja, por dicho cliente.
37. 37. El método según la reivindicación 34, caracterizado además porque comprende dejar de llevar la linea de datos a alto por dicho cliente después de que el cliente cuenta 70 ciclos de reloj continuos de los datos que se encuentran en estado alto.
38. 38. El método según la reivindicación 37, caracterizado además porque comprende contar otros 80 ciclos de reloj continuos de la linea de datos que se encuentra en alto para alcanzar los 150 ciclos de reloj de la línea de datos que se encuentra en alto por dicho cliente, y buscar aproximadamente 50 ciclos de reloj de la línea de datos que se encuentra en bajo, y buscar la palabra única.
39. 39. El método según la reivindicación 12, caracterizado además porque comprende contar el número de ciclos de reloj que ocurre hasta que se muestrea un uno por dicho huésped, muestreando la línea de datos tanto en los bordes de subida como de bajada durante el paquete de sincronización inversa.
40. 40. El método según la reivindicación 12, caracterizado además porque comprende contar el número de ciclos de reloj que ocurren hasta que se muestrea un uno por dicho huésped, muestreando la línea de datos tanto en los bordes de subida como de bajada durante el paquete de sincronización inversa.