Ronald Caravaca. A91329

Maikel Fernández. 985114

Descripción:

El proyecto consiste en crear un módulo para el kernel de Linux que inserte un controlador para un dispositivo de adquisición de video (easycap). La primera parte del proyecto consiste en investigar sobre el funcionamiento de kernel de Linux como mediador entre el hardware y el espacio de usuario, además sobre la programación de drivers de video. Entender cómo funciona un driver externo al kernel, instalarlo y verificar su funcionamiento con el easycap.

Objetivo general:

Estudiar y desarrollar un módulo para el kernel de Linux que controle un dipositivo de adquisición de video (easycap) a partir de un driver prototipo.

Objetivos específicos:

1. Estudiar sobre el funcionamiento de drivers de video escritos en C para Linux.
2. Estudiar cómo funcionan los drivers del kernel en general a través de un bus usb utilizando la librería video for linux (v4l).
3. Instalar Debian en una máquina virtual con soporte para usb 2.0.
4. Puesta en funcionamiento del esaycap, el userspace actual. (Instalar el loopback device).

Justificación:

En este proyecto se aplican los conocimientos obtenidos en el curso de programación bajo plataformas abiertas sobre el manejo del kernel de linux como plataforma de desarrollo junto con su administración, el funcionamiento del kernel de Linux como controlador y administrador de dispositivos de hardware, programar drivers de dispositivos que trabajen a través de un bus usb y el uso del lenguaje de programación C. Además, en el mercado existen cuatro dispositivos de adquisición de video, pero sólo tres tienen soporte para el kernel de linux y la unidad que nos concierne únicamente cuenta con soporte para el espacio de usuario. Es importante que exista un controlador escrito en lenguaje C, que brinde soporte para el kernel de linux, lo que implementaría un mejor manejo de los recursos del sistema.

Metodología:

• La metodología a utilizar en la realización de los objetivos 2 y 3 de este proyecto, además de buscar en internet las fuentes necesarias para obtener la
• información solicitada.
• Para el objetivo 4 se instalara Debian en una máquina virtual utilizando virtualbox.
• Para el primer objetivo se instalara el driver creado por el profesor en Debian y se pondrá en funcionamiento.
• Para la segunda parte se procederá a programar en el lenguage estructurado C el controlandor para el easycap.

Los dispositivos USB pueden ser hubs (elementos) que provean puntos de conexión adicionales a los existentes en el host, o bien diferentes dispositivos típicos periféricos.

En un bus USB existen dos tipos de elementos: Anfitrión (host) y dispositivos.

El anfitrión o “host”: El Bus Serial Universal es controlado por un anfitrión (host). Solo puede haber un anfitrión por bus. La especificación en sí misma no soporta ninguna forma de arreglo multimaestro. Sin embargo la especificación On-The-Go, la cual es un estándar suplementario al USB 2.0, ha introducido el Protocolo de Negociación de Host el cual permite a dos dispositivos negociar el papel de anfitrión. Esto está enfocado hacia, y limitado a, conexiones individuales punto a punto tales como teléfonos móviles y agendas electrónicas, y no a configuraciones de hubs múltiples/dispositivos múltiples. El anfitrión USB es responsable de emprender todas las acciones y de fijar (schedule) el ancho de banda. Los datos pueden enviarse por varios métodos de transacción usando un protocolo basado en tokens. Su implementación es una combinación de hardware y software todo en uno, es decir firmware.

El host es responsable al nivel de hardware, de los siguientes aspectos dentro del sistema UBS:

1. Detectar tanto la conexión de nuevos dispositivos USB al sistema como la atención de aquellos ya conectados, y por supuesto, configurarlos y ponerlos a disposición del usuario, tarea que involucra acciones por software.
2. Administrar y controlar el flujo de datos entre el host y los dispositivos USB, es decir el movimiento de información generada por el usuario mismo.
3. Administrar y regular los flujos de control entre el host y los dispositivos USB, es decir la información que se mueve con el objeto de mantener el orden dentro de los elementos del sistema.
4. Recolectar y resumir estadísticas de actividad y estados de los elementos del sistema.
5. Proveer de una cantidad limitada de energía eléctrica para aquellos dispositivos que pueden abastecerse con tan solo la energía eléctrica proveniente desde el ordenador (el teclado y el ratón son dos ejemplos claros)

Por otra parte, al nivel de software las funciones del Controlador de Host se incrementan y complican:

