plataforma de adquisici on de v deo con salida hdmi sobre...

Plataforma de adquisicion de vıdeo con salida HDMI sobre un

SoPC con Linux embebido

Directores:Jose Andres OteroLeonardo Suriano

Autor:Jaime Cernuda Garcıa

2018Febrero

Plataforma de adquisicion de vıdeo con salida HDMI sobre un SoPC con Linux embebido

2

Capıtulo 1

Resumen

El actual trabajo de fin de grado aborda el diseno, desarrollo y testeo de un sistema de capturasimultanea de imagenes desde multiples camaras, con salida HDMI, sobre un SoPC (”System onProgrammable Chip”) con Linux embebido. Su objetivo final es que sirva como base para el desa-rrollo de futuros trabajos de captacion y procesado de entornos 3D mediante vision estereoscopica.

El trabajo ha sido realizado en el Centro de Electronica Industrial de la Escuela Tecnica Superiorde Ingenieros Industriales de la Universidad Politecnica de Madrid. Este centro dispone de unagran experiencia previa en el desarrollo de proyectos de hardware con la tecnologıa de FPGAs engeneral, y de SoPCs en particular.

El trabajo surge en un contexto de gran auge de la vision por ordenador y el desarrollo de siste-mas sobre sobre hardware reconfigurable (FPGAs). Tradicionalmente, los algoritmos de vision porcomputador, de gran complejidad computacional y por lo tanto necesitados de una gran potencia decomputo, han sido desarrollados mediante soluciones basadas puramente en software. Sin embargo,la demanda creciente de proyectos basados en vision por ordenador que necesitan plataformas dedesarrollo mas rapidas y robustas, ha llevado a este campo a buscar soluciones basadas en hardware,y en nuestro caso, en la tecnologıa SoPC de Xilinx.

La tecnologıa SoPC Zynq unifica lo mejor del software y el hardware, proveyendo de un micro-procesador conectado a una FPGA, permitiendo desarrollar el control de la aplicacion en software,de menor requerimiento tecnico y precio, y que este software interactue con el hardware para elprocesamiento de las partes criticas del proyecto.

La implementacion que se ha usado de la tecnologıa SoPC Zynq en este proyecto es la PYNQ-Z1de Diligent. La placa PYNQ-Z1 esta basada en el chip ZYNQ XC7Z020-1CLG400C de Xilinx, quecontiene un procesador Cortex-A9 de doble nucleo y una FPGA de la familia Artix-7 junto con elsistema de comunicacion entre ambos, la conexion a perifericos y memoria RAM.

3


El proyecto queda claramente dividido en dos segmentos, el desarrollo de software y el desarrollode hardware. Esta division queda en linea con la metodologıa de trabajo propia de los dispositivosSoPC, donde un equipo de ingenieros especializados en hardware trabaja a la par con ingenierosespecializados en software.

A continuacion, se puede observar la estructura basica del proyecto:

Inicio. CamarasSoftware:

Captura de video

Software: Driver.InteraccionSoftware-Hardware

Hardware: re-cepcion de video

Hardware:Futures proyectos

Hardware: HDMIFin. Monitor

A nivel de software, el proyecto consta de dos programas:

El primero de ellos, es el encargado de controlar y configurar las dos camaras ethernet co-nectadas a la placa y de recibir y preparar el vıdeo recibido por ellas. Para ello, hara uso delas librerıas proveıdas por los desarrolladores de las camaras. Y acabara dejando los framesde vıdeo de cada camara en un frambuffer, una coleccion de posiciones de memoria donde sealmacenan en serie un numero de frames de vıdeo.

El segundo programa, es el encargado de funcionar como interfaz entre los framebuffers,situados en la memoria del microprocesador y la FPGA. Para ello, actuara como un driver(del ”user-space”, no del ”kernel-space”) y hara uso de las librerıas propias de Linux quepermiten interactuar con el microprocesador a bajo nivel. Ademas de esto, sera el encargadode configurar e inicializar el hardware y controlarlo a lo largo del proceso.

A nivel de hardware, el sistema desarrollado lee la informacion proveıda por el driver y la envıa alhardware mediante el protocolo AXI, un protocolo de bus de comunicaciones estandar desarrolladopor ARM y ampliamente usado en los SoPC de Xilinx. El uso de este protocolo permite que cualquierimplementacion de hardware desarrollado en el futuro pueda ser conectado a continuacion de lalectura de datos y por lo tanto, disponga de acceso completo a los frames de vıdeo. Adicionalmente,ha sido desarrollado un convertidor y controlador de senales HDMI. Este controlador permite enviarla informacion procesada por el hardware directamente a cualquier dispositivo compatible conHDMI, ya que ha sido desarrollado para que pueda adaptarse dinamicamente en resolucion aldispositivo deseado.

Tras la finalizacion del proyecto, se ha llegado a alcanzar el completo desarrollo y testeo tanto delhardware como de la primera aplicacion de software. Sin embargo, el desarrollo del driver resulto masarduo de lo esperado y aunque se completo su desarrollo, las limitaciones temporales del proyectohan impedido su testeo y la implementacion final de su interaccion con los otros dos elementos delproyecto.

4

Jaime Cernuda Garcıa

Respecto al futuro del proyecto se ofrecera la posibilidad a otros alumnos desarrollando su TFG,de desarrollar bloques de hardware especializados en el tratamiento de imagenes los cuales, secomuniquen mediante el protocolo AXI y por lo tanto, puedan ser integrados facilmente en elproyecto. Se dispone ası, de una interfaz comun a todos los proyectos otorgandoles la opcion devisualizar sus resultados en un monitor y evitando que sea necesario el desarrollo desde cero delsistema de comunicacion con las camaras.

5


6

Indice general

1. Resumen 3

2. Introduccion 112.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3. Marco Teorico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1. La PYNQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.2. Metodo de desarrollo en tecnologıa SoPC . . . . . . . . . . . . . . . . . . . . 162.3.3. Camaras, imagenes y framebuffers . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4. Organizacion del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3. Desarrollo del proyecto 213.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2. Diseno del Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2. GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.3. HDMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.4. Validacion del hardware en modo bare metal . . . . . . . . . . . . . . . . . . 27

3.3. Sistema operativo sobe la SoPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.1. BootROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.2. First Stage Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.3. U-Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.4. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4. Conexion PL a PS: diseno del driver . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.1. Funcionamiento del driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.2. Desarrollo del driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.5. Desarrollo del software de control de las camaras . . . . . . . . . . . . . . . . . . . . 333.5.1. Primer paso: captura de imagenes . . . . . . . . . . . . . . . . . . . . . . . . 333.5.2. Segundo Paso: Captura de vıdeo . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.6. Diseno de la carcasa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.7. Resultado Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4. Conclusiones 414.1. Impactos y aspectos de responsabilidad legal, etica y profesional . . . . . . . . . . . 42

7


5. Lineas Futuras 43

6. Planificacion temporal y presupuesto 456.1. Planificacion temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.2. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Bibliografıa 47

8

Indice de figuras

