MXPA06006012A - Interfase de indice de datos alto con sincronizacion de enlace mejorada. - Google Patents

Abstract

Una interfase de datos para transferir datos digitales y un aparato central y un cliente en una trayectoria de comunicacion que utilizan estructuras de paquetes enlazadas juntas para formar un protocolo de comunicacion para comunicar un conjunto previamente seleccionado de datos de control digital y de presentacion. El protocolo de senal es utilizado por los controladores de enlace configurados para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones y para formar datos digitales en uno o mas tipos de paquetes de datos, residiendo por lo menos uno en el aparato central y que esta siendo conectado al cliente a traves de la trayectoria de comunicaciones. La interfase proporciona un mecanismo efectivo en costos, de baja potencia, bidireccional, de transferencia de datos de alta velocidad en un enlace de datos del tipo de "serie" de rango corto, el cual se presta para la implementacion con conectores miniatura y cables flexibles delgados, los cuales son especialmente utiles para conectar elementos de pantalla, tales como micropantallas que se pueden usar en computadoras portatiles y aparatos de comunicacion inalambricos.

Description

INTERFASE DE ÍNDICE DE DATOS ALTO CON SINCRONIZACIÓN DE ENLACE MEJORADA Reclamación de prioridad conforme a 35 U.S.C. §119 La presente solicitud de patente reclama prioridad a la Solicitud Provisional No. 60/525,270 titulada "S itchable Threshold Differential Interface" presentada el 25 de noviembre de 2003 y cedida al cesionario de la presente y por este medio incorporada expresamente como referencia en la presente .

Campo del Invento Las modalidades de la invención en esta descripción se refieren a un protocolo de señales digitales y proceso para comunicar y transferir señales entre un aparato central y un aparato cliente a Índices de datos altos. Más específicamente, la descripción se refiere a una técnica para transferir señales digitales multimedia y otros tipos de señales digitales de un aparato central o controlador a un aparato cliente para presentación o visualización a un usuario final gue usa un mecanismo de transferencia de índice de datos alto de baja potencia gue tiene aplicaciones de aparato internas y externas .

Antecedentes del Invento Las computadoras, productos relacionados con juegos electrónicos y diversas tecnologías de video (por ejemplo, DVDs y VCRs de alta definición) han avanzado de manera significativa en los últimos años para brindar presentación de imágenes fijas, de video, de video a la carta y de gráficos de resolución cada vez más alta, aun cuando incluyen algunos tipos de texto, a usuarios finales de tal equipo. Estos avances a su vez exigieron el uso de dispositivos de visualización electrónicos de resolución más alta tales como monitores de video de alta definición, monitores HDTV o elementos de proyección de imágenes especializados. Combinar tales imágenes visuales con datos de audio de alta definición o de alta calidad, como por ejemplo, al usar reproducción de sonido tipo CD, DVDs, sonido envolvente y otros aparatos que tienen también salidas de señal de audio asociadas, se usa para crear una experiencia multimedia más real, rica en contenido o genuina para un usuario final. Además, los sistemas de sonido de alta calidad y altamente móviles y mecanismos de transporte de música, tales como reproductores de MP3, se han desarrollado para presentaciones solamente de audio para usuarios finales. Esto ha dado por resultado expectativas incrementadas para los usuarios típicos de aparatos electrónicos comerciales, desde computadoras hasta televisores e incluso teléfonos, que están ahora acostumbrados a una salida de alta calidad o de primera calidad, y la esperan. En un escenario de presentación de video típico, que involucra un producto de electrónica, los datos de video son típicamente transferidos usando técnicas actuales a un índice que se podría llamar mejor lento o medio, encontrándose en el orden de uno a decenas de kilobits por segundo. Estos datos son ya sea almacenados en una memoria intermedia o son almacenados en dispositivos de memoria transitoria o a largo plazo, para reproducción retardada (posterior) en un dispositivo de visualización deseado. Por ejemplo, las imágenes pueden ser transferidas "a través de" o usando la Internet con el uso de 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 al representar digitalmente una imagen. Una transferencia similar puede tener lugar usando aparatos inalámbricos tales como computadoras portátiles equipadas con módems inalámbricos, o Asistentes Personales de Datos (PDAs) o teléfonos inalámbricos . Una vez recibidos, los datos son almacenados localmente en elementos, circuitos o dispositivos de memoria, tales como RAM o memoria flash, 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 empezar relativamente rápido o ser presentada con un retardo a más largo plazo. Esto es, en algunos casos, la presentación de imágenes toma en cuenta cierto grado de reproducción en tiempo real para imágenes muy pequeñas o de baja resolución que no requieren muchos datos, o que usan algún tipo de almacenamiento en una memoria intermedia, de manera que después de un pequeño retardo, algo del material sea presentado mientras más material está siendo transferido. Siempre y cuando no haya interrupciones en el enlace de transferencia, o interferencia de otros sistemas o usuarios con relación al canal de transferencia que está siendo usado, una vez que la presentación empieza la transferencia es razonablemente transparente para el usuario final del dispositivo de visualización. Naturalmente, donde múltiples usuarios comparten una sola trayectoria de comunicación, tal como una conexión de Internet alámbrica, las transferencias pueden ser interrumpidas o más lentas de lo deseado.

Los datos usados para crear ya sea imágenes fijas o video en movimiento son con frecuencia comprimidos usando una de varias técnicas bien conocidas tales como aquellas especificadas por el Grupo Unificado de Expertos Fotográficos (JPEG) , el Grupo de Expertos en Imágenes en Movimiento (MPEG) y otras organizaciones de estándares bien conocidas o compañías en las industrias de medios, computadoras y comunicaciones para acelerar la transferencia de datos en un enlace de comunicación. Esto permite transferí imágenes o datos más rápido usando un número más pequeño de bits para transferir una cantidad cada de información. Una vez que los datos son transferidos a un aparato "local" como por ejemplo, una computadora que tiene un mecanismo de almacenamiento tal como una memoria, o elementos de almacenamiento magnéticos u ópticos, u otros aparatos receptores, la información resultante es descomprimida (o reproducida con el uso de reproductores decodificadores especiales) , y decodificada si es necesario, y es preparada para una presentación apropiada con base en los elementos de resolución y de control de presentación disponibles correspondientes. Por ejemplo, una resolución de video de computadora típica en términos de una resolución de pantalla de X por Y pixeles típicamente varía de tan bajo como 480 x 640 pixeles, a través de 600 x 800 a 1024 x 1024, aunque una variedad de otras resoluciones son generalmente posibles, ya sea como se desee o se necesite . La presentación de imágenes es afectada también por el contenido de imagen y la capacidad de controladores de video dados de manipular la imagen en términos de ciertos niveles de color o profundidad de color (bits por pixel usados para generar colores) e intensidades definidos previamente, y cualesquier bits suplementarios adicionales que sean empleados . Por ejemplo, una presentación de computadora típica anticiparía entre aproximadamente 8 y 32, o más, bits por pixel para representar diversos colores (matices y tonos), aunque se encuentran otros valores. A partir de los valores anteriores, se puede ver que una imagen de pantalla dada va a requerir la transferencia de entre 2.45 Megabits (Mb) y aproximadamente 33.55 Mb de datos en el rango de las resoluciones y profundidad típicas más bajas a las más altas, respectivamente. Cuando se ven imágenes de tipo video o en movimiento a un índice de 30 cuadros por segundo, la cantidad de los datos requerida es aproximadamente 73.7 a 1,006 Megabits de datos por segundo (Mbps) , o aproximadamente 9.21 a 125.75 Megabytes por segundo (MBps) . Además, se puede desear presentar datos de audio junto con imágenes, tal como para una presentación multimedia, o como una presentación de audio de alta resolución aparte, tal como música de calidad CD. Señales adicionales que se relacionan con comandos interactivos, controles o señales se pueden emplear también. Cada una de estas opciones añade aún más datos que van a ser transferidos. Además, las técnicas de transmisión más nuevas que implican televisión de Alta Definición (HD) y grabaciones de películas pueden añadir aún más datos e información de control. En cualquier caso, cuando se desea transferir datos de imagen de alta calidad o de alta resolución e información de audio de alta calidad o señales de datos a un usuario final para crear una experiencia rica en contenido, se requiere un enlace de índice de transferencia de datos alto entre los elementos de presentación y la fuente o aparato central que está configurado para proveer dichos tipos de datos . Los índices de datos de aproximadamente 115 Kilobytes (KBps) o 920 Kilobits por segundo (Kbps) pueden ser manejados de manera rutinaria por algunas interfases serie modernas. Otras interfases como por ejemplo, interfases serie USB, pueden admitir transferencias de datos a índices tan altos como 12 MBps, y transferencias a alta velocidad especializadas tales como aquellas configuradas con el uso del estándar 1394 del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) , pueden ocurrir a índices en el orden de 100 a 400 MBps. Desafortunadamente, estos índices carecen de los índices de datos altos deseados antes discutidos los cuales son contemplados para usar con futuros aparatos de datos inalámbricos y otros servicios para proveer señales de alta resolución, ricas en contenido, de salida para impulsar pantallas de video o aparatos de audio portátiles. Esto incluye computadoras para negocios y otras presentaciones, aparatos de juegos, y así sucesivamente. Además, estas interfases requieren el uso de una cantidad significativa de aparato central o sistema y software de cliente para operar. Sus pilas de protocolo de software crean también una cantidad grande en forma indeseable de sobrecarga, en especial donde se contemplan aparatos inalámbricos móviles o aplicaciones de teléfono. Tales aparatos tienen graves limitaciones de memoria y de consumo de potencia, así como capacidad informática ya puesta a prueba. Además, algunas de estas interfases utilizan cables voluminosos que son demasiado pesados y nada satisfactorios para aplicaciones móviles con orientación altamente estética, conectores complejos que añaden costo, o simplemente consumen demasiada potencia. Existen otras interfases conocidas tales como las interfases de Adaptador de Gráficos de Video Analógico (VGA) , Video Digital Interactivo (DVI) o Interfase de Video Gigabit (GVIF) . Las primeras dos de éstas son interfases de tipo paralelo las cuales procesan datos a índices de transferencia más altos, pero también emplean cables pesados y consumen grandes cantidades de potencia, en el orden de varios wats. Ninguna de estas características se puede usar con aparatos electrónicos portátiles. Incluso la tercera interfase consume demasiada potencia y utiliza conectores costosos o voluminosos . Para algunas de las interfases anteriores y otros sistemas/protocolos de datos de índice muy alto o mecanismos de transferencia asociados con transferencias de datos para equipo de computadora de instalación fija, existe otra desventaja importante. Admitir los índices de transferencia de datos deseados requiere también cantidades sustanciales de potencia y/u operación a altos niveles de corriente. Esto reduce considerablemente la utilidad de tales técnicas para productos orientados al consumidor altamente móviles .

En general, el admitir tales índices de transferencia de datos usando alternativas tales como conexiones de tipo de fibra óptica y elementos de transferencia, requiere también un número de convertidores y elementos adicionales que introducen mucha más complejidad y costo de lo que se desea para un producto orientado al consumidor realmente comercial. Además de la naturaleza generalmente costosa de los sistemas ópticos hasta ahora, sus requerimientos de potencia y complejidad previene el uso general para aplicaciones ligeras, de baja potencia y portátiles. Lo que ha estado faltando en la industria para aplicaciones portátiles, inalámbricas o móviles, es una técnica para proveer una experiencia de presentación de alta calidad, ya sea que se base en audio, video o multimedia, para usuarios finales altamente móviles. Esto es, al usar computadoras portátiles, teléfonos inalámbricos, PDAs, u otros aparatos o equipo de comunicación altamente móviles, los sistemas o aparatos de presentación de video y audio actuales que se usan simplemente no pueden entregar resultados al nivel de alta calidad deseado. Con frecuencia, la calidad percibida que falta es el resultado de índices de datos altos que no se pueden obtener necesarios para transferir los datos de presentación de alta calidad.

Esto puede incluir tanto transferir a aparatos externos más eficientes, avanzados o con muchas características para presentación a un usuario final, como transferir entre aparatos centrales y clientes internos a aparatos portátiles tales como computadoras, máquinas de juegos, y aparatos inalámbricos tales como teléfonos móviles . En este último caso, se ha progresado a grandes pasos en la adición de pantallas de video internas de resolución cada vez más alta y otros dispositivos de entrada y/o salida especializados y conexiones a aparatos inalámbricos como los llamados teléfonos de tercera generación; y a las llamadas computadoras portátiles. No obstante, los buses de datos internos y conexiones pueden incluir puenteo al hacer girar o deslizar estructuras de bisagra o estructuras de tipo bisagra que montan o conectan pantallas de video u otros elementos al alojamiento principal donde residen el aparato central y/u otros diversos elementos de control y componentes de salida. Resulta muy difícil construir interfases de transferencias de datos de alto rendimiento usando las técnicas anteriores que pueden requerir hasta 90 conductores o más, para lograr el rendimiento deseado en, supongamos un teléfono inalámbrico, como un ejemplo. Esto presenta muchos problemas de fabricación, de costo prohibitivo y confiabilidad que constituyen un desafío y que se deben superar. Tales problemas y requerimientos se están viendo también en instalaciones de ubicación fija donde aparatos de tipo de comunicación o cómputo, como un ejemplo, son agregados a electrodomésticos y otros artefactos caseros para proporcionar capacidades de datos avanzadas, conexiones a Internet y conexiones de transferencia de datos, o entretenimiento incorporado. Otro ejemplo serían los aviones y camiones donde pantallas de presentación de video y audio individuales son montadas en los respaldos de los asientos. Sin embargo, en estas situaciones con frecuencia resulta más conveniente, eficiente y fácilmente útil tener los elementos principales de control de almacenamiento, procesamiento o comunicación ubicados a una distancia de las pantallas visibles o salidas de audio con un enlace o canal de interconexión para la presentación de información. Este enlace necesitará manejar una cantidad significativa de datos para lograr el rendimiento deseado, como se discute anteriormente. Por lo tanto, es necesario un nuevo mecanismo de transferencia para incrementar el rendimiento de datos entre los aparatos centrales que proveen los datos y aparatos o elementos de pantalla de cliente que presentan un resultado a los usuarios finales . Los solicitantes han propuesto tales mecanismos de transferencia nuevos en la solicitud de patente de U.S. serie No. 10/020,520, ahora patente de U.S. No. 6,760,772 expedida el 6 de julio de 2004 a Quizen et al. y solicitud de patente de U.S. copehdiente serie No. 10/236,657, presentada el 6 de septiembre de 2002, ambas tituladas "Generating and implementing a communication protocol and interface for high data rate signal transfer", las cuales son cedidas al cesionario de la presente invención y se incorporan en la presente como referencia. Igualmente, la solicitud de U.S. copendiente serie No. 10/860,116 presentada el 2 de junio de 2004, titulada "Generating and implementing a signal protocol and interface for higher data rates". Las técnicas discutidas en estas solicitudes pueden mejorar considerablemente el índice de transferencia para grandes cantidades de datos en señales de datos a alta velocidad. No obstante, las demandas de índices de datos siempre crecientes, especialmente con relación a presentaciones de video, continúan creciendo. Incluso con otros desarrollos actuales en tecnología de señales de datos, existe aún la necesidad de esforzarse por alcanzar índices de transferencia aún más rápidos, eficiencias de enlace de comunicación mejoradas y enlaces de comunicación más poderosos. Por ende, existe una necesidad continua de desarrollar un mecanismo de transferencia nuevo o mejorado que es necesario para incrementar el rendimiento de datos entre el aparato central y el aparato cliente.

Sumario del Invento La desventaja anterior, y otras, existentes en la técnica son abordadas por las modalidades de la invención en la cual se han desarrollado un nuevo protocolo y medio de transferencia de datos, un método y un mecanismo para transferir datos entre un aparato central y un aparato cliente receptor a índices de velocidad altos. Las modalidades para la invención están dirigidas a una Inferíase Digital de Datos Móviles (MDDI) para transferir datos digitales a un índice alto entre un aparato central y un aparato cliente en 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 previamente seleccionado de datos de control digital y de presentación entre el aparato central y los aparatos cliente. El protocolo de comunicaciones de señal o capa de enlace es utilizado por una capa física de controladores, receptores o excitadores de enlace de aparato central o cliente. Por lo menos un controlador o excitador de enlace que reside en el aparato central está acoplado al aparato 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 datos de presentación digitales en uno o más tipos de paquetes de datos. La interfase provee transferencia bidireccional de información entre el aparato central y el cliente, que puede residir dentro de un alojamiento general común o estructura de soporte. La implementación es en general de naturaleza toda digital con excepción de excitadores y receptores diferenciales los cuales pueden ser fácilmente implementados en un chip CMOS digital, requiere 6 señales y opera a casi cualquier índice de datos que sea conveniente para el diseñador del sistema. El protocolo físico y de capa de enlace simple lo hace fácil de integrar y esta simplicidad más un estado de hibernación permite que el sistema portátil tenga un consumo de potencia del sistema muy bajo. Para ayudar al uso y la aceptación, la interfase añadirá muy poco al costo de un aparato, tendrá en cuenta un consumo de muy poca potencia mientras es capaz de accionar pantallas a través de la interfase usando voltajes de batería estándar y puede admitir dispositivos que tienen un factor de forma de bolsillo. La interfase es escalable para soportar resoluciones más allá de HDTV, soporta video en estéreo simultáneo y audio 7.1 a un dispositivo de visualización, realiza actualizaciones condicionales a cualquier región de pantalla y soporta múltiples tipos de datos en ambas direcciones . En otros aspectos de las modalidades de la invención, por lo menos un controlador, receptor, dispositivo o excitador de enlace de cliente está dispuesto en el aparato cliente y está acoplado al aparato central a través de la trayectoria o enlace de comunicaciones . El controlador de enlace de cliente está configurado también para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones y para formar datos de presentación digitales en uno o más tipos de paquetes de datos . En general, el controlador de aparato central o de enlace emplea una máquina de estados para procesar paquetes de datos usados en comandos o ciertos tipos de preparación de señales y procesamiento de indagaciones, pero puede usar un procesador de propósito general más lento para manipular datos y algunos de los paquetes menos complejos usados en el protocolo de comunicación. El controlador de aparato central comprende uno o más excitadores de línea diferenciales; mientras que el receptor de cliente comprende uno o más receptores de línea diferenciales acoplados a la trayectoria de comunicación . Los paquetes están agrupados juntos dentro de cuadros de medios que son comunicados entre los aparatos central y cliente que tienen una longitud fija previamente definida con un número predeterminado de paquetes que tienen diferentes longitudes variables. Cada uno de los paquetes comprende un campo de longitud de paquete, uno o más campos de datos de paquete y un campo de verificación de redundancia cíclica. Un Paquete de Cabecera de Subcuadro es transferido o colocado al principio de las transferencias de otros paquetes desde el controlador de enlace de aparato central. Uno o más paquetes de tipo Flujo de Video y paquetes de tipo Flujo de Audio son usados por el protocolo de comunicaciones para transferir datos de tipo video y datos de tipo audio, respectivamente, del aparato central al cliente en un enlace hacia adelante para presentación a un usuario de aparato cliente. Uno o más paquetes de tipo Encapsulación de Enlace Inverso son utilizados por el protocolo de comunicaciones para transferir datos del aparato cliente al controlador de enlace de aparato central. Estas transferencias en algunas modalidades incluyen la transferencia de datos desde controladores internos que tienen por lo menos un dispositivo de MDDI hasta pantallas de vídeo internas . Otras modalidades incluyen transferencia a sistemas de sonido internos y transferencias desde diversos dispositivos de entrada entre los que se incluyen palancas de mando y teclados complejos hasta aparatos centrales internos. Paquetes de tipo relleno son generados por el controlador de enlace de aparato central para ocupar períodos de transmisión de enlace hacia adelante que no tienen datos . Una pluralidad de otros paquetes es usada por el protocolo de comunicaciones para transferir información de video. Tales paquetes incluyen paquetes tipo Mapa de Colores, Transferencia de Bloque de Bits, Relleno de Área de Mapa de Bits, Relleno de Patrón de Mapa de Bits y Habilitación de Color Transparente. Paquetes de tipo Flujo Definido por el Usuario son utilizados por el protocolo de comunicaciones para transferir datos definidos por el usuario de la interfase. Paquetes tipo Datos de Teclado y Datos de Dispositivo Señalador son usados por el protocolo de comunicaciones para transferir datos a o desde dispositivos de entrada de usuario asociados con dicho aparato cliente. Un paquete tipo Interrupción de Enlace es usado por el protocolo de comunicaciones para terminar la transferencia de datos en cualquiera de las dos direcciones en 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, se pueden usar cables o conductores impresos, como se desee, residiendo algunos en sustratos flexibles. Las solicitudes de controlador de enlace de aparato central muestran información de capacidades del aparato cliente a fin de determinar qué tipo de datos e índices de datos a dicho cliente es capaz de admitir a través de la interfase. El controlador de enlace de cliente comunica capacidades de visualización o presentación al controlador de enlace de aparato central usando por lo menos un paquete tipo Capacidad de Cliente . Múltiples modos de transferencia son utilizados por el protocolo de comunicaciones permitiendo cada uno la transferencia de diferentes números máximos de bits de datos en paralelo en un periodo de tiempo dado, donde cada modo se puede seleccionar por medio de negociación entre los controladores de enlace de aparato central y cliente. Estos modos de transferencia son ajustables en forma dinámica durante la transferencia de datos y no se necesita usar el mismo modo en el enlace inverso como se usa en el enlace hacia adelante. En otros aspectos de algunas modalidades de la invención, el aparato central comprende un aparato de comunicaciones inalámbrico, como por ejemplo, un teléfono inalámbrico, un PDA inalámbrico o una computadora portátil que tiene un módem inalámbrico dispuesto en la misma. Un aparato cliente típico comprende una pantalla de video portátil tal como un aparato de micropantalla y/o un sistema de presentación de audio portátil. Además, el aparato central puede usar medios o elementos de almacenamiento para almacenar datos de presentación o datos multimedia que se van a transferir para ser presentados a un usuario de aparato cliente . En otros aspectos de algunas modalidades, el aparato central comprende un controlador o dispositivo de control de enlace de comunicación con excitadores como se describe más adelante que reside dentro de un aparato electrónico portátil como por ejemplo, un aparato de comunicaciones inalámbrico, tal como un teléfono inalámbrico, un PDA inalámbrico o una computadora portátil. Un aparato cliente típico en esta configuración comprende un circuito o circuito integrado o módulo de cliente acoplado al aparato central y residiendo dentro del mismo aparato, y a una pantalla de video interna tal como una pantalla de alta resolución para un teléfono móvil, y/o un sistema de presentación de audio portátil, o en el alternativo algún tipo de sistema o dispositivo de entrada.

Breve Descripción de los Dibujos Otras características y ventajas de la invención, así como la estructura y operación de diversas modalidades de la invención, se describen en detalle a continuación con referencia a los dibujos adjuntos. En los dibujos, números de referencia similares generalmente indican elementos o pasos de procesamiento idénticos, funcionalmente similares y/o estructuralmente similares, y el dibujo en el cual aparece primero un elemento es indicado por el (los) dígito (s) de extrema izquierda en el número de referencia. La figura 1A ilustra un ambiente básico en el cual las modalidades de la invención pudieran operar incluyendo el uso de un aparato de micropantalla, 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 pudieran operar incluyendo el uso de un aparato de micropantalla o un proyector, y elementos de presentación de audio usados junto con un transceptor inalámbrico. La figura 1C ilustra un ambiente básico en el cual las modalidades de la invención pudieran operar incluyendo el uso de dispositivos de pantalla o de presentación de audio internos usados en una computadora portátil . La figura ID ilustra un ambiente básico en el cual las modalidades de la invención pudieran operar incluyendo el uso de elementos de pantalla o de presentación de audio internos usados en un transceptor inalámbrico. La figura 2 ilustra el concepto general de una Inferíase de Datos Digitales Móviles con una interconexión de aparato central y cliente. La figura 3 ilustra la estructura de un paquete útil para realizar transferencias de datos de un aparato cliente a un aparato central . La figura 4 ilustra el uso de un controlador de enlace de MDDI y los tipos de señales que pasan entre un aparato central y un cliente en los conductores de enlace de datos físicos para una interfase de Tipo 1. La figura 5 ilustra el uso de un controlador de enlace de MDDI y los tipos de señales que pasan entre un aparato central y un cliente en los conductores de enlace de datos físicos para interfases Tipos 2, 3 y 4.

La figura 6 ilustra la estructura de cuadros y subcuadros utilizados para implementar el protocolo de interfase . La figura 7 ilustra la estructura general de paquetes utilizados para implementar el protocolo de interfase . La figura 8 ilustra el formato de un Paquete de Cabecera de Subcuadro. La figura 9 ilustra el formato y contenido de un Paquete de Relleno. La figura 10 ilustra el formato de un Paquete de Flujo de Video. Las figuras 11A-11E ilustran el formato y contenido para el Descriptor de Formato de Datos de Video usado en la figura 10. La figura 12 ilustra el uso de formatos empaquetados y desempaquetados para datos . La figura 13 ilustra el formato de un Paquete de Flujo de Audio. La figura 14 ilustra el uso de formatos PCM alineados por bytes y empaguetados para datos . La figura 15 ilustra el formato de un Paquete de Flujo Definido por el Usuario. La figura 16 ilustra el formato de un Paquete de Mapa de Colores . La figura 17 ilustra el formato de un Paquete de Encapsulación de Enlace Inverso. La figura 18 ilustra el formato de un Paquete de Capacidad del cliente. La figura 19 ilustra el formato de un Paquete de Datos de Teclado. La figura 20 ilustra el formato de un Paquete de Datos de Dispositivo Señalador. 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 y Estado de Cliente. La figura 23 ilustra el formato de un Paquete de Transferencia de Bloque de Bits . La figura 24 ilustra el formato de un Paquete de Relleno de Área de Mapa de Bits . La figura 25 ilustra el formato de un Paquete de Relleno de Patrón de Mapa de Bits . La figura 26 ilustra el formato de un Paquete de Canal de Datos de Enlace de Comunicación. La figura 27 ilustra el formato de un Paquete de Solicitud de Cesión de Tipo de Inferíase.

La figura 28 ilustra el formato de un Paquete de Confirmación de Tipo de Inferíase. La figura 29 ilustra el formato de un Paquete de Cesión de Tipo de Ejecución. La figura 30 ilustra el formato de un Paquete de Habilitación de Canal de Audio Hacia Adelante . La figura 31 ilustra el formato de un Paquete de índice de Muestra de Audio Inverso. La figura 32 ilustra el formato de un Paquete de Sobrecarga de Protección de Contenido Digital. La figura 33 ilustra el formato de un Paquete de Habilitación de Color Transparente . La figura 34 ilustra el formato de un Paquete de Medición de Retardo de Ida y Vuelta. La figura 35 ilustra la temporización de eventos durante el Paquete de Medición de Retardo de Ida y Vuelta. La figura 36 ilustra una implementación de muestra de un generador y comprobador de CRC útiles para implementar la invención. La figura 37A ilustra la temporización de señales de CRC para el aparato de la figura 36 al enviar paquetes de datos . La figura 37B ilustra la temporización de señales de CRC para el aparato de la figura 36 al recibir paquetes de datos . La figura 38 ilustra pasos de procesamiento para una solicitud de servicio típica sin contienda. La figura 39 ilustra pasos de procesamiento para una solicitud de servicio típica afirmada después de que la secuencia de reinicio de enlace ha comenzado, contendiendo con el inicio de enlace. La figura 40 ilustra cómo se puede transmitir una secuencia de datos usando la codificación DATOS-STB. La figura 41 ilustra circuitería útil para generar las señales DATOS y STB a partir de datos de entrada en el aparato central y después recuperar los datos en el cliente . La figura 42 ilustra excitadores y resistores de terminación útiles para implementar una modalidad. Las figuras 43A, 43B y 43C ilustran pasos y niveles de señal empleados por un cliente para asegurar el servicio desde el aparato central y por el aparato central para proveer dicho servicio. La figura 44 ilustra un espacio relativo entre las transiciones en los DatosO, otras líneas de datos (DatosX) y las líneas de señal de validación (Stb) . La figura 45 ilustra la presencia de un retardo en respuesta que puede ocurrir cuando un aparato central inhabilita el excitador de aparato central después de transferir un paquete. La figura 46 ilustra la presencia de un retardo en respuesta que puede ocurrir cuando un aparato central habilita el excitador de aparato central para transferir un paquete. La figura 47 ilustra la relación en la entrada de receptor de aparato central entre la temporización de los datos que están siendo transferidos y los flancos anterior y posterior de los pulsos de señal de validación. La figura 48 ilustra características de conmutación y el retardo de salida de cliente correspondiente desarrollado por la temporización de datos inversa. La figura 49 ilustra un diagrama de nivel alto de pasos y condiciones de procesamiento de señal mediante los cuales se puede implementar la sincronización usando una máquina de estados. La figura 50 ilustra cantidades típicas de retardo encontradas para procesamiento de señales en las trayectorias hacia adelante e inversa en un sistema gue emplea la MDDI . La figura 51 ilustra la medición de retardo de ida y vuelta marginal. La figura 52 ilustra cambios de índice de datos de Enlace Inverso.

La figura 53 ilustra una representación gráfica de valores del Divisor de índice Inverso contra índice de datos de enlace hacia adelante. Las figuras 54A y 54B ilustran pasos realizados en la operación de una interfase. La figura 55 ilustra una visión general de los paquetes de procesamiento de dispositivo de interfase. La figura 56 ilustra el formato de un Paquete de Enlace Hacia Adelante. La figura 57 ilustra valores típicos para retardo de propagación y sesgo en una interfase de Enlace Tipo 1. La figura 58 ilustra Datos, Stb y Temporización de Recuperación de Reloj en un Enlace Tipo 1 para procesamiento de señal ejemplar a través de la interfase . La figura 59 ilustra valores típicos para retardo de propagación y sesgo en interfases de Enlace Tipo 2, Tipo 3 o Tipo . Las figuras 60A, 60B y 60C ilustran diferentes posibilidades para la temporización de dos señales de datos y MDDI_Stb con respecto una de la otra, que son ideal, temprana y tardía, respectivamente. La figura 61 ilustra conectores ejemplares de asignaciones de terminales de interfase utilizados con una interfase Tipo-I/Tipo 2. Las figuras 62A y 62B ilustran posibles formas de onda MDDI_Datos y MDDI_Stb para Interfases tanto Tipo 1 como Tipo 2, respectivamente. La figura 63 ilustra un diagrama de alto nivel de pasos y condiciones de procesamiento de señal alternativos mediante los cuales se puede implementar la sincronización usando una máquina de estados. La figura 64 ilustra temporización relativa ejemplar entre una serie de ciclos de reloj y la temporización de diversos bits de paquetes de enlace inverso y valores de divisor. La figura 65 ilustra procesamiento de transferencia de código de error ejemplar. La figura 66 ilustra un aparato útil para procesamiento de transferencia de código de error. La figura 67A ilustra un procesamiento de transferencia de código de error para sobrecarga de código. La figura 67B ilustra un procesamiento de transferencia de código de error para recepción de código. La figura 68A ilustra pasos de procesamiento para una activación iniciada por el aparato central. La figura 68B ilustra pasos de procesamiento para una activación iniciada por el cliente. La figura 68C ilustra pasos de procesamiento para activación iniciada por el aparato central y el cliente con contienda. La figura 69 ilustra el formato de un Paquete de Característica VCP de Solicitud. 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 Paquete de Característica VCP de Ajuste. La figura 73 ilustra el formato de un Paquete de Parámetro Válido de Solicitud. La figura 74 ilustra el formato de un Paquete de Respuesta de Parámetro Válido. La figura 75 ilustra el formato de un Paquete de Capacidad de Imagen de Alfa-Cursor. La figura 76 ilustra el formato de un Paquete de Mapa de Transparencia de Alfa-Cursor. La figura 77 ilustra el formato de un Paquete de Desplazamiento de Imagen de Alfa-Cursor. La figura 78 ilustra el formato de un Paquete de Flujo de Video de Alfa-Cursor. La figura 79 ilustra el formato de un Paquete de Capacidad de Flujo de Video Escalado. La figura 80 ilustra el formato de un Paquete de Configuración de Flujo de Video Escalado. La figura 81 ilustra el formato de un Paquete de Confirmación de Flujo de Video Escalado. La figura 82 ilustra el formato de un Paquete de Flujo de Video Escalado. La figura 83 ilustra el formato de un Paquete de Estado Específico de 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 Retardo de Procesamiento de Paquete. La figura 85B ilustra el formato de un elemento de Lista de Parámetros de Retardo. La figura 86 ilustra el formato de un Paquete de Capacidad de Pantalla Personal. La figura 87A ilustra el formato de un Paquete de Informe de Errores de Cliente. La figura 87B ilustra el formato de un elemento de Lista de Informe de Errores . La figura 88 ilustra el formato de un Paquete de Identificación de Cliente. La figura 89 ilustra el formato de un Paquete de Capacidad de Pantalla Alterna.

La figura 90 ilustra el formato de un Paquete de Acceso a Registros. Las figuras 91A-91C ilustran el uso de dos memorias intermedias de pantalla para reducir artefactos visibles. La figura 92 ilustra dos memorias intermedias con renovación de pantalla más rápido que la transferencia de imagen . La figura 93 ilustra dos memorias intermedias con renovación de pantalla más lento que la transferencia de image . La figura 94 ilustra dos memorias intermedias con renovación de pantalla mucho más rápido que la transferencia de imagen. La> figura 95 ilustra tres memorias intermedias con renovación de pantalla más rápido que la transferencia de imagen . La figura 96 ilustra tres memorias intermedias con renovación de pantalla más lento que la transferencia de imagen . La figura 97 ilustra una memoria intermedia con renovación de pantalla más rápido que la transferencia de imagen . La figura 98 ilustra una conexión aparato central-cliente vía cadena margarita y concentrador.

La figura 99 ilustra aparatos cliente conectados vía una combinación de concentradores y cadenas margarita. La figura 100 ilustra un mapa de colores. La figura 101 ilustra análisis de corriente de fugas .

Descripción Detallada del Invento I . Visión general Un intento general de la invención es proveer una Inferíase Digital de Visualización Móvil (MDDI) , como se discute más adelante, que da por resultado o provee un mecanismo efectivo en costos, de bajo consumo de potencia, de transferencia que permite una transferencia de datos a alta velocidad o a muy alta velocidad en un enlace de comunicación de rango corto entre un aparato central y un aparato cliente, tal como un elemento de pantalla, usando un tipo "serie" de enlace o canal de datos . Este mecanismo se presta a implementación con conectores miniatura y cables flexibles delgados que son especialmente útiles para conectar (a un alojamiento o marco de soporte) elementos de pantalla internos o dispositivos de entrada a un controlador central, o elementos o dispositivos de pantalla externos tales como micropantallas que se pueden usar (anteojos o proyectores) en computadoras portátiles, aparatos de comunicación inalámbricos o aparatos de entretenimiento . Aunque los términos Móvil y Pantalla están asociados con el nombre del protocolo, se debe entender que esto es para conveniencia solamente en términos de tener un nombre estándar que sea comprendido fácilmente por los expertos en la técnica que trabajan con la interfase y protocolo. No obstante, se comprenderá fácilmente después de una revisión de las modalidades que se presentan más adelante, que muchas aplicaciones relacionadas no móviles y que no son de visualización se beneficiarán de la aplicación de este protocolo y estructura de interfase resultante y la etiqueta MDDI no pretende implicar limitación alguna a la naturaleza o utilidad de la invención o sus varias modalidades . Una ventaja de las modalidades de la invención es que se provee una técnica para transferencia de datos que es de baja complejidad, bajo costo, tiene alta confiabilidad, se adapta bien dentro del ambiente de uso y es muy robusta, aunque sigue siendo muy flexible.

Las modalidades de la invención se pueden usar en una variedad de situaciones para comunicar o transferir grandes cantidades de datos, generalmente para aplicaciones de audio, video o multimedia de un aparato central o dispositivo fuente donde tales datos son generados o almacenados, a un dispositivo de pantalla o presentación de cliente a un índice alto. Una aplicación típica, la cual se discute más adelante, es la transferencia de datos ya sea de una computadora portátil o un teléfono o módem inalámbrico a un dispositivo de presentación visual como por ejemplo, una pequeña pantalla de video o un aparato de micropantalla que se puede usar, como por ejemplo, en forma de anteojos o cascos que contienen pequeños lentes y pantallas de proyección, o de un aparato central a aparato cliente dentro de tales componentes . Esto es, de un procesador a una pantalla interna u otro elemento de presentación, así como de diversos dispositivos de entrada internos o externos que emplean un cliente a un aparato central ubicado internamente (colocado dentro del mismo alojamiento o estructura de soporte del aparato) . Las características o atributos de la MDDI son tales que son independientes de tecnología de visualización o presentación específica. Este es un mecanismo altamente flexible para transferir datos a un índice alto sin importar la estructura interna de esos datos, ni los aspectos funcionales de los datos o comandos que implementa. Esto permite que la temporización de los paquetes de datos que son transferidos sea ajustada para adaptarse a las idiosincrasias de aparatos cliente particulares, tal como para deseos de visualización únicos para ciertos dispositivos, o para cumplir con los requerimientos de audio y video combinado para algunos sistemas A-V, o para ciertos dispositivos de entrada tales como palancas de mando, pantallas y ratones táctiles, y así sucesivamente. La interfase es muy desconfiada del elemento de pantalla o aparato cliente, siempre y cuando se siga el protocolo seleccionado. Además, los datos de enlace serie agregados, o índice de datos, pueden variar en diversos órdenes de magnitud lo cual permite que un diseñador del sistema de comunicación o aparato central optimice el costo, requerimientos de potencia, complejidad del aparato cliente, e índices de actualización de aparato cliente. La interfase de datos es presentada principalmente para usar para transferir grandes cantidades de datos de índice alto en un enlace de señal "alámbrico" o cable pequeño. Sin embargo, algunas aplicaciones pueden aprovechar también un enlace inalámbrico, incluyendo enlaces ópticos, siempre y cuando esté configurada para usar las mismas estructuras de paquete y datos desarrolladas para el protocolo de interfase y pueda mantener el nivel de transferencia deseado a un consumo de potencia o complejidad lo suficientemente bajos para seguir siendo práctica.

II . Ambiente Una aplicación típica se puede ver en las figuras 1A y IB donde una computadora portátil 100 y un teléfono inalámbrico o dispositivo PDA 102 se muestran comunicando datos con dispositivos de visualización 104 y 106, respectivamente, junto con sistemas de reproducción de audio 108 y 112. Además, la figura 1A muestra conexiones potenciales a un dispositivo de presentación visual o pantalla 114 más grande o un proyector de imagen 116, los cuales se muestran solamente en una figura para mayor claridad, pero se pueden conectar también al aparato inalámbrico 102. El aparato inalámbrico puede estar actualmente recibiendo datos o haber almacenado anteriormente una cierta cantidad de datos tipo multimedia en un elemento o dispositivo de memoria para presentación posterior para ser vistos y/o escuchados por un usuario final del aparato inalámbrico. Debido a que un aparato inalámbrico típico es usado para comunicaciones de voz y texto simple la mayor parte del tiempo, tiene una pantalla de visualización bastante pequeña y un sistema de audio simple (altavoces) para comunicar información al usuario del aparato 102. La computadora 100 tiene una pantalla mucho más grande, pero aún tiene un sistema de sonido externo insuficiente, y aún carece de otros dispositivos de presentación multimedia tales como un televisor de alta definición o pantallas. La computadora 100 se usa para propósitos de ilustración y otros tipos de procesadores, juegos de video interactivos, o dispositivos electrónicos se pueden usar también con la invención. La computadora 100 puede emplear, mas no se limita a, un módem inalámbrico u otro dispositivo incorporado para comunicaciones inalámbricas, o puede estar conectada a dichos dispositivos con el uso de un cable o enlace inalámbrico, como se desee. Esto hace que la presentación de datos más complejos o "ricos" no sea una experiencia útil o agradable ni mucho menos. Por lo tanto, la industria está desarrollando otros mecanismos y dispositivos para presentar la información a usuarios finales y proveer un nivel mínimo de disfrute o experiencia positiva deseados . Como se discutió previamente, diversos tipos de dispositivos de visualización se han desarrollado o se están desarrollando en la actualidad para presentar información a usuarios finales del dispositivo 100. Por ejemplo, una o más compañías han desarrollado equipos de anteojos que se pueden usar que proyectan una imagen enfrente de los ojos de un usuario del dispositivo para una presentación visual. Cuando tales dispositivos son colocados de manera correcta, "proyectan" de manera efectiva una imagen virtual, como es percibido por los ojos de un usuario, que es mucho más grande que el elemento que provee el resultado visual. Esto es, un elemento de proyección muy pequeño permite que los ojos de un usuario "vean" imágenes en una escala mucho más grande de lo que es posible con pantallas LCD típicas y similares. El uso de imágenes de pantalla virtuales más grandes permite el uso de imágenes de resolución mucho más alta de lo que es posible con pantallas LCD más limitadas. Otros dispositivos de visualización podrían incluir, mas no se limitan a, pantallas LCD pequeñas o diversos elementos de pantalla de panel plano, lentes de proyección y excitadores de visualización para proyectar imágenes en una superficie, y así sucesivamente . También puede haber elementos adicionales conectados a o asociados con el uso del aparato inalámbrico 102 o computadora 100 para presentar un resultado a otro usuario, o a otro dispositivo el cual a su vez transfiere las señales a otro lugar o las almacena. Por ejemplo, los datos se pueden almacenar en memoria flash, en forma óptica, por ejemplo, usando medios de CD escribibles o en medios magnéticos como por ejemplo, en una grabadora de cinta magnética y dispositivos similares, para uso posterior. Además, muchos aparatos inalámbricos y computadoras ahora cuentan con capacidades de decodificación de música MP3 integradas, así como otros decodificadores y sistemas de sonido avanzados . Las computadoras portátiles utilizan capacidades de reproducción de CD y DVD como regla general, y algunas tienen pequeños lectores de memoria flash dedicados para recibir archivos de audio grabados previamente. El problema con tener estas capacidades es que los archivos de música digital prometen una experiencia rica en características altamente incrementada, pero solamente si el proceso de decodificación y reproducción puede seguir el mismo ritmo . Lo mismo es cierto para los archivos de video digital. Para ayudar con la reproducción de sonido, altavoces externos 114 se muestran en la figura 1A, los cuales podrían estar también acompañados de elementos de adición tales como altavoces para infragraves o altavoces de "sonido envolvente" para proyección de sonido anterior y posterior. Al mismo tiempo, altavoces o audífonos 108 están indicados como incorporados al marco de soporte o mecanismo del dispositivo de micropantalla 106 de la figura IB. Como sería conocido, se pueden usar otros elementos de reproducción de audio o sonido incluyendo dispositivos de amplificación de potencia o configuración de sonido. En cualquier caso, como se discute con anterioridad, cuando se desea transferir datos de imagen de alta calidad o de alta resolución e información de audio de alta calidad o señales de datos de una fuente de datos a un usuario final en uno o más enlaces de comunicación 110, se requiere un índice de datos alto. Esto es, el enlace de transferencia 110 es claramente un cuello de botella potencial en la comunicación de datos como se discutió antes, y está limitando el rendimiento del sistema, ya que los mecanismos de transferencia actuales no logran los índices de datos altos típicamente deseados . 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 índices de datos de 30 fps, los índices de datos se pueden aproximar a índices superiores a 755 Mbps o más.

Además, tales imágenes pueden ser presentadas como parte de una presentación multimedia la cual incluye datos de audio y señales potencialmente adicionales que se relacionan con juegos interactivos o comunicaciones, o diversos comandos, controles o señales que incrementan aún más la cantidad o datos y el índice de datos . Igualmente es claro que menos cables . o interconexiones requeridos para establecer un enlace de datos, significa que los dispositivos móviles asociados con una pantalla son más fáciles de usar, y es más probable que sean adoptados por una base de usuario más grande. Esto es específicamente cierto donde múltiples dispositivos son usados comúnmente para establecer una experiencia audio-visual completa, y más en especial a medida que el nivel de calidad de las pantallas y dispositivos de salida de audio incrementa. Otra aplicación típica relacionada con muchas de las mejoras anteriores y otras en pantallas de video y otros dispositivos de entrada o salida se puede ver en las figuras 1C y ID donde una computadora portátil 130 y un teléfono inalámbrico o dispositivo PDA 140 se muestran comunicando datos con dispositivos de visualización "internos" 134 y 144, respectivamente, junto con los sistemas de reproducción de audio 136 y 146. En las figuras 1C y ID, pequeñas secciones cortadas de los aparatos o productos electrónicos en general se usan para mostrar la ubicación de uno o más aparatos centrales y controladores internos en una porción del dispositivo con un enlace de comunicación generalizado, aquí 138 y 148, respectivamente, conectándolos a los elementos de pantalla de video o pantallas que tienen los clientes correspondientes, a través de una unión giratoria de algún tipo conocido usado en la industria de la electrónica hoy en día. Se puede ver que la cantidad de datos implicados en estas transferencias requiere un gran número de conductores para comprender los enlaces 138 y 148. Se estima que dichos enlaces de comunicación se acercan a 90 o más conductores a fin de satisfacer las necesidades crecientes en la actualidad para utilizar interfases de color e interfaces gráficas avanzadas, elementos de pantalla, en tales dispositivos debido a los tipos de técnicas de interfase paralela u otras técnicas de interfase conocidas disponibles para transferir tales datos. Desafortunadamente, los índices de datos más altos exceden la tecnología actual disponible para transferir datos . Tanto en términos de la cantidad en bruto de datos que necesitan ser transferidos por unidad de tiempo, como en términos de fabricar mecanismos de transferencia físicos efectivos en costos y confiables. Lo que se necesita es una técnica, una estructura, medio o método para transferir datos a índices más altos para el enlace de transferencia de datos o trayectoria de comunicación entre elementos de presentación y la fuente de datos, que tome en cuenta en forma consistente una estructura de cableado de potencia más baja, peso ligero y tan simple y económica como sea posible. Los solicitantes han desarrollado una nueva técnica, o método y aparato, para lograr éstas y otras metas para permitir gue una serie de dispositivos móviles, portátiles o incluso de ubicación fija, transfieran datos a pantallas, micropantallas o elementos de transferencia de audio deseados, a índices de datos muy altos, mientras se mantiene un bajo consumo de potencia y una complejidad deseados.

III. Arquitectura de sistema de interfase de datos digitales de Índice alto A fin de crear y utilizar en forma eficiente una nueva interfase de dispositivo, se ha formulado un protocolo de señal y una arquitectura de sistema que proveen un índice de transferencia de datos muy alto usando señales de baja potencia. El protocolo se basa en un paquete y estructura de marco común, o estructuras enlazadas juntas para formar un protocolo para comunicar una serie previamente seleccionada de datos o tipos de datos junto con un comando o estructura de operación impuesto en la interfase. A. Visión general Los dispositivos conectados por el enlace MDDI o que se comunican en el mismo, son llamados el aparato central y el cliente, siendo el cliente típicamente un dispositivo de pantalla de algún tipo, aunque se contemplan otros dispositivos de entrada y salida. Los datos del aparato central a la pantalla viajan en la dirección hacia adelante (llamada un tráfico o enlace hacia delante) , y los datos del cliente al aparato central viajan en la dirección inversa (tráfico o enlace inverso) , como es habilitado por el aparato central. Esto se ilustra en la configuración básica que se muestra en la figura 2. En la figura 2, un aparato central 202 está conectado a un cliente 204 usando un canal de comunicación bidireccional 206 el cual se ilustra compuesto de un enlace hacia adelante 208 y un enlace inverso 210. No obstante, estos canales están formados por una serie común de conductores cuya transferencia de datos es conmutada de manera efectiva entre las operaciones de enlace hacia adelante o inverso. Esto tiene en cuenta números considerablemente reducidos de conductores, lo cual aborda inmediatamente uno de los muchos problemas que se presentan con los enfoques actuales de transferencia de datos a alta velocidad en ambientes de potencia baja tales como para aparatos electrónicos móviles . Como se discute en otra parte, el aparato central comprende uno de varios tipos de dispositivos que se pueden beneficiar de usar la presente invención. Por ejemplo, el aparato central 202 podría ser una computadora portátil en forma de un dispositivo informático móvil manual, de computadora portátil o similar. Podría ser también un Asistente Personal de Datos (PDA) , un dispositivo de búsqueda de personas, o uno de - muchos teléfonos o módems inalámbricos . De manera alternativa, el aparato 202 podría ser un dispositivo de entretenimiento o presentación portátil como por ejemplo, un reproductor de DVD o CD portátil, o un dispositivo de juegos. Además, el aparato central puede residir como un aparato central o elemento de control en una variedad de otros productos comerciales ampliamente usados o planeados para los cuales se desea un enlace de comunicación a alta velocidad con un cliente. Por ejemplo, un aparato central podría ser usado para transferir datos a índices altos de un dispositivo de grabación de video a un cliente basado en almacenamiento para mejorar la respuesta, o a una pantalla más grande de alta resolución para presentaciones. Un electrodoméstico como por ejemplo, un refrigerador que incorpora un sistema de inventario o informático de a bordo y/o conexiones Bluetooth a otros dispositivos caseros, puede tener capacidades de pantalla mejoradas al operar en un modo conectado a Internet o Bluetooth, o tener necesidades de cableado reducidas para pantallas en la puerta (un cliente) y i teclados o escáneres (cliente) mientras la computadora o sistemas de control electrónicos (aparato central) residen en cualquier parte en el gabinete. En general, los expertos en la técnica entenderán la amplia variedad de dispositivos electrónicos y electrodomésticos modernos que se pueden beneficiar del uso de esta interfase, así como la capacidad de modernizar dispositivos más viejos con transporte de información de índice de datos más alto utilizando números limitados de conductores disponibles ya sea en conectores o cables recién agregados o existentes. 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 aparato central. Por ejemplo, una micropantalla incorporada en anteojos o gafas, un dispositivo de proyección incorporado en un sombrero o casco, una pantalla pequeña o incluso un elemento holográfico incorporado en un vehículo, por ejemplo, en una ventana o parabrisas, o diversos sistemas de altavoces, audífonos o de sonido para presentar sonido o música de alta calidad. Otros dispositivos de presentación incluyen proyectores o dispositivos de proyección usados para presentar información para reuniones o para imágenes de películas y de televisión. Otro ejemplo sería el uso de pantallas táctiles o dispositivos sensibles, dispositivos de entrada de reconocimiento de voz, escáneres de seguridad, y así sucesivamente, a los que se puede recurrir para transferir una cantidad significativa de información de un usuario de dispositivo o sistema con poca "entrada" real que no sea toque o sonido del usuario. Además, las estaciones de acoplamiento para computadoras y equipos para el automóvil o equipos para escritorio y soportes para teléfonos inalámbricos pueden actuar como dispositivos de interfase a usuarios finales u otros dispositivos y equipo, y emplear ya sea clientes (dispositivos de entrada o salida tales como ratones) o aparatos centrales para ayudar en la transferencia de datos, en especial cuando están implicadas redes de alta velocidad. Sin embargo, los expertos en la técnica reconocerán fácilmente que la presente invención no se limita a esos dispositivos, habiendo muchos otros dispositivos en el mercado, y que se proponen para usar, que están diseñados para proveer a los usuarios finales imágenes y sonido de alta calidad, ya sea en términos de almacenamiento y transporte o en términos de presentación durante la reproducción. La presente invención es útil para incrementar el rendimiento de datos entre diversos elementos o dispositivos para admitir los índices de datos altos necesarios para realizar la experiencia de usuario deseada. La Interfase MDD inventiva y protocolo de señal de comunicación se pueden usar para simplificar la interconexión entre un procesador de aparato central, controlador o componente de circuito (por ejemplo) , y una pantalla dentro de un dispositivo o alojamiento o estructura de dispositivo (llamado un modo interno) a fin de reducir el costo o complejidad y requerimientos o restricciones de potencia y control asociados de estas conexiones, y mejorar la confiabilidad, no sólo para conexión a o para elementos, dispositivos o equipo externos (llamado un modo externo) .

El índice de datos de enlace serie agregados en cada par de señales usado por este estructura de interfase puede variar en muchos órdenes de magnitud, lo cual permite que un diseñador de sistema o dispositivo optimice fácilmente el costo, potencia, complejidad de implementación, y el índice de actualización de pantalla para una aplicación o propósito dados . Los atributos de MDDI son independientes de la tecnología de pantalla o de otro dispositivo de presentación (cliente objetivo) . La temporización de los paquetes de datos transferidos a través de la interfase se puede ajustar fácilmente para adaptarse a las idiosincrasias de clientes particulares tales como dispositivos de pantalla, sistemas de sonido, elementos de memoria y control, o requerimientos de temporización combinados de sistemas de audio-video. Aunque esto hace posible tener un sistema con un consumo de potencia muy pequeño, no es un requerimiento de los diversos clientes tener memorias intermedias de cuadro para hacer uso del protocolo MDDI por lo menos a algún nivel.

B. Tipos de interfase Se contempla que la interfase MDD se encarga de por lo menos cuatro, y potencialmente más, tipos físicos de interfases algo distintos encontrados en las industrias de las comunicaciones y de las computadoras. Éstos están etiquetados simplemente como Tipo 1, Tipo 2, Tipo 3 y Tipo 4, aunque los expertos en la técnica pueden aplicar otras etiquetas o designaciones dependiendo de las aplicaciones específicas para las que se usan o para la industria con la que están asociados. Por ejemplo, los sistemas de audio simples utilizan menos conexiones que los sistemas multimedia más complejos, y pueden hacer referencia a características tales como "canales" de manera diferente, y así sucesivamente. La interfase Tipo 1 está configurada como una interfase de conductor de 6 hilos u otro tipo de conductor o elemento conductivo, que la hace adecuada para teléfonos móviles o inalámbricos, PDAs, juegos electrónicos y reproductores de medios portátiles, tales como reproductores de CD, o reproductores de MP3, y dispositivos similares o dispositivos usados en tipos similares de tecnología electrónica. En una modalidad, una interfase se puede configurar como una interfase (de conductor) de 8 hilos la cual es más adecuada para computadoras portátiles, miniportátiles o computadoras personales de escritorio y dispositivos o aplicaciones similares que no requieren actualizaciones de datos rápidas y no tienen un controlador de enlace de MDDI incorporado. Este tipo de interfase se distingue también por el uso de una interfase de Bus Serie Universal (USB) de dos hilos adicional, la cual es extremadamente útil para admitir sistemas operativos existentes o soportes de software encontrados en la mayoría de las computadoras personales . Las interfases Tipo 2, Tipo 3 y Tipo 4 son adecuadas para clientes o dispositivos de alto rendimiento y usan un cableado más complejo y más grande con conductores tipo par trenzado adicionales para proveer el blindaje apropiado y transferencias de pérdida baja para señales de datos. La interfase Tipo 1 pasa señales que pueden comprender información de señalización de pantalla, audio, control y limitada, y se usa típicamente para clientes móviles o aparatos cliente que no requieren datos de video de índice completo de alta resolución. Una interfase Tipo 1 puede soportar fácilmente resolución SVGA a 30 fps más canal de audio 5.1, y en una configuración mínima pudiera usar solamente tres pares de hilos en total, dos pares para transmisión de datos y un par para transferencia de potencia. Este tipo de interfase está diseñada principalmente para dispositivos, tales como aparatos inalámbricos móviles, donde un aparato central USB típicamente no está disponible dentro del aparato para conexión y transferencia de señales. En esta configuración, el aparato inalámbrico móvil es un aparato central MDDI, y actúa como el "maestro" que controla el enlace de comunicación desde el aparato central, el cual generalmente envía datos al cliente (tráfico o enlace hacia adelante) para presentación, visualización o reproducción . En esta interfase, un aparato central habilita la recepción de datos de comunicación en el aparato central desde el cliente (tráfico o enlace inverso) enviando un comando o tipo de paquete especial al cliente que le permite asumir el control del bus (enlace) por una duración especificada y enviar datos al aparato central como paquetes inversos. Estos se ilustra en la figura 3, donde un tipo de paquete llamado un paquete de encapsulación (se discute más adelante) se usa para admitir la transferencia de paquetes inversos en el enlace de transferencia, creando el enlace inverso. El intervalo de tiempo asignado para que el aparato central sondee al cliente para ver si hay datos es determinado previamente por el aparato central, y se basa en los requerimientos de cada aplicación especificada. Este tipo de transferencia de datos bidireccional semidúlplex es especialmente favorable donde no se encuentra disponible un puerto USB para transferencia de información o datos desde el cliente. Las pantallas de alto rendimiento capaces de altas resoluciones tipo HDTV o similares requieren flujos de datos de índice de aproximadamente 1.5 Gbps a fin de soportar video a velocidad real. La interfase Tipo 2 soporta índices de datos altos transmitiendo 2 bits en paralelo, el Tipo 3 transmitiendo 4 bits en paralelo y la interfase Tipo 4 transfiere 8 bits en paralelo. Las interfases Tipo 2 y Tipo 3 usan el mismo cable y colector que el Tipo 1 pero pueden operar a dos veces y cuatro veces el índice de datos para soportar aplicaciones de video de rendimiento más alto en dispositivos portátiles. Una interfase Tipo 4 es adecuada para clientes o pantallas de muy alto rendimiento y requieren un cable ligeramente más grande que contiene señales de datos de par trenzado adicionales . El protocolo usado por la MDDI permite que cada aparato central Tipo 1, 2, 3 o 4 se comunique generalmente con cualquier cliente Tipo 1, 2, 3, o 4 negociando cuál es el índice de datos más alto posible que se puede usar. Las capacidades o características disponibles de lo que se puede llamar el dispositivo menos capaz se usan para establecer el rendimiento del enlace. Como regla, incluso para sistemas donde el aparato central y cliente son ambos capaces usando interfases Tipo 2, Tipo 3 o Tipo 4, ambos empiezan la operación como una interfase Tipo 1. El aparato central determina luego la capacidad del cliente objetivo y negocia una operación de cesión o reconfiguración ya sea al modo Tipo 2, Tipo 3 o Tipo 4, como sea apropiado para la aplicación particular. Es en general posible que el aparato central use el protocolo de capa de enlace apropiado (se discute en detalle más adelante) y disminuya o reconfigure de nuevo la operación generalmente en cualquier momento a un modo más lento para ahorrar potencia o aumente a un modo más rápido para soportar transferencias a velocidad más' alta, tales como para contenido de pantalla de resolución más alta. Por ejemplo, un aparato central puede cambiar tipos de interfase cuando el sistema cambia de una fuente de potencia tal como una batería a potencia de CA, o cuando la fuente de los medios de visualización cambian a un formato de resolución más bajo o más alto, o una combinación de éstas y otras condiciones o eventos se puede considerar como una base para cambiar un tipo de interfase, o modo de transferencia.

Asimismo, es posible que un sistema comunique datos usando un modo en una dirección y otro modo en otra dirección. Por ejemplo, un modo de interfase Tipo 4 se podría usar para transferir datos a una pantalla a un índice alto, mientras que un modo Tipo 1 se usa al transferir datos a un aparato central desde dispositivos periféricos como por ejemplo, un teclado o un dispositivo señalador. Los expertos en la técnica entenderán que los aparatos centrales y clientes pueden comunicar datos de salida a diferentes índices . Con frecuencia, los usuarios el protocolo MDDI pueden distinguir entre un modo "externo" y un modo "interno". Un modo externo describe el uso del protocolo e interfase para conectar un aparato central en un dispositivo a un cliente fuera de ese dispositivo que se encuentra a una distancia de hasta aproximadamente 2 metros del aparato central. En esta situación, el aparato central puede también enviar potencia al cliente externo de modo que ambos aparatos puedan operar fácilmente en un ambiente móvil . Un modo interno describe cuando el aparato central es conectado a un cliente contenido dentro del mismo dispositivo, como por ejemplo, dentro de un alojamiento o marco de soporte o estructura común de algún tipo. Un ejemplo serían aplicaciones dentro de un teléfono inalámbrico u otro aparato inalámbrico, o una computadora portátil o dispositivo de juego cuando el cliente es una pantalla o excitador de pantalla, o un dispositivo de entrada tal como un teclado o pantalla o ratón táctil, o un sistema de sonido, y el aparato central es un controlador central, motor de gráficos o elemento de CPU. Debido a que un cliente está ubicado mucho más cerca del aparato central en aplicaciones de modo interno a diferencia de las aplicaciones de modo externo, por lo general no se discuten requerimientos para la conexión de potencia al cliente en tales configuraciones .

C. Estructura de interfase física La disposición general de un dispositivo o controlador de enlace para establecer comunicaciones entre el aparato central y aparato cliente se muestra en las figuras 4 y 5. En las figuras 4 y 5, un controlador de enlace de MDDI 402 y 502 se muestra instalado en un aparato central 202 y un controlador de enlace de MDDI 404 y 504 se muestra instalado en un aparato cliente 204. Como antes, el aparato central 202 está conectado a un cliente 204 usando un canal de comunicación bidireccional 406 que comprende una serie de conductores. Como se discute más adelante, tanto el controlador de enlace de aparato central como el controlador de enlace de cliente se pueden fabricar como un circuito integrado usando un diseño de un solo circuito que se puede fijar, ajustar o programar para que responda ya sea como un controlador de aparato central (excitador) o un controlador de cliente (receptor) . Esto provee costos más bajos debido a la fabricación a gran escala de un dispositivo de un solo circuito . En la figura 5, un controlador de enlace de MDDI 502 se muestra instalado en un aparato central 202' y un controlador de enlace de MDDI 504 se muestra instalado en un aparato cliente 204'. Como antes, el aparato central 202' está conectado a un cliente 204" usando un canal de comunicación bidireccional 506 que comprende una serie de conductores . Como se discute antes, tanto el controlador de enlace de aparato central como el controlador de enlace cliente se pueden fabricar usando un diseño de un solo circuito. Las señales que pasan entre un aparato central y un cliente, tal como un dispositivo de visualización, en el enlace de MDDI, o los conductores físicos usados, se ilustran también en las figuras 4 y 5. Como se ve en las figuras 4 y 5, la trayectoria primaria o mecanismo para transferir datos a través de la MDDI usa señales de datos etiquetadas como MDDI_DatosO+/- y MDDI_Stb+/-. Cada una de éstas son señales de datos de bajo voltaje que son transferidas en un par diferencial de hilos en un cable. Solamente hay una transición ya sea en el par MDDI_DatosO o el par MDDI_Stb para cada bit enviado en la interfase. Este es un mecanismo de transferencia basado en voltaje no basado en corriente, de manera que el consumo de corriente estática es casi cero. El aparato central impulsa las señales MDDI_Stb a la pantalla cliente. Aunque los datos pueden fluir tanto en dirección hacia adelante como en dirección inversa en los pares MDDI_Datos, esto es, es una trayectoria de transferencia bidireccional, el aparato central es el maestro o controlador del enlace de datos. Las trayectorias de señal MDDI_DatosO y MDDI_Stb son operadas en un modo diferencial para aumentar al máximo la inmunidad al ruido. El índice de datos para señales en estas líneas es determinado por el índice del reloj enviado por el aparato central y es variable en un rango de aproximadamente 1 kbps hasta 400 Mbps o más. La interfase Tipo 2 contiene un par de datos o conductores o trayectorias adicionales más allá de aquel del Tipo 1, llamado MDDI_Datosl+/- . La interfase Tipo 3 contiene dos pares de datos o trayectorias de señal adicionales más allá de aquel de la interfase Tipo 2 llamados MDDI_Datos2+/- y MDDI_Datos3+/- . La interfase Tipo 4 contiene cuatro pares de datos o trayectorias de señal más, más allá de aquel de la interfase Tipo 3 llamados: MDDI_Datos4+/-, MDDI_Datos5+/-, MDDI_Datos6+/- y MDDI_Datos7+/-, respectivamente. En cada una de las configuraciones de interfase anteriores, un aparato central puede enviar potencia al cliente o pantalla usando el par de hilos o señales designados como HOST_Pwr y HOST_Gnd. Como se discuten en más detalle más adelante, también se puede admitir la transferencia de potencia, si se desea, en algunas configuraciones en los conductores MDDI_Datos4+/-, MDDI_Dat?s5+/-, MDDI_Datos6+/- o MDDI_Datos7+/- cuando un "Tipo" de interfase está siendo usado que emplea menos conductores de los que están disponibles o presentes para los otros modos. Esta transferencia de Potencia es generalmente empleada para modos externos, por lo general no hay necesidad de modos internos, aunque algunas aplicaciones pueden diferir . Un resumen de las señales que pasan entre el aparato central y el cliente (pantalla) en el enlace de MDDI para diversos modos se ilustra en el cuadro I, a continuación, de acuerdo con el tipo de interfase.

Cuadro I Asimismo, observar que las conexiones HOST_Pwr/Gnd para transferir desde el aparato central son provistas en general para modos externos . Las aplicaciones o modos internos de operación generalmente tienen clientes que extraen potencia directamente de otros recursos internos y no usan MDDI para controlar la distribución de potencia, como sería aparente para un experto en la técnica, de manera que tal distribución no se discute en mayor detalle aquí. Sin embargo, ciertamente es posible permitir que la potencia sea distribuida a través de la interfase MDDI para tener en cuenta ciertos tipos de control de potencia, sincronización, o conveniencia de interconexión, por ejemplo, como comprendería un experto en la técnica. El cableado generalmente usado para implementar la estructura y operación anteriores es nominalmente en el orden de 1.5 metros de longitud, generalmente 2 metros o menos, y contiene tres pares trenzados de conductores, cada uno a su vez es un alambre multitrenzado AWG 30. Una cubierta de blindaje de hoja metálica está envuelta o formada de otra manera arriba de los tres pares trenzados, como un cable de drenaje adicional. Los pares trenzados y conductor de drenaje blindado terminan en el conector de cliente con el blindaje conectado al blindaje para el cliente, y hay una capa aislante, que cubre el cable completo, como sería bien conocido en la técnica. Los hilos están emparejados como: HOST_Gnd con HOST_Pwr; MDDI_Stb+ con MDDI_Stb-; MDDI_DatosO+ con MDDI_Datos0-; MDDI_Datosl+ con MDDI_Datosl-; y así sucesivamente. No obstante, se puede usar una variedad de conductores y cableado, como se entendería en la técnica, para implementar las modalidades de la invención, dependiendo de las aplicaciones específicas. Por ejemplo, revestimientos externos más pesados o incluso capas metálicas se pueden usar para proteger el cable en algunas aplicaciones, mientras que estructuras tipo cinta conductora más delgadas y planas pueden ser adecuadas para otras aplicaciones .

D. Tipos e Índices de datos Para obtener una interfase útil para un rango completo de experiencias y aplicaciones de usuario, la Inferíase de Datos Digitales Móviles (MDDI) provee soporte para una variedad de clientes e información de pantalla, transductores de audio, teclados, dispositivos señaladores y muchos otros dispositivos de entrada o salida que pudieran ser integrados en un dispositivo de pantalla móvil o trabajar junto con el mismo, junto con información de control, y combinaciones de los mismos. La interfase MDD está diseñada para ser capaz de admitir una variedad de tipos potenciales de flujos de datos que atraviesan entre el aparato central y el cliente en direcciones de enlace ya sea hacia adelante o) inversa usando un número mínimo de cables o conductores. Tanto los flujos isócronos como los flujos asincronos (actualizaciones) están soportados. Muchas combinaciones de tipos de datos son posibles siempre que el índice de datos agregados sea menor o igual al índice de enlace MDDI deseado máximo, el cual está limitado por el índice serie máximo y el número de pares de datos empleados . Estos podrían incluir, mas no se limitan a, aquellos elementos listados en los cuadros II y III a continuación.

Cuadro II Cuadro III La interfase no es fija sino ampliable de manera que puede soportar la transferencia de una variedad de "tipos" de información que incluye datos definidos por el usuario, para futura flexibilidad del sistema. Ejemplos específicos de datos que se van a admitir son: video a velocidad real, ya sea en forma de campos de mapa de bits de pantalla completa o parcial o video comprimido; mapas de bits estáticos a índices bajos para conservar la potencia y reducir los costos de implementación; PCM o datos de audio comprimidos a una variedad de resoluciones o índices; posición y selección del dispositivo señalador, y datos definibles por el usuario para capacidades que aún están por definir. Tales datos pueden ser también transferidos junto con información de control o estado para detectar la capacidad del dispositivo o establecer parámetros de operación . Las modalidades de la invención mejoran la técnica para uso en transferencias de datos que incluyen, mas no se limitan a: ver una película (visualización de video y audio) ; usar una computadora personal con visualización personal limitada (visualización de gráficos, algunas veces combinada con video y audio); reproducir un juego de video en una PC, consola o dispositivo personal (visualización de gráficos en movimiento, o video y audio sintéticos) ; "explorar" la Internet, usando dispositivos en forma de un videoteléfono (video y audio de índice bajo bidireccionales) , una cámara para imágenes digitales fijas, o una cámara de video para capturar imágenes de video digitales; usar un teléfono, computadora, o PDA acoplado con un proyector para dar una presentación o acoplado con una estación de acoplamiento de escritorio conectada a un monitor de video, teclados y ratón; y para uso de mejora de la productividad o entretenimiento con teléfonos celulares, teléfonos inteligentes o PDAs, incluyendo dispositivos señaladores inalámbricos y datos de teclado. La interfase de datos a alta velocidad como se discute más adelante es presentada en términos de proveer grandes cantidades de datos de tipo A-V en un enlace de comunicación o transferencia que está generalmente configurado como un enlace tipo línea metálica o cable. Sin embargo, será fácilmente evidente que la estructura de señal, protocolos, temporización o mecanismo de transferencia se podría ajustar para proveer un enlace en forma de medios ópticos o inalámbricos, si pueden mantener el nivel deseado de transferencia de datos. Las señales de interfase MDD usan un concepto conocido como el índice de Cuadro Común (CFR) para el protocolo o estructura de señal básico. La idea detrás de usar un índice de Cuadro Común es proveer un pulso de sincronización para flujos de datos isócronos simultáneos . Un aparato cliente puede usar este índice de cuadro común como una referencia de tiempo . Un índice CF bajo incrementa la eficiencia de canal al reducir la sobrecarga para transmitir la cabecera de subcuadro. Por otra parte, un índice CF alto reduce la latencia y permite una memoria intermedia de datos elástica más pequeña para muestras de audio. El índice CF de la presente interfase inventiva es programable de manera dinámica y se puede ajustar a uno de muchos valores que son apropiados para flujos isócronos usados en una aplicación particular. Esto es, el valor CF se selecciona para adaptarse mejor a la configuración de cliente y aparato central dada, como se desee. El número de bytes generalmente requerido por subcuadro, el cual es ajustable o programable, para flujos de datos isócronos que tienen más probabilidad de ser usados con una aplicación, tales como para un video o micropantalla se muestran en el cuadro IV.

Cuadro IV Los conteos fraccionarios de bytes por subcuadro se obtienen fácilmente usando una estructura de contador M/N programable simple. Por ejemplo, un conteo de 26-2/3 bytes por CF es implementado al transferir 2 cuadros de 27 bytes cada uno seguidos de un subcuadro de 26 bytes. Un índice de CF más pequeño se puede seleccionar para producir un número entero de bytes por subcuadro. No obstante, hablando en términos generales, implementar un contador M/N simple en hardware debe requerir menos área dentro de un chip de circuito integrado o módulo electrónico usado para implementar parte de o todas las modalidades de la invención que el área necesaria para una memoria intermedia FIFO de muestra de audio más grande. Una aplicación ejemplar que ilustra el impacto de diferentes índices de transferencia de datos y tipos de datos es un sistema karaoke . Para karaoke, un sistema donde un usuario final, o usuarios, canta junto con un programa de video de música. La letra de la canción es desplegada en algún lugar en, típicamente en la parte inferior de, una pantalla de manera que el usuario sepa las palabras que va a cantar y aproximadamente el tiempo de la canción. Esta aplicación requiere una pantalla de video con actualizaciones de gráficos poco frecuentes y mezcla de la voz del usuario, o voces, con un flujo de audio estéreo. Si uno supone un índice de cuadro común de 300 Hz, entonces cada subcuadro consistirá de: 92,160 bytes de contenido de video y 588 bytes de contenido de audio (basado en 147 muestras de 16 bits, en estéreo) en el enlace hacia adelante al dispositivo de pantalla de cliente, y un promedio de 26.67 (26-2/3) bytes de voz son enviados de vuelta desde un micrófono hasta la máquina de karaoke móvil . Paquetes asincronos son enviados entre el aparato central y la pantalla, posiblemente un visiocasco. Esto incluye como máximo 768 bytes de datos de gráficos (altura de un cuarto de pantalla) y menos de aproximadamente 200 bytes (varios) bytes para comandos de control y estado misceláneos. El cuadro V muestra cómo son asignados los datos dentro de un subcuadro para el ejemplo del karaoke. El índice total que se usa se selecciona para que sea aproximadamente 279 Mbps. Un índice ligeramente más alto de 280 Mbps permite que aproximadamente otros 400 bytes de datos por subcuadro sean transferidos, lo cual permite el uso de mensajes de control y estado ocasionales .

Cuadro V III. (Continuación) Arquitectura de sistema de interfase de datos digitales de índice alto E. Capa de enlace Los datos transferidos usando las señales de datos serie de alta velocidad de interfase MDD consisten de un flujo de paquetes multiplexados en el tiempo que están enlazados uno después de otro. Aun cuando un dispositivo de transmisión no tiene datos que enviar, un controlador de enlace MDDI generalmente envía de manera automática paguetes de relleno, por ende, mantiene un flujo de paquetes. El uso de una estructura de paquetes simple asegura una temporización isócrona confiable para señales de video . y audio o flujos de datos . Los grupos de paquetes están contenidos dentro de elementos o estructuras de señal llamados subcuadros y grupos de subcuadros están contenidos dentro de elementos o estructuras de señal llamados un cuadro de medios. Un subcuadro contiene uno o más paquetes, dependiendo de su tamaño y usos de transferencia de datos respectivos, y un cuadro de medios contiene uno o más subcuadros . El subcuadro más grande provisto por el protocolo empleado por las modalidades aquí presentadas está en el orden de 232-l ó 4,294,967,295 bytes, y el tamaño de cuadro de medios más grande se convierte entonces en el orden de 216-1 ó 65,535 subcuadros. Un paquete de cabecera de subcuadro especial contiene un identificador único que aparece al inicio de cada subcuadro, como se discute más adelante. Ese identificador se usa también para adquirir la temporización de cuadro en el aparato cliente cuando se inicia la comunicación entre el aparato central y el cliente. La adquisición de temporización de enlace se discute en más detalle más adelante. Típicamente, una pantalla de visualización es actualizada una vez por cuadro de medios cuando se está desplegando video a velocidad real. El índice de cuadro de pantalla es el mismo que el índice de cuadro de medios. El protocolo de enlace soporta video a velocidad real en una pantalla completa, o sólo una pequeña región del contenido de video a velocidad real rodeado por una imagen estática, dependiendo de la aplicación deseada. En algunas aplicaciones móviles de baja potencia, tales como ver páginas web o correo electrónico, la pantalla de visualización puede sólo necesitar ser actualizada de manera ocasional. En esas situaciones, es favorable transmitir un solo subcuadro y después interrumpir o desactivar el enlace para reducir al mínimo el consumo de potencia. Igualmente, la interfase soporta efectos como por ejemplo, visión estéreo, y maneja primitivas gráficas. Los subcuadros permiten que un sistema habilite la transmisión de paquetes de alta prioridad de forma periódica. Esto permite que flujos isócronos simultáneos coexistan con una cantidad mínima de almacenamiento en una memoria intermedia de datos . Esta es una ventaja que las modalidades proveen al proceso de visualización, permitiendo que múltiples flujos de datos (comunicación a alta velocidad de datos de video, voz, control, estado, dispositivo señalador, etc.) compartan de manera esencial un canal común. Transfiere información usando relativamente pocas señales . Asimismo, permite que existan acciones específicas de tecnología de visualización, tales como pulsos de sincronización horizontal e intervalos de supresión para un monitor CRT, o para otras acciones específicas de tecnología del cliente.

F. Controlador de enlace El controlador de enlace MDDI mostrado en las figuras 4 y 5 es fabricado o armado para ser una implementación completamente digital con la excepción de los receptores de línea diferenciales que se usan para recibir datos MDDI y señales de validación. No obstante, aún los excitadores y receptores de línea diferenciales pueden ser implementados en los mismos circuitos integrados digitales con el controlador de enlace, tal como al hacer IC tipo CMOS. No se requieren funciones analógicas o bucles de realimentación en fase (PLLs) para recuperación de bits o para implementar el hardware para el controlador de enlace. Los controladores de enlace de aparato central y cliente contienen funciones muy similares, con la excepción de la interfase de cliente que contiene una máquina de estados para sincronización de enlace. Por lo tanto, las modalidades de la invención permiten la ventaja práctica de ser capaz de crear un solo diseño de controlador o circuito que se puede configurar ya sea como un aparato central o cliente, • que puede reducir los costos de fabricación para los controladores de enlace, como un todo.

IV. Protocolo de enlace de interfase A. Estructura de cuadro El protocolo de señal o estructura de cuadro usado para implementar la comunicación de enlace hacia adelante para transferencia de paquete se ilustra en la figura 6. Como se muestra en la figura 6, la información o datos digitales son agrupados en elementos conocidos como paquetes . Múltiples paquetes están a su vez agrupados juntos para formar lo que se llama un "subcuadro", y múltiples subcuadros están a su vez agrupados juntos para formar un cuadro "de medios". Para controlar la formación de cuadros y transferencia de subcuadros, cada subcuadro empieza con un paquete definido previamente de manera especial llamado Paquete de Cabecera de Subcuadro (SHP) . El aparato central selecciona el índice de datos que se va a usar para una transferencia dada. Este índice puede ser cambiado de manera dinámica por el aparato central con base tanto en la capacidad de transferencia máxima del aparato central, o los datos que son recuperados de una fuente por el aparato central, como en la capacidad máxima del cliente, u otro dispositivo al cual son transferidos los datos. Un aparato cliente receptor diseñado para, o capaz de, la bajar con la MDDI o protocolo de señal inventivo es capaz de ser interrogado por el aparato central para determinar el índice de transferencia de datos máximo, o máximo actual que puede usar, o se puede usar un índice mínimo más lento predeterminado, así como tipos de datos utilizables y características soportadas. Esta información podría ser transferida usando un Paquete de Capacidad del Cliente (DCP) , como se discute más adelante. El dispositivo de pantalla de cliente es capaz de transferir datos o comunicarse con otros dispositivos usando la interfase a un índice de datos mínimo seleccionado previamente o dentro de un rango de índice de datos mínimo, y el aparato central realizará una consulta usando un índice de datos dentro de este rango para determinar las capacidades completas de los aparatos cliente . Otra información de estado que define la naturaleza del mapa de bits y capacidades de índice de cuadro de video del cliente puede ser transferida en un paquete de estado al aparato central de manera que el aparato central pueda configurar la interfase de modo que sea tan eficiente u óptima como sea práctico, o se desee dentro de cualesquier restricciones del sistema. El aparato central envía paquetes de relleno cuando ya no hay (más) paquetes de datos que transferir en el presente subcuadro, o cuando el aparato central no puede transferir a un índice suficiente para seguir el mismo ritmo que el índice de transmisión de datos elegido para el enlace hacia adelante. Debido a que cada subcuadro empieza con un paquete de cabecera de subcuadro, el final del subcuadro anterior contiene un paquete (más probable un paquete de relleno) que llena exactamente el subcuadro anterior. En caso de una falta de espacio para paquetes que llevan datos per se, es muy probable que el paquete de relleno sea el último paquete en un subcuadro, o al final de un subcuadro anterior siguiente y antes de un paquete de cabecera de subcuadro. Es tarea de las operaciones de control en un aparato central asegurar que haya suficiente espacio restante en un subcuadro para cada paquete que se va a transmitir dentro de ese subcuadro. Al mismo tiempo, una vez que un aparato central inicia el envío de un paquete de datos, el aparato central debe ser capaz de completar con éxito un paquete de ese tamaño dentro de un cuadro sin incurrir en una condición de vaciamiento de datos . En un aspecto de las modalidades, la transmisión de subcuadros tiene dos modos . Un modo es un modo de subcuadro periódico, o intervalos de temporización periódicos, usados para transmitir flujos de video y audio en directo. En este modo, la longitud de Subcuadro es definida como no cero. El segundo modo es un modo asincrono o no periódico en el cual los cuadros son usados para proveer datos de mapa de bits a un cliente cuando nueva información está disponible. Este modo es definido al ajustar la longitud de subcuadro a cero en el Paquete de Cabecera de Subcuadro. Al usar el modo periódico, la recepción de paquete de subcuadro puede empezar cuando el cliente se ha sincronizado con la estructura de cuadro de enlace hacia adelante. Esto corresponde con los estados "en sinc" definidos de acuerdo con el diagrama de estado que se discute más adelante con respecto a la figura 49 o figura 63. En el modo de subcuadro no periódico asincrono, la recepción empieza después de que el primer paquete de Cabecera de Subcuadro es recibido.

B. Estructura de paquete general El formato o estructura de paquetes usado para formular el protocolo de comunicación o señal, o método o medio para transferir datos, implementado por las modalidades se presentan más adelante, teniendo en mente que la interfase es ampliable y se pueden añadir estructuras de paquete adicionales como se desee. Los paquetes están etiquetados como, o se dividen en, diferentes "tipos de paquete" en términos de su función en la interfase, esto es, comandos, información, valor o datos que transfieren o con los cuales están asociados. Por lo tanto, cada tipo de paquete denota una estructura de paquete definida previamente para un paquete dado que es usado para manipular los paquetes y datos que son transferidos. Como será fácilmente evidente, los paquetes pueden tener longitudes seleccionadas previamente o pueden tener longitudes variables o cambiables de manera dinámica dependiendo de sus funciones respectivas. Asimismo, los paquetes podrían llevar diferentes nombres, aunque aún se realiza la misma función, como puede ocurrir cuando los protocolos son cambiados durante aceptación en un estándar. Los bytes o valores de byte usados en los diversos paquetes están configurados como enteros sin signo de múltiples bits (8 o 16 bits) . Un resumen de los paquetes que se emplean junto con sus designaciones de "tipo", listados en orden de tipo, se muestra en los cuadros VI-1 al VI-4. Cada cuadro representa un "tipo" general de paquete dentro de la estructura de paquete general para facilidad en la ilustración y comprensión. No existe limitación u otro impacto implicado o expresado para la invención por estos agrupamientos, y los paquetes se pueden organizar en muchas otras maneras como se desee. También se indica la dirección en la cual la transferencia de un paquete se considera válida.

Cuadro VI-1 Paquetes de control de enlace Cuadro VI-2 Paquetes de flujo de medios básicos Cuadro VI-3 Paquetes de estado y control del cliente Cuadro VI-4 Paquetes de gráficos y visualización avanzados Algo que está claro de otras discusiones dentro de este texto es que aunque cada uno de el Paquete de Encapsulación Inversa, Paquete de Capacidad del Cliente y Paquete de Solicitud y Estado del cliente se consideran muy importantes para muchas modalidades de interfases de comunicación, o se consideran incluso requeridos en las mismas, para operación de Modo Externo, puede ser o es más probable que sean considerados opcionales para operación de Modo Interno.

Esto crea otro tipo de protocolo de interfase MDD que permite la comunicación de datos a velocidades muy altas con una serie reducida de paquetes de comunicaciones y simplificación del control y temporización correspondiente. Los paquetes tienen una estructura básica común o serie general de campos mínimos que comprenden un campo de Longitud de Paquete, un campo de Tipo de Paquete, campo (s) de Bytes de Datos y un campo de CRC, que se ilustra en la figura 7. Como se muestra en la figura 7, el campo de Longitud de Paquete contiene información, en forma de un valor de múltiples bits o bytes, que especifica el número total de bits en el paquete, o su longitud entre el campo de longitud de paquete y el campo de CRC . En una modalidad, el campo de longitud de paquete contiene un entero sin signo de 16 bits o 2 bytes de ancho, que especifica la longitud de paquete. El campo de Tipo de Paquete es otro campo de múltiples bits el cual designa el tipo de información que está contenida dentro del paquete . En una modalidad ejemplar, este es un valor de 16 bits o 2 bytes y de ancho, en forma de un entero sin signo de 16 bits, y especifica tipos de datos como capacidades de pantalla, cesión, flujos de video o audio, estado, y así sucesivamente . Un tercer campo es un campo de Bytes de Datos, el cual contiene los bits o datos que están siendo transferidos o enviados entre el aparato central y el aparato cliente como parte de ese paquete. El formato de los datos es definido específicamente para cada tipo de paquete de acuerdo con el tipo específico de los datos que están siendo transferidos y se puede separar en una serie de campos adicionales, cada uno con sus propios requerimientos de formato. Esto es, cada tipo de paquete tendrá un formato definido para esta porción o campo. El último campo es el campo de CRC el cual contiene los resultados de una verificación de redundancia cíclica de 16 bits calculada en los campos de Bytes de Datos, Tipo de Paquete y Longitud de Paquete, que se usa para confirmar la integridad de la información en el paquete. En otras palabras, calculada en el paquete entero excepto para el campo de CRC en sí. El cliente por lo general mantiene un conteo total de los errores de CRC detectados e informa este conteo al aparato central en el Paquete de Solicitud y Estado del Cliente (ver más adelante) . En general, estas anchuras y organización de campos están diseñadas para mantener campos de 2 bytes alineados en un límite de byte uniforme, y campos de 4 bytes alineados en límites de 4 bytes . Esto permite que estructuras de paquetes sean incorporadas fácilmente en un espacio de memoria principal de, o asociado con, un aparato central y un cliente sin violar las reglas de alineación de tipo de datos encontradas para la mayoría de los procesadores o circuitos de control o los procesadores o circuitos de control típicamente usados . Durante la transferencia de los paquetes, los campos son transmitidos empezando con el Bit Menos Significativo (LSB) primero y terminando con el Bit Más Significativo (MSB) transmitido al último. Los parámetros que tienen una longitud superior a un byte son transmitidos usando el byte menos significativo primero, lo cual da por resultado el mismo patrón de transmisión de bits que se usa para un parámetro con una longitud mayor a 8 bits, como se usa para un parámetro más corto donde el LSB es transmitido primero. Los campos de datos de cada paquete son generalmente transmitidos en el orden en que son definidos en las secciones subsiguientes que aparecen más adelante, donde el primer campo listado es transmitido primero y el último campo descrito es transmitido al último. Los datos en la trayectoria de señal MDDI_Datos0 están alineados con el bit ?0' de bytes transmitidos en la interfase en cualquiera de los modos Tipo 1, Tipo 2, Tipo 3 o Tipo 4. Al manipular datos para pantallas, los datos para series de pixeles son transmitidos por hileras primero, luego columnas, como se hace tradicionalmente en las técnicas de electrónica. En otras palabras, todos los pixeles que aparecen en la misma hilera en un mapa de bits son transmitidos en orden donde el pixel de la extrema izquierda se transmite primero y el pixel de la extrema derecha se transmite al último. Después de que el pixel de la extrema derecha de una hilera es transmitido luego el siguiente pixel en la secuencia es el pixel de la extrema izguierda de la siguiente hilera. Las hileras de pixeles son generalmente transmitidas en orden de la parte superior a la parte inferior para la mayoría de las pantallas, aunque se pueden admitir otras configuraciones como sea necesario. Además, al manejar mapas de bits, el enfoque convencional, el cual se sigue aquí, es definir un punto de referencia al etiquetar la esquina superior izquierda de un mapa de bits como ubicación o desplazamiento "0,0". Las coordenadas X y Y usadas para definir o determinar una posición en el mapa de bits incrementan en valor a medida que uno se acerca a la derecha y parte inferior del mapa de bits, respectivamente. La primera hilera y la primera columna (esquina superior izquierda de una imagen) empiezan con un valor de índice de cero. La magnitud de la coordenada X incrementa hacia el lado derecho de la imagen y la magnitud de la coordenada Y incrementa hacia la parte inferior de la imagen como es visto 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 visualización físico. Con frecuencia ocurre que el tamaño de pantalla y el mapa de bits son del mismo tamaño. La esquina superior izquierda de una ventana de pantalla siempre despliega la ubicación de pixel de mapa de bits '0,0'. El ancho de la ventana de pantalla corresponde al eje X del mapa de bits, y el ancho de ventana de pantalla para esta modalidad es menor a o igual al ancho del mapa de bits correspondiente. La altura de la ventana corresponde al eje Y del mapa de bits y la altura de la ventana de pantalla para esta modalidad es menor a o igual a la altura del mapa de bits correspondiente. La ventana de pantalla en sí no se aborda en el protocolo porque está solamente definida como la porción visible de un mapa de bits . La relación entre mapas de bits y ventanas de pantalla es bien conocida en la técnica informática, electrónica, de comunicación de Internet y otras técnicas relacionadas con la electrónica. Por lo tanto, no se proporciona aquí mayor discusión o ilustración de estos principios .

C. Definiciones de paquete 1. Paquete de cabecera de subcuadro El paquete de Cabecera de Subcuadro es el primer paquete para cada subcuadro y tiene una estructura básica como se ilustra en la figura 8. El Paquete de Cabecera de Subcuadro se usa para sincronización aparato central-cliente, cada aparato central debe ser capaz de generar este paquete, mientras que cada cliente debe ser capaz de recibir e interpretar este paquete . Como se puede ver en una modalidad en la figura 8, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Palabra Única, Reservado 1, Longitud de Subcuadro, Versión de Protocolo, Conteo de Subcuadros y Conteo de Cuadros de Medios, generalmente en ese orden. En una modalidad, este tipo de paquete es generalmente identificado como un paquete Tipo 15359 (0 x 3 bff hexadecimal) y usa una longitud fija seleccionada previamente de 20 bytes, que no incluye el campo de longitud de paquete . El campo de Tipo de Paquete y el campo de Palabra Única usa cada uno un valor de 2 bytes (entero sin signo de 16 bits) . La combinación de 4 bytes de estos dos campos juntos forma una palabra única de 32 bits con una buena autocorrelación. En una modalidad, la palabra única real es 0x005a3bff, donde los 16 bits inferiores son transmitidos primero como el Tipo de Paquete, y los 16 bits más significativos son transmitidos después . El campo de Reservado 1 contiene 2 bytes que son espacio reservado para uso futuro y generalmente está configurado en este punto con todos los bits ajustados a cero. Un .propósito de este campo es hacer que los campos de 2 bytes subsiguientes se alineen con una dirección de palabra de 16 bits y hacer que los campos de 4 bytes se alineen con una dirección de palabra de 32 bits. El byte menos significativo está reservado para indicar si un aparato central es o no capaz de dirigir múltiples aparatos cliente. Un valor de cero para este byte está reservado para indicar que el aparato central es capaz de operar solamente con un solo aparato cliente. El campo de Longitud de Subcuadro contiene cuatro bytes de información, o valores, que especifica el número de bytes por subcuadro. En una modalidad, la longitud este campo se puede ajustar igual a cero para indicar que solamente un subcuadro será transmitido por el aparato central antes de que el enlace sea interrumpido para entrar en un estado inactivo. El valor en este campo puede ser cambiado de manera dinámica sobre la marcha al cambiar de un subcuadro al siguiente. Esta capacidad es útil a fin de hacer ajustes de temporización menores en los pulsos de sincronización para admitir flujos de datos isócronos. Si el CRC del paquete de Cabecera de Subcuadro no es válido, entonces el controlador de enlace debe usar la Longitud de Subcuadro del paquete de Cabecera de Subcuadro conocido anterior para estimar la longitud del subcuadro actual . El campo de Versión de Protocolo contiene 2 bytes que especifican la versión de protocolo usada por el aparato central. El campo de Versión de Protocolo se puede ajustar a 0' para especificar la primera versión o versión actual del protocolo como se está usando. Este valor cambiará con el tiempo a medida que se creen nuevas versiones y ya está siendo mejorado a un valor de'l' para algunos campos de versión. Los valores de versión probable o generalmente seguirán un número de versión actual para un documento de estándares aprobados que cubre interfases tales como MDDI, como sería conocido. El campo de Conteo de Subcuadros contiene 2 bytes que especifican un número de secuencia que indica el número de subcuadros que han sido transmitidos desde el inicio del cuadro de medios . El primer subcuadro del cuadro de medios tiene un Conteo de Subcuadros de cero. El último subcuadro del cuadro de medios tiene un valor de n-1, donde n es el número de subcuadros por cuadro de medios . El valor del campo de Conteo de Subcuadros es igual al Conteo de Subcuadros enviado en el paquete de Subcuadro anterior más 1, excepto por un primer subcuadro de un cuadro de medios que tendrá un conteo de cero. Observar que si la Longitud de Subcuadro se ajusta igual a cero (indicando un subcuadro no periódico) entonces el conteo de Subcuadros se ajusta también igual a cero . El campo de Conteo de Cuadros de Medios contiene 4 bytes (entero sin signo de 32 bits) que especifican un número de secuencia que indica el número de cuadros de medios que han sido transmitidos desde el inicio del presente elemento de medios o datos que son transferidos. El primer cuadro de medios de un elemento de medios tiene un Conteo de Cuadros de Medios de cero. El Conteo de Cuadros de Medios incrementa justo antes del primer subcuadro de cada cuadro de medios y salta de regreso a cero después de que el Conteo de Cuadros de Medios máximo (por ejemplo, número de cuadros de medios 23~1 = 4,294,967,295) es usado. El valor de Conteo de Cuadros de Medios puede ser restablecido generalmente en cualquier momento por el Aparato central para adaptarse a las necesidades de una aplicación final. 2. Paquete de relleno Un paquete de relleno es un paquete que es transferido a, o desde, un aparato cliente cuando no está disponible otra información para ser enviada ya sea en el enlace hacia adelante o el enlace inverso. Se recomienda que los paquetes de relleno tengan una longitud mínima a fin de permitir una máxima flexibilidad al enviar otros paquetes cuando se requiere . Al final de un subcuadro o un paquete de encapsulación de enlace inverso (ver más adelante) , un controlador de enlace fija el tamaño del paquete de relleno para llenar el espacio restante para mantener la integridad del paquete. El Paquete de Relleno se usa para mantener la temporización en el enlace cuando el aparato central o cliente no tienen información que enviar o intercambiar. Cada aparato central y cliente necesita ser capaz de enviar y recibir este paquete para hacer un uso efectivo de la interfase. Una modalidad ejemplar del formato y contenido de un Paquete de Relleno se muestra en la figura 9. Como se muestra en la figura 9, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Bytes de Relleno y CRC. En una modalidad, este tipo de paquete es generalmente identificado como un Tipo 0, el cual está indicado en el campo de Tipo de 2 bytes . Los bits o bytes en el campo de Bytes de Relleno comprenden un número variable de todos los valores de bits cero para permitir que el paquete de relleno sea de la longitud deseada. El paquete de relleno más pequeño no contiene bytes en este campo. Esto es, el paquete consiste de solamente la longitud de paquete, tipo de paquete y CRC, y en una modalidad usa una longitud fija seleccionada previamente de 6 bytes o un valor de Longitud de Paquete de 4. El valor de CRC es determinado para todos los bytes en el paquete incluyendo la Longitud de Paquete, la cual se puede excluir en algunos otros tipos de paquete . 3. Paquete de flujo de video Los Paquetes de Flujo de Video llevan datos de video para actualizar típicamente regiones rectangulares de un dispositivo de visualización. El tamaño de esta región puede ser tan pequeño como un solo pixel o tan grande como la pantalla entera. Puede haber un número casi ilimitado de flujos desplegados de manera simultánea, limitado por los recursos del sistema, porque todo el contexto requerido para desplegar un flujo está contenido dentro del Paquete de Flujo de Video. El formato de una modalidad de un Paquete de Flujo de Video (Descriptor de Formato de Datos de Video) se muestra en la figura 10. Como se ve en la figura 10, en una modalidad, este tipo de paquete está estructurado para tener campos de Longitud de Paquete (2 bytes) , Tipo de Paquete, ID de Cliente b, Descriptor de Datos de Video, Atributos de Visualización de Pixel, Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, Inicio X y Y, Conteo de Pixeles, CRC de Parámetro, Datos de Pixel, y CRC de Datos de Pixel. Este tipo de paquete está generalmente identificado como un Tipo 16, lo cual está indicado en el campo de Tipo de 2 bytes . En una modalidad, un cliente indica una capacidad de recibir un Paquete de Flujo de Video usando los campos de capacidad RVA, monocroma y Y Cr Cb del Paquete de Capacidad del Cliente. En una modalidad, el campo de ID de Cliente b contiene 2 bytes de información que están reservados para una ID de Cliente. Debido a que éste es un protocolo de comunicaciones recién desarrollado, las ID de clientes reales no se conocen aún o no se pueden comunicar en forma suficiente. Por lo tanto, los bits en este campo generalmente son fijados igual a cero hasta que se conocen tales valores de ID, tiempo en el cual los valores de ID pueden ser insertados o usados, como sería evidente para los expertos en la técnica. El mismo proceso será generalmente cierto para los campos de ID de cliente que se discuten más adelante. El concepto de cuadro común discutido anteriormente constituye una manera efectiva de reducir al mínimo el tamaño de memoria intermedia de audio y reducir la latencia. Sin embargo, para datos de video puede ser necesario esparcir los pixeles de un cuadro de video en múltiples Paquetes de Flujo de Video dentro de un cuadro de medios. Asimismo, es muy probable que los pixeles en un solo Paquete de Flujo de Video no correspondan de manera exacta con una ventana rectangular perfecta en la pantalla. Para el índice de cuadro de video ejemplar de 30 cuadros por segundo, existen 300 subcuadros por ' segundo, lo cual da por resultado 10 subcuadros por cuadro de medios. Si hay 480 hileras de pixeles en cada cuadro, cada Paquete de Flujo de Video en cada subcuadro contendrá 48 hileras de pixeles. En otras situaciones, el Paquete de Flujo de Video pudiera no contener un número entero de hileras de pixeles. Esto es cierto para otros tamaños de cuadro de video donde el número de subcuadros por cuadro de medios no se divide de manera uniforme en el número de hileras (conocidas también como líneas de video) por cuadro de video. Para una operación eficiente, cada Paquete de Flujo de Video generalmente debe contener un número entero de pixeles, aunque pudiera no contener un número entero de hileras de pixeles. Esto es importante si los pixeles son de más de un byte cada uno, o si se encuentran en un formato empaquetado como se muestra en la figura 12. El formato y contenido empleados para realizar la operación de un campo de Descriptor de Datos de Video ejemplar, como se menciona con anterioridad, se muestran en las figuras 11A-11E. En las figuras 11A-11E, el campo de Descriptor de Formato de Datos de Video contiene 2 bytes en forma de un entero sin signo de 16 bits que especifica el formato de cada pixel en los Datos de Pixel en el presente flujo en el presente paquete. Es posible que diferentes paquetes de Flujo de Video puedan usar diferentes formatos de datos de pixel, esto es, usar un valor diferente en el Descriptor de Formato de Datos de Video, y de manera similar, un flujo (región de la pantalla) puede cambiar su formato de datos sobre la marcha. El formato de datos de pixel debe cumplir con por lo menos uno de los formatos válidos para el cliente como es definido en el Paquete de Capacidad del cliente. El Descriptor de Formato de Datos de Video define el formato de pixel para el presente paquete solamente, lo cual no implica que un formato constante se seguirá usando durante el tiempo de vida de un flujo de video particular. Las figuras HA a 11D ilustran cómo se codifica el Descriptor de Formato de Datos de Video. Como se usa en estas 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 de una serie .de pixeles monocromo donde el número de bits por pixel es definido por los bits 3 al 0 de la palabra Descriptor de Formato de Datos de Video. Los bits 11 al 4 están generalmente reservados para uso o aplicaciones futuras y se ajustan a cero en esta situación. En cambio, cuando los bits [15:13] son iguales a los valores '001', como se muestra en la figura 11B, entonces los datos de video consisten de una serie de pixeles de color que especifican cada uno un color a través de un mapa de colores (paleta) . En esta situación, los bits 5 al 0 de la palabra Descriptor de Formato de Datos de Video define el número de bits por pixel, y los bits 11 al 6 están generalmente reservados para uso o aplicaciones futuras y se ajustan igual a cero. En cambio, cuando los bits [15:13] son iguales a los valores ?010', como se muestra en la figura 11C, entonces los datos de video consisten de una serie de pixeles de color donde el número de bits por pixel de rojo es definido por los bits 11 al 8, el número de bits por pixel de verde es definido por los bits 7 al 4, y el número de bits por pixel de azul es definido por los bits 3 al 0. En esta situación, el número total de bits en cada pixel es la suma del número de bits usados para rojo, verde y azul. No obstante, cuando los bits [15:13] son en cambio iguales a los valores o cadena '011', como se muestra en la figura 11D, entonces los datos de video consisten de una serie de datos de video en formato 4:2:2 YCbCr con información de luminancia y crominancia, donde el número de bits por pixel de luminancia (Y) es definido por los bits 11 al 8, el número de bits del componente Cb es definido por los bits 7 al 4, y el número de bits del componente Cr es definido por los bits 3 al 0. El número total de bits en cada pixel es la suma del número de bits usados para rojo, verde y azul. Los componentes Cb y Cr son enviados a la mitad del índice como Y. Además, las muestras de video en la porción de Datos de Pixel de este paquete están organizadas como sigue: Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3,... donde Cbn y Crn están asociados con Yn y Yn+1, y Cbn+2 y Crn+2 están asociados con Yn+2 y Yn+3, y así sucesivamente . Yn, Yn+1, Yn+2 y Yn+3 son valores de luminancia de cuatro pixeles consecutivos en una sola hilera de izquierda a derecha. Si hay un número impar de pixeles en una hilera (Borde Derecho X - Borde Izquierdo X +1) en la ventana a la que hace referencia el Paquete de Flujo de Video, entonces el valor Y correspondiente al último pixel en cada hilera estará seguido del valor Cb del primer pixel de la siguiente hilera, y un valor Cr no es enviado para el último pixel en la hilera. Se recomienda que las ventanas que usan formato Y Cb Cr tengan un ancho que sea un número par de pixeles . Los Datos de Pixel en un paquete deben contener un número par de pixeles . Puede contener un número impar o par de pixeles en el caso donde el último pixel de los Datos de Pixel corresponde al último pixel de una hilera en la ventana especificada en la cabecera de Paquete de Flujo de Video, es decir, cuando la ubicación X del último pixel en los Datos de Pixel es igual al Borde Derecho X. Cuando los bits [15:13] son en cambio iguales a los valores ?100', entonces los datos de video consisten de una serie de pixeles Bayer donde el número de bits por pixel es definido por los bits 3 al 0 de la palabra Descriptor de Formato de Datos de Video. El Patrón de Grupo de Pixeles es definido por los bits 5 y 4 como se muestra en la figura HE. El orden de los datos de pixel puede ser horizontal o vertical, y los pixeles en hileras o columnas pueden ser enviados en orden hacia adelante o hacia atrás y está definido por los bits 8 al 6. Los bits 11 al 9 se deben ajustar a cero. El grupo de cuatro pixeles en el grupo de pixeles en el formato Bayer se asemeja a lo que con frecuencia es llamado un solo pixel en algunas tecnologías de visualización. Sin embargo, un pixel en el formato Bayer es solamente uno de los cuatro pixeles de color del patrón de mosaico de grupo de pixeles . Para los cinco formatos mostrados en las figuras, el bit 12, el cual está designado como "P", especifica si las muestras de Datos de Pixel son o no datos de pixel empaquetados o alineados por bytes . Un valor de'O' en este campo indica que cada pixel en el campo de Datos de Pixel está alineado por bytes con un límite de byte de interfase MDD. Un valor de'l' indica que cada pixel y cada color dentro de cada pixel en los Datos de Pixel están empaquetados contra el pixel anterior o color dentro de un pixel sin dejar bits sin usar. La diferencia entre el formato de datos Alineado por Bytes y Pixel Empaquetado se muestra en más detalle en la figura 12, donde se puede ver claramente que los datos alineados por bytes pueden dejar porciones sin usar del subcuadro de datos, a diferencia del formato de pixel empaquetado que no lo hace. El primer pixel en el primer paquete de flujo de video de un cuadro de medios para una ventana de pantalla particular irá en la esquina superior izquierda de la ventana de flujo definida por un Borde Izquierdo X y un Borde Superior Y, y el siguiente pixel recibido es colocado en la siguiente ubicación de pixel en la misma hilera, y así sucesivamente. En este primer paquete de un cuadro de medios, el valor de inicio X usualmente será igual al Borde Izquierdo X, y el valor de inicio Y será usualmente igual al Borde Superior Y. En paquetes subsiguientes correspondientes a la misma ventana de pantalla, los valores de inicio X y Y usualmente se ajustarán a la ubicación de pixel en la ventana de pantalla que normalmente seguiría después del último pixel enviado en el Paquete de Flujo de Video que fue transmitido en el subcuadro anterior. 4. Paquete de flujo de aud±o Los paquetes de flujo de audio llevan datos de audio para ser reproducidos a través del sistema de audio del cliente, o para un dispositivo de presentación de audio independiente. Diferentes flujos de datos de audio pueden ser asignados para canales de audio separados en un sistema de sonido, por ejemplo: izquierdo anterior, derecho anterior, centro, izquierdo posterior y derecho posterior, dependiendo del tipo de sistema de audio que se está usando. Un complemento completo de canales de audio es provisto para diademas que contienen un procesamiento de señal espacial acústica mejorado. Un cliente indica una capacidad de recibir un Paquete de Flujo de Audio usando los campos de Capacidad de Canal de Audio e índice de Muestra de Audio del Paquete de Capacidad del Cliente . El formato de Paquetes de Flujo de Audio se ilustra en la figura 13. Como se muestra en la figura 13, este tipo de paquete está estructurado en una modalidad para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente b, ID de Canal de Audio, Reservado 1, Conteo de Muestras de Audio, Bits por Muestra y Empaquetado, índice de Muestra de Audio, CRC de Parámetro, Datos de Audio Digitales y CRC de Datos de Audio. En una modalidad, este tipo de paquete es generalmente identificado como un paquete Tipo 32. El campo de ID de Cliente b contiene 2 bytes de información que están reservados para una ID de Cliente, como se usó anteriormente. El campo de Reservado 1 contiene 2 bytes que están reservados para uso futuro, y está generalmente configurado en este punto con todos los bits ajustados a cero. El campo de Bits por Muestra y Empaquetado contiene 1 byte en forma de un entero sin signo de 8 bits que especifica el formato de empaquetado de datos de audio. El formato generalmente empleado es para los Bits 4 al 0 para definir el número de bits por muestra de audio PCM. El bit 5 especifica entonces si las muestras de Datos de Audio Digitales están o no empaquetadas . La diferencia entre muestras de audio empaquetadas y alineadas por bytes, que aquí usan 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 está alineada por bytes con un límite de byte de interfase MDDI, y un valor de'l' indica que cada muestra de audio PCM consecutiva está empaquetada contra la muestra de audio anterior. Este bit es generalmente efectivo solamente cuando el valor definido en los bits 4 al 0 (el número de bits por muestra de audio PCM) no es un múltiplo de ocho. Los bits 7 al 6 están reservados para uso futuro y por lo general están ajustados a un valor de cero. 5. Paquetes de flujo reservados En una modalidad, los paquetes tipos 1 a 15, 18 a 31, y 33 a 35 están reservados para paquetes de flujo que se van a definir para uso en versiones o variaciones futuras de los protocolos de paquete, como se desea para diversas aplicaciones encontradas. De nuevo, esta parte de hacer la interfase MDD más flexible y útil haciendo frente a tecnologías y diseño de sistema siempre cambiantes en comparación con otras técnicas . 6. Paquetes de flujo definidos por el usuario Ocho tipos de flujos de datos, conocidos como Tipos 56 al 63, están reservados para usar en aplicaciones propietarias que pueden ser definidas por fabricantes de equipo para usar con un enlace de MDDI . Estos se conocen como Paquetes de Flujo Definidos por el Usuario. Estos . paquetes se pueden usar para cualquier propósito, pero el aparato central y cliente deben emplear únicamente tales paquetes en situaciones donde el resultado de dicho uso es muy bien comprendido o conocido. La definición especifica de los parámetros de flujo y datos para estos tipos de paquetes se deja a los fabricantes de equipo o diseñadores de interfase específicos que implementan tales tipos de paquete o buscan su uso. Algunos usos ejemplares de los Paquetes de Flujo Definidos por el Usuario son para llevar parámetros de pruebas y resultados de pruebas, datos de calibración de fábrica y datos de uso especial propietario. El formato de los paquetes de flujo definidos por el usuario como se usa 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) , Tipo de Paquete, número de ID de Cliente b, Parámetros de Flujo, CRC de Parámetro, Datos de Flujo y CRC de Datos de Flujo . 7. Paquetes de mapa de colores Los paquetes de mapa de colores especifican el contenido de una tabla de búsqueda de mapa de colores usada para presentar colores para un cliente. Algunas aplicaciones pueden requerir un mapa de colores que sea más grande que la cantidad de datos que pueden ser transmitidos en un solo paquete. En esos casos, se pueden transferir múltiples paquetes de Mapa de Colores, cada uno con una subserie diferente del mapa de colores usando los campos de desplazamiento y longitud que se describen más adelante. El formato del Paquete de Mapa de Colores en una modalidad se ilustra en la figura 16. Como se muestra en la figura 16, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente h, Conteo de Elementos de Mapa de Colores, Desplazamiento de Mapa de Colores, CRC de Parámetro, Datos de Mapa de Colores y CRC de Datos . En una modalidad, este tipo de paquete es generalmente identificado como un paquete Tipo 64 (Formato de Datos de Video y Paquete de Mapa de Colores) como se especifica en el Campo Tipo de Paquete (2 bytes) . Un cliente indica una capacidad de recibir Paquetes de Mapa de Colores usando los campos de Tamaño de Mapa de Colores y Ancho de Mapa de Colores del Paquete de Capacidad del Cliente . 8. Paquetes de encapsulación de enlace inverso En una modalidad ejemplar, los datos son transferidos en la dirección inversa usando un Paquete de Encapsulación de Enlace Inverso . Un paquete de enlace hacia adelante es enviado y la operación de enlace de MDDI (dirección de transferencia) es cambiada o su sentido es invertido en la mitad de este paquete de manera que los paquetes puedan ser enviados en la dirección inversa. El formato del paquete de Encapsulación de Enlace Inverso en una modalidad se ilustra en la figura 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 Cliente h, Banderas de Enlace Inverso, Divisor de índice Inverso, Longitud de Inversión de Sentido 1, Longitud de Inversión de Sentido 2, CRC de Parámetro, Todo Cero 1, Inversión de Sentido 1, Paquetes de Datos Inversos, Inversión de Sentido 2 y Todo Cero 2. En una modalidad, este tipo de paquete es generalmente identificado como un paquete Tipo 65. Para Modo Externo cada aparato central debe ser capaz de generar este paquete y recibir datos, y cada cliente debe ser capaz de recibir y enviar datos al aparato central a fin de hacer uso de manera eficiente del protocolo deseado y velocidad resultante. La implementación de este paquete es opcional para Modo Interno, pero el Paquete de Encapsulación de Enlace Inverso se usa para que el aparato central reciba datos del cliente. El controlador de enlace de MDDI se comporta en una manera especial mientras envía un Paquete de Encapsulación de Enlace Inverso. La interfase MDD tiene una señal de validación que generalmente es siempre impulsada por el aparato central como controlador del enlace. El aparato central se comporta como si estuviera transmitiendo un cero para cada bit de las porciones de Inversión de Sentido y Paquetes de Datos Inversos del paquete de Encapsulación de Enlace Inverso. El aparato central conmuta una señal MDDI_Señal de Validación en cada límite de bit durante los dos tiempos de inversión de sentido y durante el tiempo asignado para paquetes de datos inversos . (Éste es el mismo comportamiento que si estuviera transmitiendo datos todo cero) . El aparato central inhabilita sus excitadores de línea de señal de datos MDDI durante el periodo de tiempo especificado por Inversión de Sentido 1, y el cliente vuelve a habilitar sus excitadores de línea durante el campo de Rehabilitación de Excitador siguiendo el periodo de tiempo especificado por el campo de Inversión de Sentido 2. El cliente lee el parámetro de Longitud de Inversión de Sentido e impulsa las señales de datos hacia el aparato central inmediatamente después del último bit en el campo de Inversión de Sentido 1. Esto es, el cliente sincroniza por reloj nuevos datos en el enlace en ciertos flancos de subida de la señal de validación MDDI como se especifica en la descripción de contenido de paquete más adelante, y en otra parte. El cliente usa los parámetros de Longitud de Paquete y Longitud de Inversión de Sentido para conocer el lapso de tiempo que tiene disponible para enviar paquetes al aparato central . El cliente puede enviar paquetes de relleno o impulsar las líneas de datos a un estado de cero cuando no tiene datos que enviar al aparato central. Si las líneas de datos son impulsadas a cero, el aparato central interpreta esto como un paquete con una longitud cero (no es una longitud válida) y el aparato central no acepta más paquetes del cliente mientras dura el Paquete de Encapsulación de Enlace Inverso actual . El aparato central impulsa las señales MDDI_Datos al nivel de cero lógico durante el campo Todo Cero 1, y un cliente impulsa las líneas de datos MDDI a un nivel de cero lógico durante al menos un periodo de reloj de enlace inverso antes del inicio del campo de Inversión de Sentido 2, esto es durante el periodo de campo de Todo Cero 2. Esto mantiene las líneas de datos en un estado determinista durante el periodo de tiempo de los campos de Inversión de Sentido 1 e Inversión de Sentido 2. Si el cliente no tiene más paquetes que enviar, puede incluso inhabilitar las líneas de datos después de impulsarlas a un nivel de cero lógico porque los resistores de polarización de hibernación (que se discuten en otra parte) mantienen las líneas de datos a un nivel de cero lógico por el resto del campo de Paquetes de Datos Inversos, o una duración de aproximadamente 16 bytes de enlace hacia adelante o más . En una modalidad, el campo de Solicitud de Enlace Inverso del Paquete de Solicitud y Estado de Cliente se puede usar para informar al aparato central del número de bytes que el cliente necesita en el Paquete de Encapsulación de Enlace Inverso para enviar datos de vuelta al aparato central . El aparato central intenta conceder la solicitud asignando por lo menos ese número de bytes en el Paquete Encapsulación de Enlace Inverso. El aparato central puede enviar más de un Paquete de Encapsulación de Enlace Inverso en un subcuadro. El cliente puede enviar un Paquete de Solicitud y Estado de Cliente casi en cualquier momento, y el aparato interpretará el parámetro de Solicitud de Enlace Inverso como el número total - de bytes requeridos en un subcuadro . 9. Paquetes de capacidad de cliente Un aparato central necesita conocer la capacidad del cliente (pantalla) con el cual se está comunicando a fin de configurar el enlace aparato central-a-cliente en una manera generalmente óptima o deseada. Se recomienda que una pantalla envíe un Paquete de Capacidad del Cliente al aparato central después de que se adquiera sincronización de enlace hacia adelante. La transmisión de dicho paquete se considera requerida cuando es solicitada por el aparato central usando las Banderas de Enlace Inverso en el Paquete de Encapsulación de Enlace Inverso. El Paquete de Capacidad del cliente es usado para informar al aparato central las capacidades de un cliente. Para Modo Externo cada aparato central debe ser capaz de recibir este paquete, y cada cliente debe ser capaz de enviar este paquete para utilizar por completo esta interfase y protocolo. La implementación de este paquete es opcional para Modo Interno, ya que las capacidades del cliente, tales como una pantalla, teclado u otro dispositivo de entrada/salida, en esta situación ya deben estar bien definidas y ser conocidas para el aparato central en el momento de fabricación o armado en un solo componente o unidad de algún tipo. El formato del Paquete de Capacidad del Cliente en una modalidad se ilustra en la figura 18. Como se muestra en la figura 18, para esta modalidad, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente c Reservado, Versión de Protocolo, Versión de Protocolo Min, Capacidad de índice de Datos, Capacidad de Tipo de Inferíase, Número de Pantallas Alt, Reservado 1, Ancho de Mapa de Bits, Altura de Mapa de Bits, Ancho de Ventana - de Pantalla, Altura de Ventana de Pantalla, Tamaño de Mapa de Colores, Ancho de RVA de Mapa de Colores, Capacidad RVA, Capacidad Monocroma, Reservado 2, Capacidad Y Cr Cb, Capacidad Bayer, Planos de Imagen de Alfa-Cursor, Capacidad de Características de Cliente, índice de Cuadro de Video Max, índice de Cuadro de Video Min, índice de Subcuadro Min, Profundidad de Memoria Intermedia de Audio, Capacidad de Canal de Audio, Capacidad de índice de Muestra de Audio, Resolución de Muestra de Audio, Resolución de Muestra de Audio Mic, Capacidad de índice de Muestra Mic, Formato de Datos de Teclado, Formato de Datos de Dispositivo Señalador, Tipo de Protección de Contenido, Nombre del Fabricante, Código de 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 es generalmente identificado como un paquete Tipo 66. 10. Paquetes de datos de teclado Un paquete de datos de teclado se usa para enviar datos de teclado del aparato cliente al aparato central. Un teclado inalámbrico (o alámbrico) se puede usar junto con diversas pantallas o dispositivos de audio, incluyendo, mas no limitado a, un visiocasco/dispositivo de presentación de audio. El Paquete de Datos de Teclado retransmite datos de teclado recibidos de uno de los varios dispositivos tipo teclado conocidos al aparato central. Este paquete se puede usar también en el enlace hacia adelante para enviar datos al teclado. Un cliente indica una capacidad de enviar y recibir Paquetes de Datos de Teclado usando el Campo de Datos de Teclado en el Paquete de Capacidad del 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 desde o para un teclado. Como se muestra en la figura 19, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente b, Formato de Datos de Teclado, Datos de Teclado y CRC. Aquí, este tipo de paquete es generalmente identificado como un paquete Tipo 67. El ID de Cliente b es un campo reservado, como antes, y el CRC se lleva a cabo en todos los bytes del paquete . El campo de Formato de Datos de Teclado contiene un valor de 2 bytes que describe el formato de datos de teclado. Los bits 6 al 0 deben ser idénticos al campo de Formato de Datos de Teclado en el Paquete de Capacidad del Cliente. Este valor no debe ser igual a 127. Los bits 15 al 7 están reservados para uso futuro y están, por consiguiente, actualmente ajustados a cero . 11. Paquetes de datos de dispositivo señalador Un paquete de datos de dispositivo señalador se usa como un método, estructura o medio para enviar información de posición desde un ratón inalámbrico u otro dispositivo señalador del cliente al aparato central. Los datos pueden ser enviados también al dispositivo señalador en el enlace hacia adelante usando este paquete. Un formato ejemplar de un Paquete de Datos de Dispositivo Señalador se muestra en la figura 20, y contiene un número variable de bytes de información de o para un dispositivo señalador. Como se muestra en la figura 20, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente b, Formato de Dispositivo Señalador, Datos de Dispositivo Señalador y CRC. En una modalidad ejemplar, este tipo de paquete es generalmente identificado como un paquete Tipo 68 en el campo de tipo de 1 byte . 12. Paquetes de interrupción de enlace Un Paquete de Interrupción de Enlace es enviado del aparato central al cliente como un método o medio para indicar que los datos y señal de validación MDDI serán interrumpidos y entrarán en un estado de "hibernación" de bajo consumo de potencia. Este paquete es útil para interrumpir el enlace y conservar potencia después de que mapas de bits estáticos son enviados de un dispositivo de comunicación móvil a la pantalla, o cuando no hay más información que transferir de un aparato central a un cliente por el momento. La operación normal es reanudada cuando el aparato central envía paquetes de nuevo . El primer paquete enviado después de la hibernación es un paquete de cabecera de subcuadro. 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 Ceros. En una modalidad, este tipo de paquete es generalmente identificado como un paquete tipo 69 en el campo de tipo de 1 byte . El campo de longitud de paquete usa 2 bytes para especificar el número total de bytes en el paquete sin incluir el campo de longitud de paquete. En una modalidad, la Longitud de Paquete de este paquete depende del Tipo de Inferíase o modo de enlace en uso en el momento cuando el Paquete de Interrupción de Enlace es enviado. Por lo tanto, la longitud de paquete típica se convierte en 20 bytes por modo Tipo 1 (22 bytes en total en el paquete) , 36 bytes para un modo Tipo 2 (38 bytes en total en el paquete) , 68 bytes para un enlace de modo Tipo 3 (70 bytes en total en el paquete) , y 132 bytes para un modo Tipo 4 (con 134 bytes en total en el paquete) . El campo de Todo Ceros usa un número variable de bytes para asegurar que las señales MDDI_Datos estén a un nivel de cero lógico durante un tiempo suficiente para permitir que el cliente empiece a recuperar el reloj usando solamente MDDI_Stb antes de inhabilitar los excitadores de línea de un aparato central. La longitud del campo de Todo Ceros depende del Tipo de Inferíase o modo de operación de enlace en uso en el momento cuando el Pagúete de Interrupción de Enlace es enviado . Se pretende que la longitud del campo de Todo Ceros produzca 64 pulsos en MDDI_Stb para cualquier ajuste de Tipo de Inferíase. Por lo tanto, la longitud de Todo Ceros para cada tipo de interfase se convierte en 16 bytes para Tipo 1, 32 bytes para Tipo 2, 64 bytes para Tipo 3 y 128 bytes para Tipo 4. El campo de CRC usa 2 bytes que contienen CRC de 16 bits de bytes de la Longitud de Paquete al Tipo de Paquete . En el estado de hibernación de potencia baja, el excitador de MDDI_DatosO es inhabilitado en un estado de alta impedancia iniciando después del 16° al 48° ciclo o pulso de MDDI_Stb después del último bit del campo de Todo Ceros. Para los enlaces Tipo 2, Tipo 3 o Tipo 4 las señales MDDI_Datosl a MDDI_DatosPwr7 son colocadas también en un estado de alta impedancia al mismo tiempo que el excitador de MDDI_DatosO es inhabilitado. Ya sea el aparato central o el cliente pueden hacer que el enlace de MDDI "despierte" del estado de hibernación como se describe en otra parte, lo cual es un avance clave para la presente invención y una ventaja de la misma. Como se describe en la definición del campo de Todo Ceros, MDDI_Stb conmuta durante 64 ciclos siguiendo el MSB del campo de CRC del Paquete de Interrupción de Enlace para facilitar una interrupción ordenada en el controlador de cliente. Un ciclo es una transición baja-a-alta seguida de una transición alta-a-baja, o una transición alta-a-baja seguida de una transición baja-a-alta. Después de que el campo de Todo Ceros es enviado, el excitador de MDDI_Stb en el aparato central es inhabilitado. 13. Paquetes de solicitud y estado de cliente El aparato central necesita una pequeña cantidad de información del cliente de manera que pueda configurar el enlace aparato central-a-cliente en una manera generalmente óptima. Se recomienda que el cliente envíe un Paquete de Solicitud y Estado de Cliente al aparato central cada subcuadro. El cliente debe enviar este paquete como el primer paquete en el Paquete de Encapsulación de Enlace Inverso para asegurar que sea entregado de manera confiable al aparato central . El reenvío de este paquete se lleva a cabo también cuando es solicitado por un aparato central usando las Banderas de Enlace Inverso en el Paquete de Encapsulación de Enlace Inverso. El Paquete de Solicitud y Estado de Cliente se usa para informar errores y estado al aparato central. Para operación en modo externo, cada aparato central debe ser capaz de recibir este paquete, y cada cliente debe ser capaz de enviar este paquete a fin de emplear de manera apropiada u óptima el protocolo de Inferíase MDD. Aunque también se recomienda que para operaciones internas, que son aparatos centrales internos y clientes internos, debe haber soporte para este paquete, no se requiere. El formato de un Paquete de Solicitud y Estado de Cliente se muestra en la figura 22. Como se muestra en la figura 22, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente c, Solicitud de Enlace Inverso, Cambio de Capacidad, Cliente Ocupado, Conteo de Errores de CRC y CRC. Este tipo de paquete está generalmente identificado como un paquete Tipo 70 en el campo de tipo de 1 byte y típicamente usa una longitud fija seleccionada previamente de 12 bytes . El campo de Solicitud de Enlace Inverso se puede usar para informar al aparato central del número de bytes que el cliente necesita en el Paquete de Encapsulación de Enlace Inverso para enviar datos de vuelta al aparato central . El aparato central debe intentar conceder la solicitud asignando al menos ese número de bytes en el Paquete de Encapsulación de Enlace Inverso. El aparato central puede enviar más de un Paquete de Encapsulación de Enlace Inverso en un subcuadro a fin de admitir datos . El cliente puede enviar un Paquete de Solicitud y Estado de Cliente en cualquier momento y el aparato central interpretará el parámetro de Solicitud de Enlace Inverso como el número total de bytes solicitados en un subcuadro. Detalles adicionales y ejemplos específicos de cómo los datos de enlace inverso son enviados de vuelta al aparato central se muestran más adelante. 14. Paquetes y transferencia de bloque de bits El Paquete de Transferencia de Bloque de Bits proporciona un medio, estructura o método para desplazarse en las regiones de la pantalla en cualquier dirección. Las pantallas que tienen esta capacidad informarán la capacidad en el bit 0 del campo de Indicadores de Capacidad de Características de Pantalla del Paquete de Capacidad del Cliente . El formato para una modalidad de un Paquete de Transferencia de Bloque de Bits se muestra en la figura 23. Como se muestra en la figura 23, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente h, Valor X Superior Izquierdo, Valor Y Superior Izquierdo, Ancho de Ventana, Altura de Ventana, Movimiento X de Ventana, Movimiento Y de Ventana y CRC. Este tipo de paquete es generalmente identificado como un paquete Tipo 71, y en una modalidad usa una longitud fija seleccionada previamente de 15 bytes. Los campos se usan para especificar los valores X y Y de la coordenada de la esquina superior izquierda de la ventana que se va a mover, el ancho y altura de la ventana que se va a mover, y el número de pixeles que la ventana va a mover de manera horizontal y vertical, respectivamente. Los valores positivos para los últimos dos campos hacen que la ventana sea movida a la derecha, y abajo, y los valores negativos causan movimiento a la izquierda y arriba, respectivamente. 15. Paquetes de relleno de área de mapa de bits El Paquete de Relleno de Área de Mapa de Bits provee un medio, estructura o método para inicializar fácilmente una región de la pantalla a un solo color. Las pantallas que tienen esta capacidad informarán la capacidad en el bit 1 del campo de Indicadores de Capacidad de Características de Cliente del Paquete de Capacidad del Cliente . Una modalidad para el formato de un Paquete de Relleno de Área de Mapa de Bits se muestra en la figura 24. Como se muestra en la figura 24, en este caso este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente h, 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 es generalmente identificado como un paquete Tipo 72 en el campo de tipo de 1 byte y usa una longitud fija seleccionada previamente de 17 bytes. 16. Paquetes de relleno de patrón de mapa de bits El Paquete de Relleno de Patrón de Mapa de Bits provee un medio o estructura para inicializar fácilmente una región de la pantalla a un patrón seleccionado previamente. Las pantallas que cuentan con esta capacidad informarán la capacidad en el bit 2 del campo de Capacidad de Características de Cliente del Paquete de Capacidad del Cliente. La esquina superior izquierda de patrón de relleno está alineada con la esquina superior izquierda de la ventana que se va a llenar, a menos que el desplazamiento de patrón horizontal o vertical sea no cero. Si la ventana que se va a llenar es más ancha o alta que el patrón de relleno, entonces el patrón se puede repetir de manera horizontal o vertical un número de veces para rellenar la ventana. La parte derecha o inferior del último patrón repetido es truncada como sea necesario. Si la ventana es más pequeña que el patrón de relleno, entonces el lado derecho o parte inferior del patrón de relleno se puede truncar para ajustarse a la ventana. Si un desplazamiento de patrón horizontal es no cero, entonces los pixeles entre el lado izquierdo de la ventana y el lado izquierdo más el desplazamiento de patrón horizontal son llenados con los pixeles de la extrema derecha del patrón. El desplazamiento de patrón horizontal debe ser menor al ancho del patrón. De manera similar, si un desplazamiento de patrón vertical es no cero, entonces los pixeles entre el lado superior de la ventana y la parte superior del lado más el desplazamiento de patrón vertical son llenados con los pixeles del extremo inferior del patrón. El desplazamiento de patrón vertical debe ser menor a la altura del patrón. Una modalidad para el formato de un Paquete de Relleno de Patrón de Mapa de Bits 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 Cliente h, Valor X Superior Izquierdo, Valor Y Superior Izquierdo, Ancho de Ventana, Altura de Ventana, Ancho de Patrón, Altura de Patrón, Desplazamiento de Patrón Horizontal, Desplazamiento de Patrón Vertical, Descriptor de Formato de Datos, CRC de Parámetro, Datos de Pixel de Patrón y CRC de Datos de Pixel. En algunas modalidades, este tipo de paquete es generalmente identificado como un paquete Tipo 73 en el campo de tipo de 1 byte. 17. Paquetes de canal de datos de enlace de comunicación El Paquete de Canal de Datos de Enlace de Comunicación provee una estructura, medio, o método para que un cliente con capacidad informática de alto nivel, como por ejemplo, un PDA, se comunique con un transceptor inalámbrico tal como un teléfono celular o dispositivo de puerto de datos inalámbrico. En esta situación, el enlace de MDDI está actuando como una interfase a alta velocidad conveniente entre el dispositivo de comunicación y el dispositivo informático con la pantalla móvil, donde este paquete transportar datos a una Capa de Enlace de Datos de un sistema operativo para el dispositivo. Por ejemplo, este paquete se podría usar si un explorador de web, cliente de correo electrónico o un PDA completo estuviera incorporado en una pantalla móvil. Las pantallas que tienen esta capacidad informarán la capacidad en el bit 3 del campo de Capacidad de Características de Cliente del Paquete de Capacidad del Cliente . El formato de una modalidad para un Paquete de Canal de Datos de 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 Cliente h, CRC de Parámetro, Datos de Enlace de Comunicación y CRC de Datos de Comunicación. En una modalidad, este tipo de paquete es generalmente identificado como un paquete Tipo 74 en el campo de tipo. 18. Paquetes de solicitud de cesión de tipo de interfase El Paquete de Solicitud de Cesión de Tipo de Inferíase provee un medio, método o estructura que permite que el aparato central solicite que el cliente 0 pantalla cambie de un modo existente o actual a los modos Tipo 1 (serie) , Tipo 2 (paralelo de 2 bits) , Tipo 3 (paralelo de 4 bits) , o Tipo 4 (paralelo de 8 bits) . Antes de que el aparato central solicite un modo particular debe confirmar que el cliente es capaz de operar en el modo deseado examinando los bits 6 y 7 del campo de Indicadores de Capacidad de Características de Pantalla del Paquete de Capacidad del Cliente . Una modalidad para un formato de un Paquete de Solicitud de Cesión de Tipo de Inferíase 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 de Inferíase, Reservado 1 y CRC. Este tipo de paquete es generalmente identificado como un paquete Tipo 75, y usa una longitud fija seleccionada previamente de 4 bytes. 19. Paquetes de confirmación de tipo de interfase El Paquete de Confirmación de Tipo de Inferíase es enviado por un cliente y provee un medio, método o estructura que permite que un cliente confirme recibo del Paquete de Cesión de Tipo de Inferíase . El modo solicitado, modo Tipo 1 (serie) , Tipo 2 (paralelo de 2 bits) , Tipo 3 (paralelo de 4 bits) , o Tipo 4 (paralelo de 8 bits) , es reflejado de vuelta al aparato central como un parámetro en este paquete. El formato de una modalidad para un Paquete de Confirmación de Tipo de Inferíase 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 Cliente c, Tipo de Inferíase, Reservado 1 y CRC. Este tipo de paquete es generalmente identificado como un pagúete Tipo 76, y usa una longitud fija seleccionada previamente de 4 bytes. 20. Paquetes de cesión de tipo de ejecución El Paquete de Cesión de Tipo de Ejecución es un medio, estructura o método para que el aparato central ordene al cliente que se transfiera al modo especificado en este paquete. Este tiene que ser el mismo modo que fue solicitado anteriormente y confirmado por el Paquete de Solicitud de Cesión de Tipo de Inferíase y el Paquete de Confirmación de Tipo de Inferíase. El aparato central y el cliente deben cambiar al modo acordado después de que este paquete es enviado. El cliente debe perder y volver a ganar la sincronización de enlace durante el cambio de modo. El formato de una modalidad para un Paquete de Cesión de Tipo de 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, Tipo de Interfase, Reserva 1 y CRC. Este tipo de paquete es generalmente identificado como un paquete Tipo 77 en el campo de tipo de 1 byte y usa una longitud fija seleccionada previamente de 4 bytes . 21. Paquetes de habilitación de canal de audio hacia adelante Este paquete provee una estructura, método o medio que permite a un aparato central habilitar o inhabilitar canales de audio en un cliente. Esta capacidad es útil de manera que un cliente (una pantalla, por ejemplo,) pueda apagar amplificadores de audio o elementos de circuitos similares para ahorrar potencia cuando el aparato central no tiene audio para hacer salir. Esto es significativamente más difícil de implementar en forma implícita simplemente usando la presencia o ausencia de flujos de audio como un indicador. El estado predeterminado cuando el sistema de cliente es encendido es que todos los canales de audio son habilitados . El formato de una modalidad de un Paquete de Habilitación de Canal de Audio Hacia Adelante 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 Cliente h, Máscara de Habilitación de Canal de Audio y CRC. Este tipo de paquete es generalmente identificado como un paquete Tipo 78 en el campo de tipo de 1 byte y usa una longitud fija seleccionada previamente de 4 bytes . 22. Paquetes de índice de muestra de audio inverso Este paquete permite que el aparato central habilite o inhabilite el canal de audio de enlace inverso y que fije el índice de muestra de datos de audio de este flujo. El aparato central selecciona un índice de muestra que es definido como válido en el Paquete de Capacidad del Cliente. Si el aparato central selecciona un índice de muestra inválido entonces el cliente no enviará un flujo de audio al aparato central, y una señal de error o valor de error apropiada puede ser enviada al aparato central en el Paquete de Informe de Errores de Cliente. El aparato central puede inhabilitar el flujo de audio de enlace inverso fijando el índice de muestra a un valor de 255. El estado predeterminado asumido cuando el sistema de cliente es inicialmente encendido o conectado es con el flujo de audio de enlace inverso inhabilitado. El formato de una modalidad para un Paquete de índice de Muestra de Audio Inverso se muestra en la figura 31. 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 Cliente h, índice de Muestra de Audio, Reservado 1 y CRC. Este tipo de paquete es generalmente identificado como paquete Tipo 79, y usa una longitud fija seleccionada previamente de 4 bytes . 23. Paquetes de sobrecarga de protección de contenido digital Este paquete provee una estructura, método o medio que permite que un aparato central y un cliente intercambien mensajes relacionados con el método de protección de contenido digital que se está usando. Actualmente se contemplan dos tipos de protección de contenido, Protección de Contenido de Transmisión Digital (DTCP) , o Sistema de Protección de Contenido Digital de Ancho de Banda Alto (HDCP) , con espacio reservado para futuras designaciones de esquema de protección alternativo. El método que se está usando es especificado por un parámetro de Tipo de Protección de Contenido en este paquete. El formato de una modalidad de un Paquete de Sobrecarga de Protección de Contenido Digital se muestra en la figura 32. Como se muestra en la figura 32, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente b, Tipo de Protección de Contenido, Mensajes de Sobrecarga de Protección de Contenido y CRC. Este tipo de paquete es generalmente identificado como un paquete Tipo 80. 24. Paquetes de habilitación de color transparente El Paquete de Habilitación de Color Transparente es una estructura, método o medio que se usa para especificar qué color es transparente en una pantalla y para habilitar o inhabilitar el uso de un color transparente para desplegar imágenes . Las pantallas que tienen esta capacidad informarán esa capacidad en el bit 4 del campo de Capacidad de Características de Cliente del Paquete de Capacidad del Cliente . Cuando un pixel con el valor para color transparente es escrito al mapa de bits, el color no cambia del valor anterior. El formato de un Paquete de Habilitación de Color Transparente se muestra en la figura 33. Como se muestra en la figura 33, en una modalidad este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente h, Habilitación de Color Transparente, Reservado 1, Identificador de Alfa-Cursor, Descriptor de Formato de Datos, Valor de Pixel Transparente y CRC. Este tipo de paquete es generalmente identificado como un paquete tipo 81 en el campo de tipo de 1 byte y usa una longitud fija seleccionada previamente de 10 bytes. 25. Paquetes de medición de retardo de ida y vuelta El Paquete de Medición de Retardo de Ida y Vuelta provee una estructura, método o medio que se usa para medir el retardo de propagación del aparato central a un cliente (pantalla) más el retardo de un cliente (pantalla) de vuelta al aparato central. Esta medición incluye de manera inherente los retardos que existen en los excitadores y receptores de línea, y un subsistema de interconexión. Esta medición se usa para fijar los parámetros de retardo de inversión de sentido y divisor de índice de enlace inverso en el Paquete de Encapsulación de Enlace Inverso, descrito en general antes . Este paquete es más útil cuando el enlace de MDDI está operando a la velocidad máxima destinada para una aplicación particular. El paquete puede ser enviado en modo Tipo 1 y a un índice de datos más bajo a fin de incrementar el rango de la medición de retardo de ida y vuelta. La señal MDDI_Stb se comporta como si todos los datos cero estuvieran siendo enviados durante los siguientes campos: ambos Tiempos de Guarda, Todo Cero y Período de Medición. Esto hace que MDDI_Stb conmute a la mitad del índice de datos de manera que se pueda usar como un reloj periódico en el cliente durante el Período de Medición. En una modalidad, un cliente generalmente indica una capacidad de soportar el Paquete de Medición de Retardo de Ida y Vuelta a través del uso del bit 18 del campo de Indicadores de Capacidad de Características de Cliente del Paquete de Capacidad del Cliente . Se recomienda que todos los clientes soporten medición de retardo de ida y vuelta, pero es posible que el aparato central conozca el peor caso de retardo de ida y vuelta con base en un retardo de cable máximo, y en retardos de excitador y receptor máximos. Igualmente, el aparato central puede conocer el retardo de ida y vuelta por anticipado para un enlace de MDDI usado en modo interno, ya que este es un aspecto de elementos de diseño conocidos (longitudes de conductor, tipo de circuitería, y características, y así sucesivamente) del dispositivo en el cual se está usando la interfase. El formato de un Paquete de Medición de Retardo 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 Cliente h, CRC de Parámetro, Tiempo de Guarda 1, Período de Medición, Todo Cero y Tiempo de Guarda 2. Este tipo de paquete es generalmente identificado como un paquete Tipo 82 y usa una longitud fija seleccionada previamente de 159 bytes . La temporización de eventos que tienen lugar durante el un Paquete de Medición de Retardo de Ida y Vuelta se ilustra en la figura 35. En la figura 35, el aparato central transmite el Paquete de Medición de Retardo de Ida y Vuelta, mostrado por la presencia de los campos de CRC de Parámetro y Alineación de Señal de Validación seguidos de los campos Todo Cero y Tiempo de Guarda 1. Un retardo 3502 ocurre antes de que el paquete alcance el dispositivo de pantalla o circuitería de procesamiento de cliente. A medida que el cliente recibe el paquete, transmite los Oxff, Oxff y 30 bytes de patrón 0x0 en forma tan precisa como resulta práctico al inicio del Período de Medición como es determinado por el cliente. El tiempo real en que el cliente empieza a transmitir esta secuencia es retardado del principio del Período de Medición desde el punto de vista del aparato central. La cantidad de este retardo es sustancialmente el tiempo que le toma al paquete propagarse a través de los excitadores y receptores de línea y el sistema de interconexión (cables, conductores) . Una cantidad similar de retardo 3504 es incurrida para que el patrón se propague desde el cliente de regreso al aparato central . A fin de determinar en forma precisa el tiempo de retardo de ida y vuelta para señales que atraviesan a y desde el cliente, el aparato central cuenta el número de períodos de tiempo de bits de enlace hacia adelante que ocurren después del inicio del Periodo de Medición hasta que el inicio de los Oxff, Oxff y 30 bytes de secuencia 0x0 es detectado al llegar. Esta información se usa para determinar la cantidad de tiempo para que una señal de ida y vuelta pase del aparato central al cliente y de regreso nuevamente. Luego, aproximadamente la mitad de esta cantidad es atribuida a un retardo creado para el pasaje unidireccional de una señal al cliente . Tanto el aparato central como el cliente impulsan la línea a un nivel de cero lógico durante ambos tiempos de guarda para mantener las líneas MDDI_DATOS en un estado definido. Los tiempos de habilitación e inhabilitación del aparato central y cliente durante ambos tiempos de guarda son tales que las señales MDDI_Datos están a un nivel bajo válido para cualquier tiempo de retardo de ida y vuelta válido . 26. Paquete de calibración de sesgo de enlace hacia adelante El Paquete de Calibración de Sesgo de Enlace Hacia Adelante permite a un cliente o pantalla calibrarse a sí mismo en cuanto a diferencias en el retardo de propagación de las señales MDDI_Datos con respecto a la señal MDD_Stb. Sin compensación de sesgo de retardo, el índice de datos máximo es generalmente limitado para explicar el peor caso de variación potencial en estos retardos. Generalmente, este paquete es enviado únicamente cuando el índice de datos de enlace hacia adelante está configurado a un índice de aproximadamente 50 Mbps o más bajo. Después de enviar este paquete para calibrar la pantalla, el índice de datos se puede elevar por arriba de 50 Mbps. Si el índice de datos se ajusta demasiado alto durante el proceso de calibración de sesgo, la pantalla pudiera sincronizarse con un alias del periodo de bits que podría causar que el ajuste de compensación de sesgo de retardo esté desactivado por más de un tiempo de bit, dando por resultado una sincronización por reloj de datos errónea. El tipo de índice de datos más alto de interfase o Tipo de Inferíase más grande posible se selecciona antes de enviar el Paquete de Calibración de Sesgo de Enlace Hacia Adelante de manera que todos los bits de datos existentes sean calibrados. Una modalidad del formato de un Paquete de Calibración de Sesgo de Enlace Hacia Adelante 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 Cliente h, CRC de Parámetro, Todo Cero, Secuencia de Datos de Calibración y CRC. Este tipo de paquete es generalmente identificado como un paquete Tipo 83 en el campo de tipo, y en una modalidad tiene una longitud seleccionada previamente de 515.

Panel de control virtual El uso de un Panel de Control Virtual (VCP) permite que un aparato central fije ciertos controles de usuario en un cliente. Al permitir que estos parámetros sean ajustados por el aparato central, la interfase de usuario en el cliente se puede simplificar porque pantallas que permiten a un usuario ajustar parámetros tales como volumen de audio o brillo de la pantalla pueden ser generadas por software de aparato central en lugar de por uno o más microprocesadores en el cliente. El aparato central tiene la capacidad de leer los ajustes de parámetro en el cliente y determinar el rango de valores válidos para cada control. El cliente generalmente tiene la capacidad de informar de vuelta al aparato central qué parámetros de control se pueden ajustar. Los códigos de control (Códigos VCP) y valores de datos asociados generalmente especificados, se utilizan para especificar controles y ajustes en el cliente. Los Códigos VCP en la especificación MDDI se expanden a 16 bits para conservar la alineación de campo de datos apropiada en las definiciones de paquete, y en el futuro para soportar valores complementarios que son únicos a esta interfase o mejoras f turas. 27. Paquete de característica VCP de solicitud El Paquete de Característica VCP de Solicitud provee un medio, mecanismo o método para que el aparato central 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 de soportar el Paquete de Característica VCP de Solicitud usando el bit 13 del campo de Indicadores de Capacidad de Características de Cliente del Paquete de Capacidad del Cliente. El formato de un 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 Cliente h, código MCCS VCP y CRC. Este tipo de paquete es generalmente identificado en una modalidad como un Tipo 128, el cual está indicado en el campo de tipo de 2 bytes . La longitud de paquete, la cual especifica el número total de bytes en el paquete sin incluir el campo de longitud de paquete, típicamente se fija para este tipo de paquete a una longitud de 8 bytes . El campo ID de Cliente h está reservado para usar como una ID de Cliente en implementaciones futuras y típicamente se ajusta a cero. El campo de Código MCCS VCP comprende 2 bytes de información que especifica el Parámetro de Código de Control MCCS VCP. Un valor en el rango de 0 a 255 hace que un Paquete de Respuesta de Característica VCP sea regresado con un solo elemento en la Lista de Respuesta de Característica VCP correspondiente al código MCCS especificado. Un Código MCCS 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 a 65534, para este campo están reservados para uso futuro y en la actualidad no están en uso. 28. Paquete de respuesta de característica VCP El Paquete de Respuesta de Característica VCP provee un medio, mecanismo o método para que un cliente responda a una solicitud de aparato central con el ajuste actual de un parámetro de control específico o todos los parámetros de control válidos. 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 él 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 la serie de controles que están soportados por el cliente. Si se envía una Característica VCP de Solicitud que hace referencia a un control específico que no está implementado en el cliente, entonces un Paquete de Respuesta de Característica VCP es regresado con un solo elemento de Lista de Respuesta de Característica VCP correspondiente al control no implementado que contiene el código de error apropiado . En una modalidad, el cliente indica una capacidad de soportar el Paquete de Respuesta de Característica VCP usando el bit 13 del campo Capacidad de Características de Cliente del Paquete de Capacidad del Cliente . El formato del Paquete de Respuesta de Característica VCP en una modalidad se muestra en la figura 70. Como se ve en la figura 70, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente c, Versión MCCS, Número de Secuencia de Respuesta, Lista de Respuesta de Característica VCP y CRC. Este tipo de paquete es generalmente identificado en una modalidad como un Tipo 129, como se indica en el campo de tipo de 2 bytes. El campo de ID de Cliente c contiene información reservada para una ID de Cliente. Este campo está reservado para uso futuro y generalmente se ajusta a cero. El campo Versión MCCS contiene 2 bytes de información que especifica la Versión de la Especificación VESA MCCS implementada por el cliente. El campo de Número de Secuencia de Respuesta de 2 bytes contiene información o datos que especifican el número de secuencia de los Paquetes de Respuesta de Característica VCP regresados por el cliente. El cliente regresa 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 esparcir la lista de respuesta de característica en múltiples Paquetes de Respuesta de Característica VCP. En este caso, el cliente asigna un número de secuencia a cada paquete consecutivo, y el número de secuencia de los Paquetes de Respuesta de Característica VCP enviados en respuesta a un solo Paquete de Característica VCP de Solicitud, empieza en cero e incrementa en uno. El último Elemento de 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 VCP igual a Oxffff para identificar que el paquete es el último y contiene el número de secuencia más alto del grupo de paquetes regresados . Si solamente un Paquete de Respuesta de Característica VCP es enviado en respuesta a un Paquete de Característica VCP de Solicitud, entonces el Número de Secuencia de Respuesta en ese paquete único es cero y la Lista de Respuesta de Característica VCP contiene un registro que tiene un Código de Control MCCS VCP igual a Oxffff. El campo de Número de Características en la Lista contiene 2 bytes que especifican el número de Elementos de Lista de Característica VCP que se encuentran en la Lista de Respuesta de Característica VCP en este paquete, mientras que el campo de Lista de Respuesta de Característica VCP es un grupo de bytes que contienen uno o más Elementos de Lista de Respuesta de Característica VCP. El formato de un solo Elemento de Lista de Respuesta de Característica VCP en una modalidad se muestra en la figura 71. Como se muestra en la figura 71, cada Elemento de Lista de Respuesta de Característica VCP tiene una longitud de 12 bytes y comprende los campos de Código MCCS VCP, Código de Resultado, Valor Máximo y Valor Presente. El campo de Código MCCS VCP de 2 bytes contiene datos o información que especifican el Parámetro de Código de Control MCCS VCP asociado con este elemento de lista. Solamente los valores de Código de Control definidos en la versión 2 y en la versión posterior de la Especificación VESA MCCS se consideran 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 referente al Control de MCCS VCP especificado. Un valor de 0' en este campo significa que no hay error, mientras que un valor de'l' significa que el control especificado no está implementado en el cliente. Otros valores para este campo de 2 a 65535 están actualmente reservados para uso e implementación futuros de otra aplicación contemplada por la técnica, pero no se deben usar por ahora . El campo de Valor Máximo de 4 bytes contiene un entero sin signo de 32 bits que especifica el valor más grande posible al cual se puede ajustar el Control de MCCS especificado. Si el control requerido no está implementado en el cliente este valor se ajusta a cero. Si el valor regresado tiene una longitud menor a 32 bits (4 bytes) , entonces el valor es convertido a un entero de 32 bits dejando los bytes más significativos (sin usar) ajustados a cero. El campo de Valor Presente de 4 bytes contiene información que especifica el valor presente del control Continuo (C) o no continuo (NC) de MCCS VCP. Si el control solicitado no está implementado en el cliente o si el control está implementado pero es un tipo de datos de tabla (T) , entonces este valor se ajusta a cero. Si el valor regresado tiene una longitud menor a 32 bits (4 bytes) por especificación VESA MCCS, entonces el valor es convertido a un entero de 32 bits dejando los bytes más significativos (sin usar) ajustados a cero. 29. Paquete de característica VCP de ajuste El Paquete de Característica VCP de Ajuste provee un medio, mecanismo o método para que un aparato central ajuste valores de control VCP tanto para controles continuos como para controles no continuos en un cliente. En una modalidad, el cliente indica la capacidad de soportar el Paquete de Característica VCP de Ajuste usando el bit 13 del campo Capacidad de Características de Cliente del Paquete de Capacidad del Cliente . El formato del Paquete de Característica VCP de Ajuste en una modalidad se muestra en la figura 72. Como se ve en la figura 72, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente h, Código MCCS VCP, Número de Valores en la Lista, Lista de Valores de Control y CRC. Este tipo de paquete es generalmente identificado como un Tipo 130, como se indica en el campo de tipo de 2 bytes, tiene una longitud de 20 bytes exclusiva del campo de Longitud de Paquete. El campo de ID de Cliente h usa de nuevo un valor de 2 bytes para especificar o actuar como una ID de Cliente. Este campo está reservado para uso futuro y está actualmente ajustado a cero. El campo de Código MCCS VCP usa 2 bytes de información o valores para especificar el Parámetro de Código de Control MCCS VCP que se va a ajustar. El Campo de Número de Valores en la Lista contiene información o valores que especifican el número de valores de 16 bits que existen en la Lista de Valores de Control. La Lista de Valores de Control 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 tablas, la Lista de Valores de Control contendrá un valor que especifica el nuevo valor que se va a escribir al parámetro de control especificado por el campo de Código MCCS VCP. Para controles relacionados con tablas el formato de los datos en la Lista de Valores de Control es especificado por la descripción de parámetro del Código MCCS VCP especificado. Si la lista contiene valores mayores a un byte, entonces el byte menos significativo es transmitido primero, consistente con el método que se define en otra parte. Por último, el campo de CRC de 2 bytes contiene un CRC de 16 bits de todos los bytes en el paquete incluyendo la Longitud de Paquete . 30. Paquete de parámetro válido de solicitud El Paquete de Parámetro Válido de Solicitud se usa como un medio una estructura útil para solicitar que un cliente regrese un Paquete de Respuesta de Parámetro Válido que contiene una lista de parámetros soportados por el control no continuo (NC) o de tabla (T) especificado. Este paquete debe especificar solamente controles no continuos o controles que se relacionen con una tabla en el cliente, y no especificar un valor de Código MCCS VCP de 65535 (Oxffff) para especificar todos los controles . Si un Código MCCS VCP no soportado o inválido es especificado, entonces un valor de error apropiado es regresado en el Paquete de Respuesta de Parámetro Válido. En una modalidad, el cliente indica una capacidad de soportar el Paquete de Parámetro Válido de Solicitud usando el bit 13 del campo de Capacidad de Características de Cliente del Paquete de Capacidad de Pantalla. El formato del Paquete de Parámetro Válido de Solicitud en una modalidad se muestra en la figura 73. Como se ve en la figura 73, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente h, Código MCCS VCP y CRC. Este tipo de paquete es generalmente identificado en una modalidad como un Tipo 131, como se indica en el campo de tipo de 2 bytes . La longitud de paquete, como se indica en el Campo de Longitud de Paquete de 2 bytes se ajusta generalmente para tener un número total de bytes en el paquete, sin incluir el campo de longitud de paquete de 8. El ID de Cliente h de nuevo especifica la ID de Cliente, pero está reservado actualmente para uso futuro, como sería evidente para el experto en la técnica, y se ajusta a cero. El Campo de Código MCCS VCP de 2 bytes contiene un valor que especifica el Parámetro de Código de Control MCCS VCP no continuo que se va a interrogar. El valor en este campo debe corresponder a un control no continuo que está implementado en el cliente. Los valores 256 al 65535 (Oxffff) están típicamente reservados o se consideran inválidos, y se consideran como un control no implementado en la respuesta de error. 31. Paquete de respuesta de parámetro válido Un Paquete de Respuesta de Parámetro Válido es enviado en respuesta a un Paquete de Parámetro Válido de Solicitud. Se usa como un medio, método o estructura para identificar los ajustes válidos para un control MCCS VCP no continuo o un control que regresa el contenido de una tabla. Si el control se relaciona con una tabla en el cliente, entonces la Lista de Respuesta de Parámetro VCP simplemente contiene la lista específica de valores de tabla consecutivos que fueron solicitados. Si el contenido de la tabla no puede caber en un solo Paquete de Respuesta de Parámetro Válido, entonces múltiples paquetes con Números de Secuencia de Respuesta consecutivos pueden ser enviados por el cliente. En una modalidad, un cliente indica una capacidad de soportar un Paquete de Respuesta de Parámetro Válido usando el bit 13 del campo de Capacidad de Características de Cliente del Paquete de Capacidad del Cliente. Un aparato central puede solicitar el contenido de una tabla en la siguiente manera: el aparato central envía un Paquete de Característica VCP de Ajuste que contiene los parámetros necesarios o deseados tales como parámetro de lectura/escritura, desplazamiento LUT y selección RVA; después un Paquete de Parámetro Válido de Solicitud que especifica el control deseado es enviado por el aparato central; luego el cliente regresa uno o más Paquetes de Respuesta de Parámetro Válido que contienen los datos de tabla. Esta secuencia de operaciones realiza una función similar a las funciones de lectura de tabla que se describen en el modelo de operación MCCS . Si un parámetro de cliente específico no está soportado por el cliente entonces en una modalidad el campo correspondiente de este paquete contendrá un valor de 255. Para parámetros que son usados 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 se ve en la figura 74, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente c, Código MCCS VCP, Código de Respuesta, Número de Secuencia de Respuesta, Valores de Número en la Lista, Lista de Respuesta de Parámetro VCP y CRC. Este tipo de paquete es generalmente identificado para una modalidad como un Tipo 132, como se indica en el campo de tipo de 2 bytes . El campo de ID de Cliente c está reservado para la ID de Cliente futura, como se sabe a partir de las discusiones anteriores, mientras que el Paquete de Código MCCS VCP de 3 bytes contiene un valor que especifica un Parámetro de Código de Control MCCS VCP no continuo que es descrito por este paquete. Si un Código de Control MCCS VCP inválido es especificado por un Paquete de Parámetro Válido de Solicitud, entonces el mismo valor de parámetro inválido será especificado en este campo con el valor apropiado en el campo de Código de Respuesta. Si el Código de Control MCCS es inválido entonces la Lista de Respuesta de Parámetro VCP tendrá una longitud de cero . El campo de Código de Respuesta contiene 2 bytes de información o valores que especifican la naturaleza de la respuesta relacionada con la solicitud de información referente al Control MCCS VCP especificado. Si el valor en este campo es igual a 0, entonces se considera que no hay error alguno presente para este tipo de datos, y el último Paquete de Respuesta de Parámetro Válido en la secuencia es enviado, teniendo el Número de Secuencia de Respuesta más alto. Si el valor en este campo es igual a 1, entonces no se considera error alguno presente, pero se enviarán otros Paquetes de Respuesta de Parámetro Válido que tienen números de secuencia más altos . Si el valor en este campo es igual a 2, entonces el control especificado no se considera implementado en el cliente. Si el valor en este campo es igual a 3, entonces el control especificado no es un control no continuo (es un control continuo que siempre tiene una serie válida de todos los valores de cero a su valor máximo) . Los valores para este campo iguales a 4 a 65535 están reservados para uso futuro y generalmente no se deben usar. El campo de Número de Secuencia de Respuesta de 2 bytes especifica el número de secuencia de los Paquetes de Respuesta de Parámetro Válido regresados por el cliente. El cliente regresa uno o más Paquetes de Respuesta de Parámetro Válido en respuesta a un Paquete de Parámetro Válido de Solicitud. El cliente puede esparcir la Lista de Respuesta de Parámetro VCP en múltiples Paquetes de Respuesta de Parámetro Válido. En este último caso, el cliente asignará un número de secuencia a cada paquete consecutivo y ajustará el Código de Respuesta a 1 en todos los paquetes menos 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 campo de Número de Valores en la Lista de 2 bytes 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 parámetro de Número de Valores en la Lista es cero. El campo de Lista de Respuesta de Parámetro VCP contiene una lista de 0 a 32760 valores de 2 bytes que indican la serie de valores válidos para el control no continuo especificado por el campo de Código de - Control MCCS . Las definiciones de los códigos de control no continuo se especifican en la Especificación VESA MCCS. Por último, en esta modalidad, el campo de CRC contiene un CRC de 16 bits de todos los bytes en el paquete incluyendo la Longitud de Paquete .

Imágenes de alfa-cursor La interfase MDD y protocolo y mecanismos inventivos asociados para comunicar datos en un enlace de comunicaciones proveen soporte para múltiples planos de imagen que se superponen entre sí y pueden tener diversos grados de transparencia. Un cursor de hardware puede ser implementado usando una imagen superpuesta que tiene un "desplazamiento X-Y variable. Una visión general de la funcionalidad Alfa-Cursor y soporte de protocolo asociado se proveen más adelante. La capacidad de soportar paquetes de imagen de Alfa-Cursor es definida en el Pagúete de Capacidad de Imagen de Alfa-Cursor, el cual es enviado en respuesta a un Paquete de Estado Específico de Solicitud. 32. Paquete de capacidad de imagen de alfa-cursor El Paquete de Capacidad de Imagen de Alfa-Cursor se usa para definir las características de la imagen de alfa-cursor y mapas de transparencia asociados en un cliente . En una modalidad, un cliente indica una capacidad de soportar un Paquete de Capacidad de Imagen de Alfa-Cursor usando un valor de parámetro de 133 en la Lista de Respuesta de Parámetro Válido en el Pagúete de Lista de Respuesta de Estado Válido. La longitud de paquete especificada en el campo de longitud de paquete se ajusta a un valor fijo de 20 para una modalidad, sin incluir el campo de longitud de paquete . El formato del Paquete de Capacidad de Imagen de Alfa-Cursor para una modalidad se muestra en la figura 75. Como se ve en la figura 75, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente c, Identificador de Alfa-Cursor, Ancho de Mapa de Bits de Alfa-Cursor, Altura de Mapa de Bits de Alfa-Cursor, Capacidad RVA, Capacidad Monocroma, Reservado 1, Capacidad Y Cr Cb, Res. de Mapa de Transparencia, Bits de Capacidad y CRC. El campo ID de Cliente c está típicamente reservado para uso de ID de Cliente futura y actualmente está ajustado a cero. El campo de Identificador de Alfa-Cursor (2 bytes) contiene un valor que identifica un plano de alfa-cursor específico. Si el cliente soporta n planos de imagen de alfa-cursor, entonces el Identificador de Alfa-Cursor tiene un rango válido de 0 a n-1. En una modalidad, el valor n es especificado por el campo de Planos de Imagen de Alfa-Cursor del Paquete de Capacidad del Cliente. El cliente regresa un Paquete de Capacidad de Imagen de Alfa-Cursor único para cada plano de imagen de alfa-cursor. El valor del campo de Ancho de Mapa de Bits de Alfa-Cursor de 2 bytes especifica el ancho de la imagen de mapa de bits de alfa-cursor expresada como un número de pixeles, mientras que el valor del campo de Altura de Mapa de Bits de Alfa-Cursor de 2 bytes especifica la altura de la imagen de mapa de bits de alfa-cursor expresada como un número de pixeles . El campo de Capacidad RVA usa 2 bytes para especificar el número de bits de resolución que pueden ser desplegados en formato RVA. Si el cliente no puede usar el formato RVA, entonces este valor es cero. La palabra Capacidad RVA se compone de tres valores separados, los cuales en una modalidad son implementados de modo que: los bits 3 al 0 definan el número máximo de bits de azul (la intensidad de azul) en cada pixel; los bits 7 al 4 definan el número máximo de bits de verde (la intensidad de verde) en cada pixel; los bits 11 al 8 definan el número máximo de bits de rojo (la intensidad de rojo) en cada pixel; y los bits 15 al 12 estén reservados para uso futuro al presentar información de capacidad RVA de modo que en general están ajustados a cero por ahora. El campo de Capacidad Monocroma de 1 byte se usa para especificar el número de bits de resolución que pueden ser desplegados en un formato monocromo. Si un cliente no puede usar el formato monocromo entonces este valor se ajusta a cero. Los bits 7 al 4 están reservados para uso futuro y, por lo tanto, generalmente están ajustados a cero. Los bits 3 al 0 definen el número máximo de bits de escala de grises que pueden existir en cada pixel. Estos cuatro bits hacen posible especificar que cada pixel consiste de 1 a 15 bits. Si el valor es cero entonces el formato monocromo no está soportado por el cliente. El campo de Reservado 1 de 1 byte contiene un valor generalmente reservado para uso futuro, y, como tal, todos los bits en este campo están ajustados a cero. Esto hará que los campos de 2 bytes subsiguientes se alineen a una dirección de palabra de 16 bits y hará que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits .

El campo de Capacidad Y Cb Cr de 2 bytes contiene valores o información que especifica el número de bits de resolución que pueden ser desplegados en formato Y Cb Cr. Si el cliente no puede usar el formato Y Cr Cb, entonces este valor es cero. Generalmente, en una modalidad, la palabra Capacidad Y Cb Cr se compone de tres valores separados donde: los bits 3 al 0 definen un número máximo de bits que especifican la muestra Cr; los bits 7 al 4 definen el número máximo de bits que especifican la muestra Cb; los bits 11 al 8 definen el número máximo de bits que especifican la muestra Y; y los bits 15 al 12 están reservados para uso futuro al presentar información o valores de Capacidad Y Cb Cr, pero actualmente están ajustados a cero. El campo de Resolución de Mapa de Transparencia de 1 byte contiene valores o información que especifica el número de bits (profundidad) en cada ubicación de pixel del mapa de transparencia de imagen de alfa-cursor. Este valor puede variar de 1 a 8. Si el valor es cero entonces el mapa de transparencia no está soportado para esta memoria intermedia de imagen de alfa-cursor (la memoria intermedia especificada por el Campo de Identificador de Alfa-Cursor) . El campo de Bits de Capacidad de 1 byte provee valores o información que contiene una serie de banderas que especifican capacidades asociadas con la memoria intermedia de imagen de alfa-cursor. En una modalidad, las banderas están definidas de manera que: el bit 0 actúe para seleccionar datos de Pixel en el Paquete de Flujo de Video de Alfa-Cursor para que estén en un formato empaquetado. El bit 1 actúa para mostrar que los datos de mapa de transparencia en el Paquete de Transparencia de Alfa-Cursor están en un formato de paquete. Un ejemplo de datos de mapa de transparencia alineados por bytes y empaquetados se muestra en la figura 76. El bit 2 actúa para mostrar que el plano de imagen de alfa-cursor soporta capacidad de desplazamiento de imagen usando el Paquete de Desplazamiento de Imagen de Alfa-Cursor. El bit 3 actúa para mostrar que el plano de imagen de alfa-cursor puede soportar un formato de datos de mapa de colores . La misma tabla de mapa de colores se usa para los planos de imagen de alfa-cursor como se usa para la memoria intermedia de imagen principal y flujos de vídeo instalado. El mapa de colores es configurado usando el Paquete de Mapa de Colores que se describe en otra parte. Los bits 7 al 4 están reservados para uso futuro y por lo tanto, en general, están ajustados a un valor de cero o nivel lógico. 33. Paquete de mapa de transparencia de alfa-cursor El Paquete de Mapa de Transparencia de Alfa-Cursor define el contenido del mapa de transparencia de imagen para el plano de imagen de alfa-cursor especificado. Algunas aplicaciones pueden requerir un mapa de transparencia que sea mayor a la cantidad de datos que pueden ser transmitidos en un solo paquete. En estos casos, se pueden enviar múltiples Paquetes de Mapa de Transparencia de Alfa-Cursor, cada uno con una diferente subserie del mapa de transparencia usando los campos de Inicio X y Y de Mapa de Transparencia que se describen más adelante. Estos campos operan en una manera similar que los campos de Inicio "X e Inicio Y del Paquete de Flujo de Video. Un cliente indica una capacidad de soportar el Paquete de Mapa de Transparencia de Alfa-Cursor en una modalidad usando el campo de Resolución de Mapa de Transparencia del Paquete de Capacidad de Imagen de Alfa-Cursor para cada Plano de Alfa-Cursor específico especificado por el campo de Identificador de Alfa-Cursor del Paquete de Capacidad de Imagen de Alfa-Cursor. Los campos de longitud de paquete e ID de Cliente operan como antes para otros paquetes antes discutidos. En una modalidad, un valor de 134 en el campo de Tipo de Paquete es usado para identificar un paquete como un Paquete de Mapa de Transparencia de Alfa-Cursor. El formato del Paquete de Mapa de Transparencia de Alfa-Cursor para una modalidad se muestra en la figura 76. Como se ve en la figura 76, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente h, Identificador de Alfa-Cursor, Inicio X de Mapa de Transparencia, Inicio Y de Mapa de Transparencia, Resolución de Mapa de Transparencia, Reservado 1, CRC de Parámetro, Medios de Mapa de Transparencia y CRC de Datos de Mapa de Transparencia. El campo de Identificador de Alfa-Cursor de 2 bytes tiene un valor que identifica un plano de alfa-cursor específico. Si el cliente soporta n planos de imagen de alfa-cursor entonces el Identificador de Alfa-Cursor tiene un rango válido de 0 a n-1. Los campos de Inicio X y Y de Mapa de Transparencia de 2 bytes especifican cada uno las coordenadas X y Y absolutas, donde el punto (Inicio X de Mapa de Transparencia, Inicio Y de Mapa de Transparencia) es el primer pixel en el campo de Datos de Mapa de Transparencia que aparece más adelante. El campo de Resolución de Mapa de transparencia (1 byte) contiene un valor que especifica la resolución del mapa de transparencia y si los datos están o no empaquetados. En una modalidad de este campo, los bits 3 al 0 definen el número de bits de resolución que existen en todos los elementos de tabla de mapa de transparencia. Los valores válidos especifican que el ancho es de 1 a 8 bits. Los valores 0 y 9 al 15 se consideran inválidos. Este valor debe coincidir con el valor regresado por un cliente en el campo de Resolución de Mapa de Transparencia en el Paquete de Capacidad de Imagen de Alfa-Cursor. Los bits 6 al 4 están reservados para uso futuro y, por lo tanto, en general están ajustados a cero lógico en este momento. El bit 7 de este byte especifica si los Datos de Mapa de Transparencia se encuentran o no en forma empaquetado a o alineada por bytes . Si el bit 7 es igual a l' , entonces los Datos de Mapa de Transparencia están en forma empaquetada, y si es ?0', los datos están alineados por bytes. Un ejemplo de datos de Mapa de Transparencia empaquetados y alineados por bytes se muestra en otra parte. El valor de este bit debe coincidir con el valor del bit 1 del campo de Bits de Capacidad del Paquete de Capacidad de Imagen de Alfa-Cursor. El campo de Reservado 1 de 1 byte esta reservado para uso futuro, por lo tanto, todos los bits en este campo generalmente están ajustados igual a un nivel de cero lógico. Un propósito de este campo es hacer que todos los campos de 2 bytes subsiguientes se alineen a una dirección de palabra de 16 bits y hacer que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits. El campo de CRC de. Parámetro contiene un CRC de 16 bits de todos los bytes del campo de Longitud de Paquete al campo de Reservado 1. Si este CRC no verifica, entonces el paquete completo debe ser desechado. Para el campo de Datos de Mapa de Transparencia, cada ubicación de mapa de transparencia tiene un ancho de 1 a 8 bits . Si un solo mapa de transparencia no puede caber en un Paquete de Mapa de Transparencia Alfa y de Cursor, entonces todo el mapa de transparencia puede ser especificado enviando múltiples paquetes con diferentes valores de Datos de Mapa de Transparencia e Inicio X y Y de Mapa de Transparencia en cada paquete .

El campo de CRC de Datos de Mapa de Transparencia de 2 bytes contiene un CRC de 16 bits de solamente los Datos de Mapa de Transparencia. Si este CRC no verifica, entonces los Datos de Mapa de Transparencia se pueden seguir usando pero el conteo de errores CRC es incrementado. 34. Paquete de desplazamiento de imagen de alfa-cursor El Paquete de Desplazamiento de Imagen de Alfa-Cursor especifica el desplazamiento X y Y del cursor de la esquina superior izquierda de la imagen de pantalla principal. El formato del Paquete de Desplazamiento de Imagen de Alfa-Cursor se ilustra en la figura 77. Como se muestra en la figura 77, en una modalidad, el Paquete de Desplazamiento de Imagen de Alfa-Cursor está estructurado con campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente h, Desplazamiento X de Alfa-Cursor, Desplazamiento Y de Alfa-Cursor y CRC. En una modalidad, un cliente indica la .capacidad de soportar el Paquete de Desplazamiento de Imagen de Alfa-Cursor usando el bit 2 del campo de Bits de Capacidad del Paquete de Capacidad de Imagen de Alfa-Cursor para cada Plano de Alfa-Cursor específico especificado por el campo de Identificador de Alfa-Cursor del Paquete de Capacidad de Imagen de Alfa-Cursor. En una modalidad, la longitud de paquete está 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 de Alfa-Cursor. Los campos de Desplazamiento X y Y de Alfa-Cursor de 2 bytes contienen valores que especifican el desplazamiento horizontal y vertical, respectivamente, de la columna de la extrema izquierda e hilera superior, respectivamente, de pixeles de la imagen de cursor del lado izquierdo y parte superior de la imagen principal. El ID de Cliente h - 2 bytes que contienen un entero sin signo de 16 bits reservado para la ID de Cliente. Este campo está reservado para uso futuro y generalmente se ajusta a niveles o valores de cero lógico para los bits. 35. Paquete de flujo de video de alfa-cursor El Paquete de Flujo de Video de Alfa-Cursor lleva datos de video para actualizar una región rectangular de un plano de imagen de alfa-cursor. El tamaño de esta región puede ser tan pequeño como un solo pixel o tan grande como la pantalla completa . El formato del Paquete de Flujo de Video de Alfa-Cursor se ilustra en la figura 78. Como se muestra en la figura 78, en una modalidad el Paquete de Flujo de Video de Alfa-Cursor está estructurado con campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente b, 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 Pixeles, Datos de Pixel de CRC de Parámetro y CRC de Datos de Pixel. En una modalidad, un cliente indica una capacidad de soportar el Paquete de Flujo de Video de Alfa-Cursor y sus parámetros asociados usando el Paquete de Capacidad de Imagen de Alfa-Cursor para cada Plano de Alfa-cursor específico especificado por el campo de Identificador de Alfa-Cursor del Paquete de Capacidad de Imagen de Alfa-Cursor, y un valor de 17 en el campo de tipo de paquete indica o identifica un paquete como un Paquete de Flujo de Video de Alfa-Cursor. El campo de ID de Cliente h (2 bytes) está reservado para uso futuro como una ID de Cliente, y generalmente está ajustado a cero entre tanto, como se entendería en la técnica. El campo de Descriptor de Formato de Datos de Video de 2 bytes contiene información o un valor que especifica el formato de cada pixel en los Datos de Pixel en el presente flujo en el presente paquete. El formato de datos de pixel debe cumplir por lo menos con uno de los formatos válidos para el plano de imagen de alfa-cursor como se define en el Paquete de Capacidad de Imagen de Alfa-Cursor. El campo de Descriptor de Formato de Datos de Video contiene un valor que define el formato de pixel para el paquete actual solamente y no implica que un formato constante continuará siendo usado durante el tiempo de vida de un flujo de video particular. La figura 11 anterior ilustra cómo se codifica el Descriptor de Formato de Datos de Video. El formato es como sigue: En una modalidad, cuando los bits [15:13] son y000' , entonces los datos de video consisten de una serie de pixeles monocromo donde el número de bits por pixel es definido por los bits 3 al 0 de la palabra Descriptor de Formato de Datos de Video. Los bits 11 al 4 son después ajustados a cero. Cuando los bits [15:13] son ?001', entonces los datos de video consisten de una serie de pixeles de color que especifican cada uno un color a través de un mapa de colores (paleta) . Los bits 5 al 0 de la palabra Descriptor de Formato de Datos de Video definen el número de bits por pixel, y los bits 11 al 6 se ajustan a cero. Cuando los bits [15:13] son ?010', entonces los datos de video consisten de una serie de pixeles de color en formato RVA en bruto donde el número de bits por pixel de rojo es definido por los bits 11 al 8, el número de bits por pixel de verde es definido por los bits 7 al 4, y el número de bits por pixel de azul es definido por los bits 3 al 0. El número total de bits en cada pixel es la suma del número de bits usados para rojo, verde y azul. Cuando los bits [15:13] son '011', entonces los datos de video consisten de una serie de datos de video en formato 4:2:2 Y Cb Cr con información de luminancia y crominancia. El número de bits por pixel de luminancia (Y) es definido por los bits 11 al 8, el número de bits del componente Cb es definido por los bits 7 al 4, y el número de bits del componente Cr es definido por los bits 3 al 0. Los componentes Cb y Cr son enviados a la mitad del índice como Y. Además, las muestras de video en la porción de Datos de Pixel de este paquete estarán organizadas como sigue: Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3,... donde Cbn y Crn están asociados con Yn y Yn+1, y Cbn+2 y Crn+2 están asociados con Yn+2 y Yn+3, y así sucesivamente. Yn, Yn+1, Yn+2 y Yn+3 son valores de luminancia de cuatro pixeles consecutivos en una sola hilera de izquierda a derecha. Si hay un número impar de pixeles en una hilera (Borde Derecho X - Borde Izquierdo X +1) en la ventana a la que hace referencia el Paquete de Flujo de Video, entonces el valor Cb correspondiente al último pixel en cada hilera estará seguido del valor Y del primer pixel de la siguiente hilera. Se recomienda gue las ventanas que usan formato Y Cb Cr tengan un ancho que sea un número par de pixeles . Los Datos de Pixel en un paquete contienen un número par de pixeles . Puede contener un número impar o par de pixeles en el caso donde el último pixel de los Datos de Pixel corresponde al último pixel de una hilera en la ventana especificada en la cabecera de Paquete de Flujo de Video, es decir, cuando la ubicación X del último pixel en los Datos de Pixel es igual al Borde Derecho X. Para los cinco formatos, el bit 12, (designado como "P", en las figuras) especifica si las muestras de Datos de Pixel están o no empaquetadas . Cuando el valor del bit 12 es '0' entonces cada pixel y cada color dentro de cada pixel en el campo de Datos de Pixel está alineado por bytes con un límite de byte de interfase MDDI. Cuando el valor del bit 12 es '1', entonces cada pixel y cada color dentro de cada pixel en los Datos de Pixel está empaquetado contra el pixel anterior o color dentro de un pixel sin dejar bits sin usar. En una modalidad, el campo de Atributos de Datos de Pixel (2 bytes) tiene una serie de valores de bits que son interpretados como sigue. Los bits 1 y 0 seleccionan cómo son encaminados los datos de pixel de visualización. Para valores de bit de ?ll' los datos son desplegados a o para ambos ojos, para valores de bit ?10', los datos son encaminados solamente al ojo izquierdo, y para valores de bit ?01', los datos son encaminados solamente al ojo derecho. El bit 2 del campo de Atributos de Datos de Pixel indica si los Datos de Pixel son o no presentados en un formato entrelazado, donde un valor de ?0' significa que los datos de pixel están en el formato progresivo estándar, y que el número de hilera (coordenada Y de pixel) es incrementado en 1 al avanzar de una hilera a la siguiente. Cuando este bit tiene un valor de ?l', los datos de pixel están en formato entrelazado, y el número de hilera es incrementado en 2 al avanzar de una hilera a la siguiente. El bit 3 indica que los Datos de Pixel están en formato de pixel alterno. Esto es similar al modo entrelazado estándar habilitado por el bit 2, pero el entrelazado es vertical en lugar de horizontal. Cuando el bit 3 es 0', los Datos de Pixel están en el formato progresivo estándar, y el número de columna (coordenada X de pixel) es incrementado en 1 a medida que cada pixel consecutivo es recibido. Cuando el bit 3 es l', los Datos de Pixel están en formato de pixel alterno, y el número de columna es incrementado en 2 a medida que cada pixel es recibido. El bit 4 del campo de Atributos de Datos de Pixel indica si los datos de Pixel están o no relacionados con una pantalla o una cámara, como donde los datos son transferidos a o desde un dispositivo interno para un teléfono inalámbrico o dispositivo similar o incluso una computadora portátil, u otros dispositivos como se discute anteriormente, o los datos están siendo transferidos a o desde una cámara integrada o directamente acoplada al dispositivo. Cuando el bit 4 es ?0', los datos de Pixel están siendo transferidos a o desde una memoria intermedia de cuadro de pantalla. Cuando el bit 4 es l' , los datos de Pixel están siendo transferidos a o desde una cámara o dispositivo de video de algún tipo, siendo dichos aparatos bien conocidos en la técnica. El bit 5 del campo de Atributos de Datos de Pixel está reservado para uso o aplicaciones futuras de la interfase MDD y, por lo tanto, generalmente está ajustado a valor de cero o x0' . Los bits 7 y 6 del campo de Atributos de Datos de Pixel son Bits de Actualización de Pantalla que especifican una memoria intermedia de cuadro donde los datos de pixel se van a escribir. Los efectos más específicos se discuten en otra parte. Para valores de bit de ?01', los datos de Pixel son escritos a la memoria intermedia de imagen fuera de línea. Para valores de bit de 00', los datos de Pixel son escritos a la memoria intermedia de imagen usado para renovar la pantalla. Para valores de bit de ?ll' , los datos de Pixel son escritos a todas las memorias intermedias de imagen. Los valores de bit o combinación de ?10' es tratada como un valor o designación inválido y los datos de Pixel son ignorados y no son escritos a ninguno de las memorias intermedias de imagen. Este valor puede tener uso para aplicaciones futuras de la interfase. Los bits 8 al 15 del campo de Atributos de Datos de Pixel están reservados para uso futuro y, por lo tanto, generalmente están ajustados como cero. En una modalidad, los campos de Inicio X e Inicio Y de 2 bytes especifican las coordenadas X y Y absolutas del punto (Inicio X, Inicio Y) para el primer pixel en el campo de Datos de Pixel. 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 imagen de alfa-cursor llenada por el campo de Datos de Pixel, mientras que los campos de Borde Derecho X y Borde Inferior Y especifican la coordenada X del borde derecho y la coordenada Y del borde inferior de la ventana de imagen de alfa-cursor que está siendo actualizada. El campo de Conteo de Pixeles (2 bytes) especifica el número de pixeles en el campo de Datos de Pixel que aparece más adelante . El campo de CRC de Parámetro de 2 bytes contiene un CRC de todos los bytes de la Longitud de Paquete al Conteo de Pixeles . Si este CRC no verifica, entonces el paquete entero es desechado. El campo de Datos de Pixel contiene la información de video en bruto que se va a desplegar y la cual está formateada en la manera descrita por el campo de Descriptor de Formato de Datos de Video. Los datos son transmitidos una "hilera" a la vez como se discute en otra parte. El campo de CRC de Datos de Pixel (2 bytes) contiene un CRC de 16 bits de solamente los Datos de Pixel. Si una verificación de CRC de este valor falla, entonces los Datos de Pixel se pueden usar aún, pero el conteo de errores de CRC es incrementado.

Imágenes de flujo de video escalado El mecanismo, estructura, medio o método de Inferíase o protocolo MDD provee soporte para imágenes de flujo de video escalado que permiten que un aparato central envíe una imagen al cliente que está escalada más grande o más pequeña que la imagen original, y la imagen escalada es copiada a una memoria intermedia de imagen principal. Una visión general de la funcionalidad de Flujo de Video Escalado y soporte de protocolo asociado se proveen en otra parte. Una capacidad para soportar flujos de video escalados es definida por o dentro del Paquete de Capacidad de Flujo de Video Escalado, el cual es enviado en respuesta a un Paquete de Estado Específico de Solicitud. 36. Paquete de capacidad de flujo de video escalado El Paquete de Capacidad de Flujo de Video Escalado define las características de la imagen fuente de flujo de video escalado en o usada por un cliente. El formato del Paquete de Capacidad de Flujo de Video Escalado se muestra generalmente en la figura 79. Como se ve en la figura 79, en una modalidad, un Paquete de Capacidad de Flujo de Video Escalado está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente c, Número Max de Flujos, Tamaño X Max de Fuente, Tamaño Y Max de Fuente, Capacidad RVA, Capacidad Monocroma, Reservado 1, Capacidad Y Cr Cb, Reservado 2 y CRC. La longitud de paquete, en una modalidad, se selecciona para que sea de 20 bytes fija, como se muestra en el campo de longitud, incluyendo el campo de ID de Cliente c de 2 bytes, el cual está reservado para usar para una ID de Cliente, de otra manera se ajusta a cero, y el campo de CRC. En una modalidad, el cliente indica una capacidad de soportar el Paquete de Capacidad de Flujo de Video Escalado usando 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 Máximo de Flujos de 2 bytes contiene un valor para identificar el número máximo de flujos de video escalados simultáneos que se pueden asignar a la vez. En una modalidad, un cliente debe denegar una solicitud de asignar un flujo de video escalado si el número máximo de flujos de video escalados ya está asignado. Si se encuentran asignados menos del número máximo de flujos de video escalados, el cliente puede denegar también una solicitud de asignación con base en otras limitaciones de recursos en el cliente. Los campos de Tamaño X y Tamaño Y Máximo de Fuente (2 bytes) especifican valores para el ancho y altura máximos, respectivamente, de la imagen fuente de flujo de video escalado expresada como un número de pixeles. El campo de Capacidad RVA usa valores para especificar el número de bits de resolución que pueden ser desplegados en formato RVA. Si el flujo de video escalado no puede usar el formato RVA, entonces este valor se ajusta igual a cero. La palabra Capacidad RVA se compone de tres valores sin signo separados, donde: los bits 3 al 0 definen un número máximo de bits de azul (la intensidad de azul) en cada pixel, los bits 7 al 4 definen el número- máximo de bits de verde (la intensidad de verde) en cada pixel; y los bits 11 al 8 definen el número máximo de bits de rojo (la intensidad de rojo) en cada pixel, mientras que los bits 15 al 12 están reservados para uso futuro en definiciones de capacidad futuras, y en general están ajustados a cero.

El campo de Capacidad Monocroma de 1 byte contiene un valor que especifica el número de bits de resolución que pueden ser desplegados en un formato monocromo. Si el flujo de video escalado no puede usar el formato monocromo entonces este valor se ajusta a cero. Los bits 7 al 4 están reservados para uso futuro y, por lo tanto, se deben ajustar a cero (?0') para aplicaciones actuales, aunque esto puede cambiar con el tiempo, como entenderán los expertos en la técnica. Los bits 3 al 0 definen el número máximo de bits de escala de grises que pueden existir en cada pixel. Estos cuatro bits hacen posible especificar que cada pixel consiste de 1 a 15 bits. Si el valor es cero entonces el formato monocromo no está soportado por el flujo de video escalado . El campo de Reservado 1 (aquí 1 byte) está reservado para uso futuro al proveer valores relacionados con la información o datos de Paquete de Flujo de Video Escalado. Por lo tanto, actualmente, todos los bits en este campo están ajustados a un ?0' lógico. Un propósito de este campo es hacer que todos los campos de 2 bytes subsiguientes se alineen a una dirección de palabra de 16 bits y hacer que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits . El campo de Capacidad Y Cb Cr de 2 bytes contiene valores que especifican el número de bits de resolución que pueden ser desplegados en formato Y Cb Cr. Si el flujo de video escalado no puede usar el formato Y Cb Cr, entonces este valor es cero. La palabra Capacidad Y Cb Cr se compone de tres valores sin signo separados donde: los bits 3 al 0 definen el número máximo de bits que especifican la muestra Cr; los bits 7 al 4 definen el número máximo de bits que especifican la muestra Cb; los bits 11 al 8 definen el número máximo de bits que especifican la muestra Y; y los bits 15 al 12 están reservados para uso futuro y generalmente se ajustan a cero. El campo de Bits de Capacidad de 1 byte contiene una serie de banderas que especifican capacidades asociadas con el flujo de video escalado. Las banderas están definidas .como sigue: el bit 0 cubre datos de Pixel en el Paquete de Flujo de Video Escalado que pueden estar en un formato empaquetado. Un ejemplo de datos de pixel empaquetados o alineados por bytes se muestra anteriormente en la figura 12. El bit 1 está reservado para uso futuro y generalmente se ajusta a cero; el bit 2 está también reservado para uso futuro y se ajusta a cero; el bit 3 cubre flujos de video escalados que pueden ser especificados en el formato de datos de mapa de colores . La misma tabla de mapa de colores se usa para los flujos de video escalados como se usa para la memoria intermedia de imagen principal y los planos de imagen de alfa-cursor. El mapa de colores es configurado usando el Paquete de Mapa de Colores que se describe en otra parte; y los bits 7 al 4 están reservados para uso futuro y generalmente se ajustan a cero. El campo de Reservado 2 (aquí 1 byte) está reservado para uso futuro al proveer valores relacionados con la información o datos de Paquete de Flujo de Video Escalado. Por lo tanto, actualmente, todos los bits en este campo están ajustados a un ?0' lógico. Un propósito de este campo es hacer que todos los campos de 2 bytes subsiguientes se alineen a una dirección de palabra de 16 bits y hacer que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits. 37. Paquete de configuración de flujo de video escalado El Paquete de Configuración de Flujo de Video Escalado se usa para definir los parámetros del flujo de video escalado y el cliente usa la información para asignar almacenamiento interno para almacenamiento en una memoria intermedia y cambio de escala de la imagen. Un flujo puede ser un desasignado enviando este paquete con los campos de Tamaño de Imagen X y Tamaño de Imagen Y iguales a cero. Los flujos de video escalados que han sido desasignados pueden ser reasignados más tarde con' los mismos o diferentes parámetros de flujo. En una modalidad un cliente indica una capacidad de soportar el Paquete de Configuración de Flujo de Video Escalado usando un valor de parámetros de 143 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido, y usando un valor de no cero en el campo de Número Máximo de Flujos del Paquete de Capacidad de Flujo de Video Escalado. El formato del Paquete de Configuración de Flujo de Video Escalado se muestra en general en la figura 80. Como se ve en la figura 80, en una modalidad, un Paquete de Configuración de Flujo de Video Escalado está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Cliente h, ID de Flujo, Descriptor de Formato de Datos Visuales, Atributos de Datos de Pixel, Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, Tamaño de Imagen X, Tamaño de Imagen Y y CRC . El campo de Longitud de Paquete de 2 bytes especifica el número total de bytes en el paquete sin incluir el campo de longitud de paquete . En una modalidad, esta longitud de paquete se fija a 24. El campo de Tipo de Paquete de 2 bytes emplea un valor de 136 para identificar el paquete como un Paquete de Configuración de Flujo de Video Escalado. El campo de ID de Cliente h de 2 bytes está reservado para uso futuro como una ID de Cliente, y por lo general se ajusta a un valor de cero lógico por el momento, o hasta que un usuario de protocolo determine qué valores de ID se deben usar, como sería conocido. El campo de ID de Flujo usa 2 bytes para especificar un identificador único para la ID de Flujo. Este valor es asignado por el aparato central y varía en un valor de cero al valor de ID de Flujo máximo especificado en el Paquete de Capacidad del Cliente. El aparato central debe administrar el uso de valores de ID de Flujo cuidadosamente para asegurar que a cada flujo activo sea asignado un valor único, y que los flujos que ya no están activos sean desasignados o reasignados . En una modalidad, el campo de Descriptor de Formato de Datos de Video usa 2 bytes para especificar el formato de cada pixel en los Datos de Pixel en el presente flujo en el presente paquete. El formato de datos de pixel debe cumplir por lo menos con uno de los formatos válidos para el plano de imagen de alfa-cursor como se define en el Paquete de Capacidad de Imagen de Alfa-Cursor. El Descriptor de Formato de Datos de Video define el formato de pixel para el paquete actual solamente y no implica que un formato constante continuará siendo usado durante el tiempo de vida de un flujo de video particular. La figura 11 ilustra una modalidad de cómo se codifica el Descriptor de Formato de Datos de Video, y como se discute anteriormente para otros paquetes. En una modalidad, el campo de Atributos de Datos de Pixel de 2 bytes tiene valores que son interpretados como sigue: los bits 1 y 0 seleccionan la pantalla donde los datos de pixel se van a encaminar. Para valores de bit de ll' o ?00' los datos de pixel son desplegados a y para ambos ojos, para valores de bit ?10', los datos son encaminados solamente al ojo izquierdo, y para valores de bit ?01', los datos de pixel son encaminados solamente al ojo derecho. El bit 2 indica si los Datos de Pixel están o no en formato entrelazado. Cuando el bit 2 es 0', entonces los Datos de Pixel están en el formato progresivo estándar. El número de hilera (coordenada Y de pixel) es incrementado en 1 al avanzar de una hilera a la siguiente. Cuando el bit 2 es l', entonces los Datos de Pixel están en formato entrelazado. El número de hilera (coordenada Y de pixel) es incrementado en 2 al avanzar de una hilera a la siguiente. El bit 3 indica si los Datos de Pixel están o no en formato de pixel alterno. Esto es similar al modo entrelazado estándar habilitado por el bit 2, pero el entrelazado es vertical en lugar de horizontal. Cuando el bit 3 es 0, los Datos de Pixel están en el formato progresivo estándar. El número de columna (coordenada X de pixel) es incrementado en 1 a medida que cada pixel consecutivo es recibido. Cuando el bit 3 es 1, entonces los Datos de Pixel están en un formato de pixel alterno. El número de columna (coordenada X de pixel) es incrementado en 2 a medida que cada pixel es recibido. El bit 4 indica si los datos de Pixel están relacionados con la pantalla o la cámara. Cuando el bit 4 es 0, los Datos de Pixel son a o desde la memoria intermedia de cuadro de pantalla. Cuando el bit 4 es 1, los Datos de Pixel son a o desde la cámara. El bit 5 está reservado para uso futuro y, por lo tanto, generalmente está ajustado para ser cero. Los bits 7 y 6 son los Bits de Actualización de Pantalla que especifican la memoria intermedia de cuadro donde los datos de pixel se van a escribir. Los efectos de los Bits de Actualización de Pantalla se describen en más detalle en otra parte. Cuando los Bits [7:6] son 01' , los datos de Pixel son escritos a la memoria intermedia de imagen fuera de línea. Cuando los Bits [7:6] son ?00', los datos de Pixel son escritos a la memoria intermedia de imagen usado para renovar la pantalla. Cuando los Bits [7:6] son ll', los datos de Pixel son escritos a todos las memorias intermedias de imagen. Si los Bits [7:6] son 10' , esto es tratado como un valor inválido. Estos bits están actualmente reservados para uso f turo. En esta situación, los datos de Pixel serían ignorados y no escritos a ninguno de las memorias intermedias de imagen. Los bits 8 al 15 están reservados para uso futuro y, por lo general se ajustan a nivel o valores de cero lógico. 38. Paquete de confirmación de flujo de video escalado El Paquete de Confirmación de Flujo de Video Escalado permite a un cliente confirmar el recibo de un Paquete de Configuración de Flujo de Video Escalado. El cliente puede indicar una capacidad de soportar el Paquete de Confirmación de Flujo de Video Escalado vía 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 vía un valor de no cero en el campo de Número Máximo de Flujos del Paquete de Capacidad de Flujo de Video Escalado. El formato del Paquete de Confirmación de Flujo de Video Escalado se muestra en general en la figura 81. Como se ve en la figura 81, en una modalidad, un Paquete de Confirmación de Flujo de Video Escalado está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Cliente c, ID de Flujo, Código ACK y CRC. El campo de Longitud de Paquete de 2 bytes se usa 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 un Paquete de Confirmación de Flujo de Video Escalado. El campo de ID de Cliente c de 2 bytes está reservado para uso futuro para la ID de Cliente, y generalmente se ajusta a cero. El campo de ID de Flujo de 2 bytes especifica un identificador único para la ID de Flujo. Este es el mismo valor asignado por el aparato central en el Paquete de Configuración de Flujo de Video Escalado. El campo de Código Ack de 2 bytes provee valores que contienen un código que describe el resultado de un intento de actualizar el flujo de video escalado especificado. En una modalidad, los códigos se definen como sigue: 0- El intento de asignación de flujo fue exitoso. 1- El intento de desasignación de flujo fue exitoso. 2- Intento inválido de asignar una ID de flujo que ya ha sido asignada. 3- Intento inválido de desasignar una ID de flujo que ya está desasignada. 4- El cliente no soporta flujos de video escalados. 5- Los parámetros de flujo no son consistentes con la capacidad del cliente. 6- Valor de ID de flujo mayor al valor máximo permitido por el cliente. 7- Recursos insuficientes disponibles en el cliente para asignar el flujo especificado. El campo de CRC de 2 bytes contiene el CRC de todos los bytes en el paquete incluyendo la Longitud de Paquete . 39. Paquete de flujo de video escalado El Paquete de Flujo de Video Escalado se usa para transmitir los datos de pixel asociados con un flujo de video escalado específico. El tamaño de la región a la que hace referencia este paquete es definido por el Paquete de Configuración de Flujo de Video Escalado. El cliente puede indicar una capacidad de soportar el Paquete de Flujo de Video Escalado vía 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 usando una respuesta de asignación de flujo de video escalado exitosa en el campo de Código Ack del Paquete de Confirmación de Flujo de Video Escalado. El formato de una modalidad del Paquete de Flujo de Video Escalado se muestra en general en la figura 82. Como se ve en la figura 82, un Paquete de Flujo de Video Escalado está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente h, ID de Flujo, CRC de Parámetro, Conteo de Pixeles, Datos de Pixel y CRC de Datos de Pixel. El campo de Tipo de Paquete de 2 bytes usa un valor de 18 para identificar un paquete como un Paquete de Flujo de Video Escalado. El campo de ID de Cliente h está reservado para la ID de Cliente, y generalmente se ajusta a cero. Como antes, el campo de ID de Flujo de 2 bytes especifica un identificador único para la ID de Flujo. Este valor es especificado por el aparato central en el Paquete de Configuración de Flujo de Video Escalado y confirmado en el Paquete de Confirmación de Flujo de Video Escalado . El campo de Conteo de Pixeles de 2 bytes especifica el número de pixeles en el campo de Datos de Pixel que se encuentra más adelante. El campo de CRC de Parámetro de 2 bytes tiene el CRC de todos los bytes de la Longitud de Paquete al Conteo de Pixeles . Si este CRC no verifica, entonces el paquete entero es desechado. El campo de Datos de Pixel de 2 bytes contiene la información de video en bruto que se va a escalar y después desplegar. Los datos son formateados en la manera descrita por el campo de Descriptor de Formato de Datos de Video. Los datos son transmitidos una hilera a la vez como se define con anterioridad. El campo de CRC de Datos de Pixel de 2 bytes contiene un CRC de solamente los Datos de Pixel. Si este CRC no verifica, entonces los Datos de Pixel se pueden seguir usando pero el conteo de errores de CRC es incrementado. 40. Paquete de estado específico de solicitud El Paquete de Estado Específico de Solicitud provee un medio, mecanismo o método para que un aparato central solicite que el cliente envíe un paquete de capacidad o estado de vuelta al aparato central como se especifica en este paquete. El cliente regresa el paquete del tipo especificado en el siguiente Paquete de Encapsulación de Enlace Inverso. El cliente generalmente ajustará el bit 17 en el campo de Capacidad de Características de Cliente del Paquete de Capacidad del Cliente si el cliente tiene la capacidad de responder al Paquete de Estado Específico de Solicitud. Un método conveniente para que el aparato central use para determinar todos los tipos de paquetes de estado a los cuales un cliente puede responder es usar el Paquete de Lista de Respuesta de Estado Válido descrito en otra parte. El cliente puede indicar una capacidad de responder con el Paquete de Lista de Respuesta de Estado Válido usando el bit 21 del campo de Capacidad de Características de Cliente del Paquete de Capacidad del Cliente . El formato de una modalidad de un Paquete de Estado Específico de Solicitud se muestra en general en la figura 83. Como se ve en la figura 83, un Paquete de Estado Específico de Solicitud está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente h, ID de Paquete de Estado y CRC. El campo de Longitud de Paquete especifica el número total de bytes en el paquete sin incluir el campo de longitud de paquete, y generalmente se fija a un valor de 10 para este tipo de paquete. Un Tipo de Paquete de 138 identifica el paquete como un Paquete de Estado Específico de Solicitud. El campo de ID de Cliente h (2 bytes) está reservado para uso futuro para una ID de Cliente, y se ajusta a cero por ahora, mientras que un campo de ID de Paquete de Estado de 2 bytes especifica el tipo de paquete de capacidad o estado que el cliente va a enviar al aparato central . Los tipos de paquetes típicos son: 66- El Paquete de Capacidad del Cliente es enviado por el cliente. 133- El Paquete de Capacidad de Imagen de Alfa-Cursor es enviado por el cliente. 139- Se envía el Paquete de Lista de Respuesta de Estado Válido que identifica los tipos exactos de paquetes de capacidad y estado que el cliente puede enviar . 140- El Paquete de Parámetros de Retardo de Procesamiento de Paquete es enviado por el cliente. 141- El Paquete de Capacidad del Cliente Personal es enviado por el cliente. 142- El Paquete de Informe de Errores de Cliente es enviado por el cliente. 143- El Paquete de Capacidad de Flujo de Video Escalado es enviado por el cliente. 144- El Paquete de Identificación de Cliente es enviado por el cliente. Los Tipos de Paquetes 56 al 63 se pueden usar para identificadores de capacidad y estado específicos del fabricante. El campo de CRC de nuevo contiene un CRC para todos los bytes en el paquete incluyendo la Longitud de Paquete . 41. Paquete de lista de respuesta de estado válido El Paquete de Lista de Respuesta de Estado Válido provee al aparato central una estructura, medio o método para tener una lista de paquetes de estado y capacidad a los cuales el cliente tiene la capacidad de responder. Un cliente puede indicar la capacidad de soportar el Paquete de Lista de Respuesta de Estado Válido usando el bit 21 del campo Capacidad de Características de Cliente del Paquete de Capacidad del Cliente . El formato de una modalidad de un Paquete de Lista de Respuesta de Estado Válido se muestra en general en la figura 84. Como se ve 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 Cliente c, 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 se fija en general a un valor de 10, y un valor de tipo de 139 identifica el paquete como un Paquete de Respuesta de Estado Válido. El campo de ID de Cliente c está reservado para uso futuro como la ID de Cliente, y generalmente se ajusta a cero. El campo de 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 especifican los tipos de paquetes de capacidad o estado que el cliente puede enviar al aparato central. Si el cliente ha indicado que puede responder al Paquete de Estado Específico de Solicitud- (usando el bit 21 del campo de Capacidad de Características de Cliente en el Paquete de Capacidad del Cliente) entonces es capaz de enviar por lo menos el Paquete de Capacidad del Cliente (Tipo de Paquete = 66) y el Paquete de Lista de Respuesta de Estado Válido (Tipo de Paquete = 139) . Los Tipos de Paquete que pueden ser enviados por el cliente y que pueden ser incluidos en esta lista, junto con sus asignaciones respectivas para propósitos de una modalidad, son: 66- Paquete de Capacidad del Cliente. 133- Paquete de Capacidad de Imagen de Alfa-Cursor. 139- Paquete de Lista de Respuesta de Estado Válido, que identifica los tipos exactos de paquetes de capacidad y estado que el cliente puede enviar. 140- Paquete de Parámetros de Retardo de Procesamiento de Paquete. 141- Paquete de Capacidad de Pantalla Personal. 142- Paquete de Informe de Errores de Cliente. 143- Paquete de Capacidad de Flujo de Video Escalado. 144- Paquete de Identificación de Cliente. 145- Paquete de Capacidad de Pantalla Alterna. Los Tipos de Paquete 56 al 63 se pueden usar para identificadores de capacidad y estado específicos del fabricante. El campo de CRC contiene un CRC para todos los bytes en el paquete incluyendo la Longitud de Paquete. 42. Paquete de parámetros de retardo de procesamiento de paquete El Paquete de Parámetros de Retardo de Procesamiento de Paquete provee una serie de parámetros para permitir al aparato central calcular el tiempo requerido para completar el procesamiento asociado con la recepción de un tipo de paquete específico. Algunos comandos enviados por el aparato central no pueden ser completados por el cliente en tiempo cero. El aparato central puede sondear los bits de estado en el Paquete de Solicitud y Estado de Cliente para determinar si ciertas funciones han sido completadas por el cliente, o el aparato central puede calcular el tiempo de terminación usando los parámetros regresados por el cliente en el Paquete de Parámetros de Retardo de Procesamiento de Paquete. El cliente puede indicar una capacidad de soportar el Paquete de Parámetros de Retardo de Procesamiento de Paquete usando 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 Retardo de Procesamiento de Paquete se muestra en general en la figura 85A. Como se ve en la figura 85A, un Paquete de Parámetros de Retardo de Procesamiento de Paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente c, Número de Elementos de Lista, Lista de Parámetros de Retardo y CRC . La longitud de paquete para este tipo de paquete se fija en general a un valor de 10, y un valor de tipo de 140 identifica el paquete como un Paquete de Parámetros de Retardo de Procesamiento de Paquete. El campo de ID de Cliente c está reservado para uso futuro como la ID de Cliente, y generalmente se ajusta a cero. El campo de Número de Elementos de 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 Retardo es una lista que contiene uno o más elementos de Lista de Parámetros de Retardo . El formato para una modalidad de un solo elemento de Lista de Parámetros de Retardo se muestra en la figura 85B, donde se muestran los campos de Tipo de Paquete para Retardo, Retardo de Pixel, Retardo de Pixel Horizontal, Retardo de Pixel Vertical y Retardo Fijo. Cada Elemento de Lista de Parámetros de Retardo está por lo general limitado a una longitud de 6 bytes, y se define aún más como sigue. El campo de Tipo de Paquete para Retardo de 2 bytes especifica el Tipo de Paquete para el cual aplican los siguientes parámetros de retardo. El campo de Retardo de Pixel (1 byte) comprende un índice a un valor de retardo. El valor leído de la tabla es multiplicado por el número total de pixeles en el campo de destino del paquete. El número total de pixeles es el ancho por la altura del área de destino del mapa de bits al que hace referencia el paquete. El campo de Retardo de Pixel Horizontal de 1 byte contiene un valor que es un índice a una tabla de valores de retardo (la misma tabla que DPVL) . El valor leído de la tabla es multiplicado por el ancho (en pixeles) del campo de destino del paquete. El campo de Retardo de Pixel Vertical de 1 byte contiene un valor que es un índice a una tabla de valores de retardo (generalmente usa la misma tabla que DPVL) . El valor leído de la tabla es multiplicado por la altura (en pixeles) del campo de destino del paquete. El campo de Retardo Fijo usa 1 byte como un índice a una tabla de valores de retardo (la misma tabla que DPVL) . El valor leído de la tabla es un parámetro de retardo fijo que representa un tiempo requerido para procesar el paquete que no está relacionado con ningún valor de parámetro especificado en el paquete. El retardo total, o retardo de tiempo de terminación de procesamiento de paquete, es determinado de acuerdo con la relación: Retardo = (Retardo de Procesamiento de Paquete (Retardo de Pixel) -Pixeles Totales) + (Retardo de Procesamiento de Paquete (Retardo de Pixel Horizontal) -Ancho) + (Retardo de Procesamiento de Paquete (Retardo de Pixel Vertical) -Altura) + Retardo de Procesamiento de Paquete (Retardo Fijo) Para algunos paguetes, los Pixeles Totales, Ancho o Altura no aplican porque el paquete correspondiente no hace referencia a esos parámetros. En esos casos, el parámetro de Retardo de Pixel correspondiente se ajusta generalmente a cero. 43. Paquete de capacidad de pantalla personal El Paquete de Capacidad de Pantalla Personal provee una serie de parámetros que describen las capacidades de un dispositivo de pantalla personal, tal como un visiocasco o anteojos de visualización. Esto permite al aparato central personalizar la información de visualización de acuerdo con las capacidades específicas de un cliente. Por otra parte, un cliente indica una capacidad de enviar un Paquete de Capacidad de Pantalla Personal usando un parámetro correspondiente 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 Capacidad de Pantalla Personal se muestra en general en la figura 86. Como se ve en la figura 86, un Paquete de Capacidad de Pantalla Personal está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente c, Diseño de Subpixel, Forma de Pixel, Campo de Visión Horizontal, Campo de Visión Vertical, Cruce de Ejes Visuales, Imagen Izq./Der., Transparencia, Brillo Máximo, Capacidad Óptica, IPD Mínima, IPD Máxima, Lista de Puntos de Curvatura de Campo y CRC. En una modalidad, el valor de campo de Longitud de Paquete se fija a 68. Un valor de Tipo de Paquete de 141 identifica un paquete como un Paquete de Capacidad de Pantalla Personal. El campo de ID de Cliente c está reservado para uso futuro y generalmente se ajusta a cero por ahora. El campo de Diseño de Subpixel especifica el diseño físico de un subpixel de la parte superior a la parte inferior y de izquierda a derecha, usando valores de: 0 para indicar que un diseño de subpixel no está definido; 1 para indicar franja roja, verde, azul; 2 para indicar franja azul, verde, roja; 3 para indicar un pixel cuádruple, que tiene una disposición de subpixel de 2 por 2 de rojo en la parte superior izquierda, azul en la parte inferior derecha y dos subpixeles verdes, uno en la parte inferior izquierda y el otro en la parte superior derecha; 4 para indicar un pixel cuádruple, que tiene una disposición de subpixel de 2 por 2 de rojo en la parte inferior izquierda, azul en la parte superior derecha, y dos subpixeles verdes, uno en la parte superior izquierda y el otro en la parte inferior derecha; 5 para indicar una Delta (Triada) ; 6 para indicar un mosaico con rojo, verde y azul superpuestos (por ejemplo, pantalla LCOS con color de campo secuencial) ; y los valores 7 al 255 están reservados generalmente para uso futuro. El campo de Forma de Pixel especifica la forma de cada pixel que se compone de subpixeles de configuración específica, usando un valor de: 0 para indicar que una forma de subpixel no está definida; 1 para indicar redondo; 2 para indicar cuadrado; 3 para indicar rectangular; 4 para indicar ovalado; 5 para indicar elíptico; y los valores 6 al 255 están reservados para uso futuro al indicar formas deseadas, como puede entender el experto en la técnica. Un campo de Campo de Visión Horizontal (HFOV) de 1 byte especifica el campo de visión horizontal en incrementos de 0.5 grados (por ejemplo, si el HFOV es 30 grados, este valor es 60) . Si este valor es cero, entonces el HFOV no está especificado. Un campo de Campo de Visión Vertical (VFOV) de 1 byte especifica el campo de visión vertical en incrementos de 0.5 grados (por ejemplo, si el VFOV es 30 grados, este valor es 60) . Si este valor es cero, entonces el VFOV no está especificado. Un campo de Cruce de Ejes Visuales de 1 byte especifica el cruce de ejes visuales en incrementos de 0.01 dioptrías (1/m) (por ejemplo, si el cruce de ejes visuales es 2.22 metros, este valor es 45) . Si este valor es_ cero, entonces el Cruce de Ejes Visuales no está especificado. Un campo de Superposición de Imagen Izquierda/Derecha de 1 byte especifica el porcentaje de superposición de la imagen izguierda y derecha. El rango permisible de la superposición de imagen en porcentaje es 1 a 100, Los valores de 101 a 255 son inválidos y por lo general no se usan. Si este valor es cero, entonces la superposición de imagen no está especificada . Un campo de Transparencia de 1 byte especifica el porcentaje de transparencia de la imagen. El rango permisible de transparencia en porcentaje es 0 a 100. Los valores de 101 a 254 son inválidos y no se deben usar. Si este valor es 255, entonces el porcentaje de transparencia no está especificado. Un campo de Brillo Máximo de 1 byte específica el brillo máximo en incrementos de 20 nits (por ejemplo, si el brillo máximo es 100 nits, este valor es 5) . Si este valor es cero, entonces el brillo máximo no está especificado. Un campo de Banderas de Capacidad Óptica de 2 bytes contiene varios campos que especifican las capacidades ópticas de la pantalla. Estos valores de bit generalmente son asignados de acuerdo con lo siguiente: Los bits 15 al 5 están reservados para uso futuro y en general se ajustan a un estado de cero lógico. El" bit 4 selecciona el Ajuste de Foco de Lentes, donde un valor de ?0' significa que la pantalla no tiene ajuste de foco de lentes, y un valor de ?l' significa que la pantalla tiene un ajuste de foco de lentes . Los bits 3 al 2 seleccionan una Función Binocular de acuerdo con los siguiente: un valor de 0 significa que la pantalla es binocular y que puede desplegar solamente imágenes bidimensionales (2D) ; 1 significa que la pantalla es binocular y puede desplegar imágenes tridimensionales (3D) ; 2 significa que la pantalla es monocular, y 3 está reservado para uso futuro. Los bits 1 al 0 seleccionan la Simetría de Curvatura de Campo Izquierda-Derecha, donde un valor de 0 significa que la curvatura de Campo no está definida. Si este campo es cero, entonces todos los valores de curvatura de campo del Al al E5 se ajustan a cero excepto el punto C3, el cual especifica una distancia focal de la pantalla o se debe ajustar a cero para indicar que la distancia focal no está especificada. Un valor de 1 significa que las pantallas Izquierda y Derecha tienen la misma simetría; 2 significa que las pantallas Izquierda y derecha están reflejadas en el eje vertical (columna C) ; y 3 está reservado para uso futuro . El campo de Distancia Interpupilar (IPD) Mínima 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 está especificada. El campo de Distancia Interpupilar (IPD) Máxima de 1 byte especifica la distancia interpupilar máxima en milímetros (mm) . Si este valor es cero, entonces la distancia interpupílar máxima no esté especificada. El campo de Lista de Puntos de Curvatura de Campo contiene una lista de 25 parámetros de 2 bytes que especifican la distancia focal en milésimas de una dioptría (1/m) con un rango de 1 a 65535 (por ejemplo, 1 es 0.001 dioptrías y 65535 es 65.535 dioptrías). Los 25 elementos en la Lista de Puntos de Curvatura de Campo están etiquetados Al a E5 como se muestra más adelante. Los puntos se deben distribuir de manera uniforme en un área activa de la pantalla. La columna C corresponde al eje vertical de la pantalla y la hilera 3 corresponde al eje horizontal de la pantalla. Las columnas A y E corresponde a los bordes izquierdo y derecho de la pantalla, respectivamente; y las hileras 1 y 5 corresponden a los bordes superior e inferior de la pantalla, respectivamente. El orden de los 25 puntos en la lista es: Al, Bl, Cl, DI, El, A2, B2, C2, D2, E2, A3, B3, C3, D3, E3, A4, B4, C4, D4, E4, A5, B5, C5, D5, E5.

El campo de CRC contiene un CRC de todos los bytes en el paquete incluyendo la Longitud de Paquete. 44. Paquete de informe de errores de cliente El Paquete de Informe de Errores de Cliente actúa como un mecanismo o medio para permitir a un cliente proveer una lista de errores de operación al aparato central. El cliente puede detectar un amplio rango de errores en el curso de su operación normal como resultado de recibir ciertos comandos del aparato central. Ejemplos de estos errores incluyen: el cliente puede haber ordenado operar en un modo que no soporta, el cliente puede haber recibido un paquete que contiene ciertos parámetros que se encuentran fuera del rango o más allá de la capacidad del cliente, el cliente puede haber ordenado entrar en un modo en una secuencia no apropiada. El Paquete de Informe de Errores de Cliente se puede usar para detectar errores durante la operación normal, pero es más útil al diseñador e integrador del sistema para diagnosticar problemas en el desarrollo e integración de los sistemas del aparato central y cliente. Un cliente indica su capacidad de enviar un Paquete de Informe de Errores de Cliente usando 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 Informe de Errores de Cliente se muestra en general en la figura 87A, Como se ve en la figura 87A, un Paquete de Informe de Errores de Cliente está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente c, Número de Elementos de Lista, Lista de Códigos de Error y CRC. Un valor de Tipo de Paquete de 142 identifica un paquete como un Paquete de Informe de Errores de Cliente. El campo de ID de Cliente c está reservado para uso futuro y generalmente se ajusta a cero por ahora . El campo de Número de Elementos de Lista (2 bytes) especifica el número de elementos en la siguiente Lista de Códigos de Error. El campo de Lista de Códigos de Error (aquí 8 bytes) es una lista que contiene uno o más elementos de Lista de Informe de Errores . El formato de un solo elemento de Lista de Informe de Errores se muestra en la figura 87B. En una modalidad, como se muestra en la figura 87B, cada Elemento de Lista de Informe de Errores tiene una longitud de exactamente 4 bytes, y tiene una estructura en una modalidad que comprende : un campo de Código de Error de Visualización de 2 bytes que especifica el tipo de error que está siendo informado, un campo de Subcódigo de Error de 2 bytes que especifica un mayor nivel de detalle referente al error definido por el paquete de Código de Error de Cliente. La definición específica de cada Código de Error de Cliente es definida por el fabricante del cliente. Un Subcódigo de Error no tiene que ser definido para cada Código de Error de Visualización, y en aquellos casos donde el Subcódigo de Error no está definido el valor se ajusta a cero. La definición específica de cada Subcódigo de Error es proporcionada por el fabricante del cliente. 45. Paquete de identificación de cliente El Paquete de Identificación de Cliente permite a un cliente regresar datos de identificación en respuesta a un Paquete de Estado Específico de Solicitud. En una modalidad, un cliente indica una capacidad de enviar el Paquete de Identificación de Cliente usando un valor de parámetro de 144 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido. Resulta útil que el aparato central sea capaz de determinar el nombre del fabricante y número de modelo del aparato cliente al leer estos datos del cliente. La información se puede usar para determinar si el cliente cuenta con capacidades especiales que no pueden ser descritas en el Paquete de Capacidad del Cliente. Existen potencialmente dos métodos, medios o mecanismos para leer información de identificación del cliente. Uno es mediante el uso del Paquete de Capacidad del Cliente, el cual contiene campos similares a aquellos en la estructura EDID de base. El otro método es mediante el uso de un Paquete de Identificación de Cliente que contiene una serie más rica de información en comparación con los campos similares en el Paquete de Capacidad del Cliente. Esto permite a un aparato central identificar fabricantes a los que no se ha asignado un código EISA de 3 caracteres, y permite que los números de serie contengan caracteres alfanuméricos . El formato de una modalidad de un Paquete de Identificación de Cliente se muestra en general en la figura 88. Como se ve 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 Cliente c, Semana de Fabricación, Año de Fabricación, Longitud del Nombre del Fabricante, Longitud del Nombre del Producto, Longitud del Número de Serie, Cadena de Nombre del Fabricante, Cadena de Nombre del Producto, Cadena de Número de Serie y CRC. El campo de Tipo de Paquete de 2 bytes contiene un valor de que identifica el paquete como un Paquete de Identificación de Cliente. En una modalidad se selecciona que este valor sea de 144. El campo de ID de Cliente c (2 bytes) de nuevo está reservado para uso futuro para la ID de Cliente, y generalmente se ajusta a cero. El campo de CRC (2 bytes) contiene un CRC de 16 bits de todos los bytes en el paquete incluyendo la Longitud de Paquete . Un campo de Semana de Fabricación de 1 byte contiene un valor que define la semana de fabricación de la pantalla. En al menos una modalidad, este valor se encuentra en el rango de 1 a 53 si está soportado por el cliente. Si este campo no está soportado por el cliente, entonces generalmente se ajusta a 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 partida, aunque se podrían usar otros años de base. Años en el rango de 1991 a 2245 pueden ser expresados por este campo. Ejemplo: el año 2003 corresponde a un valor de Año de Fabricación de 13. Si este campo no está soportado por el cliente se debe ajustar a 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 de Cadena de Nombre del Fabricante incluyendo cualesquier caracteres de terminación nula o caracteres de relleno nulos, la longitud del campo de Cadena de Nombre del Producto incluyendo cualesquier caracteres de terminación nula o caracteres de relleno nulos, y la longitud del campo del campo de Cadena de Número de Serie incluyendo cualesquier caracteres de terminación nula o caracteres de relleno nulos, respectivamente. Los campos de Cadena de Nombre del Fabricante, Cadena de Nombre del Producto y Cadena de Número de Serie contienen cada uno un número variable de bytes especificados por los campos de Longitud de Nombre del Fabricante, Nombre del Producto y Número de Serie, respectivamente, que contienen una cadena ASCII que especifica el fabricante, nombre del producto y número de serie alfanumérico de la pantalla, respectivamente. Cada una de estas cadenas está terminada por al menos un carácter nulo . 46. Paquete de capacidad de pantalla alterna El Paquete de Capacidad de Pantalla Alterna indica la capacidad de las pantallas alternas unidas al controlador de cliente MDDI , Es enviado en respuesta a un Paquete de Estado Específico de Solicitud. Cuando se le solicita, un aparato cliente envía un Paquete de Capacidad de Pantalla Alterna para cada pantalla alterna que está soportada. El cliente puede indicar una capacidad de enviar el Paquete de Capacidad de Pantalla Alterna vía un valor de parámetro de 145 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido Para sistemas de MDDI operados en modo interno puede ser común tener más de una pantalla conectada a un controlador de cliente MDDI. Un ejemplo de aplicación es un teléfono móvil con una pantalla grande en el interior de la tapa que protege el teclado y se abre hacia abajo (flip) y una pantalla más pequeña en el exterior. No es necesario que un cliente de modo interno regrese un Paquete de Capacidad de Pantalla Alterna por dos razones potenciales. Primero, el aparato central puede estar ya programado o informado de otra manera de las capacidades durante la fabricación puesto que se usan en un dispositivo o alojamiento común. Segundo, debido al armado de los dos, el cliente no se puede desconectar o separar fácilmente de una conexión al aparato central, y el aparato central puede contener una copia precodificada de las capacidades del cliente, o por lo menos saber que no cambian con un cambio en el cliente, como pudiera ocurrir de otra manera. El campo de Número de Pantallas Alt del Paquete de Capacidad del Cliente se usa para informar que más de una pantalla está unida y el Paquete de Capacidad de Pantalla Alterna informa la capacidad de cada pantalla alterna. El paquete de flujo de video contiene 4 bits en el campo de Atributos de Datos del Pixel para dirigir cada pantalla alterna en el aparato cliente. El formato de una modalidad de un Paquete de Capacidad de Pantalla Alterna se muestra en general en la figura 89. Como se ve 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 Cliente c, Número de Pantalla Alt, Reservado 1, Ancho de Mapa de Bits, Altura de Mapa de Bits, Ancho de Ventana de Pantalla, Altura de Ventana de Pantalla, Ancho de RVA de Mapa de Colores, Capacidad RVA, Capacidad Monocroma, Reservado 2, Capacidad Y Cb Cr, Capacidad de Características de Pantalla, 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 de ID de Cliente c está reservado para una ID de Cliente para uso futuro y generalmente se ajusta a cero. El campo de Número de Pantalla Alt usa 1 byte para indicar la identidad de la pantalla alterna con un entero en el rango de 0 a 15. La primera pantalla alterna es designada típicamente como número 0 y las otras pantallas alternas son identificadas con valores de Número de Pantalla Alt únicos donde el valor más grande usado es el número total de pantallas alternas menos 1. Los valores superiores al número total de pantallas alternas menos 1 no se usan. Ejemplo: un teléfono móvil que tiene una pantalla primaria y una pantalla de ID (identificación) del llamante conectadas a un cliente MDDI tiene una pantalla alterna, de manera que el Número de Pantalla Alt de la pantalla de identificación del llamante es cero y el campo de Número de Pantallas Alt del Paquete de Capacidad del Cliente tiene un valor de 1. El campo de Reservado 1 (1 byte) está reservado para uso futuro. Todos los bits en este campo se ajustan a cero. Un propósito de este campo es hacer que todos los campos de 2 bytes subsiguientes se alineen a una dirección de palabra de 16 bits y hacer que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits. El campo de Ancho de Mapa de Bits usa 2 bytes que especifican el ancho del mapa de bits expresado como un número de pixeles . El campo de Altura de Mapa de Bits usa 2 bytes que especifican la altura del mapa de bits expresada como un número de pixeles. El campo de Ancho de Ventana de Pantalla usa 2 bytes que especifican el ancho de la ventana de pantalla expresado como un número de pixeles . El campo de Altura de Ventana de Pantalla usa 2 bytes que especifican la altura de la ventana de pantalla expresada como un número de pixeles . El campo de Ancho de RVA de Mapa de Colores usa 2 bytes que especifican el número de bits de los componentes de color rojo, verde y azul que pueden ser desplegados en el modo de pantalla de mapa de colores (paleta) . Se puede usar un máximo de 8 bits para cada componente de color (rojo, verde y azul) . Aun cuando 8 bits de cada componente de color son enviados en el Paquete de Mapa de Colores, solamente el número de bits menos significativos de cada componente de color definidos en este campo son usados . Si el cliente de pantalla no puede usar el formato de mapa de colores (paleta), entonces este valor es cero. La palabra Ancho de RVA de mapa de colores se compone de tres valores sin signo separados: Los bits 3 al 0 definen el número máximo de bits de azul en cada pixel donde los valores 0 al 8 se consideran válidos. Los bits 7 al 4 definen el número máximo de bits de verde en cada pixel donde los valores 0 al 8 se consideran válidos. Los bits 11. al 8 definen el número máximo de bits de rojo en cada pixel donde los valores 0 al 8 se consideran válidos. Los bits 14 al 12 están reservados para uso futuro y en general están ajustados a cero. El bit 15 se usa para indicar la capacidad de un cliente de aceptar datos de pixel de Mapa de Colores en formato empaquetado o desempaquetado. Cuando el bit 15 se ajusta a un nivel de uno lógico, esto indica que el cliente puede aceptar datos de pixel de Mapa de Colores en formato ya sea empaquetado o desempaquetado. Si el bit 15 se ajusta a un cero lógico, esto indica que el cliente puede aceptar datos de pixel de Mapa de Colores solamente en formato desempaquetado. El campo de Capacidad RVA usa 2 bytes para especificar el número de bits de resolución que pueden ser desplegados en formato RVA. En una modalidad, si el cliente no puede usar el formato RVA, entonces este valor se ajusta igual a cero. La palabra Capacidad RVA se compone de tres valores sin signo separados : los bits 3 al 0 definen el número máximo de bits de azul (la intensidad de azul) en cada pixel, los bits 7 al 4 definen el número máximo de bits de verde (la intensidad de verde) en cada pixel, y los bits 11 al 8 definen el número máximo de bits de rojo (la intensidad de rojo) en cada pixel. Los bits 14 al 12 están reservados para uso futuro y se ajustan a cero. El bit 15 se usa para indicar la capacidad de un cliente de aceptar datos de pixel RVA en formato empaquetado o desempaquetado. Cuando el bit 15 se ajusta a un nivel de uno lógico, esto indica que el cliente puede aceptar datos de pixel RVA en formato ya sea empaquetado o desempaquetado. Si el bit 15 se ajusta a un cero lógico, esto indica que el cliente puede aceptar datos de pixel RVA solamente en formato desempaquetado. El campo de Capacidad Monocroma de 1 byte contiene un valor o información para especificar el número de bits de resolución que pueden ser desplegados en formato monocromo. Si el cliente no puede usar el formato monocromo, entonces este valor se ajusta igual a cero. Los bits 6 al 4 están reservados para uso futuro y se ajustan a cero. Los bits 3 al 0 definen el número máximo de bits de escala de grises que pueden existir en cada pixel. Estos cuatro bits hacen posible especificar que cada pixel consiste de 1 a 15 bits. Si el valor es cero entonces el formato monocromo no está soportado por el cliente. Cuando el bit 7 se ajusta a uno indica que el cliente puede aceptar datos de pixel monocromo ya sea en formato empaquetado o desempaquetado. Si el bit 7 se ajusta a cero, esto indica que el cliente puede aceptar datos de pixel monocromo únicamente en formato desempaquetado. El campo de Reservado 2 es un campo de 1 byte de ancho reservado para uso futuro y en general tiene todos los bits en este campo ajustados a nivel de cero lógico. En una modalidad, un propósito de este campo es hacer que todos los campos de 2 bytes subsiguientes se alineen a una dirección de palabra de 16 bits y hacer que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits. Un campo de Capacidad Y Cb Cr de 2 bytes especifica el número de bits de resolución que pueden ser desplegados en formato Y Cb Cr. Si el cliente no puede usar el formato Y Cb Cr, entonces este valor es cero. La palabra Capacidad Y Cb Cr se compone de tres valores sin signo separados: los bits 3 al 0 definen el número máximo de bits que especifican la muestra Cb; los bits 7 al 4 definen el número máximo de bits que especifican la muestra Cr; los bits 11 al 8 definen el número máximo de bits que especifican la muestra Y; y los bits 14 al 12 están reservados para uso futuro y se ajustan a cero. Cuando el bit 15 se ajusta a uno indica que el cliente puede aceptar datos de pixel Y Cb Cr ya sea en formato empaquetado o desempaquetado. Si el bit 15 se ajusta' a cero, esto indica que el cliente puede aceptar datos de pixel Y Cb Cr únicamente en formato desempaquetado . Un campo de Capacidad Bayer de 2 bytes especifica el número de bits de resolución, grupo de pixeles y orden de pixeles que pueden ser transferidos en formato Bayer. Si el cliente no puede usar el formato Bayer, entonces este valor es cero. El campo de Capacidad Bayer se compone de los siguientes valores: los bits 3 al 0 definen el número máximo de bits de intensidad que existen en cada pixel, los bits 5 al 4 definen el patrón de grupo de pixeles que puede ser requerido, los bits 8 al 6 definen un orden de pixeles que es requerido, y los bits 14 al 9 están reservados para uso futuro y se ajustan a cero. Cuando el bit 15 se ajusta a uno indica que el cliente puede aceptar datos de pixel Bayer ya sea en formato empaquetado o desempaquetado. Si el bit 15 se ajusta a cero, esto indica que el cliente puede aceptar datos de pixel Bayer únicamente en formato desempaquetado . El campo de CRC de 2 bytes contiene un CRC de 16 bits de todos los bytes en el paquete incluyendo la Longitud de Paquete . 47. Paquete de acceso a registros El Paquete de Acceso a Registros provee ya sea a un aparato central o a un cliente, un medio, mecanismo o método para acceder a registros de configuración y estado en el extremo opuesto del enlace de MDDI. Es probable que estos registros sean únicos para cada pantalla o controlador de dispositivo. Estos registros ya existen en muchas pantallas que requieren configuraciones de ajuste, modos de operación y tienen otros ajustes útiles necesarios. El Paquete de Acceso a Registros permite que el aparato central o cliente MDDI tanto escriban a un registro como soliciten leer un registro usando el enlace de MDDI . Cuando el aparato central o cliente solicita leer un registro, el extremo opuesto debe responder enviando los datos de registro en el mismo tipo de paquete, pero también indicando que estos son los datos leídos de un registro particular con el uso del campo de Info de Lectura/Escritura. El Paquete de Acceso a Registros se puede usar para leer o escribir múltiples registros especificando un conteo de registros mayor a 1. Un cliente indica una capacidad de soportar el Paquete de Acceso a Registros usando el bit 22 del campo Capacidad de Características de Cliente del Paquete de Capacidad del Cliente . El formato de una modalidad de un Paquete de Acceso a Registros se muestra en general en la figura 90. Como se ve en la figura 90, un Paquete de Acceso a Registros está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, ID de Cliente b, Banderas de Lectura/Escritura, Dirección de Registro, CRC de Parámetro, Lista de Datos de Registro y CRC de Datos de Registro. Un valor de Tipo de Paquete de 146 identifica un paquete como un Paquete de Acceso a Registros . El campo de ID de Cliente b está reservado para uso futuro y generalmente se ajusta a cero por ahora. El campo de Banderas de Lectura/Escritura de 2 bytes especifica el paquete específico ya sea como una escritura, o una lectura, o una respuesta a una lectura, y provee un conteo de los valores de datos. Los bits 15 al 14 actúan como Banderas de Lectura/Escritura. Si los bits [15:14] son ?00', entonces este paquete contiene datos que se van a escribir a un registro dirigido por el campo de Dirección de Registro. Los datos que se van a escribir a los registros especificados están contenidos en el campo de Lista de Datos de Registro. Si los bits [15:14] son 10', 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 ll' , entonces ese paquete contiene datos que fueron solicitados en respuesta a un Paquete de Acceso a Registros que tiene los bits 15:14 de las Banderas de Lectura/Escritura ajustados a ?10' . El campo de Dirección de Registro contiene la dirección del registro correspondiente al primer elemento de Lista de Datos de Registro, y el campo de Lista de Datos de Registro contiene datos • que fueron leídos desde la dirección o direcciones. Si los bits [15:14] son ?01' , esto se trata como un valor inválido, este valor está reservado para uso futuro y no se usa. Los bits 13:0 usan un entero sin signo de 14 bits para especificar el número de 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 elementos de datos de registro de 32 bits que están contenidos en el campo de Lista de Datos de Registro que se va a escribir a registros empezando en el registro especificado por el campo de Dirección de Registro. Si los bits 15:14 son iguales a ?10' , entonces los bits 13:0 especifican el número de elementos de datos de registro de 32 bits que el dispositivo receptor envía a un dispositivo solicitando que los registros sean leídos. El campo de Lista de Datos de Registro en este paquete no contiene elementos y tiene una longitud de cero. Si los bits 15:14 son iguales a ?ll', entonces los bits 13:0 especifican el número de elementos de datos de registro de 32 bits que han sido leídos desde lo registros que están contenidos en el campo de Lista de Datos de Registro. Los bits 15:14 no están actualmente ajustados igual a ?01', lo cual se considera un valor inválido, y están reservados de otra manera para designaciones o uso f turos. El campo de Dirección de Registro usa 4 bytes para indicar la dirección de registro a la que se debe escribir o de la que se debe leer. Para dirigir registros cuyo direccionamiento es menor a 32 bits, los bits superiores se ajustan a cero. El campo de CRC de Parámetro de 2 bytes contiene un CRC de todos los bytes de la Longitud de Paquete a la Dirección de Registro. Si este CRC no verifica, entonces el paquete completo es desechado. 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 a registros o valores de cliente que fueron leídos de registros de aparato cliente. El campo de CRC de Datos de Registro de 2 bytes contiene un CRC de solamente la Lista de Datos de Registro. Si este CRC no verifica, entonces los Datos de Registro se pueden seguir usando, pero el conteo de errores de CRC es incrementado.

D. CRC de paquete Los campos de CRC aparecen al final de los paquetes y algunas veces después de ciertos parámetros más críticos en paquetes que pueden tener un campo de datos significativamente grande, y por consiguiente, una probabilidad incrementada de errores durante la transferencia. En paquetes que tienen dos campos de CRC, el generador de CRC, cuando se usa solamente uno, es reinicializado después del primer CRC de manera que los cálculos de CRC que siguen un campo de datos largo no sean afectados por los parámetros al inicio del paquete . En una modalidad ejemplar, el polinomio usado para el cálculo de CRC es conocido como el CRC-16, o X16+X15+X2+X0. Una implementación de muestra de un generador y comprobador de CRC 3600 útiles para implementar la invención se muestra en la figura 36. En la figura 36, un registro de CRC 3602 es inicializado a un valor de 0x0001 justo antes de la transferencia del primer bit de un paquete el cual es introducido en la línea Tx_MDDI_Datos_Antes de_CRC, luego los bytes del paquete son cambiados en el registro empezando con el LSB primero. Observar que los números de bit de registro en esta figura corresponden al orden del polinomio que se está usando, y no las posiciones de bit usadas por la MDDI. Es más eficiente cambiar el registro de CRC en una sola dirección, y esto da por resultado que el bit 15 de CRC aparezca en la posición de bit 0 del campo de MDDI CRC, y el bit 14 de registro de CRC en la posición de bit 1 del campo de MDDI CRC, y así sucesivamente hasta que se alcance la posición de bit 14 de MDDI. Como un ejemplo, si los contenidos de paquete para los Paquetes de Solicitud y Estado de Cliente son: OxOOOc, 0x0046, 0x000, 0x0400, 0x00, 0x00, 0x0000 (o representados como una secuencia de bytes como: 0x0c, 0x00, 0x46, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00) , y son presentados usando las entradas de los multiplexores 3604 y 3606, y puerta NAND 3608, la salida de CRC resultante en la línea Tx_MDDI_Datos_Con_CRC es 0xd9aa (o representados como una secuencia como Oxaa, 0xd9) . Cuando el generador y comprobador de CRC 3600 están configurados como un comprobador de CRC, el CRC que es recibido en la línea Rx_MDDI_Datos es introducido al multiplexor 3604 y puerta NAND 3608, y es comparado bit por bit con el valor encontrado en el registro de CRC usando la puerta ÑOR 3610, puerta OR (XOR) -exclusiva 3612, y puerta AND 3614. Si hay cualesquier errores, como salida por la puerta AND 3614, el CRC es incrementado una vez para cada paquete que contiene un error de CRC conectando la salida de la puerta 3614 a la entrada del registro 3602. Observar que el circuito de ejemplo mostrado en el diagrama de la figura 36 puede hacer salir más de una señal de error de CRC dentro de una ventana VERIFICAR_CRC_AHORA dada (ver figura 37B) . Por consiguiente, el contador de errores de CRC en general solamente cuenta el primer caso de error de CRC dentro de cada intervalo donde VERIFICAR_CRC_AHORA está activa. Si se configura como un generador de CRC, el CRC es sincronizado por reloj fuera del registro de CRC en el momento que coincide con el fin del paquete . La temporización para las señales entrada y salida, y las señales habilitantes, se ilustra de manera gráfica en las figuras 37A y 37B. La generación de un CRC y transmisión de un paquete de datos se muestran en la figura 37A con el estado (0 ó 1) de las señales Gen_Reinicialización, Verificar_CRC_Ahora, Generar_CRC_Ahora, y Enviando_MDDI_Datos, junto con las señales Tx_MDDI_Datos_Antes_de_CRC y Tx_MDDI_Datos__Con_CRC. La recepción de un paquete de datos y comprobación del valor de CRC se muestran en la figura 37B, con el estado de las señales Gen_Reinicialización, Verificar_CRC_Ahora, Generar_CRC_Ahora, y Enviando_MDDI_Datos, junto con las señales Rx_MDDI_Datos y error de CRC.

? . Sobrecarga de código de error para CRC de paquete Siempre que solamente paquetes de datos y CRC sean transferidos entre el aparato central y el cliente, no se están admitiendo códigos de error. El único error es una pérdida de sincronización. De otro modo, uno tiene que esperar que transcurra el tiempo de espera de un enlace de una falta de una buena trayectoria de transferencia de datos o cadena de procesamiento y después restablecer el enlace y continuar. Desafortunadamente, esto toma mucho tiempo y es un poco ineficiente . Para usar en una modalidad, se ha desarrollado una nueva técnica en la cual la porción de CRC de paquetes se usa para transferir información de código de errores. Esto se muestra en general en la figura 65. Esto es, uno o más códigos de error son generados por los procesadores o dispositivos que manejan la transferencia de datos que indican los errores o defectos definidos previamente específicos que pudieran ocurrir dentro del procesamiento o enlace de comunicación. Cuando se encuentra un error, el código de error apropiado es generado y transferido usando los bits para el CRC de un paquete. Esto es, el valor de CRC es sobrecargado, o sobreescrito, con el código de error deseado, el cual puede ser detectado en el extremo receptor por un monitor o comprobador de errores que monitorea los valores del campo de CRC. Para esos casos en los cuales el código de error coincide con el valor de CRC por alguna razón, el cumplimiento del error es transferido para evitar confusión. En una modalidad, para proveer un sistema robusto de alerta y detección de errores, el código de error puede ser transferido varias veces, usando una serie de paquetes, generalmente todos, que son transferidos o enviados después de que el error ha sido detectado. Esto ocurre hasta el punto en el cual la condición que crea el error es borrada del sistema, punto en el cual los bits de CRC regulares son transferidos sin sobrecarga por otro valor. Esta técnica de sobrecargar el valor de CRC provee una respuesta mucho más rápida a los errores del sistema mientras que usa una cantidad mínima de bits o campos extra. Como se muestra en la figura 66, un mecanismo o aparato de sobreescritura de CRC 6600 se muestra usando un detector o medio de detección de errores 6602, el cual puede formar parte de otra circuitería descrita o conocida anteriormente, detecta la presencia o existencia de errores dentro del enlace o proceso de comunicación. Un generador o medio de código de error 6604, el cual puede estar formado como parte de otra circuitería o usar técnicas tales como tablas de búsqueda para almacenar mensajes de error seleccionados previamente, genera uno o más códigos de error para indicar errores o defectos predefinidos específicos que han sido detectados conforme ocurren. Se entiende fácilmente que los dispositivos 6602 y 6604 pueden estar formados como un solo circuito o dispositivo como se desee, o como parte de una secuencia programada de pasos para otros procesadores y elementos conocidos. Un comparador o medio de comparación de valor de CRC 6606 se muestra para verificar si el código o códigos de error seleccionados son los mismos en el valor de CRC que está siendo transferido. Si ése es el caso, entonces un generador o medio o dispositivo de generación de cumplimiento de código se usa para proveer el cumplimiento de los códigos de error para que no sean tomados por el patrón o valor de CRC original y confundir o complicar el esquema de detección. Un selector o medio, elemento o dispositivo de selección de código de error 6610 selecciona después el código o valor de error que se desea insertar o sobreescribir, o sus cumplimientos respectivos como sea apropiado. Un dispositivo de sobreescritura o mecanismo o medio de sobreescritura de CRC de error de código 6612 es un dispositivo que recibe el flujo de datos, paquetes y los códigos deseados que se van a insertar y sobreescribe los valores de CRC correspondientes o apropiados, a fin de transferir los códigos de error deseados a un dispositivo receptor. Como se mencionó, el código de error puede ser transferido varias veces, usando una serie de paquetes, de manera que el dispositivo de sobreescritura 6612 puede utilizar elementos de almacenamiento de memoria a fin de mantener copias de los códigos durante el procesamiento o recordar esos códigos de elementos anteriores u otras ubicaciones de almacenamiento conocidas que se pueden usar para almacenar o tener sus valores como sea necesario o como se desee. El procesamiento general que el mecanismo de sobreescritura de la figura 66 está implementando se muestra en detalle adicional en las figuras 67A y 67B. En 67A, un error, uno o más, es detectado en el paso 6702 en los datos o proceso de comunicación y un código de error es seleccionado en el paso 6704 para indicar esa condición. Al mismo tiempo, o en un punto apropiado, el valor de CRC que se va a reemplazar es verificado en un paso 6706, y comparado con el código de error deseado en el paso 6708. El resultado de esta comparación, como se discutió antes, es determinar si el código deseado, u otros valores representativos, serán o no los mismos que el valor de CRC presente. Si éste es el caso, entonces el procedimiento continúa a un paso 6712 donde el cumplimiento, o en algunos casos otro valor representativo, como se desee, es seleccionado como el código a insertar. Una vez que se ha determinado qué códigos o valores de error se van a insertar en los pasos 6710 y 6714, ese código apropiado se selecciona para inserción. Estos pasos se ilustran como separados para propósitos de claridad pero por lo general representan una sola elección basada en la salida de la decisión del paso 6708. Por último, en el paso 6716 los valores apropiados son sobreescritos en la ubicación de CRC para transferencia con los paquetes que son dirigidos por el proceso. En el lado de la recepción del paquete, como se muestra en la figura 67B, los valores de CRC de paquete están siendo monitoreados en un paso 6722. En general, los valores de CRC están siendo monitoreados por uno o más procesos dentro del sistema para determinar si un error en la transferencia de datos ha ocurrido y si se va a solicitar o no una retransmisión del paquete o paquetes, o si se van a inhibir más operaciones y así sucesivamente, algunos de los cuales se discuten anteriormente . Como parte de dicho monitoreo la información se puede usar también para comparar valores con códigos . de error conocidos o seleccionados previamente, o valores representativos y detectar la presencia de errores. De manera alternativa, se pueden implementar un proceso y monitor de detección de errores separados. Si un código parece estar presente es extraído o de otra manera observado en el paso 6724 para procesamiento adicional. Se puede determinar en el paso 6726 si éste es o no el código real o un cumplimiento, en cuyo caso un paso adicional 6728 se usa para traducir el valor al valor de código deseado. En cualquiera de los dos casos el código extraído resultante, cumplimiento u otros valores recuperados se usan luego para detectar qué error ha ocurrido del código transmitido en el paso 6730.

V. Hibernación de enlace El enlace de MDDI puede entrar en el estado de hibernación rápidamente y despertar de la hibernación rápidamente. Esta capacidad de respuesta permite que un sistema o dispositivo de comunicación obligue al enlace de MDDI a entrar en hibernación con frecuencia para reducir el consumo de potencia, puesto que se puede despertar otra vez para uso muy rápido. En una modalidad, a medida que un cliente de modo externo se despierta de la hibernación por primera vez lo hace a un índice de datos y con una temporización de pulso de señal de validación que es consistente en con un índice de 1 Mbps, esto es, el par MDDI Stb debe conmutar a un índice de 500 kHz. Una vez que las características del cliente han sido descubiertas por o comunicadas al aparato central, entonces el aparato central puede activar el enlace generalmente a cualquier índice de 1 Mbps al índice máximo al cual el cliente puede operar. Los clientes de modo interno pueden despertar a cualquier índice al cual tanto el aparato central como el cliente puedan operar. Esto es también generalmente aplicable a la primera vez que un cliente de modo interno despierta. En una modalidad, cuando el enlace despierta de la hibernación, el aparato central y el cliente intercambian una secuencia de pulsos. Estos pulsos pueden ser detectados usando receptores de línea de baja velocidad que consumen únicamente una fracción de la corriente como los receptores diferenciales requeridos para recibir las señales a la velocidad de operación de enlace máxima. Ya sea el aparato central o el cliente pueden activar el enlace, de manera que el protocolo de activación está diseñado para manejar la posible contienda que puede ocurrir si tanto el aparato central como el cliente intentan despertar de manera simultánea . Durante el estado de hibernación a los excitadores diferenciales de MDDI Datos y MDDI Stb son inhabilitados y el voltaje diferencial en todos los pares diferenciales es cero volts . Los receptores de línea diferenciales usados para detectar la secuencia de pulsos durante la activación de la hibernación tienen un desplazamiento de voltaje intencional. En una modalidad, el umbral entre un nivel de uno lógico y cero lógico en estos receptores es aproximadamente 125 mV. Esto ocasiona que un par diferencial no impulsado sea visto como un nivel de cero lógico durante la secuencia de activación del enlace. A fin de entrar en un Estado de Hibernación, el aparato central envía 64 ciclos MDDI_Stb después del CRC del Paquete de Interrupción de Enlace. El aparato central inhabilita la salida de MDDI_DatosO del aparato central en el rango de 16 a 56 ciclos MDDI_Stb (incluyendo retardos de propagación de inhabilitación de salida) después del CRC. El aparato central termina enviando los 64 ciclos MDDI_Stb después del CRC del paquete de Interrupción de Enlace antes de que inicie la secuencia de activación. En una modalidad, la activación iniciada por el aparato central se define como el aparato central que tiene que esperar por lo menos 100 nseg después de que MDDI_DatosO alcanza un nivel de uno lógico válido antes de llevar impulsos en MDDI_Stb. En una modalidad, el cliente espera por lo menos 60 ciclos MDDI_Stb después del CRC del Paquete de Interrupción de Enlace antes de impulsar MDDI_Datos0 a un nivel de uno lógico para intentar activar al aparato central . A fin de "despertar" de un Estado de Hibernación, se llevan a cabo diversas acciones o procesos. Cuando el cliente, aquí una pantalla, necesita datos o comunicación, servicio, del aparato central, impulsa la línea MDDI_DatosO a un estado de uno lógico durante aproximadamente 70 a 1000 µseg, mientras que MDDI_Stb está inactiva y mantiene MDDI_DatosO impulsada a un nivel de uno lógico durante aproximadamente 70 ciclos MDDI_Stb (en un rango de 60 a 80) después de que MDDI_Stb se activa, aunque se pueden usar otros periodos como se desee. El cliente inhabilita después el excitador de MDDI_DatosO colocándolo en un estado de alta impedancia. Si MDDI_Stb está activa durante la hibernación, aunque no es probable, entonces el cliente pudiera solamente impulsar MDDI_DatosO a un estado de uno lógico durante aproximadamente 70 ciclos MDDI_Stb (en un rango de 60 a 80) . Esta acción ocasiona que el aparato central inicie o reinicie el tráfico de datos en el enlace hacia adelante (208) y sondee al cliente para conocer su estado.

El aparato central debe detectar la presencia del pulso de solicitud e inicia la secuencia de inicio primero impulsando MDDI_Stb a un nivel de cero lógico y MDDI_DatosO a un nivel alto lógico durante al menos aproximadamente 200 nseg; y después cuando conmute MDDI_Stb continuar llevando los MDDI_DatosO a un nivel de uno lógico durante aproximadamente 150 ciclos MDDI_Stb (un rango de 140 a 160) y a cero lógico durante aproximadamente 50 ciclos MDDI_Stb. El cliente no debe enviar un pulso de solicitud de servicio si detecta MDDI_Datos0 en el estado de uno lógico durante más de 80 ciclos MDDI_Stb. Cuando el cliente ha detectado MDDI_DatosO a un nivel de uno lógico durante 60 a 80 ciclos MDDI_Stb, empieza a buscar el intervalo donde el aparato central impulsa MDDI_DatosO a un nivel de cero lógico durante 50 ciclos MDDI_Stb. Después de que el aparato central impulsa MDDI_DatosO a un nivel de cero lógico durante 50 ciclos MDDI_Stb, entonces el aparato central empieza a enviar paquetes en el enlace. El primer paquete enviado es un Paquete de Cabecera de Subcuadro. El cliente empieza a buscar el Paquete de Cabecera de Subcuadro después de que MDDI_Datos0 está a un nivel de cero lógico durante 40 ciclos MDDI_Stb del intervalo de 50 ciclos. La naturaleza de la selección de los tiempos y tolerancias de los intervalos de tiempo relacionados con el procesamiento de hibernación y secuencia de inicio se discute más adelante. (Ver figuras 68A-C más adelante) . El aparato central puede iniciar la activación habilitando primero MDDI_Stb e impulsándola de manera simultánea a un nivel de cero lógico. El MDDI_Stb no debe ser impulsada a nivel de uno lógico hasta que los pulsos sean producidos como se describe más adelante. Después de que MDDI_Stb alcanza un nivel de cero lógico, el aparato central habilita MDDI_DatosO y la impulsa de manera simultánea a un nivel de uno lógico. MDDI_DatosO no deben ser impulsada a un nivel de cero lógico durante el proceso de activación hasta el intervalo donde es impulsada a un nivel de cero lógico durante un intervalo de 50 pulsos MDDI_Stb como se describe más adelante. El aparato central debe esperar por lo menos 200 nseg después de que MDDI_Datos0 alcanza un nivel de uno lógico válido antes de llevar pulsos en MDDI_Stb. Esta relación de temporización ocurre mientras se considera el peor caso de retardos de habilitación de salida. Esto garantiza de manera sustancial que un cliente cuenta con tiempo suficiente para habilitar completamente su receptor de MDDI_Stb después de ser despertado por un nivel de uno lógico en MDDI DatosO que fue ompulsada por el aparato central.

Un ejemplo de los pasos de procesamiento para un evento de solicitud de servicio de cliente típico 3800 sin contienda se ilustra en la figura 38, donde los eventos están etiquetados para conveniencia en la ilustración usando las letras A, B, C, D, E, F y G. El proceso empieza en el punto A cuando el aparato central envía un Paquete de Interrupción de Enlace al aparato cliente para informarle que el enlace cambiará a un estado de hibernación de baja potencia. En un siguiente paso, el aparato central entra en el estado de hibernación de baja potencia inhabilitando el excitador de MDDI_DatosO y ajusfando el excitador de MDDI_Stb a un cero lógico, como se muestra en el punto B. MDDI_DatosO es impulsada a un nivel de cero lógico por una red polarizadora de alta impedancia. Después de un período de tiempo, el cliente envía un pulso de solicitud de servicio al aparato central impulsando MDDI_DatosO a un nivel de uno lógico como se ve en el punto C. El aparato central afirma aún el nivel de cero lógico usando la red polarizadora de alta impedancia, pero el excitador en el cliente fuerza a la línea a un nivel de uno lógico. En 50 µseg, el aparato central reconoce el pulso de solicitud de servicio y afirma un nivel de uno lógico en MDDI_Datos0 habilitando su excitador, como se ve en el punto D. Luego el cliente deja de intentar afirmar el pulso de solicitud de servicio, y el cliente pone su excitador en un estado de alta impedancia, como se ve en el punto E. El aparato central impulsa MDDI_DatosO a un nivel de cero lógico durante 50 µseg, como se muestra en el punto F, y también empieza a generar MDDI_Stb en una manera consistente con el nivel de cero lógico en MDDI_DatosO. El cliente empieza a buscar el Paquete de Cabecera de Subcuadro después de que MDDI_DatosO está a un nivel de cero lógico durante 40 ciclos MDDI_Stb. Después de afirmar MDDI_DatosO a un nivel de cero lógico e impulsar MDDI_Stb durante 50 µseg, el aparato central empieza a transmitir datos en el enlace hacia adelante enviando un Paquete de Cabecera de Subcuadro, como se muestra en el punto G. Un ejemplo similar se ilustra en la figura 39 donde una solicitud de servicio es afirmada después de que la secuencia de reinicio de enlace ha empezado, y los eventos son etiquetados de nuevo usando las letras A, B, C, D, E, F y G. esta representa el peor caso donde un pulso o señal de solicitud del cliente se acerca a corromper el Paquete de Cabecera de Subcuadro . El proceso comienza en el punto A donde el aparato central de nuevo envía un Paquete de Interrupción de Enlace a un aparato cliente para informarle que el enlace cambiará a un estado de hibernación de baja potencia. En un siguiente paso, el aparato central entra en el estado de hibernación de baja potencia inhabilitando el excitador de MDDI_DatosO y ajusfando el excitador de MDDI_Stb a un nivel de cero lógico, como se muestra en el punto B. Como antes, MDDI_DatosO es impulsada a un nivel de cero lógico por una red polarizadora de alta impedancia. Después de un período de tiempo, el aparato central comienza la secuencia de reinicio de enlace impulsando MDDI_DatosO a un nivel de uno lógico durante 150 µseg como se ve en el punto C. Antes de que pasen 50 µseg después de que la secuencia de reinicio de enlace comienza, la pantalla afirma también MDDI_DatosO por una duración de 70 µseg, como se ve en el punto D. Esto pasa porque la pantalla tiene una necesidad de solicitar servicio del aparato central y no reconoce que el aparato central ya ha comenzado la secuencia de reinicio de enlace. Entonces el cliente deja de intentar afirmar el pulso de solicitud de servicio, y el cliente pone su excitador en un estado de alta impedancia, como se ve en el punto E. El aparato central continúa impulsando MDDI_DatosO a un nivel de uno lógico. El aparato central impulsa MDDI_DatosO a un nivel de cero lógico durante 50 µseg, como se muestra en el punto F, y también empieza a generar MDDI Stb en una manera consistente con el nivel de cero lógico en MDDI_DatosO. Después de afirmar MDDI_DatosO a un nivel de cero lógico e impulsar MDDI_Stb durante 50 µseg, el aparato central empieza a transmitir datos en el enlace hacia adelante enviando un Paquete de Cabecera de Subcuadro, como se muestra en el punto G. A partir de la discusión anterior, se ve que la solución anterior implicada hace que el aparato central atraviese dos estados como parte de una secuencia de activación. Para el primer estado, el aparato central impulsa la señal MDDI_DatosO al estado alto durante 150 µs, y luego impulsa la señal MDDI_DatosO al estado bajo durante 50 µs mientras activa la línea MDDI_Stb, y después empieza a transmitir paquetes MDDI. Este proceso funciona bien para hacer avanzar el estado de la técnica en términos de índices de datos que se pueden obtener usando el aparato y métodos MDDI . No obstante, como se mencionó antes, más velocidad en términos de tiempo de respuesta reducido a condiciones o ser capaz de seleccionar más rápido el siguiente paso o proceso, son la capacidad de simplificar el procesamiento o elementos, siempre tienen demanda. Los solicitantes han descubierto un nuevo enfoque inventivo al procesamiento y temporización de activación en el cual el aparato central usa una temporización basada en ciclo de reloj para la conmutación de señales. En esta configuración, el aparato central empieza a conmutar MDDI_Stb de 0 a 10 µseg después de que el aparato central impulsa la señal MDDI_DatosO al estado alto al comienzo de la secuencia de activación, y no espera hasta que la señal sea impulsada al estado bajo. Durante una secuencia de activación, el aparato central conmuta MDDI_Stb como si la señal MDDI_DatosO estuviera siempre a un nivel de cero lógico. Esto elimina de manera efectiva el concepto de tiempo desde el lado del cliente, y el aparato central cambia de los períodos anteriores de 150 µs y 50 µs para los primeros dos estados, a 150 ciclos de reloj y 50 ciclos de reloj , para estos períodos . El aparato central ahora se vuelve responsable de impulsar la línea de datos al estado alto, y dentro de 10 ciclos de reloj empezar a transmitir una señal de validación como si la línea de datos fuera cero. Después de que el aparato central ha impulsado la línea de datos al estado alto durante 150 ciclos de reloj, el aparato impulsa la línea de datos al estado bajo durante 50 ciclos de reloj mientras continúa transmitiendo la señal de validación. Después de que ha completado ambos procesos, el aparato central empieza a transmitir el primer paquete de cabecera de subcuadro. En el lado del cliente, la implementación de cliente puede ahora usar el reloj generado para calcular el número de ciclos de reloj que la línea de datos está primero en el estado alto, y luego en el estado bajo. El número de ciclos de reloj que necesitan ocurrir en la línea de datos impulsada al estado alto es 150 y en la línea de datos impulsada al estado bajo es 50. Esto significa que para una secuencia de activación apropiada, el cliente debe ser capaz de contar por lo menos 150 ciclos de reloj continuos de la línea de datos en el estado alto, seguido de por lo menos 50 ciclos de reloj continuos de la línea de datos en el estado bajo. Una vez que se cumplen estas dos condiciones, el cliente puede empezar a buscar la palabra única del primer subcuadro. Se usa una pausa en este patrón como base para regresar los contadores a un estado inicial en el cual el cliente nuevamente busca los primeros 150 ciclos de reloj continuos de la línea de datos en el estado alto. Una implementación de cliente de la invención para activación de la hibernación basada en aparato central es muy similar al caso de arranque inicial excepto que el índice de reloj no es forzado a empezar a 1 Mbps, como se discutió anteriormente. Más bien, el índice de reloj se puede ajustar para reanudar en cualquier índice anterior que estaba activo cuando el enlace de comunicación entró en hibernación. Si el aparato central empieza la transmisión de una señal de validación como se escribe con anterioridad, el cliente debe ser capaz de contar de nuevo por lo menos 150 ciclos de reloj continuos de la línea de datos en estado alto, seguido de por lo menos 50 ciclos de reloj continuos de la línea de datos en el estado bajo. Una vez que se han cumplido estas dos condiciones, el cliente puede empezar la búsqueda de la palabra única.

Una implementación de cliente de la invención para activación de la hibernación basada en cliente es similar a la activación basada en aparato central excepto que empieza teniendo el cliente impulsando la línea de datos . El cliente puede impulsar en forma asincrona la línea de datos sin un reloj para activar el aparato central. Una vez que el aparato central reconoce que la línea de datos está siendo impulsada al estado alto por el cliente, puede empezar su secuencia de activación. El cliente puede contar el número de ciclos de reloj generados por el aparato central empezando o durante su proceso de activación. Una vez que el cliente cuenta 70 ciclos de reloj continuos de los datos en el estado alto, puede dejar de impulsar la línea de datos al estado alto. En este punto, el aparato central ya debe estar impulsando la línea de datos al estado alto también. El cliente puede entonces contar otros 80 ciclos de reloj continuos de la línea de datos en el estado alto para alcanzar los 150 ciclos de reloj de la línea de datos en el estado alto, y después puede buscar 50 ciclos de reloj de la línea de datos en el estado bajo. Una vez que se han cumplido estas tres condiciones, el cliente puede empezar a buscar la palabra única. Una ventaja de esta nueva implementación de procesamiento de activación es que elimina la necesidad de un dispositivo de medición de tiempo. Ya sea que éste sea un oscilador, o circuito de descarga de capacitor, u otro dispositivo conocido, el cliente ya no necesita tales dispositivos externos para determinar las condiciones de inicio. Esto ahorra dinero y área de circuito al implementar controladores, contadores y así sucesivamente en una placa de dispositivo de cliente. Aunque esto puede no ser tan favorable para el cliente, para el aparato central, esta técnica debe también simplificar de manera potencial el aparato central en términos de lógica de densidad muy alta (VHDL) usada para la circuitería principal. El consumo de potencia de usar las líneas de datos y de señal de validación como la fuente de notificación y medición de activación, también será más bajo puesto que no será necesario que una circuitería externa opere para que los elementos principales esperen una activación basada en aparato central. El número de ciclos o períodos de reloj usados son ejemplares y se pueden usar otros periodos como será evidente para un experto en la técnica. Una ventaja de esta nueva implementación de procesamiento de activación es que elimina la necesidad de un dispositivo de medición de tiempo. Ya sea que éste sea un oscilador, o circuito de descarga de capacitor, u otro dispositivo conocido, el cliente ya no necesita tales dispositivos externos para determinar las condiciones de inicio. Esto ahorra dinero y área de circuito al implementar controladores, contadores y así sucesivamente en una placa de dispositivo de cliente. Aunque esto puede no ser tan favorable para el cliente, para el aparato central, esta técnica debe también simplificar de manera potencial el aparato central en términos de lógica de densidad muy alta (VHDL) usada para la circuitería principal . El consumo de potencia de usar las líneas de datos y señal de validación como la fuente de notificación y medición de activación, también será más bajo puesto que no será necesario que una circuitería externa opere para que los elementos principales esperen una activación basada en aparato central . Para aclarar e ilustrar la operación de esta nueva técnica, la temporización de MDDI_DatosO, MDDI_Stb, y diversas operaciones relativas a los ciclos de reloj se muestran en las figuras 68A, 68B y 68C. Un ejemplo de los pasos de procesamiento para una típica Activación Iniciada por el Aparato Central sin contienda se ilustra en la figura 68A, donde los eventos son de nuevo etiquetados para conveniencia en la ilustración usando las letras A, B, C, D, E, F y G. El proceso empieza en el punto A cuando el aparato central envía un Paquete de Interrupción de Enlace al aparato cliente para informarle que el enlace cambiará a un estado de hibernación de baja potencia. En un siguiente paso, punto B, el aparato central conmuta MDDI_Stb durante aproximadamente 64 ciclos (o como se desee para el diseño del sistema) para permitir que el procesamiento por parte del cliente sea completado antes de hacer que MDDI_Stb deje de conmutar, lo cual detiene el reloj recuperado en el aparato cliente. Asimismo, el aparato central inicialmente ajusta MDDI_DatosO a un nivel de cero lógico y luego inhabilita la salida de MDDI DatosO en el rango de 16 a 48 ciclos (generalmente incluyendo retardos de propagación de inhabilitación de salida) después del CRC. Puede ser aconsejable colocar receptores de alta velocidad para MDDI_Datos0 y MDDI_Stb en el cliente en un estado de baja potencia algún tiempo después de los 48 ciclos después del CRC y antes de la siguiente etapa (C) . El cliente pone sus receptores de alta velocidad para MDDI_Datos0 y MDDI_Stb en hibernación cualquier tiempo después del flanco de subida del 48° ciclo MDDI_Stb después del CRC del Paquete de Interrupción de Enlace. Se recomienda que el cliente ponga sus receptores de alta velocidad para MDDI_DatosO y MDDI_Stb en hibernación antes del flanco de subida del 64° ciclo MDDI_Stb después del CRC del Paquete de Interrupción de Enlace. El aparato central entra en el estado de hibernación de baja potencia en el punto o paso C, inhabilitando los excitadores de MDDI_DatosO y MDDI_Stb y colocando un controlador de aparato central en un estado de hibernación de baja potencia. Se puede también ajustar el excitador de MDDI_Stb a un nivel de cero lógico (usando una red polarizadora de alta impedancia) o continuar conmutando durante la hibernación, como se desee. El cliente está también en un estado de hibernación de nivel de baja potencia.

Después de algún período de tiempo, el aparato central comienza la secuencia de reinicio de enlace en el punto D, habilitando la salida de excitador de MDDI_DatosO y MDDI_Stb . El aparato central impulsa MDDI_DatosO a un nivel de uno lógico y MDDI_Stb a un nivel de cero lógico durante el tiempo que tome a los excitadores habilitar por completo sus salidas respectivas . El aparato central típicamente espera aproximadamente 200 nanosegundos después de que estas salidas alcanzan los niveles lógicos deseados antes de llevar pulsos en MDDI_Stb. Esto permite al cliente tiempo para prepararse para recibir. Con los excitadores del aparato central habilitados y MDDI_DatosO impulsada a un nivel de uno lógico, el aparato central empieza a conmutar MDDI_Stb durante 150 ciclos MDDI_Stb, como se ve en el punto E. El aparato central impulsa MDDI_Datos0 a un nivel de cero lógico durante 50 ciclos, como se muestra en el punto F, y el cliente empieza a buscar el Paquete de Cabecera de Subcuadro después de que MDDI_DatosO está a un nivel de cero lógico durante 40 ciclos MDDI_Stb. El aparato central empieza a transmitir datos en el enlace hacia adelante enviando un Paquete de Cabecera de Subcuadro, como se muestra en el punto G. Un ejemplo de los pasos de procesamiento para una típica Activación Iniciada por el Cliente sin contienda se ilustra en la figura 68B, donde los eventos son de nuevo etiquetados para conveniencia en la ilustración usando las letras A, B, C, D, E, F, G, H e I. Como antes, el proceso empieza en el punto A cuando el aparato central envía un Paquete de Interrupción de Enlace al aparato cliente para informar al cliente que el enlace cambiará a un estado de baja potencia. En el punto B, el aparato central conmuta MDDI_Stb durante aproximadamente 64 ciclos (o como se desee para el diseño del sistema) para permitir que el procesamiento por parte del cliente sea completado antes de hacer que MDDI_Stb deje de conmutar, lo cual detiene el reloj recuperado en el aparato cliente . Asimismo, el aparato central inicialmente ajusta MDDI_Datos0 a un nivel de cero lógico y luego inhabilita la salida de MDDI_DatosO en el rango de 16 a 48 ciclos (generalmente incluyendo retardos de propagación de inhabilitación de salida) después del CRC. Puede ser aconsejable colocar receptores de alta velocidad para MDDI_DatosO y MDDI_Stb en el cliente en un estado de baja potencia algún tiempo después de los 48 ciclos después del CRC y antes de la siguiente etapa (C) . El aparato central entra en el estado de hibernación de baja potencia en el punto o paso C, inhabilitando los excitadores de MDDI_DatosO y MDDI_Stb y colocando un controlador de aparato central en un estado de hibernación de baja potencia. Uno puede también ajustar el excitador MDDI_Stb a un nivel de cero lógico (usando una red polarizadora de alta impedancia) o continuar conmutando durante la hibernación, como se desee. El cliente está también en un estado de hibernación de nivel de baja potencia. Después de algún período de tiempo, el cliente comienza la secuencia de reinicio de enlace en el punto D, habilitando el receptor de MDDI_Stb, y también habilitando un desplazamiento en el receptor de MDDI_Stb para garantizar que el estado de la versión recibida de MDDI_Stb esté a un nivel de cero lógico en el cliente antes de que el aparato central habilite su excitador de MDDI_Stb. Puede ser aconsejable que el cliente habilite el desplazamiento ligeramente antes de habilitar el receptor para asegurar la recepción de una señal -diferencial válida e inhibir señales erróneas, como se desee. El cliente habilita el excitador de MDDI_DatosO mientras lleva la línea MDDI_DatosO a un nivel de uno lógico. Se permite que MDDI_DatosO y MDDI_Stb sean habilitadas de manera simultánea si el tiempo para habilitar el desplazamiento y habilitar el receptor diferencial de MDDI_Stb. estándar es menor a 100 nseg. En aproximadamente 1 mseg., punto E, el aparato central reconoce el pulso de solicitud de servicio del cliente, y el aparato central empieza la secuencia de reinicio de enlace habilitando las salidas de excitador de MDDI_DatosO y MDDI_Stb. El aparato central impulsa MDDI_DatosO a un nivel de uno lógico y MDDI_Stb a un nivel de cero lógico por el tiempo que tome a los excitadores habilitar sus salidas respectivas. El aparato central típicamente espera aproximadamente 200 nanosegundos después de que estas salidas alcanzan los niveles lógicos deseados antes de llevar pulsos en MDDI_Stb . Esto permite al cliente tiempo para prepararse para recibir. Con los excitadores del aparato central habilitados y MDDI_DatosO siendo impulsada a un nivel de uno lógico, el aparato central empieza a producir pulsos en MDDI_Stb durante 150 ciclos MDDI_Stb, como se ve en el punto F. Cuando el cliente reconoce el primer pulso en MDDI_Stb, inhabilita el desplazamiento en su receptor de MDDI_Stb. El cliente continúa impulsando MDDI_Datos0 a un nivel de uno lógico durante 70 ciclos MDDI_Stb, e inhabilita su excitador de MDDI_DatosO en el punto G. El aparato central continúa impulsando MDDI DatosO a un nivel de uno lógico durante 80 pulsos MDDI_Stb adicionales, y en el punto H impulsa MDDI_DatosO a un nivel de cero lógico. Como se ve en los puntos G y H, el aparato central impulsa MDDI_DatosO a un nivel de cero lógico durante 50 ciclos, y el cliente empieza a buscar el Paquete de Cabecera de Subcuadro después de que MDDI_DatosO está a un nivel de cero lógico durante 40 ciclos MDDI_Stb. Después de impulsar MDDI_Stb por una duración de 50 ciclos, el aparato central empieza a transmitir datos en el enlace hacia adelante enviando un Paquete de Cabecera de Subcuadro, como se muestran él punto I. Un ejemplo de los pasos de procesamiento para una típica Activación Iniciada por el Aparato Central con contienda del cliente, esto es el cliente también quiere- activar el enlace, se ilustra en la figura 68C. Los eventos son de nuevo etiquetados para conveniencia en la ilustración usando las letras A, B, C, D, E, F, G, H e I. Como antes, el proceso empieza en el punto A cuando el aparato central envía un Paquete de Interrupción de Enlace para informar al cliente que el enlace cambiará al estado de baja potencia, continúa al punto B donde MDDI_Stb es conmutada durante aproximadamente 64 ciclos (o como se desee para el diseño del sistema) para permitir que el procesamiento por parte del cliente sea completado, y luego al punto C, donde el aparato central entra en el estado de hibernación de baja potencia, inhabilitando los excitadores de MDDI_DatosO y MDDI_Stb y poniendo un controlador de aparato central en un estado de hibernación de baja potencia. Después de algún período de tiempo, el aparato central comienza la secuencia de reinicio de enlace en el punto D, habilitando la salida de excitador de MDDI_DatosO y MDDI_Stb, y empieza a conmutar 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, aquí punto F, el cliente no ha reconocido aún que el aparato central está impulsando MDDI_Datos0 a un nivel de uno lógico, de modo que el cliente también impulsa MDDI_DatosO a un nivel de uno lógico. Esto ocurre aquí porque el cliente tiene el deseo de solicitar servicio pero no reconoce que el aparato central con el que está tratando de comunicarse ya ha comenzado la secuencia de reinicio de enlace. En el punto G, el cliente deja de impulsar MDDI_DatosO, y pone su excitador en un estado de alta impedancia inhabilitando su salida. El aparato central continúa impulsando MDDI_DatosO a un nivel de uno lógico durante 80 ciclos adicionales. El aparato central impulsa MDDI_DatosO a un nivel de cero lógico durante 50 ciclos, como se muestra en el punto H, y el cliente empieza a buscar el Paquete de Cabecera de Subcuadro después de que MDDI_DatosO está a un nivel de cero lógico durante 40 ciclos MDDI_Stb. El aparato central empieza a transmitir datos en el enlace hacia adelante enviando un Paquete de Cabecera de Subcuadro, como se muestra en el punto I.

VI. Especificaciones eléctricas de interfase En las modalidades de los ejemplos, los Datos en un formato Sin Retorno a Cero (NRZ) son codificados usando un formato de datos-señal de validación o DATOS-STB, el cual permite que información de reloj sea incluida en las señales de datos y de validación. El reloj puede ser recuperado sin circuitería de bucle de realimentación en fase compleja. Los datos son llevados en un enlace diferencial bidireccional, generalmente implementado usando un cable alámbrico, aunque se pueden usar otros conductores, cables impresos o elementos de transferencia, como se mencionó anteriormente. La señal de validación (STB) es llevada en un enlace unidireccional el cual es impulsado solamente por el aparato central. La señal de validación conmuta el valor (0 ó 1) siempre que hay un estado de oposición, 0 ó 1, eso permanece igual en la línea o señal de Datos. Un ejemplo de cómo una secuencia de datos tal como bits "1110001011" se puede transmitir usando codificación DATOS-STB se muestra en forma gráfica en la figura 40. En la figura 40, una señal DATOS 4002 se muestra en la línea superior de una diagrama de temporización de señal y una señal STB 4004 se muestra en una segunda línea, cada tiempo alineado como es apropiado (punto de partida común) . A medida que el tiempo pasa, cuando hay un cambio de estado que ocurre en la línea DATOS 4002 (señal) , entonces la línea STB (señal) 4004 mantiene un estado previo, por ende, el primer estado l' de la señal DATOS se correlaciona con el primer estado ?0' para la señal STB, su valor de partida. Sin embargo, si o cuando el estado, nivel, de la señal DATOS no cambia, entonces la señal STB conmuta al estado opuesto o l' en el presente ejemplo, como es el caso en la figura 40 donde los DATOS están proporcionando otro valor ?l' . Esto es, existe una y solamente una transición por ciclo de bit entre DATOS y STB. Por lo tanto, la señal STB cambia otra vez, esta vez a 0' a medida que la señal DATOS se queda en ?l' y mantiene este nivel o valor a medida que la señal DATOS cambia el nivel a ?0' . Cuando la señal DATOS se queda en ?l', la señal STB conmutar al estado opuesto o ?l' en el presente ejemplo, y así sucesivamente, a medida que la señal DATOS cambia o mantiene niveles o valores . Al recibir esta señales, una operación OR- (XOR-) exclusiva es llevada a cabo en la señales DATOS y STB para producir una señal de reloj 4006, la cual se muestra en la parte inferior del diagrama de temporización para comparación relativa con las señales de datos y de validación deseadas. Un ejemplo de circuitería útil para generar las salidas de DATOS y STB o señales de datos introducidos en el aparato central, y luego a recuperar o volver a capturar los datos de las señales DATA y STB en el cliente, se muestra en la figura 41. En la figura 41, una porción de transmisión 4100 se usa para generar y transmitir las señales DATOS y STB originales en una trayectoria de señal intermedia 4102, mientras que una porción de recepción 4120 se usa para recibir las señales y recuperar los datos . Como se muestra en la figura 41, a fin de transferir datos de un aparato central a un cliente, la señal DATOS es introducida a dos elementos de circuito basculante tipo D 4104 y 4106 junto con una señal de reloj para disparar los circuitos. Las dos salidas de circuito basculante (Q) son luego divididas en un par diferencial de señales MDDI_Datos0+, MDDI_DatosO- y MDDI_Stb+, MDDI_Stb-, respectivamente, usando dos excitadores de línea diferenciales 4108 y 4110 (modo de voltaje) . Una puerta ÑOR- (XNOR-) exclusiva, circuito o elemento lógico de tres entradas 4112 está conectado para recibir los DATOS y salidas de ambos biestables, y genera una salida que provee la entrada de datos para el segundo biestable, que a su vez genera las señales MDDI_Stb+, MDDI_Stb-. Para conveniencia, la puerta XNOR tiene la burbuja de inversión colocada para indicar que efectivamente está invirtiendo la salida Q del biestable que genera la Señal de Validación. En la porción de recepción 4120 de la figura 41, las señales MDDI_DatosO+, MDDI_DatosO- y MDDI_Stb+, MDDI_Stb- son recibidas por cada uno de los dos receptores de línea diferenciales 4122 y 4124, los cuales generan salidas únicas de las señales diferenciales. Las salidas de los amplificadores son luego introducidas a cada una de las entradas de una puerta OR- (XOR-) exclusiva, circuito, o elemento lógico de dos entradas 4126 que produce la señal de reloj . La señal de reloj se usa para disparar cada uno de los dos circuitos basculantes tipo D 4128 y 4130 los cuales reciben una versión retardada de la señal DATOS, a través del elemento de retardo 4132, uno de los cuales (4128) genera valores ?0' de datos y los otros (4130) valores l' de datos. El reloj tiene una salida independiente de la lógica XOR también. Debido a que la información de reloj es distribuida entre las líneas DATOS y STB, ninguna de las dos señales cambia entre estados más rápido que la mitad del índice de reloj . Debido a que el reloj es reproducido usando el procesamiento OR-exclusivo de las señales DATOS y STB, el sistema tolera de manera efectiva dos veces la cantidad de sesgo entre los datos de entrada y reloj en comparación con la situación cuando una señal de reloj es enviada directamente en una sola línea de datos dedicada . Los pares MDDI Datos, señales MDDI_Stb+ y MDDI_Stb-son operados en un modo diferencial para aumentar al máximo la inmunidad de los efectos negativos del ruido. Cada par diferencial tiene terminación en paralelo con la impedancia característica del cable o conductor que se está usando para transferir señales. En general, todas las terminaciones en paralelo residen en el aparato cliente. Esto se encuentra cerca del receptor diferencial para tráfico hacia adelante (datos enviados del aparato central al cliente) , pero está en el extremo excitador del cable u otros conductores o elementos de transferencia para tráfico inverso (datos enviados del cliente al aparato central) . Para tráfico inverso la señal es impulsada por el cliente, reflejada por el receptor de alta impedancia en el aparato central y es terminada en el cliente. Esto evita la necesidad de una terminación doble que incrementaría el consumo de corriente. Igualmente, funciona como índices de datos superiores al valor recíproco del retardo de ida y vuelta en el cable. Los conductores o señales MDDI_Stb+ y MDDI_Stb- son solamente impulsados por el aparato central . Una configuración ejemplar de elementos útiles para obtener los excitadores, receptores y terminaciones para transferir señales como parte de la interfase MDD inventiva se muestra en la figura 42. Esta interfase ejemplar usa detección de bajo voltaje, aquí 200 mV, con variaciones de la potencia menores a 1 volt y drenaje de potencia bajo. El excitador de cada par de señales tiene una salida de corriente diferencial. Mientras reciben paquetes MDD1 los pares MDDI_Datos y MDDI_Stb usan un receptor diferencial convencional con un umbral de voltaje de cero volts. En el estado de hibernación las salidas de excitador son inhabilitadas y los resistores con terminación en paralelo llevan el voltaje en cada par de señales a cero volts. Durante la hibernación un receptor especial en el par MDDI_Datos tiene un umbral de entrada de desplazamiento de 125 mV positivos, lo cual ocasiona que el receptor de línea de hibernación interprete el par de señales no impulsadas como un nivel de cero lógico. Algunas veces el aparato central o cliente impulsan de manera simultánea el par diferencial a un nivel de uno lógico o 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 (del aparato central al cliente o cliente al aparato central) . El rango de voltaje de salida y especificaciones de salida se cumplen aún con salidas impulsadas de manera simultánea impulsadas al mismo nivel lógico. En algunos sistemas puede ser necesario llevar una corriente pequeña en el par diferencial terminado para crear un voltaje de desplazamiento pequeño en ciertos momentos durante la hibernación y cuando el enlace está despertando del estado de hibernación. En esas situaciones, los circuitos de polarización de corriente de desnivel impulsan los niveles actuales llamados : IESD-Y-RX _ diodo ESD interno y entrada de receptor diferencial con IESD-Y-Rx = 1 µA típicamente; ITX-HÍ-Z _ salida de excitador diferencial en el estado de alta impedancia, con ITX-HÍ-Z = 1 µA típicamente; y lESD-extemo - la fuga a través de los diodos de protección ESD externo, con IEsD-e?terno = 3 µA típicamente.

Cada una de estas corrientes de fugas se ilustra en la figura 101. Los circuitos elevador de voltaje y reductor de voltaje deben lograr el voltaje diferencial mínimo bajo el peor caso de condiciones de fugas antes descritas cuando todo ocurre de manera simultánea. La fuga total es = 4 µA para modo interno sin diodo de protección de ESD externo y = 10 µA para modo externo con protección de ESD externo. Los parámetros eléctricos y características de los excitadores de línea y receptores de línea diferenciales se describen para una modalidad ejemplar en los cuadros VlIa-VIId. De manera funcional, el excitador transfiere el nivel lógico en la entrada directamente a una salida positiva, y la inversa de la entrada a una salida negativa. El retardo de entrada a salidas coincide con la línea diferencial que es impulsada en forma diferencial . En la mayor parte de las implementaciones, la oscilación de voltaje en las salidas es menor a la oscilación en la entrada para reducir al mínimo el consumo de potencia y emisiones electromagnéticas. En una modalidad hay una oscilación de voltaje mínima de aproximadamente 0.5 V. Sin embargo, se pueden usar otros valores, como sería conocido por los expertos de la técnica, y los inventores contemplan un valor más pequeño en algunas modalidades, dependiendo de las limitaciones del diseño . Los receptores de línea diferenciales tienen las mismas características que el comparado de voltaje de alta velocidad. En la figura 41, la entrada sin la burbuja es la entrada positiva y la entrada con la burbuja es la entrada negativa. La salida es un uno lógico si: (VentradaX) - (Ventrada-) es superior a cero.

Otra manera de describir esto es un amplificador diferencial con ganancia muy grande (virtualmente infinita) con la salida recortada a niveles de voltaje 0 y 1 lógicos . El sesgo de retardo entre diferentes pares se debe reducir al mínimo para operar el sistema de transmisión diferencial a la velocidad potencial más alta. Cuadro VIIa Especificaciones eléctricas de transmisor de aparato central Nota 1: El tiempo de subida y bajada máximo es ya sea 40% del intervalo para transmitir un bit en un par diferencial o 100 nseg, el que sea más pequeño.

Cuadro VIIb Especificaciones eléctricas de transmisor de cliente Nota 1: El tiempo de subida y bajada máximo es 40% del intervalo para transmitir un bit en un par diferencial o 100 nseg, el que sea más pequeño.

Cuadro VIIc Especificaciones eléctricas de receptor de cliente Cuadro VIId Especificaciones eléctricas de receptor de aparato central En la figura 42, un controlador de aparato central 4202 y un controlador de cliente o pantalla 4204 se muestran transfiriendo paquetes en el enlace de comunicación 4206. El controlador de aparato central emplea una serie de tres excitadores 4210, 4212 y 4214 para recibir las señales DATOS y STB de aparato central que se van a transferir, así como para recibir las señales de Datos de cliente que se van a transferir, mientras el cliente emplea los tres excitadores 4230, 4232 y 4234. El excitador responsable del paso de DATOS de aparato central (4212) emplea una entrada de señal de habilitación para permitir la activación del enlace comunicación generalmente sólo cuando se desea la transferencia del aparato central al cliente. Debido a que la señal STB se forma como parte de la transferencia de datos, no se emplea señal de habilitación adicional alguna para ese excitador (4212) . Las entradas de cada uno de los receptores de DATOS y STB de cliente (4132, 4230) tienen impedancias o resistores de terminación 4218 y 4220, respectivamente recorridos a través de ellos . El excitador 4234 en el controlador de cliente se usa para preparar las señales de datos que son transferidas del cliente al aparato central, donde el excitador 4214 en el lado de entrada, procesan los datos. Los receptores (excitadores) especiales 4216 y 4236 están acoplados o conectados a las líneas DATOS, y generan o usan el desplazamiento de voltaje de 125 mV discutido anteriormente, como parte del control de hibernación discutido en otra parte. Los desplazamientos ocasionan que los receptores de línea de hibernación interpreten pares de señales no impulsadas como un nivel de cero lógico. Los excitadores e impedancias anteriores se pueden formar como componentes discretos o como parte de un módulo de circuito, o un circuito integrado específico de aplicación (ASIC) el cual actúa como una solución de codificador o decodificador más efectiva en costos. Se puede ver fácilmente que la potencia es transferida al aparato cliente, o pantalla, desde el aparato central usando las señales etiquetadas HOST_Pwr y HOST_Gnd en un par de conductores . La porción HOST_Gnd de la señal actúa como la tierra de referencia y trayectoria de retorno de suministro de potencia o señal para el aparato, cliente. La señal HOST_Pwr actúa como el suministro de potencia del aparato cliente el cual es impulsado por el aparato central. En una configuración ejemplar, para aplicaciones de potencia baja, se le permite al aparato cliente extraer hasta 500 mA. La señal HOST_Pwr se puede proveer de fuentes de potencia portátiles, tales como mas no limitado a, batería de iones de litio o paquete de baterías que reside en el aparato central, y puede variar de 3.2 a 4.3 volts con respecto a HOST_Gnd.

VII. Características de temporización A. Visión General Los pasos y niveles de señales empleados para entrar en un estado de hibernación (no se solicita, desea o requiere servicio) y para asegurar servicio para un cliente desde el aparato central, ya sea por iniciación del aparato central o iniciación del cliente, se ilustran en las figuras 43a, 43b y 43c, respectivamente. En las figuras figuras 43a, 43b y 43c, la primera parte de las señales que' se ilustran muestra un Paquete de Interrupción de Enlace siendo transferido del aparato central y la línea de datos es después impulsada a un estado de cero lógico usando el circuito de polarización de alta impedancia. El cliente, o aparato central, el cual tiene su excitador inhabilitado, no transmiten datos. Una serie de pulsos de señal de validación para la línea de señal MDDI_Stb se puede ver en la parte inferior, puesto que MDDI_Stb está activa durante el Paquete de Interrupción de Enlace. Una vez que este paquete termina, el nivel lógico cambia a cero a medida que el aparato central impulsa el circuito de polarización y lógica a cero. Esto representa la terminación de la última transferencia de señal o servicio del aparato central, y podría haber ocurrido en cualquier momento en el pasado, y se incluye para mostrar el término anterior de servicio, y el estado de las señales antes del inicio del servicio. Si se desea, tal señal puede ser enviada solamente para reiniciar el enlace de comunicación al estado apropiado sin que una comunicación anterior ?conocida' haya sido llevada a cabo por este aparato central. Como se muestra en la figura 43a, y se discute para el Paquete de Interrupción de Enlace anterior, en el estado de hibernación de baja potencia, el excitador de MDDI_DatosO es inhabilitado en un estado de alta impedancia empezando después del 16° al 48° ciclos o pulsos después del último bit del campo Todos Ceros en el Paquete de Interrupción de Enlace . Para enlaces Tipo 2, Tipo 3 o Tipo 4, las señales MDDI_Datosl a MDDI_DatosPwr7 son puestas también en un estado de alta impedancia al mismo tiempo que el excitador de MDDI_DatosO es inhabilitado. Como se describe en la definición del campo Todos Ceros, MDDI_Stb conmuta durante 64 ciclos (o como se desee para el diseño del sistema) siguiendo el MSB del campo de CRC del Paquete de Interrupción de Enlace para permitir que el procesamiento por parte del cliente sea completado y facilitar una interrupción ordenada en un controlador de cliente. Un ciclo es una transición baja-a-alta seguida de una transición alta-a-baja, o una transición alta-a-baja seguida de una transición baja-a-alta. Después de que el campo de Todo Ceros es enviado, los excitadores de MDDI_Stb y MDDI_DatosO en el aparato central son inhabilitados, y el aparato central entra en el estado de hibernación de baja potencia. Después de algún tiempo, el aparato central comienza la secuencia de reinicio de enlace como se muestra en las figuras 43b y 43c, habilitando las líneas MDDI_DatosO y MDDI_Stb o salidas de excitador, y empieza a conmutar MDDI_Stb, como parte ya sea de una solicitud de activación iniciada por el aparato central o una solicitud de activación iniciada por el cliente. Como se muestra en la figura 43b, después de que pasa un tiempo con la salida de señal de los excitadores para MDDI_DatosO y MDDI_Stb inhabilitada, un aparato central inicia servicio o activación tras la hibernación habilitando su excitador de MDDI_Stb durante un periodo de tiempo designado tstb-dagta-enbi? durante el cual la línea es impulsada a un nivel de cero lógico, hasta que esté completamente habilitada y después habilitando su excitador de MDDI_DatosO. El aparato central mantiene MDDI_Stb a un nivel de cero lógico después de que MDDI_DatosO alcanza un nivel alto o un nivel de uno lógico lo cual ocurre en un periodo de tiempo designado tciiente-inicio • Al final del período de tdiente-inicio/ el aparato central conmuta luego la señal o línea MDDI_Stb. El aparato central impulsa la línea MDDI_DatosO a un estado alto, un nivel de uno lógico, mientras el cliente no impulsa MDDI_DatosO, durante un periodo designado treinicxo-aito/- y luego impulsa la línea MDDI_DatosO a un estado bajo, o a nivel de cero lógico, durante un periodo designado treinicio-bajo- Después de esto, el primer tráfico hacia adelante empieza con un Paquete - de Cabecera de Subcuadro, y los paquetes de tráfico hacia adelante son entonces transferidos. La señal MDDI_Stb está activa durante el periodo treinicio-ajo y el Paquete de Cabecera de Subcuadro subsiguiente. Como se muestra en la figura 43c, después de gue pasa un tiempo con la salida de señal de los excitadores para MDDI_DatosO y MDDI_Stb inhabilitada, un cliente inicia una solicitud de servicio o activación tras la hibernación habilitando un desplazamiento en el receptor de MDDI_Stb o señal de salida durante un periodo de tiempo designado tstb-dagta-e hir como se discute antes, antes de que el aparato central habilite su excitador de MDDI_Stb. El cliente después habilita su excitador de MDDI_DatosO durante un periodo de tiempo designado taparato centrai-detectr durante el cual la línea es impulsada a un nivel de cero lógico, antes de que el aparato central empiece la conmutación de MDDI_Stb. Cierta cantidad de tiempo pasa o se puede necesitar antes de que el aparato central detecte la solicitud durante taparato centrai-detect, después del cual el aparato central responde manteniendo MDDI_Stb a nivel de cero lógico durante el periodo designado tstb-ipicio? antes de que el aparato central empiece a conmutar MDDI_Stb con una secuencia de inicio de enlace impulsando la MDDI_Datos0 a un nivel de uno lógico o alto durante el periodo tre?nicio-aito • Cuando el cliente reconoce el primer pulso en MDDI_Stb inhabilita el desplazamiento en su receptor de MDDI_Stb . El cliente continúa llevando MDDI_Datos0 a un nivel de uno lógico o un periodo designado tciiente-detect hasta que detecta el aparato central que impulsa la línea. En este punto, el cliente des-afirma la solicitud, e inhabilita su excitador de MDDI_DatosO de manera que la salida del cliente vaya al nivel de cero lógico de nuevo, y el aparato central está impulsando MDDI_DatosO. Como antes, el aparato central continúa llevando MDDI_DatosO a un nivel de uno lógico durante el periodo treinicio-aitoj y luego impulsa la línea MDDI_DatosO al estado bajo durante el periodo treinicio-ajor después del cual el primer tráfico hacia adelante empieza con un Paquete de Cabecera de Subcuadro. La señal MDDI_Stb está activa durante el periodo treiniCi0-bajo y el Paquete de Cabecera de Subcuadro subsiguiente . El cuadro VIII muestra tiempos o periodos de procesamiento representativos para la duración de los diversos periodos antes discutidos, y la relación con índices de datos mínimo y máximo ej emplares , donde : 1 , donde índice de Datoss d dee E Ennllaaccee Indice_de_Datos_de_Enlace es el índice de bit de un solo par de datos Cuadro VIII Los expertos en la técnica comprenderá fácilmente que las funciones de los elementos individuales ilustrados que las figuras 41 y 42 son bien conocidas, y la función de los elementos en la figura 42 está confirmada por el diagrama de temporización en las figuras 43a, 43b y 43c. Detalles acerca de las terminaciones en serie y resistores de hibernación que se muestran en la figura 42 fueron omitidos de la figura 41 porque esa información no es necesaria para una descripción de cómo realizar la codificación de Datos-Señal de Validación y recuperar el reloj de ella.

B. Enlace hacia adelante de temporización de datos-señal de validación Las características de conmutación para la transferencia de datos en el enlace hacia adelante de la salida de excitador de aparato central se muestran en el cuadro IX. El cuadro IX representa una forma tabular del mínimo y máximo deseado, contra tiempos típicos para que ocurran ciertas transiciones de señal. Por ejemplo, el lapso típico de tiempo para que ocurra una transición del inicio al fin de un valor de datos (salida de un ?0' o l' ) , una transición de DatosO a DatosO, llamada ttdd~ (aparato central-salida), es ttbit-mientras que el tiempo mínimo es aproximadamente ttbit - 0.5 nseg, y el máximo es aproximadamente ttbit + 0.5 nseg. La separación relativa entre las transiciones en DatosO, otras líneas de datos (DatosX) , y las líneas de señal de validación (Stb) , se ilustra en la figura 44 donde se muestran las transiciones DatosO a Señal de Validación, Señal de Validación a Señal del Validación, Señal de Validación a DatosO, DatosO a no DatosO, no DatosO a no DatosO, no DatosO a Señal de Validación, y Señal de Validación a no DatosO, las cuales son llamadas ttds- (aparato central-salida) /' ttss- (aparato central-salida) r ttsd- (aparato central-salida) r ttddx- (aparato central-salida) r ttdxdx- (aparato central-salida) / ttdxs- (aparato central-salida) r Y ttsdx- (aparato central- salida) r respectivamente .

Cuadro IX Los requerimientos de temporización de MDDI típicos para la entrada de receptor de cliente para las mismas señales que transfieren datos en el enlace hacia adelante se muestran en el cuadro X. Debido a que se discuten las mismas señales pero con retardo de tiempo, no se necesita una figura nueva para ilustrar las características de señal o el significado de las etiquetas respectivas, como entendería el experto en la técnica.

Cuadro X Las figuras 45 y 46 ilustran la presencia de un retardo en respuesta que puede ocurrir cuando el aparato central inhabilita o habilita el excitador de aparato central, respectivamente. En el caso de un aparato central que reenvía ciertos paquetes, tales como el Paquete de Encapsulación de Enalce Inverso o el Paquete de Medición de Retardo de Ida y Vuelta, el aparato central inhabilita el excitador de línea después de que los paquetes deseados son reenviados, tales como los paquetes CRC de Parámetro, Alineación de Señal de Validación y Todo Cero ilustrados en la figura 45 como que han sido transferidos. Sin embargo, como se muestra en la figura 45, el estado de la línea no cambia necesariamente de ?0' a un valor más alto deseado de manera instantánea, aunque esto se puede lograr de manera potencial con ciertos elementos de control o de circuito presentes, pero toma un periodo de tiempo, llamado el periodo de Retardo de Inhabilitación de Excitador, responder. Aunque podría ocurrir virtualmente de manera instantánea que este periodo de tiempo tenga 0 nanosegundos (nseg.) de duración, se podría extender más fácilmente en un periodo más largo siendo 10 nseg una duración de periodo máxima deseada, lo que ocurre durante los periodos de paquete Tiempo de Guarda 1 o Inversión de Sentido 1. Viendo en la figura 46, se ve el cambio de nivel de señal experimentado cuando el Excitador de aparato central es habilitado para transferir un paquete tal como el Paquete de Encapsulación de Enalce Inverso o el Paquete de Medición de Retardo de Ida y Vuelta. Aquí, después de los periodos de paquete Tiempo de Guarda 2 o Inversión de Sentido 2, el excitador de aparato central en habilitado y comienza a impulsar un nivel, aquí ?0', a cuyo valor se aproxima o es alcanzado en un periodo de tiempo llamado el periodo de Retardo de Habilitación de Excitador de Aparato Central, que ocurre durante el periodo de Rehabilitación de Excitador, antes de que el primer paquete sea enviado. Un proceso similar ocurre para los excitadores y transferencias de señal para el aparato cliente, aquí una pantalla. Los lineamientos generales para la duración de estos periodos y sus relaciones respectivas se muestran en el Cuadro XI, a continuación.

Cuadro XI C. Enlace inverso de temporización de datos-señal de validación Las características de conmutación y relaciones de temporización para las señales de datos y de validación usadas para transferir datos en el enlace inverso desde la salida de excitador de cliente se muestran en las figuras 47 y 48. Los tiempos típicos para ciertas transiciones de señal se discuten más adelante. La figura 47 ilustra la relación en la entrada de receptor de aparato central entre la temporización de los datos que están siendo transferidos y los flancos anterior y posterior de los pulsos de señal revalidación. Esto es, lo que es llamado el tiempo de establecimiento para el flanco de subida o anterior de las señales de validación, tsu-sr y el tiempo de establecimiento para el flanco posterior o de bajada de las señales de validación, tsu-Sf. Una duración típica de tiempo para estos periodos de establecimiento está en el orden de un mínimo de 8 nanosegundos . La figura 48 ilustra las características de conmutación y retardo de salida de cliente correspondiente desarrollados por la temporización de datos inversos. En la figura 48, se puede ver la relación entre la temporización de los datos que están siendo transferidos y los flancos anterior y posterior de los pulsos de señal de validación que explican el retardo inducido. Esto es, lo que es llamado el retardo de propagación entre los flancos de subida o anterior de las señales de validación y los datos (válidos) , tpd_ sr, y el retardo de propagación entre los datos y el flanco posterior o de bajada de las señales de validación, tpd_Sf. Una duración de tiempo máxima típica para estos periodos de retardo de propagación está en el orden de 8 nanosegundos .

VIII . Implementación de control de enlace (operación de controlador de enlace) A. Procesador de paquete de máquina de estados Los paquetes que están siendo transferidos en un enlace de MDDI son despachados muy rápidamente, típicamente a un índice en el orden de 300 Mbps o más, tal como 400 Mbps, aunque ciertamente se admiten índices más bajos, como se desee. Este tipo de velocidad de bus o enlace de transferencia es demasiado grande para ser controlada por los microprocesadores de propósito general comercialmente disponibles (económicos) en la actualidad o similares. Por lo tanto, una implementación práctica para lograr este tipo de transferencia de señal es utilizar una máquina de estados programable para analizar sintácticamente el flujo de paquete de entrada para producir paquetes que son transferidos o redirigidos al subsistema audiovisual apropiado para el cual están destinados . Tales dispositivos son bien conocidos y usan circuitos generalmente dedicados a un número limitado de operaciones, funciones o estados para lograr una operación a alta velocidad o a muy alta velocidad deseada.

Controladores, procesadores, o elementos de procesamiento de propósito general, se pueden usar para tratar o manipular en forma más apropiada alguna información tal como paquetes de control o estado, los cuales tienen demandas de velocidad más baja. Cuando esos paquetes (paquetes de control, estado u otros paquetes definidos previamente) son recibidos, la máquina de estados los debe pasar a través de una memoria intermedia de datos o elemento de procesamiento similar al procesador de propósito general de manera que los paquetes puedan ser tratados para proveer un resultado (efectos) deseado mientras los paquetes de audio y visuales son transferidos a su destino apropiado para acción. Si microprocesadores u otros controladores, procesadores, o elementos de procesamiento de propósito general futuros se fabrican para lograr capacidades de procesamiento de índice de datos más alto, entonces los estados o máquina de estados que se discuten más adelante se pudieran también implementar usando control de software de tales dispositivos, típicamente como programas almacenados en un elemento o medios de almacenamiento . La función del procesador de propósito general se puede realizar en algunas modalidades aprovechando la potencia de procesamiento, o ciclos excesivos disponibles para, microprocesadores (CPUs) en aplicaciones de computadora, o controladores, procesadores, procesadores de señales digitales (DSPs) , circuitos especializados o ASICs encontrados en aparatos inalámbricos, mucho en la misma manera en que algunos módems o procesadores de gráficos utilizan la potencia de procesamiento de CPUs encontrados en computadoras para llevar a cabo algunas funciones y reducir la complejidad y costos de hardware. No obstante, esta compartición o utilización de ciclo puede tener un impacto negativo en la velocidad de procesamiento, temporización u operación general de tales elementos, de manera que en muchas aplicaciones, se prefieren circuitos o elementos dedicados para este procesamiento general. A fin de que los datos de imagen sean visualizados en una pantalla (micropantalla) , o recibir de manera confiable todos los paquetes enviados por el aparato central, el procesamiento de señal de cliente es sincronizado con la temporización de canal de enlace hacia adelante. Esto es, las señales que llegan al cliente y los circuitos de cliente necesitan ser sincronizadas con el tiempo de manera sustancial para que ocurra un procesamiento de señal apropiado. Un diagrama de alto nivel de estados logrados por la señal para una modalidad se presenta en la ilustración de la figura 49. En la figura 49, los posibles "estados" de sincronización de enlace hacia adelante para una máquina de estados 4900 se muestran clasificados como un ESTADO DE CUADROS ASINC 4904, dos ESTADOS DE ADQUISICIÓN DE SINC 4902 y 4906, y tres ESTADOS EN-SINC 4908, 4910 y 4912. Como se muestra mediante el paso o estado de inicio 4902, la pantalla o cliente, tal como un dispositivo de presentación, inicia en un estado "no sinc" seleccionado previamente para una palabra única en el primer paquete de cabecera de subcuadro que es detectado. Cabe mencionar que este estado no sinc representa el ajuste de comunicación mínimo o ajuste "de retroceso" en el cual se selecciona una interfase de Tipo 1. Cuando la palabra única es encontrada durante la búsqueda, el cliente guarda el campo de longitud de subcuadro. No hay verificación de los bits de CRC para procesamiento en el primer cuadro, o hasta que se obtiene la sincronización. Si la longitud de este subcuadro es cero, entonces el procesamiento del estado sinc continúa como corresponde a un estado 4904 etiquetado aquí como el estado de "cuadros asinc", el cual indica que la sincronización no ha sido lograda aún. Se designa este paso en el procesamiento como que ha encontrado la cond 3, o condición 3, en la figura 49. De otro modo, si la longitud del cuadro es mayor a cero, entonces el procesamiento de estado sinc continúa a un estado 4906 donde el estado de interfase se establece como "encontró un cuadro sinc" . Se designa este paso en el procesamiento como que encuentra la cond 5, o condición 5, en la figura 49. Además, si la máquina de estados ve un paquete de cabecera de cuadro y buena determinación de CRC para una longitud de cuadro mayor a cero, el procesamiento continúa al estado "encontró un cuadro sinc". Esto se designa como cumplir con la cond 6, o condición 6, en la figura 49. En cada situación en la cual el sistema se encuentra en un estado que no sea "no sinc", si se detecta un paquete con un buen resultado de CRC, entonces el estado de interfase es cambiado al estado "en-sinc" 4908. Este paso en el procesamiento es designado como que ha encontrado la cond 1, o condición 1, en la figura 49. Por otra parte, si el CRC en cualquier paquete no es correcto, entonces el procesamiento de estado sinc continúa o regresa al estado de interfase 4902 de estado "CUADRO NO SINC". Esta porción del procesamiento es designada como que ha encontrado la cond 2, o condición 2, en el diagrama de estados de la figura 49.

B. Tiempo de adquisición para sincronización La interfase se puede configurar para admitir cierto número de "errores de sincronización" antes de decidir que se ha perdido la sincronización y regresar al estado de "CUADRO NO SINC". En la figura 49, una vez que la máquina de estados ha alcanzado el "ESTADO EN-SINC" y no se encuentran errores, está encontrando de manera continua un resultado de cond 1, y permanece en el estado "EN-SINC". Sin embargo, una vez que se detecta un resultado de cond 2, el procesamiento cambia el estado a un estado "un error de sincronización" 4910. En este punto, si el procesamiento da por resultado la detección de otro resultado de cond 1, entonces la máquina de estados vuelve al estado "en-sinc", de otra manera encuentra otro resultado de cond 2 y se mueve el estado "DOS-ERRORES-DE-SINCRONIZACIÓN" 4912. De nuevo, si ocurre una cond 1, el procesamiento regresa la máquina de estados al estado "EN-SIC" . De otra manera, otra cond 2 es encontrada y la máquina de estados vuelve al estado "no-sinc". Es comprensible también que si la interfase encuentra un "paquete de interrupción de enlace", entonces esto ocasionará que el enlace termine la transferencia de datos y regrese al estado "cuadro no-sinc" puesto que ya no hay nada con que sincronizar, lo cual se llama cumplir la cond 4, o condición 4, en el diagrama de estados de la figura 49. Se entiende que es posible que haya una "copia falsa" repetida de la palabra única que puede aparecer en algún lugar fijo dentro del subcuadro. En esa situación, no es probable que la máquina de estados se sincronice con el subcuadro porque el CRC del Paquete de Cabecera de subcuadro debe ser también válido cuando es procesado a fin de que el procesamiento de interfase MDD continúe al estado "EN SINC". La longitud de subcuadro en el Paquete de Cabecera de subcuadro se puede ajustar a cero para indicar que el aparato central transmitirá solamente un subcuadro antes de que el enlace sea interrumpido, y la interfase MDD se pone en o se configura en un estado de hibernación de inactividad. En este caso, el cliente debe inmediatamente recibir paquetes en el enlace hacia adelante después de detectar el Paquete de Cabecera de subcuadro porque solamente un solo subcuadro es enviado antes de que el enlace cambie al estado inactivo. En operaciones normales o típicas, la longitud de subcuadro es no cero y el cliente únicamente procesa paquetes de enlace hacia adelante mientras la interface se encuentra en esos estados mostrados de manera colectiva como estados "EN-SINC" en la figura 49.

Un aparato cliente de modo externo se puede unir al aparato central mientras el aparato central ya está transmitiendo una secuencia de datos de enlace hacia adelante. En esta situación, el cliente se debe sincronizar con el aparato central. El tiempo requerido para que un cliente se sincronice con la señal de enlace hacia adelante es variable dependiendo del tamaño del subcuadro y el índice de datos de enlace hacia adelante. La probabilidad de detectar una "copia falsa" de la palabra única como parte de los datos aleatorios, o más aleatorios, en el enlace hacia adelante es mayor cuando el tamaño del subcuadro es más grande. Al mismo tiempo, la capacidad de recuperarse de una detección falsa es más baja, y el tiempo que toma hacerlo es más largo, cuando un índice de datos de enlace hacia adelante es más lento. Para una o más modalidades, se recomienda o se entiende que un aparato central MDDI debe realizar ciertos pasos adicionales para asegurarse de que el enlace inverso de MDDI es estable antes de detener la transmisión del enlace hacia adelante para ir a un modo de potencia baja o interrumpir el enlace por completo.

Un problema que puede ocurrir es que si un aparato central utiliza una medición incorrecta del valor de retardo de ida y vuelta, esto puede ocasionar que toda la transmisión de datos inversa recibida posteriormente del cliente falle aun cuando el enlace hacia adelante parezca estar bien. Esto podría pasar si el aparato central intenta enviar un Paquete de Medición de Retardo de Ida y Vuelta cuando el cliente no está en sincronización con el enlace hacia adelante, o debido a un cambio extremo en la temperatura ambiente que causa un cambio grande correspondiente en el retardo de propagación de los excitadores y receptores diferenciales que afecta el retardo de ida y vuelta. Una falla de contacto del cable o conector intermitente podría causar también que el cliente pierda en forma temporal sincronización y luego recupere sincronización, tiempo durante el cual, puede pasar por alto recibir un Paquete de Medición de Retardo de Ida y Vuelta. Los paquetes de enlace inverso subsiguientes no deben ser capaces de ser decodificados en forma apropiada por el aparato central . Otro tipo de problema que puede ocurrir es que el cliente pierda de manera temporal sincronización y el aparato central envíe un Paquete de Interrupción de Enlace antes de que el cliente sea capaz de recuperar sincronización. El aparato central estará en hibernación mientras el cliente es incapaz de entrar en el estado de hibernación porque no recibió el Paquete de Interrupción de Enlace y no tiene un reloj porque el enlace está en hibernación. Una técnica modalidad útil para superar tales problemas es hacer que el aparato central asegure que el cliente esté en sincronización con el enlace hacia adelante antes de poner el enlace en el estado de hibernación. Si el aparato central MDDI es incapaz de hacer esto o no tiene tal oportunidad, como por ejemplo, cuando pierde potencia o el enlace es roto en forma abrupta o falla debido a una separación de cable, conductor o conector, ruptura o desconexión que ocurre durante la operación, entonces el aparato central debe intentar primero asegurar que el cliente esté en sincronización antes de empezar un proceso de medición de retardo de ida y vuelta o enviar un paquete de Encapsulación de Enlace Inverso. Un aparato central puede observar el campo de Conteo de Errores de CRC en un paquete de Solicitud y Estado de Cliente enviado por el cliente para determinar la integridad del enlace hacia adelante . Este paquete es solicitado por el aparato central desde el cliente. Sin embargo, en caso de una falla o ruptura de enlace principal, es muy probable que esta solicitud quede sin respuesta porque un cliente no será capaz de decodificar de manera apropiada el paquete, o quizá incluso recibirlo por completo. La solicitud del Conteo de Errores de CRC usando el Paquete de Solicitud y Estado de Cliente enviado en un Paquete de Encapsulación de Enlace Inverso actúa como una primera comprobación de integridad, una especie de primera línea de defensa. Además, un aparato central puede enviar un Paquete de Medición de Retardo de Ida y Vuelta para confirmar si la suposición de que el cliente se encuentra fuera de sincronización es o no válida. Si el cliente no responde a un Paquete de Medición de Retardo de Ida y Vuelta, el aparato central concluirá que el cliente se encuentra fuera de sincronización y puede iniciar el proceso de ponerlo otra vez en sincronización. Una vez que el aparato central concluye que es muy probable que el cliente haya perdido sincronización con el enlace hacia adelante, espera hasta la siguiente cabecera de subcuadro antes de intentar enviar cualesquier paquetes que no sean paquetes de relleno. Esto se hace a fin de permitir a un cliente tiempo suficiente para detectar o buscar una palabra única contenida en el paquete de cabecera de subcuadro. Después de esto, el aparato central puede asumir que el cliente se habría reiniciado a sí mismo puesto que no habría encontrado la palabra única en el lugar correcto. En este punto, el aparato central puede seguir el paquete de cabecera de subcuadro con un Paquete de Medición de Retardo de Ida y Vuelta. Si el cliente a uno responde correctamente al Paquete de Medición de Retardo de Ida y Vuelta, el aparato central puede repetir el proceso de resincronización. Una respuesta correcta es una en la cual el cliente envía la secuencia especificada de vuelta al aparato central en el Periodo de Medición del Paquete de Medición de Retardo de Ida y Vuelta. Si esta secuencia no es recibida, entonces los intentos de recibir datos inversos en un Paquete de Encapsulación de Enlace Inverso fallarán. Falla continua de esta naturaleza puede indicar algún error del sistema que tendrá que ser abordado de alguna otra manera, y no es parte de la sincronización de enlace en este punto. No obstante, si después de un Paquete de Medición de Retardo de Ida y Vuelta exitoso el aparato central todavía ve datos corruptos o no ve respuesta en los Paquetes de Encapsulación de Enlace Inverso, debe confirmar si el muestreo de datos inversos es correcto volviendo enviar un Paquete de Medición de Retardo de Ida y Vuelta. Si esto no tiene éxito después de un número de intentos, se recomienda para una modalidad que el aparato central reduzca el índice de datos inversos incrementando el valor del divisor de índice inverso . El aparato central debe realizar los pasos de Detección de Falla de Enlace y Resincronización de Enlace antes descritos antes de poner el enlace de MDDI en el estado de hibernación. En general esto asegurará que el Paquete de Medición de Retardo de Ida y Vuelta realizado cuando el enlace es reiniciado más tarde sea exitoso. Si el aparato central no tiene razón para sospechar de una falla de enlace, y una respuesta correcta a un Paquete de Encapsulación de Enlace Inverso y cero errores de CRC de enlace hacia adelante están siendo reportados por el cliente, un aparato central puede suponer que todo está operando o funcionando como corresponde o de manera apropiada (no hay falla de enlace, por ejemplo) y continuar con el proceso de potencia reducida/hibernación. Otra manera en la cual un aparato central puede hacer una prueba para ver si hay sincronización es que el aparato central envíe el Paquete de Medición de Retardo de Ida y Vuelta y confirme la respuesta apropiada del cliente. Si la respuesta apropiada es recibida por el aparato central, se puede suponer de manera razonable que el cliente está interpretando con éxito los paquetes de enlace hacia adelante.

C. Inicialización Como se mencionó anteriormente, en el tiempo del "inicio", el aparato central configura el enlace hacia adelante para operar a o por debajo de un índice de datos requerido, o deseado mínimo, de 1 Mbps, y configura la longitud de subcuadro e índice de cuadro de medios en forma apropiada para una aplicación dada. Esto es, tanto el enlace hacia adelante como el enlace inverso empiezan la operación usando la interfase Tipo 1. Estos parámetros en general solamente se van a usar en forma temporal mientras el aparato central determina la capacidad o configuración deseada para la pantalla cliente (u otro tipo de aparato cliente) . El aparato central envía o transfiere un Paquete de Cabecera de subcuadro en el enlace hacia adelante seguido de un Paquete de Encapsulación de Enlace Inverso que tiene el bit ?0' de las Banderas de Solicitud ajustado a un valor de uno (1) , a fin de solicitar que la pantalla o cliente responda con un Paquete de Capacidad del Cliente. Una vez que la pantalla adquiere sincronización en (o con) el enlace hacia adelante, envía un Paquete de Capacidad del Cliente y un Paquete de Solicitud y Estado de Cliente en el enlace o canal inverso . El aparato central examina el contenido del Paquete de Capacidad del Cliente a fin de determinar cómo reconfigurar el enlace para un nivel de rendimiento óptimo o deseado. El aparato central examina los campos de Versión de Protocolo y Versión de Protocolo Mínima para confirmar que el aparato central y el cliente usan versiones del protocolo que son compatibles entre sí. Las versiones de protocolo generalmente permanecen como los dos primeros parámetros del Paquete de capacidad del cliente de manera que se pueda determinar la compatibilidad aun cuando otros elementos del protocolo pudieran no ser compatibles o completamente entendidos como compatibles . En modo interno el aparato central puede conocer los parámetros del cliente por adelantado sin tener que recibir un Paquete de Capacidad del Cliente. El enlace puede iniciar a cualquier índice de datos al cual tanto el aparato central como el cliente puedan operar. En muchas modalidades, es muy probable que un diseñador del sistema elija iniciar el enlace al máximo índice de datos alcanzable para acelerar la transferencia de datos; sin embargo, esto no se requiere y puede no ser usado en muchas situaciones . Para operación de modo interno, la frecuencia de los pulsos de señal de validación usados durante el reinicio de enlace a partir de la secuencia de hibernación será usualmente consistente con este índice deseado.

D. Procesamiento de CRC Para todos los tipos de paquete, la máquina de estados de procesador de paquete asegura que el comprobador de CRC sea controlado en forma apropiada. Asimismo, incrementa un contador de errores de CRC cuando una comparación de CRC da por resultado la detección de uno o más errores, y restaura el contador de CRC al inicio de cada subcuadro que está siendo procesado .

?. Comprobación alternativa de pérdida de sincronización Aunque la serie anterior de pasos o estados para producir índices de datos o velocidad de rendimiento más altos, los solicitantes han descubierto que una disposición o cambio alternativo en las condiciones que el cliente usa para declarar que hay una pérdida de sincronización con el aparato central, se puede usar de manera efectiva para obtener índices de datos o rendimiento aún más altos . La nueva modalidad inventiva tiene la misma estructura básica, pero con las condiciones para cambiar estados cambiadas. Además, un nuevo contador es implementado para ayudar a hacer verificaciones para sincronización de subcuadro. Estos pasos y condiciones se presentan con relación a la figura 63, la cual ilustra una serie de estados y condiciones útiles al establecer las operaciones del método o máquina de estados . Solamente las porciones "ESTADOS DE ADQUISICIÓN DE SINC" y "ESTADOS EN-SINC" se muestran para claridad. Además, debido a que los estados resultantes son sustancialmente los mismos, como es la máquina de estados en sí, usan la misma numeración. No obstante, las condiciones para cambiar estados (y la operación de la máquina de estados) varían un poco, de manera que todas son renumeradas para claridad entre las dos figuras (1, 2, 3, 4, 5 6 contra 61, 62, 63, 64 y 65) , como una conveniencia al identificar diferencias . Debido a que el estado CUADRO ASINC no es considerado en esta discusión, un estado (4904) y condición (6) no se usan ya en la figura. En la figura 63, el sistema o cliente (para visualización o presentación) inicia con la máquina de estados 5000 en el estado "no sinc" seleccionado previamente 4902, como en la figura 49. El primer cambio de estado para cambiar estados de la condición no-sinc 4902 está en la condición 64 la cual es el descubrimiento del patrón de sincronización. Suponiendo que el CRC de la cabecera de subcuadro también pase este paquete (cumple con la condición 61) , el estado de la máquina de estados de procesador de paquete se puede cambiar al estado en-sinc 4908. Un error de sincronización, condición 62, hará que la máquina de estados cambie al estado 4910, y una segunda aparición en el estado 4912. Sin embargo, se ha descubierto que cualquier falla de CRC de un paquete MDDI hará que la máquina de estados se mueva fuera del estado en-sinc 4908, a un estado de un error de sincronización 4910. Otra falla de CRC de cualquier paquete MDDI ocasionará un movimiento al estado de dos fallas de sincronización 4912. Un paquete decodificado con un valor de CRC correcto hará que la máquina de estados regrese al estado en-sinc 4908. Lo que ha cambiado es utilizar el valor de CRC o determinación para ?cada' paquete. Esto es, hacer que la máquina de estados mire el valor de CRC para cada paquete para determinar una pérdida de sincronización en lugar de solamente observar paquetes de cabecera de subcuadro. En esta configuración o proceso, una pérdida de sincronización no se determina usando la palabra única y sólo valores de CRC de cabecera de subcuadro. Esta nueva implementación de interfase permite que el enlace de interfase MDD reconozca fallas de sincronización en forma mucho más rápida y, por consiguiente, también se recupere de ellas más rápidamente . Para hacer este sistema más robusto, el cliente debe agregar o utilizar también un contador de subcuadros . El cliente luego comprueba la presencia de la palabra única en el momento en que se espera que llegue o se presente en una señal. Si la palabra única no se presenta en el tiempo correcto, el cliente puede reconocer que una falla de sincronización ha ocurrido mucho más rápidamente que si tuviera que esperar varios (aquí tres) periodos o tiempos de paquete que tuvieran una longitud superior a un subcuadro. Si la prueba para la palabra única indica que no está presente, en otras palabras que la temporización es incorrecta, entonces el cliente puede declarar inmediatamente una pérdida de enlace de sincronización y moverse al estado no-sinc. El proceso de comprobar la presencia de la palabra única apropiada, agrega ' na condición 65 (cond 65) a la máquina de estados que dice que la palabra única es incorrecta. Si se espera recibir un paquete de subcuadro en el cliente y no coincide, el cliente puede ir inmediatamente al estado no-sinc 4902, ahorrando tiempo adicional esperando múltiples errores de sincronización (condición 62) que se encuentran normalmente atravesando los estados 4910 y 4912.

Este cambio usa un contador o función de conteo adicional en el núcleo del cliente para contar la longitud de subcuadro. En una modalidad, se usa una función de conteo descendente y la transferencia de cualquier paquete que estaba siendo procesado es interrumpida para comprobar si está la palabra única de subcuadro si el contador ha expirado. De manera alternativa, el contador puede contar progresivamente comparándose el conteo con un valor máximo deseado o un valor deseado particular, punto en el cual el paquete actual es verificado. Este proceso protege al cliente de decodificar paquetes que son recibidos de manera incorrecta en el cliente con longitudes de paquete extraordinariamente grandes . Si el contador de longitud de subcuadro necesitara interrumpir algún otro paquete que estuviera siendo decodificado, se puede determinar una pérdida de sincronización puesto que ningún paquete debe atravesar un límite de subcuadro.

IX. Procesamiento de paquetes Para cada tipo de paquete antes discutido que la máquina de estados recibe, lleva a cabo un paso o una serie de pasos de procesamiento particular para implementar la operación de la interfase. Los paquetes del enlace hacia adelante son generalmente procesados de acuerdo con el procesamiento ejemplar listado en el cuadro XII que aparece a continuación. Cuadro XII X. Reducción del índice da datos de enlace inverso Los inventores han observado que ciertos parámetros usados para el controlador de enlace de aparato central se pueden ajustar o configurar de cierta manera a fin de obtener un índice de datos de enlace inverso máximo o más optimizado (escala), lo cual es muy aconsejable. Por ejemplo, durante el tiempo usado para transferir el campo de Paquetes de Datos Inversos del Paquete de Encapsulación de Enlace Inverso, el par de señales MDDI_Stb conmuta para crear un reloj de datos periódico a la mitad del índice de datos de enlace hacia adelante. Esto ocurre porque el controlador de enlace de aparato central genera la señal MDDI_Stb que corresponde a la señal MDDI_DatosO como si estuviera enviando todo ceros. La señal MDDI_Stb es transferida del aparato central a un cliente donde se usa para generar una señal de reloj para transferir datos de enlace inverso del cliente, con lo cual los datos inversos son enviados de vuelta al aparato central. Una ilustración de cantidades típicas de retardo encontradas para la transferencia y procesamiento de señal en las trayectorias hacia adelante e inversa en un sistema que emplea la MDDI, se muestra en la figura 50. En la figura 50, una serie de valores de retardo 1.5 nseg., 8.0 nseg., 2.5 nseg., 2.0 nseg., 1.0 nseg., 1.5 nseg., 8.0 nseg., y 2.5 nseg., se muestran cerca de porciones de procesamiento para las etapas de generación de Stb+/-, transferencia de cable al cliente, receptor de cliente, generación de reloj, sincronización por reloj de señal, generación de Datos0+/-, transferencia de cable a aparato central, y receptor de aparato central, respectivamente. Dependiendo del índice de datos de enlace hacia adelante y retardos de procesamiento de señal encontrados, puede requerir más tiempo que un ciclo en la señal MDDI_Stb para este efecto de "ida y vuelta" o serie de eventos sea completado, lo cual da por resultado las cantidades no deseables de consumo de tiempo o ciclos. Para evitar este problema, el Divisor de índice Inverso hace posible que un tiempo de bit en el enlace inverso abarque múltiples ciclos de la señal MDDI_Stb. Esto significa que el índice de datos de enlace inverso es menor al índice de enlace hacia adelante . Cabe mencionar que la duración real de los retardos de señal a través de la interfase puede diferir dependiendo de cada sistema de aparato central-cliente o hardware específico que se está usando. Aunque no se requiere, cada sistema puede en general estar hecho para tener un mejor rendimiento usando el Paquete de Medición de Retardo de Ida y Vuelta para medir el retardo real en un sistema de manera que el Divisor de índice Inverso pueda ser ajustado a un valor óptimo. El aparato central puede soportar ya sea muestreo de datos básico el cual es más simple pero opera a una velocidad más lenta o muestreo de datos avanzado que es más complejo pero soporta índices de datos inversos más altos . La capacidad del cliente para soportar ambos métodos se considera igual. Un retardo de ida y vuelta es medido al hacer que el aparato central envíe un Paquete de Medición de Retardo de Ida y Vuelta al cliente. El cliente responde a este paquete enviando una secuencia de unos de vuelta al aparato central de dentro de, o durante, una ventana de medición seleccionada previamente en ese paquete llamado el campo de Período de Medición. La temporización detallada de esta medición se describió con anterioridad. El retardo de ida y vuelta se usa para determinar el índice al cual los datos de enlace inverso se pueden muestrear en forma segura. La medición de retardo de ida y vuelta consiste de determinar, detectar o contar el número de intervalos de reloj de datos de enlace hacia adelante que ocurren entre el inicio del campo de Período de Medición y el inicio del período de tiempo cuando la secuencia de respuesta Oxff, Oxff, OxOO es recibida de vuelta en el aparato central desde el cliente. Observar que es posible que la respuesta del cliente pudiera ser recibida una pequeña fracción de un periodo de reloj de enlace hacia adelante antes de que el conteo de medición estuviera a punto de incrementar. Si este valor no modificado se usa para calcular el Divisor de índice Inverso podría causar errores de bit en el enlace inverso debido a muestreo de datos no confiable. Un ejemplo de esta situación se ilustra en la figura 51, donde señales que representan MDDI_Datos en el aparato central, MDD_Stb en el aparato central, reloj de datos de enlace hacia adelante dentro del aparato central, y Conteo de Retardos se ilustran en forma gráfica. En la figura 51, la secuencia de respuesta fue recibida del cliente una fracción de un periodo de reloj de enlace hacia adelante antes dé que el Conteo de Retardos estuviera a punto de incrementar de 6 a 7. Si se supone que el retardo es 6, entonces el aparato central muestreará los datos inversos justo después de una transición de bit o probablemente en la mitad de una transición de bit. Esto podría dar por resultado un muestreo erróneo en el aparato central. Por esta razón, el retardo medido típicamente debe ser incrementado en uno antes de que sea usado para calcular el Divisor de índice Inverso. El Divisor de índice Inverso es el número de ciclos de MDD_Stb que el aparato central debe esperar antes de muestrear los datos de enlace inverso. Debido a que MDDI_Stb es ciclada a un índice que es la mitad del índice de enlace hacia adelante, la medición de retardo de ida y vuelta corregida necesita ser dividida en dos y después redondeada al siguiente entero. Expresada como una fórmula, esta relación es: ,. . . ,. ^ , i J,O. • -r. (retardo de ida y vuelta +l divisor _de_?nd?ce _?nverso = Re dondeoAlSiguienteEntero) ~ - — — — — Para el ej emplo dado, esto se convierte en 6+1 , divisor _de_ índice _ inverso = Re dondeoAlSiguienteEntero =4 ^ 2 Si la medición de retardo de ida y vuelta usada en este ejemplo fuera 7 a diferencia de 6, entonces el Divisor de índice Inverso sería también igual a 4. Los datos de enlace inverso son muestreados por el aparato central en el flanco de subida del Reloj de Enlace Inverso. Hay un contador o circuito o dispositivo conocido similar presente tanto en el aparato central, en el cliente (pantalla) para generar el Reloj de Enlace Inverso. Los contadores son inicializados de manera que el primer flanco de subida del Reloj de Enlace Inverso ocurra al inicio del primer bit en el campo de Paquetes de Enlace Inverso del paquete de Encapsulación de Enlace Inverso. Esto se ilustra, para el ejemplo dado a continuación, en la figura 52. Los contadores incrementan en cada flanco de subida de la señal MDDI_Stb, y el número de conteos que ocurren hasta que inician un nuevo ciclo es establecido por el parámetro de Divisor de índice Inverso en el Paquete de Encapsulación de Enlace Inverso. Debido a que la señal MDDI_Stb conmuta a la mitad del índice de enlace hacia adelante, entonces el índice de enlace inverso es la mitad del índice de enlace hacia adelante dividido entre el Divisor de índice Inverso. Por ejemplo, si el índice de enlace hacia adelante es 200 Mbps y el Divisor de índice Inverso es 4, entonces el índice de datos de enlace inverso se expresa como: 1 200Mbps ne t „ — = 25Mbps 2 4 Un ejemplo que muestra la temporización de las líneas de señal MDDI_DatosO y MDDI_Stb en un Paquete de Encapsulación de Enlace Inverso se muestra en la figura 52, donde los parámetros de paquete usados para 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 Banderas de Enlace Inverso = 0 Divisor de índice Inverso = 2 CRC de Parámetro = 0xdb43 Todo Cero es 0x00 Los datos de paquete entre los campos de Longitud de Paquete y CRC de Parámetro son: 0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, Oxdb, 0x00,... El primer paquete de enlace inverso regresado 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 empieza con los valores de byte 0x07, 0x00, 0x46,... y así sucesivamente. Sin embargo, solamente primer byte (0x07) es visible en la figura 52. Este primer paquete de enlace inverso es sometido a desplazamiento temporal en casi un periodo de reloj de enlace inverso en la figura para ilustrar un retardo de enlace inverso real. Una forma de onda ideal con cero retardo de ida y vuelta de aparato central al cliente se muestra como un trazo de línea punteada . El byte MS del campo de CRC de Parámetro es transferido, precedido por tipo de paquete, después del campo todo cero. La señal de validación del aparato central está conmutando de uno a cero y de vuelta a uno a medida que los datos del aparato central cambian de nivel, formando pulsos más amplios. A medida que los datos van a cero, la señal de validación conmuta a un índice más alto, solamente el cambio en los datos en la línea de datos ocasiona un cambio cerca del final del campo de alineación. La señal de validación conmuta al índice más alto para el resto de la figura debido a los niveles 0 ó 1 fijos de la señal de datos durante períodos de tiempo prolongados, y las transiciones que se encuentran en el patrón de pulso (flanco) . El reloj de enlace inverso para el aparato central está a cero hasta el final del periodo de Inversión de Sentido 1, cuando el reloj es iniciado para admitir los paquetes de enlace inverso. Las flechas en la porción inferior de la figura indican cuando los datos son muestreados, como sería evidente a partir del resto de la descripción. El primer byte del campo de paquete que está siendo transferido (aquí 11000000) se muestra empezando después de Inversión de Sentido 1, y el nivel de línea se ha estabilizado debido a la inhabilitación del excitador de aparato central. El retraso en el paso del primer bit, como se ve para el bit tres, se puede ver en líneas punteadas para la señal de Datos . En la figura 53, se pueden observar valores típicos del Divisor de índice Inverso en el índice de datos de enlace hacia adelante. El Divisor de índice Inverso real se determina como un resultado de una medición de enlace de ida y vuelta para garantizar una operación de enlace inverso apropiada. Una primera región 5302 corresponde a un área de operación segura, una segunda región 5304 corresponde a un área de rendimiento marginal, mientras que una tercera región 5306 indica ajustes que es poco probable que funcionen adecuadamente . La medición de retardo de ida y vuelta y ajuste del Divisor de índice Inverso son los mismos mientras operan con cualesquiera de los ajustes de Tipo de Inferíase ya sea en el enlace hacia adelante o enlace inverso porque están expresados y operados en términos de unidades de períodos de reloj reales más que números de bits transmitidos o recibidos .

XI. Inversión de sentido y Tiempos de guarda Como se discute con anterioridad, el campo de Inversión de Sentido 1 en el Paquete de Encapsulación de Enlace Inverso y el campo de Tiempo de Guarda 1 en el Paquete de Medición de Retardo de Ida y Vuelta designan valores para duraciones de tiempo que permiten que los excitadores de interfase de aparato central sean inhabilitados antes de que los excitadores interfase de cliente sean habilitados. Los campos de Inversión de Sentido 2 y Tiempo de Guarda 2 proveen valores de tiempo los cuales permiten que los excitadores de cliente sean inhabilitados antes de que los excitadores de aparato central sean habilitados. Los campos Tiempo de Guarda 1 y Tiempo de Guarda 2 en general son llenados con valores establecidos previamente o seleccionados previamente para duraciones que no se pretende sean ajustadas. Dependiendo del hardware de interfase que se está usando, estos valores pueden ser desarrollados usando datos empíricos y ajustados en algunos casos para mejorar la operación. Diversos factores contribuyen a una determinación de la longitud de inversión de sentido 1 y éstos son el índice de datos de enlace hacia adelante y el tiempo de inhabilitación máximo de los excitadores de MDDI_Datos en el aparato central . El tiempo de inhabilitación de excitador de aparato central máximo se especifica en el Cuadro XI, donde muestra que los excitadores requieren aproximadamente 10 nseg máximo para inhabilitarse y aproximadamente 2 nseg para habilitarse. El número mínimo de relojes de enlace hacia adelante requeridos para que el excitador de aparato central sea inhabilitado se expresa de acuerdo con la relación: _ , . . , . ... índiceDeDatosDeEniaceHaciaAdelante _, , _ r , , .,., .. _ Relojes para inhabilitar,.. = RetardoDelnhabilitacionDe v^r.;,„?r¡rr?a?r,nrnmran rr, J ~ ~ ™ FactordeTipoDeInterfaseF„,D Exc?tadorDeAparatoCentralm El rango de valor permitido de Inversión de Sentido 1 está expresado de acuerdo con la siguiente relación: r„vrr*i?« _dr_S,>„Hdn_ > -Re>.dn»dt>nAlSim?tontr »tP.m F ct?rDcTipoDcIntc scF donde el Factor de Tipo de Inferíase es 1 para el Tipo 1, 2 para el Tipo 2, 4 para el Tipo 3 y 8 para el Tipo 5. 4. Combinando las dos ecuaciones de arriba, se puede ver que el término Factor de Tipo de Inferíase se cancela, e Inversión de Sentido 1 se define como: Inversión _ de_ Sentido _ 1 ™ Re dondeoAlSigllienteEntero (ÍndtceDeDatosDeEnlaceHaciaAde!ante • Re tardoDelnhabiiitaciónDeExcitadorDeAparatoCentral 0 s, Por ejemplo, un enlace hacia delante de Tipo 3 de 1500 Mbps usaría un retardo de Inversión de Sentido 1 de : Inversión _de _Sentido = 2Bytes 5 A medida que el retardo de ida y vuelta incrementa, el margen de temporización mejora desde el punto en el tiempo cuando el aparato central es inhabilitado hasta el tiempo en que el cliente es inhabilitado. Los factores que determinan la duración de tiempo 0 generalmente usado para Inversión de Sentido 2 son el índice de datos de enlace hacia adelante, el tiempo de inhabilitación máximo de los excitadores de MDDI_Datos en el cliente y el retardo de ida y vuelta del enlace de comunicación. El cálculo del tiempo requerido para 5 inhabilitar el excitador de cliente es esencialmente el mismo que aquél para el excitador de aparato central antes discutido, y se define de acuerdo con la relación: _ , . . , , .,. ÍndiceDeDatosDeEnlaceHaciaAdelante „ , . „ , , . .,. .. Relojes para ?nhab?l?tart„ = RetaraoDelnhabihtacion J ~ ~ T?1 FaclorDeTipoDeInterfase„D y el rango de valor permitido para Inversión de Sentido 2 está expresado como: Inversión _ de _ Sentido _ 2 > Re dondeoAlSiguienteEntero Re lojes _para_ ¡nhab¡liíarTA2 + rerardo _de_ ¡da _ y _ vuella -f I FactorDeTipoDe?níerfasenm J Por ejemplo, un enlace hacia delante de Tipo 3 de 1500 Mbps con un retardo de ida y vuelta de 10 relojes de enlace hacia adelante típicamente usa un retardo de Inversión de Sentido 2 en el orden de: T, , • . , , .,. 1500M»;» 1 ? „ „^ Re lojes _ para _ ?nhab?l?tarTA2 = 1 Onseg = 3.75 3.75+10+1 Inversión _de_ Sentido _ 2 > Re dondeoAlSiguienteEntero XII . Temporización de enlace inverso alternativa Aunque el uso de temporización y bandas de guarda antes discutidas funcionan para lograr una interfase de índice de transferencia de datos alto, los inventores han descubierto una técnica para tomar en cuenta longitudes de bit inverso que son más cortas que el tiempo de ida y vuelta, cambiando el descubrimiento de temporización inversa.

Como se presenta anteriormente, el enfoque anterior a la temporización del enlace inerso está configurado de manera tal que el número de ciclos de reloj sea contado del último bit del Tiempo de Guarda 1 de un paquete de temporización inversa hasta que el primer bit sea muestreado en el flanco de subida de un reloj 10. Esto es, la(s) señal (es) de reloj usada (s) para temporizar las entradas y salidas para la interfase MDD. El cálculo para el divisor de índice inverso es luego dado por: , . ,. - . , , J,„. . „ (retardo de ida y vuelta+\? divisor _de_?nd?ce_?nverso = RedondeoAlSiguwnteEnterc? = — ~ — Esto provee un ancho de bit igual al retardo de ida y vuelta que da por resultado un enlace inverso muy confiable. Sin embargo, se ha demostrado que el enlace inverso es capaz de operar más rápido, o a un índice de transferencia de datos más alto, de lo cual se quieren aprovechar los inventores . Una nueva técnica inventiva permite utilizar capacidades adicionales de la interfase para alcanzar velocidades más altas . Esto se realiza haciendo que el aparato central cuente el número de ciclos de reloj hasta que un uno sea muestreado, pero con el aparato central muestreando la línea de datos tanto en el flanco de subida como en el flanco de bajada durante el paquete de temporización inversa. Esto permite que el aparato central elija el punto de muestreo más útil o incluso óptimo dentro del bit inverso para asegurar que el bit esté estable. Esto es, encontrar el flanco de subida más útil u óptimo para muestrear datos para paquetes de encapsulación inversa de tráfico inverso. El punto de muestreo óptimo depende tanto del divisor de enlace inverso como de si el primero fue detectado en un flanco de subida o en un flanco de bajada. El nuevo método de temporización permite al aparato central sólo buscar el primer flanco del patrón OxFF OxFF 0x00 enviado por el cliente para temporización de enlace inverso para determinar dónde muestrear en un paquete de encapsulación inversa. Ejemplos del bit inverso que llega y cómo ese bit buscaría diversos divisores de índice inverso, se muestran en la figura 64, junto con un número de ciclos de reloj que han ocurrido desde el último bit de Tiempo de Guarda 1. En la figura 64, se puede ver que si el primer flanco ocurre entre un flanco de subida y de bajada (nombrado como subida/bajada) , el punto de muestreo óptimo para un divisor de índice inverso de uno, el punto de muestra óptimo es un flanco de ciclo de reloj nombrado b' , ya que ése es el único flanco de subida que ocurre dentro del periodo del bit inverso. Para un divisor de índice inverso de dos, el punto de muestreo óptimo es probablemente aún el flanco anterior de ciclo de reloj ?b' ya que el flanco de ciclo c' está más cerca de un flanco de bit que ?b' . Para un divisor de índice inverso de cuatro, el punto de muestreo óptimo es probablemente el flanco de ciclo de reloj d' , puesto que está más cerca del flanco posterior del bit inverso donde el valor probablemente se ha estabilizado. Volviendo a la figura 64, si, no obstante, el primer flanco ocurre entre un flanco de bajada y de subida (nombrado bajada/subida), el punto de muestreo óptimo para un divisor de índice inverso de uno es el flanco de ciclo de reloj ?a' , ya que es el único flanco de subida dentro del periodo de tiempo de bit inverso .

Para un divisor de índice inverso de dos, el punto de muestreo óptimo es el flanco b' , y para un un divisor de índice inverso de cuatro el punto de muestreo óptimo es el flanco ?c' . Se puede ver que a medida que los divisores de índice inverso se hacen cada vez más grandes, es más fácil determinar o seleccionar el punto de muestreo óptimo, como debe ser el flanco de subida que está más cerca del centro . El aparato central puede usar esta técnica para encontrar el número de flancos de reloj de subida antes de que el flanco de datos de subida de los datos de paquete de temporización sea observado en la línea de datos. Luego puede decidir, con base en si el flanco ocurre entre un flanco de subida y de bajada o entre un flanco de bajada y subida, y cuál es el divisor de índice inverso, cuántos ciclos de reloj adicionales agregar a un contador de números, para asegurar de manera razonable que el bit sea siempre muestreado tan cerca del centro como sea posible. Una vez que el aparato central ha seleccionado o determinado el número de ciclos de reloj , puede "explorar" diversos divisores de índice inverso con el cliente para determinar si un divisor de índice inverso particular funcionará. El aparato central (y cliente) pueden empezar con un divisor de uno y verificar el CRC del paquete de estado inverso recibido del cliente para determinar si este índice inverso funciona en forma adecuada para transferir datos. Si el CRC está corrupto, probablemente hay un error de muestreo, y el aparato central puede incrementar el divisor de índice inverso e intentar solicitar un paquete de estado nuevamente. Si el segundo paquete solicitado está corrupto, el divisor puede ser incrementado otra vez y la solicitud se puede hacer de nuevo. Si este paquete es decodificado de manera correcta, este divisor de índice inverso se puede usar para todos los paquetes inversos futuros . Este método es efectivo y útil porque la temporización inversa no debe cambiar del cálculo aproximado de temporización de ida y vuelta inicial. Si el enlace hacia adelante es estable, el cliente debe continuar decodificando paquetes de enlace hacia adelante aún si hay fallas de enlace inverso. Por supuesto, aún es responsabilidad del aparato central establecer un divisor de índice inverso para el enlace, puesto que este método no garantiza un enlace inverso perfecto. Además, el divisor dependerá principalmente de la calidad del reloj que se usa para generar un reloj de 10. Si ese reloj tiene una cantidad significativa de fluctuación, existe una mayor posibilidad de un error de muestreo. Esta probabilidad de error incrementa con la cantidad de ciclos de reloj en el retardo de ida y vuelta. Esta implementación parece funcionar mejor para datos inversos de Tipo 1, pero puede presentar problemas para datos inversos de Tipo 2 al Tipo 4 debido al sesgo entre líneas de datos es potencialmente demasiado grande para ejecutar el enlace al índice que funciona mejor sólo para un par de datos. No obstante, probablemente el índice de datos no necesita ser reducido al método anterior aún con Tipo 2 al Tipo 4 para operación. Igualmente, este método puede funcionar mejor si se duplica en cada línea de datos para seleccionar el lugar de muestra de reloj ideal u óptimo. Si están al mismo tiempo de muestra para cada par de datos, este método continuaría funcionando. Si están a diferentes periodos de muestra, se pueden usar dos enfoques diferentes. El primero es seleccionar un lugar de muestra deseado o más optimizado para cada punto de datos, aún si no es el mismo para cada par de datos . El aparato central puede luego reconstruir el flujo de datos después de muestrear todos los bits de la serie de parece datos: dos bits para el Tipo 2, cuatro bits para el Tipo 3 y ocho bits pare Tipo 4. La otra opción es que el aparato central incremente el divisor de índice inverso de modo tal que los bits de datos para cada par de datos puedan ser muestreado en el mismo flanco de reloj .

XIII. Efectos del retardo de enlace y sesgo. El sesgo de retardo en el enlace hacia adelante entre los pares de MDDI_Datos y MDDI_Stb puede limitar el índice de datos máximo posible a menos que se use compensación de sesgo de retardo. Las diferencias en el retardo que ocasionan sesgo de temporización se deben a la lógica del controlador, los excitadores y receptores de línea y el cable y conectores como se explica de manera resumida más adelante.

A. Análisis de temporización de enlace limitado por el sesgo (Tipo-1 MDDI) 1. Ejemplo de retardo y sesgo de un enlace Tipo 1 Un circuito de interfase típico similar al que se muestra en la figura 41, se muestra en la figura 57 para admitir un enlace de interfase Tipo 1. En la figura 57, valores ejemplares o típicos para retardo de propagación y sesgo se muestran para cada una de las diversas etapas de procesamiento o interfase de un enlace hacia adelante Tipo 1 MDDI . El sesgo en el retardo entre MDDI_Stb y MDDI_DatosO ocasiona que el ciclo de trabajo del reloj de salida se distorsione. Los datos en la entrada D de la etapa basculante (RXFF) de receptor que usa los biestables 5728, 5732, cambian ligeramente después del flanco de reloj de manera que se puedan muestrear de manera confiable. La figura muestra dos líneas de retardo en cascada 5732a y 5732b que se usan para solucionar dos diferentes problemas con la creación de esta relación de temporización. En la implementación real éstas se pueden combinar en un solo elemento de retardo. Datos, Stb, y Temporización de Recuperación de Reloj en un Enlace Tipo 1 para procesamiento de señal ejemplar a través de la interfase se ilustran en la figura 58. El sesgo de retardo total que es significativo por lo general surge o proviene de la suma del sesgo en las siguientes etapas: biestable de transmisor (TXFF) con biestables 5704, 5706; excitador de transmisor (TXDRVR) con los excitadores 5708, 5710; el CABLE 5702; receptor de línea de receptor (RXRCVR) con los receptores 5722, 5724; y lógica XOR de receptor (RXXOR) . El Retardol 5732a debe igualar o exceder el retardo de la puerta XOR 5736 en la etapa RXXOR que se determina por la relación: ^PZ>-min(Re ol) — ^PD-max(ZO?) Es aconsejable cumplir con este requerimiento de manera que la entrada D del biestable de receptor 5728, 5732 no cambie antes de su entrada de reloj . Esto es válido si el tiempo de retención de RXFF es cero. El propósito o función de Retardo2 es compensar el tiempo de retención del biestable RXFF de acuerdo con la relación: tpD-min(Retardo2) = ^H(RXFF) En muchos sistemas esto será cero porque el tiempo de retención es cero y, desde luego, en ese caso el retardo máximo de Retardo2 puede ser también cero .

El peor caso de contribución al sesgo en la etapa XOR de receptor está en el caso datos-tardíos/señal de validación-temprana donde el Retardol está a un valor máximo y la salida de reloj de la puerta XOR viene tan temprano como es posible de acuerdo con la relación: t SESGO-?WL(RXXOR) = ^PD-ma?(Retardol) ~ ^ PD-mm(XOR) En esta situación, los datos pueden cambiar entre dos periodos de bit, n y n+l, muy cerca al tiempo donde bit n+l es sincronizado por reloj en el biestable de receptor. El índice de datos máximo (período de bit mínimo) de un enlace Tipo 1 MDDI es una función del sesgo máximo encontrado a través de todos los excitadores, cable y receptores en el enlace de MDDI más el establecimiento de datos total en la etapa RXFF. El sesgo de retardo total en el enlace hasta la salida de la etapa RXRCVR se puede expresar como: tsESGO-max(.ENLACE) = *- SESGO-m8i(TXFF) + SESGO-max.(TXDRVR) + * SESGO '-max(C¿BZ£) "+ SESGO-max(RXRCVR) donde el "cable" representa una variedad de conductores o interconexiones o hilos y retardo correspondiente, y el período de bit mínimo es dado por: 'ß/r-min = tsESGO-m8.{ENALCE) + *• ' ^B-TP4 + ' Asmarla + ' S£SCO-max(AOr?J¡) ' Jluauaci?n-apararoamrral + ' iYJ-max(Reí<m/o2) + u(RXFF) En el ejemplo mostrado en la figura 57 para modo externo, tSEsGo-max(ENLACE) = 1000 pseg y el período de bit mínimo se puede expresar como: -m¡n = 100° +2 •125 + 625 + 125 + 200 + 0+100 = 2300 pseg, o expresado como aproximadamente 434 Mbps. En el ejemplo mostrado en la figura 57 para modo interno, tsEsco-ma (ENLACE) = 500 pseg y el período de bit mínimo se puede expresar como: tBIT_mia = 500+2 •125 +625 +125+ 200+0+100 = 1800 pseg, o expresado como aproximadamente 555 Mbps.

B. Análisis de temporización de enlace para Tipo 2, 3 y 4 de DDI Un circuito de interfase típico similar al que se muestra en las figuras 41 y 57, se muestra en la figura 59 para admitir enlaces de interfase Tipo 2, 3 y 4. Se usan elementos adicionales en las etapas TXFF (5904) , TXDRVR (5908), RXRCVCR (5922) y RXFF (5932, 5928, 5930) para admitir el procesamiento de señal adicional. En la figura 59, valores ejemplares o típicos para retardo de propagación y sesgo se muestran para cada una de las diversas etapas de procesamiento o interfase de un enlace hacia adelante Tipo 2 de MDDI . Además del sesgo en el retardo entre MDDI_Stb y MDDI_Datos0 que afecta el ciclo de trabajo del reloj de salida, también hay sesgo entre ambas señales y las otras señales MDDI_Datos . Los datos en la entrada D de la etapa basculante B (RXFFB) de receptor que consiste de los biestables 5928 y 5930, son cambiados ligeramente después del flanco de reloj de manera que se puedan muestrear de manera confiable. Si MDDI_Datosl llega antes que MDDI_Stb o MDDI_DatosO, entonces MDDI_Datosl debe ser retardada para ser muestreada por al menos la cantidad de sesgo de retardo. Para realizar esto, los datos son retardados usando la línea de retardo Retardo3. Si MDDI_Datosl llega después de MDDI_Stb y MDDI_DatosO y también es retardada por Retardo 3, entonces el punto donde MDDI_Datosl cambia es movido más cerca del siguiente flanco de reloj . Este proceso determina un límite superior del índice de datos de un enlace Tipo 2, 3 o 4 de MDDI. Algunas posibilidades diferentes ejemplares para la relación de temporización o sesgo de dos señales de datos y MDDI_Stb con respecto una de la otra se ilustra en las figuras 60A, 60B y 60C. A fin de muestrear datos de manera confiable en RXFFB cuando MDDI_DatosX llega tan temprano como es posible, Retardo3 se ajusta de acuerdo con la relación: PD-mm(RetardoÍ) — ^SESGO-max{ENLACE) + ^H{RXFFB) + ^PD-msx(XOR) La velocidad de enlace máxima es determinada por el período de bit mínimo permisible. Esto es afectado más cuando MDDI DatosX llega tan tarde como es posible. En ese caso, el tiempo de ciclo mínimo permisible es dado por: ^BIT-min ~ * SESGO-mdX.(ENLACE) + />D-max(Re tardo 3) + *SU(RXFFB) ~ * PD-pan{XOR) El límite superior de la velocidad de enlace es entonces : tpD-max(Retardo3) ~ * PD-tmn(RstardoS) y dada esa suposición : ^BIT-m (limite- í erior) ~ 2 ' ¿ SESGO-m8(ENLACE) "+ ¿ PD-max(XOR) + SU (RXFFB) + *H(,RXFFB) En el ejemplo antes dado, el límite inferior del periodo de bit mínimo es dado por la relación: 2-(1000 + 2.125+ 625 + 200)+1500 +100+0 = 5150 pseg, lo cual es aproximadamente 174 Mbps. Esto es mucho más lento que el índice de datos máximo que se puede usar con un enlace Tipo 1. La capacidad de compensación de sesgo de retardo automática de MDDI reduce de manera significativa el efecto que el sesgo de retardo tiene en el factor de índice de enlace máximo, está justo en el límite del establecimiento de datos válido. El sesgo calibrado entre MDDI_DatosO y MDDI_Stb es: t = 0 . f 1 SESGO-ta8.(calibrado) ^ íTAP-SEPARACIÓN-pm* y el periodo de bit mínimo es : ' BIT~mw-cal¡brado "*" ' fl cr acl?n-aparalocenlral + ' SESCO-rmx.(.RXAND*RXXOR) + 'SE/(?XFF) Donde "TB" o tB representa fluctuación de señal de un límite de bit a un nivel de salida mínimo. La asimetría simplemente se refiere a la naturaleza asimétrica del retardo interno a través de los receptores diferenciales o de los mismos. "TP4" está asociado con o se define de manera efectiva para caracterización eléctrica y propósitos de prueba como la conexión o interfase (terminales del dispositivo controlador de MDDI en el cliente) para los excitadores y receptores de línea diferenciales para el cliente. Representa un punto conveniente o predeterminado a partir del cual se mide el retardo de señal y caracterizado para él enlace en el resto de un sistema. En una modalidad, un valor máximo del parámetro TB en TP4 es definido por la relación .102-tßit+50 ps, para el modo interno. La etiqueta TP4 es simplemente útil al enumerar varios puntos de prueba (TP) en la interfase y enlaces. En una modalidad, se define que este punto de prueba es igual tanto para modo interno como para modo externo . Existe un punto de prueba "TPO" correspondiente, o asociado con, las terminales de conexión o interfase del dispositivo controlador de MDDI en el aparato central que contiene los excitadores y receptores de línea diferenciales . En el ejemplo mostrado en la figura 59, tSESG0-max(Datoso-stb-caiibrado) = 300 pseg y el período de bit mínimo: tBiT-r?n-cantrado = 300 + 2 • 125 + 625 + 200 + 175 + 100 = 1650 pseg, aproximadamente 606 Mbps. A fin de muestrear datos de manera confiable en RXFFB cuando MDDI_Datosl llega tan temprano como es posible, el retardo programable asociado es ajustado a la configuración óptima con una precisión de una toma, y un retardo de toma adicional se agrega para seguridad. La velocidad de enlace máxima es determinada por el período de bit mínimo permisible. Esto se afecta más cuando MDDI_Datosl llega tan tarde como es posible. En ese caso el tiempo de ciclo mínimo permisible es : *- BIT-min~Datos\-Calibrado ~ *" ' AP-Separaci?n-max. "+ ^ ' ^TA-TP4, donde "TA" o tA representa fluctuación de señal de un límite de bit al cruce de centro. En el ejemplo dado en la figura 59, el límite inferior del periodo de bit mínimo basado en el muestreado de MDDI_Datosl es: tBIT-min-Dalosl-Calibrado = 2 • 150 + 2 • 125 = 550PSeg En una modalidad, un tiempo de retardo total típico para sesgo de retardo, asimetría de retardo y Fluctuación de Reloj en el Aparato Central para Modo Interno se definiría como: 0? I • (tBp — l5üpS) mientras que un tiempo de retardo total típico para sesgo de retardo, asimetría de retardo y tiempo de establecimiento en el aparato cliente para modo interno es t Asimetria-RXRCVR + Asimetria-RXXOR + t Sesgo- RXRCVR + ^Sesgo-RXXOR + * establecimiento-RXFF ~ 0-ÍOl • (tß/r 150/W) XIV. Descripción de interconexión de capa física Las conexiones físicas útiles para implementar una interfase de acuerdo con la presente invención se puedan realizar usando partes disponibles comercialmente tales como parte número 3260-8S2(01) ' fabricada por Hirose Electric Company Ltd. en el lado del aparato central, y parte número 3240-8P-C fabricada por Hirose Electric Company Ltd. en el lado del aparato cliente. Una asignación de terminales de interfase ejemplar o "disposición de terminales" para tales colectores usados con interfaces Tipo I/Tipo 2 se lista en el cuadro XIII y se ilustra en la figura 61.

Cuadro XIII El blindaje está conectado a la HOST_Gnd en la interfase de aparato central, y un cable de drenaje blindado en el cable está conectado al blindaje del conector de cliente. No obstante, el blindaje y cable de drenaje no están conectados a la tierra del circuito dentro de un cliente . Se eligen o diseñan elementos o dispositivos de interconexión para que sean lo suficientemente pequeños para usar con los dispositivos de comunicación e informática móviles, tales como PDA' s y teléfonos inalámbricos, o dispositivos de juego portátiles, sin ser protuberantes o antiestéticos en comparación con el tamaño de aparato relativo. Cualesquier conectores y cableado deben ser lo suficientemente duraderos para usar en el ambiente de consumidor típico y tener en cuenta un tamaño pequeño, en especial para el cableado, y costo relativamente bajo. Los elementos de transferencia deben admitir datos y señales de validación que son datos NRZ diferenciales que tienen un índice de transferencia hasta de aproximadamente 450 Mbps para Tipo 1 y Tipo 2 y hasta 3.6 Gbps para la versión Tipo 4 paralela de 8 bits . Para aplicaciones de modo interno ya sea que no se usan conectores en el mismo sentido para los conductores o dichos elementos de conexión tienden a ser muy miniaturizados . Un ejemplo son los "zócalos" con fuerza de inserción nula para recibir circuitos integrados un elementos que alojan, ya sea el aparato central o el aparato cliente. Otro ejemplo es donde el aparato central y cliente residen en tarjetas de circuito impresas con diversos conductores de interconexión, y tienen "terminales" o contactos que se extienden desde los alojamientos que están soldados a contactos en los conductores para interconexión de circuitos integrados.

XV. Operación Un resumen de los pasos generales llevados a cabo al procesar datos y paquetes durante la operación de una interfase usando las modalidades de la invención se muestra en las figuras 54A y 54B, junto con una visión general del aparato de interfase que procesa los paquetes en la figura 55. En estas figuras, el proceso inicia en un paso 5402 con una determinación en cuanto a si el cliente y el aparato central están o no conectados usando una trayectoria de comunicación, aquí un cable. Esto puede ocurrir por medio del uso de un sondeo periódico por parte del aparato central, utilizando software o hardware que detecta la presencia de conectores o cables o señales en las entradas al aparato central (tal como se ve para interfases USB) u otras técnicas conocidas . Si no hay un cliente conectado al aparato central, entonces puede simplemente entrar en un estado de espera de alguna duración predeterminada, dependiendo de la aplicación, entrar en un modo de hibernación, o ser inactivado para esperar un uso futuro que pudiera requerir que un usuario tomara acción para reactivar el aparato central. Por ejemplo, cuando un aparato central reside en un dispositivo tipo computadora, un usuario pudiera tener que hacer clic en un icono de pantalla o solicitar un programa que active el procesamiento de aparato central para buscar al cliente. De nuevo, enchufar simplemente una conexión tipo USB podría activar el procesamiento de aparato central, dependiendo de las capacidades y configuración del aparato central o software de aparato central residente . Una vez que un cliente es conectado al aparato central, o viceversa, o se detecta que está presente, ya sea cliente o el aparato central envía paquetes apropiados solicitando servicio en los pasos 5404 y 5406. El cliente podría enviar ya sea paquetes de Solicitud o Estado de Servicio de Cliente en el paso 5404. Se observa que el enlace, como se discute anteriormente, podría haber sido interrumpido anteriormente o estar en modo de hibernación así que ésta puede no ser una inicialización completa del enlace de comunicación que sigue. Una vez que el enlace de comunicación está sincronizado y el aparato central está intentando comunicarse con el cliente, el cliente provee también un paquete de Capacidades del Cliente al aparato central, como en el paso 5408. El aparato central puede ahora a empezar a determinar el tipo de soporte, incluyendo índices de transferencia, que el cliente puede admitir. En general, el aparato central y el cliente también negocian el tipo (índice/velocidad) de modo de servicio que se va a usar, por ejemplo Tipo 1, Tipo 2, y así sucesivamente, en un paso 5410. Una vez que el tipo de servicio es establecido el aparato central puede empezar a transferir información. Además, el aparato central puede usar Paquetes de Medición de Retardo de Ida y Vuelta para optimizar la temporización de los enlaces de comunicación en paralelo con otro procesamiento de señal, como se muestra en el paso 5411. Como se menciona anteriormente, todas las transferencias empiezan con un Paquete de Cabecera de Subcuadro, que se muestra siendo transferido en el paso 5412, seguido del tipo de datos, aquí paquetes de flujo de video y audio, y paquetes de relleno, que se muestran siendo transferidos en el paso 5414. Los datos de audio y video habrán sido preparados o mapeados previamente en paquetes, y se insertan paquetes de relleno como sea necesario o como se desee para llenar un número requerido de bits para los cuadros de medios . El aparato central puede enviar paquetes tales como los Paquetes de Habilitación de Canal de Audio Hacia Adelante para activar dispositivos de sonido. Además, el aparato central puede transferir comandos e información usando otros tipos de paquete antes discutidos, aquí se muestra como la transferencia de paquetes de Mapa de Colores, Transferencia de Bloque de Bits u otros paquetes en el paso 5416. Además, el aparato central y el cliente pueden intercambiar datos referentes a un dispositivo de teclado o dispositivo señalador usando los paquetes apropiados . Durante la operación, puede ocurrir uno de diversos eventos diferentes que ocasionan que el aparato central o cliente desee un índice de datos o tipo de modo de interfase diferente. Por ejemplo, una computadora u otro dispositivo que comunica datos podría encontrar condiciones de carga al procesar datos que ocasiona una pérdida de velocidad en la preparación o presentación de paquetes . Un aparato cliente que recibe los datos podría cambiar de una fuente de potencia de CA dedicada a una fuente de potencia de batería más limitada, y ya sea no ser capaz de transferir datos tan rápidamente, procesar comandos tan fácilmente, o no ser capaz de usar el mismo grado de resolución o profundidad de color bajo los ajustes de potencia más limitados. De manera alternativa, una condición restrictiva podría ser eliminada o podría desaparecer permitiendo que cualquiera de los dos dispositivos transfiera datos a índices más altos. Esto es más deseable, se puede hacer una solicitud para cambiar a un modo de índice de transferencia más alto. Si éstos u otros tipos de condiciones conocidas ocurren o cambian, ya sea el aparato central o el cliente las puede detectar e intentar volver a negociar el modo de interfase. Esto se muestra en el paso 5420, donde el aparato central envía Paquetes de Solicitud de Cesión de Tipo de Inferíase al cliente solicitando una cesión a otro modo, el cliente envía Paquetes de Confirmación de Tipo de Inferíase confirmando que se busca un cambio, y el aparato central envía Paquetes de Cesión de Tipo de Ejecución para hacer el cambio al modo especificado. Aunque no requieren un orden particular de procesamiento, el cliente y aparato central pueden intercambiar también paquetes referentes a datos destinados para o recibidos de dispositivos señaladores, teclados u otro tipo de dispositivos de entrada de tipo de usuario asociados principalmente con el cliente, aunque tales elementos pueden estar también presentes en el lado del cliente. Estos paquetes son típicamente procesados usando un elemento de tipo de procesador general y no la máquina de estados (5502) . Además, algunos de los comandos antes discutidos serán también procesados por el procesador general (5504, 5508) . Después de que los datos y comandos han sido intercambiados entre el aparato central y el cliente, en algún punto se hace una decisión sobre si se van a transferir o no datos adicionales o si el aparato central o cliente van a dejar de dar servicio a la transferencia. Esto se muestra en el paso 5422. Si el enlace va a entrar en un estado de hibernación o va a ser interrumpido por completo, el aparato central envía un paquete de Interrupción de Enlace al cliente y ambos lados terminan la transferencia de datos. Los paquetes que son transferidos en el procesamiento de operaciones anterior serán transferidos usando los excitadores y receptores previamente discutidos con relación a los controladores de aparato central y cliente. Estos excitadores de línea y otros elementos lógicos son conectados a la máquina de estados y procesadores generales antes discutidos, como se ilustra en la visión general de la figura 55. En la figura 55, una máquina de estados 5502 y procesadores generales 5504 y 5508 se pueden conectar también a otros elementos no mostrados tales como una interfase USB dedicada, elementos de memoria u otros componentes que residen fuera del controlador de enlace con el cual interactúan, incluyendo, mas no limitado a, la fuente de datos, y chips de control de video para dispositivos de pantalla de visualización. Los procesadores y máquina de estados proveen control sobre la habilitación e inhabilitación de los excitadores como se discute anteriormente con relación a tiempos de guarda, y así sucesivamente para asegurar un establecimiento o terminación eficiente del enlace de comunicación, y transferencia de paquetes.

XVI Memorias Intermedias de cuadro de visualización Los requerimientos de almacenamiento en memoria intermedia de datos de video son diferentes para imágenes de video en movimiento en comparación con gráficos de computadora. Los datos de pixel son con más frecuencia almacenados en una memoria intermedia de cuadro local en el cliente de manera que la imagen en el cliente puede ser renovada localmente. Cuando un video a velocidad real está siendo visualizado (casi cada pixel en la pantalla cambian cada Cuatro de Medios) se prefiere usualmente almacenar los datos de pixel entrantes en una memoria intermedia de cuadro mientras la imagen en la pantalla está siendo renovada desde una segunda memoria intermedia de cuadro. Se pueden usar más de dos memorias intermedias de visualización para eliminar artefactos visibles como se describe más adelante. Cuando una imagen entera ha sido recibida en una memoria intermedia de cuadro, entonces las funciones de las memorias intermedias se pueden intercambiar, y la imagen recién recibida es luego usada para renovar la pantalla y la otra memoria intermedia es llenada con el siguiente cuadro de la imagen. Este concepto se ilustra en la figura 91A, donde datos de pixel son escritos a la memoria intermedia de imagen fuera de línea ajusfando los bits de Actualización de Pantalla a "01". En otras aplicaciones el aparato central necesita actualizar solamente una pequeña porción de la imagen sin tener que redib jar la imagen entera. En esta situación se desea escribir los nuevos pixeles directamente a la memoria intermedia que está siendo usado para renovar la pantalla, como se ilustra en detalle en la figura 91B. En aplicaciones que tienen una imagen fija con una pequeña ventana de video es más fácil escribir la imagen fija a ambas memorias intermedias (bits que actualización de pantalla igual a "11") como se muestra en la figura 91C, y posteriormente escribir los pixeles de la imagen en movimiento a la memoria intermedia fuera de línea ajusfando los bits que actualización de pantalla a "01". Las siguientes reglas describen la manipulación útil de indicadores de memoria intermedia mientras se escribe de manera simultánea nueva información al cliente y se renueva la pantalla. Existen tres indicadores de memoria intermedia: relleno_actual apunta a la memoria intermedia que está siendo rellenada actualmente a partir de datos en el enlace de MDDI . Recién_rellenado apunta a la memoria intermedia que fue rellenada más recientemente. Está_siendo_desplegado apunta a la memoria intermedia que se está usando actualmente para renovar la pantalla. Los tres indicadores de memoria intermedia pueden contener valores de 0 a N-l donde N es el número de memorias intermedias de visualización, y N > 2. La aritmética en los indicadores de memoria intermedia es mod N, por ejemplo, cuando N = 3 y relleno_actual = 2, incrementar relleno_actual ocasiona que relleno_actual sea ajustado a 0. En el caso simple donde N=2, recién_rellenado es siempre el complemento de relleno_actual . En cada límite de Cuadro de Medios de MDDI (Paquete de Cabecera de Subcuadro con el campo de Conteo de Subcuadros igual a 0) llevar a cabo las siguientes operaciones en el orden especificado: ajustar recién_rellenado igual a relleno_actual, y ajustar relleno_actual igual a relleno_actual+l . Los Paquetes de Flujo de Video MDDI actualizar la memorias intermedias de acuerdo con la estructura o metodología de: cuando los Bits de Actualización de Pantalla son igual a 01', los datos de pixel son escritos a la memoria intermedia especificada por relleno_actual; cuando los Bits de Actualización de Pantalla son igual a 00' , los datos de pixel son escritos a la memoria intermedia especificada por recién_rellenado; y cuando los Bits de Actualización de Pantalla son igual a ll' , los datos de pixel son escritos a todos las memorias intermedias. La pantalla es renovada desde la memoria intermedia especificada por el indicador está_siendo_desplegado. Después de que la pantalla renueva el último pixel en un intervalo de renovación de cuadro y antes de que empiece a renovar el primer pixel en el siguiente intervalo de renovación de cuadro, el proceso de actualización de pantalla lleva a cabo la operación de ajustar está_siendo_renovado a recién_rellenado. El Paquete de Flujo de Video contiene un par de Bits de Actualización de Pantalla que especifican la memoria intermedia de cuadro donde los datos de pixel se van a escribir. El Paquete de Capacidad del Cliente tiene tres bits adicionales que indican qué combinaciones de los Bits de Actualización de Pantalla están soportadas en el cliente. En muchos casos, las imágenes generadas por computadora necesitan ser actualizadas de manera incremental con base en la entrada de usuario o derivadas de información recibida de una red de computadora. Las combinaciones de Bit de Actualización de Pantalla "00" y "11" soportan este modo de operación haciendo que los datos de pixel sean escritos a la memoria intermedia de cuadro que está siendo desplegado o a ambas memorias intermedias de cuadro . Al admitir imágenes de video, la figura 92 ilustra cómo imágenes de video son desplegadas usando un par de memorias intermedias de cuadro cuando datos de video son transmitidos en el enlace de MDDI con los Bits de Actualización de Pantalla iguales a "01". Después de que un límite de cuadro de medios es detectado en el enlace de MDDI, el proceso de renovación de pantalla empezará a renovar desde la siguiente memoria intermedia de cuadro cuando el proceso de renovación para el cuadro que está siendo renovado actualmente esté completado. Una suposición importante relacionada con la figura 92 es que la imagen es recibida del aparato central como un flujo continuo de pixeles que son transmitidos en el mismo orden que el cliente usa para leer los pixeles de la memoria intermedia de cuadro para renovar la pantalla (usualmente superior-izquierda, leyendo hilera por hilera, a la esquina inferior-derecha de la pantalla. Este es un detalle importante en los casos donde las operaciones de Renovación de Pantalla y Transferencia de Imagen hacen referencia a la misma memoria intermedia de cuadro . Es necesario que el índice de cuadro de renovación de pantalla sea mayor al índice de cuadro de transferencia de imagen para evitar desplegar imágenes parciales . La figura 93 muestra cómo puede ocurrir la fragmentación de imagen con un índice de renovación de pantalla lento, esto es, la renovación de pantalla es más lento que la transferencia de imagen. En una imagen que contiene una combinación de imágenes de gráficos por computadora e imágenes de video en movimiento, los datos de pixel de video pudieran ocupar una pequeña porción de un cuadro de medios . Esto podía ser significativo en situaciones donde la operación de renovación de pantalla y la transferencia de imagen hacen referencia a la misma memoria intermedia de cuadro. Estas situaciones se muestran por medio de un sombreado con tramado en la figura 94, donde los pixeles leídos de la memoria intermedia para renovar la pantalla pudieran ser- los pixeles escritos a la memoria intermedia hace dos cuadros, o pueden corresponder al cuadro que es inmediatamente escrito a la misma memoria intermedia de cuadro . El uso de tres memorias intermedias de cuadro en el cliente resolverá problema de la ventana pequeña de contienda para acceso a una memoria intermedia de cuadro como se muestra en la figura 95. No obstante, existe aún un problema si el índice de renovación de pantalla es menor al índice de cuadro de medios en el enlace de MDDI como se muestra en la figura 96. El uso de una sola memoria intermedia para imágenes de video en movimiento es un poco problemático como se muestra en la figura 97. Con la renovación de pantalla más rápido que la transferencia de imagen en la memoria intermedia, la imagen que está siendo renovada algunas veces mostrará la porción superior del cuadro que está siendo escrito y la porción inferior de la imagen será el cuadro anteriormente transferido. Con la renovación de pantalla más rápido que la transferencia de imagen (el modo de operación preferido) habrá casos más frecuentes de cuadros que muestran una imagen dividida similar. XVII . Tabla de valores de retardo El Paquete de Parámetros de Retardo de Procesamiento de Paquete usa una función de búsqueda de tabla para calcular el retardo previsto para procesar ciertos comandos en el cliente. Los valores en la tabla incrementan en una manera logarítmica para proveer un rango dinámico muy amplio de valores de retardo. Una tabla ejemplar de valores de retardo útiles para implementar modalidades de la invención se encuentra en el cuadro XX que aparece a continuación, con valores de índice correspondientes contra valores de retardo.

Cuadro XX 0 — O retardo 37 - 1.5ns 74 - 51ns lll-1.8us 148-62us 185-2.2ms 222-75ms 1 - 46ps 38 - 1.6ns 75 - 56ns 112-2.0us 149 - 68us 186-2.4ms 223 - 83ms 2-Slps 39 - 1.8ns 76 - 62ruj 113-2.2us 150-75us 187-2.6ms 224 - 91ms 3 - 56ps 40-2.0ns 77 - 68ns 114-2.4us 151-83us lS8-2Jms 225 - lOOms 4 - 62ps 41-2.2ns 78-75ns 115-2.6us 152-9 ?s 189-3.2ms 226-llOms •68ps 42 - 2.4ns 79-83ns 116-2.9us 153 - lOOus 190-3.5ms 227-120ms 6-75ps 43-2.6ns 80 - 1us 117-3.2us 154-llOus 191-3.8ms 228 - 130ms 7 - 83ps 44 - 2.9ns 81 - lOOns 118-3.5us 155 - 120us 192-4.2rps 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.1ms 231-180ms 10-UOps 47-3.8ns 84-130ns 121-4.6U8 158 - 160us 195 - 5.6ms 232-200ms 11 - 120ps 48-4.2ns 85-150ns 122-5.1VJS 159-180us 196 - 6.2ms 233 - 220ms 12 - 130ps 49-4.6ns 86-160ns 123 - 5.6us 160-200us 197 - 6.8ms 234-240me 13 - 150ps 50-5.1ns 87-180ns 124-6.2us 161-220us 198 - 7.5ms 235 - 260ms 14-160ps 51-5.6ns 88-200ps 125 - 6.8us 162-240us 199 - 8.3ms 236 - 290ms 15-180ps 52 - 6.2ps 89-220ns 126-7.5US 163-260us 200-9.1ms 237-320ms 16-200ps 53 - 6.8ns 90-240ns 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.1ns 93-320ns 130-ll s 167-380us 204 - 13ms 241-460ms 20-290ps 57 - lOns 94-350ns 131 - 12us 168-420us 205 - 15ms 242 - 510ms 21-320ps 58-11GJS 95-380ns 132-13us 169 -460us 206 - 16ms 243 - 560ms 22-350ps 59 - 12ps 96-420ns 133 - 15us 170-510us 207-18ms 244-620ms 23 - 380ps 60 - 13ns 97-460ns 134-16us 171-560us 208-20ms 245 - 680ms 24 - 420ps 61 - 15ns 98-510ns 135 - 18us 172-620us 209 - 22ms 246 - 750ras 2S-460ps 62 - 16ns 99 -560ns 136-20us 173 - 680us 210-24ms 247 - 830ms 26 - 510ps 63 - 18ns 100 - 620ns 137-22us 174-750us 211-26ms 248-910ms 27 - 560ps 64-20ns 101 - 680ns 138-24us 175 - 830us 212-29ms 249-1.0seg 28 - 620ps 65 - 22ns 102-750pß 139 - 26us 176-910us 213 - 32ms 250-l.lseg 29 - 680ps 66-24ns 103-830ns 140-29us 177-1.0ms 214-35ms 251-1 2seg 30 - 7S0ps 67-26ns 104-910ns 141-32us 178 - l.lms 215 - 38ms 252-1 .3seg 31-830ps 68-29ps 105 - l.Ous 142-35US 179-1.2ms 216-42ms 253-1 5seg 32-910ps 69 - 32ns 106 - l.lus 143-38us 180-1.3 s 217-46ms 254-1.6s 33 - l.Ons 70-35ns 107 - 1.2us 144-42us 181 - 1.5ms 21S-51p?s 255 - indefinido 34-l.lns 71-38?S 108-1.3us 145-46us 182 - 1.6ms 219 - 56ras 35-1.2ns 72-42ns 109 - 1.5us 146-51us 183 - 1.8ms 220 - 62ms 36 - 1.3ns 73-46ns 110-1.6us 147 - 56 s 184-2.0ms 221 - 68ms El retardo es calculado llevando a cabo una búsqueda de tabla usando el parámetro especificado como un índice en la tabla. Esto significa que un retardo es igual a la Tabla de Procesamiento de Paquete (índice) . Por ejemplo: si uno de los parámetros del Elemento de Lista de Parámetros de Retardo es un valor de 8 bits igual a 134, entonces el retardo es igual a la Tabla de Procesamiento de Paquete (134) que es 16 µseg. El valor 255 indica que el tiempo de terminación de comando no puede ser determinado mediante cálculo, y que el aparato central verificará las Banderas de Ocupado de Gráficos en el Paquete de Solicitud y Estado de Cliente o Parámetro de Control MCCS VCP B7h. En algunos casos este retardo es multiplicado por la altura, ancho, o número de pixel es en la imagen de destino y se agrega a otros retardos para calcular el retardo de procesamiento de paquete general.

XVIII Soporte de múltiples clientes La versión de protocolo actual no parece soportar directamente múltiples aparatos cliente. No obstante, la mayoría de los paquetes contienen un campo de ID de Cliente reservado que se puede usar para dirigir aparatos cliente específicos en un sistema con múltiples clientes. Actualmente, para muchas aplicaciones esta ID de cliente o estas ID' s de cliente se ajustan para ser cero. El paquete de cabecera de subcuadro contiene también un campo para indicar si el aparato central soporta o no un sistema de múltiples clientes. Por lo tanto, existe una manera en la cual múltiples aparatos clientes probablemente estarían conectados y serían dirigidos en futuras aplicaciones de la interfase o protocolo MDD para ayudar a los diseñadores de sistemas a planificar una compatibilidad futura con múltiples aparatos centrales de cliente y clientes . En sistemas que tienen múltiples clientes resulta útil que los clientes estén conectados al aparato central usando una cadena margarita de clientes, o usando concentradores, como se muestra en la figura 98, o usando 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 antes discutidos para los diversos paquetes usados para implementar la arquitectura y protocolo para modalidades de la invención, contenidos de campo u operaciones más detalladas se presentan aquí para algunos de los tipos de paquetes . Estos se presentan aquí parar aclarar aún más su uso u operaciones respectivos para permitir a los expertos en la técnica comprender más fácilmente y hacer uso de la invención para una variedad de aplicaciones . Solamente unos pocos de los campos no discutidos aún se discuten aquí de manera adicional. 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 tomar como limitaciones de la invención, sino que representan una o más modalidades útiles para implementar la interfase y protocolo, y no todas las modalidades necesitan ponerse en práctica juntas o al mismo tiempo. Se pueden usar otros valores en otras modalidades para obtener la presentación deseada de datos o resultados de transferencia de índice de datos, como entenderán los expertos en la técnica.

A. Para paquetes de flujo de video En una modalidad, el campo de Atributos de Datos de Pixel (2 bytes) tiene una serie de valores de bit que son interpretados como sigue. Los bits 1 y 0 seleccionan cómo son encaminados los datos de pixel de visualización. Para valores de ?ll' los datos de pixel son desplegados a o para ambos ojos, para valores de bit 10', los datos de pixel son encaminados únicamente al ojo izquierdo y para valores de bit ?01', los datos de pixel son encaminados solamente al ojo derecho, y para valores de bit de 00', los datos de pixel son encaminados a una pantalla alterna como puede ser especificado por los bits 8 al 11 que se discuten más adelante. Si la pantalla primaria en o que está siendo usada u operada por un cliente no soporta imágenes en estéreo o representación de imágenes en alguna forma, entonces estos comandos no pueden ser implantados de manera efectiva para tener un impacto como desea la pantalla. En esta situación o configuración el cliente debe encaminar los datos de pixel a una pantalla primaria sin importar los valores de bit o para cualquiera de las combinaciones de bit ?01', ?10' o ?ll' , puesto que los comandos o control resultantes no serán implementados por la pantalla. Se recomienda, pero no es requerido por las modalidades, que el valor ?ll' se use para dirigir la pantalla primaria en los clientes que no soportan capacidad de visualización estéreo. El bit 2 indica si los Datos de Pixel están presentados o no en un formato entrelazado, donde un valor de ?0' significa que los datos de pixel están en formato progresivo estándar, y que el número de hilera (coordenada Y de pixel) es incrementado en 1 al avanzar de una hilera a la siguiente. Cuando este bit tiene un valor de ?l', los datos de pixel están en formato entrelazado y el número de hilera es incrementado en 2 al avanzar de una hilera a la siguiente. El bit 3 indica que los datos de pixel están en formato de pixel alterno. Esto es similar al modo de entrelazado estándar habilitado por el bit 2, pero el entrelazado es vertical en lugar de horizontal. Cuando el bit 3 es y Q ' , los Datos de Pixel están en el formato progresivo estándar y el número de columna (coordenada X de pixel) es incrementado en 1 a medida que cada pixel consecutivo es recibido. Cuando el bit 3 es ?l' , los Datos de Pixel están en formato de pixel alterno y el número de columna es incrementado en 2 a medida que cada pixel es recibido. El bit 4 indica si los datos de Pixel están relacionados o no con una pantalla o una cámara, como donde datos están siendo transferidos a o desde una pantalla interna para un teléfono inalámbrico o aparato similar o incluso una computadora portátil, u otros dispositivos como se discute anteriormente, o los datos están siendo transferidos a o desde una cámara incorporada en o directamente acoplada al dispositivo. Cuando el bit 4 es 0', los datos de Pixel están siendo transferidos a o desde una memoria intermedia de cuadro de visualización. Cuando el bit 4 es l' , los datos de Pixel están siendo transferidos a o desde una cámara o dispositivo de video de algún tipo, tales dispositivos son bien conocidos en la técnica. El bit 5 se usa para indicar cuando los datos de pixel contienen la siguiente hilera consecutiva de pixeles en la pantalla. Esto se considera el caso cuando el bit 5 se ajusta igual a ?l' . Cuando el bit 5 se ajusta a l' entonces los parámetros de Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, Inicio X e Inicio Y no están definidos y son ignorados por el cliente. Cuando el bit 15 se ajusta a un nivel de uno lógico, esto indica que los datos de pixel en este paquete son la última hilera de pixeles en la imagen. El bit 8 del campo de Indicadores de Capacidad de Características del Cliente del Paquete de Capacidad del Cliente indica si esta característica está soportada. Los bits 7 y 6 son Bits de Actualización de Pantalla que especifican una memoria intermedia de cuadro donde los datos de pixel se van a escribir. Los efectos más específicos se discuten en otra parte. Para valores de bit de ?01', los datos de Pixel se escriben a la memoria intermedia de imagen fuera de línea. Para valores de ?00' , los datos de Pixel se escriben a la memoria intermedia de imagen usada para renovar la pantalla. Para valores de bit de ?ll' , los datos de Pixel se escriben a todos las memorias intermedias de imagen. Los valores de bit o combinación de ?10' es tratada como un valor o designación inválido y los datos de Pixel son ignorados y no son escritos a ninguno de las memorias intermedias de imagen. Este valor puede tener uso para aplicaciones futuras de la interfase . Los bits 8 al 11 forman un entero sin signo de 4 bits que especifica una pantalla o lugar de pantalla alterno donde los datos de pixel se van a encaminar. Los bits 0 y 1 se ajustan igual a 00' para que el cliente de pantalla interprete los bits 8 al 11 como un número de pantalla alterna. Si los bits 0 y 1 no son iguales a ?00', entonces los bits 8 al 11 se ajustan a niveles de cero lógico. Los bits 12 al 14 están reservados para uso futuro y generalmente se ajustan a niveles de cero lógico. El bit 15, como se discutió, se usa junto con el bit 5, y ajustar el bit 15 a uno lógico indica que la hilera de pixeles en el campo de Datos de Pixel es la última hilera de pixeles en un cuadro de datos . El siguiente Paquete de Flujo de Video que tiene el bit 5 ajustado a uno lógico corresponderá a la primera hilera de pixeles del siguiente cuadro de video. Los campos de Inicio X e Inicio Y de 2 bytes especifican las coordenadas X y Y absolutas del punto (inicio X, inicio Y) para el primer pixel en el campo de Datos de Pixel. Los campos de Borde Izquierdo X y Borde Superior Y de 2 bytes especifican la coordenada X del borde izquierdo y coordenada Y del borde superior de la ventana de pantalla rellenada por el campo de Datos de Pixel, mientras que los campos de Borde Derecho X y- Borde Inferior Y especifican la coordenada X del borde derecho, y la coordenada Y del borde inferior de la ventana que está siendo actualizada. El campo de Conteo de Pixeles (2 bytes) especifica el número de pixeles en el campo de Datos de Pixel más adelante . El campo de CRC de Parámetro (2 bytes) contiene un CRC de todos los bytes de la Longitud de Paquete al Conteo de Pixeles. Si este CRC no verifica, entonces el paquete completo es desechado. El campo de Datos de Pixel contiene la información de video en bruto que se va a desplegar y la cual está formateada en la manera descrita por el campo de Descriptor de Formato de Datos de Video. Los datos son transmitidos una "hilera" a la vez como se discute en otra parte. Cuando el bit 5 del campo de Atributos de Datos de Pixel se ajusta a nivel lógico uno, entonces el campo de Datos de Pixel contiene exactamente una hilera de pixeles, donde el primer pixel es transmitido correspondiendo con el pixel de la extrema izquierda y el último pixel es transmitido correspondiendo al pixel de la extrema derecha. El campo de CRC de Datos de Pixel (2 bytes) contiene un CRC de 16 bits solamente de los Datos de Pixel. Si una verificación de CRC de este valor falla, entonces los Datos de Pixel se pueden seguir usando pero el conteo de errores de CRC es incrementado.

B. Para paquetes de flujo de audio En una modalidad, el campo de ID de Canal de Audio (1 byte) usa un valor de entero sin signo de 8 bits para identificar un canal de audio particular al cual datos de audio son enviados por el aparato cliente. Los canales de audio físicos son especificados en o mapeados a canales físicos por este campo como valores de 0, 1, 2, 3, 4, 5, 6 o 7 los cuales indican los canales anterior izquierdo, anterior derecho, posterior izquierdo, posterior derecho, centro anterior, altavoz para infragraves, envolvente izquierdo y envolvente derecho, respectivamente. Un valor de ID de canal de audio de 254 indica que el flujo único de muestras de audio digital es enviado tanto al canal anterior izquierdo como al canal anterior derecho. Esto simplifica las comunicaciones para aplicaciones tales como donde se usa una diadema estéreo para comunicación de voz, se usan aplicaciones de mejora de productividad en un PDA, u otras aplicaciones donde una simple Inferíase de Usuario genera tonos de advertencia. Los valores para el campo de ID que varían de 8 a 253, y 255 están reservados actualmente para usar donde nuevos diseños desean designaciones adicionales, como es anticipado por los expertos en la técnica. El campo de Reservado 1 (1 byte) generalmente está reservado para uso futuro y tiene todos los bits en este campo ajustados a cero; Una función de este campo es hacer que todos los campos de 2 bytes subsiguientes se alineen a una dirección de palabra de 16 bits y hacer que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits. El campo de Conteo de Muestras de Audio (2 bytes) específica 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 empaquetado de datos de audio. En una modalidad, el formato generalmente empleado es para Bits 4 al 0 para definir el número de bits por muestra de audio PCM. El bit 5 especifica entonces si las muestras de Datos de Audio Digitales están o no empaquetadas . Como se mencionó anteriormente, la figura 12 ilustra la diferencia entre muestras de audio empaquetadas y alineadas por bytes . 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 interfase, y un valor de ?l' indica que cada muestra de audio PCM consecutiva está empaquetada contra la muestra de audio anterior. Este bit es efectivo solamente cuando el valor definido en los bits 4 al 0 (el número de bits por muestra de audio PCM) no es un múltiplo de ocho. Los bits 7 al 6 están reservados para uso donde los diseños del sistema desean designaciones adicionales y generalmente se ajustan a un valor de cero. El campo de índice de Muestra de Audio (1 byte) especifica el índice de muestra PCM de audio. El formato empleado es para un valor de 0 para indicar un índice de 8,000 muestras por segundo (sps), un valor de 1 indica 16,000 sps., un valor de 2 para 24,000 sps, valor de 3 para 32,000 sps, valor de 4 para 40,000 sps, valor de 5 para 48,000 sps, valor de 6 para 11,025 sps, valor de 7 para 22,050 sps, y valor de 8 para 44,100 sps, respectivamente, donde los valores de 9 al 255 están reservados para uso futuro, así que actualmente están ajustados a cero. El campo de CRC de Parámetro (2 bytes) contiene un CRC de 16 bits de todos los bytes de la Longitud de Paquete al índice de Muestra de Audio. Si este CRC no verifica de manera apropiada, entonces el paquete completo es desechado. El campo de Datos de Audio Digitales contiene las muestras de audio en bruto que se van a reproducir, y usualmente está en forma de un formato lineal como enteros sin signo. El campo de CRC de Datos de Audio (2 bytes) contiene un CRC de 16 bits de solamente los Datos de Audio. Si este CRC no verifica, entonces los Datos de Audio se pueden usar todavía, pero el conteo de errores de CRC es incrementado .

C. Para paquetes de flujo definido por el usuario En una modalidad, el campo de Número de ID de Flujo de 2 bytes se usa para identificar un flujo definido por el usuario particular. El contenido de los campos de Parámetros de Flujo y Datos de Flujo, son típicamente definidos por el fabricante del equipo de MDDI. El campo de CRC de Parámetro de Flujo de 2 bytes contiene un CRC de 16 bits de todos los bytes de los parámetros de flujo empezando desde la Longitud de Paquete al byte de Codificación de Audio. Si este CRC no verifica, entonces el paquete completo es desechado. Tanto el campo de Parámetros de Flujo como el campo de CRC de Parámetro de Flujo pueden ser desechados si no son necesitados por una aplicación final de la interfase MDD, esto es, se consideran opcionales. El campo de CRC de Datos de Flujo de 2 bytes contiene un CRC de solamente los Datos de Flujo. Si este CRC no verifica en forma apropiada, entonces el uso de los Datos de Flujo es opcional, dependiendo de los requerimientos de la aplicación. El uso del contingente de datos de flujo en el CRC es bueno, por lo general requiere que los datos de flujo sean almacenados en una memoria intermedia hasta que se confirme que el CRC es bueno. El conteo de errores de CRC es incrementado si el CRC no verifica.

D. Para paquetes de mapa de colores El campo de ID de Cliente h de 2 bytes contiene información o valores que están reservados para una ID de Cliente, como se usa anteriormente. Debido a que este campo está generalmente reservado para uso futuro, el valor actual se ajusta a cero, ajusfando los bits a 0' . El campo de Conteo de Elementos de Mapa de Colores de 2 bytes usa valores para especificar el número total de elementos de mapa de colores de 3 bytes que están contenidos en el campo de Datos de Mapa de Colores, o las entradas de tabla de mapa de colores que existen en los Datos de Mapa de Colores en este paquete. En esta modalidad, el número de bytes en los Datos de Mapa de Colores es 3 veces el Conteo de Elementos de Mapa de Colores . El Conteo de Elementos de Mapa de Colores se ajusta igual a cero para no enviar datos de mapa de colores. Si el Tamaño de Mapa de Colores es cero, entonces un valor de Desplazamiento de Mapa de Colores generalmente se sigue enviando pero es ignorado por la pantalla. El campo de Desplazamiento de Mapa de Colores (4 bytes) especifica el desplazamiento de los Datos de Mapa de Colores en este paquete desde el inicio de la tabla de mapa de colores en el aparato cliente. Un campo de CRC de Parámetro de 2 bytes contiene un CRC de todos los bytes de la Longitud de Paquete al byte de Codificación de Audio. Si este CRC no verifica, entonces todo el paquete es desechado. Para el campo de Datos de Mapa de Colores, el ancho de cada lugar de mapa de colores es especificado por el campo de Tamaño de Elemento de Mapa de Colores, donde en una modalidad la primera parte especifica la magnitud de azul, la segunda parte especifica la magnitud de verde y la tercera parte especifica la magnitud de rojo. El campo de Tamaño de Mapa de Colores especifica el número de elementos de tabla de mapa de colores de 3 bytes que existen en el campo de Datos de Mapa de Colores . Si un solo mapa de colores no puede caber en un Paquete de Formato de Datos de Video y Mapa de Colores, entonces todo el mapa de colores puede ser especificado enviando múltiples paquetes con diferentes Datos de Mapa de Colores y Desplazamientos de Mapa de Colores en cada paquete. El número de bits de azul, verde y rojo en cada elemento de datos de mapa de colores es generalmente el mismo especificado en el campo de Ancho de RVA de Mapa de Colores del Paquete de Capacidad de Pantalla. Un campo de CRC de Datos de Mapa de Colores de 2 bytes contiene un CRC de solamente los Datos de Mapa de Colores. Si este CRC no verifica, entonces los Datos de Mapa de Colores se pueden usar todavía pero el conteo de errores de CRC es incrementado. Cada elemento de datos de mapa de colores se va a transmitir en el orden: azul, verde, rojo, donde el bit menos significativo de cada componente se transmite primero. Los componentes rojo, verde y azul individuales de cada elemento de mapa de colores están empaquetados, pero cada elemento de mapa de colores (el bit menos significativo del componente azul) debe estar alineado por bytes. La figura 100 ilustra un ejemplo de elementos de datos de mapa de colores con 6 bits de azul, 8 bits de verde y 7 bits de rojo. Para este ejemplo, el Tamaño de Elemento de Mapa de Colores en el Paquete de Mapa de Colores es igual a 21, y el campo de Ancho de RVA de Mapa de Colores del Paquete de Capacidad del Cliente es igual a 0x0786.

E . Para paquetes de encapsulación de enlace inverso El campo de CRC de Parámetro (2 bytes) contiene un CRC de 16 bits de todos los bytes de la Longitud de Paquete a la Longitud de Inversión de Sentido. Si este CRC no verifica, entonces el paquete completo es desechado. En una modalidad, el campo de Banderas de Enlace Inverso (1 byte) contiene una serie de banderas para solicitar información del cliente. Si un bit (por ejemplo, el bit 0) se ajusta a un nivel de uno lógico, entonces el aparato central solicita la información especificada de la pantalla usando el Paquete de Capacidad del Cliente. Si el bit se ajusta a un nivel de cero lógico, entonces el aparato central no necesita la información del cliente. Los bits restantes (aquí Bits 1 al 7) están reservados para uso futuro y se ajustan a cero. Sin embargo, se pueden usar más bits como se desee para establecer banderas para el enlace inverso. El campo de Divisor de índice Inverso (1 byte) especifica el número de ciclos de MDDI_Stb que ocurren con relación al reloj de datos de enlace inverso. El reloj de datos de enlace inverso es igual al reloj de datos de enlace hacia adelante dividido entre dos veces el Divisor de índice Inverso. El índice de datos de enlace inverso está relacionado con el reloj de datos de enlace inverso y el Tipo de Inferíase en el enlace inverso. En esta modalidad, para una interfase Tipo 1 el índice de datos inverso es igual al reloj de datos de enlace inverso, para interfases Tipo 2, Tipo 3 y Tipo 4 los índices de datos inversos son iguales a dos veces, cuatro veces y ocho veces el reloj de datos de enlace inverso, respectivamente. El campo de Todo Cero 1 contiene un grupo de bytes, aquí 8, que se ajusta igual a cero en valor ajusfando los bits a un nivel de cero lógico, y se usa para asegurar que todas las señales MDDI_Datos estén a un nivel de cero lógico durante un tiempo suficiente para permitir al cliente empezar a recuperar el reloj usando solamente MDDI_Stb antes de inhabilitar los excitadores de línea del aparato central durante el campo de Inversión de Sentido 1. En una modalidad, la longitud del campo de Todo Cero 1 es mayor a o igual al número de tiempos de transmisión de byte de enlace hacia adelante en el retardo de ida y vuelta del cable. El campo de Longitud de Inversión de Sentido 1 (un byte) especifica el número total de bytes que son asignados para Inversión de Sentido 1, estableciendo el primer periodo de inversión de sentido. El número de bytes especificado por el parámetro de Longitud de Inversión de Sentido 1 es asignado para permitir que los excitadores de línea de MDDI_Datos en el cliente se habiliten, antes de que los excitadores de línea en el aparato central sean inhabilitados . El cliente habilita sus excitadores de línea de MDDI_Datos durante el bit 0 de Inversión de Sentido 1 y el aparato central inhabilita sus salidas para que estén completamente inhabilitadas antes del último bit de Inversión de Sentido 1. La temporización de los procesos de habilitación del excitador de cliente e inhabilitación del excitador de aparato central son tales • que uno o ambos impulsan las señales MDDI_Datos a un nivel de cero lógico en toda la Inversión de Sentido 1 como es visto por los receptores de línea en el aparato central. La señal MDDI_Stb se comporta como si MDDI_DatosO estuviera a un nivel de cero lógico durante todo el periodo de Inversión de Sentido 1. Una descripción más completa del ajuste de Inversión de Sentido 1 se proporciona anteriormente. El campo de Paquetes de Datos Inversos contiene una serie de paquetes de datos transferidos del cliente al aparato central . El cliente puede enviar paquetes de relleno o impulsar las líneas de MDDI_Datos a un estado o nivel de cero lógico cuando no tiene datos que enviar al aparato central. En esta modalidad, si las líneas de MDDI_Datos son impulsadas a cero, el aparato central interpretará esto como un paquete con una longitud cero (no es una longitud válida) y el aparato central no aceptará paquetes adicionales del cliente por la duración del Paquete de Encapsulación de Enlace Inverso actual . El campo de Longitud de Inversión de Sentido 2 (1 byte) especifica el número total de bytes que son asignados para Inversión de Sentido 2, para establecer un segundo periodo de inversión de sentido. El número de bytes especificado por el parámetro de Longitud de Inversión de Sentido es asignado para permitir que los excitadores de línea MDDI_Datos en el aparato central se habiliten antes de que los excitadores de línea en el cliente sean inhabilitados. El aparato central habilita sus excitadores de línea MDDI_Datos durante el bit 0 del primer byte en Inversión de Sentido 2, y el cliente inhabilita sus salidas de manera que estén completamente inhabilitadas antes del último bit de Inversión de Sentido 2. La temporización de los procesos de inhabilitación del excitador de cliente y habilitación del excitador de aparato central son tales que uno o ambos impulsan las señales MDDI_Datos a un nivel de cero lógico en todo, o durante el periodo de Inversión de Sentido 2 completo, como es visto por los receptores de línea en el aparato central. La señal MDDI_Stb se comporta como si MDDI_DatosO estuviera a un nivel de cero lógico durante sustancialmente todo el periodo de Inversión de Sentido 2. Una descripción del ajuste de Inversión de Sentido 2 se proporciona anteriormente . El campo de Paquetes de Datos Inversos contiene una serie de paquetes de datos transferidos del cliente al aparato central. Como se menciona anteriormente, paquetes de Relleno son enviados para llenar el espacio restante que no es usado por otros tipos de paquete. El campo de Todo Cero 2 contiene un grupo de bytes (8 en esta modalidad) , que se ajusta igual a cero en valor ajusfando los bits a un nivel de cero lógico, y se usa para asegurar que todas las señales MDDI_Datos estén a un nivel de cero lógico durante un tiempo suficiente para permitir al cliente empezar a recuperar el reloj usando tanto MDDI_DatosO como MDDI_Stb después de habilitar los excitadores de línea del aparato central después el campo de Inversión de Sentido 2.

F. Para paquetes de capacidad del cliente Como se ilustra para una modalidad, el campo de Versión de Protocolo usa 2 bytes para especificar una versión de protocolo usada por el cliente. La versión inicial se ajusta actualmente igual a uno, y se cambiará con el tiempo a medida que se generen nuevas versiones como sería conocido, mientras que el campo de Versión de Protocolo Mínima usa 2 bytes para especificar la versión de protocolo mínima que el cliente puede emplear o interpretar. En este caso, un valor cero es también un valor válido. El campo de Capacidad de índice de Datos (2 bytes) especifica el índice de datos máximo que el cliente puede recibir en cada par de datos en el enlace hacia adelante de la interfase, y se especifica en forma de megabits por segundo (Mbps) . El campo de Capacidad de Tipo de Interfase (1 byte) especifica los tipos de interfase que están soportados en los enlaces hacia adelante e inverso. Un bit ajustado a ?l' significa que un tipo de interfase especificado está soportado, y un bit ajustado a ?0' significa que el tipo especificado no está soportado. Los aparatos centrales y clientes deben soportar por lo menos el Tipo 1 en las líneas hacia adelante e inversa. No hay requerimiento de soportar un rango contiguo de tipos de interfase. Por ejemplo, sería perfectamente válido soportar solamente el Tipo 1 y Tipo 3, pero no Tipo 3 y Tipo 4 en una interfase. Igualmente no es necesario que los enlaces hacia adelante e inverso operen con el mismo tipo de interfase. No obstante, cuando un enlace sale de la hibernación tanto el enlace hacia adelante como el enlace inverso deben comenzar a operar en modo Tipo 1, hasta que otros modos puedan ser negociados, seleccionados o de otra manera aprobados para uso tanto por el aparato central como por el cliente . Las interfases soportadas se indican en una modalidad seleccionando Bit 0, Bit 1 o Bit 2 para seleccionar un modo ya sea Tipo 2 (2 bits) , Tipo 3 (4 bits) o Tipo 4 (8 bits) en el enlace hacia adelante, respectivamente; y Bit 3, Bit 4 o Bit 5 para seleccionar un modo ya sea Tipo 2, Tipo 3 o Tipo 4 en el enlace inverso, respectivamente; los Bits 6 y 7 están reservados y generalmente se ajustan a cero en este momento. Los campos de Ancho y Altura de Mapa de Bits, aquí cada uno es de 2 bytes, especifican el ancho y altura del mapa de bits, respectivamente, en pixeles.

El campo de Capacidad Monocroma (1 byte) se usa para especificar el número de bits de resolución que pueden ser desplegados en un formato monocromo. Si una pantalla no puede usar un formato monocromo, entonces este valor se ajusta a cero. Los bits 7 al 4 están reservados para uso futuro y, por ende, se ajustan a cero. Los bits 3 al 0 definen el número máximo de bits de escala de grises que pueden existir para cada pixel. Estos cuatro bits hacen posible especificar valores de 1 a 15 para cada pixel. Si el valor es cero entonces el formato monocromo no está soportado por la pantalla. El campo de Capacidad Bayer usa 1 byte para especificar el número de bits de resolución, grupo de pixeles y orden de pixeles que pueden ser transferidos en formato Bayer. Si el cliente no puede usar el formato Bayer, entonces este valor es cero. El campo de Capacidad Bayer se compone de los siguientes valores : los bits 3 al 0 definen el número máximo de bits de intensidad que existen en cada pixel, mientras que los bits 5 al 4 definen el patrón de grupo de pixeles que es requerido, mientras que los bits 8 al 6 definen el orden de pixeles que es requerido; los bits 14 al 9 están reservados para uso futuro y generalmente se ajustan a cero por el momento. El bit 15, cuando se ajusta a nivel de uno lógico indica que el cliente puede aceptar datos de pixel Bayer ya sea en formato empaquetado o desempaquetado. Si el bit 15 se ajusta a cero, esto indica que el cliente puede aceptar datos de pixel Bayer únicamente en formato desempaquetado.

El campo de Capacidad de Mapa de Colores (3 bytes) especifica el número máximo de elementos de tabla que existen en la tabla de mapa de colores en la pantalla.

Si la pantalla no puede usar el formato de mapa de colores, entonces este valor se ajusta a cero. El campo de Capacidad RVA (2 bytes) especifica el número de bits de resolución que pueden ser desplegados en formato RVA. Si la pantalla no puede usar el formato RVA, entonces este valor es igual a cero. La palabra Capacidad RVA se compone de tres valores sin signo separados : los Bits 3 al 0 definen el número máximo de bits de azul, los Bits 7 al 4 definen el número máximo de bits de verde, y los Bits 11 al 8 definen el número máximo de bits de rojo en cada pixel. Actualmente, los Bits 14 al 12 están reservados para uso futuro y generalmente se ajustan a cero. El bit 15, cuando se ajusta a un nivel de uno lógico, indica que el cliente puede aceptar datos de pixel RVA en formato ya sea empaquetado o desempaquetado. Si el bit 15 se ajusta a un nivel de cero lógico, esto indica que el cliente puede aceptar datos de pixel RVA solamente en formato desempaquetado . El campo de Capacidad Y Cr Cb (2 bytes) especifica el número de bits de resolución que pueden ser desplegados en formato Y Cr Cb. Si la pantalla no puede usar el formato Y Cr Cb, entonces este valor se ajusta igual a cero. La palabra Capacidad Y Cr Cb se compone de tres valores sin signo separados donde: los Bits 3 al 0 definen el número máximo de bits en la muestra Cb; los bits 7 al 4 definen el número máximo de bits en la muestra Cr; los bits 11 al 8 definen el número máximo de bits en la muestra Y; y los bits 15 al 12 están reservados actualmente para uso futuro y se ajustan a cero. El campo de Capacidad de Características de Cliente usa 4 bytes que contienen una serie de banderas que indican características específicas en el cliente que están soportadas. Un bit ajustado a un nivel de uno lógico indica que la capacidad está soportada, mientras que un bit ajustado a un nivel de cero lógico indica que la capacidad no está soportada. En una modalidad, el valor para el bit 0 indica si el Paquete de Transferencia de Bloque de Mapa de Bits (paquete tipo 71) está o no soportado. El valor para los Bits 1, 2 y 3 indican si el Paquete de Relleno de Área de Mapa de Bits (paquete tipo 72), Paquete de Relleno de Patrón de Mapa de Bits (paquete tipo 73) o Paquete de Canal de Datos de Enlace de Comunicación (paquete tipo 74), respectivamente, están o no soportados. El valor para el Bit 4 indica si el cliente tiene o no la capacidad de hacer un color transparente usando el Paquete de Habilitación de Color Transparente, mientras que los valores para los bits 5 y 6 indican si el cliente puede aceptar datos de video o datos de audio en formato empaquetado, respectivamente, y el valor para el bit 7 indica si el cliente puede o no enviar un flujo de video de enlace inverso desde una cámara. El valor para el bit 8 indica si el cliente tiene o no la capacidad de recibir una línea completa de datos de pixel e ignorar el direccionamiento de pantalla como es especificado por el bit 5 del campo de Atributos de Datos de Pixel del Paquete de Flujo de Video, y el cliente puede también detectar sincronización de cuadros o final de datos de cuadro de video usando el bit 15 del Campo de Atributos de Datos de Pixel. El valor para los bits 11 y 12 indican cuando el cliente se está comunicando ya sea con un dispositivo señalador y puede enviar y recibir Paquetes de Datos de Dispositivo Señalador, o con un teclado y puede enviar y recibir Paquetes de Datos de Teclado, respectivamente. El valor para el bit 13 indica si el cliente tiene o no la capacidad de ajustar uno o más parámetros de audio o video soportando los paquetes de Característica VCP: Paquete de Característica VCP de Solicitud, Paquete de Respuesta de Característica VCP, Paquete de Característica VCP de Ajuste, 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 pixel en la memoria intermedia de cuadro de pantalla fuera de línea. Si este bit se ajusta a un nivel de uno lógico, entonces los Bits de Actualización de Pantalla (bits 7 y 6 del campo de Atributos de Datos de Pixel del Paquete de Flujo de Video) se - pueden ajustar a los valores 01' . El valor para el bit 15 indica cuando el cliente tiene la capacidad de escribir datos de pixel solamente en la memoria intermedia de cuadro de pantalla actualmente utilizado para renovar la imagen de pantalla. Si este bit se ajusta a uno, entonces los Bits de Actualización de Pantalla (bits 7 y 6 del campo de Atributos de Datos de Pixel del Paquete de Flujo de Video) se pueden ajustar a los valores 00' . El valor para el bit 16 indica cuando el cliente tiene la capacidad de escribir datos de pixel de un solo Paquete de Flujo de Video en todas las memorias intermedias de cuadro de pantalla. Si este bit se . ajusta a uno, entonces los Bits de Actualización de Pantalla (bits 7 y 6 del campo de Atributos de Datos de Pixel del Paquete de Flujo de Video) se pueden ajustar al valor ?ll' . El valor para el bit 17 indica cuando un cliente tiene la capacidad de responder al Paquete de Estado Específico de Solicitud, el valor para el bit 18 indica cuando el cliente tiene la capacidad de responder al Paquete de Medición de Retardo de Ida y Vuelta, y el valor para el bit 19 indica cuando el cliente tiene la capacidad de responder al Paquete de Calibración de Sesgo de Enlace Hacia Adelante. 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álido. El cliente indica una capacidad de regresar un estado adicional en el campo de Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido como se describe en otra parte. El valor para el bit 22 indica si un cliente tiene o no la capacidad de responder al Paquete de Acceso a Registros. Los bits 9 al 10, 20 y 23 al 31 están actualmente reservados para uso futuro o designaciones alternativas útiles para los diseñadores del sistema y por lo general se ajusta igual a cero. El campo de Capacidad de índice de Cuadro de Video de Pantalla (1 byte) especifica la capacidad de actualización de cuadro de video máxima de la pantalla en cuadros por segundo. Un aparato central puede elegir actualizar la imagen a un índice más lento que el valor especificado en este campo. El campo de Profundidad de Búfer de Audio (2 bytes) especifica la profundidad la memoria intermedia elástica en una Pantalla que está dedicada a cada flujo de audio . El campo de Capacidad de Canal de Audio (2 bytes) contiene un grupo de banderas que indican qué canales de audio están soportados por el cliente o dispositivo conectado al cliente. Un bit ajustado a uno indica que el canal está soportado y un bit ajustado a cero indica que ese canal no está soportado. Las posiciones de bit son asignadas a los diferentes canales, por ejemplo, las posiciones de bit 0, 1, 2, 3, 4, 5, 6 y 7 en una modalidad, indican los canales anterior izquierdo, anterior derecho, posterior izquierdo, posterior derecho, centro anterior, altavoz para infragraves, envolvente izquierdo y envolvente derecho, respectivamente. Los bits 8 al 14 están actualmente reservados para uso futuro y generalmente se ajustan a cero. En una modalidad, el bit 15 se usa para indicar si el cliente provee soporte para el Paquete de Habilitación de Canal de Audio Hacia Adelante. Si este es el caso, el bit 15 se ajusta a un nivel de uno lógico. Sin embargo, si el cliente no es capaz de inhabilitar canales .de audio como resultado del Paquete de Habilitación de Canal de Audio Hacia Adelante o si el cliente no soporta ninguna capacidad de audio, entonces este bit se ajusta a un nivel o valor de cero lógico. Un campo de Capacidad de índice de Muestra de Audio de 2 bytes, para el enlace hacia adelante, contiene una serie de banderas para indicar la capacidad de índice de muestra de audio del aparato cliente. Las posiciones de bit son asignadas a los diferentes índices como corresponde, tales como bits a 0, 1, 2, 3, 4, 5, 6, 7 y 8 son asignados a 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050 y 44,100 muestras por segundo (SPS) , respectivamente, donde los bits 9 al 15 están reservados para uso futuro o usos de índice alternativos, como se desee, de manera que actualmente están ajustados a 0' . Ajustar un valor de bit para uno de estos bits a ?l' indica que ese índice de muestra particular está soportado, y ajustar el bit a ?0' indica que ese índice de muestra no está soportado. El campo de índice de Subcuadro Mínimo (2 bytes) especifica el índice de subcuadro mínimo en cuadros por segundo. El índice de subcuadro mínimo mantiene el índice de actualización de estado de cliente suficiente para leer ciertos sensores o dispositivos señaladores en el cliente. Un campo de Capacidad de índice de Muestra de Mic de 2 bytes, para el enlace inverso, contiene una serie de banderas que indican la capacidad de índice de muestra de audio de un micrófono en el aparato cliente. Para propósitos de la MDDI, un micrófono del aparato cliente está configurado para soportar en forma mínima por lo menos un índice de 8,000 muestras por segundo. Las posiciones de bit para este campo son asignadas a los diferentes índices donde las posiciones de bit 0, 1, 2, 3, 4, 5, 6, 7 y 8, por ejemplo, se usan 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, donde los bits 9 al 15 están reservados para uso futuro o usos de índice alternativos, como se desee, de manera que actualmente están ajustados a 0' . Ajustar un valor de bit para uno de estos bits a l' indica que ese índice de muestra particular está soportado, y ajustar el bit a 0' indica que ese índice de muestra no está soportado. Si no hay ningún micrófono conectado, entonces cada uno de los bits de Capacidad de índice de Muestra de Mic se ajusta igual a cero.

El campo de Formato de Datos de Teclado (aquí 1 byte) especifica si un teclado ésta o no conectado al sistema de cliente y el tipo de teclado que está conectado. En una modalidad, el valor establecido por los bits 6 al 0 se usa para definir el tipo de teclado que está conectado. Si el valor es cero (0), entonces el tipo de teclado se considera desconocido. Para un valor de 1, se considera que el formato de datos de teclado es un estilo PS-2 estándar. Actualmente los valores en el rango de 2 a 125 no están en uso, están reservados para uso de los diseñadores del sistema e incorporadores de interfase o desarrolladores de producto para definir dispositivos de teclado o dispositivos de entrada específicos para usar con la interfase MDD y clientes o aparatos centrales correspondientes. Un valor de 126 se usa para indicar que el formato de datos de teclado está definido por el usuario, mientras que un valor de 127 se usa para indicar que un teclado no puede ser conectado a este cliente. Además, el bit 7 se puede usar para indicar si el teclado puede o no comunicarse con el cliente. El uso destinado de este bit es indicar cuando el teclado se puede comunicar con el cliente usando un enlace inalámbrico. El bit 7 se ajustaría a nivel de cero si los bits 6 al 0 indican que un teclado no puede ser conectado al cliente. Por consiguiente, para una modalidad, cuando el valor del bit 7 es 0, el teclado y el cliente no se pueden comunicar, mientras que si el valor de 7 es 1, el teclado y el cliente han confirmado que se pueden comunicar entre sí. El campo de Formato de Datos de Dispositivo Señalador (aquí 1 byte) especifica si un dispositivo señalador está o no conectado al sistema del cliente y el tipo de dispositivo señalador que está conectado. En una modalidad, el valor establecido por los bits 6 al 0 se usa para definir el tipo de dispositivo señalador que está conectado. Si el valor es cero (0), entonces el tipo de dispositivo señalador se considera desconocido. Para un valor de 1, se considera que el formato de datos de dispositivo señalador es un estilo PS-2 estándar. Actualmente los valores en el rango de 2 a 125 no están en uso, están reservados para uso de los diseñadores del sistema e incorporadores de interfase o desarrolladores de producto para definir el dispositivo señalador o dispositivos de entrada específicos para usar con la interfase MDD y clientes o aparatos centrales correspondientes. Un valor de 126 se usa para indicar que el formato de datos de dispositivo señalador está definido por el usuario, mientras que un valor de 127 se usa para indicar que un dispositivo señalador no puede ser conectado a este cliente. Además, el bit 7 se puede usar para indicar si el dispositivo señalador puede o no comunicarse con el cliente. El uso destinado de este bit es indicar cuando el teclado se puede comunicar con el cliente usando un enlace inalámbrico. El bit 7 se ajustaría a un nivel de cero si los bits 6 al 0 indican que un dispositivo señalador no puede ser conectado al cliente. Por consiguiente, para una modalidad, cuando el valor del bit 7 es 0, el dispositivo señalador y el cliente no se pueden comunicar, mientras que si el valor de 7 es 1, el dispositivo señalador y el cliente han confirmado que se pueden comunicar entre sí . El campo de Tipo de Protección de Contenido (2 bytes) contiene una serie de banderas que indican el tipo de protección de contenido digital que está soportado por la pantalla. En la actualidad, la posición de bit 0 se usa para indicar cuando DTCP está soportada y la posición 1 se usa para indicar cuando HDCP está soportada, donde las posiciones de bit 2 al 15 están reservadas para usar con otros esquemas de protección como desee o como estén disponibles, de manera que actualmente se ajustan a cero. El campo de Nombre de Fabricante (aquí 2 bytes) contiene la ID de 3 caracteres de EISA del fabricante, empaquetada en tres caracteres de 5 bits de la misma manera que en la especificación VESA EDID. El carácter ?A' Está representado como 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 consecutivos que corresponden a la secuencia alfabética entre ?A' y ?Z' , El bit más significativo del campo de Nombre de Fabricante no se usa y por lo general se ajusta a cero lógico por ahora hasta que se tenga un uso en las implementaciones f turas. Ejemplo: un fabricante representado por la cadena "XYZ" tendría un valor de Nombre de Fabricante de 0x633a. Si este campo no está soportado por el cliente generalmente se ajusta a cero. El campo de Código de Producto usa 2 bytes para contener un código de producto asignado por el fabricante de la pantalla. Si este campo no está soportado por el cliente generalmente se ajusta a cero.

Los campos Reservado 1, Reservado 2 y Reservado 3 (aquí 2 bytes cada uno) están reservados para uso futuro para impartir información. Todos los bits en este campo generalmente se ajustan a nivel de cero lógico. El propósito de tales campos es actualmente hacer que todos los campos de 2 bytes subsiguientes se alineen a una dirección de palabra de 16 bits y hacer que los campos de 4 bytes se alineen a una dirección de palabra de 32 bits. El campo de Número de Serie usa 4 bytes en esta modalidad para especificar el número de serie de la pantalla en forma numérica. Si este campo no está soportado por el cliente generalmente se ajusta a cero. El campo de Semana de Fabricación usa 1 byte para definir la semana de fabricación de la pantalla. Este valor está típicamente en el rango de 1 a 53 si está soportado por el cliente. Si este campo no es soportado por el cliente se ajusta a cero. El campo de Año de Fabricación es 1 byte que define el año de fabricación de la pantalla. Este valor es un desplazamiento del año 1990. Los años en el rango de 1991 a 2245 pueden ser expresados por este campo. Ejemplo, el año 2003 corresponde a un valor de Año de Fabricación de 13. Si este campo no está soportado por el cliente se ajusta a cero . El campo de CRC (aquí 2 bytes) contiene un CRC de 16 bits de todos los bytes en el paquete incluyendo la Longitud de Paquete.

G. Para paquetes de solicitud y estado de cliente El campo de Solicitud de Enlace Inverso (3 bytes) especifica el número de bytes que el cliente necesita en el enlace inverso en el siguiente subcuadro para enviar información al aparato central . El campo de Conteo de Errores de CRC (1 byte) indica cuántos errores de CRC han ocurrido desde el inicio del cuadro de medios . El conteo de CRC es restaurado cuando un paquete de cabecera de subcuadro con un Conteo de Subcuadros de cero es enviado. Si el número real de errores de CRC supera 255, entonces este valor generalmente se satura a 255. El campo de Cambio de Capacidad usa 1 byte para indicar un cambio en la capacidad del cliente. Esto ocurre si un usuario conecta un dispositivo periférico como por ejemplo, un micrófono, teclado o pantalla, o por alguna otra razón. Cuando los bits [7:0] son iguales a 0, entonces la capacidad no cambiado desde que el último Paquete de Capacidad de Cliente fue enviado. Sin embargo, cuando los bits [7:0] son iguales a l a 255, la capacidad ha cambiado. El Paquete de Capacidad del Cliente es examinado para determinar las nuevas características de la pantalla. El campo de Banderas de Ocupado de Cliente usa 2 bytes para indicar que el cliente está realizando una función específica y no está listo para aceptar aún otro paquete relacionado con esa función. Un bit establecido a un nivel o valor de uno lógico indica que la función particular está siendo realizada actualmente por el cliente y que la función relacionada en el cliente está ocupada. Si la función relacionada en el cliente está lista, el bit se ajusta t a cero lógico. El cliente debe regresar un estado de ocupado (bit ajustado a uno) para todas las funciones que no están soportadas en el cliente. En una modalidad, estos bytes son interpretados de acuerdo con la relación: si el bit 0 es un entonces la función de transferencia de bloque de mapa de bits está ocupada, mientras que si el bit 1 es un ?l', entonces una función de relleno de área de mapa de bits está ocupada, y si el bit 2 es un ?l' , entonces una función de relleno de patrón de mapa de bits está ocupada. Actualmente, los bits 3 al 15 permanecen reservados para uso futuro y generalmente se ajustan a un nivel o estado de uno lógico para indicar un estado de ocupado en caso de que estos bits sean asignados en el futuro.

H. Para paquetes de transferencia de bloque de bits Los campos de Valor X y Valor Y de Coordenada Superior Izquierda de Ventana usan 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 usan 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 Ventana usan 2 bytes cada uno para especificar el número de pixeles que la ventana se va a mover de manera horizontal y vertical, respectivamente. Típicamente, estas coordenadas están configuradas de manera tal que los valores positivos para X hagan que la ventana sea movida a la derecha, y los valores negativos causen el movimiento a la izquierda, mientras que los valores positivos para Y hacen que la ventana se mueva hacia abajo y los valores negativos causan movimiento hacia arriba.

I. Para paquetes de relleno de área de mapa de bits Los campos de Valor X y Valor Y de Coordenada Superior Izquierda de Ventana usan 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 rellenar. Los campos de Ancho y Altura de Ventana (2 bytes cada uno) especifican el ancho y la altura de la ventana que se va a rellenar. El campo de Descriptor de Formato de Datos de Video (2 bytes) especifica el formato del Valor de Relleno de Área de Pixel . El formato es el mismo que el mismo campo en el Paquete de Flujo de Video. El campo de Valor de Relleno de Área de Pixel (4 bytes) contiene el valor de pixel que va a ser rellenado en la ventana especificada por los campos antes discutidos. El formato de este pixel está especificado en el campo de Descriptor de Formato de Datos de Video.

J. Para paquetes de relleno de patrón de mapa de bits . Los campos de Valor X y Valor Y de Coordenada Superior Izquierda de Ventana usan 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 rellenar. Los campos de Ancho y Altura de Ventana (2 bytes cada uno) especifican el ancho y la altura de la ventana que se va a rellenar. Los campos de Ancho de Patrón y Altura de Patrón (2 bytes cada uno) especifican el ancho y altura, respectivamente, del patrón de relleno. El campo de Desplazamiento de Patrón Horizontal (2 bytes) especifica un desplazamiento horizontal del patrón de datos de pixel desde el borde izquierdo de la ventana especificada que se va a rellenar. El valor que se está especificando debe ser menor al valor en el Campo de Ancho de Patrón. El campo de Desplazamiento de Patrón Vertical (2 bytes) especifica un desplazamiento vertical del patrón de datos de pixel desde el borde superior de la ventana especificada que se va a rellenar. El valor que está siendo especificado debe ser menor al valor en el campo de Altura de Patrón. El campo de Descriptor de Formato de Datos de Video de 2 bytes especifica el formato del Valor de Relleno de Área de Pixel. La figura 11 ilustra cómo es codificado el Descriptor de Formato de Datos de Video. El formato es el mismo que el mismo campo en el Paquete de Flujo de Video. El campo de CRC de Parámetro (2 bytes) contiene un CRC de todos los bytes de la Longitud de Paquete al Descriptor de Formato de Video. Si este CRC no verifica, entonces todo el paquete es desechado. El campo de Datos de Pixel de Patrón contiene información de video en bruto que especifica el patrón de relleno en el formato especificado por el Descriptor de Formato de Datos de Video. Los datos son empaquetados en bytes y el primer pixel de cada hilera debe estar alineado por bytes . Los datos de patrón de relleno son transmitidos una hilera a la vez . El campo de CRC de Datos de Pixel de Patrón (2 bytes) contiene un CRC de solamente los Datos de Pixel de Patrón. Si este CRC no verifica, entonces los Datos de Pixel de Patrón se pueden usar todavía pero el conteo de errores de CRC es incrementado .

K. Paquetes de canal de datos de enlace de comunicación El campo de CRC de Parámetro (2 bytes) contiene un CRC de 16 bits de todos los bytes de la Longitud de Paquete al Tipo de Paquete. Si este CRC no verifica, entonces el paquete completo es desechado. El campo de Datos de Enlace de Comunicación contiene los datos en bruto del canal de comunicación. Estos datos son simplemente pasados al dispositivo informático en la pantalla. El campo de CRC de Datos de Enlace de Comunicación (2 bytes) contiene un CRC de 16 bits de solamente los Datos de Enlace de Comunicación. Si este CRC no verifica, entonces los Datos de Enlace de Comunicación.

Si este CRC no verifica, entonces los Datos de Enlace de Comunicación se usan o son útiles aún, pero el conteo de errores de CRC es incrementado.

L Para paquetes de solicitud de cesión de tipo de interfase El campo de Tipo de Inferíase (1 byte) especifica el nuevo tipo de interfase que se va a usar. El valor en este campo especifica el tipo de interfase de la siguiente manera. Si el valor en el bit 7 es igual a ?0', la solicitud de cesión de Tipo es para el enlace hacia adelante, si es igual a ?l' , entonces la solicitud de cesión de Tipo es para el enlace inverso. Los bits 6 al 3 están reservados para uso futuro y en general se ajustan a cero. Los bits 2 al 0 se usan para definir el Tipo de interfase que se va a usar, donde un valor de 1 significa una cesión a un modo Tipo 1, el valor de 2 una cesión al modo Tipo 2, un valor de 3 a una cesión al modo Tipo 3 y un valor de 4 una cesión al modo Tipo 4. Los valores de ?0' y 5 al 7 están reservados para designación futura de modos alternativos o sus combinaciones de modos.

M. Para paquetes de confirmación de tipo de interfase El campo de Tipo de Inferíase (1 byte) tiene un valor que confirma el nuevo tipo de interfase que se va a usar. El valor en este campo especifica el tipo de interfase de la siguiente manera. Si el bit 7 es igual a Q ' , la solicitud de cesión de Tipo es para el enlace hacia adelante, de manera alternativa, si es igual a ?l', entonces la solicitud de cesión de Tipo es para el enlace inverso. Las posiciones de bit 6 al 3 están actualmente reservadas para usar para designar otros tipos de cesión, como se desee, y en general se ajustan a cero. No obstante, las posiciones de bit 2 al 0 se usan para definir el Tipo de interfase que se va a usar, donde un valor de ?0' indica una confirmación negativa, o que la cesión solicitada no se puede realizar, los valores de ?l', 2', 3' y ?4' indican cesión a los modos Tipo 1, Tipo 2, Tipo 3 y Tipo 4, respectivamente. Los valores de 5 al 7 están reservados para usar con designaciones alternativas de modos, como se desee.

N. Para paquetes de cesión de tipo de ejecución El campo de Tipo de Inferíase de 1 byte indica el nuevo tipo de interfase que se va a usar. El valor presente en este campo especifica el tipo de interfase usando primero el valor del bit 7 para determinar si la cesión de Tipo es o no para los enlaces hacia adelante o inverso. Un valor de ?0' indica que la solicitud de cesión de Tipo es para el enlace hacia adelante, y un valor de ?l' el enlace inverso. Los bits 6 al 3 están reservados para uso futuro y como tales se ajustan en general a un valor de cero. Sin embargo, los bits 2 al cero se usan para definir el Tipo de interfase que se va a usar, donde los valores 1, 2, 3 y 4 especifican el uso de cesión a los modos Tipo 1, Tipo 2, Tipo 3 y Tipo 4, respectivamente. El uso de los valores 0 y 5 al 7 para estos bits está reservado para uso futuro.

O. Para paquetes de habilitación de canal de audio hacia adelante El campo de Máscara de Habilitación de Canal de Audio (1 byte) contiene un grupo de banderas que indican qué canales de audio se van a habilitar en un cliente. Un bit ajustado a uno habilita el canal correspondiente y un bit ajustado acero inhabilita el canal correspondiente. Los bits 0 al 5 designan canales 0 al 5 los cuales dirigen canales anterior izquierdo, anterior derecho, posterior izquierdo, posterior derecho, centro anterior y altavoz para infragraves, respectivamente. Los bits 6 y 7 están reservados para uso futuro y, por el momento, generalmente se ajustan igual a cero .

P. Para paquetes de índice de muestra de audio inverso El campo de índice de Muestra de Audio (1 byte) especifica el índice de muestra de audio digital. Los valores para este campo son asignados a los diferentes índices donde valores de O, 1, 2, 3, 4, 5, 6, 7 8 se usan 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, donde los bits 9 al 254 están reservados para uso con índices alternativos, como se desee, de manera que actualmente están ajustados a ?0' . Un valor de 255 se usa para inhabilitar el flujo de audio de enlace inverso. El campo de Formato de Muestra (1 byte) especifica el formato de las muestras de audio digital. Cuando los bits [1:0] son iguales a ?0', las muestras de audio digital están en formato lineal, cuando son igual a 1, las muestras de audio digital están en formato µ-Law, y cuando son igual a 2, las muestras desde digital están en formato A-Law. Los bits [7:2] están reservados para uso alterno para designar formatos de audio, como se desee, y por lo general se ajustan igual a cero.

Q. Para los paquetes de sobrecarga de protección de contenido digital El campo de .Tipo de Protección de Contenido (1 byte) especifica el método de protección de contenido digital que se usa. Un valor de ?0' indica la Protección de Contenido de Transmisión Digital (DTCP) mientras que un valor de 1 indica Sistema de Protección de Contenido Digital de Ancho de Banda Alto (HDCP) . El rango de valor de 2 al 255 no está actualmente especificado pero está reservado para usar con esquemas de protección alternativos como se desee. El campo de Mensajes de Sobrecarga de Protección de Contenido es un campo de longitud variable gue contiene mensajes de protección de contenido enviados entre el aparato central y el cliente.

R. Para los paquetes de habilitación de color transparente El campo de Habilitación de Color Transparente (1 byte) especifica cuando el modo de color transparente está habilitado o inhabilitado. Si el bit 0 es igual a 0, entonces el modo de color transparente está inhabilitado, si es igual a 1, entonces el modo de color transparente está habilitado y el color transparente es especificado por medio de los siguientes dos parámetros. Los bits 1 al 7 de este byte están reservados para uso futuro y típicamente se ajustan igual a cero. El campo de Descriptor de Formato de Datos de Video (2 bytes) especifica el formato del Valor de Relleno de Área de Pixel. La figura 11 ilustra cómo se codifica el Descriptor de Formato de Datos de Video. El formato es generalmente igual que el mismo campo en el Paquete de Flujo de Video. El campo de Valor de Relleno de Área de Pixel usa 4 bytes asignados para el valor de pixel que va a ser rellenado en la ventana antes especificada. El formato de este pixel está especificado en el campo de Descriptor de Formato de Datos de Video.

S . Para los paquetes de medición de retardo de ida y vuelta El campo de Longitud de Paquete de 2 bytes especifica el número total de bytes en el paquete sin incluir el campo de longitud de paquete, y en una modalidad se selecciona para tener una longitud fija de 159. El campo de Tipo de Paquete de 2 bytes que identifica este tipo de paquete con un valor de 82, identificando un paquete como un Paquete de Medición de Retardo de Ida y Vuelta. El campo de ID de cliente h, como antes, está reservado para uso futuro como una ID de cliente, y generalmente se ajusta a cero. En una modalidad, el campo de CRC de Parámetro (2 bytes) contiene un CRC de 16 bits de todos los bytes de la Longitud de Paquete al Tipo de Paquete. Si este CRC no verifica, entonces el paquete completo es desechado. El campo de Tiempo de Guarda 1 (aquí 64 bytes) se usa para permitir que los excitadores de línea MDDI_Datos en el cliente se habiliten antes de que los excitadores de línea en el aparato central sean inhabilitados. El cliente habilita sus excitadores de línea MDDI_Datos durante el bit 0 de Tiempo de Guarda 1 y el aparato central inhabilita sus excitadores de línea de modo que estén completamente inhabilitados antes del último bit de Tiempo de Guarda 1. Tanto el aparato central como el cliente impulsan un nivel de cero lógico durante el Tiempo de Guarda 1 cuando no están inhabilitados . Otro propósito de este campo es asegurar que todas las señales MDDI_Datos estén a un nivel de cero lógico durante tiempo suficiente para permitir que el cliente empiece a recuperar un reloj o señal de reloj usando solamente MDDI_Stb antes de inhabilitar los excitadores de línea del aparato central . El campo de Periodo de Medición es una ventana de 64 bytes usada para permitir al cliente responder con dos bytes de Oxff, y 30 bytes de 0x00 a la mitad del índice de datos usado en el enlace hacia adelante. Este índice de datos corresponde con un Divisor de índice de Enlace Inverso de 1. El cliente regresa esta respuesta inmediatamente en el momento que percibe como el inicio del Periodo de Medición. Esta respuesta del cliente será recibida en un aparato central precisamente en el retardo de ida y vuelta del enlace más retardo lógico en el cliente después del inicio del primer bit del Periodo de Medición en el aparato central . El campo de Todo Cero 1 (2 bytes) contiene ceros para permitir que los excitadores de línea MDDI_Datos en el aparato central y cliente se superpongan de manera que MDDI_Datos sea siempre impulsada. El aparato central habilita los excitadores de línea MDDI_Datos durante el bit 0 del campo de Todo Cero 1, y el cliente también continúa impulsando la señal a un nivel de cero lógico como hizo al final del Periodo de Medición. El valor en el campo de Tiempo de Guarda 2 (64 bytes) permite la superposición del Periodo de Medición impulsado por el cliente cuando el retardo de ida y vuelta está a la cantidad máxima que puede ser medida en el Periodo de Medición. El cliente inhabilita sus excitadores de línea durante el bit 0 del Tiempo de Guarda 2 y el Aparato Central habilita sus excitadores de línea inmediatamente después del último bit de Tiempo de Guarda 2. Tanto el aparato central como el cliente impulsan un nivel de cero lógico durante el Tiempo de Guarda 2 cuando no están inhabilitados . Otro propósito de este campo es asegurar que todas las señales MDDI_Datos estén a un nivel de cero lógico durante un tiempo suficiente para permitir que el cliente empiece a recuperar una señal de reloj usando tanto MDDI_DatosO como MDDI_Stb después de habilitar los excitadores de línea para un aparato central.

T. Para los paquetes de calibración de sesgo de enlace hacia adelante En una modalidad, el campo de CRC de Parámetro (2 bytes) contiene un CRC de 16 bits de todos los bytes de la Longitud de Paquete al Tipo de Paquete . Si este CRC no verifica, entonces el paquete completo es desechado.

El campo de Todo Cero 1 usa 1 byte para asegurar que haya transiciones en la MDDI_Stb al final del campo de CRC de Parámetro. El campo de Secuencia de Datos de Calibración contiene una secuencia de datos que hace que las señales MDDI_Datos conmuten cada periodo de datos . La longitud del campo de Secuencia de Datos de Calibración es determinada por la interfase que está siendo usada en el enlace hacia adelante. Durante el procesamiento de la Secuencia de Datos de Calibración, el controlador de aparato central de MDDI ajusta todas las señales MDDI_Datos igual a la señal de validación. El circuito de recuperación de reloj de cliente debe usar solamente MDDI Stb más que MDDI StbX o MDDI DatosO para recuperar el reloj de datos mientras que el campo de Secuencia de Datos de Calibración está siendo recibido por la pantalla de cliente. Dependiendo de la fase exacta de la señal MDDI_Stb al inicio del campo de Secuencia de Datos de Calibración, la Secuencia de Datos de Calibración generalmente será uno de los siguientes con base en el Tipo de interfase que se está usando cuando este paquete es enviado: Tipo 1 - (secuencia de datos de 64 bytes) Oxaa, 0xaa...o 0x55, 0x55... Tipo 2 - (secuencia de datos de 128 bytes) Oxee, Oxcc.o 0x33, 0x33... Tipo 3 - (secuencia de datos de 256 bytes) OxfO, 0xf0...o OxOf, OxOf... Tipo 4 - (secuencia de datos de 512 bytes) Oxff, 0x00, Oxff, 0x00...o 0x00, Oxff, 0x00, Oxff... Un ejemplo de las posibles formas de onda de MDDI_Datos y MDDI_Stb tanto para la interfase Tipo 1 como para la interfase Tipo 2 se muestran en las figuras 62A y 62B, respectivamente.

XX. Conclusión Aunque se han descrito anteriormente diversas modalidades de la presente invención, se debe entender que han sido presentadas únicamente a manera de ejemplo, y no limitación. Por consiguiente, la extensión y alcance de la presente invención no deben ser limitados por ninguna de las modalidades ejemplares antes descritas, si no deben estar definidos solamente de- acuerdo con las siguientes reivindicaciones y sus equivalentes .

Claims (1)

1. N O V E D AD D E L A I NV E N C I Ó N Habiendo descrito la presente invención se considera como novedad, y por lo tanto se reclama como propiedad lo contenido en las siguientes: R E I V I N D I C A C I O N E S 1. Una interfase de datos digitales para transferir datos de presentación digitales a un índice alto entre un aparato central y un aparato cliente en una trayectoria de comunicación que comprende: una pluralidad de estructuras de paquetes enlazadas juntas para formar un protocolo de comunicación para comunicar un conjunto previamente seleccionado de datos de control digital y de presentación entre un aparato central y un cliente en la trayectoria de comunicación; y por lo menos un controlador de enlace reside en el aparato central acoplado al cliente a través de la trayectoria de comunicaciones y está configurado para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones y para formar datos de presentación digitales en uno o más tipos de paquetes de datos . 2. La interfase de conformidad con la reivindicación 1 que comprende además los paquetes agrupados juntos dentro de cuadros de medios que son comunicados entre el aparato central y el cliente que tienen una longitud fija definida previamente con un número determinado previamente de los paquetes que tienen longitudes diferentes y variables. 3. La interfase de conformidad con la reivindicación 1 que comprende además un Paquete de Cabecera de Subcuadro colocado al inicio de transferencias de paquetes desde el aparato central. 4. La interfase de conformidad con la reivindicación 1, caracterizada porque el controlador de enlace es un controlador de enlace de aparato central y comprende además por lo menos un controlador de enlace de cliente que reside en el aparato cliente acoplado al aparato central a través de la trayectoria de comunicaciones, está configurado para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones y para formar datos de presentación digitales en uno o más tipos de paquetes de datos . 5. La interfase de conformidad con la reivindicación 2 que comprende además : una pluralidad de modos de transferencia donde cada uno permite la transferencia de diferentes números máximos de bits de datos en paralelo en un periodo de tiempo dado, donde cada modo es seleccionable mediante negociación entre los excitadores de enlace de aparato central y cliente; y caracterizada porque los modos de transferencia son ajustables en forma dinámica entre los modos durante la transferencia de datos . 6. La interfase de conformidad con la reivindicación 1 que comprende además un paquete de tipo Interrupción de Enlace para transmisión por parte del aparato central al cliente para terminar la transferencia de datos en cualquiera de las dos direcciones en la trayectoria de comunicación. 7. La interfase de conformidad con la reivindicación 1 que comprende además medios para que el cliente despierte al aparato central de un estado de hibernación . 8. Un método para transferir datos digitales a un índice alto entre un aparato central y un aparato cliente en una trayectoria de comunicación para presentación a un usuario, que comprende: generar una o más de una pluralidad de estructuras de paquetes definidas previamente y enlazarlas juntas para formar un protocolo de comunicación definido previamente; comunicar un conjunto previamente seleccionado de datos de control digital y de presentación entre el aparato central y aparato cliente en la trayectoria de comunicación usando el protocolo de comunicación; acoplar por, lo menos un controlador de enlace de aparato central que reside en el aparato central al aparato cliente a través de la trayectoria de comunicaciones, el controlador de enlace de aparato central está configurado para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones y para formar datos de presentación digitales en uno o más tipos de paquetes de datos; y transferir datos en forma de paquetes en la trayectoria de comunicaciones usando los controladores de enlace. 9. El método de conformidad con la reivindicación 8 que comprende además agrupar tales paquetes juntos dentro de cuadros de medios para comunicación entre el aparato central y el cliente, los cuadros de medios tienen una longitud fija definida previamente con un número determinado previamente de tales paquetes que tienen longitudes diferentes y variables . 10. El método de conformidad con la reivindicación 8 que comprende además empezar la transferencia de paquetes del aparato central con un paquete de tipo Cabecera de Subcuadro . 11. El método de conformidad con la reivindicación 8 que comprende además generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones a través de al menos un controlador de enlace de cliente que reside en el aparato cliente acoplado al aparato central a través de la trayectoria de comunicaciones . 12. El método de conformidad con la reivindicación 11 que comprende además: negociar entre los excitadores de enlace de aparato central y cliente el uso de uno de una pluralidad de modos de transferencia en cada dirección, donde cada uno permite la transferencia de diferentes números máximos de bits de datos en paralelo en un periodo de tiempo dado; y ajustar de manera dinámica entre los modos de transferencia durante la transferencia de datos. 13. El método de conformidad con la reivindicación 8 que comprende además terminar la transferencia de datos en cualquiera de las dos direcciones en la trayectoria de comunicación usando un paquete de tipo Interrupción de Enlace para transmisión por parte del aparato central al cliente. 14. El método de conformidad con la reivindicación 8 que comprende además despertar al aparato central de un estado de hibernación mediante comunicación con el cliente . 15. Un aparato para transferir datos digitales a un índice alto entre un aparato central y un aparato cliente en una trayectoria de comunicación para presentación a un usuario, que comprende: al menos un controlador de enlace de aparato central dispuesto en el aparato central para generar una o más de una pluralidad de estructuras de paquete definidas previamente y enlazadas juntas para formar un protocolo de comunicación definido previamente, y para comunicar un conjunto seleccionado previamente de datos de control digital y de presentación entre el aparato central y el aparato cliente en la trayectoria de comunicación usando el protocolo de comunicación; por lo menos un controlador de cliente dispuesto en el aparato cliente y acoplado al controlador de enlace de aparato central a través de la trayectoria de comunicaciones; y cada controlador de enlace está configurado para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones y para formar datos de presentación digitales en uno o más tipos de paquetes de datos . 16. El aparato de conformidad con la reivindicación 15, caracterizado porque el controlador de aparato central comprende una máquina de estados . 17. El aparato de conformidad con la reivindicación 15, caracterizado porque el controlador de aparato central comprende un procesador de señal de propósito general. 18. El aparato de conformidad con la reivindicación 15 que comprende además un paquete de tipo Cabecera de Subcuadro al inicio de la transferencia de paquetes desde el aparato central. 19. El aparato de conformidad con la reivindicación 15, caracterizado porque el controlador de aparato central comprende uno o más excitadores de línea diferenciales; y el receptor de cliente comprende uno o más receptores de línea diferenciales acoplados a la trayectoria de comunicación. 20. El aparato de conformidad con la reivindicación 15, caracterizado porque los controladores de enlace de aparato central y cliente están configurados para usar uno de una pluralidad de modos de transferencia en cada dirección, donde cada uno permite la transferencia de diferentes números máximos de bits de datos en paralelo en un periodo de tiempo dado; y son capaces de ajustarse de manera dinámica entre los modos de transferencia durante la transferencia de datos. 21. El aparato de conformidad con la reivindicación 15, caracterizado porque el controlador de aparato central está configurado para transmitir un paquete de tipo Interrupción de Enlace a los medios del cliente para terminar la transferencia de datos en cualquiera de las dos direcciones en la trayectoria de comunicación. 22-, Para usar en un sistema electrónico para transferir datos digitales a un índice alto entre un aparato central y un aparato cliente en una trayectoria de comunicación para presentación a un usuario, un producto de programa de computadora comprende : un medio utilizable de computadora que tiene medios de código de programa legibles por computadora incorporados en el medio para hacer que un programa de aplicaciones se ejecute en el sistema de computadora, los medios de código de programa legibles por computadora comprenden : un primer medio de código de programa legible por computadora para hacer que el sistema de computadora genere una o más de una pluralidad de estructuras de paquetes definidas previamente y las enlace juntas para formar un protocolo de comunicación definido previamente; un segundo medio de código de programa legible por computadora para hacer que el sistema de computadora comunique un conjunto seleccionado previamente de datos de control digital y de presentación entre el aparato central y el aparato cliente en la trayectoria de comunicación usando el protocolo de comunicación; un tercer medio de código de programa legible por computadora para hacer gue el sistema de computadora acople por lo menos un controlador de enlace de aparato central dispuesto en el aparato central a por lo menos un controlador de cliente dispuesto en el aparato cliente a través de la trayectoria de comunicaciones, los controladores de enlace están configurados para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones, y para formar datos de presentación digitales en uno o más tipos de paquetes de datos; y un cuarto medio de código de programa legible por computadora para hacer que el sistema de computadora transfiera datos en forma de paquetes en la trayectoria de comunicaciones usando los controladores de enlace. 23. Un aparato para transferir datos digitales a un índice alto entre un aparato central y un aparato cliente en una trayectoria de comunicación para presentación a un usuario, que comprende: medios para generar una o más de una pluralidad estructuras de paquete definidas previamente y enlazarlas juntas para formar un protocolo de comunicación definido previamente; medios para comunicar un conjunto seleccionado previamente de datos de control digital y de presentación entre el aparato central y el aparato cliente en la trayectoria de comunicación usando el protocolo de comunicación; medios para acoplar por lo menos dos controladores de enlace juntos a través de la trayectoria de comunicaciones, uno en cada uno del aparato central y cliente y cada uno está configurado para generar, transmitir y recibir paquetes que forman el protocolo de comunicaciones, y para formar datos de presentación digitales en uno o más tipos de paquetes de datos; y medios para transferir datos en forma de paquetes en la trayectoria de comunicaciones usando los controladores de enlace. 24. El aparato de conformidad con la reivindicación 23 que comprende además medios para iniciar la transferencia de paquetes desde el aparato central con un paquete de tipo Cabecera de Subcuadro. 25. El aparato de conformidad con la reivindicación 23 que comprende además medios para solicitar información de capacidades de pantalla del cliente mediante un controlador de enlace de aparato central para determinar qué tipo de datos e índices de datos el cliente es capaz de admitir a través de la interfase. 26. Un procesador para usar en un sistema electrónico para transferir datos digitales a un índice alto entre un aparato central y un aparato cliente en una trayectoria de comunicación, el procesador está configurado para generar una o más de una pluralidad de estructuras de paquetes definidas previamente y enlazarlas juntas para formar un protocolo de comunicación definido previamente; formar datos de presentación digitales en uno o más tipos de paquetes de datos; comunicar un conjunto previamente seleccionado de datos de control digital y de presentación entre el aparato central y aparato cliente en la trayectoria de comunicación usando el protocolo de comunicación; y transferir datos en forma de paquetes en la trayectoria de comunicaciones . 27. Una máquina de estados para usar para obtener sincronización en un sistema electrónico que transfiere datos digitales a un índice alto entre un aparato central y un aparato cliente en una trayectoria de comunicación, la máquina de estados está configurada para tener por lo menos un estado de sincronización Estado de Cuadros Asinc, por lo menos dos estados de sincronización Estados de Adquisición de Sinc y por lo menos tres estados de sincronización Estados En-Sinc. 28. Una máquina de estados para usar para obtener sincronización en un sistema electrónico que transfiere datos digitales a un índice alto entre un aparato central y un aparato cliente en una trayectoria de comunicación, la máquina de estados está configurada para tener por lo menos un estado de sincronización Estados de Adquisición de Sinc y por lo menos dos estados de sincronización Estados En-Sinc. 29. La máquina de estados de conformidad con la reivindicación 28, caracterizada porque una condición para cambiar entre un Estado de Adquisición de Sinc y un primer Estado En-Sinc es detectar la presencia de un patrón de sincronización en el enlace de comunicación. 30. La máquina de estados de conformidad con la reivindicación 28, caracterizada porque una segunda condición para cambiar entre un Estado de Adquisición de Sinc y un primer Estado En-Sinc es detectar la presencia de un paquete de cabecera de subcuadro y un valor de CRC bueno en un límite de cuadro . 31. La máquina de estados de conformidad con la reivindicación 28, caracterizada porque una condición para cambiar entre un primer Estado En-Sinc y un Estado de Adquisición de Sinc es detectar que no esté presente ningún patrón de sincronización o la presencia de un valor de CRC malo en un límite de subcuadro. 32. La máquina de estados de conformidad con la reivindicación 28, caracterizada porque una condición para cambiar entre un primer Estado En-Sinc y un segundo Estado En-Sinc es detectar que no esté presente ningún patrón de sincronización o la presencia de un valor de CRC malo en un límite de subcuadro . 33. El método de conformidad con la reivindicación 12 que comprende además despertar un enlace de comunicación al impulsar una línea de datos a un estado alto durante por lo menos 10 ciclos de reloj y empezar a transmitir una señal de validación como si la línea de datos fuera cero, por parte del aparato central. 34. El método de conformidad con la reivindicación 33 que comprende además impulsar la línea de datos a un estado bajo durante un número determinado previamente de ciclos de reloj por parte del aparato central mientras se continúa transmitiendo una señal de validación después de que el aparato central ha impulsado la línea de datos a un estado alto durante aproximadamente 150 ciclos de reloj . 35. El método de conformidad con la reivindicación 33 que comprende además empezar a transmitir el primer paquete de cabecera de subcuadro por parte del aparato central . 36. El método de conformidad con la reivindicación 34 que comprende además continuar por lo menos 150 ciclos de reloj continuos de la línea de datos en el estado alto, seguido de por lo menos 50 ciclos de reloj continuos de la línea de datos en el estado bajo, por parte del cliente . 37. El método de conformidad con la reivindicación 34 que comprende además dejar de impulsar la línea de datos al estado alto por parte del cliente después de que el cliente cuenta 70 ciclos de reloj continuos de los datos en el estado alto. 38. El método de conformidad con la reivindicación 37 que comprende además continuar otros 80 ciclos de reloj continuos de la línea de datos en el estado alto para alcanzar los 150 ciclos de reloj de la línea de datos en estado alto por parte del cliente, y buscar aproximadamente 50 ciclos de reloj de la línea de datos en el estado bajo, y buscar la palabra única. 39. El método de conformidad con la reivindicación 12 que comprende además contar el número de ciclos de reloj que ocurren hasta que un uno es muestreado por el aparato central, muestreando la línea de datos tanto en el flanco de subida como en el flanco de bajada durante el paquete de temporización inversa. 40. El método de conformidad con la reivindicación 12 que comprende además contar el número de ciclos de reloj que ocurren hasta que un uno es muestreado por el aparato central, muestreando la línea de datos tanto en el flanco de subida como en el flanco de bajada durante el paquete de temporización inversa.