1. Enumeración y configuración de los dispositivos conectados al sistema.
2. Administración y control de transferencias isocrónicas de información.
3. Administración y control de transferencias asincrónicas.
4. Administración avanzada de suministro eléctrico a los diferentes dispositivos.
5. Administración de la información del bus y los dispositivos USB.

Los concentradores (“Hubs”): Bajo una óptica eléctrica y teleinformática, los hubs son concentradores cableados que permiten múltiples conexiones simultáneas. Su aspecto más interesante es la concatenación, función por la que a un hub se puede conectar otro y otro, ampliando la cantidad de puertos disponibles para periféricos.

Periféricos: USB soporta periféricos de baja y media velocidad. Empleando dos velocidades para la transmisión de da tos de 1.5 y 12 Mbps se consigue una utilización más eficiente de sus recursos. Los periféricos de baja velocidad tales como teclados, ratones, joysticks, y otros periféricos para juegos, no requieren 12 Mbps. Empleando para ellos 1.5 Mbps, se puede dedicar más recursos del sistema a periféricos tales como monitores, impresoras, modems, scanners, equipos de audio, etc, que precisan de velocidades más altas para transmitir mayor volumen de datos o datos cuya dependencia temporal es más estricta.

La forma en estrella por niveles permite:

1. Que la alimentación a cada dispositivo pueda monitorearse e incluso apagarse si una condición de sobrecarga de corriente ocurre sin interrumpir otros dispositivos USB.
2. Tanto dispositivos de velocidad alta, completa y baja pueden ser soportados, haciendo que el hub filtre transacciones de velocidad alta y completa para que los dispositivos de menor velocidad no las reciban.

Conectores:

Velocidades: Alta Velocidad - 480Mbits/s Velocidad Completa - 12Mbits/s Baja Velocidad - 1.5Mbits/s

Un dispositivo USB debe indicar su velocidad al poner ya sea la línea D+ o D- en alto a 3.3 voltios. Un dispositivo de velocidad completa, ilustrado abajo, usará una resistencia pull up unida a D+ para especificarse a sí mismo como un dispositivo de velocidad completa. Estas resistencias pull up al lado del dispositivo también se usarán por el anfitrión o hub para detectar la presencia de un dispositivo conectado a su puerto. Sin una resistencia pull up, el USB asume que no hay nada conectado al bus. Algunos dispositivos tienen esta resistencia integrada en su silicio, la cual puede ser activada o desactivada bajo el control del firmware; otros requieren una resistencia externa.

Paquetes USB

Los datos en el bus USB transmiten primero el bit LSB (el de menor peso o Least Significant Bit). Los paquetes USB consisten de los siguientes campos:

• Sync

Todos los paquetes deben comenzar con un campo Sync. El campo Sync tiene 8 bits de longitud en baja velocidad o velocidad completa, o 32 bits de longitud para alta velocidad y se usa para sincronizar el reloj del receptor con el del transmisor. Los últimos dos bits indican dónde comienzan los campos PID.

• PID

PID significa Packet ID, o IDentificación de Paquete. Este campo se usa para identificar el tipo de paquete que se está enviando. La siguiente tabla muestra los valores posibles:

• ADDR

El campo de dirección especifica para cuál dispositivo está designado el paquete. Teniendo una longitud de 7 bits, permite soportar 127 dispositivos. La dirección 0 no es válida, ya que cada dispositivo que todavía no tiene una dirección asignada debe responder a los paquetes enviados a la dirección 0.

• ENDP

El campo de punto final (endpoint) está conformado de 4 bits, permitiendo 16 posibles puntos finales.

• CRC

Se efectúan Chequeos de Redundancia Cíclica en los datos dentro de la carga útil (payload) del paquete. Todos los paquetes de token tienen un CRC de 5 bits mientras que los paquetes de datos tienen un CRC de 16 bits.

• EOP

Fin del Paquete (End Of Packet). Señalado por un Cero Terminado Individualmente (Single Ended Zero o SE0 por aproximadamente el tiempo de 2 bits seguido por una J por el tiempo de un bit).

El primer campo de todo paquete de datos es el campo PID. El PID indica el tipo de paquete y por lo tanto, el formato del paquete y el tipo de detección de errores aplicado al paquete. En función de su PID podemos agrupar los diferentes tipos de paquetes en cuatro clases:

Tipos de paquetes:

Paquetes de Token.

Hay tres tipos de paquetes de token: In (Dentro) — Informan al dispositivo USB de que el anfitrión (host) desea leer información. Out (Fuera) — Informan al dispositivo USB de que el anfitrión (host) desea enviar información. Setup — Usado para iniciar transferencias de control.