2.1. Evolucion del precio, consumo, coste y velocidad de las FPGA[1] . . . . . . . . . . . 112.2. Evolucion del valor del campo de vision por ordenador[17] . . . . . . . . . . . . . . . 122.3. Sistema fısico del proyecto previamente mencionado[9] . . . . . . . . . . . . . . . . . 132.4. GIMME 2[11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5. PYNQ-Z1[16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6. Diagrama de la ZYNQ-700[6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.7. El modelo UI-524LE-C[13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.8. Visualizacion de los pixeles de una imagen[3] . . . . . . . . . . . . . . . . . . . . . . 19

3.1. Conexion de la PHY directamente al microprocesador[22] . . . . . . . . . . . . . . . 233.2. Conexion de los GPIOs al microprocesador . . . . . . . . . . . . . . . . . . . . . . . 243.3. Conexion a la VDMA, simplificado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4. Diagrama de conexion al VTC y al DynClk . . . . . . . . . . . . . . . . . . . . . . . 253.5. Generacion de senales de control para el procesado[5] . . . . . . . . . . . . . . . . . . 263.6. Salida de la imagen al puerto HDMI . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.7. Diagrama de flujo del proceso de carga de un OS[2] . . . . . . . . . . . . . . . . . . . 283.8. Carga del BootRoom[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.9. Carga del FSBL[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.10. Carga de U-Boot en memoria[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.11. Carga de Linux en memoria[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.12. Visualizacion del modelo de la carcasa . . . . . . . . . . . . . . . . . . . . . . . . . . 373.13. Carcasa impresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.1. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

9


10

Capıtulo 2

Introduccion

2.1. Motivacion

El presente trabajo de fin de grado comienza en un contexto historico de gran avance de lastecnologıas basadas en hardware y de aquellas fundamentadas sobre la vision por ordenador.

En el ambito del hardware, se esta produciendo un avance increıble en la calidad, precio, velocidady fiabilidad de sistemas como las FPGAs. Adicionalmente, tecnologıas como la Zynq SoPC estanpermitiendo que la transicion de proyectos tradicionalmente basados en software pueda realizarsesin eliminar la experiencia acumulada por la industria de software en los ultimos anos.

Figura 2.1: Evolucion del precio, consumo, coste y velocidad de las FPGA[1]

A raız de estos cambios, se enfoco el trabajo de fin de grado a permitir adquirir experienciacon estas plataformas que estan revolucionando el mercado por su mayor velocidad y capacidad

11


de procesamiento. Es por ello, que este proyecto trata de sacar el maximo partido al nucleo de latecnologıa SoPC, generar proyectos de software sobre un microprocesador, que pueden ser desa-rrollados rapidamente, y generar hardware que realice las tareas mas costosas computacionalmentesobre la FPGA.

El campo de la vision por ordenador es otro campo que ha avanzado considerablemente en losultimos anos, el gran crecimiento experimentado en campos como los coches inteligentes, los UAVs,la realidad aumentada, etc., han generado una gran predisposicion e interes publico a desarrollarproyectos dentro de este campo.

Figura 2.2: Evolucion del valor del campo de vision por ordenador[17]

Se une a este crecimiento, la gran cantidad de potencia de computacion que requiere el tratamientode vıdeo. Una camara actual graba 60 imagenes por segundo, si se quiere procesar informacion detodas estas imagenes mediante software se requiere de un equipamiento potente. Es por ello queparece logico mover gran parte de esta carga de procesamiento a una FPGA para que sea resueltacon mayor velocidad y menor coste tanto inicial como energetico.

Con el objetivo de plantear un proyecto dentro de este contexto, se decidio disenar una plataformade vision por ordenador que permitiese el desarrollo de futuros proyectos de forma mas comoda ysimple.

2.2. Estado del arte

Para entender el contexto actual de desarrollo de sistemas de vision mediante hardware, es in-teresante centrar la atencion en sus predecesores, inicialmente, sistemas desarrollados sobre micro-controladores y tras ello, centrarse en proyectos controlados mediante hardware. En particular, noshemos centrado en aquellos sistemas que tienen que ver con la vision estereoscopicas, por ser estauna de las principales aplicaciones futuras del proyecto.

12


Uno de los ejemplos mas cercanos es ”Efficient Visual Odometry and Mapping for Unmaned AerialVehicle Using ARM-based Stereo Vision Pre-Processing System[9]”, un proyecto desarrollado, entreotros, por miembros del profesorado de la Escuela Tecnica Superior de Ingenieros Industriales. Eneste proyecto, se desarrolla un sistema de vision por ordenador integrado en un UAV y que permiteresolver una ruta en un espacio tridimensional mediante el mapeado tridimensional de su entorno,detectando obstaculos y vıas libres. Esta solucion y la propuesta en este proyecto emplean camarassimilares. Ademas, el procesador que se emplea en este trabajo y el que existe dentro de las Zynq sontambien similares, aunque en la solucion aquı propuesta, al emplear un SoPC, sera posible acelerarcualquier bloque de procesado de vıdeo en el hardware de la parte reconfigurable del dispositivo.

Figura 2.3: Sistema fısico del proyecto previamente mencionado[9]

Es interesante mencionar el artıculo ”Fast Onboard Stereo Vision for UAVs”[10] donde se pre-senta un trabajo colaborativo entre el MIT y ETH Zurich, donde se realizo el mismo proyecto,vision por ordenador para vuelo autonomo de UAVs, mediante dos caminos distintos, el uso demicroprocesadores y el uso de FPGAs. El mismo documento incluye una comparacion entre ambossistemas, presentando el sistema basado en FPGAs cuatro veces mas velocidad y menos consumoelectrico. Aunque aceptan que el sistema en FPGA es mas complejo y menos flexible, los buenosresultados del mismo les llevaron a comercializarlo bajo el nombre de ”VI Sensor from SkyBotixAG”.

Utilizando tecnologıa SoC encontramos los siguientes proyectos:

El primero de ellos, ”GIMME2 - an embedded system for stereo vision and processing of mega-pixel images with FPGA-acceleration”[11], es un proyecto que busca utilizar tecnologia SoC paradesarrollar una plataforma para el desarrollo de aplicaciones de vision por ordenador mediante doscamaras. El proyecto usa la tecnologıa Zynq SoC de Xilinx, la misma que es usada en este proyecto,y presenta unos resultados muy alentadores, bajo consumo energetico, procesamiento en tiempo

13


real, pequeno tamano, etc. Ademas, el GIMME 2 ha sido comercializada en el pasado con existo,aunque se encuentra actualmente discontinuado[19].

Figura 2.4: GIMME 2[11]

El segundo proyecto interesante que usa la tecnologia SoC para el desarrollo de aplicaciones devision por ordenador es el descrito en ”A Synchronized Visual-Inertial Sensor System with FPGAPre-Processing for Accurate Real-Time SLAM”[8], en este caso, encontramos un proyecto europeoque busca desarrollar un sistema de localizacion y mapeo simultaneo (SLAM) para UAVs. El desa-rrollo es mas complicado que el propuesto en este proyecto, ya que los algoritmos desarrollados enel proyecto requieren del apoyo de sensores adicionales como giroscopios o sensores de inercia.

En general, todos estos proyectos, especialmente los dos ultimos, nos presentan con una visonno solo de donde se encuentra el campo, si no, hacia donde se mueve. Esta claro que los sistemasbasados en hardware presentan cualidades a nivel de velocidad y consumo energetico que los haceatractivos no solo para proyectos de investigacion, sino tambien para productos comerciales.

14


2.3. Marco Teorico

2.3.1. La PYNQ

En el actual proyecto se usa una placa PYNQ-Z1[16] de Diligent. Esta placa posee en su nucleoel chip ZYNQ XC7Z020-1CLG400C [23] de Xilinx, perteneciente a la gama de dispositivos basadosen APSoCP de Xilinx y mas concretamente pertenece a la familia de las Zynq-700.

Figura 2.5: PYNQ-Z1[16]

En su interior incorpora un sistema de hardware, conocido como ”Programable Logic” o PL,basado en la familia de FPGAs Artix-7, disponiendo de 13300 segmentos logicos, conteniendo cadauno de ellos 6 LUT, ”Look Up Tables” y 8 biestables sıncronos. Posee ademas un sistema micro-controlador, llamado ”Processing System” o PS, definido, principalmente, por dos nucleos ARMCortex-A9 MPCore funcionando a 650 Mhz.

Ademas, el PS cuenta con un gran numero de perifericos en silicio (”hard IPs”) que permitenla interaccion de los microprocesadores con el resto de la placa. Entre ellos, algunos importantesson los perifericos de comunicacion entrada-salida con los perifericos de la placa (Ethernet, USB,UART, etc), la interfaz con la memoria DDR3 o las interfaces AXI para la conexion con la PL.

Debido a su gran uso en el proyecto, cabe mencionar el protocolo AXI, ”Advance eXtensibleInterface”. Este protocolo es el encargado de realizar la conexion entre la PL y el PS, desarrollado

15


Figura 2.6: Diagrama de la ZYNQ-700[6]

por ARM, el protocolo AXI permite el control y la escritura-lectura de multiples entradas y salidasde proposito general a traves de interfaces multiplexadas mediante el uso de registros de 32 bits.Por ello, permite un gran flujo de informacion sin utilizar un numero excesivo de pines. Ademas,al encontrarse estandarizada y recibir mucho soporte dentro de las herramientas de desarrollo deXilinx, sera una gran opcion para servir como nexo comun entre este proyecto y futuras mejoras.

Para acabar esta seccion, se debe indicar que la placa PYNQ-Z1 ha sido elegida principalmentedebido a su bajo coste, 220 e, y a la gran cantidad de perifericos que dispone, especialmente, sudisponibilidad de puertos HDMI y Ethernet.

2.3.2. Metodo de desarrollo en tecnologıa SoPC

Las tecnologıas SoPC requieren de dos niveles de desarrollo distinto, un primer nivel de hardwarey un segundo de software. Con el objetivo principal de reemplazar aplicaciones tradicionalmentedesarrolladas unicamente sobre software, se plantea un sistema que permita realizar un repartoentre las tareas que se implementan en software (tıpicamente mas secuenciales o de control), y lasque se implementaran en hardware (computacionalmente mas intensivas...).

Para ello, un proyecto sobre una plataforma SoPC comienza con un desarrollo de hardware. Elhardware se desarrolla mediante el diseno por bloques o IPs, del ingles ”Intellectual Property”.Estos bloques son unidades encapsuladas de funcionalidad que pueden ser distribuidas y usadas enun contexto mas generico. Por ejemplo, en el proyecto se usa un bloque conocido como VDMA, este

16


bloque ha sido disenado por la empresa Xilinx y posee la funcionalidad de conectarse directamentea la memoria fısica del microprocesador y transmitir al hardware informacion desde la misma. Estebloque puede ser usado en un proyecto, como el actual, conectando sus entradas y salidas a lospuertos adecuados. Ademas, el mismo bloque puede estar compuesto de elementos mas pequenos,pertenecientes a un nivel jerarquico inferior. Siguiendo con el mismo ejemplo, la VDMA esta op-timizada para realizar toma de datos con imagenes, sin embargo, podemos encontrar otro bloquellamado DMA, que realiza el mismo proceso pero a nivel mas generico, ambos bloques, VDMA yDMA, comparten subcomponentes entre ellos que solo deben ser desarrollados una vez. Este sis-tema altamente aceptado en la industria permite un desarrollo mas claro, reducir la repeticion detrabajo innecesaria y permite una alta y facil division del trabajo dentro del equipo de desarrollode hardware.

Para las placas basadas en la tecnologıa Zynq de Xilinx, como la PYNQ seleccionada para eseproyecto, el desarrollo de hardware en la industria se realiza, principalmente, sobre Vivado, unprograma que permite el diseno de bloques con lenguajes de descripcion de hardware como esVHDL, la combinacion de los mismos para generar proyectos, su testeo, sıntesis, implementacion ylanzamiento sobre la plataforma elegida.

El proceso de desarrollo de hardware acaba con la creacion de un fichero, el bitstream, que con-tiene toda la informacion del proyecto de hardware, bloques usados, direcciones de memoria dondeestan conectados dichos bloques, las constrains (informacion de como se encuentran conectadaslas entradas y salidas fısicas de la placa a la SoCP), etc. Este fichero sera el que se transmita alequipo de desarrollo de software para que empiecen con la implementacion de software, permitiendoabstraer completamente a un equipo del trabajo y necesidades del otro.

Cuando el equipo de software recibe este fichero, el entorno de desarrollo de software embebidode Xilinx, el SDK, prepara un proyecto incluyendo las bibliotecas necesarias para interaccionar conlos bloques definidos en el hardware (conocidos a traves del fichero bitstream), define todas lasconstantes necesarias y en definitiva, prepara un proyecto de software completamente separado delhardware.

2.3.3. Camaras, imagenes y framebuffers

En al proxima seccion vamos a explicar brevemente las camaras que se han usado en el proyecto,una introduccion a los metodos de captura disponibles en las camaras, una pequena explicacion sobreimagenes digitales y espacios de color y finalmente una introduccion a los framebuffers, uno de loselementos mas importantes del proyecto a la hora de organizar nuestro intercambio de informacionentre software y hardware.

Las camaras usadas pertenecen al modelo UI-5241LE-C de la compania Imaging DevelopmentSystems. La camara tiene unas dimensiones de 45x45x26,5 cm y realiza su conexion mediante cableethernet. Presenta una resolucion de 1280x1024 con 1,31 Mpx y es capaz de obtener 50 imagenespor segundo. Implementa un sistema de control de transmision, que si activado, permite indicara la camara el momento de inicio de toma de imagenes mediante un pulso electrico, este sistemasera utilizado en el proyecto para sincronizar la toma de imagenes entre ambas camaras. Disponeademas un sistema de correccion para pixeles danados, lo que permitira darles un gran uso en el

17


tiempo y que los algoritmos de vision no se vean afectados por valores extranos tras haber sufridola camara algun defecto.

Figura 2.7: El modelo UI-524LE-C[13]

Ademas de sus increıbles especificaciones tecnicas, una de las grandes razones de su uso son lasbibliotecas ofrecidas por IDS[14]. Dentro de las estas bibliotecas se encuentra todo lo necesario parainteractuar con los drivers ethernet del dispositivo y para conectarse y controlar las camaras. Conellas, se puede enfocar la camara, tomar una foto, inicializar la transferencia de vıdeo, etc. De estaforma, el desarrollador solo necesita enfocarse en la logica de la aplicacion deseada y dejar a labiblioteca realizar los procedimientos necesarios para interactuar con la camara.

En el actual proyecto, se dispondran las camaras en en modo streaming (sin interrupciones entreun frame y otro). Esto implica una transmision de 50 imagenes desde la camara cada segundo.Las imagenes son recibidas en RGB, un metodo de codificacion donde cada pixel de la imagenesta representado mediante tres numeros, que representan la cantidad de rojo, verde y azul quecontiene. Esto implica que cada imagen va a requerir un almacen en memoria igual al producto dela resolucion, numero de pixeles por imagen, multiplicado por tres, ya que se requieren tres bytespor cada pixel, uno para cada color en el rango de 0-255.

Resolucion ∗ bytes/pixel = (1280 ∗ 1024) ∗ 3 = 3932160 bytes = 3,93 Mbytes/imagen

18


Figura 2.8: Visualizacion de los pixeles de una imagen[3]

Para manejar toda esta cantidad de informacion por segundo, necesitamos un sistema de controlespecial, los framebuffers. Un framebuffer consiste en una estructura en memoria que va a contenerla informacion de una de las imagenes o frames. Estas estructuras pueden estar bloqueadas oaccesibles. Mientras se encuentran accesibles, cualquier proceso puede acceder a ellas, quedandobloqueadas ante cualquier actividad hasta que esta termine.

Una vez definido los framebuffers, en este proyecto tres de ellos, se unen en una estructura conoci-da como buffer circular. Esta estructura incluye un numero determinado de buffers interconectadosdonde cada buffer apunta al siguiente y el ultimo al primero. De esta forma, cuando se recibe laprimera imagen, esta se escribe sobre el primer buffer, la segunda sobre el segundo, etc, volviendoautomaticamente al primero tras haber circulado por todos ellos. Cuando se empieza a leer unaimagen, el buffer que la contiene queda bloqueado, usandose solo los restantes para guardar las nue-vas imagenes recibidas, evitando ası posibles problemas de sobreescritura. Una vez que se terminade leer, se desbloquea el buffer y este puede volver a usarse para almacenar una nueva imagen.

Esta estructura sera usada para manejar el almacenamiento de las dos camaras, con una camarapor buffer circular, y durante el proceso de transmision, sera un framebuffer lo que lea el hardwaredisenado.

2.4. Organizacion del documento

El presente documento ha sido organizado de acuerdo con los siguientes capıtulos:

1. Resumen: En este capitulo se presenta brevemente el objetivo, desarrollo y consideraciones

19


realizadas previamente y durante la realizacion del proyecto. Busca realizar una introduccionbreve al proyecto.

2. Introduccion: en este capitulo se presenta las circunstancias que rodean al proyecto. La moti-vacion que origino el proyecto, el actual estado del arte y los conocimientos teoricos necesariospara entender el resto del documento

3. Proyecto tecnico: En este capitulo se describe el nucleo del proyecto. Partimos del procesode diseno e implementacion del hardware, software y driver. Mas adelante mostramos laimplementacion fısica y el diseno de la carcasa y finalmente los resultados del proyecto final

4. Conclusiones e impacto: En este capitulo se detallan las conclusiones personales obtenidasdurante el desarrollo del proyecto. Adicionalmente, se analizan el posible impacto que elproyecto puede causar en lo que respecta a la responsabilidad legal, etica y profesional delproyecto.

5. Lineas futuras: En este capitulo se propondran algunos de los posibles caminos que puedeseguir el proyecto en el futuro.

6. Planificacion temporal y presupuesto: En este capitulo se explica como ha sido distribuido eltrabajo a lo largo del tiempo y se presenta el presupuesto detallado del mismo.

7. Bibliografıa

20

Capıtulo 3

Desarrollo del proyecto

3.1. Introduccion

En este apartado, se presentara el desarrollo tecnico del proyecto. Recordamos que el mismoconsiste en el desarrollo de un sistema de captura simultanea de imagenes desde multiples camaras,con salida HDMI, sobre un SoPC (”System on Programmable Chip”) con Linux Embebido. Esteproyecto puede ser el primer paso para el desarrollo de futuros trabajos de captacion y procesadode entornos 3D mediante vision estereoscopica.

Se ha intentado realizar una explicacion del proyecto desde el nivel mas basico al mas avanzado.Por ello, se empieza comentando el hardware, diseno y testeo, tras ello se explica el metodo usadopara preparar el sistema operativo que se ejecutara en la FPGA y se combinan los dos procesosanteriores mediante el desarrollo del driver que los comunica. Una vez desarrollado el driver, sepreparan las camaras para interactuar con el mismo y se realiza la implementacion, donde todoslos componentes finales se unen. Para acabar, se explica el diseno de la carcasa que se ha creadopara el proyecto y se muestra la version final del proyecto ya terminado.

Durante la explicacion se evitara sobrecargar el documento con el codigo y se optara por la masclara forma de explicarlo, los diagramas de flujo. Un proceso similar se realizara con el hardware.

3.2. Diseno del Hardware

La capacidad que tiene la tecnologıa SoPCs Zynq de Xilinx para adaptar el hardware que rodeaal microprocesador es una de las grandes ventajas que provee al mercado, otorgando al ingenierouna flexibilidad y versatilidad increıbles. En este apartado, analizaremos las decisiones que se hantomado a nivel de diseno de hardware ası como la implementacion que se ha llevado acabo delmismo.

En el caso del actual proyecto, se requiere del desarrollo de tres capas distintas de hardware, cadauna de ellas aplicada a distintos objetivos del proyecto. Lectura de las camaras (conexion ethernet),

21


control de la camaras (GPIO) y presentacion de las lecturas realizadas (HDMI). Los tres sistemasseran explicados a continuacion.

3.2.1. Ethernet

Para establecer una conexion ethernet, se requiere establecer una conexion entre la PHY y laMAC.

La PHY, abreviatura de ”Physical Layer”, es el nombre que recibe la electronica encargada deleer y enviar los paquetes enviados atrevas de la conexion ethernet. La PHY se encuentra por unlado conectada al puerto ethernet de la placa y por otro al PL de la placa.

La MAC, ”Media Access Control”, es un dispositivo que se encuentra dentro del microprocesadory cuya funcion consiste en analizar los paquetes que la PHY ha leıdo. Su principal objetivo esdecidir si un paquete recibido por la PHY esta dirigido al microprocesador y en el caso de que asısea, enviarselo. En el caso de la MAC, las conexiones de la misma se realizan con el PL y con elmicroprocesador.

Para poder establecer una comunicacion ethernet, necesitamos establecer una conexion entre laPHY y la MAC. Para ello, se nos presentan dos opciones a elegir, cada una de ellas con sus ventajase inconvenientes.

La primera de ellas, es establecer una conexion directa. La conexion ethernet en la PYNQ, esuna de las excepciones a la necesidad de realizar conexiones a traves de el PL, esto se debe a quealgunos pines del dispositivo, como es el caso de los que van a la PHY, entran directamente al PS.Por ello no es necesario rutar estas lıneas por el PL. Aunque esta opcion reduce la complejidad delsistema, solo permite establecer una conexion ethernet.

La segunda opcion para la conexion es establecer una conexion tradicional usando la PL y confi-gurar esta ultima para que realice el procesamiento necesario de los paquetes recibidos por la PHYpara mandarselos a la MAC. Esta opcion, permite la conexion de multiples puertos ethernet, sinembargo, conlleva una alta complejidad a nivel de diseno de hardware. Adicionalmente, en la placaque se usa en el proyecto, solo se dispone de una PHY, por lo que serıa necesario el uso de unaplaca adicional que nos proveyese de estas entradas adicionales.

Dado que necesitamos dos conexiones ehternet para este proyecto, una por cada camara, ladecision no es evidente. Sin embargo, hemos decidido optar por la primera opcion, reduciendo lacomplejidad del diseno de hardware y conectando las dos camaras a un switch, siendo este switchel que se conecte a la placa.

Una vez conectada la PHY con la MAC, el paquete sera recibido por la MAC y en caso de estardirigido a nuestra placa, sera la MAC la encargada de pasara el paquete al sistema operativo. Estospaquetes contendran la informacion enviada por la camara, y seran procesados posteriormente ensoftware.

22


Figura 3.1: Conexion de la PHY directamente al microprocesador[22]

3.2.2. GPIO

Los GPIO, ”General Purpose Input Output”, son los puertos de proposito general que permitenla entrada y salida de senales electricas desde el PL del SoPC a dispositivos externos, a traves delos pines del dispositivo. En nuestro caso, los dispositivos externos seran las camaras, que como yase ha explicado, contienen puertos que permiten controlar el proceso de toma de fotos o vıdeo.

La PYNQ, contiene multiples GPIO de los cuales usaremos:

3 en modo salida: dos para conectar directamente a cada una de las camaras y uno paraconectar un led que permitira realizar pequenas indicaciones al usuario como el estado deplaca, encendido o apagada.

1 en modo entrada: el cual, conectaremos a un switch integrado en la placa y que servira paracambiar el vıdeo de la camara que se envıa a traves del HDMI.

La conexion de los puertos externos al microprocesador puede realizarse de multiples maneras.Durante el desarrollo del proyecto dos opciones fueron analizadas.

Conexion mediante EMIOs: es una matriz programable que se encuentra en el PL y quepermite llevar perifericos propios de los microprocesadores a pines externos de la placa.

Conexion mediante AXI: son GPIOs configurados como perifericos del PS, a los cuales accedemediante registros mapeados en memoria, pero se encuentran situados en la PL

Aunque ambas opciones son aceptables, se decidio el uso del protocolo AXI, debido a su mayorcontrol y capacidad de velocidad de cambio de estado.

Para la conexion, se anade el periferico que controla los GPIOs del PL mediante AXI, con el quese interactua mediante accesos a memoria desde el PL. La conexion se puede observar en la figura3.2.

23


Figura 3.2: Conexion de los GPIOs al microprocesador

3.2.3. HDMI

HDMI es una norma que define el proceso de intercambio de audio y vıdeo entre dos dispositivos.Este estandar define todo el proceso, desde la conexion fısica a la forma de enviar la informacion.Ampliamente usado hoy en dıa, es la interface de vıdeo mas extendido.

Igual que en el caso de los GPIOs, la comunicacion entre el conector de HDMI de la placa yel PS, se realiza mediante la recirculacion de las senales electricas a traves de la FPGA que iraprogramada con el hardware especifico para manejarlas.

Para el diseno de hardware se ha partido del proyecto de referencia[7] que proporciona el fabricantede la placa, Digilent, la empresa que vende la placa usada, la PYNQ, junto a otras muchas placasde desarrollo para FPGAs. Tras descargar el modelo base, este diseno ha sido adaptado a nuestrasnecesidades y actualizado, ya que estaba disenado para placas antiguas.

Este diseno posee un gran numero de IPs distintos y una alta complejidad. A continuacion, seprocedera a realizar una explicacion del diseno para su mejor compresion.

A la hora de explicar en detalle el hardware, es bueno plantear una vision global de su funciona-lidad. Inicialmente, el PS lanza una senal de que se tiene una imagen a transmitir al PL, el primerbloque, la VDMA[18], recibe esta senal y transmite la imagen al PL desde la RAM. Los bloques,DynClk y VTC[21] generan las senales de temporizacion que se requieren para controlar el proceso.La imagen y las senales de temporizacion se transmiten al bloque vid out, encargado de unir lasdos para ajustar la imagen al protocolo HDMI. Finalmente, el flujo de datos pasa por el bloquergb2dvi, que lo convierte de rgb a dvi.

A continuacion, analizaremos cada uno de estos bloques mencionados en detalle, especialmentesu funcionalidad y conexiones.

El modulo central de el hardware es el VDMA, Video Direct Memory Access. El VDMA, es unbloque que se conecta directamente con la memoria RAM de la placa y extrae datos de ella, laVDMA es tambien capaz de escribir sobre la memoria pero no se hara uso de dicha funcionalidaden este proyecto. El VDMA tiene unas interfaces AXI, optimizadas para transferencias entre las dosposiciones de memoria que se le indiquen. En este caso, la transferencia se realiza entre la posiciondonde se encuentra la imagen y la salida HDMI. Posee una entrada AXI adicional, desde la cual el

24


PS puede controlar las transferencias, iniciarlas, pararlas, etc, este sistema otorga una gran ventajaya que una vez se ha enviado la senal de inicio de transferencia, el PS no debe prestar atencion alproceso, ya que es el VDMA la que se encargara de ello.

Figura 3.3: Conexion a la VDMA, simplificado.

Una vez se ha obtenido el frame de vıdeo de la memoria, este es transmitido al bloque de salidade vıdeo, llamado vid out. Sin embargo, y una de las principales ramas de desarrollo de futuro, latransmision podrıa realizarse a bloques intermedios de procesamiento, disenados por nosotros deforma que se puedan introducir distintas etapas de procesado de la imagen antes de su salida porHDMI.

El vid out preparara el frame para cumplir con los requisitos de la interfaz HDMI. Su tareaprincipal consiste es generar los pulsos de informacion que se requieren para la transmision dedatos. De forma que utilizara unas senales de configuracion, explicadas mas adelante, para generanel flujo de informacion adaptado a las necesidades de la interfaz.

Para procesar estas senales, el procesamiento requiere de dos bloques adicionales, el reloj dinami-co, DynClk, y el VTC, ”Video Time Controller”. El reloj dinamico va a ser el encargado de generarun reloj adaptado a la resolucion de la pantalla. La salida del reloj dinamico se usara en el VTC.

Figura 3.4: Diagrama de conexion al VTC y al DynClk

El VTC se encargara de generar las senales de control que seran necesarias en el procesamientodel vıdeo. Por ejemplo, es en este bloque donde se genera la senal de sincronizacion horizontal yvertical o las senales de fin de linea y fin de buffer.

25


Figura 3.5: Generacion de senales de control para el procesado[5]

Una vez procesado el frame de vıdeo que queremos transmitir a traves de HDMI, este frame esenviado al codificador de RGB a DIV, llamado rgb2dvi. Un paso necesario, ya que las imagenescapturadas por la camara se encuentran en el espacio de color RGB, donde la imagen queda codi-ficada en tres canales diferentes, uno para el rojo, uno para el azul y un tercero para el verde. Sinembargo, esta imagen debe ser convertida a DVI, ”Digital Visual Interface”, un protocolo distintopara transmision de imagenes que se distingue principalmente por utilizar 24 pines para la conexiony por utilizar dos canales para un mismo color, de forma que se van alternando entre los dos canalespara conseguir una mayor velocidad de transmision. El bloque rgb2dvi sera el encargado de realizarestos cambios.

Finalmente, se realiza la conexion entre la salida del codificador a los pines del HDMI de la placa,utilizando para ello, las restricciones necesarias.

Figura 3.6: Salida de la imagen al puerto HDMI

26


3.2.4. Validacion del hardware en modo bare metal

Una vez desarrollado el hardware y con objetivo de eliminar fuentes de error en el diseno dehardware, se procedio a testar el mismo.

Para entender el proceso llevado a cabo es importante entender que el hardware puede ser contro-lado mediante dos metodos. El primero de ellos, programando la PS directamente en C, utilizandoeste codigo para controlar los perifericos del controlador o se puede instalar un sistema operativosde tipo Linux y desarrollar una aplicacion sobre el sistema operativo que interactue con la PLmediante el uso de drivers.

Aunque en el proyecto se ha utilizado el segundo metodo, durante la fase de testeo se desarrollouna aplicacion en C sobre bare metal, esta aplicacion fue usada para asegurar que toda la funcio-nalidad del hardware era correcta. Para ello se partio, debido a la complejidad del sistema, de unaaplicacion generica desarrollado por Diligent y se procedio a adaptarla al hardware desarrollado. Laaplicacion adaptada intentaba transmitir por HDMI un patron previamente definido y cargado enla memoria RAM de la placa. El hardware se considero correcto cuando este patron fue mostradoen un monitor HDMI conectada a la placa.

El ethernet no fue testeado previamente al uso en el sistema operativo ya que que el stack TCP/IPque se usa sobre Ethernet es parte de Linux. Aunque se podrıa haber integrado sobre el sistema baremetal, se decidio no hacerlo ya que integrar un stack TCP/IP sin un sistema operativo necesitarıaun esfuerzo significativo. Por este motivo las pruebas con las camaras se realizaron unicamentesobre la version de la plataforma con Linux.

Una vez el hardware queso disenado y testeado se procedio al desarrollo del software para con-trolarlo a nivel de sistema operativo.

27


3.3. Sistema operativo sobe la SoPC

Durante el desarrollo del proyecto, se llego a la conclusion de que se iba a necesitar el uso de unsistema operativo. Las razones principales para esta decision son:

Requerido por los drivers de la camara, el sistema operativo permite emplear directamentelos ejecutables Linux que nos da el fabricante.

Integracion del protocolo TCP/IP de manera nativa.

Mayor versatilidad para anadir nuevos algoritmos de vision en el futuro.

Debido a su uso, se cree necesario realizar una introduccion a los metodos y requerimientos quetiene una SoPC para la carga y uso de un sistema operativo.

En este proyecto se ha decidido empleamos una distribucion del kernel de linux especıfica paradispositivos de Xilinx, el linux-xlnx 8[20]. Ademas, se emplea un sistema de ficheros conocido comoLinaro[15], una version reducida de Ubuntu, disenada especialmente para sistemas embebidos.

El proceso de arranque del sistema operativo se puede resumir de acuerdo con la siguiente imagen:

Figura 3.7: Diagrama de flujo del proceso de carga de un OS[2]

3.3.1. BootROM

El BootROM, esta instalado por defecto en la FPGA SoPC y su principal funcion es detectarel metodo de arranque requerido (NAND, QSPI, JTAG o SD) y carga el codigo del First StageBootloader en memoria. Para ello, el BootRoom es capaz, por si solo, de acceder a los posiblesdatos almacenados en la NAND o SD o de leer la transmision de datos procedente del JTAG o delQSPI. Tras comprobar estas cuatro formas de arranque permitido, detecta cual de ellas contiene elFirst Stage Bootloader, FSBL, y comienza su ejecucion.

28


3.3.2. First Stage Bootloader

Previamente a la instalacion y carga del sistema operativo, se necesita arrancar y configurar tantola PS como la PL. Este trabajo es realizado por el FSBL. El FSBL ira cargado, en este proyecto,en la tarjeta SD junto con el resto de componentes necesarios para el arranque del sistema.

La funcion del FSBL, es inicializar la memoria (DDR3) y los relojes de la placa esenciales paraejecutar componentes de mayor complejidad.

Figura 3.8: Carga del BootRoom[2] Figura 3.9: Carga del FSBL[2]

3.3.3. U-Boot

Una vez el FSBL ha terminado de configurar la placa, se carga en memoria RAM el SecondStage Bootloader, SSBL, esta clasificacion generica de programas es la que se encarga de instalar yconfigurar los sistemas operativos y es incluso usada por la mayorıa de los ordenadores de propositogeneral.

En nuestro caso, usaremos U-Boot[4], un SSBL especialmente disenado para microprocesadorescomo el ARM incluido en la PYNQ aunque soporta una gran variedad de plataformas.

El objetivo del mismo sera encontrar en la tarjeta SD, cargar en memoria y arrancar el SO.Ademas sera el responsable de transmitir el device tree, informacion de los perifericos disponiblesal PS, al kernel del sistema operativo.

3.3.4. Linux

Finalmente, el SSBL (U-Boot) localiza el kernel de Linux en la SD, lo carga en memoria y procedeal arranque del mismo mediante la llamada al programa init, este programa sera el encargado delocalizar todas las funciones del kernel e ir llamandolas adecuadamente para generar la correctainicializacion del sistema operativo. Esto cargara la terminal que sera ensenada por pantalla alusuario para que pueda registrarse y empezar a usar el SO.

29


Figura 3.10: Carga de U-Boot en memoria[2] Figura 3.11: Carga de Linux en memoria[2]

3.4. Conexion PL a PS: diseno del driver

Teniendo el hardware desarrollado y el sistema operativo instalado, necesitamos implementar unsistema que permita que estos dos componentes puedan comunicarse entre ellos, el driver.

Para entender el funcionamiento y la necesidad de un driver para establecer esta comunicacion,es necesario entender dos conceptos: memoria virtual y memoria fısica. Dos terminos que se refierenal sistema que usa Linux para manejar la memoria del sistema operativo y su interaccion con lamisma.

Como se explico en la parte de hardware, el VDMA extrae informacion directamente de la me-moria. Esta memoria a la que esta conectada el VDMA es la memoria fısica. Usualmente, nosreferimos a la memoria fısica como memoria RAM, es decir, cuando tenemos 4 GB de memoriaRAM el sistema operativo nos informara que tenemos 4 GB de memoria fısica.

Por otro lado, la memoria virtual es la abstraccion de esta memoria fısica para que su uso por elsistema operativo. Esta distincion se hace para permitir al sistema operativo tener mayor controlsobre la memoria. Por ejemplo, podemos tener la mitad de la memoria fısica como memoria virtualusada por un usuario en concreto, si parte de esta memoria no se usa en un periodo determinadode tiempo, el sistema operativo puede seleccionar este segmento de memoria virtual y guardarlo endisco duro, haciendo el acceso mas lento cuando se vuelva a necesitar la informacion pero liberandouna gran cantidad de memoria. Este ejemplo, conocido como paginacion es uno de los principalesbeneficios de este sistema de division de memoria y permite que el sistema operativo, pagando unprecio en velocidad de acceso, pueda simular una memoria mucho mayor que la poseıda fısicamente.

Esta distincion es importante para el desarrollo del proyecto por que el usuario no tiene acceso amemoria fısica, el sistema operativo bloqueara todo intento de acceso a la misma. Como se vera mastarde, la aplicacion que usa el usuario para obtener la informacion de las camaras se ejecutara en loque se conoce como user space, un espacio especial del sistema operativo donde solo se tiene accesoa la memoria virtual. Sin embargo, el hardware esta esperando informacion en la memoria fısica,por ello sera la labor del driver interconectar estas dos memorias, dando al usuario la capacidad deusar el driver para acceder de forma controlada a la memoria fısica.

30


3.4.1. Funcionamiento del driver

Para realizar la explicacion del funcionamiento del driver se presenta el diagrama de flujo delmismo, que se explicara en detalle mas adelante:

Inicio

Inicializar elframebuffer en

memoria virtual

Conectar elframebufferen memoria

virtual con lamemoria fısica

Inicializar yconfigurarel VDMA

Inicializar yconfigurarel Dynclk

Inicializar yconfigurar el VTC

Enviar framebuf-fer al hardware

Comienza la ejecucion del driver realizando su funcional principal, servir de nexo entre la me-moria fısica y la virtual, para ello, inicializamos un espacio en memoria virtual donde se guardarala informacion de las camaras, el framebuffer. Segundo, utlizamos las funciones que deja a nuestradisposicion el sistema operativo, en el caso de Linux la funcion mmap, para informar al sistema ope-rativo que pase lo que pase, la informacion que se escriba sobre el framebuffer debe ser transmitidaa una posicion concreta de la memoria fısica, esta posicion es configurada en los siguientes pasos.Una vez realizado este proceso, se tendra la forma de enviar informacion a nuestro hardware.

31


Una vez preparado el framebuffer se deben configurar tres bloques de hardware, el VDMA y losbloques para la salida HDMI, el VTC y el DynClk. Para ello, se realiza un proceso similar a lo quehacıamos en el framebuffer, se prepara una direccion en memoria que permita enviar la informacionde configuracion a los bloques y se transmite, en este caso una sola vez, la configuracion deseada.

La informacion que se manda en este paso es informacion de configuracion, que resolucion se estausando, donde se situa el framebuffer, etc.

Una vez configurado el sistema, se pone en funcionamiento el VDMA y se empieza a transmitiral informacion del framebuffer a la salida HDMI.

3.4.2. Desarrollo del driver

Para el desarrollo del driver, se decidio partir de la aplicacion que habıamos generado para eltesteo del hardware. Este codigo fue reducido hasta su mınima complejidad, eliminando partesinnecesarias y funcionalidades que no seran usadas en el proyecto.

Con el codigo reducido, es necesario solucionar un problema, el proyecto utiliza una serie debibliotecas desarrolladas por Xilinx que estan pensadas para funcionar en standalone, es decir, conel microprocesador funcionando sin sistema operativo.

Para cambiar esto se realizaran dos pasos, el primero de ellos consistio en obtener una lista detodas las bibliotecas que el codigo requerıa en bare metal. Una vez extraıda esta lista, se analizoindividualmente cada biblioteca e igual que antes se elimino todo el codigo no necesario.

El segundo paso consistio en eliminar codigo que se requerıa en standalone pero que esta dispo-nible en un sistema operativo mediante el uso de bibliotecas estandar de C, printf, memset,etc. Porejemplo, la funcion printf habıa sido redefinida para enviar la cadena de texto a imprimir a travesdel USB de la placa en vez de a la consola.

Una vez se tiene un codigo con bibliotecas lo mas limpio posible se procede a cambiar el compiladory el linker usado para generar el fichero ejecutable. El nuevo compilador y linker seran los necesariospara preparar aplicaciones para el sistema operativo utilizado y se encargaran de referenciar lasbibliotecas estandar que requiere el proyecto.

Una vez finalizado, se tiene un fichero que puede ser ejecutado, .elf, en la PS de la SoPC dentrodel user space para la transmision de las imagenes obtenidas por la camara al hardware.

32


3.5. Desarrollo del software de control de las camaras

Como se ha explicado previamente, uno de los principales objetivos del presente trabajo consisteen la captacion del vıdeo grabado por las camaras, sincronizando la captacion de imagenes de ambascamaras. En este apartado, se procede a la explicacion del proceso de forma detallada.

La dificultad de la programacion de las camaras se focaliza en dos puntos:

El uso de la biblioteca proveıda por el fabricante de las camaras.

La logica de captura.

Para facilitar la comprension del proceso, se va a seguir el proceso realizado durante el desarrollodel trabajo. Primero se explicara la aplicacion para capturar imagenes. Esta aplicacion necesita depoco codigo logico y por lo tanto permitira una facil explicacion del uso de la biblioteca. Una vezentendido el uso de la misma se procedera a explicar el funcionamiento de una aplicacion de capturade vıdeo.

3.5.1. Primer paso: captura de imagenes

Este ejemplo fue el primer nivel de desarrollo en este trabajo, y su principal objetivo es entendertodos los pequenos matices que se requieren para utilizar las camaras, de forma que, cuando serealice el programa mas complicado de captura de vıdeo, todas las dificultades que surjan debido ala propia biblioteca de las camaras, puedan ser resueltas sin complicaciones.

Para explicar el codigo, se seguira el diagrama de bloques que se propone en la documentacionde las camaras[14]. El diagrama de bloques presentado es una modificacion del mismo, del cual, sehan eliminado algunas de las opciones que nos ofrece la biblioteca pero que no son necesarias paranuestro proyecto.

33


Inicio

Obtener numerode camaras

Obtener in-formacion delas camaras

Inicializarlas camaras

Definir el colorde la toma

de imagenes

Definir me-moria activa

Enviar zona dememoria activa

Definiciondel modo de

funcionamiento

Obtener imagen

Recibir imagen

Liberar memoria

Parar camara

Final

El primer paso, como ya se ha podido ver, consiste en obtener informacion de las camaras conec-tadas, el identificador de cada una de ellas, la IP con la que estan conectadas a la red, etc. Paraello se utiliza is GetNumberOfCameras(&numCam) para obtener el numero de camaras conectadasy is GetCameraList() para generar una estructura de datos que contiene los datos de cada una delas camaras conectadas.

El segundo paso consiste en inicializar las camaras, para ello se usa is InitCamera (). La inicia-lizacion de la camara avisa a la misma de que tiene que estar preparada para obtener imagenes yque debe recibir y procesar los mensajes que le mande el programa principal.

Despues de iniciar la camara, esta debe ser informada del formato que queremos que use para ob-tener las imagenes, en nuestro caso, RGB con doce bits por color, dandonos una gama de 236 coloresdistintos. Para ello se usa is SetColorMode() con el modo de color IS CM RGBA12 UNPACKED.

Previamente a que se pueda pedir a la camara que empiece a tomar imagenes, se tiene que definirla direccion de memoria en la que se quiere que el programa guarde la imagen. Para ello se usais AllocImageMem(), que recibe el tamano (altura y anchura) de la imagen y el numero de bits usadopor cada pixel (3 colores ∗ 12 bits/color = 36 bits) y definira una zona de memoria, devolviendo unpuntero al principio de la misma.

34


Aunque en este caso, solo necesitamos una zona de memoria por camara, cuando grabemos video,se observara que se tendran que definir multiples de ellas para almacenar un conjunto de frames.Es por ello, que es necesario definir una zona de memoria como principal, es decir, la zona dememoria entre todas las definidas donde la imagen actual se va a almacenar. Para ello, usaremosis SetImageMem().

El ultimo paso en la configuracion consiste en definir el modo de funcionamiento, en este caso,el modo usado es freerun mode. En este modo obtendra imagenes constantemente, siendo estasguardadas en la propia memoria de la camara y no sera hasta que se solicite una imagen que serealizara la transmision de la ultima imagen tomada.

Para realizar este proceso y que se envie la imagen se usa la funcion, is FreezeVideo().

Tras la obtencion de la imagen, la guardamos en el disco duro como un fichero tradicional png.Este proceso se realiza principalmente para testear el proceso de la aplicacion, ya que si se obtieneuna fichero png y muestra una imagen correctamente tomada, se podra considerar el codigo comofuncional.

Para acabar, se debe liberar la memoria que se habıa reservado para la imagen, para ello se usarais FreeImageMem() y se debe informar a la camara de que no se la va a necesitar mas, y que porlo tanto, debe apagarse, para ello se usa is ExitCamera().

Habiendo entendido el proceso basico de desarrollo con las camaras, se puede pasar a desarrollarel codigo de la toma de vıdeo.

3.5.2. Segundo Paso: Captura de vıdeo

Una vez se ha analizado el proceso de captura de una unica imagen, el proceso de captura de vıdeoes muy similar salvando dos diferencias. La primera de ellas, es el almacenamiento en memoria, sequiere almacenar no solo una imagen, sino multiples de ellas en serie. La segunda diferencia es laforma en la que se informa a la camara para que envie la imagen a la SoPC.

La primera diferencia se resuelve mediante la definicion de varias posiciones de memoria dondealmacenar imagenes. Tras esto, se procede a introducir las imagenes en un buffer circular. Para ello,se usa is AddToSequence(). El uso de buffers circulares es un estandar en la industria, y permiteguardar multiples imagenes una detras de otra y que al finalizar el recorrido por todos los elementosdel buffer se vuelva al primero.

Sin embargo, el buffer circular presenta un problema, si bien es cierto que resulta muy util paraalmacenar grandes volumenes de imagenes debido a su capacidad de entrar en bucle, tambien esesta cualidad la que causa que sea muy costoso encontrar la posicion dentro del anillo en la quese ha escrito por ultima vez. Para solucionar este problema se definira una FIFO que almacena laposicion dentro del buffer circular de la ultima captura introducida. De esta forma, al finalizar larecepcion se puede introducir la direccion donde se ha guardado la imagen en la FIFO, y en casode requerirse la ultima imagen, solo habra que extraer de la FIFO el ultimo valor introducido. Parala inicializacion de este proceso, se utiliza is InitImageQueue.

35


Igual que en el primer ejemplo, todas estas operaciones deben de programarse con eliminaciona la salida del programa. De esta forma, la eliminacion de las posiciones de memoria se realizade la misma manera que en el primer ejemplo, mientras que el buffer circular se elimina usandois ClearSequence() y la FIFO mediante is ExitImageQueue().

Para mantener la sincronıa entre las dos camaras, se configurara la camara en un modo de capturaconocido como el modo hardware trigger. Este metodo bloquea la transmision de imagenes entre lacamara y la SoPC hasta que la camara reciba un pulso electrico. Este pulso electrico es para lo quese usaran los GPIOs configurados en el desarrollo de hardware, ya que seran estos los que vayanconectados a ambas camaras y se encargaran de enviar tantos pulsos como se crea conveniente.Para configurar este modo se usa is SetExternalTrigger(). Esta funcion debe ejecutarse antes deinicializar el proceso de captura y tambien puede usarse para realizar interrupciones y capturas deimagen mediante software.

Finalmente, la captura de imagenes. En el caso del vıdeo, no se quiere detener el proceso de tomade imagenes sino controlar cuando llegan. Por ello, se inicializa el proceso usando is CaptureVideo(),que comenzara a obtener imagenes y a guardarlas en la memoria propia de la camara. Como se haexplicado antes, al encontrarse la camara en modo hardware trigger, estas imagenes guardadas enmemoria solo seran transmitidas al recibir un pulso electrico, el cual generara la transmision de laultima imagen obtenida por la camara. El proceso de captura de vıdeo sera detenido al final de laaplicacion con el uso de is StopLiveVideo().

La unica otra diferencia es el metodo de obtencion de la ultima imagen tomada, para ello se usais WaitForNextImage() que devuelve la direccion de memoria donde se almacena la imagen parafuturos analisis.

36


3.6. Diseno de la carcasa

Durante el proceso de finalizacion del proyecto, se diseno una carcasa que permitiese manejarmas comodamente el sistema fısico. Esta carcasa intenta cumple dos funciones:

Alojamiento de las camaras en posiciones fijas incluidas sobre el mismo plano, para facilitarla realizacion de reconstrucciones 3D.

Posibilidad del cambio de la distancia focal entre las dos camaras.

El alojamiento fijo de las camaras permite reducir el numero de piezas moviles que tiene elsistema, eliminando gran parte del enredado de cables que se producıa en el prototipo original yadicionalmente, mejorando el control que se tiene sobre la direccion a la cual las camaras estabandirigidas.

De igual manera, la carcasa ha sido disenada con la posibilidad de distribuir las camaras endistintas posiciones. De esta forma, la distancia entre los objetivos de las camaras puede variarse enfuncion de la distancia a la que se encuentre el objeto que se vaya a querer fotografiar. Esta variacionde distancia focal es discreta y actualmente se puede elegir entre 6, 12 y 36 cm. A continuacion sepresenta una de las mitades del modelo 3D:

Figura 3.12: Visualizacion del modelo de la carcasa

Este modelo puede ser impreso en una pieza utilizando una impresora 3D, sin embargo, debidoal tamano de la impresora 3D disponible durante la realizacion del presente trabajo, el modelo fue

37


dividido en dos mitades simetricas. La conexion entre ambas mitades se realiza mediante el uso depernos o tornillos.

Mediante un metodo similar se fijan las camaras a la carcasa, los cuatro taladros en la carcasacoinciden con cuatro taladros presentes en la placa base de las camaras usadas. Esto permite unaconexion rapida, estable y libre de problemas electricos, ya que los taladros en la PCB se encuentranconectados a tierra.

La carcasa impresa y unida se muestra a continuacion:

Figura 3.13: Carcasa impresa

Adicionalmente, a pesar de que las distancias focales son y deben ser discretas, el modelo 3Drealizado mediante el uso de programas CAD, especıficamente FreeCad[12], bajo el paradigma demodelado parametrico, esto permite definir relaciones entre objetos no como numeros fijos sinocomo variables. Esto permitira que, de ser necesario, se puedan variar facilmente las distanciasfocales de la carcasa, mejorando de ese modo su funcionalidad para una gran numero de proyectosque sean realizados a posteriori.

38


4.7. Resultado Final

Tras finalizar el proyecto, la gran mayorıa de los objetivos han sido cumplidos. El proyecto disponede un sistema desarrollado y testeado para la configuracion y el control de dos camaras, capaz deadquirir 50 imagenes por segundo. Tambien se ha completado el diseno y testeo del hardwarenecesario para la salida de estas imagenes adquiridas.

Figura 4.1: Patron horizontal mediante conexion HDMI

Figura 4.2: Patron aleatorio mediante conexion HDMI

Sin embargo, el desarrollo de un driver para el sistema operativo Linux ha supuesta mas compli-cado que lo originalmente pensado. Esto a conllevado que en el tiempo disponible para el desarrollode este proyecto ha sido posible el desarrollo del mismo, sin embargo, no se ha podido testear elmismo en su totalidad y por consiguiente no se ha podido completar la implementacion final delproyecto.

39


Aunque el proceso de testeo e implementacion no deberıa poseer una gran complejidad si es ciertoque requiere de una considerable cantidad de horas de trabajo a las que no se tiene acceso si sedesea cumplir los requisitos temporales del proyecto.

Figura 4.3: Camara instalada en la carcasa

40

Capıtulo 4

Conclusiones

Aunque no se ha alcanzado los objetivos definitivos propuestos al comienzo del trabajo, es im-portante reflexionar sobre la gran cantidad de objetivos cumplidos y de conocimientos adquirido.

Como se ha explicado a lo largo del trabajo, hemos conseguido desarrollar satisfactoriamente elsoftware y el hardware requerido por el proyecto. Ello ha implicado una adquisicion considerablede conocimientos en muchos niveles:

A nivel de hardware, se ha conseguido adquirir un manejo fluido con la herramienta Vivadode Xilinx, tanto a nivel de creacion de bloques como de implementcion y entendimiento delos mecanismos con los que funciona el desarrollo de hardware para una SoPC, muchos delos cuales pueden ser trasladados directa o muy facilmente a otras plataformas distintas de lamisma tecnologıa.

En el mismo campo, el uso de bloques predefinidos de Xilinx como el VDMA o el VTChan obligado al autor a la lectura de una gran cantidad de documentacion tecnica sobreel funcionamiento, diseno y uso de estos bloques. Esto ha llevado a adquirir conocimientos,aunque a nivel indirecto, sobre como se disenan bloques de hardware a nivel profesional ycomo se procede a documentar un proyecto tecnico ingenieril de tal envergadura.

A nivel de software de la aplicacion de las camaras sirvio para desarrollar conocimientos sobreel sistema de funcionamientos de los servicios ethernet de un sistema operativo, pipes, sockets,daemons, etc, que aunque no han sido usados en el desarrollo del proyecto, si que han sidonecesarios para entender e funcionamiento de las bibliotecas de las camaras.

Durante el desarrollo del driver y junto a la instalacion del sistema operativo Linux en la SoPC,se ha profundizado mucho en las profundidades del sistema operativo Linux, desde conceptosde manejo de memoria explicados en este documento al conocimiento de la interaccion delsistema operativo con dispositivos externos a traves del filesystem.

Finalmente, el desarrollo de la aplicacion de testeo y del mismo driver han permitido desarro-llar habilidades propias de la programacion en C a bajo nivel, algo que el autor nunca habıarealizado. De este periodo de tiempo quedaran conocimientos como el uso del precompila-dor, el uso eficiente de tipos para reducir la carga sobre memoria, el desarrollo profesional debibliotecas de gran complejidad, etc.

41


Es por toda esta lista anterior que el autor se queda satisfecho con los resultados obtenidos en elproyecto. Ha sido un periodo de aprendizaje, de aplicar conocimientos adquiridos durante el gradoa nivel practico y sobre todo un tiempo de trabajo ingenieril.

4.1. Impactos y aspectos de responsabilidad legal, etica yprofesional

Aunque ya se ha hablado de ello, una de las principales ventajas que posee el uso de hardwareen lso proyectos es la reduccion del consumo energetico del mismo. Esto es una gran ventaja a lahora de utilizar y vender un proyecto desarrollado en hardware, pero tambien supone un aspectode responsabilidad medioambiental para el ingeniero, ya que se esta reduciendo indirectamente lahuella de carbono generada por su producto.

Respecto a la responsabilidad etica, Xilinx, el desarrollador del chip incluido en la PYNQ tiene uncompromiso para no usar minerales conflictivos, una denominacion reconocida internacionalmentedada a materiales provenientes de la Republica Democratica del Congo y sus alrededores dondeel dinero usado para la compra de estos materiales suele acabar en las manos de grupos rebeldesarmados que explotan a la poblacion para la extraccion de dichos minerales.

42

Capıtulo 5

Lineas Futuras

En linea con el objetivo inherente del proyecto, se espera que en el futuro proximo se use esteproyecto para realizar implementaciones de algoritmos de estereoscopıa y mas genericamente devision por ordenador. Se espera que el proyecto ayuda a los alumnos a centrarse en el desarrollode hardware y que sirva como plataforma para permitir que mas alumnos de la Escuela Tecnicade Ingenieros Industriales salgan con conocimiento practico en este campo tan en desarrollo hoy endıa.

Sin embargo, y debido a los problemas que se ha tenido con el driver, se requerira de la dedicacionnecesaria al proyecto para terminar el proceso de testeo e implementacion del driver. Ademas, sepodrıa analizar la posibilidad de mover el driver del user space al kernel space, lo que otorgarıamas velocidad al sistema y que podrıa convertirse facilmente en el trabajo de fin de grado de otroalumno de la escuela.

Finalmente, y conociendo la experiencia del Centro de Electronica Industrial con la reconfigura-cion dinamica de sistemas basados en hardware, podrıa ser interesante mejorar la plataforma desalida a HDMI ofreciendo la posibilidad de cambiar el algoritmo de vision, o algun parametro dentrodel mismo, que se esta ejecutando sobre hardware, ofreciendo de esta manera una forma facil detestear distintos algoritmos para cada aplicacion

43


44

Capıtulo 6

Planificacion temporal ypresupuesto

6.1. Planificacion temporal

Para la visualizacion de la planificacion temporal se presentan dos herramientas. La primerade ellas, el esquema de descomposicion del proyecto, nos presenta una vision rapida y clara de ladistribucion real del proyecto a lo largo del tiempo, de arriba a abajo y de izquierda a derecha.

Trabajode Fin

de Grado

Preparacionprevia

Desarrollo delproyecto tecnico

Redaccion dela memoria

Reuniones pre-vias

Estudio del es-tado del arte

Estudio de lastecnologiasde desarrolloSoPC

Desarrollo delsoftware

Desarrollo delhardware

Desarrollo deldriver

Diseno de lacarcasa

Implementacion

La segunda herramienta usada es el diagrama de Gantt el cual permite observar en mas detallela duracion temporal de las acciones y su progresion y sucesion en el tiempo. Cabe destacar queel proyecto ha sido considerablemente lineal, con procesos independientes que han sido llevados acabo uno detras de otro.

45


Fig

ura

6.1

:D

iagra

ma

de

Gantt

46


6.2. Presupuesto

A continuacion se presenta el presupuesto completo del proyecto. Cuando se ha consideradonecesario se ha incluido los anos de amortizacion del producto entre parentesis, siendo por lo tantoel importe igual al coste dividido entre los anos de amortizacion.

Uds. Concepto Coste Importe1.00 ZYNQ-Z1 185,00 e 185,00 e2.00 Cables Ethernet 1,95 e 3,90 e1.00 Switch 9,99 e 9,99 e2.00 Camaras y lente 605,33 e 1210,66 e1.00 Vivado (3 anos) 2016.3 4795,00 e 1598,00 e1.00 FreeCad 0,00 ee 0,00 e1.00 BQ witbox (10 anos) 1690,00 e 169,00 e0.10 PLA 19,90 e 1,99 e400.00 Salario del personal 15,00 e 6000,0 e

Importe total 9169,54

47


48

Anexo A: Diagrama de Hardware

A continuacion se muestra el diagrama del hardware usado en el proyecto, para futuras referenciasy usos y debido a su gran tamano se prefiera el uso de una pagina individual para el mismo.

1

2

Fig

ura

1:

Dia

gra

ma

del

Hard

ware

Anexo B: Programa de captura deimagenes

#include <iostream >

#include <uEye.h>

#include <vector >

using namespace std;

int main() {

cout << "Beginning!" << endl;

// Definimos parametros de las imagenes

int width = 1280;

int height = 1024;

int bitsPixel = 32;

int colorMode = IS_CM_BGRA8_PACKED;

INT nRet = 0;

// variables globales que guardaran la informacion

unsigned int numCameras = 2;

unsigned int numImgPerCamera = 2;

vector <HIDS > cHandleVec;

cHandleVec.resize(numCameras );

vector <char*> ppcImgMemVec;

ppcImgMemVec.resize(numImgPerCamera , NULL);

vector <int > pidVec;

pidVec.resize(numImgPerCamera , 0);

// Inicializamos las camaras

for(int i = 0; i < cHandleVec.size (); i++){

nRet = is_InitCamera (& cHandleVec[i], NULL);

if(nRet != IS_SUCCESS) cout << "not 1" << endl;

cout << "Status Init " << nRet << endl;

}

3

4

// Definimos el espacio de color a usar

for(int i = 0; i < cHandleVec.size (); i++) {

nRet = is_SetColorMode(cHandleVec[i], colorMode );

cout << "Status SetColorMode " << nRet << endl;

}

// Definimos la ubicacion a guardar la imagen


nRet = is_AllocImageMem(cHandleVec[i], width , height ,

bitsPixel , &ppcImgMemVec[i], &pidVec[i]);

cout << "Status AllocImage " << nRet << endl;

}

// Definimos la memoria activa


nRet = is_SetImageMem(cHandleVec[i], ppcImgMemVec[i], pidVec[i]);

cout << "Status SetImageMem " << nRet << endl;

}

// Definimos el modo de recepcion de la imagen


nRet = is_SetDisplayMode(cHandleVec[i], IS_SET_DM_DIB );

cout << "Status displayMode " << nRet << endl;

}

// Activamos/desactivamos el trigger externo


nRet = is_SetExternalTrigger(cHandleVec[i], IS_SET_TRIGGER_OFF );

cout << "Status SetTrigger " << nRet << endl;

}

// Grabamos el video


nRet = is_FreezeVideo(cHandleVec[i], IS_WAIT );

cout << "Status is_FreezeVideo " << nRet << endl;

}

// parametros para guardar el video

IMAGE_FILE_PARAMS ImageFileParams;

ImageFileParams.pwchFileName = (wchar_t *) L"./ image1.bmp";

ImageFileParams.pnImageID = NULL;

ImageFileParams.ppcImageMem = NULL;

ImageFileParams.nQuality = 0;

ImageFileParams.nFileType = IS_IMG_BMP;

// Guardamos el video

5


nRet = is_ImageFile(cHandleVec[i], IS_IMAGE_FILE_CMD_SAVE ,

(void *) &ImageFileParams ,

sizeof(ImageFileParams ));

ImageFileParams.pwchFileName = (wchar_t *) L"./ image2.bmp";

cout << "Saving Image " << nRet << endl;

}

// Liberamos la memoria


nRet = is_FreeImageMem(cHandleVec[i], ppcImgMemVec[i], pidVec[i]);

cout << "Free Image " << nRet << endl;

}

// Apagamos las camaras


nRet = is_ExitCamera(cHandleVec[i]);

cout << "Exit Camera " << nRet << endl;

}

return 1;

}

