MXPA06010873A - Metodo y aparato de interfase de tasa de datos alta. - Google Patents

Abstract

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

Description

MÉTODO Y APARATO DE INTERFAZ DE DATOS DE ALTA VELOCIDAD CAMPO DE LA INVENCIÓN Las modalidades de la invención en esta descripción se refieren a un protocolo de señal digital, proceso y aparato, incluyendo circuitos integrados y componentes para comunicar o transferir señales entre un dispositivo huésped y un dispositivo del cliente a velocidades altas de datos. Muy específicamente, la descripción se refiere a una técnica para transferir multimedia y otros tipos de señales digitales desde un huésped o dispositivo controlador a un dispositivo de cliente para presentación o despliegue a un usuario final utilizando un mecanismo de transferencia de alta velocidad de datos de baja energía que tiene aplicaciones de dispositivo internas y externas.

ANTECEDENTES DE LA INVENCIÓN Computadoras, productos relacionados con juegos electrónicos, y varias tecnologías de video (por ejemplo, Discos Versátiles Digitales (DVD) y de Alta Definición (VCR) han avanzado significativamente durante los últimos años para proveer presentación de imágenes estáticas, de video, video-sobre-demanda, y gráficos cada vez con más alta resolución, incluso cuando se incluyen algunos tipos de texto, a los usuarios finales de dicho equipo. Estos avances a su vez exigieron el uso de dispositivos de visualización electrónicos de mayor resolución tal como monitores de video de alta definición, monitores de Televisión de Alta Definición (HDTV) , o elementos de proyección de imágenes especializadas. La combinación de dichas imágenes visuales con datos de audio de alta definición o alta calidad, tal como cuando se utiliza reproducción de sonido tipo Disco Compacto (CD) , DVD, sonido ambiental, y otros dispositivos que también tienen salidas de señal de audio asociadas, se utiliza para crear una experiencia de multimedia más realista, rica en contenido o verdadera para un usuario final. Además, los sistemas de sonido altamente móviles de alta calidad y los mecanismos de transporte de música tal como reproductores de MP3, han sido desarrollados para presentaciones de audio únicamente a los usuarios finales . Esto ha dado como resultado expectativas más elevadas para los usuarios típicos de dispositivos electrónicos comerciales, desde computadoras hasta televisiones e incluso teléfonos, quienes ahora se han acostumbrado a ellos y esperan un resultado de calidad elevada o Premium. En un escenario de presentación de video típica, que involucra un producto electrónico, los datos de video típicamente se transfieren utilizando técnicas actuales a una velocidad que podría ser mejor calificada como lenta o mediana, ubicándose en el orden de uno a diez kilobits por segundo. Estos datos son almacenados en memoria intermedia o almacenados en dispositivos de memoria a más largo plazo o transitoria, para interpretación retrasada (posterior) en un dispositivo de visualización deseado. Por ejemplo, se pueden transferir imágenes "a través de" o utilizando la Internet mediante el uso de un programa que reside en una computadora la cual tiene un módem u otro tipo de dispositivo de conexión de Internet, para recibir o transmitir datos útiles en la representación digital de una imagen. Puede ocurrir una transferencia similar utilizando dispositivos inalámbricos tal como computadoras portátiles equipadas con módems inalámbricos, o Asistentes de Datos Personales inalámbricos (PDA) o teléfonos inalámbricos. Una vez recibidos, los datos son almacenados localmente en elementos de memoria, circuitos o dispositivos, tal como Memoria de Acceso Aleatorio (RAM) o memoria instantánea, incluyendo dispositivos de almacenamiento interno o externo tal como unidades de disco duro de pequeño tamaño, para reproducción. Dependiendo de la cantidad de datos y la resolución de la imagen, la reproducción podría comenzar en forma relativamente rápida, o se podría presentar con un retraso de término más prolongado. Es decir, en algunos casos, la presentación de la imagen permite un cierto grado de reproducción en tiempo real para imágenes muy pequeñas o de lenta resolución que no requieran muchos datos, o que utilicen cierto tipo de almacenamiento en memoria intermedia, de manera que después de un corto retraso, cierto material es presentado mientras se está transfiriendo más material. Siempre y cuando no haya interrupciones en el enlace de transferencia, o interferencia proveniente de otros sistemas o usuarios con relación al canal de transferencia que se está utilizando, una vez que la presentación comienza, la transferencia es razonablemente transparente para el usuario final del dispositivo de visualización. Naturalmente, en los casos donde múltiples usuarios comparten una sola trayectoria de comunicación, tal como una conexión de Internet cableada, las transferencias se pueden interrumpir o volver más lentas, según se desee. Los datos utilizados para crear ya sea imágenes estáticas o video en movimiento con frecuencia son comprimidos utilizando una de varias técnicas muy conocidas, tal como aquellas especificadas por el Grupo de Expertos Fotográficos Unidos (JPEG) , el Grupo de Expertos en Imágenes en Movimiento (MPEG) , y otras normas muy conocidas, organizaciones o compañías en los medios, computadoras e industrias de comunicaciones para acelerar la transferencia de datos en un enlace de comunicación. Esto permite la transferencia de imágenes o datos más rápido utilizando un número más pequeño de bits para transferir una cantidad determinada de información. Una vez que los datos son transferidos a un dispositivo "local" tal como una computadora que tiene un mecanismo de almacenamiento tal como memoria, o elementos de almacenamiento magnético u óptico, o a otros dispositivos receptores, la información resultante es descomprimida (o reproducida utilizando reproductores de decodificación especiales), y decodificada si es necesario, y preparada para 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 píxeles, típicamente oscila de una cantidad tan baja como 480x640 píxeles, pasando por 600x800 a 1024x1024, aunque generalmente es posible una variedad de otras resoluciones, 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 los controladores de video determinados para manipular la imagen en términos de ciertos niveles de color predefinidos o profundidad de color (bits por píxel utilizados para generar colores) e intensidades, y cualesquiera bits de sobrecarga adicionales que se estén empleando. Por ejemplo, una presentación en computadora típica anticiparía una oscilación de alrededor de 8 a 32, o más, bits por píxel para representar varios colores (sombras y tonos) , aunque también se encuentran otros valores. A partir de los valores anteriores, se puede apreciar que una imagen de pantalla determinada va a requerir la transferencia que oscila de 2.45 Megabits (Mb) a aproximadamente 33.55 Mb de datos en el rango que va desde las resoluciones y profundidad típicas más bajas a las más elevadas, respectivamente. Cuando se visualizan imágenes tipo en movimiento o video a una velocidad de 30 cuadros por segundo, la cantidad de datos que se requiere es de alrededor de 73.7 a 1,006 Megabits de datos por segundo (Mbps), o alrededor de 9.21 a 125.75 Megabytes por segundo (MBps) . Además, se podría desear presentar datos de audio junto con imágenes, tal como para una presentación de multimedia, o como una presentación de audio de alta resolución separada, tal como música de calidad CD. También se pueden emplear señales adicionales que se refieren a comandos interactivos, controles o señales. Cada una de estas opciones agrega incluso más datos que van a ser transferidos. Además, técnicas de transmisión más nuevas que involucran HDTV y grabaciones de película pueden agregar incluso más datos e información de control. En cualquier caso, cuando se desea transferir datos de imágenes de alta resolución o alta calidad e información de audio de alta calidad o señales de datos a un usuario final para crear una experiencia rica en contenido, se requiere un enlace de alta velocidad de transferencia de datos entre los elementos de presentación y el dispositivo huésped o fuente que está configurado para proveer dichos tipos de datos. Las velocidades de datos de alrededor de 115 Kilobytes (KBps) ó 920 kilobits por segundo (Kbps) pueden ser manejadas de manera rutinaria por algunas interfaces en serie modernas. Otras interfaces tal como interfaces en serie USB pueden permitir transferencias de datos a velocidades tan altas como 12 MBps, y las transferencias de alta velocidad especializadas tal como aquellas configuradas utilizando la norma del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) 1394, pueden ocurrir a velocidades en el orden de 100 a 400 MBps. Infortunadamente, esas velocidades se quedan cortas en comparación con las altas velocidades de datos deseadas antes analizadas, las cuales se contemplan para uso con futuros dispositivos de datos inalámbricos y otros servicios para proveer señales de salida, ricas en contenido, de alta resolución para accionar pantallas de video portátiles o dispositivos de audio. Esto incluye computadoras para negocios y otras presentaciones, dispositivos de juegos y así sucesivamente. Además, estas interfaces requieren el uso de una cantidad importante de software huésped, o de sistema y de cliente para operar. Sus pilas de protocolo de software también crean una cantidad de sobrecarga indeseablemente grande, especialmente en los casos donde se contemplan los dispositivos inalámbricos móviles o las aplicaciones telefónicas. Dichos dispositivos tienen limitaciones severas de consumo de energía y memoria, así como capacidad computacional ya puesta a prueba. Además, algunas de estas interfaces utilizan cables voluminosos los cuales son demasiado pesados e insatisfactorios para aplicaciones móviles orientadas altamente estéticas, conectores complejos que añaden costo, o simplemente consumen demasiada energía. Existen otras interfaces conocidas tal como el Adaptador de Gráficos de Video Análogo (AVGA) , las interfaces Interactiva de Video Digital (DVI) o Interfaz de Video de Gigabit (GVIF) . Las primeras dos de éstas son interfaces tipo paralelas las cuales procesan datos a velocidades de transferencia superiores, pero también emplean cables pesados y consumen grandes cantidades de energía, en el orden de varios vatios. Ninguna de estas características son acordes para uso con dispositivos electrónicos portátiles para el consumidor. Incluso la tercera interfaz consume demasiada energía y utiliza conectores costosos y voluminosos. Para algunas de las interfaces anteriores, y otros sistemas/protocolos de datos de velocidad muy alta o mecanismos de transferencia asociados con transferencias de datos para equipo de cómputo de instalación fija, existe otro inconveniente mayor. El hecho de permitir velocidades de transferencia de datos deseadas también requiere cantidades sustanciales de energía y/u operación a altos niveles de corriente. Esto reduce tremendamente la utilidad de dichas técnicas para productos orientados al consumidor altamente móviles. Generalmente, el hecho de permitir dichas velocidades de transferencia de datos utilizando alternativas tal como conexiones de tipo de fibra óptica y elementos de transferencia, también requiere un número de convertidores y elementos adicionales que introducen mucha más complejidad y costo de lo que se desea para un producto orientado al consumidor verdaderamente comercial . Aparte de la naturaleza generalmente costosa de los sistemas ópticos aún, sus requerimientos de energía y complejidad evitan el uso general para aplicaciones portátiles, de peso ligero y baja energía. Lo que ha hecho falta en la industria de las aplicaciones portátiles, inalámbricas o móviles es una técnica para proveer una experiencia de presentación de alta calidad, ya sea basada en audio, video o multimedia, para usuarios finales altamente móviles. Es decir, cuando se utilizan computadoras portátiles, teléfonos inalámbricos, PDA, u otros dispositivos o equipo de comunicación, altamente móviles, los sistemas o dispositivos de presentación de audio y video actuales que se utilizan simplemente no pueden entregar una salida al nivel deseado de alta calidad. Con frecuencia, la calidad percibida que está faltando es el resultado de velocidades altas de datos que no se pueden obtener, necesarias para transferir los datos de presentación de alta calidad. Esto puede incluir tanto transferencia a dispositivos externos cargados con funciones o avanzados, más eficientes, para presentación a un usuario final, como transferencia entre huéspedes y clientes dentro de dispositivos portátiles tal como computadoras, máquinas de juego, y dispositivos inalámbricos tal como teléfonos móviles. En este último caso, ha habido grandes progresos al agregar pantallas de video internas de mayor y mayor resolución, y otros dispositivos de entrada y/o salida de especialidad y conexiones a dispositivos inalámbricos tal como los denominados teléfonos de tercera generación, y las denominadas computadoras portátiles. Sin embargo, los enlaces de datos internos y conexiones los cuales pueden incluir puenteo a través de estructuras tipo bisagra o de bisagra deslizante o giratoria las cuales montan o conectan pantallas de video u otros elementos al alojamiento principal donde reside el huésped y/o varios elementos de control y componentes de salida. Estos generalmente son interfaces de alto rendimiento o ancho de banda elevado. Es muy difícil construir interfaces de transferencia de datos de alto rendimiento utilizando técnicas previas las cuales requieren hasta 90 conductores, o más, para lograr el rendimiento deseado, se podría mencionar un teléfono inalámbrico como ejemplo. Las soluciones actuales típicamente involucran el empleo de interfaces tipo paralelo con niveles de señal relativamente elevados las cuales pueden ocasionar que la interconexión sea más costosa, menos confiable y que potencialmente genere emisiones radiadas las cuales podrían interferir con funciones del dispositivo. Esto presenta muchas cuestiones desafiantes a superar de fabricación, costo y confiabilidad. Dichas cuestiones y requerimientos también se están observando en instalaciones de ubicación fija en donde los dispositivos de comunicación o de tipo computadora, como un ejemplo, se agregan a aparatos y otros dispositivos del consumidor para proveer capacidades de datos avanzadas, conexiones de transferencia de datos e Internet, o entretenimiento integrado. Otro ejemplo podría ser aviones o autobuses en donde en los respaldos de los asientos se montan pantallas de presentación de video y audio individuales. Sin embargo, en estas situaciones con frecuencia es más conveniente, eficiente y práctico tener los elementos de almacenamiento principal, procesamiento o control de comunicación ubicados a una distancia de las pantallas visibles o de las salidas de audio con un enlace o canal de interconexión para la presentación de información. Este enlace necesitará manejar una cantidad importante de datos para lograr el rendimiento deseado, tal como se analizó anteriormente. Por lo tanto, se necesita un nuevo mecanismo de transferencia para aumentar la producción de datos entre los dispositivos huésped que proveen los datos y los dispositivos de pantalla del cliente o elementos que presentan una salida a los usuarios finales. Los solicitantes han propuesto dichos mecanismos de transferencia nuevos en la Solicitud de Patente EUA con número de serie 10/020,520, presentada el 14 de diciembre de 2001, ahora la Patente EUA número 6,760,772, emitida el 6 de julio de 2004 a Zou et al., y la Solicitud de Patente EUA con número de serie 10/236,657, presentada el 6 de septiembre de 2002, ambas tituladas "Generación y Ejecución de un Protocolo de Comunicación e Interfaz para Transferencia de Señal de Alta Velocidad de Datos", ambas cedidas al cesionario de la presente invención e incorporadas aquí por referencia. También, la Solicitud EÜA con número de serie 10/860,116, presentada el 2 de junio de 2004, titulada "Generación y Ejecución de un Protocolo de Señal e Interfaz para Velocidades de Datos Superiores". Las técnicas analizadas en esas solicitudes pueden mejorar tremendamente la velocidad de transferencia para cantidades grandes de datos en señales de datos de alta velocidad. Sin embargo, las demandas de velocidades de datos cada vez mayores, especialmente en lo que se refiere a presentaciones de video, siguen creciendo. Incluso con otros desarrollos en curso en la tecnología de señal de datos, sigue habiendo la necesidad de esforzarse por obtener velocidades 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 de desarrollar un mecanismo de transferencia, nuevo o mejorado el cual se requiere para incrementar la producción de datos entre los dispositivos huésped y del cliente.

SUMARIO DE LA INVENCIÓN El inconveniente anterior, así como otros existentes en las técnicas se corrigen a través de las modalidades de la invención, en donde se han desarrollado un nuevo medio de transferencia de datos y protocolo, método y mecanismo para transferir datos entre un dispositivo huésped y un dispositivo del cliente receptor a altas velocidades de datos. Las modalidades para la invención se enfocan en una Interfaz Digital de Datos Móviles (MDDI) para transferir datos digitales a una velocidad alta entre un dispositivo huésped y un dispositivo del cliente en una trayectoria de comunicación la cual emplea una pluralidad o serie de estructuras de paquete para formar un protocolo de comunicación para entablar comunicación con un conjunto preseleccionado de datos de presentación y control digital entre los dispositivos huésped y del cliente. El protocolo de comunicaciones de señal o capa de enlace es utilizado por una capa física de controladores, receptores o accionadores del enlace del cliente o huésped. Por lo menos un controlador de enlace o accionador que reside en el dispositivo huésped está acoplado al dispositivo del cliente a través de la trayectoria o enlace de comunicaciones, y está configurado 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. La interfaz provee transferencia bidireccional de información entre el huésped y el cliente, la cual puede residir dentro de un alojamiento global común o estructura de soporte. La ejecución generalmente es completamente digital en naturaleza con la excepción de accionadores y receptores diferenciales los cuales se pueden ejecutar fácilmente en un chip de Semiconductor Complementario de Oxido de Metal (CMOS) , requiere una cantidad por lo menos de 6 señales, y opera a casi cualquier velocidad de datos que resulte conveniente para el diseñador del sistema. El protocolo de capa de enlace y física simple hace fácil la integración, y esta simplicidad más un estado de hibernación permiten al sistema portátil tener un consumo de energía de sistema muy bajo. Para ayudar en el uso y aceptación, la interfaz agregará muy poco al costo de un dispositivo, permitirá el consumo de muy poca energía al mismo tiempo que podrá encender pantallas a través de la interfaz utilizando voltajes de batería estándar, y puede alojar dispositivos que tengan un factor forma de bolsillo. La interfaz se puede escalar para soportar resoluciones más allá de HDTV, soporta video estéreo simultáneo y audio 7.1 para un dispositivo de pantalla, ejecuta actualizaciones condicionales para cualquier región de pantalla y soporta múltiples tipos de datos en ambas direcciones. En aspectos adicionales de modalidades de la invención, por lo menos un controlador del enlace del cliente, receptor, dispositivo o accionador está colocado en el dispositivo del cliente y está acoplado al dispositivo huésped a través de la trayectoria o enlace de comunicaciones. El controlador del enlace del cliente también está configurado 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. Generalmente, el controlador de enlace o huésped emplea una máquina de estado para procesar paquetes de datos utilizados en comandos o ciertos tipos de preparación de señal y procesamiento de investigación, pero puede utilizar un procesador de propósito general más lento para manipular datos y algunos de los paquetes menos complejos utilizados en el protocolo de comunicación. El controlador huésped comprende uno o más accionadores de línea diferenciales; mientras que el receptor del cliente comprende uno o más receptores de línea diferenciales acoplados a la trayectoria de comunicación. Los paquetes son agrupados dentro de cuadros de medios que son comunicados entre los dispositivos huésped y del cliente con una longitud predefinida fija con un número predeterminado de paquetes que tienen diferentes longitudes variables. Cada uno de los paquetes comprende un campo de longitud de paquete, uno o más campos de datos de paquete, y un campo de chequeo de redundancia cíclica. Un Paquete de Encabezado de Sub-cuadro es transferido o colocado al inicio de las transferencias de otros paquetes desde el controlador de enlace huésped. Uno o más paquetes tipo Corriente de Video y paquetes tipo Corriente de Audio son utilizados por el protocolo de comunicaciones para transferir datos tipo video y datos tipo audio, respectivamente, desde el huésped al cliente en un enlace de avance para presentación a un usuario del dispositivo del cliente. Uno o más paquetes tipo Encapsulación de Enlace Inverso son utilizados por el protocolo de comunicaciones para transferir datos desde el dispositivo del cliente al controlador de enlace huésped. Estas transferencias, en algunas modalidades, incluyen la transferencia de datos desde el controlador interno que tiene por lo menos un dispositivo MDDI a pantallas de video internas. Otras modalidades incluyen transferencia a sistemas de sonido internos, y transferencias desde varios dispositivos de entrada incluyendo mandos y teclados complejos a dispositivos huésped internos. Los paquetes tipo relleno son generados por el controlador de enlace huésped para ocupar periodos de transmisión de enlace de avance que no tienen datos. El protocolo de comunicaciones utiliza una pluralidad de otros paquetes para transferir información de video. Dichos paquetes incluyen Mapa de Color, Transferencia de Bloque de Bits, Llenado de Área de Mapas de Bits, Llenado de Patrón de Mapas de Bits, y paquetes tipo Habilitación de Color Transparente. Los paquetes tipo Corriente Definida por el Usuario son utilizados por el protocolo de comunicaciones para transferir datos definidos por la interfaz-usuario. Los paquetes tipo Datos de Teclado y Datos de Dispositivo de Señalización son utilizados por el protocolo de comunicaciones para transferir datos a o desde los dispositivos de entrada de usuario asociados con dicho dispositivo del cliente. Un paquete tipo Apagado de Enlace es utilizado por el protocolo de comunicaciones para terminar la transferencia de datos en cualquier dirección sobre dicha trayectoria de comunicación. Los Paquetes de Estado de Energía de Pantalla son generados para proveer una estructura, medio o método para colocar el hardware del controlador de pantalla específico en un estado de baja energía cuando un cliente, tal como una pantalla, no está siendo utilizada o en uso activo actual, para reducir al mínimo el consumo de energía del sistema o drenaje de los recursos del sistema. En una modalidad, un cliente indica una habilidad para responder a los Paquetes de Estado de Energía de Pantalla utilizando el bit 9 de un campo de Indicadores de Capacidad de Característica del Cliente de un Paquete de Capacidad del Cliente. El formato de una modalidad para un Paquete de Estado de Energía de Pantalla, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Estado de Energía, y Chequeo de Redundancia Cíclica (CRC) . Este tipo de paquete generalmente se identifica como un paquete Tipo 75 en el campo tipo de 2 bytes. El campo ID de hCliente de 2 bytes contiene información o valores que son reservados para una ID de Cliente. El campo de Estado de Energía, especifica la información utilizada para colocar una pantalla específica en el estado de energía especificado de acuerdo con el valor de algunos bits preseleccionados. Un campo CRC de 2 bytes especifica o contiene el CRC de todos los bytes en el paquete, incluyendo la Longitud de Paquete. La trayectoria de comunicación generalmente comprende o emplea un cable que tiene una serie de cuatro o más conductores y un revestimiento. Además, se pueden utilizar cables o conductores impresos, según se desee, en donde algunos residen en substratos flexibles. El controlador de enlace huésped solicita información de las capacidades de pantalla del dispositivo del cliente para determinar qué tipo de datos y velocidades de datos dicho cliente es capaz de permitir a través de dicha interfaz. El controlador de enlace del cliente comunica capacidades de pantalla o presentación al controlador de enlace huésped utilizando por lo menos un paquete tipo Capacidad del Cliente. El protocolo de comunicaciones utiliza múltiples modos de transferencia, en donde cada uno permite la transferencia de diferentes números máximos de bits de datos en paralelo durante un periodo de tiempo determinado, en donde cada modo es seleccionado por negociación entre los controladores de enlace huésped y del cliente. Estos modos de transferencia son dinámicamente ajustables durante la transferencia de datos, y no se tiene que utilizar el mismo modo en el enlace inverso tal como se utiliza en el enlace de 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 tiene un módem inalámbrico colocado en la misma. Un dispositivo de cliente típico comprende una pantalla de video portátil tal como un dispositivo de micro-pantalla, y/o un sistema de presentación de audio portátil. Además, el huésped puede utilizar medios de almacenamiento o elementos para almacenar los datos de multimedia o presentación que se van a transferir para ser presentados a un usuario del dispositivo del cliente. En otros aspectos todavía de algunas modalidades, el dispositivo huésped comprende un controlador o dispositivo de control de enlace de comunicación con accionadores, tal como se describe a continuación, que residen dentro de un dispositivo electrónico portátil tal como un dispositivo de comunicaciones inalámbrico, tal como un teléfono inalámbrico, un PDA inalámbrico, o una computadora portátil. Un dispositivo de cliente típico, en esta configuración, comprende un circuito de cliente o circuito integrado o módulo acoplado al huésped y que reside dentro del mismo dispositivo, y a una pantalla de video interna tal como una pantalla de alta resolución para un teléfono móvil y/o un sistema de presentación de audio portátil, o en la alternativa, algún tipo de sistema o dispositivo de entrada.

BREVE DESCRIPCIÓN DE LAS FIGURAS Características y ventajas adicionales, así como la estructura y operación de varias modalidades de la invención, se describen con detalle a continuación con referencia a las figuras anexas. En las figuras, números de referencia similares generalmente indican elementos o pasos de procesamiento idénticos, funcionalmente similares y/o estructuralmente similares. La figura ÍA ilustra un ambiente básico en el que modalidades de la invención podrían operar incluyendo el uso de un dispositivo de micro-pantalla, o un proyector, junto con una computadora portátil u otro dispositivo de procesamiento de datos. La figura IB ilustra un ambiente básico en el que modalidades de la invención podrían operar incluyendo el uso de un dispositivo de micro-pantalla, o un proyector, y elementos de presentación de audio utilizados junto con un transceptor inalámbrico. La figura 2A ilustra un ambiente básico en el que modalidades de la invención podrían operar incluyendo el uso de dispositivos de presentación de audio o pantalla interna utilizados en una computadora portátil. La figura 2B ilustra un ambiente básico en el que modalidades de la invención podrían operar incluyendo el uso de elementos de presentación de audio o pantalla interna utilizados en un transceptor inalámbrico. La figura 3 ilustra el concepto general de una MDDI con una interconexión de huésped y cliente. La figura 4 ilustra la estructura de un paquete útil para ejecutar las transferencias de datos desde un dispositivo del cliente a un dispositivo huésped. La figura 5 ilustra el uso de un controlador de enlace MDDI y los tipos de señales que pasan entre un huésped y un cliente en los conductores de enlace de datos físicos para una interfaz tipo 1. La figura 6 ilustra el uso de un controlador de enlace MDDI y los tipos de señales que pasan entre un huésped y un cliente en los conductores de enlace de datos físicos para interfaces tipo 2, 3 y 4. La figura 7 ilustra una estructura de cuadros y sub-cuadros utilizados para ejecutar el protocolo de interfaz. La figura 8 ilustra la estructura general de paquetes utilizados para ejecutar el protocolo de interfaz. La figura 9 ilustra el formato de un Paquete de Encabezado de Sub-cuadro. La figura 10 ilustra el formato y contenido de un Paquete de Relleno. La figura 11 ilustra el formato de un Paquete de Corriente de Video. Las figuras 12A-12E ilustran el formato y contenido para el Descriptor de Formato de Datos de Video utilizado en la figura 11. La figura 13 ilustra el uso de formatos empacados y desempacados para datos.

La figura 14 ilustra el formato de un Paquete de Corriente de Audio. La figura 15 ilustra el uso de formatos PCM empacados y de bytes alineados para datos. La figura 16 ilustra el formato de un Paquete de Corriente Definido por el Usuario. La figura 17 ilustra el formato de un Paquete de Mapa de Color. La figura 18 ilustra el formato de un Paquete de Encapsulación de Enlace Inverso. La figura 19 ilustra el formato de un Paquete de Capacidades del Cliente. La figura 20 ilustra el formato de un Paquete de Datos de Teclado. La figura 21 ilustra el formato de un Paquete de Datos de Dispositivo de Señalización. La figura 22 ilustra el formato de un Paquete de Apagado de Enlace. La figura 23 ilustra el formato de un Paquete de Solicitud y Estado del Cliente. La figura 24 ilustra el formato de un Paquete de Transferencia de Bloque de Mapa de Bits. La figura 25 ilustra el formato de un Paquete de Relleno de Área de Mapa de Bits. La figura 26 ilustra el formato de un Paquete de Relleno de Patrón de Mapa de Bits. La figura 27 ilustra el formato de un Paquete de Memoria Intermedia de Cuadro de Lectura. La figura 28 ilustra el formato de un Paquete de Estado de Energía de Pantalla. La figura 29 ilustra el formato de un Paquete de Transferencia de Tipo Ejecución. La figura 30 ilustra el formato de un Paquete de Habilitación de Canal de Audio de Avance. La figura 31 ilustra el formato de un Paquete de Velocidad de Muestra de Audio Inverso. La figura 32 ilustra el formato de un Paquete de Sobrecarga 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 temporización de eventos durante el Paquete de Medición de Retraso de Viaje Redondo. La figura 36 ilustra una ejecución de muestra de un generador y comprobador CRC útil para ejecutar la invención. La figura 37A ilustra la temporización de señales CRC para el aparato de la figura 36 cuando se envían paquetes de datos.

La figura 37B ilustra la temporización de señales CRC para el aparato de la figura 36 cuando se reciben paquetes de datos. La figura 38 ilustra pasos de procesamiento para una solicitud de servicio típica sin contención. La figura 39 ilustra pasos de procesamiento para una solicitud de servicio típica impuesta después que ha comenzado la secuencia de reinicio de enlace, enfrentándose al inicio de enlace. La figura 40 ilustra la forma en que una secuencia de datos puede ser transmitida utilizando codificación DATOS-STB. La figura 41 ilustra circuitería útil para generar las señales de DATOS y STB a partir de datos de entrada en el huésped, y después recuperando los datos en el cliente. La figura 42 ilustra accionadores y resistencias de terminación útiles para la ejecución de una modalidad. Las figuras 43A-43C ilustran pasos y niveles de señal empleados por un cliente para asegurar el servicio proveniente del huésped y a través del huésped proveer dicho servicio. La figura 44 ilustra separación relativa entre transiciones en los DatosO, otras líneas 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 accionador de huésped después de la transferencia de un paquete. La figura 46 ilustra la presencia de un retraso en respuesta que puede ocurrir cuando un huésped habilita el accionador de huésped para transferir un paquete. La figura 47 ilustra el análisis de la corriente de fuga. La figura 48 ilustra las características de conmutación y las relaciones de temporización relativas para el tiempo de habilitación e inhabilitación de salida del huésped y cliente. La figura 49 ilustra un diagrama de alto nivel de pasos y condiciones de procesamiento de señales a través de los cuales la sincronización se puede ejecutar utilizando una máquina de estado. La figura 50 ilustra cantidades típicas de retraso encontradas para el procesamiento de señal en las trayectorias de avance e inversa en un sistema que emplea la MDDI. La figura 51 ilustra la medición del retraso de viaje redondo marginal. La figura 52A ilustra los cambios de velocidad de datos del Enlace Inverso.

La figura 52B ilustra un ejemplo de muestreo de datos inverso avanzado. La figura 53 ilustra una representación gráfica de valores del Divisor de Velocidad Inversa contra la velocidad de datos del enlace de avance. Las figuras 54A y 54B ilustran pasos emprendidos en la operación de una interfaz. La figura 55 ilustra una perspectiva general del aparato de interfaz que procesa los paquetes. La figura 56 ilustra el formato de un Paquete de Enlace de Avance. La figura 57 ilustra valores típicos para el retraso de propagación y sesgo en una interfaz de Enlace Tipo 1. La figura 58 ilustra Datos, Stb, y Temporización de Recuperación de Sincronía en un Enlace de Tipo 1 para procesamiento de señal ejemplar a través de la interfaz. La figura 59 ilustra valores típicos para el retraso de propagación y sesgo en interfaces de Enlace Tipo 2, Tipo 3 o Tipo 4. Las figuras 60A, 60B y 60C ilustran diferentes posibilidades para la temporización de dos señales de datos y MDDI_Stb con respecto entre sí, siendo ideal, temprana y posterior, respectivamente. La figura 61 ilustra conectores ejemplares de asignaciones de borne de interfaz que se utilizan con una interfaz Tipo-I/Tipo 2. .Las figuras 62A y 62B ilustran formas de onda posibles MDDI_Datos y MDDI_Stb para las interfaces Tipo 1 y Tipo 2, respectivamente. La figura 63 ilustra un diagrama de alto nivel de condiciones y pasos alternativos de procesamiento de señales a través de los cuales la sincronización se puede ejecutar utilizando una máquina de estado. La figura 64 ilustra temporización relativa ejemplar entre una serie de ciclos de sincronía y la temporización de varios bits de paquetes de enlace inverso y valores de divisor. La figura 65 ilustra el procesamiento de transferencia de código de error ejemplar. 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 sobrecarga de código. La figura 67B ilustra el procesamiento de transferencia de código de error para recepción de código. La figura 68A ilustra pasos de procesamiento para la activación iniciada de un huésped. La figura 68B ilustra pasos de procesamiento para la activación iniciada de un cliente.

La figura 68C ilustra pasos de procesamiento para la activación iniciada de huésped y cliente con contención. La figura 69 ilustra el formato de un Paquete de Funciones de Panel de Control Virtual de Solicitud (VCP) . La figura 70 ilustra el formato de un Paquete de Respuesta de Función VCP. La figura 71 ilustra el formato de una Lista de Respuesta de Función VCP. La figura 72 ilustra el formato de un Paquete de Función VCP Establecido. La figura 73 ilustra el formato de un Paquete de Parámetro Válido de Solicitud. La figura 74 ilustra el formato de un Paquete de Respuesta de Parámetro Válido. La figura 75 ilustra el formato de un Paquete de Capacidad de Corriente de Video Escalado. La figura 76 ilustra el formato de un Paquete Configurado de Corriente de Video Escalado. La figura 77 ilustra el formato de un Paquete de Reconocimiento de Corriente de Video Escalado. La figura 78 ilustra el formato de un Paquete de Corriente de Video Escalado. 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 81 ilustra el formato de un Paquete de Capacidad de Pantalla Personal. La figura 82 ilustra elementos en los Puntos de la Lista de Curvatura de Campo. La figura 83 ilustra el formato de un Paquete de Reporte de Error de Cliente. La figura 84 ilustra el formato de un artículo de la 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 intermedias de pantalla para reducir los artefactos visibles. La figura 89 ilustra dos memorias intermedias con actualización de pantalla más rápida que la transferencia de imágenes . La figura 90 ilustra dos memorias intermedias con actualización de pantalla más lenta que la transferencia de imágenes . La figura 91 ilustra dos memorias intermedias con actualización de pantalla mucho más rápida que la transferencia de imágenes. La figura 92 ilustra tres memorias intermedias con actualización de pantalla más rápida que la transferencia de imágenes. La figura 93 ilustra tres memorias intermedias con actualización de pantalla más lenta que la transferencia de imágenes. La figura 94 ilustra una memoria intermedia con actualización de pantalla más rápida que la transferencia de imágenes . La figura 95 ilustra la conexión huésped-cliente a través de una cadena de margarita y una terminal . La figura 96 ilustra los dispositivos del cliente conectados a través de una combinación de terminales y cadenas de margarita. La figura 97 ilustra un mapa de color.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN I. Perspectiva general Un intento general de la invención es proveer una MDDI, tal como se analiza a continuación, lo cual produce como resultado o provee un mecanismo de transferencia, de costo efectivo, con bajo consumo de energía que permite la transferencia de datos de alta velocidad o muy alta velocidad en un enlace de comunicación de corto rango entre un dispositivo huésped y un dispositivo del cliente, tal como un elemento de pantalla, utilizando un tipo "en serie" de canal o enlace de datos. Este mecanismo conduce a su ejecución con conectores miniatura y cables flexibles delgados los cuales son especialmente útiles para conectar una pantalla interna (dentro de un alojamiento o armazón de soporte) o elementos o dispositivos de salida, o dispositivos de entrada a un controlador central o elemento o dispositivo de comunicación. Además, este mecanismo de conexión es muy útil para conectar elementos de pantalla externos o dispositivos tales como micro-pantallas portátiles (gafas o proyectores) u otros tipos de dispositivos de presentación de información visual, audible, táctil a computadoras portátiles, dispositivos de comunicación inalámbrica, o dispositivos de entretenimiento . Aunque los términos Móvil y Pantalla se asocian con el nombre del protocolo, se entenderá que esto es para conveniencia únicamente en términos de tener un nombre estándar fácilmente entendido por aquellos expertos en la técnica que trabajan con la interfaz y protocolo. Ya que se relaciona con un estándar de la Asociación de Estándares Electrónicos de Video (VESA) y varias aplicaciones de ese estándar. Sin embargo, se entenderá fácilmente, después de una revisión de las modalidades presentadas a continuación, que muchas aplicaciones relacionadas que no son móviles y sin pantalla se beneficiarán de la aplicación de este protocolo, dando como resultado una estructura de interfaz, o mecanismo de transferencia, y la etiqueta MDDI no pretende implicar limitaciones 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 provee una técnica para la transferencia de datos que es baja en complejidad, baja en costo, tiene alta confiabilidad, se ajusta bien dentro del ambiente de uso, y es muy robusta, al mismo tiempo que sigue siendo muy flexible . Modalidades de la invención se pueden utilizar en una variedad de situaciones para comunicar o transferir grandes cantidades de datos, generalmente para aplicaciones de audio, video o multimedia desde un dispositivo fuente o huésped, en donde dichos datos son generados, manipulados, tal como para transferencia a dispositivos específicos, o de otra forma, procesados o almacenados; para un dispositivo de recepción o de cliente, tal como una pantalla de video o elemento de proyección, altavoces de audio, u otro dispositivo de presentación a alta velocidad. Una aplicación típica, la cual se analiza a continuación, es la transferencia de datos desde una computadora portátil o un teléfono o módem inalámbrico a un dispositivo de pantalla visual, tal como una pantalla de video pequeña o un aparato de micro-pantalla portátil, tal como en la forma de gafas o cascos que contienen lentes y pantallas de pequeña proyección, o desde un huésped a un dispositivo de cliente dentro de dichos componentes. Es decir, desde un procesador o controlador a una pantalla interna u otro elemento de presentación, así como desde varios dispositivos de entrada internos o externos que emplean un cliente a un huésped internamente ubicado (colocado dentro del mismo alojamiento o estructura de soporte del dispositivo) , o conectado al mismo por medio de un cable o conductores . Las características o atributos de la MDDI son tales que, son independientes de la pantalla específica o tecnología de presentación. Este es un mecanismo altamente flexible para transferir datos a una alta velocidad sin considerar la estructura interna de esos datos o de los aspectos funcionales de los datos o comandos que ejecuta. Esto permite la temporización de paquetes de datos que se están transfiriendo para ser ajustados de manera que se adapten a las idiosincrasias de dispositivos de cliente particulares, tal como para deseos de despliegue único para ciertos dispositivos, o para cumplir con los requerimientos de audio y video combinados para algunos sistemas Audio Visuales (A-V) , o para algunos dispositivos de entrada tal como mandos, almohadillas de tacto, y así sucesivamente. La interfaz es un elemento de pantalla o agnóstico del dispositivo del cliente, siempre y cuando se siga el protocolo seleccionado. Además, los datos de enlace en serie agregados, o velocidad de datos, pueden variar en varios órdenes de magnitud lo cual permite a un diseñador del sistema de comunicación o dispositivo huésped optimizar el costo, los requerimientos de energía, la complejidad del dispositivo del cliente, y las velocidades de actualización del dispositivo del cliente. La interfaz de datos se presenta principalmente para uso en la transferencia de grandes cantidades de datos de alta velocidad en un enlace de señal "cableado" o cable pequeño. Sin embargo, algunas aplicaciones también pueden sacar provecho de un enlace inalámbrico, incluyendo enlaces basados en óptica, siempre y cuando esté configurado para utilizar las mismas estructuras de datos y paquete desarrolladas para el protocolo de interfaz, y pueda sostener el nivel deseado de transferencia a un nivel de consumo de energía lo suficientemente bajo o complejidad para que siga siendo práctico.

II. Ambiente En las figuras 1A y IB se puede apreciar una aplicación típica en donde una computadora portátil o laptop 100 y un teléfono inalámbrico o dispositivo PDA 102 se muestran comunicando datos con dispositivos de pantalla 104 y 106, respectivamente, junto con sistemas de reproducción de audio 108 y 112. Además, la figura ÍA muestra conexiones potenciales con un despliegue o pantalla más grande 114 o un proyector de imágenes 116, los cuales solo se muestran en una figura para claridad, pero también se pueden conectar al dispositivo inalámbrico 102. El dispositivo inalámbrico puede estar recibiendo datos actualmente o tener una cierta cantidad de datos tipo multimedia previamente almacenados en un elemento o dispositivo de memoria para presentación posterior y poder ser visto y/o escuchado por un usuario final del dispositivo inalámbrico. Debido a que un dispositivo inalámbrico típico se utiliza para comunicaciones de texto simple y voz, la mayor parte del tiempo, éste tiene una pantalla de despliegue más bien pequeña y sistema de audio simple (altavoces) para comunicar información al usuario del dispositivo 102. La computadora 100 tiene una pantalla mucho más grande, pero sigue siendo un sistema de sonido externo inadecuado, y sigue estando muy por debajo de otros dispositivos de presentación de multimedia tal como una televisión de alta definición, o pantallas de cine. La computadora 100 se utiliza para propósitos de ilustración y otros tipos de procesadores, juegos de video interactivos, o dispositivos electrónicos del consumidor también se pueden utilizar con la invención. La computadora 100 puede emplear, pero no se limita a, un módem inalámbrico u otro dispositivo incorporado para comunicaciones inalámbricas, o que esté conectado a dichos dispositivos utilizando un enlace inalámbrico o cable, según se desee. Esto hace que la presentación de datos más complejos o "ricos" sea menos que una experiencia útil o placentera. Por lo tanto, la industria está desarrollando otros mecanismos y dispositivos para presentar la información a los usuarios finales y proveer un nivel mínimo de placer deseado o experiencia positiva. Tal como se analizó anteriormente, varios tipos de dispositivos de pantalla han sido o están siendo actualmente desarrollados para presentar información a los usuarios finales del dispositivo 100. Por ejemplo, una o más compañías han desarrollado conjuntos de gafas portátiles que proyectan una imagen en frente de los ojos de un usuario del dispositivo para presentar una pantalla visual. Cuando están colocados correctamente, dichos dispositivos "proyectan" de manera efectiva una imagen virtual, tal como es percibida por los ojos de un usuario, la cual es mucho más grande que el elemento que provee la salida visual. Es decir, un elemento de proyección muy pequeño permite que los ojos de un usuario "vean" imágenes en una escala mucho más grande de lo que resulta posible con las Pantallas de Cristal Líquido típicas (LCD) y similares. El uso de imágenes más grandes de pantalla virtual también permite el uso de imágenes con una resolución más elevada de lo que resulta posible con pantallas LCD más limitadas. Otros dispositivos de despliegue podrían incluir, pero no se limitan a, pantallas LCD pequeñas o varios elementos de pantalla de panel plano, lentes de proyección y accionadores de pantalla para proyectar imágenes en una superficie, y así sucesivamente. También puede haber elementos adicionales conectados a, o asociados con el uso del dispositivo inalámbrico 102 o la computadora 100 para presentar una salida a otro usuario, o a otro dispositivo el cual, a su vez, transfiere las señales a otra parte o las almacena. Por ejemplo, los datos se pueden almacenar en memoria instantánea, en forma óptica, por ejemplo, utilizando un medio de CD en el que se puede escribir o en un medio magnético tal como una grabadora de cinta magnética y dispositivos similares, para uso posterior. Además, muchos dispositivos inalámbricos y computadoras ahora tienen capacidades de decodificación de música MP3 incorporadas, así como otros sistemas y decodificadores de sonido avanzados. Las computadoras portátiles utilizan capacidades de reproducción de CD o DVD como regla general, y algunas tienen pequeñas lectoras de memoria instantánea dedicada para recibir archivos de audio previamente grabados . El problema con tener dichas capacidades es que, los archivos de música digital prometen una experiencia rica en función altamente incrementada, pero solo si el proceso de decodificación y reproducción puede mantener el ritmo. Lo mismo aplica para los archivos de video digital. Para ayudar con la reproducción de sonido, en la figura 1A se muestran altavoces externos 114, los cuales también podrían estar acompañados por elementos de adición tal como bafle de bajos, o altavoces de "sonido-ambiental" para proyección de sonido frontal y posterior. Al mismo tiempo, los altavoces o audífonos 108 se indican como integrados al armazón de soporte o mecanismo del dispositivo de micro-pantalla 106 de la figura IB. Tal como se debería saber, se pueden utilizar otros elementos de reproducción de audio o sonido, incluyendo dispositivos de configuración de sonido o amplificación de potencia. En cualquier caso, tal como se analizó anteriormente, cuando se desea transferir datos de imagen de alta resolución o alta calidad e información de audio de alta calidad o señales de datos provenientes de una fuente de datos a un usuario final en uno o más enlaces de comunicación 110, se requiere una alta velocidad de datos. Es decir, el enlace de transferencia 110 es claramente un cuello de botella potencial en la comunicación de datos, tal como se analizó anteriormente, y está limitando el rendimiento del sistema debido a que los mecanismos de transferencia actuales no logran las altas velocidades de datos típicamente deseadas. Como se analizó anteriormente por ejemplo, para resoluciones superiores de imagen tal como 1024 x 1024 píxeles, con profundidades de color de 24-32 bits por píxel, y a velocidades de datos de 30 fps, las velocidades de datos pueden acercarse a las velocidades en exceso de 755 Mbps o más. Además, dichas imágenes se pueden presentar como parte de una presentación de multimedia la cual incluye datos de audio y señales potencialmente adicionales que se relacionan con comunicaciones o juegos interactivos, o varios comandos, controles o señales, aumentando adicionalmente la cantidad o datos y la velocidad de datos. También es claro que menos cables o interconexiones requeridas para establecer un enlace de datos, significa que los dispositivos móviles asociados con una pantalla son más fáciles de utilizar y que, con mayor probabilidad, serán adoptados por una base de usuarios más grande. Esto es especialmente cierto en los casos donde múltiples dispositivos se utilizan de forma común para establecer una experiencia audio-visual completa, y muy especialmente, conforme incrementa el nivel de calidad de las pantallas y los dispositivos de salida de audio. Otra aplicación típica relacionada con muchas de las mejoras anteriores así como otras en las pantallas de video y otros dispositivos de entrada o salida, se puede apreciar en las figuras 1C y ID en donde una computadora portátil o laptop 130 y teléfono inalámbrico o dispositivo PDA 140 se muestran comunicando datos con dispositivos de pantalla "internos" 134 y 144, respectivamente, junto con sistemas de reproducción de audio 136 y 146. En las figuras 2A y 2B, pequeñas secciones en corte de los dispositivos electrónicos globales o productos se utilizan para mostrar la ubicación de uno o más huéspedes y controladores internos en una porción del dispositivo con un enlace de comunicación generalizado, aquí 138 y 148, respectivamente, conectándolos a los elementos de despliegue de video o pantallas que tienen los clientes correspondientes, a través de una junta giratoria de cierto tipo conocido que se emplea en la industria de electrónicos hoy en día. Se puede apreciar que la cantidad de datos involucrada en estas transferencias requiere un número grande de conductores para comprender los enlaces 138 y 148. Se estima que dichos enlaces de comunicación se están aproximando a 90 o más conductores para satisfacer las crecientes necesidades actuales de utilizar interfaces gráficas y de color avanzadas, elementos de pantalla, en dichos dispositivos debido a los tipos de técnicas de interfaz paralela u otras técnicas de interfaz conocidas disponibles para transferir dichos datos. Infortunadamente, las velocidades de datos superiores exceden la tecnología actual disponible para transferir datos. Tanto en términos de la cantidad de datos sin procesar que necesita ser transferida por tiempo de unidad, como en términos de fabricación de mecanismos de transferencia física de costo efectivo y confiables. Lo que se necesita es una técnica, una estructura, medio o método para transferir datos a velocidades superiores para el enlace de transferencia de datos o trayectoria de comunicación entre elementos de presentación y la fuente de datos, lo cual permita una estructura de cableado consistentemente de baja energía (o menor) , de peso ligero, y tan simple y económica como sea posible. Los solicitantes han desarrollado una nueva técnica, o método y aparato, para lograr estos y otros objetivos para permitir que una disposición de dispositivos de ubicación móvil, portátil o incluso fija transfiera datos a pantallas deseadas, micro-pantallas, o elementos de transferencia de audio, a velocidades de datos muy altas, mientras se mantiene un bajo consumo de energía deseado, y complejidad.

III. Arquitectura del sistema de interfaz de datos digitales de alta velocidad Para crear y utilizar de manera eficiente una nueva interfaz de dispositivo, se ha creado una arquitectura de sistema y protocolo de señal que provee una velocidad de transferencia de datos muy alta utilizando señales de baja energía. El protocolo se basa en una estructura de paquete y cuadro común, o estructuras enlazadas entre sí para formar un protocolo para comunicar un conjunto preseleccionado de datos o tipos de datos junto con un comando o estructura operativa impuesta en la interfaz .

A. Perspectiva general Los dispositivos conectados a través de, o gue se comunican en el enlace MDDI se denominan el huésped y el cliente, en donde el cliente típicamente es un dispositivo de pantalla de cierto tipo, aunque se contemplan otros dispositivos de salida y entrada. Los datos del huésped a la pantalla se desplazan en la dirección de avance (denominado como tráfico o enlace de avance) , y los datos del cliente al huésped se desplazan en la dirección inversa (tráfico o enlace inverso) , conforme a lo permitido por el huésped. Esto se ilustra en la configuración básica que se muestra en la figura 3. En la figura 3, un huésped 202 está conectado a un cliente 204 utilizando un canal de comunicación bi-direccional 206 el cual se ilustra con un enlace de avance 208 y un enlace inverso 210. Sin embargo estos canales se forman por un conjunto común de conductores cuya transferencia de datos es conmutada de manera efectiva entre las operaciones de enlace de avance o inverso. Esto permite un número tremendamente reducido de conductores, corrigiendo inmediatamente uno de los muchos problemas que se presentan con los enfoques actuales para la transferencia de datos de alta velocidad en ambientes de baja energía tal como dispositivos electrónicos móviles. Como se analiza en otro apartado, el huésped comprende uno de varios tipos de dispositivos que se pueden beneficiar del uso de la presente invención. Por ejemplo, el huésped 202 podría ser una computadora portátil en la forma de un dispositivo de cómputo manual, tipo laptop, o móvil similar. También podría ser un PDA, un dispositivo de localización, o cualquiera de muchos teléfonos o módems inalámbricos. Alternativamente, el huésped 202 podría ser un dispositivo de presentación o entretenimiento portátil tal como un reproductor de DVD o CD portátil, o un dispositivo 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 planeados o ampliamente utilizados para los que se desea un enlace de comunicación de alta velocidad con un cliente. Por ejemplo, un huésped se podría utilizar para transferir datos a altas velocidades desde un dispositivo de grabación de video a un cliente basado en almacenamiento para una respuesta mejorada, o a una pantalla más grande de alta resolución para presentaciones. Un aparato, tal como un refrigerador que incorpora en el mismo un sistema de cómputo o inventario y/o conexiones Bluetooth para otros dispositivos de casa, puede tener capacidades de pantalla mejoradas cuando se opera en un modo conectado Bluetooth o Internet, o puede tener necesidades de cableado reducido para las pantallas en-la-puerta (un cliente) y teclados o exploradores (cliente) mientras la computadora electrónica o sistemas de control (huésped) residen en alguna otra parte en el gabinete. En general, aquellos expertos en la técnica apreciarán la amplia variedad de dispositivos electrónicos modernos y aparatos que se pueden beneficiar del uso de esta interfaz, así como la habilidad para actualizar dispositivos anteriores con transporte de información de velocidad de datos superior utilizando números limitados de conductores disponibles en conectores o cables existentes o recientemente agregados. Al mismo tiempo, el cliente 204 podría comprender una variedad de dispositivos útiles para la presentación de información a un usuario final, o la presentación de información desde un usuario al huésped. Por ejemplo, una micro-pantalla incorporada en gafas o anteojos, un dispositivo de proyección incorporado en un sombrero o casco, una pantalla pequeña o incluso un elemento holográfico incorporado en un vehículo, tal como una ventana o parabrisas, o varios altavoces, auriculares, o sistemas de sonido para presentación de sonido o música de alta calidad. Otros dispositivos de presentación incluyen proyectores o dispositivos de proyección empleados para presentar información para reuniones, o para cines e imágenes de televisión. Otro ejemplo sería el uso de almohadillas de tacto o dispositivos sensibles, dispositivos de entrada de reconocimiento de voz, exploradores de seguridad, y así sucesivamente, a los cuales se puede recurrir para transferir una cantidad de información importante desde un dispositivo o usuario del sistema con poca "entrada" real que no sea tacto o sonido por parte del usuario. Además, las estaciones de acoplamiento para computadoras y equipos de vehículo o equipos de escritorio y sujetadores para teléfonos inalámbricos pueden actuar como dispositivos de interfaz para los usuarios finales o para otros dispositivos y equipo, y emplean ya sea clientes (dispositivos de salida o entrada, tal como un ratón) o huéspedes para ayudar en la transferencia de datos, especialmente en los casos donde están involucradas redes de alta velocidad. Sin embargo, aquellos expertos en la técnica reconocerán fácilmente que la presente invención no se limita a estos dispositivo, habiendo muchos otros dispositivos en el mercado, y propuestos para uso, que están destinados a proveer a los usuarios finales imágenes y sonido de alta calidad, ya sea en términos de almacenamiento y transporte o en términos de presentación en una reproducción. La presente invención es útil para aumentar el rendimiento de datos entre varios elementos o dispositivos para permitir las altas velocidades de datos necesarias para producir la experiencia de usuario deseada. El protocolo de señal de comunicación y MDDI inventivo se puede utilizar 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 alojamiento o estructura de dispositivo (denominado como un modo interno) para reducir el costo o complejidad y los requerimientos de control y energía asociados o restricciones de estas conexiones, y para mejorar la confiabilidad, no solo para la conexión con elementos externos, dispositivos o equipo (denominado como un modo externo) . La velocidad de datos de enlace en serie agregada en cada par de señales utilizado por esta estructura de interfaz puede variar en muchos órdenes de magnitud, lo cual permite a un diseñador de sistema o dispositivo optimizar fácilmente el costo, la energía, la complejidad de ejecución, y la velocidad de actualización de pantalla para una aplicación o propósito determinado. Los atributos de MDDI son independientes de la pantalla u otra tecnología de dispositivo de presentación (cliente objetivo) . La temporización de los paquetes de datos transferidos a través de la interfaz se puede ajustar fácilmente para que se adapte a las idiosincrasias de clientes particulares tal como dispositivos de pantalla, sistemas de sonido, elementos de control y memoria, o requerimientos de temporización combinados de sistemas de audio-video. Aunque esto hace posible tener un sistema con un consumo de energía muy pequeño, no es un requerimiento de los diversos clientes tener memorias intermedias de cuadro para hacer uso del protocolo MDDI por lo menos a cierto nivel.

B. Tipos de interfaz La MDDI se contempla para direccionar por lo menos cuatro, y potencialmente más, tipos de interfaces físicas de cierta forma distintas encontradas en las industrias de cómputo y comunicaciones . Estas simplemente se etiquetan como Tipo 1, Tipo 2, Tipo 3, y Tipo 4 aunque aquellos expertos en la técnica pueden aplicar otras etiquetas o designaciones dependiendo de las aplicaciones específicas para las que se utilizan o la industria con la que están asociadas. Por ejemplo, los sistemas de audio simples utilizan menos conexiones que sistemas de multimedia más complejos, y pueden hacer referencia a características tales como "canales" de manera diferente, y así sucesivamente. La interfaz Tipo 1 está configurada como un conductor de 6 cables u otro tipo de conductor o elemento conductor, interfaz que se vuelve adecuada para teléfonos móviles o inalámbricos, PDA, juegos electrónicos, y reproductores de medios portátiles, tal como reproductores de CD, o reproductores de MP3, y dispositivos similares o dispositivos utilizados en tipos similares de tecnología electrónica de consumidor. En una modalidad, una interfaz puede estar configurada como una interfaz (conductor) de 8 cables la cual es más conveniente para computadora portátil, computadora tipo agenda, o computadoras personales de escritorio y dispositivos o aplicaciones similares, que no requieren actualizaciones de datos rápidas y que no tienen un controlador de enlace MDDI incorporado. Este tipo de interfaz también se distingue por el uso de una interfaz de Enlace Serial Universal (USB) de dos cables adicional, la cual es extremadamente útil para alojar sistemas operativos existentes o soporte de software encontrado en la mayoría de las computadoras personales. Las interfaces Tipo 2, Tipo 3 y Tipo 4 son convenientes para clientes o dispositivos de alto rendimiento y utilizan cableado más complejo y más largo con conductores tipo par trenzado adicionales para proveer el revestimiento apropiado y transferencias de baja pérdida para señales de datos. La interfaz Tipo 1 pasa señales que pueden comprender información de despliegue, audio, control y señalización limitada, y típicamente se utiliza para clientes móviles o dispositivos de cliente que no requieren datos de video de alta resolución y completa velocidad. Una interfaz Tipo 1 puede fácilmente soportar resolución de Arreglo de Gráficos de Súper Video (SVGA) a 30 fps más audio de canal 5.1, y en una configuración mínima podría utilizar únicamente tres pares de cables en total, dos pares para transmisión de datos y un par para transferencia de energía. Este tipo de interfaz se destina principalmente para dispositivos, tal como dispositivos inalámbricos móviles, en donde un huésped USB típicamente no está disponible dentro de dicho dispositivo para conexión y transferencia de señales. En esta configuración, el dispositivo inalámbrico móvil es un dispositivo huésped MDDI, y actúa como la "terminal maestra" que controla el enlace de comunicación del huésped, el cual generalmente envía datos al cliente (tráfico o enlace de avance) para presentación, despliegue o reproducción. En esta interfaz, un huésped habilita la recepción de datos de comunicación en el huésped provenientes del cliente (tráfico o enlace inverso) enviando un comando especial o tipo de paquete al cliente que le permite tomar control del conector (enlace) por una duración especificada y enviar datos al huésped como paquetes inversos. Esto se ilustra en la figura 4, en donde un tipo de paquete denominado como un paquete de encapsulación (que se analiza a continuación) se utiliza para permitir la transferencia de paquetes inversos en el enlace de transferencia, creando el enlace inverso. El intervalo de tiempo asignado para que el huésped pregunte al cliente por los datos es predeterminado por el huésped, y se basa en los requerimientos de cada aplicación especificada. Este tipo de transferencia de datos bi-direccional medio dúplex es especialmente conveniente en los casos donde un puerto USB no está disponible para transferencia de información o datos desde el cliente. Las pantallas de alto rendimiento que tienen la capacidad para resoluciones tipo HDTV o altas resoluciones similares, requieren corrientes de datos de velocidad de alrededor de 1.5 Gbps para soportar el video de secuencia completa. La interfaz Tipo 2 soporta velocidades altas de datos transmitiendo 2 bits en paralelo, el Tipo 3 transmitiendo 4 bits en paralelo, y la interfaz Tipo 4 transfiere 8 bits en paralelo. Las interfaces Tipo 2 y Tipo 3 utilizan el mismo cable y conector que el Tipo 1 pero pueden operar a dos y cuatro veces la velocidad de datos para soportar aplicaciones de video de rendimiento superior en dispositivos portátiles. Una interfaz Tipo 4 es conveniente para clientes o pantallas de muy alto rendimiento y requiere un cable ligeramente más largo que contenga señales de datos de par trenzado adicionales. El protocolo utilizado por la MDDI permite a cada huésped Tipo 1, 2, 3 ó 4 entablar comunicación generalmente con cualquier cliente Tipo 1, 2, 3 ó 4 negociando cuál es la velocidad de datos más alta posible que se puede utilizar. Las capacidades o características disponibles, de lo que se puede denominar como el dispositivo con menor capacidad, se utilizan para establecer el rendimiento del enlace. Como regla, incluso para sistemas donde el huésped y el cliente tienen la capacidad para utilizar interfaces Tipo 2, Tipo 3, ó Tipo 4, ambos comienzan su operación como un interfaz Tipo 1. El huésped entonces determina la capacidad del cliente objetivo, y negocia una transferencia u operación de reconfiguración para el modo Tipo 2, Tipo 3 ó Tipo 4, según sea apropiado para la aplicación particular. Generalmente es posible que el huésped utilice el protocolo de capa de enlace adecuado (que se analiza más adelante) y reducir en forma gradual o nuevamente reconfigurar la operación por lo general en cualquier momento a un modo más lento para ahorrar energía o para aumentar a un modo más rápido y así soportar transferencias de velocidad superior, tal como para contenido de pantalla de resolución superior. Por ejemplo, un huésped puede cambiar los tipos de interfaz cuando el sistema cambia de una fuente de energía, tal como una pila a energía AC, o cuando la fuente de los medios de pantalla cambia a un formato de resolución inferior o superior, o una combinación de estas u otras condiciones o eventos se pueden considerar como una base para cambiar un tipo de interfaz, 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, se podría utilizar un modo de interfaz Tipo 4 para transferir datos a una pantalla a una velocidad alta, mientras que un modo Tipo 1 se utiliza cuando se transfieren datos a un dispositivo huésped desde dispositivos periféricos tal como un teclado o un dispositivo de señalización. Aquellos expertos en la técnica apreciarán que los huéspedes y clientes pueden comunicar datos en curso a diferentes velocidades. Con frecuencia, los usuarios del protocolo MDDI pueden distinguir entre un modo "externo" y un modo "interno". Un modo externo describe el uso del protocolo e interfaz para conectar un huésped en un dispositivo a un cliente fuera de ese dispositivo que está aproximadamente hasta a 2 metros del huésped. En esta situación, el huésped también puede enviar 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 el huésped está conectado a un cliente contenido dentro del mismo dispositivo, tal como dentro de un alojamiento común o armazón o estructura de soporte de cierto tipo. Un ejemplo serían las aplicaciones dentro de un teléfono inalámbrico u otro dispositivo inalámbrico, o una computadora portátil o dispositivo de juego en donde el cliente es una pantalla o accionador de pantalla, o un dispositivo de entrada tal como un teclado o almohadilla de tacto, o un sistema de sonido, y el huésped es un controlador central, motor de gráficos, o elemento CPU. Debido a que un cliente se encuentra mucho más cerca del huésped en las aplicaciones de modo interno en oposición a las aplicaciones de modo externo, generalmente no hay requerimientos analizados para la conexión de energía con el cliente en dichas configuraciones .

C. Estructura de interfaz física En las figuras 5 y 6 se muestra la disposición general de un dispositivo o controlador de enlace para el establecimiento de comunicaciones entre dispositivos huésped y de cliente. En las figuras 5 y 6, un controlador de enlace MDDI 402 y 502 se muestra instalado en un dispositivo huésped 202 y un controlador de enlace MDDI 404 y 504 se muestra instalado en un dispositivo de cliente 204. Como se mencionó anteriormente, el huésped 202 está conectado a un cliente 204 utilizando un canal de comunicación bi-direccional 406 que comprende una serie de conductores. Como se analiza más adelante, ambos controladores de enlace tanto huésped como de cliente, se pueden fabricar como un circuito integrado utilizando un diseño de un solo circuito que se puede configurar, ajustar o programar para responder ya sea como un controlador huésped (accionador) o un controlador de cliente (receptor) . Esto provee menores costos debido a la fabricación a mayor escala de un dispositivo con un solo circuito. En la figura 6, un controlador de enlace MDDI 502 se muestra instalado en un dispositivo huésped 202' y un controlador de enlace MDDI 504 se muestra instalado en un dispositivo de cliente 204' . Como se mencionó antes, el huésped 202' es conectado a un cliente 204' utilizando un canal de comunicación bi-direccional 506 que comprende una serie de conductores. Como se analizó anteriormente, ambos controladores de enlace huésped y de cliente se pueden fabricar utilizando un diseño de un solo circuito. Las señales que pasan entre un huésped y un cliente, tal como un dispositivo de pantalla, en el enlace MDDI, o los conductores físicos utilizados, también se ilustran en las figuras 5 y 6. Tal como se aprecia en las figuras 5 y 6, la trayectoria primaria o mecanismo para transferir datos a través de la MDDI utiliza señales de datos etiquetadas como MDDI_DatosO+/~ y MDDI_Stb+/-. Cada una de estas son señales de datos de bajo voltaje que se transfieren en un par diferencial de cables en un cable. Solo existe una transición en el par MDDI_DatosO o el par MDDI_Stb para cada bit enviado en la interfaz. Este es un mecanismo de transferencia basado en voltaje, no basado en corriente, de manera que el consumo de corriente estática es casi cero. El huésped conduce las señales MDDI_Stb a la pantalla del cliente. Aunque los datos pueden fluir en ambas direcciones, de avance y reversa, en los pares MDDI_Datos, es decir, es una trayectoria de transferencia bi-direccional, el huésped es la terminal maestra o controlador del enlace de datos. Las trayectorias de señal MDDI_DatosO y MDDI_Stb se operan en un modo diferencial para elevar al máximo la inmunidad al ruido. La velocidad de datos para señales en estas líneas queda determinada por la velocidad de la sincronía enviada por el huésped, y es variable en un rango de aproximadamente 1 kbps hasta 400 Mbps o más . La interfaz Tipo 2 contiene un par de datos adicionales o conductores o trayectorias más allá de aquel del Tipo 1, denominado como MDDI_Datosl+/-. La interfaz Tipo 3 contiene dos pares adicionales de datos o trayectorias de señal más allá de aquel de la interfaz Tipo 2 denominados como MDDI_Datos2+/-, y MDDI_TJatos3+/-. La interfaz tipo 4 contiene cuatro pares de datos más o trayectorias de señal más allá de aquellos de la interfaz Tipo 3 denominados como: MDDI_Datos4+/-, MDDI_Datos5+/-, MDDI_Datos6+/-, y MDDI_Datos7+/-, respectivamente. En cada una de las configuraciones de interfaz anteriores, un huésped puede enviar energía al cliente o pantalla utilizando el par de cables o señales designadas como HUESPED_Pwr y HUESPED_Gnd. Tal como se analiza más adelante, la transferencia de energía también se puede permitir, si se desea, en algunas configuraciones en los conductores MDDI_Datos4+/-, MDDI_Datos5+/-, MDDI_Datos6+/-, y MDDI_Datos7+/-, cuando un "Tipo" de interfaz está siendo utilizado, el cual emplea menos conductores de los disponibles o presentes para los otros modos. Esta transferencia de energía generalmente se emplea para modos externos, no habiendo necesidad generalmente de modos internos, aunque algunas aplicaciones pueden diferir. Un resumen de las señales pasadas entre el huésped y el cliente (pantalla) en el enlace MDDI para varios modos se ilustra en el cuadro I, a continuación, de acuerdo con el tipo de interfaz.

CUADRO I También se puede observar que las conexiones HUÉSPED Pwr/Gnd para transferencia desde el huésped son provistas generalmente para modos externos. Aplicaciones o modos internos de operación generalmente tienen clientes que extraen la energía directamente desde otros recursos internos, y no utilizan MDDI para controlar la distribución de energía, tal como resultaría aparente para aquellos expertos en la técnica, de manera que dicha distribución no se analiza con mayor detalle en la presente invención. Sin embargo, seguramente es posible permitir que la energía sea distribuida a través de la MDDI para permitir algunos tipos de control de energía, sincronización, o conveniencia de interconexión, por ejemplo, tal como sería entendido por aquellos expertos en la técnica. El cableado generalmente utilizado para ejecutar la estructura y operación anteriores nominalmente es del orden de 1.5 metros de longitud, generalmente 2 metros o menos, y contiene tres pares trenzados de conductores, cada uno, a su vez, es un cable de múltiples hebras, nominalmente entre 32 Calibre de Cable Americano (AWG) a 28 AWG. Aunque, el tamaño del cable no está restringido a este rango, tal como lo podrán apreciar aquellos expertos en la técnica, las especificaciones eléctricas o restricciones se deberían cumplir para una resistencia de extremo-a-extremo total máxima, capacitancia máxima por cada 30.48cm, impedancia de cada par, y superposición de sonidos. Una cubierta de revestimiento metálico está devanada o, de otra forma, formada por encima de todo, aquí tres, el conjunto o grupo de pares trenzados, y un hilo de drenaje tal como un hilo de drenaje adicional. Los pares trenzados y el conductor de drenaje de revestimiento terminan en el conector del cliente con el revestimiento conectado al revestimiento para el cliente, y existe una capa aislante, que cubre todo el cable, tal como se conocerá en la técnica. Los cables son pares como: HUESPED_Gnd con HUESPED_Pwr; MDDI_Stb+ con MDDI_Stb-; MDDI_DatosO+ con MDDI_DatosO-; MDDI_Datosl+ con MDDI_Datosl-; y así sucesivamente. Sin embargo, se puede utilizar una variedad de conductores y cableado, tal como se entenderá en la técnica, para ejecutar las modalidades de la invención, dependiendo de las aplicaciones específicas. Por ejemplo, se pueden utilizar recubrimientos exteriores más pesados o incluso capas metálicas para proteger el cable en algunas aplicaciones, mientras que para otras aplicaciones, estructuras tipo listón conductor más plano y más delgado son bastante apropiadas.

D. Tipos y velocidades de datos Para lograr una interfaz útil para un rango completo de experiencias y aplicaciones de usuario, la MDDI provee soporte para una variedad de clientes e información de pantalla, transductores de audio, teclados, dispositivos de señalización, y muchos otros dispositivos de entrada o salida que se podrían integrar en, o trabajar junto con un dispositivo de comunicación, cómputo o pantalla móvil, junto con información de control, y combinaciones de los mismos. La MDDI está diseñada para permitir una variedad de tipos potenciales de corrientes de datos que cruzan entre el huésped y el cliente en cualquiera de las direcciones de enlace de avance o inverso utilizando un número mínimo de cables o conductores. Ambas corrientes son soportadas, las corrientes isócronas y las corrientes asincronas (actualizaciones) . Son posibles muchas combinaciones de los tipos de datos siempre y cuando la velocidad de datos agregada sea menor que o igual a la velocidad de enlace MDDI deseada máxima, la cual queda limitada por la máxima velocidad en serie y el número de pares de datos empleados. Estas podrían incluir, pero no se limitan a, aquellas partidas que se listan en los cuadros II y III a continuación. CUADRO II CUADRO III La interfaz no es fija sino que se puede extender para poder soportar la transferencia de una variedad de "tipos" de información que incluye datos definidos por el usuario, para futura flexibilidad del sistema. Ejemplos específicos de datos que se van a acomodar son: video de secuencia completa, ya sea en la forma de campos de mapa de bits de pantalla completa o parcial o video comprimido; mapas de bits estáticos a bajas velocidades para conservar la energía y reducir los costos de ejecución; PCM o datos de audio comprimidos a una variedad de resoluciones o velocidades; posición y selección de dispositivo de señalización, y datos definibles por el usuario para capacidades que están por ser definidas. Dichos datos también se pueden transferir junto con información de control o estado para detectar la capacidad del dispositivo o fijar los parámetros operativos. Las modalidades de la invención adelantan la técnica para uso en transferencias de datos que incluyen, pero no se limitan a: ver una película (despliegue de video y audio) ; utilizar una computadora personal con visualización personal limitada (pantalla de gráficos, en ocasiones combinados con video y audio) ; reproducir un juego de video en una PC, consola o dispositivo personal (pantalla de gráficos en movimiento, o video y audio sintético) ; "navegar" por Internet, utilizando dispositivos en la forma de un teléfono de video (video y audio bidireccional de baja velocidad), una cámara para imágenes digitales estáticas, o una videocámara para capturar imágenes de video digital; utilizar un teléfono, computadora, o PDA acoplado con un proyector para hacer una presentación, o acoplado con una estación de acoplamiento de escritorio conectada a un monitor de video, teclado y ratón; y para la mejora de la productividad o uso de entretenimiento con teléfonos celulares, teléfonos inteligentes, o PDA, incluyendo dispositivos inalámbricos de señalamiento y datos de teclado. La interfaz de datos de alta velocidad, tal como se analiza a continuación, se muestra en términos de proveer cantidades grandes de datos tipo A-V en un enlace de comunicación o transferencia el cual generalmente está configurado como un enlace cableado o de tipo cable. Sin embargo, será fácilmente aparente que la estructura de señal, protocolos, temporización, o mecanismo de transferencia se podrían ajustar para proveer un enlace en la forma de un medio óptico o inalámbrico, si éste puede sostener el nivel deseado de transferencia de datos. Las señales MDDI utilizan un concepto conocido como Velocidad de Cuadro Común (CFR) para la estructura o protocolo de señal básico. La idea detrás del uso de una Velocidad de Cuadro Común es proveer un impulso de sincronización para corrientes de datos isócronas simultáneas enviando Paquetes de Encabezado de Sub-Cuadro a una velocidad que se puede utilizar para derivar sincronías o temporización de cuadros para múltiples corrientes. La velocidad a la que los Paquetes de Encabezado de Sub-Cuadro son enviados es la Velocidad de Cuadro Común. Un dispositivo del cliente puede utilizar esta Velocidad de Cuadro Común como una referencia de tiempo. Una CFR baja aumenta la eficiencia del canal reduciendo la sobrecarga para transmitir el encabezado de sub-cuadro. Por otra parte, una CFR elevada reduce la latencia, y permite una memoria intermedia de datos elástica más pequeña para muestras de audio. La CFR de la presente interfaz inventiva es dinámicamente programable y se puede establecer a uno de muchos valores que son apropiados para las corrientes isócronas utilizadas en una aplicación particular. Es decir, el valor CF se selecciona para que se adapte mejor a la configuración de cliente y huésped determinada, según se desee . El número de bytes que generalmente se requiere por sub-cuadro, el cual es ajustable o programable, para corrientes de datos isócronas que tienen mayor probabilidad de ser utilizadas con una aplicación, tal como para una micro-pantalla o video, se muestra en el cuadro IV.

CUADRO IV Los conteos de bytes fracciónales por sub-cuadro se pueden obtener fácilmente utilizando una estructura de contador M/N programable simple. Por ejemplo, un conteo de 26-2/3 de bytes por sub-cuadro se ejecuta transfiriendo 2 sub-cuadros que contienen 27 bytes, cada uno seguido por un sub-cuadro que contiene 26 bytes. Se puede seleccionar una CFR más reducida para producir un número entero de bytes por sub-cuadro. Sin embargo, hablando en términos generales, la ejecución de un contador M/N simple en hardware requeriría menos área dentro de un chip de circuito integrado o módulo electrónico utilizado para ejecutar algunas o todas las modalidades de la invención que el área que se necesita para una memoria intermedia FIFO de muestra de audio más grande. Una aplicación ejemplar que ilustra el impacto de diferentes velocidades de transferencias de datos y tipos de datos es un sistema Karaoke. Para karaoke, un sistema en donde un usuario final, o usuarios, cantan junto con un programa de video de música. Las letras de las canciones aparecen en alguna parte, típicamente en la parte inferior, de la pantalla de manera que el usuario sepa las palabras que debe cantar, y aproximadamente el ritmo de la canción. Esta aplicación requiere una pantalla de video con actualizaciones de gráficos infrecuentes, y la mezcla de la voz del usuario, o voces, con una corriente de audio estéreo . Si se asume una velocidad de cuadro común de 300 Hz, entonces cada sub-cuadro constará 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) en el enlace de avance al 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 de Karaoke móvil. Paquetes asincronos son enviados entre el huésped y el cliente, posiblemente una pantalla de cabeza montada. Esto incluye que el cuarto de pantalla inferior en altura sea actualizado con el texto de la letra en l/30avo de intervalos o periodos de segundo, y otros comandos de estado y control misceláneos enviados en subcuadros cuando el texto de la letra no está siendo actualizado. El cuadro V, muestra la manera en que los datos son asignados dentro de un sub-cuadro para el ejemplo de karaoke. La velocidad total que se utiliza es seleccionada para que sea de alrededor de 279 Mbps. Una velocidad ligeramente superior de 280 Mbps permite que aproximadamente otros 400 bytes de datos por sub-cuadro sean transferidos, lo cual permite el uso de mensajes ocasionales de control y estado.

CUADRO V III. (Continúa) Arquitectura del sistema de interfaz de datos digitales de alta velocidad E. Capa de enlace Los datos transferidos utilizando las señales de datos en serie de alta velocidad MDDI constan de una corriente de paquetes multiplexados en tiempo que están enlazados uno después del otro. Incluso cuando un dispositivo de transmisión no tiene datos para enviar, un controlador de enlace MDDI por lo general envía, de manera automática, paquetes de relleno, manteniendo así una corriente de paquetes. El uso de una estructura de paquete simple garantiza la temporización isócrona para señales de audio y video o de corrientes de datos. Grupos de paquetes están contenidos dentro de elementos o estructuras de señal a los que se denomina sub-cuadros, y grupos de sub-cuadros están contenidos dentro de elementos o estructuras de señal a los que se denomina cuadro de medios. Un sub-cuadro contiene uno o más paquetes, dependiendo de su tamaño respectivo y de los usos de transferencia de datos, y un cuadro de medios contiene uno o más sub-cuadros. El sub-cuadro más grande provisto por el protocolo empleado por las modalidades aquí presentadas es en el orden de 232-l ó 4,294,967,295 bytes, y el tamaño de cuadro de medios más grande entonces se vuelve del orden de 216-1 ó 65,535 sub-cuadros. Un paquete de encabezado de sub-cuadro especial contiene un identificador único que aparece al comienzo de cada sub-cuadro, tal como se analiza a continuación. El identificador también se utiliza para adquirir la temporización del cuadro en el dispositivo del cliente cuando se inicia la comunicación entre el huésped y el cliente. La adquisición de temporización de enlace se analiza con mayor detalle a continuación. Por lo regular, una pantalla de despliegue es actualizada una vez por cuadro de medios cuando se está comenzando a desplegar contenido de video de secuencia completa. La velocidad del cuadro de pantalla es la misma que la velocidad del cuadro de medios . El protocolo de enlace soporta video de secuencia completa en toda una pantalla, o solo una pequeña región de contenido de video de secuencia completa rodeado por una imagen estática, dependiendo de la aplicación deseada. En algunas aplicaciones móviles de baja potencia, tal como la visualización de páginas web o correo electrónico, la pantalla de despliegue pudiera solo necesitar ser actualizada ocasionalmente. En esas situaciones, es conveniente transmitir un solo sub-cuadro y después apagar o inactivar el enlace para reducir al mínimo el consumo de energía. La interfaz también soporta efectos tales como visión estéreo, y maneja gráficos primitivos. Los sub-cuadros permiten a un sistema habilitar la transmisión de paquetes de alta prioridad sobre una base periódica. Esto permite que corrientes isócronas simultáneas co-existan con una cantidad mínima de almacenamiento de datos en memoria intermedia. Esta es una ventaja que proveen las modalidades al proceso de despliegue, permitiendo que múltiples corrientes de datos (comunicación de video de alta velocidad, voz, control, estado, datos de dispositivo de señalamiento, etc.) compartan, esencialmente, un canal común. Este transfiere información utilizando relativamente pocas señales. También permite que existan acciones específicas de tecnología de pantalla, tal como impulsos de sincronización horizontales e intervalos en blanco para un monitor CRT, o para otras acciones específicas de tecnología de cliente.

F. Controlador de enlace El controlador de enlace MDDI que se muestra en las figuras 5 y 6 es fabricado o ensamblado para que sea una ejecución completamente digital con la excepción de los receptores de línea diferencial los cuales se utilizan para recibir datos MDDI y señales estroboscópicas . Sin embargo, incluso los accionadores y receptores de líneas diferenciales se pueden ejecutar en los mismos circuitos integrados digitales con el controlador de enlace, tal como cuando se realiza un IC tipo CMOS. No se requieren funciones análogas o Bucles de Bloqueo de Fase (PLL) para la recuperación de bits o para ejecutar el hardware para el controlador de enlace. Los controladores de enlace de huésped y cliente contienen funciones muy similares, con la excepción de la interfaz de cliente la cual contiene una máquina de estado para sincronización de enlace. Por lo tanto, las modalidades de la invención permiten la ventaja práctica de poder crear un solo diseño de controlador o circuito que se puede configurar ya sea como un huésped o cliente, lo cual reduce los costos de fabricación para los controladores de enlace, como un todo.

IV. Protocolo de enlace de interfaz A. Estructura de cuadro En la figura 7 se ilustra el protocolo de señal o estructura de cuadro que se utilizan para ejecutar la comunicación de enlace de avance para la transferencia de paquetes. Como se muestra en la figura 7, la información o datos digitales se agrupan en elementos conocidos como paquetes. A su vez, múltiples paquetes se agrupan entre sí para formar lo que se denomina un "sub-cuadro" y, a su vez, múltiples sub-cuadros se agrupan entre sí para formar un cuadro de "medios". Para controlar la formación de cuadros y transferencia de sub-cuadros, cada sub-cuadro comienza con un paquete especialmente predefinido denominado como Paquete de Encabezado de Sub-cuadro (SHP) . El dispositivo huésped selecciona la velocidad de datos que se va a utilizar para una transferencia determinada. Esta velocidad se puede cambiar dinámicamente a través del dispositivo huésped con base en la capacidad de máxima transferencia del huésped, o los datos que están siendo recuperados de una fuente por el huésped, y la capacidad máxima del cliente, u otro dispositivo al que están siendo transmitidos los datos.

Un dispositivo de cliente receptor diseñado para, o que tiene la capacidad de funcionar con la MDDI o protocolo de señal inventivo puede ser cuestionado por el huésped para determinar la velocidad máxima, o máxima actual, de transferencia de datos que puede utilizar, o se puede utilizar una velocidad mínima más lenta por omisión, así como tipos y características de datos utilizables soportados. Esta información se podría transferir utilizando un Paquete de Capacidad de Cliente (CCP) , tal como se analiza a continuación. El dispositivo de pantalla del cliente tiene la capacidad de transferir datos o establecer comunicación con otros dispositivos utilizando la interfaz a una velocidad de datos mínima preseleccionada o dentro de un rango mínimo de velocidad de datos, y el huésped realizará una investigación utilizando la velocidad de datos dentro de este rango para determinar las capacidades completas de los dispositivos del cliente. Otra información de estado que define la naturaleza del mapa de bits y las capacidades de velocidad de cuadro de video del cliente puede ser transferida en un paquete de estado al huésped de manera que, el huésped pueda configurar la interfaz para que sea lo más eficiente u óptima posible, o deseada dentro de cualesquiera restricciones del sistema. El huésped envía paquetes de relleno cuando no hay (más) paquetes de datos que van a ser transferidos en el sub-cuadro presente, o cuando el huésped no puede transferir a una velocidad suficiente para mantener el ritmo con la velocidad de transmisión de datos elegida para el enlace de avance. Debido a que cada sub-cuadro comienza con un paquete de encabezado de sub-cuadro, el fin del subcuadro previo contiene un paquete (con mayor probabilidad un paquete de relleno) que rellena con precisión el subcuadro previo. En el caso de una falta de espacio para los paquetes de portación de datos en sí, un paquete de relleno con mayor probabilidad será el último paquete en un subcuadro, o al final de un siguiente sub-cuadro previo y antes de un paquete de encabezado de sub-cuadro. Es tarea de las operaciones de control en un dispositivo de huésped asegurar que haya suficiente espacio restante en un subcuadro para cada paquete que va a ser transmitido dentro de ese sub-cuadro. Al mismo tiempo, una vez que un dispositivo de huésped inicia el envío de un paquete de datos, el huésped debe poder completar con éxito un paquete que se ajuste dentro de un cuadro sin incurrir en una condición de sub-corrimiento de datos . En un aspecto de las modalidades, la transmisión de sub-cuadro tiene dos modos. Un modo es un modo de subcuadro periódico, o tiempos de temporización periódicos, que se utilizan para transmitir corrientes de audio y video en vivo. En este modo, la longitud del sub-cuadro se define como no cero. El segundo modo es un modo asincrono o no periódico en donde los cuadros son utilizados para proveer datos de mapa de bits a un cliente cuando está disponible nueva información. Este modo se define estableciendo la longitud del sub-cuadro a cero en el paquete de encabezado de sub-cuadro. Cuando se utiliza el modo periódico, la recepción del paquete de sub-cuadro puede comenzar cuando el cliente se ha sincronizado a la estructura de cuadro de enlace de avance. Esto corresponde a los estados "en sincronización" definidos de acuerdo con el diagrama de estado analizado más adelante con respecto a la figura 49 o la figura 63. En el modo de sub-cuadro no periódico asincrono, la recepción comienza después que se recibe el primer paquete de encabezado de sub-cuadro.

B. Estructura de paquete general El formato o estructura de paquetes utilizados para formular la comunicación o protocolo de señal, o método o medios para transferir datos, ejecutados por las modalidades, se presentan a continuación, teniendo en mente que la interfaz es extensible y que estructuras de paquetes adicionales se pueden agregar según se desee. Los paquetes son etiquetados como, o divididos en diferentes "tipos de paquete" en términos de su función en la interfaz, es decir, comandos, información, valor, o datos que transfieren o con los que están asociados. Por lo tanto, cada tipo de paquete denota una estructura de paquete predefinida para un paquete determinado que se utiliza para manipular los paquetes y datos que se están transfiriendo. Tal como será fácilmente aparente, los paquetes pueden tener longitudes preseleccionadas o pueden tener longitudes dinámicamente cambiables o variables dependiendo de sus funciones respectivas. Los paquetes también podrían soportar diferentes nombres, aunque se sigue realizando la misma función, tal como puede ocurrir cuando los protocolos son modificados durante la aceptación en un estándar. Los bytes o valores de byte utilizados en varios paquetes se configuran como enteros sin firmar de múltiples bits (8 ó 16 bits) . En los Cuadros VI-1 a VI-4 se muestra un resumen de los paquetes que se están empleando junto con sus designaciones de "tipo", listadas en orden de tipo. Cada cuadro representa un "tipo" general de paquete dentro de la estructura de paquete general para facilitar la ilustración y la comprensión. No existe limitación u otro impacto implicado o que se esté expresando para la invención a través de estos agrupamientos, y los paquetes se pueden organizar en muchas otras formas deseadas. También se observa la dirección en la que la transferencia de un paquete es considerada válida. Cuadro VI-1 Paquetes de control de enlace Cuadro VI-2 Paquetes de corriente de medios básicos Cuadro VI-3 Paquetes de control y estado del cliente Cuadro VI-4 Paquetes de pantalla y gráficos avanzados Algo que resulta claro a partir de otros análisis dentro de este texto es que los paquetes de Encabezado de Sub-cuadro, Relleno, Encapsulación Inversa, Apagado de Enlace, Capacidad del Cliente, y Solicitud y Estado del Cliente se consideran muy importantes, o incluso se requieren en muchas modalidades de interfaces de comunicación para operación de Modo Externo. Sin embargo, los paquetes de Encapsulación Inversa, Apagado de Enlace, Capacidad del Cliente, y Solicitud y Estado del Cliente, pueden ser o tienen más probabilidades de ser considerados óptimos para operación de Modo Interno. Esto crea otro tipo todavía de protocolo MDDI el 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 temporización. Los paquetes tienen una estructura básica común o conjunto general de campos mínimos que comprenden un campo de Longitud de Paquete, un campo de Tipo de Paquete, campo (s) de Bytes de Datos, y un campo CRC, el cual se ilustra en la figura 8. Como se muestra en la figura 8, el campo de Longitud de Paquete contiene información en la forma de un valor de múltiples bits o bytes, que especifica el número total de bits en el paquete, o su longitud entre el campo de longitud de paquete y el campo CRC. En una modalidad, el campo de longitud de paquete contiene un entero sin firmar de 16 bits ó 2 bytes de ancho, el cual especifica la longitud del paquete. El campo de Tipo de Paquete es otro campo de múltiples bits el cual designa el tipo de información que está contenida dentro del paquete. En una modalidad ejemplar, este es un valor de 16 bits ó 2 bytes de ancho, en la forma de un entero sin firmar de 16 bits, y especifica esos tipos de datos como capacidades de pantalla, transferencia, corrientes de video o audio, estado, y así sucesivamente. Un tercer campo es el campo de Bytes de Datos, el cual contiene los bits o datos que están siendo transferidos o enviados entre los dispositivos de 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 específico de datos que se está transfiriendo, y se puede separar en una serie de campos adicionales, cada uno con sus propios requerimientos de formato. Es decir, cada tipo de paquete tendrá un formato definido para esta porción o campo. El último campo es el campo CRC el cual contiene los resultados de un chequeo de redundancia cíclica de 16 bits calculado en los campos de Bytes de Datos, Tipo de Paquete, y Longitud de Paquete, lo 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 campo CRC mismo. El cliente generalmente mantiene un conteo total de los errores CRC detectados, y reporta este conteo de regreso al huésped en el paquete de Solicitud y Estado del Cliente (ver a continuación para más detalles) . Generalmente, estos anchos de campo y organización están diseñados para mantener campos de 2 bytes alineados en un límite de bytes par, y campos de 4 bytes alineados en límites de 4 bytes. Esto permite que las estructuras de paquete sean fácilmente incorporadas en un espacio de memoria principal de, o asociado con un huésped y un cliente sin infringir las reglas de alineación del tipo de datos encontradas para la mayoría de los procesadores o circuitos de control típicamente utilizados. Durante la transferencia de paquetes, los campos son transmitidos iniciando con el Bit Menos Significativo (LSB) primero y finalizando con el Bit Más Significativo (MSB) transmitido al último. Los parámetros que tienen más de un byte de longitud se transmiten utilizando el byte menos significativo primero, lo cual produce como resultado el mismo patrón de transmisión de bits que se está utilizando para un parámetro mayor que 8 bits de longitud, tal como se acostumbra para un parámetro más corto en donde el LSB es transmitido primero. Los campos de datos de cada paquete generalmente son transmitidos en el orden en que están definidos en las secciones posteriores a continuación, en donde el primer campo mencionado es transmitido primero, y el último campo descrito es transmitido al último. Los datos en la trayectoria de señal MDDI_Datos0 está alineada con el bit "0" de bytes transmitidos en la interfaz en cualquiera de los modos, Tipo 1, Tipo 2, Tipo 3 ó Tipo 4. Cuando se manipulan datos para pantallas, los datos para disposiciones de píxeles son transmitidos por filas primero, después columnas, tal como se hace tradicionalmente en la técnica de la electrónica. En otras palabras, todos los píxeles que aparecen en la misma fila en un mapa de bits son transmitidos en orden, con el píxel más hacia la izquierda transmitido primero y el píxel más a la derecha transmitido al último. Después que el píxel más a la derecha de una fila es transmitido, entonces el siguiente píxel en la secuencia es el píxel más a la izquierda de la siguiente fila. Las filas de píxeles por lo general son transmitidas en orden desde arriba hacia abajo para la mayoría de las pantallas, aunque se pueden tener otras configuraciones según sea necesario. Además, en el manejo de los mapas de bits, el enfoque convencional, el cual se sigue aquí, es definir un punto de referencia etiquetando la esquina izquierda superior de un mapa de bits como la ubicación o compensación "0,0". Las coordenadas X y Y que se utilizan para definir o determinar una posición en el mapa de bits aumentan en valor conforme uno se acerca a la derecha y parte inferior del mapa de bits, respectivamente. La primera fila y la primera columna (esquina izquierda superior de una imagen) comienzan con un valor de índice de cero. La magnitud de la coordenada X aumenta hacia el lado derecho de la imagen, y la magnitud de la coordenada Y aumenta hacia la parte inferior de la imagen tal como lo puede visualizar 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 pantalla física. Con frecuencia sucede que la ventana de pantalla y el mapa de bits son del mismo tamaño. La esquina izquierda superior de una ventana de pantalla siempre despliega la ubicación de píxel del mapa de bits "0,0". El ancho de la ventana de pantalla corresponde al eje X del mapa de bits, y el ancho de la 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 la ventana de pantalla para esta modalidad es menor que o igual a la altura del mapa de bits correspondiente. La ventana de pantalla misma no es dirigible en el protocolo debido a que solo está definida como la porción visible de un mapa de bits. La relación entre un mapa de bits y las ventanas de pantalla es muy conocida en la técnica de las computadoras, electrónica, comunicación por Internet, y otras técnicas relacionadas con la electrónica. Por lo tanto, no se provee un análisis o ilustración adicional de estos principios.

C. Definiciones de paquete 1. Paquete de encabezado de sub-cuadro El paquete de encabezado de sub-cuadro es el primer paquete de cada sub-cuadro, y tiene la estructura básica tal como se ilustra en la figura 9. El paquete de encabezado de sub-cuadro se utiliza para la sincronización huésped-cliente, cada huésped debería ser capaz de generar este paquete, mientras que cada cliente debería ser capaz de recibir e interpretar este paquete. Tal como se puede apreciar en una modalidad en la figura 9, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Palabra Única, Reservado 1, Longitud de Sub-cuadro, Versión de Protocolo, Conteo de Sub-Cuadro, y Conteo de Cuadro de Medios, generalmente en ese orden. En una modalidad, este tipo de paquete por lo regular se identifica como un paquete Tipo 15359 (0x3bff hexadecimal) y emplea una longitud fija previamente seleccionada de 20 bytes, sin incluir el campo de longitud de paquete. El campo de Tipo de Paquete y el campo de Palabra Única utilizan, cada uno, un valor de 2 bytes (entero sin firmar de 16 bits) . La combinación de 4 bytes de estos dos campos juntos forma una palabra única de 32 bits con una buena auto-correlación. En una modalidad, la palabra única real es 0x005a3bff, en donde los 16 bits inferiores son transmitidos primero como el Tipo de Paquete, y los 15 bits más significativos son transmitidos posteriormente. El campo Reservado 1 contiene 2 bytes que son espacio reservado para uso futuro y, por lo general, se configura en este punto con todos los bits establecidos en cero. Un propósito de este campo es hacer que los campos de 2 bytes posteriores se alineen a 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. El byte menos significativo se reserva para indicar si un huésped es capaz o no de dirigir múltiples dispositivos de cliente. Se reserva un valor de cero para este byte con el fin de indicar que el huésped tiene la capacidad para operar únicamente con un solo dispositivo de cliente. El campo de Longitud de Sub-cuadro contiene 4 bytes de información, o valores, el cual especifica el número de bytes por sub-cuadro. En una modalidad, la longitud de este campo se puede establecer igual a cero para indicar que solo un sub-cuadro será transmitido por el huésped antes que el enlace sea puesto en un estado inactivo. El valor en este campo se puede modificar de manera dinámica "en el aire" cuando se cambia de un subcuadro al siguiente. Esta capacidad es útil para realizar ajustes de temporización menores en los impulsos de sincronización para permitir corrientes de datos isócronas. Si el CRC del paquete de encabezado de sub-cuadro no es válido, entonces el controlador de enlace debería utilizar la Longitud de Sub-Cuadro del paquete de encabezado de sub-cuadro previo bien conocido para calcular la longitud del sub-cuadro actual. El campo Versión de Protocolo contiene 2 bytes que especifican la versión de protocolo utilizada por el huésped. El campo de Versión de Protocolo se puede establecer en "0" para especificar la primera versión o la versión actual del protocolo como la versión que se está utilizando. Este valor cambiará con el tiempo conforme se creen nuevas versiones, y ya se está actualizando a un valor de "1" para algunos campos de versión. Los valores de versión, de manera probable o general, seguirán un número de versión actual para un documento de estándares aprobados el cual abarca las interfaces tal como MDDI, tal como se conocería. El campo de Conteo de Sub-cuadro contiene 2 bytes que especifican un número de secuencia que indica el número de sub-cuadros que han sido transmitidos desde el inicio del cuadro de medios. El primer sub-cuadro del cuadro de medios tiene un Conteo de Sub-cuadro de cero. El último sub-cuadro del cuadro de medios tiene un valor de n-l, en donde n es el número de sub-cuadros por cuadro de medios.

El valor del campo de Conteo de Sub-cuadro es igual al Conteo de Sub-cuadro enviado en el paquete de Sub-cuadro previo más 1, excepto para un primer sub-cuadro de un cuadro de medios el cual tendrá un conteo de cero. Se puede apreciar que si la Longitud de Sub-cuadro se establece igual a cero (indicando un sub-cuadro no periódico) entonces el conteo de Sub-cuadro también se establece igual a cero. El campo de Conteo de Cuadro de Medios contiene 4 bytes (entero sin firmar de 32 bits) que especifica un número de secuencia que indica el número de cuadros de medios que han sido transmitidos desde el inicio del presente producto de medios o datos que se están transfiriendo. El primer cuadro de medios de un producto de medios tiene un Conteo de Cuadro de Medios de cero. El Conteo de Cuadro de Medios incrementa justo antes del primer sub-cuadro de cada cuadro de medios y regresa a cero después que se utiliza el Conteo de Cuadro de Medios máximo (por ejemplo, número de cuadro de medios 23~1 = 4,294,967,295). El valor del Conteo de Cuadro de Medios puede ser restablecido generalmente en cualquier momento por el Huésped para que se ajuste a las necesidades de una aplicación final. 2. Paquete de relleno Un paquete de relleno es un paquete que es transferido a, o desde un dispositivo de cliente cuando no hay disponible otra información para ser enviada ya sea en el canal de avance o el canal inverso. Se recomienda que los paquetes de relleno tengan una longitud mínima para permitir la máxima flexibilidad durante el envío de otros paquetes cuando se requiera. Al final de un sub-cuadro o un paquete de encapsulación de enlace inverso (ver a continuación) , un controlador de enlace establece el tamaño del paquete de relleno para rellenar el espacio restante con el fin de mantener la integridad del paquete. El Paquete de Relleno es útil para mantener la temporización en el enlace cuando el huésped o cliente no tienen información para enviar o intercambiar. Cada huésped y cliente necesita tener la capacidad para enviar y recibir este paquete con el fin de hacer efectivo el uso de la interfaz . En la figura 10 se muestra una modalidad ejemplar del formato y contenido de un Paquete de Relleno. Como se muestra en la figura 10, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Bytes de Relleno, y CRC. En una modalidad, este tipo de paquete generalmente se identifica como un Tipo 0, el cual es indicado en el campo Tipo 2 bytes. Los bits o bytes en el campo de Bytes de Relleno comprenden un número variable de todos los valores de bit cero para permitir que el paquete de relleno tenga la longitud deseada. El paquete de relleno más pequeño no contiene bytes en este campo. Es decir, el paquete consta únicamente de la longitud de paquete, tipo de paquete, y CRC, y en una modalidad utiliza una longitud fija preseleccionada de 6 bytes o un valor de Longitud de Paquete de 4. El valor CRC se determina para todos los bytes en el paquete, incluyendo la Longitud de Paquete, el cual puede ser excluido en algunos otros tipos de paquete. 3. Paquete de corriente de video Los paquetes de corriente de video portan datos de video para actualizar regiones típicamente rectangulares de un dispositivo de pantalla. El tamaño de esta región puede ser tan pequeño como un solo píxel o tan grande como toda la pantalla. Puede haber un número casi ilimitado de corrientes desplegadas simultáneamente, limitado por recursos del sistema, debido a que todo el contexto que requirió desplegar una corriente está contenido dentro del Paquete de Corriente de Video. En la figura 11 se muestra el formato de una modalidad de un Paquete de Corriente de Video (Descriptor de Formato de Datos de Video) . Tal como se puede apreciar en la figura 11, en una modalidad, este tipo de paquete está estructurado para tener campos de Longitud de Paquete (2 bytes), Tipo de Paquete, ID de bCliente, Descriptor de Datos de Video, Atributos de Pantalla de Píxel, Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, Inicio de X y Y, Conteo de Píxeles, CRC de Parámetro, Datos de Píxel, y CRC de Datos de Píxel. Este tipo de paquete generalmente se identifica como un Tipo 16, el cual se indica en el campo Tipo 2 bytes. En una modalidad, un cliente indica una habilidad para recibir un Paquete de Corriente de Video utilizando los Campos Rojo-Verde-Azul (RGB) , Monocromo, y Capacidad Y Cr Cb del Paquete de Capacidad del Cliente. En una modalidad, el campo de ID de bCliente contiene 2 bytes de información que son reservados para una ID de Cliente. Debido a que este es un protocolo de comunicaciones recientemente desarrollado, las ID de clientes reales todavía no se conocen o son lo suficientemente comunicables. Por lo tanto, los bits en este campo generalmente se establecen igual a cero hasta que se conocen dichos valores ID, en cuyo momento los valores ID se pueden insertar o utilizar, tal como resultará aparente para aquellos expertos en la técnica. El mismo proceso por lo general será cierto para los campos de ID de cliente que se analizan a continuación. El formato y contenido empleados para ejecutar la operación de un campo ejemplar de Descriptor de Datos de Video, tal como se mencionó anteriormente, se muestran en las figuras 12A-12E. En las figuras 12A-12E, el campo de Descriptor de Formato de Datos de Video contiene 2 bytes en la forma de un entero sin firmar de 16 bits que especifica el formato de cada píxel en los Datos de Píxel en la corriente presente en el paquete presente. Es posible que diferentes paquetes de Corriente de Video puedan utilizar diferentes formatos de datos de píxel, es decir, utilizar un valor diferente en el Descriptor de Formato de Datos de Video, y de manera similar, una corriente (región de la pantalla) puede cambiar su formato de Datos en el aire. El formato de datos de píxel debería cumplir por lo menos con uno de los formatos válidos para el cliente, tal como se definió en el Paquete de Capacidad del Cliente. El Descriptor de Formato de Datos de Video define el formato de píxel para el paquete presente sólo cuando no implica que un formato constante seguirá siendo utilizado durante el periodo de vida de una corriente de video particular. Las figuras 12A a 12D ilustran la forma en que el Descriptor de Formato de Datos de Video está codificado. Tal 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 12A, entonces los datos de video constan de una disposición de píxeles monocromo, en donde el número de bits por píxel queda definido por los bits 3 a 0 de la palabra Descriptor de Formato de Datos de Video. Los bits 11 a 4 generalmente se reservan para uso o aplicaciones futuras y se establecen en cero en esta situación. Por otra parte, cuando los bits [15:13] son iguales a los valores 001' , como se muestra en la figura 12B, entonces los datos de video constan de una disposición de píxeles de color, en donde cada uno especifica un color a través de un mapa de colores (paleta) . En esta situación, los bits 5 a 0 de la palabra Descriptor de Formato de Datos de Video definen el número de bits por píxel, y los bits 11 a 6 generalmente se reservan para uso o aplicaciones futuras y se establecen igual a cero. Por otra parte, cuando los bits [15:13] son iguales a los valores 010', como se muestra en la figura 12C, entonces los datos de video constan de una disposición de píxeles de color, en donde el número de bits por píxel de rojo queda definido por los bits 11 a 8, el número de bits por píxel de verde queda definido por los bits 7 a 4, y el número de bits por píxel de azul queda definido por los bits 3 a 0. En esta situación, el número total de bits en cada píxel es la suma del número de bits utilizados para rojo, verde y azul. Sin embargo, cuando por otra parte los bits [15:13] son iguales a los valores o secuencia ?011' , como se muestra en la figura 12D, entonces los datos de video constan de una disposición de datos de video en formato YCbCr 4:2:2 con información de luminancia y crominancia, en donde el número de bits por píxel de luminancia (Y) queda definido por los bits 11 a 8, el número de bits del componente Cb queda definido por los bits 7 a 4, y el número de bits del componente Cr queda definido por los bits 3 a 0. El número total de bits en cada píxel es la suma del número de bits que se utiliza para rojo, verde y azul. Los componentes Cb y Cr son enviados a la mitad de la velocidad de Y. Además, las muestras de video en la porción de Datos de Píxel de este paquete están organizadas de la siguiente forma: Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3,... en donde Cbn y Crn están asociados con Yn y Yn+1, y Cbn+2 y Crn+2 están asociados con Yn+2 y Yn+3, y así sucesivamente. Yn, Yn+1, Yn+2 y Yn+3 son valores de luminancia de cuatro píxeles consecutivos en una sola fila de izquierda a derecha. Si hay un número impar de píxeles en una fila (Borde Derecho X - Borde Izquierdo X + 1) en la ventana referenciada por el Paquete de Corriente de Video, entonces el valor Y correspondiente al último píxel en cada fila estará seguido por el valor Cb del primer píxel de la siguiente fila, y un valor Cr no es enviado para el último píxel en la fila. Se recomienda que las ventanas que utilizan formato Y Cb Cr tengan un ancho que sea un número par de píxeles. Los Datos de Píxel en un paquete deberán contener un número par de píxeles. Estos pueden contener un número par o impar de píxeles en el caso en donde el último píxel de los Datos de Píxel corresponde al último píxel de una fila en la ventana especificada en el encabezado de Paquete de Corriente de Video, es decir, cuando la ubicación X del último píxel en los Datos de Píxel es igual al Borde Derecho X. Por otra parte, cuando los bits [15:13] son iguales a los valores X00' , entonces los datos de video constan de una disposición de píxeles Bayer, en donde el número de bits por píxel queda definido por los bits 3 a 0 de la palabra Descriptor de Formato de Datos de Video. El Patrón de Grupo de Píxeles queda definido por los bits 5 y 4, tal como se muestra en la figura 12E. El orden de los datos de píxel puede ser horizontal o vertical, y los píxeles en las filas o columnas pueden ser enviados hacia delante o hacia atrás y queda definido por los bits 8 a 6. Los bits 11 a 9 se deberían establecer a cero. El grupo de cuatro píxeles en el grupo de píxeles en el formato Bayer se parece a lo que con frecuencia se denomina como un solo píxel en algunas tecnologías de pantalla. Sin embargo, un píxel en el formato Bayer es solo uno de los cuatro píxeles a color del patrón de mosaico de grupo de píxeles. Para los cinco formatos que se muestran en las figuras, el Bit 12, el cual se designa como "P", especifica si las muestras de Datos de Píxel son empacadas o no, o datos de píxel de bytes alineados. Un valor de ?0' en este campo indica que cada píxel en el campo de Datos de Píxel está alineado en bytes con un límite de bytes de MDDI. Un valor de X' indica que cada píxel y cada color dentro de cada píxel en los Datos de Píxel está empacado contra el píxel o color previo dentro de un píxel, no dejando bits sin utilizar. La diferencia entre formato de datos de Píxel Empacado y Alineado en Bytes se muestra con mayor detalle en la figura 13, en donde claramente se puede observar que los datos alineados en bytes pueden dejar porciones sin utilizar del sub-cuadro de datos, en oposición al formato de píxel empacado en donde no ocurre lo mismo. 4. Paquete de corriente de audio Los paquetes de corriente de audio portan datos de audio para ser reproducidos a través del sistema de audio del cliente, o para un dispositivo de presentación de audio autónomo. Se pueden asignar diferentes corrientes de datos de audio para canales de audio separados en un sistema de sonido, por ejemplo: frontal izquierdo, frontal derecho, centro, posterior izquierdo, y posterior derecho, dependiendo del tipo de sistema de audio que se esté utilizando. Se proporciona un complemento completo de canales de audio para auriculares que contienen procesamiento de señal espacial-acústica mejorada. Un cliente indica una habilidad para recibir un Paquete de Corriente de Audio utilizando los campos de Capacidad de Canal de Audio y Velocidad de Muestra de Audio del Paquete de Capacidad del Cliente. El formato de Paquetes de Corriente de Audio se ilustra en la figura 14. Como se muestra en la figura 14, este tipo de paquete está estructurado en una modalidad para tener campos de Longitud de Paquete, Tipo de Paquete, ID de bCliente, ID de Canal de Audio, Reservado 1, Conteo de Muestra de Audio, Bits Por Muestra y Empaque, Velocidad de Muestra 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 Tipo 32. El campo ID de bCliente contiene 2 bytes de información que están reservados para una ID de Cliente, tal como se utilizó previamente. El campo Reservado 1 contiene 2 bytes que son recibidos para uso futuro, y generalmente se configura en este punto con todos los bits establecidos a cero. El campo Bits Por Muestra y Empaque contiene 1 byte en la forma de un entero sin firmar de 6 bits el cual especifica el formato de empaque de los datos de audio. El formato generalmente empleado es para Bits 4 a 0 con el fin de definir el número de bits por muestra de audio PCM. El bit 5 entonces especifica si se empacan o no las muestras de Datos de Audio Digital. En la figura 15 se ilustra la diferencia entre las muestras de audio empacadas y alineadas en bytes, aquí utilizando muestras de 10 bits. Un valor de 0' indica que cada muestra de audio PCM en el campo de Datos de Audio Digital está alineada en bytes con un límite de bytes MDDI, y un valor de X' indica que cada muestra de audio PCM sucesiva es empacada contra la muestra de audio previa. Este bit por lo general es efectivo solo cuando el valor definido en bits 4 a 0 (el número de bits por muestra de audio PCM) no es un múltiplo de ocho. Los bits 7 a 6 se reservan para futuro uso y generalmente se establecen a un valor de cero. 5. Paquetes de corriente reservados En una modalidad, los tipos de paquete 1 a 15, 18 a 31, y 33 a 55 son reservados para paquetes de corriente que se van a definir para uso en futuras versiones o variaciones de los protocolos de paquete, según se desee para varias aplicaciones que se pudieran encontrar. Una vez más, esto es parte de hacer a la MDDI más flexible y útil en virtud de la tecnología y diseños de sistema cambiantes en comparación con otras técnicas. 6.- Paquetes de corriente definidos por el usuario Ocho tipos de corriente de datos, conocidos como Tipos 56 a 63, se reservan para uso en aplicaciones de marca registrada que pueden ser definidas por los fabricantes de equipo para uso con un enlace MDDI. Estos se conocen como Paquetes de Corriente definidos por el Usuario. Dichos paquetes se pueden utilizar para cualquier propósito, pero el huésped y cliente solo deberían emplear esos paquetes en situaciones donde el resultado de dicho uso es muy bien entendido o conocido. La definición específica de los parámetros de corriente y datos para estos tipos de paquete se deja a los fabricantes de equipo específico o diseñadores de interfaces que ejecutan esos tipos de paquete o que buscan su uso. Algunos usos ejemplares de los Paquetes de Corriente definidos por el Usuario son transmitir parámetros de prueba y resultados de prueba, datos de calibración de fábrica, y datos de uso especial de marca registrada. El formato de los paquetes de corriente definidos por el usuario, tal como se emplea en una modalidad, se ilustra en la figura 16. Como se muestra en la figura 16, este tipo de paquete está estructurado para tener campos de Longitud de Paquete (2 bytes) , Tipo de Paquete, número de ID de bCliente, Parámetros de Corriente, CRC de Parámetro, Datos de Corriente, y CRC de Datos de Corriente. 7. Paquetes de mapa de color Los paquetes de mapa de color especifican el contenido de un cuadro de búsqueda de mapa de color que se utiliza para presentar colores a un cliente. Algunas aplicaciones pueden requerir un mapa de color que sea más grande que la cantidad de datos que puede ser transmitida en un solo paquete. En estos casos, se pueden transferir múltiples paquetes de Mapa de Color, cada uno con un subconjunto diferente del mapa de color utilizando los campos de compensación y longitud que se describen a continuación. El formato del Paquete de Mapa de Color en una modalidad se ilustra en la figura 17. Como se muestra en la figura 17, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Conteo de Artículo de Mapa de Color, Compensación de Mapa de Color, CRC de Parámetro, Datos de Mapa de Color, y CRC de Datos. En una modalidad, este tipo de paquete generalmente se identifica como un paquete Tipo 64 (Formato de Datos de Video y Paquete de Mapa de Color) tal como se especifica en el Campo de Tipo de Paquete (2 bytes) . Un cliente indica una habilidad para recibir Paquetes de Mapa de Color utilizando los campos de Tamaño de Mapa de Color y Ancho de Mapa de Color del Paquete de Capacidad de Cliente. 8. Paquetes de encapsulación de enlace inverso En una modalidad ejemplar, los datos son transferidos en la dirección inversa utilizando un Paquete de Encapsulación de Enlace Inverso. Un paquete de enlace de avance es enviado y la operación del enlace de MDDI (dirección de transferencia) es modificada o girada a la mitad de este paquete, de manera que los paquetes pueden ser enviados en la dirección inversa. El formato del paquete de Encapsulación de Enlace Inverso en una modalidad se ilustra en la figura 18. Como se muestra en la figura 187, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Indicadores de Enlace Inverso, Divisor de Velocidad Inversa, Longitud de Giro 1, Longitud de Giro 2, CRC de Parámetro, Todos Cero 1, Giro 1, Paquetes de Datos Inversos, Giro 2, y Todos Cero 2. En una modalidad, este tipo de paquete generalmente se identifica como un paquete Tipo 65. Para el Modo Externo, cada huésped debe tener la capacidad para generar este paquete y recibir datos, y cada cliente debe tener la capacidad para recibir y enviar datos al huésped con el fin de hacer uso de manera eficiente del protocolo deseado y velocidad resultante. La ejecución de este paquete es opcional para el Modo Interno, pero el Paquete de Encapsulación de Enlace Inverso se utiliza para que el huésped reciba datos desde el cliente.

El controlador de enlace MDDI se comporta en una forma especial mientras envía un Paquete de Encapsulación de Enlace Inverso. La MDDI tiene una señal estroboscópica que casi siempre es activada por el huésped como controlador del enlace. El huésped se comporta como si estuviera transmitiendo un cero para cada bit de las porciones de Paquetes de Datos Inversos y de Giro del paquete de Encapsulación de Enlace Inverso. El huésped activa una señal de MDDI_Estroboscópica en cada límite de bit durante los dos tiempos de giro y durante el tiempo asignado para paquetes de datos inversos. Es decir, el huésped activa la MDDI_Stb desde el inicio del campo de Todos Cero 1 hasta el final del campo Todos Cero 2. (Este es el mismo comportamiento que si estuviera transmitiendo datos todos cero) . El huésped inhabilita sus accionadores de línea de señal de datos de MDDI y generalmente se asegura que hayan sido completamente inhabilitados antes del último bit del campo de Giro 1, y después vuelve a habilitar sus accionadores de línea durante el campo de Giro 2, y generalmente se asegura que los accionadores hayan sido completamente rehabilitados antes del último bit del campo de Giro 2. El cliente lee el parámetro de Longitud de Giro y dirige las señales de datos hacia el huésped inmediatamente después del último bit en el campo de Giro 1. Es decir, el cliente sincroniza nuevos datos en el enlace en algunos bordes en elevación de la MDDI estroboscópica, tal como se especifica en la descripción de contenido de paquete a continuación, y en otros apartados de la presente invención. El cliente utiliza los parámetros de Longitud de Paquete y Longitud de Giro para conocer la duración en tiempo que tiene disponible para enviar paquetes al huésped. El cliente puede enviar paquetes de relleno o accionar las líneas de datos a un estado de cero cuando éste no tiene datos para enviar al huésped. Si las líneas de datos son accionadas a cero, el huésped interpreta esto como un paquete con una longitud de cero (no una longitud válida) y el huésped no acepta ningún paquete más proveniente del cliente por el tiempo que dura el Paquete de Encapsulación de Enlace Inverso actual. En una modalidad, el campo de Solicitud de Enlace Inverso del Paquete de Estado y Solicitud del Cliente, se puede utilizar para informar al huésped el número de bytes que necesita el cliente en el Paquete de Encapsulación de Enlace Inverso para enviar datos de regreso al huésped. El huésped intenta otorgar la solicitud asignando por lo 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 un sub-cuadro. El cliente puede enviar un Paquete de Estado y Solicitud del Cliente casi 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 un sub-cuadro. 9. Paquetes de capacidad del cliente Un huésped necesita conocer la capacidad del cliente (pantalla) con el que se está comunicando con el fin de configurar el enlace huésped-a-cliente en una forma deseada o generalmente óptima. Se recomienda que una pantalla envíe un Paquete de Capacidad del Cliente al huésped después que se adquiere la sincronización de enlace de avance. La transmisión de dicho paquete se considera como requerida cuando es solicitado por el huésped utilizando los Indicadores de Enlace Inverso en el Paquete de Encapsulación de Enlace Inverso. El Paquete de Capacidad del Cliente se utiliza para informar al huésped respecto de las capacidades de un cliente. Para Modo Externo, cada huésped debería tener la capacidad para recibir este paquete, y cada cliente debería tener la capacidad para enviar este paquete con el fin de utilizar completamente esta interfaz y protocolo. La ejecución de este paquete es óptima para el Modo Interno, debido a que las capacidades del cliente, tal como una pantalla, teclado u otro dispositivo de entrada/salida, en esta situación deberían estar bien definidas y deberían ser bien conocidas por el huésped al momento de la fabricación o ensamble en un componente o unidad sencilla de cierto tipo. El formato del paquete de Capacidad del Cliente en una modalidad se ilustra en la figura 19. Como se muestra en la figura 19, para esta modalidad, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de cCliente, Versión de Protocolo, Versión de Protocolo Mínimo, Capacidad de Velocidad de Datos, Capacidad de Tipo de Interfaz, 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 Color, Ancho RGB de Mapa de Color, Capacidad RGB, Capacidad Monocromo, Reservado 2, Capacidad Y Cr Cb, Capacidad Bayer, Reservado 3, Capacidad de Característica de Cliente, Velocidad de Cuadro de Video Máxima, Velocidad de Cuadro de Video Mínima, velocidad de Sub-cuadro Mínima, Profundidad de Memoria Intermedia de Audio, Capacidad de Canal de Audio, Capacidad de Velocidad de Muestra de Audio, Resolución de Muestra de Audio, Resolución de Muestra Mic, Capacidad de Velocidad de Muestra Mic, Formato de Datos de Teclado, Formato de Datos de Dispositivo de Señalamiento, Tipo de Protección de Contenido, Nombre Mfr., Código de Producto, Reservado 4, Número de Serie, Semana de Mfr., Año de Mfr., y CRC. En una modalidad ejemplar, este tipo de paquete generalmente se identifica como un paquete Tipo 66. 10. Paquetes de datos de teclado Un paquete de datos de teclado se utiliza para enviar datos de teclado desde el dispositivo del cliente al huésped. Se puede utilizar un teclado inalámbrico (o cableado) junto con varias pantallas o dispositivos de audio, incluyendo, pero no limitado a, un dispositivo de presentación de audio/pantalla de video montado en la cabeza. El Paquete de Datos de Teclado se basa en los datos de teclado recibidos desde uno de varios dispositivos conocidos tipo teclado al huésped. Este paquete también se puede utilizar en el enlace de avance para enviar datos al teclado. Un cliente indica una habilidad para enviar y recibir Paquetes de Datos de Teclado utilizando el Campo de Datos de Teclado en el Paquete de Capacidad de Cliente. En la figura 20 se muestra el formato de un Paquete de Datos de Teclado y contiene un número variable de bytes de información desde o para un teclado. Como se muestra en la figura 20, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de bCliente, Formato de Datos de Teclado, Datos de Teclado y CRC. Aquí, este tipo de paquete generalmente se identifica como un paquete Tipo 67. La ID de bCliente es un campo reservado, tal como se mencionó antes, y el CRC se ejecuta sobre 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 deberían ser idénticos al campo de Formato de Datos de Teclado en el Paquete de Capacidad del Cliente. Este valor no es para igualar 127. Los bits 15 a 7 son reservados para futuro uso y, por lo tanto, actualmente están puestos a cero. 11. Paquetes de datos de dispositivo de señalamiento Un paquete de datos de dispositivo de señalamiento se utiliza como un método, estructura o medio para enviar información de posición desde un ratón inalámbrico u otro dispositivo de señalamiento desde el cliente al huésped. Los datos también se pueden enviar al dispositivo de señalamiento en el enlace de avance utilizando este paquete. Un formato ejemplar de un Paquete de Datos de Dispositivo de Señalamiento se muestra en la figura 21, y contiene un número variable de bytes de información desde o para un dispositivo de señalamiento. Como se muestra en la figura 21, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de bCliente, Formato de Dispositivo de Señalamiento, Datos de Dispositivo de Señalamiento, y CRC. En una modalidad ejemplar, este tipo de paquete generalmente se identifica como un paquete Tipo 68 en el campo de tipo de 1 byte. 12. Paquetes de apagado de enlace Un Paquete de Apagado de Enlace en enviado desde el huésped al cliente como un método o medio para indicar que los datos de MDDI y señal estroboscópica serán apagados y entrarán a un estado de "hibernación" de bajo consumo de energía. Este paquete es útil para apagar el enlace y conservar la energía después que los mapas de bits estáticos son enviados desde un dispositivo de comunicación móvil a la pantalla, o cuando no hay información adicional para transferir desde un huésped a un cliente durante ese momento. La operación normal se reanuda cuando el huésped envía paquetes otra vez. El primer paquete enviado después de la hibernación es un paquete de encabezado de subcuadro. En la figura 22 se muestra un formato de un Paquete de Estado de Cliente para una modalidad. Como se muestra en la figura 22, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, CRC, y Todos Ceros. En una modalidad, este tipo de paquete generalmente se identifica como un paquete Tipo 69 en el campo de tipo de 1 byte . El campo de longitud de paquete utiliza 2 bytes para especificar el número total de bytes en el paquete sin incluir el campo de longitud de paquete. En una modalidad, la Longitud de Paquete de este paquete depende del Tipo de Interfaz o modo de enlace en efecto al momento en que el Paquete de Apagado de Enlace es enviado. Por lo tanto, la longitud de paquete típica se vuelve de 20 bytes para el modo Tipo 1 (un total de 22 bytes en el paquete) , 36 bytes para un modo Tipo 2 (un total de 38 bytes en el paquete) , 68 bytes para un enlace de modo Tipo 3 (un total de 70 bytes en el paquete) , y 132 bytes para un modo Tipo 4 (con un total de 134 bytes en el paquete) . El campo de Todos Ceros utiliza un número variable de bytes para asegurar que las señales MDDI_Datos estén a un nivel de lógica cero durante un tiempo suficiente para permitir al cliente comenzar a recuperar la sincronía utilizando solo MDDI_Stb antes de inhabilitar los accionadores de línea de un huésped. La longitud del campo Todos Ceros depende del Tipo de Interfaz o modo operativo del enlace en efecto al momento en que el Paquete de Apagado de Enlace es enviado. La longitud del campo Todos Ceros pretende producir 64 impulsos en MDDI_Stb para cualquier configuración de Tipo de Interfaz. Por lo tanto, la longitud Todos Ceros para cada tipo de interfaz 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 CRC utiliza 2 bytes que contienen un CRC de bytes de 16 bits de la Longitud de Paquete al Tipo de Paquete . En el estado de hibernación de baja energía, el accionador MDDI_DatosO es deshabilitado en un estado de alta impedancia comenzando después del 16avo a 48avo ciclo de MDDI_Stb o impulso después del último bit del campo de Todos Ceros. Para los enlaces Tipo 2, Tipo 3, o Tipo 4, las señales MDDI_Datosl a MDDI_DatosPwr7 también son colocadas en un estado de alta impedancia al mismo tiempo que el accionador MDDI_DatosO es deshabilitado. El huésped o el cliente pueden ocasionar que el enlace MDDI "despierte" del estado de hibernación tal como se describe en otro apartado, el cual es un avance clave, y ventaja de la presente invención. Como se describió en la definición del campo Todos Ceros, MDDI_Stb se activa para 64 ciclos siguiendo al MSB del campo CRC del Paquete de Apagado de Enlace para facilitar un apagado ordenado en el controlador del 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 que se envía el campo Todos Ceros, el accionador MDDI Stb en el huésped se deshabilita. 13. Paquetes de solicitud y estado del cliente El huésped necesita una cantidad pequeña de información proveniente del cliente de manera que pueda configurar el enlace huésped-a-cliente en una forma generalmente óptima. Se recomienda que el cliente envíe un Paquete de Solicitud y Estado del Cliente al huésped cada sub-cuadro. El cliente debería enviar este paquete como el primer paquete en el Paquete de Encapsulación de Enlace Inverso para asegurar que éste sea entregado de manera confiable al huésped. El reenvío de este paquete también se logra cuando es solicitado por un huésped utilizando los Indicadores de Enlace Inverso en el Paquete de Encapsulación de Enlace Inverso. El Paquete de Solicitud y Estado del Cliente se utiliza para reportar errores y estado al huésped. Para operación de modo externo, cada huésped debería tener la capacidad para recibir este paquete, y cada cliente debería tener la capacidad para enviar este paquete con el fin de emplear de manera adecuada u óptima el protocolo MDDI. Aunque también se recomienda que para operaciones internas, es decir huéspedes internos y clientes internos, debería haber soporte para este paquete, éste no se requiere. En la figura 23 se muestra el formato de un Paquete de Solicitud y Estado del Cliente. Como se muestra en la figura 23, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de cCliente, Solicitud de Enlace Inverso, Cambio de Capacidad, Cliente Ocupado, Conteo de Error CRC, y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 70 en el campo de tipo 1 byte, y típicamente utiliza una longitud fija preseleccionada de 12 bytes. El campo de Solicitud de Enlace Inverso se puede utilizar para informar al huésped del número de bytes que el cliente necesita en el Paquete de Encapsulación de Enlace Inverso para enviar datos de regreso al huésped. El huésped debería intentar otorgar la solicitud asignando por lo 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 un sub-cuadro para alojar datos. El cliente puede enviar un Paquete de Solicitud y Estado del 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 un subcuadro. A continuación se muestran detalles adicionales y ejemplos específicos de la forma en que los datos de enlace inverso son enviados de regreso al huésped. 14. Paquetes de transferencia del bloque de bits El Paquete de transferencia del bloque de bits provee un medio, estructura o método para recorrer regiones de la pantalla en cualquier dirección, generalmente copiando un bloque de píxeles desde una región rectangular a otra. Los clientes que tienen esta capacidad reportarán la capacidad en bit 0 del campo de Indicadores de Capacidad de Característica 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 24. Como se muestra en la figura 24, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Atributos de Datos de Píxel, Operación de Trama, Valor X Izquierdo Superior, Valor Y Izquierdo Superior, Ancho de Ventana, Altura de Ventana, Movimiento X de Ventana, Movimiento Y de Ventana, y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 71, y en una modalidad utiliza una longitud fija preseleccionada de 15 bytes. El campo de ID de hCliente de 2 bytes contiene información o valores que están reservados para una ID de Cliente, tal como se analiza en otro apartado. Debido a que este campo generalmente se reserva para futuro uso, el valor actual típicamente se establece en cero, estableciendo los bits a un nivel de lógica cero, aunque se puede establecer a otros valores o puede ser utilizado por un experto en la técnica para transferir la información deseada. En una modalidad, el campo de Atributos de Datos de Píxel de 2 bytes tiene valores que especifican el lugar donde los datos de píxel van a ser actualizados, con los Bits 1 y 0 seleccionando la pantalla en donde se van a actualizar los datos de píxel. Si una pantalla primaria en el cliente no soporta imágenes estéreo, entonces el cliente puede afectar los datos de píxel en la pantalla primaria para una de las combinaciones de bits 01, 10 u 11. Se recomienda que se utilice el valor 11 para dirigir la pantalla primaria en clientes que no soportan capacidad de pantalla estéreo. Cuando los Bits [1:0] tienen los valores 11 (doble lógica uno) , los datos de píxel son actualizados en la memoria intermedia de cuadro tanto del ojo izquierdo como del derecho, si los Bits [1:0] tienen los valores 10 (lógica uno, lógica cero) , los datos de píxel son actualizados en la memoria intermedia de cuadro del ojo izquierdo únicamente. Cuando los Bits [1:0] tienen los valores 01 (lógica cero, lógica uno) , los datos de píxel son actualizados en la memoria intermedia de cuadro del ojo derecho únicamente. Cuando los Bits [1:0] tienen los valores 00 (doble lógica cero) , los datos de píxel son actualizados en la memoria intermedia de la pantalla alterna especificada por los bits 8 a 11 a continuación. En una modalidad, el Bit 2 del campo de Atributos de Datos de Píxel especifica si la memoria intermedia para el ojo izquierdo u ojo derecho es o no una fuente de la imagen para esta operación. El Bit 2 solo aplica cuando los bits [1:0] no son iguales a 00, lo cual generalmente se implementa para indicar que no soporta datos fuente provenientes de la memoria intermedia de imágenes principal cuando el destino de la imagen es una de las pantallas alternas. El Bit 2 se utiliza para diferenciar o especificar entre las memorias intermedias de cuadro del ojo izquierdo y derecho como una fuente de datos. Cuando el Bit 2 es igual a 0, entonces la memoria intermedia de cuadro del ojo izquierdo es la fuente de datos, pero cuando el Bit 2 es igual a 1, entonces la memoria intermedia de cuadro del ojo derecho es la fuente de datos. El Bit 3 del campo de Atributos de Datos de Píxel especifica si la memoria intermedia utilizada para actualizar la pantalla o la memoria intermedia de imágenes fuera de línea va a ser la fuente de la imagen para esta operación. El Bit 3 también puede aplicar a una pantalla alterna si la pantalla alterna utiliza una memoria intermedia de imágenes fuera de línea. Sin embargo, esto no soporta que la fuente de datos provenga de la memoria intermedia de imágenes principal cuando el destino de la imagen es una pantalla alterna, o viceversa. Cuando el Bit 3 es igual a un valor de 0 o nivel de lógica cero, la memoria intermedia de imágenes utilizada para actualizar la pantalla es la fuente de datos. Cuando el Bit 3 es igual a un valor de 1 o nivel de lógica uno, la memoria intermedia de imágenes fuera de línea es la fuente de datos. Los Bits 7 y 6 del campo de Atributos de Datos de Píxel actúan como Bits de Actualización de Pantalla que especifican la memoria intermedia de cuadro en donde los datos de píxel se van a actualizar o escribir. Los efectos de los Bits de Actualización de Cuadro se describen con mayor detalle más adelante. Cuando los Bits [7:6] son ?01' (lógica cero, lógica uno) , los datos de píxel son escritos en una memoria intermedia de imágenes fuera de línea. Cuando los Bits [7:6] son ?00' (doble lógica cero), los datos de píxel son escritos en una memoria intermedia de imágenes que se utiliza para actualizar la pantalla. Cuando los Bits [7:6] son ll' (doble lógica uno), los datos de píxel son escritos en todas las memorias intermedias de imágenes. Si los Bits [7:6] son 10', esto se considera como un valor inválido. Estos bits actualmente están reservados para uso futuro. En esta situación, todo el comando es ignorado y ninguna memoria intermedia de cuadro es actualizada. Los Bits 11 a 8 del campo de Atributos de Datos de Píxel forman un entero sin firmar de 4 bits que especifica una pantalla alterna o ubicación de cliente alterna en donde los datos de píxel se van a actualizar. Los bits 0 y 1 se configuran igual a 00 (doble lógica cero) para que un cliente interprete los bits 11 a 8 como un número de pantalla alterno. Si los bits 1 y 0 no son iguales a 00, entonces los bits 8 a 11 generalmente se establecen igual a un valor o nivel de lógica cero. Los bits 4 a 5 y 12 a 15 se reservan para futuro uso y generalmente se establecen a un nivel o valores de lógica cero. En una modalidad, el campo de Operación de Trama de 2 bytes especifica cómo combinar los píxeles en las ubicaciones fuente y de destino para formar nuevos valores de píxel que van a ser escritos en una ubicación de imagen de destino. Las operaciones de trama definen la forma en que dos regiones rectangulares diferentes de igual tamaño en una memoria intermedia de cuadro se fusionan entre sí. El área de imagen de destino también es una de las dos imágenes que se fusionan entre sí. La segunda de las dos imágenes se denomina la imagen fuente. Si el cliente no soporta el campo de Operación de Trama tal como se especifica en el Paquete de Capacidad del Cliente, entonces el huésped generalmente envía este paquete con bits 3 a 0 igual a 3, y el cliente ignora los bits 3 a 0. En una modalidad, los Bits 3 a 0 se utilizan para especificar una operación de trama real utilizándolos o configurándolos igual a uno de los valores que se muestran en el cuadro VII a continuación para seleccionar la operación correspondiente que se muestra junto a ese valor. Es decir, cada valor especificado de Bits [3:0] listado en la primera columna produce como resultado la operación especificada en la segunda columna, y definida adicionalmente aquí para aclaración en la tercera columna.

CUADRO VII Los bits 5 a 4 se utilizan para especificar si los píxeles de destino están o no escritos en las ubicaciones de destino conforme se relacionan con el color transparente. La operación especificada por los bits 5 a 4 aplica si las operaciones de trama son soportadas o no por el dispositivo del cliente. Si el cliente no soporta las operaciones de trama, entonces el valor de píxel de destino resultante que se va a considerar para la operación definida por los bits 5 a 4 es igual al valor de píxel fuente únicamente. Cuando el valor de Bits [5:4] es igual a 00, entonces no se utiliza el color transparente. Un píxel de destino resultante es escrito en la ubicación de píxel de destino sin considerar el valor del color transparente definido por el Paquete de Habilitación de Color Transparente. El valor de Bits [5:4] que es igual a 01, actualmente se está reservando para uso futuro y por lo regular no se emplea, aunque está disponible para que un experto en la técnica establezca un uso relacionado para el mismo. Cuando el valor de Bits [5:4] es igual a 10, el píxel resultante no es escrito para la ubicación de píxel de destino si el píxel de destino resultante calculado por la operación de trama es igual al color transparente. De lo contrario, es escrito para la ubicación de píxel de destino. Cuando el valor de Bits [5:4] es igual a 11, el píxel resultante no es escrito para la ubicación del píxel de destino si el píxel de destino resultante calculado por la operación de trama es igual al color transparente. De lo contrario, el píxel resultante no es escrito para la ubicación de píxel de destino. Los bits 15 a 16 se reservan para futuro uso y, por lo tanto, generalmente se configuran igual a un valor o nivel de lógica cero. Los campos restantes se utilizan para especificar los valores X y Y de la coordenada de la esquina izquierda superior de la ventana que se va a mover, el ancho y la altura de la ventana que se va a mover, y el número de píxeles que la ventana va a ser movida horizontalmente, y verticalmente, en forma respectiva. Los valores positivos para los últimos dos campos ocasionan que la ventana sea movida hacia la derecha y hacia abajo, y los valores negativos ocasionan el movimiento a la izquierda y hacia arriba, respectivamente. El campo CRC (aquí 2 bytes) contiene un CRC de 16 bits de todos los bytes en el paquete, incluyendo la Longitud de Paquete. 15. Paquetes de relleno de área de mapa de bits El Paquete de Relleno de Área de Mapa de Bits provee un medio, estructura, o método para iniciar fácilmente una región de la pantalla a 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ística del Cliente del Paquete de Capacidad del Cliente. En la figura 25 se muestra una modalidad para el formato de un Paquete de Relleno de Área de Mapa de Bits. Como se muestra en la figura 25, en este caso, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Descriptor de Formato de Datos de Video, Atributos de Datos de Video, Operación de Trama, Valor de Relleno de Área de Píxel, Valor X Izquierdo Superior, Valor Y Izquierdo Superior, Ancho de Ventana, Altura de Ventana, y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 72 en el campo tipo 2 bytes, y utiliza una longitud fija preseleccionada de 24 bytes. El campo de ID de hCliente de 2 bytes contiene información o valores que están reservados para una ID de Cliente, tal como se analiza en otro apartado. Debido a que este campo generalmente se reserva para futuro uso, el valor actual por lo regular se configura a cero, estableciendo los bits a un nivel de lógica cero, aunque se puede establecer a otros valores o puede ser utilizado por un experto en la técnica para transferir información deseada. El campo de Descriptor de Formato de Datos de Video, en esta modalidad utilizando 2 bytes, especifica el formato del Valor de Relleno de Área de Píxel. El formato es el mismo que el mismo campo en el Paquete de Corriente de Video, el cual se analizó e ilustró anteriormente. El campo de Valor de Relleno de Área de Píxel (4 bytes) contiene el valor de píxel que se va a rellenar en la ventana especificada por los campos analizados anteriormente. El formato del píxel se especifica en el campo de Descriptor de Formato de Datos de Video. Los campos de Operación de Trama y Atributos de Datos de Píxel funcionan de manera similar a los mismos campos en el paquete de Transferencia de Bloque de Mapa de Bits que se analizó anteriormente, y se presentan con mayor detalle a continuación. Los campos restantes se utilizan para especificar los valores X y Y de la coordenada de la esquina izquierda superior de la ventana que se va a mover. Los campos de Valor X y Valor Y de la Coordenada Izquierda Superior de la Ventana utilizan 2 bytes, cada uno para especificar el valor X y Y de las coordenadas de la esquina izquierda superior de la ventana que se va a llenar. Los campos de Ancho y Altura de Ventana (2 bytes cada uno) especifican el ancho y altura de la ventana que se va a llenar. El campo CRC presentado (aquí 2 bytes) contiene un CRC de 16 bits de todos los bytes en el paquete incluyendo la Longitud de Paquete . 16. Paquetes de relleno de patrón de mapa de bits El Paquete de Relleno de Patrón de Mapa de Bits provee un medio o estructura para iniciar fácilmente una región de la pantalla a un patrón preseleccionado. Los clientes que tienen esta capacidad reportarán la capacidad en el bit 2 del campo de Capacidad de Característica del Cliente del Paquete de Capacidad del Cliente. La esquina izquierda superior del patrón de relleno está alineada con la esquina izquierda superior de la ventana que se va a rellenar, a menos que la compensación del patrón horizontal o vertical no sea cero. Si la ventana que se va a rellenar es más ancha o alta que el patrón de relleno, entonces el patrón se puede repetir en forma horizontal o vertical un número de veces para rellenar la ventana. La parte derecha o inferior del último patrón repetido es truncada según sea necesario. Si la ventana es más pequeña que el patrón de relleno, entonces el lado derecho o parte inferior del patrón de relleno puede ser truncado para que se ajuste a la ventana. Si una compensación de patrón horizontal no es cero, entonces los píxeles, entre el lado izquierdo de la ventana y el lado izquierdo más la compensación de patrón horizontal, se rellenan con los píxeles más a la derecha del patrón. La compensación de patrón horizontal va a ser menor que el ancho del patrón. De manera similar, si una compensación de patrón vertical no es cero, entonces los píxeles entre el lado superior de la ventana y la parte superior del lado más la compensación de patrón vertical, se rellenan con los píxeles más inferiores del patrón. La compensación del patrón vertical será menor que la altura del patrón. En la figura 26 se muestra una modalidad para el formato de un Paquete de Relleno de Patrón de Mapa de Bits. Como se muestra en la figura 26, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Descriptor de Formato de Datos, Atributos de Datos de Píxel, Operación de Trama, Valor X Izquierdo Superior, Valor Y Izquierdo Superior, Ancho de Ventana, Altura de Ventana, Ancho de Patrón, Altura de Patrón, Compensación de Patrón Horizontal, Compensación de Patrón Vertical, 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 Tipo 73 en el campo de tipo de 1 byte. El campo de ID de hCliente de 2 bytes contiene información o valores que se reservan para una ID de Cliente, tal como se analiza en otro apartado. Debido a que este campo generalmente se reserva para futuro uso, el valor actual típicamente se configura en cero, estableciendo lo bits a un nivel de lógica cero.

El campo de Descriptor de Formato de Datos de Video de 2 bytes especifica el formato del Valor de Relleno de Área de Píxel. La figura 11 ilustra la forma en que se codifica el Descriptor de Formato de Datos de Video. El formato es el mismo que el mismo campo en el Paquete de Corriente de Video. Los campos de Operación de Trama y Atributos de Datos de Píxel funcionan de manera similar a los mismos campos en el paquete de Transferencia de Bloque de Mapa de Bits que se analizó anteriormente, y se presentan con mayor detalle a continuación. Los campos restantes del Paquete de Relleno de Mapa de Bits se utilizan para especificar los valores X y Y de la coordenada de la esquina izquierda superior de la ventana que se va a rellenar, el ancho y la altura de la ventana que se va a rellenar, el ancho y altura de patrón que se va a utilizar como el patrón de relleno, y las compensaciones horizontal y vertical del patrón de datos de píxel desde los bordes izquierdo y superior, respectivamente, de la ventana especificada que se va a rellenar. Un campo de CRC de patrón (aquí 2 bytes) contiene un CRC de 16 bits de todos los bytes en el paquete desde la Longitud de Paquete al Descriptor de Formato de Video. Si este CRC no checa, entonces todo el paquete se deberá descartar. Un campo de CRC de Datos de Píxel de Patrón contiene un CRC de 16 bits únicamente de los Datos de Píxel de Patrón. Si este CRC no checa, entonces los Datos de Píxel de Patrón se pueden seguir utilizando pero el conteo de error de CRC se va a incrementar. Un campo de Datos de Píxel de Patrón contiene la 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. 17. Paquetes de memoria intermedia de cuadro de lectura Un Paquete de Memoria Intermedia de Cuadro de Lectura provee una estructura, medio o método para seleccionar, determinar o especificar una región rectangular de una memoria intermedia de cuadro en el cliente que se va a transmitir de regreso al huésped en el enlace inverso. El formato de los datos de píxel devueltos es en el formato natural de la pantalla, y ese formato generalmente se especifica en el campo de Descriptor de Formato de Datos de los Paquetes de Corriente de Video enviados en el enlace inverso al huésped. Los datos de píxel que son devueltos al huésped provienen de la memoria intermedia de imágenes que actualmente se está desplegando. Un cliente por lo regular utiliza la mayor cantidad de Paquetes de Corriente de Video en la mayor cantidad de Paquetes de Encapsulación de Enlace Inverso, según sea necesario, para devolver la región de pantalla especificada por el Paquete de Memoria Intermedia de Cuadro de Lectura. Los clientes que tienen esta capacidad pueden indicar esto o reportar la capacidad utilizando el bit 3 del campo de Indicadores de Capacidad de Característica del Cliente del Paquete de Capacidad del Cliente. El formato de una modalidad para un Paquete de Memoria Intermedia de Lectura se muestra en la figura 27. Como se muestra en la figura 27, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Atributos de Datos de Pantalla, Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, y CRC. En una modalidad, este tipo de paquete generalmente se identifica como un paquete Tipo 74 en el campo de tipo. El campo de Longitud de Paquete de 2 bytes especifica el número total de bytes en el paquete sin incluir el campo de longitud de paquete. En una modalidad, esta longitud de paquete se fija en 16. El campo de ID de hCliente de 2 bytes contiene información o valores que están reservados para una ID de Cliente, tal como se utiliza previamente. Debido a que este campo generalmente se reserva para futuro uso, el valor actual se configura en cero, estableciendo los bits a ?0' (nivel o estado de lógica cero) , aunque aquellos expertos en la técnica lo pueden emplear para transferir información deseada. En una modalidad, un campo de Atributos de Datos de Pantalla de 2 bytes tiene valores que especifican el lugar en donde se van a leer los datos de píxel, en donde el Bit 0 selecciona la memoria intermedia de cuadro de donde se van a leer datos de píxel. Cuando el Bit 0 es igual a un valor de 0 (lógica cero) , los datos de píxel se leen de la memoria intermedia de cuadro de una pantalla alterna especificada por los bit 8 a 11 a continuación. Cuando el Bit 0 es igual a un valor de 1 (lógica uno) , los datos de píxel se van a leer de la memoria intermedia de cuadro de la pantalla primaria. En una modalidad, el Bit 2 del campo de Atributos de Datos de Pantalla especifica si la memoria intermedia para el ojo izquierdo u ojo derecho es o no una fuente de los datos que se van a leer. Generalmente, el Bit 2 solo puede aplicar cuando la pantalla primaria soporta imágenes estéreo. Cuando el Bit 2 es igual a 0 (nivel de lógica cero) , entonces la memoria intermedia de cuadro del ojo izquierdo es la fuente de datos, pero cuando el Bit 2 es igual a 1 (nivel de lógica uno) , entonces la memoria intermedia de cuadro del ojo derecho es la fuente de datos. El Bit 3 del campo de Atributos de Datos de Pantalla especifica si la memoria intermedia utilizada para actualizar la pantalla o la memoria intermedia de imágenes fuera de línea va a ser la fuente de la imagen para esta operación. El Bit 3 también puede aplicar a una pantalla alterna si la pantalla alterna utiliza una memoria intermedia de imágenes fuera de línea. Sin embargo, esto no soporta que la fuente de datos provenga de la memoria intermedia de imágenes principal cuando el destino de la imagen es una pantalla alterna, o viceversa. Cuando el Bit 3 es igual a un valor de 0 o nivel de lógica cero, la memoria intermedia de imágenes utilizada para actualizar la pantalla es una fuente de datos. Cuando el Bit 3 es igual a un valor de 1 o nivel de lógica uno, una memoria intermedia de imágenes fuera de línea es la fuente de datos. Los Bits 11 a 8 del campo de Atributos de Datos de Pantalla especifican una pantalla o ubicación de cliente alterna en donde se van a leer los datos de píxel. El Bit 0 se configura igual a un valor de 0 (lógica cero) para que un cliente interprete los bits 11 a 8 como un número de pantalla alterno. Si el Bit 0 no es igual a 0, entonces los bits 8 a 11 generalmente se configuran igual a un valor o nivel de lógica cero. Los Bits 1, 4 a 7, y 12 a 15 se reservan para futuro uso y generalmente se configuran a niveles de lógica cero o valores cero. En una modalidad, los campos Borde Izquierdo X y Borde Superior Y de 2 bytes especifican la coordenada X del borde izquierdo y la coordenada Y del borde superior de la ventana de pantalla llenada por el campo de Datos de Píxel, mientras que los campos de Borde Derecho X y el Borde Inferior Y especifican la coordenada X del borde derecho, y la coordenada Y del borde inferior de la ventana que se está actualizando. En una modalidad, el campo CRC de 2 bytes especifica o contiene el CRC de todos los bytes en el paquete, incluyendo la Longitud de Paquete. 18. Paquetes de estado de energía de pantalla El Paquete de Estado de Energía de Pantalla provee una estructura, medio o método para colocar hardware controlado por el cliente específico, o relacionado con el cliente, conectado o de controlador en un estado de baja energía cuando un cliente, tal como una pantalla, no está siendo utilizado o no está en uso activo actual con el fin de reducir al mínimo el consumo de energía del sistema o vaciado de los recursos del sistema. Un paquete de este tipo es el más útil para aplicaciones de la interfaz o estructura y protocolo de interfaz para configuraciones u operaciones de modo externo. En esas aplicaciones, es más probable que el dispositivo externo esté operando en recursos de energía limitada tal como pilas, o que tenga otras restricciones y problemas de energía, por ejemplo, el sobrecalentamiento en espacios limitados, y así sucesivamente, de manera que se desee una condición operativa mínima durante periodos o inactividad o falta de uso. En una modalidad, un cliente indica una habilidad para responder a Paquetes de Estado de Energía de Pantalla utilizando el bit 9 del campo de Indicadores de Capacidad de Característica de Cliente del Paquete de Capacidad del Cliente. En la figura 28 se muestra un formato de una modalidad para un Paquete de Estado de Energía de Pantalla. Como se muestra en la figura 28, en una modalidad, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Estado de Energía y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 75 en el campo tipo de 2 bytes, y utiliza una longitud fija previamente seleccionada de 8 bytes. El campo de ID de hCliente de 2 bytes contiene información o valores que están reservados para una ID de Cliente, tal como se utilizó previamente. Debido a que este campo generalmente se reserva para uso futuro, el valor actual se establece a cero, estableciendo los bits a ?0' (nivel o estado de lógica cero) , aunque puede ser utilizado por aquellos expertos en la técnica para transferir información deseada. El campo de Estado de Energía, aquí 2 bytes, especifica la información utilizada para colocar un dispositivo específico, pieza de hardware, o equipo asociado con el cliente tal como una pantalla en el estado de energía especificado. Cuando se utiliza para pantallas, el Bit 0 de este campo especifica si el paquete aplica o no a la pantalla principal o a una pantalla alterna. Si el bit 0 es igual a 1, entonces el paquete aplica a la pantalla principal. Si el bit 0 es igual a 0, entonces el paquete aplica a la pantalla alterna especificada por los bits 11 a 8. El Bit 1 se reserva para futuro uso y generalmente se configura a cero. Los bits 3 a 2 del campo de Estado de Energía especifican el estado de energía de la pantalla seleccionado por los bits 11 a 8 y el bit 0. Cuando los Bits [3:2] tienen un valor de 00' , la pantalla seleccionada no está iluminada y debería estar consumiendo una cantidad mínima de energía, y el contenido de la memoria intermedia de cuadro no está garantizado para que sea retenido durante este estado. Cuando los Bits [3:2] tienen un valor de 01', la pantalla seleccionada no está iluminada y está consumiendo una cantidad relativamente mínima de energía y el contenido de la memoria intermedia de cuadro está garantizado para que sea retenido durante este estado. La pantalla puede consumir más energía en este estado que en el estado 00. El cliente puede indicar una habilidad para soportar el estado 01 utilizando el bit 10 del campo de Indicadores de Capacidad de Característica de Cliente del Paquete de Capacidad de Cliente. Cuando los Bits [3:2] del campo de Estado de Energía tienen un valor de XO' , la pantalla seleccionada está iluminada y está desplegando una imagen a partir de su memoria intermedia de cuadro asociada. El valor de ?ll' para los Bits [3:2] es un valor o estado reservado para futuro uso y no se emplea. Aquellos expertos en la técnica reconocerán que aunque es más útil para aplicaciones de pantalla, el uso de este paquete no queda limitado por esta invención únicamente a las pantallas y puede haber otras aplicaciones, configuraciones, o situaciones en las cuales el control de energía pueda ser necesario o deseado en relación con otros elementos de hardware con los cuales se está utilizando la MDDI, o por los cuales un cliente está controlando o comunicando. En estas situaciones, los Bits anteriormente descritos pueden tener funciones similares pero podrían estar activando elementos principales y secundarios de los mismos, o estableciendo niveles de energía y así sucesivamente, tal como se podrá entender. En una modalidad, los Bits 11 a 8 del campo de Estado de Energía forman un entero sin firmar de 4 bits el cual especifica la pantalla alterna a la que se aplica el estado de energía. El Bit 0 se establece a un valor de lógica cero para que el cliente interprete los bits 11 a 8 como un número de pantalla alterno. Si el bit 0 es igual a 1, entonces los bits 11 a 8 son cero. Los Bits 7 a 4 y los Bits 15 a 12 se reservan para futuro uso, y generalmente se establecerán al nivel o valores de lógica cero para aplicaciones o diseños actuales. El campo CRC de 2 bytes especifica o contiene el CRC de todos los bytes en el paquete, incluyendo la Longitud de Paquete. En el cuadro VIII a continuación, se muestra un resumen de los estados de energía de pantalla generalmente soportados por la estructura de interfaz o protocolo. Tal como se puede apreciar, se utilizan varias combinaciones de Bits de Capacidad de Característica de Cliente 10 y 9 para establecer, configurar o disparar varios de los estados de energía deseados. Una marca presente en una posición de fila y columna determinada indica que el estado de energía de pantalla especificado en la parte superior de esa columna es soportado para la combinación mencionada de los bits de Indicador de Capacidad de Característica del Cliente. Se puede apreciar que la primera y tercera filas del Cuadro VIII indican que solo se permite el Estado de Energía "10" cuando el cliente no tiene la habilidad para soportar el Paquete de Estado de Energía de Pantalla. Aún cuando un estado de energía de pantalla no puede ser enviado a una pantalla, la marca única indica que la pantalla está en un estado "siempre encendido" y no puede ser colocada en un estado de baja energía utilizando este conjunto de bits.

CUADRO VIII 19. Paquetes de transferencia de tipo ejecución El Paquete de Transferencia de Tipo Ejecución es un medio, estructura, o método a ser utilizado por el huésped para ordenar a un cliente hacer una transferencia al modo especificado en este paquete. Esta va a ser una de las configuraciones de tipo interfaz soportadas por el cliente, tal como se describe en el Paquete de Capacidad del Cliente. El huésped y el cliente deberían cambiar al tipo de interfaz de enlace inverso y de avance especificado justo después que este paquete es enviado. En la figura 29 se muestra el formato de una modalidad para un Paquete de Transferencia de Tipo Ejecución. Los huéspedes y clientes que soportan un tipo de interfaz diferente al Tipo 1 deberían proveer soporte para este paquete. Típicamente se recomienda que un huésped lea el Paquete de Solicitud y Estado del Cliente inmediatamente antes que envíe el Paquete de Transferencia de Tipo Ejecución para confirmar que el cliente esté en sincronización con el huésped. Como se muestra en la figura 29, en una modalidad, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Tipo de Interfaz, Reserva 1, Relleno de Retraso, y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 77 en el campo de tipo 2 bytes, y utiliza una longitud fija preseleccionada de 6 bytes, debido a que la longitud del campo de Relleno de Retraso no afecta el valor en el campo de Longitud de Paquete. En una modalidad, el campo de Tipo de Interfaz utiliza un valor de 1 byte para confirmar un nuevo tipo de interfaz que se va a utilizar o emplear para el enlace. El valor en este campo especifica o representa el tipo de interfaz en la siguiente forma. Los bits 2 a 0 definen el tipo de interfaz que se va a utilizar en el enlace de avance, en donde un valor de 1 significa o especifica una transferencia a un modo Tipo 1, un valor de 2 una transferencia al modo Tipo 2, un valor de 3 una transferencia al modo Tipo 3, y un valor de 4 una transferencia al modo Tipo 4. Los Bits 5 a 3 definen el Tipo de interfaz que se va a utilizar en el enlace inverso, en donde un valor de 1 significa o especifica una transferencia a un modo Tipo 1, un valor de 2 una transferencia al modo Tipo 2, un valor de 3 una transferencia al modo Tipo 3, y un valor de 4 una transferencia al modo Tipo 4. Los valores de 0, 5 a 7 actualmente se reservan para futuro uso. El campo de Relleno de Retraso ha sido creado como un medio, estructura o método para permitir el tiempo suficiente, por parte del sistema, para que el cliente se prepare o sea configurado para cambiar a uso o configuración para utilizar una nueva configuración de tipo interfaz al inicio del paquete que sigue inmediatamente al Paquete de Transferencia de Tipo Interfaz de Ejecución. Este campo contiene un grupo de bytes o valores de 8 bits que son puestos a, o iguales a un nivel o valor de lógica cero. El número de bytes utilizados en este campo es seleccionado de manera que se obtenga como resultado que este campo tenga una longitud equivalente a 64 ciclos MDDI_Stb. La longitud del campo de Relleno de Retraso se basa en la configuración del tipo de interfaz del enlace de avance la cual será de 16 bytes para un tipo de interfaz de enlace de avance Tipo 1, 32 bytes para un tipo de interfaz Tipo 2, 64 bytes para un tipo de interfaz Tipo 3, y 128 bytes cuando se especifique o utilice un tipo de interfaz de enlace de avance Tipo 4. El campo Reservado 1 (aquí 1 byte) queda reservado para futuro uso en la transmisión de información. Todos los bits en este campo generalmente se establecen a un nivel de lógica cero. El propósito de esos campos actualmente es ocasionar que todos los campos de 2 bytes posteriores 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 CRC (aquí 2 bytes) contiene un CRC de 16 bits de todos los bytes en el paquete incluyendo la Longitud de Paquete. 20. Paquetes de habilitación de canal de audio de avance Este paquete provee una estructura, método o medio que permite a un huésped habilitar o inhabilitar canales de audio en un cliente. Esta capacidad es útil de manera que un cliente (una pantalla por ejemplo) puede apagar los amplificadores de audio o elementos de circuito similares para ahorrar energía cuando no hay audio para ser emitido por el huésped. Esto es significativamente más difícil de ejecutar en forma implícita simplemente utilizando la presencia o ausencia de corrientes de audio como un indicador. El estado por omisión cuando el sistema de cliente es energizado es que todos los canales de audio son habilitados. En la figura 30 se muestra el formato de una modalidad de un Paquete de Habilitación de Canal de Audio de Avance. Como se muestra en la figura 30, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Máscara de Habilitación de Canal de Audio y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 78 en el campo de 1 byte, y utiliza una longitud preseleccionada fija de 4 bytes. 21. Paquetes de velocidad de muestra de audio inversa Este tipo de paquete provee una estructura, método o medio que permite a un huésped habilitar o inhabilitar canales de audio en un cliente. Esta capacidad es útil de manera que el cliente puede apagar los amplificadores de audio para ahorrar energía cuando no hay audio a ser emitido por el huésped. Esto es significativamente más difícil de ejecutar implícitamente utilizando la presencia o ausencia de corrientes de audio. El estado por omisión cuando un sistema de cliente es encendido o conectado al huésped es que se habilitan todos los canales de audio. Un sistema de audio conectado a un huésped y un cliente debería estar listo o tener la capacidad para emitir señales de audio en una forma pretendida o deseada aproximadamente con 100 msegundos o menos después que el cliente recibe un paquete de Habilitación de Canal de Audio de Avance que tiene por lo menos uno de los bits en el campo de Máscara de Habilitación de Canal de Audio habiendo hecho una transición de un estado o valor de cero a uno. El cliente indica una capacidad para responder a un paquete de Habilitación de Canal de Audio de Avance utilizando el valor establecido para el bit 15 del campo de Capacidad de Canal de Audio del Paquete de Capacidad de Cliente. Este paquete permite al huésped habilitar o inhabilitar el canal de audio de enlace inverso, y establecer la velocidad de muestra de datos de audio de esta corriente. El huésped selecciona una velocidad muestra que está definida para ser válida en el Paquete de Capacidad del Cliente. Si el huésped selecciona una velocidad de muestra inválida, entonces el cliente no enviará una corriente de audio al huésped, y un error apropiado, valor de error, o señal de error puede ser enviado al huésped en el Paquete de Reporte de Error del Cliente. El huésped puede inhabilitar la corriente de audio de enlace inverso estableciendo la velocidad muestra a un valor de 255. El estado por omisión asumido cuando el sistema de cliente es inicialmente energizado o conectado es con la corriente de audio de enlace inverso deshabilitada. En la figura 31 se muestra el formato de una modalidad para un Paquete de Velocidad de Muestra de Audio Inversa. Como se muestra en la figura 31, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Velocidad de Muestra de Audio, Reservado 1, y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 79, y utiliza una longitud fija preseleccionada de 4 bytes. 22. Paquetes de sobrecarga de protección de contenido digital Este paquete provee una estructura, método o medio que permite a un huésped y 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, el sistema de Protección de Contenido de Transmisión Digital (DTCP) , o 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 está utilizando queda especificado por un parámetro de Tipo de Protección de Contenido en este paquete. En la figura 32 se muestra el formato de una modalidad de un Paquete de Sobrecarga de Protección de Contenido Digital. Como se muestra en la figura 32, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de bCliente, Tipo de Protección de Contenido, Mensajes de Sobrecarga de Protección de Contenido, y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 80. 23. Paquetes de habilitación de color transparente El Paquete de Habilitación de Color Transparente es una estructura, método o medio que se utiliza para especificar cuál color es transparente en una pantalla y para habilitar o inhabilitar el uso de un color transparente para imágenes en despliegue. En una modalidad, los clientes o pantallas que tienen esta capacidad reportarán esa capacidad en el bit 4 del campo de Capacidad de Característica del Cliente del Paquete de Capacidad del Cliente. Cuando un píxel con el valor para color transparente es escrito en el mapa de bits, el color no cambia del valor previo. En la figura 33 se muestra el formato de un Paquete de Habilitación de Color Transparente. Como se muestra en la figura 33, en una modalidad, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Atributos de Datos de Pantalla, Reservado 1, Descriptor de Formato de Datos, Valor de Píxel Transparente, y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 81 en el campo tipo 1 byte, y utiliza una longitud fija preseleccionada de 16 bytes. El campo de ID de hCliente se reserva para uso como una ID de Cliente en futuras ejecuciones y típicamente se configura a una valor de cero (bits de lógica cero) . En una modalidad, un campo de Atributos de Datos de Pantalla de 2 bytes tiene valores que especifican el lugar en donde se va a aplicar el color de píxel transparente, en donde el Bit 0 selecciona la pantalla en donde se va a aplicar el color de píxel transparente. Cuando el Bit 0 es igual a un valor de 0 (lógica cero) , se aplica el color de píxel transparente a una pantalla alterna especificada por los bits 8 a 11 a continuación. Cuando el Bit 0 es igual a un valor de 1 (lógica uno) , el color de píxel transparente se aplica a la pantalla primaria. Los Bits 11 a 8 del campo del campo de Atributos de Datos de Pantalla especifican una pantalla o ubicación de cliente alterna en la que se va a aplicar el color de píxel transparente. El Bit 0 se configura igual a un valor de 0 (lógica cero) para que un cliente interprete los bits 11 a 8 como un número de pantalla alterno. Si el Bit 0 no es igual a 0, entonces los bits 8 a 11 generalmente se configuran igual a un nivel o valor de lógica cero, y se ignoran.

Los Bits l a 7, y 4 a l2 a l4 del campo de Atributos de Datos de Pantalla se reservan para futuro uso y generalmente se configuran a niveles de lógica cero o valores cero. Si el Bit 15 del campo de Atributos de Datos de Pantalla es igual a 0, entonces se deshabilita el modo de color transparente. Si, por otra parte, el Bit 15 es igual a 1, entonces se habilita el modo de color transparente y el color transparente queda especificado por los siguientes dos parámetros. Un campo Reservado 1 de 2 bytes se reserva para futuro uso. Todos los bits en este campo generalmente se configuran en cero (nivel o estado de lógica cero) . En una modalidad, un propósito de este campo es ocasionar que todos los campos de 2 bytes posteriores se alineen a una dirección de palabra de 16 bits y provocar que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits . En una modalidad, un campo de Descriptor de Formato de Video del paquete de Habilitación de Color Transparente utiliza 2 bytes para especificar el formato del Valor de Relleno de Área de Píxel. La figura 11 ilustra la forma en que se codifica el Descriptor de Formato de Datos de Video. El formato generalmente es el mismo que el mismo campo en el Paquete de Corriente de Video.

En una modalidad, un campo de Valor de Píxel transparente utiliza o asigna 4 bytes para el valor de píxel que se van a utilizar como el valor del color transparente. El formato de este píxel queda especificado en el campo de Descriptor de Formato de Datos de Video. El campo CRC utiliza 2 bytes para contener o expresar un CRC o todos los bytes en el paquete, incluyendo la Longitud de Paquete . 24. Paquetes de medición de retraso de viaje redondo El Paquete de Medición de Retraso de Viaje Redondo provee una estructura, método o medio que se utiliza para medir el retraso de propagación desde el huésped a un cliente (pantalla) más el retraso desde el cliente (pantalla) de regreso al huésped. Esta medición incluye, de manera inherente, los retrasos que existen en los accionadores y receptores de línea, y un sub-sistema de interconexión. Esta medición se utiliza para establecer los parámetros de divisor de velocidad de enlace inverso y retraso de giro en el Paquete de Encapsulación de Enlace Inverso, descrito anteriormente. Este paquete es más útil cuando el enlace MDDI está corriendo a la velocidad máxima pretendida para una aplicación particular. El paquete puede ser enviado en el modo Tipo 1 y a una velocidad de datos inferior para aumentar el rango de la medición de retraso de viaje redondo. La señal MDDI_Stb se comporta como si todos los datos de cero estuvieran siendo enviados durante los siguientes campos: ambos Tiempos de Guardia, Todo Cero, y el Periodo de Medición. Esto ocasiona que MDDI_Stb se active a la mitad de la velocidad de datos de manera que se puede utilizar como sincronía periódica 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 a través del uso del bit 18 del campo de Indicadores de Capacidad de Característica del Cliente del Paquete de Capacidad del 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 peor caso de retraso de viaje redondo con base en un retraso de cable máximo, y con base en los retrasos máximos del accionador y receptor. El huésped también puede conocer el retraso de viaje redondo por anticipado para un enlace MDDI utilizado en modo interno, debido a que este es un aspecto de elementos de diseño conocidos (longitudes de conductor, tipo de circuitería, y características, y así sucesivamente) del dispositivo en donde se está utilizando la interfaz. En la figura 34 se muestra el formato de un Paquete de Medición de Retraso de Viaje Redondo. Como se muestra en la figura 34, en una modalidad, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, CRC de Parámetro, Tiempo de Guardia 1, Periodo de Medición, Todos Cero, y Tiempo de Guardia 2. Este tipo de paquete generalmente se identifica como un paquete Tipo 82, y utiliza una longitud fija preseleccionada de 159 bits. En la figura 35 se ilustra la temporización de eventos que ocurren durante el Paquete de Medición de Retraso de Viaje Redondo. 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 CRC de Parámetro y Alineación Estroboscópica seguidos por los campos Todos Cero 1 y Tiempo de Guardia 1. Un retraso 3502 ocurre antes que el paquete alcance el dispositivo de pantalla del cliente o la circuitería de procesamiento. Conforme el cliente recibe el paquete, éste transmite los bytes Oxff, Oxff, y 30 de patrón 0x00 lo más práctico posible al comienzo del Periodo de Medición conforme a lo determinado por el cliente. El tiempo real que el cliente comienza a transmitir esta secuencia es retrasado desde el inicio del Periodo de Medición, desde el punto de vista del huésped. La cantidad de este retraso es sustancialmente el tiempo que toma al paquete propagarse a través de los accionadores y receptores de línea y el sub-sistema de interconexión (cables, conductores) . Se incurre en una cantidad similar de retraso 3504 para que el patrón se propague desde el cliente de regreso al huésped. Para determinar con precisión el tiempo de retraso de viaje redondo para señales que atraviesan a y desde el cliente, el huésped cuenta el número de periodos de tiempo de bit de enlace de avance que ocurren después del inicio del Periodo de Medición hasta que se detecta el comienzo de los bytes Oxff, Oxff, y 30 de secuencia 0x00 al momento de la llegada. Esta información se utiliza para determinar la cantidad de tiempo para que una señal de viaje redondo pase desde el huésped al cliente y de regreso nuevamente. Entonces, aproximadamente una mitad de esta cantidad es atribuida a un retraso creado para el paso de una vía de una señal al cliente. El huésped y el cliente accionan la línea a un nivel de lógica cero durante ambos tiempos de guardia para mantener las líneas MDDI_DATOS en un estado definido. Los tiempos de habilitación e inhabilitación del huésped y cliente durante ambos tiempos de guardia son tales que las señales MDDI_Datos están a un nivel bajo válido durante cualquier tiempo de retraso de viaje redondo válido. 25. Paquete de calibración de sesgo de enlace de avance El Paquete de Calibración de Sesgo de Enlace de Avance permite a un cliente o pantalla calibrarse para diferencias en el retraso de propagación de las señales MDDI_Datos con respecto a la señal MDDI_Stb. Sin compensación de sesgo de retraso, la velocidad máxima de datos generalmente se limita para considerar la variación potencial del peor caso en estos retrasos. Generalmente, este paquete solo es enviado cuando la velocidad de datos del enlace de avance se configura a una velocidad de aproximadamente 50 Mbps o menor. Después de enviar este paquete para calibrar la pantalla, la velocidad de datos se puede graduar hacia arriba por encima de los 50 Mbps. Si la velocidad de datos se fija muy arriba durante el proceso de calibración de sesgo, la pantalla se podría sincronizar con un nombre simbólico del periodo de bits, el cual podría ocasionar que el establecimiento de compensación de sesgo de retraso se apague por más de un periodo de bit, dando como resultado una sincronización de datos errónea. Se selecciona el Tipo de interfaz posible más grande o tipo de interfaz de velocidad de datos más elevada antes de enviar el Paquete de Calibración de Sesgo de Enlace de Avance de manera que se calibren todos los bits de datos existentes. En la figura 56 se muestra una modalidad del formato del Paquete de Calibración de Sesgo de Enlace de Avance. Tal como se muestra en la figura 56, este tipo de paquete está estructurado para tener campos de Longitud de Paquete (2 bytes), Tipo de Paquete, ID de hCliente, CRC de Parámetro, Todos Cero 1, Secuencia de Datos de Calibración, y Todos Cero 2. Este tipo de paquete generalmente se identifica como un paquete Tipo 83 en el campo de tipo, y en una modalidad tiene una longitud preseleccionada de 519.

Panel de control virtual El uso de un VCP 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 interfaz de usuario en el cliente se puede simplificar debido a que las pantallas, que permiten a un usuario ajustar parámetros tal como volumen de audio o brillantez de pantalla, pueden ser generados por el software de huésped en lugar de ser generados por uno o más microprocesadores en el cliente. El huésped tiene la capacidad para leer las configuraciones 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 al huésped cuáles de los parámetros de control pueden ser ajustados. Los códigos de control (Códigos VCP) y valores de datos asociados generalmente especificados, se utilizan para especificar controles y configuraciones en el cliente. Los Códigos VCP en la especificación MDDI se expanden a 16 bits para conservar la alineación adecuada del campo de datos en las definiciones de paquete, y en el futuro soportar valores suplementarios que son únicos para esta interfaz o futuras mejoras. 26. Paquete de característica VCP de solicitud El Paquete de Característica VCP de Solicitud provee un medio, mecanismo, o método para que el huésped solicite la configuración actual de un parámetro de control específico o todos los parámetros de control válidos. Por lo general, un cliente responde a un Paquete VCP con la información adecuada en un Paquete de Respuesta de Característica VCP. En una modalidad, el cliente indica una habilidad para soportar el Paquete de Característica VCP de Solicitud utilizando el bit 13 del campo de Indicadores de Capacidad de Característica del Cliente del Paquete de Capacidad del Cliente. En la figura 69 se muestra el formato del Paquete de Característica VCP de Solicitud en una modalidad. Como se aprecia en la figura 69, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Selector de Pantalla, código VCP de Establecimiento de Comandos de Control de Monitor (MCCS) , y CRC. Este tipo de paquete generalmente se identifica en una modalidad como un Tipo 128, el cual queda indicado en el campo tipo 2 bytes. La longitud de paquete, la cual especifica el número total de bytes en el paquete, sin incluir el campo de longitud de paquete, típicamente se fija para este tipo de paquete a una longitud de 10 bytes. El campo de ID de hCliente se reserva para uso como una ID de Cliente en ejecuciones futuras y típicamente se establece en cero. En una modalidad, un campo Selector de Pantalla de 2 bytes en el Paquete de Respuesta de Característica VCP designa una pantalla en donde aplicar el paquete VCP. El Bit 0 del campo de Selector de Pantalla selecciona la pantalla en la que se va a aplicar el paquete VCP. Cuando el Bit 0 es igual a 0, el paquete VCP aplica a una pantalla alterna especificada por los bits 11 a 8 a continuación. Si, por otra parte, el Bit 0 es igual a 1, nivel de lógica uno, entonces el paquete VCP aplica a una pantalla primaria. Actualmente los Bits 7 a 1 del campo de Selector de Pantalla se reservan para futuro uso y generalmente se configuran igual a un valor cero o los bits se configuran a un nivel de lógica cero. Los Bits 11 a 8 del campo de Selector de Pantalla utilizan un valor entero sin firmar de 4 bits para especificar una pantalla alterna en la que se va a aplicar el paquete VCP. Cuando el Bit 0 del campo de Selector de Pantalla es igual a 0 (nivel de lógica cero) el cliente interpreta los bits 11 a 8 como un número de pantalla alterno. Si el Bit 0 no es igual a 0, entonces los bits 11 a 8 se configuran a cero y se ignorarán. Los Bits 15 a 12 se reservan para futuro uso y generalmente se configuran a un valor de cero o cada bit se establece a un nivel de lógica cero. En una modalidad, un campo de Código VCP MCCS comprende 2 bytes de información que especifican el Parámetro de Código de Control VCP MCCS. Un valor en el rango de 0 a 255 ocasiona que un Paquete de Respuesta de Característica de VCP sea regresado con un solo artículo en la Lista de Respuesta de Característica de VCP correspondiente al código MCCS especificado. Un Código VCP MCCS de 65535 (Oxffff) solicita un Paquete de Respuesta de Característica de VCP con una Lista de Respuesta de Característica de VCP que contenga un Artículo de la Lista de Respuesta de Característica para cada control soportado por el cliente. Los valores de 256 a 65534, para este campo se reservan para futuro uso y actualmente no están en uso. El campo CRC de 2 bytes contiene un CRC de todos los bytes en el paquete, incluyendo la Longitud de Paquete. 27. Paquete de respuesta de característica de VCP El Paquete de Respuesta de Característica de VCP provee un medio, mecanismo o método para que un cliente responda a una solicitud de huésped con la configuración actual de un parámetro de control específico o todos los parámetros de control válidos. Por lo general, un cliente envía el Paquete de Respuesta de Característica de VCP en respuesta a un Paquete de Característica de VCP de Solicitud. Este paquete es útil para determinar la configuración actual de un parámetro específico, para determinar el rango válido para un control específico, para determinar si un control específico es soportado por el cliente, o para determinar el conjunto de controles que son soportados por el cliente. Si se envía una Característica de VCP de Solicitud la cual haga referencia a un control específico que no está ejecutado en el cliente, entonces un Paquete de Respuesta de Característica de VCP es devuelto con un solo artículo de la Lista de Respuesta de Característica de VCP correspondiente al control no ejecutado que contiene el código de error apropiado. En una modalidad, el cliente indica la capacidad para soportar el Paquete de Respuesta de Característica de VCP utilizando el bit 13 del campo de Capacidad de Característica de Cliente del Paquete de Capacidad del Cliente. En la figura 70 se muestra el formato del Paquete de Respuesta de Característica de VCP en una modalidad. Como se aprecia en la figura 70, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de cCliente, Selector de Pantalla, Versión MCCS, Número de Secuencia de Respuesta, Lista de Respuesta de Característica de VCP, y CRC. Este tipo de paquete generalmente se identifica en una modalidad como un Tipo 129, tal como se indica en el campo tipo 2 bytes. El campo ID de cCliente contiene información reservada para una ID de Cliente. Este campo está reservado para futuro uso y generalmente se configura en cero. En una modalidad, un campo Selector de Pantalla de 2 bytes en el Paquete de Respuesta de Característica VCP designa una pantalla en donde aplicar el paquete VCP. El Bit 0 del campo de Selector de Pantalla selecciona la pantalla en la que se va a aplicar el paquete VCP. Cuando el Bit 0 es igual a 0, el paquete VCP aplica a una pantalla alterna especificada por los bits 11 a 8 a continuación. Si, por otra parte, el Bit 0 es igual a 1, nivel de lógica uno, entonces el paquete VCP aplica a una pantalla primaria. Actualmente los Bits 7 a 1 del campo de Selector de Pantalla se reservan para futuro uso y generalmente se configuran igual a un valor cero o los bits se configuran a un nivel de lógica cero. Los Bits 11 a 8 del campo de Selector de Pantalla utilizan un valor entero sin firmar de 4 bits para especificar una pantalla alterna en la que se va a aplicar el paquete VCP. Cuando el Bit 0 del campo de Selector de Pantalla es igual a 0 (nivel de lógica cero) el cliente interpreta los bits 11 a 8 como un número de pantalla alterno. Si el Bit 0 no es igual a 0, entonces los bits 11 a 8 se configuran a cero y se ignorarán. Los Bits 15 a 12 se reservan para futuro uso y generalmente se configuran a un valor de cero o cada bit se establece a un nivel de lógica cero. El campo de Versión MCCS contiene 2 bytes de información que especifica la Versión de la Especificación MCCS VESA ejecutada por el cliente. El campo de Número de Secuencia de Respuesta de 2 bytes, en el Paquete de Respuesta de Característica VCP, contiene información o datos que especifican el número de secuencia de los Paquetes de Respuesta de Característica de VCP devueltos por el cliente. Un cliente regresa uno o más Paquetes de Respuesta de Característica de VCP en respuesta a un Paquete de Característica de VCP de Solicitud con un valor de Código de Control MCCS de 65535. Un cliente puede esparcir o transferir la lista de respuesta de característica en múltiples Paquetes de Respuesta de Característica de VCP. En este caso, el cliente debería asignar un número de secuencia o identificador a cada paquete sucesivo, y los números de secuencia de los Paquetes de Respuesta de Característica de VCP enviados en respuesta a un solo Paquete de Característica de VCP de Solicitud típicamente inician en cero y aumentan por uno.

El último Artículo de la Lista de Respuesta de Característica de VCP en el último Paquete de Respuesta de Característica de VCP debería contener un valor de Código de Control de VCP MCCS igual a Oxffff para identificar que el paquete es el último y que contiene el número de secuencia más elevado del grupo de paquetes devueltos. Si solo se envía un Paquete de Respuesta de Característica de VCP en respuesta a un Paquete de Característica de VCP de Solicitud, entonces el Número de Secuencia de Respuesta en ese paquete único generalmente se configura en cero y la Lista de Respuesta de Característica de VCP contiene un artículo de lista que tiene un Código de VCP MCCS en el Artículo de la Lista de Respuesta de Característica de VCP igual a Oxffff. Los campos de Valor Máximo y Valor Presente (figura 71) en el paquete de Artículo de Lista de Respuesta de Característica de VCP se establecen en cero cuando el Código de Control de VCP MCCS es igual a Oxffff. El campo de Número de Características en Lista contiene 2 bytes que especifican el número de Artículos de Lista de Respuesta de Característica de VCP que están en la Lista de Respuesta de Característica de VCP en este paquete, mientras que el campo de Lista de Respuesta de Característica de VCP es un grupo de bytes que contiene uno o más Artículos de Lista de Respuesta de Característica de VCP. En la figura 71 se muestra el formato de un solo Artículo de Lista de Respuesta de Característica de VCP en una modalidad. Como se muestra en la figura 71, cada Artículo de Lista de Respuesta de Característica de VCP tiene una longitud de 12 bytes y comprende los campos de Código de VCP MCCS, Código de Resultado, Valor Máximo, y Valor Presente. El campo de Código de VCP MCCS de 2 bytes contiene datos o información que especifica el Parámetro del Código de Control de VCP MCCS asociado con este artículo de lista. Solo los valores de Código de Control definidos en la versión 2 y posteriores de la Especificación MCCS VESA, se consideran como 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 de información respecto al Control de VCP MCCS especificado. Un valor de ?0' en este campo significa que no hay error, mientras que un valor de ?l' significa que el control especificado no está ejecutado en el cliente. Valores adicionales para este campo de 2 a 65535 están actualmente reservados para futuro uso y ejecución de otra aplicación contemplada por la técnica, pero no se utilizarán en este momento. El campo de Valor Máximo de 4 bytes especifica el valor posible más grande al que se puede fijar el Control MCCS especificado. Si el control solicitado no se ejecuta en el cliente, este valor se establece en cero. Si el valor devuelto es menor que 32 bits (4 bytes) de longitud, entonces el valor es vaciado en un entero de 32 bits dejando los bytes más significativos (no utilizados) establecidos en cero. El campo de Valor Presente de 4 bytes contiene información que especifica el valor presente del control No Continuo (NC) o Continuo (C) de VCP MCCS especificado. Si el control solicitado no se ejecuta en el cliente o si el control se ejecuta pero en un tipo de datos de Cuadro (T) , entonces este valor se establece en cero. Si el valor devuelto es menor que 32 bits (4 bytes) en longitud por la especificación MCCS VESA, entonces el valor es vaciado en un entero de 32 bits dejando los bytes más significativos (no utilizados) establecidos en cero. Si el código VCP MCCS corresponde a un control no continuo o tipo de datos de cuadro, entonces el campo de Valor Máximo se establece o selecciona para que sea cero. 28. Paquete de característica de VCP fijo El Paquete de Característica de VCP Fijo provee un medio, mecanismo o método para que un huésped establezca los valores de control de VCP tanto para controles continuos como no continuos en un cliente. En una modalidad, el cliente indica la capacidad para soportar el Paquete de Característica de VCP Fijo utilizando el bit 13 del campo de Capacidad de Característica del Cliente del Paquete de Capacidad del Cliente. En la figura 72 se muestra el formato del Paquete de Característica de VCP Fijo en una modalidad. Como se aprecia en la figura 72, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Selector de Pantalla, Código de VCP MCCS, Número de Valores en Lista, Lista de Valor de Control y CRC. Este tipo de paquete generalmente identificado como un Tipo 130, tal como se indica en el campo tipo 2 bytes, tiene 20 bytes de largo, exclusivo del campo de Longitud de Paquete. En una modalidad, un campo de ID de hCliente nuevamente utiliza un valor de 2 bytes para especificar o actuar como una ID de Cliente. Este campo se reserva para futuro uso y actualmente está configurado en cero. En una modalidad, un campo Selector de Pantalla de 2 bytes en el Paquete de Característica VCP Fijo designa una pantalla en donde aplicar el paquete VCP. El Bit 0 del campo de Selector de Pantalla selecciona la pantalla en la que se va a aplicar el paquete VCP. Cuando el Bit 0 es igual a 0, el paquete VCP aplica a una pantalla alterna especificada por los bits 11 a 8 a continuación. Si, por otra parte, el Bit 0 es igual a 1, nivel de lógica uno, entonces el paquete VCP aplica a una pantalla primaria.

Actualmente los Bits 7 a 1 del campo de Selector de Pantalla se reservan para futuro uso y generalmente se configuran igual a un valor cero o los bits se configuran a un nivel de lógica cero. Los Bits 11 a 8 del campo de Selector de Pantalla especifican una pantalla alterna en la que se va a aplicar el paquete VCP. Cuando el Bit 0 del campo de Selector de Pantalla es igual a 0 (nivel de lógica cero) el cliente interpreta los bits 11 a 8 como un número de pantalla alterno. Si el Bit 0 no es igual a 0, entonces los bits 11 a 8 se configuran a cero y se ignorarán. Los Bits 15 a 12 se reservan para futuro uso y generalmente se configuran a un valor de cero o cada bit se establece a un nivel de lógica cero. Un campo de Código de VCP MCCS, para el Paquete de Característica de VCP Fijo, utiliza 2 bytes de información o valores para especificar el Parámetro de Código de Control de VCP MCCS que se va a ajustar. El Número de Valores de 2 bytes en el Campo de Lista contiene información o valores que especifican el número de valores de 16 bits que existen en la Lista de Valor de Control. La Lista de Valor de Control por lo general contendrá un artículo, a menos que el Código de Control MCCS se refiera a un cuadro en el cliente. En el caso de controles que no están relacionados con un cuadro, la Lista de Valor de Control contendrá un valor que especifique el nuevo valor que va a ser escrito en el parámetro de control especificado por el campo de Código de VCP MCCS. Para controles relacionados con cuadro, el formato de los datos en la Lista de Valor de Control queda especificado por la descripción de parámetro del Código de VCP MCCS especificado. Si la lista contiene valores que son más grandes que un byte, entonces primero se transmite el byte menos significativo, consistente con el método definido en otro apartado. Por último, el campo CRC de 2 bytes consta de un CRC de 16 bits de todos los bytes en el paquete incluyendo la Longitud de Paquete. 29. Paquete de parámetro válido de solicitud El Paquete de Parámetro Válido de Solicitud se utiliza como un medio o estructura útil para solicitar que un cliente devuelva un Paquete de Respuesta de Parámetro Válido que contenga una lista de parámetros soportados por el control de Cuadro (T) o NC especificado. Este paquete solo debería especificar controles no continuos o controles que se relacionen con un cuadro en el cliente, y no debería especificar un valor de Código de VCP MCCS de 65535 (Oxffff) para especificar todos los controles. Si se especifica un Código de VCP MCCS inválido o no soportado, entonces se devuelve un valor de error apropiado en el Paquete de Respuesta de Parámetro Válido. En una modalidad, el cliente indica una capacidad para soportar el Paquete de Parámetro Válido de Solicitud utilizando el bit 13 del campo de Capacidad de Característica del Cliente del Paquete de Capacidad de Pantalla. En la figura 73 se muestra el formato del Paquete de Parámetro Válido de Solicitud en una modalidad. Como se aprecia en la figura 73, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, Selector de Pantalla, Código de VCP MCCS, y CRC. Este tipo de paquete generalmente se identifica en una modalidad como un Tipo 131, tal como se indica en el campo tipo 2 bytes. La longitud de paquete, tal como se indica en el Campo de Longitud de Paquete de 2 bytes, generalmente se establece para tener un número total de bytes en el paquete, sin incluir el campo de longitud de paquete de 8. La ID de hCliente nuevamente especifica la ID de Cliente, pero actualmente está reservada para uso futuro, tal como sería aparente para aquellos expertos en la técnica, y se configura a un valor de cero o nivel de lógica cero. En una modalidad, un campo Selector de Pantalla de 2 bytes en el Paquete de Parámetro Válido de Solicitud designa una pantalla en donde aplicar el paquete VCP. El Bit 0 del campo de Selector de Pantalla selecciona la pantalla en la que se va a aplicar el paquete VCP. Cuando el Bit 0 es igual a 0, el paquete VCP aplica a una pantalla alterna especificada por los bits 11 a 8 a continuación. Si, por otra parte, el Bit 0 es igual a 1, nivel de lógica uno, entonces el paquete VCP aplica a una pantalla primaria. Actualmente los Bits 7 a 1 del campo de Selector de Pantalla se reservan para futuro uso y generalmente se configuran igual a un valor cero o los bits se configuran a un nivel de lógica cero. Los Bits 11 a 8 del campo de Selector de Pantalla especifican una pantalla alterna en la que se va a aplicar el paquete VCP. Cuando el Bit 0 del campo de Selector de Pantalla es igual a 0 (nivel de lógica cero) el cliente interpreta los bits 11 a 8 como un número de pantalla alterno. Si el Bit 0 no es igual a 0, entonces los bits 11 a 8 se configuran a cero y se ignorarán. Los Bits 15 a 12 se reservan para futuro uso y generalmente se configuran a un valor de cero o cada bit se establece a un nivel de lógica cero. Un Campo de Código de VCP MCCS de 2 bytes para el Paquete de Parámetro Válido de Solicitud contiene un valor que especifica el Parámetro de Código de Control de VCP MCCS no continuo que se va a cuestionar. El valor en este campo debería corresponder a un control no continuo que es ejecutado en el cliente. Los valores 256 a 65535 (Oxffff) típicamente se reservan o consideran como inválidos, y se consideran como un control no ejecutado en la respuesta de error. El campo CRC, aquí 2 bytes, contiene un CRC de todos los bytes en el paquete, incluyendo la Longitud de Paquete. 30. Paquete de respuesta de parámetro válido Un Paquete de Respuesta de Parámetro Válido es enviado en respuesta a un Paquete de Parámetro Válido de Solicitud. Este se utiliza como un medio, método o estructura para identificar las configuraciones válidas para un control de VCP MCCS no continuo o un control que devuelve el contenido de un cuadro. Si el control se refiere a un cuadro en el cliente, entonces la Lista de Respuesta de Parámetro de VCP simplemente contiene la lista específica de valores de cuadro en secuencia que fueron solicitados. Si el contenido del cuadro no se puede ajustar en un solo Paquete de Respuesta de Parámetro Válido, entonces múltiples paquetes con Números de Secuencia de Respuesta en secuencia pueden ser enviados por el cliente. En una modalidad, un cliente indica una capacidad para soportar un Paquete de Respuesta de Parámetro Válido utilizando el bit 13 del campo de Capacidad de Característica del Cliente del Paquete de Capacidad del Cliente. Un huésped puede solicitar el contenido de un cuadro en la siguiente forma: el huésped envía un Paquete de Característica de VCP Fijo que contiene los parámetros necesarios o deseados tal como el parámetro de lectura/escritura, compensación de Cuadro de Búsqueda (LUT) , y selección RGB; después un Paquete de Parámetro Válido de Solicitud que especifica el control deseado es enviado por el huésped; después el cliente regresa uno o más Paquetes de Respuesta de Parámetro Válido que contienen los datos del cuadro. Esta secuencia de operaciones ejecuta una función similar a las funciones de lectura de cuadro descritas en el modelo de operación MCCS. Si un parámetro de cliente específico no es 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 debería contener un valor del parámetro en el cliente. En la figura 74 se muestra un formato del Paquete de Respuesta de Parámetro Válido para una modalidad. Tal como se aprecia en la figura 74, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de cCliente, Selector de Pantalla, Código de VCP MCCS, Código de Respuesta, Número de Secuencia de Respuesta, Valores de Número en Lista, Lista de Respuesta de Parámetro de VCP, y CRC. Este tipo de paquete generalmente se identifica para una modalidad como un Tipo 132, tal como se indica en el campo tipo 2 bytes. El campo ID de cCliente está reservado para el ID de Cliente futuro, tal como se apreció anteriormente. En una modalidad, un campo Selector de Pantalla de 2 bytes contiene información que designa en dónde aplicar el paquete VCP. El Bit 0 del campo de Selector de Pantalla selecciona la pantalla en la que se va a aplicar el paquete VCP. Cuando el Bit 0 es igual a 0, el paquete VCP aplica a una pantalla alterna especificada por los bits 11 a 8 a continuación. Si, por otra parte, el Bit 0 es igual a 1, nivel de lógica uno, entonces el paquete VCP aplica a una pantalla primaria. Actualmente los Bits 7 a 1 del campo de Selector de Pantalla se reservan para futuro uso y generalmente se configuran igual a un valor cero o los bits se configuran a un nivel de lógica cero. Los Bits 11 a 8 del campo de Selector de Pantalla especifican una pantalla alterna en la que se va a aplicar el paquete VCP. Cuando el Bit 0 del campo de Selector de Pantalla es igual a 0 (nivel de lógica cero) el cliente interpreta los bits 11 a 8 como un número de pantalla alterno. Si el Bit 0 no es igual a 0, entonces los bits 11 a 8 se configuran a cero y se ignorarán. Los Bits 15 a 12 se reservan para futuro uso y generalmente se configuran a un valor de cero o cada bit se establece a un nivel de lógica cero. En una modalidad, un Paquete de Código de VCP MCCS de 3 bytes contiene un valor que especifica un parámetro de Código de Control de VCP MCCS no continuo que es descrito por este paquete. Si un Código de Control de VCP MCCS inválido es especificado por un Paquete de Parámetro Válido de Solicitud, entonces el mismo valor de parámetro inválido será especificado en este campo con el valor apropiado en el campo de Código de Respuesta. Si el Código de Control MCCS es inválido, entonces la Lista de Respuesta de Parámetro de VCP tendrá una longitud de cero. El campo de Código de Respuesta contiene 2 bytes de información o valores que especifican la naturaleza de la respuesta con relación a la solicitud de información respecto al Control de VCP MCCS especificado. Si el valor en este campo es igual a 0, entonces no se considera un error presente para este tipo de datos, y se envía el último Paquete de Respuesta de Parámetro Válido en la secuencia, el cual tiene el Número de Secuencia de Respuesta más elevado. Si el valor en este campo es igual a 1, entonces no se considera un error presente, pero se enviarán otros Paquetes de Respuesta de Parámetro Válido los cuales tengan números de secuencia superiores. Si el valor en este campo es igual a 2, entonces el control especificado no se considera como ejecutado 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 de cero a su valor máximo) . Los valores para este campo de 4 a 65535 se reservan para uso futuro y generalmente para no ser utilizados. El campo de Número de Secuencia de Respuesta de 2 bytes especifica el número de secuencia de los Paquetes de Respuesta de Parámetro Válido devueltos por el cliente. El cliente regresa uno o más Paquetes de Respuesta de Parámetro Válido en respuesta a un Paquete de Parámetro Válido de Solicitud. El cliente puede esparcir la Lista de Respuesta de Parámetro de VCP en múltiples Paquetes de Respuesta de Parámetro Válido. En este último caso, el cliente asignará un número de secuencia a cada paquete sucesivo, y fijará el Código de Respuesta a 1 en todos excepto el último paquete en la secuencia. El último Paquete de Respuesta de Parámetro Válido en la secuencia tendrá el Número de Secuencia de Respuesta más elevado 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 existen en la Lista de Respuesta de Parámetro 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 Respuesta de Parámetro 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 continuos se especifican en la Especificación MCCS VESA. Por último, en esta modalidad, el campo CRC contiene un CRC de 16 bits de todos los bytes en el paquete, incluyendo la Longitud de Paquete.

Imágenes de corriente de video escalado La MDDI o mecanismo de protocolo, estructura, medio o método provee soporte para imágenes de corriente de video escalado que permiten al huésped enviar una imagen al cliente, es decir a una escala más grande o más chica que la imagen original, y la imagen escalada se copia en la memoria intermedia principal de imágenes. En otro apartado se provee una perspectiva general de la funcionalidad de la Corriente de Video Escalado y soporte de protocolo asociado. Una habilidad para soportar corrientes de video escalado queda definida por o dentro del Paquete de Capacidad de Corriente de Video Escalado, el cual es enviado en respuesta a un Paquete de Estado Específico de Solicitud. El encabezado del paquete de Corriente de Video Escalado que se analiza a continuación es ligeramente diferente del Paquete de Corriente de Video más simple cuyo encabezado contiene todo el contexto necesario para desplegar la imagen. El Paquete, de Corriente de Video Escalado utiliza un paquete de configuración para definir los parámetros del tamaño y posición de la ventana fuente y de destino, y un Paquete de Corriente de Video Escalado separado para transmitir los datos de píxel. Un cliente asigna almacenamiento interno asociado con cada corriente para almacenar los parámetros de corriente a partir del paquete de configuración y parte de los datos de píxel asociados con cada corriente. La cantidad de almacenamiento que se requiere para cada corriente variará dependiendo del tamaño de las imágenes fuente y de destino y de los valores especificados en el paquete de configuración. Por este motivo, el protocolo está diseñado para permitir al cliente ejecutar asignación de memoria dinámica para la cesión de almacenamiento asociado con cada corriente de video escalado. Resulta útil enviar una corriente de video a una pantalla que tiene un tamaño natural a la fuente de programa y tener la escala de pantalla y colocar la imagen en una forma adecuada para la aplicación final específica. La ejecución para escala en tiempo real de múltiples imágenes de video es lo suficientemente compleja para soportar esta característica opcional en el cliente. 31. Paquete de capacidad de corriente de video escalado El Paquete de Capacidad de Corriente de Video Escalado define las características de la imagen fuente de la corriente de video escalado en un cliente o utilizadas por un cliente. El formato del Paquete de Capacidad de Corriente de Video Escalado se muestra generalmente en la figura 75. Como se aprecia en la figura 75, en una modalidad, un Paquete de Capacidad de Corriente de Video Escalado está estructurado para tener Longitud de Paquete, Tipo de Paquete, ID de cCliente, Número Máximo de Corrientes, Tamaño X Máximo de Fuente, Tamaño Y Máximo de Fuente, Capacidad RGB, Capacidad Monocromo, Reservado 1, Capacidad Y Cr Cb, Reservado 2, y CRC. La longitud de paquete, en una modalidad, se selecciona para que sea un campo fijo de 20 bytes, como se muestra en el campo de longitud, incluyendo el campo de ID de cCliente de 2 bytes, el cual se reserva para uso para una ID de Cliente, de lo contrario se establece en cero, y el campo CRC. En una modalidad, el cliente indica una habilidad para soportar el Paquete de Capacidad de Corriente de Video Escalado utilizando un valor de parámetro de 143 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido. El campo de Número de Corrientes Máximo de 2 bytes contiene un valor para identificar el número máximo de corrientes simultáneas de video escalado que se pueden asignar a la vez. En una modalidad, un cliente debería negar una solicitud para asignar una corriente de video escalado si el número máximo de corrientes de video escalado ya está asignado. Si menos del número máximo de corrientes de video escalado es asignado, el cliente también puede negar una solicitud de asignación con base en otras limitaciones de recurso en el cliente. Los campos de Tamaño X y Tamaño Y Máximos de Fuente (2 bytes) especifican valores para el ancho y altura máximos, respectivamente, de la imagen de fuente de corriente de video escalado expresada como un número de píxeles . El campo de Capacidad RGB utiliza valores para especificar el número de bits de resolución que se pueden desplegar en el formato RGB. Si la corriente de video escalado no puede utilizar el formato RGB, entonces este valor se configura igual a cero. La palabra Capacidad RGB está compuesta de tres valores sin firmar separados en donde: los Bits 3 a 0 definen un número máximo de bits de azul (la intensidad del azul) en cada píxel, los Bits 7 a 4 definen el número máximo de bits de verde (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 píxel, mientras que los Bits 15 a 12 se reservan para futuro uso en definiciones futuras de capacidad, y generalmente se configuran en cero. El campo de Capacidad Monocromo de 1 byte contiene un valor que especifica el número de bits de resolución que se pueden desplegar en formato monocromo. Si la corriente de video escalado no puede utilizar el formato monocromo, entonces este valor se configura en cero. Los Bits 7 a 4 se reservan para futuro uso y, por lo tanto, se deberían fijar en cero ( 0') para aplicaciones actuales, aunque esto puede cambiar con el paso del tiempo, tal como lo podrán apreciar aquellos expertos en la técnica. Los Bits 3 a 0 definen el número máximo de bits de escala de grises que puede existir en cada píxel. Estos cuatro bits hacen posible especificar que cada píxel consta de 1 a 15 bits. Si el valor es cero, entonces el formato monocromo no es soportado por la corriente de video escalado. El campo Reservado 1 (aquí 1 byte) se reserva para futuro uso para proveer valores relacionados con la información o datos del Paquete de Corriente de Video Escalado. Por lo tanto, en la actualidad, todos los bits en este campo se configuran a una lógica ?0' . Un propósito de este campo es hacer que todos los campos de 2 bytes posteriores se alineen con una dirección de palabra de 16 bits y hacer que los campos de 4 bytes se alineen con una dirección de palabra de 32 bits.

El campo de Capacidad Y Cb Cr de 2 bytes contiene valores que especifican el número de bits de resolución que se pueden desplegar en el formato Y Cb Cr. Si la corriente de video escalado no puede utilizar el formato Y Cb Cr, entonces este valor es cero. La palabra Capacidad Y Cb Cr está compuesta de tres valores sin firmar separados en donde: los Bits 3 a 0 definen el número máximo de bits que especifican la muestra Cr; los Bits 7 a 4 definen el número máximo de bits que especifican la muestra Cb; los Bits 11 a 8 definen el número máximo de bits que especifican la muestra Y; y en donde los Bits 15 a 12 se reservan para futuro uso y generalmente se configuran en cero. El campo de Bits de Capacidad de 1 byte contiene un conjunto de indicadores que especifican las capacidades asociadas con la corriente de video escalado. Los indicadores se definen de la siguiente manera: el Bit 0 abarca los datos de Píxel en el Paquete de Corriente de Video Escalado que pueden estar en un formato empaquetado. Un ejemplo de los datos de píxel alineados en bytes y empaquetados se muestra anteriormente en la figura 13. El Bit 1 se reserva para futuro uso y generalmente está configurado en cero; el Bit 2 también se reserva para futuro uso y se configura en cero; el Bit 3 abarca las corrientes de video escalado que pueden ser especificadas en el formato de datos de mapa de color. El mismo cuadro de mapa de color se utiliza para las corrientes de video escalado, tal como se utiliza para la memoria intermedia principal de imágenes y los planos de imagen de alfa-cursor. El mapa de color se configura utilizando el Paquete de Mapa de Color que se describe en otro apartado; y los Bits 7 a 4 se reservan para futuro uso y generalmente se configuran en cero. El campo Reservado 2 (aquí 1 byte) se reserva para futuro uso para proveer valores relacionados con la información o datos del Paquete de Corriente de Video Escalado. Por lo tanto, actualmente, todos los bits en este campo se configuran a una lógica x0' . Un propósito de este campo es ocasionar que todos los campos posteriores de 2 bytes se alineen a una dirección de palabra de 16 bits y ocasionar que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits. 32. Paquete de configuración de corriente de video escalado El Paquete de Configuración de Corriente de Video Escalado provee un medio, estructura o método utilizado para definir los parámetros de la corriente de video escalado y el cliente utiliza la información para asignar almacenamiento interno para que la imagen sea guardada en memoria intermedia y escalada. Una corriente puede ser des-asignada mediante el envío de este paquete con los campos de Tamaño de Imagen X y Tamaño de Imagen Y igual a cero. Las corrientes de video escalado que han sido des-asignadas pueden ser re-asignadas más adelante con los mismos parámetros de corriente o con parámetros diferentes . En una modalidad, un cliente indica una habilidad para soportar el Paquete de Configuración de Corriente de Video Escalado utilizando un valor de parámetro de 143 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido, y utilizando un valor no cero en el campo de Número Máximo de Corrientes del Paquete de Capacidad de Corriente de Video Escalado. En la figura 76 se muestra el formato del Paquete de Configuración de Corriente de Video Escalado. Como se aprecia en la figura 76, en una modalidad, un Paquete de Configuración de Corriente de Video Escalado está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, ID de Corriente, Descriptor de Formato de Datos de Video, Atributos de Datos de Píxel, 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 Longitud de Paquete de 2 bytes especifica el número total de bytes en el paquete, sin incluir el campo de longitud de paquete. En una modalidad, esta longitud de paquete se fija en 24. El campo de Tipo de Paquete de 2 bytes emplea un valor de 136 para identificar el paquete como un Paquete de Configuración de Corriente de Video Escalado. El campo ID de hCliente de 2 bytes se reserva para futuro uso como una ID de Cliente, y generalmente se configura a Todos los Bits en el valor de lógica cero durante el momento, o hasta que un usuario de protocolo determina cuáles son los valores de ID que se van a utilizar, tal como se conocerá. El campo de ID de Corriente utiliza 2 bytes para especificar un identificador único para la ID de Corriente. Este valor es asignado por el huésped y oscila en valor de cero al valor máximo de ID de Corriente especificado en el Paquete de Capacidad de Cliente. El huésped debe administrar cuidadosamente el uso de valores de ID de Corriente para asegurar que a cada corriente activa se le asigne un valor único, y que las corrientes que ya no están activas sean des-asignadas o reasignadas. En una modalidad, el campo de Descriptor de Formato de Datos de Video utiliza 2 bytes para especificar el formato de cada píxel en los Datos de Píxel en la presente corriente en el presente paquete. El formato de datos de píxel debería cumplir por lo menos con uno de los formatos válidos para un plano de imagen de alfa-cursor tal como debería ser definido en un Paquete de Capacidad de Imagen de Alfa-Cursor, u otro patrón de imagen predefinido, tal como se definirá generalmente dentro de los otros paquetes que se analizaron anteriormente. El Descriptor de Formato de Datos de Video define el formato de píxel para el paquete actual únicamente y no implica que un formato constante seguirá siendo utilizado durante la vida de una corriente de video particular. La figura 12 ilustra una modalidad de cómo está codificado el Descriptor de Formato de Datos de Video, y tal como se analizó anteriormente para otros paquetes. Por ejemplo, como se aprecia en las figuras 12A a 12D, y para uso en una modalidad, cuando los bits [15:13] son iguales a ?000', entonces los datos de video constan de una disposición de píxeles de monocromo en donde el número de bits por píxel queda definido por los bits 3 a 0 de la palabra de Descriptor de Formato de Datos de Video. Los Bits 11 a 4 generalmente se reservan para futuro uso o aplicaciones y se configuran en cero en esta situación. Cuando los bits [15:13] son iguales a los valores 001', entonces los datos de video constan de una disposición de píxeles de color que especifican, cada uno, un color a través de un mapa de color (paleta) . En esta situación, los bits 5 a 0 de la palabra Descriptor de Formato de Datos de Video definen el número de bits por píxel, y los bits 11 a 6 generalmente se reservan para futuro uso o aplicaciones y se configuran igual a cero. Cuando los bits [15:13] son iguales a los valores ?010', entonces los datos de video constan de una disposición de píxeles de color en donde el número de bits por píxel de rojo queda definido por los bits 11 a 8, el número de bits por píxel de verde queda definido por los bits 7 a 4, y el número de bits por píxel de azul queda definido por los bits 3 a 0. En esta situación, el número total de bits en cada píxel es la suma del número de bits utilizados para rojo, verde y azul. Sin embargo, cuando los bits [15:13] son iguales a los valores o secuencia ?011', tal como se muestra en la figura 12D, entonces los datos de video constan de una disposición de datos de video en formato YCbCr 4:2:2 con información de luminancia y crominancia, en donde el número de bits por píxel de luminancia (Y) queda definido por los bits 11 a 8, el número de bits del componente Cb queda definido por los bits 7 a 4, y el número de bits del componente Cr queda definido por los bits 3 a 0. El número total de bits en cada píxel es la suma del número de bits utilizados para rojo, verde y azul. Los componentes Cb y Cr son enviados a la mitad de la velocidad que Y. Además, las muestras de video en la porción de Datos de Píxel de este paquete se organizan de la siguiente forma: Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3,... en donde Cbn y Crn están asociados con Yn y Yn+1, y Cbn+2 y Crn+2 están asociados con Yn+2 y Yn+3, y así sucesivamente. Yn, Yn+1, Yn+2, y Yn+3 son valores de luminancia de cuatro píxeles consecutivos en una sola fila de izquierda a derecha. Para los cuatro formatos que se analizaron anteriormente, el Bit 12, el cual se designa como "P" en las figuras, especifica si se empacan o no las muestras de Datos de Píxel, o datos de píxel alineados en bytes. Un valor de ?0'en este campo indica que cada píxel en el campo de Datos de Píxel está alineado en bytes con un límite de bytes MDDI. Un valor de l' indica que cada píxel y cada color dentro de cada píxel en los Datos de Píxel están empacados contra el píxel previo o color dentro de un píxel que no deja bits sin utilizar. En una modalidad, un campo de Atributos de' Datos de Píxel de 2 bytes tiene valores que son interpretados de la siguiente forma, en donde los Bits 1 y 0 están reservados para futuro uso, generalmente configurados para lógica cero por el momento, y el Bit 2 indica si los Datos de Píxel están o no en formato entrelazado. Cuando el Bit 2 es 0, entonces los Datos de Píxel están en el formato progresivo estándar. El número de fila (coordenada Y de píxel) es incrementado por 1 cuando se avanza de una fila a la siguiente. Cuando el Bit 2 es 1, entonces los Datos de Píxel están en el formato entrelazado. El número de fila (coordenada Y de píxel) es incrementado por 2 cuando se avanza de una fila a la siguiente. En una modalidad, el Bit 3 indica si los Datos de Píxel están o no en formato de píxel alterno. Esto es similar al modo de entrelazado estándar habilitado por el bit 2, pero con el entrelazado en vertical en lugar de horizontal. Cuando el Bit 3 es 0, los Datos de Píxel son generados o colocados en el formato progresivo estándar. El número de columna (coordenada X de píxel) se incrementa por 1 conforme cada píxel sucesivo es recibido. Cuando el Bit 3 es 1, entonces los Datos de Píxel son generado o colocados en formato de píxel alterno. El número de columnas (coordenada X de píxel) se incrementa por 2 conforme se recibe cada píxel. Los Bits 4 a 15 también se reservan para futuro uso y generalmente se configuran a un nivel o valores de lógica cero para aplicaciones o diseños actuales. 33. Paquete de reconocimiento de corriente de video escalado El Paquete de Reconocimiento de Corriente de Video Escalado permite a un cliente reconocer la recepción de un Paquete de Configuración de Corriente de Video Escalado. El cliente puede indicar una habilidad para soportar el Paquete de Reconocimiento de Corriente de Video Escalado a través de un valor de parámetro de 143 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido y a través de un valor no cero en el campo de Número Máximo de Corrientes del Paquete de Capacidad de Corriente de Video Escaldo. En la figura 77 se muestra de manera general el formato del Paquete de Reconocimiento de Corriente de Video Escalado. Como se puede apreciar en la figura 77, en una modalidad, un Paquete de Reconocimiento de Corriente de Video Escalado está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Corriente, ID de cCliente, Código ACK, y CRC. El campo de Longitud de Paquete de 2 bytes se utiliza para especificar el número total de bytes, excluyendo el campo de longitud de paquete, con un valor de 10 para este tipo de paquete, mientras que un Tipo de Paquete de 137 identifica un paquete como el Paquete de Reconocimiento de Corriente de Video Escalado. El campo ID de cCliente de 2 bytes queda reservado para futuro uso para la ID de Cliente, y generalmente se configura en cero. El campo de ID de Corriente de 2 bytes especifica un identificador único para la ID de Corriente. Este es el mismo valor asignado por el huésped en el Paquete de Configuración de Corriente de Video Escalado. El campo de Código Ack de 2 bytes provee valores que contienen un código que describe el resultado de un intento por actualizar la corriente especificada de video escalado. En una modalidad, los códigos se definen de la siguiente manera: 0 - El intento de asignación de corriente fue exitoso. 1 - el intento de des-asignación de corriente fue exitoso. 2 - intento inválido de asignar una ID de corriente que ya ha sido asignada. 3 - intento inválido de des-asignar una ID de corriente que ya ha sido des-asignada. 4 - el cliente no soporta las corrientes de video escalado. 5 - los parámetros de corriente son inconsistentes con la capacidad del cliente. 6 -valor de ID de corriente más grande que el valor máximo permitido por el cliente. 7 - recursos insuficientes disponibles en el cliente para asignar la corriente especificada. El campo CRC de 2 bytes contiene el CRC de todos los bytes en el paquete incluyendo la Longitud de Paquete. 34. Paquete de corriente de video escalado El Paquete de Corriente de Video Escalado se utiliza para transmitir los datos de píxel asociados con una corriente específica de video escalado. El tamaño de la región referenciado por este paquete queda definido por el Paquete de Configuración de Corriente de Video Escalado. El cliente puede indicar una habilidad para soportar el Paquete de Corriente de Video Escalado utilizando un valor de parámetro de 143 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido y utilizando una respuesta de asignación de corriente de video escalado exitosa en el campo de Código Ack del Paquete de Reconocimiento de Corriente de Video Escalado. En la figura 78 se muestra de manera general el formato de una modalidad del Paquete de Corriente de Video Escalado. Como se observa en la figura 78, un Paquete de Corriente de Video Escalado está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, ID de Corriente, Atributos de Datos de Píxel, Conteo de Píxel, CRC de Parámetro, Datos de Píxel, y CRC de Datos de Píxel. El campo Tipo Paquete de 2 bytes utiliza un valor de 18 para identificar un paquete como un Paquete de Corriente de Video Escalado. El campo ID de hCliente queda reservado para la ID de Cliente, y generalmente se configura en cero. Tal como se mencionó anteriormente, el campo de ID de Corriente de 2 bytes especifica un identificador único para la ID de Corriente. Este valor queda especificado por el huésped en el Paquete de configuración de Corriente de Video Escalado y confirmado en el Paquete de Reconocimiento de Corriente de Vídeo Escalado. En una modalidad, el campo de Atributos de Datos de Píxel de 2 bytes tiene valores que especifican el ruteo de los datos de píxel y la actualización de pantalla o ubicaciones de memorias intermedias. Estos valores se pueden apreciar en una modalidad. En una modalidad, el campo de Atributos de Datos de Píxel de 2 bytes tiene valores que especifican el ruteo de los datos de píxel y la actualización de pantalla o ubicaciones de memoria intermedia. Estos valores son, en una modalidad, interpretados de la siguiente forma: con los Bits 1 y 0 seleccionando la pantalla a donde se van a enrutar los datos de píxel. Para valores de bit de XI' ó 00', los datos de píxel son desplegados para ambos ojos, para los valores de bit 10', los datos de píxel son enrutados únicamente al ojo izquierdo, y para los valores de bit ?01', los datos de píxel son enrutados únicamente para el ojo derecho. Los Bits 7 y 6 son los Bits de Actualización de Pantalla que especifican la memoria intermedia de cuadro en donde se van a escribir los datos de píxel. Los efectos de los Bits de Actualización de Cuadro se describen con mayor detalle en otro apartado. Cuando los Bits [7:6] son ?01' , los datos de píxel son escritos en la memoria intermedia de imagen fuera de línea. Cuando los Bits [7:6] son 00' , los datos de píxel son escritos en la memoria intermedia de imagen utilizada para actualizar la pantalla. Cuando los Bits [7:6] son ?ll' , los datos de píxel son escritos en todas las memorias intermedias de imagen. Si los Bits [7:6] son 10', este se considera como un valor inválido. Estos bits actualmente se reservan para futuro uso. En esta situación, los datos de píxel serían ignorados y no serían escritos en ninguna de las memorias intermedias de imagen. Los Bits 2 a 5 y 8 a 15 se reservan para futuro uso y generalmente se establecen a un nivel o valores de lógica cero. El campo de Conteo de Píxel de 2 bytes especifica el número de píxeles en el campo Datos de Píxel a continuación. El campo CRC de Parámetro de 2 bytes tiene el CRC de todos los bytes desde la Longitud de Paquete al Conteo de Píxeles. Si este CRC no checa, entonces se descarta todo el paquete. El campo de Datos de Píxel de 2 bytes contiene la información de video sin procesar que se va a escalar y después a desplegar. Los datos son formateados en la forma descrita por el campo de Descriptor de Formato de Datos de Video. Los datos son transmitidos en una fila a la vez, tal como se definió anteriormente. El campo de CRC de Datos de Píxel de 2 bytes contiene un CRC únicamente de los Datos de Píxel. Si este CRC no checa, entonces los Datos de Píxel pueden seguir siendo utilizados pero se incrementa el conteo de error de CRC. 35. Paquete de estado específico de solicitud El Paquete de Estado Específico de Solicitud provee un medio, mecanismo, o método para que un huésped solicite que el cliente envíe un paquete de capacidad o estado de regreso al huésped, tal 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, por lo general, establecerá el bit 17 en el campo de Capacidad de Característica del Cliente del Paquete de Capacidad del Cliente, si el cliente tiene la capacidad para responder al Paquete de Estado Específico de Solicitud. Un método conveniente a ser utilizado por el huésped para determinar todos los tipos de paquetes de estado que un cliente puede devolver o transferir es utilizar el Paquete de Lista de Respuesta de Estado Válido que se describe en otro apartado. El cliente puede indicar una habilidad para responder con el Paquete de Lista de Respuesta de Estado Válido utilizando el bit 21 del campo de Capacidad de Característica del Cliente del Paquete de Capacidad del Cliente. En la figura 79 se muestra, de manera general, el formato de una modalidad de un Paquete de Estado Específico de Solicitud. Como se aprecia en la figura 79, un Paquete de Estado Específico de Solicitud está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de hCliente, ID de Paquete de Estado, y CRC. El campo de Longitud de Paquete especifica el número total de bytes en el paquete sin incluir el campo de longitud de paquete, y por lo general, se fija a un valor de 10 para este tipo de paquete. Un Tipo de Paquete de 138 identifica el paquete como un Paquete de Estado Específico de Solicitud. El campo ID de hCliente (2 bytes) se reserva para futuro uso para una ID de Cliente, y se establece en cero por el momento, 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 enviar al huésped. Los tipos de paquete típicos son: 66 - El Paquete de Capacidad del 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 Respuesta de Estado Válido es enviado, e identifica los tipos exactos de paquetes de capacidad y estado que el cliente puede enviar. 141 - El Paquete de Capacidad del Cliente Personal es enviado por el cliente. 142 - El paquete de Reporte de Error del Cliente es enviado por el cliente. 143 - El Paquete de Capacidad de Corriente de Video Escalado es enviado por el cliente. 144 - El Paquete de Identificación del Cliente es enviado por el cliente. Los Tipos de Paquete 56 a 63 se pueden utilizar para la capacidad específica del fabricante y los identificadores de estado. El campo CRC nuevamente contiene un CRC de todos los bytes en el paquete, incluyendo la Longitud de Paquete. 36. Paquete de lista de respuesta de estado válido El Paquete de Lista de Respuesta de Estado Válido provee al huésped una estructura, medio o método para tener una lista de paquetes de estado y capacidad que el cliente tiene la capacidad de devolver. Un cliente puede indicar una habilidad para soportar el Paquete de Lista de Respuesta de Estado Válido utilizando el bit 21 del campo de Capacidad de Característica del Cliente del Paquete de Capacidad del Cliente. En la figura 80 se muestra, de manera general, el formato de una modalidad de un Paquete de Lista de Respuesta de Estado Válido. Como se aprecia en la figura 80, un Paquete de Lista de Respuesta de Estado Válido está estructurado para tener campos de Longitud de paquete, Tipo de Paquete, ID de cCliente, Número de Valores en Lista, Lista de Respuesta de Parámetro Válido, y CRC. La longitud de paquete para este tipo de paquete por lo general se fija en un valor de 10, y un valor de tipo 139 identifica el paquete como un Paquete de Respuesta de Estado Válido. El campo ID de cCliente se reserva para futuro uso como la ID de Cliente, y por lo general, se configura en cero. El campo de Número de Valores en Lista de 2 bytes especifica el número de artículos en la siguiente Lista de Respuesta de Parámetro Válido. El campo de Lista de Respuesta de Parámetro Válido contiene una lista de parámetros de 2 bytes que especifican los tipos de paquetes de capacidad o estado que el cliente puede enviar al huésped. Si el cliente ha indicado que éste puede responder al Paquete de Estado Específico de Solicitud (utilizando el bit 21 del campo de Capacidad de Característica del Cliente en el Paquete de Capacidad del Cliente) entonces éste tiene la capacidad para enviar por lo menos el Paquete de Capacidad del Cliente (Tipo de Paquete = 66) y el Paquete de Lista de Respuesta de Estado Válido (Tipo de Paquete = 139) . Los Tipos de Paquete que pueden ser enviados por el cliente y que pueden ser incluidos en esta lista, junto con sus respectivas asignaciones para propósitos de una modalidad son: 66 - Paquete de Capacidad del Cliente. 133 - Paquete de Capacidad de Imagen de Alfa-Cursor. 139 - Paquete de Lista de Respuesta de Estado Válido, que identifica los tipos exactos de paquetes de capacidad y estado que el cliente puede enviar. 141 - Paquete de Capacidad de Pantalla Personal. 142 - Paquete de Reporte de Error de Cliente. 143 - Paquete de Capacidad de Corriente de Video Escalado. 144 - Paquete de Identificación de Cliente. 145 - Paquete de Capacidad de Pantalla Alterna. Los tipos de paquete 56 a 63 se pueden utilizar para capacidad específica del fabricante e identificadores de estado. El campo CRC contiene un CRC de todos los bytes en el paquete, incluyendo la Longitud de Paquete. 37. Paquete de capacidad de pantalla personal El Paquete de Capacidad de Pantalla Personal provee un conjunto de parámetros que describen las capacidades de un dispositivo de pantalla personal, tal como una pantalla de cabeza montada o cristales de pantalla. Esto permite al huésped personalizar la información de pantalla de acuerdo con las capacidades específicas de un cliente. Un cliente, por otra parte, indica una capacidad para enviar el Paquete de Capacidad de Pantalla Personal utilizando un parámetro correspondiente en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido. En la figura 81 se muestra, por lo general, el formato de una modalidad de un Paquete de Capacidad de Pantalla Personal. Como se puede ver en la figura 81, un Paquete de Capacidad de Pantalla Personal está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de cCliente, Distribución de Sub-Píxeles, Forma de Píxel, Campo de Visión Horizontal, Campo de Visión Vertical, Cruce de Ejes Visual, Imagen Izquierda/Derecha, Ver A Través, Máxima Brillantez, Capacidad Óptica, IPD Mínima, IPD Máxima, Lista de Puntos de Curvatura de Campo y CRC. En una modalidad, el valor del campo de Longitud de Paquete se fija en 68. Un valor Tipo Paquete de 141 identifica un paquete como un Paquete de Capacidad de Pantalla Personal. El campo de ID de cCliente queda reservado para futuro uso y, por lo general, se configura en cero por el momento. El campo de Distribución de Sub-Píxeles especifica la distribución física de un sub-píxel desde arriba hacia abajo y de izquierda a derecha, utilizando valores de: 0 para indicar que una distribución de sub-píxel no está definida; 1 para indicar una tira roja, verde, azul; 2 para indicar una tira azul, verde, roja; 2 para indicar un píxel cuádruple, que tiene una disposición de 2 por 2 sub-píxeles de rojo en la parte izquierda superior, azul en la parte derecha inferior, y dos sub-píxeles verdes, uno en la parte izquierda inferior y el otro en la parte derecha superior; 4 para indicar un píxel cuádruple con una disposición de 2 por 2 sub-píxeles de rojo en la parte izquierda inferior, azul en la parte derecha superior, y dos sub-píxeles verdes, uno en la parte izquierda superior y el otro en la parte derecha inferior; 5 para indicar un triángulo (Triple) ; 6 para indicar un mosaico con rojo, verde y azul en traslape (por ejemplo, pantalla LCOS con color secuencial en campo); y con valores 7 a 255 generalmente reservados para futuro uso. El campo de Forma de Píxel especifica la forma de cada píxel que está compuesto de sub-píxeles en una configuración específica, utilizando un valor de: 0 para indicar que una forma de sub-píxel no está definida; 1 para indicar redondo; 2 para indicar cuadrado; 3 para indicar rectangular; 4 para indicar ovalado; 5 para indicar elíptico; y en donde los valores 6 a 255 están reservados para futuro uso en la indicación de formas deseadas, tal como puede ser apreciado por aquellos expertos en la técnica.

Un Campo de Visión Horizontal de 1 byte (HFOV) especifica el campo de visión horizontal en incrementos de 0.5 grados (por ejemplo, si HFOV es 30 grados, este valor es 60) . Si este valor es cero, entonces HFOV no se especifica. Un Campo de Visión Vertical de 1 byte (VFOV) especifica el campo de visión vertical en incrementos de 0.5 grados (por ejemplo, si VFOV es 30 grados, este valor es 60) . Si este valor es cero, entonces VFOV no se especifica. Un Campo de Cruce de Eje Visual de 1 byte especifica el cruce de eje visual en incrementos de dioptría (l/m) de 0.01 (por ejemplo, si el cruce de eje visual es 2.22 metros, este valor es 45) . Si este valor es cero, entonces el Cruce de Eje Visual no se especifica. Un campo de Traslape de Imagen Izquierda/Derecha de 1 byte especifica el porcentaje de traslape de la imagen izquierda y derecha. El rango permisible del traslape de imagen en porcentaje es 1 a 100. Los valores de 101 a 255 son inválidos y, por lo general, no se utilizan. Si este valor es cero, entonces el traslape de imagen no se especifica. Un campo de Ver A Través de 1 byte especifica el porcentaje de ver-a-través de la imagen. El rango permisible de ver-a-través en porcentaje es 0 a 100. Los valores de 101 a 254 son inválidos y no se utilizarán. Si este valor es 255, entonces el porcentaje de ver-a-través no se especifica. Un campo de Brillantez Máxima de 1 byte especifica la máxima brillantez en incrementos de 20 nits (por ejemplo, si la máxima brillantez es 100 nits, este valor es 5) . Si este valor es cero, entonces la brillantez máxima no se especifica. Un campo de Indicadores de Capacidad Óptica de 2 bytes contiene varios campos que especifican las capacidades ópticas de la pantalla. Estos valores de bit por lo general se asignan de acuerdo con: Los Bits 15 a 5 se reservan para futuro uso y, por lo general, se fijan a un estado de lógica cero. El Bit 4 selecciona el Ajuste de Foco de Lente de Ojo, en donde un valor de ?0' significa que la pantalla no tiene ajuste de foco de lente de ojo, y un valor de l' significa que la pantalla tiene un ajuste de foco de lente de ojo. Los Bits 3 a 2 seleccionan una Función Binocular de acuerdo con: un valor de 0 significa que la pantalla es binocular y que puede desplegar imágenes de 2 dimensiones (2D) únicamente; 1 significa que la pantalla es binocular y que puede desplegar imágenes de 3 dimensiones (3D) ; 2 significa que la pantalla es monocular, y 3 queda reservado para futuro uso.

Los Bits 1 a 0 seleccionan la Simetría de Curvatura de Campo de Izquierda-Derecha, en donde un valor de 0 significa que el valor de curvatura de Campo no está definido. Si este campo es cero, entonces todos los valores de curvatura de campo de Al a E5 se configuran en cero, excepto para el punto C3, el cual especifica una distancia focal de la pantalla o se establecerá en cero para indicar que la distancia focal no está especificada. Un valor de 1 significa que pantallas de Izquierda y Derecha tienen la misma simetría; 2 significa que las pantallas de Izquierda y Derecha se reflejan en el eje vertical (columna C) ; y 3 se reserva para futuro uso. El campo de Distancia Inter-Pupilar (IPD) Mínima de 1 byte especifica la distancia inter-pupilar mínima en milímetros (mm) . Si este valor es cero, entonces la distancia inter-pupilar mínima no se especifica. El campo de Distancia Inter-Pupilar (IPD) Máxima de 1 byte especifica la distancia inter-pupilar máxima en milímetros (mm) . Si este valor es cero, entonces la distancia inter-pupilar máxima no se especifica. El campo de Lista de Puntos de Curvatura de Campo contiene una lista de 25 parámetros de 2 bytes que especifican la distancia focal en milésimas de dioptría (l/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 Puntos de Curvatura de Campo están etiquetados de Al a E5, tal como se muestra en la figura 82. Los puntos se van a distribuir de manera uniforme en el área activa de la pantalla. La columna C corresponde al eje vertical de la pantalla y la fila 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 filas 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 CRC contiene un CRC de todos los bytes en el paquete, incluyendo la Longitud de Paquete. 38. Paquete de reporte de error de cliente El Paquete de Reporte de Error de Cliente actúa como un mecanismo o medio para permitir a un cliente proveer al huésped 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. Ejemplos de estos errores incluyen: el cliente pudo haber recibido instrucciones de operar en modo que éste no soporta, el cliente pudo haber recibido un paquete que contenga algunos parámetros que estén fuera de rango o más allá de la capacidad del cliente, el cliente pudo haber recibido instrucciones de entrar a un modo en una secuencia inadecuada. El Paquete de Reporte de Error de Cliente se puede utilizar para detectar errores durante la operación normal, pero es más útil para que el diseñador e integrador del sistema diagnostiquen problemas en el desarrollo e integración de los sistemas de huésped y cliente. Un cliente indica su habilidad para enviar un Paquete de Reporte de Error de Cliente utilizando un valor de parámetro de 142 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido. En la figura 83 generalmente se muestra el formato de una modalidad de un Paquete de Reporte de Error de Cliente. Como se aprecia en la figura 83, un Paquete de Reporte de Error de Cliente está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de cCliente, Número de Artículos de Lista, Lista de Código de Error, y CRC. Un valor de Tipo Paquete de 142 identifica un paquete como un Paquete de Reporte de Error de Cliente. El campo de ID de cCliente queda reservado para futuro uso y generalmente se establece en cero por el momento. El campo de Número de Artículos de Lista (2 bytes) especifica el número de artículos en la siguiente Lista de Código de Error. El campo de Lista de Código de Error (aquí 8 bytes) es una lista que contiene uno o más artículos de Lista de Reporte de Error. En la figura 84 se muestra el formato de un solo artículo de Lista de Reporte de Error. En una modalidad, como se muestra en la figura 84, cada Artículo de Lista de Reporte de Error tiene exactamente 4 bytes de longitud, y tiene una estructura en una modalidad que comprende: un campo de Código de Error de Pantalla de 2 bytes que especifica el tipo de error que se está reportando, un campo de Sub-Código de Error de 2 bytes que especifica un nivel mayor 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 queda definida por el fabricante del cliente. Un Sub-Código de Error no tiene que ser definido para cada Código de Error de Pantalla, y en esos casos donde el Sub-Código de Error no está definido, el valor se establece en cero. La definición específica de cada Sub-Código de Error queda definida por el fabricante del cliente. 39. Paquete de identificación del cliente El Paquete de Identificación del Cliente permite a un cliente devolver datos de identificación en respuesta a un Paquete de Estado Específico de Solicitud. En una modalidad, un cliente indica una habilidad para enviar el Paquete de Identificación del Cliente utilizando un valor de parámetro de 144 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido. Resulta útil que el huésped pueda determinar el nombre del fabricante y el número de modelo del dispositivo del cliente simplemente leyendo estos datos del cliente. La información se puede utilizar para determinar si el cliente tiene capacidades especiales que no se describen en el Paquete de Capacidad del Cliente. Existen, potencialmente, dos métodos, medios o mecanismos para leer la información de identificación del cliente. Uno es a través del uso del Paquete de Capacidad del Cliente, el cual contiene campos similares a aquellos en la estructura EDID base. El otro método es a través del uso del Paquete de Identificación del Cliente que contiene un conjunto más rico de información en comparación con los campos similares en el Paquete de Capacidad del Cliente. Esto permite a un huésped identificar a los fabricantes a los que no se les ha asignado un código EISA de 3 caracteres, y permite que los números de serie contengan caracteres alfanuméricos . En la figura 85 generalmente se muestra el formato de una modalidad de un Paquete de Identificación del Cliente. Como se puede apreciar en la figura 85, un Paquete de Identificación del Cliente está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de cCliente, Semana de Mfr, Año de Mfr., Longitud de Nombre de Mfr, Longitud de Nombre del Producto, Longitud del Número de Serie, Secuencia del Nombre del Fabricante, Secuencia del Nombre del Producto, Secuencia del Número de Serie, y CRC. El campo de Tipo de Paquete de 2 bytes contiene un valor que identifica el paquete como un Paquete de Identificación del Cliente. Este valor se selecciona para que sea 144 en una modalidad. El campo de ID de cCliente (2 bytes) nuevamente se reserva para futuro uso para la ID de Cliente, y generalmente se establece en cero. El campo de CRC (2 bytes) contiene un CRC de 16 bits de todos los bytes en el paquete incluyendo la Longitud de Paquete. El campo Semana de Fabricación de 1 byte contiene un valor que define la semana de fabricación de la pantalla. Por lo menos en una modalidad, este valor se ubica en el rango de 1 a 53 si es soportado por el cliente. Si este campo no es soportado por el cliente, entonces generalmente se configura 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 compensación del año 1990 como punto de partida, aunque se podrían utilizar otros años base. Los años en el rango de 1991 a 2245 pueden ser expresados 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, éste se debería establecer a un valor de cero.

Los campos de longitud de Nombre Mfr, Longitud de Nombre del Producto, y Longitud de Número de Serie contienen, cada uno, valores de 2 bytes que especifican la longitud del campo de Secuencia de Nombre del Fabricante incluyendo cualesquiera caracteres de terminación nula o de relleno nulo, la longitud del campo de Secuencia de Nombre del Producto incluyendo cualesquiera caracteres de terminación nula o de relleno nulo, y la longitud del campo de Secuencia de Número de Serie incluyendo cualesquiera caracteres de terminación nula o de relleno nulo, respectivamente . Los campos de Secuencia de Nombre del Fabricante, Secuencia de Nombre del Producto, y Secuencia de Número de Serie contienen, cada uno, un número variable de bytes especificados por la longitud de los campos de Nombre Mfr, Nombre del Producto, y Número de Serie, respectivamente, que contienen una secuencia ASCII que especifica el fabricante, nombre del producto, y número de serie alfanumérico de la pantalla, respectivamente. Cada una de estas secuencias es finalizada por lo menos por un carácter nulo. 40. Paquete de capacidad de pantalla alterna El Paquete de Capacidad de Pantalla Alterna se utiliza como un medio, estructura o método para indicar la capacidad de pantallas alternas fijas al controlador de cliente de MDDI. Este es enviado en respuesta a un Paquete de Estado Específico de Solicitud. Cuando es lanzado, un dispositivo del cliente envía un Paquete de Capacidad de Pantalla Alterna para cada pantalla alterna que es soportada. Si un cliente tiene más de una pantalla alterna, entonces el cliente debería enviar, generar o proveer múltiples Paquetes de Capacidad de Pantalla Alterna, uno para cada pantalla, en respuesta a un solo Paquete de Estado Específico de Solicitud, aunque algunas configuraciones pueden utilizar múltiples Paquetes de Estado Específico de Solicitud según se desee, aunque esto es menos eficiente. El cliente puede enviar Paquetes de Capacidad de Pantalla Alterna en lo que se puede denominar como un "orden no secuencial" con base en el valor del campo de Número de Pantalla Alterna. El cliente puede indicar una habilidad para enviar un Paquete de Capacidad de Pantalla Alterna a través de un valor de parámetro de 145 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido. Para sistemas MDD1 operados en modo interno, puede resultar común tener más de una pantalla conectada a un controlador de cliente de MDDI. Una aplicación ejemplar es un teléfono móvil con una pantalla grande en el interior del pliegue y una pantalla más pequeña en el exterior. No es necesario que un cliente en modo interno devuelva un Paquete de Capacidad de Pantalla Alterna por dos motivos potenciales. Primero, el huésped puede ya estar programado o, de otra forma, informado sobre las capacidades durante la fabricación debido a que se utilizan en un dispositivo o alojamiento común. Segundo, debido al ensamble de los dos, el cliente no puede ser desconectado o separado fácilmente de una conexión con el huésped, y el huésped puede contener una copia dura codificada de las capacidades del cliente, o por lo menos saber que no cambian con un cambio en el cliente, tal como ocurriría de otra forma. El campo de Número de Pantallas Alternas del Paquete de Capacidad del Cliente se utiliza para reportar que más de una pantalla está fija y el Paquete de Capacidad de Pantalla Alterna reporta la capacidad de cada pantalla alterna. El paquete de corriente de video contiene 4 bits en el campo de Atributos de Datos de Píxel para dirigir cada pantalla alterna en el dispositivo del cliente. En la figura 89 generalmente se muestra el formato de una modalidad de un Paquete de Capacidad de Pantalla Alterna. Como se puede apreciar en la figura 86, un Paquete de Capacidad de Pantalla Alterna está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de cCliente, Número de Pantalla Alterna, Reservado 1, Ancho de Mapa de Bits, Altura de Mapa de Bits, Ancho de Ventana de Pantalla, Altura de Ventana de Pantalla, Ancho RGB de Mapa de Color, Capacidad RGB, Capacidad Monocromo, Reservado 2, Capacidad Y Cb Cr, Capacidad Bayer, Reservado 3, Capacidad de Característica de Pantalla, y CRC. Un valor de Tipo de Paquete de 145 identifica un paquete como un Paquete de Capacidad de Pantalla Alterna. El campo ID de cCliente queda reservado para una ID de Cliente para futuro uso y generalmente se configura en cero, por lo regular fijando los bits a un nivel de lógica cero. El campo de Número de Pantalla Alterna 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 típicamente se designa como número 0 y las otras pantallas alternas se identifican con valores únicos de Número de Pantalla Alterna, en donde el valor más grande utilizado es el número total de pantallas alternas menos 1. No se utilizan los valores que son más grandes que el número total de pantallas alternas menos 1. Ejemplo: un teléfono móvil que tiene una pantalla primaria y una pantalla de ID de persona que llama conectada a un cliente de MDDI, tiene una pantalla alterna, de manera que el Número de Pantalla Alterna de la pantalla de ID de persona que llama es cero y el campo de Número de Pantallas Alternas del Paquete de Capacidad del Cliente tiene un valor de 1. El campo Reservado 1 (1 byte) queda reservado para futuro uso. Por lo tanto, todos los bits en este campo actualmente se configuran igual a cero o a un nivel de lógica cero. En una modalidad, un propósito es ocasionar que este campo presente en el paquete y todos los campos de 2 bytes posteriores 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 píxeles. El campo de Altura de Mapa de Bits utiliza 2 bytes que especifican la altura del mapa de bits expresada como un número de píxeles . El campo de Ancho de Ventana de Pantalla utiliza 2 bytes que especifican el ancho de la ventana de pantalla expresado como un número de píxeles. El campo de Altura de Ventana de Pantalla utiliza 2 bytes que especifican la altura de la ventana de pantalla expresada como un número de píxeles. El campo de Ancho RGB de Mapa de Color utiliza 2 bytes que especifican el número de bits de los componentes de color rojo, verde y azul que se pueden desplegar en el modo de pantalla de mapa de color (paleta) . Se puede utilizar un máximo de 8 bits para cada componente de color (rojo, verde y azul) . Incluso cuando se envían 8 bits de cada componente de color en el Paquete de Mapa de Color, solo 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 color (paleta), entonces este valor es cero. La palabra Ancho RGB de mapa de color está compuesta de tres valores sin firmar separados: Los Bits 3 a 0 definen el número máximo de bits de azul en cada píxel, en donde los valores de 0 a 8 se consideran válidos. Los Bits 7 a 4 definen el número máximo de bits de verde en cada píxel, en donde los valores de 0 a 8 se consideran válidos. Los Bits 11 a 8 definen el número máximo de bits de rojo en cada píxel, en donde los valores de 0 a 8 se consideran válidos. Los Bits 14 a 12 se reservan para futuro uso y generalmente se establecen en cero. El Bit 15 se utiliza para indicar la capacidad de un cliente para aceptar los datos de píxel de Mapa de Color en formato empacado o desempacado. Cuando el Bit 15 se establece a un nivel de lógica uno, esto indica que el cliente puede aceptar datos de píxel del Mapa de Color en formato empacado o desempacado. Si el bit 15 se establece a una lógica cero, esto indica que el cliente puede aceptar datos de píxel del Mapa de Color solo en el formato desempacado. El campo de Capacidad RGB utiliza 2 bytes para especificar el número de bits de resolución que se pueden desplegar en el formato RGB. En una modalidad, si el cliente no puede utilizar el formato RGB, entonces este valor se establece igual a cero. La palabra Capacidad RGB está compuesta de tres valores sin firmar separados: los Bits 3 a 0 definen el número máximo de bits de azul (la intensidad de azul) en cada píxel, los Bits 7 a 4 definen el número máximo de bits de verde (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 píxel. Los Bits 14 a 12 se reservan para futuro uso y se establecen en cero. El Bit 15 se utiliza para indicar la capacidad de un cliente para aceptar los datos de píxel RGB en formato empacado o desempacado. Cuando el Bit 15 se establece a un nivel de lógica uno, esto indica que el cliente puede aceptar datos de píxel RGB en formato empacado o desempacado. Si el bit 15 se establece a una lógica cero, esto indica que el cliente puede aceptar datos de píxel RGB solo en el formato desempacado. El campo de Capacidad Monocromo de 1 byte contiene un valor o información para especificar el número de bits de resolución que se pueden desplegar en formato monocromo. Si el cliente no puede utilizar el formato monocromo, entonces este valor se establece igual a cero. Los Bits 6 a 4 se reservan para futuro uso y generalmente se establecen en cero. Los Bits 3 a 0 definen el número máximo de bits de escala de grises que puede existir en cada píxel. Estos cuatro bits hacen posible especificar que cada píxel consta de 1 a 15 bits. Si el valor es cero, entonces el formato monocromo no es soportado por el cliente. El Bit 7, cuando se establece a uno, indica que el cliente puede aceptar datos de píxel monocromo en formato empacado o desempacado. Si el bit 7 se establece en cero, esto indica que el cliente puede aceptar datos de píxel monocromo solo en formato desempacado. El campo Reservado 2 es un campo con un ancho de 1 byte reservado para futuro uso y generalmente tiene todos los bits en este campo establecidos a un nivel de lógica cero. En una modalidad, un propósito de tener este campo presente en el paquete es provocar que todos los campos de 2 bytes posteriores se alineen con una dirección de palabra de 16 bits y hacer que los campos de 4 bytes se alineen con una dirección de palabra de 32 bits. Un campo de Capacidad Y Cb Cr de 2 bytes especifica el número de bits de resolución que se pueden desplegar en el formato Y Cb Cr. Si el cliente no puede utilizar el formato Y Cb Cr, entonces este valor es cero. La palabra Capacidad Y Cb Cr está compuesta por tres valores sin firmar separados: los Bits 3 a 0 definen el número máximo de bits que especifican la muestra Cb, los Bits 7 a 4 definen el número máximo de bits que especifican la muestra Cr, los Bits 11 a 8 definen el número máximo de bits que especifican la muestra Y, y los Bits 14 a 12 se reservan para futuro uso y se establecen en cero. El Bit 15, cuando se establece en uno, indica que el cliente puede aceptar datos de píxel Y Cb Cr en formato empacado o desempacado. Si el bit 15 se establece en cero, esto indica que el cliente puede aceptar datos de píxel Y Cb Cr únicamente en formato desempacado. Un campo de Capacidad Bayer de 2 bytes especifica el número de bits de resolución, grupo de píxeles, y orden de píxeles que se pueden transferir en formato Bayer. Si el cliente no puede utilizar el formato Bayer, entonces este valor se establece en cero. El campo de Capacidad Bayer está compuesto de los siguientes valores: los Bits 3 a 0 definen el número máximo de bits de intensidad que existe en cada píxel, los Bits 5 a 4 definen el patrón de grupo de píxeles que se puede requerir. Los Bits 8 a 6 definen un orden de píxel que es requerido, y los Bits 14 a 9 se reservan para futuro uso y se establecen en cero. El Bit 15, cuando se establece en uno, indica que el cliente puede aceptar datos de píxel Bayer en formato empacado o desempacado. Si el bit 15 se establece en cero, esto indica que el cliente puede aceptar datos de píxel Bayer únicamente en formato desempacado.

El campo Reservado 3, aquí 2 bytes, se reserva para futuro uso. Todos los bits en este campo están, por lo tanto, típicamente configurados en, o iguales a un nivel de lógica cero o un valor 0. En una modalidad, un propósito actual de tener este campo presente en el paquete es hacer que los campos de 2 bytes posteriores se alineen con una dirección de palabra de 16 bits y hacer que los campos de 4 bytes se alineen con una dirección de palabra de 32 bits. El campo de Indicadores de Capacidad de Característica de Pantalla, aquí utilizando 4 bytes, contiene un conjunto de indicadores que indican si las características específicas en la pantalla alterna son soportadas o no. Un bit establecido en uno, indica que se soporta una capacidad particular o previamente establecida, y un bit establecido en cero, indica que la capacidad no es soportada. En una modalidad, el campo de Capacidad de Característica de Pantalla utiliza 4 bytes que contienen un conjunto de indicadores que muestran características específicas en la pantalla alterna que son soportadas. Un bit establecido a un nivel de lógica uno indica que la capacidad es soportada, mientras que un bit establecido a un nivel de lógica cero, indica que la capacidad no es soportada. En una modalidad, el valor para el Bit 0 indica si el Paquete de Transferencia de Bloque de Mapa de Bits (tipo de paquete 71) es soportado o no. El valor para los Bits 1, 2 y 3 indica si el Paquete de Relleno de Área de Mapa de Bits (tipo de paquete 72), el Paquete de Relleno de Patrón de Mapa de Bits (tipo de paquete 73) , o el Paquete de Memoria Intermedia de Cuadro de Lectura (tipo de paquete 74), respectivamente, son soportados o no. El valor para el Bit 4 indica si la pantalla alterna tiene o no la capacidad para hacer un color transparente utilizando el Paquete de Habilitación de Color Transparente. En esta modalidad, el valor de Bit 10 del campo de Capacidad de Característica de Pantalla indica si la pantalla alterna tiene o no la habilidad para soportar el estado de energía de pantalla 01. El estado de energía de pantalla se establece utilizando los bits [3:2] del campo Estado de Energía del Paquete de Estado de Energía de Pantalla antes descrito. El estado de energía de pantalla 01 es un estado en donde la pantalla seleccionada no se ilumina y está consumiendo una cantidad mínima de energía, en caso de hacerlo, y el contenido de la memoria intermedia de cuadro por lo general queda garantizado, o de manera razonable asegurado, para quedar retenido durante este estado. El valor para el Bit 13 del campo de Capacidad de Característica de Pantalla indica si la pantalla alterna tiene o no la habilidad para establecer uno o más parámetros de video soportando los paquetes de Característica VCP: Paquete de Característica VCP de Solicitud, Paquete de Respuesta de Característica VCP, Paquete de Característica VCP Establecida, Paquete de Parámetro Válido de Solicitud, y Paquete de Respuesta de Parámetro Válido. El valor para el Bit 14 indica si la pantalla alterna tiene o no la habilidad para escribir datos de píxel en la memoria intermedia de cuadro de pantalla fuera de línea, lo cual se ilustra en la figura 88A. Si este bit se configura a un nivel de lógica 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 Corriente de Video) se pueden establecer a los valores 01' . El valor para el Bit 15 del campo de Capacidad de Característica de Pantalla indica cuando la pantalla alterna tiene la habilidad para escribir datos de píxel únicamente en la memoria intermedia de cuadro de pantalla que en ese momento se está utilizando para actualizar la imagen de pantalla, lo cual se ilustra en la figura 88B. Si este bit se configura a un nivel de lógica 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 Corriente de Video) se pueden configurar a los valores ?00' . El valor para el Bit 16 indica cuando el cliente tiene la habilidad para escribir datos de píxel desde un solo paquete de Corriente de Video en todas las memorias intermedias de cuadro de pantalla, lo cual se ilustra en la figura 88C. Si este bit se configura igual a un nivel de lógica 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 Corriente de Video) se pueden establecer al valor ?ll' . En una modalidad, el valor para el Bit 21 del campo de Capacidad de Característica de Pantalla indica cuando la pantalla alterna tiene la habilidad para utilizar el campo de Operación de Trama del Paquete de Transferencia de Bloque de Mapa de Bits (tipo de paquete 71) , el Paquete de Relleno de Área de Mapa de Bits (tipo de paquete 72) , y el Paquete de Relleno de Patrón de Mapa de Bits (tipo de paquete 73) , en caso que esos paquetes sean soportados por la pantalla alterna tal como lo especifican los bits 0, 1 y 2 o este campo. En una modalidad, si el bit 21 tiene un nivel o valor de lógica cero, y los paquetes son soportados, entonces la pantalla alterna no tiene la habilidad para utilizar el campo de Operación de Trama y la pantalla alterna típicamente solo tiene la habilidad para copiar o escribir a las ubicaciones de píxel especificadas por estos paquetes. En una modalidad, los Bits 9 a 5, 11, 12, 20 a 17, y 31 a 22 del campo de Capacidad de Característica de Pantalla actualmente se están reservando para futuro uso o designaciones alternas útiles para diseñadores de sistemas, y generalmente se configuran igual a un valor cero o un nivel de lógica cero. El campo CRC de 2 bytes contiene un CRC de 16 bits de todos los bytes en el paquete, incluyendo la Longitud de Paquete. 41. Paquete de acceso de registro El Paquete de Acceso de Registro provee a un huésped o a un cliente un medio, mecanismo, o método para tener acceso a los registros de configuración y estado en el extremo opuesto del enlace MDDI. Los registros tienen la probabilidad de ser únicos para cada controlador de pantalla o dispositivo. Estos registros ya existen en muchas pantallas que requieren el establecimiento de configuraciones, modos de operación, y tener otros parámetros útiles y necesarios. El Paquete de Acceso de Registro permite al huésped o cliente de MDDI tanto escribir en un registro como solicitar la lectura de un registro utilizando el enlace MDDI. Cuando el huésped o cliente solicita leer un registro, el extremo opuesto debería responder enviando los datos de registro en el mismo tipo de paquete, pero también indicando que estos son los datos leídos a partir de un registro particular con el uso de campo de Información de Lectura/Escritura. El Paquete de Acceso de Registro se puede utilizar para leer o escribir múltiples registros especificando un conteo de registro mayor que 1. Un cliente indica una habilidad para soportar el Paquete de Acceso de Registro utilizando el bit 22 del campo de Capacidad de Característica del Cliente del Paquete de Capacidad del Cliente. El cliente utilizará el paquete de encapsulación para enviar el Paquete de Acceso de Registro, presentando así lo que aparece como un paquete dentro de una configuración o estructura de paquete. En la figura 87 se muestra de manera general el formato de una modalidad de un Paquete de Acceso de Registro. Como se aprecia en la figura 87, un Paquete de Acceso de Registro está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de bCliente, Indicadores 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 Paquete de Acceso de Registro. El campo de ID de bCliente se reserva para futuro uso y generalmente se establece en cero por el momento. El campo de Indicadores de Lectura/Escritura de 2 bytes especifica el paquete específico como una escritura, o una lectura, o una respuesta a una lectura, y provee un conteo de los valores de datos.

Los Bits 15 a 14 actúan como Indicadores de Lectura/Escritura. Si los Bits [15:14] son ?00' , entonces este paquete contiene datos que se van a escribir en un registro direccionado por el campo de Dirección de Registro. Los datos que se van a escribir en registros especificados están contenidos en el campo de Lista de Datos de Registro. Si los Bits [15:14] son 10', entonces esto es una solicitud de 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 el paquete contiene datos que fueron solicitados en respuesta a un Paquete de Acceso de Registro que tiene bits 15:14 de los Indicadores de Lectura/Escritura configurados en ?10' . El campo de Dirección de Registro contiene la dirección del registro correspondiente al primer artículo de Lista de Datos de Registro, y el campo de Lista de Datos de Registro contiene datos que se leyeron de la dirección o direcciones. Si los Bits [15:14] son ?01' , esto se considera como una valor inválido, este valor se reserva para futuro uso y no se utiliza en este momento, pero aquellos expertos en la técnica entenderán cómo emplearlo para futuras aplicaciones. Los Bits 13:0 utilizan un entero sin firmar de 14 bits para especificar el número de artículos de Datos de Registro de 32 bits que se van a transferir en la Lista de Datos de Registro. Si los bits 15:14 son iguales a ?00' , entonces los bits 13:0 especifican el número de artículos de datos de registro de 32 bits que están contenidos en el campo de Lista de Datos de Registro que se van a escribir 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 artículos de datos de registro de 32 bits que el dispositivo receptor envía a un dispositivo que está solicitando que los registros sean leídos. El campo de Lista de Datos de Registro en este paquete no contiene artículos de longitud cero. Si los bits 15:14 son iguales a ?ll' , entonces los bits 13:0 especifican el número de artículos de datos de registro de 32 bits que han sido leídos de los registros que están contenidos en el campo de Lista de Datos de Registro. Los Bits 15:14 actualmente no están configurados igual a ?01', lo cual se considera como un valor inválido, y de lo contrario, reservado para futuras designaciones o uso. El campo de Dirección de Registro utiliza 4 bytes para indicar la dirección de registro que se va a escribir o leer. Para registros de dirección cuyo direccionamiento es menor que 32 bits, los bits superiores se configuran en cero. El campo CRC de Parámetro de 2 bytes contiene un CRC de todos los bytes que forman la Longitud de Paquete o la Dirección de Registro. Si este CRC no checa, entonces se desecha todo el paquete. El campo de Lista de Datos de Registro contiene una lista de valores de datos de registro de 4 bytes que van a ser escritos en los registros o valores de cliente que se leyeron de los registros del dispositivo del cliente . El campo CRC de Datos de Registro de 2 bytes contiene un CRC únicamente de la Lista de Datos de Registro. Si este CRC no checa, entonces los Datos de Registro se pueden seguir utilizando, pero se incrementa el conteo de error de CRC.

D. CRC de paquete Los campos de CRC aparecen al final de los paquetes y, en ocasiones, después de algunos parámetros más críticos en paquetes que pueden tener un campo de datos significativamente grande, y por lo tanto, una probabilidad incrementada de errores durante la transferencia. En paquetes que tienen dos campos CRC, el generador CRC, cuando sólo se utiliza uno, es re-iniciado después del primer CRC de manera que los cálculos de CRC que siguen a un campo de datos grande no se ven afectados por los parámetros al comienzo del paquete.

Existe una posibilidad remota de que los paquetes que contienen múltiples errores de bit produzcan un buen CRC. La probabilidad de detectar un CRC bueno en un paquete con errores se aproxima a 7.6xl0~6 en paquetes muy grandes que contienen muchos errores. Por diseño, el enlace MDDI tendrá una velocidad de error de cero o muy baja. El CRC se pretende utilizar para monitorear la salud del enlace, y no para detectar errores en paquetes específicos con el fin de determinar si los paquetes deberían ser retransmitidos. En una modalidad ejemplar, el polinominal utilizado para el cálculo CRC es conocido como el CRC-16 ó X16 + X15 + X2 + XO . En la figura 36 se proporciona una ejecución muestra de un generador y checador CRC 3600 útil para ejecutar la invención. En la figura 36, un registro CRC 3602 es iniciado a un valor de 0x0001 justo antes de transferir el primer bit de un paquete el cual es ingresado en la línea Tx_MDDI_Datos_Antes_CRC, después los bytes del paquete son cambiados al registro iniciando con el LSB primero. Se puede apreciar que los números de bit de registro en esta figura corresponden al orden del polinominal que se está utilizando, y no a las posiciones de bit utilizadas por la MDDI. Resulta más eficiente cambiar el registro CRC en una sola dirección, y esto produce como resultado que el bit 15 CRC aparezca en la posición de bit 0 del campo CRC de MDDI, y el bit 14 de registro CRC en la posición de bit 1 del campo CRC MDDI, y así sucesivamente hasta llegar a la posición de bit 14 de MDDI. Como un ejemplo, si el contenido de paquete para los Paquetes de Solicitud y Estado del Cliente son: 0x000c, 0x0046, 0x000, 0x0400, 0x00, 0x00, 0x0000 (o representados como una secuencia de bytes como: 0x0c, 0x00, 0x46, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00), y se entregan utilizando las entradas de los multiplexores 3604 y 3606, y la compuerta AND 3608, la salida CRC resultante en la línea Tx_MDDI_Datos_Con_CRC es 0xd9aa (o representada como una secuencia como Oxaa, 0xd9) . Cuando el generador y checador CRC 3600 está configurado como un checador CRC, el CRC que es recibido en la línea Rx_MDDI_Datos es ingresado al multiplexor 3604 y la compuerta OR exclusiva (XOR) 3612, y se compara bit por bit con el valor encontrado en el registro CRC utilizando la compuerta ÑOR 3610, la compuerta AND 3608, y la compuerta AND 3614. Si existen cualesquiera errores, tal como emitidos por la compuerta AND 3614, el CRC es incrementado una vez por cada paquete que contiene un error CRC conectando la salida de la compuerta 3614 a la entrada del registro 3602. Se puede apreciar que el circuito ejemplar que se muestra en el diagrama de la figura 36 puede emitir más de una señal de error CRC dentro de una ventana CHECAR_CRC_AHORA determinada (ver figura 37B) . Por lo tanto, el contador de error CRC generalmente solo cuenta el primer caso de error CRC dentro de cada intervalo en donde está activo CHECAR_CRC_AHORA. Si se configura como un generador CRC, el CRC es marcado fuera del registro CRC al momento de coincidir con el final del paquete. La temporización para las señales de entrada y salida, y las señales de habilitación, se ilustra de manera gráfica en las figuras 37A y 37B. La generación de un CRC y transmisión de un paquete de datos se muestran en la figura 37A con el estado (0 ó 1) de las señales Gen_Restablecer, Checar_CRC_Ahora, Generar_CRC_Ahora, y Enviar_MDDI__Datos, junto con las señales Tx_MDDI_Datos_Antes_CRC y Tx_MDDI_Datos_Con_CRC. La recepción de un paquete de datos y la revisión del valor CRC se muestran en la figura 37B, con el estado de las señales Gen_Restablecer, Checar_CRC_Ahora, Generar_CRC_Ahora, y Enviar_MDDI_Datos, junto con las señales Tx_MDDI_Datos y error CRC.

E. Sobrecarga de código de error para CRC de paquete Siempre que solo se están transfiriendo paquetes de datos y CRC entre el huésped y el cliente, no hay códigos de error que se tengan que acomodar. El único error es una pérdida de sincronización. De lo contrario, uno tiene que esperar a que el enlace pida tiempo debido a una falta de una buena trayectoria o conducto de transferencia de datos y después restablecer el enlace y continuar. Infortunadamente, esto conlleva tiempo y de cierta manera resulta ineficiente. Para uso en una modalidad, se ha desarrollado una nueva técnica en donde la porción CRC de paquetes se utiliza para transferir información de código de error. Esto generalmente se muestra en la figura 65. Es decir, uno o más códigos de error son generados por los procesadores o dispositivos que manejan la transferencia de datos lo cual indica errores o defectos predefinidos específicos que podrían ocurrir dentro del procesamiento o enlace de comunicación. Cuando se encuentra un error, el código de error apropiado es generado y transferido utilizando los bits para el CRC de un paquete. Es decir, el valor CRC es sobrecargado, o sobrescrito, con el código de error deseado, lo cual se puede detectar en el extremo receptor a través de un monitor de error o checador que monitorea los valores del campo CRC. Para esos casos en donde el código de error coincide con el valor CRC por algún motivo, el cumplido del error es transferido para evitar confusión. En una modalidad, para proveer un sistema robusto de advertencia y detección de error, el código de error puede ser transferido varias veces, utilizando una serie de paquetes, generalmente todos, los cuales son transferidos o enviados después que se ha detectado el error. Esto ocurre hasta el punto en que la condición que crea el error es eliminada del sistema, en cuyo momento, los bits CRC regulares son transferidos sin sobrecarga por otro valor. Esta técnica de sobrecargar el valor CRC provee una respuesta mucho más rápida a los errores del sistema mientras se utiliza una cantidad mínima de bits o campos extra. Como se muestra en la figura 66, un mecanismo o aparato de sobre-escritura CRC 6600 que se muestra utilizando un detector de error o medio de detecciones 6602, el cual puede formar parte de otra circuitería previamente descrita o conocida, detecta la presencia o existencia de errores dentro del enlace o proceso de comunicación. Un generador o medio de código de error 6604, el cual puede ser formado como parte de otra circuitería o técnicas de uso, tal como cuadros de búsqueda para almacenar mensajes de error preseleccionados, genera uno o más códigos de error para indicar errores o fallos predefinidos específicos que han sido detectados conforme ocurren. Se puede entender fácilmente que los dispositivos 6602 y 6604 se pueden formar como un circuito o dispositivo sencillo, según se desee, o como parte de una secuencia programada de pasos para otros procesadores y elementos conocidos.

Un medio de comparación o comparador de valor CRC 6606 se muestra para ver si el código o códigos de error seleccionados son los mismos que el valor CRC que se está transfiriendo. Si ese es el caso, entonces se utiliza un generador de cumplido de código o medios de generación o dispositivo para proveer el cumplido de los códigos de error para que no sean confundidos como el patrón o valor CRC original y confundir o complicar el esquema de detección. Un selector de código de error o elemento de medio de selección o dispositivo 6610 entonces selecciona el código o valor de error que desea insertar o sobrescribir, o sus cumplidos respectivos, según sea apropiado. Un elemento de sobre-escritura CRC de código de error, o mecanismo de sobre-escritura o medio 6612 es un dispositivo que recibe la corriente de datos, paquetes y los códigos deseados que se van a insertar y sobrescribe los valores CRC correspondientes o apropiados, para transferir los códigos de error deseados a un dispositivo de recepción. Tal como se mencionó, el código de error puede ser transferido varias veces, utilizando una serie de paquetes, de manera que el dispositivo de sobre-escritura 6612 pueda utilizar elementos de almacenamiento de memoria para mantener copias de los códigos durante el procesamiento o recuperar estos códigos a partir de elementos previos u otras ubicaciones de almacenamiento conocidas las cuales se pueden utilizar para almacenar o mantener sus valores según sea necesario o deseable. El procesamiento general del mecanismo de sobre-escritura de la figura 66 se ejecuta como se muestra a detalle en las figuras 67A y 67B. En la figura 67A, un error, uno o más, es detectado en el paso 6702 en los datos o proceso de comunicación y un código de error es seleccionado en el paso 6704 para indicar esta condición. Al mismo tiempo, o en un punto apropiado, el valor CRC que se va a reemplazar es revisado en un paso 6706, y comparado con el código de error deseado en el paso 6708. El resultado de esta comparación, tal como se analizó anteriormente, es una determinación respecto a si el código deseado, u otros valores representativos, serán o no los mismos que el valor CRC presente. Si este es el caso, entonces el procesamiento avanza a un paso 6712 en donde el cumplido, o en algunos casos otro valor representativo, según se desee, es seleccionado como el código a insertar. Una vez que se ha determinado cuáles códigos o valores de error se van a insertar en los pasos 6710 y 6714, ese código apropiado es seleccionado para inserción. Estos pasos se ilustran como separados para propósitos de claridad pero, por lo general, se representan como una sola opción basada en la salida del paso de decisión 6708. Por último, en el paso 6716, los valores apropiados son sobrescritos en la ubicación CRC para transferencia con los paquetes que están siendo el objetivo del proceso. En el lado de recepción de paquetes, como se muestra en la figura 67B, los valores CRC de paquete están siendo monitoreados en un paso 6722. Por lo general, los valores CRC están siendo monitoreados por uno o más procesos dentro del sistema para determinar si ha ocurrido un error en la transferencia de datos y si se debe solicitar o no una retransmisión del paquete o paquetes, o inhibir operaciones adicionales y así sucesivamente, algunos de los cuales se analizaron anteriormente. Como parte de dicho monitoreo, la información también se puede utilizar para comparar valores con códigos de error conocidos o preseleccionados, o valores representativos y para detectar la presencia de errores. Alternativamente, se puede ejecutar un proceso y monitoreo de la detección de error por separado. Si un código parece estar presente, éste es extraído o, de otra forma, observado en el paso 6724 para procesamiento adicional. Se puede tomar una determinación en el paso 6726 respecto a si este es o no el código real o un cumplido, en cuyo caso se utiliza un paso adicional 6728 para trasladar el valor al valor de código deseado. En cualquier caso, el código extraído resultante, cumplido, u otros valores recuperados se utilizan entonces para detectar qué error ha ocurrido para el código transmitido en el paso 6730.

V. Hibernación de enlace El enlace MDDI puede entrar a un estado de hibernación rápidamente y despertar del estado de hibernación rápidamente. Esta capacidad de respuesta permite a un sistema o dispositivo de comunicación forzar al enlace MDDI a un estado de hibernación rápidamente para reducir el consumo de energía, debido a que puede despertar nuevamente para uso de manera muy rápida. En una modalidad, conforme un cliente en modo externo despierta del estado de hibernación por primera vez, éste lo hace a una velocidad de datos y con temporización de impulso estroboscópico que es consistente con una velocidad de 1 Mbps, es decir, el par MDDI_Stb se debería activar a una velocidad de 500 kHz. Una vez que las características del cliente han sido descubiertas por el huésped, o comunicadas al huésped, entonces el huésped puede despertar el enlace, por lo general, a cualquier velocidad de 1 Mbps a la velocidad máxima a la que el cliente puede operar. Los clientes de modo interno pueden despertar a cualquier velocidad a la que tanto el huésped como el cliente pueden operar. Por lo general, esto también aplica a la primera vez que despierta un cliente en modo interno.

En una modalidad, cuando el enlace despierta del estado de hibernación, el huésped y el cliente intercambian una secuencia de impulsos. Estos impulsos se pueden detectar utilizando receptores de línea de baja velocidad que solo consumen una fracción de la corriente ya que los receptores diferenciales requirieron recibir las señales a la máxima velocidad operativa de enlace. Tanto el huésped como el cliente pueden despertar al enlace, de manera que el protocolo de despertar está diseñado para manejar una posible contención que puede ocurrir si el huésped y el cliente intentan despertar al mismo tiempo. Durante el estado de hibernación, los accionadores diferenciales MDDI_Datos y MDDI_Stb son deshabilitados en el estado de alta impedancia y el voltaje diferencial a través de todos los pares diferenciales es cero voltios . Los receptores de línea diferencial utilizados para detectar la secuencia de impulsos durante el despertar de un estado de hibernación tienen una compensación de voltaje intencional. En una modalidad, el umbral entre un nivel de lógica uno y lógica cero en estos receptores es aproximadamente 125 mV. Esto ocasiona que un par diferencial no activado sea visto como un nivel de lógica cero durante la secuencia de despertar del enlace. Para entrar a un Estado de Hibernación, el huésped envía 64 ciclos MDDI Stb después del CRC del Paquete de Apagado 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 retrasos de propagación de inhabilitación de salida) después del CRC. El huésped finaliza el envío de los 64 ciclos MDDI_Stb después del CRC del paquete de Apagado de Enlace, antes que éste inicie la secuencia de despertar. En una modalidad, el despertar iniciado por el huésped es definido como el huésped que tiene que esperar por lo menos 100 nsegundos después que MDDI_DatosO alcanza un nivel válido de lógica uno antes de accionar los impulsos en la MDDI_Stb. En una modalidad, el cliente espera por lo menos 60 ciclos de MDDI_Stb después del CRC del Paquete de Apagado de Enlace antes que éste accione la MDDI_Datos0 a un nivel de lógica uno para intentar despertar al huésped. Para "despertar" de un Estado de Hibernación, se llevan a cabo varios procesos o acciones. Cuando el cliente, aquí una pantalla, necesita datos o comunicación, servicio, proveniente del huésped, éste genera un impulso de solicitud accionando la línea de MDDI_DatosO a un estado de lógica uno durante aproximadamente 70 a 1000 µsegundos, mientras que MDDI_Stb está inactiva y mantiene la MDDI_Datos0 accionada a un nivel de lógica uno durante aproximadamente 70 ciclos de MDDI_Stb (en un rango de 60 a 80) después que la MDDI Stb se activa, aunque se pueden utilizar otros periodos según se desee. El cliente entonces deshabilita el accionador de MDDI_DatosO colocándolo en un estado de alta impedancia. Si MDDI_Stb está activa durante el periodo de hibernación, aunque es poco probable, entonces el cliente solo debería accionar la MDDI_DatosO a un estado de lógica uno durante aproximadamente 70 ciclos de MDDI_Stb (en un rango de 60 a 80) . Esta acción ocasiona que el huésped inicie o reinicie el tráfico de datos en el enlace de avance (208) e interrogue al cliente respecto a su estado. El huésped debe detectar la presencia del impulso de solicitud y comienza la secuencia de inicio que consiste en accionar primero la MDDI_Stb a un nivel de lógica cero y la MDDI_Datos0 a un nivel de lógica alta aproximadamente por lo menos 200 nsegundos. Y después, mientras se activa la MDDI_Stb, continuar con el accionamiento de la MDDI_Datos0 a un nivel de lógica uno durante aproximadamente 150 ciclos de MDDI_Stb (un rango de 140 a 160) y a un nivel de lógica cero durante aproximadamente 50 ciclos de MDDI_Stb. El cliente no debería enviar un impulso de solicitud de servicio si éste detecta MDDI_Datos0 en el estado de lógica uno durante más de 80 ciclos de MDDI_Stb. Cuando el cliente ha detectado MDDI_Datos0 a un nivel de lógica uno durante 60 a 80 ciclos de MDDI_Stb, éste comienza a buscar el intervalo en donde el huésped acciona MDDI_DatosO a un nivel de lógica cero durante 50 ciclos de MDDI_Stb. Después que el huésped acciona MDDI_DatosO a un nivel de lógica cero durante 50 ciclos de MDDI_Stb, entonces el huésped comienza a enviar los paquetes en el enlace. El primer paquete enviado es un Paquete de Encabezado de Sub-Cuadro. El cliente comienza a buscar el Paquete de Encabezado de Sub-Cuadro después que MDDI_DatosO está a un nivel de lógica cero durante 40 ciclos de MDDI_Stb del intervalo de 50 ciclos. La naturaleza de la selección de los tiempos y tolerancias de intervalos de tiempo relacionados con el procesamiento de hibernación y la secuencia de inicio se analizan adicionalmente a continuación. (Ver figuras 68A-C más adelante) . El huésped puede iniciar el despertar habilitando primero MDDI_Stb y simultáneamente accionándola a un nivel de lógica cero. MDDI_Stb no debería ser accionada a un nivel de lógica uno hasta que los impulsos sean emitidos tal como se describe a continuación. Después que MDDI_Stb alcanza un nivel de lógica cero, el huésped habilita MDDI_Datos0 y simultáneamente la acciona a un nivel de lógica uno. MDDI_DatosO no debería ser accionada a un nivel de lógica cero durante el proceso de despertar hasta el intervalo en donde ésta es accionada a un nivel de lógica cero durante un intervalo de 50 impulsos MDDI_Stb tal como se describe a continuación. El huésped debería esperar por lo menos 200 nsegundos después que MDDI_DatosO alcanza un nivel válido de lógica uno antes de accionar los impulsos en MDDI__Stb. Esta relación de temporización ocurre mientras se consideran los retrasos de habilitación de salida en las peores condiciones. Esto sustancialmente garantiza que un cliente tiene suficiente tiempo para habilitar completamente su receptor de MDDI_Stb después de ser despertado por un nivel de lógica uno en MDDI_DatosO que fue accionada por el huésped. En la figura 38 se ilustra un ejemplo de los pasos del procesamiento para un evento típico de solicitud de servicio de cliente 3800 sin contención, en donde los eventos son etiquetados por conveniencia en la 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 Apagado de Enlace al dispositivo del cliente para informarle que el enlace cambiará a un estado de hibernación de baja energía. En un siguiente paso, el huésped entra al estado de hibernación de baja energía deshabilitando el accionador de MDDI_DatosO y estableciendo el accionador de MDDI_Stb a una lógica cero, como se muestra en el punto B. MDDI_DatosO es accionada a un nivel de lógica cero a través de una red de polarización de alta impedancia. Después de transcurrido cierto periodo de tiempo, el cliente envía un impulso de solicitud de servicio al huésped accionando la MDDI_DatosO a un nivel de lógica uno, tal como se aprecia en el punto C. El huésped sigue haciendo válido el nivel de lógica cero utilizando la red de polarización de alta impedancia, pero el accionador en el cliente fuerza la línea a un nivel de lógica uno. Dentro de un periodo de 50 µsegundos, el huésped reconoce el impulso de solicitud de servicio, y hace válido un nivel de lógica uno en MDDI_DatosO habilitando su accionador, tal como se puede apreciar en el punto D. El cliente deja de intentar entonces hacer válido el impulso de solicitud de servicio, y el cliente coloca su accionador en un estado de alta impedancia, tal como se aprecia en el punto E. El huésped acciona la MDDI_DatosO a un nivel de lógica cero durante 50 µsegundos, tal como se muestra en el punto F, y también comienza a generar MDDI_Stb en una forma consistente con el nivel de lógica cero en MDDI_DatosO. El cliente comienza a buscar el Paquete de Encabezado de Sub-Cuadro después que MDDI_DatosO está a un nivel de lógica cero durante 40 ciclos de MDDI_Stb. Después de hacer válida MDDI_DatosO a un nivel de lógica cero y después de accionar la MDDI_Stb durante 50 µsegundos, el huésped comienza a transmitir datos en el enlace de avance enviando un Paquete de Encabezado de Sub-Cuadro, tal como se muestra en el punto G. En la figura 39 se ilustra un ejemplo similar, en donde una solicitud de servicio es hecha válida después que ha comenzado la secuencia de reinicio de enlace, y los eventos son nuevamente etiquetados utilizando las letras A, B, C, D, E, F y G. Esto representa un escenario en el peor de los casos, en donde un impulso o señal de solicitud proveniente del cliente está muy cerca de corromper el Paquete de Encabezado de Sub-Cuadro. El proceso comienza en el punto A cuando el huésped nuevamente envía un Paquete de Apagado de Enlace al dispositivo del cliente para informarle que el enlace cambiará a un estado de hibernación de baja energía. En un siguiente paso, el huésped entra al estado de hibernación de baja energía deshabilitando el accionador de MDDI_Datos0 y estableciendo el accionador de MDDI_Stb a un nivel de lógica cero, tal como se muestra en el punto B. Como antes, MDDI_DatosO es activada a un nivel de lógica cero por medio de 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 accionando la MDDI_DatosO a un nivel de lógica uno durante 150 µsegundos, tal como se aprecia en el punto C. Antes que transcurran 50 µsegundos después que inicia la secuencia de inicio de enlace, la pantalla también hace válida la MDDI_DatosO por un periodo de 70 µsegundos, tal como se aprecia en el punto D. Esto sucede debido a que la pantalla tiene la necesidad de solicitar servicio del huésped y no reconoce que el huésped ya ha comenzado la secuencia de reinicio de enlace. El cliente deja de intentar entonces hacer válido el impulso de solicitud de servicio, y el cliente coloca su accionador en un estado de alta impedancia, tal como se aprecia en el punto E. A continuación, el huésped acciona la MDDI_DatosO a un nivel de lógica uno. El huésped acciona la MDDI_DatosO a un nivel de lógica cero durante 50 µsegundos, tal como se muestra en el punto F, y también comienza a generar la MDDI_Stb en una forma consistente con el nivel de lógica cero en la MDDI_DatosO. Después de hacer válida la MDDI_DatosO a un nivel de lógica cero, y después de accionar la MDDI_Stb durante 50 µsegundos, el huésped comienza a transmitir datos en el enlace de avance mediante el envío de un Paquete de Encabezado de Sub-Cuadro, tal como se muestra en el punto G. A partir del análisis anterior, se puede observar que la solución previa involucraba hacer que el huésped atravesara dos estados como parte de una secuencia de despertar. Para el primer estado, el huésped acciona la señal de MDDI_Datos0 alta por 150 µs, y después acciona la señal de MDDI_Datos0 baja por 50 µs mientras se activa la línea de MDDI_Stb, y después comienza a transmitir paquetes de MDDI. Este proceso funciona bien para avanzar la tecnología de vanguardia en términos de velocidades de datos que se pueden lograr utilizando el aparato y métodos de MDDI. Sin embargo, tal como se mencionó anteriormente, más velocidad en términos de tiempo reducido de respuesta a las condiciones, o la capacidad para seleccionar más rápidamente el siguiente paso o proceso, es la habilidad para simplificar el procesamiento o elementos, algo que siempre se está exigiendo. Los solicitantes han descubierto un nuevo enfoque inventivo para el procesamiento de despertar y temporización en donde el huésped utiliza un ciclo de sincronía basado en la temporización para la activación de señal. En esta configuración, el huésped comienza a activar la MDDI_Stb de 0 a 10 µsegundos, después el huésped acciona la señal MDDI_DatosO alta al inicio de la secuencia de despertar, y no espera hasta que la señal es baja. Durante una secuencia de despertar, el huésped activa la MDDI_Stb como si la señal MDDI_DatosO estuviera siempre a un nivel de lógica cero. Esto remueve de manera efectiva el concepto de tiempo desde el lado del cliente, y el huésped cambia de los periodos previos de 150 µs y 50 µs para los dos primeros estados, a 150 ciclos de sincronía y 50 ciclos de sincronía, para estos periodos. El huésped es ahora responsable de accionar esa línea de datos alta, y dentro de los 10 ciclos de sincronía comenzando a transmitir una señal estroboscópica como si la línea de datos fuera cero. Después que el huésped ha accionado la línea de datos alta para 150 ciclos de sincronía, el huésped acciona la línea de datos baja para 50 ciclos de sincronía mientras continúa transmitiendo la señal estroboscópica. Después que ha completado estos dos procesos, el huésped puede comenzar a transmitir el primer paquete de encabezado de sub-cuadro. En el lado del cliente, la ejecución del cliente ahora puede utilizar la sincronía generada para calcular el número de ciclos de sincronía en que la línea de datos primero está alta, y después baja. El número de ciclos de sincronía que tienen que ocurrir en el estado alto accionado de la línea de datos es 150 y el estado bajo accionado de la línea de datos es 50. Esto significa que para una secuencia de despertar adecuada, el cliente debería poder contar por lo menos 150 ciclos de sincronía continuos de la línea de datos que está alta, seguido por lo menos por 50 ciclos de sincronía continuos de la línea de datos que está baja. Una vez que se cumplen estas dos condiciones, el cliente puede comenzar a buscar la palabra única del primer sub-cuadro. Se utiliza una pausa en este patrón como base para regresar los contadores a un estado inicial en donde el cliente nuevamente busca los primeros 150 ciclos de sincronía continuos de la línea de datos que es alta.

Una ejecución del cliente de la invención para un despertar basado en el huésped a partir de un estado de hibernación es muy similar al caso de arranque inicial, excepto que la velocidad de sincronía no es forzada a comenzar en 1 Mbps, tal como se analizó anteriormente. Más bien, la velocidad de sincronía se puede establecer para reanudarse a cualquier velocidad previa a la que estuviera activa cuando el enlace de comunicación entró al estado de hibernación. Si el huésped comienza la transmisión de una señal estroboscópica tal como se analizó anteriormente, el cliente debería tener la capacidad para contar una vez más por lo menos 150 ciclos de sincronía continuos de la línea de datos que es alta, seguido por lo menos por 50 ciclos de sincronía continuos de la línea de datos que es baja. Una vez que se han cumplido estas dos condiciones, el cliente puede comenzar la búsqueda de la palabra única. Una ejecución de cliente de la invención para un despertar basado en el cliente a partir de un estado de hibernación es similar al despertar basado en el huésped excepto que éste comienza cuando el cliente acciona la línea de datos. El cliente puede accionar, de manera asincrona, la línea de datos sin una sincronía para despertar el dispositivo huésped. Una vez que el huésped reconoce que la línea de datos está siendo accionada alta por el cliente, éste puede comenzar su secuencia de despertar. El cliente puede contar el número de ciclos de sincronía generados por el huésped al inicio o durante su proceso de despertar. Una vez que el cliente cuenta 70 ciclos de sincronía continuos de los datos en alto, éste puede detener el accionamiento de la línea de datos alto. En este punto, el huésped ya debería estar accionando la línea de datos alta también. El cliente puede entonces contar otros 80 ciclos de sincronía continuos de la línea de datos que es alta para alcanzar los 150 ciclos de sincronía de la línea de datos que es alta, y puede entonces buscar 50 ciclos de sincronía de la línea de datos que es baja. Una vez que se cumplen estas tres condiciones, el cliente puede comenzar a buscar la palabra única. Una ventaja de esta nueva ejecución de proceso de despertar es que ésta elimina la necesidad de un dispositivo de medición de tiempo. Si éste es un circuito de descarga de capacitor u oscilador, u otro de esos dispositivos, el cliente ya no necesita esos dispositivos externos para determinar las condiciones de arranque. Esto ahorra dinero y área de circuito cuando se ejecutan controladores, contadores, y así sucesivamente en un tablero del dispositivo del cliente. Aunque esto puede no ser tan ventajoso para el cliente, para el huésped esta técnica debería también simplificar de manera potencial al huésped en términos de Lógica de Densidad Muy Alta (VHDL) que se utiliza para circuitería de núcleo. El consumo de energía por utilizar las líneas estroboscópicas y de datos como la notificación de despertar y la fuente de medición, también será más bajo debido a que no se necesitará circuitería externa para que los elementos de núcleo estén esperando un despertar basado en el huésped. El número de ciclos o periodos de sincronía utilizados es ejemplar y se pueden emplear otros periodos tal como resultará aparente para aquellos expertos en la técnica. Una ventaja de esta nueva ejecución de proceso de despertar es que ésta elimina la necesidad de un dispositivo de medición de tiempo. Si éste es un circuito de descarga de capacitor u oscilador, u otro de esos dispositivos, el cliente ya no necesita esos dispositivos externos para determinar las condiciones de arranque. Esto ahorra dinero y área de circuito cuando se ejecutan controladores, contadores, y así sucesivamente en un tablero del dispositivo del cliente. Aunque esto puede no ser tan ventajoso para el cliente, para el huésped esta técnica debería también simplificar de manera potencial al huésped en términos de VHDL que se utiliza para circuitería de núcleo. El consumo de energía por utilizar las líneas estroboscópicas y de datos como la notificación de despertar y la fuente de medición, también será más bajo debido a que no se necesitará circuitería externa para que los elementos de núcleo estén esperando un despertar basado en el huésped. Para aclarar e ilustrar la operación de esta nueva técnica, la temporización de MDDI_DatosO, MDDI_Stb, y varias operaciones relacionadas con los ciclos de sincronía se muestran en las figuras 68A, 68B y 68C. En la figura 68A se ilustra un ejemplo de los pasos de procesamiento para un Despertar Iniciado por el Huésped típico sin contención, en donde los eventos se vuelven a etiquetar por conveniencia en la ilustración que utiliza 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 Apagado de Enlace al dispositivo del cliente para informarle que el enlace cambiará a un estado de hibernación de baja energía. En un siguiente paso, punto B, el huésped activa MDDI_Stb aproximadamente por 64 ciclos (o según se requiera para el diseño del sistema) para permitir que el procesamiento, por parte del cliente, sea completado antes de detener la MDDI_Stb, lo cual detiene la sincronía recuperada en el dispositivo del cliente. El huésped inicialmente también establece la MDDI_DatosO a un nivel de lógica cero y después deshabilita la salida de MDDI_DatosO en el rango de 16 a 48 ciclos (por lo general, incluyendo retrasos de propagación de inhabilitación de salida) después del CRC. Puede ser deseable colocar receptores de alta velocidad para MDDI_DatosO y MDDI_Stb en el cliente en un estado de baja energía, cierto tiempo después de los 48 ciclos posteriores al 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 cualquier momento después del borde elevado del 48avo ciclo de MDDI_Stb después del CRC del Paquete de Apagado de Enlace. Se recomienda que el cliente coloque sus receptores de alta velocidad para MDDI_DatosO y MDDI_Stb en hibernación antes del borde elevado del 64avo ciclo de MDDI_Stb después del CRC del Paquete de Apagado de Enlace. El huésped entra a un estado de hibernación de baja energía en el punto o paso C, deshabilitando los accionadores de MDDI_DatosO y MDDI_Stb y colocando un controlador de huésped en un estado de hibernación de baja energía. El accionador de MDDI_Stb también se puede establecer a un nivel de lógica cero (utilizando red de polarización de alta impedancia) o para seguir activo durante la hibernación, según se desee. El cliente también está en un estado de hibernación de bajo nivel de energía. Después de cierto periodo de tiempo, el huésped comienza la secuencia de reinicio de enlace en el punto D, habilitando la salida del accionador de MDDI_DatosO y MDDI_Stb. El huésped acciona MDDI_DatosO a un nivel de lógica uno y MDDI_Stb a un nivel de lógica cero durante todo el tiempo que le tome a los accionadores habilitar completamente sus salidas respectivas. Por lo regular, el huésped espera alrededor de 200 nanosegundos, después que estas salidas alcanzan niveles de lógica deseados antes de accionar impulsos en MDDI_Stb. Esto otorga tiempo al cliente para que se prepare para la recepción. Con los accionadores del huésped habilitados y MDDI_DatosO accionado a un nivel de lógica uno, el huésped comienza a activar MDDI_Stb por una duración de 150 ciclos de MDDI_Stb, tal como se puede apreciar en el punto E. El huésped acciona MDDI_DatosO a un nivel de lógica cero durante 50 ciclos, como se muestra en el punto F, y el cliente comienza a buscar el Paquete de Encabezado de Sub-Cuadro después que MDDI_Datos0 está a un nivel de lógica cero durante 40 ciclos de MDDI_Stb. El huésped comienza a transmitir datos en el enlace de avance enviando un Paquete de Encabezado de Sub-Cuadro, como se muestra en el punto G. En la figura 68B se muestra un ejemplo de los pasos de procesamiento para un Despertar Iniciado por el Cliente típico sin contención, en donde los eventos son nuevamente etiquetados por conveniencia en ilustración utilizando las letras A, B, C, D, E, F, G, H e I. Tal como se mencionó anteriormente, el proceso comienza en el punto A cuando el huésped envía un Paquete de Apagado de Enlace para informar al cliente que el enlace cambiará al estado de baja energía. En el punto B, el huésped activa MDDI_Stb aproximadamente por 64 ciclos (o según se desee para el diseño del sistema) para permitir que el procesamiento por parte del cliente sea completado antes de detener la MDDI_Stb, lo cual detiene la sincronía recuperada en el dispositivo del cliente. El huésped inicialmente también establece MDDI_DatosO a un nivel de lógica cero y después deshabilita la salida de MDDI_DatosO en el rango de 16 a 48 ciclos (por lo general incluyendo retrasos de propagación de inhabilitación de salida) después del CRC. Puede ser deseable colocar receptores de alta velocidad para MDDI_DatosO y MDDI_Stb en el cliente en un estado de baja energía cierto tiempo después de los 48 ciclos, posterior al CRC y antes de la siguiente etapa (C) . El huésped entra al estado de hibernación de baja energía en el punto o paso C, deshabilitando los accionadores de MDDI_DatosO y MDDI_Stb y colocando un controlador de huésped en un estado de hibernación de baja energía. El accionador de MDDI_Stb también se puede establecer a un nivel de lógica cero (utilizando una red de polarización de alta impedancia) o puede seguir activo durante el estado de hibernación, según se desee. El cliente también está en un estado de hibernación de bajo nivel de energía.

Después de cierto periodo de tiempo, el cliente comienza la secuencia de reinicio de enlace en el punto D habilitando el receptor de MDDI_Stb, y también habilitando una compensación en el receptor de MDDI_Stb para garantizar que el estado de la versión recibida de MDDI_Stb es un nivel de lógica cero en el cliente antes que el huésped habilite su accionador de MDDI_Stb. Puede ser deseable que el cliente habilite la compensación ligeramente por delante de la habilitación del receptor para asegurar la recepción de una señal diferencial válida e inhibir señales erróneas, según se desee. El Cliente habilita el accionador de MDDI_DatosO mientras acciona la línea de MDDI_DatosO a un nivel de lógica uno. Se permite que MDDI_DatosO y MDDI_Stb sean habilitadas simultáneamente si el tiempo para habilitar la compensación y para habilitar el receptor diferencial estándar de MDDI_Stb es menor que 200 nsegundos. Dentro de un periodo de aproximadamente 1 msegundo, 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 del accionador de MDDI_DatosO y MDDI_Stb. El huésped acciona MDDI_DatosO a un nivel de lógica uno y MDDI_Stb a un nivel de lógica cero durante todo el tiempo que lleve a los accionadores habilitar sus salidas respectivas. El huésped típicamente espera alrededor de 200 nanosegundos después que estas salidas alcanzan niveles de lógica deseados antes de accionar los impulsos en MDDI_Stb. Esto da tiempo al cliente para que se prepare para la recepción. Con los accionadores de huésped habilitados y MDDI_DatosO accionado a un nivel de lógica uno, el huésped comienza a emitir impulsos en MDDI_Stb por una duración de 150 ciclos de MDDI_Stb, tal como se aprecia en el punto F. Cuando el cliente reconoce el primer impulso en MDDI_Stb, éste deshabilita la compensación en su receptor de MDDI_Stb. El cliente acciona MDDI_DatosO a un nivel de lógica uno durante 70 ciclos de MDDI_Stb, y deshabilita su accionador de MDDI_DatosO en el punto G. El huésped acciona MDDI_Datos0 a un nivel de lógica uno por una duración de 80 impulsos MDDI_Stb adicionales, y en el punto H acciona MDDI_Datos0 a un nivel de lógica cero. Tal como se aprecia en los puntos G y H, el huésped acciona MDDI_Datos0 a un nivel de lógica cero durante 50 ciclos, y el cliente comienza a buscar el Paquete de Encabezado de Sub-Cuadro después que MDDI_Datos0 está a un nivel de lógica cero durante 40 ciclos de MDDI_Stb. Después de accionar MDDI_Stb por una duración de 50 ciclos, el huésped comienza a transmitir datos en el enlace de avance enviando un Paquete de Encabezado de Sub-Cuadro, tal como se muestra en el punto I. En la figura 68C se ilustra un ejemplo de los pasos de procesamiento para un Despertar iniciado por el Huésped típico con contención del cliente, es decir, el cliente también desea despertar el enlace. Los eventos se etiquetan nuevamente por conveniencia en la ilustración utilizando las letras A, B, C, D, E, F, G, H e I. Tal como se mencionó anteriormente, el proceso comienza en el punto A cuando el huésped envía un Paquete de Apagado de Enlace para informar al cliente que el enlace cambiará al estado de baja energía, avanza al paso B en donde MDDI_Stb es activado durante aproximadamente 64 ciclos (o según se desee para el diseño del sistema) para permitir que se complete el procesamiento por parte del cliente, y después al punto C, en donde el huésped entra al estado de hibernación de baja energía, deshabilitando los accionadores de MDDI_Datos0 y MDDI_Stb y colocando un controlador de huésped en un estado de hibernación de baja energía. Después de transcurrido cierto periodo de tiempo, el huésped comienza la secuencia de reinicio de enlace en el punto D, habilitando la salida del accionador de MDDI_DatosO y MDDI_Stb, y comienza a activar MDDI_Stb por una duración de 150 ciclos de MDDI_Stb, tal como se puede apreciar en el punto E. Hasta a 70 ciclos de MDDI Stb después del punto E, aquí el punto F, el cliente no ha reconocido todavía que el huésped está accionando MDDI_DatosO a un nivel de lógica uno, de manera que el cliente también acciona MDDI_DatosO a un nivel de lógica uno. Esto ocurre aquí debido a que el cliente tiene un deseo de solicitar servicio pero no reconoce que el huésped con el que está tratando de comunicarse ya ha comenzado la secuencia de reinicio de enlace. En el punto G, el cliente deja de accionar MDDI_DatosO, y coloca su accionador en un estado de alta impedancia deshabilitando su salida. El huésped acciona MDDI_DatosO a un nivel de lógica uno durante 80 ciclos adicionales. El huésped acciona MDDI_Datos0 a un nivel de lógica cero durante 50 ciclos, como se muestra en el punto H, y el cliente comienza a buscar el Paquete de Encabezado de Sub-Cuadro después que MDDI_DatosO está a un nivel de lógica cero durante 40 ciclos de MDDI_Stb. El huésped comienza a transmitir datos en el enlace de avance enviando un Paquete de Encabezado de Sub-Cuadro, como se muestra en el punto I.

VI. Especificaciones eléctricas de interfaz En las modalidades ejemplares, Datos en un formato Sin Retorno a Cero (NRZ) se codifican utilizando una señal de datos-estroboscópica o formato de DATOS-STB, el cual permite que información de sincronía sea incorporada en las señales estroboscópicas y de datos. La sincronía se puede recuperar sin circuitería de bucle de bloqueo de fase compleja. Los datos son portados en un enlace diferencial bidireccional, generalmente ejecutado utilizando un cable de conexión, aunque se pueden utilizar otros conductores, cables impresos, o elementos de transferencia, tal como se mencionó anteriormente. La señal Estroboscópica (STB) es portada en un enlace unidireccional el cual es accionado únicamente por el huésped. La señal estroboscópica activa el valor (0 ó 1) siempre que existe un estado consecutivo, 0 ó 1, que permanece igual en la línea o señal de Datos. Un ejemplo de la forma en que se puede transmitir una secuencia de datos, tal como los bits "1110001011" utilizando codificación DATOS-STB se muestra en forma gráfica en la figura 40. En la figura 40, una señal de DATOS 4002 se muestra en la línea superior de un diagrama de temporización de señal y una señal STB 4004 se muestra en una segunda línea, cada tiempo alineado según resulte apropiado (punto de inicio común) . Conforme transcurre el tiempo, cuando está ocurriendo un cambio de estado en la línea de DATOS 4002 (señal), entonces la línea STB 4004 (señal) mantiene un estado previo, por lo tanto, el primer estado l' de la señal de DATOS se correlaciona con el primer estado ?0' para la señal STB, su valor de inicio. Sin embargo, si o cuando el estado, nivel de la señal de DATOS no cambia, entonces la señal STB se activa en el estado opuesto o l' en el ejemplo presente, como en el caso de la figura 40 en donde los DATOS están proveyendo otro valor X' . Es decir, existe una y solo una transición por ciclo de bits entre DATOS y STB. Por lo tanto, la señal STB cambia nuevamente, esta vez a 0' conforme la señal de DATOS permanece en l' y mantiene este nivel o valor conforme la señal de DATOS cambia el nivel a ?0' . Cuando la señal de DATOS permanece en X' , la señal STB se activa al estado opuesto o X' en el presente ejemplo, y así sucesivamente, conforme la señal de DATOS cambia o mantiene los niveles o valores. Al recibir estas señales, se ejecuta una operación OR exclusiva (XOR) en las señales de DATOS y STB para producir una señal de sincronía 4006, la cual se muestra en la parte inferior del diagrama de temporización para comparación relativa con las señales de datos y estroboscópicas deseadas. En la figura 41 se muestra un ejemplo de circuitería útil para generar las salidas o señales de DATOS y STB a partir de los datos de entrada en el huésped, y después recuperar o recapturar los datos a partir de las señales de DATOS y STB en el cliente. En la figura 41, se utiliza una porción de transmisión 4100 para generar y transmitir las señales de DATOS y STB originales en una trayectoria de señal intermedia 4102, mientras que una porción receptora 4120 se utiliza para recibir las señales y recuperar los datos. Como se muestra en la figura 41, para transferir datos desde el huésped a un cliente, la señal de DATOS es ingresada a dos elementos de circuito de basculador tipo D 4104 y 4106 junto con una señal de sincronía para disparar los circuitos. Las dos salidas de circuito de basculador (Q) se dividen entonces en un par diferencial de señales MDDI_DatosO+, MDDI_DatosO-, y MDDI_Stb+, MDDI_Stb-, respectivamente, utilizando dos accionadores de línea diferencial 4108 y 4110 (modo de voltaje) . Una compuerta de tres entradas ÑOR exclusiva (XNOR) , circuito o elemento lógico 4112 está conectado para recibir los DATOS y salidas de a bos basculadores, y genera una salida que provee la entrada de datos para el segundo basculador, el cual, a su vez, genera 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 basculador que genera la señal Estroboscópica. En la porción receptora 4120 de la figura 41, las señales MDDI_DatosO+, MDDI_DatosO-, y MDDI_Stb+, MDDI_Stb-son recibidas por cada uno de los dos receptores de línea diferencial 4122 y 4124, los cuales generan salidas sencillas a partir de las señales diferenciales. Las salidas de los amplificadores se ingresan entonces en cada una de las entradas de una compuerta XOR de dos entradas, circuito o elemento lógico 4126 lo cual produce la señal de sincronía. La señal de sincronía se utiliza para disparar cada uno de los dos circuitos de basculador tipo D 4128 y 4130, los cuales reciben una versión retrasada de la señal de DATOS, a través del elemento de retraso 4132, uno de los cuales (4128) genera valores 0' de datos y el otro (4130) valores X' de datos. La sincronía también tiene una salida independiente de la lógica XOR. Debido a que la información de sincronía se distribuye entre las líneas de DATOS y STB, ninguna señal cambia entre estados más rápido que la mitad de la velocidad de sincronía. Debido a que la sincronía se reproduce utilizando procesamiento OR exclusivo de las señales de DATOS y STB, el sistema tolera, de manera efectiva, dos veces la cantidad de sesgo entre los datos de entrada y sincronía en comparación con la situación en la que una señal de sincronía es enviada directamente en una línea de datos dedicada sencilla. Los pares de señales MDDI_Datos, MDDI_Stb+, y MDDI_Stb- se operan en un modo diferencial para elevar al máximo la inmunidad contra los efectos negativos del ruido. Cada par diferencial termina en paralelo con la impedancia característica del cable o conductor que se está utilizando para transferir señales. Generalmente, todas las terminaciones paralelas residen en el dispositivo del cliente. Este es casi el receptor diferencial para tráfico de avance (datos enviados desde el huésped al cliente) , pero está en el extremo de accionamiento del cable u otros conductores o elementos de transferencia para el tráfico inverso (datos enviados desde el cliente al huésped) . Para tráfico inverso, la señal es accionada por el cliente, reflejada por el receptor de alta impedancia en el huésped, finaliza en el cliente. Como se describió en otro apartado, los datos inversos o datos en el enlace inverso se pueden transferir o enviar a velocidades de datos mayores que el recíproco del retraso de viaje redondo en el cable. Los conductores o señales MDDI_Stb+ y MDDI_Stb- únicamente son accionados por el huésped. En la figura 42 se muestra una configuración ejemplar de elementos útiles para lograr que los accionadores, receptores y terminaciones transfieran señales como .parte de la MDDI inventiva. Esta interfaz ejemplar utiliza detección de bajo voltaje, aquí 200 mV, con variaciones de potencia de menos de 1 voltio y drenaje de baja energía. El accionador de cada par de señales tiene una salida de corriente diferencial. Mientras se reciben paquetes MDDI, los pares MDDI_Datos y MDDI_Stb utilizan un receptor diferencial convencional con un umbral de voltaje diferencial de cero voltios. En el estado de hibernación, las salidas del accionador son deshabilitadas y las resistencias de terminación paralela extraen el voltaje diferencial en cada par de señales a cero voltios. Durante la hibernación, un receptor especial en el par de MDDI_DatosO tiene un umbral de voltaje diferencial de entrada de compensación de 125 mV positivo, lo cual ocasiona que el receptor de la línea de hibernación interprete el par de señales no accionadas como un nivel de lógica cero. El voltaje diferencial de un par diferencial queda definido como la diferencia del voltaje en la señal positiva (+) menos el voltaje en la señal negativa (-) . Los nombres de las señales de par diferencial finalizan con "+" ó "-", lo cual indica la señal positiva o negativa del par, respectivamente. La corriente de salida del accionador de un par diferencial queda definida como la corriente que fluye fuera de la salida positiva (+) . La corriente que pasa a través de la salida negativa (-) de un accionador diferencial siempre es igual en magnitud pero opuesta en dirección en comparación con la corriente que pasa a través de la salida positiva (+) del mismo accionador diferencial. Algunas veces el huésped o cliente accionan simultáneamente el par diferencial a un nivel de lógica uno o un nivel de lógica cero para garantizar un nivel de lógica válido en el par cuando cambia la dirección del flujo de datos (de huésped-a-cliente o cliente-a-huésped) . El rango de voltaje de salida y las especificaciones de salida se siguen cumpliendo con salidas accionadas simultáneamente activadas al mismo nivel de lógica. En algunos sistemas, puede ser necesario accionar una pequeña corriente en el par diferencial terminado para crear un pequeño voltaje de compensación en ciertos momentos durante la hibernación y cuando el enlace está despertando del estado de hibernación. En esas situaciones, los circuitos de polarización de corriente de compensación habilitados accionan los niveles de corriente denominados como: diodo ESD interno-íEsn-y-Rx y entrada de receptor diferencial con IESD-Y-RX < 1 µA típicamente; salida de accionador diferencial-ITx-Hi-z en el estado de alta impedancia, con ITx_ HÍ-Z < 1 µA típicamente; e íESD-extemo ~ la fuga a través de los diodos de protección ESD externos, con íEso-externo < 3 µA típicamente. En la figura 47 se ilustra cada una de estas corrientes de fuga. Los circuitos para levantar y bajar deben lograr el voltaje diferencial mínimo bajo las condiciones de fuga en la peor circunstancia descrita anteriormente, cuando todo ocurre simultáneamente. La fuga total es < 4 µA para modo interno sin diodos de protección ESD externa y < 10 µA para modo externo con protección ESD externa. Los parámetros y características eléctricas de los accionadores de línea diferencial y los receptores de línea se describen para una modalidad ejemplar en los cuadros IXa-IXd. Funcionalmente, el accionador transfiere el nivel lógico en la entrada directamente a una salida positiva, y el inverso de la entrada a una salida negativa. El retraso de la entrada a salidas se compara bien con la línea diferencial que es accionada de manera diferencial. En la mayoría de las ejecuciones, la oscilación de voltaje en las salidas es menor que la oscilación en la entrada para reducir al mínimo el consumo de energía y las emisiones electromagnéticas. En una modalidad, existe una oscilación de voltaje mínima de alrededor de 0.5V. Sin embargo, se pueden utilizar otros valores, tal como lo podrán apreciar aquellos expertos en la técnica, y los inventores contemplan un valor más pequeño en algunas modalidades, dependiendo de las restricciones del diseño. Los receptores de línea diferencial tienen la misma característica que el comparador de voltaje de alta velocidad. En la figura 41, la entrada sin la burbuja es la entrada positiva y la entrada con la burbuja es la entrada negativa. La salida es una lógica uno si: (Ventradat)- (Ventrada-) es mayor que cero. Otra forma de describir esto es un amplificador diferencial con ganancia muy grande (virtualmente infinita) con la salida sujeta a los niveles de voltaje de lógica 0 y 1. El sesgo de retraso entre diferentes pares se debería reducir al mínimo para operar el sistema de transmisión diferencial a la velocidad potencial más elevada. CUADRO IXa Especificaciones eléctricas del transmisor huésped 100 nsegundos, el que sea más pequeño.

CUADRO IXb Es ecificaciones eléctricas del transmisor del cliente Nota 1 : El tiempo máximo de subida y bajada es 30% del intervalo para transmitir un bit en un par diferencial o 100 nsegundos, el que sea más pequeño.

CUADRO IXc Especificaciones eléctricas del receptor de cliente CUADRO IXd Especificaciones eléctricas del receptor de huésped En la figura 42, un controlador de huésped 4202 y un controlador de pantalla o cliente 4204 se muestran transfiriendo paquetes en el enlace de comunicación 4206. El controlador de huésped emplea una serie de tres accionadores 4210, 4212, y 4214 para recibir las señales de DATOS y STB de huésped que se van a transferir, así como para recibir las señales de Datos del cliente que se van a transferir, mientras que el cliente emplea los tres accionadores 4230, 4232, y 4234. El accionador responsable del paso de los DATOS del huésped (4212) emplea una entrada de señal habilitada para permitir la activación del enlace de comunicación generalmente solo cuando se desea la transferencia desde el huésped al cliente. Debido a que la señal STB se forma como parte de la transferencia de datos, no se emplea una señal de habilitación adicional para ese accionador (4212) . Las entradas de cada uno de los receptores de DATOS y STB del cliente (4132, 4230) tienen impedancias de terminación o resistencias 4218 y 4220, respectivamente distribuidas entre las mismas. El accionador 4234 en el controlador del cliente se utiliza para preparar las señales de datos que están siendo transferidas desde el cliente al huésped, en donde el accionador 4214 en el lado de entrada, procesa los datos. Los receptores especiales (accionadores) 4216 y 4236 están acoplados o conectados a las líneas de DATOS, y generan o utilizan la compensación de voltaje de 125 mV previamente analizada, como parte del control de hibernación que se analiza en otro apartado. Las compensaciones ocasionan que los receptores de la línea de hibernación interpreten los pares de señales no accionados como un nivel de lógica cero.

Los accionadores e impedancias anteriores se pueden formar como componentes discretos o como parte de un módulo de circuito, o un Circuito Integrado de Aplicación Específica (ASIC) el cual actúa como una solución de codificador o decodificador más efectiva en cuanto a costo. Fácilmente se puede apreciar que la potencia es transferida al dispositivo del cliente, o pantalla, desde el dispositivo del huésped utilizando las señales etiquetadas como HÜESPED_Pwr y HUESPED_Gnd en un par de conductores. La porción de HÜESPED_Gnd de la señal actúa como la referencia base y la trayectoria de retorno de suministro de energía o señal para el dispositivo del cliente. La señal HUESPED_Pwr actúa como el suministro de energía del dispositivo del cliente el cual es accionado por el dispositivo de huésped. En una configuración ejemplar, para aplicaciones de baja energía, el dispositivo del cliente se deja aproximar hasta 500 mA. La señal HUESPED_P r puede ser provista desde fuentes de energía portátiles, tal como, pero no limitado a, una batería tipo litio-iones o paquete de batería que reside en el dispositivo del huésped, y puede oscilar de 3.2 a 4.3 voltios con respecto a HUÉSPED Gnd.

VII. Características de temporización A. Perspectiva general Los pasos y niveles de señal empleados para entrar a un estado de hibernación (no se solicita, desea o requiere servicio) y para asegurar el servicio a un cliente desde el huésped, ya sea mediante iniciación del huésped o cliente, se ilustran en las figuras 43A, 43B y 43C, respectivamente. En las figuras 43A, 43B y 43C, la primera parte de las señales que se ilustran, muestra un Paquete de Apagado de Enlace que se está transfiriendo desde el huésped, y la línea de datos es entonces accionada a un estado de lógica cero utilizando el circuito de polarización de alta impedancia. Ningún dato está siendo transmitido por el cliente, o huésped, el cual tiene su accionador deshabilitado. Una serie de impulsos estroboscópicos para la línea de señal MDDI_Stb se pueden apreciar en la parte inferior, debido a que MDDI_Stb está activa durante el Paquete de Apagado de Enlace. Una vez que finaliza este paquete, el nivel de lógica cambia a cero conforme el huésped acciona el circuito de polarización y la lógica a cero. Esto representa la terminación de la última transferencia de señal o servicio desde el huésped, y podría haber ocurrido en cualquier momento en el pasado, y se incluye para mostrar el cese de servicio previo, y el estado de las señales antes del comienzo del servicio. Si se desea, dicha señal puede ser enviada solo para restablecer el enlace de comunicación al estado adecuado sin una comunicación previa "conocida" emprendida por este dispositivo de huésped. Como se muestra en la figura 43A, y se analiza para el Paquete de Apagado de Enlace anterior, en el estado de hibernación de baja energía, el accionador MDDI_DatosO es deshabilitado en un estado de alta impedancia comenzando después del 16avo a 48avo ciclos o impulsos de MDDI_Stb después del último bit del campo Todos Ceros en el Paquete de Apagado de Enlace. Para los enlaces Tipo 2, Tipo 3 o Tipo 4, las señales de MDDI_Datosl a MDDI_DatosPwr7 también están colocadas en un estado de alta impedancia al mismo tiempo que el accionador de MDDI_DatosO es deshabilitado. Tal como se describió en la definición del campo Todos Ceros, MDDI_Stb se activa por 64 ciclos (o según se desee para el diseño del sistema) siguiendo al MSB del campo CRC del Paquete de Apagado de Enlace para permitir que el procesamiento por parte del cliente se complete y facilitar 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 que se envía el campo Todos Ceros, los accionadores de MDDI_Stb y MDDI_DatosO en el huésped son deshabilitados, y el huésped entra al estado de hibernación de baja energía. Después de cierto periodo de tiempo, el huésped comienza la secuencia de reinicio de enlace, tal como se muestra en las figuras 43b y 43c, habilitando las líneas de MDDI_DatosO y MDDI_Stb o salidas de accionador, y comienza a activar MDDI_Stb como parte de una solicitud de despertar iniciada por un huésped o un cliente. Como se muestra en la figura 43B, después de transcurrido cierto tiempo con la salida de señal de los accionadores para MDDI_DatosO y MDDI_Stb deshabilitada, un huésped inicia el servicio o despertar del estado de hibernación habilitando su accionador de MDDI_Stb durante un periodo de tiempo designado tstb-dagta-habiiitar durante el cual la línea es accionada a un nivel de lógica cero, hasta que queda completamente habilitada y después habilitando su accionador MDDI_DatosO. El huésped mantiene MDDI_Stb al nivel de lógica cero después que MDDI_DatosO alcanza un nivel alto o un nivel de lógica uno, lo cual ocurre en un periodo de tiempo designado tciiente-inicio• Al final del periodo tciiente-inicio el huésped entonces activa la señal o línea de MDDI_Stb. El huésped acciona la línea de MDDI_DatosO alta, un nivel de lógica uno, mientras que el cliente no acciona MDDI_DatosO, durante un periodo designado treiniCio-a?to/ y después acciona la línea de MDDI_DatosO baja, o a un nivel de lógica cero, durante un periodo designado treiniCi0-bjo- Después de esto, el primer tráfico de avance comienza con un Paquete de Encabezado de Sub-Cuadro, y después se transfieren los paquetes de tráfico de avance. La señal MDDI_Stb está activa durante el periodo treinicxo-bajo y el Paquete de Encabezado de Sub-Cuadro posterior. Como se muestra en la figura 43C, después de transcurrido cierto tiempo con la salida de señal desde los accionadores para MDDI_DatosO y MDDI_Stb deshabilitada, un cliente inicia una solicitud de servicio o despertar del estado de hibernación habilitando una compensación en el receptor de MDDI_Stb o señal de salida durante un periodo de tiempo designado tstb~dagta-habiiitarf como se analizó anteriormente, antes que el huésped habilite su accionador de MDDI_Stb. El cliente entonces habilita su accionador de MDDI_DatosO durante un periodo de tiempo designado thUésped-detectarf durante el cual, la línea es accionada a un nivel de lógica cero, antes que el huésped comience la activación de MDDIJStb. Transcurre o se pudiera necesitar una cierta cantidad de tiempo antes que el huésped detecte la solicitud durante thuésped-detectar/• después de lo cual el huésped responde manteniendo MDDI_Stb a un nivel de lógica cero durante un periodo designado tstb-inicio antes que el huésped comience a activar MDDI_Stb con una secuencia de inicio de enlace accionando la MDDI_DatosO a un nivel alto o de lógica uno durante el periodo de tEeiniCi0-aito- Cuando el cliente reconoce el primer impulso en MDDI_Stb, éste deshabilita la compensación en su receptor de MDDI_Stb. El cliente continúa accionando MDDI_DatosO a un nivel de lógica uno o un periodo designado tciiente-detectar hasta que éste detecta al huésped que está accionando la línea. En este punto, el cliente deja de hacer válida la solicitud, y deshabilita su accionador de MDDI_DatosO de manera que la salida del cliente pasa a un nivel de lógica cero una vez más, y el huésped está accionando MDDI_DatosO. Como se mencionó anteriormente, el huésped continúa accionando MDDI_DatosO a un nivel de lógica uno durante el periodo de treinicio-aito i Y después acciona la línea de MDDI_DatosO baja durante el periodo de trßinicio-bajo después de lo cual el primer tráfico de avance comienza con un Paquete de Encabezado de Sub-Cuadro. La señal de MDDI_Stb está activa durante el periodo de treinicio-bajo y el Paquete de Encabezado de Sub-Cuadro posterior. El cuadro X muestra tiempos representativos o periodos de procesamiento durante la longitud de los diversos periodos anteriormente analizados, y la relación con velocidades de datos mínimas y máximas ejemplares, en donde: 1 u en donde Enlace Datos Velocidad Enlace _ Datos _ Velocidad s la velocidad de bits de un par de datos sencillos. CUADRO X Aquellos expertos en la técnica fácilmente entenderán que las funciones de los elementos individuales que se ilustran en las figuras 41 y 42, son muy conocidas, y la función de los elementos en la figura 42 se confirma a través del diagrama de temporización en las figuras 43a, 43b y 43c. Detalles respecto a las terminaciones en serie y las resistencias de hibernación que se muestran en la figura 42 se omitieron en la figura 41 debido a que esa información es innecesaria para una descripción de cómo realizar codificación de Datos-Estroboscópicos y recuperar la sincronía de ésta.

B. Enlace de avance de temporización de datos estroboscópicos Las características de conmutación para la transferencia de datos en el enlace de avance desde la salida del accionador de huésped se muestran en el cuadro XI-1. El cuadro XI presenta una forma tabular de los tiempos mínimos y máximos deseados contra los tiempos típicos para que ocurran algunas transiciones de señal. Por ejemplo, la longitud típica de tiempo para que ocurra una transición desde el inicio hasta el final de un valor de datos (salida de un 0' ó l' ) , una transición de DatosO a DatosO, calificada ttdd- (huésped-salida) , es ttbit mientras que el tiempo mínimo es aproximadamente ttbit-0.5 nsegundos, y el tiempo máximo es alrededor de ttbit+0.5 nsegundos. La separación relativa entre transiciones en los DatosO, otras líneas 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, Datos 0 a No DatosO, No Datos 0 a No DatosO, No DatosO a Estroboscópica, y Estroboscópica a No DatosO, las cuales se denominan COmo ttds- (huésped-salida) i tss- (huésped-salida) r ttsd- (huésped-salida) r ttdxx- (huésped-salida) r ttdxdx- (huésped-salida) r t d s- (huésped-salida) r Y ttsdx- (huésped-salida) i respectivamente .

CUADRO XI-1 Los requerimientos de temporización MDDI típicos para la entrada del receptor del cliente para las mismas señales que transfieren datos en el enlace de avance se muestran en el cuadro XI-2. Debido a que se analizan las mismas señales pero en tiempo retrasado, no se necesita una nueva figura para ilustrar las características de la señal o el significado de las etiquetas respectivas, tal como lo podrán entender aquellos expertos en la técnica.

CUADRO XI-2 Las figuras 45 y 46 ilustran la presencia de un retraso en respuesta que puede ocurrir cuando el huésped deshabilita o habilita el accionador del huésped, respectivamente. En el caso de un huésped que reenvía 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 accionador de línea después que los paquetes deseados son reenviados, tal como los paquetes CRC de Parámetro, Alineación Estroboscópica, y Todos Cero que se ilustran en la figura 45 como transferidos. Sin embargo, como se muestra en la figura 45, el estado de la línea no necesariamente cambia de ?0' a un valor superior deseado instantáneamente, aunque esto se puede lograr potencialmente con cierto control o elementos de circuito presentes, pero toma un periodo de tiempo calificado como el periodo de Retraso de Inhabilitación del Accionador de huésped para responder. Aunque esto podría ocurrir virtualmente casi en forma instantánea, de manera que este periodo de tiempo tenga una longitud de 0 nanosegundos (nseg.), éste se podría extender de manera más fácil en un periodo de tiempo más prolongado en donde 10 nanosegundos son una longitud de periodo máxima deseada, lo cual ocurre durante los periodos de paquete de Tiempo de Guardia 1 o Giro 1. Observando en la figura 46, se puede apreciar el cambio de nivel de señal experimentado cuando el Accionador del huésped es habilitado para transferir un paquete tal como un 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 Guarida 2 o Giro 2, el accionador del huésped es habilitado y comienza a accionar un nivel, aquí ?0X cuyo valor se aproxima o logra en un periodo de tiempo calificado como el periodo de Retraso de Habilitación del Accionador de Huésped, lo cual ocurre durante el periodo de Re-habilitación del Accionador, antes que se envíe el primer paquete. Un proceso similar ocurre para los accionadores y transferencias de señal para el dispositivo del cliente, aquí una pantalla. Los lineamientos generales para la longitud de estos periodos, y sus relaciones respectivas se muestran en XII, a continuación.

CUADRO XII C. Tiempos de habilitación e inhabilitación de salida de huésped y cliente Las características de conmutación y las relaciones de temporización relativas para el tiempo de habilitación e inhabilitación de salida del Huésped y Cliente u operaciones relacionadas con la estructura y periodo del Paquete de Encapsulación de Enlace Inverso, se muestran en la figura 48. Las funciones u operaciones de salida del accionador se etiquetan como: thUésped-habiiitar para el tiempo de habilitación de salida de Huésped, thUéSped-inhaiiitar para el tiempo de inhabilitación de salida de Huésped, tciiente-habiiitar para el tiempo de habilitación de salida de Cliente, y tciiente-inhabiiitar para el tiempo de inhabilitación de salida de Cliente. Los tiempos típicos para algunas transiciones de señal se analizan a continuación. El periodo mínimo para estas operaciones sería de cero nanosegundos, con valores máximos o típicos determinados a partir del diseño del sistema que emplee la interfaz, posiblemente en el orden de 8 nanosegundos, o más . Los lineamientos generales para la longitud de estos periodos, (tiempos de habilitación/inhabilitación de huésped y cliente) y sus respectivas relaciones se muestran en XIII, a continuación.

CUADRO XIII VIII. Ejecución del control de enlace (Operación de Controlador de Enlace) A. Procesador de paquete de máquina de estado Los paquetes que se transfieren en un enlace de MDDI son despachados de manera muy rápida, típicamente a una velocidad en el orden de 300 Mbps o más, tal como 400 Mbps, aunque ciertamente se pueden permitir velocidades inferiores, según se desee. Este tipo de enlace o velocidad de enlace de transferencia es demasiado grande para microprocesadores de propósito general actualmente disponibles de manera comercial (económicos) o similares para ejercer control. Por lo tanto, una ejecución práctica para lograr este tipo de transferencia de señal es utilizar una máquina de estado programable para analizar sintácticamente la corriente del paquete de entrada a fin de producir paquetes que son transferidos o redirigidos al sub-sistema audiovisual apropiado para el cual están destinados. Dichos dispositivos son muy conocidos y utilizan circuitos generalmente dedicados a un número limitado de operaciones, funciones, o estados para lograr una operación de velocidad alta o velocidad muy alta deseada. Los controladores de propósito general, procesadores o elementos de procesamiento se pueden utilizar para actuar de manera más apropiada o manipular cierta información tal como paquetes de control o estado, los cuales tienen demandas de velocidad inferior. Cuando esos paquetes (control, estado u otros paquetes previamente definidos) son recibidos, la máquina de estado debería pasarlos a través de una memoria intermedia de datos o elemento de procesamiento similar al procesador de propósito general de manera que se pueda actuar sobre los paquetes para proveer un resultado (efecto) deseado mientras los paquetes de audio y visuales son transferidos a su destino apropiado para acción. Si futuros microprocesadores u otros controladores de propósito general, procesadores, o elementos de procesamiento son fabricados para lograr capacidades de procesamiento de velocidad de datos superior, entonces la máquina de estado o estados, que se analiza a continuación, también se debería ejecutar utilizando control de software de dichos dispositivos, típicamente como programas almacenados en un elemento o medio de almacenamiento . La función del procesador de propósito general se puede evidenciar en algunas modalidades sacando ventaja de la potencia de procesamiento, o ciclos en exceso disponibles para microprocesadores (CPU) en aplicaciones de computadora, o controladores, procesadores, procesadores de señal digital (DSP) , circuitos especializados, o ASIC encontrados en dispositivos inalámbricos, en forma muy parecida en la que algunos módems o procesadores de gráficos utilizan la potencia de procesamiento del CPU encontrada en computadoras para realizar algunas funciones y reducir la complejidad y costos del hardware. Sin embargo, la repartición o uso de este ciclo podría impactar de manera negativa la velocidad de procesamiento, temporización u operación global de esos elementos, de manera que en muchas aplicaciones se prefieren circuitos o elementos dedicados para este procesamiento general. Para poder ver datos de imagen en una pantalla (micro-pantalla) , o para recibir de manera confiable todos los paquetes enviados por el dispositivo huésped, el procesamiento de la señal del cliente es sincronizado con la temporización del canal de enlace de avance. Es decir, las señales que llegan al cliente y a los circuitos del cliente tienen que estar sustancialmente sincronizadas en tiempo para que ocurra un procesamiento de señal adecuado. En la figura 49 se ilustra un diagrama de alto nivel de estados logrados por la señal para una modalidad. En la figura 49, los "estados" de sincronización de enlace de avance posibles para una máquina de estado 4900 se muestran como clasificados en un ESTADO DE CUADROS ASINCRONOS 4909, dos ESTADOS DE SINCRONÍA DE ADQUISICIÓN 4902 y 4906, y tres ESTADOS EN-SINCRONÍA 4908, 4910 y 4912. Tal como se muestra en el paso o estado de inicio 4902, la pantalla o cliente, tal como un dispositivo de presentación, inicia un estado "no sincrónico" previamente seleccionado, y busca una palabra única en el primer paquete de encabezado de sub-cuadro que es detectado. Se apreciará que este estado no sincrónico representa la configuración de comunicación mínima o configuración de "repliegue" en donde se selecciona una interfaz Tipo 1. Cuando se encuentra la palabra única durante la búsqueda, el cliente guarda el campo de longitud de sub-cuadro. No existe revisión alguna de los bits CRC para procesamiento en este primer cuadro, o hasta que se obtiene la sincronización. Si esta longitud de sub-cuadro es cero, entonces el procesamiento del estado sincrónico procede, por consiguiente, a un estado 4904 etiquetado aquí como el estado de "cuadros asincronos", el cual indica que la sincronización todavía no se ha logrado. Este paso en el procesamiento es etiquetado como un paso que ha encontrado la cond 3 o condición 3, en la figura 49. De otro modo, si la longitud de cuadro es mayor que cero, entonces el procesamiento del estado sincrónico procede a un estado 4906 en donde el estado de interfaz se establece como "encontró un cuadro sincrónico". Este paso en el procesamiento está etiquetado como un paso que ha encontrado la cond 5, o condición 5, en la figura 49. Además, si la máquina de estado observa un paquete de encabezado de cuadro y buena determinación CRC para una longitud de cuadro mayor que cero, el procesamiento avanza al estado "encontró un cuadro sincrónico". Este paso está etiquetado como un paso que cumple con la cond 6, o condición 6, en la figura 49. En cada situación en la que el sistema está en un estado que no sea "no sincrónico", si se detecta un paquete con un buen resultado CRC, entonces el estado de interfaz es modificado al estado "en sincronía" 4908. Este paso en el procesamiento está etiquetado como un paso que ha encontrado la cond 1, o condición 1, en la figura 49. Por otra parte, si el CRC en cualquier paquete no es correcto, entonces el procesamiento de estado sincrónico avanza o regresa al estado de interfaz 4902 de estado "CUADRO NO SINCRÓNICO". Esta porción del procesamiento está etiquetada como que ha encontrado la cond 2, o condición 2, en el diagrama de estado de la figura 49.

B. Tiempo de adquisición para sincronización La interfaz se puede configurar para permitir un cierto número de "errores de sincronización" antes de decidir que la sincronización está perdida y volver al estado "CUADRO NO SINCRÓNICO". En la figura 49, una vez que la máquina de estado ha alcanzado el "ESTADO EN SINCRONÍA" y no se encontraron errores, continuamente está encontrando un resultado de condición 1, y permanece en el estado "EN SINCRONÍA" . Sin embargo, una vez que se detecta un resultado de cond 2, el procesamiento cambia el estado a un estado "un-error-sincrónico" 4910. En este punto, si el procesamiento produce como resultado la detección de otro resultado de cond 1, entonces la máquina de estado regresa al estado "en sincronía", de lo contrario, encuentra otro resultado de condición 2, y se mueve a un estado "DOS-ERRORES-SINCRONICOS" 4912. Una vez más, si ocurre una cond 1, el procesamiento regresa la máquina de estado al estado "EN SINCRONÍA". De lo contrario, se encuentra otra cond 2 y la máquina de estado regresa al estado "no sincrónico".

También se puede entender que si la interfaz encuentra un "paquete de apagado de enlace", entonces esto ocasionará que el enlace finalice las transferencias de datos y regrese al estado de "cuadro-no-sincrónico" ya que no hay algo con lo cual sincronizarse, lo cual se denomina como que cumple con la cond 4, o condición 4, en el diagrama de estado de la figura 49. Se entiende que es posible que haya una "falsa copia" de repetición de la palabra única, lo cual puede aparecer en algún lugar fijo dentro del sub-cuadro. En esa situación, es muy poco probable que la máquina de estado se sincronice con el sub-cuadro debido a que el CRC, en el Paquete de Encabezado de Sub-Cuadro, también debe ser válido cuando es procesado con el fin de que el procesamiento de MDDI avance al estado "EN SINCRONÍA". La longitud de sub-cuadro en el Paquete de Encabezado de Sub-Cuadro se puede establecer en cero para indicar que el huésped transmitirá únicamente un sub-cuadro antes que se apague el enlace, y la MDDI es colocada o configurada en un estado de hibernación inactivo. En este caso, el cliente debe recibir inmediatamente paquetes en el enlace de avance después de detectar el Paquete de Encabezado de Sub-Cuadro debido a que solo un sub-cuadro es enviado antes que el enlace cambie al estado inactivo. En operaciones normales o típicas, la' longitud del sub-cuadro es no cero y el cliente solo procesa paquetes de enlace de avance mientras la interfaz está en esos estados colectivamente mostrados como estados "EN SINCRONÍA" en la figura 49. Un dispositivo de cliente de modo externo se puede fijar al huésped mientras el huésped está transmitiendo una secuencia de datos de enlace de avance. En esta situación, el cliente se debe sincronizar con el huésped. El tiempo requerido para que un cliente se sincronice con la señal de enlace de avance es variable dependiendo del tamaño de sub-cuadro y la velocidad de datos del enlace de 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 de avance es mayor cuando el tamaño del sub-cuadro es más grande. Al mismo tiempo, la habilidad para recuperarse de una falsa detección es más baja, y el tiempo que toma esto es más prolongado, cuando la velocidad de datos del enlace de avance es más lenta. Para una o más modalidades, se recomienda o entiende que un huésped de MDDI debería realizar algunos pasos adicionales para asegurar que el enlace inverso de MDDI sea estable antes que éste detenga la transmisión del enlace de avance para que pase a un modo de baja energía o que apague 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 toda la transmisión de datos inversos recibidos posteriormente desde el cliente falle aún cuando el enlace de avance parezca estar bien. Esto podría suceder si el huésped trata de enviar un Paquete de Medición de Retraso de Viaje Redondo cuando el cliente no está en sincronía con el enlace de avance, o debido a un cambio de temperatura de ambiente extremo que ocasione un cambio grande correspondiente en el retraso de propagación de los accionadores diferenciales y receptores, lo cual afecta el retraso de viaje redondo. Una falla de contacto intermitente del cable o conector también podría ocasionar que el cliente pierda temporalmente la sincronización y después vuelva a obtener la sincronización, durante ese tiempo, éste puede no recibir un Paquete de Medición de Retraso de Viaje Redondo. Los paquetes de enlace inverso posteriores no podrían ser decodificados de manera adecuada por el huésped. Otro tipo de problema que puede ocurrir es que, si el cliente pierde sincronización temporalmente y el huésped envía un Paquete de Apagado de Enlace antes que el cliente pueda volver a obtener sincronización, el huésped estará en hibernación mientras el cliente no pueda entrar al estado de hibernación debido a que no recibió el Paquete de Apagado de Enlace y no tiene una sincronía debido a que el enlace está en hibernación. Una técnica o modalidad útil para superar estos problemas es que el huésped se asegure que el cliente está en sincronización con el enlace de avance antes de poner al enlace en estado de hibernación. Si el huésped de MDDI no puede hacer esto o no tiene la oportunidad, tal como en el caso donde pierde potencia o el enlace se interrumpe o falla abruptamente debido a un cable, conductor o separación de conector, interrupción o desconexión que ocurre durante la operación, entonces el huésped primero debería tratar de asegurarse que el cliente esté en sincronización antes de comenzar el proceso de medición de retraso de viaje redondo o antes de enviar un paquete de Encapsulación de Enlace Inverso. Un huésped puede observar el campo de Conteo de Error de CRC en un paquete de Solicitud y Estado del Cliente enviado por el cliente para determinar la integridad del enlace de avance. Este paquete es solicitado por el huésped al cliente. Sin embargo, en el caso de una falla de enlace mayor o interrupción, esta solicitud con mayor probabilidad pasará sin recibir respuesta debido a que un cliente no podrá decodificar de manera adecuada el paquete, o incluso recibirlo totalmente. La solicitud del Conteo de Error de CRC utilizando el paquete de Solicitud y Estado del Cliente enviado en un Paquete de Encapsulación de Enlace Inverso actúa como un primer chequeo de integridad, una clase de primera línea de defensa. Además, un huésped puede enviar un Paquete de Medición de Retraso de Viaje Redondo para confirmar la suposición afirmativa o negativa respecto a si el cliente que ha perdido sincronización es válido 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 está fuera de sincronización y puede entonces comenzar el proceso de ponerlo nuevamente en sincronización. El Huésped debería monitorear continuamente el Conteo de Error de CRC en el cliente enviando periódicamente Paquetes de Encapsulación de Enlace Inverso al cliente, en donde el bit 1 del campo de Indicadores de Enlace Inverso se configura en 1 para solicitar que el cliente regrese un Paquete de Estado y Solicitud del Cliente al huésped. Una vez que el huésped concluye que el cliente tiene más que sincronización perdida con el enlace de avance, éste espera hasta el siguiente encabezado de subcuadro antes de intentar enviar cualesquiera paquetes que no sean paquetes de relleno. Esto se hace para dar al cliente suficiente tiempo para detectar o buscar una palabra única contenida en el paquete de encabezado de subcuadro. Después de esto, el huésped puede asumir que el cliente se habría restablecido así mismo debido a que no habría encontrado la palabra única en la ubicación correcta. En este punto, el huésped puede seguir el paquete de encabezado de sub-cuadro con un Paquete de Medición de Retraso de Viaje Redondo. Si el cliente sigue sin responder 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 aquella en donde el cliente envía 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 no se recibe esta secuencia, entonces fallarán los intentos por recibir datos inversos en un Paquete de Encapsulación de Enlace Inverso. La falla continua de esta naturaleza puede indicar otro error de sistema el cual tendrá que ser corregido de alguna otra forma, 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 sigue observando datos corrompidos o ninguna respuesta en los Paquetes de Encapsulación de Enlace Inverso, éste debería confirmar que el muestreo de datos inversos sea correcto mediante el reenvío de un Paquete de Medición de Retraso de Viaje Redondo. Si esto no tiene éxito después de un número de intentos, se recomienda, para una modalidad, que el huésped reduzca la velocidad de datos inversos aumentando el valor divisor de velocidad inversa. El huésped debería ejecutar los pasos de Detección de Falla de Enlace y, posiblemente, de Resincronización de Enlace, anteriormente descritos, antes de colocar el enlace de MDDI en el estado de hibernación. Esto generalmente asegurará que el Paquete de Medición de Retraso de Viaje Redondo ejecutado sea exitoso cuando se reinicie el enlace más adelante. Si el huésped no tiene motivo para tener sospechas de una falla de enlace, y el cliente está reportando una respuesta correcta para un Paquete de Encapsulación de Enlace Inverso y cero errores de CRC de enlace de avance, un huésped puede asumir que todo está operando o funcionando de manera acorde o apropiada (ninguna falla de enlace, por ejemplo) y procede con el proceso de hibernación/apagado. Otra forma en la que un huésped puede probar la sincronización es que el huésped envíe el Paquete de Medición de Retraso de Viaje Redondo y confirme la respuesta apropiada por parte del cliente. Si la respuesta apropiada es recibida por el huésped, éste puede asumir, de manera razonable, que el cliente está interpretando exitosamente los paquetes de enlace de avance.

C. Inicialización Tal como se mencionó anteriormente, al momento del "arranque", el huésped configura el enlace de avance para operar a, o por debajo de una velocidad de datos mínima requerida o deseada de 1 Mbps, y configura la longitud de sub-cuadro y la velocidad de cuadro de medios de manera apropiada para una aplicación determinada. Es decir, tanto el enlace de avance como el enlace inverso comienzan a operar utilizando la interfaz Tipo 1. Estos parámetros por lo general solo se utilizarán temporalmente mientras el huésped determina la capacidad o configuración deseada para la pantalla del cliente (u otro tipo de dispositivo del cliente) . El huésped envía o transfiere un Paquete de Encabezado de Sub-Cuadro en el enlace de avance seguido por un Paquete de Encapsulación de Enlace Inverso el cual tiene el bit ''O' de los Indicadores de Solicitud configurado a un valor de uno (1) , para solicitar que la pantalla o cliente respondan con un Paquete de Capacidad del Cliente. Una vez que la pantalla adquiere sincronización en (o con) el enlace de avance, ésta envía un Paquete de Capacidad del Cliente y un Paquete de Solicitud y Estado del Cliente en el enlace o canal inverso. El huésped examina el contenido del Paquete de Capacidad del Cliente para determinar cómo reconfigurar el enlace para un nivel de rendimiento óptimo o deseado. El huésped examina los campos de Versión de Protocolo y Versión de Protocolo Mínimo para confirmar que el huésped y el cliente utilizan versiones del protocolo que sean compatibles entre sí. Las versiones de protocolo por lo general permanecen como los primeros dos parámetros . del Paquete de Capacidad del Cliente de manera que la compatibilidad se puede determinar incluso cuando otros elementos del protocolo pudieran no ser compatibles o completamente entendidos como compatibles. En modo interno, el huésped puede conocer los parámetros del cliente por anticipado sin tener que recibir un Paquete de Capacidad del Cliente. El enlace puede comenzar a cualquier velocidad de datos a la que el huésped y el cliente pueden operar. En muchas modalidades, un diseñador de sistema con mayor probabilidad elegirá iniciar el enlace a la velocidad de datos máxima posible para apresurar la transferencia de datos; sin embargo, esto no se requiere y puede no utilizarse en muchas situaciones. Para operación en modo interno, la frecuencia de los impulsos estroboscópicos utilizados durante el reinicio del enlace a partir de la secuencia de hibernación, por lo general será consistente con esta velocidad deseada.

D. Procesamiento de CRC Para todos los tipos de paquete, la máquina de estado del procesador de paquetes asegura que el checador de CRC esté controlado de manera apropiada o adecuada. También incrementa un contador de error de CRC cuando una comparación de CRC produce como resultado la detección de uno o más errores, y restablece el contador de CRC al inicio de cada sub-cuadro que se esté procesando.

E. Pérdida alternativa de chequeo de sincronización Aunque la serie anterior de pasos o estados funcionan para producir velocidades de datos superiores o velocidad de rendimiento superior, los solicitantes han descubierto que una disposició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, se puede emplear de manera efectiva para lograr un rendimiento o velocidades de datos superiores. La nueva modalidad inventiva tiene la misma estructura básica, pero con las condiciones para cambiar estados modificados. Adicionalmente, se ejecuta un nuevo contador para ayudar en los chequeos de sincronización de sub-cuadro. 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 estado.

Solo las porciones "ESTADOS DE SINCRONÍA DE ADQUISICIÓN" y "ESTADOS EN-SINCRONÍA" se muestran para claridad. Además, debido a que los estados resultantes son sustancialmente los mismos, como es la máquina de estado misma, éstos utilizan la misma numeración. Sin embargo, las condiciones para cambiar estados (y la operación de la máquina de estado) varían de cierta forma, de manera que todos son numerados, para claridad, entre las dos figuras (1, 2, 3, 4, 5, y 6 contra 61, 62, 63, 64, y 65), como algo conveniente para identificar diferencias. Debido a que el estado de CUADRO ASINCRONO no se considera en este análisis, un estado (4904) y condición (6) ya no se utilizan en la figura. En la figura 63, el sistema o cliente (para despliegue o presentación) inicia con la máquina de estado 5000 en el estado "no sincrónico" previamente seleccionado 4902, como en la figura 49. El cambio del primer estado para estados cambiantes de la condición no sincrónica 4902 se ubica en la condición 64 la cual es el descubrimiento del patrón sincrónico. Asumiendo que el CRC del encabezado de sub-cuadro también pasa este paquete (cumple la condición 61), el estado de la máquina de estado del procesador de paquetes se puede cambiar al estado en-sincronía 4908. Un error de sincronía, condición 62, ocasionará que la máquina de estado cambie al estado 4910, y una segunda ocurrencia al estado 4912. Sin embargo, se ha descubierto que cualquier falla del CRC de un paquete de MDDI ocasionará que la máquina de estado se mueva fuera del estado en-sincronía 4908, al estado de error sincrónico uno 4910. Otra falla del CRC de cualquier paquete MDDI ocasionará un movimiento al estado de error sincrónico dos 4912. Un paquete decodificado con un valor de CRC correcto ocasionará que la máquina de estado regrese al estado en-sincronía 4908. Lo que se ha cambiado es utilizar el valor CRC o determinación para 'cada' paquete. Es decir, hacer que la máquina de estado observe el valor de CRC para que cada paquete determine una pérdida de sincronización en lugar de solo observar paquetes de encabezado de sub-cuadro. En esta configuración o proceso, una pérdida de sincronización no se determina utilizando la palabra única y solo valores de CRC de encabezado de sub-cuadro. Esta nueva ejecución de interfaz permite al enlace de MDDI reconocer fallas de sincronización de manera mucho más rápida, y por lo tanto, recuperarse de las mismas en forma más rápida también. Para hacer que este sistema sea más robusto, el cliente también debería agregar o utilizar un contador de sub-cuadro. El cliente entonces verifica la presencia de la palabra única al momento 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ápido que si tuviera que esperar que varios tiempos o periodos de paquete (aquí tres) fueran mayores que una longitud de sub-cuadro. Si la prueba de la palabra única indica que no está presente, en otras palabras que la temporización es incorrecta, entonces el cliente puede declarar inmediatamente una pérdida de enlace de sincronización y moverse al estado no sincrónico. El proceso de verificación de la presencia de la palabra única adecuada agrega una condición 65 (cond 65) a la máquina de estado que indica que la palabra única es incorrecta. Si se espera recibir un paquete de sub-cuadro en el cliente y no coincide, el cliente inmediatamente puede pasar al estado no sincrónico 4902, ahorrando tiempo adicional en espera de múltiples errores de sincronización (condición 62) normalmente encontrados cuando se pasa por los estados 4910 y 4912. Este cambio utiliza un contador o función de conteo adicional en el núcleo del cliente para contar la longitud del sub-cuadro. En una modalidad, se utiliza una función de conteo descendente y la transferencia de cualquier paquete que en ese momento se estaba procesando es interrumpida para revisar la palabra única de sub-cuadro si el contador ha vencido. Alternativamente, el contador puede hacer un conteo ascendente, en donde el conteo se compara con un valor deseado particular o máximo deseado, en cuyo punto se revisa el paquete actual. Este proceso protege al cliente contra la decodificación de paquetes que son recibidos incorrectamente en el cliente con longitudes de paquete extraordinariamente grandes. Si el contador de longitud de sub-cuadro necesitara interrumpir algún otro paquete que se estuviera decodificando, se puede determinar una pérdida de sincronización debido a que ningún paquete debería cruzar un límite de sub-cuadro.

IX. Procesamiento de paquetes Para cada tipo de paquete, analizado anteriormente, que recibe la máquina de estado, éste conlleva un paso de procesamiento particular o serie de pasos para ejecutar la operación de la interfaz. Los paquetes de enlace de avance generalmente son procesados de acuerdo con el procesamiento ejemplar que se lista en el cuadro XIV a continuación.

CUADRO XIV X. Reducción de la velocidad de datos del enlace inverso Los inventores han observado que algunos parámetros utilizados para el controlador de enlace de huésped se pueden ajustar o configurar en una cierta forma para lograr una velocidad de datos de enlace inverso (escala) más optimizada o máxima, 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ñal MDDI_Stb se activa para crear una sincronía de datos periódica a la mitad de la velocidad de los datos de enlace de avance. Esto ocurre debido a que el controlador de enlace de huésped genera la señal MDDI_Stb que corresponde a la señal MDDI_DatosO como si estuviera enviando todos ceros. La señal MDDI_Stb es transferida desde el huésped a un cliente en donde es utilizada para generar una señal de sincronía para transferir datos de enlace inverso desde el cliente, en donde dichos datos inversos son enviados de regreso al huésped. Una ilustración de cantidades típicas de retraso encontrado para la transferencia de señal y el procesamiento en las trayectorias de 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 muestra cerca de las porciones de procesamiento para las etapas de generación de Stb+/-, transferencia por cable-a-cliente, receptor de cliente, generación de sincronía, sincronía de señal, generación de Datos0+/-, transferencia por cable-a-huésped, y receptor de huésped, respectivamente. Dependiendo de la velocidad de los datos del enlace de avance y de los retrasos de procesamiento de señal encontrados, se puede requerir más tiempo que un ciclo en la señal MDDI_Stb para este efecto de "viaje redondo" o para que se complete este conjunto de eventos, lo cual resulta en el consumo de cantidades indeseables de tiempo o ciclos. Para sortear este problema, el Divisor de Velocidad Inversa hace posible que un tiempo de un bit en el enlace inverso abarque múltiples ciclos de la señal MDDI_Stb. Esto significa que la velocidad de datos del enlace inverso es menor que la velocidad de enlace de avance. Se debería apreciar que la longitud real de los retrasos de señal a través de la interfaz puede diferir dependiendo de cada sistema de huésped-cliente específico o hardware que se esté utilizando. Aunque no se requiere, cada sistema generalmente puede estar hecho para que funcione mejor utilizando el Paquete de Medición de Retraso de Viaje Redondo para medir el retraso real en un sistema de manera que el Divisor de Velocidad Inversa se pueda fijar a un valor óptimo. El huésped puede soportar ya sea un muestreo de datos básico, el cual es más simple pero opera a una velocidad más lenta o muestreo de datos avanzado, el cual es más complejo pero soporta velocidades de datos inversas superiores. La capacidad del cliente para soportar ambos métodos se considera la misma. ün retraso de viaje redondo es medido cuando el huésped envía un Paquete de Medición de Retraso de Viaje Redondo al cliente. El cliente responde a este paquete enviando una secuencia de unos de regreso al huésped dentro de, o durante, una ventana de medición previamente seleccionada en ese paquete denominado el campo de Periodo de Medición. La temporización detallada de esta medición se describió previamente. El retraso de viaje redondo se utiliza para determinar la velocidad a la que los datos de enlace inverso se pueden muestrear de manera segura. La medición de retraso de viaje redondo consta de determinar, detectar o contar el número de intervalos de sincronía de datos de enlace de avance que ocurren entre el inicio del campo de Periodo de Medición y el comienzo del periodo de tiempo cuando la secuencia de respuesta Oxff, Oxff, 0x00 es recibida de regreso en el huésped desde el cliente. Se puede apreciar que es posible que la respuesta del cliente pudiera ser recibida una fracción pequeña de un periodo de sincronía de enlace de avance antes que el conteo de medición estuviera a punto de incrementarse. Si se utiliza este valor no modificado para calcular el Divisor de Velocidad Inversa, esto podría ocasionar errores de bit en el enlace inverso debido al muestreo de datos no confiable. Un ejemplo de esta situación se ilustra en la figura 51, en donde las señales que representan MDDI_Datos en el huésped, MDDI Stb en el huésped, sincronía de datos de enlace de avance dentro del huésped y Conteo de Retraso se hace que escriban el píxel resultante para la ubicación de píxel de destino ilustrada en forma gráfica. En la figura 51, la secuencia de respuesta se recibió del cliente una fracción de un periodo de sincronía de enlace de avance antes que el Conteo de Retraso estuviera a punto de incrementarse de 6 a 7. Si se asume que el retraso es 6, entonces el huésped muestreará los datos inversos justo después de una transición de bits o posiblemente a la mitad de una transición de bits. Esto podría dar como resultado un muestreo erróneo en el huésped. Por este motivo, el retraso medido típicamente se debería incrementar por uno antes que sea utilizado para calcular el Divisor de Velocidad Inversa. El Divisor de Velocidad Inversa es el número de ciclos MDDI_Stb que el huésped deberá esperar antes de muestrear los datos de enlace inverso. Debido a que MDDI_Stb es ciclada a una velocidad que es una mitad de la velocidad de enlace de avance, la medición de retraso de viaje redondo corregida necesita ser dividida entre 2 y después redondeada hacia arriba al siguiente entero. Expresada como una fórmula, esta relación es: r retraso _ viaje _ redondo + 1 divisor _velocidad _ inversa = RedondeoAlSiguienteEntero Para este ejemplo dado, esto se convierte en: divisor _velocidad Anversa = ^ edondeoAlSiguienteEntero] Si la medición de retraso de viaje redondo utilizada en este ejemplo fuera 7 en oposición a 6, entonces el Divisor de Velocidad Inversa también sería igual a 4. Los datos de enlace inverso son muestreados por el huésped en el borde elevado de la Sincronía de Enlace Inverso. Existe un contador o circuito similar conocido o dispositivo presente tanto en el huésped como en el cliente (pantalla) para generar la Sincronía de Enlace Inverso. Los contadores son inicializados de manera que el primer borde elevado de la Sincronía de Enlace Inverso ocurre al comienzo 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 que se proporciona a continuación, en la figura 52A. Los contadores aumentan en cada borde elevado de la señal MDDI_Stb, y el número de conteos que ocurre hasta que se envuelven, es establecido por el parámetro de Divisor de Velocidad Inversa en el Paquete de Encapsulación de Enlace Inverso. Debido a que la señal MDDI Stb se activa a una mitad de la velocidad del enlace de avance, entonces la velocidad del enlace inverso es una mitad de la velocidad del enlace de avance dividida por el Divisor de Velocidad Inversa. Por ejemplo, si la velocidad del enlace de avance es 200 Mbps y el Divisor de Velocidad Inversa es 4, entonces la velocidad de datos de enlace inverso se expresa como: 1.200^ 2 4 ün ejemplo que muestra la temporización de las líneas de señal de MDDI_DatosO y MDDI_Stb en un Paquete de Encapsulación de Enlace Inverso se muestra en la figura 52, en donde los parámetros de paquete utilizados para ilustración tienen los valores: Longitud de Paquete = 1024 Longitud de Giro 1 = 1 (0x0400) Tipo de Paquete = 65 Longitud de Giro 2 = 1 (0x41) Indicadores de Enlace Divisor de Velocidad Inverso = 0 Inversa =2 CRC de Parámetro = 0xdb43 Todos Ceros es 0x00 Los datos de paquete entre los campos de Longitud de Paquete y CRC de parámetro son: 0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, Oxdb, 0x00...

El primer paquete de enlace inverso que regresa del cliente es el Paquete de Solicitud y Estado del Cliente que tiene una Longitud de Paquete de 7 y un tipo de paquete de 70. Este paquete comienza con los valores de byte 0x07, 0x00, 0x46,... y así sucesivamente. Sin embargo, en la figura 52 solo es visible el primer byte (0x07) . Este primer paquete de enlace inverso es cambiado en tiempo por casi un periodo de sincronía de enlace inverso en la figura para ilustrar un retraso de enlace inverso real. Una forma de onda ideal con retraso de viaje redondo cero de huésped a cliente se muestra como un trazo de línea punteada. El byte MS del campo de CRC de Parámetro es transferido, precedido por el tipo de paquete, después el campo todos ceros. La marca estroboscópica del huésped está cambiando de uno a cero y de regreso a uno conforme los datos provenientes del huésped cambian de nivel, formando impulsos más amplios. Conforme los datos pasan a cero, la marca estroboscópica cambia a la velocidad superior, únicamente el cambio en los datos sobre la línea de datos ocasiona un cambio cerca del final del campo de alineación. La marca estroboscópica cambia a la velocidad superior por el resto de la figura debido a los niveles fijos 0 ó 1 de la señal de datos durante periodos de tiempo prolongados, y las transiciones caen en el patrón de impulso (borde) . La sincronía de enlace inverso para el huésped es a cero hasta el final del periodo de Giro 1, cuando la sincronía es iniciada para alojar los paquetes de enlace inverso. Las flechas en la porción inferior de la figura indican cuando los datos están muestreados, tal como sería aparente a partir del resto de la descripción. El primer byte del campo de paquete que está siendo transferido (aquí 11000000) se muestra comenzando después del Giro 1, y el nivel de línea se ha estabilizado a partir del accionador de huésped que ha sido inhabilitado. El retraso en el paso del primer bit, y como se aprecia para el bit tres, se puede apreciar en las líneas punteadas para la señal de Datos. En la figura 53, se pueden observar valores típicos del Divisor de Velocidad Inversa con base en la velocidad de datos de enlace de avance. El Divisor de Velocidad Inversa real se determina como un resultado de una medición de enlace de viaje redondo para garantizar la operación adecuada del enlace inverso. Una primera región 5302 corresponde a un área de operación segura, una segunda región 5304 corresponde a un área de rendimiento marginal, mientras que una tercera región 5306 indica las configuraciones que tienen pocas probabilidades de funcionar adecuadamente. Las configuraciones de la medición de retraso de viaje redondo y el Divisor de Velocidad Inversa son las mismas mientras operan con cualquiera de las configuraciones de Tipo de Interfaz ya sea en el enlace de avance o el enlace inverso, debido a que se expresan y operan en términos de unidades de periodos de sincronía real en lugar de números de bits transmitidos o recibidos. Por lo regular, el Divisor de Velocidad Inversa más grande posible es la mitad del número de bits que se puede enviar en la ventana de medición del Paquete de Medición de Retraso de Viaje Redondo utilizando una interfaz Tipo-1, o para este ejemplo: (5 Ylbytes • its 1 byte) _ ?M R También se puede emplear un método de muestreo de datos inversos avanzado como una alternativa que permite que el tiempo de los bits inversos sea más corto que el retraso de viaje redondo. Para esta técnica, un huésped no solo mide el retraso de viaje redondo, sino que también determina la fase de la respuesta del cliente con respecto a un límite de bits "ideal" de un cliente y enlace con retraso cero. Al conocer la fase de la respuesta del dispositivo del cliente, un huésped puede determinar un tiempo relativamente seguro para muestrear los bits de datos inversos del cliente. La medición de retraso de viaje redondo indica a un huésped la ubicación del primer bit de datos inversos con respecto al comienzo 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 de datos inversos ideal con cero retraso de viaje redondo se muestra como una forma de onda de línea punteada. El retraso de viaje redondo real, entre 3.5 y 4 ciclos de MDDI_Stb, se puede observar como la diferencia en retraso entre la forma de onda sólida y la ideal. Este es el mismo retraso que se mediría utilizando el Paquete de Medición de Retraso de Viaje Redondo, y sería un valor de retraso de viaje redondo medido igual a 7 veces el bit de enlace de avance. En esta modalidad, los bits de datos inversos son 2 impulsos MDDI_Stb largos, lo cual es 4 veces el bit de enlace de avance, lo cual corresponde a un Divisor de Velocidad Inversa igual a 2. Para muestreo avanzado de datos inversos, es conveniente utilizar un Divisor de Velocidad Inversa previamente seleccionado de 2 en lugar de calcularlo como se describió en otro apartado. Esto parece ser una opción sustancialmente óptima para muestreo avanzado de datos inversos debido a que el punto de muestreo ideal se puede determinar fácilmente utilizando las mediciones convencionales descritas anteriormente. El punto de muestreo ideal para datos inversos se puede calcular fácilmente tomando el resto del retraso de viaje redondo total dividido entre el número de sincronías de enlace de avance por bit inverso, o sincronías de enlace de avance de módulos de retraso de viaje redondo por bit inverso. Después, restar ya sea 1 6 2 para llegar a un punto seguro lejos de la transición de datos. En este ejemplo, 7 mod 4 = 3, después 3 - 1 = 2, ó 3 - 2 = 1. El punto de muestreo seguro es 1 ó 2 veces el bit de enlace de avance proveniente del borde del límite de bit "ideal" para retraso cero de viaje redondo. La figura muestra el punto de muestreo a 2 veces el bit de enlace de avance desde el límite de bit ideal, tal como lo indica la serie de flechas verticales en la parte inferior del diagrama de temporización. El primer punto de muestreo es el primer límite de bits ideal después del retraso de viaje redondo medido, más la compensación para el muestreo seguro. En este ejemplo, la medición de retraso de viaje redondo es 7, de manera que el siguiente límite de bits ideal es al tiempo de bit 8avo, después agregar ya sea 1 ó 2 para el punto de muestreo seguro, de manera que el primer bit debería ser muestreado ya sea a 9 ó 10 veces el bit de enlace de avance después del comienzo del campo de Paquetes de Datos Inversos.

XI. Tiempos de giro y guardia El campo de Giro 1 en el Paquete de Encapsulación de Enlace Inverso proporciona tiempo para que los accionadores del huésped se inhabiliten y los accionadores del cliente se habiliten simultáneamente. El campo de Tiempo de Guardia 1 en el Paquete de Medición de Retraso de Viaje Redondo permite el traslape del huésped y el cliente, de manera que los accionadores del cliente se pueden habilitar antes que los accionadores de interfaz del huésped sean inhabilitados. El campo de Giro 2 en el Paquete de Encapsulación de Enlace Inverso permite que los datos en el campo previo del cliente sean transmitidos completamente antes que los accionadores del huésped sean habilitados. El campo de Tiempo de Guardia 2 provee un valor o periodo de tiempo el cual permite a los accionadores del cliente y del huésped accionarse simultáneamente a un nivel de lógica cero. Los campos de Tiempo de Guardia 1 y Tiempo de Guardia 2 generalmente se rellenan con valores previamente establecidos o previamente seleccionados para longitudes que no se pretenden ajustar. Dependiendo del hardware de interfaz que se esté utilizando, estos valores se pueden desarrollar utilizando datos empíricos y se pueden ajustar en algunos casos para mejorar la operación.

Giro 1 Varios factores contribuyen a una determinación de la longitud de Giro 1 y estos son la velocidad de datos del enlace de avance, el tiempo de inhabilitación máximo de los accionadores de MDDI_Datos en el huésped, y el tiempo de habilitación del accionador del cliente el cual, generalmente es el mismo que el tiempo de inhabilitación del huésped. La longitud del campo de Giro 1 se selecciona para que sea 24-tB?t- (Cuadro XIII) . La longitud en el número de bytes de enlace de avance del campo de Giro 1 se determina utilizando el Factor de Tipo de Interfaz, y se calcula utilizando la relación: 24 Longitud GM = FactorTipoInterfazFlVD = 3 • FactorTipoInterfaz FÍVD itslbyte En donde el Factor de Tipo de Interfaz es 1 para Tipo 1, 2 para Tipo 2, 4 para Tipo 3, y 8 para Tipo 4.

Giro 2 Los factores que determinan la longitud de tiempo generalmente utilizados para el Giro 2 son, el retraso de viaje redondo del enlace de comunicación, el tiempo de inhabilitación máximo de los accionadores de MDDI_Datos en el cliente, y el tiempo de habilitación del accionador del huésped, el cual es especificado para que sea el mismo que el tiempo de inhabilitación del accionador del cliente. El tiempo de habilitación del accionador de huésped máximo y el tiempo de inhabilitación del accionador de cliente máximo se especifican en otro apartado. El retraso de viaje redondo se mide en unidades de tB?t- La longitud mínima especificada en el número de bytes de enlace de avance del campo de Giro 2 se calcula de acuerdo con la relación: RetrasoViajeRedondo+24 „ _. _ . Longitud G¡ro2 = RedondearAlSiguienteEntero Factor T?polnterjazFWD Sbits/byte Por ejemplo, un enlace de avance Tipo 3 con un retraso de viaje redondo de 10 sincronías de enlace de avance, típicamente utiliza un retraso de Giro 2 en el orden de: 11 + 24 Longitud Gíro2 = Redondear -AlSiguienteEnterol 4 =18bytes ~~8 XII. Temporización alternativa de enlace inverso Aunque el uso de temporización y bandas de guardia, analizadas anteriormente, funcionan para lograr una interfaz de velocidad de transferencia de datos alta, los inventores han descubierto una técnica para permitir longitudes de bits inversos que son más cortas que el tiempo de viaje redondo, cambiando el descubrimiento de la temporización inversa.

Como se mostró anteriormente, el enfoque previo respecto a la temporización del enlace inverso se configura para que el número de ciclos de sincronía se cuente a partir del último bit del Tiempo de Guardia 1 de un paquete de temporización inversa hasta que el primer bit es muestreado en el borde elevado de una sincronía 10. Es decir, las señales de sincronía utilizadas para medir las entradas y salidas para la MDDI. El cálculo para el divisor de velocidad inversa es entonces proporcionado por: retraso _ viaje _ redondo + 1 divisor _velocidad _inversa = RedondearAlSiguienteEntero\ Esto provee un ancho de bit igual al retraso de viaje redondo el cual produce como resultado un enlace inverso muy confiable. Sin embargo, el enlace inverso ha mostrado la capacidad para correr más rápido, o a una velocidad de transferencia de datos superior, de lo cual quieren sacar provecho los inventores. Una nueva técnica inventiva permite el uso de capacidades adicionales de la interfaz para alcanzar velocidades superiores. Esto se logra haciendo que el huésped cuente el número de ciclos de sincronía hasta que uno sea muestreado, pero en donde el huésped muestrea la línea de datos tanto en los bordes de subida como de bajada durante el paquete de temporización inversa. Esto permite al huésped elegir el punto de muestreo más útil o incluso óptimo dentro del bit inverso para asegurarse que el bit sea estable. Es decir, encontrar el borde elevado más útil u óptimo sobre el cual muestrear datos para paquetes de encapsulación inversa de tráfico inverso. El punto de muestreo óptimo depende tanto del divisor de enlace inverso como del hecho de saber si el primero se detectó en un borde de subida o un borde de bajada. El nuevo método de temporización permite al huésped solo buscar el primer borde del patrón OxFF, OxFF, 0x00 enviado por el cliente para temporización de enlace inverso a fin de determinar el lugar de muestreo en un paquete de encapsulación inversa. En la figura 64 se ilustran ejemplos del bit inverso de llegada y la forma en que ese bit buscaría varios divisores de velocidad inversa, junto con un número de ciclos de sincronía que han ocurrido desde el último bit del Tiempo de Guardia 1. En la figura 64, se puede apreciar que si el primer borde ocurre entre un borde de subida y de bajada (etiquetado como subida/bajada), el punto de muestreo óptimo para un divisor de velocidad inversa de uno, el punto de muestra óptimo es un borde de ciclo de sincronía etiquetado "b", ya que ese es el único borde elevado que ocurre dentro del periodo del bit inverso. Para un divisor de velocidad inversa de dos, el punto de muestreo óptimo sigue siendo probablemente el borde guía de ciclo de sincronía "b" ya que el borde de ciclo "c" está más cerca de un borde de bit que ?b". Para un divisor de velocidad inversa de cuatro, el punto de muestreo óptimo es probablemente el borde de ciclo de sincronía "d", ya que está más cerca del borde posterior del bit inverso en donde el valor probablemente se ha estabilizado. Volviendo a la figura 64, sin embargo, si el primer borde ocurre entre un borde de bajada y de subida (etiquetado como bajada/subida), el punto de muestreo óptimo para un divisor de velocidad inversa de uno es el borde de ciclo de sincronía de punto de muestreo "a", ya que ese es el único borde de subida dentro del periodo de tiempo del bit inverso. Para un divisor de velocidad inversa de dos, el punto de muestreo óptimo es el borde "b", y para un divisor de velocidad inversa de cuatro, el punto de muestreo óptimo es el borde "c". Se puede apreciar que conforme los divisores de velocidad inversa se hacen más y más grandes, el punto de muestreo óptimo se vuelve más fácil de determinar o seleccionar, ya que éste debería ser el borde de subida que esté más cerca de la parte media. El huésped puede utilizar esta técnica para encontrar el número de bordes de sincronía en subida antes que el borde de datos en subida, de los datos de paquete de temporización, se observe en la línea de datos. Enseguida puede decidir, con base en si el borde ocurre entre un borde de subida y bajada o entre un borde de bajada y subida, y cuál es el divisor de velocidad inversa, cuántos ciclos de sincronía adicionales agregar a un contador de números, para asegurar de manera razonable que el bit siempre sea muestreado lo más cerca posible de la parte media. Una vez que el huésped ha seleccionado o determinado el número de ciclos de sincronía, éste puede "explorar" varios divisores de velocidad inversa con el cliente para determinar si funcionará un divisor de velocidad inversa particular. El huésped (y el cliente) pueden comenzar con un divisor de uno y revisar el CRC del paquete de estado inverso recibido desde el cliente para determinar si esta velocidad inversa funciona apropiadamente para transferir datos. Si el CRC está viciado, probablemente haya un error de muestreo, y el huésped puede incrementar el divisor de velocidad inversa y tratar de solicitar un paquete de estado nuevamente. Si el segundo paquete solicitado está viciado, el divisor puede ser incrementado nuevamente y se puede volver a realizar la solicitud. Si este paquete es decodificado correctamente, este divisor de velocidad inversa se puede utilizar para todos los paquetes inversos futuros.

Este método es efectivo y útil debido a que la temporización inversa no debería cambiar del estimado de temporización de viaje redondo inicial. Si el enlace de avance es estable, el cliente debería continuar decodificando paquetes de enlace de avance incluso si hay fallas de enlace inverso. Por supuesto, sigue siendo responsabilidad del huésped fijar un divisor de enlace inverso para el enlace, debido a que este método no garantiza un enlace inverso perfecto. Además, el divisor dependerá principalmente de la calidad de la sincronía que se utilice para generar una sincronía 10. Si esa sincronía tiene una cantidad importante de fluctuación, hay una mayor posibilidad para un error de muestreo. Esta probabilidad de error aumenta con la cantidad de ciclos de sincronía en el retraso de viaje redondo. Esta ejecución parece funcionar mejor para los datos inversos Tipo 1, pero puede presentar problemas para los datos inversos Tipo 2 a Tipo 4 debido a que el sesgo entre las líneas de datos puede ser potencialmente demasiado grande para correr el enlace a la velocidad que mejor funciona para un solo par de datos. Sin embargo, la velocidad de datos probablemente no necesite ser reducida al método previo incluso con Tipo 2 a Tipo 4 para 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 sincronía óptima o ideal. Si están al mismo tiempo de muestra para cada par de datos, este método seguiría funcionando. Si están a diferentes periodos de muestra, se pueden emplear dos enfoques diferentes. El primero es seleccionar una ubicación de muestra deseada o más optimizada para cada punto de datos, incluso si éste no es el mismo para cada par de datos. El huésped puede entonces reconstruir la corriente de datos después de muestrear todos los bits 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 para que el huésped incremente el divisor de velocidad inversa de manera que los bits de datos para cada par de datos puedan ser muestreados en el mismo borde de sincronía.

XIII. Efectos de sesgo y retraso de enlace El sesgo de retraso en el enlace de avance entre los pares de MDDI_Datos y MDDI_Stb puede limitar la velocidad de datos posible máxima a menos que se utilice la compensación de sesgo de retraso. Las diferencias en retraso que ocasionan el sesgo de temporización se deben a la lógica de controlador, los accionadores y receptores de línea, y el cable y conectores como se menciona a continuación.

A. Análisis de temporización de enlace limitado por el sesgo (MDDI Tipo-1) 1. Ejemplo de retraso y sesgo de un enlace Tipo 1 Un circuito de interfaz típico similar a aquel que se muestra en la figura 41, se muestra en la figura 57 para alojar un enlace de interfaz Tipo 1. En la figura 57, se muestran valores ejemplares o típicos para el sesgo y retraso de propagación para cada una de las diversas etapas de interfaz o procesamiento de un enlace de avance MDDI Tipo 1. El sesgo en el retraso entre MDDI_Stb y MDDI_Datos0 ocasiona que el ciclo de trabajo de la sincronía de salida se distorsione. Los Datos en la entrada D de la etapa de basculador del receptor (RXFF) utilizando basculadores 5728, 5732, cambian ligeramente después del borde de sincronía, de manera que se pueden muestrear de manera confiable. La figura muestra dos líneas de retraso en cascada 5732a y 5732b que se utilizan para resolver dos problemas diferentes con la creación de esta relación de temporización. En la ejecución real, éstas se pueden combinar en un solo elemento de retraso. En la figura 58 se ilustran Datos, Stb, y Temporización de Recuperación de Sincronía en un Enlace Tipo 1 para procesamiento de señal ejemplar a través de la interfaz.

El sesgo de retraso total que es significativo, generalmente surge o proviene de la suma del sesgo en las siguientes etapas: basculador de transmisor (TXFF) con basculadores 5704, 5706; accionador de transmisor (TXDRVR) con accionadores 5708, 5710; el CABLE 5702; receptor de línea de receptor (RXRCVR) con receptores 5722, 5724; y lógica XOR de receptor (RXXOR) . El Retrasol 5732a deberá coincidir con, o exceder el retraso de la compuerta XOR 5736 en la etapa RXXOR la cual queda determinada por la relación: tpD -min(.Retraso\) — *PD -m¡tx(XOR) Es deseable cumplir con este requerimiento de manera que la entrada D del basculador de receptor 5728, 5732 no cambie antes que su entrada de sincronía. Esto es válido si el tiempo de espera de RXFF es cero. El propósito o función del Retraso2 es compensar el tiempo de espera del basculador RXFF de acuerdo con la relación: tpD-min(Retraso2) ~ ^H(RXFF) En muchos sistemas éste será cero debido a que el tiempo de espera es cero, y por supuesto, en ese caso, el retraso máximo de Retraso2 también puede ser cero. El peor caso de contribución al sesgo en la etapa XOR del receptor se ubica en el caso de datos-tardíos/estroboscópica-temprana en donde el Retrasol se ubica a un valor máximo y la salida de sincronía de la compuerta XOR llega lo más pronto posible de acuerdo con la relación: ESG0-max(RXX0R) ~ -" PD-raax(Retrasol) tpD-rain(X0R) En esta situación, los datos pueden cambiar entre dos periodos de bit, n y n+1, muy cerca del tiempo en donde el bit n+1 está en sincronía con el basculador del receptor. La velocidad máxima de datos (periodo mínimo de bits) de un enlace Tipo 1 MDDI es una función del sesgo máximo encontrado a través de todos los accionadores, cable, y receptores en el enlace MDDI más la configuración de datos total en la etapa RXFF. El sesgo de retraso total en el enlace hasta la salida de la etapa RXRCVR se puede expresar como: tsESGO-max(ENLACE) ~ ^SESGO-max{TXFF) + * SESGO-msx.{TXDRVR) + * SESGO-max(CABLE) + ' * SESGO-max(RXRCVR) en donde el "cable" representa una variedad de conductores o interconexiones o alambres y retraso correspondiente, y el periodo mínimo de bits es proporcionado por: ir-mi tsESGOmaxíENLAC? ~*~ ¿ ' *B-TP4 "*" • fluctuaci?-¡mésped+ *PD-max(Ríras?2) + *SU(RXFF¡ En el ej emplo que se muestra en la figura 57 para modo externo, tSESGo-max (ENLACE) = 1000 pseg y el periodo de bit mínimo se puede expresar como : tB]T_min = 1000 + 2-125 + 625+125 + 200 + 0 + 100 = 2300/weg, o mencionar como aproximadamente 434 Mbps . En el ej emplo que se muestra en la figura 57 , para modo interno, tSESG0_ max (ENLACE) = 500 pseg y el periodo de bit mínimo se puede expresar como : tßiT-mm = 500 + 2-125 + 625 + 125 + 200 + 0+1.00 = 1800/weg, o mencionar como aproximadamente 555 Mbps, B. Análisis de temporización de enlace para MDDI Tipo 2, 3 Y 4 Un circuito de interfaz típico similar al que se muestra en las figuras 41 y 57 se muestra ahora en la figura 59 para alojar enlaces de interfaz Tipo 2, 3, y 4.

Los elementos adicionales se utilizan en las etapas TXFF (5904), TXDRVR (5908), RXRCVCR (5922), y RXFF (5932, 5928, 5930) para permitir el procesamiento adicional de señales. En la figura 59, valores ejemplares o típicos para el retraso de propagación y sesgo se muestran para cada una de las diversas etapas de interfaz o procesamiento de un enlace de avance MDDI Tipo 2. Además del sesgo en el retraso entre MDDI_Stb y MDDI_Datos0 que afectan el ciclo de trabajo de la sincronía de salida, también existe sesgo entre estas dos señales y las otras señales de MDDI_Datos. Los Datos en la entrada D de la etapa de basculador de receptor B (RXFFB) que consta de basculadores 5928 y 5930, cambian ligeramente después del borde de sincronía, de manera que se pueden muestrear de manera confiable. Si MDDI_Datosl llega antes que MDDI_Stb o MDDI_Datos0, entonces MDDI_Datosl se debería retrasar para ser muestreada por lo menos por la cantidad del sesgo de retraso. Para lograr esto, los datos son retrasados utilizando la línea de retraso Retraso3. Si MDDI_Datosl llega después que MDDI_Stb y MDDI_DatosO y también está retrasada por Retraso3, entonces el punto en donde MDDI_Datosl cambia, se traslada a una posición más cercana al siguiente borde de sincronía. Este proceso determina un límite superior de la velocidad de datos de un enlace MDDI Tipo 2, 3 ó 4. Algunas posibilidades diferentes ejemplares para la relación de sesgo o temporización de dos señales de datos y MDDI_Stb con respecto entre sí se ilustran en las figuras 60A, 60B y 60C. Para muestrear datos de manera confiable en RXFFB cuando MDDI_DatosX llega lo más pronto posible, Retraso3 se configura de acuerdo con la relación: tpD-mm(Retraso3) ~ ' SESGO-max(ENLACE) + A(RXFFB) "*" ^ PD- ax{X0R) La velocidad máxima de enlace queda determinada por el periodo de bits mínimo permitido. Esto se ve más afectado cuando MDDI_DatosX llega lo más tarde posible. En ese caso, el tiempo de ciclo mínimo permitido es proporcionado por: ¿BIT-min = • SESGO-msx(ENLACE) + * PD-max(Relraso3) + u{RXFFB) ~ PD-pan(XOR) El límite superior de la velocidad de enlace es entonces : tpD-max(Retraso3) tpD-min( Retraso3) Y conforme a la suposición que : l BIT-mm(¡ímite-inferior) ~ ¿ " t SESGO-maxtENIACE) + PD-max(XOR) + u(RXFFB) + ''H{RXFFB) En el ejemplo arriba proporcionado, el límite inferior del periodo de bit mínimo es proporcionado por la relación: tB,t-^um¡l -¡n feriar) = 2 • (1000 + 2 • 125 + 625 + 200) + 1500 + 100 + 0 = 5150 pseg que es aproximadamente 174 Mbps. Esto es mucho más lento que la velocidad de datos máxima que se puede utilizar con un enlace Tipo 1. La capacidad de compensación de sesgo de retraso automático de MDDI reduce significativamente el hecho de que el sesgo de retraso que tiene sobre el factor de velocidad máxima de enlace está justo en-el-borde de la configuración de datos válida. El sesgo calibrado entre MDDI_DatosO y MDDI_Stb es: t 1 SESGO- sx(Caiibrado) = 2 ^-t l DERIVACIÓN -SEPARACIÓN -max ' y el periodo mínimo de bits es: ' BIT -m¡n -Calibrado ~ ' SESGO -ma.\( Calibrado ) "*" ^ ' ' * B-TP 4 + ' Asmarla "*" ' fluctuaría n -huésped + ' SESGO -max( RXAND +RXXOR ) + ¡ SU (RXI? ) En donde "TB" o tB representa la fluctuación de señal de un límite de bits a un nivel de salida mínimo. La Asimetría simplemente se refiere a la naturaleza asimétrica del retraso interno a través de, o de los receptores diferenciales. ??tp4" Se asocia con, o queda definido de manera efectiva para propósitos de prueba y caracterización eléctrica como la conexión o interfaz (bornes del dispositivo de controlador MDDI en el cliente) para los accionadores y receptores de línea diferencial para el cliente. Representa un punto conveniente o predeterminado a partir del cual se mide el retraso de señal y se caracteriza por el enlace a través del resto de un sistema. En una modalidad, un valor máximo del parámetro tB en TP4 queda definido por la relación tDiferenciai-sesgo-tp4-DRVR-Ext =0.3- tBIT para el modo externo y tDife?encíai-sesgo-tp4-DRVR-iNt =0.6-ÜBJG para el modo interno para los transmisores de cliente; y T B-TP4-RCVR-EXT = 0.051- tB?t + 1 5 ps para el modo externo para los receptores del cliente. La etiqueta TP4 simplemente es útil para numerar varios puntos de prueba (TP) en la interfaz y enlaces. En una modalidad, esta ubicación de punto de prueba queda definida para que sea la misma tanto para modos internos como externos. Existe un punto de prueba "TPO" correspondiente para, o asociado con los bornes de interfaz o conexión del dispositivo de controlador MDDI en el huésped que contiene los accionadores y receptores de línea diferencial. En esta modalidad, un valor máximo del parámetro TB en TPO queda definido por la relación tB-TP0-RcvR- IN = 0 . 051 - tBXT + 50ps, para modo interno y tB-tpo-RcvR-ext = 0 . 051 - tBtt + 175ps, para modo externo para los receptores de huésped; y tB- P0 - 0 . 102 - tBIT para los transmisores de huésped . En el ej emplo que se muestra en la figura 59 , tS£SGo-max(Datos?-stb-caiibrado) = 300 pseg, el periodo mínimo de bits : -min-ca/ o =300 + 2 -125 + 625 + 200+175+100 = 1650^eg aproximadamente 606 Mbps. Para muestrear datos de manera confiable en RXFFB cuando MDDI_Datosl llega lo más pronto 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 derivación adicional para seguridad. La velocidad máxima del enlace queda determinada por el periodo de bits mínimo permitido. Esto se ve más afectado cuando MDDI_Datosl llega lo más tarde posible. En ese caso, el tiempo de ciclo mínimo permitido es: *BlT-mm-Dato$l-Calibraclo ~ ¿ ' • DERIVACIÓN -Separa ?n- sx. + ^ ' ^TA-TP4> donde "TA" o tñ representa fluctuación de señal de un límite de bit para cruzado centrado.

En el ejemplo que se proporciona en la figura 59, el límite inferior del periodo de bit mínimo basado en el muestreo de MDDI_Datosl es: tBIT-tzin-Datosl-Calibrado = 2 - 150 + 2 - 125 = 550 PSßg En una modalidad, un tiempo de retraso total típico para el sesgo de retraso, asimetría de retraso, y Fluctuación de Sincronía en el transmisor de huésped para el Modo Interno se definiría como: t Asimetria-TXFF + ' Asimetria-TXDRVR + *Sesgo-TXFF + ' Sesgo-TXDRVR + fluctuación-huésped = U.4? / - ( B/r — IDOpS), y para el modo externo como: " Asimetria-TXFF + ' As? etria-TXDRVR + ^Sesgo-TXFF ~*~ " Sesgo-TXDRVR + ' fluctuada-huésped ~~ "^ "^' *B1T -* *" ÍSUpS) mientras que un tiempo de retraso total típico para sesgo de retraso, asimetría de retraso, y tiempo de establecimiento en el dispositivo del cliente (tB-tp ) para modo interno es : 1 Asimetria-RXRCVR + Asimetrí -RXXOR + SesgcpRXRCVR + ^Sesgo-RXXOR + 1 establecer-RXFF ~ ^"^ ' " VBIT ~ ->VPS) y para modo externo : ~ " -í BD' (tßJT 1 BDpS), en donde el término TBD es una etiqueta que mantiene el lugar flexible para valores que se van a determinar en un futuro, los cuales dependen de una variedad de características bien entendidas y requerimientos operativos para las conexiones de modo externo.

XIV. Descripción de interconexión de capa física Las conexiones físicas útiles para ejecutar una interfaz de acuerdo con la presente invención se pueden desarrollar utilizando partes comercialmente disponibles tal como el número de parte 3260-8S2(01) tal como es fabricada por Hirose Electric Company Ltd. en el lado del huésped, y el número de parte 3240-8P-C tal como es fabricada por Hirose Electric Company Ltd. en el lado del dispositivo del cliente. Una asignación de borne de interfaz ejemplar o "salida de borne" para dichos conectores utilizados con una interfaz Tipo-l/Tipo-2 se lista en el cuadro XV, y se ilustra en la figura 61.

CUADRO XV El recubrimiento está conectado al HUESPED_Gnd en la interfaz de huésped, y un hilo de drenaje de recubrimiento en el cable está conectado al recubrimiento del conector del cliente. Sin embargo, el recubrimiento y el hilo de drenaje no están conectados al circuito base dentro de un cliente. Los elementos o dispositivos de interconexión se eligen o diseñan para ser lo suficientemente pequeños para uso con dispositivos de cómputo o comunicación móvil, tal como PDA y teléfonos inalámbricos, o dispositivos de juego portátiles, sin ser demasiado prominentes o carentes de estética en comparación con el tamaño de dispositivo relativo. Cualesquiera conectores y cableado deberá ser lo suficientemente duradero para uso en el ambiente del consumidor típico y permitir el tamaño pequeño, especialmente para el cableado, y costo relativamente bajo. Los elementos de transferencia deberán alojar las señales estroboscópicas y de datos que son datos NRZ diferenciales que tienen una velocidad de transferencia hasta de alrededor de 450 Mbps para Tipo 1 y Tipo 2 y hasta 3.6 Gbps para la 'versión paralela de 8 bits Tipo 4. Para aplicaciones de modo interno, no hay conectores en el mismo sentido para los conductores que se están utilizando o dichos elementos de conexión tienden a ser muy pequeños en tamaño. Un ejemplo son los "enchufes" de fuerza de inserción cero para recibir circuitos integrados o elementos que alojan ya sea el dispositivo de huésped o de cliente. Otro ejemplo es donde el huésped y el cliente residen en tableros de circuitos impresos con varios conductores interconectados, y tienen "bornes" o contactos que se extienden desde los alojamientos, los cuales están soldados a los contactos en los conductores para interconexión de circuitos integrados.

XV. Operación ün resumen de los pasos generales emprendidos en el procesamiento de datos y paquetes durante la operación de una interfaz utilizando las modalidades de la invención se muestra en las figuras 54A y 54B, junto con una perspectiva general del aparato de interfaz que procesa los paquetes en la figura 55. En estas figuras, el proceso inicia en un paso 5402 con una determinación respecto a si el cliente y el huésped están o no conectados mediante el uso de una trayectoria de comunicación, aquí un cable. Esto puede ocurrir a través del uso de sondeos periódicos por parte del 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 puede apreciar para las interfaces USB), u otras técnicas conocidas. Si no hay un cliente conectado al huésped, entonces éste simplemente puede entrar a un estado de espera de cierta longitud predeterminada, dependiendo de la aplicación, pasar a un modo de hibernación, o quedar inactivo en espera de uso futuro lo cual requeriría que un usuario emprendiera una acción para reactivar al huésped. Por ejemplo, cuando un huésped reside en un dispositivo tipo computadora, un usuario podría tener que hacer clic en un icono de pantalla o solicitar a un programa que active el procesamiento del huésped para buscar al cliente. Una vez más, el simple enchufe de una conexión tipo USB podría activar el procesamiento del huésped, dependiendo de las capacidades y configuración del huésped o del software de huésped residente. Una vez que un cliente está conectado al huésped, o viceversa, o se detecta su presencia, el cliente o el huésped envía paquetes apropiados solicitando el servicio en los pasos 5404 y 5406. El cliente podría enviar cualesquiera paquetes de Estado y Solicitud de Servicio del Cliente en el paso 5404. Se puede apreciar que el enlace, tal como se analizó anteriormente, pudo haber sido apagado previamente o pudo ser puesto en modo de hibernación de manera que esto puede no ser una inicialización completa del enlace de comunicación que sigue. Una vez que el enlace de comunicación está sincronizado y el huésped está tratando de establecer comunicación con el cliente, el cliente también provee un Paquete de Capacidades del Cliente al huésped, como en el paso 5408. El huésped ahora puede comenzar a determinar el tipo de soporte, incluyendo las velocidades de transferencia, que el cliente puede permitir. Generalmente, el huésped y el cliente también negocian el tipo (tasa/velocidad) de modo de servicio que se va a utilizar, por ejemplo, Tipo 1, Tipo 2, y así sucesivamente, en un paso 5410. Una vez que se establece el tipo de servicio, el huésped puede comenzar a transferir información. Además, el huésped puede utilizar Paquetes de Medición de Retraso de Viaje Redondo para optimizar la temporización de los enlaces de comunicación en paralelo con otro procesamiento de señal, como se muestra en el paso 5411.

Tal como se mencionó anteriormente, todas las transferencias comienzan con un Paquete de Encabezado de Sub-Cuadro, que se muestra como transferido en el paso 5412, seguido por el tipo de datos, aquí paquetes de corriente de video y audio, y paquetes de relleno, que se muestran transferidos en el paso 5414. Los datos de audio y video habrán sido previamente preparados o mapeados en paquetes, y los paquetes de relleno se insertan según sea necesario o deseable para rellenar un número requerido de bits para los cuadros de medios. El huésped puede enviar paquetes tal como los Paquetes de Habilitación de Canal de Audio de Avance para activar dispositivos de sonido. Además, el huésped puede transferir comandos e información utilizando otros tipos de paquete antes analizados, aquí mostrados como la transferencia de Mapa de Color, 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 dispositivos de señalamiento utilizando los paquetes apropiados. Durante la operación, puede ocurrir uno de varios eventos diferentes el cual conduzca a que el huésped o el cliente deseen una velocidad de datos diferente o tipo de modo de interfaz diferente. Por ejemplo una computadora u otro dispositivo que comunique datos podría encontrar condiciones de carga en el procesamiento de datos lo que ocasionaría lentitud en la preparación o presentación de paquetes. Un dispositivo del cliente que recibe los datos podría cambiar de una fuente de energía AC dedicada a una fuente de energía de batería más limitada, y pudiera no tener la capacidad para transferir datos de manera tan rápida, procesar comandos de manera tan fácil, o utilizar el mismo grado de resolución o profundidad de color bajo los escenarios de energía más limitados. Alternativamente, una condición restrictiva se podría mitigar o desaparecer permitiendo a cualquier dispositivo transferir datos a velocidades superiores. Esto es más deseable, se puede hacer una solicitud para cambiar a un modo de velocidad de transferencia superior. Si estos u otros tipos de condiciones conocidas ocurren o cambian, ya sea el cliente o el huésped pueden detectarlas y tratar de renegociar el modo de interfaz. Esto se muestra en el paso 5420, en donde el huésped envía Paquetes de Solicitud de Transferencia Tipo Interfaz al cliente solicitando una transferencia a otro modo, el cliente envía Paquetes de Reconocimiento Tipo Interfaz confirmando que se está buscando un cambio, y el huésped envía Paquetes de Transferencia de Tipo Ejecución para hacer el cambio al modo especificado. Aunque no se requiere un orden particular de procesamiento, el cliente y el huésped también pueden intercambiar paquetes relacionados con datos destinados para, o recibidos desde dispositivos de señalamiento, teclados, u otros dispositivos de entrada de tipo usuario asociados principalmente con el cliente, aunque dichos elementos también pueden estar presentes en el lado del huésped. Estos paquetes típicamente son procesados utilizando un elemento tipo procesador general y no la máquina de estado (5502) . Además, algunos de los comandos anteriormente analizados también serán procesados por el procesador general. (5504, 5508) . Después que los datos y comandos han sido intercambiados entre el huésped y el cliente, en cierto punto se toma una decisión respecto a si se van a transferir o no datos adicionales o si el huésped o cliente va a cesar o no el servicio de transferencia. Esto se muestra en el paso 5422. Si el enlace va a entrar a un estado de hibernación o se va a apagar completamente, el huésped envía un paquete de Apagado de Enlace al cliente, y ambos lados terminan la transferencia de datos. Los paquetes que se están transfiriendo en el procesamiento de las operaciones anteriores serán transferidos utilizando los accionadores y receptores previamente analizados en relación con los controladores del huésped y del cliente. Estos accionadores de línea y otros elementos lógicos están conectados a la máquina de estado y procesadores generales anteriormente analizados, tal como se ilustra en la perspectiva general de la figura 55. En la figura 55, una máquina de estado 5502 y procesadores generales 5504 y 5508 además se pueden conectar a otros elementos que no se muestran, tal como una interfaz USB dedicada, elementos de memoria, u otros componentes que residen fuera del controlador de enlace con los cuales interactúan, incluyendo, pero no limitado a, la fuente de datos, y chips de control de video para dispositivos de pantalla de visualización. Los procesadores, y la máquina de estado proveen control sobre la habilitación e inhabilitación de los accionadores, tal como se analizó anteriormente, con relación a los tiempos de guardia, y así sucesivamente, para asegurar el establecimiento o terminación eficiente del enlace de comunicación, y la transferencia de paquetes.

XVI. Memorias intermedias de cuadro de pantalla Los requerimientos para almacenamiento en memoria intermedia de datos de video son diferentes para imágenes de video en movimiento en comparación con gráficos de cómputo. Los datos de píxel con mayor frecuencia se almacenan en una memoria intermedia de cuadro local en el cliente, de manera que la imagen en el cliente se puede renovar localmente.

Cuando se está desplegando video de secuencia en movimiento (casi todos los píxeles en la pantalla cambian cada Cuadro de Medio) por lo regular se prefiere almacenar los datos de píxel entrantes en una memoria intermedia de cuadro, mientras que la imagen en la pantalla está siendo renovada a partir de una segunda memoria intermedia de cuadro. Se pueden utilizar más de dos memorias intermedias de pantalla para eliminar los artefactos visibles, tal como se describe a continuación. Cuando toda la imagen ha sido recibida en una memoria intermedia de cuadro, entonces las funciones de las memorias intermedias se pueden intercambiar, y la imagen recientemente recibida se utiliza entonces para renovar la pantalla y la otra memoria intermedia se llena con el siguiente cuadro de la imagen. Este concepto se ilustra en la figura 88A, en donde los datos de píxel se escriben en la memoria intermedia de imagen fuera de línea estableciendo los bits de Actualización de Pantalla a "01". En otras aplicaciones, el huésped necesita actualizar únicamente una pequeña porción de la imagen sin tener que volver a pintar la imagen completa. En esta situación, es deseable escribir los nuevos píxeles directamente en la memoria intermedia que se está utilizando para renovar la pantalla, tal como se ilustra a detalle en la figura 88B.

En aplicaciones que tienen una imagen fija con una ventana de video pequeña, es más sencillo escribir la imagen fija en ambas memorias intermedias (bits de actualización de pantalla igual a "11") como se muestra en la figura 88C, y posteriormente escribir los píxeles de la imagen en movimiento en la memoria intermedia fuera de línea estableciendo los bits de actualización de pantalla en "01". Las siguientes reglas describen la manipulación útil de los indicadores de memoria intermedia al mismo tiempo que se escribe nueva información para el cliente y se renueva la pantalla. Existen tres indicadores de memoria intermedia: llenado_actual señala a la memoria intermedia que en ese momento se está llenando a partir de los datos en el enlace MDDI. Recién_llenado señala a la memoria intermedia que se llenó más recientemente. Está_desplegado señala a la memoria intermedia que en ese momento se está utilizando para renovar la pantalla. Los tres indicadores de memoria intermedia pueden contener valores de 0 a N-l, en donde N es el número de memorias intermedias de pantalla, y N > 2. La aritmética en los indicadores de memoria intermedia es mod N, por ejemplo cuando N = 3 y llenado_actual = 2, el incremento del llenado_actual provoca que el llenado_actual se fije en 0. En el caso simple donde N = 2, recién_llenado siempre es el complemento de llenado_actual. En cada límite de Cuadro de medios MDDI (Paquete de Encabezado de Sub-Cuadro con el campo de Conteo de Sub-Cuadro igual a cero) realizar las siguientes operaciones en el orden especificado: establecer recién__llenado igual a llenado_actual, y establecer llenado_actual igual a llenado_actual +1. Los Paquetes de Corriente de Video MDDI actualizan las memorias intermedias de acuerdo con la estructura o metodología de: cuando los Bits de Actualización de Pantalla igual a 0i? los datos de píxel se escriben en la memoria intermedia especificada por llenado_actual; cuando los Bits de Actualización de Pantalla igual a ?00', los datos de píxel se escriben en la memoria intermedia especificada por recién_llenado; y cuando los Bits de Actualización de Pantalla igual a ?ll' , los datos de píxel se escriben en todas las memorias intermedias. La pantalla se renueva a partir de la memoria intermedia especificada por el indicador se_está_desplegando. Después que la pantalla renueva el último píxel en una etapa de renovación de cuadro y antes que comience a renovar el primer píxel en la siguiente etapa de renovación de cuadro, el proceso de actualización de pantalla ejecuta la operación de establecer se_está_renovando igual a recién_llenado. Los Paquetes con un campo de Atributo de Datos de Píxel contienen un par de Bits de Actualización de Pantalla que especifican la memoria intermedia de cuadro en donde se van a escribir los datos de píxel. El Paquete de Capacidad del 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, imágenes generadas por computadora necesitan ser incrementalmente actualizadas con base en la entrada de usuario o derivadas de la información recibida desde una red de cómputo. Las combinaciones de Bits de Actualización de Pantalla "00" y "11" soportan este modo de operación ocasionando que los datos de píxel sean escritos en la memoria intermedia de cuadro que se está desplegando o en ambas memorias intermedias de cuadro. Cuando se permiten imágenes de video, la figura 89 ilustra la forma en que las imágenes de video son desplegadas utilizando un par de memorias intermedias de cuadro cuando los datos de video son transmitidos en el enlace MDDI con los Bits de Actualización de Pantalla igual a "01". Después que se detecta un límite de cuadro de medios en el enlace MDD1, el proceso de actualización de pantalla comenzará la actualización a partir de la siguiente memoria intermedia de cuadro, cuando se completa el proceso de actualización para el cuadro que en ese momento se está actualizando.

Una suposición importante con referencia a la figura 89 es que la imagen es recibida desde el huésped como una corriente continua de píxeles que son transmitidos en el mismo orden que el cliente utiliza para leer los píxeles desde la memoria intermedia de cuadro para actualizar la pantalla (generalmente izquierda-superior, leyendo fila por fila, a la esquina derecha inferior de la pantalla) . Este es un detalle importante en los casos donde las operaciones de Actualización de Pantalla y Transferencia de Imágenes hacen referencia a la misma memoria intermedia. Es necesario que la velocidad del cuadro de actualización de pantalla sea mayor que la velocidad de cuadro de transferencia de imágenes para evitar el despliegue de imágenes parciales. La figura 90 muestra la forma en que ocurre una fragmentación de imagen con una velocidad de actualización de pantalla lenta, es decir, la actualización de pantalla es más lenta que la transferencia de imágenes . En una imagen que contiene una combinación de imágenes gráficas de cómputo e imágenes de video en movimiento, los datos de píxel de video podrían ocupar una pequeña porción de un cuadro de medios. Esto podría ser importante en situaciones donde la operación de actualización de pantalla y la transferencia de imágenes hacen referencia a la misma memoria intermedia. Estas situaciones se muestran por medio de un sombreado cruzado en la figura 91, en donde los píxeles leídos de la memoria intermedia para actualizar la pantalla podrían ser los píxeles escritos para la memoria intermedia dos cuadros atrás, o podrían corresponder a la memoria intermedia que se está escribiendo inmediatamente en la misma memoria intermedia. El uso de tres memorias intermedias en el cliente resolverá el problema de la pequeña ventana de contención para acceso a una memoria intermedia de cuadro, tal como se muestra en la figura 92. Sin embargo, sigue existiendo un problema si la velocidad de actualización de pantalla es menor que la velocidad de cuadro de medios en el enlace MDDI, tal como se muestra en la figura 93. El uso de una sola memoria intermedia para imágenes de video en movimiento es, de cierta forma, problemático, tal como se muestra en la figura 94. Con la actualización de pantalla más rápida que la transferencia de imágenes en la memoria intermedia, la imagen que se está actualizando en ocasiones mostrará la porción superior del cuadro como escrita y la porción inferior de la imagen será el cuadro previamente transferido. Con la actualización de pantalla más rápida que la transferencia de imágenes (el modo de operación preferido) habrá más casos frecuentes de cuadros que muestren una imagen dividida similar.

XVII. Soporte de clientes múltiples La versión de protocolo actual no parece soportar directamente múltiples dispositivos de cliente. Sin embargo, la mayoría de los paquetes contiene un campo de ID de Cliente reservado que se puede utilizar para direccionar dispositivos de cliente específicos en un sistema con múltiples clientes. Actualmente, para muchas aplicaciones, esta ID de cliente o estas ID de clientes se configuran para que sean cero. El paquete de encabezado de sub-cuadro también contiene un campo para indicar si el huésped soporta o no un sistema de clientes múltiples. Por lo tanto, existe una forma en la que dispositivos de múltiples clientes tienen la probabilidad de estar conectados y direccionados en futuras aplicaciones de la MDDI o protocolo para ayudar a los diseñadores del sistema a planear la compatibilidad futura con clientes y huéspedes de múltiples clientes. En sistemas que tienen múltiples clientes, resulta útil que los clientes sean conectados al huésped utilizando una cadena de margarita de clientes, o utilizando terminales, como se muestra en la figura 95, o utilizando una combinación de estas técnicas como se muestra en la figura 96. También puede resultar útil que un huésped despliegue ciertos mensajes de error para administrar a los clientes conectados, tal como un mensaje de error cuando uno o más clientes que desean la dirección 0 están conectados, lo cual no debería ser el caso para sistemas de múltiples clientes, ya que dichas pantallas se espera que sean o estén configuradas para operar como el único cliente.

XIII. Apéndice Además de los formatos, estructuras, y contenido analizado anteriormente para los diversos paquetes utilizados en la ejecución de la arquitectura y protocolo para las modalidades de la invención, aquí se presentan más operaciones o contenido de campo detallado para algunos tipos de paquete. Estos se presentan aquí para aclarar adicionalmente su uso u operaciones respectivas con el fin de permitir a aquellos expertos en la técnica entender más fácilmente y hacer uso de la invención para una variedad de aplicaciones. Solo unos cuantos de los campos que no se analizan todavía, se describirán con mayor detalle en la presente invención. Además, estos campos se presentan con definiciones y valores ejemplares en relación con las modalidades antes mostradas. Sin embargo, esos valores no se considerarán limitaciones de la invención, sino que representan una o más modalidades útiles para ejecutar la interfaz y protocolo, y no todas las modalidades tienen que ser practicadas en conjunto o al mismo tiempo. Se pueden utilizar otros valores en otras modalidades para lograr la presentación de datos deseada o los resultados de transferencia de velocidad de datos deseados, tal como lo podrán apreciar aquellos expertos en la técnica.

A. Para paquetes de corriente de video En una modalidad, el campo de Atributos de Datos de Píxel (2 bytes) tiene una serie de valores de bit que se interpretan de la siguiente forma. Los bits 1 y 0 seleccionan la forma en que los datos de píxel de pantalla son enrutados. Para los valores de bit de li? los datos de píxel se despliegan a o para ambos ojos, para valores de bit ?10X los datos de píxel se enrutan únicamente para el ojo izquierdo, y para los valores de bit 01X los datos de píxel se enrutan solo para el ojo derecho, y para los valores de bit de ?00' los datos de píxel se enrutan para una pantalla alterna, tal como puede ser especificado por los bits 8 a 11 que se analizan a continuación. Si la pantalla primaria en un cliente o que está siendo utilizada u operada por un cliente no soporta imágenes estero o la generación de imágenes en alguna forma, entonces estos comandos no pueden ser implantados de manera efectiva para tener un impacto conforme a lo deseado por la pantalla. En esta situación o configuración, el cliente debería enrutar los datos de píxel a una pantalla primaria sin considerar los valores de bit o para cualquiera de las combinaciones de bit '01, ?10' u XIX debido a que los comandos resultantes o control no serán ejecutados por la pantalla. Se recomienda, pero no lo requieren así las modalidades, que el valor ?ll' sea utilizado para direccionar la pantalla primaria en aquellos clientes que no soportan capacidad de pantalla estéreo. El Bit 2 indica si los Datos de Píxel están o no presentes en un formato entrelazado, en donde un valor de 0' significa que los datos de píxel están en el formato progresivo estándar, y que el número de fila (coordenada de píxel Y) se incrementa por 1 cuando se avanza de una fila a la siguiente. Cuando este bit tiene un valor de ?iX los datos de píxel están en el formato entrelazado, y el número de fila se incrementa por 2 cuando se avanza de una fila a la siguiente. El Bit 3 indica que los Datos de Píxel están en un formato de píxel alterno. Esto es similar al modo entrelazado estándar habilitado por el bit 2, pero el entrelazado es vertical en lugar de horizontal. Cuando el Bit 3 es ?0X los Datos de Píxel están en el formato progresivo estándar, y el número de columna (coordenada de píxel x) se incrementa por 1 conforme se recibe cada píxel sucesivo. Cuando el Bit 3 es X', los Datos de Píxel están en el formato de píxel alterno, y el número de columna se incrementa por 2 conforme se recibe cada píxel. El Bit 4 indica si los datos de píxel están o no relacionados con una pantalla o una cámara, así como el lugar a donde se están transfiriendo los datos hacia o desde una pantalla interna para un teléfono inalámbrico o dispositivo similar o incluso una computadora portátil, o algún otro dispositivo tal como se analizó anteriormente, o los datos están siendo transferidos a o desde una cámara incorporada en, o directamente acoplada al dispositivo. Cuando el Bit 4 es ?0X los datos de Píxel están siendo transferidos a, o desde una memoria intermedia de cuadro de pantalla. Cuando el Bit 4 es i? los datos de Píxel están siendo transferidos a, o desde una cámara o dispositivo de video de cierto tipo, tal como dispositivos muy conocidos en la técnica. El Bit 5 se utiliza para indicar cuando los datos de píxel contienen la siguiente fila consecutiva de píxeles en la pantalla. Esto se considera el caso cuando el Bit 5 se establece igual a ?l' . Cuando el bit 5 se establece a l', entonces los parámetros de Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, Inicio en X, e Inicio en Y no son definidos y son ignorados por el cliente. Cuando el Bit 15 se establece a un nivel de lógica uno, esto indica que los datos de píxel en este paquete son la última fila de píxeles en la imagen. El Bit 8 del campo de Indicadores de Capacidad de Característica del Cliente del Paquete de Capacidad del Cliente indica si esta característica es soportada. Los Bits 7 y 6 son Bits de Actualización de Pantalla que especifican una memoria intermedia de cuadro en donde se van a escribir los datos de píxel. Los efectos más específicos se analizan en otro apartado. Para valores de bit de 0i? los datos de píxel se escriben en la memoria intermedia de imágenes fuera de línea. Para valores de bit de 00?- los datos de píxel se escriben en la memoria intermedia de imágenes que se utiliza para actualizar la pantalla. Para valores de bit de xll' , los datos de píxel se escriben para todas las memorias intermedias de imagen. Los valores de bit o combinación de ?10' se consideran como un valor o designación inválida y los datos de píxel se ignoran y no se escriben en ninguna de las memorias intermedias de imagen. Este valor puede tener uso para futuras aplicaciones de la interfaz. Los bits 8 a 11 forman un entero sin firmar de 4 bits que especifica una pantalla alterna o ubicación de pantalla a donde se van a enrutar los datos de píxel. Los bits 0 y 1 se establecen igual a ?00' para que el cliente de pantalla interprete los bits 8 a 11 como un número de pantalla alterno. Si los bits 0 y 1 no son iguales a ?00', entonces los bits 8 a 11 se establecen a niveles de lógica cero. Los bits 12 a 14 se reservan para futuro uso y generalmente se establecen a niveles de lógica cero. El bit 15, tal como se analizó, se utiliza junto con el bit 5, y el establecimiento del bit 15, a un nivel de lógica uno, indica que la fila de píxeles en el campo de Datos de Píxel es la última fila de píxeles en un cuadro de datos. El siguiente Paquete de Corriente de Video que tiene el bit 5 fijo a un nivel de lógica uno, corresponderá a la primera fila de píxeles del siguiente cuadro de video. Los campos de 2 bytes de Inicio X e Inicio Y especifican las coordenadas absolutas 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 Borde Izquierdo X y Borde Superior Y de 2 bytes especifican la coordenada X del borde izquierdo y la coordenada Y del borde superior de la ventana de pantalla llenada por el campo de Datos de Píxel, 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 que se está actualizando . El campo de Conteo de Píxeles (2 bytes) especifica el número de píxeles en el campo de Datos de Píxel a continuación. El campo CRC de Parámetro (2 bytes) contiene un CRC de todos los bytes desde la Longitud de Paquete al Conteo de Píxeles. Si este CRC no checa, entonces se desecha todo el paquete. El campo de Datos de Píxel contiene la información de video sin procesar que se va a desplegar, y la cual está formateada en la forma descrita por el campo de Descriptor de Formato de Datos de Video. Los datos son transmitidos una "fila" a la vez, tal como se analiza en otro apartado. Cuando el Bit 5 del campo de Atributos de Datos de Píxel se fija a un nivel de lógica uno, entonces el campo de Datos de Píxel contiene exactamente una fila de píxeles, en donde el primer píxel que se transmite corresponde al píxel más a la izquierda y el último píxel transmitido corresponde al píxel más a la derecha. El campo CRC de Datos de Píxel (2 bytes) contiene un CRC de 16 bits únicamente de los Datos de Píxel. Si una verificación de CRC de este valor falla, entonces los Datos de Píxel se pueden seguir utilizando, pero se incrementa el conteo de error de CRC.

B. Para paquetes de corriente de audio En una modalidad, el campo ID de Canal de Audio (1 byte) utiliza un valor de entero sin firmar de 8 bits para identificar un canal de audio particular al cual los datos de audio son enviados por el dispositivo del cliente. Los canales de audio físicos son especificados en, o mapeados para los canales físicos por este campo como valores de 0, 1, 2, 3, 4, 5, 6, ó 7 los cuales indican los canales frontal izquierdo, frontal derecho, posterior izquierdo, posterior derecho, central frontal, bafle de bajos, izquierdo ambiental y derecho ambiental, respectivamente. Un valor de ID de canal de audio de 254 indica que la corriente sencilla de muestras de audio digital es enviada tanto a los canales frontal izquierdo como frontal derecho. Esto simplifica las comunicaciones para aplicaciones tal como en los casos donde se utilizan auriculares estéreo para comunicación de voz, aplicaciones de mejora de productividad se utilizan en un PDA, u otras aplicaciones en donde una Interfaz de Usuario simple genera tonos de advertencia. Los valores para el campo de ID que oscilan de 8 a 253, y 255 actualmente se reservan para uso en los lugares donde nuevos diseños desean designaciones adicionales, tal co o lo anticipan aquellos expertos en la técnica. El campo Reservado 1 (1 byte) generalmente se reserva para futuro uso, y tiene todos los bits en este campo puestos a cero. Una función de este campo es ocasionar que todos los campos posteriores 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 Conteo de Muestra de Audio (2 bytes) especifica el número de muestras de audio en este paquete. El campo de Bits Por Muestra y Empaque contiene 1 byte que especifica el formato de empaque de 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 PCM. El Bit 5 entonces especifica si las muestras de Datos de Audio Digital están o no empacadas. Como se mencionó anteriormente, la figura 12 ilustra la diferencia entre las muestras de audio de bytes alineados y empacadas. Un valor de 0 ' para el Bit 5 indica que cada muestra de audio PCM en el campo de Datos de Audio Digital está alineada en bytes con el límite de byte de interfaz, y un valor de ?l' indica que cada muestra de audio PCM sucesiva está empacada contra la muestra de audio previa. Este bit es efectivo solo cuando el valor definido en los bits 4 a 0 (el número de bits por muestra de audio PCM) no es un múltiplo de ocho. Los bits 7 a 6 se reservan para uso en las situaciones donde los diseños del sistema desean designaciones adicionales y generalmente se establecen a un valor de cero. El campo de Velocidad de Muestra de Audio (1 byte) especifica la velocidad de muestra PCM de audio. El formato empleado es para que un valor de 0 indique una velocidad de 8,000 muestras por segundo (sps), un valor de 1 indique 16,000 sps., un valor de 2 para 24,000 sps., un valor de 3 para 32,000 sps., un valor de 4 para 40,000 sps., un valor de 5 para 48,000 sps., un valor de 6 para 11,025 sps., un valor de 7 para 22,050 sps., y un valor de 8 para 44,100 sps., respectivamente, en donde los valores 9 a 254 se reservan para futuro uso, de manera que actualmente están en cero. El campo de CRC de Parámetro (2 bytes) contiene un CRC de 16 bits de todos los bytes desde la Longitud de Paquete hasta la Velocidad de Muestra de Audio. Si este CRC no checa de manera apropiada, entonces se desecha todo el paquete. El campo de Datos de Audio Digital contiene las muestras de audio sin procesar que se van a reproducir, y por lo general se encuentra en la forma de un formato lineal como enteros sin firmar. El campo CRC de Datos de Audio (2 bytes) contiene un CRC de 16 bits únicamente de Datos de Audio. Si este CRC no checa, entonces se pueden seguir utilizando los Datos de Audio, pero se incrementa el conteo de error CRC.

C. Para paquetes de corriente definidos por el usuario En una modalidad, el campo de Número de ID de Corriente de 2 bytes se utiliza para identificar una corriente definida por el usuario particular. El contenido de los campos Parámetros de Corriente y Datos de Corriente típicamente queda definido por el fabricante del equipo de MDDI. El campo CRC de Parámetro de Corriente de 2 bytes contiene un CRC de 16 bits de todos los bytes de los parámetros de corriente comenzando desde la Longitud de Paquete al byte de Codificación de Audio. Si este CRC no checa, entonces se desecha todo el paquete. Ambos campos de Parámetros de Corriente y CRC de Parámetro de Corriente se pueden descartar si no son requeridos por una aplicación final de la MDDI, es decir, se consideran opcionales. El campo CRC de Datos de Corriente de 2 bytes contiene un CRC únicamente de los Datos de Corriente. Si este CRC no checa de manera apropiada, entonces el uso de los Datos de Corriente es opcional, dependiendo de los requerimientos de la aplicación. El uso de los datos de corriente depende de que CRC esté bien, generalmente requiere que los datos de corriente sean almacenados en memoria intermedia hasta que el CRC se confirma como adecuado. El conteo de error de CRC se incrementa si el CRC no checa.

D. Para paquetes de mapa de color El campo ID de hCliente de 2 bytes contiene información o valores que se reservan para una ID de Cliente, tal como se utilizó previamente. Debido a que este campo generalmente se reserva para futuro uso, el valor actual se establece a cero, fijando los bits a x0' . El campo de Conteo de Artículo de Mapa de Color de 2 bytes utiliza valores para especificar el número total de artículos de mapa de color de 3 bytes que están contenidos en el campo de Datos de Mapa de Color, o las entradas del cuadro de mapa de color que existen en los Datos de Mapa de Color en este paquete. En esta modalidad, el número de bytes en los Datos de Mapa de Color es 3 veces el Conteo de Artículo de Mapa de Color. El Conteo de Artículo de Mapa de Color se establece igual a cero para no enviar datos de mapa de color alguno. Si el Tamaño de Mapa de Color es cero, entonces un valor de Compensación de mapa de color generalmente sigue siendo enviado pero es ignorado por la pantalla. El campo de Compensación de Mapa de Color (4 bytes) especifica la compensación de los Datos de Mapa de Color en este paquete desde el inicio del cuadro de mapa de color en el dispositivo del cliente. Un campo CRC de Parámetro de 2 bytes contiene un CRC de todos los bytes desde la Longitud de Paquete al byte de Codificación de Audio. Si este CRC no checa, entonces todo el paquete se desecha. Para el campo de Datos de Mapa de Color, el ancho de cada ubicación de mapa de color es especificado por el campo de Tamaño de Artículo de Mapa de Color, en donde en una modalidad, la primer parte especifica la magnitud de azul, la segunda parte especifica la magnitud de verde, y la tercer parte especifica la magnitud de rojo. El campo de Tamaño de Mapa de Color especifica el número de artículos de cuadro de mapa de color de 3 bytes que existen en el campo de Datos de Mapa de Color. Si un solo mapa de color no se puede ajustar en un Formato de Datos de Video y Paquete de Mapa de Color, entonces todo el mapa de color se puede especificar enviando múltiples paquetes con diferentes Datos de Mapa de Color y Compensaciones de Mapa de Color en cada paquete. El número de bits de azul, verde y rojo en cada artículo de datos de mapa de color generalmente es el mismo conforme a lo especificado en el campo de Ancho RGB de Mapa de Color del Paquete de Capacidad de Pantalla. Un campo CRC de Datos de Mapa de Color de 2 bytes contiene un CRC únicamente de Datos de Mapa de Color. Si este CRC no checa, entonces los Datos de Mapa de Color se pueden seguir utilizando pero se incrementa el conteo de error de CRC. Cada artículo de datos de mapa de color se va a transmitir en el orden: azul, verde, rojo, en donde primero se transmite el bit menos significativo de cada componente. Los componentes rojo, verde y azul individuales de cada artículo de mapa de color están empacados, pero cada artículo de mapa de color (el bit menos significativo del componente azul) debería estar alineado en bytes. La figura 97 ilustra un ejemplo de artículos de datos de mapa de color con 6 bits de azul, 8 bits de verde, y 7 bits de rojo. Para este ejemplo, el Tamaño de Artículo de Mapa de Color en el Paquete de Mapa de Color es igual a 21, y el campo de Ancho RGB de Mapa de Color del Paquete de Capacidad del Cliente es igual a 0x0786.

E. Para paquetes de encapsulación de enlace inverso El campo CRC de parámetro (2 bytes) contiene un CRC de 16 bits de todos los bytes desde la Longitud de Paquete a la Longitud de Giro. Si este CRC no checa, entonces se desecha todo el paquete. En una modalidad, el campo de Indicadores de Enlace Inverso (1 byte) contiene un conjunto de indicadores para solicitar información del cliente y especificar un tipo de enlace inverso. Si un bit (por ejemplo, Bit 0) se configura a un nivel de lógica uno, entonces el huésped solicita la información especificada del cliente, pero si el bit se configura a un nivel de lógica cero, entonces el huésped no necesita la- información del cliente. El Bit 0 se utiliza para indicar cuándo el huésped desea el Paquete de Capacidad del Cliente, el cual generalmente es enviado por el cliente al huésped en el campo de Paquetes de Datos Inversos. El Bit 1 se utiliza para indicar cuándo el huésped desea el Paquete de Estado y Solicitud del Cliente el cual es enviado por el cliente al huésped en el campo de Paquetes de Datos Inversos. Los bits restantes (aquí Bits 2 a 7) se reservan para futuro uso y se establecen en cero. Sin embargo, se pueden utilizar más bits según se desee para establecer los indicadores para el enlace inverso. El campo Divisor de Velocidad Inversa (1 byte) especifica el número de ciclos de MDDI_Stb que ocurren en relación con la sincronía de datos de enlace inverso. La sincronía de datos de enlace inverso es igual a la sincronía de datos de enlace de avance dividida entre dos veces el Divisor de Velocidad Inversa. La velocidad de datos de enlace inverso se relaciona con la sincronía de datos de enlace inverso y el Tipo de Interfaz en el enlace inverso. En esta modalidad, para una interfaz Tipo 1, la velocidad de datos inversos iguala la sincronía de datos de enlace inverso, para las interfaces Tipo 2, Tipo 3 y Tipo 4 las velocidades de datos inversos iguala dos veces, cuatro veces y ocho veces la sincronía de datos de enlace inverso, respectivamente . El campo Todos Ceros 1 contiene un grupo de bytes, aquí 8, que se establece igual a cero en valor, estableciendo los bits a un nivel de lógica cero, y se utiliza para asegurar que todas las señales de MDDI_Datos estén a un nivel de lógica cero durante un tiempo suficiente para permitir que el cliente comience a recuperar la sincronía utilizando simplemente MDDI_Stb antes de deshabilitar los accionadores de línea del huésped durante el campo de Giro 1. En una modalidad, la longitud del campo Todos Ceros 1 es mayor que o igual al número de veces de transmisión de byte de enlace de avance en el retraso de viaje redondo del cable. El campo Longitud de Giro 1 (1 byte) especifica el número total de bytes que se asignan para Giro 1, estableciendo el primer periodo de giro. El campo de Giro 1 que emplea el número de bytes especificados por el parámetro de Longitud de Giro 1, se asigna para permitir la habilitación de los accionadores de línea MDDI_Datos en el cliente, antes que sean inhabilitados los accionadores de línea en el huésped. El cliente habilita sus accionadores de línea de MDDI_Datos durante el bit 0 de Giro 1 y el huésped inhabilita su salida para quedar completamente inhabilitado antes del último bit de Giro 1. La señal MDDI_Stb se comporta como si MDDI_DatosO estuviera a un nivel de lógica cero durante todo el periodo de Giro 1. Una descripción más completa de la configuración de Giro 1 se menciona en un apartado anterior. El campo de Paquetes de Datos Inversos contiene una serie de paquetes de datos transferidos desde el cliente al huésped. El cliente puede enviar paquetes de relleno o accionar las líneas de MDDI_Datos a un estado o nivel de lógica cero cuando no tiene datos para enviar al huésped. En esta modalidad, si las líneas de MDDI_Datos son llevadas a cero, el huésped interpretará esto como un paquete con una longitud cero (no una longitud válida) y el huésped no aceptará paquetes adicionales provenientes del cliente durante el periodo del Paquete de Encapsulación de Enlace Inverso actual. El campo de Longitud Giro 2 (1 byte) especifica el número total de bytes que se asignan para Giro 2, a fin de establecer un segundo periodo de giro. La longitud recomendada de Giro 2 es el número de bytes que se requiere para el retraso de viaje redondo más el tiempo que se requiere para que el huésped habilite sus accionadores de MDDI_Datos . La Longitud de Giro 2 también puede ser un valor más grande que el valor mínimo requerido o calculado para permitir suficiente tiempo a fin de procesar paquetes de enlace inverso en el huésped. El campo de Giro 2 consta del número de bytes conforme a lo especificado por el parámetro de Longitud de Giro. El huésped espera por lo menos el tiempo de retraso de viaje redondo antes de habilitar sus accionadores de línea de MDDI Datos durante el Giro 2. El huésped habilita sus accionadores de línea MDDI_Datos de manera que, por lo regular, quedan completamente habilitados antes del último bit del Giro 2, y el cliente inhabilita sus salidas de manera que por lo regular quedan completamente inhabilitadas antes del último bit de Giro 2. El propósito del campo de Giro 2 es permitir que la cantidad restante de datos proveniente del campo de Paquetes de Datos Inversos sea transmitida o transferida desde el cliente. Con las variaciones en diferentes sistemas que ejecutan la interfaz y la cantidad de margen de seguridad asignada, es posible que ni el huésped ni el cliente accionen las señales MDDI_Datos a un nivel de lógica cero durante algunas partes del periodo de campo Giro 2, tal como lo pueden apreciar los receptores de línea en el huésped. La señal MDDI_Stb se comporta como si MDDI_DatosO estuviera a un nivel de lógica cero durante sustancialmente todo el periodo de Giro 2. Anteriormente se proporcionó una descripción de la configuración de Giro 2. El campo de Paquetes de Datos Inversos contiene una serie de paquetes de datos que están siendo transferidos desde el cliente a un huésped. Tal como se mencionó anteriormente, los paquetes de relleno son enviados para llenar el espacio restante que no está siendo utilizado por otros tipos de paquete. El campo Todos Ceros 2 contiene un grupo de bytes (8 en esta modalidad) que se establece igual a cero en valor fijando los bits a un nivel de lógica cero, y se utiliza para asegurar que todas las señales MDDI_Datos estén a un nivel de lógica cero durante un tiempo suficiente para permitir al cliente comenzar a recuperar la sincronía utilizando tanto MDDIJDatosO como MDDI_Stb después de habilitar los accionadores de línea del huésped siguiendo el campo de Giro 2.

F. Para paquetes de capacidad de cliente Como se ilustró en 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 actualmente se fija igual a uno, y se cambiará con el paso del tiempo conforme se generen nuevas versiones tal como se conoce, mientras que el campo Versión de Protocolo Mínima utiliza 2 bytes para especificar la versión de protocolo mínima que el cliente puede emplear o interpretar. En este caso, un valor cero también es un valor válido. El campo de Capacidad de Velocidad de Datos (2 bytes) especifica la velocidad de datos máxima que el cliente puede recibir en cada par de datos en el enlace de avance de la interfaz, y se especifica en la forma de megabits por segundo (Mbps) . El campo de Capacidad de Tipo de Interfaz (1 byte) especifica los tipos de interfaz que son soportados en los enlaces de avance e inverso. Un bit establecido a ?l' indica que se soporta un tipo de interfaz especificado, y un bit establecido a ?0' indica que el tipo especificado no es soportado. Los huéspedes y clientes deberían soportar por lo menos el Tipo 1 en los enlaces de avance e inverso. No existe requerimiento alguno para soportar un rango contiguo de tipos de interfaz. Por ejemplo, sería perfectamente válido soportar solo el Tipo 1 y el Tipo 3, pero no el Tipo 3 y el Tipo 4 en una interfaz. Tampoco es necesario que los enlaces de avance e inverso operen con el mismo tipo de interfaz. Sin embargo, cuando un enlace sale del estado de hibernación, ambos enlaces, de avance e inverso, deberían comenzar a operar en un modo Tipo 1, hasta que se puedan negociar, seleccionar o, de otra forma, aprobar otros modos para uso por parte del huésped y del cliente. Las interfaces soportadas se indican en una modalidad seleccionando el Bit 0, Bit 1 ó Bit 2 para seleccionar ya sea un modo Tipo 2 (2 bits) , Tipo 3 (4 bits) o Tipo 4 (8 bits) en el enlace de avance, respectivamente; y el Bit 3, Bit 4 ó Bit 5 para seleccionar ya sea un modo Tipo 2, Tipo 3 ó Tipo 4 en el enlace inverso, respectivamente; en donde los Bits 6 y 7 están reservados y generalmente configurados en cero en este momento. Los campos de Altura y Ancho de Mapa de Bits, aquí cada uno es de 2 bytes, especifican el ancho y la altura del mapa de bits, respectivamente, en píxeles. El campo de Capacidad Monocromo (1 byte) se utiliza en una modalidad para especificar el número de bits de resolución que se pueden desplegar en un formato monocromo. Si una pantalla no puede utilizar un formato monocromo, entonces este valor se establece en cero. Los Bits 7 a 4 se reservan para futuro uso y son, por lo tanto, configurados como 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 píxel. Si el valor es cero, entonces el formato monocromo no es soportado por la pantalla. El campo de Capacidad Bayer utiliza 1 byte para especificar el número de bits de resolución, el grupo de píxeles, y el orden de píxeles que se pueden transferir en formato Bayer. Si un cliente no puede utilizar el formato Bayer, entonces este valor es cero. El campo de Capacidad Bayer está compuesto de los siguientes valores: los Bits 3 a 0 definen el número máximo de bits de intensidad que existe en cada píxel, mientras que los Bits 5 a 4 definen el patrón de grupo de píxeles que se requiere, mientras que los Bits 8 a 6 definen el orden de píxeles que se requiere; en donde los Bits 14 a 9 se reservan para futuro uso y generalmente se establecen en cero mientras tanto. El Bit 15, cuando se establece a un nivel de lógica uno indica que el cliente puede aceptar los datos de píxel Bayer en cualquier formato empacado o desempacado. Si el bit 15 se establece a cero, esto indica que el cliente puede aceptar los datos de píxel Bayer solo en formato desempacado. El campo de Capacidad de Mapa de Color (3 bytes) en una modalidad especifica el número máximo de artículos de cuadro que existen en el cuadro de mapa de color en la pantalla. Si la pantalla no puede utilizar el formato de mapa de color, entonces este valor se configura en cero. El campo de Capacidad RGB (2 bytes) especifica el número de bits de resolución que se puede desplegar en formato RGB. Si la pantalla no puede utilizar el formato RGB, entonces este valor es igual a cero. La palabra Capacidad RGB está compuesta de tres valores no firmados separados en 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 reservan para futuro uso y generalmente se establecen en cero. Los Bits 14 a 12 se reservan para futuro uso y generalmente se establecen en cero. El Bit 15, cuando se establece a un nivel de lógica uno, indica que el cliente puede aceptar datos de píxel RGB en el formato empacado o desempacado. Si el bit 15 se configura a un nivel de lógica cero, esto indica que el cliente puede aceptar datos de píxel RGB solo en formato desempacado. El campo de Capacidad Y Cr Cb (2 bytes) especifica el número de bits de resolución que se pueden desplegar en formato Y Cr Cb. Si la pantalla no puede utilizar el formato Y Cr Cb, entonces este valor se configura igual a cero. La palabra Capacidad Y Cr Cb está compuesta de tres valores sin firmar separados en donde: los Bits 3 a 0 definen el número máximo de bits en la muestra Cb, los Bits 7 a 4 definen el número máximo de bits en la muestra Cr, los Bits 11 a 8 definen el número máximo de bits en la muestra Y, y los Bits 15 a 12 actualmente están reservados para futuro uso y se establecen en cero. En una modalidad, el campo de Capacidad de Característica del Cliente utiliza 4 bytes en una modalidad que contiene un conjunto de indicadores que indica características específicas en el cliente que son soportadas. Un bit configurado a un nivel de lógica uno indica que la capacidad es soportada, mientras que un bit configurado a un nivel de lógica cero indica que la capacidad no es soportada. En una modalidad, el valor para el Bit 0 indica si un Paquete de Transferencia de Bloque de Mapa de Bits (tipo de paquete 71) es soportado o no . El valor para los Bits 1, 2 y 3 indica si un Paquete de Relleno de Área de Mapa de Bits (tipo de paquete 72), un Paquete de Relleno de Patrón de Mapa de Bits (tipo de paquete 73) o un Paquete de Memoria Intermedia de Cuadro de Lectura (tipo de paquete 74), respectivamente, son soportados o no. El valor para el Bit 4 indica si el cliente tiene o no la capacidad para hacer un color transparente utilizando el Paquete de Habilitación de Color Transparente, mientras que los valores para los Bits 5 y 6 indican si el cliente puede aceptar datos de audio en formato empacado o desempacado, respectivamente, y el valor para el Bit 7 indica si el cliente puede o no enviar una corriente de video de enlace inverso desde una cámara. El valor para el Bit 8 indica si el cliente tiene o no la habilidad para recibir una línea completa de datos de píxel e ignorar el direccíonamiento de pantalla, tal como lo especifica el bit 5 del campo de Atributos de Datos de Píxel del Paquete de Corriente de Video, y el cliente también puede detectar sincronización de cuadro o fin de datos de cuadro de video utilizando el bit 15 del campo de Atributos de Datos de Pí el. El valor del Bit 9 indica si el cliente tiene o no la habilidad para interpretar el Paquete de Estado Específico de Solicitud y responder con el Paquete de Lista de Respuesta de Estado Válido. El cliente puede indicar una habilidad para devolver un estado adicional en el campo de Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido, tal como se describió anteriormente. El valor de Bit 10 indica si el cliente tiene o no la habilidad para soportar estado de energía de pantalla 01. El estado de energía de pantalla se establece utilizando los bits [3:2] del campo de Estado de Energía del Paquete de Estado de Energía de Pantalla descrito anteriormente. El estado de energía de pantalla 01 es un estado en donde la pantalla seleccionada no se ilumina y está consumiendo una cantidad mínima de energía, en caso de hacerlo, y el contenido de la memoria intermedia de cuadro generalmente queda garantizado para que sea retenido durante este estado. El valor para los Bits 11 y 12 indica cuando el cliente se está comunicando ya sea con un dispositivo de señalamiento y puede enviar y recibir Paquetes de Datos de Dispositivo de Señalamiento, 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 habilidad para establecer uno o más parámetros de audio o video soportando los paquetes de Característica VCP: Paquete de Característica VCP de Solicitud, Paquete de Respuesta de Característica VCP, Paquete de Característica VCP Establecida, Paquete de Parámetro Válido de Solicitud, y Paquete de Respuesta de Parámetro Válido. El valor para el Bit 14 indica si el cliente tiene o no la habilidad para escribir datos de píxel en la memoria intermedia de cuadro de pantalla fuera de línea, lo cual se ilustra en la figura 88A. Si este bit se configura a un nivel de lógica 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 Corriente de Video) se pueden establecer a los valores ?01' . El valor para el Bit 15 indica cuando el cliente tiene la habilidad para escribir datos de píxel únicamente en la memoria intermedia de cuadro de pantalla que en ese momento se está utilizando para actualizar la imagen de pantalla, lo cual se ilustra en la figura 88B. Si este bit se configura a un nivel de lógica 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 Corriente de Video) se pueden configurar a los valores 00' . El valor para el Bit 16 indica cuando el cliente tiene la habilidad para escribir datos de píxel desde un solo paquete de Corriente de Video en todas las memorias intermedias de cuadro de pantalla, lo cual se ilustra en la figura 88C. Si este bit se configura igual a un nivel de lógica 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 Corriente de Video) se pueden establecer al valor ll' .

En una modalidad, el valor para el Bit 17 indica cuando un cliente tiene la habilidad para responder al Paquete de Estado Específico de Solicitud, el valor para el Bit 18 indica cuando el cliente tiene la habilidad para responder al Paquete de Medición de Retraso de Viaje Redondo, y el valor para el Bit 19 indica cuando el cliente tiene la habilidad para responder al Paquete de Calibración de Sesgo de Enlace de Avance. En una modalidad, el valor para el Bit 20 indica cuando el cliente tiene la habilidad para responder al Paquete de estado de Energía de Pantalla. En una modalidad, el valor para el Bit 21 indica cuando el cliente tiene la habilidad para utilizar el campo de Operación de Trama del Paquete de Transferencia de Bloque (tipo de paquete 71) , el Paquete de Relleno de Área de Mapa de Bits (tipo de paquete 72), y el Paquete de Relleno de Patrón de Mapa de Bits (tipo de paquete 73) , en caso que esos paquetes sean soportados por el cliente tal como lo especifican los bits 0, 1 y 2 o este campo. En una modalidad, si el bit 21 tiene un nivel o valor de lógica cero, y los paquetes son soportados, entonces el cliente no tiene la habilidad para utilizar el campo de Operación de Trama y el cliente solo tiene la habilidad para copiar o escribir a las ubicaciones de píxel especificadas por estos paquetes . El valor para el Bit 22 indica si el cliente tiene o no la habilidad para responder al Paquete de Acceso de Registro. Los Bits 23 a 31 actualmente se están reservando para futuro uso o designaciones alternativas útiles para diseñadores de sistemas, y generalmente se configuran igual a un valor cero o un nivel de lógica cero. El campo de Capacidad de Velocidad de Cuadro de Video de Pantalla, en esta modalidad utiliza byte, especifica la máxima capacidad de actualización de cuadro de video de la pantalla en cuadros por segundo. Un huésped puede elegir actualizar la imagen a una velocidad más lenta que el valor especificado en este campo. El campo de Profundidad de Memoria Intermedia de Audio (2 bytes) especifica la profundidad de la memoria intermedia elástica en una Pantalla la cual está dedicada a cada corriente de audio. El campo de Capacidad de Canal de Audio, en esta modalidad utiliza 2 bytes, contiene un grupo de indicadores que indican cuáles canales de audio son soportados por el cliente o dispositivo conectado al cliente. Un bit establecido en uno indica que el canal es soportado, y un bit establecido en cero indica que el canal no es soportado. Las posiciones de Bit que se asignan a los 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, bafle de bajos, izquierdo ambiental y derecho ambiental, respectivamente. Los bits 8 a 14 actualmente se están reservando para futuro uso, y por lo general se configuran en cero. En una modalidad, el Bit 15 se utiliza para indicar si el cliente provee soporte para el Paquete de Habilitación de Canal de Audio de Avance. Si este es el caso, el Bit 15 se configura a un nivel de lógica uno. Sin embargo, si el cliente no tiene la capacidad para inhabilitar los canales de audio como resultado del Paquete de Habilitación del Canal de Audio de Avance o si el cliente no soporta capacidad de audio alguna, entonces este bit se configura a un nivel o valor de lógica cero. Un campo de Capacidad de Velocidad de Muestra de Audio de 2 bytes, para el enlace de avance, contiene un conjunto de indicadores para indicar la capacidad de velocidad de muestra de audio del dispositivo del cliente. Las posiciones de bit se asignan a las diferentes velocidades, por consiguiente, tal como los Bits 0, 1, 2, 3, 4, 5, 6, 7, y 8 se asignan 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, en donde los Bits 9 a 15 se reservan para usos futuros o alternativos de velocidad, según se desee, de manera que actualmente están configurados a ?0' . La configuración de un valor de bit para uno de estos bits a l' indica que esa velocidad de muestra particular es soportada, y la configuración del bit a ?0' indica que esa velocidad de muestra no es soportada. El campo de Velocidad de Sub-cuadro Mínima (2 bytes) especifica la velocidad de sub-cuadro mínima en cuadros por segundo. La velocidad de sub-cuadro mínima mantiene la suficiente velocidad de actualización de estado del cliente para leer algunos sensores o dispositivos de señalamiento en el cliente. Un campo de Capacidad de Velocidad de Muestra Mic de 2 bytes, para el enlace inverso, contiene un conjunto de indicadores que indican la capacidad de velocidad de muestra de audio de un micrófono en el dispositivo del cliente. Para propósitos de la MDDI, un micrófono del dispositivo del cliente está configurado para soportar, de manera mínima, por lo menos una velocidad de 8,000 muestras por segundo. Las posiciones del bit para este campo se asignan a las diferentes velocidades con las posiciones de bit 0, 1, 2, 3, 4, 5, 6, 7 y 8, por ejemplo, utilizadas 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, en donde los Bits 9 a 15 se reservan para usos futuros o alternativos de velocidad, según se desee, de manera que actualmente están configurados a 0' . La configuración de un valor de bit para uno de estos bits a l' indica que esa velocidad de muestra particular es soportada, y la configuración del bit a ?0' indica que esa velocidad de muestra no es soportada. Si no hay un micrófono conectado, entonces cada uno de los bits de Capacidad de Velocidad de Muestra Mic se configura igual a cero. El campo de Formato de Datos de Teclado (aquí 1 byte) especifica si un teclado está o no conectado al sistema del cliente y el tipo de teclado que está conectado. En una modalidad, el valor establecido por los Bits 6 a 0 se utiliza para definir el tipo de teclado que está conectado. Si el valor es cero (0), entonces el tipo de teclado se considera como desconocido. Para un valor de 1, el formato de datos de teclado se considera como un estilo PS-2 estándar. Los valores actuales en el rango de 2 a 125 no están en uso, se reservan para uso de los diseñadores del sistema e integradores de interfaces o desarrolladores de productos para definir el teclado específico o dispositivos de entrada para uso con la MDDI y clientes o huéspedes correspondientes. Un valor de 126 se utiliza para indicar que el formato de datos de teclado queda definido por el usuario, mientras que un valor de 127 se utiliza para indicar que un teclado no puede ser conectado a este cliente. Además, el Bit 7 se puede utilizar para indicar si el teclado se puede comunicar o no con el cliente. El uso pretendido de este bit es indicar cuándo el teclado puede entablar comunicación con el cliente utilizando un enlace inalámbrico. El Bit 7 se configuraría a un nivel cero si los bits 6 a 0 indican que un teclado no puede ser conectado al cliente. Por lo tanto, para una modalidad, cuando el valor del Bit 7 es 0, el teclado y el cliente no pueden entablar comunicación, mientras que si el valor del Bit 7 es 1, el teclado y el cliente tienen conocimiento de que pueden entablar comunicación entre ellos. El campo de Formato de Datos del Dispositivo de Señalamiento (aquí 1 byte) especifica si un dispositivo de señalamiento está o no conectado al sistema del cliente y el tipo de dispositivo de señalamiento que está conectado. En una modalidad, el valor establecido por los Bits 6 a 0 se utiliza para definir el tipo de dispositivo de señalamiento que está conectado. Si el valor es cero (0), entonces el tipo de dispositivo de señalamiento se considera como desconocido. Para un valor de 1, el formato de datos del dispositivo de señalamiento se considera un estilo PS-2 estándar. Los valores actualmente en el rango de 2 a 125 no están en uso, se reservan para uso de los diseñadores del sistema e integradores de interfaces o desarrolladores de productos para definir el dispositivo de señalamiento o dispositivos de entrada específicos para uso con la MDDI y clientes o huéspedes correspondientes, ün valor de 126 se utiliza para indicar que el formato de datos del dispositivo de señalamiento queda definido por el usuario, mientras que un valor de 127 se utiliza para indicar que un dispositivo de señalamiento no puede ser conectado a este cliente. Además, el Bit 7 se puede utilizar para indicar si el dispositivo de señalamiento se puede comunicar o no con el cliente. El uso pretendido de este bit es indicar cuándo el teclado puede entablar comunicación con el cliente utilizando un enlace inalámbrico. El Bit 7 se configuraría a un nivel cero si los bits 6 a 0 indican que un dispositivo de señalamiento no puede ser conectado al cliente. Por lo tanto, para una modalidad, cuando el valor del Bit 7 es 0, el dispositivo de señalamiento y el cliente no pueden entablar comunicación, mientras que si el valor del Bit 7 es 1, el dispositivo de señalamiento y el cliente han reconocido que pueden entablar comunicación entre ellos . El campo de Tipo de Protección de Contenido (2 bytes) contiene un conjunto de indicadores que indican el tipo de protección de contenido digital que es soportado por la Pantalla. Actualmente, la posición de bit 0 se utiliza para indicar cuando DTCP es soportado y la posición de bit 1 se utiliza para indicar cuando HDCP es soportado, en donde las posiciones de los bits 2 a 15 se reservan para uso con otros esquemas de protección según se desee, o estén disponibles, de manera que actualmente están configurados en cero. El campo de Nombre Mfr (aquí 2 bytes) contiene la ID de 3 caracteres EISA del fabricante, empacada en tres caracteres de 5 bits en la misma forma que en la especificación VESA EDID. El carácter ' es representado como 00001 binario, el carácter ?Z' es representado como 11010 binario, y todas las letras entre ?A' y Z' son representadas como valores binarios en secuencia que corresponden a la secuencia alfabética entre ?A' y Z' . El bit más significativo del campo de Nombre Mfr no se utiliza y, generalmente, se configura a un valor de lógica cero por el momento hasta que se hace uso en futuras ejecuciones. Por ejemplo, un fabricante, representado por la secuencia "XYZ" tendría un valor de Nombre Mfr de 0x633a. Si este campo no es soportado por el cliente, generalmente éste se configura 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, éste generalmente se configura en cero. Los campos Reservado 1, Reservado 2 y Reservado 3 (aquí 2 bytes cada uno) se reservan para futuro uso a fin de transmitir información. Todos los bits en estos campos generalmente se configuran para que estén a un nivel de lógica cero. El propósito de dichos campos es, en ese momento, provocar que todos los campos posteriores de 2 bytes se alineen con una dirección de palabra de 16 bits y provocar que los campos de 4 bytes se alineen con 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, éste generalmente se configura en cero. El campo de Semana de Fabricación utiliza 1 byte para definir la semana de fabricación de la pantalla. Este valor típicamente se ubica en el rango de 1 a 53 en caso de ser soportado por el cliente. Si este campo no es soportado por el cliente, éste se configura en cero. El campo de Año de Fabricación es 1 byte que define el año de fabricación de la pantalla. Este valor es una compensación del año 1990. Los años en el rango de 1991 a 2245 pueden ser expresados por este campo. Ejemplo: el año 2003 corresponde al valor de Año de Fabricación de 13. Si este campo no es soportado por el cliente, éste se configura en cero. El campo CRC (aquí 2 bytes) contiene un CRC de 16 bits de todos los bytes en el paquete, incluyendo la Longitud de Paquete.

G. Para paquetes de estado y solicitud del cliente El campo de Solicitud de Enlace Inverso (3 bytes) especifica el número de bytes que el cliente necesita en el enlace inverso en el siguiente sub-cuadro para enviar información al huésped. El campo Conteo de Error de CRC (1 byte) indica cuántos errores CRC han ocurrido desde el inicio del cuadro de medios. El conteo de CRC se restablece cuando se envía un paquete de encabezado de sub-cuadro con un Conteo de Sub-Cuadro de cero. Si el número real de errores de CRC excede 255, entonces este valor generalmente se satura en 255. El campo de Cambio de Capacidad utiliza 1 byte para indicar un cambio en la capacidad del cliente. Esto podría ocurrir si un usuario se conecta a 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 del Cliente. Sin embargo, cuando los Bits [7:0] son iguales a l a 255, la capacidad ha cambiado. Se examina el Paquete de Capacidad del Cliente para determinar las nuevas características de pantalla. El campo de Indicadores Ocupados del Cliente utiliza 2 bytes para indicar que el cliente está realizando una función específica y no está listo para aceptar todavía otro paquete relacionado con esa función. Un bit establecido a un nivel o valor de lógica uno indica que la función particular está siendo actualmente ejecutada por el cliente y que la función relacionada en el cliente está ocupada. Si la función relacionada en el cliente está lista, el bit se configura a un nivel de lógica cero. El cliente debería retornar un estado de ocupado (bit establecido a uno) para todas las funciones que no son soportadas en el cliente. En una modalidad, estos bytes se interpretan de acuerdo con las siguientes relaciones. Si el Bit 0 es ?l' , entonces la función de transferencia del bloque de mapa de bits está ocupada, mientras que si el Bit 1 es un l' , entonces una función de relleno de área de mapa de bits está ocupada, y si el Bit 2 es un X' , entonces una función de relleno de patrón de mapa de bits está ocupada. Al mismo tiempo, si el Bit 3 es un l' , entonces el sub-sistema de gráficos está ocupado realizando una operación que requiere el uso de la memoria intermedia de cuadro en el cliente. Otras funciones gráficas que requieren el uso de la memoria intermedia de cuadro no pueden comenzar hasta que este bit está establecido a un nivel de lógica uno. Actualmente, los Bits 4 a 15 permanecen reservados para futuro uso y generalmente se configuran a un nivel o estado de lógica uno para indicar un estado ocupado en caso que estos bits sean asignados en el futuro.

H. Para paquetes de transferencia de bloque de bits Los campos de Valor X y Valor Y de Coordenada Izquierda Superior de Ventana utiliza 2 bytes, cada uno para especificar el valor X y Y de las coordenadas de la esquina izquierda superior de la ventana que se va a mover. Los campos de Ancho y Altura de Ventana utilizan 2 bytes, cada uno para especificar el ancho y altura de la ventana que se va a mover. Los campos de Movimiento X y Movimiento Y de la Ventana utilizan 2 bytes, cada uno para especificar el número de píxeles que la ventana se va a mover de forma horizontal y vertical, respectivamente. Por lo regular, estas coordenadas están configuradas de manera que valores positivos para X ocasionan que la ventana sea movida a la derecha, y valores negativos provocan un movimiento hacia la izquierda, mientras que los valores positivos para Y ocasionan que la ventana sea movida hacia abajo, y valores negativos ocasionan un movimiento ascendente.

I. Para paquetes de relleno de área de mapa de bits En una modalidad, el campo de Atributos de Datos de Píxel de 2 bytes tiene valores que especifican el lugar donde los datos de píxel van a ser actualizados, con los Bits 1 y 0 seleccionando la pantalla en donde se van a actualizar los datos de píxel. Si una pantalla primaria en el cliente no soporta imágenes estéreo, entonces el cliente puede afectar los datos de píxel en la pantalla primaria para una de las combinaciones de bits 01, 10 u 11. Se recomienda que se utilice el valor 11 para dirigir la pantalla primaria en clientes que no soportan capacidad de pantalla estéreo. Cuando los Bits [1:0] tienen los valores 11 (doble lógica uno) , los datos de píxel son actualizados en la memoria intermedia de cuadro tanto del ojo izquierdo como del derecho, si los Bits [1:0] tienen los valores 10 (lógica uno, lógica cero) , los datos de píxel son actualizados en la memoria intermedia de cuadro del ojo izquierdo únicamente. Cuando los Bits [1:0] tienen los valores 01 (lógica cero, lógica uno) , los datos de píxel son actualizados en la memoria intermedia de cuadro del ojo derecho únicamente. Cuando los Bits [1:0] tienen los valores 00 (doble lógica cero) , los datos de píxel son actualizados en la memoria intermedia de la pantalla alterna especificada por los bits 8 a 11 a continuación. En una modalidad, el Bit 2 del campo de Atributos de Datos de Píxel especifica si la memoria intermedia para el ojo izquierdo u ojo derecho es o no una fuente de la imagen para esta operación. El Bit 2 solo aplica cuando los bits [1:0] no son iguales a 00, lo cual generalmente se implementa para indicar que no soporta datos fuente provenientes de la memoria intermedia de imágenes principal cuando el destino de la imagen es una de las pantallas alternas. El Bit 2 se utiliza para diferenciar o especificar entre las memorias intermedias de cuadro del ojo izquierdo y derecho como una fuente de datos. Cuando el Bit 2 es igual a 0 (nivel de lógica cero) , entonces la memoria intermedia de cuadro del ojo izquierdo es la fuente de datos, pero cuando el Bit 2 es igual a 1 (nivel de lógica uno) , entonces la memoria intermedia de cuadro del ojo derecho es la fuente de datos. El Bit 3 del campo de Atributos de Datos de Píxel especifica si la memoria intermedia utilizada para actualizar la pantalla o la memoria intermedia de imágenes fuera de línea va a ser la fuente de la imagen para esta operación. El Bit 3 también puede aplicar a una pantalla alterna si la pantalla alterna utiliza una memoria intermedia de imágenes fuera de línea. Sin embargo, esto no soporta que la fuente de datos provenga de la memoria intermedia de imágenes principal cuando el destino de la imagen es una pantalla alterna, o viceversa. Cuando el Bit 3 es igual a un valor de 0 o nivel de lógica cero, la memoria intermedia de imágenes utilizada para actualizar la pantalla es la fuente de datos. Cuando el Bit 3 es igual a un valor de 1 o nivel de lógica uno, la memoria intermedia de imágenes fuera de línea es la fuente de datos.

Los Bits 7 y 6 del campo de Atributos de Datos de Píxel actúan como Bits de Actualización de Pantalla que especifican la memoria intermedia de cuadro en donde los datos de píxel se van a actualizar o escribir. Los efectos de los Bits de Actualización de Cuadro se describen con mayor detalle más adelante. Cuando los Bits [7:6] son ?01' (lógica cero, lógica uno) , los datos de píxel son escritos en una memoria intermedia de imágenes fuera de línea. Cuando los Bits [7:6] son 00' (doble lógica cero), los datos de píxel son escritos en una memoria intermedia de imágenes que se utiliza para actualizar la pantalla. Cuando los Bits [7:6] son ll' (doble lógica uno), los datos de píxel son escritos en todas las memorias intermedias de imágenes. Si los Bits [7:6] son y10' , esto se considera como un valor inválido. Estos bits actualmente están reservados para uso futuro. En esta situación, todo el comando es ignorado y ninguna memoria intermedia de cuadro es actualizada. Los Bits 11 a 8 del campo de Atributos de Datos de Píxel forman un entero sin firmar de 4 bits que especifica una pantalla alterna o ubicación de cliente alterna en donde los datos de píxel se van a actualizar. Los bits 0 y 1 se configuran igual a 00 (doble lógica cero) para que un cliente interprete los bits 11 a 8 como un número de pantalla alterno. Si los bits 1 y 0 no son iguales a 00, entonces los bits 8 a 11 generalmente se establecen igual a un valor o nivel de lógica cero. Los bits 4 a 5 y 12 a 15 se reservan para futuro uso y generalmente se establecen a un nivel o valores de lógica cero. En una modalidad, el campo de Operación de Trama de 2 bytes especifica cómo combinar los píxeles en las ubicaciones fuente y de destino para formar nuevos valores de píxel que van a ser escritos en una ubicación de imagen de destino. Las operaciones de trama definen la forma en que dos regiones rectangulares diferentes de igual tamaño en una memoria intermedia de cuadro se fusionan entre sí. El área de imagen de destino también es una de las dos imágenes que se fusionan entre sí. La segunda de las dos imágenes se denomina la imagen fuente. Si el cliente no soporta el campo de Operación de Trama tal como se especifica en el Paquete de Capacidad del Cliente, entonces el huésped generalmente envía este paquete con bits 3 a 0 igual a 3, y el cliente ignora los bits 3 a 0. En una modalidad, los Bits 3 a 0 se utilizan para especificar una operación de trama real utilizándolos o configurándolos igual a uno de los valores que se muestran en el cuadro VII a continuación para seleccionar la operación correspondiente que se muestra junto a ese valor. Es decir, cada valor especificado de Bits [3:0] listado en la primera columna produce como resultado la operación especificada en la segunda columna, y definida adicionalmente aquí para aclaración en la tercera columna.

CUADRO XVI Los bits 5 a 4 se utilizan para especificar si los píxeles de destino están o no escritos en las ubicaciones de destino conforme se relacionan con el color transparente. La operación especificada por los bits 5 a 4 aplica si las operaciones de trama son soportadas o no por el dispositivo del cliente. Si el cliente no soporta las operaciones de trama, entonces el valor de píxel de destino resultante que se va a considerar para la operación definida por los bits 5 a 4 es igual al valor de píxel fuente únicamente . Cuando el valor de Bits [5:4] es igual a 00, entonces no se utiliza el color transparente. Un píxel de destino resultante es escrito en la ubicación de píxel de destino sin considerar el valor del color transparente definido por el Paquete de Habilitación de Color Transparente. El valor de Bits [5:4] que es igual a 01, actualmente se está reservando para uso futuro y por lo regular no se emplea, aunque está disponible para que un experto en la técnica establezca un uso relacionado para el mismo. Cuando el valor de Bits [5:4] es igual a 10, el píxel resultante no es escrito para la ubicación de píxel de destino si el píxel de destino resultante calculado por la operación de trama es igual al color transparente. De lo contrario, es escrito para la ubicación de píxel de destino. Cuando el valor de Bits [5:4] es igual a 11, el píxel resultante no es escrito para la ubicación del píxel de destino si el píxel de destino resultante calculado por la operación de trama es igual al color transparente. De lo contrario, el píxel resultante no es escrito para la ubicación de píxel de destino. Los bits 15 a 16 se reservan para futuro uso y, por lo tanto, generalmente se configuran igual a un valor o nivel de lógica cero.

J. Para paquetes de relleno de patrón de mapa de bits En una modalidad, los campos de Valor X y Valor Y de Coordenada Izquierda Superior de Ventana utiliza 2 bytes, cada uno para especificar el valor X y Y de las coordenadas de la esquina izquierda superior de la ventana que se va a llenar. Los campos de Ancho y Altura de Ventana (2 bytes cada uno) especifican el ancho y altura de la ventana que se va a llenar. Los campos de Ancho de Patrón y Altura de Patrón (2 bytes cada uno) especifican el ancho y la altura, respectivamente, del patrón de relleno. El campo de Compensación de Patrón Horizontal (2 bytes) especifica una compensación horizontal del patrón de datos de píxel desde el borde izquierdo de la ventana especificada que se va a rellenar. El valor que se está especificando va a ser menor que el valor en el campo de Ancho de Patrón. El campo de Compensación de Patrón Vertical (2 bytes) especifica una compensación vertical del patrón de datos de píxel desde el borde superior de la ventana especificada que se va a rellenar. El valor que se está especificando va a ser menor que el valor en el campo de Altura de Patrón.

En una modalidad, el campo de Atributos de Datos de Píxel de 2 bytes tiene valores que especifican el lugar donde los datos de píxel van a ser actualizados, con los Bits 1 y 0 seleccionando la pantalla en donde se van a actualizar los datos de píxel. Si una pantalla primaria en el cliente no soporta imágenes estéreo, entonces el cliente puede afectar los datos de píxel en la pantalla primaria para una de las combinaciones de bits 01, 10 u 11. Se recomienda que se utilice el valor 11 para dirigir la pantalla primaria en clientes que no soportan capacidad de pantalla estéreo. Cuando los Bits [1:0] tienen los valores 11 (doble lógica uno) , los datos de píxel son actualizados en la memoria intermedia de cuadro tanto del ojo izquierdo como del derecho, si los Bits [1:0] tienen los valores 10 (lógica uno, lógica cero) , los datos de píxel son actualizados en la memoria intermedia de cuadro del ojo izquierdo únicamente. Cuando los Bits [1:0] tienen los valores 01 (lógica cero, lógica uno) , los datos de píxel son actualizados en la memoria intermedia de cuadro del ojo derecho únicamente. Cuando los Bits [1:0] tienen los valores 00 (doble lógica cero) , los datos de píxel son actualizados en la memoria intermedia de la pantalla alterna especificada por los bits 8 a 11 a continuación. En una modalidad, el Bit 2 del campo de Atributos de Datos de Píxel especifica si la memoria intermedia para el ojo izquierdo u ojo derecho es o no una fuente de la imagen para esta operación. El Bit 2 solo aplica cuando los bits [1:0] no son iguales a 00, lo cual generalmente se implementa para indicar que no soporta datos fuente provenientes de la memoria intermedia de imágenes principal cuando el destino de la imagen es una de las pantallas alternas. El Bit 2 se utiliza para diferenciar o especificar entre las memorias intermedias de cuadro del ojo izquierdo y derecho como una fuente de datos. Cuando el Bit 2 es igual a 0 (nivel de lógica cero) , entonces la memoria intermedia de cuadro del ojo izquierdo es la fuente de datos, pero cuando el Bit 2 es igual a 1 (nivel de lógica uno) , entonces la memoria intermedia de cuadro del ojo derecho es la fuente de datos. El Bit 3 del campo de Atributos de Datos de Píxel especifica si la memoria intermedia utilizada para actualizar la pantalla o la memoria intermedia de imágenes fuera de línea va a ser la fuente de la imagen para esta operación. El Bit 3 también puede aplicar a una pantalla alterna si la pantalla alterna utiliza una memoria intermedia de imágenes fuera de línea. Sin embargo, esto no soporta que la fuente de datos provenga de la memoria intermedia de imágenes principal cuando el destino de la imagen es una pantalla alterna, o viceversa. Cuando el Bit 3 es igual a un valor de 0 o nivel de lógica cero, la memoria intermedia de imágenes utilizada para actualizar la pantalla es la fuente de datos. Cuando el Bit 3 es igual a un valor de 1 o nivel de lógica uno, la memoria intermedia de imágenes fuera de línea es la fuente de datos . Los Bits 7 y 6 del campo de Atributos de Datos de Píxel actúan como Bits de Actualización de Pantalla que especifican la memoria intermedia de cuadro en donde los datos de píxel se van a actualizar o escribir. Los efectos de los Bits de Actualización de Cuadro se describen con mayor detalle más adelante. Cuando los Bits [7:6] son ?01' (lógica cero, lógica uno) , los datos de píxel son escritos en una memoria intermedia de imágenes fuera de línea. Cuando los Bits [7:6] son 00' (doble lógica cero), los datos de píxel son escritos en una memoria intermedia de imágenes que se utiliza para actualizar la pantalla. Cuando los Bits [7:6] son ll' (doble lógica uno), los datos de píxel son escritos en todas las memorias intermedias de imágenes. Si los Bits [7:6] son ?10', esto se considera como un valor inválido. Estos bits actualmente están reservados para uso futuro. En esta situación, todo el comando es ignorado y ninguna memoria intermedia de cuadro es actualizada. Los Bits 11 a 8 del campo de Atributos de Datos de Píxel especifican una pantalla o ubicación de cliente alterna en donde se van a actualizar los datos de píxel.

Los bits 0 y 1 se configuran igual a 00 (doble lógica cero) para que un cliente interprete los bits 11 a 8 como un número de pantalla alterno. Si los bits 1 y 0 no son iguales a 00, entonces los bits 8 a 11 generalmente se establecen igual a un valor o nivel de lógica cero. Los bits 4 a 5 y 12 a 15 se reservan para futuro uso y generalmente se establecen a un nivel o valores de lógica cero . En una modalidad, el campo de Operación de Trama de 2 bytes especifica cómo combinar los píxeles en las ubicaciones fuente y de destino para formar nuevos valores de píxel que van a ser escritos en una ubicación de imagen de destino. Las operaciones de trama definen la forma en que dos regiones rectangulares diferentes de igual tamaño en una memoria intermedia de cuadro se fusionan entre sí. El área de imagen de destino también es una de las dos imágenes que se fusionan entre sí. La segunda de las dos imágenes se denomina la imagen fuente. Si el cliente no soporta el campo de Operación de Trama tal como se especifica en el Paquete de Capacidad del Cliente, entonces el huésped generalmente envía este paquete con bits 3 a 0 igual a 3, y el cliente ignora los bits 3 a 0. En una modalidad, los Bits 3 a 0 se utilizan para especificar una operación de trama real utilizándolos o configurándolos igual a uno de los valores que se muestran en el cuadro VII a continuación para seleccionar la operación correspondiente que se muestra junto a ese valor. Es decir, cada valor especificado de Bits [3:0] listado en la primera columna produce como resultado la operación especificada en la segunda columna, y definida adicionalmente aquí para aclaración en la tercera columna.

CUADRO XVII Los bits 5 a 4 se utilizan para especificar si los píxeles de destino están o no escritos en las ubicaciones de destino conforme se relacionan con el color transparente. La operación especificada por los bits 5 a 4 aplica si las operaciones de trama son soportadas o no por el dispositivo del cliente. Si el cliente no soporta las operaciones de trama, entonces el valor de píxel de destino resultante que se va a considerar para la operación definida por los bits 5 a 4 es igual al valor de píxel fuente únicamente . Cuando el valor de Bits [5:4] del campo de Atributos de Datos de Píxel es igual a 00, entonces no se utiliza el color transparente. Un píxel de destino resultante es escrito en la ubicación de píxel de destino sin considerar el valor del color transparente definido por el Paquete de Habilitación de Color Transparente. El valor de Bits [5:4] que es igual a 01, actualmente se está reservando para uso futuro y por lo regular no se emplea, aunque está disponible para que un experto en la técnica establezca un uso relacionado para el mismo. Cuando el valor de Bits [5:4] es igual a 10, el píxel resultante no es escrito para la ubicación de píxel de destino si el píxel de destino resultante calculado por la operación de trama es igual al color transparente. De lo contrario, es escrito para la ubicación de píxel de destino. Cuando el valor de Bits [5:4] es igual a 11, el píxel resultante no es escrito para la ubicación del píxel de destino si el píxel de destino resultante calculado por la operación de trama es igual al color transparente. De lo contrario, el píxel resultante no es escrito para la ubicación de píxel de destino. Los bits 15 a 16 se reservan para futuro uso y, por lo tanto, generalmente se configuran igual a un valor o nivel de lógica cero. En una modalidad, un campo CRC de Parámetro de 2 bytes en el Paquete de Relleno de Patrón de Mapa de Bits contiene un CRC de todos los bytes desde la Longitud de Paquete hasta el Descriptor de Formato de Video. Si este CRC no checa, entonces se descarta todo el paquete. Un 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 son empacados en bytes, y el primer píxel de cada fila va a ser alineado en bytes. Los datos de patrón de relleno son transmitidos una fila a la vez. El campo CRC de Datos de Píxel de Patrón para el Paquete de Relleno de Patrón de Mapa de Bits utiliza 2 bytes que contienen un CRC únicamente de los Datos de Píxel de Patrón. Si este CRC no checa, entonces los Datos de Píxel de patrón pueden seguir siendo utilizados pero se incrementa el conteo de error de CRC.

K. Para paquetes de habilitación de canal de audio de avance El campo de Máscara de Habilitación de Canal de Audio (1 byte) contiene un grupo de indicadores que indican cuáles canales de audio se van a habilitar en un cliente. Un bit configurado en uno habilita el canal correspondiente, y un bit configurado en cero inhabilita 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 bafle de bajos, respectivamente. Los Bits 6 y 7 se reservan para futuro uso y, en el tiempo intermedio, generalmente se configuran igual a cero.

L. Para paquetes de velocidad inversa de muestra de audio El campo de Velocidad de Muestra de audio (1 byte) especifica la velocidad de muestra de audio digital. Los valores para este campo son asignados a las diferentes velocidades, en donde los valores de 0, 1, 2, 3, 4, 5, 6, 7, y 8 se utilizan para designar 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, y 44,100 muestras por segundo (SPS) , respectivamente, en donde los valores de 9 a 254 se reservan para uso con velocidades alternativas, según se desee, de manera que actualmente están configurados en'OX Un valor de 255 se utiliza para inhabilitar la corriente 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 están en formato lineal, cuando son iguales a 1, las muestras de audio digital están en un formato µ-Law, y cuando son iguales a 2, las muestras de audio digital están en un formato A-Law. Los Bits [7:2] se reservan para uso alterno en el diseño de formatos de audio, según se desee, y generalmente se establecen igual a cero.

M. Para paquetes de sobrecarga de protección de contenido digital El campo Tipo de Protección de Contenido (1 byte) especifica el método de protección de contenido digital que se está utilizando, ün valor de ?0' indica una 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 Alto (HDCP) . El rango de valores de 2 a 255 actualmente no se especifica pero se reserva para uso con esquemas de protección alternos, según se desee. El campo de Mensajes de Sobrecarga de Protección de Contenido es un campo de longitud variable que contiene mensajes de protección de contenido enviados entre el huésped y el cliente.

N. Para los paquetes de medición de retraso de viaje redondo El campo de Longitud de Paquete de 2 bytes especifica el número total de bytes en el paquete, sin incluir el campo de longitud de paquete, y en una modalidad es seleccionado para tener una longitud fija de 159. El campo de Tipo de Paquete de 2 bytes que identifica este tipo de paquete con un valor de 82, identifica un paquete como un Paquete de Medición de Retraso de Viaje Redondo. El campo ID de hCliente, tal como se mencionó anteriormente, queda reservado para futuro uso como una ID de Cliente, y generalmente se configura en cero. En una modalidad, el campo CRC de Parámetro (2 bytes) contiene un CRC de 16 bits de todos los bytes desde la Longitud de Paquete al Tipo de Paquete. Si este CRC no checa, entonces se descarta todo el paquete. El campo de Tiempo de Guardia 1 (aquí 64 bytes) se utiliza para permitir la habilitación de los accionadores de línea MDDI_Datos en el cliente antes que se inhabiliten los accionadores de línea en el huésped. El cliente habilita sus accionadores de línea MDDI_Datos durante el bit 0 del Tiempo de Guardia 1 y el huésped inhabilita sus accionadores de línea para que queden completamente inhabilitados antes del último bit de Tiempo de Guardia 1. El huésped y el cliente accionan un nivel de lógica cero durante el Tiempo de Guardia 1 cuando no están inhabilitados. Otro propósito de este campo es asegurar que todas las señales MDDI__Datos estén a un nivel de lógica cero durante un tiempo suficiente para permitir al cliente comenzar a recuperar una sincronía o señal de sincronía utilizando únicamente MDDI_Stb antes de inhabilitar los accionadores de línea de huésped. El campo de Periodo de Medición es una ventana de 64 bytes utilizada para permitir al cliente responder con dos bytes de Oxff, y 30 bytes de 0x00 a la mitad de la velocidad de datos utilizada en el enlace de avance. Esta velocidad de datos corresponde a un Divisor de Velocidad de Enlace Inverso de 1. El cliente regresa su respuesta inmediatamente al momento en que percibe el comienzo del Periodo de Medición. Esta respuesta del cliente será recibida en un huésped precisamente al momento del retraso de viaje redondo del enlace más el retraso lógico en el cliente después de comenzar el primer bit del Periodo de Medición en el huésped. El campo Todos Ceros 1 (2 bytes) contiene ceros para permitir que los accionadores de línea MDDI_Datos en el huésped y el cliente se traslapen de manera que MDDI_Datos siempre esté accionado. El huésped habilita los accionadores de línea de MDDI_Datos durante el bit 0 del campo de Todos Cero 1, y el cliente también continúa accionando la señal a un nivel de lógica cero tal como lo hizo al final del Periodo de Medición. El valor en el campo de Tiempo de Guardia 2 (64 bytes) permite el traslape del Periodo de Medición accionado por el cliente cuando el retraso de viaje redondo está a la cantidad máxima que puede ser medida en el Periodo de Medición. El Cliente inhabilita sus accionadores de línea durante el bit 0 del Tiempo de Guarida 2 y el Huésped habilita sus accionadores de línea inmediatamente después del último bit del Tiempo de Guardia 2. El huésped y el cliente accionan un nivel de lógica cero durante el Tiempo de Guardia 2 cuando no están inhabilitados. Otro propósito de este campo es asegurar que todas las señales MDDI_Datos estén a un nivel de lógica cero durante un tiempo suficiente para permitir al cliente comenzar a recuperar una señal de sincronía utilizando tanto MDDI_Datos0 y MDDI_Stb después de habilitar los accíonadores de línea para un huésped.

O. Para paquetes de calibración de sesgo de enlace de avance En una modalidad, el campo CRC de Parámetro (2 bytes) contiene un CRC de 16 bits de todos los bytes desde la Longitud de Paquete al Tipo de Paquete. Si este CRC no checa, entonces se descarta todo el paquete.

El campo de Todos Ceros 1 utiliza 8 bytes para asegurar que habrá transiciones en la MDDI_Stb al comienzo del campo de Secuencia de Datos de Calibración. Generalmente, estos bytes emplean enteros sin firmar de 8 bits igual a cero. También provee el tiempo suficiente para que la lógica de núcleo de cliente cambie el modo del circuito de recuperación de sincronía a partir del uso de XOR de MDDI_0 y MDDI_Stb, para simplemente utilizar MDDl_Stb o la señal MDDI_Stb como la sincronía recuperada. El campo de Secuencia de Datos de Calibración contiene una secuencia de datos que ocasiona que las señales MDDI_Datos se activen en cada periodo de datos. La longitud del campo de Secuencia de Datos de Calibración queda determinada por la interfaz que se está utilizando en el enlace de avance. Durante el procesamiento de la Secuencia de Datos de Calibración, el controlador de huésped MDDI establece todas las señales MDDI_Datos igual a la señal estroboscópica. El circuito de recuperación de sincronía del cliente debería utilizar únicamente MDDI_Stb en lugar de MDDI_Stb XOR MDDI_DatosO para recuperar la sincronía de datos mientras el campo de Secuencia de Datos de Calibración está siendo recibido por el cliente. Dependiendo de la fase exacta de la señal MDDI_Stb al comienzo 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 interfaz que se esté utilizando cuando este paquete sea enviado: Tipo 1 - (secuencia de datos de 64 bytes) Oxaa, Oxaa... ó 0x55, 0x55... Tipo 2 - (secuencia de datos de 128 bytes) Oxee, Oxee... ó 0x33, 0x33... Tipo 3 - (secuencia de datos de 256 bytes) OxfO, OxfO... ó OxOf, OxOf... Tipo 4 - (secuencia de datos de 512 bytes) Oxff, 0x00, Oxff, 0x00,... ó 0x00, Oxff, 0x00, Oxff... El campo de Todos Ceros 2 utiliza 8 bytes para proveer suficiente tiempo a fin de que la lógica de núcleo del cliente cambie el modo del circuito de recuperación de sincronía de regreso a un estado original, a partir del uso de la señal MDDI_Stb como la sincronía recuperada al uso de XOR de MDDI_0 y MDDI_Stb. Generalmente estos bytes emplean enteros sin firmar de 8 bits igual a cero. Un ejemplo de las formas de onda posibles de MDDI_Datos y MDDI_Stb para las interfaces Tipo 1 y Tipo 2 se muestra en las figuras 62A y 62B, respectivamente.

XIX. Conclusión Aunque se han descrito varias modalidades de la presente invención, se debería entender que se han presentado a manera de ejemplo únicamente, y no como una limitación. Por lo tanto, la amplitud y alcance de la presente invención no deberían quedar limitados por ninguna de las modalidades ejemplares antes descritas, pero se deberían definir únicamente de acuerdo con las siguientes reivindicaciones y sus equivalentes.

Claims (1)

1. NOVEDAD DE A INVENCIÓN Habiendo descrito el presente invento, se considera como una novedad y, por lo tanto, se reclama como prioridad lo contenido en las siguientes: REIVINDICACIONES 1.- Una interfaz de datos digitales para transferir datos de presentación digital a una velocidad alta entre un dispositivo de huésped y un dispositivo de cliente en una trayectoria de comunicación, que comprende: una pluralidad de estructuras de paquete enlazadas entre sí para formar un protocolo de comunicación para comunicar un conjunto previamente seleccionado de datos de presentación y control digital entre un huésped y un cliente en esa trayectoria de comunicación; y por lo menos un controlador de enlace que reside en dicho dispositivo de huésped acoplado a dicho cliente a través de dicha trayectoria de comunicaciones, el cual está configurado para generar, transmitir y recibir paquetes que forman dicho protocolo de comunicaciones, y para formar datos de presentación en uno o más tipos de paquetes de datos . 2. - La interfaz de conformidad con la reivindicación 1, que además comprende dichos paquetes agrupados entre sí dentro de cuadros de medios que son comunicados entre dicho huésped y cliente teniendo una longitud fija previamente definida con un número predeterminado de dichos paquetes que tienen longitudes diferentes y variables. 3.- La interfaz de conformidad con la reivindicación 1, que además comprende un Paquete de Encabezado de Sub-cuadro colocado al comienzo de las transferencias de paquetes desde dicho huésped. 4.- La interfaz de conformidad con la reivindicación 1, que además comprende un Paquete de Estado de Energía de Pantalla para colocar hardware relacionado con el cliente específico en un estado de baja energía. 5. - La interfaz de conformidad con la reivindicación 1, caracterizada porque dicho controlador de enlace es un controlador de enlace de huésped y además comprende por lo menos un controlador de enlace de cliente que reside en dicho dispositivo de cliente acoplado a dicho huésped a través de dicha trayectoria de comunicaciones, estando configurado 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. 6.- La interfaz de conformidad con la reivindicación 2, que además comprende: una pluralidad de modos de transferencia, cada uno permite la transferencia de diferentes números máximos de bits de datos en paralelo en un periodo de tiempo determinado, en donde cada modo se puede seleccionar negociando entre dichos accionadores de enlace de huésped y cliente; y en donde dichos modos de transferencia son dinámicamente ajustables entre dichos modos durante la transferencia de datos. 1 . - La interfaz de conformidad con la reivindicación 1, que además comprende un paquete tipo Apagado de Enlace para transmisión por dicho huésped a dicho cliente a fin de finalizar la transferencia de datos en cualquier dirección en dicha trayectoria de comunicación. 8.- La interfaz de conformidad con la reivindicación 1, que además comprende medios para que dicho cliente despierte a dicho huésped de un estado de hibernación. 9.- ün método para transferir datos digitales a una velocidad alta entre un dispositivo huésped y un dispositivo de cliente en una trayectoria de comunicación para presentación a un usuario, que comprende: generar una o más de una pluralidad de estructuras de paquete previamente definidas y enlazarlas entre sí para formar un protocolo de comunicación previamente definido; comunicar un conjunto previamente seleccionado de datos de presentación y control digital entre dichos dispositivos de huésped y cliente en dicha trayectoria de comunicación utilizando dicho protocolo de comunicación; acoplar por lo menos un controlador de enlace de huésped que reside en dicho dispositivo huésped a dicho dispositivo de cliente a través de dicha trayectoria de comunicación, el controlador de enlace de huésped está configurado 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 la forma de paquetes en dicha trayectoria de comunicaciones utilizando dichos controladores de enlace. 10.- El método de conformidad con la reivindicación 9, que además comprende agrupar dichos paquetes entre sí dentro de cuadros de medios para comunicación entre dicho huésped y cliente, los cuadros de medios tienen una longitud fija previamente definida con un número previamente determinado de dichos paquetes que tienen longitudes diferentes y variables. 11.- El método de conformidad con la reivindicación 9, que además comprende comenzar a transferir paquetes desde dicho huésped con un paquete tipo Encabezado de Sub-Cuadro. 12.- El método de conformidad con la reivindicación 9, que además comprende generar, transmitir y recibir paquetes que forman dicho protocolo de comunicaciones a través, por lo menos, de un controlador de enlace de cliente que reside en dicho dispositivo de cliente acoplado a dicho dispositivo de huésped a través de dicha trayectoria de comunicación. 13.- El método de conformidad con la reivindicación 12, que además comprende: negociar entre los accionadores de enlace de huésped y cliente el uso de uno de una pluralidad de modos de transferencia en cada dirección, cada uno permitiendo la transferencia de diferentes números máximos de bits de datos en paralelo en un periodo de tiempo determinado; y realizar ajustes dinámicamente entre dichos modos de transferencia durante la transferencia de datos. 14.- El método de conformidad con la reivindicación 9, que además comprende finalizar la transferencia de datos en cualquier dirección en dicha trayectoria de comunicación utilizando un paquete tipo Apagado de Enlace para la transmisión por parte de dicho huésped a dicho cliente. 15.- El método de conformidad con la reivindicación 9, que además comprende despertar a dicho huésped de un estado de hibernación a través de comunicación con dicho cliente. 16.- El método de conformidad con la reivindicación 9, que además comprende generar un Paquete de Estado de Energía de Pantalla para colocar hardware de cliente específico en un estado de baja energía. 17.- Un aparato para transferir datos digitales a una alta velocidad entre un dispositivo huésped y un dispositivo de cliente en una trayectoria de comunicación para presentación a un usuario, que comprende: por lo menos un controlador de enlace de huésped colocado en dicho dispositivo huésped para generar una o más de una pluralidad de estructuras de paquete previamente definidas y enlazarlas entre sí para formar un protocolo de comunicación previamente definido, y para comunicar un conjunto previamente seleccionado de datos de presentación y control digital entre dichos dispositivos de huésped y de cliente en dicha trayectoria de comunicación utilizando dicho protocolo de comunicación; por lo menos un controlador de cliente colocado en dicho dispositivo de cliente y acoplado a dicho controlador de enlace de huésped a través de dicha trayectoria de comunicaciones; y cada controlador de enlace está configurado 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 . 18.- El aparato de conformidad con la reivindicación 17, caracterizado porque dicho controlador huésped comprende una máquina de estado. 19.- El aparato de conformidad con la reivindicación 17, caracterizado porque dicho controlador huésped comprende un procesador de señal de propósito general . 20.- El aparato de conformidad con la reivindicación 17, que además comprende un paquete tipo Encabezado de Sub-Cuadro al inicio de la transferencia de paquetes desde dicho huésped. 21.- El aparato de conformidad con la reivindicación 17, caracterizado porque dicho controlador huésped comprende uno o más accionadores de línea diferencial; y dicho receptor de cliente comprende uno o más receptores de línea diferencial acoplados a dicha trayectoria de comunicación. 22.- El aparato de conformidad con la reivindicación 17, caracterizado porque dicho controlador huésped comprende uno o más accionadores de línea diferenciales; y dicho receptor de cliente comprende uno o más receptores de línea diferenciales acoplados a dicha trayectoria de comunicación. 22.- El aparato de conformidad con la reivindicación 17, caracterizado porque dichos controladores de cliente y huésped están configurados para utilizar uno de una pluralidad de modos de transferencia en cada dirección, en donde cada uno permite la transferencia de diferentes números máximos de bits de datos en paralelo en un periodo de tiempo determinado; y tienen la capacidad de ser dinámicamente ajustados entre dichos modos de transferencia durante la transferencia de datos. 23.- El aparato de conformidad con la reivindicación 17, caracterizado porque dicho controlador huésped está configurado para transmitir un paquete tipo Apagado de Enlace a dicho medio de cliente para finalizar la transferencia de datos en cualquier dirección en dicha trayectoria de comunicación. 24.- El aparato de conformidad con la reivindicación 17, caracterizado porque dicho controlador huésped está configurado para generar un Paquete de Estado de Energía de Pantalla para colocar hardware de controlador de pantalla específico en un estado de baja energía. 25.- Para uso en un sistema electrónico para transferir datos digitales a una alta velocidad entre un dispositivo huésped y un dispositivo del cliente en una trayectoria de comunicación para presentación a un usuario, un producto de programa de cómputo que comprende: un medio utilizable por computadora que tiene medios de código de programa legible por computadora incorporados en dicho medio para ocasionar que un programa de aplicación se ejecute en el sistema de cómputo, dicho medio de código de programa legible por computadora comprende: un primer código de programa legible por computadora para ocasionar que el sistema de cómputo genere una o más de una pluralidad de estructuras de paquete previamente definidas y las enlace entre sí para formar un protocolo de comunicación previamente definido; un segundo código de programa legible por computadora para ocasionar que el sistema de cómputo comunique un conjunto previamente seleccionado de datos de presentación y control digital entre dicho dispositivo huésped y dicho dispositivo del cliente en dicha trayectoria de comunicación utilizando dicho protocolo de comunicación; un tercer código de programa legible por computadora para ocasionar que el sistema de cómputo acople por lo menos un controlador de enlace huésped colocado en dicho dispositivo huésped por lo menos a un controlador de cliente colocado en dicho dispositivo de cliente a través de dicha trayectoria de comunicación, los controladores de enlace están configurados 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 código de programa legible por computadora para ocasionar que el sistema de cómputo transfiera datos en la forma de paquetes en dicha trayectoria de comunicaciones utilizando dichos controladores de enlace. 26.- El producto de programa de cómputo de conformidad con la reivindicación 25, que comprende: un medio de código de programa legible por computadora para ocasionar que el sistema de cómputo genere estructuras de paquete previamente definidas y las enlace entre sí para formar un protocolo de comunicación previamente definido. 27.- Un aparato para transferir datos digitales a una velocidad alta entre un dispositivo huésped y un dispositivo de cliente en una trayectoria de comunicación para presentación a un usuario, que comprende: medios para generar una o más de una pluralidad de estructuras de paquete previamente definidas y enlazarlas entre sí para formar un protocolo de comunicación previamente definido; medios para comunicar un conjunto previamente seleccionado de datos de presentación y control digital entre dichos dispositivos de huésped y cliente en dicha trayectoria de comunicación utilizando dicho protocolo de comunicación; medios para acoplar por lo menos dos controladores de enlace a través de dicha trayectoria de comunicación, uno en cada uno del huésped y el cliente y cada uno configurado 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 medios para transferir datos en la forma de paquetes en dicha trayectoria de comunicaciones utilizando dichos controladores de enlace. 28.- El aparato de conformidad con la reivindicación 27, que además comprende medios para comenzar la transferencia de paquetes desde dicho huésped con un paquete tipo Encabezado de Sub-cuadro. 29.- El aparato de conformidad con la reivindicación 27, que además comprende medios para generar un Paquete de Estado de Energía de Pantalla configurado para colocar hardware específico en un estado de baja energía. 30.- El aparato de conformidad con la reivindicación 27, que además comprende medios para solicitar información de capacidades de pantalla de un cliente a través de un controlador de enlace de huésped con el fin de determinar qué tipo de datos y velocidades de datos, dicho cliente es capaz de permitir a través de dicha interfaz . 31.- Un procesador para uso en un sistema electrónico para transferir datos digitales a una velocidad alta entre un dispositivo huésped y un dispositivo del cliente en una trayectoria de comunicación, el procesador configurado para generar una o más de una pluralidad de estructuras de paquete previamente definidas y enlazarlas entre sí para formar un protocolo de comunicación previamente definido; para formar datos de presentación digital en uno o más tipos de paquetes de datos; comunicar un conjunto previamente seleccionado de datos de presentación y control digital entre dichos dispositivos de huésped y cliente en dicha trayectoria de comunicación utilizando dicho protocolo de comunicación; y transferir datos en la forma de paquetes en dicha trayectoria de comunicaciones . 32.- Una máquina de estado para uso en la obtención de sincronización en un sistema electrónico que transfiere datos digitales a una velocidad alta entre un dispositivo huésped y un dispositivo del cliente en una trayectoria de comunicación, la máquina de estado configurada para tener por lo menos un estado de sincronización de Estado de Cuadros Asincrono, por lo menos dos estados de sincronización de Estados Sincrónicos de Adquisición, y por lo menos tres estados de sincronización de Estados En-Sincronía. 33.- Una máquina de estado para uso en la obtención de sincronización en un sistema electrónico que transfiere datos digitales a una velocidad alta entre un dispositivo huésped y un dispositivo del cliente en una trayectoria de comunicación, la máquina de estado configurada para tener por lo menos un estado de sincronización de Estados Sincrónicos de Adquisición, y por lo menos dos estados de sincronización de Estados En-Sincronía.