Los paquetes de token deben apegarse al siguiente formato:

Sync | PID | ADDR | ENDP | CRC5 | EOP

Paquetes de Datos (DATA). Hay dos tipos de paquetes de datos, cada uno capaz de transmitir hasta 1024 bytes de datos: DATA0, DATA1.

El modo de alta velocidad define otros dos PIDs de datos, DATA2 y MDATA. Los paquetes de datos tienen el siguiente formato:

Sync | PID | Data | CRC5 | EOP

Paquetes de Saludo (Handshake) Hay tres tipos de paquetes de handshake que consisten simplemente del PID:

• ACK — Reconocimiento de que el paquete ha sido recibido exitosamente.
• NAK — Reporta que el dispositivo no puede temporalmente enviar o recibir datos. También usado durante transacciones de interrupción para informarle al anfitrión que no hay datos que enviar.
• STALL — El dispositivo encuentra que está en un estado que requiere intervención del anfitrión.
• NYET, Significa “Not YET” (todavía no), y se emplea en los protocolos Split y de control de flujo PING. Solo en alta velocidad.
• ERR: De nuevo sólo disponible en alta velocidad y de nuevo formando parte del protocolo PING, permite a un hub de alta velocidad indicar que se ha producido un error en un bus de media o baja velocidad.

Los paquetes de handshake tienen el siguiente formato:

Sync | PID | Data

Paquete inicio de frame (SOF)

Estos paquetes son generados por el host cada un milisegundo en buses de velocidad media y cada 125 microsegundos para velocidad alta. Este paquete está compuesto por un campo número de frame y un campo de CRC de 5 bits.

Sync | PID | Numero frame | CRC5 | EOP

Endpoints y direcciones de dispositivo:

Cada dispositivo USB está compuesto por una colección de endpoints independientes, y una dirección única asignada por el sistema en tiempo de conexión de forma dinámica. A su vez cada endpoint dispone de un identificador único dentro del dispositivo al que pertenece, a este identificador se le conoce como número de endpoint y viene asignado de fábrica. Cada endpoint tiene una determinada orientación de flujo de datos. La combinación de dirección, número de endpoint y orientación, permite referenciar cada endpoint de forma inequívoca. Cada endpoint es por si solo una conexión simple que soporta un flujo de datos en una única dirección, bien de entrada o bien de salida. Cada endpoint se caracteriza por:

• Frecuencia de acceso al bus requerida
• Ancho de banda requerido
• Número de endpoint
• Tratamiento de errores requerido
• Máximo tamaño de paquete que el endpoint puede enviar o recibir
• Tipo de transferencia para el endpoint
• La orientación en la que se transmiten los datos

Existen dos endpoints especiales que todos los dispositivos deben tener, los endpoints con número 0 de entrada y de salida, que deben de implementar un método de control por defecto al que se le asocia la tubería de control por defecto. Estos endpoints están siempre accesibles mientras que el resto no lo estarán hasta que no hayan sido configurados por el host.

Pipe (tubería)

Mientras que el dispositivo envía y recibe datos en una serie de puntos finales (endpoints), el software cliente transfiere datos a través de tuberías (pipes). Una tubería es una conexión lógica entre el anfitrión y el o los puntos finales. Las tuberías también tienen un conjunto de parámetros asociados con estos, tales como cuánto ancho de banda se ha reservado para este, qué tipo de transferencia usa (Control, Bulto/Bulk, Isócrona o Interrupción), una dirección de flujo de datos y tamaños máximos de paquete/buffer. Por ejemplo la tubería por defecto es una tubería bidireccional hecha del punto final cero in (endpoint zero in) y el punto final cero out (endpoint zero out) con un tipo de transferencia de control.

- Pipes de Flujo (Stream). No tienen un formato USB definido; eso significa que puede enviar cualquier tipo de datos por una tubería de flujo y puede recuperar los datos en el otro extremo. Los datos fluyen secuencialmente y tienen una dirección predefinida, ya sea dentro (in) o fuera (out). Las tuberías de flujo soportarán tipos de transferencia de bulto, isócronas y de interrupción. Las tuberías de flujo pueden controlarse ya sea por el anfitrión o el dispositivo.

- Pipes de Mensajes. Tienen un formato USB definido. Son controladas por el anfitrión, y las cuales son iniciadas por una petición enviada desde el anfitrión. Los datos son luego transferidos en la dirección deseada, dictada por la petición. Por eso, las tuberías de mensajes permiten a los datos fluír en ambas direcciones pero solo soportarán transferencias de control.