Anexo C: Programa del driver

#include "display_ctrl/display_ctrl.h"

#include <sys/mman.h>

#include <unistd.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include "math.h"

#include <ctype.h>

#include <stdlib.h>

#include <limits.h> // CHAR_BIT

#include "include/xil_types.h"

#include "include/xparameters.h"

// definiciones de las propiedades de las imagenes

#define DEMO_MAX_FRAME (640*480*3)// max size of the frame

#define DEMO_STRIDE (640 * 3)// max size of a line in a frame

#define HEIGHT 480

#define WIDTH 640

#define STRIDE WIDTH

// Estructuras y definiciones de apoyo para el codigo

#define VDMA_MM2S_ALIGN (XPAR_AXI_VDMA_0_M_AXI_MM2S_DATA_WIDTH / CHAR_BIT)

typedef struct { unsigned g:8, b:8, r:8; }

__attribute__ (( __packed__ )) pixel;

typedef pixel line[STRIDE ];

typedef line frame[HEIGHT] __attribute__

(( __aligned__ (VDMA_MM2S_ALIGN )));

// Estructuras para almacenar la informacion

//de los bloques de hardware

DisplayCtrl dispCtrl;// DynClk y VTC

XAxiVdma vdma;//VDMA

// Bucle Circular

u8 *pFrames[DISPLAY_NUM_FRAMES ];

