ES2323129T3 - Interfaz de alta velocidad de datos. - Google Patents

Abstract

Un procedimiento para que un cliente comunique a un servidor una selección de una velocidad inválida de datos de muestreo para un flujo de datos de audio inverso en un sistema de comunicaciones de interfaz digital de visualización móvil MDDI, comprendiendo el procedimiento las etapas de: enviar un paquete de encapsulamiento inverso desde el servidor al cliente; enviar un paquete de informe de error desde el cliente al servidor, comprendiendo el paquete de informe de error un indicador de que el cliente no brinda soporte a la velocidad de datos de muestreo inválida; solicitar un paquete de capacidad de cliente por parte del servidor, comprendiendo una solicitud de datos de soporte de flujo de audio; y enviar el paquete de capacidad de cliente al servidor, comprendiendo el paquete de capacidad de cliente los datos de soporte de flujo de audio.

Description

Interfaz de alta velocidad de datos.

Antecedentes I. Campo

Las realizaciones de la invención en esta descripción se refieren a un protocolo de señal digital y al proceso para comunicar o para transferir señales entre un dispositivo servidor y un dispositivo cliente a altas velocidades de datos. De manera más específica, la descripción se refiere a una técnica para la transferencia de señales multimedia y otros tipos de señales digitales desde un dispositivo servidor o controlador a un dispositivo cliente para la presentación o la visualización a un usuario final usando un mecanismo de transferencia de alta velocidad de datos de baja potencia que tenga aplicaciones de dispositivo internas y externas.

II. Antecedentes

Los ordenadores, los productos relacionados con juegos electrónicos, y varias tecnologías de vídeo (por ejemplo, DVD y VCR de alta definición) han avanzado de manera significativa en los últimos años para proporcionar la presentación de imágenes de resolución cada vez mayor, fijas, de vídeo, de vídeo bajo demanda y de gráficos, incluso cuando incluyan algún tipo de texto, a los usuarios finales de dicho equipo. Estos avances a su vez dictan el uso de dispositivos de visualización electrónicos de resoluciones mayores, tales como monitores de vídeo de alta definición, monitores HDTV, o elementos de proyección de imagen especializados. La combinación de dichas imágenes visuales con datos de audio de alta definición o de alta calidad, tales como cuando se usa la reproducción de sonido de tipo CD, DVD, sonido envolvente, y otros dispositivos que también tengan asociadas salidas de señal de audio, se usa para crear una experiencia multimedia más realista, rica en contenidos o verosímil para un usuario final. Además, los sistemas de sonido sumamente móviles, de alta calidad, y los mecanismos de transporte de música, tales como los reproductores MP3, se han desarrollado sólo para las presentaciones de audio a los usuarios finales. Esto ha dado como resultado expectativas aumentadas para los usuarios típicos de dispositivos electrónicos comerciales, desde ordenadores a televisores e incluso teléfonos, estando ahora acostumbrados a, y esperando, una alta calidad de salida, o calidad de salida suprema.

En un escenario de presentación de vídeo típico, que implique un producto electrónico, los datos de vídeo son transferidos de manera típica, usando técnicas actuales, a una velocidad que podría ser mejor denominada baja o media, estando en el orden de uno a decenas de kilobits por segundo. Estos datos son después almacenados de manera temporal o almacenados en dispositivos de memoria transitoria o de largo plazo, para su reproducción retardada (posterior) sobre un dispositivo de visualización deseado. Por ejemplo, las imágenes se pueden transferir "a través" o usando Internet, empleando un programa residente en un ordenador que tenga un módem u otro tipo de dispositivo de conexión a Internet, para recibir o para transmitir datos útiles en la representación digital de una imagen. Una transferencia similar puede tener lugar usando dispositivos inalámbricos tales como ordenadores portátiles equipados con módems inalámbricos, o asistentes personales digitales (PDA) inalámbricas, o teléfonos inalámbricos.

Una vez recibidos, los datos se almacenan de manera local en elementos de memoria, en circuitos o en dispositivos, tales como memoria RAM o flash, incluyendo dispositivos de almacenamiento interno o externo tales como unidades de disco duro de pequeño tamaño, para la reproducción. Según la cantidad de datos y la resolución de la imagen, la reproducción podría comenzar relativamente rápida, o se podría presentar con un retardo a más largo plazo. Esto es, en algunos casos, la presentación de la imagen permite cierto grado de reproducción en tiempo real para imágenes muy pequeñas o de baja resolución que no requieran muchos datos, o que usen algún tipo de almacenamiento temporal, de forma que después de un pequeño retardo, se presente algún material mientras se transfiere más material. Con tal de que no haya interrupciones en el enlace de transferencia, o interferencia proveniente de otros sistemas o usuarios con respecto al canal de transferencia que se esté usando, una vez que la presentación comienza, la transferencia es razonablemente transparente para el usuario final del dispositivo de visualización. Naturalmente, cuando múltiples usuarios comparten un único trayecto de comunicaciones, tal como una conexión a Internet por cable, las transferencias pueden interrumpirse o ralentizarse más de lo deseado.

Los datos usados para crear bien imágenes fijas o bien vídeo en movimiento a menudo se comprimen usando una de varias técnicas bien conocidas, tales como las especificadas por el Grupo de Expertos Conjunto de Fotografía (JPEG), el Grupo de Expertos de Imágenes en Movimiento (MPEG), y otras organizaciones o compañías de normas bien conocidas en las industrias de medios, de ordenadores y de las comunicaciones para acelerar la transferencia de datos sobre un enlace de comunicaciones. Esto permite la transferencia de imágenes o de datos más rápida por medio de la utilización de un número menor de bits para transferir una cantidad dada de información.

Una vez que los datos son transferidos a un dispositivo "local" tal como un ordenador que tenga un mecanismo de almacenamiento tal como una memoria, o elementos de almacenamiento magnéticos u ópticos, o a otros dispositivos destinatarios, la información resultante es descomprimida (o reproducida usando reproductores de descodificación especiales), y descodificada si se necesita, y preparada para la presentación apropiada en base a la resolución de presentación disponible correspondiente y a los elementos de control. Por ejemplo, una resolución de vídeo de ordenador típica en términos de una resolución de pantalla de X por Y píxeles oscila de manera típica desde 480x640 píxeles, pasando por 600x800, hasta 1024x1024, aunque generalmente son posibles una gran variedad de otras resoluciones, según se desee o se necesite.

La presentación de imagen también se ve afectada por el contenido de la imagen y la capacidad de los controladores de vídeo dados para manipular la imagen, en términos de ciertos niveles de color o profundidad de color predefinidos (bits por píxel usados para generar colores) e intensidades, y cualesquiera bits de sobrecarga adicionales que se empleen. Por ejemplo, una presentación de ordenador típica anticiparía cualquier valor entre alrededor de 8 a 32, o más, bits por píxel para representar varios colores (sombras y matices), aunque se encuentren otros valores.

A partir de los valores anteriores, uno puede ver que una imagen de pantalla dada va a requerir la transferencia desde cualquier valor entre 2,45 Megabits (Mb) y aproximadamente 33,55 Mb de datos sobre el intervalo que va desde las resoluciones y profundidad típicas más bajas a las más altas, respectivamente. Cuando se visualiza vídeo o imágenes del tipo en movimiento a una velocidad de 30 tramas por segundo, la cantidad de datos requeridos es de aproximadamente 73,7 a 1.006 Megabits de datos por segundo (Mbps), o aproximadamente de 9,21 a 125,75 Megabytes por segundo (MBps). Además, uno puede desear presentar datos de audio junto con imágenes, tales como para una presentación multimedia, o como una presentación independiente de audio de alta resolución, tal como música con calidad de CD. También se pueden emplear señales adicionales que traten de órdenes, controles o señales interactivas. Cada una de estas opciones añade incluso más datos para su transferencia. Además, las técnicas más modernas de transmisión que implican la televisión de alta definición (HD) y las grabaciones de películas pueden añadir incluso más datos e información de control. En cualquier caso, cuando uno desee 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 contenidos, se requiere un enlace de alta velocidad de transferencia de datos entre elementos de presentación y el dispositivo fuente o servidor que está configurado para proporcionar dichos tipos de datos.

Las velocidades de datos de aproximadamente 115 kilobytes (kBps) o de 920 kilobits por segundo (kbps) se pueden manejar de manera rutinaria por algunas interfaces de módem en serie. Otras interfaces, tales como las interfaces en serie USB, pueden acomodar transferencias de datos a velocidades tan altas como 12 MBps, y transferencias de alta velocidad especializadas tales como aquéllas configuradas usando la norma 1394 del Institute of Electrical and Electronics Engineers (IEEE) [Instituto de Ingenieros Eléctricos y Electrónicos], pueden tener lugar a velocidades del orden de 100 a 400 MBps. Desafortunadamente, estas velocidades caen por debajo de las altas velocidades de datos deseadas tratadas con anterioridad, que se contemplan para su uso con futuros dispositivos de datos inalámbricos y otros servicios, para proporcionar señales de salida de alta resolución, ricas en contenido, para controlar pantallas de vídeo portátiles o dispositivos de audio. Esto incluye ordenadores para empresa y otras presentaciones, dispositivos de juegos, etc. Además, estas interfaces requieren el uso de una cantidad significativa de software del servidor, o del sistema, y software del cliente, para funcionar. Sus pilas de protocolo de software también crean una gran cantidad indeseable de sobrecarga, especialmente donde se contemplen dispositivos inalámbricos móviles o aplicaciones de telefonía. Dichos dispositivos tienen severas limitaciones de memoria y de consumo de potencia, así como una capacidad de cómputo ya gravada. Además, algunas de estas interfaces utilizan cables voluminosos que son demasiado pesados e insatisfactorios para aplicaciones móviles sumamente orientadas a la estética, conectores complejos que suman costes, o simplemente consumen demasiada potencia.

Hay otras interfaces conocidas tales como el adaptador gráfico de vídeo analógico (VGA), la interfaz interactiva de vídeo digital (DVI) o la interfaz de vídeo Gigabit (GVIF). Las dos primeras de éstas son interfaces de tipo paralelo que procesan datos a velocidades de transferencia más altas, pero que también emplean cables pesados y consumen grandes cantidades de energía, del orden de varios vatios. Ninguna de estas características es dócil al uso con dispositivos electrónicos portátiles de consumo. Incluso la tercera interfaz consume demasiada potencia y usa conectores caros o voluminosos.

Para alguna de las interfaces anteriores, y para otros sistemas/protocolos de muy alta velocidad de datos, o mecanismos de transferencia asociados con las transferencias de datos para equipos informáticos de instalación fija, existe otra desventaja principal. Para acomodar las velocidades de transferencia de datos deseadas se requieren también cantidades sustanciales de potencia y/o de funcionamiento a altos niveles de corriente. Esto reduce en gran medida la utilidad de dichas técnicas para productos orientados al consumidor sumamente móviles.

Por lo general, para acomodar dichas velocidades de transferencia de datos usando alternativas tales como, digamos, conexiones del tipo de fibra óptica y elementos de transferencia, también se requiere un buen número de conversores y de elementos adicionales que introducen mucha más complejidad y coste que el que se desea para un producto orientado para el consumidor verdaderamente comercial. Además de la naturaleza generalmente cara de los sistemas ópticos hasta ahora, sus requisitos de potencia y su complejidad evitan el uso general de aplicaciones portátiles ligeras de peso y de baja potencia.

De lo que se ha estado careciendo en la industria de aplicaciones portátiles, inalámbricas o móviles, es de una técnica para proporcionar una experiencia de presentación de alta calidad, ya esté basada en audio, en vídeo, o en multimedia, para usuarios finales sumamente móviles. Esto es, cuando se usen ordenadores portátiles, teléfonos inalámbricos, PDA, u otros dispositivos o equipos de comunicación sumamente móviles, los actuales sistemas o dispositivos de presentación de vídeo y de audio que se estén usando simplemente no pueden entregar salida al nivel de alta calidad deseado. A menudo, la calidad percibida que se echa en falta es el resultado de altas velocidades de datos que no se pueden obtener, necesarias para la transferencia de los datos de presentación de alta calidad. Esto puede incluir tanto una transferencia a dispositivos externos más eficientes, avanzados o cargados de características, para la presentación a un usuario final, como la transferencia entre servidores y clientes internos a dispositivos portátiles tales como ordenadores, máquinas de juegos y dispositivos inalámbricos tales como teléfonos móviles.

En este último caso, se han dado grandes pasos al añadir pantallas de vídeo internas de resolución cada vez más alta, y otros dispositivos y conexiones de entrada y/o de salida especiales a dispositivos inalámbricos como los denominados teléfonos de tercera generación, y para los llamados ordenadores portátiles. Sin embargo, los buses y las conexiones internos de datos que pueden incluir el pasaje a través de estructuras giratorias, o de bisagra deslizante, o de estructuras similares a bisagras de giro, que montan o conectan pantallas de vídeo u otros elementos a la carcasa principal donde residen el servidor y/o varios otros elementos de control y componentes de salida. Es muy difícil construir interfaces de transferencias de datos de alto caudal usando las técnicas anteriores, que pueden requerir de hasta 90 conductores, o más, para conseguir el caudal deseado, sobre, digamos, un teléfono inalámbrico, como un ejemplo. Esto presenta muchas cuestiones de fabricación, de costes prohibitivos, y cuestiones de retos de fiabilidad a superar.

Dichas cuestiones y requisitos también están siendo vistos en instalaciones de localización fija en las que los dispositivos del tipo de comunicaciones, o informáticos, como un ejemplo, son añadidos a aparatos y a otros dispositivos de consumo para proporcionar capacidades de datos avanzadas, Internet y conexiones de transferencia de datos, o entretenimiento incorporado. Otro ejemplo sería el de aviones y autobuses en los que se montan en el respaldo de los asientos pantallas de presentación de vídeo y de audio individuales. Sin embargo, en estas situaciones a menudo es más conveniente, eficiente y más fácilmente utilizable, tener los elementos del almacenamiento principal, del procesado o del control de las comunicaciones localizados a una cierta distancia de las pantallas visibles o de las salidas de audio, con un enlace o canal de interconexión para la presentación de información. Este enlace necesitará manejar una cantidad significativa de datos para conseguir el caudal deseado como se ha tratado con anterioridad.

Por lo tanto, se necesita un nuevo mecanismo de transferencia para aumentar el caudal de datos entre dispositivos servidores que proporcionen los datos y los dispositivos o elementos de visualización de cliente que presentan una salida a los usuarios finales.

Los solicitantes han propuesto dichos nuevos mecanismos de transferencia en el documento WO 03/023587 titulado "Generating And Implementing A Communication Protocol And Interface For High Data Rate Signal Transfer" ["Generación e Implementación de un Protocolo de Comunicación y una Interfaz para la Transferencia de Señales a Alta Velocidad de Datos"]. Las técnicas tratadas en esas solicitudes pueden mejorar en gran medida la velocidad de transferencia para grandes cantidades de datos en señales de datos de alta velocidad. Sin embargo, las demandas de velocidades de datos siempre en aumento, especialmente en lo relacionado a las presentaciones de vídeo, continúan creciendo. Incluso con otros desarrollos en curso en la tecnología de señales de datos, aún existe una necesidad para esforzarse hacia velocidades de transferencia aún más rápidas, eficiencias de enlaces de comunicaciones mejoradas, y enlaces de comunicaciones más potentes. Por lo tanto, existe una necesidad continua para desarrollar un nuevo o mejorado mecanismo de transferencia que se necesita para aumentar el caudal de datos entre los dispositivos servidor y cliente.

Resumen

Éstos, y otros, objetos y ventajas se proporcionan por medio de un procedimiento, un sistema y un producto de programa de ordenador de acuerdo con las reivindicaciones anejas 1, 5 y 9.

Las realizaciones preferidas se definen en las reivindicaciones dependientes.

Breve descripción de los dibujos

Características y ventajas adicionales de la invención, así como la estructura y el funcionamiento de varias realizaciones de la invención, se describen con detalle a continuación con referencia a los dibujos que se acompañan. En los dibujos, idénticos números de referencia por lo general indican idénticos elementos, elementos con una funcionalidad similar y/o elementos o etapas de procesamiento estructuralmente similares, y el dibujo en el que aparece por primera vez un elemento está indicado por el dígito o por los dígitos de más a la izquierda en el número de referencia.

La Fig. 1A ilustra un entorno básico en el que las realizaciones de la invención podrían funcionar, incluyendo el uso de un dispositivo de microvisualización, o un proyector, junto con un ordenador portátil u otro dispositivo de procesado de datos.

La Fig. 1B ilustra un entorno básico en el que podrían funcionar las realizaciones de la invención, incluyendo el uso de un dispositivo de microvisualización o un proyector, y elementos de presentación de audio usados junto con un transceptor inalámbrico.

La Fig. 1C ilustra un entorno básico en el que podrían funcionar las realizaciones de la invención, incluyendo el uso de dispositivos internos de presentación de visualización o de audio usados en un ordenador portátil.

La Fig. 1D ilustra un entorno básico en el que podrían funcionar las realizaciones de la invención, incluyendo el uso de elementos internos de presentación de visualización o de audio, usados en un transceptor inalámbrico.

La Fig. 2 ilustra el concepto global de una Interfaz Móvil de Datos Digitales (MDDI) con una interconexión de servidor y cliente.

La Fig. 3 ilustra la estructura de un paquete útil para realizar las transferencias de datos desde un dispositivo cliente a un dispositivo servidor.

La Fig. 4 ilustra el uso de un controlador de enlace MDDI y los tipos de señales pasadas entre un servidor y un cliente por los conductores del enlace de datos físico para una interfaz de Tipo 1.

La Fig. 5 ilustra el uso de un controlador de enlace MDDI y los tipos de señales pasadas entre un servidor y un cliente por los conductores de enlace de datos físicos para las interfaces de los Tipos 2, 3 y 4.

La Fig. 6 ilustra la estructura de tramas y de subtramas usada para implementar el protocolo de interfaz.

La Fig. 7 ilustra la estructura general de paquetes usada para implementar el protocolo de interfaz.

La Fig. 8 ilustra el formato de un paquete de cabecera de subtrama.

La Fig. 9 ilustra el formato y el contenido de un Paquete de Relleno.

La Fig. 10 ilustra el formato de un Paquete de Flujo de Vídeo.

Las Figs. 11A a 11E ilustran el formato y el contenido para el Descriptor de formato de Datos de Vídeo usado en la Fig. 10.

La Fig. 12 ilustra el uso de formatos empaquetados y no empaquetados para los datos.

La Fig. 13 ilustra el formato de un Paquete de Flujo de Audio.

La Fig. 14 ilustra el uso de formatos PCM (Modulación Pulso-Código) alineados por bytes y empaquetados para los datos.

La Fig. 15 ilustra el formato de un Paquete de Flujo Definido por el Usuario.

La Fig. 16 ilustra el formato de un Paquete de Mapa de Colores.

La Fig. 17 ilustra el formato de un Paquete de Encapsulamiento de Enlace Inverso.

La Fig. 18 ilustra el formato de un Paquete de Capacidad de Cliente.

La Fig. 19 ilustra el formato de un Paquete de Datos de Teclado.

La Fig. 20 ilustra el formato de un Paquete de Datos de Dispositivo Puntero.

La Fig. 21 ilustra el formato de un Paquete de Cierre de Enlace.

La Fig. 22 ilustra el formato de un Paquete de Petición y Estado de Cliente.

La Fig. 23 ilustra el formato de un Paquete de Transferencia de Bloques de Bits.

La Fig. 24 ilustra el formato de un Paquete de Relleno de Área de Mapa de Bits.

La Fig. 25 ilustra el formato de un Paquete de Relleno de Patrón de Mapa de Bits.

La Fig. 26 ilustra el formato de un Paquete de Canal de Datos de Enlace de Comunicaciones.

La Fig. 27 ilustra el formato de un Paquete de Petición de Traspaso de Tipo de Interfaz.

La Fig. 28 ilustra el formato de un Paquete de Acuse de Recibo de Tipo de Interfaz.

La Fig. 29 ilustra el formato de un Paquete de Ejecución de Traspaso de Tipo.

La Fig. 30 ilustra el formato de un Paquete de Habilitación de Canal de Audio Directo.

La Fig. 31 ilustra el formato de un Paquete de Velocidad de Muestra de Audio Inverso.

La Fig. 32 ilustra el formato de un Paquete de Sobregasto de Protección de Contenido Digital.

La Fig. 33 ilustra el formato de un Paquete de Habilitación de Color Transparente.

La Fig. 34 ilustra el formato de un Paquete de Medición de Retardo de Ida y Vuelta.

La Fig. 35 ilustra la temporización de sucesos durante el Paquete de Medición de Retardo de Ida y Vuelta.

La Fig. 36 ilustra una implementación de muestra de un generador y comprobador de CRC (Comprobación de Redundancia Cíclica) útil para implementar la invención.

La Fig. 37A ilustra la temporización de señales CRC para el aparato de la Fig. 36 cuando se envían paquetes de datos.

La Fig. 37B ilustra la temporización de señales CRC para el aparato de la Fig. 36 cuando se reciben paquetes de datos.

La Fig. 38 ilustra las etapas de procesamiento para una petición de servicio típica sin contención.

La Fig. 39 ilustra las etapas de procesamiento para una petición de servicio típica activada después de que la secuencia de reinicio de enlace haya comenzado, enfrentándose con el inicio del enlace.

La Fig. 40 ilustra cómo una secuencia de datos se puede transmitir usando codificación DATA-STB (DATOS-SONDEO).

La Fig. 41 ilustra unos circuitos útiles para generar las señales de DATA y STB a partir de los datos de entrada en el servidor, y después recuperar los datos en el cliente.

La Fig. 42 ilustra controladores y resistencias de terminación útiles para la implementación de una realización.

La Fig. 43 ilustra las etapas y los niveles de señal empleados por un cliente para asegurar el servicio desde el servidor, y por el servidor para proporcionar dicho servicio.

La Fig. 44 ilustra el espaciado relativo entre transiciones sobre Data0, otras líneas de datos (DataX), y las líneas de habilitación (Stb).

La Fig. 45 ilustra la presencia de un retardo en la respuesta que puede ocurrir cuando un servidor inhabilita el controlador del servidor después de transferir un paquete.

La Fig. 46 ilustra la presencia de un retardo en la respuesta que puede ocurrir cuando un servidor habilita al controlador del servidor para transferir un paquete.

La Fig. 47 ilustra la relación en la entrada del receptor del servidor entre la temporización de los datos que se están transfiriendo y el borde de subida y el borde de bajada de los pulsos de habilitación.

La Fig. 48 ilustra las características de conmutación y el correspondiente retardo de salida del cliente desarrollado por la temporización de datos inversa.

La Fig. 49 ilustra un diagrama de alto nivel de las etapas de procesamiento de la señal y de las condiciones por medio de las que se puede implementar la sincronización usando una máquina de estados.

La Fig. 50 ilustra cantidades típicas de retardo que se encuentran para el procesado de la señal en los trayectos directo e inverso en un sistema que emplee la MDDI.

La Fig. 51 ilustra la medición de retardo marginal de ida y vuelta.

La Fig. 52 ilustra los cambios de velocidad de datos del Enlace Inverso.

La Fig. 53 ilustra una representación gráfica de valores del Divisor de Velocidad Inversa frente a la velocidad de datos del enlace directo.

Las Figs. 54A y 54B ilustran las etapas emprendidas en el funcionamiento de una interfaz.

La Fig. 55 ilustra una visión global de los paquetes de procesado de aparato de interfaz.

La Fig. 56 ilustra el formato de un Paquete de Enlace Directo.

La Fig. 57 ilustra valores típicos para el retardo de propagación y para el desfase en una interfaz de Enlace de Tipo 1.

La Fig. 58 ilustra las líneas de Datos, Sondeo, y Temporización de Recuperación de Reloj en un Enlace de Tipo 1 para un procesamiento de señal ejemplar a través de la interfaz.

La Fig. 59 ilustra valores típicos para el retardo de propagación y para el desfase en las interfaces de Enlaces de Tipo 2, Tipo 3 o Tipo 4.

Las Figs. 60A, 60B y 60C ilustran diferentes posibilidades para la temporización de dos señales de datos y de MDDI_Stb, cada una con respecto a la otra, siendo ideales, tempranas y tardías, respectivamente.

La Fig. 61 ilustra conectores ejemplares de asignaciones de patillas de interfaz, usados con interfaces de Tipo 1/Tipo 2.

Las Figs. 62A y 62B ilustran posibles formas de onda de MDDI_Data y MDDI_Stb para ambas interfaces, de Tipo 1 y de Tipo 2, respectivamente.

La Fig. 63 ilustra un diagrama de alto nivel de etapas y condiciones alternativas de procesamiento de señales, por medio de las cuales se puede implementar la sincronización usando una máquina de estados.

La Fig. 64 ilustra una temporización relativa ejemplar entre una serie de ciclos de reloj y la temporización de varios bits de paquetes de enlace inverso y valores de divisor.

La Fig. 65 ilustra un procesamiento ejemplar de transferencia de código de error.

La Fig. 66 ilustra un aparato útil para el procesado de transferencia de código de error.

La Fig. 67A ilustra un procesado de transferencia de código de error para la sobrecarga de código.

La Fig. 67B ilustra un procesado de transferencia de código de error para la recepción de código.

La Fig. 68A ilustra las etapas de procesamiento para un servicio de reanimación iniciado por un servidor.

La Fig. 68B ilustra las etapas de procesamiento para un servicio de reanimación iniciado por un cliente.

La Fig. 68C ilustra las etapas de procesamiento para el servicio de reanimación iniciado por el servidor y por el cliente, con contención.

La Fig. 69 ilustra el formato de un Paquete de Solicitud de Característica VCP (Panel de Control Virtual).

La Fig. 70 ilustra el formato de un Paquete de Respuesta de Característica VCP.

La Fig. 71 ilustra el formato de una Lista de Respuesta de Característica VCP.

La Fig. 72 ilustra el formato de un Paquete de Fijación de Característica VCP.

La Fig. 73 ilustra el formato de un Paquete de Petición de Parámetro Válido.

La Fig. 74 ilustra el formato de un Paquete de Respuesta de Parámetro Válido.

La Fig. 75 ilustra el formato de un Paquete de Capacidad de Imagen Alfa-Cursor.

La Fig. 76 ilustra el formato de un Paquete de Mapa de Transparencia Alfa-Cursor.

La Fig. 77 ilustra el formato de un Paquete de Desplazamiento de Imagen Alfa-Cursor.

La Fig. 78 ilustra el formato de un Paquete de Flujo de Vídeo Alfa-cursor.

La Fig. 79 ilustra el formato de un Paquete de Capacidad de Flujo de Vídeo Escalado.

La Fig. 80 ilustra el formato de un Paquete de Configuración de Flujo de Vídeo Escalado.

La Fig. 81 ilustra el formato de un Paquete de Acuse de Recibo de Flujo de Vídeo Escalado.

La Fig. 82 ilustra el formato de un Paquete de Flujo de Vídeo Escalado.

La Fig. 83 ilustra el formato de un Paquete de Petición de ecífico.

La Fig. 84 ilustra el formato de un Paquete de Lista de Respuesta de Estado Válido.

La Fig. 85A ilustra el formato de un Paquete de Parámetros de Retardo de Procesamiento de Paquete.

La Fig. 85B ilustra el formato de un elemento de la Lista de Parámetros de Retardo.

La Fig. 86 ilustra el formato de un Paquete de Capacidad de Visualización Personal.

La Fig. 87A ilustra el formato de un Paquete de Informe de Errores de Cliente.

La Fig. 87B ilustra el formato de un elemento de la Lista de Informe de Errores.

La Fig. 88 ilustra el formato de un Paquete de Identificación de Cliente.

La Fig. 89 ilustra el formato de un Paquete de Capacidad de Visualización Alternativa.

La Fig. 90 ilustra el formato de un Paquete de Acceso a Registro.

Las Figs. 91A a 91C ilustran el uso de dos almacenes temporales de visualización para reducir artefactos visibles.

La Fig. 92 ilustra dos almacenes temporales con un refresco de visualización más rápido que la transferencia de imagen.

La Fig. 93 ilustra dos almacenes temporales con refresco de visualización más lento que la transferencia de la imagen.

La Fig. 94 ilustra dos almacenes temporales con refresco de visualización mucho más rápido que la transferencia de imagen.

La Fig. 95 ilustra tres almacenes temporales con refresco de visualización más rápido que la transferencia de imagen.

La Fig. 96 ilustra tres almacenes temporales con refresco de visualización más lento que la transferencia de la imagen.

La Fig. 97 ilustra un almacén temporal con refresco de imagen más rápido que la transferencia de imagen.

La Fig. 98 ilustra la conexión servidor-cliente mediante encadenamiento activo y concentrador.

La Fig. 99 ilustra dispositivos cliente conectados mediante una combinación de concentradores y encadenamientos activos.

La Fig. 100 ilustra un mapa de colores.

Descripción detallada de las realizaciones I. Visión de Conjunto

Un propósito general de la invención es proporcionar una interfaz móvil de datos digitales (MDDI), como se expone más adelante, lo que da como resultado, o proporciona, un mecanismo de transferencia efectivo en costes, de bajo consumo de potencia, que hace posible una transferencia de datos a alta o a muy alta velocidad por un enlace de comunicaciones de corto alcance entre un dispositivo servidor y un dispositivo cliente, tal como un elemento de visualización, usando un enlace o un canal de datos de tipo "serie". Este mecanismo se presta a la implementación con conectores en miniatura y con cables flexibles y delgados que son especialmente útiles en la conexión de elementos de visualización internos (a una carcasa o a una estructura de soporte) o dispositivos de entrada a un controlador central, o elementos o dispositivos de visualización externos tales como micropantallas para llevar consigo (antiparras o proyectores) a ordenadores portátiles, dispositivos de comunicaciones inalámbricos, o dispositivos de entretenimiento.

Aunque los términos Móvil y Visualización están asociados a la denominación del protocolo, se comprenderá que esto es solamente por conveniencia, en términos de tener un nombre estándar fácilmente comprensible por aquellos expertos en la técnica que trabajen con la interfaz y el protocolo. Sin embargo, se comprenderá rápidamente, después de una revisión de las realizaciones presentadas más adelante, que muchas aplicaciones no relacionadas con lo móvil y lo visualizable se beneficiarán de la aplicación de este protocolo y la estructura de interfaz resultante, y que la etiqueta MDDI no está concebida para implicar ninguna limitación en la naturaleza o en la utilidad de la invención o de sus varias realizaciones.

Una ventaja de las realizaciones de la invención es que se proporciona una técnica para la transferencia de datos que es de baja complejidad, de bajo coste, tiene una alta fiabilidad, se ajusta bien dentro del entorno de utilización y es muy robusta, mientras que a la vez se mantiene muy flexible.

Las realizaciones de la invención se pueden usar en una gran variedad de situaciones para comunicar o para transferir grandes cantidades de datos, por lo general para audio, vídeo, o aplicaciones multimedia desde un dispositivo servidor o fuente, en el que se generan o se almacenan dichos datos, a una pantalla o dispositivo de presentación de cliente, a alta velocidad. Una aplicación típica, que se trata más adelante, es la transferencia de datos desde un ordenador portátil o un teléfono o módem inalámbricos a un dispositivo de pantalla visual tal como una pequeña pantalla de vídeo o un aparato de microvisualización para llevar consigo, tal como en forma de anteojos o cascos que contienen pequeñas lentes y pantallas de proyección, o desde un servidor a un dispositivo cliente dentro de tales componentes. Esto es, desde un procesador a una pantalla interna u otro elemento de presentación, así como desde varios dispositivos de entrada internos o externos que empleen un cliente, a un servidor localizado internamente (colocado dentro de la misma carcasa o estructura de soporte de dispositivo).

Las características o atributos de la MDDI son tales que son independientes de la tecnología de visualización o de presentación específica. Éste es un mecanismo sumamente flexible para la transferencia de datos a alta velocidad, con independencia de la estructura interna de los datos, y de los aspectos funcionales de los datos o de las órdenes que implemente. Esto permite la temporización de paquetes de datos que se estén transfiriendo, para su ajuste a fin de adaptarse a la idiosincrasia de dispositivos clientes particulares, tal como para deseos de pantalla única para ciertos dispositivos, o para cumplir con los requisitos de audio y vídeo combinados para algunos sistemas A-V, o para ciertos dispositivos de entrada tales como joysticks, panel táctil, etc. La interfaz es muy agnóstica para un elemento de visualización o dispositivo cliente, mientras se siga el protocolo seleccionado. Además, los datos compuestos de enlace en serie, o la velocidad de datos, pueden cambiar en varias órdenes de magnitud, lo que permite a un diseñador de un sistema de comunicaciones o de un dispositivo servidor optimizar el coste, los requisitos de potencia, la complejidad del dispositivo cliente y las velocidades de actualización del dispositivo cliente.

La interfaz de datos se presenta en primer lugar para su uso en la transferencia de grandes cantidades de datos a alta velocidad por un enlace de señal "por cable" o un pequeño cable. Sin embargo, algunas aplicaciones pueden asimismo aprovechar la ventaja de un enlace inalámbrico, incluyendo enlaces basados en óptica, con tal de que esté configurado para usar el mismo paquete y estructuras de datos desarrollados para el protocolo de la interfaz, y pueda sostener el nivel deseado de transferencia a un consumo de potencia, o complejidad, que sean lo suficientemente bajos como para seguir siendo prácticos.

II. Entorno

En las Figs. 1A y 1B se puede ver una aplicación típica en la que se muestran un ordenador portátil 100 y un teléfono inalámbrico o dispositivo PDA 102 comunicando datos con los dispositivos 104 y 106 de visualización, respectivamente, junto con sistemas 108 y 112 de reproducción de audio. Además, la Fig. 1A muestra conexiones potenciales a un visor o pantalla 114 más grande, o a un proyector 116 de imágenes, que solamente se muestran en una figura por razones de claridad, pero que se pueden conectar asimismo a un dispositivo inalámbrico 102. El dispositivo inalámbrico puede estar recibiendo datos actualmente, o haber almacenado previamente una cierta cantidad de datos de tipo multimedia en un elemento de memoria o dispositivo para su presentación posterior, para visualización y/o audición por parte de un usuario final del dispositivo inalámbrico. Como se usa un dispositivo inalámbrico típico para la voz y comunicaciones de texto sencillas la mayoría del tiempo, tiene una pantalla de visualización más bien pequeña y un sencillo sistema de audio (altavoces) para comunicar información al usuario 102 del dispositivo.

El ordenador 100 tiene una pantalla mucho más grande, pero un sistema de sonido externo aún inadecuado, y todavía queda corto respecto a otros dispositivos de presentación multimedia tales como una televisión de alta definición, o pantallas de cine. El ordenador 100 se usa para propósitos de ilustración, y otros tipos de procesadores, videojuegos interactivos o dispositivos electrónicos de consumo también se pueden usar con la invención. El ordenador 100 puede emplear, pero no está limitado a, o por, un módem inalámbrico u otro dispositivo incorporado para las comunicaciones inalámbricas, o ser conectado a dichos dispositivos usando un cable o un enlace inalámbrico, según se desee.

Esto hace que la presentación de datos más complejos o "ricos" sea menos que una experiencia útil o agradable. Por lo tanto, la industria está desarrollando otros mecanismos y dispositivos para presentar la información a los usuarios finales y proporcionar un nivel mínimo de disfrute deseado o de experiencia positiva.

Como se ha tratado con anterioridad, se han desarrollado o están actualmente en desarrollo varios tipos de dispositivos de visualización para la presentación de información a los usuarios finales del dispositivo 100. Por ejemplo, una o más empresas han desarrollado conjuntos de anteojos de vestir que proyectan una imagen en frente de los ojos de un usuario del dispositivo para presentar una representación visual. Cuando se colocan correctamente dichos dispositivos "proyectan" de manera efectiva una imagen virtual, según es percibida por los ojos de un usuario, que es mucho mayor que el elemento que proporciona la salida visual. Esto es, un elemento de proyección muy pequeño permite que el ojo o los ojos del usuario "vean" las imágenes en una escala mucho mayor que la que es posible con típicas pantallas LCD y similares. El uso de imágenes de pantalla virtual más grandes permite también el uso de imágenes de resolución mucho más alta que las que son posibles con visualizaciones de pantalla LCD más limitadas. Otros dispositivos de visualización podrían incluir, pero no están limitados a, pequeñas pantallas LCD o varios elementos de visualización de panales planos, lentes de proyección y controladores de visualización para la proyección de imágenes sobre una superficie, etc.

Puede que haya también elementos adicionales conectados con, o asociados al uso de, un dispositivo inalámbrico 102 u ordenador 100 para presentar una salida a otro usuario, o a otro dispositivo que a su vez transfiere las señales a algún lugar más o las almacena. Por ejemplo, los datos se pueden almacenar en una memoria flash, en formato óptico, por ejemplo, usando un medio de CD sobre el que se pueda escribir o sobre un medio magnético tal como en un grabador de cinta magnética y dispositivos similares, para su uso posterior.

Además, muchos dispositivos inalámbricos y ordenadores tienen ahora capacidades de descodificación de música MP3 incorporadas, así como otros descodificadores y sistemas de sonido avanzado. Los ordenadores portátiles utilizan capacidades de reproducción de CD y DVD por regla general, y algunos tienen pequeños lectores de memoria flash dedicados para recibir los ficheros de audio pregrabados. La cuestión, al tener dichas capacidades, es que los ficheros de música digitales prometen una experiencia rica en características sumamente aumentada, pero solamente si el proceso de descodificación y de reproducción pueden mantener el ritmo. Lo mismo se cumple para los ficheros de vídeo digitales.

Para colaborar en la reproducción del sonido, se muestran los altavoces externos 114 en la Fig. 1A, que podrían estar acompañados también por elementos adicionales tales como altavoces de graves, o altavoces de "sonido envolvente" para la proyección de sonido frontal y trasera. Al mismo tiempo, los altavoces o auriculares 108 están indicados como incorporados a la estructura o mecanismo de soporte del dispositivo 106 de microvisualización de la Fig. 1B. Como se debería saber, se pueden usar otros elementos de reproducción de audio o de sonido, incluyendo dispositivos de amplificación de potencia o dispositivos de ecualización del sonido.

En cualquier caso, como se ha tratado 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, desde una fuente de datos a un usuario final, por uno o más enlaces 110 de comunicaciones, se requiere una alta velocidad de datos. Esto es, el enlace 110 de transferencia es claramente un cuello de botella potencial en la comunicación de datos, como se ha tratado con anterioridad, y está limitando el rendimiento del sistema, ya que los mecanismos de transferencia actuales no consiguen las altas velocidades de datos que se desean típicamente. Como se ha tratado con anterioridad, por ejemplo, para resoluciones de imagen superiores, tales como 1024 por 1024 píxeles, con profundidades de color de 24 a 32 bits por píxel y a velocidades de datos de 30 tps (tramas por segundo), las velocidades de datos se pueden aproximar a velocidades por encima de los 755 Mbps, o más. Además, dichas imágenes se pueden presentar como parte de una presentación multimedia que incluya datos de audio y señales potencialmente adicionales que traten con juegos interactivos o con comunicaciones, o varias órdenes, controles o señales, que aumenten adicionalmente la cantidad de datos y la velocidad de datos.

También está claro que menos cables o interconexiones necesarias para el establecimiento de un enlace de datos, significa que los dispositivos móviles asociados con una visualización son más fáciles de usar, y que es más probable que sean adoptados por una base más grande de usuarios. Esto es especialmente verdadero allí donde múltiples dispositivos se usen comúnmente para establecer una experiencia audiovisual completa y, de manera más especial, a medida que aumente el nivel de calidad de las visualizaciones y los dispositivos de salida de audio.

Otra aplicación típica relacionada con muchas de las mejoras anteriores, y otras, en pantallas de vídeo y otros dispositivos de salida o de entrada, pueden verse en las Figs. 1C y 1D, en las que se muestra un ordenador portátil 130 y un teléfono inalámbrico o dispositivo PDA 140 comunicando datos con dispositivos 134 y 144 de visualización "internos", respectivamente, junto con sistemas 136 y 146 de reproducción de audio.

En las Figs. 1C y 1D, se usan secciones recortadas pequeñas de dispositivos o productos electrónicos globales para mostrar la localización de uno o más servidores y controladores internos en una parte del dispositivo, con un enlace de comunicaciones generalizado, aquí 138 y 148, respectivamente, conectándolos a los elementos o pantallas de visualización de vídeo que tengan los correspondientes clientes, a través de una unión giratoria de algún tipo conocido usado en toda la industria de la electrónica actual. Uno 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 comunicaciones se aproximan a los 90 o más conductores con el fin de satisfacer las necesidades de crecimiento actuales para la utilización de interfaces avanzadas de color y gráficas, y elementos de visualización sobre dichos dispositivos, debido a los tipos de técnicas de interfaces paralelas u otras técnicas de interfaces conocidas, disponibles para la transferencia de dichos datos.

Desafortunadamente, las velocidades de datos más altas sobrepasan la tecnología actual disponible para la transferencia de datos. Tanto en términos de cantidad bruta de datos que se necesita transferir por unidad de tiempo, como en términos de fabricación de mecanismos de transferencia física fiable efectiva en costes.

Lo que se necesita es una técnica para la transferencia de datos a velocidades más altas para el enlace de transferencia de datos o el trayecto de comunicaciones entre elementos de presentación y la fuente de datos, lo que permite una potencia consecuentemente baja (inferior), un peso ligero y una estructura de cableado tan simple y tan económica como sea posible. Los solicitantes han desarrollado una nueva técnica, o un procedimiento y un aparato, para conseguir éstos y otros objetivos, a fin de permitir que una formación de dispositivos móviles, portátiles o de localización incluso fija, transfiera datos a pantallas deseadas, micropantallas o elementos de transferencia de audio, a velocidades de datos muy altas, a la vez que se mantiene un bajo consumo de potencia y una baja complejidad deseados.

III. Arquitectura de Sistema de Interfaz de Datos Digitales de Alta Velocidad

Con el fin de crear y utilizar de manera eficiente una nueva interfaz de dispositivo, se ha formulado una arquitectura de protocolo de señal y de sistema que proporciona una muy alta velocidad de transferencia de datos usando señales de baja potencia. El protocolo se basa en una estructura de paquetes y de tramas comunes, o en estructuras enlazadas conjuntamente para formar un protocolo a fin de comunicar un conjunto preseleccionado de datos o de tipos de datos, junto con una orden o estructura operativa impuesta sobre la interfaz.

A. Visión de Conjunto

Los dispositivos conectados por, o que se comunican por el enlace MDDI, son denominados el servidor y el cliente, siendo el cliente, típicamente, un dispositivo de visualización de algún tipo, aunque se contemplan otros dispositivos de entrada y de salida. Los datos provenientes del servidor hacia la pantalla viajan en la dirección directa (a lo que se hace referencia como tráfico o enlace directo), y los datos desde el cliente al servidor viajan en la dirección inversa (tráfico o enlace inverso), según lo habilita el servidor. Esto se ilustra en la configuración básica que se muestra en la Fig. 2. En la Fig. 2, se conecta un servidor 202 a un cliente 204 usando un canal 206 de comunicación bidireccional que se ilustra comprendiendo un enlace directo 208 y un enlace inverso 210. Sin embargo, estos canales están formados por un conjunto común de conductores cuya transferencia de datos se conmuta de manera efectiva entre las operaciones del enlace directo o del enlace inverso. Esto permite números sumamente reducidos de conductores, lo que aborda de manera inmediata uno de muchos problemas a los que se hace frente con las aproximaciones actuales a la transferencia de datos a alta velocidad en entornos de baja potencia tales como para dispositivos electrónicos móviles.

Como se ha tratado en otra parte, el servidor comprende uno entre varios tipos de dispositivos que se pueden beneficiar del uso de la presente invención. Por ejemplo, el servidor 202 podría ser un ordenador portátil en forma de un ordenador de mano, portátil, o dispositivo de cómputo móvil similar. También podría ser un asistente de datos digital (PDA), un dispositivo de radiobúsqueda o uno entre muchos teléfonos o módems inalámbricos. De manera alternativa, el servidor 202 podría ser un dispositivo de entretenimiento o de presentación portátil, tal como un reproductor de DVD o de CD portátil, o un dispositivo de juegos.

Además, el servidor puede residir, como un dispositivo servidor o como un elemento de control, en una gran variedad de otros productos comerciales ampliamente usados o planificados, para los que se desea un enlace de alta velocidad con un cliente. Por ejemplo, un servidor se podría usar para transferir datos a altas velocidades desde un dispositivo grabador de vídeo a un cliente basado en almacenamiento para una respuesta mejorada, o a una pantalla más grande de alta resolución, para presentaciones. Un electrodoméstico tal como un refrigerador, que incorpore un inventario o un sistema de ordenador de a bordo, y/o conexiones Bluetooth a otros dispositivos domésticos, puede tener capacidades de visualización mejoradas cuando funcione en un modo conectado a Internet o a Bluetooth, o tener necesidades reducidas de cableado para las pantallas de portada (un cliente) y teclados o escáneres (cliente) mientras que el ordenador electrónico o los sistemas de control (servidor) residen en algún lugar en la carcasa. En general, los que sean expertos en la técnica apreciarán la amplia variedad de dispositivos y aparatos electrónicos modernos que se pueden beneficiar del uso de esta interfaz, así como la capacidad para retroajustar dispositivos más antiguos con transporte de información a velocidad de datos más alta utilizando números limitados de conductores disponibles en conectores o cables nuevos añadidos o ya existentes.

Al mismo tiempo, el cliente 204 podría comprender una gran variedad de dispositivos útiles para presentar información a un usuario final, o para presentar información desde un usuario al servidor. Por ejemplo, una micropantalla incorporada en antiparras o gafas, un dispositivo de proyección incorporado a un gorro o un casco, una pequeña pantalla o incluso un elemento holográfico incorporado a un vehículo, tal como en una ventana o en un parabrisas, o varios sistemas de altavoces, cascos o 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 televisión. Otro ejemplo sería el uso de paneles táctiles o dispositivos sensibles, dispositivos de entrada de reconocimiento de la voz, escáneres de seguridad, etc., a los que se puede invocar para transferir una cantidad significativa de información desde un usuario de dispositivo o de sistema, con poca "entrada" real que no sea la táctil o la sonora del usuario. Además, las estaciones de atraque para ordenadores y kits de coches o kits de sobremesa, y los soportes para teléfonos inalámbricos, pueden actuar como dispositivos de interfaz para los usuarios finales o para otros dispositivos y equipos, y pueden emplear bien clientes (dispositivos de salida y de entrada tales como ratones) o servidores para ayudar en la transferencia de datos, especialmente cuando estén implicadas redes de alta velocidad.

Sin embargo, los que sean expertos en la técnica reconocerán con facilidad que la presente invención no está limitada a estos dispositivos, habiendo muchos otros dispositivos en el mercado, y propuestos para su uso, que están concebidos para proporcionar a los usuarios finales imágenes y sonido de alta calidad, ya sea en términos de almacenamiento y transporte o en términos de presentación en la reproducción. La presente invención es útil en el incremento del caudal de datos entre varios elementos o dispositivos para asimilar las altas velocidades de datos necesarias para realizar la experiencia deseada del usuario.

La interfaz MDD inventiva y el protocolo de señal de comunicación se pueden usar para simplificar la interconexión entre un procesador, un controlador o un componente de circuito (por ejemplo) de un servidor, y una pantalla dentro de un dispositivo o carcasa o estructura de dispositivo (a la que se denomina modalidad interna) con el fin de reducir el coste o la complejidad y la potencia asociada y los requisitos de control o restricciones de estas conexiones, y para mejorar la fiabilidad, no sólo para la conexión a, o para, elementos, dispositivos o equipos externos (a la que se denomina modalidad externa).

La velocidad compuesta de datos de enlace en serie sobre cada par de señales usadas por esta estructura de interfaz puede variar sobre muchos órdenes de magnitud, lo que permite a un diseñador de sistemas o de dispositivos optimizar fácilmente costes, potencia, complejidad de implementación, y la velocidad de actualización de la pantalla para una aplicación o propósito dados. Los atributos de MDDI son independientes de la pantalla o de otra tecnología de dispositivos de presentación (cliente objetivo). La temporización de paquetes de datos transferidos a través de la interfaz se puede ajustar fácilmente para adaptarse a la idiosincrasia de clientes particulares tales como dispositivos de visualización, sistemas de sonido, memoria y elementos de control, o requisitos de temporización combinados de sistemas de audio-vídeo. Mientras que esto hace posible tener un sistema con un consumo de muy baja potencia, no es un requisito de los diversos clientes tener memorias de almacenamiento temporal de tramas con el fin de hacer uso del protocolo MDDI, a algún nivel al menos.

B. Tipos de Interfaz

La interfaz MDD se contempla como abordando al menos cuatro, y potencialmente más, tipos físicos algo distintos de interfaces que se encuentran en las industrias de las comunicaciones y de los ordenadores. Éstas están etiquetadas simplemente como Tipo 1, Tipo 2, Tipo 3 y Tipo 4, aunque los que sean expertos en la técnica pueden aplicar otras etiquetas o designaciones, según las aplicaciones específicas para las que se usen, o la industria a la cual estén asociadas. Por ejemplo, los sistemas de audio sencillos usan menos conexiones que los sistemas multimedia más complejos, y pueden hacer referencia a características tales como "canales" de manera diferente, etc.

La interfaz de Tipo 1 está configurada como una interfaz de 6 hilos, o de otro tipo de conductor o elemento conductor, que la hace adecuada para teléfonos móviles o inalámbricos, PDA, 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 de consumo. En una realización, una interfaz se puede configurar como una interfaz de 8 hilos (conductores) que es más adecuada para ordenadores portátiles, de mano o personales de sobremesa, y dispositivos o aplicaciones similares, que no requieran rápidas actualizaciones de datos y que no tengan un controlador de enlace MDDI incorporado. Este tipo de interfaz también se puede distinguir por la utilización de una interfaz adicional de Bus en Serie Universal (USB) de dos hilos, que es extremadamente útil para asimilar los sistemas operativos existentes o el soporte de software encontrado en la mayoría de los ordenadores personales.

Las interfaces de Tipo 2, de Tipo 3 y de Tipo 4 son adecuadas para clientes o dispositivos de alto rendimiento y usan un cableado complejo más grande, con conductores adicionales de tipo de par trenzado para proporcionar el apantallamiento adecuado y transferencias de bajas pérdidas para las señales de datos.

La interfaz de Tipo 1 pasa señales que pueden comprender información de visualización, audio, control y señalización limitada, y se usa, típicamente, para clientes móviles o dispositivos de clientes que no requieren datos de vídeo de alta resolución a velocidad máxima. Una interfaz de Tipo 1 puede soportar fácilmente resolución SVGA a 30 tps más canal de audio 5.1, y en una configuración mínima podría usar solamente tres pares de hilos en total, dos pares para la transmisión de datos y un par para la transferencia de potencia. Este tipo de interfaz está principalmente concebida para dispositivos tales como dispositivos inalámbricos móviles, en los que un servidor USB no se encuentra disponible, típicamente, dentro de dicho dispositivo para la conexión y para la transferencia de señales. En esta configuración, el dispositivo inalámbrico móvil es un dispositivo servidor MDDI, y actúa como el "maestro" que controla el enlace de comunicaciones desde el servidor que, por lo general, envía datos al cliente (tráfico o enlace directo) para la presentación, visualización o reproducción.

En esta interfaz, un servidor habilita la recepción de datos de comunicaciones en el servidor provenientes del cliente (tráfico o enlace inverso) por medio del envío de una orden especial o tipo de paquete al cliente que le permita controlar el bus (enlace) durante un lapso especificado y enviar datos al servidor como paquetes inversos. Esto se ilustra en la Fig. 3, en la que un tipo de paquete al que se hace referencia como un paquete de encapsulamiento (que se trata más adelante) se usa para asimilar la transferencia de paquetes inversos por el enlace de transferencia, creando el enlace inverso. El intervalo de tiempo asignado al servidor para sondear al cliente en busca de datos viene predeterminado por el servidor, y se basa en los requisitos de cada aplicación especificada. Este tipo de transferencia de datos semidúplex bidireccional es especialmente ventajosa allí donde un puerto USB no se encuentra disponible para la transferencia de información o de datos desde el cliente.

Los visores de alto rendimiento capaces de altas resoluciones de tipo HDTV o similares requieren aproximadamente 1,5 Gbps de velocidad para flujos de datos con el fin de brindar soporte a vídeo de movimiento total. La interfaz de Tipo 2 brinda soporte a altas velocidades de datos transmitiendo 2 bits en paralelo, el Tipo 3 por medio de la transmisión de 4 bits en paralelo, y la interfaz de Tipo 4 transfiere 8 bits en paralelo. Las interfaces de Tipo 2 y de Tipo 3 usan el mismo cable y conector que el Tipo 1 pero pueden funcionar al doble y al cuádruple de la velocidad de datos para brindar soporte a aplicaciones de vídeo de altas prestaciones en dispositivos portátiles. Una interfaz de Tipo 4 es adecuada para clientes de muy alto rendimiento o para visualizaciones, y requiere un cable ligeramente mayor que contenga señales de datos de pares trenzados adicionales.

El protocolo usado por la MDDI permite a cada servidor de Tipo 1, 2, 3 ó 4 comunicarse generalmente con cualquier cliente de tipo 1, 2, 3 ó 4 por medio de la negociación de cuál es la velocidad de datos más alta posible que se puede usar. Las capacidades o las características disponibles de lo que se puede denominar el dispositivo menos capaz se usan para fijar el rendimiento del enlace. Como regla, incluso para sistemas en los que el servidor y el cliente sean ambos capaces de usar interfaces de Tipo 2, de Tipo 3 o de Tipo 4, ambos comienzan la operación como una interfaz de Tipo 1. El servidor determina entonces la capacidad del cliente señalado, y negocia una operación de traspaso o reconfiguración para la modalidad de Tipo 2, Tipo 3 ó Tipo 4, según sea apropiado para la aplicación particular.

Por lo general es posible para el servidor usar el protocolo de capa de enlace apropiado (tratado de manera adicional más adelante) y reducir o reconfigurar de nuevo el funcionamiento, por lo general en cualquier momento, a una modalidad más lenta para ahorrar energía, o aumentar a una modalidad más rápida para brindar soporte a transferencias de velocidad más alta, tales como para un contenido de visualización de resolución superior. Por ejemplo, un servidor puede cambiar los tipos de interfaz cuando el sistema conmute desde una fuente de alimentación, tal como una batería, a una alimentación de corriente alterna, o cuando la fuente de los medios de visualización conmute a un formato de resolución inferior o superior, o bien una combinación de estas u otras condiciones o sucesos se puedan considerar como una base para cambiar un tipo de interfaz, o modalidad de transferencia.

También es posible para un sistema comunicar datos usando una modalidad en una dirección y otra modalidad en otra dirección. Por ejemplo, una modalidad de interfaz de Tipo 4 se podría usar para transferir datos a un visor a alta velocidad, mientras que una modalidad de Tipo 1 se usa cuando se transfieren datos a un dispositivo servidor desde dispositivos periféricos tales como un teclado o un dispositivo puntero. Alguien que sea experto en la técnica apreciará que los servidores y los clientes pueden comunicar datos salientes a diferentes velocidades.

A menudo, los usuarios del protocolo MDDI pueden distinguir entre una modalidad "externa" y una modalidad "interna". Una modalidad externa describe el uso del protocolo y la interfaz para conectar un servidor en un dispositivo a un cliente fuera de ese dispositivo que esté aproximadamente hasta 2 metros del servidor. En esta situación, el servidor puede enviar también energía al cliente externo de forma que ambos dispositivos puedan funcionar fácilmente en un entorno móvil. Una modalidad interna describe cuándo el servidor está conectado a un cliente contenido dentro del mismo dispositivo, tal como dentro de una carcasa, o armazón o estructura de soporte común de algún tipo. Un ejemplo serían aplicaciones dentro de un teléfono inalámbrico u otro dispositivo inalámbrico, o un ordenador portátil o dispositivo de juegos en los que el cliente es una pantalla o un controlador de pantalla, o un dispositivo de entrada tal como un teclado o panel táctil, o bien un sistema de sonido, y el servidor es un controlador central, un motor de gráficos o un elemento de CPU. Como un cliente se sitúa mucho más cerca del servidor en aplicaciones de modalidad interna, al contrario que en aplicaciones de modalidad externa, por lo general no se exponen requisitos para la conexión de alimentación al cliente en dichas configuraciones.

C. Estructura de Interfaz Física

La disposición general de un dispositivo o de un controlador de enlace, para el establecimiento de las comunicaciones entre un dispositivos servidores y clientes se muestra en las Figs. 4 y 5. En las Figs. 4 y 5, se muestra un controlador 402 y 502 de enlace MDDI instalado en un dispositivo servidor 202, y un controlador 404 y 504 de enlace MDDI se muestra instalado en un dispositivo cliente 204. Como antes, el servidor 202 está conectado a un cliente 204 usando un canal 406 de comunicaciones bidireccional que comprende una serie de conductores. Como se expone más adelante, tanto el servidor como los controladores de enlace cliente se pueden fabricar como un circuito integrado usando un único diseño de circuito que se pueda fijar, ajustar o programar para responder ya sea como controlador de servidor (conductor) o como un controlador de cliente (receptor). Esto proporciona costes más bajos debido a la fabricación a mayor escala de un único dispositivo de circuito.

En la Fig. 5, se muestra un controlador 502 de enlace MDDI instalado en un dispositivo servidor 202' y un controlador 504 de enlace MDDI se muestra instalado en un dispositivo cliente 204'. Como antes, el servidor 202' está conectado a un cliente 204' usando un canal 506 de comunicación bidireccional que comprende una serie de conductores. Como se ha expuesto antes, tanto el servidor como los controladores de enlace de cliente se pueden fabricar usando un único diseño de circuito.

Las señales que se hacen pasar entre un servidor y un cliente, tal como un dispositivo de visualización, por el enlace MDDI, o los conductores físicos usados, también se ilustran en las Figs. 4 y 5. Como se puede ver en las Figs. 4 y 5, el trayecto o mecanismo primarios para transferir datos a través de la MDDI usa señales de datos etiquetadas como MDDI_Data0+/- y MDDI_Stb+/-. Cada una de éstas son señales de datos de baja tensión que son transferidas por un par diferencial de hilos en un cable. Solamente existe una transición bien en el par MDDI_Data0 o bien en el par MDDI-Stb para cada bit enviado por la interfaz. Éste es un mecanismo de transferencia basado en tensión, no basado en corriente, de forma que el consumo estático de corriente es casi cero. El servidor alimenta las señales MDDI_Stb para la visualización del cliente.

Mientras que los datos puedan fluir en ambas direcciones directa e inversa por los pares MDDI_Data, es decir, es un trayecto de transferencia bidireccional, el servidor es el maestro o el controlador del enlace de datos. Los trayectos de las señales MDDI_Data0 y de MDDI-Stb son operados en modalidad diferencial para maximizar la inmunidad al ruido. La velocidad de datos para las señales en estas líneas viene determinada por la velocidad del reloj enviada por el servidor, y es variable sobre un intervalo de aproximadamente 1 kbps hasta 400 Mbps o más.

La interfaz de Tipo 2 contiene un par de datos, o conductores o trayectos, adicionales más allá de los del Tipo 1, a los que se hace referencia como MDDI_Data11+/-. La interfaz de Tipo 3 contiene dos pares de datos, o trayectos de señal, adicionales más allá de los de la interfaz de Tipo 2 a los que se hace referencia como MDDI_Data2+/-, y MDDI_Data3+/-. La interfaz de Tipo 4 contiene cuatro pares de datos o trayectos de señal más, por encima de los de la interfaz de Tipo 3 a los que se hace referencia como: MDDI_data4+/-, MDDI_Data5+/-, MDDI_Data6+/-,
y MDDI_Data7+/-, respectivamente. En cada una de las anteriores configuraciones de interfaz, un servidor puede enviar alimentación al cliente o a la pantalla usando el par de hilos o las señales designadas como HOST_Pwr y HOST_Gnd. Como se expone adicionalmente más adelante, la transferencia de potencia también se puede asimilar, si se desea, en algunas configuraciones sobre los conductores MDDI_data4+/-, MDDI_Data5+/-, MDDI_Data6+/- o MDDI-_Data7+/- cuando se está usando un "Tipo" de interfaz que emplea menos conductores que los que se encuentran disponibles o presentes para las otras modalidades. Esta transferencia de potencia se emplea por lo general para modalidades externas, no habiendo por lo general necesidad de modalidades internas, aunque algunas aplicaciones puedan diferir.

Un resumen de las señales pasadas entre el servidor y el cliente (pantalla) por el enlace MDDI para varias modalidades se ilustra en la tabla I, a continuación, de acuerdo al tipo de la interfaz.

TABLA I

1

Nótese también que las conexiones HOST_Pwr/Gnd para la transferencia desde el servidor se proporcionan, por lo general, para las modalidades externas. Las aplicaciones o las modalidades de funcionamiento internos, por lo general, tienen clientes que extraen energía directamente desde otros recursos internos, y no usan MDDI para controlar la distribución de potencia, como sería obvio para alguien que sea experto en la técnica, por lo que tal distribución no se trata en mayor detalle en este documento. Sin embargo, es ciertamente posible permitir que la potencia se distribuya a través de la interfaz MDDI, para permitir ciertas clases de control de potencia, sincronización o conveniencia de interconexión, por ejemplo, como comprendería alguien que sea experto en la técnica.

El cableado generalmente usado para implementar la estructura y funcionamiento anteriores es nominalmente del orden de 1,5 metros de longitud, generalmente de 2 metros o menos, y contiene tres pares trenzados de conductores, siendo cada uno a su vez cable multi-hebra 30 AWG. Una cubierta de pantalla de aluminio se envuelve, o se forma de otra manera, por encima de los tres pares trenzados, como un cable de drenado adicional. Los pares trenzados y el conductor de drenado de pantalla terminan en el conector de cliente con la pantalla conectada a la pantalla para el cliente, y hay una capa aislante, que cubre todo el cable, como es bien conocido en la técnica. Los cables están pareados como: HOST_Gnd con HOST_Pwr; MDDI_Stb+ con MDDI_Stb-; MDDI_Data0+ con MDDI_Data0-;
MDDI_Data1+ con MDDI_Data1; etc.

D. Tipos y Velocidades de Datos

Para conseguir una interfaz útil para un abanico completo de experiencias y aplicaciones de usuario, la interfaz digital de datos móviles (MDDI) proporciona soporte para una gran variedad de clientes y para información de visualización, transductores de audio, teclados, dispositivos punteros y muchos otros dispositivos de entrada o salida que se podrían integrar o que podrían funcionar de manera coordinada con un dispositivo de visualización móvil, junto con información de control, y combinaciones de las mismas. La interfaz MDD está diseñada para poderse acomodar a una gran variedad de tipos potenciales de flujos de datos que circulan entre el servidor y el cliente, bien en la dirección de enlace directo o bien en la dirección de enlace inverso, usando un número mínimo de cables o conductores. Se brinda soporte tanto a flujos isócronos como a flujos asíncronos (actualizaciones). Son posibles muchas combinaciones de tipos de datos mientras la velocidad de datos compuestos sea menor o igual a la velocidad de enlace MDDI máxima deseada, que está limitada por la velocidad máxima en serie y por el número de emisiones de datos empleadas. Éstas podrían incluir, pero no se limitan a, aquellos elementos que se enumeran en las Tablas Mano III a continuación.

TABLA II

2

TABLA III

3

La interfaz no es fija, sino extensible de manera que pueda soportar la transferencia de una gran variedad de "tipos" de información que incluyen datos definidos por el usuario, para flexibilidad futura del sistema. Ejemplos específicos de datos para ser asimilados son: vídeo con movimiento completo, en forma de campos de mapa de bits de pantalla, bien completa o bien parcial, o vídeo comprimido; mapas de bits estáticos a bajas velocidades para conservar la potencia y reducir los costes de implementación; datos de PCM o de audio comprimidos en una gran variedad de resoluciones o de velocidades; posición y selección de dispositivo puntero, y datos definibles por el usuario para capacidades aún por ser definidas. Tales datos también se pueden transferir junto con información de control o de estado para detectar capacidad de dispositivo o fijar parámetros operativos.

Las realizaciones de la invención adelantan la técnica para su utilización en transferencias de datos que incluyen, pero que no están limitadas a: ver una película (visualización de vídeo y audio); usar un ordenador personal con visualización personal limitada (pantalla de gráficos, a veces combinada con vídeo y audio); jugar un videojuego en un PC, consola o dispositivo personal (visualización de gráficos en movimiento, o vídeo y audio sintéticos); "navegar" por Internet, usando dispositivos en forma de un videoteléfono (vídeo y audio bidireccionales de baja velocidad), una cámara para imágenes digitales fijas, o una cámara grabadora para capturar imágenes de vídeo digitales; usar un teléfono, ordenador, o PDA amarrado a un proyector para dar una presentación, o a una estación de amarre de sobremesa conectada a un monitor de vídeo, teclado y ratón; y para la mejora de la productividad o el uso para entretenimiento, con teléfonos celulares, teléfonos inteligentes o PDA, incluyendo dispositivos punteros inalámbricos y datos de teclado.

La interfaz de datos de alta velocidad, según se trata a continuación, se presenta en términos de proporcionar grandes cantidades de datos de tipo A-V por un enlace de comunicaciones o transferencia que generalmente se configura como un enlace de tipo línea alámbrica o cable. Sin embargo, será inmediatamente evidente que la estructura de la señal, los protocolos, la temporización o el mecanismo de transferencia se podrían ajustar para proporcionar un enlace en forma de un medio óptico o inalámbrico, si puede sostener el nivel deseado de transferencia de datos.

Las señales de la interfaz MDD usan un concepto conocido como la Velocidad de Trama Común (CFR) para el protocolo o estructura básicos de la señal. La idea tras el uso de una Velocidad de Trama Común es proporcionar un pulso de sincronización para los flujos de datos isócronos simultáneos. Un dispositivo cliente puede usar esta velocidad de trama común como una referencia temporal. Una baja velocidad de CF aumenta la eficiencia del canal disminuyendo la sobrecarga para transmitir la cabecera de subtrama. Por otra parte, una alta velocidad de CF disminuye la latencia, y permite una memoria elástica de almacenamiento temporal de datos más pequeña para las muestras de audio. La velocidad de CF de la presente interfaz inventiva es programable de manera dinámica y se puede fijar en uno entre muchos valores que sean apropiados para los flujos isócronos usados en una aplicación particular. Esto es, el valor de CF se selecciona para que se adapte óptimamente a la configuración dada de cliente y servidor, según se desee.

El número de bytes generalmente requeridos por subtrama, que es ajustable o programable, para los flujos de datos isócronos con más probabilidad de ser usados con una aplicación, tales como para vídeo o microvisor, se muestran en la tabla IV.

TABLA IV

4

Los totales fraccionarios de bytes por subtrama se pueden obtener fácilmente usando una sencilla estructura programable de contador de M/N. Por ejemplo, un total de 26-2/3 bytes por CF se implementa por medio de la transferencia de 2 tramas de 27 bytes cada una, seguidas por una subtrama de 26 bytes. Puede seleccionarse una velocidad de CF menor para producir un número entero de bytes por subtrama. Sin embargo, por lo general, implementar un sencillo contador de M/N en hardware necesitaría menos área dentro de un circuito integrado o módulo electrónico usado para implementar una parte de, o todas, las realizaciones de la invención que el área necesaria para una memoria de almacenamiento temporal FIFO mayor de muestras de audio.

Una aplicación a título de ejemplo que ilustra el impacto de diferentes velocidades de transferencia de datos y de tipos de datos es un sistema Karaoke. Para un Karaoke, un sistema en el que un usuario, o usuarios, final(es), canta(n) junto con un programa de vídeo musical. Las letras de la canción se visualizan en algún lugar, típicamente en la parte inferior de una pantalla de forma que los usuarios conocen la letra que tienen que cantar y, a grandes rasgos, la temporización de la canción. Esta aplicación requiere una pantalla de vídeo con actualizaciones de gráficos poco frecuentes, y la mezcla de la voz, o voces, de usuario, con un flujo de audio estéreo.

Si uno supone una velocidad de trama común de 300 Hz, entonces cada subtrama consistirá en: 92.160 bytes de contenido de vídeo y 588 bytes de contenido de audio (en base a 147 muestras de 16 bits, en estéreo) por el enlace directo al dispositivo de visualización cliente, y se envían de retorno desde un micrófono a la máquina móvil del Karaoke un promedio de 26,67 (26-2/3) bytes de voz. Los paquetes asíncronos se envían entre el servidor y la pantalla, posiblemente montados en cabecera. Esto incluye como mucho 768 bytes de datos gráficos (altura de un cuarto de pantalla), y menos de aproximadamente 200 bytes (varios) para comandos varios de control y de estado.

La tabla V muestra cómo se asignan los datos dentro de una subtrama para el ejemplo del Karaoke. La velocidad total que se esté usando se selecciona para que sea aproximadamente 279 Mbps. Una velocidad ligeramente superior de 280 Mbps permite aproximadamente otros 400 bytes de datos por subtrama a transferir, lo que permite el uso de mensajes ocasionales de control y estado.

TABLA V

5

III. (Continuación) Arquitectura del Sistema de Interfaz de Datos Digital de Alta Velocidad E. Capa de Enlace

Los datos transferidos usando las señales de datos en serie de alta velocidad de la interfaz MDD consisten en un flujo de paquetes multiplexados en el tiempo que son enlazados uno tras otro. Incluso cuando un dispositivo de transmisión no tiene datos para enviar, un controlador de enlace MIDI por lo general envía de manera automática paquetes de relleno, manteniendo de esta manera un flujo de paquetes. El uso de una estructura de paquetes sencilla asegura una temporización isócrona fiable para las señales de vídeo y de audio o para los flujos de datos.

Grupos de paquetes están contenidos dentro de elementos o estructuras de señal, que se denominan subtramas, y los grupos de subtramas están contenidos dentro de elementos o estructuras de señal que se denominan trama de medios. Una subtrama contiene uno o más paquetes, según sus respectivos tamaños y modos de transferencia de datos, y una trama de medios contiene una o más subtramas. La subtrama más grande proporcionada por el protocolo empleado por las realizaciones presentadas aquí es del orden de 2^{32}-1, ó 4.294.967.295 de bytes, y el tamaño de la trama de medios más grande deviene entonces del orden de 2^{16}-1 o 65.535 subtramas.

Un paquete especial de cabecera de subtrama contiene un identificador único que aparece al comienzo de cada subtrama, como se expone más adelante. Ese identificador también se usa para adquirir la temporización de trama en el dispositivo cliente cuando se inicia la comunicación entre el servidor y el cliente. La adquisición de temporización de enlace se trata con más detalle a continuación.

Típicamente, una pantalla de visualización se actualiza una vez por cada trama de medios cuando se está visualizando vídeo con movimiento completo. La velocidad de trama visualizada es la misma que la velocidad de trama de medios. El protocolo de enlace brinda soporte a vídeo de movimiento completo sobre una pantalla entera, o sólo a una pequeña región de contenido de vídeo de movimiento completo rodeado por una imagen estática, según la aplicación deseada. En algunas aplicaciones móviles de baja potencia, tales como la visualización de páginas web o el correo electrónico, la pantalla de visualización solamente puede necesitar ser actualizada de manera ocasional. En estas situaciones, es ventajoso transmitir una única subtrama y después apagar o desactivar el enlace para minimizar el consumo de
potencia. La interfaz brinda soporte también a efectos tales como la visión estéreo, y manipula primitivas de gráficos.

Las subtramas permiten a un sistema habilitar la transmisión de paquetes de alta prioridad periódicamente. Esto permite que flujos isócronos simultáneos coexistan con una cantidad mínima de memoria de almacenamiento temporal de datos. Esta es una ventaja que proporcionan las realizaciones para el proceso de visualización, permitiendo que múltiples flujos de datos (comunicación de alta velocidad de vídeo, voz, control, estado, datos de dispositivo puntero, etc.) compartan de manera esencial un canal común. Transfiere información usando relativamente pocas señales. También hace posible la existencia de acciones específicas de la tecnología de la visualización, tales como pulsos de sincronismo
horizontal e intervalos de vacíos para un monitor CRT, o para otras acciones específicas de la tecnología del cliente.

F. Controlador de enlace

El controlador de enlace MDDI mostrado en las Figs. 4 y 5 está fabricado o montado para ser una implementación completamente digital, con la excepción de receptores de línea diferenciales que se usan para recibir datos MDDI y señales de sondeo. Sin embargo, incluso los controladores y los receptores de línea diferenciales se pueden implementar en los mismos circuitos integrados digitales con el controlador de enlace, tal como cuando se hace un IC de tipo CMOS. No se requieren funciones analógicas o lazos enganchados en fase (PLLs) para la recuperación binaria o para implementar el hardware para el controlador de enlace. Los controladores de enlace del servidor y del cliente contienen funciones muy similares, con la excepción de la interfaz de cliente que contiene una máquina de estados para la sincronización de enlace. Por lo tanto, las realizaciones de la invención permiten la ventaja práctica de poder crear un único diseño de controlador o circuito que se pueda configurar bien como un servidor o bien como un cliente, lo que puede reducir los costes de fabricación para los controladores de enlace, en lo general.

IV. Protocolo de Enlace de Interfaz A. Estructura de Trama

El protocolo de señal o la estructura de trama usados para implementar la comunicación de enlace directo para la transferencia de paquetes se ilustra en la Fig. 6. Como se muestra en la Fig. 6, la información o los datos digitales se agrupan en elementos conocidos como paquetes. Múltiples paquetes se agrupan entre sí a su vez para formar lo que se denomina una "subtrama", y múltiples subtramas, a su vez, se agrupan entre sí para formar una trama de "medios". Para controlar la formación de tramas y la transferencia de subtramas, cada una de las subtramas comienza con un paquete especialmente predefinido denominado Paquete de Cabecera de Subtrama (SHP).

El servidor selecciona la velocidad de datos que se va a usar para una transferencia dada. Esta velocidad puede ser cambiada dinámicamente por el dispositivo servidor basándose tanto en la capacidad de transferencia máxima del servidor como en los datos que se están recuperando desde una fuente por parte del servidor, y en la capacidad máxima del cliente, u otro dispositivo al que se están transfiriendo los datos.

Un dispositivo cliente destinatario designado para, o capaz de, trabajar con la MDDI o con el protocolo de señal inventivo es capaz de ser consultado por el servidor para determinar la velocidad de transferencia máxima, o máxima actual, que puede usar, o bien puede usarse una velocidad mínima más lenta por defecto, así como los tipos de datos utilizables y las características que reciben soporte. Esta información se podría transferir usando un Paquete de Capacidad de Cliente (CCP), como se trata adicionalmente más adelante. El dispositivo cliente de visualización es capaz de transferir datos o de comunicarse con otros dispositivos usando la interfaz a una velocidad de datos mínima preseleccionada, o bien dentro de un intervalo de velocidad mínima de datos, y el servidor realizará una consulta usando una velocidad de datos dentro de este intervalo para determinar las capacidades completas de los dispositivos clientes.

Otra información de estado que define la naturaleza del mapa de bits y las capacidades de velocidad de trama de vídeo del cliente se pueden transferir en un paquete de estado al servidor de forma que el servidor pueda configurar la interfaz para que sea tan eficiente u óptima como práctica, o como se desee dentro de cualesquiera restricciones del sistema.

El servidor envía paquetes de relleno cuando no hay (más) paquetes de datos a transferir en la presente subtrama, o cuando el servidor no puede transferir a una velocidad suficiente para conservar el ritmo con la velocidad de transmisión de datos elegida para el enlace directo. Como cada una de las subtramas comienza con un paquete de cabecera de subtrama, el final de la subtrama anterior contiene un paquete (con máxima probabilidad, un paquete de relleno) que rellena exactamente la anterior subtrama. En el caso de una falta de sitio para los paquetes portadores de datos per se, un paquete de relleno será, con máxima probabilidad, el último paquete de una subtrama, o bien estará al final de una siguiente subtrama anterior y antes de un paquete de cabecera de subtrama. Es la tarea de las operaciones de control en un dispositivo servidor asegurar que hay espacio suficiente restante en una subtrama para cada paquete que se haya de transmitir dentro de esa subtrama. Al mismo tiempo, una vez que un dispositivo servidor inicia el envío de un paquete de datos, el servidor debe poder completar con éxito un paquete de ese tamaño dentro de una trama sin incurrir en un estado de infrasuministro de datos.

En un aspecto de las realizaciones, la transmisión de subtramas tiene dos modalidades. Una modalidad es una modalidad de subtrama periódica, o puntos fijos de temporización periódica, usada para transmitir flujos de vídeo y de audio en directo. En esta modalidad, la longitud de la Subtrama se define como distinta de cero. La segunda modalidad es una modalidad asíncrona o no periódica, en la que se usan las tramas para proporcionar datos de mapa de bits a un cliente solamente cuando se encuentre disponible nueva información. Esta modalidad se define por medio de la configuración de la longitud de la subtrama a cero en el Paquete de Cabecera de Subtrama. Cuando se usa la modalidad periódica, puede comenzar la recepción del paquete de subtrama cuando el cliente se haya sincronizado con la estructura de tramas de enlace directo. Esto corresponde a los estados "en sincronismo" definidos de acuerdo al diagrama de estados tratados más adelante con respecto a la Fig. 49 o a la Fig. 63. En la modalidad de subtrama no periódica asíncrona, la recepción comienza después de que se reciba el primer paquete de Cabecera de Subtrama.

B. Estructura General de Paquetes

El formato o la estructura de los paquetes usados para formular el protocolo de señalización implementado por las realizaciones se presenta a continuación, teniendo presente que la interfaz es extensible y que se pueden añadir como se desee estructuras de paquete adicionales. Los paquetes están etiquetados como, o divididos en, diferentes "tipos de paquete", en términos de su función en la interfaz, esto es, las órdenes o datos que transfieren. Por lo tanto, cada tipo de paquete denota una estructura de paquete predefinida para un paquete dado, que se usa en la manipulación de los paquetes y en los datos que se vayan a transferir. Como será inmediatamente evidente, los paquetes pueden tener longitudes preseleccionadas o tener longitudes variables o dinámicamente cambiantes, según sus funciones respectivas. Los paquetes también podrían llevar diferentes nombres, aunque se realice todavía la misma función, como puede ocurrir cuando se cambian los protocolos durante la aceptación en un estándar. Los bytes o valores de byte usados en los distintos paquetes están configurados como enteros sin signo multi-bits (8 o 16 bits). Un resumen de los paquetes que se em-
plean, junto con sus designaciones de "tipo", enumerados según orden de tipo, se muestra en las tablas VI-1 a la VI-4.

Cada una de las tablas representa un "tipo" general de paquete dentro de la estructura general del paquete, para facilitar la ilustración y comprensión. No hay ninguna limitación u otro impacto implícito, o expreso, para la invención por estas agrupaciones, y los paquetes se pueden organizar de muchas otras maneras según se desee. También se indica la dirección en la que se considera válida la transferencia de un paquete.

TABLA VI-1

6

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA VI-2

7

TABLA VI-3

8

TABLA VI-4

9

Algo que está claro de otras exposiciones dentro de este texto es que, mientras que el Paquete de Encapsulamiento Inverso, el Paquete de Capacidad de Cliente y el Paquete de Petición y Estado de Cliente son cada uno de ellos considerados muy importantes, o incluso requeridos, para el funcionamiento de la Modalidad Externa, se pueden considerar optativos para el funcionamiento de la Modalidad Interna. Esto crea otro tipo más de protocolo de Interfaz MDD que permite la comunicación de datos a velocidades muy altas con un conjunto reducido de paquetes de comunicaciones, y la simplificación correspondiente del control y de la temporización.

Los paquetes tienen una estructura básica común, o conjunto global de campos mínimos, que comprende un campo de Longitud de Paquete, un campo de Tipo de Paquete, campos de Bytes de Datos, y un campo de CRC, que se ilustra en la Fig. 7. Como se muestra en la Fig. 7, el campo de Longitud de Paquete contiene información, en forma de valor multibit o multibyte, que especifica el número total de bits del paquete, o su longitud entre el campo de longitud de paquete y el campo de CRC. En una realización, el campo de longitud de paquete contiene un entero sin signo de 16 bits o de 2 bytes, que especifica la longitud del paquete. El campo de Tipo de Paquete es otro campo multibit que designa el tipo de información que está contenida dentro del paquete. En una realización a título de ejemplo, éste es un valor de 16 bits o de 2 bytes, en forma de entero sin signo de 16 bits, y especifica dichos tipos de datos como capacidades de visualización, traspaso, flujos de vídeo o de audio, estado, etc.

Un tercer campo es el campo de Bytes de Datos, que contiene los bits o los datos que se están transfiriendo o enviando entre el servidor y los dispositivos clientes como parte de ese paquete. El formato de los datos se define de manera específica para cada tipo de paquete de acuerdo al tipo específico de datos que se estén transfiriendo, y se pueden separar en una serie de campos adicionales, cada uno con sus propios requisitos de formato. Esto es, cada tipo de paquete tendrá un formato definido para esta parte o campo. El último campo es el campo de CRC que contiene los resultados de una comprobación de redundancia cíclica de 16 bits calculada sobre los campos de Bytes de Datos, Tipo de Paquete, y Longitud de Paquete, que se usan para confirmar la integridad de la información en el paquete. En otras palabras, calculado sobre todo el paquete excepto el campo CRC mismo. El cliente, por lo general, conserva un total de los errores CRC detectados, e informa de este total al servidor en el Paquete de Petición y Estado del Cliente (véase más adelante a continuación).

Por lo general, estos anchos y esta organización de campo están diseñados para mantener campos de 2 bytes alineados en un límite de byte par, y campos de 4 bytes alineados en límites de 4 bytes. Esto permite que las estructuras de paquete sean fácilmente construidas en un espacio de memoria principal de, o asociado a, un servidor y un cliente, sin violar las reglas de alineamiento de tipos de datos encontradas para la mayoría de los procesadores o circuitos de control, o para los típicamente usados.

Durante la transferencia de los paquetes, los campos se transmiten comenzando por el bit menos significativo (LSB) primero, y acabando por el bit más significativo (MSB), transmitido en último término. Los parámetros que tengan más de un byte de longitud se transmiten usando el byte menos significativo primero, lo que da como resultado que se use el mismo patrón de transmisión de bits para un parámetro mayor de 8 bits de longitud, que el que se usa para un parámetro más corto, en el que el bit menos significativo se transmite primero. Los campos de datos de cada paquete se transmiten, por lo general, en el orden en que están definidos en las secciones posteriores a continuación, siendo el primer campo enumerado transmitido primero, y siendo el último campo descrito transmitido en último término. Los datos en el trayecto de la señal MDDI_Data0 están alineados con el bit `0' de los bytes transmitidos por la interfaz en cualquiera de las modalidades, Tipo 1, Tipo 2, Tipo 3 o Tipo-4.

Cuando se manipulan datos para las visualizaciones, los datos para las matrices de píxeles se transmiten por filas primero y después por columnas, como se hace de manera tradicional en la técnica electrónica. En otras palabras, todos los píxeles que aparecen en la misma fila en un mapa de bits se transmiten en orden, con el píxel de más a la izquierda transmitido primero y el píxel de más a la derecha transmitido en último término. Después de que se haya transmitido el píxel de más a la derecha de una fila, entonces el siguiente píxel de la secuencia es el píxel de más a la izquierda de la siguiente fila. Las filas de píxeles, por lo general, son transmitidas en orden desde la parte superior hasta la parte inferior para la mayoría de las pantallas, aunque se pueden asimilar otras configuraciones según sea necesario. Además, al manipular mapas de bits, el enfoque convencional, que se sigue aquí, es definir un punto de referencia por medio del etiquetado de la esquina superior izquierda de un mapa de bits como localización o desplazamiento "0,0". Las coordenadas X e Y usadas para definir o para determinar una posición en el mapa de bits aumentan en valor a medida que uno se aproxima a la parte derecha y a la inferior del mapa de bits, respectivamente. La primera fila y la primera columna (esquina superior izquierda de una imagen) comienzan con un valor de índice de cero. La magnitud de la coordenada X aumenta hacia el lado derecho de la imagen, y la magnitud de la coordenada Y aumenta hacia la parte inferior de la imagen, según lo visto por el usuario de la visualización.

Una ventana de visualización es la parte visible de un mapa de bits, la parte de los píxeles del mapa de bits que puede ser vista por el usuario en el medio de visualización físico. A menudo se da el caso de que la ventana de visualización y el mapa de bits son del mismo tamaño. La esquina superior izquierda de una ventana de visualización siempre visualiza la localización del píxel de mapa de bits 0,0. El ancho de la ventana de visualización corresponde al eje X del mapa de bits, y el ancho de la ventana de visualización deberá ser menor 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 visualización deberá ser menor o igual a la altura del correspondiente mapa de bits. La propia ventana de visualización no es direccionable en el protocolo porque solamente está definida como la parte visible de un mapa de bits.

La relación entre mapas de bits y ventanas de visualización es bien conocida en las técnicas de ordenadores, electrónica, comunicación por Internet y otras técnicas relacionadas con la electrónica. Por lo tanto, no se proporcionan en este documento exposiciones o ilustraciones adicionales de estos principios.

C. Definiciones de Paquete 1. Paquete de Cabecera de Subtrama

El paquete de Cabecera de Subtrama es el primer paquete de cada subtrama, y tiene una estructura básica que se ilustra en la Fig. 8. El Paquete de Cabecera de Subtrama se usa para la sincronización servidor-cliente, y cada servidor debería poder generar este paquete, mientras que cada cliente debería poder recibir e interpretar este paquete. Como puede verse en una realización en la Fig. 8, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Palabra Única, Reservado 1, Longitud de Subtrama, Versión de Protocolo, Total de Subtramas y Total de Tramas de Medios, generalmente en ese orden. En una realización, este tipo de paquete se identifica generalmente como un paquete de Tipo 15359 (0x3bff en hexadecimal) y utiliza una longitud fija preseleccionada de 20 bytes, sin incluir el campo de longitud del paquete.

El campo de Tipo de Paquete y el campo Palabra Única utilizan, cada uno, un valor de 2 bytes (entero sin signo de 16 bits). La combinación de 4 bytes de estos dos campos forma en conjunto una palabra única de 32 bits con buena autocorrelación. En una realización, la palabra única efectiva es 0x005a3bff, donde los 16 bits de orden inferior se transmiten primero como el Tipo de Paquete, y los 16 bits más significativos se transmiten después.

El campo Reservado 1 contiene 2 bytes que son espacio reservado para uso futuro, y generalmente se configura en este punto con todos los bits en cero. Un objeto de este campo es causar que los campos subsiguientes de 2 bytes se alineen a una palabra de dirección de 16 bits y causar que los campos de 4 bytes se alineen a una palabra de dirección de 32 bits. El byte menos significativo se reserva para indicar que el servidor es capaz de direccionar múltiples dispositivos clientes. Un valor de cero se reserva para indicar que el servidor es capaz de funcionar sólo con un único dispositivo cliente.

El campo de Longitud de Subtrama contiene 4 bytes de información o valores, que especifican el número de bytes por subtrama. En una realización, la longitud de este campo puede hacerse igual a cero para indicar que sólo una subtrama será transmitida por el servidor antes de que el enlace se cierre en estado ocioso. El valor en este campo puede cambiarse dinámicamente "sobre la marcha" al efectuar la transición desde una subtrama a la siguiente. Esta capacidad es útil a fin de hacer ajustes menores de temporización en los pulsos de sincronización para asimilar flujos de datos isócronos. Si el CRC del paquete de Cabecera de Subtrama no es válido, entonces el controlador de enlace debería utilizar la Longitud de Subtrama del paquete anterior de Cabecera de Subtrama considerado como bueno para estimar la longitud de la subtrama actual.

El campo Versión de Protocolo contiene 2 bytes que especifican la versión de protocolo utilizada por el servidor. El campo Versión de Protocolo se fija en `0' para especificar la versión primera, o actual, del protocolo según se está utilizando. Este valor cambiará a lo largo del tiempo según se creen nuevas versiones.

El campo de Total de Subtrama contiene 2 bytes que especifican un número de secuencia que indica el número de subtramas que han sido transmitidas desde el comienzo de la trama de medios. La primera subtrama de la trama de medios tiene un Total de Subtrama igual a cero. La última subtrama de la trama de medios tiene un valor de n-1, donde n es el número de subtramas por trama de medios. Observe que, si la Longitud de Subtrama se fija igual a cero (indicando una subtrama no periódica), entonces el total de Subtramas también debe fijarse igual a cero.

El campo Total de Trama de Medios contiene 4 bytes (entero sin signo de 32 bits) que especifican un número de secuencia que indica el número de tramas de medios que han sido transmitidas desde el comienzo del elemento o dato actual de medios que está siendo transferido. La primera trama de medios de un elemento de medios tiene un Total de Tramas de Medios igual a cero. El Total de Tramas de Medios se incrementa justo antes de la primera subtrama de cada trama de medios, y vuelve al valor cero después de que se emplea el máximo Total de Tramas de Medios (por ejemplo, el número de trama de medios 2^{3}-1 = 4.294.967.295). El valor del Total de Tramas de Medios puede ser reiniciado, por lo general, en cualquier momento por el Servidor, para adaptarse a las necesidades de una aplicación final.

2. Paquete de Relleno

Un paquete de relleno es un paquete que se transfiere a, o desde, un dispositivo cliente cuando no se dispone de ninguna otra información para enviar, bien por el enlace directo o bien por el inverso. Se recomienda que los paquetes de relleno tengan una longitud mínima a fin de permitir la máxima flexibilidad al enviar otros paquetes cuando se requiera. Al final de una subtrama o de un paquete de encapsulación del enlace inverso (véase más adelante), un controlador de enlace establece el tamaño del paquete de relleno para llenar el espacio restante, a fin de mantener la integridad del paquete. El Paquete de Relleno es útil para mantener la temporización en el enlace cuando el servidor o el cliente no tienen ninguna información que enviar o intercambiar. Todo servidor y cliente necesita poder enviar y recibir este paquete para hacer un uso efectivo de la interfaz.

El formato y el contenido de un Paquete de Relleno se muestran en la Fig. 9. Según se muestra en la Fig. 9, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Bytes de Relleno y CRC. En una realización, este tipo de paquete se identifica, generalmente, como un Tipo 0, lo que se indica 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 valores de bit, todos ceros, para permitir que el paquete de relleno tenga la longitud deseada. El paquete de relleno más pequeño no contiene ningún byte en este campo. Es decir, el paquete consiste sólo en la longitud del paquete, el tipo de paquete y el CRC, y en una realización utiliza una longitud fija preseleccionada de 6 bytes, o un valor de Longitud de Paquete igual a 4. El valor del CRC está determinado para todos los bytes en el paquete, incluyendo la Longitud de Paquete, que puede excluirse en algunos otros tipos de paquetes.

3. Paquete de Flujo de Vídeo

Los Paquetes de Flujo de Vídeo llevan datos de vídeo para actualizar, típicamente, regiones rectangulares de un dispositivo de visualización. El tamaño de esta región puede ser tan pequeña como un único píxel, o tan grande como el visor entero. Puede haber un número casi ilimitado de flujos exhibidos simultáneamente, limitados por los recursos del sistema, porque todo el contexto requerido para visualizar un flujo está contenido dentro del Paquete de Flujo de Vídeo. El formato de una realización del Paquete de Flujo de Vídeo (Descriptor de Formato de Datos de Vídeo) se muestra en la Fig. 10. Según se ve en la Fig. 10, en una realización, este tipo de paquete está estructurado para tener campos de Longitud de Paquete (2 bytes), Tipo de Paquete, Identificador de bCliente, Descriptor de Datos de Vídeo, Atributos de Visualización de Píxeles, Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, Inicio de X e Y, Total de Píxeles, CRC de Parámetros, Datos de Píxeles y CRC de Datos de Píxeles. Este tipo de paquete se identifica generalmente como un Tipo 16, lo que se indica en el campo de Tipo de 2 bytes. En una realización, un cliente indica una capacidad de recibir un Paquete de Flujo de Vídeo utilizando los campos de RGB, Monocromático y Capacidad de Y Cr Cb del Paquete de Capacidad del Cliente.

En una realización, el campo Identificador de bCliente contiene 2 bytes de información que están reservados para un Identificador de Cliente. Dado que este es un protocolo de comunicaciones recientemente desarrollado, los Identificadores de clientes reales no se conocen aún o no son lo bastante comunicables. Por lo tanto, los bits en este campo se fijan generalmente iguales a cero hasta que se conocen dichos valores de Identificadores, en cuyo momento los valores de Identificadores pueden insertarse o utilizarse, como sería evidente a aquellos expertos en la técnica. El mismo proceso será generalmente cierto para los campos de Identificadores de cliente expuestos a continuación.

El concepto de trama común expuesto anteriormente es una manera efectiva de minimizar el tamaño del almacén temporal de audio y de disminuir la latencia. Sin embargo, para datos de vídeo puede ser necesario extender los píxeles de una trama de vídeo entre múltiples Paquetes de Flujo de Vídeo dentro de una trama de medios. También es muy probable que los píxeles en un único Paquete de Flujo de Vídeo no se correspondan exactamente con una ventana rectangular perfecta en el visor. Para la velocidad ejemplar de tramas de vídeo de 30 tramas por segundo, hay 300 subtramas por segundo, lo que da como resultado 10 subtramas por trama de medios. Si hay 480 filas de píxeles en cada trama, cada Paquete de Flujo de Vídeo en cada subtrama contendrá 48 filas de píxeles. En otras situaciones, el Paquete de Flujo de Vídeo podría no contener un número entero de filas de píxeles. Esto es cierto para otros tamaños de tramas de vídeo, donde el número de subtramas por trama de medios no es exactamente divisible por el número de filas (también conocidas como líneas de vídeo) por trama de vídeo. Cada Paquete de Flujo de Vídeo, por lo general, debe contener un número entero de píxeles, incluso aunque podría no contener un número entero de filas de píxeles. Esto es importante si los píxeles tienen más de un byte cada uno, o si están en un formato empaquetado, según se muestra en la Fig. 12.

El formato y el contenido empleados para realizar la operación de un campo a título de ejemplo de Descriptor de Datos de Vídeo, según se ha mencionado anteriormente, se muestran en las Figs. 11A-11E. En las Figs. 11A-11E, el campo Descriptor de Formato de Datos de Vídeo contiene 2 bytes en forma de un entero sin signo de 16 bits, que especifica el formato de cada píxel en los Datos de Píxeles en el presente flujo en el presente paquete. Es posible que distintos paquetes de Flujo de Vídeo puedan utilizar distintos formatos de datos de píxeles, es decir, utilizar un valor distinto en el Descriptor de Formato de Datos de Vídeo y, de manera similar, un flujo (región del visor) puede cambiar su formato de datos sobre la marcha. El formato de datos de píxeles debería cumplir al menos uno de los formatos válidos para el cliente, según se define en el Paquete de Capacidad de Cliente. El Descriptor de Formato de Datos de Vídeo define el formato de píxeles sólo para el presente paquete, lo que no implica que continuará utilizándose un formato constante para toda la vida útil de un flujo de vídeo específico.

Las Figs. 11A a 11d ilustran cómo se codifica el Descriptor de Formato de Datos de Vídeo. Según se utiliza en estas figuras, y en esta realización, cuando los bits [15:13] son iguales a `000', según se muestra en la Fig. 11A, entonces los datos de vídeo consisten en una formación de píxeles monocromáticos, donde el número de bits por píxel está definido por los bits 3 a 0 de la palabra del Descriptor de Formato de Datos de Vídeo. Los bits 11 a 4, por lo general, se reservan para futuros usos o aplicaciones, y se fijan en cero en esta situación. Cuando los bits [15:13], en cambio, son iguales a `001', según se muestra en la Fig. 11B, entonces los datos de vídeo consisten en una formación de píxeles de color, cada uno de los cuales especifica un color dentro del mapa de colores (). En esta situación, los bits 5 a 0 de la palabra del Descriptor de Formato de Datos de Vídeo definen el número de bits por píxel, y los bits 11 a 6, por lo general, se reservan para futuros usos o aplicaciones, y se fijan iguales a cero. Cuando los bits [15:13], en cambio, son iguales a `010', como se muestra en la Fig. 11C, entonces los datos de vídeo consisten en una formación de píxeles de color, donde el número de bits por píxel del rojo está definido por los bits 11 a 8, el número de bits por píxel del verde está definido por los bits 7 a 4, y el número de bits por píxel del azul está definido por los bits 3 a 0. En esta situación, el número total de bits en cada píxel es la suma de los números de bits utilizados para el rojo, el verde y el azul.

Sin embargo, cuando los bits [15:13], en cambio, son iguales a `011', como se muestra en la Fig. 11D, entonces los datos de vídeo consisten en una formación de datos de vídeo en formato 4:2:2 YCbCr, con información de luminosidad y cromaticidad, donde el número de bits por píxel de la luminosidad (Y) está definido por los bits 11 a 8, el número de bits del componente Cb está definido por los bits 7 a 4, y el número de bits del componente Cr está definido por los bits 3 a 0. El número total de bits en cada píxel es la suma de los números de bits utilizados para el rojo, el verde y el azul. Los componentes Cb y Cr se envían a la mitad de la velocidad que Y. Además, las muestras de vídeo en la porción de Datos de Píxeles de este paquete se organizan de la siguiente manera: Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3, ..., donde Cbn y Crn están asociados a Yn e Yn+1, y Cbn+2 y Crn+2 están asociados a Yn+2 e Yn+3, y así sucesivamente.

Yn, Yn+1, Yn+2 e Yn+3 son valores de luminosidad de cuatro píxeles consecutivos en una única fila de izquierda a derecha. Si hay un número impar de píxeles en una fila (Borde Derecho X-Borde Izquierdo X + 1) en la ventana mencionada por el Paquete de Flujo de Vídeo, entonces el valor de Y correspondiente al último píxel en cada fila será seguido por el valor Cb del primer píxel de la siguiente fila, y no se envía un valor de Cr para el último píxel de la fila. Se recomienda que las ventanas que utilicen el formato Y Cb Cr tengan un ancho que sea un número par de píxeles. Los Datos de Píxeles en un paquete deberían contener un número par de píxeles. Puede contener un número impar o par de píxeles en el caso en que el último píxel de los Datos de Píxeles corresponda al último píxel de una fila en la ventana especificada en la cabecera del Paquete de Flujo de Vídeo, es decir, cuando la ubicación X del último píxel en los Datos de Píxeles sea igual al Borde Derecho X.

Cuando los bits [15:13], en cambio, sean iguales a `100', entonces los datos de vídeo consisten en una formación de píxeles de Bayer, donde el número de bits por píxel está definido por los bits 3 a 0 de la palabra del Descriptor de Formato de Datos de Vídeo. El Patrón del Grupo de Píxeles está definido por los bits 5 y 4, según se muestra en la Fig. 11E. El orden de los datos de píxeles puede ser horizontal o vertical, y los píxeles en las filas o columnas pueden enviarse en orden ascendiente o descendiente, y está definido por los bits 8 a 6. Los bits 11 a 9 deberían fijarse iguales a cero. El grupo de cuatro píxeles en el grupo de píxeles en el formato de Bayer se asemeja a lo que a menudo se denomina un único píxel en algunas tecnologías de visualización. Sin embargo, un píxel en el formato Bayer es sólo uno de los cuatro píxeles coloreados del patrón de mosaico del grupo de píxeles.

Para todos los cinco formatos mostrados en las figuras, el bit 12, que se indica como "P", especifica si las muestras de Datos de Píxeles están empaquetadas o no, o son datos de píxeles alineados por byte. Un valor de `0' en este campo indica que cada píxel en el campo de Datos de Píxeles está alineado por byte, con un límite de byte de interfaz de MDD. Un valor de `1' indica que cada píxel y cada color dentro de cada píxel en los Datos de Píxeles está empaquetado con el píxel, o color dentro de un píxel, anterior, sin dejar ningún bit sin usar. La diferencia entre el formato de datos Alineado por Byte y el Píxel Empaquetado se muestra en más detalle en la Fig. 12, donde puede verse claramente que los datos alineados por byte pueden dejar porciones sin utilizar de la subtrama de datos, al contrario que el formato de píxel empaquetado, que no lo hace.

El primer píxel en el primer paquete de flujo de vídeo de una trama de medios para una ventana visualizadora específica irá a la esquina superior izquierda de la ventana de flujo definida por un Borde Izquierdo X y un Borde Superior Y, y el siguiente píxel recibido se coloca en la siguiente ubicación de píxel en la misma fila, y así sucesivamente. En este primer paquete de una trama de medios, el valor inicial de X usualmente será igual al Borde Izquierdo X, y el valor inicial de Y será usualmente igual al Borde Superior Y. En los paquetes subsiguientes correspondientes a la misma ventana de pantalla, los valores iniciales de X e Y se fijarán usualmente en la ubicación de píxel en la ventana de la pantalla que normalmente seguiría después del último píxel enviado en el Paquete de Flujo de Vídeo que se transmitió en la subtrama anterior.

4. Paquete de Flujo de Audio

Los paquetes de flujo de audio llevan datos de audio para reproducir mediante el sistema de audio del cliente, o para un dispositivo autónomo de presentación de audio. Pueden adjudicarse distintos flujos de datos de audio para canales de audio separados en un sistema de sonido, por ejemplo: izquierda-frente, derecha-frente, centro, izquierda-fondo y derecha-fondo, según el tipo de sistema de audio que se esté utilizando. Se proporciona un complemento completo de canales de audio para auriculares que contienen un procesamiento mejorado de señales espacial-acústicas. Un cliente indica una capacidad de recibir un Paquete de Flujo de Audio utilizando los campos Capacidad de Canal de Audio y Velocidad de Muestra de Audio del Paquete de Capacidad del Cliente. El formato de los Paquetes de Flujo de Audio se ilustra en la Fig. 13.

Según se muestra en la Fig. 13, este tipo de paquete está estructurado en una realización para contener campos de Longitud de Paquete, Tipo de Paquete, Identificador de bCliente, Identificador de Canal de Audio, Reservado 1, Total de Muestra de Audio, Bits por Muestra y Empaquetado, Velocidad de Muestra de Audio, CRC de Parámetros, Datos de Audio Digital y CRC de Datos de Audio. En una realización, este tipo de paquete se identifica generalmente como un paquete de Tipo 32.

El campo Identificador de bCliente contiene 2 bytes de información que se reservan para un Identificador de Cliente, según lo empleado anteriormente. El campo Reservado 1 contiene 2 bytes que se reservan para uso futuro, y generalmente se configura en este punto con todos los bits iguales 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 que los Bits 4 a 0 definan el número de bits por muestra de audio PCM. El bit 5 especifica entonces si las muestras de Datos de Audio Digital están empaquetadas o no. La diferencia entre muestras de audio empaquetadas y alineadas a byte, utilizando aquí muestras de 10 bits, se ilustra en la Fig. 14. Un valor de `0' indica que cada muestra de audio PCM en el campo de Datos de Audio Digital está alineado por byte con un límite de byte de interfaz MDDI, y un valor de `1' indica que cada muestra sucesiva de audio PCM está empaquetada con la muestra anterior de audio. Este bit es generalmente efectivo sólo cuando el valor definido en los bits 4 a 0 (el número de bits por muestra de audio PCM) no es un múltiplo de ocho. Los bits 7 a 6 están reservados para uso futuro y generalmente se fijan con un valor de cero.

5. Paquetes de Flujo Reservados

En una realización, los tipos de paquetes 1 a 15, 18 a 31 y 33 a 55 están reservados para paquetes de flujo a definir para su empleo en versiones o variaciones futuras de los protocolos de paquetes, según se desee para diversas aplicaciones consideradas. Nuevamente, esto es parte de hacer que la interfaz MDD sea más flexible y útil de cara a diseños de sistemas y tecnologías siempre cambiantes, en comparación con otras técnicas.

\newpage

6. Paquetes de Flujo Definidos por el Usuario

Ocho tipos de flujo de datos, conocidos como Tipos 56 a 63, están reservados para su empleo en aplicaciones de propiedad industrial que puedan ser definidas por fabricantes de equipos, para su utilización con un enlace MDDI. Estos se conocen como Paquetes de Flujo Definidos por el Usuario. Tales paquetes pueden ser utilizados con cualquier fin, pero el servidor y el cliente deberían emplear tales paquetes sólo en situaciones donde el resultado de tal uso sea muy bien comprendido o conocido. La definición específica de los parámetros y datos de flujo para estos tipos de paquetes se deja a los fabricantes de equipos específicos que implementen tales tipos de paquetes o que busquen su utilización. Algunos usos a título de ejemplo de los Paquetes de Flujo Definidos por el Usuario son trasladar parámetros de pruebas y resultados de pruebas, datos de calibración de fábrica y datos de uso especial de propiedad industrial. El formato de los paquetes de flujo definidos por el usuario, según lo utilizado en una realización, se ilustra en la Fig. 15. Según se muestra en la Fig. 15, este tipo de paquete está estructurado para tener campos de Longitud de Paquete (2 bytes), Tipo de Paquete, número de Identificador de bCliente, Parámetros de Flujo, CRC de Parámetros, 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, utilizado para presentar colores a un cliente. Algunas aplicaciones pueden requerir un mapa de colores que sea más grande que la cantidad de datos que pueden transmitirse en un único paquete. En estos casos, pueden transferirse múltiples paquetes de Mapa de Colores, cada uno con un subconjunto distinto del mapa de colores, utilizando los campos de desplazamiento y longitud descritos más adelante. El formato de un Paquete de Mapa de Colores en una realización se ilustra en la Fig. 16. Según se muestra en la Fig. 16, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de hcliente, Total de Elementos del Mapa de Colores, Desplazamiento del Mapa de Colores, CRC de Parámetros, Datos del Mapa de Colores y CRC de los Datos. En una realización, este tipo de paquete se identifica generalmente como un paquete de Tipo 64 (Paquete de Formato de Datos de Vídeo y Mapa de Colores) según se especifica en el Campo de Tipo de Paquete (2 bytes). Un cliente indica una capacidad de recibir Paquetes de Mapa de Colores utilizando los campos 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 realización a título de ejemplo, los datos se transfieren en la dirección inversa utilizando un Paquete de Encapsulación de Enlace Inverso. Se envía un paquete del enlace directo y la operación del enlace MDDI (dirección de transferencia) se cambia o se invierte en el medio de este paquete, de forma que los paquetes puedan enviarse en la dirección inversa. El formato del paquete de Encapsulación de Enlace Inverso en una realización se ilustra en la Fig. 17. Según se muestra en la Fig. 17, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, Indicadores de Enlace Inverso, Divisor de Velocidad Inversa, Longitud de Giro 1, Longitud de Giro 2, CRC de Parámetros, Todos Ceros 1, Giro 1, Paquetes de Datos Inversos, Giro 2 y Todos Ceros 2. En una realización, este tipo de paquete se identifica generalmente como un paquete de Tipo 65. Para la Modalidad Externa, cada servidor debe ser capaz de generar este paquete y recibir datos, y cada cliente debe poder recibir y enviar datos al servidor. La implementación de este paquete es optativa para la Modalidad Interna.

El controlador de enlace MDDI actúa en forma especial al enviar un Paquete de Encapsulación de Enlace Inverso. La interfaz MDD tiene una señal de sondeo que, generalmente, está siempre alimentada por el servidor, como controlador del enlace. El servidor actúa como si estuviera transmitiendo un cero para cada bit de las porciones de Giro y de Paquetes de Datos Inversos del paquete de Encapsulación de Enlace Inverso. El servidor alterna una señal MDDI_Strobe en cada límite de bit durante los dos momentos de giro y durante el tiempo adjudicado para los paquetes de datos inversos. (Este es el mismo comportamiento que si estuviera transmitiendo datos con todos ceros).

El servidor desactiva los controladores de línea de señal de datos MDDI durante el periodo especificado por Giro 1, y el cliente reactiva sus controladores de línea durante el campo Reactivar Controlador a continuación del periodo especificado por el campo Giro 2. El cliente lee el parámetro de Longitud de Giro y alimenta las señales de datos hacia el servidor inmediatamente después del último bit en el campo Giro 1. Es decir, el cliente sincroniza nuevos datos en el enlace para ciertos bordes crecientes de la sonda MDDI, según lo especificado en la descripción del contenido del paquete, más adelante, y en otra parte. El cliente utiliza los parámetros Longitud de Paquete y Longitud de Giro para conocer la longitud del tiempo que tiene disponible para enviar paquetes al servidor. El cliente puede enviar paquetes de relleno o alimentar las líneas de datos a un estado cero cuando no tenga datos que enviar al servidor. Si las líneas de datos se alimentan a cero, el servidor interpreta esto como un paquete de longitud cero (longitud no válida) y el servidor no acepta ningún paquete más desde el cliente por lo que dure el Paquete de Encapsulación de Enlace Inverso actual.

El Servidor alimenta las señales MDDI_Data al nivel de cero lógico durante el campo Todos Ceros 1, y un cliente alimenta las líneas de datos MDDI a un nivel de cero lógico durante al menos un periodo de reloj del enlace inverso, antes del inicio del campo Giro 2, es decir, durante el periodo del campo Todos Ceros 2. Esto mantiene las líneas de datos en un estado determinístico durante el periodo de tiempo de los campos Giro 1 y Giro 2. Si el cliente no tiene más paquetes que enviar, puede incluso desactivar las líneas de datos después de alimentarlas al nivel de cero lógico, porque los resistores de sesgo de hibernación (expuestos en otra parte) mantienen las líneas de datos en un nivel de cero lógico durante el resto del campo Paquetes de Datos Inversos, o durante un lapso de alrededor de 16 bytes de enlace directo, o más.

En una realización, el campo Solicitud de Enlace Inverso del Paquete de Solicitud y Estado de Cliente puede utilizarse para informar al servidor del número de bytes que el cliente necesita en el Paquete de Encapsulación de Enlace Inverso para enviar datos de vuelta al servidor. El servidor intenta conceder la petición adjudicando al menos ese número de bytes en el Paquete de Encapsulación de Enlace Inverso. El servidor puede enviar más de un Paquete de Encapsulación de Enlace Inverso en una subtrama. El cliente puede enviar un Paquete de Solicitud y Estado de Cliente casi en cualquier momento, y el servidor interpretará el parámetro Solicitud de Enlace Inverso como el número total de bytes solicitados en una subtrama.

9. Paquetes de Capacidad del Cliente

Un servidor necesita conocer la capacidad del cliente (visor) con el que está comunicándose a fin de configurar el enlace de servidor-a-cliente de manera generalmente óptima o deseada. Se recomienda que un visor envíe un Paquete de Capacidad del Cliente al servidor después de que se ha adquirido la sincronización del enlace directo. La transmisión de tal paquete se considera requerida cuando es solicitada por el servidor utilizando los Indicadores de Enlace Inverso en el Paquete de Encapsulación de Enlace Inverso. El Paquete de Capacidad del Cliente se utiliza para informar al servidor de las capacidades de un cliente. Para la Modalidad Externa, cada servidor debe poder recibir este paquete, y cada cliente debe poder enviar este paquete para utilizar por completo esta interfaz y protocolo. La implementación del paquete es optativa para la Modalidad Interna, dado que las capacidades del cliente, tal como un visor, en esta situación deberían estar ya bien definidas, y ser conocidas por el servidor en el momento de fabricación o montaje en un único componente o unidad de algún tipo.

El formato del paquete de Capacidad del Cliente en una realización se ilustra en la Fig. 18. Según se muestra en la Fig. 18, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, Versión de Protocolo, Versión Mínima de Protocolo, Capacidad de Velocidad de Datos, Capacidad de Tipo de Interfaz, Número de Visores Alternativos, Reservado 1, Ancho de Mapa de Bits, Altura de Mapa de Bits, Ancho de Ventana de Visualización, Altura de Ventana de Visualización. Tamaño del Mapa de Colores, Ancho de RGB del Mapa de Colores, Capacidad de RGB, Capacidad Monocromática, Reservado 2, Capacidad de Y Cr Cb, Capacidad de Bayer, Planos de Imagen de Alfa-Cursor, Capacidad de Características de Cliente, Velocidad Máxima de Tramas de Vídeo, Velocidad Mínima de Tramas de Vídeo, Velocidad Mínima de Subtrama, Profundidad del Almacén Temporal de Audio,

Capacidad de Canal de Audio, Capacidad de Velocidad de Muestra de Audio, Resolución de Muestra de Audio, Resolución de Muestra de Micrófono, Capacidad de Velocidad de Muestra de Micrófono, Formato de Datos de Teclado, Formato de Datos de Dispositivo Puntero, Tipo de Protección de Contenido, Nombre de Fabricante, Código de Producto, Reservado 4, Número de Serie, Semana del Fabricante, Año del Fabricante y CRC. En una realización a título de ejemplo, este tipo de paquete se identifica generalmente como un paquete de Tipo 66.

10. Paquetes de Datos de Teclado

Un paquete de datos de teclado se utiliza para enviar datos de teclado desde el dispositivo cliente al servidor. Puede emplearse un teclado inalámbrico (o con cable) conjuntamente con diversos dispositivos de visualización o audio, incluyendo, pero sin limitarse a, un dispositivo de presentación de visualización de vídeo/audio montado en la cabeza. El Paquete de Datos de Teclado retransmite datos de teclado recibidos desde uno entre varios dispositivos, conocidos como de teclado, al servidor. Este paquete también puede emplearse en el enlace directo para enviar datos al teclado. Un cliente indica una capacidad de enviar y recibir Paquetes de Datos de Teclado utilizando el Campo de Datos de Teclado en el Paquete de Capacidad de Cliente.

El formato de un Paquete de Datos de Teclado se muestra en la Fig. 19, y contiene un número variable de bytes de información desde o para un teclado. Según se muestra en la Fig. 19, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de bCliente, Formato de Datos de Teclado, Datos de Teclado y CRC. Aquí, este tipo de paquete se identifica generalmente como un paquete de Tipo 67.

El Identificador de bCliente es un campo reservado, igual que antes, y el CRC se efectúa sobre todos los bytes del paquete. El campo Formato de Datos de Teclado contiene un valor de 2 bytes que describe el formato de datos de teclado. Los bits 6 a 0 deberían ser idénticos al campo Formato de Datos de Teclado en el Paquete de Capacidad de Cliente. Este valor no ha de ser igual a 127. Los bits 15 a 7 están reservados para uso futuro y, por lo tanto, se fijan actualmente en cero.

11. Paquetes de Datos de Dispositivo Puntero

Un paquete de datos de dispositivo puntero se utiliza para enviar información de posición desde un ratón inalámbrico u otro dispositivo puntero, desde el cliente al servidor. Los datos también pueden enviarse al dispositivo puntero por el enlace directo, utilizando este paquete. Un formato ejemplar de un Paquete de Datos de Dispositivo Puntero se muestra en la Fig. 20, y contiene un número variable de bytes de información desde, o para, un dispositivo puntero. Según se muestra en la Fig. 20, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de bCliente, Formato de Dispositivo Puntero. Datos de Dispositivo Puntero y CRC. En una realización a título de ejemplo, este tipo de paquete se identifica generalmente como un paquete de Tipo 68 en el campo de tipo de 1 byte.

12. Paquetes de Cierre de Enlace

Un Paquete de Cierre de Enlace se envía desde el servidor al cliente para indicar que los datos de MDDI y la sonda se cerrarán e irán a un estado de "hibernación" de bajo consumo de energía. Este paquete es útil para apagar el enlace y conservar energía después de que los mapas de bits estáticos se hayan enviado desde un dispositivo de comunicación móvil al visor, o cuando no hay ninguna información adicional a transferir desde un servidor a un cliente por el momento. El funcionamiento normal se reanuda cuando el servidor envía paquetes nuevamente. El primer paquete enviado después de la hibernación es un paquete de cabecera de subtrama. El formato de un Paquete de Estado de Cliente se muestra en la Fig. 21. Según se muestra en la Fig. 21, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, CRC y Todos Ceros. En una realización, este tipo de paquete se identifica generalmente como un paquete de Tipo 69 en el campo de tipo de 1 byte, y utiliza una longitud fija preseleccionada de 3 bytes.

En el estado de hibernación de baja energía, el controlador de la línea MDDI_Data queda desactivado en un estado de alta impedancia, y las señales MDDI_Data se llevan a un estado de cero lógico empleando una red de sesgo de alta impedancia cuyo control puede ser retomado por el cliente. La señal de sonda utilizada por la interfaz se lleva a un nivel de cero lógico en el estado de hibernación, para minimizar el consumo de energía. Bien el servidor, o bien el cliente, pueden causar que el enlace MDDI se "despierte" del estado de hibernación, según se describe en otra parte, lo que es un avance clave, y una ventaja, para la presente invención.

13. Paquetes de Solicitud y Estado de Cliente

El servidor necesita una pequeña cantidad de información del cliente para poder configurar el enlace de servidor-a-cliente de una manera generalmente óptima. Se recomienda que el cliente envíe al servidor un Paquete de Solicitud y Estado de Cliente con cada subtrama. El cliente debería enviar este paquete como el primer paquete en el Paquete de Encapsulación de Enlace Inverso, para garantizar que se entregue de manera fiable al servidor. La remisión de este paquete también se logra cuando es solicitada por un servidor utilizando los Indicadores de Enlace Inverso en el Paquete de Encapsulación del Enlace Inverso. El Paquete de Solicitud y Estado de Cliente se utiliza para informar errores y estado al servidor. Cada servidor debería ser capaz de recibir este paquete, y cada cliente debería poder enviar este paquete a fin de emplear debida y óptimamente el protocolo de interfaz MDD.

El formato de un Paquete de Solicitud y Estado de Cliente se muestra en la Fig. 22. Según se muestra en la Fig. 22, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, Solicitud de Enlace Inverso, Cambio de Capacidad, Errores Gráficos. Total de Errores de CRC y CRC. Este tipo de paquete se identifica generalmente con un paquete de Tipo 70 en el campo de tipo de 1 byte y, típicamente, utiliza una longitud fija preseleccionada de 12 bytes.

El campo de Solicitud de Enlace Inverso puede utilizarse para informar al servidor del número de bytes que el cliente necesita en el Paquete de Encapsulación de Enlace Inverso para enviar datos de vuelta al servidor. El servidor debería intentar conceder la solicitud adjudicando al menos ese número de bytes en el Paquete de Encapsulación de Enlace Inverso. El servidor puede enviar más de un Paquete de Encapsulación de Enlace Inverso en una subtrama, a fin de acomodar los datos. El cliente puede enviar un Paquete de Solicitud y Estado de Cliente en cualquier momento, y el servidor interpretará el parámetro Solicitud de Enlace Inverso como el número total de bytes solicitados en una subtrama. Más adelante se muestran detalles adicionales y ejemplos específicos de cómo los datos del enlace inverso se envían de vuelta al servidor.

14. Paquetes de Transferencia de Bloques de Bits

El Paquete de Transferencia de Bloques de Bits proporciona un medio para desplazar regiones del visor en cualquier dirección. Los visores que tienen esta capacidad informarán de la capacidad en el bit 0 del campo Indicadores de Capacidad de Características de Visor del Paquete de Capacidad de Cliente. El formato de un Paquete de Transferencia de Bloques de Bits se muestra en la Fig. 23. Según se muestra en la Fig. 23, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, Valor de X Superior Izquierdo, Valor de Y Superior Izquierdo, Ancho de Ventana, Altura de Ventana, Movimiento X de Ventana, Movimiento Y de Ventana y CRC. Este tipo de paquete se identifica generalmente como un paquete de Tipo 71, y utiliza una longitud fija preseleccionada de 15 bytes.

Los campos se usan para especificar los valores de X e Y de la coordenada de la esquina izquierda superior de la ventana a mover, el ancho y la altura de la ventana a mover y el número de píxeles por los que la ventana se va a mover en dirección horizontal y vertical, respectivamente. Los valores positivos para los dos últimos campos causan que la ventana se mueva hacia la derecha y abajo y los valores negativos causan movimiento hacia la izquierda y arriba, respectivamente.

15. Paquetes de Relleno de Área de Mapa de Bits

El Paquete de Relleno del Área de Mapa de Bits proporciona un medio para inicializar fácilmente una región del visor con un único color. Los visores que tienen esta capacidad informarán de la capacidad en el bit 1 del campo Indicadores de Capacidad de Características de Cliente del Paquete de Capacidad de Cliente. El formato de un Paquete de Relleno del Área de Mapa de Bits se muestra en la Fig. 24. Según se muestra en la Fig. 24, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, Valor X Superior Izquierdo, Valor Y Superior Izquierdo, Ancho de Ventana, Altura de Ventana, Descriptor de Formato de Datos, Valor de Relleno del Área de Píxeles y CRC. Este tipo de paquete se identifica generalmente como un paquete de Tipo 72 en el campo de tipo de 1 byte, y utiliza una longitud fija preseleccionada de 17 bytes.

16. Paquetes de Relleno del Patrón de Mapa de Bits

El Paquete de Relleno del Patrón de Mapa de Bits proporciona un medio para inicializar fácilmente una región del visor con un patrón preseleccionado. Los visores que tienen esta capacidad informarán de la capacidad en el bit 2 del campo Capacidad de Característica de Cliente del Paquete de Capacidad de Cliente. La esquina superior izquierda del patrón de relleno se alinea con la esquina superior izquierda de la ventana a rellenar. Si la ventana a rellenar es más ancha o más alta que el patrón de relleno, entonces el patrón puede repetirse horizontal o verticalmente un cierto número de veces para llenar la ventana. El extremo derecho o inferior del patrón de relleno se trunca según sea necesario. Si la ventana es más pequeña que el patrón de relleno, entonces el lado derecho o inferior del patrón de relleno puede truncarse para ajustarse a la ventana.

El formato de un Paquete de Relleno de Patrón de Mapa de Bits se muestra en la Fig. 25. Según se muestra en la Fig. 25, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, Valor X Superior Izquierdo, Valor Y Superior Izquierdo, Ancho de Ventana, Altura de Ventana, Ancho de Patrón, Altura de Patrón, Descriptor de Formato de Datos, CRC de Parámetros, Datos de Píxeles del Patrón y CRC de Datos de Píxeles. Este tipo de paquete se identifica generalmente como un paquete de 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 proporciona un medio para que un cliente con capacidad de cálculo de alto nivel, tal como una agenda electrónica, se comunique con un transceptor inalámbrico tal como un teléfono celular o un dispositivo inalámbrico de puerto de datos. En esta situación, el enlace MDDI está actuando como una conveniente interfaz de alta velocidad entre el dispositivo de comunicación y el dispositivo de cálculo con el visor móvil, donde este paquete transporta datos en una Capa de Enlace de Datos de un sistema operativo para el dispositivo. Por ejemplo, este paquete podría utilizarse si un explorador de la Red, un cliente de correo electrónico, o una agenda electrónica entera se integraran en un visor móvil. Los visores que tienen esta capacidad informarán de la capacidad en el bit 3 del campo Capacidad de Característica de Cliente del Paquete de Capacidad de Cliente.

El formato de un Paquete de Canal de Datos de Enlace de Comunicación se muestra en la Fig. 26. Según se muestra en la Fig. 26, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, CRC de Parámetros, Datos de Enlace de Comunicación y CRC de Datos de Comunicación. Este tipo de paquete se identifica generalmente como un paquete de Tipo 74 en el campo de tipo.

18. Paquetes de Solicitud de Traspaso de Tipo de Interfaz

El Paquete de Solicitud de Traspaso de Tipo de Interfaz permite al servidor solicitar que el cliente o visor pase desde una modalidad existente o actual a las modalidades de Tipo 1 (en serie), Tipo 2 (en paralelo en 2 bits), Tipo 3 (en paralelo en 4 bits) o Tipo 4 (en paralelo en 8 bits). Antes de que el servidor solicite una modalidad específica, debería confirmar que el cliente es capaz de operar en la modalidad deseada, examinando los bits 6 y 7 del campo Indicadores de Capacidad de Característica de Visualización del Paquete de Capacidad de Cliente. El formato de un Paquete de Solicitud de Traspaso de Tipo de Interfaz se muestra en la Fig. 27. Según se muestra en la Fig. 27, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Tipo de Interfaz, Reservado 1 y CRC. Este tipo de paquete se identifica generalmente como un paquete de Tipo 75, y utiliza una longitud fija preseleccionada de 4 bytes.

19. Paquetes de Acuse de Recibo de Tipo de Interfaz

El Paquete de Acuse de Recibo de Tipo de Interfaz es enviado por el cliente para confirmar la recepción del Paquete de Traspaso de Tipo de Interfaz. La modalidad solicitada, Tipo 1 (en serie), Tipo 2 (en paralelo en 2 bits), Tipo 3 (en paralelo en 4 bits) o Tipo 4 (en paralelo en 8 bits) se devuelve al servidor como un parámetro en este paquete. El formato de un Paquete de Acuse de Recibo de Tipo de Interfaz se muestra en la Fig. 28. Según se muestra en la Fig. 28, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, Tipo de Interfaz, Reservado 1 y CRC. Este tipo de paquete se identifica generalmente como un paquete de Tipo 76, y utiliza una longitud fija preseleccionada de 4 bytes.

20. Paquetes de Traspaso de Tipo de Ejecución

El Paquete de Traspaso de Tipo de Ejecución es un medio para que el servidor ordene al cliente pasar a la modalidad especificada en este paquete. Esta debe ser la modalidad previamente solicitada y confirmada por el Paquete de Solicitud de Traspaso de Tipo de Interfaz y el Paquete de Acuse de Recibo de Tipo de Interfaz. El servidor y el cliente deberían conmutar a la modalidad acordada después de que se envíe este paquete. El cliente puede perder y recuperar la sincronización del enlace durante el cambio de modalidad. El formato de un Paquete de Traspaso de Tipo de Ejecución se muestra en la Fig. 29. Según se muestra en la Fig. 29, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Tipo de Paquete, Reservado 1 y CRC. Este tipo de paquete se identifica generalmente como un paquete de Tipo 77 en el campo de tipo de 1 byte, y utiliza una longitud fija preseleccionada de 4 bytes.

21. Paquetes de Activación de Canal de Audio Directo

Este paquete permite que el servidor active o desactive canales de audio en el cliente. Esta capacidad es útil para que el cliente (un visor, por ejemplo) pueda apagar amplificadores de audio o elementos similares de circuitos para ahorrar energía cuando no hay ningún audio a emitir por parte del servidor. Esto es significativamente más difícil de implementar implícitamente, utilizando sencillamente la presencia o ausencia de flujos de audio como un indicador. El estado por defecto cuando el sistema cliente está encendido es que todos los canales de audio estén activados. El formato de un Paquete de Activación de Canal de Audio Directo se muestra en la Fig. 30. Según se muestra en la Fig. 30, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, Máscara de Activación de Canal de Audio y CRC. Este tipo de paquete se identifica generalmente como un paquete de Tipo 78 en el campo de tipo de 1 byte, y utiliza una longitud fija preseleccionada de 4 bytes.

22. Paquetes de Velocidad de Muestra de Audio Inverso

Este paquete permite al servidor activar o desactivar el canal de audio del enlace inverso, y fijar la velocidad de la muestra de datos de audio de este flujo. El servidor selecciona una velocidad de muestra que está definida como válida en el Paquete de Capacidad de Cliente. Si el servidor selecciona una velocidad de muestra inválida, entonces el cliente no enviará un flujo de audio al servidor, y el error adecuado puede enviarse al servidor en el Paquete de Informe de Error de Cliente. El servidor puede desactivar el flujo de audio del enlace inverso fijando la velocidad de muestra con un valor de 255. El estado por defecto supuesto cuando el sistema cliente se enciende o conecta originalmente es con el flujo de audio de enlace inverso desactivado. El formato de un Paquete de Velocidad de Muestra de Audio Inverso se muestra en la Fig. 31. Según se muestra en la Fig. 31, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, Velocidad de Muestra de Audio, Reservado 1 y CRC. Este tipo de paquete se identifica generalmente como un paquete de Tipo 79 y utiliza una longitud fija preseleccionada de 4 bytes.

23. Paquetes de Sobrecarga de Protección de Contenido Digital

Este paquete permite que el servidor y un cliente intercambien mensajes relacionados con el procedimiento de protección de contenido digital que se está utilizando. Actualmente se contemplan dos tipos de protección de contenido, la Protección de Contenido de Transmisión Digital (DTCP), o el Sistema de Protección de Contenido Digital de Gran Ancho de Banda (HDCP), con espacio reservado para futuras designaciones de esquemas de protección alternativos. El procedimiento que se está utilizando es especificado por un parámetro de Tipo de Protección de Contenido en este paquete. El formato de un Paquete de Sobrecarga de Protección de Contenido Digital se muestra en la Fig. 32. Como se muestra en la Fig. 32, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de bCliente, Tipo de Protección de Contenido, Mensajes de Sobrecarga de Protección de Contenido y CRC. Este tipo de paquete se identifica generalmente como un paquete de Tipo 80.

24. Paquetes de Activación de Color Transparente

El Paquete de Activación de Color Transparente se utiliza para especificar qué color es transparente en un visor, y para activar o desactivar el empleo de un color transparente para visualizar imágenes. Los visores que tienen esta capacidad informarán de esa capacidad en el bit 4 del campo de Capacidad de Característica de Cliente del Paquete de Capacidad de Cliente. Cuando se graba un píxel con el valor para el color transparente en el mapa de bits, el color no cambia con respecto al valor anterior. El formato de un Paquete de Activación de Color Transparente se muestra en la Fig. 33. Según se muestra en la Fig. 33, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, Activación de Color Transparente, Reservado 1, Identificador de Alfa-Cursor, Descriptor de Formato de Datos, Valor de Píxel Transparente y CRC. Este tipo de paquete se identifica generalmente como un paquete de Tipo 81 en el campo de tipo de 1 byte, y utiliza una longitud fija preseleccionada 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 se utiliza para medir el retardo de propagación desde el servidor a un cliente (visor), más el retardo desde el cliente (visor) de vuelta al servidor. Esta medición incluye implícitamente los retardos que existen en los controladores de línea y los receptores, y un subsistema de interconexión. Esta medición se utiliza para fijar el retardo de giro y los parámetros de divisores de velocidad de enlace inverso en el Paquete de Encapsulación de Enlace Inverso, descrito en general anteriormente. Este paquete es utilísimo cuando el enlace MDDI está funcionando a la máxima velocidad concebida para una aplicación específica. La señal MDDI_Stb actúa como si se están enviando datos todos ceros durante los siguientes campos: ambos Tiempos de Guardia, Todos Cero y el Periodo de Medición. Esto causa que la señal MDDI_Stb alterne sus valores a la mitad de la velocidad de datos, para que pueda utilizarse como un reloj periódico en el cliente durante el Periodo de Medición.

En una realización, un cliente indica en general una capacidad de brindar soporte al Paquete de Medición de Retardo de Ida y Vuelta mediante el empleo del bit 18 del campo de Indicadores de Capacidad de Característica de Cliente del Paquete de Capacidad de Cliente. Se recomienda que todos los clientes brinden soporte a la medición de retardo de ida y vuelta, pero es posible que el servidor conozca el retardo de ida y vuelta en el peor caso basándose en un retardo máximo por cable, y en los retardos máximos de controlador y de receptor. El servidor también puede saber el retardo de ida y vuelta anticipadamente para un enlace MDDI utilizado en la modalidad interna, ya que esto es un aspecto de elementos conocidos de diseño (longitudes de conductores, tipo de circuitos, y características, etc.) del dispositivo en el cual se está utilizando la interfaz.

El formato de un Paquete de Medición de Retardo de Ida y Vuelta se muestra en la Fig. 34. Según se muestra en la Fig. 34, en una realización este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, CRC de Parámetros, Tiempo de Guardia 1, Periodo de Medición, Todos Ceros y Tiempo de Guardia 2. Este tipo de paquete se identifica generalmente como un paquete de Tipo 82, y utiliza una longitud fija preseleccionada de 533 bits.

La temporización de los sucesos que tienen lugar durante el Paquete de Medición de Retardo de Ida y Vuelta se ilustra en la Fig. 35. En la Fig. 35, el servidor transmite el Paquete de Medición de Retardo de Ida y Vuelta, mostrado por la presencia de los campos de CRC de Parámetros y Alineación de Sonda, seguidos por los campos de Todos Ceros y Tiempo de Guardia 1. Un retardo 3502 ocurre antes de que el paquete llegue al dispositivo de visualización o circuitos de procesamiento del cliente. Según el cliente recibe el paquete, transmite la secuencia 0xff, 0xff y 30 bytes del patrón 0x0 con tanta precisión como sea práctico en el comienzo del Periodo de Medición, según lo determinado por el cliente. El momento efectivo en que el cliente comienza a transmitir esta secuencia se retarda desde el comienzo del Periodo de Medición, desde el punto de vista del servidor. La magnitud de este retardo es esencialmente el tiempo que le lleva al paquete propagarse a través de los controladores de línea y los receptores, y el subsistema de interconexión (cables, conductores). Se incurre en una magnitud similar de retardo 3504 para que el patrón se propague de regreso desde el cliente hasta el servidor.

A fin de determinar con precisión el tiempo de retardo de ida y vuelta para que las señales viajen a y desde el cliente, el servidor cuenta el número de periodos de tiempos de bits del enlace directo después del inicio del Periodo de Medición, hasta que se detecta el comienzo de la secuencia 0xff, 0xff y los 30 bytes de 0x0 al llegar. Esta información se utiliza para determinar la cantidad de tiempo para que una señal de ida y vuelta pase desde el servidor al cliente, y de regreso. Luego, alrededor de la mitad de esta cantidad se atribuye a un retardo creado para el pasaje unidireccional de una señal al cliente.

Tanto el servidor como el cliente alimentan la línea a un nivel de cero lógico durante ambos tiempos de guardia, para mantener las líneas MDDI_Data en un estado definido. Los resistores de alza y baja de hibernación (véase la Fig. 42) garantizan que las señales MDDI_Data se mantienen en un nivel bajo válido en los intervalos donde los controladores de línea están desactivados tanto en el servidor como en el cliente.

26. Paquete de Calibración de Sesgo de Enlace Directo

El Paquete de Calibración de Sesgo de Enlace Directo permite a un cliente o visor autocalibrarse en cuanto a las diferencias en el retardo de propagación de las señales MDDI_Data con respecto a la señal MDDI_Stb. Sin compensación de sesgo de retardo, la máxima velocidad de datos se limita generalmente a tener en cuenta la variación potencial del peor caso en estos retardos. Generalmente, este paquete se envía sólo cuando la velocidad de datos del enlace directo está configurada en una velocidad de alrededor de 50 Mbps, o menor. Después de enviar este paquete para calibrar el visor, la velocidad de datos puede elevarse por encima de los 50 Mbps. Si la velocidad de datos se pone demasiado alta durante el proceso de calibración de sesgo, el visor podría sincronizarse con un alias del periodo de bits, lo que podría causar que el valor de compensación del sesgo de retardo se desfasara en más de un periodo de bit, dando como resultado una sincronización errónea de datos. El tipo de interfaz de más alta velocidad de datos, o el mayor Tipo de Interfaz posible, se seleccionan antes de enviar el Paquete de Calibración de Sesgo de Enlace Directo, de forma que todos los bits de datos existentes sean calibrados.

El formato de un Paquete de Calibración de Sesgo de Enlace Directo se muestra en la Fig. 56. Como se muestra en la Fig. 56, este tipo de paquete está estructurado para tener campos de Longitud de Paquete (2 bytes), Tipo de Paquete, CRC de Parámetros, Secuencia de Datos de Calibración y CRC. Este tipo de paquete se identifica generalmente como un paquete de Tipo 83 en el campo de tipo, y tiene una longitud preseleccionada de 515.

\newpage

Panel de Control Virtual

El empleo de un Panel de Control Virtual (VCP) permite a un servidor establecer ciertos controles de usuario en un cliente. Permitiendo que estos parámetros sean ajustados por el servidor, la interfaz de usuario en el cliente puede simplificarse, porque las pantallas que permiten a un usuario ajustar parámetros, tales como el volumen del audio o el brillo del visor, pueden ser generadas por el software del servidor, en lugar de uno o más microprocesadores en el cliente. El servidor tiene la capacidad de leer la configuración de parámetros en el cliente y de determinar la gama de valores válidos para cada control. El cliente tiene la capacidad de informar al servidor de qué parámetros de control pueden ajustarse.

Los códigos de control (códigos VCP) y los valores de datos asociados generalmente especificados se utilizan para especificar controles y configuraciones en el cliente. Los Códigos VCP en la especificación de la MDDI están expandidos a 16 bits para preservar la debida alineación de los campos de datos en las definiciones de paquetes y, en el futuro, para brindar soporte a valores suplementarios que sean únicos para esta interfaz, o a futuras mejoras.

27. Paquete de Solicitud de Característica VCP

El Paquete de Solicitud de Característica VCP proporciona un medio, mecanismo o procedimiento para que el servidor solicite la configuración actual de un parámetro de control específico, o de todos los parámetros válidos de control. Generalmente, un cliente responde a un Paquete VCP con la información adecuada en un Paquete de Respuesta de Característica VCP. En una realización, el cliente indica una capacidad de brindar soporte al Paquete de Solicitud de Característica VCP utilizando el bit 20 del campo de Indicadores de Capacidad de Cliente del Paquete de Capacidad de Cliente.

El formato del Paquete de Solicitud de Característica VCP, en una realización, se muestra en la Fig. 69. Como se ve en la Fig. 69, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, código VCP de MCCS y CRC. Este tipo de paquete se identifica generalmente en una realización como un Tipo 128, lo que se indica en el campo de tipo de 2 bytes. La longitud del paquete, que especifica el número total de bytes en el paquete, sin incluir el campo de longitud del paquete, está típicamente fijada para este tipo de paquete en una longitud de 8 bytes.

El campo de Identificador de hCliente contiene un entero sin signo de 16 bits reservado para el Identificador de Cliente. Este campo está reservado para uso futuro y, típicamente, se fija en cero. El campo de Código VCP de MCCS comprende 2 bytes de información que especifican el Parámetro de Código de Control VCP de MCCS. Un valor en la gama de 0 a 255 causa que se devuelva un Paquete de Respuesta de Característica VCP con un único elemento en la Lista de Respuesta de Característica VCP correspondiente al código de MCCS especificado. Un Código VCP de MCCS de 65535 (Oxffff) solicita un Paquete de Respuesta de Característica VCP con una Lista de Respuesta de Característica de VCP que contiene un Elemento de Lista de Respuesta de Característica para cada control que tenga soporte por parte del cliente. Los valores de 256 hasta 65534 para este campo están reservados para uso futuro y actualmente no se utilizan.

28. Paquete de Respuesta de Característica VCP

El Paquete de Respuesta de Característica VCP proporciona un medio, mecanismo o procedimiento para que un cliente responda a una solicitud del servidor con la configuración actual de un parámetro de control específico, o de todos los parámetros de control válidos. Generalmente, el cliente envía el Paquete de Respuesta de Característica VCP en respuesta al Paquete de Solicitud de Característica VCP. Este paquete es útil para determinar la configuración actual de un parámetro específico, para determinar la gama válida para un control específico, para determinar si un control específico dispone de soporte por parte del cliente, o para determinar el conjunto de controles que cuentan con soporte por parte del cliente. Si se envía una Solicitud de Característica VCP que hace referencia a un control específico que no está implementado en el cliente, entonces se devuelve el Paquete de Respuesta de Característica de VCP con un único elemento de la Lista de Respuesta de Característica VCP, correspondiente al control no implementado que contiene el código de error adecuado. En una realización, el cliente indica una capacidad para brindar soporte al Paquete de Respuesta de Característica VCP utilizando el bit 20 del campo de Indicadores de Capacidad de Característica de Visor del Paquete de Capacidad de Cliente.

El formato del Paquete de Respuesta de Característica VCP, en una realización, se muestra en la Fig. 70. Como se ve en la Fig. 70, este tipo de paquete está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, Versión de MCCS, Número de Secuencia de Respuesta, Lista de Respuesta de Característica VCP y CRC. Este tipo de paquete se identifica generalmente en una realización como un Tipo 129, según lo indicado en el campo de tipo de 2 bytes.

El campo Identificador de cCliente contiene información reservada para un Identificador de Cliente. Este campo está reservado para uso futuro y generalmente se fija en cero. El campo Versión de MCCS contiene 2 bytes de información que especifica la Versión de la Especificación de MCCS de VESA implementada por el cliente.

El campo 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 de VCP devueltos por el cliente. El cliente devuelve uno o más Paquetes de Respuesta de Característica de VCP en respuesta a un Paquete de Solicitud de Característica VCP, con un valor del Código de Control de MCCS igual a 65535. El cliente puede dispersar la lista de respuesta de características entre múltiples Paquetes de Respuesta de Característica VCP. En este caso, el cliente asigna un número de secuencia a cada paquete sucesivo, y los números de secuencia de los Paquetes de Respuesta de Característica VCP, enviados en respuesta a un único Paquete de Solicitud de Característica VCP, comienzan en cero y se incrementan de a uno. El último Elemento de la Lista de Características VCP en el último Paquete de Respuesta de Característica VCP debería contener un valor del Código de Control de VCP de MCCS igual a Oxffff, para identificar que el paquete es el último y que contiene el número más alto de secuencia del grupo de paquetes devueltos. Si sólo se envía un Paquete de Respuesta de Característica VCP en respuesta a un Paquete de Solicitud de Característica VCP, entonces el Número de Secuencia de Respuesta en ese único paquete es cero, y la Lista de Respuesta de Característica VCP contiene un registro con un Código de Control de VCP de MCCS igual a 0xffff.

El campo Número de Características en la Lista contiene 2 bytes que especifican el número de Elementos de la Lista de Características VCP que están en la Lista de Respuesta de Característica VCP en este paquete, mientras que el campo Lista de Respuesta de Característica VCP es un grupo de bytes que contienen uno o más Elementos de la Lista de Respuesta de Característica VCP. El formato de un único Elemento de la Lista de Respuesta de Característica VCP en una realización se muestra en la Fig. 71.

Como se muestra en la Fig. 71, cada Elemento de la Lista de Respuesta de Característica VCP tiene exactamente 12 bytes de largo, y comprende los campos Código VCP de MCCS, Código de Resultado, Valor Máximo y Valor Actual. El campo de 2 bytes Código VCP de MCCS contiene datos o información que especifica el Parámetro del Código de Control VCP de MCCS asociado a este elemento de la lista. Sólo los valores de Códigos de Control definidos en la versión 2 de la Especificación de MCCS de VESA, y posteriores, se consideran válidos. El campo de 2 bytes Código de Resultado contiene información que especifica un código de error relacionado con la solicitud de información con respecto al Control de VCP de MCCS especificado. Un valor de `0' en este campo significa que no hay ningún error, mientras que un valor de `1' significa que el control especificado no está implementado en el cliente. Los valores adicionales para este campo, entre 2 y 65535, están actualmente reservados para el futuro uso e implementación de otras aplicaciones contempladas en la técnica, pero no deben usarse por ahora.

El campo de 4 bytes Valor Máximo contiene un entero sin signo de 32 bits que especifica el más grande valor posible que puede asignarse al Control de MCCS especificado. Si el control solicitado no está implementado en el cliente, este valor se fija en cero. Si el valor devuelto tiene menos de 32 bits (4 bytes) de longitud, entonces el valor se coloca en un entero de 32 bits, dejando los bytes más significativos (no utilizados) fijados en cero. El campo de 4 bytes Valor Actual contiene información que especifica el valor actual del control especificado, Continuo (C) o no continuo (NC), del VCP del MCCS. 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 fija en cero. Si el valor devuelto tiene menos de 32 bits (4 bytes) de longitud según la especificación del MCCS de VESA, entonces el valor se coloca en un entero de 32 bits, dejando los bytes más significativos (no utilizados) fijados en cero.

29. Paquete de Fijación de Característica de VCP

El Paquete de Fijación de Característica de VCP proporciona un medio, mecanismo o procedimiento para que un servidor fije valores de control de VCP para controles tanto continuos como no continuos en un cliente. En una realización, el cliente indica la capacidad de brindar soporte al Paquete de Fijación de Característica VCP utilizando el bit 20 del campo de Indicadores de Capacidad de Característica de Visor del Paquete de Capacidad de Cliente.

El formato del Paquete de Fijación de Característica VCP, en una realización, se muestra en la Fig. 72. Como se ve en la Fig. 72, este tipo de paquete está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, Código de VCP del MCCS, Número de Valores en la Lista, Lista de Valores de Control y CRC. Este tipo de paquete se identifica generalmente como un Tipo 130, según lo indicado en el campo de tipo de 2 bytes, y tiene 20 bytes de largo, excluyendo el campo de Longitud de Paquete.

El campo Identificador de hCliente utiliza de nuevo un valor de 2 bytes para especificar o actuar como un Identificador de Cliente. Este campo está reservado para uso futuro y actualmente está fijado en cero. El campo Código de VCP del MCCS utiliza 2 bytes de información o valores para especificar el Parámetro de Código de Control de VCP del MCCS a ajustar. El campo de 2 bytes 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 del MCCS se refiera a una tabla en el cliente. En el caso de controles no referidos a tablas, la Lista de Valores de Control contendrá un valor que especifica el nuevo valor a grabar en el parámetro de control especificado por el campo Código de VCP del MCCS. Para controles referidos a tablas, el formato de los datos en la Lista de Valores de Control está especificado por la descripción del parámetro del Código de VCP del MCCS especificado. Si la lista contiene valores que son más grandes que un byte, entonces se transmite primero el byte menos significativo, en coherencia con el principio definido en otro sitio. Finalmente, el campo CRC de 2 bytes contiene un CRC de 16 bits de todos los bytes en el paquete, incluyendo la Longitud de Paquete.

\newpage

30. Paquete de Solicitud de Parámetro Válido

El Paquete de Solicitud de Parámetro Válido se emplea como un medio o mecanismo para solicitar que un cliente devuelva un Paquete de Respuesta de Parámetro Válido que contenga una lista de parámetros con soporte por parte del control especificado, no continuo (NC) o de tabla (T). Este paquete sólo debería especificar controles no continuos, o controles que se refieran a una tabla en el cliente, y no especificar un valor de Código de VCP del MCCS igual a 65535 (0xffff) para especificar todos los controles. Si se especifica un Código de VCP del MCCS sin soporte, o inválido, entonces se devuelve un valor de error adecuado en el Paquete de Respuesta de Parámetro Válido. En una realización, el cliente indica una capacidad para brindar soporte al Paquete de Solicitud de Parámetro Válido utilizando el bit 20 del campo Indicadores de Capacidad de Característica de Visor del Paquete de Capacidad de Visor.

El formato del Paquete de Solicitud de Parámetro Válido en una realización se muestra en la Fig. 73. Como se ve en la Fig. 73, este tipo de paquete está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, Código de VCP del MCCS y CRC. Este tipo de paquete se identifica generalmente en una realización como un Tipo 131, según lo indicado en el campo de tipo de 2 bytes.

La longitud del paquete, según se indica en el campo de Longitud de Paquete de 2 bytes, se fija generalmente para tener un número total de bytes en el paquete, sin incluir el campo de longitud del paquete de 8. El Identificador de hCliente nuevamente especifica el Identificador de Cliente, pero está actualmente reservado para uso futuro, como será evidente para alguien experto en la técnica, y se fija en cero. El campo Código de VCP del MCCS de 2 bytes contiene un valor que especifica el Parámetro de Código de Control de VCP del MCCS no continuo a consultar. El valor en este campo debería corresponder a un control no continuo que está implementado en el cliente. Los valores entre 256 y 65535 (0xffff) están típicamente reservados o considerados como 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 se envía en respuesta a un Paquete de Solicitud de Parámetro Válido. Se utiliza como un medio, procedimiento o mecanismo para identificar las configuraciones válidas para un control no continuo de VCP del MCCS, o un control que devuelve el contenido de una tabla. Si el control se refiere a una tabla en el cliente, entonces la Lista de Respuesta de Parámetros de VCP simplemente contiene la lista específica de valores secuenciales de tablas que se solicitaron. Si el contenido de la tabla no puede caber en un único Paquete de Respuesta de Parámetro Válido, entonces múltiples paquetes, con Números de Secuencia de Respuesta secuenciales pueden ser enviados por el cliente. En una realización, un cliente indica una capacidad para brindar soporte a un Paquete de Respuesta de Parámetro Válido utilizando el bit 20 del campo Indicadores de Capacidad de Característica de Visor del Paquete de Capacidad de Visor.

Un servidor puede solicitar el contenido de una tabla de la siguiente manera: el servidor envía un Paquete de Fijación de Característica de VCP que contiene los parámetros necesarios o deseados, tales como el parámetro de lectura/escritura, el desplazamiento de LUT y la selección de RGB; luego, un Paquete de Solicitud de Parámetro Válido que especifica el control deseado es enviado por el servidor; luego el cliente devuelve uno o más Paquetes de Respuesta de Parámetro Válido que contienen los datos de la tabla. Esta secuencia de operaciones lleva a cabo una función similar a las de las funciones de lectura de tablas descritas en el modelo de operación del MCCS.

Si un parámetro específico del cliente no dispone de soporte por parte del cliente, entonces, en una realización, el correspondiente campo de este paquete contendrá un valor de 255. Para parámetros que se utilizan en el cliente, el campo correspondiente debería contener un valor del parámetro en el cliente.

El formato del Paquete de Respuesta de Parámetro Válido, para una realización, se muestra en la Fig. 74. Como se ve en la Fig. 74, este tipo de paquete está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, Código de VCP del MCCS, Código de Respuesta, Número de Secuencia de Respuesta, Número de Valores en la Lista, Lista de Respuesta de Parámetros de VCP y CRC. Este tipo de paquete se identifica generalmente, para una realización, como un Tipo 132, según se indica en el campo de tipo de 2 bytes.

El campo Identificador de cCliente está reservado para el futuro Identificador de Cliente, como se conoce de las exposiciones anteriores, mientras que el campo Código de VCP del MCCS de 3 bytes contiene un valor que especifica un Parámetro de Código de Control de VCP del MCCS, no continuo, que está descrito por este paquete. Si un Código de Control de VCP del MCCS inválido es especificado por un Paquete de Solicitud de Parámetro Válido, entonces el mismo valor de parámetro inválido será especificado en este campo con el valor adecuado en el campo Código de Respuesta. Si el Código de Control del MCCS es inválido, entonces la Lista de Respuesta de Parámetros de VCP tendrá longitud cero.

El campo 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 con respecto al Control de VCP del MCCS especificado. Si el valor en este campo es igual a 0, entonces se considera que no está presente ningún error para este tipo de datos, y se envía el último Paquete de Respuesta de Parámetro Válido en la secuencia, el que tenga el más alto Número de Secuencia de Respuesta. Si el valor en este campo es igual a 1, entonces se considera que no está presente ningún error, pero se enviarán otros Paquetes de Respuesta de Parámetro Válido que tengan números de secuencia más altos. Si el valor en este campo es igual a 2, entonces no se considera que el control especificado esté 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 un conjunto válido de todos los valores desde cero hasta su valor máximo). Los valores para este campo, entre 4 y 65535, están reservados para uso futuro y generalmente no deben utilizarse.

El campo Número de Secuencia de Respuesta de 2 bytes especifica el número de secuencia de los Paquetes de Respuesta de Parámetro Válido devueltos por el cliente. El cliente devuelve uno o más Paquetes de Respuesta de Parámetro Válido en respuesta a un Paquete de Solicitud de Parámetro Válido. El cliente puede dispersar la Lista de Respuesta de Parámetro VCP entre múltiples Paquetes de Respuesta de Parámetro Válido. En este último caso, el cliente asignará un número de secuencia a cada paquete sucesivo, y fijará el Código de Respuesta en 1 en todos los paquetes, excepto el último en la secuencia. El último Paquete de Respuesta de Parámetro Válido en la secuencia tendrá el más alto Número de Secuencia de Respuesta y el Código de Respuesta contendrá un valor de 0.

El campo 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 Número de Valores en la Lista es cero. El campo Lista de Respuesta de Parámetro VCP contiene una lista de entre 0 y 32760 valores de 2 bytes que indican el conjunto de valores válidos para el control no continuo especificado por el campo Código de Control del MCCS. Las definiciones de los códigos de control no continuos se especifican en la Especificación del MCCS de VESA. Finalmente, en esta realización, el campo CRC contiene un CRC de 16 bits de todos los bytes en el paquete, incluyendo la Longitud de Paquete.

Imágenes Alfa-Cursor

La interfaz MDD, y el protocolo y mecanismos inventivos asociados, para comunicar datos por un enlace de comunicaciones, brinda soporte para que múltiples planos de imágenes se solapen y puedan tener grados variables de transparencia. Puede implementarse un cursor de hardware utilizando una imagen solapada que tiene un desplazamiento X-Y variable. Se proporciona más adelante una visión general de la funcionalidad del Alfa-Cursor y del soporte protocolar asociado. La capacidad de brindar soporte a paquetes de imágenes Alfa-Cursor se define en el Paquete de Capacidad de Imagen Alfa-Cursor, que se envía en respuesta a un Paquete de Solicitud de Estado Específico.

32. Paquete de Capacidad de Imagen Alfa-Cursor

El Paquete de Capacidad de Imagen Alfa-Cursor se utiliza para definir las características de la imagen Alfa-Cursor y los mapas de transparencia asociados en un cliente. En una realización, un cliente indica una capacidad para brindar soporte a un Paquete de Capacidad de Imagen Alfa-Cursor utilizando un valor de parámetro de 133 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido. La longitud del paquete especificada en el campo de longitud del paquete se establece en un valor fijo de 20 para una realización, sin incluir el campo de longitud del paquete.

El formato del Paquete de Capacidad de Imagen Alfa-Cursor para una realización se muestra en la Fig. 75. Como se ve en la Fig. 75, este tipo de paquete está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, Identificador de Alfa-Cursor, Ancho del Mapa de Bits de Alfa-Cursor, Altura del Mapa de Bits de Alfa-Cursor, Capacidad RGB, Capacidad Monocromática, Reservado 1, Capacidad Y Cr Cb, Resolución del Mapa de Transparencia, Bits de Capacidad y CRC. El campo Identificador de cCliente está típicamente reservado para uso futuro de Identificador de Cliente y está actualmente fijado en cero.

El campo Identificador de Alfa-Cursor (2 bytes) contiene un valor que identifica un plano alfa-cursor específico. Si el cliente brinda soporte a n planos de imagen alfa-cursor, entonces el Identificador de Alfa-Cursor tiene una gama válida entre 0 y n-1. En una realización, el valor n se especifica en el campo Planos de Imagen Alfa-Cursor del Paquete de Capacidad de Visor. El cliente devuelve un único Paquete de Capacidad de Imagen Alfa-Cursor para cada plano de imagen alfa-cursor.

El valor del campo Ancho del Mapa de Bits de Alfa-Cursor, de 2 bytes, especifica el ancho de la imagen de mapa de bits de alfa-cursor, expresado como un número de píxeles, mientras que el valor del campo Altura del 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 píxeles.

El campo Capacidad RGB utiliza 2 bytes para especificar el número de bits de resolución que pueden visualizarse en formato RGB. Si el cliente no puede utilizar el formato RGB, entonces este valor es cero. La palabra de Capacidad RGB se compone de tres valores distintos, que, en una realización, se implementan de forma tal que: los Bits 3 a 0 definen el número máximo de bits en azul (la intensidad azul) en cada píxel; los Bits 7 a 4 definen el número máximo de bits de verde (la intensidad verde) en cada píxel; los Bits 11 1 a 8 definen el número máximo de bits de rojo (la intensidad roja) en cada píxel; y los Bits 15 a 12 se reservan para uso futuro en la presentación de información de capacidad RGB, por lo que generalmente se fijan en cero por ahora.

El campo Capacidad Monocromática, de 1 byte, se utiliza para especificar el número de bits de resolución que pueden visualizarse en formato monocromático. Si un cliente no puede utilizar el formato monocromático, entonces este valor se fija en cero. Los bits 7 a 4 están reservados para uso futuro y, por lo tanto, se fijan generalmente en cero. Los bits 3 a 0 definen el número máximo de bits de escala de grises que pueden existir en cada píxel. Estos cuatro bits hacen posible especificar que cada píxel consiste en 1 a 15 bits. Si el valor es cero, entonces el formato monocromático no dispone de soporte por parte del cliente.

El campo Reservado 1, de 1 byte, contiene un valor generalmente reservado para uso futuro y, como tal, todos los bits en este campo se fijan en cero. Esto causará que los campos subsiguientes de 2 bytes se alineen a una palabra de dirección de 16 bits y causará que los campos de 4 bytes se alineen a una palabra de dirección 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 visualizarse en formato Y Cb Cr. Si el cliente no puede utilizar el formato Y Cr Cb, entonces este valor es cero. Generalmente, en una realización, la palabra de Capacidad Y Cb Cr se compone de tres valores distintos con: los Bits 3 a 0, que definen un número máximo de bits que especifican la muestra Cr; los Bits 7 a 4, que definen el número máximo de bits que especifican la muestra Cb; los Bits 11 a 8, que definen el número máximo de bits que especifican la muestra Y; y los Bits 15 a 12, reservados para uso futuro de la presentación de información o valores de Capacidad Y Cb Cr, pero que actualmente están fijados en cero.

El campo de Resolución del Mapa de Transparencia, de 1 byte, contiene valores o información que especifica el número de bits (profundidad) en cada ubicación de píxel del mapa de transparencia de la imagen alfa-cursor. Este valor puede oscilar entre 1 y 8. Si el valor es cero, entonces el mapa de transparencia no tiene soporte para este almacén temporal de imágenes alfa-cursor (el almacén temporal especificado por el campo Identificador de Alfa-Cursor).

El campo Bits de Capacidad, de 1 byte, proporciona valores o información que contienen un conjunto de indicadores que especifican capacidades asociadas con el almacén temporal de imágenes alfa-cursor. En una realización, los indicadores están definidos de forma tal que: el Bit 0 actúa para seleccionar que los datos de Píxeles en el Paquete de Flujo de Vídeo Alfa-Cursor estén en formato empaquetado. El Bit 1 actúa para mostrar que los datos del mapa de transparencia en el Paquete de Transparencia Alfa-Cursor están en un formato empaquetado. Un ejemplo de datos de mapa de transparencia alineados por bytes, y empaquetados, se muestra en la Fig. 76. El Bit 2 actúa para mostrar que el plano de imagen alfa-cursor brinda soporte a la capacidad de desplazamiento de imagen, utilizando el Paquete de Desplazamiento de Imagen Alfa-Cursor. El Bit 3 actúa para mostrar que el plano de imagen alfa-cursor puede brindar soporte a un formato de datos de mapa de colores. Se utiliza la misma tabla de mapa de colores para los planos de imagen alfa-cursor que se utiliza para el principal almacén temporal de imágenes y los flujos de vídeo escalado. El mapa de colores se configura utilizando el Paquete de Mapa de Colores descrito en otro sitio.

Los Bits 7 a 4 están reservados para uso futuro y, por lo tanto, generalmente se fijan en un valor o nivel lógico cero.

33. Paquete de Mapa de Transparencia Alfa-Cursor

El Paquete de Mapa de Transparencia Alfa-Cursor define el contenido del mapa de transparencia de imágenes para el plano de imagen alfa-cursor especificado. Algunas aplicaciones pueden requerir un mapa de transparencia que sea mayor que la cantidad de datos que pueden transmitirse en un único paquete. En estos casos, pueden enviarse múltiples Paquetes de Mapa de Transparencia Alfa-Cursor, cada uno con un subconjunto distinto del mapa de transparencia, utilizando los campos Inicio X e Y de Mapa de Transparencia, y descritos más adelante. Estos campos funcionan de manera similar a la de los campos Inicio X e Inicio Y del Paquete de Flujo de Vídeo. Un cliente indica una capacidad de brindar soporte al Paquete de Mapa de Transparencia Alfa-Cursor, en una realización, utilizando el campo Resolución del Mapa de Transparencia del Paquete de Capacidad de Imagen Alfa-Cursor para cada Plano Alfa-Cursor específico especificado por el campo Identificador de Alfa-Cursor del Paquete de Capacidad de Imagen Alfa-Cursor. Los campos de longitud de paquete e Identificador de Cliente funcionan como antes para otros paquetes expuestos anteriormente. En una realización, se utiliza una valor de 134 en el campo Tipo de Paquete para identificar un paquete como un Paquete de Mapa de Transparencia Alfa-Cursor.

El formato del Paquete de Mapa de Transparencia Alfa-Cursor, para una realización, se muestra en la Fig. 76. Como se ve en la Fig. 76, este tipo de paquete está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, 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ámetros, Medios de Mapa de Transparencia y CRC de Datos de Mapa de Transparencia.

El campo Identificador de Alfa-Cursor, de 2 bytes, tiene un valor que identifica un plano alfa-cursor específico. Si el cliente brinda soporte a n planos de imagen alfa-cursor, entonces el Identificador de Alfa-Cursor tiene una gama válida entre 0 y n-1.

Cada uno de los campos Inicio X e Y de Mapa de Transparencia, de 2 bytes, especifica las coordinadas X e Y absolutas, donde el punto (Inicio X de Mapa de Transparencia, Inicio Y de Mapa de Transparencia) es el primer píxel en el campo Datos de Mapa de Transparencia, a continuación.

El campo 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 empaquetados o no. En una realización de este campo, los Bits 3 a 0 definen el número de bits de resolución que existen en todos los elementos de la tabla del mapa de transparencia. Los valores válidos especifican que el ancho sea de entre 1 y 8 bits. Los valores 0, y entre 9 y 15, se consideran inválidos. Este valor debería coincidir con el valor devuelto por un cliente en el campo Resolución de Mapa de Transparencia en el Paquete Capacidad de Imagen Alfa-Cursor. Los Bits 6 a 4 están reservados para uso futuro y están, por lo tanto, se deben fijar generalmente en cero lógico en este momento. El bit 7 de este byte especifica si los Datos del Mapa de Transparencia están o no en formato empaquetado o alineado por byte. Si el bit 7 es igual a `1', entonces los Datos del Mapa de Transparencia están en forma empaquetada, y si es igual a `0', los datos están alineados por byte. Un ejemplo de datos de Mapa de Transparencia empaquetados y alineados por byte se muestra en otro sitio. El valor de este bit debe coincidir con el valor del bit 1 del campo Bits de Capacidad del Paquete de Capacidad de Imagen Alfa-Cursor.

El campo Reservado 1, de 1 byte, está reservado para uso futuro; por lo tanto, todos los bits en este campo están generalmente fijados iguales a un nivel de cero lógico. Un fin de este campo es causar que todos los campos subsiguientes de 2 bytes se alineen a una palabra de dirección de 16 bits y causar que los campos de 4 bytes se alineen a una palabra de dirección de 32 bits.

El campo CRC de Parámetros contiene un CRC de 16 bits de todos los bytes desde la Longitud de Paquete hasta el campo Reservado 1. Si este CRC no confirma la comprobación, entonces debe descartarse el paquete entero.

Para el campo Datos del Mapa de Transparencia, cada ubicación del mapa de transferencia tiene entre 1 y 8 bits de ancho. Si un único mapa de transferencia no cabe en un Paquete de Mapa de Transferencia Alfa y Cursor, entonces puede especificarse el mapa de transferencia entero enviando múltiples paquetes con distintos valores de Datos de Mapa de Transferencia, y de Inicio X e Y de Mapa de Transferencia, en cada paquete.

El campo CRC de Datos del Mapa de Transparencia, de 2 bytes, contiene un CRC de 16 bits, sólo de los Datos del Mapa de Transparencia. Si este CRC no confirma la comprobación, entonces los Datos del Mapa de Transferencia pueden ser utilizados aún, pero el total de errores de CRC se incrementará.

34. Paquete de Desplazamiento de Imagen Alfa-Cursor

El Paquete de Desplazamiento de Imagen Alfa-Cursor especifica el desplazamiento de X e Y del cursor desde la esquina superior izquierda de la imagen del visor principal. El formato del Paquete de Desplazamiento de Imagen Alfa-Cursor se ilustra en la Fig. 77. Como se muestra en la Fig. 77, en una realización, el Paquete de Desplazamiento de Imagen Alfa-Cursor está estructurado con los campos Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, Desplazamiento X de Alfa-Cursor, Desplazamiento Y de Alfa-Cursor y CRC. En una realización, un cliente indica la capacidad de brindar soporte al Paquete de Desplazamiento de Imagen Alfa-Cursor utilizando el bit 2 del campo Bits de Capacidad del Paquete de Capacidad de Imagen de Alfa-Cursor para cada Plano Alfa-Cursor específico especificado por el campo Identificador de Alfa-Cursor del Paquete de Capacidad de Imagen Alfa-Cursor. En una realización, la longitud del paquete se fija en 10, como se muestra en el campo Longitud de Paquete de 2 bytes. En una realización, un Tipo de Paquete de 135 identifica el paquete como un Paquete de Desplazamiento de Imagen Alfa-Cursor.

Los campos Desplazamiento X e Y de Alfa-Cursor, de 2 bytes, contienen valores que especifican, respectivamente, los desplazamientos horizontal y vertical de la columna más a la izquierda y de la primera fila, de los píxeles de la imagen alfa-cursor, desde el lado izquierdo y el extremo superior de la imagen principal. El campo Identificador de hCliente, de 2 bytes, contiene un entero sin signo de 16 bits reservado para el Identificador del Cliente. Este campo está reservado para uso futuro y se fijará en cero.

35. Paquete de Flujo de Vídeo Alfa-Cursor

El Paquete de Flujo de Vídeo Alfa-Cursor lleva datos de vídeo para actualizar una región rectangular de un plano de imagen alfa-cursor. El tamaño de esta región puede ser tan pequeño como el de un único píxel, o tan grande como el del visor entero. El formato del Paquete de Flujo de Vídeo Alfa-Cursor se ilustra en la Fig. 78. Como se muestra en la Fig. 78, en una realización, el Paquete de Flujo de Vídeo Alfa-Cursor está estructurado con los campos Longitud de Paquete, Tipo de Paquete, Identificador de bCliente, Atributos de Formato de Datos de Vídeo, Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, Inicio X, Inicio Y, Total de Píxeles, Crc de Parámetros, Datos de Píxeles y CRC de Datos de Píxeles. En una realización, un cliente indica una capacidad para brindar soporte al Paquete de Flujo de Vídeo Alfa-Cursor y sus parámetros asociados utilizando el Paquete de Capacidad de Imagen Alfa-Cursor para cada Plano Alfa-Cursor específico especificado por el campo Identificador de Alfa-Cursor del Paquete de Capacidad de Imagen 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 Vídeo Alfa-Cursor. El campo Identificador de hCliente (2 bytes) está reservado para uso futuro como un Identificador de Cliente, y generalmente se fija en cero mientras tanto, como será bien comprendido en la técnica.

El campo Descriptor de Formato de Datos de Vídeo, de 2 bytes, contiene información o un valor que especifica el formato de cada píxel en los Datos de Píxeles en el presente flujo en el presente paquete. El formato de datos de píxeles debe concordar con al menos uno de los formatos válidos para el plano de imagen alfa-cursor, según lo definido en el Paquete de Capacidad de Imagen Alfa-Cursor. El campo Descriptor de Formato de Datos de Vídeo contiene un valor que define el formato de píxeles para el paquete actual solamente, y no implica que se continuará utilizando un formato constante durante la vida útil de un flujo de vídeo específico. La Fig. 11 ilustra cómo se codifica el Descriptor de Formato de Datos de Vídeo. El formato es el siguiente:

En una realización, cuando los bits [15:13] son `000', entonces los datos de vídeo consisten en una matriz de píxeles monocromáticos, donde el número de bits por píxel está definido por los bits 3 a 0 de la palabra del Descriptor de Formato de Datos de Vídeo. Los Bits 11 a 4 se fijan entonces en cero. Cuando los bits [15:13] son `001', entonces los datos de vídeo consisten en una matriz de píxeles en color, cada uno de los cuales especifica un color dentro de un mapa de colores (paleta). Los Bits 5 a 0 de la palabra del Descriptor de Datos de Vídeo definen el número de bits por píxel, y los Bits 11 a 6 se fijan en cero. Cuando los bits [15:13] son `010', entonces los datos de vídeo consisten en una matriz de píxeles de color en formato RGB no procesado, donde el número de bits por píxel del rojo está definido por los bits 11 a 8, el número de bits por píxel del verde está definido por los bits 7 a 4, y el número de bits por píxel del azul está definido por los bits 3 a 0. El número total de bits en cada píxel es la suma del número de bits utilizados para el rojo, el verde y el azul.

Cuando los bits [15:13] son `011', entonces los datos de vídeo consisten en una matriz de datos de vídeo en formato 4:2:2 Y Cb Cr, con información de luminosidad y cromaticidad. El número de bits por píxel de luminosidad (Y) está definido por los bits 11 a 8, el número de bits del componente Cb está definido por los bits 7 a 4, y el número de bits del componente Cr está definido por los bits 3 a 0. Los componentes Cb y Cr se envían a la mitad de velocidad que Y. Las muestras de vídeo en la porción de Datos de Píxeles de este paquete se organizarán de la siguiente manera: Cbn, Yn, Cm, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3, ..., donde Cbn y Cm están asociados a Yn e Yn+1, y Cbn+2 y Crn+2 están asociados a Yn+2 e Yn+3, y así sucesivamente. Yn, Yn+1, Yn+2 e Yn+3 son valores de luminosidad de cuatro píxeles consecutivos en una única fila, de izquierda a derecha. El ordenamiento de los componentes cromáticos es el mismo que el formato UYVY FOURCC de Microsoft. Si hay un número impar de píxeles en una fila (X Borde Derecho-X Borde Izquierdo + 1) en la ventana mencionada por el Paquete de Flujo de Vídeo, entonces el valor de Cb correspondiente al último píxel en cada fila estará seguido por el valor de Y del primer píxel de la siguiente fila.

Se recomienda que las ventanas que utilizan el formato Y Cb Cr tengan un ancho que sea un número par de píxeles. Los Datos de Píxeles en un paquete contendrán un número par de píxeles. Pueden contener un número impar o par de píxeles en el caso en que el último píxel de los Datos de Píxeles corresponde al último píxel de una fila en la ventana especificada en la cabecera del Paquete de Flujo de Vídeo, es decir, cuando la ubicación X del último píxel en los Datos de Píxeles es igual al Borde Derecho X.

Para todos los cinco formatos, el bit 12 (indicado como "P" en las figuras) especifica si las muestras de Datos de Píxeles están empaquetadas o no. Cuando el valor del bit 12 es `0', entonces cada píxel y cada color dentro de cada píxel en el campo Datos de Píxeles está alineado por byte con el límite de byte de la interfaz MDDI. Cuando el valor del bit 12 es `1', entonces cada píxel y cada color dentro de cada píxel en los Datos de Píxeles está empaquetado con el píxel o color anterior dentro de un píxel, sin dejar ningún bit no utilizado.

En una realización, el campo Atributos de Datos de Píxeles (2 bytes) tiene una serie de valores de bit que se interpretan de la siguiente manera. Los Bits 1 y 0 seleccionan cómo se encaminan los datos de píxeles del visor. Para los valores de bit `11', los datos se exhiben a, o para, ambos ojos, para los valores de bit `10', los datos se encaminan sólo al ojo izquierdo, y para los valores de bit `01', los datos se encaminan sólo al ojo derecho.

El Bit 2 indica si los Datos de Píxeles se presentan o no en un formato de entrelazado, donde un valor de `0' significa que los datos de píxeles están en el formato progresivo estándar, y que el número de fila (coordenada Y del píxel) se incrementa en 1 cuando se avanza desde una fila a la siguiente. Cuando este bit tiene un valor de `1', los datos de píxeles están en el formato entrelazado, y el número de fila se incremente en 2 al avanzar desde una fila a la siguiente. El Bit 3 indica que los Datos de Píxeles están en un formato alternativo de píxel. Esto es similar a la modalidad entrelazada estándar activada por el bit 2, pero el entrelazado es vertical en lugar de horizontal. Cuando el Bit 3 es `0', los Datos de Píxeles están en el formato progresivo estándar, y el número de columna (coordenada X del píxel) se incrementa en 1 según se recibe cada píxel sucesivo. Cuando el Bit 3 es `1', los Datos de Píxeles están en un formato alternativo de píxel, y el número de columna se incrementa en 2 según se recibe cada píxel.

El Bit 4 indica si los Datos de Píxeles están o no relacionados con un visor o una cámara, como cuando los datos están siendo transferidos a o desde un visor interno para un teléfono inalámbrico o dispositivo similar, o incluso un ordenador portátil, u otros dispositivos tales como los expuestos anteriormente, o bien los datos están siendo transferidos a o desde una cámara integrada en o directamente acoplada al dispositivo. Cuando el Bit 4 es `0', los Datos de Píxeles están siendo transferidos a o desde un almacén temporal de tramas de pantalla. Cuando el Bit 4 es `1', los Datos de Píxeles están siendo transferidos a o desde una cámara o dispositivo de vídeo de algún tipo, siendo tales dispositivos bien conocidos en la técnica.

El Bit 5 está reservado para uso o aplicaciones futuras de la interfaz MDD y, por lo tanto, generalmente se fija en el valor `0'.

Los Bits 7 y 6 son Bits de Actualización de Visor que especifican un almacén temporal de tramas donde han de grabarse los datos de píxeles. Los efectos más específicos se exponen en otra parte. Para valores de bit de `01', los Datos de Píxeles se graban en el almacén temporal de imágenes fuera de línea. Para valores de bit de `00', los Datos de Píxeles se graban en el almacén temporal de imágenes utilizado para refrescar el visor. Para valores de bit de `11', los Datos de Píxeles se graban en todos los almacenes temporales de imágenes. Los valores, o combinación, de bits de `10' se tratan como un valor o asignación inválida, y los Datos de Píxeles se ignoran y no se graban en ninguno de los almacenes temporales de imágenes. Este valor puede tener uso para aplicaciones futuras de la interfaz.

Los Bits 8 a 15 están reservados para uso futuro y, por lo tanto, generalmente se fijan en cero.

En una realización, los campos Inicio X e Inicio Y, de 2 bytes, especifican las coordenadas absolutas X e Y del punto (Inicio X, Inicio Y) para el primer píxel en al campo Datos de Píxeles. Los campos Borde Izquierdo X y Borde Superior Y, de 2 bytes, especifican la coordenada X del borde izquierdo y la coordenada Y del borde superior de la ventana de imagen alfa-cursor rellenada por el campo Datos de Píxeles, mientras que los campos Borde Derecho X y Borde Inferior Y especifican la coordenada X del borde derecho, y la coordenada Y del borde inferior de la ventana de imagen alfa-cursor que está siendo actualizada.

El campo Total de Píxeles (2 bytes) especifica el número de píxeles en el campo Datos de Píxeles a continuación.

El campo CRC de Parámetros, de 2 bytes, contiene un CRC de todos los bytes desde la Longitud de Paquete hasta el Total de Píxeles. Si este CRC no verifica la comprobación, entonces se descarta el paquete entero.

El campo Datos de Píxeles contiene la información de vídeo en bruto que ha de visualizarse, y que está formateada de la manera descrita por el campo Descriptor de Formato de Datos de Vídeo. Los datos se transmiten de a una "fila" por vez, según se expone en otro sitio.

El campo CRC de Datos de Píxeles (2 bytes) contiene un CRC de 16 bits sólo de los Datos de Píxeles. Si falla una verificación de CRC de este valor, entonces los Datos de Píxeles aún pueden emplearse, pero el contador de errores de CRC se incrementa.

Imágenes de Flujo de Vídeo Escalado

La Interfaz MDD, o el mecanismo protocolar, o el procedimiento, proporciona soporte para imágenes de flujo de vídeo escalado, que permiten al servidor enviar una imagen al cliente que está en escala mayor o menor que la imagen original, y la imagen escalada se copia a un almacén temporal principal de imágenes. Una visión general de la funcionalidad del Flujo de Vídeo Escalado y del soporte protocolar asociado se proporciona en otro sitio. Una capacidad para brindar soporte a flujos de vídeo escalados está definida por, o dentro de, el Paquete de Capacidad de Flujo de Vídeo Escalado, que se envía en respuesta a un Paquete de Solicitud de Estado Específico.

36. Paquete de Capacidad de Flujo de Vídeo Escalado

El Paquete de Capacidad de Flujo de Vídeo Escalado define las características de la imagen fuente de flujo de vídeo escalado en, o utilizado por, un cliente. El formato del Paquete de Capacidad de Flujo de Vídeo Escalado se muestra, en general, en la Fig. 79. Como se ve en la Fig. 79, en una realización, un Paquete de Capacidad de Flujo de Vídeo Escalado está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, Número Máximo de Flujos, Tamaño X Máximo de Fuente, Tamaño Y Máximo de Fuente, Capacidad RGB, Capacidad Monocromática, Reservado 1, Capacidad Y Cr Cb, Reservado 2 y CRC. La longitud del paquete, en una realización, se selecciona para que tenga un valor de 20 bytes fijos, según se muestra en el campo de longitud, incluyendo el campo Identificador de cCliente, de 2 bytes, que está reservado para el uso de un Identificador de Cliente, y que en otro caso se fija en cero, y el campo CRC. En una realización, el cliente indica una capacidad para brindar soporte al Paquete de Capacidad de Flujo de Vídeo Escalado, utilizando un valor de parámetro de 143 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido.

El campo Número Máximo de Flujos, de 2 bytes, contiene un valor para identificar el máximo número de flujos simultáneos de vídeo escalado que pueden adjudicarse a la vez. En una realización, un cliente debería denegar una solicitud para adjudicar un flujo de vídeo escalado si ya está adjudicado el número máximo de flujos de vídeo escalado. Si se han adjudicado menos del número máximo de flujos de vídeo escalado, el cliente también puede denegar la solicitud de adjudicación, basándose en otras limitaciones de recursos en el cliente.

Los campos Tamaño X e Y Máximo de Fuente (2 bytes) especifican valores para el ancho y altura máximos, respectivamente, de la imagen fuente de flujo de vídeo escalado, expresados como un número de píxeles.

El campo Capacidad RGB utiliza valores para especificar el número de bits de resolución que pueden visualizarse en formato RGB. Si el flujo de vídeo escalado no puede utilizar el formato RGB, entonces este valor se fija igual a cero. La palabra de Capacidad RGB está compuesta por tres valores sin signo distintos, donde: los Bits 3 a 0 definen un número máximo de bits de azul (la intensidad azul) en cada píxel, los Bits 7 a 4 definen el número máximo de bits de verde (la intensidad verde) en cada píxel, y los Bits 11 a 8 definen el número máximo de bits de rojo (la intensidad roja) en cada píxel, mientras que los Bits 15 a 12 están reservados para uso futuro, en futuras definiciones de capacidad y, generalmente, se fijan en cero.

El campo Capacidad Monocromática, de 1 byte, contiene un valor que especifica el número de bits de resolución que pueden visualizarse en formato monocromático. Si el flujo de vídeo escalado no puede utilizar el formato monocromático, entonces este valor se fija en cero. Los Bits 7 a 4 están reservados para uso futuro y, por lo tanto, deberían fijarse en cero (`0') para las aplicaciones actuales, aunque esto puede cambiar a lo largo del tiempo, como apreciarán los expertos en la técnica. Los Bits 3 a 0 definen el número máximo de bits de escala de grises que pueden existir en cada píxel. Estos cuatro bits hacen posible especificar que cada píxel consiste en 1 a 15 bits. Si el valor es cero, entonces el formato monocromático no dispone de soporte por parte del flujo de vídeo escalado.

El campo Reservado 1 (aquí, 1 byte) está reservado para uso futuro, proporcionando valores relacionados con la información o datos del Paquete de Flujo de Vídeo Escalado. Por lo tanto, actualmente, todos los bits en este campo se fijan en un `0' lógico. Un fin de este campo es causar que todos los campos subsiguientes de 2 bytes se alineen a una palabra de dirección de 16 bits, y causar que los campos de 4 bytes se alineen a una palabra de dirección de 32 bits.

El campo Capacidad Y Cb Cr, de 2 bytes, contiene valores que especifican el número de bits de resolución que pueden visualizarse en formato Y Cb Cr. Si el flujo de vídeo escalado no puede utilizar entonces el formato Cb Cr, entonces este valor es cero. La palabra de Capacidad Y Cb Cr está compuesta por tres valores sin signo distintos, donde: los Bits 3 a 0 definen el máximo número de bits que especifican la muestra Cr; los Bits 7 a 4 definen el número máximo de bits que especifican la muestra Cb; los Bits 11 a 8 definen el número máximo de bits que especifican la muestra Y; estando los Bits 15 a 12 reservados para uso futuro, y generalmente fijados en cero.

El campo Bits de Capacidad, de 1 byte, contiene un conjunto de indicadores que especifican capacidades asociadas al flujo de vídeo escalado. Los indicadores se definen de la manera siguiente: el Bit 0 indica que los Datos de Píxeles en el Paquete de Flujo Escalado pueden estar en formato empaquetado. Un ejemplo de datos de píxeles empaquetados y alineados por byte se muestra anteriormente en la Fig. 12. El Bit 1 está reservado para uso futuro y se fijará en cero; el Bit 2 está reservado para uso futuro y se fijará en cero; el Bit 3 indica flujos de vídeo escalado que pueden especificarse en el formato de datos de mapa de colores. Se utiliza la misma tabla de mapa de colores para los flujos de vídeo escalado que la que se emplea para el almacén temporal principal de imágenes y los planos de imagen alfa-cursor. El mapa de colores se configura utilizando el Paquete de Mapa de Colores descrito en otro sitio; y los Bits 7 a 4 están reservados para uso futuro y generalmente se fijan en cero.

El campo Reservado 2 (aquí, 1 byte) está reservado para uso futuro, proporcionando valores relacionados con la información o datos del Paquete de Flujo de Vídeo Escalado. Por lo tanto, actualmente, todos los bits en este campo se fijan en un `0' lógico. Un fin de este campo es causar que todos los campos subsiguientes de 2 bytes se alineen a una palabra de dirección de 16 bits, y causar que los campos de 4 bytes se alineen a una palabra de dirección de 32 bits.

37. Paquete de Configuración de Flujo de Vídeo Escalado

El Paquete de Configuración de Flujo de Vídeo Escalado se utiliza para definir los parámetros del flujo de vídeo escalado, y el cliente emplea la información para adjudicar almacenamiento interno, para el almacenamiento temporal y escalamiento de la imagen. Un flujo puede ser desasignado enviando este paquete con los campos Tamaño de Imagen X y Tamaño de Imagen Y iguales a cero. Los flujos de vídeo escalado que han sido desasignados pueden reasignarse más tarde con los mismos, o distintos, parámetros de flujo. En una realización, un cliente muestra una capacidad de brindar soporte al Paquete de Configuración de Vídeo Escalado utilizando un valor de parámetro de 143 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Parámetro Válido, y utilizando un valor distinto de cero en el campo Número Máximo de Flujos del Paquete de Capacidad de Flujo de Vídeo Escalado.

El formato del Paquete de Configuración de Flujo de Vídeo Escalado se muestra, en general, en la Fig. 80. Como se ve en la Fig. 80, en una realización, un Paquete de Configuración de Flujo de Vídeo Escalado está estructurado para tener los campos Longitud de Paquete Tipo de Paquete, hCliente, Identificador de Flujo, Descriptor de Formato de Datos Visuales, Atributos de Datos de Píxeles, 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 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 realización, esta longitud de paquete se fija en 24. El campo de Tipo de Paquete, de 2 bytes, emplea un valor de 136 para identificar el paquete como un Paquete de Configuración de Flujo de Vídeo Escalado. El campo Identificador de hCliente, de 2 bytes, está reservado para uso futuro como Identificador de Cliente y, por lo general, se fija en un valor cero de momento, o hasta que un usuario del protocolo determine qué valores de Identificador deben utilizarse, como se sabe.

El campo Identificador de Flujo utiliza 2 bytes para especificar un identificador único para el Identificador de Flujo. Este valor es asignado por el servidor, y variará entre cero y el máximo valor de Identificador de Flujo especificado en el Paquete de Capacidad de Visor. El servidor debe administrar el uso de los valores de Identificador de Flujo cuidadosamente, para garantizar que a cada flujo activo se le asigna un valor único, y que los flujos que ya no están activos son desasignados o reasignados.

En una realización, el campo Descriptor de Formato de Datos de Vídeo utiliza 2 bytes para especificar el formato de cada píxel en los Datos de Píxeles en el presente flujo y en el presente paquete. El formato de datos de píxeles debería ser conforme con al menos uno de los formatos válidos para el plano de imagen alfa-cursor, según lo definido en el Paquete de Capacidad de Imagen Alfa-Cursor. El Descriptor de Formato de Datos de Vídeo define el formato de píxel sólo para el paquete actual y no implica que se continuará utilizando un formato constante durante la vida útil de un flujo de vídeo específico. La Fig. 11 ilustra una realización de cómo se codifica el Descriptor de Formato de Datos de Vídeo, como se ha expuesto anteriormente para otros paquetes.

El campo Atributos de Datos de Píxeles, de 2 bytes, tiene valores que se interpretan de la siguiente manera:

Los Bits 1 y 0 seleccionan el visor adonde se encaminarán los datos de píxeles.

Bits [1:0] = 11 o 00: los datos se exhiben a ambos ojos

Bits [1:0] = 10: los datos se encaminan sólo al ojo izquierdo.

Bits [1:0] = 01: los datos se encaminan sólo al ojo derecho.

El Bit 2 indica si los Datos de Píxeles están o no en formato entrelazado. Cuando el Bit 2 es 0, entonces los Datos de Píxeles están en el formato progresivo estándar. El número de fila (coordenada Y del píxel) se incrementará en 1 al avanzar desde una fila a la próxima. Cuando el Bit 2 es 1, entonces los Datos de Píxeles están en formato entrelazado. El número de fila (coordenada Y del píxel) se incrementará en 2 al avanzar desde una fila a la siguiente.

El Bit 3 indica si los Datos de Píxeles están o no en formato de píxeles alternativo. Esto es similar a la modalidad de entrelazado estándar activada por el bit 2, pero el entrelazado es vertical en lugar de horizontal. Cuando el Bit 3 es 0, los Datos de Píxeles están en el formato progresivo estándar. El número de columna (coordenada X del píxel) se incrementará en 1 según se recibe cada píxel sucesivo. Cuando el Bit 3 es 1, entonces los Datos de Píxeles están en un formato de píxel alternativo. El número de columna (coordenada X del píxel) se incrementará en 2 según se recibe cada píxel.

El Bit 4 indica si los Datos de Píxeles están relacionados o no con el visor o la cámara. Cuando el Bit 4 es 0, los Datos de Píxeles van a, o vienen desde, el almacén temporal de tramas de pantalla. Cuando el Bit 4 es 1, los Datos de Píxeles van a, o vienen desde, la cámara.

El Bit 5 está reservado para uso futuro y, por lo tanto, se fija generalmente en cero.

Los Bits 7 y 6 son los Bits de Actualización de Visor que especifican el almacén temporal de tramas donde se grabarán los datos de píxeles. Los efectos de los Bits de Actualización se describen en más detalle en otro sitio. Cuando los Bits [7:6] son `01', los Datos de Píxeles se graban en el almacén temporal de imágenes fuera de línea. Cuando los Bits [7:6] son `00', los Datos de Píxeles se graban en el almacén temporal de imágenes utilizado para refrescar el visor. Cuando los Bits [7:6] son `11', los Datos de Píxeles se graban en todos los almacenes temporales de imágenes. Si los Bits [7:6] son `10', esto se trata como un valor inválido. Estos bits están actualmente reservados para uso futuro. En esta situación, los Datos de Píxeles serían ignorados y no se grabarían en ninguno de los almacenes temporales de imágenes.

Los Bits 8 a 15 están reservados para uso futuro y se fijarán en cero.

Los campos Borde Izquierdo X, Borde Superior Y, Borde Derecho X, Borde Inferior Y, de 2 bytes, especifican, respectivamente, la coordenada X del borde izquierdo, la coordenada Y del borde superior, la coordenada X del borde derecho y el borde inferior de la imagen de destino. Los campos Tamaño de Imagen X y Tamaño de Imagen Y, de 2 bytes, especifican el ancho y la altura, respectivamente, de la imagen fuente. El campo CRC, nuevamente, contiene un CRC de todos los bytes en el paquete, incluyendo la Longitud de Paquete.

38. Paquete de Acuse de Recibo de Flujo de Vídeo Escalado

El Paquete de Acuse de Recibo de Flujo de Vídeo Escalado permite a un cliente acusar recibo de la recepción de un Paquete de Configuración de Flujo de Vídeo Escalado. El cliente indicará su capacidad de brindar soporte al Paquete de Acuse de Recibo de Flujo de Vídeo Escalado mediante 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 mediante un valor distinto de cero en el campo Número Máximo de Flujos del Paquete de Capacidad de Flujo de Vídeo Escalado.

El formato del Paquete de Acuse de Recibo de Flujo de Vídeo Escalado se muestra, en general, en la Fig. 81. Como se ve en la Fig. 81, en una realización, un Paquete de Acuse de Recibo de Flujo de Vídeo Escalado está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, cCliente, Identificador de Flujo, Código de Acuse de Recibo y CRC. El campo Longitud de Paquete, de 2 bytes, se utiliza para especificar el número total de bytes, excluyendo el campo de longitud de paquete, con un valor de 10 para este tipo de paquete, mientras que un Tipo de Paquete de 137 identifica un paquete como un Paquete de Acuse de Recibo de Flujo de Vídeo Escalado.

El campo Identificador de cCliente, de 2 bytes, está reservado para uso futuro del Identificador de Cliente, y generalmente se fija en cero. El campo Identificador de Flujo, de 2 bytes, especifica un identificador único para el Identificador de Flujo. Este es el mismo valor asignado por el servidor en el Paquete de Configuración de Flujo de Vídeo Escalado.

El campo de Código de Acuse de Recibo, de 2 bytes, proporciona valores que contienen un código que describe el resultado de un intento de actualizar el flujo de vídeo escalado especificado. En una realización, los códigos se definen de la siguiente manera:

0 -

El intento de asignación del flujo tuvo éxito.

1 -

el intento de desasignación del flujo tuvo éxito.

2 -

intento inválido de asignar un Identificador de flujo que ya ha sido asignado.

3 -

intento inválido de desasignar un Identificador de flujo que ya está desasignado.

4 -

el cliente no presta soporte a flujos de vídeo escalado

5 -

los parámetros de flujo son incoherentes con la capacidad del cliente.

6 -

valor de Identificador de flujo mayor que el valor máximo permitido por el cliente.

7 -

recursos insuficientes disponibles en el cliente para asignar el flujo especificado.

\vskip1.000000\baselineskip

El campo CRC, de 2 bytes, contiene el CRC de todos los bytes en el paquete, incluyendo la Longitud de Paquete.

39. Paquete de Flujo de Vídeo Escalado

El Paquete de Flujo de Vídeo Escalado se utiliza para transmitir los datos de píxeles asociados a un flujo específico de vídeo escalado. El tamaño de la región mencionada por este paquete está definido por el Paquete de Configuración de Flujo de Vídeo Escalado. El cliente indicará su capacidad de prestar soporte al Paquete de Flujo de Vídeo Escalado mediante un valor de parámetro de 143 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido, y utilizando una respuesta de asignación exitosa de flujo de vídeo escalado en al campo Código de Acuse de Recibo del Paquete de Acuse de Recibo de Flujo de Vídeo Escalado.

El formato de una realización del Paquete de Flujo de Vídeo Escalado se muestra, en general, en la Fig. 82. Como se ve en la Fig. 82, un Paquete de Flujo de Vídeo Escalado está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, Identificador de Flujo, CRC de Parámetros, Total de Píxeles, Datos de Píxeles y CRC de Datos de Píxeles. El campo Tipo de Paquete, de 2 bytes, utiliza un valor de 18 para identificar un paquete como un Paquete de Flujo de Vídeo Escalado. El campo Identificador de hCliente está reservado para el Identificador de Cliente y, generalmente, se fija en cero. Como antes, el campo Identificador de Flujo, de 2 bytes, especifica un identificador único para el Identificador de Flujo. Este valor es especificado por el servidor en el Paquete de Configuración de Flujo de Vídeo Escalado, y confirmado en el Paquete de Acuse de Recibo de Flujo de Vídeo Escalado.

El campo Total de Píxeles, de 2 bytes, especifica el número de píxeles en el campo Datos de Píxeles a continuación. El campo CRC de Parámetros, de 2 bytes, tiene el CRC de todos los bytes desde la Longitud de Paquete hasta el Total de Píxeles. Si este CRC no confirma la comprobación, entonces se descartará el paquete entero. El campo Datos de Píxeles, de 2 bytes, contiene la información de vídeo en bruto que debe ser escalada y luego visualizada. Los datos se formatean de la manera descrita por el campo Descriptor de Formato de Datos de Vídeo. Los datos se transmiten de a una fila por vez, según lo anteriormente definido.

El campo CRC de Datos de Píxeles, de 2 bytes, contiene un CRC sólo de los Datos de Píxeles. Si este CRC no confirma la comprobación, entonces los Datos de Píxeles se utilizarán aún así, pero el total de errores de CRC se incrementará.

40. Paquete de Solicitud de Estado Específico

El Paquete de Solicitud de Estado Específico proporciona un medio, mecanismo o procedimiento para que un servidor solicite que el cliente envíe de vuelta un paquete de capacidad o estado al servidor, según lo especificado en este paquete. El cliente devuelve el paquete del tipo especificado en el siguiente Paquete de Encapsulación de Enlace Inverso. El cliente fijará el bit 17 en el campo Capacidad de Característica de Cliente del Paquete de Capacidad de Cliente si el cliente tiene la capacidad de responder al Paquete de Solicitud de Estado Específico. El cliente debe indicar su capacidad de prestar soporte al Paquete de Solicitud de Estado Específico utilizando el bit 21 del campo de Capacidad de Característica de Cliente del Paquete de Capacidad de Cliente.

El formato de una realización de un Paquete de Solicitud de Estado Específico se muestra, en general, en la Fig. 83. Como se ve en la Fig. 83, un Paquete de Solicitud de Estado Específico está estructurado para tener los campos de Longitud de Paquete, Tipo de Paquete, Identificador de hCliente, Identificador de Paquete de Estado y CRC.

El campo 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 en un valor de 10 para este tipo de paquete. Un Tipo de Paquete de 138 identifica el paquete como un Paquete de Solicitud de Estado Específico.

El campo Identificador de hCliente (2 bytes) está reservado para uso futuro por un Identificador de Cliente, y se fija en cero por ahora.

El campo Identificador de Paquete de Estado, de 2 bytes, especifica el tipo de paquete de capacidad o estado que el cliente va a enviar al servidor, según lo siguiente:

66 -

El Paquete de Capacidad de Cliente será enviado por el cliente.

133 -

El Paquete de Capacidad de Imagen Alfa-Cursor será enviado por el cliente.

139 -

Se enviará 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 Paquetes será enviado por el cliente.

141 -

El Paquete de Capacidad de Visualización Personal será enviado por el cliente.

142 -

El Paquete de Informe de Errores de Visor será enviado por el cliente.

143 -

El Paquete de Capacidad de Flujo de Vídeo Escalado será enviado por el cliente.

144 -

El Paquete de Identificación de Visor será enviado por el cliente.

56 a 63 -

pueden utilizarse para identificadores de capacidad y estado específicos del fabricante.

\vskip1.000000\baselineskip

El campo CRC, nuevamente, contiene un CRC de todos los bytes en el paquete, incluyendo la Longitud de Paquete.

\vskip1.000000\baselineskip

41. Paquete de Lista de Respuesta de Estado Válido

El Paquete de Respuesta de Estado Válido proporciona al servidor una lista de paquetes de estado y capacidad a los cuales el cliente tiene capacidad de responder. Un cliente puede indicar una capacidad de prestar soporte al Paquete de Lista de Respuesta de Estado Válido utilizando el bit 21 del campo de Capacidad de Característica de Cliente de Paquete de Capacidad de Cliente.

El formato de una realización de un Paquete de Lista de Respuesta de Estado Válido se muestra, en general, en la Fig. 84. Como se ve en la Fig. 84, un Paquete de Lista de Respuesta de Parámetro Válido está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, Número de Valores en Lista, Lista de Respuesta de Parámetro Válido y CRC. La longitud del paquete para este tipo de paquete se fija generalmente en 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 Identificador de cCliente está reservado para uso futuro como el Identificador de Cliente y, por lo general, se fija en cero. El campo Número de Valores en Lista, de 2 bytes, especifica el número de elementos en la siguiente Lista de Respuesta de Parámetro Válido.

El campo 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 servidor. Si el cliente ha indicado que puede responder al Paquete de Solicitud de Estado Específico (utilizando el bit 21 del campo Capacidad de Característica de Cliente en el Paquete de Capacidad de Cliente), entonces es capaz de enviar al menos el Paquete de Capacidad de Cliente (Tipo de Paquete = 66) y el Paquete de Lista de Respuesta de Estado Válido (Tipo de Paquete = 139). Los Tipos de Paquete que pueden ser enviados por el cliente y que pueden ser incluidos en esta lista, junto con sus respectivas asignaciones para los fines de una realización, son

66 -

Paquete de Capacidad de Cliente.

133 -

Paquete de Capacidad de Imagen Alfa-Cursor.

139 -

Paquete de Lista de Respuesta de Estado Válido, que identifica los tipos exactos de paquetes de capacidad y estado que el cliente puede enviar.

140 -

Paquete de Parámetros de Retardo de Procesamiento de Paquetes.

141 -

Paquete de Capacidad de Visualización Personal.

142 -

Paquete de Informe de Errores de Cliente.

143 -

Paquete de Capacidad de Flujo de Vídeo Escalado.

144 -

Paquete de Identificación de Cliente.

56 a 63 -

pueden utilizarse para identificadores de capacidad y estado específicos del fabricante.

El campo CRC contiene el CRC de todos los bytes en el paquete, incluyendo la Longitud de Paquete.

\vskip1.000000\baselineskip

42. Paquete de Parámetros de Retardo de Procesamiento de Paquetes

El Paquete de Parámetros de Retardo de Procesamiento de Paquetes proporciona un conjunto de parámetros para permitir que el servidor calcule el tiempo requerido para completar el procesamiento asociado a la recepción de un tipo específico de paquete. Algunos comandos enviados por el servidor no pueden ser completados por el cliente en tiempo cero. El servidor puede sondear los bits de estado en los Paquetes de Solicitud y Estado de Visor para determinar si ciertas funciones han sido completadas por el cliente, o el servidor puede calcular el tiempo de realización utilizando los parámetros devueltos por el cliente en el Paquete de Parámetros de Retardo de Procesamiento de Paquetes. El cliente indicará su capacidad de brindar soporte al Paquete de Parámetros de Retardo de Procesamiento de Paquetes utilizando un valor de parámetro de 140 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido.

El formato de una realización del Paquete de Parámetros de Retardo de Procesamiento de Paquetes se muestra, en general, en la Fig. 85A. Como se ve en la Fig. 85A, un Paquete de Parámetros de Retardo de Procesamiento de Paquetes está estructurado para tener los campos de Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, Número de Elementos de Lista, Lista de Parámetros de Retardo y CRC. La longitud del paquete para este tipo de paquete se fija generalmente en 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 Paquetes. El campo Identificador de cCliente está reservado para uso futuro como el Identificador de Cliente y, por lo general, se fija en cero. El campo Número de Elementos de Lista, de 2 bytes, especifica el número de elementos en la siguiente Lista de Respuesta de Parámetros Válidos.

El campo Lista de Parámetros de Retardo es una lista que contiene uno o más elementos de la Lista de Parámetros de Retardo. El formato para una realización de un único elemento de la Lista de Parámetros de Retardo se muestra en la Fig. 85B, donde se muestran los campos Tipo de Paquete para Retardo, el Retardo de Píxel, el Retardo de Píxel Horizontal, el Retardo de Píxel Vertical y el Retardo Fijo.

Cada Elemento de la Lista de Parámetros de Retardo está generalmente restringido a tener exactamente 6 bytes de longitud, y se define adicionalmente de la siguiente manera:

El campo Tipo de Paquete para Retardo, de 2 bytes, especifica el Tipo de Paquete al cual se aplican los siguientes parámetros de retardo.

El campo Retardo de Píxel (1 byte) comprende un índice a un valor de retardo. El valor leído de la tabla se multiplica por el número total de píxeles en el campo de destino del paquete. El número total de píxeles es igual al ancho multiplicado por la altura del área de destino del mapa de bits mencionado por el paquete.

El campo Retardo de Píxel 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 se multiplica por el ancho (en píxeles) del campo de destino del paquete.

El campo Retardo de Píxel Vertical, 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 se multiplica por la altura (en píxeles) del campo de destino del paquete.

El campo Retardo Fijo utiliza 1 byte como un índice en 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 el retardo del tiempo de realización del procesamiento del paquete, está determinado según la relación:

Retardo =

(RetardoProcesamientoPaquete(RetardoPíxel)*TotalPíxeles) +

\quad

(RetardoProcesamientoPaquete(RetardoPíxelHorizontal)*Ancho) +

\quad

(RetardoProcesamientoPaquete(RetardoPíxelVertical)*Altura) +

\quad

RetardoProcesamientoPaquete(RetardoFijo)

\vskip1.000000\baselineskip

Para algunos paquetes, el Total Píxeles, el Ancho, o la Altura no se aplican, porque esos parámetros no son mencionados en el paquete correspondiente. En esos casos, el parámetro correspondiente Retardo Píxel se fija generalmente en cero.

43. Paquete de Capacidad de Visor Personal

El Paquete de Capacidad de Visor Personal proporciona un conjunto de parámetros que describen las capacidades de un dispositivo visualizador personal, tal como un visor montado en la cabeza, o gafas con visor. Esto permite que el servidor personalice la información de visualización según las capacidades específicas de un cliente. Un cliente, por otra parte, indica una capacidad de enviar el Paquete de Capacidad de Visor Personal utilizando un parámetro correspondiente en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido.

El formato de una realización de un Paquete de Capacidad de Visor Personal se muestra, en general, en la Fig. 86. Como se ve en la Fig. 86, un Paquete de Capacidad de Visor Personal está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, Diseño de SubPíxel, Forma de Píxel, Campo de Visión Horizontal, Campo de Visión Vertical, Cruce Visual de Eje, Imagen Izq./Dcha., Transparencia, Brillo Máximo, Capacidad Óptica, Distancia Interpupilar Mínima, Distancia Interpupilar Máxima, Lista de Puntos de Curvatura de Campo y CRC. En una realización, el valor del campo Longitud de Paquete se fija en 68. Un valor de Tipo de Paquete de 141 identifica un paquete como un Paquete de Capacidad de Visor Personal. El campo Identificador de cCliente está reservado para uso futuro y generalmente se fija en cero por ahora.

El campo de Diseño de SubPíxel especifica el diseño físico de un subpíxel desde el extremo superior al inferior y de izquierda a derecha, utilizando los valores de: 0 para indicar que no está definido un diseño de subpíxel; 1 para indicar una franja roja, verde, azul; 2 para indicar una franja azul, verde, roja; 3 para indicar un quadpíxel, con una disposición de subpíxeles de 2 por 2, de rojo en el extremo superior izquierdo, azul en el extremo inferior derecho, y dos subpíxeles verdes, uno en el extremo inferior izquierdo y el otro en el extremo superior derecho; 4 para indicar un quadpíxel, con una disposición de subpíxeles de 2 por 2, con rojo en el extremo inferior izquierdo, azul en el extremo superior derecho, y dos subpíxeles verdes, uno en el extremo superior izquierdo y el otro en el extremo inferior derecho; 5 para indicar un Delta (Tríada); 6 para indicar un mosaico con rojo, verde y azul superpuestos (p. ej., visor LCOS con color secuencial por campo); y con los valores 7 a 255 generalmente reservados para uso futuro.

El campo Forma de Píxel especifica la forma de cada píxel que está compuesto de una configuración específica de subpíxeles, utilizando un valor de: 0 para indicar que no está definida una forma de subpíxel; 1 para indicar forma redonda; 2 para indicar forma cuadrada; 3 para indicar forma rectangular; 4 para indicar forma ovalada; 5 para indicar forma elíptica; y con los valores 6 a 255 reservados para uso futuro de indicación de formas deseadas, como apreciará el experto en la técnica.

Un campo Campo de Visión Horizontal (HFOV), de 1 byte, especifica el campo de visión horizontal en incrementos de 0,5 grados (p. ej., si el HFOV es de 30 grados, este valor es 60). Si este valor es cero, entonces no se especifica el HFOV.

Un campo Campo de Visión Vertical (VFOV), de 1 byte, especifica el campo de visión vertical en incrementos de 0,5 grados (p. ej., si el VFOV es de 30 grados, este valor es 60). Si este valor es cero, entonces no se especifica el VFOV.

Un campo Cruce Visual de Eje, de 1 byte, especifica el cruce visual de eje en incrementos de 0,01 dioptrías (1/m) (p. ej., si el cruce visual de eje es de 2,22 metros, este valor es 45). Si este valor es cero, entonces no se especifica el Cruce Visual de Eje. (Nota: ¿es adecuada la especificación de este parámetro para la gama deseada en la mayoría de las aplicaciones?).

Un campo Solapamiento de Imagen Izquierda/Derecha, de 1 byte, especifica el porcentaje de solapamiento de la imagen izquierda y derecha. La gama admisible del solapamiento de imagen, en porcentaje, está entre 1 y 100. Los valores de 101 a 255 son inválidos, y no se utilizarán. Si este valor es cero, entonces no se especifica el solapamiento de imagen.

Un campo Transparencia, de 1 byte, especifica el porcentaje de transparencia de la imagen. La gama admisible de transparencia, en porcentaje, está entre 0 y 100. Los valores de 101 a 254 son inválidos y no se utilizarán. Si este valor es 255, entonces no se especifica el porcentaje de transparencia.

Un campo Brillo Máximo, de 1 byte, especifica el máximo brillo en incrementos de 20 niteres (p. ej., si el brillo máximo es de 100 niteres, este valor es 5). Si este valor es cero, entonces no se especifica el brillo máximo.

Un campo Indicadores de Capacidad Óptica, de 2 bytes, contiene varios campos que especifican capacidades ópticas del visor. Estos valores de bit se asignan generalmente según lo siguiente:

Los Bits 15 a 5 están reservados para uso futuro, y se fijarán en cero.

El Bit 4 selecciona el Ajuste de Foco de Lente, donde un valor de `0' significa que el visor no tiene ajuste de foco de Lente, y un valor de `1' significa que el visor tiene un ajuste de foco de lente.

\newpage

Los Bits 3 a 2 seleccionan una Función Binocular según lo siguiente: un valor de 0 significa que el visor es binocular y puede exhibir sólo imágenes bidimensionales (2D); 1 significa que el visor es binocular y puede exhibir imágenes tridimensionales (3D); 2 significa que el visor es monocular, y 3 está reservado para uso futuro.

Los Bits 1 a 0 seleccionan la Simetría de Curvatura de Campo Izquierdo-Derecho, 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 entre A1 y E5 se fijarán en cero, excepto el punto C3, que especificará la distancia focal del visor, o se fijará en cero para indicar que la distancia focal no está especificada. Un valor de 1 significa que los visores Izquierdo y Derecho tienen la misma simetría; 2 significa que los visores Izquierdo y Derecho se reflejan en el eje vertical (columna C); y 3 está reservado para uso futuro.

El campo Distancia Interpupilar (IPD) Mínima, de 1 byte, especifica la distancia interpupilar mínima en milímetros (mm). Si este valor es cero, entonces no se especifica la distancia interpupilar mínima. El campo Distancia Interpupilar (IPD) Máxima, de 1 byte, especifica la máxima distancia interpupilar en milímetros (mm). Si este valor es cero, entonces no se especifica la distancia interpupilar máxima.

El campo Lista de Puntos de Curvatura de Campo contiene una lista de 25 parámetros de 2 bytes, que especifican la distancia focal en milésimas de dioptría (1/m), con una gama entre 1 y 65535 (p. ej., 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 se etiquetan A1 a E5, según se muestra más adelante. Los puntos se distribuirán homogéneamente sobre el área activa del visor. La columna C corresponde al eje vertical del visor y la fila 3 corresponde al eje horizontal del visor. Las columnas A y E corresponden a los bordes izquierdo y derecho del visor, respectivamente. Y las filas 1 y 5 corresponden a los bordes superior e inferior del visor, respectivamente. El orden de los 25 puntos en la lista es: A1, B1, C1, D1, E1, A2, B2, C2, D2, E2, A3, B3, C3, D3, E3, A4, B4, C4, D4, E4, A5, B5, C5, D5, E5.

10

El campo 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 que un cliente proporcione una lista de errores de funcionamiento al servidor. El cliente puede detectar una amplia gama de errores en el curso de su funcionamiento normal, como resultado de recibir ciertos comandos desde el servidor. Los ejemplos de estos errores incluyen: el cliente puede haber recibido la orden de funcionar en una modalidad a la que no presta soporte, el cliente puede haber recibido un paquete que contiene ciertos parámetros que están fuera de rango, o que están más allá de la capacidad del cliente, o el cliente puede haber recibido la orden de ingresar a una modalidad en una secuencia indebida. El Paquete de Informe de Errores de Cliente puede utilizarse para detectar errores durante el funcionamiento normal, pero es sumamente útil al diseñador e integrador del sistema, para diagnosticar problemas en el desarrollo y la integración de los sistemas servidor y cliente. Un cliente indica su capacidad de enviar un Paquete de Informe de Errores de Cliente utilizando un valor de parámetro de 142 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido.

El formato de una realización de un Paquete de Informe de Errores de Cliente se muestra, en general, en la Fig. 87A. Como se ve en la Fig. 87A, un Paquete de Informe de Errores de Cliente está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, 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 Identificador de cCliente está reservado para uso futuro, y se fija generalmente en cero por ahora. El Campo 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 Lista de Códigos de Error (aquí, 8 bytes) es una lista que contiene uno o más elementos de la Lista de Informe de Errores. El formato de un elemento individual de la Lista de Informe de Errores se muestra en la Fig. 87B.

En una realización, según se muestra en la Fig. 87B, cada Elemento de la Lista de Informe de Errores tiene exactamente 4 bytes de longitud, y tiene una estructura, en una realización, que comprende: un campo de Código de Error de Visor, de 2 bytes, que especifica el tipo de error que se está informando, y un campo Subcódigo de Error, de 2 bytes, especifica un mayor nivel de detalle con respecto al error definido por el paquete de Código de Error de Cliente. La definición específica de cada Código de Error de Cliente está definida por el fabricante del cliente. No se requiere que un Subcódigo de Error esté definido para cada Código de Error de Visor y, en aquellos casos donde el Subcódigo de Error no está definido, el valor se fija en cero. La definición específica de cada Subcódigo de Error está definida por el fabricante del cliente.

45. Paquete de Identificación de Cliente

El Paquete de Identificación de Cliente permite a un cliente devolver datos de identificación en respuesta a un Paquete de Solicitud de Estado Específico. En una realización, un cliente indica una capacidad de enviar el Paquete de Identificación de Visor utilizando un valor de parámetro de 144 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido. Es útil para el servidor poder determinar el nombre y número de modelo del fabricante del dispositivo cliente, leyendo estos datos provenientes del cliente. La información puede utilizarse para determinar si el cliente tiene capacidades especiales que no pueden describirse en el Paquete de Capacidad de Cliente. Potencialmente, hay dos procedimientos, medios o mecanismos para leer información de identificación proveniente del cliente. Uno es mediante el empleo del Paquete de Capacidad de Cliente, que contiene campos similares a aquellos en la estructura básica EDID. El otro procedimiento es mediante el empleo del Paquete de Identificación de Cliente que contiene un conjunto más rico de información, en comparación con los campos similares en el Paquete de Capacidad de Cliente. Esto permite que un servidor identifique los 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 realización de un Paquete de Identificación de Cliente se muestra, en general, en la Fig. 88. Como se ve en la Fig. 88, un Paquete de Identificación de Cliente está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, 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 del Nombre del Fabricante, Cadena del Nombre del Producto, Cadena del Número en Serie y CRC.

El campo Tipo de Paquete, de 2 bytes, contiene un valor que identifica el paquete como un Paquete de Identificación de Visor. Este valor se selecciona con un valor de 144 en una realización. El campo Identificador de cCliente (2 bytes) nuevamente está reservado para uso futuro para el Identificador de Cliente, y generalmente se fija en cero. El campo CRC (2 bytes) contiene un CRC de 16 bits de todos los bytes en el paquete, incluyendo la Longitud de Paquete.

Un campo Semana de Fabricación, de 1 byte, contiene un valor que define la semana de fabricación del visor. En al menos una realización, este valor está en la gama entre 1 y 53, si recibe soporte del cliente. Si este campo no dispone de soporte del cliente, entonces se fija generalmente en cero. Un campo de Año de Fabricación, de 1 byte, contiene un valor que define el año de fabricación del cliente (visor). Este valor es un desplazamiento desde el año 1990 como punto de partida, aunque podrían utilizarse otros años como base. Los años en la gama entre 1991 y 2245 pueden expresarse en este campo. Ejemplo: el año 2003 corresponde a un valor de Año de Fabricación de 13. Si este campo no dispone de soporte por parte del cliente, debería fijarse en un valor cero.

Cada uno de los campos Longitud del Nombre del Fabricante, Longitud del Nombre del Producto y Longitud del Número de Serie contiene valores de 2 bytes que especifican, respectivamente, la longitud del campo Cadena del Nombre del Fabricante, incluyendo caracteres cualesquiera de terminación nula o de relleno nulo, la longitud del campo Cadena del Nombre del Producto, incluyendo caracteres cualesquiera de terminación nula o de relleno nulo, y la longitud del campo Cadena del Número de Serie, incluyendo caracteres cualesquiera de terminación nula o de relleno nulo.

Cada uno de los campos Cadena del Nombre del Fabricante, Cadena del Nombre del Producto y Cadena del Número de Serie contiene un número variable de bytes especificados, respectivamente, por los campos Longitud del Nombre del Fabricante, Nombre del Producto y Número de Serie, que contienen una cadena ASCII que especifica, respectivamente, el fabricante, el nombre del producto y el número de serie alfanumérico del visor. Cada una de estas cadenas está terminada por al menos un carácter nulo.

46. Paquete de Capacidad de Visor Alternativo

El Paquete de Capacidad de Visor Alternativo indica la capacidad de los visores alternativos conectados al controlador de cliente MDDI. Se envía en respuesta a un Paquete de Solicitud de Estado Específico. Cuando se le solicita, un dispositivo cliente envía un Paquete de Capacidad de Visor Alternativo para cada visor alternativo que recibe soporte. El cliente indicará esta capacidad para enviar el Paquete de Capacidad de Visor Alternativo mediante un valor de parámetro de 145 en la Lista de Respuesta de Parámetro Válido del Paquete de Lista de Respuesta de Estado Válido.

Para los sistemas MDDI gestionados en modalidad interna, puede ser común tener más de un visor conectado a un controlador de cliente MDDI. Un ejemplo de aplicación es un teléfono móvil con un gran visor en el interior de la cubierta abatible, y un visor más pequeño en el exterior. El campo Número de Visores Alternativos del Paquete de Capacidad de Cliente se emplea para informar que está conectado más de un visor, y el Paquete de Capacidad de Visor Alternativo informa de la capacidad de cada visor alternativo. El paquete de flujo de vídeo contiene 4 bits en el campo Atributos de Datos de Píxeles para dirigirse a cada visor alternativo en el dispositivo cliente.

El formato de una realización de un Paquete de Capacidad de Visor Alternativo se muestra, en general, en la Fig. 89. Como se ve en la Fig. 89, un Paquete de Capacidad de Visor Alternativo está estructurado para tener campos de Longitud de Paquete, Tipo de Paquete, Identificador de cCliente, Número de Visor Alternativo, Reservado 1, Ancho de Mapa de Bits, Altura de Mapa de Bits, Ancho de Ventana de Visor, Altura de Ventana de Visor, Ancho de RGB de Mapa de Colores, Capacidad de RGB, Capacidad Monocromática, Reservado 2, Capacidad de Y Cb Cr, Capacidad de Característica de Visor, Reservado 3 y CRC. Un valor de Tipo de Paquete de 145 identifica un paquete como un Paquete de Capacidad de Visor Alternativo. El campo Identificador de cCliente está reservado para un Identificador de Cliente de uso futuro y generalmente se fija en cero.

El campo Número de Visor Alternativo utiliza 1 byte para indicar la identidad del visor alternativo, con un entero en la gama entre 0 y 15. El primer visor alternativo será el número 0, y los otros visores alternativos se identificarán con valores únicos del Número de Visor Alternativo, siendo el valor más grande el número total de visores alternativos menos 1. Los valores más grandes que el número total de visores alternativos menos 1 no se utilizarán. Ejemplo: un teléfono móvil con un visor primario y un visor de Identificador de llamante conectado con un cliente MDDI tiene un visor alternativo, de manera que el Número de Visor Alternativo del visor del Identificador de llamante es cero, y el campo Número de Visores Alternativos del Paquete de Capacidad de Visor tiene un valor de 1.

El campo Reservado 1 (1 byte) está reservado para uso futuro. Todos los bits en este campo se fijan en cero. Un fin de este campo es causar que todos los campos subsiguientes de 2 bytes se alineen a una palabra de dirección de 16 bits, y causar que los campos de 4 bytes se alineen a una palabra de dirección de 32 bits.

El campo Ancho de Mapa de Bits utiliza 2 bytes que especifican el ancho del mapa de bits, expresado como un número de píxeles. El campo Altura de Mapa de Bits utiliza 2 bytes que especifican la altura del mapa de bits, expresada como un número de píxeles. El campo Ancho de Ventana de Visor utiliza 2 bytes que especifican el ancho de la ventana del visor, expresado como un número de píxeles. El campo Altura de Ventana de Visor utiliza 2 bytes que especifican la altura de la ventana del visor, expresada como un número de píxeles.

El campo Ancho de RGB de Mapa de Colores utiliza 2 bytes que especifican el número de bits de componentes de colores rojo, verde y azul que pueden visualizarse en la modalidad de visualización de mapa de colores (paleta). Puede utilizarse un máximo de 8 bits para cada componente de color (rojo, verde y azul). Incluso aunque se envíen 8 bits de cada componente de color en el Paquete de Mapa de Colores, sólo se utiliza el número de bits menos significativos de cada componente de color definido en este campo. Si el visor cliente no puede utilizar el formato de mapa de colores (paleta), entonces este valor es cero. La palabra del Ancho de RGB de Mapa de Colores está compuesta por tres valores sin signo distintos:

Los Bits 3 a 0 definen el máximo número de bits de azul en cada píxel, siendo considerados válidos los valores entre 0 y 8. Los Bits 7 a 4 definen el máximo número de bits de verde en cada píxel, siendo considerados válidos los valores entre 0 y 8. Los bits 11 1 a 8 definen el máximo número de bits de rojo en cada píxel, siendo considerados válidos los valores entre 0 y 8. Los Bits 14 a 12 están reservados para uso futuro y generalmente se fijan en cero. El Bit 15 se utiliza para indicar la capacidad de un cliente de aceptar datos de píxeles de Mapa de Colores en formato empaquetado o desempaquetado. Cuando el Bit 15 se fija en un nivel de uno lógico, esto indica que el cliente puede aceptar datos de píxeles de Mapa de Colores en formato bien empaquetado o bien desempaquetado. Si el bit 15 se fija en un cero lógico, esto indica que el cliente puede aceptar datos de píxeles de Mapa de Colores sólo en formato desempaquetado.

El campo Capacidad RGB utiliza 2 bytes para especificar el número de bits de resolución que pueden exhibirse en formato RGB. En una realización, si el cliente no puede utilizar el formato RGB, entonces este valor se fija igual a cero. La palabra de Capacidad de RGB se compone de tres valores sin signo distintos: los Bits 3 a 0 definen el número máximo de bits de azul (la intensidad azul) en cada píxel. Los Bits 7 a 4 definen el número máximo de bits de verde (la intensidad verde) en cada píxel, y los Bits 11 a 8 definen el número máximo de bits de rojo (la intensidad roja) en cada píxel. Los Bits 14 a 12 se reservan para uso futuro y se fijan en cero. El Bit 15 se utiliza para indicar la capacidad de un cliente para aceptar datos de píxeles RGB en formato empaquetado o desempaquetado. Cuando el Bit 15 está fijado en un nivel de uno lógico, esto indica que el cliente puede aceptar datos de píxeles RGB en formato bien empaquetado o bien desempaquetado. Si el Bit 15 está fijado en un cero lógico, esto indica que el cliente puede aceptar datos de píxeles RGB sólo en formato desempaquetado.

El campo Capacidad Monocromática, de 1 byte, contiene un valor o información para especificar el número de bits de resolución que pueden exhibirse en formato monocromático. Si el cliente no puede utilizar el formato monocromático, entonces este valor se fija igual a cero. Los Bits 6 a 4 están reservados para uso futuro y generalmente se fijan en cero. Los Bits 3 a 0 definen el máximo número de bits de escala de grises que pueden existir en cada píxel. Estos cuatro bits hacen posible especificar que cada píxel consiste en 1 a 15 bits. Si el valor es cero, entonces el formato monocromático no dispone de soporte por parte del cliente. El Bit 7, cuando está fijado en uno, indica que el cliente puede aceptar datos de píxeles monocromáticos en formato bien empaquetado o bien desempaquetado. Si el Bit 7 está fijado en cero, esto indica que el cliente puede aceptar datos de píxeles monocromáticos sólo en formato desempaquetado.

El campo Reservado 2 es un campo de 1 byte de largo, reservado para uso futuro, y que generalmente tiene todos los bits en este campo fijados en el nivel de cero lógico. En una realización, un fin de este campo es causar que todos los campos subsiguientes de 2 bytes se alineen a una palabra de dirección de 16 bits, y causar que los campos de 4 bytes se alineen a una palabra de dirección de 32 bits.

Un campo Capacidad Y Cb Cr, de 2 bytes, especifica el número de bits de resolución que pueden visualizarse en formato Y Cb Cr. Si el cliente no puede utilizar el formato Y Cb Cr, entonces este valor es cero. La palabra Capacidad Y Cb Cr se compone de tres valores sin signo distintos: los Bits 3 a 0 definen el número máximo de bits que especifican la muestra Cb, los Bits 7 a 4 definen el número máximo de bits que especifican la muestra Cr, los Bits 11 a 8 definen el número máximo de bits que especifican la muestra Y y los Bits 14 a 12 están reservado para uso futuro, y se fijan en cero. El Bit 15, cuando está fijado en el valor uno, indica que el cliente puede aceptar datos de píxeles Y Cb Cr en formato bien empaquetado o desempaquetado. Si el Bit 1 se fija en cero, esto indica que el cliente puede aceptar datos de píxeles Y Cb Cr sólo en formato desempaquetado.

Un Campo de Capacidad Bayer, de 1 byte, especifica el número de bits de resolución, grupo de píxeles y orden de píxeles que pueden transferirse en formato Bayer. Si el cliente no puede utilizar el formato Bayer, entonces este valor se fija en cero. El campo Capacidad de Bayer se compone de los siguientes valores: los Bits 3 a 0 definen el número máximo de bits de intensidad que existen en cada píxel, los Bits 5 a 4 definen el patrón de grupo de píxeles que puede ser requerido, los Bits 8 a 6 definen un orden de píxeles que se requiere y los Bits 14 a 9 están reservados para uso futuro y se fijan en cero. El Bit 15, cuando está fijado en el valor uno, indica que el cliente puede aceptar datos de píxeles Bayer en formato bien empaquetado o desempaquetado. Si el Bit 15 está fijado en cero, esto indica que el cliente puede aceptar datos de Píxeles Bayer sólo en formato desempaquetado.

El campo 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 Registro

El Paquete de Acceso a Registro proporciona bien a un servidor, o bien a un cliente, un medio, mecanismo o procedimiento para acceder a registros de configuración y estado en el extremo opuesto del enlace MDDI. Es probable que estos registros sean únicos para cada controlador de visor o dispositivo. Estos registros ya existen en muchos visores que requieren establecer valores de configuraciones y modalidades de funcionamiento, y tienen otras configuraciones útiles y necesarias. El Paquete de Acceso a Registro permite al servidor o cliente MDDI tanto escribir en un registro como solicitar una lectura de un registro utilizando el enlace MDDI. Cuando el servidor o cliente solicita leer un registro, el extremo opuesto debería responder enviando los datos del registro en el mismo tipo de paquete, pero también indicando que estos son los datos leídos de un registro específico, con el uso del campo Información de Lectura/Escritura. El Paquete de Acceso a Registro puede utilizarse para leer o escribir múltiples registros, especificando un total de registros mayor que 1. Un cliente indica una capacidad de brindar soporte al Paquete de Acceso a Registro utilizando el bit 22 del campo de Capacidad de Característica de Cliente del Paquete de Capacidad de Cliente. El formato de una realización de un Paquete de Acceso a Registro se muestra, en general, en la Fig. 90. Como se ve en la Fig. 90, un Paquete de Acceso a Registro está estructurado para tener los campos Longitud de Paquete, Tipo de Paquete, Identificador de bCliente, Indicadores de Lectura/Escritura, Dirección de Registro, CRC de Parámetros, Lista de Datos de Registro y CRC de Datos de Registro. Un valor de Tipo de Paquete de 146 identifica un paquete como Paquete de Acceso a Registro. El campo Identificador de bCliente está reservado para uso futuro y generalmente se fija en cero por ahora.

El campo Indicadores de Lectura/Escritura, de 2 bytes, especifica el paquete específico como una escritura, o una lectura, o una respuesta a una lectura, y proporciona un total de los valores de los datos.

Los Bits 15 a 14 actúan como Indicadores de Lectura/Escritura. Si los Bits [15:14] son `00', entonces este paquete contiene datos para escribir en un registro direccionado por el campo Dirección de Registro. Los datos a escribir en los registros especificados están contenidos en el campo Lista de Datos de Registro. Si los Bits [15:14] son `10', entonces esto es una solicitud de datos provenientes de uno o más registros direccionados por el campo Dirección de Registro. Si los Bits [15:14] son `11', entonces ese paquete contiene datos que fueron solicitados en respuesta a un Paquete de Acceso de Registro con los bits 15:14 de los Indicadores de Lectura/Escritura fijados en `10'. El campo Dirección de Registro contiene la dirección del registro correspondiente al primer elemento de la Lista de Datos de Registro, y el campo Lista de Datos de Registro contendrá los datos que fueron leídos en 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 utiliza.

Los Bits 13:0 utilizan un entero sin signo de 14 bits para especificar el número de los elementos de 32 bits de los Datos de Registro a transferir en el campo 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 la Lista de Datos de Registro a escribir en los registros que comienzan en el registro especificado por el campo 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 registros de 32 bits que el dispositivo receptor envía a un dispositivo que solicita que se lean los registros. El campo Lista de Datos de Registro en este paquete no contiene ningún elemento y es de longitud cero. Si los bits 15:14 son iguales a `11', entonces los bits 13:0 especifican el número de elementos de datos de registros de 32 bits que han sido leídos de los registros que están contenidos en el campo de Lista de Datos de Registro. Los bits 15:14 no se fijan actualmente iguales a `01', que se considera un valor inválido, y se reservan en otro caso para designaciones o usos futuros.

El campo Dirección de Registro utiliza 4 bytes para indicar la dirección de registro que va a ser escrito o leído. Para direccionar registros cuya dirección es menor de 32 bits, los bits superiores se fijan en cero.

El campo CRC de Parámetros, de 2 bytes, contiene un CRC de todos los bytes, desde la Longitud de Paquete hasta la Dirección de Registro. Si este CRC no confirma la comprobación, entonces se descarta el paquete entero.

El campo Lista de Datos de Registro contiene una lista de valores de datos de registros de 4 bytes, a escribir en los registros del cliente, o valores que fueron leídos en los registros del dispositivo cliente.

El campo CRC de Datos de Registros, de 2 bytes, contiene un CRC sólo de la Lista de Datos de Registro. Si este CRC no confirma la comprobación, entonces los Datos de Registro aún pueden utilizarse, pero el contador de errores de CRC se incrementa.

D. CRC del Paquete

Los campos CRC aparecen al final de los paquetes y, a veces, después de ciertos parámetros más críticos, en paquetes que pueden tener un campo de datos significativamente grande y, así, una probabilidad aumentada de errores durante la transferencia. En paquetes que tienen dos campos CRC, el generador de CRC, cuando sólo se emplea uno, se reinicializa después del primer CRC, de forma que los cálculos de CRC a continuación de un largo campo de datos no sean afectados por los parámetros al comienzo del paquete.

En una realización a título de ejemplo, el polinomio utilizado para el cálculo del CRC se conoce como el CRC-16, o X16 + X15 + X2 + X0. Una implementación de muestra de un generador y comprobador 3600 de CRC, útil para implementar la invención, se muestra en la Fig. 36. En la Fig. 36, un registro 3602 de CRC se inicializa con un valor de 0x0001 justo antes de transferir el primer bit de un paquete que ingresa por la línea Tx_MDDI_Data_Before_CRC, luego los bytes del paquete se desplazan hacia el registro comenzando por el LSBmenos significativo en primer lugar. Observe que los números de bits del registro en esta figura corresponden al orden del polinomio que se está utilizando, y no a las posiciones de bit utilizadas por la MDDI. Es más eficiente desplazar el registro CRC en una única dirección, y esto da como resultado que el bit 15 del CRC aparezca en la posición de bit 0 del campo CRC de MDDI, y el bit 14 del registro de CRC en la posición de bit 1 del campo CRC de MDDI, y así sucesivamente hasta que se llega a la posición de bit 14 de la MDDI.

Como ejemplo, si el contenido del paquete para los Paquetes de Visualización de Solicitud y Estado es: 0x07, 0x46, 0x000400, 0x00 (o representado como una secuencia de bytes: 0x07, 0x00, 0x46, 0x00, 0x04, 0x00, 0x00), y se despacha utilizando las entradas de los multiplexadores 3604 y 3606, y el puerto NAND 3608, la salida del CRC resultante en la línea Tx_MDDI_Data_With_CRC es 0x0eal (o representado como una secuencia 0xal, 0x0e).

Cuando el generador y comprobador 3600 de CRC se configura como un comprobador de CRC, el CRC que se recibe en la línea Rx_MDDI_Data se suministra al multiplexador 3604 y al puerto NAND 3608, y se compara bit a bit con el valor hallado en el registro de CRC, utilizando el puerto NOR 3610, el puerto 3612 de O exclusivo (XOR) y el puerto AND 3614. Si hay algún error, según lo emitido por el puerto AND 3614, el CRC se incrementa una vez por cada paquete que contiene un error de CRC, conectando la salida del puerto 3614 con la entrada del registro 3602. Observe que el ejemplo de circuito mostrado en el diagrama de la Fig. 36 puede emitir más de una señal de error de CRC dentro de una ventana CHECK_CRC_NOW dada (véase la Fig. 37B). Por lo tanto, el contador de errores de CRC, por lo general, sólo cuenta la primera instancia de error de CRC dentro de cada intervalo donde CHECK_CRC_NOW está activo. Si se configura como un generador de CRC, el CRC es derivado por sincronización del registro CRC en el momento en que coincide con el fin del paquete.

La temporización para las señales de entrada y salida, y las señales de habilitación, se ilustran gráficamente en las Figs. 37A y 37B. La generación de un CRC y la transmisión de un paquete de datos se muestran en la Fig. 37A con el estado (0 ó 1) de las señales Gen_Reset, Check_CRC_Now, Generate_CRC_Now y Sending_MDDI_Data, junto con las señales Tx_MDDI_Data_Before_CRC y Tx_MDDI_Data_With_CRC. La recepción de un paquete de datos y la comprobación del valor del CRC se muestran en la Fig. 37B, con el estado de las señales Gen_Reset, Check_CRC_Now, Generate_CRC_Now y Sending_MDDI_Data, junto con las señales de error Rx_MDDI_Data y CRC.

E. Sobrecarga de Código de Error para CRC de Paquete

Toda vez que sólo se están transfiriendo paquetes de datos y CRC entre el servidor y el cliente, no hay ningún código de error asimilado. El único error es una pérdida de sincronización. En caso contrario, uno debe esperar para que el enlace agote el plazo de espera debido a una falta de un buen trayecto o tubo de transferencia de datos, y luego reiniciar el enlace y continuar. Desafortunadamente, esto consume tiempo y es algo ineficiente.

Para su empleo en una realización, ha sido desarrollada una nueva técnica en la cual la porción del CRC de los paquetes se utiliza para transferir información del código de error. Esto se muestra, en general, en la Fig. 65. Es decir, uno o más códigos de error son generados por los procesadores o dispositivos que gestionan la transferencia de datos, que indican errores o fallos predefinidos específicos que podrían ocurrir dentro del procesamiento o enlace de comunicación. Cuando se encuentra un error, se genera el código de error adecuado y se transfiere utilizando los bits para el CRC de un paquete. Es decir, el valor de CRC es sobrecargado, o sobrescrito, con el código de error deseado, lo que puede ser detectado en el extremo receptor por un monitor o comprobador de errores que monitoriza los valores del campo CRC. Para aquellos casos en los cuales el código de error coincide con el valor del CRC, por algún motivo, se transfiere el complemento del error para evitar confusión.

En una realización, a fin de proporcionar un sistema robusto de advertencia y detección de errores, el código de error puede transferirse varias veces, utilizando una serie de paquetes, generalmente todos, que se transfieren o envían después de que el error ha sido detectado. Esto ocurre hasta que el punto en el cual la condición que crea el error es eliminada del sistema, en cuyo punto los bits ordinarios del CRC son transferidos sin sobrecargarlos con otro valor.

Esta técnica de sobrecargar el valor del CRC proporciona una respuesta mucho más rápida a errores del sistema, utilizando a la vez una cantidad mínima de bits o campos extra.

Como se muestra en la Fig. 66, un mecanismo o aparato 6600 de sobreescritura se muestra utilizando un detector de errores, o medio 6602 de detección, que puede formar parte de otros circuitos previamente descritos o conocidos, y que detecta la presencia o existencia de errores dentro del enlace o proceso de comunicación. Un generador o medio 6604 de códigos de error, que puede formarse como parte de otros circuitos, o utilizar técnicas tales como búsqueda de tablas para almacenar mensajes de error preseleccionados, genera uno o más códigos de error para indicar errores o fallos específicos predefinidos cuya ocurrencia ha sido detectada. Se comprende inmediatamente que los dispositivos 6602 y 6604 pueden formarse como un único circuito o dispositivo, según se desee, o como parte de una secuencia programada de etapas para otros procesadores y elementos conocidos.

Se muestra un comparador de valores, o medio 6606 de comparación, para comprobar si el código, o códigos, de error seleccionado(s) es, o son, el mismo (los mismos) que el valor de CRC que se está transfiriendo. Si es ese el caso, entonces se utiliza un generador de complemento de código, o medio o dispositivo de generación, para proporcionar el complemento de los códigos de error, a fin de que no se malinterpreten como el patrón o valor original del CRC, y confundan o compliquen el esquema de detección. Un selector de código de error, o elemento o dispositivo 6610 de medios de selección, selecciona entonces el código o valor de error que se desea insertar o sobreescribir, o sus respectivos complementos, según convenga. Un sobreescritor de CRC de código de error, o mecanismo o medio 6612 de sobreescritura, es un dispositivo que recibe el flujo de datos, los paquetes y los códigos deseados a insertar, y sobreescribe los valores de CRC correspondientes o adecuados, a fin de transferir los códigos de error deseados a un dispositivo receptor.

Como se ha mencionado, el código de error puede transferirse varias veces, utilizando una serie de paquetes, de forma que el sobreescritor 6612 pueda utilizar elementos de almacenamiento de memoria a fin de mantener copias de los códigos durante el procesamiento, o recuperar estos códigos de elementos anteriores, u otras ubicaciones de almacenamiento conocidas, que puedan utilizarse para almacenar o retener sus valores según se necesite o se desee.

El procesamiento general que el mecanismo de sobreescritura de la Fig. 66 está implementando se muestra en detalle adicional en las Figs. 67A y 67B. En 67A uno o más errores se detectan en la etapa 6702 en los datos, o el proceso, de comunicación, y se selecciona un código de error en la etapa 6704 para indicar esta condición. Al mismo tiempo, o en un momento adecuado, el valor de CRC a reemplazar se comprueba en una etapa 6706, y se compara con el código de error deseado en la etapa 6708. El resultado de esta comparación, como se ha expuesto anteriormente, es una determinación en cuanto a si el código deseado, u otros valores representativos, será o no el mismo que el valor presente del CRC. Si es este el caso, entonces el procesamiento continúa en la etapa 6712, donde el complemento o, en algunos casos, otro valor representativo, según se desee, se selecciona como el código a insertar. Una vez que se ha determinado qué códigos o valores de error han de insertarse en las etapas 6710 y 6714, se selecciona ese código adecuado para su inserción. Estas etapas se ilustran como separadas con fines de claridad, pero generalmente representan una única elección basada en la salida de la decisión de la etapa 6708. Finalmente, en la etapa 6716 se sobreescriben los valores adecuados en la ubicación del CRC para su transferencia con los paquetes objeto del proceso.

En el lado de recepción del paquete, como se muestra en la Fig. 67B, los valores de CRC del paquete están siendo monitorizados en una etapa 6722. Generalmente, los valores de CRC están siendo monitorizados por uno o más procesos dentro del sistema, a fin de determinar si ha ocurrido un error en la transferencia de datos, y si ha de solicitarse o no una retransmisión del paquete, o paquetes, o inhibir las operaciones ulteriores, etc., algo de lo cual se ha expuesto anteriormente. Como parte de dicha monitorización, la información también puede utilizarse para comparar valores con códigos de error conocidos o preseleccionados, o valores representativos, y detectar la presencia de errores. Alternativamente, puede implementarse un proceso y un monitor separados de detección de errores. Si un código parece estar presente, se extrae, o se registra de otra forma, en la etapa 6724, para su ulterior procesamiento. Puede tomarse una determinación en la etapa 6726 en cuanto a si este es o no el código real o un complemento, en cuyo caso se utiliza una etapa adicional 6728 para traducir el valor al valor del código deseado. En cualquier caso, el código extraído resultante, el complemento, u otros valores recuperados se utilizan entonces para detectar qué error ha ocurrido a partir del código transmitido en la etapa 6730.

V. Reinicio de Enlace desde la Hibernación

Cuando el servidor reinicia el enlace directo desde un estado de hibernación, alimenta la señal MDDI_Data a un estado de uno lógico durante alrededor de 150 ciclos de MDDI_Stb y luego alimenta la señal MDDI_Data0 a un estado de cero lógico durante 50 ciclos de MDDI_Stb, y luego inicia el tráfico del enlace directo enviando un paquete de cabecera de subtrama. Esto, por lo general, permite que las contenciones de bus se resuelvan antes de que el paquete de cabecera de subtrama sea enviado, proporcionando bastante tiempo de asentamiento entre las señales. Cuando el servidor alimenta la señal MDDI_Data0 a un estado de uno lógico, también activa la señal MDDI_Stb para proporcionar un reloj para la lógica de reanimación en el cliente.

Cuando el cliente, aquí un visor, necesita servicio de datos, o comunicación, desde el servidor, alimenta la línea MDDI_Data0 a un estado de uno lógico durante alrededor de 70 a 1000 \museg, mientras MDDI_Stb está inactiva, más 70 ciclos de MDDI_Stb después de que MDDI_Stb deviene activa, aunque pueden utilizarse otros periodos según se desee, y luego desactiva el controlador poniéndolo en un estado de alta impedancia. Si MDDI_Stb está activa durante la hibernación, aunque es improbable, entonces el cliente sólo podría alimentar MDDI_Data0 a un estado de uno lógico durante 70 ciclos de MDDI_Stb. Esta acción causa que el servidor inicie, o reinicie, el tráfico de datos por el enlace directo (208) y sondee el cliente en cuanto a su estado. El servidor debe detectar la presencia del pulso requerido dentro de 50 ciclos de MDDI_Stb, y luego comenzar la secuencia de arranque de alimentación MDDI_Data0 al uno lógico durante 150 ciclos de MDDI_Stb y al cero lógico durante 50 ciclos de MDDI_Stb. El visor no debería enviar un pulso de solicitud de servicio si detecta MDDI_Data0 en el estado de uno lógico por más de 50 \museg. La naturaleza de la selección de los tiempos y tolerancias de los intervalos temporales relacionados con el procesamiento de la hibernación y la secuencia de arranque se exponen adicionalmente más adelante. (Véase 68A-C más adelante).

Un ejemplo de las etapas de procesamiento para un típico suceso 3800 de solicitud de servicio de cliente, sin ninguna contención, se ilustra en la Fig. 38, donde los sucesos se etiquetan, por comodidad en la ilustración, utilizando las letras A, B, C, D, E, F y G. El proceso comienza en el punto A, cuando el servidor envía un Paquete de Cierre de Enlace al dispositivo cliente, para informarle de que el enlace efectuará una transición a un estado de hibernación de baja energía. En una etapa siguiente, el servidor ingresa al estado de hibernación de baja energía desactivando el controlador de MDDI_Data0 y llevando el controlador de MDDI_Stb a un cero lógico, como se muestra en el punto B. La señal MDDI_Data0 se alimenta a un cero lógico mediante una red de sesgo de alta impedancia. Después de un cierto periodo, el cliente envía un pulso de solicitud de servicio al servidor alimentando la línea MDDI_Data0 a un nivel de uno lógico, como se ve en el punto C. El servidor reafirma aún el nivel de cero lógico utilizando la red de sesgo de alta impedancia, pero el controlador en el cliente fuerza la línea a un nivel de uno lógico. Dentro de 50 \museg, el servidor reconoce el pulso de solicitud de servicio, y reafirma un nivel de uno lógico en MDDI_Data0, habilitando su controlador, como se ve en el punto D. El cliente cesa entonces de intentar reafirmar el pulso de solicitud de servicio, y el cliente pone su controlador en un estado de alta impedancia, como se ve en el punto E. El servidor alimenta MDDI_Data0 a un nivel de cero lógico durante 50 \museg, como se ve en el punto F, y también comienza a generar MDDI_Stb de manera coherente con el nivel de cero lógico en NMDI_Data0. Después de reafirmar MDDI_Data0 a un nivel de cero lógico y de alimentar MDDI_Stb durante 50 \museg, el servidor comienza a transmitir datos por el enlace directo, enviando un Paquete de Cabecera de Subtrama, como se muestra en el punto G.

Un ejemplo similar se ilustra en la Fig. 39, donde una solicitud de servicio se reafirma después de que ha empezado la secuencia de reinicio de enlace, y los sucesos se etiquetan nuevamente utilizando las letras A, B, C, D, E, F y G. Esto representa un escenario del peor caso, donde un pulso o señal de solicitud desde el cliente llega casi a corromper el Paquete de Cabecera de Subtrama. El proceso comienza en el punto A, cuando el servidor envía nuevamente un Paquete de Cierre de Enlace al dispositivo cliente, para informarle de que el enlace efectuará la transición a un estado de hibernación de baja energía. En una etapa siguiente, el servidor ingresa al estado de hibernación de baja energía desactivando el controlador de MDDI_Data0 y llevando el controlador de MDDI_Stb a un nivel de cero lógico, como se muestra en el punto B. Como antes, la línea MDDI_Data0 es alimentada a un nivel de cero lógico por una red de sesgo de alta impedancia. Después de un periodo de tiempo, el servidor comienza la secuencia de reinicio de enlace alimentando MDDI_Data0 a un nivel de uno lógico durante 150 \museg, como se ve en el punto C. Antes de que pasen 50 \museg después de que comience la secuencia de reinicio de enlace, el visor también reafirma MDDI_Data0 durante 70 \museg, como se ve en el punto D. Esto ocurre porque el visor tiene necesidad de solicitar servicio del servidor y no reconoce que el servidor ya ha empezado la secuencia de reinicio de enlace. El cliente cesa entonces de intentar reafirmar el pulso de solicitud de servicio, y el cliente pone su controlador en un estado de alta impedancia, como se ve en el punto E. El servidor continúa alimentando MDDI_Data0 a un nivel de uno lógico. El servidor alimenta MDDI_Data0 a un nivel de cero lógico durante 50 \museg, como se muestra en el punto F, y también comienza a generar MDDI_Stb de manera coherente con el nivel de cero lógico en MDDI_Data0. Después de reafirmar MDDI_Data0 en un nivel de cero lógico, y de alimentar MDDI_Stb durante 50 \museg, el servidor comienza a transmitir datos por el enlace directo, enviando un Paquete de Cabecera de Subtrama, como se muestra en el punto G.

De la exposición anterior, se ve que la solución anterior implicaba hacer que el servidor atravesara dos estados como parte de una secuencia de reanimación. Para el primer estado, el servidor alimenta la señal MDDI_Data0 al estado alto durante 150 \mus, y luego alimenta la señal MDDI_Data0 al estado bajo durante 50 \mus, activando a la vez la línea MDDI_Stb, y luego comienza a transmitir paquetes MDDI. Este proceso funciona bien para adelantar el estado de la técnica en términos de las velocidades de datos alcanzables utilizando el aparato y procedimientos de MDDI. Sin embargo, como se ha afirmado anteriormente, más velocidad, en términos de tiempo de respuesta reducido ante ciertas condiciones, o poder seleccionar más rápidamente la siguiente etapa o proceso, y la capacidad de simplificar el procesamiento o los elementos, son cosas que siempre tienen demanda.

Los solicitantes han descubierto un nuevo enfoque inventivo para el procesamiento y temporización de la reanimación, en el cual el servidor utiliza una temporización basada en el ciclo de reloj para la alternación de señales. En esta configuración, el servidor comienza a alternar MDDI_Stb entre 0 y 10 \museg después de que el servidor alimenta la señal MDDI_Data0 al estado alto al comienzo de la secuencia de reanimación, y no espera hasta que la señal es alimentada al estado bajo. Durante una secuencia de reanimación, el servidor alterna MDDI_Stb, como si la señal MDDI_Data0 estuviera siempre en un nivel de cero lógico. Esto elimina efectivamente el concepto de tiempo en el lado del cliente, y el servidor cambia, desde los anteriores periodos de 150 \mus y 50 \mus para los dos primeros estados, a 150 ciclos de reloj y 50 ciclos de reloj, para estos periodos.

El servidor se hace ahora responsable de alimentar la línea de datos al estado alto y, dentro de 10 ciclos de reloj, de comenzar a transmitir una señal de sondeo, como si la línea de datos fuera cero. Después de que el servidor ha alimentado la línea de datos al estado alto durante 150 ciclos de reloj, el servidor alimenta la línea de datos al estado bajo durante 50 ciclos de reloj, mientras continúa transmitiendo la señal de sondeo. Después de que ha completado ambos procesos, el servidor puede comenzar a transmitir el primer paquete de cabecera de subtrama.

En el lado del cliente, la implementación del cliente puede utilizar ahora el reloj generado para calcular el número de ciclos de reloj en que la línea de datos está primero en estado alto, y luego bajo. El número de ciclos de reloj que deben tener lugar en la línea de datos alimentada al estado alto es 150, y en la línea de datos alimentada al estado bajo, 50. Esto significa que, para una secuencia de reanimación adecuada, el cliente debería poder contar al menos 150 ciclos de reloj continuos de la línea de datos en estado alto, seguidos por al menos 50 ciclos de reloj continuos de la línea de datos en estado bajo. Una vez que se satisfacen estas dos condiciones, el cliente puede comenzar a buscar la palabra única de la primera subtrama. Una ruptura en este patrón se utiliza como la base para devolver los contadores a un estado inicial, en el cual el cliente busca nuevamente los primeros 150 ciclos de reloj continuos de la línea de datos en estado alto.

Una implementación en el cliente de la invención para la reanimación desde la hibernación, basada en el servidor, es muy similar al caso de reanimación inicial, excepto en que la velocidad del reloj no se fuerza para que comience en 1 Mbps, como se ha expuesto anteriormente. En cambio, la velocidad del reloj puede fijarse para reanudarse en cualquier velocidad anterior que estuviera activa cuando el enlace de comunicación entró en hibernación. Si el servidor comienza la transmisión de una señal de sondeo según lo anteriormente descrito, el cliente debería poder contar nuevamente al menos 150 ciclos de reloj continuos de la línea de datos en estado alto, seguidos por al menos 50 ciclos de reloj continuos de la línea de datos en estado bajo. Una vez que estas dos condiciones han sido satisfechas, el cliente puede comenzar la búsqueda de la palabra única.

Una implementación en el cliente de la invención para la reanimación desde la hibernación, basada en el cliente, es similar a la reanimación basada en el servidor, excepto en que comienza haciendo que el cliente alimente la línea de datos. El cliente puede alimentar de manera asíncrona la línea de datos sin un reloj, para reanimar al dispositivo servidor. Una vez que el servidor reconoce que la línea de datos está siendo alimentada al estado alto por el cliente, puede comenzar su secuencia de reanimación. El cliente puede contar el número de ciclos de reloj generados por el inicio del servidor, o durante su proceso de reanimación. Una vez que el cliente cuenta 70 ciclos de reloj continuos de la línea de datos en el estado alto, puede dejar de alimentar la línea de datos en el estado alto. En este punto, el servidor ya debería también estar alimentando la línea de datos al estado alto. El cliente puede contar entonces otros 80 ciclos de reloj continuos de la línea de datos en estado alto, para llegar a 150 ciclos de reloj de la línea en estado alto, y luego puede esperar 50 ciclos de reloj de la línea de datos en estado bajo. Una vez que estas tres condiciones se han satisfecho, el cliente puede comenzar a buscar la palabra única.

Una ventaja de esta nueva implementación del procesamiento de reanimación es que elimina la necesidad de un dispositivo de medición de tiempo. Ya sea un oscilador, o circuito de descarga de condensador, u otros tales dispositivos conocidos, el cliente no necesita más de tales dispositivos externos para determinar las condiciones de arranque. Esto ahorra dinero y área de circuitos al implementar controladores, contadores, etc., en una placa de dispositivo cliente. Si bien esto puede no ser tan ventajoso para el cliente, para el servidor esta técnica también debería simplificarlo potencialmente, en términos de la lógica de muy alta densidad (VHDL) utilizada para los circuitos centrales. El consumo de energía al utilizar las líneas de datos y sondeo como la fuente de notificación y medición de la reanimación también será menor, ya que no se necesitará que ningún circuito externo esté funcionando para los elementos centrales esperando una reanimación basada en el servidor.

El número de ciclos o periodos de reloj utilizados son ejemplares, y pueden utilizarse otros periodos, como será evidente para alguien experto en la técnica.

Una ventaja de esta nueva implementación del procesamiento de reanimación es que elimina la necesidad de un dispositivo de medición de tiempo. Ya sea un oscilador, o circuito de descarga de condensador, u otros tales dispositivos conocidos, el cliente no necesita más de tales dispositivos externos para determinar las condiciones de arranque. Esto ahorra dinero y área de circuitos al implementar controladores, contadores, etc., en una placa de dispositivo cliente. Si bien esto puede no ser tan ventajoso para el cliente, para el servidor esta técnica también debería simplificarlo potencialmente, en términos de la lógica de muy alta densidad (VHDL) utilizada para los circuitos centrales. El consumo de energía al utilizar las líneas de datos y sondeo como la fuente de notificación y medición de la reanimación también será menor, ya que no se necesitará que ningún circuito externo esté funcionando para los elementos centrales esperando una reanimación basada en el servidor.

Para clarificar e ilustrar el funcionamiento de esta nueva técnica, la temporización de MDDI_Data0, MDDI_Stb y varias operaciones relacionadas con los ciclos de reloj se muestran en las Figs. 68A, 68B y 68C.

Un ejemplo de las etapas de procesamiento para una típica Reanimación iniciada por Servidor, sin ninguna contención, se ilustra en la Fig. 68A, donde los sucesos se etiquetan nuevamente, para comodidad en la ilustración, utilizando las letras A, B, C, D, E, F y G. El proceso comienza en el punto A, cuando el servidor envía un Paquete de Cierre de Enlace al dispositivo cliente, para informarle de que el enlace efectuará una transición al estado de hibernación de baja energía. En una siguiente etapa, el punto B, el servidor alterna MDDI_Stb durante unos 64 ciclos (o como se desee para el diseño del sistema) para permitir que el procesamiento por parte del cliente se complete antes de detener la alternación de MDDI_Stb, lo que detiene el reloj recuperado en el dispositivo cliente. El servidor también lleva inicialmente MDDI_Data0 al nivel de cero lógico, y luego desactiva la salida de MDDI_Data0 en la gama de entre 16 y 48 ciclos (incluyendo por lo general los retardos de propagación de la desactivación de la salida) después del CRC. Puede ser deseable poner receptores de alta velocidad para MDDI_Data0 y MDDI_Stb en el cliente en un estado de baja energía, algún tiempo después de los 48 ciclos después del CRC, y antes de la siguiente etapa (C).

El servidor ingresa al estado de hibernación de baja energía en el punto o etapa C, desactivando los controladores de MDDI_Data0 y MDDI_Stb, y poniendo un controlador de servidor en un estado de hibernación de baja energía. Uno también puede poner el controlador de MDDI_Stb en un nivel de cero lógico (utilizando una red de sesgo de alta-impedancia) o continuar alternando durante la hibernación, según se desee. El cliente también está en un estado de hibernación de bajo nivel de energía.

Después de algún tiempo, el servidor comienza la secuencia de reinicio del enlace en el punto D, habilitando la salida de controlador de MDDI_Data0 y MDDI_Stb. El servidor alimenta MDDI_Data0 a un nivel de uno lógico y MDDI_Stb a un nivel de cero lógico, durante tanto tiempo como les lleve a los controladores habilitar totalmente sus respectivas salidas. El servidor, típicamente, espera alrededor de 200 nanosegundos después de que estas salidas alcanzan los niveles lógicos deseados, antes de alimentar los pulsos en MMDI_Stb. Esto concede al cliente tiempo para prepararse para recibir.

Con los controladores del servidor activados y MDDI_Data0 alimentado a un nivel de uno lógico, el servidor comienza a alternar MDDI_Stb durante 150 ciclos de MDDI_Stb, como se ve en el punto E. El servidor alimenta MDDI_Data0 a un nivel de cero lógico durante 50 ciclos, como se muestra en el punto F, y el cliente comienza a buscar el Paquete de Cabecera de Subtrama después de que MDDI_Data0 esté en un nivel de cero lógico durante 40 ciclos de MDDI_Stb. El servidor comienza a transmitir datos por el enlace directo enviando un Paquete de Cabecera de Subtrama, como se muestra en el punto G.

Un ejemplo de las etapas de procesamiento para una típica Reanimación iniciada por Cliente, sin ninguna contención, se ilustra en la Fig. 68B, donde los sucesos se etiquetan nuevamente, por conveniencia en la ilustración, utilizando las letras A, B, C, D, E, F, G, H e I. Como antes, el proceso comienza en el punto A, cuando el servidor envía un Paquete de Cierre de Enlace para informar al cliente de que el enlace efectuará la transición al estado de baja energía.

En el punto B, el servidor alterna MDDI_Stb durante unos 64 ciclos (o como se desee para el diseño del sistema) para permitir que se complete el procesamiento por parte del cliente antes de detener la alternación de MDDI_Stb, lo cual detiene el reloj en el dispositivo cliente. El servidor también lleva inicialmente MDDI_Data0 a un nivel de cero lógico y luego desactiva la salida de MDDI_Data0 en la gama de entre 16 a 48 ciclos (incluyendo, por lo general, los retardos de propagación de desactivación de salida) después del CRC. Puede ser deseable poner receptores de alta velocidad para MDDI_Data0 y MDDI_Stb en el cliente en un estado de baja energía, algo después de los 48 ciclos después del CRC y antes de la siguiente etapa (C).

El servidor ingresa al estado de hibernación de baja energía en el punto o etapa C, desactivando los controladores de MDDI_Data0 y MDDI_Stb, y poniendo un controlador de servidor en un estado de hibernación de baja energía. Uno también puede llevar el controlador de MDDI_Stb a un nivel de cero lógico (utilizando una red de sesgo de alta impedancia), o continuar alternando durante la hibernación, según se desee. El cliente también está en un estado de hibernación de baja energía.

Después de algún tiempo, el cliente comienza la secuencia de reinicio de enlace en el punto D, habilitando el receptor MDDI_Stb, y habilitando también un desplazamiento en el receptor de MDDI_Stb para garantizar que el estado de la versión recibida de MDDI_Stb es un nivel de cero lógico en el cliente antes de que el servidor habilite su controlador de MDDI_Stb. Puede ser deseable que el cliente habilite el desplazamiento levemente por delante de la activación del receptor, para garantizar la recepción de una señal diferencial válida e inhibir las señales erróneas, según se desee. El cliente activa el controlador de MDDI_Data0 mientras alimenta la línea MDDI_Data0 a un nivel de uno lógico.

Dentro de alrededor de 1 mseg, punto E, el servidor reconoce el pulso de solicitud de servicio del cliente, y el servidor comienza la secuencia de reinicio de enlace habilitando las salidas de controlador de MDDI_Data0 y MDDI_Stb. El servidor alimenta MDDI_Data0 a un nivel de uno lógico y MDDI_Stb a un nivel de cero lógico, por tanto tiempo como le lleve a los controladores activar sus respectivas salidas. El servidor, típicamente, espera alrededor de 200 nanosegundos después de que estas salidas alcancen los niveles lógicos deseados, antes de alimenta los pulsos en MDDI_Stb. Esto concede al cliente tiempo para prepararse para recibir.

Con los controladores del servidor activados y MDDI_Data0 alimentada a un nivel de uno lógico, el servidor comienza a emitir pulsos en MDDI_Stb durante 150 ciclos de MDDI_Stb, como se ve en el punto F. Cuando el cliente reconoce el primer pulso en MDDI_Stb, desactiva el desplazamiento en su receptor MDDI_Stb. El cliente continúa alimentando MDDI_Data0 a un nivel de uno lógico durante 70 ciclos de MMDI_Stb, y desactiva su controlador de MDDI_Data0 en el punto G.

Como se ve en los puntos G y H, el servidor alimenta MDDI_Data0 a un nivel de cero lógico durante 50 ciclos, y el cliente comienza a buscar el Paquete de Cabecera de Subtrama después de que MDDI_Data0 esté en el nivel de cero lógico durante 40 ciclos de MDDI_Stb. El servidor comienza a transmitir datos por el enlace directo enviando un Paquete de Cabecera de Subtrama, como se muestra en el punto I.

Un ejemplo de las etapas de procesamiento para una típica Reanimación iniciada por el Servidor, con contención de parte del cliente, es decir, el cliente también quiere reanimar el enlace, se ilustra en la Fig. 68C. Los sucesos se etiquetan nuevamente, por conveniencia en la ilustración, utilizando las letras A, B, C, D, E, F, G, H e I. Como antes, el proceso comienza en el punto A, cuando el servidor envía un Paquete de Cierre de Enlace, para informar al cliente de que el enlace efectuará una transición al estado de baja energía, continúa en el punto B, donde MDDI_Stb es alternado durante unos 64 ciclos (o como se desee para el diseño del sistema) para permitir que se complete el procesamiento por parte del cliente, y luego en el punto C, donde el servidor ingresa al estado de hibernación de baja energía, desactivando los controladores de MDDI_Data0 y MDDI_Stb, y poniendo un controlador del servidor en un estado de hibernación de baja energía. Después de un tiempo, el servidor comienza la secuencia de reinicio de enlace en el punto D, activando la salida de los controladores de MDDI_Data0 y MDDI_Stb, y comienza a alternar MDDI_Stb durante 150 ciclos de MDDI_Stb, como se ve en el punto E.

Hasta 70 ciclos de MDDI_Stb después del punto E, aquí el punto F, el cliente no ha reconocido aún que el servidor está alimentando MDDI_Data0 a un nivel de uno lógico, por lo que el cliente también alimenta MDDI_Data0 a un nivel de uno lógico. Esto ocurre aquí porque el cliente tiene el deseo de solicitar servicio, pero no reconoce que el servidor con el que está tratando de comunicarse ya ha comenzado la secuencia de reinicio de enlace. En el punto G, el cliente cesa de alimentar MDDI_Data0, y pone su controlador en un estado de alta impedancia, desactivando su salida. El servidor continúa alimentando MDDI_Data0 a un nivel de uno lógico durante 80 ciclos adicionales.

El servidor alimenta MDDI_Data0 a un nivel de cero lógico durante 50 ciclos, como se muestra en el punto H, y el cliente comienza a buscar el Paquete de Cabecera de Subtrama después de que MDDI_Data0 esté en un nivel de cero lógico durante 40 ciclos de MDDI_Stb. El servidor comienza a transmitir datos por el enlace directo, enviando un Paquete de Cabecera de Subtrama, como se muestra en el punto I.

VI. Especificaciones de Interfaz Eléctrica

En los ejemplos de realizaciones, los Datos en un formato de No Retorno a Cero (NRZ) se codifican utilizando una señal de sondeo de datos, o formato DATA_STB, que permite que la información del reloj se integre en las señales de datos y sondeo. El reloj puede recuperarse sin circuitos complejos de bucle de cierre de fase. Los datos se transportan por un enlace diferencial bidireccional, implementado generalmente utilizando un cable de línea, aunque pueden utilizarse otros conductores, cables impresos o elementos de transferencia, como se ha establecido anteriormente. La señal de sondeo (STB) se transporta por un enlace unidireccional que es alimentado sólo por el servidor. La señal de sondeo alterna el valor (0 ó 1) cada vez que hay un estado de espalda a espalda, 0 ó 1, que se mantiene igual en la línea o señal de Datos.

Un ejemplo de cómo una secuencia de datos tal como los bits "1110001011" puede transmitirse utilizando la codificación DATA-STB se muestra en forma gráfica en la Fig. 40. En la Fig. 40, una señal 4002 de DATA se muestra sobre la línea superior de un gráfico de temporización de señal y una señal 4004 STB se muestra en una segunda línea, cada una alineada temporalmente como convenga (punto de partida común). Según pasa el tiempo, cuando está ocurriendo un cambio de estado en la línea 4002 DATA (señal), entonces la línea 4004 STB (señal) mantiene un estado previo; así, el primer estado `1' de la señal DATA se correlaciona con el primer estado `0' para la señal STB, su valor de partida. Sin embargo, si, o cuando, el estado, o nivel, de la señal DATA no cambia, entonces la señal STB alterna al estado opuesto, o `1' en el presente ejemplo, como es el caso en la Fig. 40, donde el DATA está proporcionando otro valor `1'. Es decir, hay una y sólo una transición por ciclo de bit entre DATA y STB. Por lo tanto, la señal STB efectúa nuevamente una transición, esta vez a `0', mientras la señal DATA se mantiene en `1', y mantiene este nivel o valor mientras la señal DATA cambia al nivel `0'. Cuando la señal DATA se mantiene en `1', la señal STB alterna al estado opuesto, o `1' en el presente ejemplo, y así sucesivamente, según la señal DATA cambia o mantiene sus niveles o valores.

Al recibir estas señales, se realiza una operación de O exclusivo (XOR) sobre las señales de DATA y STB, para producir una señal 4006 de reloj, que se muestra en el extremo inferior del gráfico de temporización, para la comparación relativa con las señales deseadas de datos y sondeo. Un ejemplo de circuitos útiles para generar las salidas o señales DATA y STB a partir de datos ingresados en el servidor, y recuperar luego los datos de las señales DATA y STB en el cliente, se muestra en la Fig. 41.

En la Fig. 41, una porción 4100 de transmisión se utiliza para generar y transmitir las señales DATA y STB originales por un trayecto 4102 de señal intermediaria, mientras que una porción 4120 de recepción se utiliza para recibir las señales y recuperar los datos. Como se muestra en la Fig. 41, a fin de transferir datos desde un servidor a un cliente, la señal DATA se suministra a dos elementos 4104 y 4106 de circuito flip-flop de tipo D, junto con una señal de reloj para disparar los circuitos. Las dos salidas de circuito flip-flop (Q) se parten luego en un par diferencial de señales MDDI_Data0+, MDDI_Data0- y MDDI_Stb+, MDDI_Stb-, respectivamente, utilizando dos controladores 4108 y 4110 de línea diferenciales (modalidad de voltaje). Un puerto, circuito o elemento lógico 4112 de NOR exclusivo (XNOR) de tres entradas está conectado para recibir el DATA y las salidas de ambos flip-flops, y genera una salida que proporciona la entrada de datos para el segundo flip-flop, que, a su vez, genera las señales MDDI_Stb+, MDDI_Stb-. Por conveniencia, el puerto XNOR tiene la burbuja de inversión puesta para indicar que está efectivamente invirtiendo la salida Q del flip-flop que genera la Sonda.

En la porción 4120 de recepción de la Fig. 41, las señales MDDI_Data0+, MDDI_Data0- y MDDI_Stb+, MDDI_
Stb- son recibidas por cada uno de los dos receptores 4122 y4124 de línea diferenciales, que generan salidas individuales a partir de las señales diferenciales. Las salidas de los amplificadores se suministran luego a cada una de las entradas de un puerto, circuito o elemento lógico 4126 de O exclusivo (XOR) de dos entradas, que produce la señal de reloj. La señal de reloj se utiliza para disparar cada uno de los dos circuitos 4128 y 4130 flip-flop de tipo D, que reciben una versión retardada de la señal DATA, a través del elemento 4132 de retardo, uno de los cuales (4128) genera valores de datos `0' y el otro (4130) valores de datos `1'. El reloj tiene asimismo una salida independiente de la lógica XOR. Como la información de reloj está distribuida entre las líneas DATA y STB, ninguna señal efectúa transiciones entre estados más rápido que la mitad de la velocidad del reloj. Como el reloj está reproducido utilizando el procesamiento por O-exclusivo de las señales DATA y STB, el sistema tolera efectivamente el doble de la magnitud de sesgo entre los datos de entrada y el reloj, en comparación con la situación cuando una señal de reloj se envía directamente por una única línea de datos dedicada.

Los pares de Datos MDDI, y las señales MDDI_Stb+ y MDDI_Stb- funcionan en una modalidad diferencial para maximizar la inmunidad ante los efectos negativos del ruido. Cada porción del trayecto de señal diferencial está terminada en origen con una mitad de la impedancia característica del cable o conductor que se esté utilizando para transferir señales. Los pares de Datos de MDDI son terminados en origen en ambos extremos servidor y cliente. Como sólo uno de estos dos controladores está activo en un momento dado, existe continuamente una terminación en el origen para el enlace de transferencia. Las señales MDDI_Stb+ y MDDI_Stb- sólo son alimentadas por el servidor.

Una configuración a título de ejemplo de elementos útiles para lograr los controladores, receptores y terminaciones para transferir señales como parte de la interfaz MDD inventiva se muestra en la Fig. 42, mientras que las correspondientes especificaciones eléctricas de corriente DC de MDDI_Data y MDDI_Stb se muestran en la Tabla VII. Esta interfaz a título de ejemplo utiliza sensores de bajo voltaje, aquí 220 mV, con menos de 1 voltio de oscilaciones de potencia y bajo drenaje de energía.

TABLA VII

11

Los parámetros eléctricos y características de los controladores de línea diferencial y los receptores de línea se describen en la Tabla VIII. Funcionalmente, el controlador 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 desde la entrada hasta las salidas está bien adaptado a la línea diferencial, que se alimenta diferencialmente. En la mayoría de las implementaciones, la oscilación de voltaje en las salidas es menor que la oscilación en la entrada, para minimizar el consumo de energía y las emisiones electromagnéticas. La Tabla VIII presenta una oscilación mínima de voltaje de alrededor de 0,5V. Sin embargo, pueden emplearse otros valores, como será conocido por aquellos expertos en la técnica, y los inventores contemplan un valor más pequeño en algunas realizaciones, según las restricciones de diseño.

Los receptores de línea diferencial tienen la misma característica que un comparador de voltaje de alta velocidad. En la Fig. 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: (V_{entrada+})-(V_{entrada-}) es mayor que cero. Otra forma de describir esto es un amplificador diferencial con una ganancia muy grande (virtualmente infinita), con la salida recortada a niveles de voltaje de 0 y 1 lógicos.

El sesgo de retardo entre distintos pares debería minimizarse para operar el sistema de transmisión diferencial a la más alta velocidad potencial.

En la Fig. 42, un controlador 4202 de servidor y un controlador 4204 de cliente o visor se muestran transfiriendo paquetes por el enlace 4206 de comunicación. El controlador del servidor emplea una serie de tres controladores 4210, 4212 y 4214 para recibir las señales DATA y STB del servidor a transferir, así como para recibir las señales de Datos del cliente a transferir. El controlador responsable del pasaje del DATA del servidor emplea una entrada de señal de habilitación para permitir la activación del enlace de comunicación, generalmente sólo cuando se desea la transferencia desde el servidor al cliente. Como la señal STB se forma como parte de la transferencia de datos, no se emplea ninguna señal de habilitación adicional para ese controlador (4212). Las salidas de cada uno de los controladores DATA y STB se conectan, respectivamente, con las impedancias o resistores 4216a, 4216b, 4216c y 4216d de terminación.

Los resistores 4216a y 4216b de terminación también actuarán como impedancias sobre la entrada del receptor 4420 del lado del cliente, para el procesamiento de la señal STB, mientras que los resistores 4216e y 4216f de terminación adicionales se colocan en serie con los resistores 4216c y 4216d, respectivamente, sobre la entrada del receptor 4222 de procesamiento de datos del cliente. Un sexto controlador 4226 en el controlador del cliente se utiliza para preparar las señales de datos que se están transfiriendo desde el cliente al servidor, donde el controlador 4214, a través de los resistores 4216c y 4216d de terminación, en la entrada, procesa los datos para la transferencia al servidor para su procesamiento.

Dos resistores adicionales 4218a y 4218b se colocan entre los resistores de terminación y la descarga a tierra, y una fuente 4220 de voltaje, respectivamente, como parte del control de hibernación expuesto en otro sitio. La fuente de voltaje se utiliza para alimentar las líneas de transferencia a los niveles altos o bajos anteriormente expuestos, para gestionar el flujo de datos.

Los anteriores controladores e impedancias pueden formarse como componentes discretos o como parte de un módulo de circuitos, o como un circuito integrado específico de la aplicación (ASIC) que actúa como una solución codificadora o descodificadora más efectiva en términos de coste.

Puede verse fácilmente que la energía se transfiere al dispositivo cliente, o visor, desde el dispositivo servidor, utilizando las señales etiquetadas HOST_Pwr y HOST_Gnd, por un par de conductores. La porción HOST_Gnd de la señal actúa como la descarga a tierra de referencia y el trayecto o señal de retorno de la fuente de alimentación para el dispositivo de visualización. La señal HOST_Pwr actúa como la fuente de alimentación del dispositivo de visualización, que está alimentada por el dispositivo servidor En una configuración a título de ejemplo, para aplicaciones de baja potencia, se permite al dispositivo de visualización consumir hasta 500 mA. La señal HOST_Pwr puede suministrarse desde fuentes de alimentación portátiles, tales como, pero sin limitarse a, una batería de tipo ion de litio, o un paquete de baterías residentes en el dispositivo servidor, y puede variar entre 3,2 y 4,3 voltios con respecto a HOST_Gnd.

VII. Características de Temporización A. Visión General

Las etapas y niveles de señal empleadas por un cliente para asegurar el servicio desde el servidor, y por el servidor para proporcionar tal servicio, se ilustran en la Fig. 43. En la Fig. 43, la primera parte de las señales ilustradas muestra un Paquete de Cierre de Enlace transfiriéndose desde el servidor, y la línea de datos se alimenta luego a un estado de cero lógico, utilizando el circuito de sesgo de alta impedancia. Ningún dato está siendo transmitido por el visor del cliente, o el servidor, que tiene su controlador desactivado. Una serie de pulsos de sondeo para la línea de señal MDDI_Stb puede verse en el extremo inferior, ya que MDDI_Stb está activa durante el Paquete de Cierre de Enlace. Una vez que este paquete acaba y el nivel lógico cambia a cero según el servidor alimenta el circuito de sesgo y la lógica a cero, la línea de señal MDDI_Stb cambia asimismo a un nivel de cero lógico. Esto representa la terminación de la última transferencia de señal, o servicio, desde el servidor, y podría haber ocurrido en cualquier momento del pasado, y se incluye para mostrar el cese anterior del servicio, y el estado de las señales antes del comienzo del servicio. Si se desea, tal señal puede enviarse sólo para reiniciar el enlace de comunicación al estado adecuado, sin que una comunicación anterior "conocida" haya sido encarada por este dispositivo servidor.

Como se muestra en la Fig. 43, la salida de señal desde el cliente se fija inicialmente en un nivel lógico de cero. En otras palabras, la salida del cliente está en alta impedancia, y el controlador está desactivado. Cuando se está solicitando servicio, el cliente activa su controlador y envía una solicitud de servicio al servidor, en un periodo de tiempo, denominado tservicio, durante el cual la línea es alimentada a un nivel de uno lógico. Pasa luego, o puede ser necesaria antes de que el servidor detecte la solicitud, una cierta cantidad de tiempo, denominada tdetectar-servidor, después de lo cual el servidor responde con una secuencia de arranque de enlace, alimentando la señal a un nivel de uno lógico. En este punto, el cliente desactiva la solicitud e inhabilita el controlador de solicitud de servicio de forma que la línea de salida desde el cliente vaya de nuevo a un nivel de cero lógico. Durante este tiempo, la señal MDDI_Stb está en un nivel de cero lógico.

El servidor alimenta la salida de datos del servidor al nivel `1' durante un periodo denominado treinicio-alto, después de lo cual el servidor alimenta el nivel lógico a cero y activa MDDI_Stb durante un periodo denominado treinicio-bajo, después de lo cual comienza el primer tráfico directo con un Paquete de Cabecera de Subtrama, y los paquetes de tráfico directo se transfieren luego. La señal MDDI_Stb está activa durante el periodo treinicio-bajo y el subsiguiente Paquete de Cabecera de Subtrama.

La Tabla VIII muestra tiempos representativos para la duración de los diversos periodos expuestos anteriormente, y la relación con las velocidades de datos a título de ejemplo, mínimas y máximas, donde:

t_{bit} = \frac{1}{Velocidad \ \_Datos \ \_Enlace}

TABLA VIII

13

Aquellos versados en la técnica comprenderán inmediatamente que las funciones de los elementos individuales ilustrados en las Figs. 41 y 42 son bien conocidas, y que la función de los elementos en la Fig. 42 está confirmada por el diagrama de temporización en la Fig. 43. Los detalles acerca de las terminaciones en serie y los resistores de hibernación que se muestran en la Fig. 42 se omitieron de la Fig. 41 porque esa información es innecesaria para una descripción de cómo realizar la codificación Datos-Sondeo y recuperar el reloj de ella.

B. Enlace Directo de Temporización Datos-Sondeo

Las características de conmutación para la transferencia de datos por el enlace directo desde la salida del controlador del servidor se muestran en la Tabla IX. La Tabla IX presenta un formato tabular del mínimo y máximo deseados, con respecto a los tiempos típicos para que ocurran ciertas transiciones de señal. Por ejemplo, la duración típica del tiempo para que ocurra una transición desde el principio hasta el final de un valor de datos (salida de un `0' o `1'), una transición de Data0 a Data0, denominada ttdd-(salida-servidor), es ttbit, mientras que el tiempo mínimo es de alrededor de ttbit-0,5 nseg, y el máximo es de alrededor de ttbit-0,5 nseg. El espaciado relativo entre las transiciones en Data0, otras líneas de datos (DataX) y otras líneas de sondeo (Stb), se ilustra en la Fig. 44, donde se muestran las transiciones de Data0 a Sondeo, Sondeo a Sondeo, Sondeo a Data0, Data0 a no Data0, no Data0 a no Data0, no Data0 a Sondeo, y Sondeo a no Data0, que se denominan ttds-(salida-servidor), ttss-(salida-servidor), ttsd-(salida-servidor), ttddx-(salida-servidor), ttdxdx-(salida-servidor), ttdxs-(salida-servidor) y ttsdx-(salida-servidor), respectivamente.

TABLA IX

14

Los típicos requisitos de temporización de MDDI para la entrada del receptor cliente para las mismas señales que transfieren datos por el enlace directo se muestran en la Tabla X. Como se están exponiendo las mismas señales, pero retardadas en el tiempo, no se necesita ninguna nueva figura para ilustrar las características de señal o el significado de las respectivas etiquetas, como entenderán aquellos versados en la técnica.

TABLA X

15

Las Figs. 46 y 46 ilustran la presencia de un retardo en la respuesta, que puede ocurrir cuando el servidor desactiva o activa el controlador del servidor, respectivamente. En el caso de un servidor que remite ciertos paquetes, tales como el Paquete de Encapsulación de Enlace Inverso o el Paquete de Medición de Retardo de Ida y Vuelta, el servidor desactiva el controlador de línea después de que se han remitido los paquetes deseados, tales como los paquetes de CRC de Parámetros, Alineación de Sondeo y Todos Ceros ilustrados en la Fig. 45 como transferidos. Sin embargo, según se muestra en la Fig. 45, el estado de la línea no necesariamente conmuta entre `0' a un valor deseado más alto instantáneamente, aunque esto es potencialmente alcanzable con ciertos elementos de control o circuitos presentes, pero lleva un periodo de tiempo, denominado el periodo de Retardo de Desactivación de Controlador, para responder. Si bien podría ocurrir de manera virtualmente instantánea, dado que este periodo de tiempo tiene 0 nanosegundos (nseg) de longitud, podría extenderse más inmediatamente sobre algún periodo más largo, siendo 10 nseg una longitud máxima deseado del periodo, que ocurre durante los periodos de paquete de Tiempo de Guardia 1 o
Giro 1.

Mirando a la Fig. 46, se ve el cambio de nivel de señal sufrido cuando el Controlador del servidor está habilitado para transferir un paquete tal como el Paquete de Encapsulación de Enlace Inverso, o el Paquete de Medición de Retardo de Ida y Vuelta. Aquí, después de los periodos de paquetes Tiempo de Guardia 2 o Giro 2, el controlador del servidor está activado y comienza a alimentar a un nivel, aquí `0', cuyo valor es aproximado o alcanzado durante un periodo de tiempo denominado el periodo de Retardo de Activación de Controlador de Servidor, lo que ocurre durante el periodo de Reactivación del Controlador, antes de que se envíe el primer paquete.

Un proceso similar ocurre para los controladores y transferencias de señales para el dispositivo cliente, aquí un visor. Las directrices generales para la longitud de estos periodos, y sus respectivas relaciones, se muestran en la Tabla XI, a continuación.

\vskip1.000000\baselineskip

TABLA XI

16

C. Temporización Datos-Sondeo-Enlace Inverso

Las características de conmutación y las relaciones de temporización para las señales de datos y sondeo, utilizadas para transferir datos por el enlace inverso desde la salida del controlador del cliente, se muestran en las Figs. 47 y 48. Los tiempos típicos para ciertas transiciones de señal se exponen más adelante. La Fig. 47 ilustra la relación en la entrada del receptor del servidor, entre la temporización de los datos transferidos y los bordes de cabecera y de cola de los pulsos de sondeo. Es decir, lo que se denomina tiempo de configuración para el borde creciente o inicial de las señales de sondeo, tsu-sr, y el tiempo de configuración para el borde final o decreciente de las señales de sondeo, tsu-sf. Una duración típica del tiempo para estos periodos de configuración está en el orden de un mínimo de 8 nano-
segundos.

La Fig. 48 ilustra las características de conmutación y el correspondiente retardo de salida del cliente desarrollado por la temporización de datos inversos. En la Fig. 48, se puede ver la relación entre la temporización de los datos transferidos y los bordes inicial y final de los pulsos de sondeo que generan el retardo inducido. Es decir, lo que se denomina retardo de propagación entre el borde creciente o inicial de las señales de sondeo y los datos (válidos), tpd-sr, y el retardo de propagación entre los datos y el borde final o decreciente de las señales de sondeo, tpd-sf. Una duración máxima típica del tiempo para estos periodos de retardo de propagación está en el orden de 8 nano-
segundos.

VIII. Implementación del Control de Enlace (Funcionamiento del Controlador de Enlace) A. Procesador de Paquetes de la Máquina de Estados

Los paquetes transferidos por un enlace MDDI se despachan muy rápidamente, típicamente, a una velocidad del orden de 300 Mbps o más, tal como 400 Mbps, aunque las velocidades menores son ciertamente asimilables, según se desee. Este tipo de velocidad de bus o de enlace de transferencia es demasiado grande como para que los microprocesadores, o similares, de propósito general comercialmente disponibles (económicos) actualmente puedan controlarla. Por lo tanto, una implementación práctica para lograr este tipo de transferencia de señales es utilizar una máquina de estados programable para analizar el flujo de paquetes de entrada, a fin de producir paquetes que sean transferidos o redirigidos al subsistema audio-visual adecuado, al cual están destinados. Tales dispositivos son bien conocidos y utilizan circuitos generalmente dedicados a un número limitado de operaciones, funciones o estados, para lograr un funcionamiento a una velocidad deseada alta, o muy alta.

Los controladores, procesadores o elementos de procesamiento de propósito general pueden utilizarse para actuar más adecuadamente sobre, o manipular, alguna información tal como los paquetes de control o estado, que tienen menores exigencias de velocidad. Cuando esos paquetes (de control, de estado, u otros paquetes predefinidos) se reciben, la máquina de estados debería pasarlos a través de un almacén temporal de datos o elemento similar de procesamiento al procesador de propósito general, de forma que se pueda actuar sobre los paquetes para proporcionar un resultado (efecto) deseado, mientras que los paquetes visuales y de audio se transfieren a su destino adecuado para actuar sobre ellos. Si se fabrican microprocesadores futuros, u otros controladores, procesadores, o elementos de procesamiento de propósito general, para lograr capacidades de procesamiento de mayor velocidad de datos, entonces los estados, o máquinas de estados, expuestos más adelante también podrían implementarse utilizando el control por software de tales dispositivos, típicamente, como programas almacenados en un elemento o medio de
almacenamiento.

La función del procesador de propósito general también puede realizarse en algunas realizaciones aprovechando la potencia de procesamiento de, o los ciclos sobrantes disponibles para, los microprocesadores (CPU) en aplicaciones informáticas, o los controladores, procesadores, procesadores de señales digitales (DSP), circuitos especializados o los ASIC hallados en dispositivos inalámbricos, de manera muy similar a como algunos módems o procesadores gráficos utilizan la potencia de procesamiento de las CPU halladas en los ordenadores para realizar algunas funciones y reducir la complejidad y los costes del hardware. Sin embargo, esta compartición o utilización de ciclos puede tener un impacto negativo sobre la velocidad de procesamiento, la temporización, o el funcionamiento global de tales elementos, por lo que, en muchas aplicaciones se prefieren circuitos o elementos dedicados para este procesamiento
general.

A fin de que los datos de imágenes sean visualizados en un visor (microvisor), o para recibir con fiabilidad todos los paquetes enviados por el dispositivo servidor, el procesamiento de señales del visor se sincroniza con la temporización del canal del enlace inverso. Es decir, las señales que llegan al visor y los circuitos del visor necesitan estar esencialmente sincronizados en el tiempo, para que tenga lugar el procesamiento adecuado de las señales. Un diagrama de alto nivel de los estados alcanzados por las etapas de procesamiento de señales, o un procedimiento por el cual tal sincronización puede implementarse, se presenta en la ilustración de la Fig. 49. En la Fig. 49, se muestran los posibles "estados" de sincronización del enlace directo para una máquina 4900 de estados, categorizados como un ESTADO 4904 DE TRAMAS ASÍNCRONAS, dos ESTADOS 4902 y 4906 DE ADQUISICIÓN DE SINCRONÍA, y tres ESTADOS 4908, 4910 y 4912 EN SINCRONÍA.

Como se muestra en la etapa de inicio, o estado 4902, el visor, o cliente, tal como un dispositivo de presentación, comienza en un estado preseleccionado de "no sincronía", y busca una palabra única en el primer paquete de cabecera de subtrama que se detecte. Debe observarse que este estado de no sincronía representa la configuración de comunicación mínima, o configuración de "retroceso", en el cual se selecciona una interfaz de Tipo 1. Cuando se halla la palabra única durante la búsqueda, el visor guarda el campo de longitud de subtrama. No hay ninguna comprobación de los bits del CRC para el procesamiento de esta primera trama, o hasta que se logra la sincronización. Si la longitud de esta subtrama es cero, entonces el procesamiento del estado sincrónico continúa en consecuencia hasta un estado 4904, etiquetado aquí como el estado de "tramas asíncronas", lo que indica que la sincronización no se ha logrado aún. Esta etapa en el procesamiento se etiqueta como que ha encontrado la cond 3, o condición 3, en la Fig. 49. Por lo demás, si la longitud de trama es mayor que cero, entonces el procesamiento de estado síncrono continúa hasta un estado 4906 donde el estado de interfaz se fija como "hallada una trama síncrona". Esta etapa del procesamiento se etiqueta como encontrando cond 5, o condición 5, en la Fig. 49. Además, si la máquina de estados ve un paquete de cabecera de trama y una buena determinación del CRC para una longitud de trama mayor que cero, el procesamiento continúa hasta el estado "hallada una trama síncrona". Esto se etiqueta como que satisface la cond 6, o condición 6, en la Fig. 49.

En cada situación en la cual el sistema está en un estado distinto a "no sincronizado", cuando la palabra única se detecta y se determina un buen resultado del CRC para el paquete de cabecera de subtrama, y la longitud de subtrama es mayor que cero, entonces el estado de la interfaz cambia al estado 4908 "en sincronía". Esta etapa en el procesamiento se etiqueta como que ha encontrado la cond 1, o condición 1, en la Fig. 49. Por otra parte, si bien la palabra única o bien el CRC en el Paquete de Cabecera de subtrama no son correctos, entonces el procesamiento del estado de sincronía continúa o vuelve al estado 4902 de interfaz del estado "SIN TRAMA SÍNCRONA". Esta porción del procesamiento se etiqueta como que ha encontrado la cond 2, o condición 2, en el diagrama de estados de la Fig. 49.

\newpage

B. Tiempo de Adquisición de Sincronía

La interfaz puede configurarse para asimilar un cierto número de "errores de sincronía" antes de decidir que se ha perdido la sincronización y volver al estado "SIN TRAMA SÍNCRONA". En la Fig. 49, una vez que la máquina de estados ha llegado al "ESTADO EN SINCRONÍA" y no se hallan errores, está encontrando continuamente un resultado de cond 1, y permanece en el estado "EN SINCRONÍA". Sin embargo, una vez que se detecte el resultado de cond 2, el procesamiento cambia el estado a un estado 4910 "un error de sincronía". En este punto, si el procesamiento tiene como resultado detectar otro resultado de cond 1, entonces la máquina de estados vuelve al estado "en sincronía"; en caso contrario, encuentra otro resultado de cond 2, y se desplaza al estado 4912 "DOS ERRORES DE SINCRONÍA". Nuevamente, si ocurre una cond 1, el procesamiento devuelve la máquina de estados al estado "EN SINCRONÍA". En caso contrario, se encuentra otra cond 2 y la máquina de estados vuelve al estado "sin sincronía". También es comprensible que, si la interfaz encontrara un "paquete de cierre de enlace", esto causaría que el enlace terminara las transferencias de datos y volviera al estado "trama no síncrona", ya que no hay nada con qué sincronizarse, lo que se denomina como satisfacer la cond 4, o condición 4, en el diagrama de estados de la Fig. 49.

Se entiende que es posible que haya una "falsa copia" repetida de la palabra única que pueda aparecer en alguna ubicación fija dentro de la subtrama. En esa situación, es sumamente improbable que la máquina de estados se sincronice con la subtrama, porque el CRC en el Paquete de Cabecera de subtrama también debe ser válido cuando se procese, a fin de que el procesamiento de la interfaz MDD continúe al estado "EN SINCRONÍA".

La longitud de subtrama en el Paquete de Cabecera de subtrama puede fijarse en cero para indicar que el servidor transmitirá sólo una subtrama antes de que el enlace se cierre, y la interfaz MDD sea puesta o configurada en un estado de hibernación ociosa. En este caso, el visor debe recibir paquetes inmediatamente por el enlace directo después de detectar el Paquete de Cabecera de subtrama, porque sólo se envía una única subtrama antes de que el enlace efectúe la transición al estado ocioso. En operaciones normales o típicas, la longitud de subtrama no es cero, y el visor sólo procesa paquetes del enlace directo, mientras que la interfaz está en aquellos estados mostrados colectivamente como los estados "EN SINCRONÍA" en la Fig. 49.

El tiempo requerido para que un visor se sincronice con la señal del enlace directo es variable, según el tamaño de la subtrama y la velocidad de datos del enlace directo. La probabilidad de detectar una "falsa copia" de la palabra única como parte de los datos aleatorios, o más aleatorios, en el enlace directo es mayor cuando el tamaño de la subtrama es más grande. Al mismo tiempo, la capacidad de recuperarse de una falsa detección es inferior, y el tiempo que lleva hacerlo es más largo, cuando una velocidad de datos de enlace directo es más lenta.

C. Inicialización

Como se ha afirmado anteriormente, en el momento de "arranque", el servidor configura el enlace directo para funcionar en la velocidad mínima requerida, o deseada, de 1 Mbps, o por debajo de ella, y configura la longitud de subtrama y la velocidad de tramas de medios adecuadamente para una aplicación dada. Es decir, tanto los enlaces directos como los inversos comienzan la operación utilizando la interfaz de Tipo 1. Estos parámetros, generalmente, sólo van a ser utilizados temporalmente mientras que el servidor determina la capacidad o configuración deseada para el visor del cliente (u otro tipo de dispositivo cliente). El servidor envía o transfiere un Paquete de Cabecera de subtrama por el enlace directo, seguido por un Paquete de Encapsulación de Enlace Inverso, que tiene el bit `0' de los Indicadores de Solicitud fijado en un valor de uno (1), a fin de solicitar que el visor o cliente responda con un Paquete de Capacidad de Visor. Una vez que el visor adquiere la sincronización por (o con) el enlace directo, envía un Paquete de Capacidad de Visor y un Paquete de Visualización de Solicitud y Estado por el enlace o canal inverso.

El servidor examina el contenido del Paquete de Capacidad de Visor a fin de determinar cómo reconfigurar el enlace para un nivel de prestaciones óptimo o deseado. El servidor examina los campos Versión de Protocolo y Versión Mínima de Protocolo para confirmar que el servidor y el visor utilizan versiones del protocolo que sean compatibles entre sí. Las versiones del protocolo se mantienen, generalmente, como los dos primeros parámetros del Paquete de Capacidad de Visor, de forma que pueda determinarse la compatibilidad incluso cuando otros elementos del protocolo podrían no ser compatibles, o no interpretarse completamente como compatibles.

D. Procesamiento del CRC

Para todos los tipos de paquetes, la máquina de estados del procesador de paquetes garantiza que el verificador de CRC está adecuada o debidamente controlado. También incrementa un contador de errores de CRC cuando una comparación del CRC da como resultado uno o más errores detectados, y reinicia el contador del CRC al comienzo del procesamiento de cada subtrama.

E. Pérdida Alternativa de la Comprobación de Sincronización

Si bien la serie anterior de etapas o estados funciona para producir mayores velocidades de datos, o velocidad de caudal, los Solicitantes han descubierto que una disposición o cambio alternativo en las condiciones que el cliente utiliza para declarar que hay una pérdida de sincronización con el servidor puede utilizarse efectivamente para lograr velocidades o caudales de datos aún mayores. La nueva realización inventiva tiene la misma estructura básica, pero con las condiciones para cambiar de estados modificados. Además, se implementa un nuevo contador para ayudar a hacer comprobaciones para la sincronización de subtrama. Estas etapas y condiciones se presentan con relación a la Fig. 63, que ilustra una serie de estados y condiciones útiles para establecer las operaciones del procedimiento o máquina de estados. Sólo se muestran las porciones de "ADQUISICIÓN DE ESTADOS SÍNCRONOS" y "ESTADOS EN SINCRONÍA", para mayor claridad. Además, como los estados resultantes son esencialmente los mismos, como lo es la misma máquina de estados, utilizan la misma numeración. Sin embargo, las condiciones para cambiar de estados (y el funcionamiento de la máquina de estados) varían en alguna medida, por lo que todo está renumerado para mayor claridad entre las dos figuras (1, 2, 3, 4, 5 y 6, ante 61, 62, 63, 64 y 65), como una comodidad para identificar diferencias. Como el estado TRAMA ASÍNCRONA no se considera en esta exposición, un estado (4904) y una condición (6) ya no se utilizan en la figura.

En la Fig. 63, el sistema o cliente (para visualización o presentación) comienza con la máquina 5000 de estados en el estado preseleccionado 4902 "sin sincronía", como en la Fig. 49. El primer cambio de estado, para cambiar estados desde la condición 4902 de no sincronía, está en la condición 64, que es el descubrimiento del patrón de sincronía. Suponiendo que el CRC de la cabecera de subtrama también es correcto en este paquete (satisface la condición 61), el estado de la máquina de estados del procesador de paquetes puede cambiar al estado 4908 en sincronía. Un error de sincronización, la condición 62, causará que la máquina de estados se desplace al estado 4910, y una segunda ocurrencia, al estado 4912. Sin embargo, se ha descubierto que cualquier fallo de CRC de un paquete MDDI causará que la máquina de estados salga del estado 4908 en sincronía, hacia el estado 4910 de un error de sincronización. Otro fallo de CRC de cualquier paquete MDDI causará un movimiento al estado 4912 de dos fallos de sincronía. Un paquete descodificado con un valor de CRC correcto causará que la máquina de estados vuelva al estado 4908 en sincronía.

Lo que se ha cambiado es utilizar el valor o determinación del CRC para `todo' paquete. Es decir, hacer que la máquina de estados mire el valor del CRC para todo paquete a fin de determinar una pérdida de sincronización, en lugar de observar sólo los paquetes de cabecera de subtrama. En esta configuración o proceso, una pérdida de sincronización no se determina utilizando la palabra única y sólo los valores de CRC de la cabecera de subtrama.

Esta nueva implementación de interfaz permite que el enlace de la interfaz MDD reconozca fallos de sincronización mucho más rápidamente y, por lo tanto, que también se recupere de ellos más rápidamente.

Para hacer este sistema más robusto, el cliente también debería añadir o utilizar un contador de subtramas. El cliente comprueba luego la presencia de la palabra única en el momento en que se espera que llegue u ocurra en una señal. Si la palabra única no ocurre en el momento correcto, el cliente puede reconocer que ha ocurrido un fallo de sincronización mucho más rápidamente que si tuviese que esperar varios (tres aquí) tiempos o periodos de paquete que fueran mayores que la longitud de una subtrama. Si la comprobación de la palabra única indica que no está presente (en otras palabras, que la temporización es incorrecta), entonces el cliente puede declarar inmediatamente una pérdida de sincronización de enlace y desplazarse al estado de no sincronía. El proceso de comprobar la presencia de la palabra única adecuada añade una condición 65 (cond 65) a la máquina de estados, diciendo que la palabra única es incorrecta. Si se espera recibir un paquete de subtrama en el cliente y no coincide, el cliente puede ir inmediatamente al estado 4902 de no sincronía, ahorrando tiempo adicional de espera de múltiples errores de sincronía (condición 62) normalmente encontrados al atravesar los estados 4910 y 4912.

Este cambio utiliza un contador, o función de cuenta, adicional en el núcleo del cliente, para contar la longitud de subtrama. En una realización, se utiliza una función de cuenta descendente, y la transferencia de cualquier paquete que estuviese procesándose actualmente se interrumpe para comprobar la palabra única de subtrama si el contador ha expirado. Alternativamente, el contador puede contar ascendentemente, comparándose el total con un valor deseado máximo o específico, en cuyo momento se comprueba el paquete actual. Este proceso protege al cliente de descodificar paquetes que sean recibidos incorrectamente en el cliente, con longitudes de paquete extraordinariamente largas. Si el contador de longitud de subtrama necesitara interrumpir a algún otro paquete que estuviera siendo descodificado, puede determinarse una pérdida de sincronización, dado que ningún paquete debería cruzar un límite de
subtrama.

\newpage

IX. Procesamiento de Paquetes

Para cada tipo de paquete expuesto anteriormente, que recibe la máquina de estados, acomete una etapa, o serie de etapas, de procesamiento específica(s), para implementar la operación de la interfaz. Los paquetes del enlace directo se procesan generalmente según el procesamiento a título de ejemplo enumerado en la Tabla XII a continuación.

\vskip1.000000\baselineskip

TABLA XII

17

18

19

X. Reducción de la Velocidad de Datos del Enlace Inverso

Ha sido observado por los inventores que ciertos parámetros utilizados para el controlador de enlace del servidor pueden ajustarse o configurarse de cierta manera, a fin de lograr una velocidad máxima, o más optimizada (en escala) de los datos del enlace inverso, lo que es muy deseable. Por ejemplo, durante el tiempo empleado para transferir el campo Paquetes de Datos Inversos del Paquete de Encapsulación de Enlace Inverso, el par de señales MDDI_Stb alterna sus valores para crear un reloj de datos periódicos a la mitad de la velocidad de datos del enlace directo. Esto ocurre porque el controlador de enlace del servidor genera la señal MDDI_Stb que corresponde a la señal MDDI_Data0 como si estuviera enviando todos ceros. La señal MDDI_Stb es transferida desde el servidor a un cliente, donde es utilizada para generar una señal de reloj para transferir datos de enlace inverso desde el visor, con lo cual se envían de vuelta datos inversos al servidor. Una ilustración de magnitudes típicas de retardo halladas para la transferencia de señal y el procesamiento en los trayectos directo e inverso en un sistema que emplea la MDDI se muestra en la Fig. 50. En la Fig. 50, se muestra una serie de valores de retardo de 1,5 nseg, 8,0 nseg, 2,5 nseg, 2,0 nseg, 1,0 nseg, 1,5 nseg, 8,0 nseg y 2,5 nseg, cerca de porciones de procesamiento para las etapas de generación de Stb+/-, la transferencia a visor por cable, el receptor del visor, la generación del reloj, la sincronización de señal, la generación de Data0+/-, la transferencia al servidor por cable y del receptor del servidor, respectivamente.

Según la velocidad de datos de enlace directo y los retardos de procesamiento de señal encontrados, puede requerir más tiempo que un ciclo en la señal MDDI_Stb para que se complete este efecto de "ida y vuelta", o conjunto de sucesos, lo que da como resultado el consumo de magnitudes indeseables de tiempo o ciclos. Para eludir este problema, el Divisor de Velocidad Inversa hace posible que un lapso de bit en el enlace inverso abarque múltiples ciclos de la señal MDDI_Stb. Esto significa que la velocidad de datos del enlace inverso es menor que la velocidad del enlace directo.

Debería observarse que la longitud efectiva de los retardos de señal a través de la interfaz puede diferir, según cada sistema o hardware servidor-cliente específico utilizado. Aunque no se requiere, puede hacerse, generalmente, que cada sistema funcione mejor utilizando el Paquete de Medición de Retardo de Ida y Vuelta para medir el retardo efectivo en un sistema, de forma que el Divisor de Velocidad Inversa pueda fijarse en un valor óptimo.

Un retardo de ida y vuelta se mide haciendo que el servidor envíe un Paquete de Medición de Retardo de Ida y Vuelta al visor. El visor responde a este paquete enviando una secuencia de unos de vuelta al servidor dentro de, o durante, una ventana de medición preseleccionada en ese paquete, llamada el campo Periodo de Medición. La temporización detallada de esta medición fue descrita anteriormente. El retardo de ida y vuelta se utiliza para determinar la velocidad a la cual los datos del enlace inverso pueden muestrearse con seguridad.

La medición del retardo de ida y vuelta consiste en determinar, detectar o contar el número de intervalos de reloj de datos del enlace directo que ocurren entre el comienzo del campo Periodo de Medición y el comienzo del periodo en que se recibe de vuelta la secuencia de respuesta 0xff, 0xff, 0x00 en el servidor, proveniente del cliente. Observe que es posible que la respuesta del cliente pudiera ser recibida en una pequeña fracción de un periodo de reloj del enlace directo, antes de que el contador de la medición fuera a incrementarse. Si se utiliza este valor no modificado para calcular el Divisor de Velocidad Inversa, podría causar errores de bit en el enlace inverso, debido al muestreo de datos no fiable. Un ejemplo de esta situación se ilustra en la Fig. 51, donde las señales que representan MDDI_Data en el servidor, MDDI_Stb en el servidor, el reloj de datos del enlace directo dentro del servidor, y un Contador de Retardo, se ilustran de forma gráfica. En la Fig. 51, la secuencia de respuesta fue recibida desde el visor una fracción de un periodo de reloj de enlace directo antes de que el Contador de Retardo fuera a incrementarse desde 6 a 7. Si se supone que el retardo es 6, entonces el servidor muestreará los datos inversos justo después de una transición de bit, o posiblemente en la mitad de una transición de bit. Esto podría resultar en un muestreo erróneo en el servidor. Por esta razón, el retardo medido, típicamente, debería incrementarse en uno antes de que se emplee para calcular el Divisor de Velocidad Inversa.

El Divisor de Velocidad Inversa es el número de ciclos de MDDI_Stb que el servidor debería esperar antes de muestrear los datos del enlace inverso. Como MDDI_Stb cicla a una velocidad que es la mitad de la velocidad del enlace directo, la medición corregida del retardo de ida y vuelta debe ser dividida entre 2 y luego redondeada al siguiente entero. Expresado como una fórmula, esta relación es:

2000

Para el ejemplo dado, esto se convierte en:

2001

Si la medición del retardo de ida y vuelta utilizado en este ejemplo fuera 7 en lugar de 6, entonces el Divisor de Velocidad Inversa también sería igual a 4.

Los datos del enlace inverso son muestreados por el servidor en el borde creciente del Reloj del Enlace Inverso. Hay un contador, o un circuito o dispositivo similar conocido, presente tanto en el servidor como en el cliente (visor) para generar el Reloj de Enlace Inverso. Los contadores se inicializan de forma que el primer borde creciente del Reloj de Enlace Inverso ocurra al comienzo del primer bit en el campo Paquetes de Enlace Inverso del paquete de Encapsulación de Enlace Inverso. Esto se ilustra, para el ejemplo dado más adelante, en la Fig. 52. Los contadores se incrementan en cada borde creciente de la señal MDDI_Stb, y el número de totales habidos hasta que vuelven al cero está fijado por el parámetro Divisor de Velocidad Inversa en el Paquete de Encapsulación de Enlace Inverso. Como la señal MDDI_Stb alterna sus valores a la mitad de la velocidad del enlace directo, entonces la velocidad del enlace inverso es la mitad de la velocidad del enlace directo, dividida entre el Divisor de Velocidad Inversa. Por ejemplo, si la velocidad del enlace directo es de 200 Mbps y el Divisor de Velocidad Inversa es 4, entonces la velocidad de datos del enlace inverso se expresa como:

20

Un ejemplo que muestra la temporización de las líneas de señal MDDI_Data0 y MDDI_Stb en un Paquete de Encapsulación de Enlace Inverso se muestra en la Fig. 52, donde los parámetros del paquete utilizados para la ilustración tienen los valores:

2002

El primer paquete del enlace inverso devuelto desde el visor es el Paquete de Solicitud y Estado de Visor, con una Longitud de Paquete de 7 y un tipo de paquete de 70. Este paquete comienza con los valores de byte 0x07, 0x00, 0x46, ... y así sucesivamente. Sin embargo, sólo el primer byte (0x07) es visible en la Fig. 52. Este primer paquete del enlace inverso está desplazado temporalmente, en cerca de un periodo de reloj de enlace inverso, en la figura, para ilustrar un retardo efectivo del enlace inverso. Una onda ideal, con retardo cero de ida y vuelta de servidor a visor, se muestra como un rastro de línea de puntos.

Se transfiere el byte más significativo del campo CRC de Parámetros, precedido por el tipo de paquete, luego el campo con todos ceros. La sonda desde el servidor está conmutando desde uno a cero, y de vuelta a uno, según los datos provenientes del servidor cambian de nivel, formando pulsos más amplios. Según los datos llegan a cero, la sonda conmuta a una velocidad mayor, y sólo el cambio en los datos en la línea de datos causa un cambio cerca del final del campo de alineación. La sonda conmuta a la velocidad más alta por el resto de la figura, debido a los niveles fijos 0 ó 1 de la señal de datos durante periodos extendidos, y a las transiciones que caen sobre el patrón de pulsos (borde).

El reloj del enlace inverso para el servidor está en cero hasta el final del periodo de Giro 1, cuando el reloj se inicia para asimilar los paquetes del enlace inverso. Las flechas en la porción inferior de la figura indican cuando los datos son muestreados, como será evidente a partir del resto de la revelación. El primer byte del campo del paquete que se está transfiriendo (aquí 11000000) se muestra comenzando después del Giro 1, y el nivel de línea se ha estabilizado desde que el controlador del servidor ha sido desactivado. El retardo en el pasaje del primer bit, como se ve para el bit tres, puede verse en las líneas de puntos para la señal Data.

En la Fig. 53, se pueden observar valores típicos del Divisor de Velocidad Inversa, basados en la velocidad de datos del enlace directo. El Divisor de Velocidad Inversa efectivo se determina como resultado de una medición del enlace de ida y vuelta, para garantizar el funcionamiento debido del enlace inverso. Una primera región 5302 corresponde a un área de funcionamiento seguro, una segunda región 5304 corresponde a un área de rendimiento marginal, mientras que una tercera región 5306 indica configuraciones que es improbable que funcionen debidamente.

La medición del retardo de ida y vuelta y la configuración del Divisor de Velocidad Inversa son las mismas mientras se funciona con cualquiera de las configuraciones de Tipo de Interfaz, tanto en el enlace directo como el inverso, porque se expresan y se operan sobre ellas en términos de unidades de periodos efectivos de reloj, en lugar de números de bits transmitidos o recibidos.

XI. Tiempos de Giro y de Guardia

Como se ha expuesto anteriormente, el campo Giro 1 en el Paquete de Encapsulación de Enlace Inverso y el campo Tiempo de Guardia 1 en el Paquete de Medición de Retardo de Ida y Vuelta designan valores para los periodos de tiempo que permiten que los controladores de interfaz del servidor sean desactivados antes de que los controladores de interfaz de visor sean activados. Los campos Giro 2 y Tiempo de Guardia 2 proporcionan valores de tiempos que permiten que los controladores de visor sean desactivados antes de que los controladores del servidor sean activados. Los campos Tiempo de Guardia 1 y Tiempo de Guardia 2, generalmente, se rellenan con valores prefijados o preseleccionados para longitudes que no se pretende ajustar. Según el hardware de interfaz utilizado, estos valores pueden desarrollarse utilizando datos empíricos, y ajustarse en algunos casos para mejorar el funcionamiento.

Varios factores contribuyen a una determinación de la longitud de Giro 1, y son éstos la velocidad de datos del enlace directo y el máximo tiempo de desactivación de los controladores de MDDI_Data en el servidor. El tiempo máximo de desactivación del controlador del servidor se especifica en la Tabla XI, donde se muestra que los servidores se toman alrededor de 10 nseg, como máximo, para desactivarse, y alrededor de 2 nseg para activarse. El número mínimo de ciclos de reloj del enlace directo requerido para que el controlador del servidor se desactive se expresa según la relación:

21

\vskip1.000000\baselineskip

La gama de valores admitidos de Giro 1 se expresa según la relación:

22

donde el Factor de Tipo de Interfaz es 1 para el Tipo 1, 2 para el Tipo 2, 4 para el Tipo 3 y 8 para el Tipo-IV.

\vskip1.000000\baselineskip

Combinando las dos ecuaciones anteriores, puede verse que el término Factor de Tipo de Interfaz se elimina, y que Giro 1 se define como:

23

\vskip1.000000\baselineskip

Por ejemplo, un enlace directo de Tipo 3 de 1500 Mbps utilizaría un retardo de Giro 1 de:

24

\vskip1.000000\baselineskip

Según aumenta el retardo de ida y vuelta, el margen de temporización mejora desde el instante en que el servidor es desactivado hasta el momento en que se activa el visor.

Los factores que determinan la extensión del tiempo generalmente utilizado para el Giro 2 son la velocidad de datos del enlace directo, el máximo tiempo de desactivación de los controladores de MDDI_Data en el visor, y el retardo de ida y vuelta del enlace de comunicación. El cálculo del tiempo requerido para desactivar el controlador del visor es esencialmente el mismo que para el controlador del servidor expuesto anteriormente, y se define según la relación:

25

\vskip1.000000\baselineskip

y la gama de valores admitidos para Giro 2 se expresa como:

26

\vskip1.000000\baselineskip

Por ejemplo, un enlace directo de Tipo 3 de 1500 Mbps, con un retardo de ida y vuelta de 10 ciclos de reloj del enlace directo, típicamente, utiliza un retardo de Giro 2 del orden de:

27

XII. Temporización Alternativa de Enlace Inverso

Si bien el empleo de bandas de temporización y guardia expuesto anteriormente funciona para lograr una interfaz de alta velocidad de transferencia de datos, los inventores han descubierto una técnica para lograr longitudes de bit inversos que son más cortas que el tiempo de ida y vuelta, cambiando el descubrimiento de la temporización inversa.

Como se ha presentado anteriormente, el enfoque anterior de la temporización del enlace inverso se configura de forma que el número de ciclos de reloj se cuenta desde el último bit del Tiempo de Guardia 1 de un paquete de temporización inversa, hasta que se muestrea el primero bit en el borde creciente de un reloj 10. Es decir, la señal, o señales, de reloj utilizada(s) para sincronizar las entradas y salidas para la interfaz MDD. El cálculo para el divisor de velocidad inversa, entonces, está dado por:

28

Esto proporciona un ancho de bit igual al retardo de ida y vuelta, lo que da como resultado un enlace inverso muy fiable. Sin embargo, se ha mostrado que el enlace inverso es capaz de funcionar más rápidamente, o a una velocidad de transferencia de datos mayor, que los inventores quieren aprovechar. Una nueva técnica inventiva permite utilizar capacidades adicionales de la interfaz para alcanzar velocidades más altas.

Esto se logra haciendo que el servidor cuente el número de ciclos de reloj hasta que se muestree un uno, pero con el servidor muestreando la línea de datos en ambos bordes creciente y decreciente, durante el paquete de temporización inversa. Esto permite que el servidor escoja el punto de muestreo más útil, o incluso óptimo, dentro del bit inverso, para garantizar que el bit es estable. Es decir, para hallar el borde creciente más útil, u óptimo, para muestrear datos para paquetes de encapsulación inversa de tráfico inverso. El punto óptimo de muestreo depende tanto del divisor de enlace inverso como de si el primero fue detectado en un borde creciente o en un borde decreciente. El nuevo procedimiento de temporización permite que el servidor sólo busque el primer borde del patrón 0xFF 0xFF 0x00 enviado por el cliente para la temporización del enlace inverso, a fin de determinar dónde muestrear en un paquete de encapsulación inversa.

Ejemplos del bit inverso que llega y de cómo se vería ese bit para diversos divisores de velocidad inversa, se ilustran en la Fig. 64, junto con un cierto número de ciclos de reloj que han ocurrido desde el último bit del Tiempo de Guardia 1. En la Fig. 64, puede verse que si el primer borde ocurre entre un borde creciente y decreciente (etiquetado como alza/baja), el punto óptimo de muestreo para un divisor de velocidad inversa igual a uno, el punto óptimo de muestreo es un borde de ciclo de reloj etiquetado `b', ya que ese es el único borde creciente que ocurre dentro del periodo del bit inverso. Para un divisor de velocidad inversa igual a dos, el punto óptimo de muestreo aún es, probablemente, el borde `b' inicial del ciclo de reloj, ya que el borde `c' del ciclo está más cerca de un borde de bit que `b'. Para un divisor de velocidad inversa igual a cuatro, el punto óptimo de muestreo es, probablemente, el borde `d' del ciclo de reloj, ya que está más cerca del borde trasero del bit inverso, donde el valor, probablemente, se ha estabilizado.

Volviendo a la Fig. 64, si, sin embargo, el primer borde ocurre entre un borde decreciente y creciente (etiquetado como baja/alza), el punto óptimo de muestreo para un divisor de velocidad inversa igual a uno es el punto de muestreo del borde `a' del ciclo de reloj, ya que ese es el único borde creciente dentro del periodo del bit inverso. Para un divisor de velocidad inversa igual a dos. el punto óptimo de muestreo es el borde `b', y para un divisor de velocidad inversa igual a cuatro, el punto óptimo de muestreo es el borde `c'.

Puede verse que, según los divisores de velocidad inversa se hacen más y más grandes, el punto óptimo de muestreo deviene más fácil de comprobar o seleccionar, ya que debería ser el borde creciente que está más cerca del medio.

El servidor puede utilizar esta técnica para hallar el número de bordes crecientes de reloj antes de que se observe el borde creciente de datos de los datos del paquete de temporización en la línea de datos. Puede decidir entonces, basándose en si el borde ocurre entre un borde creciente y decreciente, o entre un borde decreciente y creciente, y en cuál es el divisor de velocidad inversa, cuántos ciclos adicionales de reloj añadir a un contador de números, para garantizar razonablemente que el bit siempre es muestreado tan cerca del medio como sea posible.

Una vez que el servidor ha seleccionado o determinado el número de ciclos de reloj, puede "explorar" diversos divisores de velocidad inversa con el cliente, para determinar si funcionará un divisor de velocidad inversa específico. El servidor (y el cliente) pueden comenzar con un divisor igual a uno y comprobar el CRC del paquete de estado inverso recibido desde el cliente, para determinar si esta velocidad inversa funciona adecuadamente para transferir datos. Si el CRC está corrompido, hay probablemente un error de muestreo, y el servidor puede aumentar el divisor de velocidad inversa e intentar solicitar nuevamente un paquete de estado. Si el segundo paquete solicitado está corrompido, el divisor puede aumentarse nuevamente y la solicitud puede hacerse de nuevo. Si este paquete es descodificado correctamente, este divisor de velocidad inversa puede utilizarse para todos los futuros paquetes inversos.

Este procedimiento es efectivo y útil porque la temporización inversa no debería cambiar a partir de la estimación inicial de temporización de ida y vuelta. Si el enlace directo es estable, el cliente debería continuar descodificando paquetes del enlace directo, incluso si hay fallos del enlace inverso. Por supuesto, es aún responsabilidad del servidor fijar un divisor de enlace inverso para el enlace, ya que este procedimiento no garantiza un enlace inverso perfecto. Además, el divisor dependerá principalmente de la calidad del reloj que se utiliza para generar un reloj IO. Si ese reloj tiene una magnitud significativa de arritmia, hay una mayor posibilidad de un error de muestreo. Esta probabilidad de error aumenta 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 desde el Tipo 2 hasta el Tipo 4, debido al sesgo entre las líneas de datos, al ser potencialmente demasiado grande para administrar el enlace a la velocidad que funciona mejor para sólo un par de datos. Sin embargo, la velocidad de datos, probablemente, no requiere ser reducida al procedimiento anterior, incluso con los Tipos 2 a 4, para el funcionamiento. Este procedimiento también puede funcionar mejor si se duplica en cada línea de datos para seleccionar la ubicación ideal, o una óptima, de la muestra de reloj. Si están en el mismo momento de muestreo para cada par de datos, este procedimiento continuaría funcionando. Si están en distintos periodos de muestreo, pueden utilizarse dos enfoques distintos. El primero es seleccionar una ubicación deseada, o más optimizada, de muestra para cada punto de datos, incluso si no es el mismo para cada par de datos. El servidor puede entonces reconstruir el flujo de datos después de muestrear todos los bits del conjunto de pares de datos: dos bits para el Tipo 2, cuatro bits para el Tipo 3, y ocho bits para el Tipo-IV. La otra opción es que el servidor aumente el divisor de velocidad inversa de forma tal que los datos de bits para cada par de datos puedan muestrearse en el mismo borde de reloj.

XIII. Efectos del Retardo y Sesgo de Enlace

El retardo y el sesgo en el enlace directo entre los pares de MDDI_Data y MDDI_Stb pueden limitar la máxima velocidad de datos posible, a menos que se emplee una compensación de retardo y sesgo. Las diferencias en el retardo que causan el sesgo de temporización se deben a la lógica controladora, los controladores y receptores de línea, y los cables y conectores, como se esboza más adelante.

A. Análisis de Temporización de Enlace Limitado por Sesgo (MDDI Tipo-1) 1. Ejemplo de Retardo y Sesgo de un Enlace de Tipo 1

Un circuito de interfaz típica, similar al mostrado en la Fig. 41, se muestra en la Fig. 57 para asimilar un enlace de interfaz de Tipo 1. En la Fig. 57, se muestran valores a título de ejemplo o típicos para el retardo y sesgo de propagación, para cada una de varias etapas de procesamiento o de interfaz de un enlace directo MDDI de Tipo 1. El sesgo en el retardo entre MDDI_Stb y MDDI_Data0 causa que se distorsione el ciclo de funcionamiento del reloj de salida. Los datos en la entrada D de la etapa de flip-flop del receptor (RXFF), que utiliza los flip-flops 5728, 5732, deben cambiar levemente después del borde del reloj, para que puedan ser muestreados fiablemente. La figura muestra dos líneas 5732a y 5732b de retardo en cascada, utilizadas para resolver dos problemas distintos al crear esta relación de temporización. En la implementación efectiva, estas puedan combinarse en un único elemento de retardo.

Las líneas Data, Stb y Temporización de Recuperación de Reloj en un Enlace de Tipo 1, para el procesamiento a título de ejemplo de señales a través de la interfaz se ilustran en la Fig. 58.

El sesgo total de retardo que es significativo generalmente surge o proviene de la suma del sesgo en las siguientes etapas: flip-flop transmisor (TXFF) con los flip-flops 5704, 5706; el controlador de transmisor (TXDRVR) con los controladores 5708, 5710; el CABLE 5702; el receptor de línea receptora (RXRCVR) con los receptores 5722, 5724; y la lógica XOR receptora (RXXOR). El Retardo1 5732a debería coincidir con, o superar, el retardo del puerto XOR 5736 en la etapa RXXOR, que está determinado por la relación:

29

\vskip1.000000\baselineskip

Es deseable satisfacer este requisito a fin de que la entrada D del flip-flop receptor 5728, 5732 no cambie antes de su entrada de reloj. Esto es válido si el tiempo de retención de RXFP es cero.

El objeto o función del Retardo2 es compensar el tiempo de retención del flip-flop RXFF, según la relación:

30

\vskip1.000000\baselineskip

En muchos sistemas, esto será cero, porque el tiempo de retención es cero y, por supuesto, en ese caso el retardo máximo de Retardo2 también puede ser cero.

La contribución del peor caso al sesgo en la etapa del elemento XOR receptor es en el caso de datos-tardíos/sondeo-temprano, donde el Retardo1 está en un valor máximo y la salida del reloj desde el puerto XOR llega tan pronto como sea posible, según la relación:

31

\vskip1.000000\baselineskip

En esta situación, los datos pueden cambiar entre dos periodos de bit, n y n + 1, muy cercanos al momento donde el bit n + 1 es sincronizado en el flip-flop receptor.

La máxima velocidad de datos (mínimo periodo de bit) de un enlace MDDI de Tipo 1 es una función del máximo sesgo encontrado por todos los controladores, cables y receptores en el enlace MDDI, más la configuración total de datos en la etapa RXFF. El sesgo total de retardo en el enlace, hasta la salida de la etapa RXRCVR, puede expresarse como:

32

\vskip1.000000\baselineskip

y el periodo mínimo de bit está dado por:

33

\vskip1.000000\baselineskip

En el ejemplo mostrado en la Fig. 57, t_{SESGO-máx(ENLACE)} = 1,4 nseg, y el periodo mínimo de bit puede expresarse como:

34

o expresarse como aproximadamente 416 Mbps.

B. Análisis de Temporización de Enlace para MDDI de Tipo 2, 3 y 4

Un típico circuito de interfaz, similar al mostrado en las Figs. 41 y 57, se muestra en la Fig. 59 para incluir enlaces de interfaz de Tipo 2, III y IV. Se utilizan elementos adicionales en las etapas TXFF (5904), TXDRVR (5908), RXRCVCR (5922) y RXFF (5932, 5928, 5930) para incluir el procesamiento de señales adicionales. En la Fig. 59, se muestran valores a título de ejemplo o típicos para el retardo y sesgo de propagación, para cada una de varias etapas de procesamiento o interfaz de un enlace directo MDDI de Tipo 2. Además del sesgo en el retardo entre MDDI_Stb y MDDI_Data0 que afecta el ciclo de operación del reloj de salida, también hay sesgo tanto entre estas dos señales como en las otras señales MDDI_Data0. Los datos en la entrada D de la etapa del flip-flop receptor B (RXFFB), que consisten en los flip-flops 5928 y 5930, están levemente cambiados después del borde de reloj, por lo que pueden ser muestreados con fiabilidad. Si MDDI_Data1 llega antes que MDDI_Stb o MDDI_Data0, entonces MDDI_Data1 debería retardarse para ser muestreado durante al menos la magnitud del sesgo del retardo. Para lograr esto, los datos se retardan utilizando la línea de retardo Retardo3. Si MDDI_Data1 llega después de MDDI_Stb y MDDI_Data0, y también es retardado por Retardo3, entonces el punto donde MDDI_Data1 cambia se mueve más cerca del siguiente borde de reloj. Este proceso determina un límite superior de la velocidad de datos de un enlace MDDI de Tipo 2, 3 ó 4. Algunas posibilidades distintas a título de ejemplo para la temporización o la relación de sesgo de dos señales de datos y MDDI_Stb, cada una con respecto a la otra, se ilustra en las Figs. 60A, 60B y 60C.

A fin de muestrear datos fiablemente en RXFFB cuando llega MDDI_DataX lo antes posible, Retardo3 se fija de acuerdo a la relación:

35

La máxima velocidad de enlace está determinada por el mínimo periodo de bit admisible. Esto es afectado en el máximo grado cuando MDDI_DataX llega lo más tarde posible. En ese caso, el mínimo tiempo de ciclo admisible está dado por:

36

\vskip1.000000\baselineskip

La cota superior de la velocidad de enlace es entonces:

37

\vskip1.000000\baselineskip

y, dada esa hipótesis:

38

\vskip1.000000\baselineskip

En el ejemplo dado anteriormente, la cota inferior del periodo mínimo de bit está dada por la relación:

39

lo que es, aproximadamente, 208 Mbps.

\newpage

Esto es mucho más lento que la máxima velocidad de datos que puede utilizarse con un enlace de Tipo 1. La capacidad automática de compensación de sesgo del retardo de la MDDI reduce significativamente el efecto que el sesgo de retardo tiene sobre la velocidad máxima del enlace.

XIV. Descripción de la Interconexión de Capa Física

Las conexiones físicas útiles para implementar una interfaz según la presente invención pueden realizarse utilizando piezas comercialmente disponibles, como la pieza número 3260-8S2(01) fabricada por Hirose Electric Company Ltd. en el lado del servidor, y la pieza número 3240-8P-C fabricada por Hirose Electric Company Ltd en el lado del dispositivo visor. Una asignación a título de ejemplo de patillas de interfaz, o "desglose de patillas", para tales conectores, utilizados con una interfaz de Tipo-I/Tipo 2, se enumera en la Tabla XIII, y se ilustra en la
Fig. 61.

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA XIII

40

\newpage

La pantalla está conectada con la HOST_Gnd en la interfaz del servidor, y un hilo de drenaje apantallado en el cable está conectado con la pantalla del conector de visor. Sin embargo, la pantalla y el hilo de drenaje no están conectados con la descarge de tierra del circuito dentro de un visor.

Los elementos o dispositivos de interconexión se escogen o se diseñan a fin de que sean lo bastante pequeños para su empleo con dispositivos móviles de comunicación y cálculo, tales como las agendas electrónicas y los teléfonos inalámbricos, o los dispositivos de juegos portátiles, sin ser abultados ni antiestéticos en comparación con el tamaño relativo del dispositivo. Todos los conectores y el cableado deberían ser lo bastante duraderos como para su utilización en el típico entorno de consumo, y tener presente un tamaño pequeño, especialmente para el cableado, y de coste relativamente bajo. Los elementos de transferencia deberían admitir señales de datos y sondeo que sean datos NRZ diferenciales, con una velocidad de transferencia de hasta unos 450 Mbps para el Tipo 1 y el Tipo 2, y hasta 3,6 Gbps para la versión de Tipo 4 paralela de 8 bits.

Para aplicaciones en modalidad interna o bien no hay conectores en el mismo sentido para los conductores utilizados, o bien tales elementos de conexión tienden a estar muy miniaturizados. Un ejemplo son los "zócalos" de nula fuerza de inserción para recibir circuitos integrados o elementos que albergan bien al servidor o bien al dispositivo cliente. Otro ejemplo es cuando el servidor y el cliente residen en placas de circuitos impresos con diversos conductores de interconexión, y tienen "patillas" o contactos que se extienden desde cubiertas que están soldadas a contactos en los conductores para la interconexión de circuitos integrados.

XV. Operación

Un resumen de las etapas generales acometidas al procesar datos y paquetes durante la operación de una interfaz que utiliza las realizaciones de la invención se muestra en las Figs. 54A y 54B, junto con una visión general del aparato de interfaz que procesa los paquetes en la Fig. 55. En estas figuras, el proceso comienza en una etapa 5402, con una determinación en cuanto a si el cliente y el servidor están o no conectados utilizando un trayecto de comunicación, en este caso un cable. Esto puede ocurrir mediante el empleo de un sondeo periódico por parte del servidor, utilizando software o hardware que detecta la presencia de conectores o cables o señales en las entradas al servidor (tal como se ve para las interfaces USB), u otras técnicas conocidas. Si no hay ningún cliente conectado con el servidor, entonces puede simplemente ingresar a un estado de espera de alguna duración predeterminada, según la aplicación, ingresar a una modalidad de hibernación, o ser desactivado para esperar un uso futuro, que podría requerir que un usuario iniciara una acción para reactivar el servidor. Por ejemplo, cuando un servidor reside en un dispositivo de tipo ordenador, un usuario podría tener que pinchar en un icono de pantalla, o solicitar un programa que active el procesamiento del servidor para buscar al cliente. Nuevamente, el simple enchufe de una conexión de tipo USB podría activar el procesamiento del servidor, según las capacidades y configuración del servidor o del software residente en el
servidor.

Una vez que un cliente está conectado con el servidor, o viceversa, o detectado como presente, bien el cliente, o bien el servidor, envía los paquetes adecuados solicitando servicio en las etapas 5405 y 5406. El cliente podría enviar los paquetes de Solicitud o Estado de Servicio de Cliente en la etapa 5404. Se observa que el enlace, según lo anteriormente expuesto, podría haber sido apagado previamente, o estar en modalidad de hibernación, por lo que esto puede no ser una inicialización completa del enlace de comunicación a continuación. Una vez que el enlace comunicación está sincronizado y el servidor está intentando comunicarse con el cliente, el cliente también proporciona un Paquete de Capacidades de Visor al servidor, como en la etapa 5408. El servidor puede comenzar ahora a determinar el tipo de soporte, incluyendo las velocidades de transferencia, que el cliente puede asimilar.

Generalmente, el servidor y el cliente también negocian el tipo (velocidad/rapidez) de la modalidad de servicio a utilizar, por ejemplo, Tipo 1, Tipo 2, y así sucesivamente, en una etapa 5410. Una vez que está establecido el tipo de servicio, el servidor puede comenzar a transferir información. Además, el servidor puede utilizar 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ñales, según se muestra en la etapa 5411.

Como se ha establecido anteriormente, todas las transferencias comienzan con un Paquete de Cabecera de Subtrama, mostrado durante su transferencia en la etapa 5412, seguido por el tipo de datos, aquí paquetes de flujo de vídeo y audio, y paquetes de relleno, mostrados durante su transferencia en la etapa 5414. Los datos de audio y vídeo han sido previamente preparados o mapeados en paquetes, y se han insertado paquetes de relleno según se necesite o se desee, para rellenar un número requerido de bits para las tramas de medios. El servidor puede enviar paquetes tales como los Paquetes de Activación de Canal de Audio Directo para activar dispositivos de sonido. Además, el servidor puede transferir comandos e información utilizando otros tipos de paquetes expuestos anteriormente, mostrados aquí como la transferencia de Mapa de Colores, Transferencia de Bloques de Bits u otros paquetes en la etapa 5416. Además, el servidor y el cliente pueden intercambiar datos relacionados con un teclado o dispositivo puntero, utilizando los paquetes adecuados.

Durante la operación, puede ocurrir uno entre varios sucesos que llevan al servidor o al cliente a desear una velocidad de datos, o tipo de modalidad de interfaz, distintos. Por ejemplo, un ordenador, u otro dispositivo comunicando datos, podría encontrar condiciones de carga al procesar datos que causan una ralentización en la preparación o presentación de paquetes. Un visor que recibe los datos podría cambiar de una fuente de energía AC dedicada a una fuente de energía por batería más limitada, y bien no poder transferir los datos hacia adentro tan rápidamente, bien procesar los comandos tan inmediatamente, o bien no poder utilizar el mismo grado de resolución o intensidad de color ante los más limitados valores de potencia. Alternativamente, una condición restrictiva podría ser abatida o desaparecer, permitiendo a cualquier dispositivo transferir datos a mayores velocidades. Siendo esto más deseable, puede efectuarse una solicitud para cambiar a una modalidad de mayor velocidad de transferencia.

Si ocurren, o cambian, estos, u otros, tipos de condiciones conocidas, ya sea el servidor o el cliente pueden detectarlas e intentar renegociar la modalidad de interfaz. Esto se muestra en la etapa 5420, donde el servidor envía Paquetes de Solicitud de Traspaso de Tipo al cliente, solicitando un traspaso a otra modalidad, el cliente envía Paquetes de Acuse de Recibo de Tipo de Interfaz, confirmando que se busca un cambio, y el servidor envía Paquetes de Ejecución de Traspaso de Tipo para realizar el cambio a la modalidad especificada.

Aunque no se requiere un orden específico de procesamiento, el cliente y el servidor también pueden intercambiar paquetes relacionados con datos destinados a, o recibidos desde, dispositivos punteros, teclados u otros dispositivos de entrada de tipo usuario, asociados principalmente al cliente, aunque tales elementos también pueden estar presentes en el lado del servidor. Estos paquetes son típicamente procesados utilizando un elemento de tipo procesador general, y no la máquina (5502) de estados. Además, algunos de los comandos anteriormente expuestos también serán procesados por el procesador general. (5504, 5508).

Después de que los datos y comandos han sido intercambiados entre el servidor y el cliente, en algún punto se toma una decisión en cuanto a si han de transferirse o no datos adicionales, o si el servidor o el cliente va a cesar de prestar servicio a la transferencia. Esto se muestra en la etapa 5422. Si el enlace va a entrar bien a un estado de hibernación, o bien a un cierre por completo, el servidor envía un paquete de Cierre de Enlace al cliente, y ambas partes terminan la transferencia de datos.

Los paquetes que se transfieren en el procesamiento anterior de operaciones serán transferidos utilizando los controladores y receptores previamente expuestos con relación a los controladores del servidor y del cliente. Estos controladores de línea y de otros elementos lógicos están conectados con la máquina de estados y los procesadores generales anteriormente expuestos, según se ilustra en la visión general de la Fig. 55. En la Fig. 55, una máquina 5502 de estados y los procesadores generales 5504 y 5508 pueden conectarse adicionalmente con otros elementos no mostrados, tales como una interfaz USB dedicada, elementos de memoria, u otros componentes que residen fuera del controlador de enlace con el cual interactúan, incluyendo, pero sin limitarse a, la fuente de datos, y los chips de control de vídeo para los dispositivos de visualización.

Los procesadores y la máquina de estados proporcionan control sobre la activación y desactivación de los controladores, según lo anteriormente expuesto con relación a los tiempos de guardia, etc., para garantizar el establecimiento o terminación del enlace de comunicación, y la transferencia de paquetes.

XVI. Almacenes Temporales de Tramas de Visor

Los requisitos de almacenamiento temporal de datos de vídeo son distintos para imágenes de vídeo en movimiento, en comparación con los gráficos de ordenador. Los datos de píxeles se almacenan muy frecuentemente en un almacén temporal local de tramas en el cliente, de forma que la imagen en el visor pueda refrescarse localmente.

Cuando se está visualizando vídeo de movimiento completo (casi todo píxel en el visor cambia en cada Trama de Medios), se prefiere, usualmente, almacenar los datos de píxeles entrantes en un almacén temporal de tramas, mientras que la imagen en el visor está siendo refrescada desde un segundo almacén temporal de tramas. Pueden utilizarse más de dos almacenes temporales de visor, para eliminar efectos visibles como los descritos más adelante. Cuando una imagen entera ha sido recibida en un almacén temporal de tramas, pueden conmutarse los roles de los almacenes temporales, y la imagen recientemente recibida se utiliza entonces para refrescar el visor, y el otro almacén temporal se llena con la próxima trama de la imagen. Este concepto se ilustra en la Fig. 91A, donde los datos de píxeles se escriben en el almacén temporal de imágenes fuera de línea fijando los bits de Actualización de Visor
en "01".

En otras aplicaciones, el servidor necesita actualizar sólo una pequeña porción de la imagen, sin tener que repintar la imagen completa. En esta situación, se desea escribir los nuevos píxeles directamente en el almacén temporal utilizado para refrescar el visor, como se ilustra en detalle en la Fig. 91B.

En aplicaciones que tienen una imagen fija con una pequeña ventana de vídeo, lo más fácil es escribir la imagen fija en ambos almacenes temporales (los bits de actualización del visor son iguales a "11"), como se muestra en la Fig. 91C, y escribir posteriormente los píxeles de la imagen en movimiento en el almacén temporal en línea fijando los bits de actualización del visor en "01".

Las siguientes normas describen la manipulación útil de los punteros de almacén temporal al escribir la nueva información al cliente y refrescar el visor simultáneamente. Existen tres punteros de almacén temporal: actualmente_llenado apunta al almacén temporal que está siendo actualmente llenado con datos por el enlace MDDI. recién_llenado apunta al almacén temporal que ha sido llenado más recientemente. en_visualización apunta al almacén temporal que está siendo actualmente utilizado para refrescar el visor. Los tres punteros de almacén temporal pueden contener valores entre 0 y N-1, donde N es el número de almacenes temporales del visor, y N > 2. Las operaciones aritméticas sobre los punteros de almacén temporal son mod N, p. ej., cuando N = 3 y actualmente_llenado = 2, el incremento de actualmente_llenado causa que actualmente_llenado sea fijado en 0. En el caso sencillo donde N = 2, recién_llenado es siempre el complemento del actualmente_llenado. En todo límite de Trama de Medios MDDI (Paquete de Cabecera de Subtrama con el campo Total de Subtrama igual a cero), realizar las siguientes operaciones en el orden especificado: fijar recién_llenado al valor de actualmente_llenado, y fijar actualmente_llenado igual a actualmente_llenado + 1.

Los Paquetes de Flujo de Vídeo MDDI actualizan los almacenes temporales según la estructura o metodología siguiente: cuando los Bits de Actualización de Visor son iguales a `01', los datos de píxeles se escriben en el almacén temporal especificado por actualmente_llenado; cuando los Bits de Actualización de Visor son iguales a `00', los datos de píxeles se escriben en el almacén temporal especificado por recién_llenado; y cuando los Bits de Actualización de Visor son iguales a "11", los datos de píxeles se escriben en todos los almacenes temporales. El visor se refresca desde el almacén temporal especificado por el puntero en_visualización. Después de que el visor refresca el último píxel en un origen de refresco de tramas, y antes de que comience a refrescar el primer píxel en el siguiente origen de refresco de tramas, el proceso de actualización del visor realiza la operación de fijar el puntero en_refresco con el valor de recién_llenado;

El Paquete de Flujo de Vídeo contiene un par de Bits de Actualización de Visor que especifican el almacén temporal de tramas donde se escribirán los datos de píxeles. El Paquete de Capacidad de Visor tiene tres bits adicionales que indican qué combinaciones de los Bits de Actualización de Visor disponen de soporte en el cliente En muchos casos, las imágenes generadas por ordenador necesitan actualizarse incrementalmente, basándose en la entrada del usuario, o derivándose de información recibida desde una red de ordenadores. Las combinaciones "00" y "11" de los Bits de Actualización del Visor brindan soporte a esta modalidad de operación, causando que los datos de píxeles se escriban en el almacén temporal de tramas que está visualizándose, o en ambos almacenes temporales de
tramas.

Al asimilar imágenes de vídeo, la Fig. 92 ilustra cómo las imágenes de vídeo se visualizan utilizando un par de almacenes temporales de tramas cuando los datos de vídeo se transmiten por el enlace MDDI con los Bits de Actualización de Visor iguales a "01". Después de que se detecta un límite de trama de medios en el enlace MDDI, el proceso de refresco del visor comenzará a refrescar a partir del siguiente almacén temporal de tramas cuando el proceso de refresco para la trama actualmente refrescada se haya completado.

Una hipótesis importante relacionada con la Fig. 92 es que la imagen es recibida desde el servidor como un flujo continuo de píxeles que se transmiten en el mismo orden que el cliente emplea para leer los píxeles desde el almacén temporal de tramas para refrescar el visor (usualmente desde el extremo superior izquierdo, leyendo fila por fila, hasta la esquina inferior derecha de la pantalla. Este es un detalle importante en los casos donde las operaciones de Refresco de Visor y Transferencia de Imagen hacen referencia al mismo almacén temporal de tramas.

Es necesario que la velocidad de refresco de tramas de visor sea mayor que la velocidad de transferencia de tramas de imagen, para evitar exhibir imágenes parciales. La Fig. 93 muestra cómo puede ocurrir la fragmentación de imágenes con una velocidad lenta de refresco de visor, esto es, el refresco del visor es más lento que la transferencia de imagen.

En una imagen que contiene una combinación de imágenes gráficas de ordenador e imágenes de vídeo en movimiento, los datos de píxeles de vídeo podrían ocupar una pequeña porción de una trama de medios. Esto podría ser significativo en situaciones donde la operación de refresco de visor y la transferencia de imágenes se refieren al mismo almacén temporal de tramas. Estas situaciones se muestran con un sombreado con cruces en la Fig. 94, donde los píxeles leídos del almacén temporal para refrescar el visor podrían ser los píxeles escritos en el almacén temporal dos tramas atrás, o pueden corresponder a la trama que está siendo escrita inmediatamente en el mismo almacén temporal de tramas.

El empleo de tres almacenes temporales de tramas en el cliente resolverá el problema de la pequeña ventana de contención para acceder a un almacén temporal de tramas, como se muestra en la Fig. 95.

Sin embargo, aún hay un problema si la velocidad de refresco del visor es menor que la velocidad de tramas de medios por el enlace MDDI, según se muestra en la Fig. 96.

El uso de un único almacén temporal para mover imágenes de vídeo es algo problemático, según se muestra en la Fig. 97. Con el refresco de visor más rápido que la transferencia de imágenes hacia el almacén temporal, la imagen que está siendo refrescada mostrará a veces la porción superior de la trama que se está escribiendo, y la porción inferior de la imagen será la trama previamente transferida. Con el refresco del visor más rápido que la transferencia de imágenes (la modalidad preferida de operación) habrá instancias más frecuentes de tramas que muestran una imagen partida similar.

\newpage

XVII. Tabla de Valores de Retardo

El Paquete de Parámetros de Retardo de Procesamiento de Paquetes utiliza una función de búsqueda en tabla para calcular el retardo predicho para procesar ciertos comandos en el cliente. Los valores en la tabla aumentan de forma logarítmica para proporcionar una gama dinámica muy amplia de valores de retardo. Una tabla a título de ejemplo de valores de retardo, útil para implementar realizaciones de la invención, se halla en la Tabla XX a continuación, con los valores de índices correspondientes con respecto a los valores de retardo.

\vskip1.000000\baselineskip

TABLA XX

41

42

El retardo se calcula realizando una búsqueda en tabla, utilizando el parámetro especificado como un índice en la tabla. Esto significa que un retardo es igual a TablaProcesamientoPaquetes(índice). Por ejemplo: si uno de los parámetros del Elemento de la Lista de Parámetros de Retardo es un valor de 8 bits igual a 134, entonces el retardo es igual a TablaProcesamientoPaquetes(134), que es 16 \museg. El valor 255 indica que el tiempo de ejecución del comando no puede determinarse por cálculo, y que el servidor debe comprobar los Indicadores Activos de Gráficos en el Paquete de Solicitud y Estado de Visor, o el Parámetro de Control B7h del VCP del MCCS.

En algunos casos, este retardo se multiplica por la altura, ancho o número de píxeles en la imagen de destino, y se añade a otros retardos para calcular el retardo global de procesamiento de paquete.

XVIII. Soporte de Clientes Múltiples

La versión actual del protocolo no parece prestar soporte directamente a múltiples dispositivos clientes. Sin embargo, la mayoría de los paquetes contienen un campo reservado Identificador de Cliente que puede utilizarse para dirigirse a dispositivos clientes específicos en un sistema con múltiples clientes. Actualmente, para muchas aplicaciones, este Identificador de cliente, o estos Identificadores de clientes, se fijan en cero. El paquete de cabecera de subtrama también contiene un campo para indicar si el servidor presta soporte o no a un sistema de múltiples clientes. Por lo tanto, hay una manera en la cual múltiples dispositivos clientes probablemente serían conectados y direccionados en futuras aplicaciones de la interfaz o protocolo MDD para ayudar a los diseñadores de sistemas a planificar la compatibilidad futura con múltiples servidores y clientes.

En sistemas con múltiples clientes es útil que los clientes estén conectados al servidor utilizando un encadenamiento activo de clientes, o utilizando concentradores, como se muestra en la Fig. 98, o bien utilizando una combinación de estas técnicas, como se muestra en la Fig. 99.

XVIII. Addendum

Además de los formatos, estructuras y contenidos expuestos anteriormente para los diversos paquetes utilizados para implementar la arquitectura y el protocolo para realizaciones de la invención, se presentan aquí contenidos de campos u operaciones más detallados para algunos de los tipos de paquetes. Estos se presentan aquí para clarificar adicionalmente su respectivo uso u operaciones, para permitir a aquellos versados en la técnica comprender más inmediatamente y hacer uso de la invención para una gran variedad de aplicaciones. Sólo unos pocos de los campos no expuestos ya se exponen aquí adicionalmente. Además, estos campos se presentan con definiciones y valores a título de ejemplo con respecto a las realizaciones presentadas anteriormente. Sin embargo, tales valores no deben tomarse como limitaciones de la invención, sino que representan una o más realizaciones útiles para implementar la interfaz y el protocolo, y no todas las realizaciones deben practicarse juntas o al mismo tiempo. Pueden emplearse otros valores en otras realizaciones para lograr la presentación deseada de los datos, o de los resultados de la velocidad de transferencia de los datos, como entenderán aquellos versados en la técnica.

A. Para Paquetes de Flujo de Vídeo

En una realización, el campo Atributos de Datos de Píxel (2 bytes) tiene una serie de valores de bit que se interpretan de la siguiente manera. Los Bits 1 y 0 seleccionan cómo se encaminan los datos de píxeles del visor. Para valores de bits de `11', los datos se visualizan en, o para, ambos ojos; para los valores de bits `10', los datos se encaminan sólo al ojo izquierdo, para los valores de bits `01', los datos se encaminan sólo al ojo derecho, y para los valores de bits de `00', los datos se encaminan a un visor alternativo, como el que puede especificarse con los bits 8 a 11 expuestos más adelante.

El Bit 2 indica si los Datos de Píxeles se presentan o no en un formato entrelazado, donde un valor de `0' significa que los datos de píxeles están en el formato progresivo estándar, y que el número de fila (coordenada Y del píxel) se incrementa en 1 cuando se avanza desde una fila a la siguiente. Cuando este bit tiene un valor de `1', los datos de píxeles están en formato entrelazado, y el número de fila se incrementa en 2 al avanzar desde una fila a la siguiente. El Bit 3 indica que los Datos de Píxeles están en formato alternativo de píxel. Esto es similar a la modalidad entrelazada estándar habilitada por el bit 2, pero el entrelazado es vertical, en lugar de horizontal. Cuando el Bit 3 es `0', los Datos de Píxeles están en el formato progresivo estándar, y el número de columna (coordenada X del píxel) se incrementa en 1 según se recibe cada píxel sucesivo. Cuando el Bit 3 es `1', los Datos de Píxel están en formato alternativo de píxel, y el número de columna se incrementa en 2 según se recibe cada píxel.

El Bit 4 indica si los Datos de Píxeles se relacionan o no con un visor o una cámara, como cuando los datos se transfieren a o desde un visor interno para un teléfono inalámbrico, o dispositivo similar, o incluso un ordenador portátil, o tales otros dispositivos como los anteriormente expuestos, o los datos se transfieren a o desde una cámara integrada en, o directamente acoplada con, el dispositivo. Cuando el Bit 4 es `0', los Datos de Píxeles se transfieren a o desde un almacén temporal de tramas de visor. Cuando el Bit 4 es `1', los Datos de Píxeles se transfieren a o desde una cámara o dispositivo de vídeo de algún tipo, siendo tales dispositivos bien conocidos en la técnica.

El Bit 5 se utiliza para indicar que los datos de píxeles contienen la siguiente fila consecutiva de píxeles en el visor. Se considera que este es el caso cuando el Bit 5 se fija igual a `1'. Cuando el Bit 5 se fija en `1', entonces los parámetros 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 fija en un nivel de uno lógico, esto indica que los datos de píxeles en este paquete son la última fila de píxeles en la imagen. El Bit 8 del campo Indicadores de Capacidad de Característica de Cliente del Paquete Capacidad del Cliente indica si esta característica dispone de soporte.

Los Bits 7 y 6 son Bits de Actualización de Visor que especifican un almacén temporal de tramas donde los datos de píxeles han de escribirse. Los efectos más específicos se exponen en otro sitio. Para valores de bit de `01', los Datos de Píxeles se escriben en el almacén temporal de imágenes fuera de línea. Para los valores de bit de `00', los Datos de Píxeles se escriben en el almacén temporal de imágenes utilizado para refrescar el visor. Para valores de bit de `11', los Datos de Píxeles se escriben en todos los almacenes temporales de imágenes. Los valores de bit, o la combinación, `10' se trata como un valor o asignación inválida, y los Datos de Píxeles se ignoran y no se escriben en ninguno de los almacenes temporales de imágenes. Este valor puede tener uso para aplicaciones futuras de la interfaz.

Los Bits 8 a 11 forman un entero sin signo de 4 bits que especifica un visor, o ubicación de visor, alternativo, donde los datos de píxeles han de encaminarse. Los Bits 0 y 1 se fijan iguales a `00' a fin de que el cliente visor interprete los bits 8 a 11 como un número de visor alternativo. Si los bits 0 y 1 no son iguales a `00', entonces los bits 8 a 11 se fijan en niveles de cero lógico.

Los Bits 12 a 14 están reservados para uso futuro y generalmente se fijan en niveles de cero lógico. El Bit 15, como se ha expuesto, se utiliza conjuntamente con el bit 5, y fijar el bit 15 al valor de uno lógico indica que la fila de píxeles en el campo Datos de Píxeles es la última fila de píxeles en una trama de datos. El siguiente Paquete de Flujo de Vídeo con el bit 5 fijado en el uno lógico corresponderá a la primera línea de píxeles de la próxima trama de vídeo.

Los campos Inicio X e Inicio Y, de 2 bytes, especifican las coordenadas absolutas X e Y del punto (Inicio X, Inicio Y) para el primer píxel en el campo Datos de Píxeles. Los campos Borde Izquierdo X y Borde Superior Y, de 2 bytes, especifican la coordenada X del borde izquierdo y la coordenada Y del borde superior de la ventana de pantalla rellenada por el campo Datos de Píxeles, mientras que los campos Borde Derecho X y Borde Inferior Y especifican la coordenada X del borde derecho y la coordenada Y del borde inferior de la ventana que se está actualizando.

El campo Total de Píxeles (2 bytes) especifica el número de píxeles en el campo Datos de Píxeles más adelante.

El campo CRC de Parámetros (2 bytes) contiene un CRC de todos los bytes desde la Longitud de Paquete hasta el Total de Píxeles. Si este CRC no confirma la comprobación, entonces se descarta el paquete entero.

El campo Datos de Píxeles contiene la información de vídeo no procesado que debe exhibirse, y que está formateada de la manera descrita por el campo Descriptor de Formato de Datos de Vídeo. Los datos se transmiten de a una "fila" por vez, como se ha expuesto en otro sitio.

El campo CRC de Datos de Píxeles (2 bytes) contiene un CRC de 16 bits sólo de los Datos de Píxeles. Si una verificación del CRC de este valor falla, entonces los Datos de Píxeles aún pueden utilizarse, pero el contador de errores de CRC se incrementa.

B. Para Paquetes de Flujo de Audio

En una realización, el campo Identificador de Canal de Audio (1 byte) utiliza un valor entero sin signo de 8 bits para identificar un canal específico de audio, al cual los datos de audio son enviados por el dispositivo cliente. Los canales físicos de audio se especifican como, o se mapean a, canales físicos mediante este campo, como valores 0, 1, 2, 3, 4, 5, 6 ó 7, que indican, respectivamente, los canales izquierdo frontal, derecho frontal, izquierdo trasero, derecho trasero, central frontal, de graves, izquierdo envolvente, y derecho envolvente. Un valor de Identificador de canal de audio de 254 indica que el flujo individual de muestras de audio digital se envía a ambos canales izquierdo frontal y derecho frontal. Esto simplifica las comunicaciones para aplicaciones tales como aquellas donde se utiliza un auricular estéreo para la comunicación de voz, o se utilizan artefactos de mejora de productividad en una agenda electrónica, u otras aplicaciones donde una Interfaz de Usuario sencilla genera tonos de advertencia. Los valores para el campo del Identificador entre 8 y 253, y el valor 255, están actualmente reservados para su uso allí donde los nuevos diseños deseen asignaciones adicionales, según lo anticipado por aquellos versados en la técnica.

El campo Reservado 1 (1 byte) está generalmente reservado para uso futuro, y tiene todos los bits en este campo fijados en cero. Una función de este campo es causar que todos los campos subsiguientes de 2 bytes se alineen a una palabra de dirección de 16 bits, y causar que los campos de 4 bytes se alineen a una palabra de dirección de 32 bits.

El campo Total de Muestras de Audio (2 bytes) especifica el número de muestras de audio en este paquete.

El campo Bits por Muestra y Empaquetado contiene 1 byte que especifica el formato de empaquetado de los datos de audio. En una realización, el formato generalmente empleado es que los Bits 4 a 0 definan el número de bits por muestra de audio PCM. El Bit 5 especifica entonces si las muestras de Datos de Audio Digital están o no empaquetadas. Como se ha mencionado anteriormente, la Fig. 12 ilustra la diferencia entre muestras de audio empaquetadas y alineadas a byte. Un valor de `0' para el Bit 5 indica que cada muestra de audio PCM en el campo Datos de Audio Digital está alineado por byte con el límite de byte de interfaz, y un valor de `1' india que cada muestra sucesiva de audio PCM está empaquetada con la muestra de audio previa. Este bit es efectivo sólo cuando el valor definido en los bits 4 a 0 (el número de bits por muestra de audio PCM) no es un múltiplo de ocho. Los Bits 7 a 6 se reservan para su uso allí donde los diseñadores de sistemas deseen asignaciones adicionales, y generalmente se fijan en un valor cero.

El campo Velocidad de Muestra de Audio (1 byte) especifica la velocidad de muestra de audio PCM. El formato empleado es para que un valor de 0 indique una velocidad de 8.000 muestras por segundo (mps), un valor de 1 indica 16.000 mps., un valor de 2, 24.000 mps, un valor de 3, 32.000 mps, un valor de 4, 40.000 mps, un valor de 5, 48.000 mps, un valor de 6, 11.025 mps, un valor de 7, 22.050 mps y un valor de 8, 44.100 mps, respectivamente, estando los valores entre 9 y 255 reservados para uso futuro, por lo que actualmente se fijan en cero.

El campo CRC de Parámetros (2 bytes) contiene un CRC de 16 bits de todos los bytes desde la Longitud de Paquete a la Velocidad de Muestra de Audio. Si este CRC no confirma la comprobación adecuadamente, entonces se descarta el paquete entero. El campo Datos de Audio Digital contiene las muestras de audio no procesado a reproducir, y usualmente tiene la forma de un formato lineal de enteros sin signo. El campo CRC de Datos de Audio (2 bytes) contiene un CRC de 16 bits sólo de los Datos de Audio. Si este CRC no confirma la comprobación, entonces los Datos de Audio aún pueden utilizarse, pero el contador de errores de CRC se incrementa.

C. Para Paquetes de Flujo Definido por el Usuario

En una realización, el campo Número de Identificador de Flujo, de 2 bytes, se utiliza para identificar un flujo específico definido por el usuario. El contenido de los campos Parámetros de Flujo y Datos de Flujo está típicamente definido por el fabricante del equipo MDDI. El campo CRC de Parámetros de Flujo, de 2 bytes, contiene un CRC de 16 bits de todos los bytes de los parámetros del flujo, a partir de la Longitud de Paquete y hasta el byte de Codificación de Audio. Si este CRC falla en la comprobación, entonces se descarta el paquete entero. Ambos campos Parámetros de Flujo y CRC de Parámetros de Flujo pueden descartarse si no son necesarios para una aplicación final de la interfaz MDD, es decir, son considerados optativos. El campo CRC de Datos de Flujo, de 2 bytes, contiene un CRC sólo de los Datos de Flujo. Si este CRC no confirma la comprobación adecuadamente, entonces el uso de los Datos de Flujo es optativo, según los requisitos de la aplicación. El empleo de los datos de flujo, condicionados al CRC válido, requiere generalmente que los datos de flujo sean almacenados temporalmente hasta que el CRC se confirme como correcto. El contador de errores de CRC se incrementa si el CRC no es correcto.

D. Para Paquetes de Mapa de Colores

El campo Identificador de hCliente, de 2 bytes, contiene información o valores que están reservados para un Identificador de Cliente, como se ha utilizado anteriormente. Como este campo está generalmente reservado para uso futuro, el valor actual se fija en cero, fijando sus bits en `0'.

El campo Total de Elementos de Mapa de Colores, de 2 bytes, utiliza valores para especificar el número total de elementos del mapa de colores, de 3 bytes, que están contenidos en el campo Datos de Mapa de Colores, o las entradas de la tabla del mapa de colores que existen en los Datos de Mapa de Colores en este paquete. En esta realización, el número de bytes en los Datos de Mapa de Colores es 3 veces el Total de Elementos de Mapa de Colores. El Total de Elementos de Mapa de Colores se fija igual a cero para no enviar ningún dato de mapa de colores. Si el Tamaño del Mapa de Colores es cero, entonces aún se envía, generalmente, un valor de Desplazamiento de Mapa de Colores, pero es ignorado por el visor. El campo Desplazamiento de Mapa de Colores (4 bytes) especifica el desplazamiento de los Datos de Mapa de Colores en este paquete, desde el principio de la tabla de mapa de colores en el dispositivo
cliente.

Un campo CRC de Parámetros, de 2 bytes, contiene un CRC de todos los bytes desde la Longitud de Paquete hasta el byte de Codificación de Audio. Si este CRC no confirma la comprobación, entonces se descarta el paquete entero.

Para el campo Datos de Mapa de Colores, el ancho de cada ubicación del mapa de colores está especificado por el campo Tamaño de Elemento del Mapa de Colores, donde, en una realización, la primera parte especifica la magnitud del azul, la segunda parte especifica la magnitud del verde, y la tercera parte especifica la magnitud del rojo. El campo Tamaño del Mapa de Colores especifica el número de elementos de la tabla de mapa de colores, de 3 bytes, que existen en el campo Datos de Mapa de Colores. Si un mapa de colores individual no cabe en un Paquete de Formato de Datos de Vídeo y Mapa de Colores, entonces puede especificarse el mapa de colores entero enviando múltiples paquetes con distintos 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 del mapa de colores será el mismo que el especificado en el campo Ancho RGB de Mapa de Colores del Paquete de Capacidad de Visor.

Un campo CRC de Datos de Mapa de Colores, de 2 bytes, contiene un CRC sólo de los Datos de Mapa de Colores. Si este CRC no confirma la comprobación, entonces los Datos de Mapa de Colores aún pueden utilizarse, pero el contador de errores de CRC se incrementa.

Cada elemento de datos del mapa de colores debe transmitirse en el orden: azul, verde, rojo, con el bit menos significativo de cada componente transmitido en primer término. Los componentes individuales azules, verdes y rojos de cada elemento del mapa de colores estarán empaquetados, pero cada elemento del mapa de colores (el bit menos significativo del componente azul) debería estar alineado por byte. La Fig. 100 ilustra un ejemplo de elementos de datos del 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, el campo Ancho RGB de Mapa de Colores del Paquete de Capacidad de Visor es igual a 0x0786.

E. Para Paquetes de Encapsulación de Enlace Inverso

El campo CRC de Parámetros (2 bytes) contiene un CRC de 16 bits de todos los bytes desde la Longitud de Paquete hasta la Longitud de Giro. Si este CRC no confirma la comprobación, entonces se descarta el paquete entero.

En una realización, el campo Indicadores de Enlace Inverso (1 byte) contiene un conjunto de indicadores para solicitar información del cliente. Si un bit (por ejemplo, el Bit 0) se fija en uno, entonces el servidor solicita la información especificada del visor utilizando el Paquete de Capacidad de Cliente. Si el bit es cero, entonces el servidor no necesita la información del cliente. Los bits restantes (aquí, los Bits 1 a 7) están reservados para uso futuro y se fijan en cero. Sin embargo, pueden utilizarse más bits, según se desee, para establecer indicadores para el enlace inverso.

El campo Divisor de Velocidad Inversa (1 byte) especifica el número de ciclos MDDI_Stb que ocurren con relación al reloj de datos del enlace inverso. El reloj de datos del enlace inverso es igual al reloj de datos del enlace directo dividido entre dos veces el Divisor de Velocidad Inversa. La velocidad de datos del enlace inverso está relacionada con el reloj de datos del enlace inverso y con el Tipo de Interfaz en el enlace inverso. Para una interfaz de Tipo 1, la velocidad de datos inversa es igual al reloj de datos del enlace inverso, para interfaces de Tipo 2, Tipo 3 y Tipo 4, las velocidades de datos inversas son iguales a dos veces, cuatro veces y ocho veces el reloj de datos del enlace inverso, respectivamente.

El campo Todos Ceros 1 contiene un grupo de bytes, aquí 8, que se fijan iguales a un valor cero, fijando los bits a un nivel de cero lógico, y se utiliza para garantizar que todas las señales MDDI_Data están en un nivel de cero lógico durante un tiempo suficiente para permitir que el cliente comience a recuperar el reloj, utilizando sólo MDDI_Stb antes de desactivar los controladores de línea del servidor durante el campo Giro 1. En una realización, la longitud del campo Todos Ceros 1 es mayor o igual que el número de tiempos de transmisión de bytes del enlace directo en el retardo de ida y vuelta del cable.

El campo Longitud de Giro 1 (1 byte) especifica el número total de bytes que están asignados para el Giro 1, estableciendo el primer periodo de giro. El número de bytes especificado por el parámetro Longitud de Giro 1 se adjudican para permitir que los controladores de línea de MDDI_Data en el cliente se activen antes de que los controladores de línea en el servidor se desactiven. El cliente activa sus controladores de línea MDDI_Data durante el bit 0 del Giro 1, y el servidor desactiva sus salidas para estar completamente desactivado antes del último bit del Giro 1. La temporización de la activación del controlador del cliente y la desactivación de los procesos del controlador del servidor es tal que uno, o ambos, alimentan las señales MDDI_Data a un nivel de cero lógico durante todo el Giro 1, como lo ven los receptores de línea en el servidor. La señal MDDI_Stb actúa como si MDDI_Data0 estuviera en un nivel de cero lógico durante todo el periodo Giro 1. Una descripción más completa de la configuración de Giro 1 se ha proporcionado anteriormente.

El campo Paquetes de Datos Inversos contiene una serie de paquetes de datos transferidos desde el cliente al servidor. El cliente puede enviar paquetes de relleno o alimenta las líneas MDDI_Data a un estado cero cuando no tiene datos para enviar al servidor. Si las líneas MDDI_Data se alimentan al cero, el servidor interpretará esto como un paquete de longitud cero (una longitud inválida) y el servidor no aceptará paquetes adicionales del cliente durante el actual Paquete de Encapsulación de Enlace Inverso.

El campo Longitud de Giro 2 (1 byte) especifica el número total de bytes que están asignados para el Giro 2, para establecer un segundo periodo de giro. El número de bytes especificado por el parámetro Longitud de Giro se asignan para permitir que los controladores de línea MDDI_Data en el servidor se activen antes de que los controladores de línea en el cliente se desactiven. El servidor activa sus controladores de línea MDDI_Data durante el bit 0 del primer byte en el Giro 2, y el cliente desactiva sus salidas, para que estén completamente desactivadas antes del último bit de Giro 2. La temporización de la desactivación del controlador del cliente y la activación de los procesos controladores del servidor es tal que uno o ambos alimentan las señales MDDI_Data a un nivel de cero lógico durante todo el periodo Giro 2, según lo ven los receptores de línea en el servidor. La señal MDDI_Stb actúa como si MDDI_Data0 estuviera en un nivel de cero lógico durante todo el periodo Giro 2. Una descripción de la configuración de Giro 2 se ha proporcionado anteriormente.

El campo Paquetes de Datos Inversos contiene una serie de paquetes de datos transferidos desde el cliente a un servidor. Como se ha afirmado anteriormente, los paquetes de Relleno se envían para llenar el espacio restante que no es utilizado por otros tipos de paquetes.

El campo Todos Ceros 2 contiene un grupo de bytes (8 en esta realización) que se fijan iguales a un valor cero, fijando los bits en un nivel de cero lógico, y se utiliza para garantizar que todas las señales MDDI_Data están en un nivel de cero lógico durante un tiempo suficiente para permitir que el cliente comience a recuperar el reloj, utilizando ambas líneas MDDI_Data0 y MDDI_Stb después de activar los controladores de línea del servidor a continuación del campo Giro 2.

F. Para Paquetes de Capacidad de Cliente

Como ilustra una realización, el campo Versión de Protocolo utiliza 2 bytes para especificar una versión de protocolo utilizada por el cliente. La versión inicial se fija igual a cero, mientras que el campo Versión Mínima de Protocolo utiliza 2 bytes para especificar la versión mínima del protocolo que el cliente puede emplear o interpretar. El campo Capacidad de Velocidad de Datos (2 bytes) especifica la máxima velocidad de datos que el cliente puede recibir por el enlace directo de la interfaz, y está especificado en forma de megabits por segundo (Mbps). El campo Capacidad de Tipo de Interfaz (1 byte) especifica los tipos de interfaz que disponen de soporte en los enlaces directo e inverso. Esto se indica actualmente seleccionando el Bit 0, el Bit 1 o el Bit 2 para seleccionar una modalidad de Tipo 2, Tipo 3 o Tipo 4, respectivamente, en el enlace directo; y el Bit 3, el Bit 4 o el Bit 5 para seleccionar una modalidad de Tipo 2, Tipo 3 o Tipo 4, respectivamente, en el enlace inverso; estando los Bits 6 y 7 reservados y fijados en cero. Los campos Ancho y Altura de Mapa de Bits (2 bytes) especifican, respectivamente, el ancho y la altura del mapa de bits, en píxeles.

El campo Capacidad Monocromática (1 byte) se utiliza para especificar el número de bits de resolución que pueden visualizarse en un formato monocromático. Si un visor no puede utilizar un formato monocromático, entonces este valor se fija en cero. Los Bits 7 a 4 se reservan para uso futuro y, por ello, se fijan en cero. Los Bits 3 a 0 definen el máximo número de bits de escala de grises que pueden existir para cada píxel. Estos cuatro bits hacen posible especificar valores de 1 a 15 para cada píxel. Si el valor es cero, entonces el formato monocromático no dispone de soporte en el visor.

El campo Capacidad Bayer utiliza 1 byte para especificar el número de bits de resolución, grupo de píxeles y orden de píxeles que pueden transferirse en formato Bayer. Si el cliente no puede utilizar el formato Bayer, entonces este valor es cero. El campo Capacidad Bayer se compone de los siguientes valores: los Bits 3 a 0 definen el número máximo de bits de intensidad que existe en cada píxel, mientras que los Bits 5 a 4 definen el patrón del grupo de píxeles que se requiere, mientras que los Bits 8 a 6 definen el orden de píxeles que se requiere; estando los Bits 14 a 9 reservados para uso futuro, y generalmente fijados en cero mientras tanto. El Bit 15, cuando está fijado en uno, indica que el cliente puede aceptar datos de píxeles Bayer en formato empaquetado o desempaquetado. Si el bit 15 está fijado en cero, esto indica que el cliente puede aceptar datos de píxeles Bayer sólo en formato desempaquetado.

El campo Capacidad de Mapa de Colores (3 bytes) especifica el número de elementos de tabla que existen en la tabla de mapa de colores en el visor. Si el visor no puede utilizar el formato de mapa de colores, entonces este valor se fija en cero.

El campo Capacidad RGB (2 bytes) especifica el número de bits de resolución que pueden visualizarse en formato RGB. Si el visor no puede utilizar el formato RGB, entonces este valor es igual a cero. La palabra de Capacidad RGB se compone de tres valores sin signo distintos, donde: los Bits 3 a 0 definen el número máximo de bits de azul, los Bits 7 a 4 definen el número máximo de bits de verde y los Bits 11 a 8 definen el número máximo de bits de rojo en cada píxel. Actualmente, los Bits 14 a 12 están reservados para uso futuro y se fijan generalmente en cero. Los Bits 14 a 12 están reservados para uso futuro y se fijan generalmente en cero. El Bit 15, cuando se fija en uno, indica que el cliente puede aceptar datos de píxeles de Mapa de Colores en formato empaquetado o desempaquetado. Si el bit 15 se fija en cero, esto indica que el cliente puede aceptar datos de píxeles de Mapa de Colores sólo en formato desempaquetado.

El campo Capacidad Y Cr Cb (2 bytes) especifica el número de bits de resolución que pueden visualizarse en formato Y Cr Cb. Si el visor no puede utilizar el formato Y Cr Cb, entonces este valor se fija igual a cero. La palabra de Capacidad Y Cr Cb está compuesta de tres valores sin signo distintos, donde: los Bits 3 a 0 definen el número máximo de bits en la muestra Cb, los Bits 7 a 4 definen el número máximo de bits en la muestra Cr, los Bits 11 a 8 definen el número máximo de bits en la muestra Y, y los Bits 15 a 12 están actualmente reservados para uso futuro y se fijan en cero.

El campo Capacidad de Característica de Cliente utiliza 4 bytes que contiene un conjunto de indicadores que indican características específicas en el visor que disponen de soporte. Un bit fijado a uno indica que la capacidad dispone de soporte y un bit fijado a cero indica que la capacidad no dispone de soporte. El valor para el Bit 0 indica si el Paquete de Transferencia de Bloques de Mapa de Bits (tipo de paquete 71) dispone o no de soporte. El valor para los Bits 1, 2 y 3 indica si el Paquete de Área de Mapa de Bits (tipo de paquete 72), el Paquete de Relleno de Patrón de Mapa de Bits (tipo de paquete 73), o el Paquete de Canal de Datos de Enlace de Comunicación (tipo de paquete 74), respectivamente, disponen o no de soporte. El valor para el Bit 4 indica si el cliente tiene o no la capacidad de hacer transparente un color, mientras que los valores para los Bits 5 y 6 indican si el cliente puede aceptar, respectivamente, datos de vídeo o datos de audio en formato empaquetado, y el valor para el Bit 7 indica si el cliente puede o no enviar un flujo de vídeo 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 píxel e ignorar el direccionamiento del visor, según lo especificado por el Bit 5 del campo Atributos de Datos de Píxeles del Paquete de Flujo de Vídeo, y si el cliente también puede detectar la sincronización de tramas o el fin de datos de tramas de vídeo mediante el bit 15 del campo de Atributos de Datos de Píxeles.

El valor para los Bits 11 y 12 indica cuándo el cliente está comunicándose, bien con un dispositivo puntero, y puede enviar y recibir Paquetes de Datos de Dispositivo Puntero, o bien 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 enviar uno o más parámetros de audio o vídeo prestando soporte a los paquetes de Característica VCP: Paquete de Solicitud de Característica VCP, Paquete de Respuesta de Característica VCP, Paquete de Fijación de Característica VCP, Paquete de Solicitud de Parámetro Válido y Paquete de Respuesta de Parámetro Válido. El valor para el Bit 14 indica si el cliente tiene o no la capacidad de escribir datos de píxeles en el almacén temporal de tramas de visor fuera de línea. Si este bit está fijado en un nivel de uno lógico, entonces los Bits de Actualización de Visor (bits 7 y 6 del campo Atributos de Datos de Píxeles del Paquete de Flujo de Vídeo) pueden fijarse en 01. El valor para el Bit 22 indica si el cliente tiene o no la capacidad de responder al Paquete de Acceso a Registro. Los Bits 9 a 10 y 23 a 31 están actualmente reservados para uso futuro, o asignaciones alternativas útiles para diseñadores de sistemas, y están generalmente fijados iguales a cero.

El campo Capacidad de Velocidad de Tramas de Vídeo del Visor (1 byte) especifica la máxima capacidad de actualización de tramas de vídeo del visor, en tramas por segundo. Un servidor puede escoger actualizar la imagen a una velocidad más lenta que el valor especificado en este campo.

El campo Profundidad de Almacén Temporal de Audio (2 bytes) especifica la profundidad del almacén temporal elástico en un Visor que está dedicado a cada flujo de audio.

El campo Capacidad de Canal de Audio (2 bytes) contiene un grupo de indicadores que indican qué canales de audio disponen de soporte por parte del visor (cliente). Un bit fijado en uno indica que el canal dispone de soporte, y un bit fijado en cero indica que el canal no dispone de soporte. Las posiciones de Bit se asignan a los distintos canales, por ejemplo, las posiciones de Bit 0, 1, 2, 3, 4, 5, 6 y 7 indican, respectivamente, los canales izquierdo frontal, derecho frontal, izquierdo trasero, derecho trasero, central frontal, de graves, izquierdo envolvente y derecho envolvente. Los Bits 8 a 15 están actualmente reservados para uso futuro, y se fijan generalmente en cero.

Un campo de Capacidad de Velocidad de Muestra de Audio, de 2 bytes, para el enlace directo, contiene un conjunto de indicadores para indicar la capacidad de velocidad de muestras de audio del dispositivo cliente. Las posiciones de bit se asignan de manera correspondiente a las distintas velocidades, tales como Bits 0, 1, 2, 3, 4, 5, 6, 7 y 8 asignados, respectivamente, a 8.000, 16.000, 24.000, 32.000, 40.000, 48.000, 11.025, 22.050 y 44.100 muestras por segundo (MPS), con los Bits 9 a 15 reservados para usos futuros o de velocidades alternativas, según se desee, por lo que actualmente están fijados en `0'. Fijar un valor de bit para uno de estos bits en `1' indica que esa velocidad de muestra específica dispone de soporte, y fijar el bit en `0' indica que esa velocidad de muestra no dispone de soporte.

El campo Velocidad Mínima de Subtrama (2 bytes) especifica la velocidad mínima de subtrama en tramas por segundo. La velocidad mínima de subtrama mantiene la velocidad de actualización del estado del visor suficiente para leer ciertos sensores o dispositivos punteros en el visor.

Un campo Capacidad de Velocidad de Muestra de Micrófono, de 2 bytes, para el enlace inverso, contiene un conjunto de indicadores que indican la capacidad de velocidad de muestra de audio de un micrófono en el dispositivo cliente. Para los fines de la MDDI, un dispositivo micrófono cliente está configurado para prestar soporte, mínimamente, a una velocidad al menos 8.000 muestras por segundo. Las posiciones de bit para este campo están asignadas a las distintas velocidades, con las posiciones de bit 0, 1, 2, 3, 4, 5, 6, 7 y 8, por ejemplo, utilizándose para representar, respectivamente, 8.000, 16.000, 24.000, 32.000, 40.000, 48.000, 11.025, 22.050 y 44.100 muestras por segundo (MPS), con los Bits 9 a 15 reservados para usos futuros o de velocidades alternativas, según se desee, por lo que actualmente se fijan en `0'. Fijar un valor de bit para uno de estos bits en `1' indica que esa velocidad específica de muestras dispone de soporte, y fijar el bit en `0' indica que esa velocidad de muestras no dispone de soporte. Si no está conectado ningún micrófono, entonces cada uno de los bits de Capacidad de Velocidad de Muestra de Micrófono se fija igual a cero.

El campo Tipo de Protección de Contenido (2 bytes) contiene un conjunto de indicadores que indican el tipo de protección de contenido digital que recibe soporte del Visor. Actualmente, la posición de bit 0 se utiliza para indicar cuándo DTCP dispone de soporte, y la posición de bit 1 se utiliza para indicar cuándo HDCP dispone de soporte, con las posiciones de bit 2 a 15 reservadas para su uso con otros esquemas de protección, según se desee o estén disponibles, por lo que actualmente se fijan en cero.

G. Para Paquetes de Solicitud y Estado de Cliente

El campo Solicitud de Enlace Inverso (3 bytes) especifica el número de bytes que el cliente necesita en el enlace inverso en la próxima subtrama para enviar información al servidor.

El campo Total Errores CRC (1 byte) indica cuántos errores de CRC han ocurrido desde el comienzo de la trama de medios. El total de CRC se reinicia cuando se envía un paquete de cabecera de subtrama con un Total de Subtrama igual a cero. Si el número efectivo de errores de CRC supera 255, entonces este valor, generalmente, se satura en 255.

El campo Cambio de Capacidad utiliza 1 byte para indicar un cambio en la capacidad del visor. Esto podría ocurrir si un usuario conecta un dispositivo periférico, tal como un micrófono, teclado o visor, o por algún otro motivo. Cuando los Bits [7:0] son iguales a 0, entonces la capacidad no ha cambiado desde que se envió el último Paquete de Capacidad de Cliente. Sin embargo, cuando los Bits [7:0] son iguales a un valor entre 1 y 255, la capacidad ha cambiado. El Paquete de Capacidad de Cliente es examinado para determinar las nuevas características del visor.

H. Para Paquetes de Transferencia de Bloques de Bits

Los campos Valor de Coordenada X y Coordenada Y de Ventana Superior Izquierda utilizan 2 bytes cada uno para especificar el valor de X e Y de las coordenadas de la esquina superior izquierda de la ventana a mover. Los campos Ancho y Altura de Ventana utilizan 2 bytes cada uno para especificar el ancho y altura de la ventana a mover. Los campos Movimiento X e Y de Ventana utilizan 2 bytes cada uno para especificar el número de pixeles en que la ventana debe moverse, respectivamente, horizontal y verticalmente. Típicamente, estas coordenadas se configuran de forma tal que los valores positivos para X causan que la ventana se mueva hacia la derecha, y los valores negativos causan movimiento hacia la izquierda, mientras que los valores positivos para Y causan 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 Valor X e Y de Coordenada de Ventana Superior Izquierda utilizan 2 bytes cada uno para especificar el valor de X e Y de las coordenadas de la esquina superior izquierda de la ventana a rellenar. Los campos Ancho y Altura de Ventana (2 bytes cada uno) especifican el ancho y altura de la ventana a rellenar. El campo Descriptor de Formato de Datos de Vídeo (2 bytes) especifica el formato del Valor de Relleno del Área de Píxeles. El formato es el mismo que el del mismo campo en el Paquete de Flujo de Vídeo. El campo Valor de Relleno de Área de Píxeles (4 bytes) contiene el valor de píxel a rellenar en la ventana especificada por los campos anteriormente expuestos. El formato de este píxel está especificado en el campo Descriptor de Formato de Datos de Vídeo.

J. Para Paquetes de Relleno de Patrón de Mapa de Bits

Los campos Valor de Coordenada X e Y de Ventana Superior Izquierda utilizan 2 bytes cada uno para especificar el valor de X e Y de las coordenadas de la esquina superior izquierda de la ventana a rellenar. Los campos Ancho y Altura de Ventana (2 bytes cada uno) especifican el ancho y la altura de la ventana a rellenar. Los campos Ancho de Patrón y Altura de Patrón (2 bytes cada uno) especifican, respectivamente, el ancho y la altura del patrón de relleno. El campo Descriptor de Formato de Datos de Vídeo, de 2 bytes, especifica el formato del valor de Relleno del Área de Píxeles. La Fig. 11 ilustra cómo se codifica el Descriptor de Formato de Datos de Vídeo. El formato es el mismo que el del mismo campo en el Paquete de Flujo de Vídeo.

El campo CRC de Parámetros (2 bytes) contiene un CRC de todos los bytes desde la Longitud de Paquete hasta el Descriptor de Formato de Vídeo. Si este CRC no confirma la comprobación, entonces se descarta el paquete entero. El campo Datos de Píxeles de Patrón contiene información de vídeo no procesado que especifica el patrón de relleno en el formato especificado por el Descriptor de Formato de Datos de Vídeo. Los datos se empaquetan en bytes, y el primer píxel de cada fila debe estar alineado por byte. Los datos del patrón de relleno se transmiten de una fila a la vez. El campo CRC de Datos de Píxeles de Patrón (2 bytes) contiene un CRC sólo de los Datos de Píxeles de Patrón. Si este CRC no confirma la comprobación, entonces los Datos de Píxeles de Patrón aún pueden utilizarse, pero el contador de errores de CRC se incrementa.

K. Paquetes de Canal de Datos de Enlace de Comunicación

El campo CRC de Parámetros (2 bytes) contiene un CRC de 16 bits de todos los bytes desde la Longitud de Paquete hasta el Tipo de Paquete. Si este CRC no confirma la comprobación, entonces se descarta el paquete entero.

El campo Datos de Enlace de Comunicación contiene los datos no procesados provenientes del canal de comunicación. Estos datos se pasan simplemente al dispositivo de cálculo en el visor.

El campo CRC de Datos de Enlace de Comunicación (2 bytes) contiene un CRC de 16 bits de sólo los Datos de Enlace de Comunicación. Si este CRC no confirma la comprobación, entonces los Datos de Enlace de Comunicación aún pueden utilizarse o ser útiles, pero el contador de errores de CRC se incrementa.

L. Para Paquetes de Solicitud de Traspaso de Tipo de Interfaz

El campo Tipo de Interfaz (1 byte) especifica el nuevo tipo de interfaz a utilizar. El valor en este campo especifica el tipo de interfaz de la siguiente manera. Si el valor en el Bit 7 es igual a `0', la solicitud de traspaso de Tipo es para el enlace directo; si es igual a `1', entonces la solicitud de traspaso de Tipo es para el enlace inverso. Los Bits 6 a 3 están reservados para uso futuro, y se fijan generalmente en cero. Los Bits 2 a 0 se utilizan para definir el Tipo de interfaz a utilizar, donde un valor de 1 significa un traspaso a la modalidad de Tipo 1, un valor de 2, un traspaso a la modalidad de Tipo 2, un valor de 3, un traspaso a la modalidad de Tipo 3, y un valor de 4, un traspaso a la modalidad de Tipo 4. Los valores de `0', y de 5 a 7 están reservados para la designación futura de modalidades alternativas, o combinaciones de modalidades.

M. Para Paquetes de Acuse de Recibo de Tipo de Interfaz

El campo Tipo de Interfaz (1 byte) tiene un valor que confirma el nuevo tipo de interfaz a utilizar. El valor en este campo especifica el tipo de interfaz de la siguiente manera. Si el Bit 7 es igual a `0', la solicitud de traspaso de Tipo es para el enlace directo; alternativamente, si es igual a `1', la solicitud de traspaso de Tipo es para el enlace inverso. Las posiciones de bit 6 a 3 están actualmente reservadas para su uso en la designación de otros tipos de traspaso, según se desee, y se fijan generalmente en cero. Sin embargo, las posiciones de bit 2 a 0 se utilizan para definir el Tipo de interfaz a utilizar, donde un valor de `0' indica un acuse de recibo negativo, o bien que el traspaso solicitado no puede realizarse; los valores de `1', `2', `3' y `4' indican, respectivamente, traspaso a modalidades de Tipo 1, Tipo 2, Tipo 3 y Tipo 4. Los valores de 5 a 7 están reservados para su uso con designaciones alternativas de modalidades, según se desee.

N. Para Paquetes de Ejecución de Traspaso de Tipo

El campo Tipo de Interfaz, de 1 byte, indica el nuevo tipo de interfaz a utilizar. El valor presente en este campo especifica el tipo de interfaz, utilizando, primero, el valor del Bit 7 para determinar si el traspaso de Tipo es para los enlaces directo o inverso. Un valor de `0' indica que la solicitud de traspaso de Tipo es para el enlace directo, y un valor de `1', para el enlace inverso. Los Bits 6 a 3 están reservados para uso futuro y, como tales, se fijan generalmente en un valor de cero. Sin embargo, los Bits 2 a 0 se utilizan para definir el Tipo de interfaz a utilizar, especificando los valores 1, 2, 3 y 4 el uso del traspaso al Tipo 1, Tipo 2, Tipo 3 y Tipo 4, respectivamente. El uso de los valores 0, y 5 a 7, para estos bits, está reservado para uso futuro.

O. Para Paquetes de Activación de Canal de Audio Directo

El campo Máscara de Activación de Canal de Audio (1 byte) contiene un grupo de indicadores que indican qué canales de audio han de activarse en un cliente. Un bit fijado en uno activa el canal correspondiente, y un bit fijado en cero desactiva el canal correspondiente. Los Bits 0 a 5 designan los canales 0 a 5, que se refieren, respectivamente, a los canales izquierdo frontal, derecho frontal, izquierdo trasero, derecho trasero, central frontal y de graves. Los Bits 6 y 7 están reservados para uso futuro, y mientras tanto se fijan generalmente iguales a cero.

P. Para Paquetes de Velocidad de Muestra de Audio Inverso

El campo Velocidad de Muestra de Audio (1 byte) especifica la velocidad de muestras de audio digital. Los valores para este campo se asignan a las distintas velocidades, con valores de 0, 1, 2, 3, 4, 5, 6, 7 y 8 utilizados para designar, respectivamente, 8.000, 16.000, 24.000, 32.000, 40.000, 48.000, 11.025, 22.050 y 44.100 muestras por segundo (MPS), estando los valores entre 9 y 254 reservados para su uso con velocidades alternativas, según se desee, por lo que actualmente se fijan en `0'. Un valor de 255 se utiliza para desactivar el flujo de audio de enlace inverso.

El campo Formato de Muestra (1 byte) especifica el formato de las muestras de audio digital. Cuando los Bits [1:0] son iguales a `0', las muestras de audio digital están en formato lineal; cuando son iguales a 1, las muestras de audio digital están en formato \mu-Law, y cuando son iguales a 2, las muestras de audio digital están en formato A-Law. Los Bits [7:2] están reservados para uso alternativo en la designación de formatos de audio, según se desee, y están generalmente fijados en cero.

Q. Para Paquetes de Sobrecarga de Protección de Contenido Digital

El campo Tipo de Protección de Contenido (1 byte) especifica el procedimiento de protección de contenido digital que se emplea. Un valor de `0' indica Protección de Contenido de Transmisión Digital (DTCP), mientras que un valor de 1 indica el Sistema de Protección de Contenido Digital de Alto Ancho de Banda (HDCP). La gama de valores entre 2 y 255 no está actualmente especificada, pero está reservada para su uso con esquemas de protección alternativos, según se desee. El campo Mensajes de Sobrecarga de Protección de Contenido es un campo de longitud variable que contiene mensajes de protección de contenido enviados entre el servidor y el cliente.

R. Para Paquetes de Activación de Color Transparente

El campo Activar Color Transparente (1 byte) especifica cuándo la modalidad de color transparente está activada o desactivada. Si el Bit 0 es igual a 0, entonces la modalidad de color transparente está desactivada; si es igual a 1, entonces la modalidad de color transparente está activada, y el color transparente se especifica mediante los dos parámetros siguientes. Los Bits 1 a 7 de este byte están reservados para uso futuro y son típicamente fijados iguales a cero.

El campo Descriptor de Formato de Datos de Vídeo (2 bytes) especifica el formato del Valor de Relleno del Área de Píxeles. La Fig. 11 ilustra cómo se codifica el Descriptor de Formato de Datos de Vídeo. El formato es generalmente el mismo que el del mismo campo en el Paquete de Flujo de Vídeo.

El campo Valor de Relleno del Área de Píxeles utiliza 4 bytes asignados al valor de píxel para rellenar la ventana especificada anteriormente. El formato de este píxel se especifica en el campo Descriptor de Formato de Datos de Vídeo.

S. Para Paquetes de Medición de Retardo de Ida y Vuelta

El campo 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 realización, se selecciona que tenga una longitud fija de 159. El campo Tipo de Paquete, de 2 bytes, 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 Identificador de hCliente, como antes, está reservado para uso futuro como Identificador de Cliente, y se fija generalmente en cero.

En una realización, el campo CRC de Parámetros (2 bytes) contiene un CRC de 16 bits de todos los bytes desde la Longitud de Paquete hasta el Tipo de Paquete. Si este CRC no confirma la comprobación, entonces se descarte el paquete entero.

El campo Tiempo de Guardia 1 (aquí, 64 bytes) se utiliza para permitir que los controladores de línea MDDI_Data en el cliente se activen antes de que los controladores de línea en el servidor se desactiven. El cliente activa sus controladores de línea MDDI_Data durante el bit 0 del Tiempo de Guardia 1, y el servidor desactiva sus controladores de línea para que estén completamente desactivados antes del último bit de Tiempo de Guardia 1. Tanto el servidor como el cliente alimentan a un nivel de cero lógico durante el Tiempo de Guardia 1, cuando no están desactivados. Otro fin de este campo es garantizar que todas las señales MDDI_Data estén en un nivel de cero lógico por un tiempo suficiente para permitir que el cliente comience a recuperar un reloj o una señal de reloj, utilizando sólo MDDI_Stb, antes de desactivar los controladores de línea del servidor.

El campo Periodo de Medición es una ventana de 64 bytes utilizada para permitir que el cliente responda con dos bytes de 0xff, y 30 bytes de 0x0, a la mitad de la velocidad de datos utilizada en el enlace directo. Esta velocidad de datos corresponde a un Divisor de Velocidad de Enlace Inverso igual a 1. El cliente devuelve esta respuesta inmediatamente en el momento en que percibe el comienzo del Periodo de Medición. Esta respuesta desde el cliente será recibida en un servidor, precisamente cuando hayan transcurrido el retardo de ida y vuelta del enlace más el retardo lógico en el cliente, después del comienzo del primer bit del Periodo de Medición en el servidor.

El campo Todos Ceros (2 bytes) contiene ceros para permitir que los controladores de línea MDDI_Data en el servidor y en el cliente se solapen de forma que MDDI_Data esté siempre alimentado. El servidor activa los controladores de línea MDDI_Data durante el bit 0 del Tiempo de Guardia 2, y el cliente también alimenta la señal a un nivel de cero lógico, como lo hizo al final del Periodo de Medición.

El valor en el campo Tiempo de Guardia 2 (64 bytes) permite el solapamiento del Periodo de Medición alimentado por el cliente, cuando el retardo de ida y vuelta está en la magnitud máxima que pueda medirse en el Periodo de Medición. El cliente desactiva sus controladores de línea durante el bit 0 del Tiempo de Guardia 2, y el Servidor activa sus controladores de línea inmediatamente después del último bit de Tiempo de Guardia 2. Tanto el servidor como el cliente alimentan a un nivel de cero lógico durante el Tiempo de Guardia 2, cuando no están desactivados. Otro fin de este campo es garantizar que todas las señales MDDI_Data están en un nivel de cero lógico por un tiempo suficiente para permitir que el cliente comience a recuperar una señal de reloj utilizando tanto MDDI_Data0 como MDDI_Stb, después de activar los controladores de línea para un servidor.

T. Para los Paquetes de Calibración de Sesgo de Enlace Directo

En una realización, el campo CRC de Parámetros (2 bytes) contiene un CRC de 16 bits de todos los bytes desde la Longitud de Paquete hasta el Tipo de Paquete. Si este CRC no confirma la comprobación, entonces se descarta el paquete entero.

La Secuencia de Datos de Calibración contiene una secuencia de datos de 512 bytes que causa que las señales MDDI_Data alternen sus valores cada periodo de datos. Durante el procesamiento de la Secuencia de Datos de Calibración, el controlador de MDDI del servidor fija todas las señales MDDI_Data iguales a la señal de sondeo. El circuito de recuperación del reloj del visor debería utilizar sólo MDDI-Stb, en lugar de MDDI-Stb Xo MDDI-Data0, para recuperar el reloj de datos, mientras el campo de Secuencia de Datos de Calibración está siendo recibido por el Visor cliente. Según la fase exacta de la señal MDDI_Stb al comienzo del campo de Secuencia de Datos de Calibración, la Secuencia de Datos de Calibración será generalmente una de las siguientes, sobre la base del Tipo de interfaz utilizada cuando se envía este paquete:

Tipo I - 0xaa, 0xaa ... ó 0x55, 0x55...

Tipo II - 0xcc, 0xcc ... ó 0x33, 0x33...

Tipo III - 0xf0, 0xf0 ... ó 0x0f, 0x0f ...

Tipo IV - 0xff, 0x00, 0xff, 0x00 ... ó 0x00, 0xff, 0x00, 0xff ...

\vskip1.000000\baselineskip

Un ejemplo de las posibles ondas de MDDI_Data y MDDI_Stb para ambas Interfaces de Tipo 1 y Tipo 2 se muestran, respectivamente, en las Figs. 62A y 62B.

XVII. Conclusión

Si bien se han descrito anteriormente diversas realizaciones de la presente invención, debería entenderse que han sido presentadas sólo a modo de ejemplo, y no de limitación. Así, la amplitud y el alcance de la presente invención no debería estar limitada por ninguna de las realizaciones ejemplares anteriormente descritas, sino que deberían definirse sólo de acuerdo a las siguientes reivindicaciones y sus equivalentes.

Claims (12)

1. Un procedimiento para que un cliente comunique a un servidor una selección de una velocidad inválida de datos de muestreo para un flujo de datos de audio inverso en un sistema de comunicaciones de interfaz digital de visualización móvil MDDI, comprendiendo el procedimiento las etapas de:

\quad

enviar un paquete de encapsulamiento inverso desde el servidor al cliente;

\quad

enviar un paquete de informe de error desde el cliente al servidor, comprendiendo el paquete de informe de error un indicador de que el cliente no brinda soporte a la velocidad de datos de muestreo inválida;

\quad

solicitar un paquete de capacidad de cliente por parte del servidor, comprendiendo una solicitud de datos de soporte de flujo de audio; y

\quad

enviar el paquete de capacidad de cliente al servidor, comprendiendo el paquete de capacidad de cliente los datos de soporte de flujo de audio.

\vskip1.000000\baselineskip

2. El procedimiento de la reivindicación 1, en el que los datos de soporte de flujo de audio comprenden un indicador de que el cliente no brinda soporte al flujo de datos de audio inverso.

3. El procedimiento de la reivindicación 1, en el que los datos de soporte de flujo de audio comprenden un indicador de que el cliente brinda soporte al menos a una velocidad de datos.

4. El procedimiento de la reivindicación 3, comprendiendo adicionalmente la etapa del servidor seleccionando una velocidad de datos operativa desde al menos esa velocidad de datos.

5. Un sistema para que un cliente comunique a un servidor una selección de una velocidad inválida de datos de muestra para un flujo de datos de audio inverso en un sistema de comunicaciones de una interfaz digital de visualización móvil MDDI, comprendiendo el sistema:

\quad

un medio para enviar un paquete de encapsulamiento inverso desde el servidor al cliente;

\quad

un medio para enviar un paquete de informe de error desde el cliente al servidor, comprendiendo el paquete de informe de error un indicador de que el cliente no brinda soporte a la velocidad inválida de datos de muestreo;

\quad

un medio para solicitar un paquete de capacidad de cliente por parte del servidor, comprendiendo una petición de datos de soporte de flujo de audio; y

\quad

un medio para enviar el paquete de capacidad de cliente al servidor, comprendiendo el paquete de capacidad de cliente los datos de soporte de flujo de audio.

\vskip1.000000\baselineskip

6. El sistema de la reivindicación 5, en el que los datos de soporte de flujo de audio comprenden un indicador de que el cliente no brinda soporte al flujo de datos de audio inverso.

7. El sistema de la reivindicación 5, en el que los datos de soporte de flujo de audio comprenden un indicador de que el cliente brinda soporte a al menos una velocidad de datos.

8. El sistema de la reivindicación 7, comprendiendo adicionalmente un medio para seleccionar una velocidad de datos operativa de al menos esa velocidad de datos por parte del servidor.

9. Un producto de programa de ordenador, que comprende:

\quad

un medio legible por un ordenador que comprende:

\quad

un código para provocar que un cliente comunique a un servidor una selección de una velocidad inválida de datos de muestra para un flujo de datos de audio inverso en un sistema de comunicaciones de interfaz digital de visualización móvil MDDI, comprendiendo el producto de ordenador:

\quad

un código para provocar el envío de un paquete de encapsulación inverso desde el servidor al cliente;

\quad

un código para provocar el envío de un paquete de informe de error desde el cliente al servidor, comprendiendo el paquete de informe de error un indicador de que el cliente no brinda soporte a la velocidad inválida de datos de muestra;

\quad

un código para provocar que un paquete de capacidad de cliente sea solicitado por el servidor, comprendiendo una petición de datos de soporte de flujo de audio; y

\quad

un código para provocar que el paquete de capacidad de cliente sea enviado al servidor, comprendiendo el paquete de capacidad de cliente los datos de soporte de flujo de audio.

\vskip1.000000\baselineskip

10. El producto de programa de ordenador de la reivindicación 9, en el que los datos de soporte de flujo de audio comprenden un indicador de que el cliente no brinda soporte al flujo de datos de audio inverso.

11. El producto de programa de ordenador de la reivindicación 9, en el que los datos de soporte de flujo de audio comprenden un indicador de que el cliente brinda soporte a al menos una velocidad de datos.

12. El producto de programa de ordenador de la reivindicación 11, comprendiendo adicionalmente un código para provocar que el servidor seleccione una velocidad de datos operativa de al menos esa velocidad de datos.