Tipos de transferecia

El enlace virtual (pipe) puede ser de cuatro tipos:

- Control: Modo utilizado para realizar configuraciones: Existe siempre sobre el Punto terminal 0 (EndPoint 0). Todos los dispositivos USB deben soportar este tipo de transferencia. Los datos de control sirven para configurar el periférico en el momento de conectarse al USB. Algunos drivers específicos pueden utilizar este enlace para transmitir su propia información de control. Este enlace no tiene pérdida de datos, puesto que los dispositivos de detección de recuperación de errores están activos a nivel USB.

- Bulk: Este modo se utiliza para la transmisión de importantes cantidades de información. Como el tipo control, este enlace no tiene pérdida de datos. Este tipo de transferencia es útil cuando la razón de transferencia no es critica como por ejemplo , el envió de un archivo a imprimir o la recepción de datos desde un escáner. En estas aplicaciones, la transferencia es rápida, pero puede espera r si fuera necesario. Solo los dispositivos de media y alta velocidad utilizan este tipo de transferencia.

- Interrupt: Modo utilizado para transmisiones de pequeños paquetes, rápidos, orientados a percepciones humanas (ratón, punteros). Este tipo de transferencia son para dispositivos que deben recibir atención periódicamente y lo utilizan los dispositivos de baja velocidad . Este tipo de transmisión garantiza la transferencia de pequeñas cantidades de datos. El tiempo de respuesta no puede ser inferior al valor especificado por la interfaz. El ratón o cualquier otro dispositivo apuntador es una aplicación típica de este modo de transmisión.

- Isochronous o Flujo en tiempo real: Modo utilizado para la transmisión de audio o video comprimido. Este tipo de transmisión funciona en tiempo real. Este es el modo de mayor prioridad. La transmisión de la voz es un ejemplo de esta aplicación. Si ésta no se transmite correctamente, pueden llegar a oírse parásitos (glich) y la aplicación puede detectar ciertos errores de los llamados underruns

Proceso de Enumeración:

Esta fase se produce cuando el dispositivo es conectado al Bus y después de la fase de Bus Reset. El host debe reunir la información necesaria para que el sistema identifique al dispositivo y configure el tipo de comunicación que se producirá entr e ambos y encuentre al driver que tiene que utilizar para establecer la comunicación. El proceso consiste primero, en asignar una dirección al device y segundo, el host envía una serie de peticiones para que el dispositivo mande información con el fin de e stablecer la comunicación. La información que debe mandar el dispositivo se estructura en registros o descriptores que configuran al dipositivo y son transmitidos mediante transferencia de control y siempre por el endpoint 0.

Estos descriptores son los siguientes:

1. Device descriptor : contiene información básica del dispositivo como puede ser número de serie, clase de dispositivo, etc.
2. Configuración descriptor: contiene información sobre las capacidades y funciones del dispositivo, tipo de alimentación de energía que soporta..
3. Interface descriptor: contiene información sobre el número de endpoints que soporta y el protocolo utilizado.
4. Class descriptor : determina la clase del dispositivo.
5. Endpoint descriptor: excepto para el endpoint 0, cada endpoint debe ser configurado. La cofiguración de cada endpoint consiste en el número de endpoint, dirección de sus comunicaciones (IN, OUT) y numero de bytes que transmite.

Con esto el host le asigna una dirección al dispositivo adjuntado al bus y habilita su configuración permitiendo la transferencia de datos sobre el bus.

• Si no tiene instalado Git haga:

apt-get install git 

• Ahora se instalara V4L2 loopback devices

git clone git://github.com/umlaeute/v4l2loopback.git
cd v4l2loopback/
make

Haciendo ls deberíamos observar un archivo llamado “v4l2loopback.ko” el cual es el modulo.

• Luego hacemos:

sudo make install 

lo cual instalara el modulo.

• Ahora instalamos las dependencias…

para numpy:

sudo apt-get install numpy

para libusb1:

git clone git://github.com/vpelletier/python-libusb1.git 
cd python-libusb1/
sudo python setup.py install

para v4l2: descargar el archivo de http://staff.science.uva.nl/~bterwijn/Projects/V4L2/, luego:

cd v4l2-0.2/
sudo python setup.py install

• Ahora cargamos el modulo v4l2loopback

sudo modprobe v4l2loopback

• y desde el directorio usbtv007 hacemos:

sudo ./utv007_driver.py -d /dev/video1 (puede que sea /dev/video0, depende de su computadora)