7

8

int main(void)

{

int Status = 0;

XAxiVdma_Config *vdmaConfig;

// definicion del bucle circular

pFrames [0]= (u8*) 0x10000000;

// Direccion de memoria donde se guarda la imagen

pFrames [1]= NULL;

pFrames [2]= NULL;

// Definicion del VDMA

vdmaConfig = XAxiVdma_LookupConfig(XPAR_AXIVDMA_0_DEVICE_ID );

// Conexion de la memoria virtual a la memoria fisica

int fd;

fd = open("/dev/mem", O_RDWR );

char *adress = mmap(( caddr_t )0x43000000 , DEMO_MAX_FRAME ,

PROT_READ , MAP_SHARED , fd , 0);

vdmaConfig ->BaseAddress = (UINTPTR)adress;

// guardamos la direccion de memoria virtual conectada

// Inicializacion del VDMA

Status = XAxiVdma_CfgInitialize (&vdma , vdmaConfig ,

vdmaConfig ->BaseAddress );

// Definicion e inicializacion del DynClk y del VTC

Status = DisplayInitialize (&dispCtrl , &vdma ,

XPAR_VTC_0_DEVICE_ID ,

XPAR_AXI_DYNCLK_0_BASEADDR ,

pFrames , DEMO_STRIDE );

// Arranque de los bloques

Status = DisplayStart (& dispCtrl );

// Preparamos la configuracion de la VDMA

dispCtrl.vdmaConfig.VertSizeInput = HEIGHT;

// number of lines

dispCtrl.vdmaConfig.HoriSizeInput = WIDTH * sizeof (pixel );

// image BYTES per line

dispCtrl.vdmaConfig.Stride = sizeof (line);

// total BYTES per line (image+padding)

dispCtrl.vdmaConfig.EnableCircularBuf = 0;

// 0 = Park Mode; 1 = Circular Mode

dispCtrl.vdmaConfig.EnableFrameCounter = 1;

9

// 0 = stream forever; 1 = N frames (def .1)

dispCtrl.vdmaConfig.FrameStoreStartAddr [0] = (UINTPTR )(fbs + 0);

// frame addresses

dispCtrl.vdmaConfig.FixedFrameStoreAddr = 0;

// Frame to use when in Park Mode

dispCtrl.vdmaConfig.FrameDelay = 0;

// min # of FBs Genlock slave is behind master

dispCtrl.vdmaConfig.EnableSync = 0;

// GenLock sync (0 = disable; 1 = enable)

dispCtrl.vdmaConfig.PointNum = 0;

// master in control when not Genlock Master mode

dispCtrl.vdmaConfig.GenLockRepeat = 0;

// on error , 0 = drop frame; 1 = repeat frame

//Se para la VDMA

XAxiVdma_DmaStop (&vdma , XAXIVDMA_READ );

//Se espera a que se encuentre parada

while (XAxiVdma_IsBusy (&vdma , XAXIVDMA_READ )) {}

//Se configura

XAxiVdma_DmaConfig (&vdma , XAXIVDMA_READ ,

&dispCtrl.vdmaConfig );

int i;

while (1) {

for (i=0; i<3; i++) { // Recorremos el buffer circular

dispCtrl.vdmaConfig.FrameStoreStartAddr [0] =

(UINTPTR)fbs;

while (XAxiVdma_IsBusy (&vdma , XAXIVDMA_READ )) {}

//Y se lo mandamos al VDMA

XAxiVdma_StartReadFrame (&vdma ,

&dispCtrl.vdmaConfig );

}

}

munmap(adress , DEMO_MAX_FRAME );//al salir , limpiamos la memoria

close(fd);

return 0;

}

