MXPA06005403A - Interfaz de velocidad de datos elevada - Google Patents

Abstract

Una Interfaz de datos para transferir datos digitales entre un anfitrión y un cliente a través de una trayectoria de comunicación utilizando estructuras de paquete enlazadas conjuntamente para formar un protocolo de comunicación para comunicar un grupo preseleccionado de datos de control y presentación digital. El protocolo de la señal se utiliza mediante los controladores de enlace configurados para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones, ypara formar datos digitales dentro de uno o más tipos de paquetes de datos, con al menos uno residiendo en el dispositivo anfitrión y que se acopla con el cliente a través de la trayectoria de comunicaciones. La interfaz proporciona un mecanismo de transferencia de datos efectivo en costos, de baja potencia, bidireccional, de velocidad elevada a través de un enlace de datos tipo"serial"de corto alcance, que se presta por símismo para la implementación con conectores miniatura y cables flexibles delgados que son especialmenteútiles para conectar elementos de pantalla tales como micropantallas usables en computadoras portátiles y dispositivos de comunicación inalámbricos.

Description

INTERFAZ DE VELOCIDAD DE DATOS ELEVADA CAMPO DE LA INVENCIÓN Las modalidades de la invención en esta descripción se relacionan a un protocolo y un proceso de una señal digital para comunicar o transferir señales entre un dispositivo huésped y un dispositivo de cliente a velocidades de datos elevadas. Más específicamente, la descripción se " relaciona con una técnica para transferir multimedia u otros tipos de señales digitales desde un huésped o dispositivo controlador a un dispositivo de cliente para su presentación o despliegue de un usuario final que utiliza un mecanismo de transferencia de velocidad de datos elevada de potencia baja que tiene aplicaciones de dispositivo interno y externo.

ANTECEDENTES DE LA INVENCIÓN Las computadoras, los productos relacionados con los juegos electrónicos y diversas tecnologías de video (por ejemplo los DVD y los VCR de alta definición) han avanzado significativamente durante los últimos años para proporcionar su presentación de imágenes fijas de una cada vez mayor alta resolución, video, video a la carta y gráficos, incluso cuando incluyen algunos tipos de texto, para los usuarios finales de tal equipo. Esos avances a su vez exigían el uso de dispositivos de pantalla electrónicos de una resolución más alta tales como los monitores de video de alta definición, los monitores HDTV, o elementos de proyección de imagen especializados. Combinar ese tipo de imágenes visuales con datos de audio de calidad o alta definición, tales como cuando se utilizan en la reproducción tipo CD, los DVD, sonido envolvente, y otros dispositivos que también tienen salidas de señal de audio asociadas, se utiliza para crear una experiencia multimedia más realista, de contenido rico o verdadero para un usuario final. Además, se han desarrollado sistemas de sonido altamente móviles de alta calidad, y mecanismos de transporte de música, tales como los reproductores de 1P3 , solamente para presentaciones de audio para los usuarios finales . Esto ha- dado por resultado un incremento de las expectativas de los usuarios típicos para dispositivos electrónicos comerciales, desde computadoras hasta televisiones e incluso teléfonos, que ahora se personalizan para y de los que se espera una salida de calidad elevada o de primera calidad. En un escenario de presentación de video típico, que involucra un producto electrónico, los datos de video típicamente se transfieren utilizando técnicas actuales a una velocidad que podría determinarse mejor como lenta o media, que está en el orden de uno a decenas de kilobits por segundo. Estos datos están ya sea almacenados en forma intermedia, o almacenados en dispositivos de memorias transitorias o de largo plazo, para una reproducción retrasada (posterior) en un dispositivo de despliegue deseado. Por ejemplo, las imágenes pueden transferirse "a través de" o utilizando la Internet utilizando un programa residente en una computadora que tiene un módem u otro tipo de dispositivo de conexión a Internet, para recibir o transmitir datos útiles en la representación digital de una imagen. Puede llevarse a cabo una transferencia similar utilizando dispositivos inalámbricos tales como computadoras portátiles equipadas con módems inalámbricos, o asistentes de datos personales inalámbricos (los PDA) , o teléfonos inalámbricos. Una vez que se reciben, los datos se almacenan localmente en elementos de memoria, circuitos o dispositivos, tales como una RAM o una memoria no volátil, incluyendo dispositivos de almacenamiento internos o externos tales como discos duros de tamaño pequeño, para reproducción. Dependiendo de la cantidad de datos y la resolución de imagen, la reproducción podría comenzar relativamente rápida, o puede presentarse con un retraso de largo plazo. Es decir, en algunos casos, la presentación de la imagen permite cierto grado de reproducción en tiempo real para imágenes de muy pequeña o baja resolución que no requieran muchos datos, o que utilicen algún tipo de almacenamiento intermedio, para que después de un pequeño retraso, parte del material se presente mientras se está transfiriendo más material . A condición de que no existan interrupciones en el enlace de transferencia, o interferencia de otros sistemas o usuarios con relación al canal de transferencia que se está utilizando, una vez que comienza la presentación la transferencia es razonablemente transparente para el usuario final del dispositivo de despliegue. Naturalmente , cuando múltiples usuarios comparten una sola trayectoria de comunicación, tal como una conexión a Internet cableada, las transferencias pueden interrumpirse o reducirse más de lo deseado. Los datos utilizados para crear ya sea imágenes fijas o video en movimiento a menudo se comprimen utilizando una o diversas técnicas bien conocidas tales como las que se especifican mediante el Grupo Conjunto de Expertos en Fotografía (JPEG) , el Grupo de Expertos en Películas en Movimiento (MPEG) , y otras organizaciones de estándares bien conocidas o compañías en multimedia, cómputo e industrias de las comunicaciones para acelerar la transferencia de datos a través de un enlace de comunicación. Esto permite una transferencia de imágenes o de datos más rápida al utilizar un número más pequeño de bits para transferir una cantidad determinada de información. Una vez que los datos se transfieren a un dispositivo "local" tal como una computadora que tiene un mecanismo de almacenamiento tal como una memoria, o elementos de almacenamiento magnéticos u ópticos o hacia otros dispositivos receptores, la información que resulta está descomprimida (o reproducida utilizando reproductores de descodificación especiales) , y descodificada si es necesario, y preparada para su presentación apropiada con base en la resolución de presentación correspondiente disponible y los elementos de control. Por ejemplo, una resolución de video típica para una computadora en términos de resolución en pantalla de pixeles X por Y típicamente fluctúa desde tan abajo como 480x640 pixeles, a través de 600x800 hasta 1024x1024, aunque son generalmente posibles una variedad de otras resoluciones, ya sea según se desee o sea necesario. La presentación de la imagen también está afectada por el contenido de la imagen 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 pixel utilizados para generar colores) e intensidades, y cualesquiera bits de operaciones auxiliares adicionales que se empleen. Por ejemplo, una presentación en computadora típica se anticiparía desde cualquier parte desde aproximadamente 8 hasta 32, o más, bits por pixel para representar diversos colores (tonalidades y matices) , aunque pueden encontrarse otros valores . A partir de los valores anteriores, puede verse que una imagen en pantalla determinada va a requerir la transferencia desde cualquier parte a partir de 2.45 Megabits (Mb) hasta aproximadamente 33.55 Mb de datos sobre el rango a partir de las resoluciones y profundidades típicas más baja hasta la más alta, respectivamente. Cuando se visualiza video o imagen tipo en movimiento a una velocidad de 30 tramas por segundo, la cantidad de datos que se requieren es de aproximadamente 73.7 hasta 1,006 Megabits de datos por segundo (Mbps) , o aproximadamente 9.21 hasta 125.75 Megabytes por segundo (MBps) . Además, puede ser deseable presentar datos de audio junto con las imágenes, tales como para presentación multimedia, o como una presentación de audio de alta resolución por separado, tal como la música de calidad CD. También pueden emplearse señales adicionales que tienen que ver con comandos interactivos, controles o señales. Cada una de esas opciones agrega incluso más datos que se van a transferir. Además, las técnicas de transmisión más nuevas involucran grabaciones de televisión y película de Alta Definición (HD) que pueden agregar incluso más datos e información de control. En cualquier caso, cuando se desea transferir datos de imágenes de alta calidad o alta resolución e información o señales de datos de audio de alta calidad a un usuario final para crear una experiencia rica en contenido, se requiere un enlace de velocidad de transferencia de datos elevada entre los elementos de presentación y la fuente o el dispositivo anfitrión que se configura para proporcionar tales tipos de datos. Las velocidades de datos de aproximadamente 115 Kilobytes (KBps) ó 920 Kilobits por segundo (Kbps) pueden manejarse rutinariamente mediante algunas interfaces en serie moderna. Otras interfaces tales como interfaces en serie USB, pueden ajustar transferencia de datos a velocidades tan altas como 12 MBps, y transferencias de rapidez elevada especializadas tales como las que se configuran utilizando la norma 1394 del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) puede ocurrir a velocidades en el orden de 100 hasta 400 MBps. Desafortunadamente, esas velocidades se quedan cortas con las velocidades de datos elevadas deseadas que se discutieron anteriormente que están contempladas para utilizarlas con futuros dispositivos de datos inalámbricos y otros servicios para proporcionar una alta resolución, un contenido rico, señales de salida para controlar dispositivos de despliegues de video portátiles o audio.

Esto incluye computadoras para negocios y otras presentaciones, dispositivos para juegos, etc. Además, esas interfaces requieren el uso de una cantidad significativa de un anfitrión o sistema y software del cliente para operar. Sus pilas de protocolo de software también crean una cantidad enormemente indeseable de operaciones auxiliares, especialmente en donde se tienen contemplados dispositivos móviles inalámbricos o aplicaciones telefónicas. Tales dispositivos tienen severas limitaciones de consumo de memoria y energía eléctrica, así como una capacidad computacional ya puesta a prueba. Además, algunas de esas interfaces utilizan cables voluminosos los cuales son demasiado pesados e insatisfactorios para aplicaciones móviles orientadas a ser altamente estéticas, conectores complejos los cuales agregan costos, o simplemente consumen demasiada energía eléctrica. Existen otras interfaces conocidas tales como la del Adaptador de Gráficos de Video Análogo (VGA) , Video Digital Interactivo (DVI) o Interfaces de Interfaz de Video de Gigabit (GVIF) . Las primeras dos de esas son interfaces de tipo paralelo que procesan datos a velocidades de transferencia más elevadas, pero también emplean cables pesados y consumen enormes cantidades de energía eléctrica, en el orden de varios vatios . Ninguna de esas características es asequible para utilizarlas con dispositivos electrónicos del consumidor portátiles. Incluso la tercera interfaz consume demasiada energía eléctrica y utiliza conectores costosos o voluminosos. Para algunas de las interfaces anteriores, y otros sistemas/protocolos de datos de velocidad muy elevada por mecanismos de transferencia asociados con las transferencias de datos para equipo de cómputo de instalación fija, existe otra desventaja mayor. Para ajustar las velocidades de transferencia de datos deseadas también se requieren sustanciales cantidades de energía eléctrica y/u operación en elevados niveles de corriente. Esto reduce enormemente la utilidad de tales técnicas para productos orientados hacia el consumidor, altamente móviles . Generalmente, para ajustar tales velocidades de transferencia de datos utilizando alternativas tales como digamos conexiones de tipo 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, que los deseados para un producto propiamente orientado hacia un consumidor comercial. A parte de la naturaleza generalmente costosa de los sistemas ópticos hasta el momento, sus requerimientos de energía eléctrica y complejidad evitan el uso general de aplicaciones portátiles de baja energía eléctrica, y de bajo peso. De lo que ha carecido la industria de aplicaciones portátiles, inalámbricas o móviles, es una técnica que proporcione 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, los PDA, u otros dispositivos o equipos de comunicación altamente móviles, los sistemas o dispositivos de presentación de video y audio actuales que se utilizan simplemente no pueden suministrar una salida al nivel de calidad elevado deseado. A menudo, la calidad percibida que hace falta es el resultado de velocidades de datos elevadas que no se pueden obtener y que son necesarias para transferir los datos de la presentación de alta calidad. Estos pueden incluir tanto, transferencia a dispositivos externos de característica cargada o avanzada más eficientes, para la presentación a un usuario final, o transferir entre anfitriones y clientes internos hacia dispositivos portátiles tales como computadoras, máquinas de juego, y dispositivos inalámbricos tales como teléfonos móviles . En este último caso, ha habido enormes avances que se han hecho al agregar pantallas de video internas de más alta resolución, y otros dispositivos de entrada y/o salida de especialidad y conexiones a dispositivos inalámbricos como los así llamados teléfonos de la tercera generación, y para las llamadas computadoras laptop. Sin embargo, los buses y las conexiones de datos internos los cuales pueden incluir un puenteo a través de la rotación o deslizamiento de estructuras de articulación o similares a una articulación las cuales se montan o se conectan a pantallas de video u otros elementos al alojamiento principal en donde residen el anfitrión y/o diversos elementos de control y componentes de salida. Es muy difícil construir interfaces de transferencias de datos de rendimiento total elevado que utilizan técnicas anteriores que pueden requerir hasta 90 conductores o más, para alcanzar el rendimiento total deseado, en dichos teléfonos inalámbricos, como un ejemplo. Esto presenta muchas cuestiones de fabricación, que son carísimas y retos de confiabilidad que superar. Tales cuestiones y requerimientos también se han visto en instalaciones de ubicación fija en donde la comunicación o los dispositivos de tipo cómputo, como un ejemplo, se agregan a los electrodomésticos y otros dispositivos del consumidor para proporcionar capacidades de datos avanzadas, Internet y conexiones de transferencia de datos, o entretenimiento integrado. Otro ejemplo serían los aviones y los autobuses en donde la pantalla de presentación de audio y video individual se monta en los respaldos de los asientos. Sin embargo, en esas situaciones es a menudo, eficiente y fácilmente aprovechable dar servicio al tener el almacenamiento principal, el procesamiento o los elementos de control de la comunicación ubicados a una distancia desde pantallas visibles o salidas de audio con un enlace o canal de interconexión para la presentación de la información. Este enlace necesitará el manejo de una cantidad significativa de datos para alcanzar el rendimiento total deseado, como se discute anteriormente . Por lo tanto, se necesita un nuevo mecanismo de transferencia para incrementar el rendimiento total de datos entre los dispositivos del anfitrión que proporcionan los datos y los dispositivos de despliegue de cliente o los elementos que presentan una salida a los usuarios finales. Se han propuesto tales mecanismos nuevos de transferencia en las Solicitudes de Patente Norteamericanas Nos. de Serie 10/020,520 y 10/236,657, tituladas ambas "Generación e Implementación de un Protocolo de Comunicación e Interfaz para una Transferencia de Señal de Velocidad de Datos Elevada", ahora otorgadas, las cuales se asignan al cesionario de la presente invención y se incorporan a la presente para referencia. Además, la Solicitud No. de Serie 10/860,116 titulada "Generación e Implementación de un Protocolo de Señal e Interfaz para Velocidades de Datos más Elevadas" . Las técnicas discutidas en esas solicitudes pueden mejorar enormemente la velocidad de transferencia para enormes cantidades de datos en señales de datos de rapidez elevada. Sin embargo, las demandas por cada vez más velocidades de datos incrementan, especialmente como relación a presentaciones de video, continúan creciendo. Incluso con otros desarrollos en curso en la tecnología de las señales de datos, existe aún una necesidad por esmerarse en velocidades de transferencia más rápidas, eficiencias de enlaces de comunicación mejoradas, y enlaces de comunicación más poderosos. Por lo tanto, existe una necesidad continua de desarrollar un mecanismo de transferencia nuevo o mejorado, que es necesario para incrementar el rendimiento total de datos entre los dispositivos del anfitrión y el cliente.

SUMARIO DE LA INVENCIÓN La desventaja anterior y otras, que existen en la técnica se direccionan mediante las modalidades de la invención en la cual se ha desarrollado un nuevo protocolo y medio de transferencia de datos, método y mecanismo para transferir datos entre un dispositivo anfitrión y un dispositivo receptor de cliente a velocidades de datos elevadas.

Las modalidades de la invención se dirigen hacia una Interfaz Digital de Datos Móvil (MDDI) para transferir datos digitales a una velocidad elevada entre un dispositivo anfitrión y un dispositivo de cliente a través de una trayectoria de comunicación que emplea una pluralidad o series de estructuras de paquete para formar un protocolo de comunicación para comunicar un conjunto pre-seleccionado de control digital y datos de presentación entre los dispositivos de anfitrión y el cliente. El protocolo de comunicaciones de señal o capa de enlace se utilizan mediante una capa física de los controladores de enlace de anfitrión o el cliente. Al menos un controlador de enlace que reside en el dispositivo de anfitrión se acopla ' al dispositivo de cliente a través de una 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 proporciona una transferencia bi-direccional de información entre el anfitrión y el cliente, que puede residir dentro de un alojamiento global común o una estructura de soporte . La implementación es generalmente toda digital en su naturaleza con la excepción de controladores y receptores diferenciales que pueden fácilmente implementarse en un chip CMOS digital, que requiere unas cuantas tal como 6 señales, y opera casi a cualquier velocidad de datos que es conveniente para el diseñador del sistema. El protocolo de capa física y de enlace simple hace fácil integrar, y esta simplicidad más un estado de hibernación posibilita que el sistema portátil tenga un consumo de energía de sistema muy bajo. Para ayudar en el uso y la aceptación, la interfaz incrementará muy poco el costo de un dispositivo, permitirá un consumo muy pequeño de energía mientras que posibilita que los despliegues de energía a través de la interfaz utilicen voltajes de batería estándar, y pueden ajustar dispositivos que tienen un tamaño físico que puede meterse en el bolsillo. La interfaz es escalable para soportar resoluciones más allá de la HDTV, soporta video estéreo simultáneo y audio 7.1 para un dispositivo de despliegue, lleva a cabo actualizaciones condicionales para cualquier región de la pantalla, y soporta múltiples tipos de datos en ambas direcciones . En. aspectos adicionales de las modalidades de la invención, al menos un controlador de enlace de cliente, o receptor de cliente, está dispuesto en el dispositivo de cliente y se acopla al dispositivo anfitrión a través de la trayectoria o enlace de comunicaciones. El controlador de enlace de cliente también está configurado para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones, y para formar los datos de la presentación digital en uno o más tipos de paquetes de datos . Generalmente, el controlador del anfitrión o el enlace emplean 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 solicitud, pueden utilizar un procesador de propósito general más lento para manipular los datos y algunos de los paquetes menos complejos utilizados en el protocolo de comunicación. El controlador del anfitrión comprende uno o más controladores de línea diferenciales; aunque el receptor del cliente comprende uno o más receptores en línea diferenciales acoplados a la trayectoria de comunicación. Los paquetes se agrupan conjuntamente dentro de tramas de medios que se comunican entre los dispositivos del anfitrión y el cliente que tienen una longitud fija pre-definida con un número pre-determinado de paquetes que tienen diferentes longitudes variables. Los paquetes comprenden cada uno un campo de longitud de paquete, uno o más campos de datos de paquete, y un campo de verificación de redundancia cíclica. Un Paquete de Encabezamiento de Sub-trama se transfiere o se coloca al principio de las transferencias de otros paquetes del controlador del enlace de anfitrión. Uno o más paquetes tipo Corriente de Video y paquetes tipo Corriente de Audio se utilizan mediante el protocolo de comunicaciones para transferir datos de tipo video y datos tipo audio, respectivamente, desde el anfitrión hacia el cliente a través de un enlace sin retorno para su presentación a un usuario del dispositivo de cliente . Uno o más paquetes de tipo Encapsulamiento de Enlace de Retorno se utilizan mediante el protocolo de comunicaciones para transferir datos del dispositivo de cliente al controlador del enlace de anfitrión. Esa transferencia en algunas modalidades incluye la transferencia de datos de los controladores internos que tienen al menos un dispositivo MDDI para pantallas de video internas. Otras modalidades incluyen la transferencia a sistema de sonido interno, y transfiere desde varios dispositivos de entrada que incluyen palancas de mando y teclados complejos para dispositivos internos del anfitrión. Los paquetes tipo relleno se generan mediante el controlador de enlace de anfitrión para ocupar periodos de transmisión en el enlace sin retorno que no tienen datos. Se utiliza una pluralidad de otros paquetes mediante el protocolo de' comunicaciones para transferir información de video. Tales paquetes incluyen el Mapa de Colores, Transferencia en Bloque de Bit, Relleno de Área de Mapa de Bits, Relleno de Patrón de Mapa de Bits y paquetes tipo Habilitar Color Transparente. Los paquetes tipo Corriente Definida por el Usuario se utilizan mediante el protocolo de comunicaciones para transferir datos definidos por la interfaz-usuario. Los datos del teclado y los paquetes tipo Datos del Dispositivo de Señalamiento se utilizan mediante el protocolo de comunicaciones para transferir datos hacia o desde los dispositivos de entrada del usuario asociados con el dispositivo de cliente. Un paquete tipo Cierre de Enlace se utiliza mediante el protocolo de comunicaciones para terminar la transferencia de datos en cualquier dirección a través de la trayectoria de comunicación. La trayectoria de comunicación generalmente comprende o emplea un cable que tiene una serie de cuatro o más conductores y un blindaje. Además, si se desea pueden utilizarse cables o conductores impresos, con algunos sustratos residentes o flexibles. El controlador del enlace de anfitrión despliega las capacidades de información del dispositivo de cliente para determinar qué tipo de datos y velocidades de datos es capaz de ajustar el cliente a través de la interfaz. El controlador de enlace de cliente se comunica con el despliegue o las capacidades de presentación para el controlador del enlace de anfitrión que utiliza al menos un paquete tipo Capacidad de Cliente. Los modos de transferencia múltiples se utilizan mediante el protocolo de comunicaciones con cada uno permitiendo la transferencia de números de bits máximos diferentes de datos en paralelo a través de un periodo de tiempo determinado, con cada modo seleccionable mediante la negociación entre los controladores de enlace de anfitrión y el cliente. Esos modos de transferencia se pueden ajustar dinámicamente durante la transferencia de datos, y no necesita utilizarse el mismo modo en el enlace de retorno como se utilizan en el enlace sin retorno. En otros aspectos de algunas modalidades de la invención, el dispositivo de anfitrión comprende un dispositivo de comunicaciones inalámbrico, tal como un teléfono inalámbrico, una PDA inalámbrica, o una computadora portátil que tiene un módem inalámbrico dispuesto en la misma. Un dispositivo típico del cliente 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 anfitrión puede utilizar el medio o los elementos de almacenamiento para almacenar la presentación o los datos multimedia que se van a transferir para ser presentados a un usuario de dispositivo de cliente. En aún otros aspectos de algunas modalidades, el dispositivo de anfitrión comprende un controlador o un dispositivo de control del enlace de comunicación con controladores como se describe a continuación que reside dentro de un dispositivo electrónico portátil tal como un dispositivo de comunicaciones inalámbrico, tal como un teléfono inalámbrico, una PDA inalámbrica, o una computadora portátil. Un dispositivo típico del cliente en esta configuración comprende un circuito del cliente o un circuito integrado o un módulo acoplado al anfitrión y que reside dentro del mismo dispositivo, y a un despliegue de video interno 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 algún tipo alternativo de sistema o dispositivo de entrada.

BREVE DESCRIPCIÓN DE LOS DIBUJOS A continuación se describen con detalle características y ventajas adicionales de la invención, así como la estructura y la operación de diversas modalidades de la invención, con referencia a los dibujos anexos. En los dibujos, los números de referencia similares generalmente indican elementos o etapas de procesamiento idénticos, funcionalmente similares, y/o estructuralmente similares, y el dibujo en el cual un primer elemento como se indicó mediante el o los dígitos más a la izquierda en el número de referencia. La FIGURA 1A ilustra un ambiente básico en el cual las 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 cual las 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 1C ilustra un ambiente básico en el cual las modalidades de la invención podrían operar incluyendo el uso de dispositivos de presentación de pantalla o audio internos utilizados en una computadora portátil . La FIGURA ID ilustra un ambiente básico en el cual las modalidades de la invención podrían operar incluyendo el uso de elementos de presentación de pantalla o audio internos utilizados en un transceptor inalámbrico. La FIGURA 2 ilustra el concepto global de una Interfaz de Datos Digital Móvil con una interconexión anfitrión y cliente. La FIGURA 3 ilustra la estructura de un paquete útil para realizar transferencias de datos desde un dispositivo de cliente a un dispositivo anfitrión. La FIGURA 4 ilustra el uso de un controlador de enlace MDDI y los tipos de señales que pasan entre un anfitrión y un cliente a través de conductores de enlace de datos físicos para una interfaz mixta Tipo 1. La FIGURA 5 ilustra el uso de un controlador de enlace MDDI y los tipos de señales que pasan entre un anfitrión y un cliente a través de conductores de enlace de datos físicos para las interfaces Tipos 2, 3, y 4. La FIGURA 6 ilustra la estructura de tramas y sub-tramas utilizadas para implementar el protocolo de la interfaz. La FIGURA 7 ilustra la estructura general de paquetes utilizada para implementar el protocolo de la interfaz . La FIGURA 8 ilustra el formato de un Paquete de Encabezamiento de Sub-trama. La FIGURA 9 ilustra el formato y el contenido de un Paquete Rellenador. La FIGURA 10 ilustra el formato de un Paquete de Corriente de Video . Las FIGURAS 11A-11E ilustran el formato y el contenido para el Descriptor de Formatos de Datos de Video utilizado en la FIGURA 10. La FIGURA 12 ilustra el uso de formatos empaquetados y desempaquetados para los datos . La FIGURA 13 ilustra el formato de un Paquete de Corriente de Audio . La FIGURA 14 ilustra el uso de formatos byte alineados y empaquetados PCM para datos. La FIGURA 15 ilustra el formato de un Paquete de Corriente Definida por el Usuario. La FIGURA 16 ilustra el formato de un Paquete de Mapa de Color. La FIGURA 17 ilustra el formato de un Paquete de Encapsulamiento de Enlace de Retorno. La FIGURA 18 ilustra el formato de un Paquete de Capacidad de cliente. La FIGURA 19 ilustra el formato de un Paquete de Datos del Teclado. La FIGURA 20 ilustra el formato de Paquete de Datos del Dispositivo de Señalamiento. La FIGURA 21 ilustra el formato de un Paquete de Interrupción de Enlace . La FIGURA 22 ilustra el formato de un Paquete de Solicitud del Cliente y un Paquete de Estado. La FIGURA 23 ilustra el formato de un Paquete de Transferencia en Bloque de Bits . La FIGURA 24 ilustra el formato de un Paquete de Relleno de Área del Mapa de Bits . La FIGURA 25 ilustra el formato de un Paquete de Relleno del Patrón del Mapa de Bits.

La FIGURA 26 ilustra el formato de un Paquete del Canal de Datos del Enlace de Comunicación. La FIGURA 27 ilustra el formato de un Paquete de Solicitud de Transferencia Tipo Interfaz. La FIGURA 28 ilustra el formato de un Paquete de Reconocimiento Tipo Interfaz . La FIGURA 29 ilustra el formato de un Paquete de Transferencia Tipo Ejecución. La FIGURA 30 ilustra el formato de un Paquete que Posibilita el Canal de Audio Sin Retorno. La FIGURA 31 ilustra el formato de un Paquete de Velocidad de Muestra de Audio de Retorno. La FIGURA 32 ilustra el formato de un Paquete por Encima de la Protección del Contenido Digital . La FIGURA 33 ilustra el formato de un Paquete que Posibilita el Color Transparente. La FIGURA 34 ilustra el formato de un Paquete de Medición de Retraso de Ida y Retorno. La FIGURA 35 ilustra el cronometraje de los eventos durante el Paquete de Medición de Retraso de Ida y Retorno . La FIGURA 36 ilustra una implementación de muestra de un generador CRC y un verificador útil para implementar la invención. La FIGURA 37A ilustra el cronometraje de las señales CRC del aparato de la FIGURA 36 cuando envía paquetes de datos . La FIGURA 37B ilustra el cronometraje de las señales CRC para el aparato de la FIGURA 36 cuando recibe paquetes de datos . La FIGURA 38 ilustra las etapas de procesamiento para una solicitud . de servicio típica sin conflicto de línea. La FIGURA 39 ilustra las etapas de procesamiento para una solicitud de servicio típica afirmada después de que ha iniciado la secuencia de reinicio del enlace, que está en conflicto de línea con el inicio del enlace. La FIGURA 40 ilustra cómo puede transmitirse una secuencia de datos utilizando una codificación DATA-STB. La FIGURA 41 ilustra un sistema de circuitos eléctricos útil para generar DATA y las señales STB de la entrada de datos en el anfitrión, y luego recuperar los datos en el cliente. La FIGURA 42 ilustra los controladores y los resistores de terminación útiles para implementar una modalidad. La FIGURA 43 ilustra las etapas y los niveles de señal empleados por un cliente para asegurar el servicio del anfitrión y mediante el anfitrión para proporcionar tal servicio.

La FIGURA 44 ilustra la separación relativa entre las 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 la respuesta que puede ocurrir cuando un anfitrión deshabilita el controlador del anfitrión después de transferir un paquete . La FIGURA 46 ilustra la presencia de un retraso en la respuesta que puede ocurrir cuando un anfitrión habilita al controlador del anfitrión para transferir un paquete . La FIGURA 47 ilustra la relación en la entrada del receptor del anfitrión entre el cronometraje de los datos que se transfieren y los- bordes anterior y pasante de los pulsos estroboscópicos . La FIGURA 48 ilustra las características de conmutación y el retraso de salida del cliente correspondiente desarrollado por el cronometraje de los datos de retorno. La FIGURA 49 ilustra un diagrama de nivel alto de las etapas de procesamiento de señal y las condiciones mediante las cuales puede implementarse la sincronización que utiliza una máquina de estado. La FIGURA 50 ilustra cantidades típicas de retraso que se encuentran para el procesamiento de la señal en las trayectorias sin retorno y retorno en un sistema que emplea la MDDI . La FIGUR 51 ilustra una medición de retraso de de ida y retorno marginal . La FIGURA 52 ilustra los cambios en la velocidad de datos del Enlace de Retorno. La FIGURA 53 ilustra una representación gráfica de los valores del Divisor de Velocidad de Retorno contra una velocidad de datos del enlace sin retorno. Las FIGURAS 54A y 54B ilustran las etapas que se llevan a cabo en la operación de una interfaz . La FIGURA 55 ilustra una vista global de los paquetes de procesamiento del aparato de la interfaz. La FIGURA 56 ilustra el formato de un Paquete de Enlace sin Retorno. La FIGURA 57 ilustra valores típicos para el retraso y sesgo de propagación en una interfaz de Enlace Tipo 1. La FIGURA 58 ilustra los Datos, Stb y el Cronometraje de Recuperación de Medir el Tiempo en un Enlace Tipo 1 para un procesamiento de señal ejemplar a través de la interfaz . La FIGURA 59 ilustra valores típicos de retraso y sesgo de propagación en interfaces Enlace del Tipo 2, Tipo 3 o Tipo 4.

Las FIGURAS 60A, 60B y 60C ilustran diferentes posibilidades para el cronometraje de dos señales de datos y MDDI_Stb con respecto de una a otra, que son ideales, tempranas, y tardías, respectivamente. La FIGURA 61 ilustra conectores ejemplares de asignaciones de alfiler de interfaz utilizados con interfaces Tipo l/Tipo 2. Las FIGURAS 62A y 62B ilustran formas de onda posibles de MDDI_Data y MDDI_Stb tanto para las interfaces Tipo 1 y Tipo 2, respectivamente. La FIGURA 63 ilustra un diagrama de nivel elevado de etapas y condiciones de procesamiento de señal alternativas mediante las cuales puede implementarse la sincronización utilizando una máquina de estado. La FIGURA 64 ilustra un cronometraje relativo ejemplar entre una serie de ciclos de medir el tiempo y el cronometraje de diversos bits de paquete de enlace de retorno y valores de divisor. La FIGURA 65 ilustra un procesamiento" de transferencia de código de error ejemplar. La FIGURA 66 ilustra un aparato útil para el procesamiento de transferencia del código de error. La FIGURA 67A ilustra un procesamiento de transferencia de código de error para una sobrecarga de código.

La FIGURA 67B ilustra un procesamiento de transferencia de código de error para una recepción de código . La FIGUR 68A ilustra las etapas de procesamiento para una llamada despertadora iniciada por el anfitrión. La FIGURA 68B ilustra las etapas de procesamiento para una llamada despertadora iniciada por el cliente. La FIGURA 68C ilustra las etapas de procesamiento para una llamada despertadora iniciada por el anfitrión y el cliente con conflicto de línea. La FIGURA 69 ilustra el formato de una Solicitud de Paquete de Característica VCP. La FIGURA 70 ilustra el formato de un Paquete de Respuesta de Característica VCP. La FIGURA 71 ilustra el formato de una Lista de Respuesta de Característica VCP. La FIGURA 72 ilustra el formato de un Juego de Paquete de Característica VCP. La FIGURA 73 ilustra el formato de una Solicitud de Paquete de Parámetro Válido. 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 Imagen Alfa-Cursor. La FIGURA 76 ilustra el formato de un Paquete de Mapa de Transparencia Alfa-Cursor. La FIGURA 77 ilustra el formato de un Paquete de Desplazamiento de Imagen Alfa-Cursor. La FIGURA 78 ilustra el formato de un Paquete de Corriente de .Video Alfa-Cursor. La FIGURA '79 ilustra el formato de un Paquete de Capacidad de Corriente de Video Escalado. La FIGURA 80 ilustra el formato de un Paquete de Instalación de Corriente de Video Escalado . La FIGURA 81 ilustra el formato de un Paquete de Reconocimiento de Corriente de Video Escalado. La FIGURA 82 ilustra el formato de un Paquete de corriente de Video Escalado . La FIGURA 83 ilustra el formato de un Paquete de Estado Específico de la Solicitud. La FIGURA 84 ilustra el formato de un Paquete de Lista de Respuesta de Estado Válido. La FIGURA 85A ilustra el formato de un Paquete de Parámetros de Retraso del Procesamiento. La FIGURA 85B ilustra el formato de un Artículo de Lista de Parámetros del Retraso. La FIGURA 86 ilustra el formato de un Paquete de Capacidad de Despliegue Personal . La FIGURA 87A ilustra el formato de un Paquete de Reporte de Error del Cliente.

La FIGURA 87B ilustra el formato de un Artículo de la Lista del Reporte de Error. La FIGURA 88 ilustra el formato de un Paquete de Identificación del Cliente. La FIGURA 89 ilustra el formato de un Paquete de Capacidad de Despliegue Alterno. La FIGURA 90 ilustra el formato de un Paquete de Acceso de Registro. Las FIGURAS 91A-91C ilustran el uso de dos memorias intermedias de despliegue para reducir los artefactos visibles . La FIGURA 92 ilustra dos memorias intermedias con una renovación de despliegue más rápida que la transferencia de imagen. La FIGURA 93 ilustra dos memorias intermedias con una renovación de despliegue más lenta que la transferencia de imagen. La FIGURA 94 ilustra dos memorias intermedias con renovación de despliegue mucho más rápida que la transferencia de imagen. La FIGURA 95 ilustra tres memorias intermedias con renovación de despliegue más rápida que la transferencia de imagen. La FIGURA 96 ilustra tres memorias intermedias con renovación de despliegue más lenta que la transferencia de imagen. La FIGURA 97 ilustra una memoria intermedia con renovación de despliegue más rápida que la transferencia de imagen. La FIGURA 98 ilustra la conexión anfitrión cliente a través de una cadena daisy y un centro nodal . La FIGURA 99 ilustra dispositivos del cliente conectados a través de una combinación de centros nodales y cadenas daisy. La FIGURA 100 ilustra un mapa de color. La FIGURA 101 ilustra un análisis de corriente de fugas .

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN I. Vista general Un intento general de la invención es proporcionar una Interfaz Digital de Despliegue Móvil (MDDI) , como se discute a continuación, la cual da por resultado o proporciona un mecanismo de transferencia efectivo en costos, de bajo consumo de energía eléctrica que posibilita una transferencia de datos de rapidez elevada o muy elevada a través de un enlace de comunicación de corto alcance entre un dispositivo de anfitrión y un dispositivo de cliente, tal como un elemento de despliegue, utilizando un enlace o canal de datos tipo "en serie" este mecanismo se presta para su implementación con conectores en miniatura y cables flexibles delgados que son especialmente útiles al conectar elemento de despliegue interno (a un alojamiento o armazón de soporte) o dispositivos de entrada a un controlador central, o elementos de despliegue externo o dispositivos tales como micro-pantallas que pueden llevarse puestos (gogles o proyectores) para computadoras portátiles, dispositivos de comunicación inalámbricos, o dispositivos de entretenimiento. Aunque los términos Móvil y Despliegue se asocian con la denominación del protocolo, se debe entender que esto es por conveniencia solamente en términos de tener un nombre estandarizado que sea fácilmente entendido por quienes tienen experiencia en la técnica que trabajan con la interfaz y el protocolo. Sin embargo, se entenderá con facilidad después de que se revisen las modalidades presentadas a continuación en las que muchas aplicaciones relacionadas no móviles y de no despliegue se beneficiarán de la aplicación de este protocolo y de la estructura de la interfaz resultante, y la etiqueta MDDI no pretende implicar ninguna limitación a la naturaleza o utilidad de la invención o sus diversas modalidades. Una ventaja de las modalidades de la invención es que se proporciona una técnica para la transferencia de datos que es baja en complejidad, de costo bajo, tiene una elevada confiabilidad, se ajusta bien dentro del ambiente de uso, y es muy sólida, aunque permanece muy flexible. Las modalidades de la invención pueden utilizarse en una variedad de situaciones para comunicar o transferir enormes cantidades de datos, generalmente para audio, video o aplicaciones multimedia a partir de un anfitrión o dispositivo o fuente en donde se generan o se almacenan tales datos, para un despliegue de cliente o un dispositivo de presentación a una velocidad elevada. Una aplicación típica, la cual se discute a continuación, es la transferencia de datos desde ya sea una computadora portátil o un teléfono o módem inalámbrico a un dispositivo de despliegue visual tal como una pantalla de video pequeña o un electrodoméstico de micro-pantalla que puede llevarse puesto, tal como en forma de unos gogles o casos que contengan lentes o pantallas de proyección pequeñas, o a partir de un dispositivo de anfitrión al cliente dentro de tales componentes. Es decir, a partir de un procesador hacia una pantalla interna u otro elemento de presentación, así como a partir de diversos dispositivos de entrada internos o externos que emplean a un cliente para un anfitrión localizado internamente (colocado dentro del mismo alojamiento del dispositivo o estructura de soporte) . Las características o atributos de la MDDI son tales que son independientes de la tecnología de despliegue o presentación específica. Éste es un mecanismo altamente flexible para transferir datos a una velocidad elevada sin considerar la estructura interna de esos datos, ni los aspectos funcionales de los datos o los comandos que implementa. Esto permite un cronometraje de los paquetes de datos que se transfieren para ajustarlos para adaptarlos a las idiosincrasias de los dispositivos particulares del cliente, tales como para deseos de despliegues únicos, para ciertos dispositivos, o para cumplir con los requerimientos de audio y video combinados para algunos sistemas A-V o para ciertos dispositivos de entrada tales como palancas de mando, pantallas táctiles, etc. La interfaz es el elemento de despliegue mismo o el agnóstico del dispositivo de cliente, siempre y cuando se siga el protocolo seleccionado. Además, los datos del enlace en serie agregados, o velocidad de datos, pueden variar durante diversas órdenes de magnitud lo cual permite un sistema de comunicación dispositivo o diseñador del dispositivo de anfitrión para que optimice el costo, los requerimientos de energía eléctrica, la complejidad del dispositivo de cliente, y las velocidades de actualización del dispositivo de cliente. La interfaz de datos se presenta principalmente para utilizarla en la transferencia de enormes cantidades de datos de velocidad elevada a través de un enlace de señal . "hilos" o cable pequeño. Sin embargo, algunas aplicaciones pueden sacar ventaja de un enlace inalámbrico también, incluyendo enlaces basados en la óptica, siempre que esté configurado para utilizar las misma estructuras de paquete y datos desarrollados para el protocolo de la interfaz, y puedan sostener el nivel deseado de transferencia en un consumo de energía eléctrica lo suficientemente bajo o de una complejidad que continúe siendo practica.

II . Ambiente Una aplicación típica puede verse en las FIGURAS 1A y IB en donde se muestran una computadora 100 laptop o portátil y un teléfono inalámbrico o dispositivo 102 PDA que comunican datos con los dispositivos 104 y 106 de despliegue, respectivamente, junto con sistemas 108 y 112 de reproducción de audio. Además, la FIGURA 1A muestra las conexiones potenciales para un despliegue o pantalla 114 más grande o un proyector 116 de imagen, los cuales se muestran solamente en una figura para claridad, aunque se pueden conectar al dispositivo 102 inalámbrico también. El dispositivo inalámbrico puede actualmente recibir datos o tener almacenados previamente una cierta cantidad de datos tipo multimedia en un elemento o dispositivo de memoria para una presentación posterior para visualizar y/o escuchar por un usuario final del dispositivo inalámbrico. Dado que un dispositivo inalámbrico típico se utiliza para comunicaciones de voz y de texto simple la mayor parte del tiempo, tiene más bien una pantalla de despliegue pequeña y un sistema de audio simple (altavoces) para comunicar la información al dispositivo 102 de usuario. La computadora 100 tiene una pantalla mucho más grande, aunque es aún inadecuada para un sistema de sonido externo, y se queda incluso corta para otros dispositivos de presentación multimedia tales como una televisión de alta definición, o pantallas para películas. La computadora 100 se utiliza para propósitos de ilustración y también pueden utilizarse con la invención otros tipos de procesadores, juegos de video interactivos o dispositivos electrónicos del consumidor. La computadora 100 puede emplear, aunque no se limita a éste o mediante éste, un módem inalámbrico u otro dispositivo integrado para las comunicaciones inalámbricas, o puede conectarse a tales dispositivos utilizando un enlace de cable o inalámbrico, según se desee . Esto hace que la presentación de datos más complejos o "ricos" sea menor que una experiencia útil o agradable. Por lo tanto, la industria está desarrollando otros mecanismos y dispositivos para presentar la información a los usuarios finales y para proporcionar un nivel mínimo de goce deseado o experiencia positiva. Como se discutió previamente en lo anterior, diversos tipos de dispositivos de despliegue tienen o se están actualmente desarrollando para presentar información a los usuarios finales del dispositivo 100. Por ejemplo, una o más compañías han desarrollado juegos de gogles que pueden llevarse puestos que proyectan una imagen enfrente de los ojos de un dispositivo de usuario para presentar un despliegue visual. Cuando están colocados correctamente tales dispositivos efectivamente "proyectan" una imagen virtual, tal como se percibe mediante los ojos de los usuarios, es decir mucho más grande de lo que proporciona elemento de salida visual. Es decir, un elemento de proyección muy pequeño permite que el o los ojos del usuario "vean" imágenes a una escala mucho más grande de lo que es posible con pantallas de LCD típicas y similares. El uso de imágenes en pantalla virtual más grandes también permite el uso de imágenes de una resolución mucho más alta de lo posible con despliegues de pantalla de LCD más limitados. Otros dispositivos de despliegue podrían incluir, aunque no limitarse a éstos, pantallas de LCD pequeñas de diversos elementos de despliegue de panel plano, lentes de proyección y controladores de despliegue para proyectar imágenes en una superficie, etc.

Puede haber también elementos adicionales conectados o asociados con el uso de un dispositivo 102 inalámbrico o una computadora 100 para presentar una salida a otro usuario, o a otro dispositivo que a su vez transfiere las señales a cualquier parte o las almacena. Por ejemplo, los datos pueden almacenarse en una memoria no volátil, en forma óptica, por ejemplo utilizando un medio de CD escribible o en un medio magnético tal como una grabadora de cinta magnética y dispositivos similares, para su uso posterior. Además, muchos dispositivos y computadoras inalámbricos tienen ahora capacidades de descodificación de música MP3 integrada, así como otros descodificadores y sistemas de sonido avanzados. Las computadoras portátiles utilizan capacidades de reproducción CD y DVD como regla general, y algunas tienen lectores de memoria no volátil pequeños dedicados para recibir archivos de audio pre-grabados . El problema con tener tales capacidades es que los archivos de música digital prometen una experiencia rica en características altamente incrementadas, pero solamente si el proceso de descodificación y reproducción puede mantener el ritmo. Lo mismo es válido para los archivos de video digital . Para ayudar con la reproducción de sonido, se muestran altavoces 114 externos en la FIGURA 1A, que pueden también estar acompañados por elementos de adición tales como altavoces "de sonido envolvente" o altavoz para infragraves para una proyección frontal y posterior del sonido. Al mismo tiempo, los altavoces o audífonos 108 están indicados como integrados para el armazón o mecanismo de soporte del dispositivo 106 de micro-pantalla de la FIGURA IB. Como se conoce, pueden utilizarse otros elementos de reproducción de audio o sonido que incluyen amplificación de potencia o dispositivos modeladores de sonido. En cualquier caso, como se discutió anteriormente, cuando se desea transferir datos de imagen de alta calidad o alta resolución e información o señales de datos de audio de alta calidad desde una fuente de datos hasta un usuario final a través de uno o más enlaces 110 de comunicación, se requiere una velocidad de datos elevada. Es decir, el enlace 110 de transferencia es claramente un potencial cuello de botella en la comunicación de datos como se discutió al inicio, y limita el desempeño del sistema, dado que los mecanismos de transferencia actuales no alcanzan las velocidades de datos elevadas que típicamente se desean. Como se discutió anteriormente por ejemplo, para resoluciones de imagen más altas tales como 1024 por 1024 pixeles, con profundidades de color de 24-32 bits por pixel y a velocidades de datos de 30 fps, las velocidades de datos pueden aproximarse a velocidades que exceden los 755 Mbps o más. Además, tales imágenes pueden presentarse como parte de una presentación multimedia que incluye datos de audio y potencialmente señales adicionales que tienen que ver con juegos o comunicaciones interactivas, o varios comandos, controles o señales, que además incrementan la cantidad de datos y la velocidad de datos . También es claro que pocos cables o interconexiones que se requieran para establecer un enlace de datos significa que los dispositivos móviles asociados con un despliegue son más fáciles de utilizar, y que es más probable que sean adoptados por una base de usuarios más grande. Esto es especialmente verdadero cuando se utilizan en forma común múltiples dispositivos para establecer una experiencia audiovisual completa, y más especialmente ya que el nivel de calidad de los despliegues de los dispositivos de salida de audio se incrementa. Otra aplicación típica relacionada con muchas de las anteriores y otras mejoras en las pantallas de video y otros dispositivos de salida o entrada pueden verse en las FIGURAS 1C y ID en donde una computadora 130 laptop o portátil y un teléfono inalámbrico o un dispositivo 140 PDA se muestran comunicando datos con dispositivos 134 y 144 de despliegue "internos", respectivamente, junto con sistemas 136 y 146 de reproducción de audio. En las FIGURAS 1C y ID, las secciones pequeñas en recorte de los dispositivos o productos electrónicos en general se utilizan para mostrar la ubicación de uno o más anfitriones y controladores internos en una porción del dispositivo con un enlace de comunicación generalizado, aquí 138 y 148, respectivamente, conectándolos con los elementos o pantallas de despliegue de video que tienen los clientes correspondientes, a través de una unión rotatoria de algún tipo conocido utilizada a través de toda la industria de la electrónica en la actualidad. Puede verse que la cantidad de datos implicados en esas transferencias requieren un enorme número de conductores para comprender los enlaces 138 y 148. Se estima que tales enlaces de comunicación se aproximan a 90 o más conductores para satisfacer las necesidades de crecimiento actuales para utilizar interfaces de color y de gráficos avanzadas, elementos de despliegue, en tales dispositivos debido a los tipos de técnicas de interfaz paralelas u otras conocidas disponibles para transferir tales datos. Desafortunadamente, las velocidades de datos más elevadas exceden la tecnología actual disponible para transferir datos, tanto en términos de la cantidad de datos en estado primario que son necesarios transferirse por unidad de tiempo, como en términos de mecanismos de transferencia físicos efectivos en costos y confiables en su fabricación. Lo que es necesario es una técnica, una estructura, un medio o método, para transferir datos a velocidades más elevadas para el enlace o la trayectoria de comunicación de transferencia de datos entre los elementos de presentación y la fuente de datos, que permita una potencia consistentemente baja (o más baja) de peso ligero, y que sea simple y económica en su estructura de cableado hasta donde sea posible. Se ha desarrollado una nueva técnica o método y aparato, para alcanzar esas y otras metas para permitir una serie de dispositivos de ubicación móvil, portátil o incluso fijos para transferir datos a elementos de transferencia de audio o micro-pantallas, pantallas deseadas a velocidades de datos muy elevadas, aunque se mantiene un consumo de energía eléctrica bajo deseado y complejidad.

III. Arquitectura de un Sistema de Interfaz de Datos Digital de Velocidad Elevada Para crear y utilizar eficientemente una nueva interfaz de dispositivo, se ha formulado un protocolo y arquitectura de sistema de señal que proporciona una velocidad de transferencia de datos muy elevada utilizando señales de baja potencia. El protocolo se basa en un paquete y una estructura de trama, o estructuras enlazadas juntas para formar un protocolo para comunicar un conjunto de datos pre-seleccionado o tipos de datos junto con un comando o una estructura operacional impuesta a la interfaz .

A. Vista General Los dispositivos conectados mediante o que se comunican a través del enlace MDDI se llaman anfitrión y cliente, siendo el cliente típicamente un dispositivo de despliegue de algún tipo, aunque se contemplan otros dispositivos de entrada y salida. Los datos del anfitrión que se van a desplegar viajan en una dirección sin retorno (a lo que se hace referencia como en tráfico o enlace sin retorno) , y los datos del cliente hacia el anfitrión viajan en una dirección de retorno (tráfico o enlace de retorno) , según lo habilite el anfitrión. Esto se ilustra en la configuración básica mostrada en la FIGURA 2. En la FIGURA 2, un anfitrión 202 se conecta a un cliente 204 utilizando un canal 206 de comunicación bi-direccional que se ilustra comprendiendo un enlace 208 sin retorno y un enlace 210 de retorno. Sin embargo, esos canales se forman mediante un conjunto común de conductores cuya transferencia de datos se conmuta efectivamente entre las operaciones de enlace - sin retorno o de retorno. Esto posibilita reducir enormemente el número de conductores, direccionando inmediatamente uno de muchos problemas que se enfrentan con las metodologías actuales para la transferencia de datos de rapidez elevada en ambientes de baja potencia tales como para los dispositivos electrónicos móviles. Como se ha discutido antes, el anfitrión comprende uno de diversos tipos de dispositivos que pueden beneficiarse de la utilización de la presente invención. Por ejemplo, el anfitrión 202 podría ser una computadora portátil en la forma de un dispositivo de cómputo móvil portátil, una laptop, o similar. Puede ser también un Asistente de Datos Personal (PDA) , un dispositivo radio localizador, o uno de muchos teléfonos módem inalámbricos. Alternativamente, el anfitrión 202 podría ser un dispositivo de entretenimiento o presentación portátil tal como un reproductor de DVD o de CD portátil, o un dispositivo para jugar juegos. Además, el anfitrión puede residir como un dispositivo anfitrión o elemento de control en una variedad de otros productos ampliamente utilizados o comercialmente planeados para los cuales se desea un enlace de comunicación de rapidez elevada con un cliente. Por ejemplo, un anfitrión podría utilizarse para transferir datos a velocidades elevadas desde un dispositivo de grabación de video a un cliente que se basa en un almacenamiento para una respuesta mejorada, o para una pantalla más grande de alta resolución para presentaciones . Un electrodoméstico tal como un refrigerador que incorpora un inventario a bordo o un sistema de cómputo y/o conexiones Bluetooth a otros dispositivos domésticos, pueden tener capacidades de despliegue mejoradas cuando se operan en un modo conectado a Internet o Bluetooth, o tienen necesidades de cableado reducidas para despliegues en la puerta (un cliente) y teclados o escáneres (cliente) mientras que la computadora electrónica o los sistemas de control (anfitrión) residen en cualquier parte en el gabinete. En general, quienes tienen experiencia en la técnica apreciarán la amplia variedad de dispositivos y electrodomésticos electrónicos modernos que pueden beneficiarse del uso de esta interfaz, así como de la capacidad para adaptar dispositivos antiguos con una velocidad de transporte de información de datos más elevada que utiliza números limitados de conductores disponibles ya sea recientemente agregados o en conectores que ya existen o cables. Al mismo tiempo el cliente 204 podría comprender una variedad de dispositivos útiles para presentar información a un usuario final, o presentar información de un usuario al anfitrión. Por ejemplo, una micro-pantalla incorporada en goggles o anteojos, un dispositivo de proyección incorporado en un sombrero o en un casco, una pequeña pantalla o incluso un elemento holográfico incorporado dentro de un vehículo, tal como una ventana o un parabrisas, o diversos altavoces, audífonos o sistemas de sonido para presentar sonido o música de alta calidad. Otros dispositivos de presentación incluyen proyectores o dispositivos de proyección utilizados para presentar información para reuniones, o para películas e imágenes de televisión. Otro ejemplo sería el uso de dispositivos sensibles o tablilla tacto sensible, dispositivos de entrada de reconocimiento de voz, escáneres de seguridad, etc. a los cuales se puede acudir para transferir una cantidad significativa de información desde un dispositivo o sistema de usuario con pocos "ingresos" reales de un toque o un sonido de usuario. Además, las estaciones de acoplamiento para las computadoras y los juegos de accesorios para un auto o los juegos de accesorios de escritorio y los sujetadores para teléfonos inalámbricos pueden actuar como dispositivos de interfaz para los usuarios finales o para otros dispositivos y equipo, y emplear ya sea a los clientes o a los anfitriones (dispositivos de entrada y salida tales como un ratón) para ayudar en la transferencia de datos, especialmente en donde están involucradas redes de rapidez elevada. Sin embargo, quienes son expertos en la técnica fácilmente reconocerán que la presente invención no se limita a esos dispositivos, existen muchos otros dispositivos en el mercado, y se proponen para su uso, que pretenden proporcionar a los usuarios finales con imágenes y sonido de alta calidad, ya sea en términos de almacenamiento y transporte o en términos de presentación en la reproducción. La presente invención es útil para incrementar el rendimiento total de datos entre diversos elementos o dispositivos para ajustar las velocidades de datos elevadas necesarias para realizar la experiencia deseada por el usuario. La Interfaz MDD inventiva y el protocolo de señal de comunicación pueden utilizarse para simplificar la interconexión entre un procesador anfitrión, un controlador o un componente de circuito (por ejemplo) , y una pantalla dentro de un dispositivo o un alojamiento o estructura de dispositivo (a la que se hace referencia como un modo interno) para reducir el costo o la complejidad y los requerimientos de energía eléctrica y control asociados o las restricciones de esas conexiones, y para mejorar la confiabilidad, no sólo para su conexión a, o para elementos, dispositivos o equipos externos (a los qué se hace referencia como modo externo) . La velocidad de datos del enlace en serie agregada en cada par de señal utilizada para esta estructura de interfaz puede variar en muchos órdenes de magnitud, lo cual permite a un diseñador de un sistema o de un dispositivo fácilmente optimizar el costo, la energía eléctrica, la complejidad de implementación y la velocidad de actualización del despliegue para una aplicación o propósito determinado. Los atributos de la MDDI son independientes del despliegue u otra tecnología de dispositivo de presentación (cliente objetivo) . El cronometraje de los paquetes de datos transferidos a través de la interfaz puede fácilmente ajustarse para adaptarse a idiosincrasias de clientes particulares tales como los dispositivos de despliegue, los sistemas de sonido, de memoria y elementos de control, o combinar los requerimientos de cronometraje de los sistemas de audio-video. Mientras esto hace posible tener un sistema con un consumo de energía eléctrica muy pequeño, no es un requerimiento de los diversos clientes el tener memorias intermedias de trama para hacer uso del protocolo MDDI al menos hasta cierto nivel .

B. Tipos de Interfaz La Interfaz MDD está contemplada para direccionar al menos cuatro, y potencialmente más, tipos de interfaces físicas un tanto distintas que se encuentran en las comunicaciones y en la industria de cómputo. Éstas se etiquetan simplemente como Tipo 1, Tipo 2, Tipo 3 y Tipo 4, aunque pueden aplicárseles otras etiquetas o designaciones por parte de quienes son expertos en la técnica dependiendo de las aplicaciones específicas que ellos están utilizando para o con la industria con la que se encuentran asociados . Por ejemplo, los sistemas de audio simples utilizan pocas conexiones que los sistemas de multimedia más complejos, y pueden hacer referencia a características tales como "canales" de manera diferente, etc. La interfaz Tipo 1 se configura como un conductor de 6 hilos o de otro tipo, o un elemento conductivo, interfaz que es adecuada para teléfonos móviles o inalámbricos, los PDA, juegos electrónicos y reproductores multimedia portátiles, tales como reproductores de CD, o reproductores de MP3 , y dispositivos similares o dispositivos que se utilizan en tipos similares de tecnología electrónica del consumidor. En una modalidad, una interfaz puede configurarse como una interfaz de 8 hilos (conductor) que es más adecuada para una laptop, libreta electrónica, o computadoras de escritorio personales y dispositivos o aplicaciones similares, que no requieran actualizaciones de datos rápidas y los cuales no tengan un controlador de enlace MDDI integrado. Este Tipo Interfaz también se puede distinguir mediante el uso de una interfaz de Bus en Serie Universal de dos hilos (USB) , que es extremadamente útil para ajustar sistemas de operación existentes o un soporte de software que se encuentra en la mayoría de las computadoras personales . Las interfaces Tipo 2 , Tipo 3 y Tipo 4 son adecuadas para clientes o dispositivos de alto desempeño y utilizan un cableado más complejo y más grande con conductores adicionales tipo por trenzado para proporcionar el blindaje apropiado y transferencias con pérdidas bajas para las señales de datos. La interfaz Tipo 1 pasa las señales que pueden comprender un despliegue, audio, control, e información de señalización limitada, y se utiliza típicamente para clientes móviles o dispositivos de cliente que no requieren datos de video de velocidad máxima de alta resolución. Una interfaz Tipo 1 puede fácilmente soportar una resolución SVGA a 30 fps además de un canal de audio 5.1, y una configuración mínima podría utilizar solamente un total de tres pares de hilos, dos pares para la transmisión de datos y un par para la transferencia de energía eléctrica. Este Tipo Interfaz está destinado principalmente para dispositivos, tales como dispositivos inalámbricos móviles, en donde típicamente no está disponible un anfitrión USB dentro de tal dispositivo para su conexión y transferencia de señales. En esta configuración, el dispositivo inalámbrico móvil es un dispositivo anfitrión MDDI, y actúa como el "control maestro" que controla el enlace de comunicación desde el anfitrión, que generalmente envía los datos al cliente (tráfico o enlace sin retorno) para su presentación, despliegue o reproducción. En esta interfaz, un anfitrión posibilita la recepción de datos de comunicación en el anfitrión desde el cliente (tráfico o enlace de retorno) mediante el envío de un comando especial o un tipo de paquete al cliente que le permita hacerse cargo del bus (enlace) para una duración especificada y envía los datos al anfitrión como paquetes de retorno. Esto se ilustra en la FIGURA 3, en donde un tipo de paquete al que se hace referencia como paquete de encapsulamiento (se discute más adelante) se utiliza para ajustar la transferencia de paquetes de retorno a través del enlace de transferencia, creando el enlace de retorno. El intervalo de tiempo destinado para que el anfitrión sondee al cliente en búsqueda de datos se predetermina mediante el anfitrión, y se basa en los requerimientos de cada aplicación especificada. Este tipo de transferencia de datos bi-direccional semi-dúplex es especialmente ventajoso cuando un puerto USB no se encuentra disponible para transferir la información o los datos desde el cliente. Los dispositivos de alto desempeño capaces del tipo HDTV o de altas resoluciones similares requieren aproximadamente corrientes de datos de una velocidad de 1.5 Gbps para soportar el video de movimiento total . La interfaz Tipo 2 soporta velocidades de datos elevadas mediante la transmisión de 2 bits en paralelo, el Tipo 3 mediante la transmisión de 4 bits en paralelo, y la interfaz de Tipo 4 transfiere 8 bits en paralelo. Las interfaces Tipo 2 y Tipo 3 utilizan el mismo cable y conector como la Tipo 1 pero pueden operar de dos a cuatro veces la velocidad de datos para soportar aplicaciones de video de un desempeño más alto en dispositivos portátiles. Una interfaz Tipo 4 es adecuada para clientes o despliegues de un desempeño muy alto y requiere un cable ligeramente más grande que contiene señales de datos por trenzado. El protocolo utilizado mediante la MDDI permite a cada Tipo 1, 2 3 ó 4 de anfitrión comunicarse generalmente con cualquier Tipo 1, 2, 3 ó 4 de cliente mediante la negociación que es la velocidad de datos más elevada posible que puede utilizarse. Las capacidades o características disponibles a las que puede hacerse referencia como al dispositivo de capacidad mínima se utilizan para establecer el desempeño del enlace. Por regla, incluso para sistemas en donde el anfitrión y el cliente son capaces de utilizar las interfaces Tipo 2, Tipo 3, o Tipo 4, comienzan la operación como una interfaz Tipo 1. El anfitrión determina entonces la capacidad de cliente objetivo, y negocia una operación de transferencia intracelular o de re-configuración ya sea para cualquier modo Tipo 2, Tipo 3 o Tipo 4, según sea lo apropiado para la aplicación en particular. Generalmente es posible para el anfitrión utilizar el protocolo de enlace-capa apropiado (se discute adicionalmente más adelante) y descender o configurar de nuevo la operación generalmente en cualquier momento para un modo más lento para ahorrar energía eléctrica o para ascender a un modo más rápido para soportar transferencias de rapidez más elevada, tales como para un contenido de despliegue de alta resolución. Por ejemplo, un anfitrión puede cambiar los tipos de interfaz cuando el sistema conmuta de una fuente de energía eléctrica tal como una batería a una energía eléctrica CA, o cuando la fuente del medio de despliegue conmuta a un formato de resolución más bajo o más elevado, o una combinación de esas u otras condiciones o eventos puede considerarse como una base para cambiar un Tipo Interfaz, o modo de transferencia. También es posible para un sistema comunicar datos utilizando un modo en una dirección y otro modo en otra dirección. Por ejemplo, un modo de interfaz Tipo 4 podría utilizarse para transferir datos a una pantalla a una velocidad elevada, mientras que un modo Tipo 1 se ' utiliza cuando se transfieren datos a un dispositivo anfitrión desde dispositivos periféricos tales como un teclado o un dispositivo de señalamiento. Alguien con experiencia en la técnica apreciará que los anfitriones y los clientes pueden comunicar datos de salida a velocidades diferentes. A menudo, los usuarios del protocolo MDDI pueden distinguir entre un modo "externo" y un modo "interno" . Un modo externo describe el uso del protocolo y de la interfaz para conectar un anfitrión en un dispositivo a un cliente fuera de ese dispositivo que está hasta aproximadamente 2 metros o algo así desde el anfitrión. En esta situación, el anfitrión puede también enviar la potencia al cliente externo para que ambos dispositivos puedan fácilmente operar en un ambiente móvil . Un modo interno describe cuándo el anfitrión se conecta a un cliente que está contenido dentro del mismo dispositivo, tal como dentro de un alojamiento común o armazón o estructura de soporte de algún 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 un dispositivo de juego en donde el cliente es una pantalla o controlador de pantalla, o un dispositivo de entrada tal como un teclado o una tablilla tacto sensible, o un sistema de sonido, y el anfitrión es un controlador central, un procesador de gráficos o un elemento de CPU. Dado que un cliente se ubica mucho más cerca del anfitrión en aplicaciones de modo interno como opuesto a las aplicaciones de modo externo, generalmente no existen requerimientos que se discutan para la conexión de la energía eléctrica al cliente en tales configuraciones.

C. Estructura de la Interfaz Física La disposición general de un dispositivo o controlador de enlace para establecer comunicaciones entre dispositivos del anfitrión y el cliente se muestra en las FIGURAS 4 y 5. En las FIGURAS 4 y 5, un controlador 402 y 502 del enlace MDDI se muestra instalado en un dispositivo 202 de anfitrión y un controlador 404 y 504 de enlace MDDI se muestra instalado en un dispositivo 204 de cliente. Como antes, el anfitrión 202 se conecta a un cliente 204 utilizando un canal 406 de comunicación bi-direccional que comprende una serie de conductores . Como se discute a continuación, tanto los controladores de enlace de anfitrión como del cliente pueden fabricarse como un circuito integrado utilizando un solo diseño de circuito que puede situarse, ajustarse o programarse para responder ya sea a un controlador del anfitrión (manejador) o a un controlador del cliente (receptor) . Esto hace posible costos más bajos debido a una fabricación a una mayor escala de un solo dispositivo de circuito. En la FIGURA 5, se muestra un controlador 502 de enlace MDDI instalado en un dispositivo 204' de cliente.

Como el anterior, el anfitrión 202' se conecta a un cliente 204' utilizando un canal 506 de comunicación bi-direccional que comprende una serie de conductores. Como se discutió anteriormente, tanto los controladores de enlace de anfitrión como del cliente pueden fabricarse utilizando un solo diseño de circuito. Las señales pasan entre un anfitrión y un cliente, tal como un dispositivo de despliegue, a través del enlace MDDI, o se utilizan los conductores físicos, que también se ilustran en la FIGURAS 4 Y 5. Como puede verse en las FIGURAS 4 y 5, la trayectoria o mecanismo primario para transferir los datos a través de la MDDI utilizan señales de datos etiquetadas como MDDI_DataO+/- y MDDI_Stb+/- . Cada una de esas son señales de datos de bajo voltaje que se transfieren a través de un par de hilos diferenciales en un cable. Sólo hay una transición ya sea en el par MDDI_DataO o el par MDDI-Stb para cada bit enviado a través de la interfaz. Éste es un voltaje que se basa en el mecanismo de transferencia y que no se basa en la corriente, para que el consumo de corriente estática sea casi cero. El anfitrión controla las señales MDDI_Stb en la pantalla del cliente. Aunque los datos pueden fluir en ambas direcciones sin retorno y de retorno a través de los pares MDDI Data, es decir, es una trayectoria de transferencia bi-direccional, el anfitrión es el maestro o controlador del enlace de datos . Las trayectorias de señal MDDI_DataO y MDDI_Stb se operan en un modo diferencial para maximizar la inmunidad al ruido. La velocidad de datos para las señales en esas líneas se determina mediante la velocidad de medir el tiempo enviado por el anfitrión, y es variable a través de un rango de aproximadamente 1 kbps hasta 400 Mbps o más. La interfaz Tipo 2 contiene un par de datos o conductores o trayectorias adicionales más allá que la del Tipo 1, al cual se hace referencia como MDDI_Datall+/- . La interfaz Tipo 3 contiene dos pares de datos o trayectorias de señal adicionales más allá que la de la interfaz Tipo 2 al cual se hace referencia como MDDI_Data2+/-, y MDDI_Data3+/- . La interfaz Tipo 4 contiene cuatro pares de datos o trayectoria de señal más allá que la de la interfaz Tipo 3 al cual se hace referencia como: MDDI_data4+/-, MDDI_Data5+/-, MDDI_Data6+/- y MDDI_Data7+/-respectivamente . En cada una de las configuraciones de interfaz anteriores, un anfitrión puede enviar la potencia al cliente o pantalla utilizando el par de hilos o señales designadas como H0ST_Pwr y H0ST_Gnd. Como se discute adicionalmente a continuación, la transferencia de potencia también puede ajustarse, si se desea, en algunas configuraciones en los conductores MDDI_data4+/-, MDDI Data5+/-, MDDI Data6+/- o MDDI Data7+/- cuando se está utilizando una interfaz de "Tipo" que emplea pocos conductores de los que están disponibles o presentes para los otros modos . Esta transferencia de Potencia generalmente se emplea para modos externos, que generalmente no se necesitan para modos internos, aunque algunas aplicaciones pueden diferir. En la Tabla I se resumen las señales que se pasan entre el anfitrión y el cliente (pantalla) a través del enlace MDDI para diversos modos, a continuación, de acuerdo con el Tipo Interfaz. Tabla I Tipo I Tipo 2 Tipo 3 Tipo 4 H HOOSSTT__PPwr/Gnd HOST_Pwr/Gnd HOST_Pwr/Gnd HOST_Pwr/Gnd MMDDDDII__SStb+/- MDDI_Stb+/- MDDI_Stb+/- MDDI_Stb+/-MDDI Data0+/ MDDI_Data0+/- MDDI_Data0+/- MDDI_DataO+/- MDDI Datal+/- MDDI_Datal+/- MDDI_Datal+/- MDDI_Data2+/- MDDI_Data2+/~ Optional Pwr MDDI_Data3+/- MDDI_Data3+/~ Optional Pwr Optional Pwr Optional Pwr MDDI_Data4+/- Optional Pwr Optional Pwr Optional Pwr MDDI_Data5+/~ Optional Pwr Optional Pwr Optional Pwr MDDI_Data6+/~ Optiona1 Pwr Optional Pwr MDDI Data7+/- También debe hacerse notar que las conexiones HOST_Pwr/Gnd para transferir desde el anfitrión se proporcionan generalmente para modos externos. En aplicaciones o modos internos de operación generalmente se tiene a clientes que extraen la potencia directamente de otros recursos internos, y no utilizan la MDDI para controlar la distribución de energía eléctrica, como puede ser aparente para quien tiene experiencia en la técnica, así que tal distribución no se discute adicionalmente con detalle en la presente. Sin embargo, es ciertamente posible permitir que la energía eléctrica se distribuya a través de la interfaz MDDI para permitir ciertas clases de control de 5 energía eléctrica, sincronización, o por conveniencia de interconexión, por ejemplo, como puede entenderlo alguien que tiene experiencia en la técnica. El cableado que generalmente se utiliza para implementar la anterior estructura y su operación está . nominalmente en el orden de los 1.5 metros de longitud, generalmente de 2 metros o menos, y contiene tres pares de conductores trenzados, cada uno a su vez es un hilo de muíti-prensado 30 AWG. Una cubierta de blindaje de lámina se enrolla o se forma de otra manera por encima de los tres pares trenzados, como un hilo de drenado adicional. Los pares trenzados y el conductor de blindaje de drenado terminan en el conector del Cliente con el blindaje conectado al blindaje del cliente, y existe una capa aislante, que cubre todo el cable, como se conoce bien en la técnica. Los hilos se forman en pares como: HOST_Gnd con HOST_Pwr; MDDI_Stb+ con MDDI_Stb- ; MDDI_DataO+ con MDDI_DataO-; MDDI_Datal+ con MDDI_Datal- ; etc. Sin embargo, puede utilizarse una variedad de conductores y cableado, como se entiende bien en la técnica, para implementar las modalidades de la invención, que dependen de las aplicaciones específicas. Por ejemplo, los recubrimientos externos más pesados o incluso las capas metálicas pueden utilizarse para proteger el cable en algunas aplicaciones, aunque pueden ser muy adecuadas estructuras más delgadas, tipo listón conductor más plano para otras aplicaciones.

D. Tipos y Velocidades de Datos Para alcanzar una interfaz útil para un rango total de experiencias y aplicaciones de usuario, la Interfaz de Datos Digitales Móvil (MDDI) proporciona soporte para una variedad de clientes e información de despliegue, traductores de audio, teclados, dispositivos de señalamiento y muchos otros dispositivos de entrada y salida que podrían integrarse dentro de o funcionar en coordinación con un dispositivo de despliegue móvil, junto con la información de control, y las combinaciones de los mismos. La interfaz MDD está diseñada para posibilitar el ajuste de una variedad de tipos potenciales de corrientes de datos que atraviesan entre el anfitrión y el cliente ya sea en direcciones de enlace sin retorno o de retorno utilizando un número mínimo de cables o conductores. Se soportan ambas corrientes isócronas y corrientes asincronas (actualizaciones) . Son posibles muchos tipos de combinaciones de datos siempre y cuando las velocidades de datos agregadas sean menores que o iguales al máximo deseado de velocidad de enlace MDDI , lo cual está limitado por la velocidad en serie máxima y el número de transferencias de datos empleadas. Estos podrían incluir, aunque sin limitarse a ellos, aquellos artículos numerados en las Tablas II y III a continuación. Tabla II Transfiriendo desde un Anfitrión al Cliente datos de video 720x480, 12bit, 30 f/s -124.5 Mbps isócronos datos de audio 44.1kHz, 16bit, 1.4 Mbps estéreo isócronos estéreo datos de gráficos 800x600, 12bit, lOf/s, -115.2 Mbps asincronos estéreo control asincrono Mínimo << 1.0 Mbps Tabla III La interfaz no se fija sino que es extensible para que pueda soportar la transferencia de una variedad de "tipos" de información que incluye datos definidos por el usuario, para una flexibilidad futura del sistema. Los ejemplos específicos de datos que se pueden ajustar son: video de movimiento total, ya sea en forma de campos de mapa de bits de pantalla totales o parciales o video comprimido; mapas de bits estáticos a velocidades bajas para conservar la potencia y reducir los costos de implementación; PCM o datos de audio comprimidos en una variedad de resoluciones o velocidades; la posición y selección de dispositivo de señalamiento y datos definibles por el usuario para las capacidades que están por definirse. Tales datos también pueden transferirse junto con información de control o estado para detectar la capacidad del dispositivo o establecer los parámetros de operación. Las modalidades de la invención hacen avanzar la técnica para utilizarlas en las transferencias de datos que incluyen, aunque sin limitarse a estas: ver una película (despliegue de video y audio) ; utilizar una computadora personal con pantalla personal limitada (despliegue de gráficos, algunas veces combinados con video y audio) ; jugar un video juego en una PC, consola o dispositivo personal (despliegue de gráficos en movimiento, o video y audio sintéticos) ; "navegar" en la Internet, utilizando dispositivos en forma de un video teléfono (video y audio de velocidad baja bi-direccional) , una cámara para fotos digitales de imagen fija, o una video cámara para capturar imágenes de video digitales; utilizar un teléfono, computadora o PDA acoplada con un proyector para proporcionar una presentación o acoplada con una estación de acoplamiento de escritorio conectada a un monitor de video, un teclado y un ratón; y para incrementar la productividad o un uso de entretenimiento con teléfonos celulares, teléfonos inteligentes o los PDA, incluyendo dispositivos de señalamiento inalámbricos y datos de teclado. La interfaz dé datos de rapidez elevada que se discute a continuación se presenta en términos de la proporción de enormes cantidades de datos tipo A-V a través de una comunicación o enlace de transferencia que generalmente se configura como un enlace tipo línea metálica o cable. Sin embargo, será fácilmente aparente que la estructura de la señal, los protocolos, el cronometraje o el mecanismo de transferencia podrían ajustarse para proporcionar un enlace en forma de un medio óptico o inalámbrico, si puede sostener el . nivel deseado de transferencia de datos. Las señales de la interfaz MDD utilizan un concepto que se conoce como la Velocidad de Trama Común (CFR) para el protocolo o estructura de señal básica. La idea detrás del uso de una Velocidad de Trama Común es proporcionar un pulso de sincronización para corrientes de datos isócronas simultáneas. Un dispositivo de cliente puede utilizar esta velocidad de trama común como un tiempo de referencia. Una velocidad CF baja incrementa la eficiencia del canal al disminuir las operaciones auxiliares para transmitir el encabezamiento de sub-trama.

Por otro lado, una velocidad de CF elevada disminuye la latencia, y permite una memoria intermedia de datos elástica más pequeña para las muestras de audio. La velocidad CF de la presente interfaz inventiva se puede programar dinámicamente y puede fijarse en uno o muchos valores que son apropiados para las corrientes isócronas utilizadas en una aplicación particular. Es decir, el valor CF se selecciona para adecuar lo mejor a un cliente determinado y a la configuración del anfitrión, según se desee. El número de bytes generalmente requerido para la sub-trama, que se puede ajustar o puede programarse, para corrientes de datos isócronas que son las más probables que se vayan a utilizar con una aplicación, tales como para un video o una miero-pantall se muestran en la Tabla IV. Tabla IV Los conteos fraccionarios de bytes por sub-trama se obtienen fácilmente utilizando una estructura de contador M/N programable simple. Por ejemplo, un conteo de 26-2/3 bytes por CF se implementa al transferir dos tramas de 27 bytes seguido cada uno por una sub-trama de 26 bytes. Puede seleccionarse una velocidad de CF más pequeña para producir un número entero de bytes por sub-trama. Sin embargo, hablando en forma general, para implementar un contador M/? simple en el hardware requeriría una menor área dentro de un chip de circuito integrado o módulo electrónico utilizado para implementar parte de o todas las modalidades de la invención del área necesaria para una memoria intermedia FIFO de muestra de audio más grande. Una aplicación ejemplar que ilustra el impacto de diferentes velocidades de transferencia de datos y tipos de datos es un sistema Karaoke. Para el Karaoke, un sistema en donde un usuario final o usuarios cantan junto con un programa de video musical . La letra de la canción se despliega en alguna parte sobre, típicamente en la parte inferior de, una pantalla para que el usuario sepa la letra que va a cantar, y en forma aproximada el cronometraje de la canción. Esta aplicación requiere un despliegue del video con actualizaciones de gráficos no frecuentes, y mezclar la voz del usuario o, las voces, con una corriente de audio en estéreo. Si se asume una velocidad de trama común de 300 Hz, entonces cada sub-trama consistirá en: 92,160 bytes de contenido de video y 588 bytes de contenido de audio (con base en 147 muestras de 16 bit, en estéreo) a través del enlace sin retorno para el dispositivo de .despliegue de cliente, y un promedio de 26.67 (26-2/3) de bytes de voz se envían devuelta desde un micrófono a la máquina de Karaoke móvil . Los paquetes asincronos se envían entre el anfitrión y el despliegue, posiblemente montados en la cabeza. Esto incluye como máximo 768 bytes de datos de gráficos (un cuarto de altura de la pantalla) , y menos de aproximadamente 200 bytes (varios) bytes para control misceláneo y comandos de estado. La Tabla V, muestra cómo se destinan los datos dentro de una sub-trama para el ejemplo del Karaoke. La velocidad total que se utiliza se selecciona para que sea de aproximadamente 279 Mbps. Una velocidad ligeramente más elevada de 280 Mbps permite aproximadamente otros 400 bytes de datos por sub-trama para transferirse, lo cual permite el uso de un control ocasional y mensajes de estado. Tabla V III. (Continuación) Arquitectura del Sistema de Interfaz de Datos Digitales de Velocidad Elevada E. Capa de Enlace Los datos transferidos utilizando las señales de datos en serie de rapidez elevada de interfaz MDD consisten en una corriente de paquetes multiplexados por tiempo que se enlazan uno tras otro. Incluso cuando un dispositivo de transmisión no tiene datos que enviar, un controlador de enlace MDDI automáticamente en forma general envía paquetes de relleno, de ese modo, manteniendo de esa forma una corriente de paquetes . El uso de una estructura de paquetes simple asegura un cronometraje isócrono confiable para señales de video y audio o corrientes de datos . Los grupos de paquetes están contenidos dentro de elementos o estructuras de señal a los cuales se hace referencia como sub-trama, y los grupos de sub-tramas están contenidos dentro de elementos o estructuras de señal a los cuales se hace referencia como una trama de medio. Una sub-trama contiene uno o más paquetes, dependiendo de su tamaño y usos de transferencias de datos respectivos, y una trama de medios contiene uno o más sub-tramas. La sub-trama más grande que se proporciona mediante el protocolo que se emplea a través de las modalidades presentadas en la presente están en el orden de 232-l ó 4,294,967,295 bytes, y el tamaño de trama de medio más grande se transforma entonces en el orden de 216-1 ó 65,535 sub-tramas. Un paquete de encabezamiento de sub-trama especial contiene un identificador único que aparece al principio de cada sub-trama, como se discute a continuación. Ese identificador también se utiliza para adquirir el cronometraje de trama en el dispositivo de cliente cuando se inicia la comunicación entre el anfitrión y el cliente. La adquisición del cronometraje del enlace se discute con más detalle a continuación. Típicamente, una pantalla de despliegue se actualiza una vez por trama de medios cuando se está desplegando un video de movimiento total . La velocidad de despliegue de trama es la misma para la velocidad de trama de medios. El protocolo de enlace soporta video de movimiento total a través de todo un despliegue, o sólo una pequeña región del contenido de video de movimiento total rodeada por una imagen estática, dependiendo de la aplicación deseada. En algunas aplicaciones móviles de baja potencia, tales como el despliegue de páginas web o correos electrónicos, la pantalla de despliegue puede necesitar solamente actualizarse en forma ocasional. En esas situaciones, es ventajoso transmitir un solo sub-trama y luego cerrar o desactivar el enlace para minimizar el consumo de energía eléctrica. La interfaz también soporta efectos tales como el estéreo-visión, y maneja gráficos básicos . Los sub-tramas permiten a un sistema habilitar la transmisión de paquetes de alta prioridad en una base periódica. Esto permite corrientes isócronas simultáneas que co-existen con una cantidad mínima de almacenamiento intermedio de datos. Esta es una ventaja de las modalidades que se proporciona para el proceso de despliegue, que permite corrientes de datos múltiples (comunicación de video, voz, control, estado, datos del dispositivo de señalamiento de rapidez elevada, etc.) para esencialmente compartir un canal común. Transfiere información utilizando relativamente pocas señales. También habilita que existan acciones específicas de la tecnología de despliegue, tales como pulsos de sincronización horizontal e intervalos de bloqueo para un monitor CRT, o para otras acciones específicas de la tecnología del cliente.

F. Controlador de Enlace El controlador de enlace MDDI mostrado en las FIGURAS 4 y 5 se fabrica o se ensambla para que sea una implementación completamente digital con excepción de los receptores en línea diferenciales que se utilizan para recibir datos MDDI y señales estroboscópicas . Sin embargo, incluso los manej adores y los receptores de línea diferencial pueden implementarse en los mismos circuitos integrados digitales con el controlador de enlace, tal como se fabrica un CMOS tipo IC. No se requieren funciones análogas o circuitos de fase cerrada (los PLL) para la recuperación de bits o para implementar el hardware para el controlador de enlace . Los controladores de enlace de anfitrión y cliente contienen funciones muy similares, con la excepción de la interfaz de cliente que contiene una máquina de estado para la sincronización de enlace. Por lo tanto, las modalidades de la invención permiten una ventaja práctica para que exista la posibilidad de crear un solo diseño de controlador o circuito que puede configurarse ya sea como un anfitrión o un cliente, que puede reducir los costos de fabricación para los controladores de enlace en forma total .

IV. Protocolo de Enlace de la Interfaz A. Estructura de trama El protocolo de señal o estructura de trama utilizado para implementar la comunicación de enlace sin retorno para la transferencia de paquete se ilustra en la FIGURA 6. Como se muestra en la FIGURA 6, la información o los datos digitales se agrupan en elementos conocidos como paquetes. A su vez, múltiples paquetes se agrupan en forma conjunta para formar a lo que se hace de referencia como un "sub-trama" y múltiples sub-tramas a su vez se agrupan en forma conjunta para formar una trama de "medios" . Para controlar la formación de tramas y transferir los sub-tramas, cada sub-trama comienza con un paquete predefinido en forma especial al cual se hace referencia como Paquete de Encabezamiento de Sub-trama (SHP) . El dispositivo anfitrión selecciona la velocidad de datos que se van a utilizar para una transferencia determinada. Esta velocidad puede cambiarse dinámicamente mediante el dispositivo anfitrión con base tanto en la capacidad de transferencia máxima del anfitrión, como en los datos que se recuperan de una fuente mediante el anfitrión, y la capacidad máxima del cliente u otro dispositivo al cual se están transfiriendo los datos. Un dispositivo de cliente receptor diseñado para, o que es capaz de, funcionar con la MDDI o el protocolo de señal inventivo está en posibilidad de ser consultado por el anfitrión para determinar la velocidad de transferencia de datos máxima, o actualmente máxima, que puede utilizarse o una velocidad mínima más lenta por defecto que puede utilizarse, así como los tipos de datos que pueden utilizarse y las características soportadas. Esta información podría transferirse utilizando un Paquete de Capacidad de Cliente (DCP) , como se discute adicionalmente a continuación. El dispositivo de despliegue de cliente es capaz de transferir datos o comunicarse con otros dispositivos utilizando la interfaz a una velocidad de datos mínima pre-seleccionada o dentro de un rango de velocidad de datos mínimo, y el anfitrión llevará a cabo una consulta utilizando una velocidad de datos dentro de este rango para determinar las capacidades totales de los dispositivos del cliente. Puede transferirse otra información de estado que defina la naturaleza del mapa de bits y las capacidades de velocidad de trama de video del cliente en un paquete de estado para el anfitrión de modo de que el anfitrión pueda configurar la interfaz para que sea tanto eficiente como óptima en lo práctico, o según se desee dentro de cualesquiera restricciones del sistema. El anfitrión envía los paquetes de relleno cuando no hay (más) paquetes de datos que se vayan a transferir en el actual sub-trama, o cuando el anfitrión no puede transferir a una velocidad suficiente para mantener el paso con la velocidad de transmisión de datos elegida por el enlace sin retorno. Dado que cada sub-trama comienza con un paquete de encabezamiento de sub-trama, el final de la sub-trama anterior contiene un paquete (que es más probable que sea un paquete rellenador) que rellena exactamente la sub-trama anterior. En el caso de una falta de espacio para los paquetes que portan los datos propiamente dichos, un paquete rellenador muy probablemente será el último paquete en una sub-trama, o al final del siguiente sub-trama anterior y antes de un paquete del encabezamiento de la sub-trama. Es una tarea de las operaciones de control en un dispositivo de anfitrión para asegurarse que existe suficiente espacio restante en una sub-trama para cada paquete que se va a transmitir dentro de ese sub-trama. Al mismo tiempo, una vez que el dispositivo anfitrión inicia el envío de un paquete de datos, el anfitrión debe estar en posibilidad de completar exitosamente un paquete de ese tamaño dentro de una trama sin incurrir en una condición de una cantidad insuficiente de datos . En un aspecto de las modalidades, la transmisión de sub-tramas tiene dos modos. Un modo es un modo de sub-trama periódico, épocas de cronometraje periódico, utilizadas para transmitir corrientes de video y audio en vivo. En este modo, la longitud de sub-trama se define como si no estuviera en cero. El segundo modo es un modo asincrono o no periódico en el cual las tramas se utilizan para proporcionar los Datos de Mapa de bits para un cliente cuando está disponible nueva información. Este modo se define al establecer la longitud de sub-trama en cero en el Paquete de Encabezamiento de la sub-trama. Cuando se utiliza el modo periódico, la recepción del paquete de sub-trama puede comenzar cuando el cliente se ha sincronizado con la estructura de trama de enlace sin retorno. Esto corresponde a los estados "en sincronización" definidos de acuerdo con el diagrama de estado que se discute a continuación con respecto a la FIGURA 49 o la FIGURA 63. En el modo de sub-trama no periódico asincrono, la recepción comienza después de que se ha recibido el primer paquete de Encabezamiento de la sub-trama.

B. Estructura General del Paquete El formato o la estructura de los paquetes utilizados para formular la comunicación o el protocolo de la señal, o el método o el medio para transferir los datos, implementado mediante las modalidades se presenta a continuación, teniendo en mente que la interfaz es extensible y que si se desea pueden agregarse estructuras de paquete adicionales . Los paquetes están etiquetados como, o divididos en, diferentes "tipos de paquetes" en términos de su capacidad en la interfaz, es decir, comandos, información, valor o datos que transfieren o con los cuales están asociados. Por lo tanto, cada tipo de paquete indica una estructura de paquete pre-definida para un paquete determinado que se utiliza en la manipulación de los paquetes y los datos que se están transfiriendo. Será fácilmente aparente, que los paquetes pueden tener longitudes pre-seleccionadas o pueden tener longitudes variables o que pueden cambiarse dinámicamente dependiendo de sus funciones respectivas . Los paquetes podrían también portar nombres diferentes, aunque se esté realizando la misma capacidad aún, como puede ocurrir cuando los protocolos se cambian durante la aceptación dentro de un estándar. Los valores de bytes o byte utilizados en los diversos paquetes se configuran como enteros sin signo de multi-bit (8 ó 16 bits) se emplea un resumen de los paquetes que se emplean junto con sus designaciones de "tipo", enumeradas por orden de tipo, y que se muestran en las Tablas VI-1 hasta la VI-4. Cada tabla representa un "tipo" de paquete dentro de una estructura general de paquete para facilitar su ilustración y comprensión. No hay limitación u otro impacto que esté implicado o que se exprese para la invención mediante esos agrupamientos, y los paquetes pueden organizarse en muchas otras maneras según se desee. También se resalta la dirección en la cual se considera válida la transferencia de un paquete.

Tabla VI-1 Paquetes de Control de Enlace Tabla VI-2 Paquetes de Corriente de Medios Básicos Tabla VI-3 Estado de Cliente y Paquetes de Control Tabla V -4 Gráfico Avanzado y Paquete de Despliegue Algo que es claro a partir de otras discusiones dentro de este texto es que aunque el Paquete de Encapsulamiento de Retorno, el Paquete de Capacidad de Cliente y el Paquete de Solicitud y Estado de Cliente se consideren cada uno como muy importantes o incluso se requieran en muchas modalidades de las interfaces de comunicación para la operación del Modo Externo, aunque puede considerarse que sean o que es más probable que sean opcionales para la operación de Modo Interno. Esto crea incluso otro tipo de protocolo de Interfaz MDD que permite la comunicación de datos a rapidez muy elevada con un conjunto de paquetes de comunicaciones reducido, y una simplificación de control y cronometraje correspondiente. Los paquetes tienen una estructura básica común o conjunto global de campos mínimos que comprenden un campo de Longitud de Paquete, un campo de Tipo de Paquete, un campo o campos de Bytes de Datos, y un campo CRC, que se ilustra en la FIGURA 7. Como se muestra en la FIGURA 7, el campo de la Longitud de Paquete contiene información en la forma de un valor de múltiples bits o bytes, que especifican 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 signo amplio de 16 bits ó 2 bytes, que especifica la Longitud de Paquete . El campo del Tipo de Paquete es otro campo de múltiples bits que designa el tipo de información que está contenida dentro del paquete . En una modalidad ejemplar, éste es un valor amplio de 16 bits ó 2 bytes, en forma de un entero sin signo de 16 bits, y especifica tales tipos de datos como capacidades de despliegue, transferencia intracelular, corrientes de video o audio, estado, etc. Un tercer campo es el campo de Bytes de Datos, que contiene los bits o los datos que se transfieren o se envían entre los dispositivos anfitrión y Cliente como parte de ese paquete. El formato de los datos está definido específicamente para cada tipo de paquete de acuerdo con el tipo específico de datos que se transfieren, y pueden separarse 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 que contiene los resultados de una verificación de redundancia cíclica de 16 bits calculada a través de los campos Bytes de Datos, Tipo de Paquete y Longitud de Paquete, que se utilizan para confirmar la integridad de la información en el paquete. En otras palabras, se calcula para todo el paquete excepto para el propio campo CRC. El cliente generalmente mantiene un conteo total de los errores de CRC detectados, y reporta este conteo devuelta hacia el anfitrión en el Paquete de Solicitud y Estado de Cliente (véase más adelante) . Generalmente, esos anchos de campo y su organización están diseñados para mantener campos de 2 bytes en un límite uniforme de bytes, y los campos de 4 bytes se alinean son los límites de 4 bytes. Esto permite estructura de paquete que puede integrarse fácilmente dentro de un espacio de una memoria principal de un anfitrión y un cliente o asociarse con éstos sin violar las reglas de alineación de tipo de datos que se encuentran para la mayoría o típicamente se utilizan en los circuitos de control o procesadores. Durante la transferencia de los paquetes, los campos se transmiten iniciando con el Último Bit Significativo (LSB) primero y se termina con el último Bit Más Significativo (MSB) transmitido. Los parámetros que tienen una longitud de más de un byte se transmiten utilizando primero el último byte significativo, lo cual da por resultado el mismo patrón de transmisión de bit que se utiliza para un parámetro mayor a una longitud de 8 ites, como el que se utilizaría para un parámetro más corto en donde se transmite primero el LSB. Los campos de datos para cada paquete se transmiten generalmente en el orden en el que están definidos en secciones subsecuentes a continuación, con el primer campo enumerado para que se transmita primero, y el último campo se describe para que se transmita al último. Los datos en la trayectoria de la señal MDDI_Data0 se alinean con el bit 0' de los bytes que se transmiten en la interfaz en cualquiera de los modos Tipo 1, Tipo 2, Tipo 3 o Tipo 4. Cuando se manipulan datos para los despliegues, los datos para la disposición de los pixeles se transmiten primero mediante filas, luego en columnas, como tradicionalmente se hace en la técnica de la electrónica. En otras palabras, todos los pixeles que aparecen en la misma fila en un mapa de bits se transmiten en orden con el pixel que se encuentra más a la izquierda transmitido primero y el pixel que se encuentra más a la derecha transmitido al final. Después de que el pixel que está más a la derecha de una fila se transmite, entonces el siguiente pixel en la secuencia es el pixel que se encuentra más a la izquierda de la siguiente fila. Las filas de pixeles se transmiten generalmente en orden desde arriba hasta abajo para la mayoría de los despliegues, aunque pueden ajustarse otras configuraciones según sea necesario. Además, al manejar mapas de bits el método convencional, el cual se sigue aquí, es definir un punto de referencia mediante la etiquetación de la esquina superior izquierda de un mapa de bits como la ubicación o desplazamiento "0,0". Las coordenadas X e Y utilizadas para definir o determinar una posición en el mapa de bits incrementan su valor conforme se aproximan a la derecha o al fondo del mapa de bits, respectivamente. La primera fila y la primera columna (esquina superior izquierda de una imagen) inician con un valor índice de cero. La magnitud de la coordenada X se incrementa en dirección al lado derecho de la imagen, y la magnitud de la coordenada Y se incrementa en dirección a la parte inferior de la imagen tal como se visualiza por el usuario de la pantalla. Una ventana de pantalla es la porción visible de un mapa de bits, la porción de los pixeles en el mapa de bits que puede ser vista por el usuario en el medio de despliegue físico. A menudo se da el caso en el que la ventana de pantalla y el mapa de bits son del mismo tamaño. La esquina superior izquierda de la ventana de pantalla siempre despliega la ubicación de pixel en el mapa de bits de "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 a o igual al ancho del mapa de bits correspondiente. La altura de la ventana corresponde al eje de las Y del mapa de bits, y la altura de la ventana de pantalla para esta modalidad es menor a o igual a la altura del mapa de bits correspondiente . Por sí misma la ventana de pantalla no puede direccionarse en el protocolo debido a que solamente está definida como la porción visible de un mapa de bits. La relación entre los mapas de bits y las ventanas de pantalla se conoce bien en las técnicas de cómputo, la electrónica, la comunicación Internet y otras técnicas de la electrónica relacionadas. Por lo tanto, en la presente no se proporcionan discusiones o ilustraciones adicionales de esos principios.

C. Definiciones de Paquete I. Pacjuete de Encabezamiento de Sub-Trama El paquete de Encabezamiento de Sub-Trama es el primer paquete de todo sub-trama, y tiene una estructura básica como se ilustra en la FIGURA 8. El Paquete de Encabezamiento de Sub-Trama se utiliza para una sincronización anfitrión-cliente, cada anfitrión debe estar en posibilidad de generar este paquete, aunque cada cliente debe estar en posibilidad de recibir e interpretar este paquete. Como puede verse en una modalidad de la FIGURA 8, este tipo de paquete está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, Término Único, Reservado 1, Longitud de Sub-Trama, Versión de Protocolo, Conteo de Sub-Trama y Conteo de Medio-Trama, generalmente en ese orden. En una modalidad, este tipo de paquete se identifica generalmente como un paquete Tipo 15359 (hexadecimal 0x3bff) y utiliza una longitud fija preseleccionada de 20 bytes, que no incluye el campo longitud de paquete. El campo Tipo de Paquete y el campo Término Único utilizan cada uno un valor de 2 bytes (entero sin signo de 16 bits) . La combinación de 4 bytes de esos dos campos forma de manera conjunta un término único de 32 bits con una buena auto-correlación. En una modalidad, el término único real es 0x005a3bff, en donde se transmiten los 16 bits más bajos primero como el Tipo de Paquete, y después se transmiten como los 16 bits más significativos. El campo Reservado 1 contiene 2 bytes que son un espacio reservado para un uso futuro, y generalmente está configurado en ese momento con todos los bits establecidos en cero. Un propósito de este campo es provocar que los campos de 2 bytes subsecuentes se alineen con una dirección de término de 16 bits y provocar que los campos de 4 bytes se alineen con direcciones de término de 32 bits. El último byte significativo se reserva para indicar si el anfitrión es capaz o no de dirigirse a múltiples dispositivos de cliente . Un valor de cero para este byte se reserva para indicar que el anfitrión es capaz de operar solamente con un solo dispositivo de cliente. El campo Longitud de Sub-Trama contiene 4 bytes de información, o valores, que especifican el número de bytes por sub-trama. En una modalidad, la longitud de este campo puede establecerse igual a cero para indicar que solamente se transmitirá una sub-trama mediante el anfitrión antes de que se cierre el enlace en un estado de disponibilidad. El valor en este campo puede cambiarse dinámicamente "sobre la marcha" cuando hace la transición de una sub-trama al siguiente. Esta capacidad es útil para hacer ajustes de cronometraje menores en los pulsos de sincronización para ajustar corrientes de datos isócronas. Si la CRC del Paquete de Encabezamiento de Sub-trama no es válido entonces el controlador del enlace debe utilizar la Longitud de Sub-trama del paquete de Encabezamiento de Sub-trama bien conocido previo para estimar la longitud de sub-trama actual. El campo Versión de Protocolo contiene 2 bytes que especifican la versión del protocolo que está siendo utilizada por el anfitrión. El campo Versión de Protocolo puede establecerse en ? 0' para especificar la primera o la actual versión del protocolo que se está utilizando. Este valor cambiará con el tiempo conforme se creen nuevas versiones, y está ya mejorado a un valor x l ' para algunos campos de versión. Los valores de versión probable o generalmente siguen un número de versión actual para un documento de estándares aprobados que cubren las interfaces tales como la MDDI, como ya se conoce. El campo de Conteo de Sub-trama contiene 2 bytes que especifican un número de secuencia que indica el número de sub-tramas que se han transmitido desde el inicio de la trama de medios. La primer sub-trama de trama de medios tiene un Conteo de Sub-trama de cero. La última sub-trama de trama de medios tiene un valor de n-l, en donde n es el número de sub-tramas por trama de medios. El valor del campo de Conteo de Sub-trama es igual al Conteo de Sub-trama enviado en el paquete de Sub-Trama previo más 1, excepto por una sub-primer sub-trama de una trama de medios que tendrá un conteo de cero. Debe notarse que si la Longitud de Sub-trama se establece igual a cero (indicando una sub-trama no periódica) entonces el conteo de Sub-trama también se establece igual a cero. El campo de Conteo de Trama de medios contiene 4 bytes (entero sin signo de 32 bits) que especifica un número de secuencia que indica el número de tramas de medios que se han transmitido desde el inicio del elemento de medios presente o datos que se están transfiriendo. La primer trama de medios de un elemento de medios tiene un Conteo de Tramas de Medios de cero. El Conteo de Trama de Medios se incrementa justo antes de la primer sub-trama de cada trama de medios y se regresa a cero después de que se utiliza el Conteo de Trama de Medios máximo (por ejemplo, el número de trama de medios 23"1=4, 294, 967, 295) . El valor del Conteo de trama de Medios puede reiniciarse generalmente en cualquier momento mediante el Anfitrión para adecuarse a las necesidades de una aplicación final. 2. Paquete Rellenador Un paquete rellenador es un paquete que se transfiere hacia o desde un dispositivo de Cliente cuando no está disponible otra información que se vaya a enviar ya sea en el enlace sin retorno o de retorno. Se recomienda que los paquetes rellenadores tengan una longitud mínima para permitir una flexibilidad máxima al enviar otros paquetes cuando se requieran. Justo al final de una sub-trama o un paquete de encapsulamiento del enlace de retorno (véase más adelante) , un controlador de enlace establece el tamaño del paquete rellenador para rellenar el espacio restante para mantener una integridad de paquete. El Paquete Rellenador es útil para mantener el cronometraje en el enlace cuando el anfitrión o el cliente no tienen información que enviar o intercambiar. Todo anfitrión y cliente necesitan estar en posibilidad de enviar y recibir este paquete para hacer uso efectivo de la interfaz. Una modalidad ejemplar de Formato y el contenido de un Paquete Rellenador se muestra en la FIGURA 9. Como se muestra en la FIGURA 9, éste tipo de paquete está estructurado para tener campos de Longitud de Paquete, un Tipo de Paquete, Bytes de Rellenador y CRC. En una modalidad, éste tipo de paquete está generalmente definido como un Tipo 0, que se indica en el campo Tipo 2 bytes. Los bits o los bytes en el campo Bytes del Rellenador comprenden un número variable de todos los valores de bit de cero para permitir que el paquete rellenador sea de la longitud deseada. El paquete rellenador más pequeño no contiene bytes en este campo. Es decir, el paquete consiste solamente en una longitud de paquete, un tipo de paquete y una CRC, y en una modalidad utiliza una longitud fija pre-seleccionada de 6 bytes o un valor de Longitud de Paquete de 4. El valor de la CRC se determina para todos los bytes en el paquete incluyendo la Longitud de Paquete, que puede excluirse en algunos otros tipos de paquete. 3. Paquete de Corriente de Video Los Paquetes de Corriente de Video portan datos de video para actualizar típicamente regiones rectangulares de un dispositivo de despliegue. El tamaño de ésta región puede ser tan pequeño como un solo pixel o tan grande como el despliegue completo. Puede existir casi un número ilimitado de corrientes desplegadas simultáneamente, limitadas por los recursos del sistema, debido a que todo el contexto que se requiere para desplegar una corriente está contenido dentro del Paquete de Corriente de Video. El formato de una modalidad de un Paquete de Corriente de Video (Descriptor de Formato de los Datos del Video) se muestra en la FIGURA 10. Como puede verse en la FIGURA 10, en una modalidad, este tipo de paquetes está estructurado para tener campos de Longitud de Paquete (2 bytes) , Tipo de Paquete, ID de Clienteb, Descriptor de Datos de Video, Atributos de Despliegue de Pixel, Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, Inicio X e Y, Conteo de Pixel, Parámetro de la CRC, Datos del Pixel y CRC de Datos del Pixel. Este tipo de paquete generalmente se identifica con un Tipo 16, que está indicado en el campo Tipo 2 bytes. En una modalidad, un cliente indica una capacidad para recibir un Paquete de Corriente de Video que utiliza RGB, Monocromo, y campos de Capacidad Y CrCb del Paquete de la Capacidad de cliente.

En una modalidad, el campo ID de Clienteb contiene 2 bytes de información que se reservan para un ID de Cliente. Dado que éste es un protocolo de comunicaciones recientemente desarrollado los ID de Cliente actuales no se conocen aún o no se pueden comunicar lo suficiente . Por lo tanto, los bits en este campo generalmente son iguales a cero hasta que se conozcan los valores de la ID, en cuyo momento lo valores de la ID pueden insertarse o utilizarse, como será aparente para quienes tienen experiencia en la técnica. El mismo proceso generalmente será verdadero para los campos del ID de Cliente que se discuten más adelante. El concepto de trama común discutido anteriormente es una manera efectiva de minimizar el tamaño de la memoria intermedia de audio y disminuir la latencia. Sin embargo, para los datos de video puede ser necesario dispersar los pixeles de una trama de video a través de múltiples Paquetes de Corriente de Video dentro de una trama de medios. También es muy probable que los pixeles, en un solo Paquete de Corriente de Video no correspondan exactamente a una ventana rectangular perfecta en la pantalla. Para la velocidad de trama de video ejemplar de 30 tramas por segundos, existen 300 sub-tramas por segundo, lo cual da por resultado en 10 sub-tramas por trama de medios. Si existen 480 filas de pixeles en cada trama, cada Paquete de Corriente de Video en cada sub-trama contendrá 48 filas de pixeles. En otras situaciones, el Paquete de Corriente de Video podría no contener un número entero de filas de pixeles. Si esto es cierto para otros tamaños de trama de video en donde el número de sub-tramas por tramas de medio no se divide con igualdad entre el número de filas (también conocidas como líneas de video) por trama de video. Para una operación eficiente, cada Paquete de Corriente de Video debe contener generalmente un número entero de pixeles. Incluso podría no contener un número entero de filas de pixeles. Esto es importante si los pixeles son de más de un byte cada uno, o si están en un formato de paquete como el que se muestra en la FIGURA 12. El formato y el contenido empleados para hacer realidad la operación de un campo Descriptor de Datos de Video ejemplar, como se menciona anteriormente, se muestran en las FIGURAS 11A-11E. En las FIGURAS 11A-11E, el campo Descriptor de Formato de Datos de Video contiene 2 bytes en la forma de un entero sin signo de 16 bits que especifican el formato de cada pixel en los Datos de Pixel en la corriente presente en el paquete presente. Es posible que diferentes paquetes de Corriente de Video puedan utilizar diferentes formatos de datos de pixel, es decir, que utilicen un valor diferente en el Descriptor de Formato de Datos de Video, y de modo similar una corriente (región del despliegue) puede cambiar su formato de datos sobre la marcha. El formato de datos de pixel debe cumplir con al menos uno de los formatos válidos para el Cliente, como se define en el Paquete de Capacidad de cliente . El Descriptor de Formato de Datos del Video define el formato de pixel para el paquete presente sólo que no implica que se continuará utilizando un formato constante durante la vida útil de una corriente de video en particular. Las FIGURAS HA hasta la 11D ilustran como se codifica el Descriptor de Formato de Datos de Video. Como se utiliza en esas figuras, y en esta modalidad, cuando los bits [15:13] son iguales a ?000', como se muestra en la FIGURA HA, entonces los datos de video consisten en una disposición de pixeles de monocromo en donde el número de bits por pixel está definido por los bits de 3 hasta 0 del término de Descriptor de Formato de Datos de Video. Los Bits 11 hasta el 4 generalmente se reservan para un uso o aplicaciones futuras y se establecen en cero en ésta situación. Cuando los bits [15:13] en vez de ser igual a los valores "001', como se muestra en la FIGURA 11B, entonces los datos de video consisten en una disposición de pixeles de color que especifica cada uno un color a través de un mapa de color (paleta) . En esta situación, los bits desde 5 hasta 0 del término del Descriptor de Formato de Dato de Video definen el número de bits por pixel, y los bits 11 hasta 6 generalmente se reservan para un uso o aplicaciones futuras y se establece igual a cero. Cuando los bits [15:13] son en vez de igual a los valores ? 010', como se muestra en la FIGURA 11C, entonces los datos de video consisten en una disposición de pixeles de color en donde el número de bits por pixel de rojo se define mediante los bits 11 hasta el 8, el número de bits por pixel del verde se definen mediante los bits 7 hasta el 4, y el número de bits por pixel del azul se define mediante los bits 3 hasta el 0. En esta situación, el número total de bits en cada pixel es la suma del número de bits utilizados para el rojo, verde y azul- Sin embargo, cuando los bits [15:13] son en vez de igual a los valores o a la secuencia ' 011', como se muestra en la FIGURA 11D, entonces los datos de video consisten en una disposición de datos de video en un formato 4:2:2 YCbCr con información de luminancia y crominancia, en donde el número de bits por pixel de luminancia (Y) está definido mediante los bits 11 hasta el 8, el número de bits del componente Cb está definido por los bits 7 hasta el 4, y el número de bits del componente Cr está definido por los bits 3 hasta el 0. El número total de bits en cada pixel es la suma de número de bits utilizados para el rojo, verde y azul. Los componentes Cb y Cr se envían a la mitad de la velocidad como Y. Además, las muestras de video en la porción de Datos de Pixel de este paquete se organizan de la siguiente manera: Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3 , ... en donde Cbn y Crn se asocian con Yn y Yn+1, y Cbn+2 y Crn+2 se asocian con Yn+2 y Yn+3 , etc . Yn, Yn+1, Yn+2 y Yn+3 son valores de luminancia de cuatro pixeles consecutivos en una sola fila de izquierda a derecha. Si existe un número impar de pixeles en una fila (X Borde Derecho - X Borde Izquierdo +1) en la ventana a la que se hace referencia mediante el Paquete de Corriente de Video entonces el valor Y corresponde al último pixel en cada fila que está seguido por el valor Cb del primer pixel de la siguiente fila, y un valor Cr que no se envía al último pixel en la fila. Se recomienda que las ventanas utilicen un formato Y Cb Cr que tenga un ancho que es un número par de pixeles. Los Datos de Pixel en un paquete deben contener un número par de pixeles . Pueden contener un número impar o par de pixeles en el caso en donde el último pixel los Datos de Pixel corresponda al último píxel de una fila en la ventana especificada en el encabezamiento del Paquete de Corriente de Video, es decir, cuando la ubicación X del último pixel en los Datos de Pixel sea igual al Borde Derecho X. Cuando los bits [15:13] son en vez de igual a los valores Y00' entonces los datos de video consisten en una disposición de pixeles Bayer en donde el número de bits por pixel esta definido por los bits del 3 hasta el 0 del término del Descriptor de Formato de Datos de Video. El Patrón del Grupo de Pixel está definido por los bits 5 y 4 como se muestra en la FIGURA HE. El orden de los datos del pixel puede ser horizontal o vertical, y los pixeles en las filas o las columnas pueden enviarse en un orden de retorno y sin retorno y está definido por los bits 8 hasta el 6. Los Bits del 11 hasta el 9 deben establecerse en cero. El grupo de cuatro pixeles en el grupo de pixel en el formato Bayer se asemeja a lo que a menudo se hace referencia como un solo pixel en algunas tecnologías de despliegue. Sin embargo, un pixel en el formato Bayer es solamente uno de los cuatro pixeles coloreados del patrón del mosaico del grupo de pixel . Para todos los cinco formatos mostrados en las figuras, el Bit 12, que se designa como "P" , especifica si las muestras de Datos de Pixel están empaquetadas o no, o datos de pixel alineados con el byte. Un valor Y' en este campo indica que cada pixel en el campo Datos de Pixel está alineado con el byte y con un limite de byte de interfaz MDD. Un valor de ? 1' indica que cada pixel y cada color dentro de cada pixel en los Datos de Pixel se empaquetan contra el pixel previo o el color dentro de un pixel que no deja bits sin utilizar. La diferencia entre el formato de datos Alineado con el Byte y Pixel Empaquetado se muestra con más detalle en la FIGURA 12, en donde se puede claramente ver que los datos alineados con el byte pueden dejar porciones sin utilizar de la sub-trama de datos, en oposición al formato de pixel empaquetado que no las deja. El primer pixel en el primer paquete de corriente de video de una trama de medios para una ventana de pantalla en particular irá hacia la esquina superior izquierda de la ventana de corriente definida por un Borde Izquierdo X y un Borde Superior Y, y el siguiente pixel recibido se coloca en la siguiente ubicación de pixel en la misma fila, etc. En este primer paquete de trama de medios, el valor de inicio X será usualmente igual al Borde Izquierdo X y el valor de inicio Y usualmente será igual al Borde Superior Y. En los paquetes subsecuentes que corresponden a la misma ventana de la pantalla, los valores de inicio X e Y usualmente se establecerán en la ubicación de pixel en la ventana de la pantalla que normalmente seguiría después del último pixel enviado en el Paquete de Corriente de Video que se transmite en la sub-trama previa. 4. Pagúete de Corriente de Audio Los paquetes de corriente de audio portan datos de audio que se van a reproducir a través del sistema de audio del cliente, o para un dispositivo de presentación de audio independiente. Pueden destinarse diferentes corrientes de datos de audio para canales de audio separados en un sistema de sonido, por ejemplo: izquierda al frente, derecha al frente, centro, atrás izquierda y atrás derecha, dependiendo del tipo de sistema de audio que se esté utilizando. Se proporciona un complemento para canales de audio completo para audífonos que contienen un procesamiento de señal espacial-acústica mejorada. Un cliente indica una capacidad para recibir un Paquete de Corriente de Audio utilizando la Capacidad del Canal de Audio y los campos de Velocidad de Muestra de Audio del Paquete de Capacidad de cliente . El formato de los Paquetes de Corriente de Audio se ilustra en la FIGURA 13. Como se muestra en la FIGURA 13, este tipo de paquete está estructurado en una modalidad para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteb, ID del Canal de Audio, Reservado 1, Conteo de Muestra de Audio, Bits por Muestra y Empaquetado, Velocidad de Muestra de Audio, Parámetro CRC, Datos de Audio Digitales, y CRC de Datos de Audio. En una modalidad, éste tipo de paquete se define generalmente como un paquete Tipo 32. El campo ID de Clienteb contienen 2 bytes de información que se reservan para un ID de Cliente, como se utilizó previamente. El campo Reservado 1 contiene 2 bytes que están reservados para un uso futuro, y que generalmente se configura en este punto con todos los bits establecidos en cero . El campo Bits por Muestra y Empaquetado contiene 1 byte en la forma de un entero sin signo de 8 bits que especifica el formato del empaquetado de los datos de audio. El formato generalmente empleado es para los Bits 4 hasta el 0 para definir el número de bits por muestra de audio PCM. El Bit 5 entonces especifica si las muestras de los Datos de Audio Digitales se empaquetan o no. La diferencia entre el paquete y las muestras de audio alineadas por el byte, que aquí utilizan muestras de 10 bits, se ilustra en la FIGURA 14. Un valor de '0' indica que cada muestra de audio PCM en el campo de Datos de Audio Digitales se alinea con el byte con un límite de byte de interfaz MDDI y un valor de Y' indica que cada muestra de audio PCM sucesiva se empaqueta contra la muestra de audio previa. Este bit es generalmente efectivo solo cuando el valor definido en los bits del 4 al 0 (el número de bits por muestra de audio PCM) no es un múltiplo de ocho. Los Bits del 7 hasta el 6 están reservados para un uso futuro y generalmente se establecen en un valor de cero.

. Paquetes de Corriente Reservada En una modalidad, los tipos de paquete 1 hasta el 15, 18 hasta el 31, y 33 hasta el 55 se reservan para paquetes de corriente que se van a definir para un uso en futuras versiones o variaciones de los protocolos de paquete, según desee para las diversas aplicaciones que se encuentren. De nuevo, esto es parte de lo que hace a la interfaz MDD más flexible y útil a pesar de los siempre cambiantes diseños de tecnología y sistemas cuando se compara con otras técnicas . 6. Paquetes de Corriente Definidos por el Usuario Ocho tipos de corriente de datos, conocidos como los Tipos 56 hasta el 63, se reservan para utilizarlos en aplicaciones del propietario que pueden ser definidos por los fabricantes del equipo para utilizarlos con un enlace MDDI . Estos se conocen como los Paquetes de Corriente definidos por el usuario. Tales paquetes pueden utilizarse para cualquier propósito, aunque el anfitrión y el cliente deben emplear solamente tales paquetes en situaciones en las cuales el resultado de tal uso se entiende o se conoce muy bien. La definición específica de los parámetros y los datos de corriente para esos tipos de paquetes se dejan para que sean específicos de los fabricantes del equipo o de los diseñadores de la interfaz que implementan tales tipos de paquete o que buscan su uso. Algunos usos ejemplares de los Paquetes de Corriente definidos por el Usuario son para transferir parámetros de prueba y resultados de prueba, datos de calibración en la fábrica, y datos de uso especial del propietario. El formato de los paquetes de corriente definidos por el usuario que se utilizan en una modalidad se ilustra en la FIGURA 15. Como se muestra en la FIGURA 15, este tipo de paquete está estructurado para tener campos de Longitud de Paquete (2 bytes) , un Tipo de Paquete, un número ID de Clienteb, Parámetros de Corriente, Parámetro CRC, 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 una tabla de consulta del mapa de color utilizada para presentar colores para un cliente. Algunas aplicaciones pueden requerir un mapa de colores que es más grande que la cantidad de datos que pueden transmitirse en un solo paquete. En esos casos, los paquetes del Mapa de Color Múltiples pueden transferirse, cada uno con un subconjunto diferente del mapa de color al utilizar los campos de desplazamiento y longitud que se describen a continuación. El formato del Paquete el Mapa de Color en una modalidad se ilustra en la FIGURA 16. Como se muestra en la FIGURA 16, este tipo de paquete se estructura para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteh, un Conteo de Elemento de Mapa de Color, Desplazamiento de Mapa de Color, Parámetro CRC, Datos de Mapa de Color y CRC de Datos. En una modalidad, este tipo de paquete se identifica generalmente como un paquete Tipo 64 (Formato de Datos de Video y Paquete de Mapa de Color) como el que se especifica en el Campo de Tipo de Paquete (2 bytes) . Un cliente indica una capacidad para recibir los Paquetes de Mapa de Color que utilizan los campos Tamaño de Mapa de Color, y Ancho de Mapa de Color del Paquete de Capacidad de Cliente . 8. Paquetes de Encapsulamiento de Enlace de Retorno En una modalidad ejemplar, los datos se transfieren en la dirección de retorno utilizando un Paquete de Encapsulamiento de Enlace de Retorno. Un paquete de enlace sin retorno se envía y la operación del enlace MDDI (dirección de transferencia) se cambia o se le da la vuelta a la mitad de este paquete para que los paquetes puedan enviarse en la dirección de retorno . El formato del paquete de Encapsulamiento de Enlace de Retorno 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 Clienteh, Indicadores de Enlace de Retorno, Divisor de Velocidad de Retorno, Longitud de Dar Vuelta 1, Longitud de Dar Vuelta 2, Parámetro CRC, Todo Cero 1, Dar Vuelta 1, Paquetes de Datos de Retorno, Dar Vuelta 2, y Todos Cero 2. En una modalidad, este tipo de paquete generalmente está identificado como un paquete Tipo 65. Para el Modo Externo todo anfitrión debe estar en posibilidad de generar este paquete y recibir los datos, y todo cliente debe estar en posibilidad de recibir y enviar datos al anfitrión para hacer uso eficientemente del protocolo deseado y la velocidad resultante. La implementación de este paquete es opcional para el Modo Interno, aunque el Paquete de Encapsulamiento de Enlace de Retorno se utiliza para que el anfitrión reciba datos del cliente. El controlador del enlace MDDI se comporta de una manera especial mientras está enviando un Paquete de Encapsulamiento de Enlace de Retorno. La interfaz MDD tiene una señal estroboscópica que generalmente está controlada por el anfitrión como controlador de enlace. El anfitrión se comporta como si estuviera transmitiendo en cero para cada bit de las porciones de Paquetes Dar Vuelta y Datos de Retorno del paquete Encapsulamiento de Enlace de Retorno.

El anfitrión alterna una señal MDDI_Strobe en cada límite de bit durante las dos veces que se da vuelta y durante el tiempo destinado para los paquetes de datos de retorno.

(Este es el mismo comportamiento como si se fueran a transmitir datos todos en cero) .

El anfitrión deshabilita sus manej adores en línea de la señal de datos MDDI durante el periodo de tiempo especificado por Dar la Vuelta 1, y el cliente vuelve a habilitar sus manej adores en línea durante el campo Rehabilitar Manejador' después del periodo de tiempo especificado por el campo Dar la Vuelta 2. El cliente lee el parámetro Longitud de Dar la Vuelta y acciona las señales de datos en dirección al anfitrión inmediatamente después del último bit en el campo Dar la Vuelta 1. Es decir, el cliente registra el tiempo de los datos nuevos dentro del enlace en ciertos bordes de elevación del estrobo MDDI según se especifica en la descripción del contenido de paquete a continuación, y en cualquier otra parte. El cliente utiliza los parámetros de Longitud de Paquete y Longitud de Dar la Vuelta para conocer la longitud de tiempo que tiene disponible para enviar los paquetes al anfitrión. El cliente puede enviar paquetes de rellenador o accionar las líneas de datos en el estado cero cuando no hay datos que enviar al anfitrión. Si las líneas -de datos se accionan en cero, el anfitrión interpreta esto como un paquete con longitud cero (una longitud no válida) y el anfitrión no acepta más paquetes de cliente para la duración del Paquete de Encapsulamiento de Enlace de Retorno Actual . El Anfitrión acciona las señales MDDI Data al nivel de cero-lógico durante el campo Todo en Cero 1 y el cliente acciona las líneas de datos MDDI al nivel cero-lógico por al menos un periodo de registro de tiempo del enlace de retorno antes del inicio del campo Dar Vuelta 2, que está durante el período del campo Todo en Cero 2. Esto mantiene la línea de datos en un estado determinista durante el periodo de tiempo de los campos Dar la Vuelta 1 y Dar la Vuelta 2. Si el cliente ya no tiene más paquetes que enviar, puede incluso deshabilitar las líneas de datos después de accionarlas al nivel cero-lógico debido a que las resistencias de polarización para hibernación (se discuten en cualquier otra parte) mantienen las líneas de datos en un nivel de cero-lógico por el resto del campo Paquetes de Datos de Retorno, o una duración de aproximadamente 16 bytes del enlace sin retorno o más. En una modalidad, el campo Solicitud de Enlace de Retorno de la Solicitud de Cliente y el Paquete de Estado pueden utilizarse para informar al anfitrión del número de bytes que el cliente necesita en el Paquete de Encapsulamiento del Enlace de Retorno para enviar los datos nuevamente al anfitrión. El anfitrión intenta otorgar la solicitud al asignar al menos un número de bytes en el Paquete de Encapsulamiento de Enlace de Retorno. El anfitrión pude enviar más de un Paquete de Encapsulamiento de Enlace de Retorno en una sub-trama. El cliente puede enviar Solicitud de Cliente y un Paquete .de Estado casi en cualquier momento, y el anfitrión interpretará el parámetro de Solicitud de Enlace de Retorno como el número total de bytes solicitados en una sub-trama. 9. Paquetes de Capacidad de Cliente Un anfitrión necesita conocer la capacidad de cliente (despliegue) con el que se está comunicando para configurar el enlace anfitrión-cliente de una manera generalmente óptima o deseada. Se recomienda que el despliegue envíe un Paquete de Capacidad de Cliente al anfitrión después de que se adquirió la sincronización del enlace sin retorno. La transmisión de un paquete como ese se considera que se requiere cuando es solicitado por el anfitrión utilizando las Indicadores de Enlace de Retorno en el Paquete de Encapsulamiento de Enlace de Retorno. El Paquete de Capacidad de Cliente se utiliza para informar al anfitrión de las capacidades de un cliente. Para todo Modo Externo el anfitrión debe estar en posibilidad de recibir ese paquete, y todo cliente debe estar en posibilidad de enviar ese paquete para utilizar en forma total esta interfaz y protocolos . La implementación de este paquete es opcional para el Modo Interno, dado que las capacidades del cliente, tales como una pantalla, un teclado u otro dispositivo de entrada/salida, en esta situación debe estar ya bien definido y debe conocerse por el anfitrión en el momento de la fabricación o ensamble dentro de un solo componente o unidad de algún tipo. El formato del paquete Capacidad de Cliente en una modalidad se ilustra en la FIGURA 18. Como se muestra en la FIGURA 18, para esta modalidad este tipo de paquete se estructura para que tenga campos de Longitud de Paquete, Tipo de Paquete, ID de Cuentee reservada, Versión de Protocolo, Versión de Protocolo Mín. , Capacidad de Velocidad de Datos, Capacidad de Tipo Interfaz, Número Despliegues Alt, Reservado 1, Ancho de Mapa de Bit, Altura de Mapa de Bit, Ancho de la Ventana de pantalla, Altura de la Ventana de pantalla. Tamaño de Mapa de Color, Ancho RGB del Mapa de Color, Capacidad RGB, Capacidad Monocromo, Reservado 2, Capacidad Y CrCb, Compatibilidad Bayer, Planos de Imagen Alfa-Cursor, Capacidad de Característica del Cliente, Velocidad de Trama de Video Max., Velocidad de Trama de Video Min., Velocidad de Sub-Trama Min., 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 de Audio de Micrófono, Capacidad de Velocidad de Muestra de Micrófono, Formato de Datos del Teclado, Formato de Datos del Dispositivo de Señalamiento, Tipo de Protección de Contenido, Nombre del Fabricante, Código del Producto, Reservado 3, Número de Serie, Semana de Fabricación, Año de Fabricación y CRC. En una modalidad ejemplar, este tipo de paquete generalmente se identifica como un paquete Tipo 66.

. Paquete de Datos de Teclado Un paquete de datos de teclado se utiliza para enviar datos de teclado desde un dispositivo de Cliente hasta el anfitrión. Un teclado inalámbrico (o cableado) , puede utilizarse junto con varios dispositivos de pantalla o audio, que incluyen aunque no se limitan a estos, un dispositivo de presentación de audio/pantalla de video montada en la cabeza. El Paquete de Datos de Teclado que transmite los datos de teclado recibidos desde uno o diversos dispositivos similares a un teclado conocidos hacia el anfitrión. Este paquete puede también utilizarse en el enlace sin retorno para enviar datos para el teclado. Un cliente indica una capacidad para enviar y recibir Paquete de Datos de Teclado utilizando el Campo de Datos de Teclado en el Paquete de Capacidad de Cliente . El formato de un Paquete de Datos de Teclado se muestra en la FIGURA 19, y contiene un número variable de bytes de información a partir de o para un teclado. Como se muestra en la FIGURA 19, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, un Tipo de Paquete, ID de Clienteb, Formato de Datos del Teclado, Datos de Teclado, y CRC. Aquí, este tipo de paquete generalmente está identificado como un paquete Tipo 67. La ID de Clienteb es un campo reservado, como antes, y la CRC se lleva a cabo a través de todos los bytes del paquete. El campo Formato de Datos de Teclado contiene un valor de 2 bytes que describe el formato de datos de teclado. Los bits 6 hasta 0 deben ser idénticos para el campo Formato de Datos de Teclado en el Paquete de Capacidad de Cliente. Este valor no es igual a 127. Los bits 15 hasta 7 están reservados para un uso futuro y por lo tanto, están actualmente establecidos en cero. 11. Paquete de Datos de Dispositivo de Señalamiento Se utiliza un paquete de datos de dispositivo de señalamiento como un método, estructura o medio para enviar la información de posición desde un ratón inalámbrico u otro dispositivo de señalamiento desde el Cliente hasta el anfitrión. Los datos también pueden enviarse al dispositivo de señalamiento en el enlace sin retorno utilizando este paquete. Un formato ejemplar de un Paquete de Datos del Dispositivo de Señalamiento se muestra en la FIGURA 20, 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 20, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, un Tipo de Paquete, ID de Clienteb, un 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 tipo 1 byte. 12. Paquetes de Interrupción de Enlace Se envía un Paquete de Interrupción de Enlace desde el anfitrión hasta el Cliente como un método o medio para indicar que los datos MDDI y el estroboscopio se cerrarán y se dirigirán hacia un estado de "hibernación" de consumo bajo de energía eléctrica. Este paquete es útil para cerrar el enlace y conservar la potencia después de que los mapas de bits estáticos se envían desde un dispositivo de comunicación móvil a la pantalla, o cuando no existe más información que transferir desde un anfitrión hasta un cliente por el momento. La operación normal se resume cuando el anfitrión envía los paquetes de nuevo. El primer paquete enviado después de la hibernación es un paquete de encabezamiento de sub-trama. El formato de un Paquete de Estado de Cliente para una modalidad se muestra en la FIGURA 21. Como se muestra en la FIGURA 21, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, CRC y Todo en Ceros. En una modalidad, este tipo de paquete generalmente se identifica como un paquete Tipo 69 en el campo tipo 1 byte. El campo longitud de paquete utiliza 2 bytes para especificar el número total de bytes en el paquete sin incluir el campo longitud de paquete. En una modalidad, la Longitud de Paquete de este paquete depende del Tipo de Interfaz o modo de enlace en efecto en el momento en el que se envía el Paquete de Interrupción de Enlace . Por lo tanto, la longitud típica de paquete se convierte en 20 bytes para el modo Tipo 1 (22 bytes en total en el paquete) , 36 bytes para el modo Tipo 2 (38 bytes en total en el paquete) , 68 bytes para el enlace modo Tipo 3 (70 byte en total en el paquete) , y 132 bytes para pun modo Tipo 4 (con 134 bytes en total en el paquete) . El campo Todo en Cero utiliza un número variable de bytes Prat asegurarse de que las señales MDDI_Data están en un nivel de cero lógico poro un tiempo suficiente para permitir que el cliente comience a recuperar el reloj utilizando solamente MDDI_Stb antes de deshabilitar los manej adores de la línea del anfitrión. La longitud del campo Todo en Cero depende del Tipo de Interfaz o modo de operación del enlace en efecto en el momento en el que se envía el Paquete de Interrupción de Enlace. La longitud de del campo Todo en Cero pretende producir 64 pulsos en MDDI_Stb para cualquier ajuste del Tipo de Interfaz. Por lo tanto, la longitud de Todo en Ceros para cada interfaz se convierte en 16 bytes 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 una CRC de 16 bits de la Longitud de Paquete para el Tipo de Paquete. En el estado de hibernación de baja potencia, el manejador MDDI_Data0 se deshabilita dentro en un estado de alta impedancia, que inicia después del ciclo 16° hasta el 48° de MDDI_Stb después del último bit del campo Todo en Cero. Para los enlaces Tipo 2, Tipo 3 o Tipo 4 las señales MDDI_Datal hasta MDDI_DataPwr7 también se colocan en un estado de alta impedancia al mismo tiempo que el manejador MDDI_DataO es deshabilitado. Ya sea el anfitrión o el cliente pueden provocar que el enlace MDDI "despierte" del estado de hibernación como se describe en cualquier parte más adelante, lo cual es una ventaja clave para y una ventaja de la presente invención. Como se describe en la definición del campo Todo en Cero, MDDI_Stb bascula durante 64 ciclos después del MSB del campo CRC del Paquete de Interrupción de Enlace para facilitar una interrupción ordenadamente en el controlador del cliente. Un ciclo es una transición de bajo-a-elevado seguida de una transición elevado-a-bajo, o una transición elevado-a-bajo seguida de una transición bajo-a-elevado.

Después de que se envía el campo Todo en Cero, el manejador MDDI__Stb en el anfitrión se deshabilita. 13. Solicitud del Cliente y Paquetes de Estado El anfitrión necesita una pequeña cantidad de información del cliente para que pueda configurar el enlace anfitrión a cliente en una manera generalmente óptima. Se recomienda que el cliente envíe una Solicitud del Cliente, y Paquete de Estado al anfitrión en cada sub-trama. El cliente debe enviar este paquete como el primer paquete en el Paquete de Encapsulamiento de Enlace de Retorno, para asegurarse de que sea suministrado confiablemente al anfitrión. Para la operación del modo externo, todo anfitrión debe estar habilitado para recibir este paquete para apropiada y óptimamente emplear el protocolo de la interfaz MDD. Aunque también se recomienda que para las operaciones internas, es decir los anfitriones internos y los clientes internos, deba existir un soporte para este paquete, éste no se requiere. El formato de una Solicitud de Cliente y Paquete de Estado se muestra en la FIGURA 22. Como se muestra en la FIGURA 22, este tipo de paquetes está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cuentee, Solicitud de Enlace de Retorno, Cambio de Capacidad, Defectos de Gráficos, Conteo de Error CRC y CRC.

Este tipo de paquete generalmente se identifica como un paquete Tipo 70 en el campo tipo 1 byte, y típicamente utiliza una longitud fija pre-seleccionada de 12 bytes. El campo Solicitud de Enlace de Retorno puede utilizarse para informar al anfitrión del número de bytes que el cliente necesita en el Paquete de Encapsulamiento de Enlace de Retorno para enviar datos de vuelta al anfitrión. El anfitrión debe intentar otorgar la solicitud al destinar al menos ese número de bytes en el Paquete de Encapsulamiento de Enlace de Retorno. El anfitrión puede enviar más de un Paquete de Encapsulamiento de Enlace de Retorno en una sub-trama para ajustar los datos. El cliente puede enviar una Solicitud de Cliente y un Paquete de Estado en cualquier momento y el anfitrión interpretará el parámetro de Solicitud de Enlace de Retorno como el número total de bytes solicitados en una sub-trama. Los detalles y ejemplos específicos adicionales de cómo se envían los datos del enlace de retorno devuelta al anfitrión se muestran a continuación. 14. Paquetes de Transferencia de Bloque de Bit El Paquete de Transferencia de Bloque de Bit proporciona un medio, estructura o método para deslizar regiones de despliegue en cualquier dirección. Los despliegues que tienen ésta capacidad reportarán la capacidad en el bit O del campo de Indicadores de Capacidad de Característica de Despliegue del Paquete de Capacidad de cliente. El formato para una modalidad de un Paquete de Transferencia de Bloque de Bit se muestra en la FIGURA 23. 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 Clienteh, Valor X Izquierda Superior, Valor Y izquierda 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. Los campos se utilizan para especificar los valores X e 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 pixeles en el que se va. a mover la ventana horizontal, y verticalmente, en forma respectiva. Los valores positivos para los dos últimos campos provocan que la ventana se mueva hacia la derecha, y hacia abajo, y los valores negativos provocan que el movimiento sea a la izquierda y hacia arriba, respectivamente.

. Paquetes de Relleno de Área de Mapa de Bit El Paquete de Relleno de Área de Mapa de Bit proporciona un medio, estructura o método para fácilmente iniciar una región de la pantalla para un solo color. Las pantallas que tienen esta capacidad reportan la capacidad en el bit 1 del campo Indicadores de Capacidad de Característica del Cliente del Paquete de Capacidad de cliente. En la FIGURA 24 se muestra una modalidad de Formato de Paquete de Relleno de Área de Mapa de Bit. Como se muestra en la FIGURA 24, en este caso éste tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteh, Valor X Superior Izquierdo, Valor Y Superior Izquierdo, Ancho de Ventana, Altura de Ventana, Descriptor de Formato de Datos, Valor de Relleno de Área de Pixel, y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 72 en el campo tipo 1 byte, y utiliza una longitud fija preseleccionada de 17 bytes. 16. Paquetes de Relleno de Patrón de Mapa de Bit El Paquete de Relleno de Patrón de Mapa de Bit proporciona un medio o estructura para fácilmente iniciar una región de la pantalla en un patrón pre-seleccionado.

Las pantallas que tienen está capacidad reportarán la capacidad en el bit 2 del campo de Capacidad de Característica del Cliente del Paquete de Capacidad de cliente. La esquina izquierda superior del patrón de relleno se alinea con la esquina izquierda superior de la ventana que se va a rellenar, a menos que el desplazamiento del patrón horizontal o vertical no sea cero. Si la ventana que se va rellenar es más ancha o más alta que la del patrón de relleno, entonces el patrón puede repetirse horizontal o verticalmente un número de veces para llenar la ventana. Cuando es necesario se trunca el derecho o la parte inferior del último patrón repetido. Si la ventana es más corta que el patrón de relleno, entonces el lado derecho o la parte inferior del último patrón relleno pueden truncarse para ajustar la ventana. Si el desplazamiento del patrón horizontal no es cero, entonces los pixeles entre el lado izquierdo de la ventana y el lado izquierdo más el desplazamiento del patrón horizontal se rellenan con los pixeles que están más a la derecha del patrón. El desplazamiento horizontal del patrón va a ser menor que el ancho del patrón. Del mismo modo, si un desplazamiento vertical del patrón no es cero, entonces los pixeles entre el lado superior de la ventana y la parte superior del desplazamiento del patrón del lado más vertical se rellenan con los pixeles que están más abajo del patrón. El desplazamiento vertical del patrón va a ser menor que la altura del patrón.

Una modalidad para el formato de un Paquete de Relleno del Patrón del Mapa de Bit se muestra en la FIGURA 25, Como se muestra en la FIGURA 25, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteh, Valor X Superior Izquierdo, Valor Y Superior Izquierdo, Ancho de Ventana, Altura de Ventana, Ancho de Patrón, Altura de Patrón, Desplazamiento Horizontal del Patrón, Desplazamiento Vertical del Patrón, Descriptor de Formato de Datos, Parámetro CRC, Datos del Pixel del Patrón, y CRC de Datos de Pixel. En algunas modalidades, este tipo de paquete generalmente se identifica como un paquete Tipo 73 en el campo del tipo 1 byte. 17. Paquetes de Canal de Datos del Enlace de Comuní cací ón El Paquete de Canal de Datos del Enlace de Comunicación proporciona una estructura, medio o método para un Cliente con una capacidad informática de nivel elevado, tal como un PDA, para comunicarse con un transceptor inalámbrico tal como un teléfono celular o un dispositivo de puerto de datos inalámbrico. En esta situación, el enlace MDDI está actuando como una interfaz de rapidez elevada conveniente entre el dispositivo de comunicación y el dispositivo de informática con la pantalla móvil, en donde este paquete transporta los datos a una Capa de Enlace de Datos de un sistema de operación para el dispositivo. Por ejemplo, este paquete podría utilizarse si un navegador de red, correo electrónico del cliente o todo un PDA estuvieran integradas en una pantalla móvil . Las pantallas que tienen ésta capacidad reportarán la capacidad en el bit 3 del campo de Capacidad de Característica del Cliente del Paquete de Capacidad de cliente. El formato de una modalidad para un Paquete de Canal de Datos del Enlace de Comunicación se muestra en la FIGURA 26. 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 Clienteh, Parámetro CRC, Datos del Enlace de Comunicación, y CRC de Datos de Comunicación. En una modalidad, éste tipo de paquete generalmente se identifica como un paquete Tipo 74 en el campo tipo. 18. Paquetes de Solicitud de Transferencia Intracelular Tipo Interfaz El Paquete de Solicitud de Transferencia Intracelular Tipo Interfaz proporciona un medio, método o estructura que posibilita al anfitrión solicitar que el cliente o el despliegue se cambie de un modo existente o actual a los modos del Tipo 1 (serial) , Tipo 2 (paralelo de 2 bits) , Tipo 3 (paralelo de 4 bits) , o Tipo 4 (paralelo de 8 bits) . Antes de que el anfitrión solicite un modo en particular debe confirmar que el cliente es capaz de operar en el modo deseado al examinar los bits 6 y 7 del campo Indicadores de Capacidad de Características de Despliegue del Paquete de Capacidad de cliente. Una modalidad para el formato de un Paquete de Solicitud de Transferencia Intracelular Tipo Interfaz 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, Tipo Interfaz, Reservado 1 y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 75, y utiliza una longitud fija pre-seleccionada de 4 bytes. 19. Paquetes de Reconocimiento Tipo Interfaz El Paquete de Reconocimiento Tipo Interfaz se envía mediante un cliente y proporciona un medio, método o estructura que posibilita a un Cliente confirmar la recepción del Paquete de Transferencia Intracelular Tipo Interfaz. El modo solicitado, modo Tipo 1 (serial), Tipo 2 (paralelo de 2 bits) , Tipo 3 (paralelo de 4 bits) o Tipo 4 (paralelo de 8 bits) , se refleja de vuelta al anfitrión como un parámetro en este paquete . El formato de una modalidad para un Paquete de Reconocimiento Tipo Interfaz se muestra en la FIGURA 28. Como se muestra en la FIGURA 28, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cuentee, Tipo Interfaz, Reservado 1 y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 76 y utiliza una longitud fija pre-seleccionada de 4 bytes.

. Paquetes de Transferencia Intracelular Tipo Ejecución El Paquete de Transferencia Intracelular Tipo Ejecución es un medio, estructura o método para que el anfitrión instruya al cliente al modo de transferencia intracelular especificado en este paquete. Este va a ser el mismo modo que previamente se solicitó y se reconoció mediante el Paquete de Solicitud de Transferencia Intracelular Tipo Interfaz y el Paquete de Reconocimiento Tipo Interfaz. El anfitrión y el Cliente deben conmutar hacia el modo que se acordó después que este paquete se envía. El cliente puede perder y volver a obtener la sincronización del enlace durante el cambio de modo. El formato de una modalidad para un Paquete de Transferencia Intracelular Tipo Ejecución se muestra en la FIGURA 29. Como se muestra en la FIGURA 29, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Tipo de Paquete, Reserva 1, y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 77 en el campo tipo 1 byte, y utiliza una longitud fija preseleccionada de 4 bytes . 21. Paquetes que Habilitan el Canal de Audio Sin Retorno Este paquete proporciona una estructura, método o medios que permiten a un anfitrión habilitar o deshabilitar canales de audio en un cliente . Esta capacidad es útil ya que un cliente (por ejemplo un despliegue) puede apagar amplificadores de audio o elementos de circuito similares para ahorrar energía eléctrica cuando no hay audio producido mediante el anfitrión. Esto es significativamente más difícil de implementar simplemente porque está implícita la utilización de la presencia o la ausencia de corrientes de audio como un indicador. El estado por defecto cuando el sistema del cliente está encendido es que todos los canales de audio se habiliten. El formato de una modalidad de un Paquete de Habilitación de Canal de Audio Sin Retorno se muestra en la FIGURA 30. 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 Clienteh, Máscara que Habilita el Canal de Audio, y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 78 en el campo tipo 1 byte, y utiliza una longitud fija pre-seleccionada de 4 bytes. 22. Paquetes de Velocidad de Muestra de Audio de Retorno Este paquete permite al anfitrión habilitar o deshabilitar el canal de audio de enlace de retorno, y establecer la velocidad de la muestra de datos de audio de ésta corriente. El anfitrión selecciona una velocidad de muestra que se define para que sea válida en el Paquete de Capacidad de cliente. Si el anfitrión selecciona una velocidad de muestra inválida entonces el cliente no enviará una corriente de audio al anfitrión, y puede enviarse un error inapropiado, valor de error o señal de error, al anfitrión en el Paquete de Reporte de Error del Cliente. El anfitrión puede deshabilitar la corriente de audio del enlace de retorno al establecer la velocidad de la muestra en un valor de 255. El estado por defecto se asume cuando el sistema de cliente es inicialmente encendido o conectado está con la corriente de audio del enlace de retorno deshabilitada. En la FIGURA 31 se muestra el formato de una modalidad de un Paquete de Velocidad de Muestra de Audio de Retorno. 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 Clienteh, 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. 23. Paquetes de Operaciones Auxiliares para Protección de Contenido Digital Este paquete proporciona una estructura, método o medio que permite a un anfitrión y a un cliente intercambiar mensajes relacionados con el método de protección de contenido digital que se está utilizando. En la actualidad se contemplan dos tipos de protección de contenido, la Protección de Contenido de Transmisión Digital (DTCP) , o el Sistema de Protección de Contenido Digital de Banda Ancha Elevada (HDCP) , con espacio reservado para designaciones de esquema de protección alternativas futuras. El método que se utiliza se especifica mediante un parámetro del Tipo de Protección de Contenido en este paquete. El formato de una modalidad de un Paquete de Operaciones Auxiliares de Protección de Contenido Digital se muestra en la FIGURA 32. Como se muestra en la FIGURA 32, este tipo de paquetes está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteb, Tipo de Protección de Contenido, Mensajes de Operaciones Auxiliares de Protección de Contenido y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 80. 24. Paquetes que Habilitan el Color Transparente El Paquete que Habilita el Color Transparente es una estructura, método o medio que se utiliza para especificar que color es transparente en una pantalla y para habilitar o deshabilitar el uso de un color transparente para imágenes que se despliegan. Las pantallas que tienen ésta capacidad reportarán esa capacidad en el bit 4 del campo de Capacidad de Característica del Cliente del Paquete de Capacidad de cliente. Cuando un pixel con el valor para color transparente se escribe en el mapa de bit, el color no cambia del valor previo. El formato de un Paquete de Habilitación de Color Transparente se muestra en la FIGURA 33. Como se muestra en la FIGURA 33, en una modalidad éste tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteh, Habilitar Color Transparente, Reservado 1, Identificador Alfa-Cursor, Descriptor de Formato de Datos, Valor del Pixel 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 10 bytes.

. Paquetes de Medición de Retraso de Ida y Vuel ta El Paquete de Medición de Retraso de Ida y Vuelta proporciona una estructura, método o medio que se utiliza para medir el retraso de la propagación desde el anfitrión hasta el cliente (despliegue) más el retraso del cliente (despliegue) de vuelta hacia el anfitrión. Esta medición inherentemente incluye los retrasos que existen en los manejadores y receptores en línea, y un subsistema de interconexión. Esta medición se utiliza para establecer el retraso de giro en redondo y los parámetros del divisor de velocidad del enlace de retorno en el Paquete de Encapsulamiento de Enlace de Retorno, descrito en forma general anteriormente. Este paquete es más útil cuando el enlace MDDI está corriendo a la rapidez máxima pretendida para una aplicación en particular. La señal MDDI_Stb se comporta como si todos los datos en cero se estuvieran enviando durante los campos siguiente: ambos, Tiempos de Guarda, Todo en Cero, y el Período de Medición. Esto provoca que MDDI_Stb alterne a la mitad de la velocidad de datos para que pueda utilizarse como medir el tiempo periódico en el cliente durante el Período de Medición. . En una modalidad, un cliente generalmente indica una capacidad para soportar el Paquete de Medición de Retraso de Ida y Vuelta a través del uso de 18 bits del campo Indicadores de Capacidad de Característica del Cliente del Paquete de Capacidad de Cliente. Se recomienda que todos los clientes soporten la medición del retraso de ida y vuelta, aunque es posible para el anfitrión conocer el peor caso de retraso de ida y vuelta con base en un retraso de cable máximo, y los retrasos máximos del manejador y el receptor. El anfitrión también puede conocer el retraso de ida y vuelta por adelantado para un enlace MDDI que se utiliza eh el modo interno, dado que éste es un aspecto de elemento de diseño conocidos (longitudes del conductor, tipo de circuitos y características, etc.) del dispositivo en el cual se está utilizando la interfaz. El formato de un Paquete de Medición de Retraso de Ida y Vuelta se muestra en la FIGURA 34. 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 Clienteh, Parámetro CRC, Tiempo de Guarda 1, Período de Medición, Todo en Cero, y Tiempo de Guarda 2. Este tipo de paquete generalmente se identifica como un paquete Tipo 82, y utiliza una longitud fija pre-seleccionada de 159 bits. El cronometraje de los eventos que toman lugar durante el Paquete de Medición de Retraso de Ida y Vuelta se ilustra en la FIGURA 35. En la FIGURA 35, el anfitrión transmite el Paquete de Medición de Ida y Vuelta, que se muestra mediante la presencia los campos del Parámetro CRC y la Alineación de Estroboscopio seguidos por los campos Todo en Ceros y Tiempo de Guarda 1. Un retraso 3502 ocurre antes de que el paquete alcance el dispositivo de despliegue de cliente o los circuitos de procesamiento. Cuando el cliente recibe el paquete, transmite el patrón Oxff, Oxff, y 30 bytes de 0x0 tan precisamente como sea práctico al inicio del Período de Medición según lo determine el cliente. El tiempo real en el que el Cliente comienza a transmitir ésta secuencia se retraza desde el inicio del Período de Medición desde el punto de vista del anfitrión. La cantidad de éste retraso es sustancialmente el tiempo que lleva al paquete propagarse a través de los manejadores y los receptores de la línea y el subsistema 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 vuelta al anfitrión. Para determinar con precisión el tiempo de retraso de ida y de vuelta para las señales que atraviesan hacia y desde el cliente, el anfitrión contabiliza el número de periodos de tiempo de bit del enlace sin retorno que ocurren después del inicio del Período de Medición hasta el inicio de Oxff, Oxff y 30 bytes de la secuencia 0x0 que se detectan al llegar. Esta información se utiliza para determinar la cantidad de tiempo para una señal de ida y vuelta que pasa desde el anfitrión hasta el cliente y regresa de nuevo. Además, alrededor de la mitad de esta cantidad se atribuye a un retraso creado por un paso de una sola dirección de una señal hasta el cliente. El anfitrión y el cliente accionan ambos la línea para un nivel de cero-lógico durante ambos tiempos de guarda para mantener las líneas MDDI_DATA en un estado definido. Los tiempos de habilitación y deshabilitación del anfitrión y el cliente durante ambos tiempos de guarda son aquellos en los que las señales MDDI_Data están en un nivel válido bajo para cualquier tiempo de retraso de ida y vuelta válido. 26. Paquete de Calibración de Sesgo de Enlace sin retorno El Paquete de Calibración de Sesgo de Enlace Sin Retorno permite a un cliente o pantalla calibrar por si mismo las diferencias en el retraso de propagación de las señales de MDDI_Data con respecto a la señal MDDI_Stb. Sin la compensación de sesgo de retraso, la velocidad máxima de datos está generalmente limitada a justificar una potencial variación en el peor de los casos en esos retrasos. Por lo general, este paquete solamente se envía cuando la velocidad de datos del enlace sin retorno está configurada para una velocidad de aproximadamente 50 Mbps o más baja.

Después de enviar este paquete para calibrar la pantalla, la velocidad de datos puede escalonarse por arriba de los 50 Mbps. Si la velocidad de datos se establece demasiado elevada durante el proceso de calibración del sesgo, la pantalla podría sincronizarse con un alias del período de bit que podría provocar que la compensación del sesgo de retraso se establezca en apagado por más de un tiempo de bit, resultando en registrar el tiempo de datos erróneo. Se selecciona el tipo de velocidad de datos más elevada de interfaz o Tipo de Interfaz mayor posible previo al envío del Paquete de Calibración de Sesgo del Enlace Sin Retorno para que se calibren todos los bits de datos existentes . Una modalidad de Formato del Paquete de Calibración de Sesgo de Enlace Sin Retorno se muestra en la FIGURA 56. 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 Clienteh, Parámetro CRC, Todo en Cero, Secuencia de Datos de Calibración y CRC. Este tipo de paquete generalmente se identifica como un paquete Tipo 83 en el campo tipo, y en una modalidad tiene una longitud pre-seleccionada de 515.

Panel de Control Virtual El uso de un Panel de Control Virtual (VCP) permite a un anfitrión establecer ciertos controles de usuario en un cliente. Al permitir que esos parámetros sean ajustados por el anfitrión, la interfaz de usuario en el cliente puede simplificarse debido a que las pantallas que permiten a un usuario ajustar los parámetros tales como el volumen de audio o brillo del despliegue pueden generarse mediante el software del anfitrión en vez de mediante uno o más microprocesadores en el cliente. El anfitrión tiene la capacidad de leer los ajustes de parámetro en el cliente y para determinar el rango de valores válidos para cada control. El cliente generalmente tiene la capacidad de regresar al anfitrión que parámetros de control pueden ajustarse. Los códigos de control (Códigos VCP) y los valores de datos asociados generalmente especificados, se utilizan para especificar los controles y los ajustes en el cliente. Los Códigos VCP en la especificación MDDI se expanden hasta 16 bits para conservar la alineación de campo de datos apropiada en las definiciones de paquete, y en el futuro para soportar valores suplementarios que son únicos para esta interfaz o futuras mejoras. 27. Paquete de Característica VCP de Solicitud El Paquete de Característica VCP de Solicitud proporciona un medio, mecanismo o método para que el anfitrión solicite el ajuste actual de un parámetro de control específico o todos los parámetros de control válidos. Generalmente, un cliente responde a un Paquete VCP con la información apropiada en un Paquete de Respuesta de Característica VCP. En una modalidad, el cliente indica una capacidad para soportar el Paquete de Característica de solicitud VCP que utiliza 20 bits del campo de los Indicadores de . Capacidad de Características del Cliente del Paquete de Capacidad de cliente. El formato del Paquete de Característica VCP de Solicitud en una modalidad se muestra en la FIGURA 69. Como se ve en la FIGURA 69 , este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteh, Código MCCS de VCP, y CRC. Este tipo de paquete generalmente se identifica en una modalidad como el Tipo 128, que se indica en el campo tipo 2 bytes. La Longitud de Paquete, la cual especifica el número total de bytes en el paquete no incluye el campo de longitud de paquete, típicamente se fija para éste tipo de paquete en una longitud de 8 bytes. El campo ID de Clienteh está reservado para utilizarlo como un ID de Cliente en implementaciones futuras y típicamente se ajusta a cero. El campo de Código MCCS de VCP comprende 2 bytes de información que especifica el Parámetro de Código de Control MCCS de VCP. Un valor en el rango de 0 hasta 255 provoca que un Paquete de Respuesta de Característica VCP sea devuelto con un solo elemento en la Lista de Respuesta de Característica VCP que corresponde al código MCCS especificado. Un código MCCS de VCP de 65535 (Oxffff) solicita un Paquete de Respuesta de Característica VCP con una Lista de Respuesta de Característica VCP que contiene un Elemento de Lista de Respuesta de Característica para cada control soportado por el cliente. Los valores de 256 hasta 65534, para este campo se reservan para un uso futuro y no se utilizan en la actualidad. 28. Paquete de Respuesta de Característica VCP El Paquete de Respuesta de Características VCP proporciona un medio, mecanismo o método para que un cliente responda a la solicitud de un anfitrión con el actual ajuste de un parámetro de control específico o todos los parámetros de control válido. Generalmente, un cliente envía el Paquete de Respuesta de Característica VCP en respuesta a un Paquete de Característica VCP de Solicitud. Este paquete es útil para determinar el ajuste 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 está soportado por el cliente, o para determinar el conjunto de controles que están soportados por el cliente. Si una característica VCP de solicitud se envía y hace referencia a un control específico que no está implementado en el cliente entonces un Paquete de Respuesta de Característica VCP se devuelve con un sólo elemento de la Lista de Respuesta de Característica VCP que corresponde al control no implementado que contiene el código de error apropiado. En una modalidad, el cliente indica una capacidad para soportar el Paquete de Respuesta de Característica VCP utilizando 20 bits del campo de Capacidad de Característica de Cliente del Paquete de Capacidad de Cliente . El formato del Paquete de Respuesta de Característica VCP en una modalidad que se muestra en la FIGURA 70. Como puede verse en la FIGURA 70, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cuentee, Versión MCCS, Número de Secuencia de Respuesta, Lista de Respuesta de Característica VCP y CRC. Este tipo de paquete generalmente se identifica en una modalidad como un Tipo 129, como el que está indicado en el campo tipo 2 bytes . El campo ID de Cuentee contiene información reservada para una ID de Cliente. Este campo está reservado para un uso futuro y generalmente se ajusta a cero. El campo versión MCCS contiene 2 bytes de información que especifican la Versión de la Especificación MCCS de VESA implementada por el cliente. El campo Número de Secuencia de Respuesta de 2 bytes contiene información o datos que especifican el número de secuencia de los Paquetes de Respuesta de Característica VCP devueltos por el cliente. El cliente devuelve uno o más Paquetes de Respuesta de Característica VCP en respuesta a un Paquete de Característica VCP de solicitud con un valor de Código de Control MCCS de 65535. El cliente puede distribuir la lista de la respuesta de la característica a través de múltiples Paquetes de Respuesta de Característica VCP. En este caso, el cliente asigna un número de secuencia para cada paquete sucesivo, y los números de la secuencia de los Paquetes de Respuesta de Característica VCP enviados en respuesta a un sólo Paquete de Característica VCP de solicitud inicia en cero y se incrementa por uno. El último Elemento de la Lista de Característica VCP en el último Paquete de Respuesta de Característica VCP debe contener un valor de Código de Control MCCS de VCP igual a Oxffff para identificar que el paquete es el último y contiene el número de secuencia más elevado del grupo de paquetes devueltos . Si solamente se envió un Paquete de Respuesta de Característica VCP en respuesta a un Paquete de Característica VCP de solicitud entonces el Número de Secuencia de Respuesta en ese sólo paquete es cero y la Lista de Respuesta de Característica VCP contiene un registro que tiene un código de control MCCS de VCP igual a Oxffff.

El Número de Característica en este campo de lista contiene 2 bytes que especifican el número de Elementos de Lista de Característica VCP que están en la Lista de Respuesta de Característica VCP en este paquete, mientras que el campo de la Lista de Respuesta de Características VCP es un grupo de bytes que contiene uno o más elementos de Lista de Respuesta de Característica VCP. El formato de un sólo Elemento de Lista de Respuesta de Característica VCP es una modalidad que se muestra en la FIGURA 71. Como se muestra en la FIGURA 71, cada Elemento de Lista de Respuesta de Característica VCP es de 12 bytes de longitud, y comprende los campos de código MCCS de VCP, el Código de Resultado, el Valor Máximo y de Valor Presente. El campo de Código MCCS de VCP de 2 bytes contiene los datos o la información que especifican el Parámetro del Código de Control MCCS de VCP asociado con este elemento de la lista. Solamente los valores del Código de Control definidos en la Especificación MCCS de VESA de la versión 2 y más tarde 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 con respecto al Control MCCS de VCP especificado. Un valor de 0' en este campo significa que no hay error, aunque un valor de ?l' significa que el control específico no se implemento en el cliente. Los valores adicionales en este campo de 2 hasta 65535 están actualmente reservados para un uso futuro y para su implementación de otra aplicación contemplada por la técnica, aunque no para utilizarse por ahora. El campo del Valor Máximo de 4 bytes contiene un entero sin signo de 32 bits que especifica el valor más grande posible para el cual puede ajustarse el Control MCCS especificado. Si el control solicitado no se implementa en el cliente este valor se ajusta a cero. Si el valor devuelto es menor a 32 bits (4 bytes) de longitud, entonces el valor se reparte entre un numero entero de 32 bits dejando a los bytes más significativos (sin utilizar) ajustados a cero. El campo Valor Presente de 4 bytes contiene información que especifica el valor presente del control continuo (C) MCCS o no continuo (NC) de VCP especificado. Si el control solicitado no se implementa en el cliente o si el control se implementa pero es un tipo de datos (T) de tabla, entonces este valor se ajusta a cero. Si el valor devuelto es menor a 32 bits (4 bytes) de longitud por Especificación MCCS de VESA entonces el valor se reparte entre un número entero de 32 bits dejando los bytes más significativos (sin utilizar) ajustados en cero. 29. Paquete de Característica VCP Ajustado El Paquete de Característica VCP Ajustado proporciona un medio, mecanismo o método para que un anfitrión ajuste los valores de control VCP para ambos controles continuo y no continuo en un cliente. En una modalidad, el cliente indica la capacidad para soportar el Paquete de Característica VCP Ajustado utilizando 20 bits del campo de Capacidad de Característica del Cliente del Paquete de Capacidad de cliente. El formato del Paquete de Característica VCP Ajustado en una modalidad se muestra en la FIGURA 72. Como puede verse en la FIGURA 72, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteh, Código MCCS de VCP, Número de Valores en la Lista, Lista de Valor de Control y CRC. Este tipo de paquete generalmente está identificado como un Tipo 130, como se indica mediante el campo de tipo 2 bytes, y es de 20 bytes de longitud exclusivamente para el campo de Longitud de Paquete. El campo ID de Clienteh utiliza de nuevo un valor de 2 bytes para especificar o actuar como un ID de Cliente. Este campo se reserva para un uso futuro y actualmente está ajustado a cero. El campo de Código MCCS de VCP utiliza 2 bytes de información o valores para especificar el Parámetro de Código de Control MCCS de VCP 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 del Valor de Control . La Lista de Valor de Control usualmente contendrá un elemento a menos que el Código de Control MCCS se relacione con una tabla en el cliente. En el caso de controles no relacionados con una tabla, la Lista del Valor de Control contendrá un valor que especifica un valor nuevo que se va a escribir para el parámetro de control especificado por el campo Código MCCS de VCP. Para controles relacionados con la tabla el formato de los datos en la Lista de Valor de Control se especifica mediante la descripción del parámetro del Código MCCS de VCP especificado. Si la lista contiene valores que son más grandes. que un byte, entonces el último byte significativo se transmite primero, consistente con el método definido en cualquier otra parte. Finalmente, el campo CRC de 2 bytes contiene una CRC de 16 bits de todos los bytes en el paquete incluyendo la Longitud de Paquete .

. 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 contiene una lista de parámetros soportados por el control no continúo (NC) o tabla (T) especificado. Este paquete debería solamente especificar los controles no continuos o los controles que se relacionan con una tabla en el cliente, y no especificar un valor de Código MCCS de VCP de 65535 (Oxffff) para especificar todos los controles. Si un Código MCCS de VCP no soportado o inválido se especifica entonces un valor de error apropiado se devuelve 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 20 bits del campo de Capacidad de Característica del Cliente del Paquete de Capacidad de Despliegue. El formato del Paquete de Parámetro Válido de solicitud en una modalidad se muestra en la FIGURA 73. Como » puede verse en la FIGURA 73 , este tipo de paquete está estructurado para tener campos de Longitud de Paquete, un Tipo de Paquete, ID de Clienteh, Código MCCS de VCP, y CRC.

Este tipo de paquete generalmente se identifica en una modalidad como el Tipo 131, como se indica en el campo tipo 2 bytes. La longitud de paquete, como se indica en el Campo de Longitud de Paquete de 2 bytes generalmente se ajusta para que tenga un número de bytes total en el paquete, sin incluir el campo de longitud de paquete de 8. La ID de Clienteh de nuevo especifica la ID de Cliente, pero está actualmente reservada para un uso futuro, como será aparente para quien tiene experiencia en la técnica, y se ajusta a cero. El Campo de Código MCCS de VCP de 2 bytes contiene un valor que especifica el Parámetro de Código de Control MCCS de VCP no continuo que se va a consultar. El valor en este campo debe corresponder a un control que no es continuo que se implementa en el cliente. Los valores 256 hasta 65535 (Oxffff) se reservan típicamente o se consideran como inválidos, y se consideran como un control no implementado en la respuesta al error. 31. Paquete de Respuesta de Parámetro Válido Un Paquete de Respuesta de Parámetro Válido se envía en respuesta al Paquete de Respuesta de Parámetro Válido. Se utiliza como un medio, método o estructura para identificar los ajustes válidos para un control MCCS de VCP no continuo o un control que devuelve el contenido de una tabla. Si el control se relaciona con una tabla en un cliente, entonces la lista de respuesta del parámetro VCP simplemente contiene la lista específica de valores de tablas secuenciales que se solicitaron. Si el contenido de la tabla no puede ajustarse dentro de un sólo Paquete de Respuesta de Parámetro Válido entonces múltiples paquetes con Números de Secuencia de Respuesta secuencial pueden enviarse por el cliente. En una modalidad, un cliente indica una capacidad para soportar un paquete de Respuesta de Parámetro Válido utilizando 20 bits del campo de Capacidad de Característica del Cliente del Paquete de Capacidad de cliente. Un anfitrión puede solicitar el contenido de una tabla de la siguiente manera: el anfitrión envía un Paquete de Característica VCP de Ajuste que contiene los parámetros necesarios o deseados tales como el parámetro leer/escribir, el desplazamiento LUT y la selección RGB; luego un Paquete de Parámetro Válido de Solicitud que - especifica el control deseado se envía mediante el anfitrión; luego el cliente devuelve una o más Respuesta de Parámetro Válido que contienen los datos de la tabla. Esta secuencia de operaciones realiza una capacidad similar como la de las funciones de lectura de la tabla descrita en el modelo de operación MCCS. Si un parámetro del cliente específico no está soportado por el cliente entonces en una modalidad el campo correspondiente de este paquete contendrá un valor de 255. Para los parámetros que se utilizan en el cliente, el campo correspondiente debe contener un valor del parámetro en el cliente. El formato del Paquete de Respuesta de Parámetro Válido para una modalidad se muestra en la FIGURA 74. Como puede verse en la FIGURA 74, este tipo de paquetes está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cuentee, Código MCCS de VCP, Código de Respuesta, Número de Secuencia de Respuesta, Valores del Número en la Lista, Lista de Respuesta del Parámetro VCP y CRC. Este tipo de paquete generalmente identificado para una modalidad como un Tipo 132, como se indica en el campo de tipo 2 bytes. El campo ID de Clientec está reservado para la ID de Cliente futura, como se conoce a partir de las discusiones anteriores, aunque el Paquete del Código MCCS de VCP de 3 bytes contiene un valor que especifica un Parámetro de Código de Control MCCS de VCP que se describe mediante este paquete. Si se especifica un Código de Control MCCS de VCP inválido mediante un Paquete de Parámetro Válido de Solicitud, entonces el mismo valor de parámetro inválido se especificará en este campo con el valor apropiado en el campo Código de Respuesta. Si el Código de Control MCCS es inválido entonces la Lista de Respuesta del Parámetro VCP tendrá una longitud de cero. El campo Código de Respuesta contiene 2 bytes de información o valores que especifican la naturaleza de la respuesta que se relaciona con la solicitud para la información con respecto al Control MCCS de VCP especificado. Si el valor en este campo es igual a 0, entonces no se considera que esté presente el error para este tipo de datos, y la última Respuesta de Parámetro Válido en la secuencia se envía, teniendo el Número de Secuencia de Respuesta más elevado. Si el valor en este campo es igual a 1, entonces no se considera que esté presente el error, aunque pueden enviarse otros Paquetes de Respuesta de Parámetro Válido que tengan número de secuencia más elevados . Si el valor en este campo es igual • a 2 , entonces el control especificado no se considera que esté implementado en el cliente. Si el valor en este campo id es igual a 3, entonces el control especificado no es un control que no es continuo (es un control continuo que siempre tiene un conjunto válido de todos los valores desde cero hasta su valor máximo) . Los valores para este campo igual a 4 hasta 65535 se reservan para un uso futuro y generalmente no se utilizan. El campo Número de Secuencia de Repuesta de 2 bytes especifica el número de secuencia de los Paquetes de Respuestas de Parámetro Válido devueltos por el cliente. El cliente devuelve uno o más Paquetes de Respuestas de Parámetro Válido en respuesta a un Paquete de Parámetro Válido de Solicitud. El cliente puede distribuir la Lista de Respuesta de Parámetro VCP a través de múltiples Paquetes de Respuestas de Parámetro Válido. En este último caso, el cliente asignará un número de secuencia a cada paquete sucesivo, y establecerá el Código de Respuesta en 1 en todos menos en 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 alto y el Código de Respuesta contiene un valor de 0. El Número de Valores de 2 bytes en el campo de Lista especifica el número de valores de 16 bits que existen en la Lista de Respuesta de Parámetro VCP. Si el Código de Respuesta no es igual a cero entonces el Número de Valores en el parámetro Lista es cero. El campo de Lista de Respuesta de Parámetro VCP contiene una lista de 0 hasta 32760 valores de 2 bytes que indica el conjunto de valores válidos para el control que no es continuo especificado mediante el campo Código de Control MCCS . Las definiciones de los códigos de control que no son continuos se especifican en la Especificación MCCS de VESA. Finalmente, en esta modalidad el campo CRC contiene una CRC de 16 bits de todos los bytes en el paquete incluyendo la Longitud de Paquete .

Imágenes Alfa-Cursor La interfaz MDD y el protocolo y los mecanismos inventivos asociados para comunicar datos a través de un enlace de comunicaciones proporciona un soporte para múltiples planos de imagen que se superponen entre sí y que pueden tener grados de transparencia variables. Puede implementarse un cursor de hardware utilizando la imagen superpuesta que tiene un desplazamiento variable X-Y. Una vista general de la funcionalidad Alfa-Cursor y el soporte de protocolo asociado se proporciona a continuación. La capacidad para soportar paquetes de imagen Alfa-Cursor se define en el Paquete de Capacidad de Imagen Alfa-Cursor, que se envía en respuesta a un Paquete de Estado Específico de Solicitud. 32. Paquete de Capacidad de Imagen Alfa-Cursor El Paquete de Capacidad de Imagen Alfa-Cursor se utiliza para definir las características de la imagen alfa-cursor y los mapas de transparencia asociados en un cliente. En una modalidad, un cliente indica una capacidad para soportar un Paquete de Capacidad de Imagen Alfa-Cursor utilizando un valor de parámetro de 133 en la Lista de Respuesta de Parámetro Válido del Paquete de la Lista de Respuesta de Estado Válido. La Longitud de Paquete especificada en el campo de longitud de paquete se establece para un valor fijo de 20 para una modalidad, sin incluir el campo de longitud de paquete. El formato del Paquete de Capacidad de Imagen Alfa-Cursor para una modalidad se muestra en la Figura 75. Como se ve en la Figura 75, este tipo de paquete esta estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clientec, Identificador Alfa-Cursor, Ancho de Mapa de Bit Alfa-Cursor, Altura de Mapa de Bit Alfa-Cursor, Capacidad RGB, Capacidad Monocromo, Reservado 1, Capacidad Y Cr Cb, Respuesta de Mapa de Transparencia, Bits de Capacidad y CRC. El campo ID de Clientec típicamente se reserva para un uso futuro de ID de Cliente y actualmente se establece en cero. El campo del Identificador Alfa-Cursor (2 bytes) contiene un valor que identifica un plano específico Alfa-Cursor. Si el cliente soporta un plano de imagen alfa-cursor n entonces el Identificador Alfa-Cursor tiene un rango válido de 0 a n-l. En una modalidad, el valor n se especifica mediante el campo Planos de Imagen Alfa-Cursor del Paquete de Capacidad de Cliente. El cliente devuelve un Paquete de Capacidad de Imagen Alfa-Cursor único para cada plano de imagen Alfa-Cursor. El valor del campo Ancho de Mapa de Bits Alfa-Cursor de 2 bytes especifica el ancho de la imagen del mapa de bit alfa-cursor expresado como un número de pixeles, aunque el valor del campo Altura del Mapa de Bits Alfa-Cursor de 2 bytes especifica la altura de la imagen del mapa de bits alfa-cursor expresada como un número de pixeles . El campo de Capacidad RGB utiliza 2 bytes para especificar el número de bits de resolución que pueden desplegarse en el formato RGB. Si el cliente no puede utilizar el formato RGB entonces este valor es cero. La palabra Capacidad RGB esta compuesta de tres valores separados, los cuales en una modalidad se implementan de modo que : Bits de 3 hasta 0 definen el número máximo de bits del azul (intensidad de azul) en cada píxel; los Bits 7 a 4 definen el número máximo de bits de verde (intensidad de verde) en cada píxel; los Bits 11 a 8 definen el número máximo de bits del rojo (intensidad de rojo) en cada píxel; y los Bits 15 a 12 están reservados para un uso futuro al presentar la información de la capacidad RGB así que generalmente se establecen en cero por ahora. El campo de Capacidad Monocromo de 1 byte se utiliza para especificar el número de bits de resolución que pueden desplegarse en el formato monocromo. Si un cliente no puede utilizar el formato monocromo entonces este valor se establece en cero. Los Bits 7 a 4 se reservan para un uso futuro y, por lo tanto, generalmente se establecen en cero. Los Bits 3 a 0 definen el número máximo de bits de la escala de grises que puede existir en cada píxel. Esos cuatro bits hacen posible especificar que cada píxel consiste de 1 a 15 bits. Si el valor es cero, entonces el formato monocromo no está soportado por el cliente. El campo Reservado 1 de 1 byte contiene un valor generalmente reservado para uso futuro, y tal como todos los bits en ese campo se establecen en cero. Esto provocará que sus frecuentes campos de 2 bytes se alineen con la dirección de la 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 Capacidad Y Cb Cr de 2 bytes contiene valores o información que especifican el número de bits de resolución que puedan desplegarse en el formato Y Cb Cr. Si el cliente no puede utilizar el formato Y Cr Cb entonces este valor es cero. Generalmente, en una modalidad, la palabra Capacidad Y Cb Cr esta compuesta de tres valores por separado con: Bits 3 a 0 que definen un número máximo de bits que especifica la muestra Cr; los Bits 7 a 4 que definen el número máximo de bits que especifican la muestra Cb; los Bits 11 a 8 que definen el número máximo de bits que especifican la muestra Y; y con los Bits 15 a 12 que se reservan para un uso futuro en la presentación de información o los valores de la Capacidad Y Cb Cr, aunque actualmente se establece en cero. El campo de Resolución de Mapa de Transparencia de 1 byte contiene valores o información que especifican el número de bits (profundidad) en cada ubicación de píxel del mapa de transparencia de imagen alfa-cursor. Este valor puede variar de 1 a 8. Si el valor es cero entonces el mapa de transparencia no está soportado por esta memoria intermedia de imagen alfa-cursor (la memoria intermedia especificada por el Campo Identificador Alfa-Cursor) . Se proporcionan valores o información para el campo de Capacidad de Bits de 1 byte que contiene un conjunto de indicadores que especifica las capacidades asociadas con la memoria intermedia de imagen alfa-cursor. En una modalidad, los indicadores están definidos de modo que: el Bit 0 actúa para seleccionar los datos de Píxel en el Paquete de Corriente de Video alfa-Cursor que va a estar en un formato empaquetado. El Bit 1 actúa para mostrar que los datos de mapa de transparencia en el Paquete de Transparencia Alfa-Cursor esta en un formato de paquete. Un ejemplo del byte alineado y los Datos de Mapa de transparencia empaquetados se muestran en la Figura 76. El Bit 2 actúa para mostrar que el plano de imagen alfa-cursor soporta la capacidad de desplazamiento de imagen utilizando el Paquete de Desplazamiento de Imagen Alfa-Cursor. El Bit 3 actúa para mostrar que el plano de imagen alfa-cursor puede soportar un formato de datos de mapa de color. La misma tabla de mapa de color se utiliza para los planos de imagen alfa-cursor ya que se utiliza para la memoria intermedia de imagen principal y las corrientes de video escaladas. El mapa de color se configura utilizando el Paquete de Mapa de Color descrito con anterioridad. Los Bits 7 a 4 están reservados para un uso futuro y generalmente, por lo tanto, se establecen en un nivel de cero o un valor lógico. 33. Paquete de Mapa de Transparencia Alfa-Cursor El Paquete de Mapa de Transparencia Alfa-Cursor define el contenido del mapa de transparencia de la imagen para el plano de imagen alfa-cursor especificado. Algunas aplicaciones pueden requerir un mapa de transparencia que es más grande que la cantidad de datos que pueden transmitirse en un sólo paquete. En esos casos, múltiples Paquetes de Mapa de Transparencia Alfa-Cursor pueden enviarse, cada uno con un subconjunto diferente de mapa de transparencia al utilizar los campos de Mapa de Transparencia X e Inicio Y descritos a continuación. Esos campos operan de manera similar al de los campos Inicio X e Inicio Y del Paquete de Corriente de Video. Un cliente indica una capacidad para soportar el paquete de mapa de transparencia alfa-cursor en una modalidad utilizando el campo de Resolución de Mapa de Transparencia del Paquete de Capacidad de Imagen Alfa-Cursor para cada Plano Alfa-Cursor específico especificado por el campo Identificador Alfa-Cursor del Paquete de Capacidad de Imagen Alfa-Cursor. Los campos Longitud de Paquete e ID de Cliente operan como anteriormente se discutió para otros paquetes. En una modalidad, un valor de 134 en el campo Tipo de Paquete se utiliza para identificar un paquete como un Paquete de Mapa de Transparencia Alfa-Cursor. El formato del Paquete de Mapa de Transparencia Alfa-Cursor para una modalidad se muestra en la Figura 76. Como se ve en la Figura 76, este tipo de paquete esta estructurado para tener campo de Longitud de Paquete, Tipo de Paquete, ID de Clienteh, Identificador Alfa-Cursor, Inicio X de Mapa de Transparencia, Inicio Y de Mapa de Transparencia, Resolución de Mapa de Transparencia, Reservado 1, Parámetro CRC, Medios de Mapa de Transparencia y CRC de Datos de Mapa de Transparencia. El campo Identificador Alfa-Cursor de 2 bytes tiene un valor que identifica un plano alfa-cursor específico. Si el cliente soporta planos de imagen alfa-cursor n entonces el Identificador Alfa-Cursor tiene un rango válido de 0 hasta n-l. Los campos de Inicio X e Y del Mapa de Transparencia de 2 bytes especifican cada uno las coordenadas absolutas X e Y, en donde el punto (Inicio Y de Mapa de Transparencia, Inicio X de Mapa de Transparencia) es el primer píxel en el campo de los Datos de Mapa de Transparencia a continuación. El campo de Resolución de Mapa de transparencia de (1 byte) contiene un valor que especifica la resolución del mapa de transparencia y si los datos están empaquetados o no. En una modalidad de este campo, los Bits 3 a 0 definen el número de bits de la resolución que existen en todos los elementos de la tabla del mapa de transparencia. Los valores válidos especifican el ancho que va de 1 a 8 bits. Los valores 0 y 9 a 15 se consideran inválidos. Este valor debe corresponder con el valor devuelto por un cliente en el campo de Resolución del Mapa de Transparencia en el Paquete de Capacidad de Imagen Alfa-Cursor. Los Bits 6 a 4 se reservan para un uso futuro y, por lo tanto, generalmente se establecen en cero-lógico en este momento. El Bits 7 de este byte especifica si los Datos de Mapa de Transparencia están empaquetados o no o en forma de byte alineado. Si el bit 7 es igual a ?l' entonces los Datos de Mapa te Transparencia están en forma de paquete, y si es l0' los datos son byte alineados. Un ejemplo de los datos empaquetados y byte alineado del Mapa de Transparencia se muestra en algún otro sitio. El valor de este bit debe corresponder al valor del bit 1 del campo Bits de Capacidad del Paquete de Capacidad de Imagen Alfa-Cursor. El campo del Reservado 1 de 1 byte se reserva para un uso futuro, por lo tanto, todos los bits en este campo generalmente se establecen igual a un nivel de cero-lógico. El propósito de este campo es provocar que todos los campos subsecuentes 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 direcciones de palabra de 32 bits. El campo de Parámetro CRC contiene una CRC de 16 bits de todos los bytes de la Longitud de Paquete en el campo Reservado 1. Si esta CRC falla al verificar, entonces todo el paquete se descarta. Para el campo de Datos de Mapa de Transparencia, cada ubicación de mapa de transparencia es de 1 a 8 bits de ancho. Si un sólo mapa de transparencia no puede ajustarse dentro de un Paquete del Mapa de Transparencia Alfa y Cursor, entonces todo el mapa de transparencia puede especificarse mediante el envío de múltiples paquetes con diferentes Datos de Mapa de Transparencia y valores de Inicio X e Y del mapa de transparencia en cada paquete. El campo CRC de Datos de Mapa de Transparencia de 2 bytes contiene una CRC de 16 bits de solamente los Datos de Mapa de Transparencia. Si esta CRC falla en verificar, entonces los Datos de Mapa de Transparencia pueden aún utilizarse aunque se incrementa el conteo de error CRC. 34. Paquete de Desplazamiento de Imagen Alfa-Cursor El Paquete de Desplazamiento de Imagen Alfa-Cursor especifica el desplazamiento X e Y del cursor de la esquina superior izquierda de la imagen de despliegue principal . El formato del Paquete de Desplazamiento de Imagen Alfa-Cursor se ilustra en la Figura 77. Como se muestra en la Figura 77, en una modalidad, el Paquete de Desplazamiento de Imagen Alfa-Cursor está estructurado con campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteh, Desplazamiento X Alfa-Cursor, Desplazamiento Y Alfa-Cursor, y CRC. En una modalidad, un cliente indica la capacidad para soportar el Paquete de Desplazamiento de Imagen Alfa-Cursor utilizando 2 bit del campo Bits de Capacidad del Paquete de Capacidad de Imagen Alfa-Cursor para cada plano Alfa-Cursor específico especificado mediante el campo del Identificador Alfa-Cursor del Paquete de Capacidad de Imagen Alfa-Cursor. En una modalidad, la longitud de paquete se fija en 10, como se muestra en el campo de Longitud de Paquete de 2 bytes. En una modalidad, un Tipo de Paquete de 135 identifica el paquete como un Paquete de Desplazamiento de Imagen Alfa-Cursor. Los campos de Desplazamiento X e Y Alfa-Cursor de 2 bytes contienen valores que especifican la horizontal y la vertical, respectivamente, el desplazamiento de la columna que se encuentra más a la izquierda y la fila superior, respectivamente de pixeles de la imagen de cursor del lado izquierdo y superior de la imagen principal . La ID de Clienteh - de 2 bytes que contiene un número entero sin signo de 16 bits reservada para el ID de Cliente. Este campo está reservado para un uso futuro y generalmente se establece en niveles de cero-lógico o valores para los bits.

. Paquete de Corriente de Video Alfa- Cursor El Paquete de Corriente de Video Alfa-Cursor porta datos de vídeo para actualizar una región rectangular de un plano de imagen alfa-cursor. El tamaño de esta región puede ser tan pequeño como un solo píxel o tan grande como la pantalla completa. El formato de Paquete de Corriente de Video Alfa-Cursor se ilustra en la Figura 78. Como se muestra en la Figura 78, en una modalidad el Paquete de Corriente de Video Alfa-Cursor está estructurado con campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteb, Atributos de Formato de Datos de Video, Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, Inicio X, Inicio Y, Conteo de Píxel, Datos de Píxel del Parámetro Crc y CRC de Datos de Píxel. En una modalidad, un cliente indica una capacidad para soportar el Paquete de Corriente de Video Alfa-Cursor y sus parámetros asociados al utilizar el Paquete de Capacidad de Imagen Alfa-Cursor para cada Plano Alfa-Cursor específico especificado mediante el campo Identificador Alfa-Cursor, del Paquete de Capacidad de Imagen Alfa-Cursor, y un valor de 17 en el campo tipo de paquete indica o identifica un paquete que es un Paquete de Corriente de Video Alfa-Cursor. El campo ID de Clienteh (2 bytes) se reserva para un uso futuro como una ID de Cliente, y generalmente se establece en cero entre tanto, como se entenderá bien en la técnica. El campo Descriptor de Formato de Datos de Video de 2 bytes contiene información o un valor que especifica el formato de cada píxel en los Datos de Píxel en la corriente presente en el paquete presente . El formato de datos de píxel debe cumplir con al menos uno de los formatos válidos para el plano de imagen alfa-cursor como se definió en el Paquete de Capacidad de Imagen Alfa-Cursor. El campo Descriptor de Formato de Datos de Video contiene un valor que define el formato de Píxel para el paquete actual solamente y no implica que se continuará utilizando un formato constante para la duración por la vida útil de una corriente de video en particular. La Figura HA A HE, anterior ilustra como se codifica el Descriptor de Formato de Datos de Video. El formato es como sigue : En una modalidad, cuando los bits [15:13] son ?000' entonces los datos de video consisten en una serie de pixeles de monocromo en donde el número de bits por píxel está definido por los bits 3 a 0 de la palabra Descriptor de Formato de Datos de Video. Los bits 11 a 4 se establecen entonces en cero. Cuando los bits [15:13] son Y01' entonces los datos de vídeo consisten en una serie de pixeles de color que especifican cada uno un color a través de un mapa de color (paleta) . Los bits 5 a 0 de la palabra Descriptor de Formatos de Datos de Video definen el número de bits por píxel, y los bits del 11 al 6 se establecen en cero. Cuando los bits [15:13] son v010' entonces los datos de video consisten en una serie de pixeles de color en un formato RGB en estado primario en donde los número de bits por píxel del rojo está definido por los bits 11 a 8, el número de bits por píxel del verde están definidos por los bits 7 a 4 y el número de bits por píxel del azul están definidos 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 el rojo, verde y azul. Cuando los bits [15:13] son ?011' entonces los datos de vídeo consisten en una serie de datos de vídeo en el formato 4:2:2 Y Cb Cr con información de luminancia y crominancia. El número de bits por píxel de la luminancia (Y) está definido por los bits 11 a 8, el número de bits del componente Cb está definido por los bits 7 a 4, y el número de bits del componente Cr está definido por los bits 3 a 0. Los componentes Cb y Cr se envían a la mitad de la velocidad de Y. Las muestras de vídeo en la porción de Datos de Píxel de este paquete se organizarán de esta manera: Cbn, Yn, Crn, Yn+1, Cbn+2 , Yn+2 , Crn+2 , Yn+3 , ... en donde Cbn y Crn se asocian con Yn y Yn+1, y Cbn+2 y Crn+2 se asocian con Yn+2 y Yn+3 etc. Yn, Yn+1, Yn+2 y Yn+3 , son valores de luminancia de cuatro pixeles consecutivos en una sola fila de izquierda a derecha. El ordenamiento de los componentes de color es el mismo como el formato Microsoft UYVY FOURCC. Si existe un número impar de pixeles en una fila (Borde Derecho X - Borde Izquierdo X+l) en la ventana a la que se hace referencia mediante el Paquete de Corriente de Video entonces el valor Cb que corresponde al último píxel en cada fila estará seguido por el valor Y del primer píxel en la siguiente fila. Se recomienda que las ventanas que utilizan el formato Y Cb Cr tengan un ancho que es de un número par de pixeles . Los Datos de Píxel en un paquete contienen un número par de pixeles. Pueden contener números de pixeles impares o pares en el caso donde el último píxel de los Datos de Píxel corresponda al último píxel de una fila en la ventana especificada en el encabezamiento 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. Para todos los cinco formatos, el bit 12 (designado como "P" en las figuras) especifica si las muestras Datos de Píxel están empaquetadas o no. Cuando el valor del bit 12 es '0' entonces cada píxel y cada color dentro de cada píxel en el campo de Datos de Píxel este byte se alinea con un límite de bytes de interfaz MDDI . Cuando el valor del bit 12 es Y' entonces cada píxel y cada color dentro de cada píxel en los Datos de Píxel se empaquetan contra el píxel o el color previo dentro de un píxel que deja bit sin utilizar. En una modalidad, el campo de Atributos de Datos de Píxel (2 byte) tiene una serie de valores de bits que se interpretan como sigue. Los Bits 1 y 0 seleccionan como se enrutan los datos de píxel de despliegue. Para los valores de bit de ? 11', los datos se despliegan para ambos ojos, para los valores de bit YO', los datos se enrutan solamente para el ojo izquierdo, y para los valores de bits 101', los datos se enrutan solamente para el ojo derecho. El bit 2 del campo de Atributos de Datos de Píxel indica si los datos de píxel están presentes o no en un formato de entrelazado con un valor de ?0' significando que los datos de Píxel están en el formato progresivo estándar, y que el número de fila (coordenada Y de Píxel) se incrementa por 1 cuando se avanza desde una fila a la siguiente. Cuando este bit tiene un valor de Y', los datos de Píxel están en el formato de entrelazado, y el número de filas 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 de entrelazado estándar habilitado por el bit 2, aunque el entrelazado es vertical en vez de horizontal . Cuando el bit 3 están en 10' los Datos de Píxel están en el formato progresivo estándar, y el número de columna (coordenada X de píxel) se incrementa por 1 conforme se recibe cada píxel sucesivo. Cuando el Bit 3 es Y' los Datos de Píxel están en un formato de píxel alterno, y el número de columnas se incrementa por 2 conforme se recibe cada píxel . El bit 4 del campo de Atributos de Datos de Píxel indica si los datos de Píxel se relacionan o no con una pantalla o una cámara, como cuando los datos se están transfiriendo hacia o desde una pantalla interna para un teléfono inalámbrico o un dispositivo similar o incluso una computadora portátil, o tales otros dispositivos como los que se discutieron anteriormente, o los datos que se transfieren hacia o desde una cámara integrada dentro de o acoplada directamente con el dispositivo. Cuando el Bit 4 es Y' los datos de Píxel que se transfieren hacia o desde una memoria intermedia de trama de pantalla. Cuando el bit 4 es ?l' los datos de Píxel que se transfieren hacia o desde una cámara o dispositivo de vídeo de algún tipo, tales dispositivos se conocen bien en la técnica. El Bit 5 del campo de Atributos de Datos de. Píxel se reserva para un uso futuro o para aplicaciones de la interfaz MDD y es, por lo tanto, generalmente se establece en el valor de cero o * 0 ' . Los Bits 7 y 6 del campo de Atributos de Datos de Píxel son bits de actualización de despliegue que especifican una memoria intermedia de trama en donde los datos de Píxel se van a escribir. Más efectos específicos se discuten en alguna otra parte . Para los valores de bits de x01' los datos de Píxel se escriben para la memoria intermedia de la imagen fuera de línea. Para los valores de bits de YO' de los datos de Píxel se escriben para la memoria intermedia de imagen utilizada para renovar el despliegue. Para valores de bits de ll' de los datos de Píxel se escriben para todas las memorias intermedias de imagen. Los valores de bits o la combinación de ?10' se tratan como un valor o designación inválida y los datos de Píxel se ignoran o no se escriben en ninguna de las memorias intermedias de la imagen. Este valor puede tener un uso para futuras aplicaciones de la interfase. Los bits 8 a 15 del campo de Atributos de Datos de Píxel se reservan para un uso futuro y por lo tanto, generalmente se establecen en cero. En una modalidad, los campos de Inicio X e Inicio Y de 2 bytes especifica las coordenadas absolutas X e Y del punto (Inicio X, Inicio Y) para el primer píxel en el campo de Datos de Píxel. Los campos del 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 imagen alfa-cursor rellenada por el campo 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 de imagen alfa-cursor que se esta actualizando. El campo Conteo de Píxel (2 bytes) especifica el número de pixeles en el campo de Datos de Píxel a continuación. El campo de Parámetro CRC de 2 bytes contiene una CRC de todos los bytes de la Longitud de Paquete en el Conteo de Píxel. Si esta CRC falla al verificar entonces todo el paquete se descarta. El campo de Datos de Píxel contiene la información de vídeo en estado primario que se está desplegando, y que se formatea en la manera descrita mediante el campo Descriptor de Formato de datos de Video.

Los datos se transmiten en una "fila" en un momento que se discutirá más adelante. El campo CRC de los Datos de Píxel (2 bytes) contiene una CRC de 16 bits de solamente los Datos de Píxel. Si una verificación CRC de este valor falla entonces los Datos de Píxel pueden aún utilizarse, pero el conteo de error de la CRC se incrementa.

Imágenes de Corriente de Video Escaladas La Interfaz o mecanismo de protocolo MDD, la estructura, el medio o el método proporciona soporte para imágenes de corriente de video escaladas que permiten al anfitrión enviar una imagen al cliente que se escala más grande o más pequeña que la imagen original, y la imagen escalada se copia a una memoria intermedia de imagen principal . Una vista general de la funcionalidad y el soporte del protocolo asociado de la Corriente de Video Escalada se proporciona más adelante. Una capacidad para proporcionar corriente de vídeo escaladas se define mediante o dentro del Paquete de Capacidad de Corriente de Video Escalada, que se envía en respuesta a un Paquete de Estado Específico de Solicitud. 36. Paquete de Capacidad de Corriente de Video Escalada El Paquete de Capacidad de Corriente de Video Escalada define las características de la imagen fuente de la corriente de video escalada en o utilizada por un cliente. El formato del Paquete de Capacidad de Corriente de Video Escalada se muestra generalmente en la Figura 79. Como puede verse en la Figura 79, en una modalidad, se estructura un Paquete de Capacidad de Corriente de Video Escalada para que tenga campos de Longitud de Paquete, Tipo de Paquete, ID de Clientec, Número de Corriente Máxima, Tamaño Máximo de Fuente X, Tamaño Máximo de Fuente Y, Capacidad RGB, Capacidad Monocromo, Reservado 1, Capacidad Y Cr Cb, Reservado 2 y CRC. La longitud de paquete en una modalidad, se selecciona para fijarse en 20 bytes como se muestra en el campo de longitud, que incluye el campo de la ID de Clientec de 2 bytes, que se reserva para utilizarla para una ID de Cliente, o que de otra manera se establece en cero, y el campo CRC. En una modalidad, el cliente indica una capacidad para soportar el paquete de capacidad de corriente de video escalada 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 Corriente Máximo de 2 byte contiene un valor para identificar el número máximo de corrientes de video escaladas simultáneas que pueden asignarse en un momento. En una modalidad, un cliente podría negar una solicitud para asignar una corriente de vídeo escalada si el número máximo de corrientes de video escaladas ya se ha destinado. Si se destinan menos del número máximo de corrientes de vídeo escaladas el cliente puede también negar una solicitud de destinación con base en otras limitaciones de la fuente en el cliente. Los campos de Tamaño X y Tamaño Y Máximo de la Fuente (2 bytes) especifican los valores para el ancho y altura máximos, respectivamente, de la imagen de la fuente de corriente de video escalada expresada como un número de pixeles . El campo de Capacidad RGB utiliza valores para especificar el número de bits de resolución que pueden desplegarse en el formato RGB. Si la corriente de video escalada no se utiliza en el formato RGB entonces este valor se establece igual a cero. La palabra Capacidad RGB está compuesta de tres valores sin signo separados con: los Bits 3 a 0 definen un número máximo de bits del azul (la intensidad de azul) en cada píxel, los Bits 7 a 4 definen el número máximo de bits del verde (intensidad de verde) en cada píxel, y los bits 11 a 8 definen el número máximo de bits de rojo (intensidad de rojo) en cada píxel, mientras que los Bits 15 a 12 se reservan para un uso futuro en definiciones de capacidad futuras y generalmente se establecen en cero. El campo de Capacidad Monocromo de 1 byte contiene un valor que especifica el número de bits de resolución que pueden desplegarse en el formato monocromo. Si la corriente de video escalada no puede utilizar el formado monocromo entonces este valor se establece en cero. Los Bits 7 a 4 se reservan para un uso futuro y, por lo tanto, debieran establecerse en cero (?0') para aplicaciones actuales, aunque esto puede cambiar con el tiempo, como lo apreciarán quienes tienen experiencia en la técnica. Los Bits 3 a 0 definen el número máximo de bits de la escala de grises que puede existir en cada píxel. Esos cuatro bits hacen posible especificar que cada píxel consiste de 1 a 15 bits. Si el valor es cero, entonces el formato monocromo no está soportado por la corriente de video escalada. El campo Reservado 1 (aquí de 1 byte) se reserva para un uso futuro al proporcionar valores relacionados con la información o los datos de paquete de Corriente de Video Escalada. Por lo tanto, en la actualidad, todos los bits en este campo se establecen en un ? 0' lógico. Un propósito en este campo es provocar que todos los campos subsecuentes de 2 bytes se alineen con una dirección de palabra de 16 bit y provocar que los campos de 4 bytes se alineen con direcciones 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 pueden desplegarse en el formato Y Cb Cr. Si la corriente de video escalada 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 signo separados con: los Bits 3 a 0 que definen el número máximo de bits que especifican la muestra Cr; los Bits 7 a 4 que definen el número máximo de bits que especifican la muestra Cb; los Bits 11 a 8 que definen el número máximo de bits que especifican la muestra Y, y con los Bits 15 a 12 que se reservan para un uso futuro y que generalmente se establecen 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 escalada. Los indicadores se definen de la siguiente forma: el Bit 0 cubre los datos de Píxel en el Paquete de Corriente de Video Escalada que puede ser de un formato empaquetado. Un ejemplo de los datos de píxel empaquetados y byte alineado se muestran previamente en la Figura 12. El Bit 1 se reserva para un uso futuro y generalmente se establece en cero; el Bit 2 también se reserva para un uso futuro y se establece en cero; el Bit 3 cubre corrientes de video escaladas que pueden especificarse en el formato de datos de mapa de color. La misma tabla del mapa de color se utiliza para las corrientes de video escaladas como se utilizan para la memoria intermedia de la imagen principal y los planos de imagen alfa-cursor. El mapa de color se configura utilizando el Paquete de Mapa de Color descrito más adelante; y los Bits 7 a 4 se reservan para un uso futuro y generalmente se establecen en cero. El campo Reservado 2 (aquí de 1 byte) se reserva para un uso futuro al proporcionar valores relacionados con información o datos de paquete de Corriente de Video Escalada. Por lo tanto, en la actualidad, todos los bits en este campo se establecen en un ?0' lógico. Un propósito de este campo es provocar que todos los campos de 2 bytes subsecuentes 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. 37. Paquete de Instalación de Corriente de Video Escalada El Paquete de Instalación de Corriente de Video Escalada se utiliza para definir los parámetros de la corriente de video escalada y los usos del cliente de la información para asignar un almacenamiento interno para poner en memoria interna y escalar la imagen. Una corriente se desasigna al enviar este paquete con los campos del Tamaño de Imagen X y el Tamaño de Imagen Y iguales a cero. Las corrientes de video escaladas que se han retirado de donde se han destinado pueden volverse a asignar más adelante con los mismos o diferentes parámetros de corriente. En una modalidad un cliente indica una capacidad para soportar el Paquete de Instalación de Corriente de Video Escalada 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 al utilizar un valor distinto de cero en el campo de Números de Corrientes Máximo del Paquete de Capacidad de Corriente de Video Escalada. El formato del Paquete de Instalación de Corriente de Video Escalada se muestra generalmente en la Figura 80. Como se ve en la Figura 80, en una modalidad, un Paquete de Instalación de Corriente de Video Escalada esta estructurada para tener campos de Tipo de Paquete de Longitud de Paquete, Clienteh, ID de Corriente, Descriptor de Formato de Datos Visuales, 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 específica el número total de bytes en el paquete que no incluyen el campo de longitud de paquete. En una modalidad, esta longitud de paquete se fija en 24. El campo Tipo de Paquete de 2 bytes emplea un valor de 136 para identificar el paquete como un Paquete de Instalación de Corriente de Video Escalada. El campo ID de dienten de 2 bytes se reserva para un uso futuro como una ID de Cliente, y generalmente se establece para y en todos los bits como un valor de cero-lógico por el momento o hasta que un usuario del protocolo determina que valores de ID se van a utilizar, como ya se conoce. El campo ID de Corriente utiliza 2 bytes para especificar un identificador único para la ID de Corriente. Este valor se asigna mediante el anfitrión y varía en su valor desde cero hasta el valor de la ID de Corriente máximo especificado en el Paquete de Capacidad de Cliente. El anfitrión debe administrar el uso de los valores de la ID de Corriente cuidadosamente para asegurarse de que a cada corriente se le asigne un valor único, y que las corrientes que ya no están activas se desasignan o se reasignan. En una modalidad, el campo 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 corriente presente en el paquete presente . El formato de datos de píxel debe cumplir con al menos uno de los formatos válidos para el plano de imagen alfa-cursor como se define en el Paquete de Capacidad de Imagen Alfa-Cursor. El Descriptor de Formato de Datos de Video define el formato de píxel para el paquete actual solamente y no implica que un formato constante continuará utilizándose durante la vida útil de una corriente de vídeo en particular. La FIGURA HA A HE ilustra una modalidad de cómo se codifica el Descriptor de Formato de Datos de Video, y como se discutió anteriormente para otros paquetes . El campo de Atributos de Datos de Píxel de 2 bytes tiene valores que se interpretan de la siguiente forma : Los Bits 1 y 0 seleccionan el despliegue cuando los datos de píxel se van a enrutar. Los Bits [1:0] =11 ó 00 - de los datos se despliegan para ambos ojos. Los Bits [1:0] =10 - de los datos se enrutan solamente para el ojo izquierdo. Los Bits [1:0] =01 - de los datos se enrutan solamente para el ojo derecho. El Bit 2 indica si los Datos de Píxel están o no en el formato de 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) se incrementa 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) se incrementa por dos cuando se avanza de una fila a la siguiente. El bits 3 indica si los Datos de Píxel están o no en el formato de píxel alterno. Esto es similar para el modo entrelazado estándar habilitado mediante el bit 2, pero el entrelazamiento es vertical en vez de horizontal.

Cuando el bit 3 es cero, los Datos de Píxel están en el formato progresivo estándar. El número de columna (coordenada X de Píxel) se incrementa por 1 conforme se recibe cada píxel sucesivo. Cuando el Bits 3 es 1, entonces los Datos de Píxel están en un formato de píxel alterno. El número de columna (coordenada X de Píxel) se incrementa por 2 conforme se recibe cada píxel . El Bit 4 indica si los datos de Píxel se relacionan con la pantalla o la cámara. Cuando el Bit 4 es 0, los Datos de Píxel son para o vienen desde la memoria intermedia de trama de despliegue. Cuando el Bit 4 es 1, los Datos de Píxel son para o vienen de la cámara. El Bit 5 se reserva para un uso futuro y, por lo tanto, generalmente se establece en cero. Los Bits 7 y 6 son los Bits de Actualización del Despliegue que especifican la memoria intermedia de la trama en donde se van a escribir los datos de píxel . Los efectos de los Bits de Actualización de trama se describen con más detalle más adelante. Cuando los Bits [7:6] son ?01', los datos de Píxel se escriben en la memoria intermedia de la imagen fuera de línea. Cuando los Bits [7:6] son 00' los datos de Píxel se escriben para que la memoria intermedia de la imagen los utilice para renovar el despliegue. Cuando los Bits [7:6] son Yl', los datos de Píxel se escriben para todas las memorias intermedias de imagen. Si los bits [7:6] son '10', estos se tratan como un valor inválido. Esos bits se reservan actualmente para un uso futuro. En esta situación, los datos de Píxel debieran ignorarse y no escribirse para ninguna de las memorias intermedias de la imagen.

Los Bits 8 a 15 se reservan para un uso futuro y generalmente se establecen en un nivel o valores de cero-lógico. 38 . Paquete de Reconocimiento de Corriente de Video Escalada El Paquete de Reconocimiento de Corriente de Video Escalada permite a un cliente reconocer la recepción de un Paquete de Instalación de Corriente de Video Escalada. El cliente puede indicar una capacidad para soportar el Paquete de Reconocimiento de Corriente de Video Escalada 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 distinto de cero en el campo Número de Corrientes Máximo del Paquete de Capacidad de Corriente de Video Escalada. El formato del Paquete de Reconocimiento de Corriente de Video Escalada se muestra generalmente en la Figura 81. Como puede verse en la Figura 81, en una modalidad, el Paquete de Reconocimiento de Corriente de Video Escalada se estructura para tener Campos de Longitud de Paquete, Tipo de Paquete, Clientec, ID de Corriente, Código ACK y CRC. El campo de Longitud de Paquete de 2 byte 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 Paquete de Reconocimiento de Corriente de Video Escalada. El campo ID de Clientec de 2 bytes se reserva para un uso futuro para el ID de Cliente, y generalmente se establece en cero. El campo ID de Corriente de 2 byte especifica un identificador único para la ID de Corriente. Este es el mismo valor asignado por el anfitrión en el Paquete de Instalación de Corriente de Video Escalada. El campo Código Ack de 2 bytes proporciona valores que contienen un código que describe el resultado final de un intento por actualizar la corriente de video escalada especificada. 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 desasignación de corriente fue exitoso. 2 - el intento inválido por asignar una ID de corriente que ya ha sido asignada. 3 - intento inválido para desasignar una ID de corriente que ya esta desasignada. 4 - el cliente no soporta las corrientes de video escaladas . 5 - los parámetros de corriente son inconsistentes con la capacidad de cliente. 6 - el valor de la ID de Corriente es más grande que el valor máximo permitido por el cliente. 7 - insuficientes recursos disponibles en el cliente para asignar la corriente especificada. El campo CRC de 2 byte contiene la CRC de todos los bytes en el paquete que incluye la Longitud de Paquete. 39. Paquete de Corriente de Video Escalada El Paquete de Corriente de Video Escalada se utiliza para transmitir los datos de píxel asociados con una corriente de video escalada específica. El tamaño de la referencia de región mediante este paquete se define mediante el Paquete de Instalación de Corriente de Video Escalada. El cliente puede indicar una capacidad para soportar el Paquete de Corriente de Video Escalada 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 utilizando una respuesta de asignación de corriente de video escalada exitosa en el campo del Código Ack del Paquete de Reconocimiento de Corriente de Video Escalada. El formato de una modalidad del Paquete de Corriente de Video Escalada se muestra generalmente en la Figura 82. Como puede verse en la Figura 82, un Paquete de Corriente de Video Escalada se estructura para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteh, ID de Corriente, Parámetro CRC, Conteo de Píxel, Datos de Píxel y CRC de Datos de Píxel . El campo Tipo de Paquete de 2 bytes utiliza un valor de 18 para identificar un paquete como un Paquete de Corriente de Video Escalada. El campo ID de Clienteh se reserva para la ID de Cliente, y generalmente se establece en cero. Como anteriormente, el campo ID de Corriente de 2 bytes especifica un identificador único para la ID de Corriente . Este valor es especificado por el anfitrión en el Paquete de Instalación de Corriente de Video Escalada y se confirma en el Paquete de Reconocimiento de Corriente de Video Escalada. El campo Conteo de Píxel de 2 bytes especifica el número de pixeles en el campo de Datos de Píxel a continuación. El campo de Parámetro CRC de 2 bytes tiene la CRC de todos los bytes desde la Longitud de Paquete hasta el Conteo de Píxel. Si esta CRC falla al hacer la verificación entonces todo el paquete se descarta. El campo de Datos de Píxel de 2 bytes contiene información de video en estado primario que se va a escalar y luego a desplegarse . Los datos se formatean de la manera descrita mediante el campo Descriptor de Formato de Datos de Video. Los datos se transmiten a una fila a la vez como se describió previamente . El campo CRC de Datos de Píxel de 2 bytes contiene una CRC de solamente los Datos de Píxel . Si esta CRC falla al verificar entonces los Datos de Píxel pueden aún utilizarse para que el conteo de error de CRC se incremente . 40. Paquete de Estado Específico de Solicitud El Paquete de Estado Específico de Solicitud proporciona un medio, mecanismo o método para que un anfitrión solicite que el cliente envíe un paquete de capacidad o estado de vuelta al anfitrión como se especifica en ese paquete. El cliente devuelve el paquete del tipo especificado en el siguiente Paquete de Encapsulamiento de Enlace de Retorno . El cliente establecerá 17 bits en el campo de Capacidad de Característica de Cliente del Paquete de capacidad de Cliente si el cliente tiene la capacidad para responder al Paquete de Estado Específico de Solicitud. Un método conveniente para que el anfitrión utilice la determinación de todos los tipos de paquetes de estado a los que puede responder el cliente es utilizar el Paquete de Lista de Respuesta de Estado Válido descrito e cualquier parte. El cliente puede indicar una capacidad para responder el Paquete de Estado Específico de Solicitud utilizando 21 bits del campo de Capacidad de Característica de Cliente del Paquete de capacidad de Cliente.

El formato de una modalidad de un Paquete de Estado Específico de Solicitud se muestra generalmente en la Figura 83. Como puede verse en la Figura 83, un Paquete de Estado Específico de Solicitud se estructura para gue tenga campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteh, ID del Paquete de Estado y CRC. El campo de Longitud de Paquete especifica el número total de bytes en el paquete que no incluyen el campo de Longitud de Paquete, y generalmente se fija en el 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 Clienteh (2 bytes) se reserva para un uso futuro para una ID de Cliente, y se establece en cero por ahora, aunque el campo ID del Paquete de Estado de 2 bytes especifica el tipo de paquete de capacidad o estado que el cliente va a enviar al anfitrión. Los tipos de paquetes típicos son: 66 - El Paquete de Capacidad de Cliente es enviado por el cliente. 133 - El Paquete de Capacidad de Imagen Alfa-Cursor es enviado por el cliente. 139 - Un Paquete de Lista de Respuesta de Estado Válido se envía el cual identifica los tipos exactos de paquetes de capacidad y estado que el cliente puede enviar. 140 - El Paquete de Parámetro de Retraso de Procesamiento de Paquete es enviado por el cliente. 141 - El Paquete de Capacidad de Cliente Personal es enviado por el cliente 142 - El Paquete de Reporte de Error de Cliente es enviado por el cliente. 143 - El Paquete de Capacidad de Corriente de Video Escalada es enviado por el cliente. 144 - El Paquete de Identificación del Cliente es enviado por el cliente. 145 - Paquete de Capacidad de Despliegue Alterno. Los Tipos de Paquetes 56 a 63 pueden utilizarse para los identificadores de capacidad y estado específicos del fabricante. El campo CRC de nuevo contiene una CRC de todos los bytes en el paquete que incluye la Longitud de Paquete. 41 . Paquete de Lista de Respuesta de Estado Válido El Paquete de Lista de Respuesta de Estado Válido proporciona al anfitrión con una estructura, medio o método para que tenga una lista de paquetes de estado y capacidad para los cuales el cliente tiene la capacidad de responder. Un cliente puede indicar una capacidad para soportar el Paquete de Lista de Respuesta de Estado Válido utilizando 21 bits del campo de Capacidad de Característica de Cliente del Paquete de Capacidad de Cliente. El formato de una modalidad del Paquete de Lista de Respuesta de Estado Válido se muestra generalmente en la Figura 84. Como puede verse en la Figura 84, un Paquete de Lista de Respuesta de Estado Válido está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clientec, Número de Valores en la Lista, Lista de Respuesta de Parámetro Válido y CRC. La Longitud de Paquete para este tipo de paquete generalmente 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 Clientec se reserva para un uso futuro de la ID de Cliente, y generalmente se establece en cero. El campo Número de Valores en la Lista de 2 bytes especifica el número de elementos 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 especifica los tipos de paquetes de capacidad o estado que el cliente puede enviar al anfitrión. Si el Cliente ha indicado que puede responder al Paquete de Estado Específico de Solicitud (utilizando 21 bits del campo de Capacidad de Características de Cliente en el Paquete de Capacidad de Cliente) entonces es capaz de enviar al menos el Paquete de Capacidad de Cliente (Tipo de Paquete = 66) y el Paquete de Lista de Respuesta de Estado Válido (Tipo de Paquete = 139) . Los Tipos de Paquete que pueden ser enviados por el cliente y que pueden incluirse en esta lista, junto con sus asignaciones respectivas para propósitos de una modalidad, son: 66 - Paquete de Capacidad de Cliente 133 - Paquete de Capacidad de Imagen Alfa-Cursor 139 - Paquete de Lista de Respuesta de Estado Válido, que identifica los tipos exactos de paquete de capacidad y estado que el cliente puede enviar. 140 - Paquete de Parámetro de Retraso de Procesamiento de Paquete . 141 - Paquete de Capacidad de Cliente Personal. 142 - Paquete de Reporte de Error de Cliente. 143 - Paquete de Capacidad de Corriente de Video Escalada. 144 - Paquete de Identificación de Cliente. Los Tipos de Paquetes 56 a 63 pueden utilizarse para los identificadores de capacidad y estado específicos del fabricante. El campo CRC contiene una CRC de todos los bytes en el paquete que incluyen la Longitud de Paquete. 42 . Paquete de Parámetros de Retraso de Procesamiento de Paquete El Paquete de Parámetros de Retraso de Procesamiento de Paquete proporciona un conjunto de parámetros para permitir al anfitrión calcular el tiempo que se requiere para completar el procesamiento asociado con la recepción de un tipo de paquete específico. Algunos comandos enviados por el anfitrión no pueden completarse mediante el cliente en el tiempo cero. El anfitrión puede consultar los bits de estado en el Paquete de Solicitud y Estado del Cliente para determinar si ciertas funciones han sido completadas por el cliente, o el anfitrión puede calcular el tiempo de finalización utilizando los parámetros que fueron devueltos por el cliente en el Paquete de Parámetros de Retraso de Procesamiento de Paquete. El cliente puede indicar una capacidad para soportar el Paquete de Parámetros de Retraso de Procesamiento de Paquete utilizando un valor de parámetro de 140 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido. El formato de una modalidad de un Paquete de Parámetros de Retraso de Procesamiento de Paquete se muestra generalmente en la Figura 85A. Como puede verse en la Figura 85A, un Paquete de Parámetros de Retraso de Procesamiento de Paquete se estructura para que tenga campos de Longitud de Paquete, Tipo de Paquete, ID de Clientec, Número de Elementos en la Lista, Lista de Parámetros de Retraso y CRC. La Longitud de Paquete para este tipo de paquete generalmente se fija en un valor de 10, y un valor de tipo de 140 identifica el paquete como un Paquete de Parámetros de Retraso de Procesamiento de Paquete. El campo ID de Clientec se reserva para un uso futuro como la ID de Cliente, y generalmente se establece en cero. El campo del Número de Elementos en la Lista de 2 bytes especifica el número de elementos en la siguiente Lista de Respuesta de Parámetro Válido. El campo de Lista de Parámetros de Retraso es una lista que contiene uno o más elementos de la Lista del Parámetro de Retraso. El formato para una modalidad de un sólo elemento de la Lista de Parámetro de Retraso se muestra en la Figura 85B, en donde los campos Tipo de Paquete para el Retraso, Retraso de Píxel, Retraso de Píxel Horizontal, Retraso de Píxel Vertical y de Retraso Fijo se muestran. Cada Elemento en la Lista de Parámetros de Retraso generalmente se restringe a 6 bytes de longitud, y se define adicionalmente como sigue. El campo de retraso para Tipo de Paquete de 2 bytes especifica el tipo de paquete para el cual aplican los parámetros de retraso siguientes. El campo Retraso de Píxel (1 byte) comprende un índice para un valor de retraso. La lectura del valor de la tabla se multiplica por el número total de pixeles en el campo de destino del paquete. El número total de pixeles es las veces que el ancho de la altura del área de destino del mapa de bits hace referencia mediante el paquete. El campo Retraso de Píxel Horizontal de 1 byte contiene un valor que es un índice para una tabla de valor de retraso (misma tabla que DPVL) . La lectura del valor de la tabla se multiplica por el ancho (en pixeles) del campo de destino del paquete. El campo Retraso de Píxel Vertical de 1 byte contiene un valor que es un índice para una tabla de valor de retraso (generalmente utiliza la misma tabla que DPVL) . La lectura de valor de la tabla se multiplica por la altura (en pixeles) del campo de destino del paquete. El campo Retraso Fijo utiliza 1 byte como un índice para una tabla de valor de retraso (misma tabla que DPVL) . La lectura de valor de la tabla es un parámetro de retraso fijo que representa un tiempo que se requiere para procesar el paquete que no está relacionado con ninguno de los valores de parámetro especificados en el paquete. El retraso total o el retraso de tiempo para completar el procesamiento del paquete, se determina de acuerdo con la relación: Retraso= (PacketProcessingDelay (PixelDelay) «TotalPixels) + (PacketProcessingDelay (HorizontalPixelDelay) »Width) + (PacketProcessingDelay (VerticalPixelDelay) »Height) + PacketProcessingDelay (FixedDelay) Para algunos paquetes, los Pixeles Totales, Ancho o Altura no aplican debido a que esos parámetros no tienen referencia en el paquete correspondiente. En esos casos, el parámetro de Retraso de Píxel correspondiente generalmente se establece para que sea cero. 43 . Paquete de Capacidad de Despliegue Personal El Paquete de Capacidad de Despliegue Personal proporciona un conjunto de parámetros que describe las capacidades de un dispositivo de despliegue personal, tales como una pantalla montado en la cabeza o lentes de pantalla. Esto habilita al anfitrión para que haga una adaptación personal de la información del despliegue de acuerdo con las capacidades específicas de un cliente, un cliente, por otro lado, indica una capacidad para enviar el Paquete de Capacidad de Despliegue Personal al utilizar un parámetro correspondiente en la Lista de Repuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido. El formato de una modalidad de un Paquete de Capacidad de Despliegue Personal se muestra generalmente en la Figura 86. Como puede verse en la Figura 86, un Paquete de Capacidad de Despliegue Personal está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clientec, Distribución de Sub-píxel, Forma de Píxel, Campo o Vista Horizontal, Campo o Vista Vertical, Cruzamiento de Eje Visual, Imagen Izquierda/Derecha, Transparencia, Brillo Máximo, Capacidad Óptica, IPD Mínimo, IPD Máximo, Puntos de Campo de Lista de Curvatura y CRC. En una modalidad, el valor de campo de Longitud de Paquete se fija en 68. Un valor del Tipo de Paquete de 141 identifica un paquete como un Paquete de Capacidad de Despliegue Personal . El campo ID de Clientec está reservado para un uso futuro y generalmente se establece en cero por ahora. El campo de Distribución de Sub-Píxel especifica la distribución física de un sub-píxel desde la parte superior hasta la parte inferior y de izquierda a derecha, utilizando los valores de: 0 para indicar que una distribución de sub-píxel no está definida; 1 para indicar la banda roja, verde y azul; 2 para indicar la banda azul, verde o roja; 3 para indicar píxel cuádruple, que tiene una disposición de sub-píxel de 2 por 2 de rojo en la parte superior izquierda, azul en la parte inferior derecha, dos sub-pixeles verde, uno en la parte inferior izquierda y otro en la parte superior derecha; 4 para indicar un píxel cuádruple, con una disposición de sub-píxel de 2 por 2 en rojo en la parte inferior izquierda, azul en la parte superior derecha, y dos sub-pixeles verdes, uno en la parte superior izquierda y otro en la parte inferior derecha; 5 para indicar un Delta (Triada) ; 6 para indicar un mosaico con rojo, verde y azul sobrepuestos, (por ejemplo pantalla LCOS con color de campo en secuencia) ; y con valores de 7 a 255 que generalmente se reservan para un uso futuro. El campo Forma de Píxel especifica la forma de cada píxel que está compuesto de una configuración de sub-pixeles específica, utilizando un valor de: 0 para indicar que no se ha definido la forma de un sub-píxel; 1 para indicar redondo; 2 para indicar cuadrado; 3 para indicar rectangular; 4 para indicar oval; 5 para indicar elíptico y con los valores de 6 a 255 se reservan para un uso futuro en la indicación de formas deseadas como lo puede apreciar alguien con experiencia en la técnica. Un campo de Campo Horizontal de Visión (HFOV) de 1 byte especifica el campo de visión horizontal en incrementos de 0.5 grados (por ejemplo si el HFOV es de 30 grados, este valor es 60) . Si este valor es cero entonces no se especifica el HFOV. Un campo de Campo Vertical de Visión (VFOV) de 1 byte especifica el campo de visión vertical en incrementos de 0.5 grados (por ejemplo si el VFOV es de 30 grados, ese valor es 60) . Si este valor es cero entonces no se especifica el VFOV. Un campo Cruzamiento de Eje Visual de 1 byte especifica el cruzamiento del eje visual en incrementos de dioptrías de 0.01 (l/m) (por ejemplo, si el cruzamiento del eje visual es 2.22 metros, este valor es 45) . Si este valor es cero, entonces el Cruzamiento del Eje Visual no se especifica. Un campo de Superposición de Imagen Izquierda/Derecha de 1 byte especifica el porcentaje de superposición de una imagen izquierda y derecha. El rango permisible de la superposición de la imagen porcentual es de 1 a 100. Los valores 101 a 255 son inválidos y generalmente no se van a utilizar. Si este valor es cero, entonces la superposición de imagen no se especifica. Un campo de Transparencia de 1 byte especifica el porcentaje de transparencia de la imagen. El rango permisible de transparencia en porcentaje es de 0 a 100. Los valores de 101 a 254 son inválidos y no se van a utilizar. Si este valor es 255 entonces el porcentaje de transparencia no se especifica. Un campo de Brillo Máximo de 1 byte específica el brillo máximo en incrementos en 20 nits (por ejemplo, si el brillo máximo es de 100 nits, este valor es 5) . Si este valor es cero entonces el brillo máximo no se especifica. Un campo Indicador de Capacidad Óptica de 2 bytes contiene varios campos que especifican capacidades ópticas de la pantalla. Esos valores de bits generalmente se asignan de acuerdo con: Los Bits 15 a 5 se reservan para un uso futuro, generalmente se establecen en un estado de cero lógico. El Bit 4 selecciona el Ajuste del Enfoque del Cristal Ocular, con un valor de ?0' que significa que la pantalla no tiene un ajuste del cristal ocular, y un valor de Y' que significa que la pantalla tiene un ajuste del cristal ocular. Los Bits 3 a 2 seleccionan una Función Binocular de acuerdo con: un valor de 0 significa que la pantalla es binocular y puede desplegar solamente imágenes bidimensionales (2D) ; 1 significa que la pantalla es binocular y que puede desplegar imágenes tridimensionales (3D) ; 2 significa que la pantalla es monocular, y 3 se reserva para un uso futuro. Los Bits 1 a 0 seleccionan la Simetría de la Curvatura del Campo Izquierda-Derecha, con un valor de 0 que significa la curvatura del campo no se define. Si este campo es cero entonces todos los valores de curvatura de campo desde Al a E5 se establecen en cero a excepción del punto C3 que especifica una distancia focal de la pantalla o que se establece en cero para indicar una distancia focal no especificada. Un valor de 1 significa despliegues de izquierda y derecha que tienen la misma simetría; 2 significa despliegues izquierda y derecha que están reflejados en el eje vertical (columna C) ; y 3 se reserva para un uso futuro . El campo Distancia Mínima Interpupilar (IPD) de 1 byte especifica la distancia interpupilar mínima en milímetros (mm) . Si este valor es cero entonces la distancia interpupilar mínima no se especifica. El campo Máxima Distancia Interpupilar (IPD) de 1 byte especifica la distancia interpupilar máxima en milímetros (mm) . Si este valor es cero entonces la distancia interpupilar máxima no se especifica. El campo de Lista de Curvatura de Puntos de Campo contiene una lista de 25 parámetros de 2 bytes que especifican la distancia focal en milésimas de una 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 Curvatura de Puntos de Campo se etiquetan de Al a E5 como se muestra a continuación. Los puntos se van a distribuir uniformemente sobre 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. A B C D E 0 El campo CRC contiene una CRC de todos los bytes en el paquete que incluye la Longitud de Paquete . 44. Paquete de Reporte de Error de Cliente El Paquete de Reporte de Error de Cliente actúa 5 como un mecanismo o medio para permitir a un cliente que proporcione una lista de errores de operación al anfitrión.

El cliente puede detectar un amplio rango de errores en el curso de su operación normal como resultado de la recepción de ciertos comandos desde el anfitrión. Los ejemplos de 0 esos errores incluyen: puede habérsele ordenado al cliente que operará en un modo que no soporta, el cliente puede haber recibido un paquete que contiene ciertos parámetros que están fuera del rango o que están más allá de la capacidad del cliente, puede habérsele ordenado al cliente 5 que ingresara un modo en una secuencia inapropiada. El Paquete de Reporte de Error de Cliente puede utilizarse para detectar errores durante una operación normal, pero es más útil para el diseñador e integrador del sistema diagnosticar problemas en el desarrollo e integración de los sistemas del anfitrión y el cliente. Un cliente indica su capacidad 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. El formato de una modalidad de un Paquete de Reporte de Error de Cliente se muestra generalmente en la Figura 87A. Como se muestra en la Figura 87A, un Paquete de Reporte de Error de Cliente está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cuentee, Número de Elementos de la Lista, Lista del Código de Error y CRC. Un valor de Tipo de Paquete de 142 identifica un paquete como un Paquete de Reporte de Error de Cliente. El campo ID de Clientec está reservado para un uso futuro y generalmente se establece en cero por ahora. El campo de Número de Elementos en la Lista (2 bytes) especifica el número de elementos en la siguiente Lista de Código de Error. El campo de Lista de Código de Error (aquí de 8 bytes) es una lista que contiene uno o más elementos de Lista de Reporte de Error. El formato de un sólo elemento de la lista de reporte de error se muestra en la Figura 87B. En una modalidad, como se muestra en la Figura 87B, cada elemento de la Lista de Reporte de Error es exactamente de 4 bytes de longitud, y tiene una estructura en una modalidad que comprende: un campo de Código de Error de Despliegue de 2 bytes que especifica el tipo de error que se está reportando, un campo de sub-código de error de 2 bytes especifica un nivel mayor de detalle con respecto al error definido por el Paquete de Código de Error de Cliente. La definición especifica de cada Código de Error de Cliente está definida por el fabricante del cliente. Un sub-código de error no tiene que definirse para cada Código de Error de Despliegue, y en esos casos en 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 está definido por el fabricante del cliente. 45. Paquete de Identificación de Cliente El Paquete de Identificación de 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 capacidad para enviar el Paquete de Identificación de 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.

Es útil para el anfitrión estar en posibilidad de determinar el nombre del fabricante del dispositivo de cliente y el número de modelo al leer estos datos del cliente. La información puede utilizarse para determinar si el cliente tiene capacidades especiales que no pueden describirse en el Paquete de Capacidad de cliente. Hay potencialmente dos métodos, medios o mecanismos para leer la información de Identificación de Cliente. Uno es a través del uso del Paquete de Capacidad de Cliente, que 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 de Cliente que contiene un conjunto más rico de información comparado con los campos similares en el Paquete de Capacidad de Cliente. Esto le permite a un anfitrión identificar a los fabricantes a los que no se les ha asignado un código EISA de tres caracteres, y permite números de serie que contengan caracteres alfanuméricos . El formato de una modalidad de un Paquete de Identificación de Cliente se muestra generalmente en la Figura 88. Como se puede ver en la Figura 88, un Paquete de Identificación de Cliente está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clientec, Semana de Fabricación, Año de Fabricación, Longitud del Nombre de Fabricación, Longitud del Nombre del Producto, Longitud del Número de Serie, Serie de Caracteres del Nombre del Fabricante, Serie de Caracteres del Nombre del Producto, Serie de Caracteres del Número de Serie y CRC. El campo Tipo de Paquete de 2 bytes contiene un valor que identifica el paquete como un Paquete de Identificación de Cliente. Este valor se selecciona para que sea 144 en una modalidad. El campo ID de Clientec (2 bytes) de nuevo se reserva para un uso futuro para la ID de Cliente, y generalmente se establece en cero. El campo CRC (2 bytes) contiene una CRC de 16 bits de todos los bytes en el paquete que incluye la Longitud de Paquete . Un campo de Semana de Fabricación de 1 byte contiene un valor que identifique la semana de fabricación de la pantalla. En al menos una modalidad, este valor está en el rango de 1 a 53 si está soportado por el cliente. Si este campo no está soportado por el cliente entonces se establece generalmente 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 un desplazamiento del año 1990 como un punto de inicio, aunque podrían utilizarse otros años base. Los años en el rango de 1991 a 2245 podrían expresarse mediante este campo. Por ejemplo: el año 2003 corresponde a un Valor de Año de Fabricación de 13. Si este campo no estuviera soportado por el cliente se establecería en un valor de cero.

Los campos de Longitud del Nombre del Fabricante, Longitud del Nombre del Producto, y Longitud del Número de Serie contienen cada uno valores de 2 bytes que especifican la longitud del campo Serie de Caracteres del Nombre del Fabricante que incluyen cualquier caracteres de terminación nula o de relleno nulos, la longitud del campo Serie de Caracteres del Nombre del Producto que incluyen cualesquiera caracteres de terminación nulos o de relleno nulos, o la longitud del campo de la serie de caracteres del número de serie que incluyen caracteres de terminación nulos o de relleno nulos, respectivamente. Los campos de la Serie de Caracteres del Nombre del Fabricante, Serie de Caracteres del Nombre del Producto, y la Serie de Caracteres del Número de Serie, contiene cada uno un número variado de bits especificados mediante los campos de Longitud del Nombre del Fabricante, el Nombre del Producto y los de Número de Serie, respectivamente, que contienen una serie de caracteres ASCII que especifica el fabricante, nombre del producto y número de serie alfanumérico de la pantalla, respectivamente. Cada uno de estos números de serie son terminados mediante al menos un carácter nulo . 46. Paquete de Capacidad de Pantalla Alterna El Paquete de Capacidad de Pantalla Alterna indica la capacidad de pantalla alterna unida al controlador del cliente MDDI . Se envía en respuesta a un Paquete de Estado Específico de Solicitud. Cuando se estimula, un dispositivo de cliente envía un Paquete de Capacidad de Pantalla Alterna para cada pantalla alterna que se soporte. El cliente puede indicar una capacidad para enviar el 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 los sistemas MDDI operados en un modo interno puede ser común tener más de una pantalla conectada a un controlador del cliente MDDI. Un ejemplo de aplicación es un teléfono móvil con una enorme pantalla en el interior de la transición y una pantalla más pequeña en el exterior. No es necesario que un cliente del modo interno regrese un Paquete de Capacidad de Despliegue Alterna por dos razones potenciales: primero, el anfitrión puede estar ya programado o informado de otra manera de las capacidades durante la fabricación dado que se utilizan en un dispositivo o alojamiento común; segundo, debido al ensamblaje de los dos, el cliente no puede desconectarse o separarse con facilidad de una conexión con el anfitrión, y el anfitrión puede contener una copia de programación cerrada de las capacidades del cliente, o al menos no cambian con un cambio del cliente, como podría ocurrir de otra manera. El campo Número de Pantalla Alt del Paquete de Capacidad de Cliente se utiliza para reportar que más de una pantalla está unida 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 dirigirse a cada pantalla alterna en el dispositivo de cliente. El formato de una modalidad de un Paquete de Capacidad de Pantalla Alterna se muestra generalmente en la FIGURA 89. Como puede verse en la FIGURA 89, un Paquete de Capacidad de Pantalla Alterna está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clientec, Número de Pantalla Alt, Reservado 1, Ancho de Mapa de Bit, Alto de Mapa de Bit, Ancho de Ventana de Despliegue, Alto de Ventana de Despliegue, Ancho RGB del Mapa de Color, Capacidad RGB, Capacidad Monocromo, Reservado 2, Capacidad Y Cb Cr, Capacidad de Característica de Despliegue, Reservado 3, 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 Clientec está reservado para una ID de Cliente para un uso futuro y generalmente se establece en cero. El Campo Número de Pantalla Alt utiliza 1 byte para indicar la identidad de la pantalla alterna con un número entero del rango de 0 hasta 15. La primer pantalla alterna típicamente se designa con el número 0 y las otras pantallas alternas se identifican con valores de Número de Pantalla Alt únicos con el valor más grande utilizado como el número total de pantallas alternas menos 1. Los valores más grandes que el número total de pantallas alternas menos 1 no se utilizan. Ejemplo: un teléfono móvil que tiene una pantalla principal y un despliegue del ID de quien llama conectado a un cliente MDDI tiene una pantalla alterna, así que el Número de Pantalla Alt del despliegue del ID de quien llama es cero y el Campo de Número de Pantalla Alt del Paquete de Capacidad de Cliente tiene un valor de 1. El campo Reservado 1 (1 byte) está reservado para un uso futuro. Todos los bits en este campo se establecen en cero . Un propósito de este campo es provocar que todos los campos de 2 bytes subsecuentes se alineen con una dirección de palabra de 16 bits y provocar que los campos de 4 bytes se alineen con direcciones de palabra de 32 bits. El campo Ancho de Mapa de Bit utiliza 2 bytes que especifican el ancho de mapa de bit expresado como un número de píxeles . El campo Altura del Mapa de Bits utiliza 2 bytes que especifican la altura del mapa de bits expresada como un número de píxeles. El Campo Ancho de la Ventana de Despliegue utilizada 2 bytes que especifican el ancho de la ventana de despliegue expresado como un número de píxeles. El campo Altura de la Ventana de Despliegue utiliza 2 bytes que especifican la altura de la ventana de despliegue expresada como un número de píxeles. El campo Ancho RGB del Mapa de Color utiliza 2 bytes que especifican el número de bits en los componentes de color rojo, verde y azul que pueden desplegarse en el modo despliegue de mapa de color (paleta) . Puede utilizarse un máximo de 8 bits por cada componente de color (rojo, verde y azul) . Aunque se envían 8 bits de cada componente de color en el Paquete del Mapa de Color, solamente se utilizan el número de los últimos bits significativos de cada componente de color definido en este campo. Si la pantalla del cliente no puede utilizar el mapa de color (paleta) el- formato entonces de este valor es cero. La palabra del Ancho RGB del mapa de color está compuesta de tres valores sin signo separados: los Bits 3 hasta 0 definen un número máximo de bits de azul en cada píxel con valores de 0 a 8 que se consideran válidos. Los Bits 7 hasta el 4 definen el número máximo de bits del verde en cada píxel con los valores de 0 a 8 que se consideran válidos. Los Bits 11 hasta el 8 definen el número máximo de bits de rojo en cada píxel con valores de 0 a 8 que se consideran válidos. Los Bits 14 hasta 12 están reservados para un uso futuro y generalmente se establecen en cero. El Bit 15 se utiliza para indicar la capacidad de un cliente para aceptar datos de Píxel en el Mapa de color en un formato empaquetado o desempaquetado. Cuando el Bit 15 se establece en un nivel de uno-lógico, esto indica que el cliente puede aceptar los datos de Píxel del Mapa de Color ya sea en un formato empaquetado o desempaquetado. Si el bit 15 se establece en un cero-lógico, esto indica que el cliente puede aceptar datos de píxel del Mapa de Color solamente en un formato desempaquetado . El campo _de Capacidad RGB utiliza 2 bytes para especificar el número de bits de resolución que pueden desplegarse 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 signo separados : Los Bits de 3 hasta 0 definen el número máximo de bits del azul (la intensidad del azul) en cada píxel, los Bits de 7 hasta 4 definen el número máximo de bits del verde (intensidad del verde) en cada píxel, y los Bits 11 hasta el 8 definen el número máximo de bits del rojo (intensidad del rojo) en cada píxel . Los Bits 14 hasta el 12 están reservados para un uso futuro y se establecen en cero. El Bit 15 se utiliza para indicar la capacidad de un cliente para aceptar datos de píxel RGB en un formato empaquetado o desempaquetado. Cuando el Bit 15 se establece en un nivel de uno-lógico, esto indica que el cliente puede aceptar los datos de píxel RGB ya sea en un formato empaquetado o desempaquetado. Si el bit 15 se establece en un cero-lógico, esto indica que el cliente puede aceptar solamente datos de píxel RGB en un formato desempaquetado . El campo de Capacidad de Monocromo de 1 byte contiene un valor o información para especificar el número de bits de resolución que pueden desplegarse en el formato monocromo. Si el cliente no puede utiliza el formato monocromo entonces este valor se establece igual a cero. Los Bits 6 hasta el 4 están reservados para un uso futuro y generalmente se establecen en cero. Los Bits 3 hasta 0 definen el número máximo de bits de la escala de grises que puede existir en cada píxel. Estos cuatro bits hacen posible especificar que cada píxel consiste de 1 a 15 bits. Si el valor es cero entonces el formato monocromo no está soportado por el cliente. El Bit 7 cuando se establece en uno indica que el cliente puede aceptar los datos de Píxel monocromo en cualquier formato empaquetado o desempaquetado. Si el bit 7 se establece encero esto indica que el cliente puede aceptar datos de píxel monocromo solamente en un formato desempaquetado. El campo Reservado 2 es un campo de un ancho de 1 byte reservado para un uso futuro y generalmente tiene todos los bits en este campo establecidos en un nivel de cero-lógico. En una modalidad, un propósito de este campo es provocar que todos los campos de 2 bytes subsecuentes se alineen con una dirección de palabras de 16 bits y provocar 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 específica el número de bits de resolución que puedan desplegarse 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 de tres valores sin signo separados : los Bits 3 hasta 0 definen el número máximo de bits que especifica la muestra Cb, los Bits 7 hasta 4 definen el número máximo de bits que especifica la muestra Cr, los Bits 11 hasta el 8 definen el número máximo de bits que especifican la muestra Y y los Bits 14 hasta 12 están reservados para un uso futuro y se establecen en cero. Cuando el Bit 15 se establece en uno indica que el cliente puede aceptar datos de píxel Y Cb Cr en cualquier formato empaquetado o desempaquetado. Si el bit 15 se establece en cero esto indica que el cliente puede aceptar solamente datos de píxel Y Cb Cr en un formato desempaquetado . Un campo de Capacidad Bayer de 1 byte especifica el número de bits de resolución, el grupo de píxel y el orden de píxel que puede transferirse en el 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 hasta 0 definen el número máximo de bits de intensidad que existe en cada píxel, los Bits 5 hasta 4 definen el patrón de grupo de píxel que puede requerirse, los Bits 8 hasta 6 definen un orden de píxel que se requiere, y los Bits 14 hasta el 9 están reservados para un uso futuro 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 cualquier formato empaquetado o desempaquetado . Si el bit 15 se establece en cero esto indica que el cliente puede aceptar solamente datos de píxel Bayer en un formato desempaquetado . El campo CRC de 2 bytes contiene una CRC de 16 bits de todos los bytes en el paquete incluyendo La Longitud de Paquete . 47. Paquete de Acceso de Registro El Paquete de Acceso de Registro proporciona ya sea un anfitrión o un Cliente con un medio, mecanismo o método para tener acceso a la configuración y a los registros de estado en el extremo opuesto del enlace MDDI .

Esos registros probablemente van a ser únicos para cada controlador de pantalla o dispositivo. Esos registros ya existen en muchas pantallas que requieren configuraciones de ajuste, modos de operación, y que tienen otros ajustes útiles y necesarios. El Paquete de Acceso de Registro permite que el anfitrión o el cliente MDDI escriban ambos en un registro y soliciten la lectura de un registro utilizando el enlace MDDI. Cuando el anfitrión o el cliente solicitan leer un registro, el extremo opuesto debe responder por medio de Datos de Registro en el mismo tipo de paquete, pero también al indicar que esta es una lectura de datos de un registro en particular con el uso del campo Información de Lectura/Escritura. El Paquete de Acceso de Registro puede utilizarse para leer o escribir en múltiples registros mediante la especificación de un conteo del registro mayor a uno. Un cliente indica una capacidad para soportar el Paquete de Acceso de Registro utilizando 22 bits del campo de Capacidad de Característica de Cliente de del Paquete de Capacidad de Cliente. El formato de una modalidad de un Paquete de Acceso de Registro se muestra generalmente en la FIGURA 90. Como se ve en la FIGURA 90, un Paquete de Acceso de Registro está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Clienteb, Indicadores de Leer/Escribir, Dirección de Registro, Parámetro CRC, Lista de Datos de Registro, CRC de Datos de Registro. Un valor Tipo de Paquete de 146 identifica un paquete como un Paquete de Acceso de Registro. El campo ID de Clienteb está reservado para un uso futuro y generalmente se establece en cero por ahora. El campo Indicadores de Lectura/Escritura de 2 bytes especifica el paquete específico ya sea por escrito o de lectura, o en respuesta a una lectura, y proporciona un conteo de los valores de datos . Los Bits 15 hasta el 14 actúan como los Indicadores de Lectura/Escritura. Si los Bits [15:14] son ? 00' entonces este paquete contiene datos que van a escribirse en un registro dirigido mediante el campo de Dirección de Registro. Los datos que se van a escribir para los registros específicos están contenidos en el campo de Lista de Datos de Registro. Si los Bits [15:14] son YO', entonces esta es una solicitud de datos de uno o más registros dirigidos por el campo de Dirección de Registro. Si los Bits [15:14] son lll' entonces ese paquete contiene datos que son solicitados en respuesta a un Paquete de Acceso de Registro que tiene los bits 15:14 de los Indicadores de Lectura/Escritura establecidas en ?10' . El campo dirección de registro Contiene la Dirección de Registro que corresponde al primer elemento de la Lista de Datos de Registro, y el campo de Lista de Datos de Registro contiene los datos que se leen desde la dirección o las direcciones. Si los Bits [15:14] son l01' estos se tratan como un valor inválido, este valor se reserva para un uso futuro y no se utiliza. Los Bits 13:0 utilizan un número entero sin signo de 14 bits para especificar el número de los elementos de Datos de Registro de 32 bits que se van a transferir en el campo de Lista de Datos de Registro. Si los bits 15:14 son iguales a ?00' entonces los bits 13:0 especifican el número de los elementos de los datos de registro de 32 bits que están contenidos en el campo de Lista de Datos de Registro que se van a escribir para registros que inician en el registro especificado mediante el campo de Dirección de Registro. Si los bits 15:14 son igual a '10' entonces los bits 13:0 especifican el número de elementos de datos de registro de 32 bits que el dispositivo de recepción envía a un dispositivo que solicita que se lean los registros. El campo de Lista de Datos de Registro en este paquete no contiene elementos y es de una longitud de cero. Si los 15:14 son igual '11' entonces los bits 13:0 especifican el número de los elementos de los Datos de Registro de 32 bits que se han leído desde los registros que están contenidos en el campo de Lista de Datos de Registro. Los Bits 15:14 no se establecen actualmente iguales a 01', el cual se considera un valor inválido, y se reservan de otra manera para designaciones o uso futuro. El campo de Dirección de Registro utiliza 4 bytes para indicar la dirección de registro en la que se va a escribir o desde la cual se va a leer. Para direccionar registros cuyo direccionamiento es menor a 32 bits, los bits superiores se establecen en cero. El campo de Parámetro CRC de dos bytes contiene una CRC de todos los bytes forman la Longitud de Paquete para la Dirección de Registro. Si esta CRC falla al verificar entonces todo el paquete se descarta. El campo de Lista de Datos de Registro contiene una lista de valores de Datos de Registro de 4 bytes que se van a escribir en registros o valores del cliente que fueron leídos desde los registros del dispositivo de cliente. El campo CRC de los Datos de Registro de dos bytes contiene una CRC de solamente la Lista de Datos de Registro. Si está CRC falla al verificar entonces los Datos de Registro pueden aún utilizarse, pero el conteo de error CRC se incrementa.

D. Paquete CRC Los campos CRC aparecen al final de los paquetes y algunas veces después de ciertos parámetros más cruciales en los paquetes que pueden tener un campo de datos significativamente grandes, y de ese modo, una probabilidad mayor de errores durante la transferencia. En los paquetes que tienen dos campos CRC, el generador CRC, cuando solamente se utiliza uno, se reinicializa después de el primer CRC de modo que los cálculos CRC que siguen un campo de datos largo no están afectados por los parámetros al inicio del paquete . En una modalidad ejemplar, el polinomio utilizado para el cálculo CRC se conoce como el CRC-16, o X16+X15+X2+X0. Una implementación de muestra de un generador CRC y un verificador 3600 útil para implementar la invención se muestra en la FIGURA 36. En la FIGURA 36, un registro 3602 CRC se inicializa en un valor de 0x0001 justo previo a la transferencia del primer bit de un paquete que se ingresa en la línea Tx_MDDI_Data_Before_CRC, luego los bytes del paquete se desplazan hacia el registro iniciando con el primer LSB. Nótese que los números de bits del registro en esta figura corresponden al orden del polinomio que se utiliza, y no a las posiciones de bit utilizadas por la MDDI. Es más eficiente desplazar el registro CRC en una sola dirección, y eso da por resultado que se tenga que el bit 15 de la CRC parezca en la posición de bit 0 del campo CRC MDDI, y el bit 14 del registro CRC en la posición 1 de bit del campo MDDI CRC, etc, hasta que se alcanza la posición 14 de bit de la MDDI.

Como un ejemplo, si el contenido del paquete para los Paquetes de Solicitud de Cliente y de Estado son: 0x000c, 0x0046, 0x000, 0x0400, 0x00, 0x00, 0x0000 (o se representan como una secuencia de bytes como: 0x0c, 0x00, 0x46, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00) , y se presentan utilizando las entradas de los multiplexores 3604 y 3606, y la compuerta 3608 NAND, la salida CRC resultante en la línea Tx_MDDI_Data_ ith_CRC es 0xd9aa (o representado como una secuencia como Oxaa, 0xd9) . Cuando el generador CRC y el verificador 3600 se configuran como un verificador CRC, la CRC que se recibe en la línea Rx_MDDI_Data se ingresa al multiplexor 3604 y a la compuerta 3608 NAND, y se compara bit por bit con el valor encontrado en el registro CRC utilizando la compuerta 3610 NOR la compuerta 3612 exclusiva-OR (XOR) , y" la compuerta 3614 AND. Si existen cualesquiera errores, con forme sale mediante la compuerta 3614 AND, la CRC se incrementa una vez para cada paquete que contiene un error CRC al conectar la salida de la compuerta 3614 a la entrada del registro 3602. Nótese que el circuito del ejemplo mostrado en el diagrama de la FIGURA 36 puede dar salida a más de una señal de error CRC dentro una ventana determinada CHECK_CRC_NOW (véase la FIGURA 37B) . Por lo tanto, el contador de error CRC generalmente solamente contabiliza el primer caso de error CRC dentro de cada intervalo en donde CHECK_CRC_NO es activo. Si se configura como un generador CRC la CRC se cronometra fuera del registro CRC en el momento en el que coincide con el final del paquete. El cronometraje para las señales de entrada y de salida, y la habilitación de las señales se ilustra gráficamente en las FIGURAS 37A y 37B. La generación de una CRC y la transmisión de un paquete de datos se muestra en la FIGURA 37A con el estado (0 ó 1) de las señales Gen_Reset, Check_CRC_Now, Generate_CRC_Now, y Sending_MDDI_Data, junto con las señales Tx_MDDI_Data_Before_CRC y Tx_MDDI_Data_With_CRC. La recepción de un paquete de datos y la verificación del valor CRC se muestran en la FIGURA 37B, con el estado de las señales Gen_Reset, Check_CRC_Now, Generate_CRC_Now, Sending_MDDI_Data, junto con las señales Rx_MDDI_Data y de error CRC.

E. Sobrecarga del Código de Error para el Paquete CRC Siempre que solamente se transmiten paquetes de datos y CRC entre el anfitrión y el cliente, no existen códigos de error que se ajustan. El único error es una perdida de sincronización. De otro modo, se tiene que esperar una pausa del enlace a partir de una necesidad de una buena trayectoria o cause de transferencia de datos y entonces se reinicia el enlace y se procede. Desafortunadamente, esto consume tiempo y es un tanto ineficiente. Para usarla en una modalidad, se ha desarrollado una nueva técnica en la cual la porción de los paquetes CRC se utiliza para transferir la 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 se generan mediante los procesadores o dispositivos que manejan la transferencia de datos que indican error o desperfectos predefinidos específicos que podrían suceder dentro del procesamiento o enlace de comunicación. Cuando se encuentra un error, entonces se genera y se transfiere un código de error apropiado utilizando los bits para la CRC de un paquete. Es decir, el valor CRC se sobrecarga, o se sobre escribe, con el código de error deseado, lo cual puede detectarse en el extremo de recepción mediante un monitor o verificador de error que monitorea los valores del campo CRC. Para esos casos en los cuales el código de error corresponde con el valor CRC por alguna razón, el cumplimiento del error se transfiere para evitar confusión. En una modalidad, para proporcionar un sistema de advertencia y detección de error contundente, el código de error puede transferirse varias veces, utilizando una serie de paquetes, generalmente todos, que se transfieren o envían después de que se ha detectado el error. Esto ocurre hasta el punto en el que la condición de crear el error se aclara desde el sistema, en el punto en el que los bits CRC regulares se transfieren sin sobrecarga mediante otro valor . Esta técnica de sobrecarga del valor CRC proporciona una respuesta mucho más rápida para los errores del sistema mientras que se utiliza una cantidad mínima de bits o campos extra. Como se muestra en la FIGURA 66, se muestra un mecanismo o aparato 6600 de sobre escritura utilizando un medio 6602 de detecciones o detector de error, que puede formar parte de otro conjunto de circuitos previamente descritos o conocidos, detecta la presencia o la existencia de errores dentro del enlace o proceso de comunicación. Un medio 6604 o generador de código de error, que puede formarse como parte de otro conjunto de circuitos o utiliza técnicas tales como tablas de búsqueda para almacenar mensajes de error preseleccionados, genera uno o más códigos de error para indicar errores o desperfectos predefinidos específicos que pueden haberse detectado mientras ocurren. Se entiende con facilidad que los dispositivos 6602 y 6604 pueden formarse como un solo circuito o dispositivo según se desee, o como parte de una secuencia de etapas programadas para otros procesadores y elementos conocidos . Un medio 6606 de comparación o comparador de valor CRC se muestra para verificación para ver si el código o códigos de error seleccionados son los mismos como el valor CRC que se transfiere. Si este es el caso, entonces se utiliza un medio o dispositivo generador o generación de cumplimiento de código para proporcionar el cumplimiento de los códigos de error en cuanto que no sean confundidas como el original del patrón o valor CRC y se confunda o se complique el esquema de detección. Un elemento o dispositivo 6610 de un selector o medio de selección de código de error selecciona entonces el código o valor de error que se desea insertar o sobre escribir, o sus respectivos cumplimientos según sea lo apropiado. Un mecanismo o medio 6612 sobre escritor o de sobre escritura CRC de código de error es un dispositivo que recibe la corriente de datos, los paquetes y los códigos deseados que se van a insertar o sobre escribe los valores CRC correspondientes o apropiados, para transferir los códigos de error deseados a un dispositivo de recepción. Como se mencionó, el código de error puede transferirse varias veces, utilizando una serie de paquetes, así que el sobre escritor 6612 puede utilizar elementos de almacenamiento en memoria para mantener copias de los códigos durante el procesamiento o recuperación de esos códigos de elementos previos u otras ubicaciones de almacenamiento conocidas que puedan utilizarse para almacenar o mantener sus valores según sea necesario, o según se desee . El procesamiento general del mecanismo de sobre escritura de la FIGURA 66 se implementa mostrado en detalle adicional en las FIGURAS 67A y 67B. En la 67A se detectan uno o más errores, en la etapa 6702 en la comunicación de datos o el proceso y un código de error se selecciona en la etapa 6704 para indicar esta condición. Al mismo tiempo, o en un punto apropiado, el valor CRC que se va a reemplazar se verifica en una etapa 6706, y se compara con el código de error deseado en la etapa 6708. El resultado de esta comparación, como se discutió anteriormente, es una determinación en cuanto a que si el código deseado, u otros valores representativos, serán los mismos o no que los del valor CRC presente. Si este es el caso, entonces el procesamiento procede a una etapa 6712 en donde se selecciona el cumplimiento, o en algunos casos según se desee otro valor representativo, como el código que se va a insertar. Una vez que se determina que códigos o valores de error se van a insertar en las etapas 6710 y 6714, ese código apropiado se selecciona para su inserción. Esas etapas están ilustradas por separado para propósitos de claridad aunque generalmente representan una sola elección basada en la salida de decisión de la etapa 6708. Finalmente, en la etapa 6716 los valores apropiados se sobre escriben en la ubicación CRC para transferirlos con los paquetes que se han seleccionado como objetivo mediante el proceso. En el lado de la recepción del paquete, como se muestra en las FIGURAS 67B, los valores CRC del paquete se están monitoreando en una etapa 6722. Generalmente, los valores CRC que se están monitoreando mediante uno o más procesos dentro del sistema para determinar si ha ocurrido un error en la transferencia de datos y si se solicita o no una retransmisión de el paquete o los paquetes, o para inhibir operaciones adicionales, etc., algunas de las cuales se discutieron anteriormente. Como parte de tal monitoreo de la información se puede también utilizar para comparar valores para códigos de error conocidos o preseleccionados, o valores representativos y detectar la presencia de errores. Alternativamente, puede implementarse un proceso y monitor para detección de errores separados. Si un código aparece para estar presente se extrae o se hace notar de otra manera en la etapa 6724 para un procesamiento adicional . Puede hacerse una determinación en la etapa 6726 en cuanto si éste es el código real o no o un cumplimiento, en la cual en cuyo caso, se utilizan una etapa 6728 adicional para traducir el valor al valor de código deseado. En cualquier caso, el código extraído resultante, el cumplimiento u otros valores recuperados se utilizan entonces para detectar que error ha ocurrido a partir del código transmitido en la etapa 6730.

V. Hibernación de Enlace El enlace MDDI puede ingresar el estado de hibernación rápidamente y despertarse del estado de la hibernación rápidamente. Esta receptividad permite que un sistema o dispositivo de comunicación forcé al enlace MDDI hacia la hibernación frecuentemente para reducir el consumo de energía eléctrica, dado que puede despertarse de nuevo para utilizarse muy rápidamente. En una modalidad, cuando un cliente de modo externo se despierta de la hibernación por primera vez lo hace de modo que una velocidad de datos y con un cronometrado de pulso estroboscópico que es consistente con una velocidad de uno Mbps, es decir, el par MDDI_Stb debiera bascularse a una velocidad de 500 kHz. Una vez que se han descubierto las Características de Cliente mediante el o se han comunicado al anfitrión, entonces el anfitrión puede descartar el enlace generalmente a una velocidad de 1 Mbps hasta la velocidad máxima en la cual el cliente puede operar. Los clientes de modo interno pueden despertarse a cualquier velocidad a la cual tanto el anfitrión como el cliente puedan operar. Esto también se puede aplicar generalmente a la primera vez que un cliente de modo interno se despierta. Que en una modalidad, cuando el enlace se despierta de la hibernación el anfitrión y el cliente intercambian una secuencia de pulsos. Esos pulsos pueden detectarse utilizando receptores en línea de baja velocidad que consumen solamente una fracción de la corriente con forme a los receptores diferenciales que se requieren para recibir las señales en lá rapidez de operación máxima de enlace. Cualquiera de ambos el anfitrión o el cliente pueden despertar el enlace, de modo que el protocolo de despertar está diseñado para manejar una posible contención que puede ocurrir si ambos el anfitrión y el cliente intentan despertarse simultáneamente . Durante el estado de hibernación los manej adores diferenciales MDDI_Data y MDDI_Stb se deshabilitan y el voltaje diferencial a través de todos los pares diferenciales es de cero voltios . Los receptores en línea diferenciales utilizados para detectar la secuencia de pulsos durante el despertar de la hibernación tienen un desplazamiento de voltaje intencional. En una modalidad, el umbral entre un nivel de uno-lógico y de cero-lógico en esos receptores es de aproximadamente 125 mV. Esto provoca un par diferencial no accionado que se va a ver como un nivel cero-lógico durante la secuencia de despertar del enlace . Para ingresar a un Estado de Hibernación, el anfitrión envía 64 ciclos MDDI_Stb tras la CRC del Paquete de Interrupción de Enlace. El anfitrión deshabilita la salida de MDDI_Data 0 del anfitrión en el rango de 16 a 56 ciclos MDDI_Stb (incluyendo los retrasos de propagación que deshabilitan la salida) . El anfitrión finaliza el envío de los ciclos MDDI_Stb después de las CRC del paquete de Interrupción de Enlace antes de que inicie la secuencia de despertar. En una modalidad, el despertar iniciado por el anfitrión está definido como el anfitrión que tiene que esperar al menos 100 nseg después de que MDDI_DataO alcanza un nivel de uno-lógico válido antes de accionar los pulsos en MDDI_Stb. En una modalidad, el cliente espera al menos 60 ciclos MDDI_Stb después de la CRC del Paquete de Interrupción de Enlace antes de que accione MDDI_Data0 en un nivel de uno-lógico para intentar despertar al anfitrión. Para "despertar" de un Estado de Hibernación, se realizan diversas acciones o procesos. Cuando el cliente, aquí una pantalla, necesita datos o comunicación, o servicio, desde el anfitrión se acciona la línea MDDI_Data0 en un estado de uno-lógico por aproximadamente 70 a 1000 µseg, mientras que MDDI_Stb está inactivo y mantiene MDDI_DataO accionados en un nivel de uno-lógico durante aproximadamente 70 ciclos MDDI_Stb (a través de un rango de 60 a 80) después la MDDI_Stb se vuelve activa, aunque pueden utilizarse según se desee otros periodos. El cliente entonces deshabilita el manejador MDDI_DataO al colocarlo dentro de un estado de alta impedancia. Si MDDI_Stb esta activo durante la hibernación, aunque improbable, entonces el cliente podría solamente accionar MDDI_DataO en un estado de uno-lógico por aproximadamente 70 ciclos MDDI_Stb (o través de un rango de 60 a 80) . Esta acción provoca que el anfitrión inicie o reinicie el tráfico de datos en el enlace (208) sin retorno y que llame a un cliente para saber su estado. El anfitrión debe detectar la presencia del pulso de solicitud y comienza la secuencia de inicio al accionar MDDI_Stb en un nivel de cero-lógico y MDDI_Data0 en un nivel lógico elevado de al menos aproximadamente 100 nsec. Y luego, mientras bascula MDDI_Stb continua para accionar MDDI_Data0 en un nivel de uno lógico por aproximadamente 50 ciclos MDDI_Stb. El cliente no debe enviar un pulso de solicitud de servicio si se detecta MDDI_Data0 en el estado lógico de uno por más de 80 ciclos MDDI_Stb. Cuando el cliente ha detectado MDDI_Data0 en un nivel de uno lógico durante 60 hasta 80 ciclos MDDI_Stb comienza a buscar el intervalo en el que el anfitrión acciona MDDI_DataO en un nivel de cero lógico durante 50 ciclos MDDI_Stb. Luego de que el anfitrión acciona MDDI_DataO en un nivel de cero lógico por una duración de 50 ciclos MDDI_Stb, entonces el anfitrión empieza a enviar paquetes al enlace . El primer paquete enviado es un Paquete del Encabezamiento de Sub-trama. El cliente comienza a buscar el Paquete de Encabezamiento de Sub-trama después de que MDDI_DataO está en un nivel de cero lógico durante 40 _ciclos MDDI_Stb del intervalo de 50 ciclos. La naturaleza de la selección de las veces y las tolerancias de los intervalos de tiempo relacionados con el procesamiento de hibernación y el inicio de la secuencia se discuten adicionalmente a continuación. (Véanse las FIGURAS 68A-C a continuación) . El anfitrión puede iniciar el despertar mediante la primera habilitación MDDI_Stb y simultáneamente accionarlo en un nivel de cero-lógico. MDDI_Stb no debiera accionarse en un nivel de uno-lógico hasta que se producen los pulsos como se describe a continuación. Después de que MDDI_Stb alcanza un nivel de cero-lógico valido el anfitrión habilita MDDI_DataO y simultáneamente lo acciona en un nivel de uno-lógico. MDDI_Data0 no debiera accionarse en un nivel de cero-lógico hasta que el intervalo en donde está siendo activado el nivel de cero-lógico por un intervalo de 50 pulsos MDDI Stb como se describe a continuación. El anfitrión debe esperar al menos 100 nseg después de que MDDI_DataO alcance un nivel de uno-lógico válido antes de accionar los pulsos en MDDI_Stb. Esta relación de cronometraje ocurre mientras se considera el peor caso de los retrasos que habilitan la salida. Esto sustancialmente garantiza que un cliente tenga suficiente tiempo para habilitar completamente su receptor MDDI_Stb después de que ha sido despertado mediante un nivel de uno-lógico en MDDI_DataO que fue accionado por el anfitrión. Un ejemplo de las etapas de procesamiento para un evento 3800 de solicitud de servicio de cliente típico sin contención se ilustra en la FIGURA 38, en donde los eventos se etiquetan 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 anfitrión envía un Paquete de Interrupción de Enlace al dispositivo de cliente para informarle que el enlace pasará a un estado de hibernación de baja potencia. En una siguiente etapa, el anfitrión ingresa el estado de hibernación de baja potencia al deshabilitar el manejador MDDI_DataO y al ajustar el manejador MDDI_Stb en un cero-lógico, como se muestra en el punto B. MDDI_Data0 se acciona en un nivel de cero-lógico mediante una red de polarización de alta impedancia. Tras algún período de tiempo, el cliente envía un pulso de solicitud de servicio al anfitrión al accionar MDDI DataO en un nivel de uno-lógico como se ve en el punto C. El anfitrión aún mantiene el nivel de cero-lógico utilizando la red de polarización de alta impedancia, aunque el manejador en el cliente fuerza la línea a un nivel de uno-lógico. Dentro de 50 µseg, el anfitrión reconoce el pulso de solicitud de servicio, y mantiene un nivel de uno-lógico en MDDI_Data0 mediante la habilitación de su manejador, como se ve en el punto D. Entonces el Cliente cesa de intentar mantener el pulso de solicitud de servicio, y el Cliente coloca su manejador en un estado de alta impedancia, como se ve en el punto E. El anfitrión acciona MDDI_DataO en un nivel de cero-lógico durante 50 µseg, como se muestra en el punto F, y también comienza a generar MDDI_Stb de una manera consistente con el nivel de cero-lógico en MDDI_DataO. El cliente comienza a buscar el Paquete de Encabezamiento de Sub-tram después de que MDDI_DataO está en un nivel de cero lógico durante 40 ciclos MDDI_Stb. Después de mantener MDDI_DataO en un nivel de cero-lógico y de accionar MDDI_Stb durante 50 µseg, el anfitrión comienza a transmitir los datos en el enlace sin retorno al enviar un Paquete de Encabezamiento de Sub-trama, como se muestra en el punto G. Un ejemplo similar se ilustra en la FIGURA 39 en donde una solicitud de servicio se mantiene después de que se ha iniciado la secuencia de reinicio del enlace, y que los eventos están de nuevo etiquetados utilizando las letras A, B, C, D, E, F y G. Esto representa el peor escenario de caso en donde un pulso o señal de solicitud del cliente llega lo más cerca de alterar el Paquete del Encabezamiento de Sub-trama. El proceso comienza en el punto A en donde el anfitrión de nuevo envía un Paquete de Interrupción de Enlace al dispositivo de cliente para informarle que el enlace pasará a un estado de hibernación de baja potencia. En la siguiente etapa, el anfitrión ingresa el estado de hibernación de baja potencia al deshabilitar el manejador MDDI_DataO y ajustar el manejador MDDI_Stb en un nivel de cero-lógico, como se muestra el punto B. Como en el caso anterior, MDDI_DataO se acciona en un nivel de cero-lógico mediante una red de polarización de alta impedancia. Tras un período de tiempo, el anfitrión comienza la secuencia de reinicio del enlace al accionar MDDI_DataO en un nivel de uno-lógico durante 150 µseg como se ve en el punto C. Antes de pasar los 50 µseg después de que comienza la secuencia de reinicio del enlace el despliegue también mantiene MDDI_DataO durante una duración de 70 µseg, como se ve en el punto D. Esto sucede debido a que el despliegue tiene una necesidad de solicitar el servicio del anfitrión y no reconoce que el anfitrión ya haya iniciado la secuencia de reinicio de enlace. El cliente entonces deja de intentar mantener el pulso de solicitud de servicio, y el Cliente coloca su manejador en un estado de alta impedancia, como se ve en el punto E. El anfitrión continúa accionando MDDI_DataO en un nivel de uno-lógico. El anfitrión acciona MDDI_DataO en un nivel de cero-lógico durante 50 µseg, como se muestra en el punto F, y también comienza a generar MDDI_Stb de una manera consistente con el nivel de cero-lógico en MDDI_DataO . Tras mantener MDDI_Data 0 en un nivel de cero-lógico, y de accionar MDDI_Stb durante 50 µseg, el anfitrión comienza a transmitir los datos en el enlace sin retorno al enviar un Paquete de Encabezamiento de Sub-trama, como se muestra en el punto G. A partir de la anterior discusión, puede verse que la solución previa implicó mantener al anfitrión pasando a través de dos estados como parte de una secuencia de despertar. Para el primer estado, el anfitrión acciona la señal MDDI_DataO elevada durante 150 µs, y luego acciona la señal baja MDDI_DataO durante 50 us mientras que activa la línea MDDI_Stb, y luego comienza a transmitir los paquetes MDDI. Este proceso funciona bien para mejorar el estado de la técnica en términos de velocidades de datos que pueden alcanzarse utilizando el aparato y los métodos MDDI. Sin embargo, como se afirmo anteriormente, siempre están en demanda una mayor rapidez en términos de un tiempo de respuesta reducido a condiciones o estar en posibilidad de seleccionar más rápidamente la siguiente etapa o proceso, son la capacidad para simplificar el procesamiento o los elementos . Se ha descubierto una nueva metodología inventiva para procesar y cronometrar el despertar en la cual el anfitrión utiliza un ciclo de medir el tiempo con base en el cronometraje de la basculación de la señal. En esta configuración, el anfitrión inicia la basculación de MDDI_Stb desde 0 hasta 10 µseg después de que el anfitrión acciona la señal elevada MDDI__DataO al inicio de la secuencia de despertar, y no espera hasta que la señal esté accionada en bajo. Durante una secuencia de despertar, el anfitrión bascula MDDI_Stb aunque la señal MDDI_DataO estuviera siempre en un nivel de cero-lógico. Esto efectivamente retira el concepto de tiempo del lado del cliente, y el anfitrión cambia desde los periodos 150 µs y 50 µs anteriores para los dos primeros estados a 150 ciclos de medir el tiempo y 50 ciclos de medir el tiempo, para esos periodos . El anfitrión ahora se hace responsable de accionar esa elevada línea de datos, y dentro de 10 ciclos de medir el tiempo que inician al transmitir una señal estroboscópica como si la línea de datos estuviera en cero. Después de que el anfitrión ha accionado la elevada línea de datos durante 150 ciclos de medir el tiempo, el anfitrión acciona la línea de datos baja durante 50 ciclos de medir el tiempo mientras que continúa transmitiendo la señal estroboscópica. Después de que ha completado ambos de esos procesos, el anfitrión puede comenzar a transmitir el primer paquete de encabezamiento de sub-trama. En el lado del cliente, la implementación de cliente puede ahora utilizar medir el tiempo generado para calcular el número de ciclos de medir el tiempo que la línea de datos es primero elevada y después baja. El número de ciclos de medir el tiempo que se necesitan para que ocurra tanto la línea de datos accionada en el estado elevado sea de 150 y que la línea de datos accionada en el estado bajo sea 50. Esto significa que para una secuencia de despertar apropiada, el cliente debería estar en posibilidad de contar al menos 150 ciclos de medir el tiempo continuos de la línea de datos que es alta, seguidos de al menos 50 ciclos de medir el tiempo continuos de la línea de datos que es baja. Una vez que esas dos condiciones se han alcanzado, el cliente pude comenzar a buscar la palabra única de la primer sub-trama. Un rompimiento en este patrón se utiliza como una base para regresar los contadores a un estado inicial en los cuales el cliente de nuevo busca los primeros 150 ciclos de medir el tiempo continuos de la línea de datos que es elevada. Una implementación de cliente de la invención para el anfitrión con base en el despertar de la hibernación es muy similar al caso de arranque inicial excepto que la velocidad de medir el tiempo no se fuerza para iniciar en IMbps, como se discutió anteriormente. En cambio, la velocidad de medir el tiempo puede ajustarse para volver a empezar en cualquier velocidad previa que estuviera activa cuando el enlace de comunicación entró en hibernación. Si el anfitrión comienza la transmisión de una señala estroboscópica como se describió anteriormente, el cliente debiera estar en posibilidad para de nuevo contar al menos 150 ciclos de medir el tiempo continuos de la línea de datos que es elevada, seguido de al menos 50 ciclos de medir el tiempo continuos de la línea de datos que es baja. Una vez que se han reunido esas dos condiciones, el cliente puede comenzar a buscar la palabra única. Una implementación de cliente de la invención para el Cliente con base en el despertar de la hibernación es similar al despertar basado en anfitrión excepto en que inicia al mantener al cliente accionando la línea de datos. El cliente puede asincronamente accionar la línea de datos sin medir el tiempo para despertar el dispositivo del anfitrión. Una vez que el anfitrión reconocer que la línea de datos está siendo accionada elevada por el cliente, puede comenzar su secuencia de despertar. El cliente puede contar el número de ciclos de medir el tiempo generados por el anfitrión al iniciar o durante su proceso de despertar. Una vez que el Cliente cuenta 70 ciclos de medir el tiempo continuos de los datos que son elevados, puede detener el accionamiento de la línea de datos elevada. En este punto, el anfitrión debiera ya accionar la línea de datos elevada también. Un cliente puede entonces contar otros 80 ciclos de medir el tiempo continuos de la línea de datos que es elevada para alcanzar los 150 ciclos de medir el tiempo de la línea de datos que es elevada, y puede entonces buscar los 50 ciclos de medir el tiempo de la línea de datos que es baja. Una vez que se han reunido esas tres condiciones, el cliente puede comenzar a buscar la palabra única. Una ventaja de esta nueva implementación del procesamiento de despertar es que retira la necesidad de un dispositivo de medición del tiempo. Ya sea que sea un oscilador, o un circuito de descarga del condensador u otros dispositivos conocidos, el cliente ya no necesita tales dispositivos externos para determinar las condiciones de inicio. Esto ahorra dinero y áreas de circuitos cuando se implementan los controladores, contadores, etc., en un tablero de dispositivo de cliente. Aunque esto puede no ser ventajoso para el cliente, para el anfitrión, esta técnica debiera también simplificar potencialmente al anfitrión en términos de una densidad lógica muy elevada (VHDL) que se utiliza para el conjunto de circuitos de núcleo. El consumo de energía eléctrica del uso de las líneas de datos y del estroboscopio como la fuente de notificación y medición de despertar también se da más baja dado que no será necesario ningún conjunto de circuitos externos que esté funcionando para los elementos de núcleo para que esperen a que un despertar basado en el anfitrión. El número de ciclos o periodos de medir el tiempo utilizados son ejemplares y pueden utilizarse otros periodos como será aparente para quienes tienen experiencia en la técnica. Una ventaja de esta nueva implementación del procesamiento de despertar es que retira la necesidad de un dispositivo de medición de tiempo. Ya sea que se trate de un oscilador, o un circuito de descarga del condensador u otros dispositivos conocidos, el cliente no necesita ya tales dispositivos externos para determinar las condiciones de inicio . Esto ahorra dinero y áreas de circuitos cuando se implementan los controladores, los contadores, etc., en un tablero del dispositivo de cliente. Aunque esto no puede ser tan ventajoso para el cliente, para el anfitrión, esta técnica debería también potencialmente simplificar el anfitrión en términos de una lógica de muy alta densidad (VHDL) que se utiliza para el conjunto de circuitos de núcleo. El consumo de energía eléctrica al utilizar las líneas de datos y estroboscopio como la fuente de notificación y medición del despertar también será más bajo dado que no será necesario un conjunto de circuitos externos para que funcionen para los elementos de núcleo que van estar esperando un despertar con base en el anfitrión. Para aclarar e ilustrar la operación de esta nueva técnica, el cronometraje de MDDI_DataO, MDDI_Stdb, y diversas operaciones relacionadas con los ciclos de medir el tiempo se muestran en las FIGURAS 68A, 68B y 68C. Un ejemplo de las etapas de procesamiento de un Despertar iniciado por el Anfitrión típico sin conexión se ilustra en la FIGURA 68A, en donde los eventos de nuevo se etiquetan para conveniencia de ilustración utilizando las letras A, B, C, D, E, F, y G. El proceso comienza en el punto A cuando el anfitrión envía un Paquete de Interrupción de Enlace al dispositivo de cliente para informarle que el enlace pasará a un estado de hibernación de baja potencia. En una siguiente etapa, en el punto B, el anfitrión bascula MDDI_Stb por aproximadamente 64 ciclos (o conforme se desee para el diseño del sistema) para permitir que el procesamiento sea completado por el cliente antes de detener la basculación de MDDI_DataO, el cual detiene a medir el tiempo recuperado en el dispositivo de cliente. El anfitrión también inicialmente establece MDDI_DataO en un nivel de cero-lógico y después deshabilita la salida MDDI_DataO en el rango de 16 hasta 48 ciclos (generalmente incluyendo retraso de propagación de deshabilitación de salida) después de la CRC. Puede ser deseable colocar receptores de alta velocidad para MDDI_DataO y MDDI_Stb en el cliente en un estado de baja potencia algún tiempo después de los 48 ciclos tras la CRC y antes de la siguiente fase (C) . El cliente coloca sus receptores de alta velocidad para MDDI_DataO y MDDI_Stb en hibernación en cualquier momento después el borde de subida del 48avo ciclo MDDI_Stb después de la CRC del Paquete de Interrupción de Enlace . Se recomienda que el cliente coloque sus receptores de alta velocidad para MDDI_DataO y MDDI_Stb en hibernación antes del borde de subida de 64avo ciclo MDDI_Stb después de la CRC del Paquete de Interrupción de Enlace. El anfitrión ingresa al estado de hibernación de baja potencia en el punto o etapa C, al deshabilitar los manej adores MDDI_DataO y MDDI_Stb y coloca un controlador del anfitrión en un estado de hibernación de baja potencia. También se puede ajustar al manejador MDDI_Stb en un nivel de cero-lógico (utilizando una red de polarización de alta impedancia) o continuar basculando durante la hibernación, según se desee. El cliente también está en un estado de hibernación de nivel de potencia bajo. Después de algún periodo de tiempo, el anfitrión comienza la secuencia de reinicio del enlace en el punto D, al habilitar la salida del manejador MDDI_DataO y MDDI_Stb. El anfitrión acciona MDDI_DataO en un nivel de uno-lógico y MDDI_Stb en un nivel de cero-lógico por todo el tiempo que les tome a los manejadores habilitar completamente sus respectivas salidas. El anfitrión típicamente espera aproximadamente 200 nanosegundos después de que esas salidas alcanzan los niveles lógicos deseados antes de accionar los pulsos en MDDI_Stb. Esto le permite al cliente tiempo para prepararse a recibir. Ya con los manejadores del anfitrión habilitados y con MDDI_DataO que está accionado en un nivel de uno-lógico, el anfitrión comienza a bascular MDDI_Stb por una duración de 150 ciclos MDDI_Stb, como se ve en el punto E. El anfitrión acciona MDDI_DataO en un nivel de cero-lógico durante 50 ciclos, como se muestra en el punto F, y el cliente comienza a buscar el Paquete de Encabezamiento de Sub-trama después de que MDDI_Data0 está en un nivel de cero-lógico durante 40 ciclos MDDI_Stb. El anfitrión comienza a transmitir los datos en el enlace sin retorno al enviar un Paquete de Encabezamiento de Sub-trama, como se muestra en el punto G. Un ejemplo de las etapas de procesamiento de un Despertar iniciado por el Cliente típico sin contención se ilustra en la FIGURA 68B, en donde los eventos se etiquetan de nuevo por conveniencia en ilustración utilizando las letras A, B, C, D, E, F, G, H, e l. Como antes, el proceso comienza en el punto A cuando el anfitrión envía un Paquete de Interrupción de Enlace para informar al cliente que el ' enlace pasará al estado de baja potencia. En el punto B, el anfitrión bascula MDDI_Stb por aproximadamente 64 ciclos (o conforme se desee para el diseño de sistema) para permitir que sea completado el procesamiento por parte del cliente antes de detener la basculación MDDI_Stb lo cual detiene medir el tiempo recuperado en el dispositivo de cliente. El anfitrión también inicialmente ajusta MDDI_DataO en un nivel de cero- lógico y luego deshabilita la salida MDDI_DatáO en el rango de 16 hasta 48 ciclos (que generalmente incluyen retraso de propagación por deshabilitación de salida) tras la CRC. Puede ser deseable colocar los receptores de alta velocidad para MDDI_DataO y MDDI_Stb en el cliente en un estado de baja potencia en algún momento después de los 48 ciclos después de la CRC y previo a la siguiente fase (C) . El anfitrión ingresa el estado de hibernación de baja potencia en el punto o etapa C, al deshabilitar los manej adores MDDI_DataO y MDDI_Stb y al colocar un controlador del anfitrión en un estado de hibernación de baja potencia. También se puede ajustar el manejador MDDI_Stb en un nivel de cero-lógico (utilizando una red de polarización de alta impedancia) o continuar basculando durante la hibernación, según se desee. El cliente también está en un estado de hibernación de nivel de potencia bajo. Después de algún periodo de tiempo, el cliente comienza la secuencia de reinicio del enlace en el punto D, al habilitar al receptor MDDI_Stb, y también al habilitar un desplazamiento en el receptor MDDI_Stb para garantizar el estado de la versión recibida de MDDI_Stb que está en el nivel de cero-lógico en el cliente antes de que el anfitrión habilite su manejador MDDI_Stb. Puede ser deseable para el cliente habilitar el desplazamiento 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 manejador MDDI_Data0 mientras acciona la línea MDDI_Data0 en un nivel de uno-lógico. Se le autoriza a MDDI_DataO y MDDI_Stb estar habilitados simultáneamente si el tiempo para habilitar el desplazamiento y el receptor diferencial MDDI_Stb estándar es menor a 100 nsec . Dentro de aproximadamente 1 mseg., en el punto E, el anfitrión reconoce el pulso de solicitud de servicio del cliente, y el anfitrión comienza la secuencia de reinicio de enlace al habilitar la salida del manejador MDDI_Data0 y MDDI_Stb. El anfitrión acciona MDDI_DataO en un nivel de uno-lógico y MDDI_Stb en un nivel de cero-lógico por el tiempo que pueda tomarle a los manej adores habilitar sus respectivas salidas. El anfitrión típicamente espera alrededor de 200 nanosegundos después de que esa salida alcanza los niveles lógicos deseados antes de accionar los pulsos en MDDI_Stb. Esto permite al cliente tiempo para prepararse a recibir. Con los manej adores del anfitrión habilitados y con Esto permite al cliente tener que está accionado en un nivel de uno-lógico, el anfitrión comienza a dar salida a los pulsos en MDDI_Stb por una duración de 150 ciclos MDDI_Stb, como se ve en el punto F. Cuando el cliente reconoce el primer pulso en MDDI_Stb deshabilita el desplazamiento de su receptor MDDI_Stb. El cliente continúa accionando MDDI_Data0 en un nivel de uno-lógico durante 70 ciclos MDDI_Stb, y deshabilita su manejador MDDI_Data0 en el punto G. El anfitrión continua para accionar MDDI_Data0 en un nivel lógico de uno por una duración adicional de 80 pulsos MDDI_Stb, y en un punto H acciona MDDI_Data0 en un nivel de cero lógico. Como se ve en los puntos G y H, el anfitrión acciona MDDI_Data0 en un nivel de cero-lógico durante 50 ciclos, y el cliente comienza a buscar el Paquete de Encabezamiento de Sub-trama después de que MDDI_Data0 está en un nivel de cero-lógico durante 40 ciclos MDDI_Stb. Tras accionar MDDI_Stb por una duración de 50 ciclos, el anfitrión comienza a transmitir los datos en el enlace de sin retorno al enviar un Paquete de Encabezamiento de Sub-trama, como se muestra en el punto I Un ejemplo de las etapas de procesamiento para un Despertar iniciado por el Anfitrión típico con contención desde el cliente, es decir, el cliente siempre quiere despertar el enlace, como se ilustra en la FIGURA 68C. Los eventos de nuevo se etiquetan para conveniencia de ilustración utilizando las letras A, B, C, D, E, F, G, H, e I. Como antes, el proceso comienza en el punto A cuando el anfitrión envía un Paquete de Interrupción de Enlace para informar al cliente que el enlace pasará al estado de baja potencia, procede al punto B en donde MDDI_Stb se bascula durante aproximadamente 64 ciclos (o conforme se desee para el diseño de sistema) para permitir que el procesamiento sea completado por el cliente, y después va al punto C, en donde el anfitrión ingresa al estado de hibernación de baja potencia, al deshabilitar los manej adores MDDI_DataO y MDDI_Stb y colocar un controlador del anfitrión en un estado de hibernación de baja potencia. Después de algún periodo de tiempo, el anfitrión comienza la secuencia de reinicio del enlace en el punto D, al habilitar la salida del manejador MDDI_DataO y MDDI_Stb y comienza a bascular MDDI_Stb por una duración de 150 ciclos MDDI_Stb, como se ve en el punto E. Hasta 70 ciclos MDDI_Stb después del punto E, para este momento el punto F, el cliente ya no ha reconocido que el anfitrión está accionando MDDI_DataO en un nivel de uno-lógico así que el cliente también acciona MDDI_DataO en un nivel de uno-lógico. Esto ocurre aquí - debido a que el cliente tiene el deseo de solicitar el servicio pero no reconoce que el anfitrión está tratando de comunicarse con él y que ya ha iniciado la secuencia de reinicio del enlace. En el punto G, el cliente deja de accionar MDDI_DataO, y coloca su manejador en un estado de alta impedancia al deshabilitar su salida. El anfitrión continúa accionando MDDI_Data0 en un nivel de uno-lógico durante 80 ciclos adicionales. El anfitrión acciona MDDI_Data0 en un nivel de cero-lógico durante 50 ciclos, como se muestra en el punto H, y el cliente comienza a buscar el Paquete de Encabezamiento de Sub-trama después de que MDDI_DataO está en un nivel de cero-lógico durante 40 ciclos MDDI_Stb. El anfitrión comienza a transmitir los datos en el enlace sin retorno al enviar un Paquete de Encabezamiento de Sub- trama, como se muestra en el punto I.

VI. Especificaciones Eléctricas de la Interfaz En las modalidades ejemplares, los Datos en un formato de Sin Retorno a Cero (NRZ) se codifican utilizando una señal de datos-estroboscópica o formato DATA-STB, que permiten que la información de medir el tiempo se incluya en las señales de datos y estroboscópicas . El medir el tiempo puede recuperarse sin una fase compleja de circuitos de bucle cerrados . Los datos se transportan a través de un enlace diferencial bi-direccional, que generalmente se implementa utilizando un cable de línea metálica, aunque pueden utilizarse otros conductores, y los impresos o elementos de transferencia, como se manifestó anteriormente. La señal estroboscópica (STB) se transporta a través de un enlace uni-direccional que está accionado solamente por el anfitrión. La señal estroboscópica bascula el valor (0 ó 1) siempre que exista un estado ininterrumpido, 0 ó 1, que permanece igual en la línea o señal de los Datos . Un ejemplo de cómo una secuencia de datos tal como la de los bits "1110001011" puede transmitirse utilizando la codificación DATA-STB se muestra en forma gráfica en la FIGURA 40. En la FIGURA 40, una señal 4002 de DATA se muestra en la línea superior de un cuadro de tiempos de señal y una señal 4004 STB se muestra en una segunda línea, cada tiempo se alinea según lo apropiado (punto de inicio común) . Conforme pasa el tiempo, cuando existe un cambio de estado que ocurre en la línea 4002 de DATA (señal) , entonces la línea 4004 STB (señal) mantiene un estado previo, de ese modo en primer l' estado de la señal DATA 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 DATA no cambia, entonces la señal STB bascula al estado opuesto o ?l' en el ejemplo presente, como es el caso de la FIGURA 40 en donde el DATA se les proporciona otro valor ?l'. Es decir, existe solamente una y solamente una transición por ciclo de bit entre DATA y STB. Por lo tanto, las transiciones de señal STB de nuevo, esta vez en '0' conforme la señal DATA permanece en ?l' y mantiene este nivel o valor conforme la señal DATA cambia el nivel a ?0'. Cuando la señal DATA permanece en ?l', la señal STB bascula al estado opuesto o ?l' en el presente ejemplo, etcétera, conforme la señal DATA cambia o mantiene los niveles o los valores. Al recibir esas señales, se lleva a cabo una operación O-exclusiva (XOR) en las señales DATA y STB para producir una señal 4006 de medir el tiempo, que se muestra en la parte inferior del cuadro de tiempo para su comparación relativa con las señales de datos y -estroboscopio deseadas. Un ejemplo de conjunto de circuito útiles para generar las salidas DATA y STB o señales de entrada de datos en el anfitrión, y luego recuperar o recapturar los datos desde las señales DATA y STB, se muestra en la FIGURA 41. En la FIGURA 41, una porción 4100 de transmisión se utiliza para generar y transmitir las señales DATA y STB originales a través de una trayectoria 4102 de señal intermedia, mientras que una porción 4120 de recepción se utiliza para recibir las señales y recuperar los datos. Como se muestra en la FIGURA 41, para transferir los datos desde un anfitrión hasta un cliente, la señal DATA se ingresa en dos elementos 4104 y 4106 de circuito basculante tipo D junto con una señal de medir el tiempo para activar los circuitos. Las dos salidas (Q) del circuito basculante están entonces divididas en un par de señales diferenciales MDDI_DataO+, MDDI_DataO-, y MDDI_Stb+, MDDI_Stb-, respectivamente, utilizando dos manej adores 4108 y 4110 de línea diferenciales (modo de voltaje) . Una compuerta NOR-exclusiva (XNOR) de tres entradas, un circuito, o un elemento 4112 lógico se conecta para recibir DATA y las salidas de ambos basculantes, y genera una salida que proporciona los datos de entrada para el segundo basculante, que a su vez genera las señales MDDI_Stb+, MDDI_Stb- . Por conveniencia, la compuerta XNOR tiene la burbuja de inversión colocada para indicar que está efectivamente invirtiendo la salida Q del basculante que genera el Estroboscopio. En la porción 4120 de recepción de la FIGURA 41 las señales MDDI_DataO+, MDDI_DataO- y MDDI_Stb+, MDDI_Stb-se reciben mediante cada uno de los dos receptores 4122 y 4124 en línea diferenciales, que generan salidas únicas de las señales diferenciales. Las salidas de los amplificadores se ingresan entonces a cada una de las entradas de una compuerta OR-exclusiva (XOR) de dos entradas, un circuito, o un elemento 4126 lógico que produce la señal de medir el tiempo. La señal de medir el tiempo se utiliza para activar cada uno de los dos circuitos 4128 y 4130 basculantes tipo D que reciben una versión retrasada de la señal DATA, a través del elementos 4132 de retraso, uno de los cuales (4128) genera los valores de datos 0' y el otro (4130) los valores de datos ' 1'. El medir el tiempo tiene una salida independiente del XOR lógico también. Puesto que la información de medir el tiempo está distribuida entre las líneas DATA y STB, ninguna de las transiciones de señal entre los estados es más rápida que la mitad de la velocidad de medir el tiempo. Puesto que medir el tiempo se reproduce utilizando el procesamiento OR-exclusivo de las señales DATA y STB, el sistema efectivamente tolera dos veces la cantidad de sesgo entre los datos de entrada y medir el tiempo comparado con la situación cuando una señal de medir el tiempo se envía directamente a través de una sola línea de datos dedicada. Las señales de los pares de Datos MDDI, MDDI_Stb+, y MDDI_Stb- se operan en un modo diferencial para maximizar la inmunidad de los efectos negativos del ruido. Cada par diferencial está finalizado en paralelo con la impedancia característica del cable o el conductor que se utiliza para transferir las señales. Generalmente, todas terminaciones en paralelo residen en el dispositivo de cliente. Éste está cerca del receptor diferencial para el tráfico sin retorno (datos enviados desde el anfitrión al cliente) , pero está en el extremo de accionamiento del cable u otros conductores o elementos de transferencia para el tráfico de retorno (datos enviados desde el cliente hasta el anfitrión) . Para el tráfico de retorno la señal es accionada por el cliente, reflejada mediante el receptor de alta impedancia en el anfitrión, y termina en el cliente. Esto evita la necesidad de una doble terminación que incrementaría el consumo de corriente eléctrica. También funciona a velocidades de datos mayores que las del retraso de ida ' y vuelta recíprocas en el cable . Los conductores o señales MDDI_Stb+ y MDDI_Stb- solamente son accionados por el anfitrión. Una configuración ejemplar de elementos útil para lograr que los manej adores, los receptores y las terminaciones transfieran las señales como parte de la interfaz MDD inventiva se muestra en la FIGURA 42. Esta interfaz ejemplar utiliza una detección de bajo voltaje, que aquí es de 200 mV, con menos que 1 voltio de oscilaciones de energía eléctrica y un bajo gasto de energía. El manejador de cada par de señal tiene una salida de corriente diferencial . Mientras se reciben los paquetes MDDI los pares MDDI_Data y MDDI_Stb utilizan un receptor diferencial convencional con un umbral de voltaje de cero voltios. En el estado de hibernación las salidas del manejador están deshabilitadas y los reóstatos de terminación en paralelo atraen el voltaje en cada par de señal a los cero voltios. Durante la hibernación un receptor especial en el par MDDI_DataO tiene un umbral de entrada de desplazamiento de 125 mV positivo, que provoca que el receptor de la línea de hibernación interprete el par de señal no accionado como un nivel de cero-lógico. Algunas veces el anfitrión o el cliente simultáneamente accionan el par diferencial a un nivel de uno-lógico o a un nivel de cero-lógico para garantizar un nivel lógico válido en el par cuando la dirección del flujo de datos cambia (desde el anfitrión al cliente o del cliente al anfitrión) . El rango de voltaje de salida y las especificaciones de salida deben incluso cumplir con salidas accionadas simultáneamente que están accionadas en el mismo nivel lógico. En algunos sistemas puede ser necesario accionar una corriente pequeña dentro del par diferencial terminado para crear un pequeño voltaje de desplazamiento en ciertos momentos durante la hibernación y cuando el enlace se despierta del estado de hibernación. En esas situaciones, los circuitos de polarización de corriente de desplazamiento habilitados accionan los niveles actuales a los que se hace referencia como : I_sD-and-RX- diodo ESD interno y entrada de receptor diferencial con lESD-an-R < 1 µA típicamente; ITX-HÍ-Z- salida de manejador diferencial en el estado de alta impedancia con ITX-HÍ-Z = 1 µA típicamente; y I_xter_ai-ESD- la fuga a través de los diodos de protección ESD externos con Iextemai-ESD < 3 µA típicamente . Cada una de esas corrientes de fuga se ilustra en la FIGURA 101. Los circuitos elevadores y reductores de voltaje deben alcanzar el voltaje diferencial mínimo bajo las condiciones de fuga del peor caso anteriormente descritas cuando todo ocurre simultáneamente. La fuga total es < 4 µA para el modo interno sin los diodos de protección ESD externos y = 10 µA para el modo externo con la protección ESD externa. Los parámetros y las características eléctricas de los manej adores de la línea diferencial y los receptores de línea se describen en la Tabla VIII. Funcionalmente, el manejador 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 las salidas está bien correspondido en la línea diferencial que está accionada diferencialmente. En la mayoría de las implementaciones, la oscilación de voltaje en las salidas es menor que la oscilación en la entrada para minimizar el consumo de energía eléctrica y las emisiones electromagnéticas. La Tabla VIII presenta una oscilación de voltaje mínima que está alrededor de los 0.5V. Sin embargo, pueden utilizarse otros valores, como lo saben bien quienes son expertos en la técnica, y se contempla un valor más pequeño en algunas modalidades, dependiendo de las restricciones del diseño. Los receptores en línea diferenciales tienen las mismas características que un comparador de voltaje de alta rapidez. 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 un uno-lógico si : (Vinput+) - (Vinput-) es mayor que cero. Otra manera para describir esto es un amplificador diferencial con una ganancia muy grande (virtualmente infinita) con la salida sujeta a niveles de voltaje de 0 y 1 lógicos. El sesgo de retraso entre los pares diferentes debe minimizarse para operar el sistema de transmisión diferencial a la rapidez potencial más elevada. En la FIGURA 42, un controlador 4202 de anfitrión y un controlador 4202 de cliente o de despliegue se muestran transfiriendo paquetes a través del enlace 4206 de comunicación. El controlador de anfitrión emplea una serie de tres manejadores 4210, 4212, y 4214 para recibir las señales DATA y STB de anfitrión que se van a transferir, así como para recibir las señales DATA de cliente que se van a transferir, mientras que el cliente emplea los tres manej adores 4230, 4232, y 4234. El manejador responsable del paso de anfitrión DATA (4212) emplea una entrada de señal de habilitación para permitir la activación del enlace de comunicación generalmente sólo cuando se desea la transferencia desde el anfitrión hacia el cliente. Dado 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 manejador (4212) . Las entradas de cada uno de los receptores de DATA y STB de cliente (4132, 4230) tienen impedancias de terminación o reóstatos 4218 y 4220, respectivamente distribuidos a través de los mismos. El manejador 4234 en el controlador de cliente se utiliza para preparar las señales de datos que se transfieren desde el cliente al anfitrión, en donde el manejador 4214 en el lado de entrada, procesa los datos. Los receptores especiales (manej dores) 4212 y 4236 se acoplan o se conectan a las líneas de DATA, y generan o utilizan el desplazamiento de voltaje de 125 mV previamente discutido, como parte del control de hibernación discutido anteriormente. Los desplazamientos provocan que los receptores en línea de hibernación interpreten los pares de señales sin accionar como un nivel de cero-lógico. Los manejadores y las impedancias anteriores pueden formarse como componentes discretos o como parte de un módulo de circuito, o en un circuito integrado de aplicación específica (ASIC) que actúa como una solución codificadora o descodificadora más efectiva en costos. Puede verse fácilmente que la energía se transfiere al dispositivo de cliente, o pantalla, desde el dispositivo anfitrión utilizando las señales etiquetadas HOSTJPwr y HOST_Gnd a través de un par de conductores. La porción HOST_Gnd de la señal actúa como la tierra de referencia y la trayectoria o señal de retorno de suministro de energía eléctrica para el dispositivo de cliente. La señal H0ST_Pwr actúa como el suministro de energía eléctrica del dispositivo de cliente que es accionado mediante el dispositivo anfitrión. En una configuración ejemplar, para aplicaciones de baja energía eléctrica, se permite al dispositivo de cliente extraer hasta 500 mA. La señal HOST_Pwr puede proporcionarse desde fuentes de energía eléctrica portátiles, tales como aunque sin limitarse a éstas como una batería tipo ion de litio o un paquete de batería que reside en el dispositivo anfitrión, y puede variar desde 3.2 hasta 4.3 voltios con respecto a H0ST_Gnd.

VII. Características de Cronometraje A. Vista General Las etapas y los niveles de señal empleados por un cliente para asegurar el servicio desde el anfitrión y por el anfitrión para proporcionar tal servicio, se ilustran en la FIGURA 43. En la FIGURA 43, la primera parte de las señales se ilustra mostrando un Paquete de Interrupción de Enlace que se transfiere desde el anfitrión y la línea de datos es accionada entonces hacia un estado de cero-lógico utilizando el circuito de polarización de alta impedancia. No se transmiten datos mediante la pantalla de cliente, o el anfitrión, que tiene su manejador deshabilitado. Puede verse una serie de pulsos estroboscópicos para la línea de la señal MDDI_Stb en la parte inferior, dado que MDDI_Stb está activo durante el Paquete de Interrupción de Enlace. Una vez que el paquete finaliza y el nivel lógico cambia a cero conforme el anfitrión acciona el circuito de polarización y la lógica a cero, la línea de la señal MDDI_Stb cambia a un nivel de cero-lógico también. Esto representa la finalización de la última transferencia de señal o servicio desde el anfitrión, y podría ocurrir en cualquier momento en el pasado, y se incluye para mostrar un cese previo del servicio, y el estado de las señales previo al comienzo del servicio. Si se desea, esa señal puede enviarse justo para reiniciar el enlace de comunicación en el estado propio sin una comunicación previa 'conocida' que se haya llevado a cabo mediante este dispositivo anfitrión. Como se muestra en la FIGURA 43, la salida de la señal desde el cliente se ajusta inicialmente en un nivel de cero-lógico. En otras palabras, la salida del cliente está en una alta impedancia, y el manejador se deshabilita. Cuando el servicio se está solicitando, el cliente habilita su manejador y envía una solicitud de servicio al anfitrión, que está en un periodo de tiempo designado tserice/ durante la cual la línea está accionada en un nivel de uno-lógico. Una cierta cantidad de tiempo pasa entonces o puede necesitarse antes de que el anfitrión detecte la solicitud, la cual se denomina como thos-detect/ después de lo cual el anfitrión responde con una secuencia de inicio de enlace al accionar la señal en un nivel de uno-lógico. En este punto, el cliente niega la solicitud, y deshabilita el manejador de solicitud del servicio para que la línea de salida de cliente se vaya nuevamente a un nivel de cero-lógico. Durante este tiempo, la señal MDDI_Stb está en un nivel de cero-lógico. El anfitrión acciona la salida de datos de anfitrión en el nivel '1' por un periodo denominado restar-high después de lo cual el anfitrión acciona el nivel lógico en cero y activa MDDI_Stb por un periodo denominado trestart-iow/ después de lo cual el primer tráfico sin retorno comienza con un Paquete de Encabezamiento de Sub-trama, y los paquetes del tráfico sin retorno se transfieren entonces . La señal MDDI_Stb se activa durante el periodo testar-io - y el subsecuente Paquete de Encabezamiento de Sub-trama. Las Tablas VII y VIII muestran tiempos representativos o periodos de procesamiento para la longitud de varios periodos anteriormente discutidos, y la relación para velocidades de datos mínimas y máximas ejemplares en donde: tU=Link DataRate' en donde Link_Data_Rate es la velocidad de bit de un solo par de datos . Tabal VII Tabla VIII Aquellos con experiencia en la técnica fácilmente comprenderán que las funciones de los elementos individuales ilustradas en las FIGURAS 41 y 42, son bien conocidas, y la función de los elementos de la FIGURA 42 se confirma mediante el diagrama de cronometraje en la FIGURA 43. Los detalles acerca de las terminaciones de la serie y los reóstatos 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 acerca de cómo ejecutar la codificación de los Datos Estroboscópicos y para recuperar de éstos el medir el tiempo.

B. Enlace Sin Retorno de Cronometraje de los Datos Estroboscópicos Las características de conmutación para la transferencia de datos en el enlace sin retorno desde la salida del manejador del anfitrión se muestran en la Tabla IX. La Tabla IX presenta una forma tabular del mínimo y máximo deseados, contra los tiempos típicos que van a ocurrir para ciertas transiciones de señales. Por ejemplo, la longitud de tiempo típica para que ocurra una transición desde el inicio hasta el final de un valor de datos (salida de '0' o '1'), una transición DataO hasta DataO, denominada ttdd- (host-output) , es ttb_t mientras que el tiempo mínimo es de aproximadamente ttbit-0.5 nseg., y el máximo es de aproximadamente ttb_.t+0.5 nseg. La separación relativa entre las transiciones en DataO, otras líneas de datos (DataX) , y las líneas estroboscópicas (Stb) , se ilustran en la FIGURA 44 en donde los DataO para el Estroboscopio, el Estroboscopio a Estroboscopio, Estroboscopio a DataO, DataO a non-DataO, non-DataO a non-DataO, non-DataO a Estroboscopio, y Estroboscopio a non-DataO que son transiciones que se muestran las cuales son referidas como ttds- (host-output) / ttss- (host-output) / Ysd- (host-output) / ttddx- (host-output) / ttdxdx- (host-output) _ ttdxs- (host-output) / Y ttsdx- (host-output) / respectivamente.

Tabla IX Los requerimientos de cronometraje MDDI típicos para la entrada del receptor del cliente para las mismas señales de transferencia de datos en el enlace sin retorno se muestran en la Tabla X. Dado que las mismas señales se discuten aunque con tiempo retrasado, no es necesaria una nueva figura para ilustrar las características de señal o el significado de las etiquetas respectivas, como lo pueden entender aquellos que tienen experiencia en la técnica.

TABLA X Las FIGURAS 45 y 46 ilustran la presencia de un retraso en la respuesta que puede ocurrir cuando el anfitrión deshabilita o habilita el manejador del anfitrión, respectivamente. En el caso del reenvío del anfitrión de ciertos paquetes, tales como el Paquete de Encapsulamiento de Enlace de Retorno o el Paquete de Medición de Retraso de Ida y Vuelta, el anfitrión deshabilita el manejador de línea después de que se han reenviado los paquetes deseados, de modo que los paquetes de Parámetro CRC, Alineación de Estroboscopio, y Todo en Cero ilustrados en la FIGURA 45 como si hubieran sido transferidos. Sin embargo, como se muestra en la FIGURA 45, el estado de la línea no necesariamente conmuta de '0' a un valor más elevado deseado instantáneamente, aunque esto potencialmente pueda alcanzarse con cierto control o elementos de circuito presente, pero toma un periodo de tiempo que denomina el periodo de Retraso de Habilitación del Manejador del anfitrión para responder. Aunque podría ocurrir virtualmente en forma instantánea de tal modo que este periodo de tiempo es 0 nanosegundos (nseg.) en longitud, podría extenderse más fácilmente durante un periodo algo más largo con 10 nseg. , que es una longitud de periodo máxima deseada, que ocurre durante los periodos de paquete Tiempo de Guarda 1 o Dar Vuelta 1. Mirando en la FIGURA 46, puede verse un cambio en el nivel de la señal que se experimenta cuando el Manejador del anfitrión está habilitado para transferir un paquete tal como el Paquete de Encapsulamiento de Enlace de Retorno o el Paquete de Medición de Ida y Vuelta. Aquí, después de que los periodos de paquete de Tiempo de Guarda 2 o Dar Vuelta 2, el manejador del anfitrión está habilitado y comienza a accionar un nivel, que aquí es '0', cuyo valor se aproxima o se alcanza durante un periodo de tiempo que se denomina como el periodo De Retraso que Habilita el Manejador del Anfitrión, que ocurre durante el periodo de Rehabilitación del Manejador, previo a que sea enviado el primer paquete. Ocurre un proceso similar para los manej adores y las transferencias de señal para el dispositivo de cliente, aquí una pantalla. Los lineamientos generales para la longitud de esos periodos, y sus relaciones respectivas se muestran en la Tabla XI a continuación.

TABLA XI C. Enlace de Retorno de Cronometraje de Datos Estroboscópicos Las características de conmutación y las relaciones de cronometraje para las señales de datos y estroboscopio utilizadas para transferir datos en el enlace de retorno de la salida del manejador de cliente se muestran en las FIGURAS 47 y 48. Los tiempos típicos para ciertas transiciones de señal se discuten a continuación. La FIGURA 47 ilustra la relación en la entrada del receptor del anfitrión entre el cronometraje de los datos que se están transfiriendo y los bordes frontal y posterior de los pulsos del estroboscopio. Es decir, a lo que se hace referencia como el tiempo de establecimiento para el borde ascendente o frontal de las señales de estroboscopio, t?U-sr y el tiempo de establecimiento para el borde de posterior o descendente de las señales de estroboscopio, tsu-sf- Una longitud de tiempo típica para esos periodos de establecimiento está en el orden de un mínimo de 8 nanosegundos . La FIGURA 48 ilustra las características y correspondientes conmutaciones de retraso de salida del cliente desarrolladas por el cronometraje de datos de retorno. En la FIGURA 48, puede verse la relación entre el cronometraje de los datos que se transfieren y los bordes frontal y posterior, de los pulsos del estroboscopio que representan el retraso inducido. Es decir, a lo que se hace referencia como el retraso de propagación entre el borde ascendente o frontal de las señales del estroboscopio y los datos (válidos) , tpa-Sf, y el retraso de propagación entre los datos y el borde posterior o descendente de las señales de estroboscopio, tpd_sf. Una longitud de tiempo máxima típica para esos periodos del retraso de propagación está en el orden de los 8 nanosegundos VIII . Implementación de Control de Enlace (Operación del Controlador de Enlace) A. Procesador de Paquete de Máquina de Estado Los paquetes que se transfieren a través de un enlace MDDI son despachados muy rápidamente, en forma típica a una velocidad del orden de 300 Mbps o más, tal como 400 Mbps, aunque por supuesto pueden ajustarse velocidades más bajas, según se desee. Este tipo de bus o rapidez de enlace de transferencia es demasiado grande para microprocesadores en la actualidad comercialmente disponibles (económicos) de propósito general, o similares para el control. Por lo tanto, una implementación práctica para lograr este tipo de transferencia de señal es utilizar una máquina de estado programable para analizar la corriente del paquete de entrada para producir paquetes que se transfieren o se reorientan hacia el sub-sistema audiovisual apropiado para el cual están pensados. Tales dispositivos son bien conocidos y utilizan circuitos que generalmente se dedican a un número limitado de operaciones, funciones, o estados para alcanzar una rapidez elevada deseada o una operación de rapidez muy elevada. Los controladores, procesadores o elementos de procesamiento de propósito general, pueden utilizarse para actuar más apropiadamente en o manipular parte de la información tal como los paquetes de control o estado, que tienen demandas de rapidez más baja. Cuando estos paquetes se reciben (control, estado u otros paquetes predefinidos), la máquina de estado podría pasarlos a través de una memoria intermedia de datos o un elementos de procesamiento similar hacia el procesador de propósito general para que los paquetes puedan activarse para proporcionar un resultado deseado (efecto) mientras los paquetes de audio y visuales se transfieren a su destino apropiado para su activación. Si futuros microprocesadores u otros controladores, procesadores o elementos de procesamiento de propósito general se fabrican para alcanzar capacidades de procesamiento de velocidad de datos más elevada, entonces las máquinas de estado o estados que se discuten a continuación podrían también implementarse utilizando el control de software de tales dispositivos, típicamente como programas almacenados en un elemento o medio de almacenamiento . La capacidad del procesador de propósito general puede realizarse en algunas modalidades al sacar ventaja de la potencia de procesamiento, o los ciclos excedentes disponibles para microprocesadores (los CPU) en aplicaciones de computadora, o controladores, procesadores o procesadores de señal digital (los DSP) , circuitos especializados, o los ASIC que se encuentran en dispositivos inalámbricos, muchos de la misma manera en que algunos módems o procesadores gráficos utilizan la potencia de procesamiento de los CPU que se encuentran en las computadoras para ejecutar algunas funciones y reducir la complejidad y los costos de hardware. Sin embargo, este ciclo de compartición o utilización puede impactar negativamente la rapidez de procesamiento, el cronometraje o la operación global de tales elementos, así que en muchas aplicaciones se prefieren circuitos o elementos dedicados para este procesamiento general . Para que los datos de la imagen se vean en una pantalla (micro-pantalla) , o para recibir confiablemente todos los paquetes enviados por el dispositivo del anfitrión, se sincroniza el procesamiento de la señal del cliente con el cronometraje del canal del enlace sin retorno. Es decir, las señales que llegan al cliente y los circuitos de cliente necesitan sincronizarse en tiempo sustancialmente para que ocurra un procesamiento de señal apropiada. En la ilustración de la FIGURA 49 se presenta un diagrama de estados de nivel elevado alcanzado para la señal para una modalidad. En la FIGURA 49 los "estados" de sincronización del enlace sin retorno posibles para una máquina 4900 de estado se muestran estando clasificados como un ESTADO 4904 de TRAMAS ASYNC, dos ESTADOS 4902 y 4906 SYNC de ADQUISICIÓN, y tres ESTADOS 4908, 4910 Y 4912 IN-SYNC.

Como se muestra mediante la etapa o estado 4902 de inicio, el despliegue o el cliente, tal como un dispositivo de presentación, inician un estado preseleccionado de "no sync" , y busca una palabra única en el primer paquete del encabezamiento del Sub-trama que se detecta. Se debe hacer notar que este estado de no sync representa el ajuste de comunicación mínimo o ajuste "vuelta atrás" en el cual se selecciona una interfaz Tipo 1. Cuando la palabra única se encuentra durante la búsqueda, el cliente guarda el campo de longitud de Sub-trama. No existe verificación de los bits CRC para continuar procesando esta primer trama, o hasta que se obtenga la sincronización. Si esta longitud de sub-trama es cero, entonces el estado sync de procesamiento continúa de acuerdo con un estado 4904 etiquetado aquí como el estado "async frames" , que indica que no se ha alcanzado la sincronización. Esta etapa en el procesamiento se etiqueta como si hubiera encontrado una cond 3 , o condición 3 , en la FIGURA 49. De otro modo, si la longitud de trama es mayor que cero, entonces el estado sync de procesamiento continúa hacia un estado 4906 en donde el estado de la interfaz se establece como "found one sync frame" . Esta etapa en el procesamiento se etiqueta como si se encontrara una cond 5, o condición 5, en la FIGURA 49. Además, si la máquina de estado ve un paquete de encabezamiento de trama y una determinación good CRC para una longitud de trama mayor que cero, el procesamiento continúa hacia el estado "found one ' sync frame" . Esto se etique como si se encontrara una cond 6, o condición 6, en la FIGURA 49. En cada situación en la cual el sistema está en un estado diferente al de "no sync" , si un paquete con un resultado good CRC se detecta, entonces la interfaz se cambia al estado 4908 "in-sync" . Esta etapa en el procesamiento se etiqueta como si se hubiera encontrado una cond 1, o condición 1, en la FIGURA 49. Por otro lado, si la CRC en cualquier paquete no es correcta, entonces el estado sync de procesamiento continúa o regresa al estado 4902 de la interfaz o al estado "NO SYNC FRAME" . Esta porción del procesamiento se etiqueta como si se encontrara una cond 2 , o condición 2 , en el diagrama de estado de la FIGURA 49.

B. Tiempo de Adquisición para Sync La interfaz puede configurarse para ajustar cierto número de "sync errors" antes de decidir que la sincronización se pierda y regresar al estado "NO SYNC FRAME". En la FIGURA 49, una vez que la máquina de estado ha alcanzado "IN-SYNC STATE" y no se encuentran errores, se encuentra continuamente un resultado de cond 1, y permanece en el estado "IN-SYNC" . Sin embargo, una vez que el resultado cond 2 se detecta, el procesamiento cambia el estado a un estado 4910 "one-sync-error" . Para este punto, si el procesamiento da por resultado la detección de otro resultado cond 1, entonces la máquina de estado regresa al estado "in-sync", de lo contrario encuentra otro resultado cond 2, y se mueve hacia un estado 4912 "TWO-SYNC-ERRORS" . Nuevamente, si ocurre una cond 1, el procesamiento regresa a la máquina de estado en el estado "IN-SYNC" . De lo contrario, se encuentra otra cond 2 y la máquina de estado regresa al estado "no-sync" . También puede ser comprensible que la interfaz pudiera encontrar un "link shutdown packet" , entonces esto provocará que el enlace finalice las transferencias de datos y regrese al estado "no-sync frame" ya que no existe nada con que sincronizarse, a lo cual se hace referencia como encontrar una cond 4, o condición 4 en el diagrama de estado de la FIGURA 49. Se entiende que es posible que exista una repetición de "false copy" de la palabra única que puede aparecer en alguna ubicación fija dentro de la Sub-trama. En esta situación, es altamente improbable que la máquina de estado se sincronice con la Sub-trama debido a que la CRC en el Paquete de Encabezamiento de Sub-trama deba también ser válida cuando se procesa para que la interfaz MDD de procesamiento proceda al estado "IN SYNC" . La longitud de sub-trama en el Paquete de Encabezamiento de Sub-trama puede establecerse en cero para indicar que el anfitrión transmitirá solamente una sub-trama antes de que se interrumpa el enlace, y la interfaz MDD se coloca en o se configura en un estado de hibernación inactivo. En este caso, el cliente debe recibir inmediatamente los paquetes a través del enlace sin retorno después de detectar el Paquete de Encabezamiento de sub-trama debido a que solamente se envió una sola Sub-trama antes de las transiciones de enlace al estado inactivo. En operaciones normales o típicas, la longitud de sub-trama no es cero y el cliente solamente procesa los paquetes de enlace sin retorno mientras que la interfaz está en esos estados que se muestran colectivamente como estado "IN-SYNC" en la FIGURA 49. Puede unirse un dispositivo de cliente de modo externo al anfitrión mientras el anfitrión está transmitiendo ya una secuencia de datos del enlace sin retorno. En esta situación, el cliente debe sincronizarse con el anfitrión. El tiempo que se requiere para que un cliente se sincronice con la señal de enlace sin retorno es variable dependiendo del tamaño de la Sub-trama y de la velocidad de datos en el enlace sin retorno. La probabilidad de detectar una "false copy" de la palabra única como parte de lo aleatorio o más aleatorio, de datos en el enlace sin retorno es mayor cuando el tamaño de la sub-trama es más grande. Al mismo tiempo, la capacidad para recuperarse de una detección falsa es más lenta, y el tiempo que lleva hacerlo es más largo, cuando la velocidad de datos del enlace sin retorno es más lenta.

C. Iniciación Como se estableció anteriormente, en el momento de "start-up", el anfitrión configura el enlace sin retorno para operar en o por debajo de un mínimo requerido, o deseado, de velocidad de datos de 1 Mbps, y configura la longitud de sub-trama y la velocidad de trama de los medios apropiadamente para una aplicación determinada. Es decir, tanto los enlaces sin retorno como de retorno inician su operación utilizando la interfaz Tipo 1. Esos parámetros generalmente sólo se van a utilizar temporalmente mientras el anfitrión determina la capacidad o configuración deseadas para pantalla del cliente (u otro tipo de dispositivo de cliente) . El anfitrión envía o transfiere un Paquete de Encabezamiento de sub-trama a través del enlace sin retorno seguido por un Paquete de Encapsulamiento de Enlace de Retorno que tiene un bit '0' de los Indicadores de Solicitud que se establecen para un valor de uno (1) , par solicitar que la pantalla o el cliente respondan con un Paquete de Capacidad de Cliente. Una vez que la pantalla adquiere la sincronización en (o con) el enlace sin retorno, envía un Paquete de Capacidad de Cliente y un Paquete de Solicitud y Estado de Cliente a través del enlace o canal de retorno. El anfitrión examina los contenidos del Paquete de Capacidad de Cliente para determinar cómo reconfigurar el enlace para un nivel óptimo o deseado de desempeño. El anfitrión examina los campos de Versión de Protocolo y Versión de Protocolo Mínima para confirmar que el anfitrión y el cliente utilicen versiones del protocolo que son compatibles entre sí. Las versiones de protocolo generalmente permanecen como el primero de dos parámetros del Paquete de capacidad de cliente para que la compatibilidad pueda determinarse incluso cuando otros elementos del protocolo podrían no ser compatibles o entenderse completamente como si fueran compatibles .

D. Procesamiento CRC Para todos los tipos de paquete, la máquina de estado del procesador de paquete se asegura que el verificador CRC se controle apropiada o adecuadamente. También incrementa un contador de error CRC cuando una comparación CRC da por resultado uno o más errores que se detectan, y reinicia el contador CRC al inicio de cada sub-trama que se está procesando.

E. Pérdida Alternativa de Verificación de Sincronización Mientras que la serie de etapas o estados anteriores funciona para producir velocidades de datos más elevadas o una rapidez de rendimiento total, se ha descubierto que una disposición o cambio alternativo en las condiciones el cliente utiliza para declarar que existe una pérdida de sincronización con el anfitrión, que puede utilizarse efectivamente para alcanzar incluso velocidades o un rendimiento total de datos más elevados. La nueva modalidad inventiva tiene la misma estructura básica, pero con condiciones para cambiar estados cambiados . Adicionalmente se implementa un nuevo contador para ayudar a realizar las verificaciones para la sincronización de sub-trama. Esas etapas y condiciones se presentan con relación a la FIGURA 63 , en la cual se ilustra una serie de estados y condiciones útiles para establecer las operaciones del método o la máquina de estado. Solamente se muestran para claridad las porciones "ACQUIRING-SYNC STATES" e "IN-SYNC STATES". Además, dado que los estados resultantes son sustancialmente los mismos, como lo es la propia máquina de estado, utilizan la misma numeración. Sin embargo, las condiciones para cambiar los estados (y la operación de la máquina de estado) varían un poco, así que todos se vuelven a numerar para claridad entre las dos figuras (1, 2, 3, 4, 5, y 6, contra 61, 62, 63, 64, y 65), por conveniencia para identificar las diferencias. Dado que el estado ASYNC FRAME no se considera en esta discusión, un estado (4904) y una condición (6) no se utilizan ya más en la figura. En la FIGURA 63 , el sistema o cliente (para despliegue o presentación) inician con la máquina 5000 de estado en el estado 4902 pre-seleccionado "no sync", como en la FIGURA 49. El primer estado cambia para cambiar los estados de la condición 4902 no-sync es una condición 64 que es el descubrimiento del patrón sync . Se asume que la CRC del encabezamiento de sub-trama también pasa en este paquete (cumple la condición 61) , el estado de la máquina de estado del procesador de paquete puede cambiarse al estado 4908 in-sync. Un error sync, en la condición 62, provocará que la máquina de estado se desplace al estado 4910, y que ocurra un segundo estado 4912. Sin embargo, se ha descubierto que cualquier falla de CRC de un paquete MDDI provocará que la máquina de estado se mueva hacia fuera del estado 4908 in-sync, hacia el estado 4910 de error sync . Otra falla de CRC de cualquier paquete MDDI provocará un movimiento hacia los dos estados 4912 de falla sync. Un paquete descodificado con un valor CRC correcto provocará que la máquina de estado regrese al estado 4908 in-sync.

Lo que se ha cambiado es la utilización del valor CRC o la determinación para 'cada' paquete. Es decir, para hacer que la máquina de estado mire el valor CRC para cada paquete para determinar una pérdida de sincronización en vez de solamente observar los paquetes de encabezamiento de sub-trama. En esta configuración o proceso, una pérdida de sincronización no se determina utilizando la palabra única y sólo los valores CRC de encabezamiento de Sub-trama. Esta nueva implementación de interfaz permite que el enlace de la interfaz MDD reconozca las fallas de sincronización mucho más rápidamente, y que por lo tanto, se recupere de ellas más rápidamente también. Para hacer a este sistema más contundente, el cliente también debería agregar o utilizar un contador de Sub-trama. El cliente entonces verifica la presencia de una palabra única en el momento en el que espera que llegue u ocurra una señal . Si la palabra única no ocurre en el momento correcto, el cliente puede reconocer que ha ocurrido una falla de sincronización mucho más rápidamente de que si tuviera que esperar varios tiempos de paquete (aquí tres) o periodos que fueran más grandes que la longitud de una sub-trama. Si la prueba de la palabra única indica que no está presente, en otras palabras que el cronometraje es incorrecto, entonces el cliente puede inmediatamente declarar una pérdida de enlace de sincronización y moverse hacia el estado de no-sync. El proceso de verificar la presencia de la palabra única apropiada, agrega una condición 65 (cond 65) a la máquina de estado que dice que la palabra única es incorrecta. Si se espera que un paquete de sub-trama se reciba en el cliente y no corresponde, el cliente puede inmediatamente ir al estado 4902 de no-sync, ahorrando un tiempo de espera adicional para múltiples errores de sync (condición 62) que normalmente se encuentra atravesando por medio de los estados 4910 y 4912. Este cambio utiliza un contador adicional o función de conteo en el núcleo del cliente para contar la longitud de sub-trama. En una modalidad, una función de cuenta regresiva se utiliza y la transferencia de cualquier paquete que estuviera siendo procesado actualmente se interrumpe para verificar la palabra única de la sub-trama si el contador ha expirado. Alternativamente, el contador puede contar, con el contador que está siendo comparado con un valor máximo deseado o deseado en particular, en un punto en el que el paquete actual se verifica. Este proceso protege al cliente de la descodificación de los paquetes que se reciben incorrectamente en el cliente con longitudes de paquete extraordinariamente largas. Si el contador de la longitud de sub-trama necesita interrumpir algún otro paquete que estuviera siendo descodificado, se puede determinar una pérdida de sincronización dado que ningún paquete podría cruzar un límite de sub-trama.

IX. Procesamiento de Paquete Para cada tipo de paquete anteriormente discutido que la máquina de estado recibe, se lleva a cabo una etapa de procesamiento particular o series de etapas para implementar la operación de la interfaz . Los paquetes de enlace sin retorno generalmente se procesan de acuerdo con un procesamiento ejemplar que se lista en la Tabla XII a continuación.

Tabla XII Tipo de Paquete Respuesta de la máquina de estado del procesador de paquete Corriente de Audio Envía el ajuste de la velocidad de (AS) la muestra de audio a un generador de reloj de muestra de audio, separa las muestras de audio del tamaño especificado, desempaqueta los datos de la muestra de audio cuando es necesario, y enruta las muestras de audio hacia la muestra de audio apropiada FIFO Mapa de Color (CM) Lee el tamaño del mapa de color y los parámetros de desplazamiento, y escribe los datos del mapa de color en una memoria o ubicación de almacenamiento del mapa de color.

Encapsulamiento del Facilita el envío de paquetes en la Enlace de Retorno dirección de retorno en el tiempo (REL) apropiado. Se examinan los indicadores del enlace de retorno y los paquetes de Capacidad de Cliente se envían según sea necesario. Los paquetes de Solicitud y Estado de Cliente también se envían cuando sea apropiado . Capacidad del Cliente Envía este tipo de paquete cuando es (CC) solicitado por un anfitrión utilizando el campo de indicadores de enlace de retorno del Paquete de Encapsulamiento de Enlace de Retorno Teclado (K) Pasa esos paquetes hacia y desde el procesador de propósito general que se comunica con un dispositivo tipo teclado, si está presente alguno, y lo utiliza si se desea Dispositivo de Pasa esos paquetes hacia y desde el Señalamiento (PD) procesador de propósito general que se comunica con un dispositivo tipo señalamiento, si es que está presente alguno, y lo utiliza si se desea. Interrupción de Registra el hecho de que el enlace Enlace (LS) se interrumpe e informa a un procesador de propósito general .

Solicitud y Estado de Envía este paquete como el primer Servicio del Cliente paquete en el Paquete de (CSRS) Encapsulamiento del Enlace de Retorno .

Tipo de Paquete Respuesta de la máquina de estado del procesador de paquete Ejecutar Tipo de Puede actuar en tales paquetes ya Transferencia sea directamente o al Intracelular (PTH) transferirlos al procesador de propósito general, también dando instrucciones al hardware para que experimente un cambio de modo X. Reducir la Velocidad de Datos del Enlace de Retorno Se ha observado que ciertos parámetros utilizados para el controlador de enlace del anfitrión pueden ajustarse o configurarse de cierta manera para alcanzar una velocidad de datos del enlace de retorno máximos o más optimizados (escala), lo cual es muy deseable. Por ejemplo, durante el tiempo que se utiliza para transferir el campo de Paquetes de Datos de Retorno del Paquete de Encapsulamiento de Enlace de Retorno, el par de señal MDDI_Stb bascula para crear medir el tiempo de datos periódicos a la mitad de la velocidad de datos del enlace sin retorno. Esto ocurre debido a que el controlador de enlace del anfitrión genera la señal MDDI_Stb que corresponde a la señal MDDI_DataO como si estuviera enviando todos los ceros. La señal MDDI_Stb se transfiere desde el anfitrión hasta un cliente en donde se utiliza para generar una señal de medir el tiempo para transferir datos del enlace de retorno desde el cliente con lo cual los datos de retorno se envían de vuelta al anfitrión. Una ilustración de las cantidades de retraso típicas encontradas para la transferencia y procesamiento de señal en las trayectorias sin retorno y retorno en un sistema que emplea la MDDI, se muestra en la FIGURA 50. En la FIGURA 50, se muestra una serie de valores de retraso 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., como se muestra cerca de las porciones de procesamiento para generación Stb+/-, cable de transferencia al cliente, receptor de cliente, generación de medir el tiempo, registrar el tiempo de señal, generación de Data0+/-, cable de transferencia al anfitrión, y fases de receptor del anfitrión, respectivamente. Dependiendo de la velocidad de los datos del enlace sin retorno y de los retrasos en el procesamiento de señal encontrados, puede requerirse más tiempo de un ciclo en la señal MDDI_Stb para este efecto de "ida y vuelta" o el conjunto de eventos que se va a completar, lo cual da por resultado un consumo indeseable de cantidades de tiempo o ciclos. Para eludir este problema, el Divisor de la Velocidad de Retorno hace posible un bit a la vez en el enlace de retorno para abarcar múltiples ciclos de la señal MDDI_Stb. Esto significa que la velocidad de datos del enlace de retorno es menor que la velocidad de enlace sin retorno . Debe hacerse notar que la longitud real de los retrasos de señal a través de la interfaz puede diferir dependiendo de cada sistema o hardware anfitrión-cliente específicos que se estén utilizando. Aunque no se requiere, cada sistema puede estar hecho generalmente para desempeñarse mejor al utilizar el Paquete de Medición de Retraso de Ida y Vuelta para medir el retraso real en un sistema de modo que el Divisor de la Velocidad de Retorno pueda establecerse en un valor óptimo. El anfitrión puede soportar ya sea un muestreo de datos básico que es más simple pero opera a una rapidez más lenta o un muestreo de datos avanzado que es más complejo pero soporta velocidades de datos de retorno más elevadas. La capacidad del cliente para soportar ambos métodos se considera la misma. Un retraso de ida y vuelta se mide cuando se tiene un anfitrión que envía un Paquete de Medición de Retraso de Ida y Vuelta al cliente. El cliente responde a este paquete al enviar una secuencia de unos de vuelta al anfitrión dentro de, o durante, una ventana de medición preseleccionada en el paquete que se llama campo de Periodo de Medición. El cronometraje detallado de esta medición se describió previamente . El retraso de ida y vuelta se utiliza para determinar la velocidad a la cual pueden muestrearse en forma segura los datos del enlace de retorno . La medición del retraso de ida y vuelta consiste en determinar, detectar o contar el número de intervalos de medir el tiempo de los datos del enlace sin retorno que ocurre entre el inicio del campo de Periodo de Medición y el inicio del periodo de tiempo cuando la secuencia de respuesta Oxff, Oxff, 0x00 se recibe de vuelta en el anfitrión desde el cliente. Nótese que es posible que la respuesta del cliente pudiera recibirse en una fracción pequeña del periodo de medir el tiempo de enlace sin retorno antes de que el conteo de medición estuviera a punto de incrementarse. Si este valor no modificado se utiliza para calcular el Divisor de la Velocidad de Retorno podrían provocarse errores de bit en el enlace de retorno debido a un muestreo de datos no confiable. Un ejemplo de esta situación se ilustra en la FIGURA 51, en donde las señales que representan a MDDI_Data en el anfitrión, MDDI_Stb en el anfitrión, medir el tiempo de datos del enlace sin retorno en el anfitrión, y un Conteo de Retardo se ilustran en forma gráfica. En la FIGURA 51, la secuencia de respuesta se recibió desde el cliente en una fracción del periodo de medir el tiempo del enlace sin retorno antes de que el Conteo de Retardo estuviera a punto de incrementarse de 6 a 7. Si se asume que el retardo va a ser 6, entonces el anfitrión muestreará los datos de retorno justo después de una transición de bit o posiblemente a la mitad de la transición de bit. Esto podría dar por resultado un muestreo erróneo en el anfitrión. Por esta razón, el retardo medido debería típicamente incrementarse por uno antes de que se utilizara para calcular el Divisor de Velocidad de Retorno. El Divisor de Velocidad de Retorno es el número de ciclos MDDI_Stb que el anfitrión debiera esperar antes de muestrear los datos del enlace de retorno. Dado que MDDI_Stb se cicla a una velocidad que es la mitad de la velocidad de enlace sin retorno, la medición de retardo de ida y vuelta corregida necesita dividirse entre 2 y luego redondearse al siguiente número entero. Expresado como una fórmula, esta relación es: reverse _rate Para el ej emplo dado, esto se convierte en: reverse _ rate _ divisor = RoundUpT Nextlnteger ( < Si la medición del retardo de ida y vuelta se utiliza en este ejemplo en donde 7 se opone a 6, entonces el Divisor de Velocidad de Retorno sería también igual a 4. Los datos del enlace de retorno se muestrean mediante' el anfitrión en el borde ascendente de Medir el Tiempo de Enlace de Retorno. Existe un contador o un circuito o dispositivo conocido similar presente tanto en el anfitrión como en el cliente (pantalla) para generar Medir el Tiempo de Enlace de Retorno. Los contadores se inicializan de modo que el primer borde ascendente de medir el tiempo de enlace de retorno ocurre al inicio del primer bit en el campo de los Paquetes de enlace de Retorno del paquete de Encapsulamiento de Enlace de Retorno. Esto se ilustra, por ejemplo como se da a continuación, en la FIGURA 52. Los contadores se incrementan en cada borde ascendente de la señal MDDI_Stb, y el número de conteos que ocurren hasta que la sobre-escritura de pase se establece por el parámetro Divisor de Velocidad de Retorno en el paquete de Encapsulamiento de Enlace de Retorno. Dado que la señal MDDI_Stb bascula en una mitad de la Velocidad de enlace sin retorno, entonces la velocidad de enlace de retorno es la mitad de la velocidad de enlace sin retorno dividida por el Divisor de Velocidad de Retorno. Por ejemplo, si la velocidad de enlace sin retorno es de 200 Mbps y el Divisor de Velocidad de Retorno es 4 entonces la velocidad de los datos del enlace de retorno se expresa como : _ 1 200Mbp _s_ _ n 25- M1?bps 2 4 Un ejemplo que muestra el cronometraje de las líneas de señal MDDI_DataO y MDDI_Stb en un Paquete de Encapsulamiento de Enlace de Retorno se muestra en la FIGURA 52, donde los parámetros de paquete utilizados para la ilustración tienen los valores: Longitud de Paquete = 1024 (0x0400) Longitud de Inversión de Sentido 1 = 1 Tipo de Paquete = 65 (0x41 ) Longitud de Inversión de Sentido 2 = 1 Indicadores de Enlace de Retorno = 0 Divisor de Velocidad de Retorno = 2 Parámetro CRC = 0xdb43 Todo en Cero es 0x00 Los datos de paquete entre los campos de Longitud de Paquete y Parámetro CRC son: 0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, Oxdb, 0x00, ... El primer paquete de enlace de retorno devuelto desde el cliente es el Paquete de Solicitud y Estado de 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, ... etc. Sin embargo, solamente el primer byte (0x07) es visible en la FIGURA 52. El primer paquete de enlace de retorno se desplaza en tiempo por casi un periodo de medir el tiempo de enlace de retorno en la figura para ilustrar un retardo de enlace de retorno real . Una forma de onda ideal con cero retardo de ida y vuelta del anfitrión al cliente se muestra como una traza de línea punteada . El byte MS del campo de Parámetro CRC se transfiere, precedido por un tipo de paquete, y luego el campo todo en cero. El estroboscopio del anfitrión se conmuta de uno a cero y regresa a uno conforme los datos desde el anfitrión cambian de nivel, formando pulsos más amplios. Conforme los datos se acercan a cero, el estroboscopio conmuta a la velocidad más elevada, solamente el cambio en los datos en la línea de datos provoca un cambio cerca del final del campo de alineación. El estroboscopio conmuta a la velocidad más elevada del resto de la figura debido a los niveles fijos de 0 ó 1 de la señal de datos por los periodos de tiempo extendidos, y las transiciones que caen en el patrón de pulso (borde) . Medir el tiempo del enlace de retorno para el anfitrión está en cero hasta el final del periodo de Inversión de Sentido 1, cuando medir el tiempo se inicia para ajustar los paquetes de enlace de retorno. Las flechas en la porción inferior de la figura indican cuándo los datos se muestrean, como es aparente a partir del resto de la descripción. El primer byte del campo de paquete que se transfiere (que aquí es 11000000) se muestra comenzando después de Inversión de Sentido 1 y el nivel de línea se ha estabilizado desde el manejador del anfitrión que está deshabilitado. El retardo en el paso del primer bit, como puede verse para el bit tres, puede verse en líneas punteadas para la señal de Datos . En la FIGURA 53, puede observarse valores típicos del Divisor de Velocidad de Retorno con base en la velocidad de datos del enlace sin retorno. El Divisor de Velocidad de Retorno real se determina como un resultado de una medición del enlace de ida y vuelta para garantizar una operación apropiada del enlace de retorno. Una primera región 5302 corresponde a un área de operación segura, una segunda región 5304 corresponde a un área de desempeño marginal, mientras que una tercera región 5306 indica los ajustes que son improbables que funcionen apropiadamente. La medición del retardo de ida y vuelta y del ajuste del Divisor de Velocidad de Retorno son los mismos mientras están operando con cualquiera de los ajustes del Tipo de Interfaz en cualquiera del enlace sin retorno o de retorno debido a que se expresan y se operan en términos de unidades de periodos de medir el tiempo reales más bien que números de bits transmitidos o recibidos.

XI . Inversión de Sentido y Tiempo de Guarda Como se discutió anteriormente, el campo Inversión de Sentido 1 en el Paquete de Encapsulamiento de Enlace de Retorno y el campo Tiempo de Guarda 1 en el Paquete de Medición de Retardo de Ida y Vuelta designan los valores para las longitudes de tiempo que permiten a los manejadores de la interfaz del anfitrión deshabilitarse antes de que los manej adores de la interfaz de cliente se habiliten. Los campos de Inversión de Sentido 2 y Tiempo de Guarda 2 proporcionan valores de tiempo que permiten a los manej adores del cliente deshabilitarse antes de que se habiliten los manejadores del anfitrión. Los campos de Tiempo de Guarda 1 y Tiempo de Guarda 2 generalmente se rellenan con valores preestablecidos o preseleccionados para longitudes que no implican que se vayan a ajustar. Dependiendo del hardware de la interfaz que se esté utilizando, estos valores pueden desarrollarse utilizando datos, empíricos y ajustándose en algunos casos para mejorar su operación. Diversos factores contribuyen para la determinación de la longitud de Inversión de Sentido 1 y estos son la velocidad de datos del enlace sin retorno, y el tiempo de deshabilitación máximo de los manej adores MDDI_Data en el anfitrión. El tiempo de deshabilitación del manejador del anfitrión máximo se especifica en la Tabla XI, donde se muestra que los manej adores tomen aproximadamente 10 nseg., máximo para deshabilitarse y aproximadamente 2 nseg., para habilitarse. El número mínimo de medir el tiempo de enlace sin retorno que se requieren para el manejador del anfitrión que se va a deshabilitar se expresa de acuerdo con la relación: ,? r .? ,. , . ForwardLinkDataRate __ „ , Clocks _to_ d?sablem = - — - — - — HostDriverDisableDelay^ ¿ÍÍT6TJCICG i " jjTi* LQlOTp jr El rango de valores permitidos para Inversión de Sentido 1 se expresa de acuerdo con la relación: tum_ArouM_l= donde el Factor del Tipo de Interfaz es 1 para el Tipo 1, 2 para el Tipo 2, 4 para el Tipo 3, y 8 para el Tipo-4. Combinando las dos ecuaciones anteriores, puede verse que el término Factor del Tipo de Interfaz se cancela, y se define la Inversión de Sentido 1 como: _ _, _ _, „ ,^_ »_, _t ( ForwardLikDatáRate HostDriveBisableDe& m? Turn_Aro nd_l=Ro ndUpToMxtIntegeY ^=- ° ) Por ejemplo, un enlace sin retorno Tipo 3 de 1500 Mbps utilizaría un retardo de Inversión de Sentido 1 de: Turn __ Around _1 = RoundUpToNextlntegerl = IBytes Conforme se incrementa el retardo de ida y vuelta, el margen de cronometraje se mejora a partir del punto de tiempo en el que el anfitrión está deshabilitado hasta el momento en el que el cliente está habilitado. Los factores que determinan la longitud del tiempo generalmente utilizados para Inversión de Sentido 2 son la velocidad de datos del enlace sin retorno, el tiempo de deshabilitación máximo de los manej adores MDDI_Data en el cliente, y el retardo de ida y vuelta del enlace de comunicación. El cálculo del tiempo que se requiere para deshabilitar el manejador del cliente esencialmente es el mismo que el del manejador del anfitrión anteriormente discutido, y se define de acuerdo con la relación: _-.? T _-. » _ ForwardLinkDataRate _. , _ . _ . .7 _ . Cloeks to_ d?sableT?2 = "t _ ,:1 " ^ — ;^~; ' D?splayDr?verD?sableDelaya InterfaceTypeFactorf WD y el rango de valores permitidos para Inversión de Sentido 2 se expresa como : Por ejemplo, un enlace sin retorno Tipo 3 de 1500 Mbps con un retardo de ida y vuelta de 10 mediciones de tiempo de enlace sin retorno utilizan un retardo de Inversión de Sentido 2 en el orden de: Clocks „to_ disábleTM¡ = ,"- • 1 On sec = 3.75 XII. Cronometraje de Enlace de Retorno Alternativo Aunque el uso del cronometraje y las bandas de guarda discutidas anteriormente funcionan para alcanzar una interfaz de velocidad de transferencia de datos elevada, se ha descubierto una técnica para aceptar longitudes de bit de retorno que no son más cortas que el tiempo de ida y vuelta, al cambiar el descubrimiento del cronometraje de retorno . Como se presentó anteriormente, la metodología previa del cronometraje del enlace de retorno se configura de tal forma que el número de ciclos de medir el tiempo se cuenta desde el último bit del Tiempo de Guarda 1 de un paquete de cronometraje de retorno hasta que el primer bit es muestreado en el borde ascendente de medir el tiempo 10. Esa es la o las señales de medir el tiempo que se utilizan para cronometrar las entradas y las salidas para la interfaz MDD. El cálculo para el Divisor de Velocidad de retorno está dado entonces por: reverse _rate ..divisor = RoundUpToNextlntegerí °Und ~trip -Ma^ + ^ ^ 2 J Esto proporciona un ancho de bit igual al retardo de ida y vuelta que da por resultado un enlace de retorno muy confiable. Sin embargo, el enlace de retorno ha mostrado ser capaz de correr más rápido, o a una velocidad de transferencia de datos más elevada, de lo cual se desea sacar ventaja. Una nueva técnica inventiva permite utilizar capacidades adicionales de la interfaz para alcanzar rapideces más elevadas. Esto se logra al tener el anfitrión de conteo del número de ciclos de medir el tiempo hasta que uno es muestreado, pero con el muestreo del anfitrión de la línea de datos tanto en los bordes ascendentes como descendentes durante el paquete del cronometraje de retorno. Esto permite que el anfitrión elija el punto de muestreo más útil o incluso óptimo dentro del bit de retorno para asegurar que el bit es estable. Es decir, para encontrar el borde ascendente más útil u óptimo para muestrear los datos en los paquetes de encapsulamiento de retorno del tráfico de retorno. El punto óptimo de muestreo depende tanto del divisor del enlace de retorno como de si el primer punto fue detectado en un borde ascendente o en un borde descendente. El nuevo método de cronometraje permite que el anfitrión sólo se concentre en el primer borde del patrón OxFF OxFF 0x00 enviado por el cliente para el cronometraje del enlace de retorno para determinar donde muestrear un paquete de encapsulamiento de retorno . Los ejemplos del bit de retorno que llegan y de cómo ese bit se vería para diversos divisores de la velocidad de retorno, se ilustran en la FIGURA 64, junto con un número de ciclos de medir el tiempo que han ocurrido desde el último bit del Tiempo de Guarda 1. En la FIGURA 64 se puede ver que si el primer borde ocurre entre un borde ascendente y descendente (etiquetado como ascender/descender) , el punto de muestreo óptimo para un Divisor de Velocidad de retorno de uno, el punto de muestreo óptimo es un borde de ciclo de medir el tiempo etiquetado como 'b' , ya que ese es el único borde ascendente que ocurre dentro del periodo del bit de retorno. Para un Divisor de Velocidad de retorno de dos, el punto de muestreo óptimo es probablemente aún el borde 'b' frontal dado que el borde 'C de ciclo está más cerca de un borde de bit que 'b' . Para un Divisor de Velocidad de retorno de cuatro, el punto de muestro óptimo es probablemente el borde 'd' de ciclo de medir el tiempo, ya que está más cerca del borde posterior del bit de retorno donde el valor se ha probablemente estabilizado. Regresando a la FIGURA 64, sin embargo, si el primer borde ocurre entre un borde descendente y ascendente (etiquetado como descender/ascender) , el punto de muestreo óptimo para un Divisor de Velocidad de retorno de uno, es el punto de muestreo del borde 'a' de ciclo de medir el tiempo ya que ese es el único borde ascendente dentro del periodo de tiempo del bit de retorno. Para un Divisor de Velocidad de retorno de dos, el punto de muestreo óptimo es el borde 'b' , y para un Divisor de Velocidad de retorno de cuatro, el punto de muestreo óptimo es el borde 'c' . Puede verse que conforme los divisores de velocidad de retorno se hacen grandes y más grandes, el punto de muestreo óptimo se vuelve más fácil de determinar o seleccionar, como debe ser el borde ascendente que está más cerca de la mitad. El anfitrión puede utilizar esta técnica para encontrar el número de bordes de medir el tiempo ascendentes antes del borde de datos ascendente de los datos de paquete de cronometraje que se observan en la línea de datos . Puede entonces decidirse con base en si el borde ocurre entre un borde ascendente y descendente o entre un borde descendente y ascendente, y qué Divisor de Velocidad de retorno es, cuántos ciclos de medir el tiempo adicionales se agregan a un contador de número, para razonablemente asegurar que el bit está siempre muestreado tan cerca de la mitad como sea posible. Una vez que el anfitrión ha seleccionado o determinado el número de ciclos de medir el tiempo, puede "explorar" varios divisores de la velocidad de retorno con el cliente para determinar si un Divisor de Velocidad de retorno en particular funcionará. El anfitrión (y el cliente) puede iniciar con un divisor de uno y verificar la CRC del paquete de estado de retorno recibido del cliente para determinar si esta velocidad de retorno funciona apropiadamente para la transferencia de datos. Si la CRC se altera, probablemente exista un error de muestreo, y el anfitrión puede incrementar el Divisor de Velocidad de retorno e intentar solicitar un paquete de estado de nuevo. Si el segundo paquete solicitado está alterado, el divisor puede incrementarse de nuevo y hacer la solicitud de nuevo. Si el paquete se descodifica correctamente, este Divisor de Velocidad de retorno puede utilizarse para todos los paquetes de retorno futuros . Este método es efectivo y útil debido a que el cronometraje de retorno no debiera cambiar desde el estimado de cronometraje de ida y vuelta inicial. Si el enlace sin retorno es estable, el cliente debe continuar descodificando los paquetes de enlace sin retorno incluso si existen fallas en el enlace de retorno. Por supuesto, es aún responsabilidad del anfitrión establecer un divisor del enlace de retorno para el enlace, dado que este método no garantiza un enlace de retorno perfecto. Además, el divisor dependerá primordialmente de la calidad de medir el tiempo que se está utilizando para generar medir el tiempo 10. Si ese medir el tiempo tiene una cantidad significativa de oscilación, existe una mayor posibilidad de un error de muestreo. Este error probablemente se incrementa con la cantidad de ciclos de medir el tiempo en el retardo de ida y vuelta. Esta implementación parece funcionar mejor para los datos de retorno Tipo 1, pero puede presentar problemas para los datos de retorno Tipo 2 a Tipo 4 debido al sesgo entre las líneas de datos que potencialmente son demasiado grandes para correr el enlace a la velocidad que funciona mejor para sólo un par de datos. Sin embargo, la velocidad de datos probablemente no necesita reducirse para el método previo incluso con el Tipo 2 a Tipo 4 para su operación. Este método puede también funcionar mejor si se duplica en cada línea de datos para seleccionar la ubicación de la muestra de medir el tiempo ideal u óptimo. Si se encuentran en el mismo tiempo de muestra para cada par de datos, este método continuaría funcionando. Si se encuentran en periodos de muestra diferentes, pueden utilizarse dos metodologías diferentes . Lo primero es seleccionar una ubicación de muestra más optimizada o deseada para cada punto de datos, incluso si no es el mismo para cada par de datos . El anfitrión 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-IV.' La otra opción es para que el anfitrión incremente el Divisor de Velocidad de retorno de modo que los bits de datos para cada par de datos pueda muestrearse en el mismo borde de medir el tiempo.

XIII. Efectos de Retardo y Sesgo de Enlace El sesgo de retardo en el enlace sin retorno entre los pares MDDI_Data y MDDI_Stb puede limitar la velocidad de datos máxima posible a menos que se utilice una compensación para el sesgo de retardo. Las diferencias en el retardo que provocan un sesgo en el cronometraje se deben a la lógica del controlador, los manejadores y los receptores de la línea, y el cable y los conectores como se detallan a continuación.

A. Análisis de Cronometraje de Enlace Limitado por el Sesgo (MDDI Tipo 1) 1. Ejemplo de Retardo y Sesgo de un Enlace Tipo 1 Un circuito de interfaz típico similar al que se muestra en la FIGURA 41, se muestra en la FIGURA 57 para ajustar un enlace de interfaz Tipo 1. En la FIGURA 57, los valores ejemplares o típicos para el retardo y sesgo de propagación se muestran para cada una de las diversas fases de procesamiento o interfaz de un enlace sin retorno MDDI Tipo 1. El sesgo en el retardo entre MDDI_Stb y MDDI_DataO provoca que el ciclo de trabajo de medir el tiempo de salida se distorsione. Los datos en la entrada D de la fase de circuito basculante del receptor (RXFF) que utiliza circuitos 5728, 5732 basculantes, cambia ligeramente después del borde de medir el tiempo para que pueda muestrearse confiablemente. La figura muestra dos líneas 5732a y 5732b de retardo en cascada que se utilizan para resolver dos problemas diferentes con la creación de esta relación de cronometraje. En la implementación actual esas pueden combinarse en un sólo elemento de retardo. Los datos, Stb, y el Cronometraje de Recuperación de Medir el Tiempo en un Enlace Tipo 1 para el procesamiento de señal ejemplar a través de la interfaz se ilustra en la FIGURA 58. El sesgo de retardo total que es generalmente significante surge o viene de la suma del sesgo en las siguientes fases: circuito basculante transmisor (TXFF) con circuitos 5704, 5706 basculantes; manejador del transmisor (TXDRVR) con manej adores 5708, 5710; el CABLE 5702; receptor de la línea del receptor (RXRCVR) con receptores 5722, 5724; y el receptor XOR lógico (RXXOR) . El Delayl 5732a debe corresponder con o exceder el retardo de la compuerta 5736 XOR en la fase RXXOR que se determina mediante la relación: pD - min (Delay 1) = tpD-max {XOR) Es deseable cumplir con este requerimiento para que la entrada D del circuito 5728, 5732 basculante receptor no cambie antes de su entrada de medir el tiempo. Esto es válido si el tiempo de ocupación de RXFF es igual a cero. El propósito o función del Delay2 es compensar el tiempo de ocupación del circuito basculante RXFF de acuerdo con la relación: tpo - min (Delay 2) = t__ (RXFP) En muchos sistemas esto será cero debido a que el tiempo de ocupación es cero, y por supuesto en ese caso el retardo máximo del Delay2 puede también ser cero. El peor caso de contribución para el sesgo en la fase XOR del receptor es en el caso de datos retardados/estroboscopio anticipado en donde el Delayl está en un valor máximo y la salida del medir el tiempo de la compuerta XOR llega tan anticipado como sea posible de acuerdo con la relación: tsKEW-max (RXXOR) ~ tpp-max {.Delay 1) ~ tpD-min ( 0 ) En esta situación, los datos pueden cambiar entre dos periodos de bit, n y n+1, muy cerca del tiempo donde el bit n+1 es medir el tiempo dentro del circuito basculante del receptor. La velocidad de datos máxima (periodo de bit mínimo) de un enlace MDDI Tipo 1 es una función del sesgo máximo que se encuentra a través de todos los manej adores, el cable, y los receptores en el enlace MDDI más la actualización total de los datos en la fase RXFF. El sesgo de retardo total en el enlace hasta la salida de la fase RXRCVR puede expresarse como: tsícEI.-max(J_INr.) = ts? -max(TXFF) + ts?_W-max(3XDJ.VR) + ts?EW-raax(CñBLE) + S?EW -max (RXRCVR) y el periodo de bit mínimo está proporcionado por: *_Ur-m__ = tSKEW-em'mK) + ¿ ' ÍB-TP4 + i??yrnnett *tSKEW-ttm{RXXOR) ^^Itle -hoil + t PD-rpsxfd y ) + ÍSU(.RXFF) En el ejemplo mostrado en la FIGURA 57 para el modo externo, tSKEw-max(L__??) = 1000 psec . , y el periodo de bit mínimo puede ^ expresarse como: tsxr-min = 1000 + 2*125 + 625 + 125 + 200 + 0 100= 2300 pseg, o establecido como aproximadamente 434 Mbps.

B. Análisis de Cronometraje de Enlace para MDDI Tipo 2, 3 y 4 Un circuito de ínterfaz típico similar al que se muestra en las FIGURAS 41 y 57, se muestra en la FIGURA 59 para ajustar enlaces de interfaz Tipo 2, III y IV. Los elementos adicionales se utilizan en las fases TXFF (5904) , TXDRVR (5908), RXRCVCR (5922), y RXFF (5932, 5928, 5930) puede ajustar el procesamiento de señal adicional. En la FIGURA 59, los valores ejemplares o típicos para el retardo y sesgo de propagación se muestran para cada una de las diversas fases de procesamiento o interfaz de un enlace sin retorno MDDI Tipo 2. Además del sesgo en el retardo entre MDDI_Stb y MDDI_Data0 que afecta el ciclo de trabajo de medir el tiempo de salida, también existe un sesgo entre estas dos señales y las otras señales MDDI_Data. Los datos en la entrada D de la fase del circuito basculante B del receptor (RXFFB) consiste de los circuitos 5928 y 5930 basculantes, se cambia ligeramente después del borde de medir el tiempo para que puedan muestrearse confiablemente. Si MDDI_Datal llega antes que MDDI_Stb o MDDI_Data0 entonces MDDI_Datal debiera retardarse para muestrearse mediante al menos la cantidad del sesgo de retardo. Para lograr esto, los datos se retardan utilizando la línea de retardo de Delay3. Si MDDI_Datal llega más tarde que MDDI_Stb y MDDI_DataO y también se retarda mediante el Delay3 entonces el punto en el que MDDI_Datal cambia se mueve más cerca del siguiente borde de medir el tiempo. 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 cronometraje o sesgo de las dos señales de datos y MDDI_Stb una con respecto a la otra se ilustra en las FIGURAS 60A, 60B y 60C. Para muestrear los datos confiablemente en RXFFB cuando MDDI_DataX llega tan anticipado como sea posible, Delay3 se establece de acuerdo con la siguiente relación: tpD-min (Delay3 ) = tsKEW-taax (LINK) + tH( FFB) + La rapidez de enlace máximo se determina mediante el periodo de bit permisible mínimo. Esto en su mayoría se ve afectado cuando MDDI_DataX llega tan retardado como sea posible. En ese caso, el tiempo de ciclo mínimo permisible se proporciona mediante: tB-T-min = tsKEW-max (LINK) + tpD-__ax(Delay3) + tSu(RXFFB) ~ tpD-min (XOR) El límite superior de la rapidez de enlace es entonces : tpD-max(Delay3) ~ tpD-min (Delay3) y proporciona esa suposición: tBIT-min (lower-bound) = 2 ts?EW-max (LINK) + tp -max(XOR) + tSu(RXFFB) + tH(RXFFB) En el ejemplo dado anteriormente, el límite inferior del periodo de bit mínimo se proporciona mediante la relación: Bjr-min(iot.er-£>ound) = 2 • (1000+2 «125+625+200) +1500+100+0=5750 pseg. , lo cual es aproximadamente 174 Mbps. Esto es mucho más lento que la velocidad de datos máxima que puede utilizarse con un enlace Tipo 1. La capacidad de compensación del sesgo de retardo automático de MDDI significativamente reduce la afectación que el sesgo de retardo tiene sobre el factor de la velocidad máxima de enlace está apenas en el borde del establecimiento de datos válido. El sesgo calibrado entre MDDI_DataO y MDDI_Stb es: y el periodo de bit mínimo es : rr-pia-Calibrale ~ + *SU(SX¡ En el ejemplo mostrado en la Figura 8-5, Tskwe- max(DataO-Stb-Calibrated) = 300 pseg y el periodo de bit mínimo es : -n?l-c«/¿_r_r rf == 300 + 2.125 + 625 +200+175 - lOO =: 1650 secJ de aproximadamente 606 Mbps. Para muestrear confiablemente los datos en RXFFB cuando MDDI_Datal arriba tan pronto como sea posible, el retraso programable asociado se ajusta en la configuración óptima con una precisión de una derivación, y un retraso de derivación adicional se agrega por seguridad. La velocidad máxima del enlace se determina mediante el periodo de bit mínimo permisible. Esto está mayoritariamente afectado cuando MDDI_Datal arriba tan tarde como sea posible . En ese caso, el tiempo de ciclo mínimo permisible es: tjlIT-ti?a-Datal-Calibrated ~ *• ' En el ejemplo dado en la Figura 8-5, el límite inferior del periodo de bit mínimo basado en el muestreo MDDI Datal es: tm-t?i-Datal-Calibrated = 2-150+2-125 = 55 pSQC XIV. Descripción de la Interconexión de la Capa Física Las conexiones físicas útiles para implementar una interfaz de acuerdo con la presente invención pueden realizarse utilizando partes comercialmente disponibles tales como la parte número 3260-8S2 (01) que fabrica Hirose Electric Company Ltd. en el lado del anfitrión, y la parte número 3240-8P-C que fabrica Hirose Electric Company Ltd. en el lado del dispositivo de cliente. Una asignación ejemplar de los contactos de la interfaz o "mapa de contacto" para tales conectores se utiliza con las interfaces Tipo I/Tipo 2 que se listan en la Tabla XIII, y se ilustra en la FIGURA 61.

Tabla XIII El protector se conecta a la H0ST_Gnd en la interfaz del anfitrión, y un hilo de drenado protector en el cable se conecta al protector del conector del cliente.

Sin embargo, el protector y el hilo de drenado no se conectan al interior del circuito a tierra de un cliente. Los elementos o dispositivos de interconexión se eligen o diseñan para ser lo suficientemente pequeños para utilizarlos con dispositivos de comunicación y cómputo móviles, tales como los PDA y teléfonos inalámbricos, o dispositivos para juegos portátiles, sin que sean molestos o antiestéticos en comparación con el tamaño relativo del dispositivo. Cualesquier conectores y cableados deben ser lo suficientemente durables para utilizarlos en un ambiente típico del consumidor y permitir un tamaño pequeño, especialmente para el cableado, y deben ser de un costo relativamente bajo. Los elementos de transferencia deben alojar las señales de datos y estroboscópicas que son datos NRZ diferenciales que tienen una velocidad de transferencia de hasta aproximadamente 450 Mbps para el Tipo 1 y el Tipo 2 y de hasta 3.6 Gbps para la versión Tipo 4 de 8 bits en paralelo. Para las aplicaciones de modo interno no existen conectores en el mismo sentido que para los conductores que se utilizan o tales elementos de conexión tienden a miniaturizarse mucho. Un ejemplo son los "enchufes hembra" de cero fuerza de inserción para recibir circuitos integrados o elementos que alojan ya sean el dispositivo del anfitrión o del cliente. Otro ejemplo es en donde el anfitrión y el cliente residen en tarjetas de circuitos impresos con varios conductores que se interconectan, y que tienen "patitas" o contactos que se extienden desde los alojamientos que se sueldan a contactos en los conductores para su interconexión con los circuitos integrados .

XV. Operación En las FIGURAS 54A y 54B se muestra un resumen de las etapas generales que se llevan a cabo en el procesamiento de datos y paquetes durante la operación de una interfaz que utiliza modalidades de la invención, junto con una vista general del procesamiento de paquetes del aparato de interfaz en la FIGURA 55. En estas figuras, el proceso arranca en una etapa 5402 con una determinación en cuanto a si el cliente y el anfitrión están o no conectados utilizando una trayectoria de comunicación, que en este caso es un cable. Esto puede ocurrir a través del uso periódico de consultas mediante el anfitrión, utilizando un software o un hardware que detecta la presencia de conectores o cables o señales en las entradas del anfitrión (tal como se ve para interfaces USB) , u otras técnicas conocidas. Si no existe ningún cliente conectado al anfitrión, entonces simplemente se ingresa a un estado de espera por alguna longitud predeterminada, dependiendo de la aplicación, que se dirige hacia un modo de hibernación, o que se inactiva para esperar una utilización futura que podría requerir que un usuario realizara alguna acción para reactivar al anfitrión. Por ejemplo, cuando un anfitrión reside en un dispositivo tipo computadora, un usuario podría dar un clic en un icono de la pantalla o solicitarle a un programa que active el procesamiento del anfitrión para buscar al cliente. De nuevo, un simple enchufe macho en una conexión tipo USB podría activar el procesamiento del anfitrión, dependiendo de las funciones y la configuración del anfitrión o el software del anfitrión residente . Una vez que un cliente se conecta al anfitrión, o viceversa, o se detecta que está presente, ya sea el cliente o el anfitrión envía paquetes apropiados solicitando el servicio en las etapas 5404 y 5406. El cliente podría enviar ya sea paquetes de Solicitud o Estado de Servicio al Cliente en la etapa 5404. Se hace notar que el enlace, como se discutió anteriormente, podría haberse cerrado previamente o podría estar en el modo de hibernación, así que ésta podría no ser una inicialización completa del enlace de comunicación que sigue. Una vez que el enlace de comunicación se sincroniza y el anfitrión está tratando de comunicarse con el cliente, el cliente también proporciona un paquete de Funciones del Cliente al anfitrión, como en la etapa 5408. El anfitrión puede ahora comenzar a determinar el tipo de soporte, incluyendo las velocidades de transferencia, que el cliente puede ajustar. Generalmente, el anfitrión y el cliente también negocian el tipo (velocidad/rapidez) de modo de servicio que se va a utilizar, por ejemplo Tipo 1, Tipo 2, etc., en una etapa 5410. Una vez que el tipo de servicio se establece, el anfitrión puede comenzar a transferir información. Además, el anfitrión puede utilizar Paquetes de Medición de Retardo de Ida y Vuelta para optimizar el cronometraje de los enlaces de comunicación en paralelo con otro procesamiento de señal, como se muestra en la etapa 5411. Como se estableció anteriormente, todas las transferencias comienzan con un Paquete de Encabezamiento de Sub-Trama, que se muestra que está siendo transferido en la etapa 5412, seguido por el tipo de datos, que aquí son paquetes de corriente de audio y vídeo, y paquetes de relleno, que se muestra que están siendo transferidos en la etapa 5414. Los datos de audio y vídeo se habrán previamente preparado o mapeado dentro de paquetes, y paquetes rellenadores se insertan según sea necesario o deseado para llenar un número requerido de bits para las tramas de los medios. El anfitrión puede enviar los paquetes de modo que los Paquetes de Habilitación del Canal de Audio Sin Retorno activen los dispositivos de sonido. Además, el anfitrión puede transmitir comandos e información que utilizan otros tipos de paquetes que se discutieron anteriormente, que aquí se muestran como la transferencia del Mapa de Color, Transferencia de Bloque de Bits u otros paquetes en la etapa 5416. Además, el anfitrión y el cliente pueden intercambiar datos que se relacionan con un teclado o dispositivos de señalamiento que utilizan los paquetes apropiados. Durante la operación, puede ocurrir uno de varios eventos diferentes que conducen a que el anfitrión o el cliente desee una velocidad de datos o tipo de modo de interfaz diferentes. Por ejemplo, una computadora u otro dispositivo de comunicación de datos podrían encontrase con condiciones de carga en los datos de procesamiento que provoca una baja de velocidad en la preparación o la presentación de los paquetes. Un dispositivo de cliente que recibe los datos podría cambiar de una fuente de energía eléctrica de CA dedicada a una fuente de energía eléctrica de batería más limitada, y tampoco estaría en posibilidad de transferir datos tan rápidamente, procesar comandos con facilidad, ni estaría en posibilidad de utilizar el mismo grado de resolución o profundidad de color bajo los ajustes de energía eléctrica más limitados. Alternativamente, una condición restrictiva podría abatirse o desaparecer permitiendo a cualquier dispositivo transferir datos a velocidades más elevadas. Ya que esto es más deseable, puede hacerse una solicitud para cambiar a un modo de velocidad de transferencia más elevado. Si estos u otros tipos de condiciones conocidas ocurren o cambian, ya sea que el anfitrión o el cliente puedan detectarlas y traten de renegociar el modo de interfaz. Esto se muestra en la etapa 5420, donde el anfitrión envía Paquetes de Solicitud de Transferencia Intracelular Tipo Interfaz al cliente solicitando una transferencia intracelular a otro modo, el cliente envía los Paquetes de Reconocimiento de Tipo de Interfaz que confirman un cambio que se está buscando, y el anfitrión envía los Paquetes de Transferencia Intracelular Tipo Ejecución para hacer el cambio hacia el modo especificado. A pesar de que, no se requiere un orden de procesamiento en particular, el cliente y el anfitrión pueden también intercambiar paquetes que se relacionan con los datos que están destinados para o que se reciben desde los dispositivos de señalamiento, teclados, u otro tipo de dispositivos de entrada del usuario asociados principalmente con el cliente, aunque tales elementos podrían también estar presentes en el lado del anfitrión.

Estos paquetes típicamente se procesan utilizando un elemento tipo procesador general y no la máquina de estado (5502) . Además, algunos de los comandos anteriormente discutidos también serán procesados por el procesador general. (5504, 5508) Después de que se han intercambiado los datos y los comandos entre el anfitrión y el cliente, en algún punto se toma una decisión en cuanto a si se van a transmitir o no datos adicionales o si el anfitrión o el cliente van a dejar de dar servicio de transferencia. Esto se muestra en la etapa 5422. Si el enlace va a entrar ya sea a un estado de hibernación o va a ser cerrado completamente, el anfitrión envía un paquete de Interrupción de Enlace al cliente, y ambos lados terminan la transferencia de datos . Los paquetes que se transfieren en el procesamiento de las operaciones anteriores se transferirán utilizando los manejadores y los receptores previamente discutidos con relación a los controladores del anfitrión y el cliente. Estos manej adores en línea y otros elementos lógicos se conectan a la máquina de estado y a los procesadores generales anteriormente discutidos, como se ilustra en la vista general de la FIGURA 55. En la Figura 55, una máquina 5502 de estado y los procesadores 5504 y 5508 generales pueden conectarse adicionalmente a otros elementos que no se muestran tales como una interfaz USB dedicada, elementos de memoria u otros componentes que residen afuera del controlador de enlace con los cuales interactúa, que incluyen, pero no se limitan a, la fuente de datos, y chips para control de vídeo para ver los dispositivos de despliegue. Los procesadores, y la máquina de estado proporcionan un control a través de la habilitación y deshabilitación de los manej adores como se discutió anteriormente con relación a los tiempos de guarda, etcétera, para asegurar un establecimiento o finalización eficiente del enlace de comunicación, y la transferencia de paquetes .

XVI Memorias Intermedias de Trama de Despliegue Los requerimientos de almacenamiento intermedio de los datos de vídeo son diferentes para imágenes de vídeo en movimiento comparadas con los gráficos para computadora. Los datos de píxel en su mayoría se almacenan a menudo en una memoria intermedia de trama local en el cliente de modo que la imagen en el cliente puede renovarse localmente. Cuando se está desplegando un vídeo de movimiento total (casi cualquier píxel en el despliegue cambia cada Trama de los Medios) usualmente se prefiere almacenar los datos de Píxel entrante en una memoria intermedia de trama mientras que la imagen en el despliegue está siendo renovada desde una segunda memoria intermedia de trama. Pueden utilizarse más de dos memorias intermedias del despliegue para eliminar artefactos visibles como se describe a continuación. Cuando una imagen entera se ha recibido en una memoria intermedia de trama, entonces el papel de las memorias intermedias puede permutarse, y la imagen recién recibida se utiliza entonces para renovar el despliegue y la otra memoria intermedia se rellena con la siguiente trama de la imagen. Este concepto se ilustra en la FIGURA 91A, en donde los datos de píxel, se escriben en la memoria intermedia de imagen fuera de línea al ajustar los bits de Actualización de Despliegue en '01' . En otras aplicaciones el anfitrión necesita actualizar solamente una pequeña porción de la imagen sin tener que volver a pintar toda la imagen. En esta situación se desea escribir los nuevos píxeles directamente en la memoria intermedia que se está utilizando para renovar el despliegue, como se ilustra con detalle en la FIGURA 91B. En aplicaciones que tienen una imagen fija con una ventana de vídeo pequeña es más fácil escribir la imagen fija para ambas memorias intermedias (bits de actualización de despliegue iguales en "11") como se muestra en la FIGURA 91C, y subsecuentemente escribe los píxeles de la imagen en movimiento en la memoria intermedia fuera de línea al ajustar los bits de actualización de despliegue en '01'. Las siguientes reglas describen la manipulación útil de los señaladores de la memoria intermedia mientras simultáneamente escriben información nueva para el cliente y para renovar el despliegue. Existen tres señaladores de memoria intermedia: puntos current_fill para la memoria intermedia que actualmente está siendo llenada desde los datos a través del enlace MDDI. Puntos just_filled para la memoria intermedia que fue casi recientemente rellenada. Puntos being_displayed para la memoria intermedia que se está utilizando actualmente para renovar el despliegue. Todos los tres señaladores de memoria intermedia pueden contener valores desde 0 hasta N-l donde N es el número de memorias intermedias del despliegue, y N _> 2. La aritmética en los señaladores de memoria intermedia es modificar N, por ejemplo cuando N=3 y current_fill=2, incrementar current_fill provoca que current_fill se establezca en 0. En el caso simple donde N=2, just_filled siempre se complementa con current_fill . En cada límite de trama de Medios MDDI (Paquete de Encabezamiento de Sub-trama con el campo de Conteo de Sub-trama igual a cero) llevar a cabo las siguientes operaciones en el orden especificado: establecer just_filled igual a current_fill, y establecer current fill igual a current fill + 1.

Los Paquetes de Corriente de Vídeo MDDI actualizan las memorias intermedias de acuerdo con la estructura o metodología de : cuando los Bits de Actualización de Despliegue son igual a '01', los datos de píxel se escriben en la memoria intermedia especificada por current_fill ; cuando los Bits de Actualización de Despliegue son igual a '00', los datos de píxel se escriben en la memoria intermedia especificada por just_filled, y cuando los Bits de Actualización de Despliegue son iguales a '11', los datos de píxel se escriben en todas la memorias intermedias. El despliegue se renueva desde la memoria intermedia especificada por el señalador being_displayed. Después de que el despliegue renueva el último píxel en una época de renovación de trama y antes de que comience a renovar el primer píxel en la siguiente época de renovación de trama el proceso de actualización de despliegue lleva a cabo la operación de ajustar being_refreshed igual a just_filled; El Paquete de Corriente de Vídeo contiene un par de Bits de Actualización de Despliegue que especifican la memoria intermedia de trama donde los datos de píxel se van a escribir. El Paquete de Capacidad del Cliente tiene tres bits adicionales que indican que combinaciones de los Bits de Actualización de Despliegue están soportadas en el cliente. En muchos casos, las imágenes generadas por computadora necesitan actualizarse de modo gradual con base en el ingreso de datos del usuario o derivado de la información recibida desde la red de cómputo. Las combinaciones de Bits de Actualización de Despliegue '00' y "ii" soportan este modo de operación al provocar que los datos de píxel se escriban en la memoria intermedia de trama que está siendo desplegado o en ambas memorias intermedias de trama. Cuando se da acomodo a las imágenes de vídeo, la FIGURA 92 ilustra como se despliegan las imágenes de vídeo utilizando un par de memorias intermedias de trama cuando los datos de vídeo se transmiten a través del enlace MDDI con los Bits de Actualización de Despliegue iguales a '01'. Después de que se detecta un límite de trama de medios en el enlace de MDDI, el proceso de renovación de despliegue comenzará a renovar a partir de la siguiente memoria intermedia de trama cuando el proceso de renovación para la trama que actualmente se está renovando se haya completado . Una suposición importante que se relaciona con la FIGURA 92 es que la imagen se recibe desde el anfitrión como una corriente continua de píxeles que se transmiten en el mismo orden que el cliente utiliza para leer los píxeles de la memoria intermedia de trama para renovar el despliegue (usualmente superior izquierda, leyendo fila por fila, hasta la esquina inferior derecha de la pantalla.

Este es un detalle importante en los casos en que las operaciones Renovar Despliegue y Transferir Imagen hacen referencia a la misma memoria intermedia de trama. Es necesario que la velocidad de renovación de trama de despliegue sea mayor que la velocidad de transferencia de trama de imagen para evitar • el despliegue parcial de imágenes . La FIGURA 93 muestra cómo puede ocurrir la fragmentación de imagen con una velocidad de renovación de despliegue lenta, es decir la renovación de despliegue es más lenta que la transferencia de imagen. En una imagen que contiene una combinación de imágenes gráficas por computadora y películas de vídeo en movimiento los datos de píxel del vídeo podrían ocupar una pequeña porción de una trama de medios . Esto podría ser ' importante en situaciones en las que la operación de renovación del despliegue y la transferencia de imagen hacen referencia a la misma memoria intermedia de trama. Estas situaciones se muestran mediante un sombreado cuadriculado en la FIGURA 94, donde los píxeles leídos desde la memoria intermedia para renovar el despliegue podrían ser los píxeles escritos en la memoria intermedia de dos tramas anteriores, o podrían corresponder a la trama que sé está escribiendo inmediatamente en la misma memoria intermedia de trama. El uso de tres memorias intermedias de trama en el cliente resolverá el problema de la ventana de contención pequeña para tener acceso a una memoria intermedia de trama como se muestra en la FIGURA 95. Sin embargo, existe aún un problema si la velocidad de renovación de despliegue es menor a la velocidad de la trama de medios a través del enlace MDDI, como se muestra en la FIGURA 96. El uso de una sola memoria intermedia para imágenes de vídeo en movimiento es un tanto problemático como se muestra en la FIGURA 97. Cuando la renovación del despliegue es más rápida que la transferencia de la imagen dentro de la memoria intermedia, la imagen que está renovándose algunas veces puede mostrar la porción superior de la trama que se está escribiendo y la porción inferior de la imagen será la de la trama previamente transferida. Cuando la renovación del despliegue es más rápida que la transferencia de imagen (el modo preferido de operación) existirán casos más frecuentes de tramas que muestran una división de imagen similar.

XVII. Tabla de Valor de Retardo El Paquete de Parámetros de Retardo del Procesamiento de Paquete utiliza una capacidad de búsqueda en tabla para calcular el retardo predicho para procesar ciertos comandos en el cliente. Los valores en la tabla se incrementan de una manera logarítmica para proporcionar un rango dinámico muy amplio de los valores de retardo. Una tabla ejemplar de los valores de retardo útil para implementar las modalidades de la invención se encuentra en la Tabla XX a continuación, con los valores de índice correspondientes confrontados con los valores de retardo.

Tabla XX 0-no_delay 37-1.5ns 74-51ns 111 - 1.8us 148 - 62us 185 - 2.2ms 222-75_ns 1 - 46ps 38 - l.dns 75 - 56ns 112-2.0us 149 - 68us 186-2.4ms 223 - 83ms 2-5.ps 39 - 1.8ps 76 - 62ns 113-2.2us 150-75us 187-2.6?rts 224-91ms 3 - 56ps 40 - 2.0ps 77 - 68ns 114-2.4us 151 - 83us 188-2.9ms 225 - lOOms 4 - 62?s 41 - 2.2ns 78-75ns 115-2.6us 152-91us 189 - 3.2ms 226-110ms 5 - 68ps 42-2.4ns 79 - 83ns H6-2.9us 153 - lOOus 190 - 3.5p?s 227 - 120ms 6 - 75ps 43 - 2.6ps 80-91ps 117 - 3.2us 154-UOus 191 - 3.8ms 228 - 130ms 7 - 83ps 44-2.9ns 81 - lOOns 118-3.5us 155 - 120us 192-4.2ms 229 - 150ms 8-91ps 45 - 3.2ns 82-110ns 119 - 3.8us 156 - 130us 193-4.6ms 230 - 160ms 9 - lOOps 46 - 3.5ns 83 - 120ns 120-4.2us 157 - 150us 194-5.1 s 231 - 180?ns 10-110ps 47-3.8ns 84-130ns 121-4.6us 158 - 160us 195 - 5.6ms 232-200ms 11 - 120ps 48 - 4.2ns 85 - 150ps 122-5.1us 159 - 180us 196 - 6.2ms 233 - 220ms 12-130ps 49 - 4.6ns 86 - 160ns 123 - 5.6us 160 - 200us 197 - 6.8ms 234-240ras 13 - 150ps 50-5.1ns 87-180ns 124-6.2us 161 - 220us 198-7.5ms 235 - 260ras 14 - 160ps 51 - 5.6ns 88-200ns 125 - 6.8us 162 - 240us 199 - 8.3ms 236 - 290ms 15-180ps 52 - 6.2ps 89 -220-s 126-7.5us 163-260us 200-9.1ms 237 - 320ras 16 - 200ps 53 - 6.8ns 90 - 240r_5 127 - 8.3us 164-290us 201 - lOms 238 - 350ms 17-220ps 54-7.5ns 91 - 260ns 128-9.1us 165 - 320us 202 - llms 239 - 380ms 18 - 240ps 55 - 8.3ns 92-290ns 129-lOus 166-350us 203 - 12ms 240 - 420ms 19 - 260ps 56-9.1ps 93 - 320ns 130-llus 167 - 380us 204 - 13ms 241 - 460ms 20 - 290ps 57-10ns 94-350ns 131 - 12us 168 - 420us 205 - 15ms 242-510ms 21 - 320ps 58 - llps 95 - 380ps 132-13us 169-460us 206 - 16ms 243 - 560r_s 22-350ps 59 - 12ns 96 - 420ns 133 - 15us 170 - 510us 207 - 18ms 244-620_as 23 - 380?s 60 - 13ns 97 - 460ps 134 - 16us 171-560us 208 - 20ms 245 - 680ms 24-420ps 61 - 15ns 98-510ns 135 - ldus 172 - 620us 209 - 22m_ 246 - 750ms 25 - 460ps 62 - 16ns 99 - 560ns 136 - 20us 173 - 680us 210-24m_ 247 - 830ms 26 - SlOps 63 - 18ns 100 - 620ps í37-22us 174-750us 211-26ms 248 - 910ms 27 - 560ps 64 - 20ns 101 - 680ps 138 - 24us 175 - 830us 212-29ms 249 - l.Osec 28 - 620ps 65 - 22ps 102-750ps 139-26us 176-910us 213 - 32ms 250 - l.lsec 29 - 680ps 66-24ns 103 - 830ns 140-29us 177 - l.Oms 214 - 35ms 251 - 1.2sec 30 - 750ps 67 - 26ns 104-910ns 141 - 32us 178 - l.lms 215-38m_ 252 - 1.3sec 31 - 830ps 68-29ns 105-l.Ous 142-35us 179 - 1.2ms 216 - 42ms 253 - 1.5sec 32-910ps 69 - 32ns 106-l.lus 143 - 38us 180 - 1.3ms 217-46ms 254-1.6s 33 - l.Ons 70-35ns 107 - 1.2us 144-42us 181 - 1.5ms 218-51ms 255 - indefinido 34-l.lns 71 - 38ps 108 - 1.3us 145-46us 182-1.6ms 219 - 56ms 35 - 1.2ns 72-42ns 109-1.5us 146-51us 183 - 1.8ms 220 - 62ms 36-1.3ns 73 - 46ns 110-1.6us 147 - 56us 184 - 2.0 s 221 - 68ms El retardo se calcula al ejecutar una búsqueda en tabla utilizando el parámetro especificado como un índice dentro de la tabla. Esto significa que un retardo es igual al PacketProcesingTable (index) . Por ejemplo: si uno de los parámetros del Elemento de la Lista de Parámetros de Retardo es un valor de 8 bits igual a 134, entonces el retardo es igual a PacketProcesingTable (134) que es de 16 µseg. El valor 255 indica que el tiempo de finalización del comando no puede determinarse por cálculo, y que el anfitrión verificará los indicadores de Ocupado de Gráficos en la Solicitud de Cliente y el Paquete de Estado o el Parámetro B7h de Control MCCS VCP. En algunos casos este retardo se multiplica por la altura, el ancho o el número de píxeles en la imagen de destino y se agregan a otros retardos para calcular el retardo global del procesamiento de paquete .

XVIII. Soporte Múltiple del Cliente La versión del protocolo actual no parece soportar directamente múltiples dispositivos del cliente. Sin embargo, la mayoría de los paquetes contienen un campo reservado para la ID de Cliente que puede utilizarse para direccionar dispositivos específicos del cliente en un sistema con múltiples clientes. En la actualidad, para muchas aplicaciones esta ID de cliente o estas ID de clientes se establecen en cero. El paquete de encabezamiento de sub-trama también contiene un campo para indicar si el anfitrión soporta o no un sistema de múltiples clientes. Por lo tanto, existe una manera en la cual múltiples dispositivos de cliente podrían probablemente conectarse y direccionarse en futuras aplicaciones de la interfaz o protocolo MDD para ayudar a los diseñadores del sistema a planear una compatibilidad futura con múltiples anfitriones y clientes. En sistemas que tienen múltiples clientes es útil para los clientes conectarse al anfitrión utilizando una conexión en cadena de clientes, o utilizar centros nodales, como se muestra en la Figura 98, o utilizar una combinación de estas técnicas como se muestra en la FIGURA 99.

XIX. Apéndice Además de los formatos, estructuras y contenidos discutidos anteriormente para los diversos paquetes utilizados para implementar la arquitectura y el protocolo de las modalidades de la invención, se presentan aquí contenidos u operaciones de campo más detalladas para algunos de los tipos de paquete. Estos se presentan aquí para clarificar aún más su uso respectivo o sus operaciones para posibilitar que quienes tienen experiencia en la técnica comprendan más fácilmente y hagan uso de la invención para una variedad de aplicaciones. Solamente unos cuantos de los campos que no se han discutido ya se discuten adicionalmente aquí. Además, estos campos se presentan con definiciones y valores ejemplares con relación a las modalidades presentadas anteriormente. Sin embargo, tales valores no se deben considerar como limitaciones de la invención, sino que representan una o más modalidades útiles para implementar la interfaz y el protocolo, y no todas las modalidades necesitan practicarse en forma conjunta o al mismo tiempo. Pueden utilizarse otros valores en otras modalidades para lograr la presentación de datos deseada o los resultados de transferencia de velocidad de datos como lo entenderán quienes tienen experiencia en la técnica.

A. Para Paquetes de Corriente de Vídeo En una modalidad, el campo de Atributos de los Datos de Píxel (2 bytes) tiene una serie de valores de bit que se interpretan de la siguiente manera. Los bits 1 y 0 seleccionan cómo se enrutan los datos de píxel del despliegue. Para valores de bit de '11' los datos se despliegan en o para ambos ojos, para valores de bits '10', los datos se enrutan solamente al ojo izquierdo, y para valores de bit de '01', los datos se enrutan solamente al ojo derecho, y para valores de bits de '00' los datos se enrutan para un despliegue alterno como puede especificarse mediante los bits 8 a 11 anteriormente discutidos.

El Bit 2 indica si los Datos de Píxel se presentan o no en un formato de entrelazado, con un valor de '0' que significa que los datos de píxel están en el formato progresivo estándar, y que el número de fila (coordenada Y de píxel) se incrementa por uno cuando se avanza de una fila a la siguiente. Cuando este bit tiene un valor de '1', 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 el formato de píxel alterno. Este es similar al modo entrelazado estándar habilitado por el bit 2 , pero el entrelazado es vertical en vez de horizontal. Cuando el Bit 3 es O' los Datos de Píxel están en el formato progresivo estándar, y el número de columna (coordenada X de píxel) se incrementa por 1 conforme cada píxel sucesivo se recibe. Cuando el Bit 3 es '1' 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 cada píxel se recibe. El Bit 4 indica si los Datos de Píxel se relacionan o no con un despliegue o una cámara, como si fueran los datos que se están transfiriendo hacia o desde un despliegue interno para un teléfono inalámbrico o un dispositivo similar o incluso una • computadora portátil, o algunos otros dispositivos como los anteriormente discutidos, o los datos que se están transfiriendo hacia o desde una cámara integrada o directamente acoplada al dispositivo. Cuando el Bit 4 es '0' los datos de Píxel se están transfiriendo hacia o desde una memoria intermedia de despliegue. Cuando el Bit 4 es '1' se están transfiriendo hacia y desde una cámara o dispositivo de vídeo de algún tipo, tales dispositivos son bien conocidos en la técnica. El Bit 5 se utiliza para indicar cuándo los datos de píxel contienen la siguiente fila consecutiva de píxeles en el despliegue. Esto se considera en el caso en el que el Bit 5 se establece igual a '1' . Cuando el bit 5 se establece en '1' entonces los parámetros Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, Arranque X y Arranque Y no están definidos y son ignorados por el cliente. Cuando el Bit 15 se establece en un nivel de uno lógico, esto indica que los datos de píxel en este paquete son la última 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 ésta característica está soportada. Los Bits 7 y 6 son Bits de Actualización del Despliegue que especifican una memoria intermedia de trama en donde los datos de píxel se van a escribir. Los efectos más específicos se discuten en otra parte. Para los valores de bit de '01' los datos de Píxel se escriben en la memoria intermedia de la imagen fuera de línea. Para los valores de bit de '00' los datos de Píxel se escriben en la memoria intermedia de imagen utilizada para renovar el despliegue. Para los valores de bit de '11' los datos de Píxel se escriben en todas las memorias intermedias de imagen. Los valores de bit o la combinación de ?10' se tratan como un valor o designación inválidos y los datos de Píxel se ignoran y no se escriben en ninguna de las memorias intermedias de imagen. Este valor puede tener un uso para aplicaciones futuras de la interfaz. Los Bits 8 a 11 forman un número entero sin signo de 4 bits que especifica una ubicación de despliegue o de despliegue alterna cuando los datos de píxel se van a enrutar. Los Bits 0 y 1 se establecen iguales a '00' para que el despliegue del cliente interprete los bits 8 a 11 como un número de despliegue alterno. Si los bits 0 y 1 no son iguales a '00' entonces los bits 8 a 11 se establecen en niveles de cero lógico. Los Bits 12 a 14 se reservan para un uso futuro y generalmente se establecen en niveles de cero lógico. El Bit 15, como se discutió, se utiliza junto con el bit 5, y al ajustar el bit 15 a uno lógico se indica que la fila de píxeles en el campo de Datos de Píxel es la última fila de píxeles en una trama de datos . El siguiente Paquete de Corriente de Vídeo que tiene el bit 5 establecido en uno lógico corresponderá a la primera fila de píxeles de la siguiente trama de vídeo. Los campos de Arranque X y Arranque Y de 2 bytes especifican las coordenadas X e Y absolutas del punto (Arranque X, Arranque 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 la pantalla rellenada con el ' campo de Datos de Píxel, mientras que los campos de Borde Derecho X y Borde Inferior Y especifican la coordenada X en el borde derecho, y la coordenada Y en el borde inferior de la ventana que se está actualizando. El campo de Conteo de Píxel (2 bytes) especifica el número de píxeles en el campo de Datos de Píxel a continuación. El campo de Parámetro CRC (2 bytes) contiene una CRC de todos los bytes de la Longitud de Paquete al Conteo de Píxel. Si esta CRC falla al verificar entonces todo el paquete se descarta. El campo de Datos de Píxel contiene la información de vídeo en su estado primario que se va a desplegar, y la cual está formateada en la manera descrita por el campo de Descriptor de Formato de los Datos de Vídeo. Los datos se transmiten uno a la vez "en fila" como se discutió en otra parte. Cuando el Bit 5 del campo de Atributos de los Datos de Píxel se establece en un nivel de uno lógico, entonces el campo de Datos de Píxel contiene exactamente una fila de píxeles, con el primer siendo transmitido en correspondencia al píxel que se encuentra más a la izquierda y el último píxel transmitido corresponde al píxel que se encuentra más a la derecha. El campo de CRC de los Datos de Píxel (2 bytes) contiene una CRC de 16 bits de solamente los Datos de Píxel . Si una verificación de CRC de este valor falla entonces los Datos de Píxel pueden aún utilizarse, pero se incrementa el conteo de error de CRC.

B. Para Paquetes de Corriente de Audio En una modalidad, el campo de ID de Canal de Audio (1 byte) utiliza un valor de número entero sin signo de 8 bits para identificar un canal de audio en particular al cual se van a enviar los datos de audio mediante el dispositivo de cliente. Los canales de audio físicos se especifican o se mapean para canales físicos mediante este campo como valores de O, 1, 2, 3, 4, 5, 6 6 1 que indican canales frontal izquierdo, frontal derecho, posterior izquierdo, posterior derecho, central frontal, de sub-graves ( sub-woofer) , izquierdo envolvente y derecho envolvente, respectivamente. Un valor de ID de canal de audio de 254 indica que la única corriente de las muestras de audio digitales se envían tanto a los canales frontal izquierdo como frontal derecho. Esto simplifica las comunicaciones para las aplicaciones tales como donde se utiliza un microteléfono estéreo para comunicación de voz, aplicaciones de ' mejoramiento de productividad que se utilizan en un PDA, u otras aplicaciones donde una Interfaz de Usuario simple genera tonos de aviso. Los valores para el campo de ID que fluctúan desde 8 hasta 253, y 255 se reservan actualmente para utilizarlos donde nuevos diseños desean designaciones adicionales, como se anticipa por aquellos con experiencia en la técnica. El campo de Reservado 1 (1 byte) generalmente se reserva para un uso futuro, y todos los bits en este campo se establecen en cero. Una capacidad de este campo es provocar que todos los campos subsecuentes 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 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 Empaquetado contiene 1 byte que especifica el formato de empaquetamiento de datos de audio. En una modalidad, el formato generalmente empleado es para los Bits 4 a 0 para definir el número de bits por muestra de audio PCM. El Bit 5 entonces especifica si las muestras de Datos de Audio Digitales se empaquetan o no . Como se mencionó anteriormente, la FIGURA 12 ilustra la diferencia entre las muestras de audio empaquetadas y alineadas por byte. Un valor de '0 ' para el Bit 5 indica que cada muestra de audio PCM en el campo de Datos de Audio Digitales está alineada por bytes con el límite de byte de interfaz, y un valor de '1' indica que cada muestra de audio PCM sucesiva se empaqueta contra la muestra de audio previa. Este bit es efectivo solamente 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 utilizarlos donde los diseños de sistema desean designaciones adicionales y generalmente se establecen en un valor de cero. El campo de Velocidad de la Muestra de Audio (1 byte) especifica la velocidad de la muestra PCM de audio. El formato empleado es para un valor de 0 para indicar una velocidad de 8,000 muestras por segundo (sps), un valor de 1 indica 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, con valores de 9 a 255 siendo reservados para un uso futuro, así que actualmente se establecen en cero. El campo de Parámetro CRC (2 bytes) contiene una CRC de 16 bits de todos los bytes desde la Longitud de Paquete hasta la Velocidad de Muestra de Audio . Si esta CRC falla al verificar apropiadamente, entonces todo el paquete se descarta. El campo de Datos de Audio Digitales contiene las muestras de audio en su estado original que se van a reproducir, y usualmente está en forma de un formato lineal como números enteros sin signo. El campo de CRC de los datos de audio (2 bytes) contiene una CRC de 16 bits de solamente Datos de Audio. Si la CRC falla al verificar, entonces los Datos de Audio pueden aún utilizarse, pero se incrementa el conteo de error de 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. Los contenidos de los campos de Parámetros de Corriente y los Datos de Corriente, típicamente está definido por el fabricante del equipo MDDI . El campo de Parámetro CRC de la Corriente de 2 bytes contiene una CRC de 16 bits para todos los bytes de los parámetros de la corriente iniciando desde la Longitud de Paquete hasta el byte de Codificación de Audio. Si esta CRC falla al verificar, entonces todo el paquete se descarta. Ambos campos de Parámetro de Corriente y Parámetro .CRC de Corriente pueden descartarse si no son necesarios para una aplicación final de la interfaz MDD, es decir, se consideran opcionales. El campo de CRC de Datos de Corriente de 2. bytes contiene una CRC de solamente los Datos de Corriente. Si esta CRC falla al verificar apropiadamente, entonces el uso de los Datos de Corriente es opcional, dependiendo de los requerimientos de la aplicación. El uso del contingente de la corriente de datos en la CRC que es buena, generalmente requiere que los datos de corriente se almacenen en forma intermedia hasta que se confirma la CRC como siendo buena. El conteo de error de CRC se incrementa si la CRC no se verifica.

D. Para Paquetes de Mapa de Color El campo de ID del Cliente de 2 bytes contiene información o valores que se reservan para una ID de Cliente, como se utilizó previamente. Dado que este campo generalmente se reserva para un uso futuro, el valor actual se establece en cero, al ajustar los bits en '0'. El campo de Conteo de Elemento de Mapa de Color de 2 bytes utiliza valores para especificar el número total de elementos de mapa de color de 3 bytes que están contenidos en el campo de Datos de Mapa de Color, o las entradas de la tabla de mapa de color que existe 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 Elemento de Mapa de Color. El Conteo de Elemento de Mapa de Color se establece igual a cero para no enviar ningún dato del mapa de color. Si el Tamaño de Mapa de Color es cero entonces un valor de Desplazamiento de Mapa de Color generalmente se sigue enviando pero es ignorado por el despliegue. El campo de Desplazamiento del Mapa de Color (4 bytes) especifica el desplazamiento de los Datos de Mapa de Color en este paquete desde el inicio de la tabla del mapa de color en el dispositivo de cliente. Un campo de Parámetro CRC de 2 bytes contiene una CRC de todos los bytes desde la Longitud de Paquete hasta el byte de Codificación de Audio. Si esta CRC falla al verificar, entonces todo el paquete se descarta. Para el campo de Datos de Mapa de Color, el ancho de cada ubicación del mapa de color se especifica mediante el campo de Tamaño de Elemento de Mapa de Color, donde en una modalidad la primera parte especifica la magnitud del azul, la segunda parte especifica la magnitud del verde, y la tercera parte especifica la magnitud del rojo. El campo de Tamaño de Mapa de Color especifica el número de elementos de la tabla 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 puede ajustarse dentro de un Formato de Datos de Vídeo y Paquete de Mapa de Color, entonces todo el mapa de color puede especificarse al enviar paquetes múltiples con diferentes Datos de Mapa de Color y Desplazamientos del Mapa de Color en cada paquete . El número de bits para el azul, verde y rojo en cada elemento de datos de mapa de color generalmente es el mismo como se especifica en el campo de Ancho RGB del Mapa de Color del Paquete de Capacidad de Despliegue. Un campo de CRC de Datos de Mapa de Color de 2 bytes contiene una CRC de solamente los Datos de Mapa de Color. Si esta CRC falla al verificar, entonces los Datos de Mapa de Color pueden aún utilizarse aunque se incrementa el conteo de error de CRC. Cada elemento de datos de mapa de color se va a transmitir en el orden: azul, verde, rojo, con el bit menos significativo de cada componente transmitido primero. Los componentes individuales rojo, verde y azul de cada elemento de mapa de color se empaquetan, aunque cada elemento de mapa de color (el bit menos significativo del componente azul) debería alinearse por bytes. La Figura 100 ilustra un ejemplo de los elementos 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 Elemento de Mapa de Color en el Paquete de Mapa de Color es igual a 21, y el campo de Ancho RGB del Mapa de Color del Paquete de Capacidad del Cliente es igual a 0x0786.

E. Para Paquetes de Encapsulamiento de Enlace de Retorno El campo de Parámetro CRC (2 bytes) contiene una CRC de 16 bits de todos los bytes desde la Longitud de Paquete hasta la Longitud de Inversión de Sentido . Si esta CRC falla al verificar, entonces se descarta todo el paquete. En una modalidad, el campo de Indicadores del Enlace de Retorno (1 byte) contiene un conjunto de indicadores para solicitar información del cliente. Si un bit (por ejemplo, Bit 0) se establece en un nivel de uno lógico, entonces el anfitrión sólita la información especificada del despliegue utilizando el Paquete de Capacidad del Cliente. Si el bit se establece en un nivel de cero lógico, entonces el anfitrión no necesita la información del cliente. Los bits restantes (que aquí son los Bits 1 a 7) se reservan para un uso futuro y se establecen en cero. Sin embargo, pueden utilizarse más bits según se desee para establecer indicadores para el enlace de retorno. El campo de Divisor de Velocidad de Retorno (1 byte) especifica el número de ciclos MDDI_Stb que pueden ocurrir con relación de medir el tiempo de datos del enlace de retorno. Medir el tiempo de datos del enlace de retorno es igual de medir el tiempo de datos del enlace sin retorno dividido por dos veces el Divisor de Velocidad de Retorno. La velocidad de datos del enlace de retorno se relaciona con la medición de tiempo de datos del enlace de retorno y el Tipo de Interfaz en el enlace de retorno. En esta modalidad, para una interfaz Tipo 1 la velocidad de datos de retorno iguala la medición de tiempo de datos del enlace de retorno, para las interfaces Tipo 2, Tipo 3 y Tipo 4 las velocidades de datos de retorno igualan dos veces, cuatro veces, y ocho veces la medición de tiempo de datos del enlace de retorno, respectivamente. El Campo de Todo en Cero 1 contiene un grupo de bytes, que aquí son 8, es decir se establece igual a cero en el valor al ajustar los bits en un nivel de cero lógico, y se utiliza para asegurarse de que las señales MDDI_Data están en un nivel de cero lógico por un tiempo suficiente para permitirle al cliente que está recuperando la medición de tiempo utilizar solamente MDDI_Stb previo a la deshabilitación de los manejadores en línea del anfitrión durante el campo de Inversión de Sentido 1. En una modalidad, la longitud del campo de Todo en Cero 1 es mayor que o igual al número de veces de la transmisión del byte del enlace sin retorno en el retardo de ida y vuelta del cable. El campo de Longitud de Inversión de Sentido 1 (1 byte) especifica el número total de bytes que se destinan para Inversión de Sentido 1, estableciendo el primer periodo de inversión de sentido . El número de bits especificado mediante el parámetro Longitud de Inversión de Sentido 1 se destina para permitir que los manejadores en línea MDDI_Data en el cliente se habiliten, antes de que los manej adores en línea en el anfitrión se deshabiliten. El cliente habilita' sus manej adores en línea MDDI_Data durante el bit 0 de Inversión de Sentido 1 y el anfitrión deshabilita sus entradas de modo que estén completamente deshabilitadas antes del último bit de Inversión de Sentido 1. Los procesos de cronometraje para habilitar el manejador del cliente y deshabilitar el manejador del anfitrión son tales que uno o ambos accionan las señales MDDI_Data en un nivel de cero-lógico a través de toda la Inversión de Sentido 1 como se ve mediante los receptores en línea en el anfitrión. La señal MDDI_Stb se comporta como si MDDI_DataO estuviera en un nivel de cero-lógico durante todo el período de Inversión de Sentido 1. Se da una descripción más completa del ajuste de Inversión de Sentido 1 en lo anterior. El campo de Paquete de Datos de Retorno contiene una serie de datos que se transfieren del cliente al anfitrión. El cliente puede enviar paquetes rellenadores o accionar las líneas MDDI_Data en un estado o nivel de cero-lógico cuando no tiene datos que enviar al anfitrión. En esta modalidad, si las líneas MDDI_Data se accionan en cero, el anfitrión interpretará esto como ' un paquete con una longitud cero (longitud no válida) y el anfitrión no aceptará ningún paquete adicional del cliente durante el Paquete de Encapsulamiento de Enlace de Retorno actual . El campo de Longitud de Inversión de Sentido 2 (1 byte) específica el número total de bytes que se destinan para Inversión de Sentido 2, para establecer un segundo período de inversión de sentido. El número de bytes especificado por el parámetro Longitud de Inversión de Sentido se destina para permitir a los manej adores en línea MDDI_Data en el anfitrión que se habiliten antes de que los manej adores en línea en el cliente se deshabiliten. El anfitrión habilita sus manej adores ' en línea MDDI_Data durante el bit 0 del primer byte en Inversión de Sentido 2, y el cliente deshabilita sus salidas de modo que están completamente deshabitadas en forma general previo al último bit de Inversión de Sentido 2. Los procesos de cronometraje para deshabilitar el manejador del cliente y habilitar el manejador del anfitrión son tales que uno o ambos accionan las señales MDDI_Data0 en un nivel de cero-lógico a través de todo o durante todo, el período Inversión de Sentido 2, como se ve mediante los receptores en línea en el anfitrión. La señal MDDI_Stb se comporta como si MDDI_DataO estuviera en un nivel de cero-lógico durante sustancialmente todo el período de Inversión de Sentido 2. Se da una descripción del ajuste de Inversión de Sentido 2 en lo anterior. El campo de Paquete de Datos de Retorno contiene una serie de paquete de datos que se transfieren del cliente a un anfitrión. Como se estableció anteriormente, los paquetes del Rellenador se envían para rellenar el espacio restante que no se utiliza por otros tipos de paquetes . El campo de Todo en Cero 2 contiene un grupo de bytes (8 en esta modalidad) que se establece igual a cero en su valor al ajustar los bits en un nivel de cero-lógico, y se utiliza para asegurarse de que todas las señales MDDI_Data están a un nivel de cero-lógico por un tiempo suficiente para permitir al cliente comenzar a recuperar la medición de tiempo utilizando tanto MDDI_DataO y MDDI_Stb después de habilitar los manej adores en línea del anfitrión después del campo de Inversión de Sentido 2.

F. Para los Paquetes de Capacidad del Cliente Como se ilustra para una modalidad, el campo de Versión del Protocolo utiliza 2 bytes para especificar una versión del protocolo que está utilizando el cliente. La versión inicial se establece actualmente igual a cero, y se cambiará con el paso el tiempo conforme se generen nuevas versiones como es sabido, aunque el campo de Versión de Protocolo Mínima utiliza 2 bytes para especificar la versión de protocolo mínima que el cliente puede enviar o interpretar. En este caso, un valor de cero también es un valor válido. El campo de capacidad de Velocidad de los Datos (2 bytes) especifica la velocidad de datos máxima que el cliente puede recibir en cada par de datos en el enlace sin retorno 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 están soportados en los enlaces sin retorno y de retorno. Un bit que se establece en "1" indica que se soporta un tipo de interfaz específico, y un bit establecido en "0" indica que el tipo especificado no se soporta. Los anfitriones y los clientes debieran soportar al menos el Tipo 1 en las líneas sin retorno y de retorno. No existe requerimiento para soportar un rango contiguo de tipos de interfaz. Por ejemplo, sería perfectamente válido soportar solamente un Tipo 1 y Tipo 3, pero no un Tipo 3 y Tipo 4 en una interfaz. Esto también no es necesario para los enlaces sin retorno y de retorno para que operen con el mismo tipo de interfaz. Sin embargo, cuando un enlace sale de hibernación, ambos de los enlaces sin retorno y de retorno debieran comenzar en el modo tipo 1 hasta que puedan negociarse, seleccionarse o aprobarse de otros modos para utilizarlos tanto con el anfitrión como con el cliente. Las interfaces soportadas se indican en una modalidad al seleccionar el Bit 0, el Bit 1, o el Bit 2 para seleccionar ya sea un Tipo 2 (2 bits) , Tipo 3 (4 bits) , o Tipo 4 (8 bits) en el enlace sin retorno, respectivamente; y el modo Bit 3, Bit 4, o Bit 5 para seleccionar ya sea un Tipo 2, Tipo 3, o Tipo 4 en el enlace de retorno, respectivamente; con los Bits 6 y 7 que se reservan y que generalmente se establecen en cero en este momento. Los campos 7?ncho y Alto del Mapa de Bits tienen en cada uno aquí 2 bytes, especifican el ancho y la altura del mapa de bit, respectivamente, en píxeles. El campo de capacidad de Monocromo (1 byte) se utiliza para especificar el número de bits de resolución que puedan desplegarse en un formato monocromo. Si un despliegue no puede utilizar un formato monocromo, entonces este valor se establece en cero. Los Bits 7 hasta 4 se reservan para un uso futuro y de ese modo, se establecen en cero. Los Bits 3 hasta 0 definen el número máximo de bits de la escala de gris que puede existir para cada píxel. Esos cuatro bits hacen posible especificar los valores de 1 hasta 15 para cada píxel. Si el valor es cero, entonces el formato monocromo no está soportado por el despliegue. El campo de Capacidad Bayer utiliza 1 byte para especificar el número de bits de resolución, el grupo de píxel y el orden del píxel que puede transferirse en el formato Bayer. Si el 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 hasta 0 definen el número máximo de bits de intensidad existe en cada píxel, aunque los Bits 5 hasta 4 definen el patrón de grupo de píxel que se requiere, aunque Bits 8 hasta 6 definen el orden del píxel que se requiere; con los Bits 14 hasta 9 que se reservan para un uso futuro y generalmente se establecen en cero mientras tanto. El Bit 15 cuando se establece en uno indica que el cliente puede aceptar los datos de píxel Bayer ya sea en el formato empaquetado o desempaquetado. Si el bit 15 se establece en cero esto indica que el cliente puede aceptar los datos de píxel Bayer solamente en el formato desempaquetado. El campo de Capacidad del Mapa de Color (3 bytes) especifica el número máximo de los elementos de la tabla que existe en la tabla del mapa de color en el despliegue . Si el despliegue no puede utilizar el formato de mapa de color entonces este valor se establece en cero. El campo de Capacidad RGB (2 bytes) específica el número de bits de resolución que puede desplegarse en el formato RGB. Si el despliegue no puede utilizar el formato RGB, entonces este valor es igual a cero. La palabra Capacidad RGB está compuesta de tres valores sin signo separados en donde : los Bit 3 hasta 0 definen el número máximo de bits de azul, los Bit 7 hasta 4 definen el número máximo de bits de verde, y los Bit 11 hasta 8 definen el número máximo de bits de rojo en cada píxel. Actualmente, los Bits 14 hasta 12 se reservan para un uso futuro y generalmente se establecen en cero. Los Bit 14 hasta 12 están reservados para un uso futuro y generalmente se establecen en cero. El Bit 15 cuando se establece en uno indica que el cliente puede aceptar los datos de píxel RGB ya sea en el formato empaquetado o desempaquetado. Si el bit 15 se establece en un nivel de cero-lógico, esto indica que el cliente puede aceptar los datos de píxel RGB solamente en el formato desempaquetado. El campo de Capacidad Y Cr Cb (2 bytes) especifica el número de bits de resolución que pueden desplegarse en el formato Y Cr Cb. Si el despliegue no puede utilizar el formato Y Cr Cb entonces este valor se establece igual a cero. La palabra Capacidad Y Cr Cb se compone de tres valores sin signo separados en donde: Los Bit 3 hasta 0 definen el número máximo de bits en la muestra Cb, los Bits 7 hasta 4 definen el número máximo de bits en la muestra Cr, los Bit 11 hasta 8 definen el número máximo de bits en la muestra Y, y los Bit 15 hasta 12 se reservan actualmente para un uso futuro y se establecen en cero. El campo de Capacidad de Característica del Cliente utiliza 4 bytes que contienen un conjunto de indicadores que indican características específicas en el cliente que están soportadas. Un bit que se establece en uno indica que la capacidad está soportada, y un bit que se establece en cero indica que la capacidad no se soporta. En una modalidad, el valor para el Bit 0 indica si se soporta o no el Paquete de Transferencia del Bloque del Mapa de Bit (paquete tipo 71) . El valor para los Bit 1, 2 y 3 indica si se soportan o no el Paquete de Relleno de Área del Mapa de Bits (paquete tipo 72) , el Paquete de Relleno del Patrón del Mapa de Bits (paquete tipo 73) , o un Paquete del Canal de Datos del Enlace de Comunicación (paquete tipo 74) , respectivamente. El valor para el Bit 4 indica si el cliente tiene o no la capacidad de hacer un color transparente usando el Paquete Habilitar Color Transparente, mientras que los bits del Bit 5 al 6 indican si el cliente puede aceptar datos de Vídeo o datos de audio en el formato empaquetado, respectivamente, y el valor para el Bit 7 indica si el cliente puede enviar una corriente de Vídeo de enlace de retorno desde una cámara o no. El valor para el Bit 8 indica si el cliente tiene o no la capacidad para recibir una línea completa de datos de píxel e ignorar el direccionamiento del despliegue según se especifica mediante el bit 5 del campo de Atributos de los Datos de Píxel del Paquete de Corriente de Vídeo, y el cliente también puede detectar la sincronización de la trama o la finalización de los datos de la trama de Vídeo utilizando el bit 15 del campo de Atributos de los Datos de Píxel. 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 del Dispositivo de Señalamiento, o cuando con un teclado y puede enviar y recibir Paquete de Datos del Teclado, respectivamente . El valor para el Bit 13 indica si el cliente tiene o no la capacidad para establecer uno o más parámetros de audio o de Vídeo al soportar los paquetes de Características VCP: El Paquete de Característica VCP de Solicitud, Paquete de Respuesta de Característica VCP, Establecer Paquete de Características VCP, 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 capacidad de escribir datos de píxel dentro de la memoria intermedia de la trama del despliegue fuera de línea. Si este bit se establece en un nivel de uno-lógico entonces los Bits de Actualización del Despliegue (bits 7 y 6 del campo de Atributos de los Datos de Píxel del Paquete de la Corriente de Vídeo) puede establecerse en los valores '01'. El valor para el Bit 15 indica cuando el cliente tiene la capacidad de escribir datos de píxel dentro de solamente la memoria intermedia de la trama del despliegue que actualmente se está utilizando para renovar la imagen del despliegue . Si este bit se establece en uno entonces los Bits de actualización del despliegue (bits 7 y 6 del campo de Atributos de los Datos de Píxel del Paquete de la Corriente de Vídeo) pueden establecerse en los valores '00'. El valor para el Bit 16 indica cuando el cliente tiene la capacidad para escribir datos de píxel desde un solo Paquete de la Corriente de Vídeo dentro de todas las memorias intermedias de la trama del despliegue. Si este bit se establece en uno, entonces los Bits de Actualización del Despliegue (bits 7 y 6 del campo de Atributos de los Datos de Píxel del Paquete de la Corriente de Vídeo) pueden establecerse en el valor "11" . El valor para el Bit 17 indica cuando un cliente tiene la capacidad para responder al Paquete de Estado Específico de Solicitud, el valor para el Bit 18 indica cuando el cliente tiene la capacidad para responder al Paquete de Medición de Retraso de Ida y Vuelta, el valor para el Bit 19 indica cuando el cliente tiene la capacidad para el Paquete de Calibración del Sesgo del Enlace Sin Retorno . El valor para el Bit 21 indica cuando el cliente tiene la capacidad de interpretar el Paquete de Estado Específico de Solicitud y responder con el Paquete de Lista de Respuesta de Estado Válida. El cliente indica una capacidad para devolver el estado adicional en el campo de Lista de Respuesta de Parámetro Válida del Paquete de la Lista de Respuesta de Estado Válida como se describió en otra parte. El valor para el Bit 22 indica si el cliente tiene o no la capacidad para responder al Paquete de Acceso al Registro. Los Bits 9 hasta 10 y 23 hasta 31 se reservan actualmente para un uso futuro o designaciones útiles alternativas para los diseñadores del sistema y generalmente se establecen igual a cero . El campo de Capacidad de la Velocidad de la Trama de Vídeo en el Despliegue (1 byte) especifica la capacidad de actualización de la trama de vídeo máxima del despliegue en tramas por segundo. Un anfitrión puede elegir actualizar la imagen a una velocidad más lenta que la del valor especificado en este campo. El campo de Profundidad de la Memoria- Intermedia de Audio (2 bytes) especifica la profundidad de la memoria intermedia elástica en un Despliegue que está dedicado a cada corriente de audio.

El campo de Capacidad del Canal de Audio (2 bytes) contiene un grupo de indicadores que indican que canales de audio están soportados por el cliente o el dispositivo conectado al cliente. Un bit establecido en uno indica que el canal se soporta, y un bit establecido en cero indica que el canal no se soporta. Las posiciones de Bit están asignadas a diferentes canales, por ejemplo las posiciones de Bit 0, 1, 2, 3, 4, 5, 6, y 7 en una modalidad, que indican los canales frontal izquierdo, frontal derecho, posterior izquierdo, posterior derecho, central frontal, de sub-graves, izquierdo envolvente y derecho envolvente, respectivamente. Los Bits 8 hasta 14 se reservan actualmente para utilizarlos en el futuro, y generalmente se establecen en cero. En una modalidad el Bit 15 se utiliza para indicar si el cliente proporciona el soporte para Paquete de Habilitación del Canal de Audio Sin Retorno. Si este es el caso, el Bit 15 se establece en un nivel de uno-lógico. Sin embargo, si el cliente no es capaz de deshabilitar los canales de audio como resultado del Paquete de Habilitación del Canal de Audio Sin Retorno o si el cliente no soporta ninguna capacidad de audio, entonces este bit se establece en un nivel o valor de cero-lógico. Un campo de capacidad de Velocidad de la Muestra de Audio de 2 bytes, para el enlace sin retorno, contiene un conjunto de indicadores para indicar la capacidad de la velocidad de la muestra de audio del dispositivo de cliente. Las posiciones de Bit se asignan para diferentes velocidades consecuentemente, tales como los Bits 0, 1, 2, 3, 4, 5, 6, 7 y 8 que 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, con los Bits 9 hasta 15 que se reservan para usos futuros o de velocidad alternativas, según se desee, así que actualmente se establecen en ' 0 ' . Establecer un valor de bit para uno de esos bits en '1' indica que esa velocidad de muestra en particular se soporta, y establecer el bit "0" indica que esa velocidad de muestra no se soporta. El campo de Velocidad de Sub-trama Mínima (2 bytes) específica la velocidad mínima de sub-trama en tramas por segundo. La velocidad mínima de sub-trama mantiene la velocidad de actualización del estado del cliente lo suficiente para leer ciertos sensores o dispositivos de señalamiento en el cliente. Un campo de Capacidad de Velocidad de Muestra de Mic de 2 bytes, para el enlace de retorno, contiene un conjunto de indicadores que indican la capacidad de la velocidad de la muestra de audio de un micrófono en el dispositivo de cliente. Para propósitos de la MDDI, un micrófono del dispositivo de cliente está configurado para soportar mínimamente al menos una velocidad de 8,000 muestras por segundo. Las posiciones de Bit para este campo se asignan para diferentes velocidades con posiciones de Bit de 0, 1, 2, 3, 4, 5, 6, 7, y 8, por ejemplo, que se utilizan para representar 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050 y 44,100 muestras por segundo (SPS) , respectivamente, con los Bits 9 hasta 15 que se reservan para usos futuros o de velocidad alternativa, según se desee, así que pueden actualmente establecerse en '0'. Al establecer un valor de bit para uno de esos bits ?l' indica que esa velocidad de muestra en particular está soportada, y al establecer el bit en '0' indica que esa velocidad de muestra no se soporta. Si no se conecta ningún micrófono entonces cada uno de los bits de la Capacidad de la Velocidad de la Muestra de Mic se establece igual a cero. El campo de Formato de los Datos del Teclado (que aquí es de 1 byte) específica si el teclado está conectado o no al sistema del cliente y el tipo de teclado que se conecta. En una modalidad, el valor establecido por los Bits 6 hasta el 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 los datos del teclado se considera que es de un estilo PS-2 estándar. Los valores actualmente en el rango de 2 hasta 125 no se utilizan, se reservan para uso de los diseñadores del sistema e incorporadores de la interfaz o desarrolladores del producto para que definan el teclado específico o los dispositivos de entrada para utilizarlos con la interfaz MDD y los correspondientes clientes o anfitriones. Un valor de 126 se utiliza para indicar que el formato de datos del teclado es definido por el usuario, mientras que un valor de 127 se utiliza para indicar que un teclado no puede conectarse a este cliente. Además, el Bit 7 puede utilizarse para indicar si el teclado puede comunicarse o no con el cliente . El uso pretendido de este bit es indicar cuando el teclado puede comunicarse con el cliente utilizando un enlace inalámbrico. El Bit 7 se establecería en un nivel cero si los bits 6 hasta 0 indican que un teclado no puede conectarse con el cliente. Por lo tanto, para una modalidad, cuando el valor de Bit 7 es 0, el teclado y el cliente no pueden comunicarse, mientras que si el valor del Bit 7 es 1, el teclado y cliente han reconocido que pueden comunicarse entre sí . El campo de Formato de los Datos del Dispositivo de Señalamiento (que aquí es de 1 byte) específica si el dispositivo de señalamiento se conecta o no con el sistema del cliente y el tipo de dispositivo de señalamiento que está conectado. En una modalidad, el valor establecido mediante los Bits 6 hasta 0 se utilizan para definir el tipo de dispositivo de señalamiento que se conecta. 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 los datos del dispositivo de señalamiento se considera que son de un estilo PS-2 •estándar. Los valores actuales en el rango de 2 hasta 125 no se utilizan, se reservan para ser utilizados por los diseñadores del sistema y los incorporadores de la interfaz o los desarrolladores del producto para definir el dispositivo de señalamiento específico o los dispositivos de entrada para utilizarlos con la interfaz MDD y los clientes o anfitriones correspondientes. Se usa un valor de 126 para indicar que el formato de los datos del dispositivo de señalamiento son definidos por el usuario, mientras que un valor de 127 se utiliza para indicar que un dispositivo de señalamiento no puede conectarse con este cliente. Además el Bit 7 puede utilizarse para indicar si el dispositivo de señalamiento puede comunicarse o no con el cliente. El uso pretendido de este bit es indicar cuando el teclado puede comunicarse con el cliente utilizando un enlace inalámbrico . El Bit 7 se establecería en un nivel de cero si los bits 6 hasta 0 indican que un dispositivo de señalamiento no puede conectarse con el cliente . Por lo tanto, para una modalidad, cuando el valor de Bit 7 es 0, el dispositivo de señalamiento y el cliente no pueden comunicarse, mientras que si el valor del Bit 7 es 1, el dispositivo de señalamiento y el cliente han reconocido que pueden comunicarse entre sí. El campo de Tipo de Protección del Contenido (2 bytes) contiene un conjunto de indicadores que indican el tipo de protección del contenido digital que es soportada por Despliegue. Actualmente, la posición del bit 0 se utiliza para indicar cuando se soporta la DTCP y la posición de bit 1 se utiliza para indicar cuando se soporta la HDCP con las posiciones de bit 2 hasta 15 reservándose para utilizarlas con otros esquemas de protección según se desee o estén disponibles, así que actualmente se establecen en cero . Nombre del Fabricante - 2 bytes que forman un valor de 16 bits que contiene el ID del carácter 3 EISA (Arquitectura Estándar Industrial Ampliada) del fabricante, empaqueta en 3 caracteres de 5 bits de la misma manera que la especificación VESA EDID. El carácter 'A' está representado como un 00001 binario, el carácter 'Z' está representado como 11010 binario, y todas las letras entre 'A' y 'Z' están representadas como valores binarios secuenciales que corresponden a la secuencia alfabética entre 'A' y 'Z' . El bit más importante del campo de Nombre del Fabricante no se utiliza y generalmente se establece en cero lógico por ahora hasta que se utiliza en implementaciones futuras. Por ejemplo: un fabricante representado por la serie de caracteres 'XYZ' debería tener un valor que el Nombre del Fabricante de 0x633a. Si este campo no es soportado por el cliente debe establecerse en cero . Código de Producto - 2 bytes que contienen un código de producto asignado por el fabricante del despliegue. Si este campo no es soportado por el cliente debe estar en cero. Los campos Reservado 1, Reservado 2 y Reservado 3 (aquí de 2 bytes cada uno) están reservados para un uso futuro en la impartición de información. Todos los bits en este campo generalmente se establecen -en un nivel de cero lógico. El propósito de este campo es provocar que todos los campos subsecuentes 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 Número de Serie utiliza 4 bytes en esta modalidad que especifican el número de serie del despliegue en forma numérica. Si este campo no es soportado por el cliente generalmente se establece en cero. El campo Semana de Fabricación utiliza 1 byte que define la semana de fabricación del despliegue . Este valor debe estar en el rango de 1 a 53 si es soportado por el cliente. Si este campo no es soportado por el cliente debe estar en cero . El campo Año de Fabricación es 1 byte que define el año de fabricación del despliegue. Este valor es un intervalo desde el año 1990. Los años en el rango de 1991 hasta 2245 pueden expresarse mediante este campo. Ejemplo: el año 2003 corresponde a un valor del Año de Fabricación de 13. Si este campo no es soportado por el cliente debe estar en cero. El campo CRC (aquí 2 bytes) contiene una CRC de 16 bits de todos los bytes en el paquete que incluye la Longitud de Paquete .

G. Para los Paquetes de Estado y Solicitud del Cliente El campo de Solicitud del Enlace de Retorno (3 bytes) específica el número de bytes que el cliente necesita en el enlace de retorno en el siguiente sub-trama para enviar la información al anfitrión. El campo de Conteo de Error CRC (1 byte) indica cuantos errores CRC han ocurrido desde el inicio de trama de medios. El conteo CRC se reinicia cuando un paquete del encabezamiento del sub-trama con un Cónteo de Sub-trama de cero se envía. Si el número actual de los errores 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 conecta un dispositivo periférico tal como un micrófono, tecla o despliegue, o por alguna otra razón. Cuando los Bits [7:0] son iguales a 0, entonces la capacidad no ha cambiado dado que el último Paquete de Capacidad del Cliente se envío. Sin embargo, cuando los Bits [7:0] son iguales a 1 hasta 255, la capacidad ha cambiado. El Paquete de Capacidad del Cliente se examina para determinar las nuevas características del despliegue. El campo Banderas de Cliente Ocupado usa dos bytes para indicar que el cliente esta ejecutando una función específica y que no está listo para aceptar aún otro paquete relacionado con esa función. Un bit establecido en un nivel o valor lógico indica que la función particular está llevándose a cabo actualmente por parte del cliente y que la función relacionada en el cliente está ocupada. Si la función en el cliente está lista, el bit se establece en un cero lógico. El cliente debería devolver un estado de ocupado (bit establecido en uno) para todas las funciones que no estén soportadas por el cliente. En una modalidad, esos bytes se interpretan de acuerdo con la relación: si el Bit 0 es un '1' entonces la función de transferencia de del bloque del mapa de bits está ocupada, mientras que si el Bit 2 es un Y', entonces la función de relleno del patrón del mapa de bits está ocupada. Actualmente, los Bits 3 a 15 permanecen reservados para un uso futuro y generalmente se establecen en un nivel o estado de cero lógico para indicar un estado ocupado en caso de que esos bits se asignen en el futuro.

H. Para los Paquetes de Transferencia del Bloque de Bits Los campos de Valor X y Valor Y de la Coordenada Superior Izquierda de la Ventana utiliza 2 bytes cada uno para especificar el valor X y Y de las coordenadas de la esquina superior izquierda 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 la 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 horizontal y verticalmente, respectivamente. De manera típica, esas coordenadas se configuran de modo que los valores positivo para X provoquen que la ventana se mueva hacia la derecha, y los valores negativos provocan su movimiento hacia la izquierda, mientras que los valores positivos para Y provocan que la ventana se mueva hacia abajo y los valores negativos provocan su movimiento hacia arriba.

I. Para los Paquetes de Relleno del Área de Mapa de Bits Los campos de Valor X y Valor Y de la Coordinada Superior Izquierda de la Ventana utilizan 2 bytes cada uno para especificar el valor X y Y de las coordenadas de la esquina superior izquierda de la ventana para que se rellenen. Los campos de Ancho y Alto de Ventana (2 bytes cada uno) especifican el ancho y el alto de la ventana que se va a rellenar. El campo de Descriptor del Formato de los Datos de Vídeo (2 bytes) especifica el formato del Valor de Relleno del Área de Píxel . El formato es el mismo que el del mismo campo en el Paquete de Corriente de Vídeo. El campo del Valor de Relleno del Área de Píxel (4 bytes) contiene el valor de píxel que se va a rellenar dentro de la ventana especificada mediante los campos anteriormente discutidos. El formato de este píxel se especifica en el campo de Descriptor del Formato de los Datos de Vídeo.

J. Para los Paquetes del Relleno del Patrón de Mapa de Bits Los campos de Valor X y Valor Y de la Coordenada Superior Izquierda de la Ventana utilizan 2 bytes cada uno para especificar el valor X y Y de las coordenadas de la esquina superior izquierda de la ventana que se va rellenar. Los campos de Ancho y Alto de Ventana (2 bytes cada uno) especifican el ancho y el alto de la ventana que se va a rellenar. Los campos de Patrón de Ancho y Patrón de Alto (2 bytes cada uno) especifican el ancho y el alto, respectivamente, del patrón de relleno. El campo de Desplazamiento Horizontal del Patrón (2 bytes) específica un desplazamiento horizontal del patrón de los datos de píxel del borde izquierdo de la ventana específica que se va a rellenar. El valor que se específica va a ser menor que el valor en el Campo de Ancho de Patrón. El campo de Desplazamiento Vertical del Patrón (2 bytes) específica un desplazamiento vertical del patrón de los datos de píxel desde el borde superior de la ventana específica que se va a rellenar. El valor que se específica va a ser menor que el valor en el campo de Altura de Patrón. El campo de Descriptor del Formato de los Datos de Vídeo de 2 bytes específica el formato del Valor de Relleno del Área de Píxel. La FIGURA HA A HE ilustra como se codifica el Descriptor del Formato de los Datos de Vídeo. El formato es el mismo que el mismo campo en el Paquete de la Corriente de Vídeo. El campo del Parámetro CRC (2 bytes) contiene una CRC de todos los bytes de la Longitud de Paquete del Descriptor del Formato de Vídeo. Si esta CRC falla al verificar, entonces todo el paquete se descarta. El campo de Datos de Píxel del Patrón contiene información de vídeo en bruto que específica que el patrón de relleno en el formato especificado mediante el Descriptor del Formato de los Datos de Vídeo. Los datos se empaquetan en bytes, y el primer píxel de cada fila se va a alinear por bytes. Los datos del patrón de relleno se transmiten una fila a la vez. El campo de CRC de los Datos de Píxel del Patrón (2 bytes) contiene una CRC de solamente los Datos de Píxel del Patrón. Si estas CRC falla al verificar, entonces los Datos de Píxel del Patrón pueden aún utilizarse aunque se incrementa el conteo de error CRC.

K. Paquetes del Canal de los Datos del Enlace de Comunicación El campo de Parámetro CRC (2 bytes) contiene una CRC de 16 bits de todos los bytes de la Longitud de Paquete para el Tipo de Paquete. Si esta CRC falla al verificar, entonces todo el paquete se descarta. El campo de Datos del Enlace de Comunicación contiene los datos en bruto del canal de comunicación.

Estos datos simplemente se pasan en el dispositivo de cómputo en el despliegue. El campo de CRC de los Datos del Enlace de Comunicación (2 bytes) contiene una CRC de 16 bits de solamente los Datos del Enlace de Comunicación. Si esta CRC falla para verificar, entonces los Datos del Enlace de Comunicación se pueden utilizar aún o son útiles, pero el conteo de error CRC se incrementa.

L. Para Paquetes de Solicitud de Transferencia Intracelular Tipo Interfaz El campo de Tipo de Interfaz (1 byte) específica el nuevo tipo de interfaz que se va a utilizar. El valor en este campo especifica el tipo de interfaz de la siguiente manera. Si el valor en el Bit 7 es igual a '0' la solicitud de Tipo transferencia intracelular es para el enlace sin retorno, si es igual a '1', entonces la solicitud del Tipo transferencia intracelular es para el enlace de retorno. Los Bits 6 a 3 se reservan para un uso futuro, y generalmente se establecen en cero. Los Bits 2 hasta 0 se utilizan para definir el Tipo de Interfaz que se va a utilizar, con un valor de 1 que significa una transferencia intracelular de un modo Tipo 1, un valor de 2 en una transferencia intracelular de un modo Tipo 2, un valor de 3 en una transferencia intracelular de un modo Tipo 3, y un valor de 4 en una transferencia intracelular de un modo Tipo 4. Los valores de ?0' y 5 hasta 7 se reservan para una designación futura de modos o combinaciones de modos alternativos .

M. Para Paquetes de Reconocimiento del Tipo de Interfaz El campo de Tipo de Interfaz (1 byte) tiene un valor que confirma el nuevo tipo de interfaz que se va a utilizar. El valor en este campo especifica el tipo de interfaz de la siguiente manera. Si el Bit 7 es igual a '0' la solicitud de Tipo transferencia intracelular es para el enlace sin retorno, alternativamente, si es igual a '1' la solicitud de Tipo transferencia intracelular es para el enlace de retorno. Las posiciones de Bits 6 a 3 están actualmente reservadas para su uso en el diseño de otros tipos de transferencia intracelular, según se desee, y generalmente se establecen en cero. Sin embargo, las posiciones de bit 2 hasta 0 se utilizan para definir el Tipo de interfaz que se va a utilizar con un valor de '0' que indica un reconocimiento negativo, o que la transferencia intracelular solicitada no puede llevar a cabo, los valores de ?l', ?2', ?3' y Y' indican una transferencia intracelular para los modos Tipo 1 , Tipo 2 , Tipo 3 y Tipo 4 , respectivamente . Los valores de 5 hasta 7 se reservan para utilizarlos con designaciones de modos alternativos, según se desee.

N. Para Paquetes de Transferencia Intracelular Tipo Desempeño El campo de Tipo de Interfaz de 1 byte indica el nuevo tipo de interfaz que se va a usar. El valor presente en este campo especifica el tipo de interfaz mediante primero la utilización del valor de Bit 7 para determinar si el Tipo de transferencia intracelular es o no para los enlaces sin retorno o de retorno. Un valor de '0' indica que la solicitud de Tipo transferencia intracelular es para el enlace sin retorno, y el valor de ?l' para el enlace de retorno. Los Bits 6 hasta 13 están reservados para un uso futuro, y estos generalmente se establecen en un valor de cero. Sin embargo, los Bits 2 hasta 0 se utilizan para definir el Tipo de Interfaz que va a utilizarse, con los valores 1, 2, 3, y 4 especificando el uso de transferencia intracelular para los modos Tipo 1, Tipo 2, Tipo 3 y Tipo 4, respectivamente. El uso de los valores 0 y 5 hasta 7 para esos bits se reserva para un uso futuro.

O. Para Paquetes que Habilitan el Canal de Audio Sin Retorno El campo de Máscara que Habilita el Canal de Audio (1 byte) contiene un grupo de indicadores que indican que canales de audio se van a habilitar en un cliente. Un bit que establece en uno habilita el canal correspondiente, y un bit que se establece en cero deshabilita el canal correspondiente . Los Bits 0 hasta 5 designan los canales 0 hasta 5 que direccionan los canales frontal izquierdo, frontal derecho, posterior izquierdo, posterior derecho, central frontal, de sub-graves, izquierdo envolvente y derecho envolvente, respectivamente. Los Bits 6 y 7 están reservados para un uso futuro, y mientras tanto generalmente se establecen igual a cero .

P. Paquete de Velocidad de la Muestra de Audio de Retorno El campo de Velocidad de la Muestra de Audio (1 byte) específica la velocidad de la muestra de audio digital . Los valores para este campo se asignan para diferentes velocidades con valores de 0, 1, 2, 3, 4, 5, 6, 7 y 8 que 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, con valores de 9 hasta 254 que se reservan para utilizarlos con velocidades alternativas, según se desee, así que actualmente se establecen en '0'. Un valor de 255 se utiliza para deshabilitar la corriente de audio del enlace de retorno. El campo de Formato de Muestra (1 byte) específica el formato de las muestras de audio digitales. Cuando los Bits [1:0] son iguales a '0', las muestras de audio digitales están en un formato lineal, cuando son iguales a 1, las muestras de audio digitales están en un formato µ-Law, y cuando son iguales a 2, las muestras de audio digitales están en un formato A-Law. Los Bits [7:2] están reservados para alternar su uso en la designación de formatos de audio, según se desea, y generalmente se establecen iguales a cero.

Q. Para Paquetes de Operaciones Auxiliares de Protección del Contenido Digital El campo de Tipo de Protección de Contenido (1 byte) específica el método de protección de contenido digital que se utiliza. Un 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 Elevado (HDCP) . El rango del valor es de 2 hasta 255 y no se especifica actualmente aunque se reserva para su uso con esquemas de protección alternativos, según se desee. El campo de Mensajes de Operaciones Auxiliares para la Protección del Contenido es un campo de longitud variable que contiene mensajes de protección de contenido que se envían entre el anfitrión y el cliente.

R. Para los Paquetes de Habilitación del Color Transparente El campo de Habilitación de Color Transparente (1 byte) específica cuando se habilita o se deshabilita el modo de color transparente . Si el Bit 0 es igual a 0 , entonces el modo de color transparente está deshabilitado, si es igual a 1 entonces el modo de color transparente está habilitado y el color transparente se específica mediante los siguientes dos parámetros. Los Bits 1 hasta 7 de este byte se reservan para un uso futuro y típicamente se establecen igual a cero. El campo de Descriptor del Formato de los Datos de Vídeo (2 bytes) específica el formato del Valor de Relleno del Área de Píxel. La FIGURA HA A HE ilustra como se codifica el Descriptor de Formato de los Datos de Vídeo. El formato generalmente es el mismo que el del mismo campo en el Paquete de Corriente de Vídeo. El campo de Valor de Relleno del Área de Píxel utiliza 4 bytes destinados para el valor de píxel que se va a rellenar dentro de la ventana anteriormente especificada. El formato de este píxel está especificado en el campo de Descriptor del Formato de Vídeo.

S . Para los Paquetes de Medición del Retraso de Ida y Vuelta El campo de Longitud de Paquete de 2 bytes específica el número total de bytes en el paquete que no incluyen el campo de Longitud de Paquete, y en una modalidad, se selecciona para tener una longitud fija de 159. El campo de Tipo del Paquete de 2 bytes que identifica este tipo de paquete con un valor 82, identificando a un paquete como un Paquete de Medición del Retraso de Ida y Vuelta. El campo de ID del Clienteh, como anteriormente se reserva para un uso futuro como una ID del Cliente, y generalmente se establece en cero. En una modalidad, el campo de Parámetro CRC (2 bytes) contiene una CRC de 16 bits de todos los bytes de la Longitud de Paquete para el Tipo de Paquete . Si esta CRC falla al verificar, entonces todo el paquete se descarta. El campo de Tiempo de Guarda 1 (que aquí es de 64 bytes) se utiliza para permitir a los manej adores en línea MDDI_Data en el cliente habilitarse antes de que los manej adores en línea en el anfitrión se deshabiliten. El cliente habilita sus manej adores en línea MDDI_Data durante el bit 0 del Tiempo de Guarda 1 y el anfitrión deshabilita los manej adores en línea de modo que estén completamente deshabilitados previos al último bit del Tiempo de Guarda 1. El anfitrión y el cliente tienen ambos un nivel de cero-lógico durante el Tiempo de Guarda 1 cuando no están deshabilitados. Otro propósito de este campo es asegurar que todas las señales MDDI_Data estén en un nivel de cero-lógico durante un tiempo suficiente para permitir al cliente iniciar la recuperación de medir el tiempo o señal de medir el tiempo que utiliza MDDI_Stb previo a la deshabilitación de los manej adores en línea del anfitrión. El campo de Período de Medición es una ventana de 64 bytes utilizada para permitir al cliente responder con dos bytes de Oxff, y 30 bytes de 0x0 a la mitad de la velocidad de datos utilizada en el enlace sin retorno. Esta velocidad de datos corresponde a un Divisor de la Velocidad del Enlace de Retorno de 1. El cliente devuelve esta respuesta inmediatamente en el momento en que la percibe como si estuviera iniciando el Período de Medición. Esta respuesta del cliente será recibida en un anfitrión precisamente en el retraso de ida y vuelta del enlace más el retraso lógico en el cliente tras el inicio del primer bit del Período de Medición en el anfitrión. El campo de Todo en Cero 1 (2 bytes) contiene los ceros que permiten a los manej adores en línea MDDI_Data en el anfitrión y el cliente superponerse de modo que MDDI_Data siempre está accionado. El anfitrión habilita los manej adores en línea MDDI_Data durante el bit 0 del Tiempo de Guarda 2, y el cliente también acciona la señal en un nivel de cero-lógico como lo hizo al final del Período de Medición.

El valor en el campo de Tiempo de Guarda 2 (64 bytes) permite superponer el Período de Medición accionado por el cliente cuando el retraso del viaje de ida y vuelta está en la cantidad máxima que puede medirse en el Período de Medición. El Cliente deshabilita sus manej adores en línea durante el bit 0 del Tiempo de Guarda 2 y el Anfitrión habilita sus manejadores en línea inmediatamente después del último bit del Tiempo de Guarda 2. El anfitrión y el cliente accionan ambos un nivel de cero-lógico durante el Tiempo de Guarda 2 cuando no están deshabilitados. Otro propósito de este campo es asegurar que todas las señales MDDI_Data estén en un nivel de cero-lógico durante un tiempo suficiente para permitir al cliente iniciar la recuperación de una señal de medir el tiempo utilizando ambos MDDI_Data0 y MDDI_Stb tras habilitar los manej adores en línea para un anfitrión.

T. Para los Paquetes de Calibración del Sesgo del Enlace Sin Retorno En una modalidad, el campo de Parámetro CRC (2 bytes) contiene una CRC de 16 bits para todos los bytes de la Longitud de Paquete para el Tipo de Paquete. Si esta CRC falla en verificarlos entonces en todo el paquete se descarta. El campo Todo en Cero usa un byte para asegurar que habrá transiciones en el MDDI_Stb al final del campo CRC. El campo de Secuencia de los Datos de Calibración contiene una secuencia de datos de 512 bytes que provoca que las señales MDDI_Data conmuten en todos los períodos de datos . La longitud del campo Secuencia de Datos de Calibración se determina mediante la interfaz que se está utilizando en el enlace sin retorno. Durante el procesamiento de la Secuencia de Datos de Calibración, el controlador del anfitrión MDDI establece todas las señales MDDI_Data iguales a la señal del estroboscopio. El circuito de recuperación de medir el tiempo del cliente debiera utilizarse solamente en MDDI_Stb más que en MDDI_Stb X o MDDI_DataO para recuperar la medición de tiempo de datos mientras que el campo de Secuencia de los Datos de Calibración se está recibiendo a través del Despliegue del Cliente. Dependiendo de la fase exacta de la señal MDDI_Stb al inicio del campo de Secuencia de los Datos de Calibración, la Secuencia de los Datos de Calibración generalmente será uno de los siguientes con base en el Tipo de interfaz que se esté utilizando cuando este paquete se envía : Tipo I- (secuencia de datos de 64 bytes) Oxaa, Oxaa...o 0x55,0x55... Tipo II- (secuencia de datos de 128 bytes) Oxee, Oxee... o 0x33, 0x33... Tipo III- (secuencia de datos de 256 bytes) OxfO, OxfO... o OxOf, OxOf... Tipo IV- (secuencia de datos de 512 bytes) Oxff, 0x00, Oxff, 0x00 ... o 0x00, Oxff, 0x00, Oxff... Un ejemplo de las formas de onda posibles de MDDI_Data y MDDI_Stb para ambas Interfaces Tipo 1 y Tipo 2 se muestra en las FIGURAS 62A y 62B, respectivamente.

XVII. Conclusión Aunque se han descrito anteriormente diversas modalidades de la presente invención, debió de entenderse que se han presentado a modo de ejemplo solamente, y no de limitación. De ese modo, la amplitud y el alcance de la presente invención no debieran limitarse a ninguna de las modalidades ejemplares anteriormente descritas, sino que debe definirse solamente de acuerdo con la siguientes r reivindicaciones y sus equivalentes .

Claims (70)

1. NOVEDAD DE LA INVENCIÓN Habiendo descrito la presente invención se considera como novedad y por lo tanto se reclama como propiedad lo descrito en las siguientes reivindicaciones . REIVINDICACIONES 1. Una interfaz de datos digital para transferir datos de una presentación digital a una velocidad elevada entre un dispositivo de anfitrión y un dispositivo de cliente a través de una trayectoria de comunicación caracterizada porque comprende: una pluralidad de estructuras de paquete enlazadas conjuntamente para formar un protocolo de comunicación para comunicar un conjunto pre-seleccionado de datos de control y presentación digitales entre un anfitrión y un cliente a través de la trayectoria de comunicación; y al menos un controlador de enlace que reside en el dispositivo del anfitrión acoplado al cliente a través de la trayectoria de comunicaciones, que se configura para generar, transmitir o recibir paquetes que forman el protocolo de comunicaciones, y para formar los datos de la presentación digital en uno o más tipos de paquetes de datos .
2. 2. La interfaz de conformidad con la reivindicación 1, caracterizada además porque comprende los paquetes agrupados conjuntamente dentro de la trama de medios que se comunican entre el anfitrión y el cliente que tienen una longitud fija pre-definida con un número pre-determinado de paquetes que tienen longitudes diferentes y variables .
3. 3. La interfaz de conformidad con la reivindicación 1, caracterizada además porque comprende un Paquete de Encabezamiento de Sub-trama colocado en el principio de las transferencias de los paquetes del anfitrión.
4. 4. La interfaz de conformidad con la reivindicación 1, caracterizada porque el controlador de enlace es un controlador del enlace del anfitrión y además comprende al menos un controlador de enlace del cliente que reside en el dispositivo de cliente acoplado al anfitrión a través de la trayectoria de comunicaciones, que se configura para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones, y para formar datos de una presentación digital en uno o más tipos de paquetes de datos .
5. 5. La interfaz de conformidad con la reivindicación 1, caracterizada además porque comprende uno o más Paquetes de Corriente de Vídeo para los datos tipo vídeo, y los Paquetes de Corriente de Audio para datos tipos audio para transferir datos desde el anfitrión hasta el cliente a través de un enlace sin retorno para su presentación a un usuario del cliente .
6. 6. La interfaz de conformidad con la reivindicación 2, caracterizada además porque comprende: una pluralidad de modo de transferencia, cada uno permite la transferencia de números de bits máximos diferentes de los datos en paralelo a través de un período de tiempo determinado, con cada modo que puede seleccionarse mediante la negociación entre los manejadores de enlace del anfitrión y el cliente; y en donde los modos de transferencia se pueden ajustar dinámicamente entre los modos durante la transferencia de los datos .
7. 7. La interfaz de conformidad con la reivindicación 1, caracterizada además porque comprende una pluralidad de paquetes que pueden utilizarse para transferir información de vídeo elegida de un grupo de Mapa de Color, Transferencia de Bloque de Bit, Relleno de Área del Mapa de Bit, Relleno del Patrón del Mapa de Bit, y paquetes tipo Habilitar Color Transparente.
8. 8. La interfaz de conformidad con la reivindicación 1, caracterizada además porque comprende paquetes tipos Rellenador generados mediante el anfitrión para ocupar períodos de la transmisión del enlace sin retorno que no tienen datos.
9. 9. La interfaz de conformidad con la reivindicación 1, caracterizada además porque comprende paquetes tipo Corriente Definida por el Usuario para transferir datos definidos por la interfaz del usuario.
10. 10. La interfaz de conformidad con la reivindicación 1, caracterizada además porque comprende un paquete tipo Cierre de Enlace para la transmisión del anfitrión al cliente para terminar la transferencia de datos en cualquier dirección a través de la trayectoria de comunicación.
11. 11. La interfaz de conformidad con la reivindicación 1, caracterizada además porque comprende medios para que el cliente despierte al anfitrión del estado de hibernación.
12. 12. Un método para transferir datos digitales a una velocidad elevada entre un dispositivo del anfitrión y un dispositivo de cliente a través de una trayectoria de comunicación para su presentación a un usuario, caracterizado porque comprende: generar una o más estructuras de una pluralidad de paquetes predefinidos y enlazarlos conjuntamente para formar un protocolo de comunicación predefinido; comunicar un conjunto preseleccionado de datos de presentación y control digitales entre los dispositivos del anfitrión y del cliente a través de la trayectoria de comunicación utilizando el protocolo de comunicación; acoplar al menos un controlador de enlace del anfitrión que reside en el dispositivo del anfitrión para el dispositivo de cliente a través de la trayectoria de comunicaciones, el controlador de enlace del anfitrión se configura para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones, y para formar datos de una presentación digital dentro de uno o más tipos de paquetes de datos; y transferir los datos en forma de paquetes a través de la trayectoria de comunicaciones utilizando los controladores de enlace.
13. 13. El método de conformidad con la reivindicación 12, caracterizado además porque comprende agrupar los paquetes conjuntamente dentro de las tramas de medios para su comunicación entre el anfitrión y el cliente, las tramas de medios tienen una longitud fija predefinida con un número predeterminado de paquetes que tienen longitudes diferentes y variables.
14. 14. El método de conformidad con la reivindicación 12, caracterizado además porque comprende comenzar la transferencia de paquetes desde el anfitrión con un paquete tipo Encabezamiento de Sub-trama.
15. 15. El método de conformidad con la reivindicación 12, caracterizado además porque comprende transferir información entre el anfitrión y el cliente bi-direccionalmente a través del enlace de comunicaciones.
16. 16. El método de conformidad con la reivindicación 12, caracterizado además porque comprende al menos un controlador de enlace del cliente que reside en el dispositivo de cliente acoplado al dispositivo del anfitrión a través de la trayectoria de comunicaciones, que se configura para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones, y para formar datos de una presentación digital dentro de uno o más tipos de paquetes de datos .
17. 17. El método de conformidad con la reivindicación 16, caracterizado porque comprende el controlador del enlace del anfitrión comprende uno o más manej adores en línea diferenciales; y el controlador de enlace del cliente comprende uno o más receptores en línea diferenciales acoplados a la trayectoria de comunicación.
18. 18. El método de conformidad con la reivindicación 12, caracterizado además porque comprende solicitar información de las funciones de despliegue del cliente mediante un controlador de enlace del anfitrión de modo que se determina que tipo de datos y velocidades de datos del cliente es capaz de ajustar a través de la interfaz.
19. 19. El método de conformidad con la reivindicación 12, caracterizado además porque comprende operar una interfaz de datos USB mediante cada uno de los controladores de enlace como parte de la trayectoria de comunicación.
20. 20. El método de conformidad con la reivindicación 12, caracterizado porque comprende los paquetes que comprenden cada uno un campo de longitud de paquete, uno o más campos de datos de paquete, y un campo de verificación de redundancia cíclico.
21. 21. El método de conformidad con la reivindicación 13, caracterizado además porque comprende: negociar entre los manej adores de enlace del anfitrión y el cliente, el uso de una pluralidad de modos de transferencia en cada dirección, permitiendo cada uno la transferencia de números de bits máximos diferentes de datos en paralelo a través de un periodo de tiempo determinado; y ajustar dinámicamente entre los modos de transferencia durante la transferencia de datos.
22. 22. El método de conformidad con la reivindicación 12, caracterizado además porque comprende utilizar uno o más de una pluralidad de paquetes para transferir información de video elegidos de un grupo de Mapa de Color, Transferencia de Bloque de Bits, Relleno de Área del Mapa de Bits, Relleno del Patrón del Mapa de Bits y paquetes tipo Habilitar Color Transparente.
23. 23. El método de conformidad con la reivindicación 12, caracterizado además porque comprende generar paquetes tipo Rellenador mediante el anfitrión para ocupar los períodos de transmisión del enlace sin retorno que no tienen datos.
24. 24. El método de conformidad con la reivindicación 12, caracterizado además porque comprende terminar la transferencia de datos en cualquier dirección a través de la trayectoria de comunicación utilizando un paquete tipo Cierre de Enlace para la transmisión mediante el anfitrión hacia el cliente.
25. 25. El método de conformidad con la reivindicación 12, caracterizado además porque comprende despertar al anfitrión de un estado de hibernación mediante la comunicación con el cliente.
26. 26. Un aparato para transferir datos digitales a una velocidad elevada entre un dispositivo anfitrión y un dispositivo de cliente a través de una trayectoria de comunicación para su presentación a un usuario, caracterizado porque comprende: al menos un controlador de enlace del anfitrión dispuesto en el dispositivo del anfitrión para generar una o más de una pluralidad de estructuras de paquete predefinidas y enlazarlas en forma conjunta para formar un protocolo de comunicación predefinido, y para comunicar el conjunto preseleccionado de datos de control y presentación digitales entre los dispositivos del anfitrión y el cliente a través de la trayectoria de comunicación utilizando el protocolo de comunicación; al menos un controlador del cliente dispuesto en el dispositivo de cliente y acoplado al controlador del enlace del anfitrión a través de la trayectoria de comunicaciones; y cada controlador de enlace se configura para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones, y para formar datos de una presentación digital dentro de uno o más tipos de paquetes.
27. 27. El aparato de conformidad con la reivindicación 26, caracterizado porque el controlador del anfitrión comprende una máquina de estado .
28. 28. El aparato de conformidad con la reivindicación 26, caracterizado porque el controlador del anfitrión comprende un procesador de señal de aplicación general .
29. 29. El aparato de conformidad con la reivindicación 26, caracterizado además porque comprende un paquete tipo Encabezamiento de Sub-trama al comienzo de la transferencia de los paquetes desde el anfitrión.
30. 30. El aparato de conformidad con la reivindicación 26, caracterizado porque los controladores de enlace se configuran para transferir información entre los dispositivos del anfitrión y del cliente bi-direccionalmente a través del enlace de comunicaciones .
31. 31. El aparato de conformidad con la reivindicación 30, caracterizado porque comprende el controlador del anfitrión comprende uno o más manej adores en línea diferenciales; y el receptor del cliente comprende uno o más receptores en línea diferenciales acoplados a la trayectoria de comunicación.
32. 32. El aparato de conformidad con la reivindicación 26, caracterizado además porque comprende paquetes tipo Corriente de Vídeo para los datos de tipo vídeo, y paquetes tipo Corriente de Audio para tipo audio cuando se transfieren datos desde el anfitrión hasta el cliente para su presentación al usuario del cliente.
33. 33. El aparato de conformidad con la reivindicación 26, caracterizado además porque comprende uno o más paquetes tipo Encapsulamiento de Enlace de Retorno para transferir datos desde el cliente hasta el anfitrión.
34. 34. El aparato de conformidad con la reivindicación 33, caracterizado además porque comprende al menos un paquete tipo Capacidad de Despliegue para comunicar las funciones del despliegue o la presentación desde un controlador de enlace del cliente al controlador del enlace del anfitrión.
35. 35. El aparato de conformidad con la reivindicación 26, caracterizado porque comprende los paquetes comprenden cada uno un campo de Longitud de Paquete, uno o más campos de datos de paquete, y un campo de verificación de redundancia cíclica.
36. 36. El aparato de conformidad con la reivindicación 26, caracterizado porque los controladores de enlace de anfitrión y del cliente están configurados para utilizar una de una pluralidad de modos de transferencia en cada dirección, permitiendo cada una la transferencia de un número máximo diferente de bits de datos en paralelo a través de un período de tiempo determinado; y que es capaz de ajustarse dinámicamente entre los modos de transferencia durante la transferencia de los datos .
37. 37. El aparato de conformidad con la reivindicación 26, caracterizado además porque comprende una o más de una pluralidad de paquetes para transferir información de vídeo elegida de grupo de Mapa de Color, Transferencia del Bloque de Bits, Relleno del Área de Mapa de Bits, Relleno del Patrón de Mapa de Bits, y paquetes tipo Habilitar Color Transparente.
38. 38. El aparato de conformidad con la reivindicación 26, caracterizado además porque comprende paquetes tipo Rellenador para Transferirse mediante el anfitrión para ocupar períodos de transmisión del enlace sin retorno que no tienen datos .
39. 39. El aparato de conformidad con la reivindicación 26, caracterizado porque el controlador del anfitrión está configurado para transmitir un paquete tipo Cierre de Enlace para el medio del cliente para finalizar la transferencia de datos en cualquier dirección a través de la trayectoria de comunicación.
40. 40. Un producto de programa de cómputo para utilizarlo en un sistema electrónico para transferir datos digitales a una velocidad elevada entre un dispositivo del anfitrión y un dispositivo de cliente a través de una trayectoria de comunicación para su presentación a un usuario, caracterizado porque comprende: un medio utilizable en computadora que tiene un medio de código de programa leíble en computadora contenido en el medio para provocar que un programa de aplicación se ejecute en el sistema de la computadora, un medio de código de programa leíble en computadora que comprende: un medio de código de un primer programa leíble en computadora para provocar que el sistema de computadora genere una o más de una pluralidad de estructuras de paquete predefinidas y las enlace conjuntamente para formar un protocolo de comunicación predefinido; un segundo medio de código de programa leíble en computadora para provocar que el sistema de computadora comunique un conjunto preseleccionado de datos de control y presentación digitales entre los dispositivos del anfitrión y el cliente a través de la trayectoria de comunicación utilizando el protocolo de comunicación; un tercer medio de código de programa leíble en computadora para provocar que el sistema de la computadora se acople al menos con un controlador del cliente dispuesto en el dispositivo de cliente a través de la trayectoria de comunicaciones, los controladores de enlace se configuran para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones, y para formar datos de una presentación digital dentro de uno o más tipos de paquetes de datos; y un cuarto medio de código de programa leíble en computadora para provocar que el sistema de la computadora transfiera datos en forma de paquete a través de la trayectoria de comunicaciones utilizando los controladores de enlace .
41. 41. Un aparato para transferir datos digitales a una velocidad elevada entre un dispositivo del anfitrión y un dispositivo de cliente a través de una trayectoria de comunicación para su presentación a un usuario, caracterizado porque comprende: el medio para generar una o más de una pluralidad de estructuras de paquetes predefinidas y enlazarlas conjuntamente para formar un protocolo de comunicación predefinido; el medio para comunicar un conjunto preseleccionado de datos de control y presentación digitales entre los dispositivos del anfitrión y el cliente a través de la trayectoria de comunicación utilizando el protocolo de comunicación; el medio para acoplar al menos dos controladores de enlace conjuntamente a través de la trayectoria de comunicación, uno en cada anfitrión y cliente y cada uno se configura para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones, y para formar datos de una presentación digital en uno o más tipos de paquete de datos; y el medio para transferir los datos en forma de paquetes a través de la trayectoria de comunicaciones utilizando los controladores del enlace.
42. 42. El aparato de conformidad con la reivindicación 41, caracterizado además porque comprende medios para conectar la transferencia de paquetes del anfitrión con un paquete tipo Encabezamiento de Sub-trama.
43. 43. El aparato de conformidad con la reivindicación 41, caracterizado además porque comprende medios para transferir información entre el anfitrión y el cliente bi-direccionalmente a través del enlace de comunicaciones . 4 .
44. El aparato de conformidad con la reivindicación 41, caracterizado además porque comprende medios para solicitar información de funciones de despliegue del cliente mediante un controlador de enlace del anfitrión de modo que se determina que tipo de datos en las velocidades de datos es el cliente capaz de ajustar a través de la interfaz .
45. 45. El aparato de conformidad con la reivindicación 44, caracterizado además porque comprende medios para comunicar funciones de despliegue o presentación de un controlador de enlace del cliente al controlador de enlace del anfitrión utilizando al menos un paquete tipo Capacidad de Despliegue.
46. 46. El aparato de conformidad con la reivindicación 42, caracterizado además porque comprende: el medio para negociar entre los manejadores del anfitrión y el cliente el uso de uno de una pluralidad de modo de transferencia en cada dirección, cada uno permitiendo la transferencia de diferentes números de bits máximo de datos en paralelo a través de un período de tiempo determinado; y el medio para dinámicamente ajustar los modos de transferencia durante la transferencia de datos.
47. 47. El aparato de conformidad con la reivindicación 41, caracterizado además porque comprende medios para utilizar una o más de una pluralidad de paquete para transferir información de vídeo elegida del grupo de Mapa de Color, Transferencia del Bloque de Bits, Relleno de Área del Mapa de Bits, Relleno del Patrón de Mapa de Bits, paquetes tipo Habilitar Color Transparente.
48. 48. Un procesador para utilizarlo en un sistema electrónico para transferir datos digitales a una velocidad elevada entre un dispositivo del anfitrión y un dispositivo de cliente a través de una trayectoria de comunicación, el procesador está configurado para generar una o más de una pluralidad de estructura de paquetes predefinidas y enlazarlas conjuntamente para formar un protocolo de comunicación predefinido; formar datos de una presentación digitales en uno o más tipos de paquetes de datos; comunicar un conjunto preseleccionado de datos de control y presentación digitales entre los dispositivos del anfitrión y el cliente a través de la trayectoria de comunicación utilizando el protocolo de comunicación; y transferir los datos en forma de paquetes a través de la trayectoria de comunicaciones.
49. 49. Una máquina de estado para utilizarla en la obtención de la sincronización en los datos digitales de una transferencia de un sistema electrónico a una velocidad elevada entre un dispositivo del anfitrión y un dispositivo de cliente a través de una trayectoria de comunicación, la máquina de estado está configurada para tener al menos un estado de sincronización de Estado de Tramas Asincronos, al menos dos estados de sincronización de Estados de Adquisición Síncronos, y al menos tres estados de sincronización de Estados En Sincronía.
50. 50. Una máquina de estado para utilizarla en la obtención de la sincronización de los datos digitales de una transferencia de un sistema electrónico a una velocidad elevada entre un dispositivo del anfitrión y un dispositivo de cliente a través de una trayectoria de comunicación, la máquina de estado se configura para tener al menos estados de sincronización de Estados de Adquisición Síncronos y al menos dos estados de sincronización de Estados En Sincronía.
51. 51. La máquina de estado de conformidad con la reivindicación 50, caracterizada porque una condición para desplazarse entre un Estado de Adquisición Síncrono y un primer Estado En Sincronía es detectada la presencia de un patrón de sincronización en el enlace de comunicación.
52. 52. La máquina de estado de conformidad con la reivindicación 51, caracterizada porque una segunda condición para desplazarse entre un Estado de Adquisición Síncrono y un primer Estado En Sincronía es detectada de un paquete del encabezamiento de sub-trama y un valor de CRC bueno en un límite de trama.
53. 53. La máquina de estado de conformidad con la reivindicación 50, caracterizada porque una condición para desplazarse entre un primer Estado En Sincronía y un Estado de Adquisición Síncrono es detectada la presencia de ningún patrón de sincronización o un valor de CRC malo en un límite de sub-trama.
54. 54. La máquina de estado de conformidad con la reivindicación 50, caracterizada porque una condición para desplazarse entre un primer Estado En Sincronía y un segundo Estado En Sincronía es detectar la presencia de ningún patrón de sincronización o un valor de CRC malo en un límite de sub-trama.
55. 55. La máquina de estado de conformidad con la reivindicación 50, caracterizada porque una condición para desplazarse entre un Estado de Adquisición Síncrono y un primer Estado En Sincronía es detectar la presencia de un patrón de sincronización en el enlace de comunicación es detectar la presencia de un valor de CRC de paquete bueno.
56. 56. La máquina de estado de conformidad con la reivindicación 50, caracterizada porque una condición para desplazarse entre un primer Estado En Sincronía y un Estado de Adquisición Síncrono es detectar la presencia de un valor de CRC malo en un paquete .
57. 57. Una máquina de estado para utilizarla en la obtención de la sincronización en los datos digitales de una transferencia de un sistema electrónico a una velocidad elevada entre un dispositivo del anfitrión y un dispositivo de cliente a través de una trayectoria de comunicación, la máquina de estado está configurada para tener al menos uno de los estado de sincronización de Estado de Adquisición Síncrono, y al menos dos estados de sincronización de Estados En Sincronía en donde una condición para desplazarse directamente entre un primer Estado En Sincronía y un Estado de Adquisición Síncrono es detectar la presencia de un valor de CRC malo en cualquiera de la serie de paquetes.
58. 58. La máquina de estado de conformidad con la reivindicación 57, caracterizada porque una condición para desplazarse directamente entre un primer Estado En Sincronía y un Estado de Adquisición Síncrono es detectar cuando la palabra única no ocurre en un momento que se esperaba que llegara.
59. 59. El método de conformidad con la reivindicación 26, caracterizado además porque comprende despertar un enlace de comunicación mediante el accionamiento de una línea de datos para un estado elevado durante al menos 10 ciclos de medir el tiempo e iniciar la transmisión de una señal estroboscópica como si la línea de datos fuera cero, mediante el anfitrión.
60. 60. El método de conformidad con la reivindicación 59, caracterizado además porque comprende accionar la línea de datos baja durante 50 ciclos de medir el tiempo mediante el anfitrión mientras que se continúa transmitiendo una señal estroboscópica después de que el anfitrión ha accionado la línea de datos elevada durante 150 ciclos de medir el tiempo.
61. 61. El método de conformidad con la reivindicación 59, caracterizado además porque comprende comenzar a transmitir el primer paquete del encabezamiento de la sub-trama mediante el anfitrión.
62. 62. El método de conformidad con la reivindicación 60, caracterizado además porque comprende continuar al menos 150 ciclos de medir el tiempo continuos de la línea de datos que es elevada, seguido por al menos 50 ciclos de medir el tiempo continuos de la línea de datos que es baja, mediante el cliente.
63. 63. El método de conformidad con la reivindicación 62, caracterizado además porque comprende buscar la palabra única de la primera sub-trama del cliente.
64. 64. El método de conformidad con la reivindicación 60 , caracterizado además porque comprende detener el accionamiento de la línea de datos elevada mediante el cliente después de que el cliente cuenta 70 ciclos de medir el tiempo continuos de los datos que son elevados .
65. 65. El método de conformidad con la reivindicación 64, caracterizado además porque comprende continuar otros 80 ciclos de medir el tiempo continuos de la línea de datos que es elevada para alcanzar los 150 ciclos de medir el tiempo de la línea de datos elevada mediante el cliente, y buscar los 50 ciclos de medir el tiempo de la línea de datos que es baja, y buscar la palabra única.
66. 66 . El método de conformidad con la reivindicación 26, caracterizado además porque comprende continuar el número de ciclos de medir el tiempo que ocurren hasta que uno está muestreado mediante el anfitrión, al muestrear la línea de datos en ambos de los bordes de ascendentes y descendentes durante el paquete de cronometraje de retorno.
67. 67. Un método para transferir código de error en un sistema de comunicación en el cual se transfieren datos digitales en forma de paquetes que tiene un valor de CRC entre un dispositivo del anfitrión y un dispositivo de cliente a través de una trayectoria de comunicación que comprende detectar la presencia de un error, seleccionar un código de error predeterminado que corresponde al error, y sobrescribir el valor CRC con el código.
68. 68. El método de conformidad con la reivindicación 67, caracterizado además porque comprende sobrescribir el valor CRC en paquetes sucesivos que se transfieren hasta que el error se corrige .
69. 69. Un método para transmitir datos digitales a una velocidad elevada entre un dispositivo del anfitrión y un dispositivo de cliente a través de una trayectoria de comunicación para su presentación a un usuario, caracterizado porque comprende: generar una o más de una pluralidad de estructuras de paquete predefinidas cada una incluye al menos un campo CRC, y enlazarlos conjuntamente para formar un protocolo de comunicación predefinido; comunicar un conjunto preseleccionado de datos de control y presentación digitales entre los dispositivos del anfitrión y el cliente a través de la trayectoria de comunicación utilizando el protocolo de comunicación; acoplar al menos un controlador del enlace del cliente que reside en el dispositivo del anfitrión al dispositivo de cliente a través de la trayectoria de comunicaciones, el controlador del enlace del anfitrión se configura para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones, y para formar datos de una presentación digital en uno o más tipos de paquetes de datos ; transferir los datos en forma de paquetes a través de la trayectoria de comunicaciones utilizando los controladores de enlace; detectar la presencia de un error para el enlace de comunicación; seleccionar un código de error predeterminado que corresponde al error; y sobrescribir el valor CRC con el código.
70. 70. El método de conformidad con la reivindicación 69, caracterizado además porque comprende sobrescribir el valor CRC en paquetes sucesivos que se transfieren hasta que el error se corrige.