Bibliografıa

[1] Sagheer Ahmad. “A 16-nm Multiprocessing System-on-Chip Field-Programmable Gate ArrayPlatform”. En: IEE Micro 36.02 (2016). doi: https://www.computer.org/csdl/mags/mi/2016/02/mmi2016020048.html.

[2] Avnet. Implementing Linux on the Zynq R©-7000 All Programmable SoC (ISE 14.2). url:http://zedboard.org/support/trainings-and-videos.

[3] CutOutImage. url: https://www.cutoutimage.com/blog/wp-content/uploads/2015/05/articleImage04.jpg.

[4] Denx. Das U-Boot – the Universal Boot Loader. url: https://www.denx.de/wiki/U-Boot.

[5] Analog Devices. ADV7511. Low-Power HDMI 1.4 Compatible Transmitter with Audio ReturnChannel. 2012. url: http://www.analog.com/media/en/technical-documentation/user-guides/ADV7511_Programming_Guide.pdf.

[6] Diligent. url: http://f.digilent.com.cn/14632804648.png.

[7] Diligent. ZYBO HDMI Demo. url: https://reference.digilentinc.com/learn/programmable-logic/tutorials/zybo-hdmi-demo/start.

[8] Albert Einstein. “A Synchronized Visual-Inertial Sensor System with FPGA Pre-Processingfor Accurate Real-Time SLAM”. En: Annalen der Physik 322.10 (1905), pags. 891-921. doi:http://dx.doi.org/10.1002/andp.19053221004.

[9] Albert Einstein. “Efficient Visual Odometry and Mapping for Unmaned Aerial Vehicle UsingARM-based Stereo Vision Pre-Processing System”. En: Annalen der Physik 322.10 (1905),pags. 891-921. doi: http://dx.doi.org/10.1002/andp.19053221004.

[10] Albert Einstein. “Fast Onboard Stereo Vision for UAVs”. En: Annalen der Physik 322.10(1905), pags. 891-921. doi: http://dx.doi.org/10.1002/andp.19053221004.

[11] Albert Einstein. “GIMME2 - an embedded system for stereo vision and processing of megapi-xel images with FPGA-acceleration”. En: Annalen der Physik 322.10 (1905), pags. 891-921.doi: http://dx.doi.org/10.1002/andp.19053221004.

[12] FreeCad. FreeCAD: An open-source parametric 3D CAD modeler. url: https : / / www .

freecadweb.org/.

[13] IDS. url: https://en.ids-imaging.com/store/ui-5241le-mb.html.

[14] IDS. url: https://en.ids-imaging.com/manuals-ueye-api.html.

[15] Linaro. Linaro - Leading collaboration in the ARM Ecosystem. url: https://www.linaro.org/.

49


[16] PYNQ. PYNQ: pyhton productivity for zynq. url: http://www.pynq.io/.

[17] Tracita. Virtual Reality for Consumer Markets. url: https://www.tractica.com/research/virtual-reality-for-consumer-markets/.

[18] Xilinx. AXI Video Direct Memory Access v6.2. 2016. url: https://www.xilinx.com/

support/documentation/ip_documentation/axi_vdma/v6_2/pg020_axi_vdma.pdf.

[19] Xilinx. Gimme2 stereovision system. url: https://www.xilinx.com/products/boards-and-kits/1-3bwl4k.html.

[20] Xilinx. linux-xlnx: The official Linux kernel from Xilinx. url: https://github.com/Xilinx/linux-xlnx.

[21] Xilinx. LogiCORE IP Video Timing Controller. 2013. url: https://www.xilinx.com/

support/documentation/ip_documentation/v_tc/v6_0/pg016_v_tc.pdf.

[22] Xilinx. MIO and EMIO Configuration for Zynq-7000. url: https://www.xilinx.com/

video/soc/mio-emio-configuration-zynq-7000.html.

[23] Xilinx. Zynq-7000 All Programmable SoC Data Sheet. url: https://www.xilinx.com/

support/documentation/data_sheets/ds190-Zynq-7000-Overview.pdf.

50

plataforma de adquisici on de v deo con salida hdmi sobre...

Documents