“Diseño de una Estructura de Trabajo (RF) para el ...aplicaciones y finalmente probar su...

INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA

UNIDAD PROFESIONAL ADOLFO LÓPEZ MATEOS “ZACATENCO”

SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN

“Diseño de una Estructura de Trabajo (RF) para el procesamiento de video en Tiempo Real”

TESIS

Que para obtener el grado de

MAESTRO EN CIENCIAS EN INGENIERÍA ELECTRÓNICA

Presenta:

Ing. Mario Dehesa González

Directores de Tesis:

Dr. Alberto Jorge Rosales Silva Dr. Alfredo Ramírez García

México D.F. Agosto de 2013

INSTITUTO POLITECNICO NACIONAL

SECRETARIA DE INVESTIGACION Y POSGRADO

CARTA DE CESIÓN DE DERECHOS

En la ciudad de México, D. F. el día 5 del mes de Junio del año 2013, el (la) que suscribe Mario Dehesa González, alumno (a) del Programa de Maestría en Ciencias en Ingeniería Electrónica con número de registro B110290, adscrito a la Sección de Estudios de Posgrado e Investigación de la Escuela Superior de Ingeniería Mecánica y Eléctrica Unidad Profesional Adolfo López Mateos “Zacatenco”, manifiesta que es autor (a) intelectual del presente trabajo de tesis bajo la dirección del Dr. Alberto Jorge Rosales Silva y el Dr. Alfredo Ramírez García y ceden los derechos del trabajo intitulado “Diseño de una Estructura de Trabajo (RF) para el procesamiento de video en Tiempo Real” al Instituto Politécnico Nacional para su difusión, con fines académicos y de investigación.

Los usuarios de la información no deben reproducir el contenido textual, gráficas o datos del trabajo sin el permiso expreso del autor y del director del trabajo. Este puede ser obtenido escribiendo a la siguiente dirección: [email protected], [email protected], [email protected]. Si el permiso se otorga, el usuario deberá dar el agradecimiento correspondiente y citar la fuente del mismo.

.

Nombre y firma Mario Dehesa González

I

Resumen Este trabajo se enfoca en la creación de una estructura de trabajo nivel cinco (RF5) para el procesamiento de video en el módulo de evaluación (EVM) TMS320DM6437 DSP (Procesador Digital de Señales serie TMS320), utilizando el modelo de RF5 de Texas Instruments (TI). La implementación de la estructura de trabajo nivel cinco, consta de la creación de módulos de comunicación para aprovechar la arquitectura del procesador, y la programación de tareas (entrada, proceso, salida, control), canales y células (contenedores de algoritmos), de esta manera se tiene un código fuente general para posteriormente utilizarlo en la creación de aplicaciones personalizadas, y resolver problemas de programación de hardware, además de poder reutilizar el código fuente en diferentes aplicaciones (como por ejemplo detección de bordes, supresión de ruido, imagenología medica, etc.). De esta manera el diseñador podrá enfocarse solo en la personalización de su aplicación.

Abstract This work focuses on creating a Reference Framework, level 5 (RF) for video processing, in the evaluation module (EVM) TMS320DM6437 DSP (Digital Signal Processor TMS320 series), using the model RF5 of Texas Instruments (TI). The implementation of the Reference Framework 5 consists of the creation of communication modules to take advantage of the processor architecture and programming tasks (input, process, output, control), channels and cells (algorithms container), this way you a general source before in the creation of custom applications, and solving problems of hardware programming and reuse code in different applications (such as edge detection, noise suppression, imaging medical, etc.). In this way the designer can focus only on the customization of your application.

II Diseño de una Estructura de Trabajo (RF) para el procesamiento de video en Tiempo Real

Planteamiento del problema El poder realizar desarrollos tecnológicos en el área de procesamiento de imágenes, implica no solo la investigación de algoritmos para resolver una gran cantidad de problemas entre los que podemos destacar los relacionados con el realce de una imagen, extracción de información contenida en imágenes, detección de movimiento, eliminación de ruido, detección de bordes, segmentación de la imagen, etc., para la interpretación y análisis de un sistema automatizado, que le ayudará a tomar decisiones o también para extracción de la información relativa a la percepción de una máquina.

Realizar la implementación en hardware de un algoritmo, implica el estudio de diferentes procesadores existentes en el mercado que sea acorde a las necesidades del problema. Por lo general lo que se hace es implementar en un procesador conocido un algoritmo, por la experiencia que se tiene en él, debido a que se conoce la plataforma de programación y la arquitectura del mismo (todos estos conocimientos requieren de por lo menos un año de tiempo de experimentación, según nuestra experiencia), por esta razón difícilmente nos arriesgamos a tomar un nuevo procesador para no tener que volver a empezar el aprendizaje de programación de hardware, además de que los procesadores especializados en la investigación de procesamiento de imágenes y video son de precios muy elevados.

Por esta razón es necesario recurrir a un procesador que tenga las características de poder hacer implementaciones de procesamiento de imágenes y video, y que el costo sea menor a un procesador de investigación. Además de crear una estructura de trabajo específica para el procesador elegido que nos ayude a avanzar rápidamente en el conocimiento del hardware, iniciar un proyecto, integrarlo y realizar pruebas, de esta manera el investigador no ocupará tiempo en el aprendizaje de una nueva plataforma y solo se concentrará en la investigación del algoritmo y la integración a la estructura de trabajo.

III

Objetivo general Analizar la arquitectura del procesador TMS320DM6437 e implementar la estructura de trabajo nivel cinco (RF5) como herramienta de ayuda a la rápida implementación de aplicaciones y finalmente probar su funcionalidad con un algoritmo de procesamiento de video en tiempo real.

Objetivos particulares Analizar la arquitectura del procesador TMS320DM6437.

Estudiar las estructuras de trabajo RF1, RF3, y RF5 de Texas Instruments.

Realizar pruebas de detección de bordes en video utilizando el Simulink de MatLab como generador de código en lenguaje C y compilarlo en CCS.

Realizar la medición del tiempo de procesamiento del algoritmo de detección de bordes (generado por Simulink de MatLab) en el procesador TMS320DM6437.

Implementar la RF5 para el procesador TMS320DM6437.

Integrar un algoritmo XDAIS de procesamiento de video en una célula para su ejecución en tiempo real.

Medir el tiempo de procesamiento del algoritmo de detección de bordes utilizando la RF5.

IV Diseño de una Estructura de Trabajo (RF) para el procesamiento de video en Tiempo Real

Justificación La utilización de hardware de arquitectura especifica nos permite tener grandes capacidades (arquitectura VLIW, IDMA, EDMA3, etc) para las operaciones matemática de una señal digital (caracterizado por la representación en el dominio del tiempo discreto y el dominio de la frecuencia discreta), lo que permite mejorar de forma exponencial la manera de crear aplicaciones en los DSPs, algunos ejemplos de su utilización los podemos encontrar en la detección de movimiento [1], detección de placas de vehículo [2], entre otros. En donde el software de programación se basa en el Code Composer Studio (CCS) y los eXpressDSP Software Technology.

TI ha plasmado toda su experiencia de programación en el desarrollo de diferentes estructuras de trabajo (RF1, RF3, y RF5) para diversas aplicaciones y procesadores, la RF es un código genérico que es utilizado por el DSP/BIOS [3] exclusivo del DSP y los algoritmos estándar XDAIS. Una característica muy especial de la RF es su flexibilidad para ajustarse a cualquier proyecto sin que sufra muchas modificaciones el código fuente, además de utilizar un conjunto de herramientas de Software compatibles para los DSPs TMS320 llamada eXpressDSP [4].

La característica más importante de una RF dentro del diseño de un proyecto es eliminar las necesidades de administración de recursos de hardware (diseño de la plataforma o sistema operativo), construcción del prototipo, y acelerar el diseño e implementación de aplicaciones.

La RF es un modelo de aplicación, donde existen políticas de administración de memoria, tareas y la encapsulación de canales, para que el desarrollador se pueda concentrar en las necesidades de su aplicación y evitar la construcción y administración de recursos de hardware de un sistema específico para su aplicación.

Al implementar una RF en un procesador que tiene la posibilidad de realizar análisis de imágenes/video. Podrá ser utilizado para la investigación y desarrollo de algoritmos de procesamiento de imágenes/video, y utilizando la RF más flexible es posible adaptar un mayor número de algoritmos en el DSP de forma mas sencilla y por consecuencia gracias a su administración de recursos de hardware se mejorara el tiempo de procesamiento de información en video.

V

Alcance del proyecto Implementar una estructura de trabajo (RF) que nos permita utilizar un procesador especializado en la industria e investigación que posea herramientas de procesamiento de imagen/video y nos permita implementar la RF.

Al implementar la RF5 en el procesador TMS320DM6437, los recursos en hardware que contiene el DSP TMS320DM6437 se administraran a manera de que el procesamiento de algoritmos sea mucho más eficiente para poder tener un sistema en tiempo real.

Al concluir la implementación de la estructura de trabajo para el TMS320DM6437 se contará con una herramienta para ser utilizada para la investigación y desarrollo en el campo de procesamiento de imágenes, visión artificial, detección de movimiento, seguridad industrial, vigilancia, etc. Que permitirá la rápida implementación del proyecto y realización de pruebas del algoritmo.

Por las características de la RF, su utilización principal es en la industria para el desarrollo rápido de proyectos, pero al realizar la implementación en el procesador TMS320DM6437 su utilidad permitirá que este procesador y todas sus características sean para la investigación y desarrollo de algoritmos en el laboratorio de señales y sistemas de la SEPI en ESIME Zacatenco, y obtener resultados en el rendimiento y comportamiento del algoritmo, además de evaluar su comportamiento en ambientes reales, y probar diferentes fuentes de adquisición de información (cámaras web, reproductores dvd, cámaras de seguridad, cámaras portátiles, etc.) que puedan ser compatibles con el módulo de procesamiento de video del procesador TMS320DM6437.

VI Diseño de una Estructura de Trabajo (RF) para el procesamiento de video en Tiempo Real

Índice Capítulo 1. Introducción ....................................................................................... 1

1.1 Operaciones de Nivel Bajo ............................................................................................. 3 1.2 Operaciones de Nivel Intermedio ................................................................................... 4 1.3 Operaciones de Nivel Alto .............................................................................................. 4 1.4 Hardware de propósito general ...................................................................................... 5 1.5 Hardware de propósito especifico .................................................................................. 5 1.6 Procesador Digital de Señales (DSP) ............................................................................... 6 1.7 Familia TMS320DM64x .................................................................................................. 7

1.7.1 Familia DaVinci ............................................................................................................. 10 1.8 Estructuras de Trabajo ................................................................................................. 12 1.9 Conclusiones ................................................................................................................ 13

Capítulo 2. Características del procesador de video digital propuesto ................. 14 2.1 Características del dispositivo TMS320DM6437 ............................................................ 17 2.2 CPU (Núcleo del DSP) ................................................................................................... 18 2.3 Mapa de Memoria ....................................................................................................... 18 2.4 Consideraciones del Reloj ............................................................................................ 20 2.5 Secuencia de arranque del TMS320DM6437 ................................................................. 20

2.5.1 Modos de arranque ..................................................................................................... 21 2.6 Interconexión interna del Sistema ................................................................................ 21 2.7 Subsistema de Procesamiento de Video (VPSS) ............................................................ 21

2.7.1 Procesamiento de Video Front‐End (VPFE) .................................................................. 22 2.7.2 Controlador de CCD (CCDC) ......................................................................................... 24 2.7.3 Motor de Vista Previa .................................................................................................. 24 2.7.4 Redimensionador ......................................................................................................... 25 2.7.5 Hardware 3A (H3A) ...................................................................................................... 25 2.7.6 Histograma ................................................................................................................... 26 2.7.7 Codificador de video (VENC) ........................................................................................ 27

2.8 Receptor/Transmisor Universal Asíncrono (UART) ....................................................... 27 2.9 Comunicaciones entre circuitos (I2C) ............................................................................ 28 2.10 Conclusión ................................................................................................................. 29

Capítulo 3. Estructuras de trabajo (RFs) .............................................................. 30 3.1 Estructura de trabajo nivel uno (RF1) ........................................................................... 33 3.2 Estructura de trabajo nivel tres (RF3) ........................................................................... 35 3.3 Estructura de trabajo nivel cinco (RF5) ......................................................................... 36

3.3.1 Justificación de la migración y adaptación de la estructura de trabajo nivel cinco al procesador TMS320DM6437 .................................................................................................... 37 3.3.2 Características principales de la RF5 ............................................................................ 38 3.3.3 Arquitectura de la estructura de trabajo nivel cinco ................................................... 38

VII

3.3.4 Comunicación entre los diferentes módulos ............................................................... 40 3.4 Desarrollo de aplicaciones ............................................................................................ 42

3.4.1 Arquitectura para el diseño de aplicaciones ................................................................ 42 3.4.2 Modo de operación del canal ...................................................................................... 43 3.4.3 Solicitud de envíos de E/S ............................................................................................ 44 3.4.4 Control de un dispositivo ............................................................................................. 44

3.5 Controladores de Clase ................................................................................................ 44 3.5.1 Adaptador SIO (DIO) .................................................................................................... 44 3.5.2 Módulo PIP ................................................................................................................... 46 3.5.3 Controlador clase GIO .................................................................................................. 46

3.6 Conclusiones ................................................................................................................ 46

Capítulo 4. Diseño e implementación de la RF5 en el procesador TMS320DM6437 utilizando un algoritmo de detección de bordes y resultados de

tiempo de procesamiento ........................................................................................ 47 4.1 Configuración del DSP/BIOS ......................................................................................... 47 4.2 Modificación de la memoria interna ............................................................................. 48 4.3 Programación del subsistema de procesamiento de video ........................................... 50 4.4 Ajustes del temporizador ............................................................................................. 51 4.5 Archivos de aplicación para la RF5 en el procesador DM6437 ....................................... 53 4.6 Adaptación de la RF5 .................................................................................................... 54

4.6.1 Agregar nuevo código fuente para los módulos .......................................................... 54 4.7 Adaptación de un algoritmo de detección de bordes en la estructura de trabajo nivel cinco 56 4.8 Estructura del árbol de navegación de la RF5 ............................................................... 58 4.9 Implementación de un algoritmo de detección de bordes utilizando la estructura de trabajo nivel cinco ................................................................................................................. 59

4.9.1 Arquitectura de software y flujo de datos ................................................................... 60 4.10 Arquitectura de la Tarea de Captura .......................................................................... 61 4.11 Arquitectura de la Tarea Proceso ............................................................................... 62 4.12 Personalización de la RF5 ........................................................................................... 63

4.12.1 Creación del canal de procesamiento ........................................................................ 63 4.12.2 Procedimiento para habilitar e inicializar el canal ..................................................... 65 4.12.3 Condiciones para agregar una célula ......................................................................... 65

4.13 Arquitectura de la Tarea Display ................................................................................ 66 4.14 Análisis en tiempo real utilizando el DSP/BIOS ........................................................... 67

4.14.1 Módulo UTL ............................................................................................................... 67 4.15 Conclusiones .............................................................................................................. 69

Capítulo 5. Conclusiones y trabajo a futuro ......................................................... 71 5.1 Trabajo a futuro ........................................................................................................... 72

Referencias ............................................................................................................. 73

VIII Diseño de una Estructura de Trabajo (RF) para el procesamiento de video en Tiempo Real

Anexos .................................................................................................................... 77

Índice de figuras Figura 1.1. Pirámide de procesamiento de operaciones. (Kehtarnavaz & Gamadia, 2006) ............................... 3 Figura 1.2. Paralelismo en Nivel bajo (a) punto, (b) vecindad, y (c) global para operaciones de procesamiento de imagen y video. .............................................................................................................................................. 4 Figura 1.3. Diagrama de bloques de la familia TMS320DM64x. ........................................................................ 7 Figura 1.4. Jerarquía de la memoria del procesador TMS320DM64x. ................................................................ 8 Figura 1.5. Estructura interna del controlador DMA. ......................................................................................... 9 Figura 1.6. Diagrama de bloques de la arquitectura del procesador TMS320DM6437. ................................... 10 Figura 1.7. Arquitectura de los controladores IDMA y EDMA3. ........................................................................ 11 Figura 2.1. Diagrama de bloques de funcionalidad del procesador DM6437 (Texas Instruments, 2008) pág. 12. ..................................................................................................................................................................... 16 Figura 2.2. Ruta de datos en el procesador TMS320C64x+ (Núcleo del DSP) (Texas Instruments). .................. 19 Figura 2.3. Diagrama de bloques de la interconexión del sistema. .................................................................. 23 Figura 2.4. Diagrama de bloques del módulo I2C. ............................................................................................ 29 Figura 3.1. Etapas de desarrollo de un proyecto. ............................................................................................. 30 Figura 3.2. Creación de un pequeño sistema a un sistema complejo. .............................................................. 32 Figura 3.3. Creación de un sistema utilizando las estructuras de trabajo. ....................................................... 33 Figura 3.4. Topología de los módulos de la RF1. ............................................................................................... 34 Figura 3.5 Topología de los módulos de la RF3. ................................................................................................ 36 Figura 3.6. Arquitectura de la estructura de trabajo nivel cinco. (Texas Instruments, 2003) ........................... 38 Figura 3.7. Comunicación entre una tarea y un controlador por medio de un objeto SIO. (Texas Instruments, 2003) ................................................................................................................................................................. 40 Figura 3.8. Comunicación entre dos tareas utilizando mensajes SCOM. (Texas Instruments, 2003) ................ 41 Figura 3.9. Comunicación intercelular utilizando objetos ICC. (Texas Instruments, 2003) ............................... 41 Figura 3.10. Componentes del controlador de un dispositivo. (Texas Instruments, 2003) ............................... 43 Figura 3.11. Transmisión de datos en una aplicación utilizando DIO. (Texas Instruments, 2003) .................... 45 Figura 4.1. Diagrama a bloques de la comunicación de la memoria interna del núcleo C64x+ (Texas Instruments). ..................................................................................................................................................... 49 Figura 4.2. Configuración en modo desencadenado del temporizador ............................................................ 52 Figura 4.3. Estructura de trabajo nivel cinco. ................................................................................................... 53 Figura 4.4. (a) Imagen original, (b) Extracción de la fila central de la imagen (a). ........................................... 57 Figura 4.5. (a) Función que representa el perfil horizontal de la imagen original. (b) Primera derivada a partir del perfil horizontal. .......................................................................................................................................... 57 Figura 4.6 Árbol de navegación de la RF5. ........................................................................................................ 58 Figura 4.7 Procesamiento de un algoritmo de detección de bordes utilizando la RF5. .................................... 59 Figura 4.8. Flujo de datos de la aplicación. ....................................................................................................... 60 Figura 4.9. Digitalización de la señal de video. ................................................................................................. 61 Figura 4.10. Almacenamiento de la imagen en la memoria externa (VPFE). (Texas Instruments, 2008) ......... 62 Figura 4.11. Modificación del archivo thrProcess.h para inicializar canales y células. ..................................... 64 Figura 4.12. Conversión digital analógica. ........................................................................................................ 66 Figura 4.13. Tiempo de procesamiento para tres tramas diferentes. ............................................................... 69

IX

Índice de tablas Tabla 1. Características del procesador DM6437. [19] ..................................................................................... 17 Tabla 2 Descripción de Registros VPSS. [22] ..................................................................................................... 22 Tabla 3. Procesadores que pueden utilizar las estructuras de trabajo. ............................................................ 37 Tabla 4. Registro de memoria L1 ...................................................................................................................... 48 Tabla 5. Registro de memoria L2 ...................................................................................................................... 49 Tabla 6. Tabla de descripción del Control de Registros del Temporizador Global. ........................................... 52 Tabla 7. Cuadro comparativo de tiempo de procesamiento de un algoritmo con RF5 y sin RF5 en una trama. .......................................................................................................................................................................... 68 Tabla 8. Cuadros por segundo procesados en un algoritmo de detección de bordes con RF5 y sin RF5. .......... 68 Tabla 9. Tiempo de procesamiento para una trama utilizando el procesador DM642 con una estructura de trabajo nivel cinco. ............................................................................................................................................ 69 Tabla 10. Tiempo de procesamiento de una trama con un algoritmo FVM en un IDK. .................................... 69

X Diseño de una Estructura de Trabajo (RF) para el procesamiento de video en Tiempo Real

Acrónimos Acrónimo Español Inglés

API Interfaz de programación de aplicaciones Application Programming Interface

ASIC Circuito Integrado para Aplicaciones Especificas Application-Specific Integrated Circuit

BIN

Un bin es una subdivisión en la escala de intensidad de una imagen, por lo general se utilizan 256, si por ejemplo, se utilizan dos bins, existirán dos regiones (una de 0 a 127 y otra de 128 a 255)

CCL Librería de soporte de chip Chip Support Library

CCS Code Composer Studio

CPU Unidad Central de Procesamiento Central Processing Unit

D1 Formato de video de 704 x 480 pixeles

DAC Convertidor Digital Analógico Digital Analog Converter

DDR2 Double Data Rate 2

DLP Paralelismo a nivel de datos Data Level Parallelism

DMA Acceso Directo a Memoria Direct Memory Access

DSP Procesador Digital de Señales Digital Signal Processor

EDMA3 Acceso Directo a Memoria Mejorado Enhanced Direct Memory Access 3

EMAC Ethernet MAC Ethernet Media Access Control

EMIF Interface de Memoria Externa External Memory Interface

EVM Módulo de evaluación Evaluation Module

FPGA Arreglo de compuertas lógicas programables Field-programmable Gate Array

I2C Inter-Circuitos Integrados Inter-Integrated Circuit

XI

Acrónimo Español Inglés

IDK Kit de desarrollo de imágenes Imaging Developer’s Kit

IDMA DMA Interno Internal DMA

ILP Paralelismo a nivel de instrucciones Instruction Level Parallelism

KW Kilopalabra = 1024 palabras Kiloword

L1 Memoria Nivel 1 Level 1

L1D Memoria Nivel 1 de Datos L1 Data

L1P Memoria Nivel 1 de Programa L1 Program

L2 Memoria Nivel 2 Level 2

McASP Puerto Serie Asíncrono Multicanal Multichannel Asynchronous Serial Port

McBSP Puerto Serie Multicanal con capacidad de almacenamiento Peripheral Component Interconnect

RF5 Estructura de trabajo nivel 5 Reference Framework 5

RTOS Sistema operativo en tiempo real Real Time Operating System

SCOM Comunicaciones sincronizadas Synchronous Communications

TGCR Control de registros del temporizador global Timer Global Control Register

UART Transmisor-Receptor Asíncrono Universal

Universal Asynchronous Receiver-Transmitter

VGA Adaptador de gráficos de video Video Graphics Array

VLIW Procesador de instrucciones complejas Very Long Instruction Word

VPBE Puerto de salida de video Video Processing Back End

VPFR Puerto de captura de video Video Processing Front End

VPSS Subsistema de procesamiento de video Video Processing Subsystem

XDAIS eXpressDSP Algorithm Interoperability Standard

Diseño de una Estructura de Trabajo (RF) para el procesamiento de video en Tiempo Real

1

Capítulo 1. Introducción El tipo de información al que hoy en día tenemos acceso, es principalmente de carácter digital, y podemos almacenarla en archivos de datos, podemos incorporar a la vida cotidiana diversos formatos (qt, mp4, wmv, bmp, gif, tif, jpg, mp3, wav, wma, pdf) para almacenar música, libros, imágenes y video, es evidente que la portabilidad actual de todo este tipo de información no habría sido posible sin la implementación eficiente y optimizada de los algoritmos de procesamiento digital de la señal de entrada.

El procesar una imagen o video implica una gran carga computacional debido a la cantidad de información que debe ser procesada y tomando en cuenta que las diversas plataformas tienen límite de recursos computacionales como memoria y el consumo de energía.

Como la mayoría de los algoritmos que se desarrollan para procesar imágenes digitales y video requieren una gran demanda del hardware de propósito general, es necesario recurrir a procesadores especializados con toma de decisiones (Trade Off)1 [5] para llegar a una decisión aceptable en la ejecución del algoritmo que dependerá del resultado al que se desea llegar.

El tiempo real en el procesamiento de imágenes/video toma en cuenta el procesamiento de grandes cantidades de datos con el propósito de extraer información útil en un tiempo determinado dependiendo de la aplicación. Un tema muy importante es como poder procesar grandes cantidades de datos y cálculos en tiempo real, por ejemplo, una video cámara VGA tiene una resolución de 640 x 480 pixeles a 30 cuadros por segundo (fps), se necesitaría realizar un procesamiento aproximado de 28 millones de pixeles por segundo, considerando que hoy en día ya es común encontrar cámaras de alta definición, que tienen una resolución de 1280 x 720 pixeles a 30 fps, se necesitaría realizar el procesamiento de 83 millones de pixeles por segundo. Una forma de poder realizar el procesamiento de esta cantidad de datos es mediante el procesamiento en paralelo, realizado por procesadores especializados [6].

1 Trade-off: Consiste en agilizar la ejecución de un algoritmo de tal manera que el sistema se vuelve controlado tomando las decisiones correctas de ejecución del algoritmo, evitando que el sistema se vuelva caótico. Por ejemplo: Supongamos que un algoritmo trabaja de manera secuencial. La lógica de este algoritmo funciona de la siguiente manera: éste va a avanzar hasta descubrir una solución; checa si la solución es óptima y, si no lo es, continúa buscando la siguiente solución. Por otro lado, existen algoritmos que, si bien trabajan de manera secuencial, brindan información de contexto (local) y ofrecen visión a futuro, de manera de poder anticiparse y llegar antes al objetivo deseado para hacer más ágil la búsqueda. Por ejemplo, teniendo en cuenta información local, el algoritmo podría darse cuenta a mitad de camino, que el camino seleccionado no es el que busca y así comenzar a recorrer un nuevo camino (solución) antes de llegar al final de ese. En estos casos, si se toma demasiada información de contexto, pretendiendo saber demasiado sobre el futuro, el algoritmo puede ser más lento que un algoritmo secuencial.

2 Diseño de una Estructura de Trabajo (RF) para el procesamiento de video en Tiempo Real

Existen dos formas de paralelismo en un algoritmo a nivel de datos, DLP (Data Level Parallelism) y a nivel de instrucciones, ILP (Instruction Level Parallelism). El DLP se presenta en la aplicación de la misma operación en diferentes conjuntos de datos y la ILP está presente en la programación simultánea de múltiples operaciones independientes [7].

Un ejemplo de DLP es el cálculo del área bajo la curva por medio de una integración, que basta con dividir el intervalo de integración entre todos los procesadores disponibles y que cada uno resuelva su fragmento sin preocuparse de lo que hacen los demás, al final, todos los resultados parciales se recolectan y se suman. Con “n” procesadores el problema se puede resolver “n” veces más rápido que haciendo uso de uno solo [8].

El ILP es un modelo computacional que se basa en que una aplicación consiste de varias tareas y cada tarea es responsable de una parte de la carga del procesamiento de la aplicación en general y a su vez cada tarea realiza una operación independiente. Los algoritmos de cada tarea son diferentes y se pueden aprovechar las características particulares de cada uno para ejecutarlas en el CPU. Por ejemplo la ecuación ( 1 ) :

( 1 )

Suponiendo que cada instrucción se ejecuta en un ciclo de reloj en forma secuencial, entonces nos tomaría 3 ciclos de reloj terminar estas operaciones. Como podemos ver las instrucciones “e” y “f” son independientes por lo tanto las podemos ejecutar en el mismo ciclo de reloj en un procesamiento tipo ILP, y “g” espera los resultados de “e” y “f”, por lo tanto el tiempo de ejecución será de solo dos ciclos de reloj, lo que significa que es 3/2 más rápido [9].

Estos desarrollos hoy en día los podemos ver aplicados en distintas áreas como la navegación, robótica, biología, geología, meteorología, medicina, identificación de construcciones, inspección, control de calidad, cartografía, etc.

Las operaciones involucradas en el procesamiento tradicional de imágenes/video es clasificado en tres niveles, bajo, intermedio y alto donde cada nivel posterior se diferencia del anterior en su número de entradas/salidas de datos [10]. En los operadores de bajo nivel tenemos una imagen de entrada y se produce una imagen de salida, con los operadores de nivel intermedio, se toma una imagen de entrada, y a la salida tenemos los atributos pertenecientes a la imagen, como pueden ser detección de bordes, líneas, curvas u otros atributos de la imagen, y por último los operadores de alto nivel, toman los atributos pertenecientes a una imagen e interpretan esta información que nos proporciona algún tipo de conocimiento, como por ejemplo la clasificación y reconocimiento de objetos o la toma de decisiones basándose en las características extraídas de la escena. Esta clasificación puede representarse como una pirámide en donde las operaciones con pixeles y de control


3

se encuentran en el nivel inferior, las operaciones de extracción de características se encuentran en el nivel intermedio y las operaciones para la adquisición de conocimiento se encuentran en la parte superior, ver Figura 1.1.

Figura 1.1. Pirámide de procesamiento de operaciones. [6]

Para realizar la tarea de muestreo de la señal, digitalización de video, procesamiento y análisis en tiempo real, implica una gran cantidad de cálculos matemáticos. Estas tareas se pueden realizar con diferentes alternativas tecnológicas, como son: El hardware de propósito general, hardware de propósito específico y el procesador digital de señales (DSP).

1.1 Operaciones de Nivel Bajo Estas operaciones también son conocidas como operaciones directas con la matriz de datos de la imagen. En estas operaciones podemos encontrar las transformaciones de color, corrección de la gamma, filtros lineales y no lineales, reducción de ruido, transformaciones en el dominio de la frecuencia, etc. [11]. El objetivo de estas operaciones es mejorar visiblemente los datos de la imagen posiblemente enfatizando ciertas características determinadas o preparando las características para el procesamiento del Nivel intermedio.

Estas operaciones pueden ser mejor clasificadas como punto, vecindad y operaciones globales [12]. Las operaciones punto son simplemente en donde tenemos un pixel de entrada y otro pixel de salida, en donde la transformación no depende de los pixeles que rodean al pixel de entrada, este tipo de operaciones contempla las operaciones aritméticas, operaciones lógicas, búsquedas en la tabla, operaciones de umbral, etc. Aquí es evidente el uso de DLP como se muestra en la Figura 1.2 (a).

Las operaciones de vecindad son más complejas que las operaciones punto, ya que el pixel de salida depende de los pixeles que rodean al pixel de entrada. En este tipo de operaciones podemos incluir la convolución y filtrado espacial, suavizado, mejoramiento de la imagen, etc. Dado que cada pixel de salida se encuentra en función de cada pixel de entrada y sus


vecinos como se muestra en la Figura 1.2 (b), estas operaciones requieren una gran cantidad de cálculos y por este motivo es necesaria la aplicación de procesamientos en paralelo.

Las operaciones globales están basadas en las operaciones de vecindad en el que el pixel de salida solo depende de cada pixel de entrada en la imagen como se muestra en la Figura 1.2 (c). Estas operaciones son comúnmente utilizadas en la Transformada de Fourier discreta que depende de la imagen completa.

Figura 1.2. Paralelismo en Nivel bajo (a) punto, (b) vecindad, y (c) global para operaciones de procesamiento de imagen y video.

1.2 Operaciones de Nivel Intermedio En este tipo de operaciones la transformación de datos de la imagen se ve modificada mediante la extracción de ciertos atributos o características de interés de una imagen. En este tipo de operaciones podemos encontrar la segmentación de la imagen en regiones y objetos de interés, detección de bordes, líneas, curvas u otros atributos de la imagen tales como las funciones estadísticas (media, mediana, desviación estándar, etc.). El objeto del Nivel intermedio de operaciones es reducir la cantidad de datos para formar un conjunto adecuado de características (transformaciones de color, corrección de la gamma, filtros lineales y no lineales, reducción de ruido) para el procesamiento a Nivel alto [11].

1.3 Operaciones de Nivel Alto Es el encargado de interpretar los resultados abstractos del Nivel intermedio, las operaciones de Nivel alto se encargan de realizar el análisis de la escena basándose en un conocimiento previo, entre las operaciones que se ejecutan en este nivel están incluidas la

Imagen de entrada

Nivel alto

Imagen de salida Imagen de entrada Imagen de salida

Imagen de salida Imagen de entrada

(a) (b)

(c)


5

clasificación y reconocimiento de objetos o la toma de decisiones basándose en las características extraídas de la escena. Este tipo de operaciones está caracterizado por el control sobre las operaciones realizadas, en este tipo de procesamiento las operaciones son más secuenciales que paralelas, pero debido a sus irregularidades son candidatas para utilizar el ILP [11].

Los algoritmos para el procesamiento de video son muy exigentes en cuanto a los recursos computacionales que necesitan de recursos tecnológicos con una capacidad de cómputo elevada. Hoy en día podemos encontrar diferentes alternativas para poder implementar algoritmos de procesamiento de video y los podemos clasificar en tres grupos: Hardware de Propósito General, Hardware de Propósito Específico y los basados en DSP´s.

1.4 Hardware de propósito general Este tipo de hardware puede implementar diversos estándares de codificación entre los que podemos encontrar C y C++. Un ejemplo muy claro de este tipo de tecnología lo podemos encontrar en los procesadores utilizados por las computadoras personales o de escritorio, este tipo de procesadores son capaces de realizar el muestreo, digitalización y análisis del video en tiempo real, y todo esto sin utilizar el 100% de su capacidad, otra ventaja de este tipo de tecnología es que permite la ejecución de software aunque este no se encuentre optimizado para la arquitectura especifica del microprocesador. Las desventajas que presenta el Hardware de propósito general es que no se encuentran optimizados para una arquitectura concreta, así como su elevado consumo de energía y precio.

Ejemplo de hardware de propósito general:

• Procesadores Intel [13]: Este tipo de procesadores ofrecen procesamiento multitarea, aumento en sus operaciones visuales en su tarjeta de video dedicada y administrando mejor el uso de la energía.

• Procesadores ARM [14]: Este tipo de procesadores son muy utilizados para ejecutar sistemas operativos RTOS (Real-Time Operating System), los podemos encontrar en sensores inteligentes, televisión digital, Smartphones, Sistemas de frenado, etc.

1.5 Hardware de propósito especifico Este tipo de tecnología ha venido creciendo durante los últimos años, y fue creada específicamente para utilizarse con arquitecturas especialmente diseñadas para minimizar tiempos de procesamiento y en muchos casos mejorar el consumo de energía. La mayor parte de estas tecnologías ocupan FPGA con tecnología ASIC (Circuito Integrado para


Aplicaciones Específicas), este tipo de circuitos están hechos para un uso específico, con diseños más pequeños, con la desventaja de que se fabrican en pequeñas líneas de producción y el costo final de cada FPGA es muy alto comparado con un FPGA de uso general, este tipo de hardware también tiene la ventaja de procesar video en tiempo real con bajos consumos de energía. Entre las desventajas que tiene este tipo de Hardware se encuentra su poca flexibilidad ya que una vez que se han fabricado son difícilmente adaptables a modificaciones que se produzcan por ejemplo en el tamaño de captura de imagen.

1.6 Procesador Digital de Señales (DSP) En 1979 Bell Labs lanza el primer Procesador Digital de Señales "The Mac 4 Microprocessor", después en 1980 NEC presenta el primer DSP completo, el PD7710 y AT&T presenta el DSP1 [15]. El primer DSP producido por Texas Instruments (TI) "TMS32010" fue presentado el 8 de abril de 1983, este procesador contenía ya algunas variantes con respecto a otros, como la arquitectura de punto fijo y punto flotante. El estudio de los DSP’s en la actualidad es de gran importancia y además existen diversos fabricantes que construyen este tipo de tecnología entre los que se encuentran: TI, NXP y Analog Devices. Cada fabricante tiene DSP’s que se ajustan a diferentes campos de aplicación entre los que podemos encontrar los orientados al desarrollo de aplicaciones de video.

Las diferencias que podemos encontrar entre los DSP’s de las diferentes compañías son la cantidad de memoria interna que contienen y los periféricos que lo integran [16]. En la última década han aparecido DSP´s especializados en el procesamiento de video, estos DSP´s poseen una arquitectura que facilita la implementación de estas aplicaciones e incluyen periféricos (puertos de entrada y salida de video, puertos Ethernet, puertos de audio, etc.), que son de gran importancia en el área de procesamiento de video.

Los DSP´s tienen la ventaja de flexibilidad del Hardware de Propósito General, ya que pueden adaptarse o modificar el sistema de video con el que se esté trabajando solamente modificando el programa que ejecutan, además de una adecuada ejecución de algoritmos de análisis de video que pueden llegar a alcanzar las velocidades del Hardware específico.

Entre los fabricantes de DSP´s más destacados se encuentra TI, el cual dispone de varias familias de DSP’s orientadas al desarrollo de aplicaciones de video, en el siguiente subtema vamos a ver las características de la familia DaVinci de TI.


7

1.7 Familia TMS320DM64x Esta familia de DSP’s de TI actualmente se compone de las siguientes subfamilias: TMS320DM648x, TMS320DM647x, TMS320DM643x, TMS320DM642x, TMS320DM641x, TMS320DM640x. En la Figura 1.3 podemos ver la estructura interna que poseen todos los procesadores de esta familia.

Figura 1.3. Diagrama de bloques de la familia TMS320DM64x.

El núcleo de esta familia TMS320DM64x está integrado por una arquitectura de Procesador de Instrucciones Complejas (VLIW), que puede realizar hasta ocho operaciones de forma simultánea en un solo ciclo de reloj con datos de 32 bits, este rendimiento se logra gracias a sus 8 unidades funcionales y 64 registros internos de 32 bits. Las unidades funcionales se encuentran agrupadas en 2 rutas de datos y cada uno con 4 unidades idénticas que operan principalmente con los registros de ruta de datos a la que pertenecen con una capacidad limitada para acceder a registros de otra ruta. La memoria del procesador está organizada jerárquicamente en tres niveles como se muestra en la Figura 1.4. Los dos primeros niveles (L1 y L2) son internos al procesador, mientras que el tercero es la Memoria Externa. El primer nivel es de tipo caché y siempre está en estado activo, ya que solo en este nivel el CPU trabaja directamente. L1 a su vez está dividido en dos, uno para datos (L1D) y otro para programa (L1P), ambos con una capacidad de 16kB. El nivel L2 tiene una capacidad de 256kB y puede ser configurado como memoria de propósito general o como memoria cache de nivel 2 o ambas opciones según requiera las necesidades del software. Y por último la Memoria Externa, es externa al DSP y se conecta por medio de una Interfaz de Memoria Externa (EMIF, por sus siglas en inglés) que puede expandirse hasta un máximo de 1GB [17].


El tiempo que toma entrar a las memorias depende de su nivel de jerarquía. La memoria L1 tiene un tiempo de acceso que depende de la frecuencia del procesador (594 MHz), el L2 tiene un tiempo de acceso del doble de tiempo que la memoria L1 y la Memoria Externa tiene un tiempo programable de acceso que se encuentra determinado por el intervalo de frecuencias de 100MHz y 133Mhz [18].

Figura 1.4. Jerarquía de la memoria del procesador TMS320DM64x.

La función del controlador DMA (Acceso Directo a Memoria) es la de administrar todas las transferencias entre la memoria interna (L1 y L2) y la memoria externa o los periféricos como se muestra en la Figura 1.6. Las tareas que provocan una transferencia de datos mediante el controlador DMA están definidas por las siguientes situaciones:

• Cuando el CPU accede a un fragmento de código o de datos que se encuentran almacenados en la memoria externa.

• Si los periféricos realizan alguna transferencia de datos hacia o desde la memoria externa.

Ruta de datos, administrados por el controlador de memoria cache.


9

• Cuando el usuario programa el DMA para realizar alguna transferencia definida de datos entre la memoria interna de propósito general y la memoria externa, mediante el mecanismo llamado QDMA (Quick DMA), o también por EDMA (DMA Mejorado). Una de las ventajas de estas transferencias es que se pueden realizar en bloques de datos unidimensionales o bidimensionales.

Todas las transferencias solicitadas son almacenadas en una de las cuatro colas de petición (urgente, alta, media y baja) que posee el controlador DMA, cada cola contiene 16 posiciones por lo que puede acumular 64 peticiones. Las colas de petición tienen prioridad, lo que significa que, si existen transferencias pendientes en varias de ellas, éstas se atienden en un orden preestablecido, es posible configurar las peticiones máximas que puede realizar cada elemento de la cola de petición para acceder al controlador DMA.

Por ejemplo en la Figura 1.5, se podría pensar que las peticiones provenientes de los periféricos (representadas con el número uno), pueden acumularse en cualquiera de las 4 colas de prioridad pero solo se disponen de 4 posiciones en la cola de prioridad urgente, 7 en la de prioridad alta y 5 en las de prioridad media y baja. Lo mismo se puede indicar para las peticiones generadas por el controlador de EDMA (representadas con el número dos) y por el CPU o el usuario a través del controlador IDMA (representadas con el número tres).

L 1 (CPU)L 2 (CPU)IDMA

L 1 (CPU)L 2 (CPU)IDMA

EDMAEDMA

PeriféricosPeriféricos

split

split

1 1 1 21 2 2 2 2 2 3 3 3 3 3 3

1 1 1 11 1 1 2 2 2 2 2 2 3 3 3

1 1 1 11 2 2 2 2 2 2 2 3 3 3 3

ControladorDMA

ControladorDMA

Cola con 16 posiciones3

2

1

Figura 1.5. Estructura interna del controlador DMA.

El rendimiento de las transferencias al DMA depende de parámetros como a qué tipo de recurso se desea acceder, la cantidad de datos que tiene el buffer para transferir y su alineamiento en la memoria. En el caso de la memoria externa conectada al DSP a través de la interfaz EMIF, se pueden llegar a transferir bloques de datos de 32 bits a una velocidad de un dato por ciclo de reloj del procesador. Pero si solo se transfiere un dato de 1Byte será necesario emplear hasta 18 ciclos de reloj.

La Familia TMS320DM64x integra diversos periféricos que son de mucha utilidad para el desarrollo de aplicaciones de procesamiento de video, entre las características que podemos encontrar son 3 puertos bidireccionales de video (videoports), un puerto de acceso por


Ethernet (EMAC), un puerto serie multicanal de audio (McASP0), 3 temporizadores de 32 bits, 16 pines de entrada/salida de propósito general (GP0) y un Controlador del Bus (I2C).

Una familia muy importante de TI es la Familia DaVinci TMS320DM6437 que cuenta con un menor tamaño que sus antecesoras, mayor flexibilidad de la memoria interna, mejoras en la eficiencia del controlador de transferencias por DMA y en la ampliación en su repertorio de instrucciones, a continuación se presentan los elementos que integran esta familia.

1.7.1 Familia DaVinci Entre el hardware especializado para el procesamiento de video tenemos a la familia DaVinci con el procesador TMS320DM6437. El núcleo de este procesador también se le llama C64x+ [19], posee una arquitectura VLIW con dos niveles de memoria interna (L1, L2) y un controlador IDMA (DMA Interno) para realizar transferencias entre elementos internos (L1 y L2).

El núcleo del procesador se conecta mediante una matriz de conmutación con un conjunto de periféricos internos y un subsistema de procesado de video [20], como se muestra en el diagrama de bloques en la Figura 1.6.

Figura 1.6. Diagrama de bloques de la arquitectura del procesador TMS320DM6437.


11

El tamaño de la memoria interna es de 240kB, con cache de nivel 1 de programa (LP1) con 32kB que puede ser configurada como memoria de propósito general, cache de nivel 1 para código o se puede combinar como las dos anteriores, el cache de nivel 1 de datos (L1D) posee 80kB y también es configurable como memoria de propósito general o una combinación de ambas. La memoria L2, tiene una capacidad de 128kB que pueden ser compartidos entre memoria cache de nivel 2 y memoria de propósito general para datos y código.

La funcionalidad del DMA ha sido modificada de las familias anteriores con dos controladores independientes (IDMA y EDMA3), el IDMA que se encarga de realizar transferencias más eficientes entre las memorias internas (L1 y L2) y los periféricos, y el EDMA3, utilizado para las transferencias entre memoria externa y memoria interna. Al combinar el trabajo de los dos controladores se mejora significativamente el rendimiento, ya que reduce el empleo del CPU. En la Figura 1.7 se puede ver la relación existente entre los dos controladores de DMA y los recursos a los que puede acceder cada uno de ellos. Con estos dos controladores de DMA se pueden enlazar automáticamente transferencias sin la intervención del CPU [21].

MemoriaexternaMemoriaexterna

PeriféricosPeriféricos

EDMA3EDMA3

L 2∙ Caché∙ Propósito

general

L 2∙ C aché∙ Propósito

general

Controlador de memoria de programa L 1

Controlador de memoria de programa L 1

IDMAIDMA CPUCPU

Controlador de memoria de datos L 1

Controlador de memoria de datos L 1

L 1PL 1P

L 1DL 1D

Figura 1.7. Arquitectura de los controladores IDMA y EDMA3.

En la actualidad algunas de las familias de TI de la serie C6000 tienen la posibilidad de utilizar las llamadas estructuras de trabajo. Estas estructuras de trabajo se utilizan para


realizar implementaciones de software de manera rápida ahorrando tiempo de pruebas, así como tiempo para el desarrollo del prototipo del proyecto final.

1.8 Estructuras de Trabajo Desde que Texas Instruments presentó los DSPs con grandes capacidades de desarrollo de software, se marcó el inicio para que los desarrolladores mejoraran de forma exponencial la manera de crear aplicaciones para la familia de DSP’s TMS320, algunos ejemplos de su utilización los podemos encontrar en la detección de movimiento [1], detección de placas [2] entre otros. Donde los elementos más importantes para el desarrollo de software son: Code Composer Studio (CCS) y eXpressDSP Software Technology.

La estructura de trabajo (“Reference Frameworks” RF) es el código genérico del DSP que es utilizado por el DSP/BIOS [3] y los algoritmos estándar del TMS320DSP, esta estructura de trabajo se adapta y utiliza con un conjunto de herramientas de Software y Desarrollo para los DSP’s TMS320 llamada eXpressDSP compatibles para lograr aplicaciones específicas [4].

Además una estructura de trabajo es un modelo de aplicación, donde existen políticas de administración de memoria, de hilos y la encapsulación de canales, donde el desarrollador se puede concentrar en las necesidades de su sistema y comenzar a construir en la parte superior de la RF2. TI ofrece múltiples RFs, el uso de cada RF depende del tipo de proyecto a realizar, este trabajo de investigación se enfoca en la plataforma DSP C64x+. El código fuente proporcionado por TI para las RFs se encuentra escrito en Lenguaje C. Las RFs están diseñadas para eliminar las necesidades de diseño, construcción y pruebas de código en bajo nivel y acelerar el diseño e implementación de las aplicaciones.

La RF1 (Compacta), está diseñada para tener un Footprint3 mínimo y conserva todos los elementos eXpressDSP4. Se utiliza para la configuración de objetos estáticos sin considerar el tiempo de ejecución y la creación de objetos dinámicos. La administración de memoria es completamente estática y no es compatible con la administración de memoria dinámica. El número de canales y algoritmos soportados es como máximo tres y no existe preferencia o bloqueo de hilos.

2Las RFs nos dan la ventaja de no preocuparnos por el diseño y construcción de un sistema específico desde el inicio del proyecto. Las RFs están construidas por las librerías de soporte de chip para el dispositivo utilizado, contenedores de algoritmos, algoritmos estándar TMS320 y el código de aplicación específico, siendo este último la parte superior de la RF. 3Espacio de memoria utilizado por la aplicación. 4 Es un paquete de software producido por Texas Instruments que contiene un conjunto de herramientas utilizadas para desarrollar aplicaciones en los DSP’s producidos por TI, eXpressDSP se compone de: Un entorno de desarrollo llamado Code Composer Studio, un Sistema Operativo en tiempo real (DSP/BIOS) y algoritmos XDAIS.


13

Con la RF3 (Flexible) cambia el Footprint mínimo de la RF1 por mayor flexibilidad, solo se pueden crear objetos estáticos, pero ahora existen Buffers para la administración de la memoria dinámica, la flexibilidad consiste en el uso de más canales y algoritmos, es compatible con operaciones multi-hilo. Este nivel nos proporciona un hilo adicional para permitir el control del DSP por una unidad externa como por ejemplo un procesador Host.

Cuando necesitamos una amplia flexibilidad y el Footprint no es importante podemos utilizar la RF5 (Extensiva), donde el número de canales y algoritmos llega a más de 100, puede trabajar con un solo rango ó multi-rango5, existe prioridad, bloqueo y control dedicado de hilos.

1.9 Conclusiones Los DSPs poseen arquitecturas diseñadas especialmente para acelerar los cálculos matemáticos intensos utilizados en la mayoría de sistemas de procesamiento de señales en tiempo real. Por medio de una estructura de trabajo es posible adaptar los recursos específicos del DSP para el procesamiento de una aplicación específica.

Una estructura de trabajo es muy eficaz al trabajar con el paralelismo de un programa y así obtener la mayor cantidad de ventajas de las arquitecturas VLIW y con ello la obtención de elevadas prestaciones del DSP. Al poder realizar el desarrollo de una estructura de trabajo como la RF5 es posible utilizarla tanto en la industria como en el área de desarrollo e investigación de algoritmos de procesamiento de imágenes y video que actualmente se realizan en el laboratorio de Señales y Sistemas de SEPI Electrónica.

5La operación multi-rango permite trabajar con varias tareas a diferentes velocidades de ejecución de forma simultánea.


Capítulo 2. Características del procesador de video digital propuesto

El módulo de evaluación TMS320DM6437 es un dispositivo basado en la tercera generación de alto rendimiento llamada VelociTI con arquitectura VLIW. El núcleo del DSP llamado C64x+ [19] tiene 64 registros de propósito general con una longitud de palabra de 32 bits y ocho unidades funcionales independientes (2 multiplicadores para resultados de 32 bits y 6 Unidades Lógicas Aritméticas “ALU”), las ocho unidades funcionales incluyen instrucciones para acelerar el rendimiento en aplicaciones de video e imágenes. El núcleo del DSP puede almacenar hasta cuatro multiplicaciones acumuladas (MACs multiply-accumulates) de 16-bits por ciclo de reloj, dando un total de 2800 millones de MACs por segundo (MMACS), u ocho MACs por ciclo para un total de 5600 MMACS [22].

El núcleo del procesador DM6437 utiliza una arquitectura de dos niveles de caché. La memoria caché Nivel 1 de Programa (L1P), consiste en un espacio de memoria de 256 Kbits que puede ser configurada como memoria de propósito general o memoria caché directa; y la memoria caché nivel 1 de datos (L1D), consta de una memoria de 640 Kbits que puede ser configurada como memoria caché de propósito general o memoria caché nivel 1 de datos. La memoria caché nivel 2 (L2) se compone de un espacio de memoria de 1M bit y puede ser configurada para utilizarse como archivo mapeado6, caché o una combinación de ambos.

El conjunto de periféricos se puede adaptar a una gran diversidad de entornos y cuenta con los siguientes recursos:

Dos puertos de video configurables, un conector Ethernet MAC (EMAC) 10/100Mb, un bus de comunicaciones entre circuitos (I2C), dos puertos serie (McBSPs), un puerto de audio multicanal serie (McASP0), 2 temporizadores de 64 bits de propósito general ó 2 temporizadores de 32 bits independientes, 1 temporizador de 64 bits (Watchdog), una Interfaz de Puerto Host (HPI) [23] de 16 bits configurable por el usuario, 2 UARTs, 3 moduladores por ancho de pulso (PWM), un protocolo de comunicación CAN (Control Area Network), un sistema de expansión de periféricos (PCI) a 33MHz, 2 interfaces de memoria externa sin cola: una interfaz de memoria asíncrona externa (EMIFA) para memorias lentas y periféricos, y una interfaz para memorias sincronizadas de mayor velocidad (DDR2).

6 Un archivo de memoria asignada (memory-mapped) es una porción de memoria virtual en la que se establece una correlación directa byte a byte con una parte de un archivo o un recurso similar. Este recurso puede ser un archivo presente en la memoria externa.


15

El procesador DM6437 incluye un subsistema de procesamiento de video (VPSS) con dos periféricos configurables de Video/Imagen: 1 sistema de procesamiento de video de entrada (VPFE) utilizado para la captura de video, 1 sistema de procesamiento de video de Back-End (VPBE) utilizado para la salida de video.

El procesamiento de video Front-End (VPFE) se compone de un controlador CCD (CCDC), un motor de pre-visualización, un módulo de histograma, auto exposición/balance de blancos/módulo de enfoque (H3A) y módulo Redimensionador. La CCDC es capaz de interactuar con los decodificadores de video comunes (sensores CMOS y dispositivos de carga acoplada CCD). La pre-visualización de la imagen es un motor de procesamiento en tiempo real que toma los datos directamente del sensor CMOS o CCD y los convierte a partir de un diseño RGB a YUV422 [24]. El módulo de histograma y H3A proporciona información estadística sobre los datos obtenidos directamente del sensor para el uso del procesador DM6437. El Redimensionador acepta los datos de la imagen para cambiar el tamaño horizontal y vertical de 1/4x a 4x en incrementos de 256/N, donde N se encuentra entre 64 y 1024.

El procesamiento de video Back-End (VPBE) está compuesto por un motor de visualización en pantalla (OSD) y un codificador de video (VENC) [25]. El motor OSD es capaz de manejar 2 ventanas de video por separado y 2 ventanas separadas OSD. El VENC está compuesto por 4 DACs analógicos a 54 MHz, proporcionando un medio de video en formato NTSC/PAL, S-Video y/o salida de video compuesto. El VENC también proporciona hasta 24 bits de salida digital a un dispositivo RGB8887. La salida digital utiliza el protocolo BT.6568 de 8/16 bits de salida [26].

El control de acceso por Ethernet (EMAC) proporciona una interfaz entre el DM6437 y la red. El EMAC puede ser configurado con los estándares 10Base-T (10 Mbits/segundo) y 100Base-TX (100 Mbits/segundo).

El módulo de administración de datos de Entrada/Salida (MDIO) revisa continuamente 32 direcciones MDIO para enumerar los dispositivos PHY9 en el sistema [27].

Los buses I2C y VLYNQ permiten controlar fácilmente los dispositivos periféricos para comunicarse con los procesadores de un host.

El Controlador de CAN10 (HECC “High-End Controller Area Network”) proporciona un protocolo de control distribuido (sincroniza la comunicación entre los diferentes dispositivos) para comunicarse con otros controladores en serie.

7 RGB88: Asigna 8 bits para los canales rojo (R), verde (G) y azul (B). Normalmente se utiliza para contenidos sin comprimir. 8 Protocolo de video digital sin comprimir para transmitir en NTSC o PAL 9 PHY: Es un servicio de transmisión de datos sobre un medio físico y provee de una interfaz con el dispositivo de gestión del nivel físico, por medio del cual se puede acceder a todos los servicios de gestión de nivel.


El procesador DM6437 se comunica con los periféricos a través de las interfaces de dispositivos y un bus EMIF con un ancho de 8 bits. La memoria DDR2 está conectada a un bus dedicado con un ancho de 32 bits. El Bus EMIF es seleccionable por medio de un jumper para ser conectado a la memora FLASH, SRAM, NAND o a otras tarjetas de expansión.

El procesador DM6437 utiliza el decodificador TVP5146M2 para realizar la codificación y decodificación de video.

El Códec AIC33 le permite al DSP transmitir y recibir señales analógicas de audio. El Bus I2C se utiliza para administrar la interfaz de control del Códec, mientras que el McBSP controla el flujo de audio. La conexión de audio se realiza por medio de las tomas de audio de 3.5mm que corresponden a la entrada de micrófono, entrada de línea, salida de línea y audífonos, en este proyecto de tesis solo nos enfocaremos a la parte del procesamiento de imágenes y video.

En la Figura 2.1 se muestra el diagrama a bloques de la tarjeta TMS320DM6437.

Figura 2.1. Diagrama de bloques de funcionalidad del procesador DM6437 [28] pág. 12.

10 CAN (Controller Area Network) es un protocolo de comunicaciones desarrollado por la firma alemana Robert Bosh GmbH, basado en una topología bus para la transmisión de mensajes en ambientes distribuidos, además ofrece una solución a la gestión de la comunicación entre múltiples CPUs (unidades centrales de proceso).


17

2.1 Características del dispositivo TMS320DM6437 En la Tabla 1 podemos ver las características generales del DSP TMS320DM6437 que utilizaremos en la implementación de la RF5, para referencias más detalladas consultar el manual TMS320C64x/C64x+ DSP [19].

Tabla 1. Características del procesador DM6437. [19]

Características de Hardware TMS320DM6437

Periféricos

Controlador de memoria DDR2

Ancho de bus 16/32 bits [1.8 V Entrada/Salida]

EMIF Asíncrono (EMIFA) Asíncrono (ancho de bus 8 bits), RAM, Flash, (NOR o NAND de 8 bits)

EDMA3 1 (64 canales independientes, 8 canales QDMA)

Temporizadores

2 de propósito general de 64 bits (configurables como 2 de 64 bits o 4 de 32 bits) y 1 WatchDog de 64 bits.

UARTs 2 (1 con RTS y otro para el control de lujo CTS)

I2C 1 (Maestro/Esclavo) McBSPs 2 McASP 1 (4 serializadores) Puertos de Video Configurables

1 Entrada (VPFE) 1 Salida (VPBE)

Circuito de memoria

Tamaño (Bytes) RAM de 240 KB, ROM de 64 KB

Organización

32 KB en L1P (Puede almacenar RAM/Caché hasta 32 KB), 80 KB en L1D (Puede almacenar RAM/Caché hasta 80 KB), 128 KB para RAM/Caché (L2). 64KB ROM de arranque.

MegaModule Rev ID Dirección de localización: 0x01812000 Ver las características del

TMS320DM6437 Digital Media Processor (DMP) [29] CPU ID + CPU Rev

ID Control de Registros de Estado

JTAG BSDL_ID Registro JTAGID (Dirección de localización: 0x01C40028) Ver tablas de conexión [22]


2.2 CPU (Núcleo del DSP) Conocer las características del núcleo C64x+ es muy importante para poder implementar una estructura de trabajo como la RF5 de TI, que ya se encuentra implementada en el DSP DM642, ya que del desempeño del núcleo dependerá el funcionamiento de la RF5.

El C64x+ es la Unidad Central de Procesamiento (CPU) y está compuesta de ocho unidades funcionales, 2 archivos de registro y 2 rutas de datos como se muestra en la Figura 2.2. Los 2 registros son de Propósito General (A y B), contienen 32 registros de 32-bits para un total de 64 registros. Los registros de propósito general pueden ser utilizados para datos o para punteros de dirección. Los tipos de datos soportados son: paquetes de datos de 8-bits, paquetes de datos de 16-bits, paquetes de datos de 32-bits, datos de 40 bits y datos de 64 bits. Los valores mayores a 32 bits, como los valores de 40 bits o 64 bits de longitud, se almacenan en registros pares, con los 32 bits menos significativos (LSBs) de datos colocados en algún registro y los restantes 8 o 32 bits más significativos (MSBs) en el registro superior siguiente (que siempre es un número impar del registro).

Las 8 unidades funcionales (.M1, .L1, .D1, .S1, .M2, .L2, .D2, y .S2) son cada una capaz de ejecutar una instrucción en un ciclo de reloj [28].

La unidad funcional .M se encarga de realizar todas las operaciones relacionadas con multiplicaciones. Las unidades .S y .L se encargan de ejecutar un conjunto general de aritmética, lógica, y funciones secundarias. La función de la unidad .D es cargar los datos de memoria a los archivos de registro y almacenar los resultados de los archivos de registro en la memoria.

2.3 Mapa de Memoria El dispositivo tienes varios chips de memoria asociados al procesador. El mapa de memoria cuyo espacio de configuración es de la dirección 0x0180 0000 a 0x0FFF FFFF, es utilizado para simplificar el desarrollo de software y mantiene una coherencia entre los recursos del dispositivo a través de los buses maestros. El mapa de memoria puede ser consultado en el manual de referencia de la memoria interna [30] .

La herramienta de programación utilizada es el Code Composer StudioTM Integrated Development Environment (IDE).

• Code Composer StudioTM Integrated Development Environment (IDE): incluye herramientas C/C++/Ensamblador y un depurador adicional a las herramientas de desarrollo.


19

Figura 2.2. Ruta de datos en el procesador TMS320C64x+ (Núcleo del DSP) [19].


2.4 Consideraciones del Reloj El dispositivo TMS320DM6437 así como sus periféricos son controlados por los controladores (PLLC1 y PLLC2) y el Controlador de Poder y Suspensión (PSC). Además el sistema modular VPSS_CLKCTL que configura los registros de la fuente de reloj para el subsistema de procesamiento de video (VPS).

Después de haber reiniciado el dispositivo, el usuario es el responsable de la programación de los controladores de PLL (PLLC1 y PLLC2) y el Controlador PSC para que el dispositivo trabaje a la frecuencia de reloj deseada así como el estado del reloj periférico deseado (clock gating or not11).

Para el ahorro de energía, los periféricos del DM6437 hacen uso del “clock gating or not” [31].

El DM6437 se encuentra predeterminado en el modo PLL bypass12, para poder utilizarlo en la frecuencia deseada es necesario programar el PLLC1 y PLLC2 [28].

El procesador DM6437 soporta la opción de fastboot, cuando se reinicia la salida del dispositivo el código interno encargado de iniciar los programas del PLLC1 en modo PLL con un multiplicador y un divisor PLL específico para agilizar el arranque del dispositivo. La opción de fastboot es un beneficio para un inicio más rápido, pero el multiplicador y el divisor PLL seleccionado pueden no ser de la frecuencia necesaria para la aplicación en tiempo de ejecución, es por esto que queda como responsabilidad del usuario volver a configurar el PLLC1 después del fastboot para llevar el dispositivo a la frecuencia de reloj requerida [32].

El reloj y el estado de reinicio para cada módulo del TMS320DM6437 están controlados por el PSC [28].

2.5 Secuencia de arranque del TMS320DM6437 La secuencia de arranque es un proceso que se carga de la memoria del DM6437 en la sección de datos y de programa, por lo que algunos registros internos están definidos con valores predeterminados. La secuencia de arranque inicia de forma automática después de cada reinicio del DM6437. Existen diferentes métodos para poder inicializar la memoria y los registros, cada uno de estos métodos es conocido como modo de arranque. El modo de arranque se puede realizar por medio de la ROM interna, EMIFA o por los gestores de

11 El método encargado de la conmutación entre componentes innecesarios se llama clock gating, que implica apagar la señal de reloj de los componentes innecesarios, y esto se realiza desactivando dichos componentes. 12 En el modo PLL bypass, el on-chip PLL y el PLL clock son omitidos y el dispositivo funciona a la misma velocidad que la frecuencia de reloj de entrada.


21

arranque secundarios como la memoria externa. Algunas configuraciones de dispositivos son determinadas al restaurar el dispositivo.

2.5.1 Modos de arranque El modo de arranque del DM6437 está determinado por los dispositivos de arranque y los pines de configuración. Los modos de arranque están agrupados en tres categorías: modo Non Fastboot, modo Fixed-Multiplier Fastboot y modo User-Select Multiplier Fastboot.

• Modo Non-Fastboot (FASTBOOT=0): El DM6437 opera en modo PLL bypass predeterminado durante el arranque.

• Modo Fixed-Multiplier Fastboot (FASTBOOT=1, AEM[2:0]=001b): La velocidad de arranque está determinada dependiendo de la configuración de los multiplicadores PLL.

• Modo User-Select Multiplier Fastboot (FASTBOOT=1, AEM[2:0]=000b,011b,100b,101b): El código del bootloader acelera el arranque del DM6437. El multiplicador PLL es seleccionado por el usuario a través del pin PLLMS[2:0].

2.6 Interconexión interna del Sistema La Figura 2.3 muestra el diagrama a bloques de la interconexión del sistema. La siguiente lista es la ayuda para la interpretación del diagrama:

• La dirección de las flechas indican un Bus Maestro o Esclavo. • Las flechas se originan en el Bus Maestro y terminan en el Bus esclavo. • La dirección de las flechas no indican la dirección del flujo de datos. El flujo de

datos es normalmente bidireccional para cada uno de los caminos del Bus. • El patrón de la línea de cada flecha nos indica la frecuencia de reloj a la que opera,

por ejemplo a la frecuencia de reloj DSP/3, DSP/6 o MXI/CLKIN. • Un periférico puede tener varias instancias como se muestra en la Figura 2.3, por lo

tanto: El Periférico/Módulo tiene un Puerto(s) Maestro para la transferencia de datos, así como un Puerto(s) Esclavo para el acceso a registros, acceso a datos y/o acceso a memoria. Un ejemplo de estos periféricos son en Megamódulo C64x+ [21], EDMA3 [33], VPSS, VLYNQ, HPI, EMAC, y el PCI.

2.7 Subsistema de Procesamiento de Video (VPSS) El subsistema de procesamiento de video en el DM6437 (VPSS) proporciona un procesamiento de video de una Interfaz de Entrada Externa para Periféricos de Imágenes


llamada “Front End” (VPFE) por ejemplo sensores de imágenes CCD, decodificadores de video, etc., y una Interfaz de procesamiento de video de Salida llamada “Back End” para la visualización en dispositivos como pantallas analógicas, codificadores de video, etc.

En la Tabla 2 se muestra el mapa de asignación de memoria VPSS.

Tabla 2 Descripción de Registros VPSS. [22]

Intervalo de Dirección HEX

Acrónimo Descripción

0x01C7 3400 PID Revisión periférica e información de clase. 0x01C7 3404 PCR Control de Registros SCPV. 0x01C7 3408 -- Reservado. 0x01C7 3508 SDR_REG_EXP SDRAM solicitud de lectura no se ejecuta en

tiempo real. 0x01C7 350C - 0x01C7 3FFF

-- Reservado.

2.7.1 Procesamiento de Video Front‐End (VPFE) El Procesamiento de Video Front-End (VPFE) está compuesto por un Controlador CCD (CCDC), un Motor de Vista Previa, Redimensionador, Hardware Generador de Estadísticas 3A (H3A), y un bloque de Histograma. Todos estos módulos son ofrecidos por el DM6437.

• El CCDC proporciona la interfaz con los sensores de imagen y fuentes de video digital.

• El Motor de Vista Previa es un bloque de procesamiento de imágenes encargado de convertir el formato de Color RAW Bayer en un patrón YUV 4:2:2.

• El módulo Redimensionador se encarga de modificar la resolución de la imagen de entrada a la resolución requerida de video.

• El módulo H3A se encarga del control de Auto Enfoque (AF), Balance de Blanco Automático (AWB), y la Exposición Automática (AE).

• El módulo de Histograma contiene bins13 para el conteo de pixeles de color, que nos proporcionará las estadísticas necesarias para implementar diversos algoritmos 3A (AE/AF/AWB) y ajustar la imagen/video a la salida de video.

El mapa de memoria del Registro VPFE se puede consultar en el documento TMS320DM6437 Digital Media Processor [22].

13 Un bin es una subdivisión en la escala de intensidad de una imagen, por lo general se utilizan 256, si por ejemplo, se utilizan dos bins, existirán dos regiones (una de 0 a 127 y otra de 128 a 255) [38].


23

Figura 2.3. Diagrama de bloques de la interconexión del sistema.


2.7.2 Controlador de CCD (CCDC) El CCDC recibe el video/imagen (datos procedentes del sensor CMOS o CCD) o datos YUV de video. Las siguientes funciones son soportadas por el módulo CCDC.

• Formato convencional Bayer. • Interfaz con sensores progresivos y entrelazados. • REC656/CCIR-656 estándar (Formato YCbCr 4:2:2 ya sea de 8 ó 16 bits). • Formato YCbCr 4:2:2, ya sea de 8 o 16 bits con señales VSYNC. • Control de disparo de señal. • Compensación de niveles de negro. • Compresión de 10 bits a 8 bits. • Filtro pasa bajos antes de escribir en SDRAM. Si este filtro está habilitado, 2

pixeles en cada borde (izquierdo y derecho) se recortan a la salida. • Intervalo de salida de 16 bits a 8 bits (permite un ahorro del 50% de

almacenamiento). • Disminución de resolución a través de los patrones de eliminación selectiva

programable. • Salida de control a la DDR2 a través de una señal externa con un permiso de

escritura. • Hasta 16K pixeles (resolución de la imagen) tanto en la dirección horizontal y

vertical.

2.7.3 Motor de Vista Previa El motor de vista previa se encarga de procesar la información de imagen/video sin procesar directamente del sensor (CMOS o CCD) en datos YCbCr 4:2:2. La salida de la vista previa es utilizada para realizar compresiones de video y para ser utilizada por pantallas con codificadores analógicos NTSC/PAL. Las siguientes características son soportadas por el motor de vista previa:

• Acepta formatos convencionales del Patrón de Bayer14 [34]. • Entrada de datos Imagen/Video, ya sea del Controlador CCD/CMOS o la memoria

DDR2. • Una salida hasta con un ancho de 1280 pixeles. • Recorte automático/definido de pixeles/líneas de borde cuando se está procesando la

imagen/video. • Captura de cuadro oscuro a DDR2.

14El patrón de Bayer es un arreglo en donde los sensores tiene el acomodo rojo-verde-rojo… en una fila, y verde-azul-verde en la siguiente fila, por lo tanto el arreglo final queda con un 50% de filtros verdes, un 25 % de rojos y un 25% de azules, interpolando dos muestras verdes, una roja y una azul se obtiene un pixel de color.


25

• Sustracción de cuadros oscuros para la entrada de datos sin procesar. • Compensación de sombreado. Cada pixel de entrada se multiplica por un valor de

ganancia de 8 bits y el resultado es desplazado a la derecha por un parámetro programable (0-7 bits).

• Descompresión de datos lineales de 10 bits para transformarlos a datos no lineales de 8 bits, lo que permite un ahorro del 50% sobre la memoria DDR2.

• Filtro de Mediana Horizontal para reducir el nivel de ruido inducido en los pixeles. • Filtro de supresión ruido programable que opera en una vecindad de 3x3. • Ganancia digital y balance de blancos. • Interpolación programable CFA que opera en vecindades de 5x5. • Patrón de Bayer RGB y sensor de colores complementarios. • Corrección gamma programable. • Conversión de color programable (RGB a YUV). • Mejora de luminancia y supresión de crominancia.

2.7.4 Redimensionador El módulo Redimensionador puede aceptar datos de Imagen/Video, ya sea del motor de vista previa o de la DDR2. Las siguientes funciones son compatibles con el módulo Redimensionador:

• Una salida con hasta 1280 pixeles horizontales. • Entrada de datos de la DDR2 externa. • Ampliación hasta 4x (zoom digital). • Interpolación bicúbica. • Interpolación bilineal opcional para los componentes de crominancia. • Reducción hasta por ¼ x. • Factor de Redimensionamiento de las direcciones horizontal y vertical. • Los índices disponibles para la Ampliación y Reducción son: 256/N, donde N toma

valores desde 64 a 1024.

2.7.5 Hardware 3A (H3A) El módulo de Hardware 3A (H3A) proporciona los bucles15 de control para el auto enfoque, auto balance de blancos y la auto exposición. Existen dos componentes principales para el módulo H3A:

• Motor de Auto Enfoque (AF).

15 Un bucle o ciclo, es una sentencia que se realiza repetidas veces en un código determinado, hasta que se cumpla una condición o hasta que dicho bucle deje de cumplirse.


• Motor de Auto Exposición (AE) y Auto balance de Blancos (AWB).

El motor de AF filtra los datos en rojo, verde, y azul de la entrada de datos de imagen/video y proporciona la acumulación o picos de datos de una región determinada. La región específica es un bloque de datos de dos dimensiones y se le conoce como un “paxel” para el caso de AF.

El motor de AE/AWB acumula los valores y los controles de los valores saturados en el muestreo secundario de los datos de video. En el caso de AE/AWB, el bloque de dos dimensiones de datos se conoce como “window”. El número, dimensiones, y posición inicial de los AF paxels y los AE/AWB window son programados por separado.

2.7.6 Histograma El módulo histograma acepta datos de imagen/video sin procesamiento y bins de pixeles. El valor de los pixeles en si no es almacenado, sino que cada bin contiene el número de pixeles que se encuentra en un intervalo de configuración predeterminado. La fuente de datos sin procesamiento para el histograma es tomada del sensor CCD/CMOS (a través del módulo CCDC) o de la DDR2. Las siguientes funciones son soportadas por el modulo Histograma:

• Hasta cuatro regiones/áreas. • Posición inicial y final para cada región horizontal/vertical por separado. • Los pixeles que se solapan en alguna región se acumulan en la región de más alta

prioridad. La prioridad es: region0 > region1 > region2 > region3. • Interfaz compatible con el patrón de Bayer. Cada región puede acumular 3 o 4

colores. • 32, 64, 128, o 256 bins por color para cada región. • 32, 64, o 128 bins por color para 2 regiones. • 32 o 64 bins por color par 3 o 4 regiones. • Limpieza automática del histograma en RAM después de leer el ARM. • Saturación del conteo de pixeles si el conteo excede el valor máximo (cada posición

en memoria tiene un ancho de 20 bits). • Cambio descendente que va de 0 a 7 bits (Intervalo máximo de bin 128). • En el último bin (intervalo más alto de los valores) se acumulará cualquier valor que

sea más alto que el límite inferior.


27

2.7.7 Codificador de video (VENC) La Interfaz Analógica/DACs del Codificador de Video (VENC) soporta las siguientes características [35]:

• Entrada de Reloj Maestro – 27MHz. • Soporte SDTV

‐ Compuesto NTSC-M, PAL-B/D/G/H/I ‐ S-Video (Y/C) ‐ Componentes YPbPr (SMPTE/EBU N10, Betacam, MII) ‐ RGB ‐ CGMS/WSS ‐ Fase SC-H programable

• Soporte HDTV ‐ Salida Progresiva (525p/625p) ‐ Componente YPbPr ‐ RGB ‐ CGMS/WSS

• Convertidores D/A de 10 bits • Operación Maestro/Esclavo • DCLK programable • Varios formatos de salida

‐ YCbCr 16 bit ‐ YCbCr 8 bit ‐ ITU+R BT.656 ‐ RGB 24 bits paralelo

• Filtro Pasa Bajos para salida digital RGB

2.8 Receptor/Transmisor Universal Asíncrono (UART) El procesador DM6437 contiene 2 periféricos UART. Cada UART tiene las siguientes características:

• Espacio de almacenamiento de 16 bits para cada transmisor y receptor FIFO. • Receptor seleccionable FIFO 1, 4, 8, o 16 bytes para el ajuste automático de control

y DMA. • Auto-RTS programable y CTS automático para el ajuste automático de control. • Frecuencia para pre-escalar valores de 1 a 65,535 para generar velocidades

adecuadas de transmisión. • Interrupciones priorizadas. • Formato de datos serie programable.


‐ Caracteres 5, 6, 7, u 8 bits. ‐ Par, Impar, o sin paridad y detección. ‐ Generación de bit de alto 1, 1.5, o 2.

• Bit de falso comienzo de detección. • Generación de línea de ruptura y detección. • Capacidad de diagnóstico interno.

‐ Control de bucle interno para el aislamiento de fallas de enlace en las comunicaciones.

‐ Simulación de errores Break, Parity , Overrun y Framing [36]. • Funciones de control de modem (CTS, RTS) solamente sobre el UART0.

2.9 Comunicaciones entre circuitos (I2C) El módulo de comunicaciones entre circuitos (I2C) proporciona una interfaz entre el DM6437 y otros dispositivos compatibles con Philips Semiconductors Inter-IC (bus I2C) versión 2.1. Los componentes externos conectados a este bus serie de 2 hilos pueden transmitir/recibir datos de hasta 8 bits desde el DSP a través del módulo I2C. El puerto I2C no es compatible con dispositivos CBUS [31].

El puerto I2C soporta:

• Compatibilidad con la Revisión Philips I2C versión 2.1. • Modo rápido hasta 400 Kbps. • Filtro de ruido con una velocidad de 50ns o menos. • Dispositivo de direccionamiento con 7 y 10 bits. • Funcionalidad Master (transmisión/recepción) y Esclavo (transmisión/recepción).

En la Figura 2.4 se muestra el diagrama de bloques del módulo I2C.

Con esta descripción de dispositivos del DSP TMS320DM6437 podemos observar que existe una similitud con el núcleo C64x, la capacidad de procesamiento Front-End y Back-End, la característica de periféricos útiles para el entorno de la estructura de trabajo RF5 que se describirá en el siguiente capítulo.


29

Figura 2.4. Diagrama de bloques del módulo I2C.

2.10 Conclusión La arquitectura del procesador DM6437 dispone de diversas unidades funcionales que administran la información almacenada en los registros internos. Contiene varios niveles de memoria caché interna en los que existen diferencia entre los empleados para almacenar datos y programas en el primer nivel (L1), una característica muy especial es una de las mejoras de su antecesor (C64x) de este procesador, es la integración de un EDMA, y además contar con una arquitectura VLIW, que contiene muchas unidades funcionales que operan en paralelo, permitiendo ejecutar varias instrucciones en el mismo ciclo de reloj. La arquitectura de este procesador se adapta muy bien a tareas concretas dando solución a diferentes problemas que pueden abarcar desde el campo medico hasta el militar. Se aprovechará su característica de poder realizar múltiples accesos a memoria en un solo ciclo para la implementación de aplicaciones en tiempo real.

Todas estas características se necesitan administrar para poder implementar la estructura de trabajo RF5 como la ya utilizada en el núcleo C64x, que nos permitirá reducir el tiempo de implementación de diferentes proyectos.


Capítulo 3. Estructuras de trabajo (RFs) Cuando se desarrollan aplicaciones, reutilizar el código fuente es un gran problema, debido a que el código generado se vuelve exclusivo y difícilmente se puede utilizar para iniciar un nuevo proyecto de diferentes características. Las estructuras de trabajo están diseñadas para agilizar el tiempo requerido de implementación para las primeras etapas de desarrollo de un prototipo, como puede verse en la parte sombreada de la Figura 3.1, que representa la línea de tiempo para el desarrollo de un proyecto [37].

Figura 3.1. Etapas de desarrollo de un proyecto.

Los fabricantes de equipo original (OEM) son los principales usuarios de este tipo de aplicaciones para el uso de plataformas DSP, todos ellos necesitan un inicio rápido para la construcción de prototipos, ya que de esto depende su éxito o fracaso de la realización de un proyecto. Texas Instruments (TI) se ha caracterizado por su desarrollo de DSP´s y ha utilizado las buenas prácticas16 para dar a conocer cómo aprovechar los DSP´s de la serie TMS320.

Entre las características más importantes de las RFs son que:

• Están diseñadas para que el código fuente principal, no sufra modificaciones, realizando solo los cambios en los archivos de soporte (process, control, y cells).

• Las RFs son la herramienta que nos ayuda en la parte inicial de un proyecto y está diseñada para poderse utilizar con una gran cantidad de aplicaciones finales (detección de objetos en movimiento, reconocimiento de patrones, conteo de objetos, etc.).

• El código fuente de las RFs se encuentra escrito en lenguaje C. Esto permite su portabilidad a través de los proyectos, su modularidad permite copiar y pegar líneas de instrucciones y finalmente una gran adaptabilidad para un amplio espectro de aplicaciones.

• Las RFs están diseñadas específicamente para eliminar gran parte de la experimentación e hipótesis requeridas (La recopilación de la arquitectura necesaria en una aplicación, como revisar la administración de los tipos de acceso entre

16 Texas Instruments desde el lanzamiento de su primer procesador digital de señales (TMS320010) en 1983 a adquirido la experiencia en la programación de los mismos, y esa experiencia les ha servido para realizar la implementación de las estructuras de trabajo (RF1, RF3 y RF5)


31

periféricos y el núcleo, creación de buffers, configuración de Timers, etc.) en la arquitectura de la plataforma del DSP.

Las RFs son una extensión del software eXpressDSP17 de TI, y en la actualidad existen tres niveles, para una descripción breve podemos hacer una analogía con la construcción de viviendas. Por sentido común no se construye una mansión cuando el usuario necesita un condominio o cuando es necesario un castillo. Es evidente que se utilizara el diseño técnico en función del producto final y el presupuesto disponible. En base a esta analogía, lo que nos proporcionan las RFs son escalabilidad para adaptar nuevos recursos y ajustarse a necesidades de aplicación.

Una descripción de las RFs existentes es la siguiente:

• La RF1 (Compacta), está diseñada para tener un Footprint18 mínimo y conserva todos los elementos eXpressDSP. Se utiliza para la configuración de objetos estáticos sin considerar el tiempo de ejecución y la creación de objetos dinámicos. La administración de memoria es completamente estática y no es compatible con la administración de memoria dinámica. El número de canales y algoritmos soportados es como máximo tres y no existe preferencia o bloqueo de tareas19.

• Con la RF3 (Flexible) cambia el Footprint mínimo especificado en la RF1 para una mayor flexibilidad, solo se pueden crear objetos estáticos, pero ahora existen buffers20 para la administración de la memoria dinámica, la flexibilidad consiste en el uso de más canales y algoritmos, es compatible con operaciones multi-tarea. Este nivel nos proporciona una tarea adicional para permitir el control del DSP por una unidad externa, por ejemplo un host.

• Cuando necesitamos de una amplia flexibilidad y el Footprint no es importante, podemos utilizar la RF5 (Extensiva), donde el número de canales y algoritmos pueden ser de 100+, trabaja con un solo rango o multi-rango21, existe prioridad, bloqueo, y control dedicado de tareas.

En la Figura 3.2 se muestra como la complejidad de la programación aumenta dependiendo de la aplicación y su rendimiento, en donde a la izquierda se muestra un sistema pequeño y 17 eXpressDSP es un paquete de software producido por TI, este paquete de software es un conjunto de herramientas utilizado para el desarrollo de aplicaciones sobre DSPs (Procesador Digital de Señales) y consiste de:

• Un entorno de desarrollo integrado llamado Code Composer Studio (CCS). • Un Sistema Operativo en Tiempo Real DSP/BIOS. • Normas de interoperabilidad para poder ser utilizado con otros algoritmos, utilizando los recursos críticos del

sistema, como la memoria y el DMA [24]. 18 Espacio de memoria utilizado para la aplicación. 19 Las tareas contienen los archivos de hardware de forma independiente para su ejecución. 20 Un buffer de datos es una ubicación en memoria que se encarga de almacenar información digital de manera temporal, que espera ser procesada. 21 La RF5 permite trabajar a diferentes velocidades de procesamiento, ajustándose a las diferentes velocidades de los elementos de la aplicación, y también trabaja en un solo rango, en donde la RF5 toma la velocidad del elemento más lento.


va aumentando la complejidad. También observamos que los sistemas se dividen en dos partes fundamentales; en la parte inferior se encuentra todo el código de bajo nivel (por su eficiencia y comunicación directa con el procesador, también es posible escribirlo en lenguaje C) y en la parte superior encontramos código en lenguaje C que sirve para darle las características específicas a la aplicación.

En la Figura 3.3 podemos ver el aprovechamiento del núcleo DSP/BIOS y el aprovechamiento de algún algoritmo realizado por terceros, que es compatible con eXpressDSP y de esta manera una gran parte del complicado código de bajo nivel se encontrará funcionando casi inmediatamente, dejando solamente la parte de moldeado del sistema, a esto es a lo que llamamos Estructura de trabajo y se puede observar como representa un gran impulso para iniciar un proyecto en un tiempo menor.

Figura 3.2. Creación de un pequeño sistema a un sistema complejo.

Uno de los objetivos de saber que RF utilizar, depende de los recursos disponibles para una solución más eficiente. En los siguientes temas veremos las características más importantes de las RFs.


33

Figura 3.3. Creación de un sistema utilizando las estructuras de trabajo.

3.1 Estructura de trabajo nivel uno (RF1) La RF1 está relacionada principalmente con el bajo costo de los DSPs, donde la creación de aplicaciones completas cabe en un espacio de memoria menor a 8KW22, este tamaño permite utilizar DSPs muy económicos como el TMS320VC5401 de TI.

Por lo general las aplicaciones para la RF1 se encuentran en la memoria interna, es decir, no existe la memoria externa. Una aplicación mínima incluye un DSP/BIOS, librería de soporte de chip (CSL), XDAIS, así como de su Framework.

Como referencia de las características que posee la RF1 consulte la tabla que se encuentra en el documento spra791d.pdf, pp10 [37].

Existe un tamaño mínimo para el uso de memoria. La RF1 utiliza una serie de técnicas especiales para reducir al mínimo el consumo de memoria para la aplicación. El objetivo es utilizar un DSP de bajo costo con capacidad de memoria mínima.

Permite el uso de algoritmos XDAIS23. Aunque la RF1 minimiza el uso de memoria, permite el uso de un número limitado de algoritmos XDAIS.

22 KW (KiloWords): Kilopalabras (1 K palabra = 210 palabras = 1024 palabras). La palabra de un elemento de almacenamiento puede constar de varias unidades conocidas como bits. 23 XDAIS (eXpressDSP Algorithm Interoperability Standard), en un estándar para el desarrollo de algoritmos de TI, para la familia de DSP’s TMS320. La norma fue introducida por primera vez en 1999 y fue creada para facilitar la integración


Entradas/Salidas basadas en PIP24. El módulo PIP es muy sencillo comparado con el módulo SIO25 utilizado por la RF5, además tiene la ventaja de reducir la sobrecarga de datos.

Gracias a su estructura bien definida permite una fácil localización de sus elementos y por lo tanto una fácil depuración. Además, posee un módulo UTL26 que permite cambios rápidamente [38].

Se pueden reemplazar fácilmente los controladores de E/S. El modelo IOM27 permite alternar los mini-controladores al adaptador PIP28 (PIO) utilizado en la RF1.

La arquitectura de la estructura de trabajo nivel uno, nos permite crear sistemas compactos y estáticos. Lo más importante para poder adaptar la RF1 a una aplicación, es elegir los servicios adecuados (que la aplicación no exceda tres canales, tres algoritmos, tomar en cuenta que la aplicación funcionará en un solo intervalo de operación y que no se exceda el Footprint mínimo de 3.5 KW). En la Figura 3.4 se muestran los servicios utilizados por la RF1 [37]. La RF1 es utilizada para aplicaciones como cámaras ethernet, escáneres digitales, sistemas de cobro en teléfonos públicos, etc.

Figura 3.4. Topología de los módulos de la RF1.

de algoritmos en los sistemas DSP sin un costo por la re-ingeniería. Cuando un algoritmo pasa las pruebas de cumplimiento de normas XDAIS se le otorga un “XDAIS support” [51]. 24 PIP (PIPE): Es un administrador basado en la sincronización de bloques de E/S. La RF1 configura 2 objetos PIP (pipRX y pipTX). 25 Streaming de E/S (SIO) en el DSP/BIOS proporciona un mecanismo independiente de E/S para el uso de las tareas con el DSP/BIOS. 26 En las RF el módulo UTL es llamado en la appMain.c. estos módulos son macros en donde su código puede ser ampliado para el código que realiza la función de depuración. 27 IOM (input/output mini-driver), es la interfaz entre las tareas y el hardware. 28 PIP: Administrador del Buffer Pipi, es un administrador de bloques de E/S sincronizada. La RF1 configura dos objetos PIP estáticos (pipRx y pipTX)


35

3.2 Estructura de trabajo nivel tres (RF3) La estructura de trabajo nivel tres (RF3) tiene la característica de permitir diseños compactos con varios algoritmos y canales. Es muy útil cuando el espacio utilizado en memoria nos representa un costo pero con cierta flexibilidad (número de algoritmos y canales).

Una de las características más importantes a tomar en cuenta para el diseño con la RF3, es que no existe la creación de objetos dinámicos o tareas de control. Como consecuencia la RF3 no está destinada para el uso de aplicaciones que tienen complejas interdependencias entre tareas lo que no la hace adecuada para realizar tareas en el área de procesamiento de imágenes y video.

Las aplicaciones que normalmente utilizan la RF3, son las que solo necesitan una cantidad de memoria relativamente pequeña, pero que necesitan un poco más de flexibilidad para agregar más algoritmos en el futuro (característica no proporcionada por la RF1).

• Existe el compromiso entre el desempeño general y su flexibilidad. Proporciona una menor sobrecarga de memoria que la RF5, al mismo tiempo que proporciona mayor flexibilidad que la RF1.

• La RF3 está diseñada para maximizar su facilidad de uso y minimiza su complejidad. La complejidad de minimizar el Footprint de memoria de la RF1 no existe, ni la gran cantidad de módulos utilizados por la RF5 que soporta una gran cantidad de algoritmos y canales.

• La estructura bien definida de la RF3 permite una depuración muy rápida y muy utilizada para proyectos como verificadores de huella digital, teléfonos multicanales, cámaras fotográficas/video digitales.

La RF3 incluye el software DSP/BIOS, la librería de soporte de chip (CSL) y XDAIS. En la Figura 3.5 se muestran las características de la RF3 con más detalles. Cuando la aplicación no coincide con las características adecuadas para la RF3, no será posible adecuar la aplicación como por ejemplo en el caso de que la aplicación necesite más de diez algoritmos y su Footprint sobrepase los 11KW [39].


Figura 3.5 Topología de los módulos de la RF3.

Como podemos ver, en las estructuras de trabajo anteriores, éstas son útiles para DSPs con poca capacidad de memoria y pocos recursos (como ejemplo para el procesador TMS320VC5402 [40]). Para poder aprovechar todas las capacidades del procesador TMS320DM6437 (como lo son su Acceso Directo a Memoria versión tres (EDMA3) y su versión mejorada del núcleo con instrucciones de palabras muy largas (VLIW) y sus dos niveles de memoria interna L1 y L2) y no limitar el número de algoritmos para el procesamiento, análisis, y aplicación de imágenes y video, necesitamos utilizar la RF5.

3.3 Estructura de trabajo nivel cinco (RF5) La RF5 está diseñada para el uso de aplicaciones que requieran de varios canales y algoritmos (100+), el tamaño de la memoria (25 KW) utilizado no tiene un límite de capacidad como en las anteriores RFs.

Al utilizar la RF5 se evitará concentrarse en el software base de la aplicación29 y el diseñador se concentrará exclusivamente en la aplicación específica, la RF5 la podemos definir como: un starterware30 para DSP que utiliza un código fuente DSP/BIOS y algoritmos estándar para la serie DSP TMS320 que los diseñadores pueden adaptar, moldear o rellenar con algoritmos compatibles31 para conseguir soluciones específicas.

29 El software base de la aplicación se refiere al lenguaje estructurado de programación mediante el cual el procesador ejecuta las diferentes tareas y este software esta compuesto por variables, identificadores, punteros, palabras reservadas y una sintaxis específica. 30 Starterware es un paquete de desarrollo que proporciona soporte para determinadas plataformas 31 Los algoritmos compatibles son todos los XDAIS de la serie C6000 además de poder adaptar algoritmos que no cumplen con la norma XDAIS bajando el rendimiento del tiempo de procesamiento.


37

De acuerdo con las características de los DSPs y las características de las estructuras de trabajo mencionadas, en la Tabla 3 se muestran ejemplos de tarjetas DSP de TI que se pueden utilizar para cada RF y las RFs compatibles para cada una de ellas [41].

Tabla 3. Procesadores que pueden utilizar las estructuras de trabajo.

Tarjeta RF1 RF3 RF5 C5402 DSK C5416 DSK C5510 DSK C6x11 DSK C6416

3.3.1 Justificación de la migración y adaptación de la estructura de trabajo nivel cinco al procesador TMS320DM6437

En comparación con las otras estructuras de trabajo (RF1, RF3), en la RF5 las tareas no trabajan de forma serial, sino que se le puede dar prioridad a un proceso o bloquearlo, mediante los mensajes de control. Como resultado, la RF5 se puede utilizar para aplicaciones muy complejas en donde existe una fuerte interrelación entre las tareas, aun así es posible adaptar la RF1 y RF3 en el procesador TMS320DM6437, pero no es lo más adecuado ya que no se utilizarían todos los recursos de los que se dispone en este procesador, debido a esto, si se necesita implementar una RF1 o RF3 se recomienda buscar un procesador con menos recursos, esto implica también una solución más económica.

La RF5 utiliza el termino célula para describir un contenedor que realiza la solicitud de un algoritmo. Un canal de la RF5 puede contener varias células y por lo tanto múltiples algoritmos. La RF5 posee módulos que nos permiten crear aplicaciones y controlar las células y canales que son los encargados de procesar los algoritmos contenidos en las células en forma serial. También posee módulos adicionales de apoyo en la comunicación y sincronización (Administrador de algoritmos en serie, Módulo de comunicación sincronizada, Módulo de mini-controladores, DSP/BIOS, etc.).

La RF5 aprovecha el software base como lo es el DSP/BIOS, la librería de soporte del chip (CSL) y los algoritmos XDAIS32, también hace uso de otros módulos, como el módulo UTL que es el encargado de la depuración y el diagnóstico del sistema.

El estudio y la adaptación de la RF5 se enfocó en el desarrollo para aplicaciones de video e imágenes, para la implementación de los algoritmos diseñados en el laboratorio de señales y sistemas de la SEPI-ESIME Zacatenco utilizando el DSP de TI TMS320DM6437.

32 XDAIS (eXpressDSP Algorithm Interoperability Standard) es un estándar de algoritmos de TI para la familia de DSPs TMS320. Estos algoritmos fueron creados para facilitar la integración de los algoritmos en diferentes sistemas sin costos adicionales de reingeniería. Los algoritmos cumplen con normas de prueba que define TI.


3.3.2 Características principales de la RF5 Está provisto de un administrador de canales escalable, es decir, tiene la propiedad de incrementar su número de canales sin perder las propiedades de la RF y sin la necesidad de generar un código adicional. El administrador CHAN se encarga de realizar la aplicación escalable para grandes números de algoritmos XDAIS. Los algoritmos pueden trabajar de forma independiente de manera eficiente y pueden habilitarse a través de la interfaz ICELL.

Eficiencia en la comunicación entre tareas. Contiene un módulo de Comunicación Sincronizada (SCOM), encargado de copiar los datos que pasan entre las tareas.

Mecanismo de control. Es una tarea de control que puede estar leyendo los datos de otras tareas y modificar el curso de la aplicación enviando mensajes de control a otras tareas.

Fácil sustitución de los controladores de Entrada-Salida (E/S). El módulo IOM nos permite realizar cambios con los mini-controladores conectados al adaptador SIO (DIO).

Permite una fácil depuración. La estructura bien definida de la RF5 permite una rápida depuración.

Detalles completos de funcionalidad se describen en la referencia [38].

3.3.3 Arquitectura de la estructura de trabajo nivel cinco La estructura de trabajo utiliza diversos módulos (comunicación, procesamiento y administración, un módulo es una implementación de una interfaz en lenguaje C) como se muestra en la Figura 3.6.

Figura 3.6. Arquitectura de la estructura de trabajo nivel cinco. [41]


39

Hilos: En estos módulos se realiza todo el procesamiento de la aplicación y se compone de los módulos, tskRxSplit, tskProcess, tskTxJoin, y tskControl.

• tskRxSplit: Módulo encargado de dividir o multiplicar la señal en un número específico de señales necesarias en la aplicación.

• tskProcess: Este módulo es el más importante para la aplicación, ya que es el encargado de ejecutar los algoritmos. Este módulo se modifica de acuerdo a la aplicación (el código fuente de este módulo lo podemos encontrar en thrProcess.h y thrProcess.c).

• tskTxJoin: Es el módulo encargado de unir las señales resultantes del hilo tskProcess.

• tskControl: Es el encargado de que los hilos anteriores puedan enviar o recibir mensajes de control a través del mail box (tskControl).

El bloque framework está compuesto por los módulos necesarios para la ejecución de una aplicación.

• ICC: Es el mecanismo de comunicación intercelular para mover los datos de entrada y salida de la célula.

• Cell wrappers: Contiene el código para que pueda interpretarlo la interfaz de los algoritmos XDAIS.

• Algoritmos XDAIS: Es un estándar de desarrollo de algoritmos altamente depurados y que cumple con normas de interoperabilidad para la serie TMS320.

• ICELL: es la interfaz que permite encapsular los algoritmos XDAIS en las células. • CHAN: Administra la ejecución en serie de los algoritmos XDAIS contenidos en la

célula. • ALGRF: Encargado de utilizar el DSP/BIOS para la asignación de memoria

dinámica. • SSCR: Maneja la superposición de la memoria de datos solicitada por los

algoritmos XDAIS. • SCOM: Administra la comunicación síncrona que existe entre las tareas. • UTL: Encargado de la depuración y diagnóstico del sistema. • DIO: Interfaz entre el módulo mini-controladores y el DSP/BIOS. • IOM mini-controladores: Es la interfaz entre hilos y hardware.

DSP/BIOS es el sistema operativo en tiempo real que proporciona los servicios multitarea al DSP, el sistema es proporcionado por el fabricante y permanece intacto [41].

Hardware: Es la tarjeta para la cual está diseñada la estructura de trabajo, para nuestro caso incluimos nuestra tarjeta de desarrollo, la TMS320DM6437.


La información más detallada se encuentra en “Reference Frameworks for eXpressDSP Software: API Reference” [38].

3.3.4 Comunicación entre los diferentes módulos La comunicación entre controladores y tareas se realiza por medio de los objetos SIO de los cuales se hablará más adelante, la comunicación en lugar de utilizar variables globales para llamar a los elementos de procesamiento, introduce objetos estructurados para transmitir la información, la comunicación se mostrará en los siguientes temas.

3.3.4.1 Objetos SIO La comunicación entre controladores y tareas se realiza por medio de objetos SIO, como se muestra en la Figura 3.7.

La tarea se encarga de asignar los buffers para datos, cuando los buffers están vacíos se le asignan al controlador, una vez que el controlador ha llenado los buffers, estos son asignados a la tarea.

Figura 3.7. Comunicación entre una tarea y un controlador por medio de un objeto SIO. [41]

3.3.4.2 Estructura de intercambio de objetos entre tareas La tarea receptora se encarga de asignar un buffer en donde la otra tarea puede leer o escribir datos. El objetivo de manejar la comunicación síncrona es evitar el acceso simultáneo de las tareas, en este sentido el mensaje SCOM es el que describe el estado del buffer de la siguiente manera: la tarea contiene un mensaje y el mensaje SCOM le indica si


41

está en estado de lectura o escritura, en estado de escritura cuando el mensaje se termina de escribir, el buffer pasa al estado de lectura. Cada tarea tiene su propia cola de comunicación síncrona, la Figura 3.8 muestra gráficamente la comunicación utilizando mensajes SCOM.

Figura 3.8. Comunicación entre dos tareas utilizando mensajes SCOM. [41]

3.3.4.3 Comunicación a nivel celular La comunicación a nivel celular se realiza con la ayuda del objeto ICC [38]. El propósito del objeto ICC es describir el buffer desde donde la célula puede leer o escribir datos. Cada célula tiene una entrada y una lista de salida de objetos (apuntadores a los objetos ICC). Si la célula necesita escribir en el buffer, coloca los datos en su lista de salida de objetos ICC, si la célula necesita leer el buffer, toma los datos de la lista de objetos ICC de entrada, como se puede observar en la Figura 3.9.

Figura 3.9. Comunicación intercelular utilizando objetos ICC. [41]


3.4 Desarrollo de aplicaciones A continuación describiremos la arquitectura de la RF5 para el manejo de los controladores DSP/BIOS para el desarrollo de nuestras aplicaciones.

Para la creación de aplicaciones en tiempo real, el hardware siempre ha sido el encargado de portar los controladores para el manejo de periféricos y estos son dependientes del sistema operativo, esto ha sido una tarea difícil debido a las limitaciones de los sistemas DSP, como lo son su Footprint de memoria, tiempo de respuesta y administración de la energía. Este comportamiento del software del controlador del dispositivo lo podemos dividir en dos modelos “Controlador de clase” y “Mini- controladores”.

• Controlador de clase: El controlador de clase generalmente proporciona la serialización y la sincronización de tareas de entrada y salida, y se encarga de la administración de dispositivos. En los típicos sistemas de tiempo real, solo algunos controladores de clase son necesarios para representar los dispositivos utilizados para la aplicación, incluyendo los bloques de entrada/salida.

• Mini-controladores: El controlador de clase utiliza un dispositivo específico de mini-controlador para operar un dispositivo en particular a petición de una aplicación de software.

El diseñador de mini-controladores debe tener la habilidad de representar de forma eficaz un dispositivo en particular para un controlador de clase. Por ejemplo, en un dispositivo que se encarga del procesamiento de video, podrá necesitar de un buffer de memoria para cada trama que una aplicación necesita asignar con el fin de realizar una operación deseada de E/S de manera eficiente. Pero además, un controlador de clase de video puede necesitar representar las solicitudes de E/S como un conjunto de buffers de memoria divididas, como pueden ser el formato RGB o YUB, por lo que el nivel inferior del mini-controlador puede interactuar con el hardware de video.

Un modelo eficaz de controlador debe permitir que los servicios del controlador represente la manera más adecuada de las solicitudes de E/S a los mini-controladores en forma de paquetes para la solicitud de E/S.

La reutilización del controlador del dispositivo se puede mejorar a partir del controlador de clase/mini-controlador y después agregar todas las características de solicitudes del dispositivo de E/S al mini-controlador.

3.4.1 Arquitectura para el diseño de aplicaciones En la Figura 3.10 se muestra la relación entre las dos capas (Controlador de clase y mini-controlador) utilizadas para la descripción de controladores.


43

Como se observa en la Figura 3.10, la aplicación no interactúa directamente con los mini-controladores, pero si utiliza uno o más controladores clase como interfaz con el mini-controlador.

Figura 3.10. Componentes del controlador de un dispositivo. [41]

Cada controlador de clase presenta una API para el código de aplicación y se comunica con la interfaz IOM Mini-controlador. Un controlador de clase utiliza la API del DSP/BIOS para utilizar los servicios de sincronización, llama a la interfaz estándar del mini-controlador para acceder a los dispositivos periféricos del hardware.

El DSP/BIOS define los tres controladores clase como se muestra en la Figura 3.10 (PIP/PIO, SIO/DIO y GIO). En el caso de los controladores clase PIP/PIO y SIO/DIO, las APIs utilizadas por la aplicación existen en el DSP/BIOS y las funciones SIO. Para el caso del controlador clase GIO, la aplicación llama a estas nuevas APIs, con la interfaz directamente con el mini-controlador.

3.4.2 Modo de operación del canal Una vez que el canal fue creado, podemos realizar llamados al canal de dos maneras:

• mdSubmitChan: Envía una solicitud de E/S en forma de una IOM_Packet33. • mdControlChan: Realiza una llamada de control a un controlador específico.

33 Es una estructura creada por el driver clase y se utiliza para transmitir ordenes, buffers de datos, e información de estado entre el driver clase y el mini-driver.


Los canales en el mini-controlador no son necesarios para serializar el acceso a las llamadas múltiples (tareas múltiples). La serialización es la encargada de la aplicación. Esto simplifica el diseño del mini-controlador.

3.4.3 Solicitud de envíos de E/S Cuando un mini-controlador recibe un IOM_Packet por medio de una llamada mdSubmitChan, el mini-controlador puede tratar de completar la solicitud y si es necesario regresa inmediatamente al emisor.

3.4.4 Control de un dispositivo El mini-controlador mdControlChan implementa cualquier función de control que se desee diseñar para una aplicación. La aplicación puede llamar la función de control a través de llamadas al GIO_control, SIO_ctrl o al PIO_ctrl [42].

Cada mini-controlador viene con su documentación en donde se proporciona una lista de códigos de control, todo código de control que no es soportado por el mini-controlador nos regresa un código de error.

3.5 Controladores de Clase El DSP/BIOS permite dos modelos para la transferencia de datos. Uno de ellos es el modelo stream, que se realiza mediante el módulo SIO. Y el otro modelo es el pipe, que se realiza mediante el módulo PIP, en ambos modelos:

• Se requiere de un pipe o stream para la lectura o escritura de la tarea. • Se realiza la transferencia de buffers por pipe o stream por copia de punteros en

lugar de la copia de datos. • Están diseñados para manejar bloques de E/S.

En ambos modelos de transferencia de datos se pueden conectar a la interfaz IOM mini-controladores utilizando adaptadores para ser utilizados como parte de un controlador clase.

3.5.1 Adaptador SIO (DIO) El módulo streaming (transferencia de información de forma continua) de E/S (SIO) en el DSP/BIOS proporciona un mecanismo independiente de E/S para el uso de las tareas con el DSP/BIOS.


45

Para que SIO pueda proporcionar esta capacidad, SIO tiene su propio modelo de controlador de dispositivo, llamado DEV34 [43].

El adaptador SIO, que también es llamado DIO, está diseñado para integrarse fácilmente con los streams de los modelos IOM mini-controlador.

Figura 3.11. Transmisión de datos en una aplicación utilizando DIO. [41]

En la Figura 3.11 se observa el camino del streaming35 de datos en aplicaciones que utilizan DIO.

34 Este es un módulo del DSP/BIOS que se encarga de la administración de los dispositivos definidos por el usuario que se deben configurar para utilizar el módulo IOM mini-driver. Escribir un DEV es similar a escribir un IOM mini-driver para un pequeño conjunto de dispositivos específicos de funciones como puede ser, abrir, cerrar, y administrar la memoria. 35 Es el flujo continuo de datos de video que pasa a través de una dirección determinada.


3.5.2 Módulo PIP El módulo PIP36 (PIPE) DSP/BIOS proporciona un servicio PIPE para la administración de bloques de E/S. Cada objeto pipe37 mantiene un buffer dividido en tramas de longitud fija. El tamaño y el número de fotogramas para un PIP se establece en la herramienta de configuración del DSP/BIOS.

La pipe tiene dos extremos, un extremo se encarga de escribir las tramas de datos y el otro extremo encargado de leer las tramas de datos.

3.5.3 Controlador clase GIO El controlador de clase GIO fue implementado para minimizar el tamaño del código y de datos, ofreciendo también la funcionalidad para la sincronización de lectura/escritura de la API y extensiones. La GIO puede ser utilizada directamente por la interfaz de IOM mini-controladores.

3.6 Conclusiones La estructura de trabajo nivel cinco es una metodología para la construcción de varios sistemas (es el conjunto de elementos organizados e interrelacionados para lograr un objetivo, un sistema tiene como característica la recepción y salida de datos.), así como una herramienta reutilizable con soluciones bien definidas para las aplicaciones.

La estructura de trabajo nivel cinco es un punto de partida para aplicaciones más complejas, este trabajo de investigación y adaptación hacia la tarjeta DaVinci DM6437 se concentra en la correcta programación y aprovechamiento de los recursos que se tienen con la arquitectura de hardware, nos enfocamos en dejar la tarjeta programada en sus puertos de entrada y salida utilizando las potencialidades que nos ofrecen las herramientas de TI y dejar solo el trabajo al desarrollo de aplicaciones robustas de procesamiento, lo que nos permitirá concentrar los esfuerzos en el desarrollo de algoritmos de procesamiento de imágenes y video en lugar de enfocarnos en la programación de la tarjeta, así la migración de nuestro algoritmo de procesamiento de imágenes y video para la tarjeta será más simple de probar y validar.

36 Es un modulo del DSP/BIOS encargado de administrar objetos pipe I/O. 37 Los objetos pipe pueden tener funciones de devolución de llamada especifica para lectura o escritura. Los objetos pipe son normalmente usados con tareas SWI y sin bloqueo de ejecución.


47

Capítulo 4. Diseño e implementación de la RF5 en el procesador TMS320DM6437 utilizando un algoritmo de detección de bordes y resultados de tiempo de procesamiento

Para realizar la migración de diseño de la estructura de trabajo al procesador TMS320DM6437 se consideraron los detalles de compatibilidad y diferencias entre dos núcleos similares. El núcleo del procesador DM642 se pueden consultar en el manual “TMS320DM642 Video/Imaging Fixed-Point Digital Signal Processor” [44]. Estos dos dispositivos están basados en núcleos, un subsistema de procesamiento de video y una modalidad de la distribución de memoria y periféricos similares.

Las áreas modificadas para la reconstrucción de la estructura de trabajo son las siguientes: El conjunto de instrucciones, registros, interrupciones, operaciones en el DMA y cambio del temporizador. Por esta razón es necesario ajustar las diferencias existentes en el mapa de memoria y recompilar el código para un núcleo C64x+.

Las instrucciones de compatibilidad entre el núcleo C64x y C64x+ se pueden consultar en manual TMS320C64x/C64x+ DSO CPU and Instruction Set [19].

4.1 Configuración del DSP/BIOS El sistema DSP/BIOS es el software que permite desarrollar aplicaciones en tiempo real para dispositivos embebidos. El sistema DSP/BIOS se instala como parte del CCS V3.3

Las características de programación del DSP/BIOS está contemplada para realizar la configuración de la plataforma, definir el mapa de memoria, configurar la velocidad de reloj, programar la memoria interna nivel dos y uno, inicializar los parámetros específicos de la plataforma, definir los subprocesos y herramientas para el seguimiento y análisis en tiempo real del procesador DM6437. La configuración queda de la siguiente manera (Los detalles de configuración de DSP/BIOS se pueden consultar en “DSP/BIOS 5.40 Textual Configuration (Tconf) User’s Guide” [45]):

/* ======== appcfg.tcf ======== */ /* Configuración de la plataforma específica, mapa de memoria, velocidad CLK. */ var mem_ext = []; /* Configuración de la memoria L2 */ var device_regs = { l2Mode: "0k" }; var params = { clockRate: 1000, catalogName: "ti.catalog.c6000",


deviceName: "TCI6482", regs: device_regs, mem: mem_ext }; /* Personalización de la plataforma con parámetros específicos */ utils.loadPlatform("ti.platforms.generic", params); utils.importFile( "appParams.tci" ); /* Cargar archico TCI para hardware especifico */ utils.importFile( "appBoard.tci" ); /* Cargar archive TCI para la definicion de subprocesos */ utils.importFile( "appThreads.tci" ); /* Cargar archive TCI que define los dispositivos utilizados por el sistema */ utils.importFile( "appDevices.tci" ); /* Cargar el sistema de archivos LOG y objetos STS para la definir la instrumentación*/ utils.importFile( "appInstrument.tci" ); /* Cargar el archive de definición de parámetros del sistema global*/ utils.importFile( "appGlobal.tci" ); bios.RTDX.MODE = "JTAG"; bios.RTDX.MODE = "Simulator"; bios.RTDX.MODE = "JTAG"; bios.GBL.BOARDNAME = "c6437"; bios.GBL.BOARDNAME = "c64xx"; bios.GBL.BOARDNAME = "c64x+"; /* Comprobación de errores en el sistema */ if (config.hasReportedError == false) { prog.gen(); } else { throw new Error( "Error in config script ‐‐ database not generated." ); }

4.2 Modificación de la memoria interna Ajustar la memoria interna del procesador se puede considerar una de las personalizaciones más importantes para el aprovechamiento de la misma.

La programación de la memoria interna nivel uno de programa (L1P) tiene como propósito minimizar el tiempo de ejecución del código. Esta memoria puede configurarse en los tamaños 0K, 4K, 8K, 16K y 32K, quedando 8K como la configuración determinada.

Tabla 4. Registro de memoria L1

Dirección Descripción del registro 0184 0020h L1 Registro de configuración de programa. 0184 0024h L1P Cache de control de registro. 0184 4020h L1P Validación del registro de direcciones. 0184 4024h L1P Validación del contador de palabras. 0184 5028h L1P Validación global.

Todos los registros para la personalización y reprogramación de la memoria L1 y L2 se pueden consultar en la guía de referencia “TMS320C64x+ DSP Megamodule” [21].


49

Tabla 5. Registro de memoria L2

Dirección Descripción del registro 0184 C040h L2 Apagado y encendido de registro 0. 0184 C044h L2 Apagado y encendido de registro 1. 0184 C050h L2 Apagado y encendido de registro 0. 0184 C054h L2 Apagado y encendido de registro 1. 0184 C060h L2 Apagado y encendido de registro 0. 0184 C064h L2 Apagado y encendido de registro 1.

Se realiza la administración de la memoria interna y la comunicación con el núcleo del procesador siguiendo el diagrama a bloques mostrado en la Figura 4.1 y comparando los registros asignados en memoria que se utilizan para controlar la L1P, L1D, áreas de memoria interna y la memoria cache L2 del núcleo C64x y C64x+.

Figura 4.1. Diagrama a bloques de la comunicación de la memoria interna del núcleo C64x+ [21].

La programación para el control de la estructura de trabajo sobre la memoria interna y la comunicación queda de la siguiente manera:

object CACHE_L2 :: MEM { param iIsUsed :: 0 param iId :: 0 param iDelUser :: "USER" param iDelMsg :: "ok" param base :: 10485760 param len :: 0 param iAllocHeap :: 0 param iHeapSize :: 32768 param iUserHeapId :: 0 param iHeapId :: @segment_name


param iReqHeapCount :: 0 param space :: "Cache" param dynamicLoading :: 0 param iIsModifiable :: 1 } object CACHE_L1P :: MEM { param iIsUsed :: 1 param iId :: 0 param iDelUser :: "USER" param iDelMsg :: "ok" param base :: 14680064 param len :: 32768 param iAllocHeap :: 0 param iHeapSize :: 32768 param iUserHeapId :: 0 param iHeapId :: @segment_name param iReqHeapCount :: 0 param space :: "Cache" param dynamicLoading :: 0 param iIsModifiable :: 1 } object CACHE_L1D :: MEM { param iIsUsed :: 1 param iId :: 0 param iDelUser :: "USER" param iDelMsg :: "ok" param base :: 15728640 param len :: 32768 param iAllocHeap :: 0 param iHeapSize :: 32768 param iUserHeapId :: 0 param iHeapId :: @segment_name param iReqHeapCount :: 0 param space :: "Cache" param dynamicLoading :: 0 param iIsModifiable :: 1

4.3 Programación del subsistema de procesamiento de video Las características de los periféricos existentes en la tarjeta TMS320DM6437 se han tratado en el capítulo dos en donde se toca el tema del subsistema de procesamiento de video. Para poder realizar la configuración del sistema encargado de aceptar video y de generar una salida de video, La información detallada sobre el funcionamiento del sistema de captura de video se encuentra en el documento “TMS320DM643x DMP Video Processing Front End (VPFE)” [46].

tvp5150_init(); vpfe_init( 0x82000000, 704, 480); _wait(3000000); VPFE_CCDC_PCR=0x0000000; for(i = 0; i < height; i++) { k = width*i*2; l = width*i*2;


51

for(j = 0; j < width/2; j++) { cb = *((Uint8*)0x82000000 + 2 + 4*j + k); y0 = *((Uint8*)0x82000000 + 1 + 4*j + k); y1 = *((Uint8*)0x82000000 + 3 + 4*j + k); cr = *((Uint8*)0x82000000 + 4*j + k); y0 = (1.00000 * y0) + (0.00000 * cb) + (1.40200 * cr); u0 = (1.00000 * y0) ‐ (0.34414 * cb) ‐ (0.71444 * cr); v0 = (1.00000 * y0) + (1.72200 * cb) + (0.00000 * cr); y1 = (1.00000 * y1) + (0.00000 * cb) + (1.40200 * cr); u1 = (1.00000 * y1) ‐ (0.34414 * cb) ‐ (0.71444 * cr); v1 = (1.00000 * y1) + (1.72200 * cb) + (0.00000 * cr); if(r0 > 255) r0 = 255; else if(r0 < 0) r0 = 0; if(g0 > 255) g0 = 255; else if(g0 < 0) g0 = 0; if(b0 > 255) b0 = 255; else if(b0 < 0) b0 = 0; if(r1 > 255) r1 = 255; else if(r1 < 0) r1 = 0; if(g1 > 255) g1 = 255; else if(g1 < 0) g1 = 0; if(b1 > 255) b1 = 255; else if(b1 < 0) b1 = 0; *((Uint8*)0x83000000 + 6*j + l) = y0; *((Uint8*)0x83000000 + 1 + 6*j + l) = u0; *((Uint8*)0x83000000 + 2 + 6*j + l) = v0; *((Uint8*)0x83000000 + 3 + 6*j + l) = y1; *((Uint8*)0x83000000 + 4 + 6*j + l) = u1; *((Uint8*)0x83000000 + 5 + 6*j + l) = v1; } } vpbe_init( 0x83000000, 704, 480,0); // configura VPBE return 0; }

4.4 Ajustes del temporizador Para satisfacer los requisitos del temporizador se hace uso de la posibilidad de poder modificar los temporizadores a 32 bits, con este cambio la estructura de trabajo será compatible con el núcleo DM6437. Para poder tener úna compatibilidad directa del procesador DM6437 con la estructura de trabajo, el fabricante recomienda modificar el timer al modo unchained 32-bits.

La configuración de los temporizadores DM6437 en el modo no encadenado de 32 bits permite la migración directa del procesador DM642 cumpliendo con los requisitos del temporizador para este dispositivo. Aunque la configuración y asignación de señales diferentes, las capacidades del temporizador del mapa DM6437 también para apoyar los requisitos del temporizador de una aplicación DM642. Todas la características de programación del temporizador se pueden consultar en “TMS320DM643x DMP 64-Bit Timer” [47].


En el diagrama a bloques de la Figura 4.2 se muestra el temporizador en modo desencadenado para el procesador DM6437.

Figura 4.2. Configuración en modo desencadenado del temporizador

La configuración predeterminada para este modulo es temporizador en modo general, la forma de modificar al modo temporizador 32 bits desencadenado es activando el bit TIMMODE a uno en el TGCR como se muestra en la Tabla 6.

Tabla 6. Tabla de descripción del Control de Registros del Temporizador Global.

Bit Función Valor Descripción 3-2 TIMMODE 0-3h TIMMEDO determina el modo del temporizador.

0 El temporizador se encuentra en el modo temporizador 64 bits de propósito general.

1h El temporizador se encuentra en el modo temporizador 32 bits desencadenado.

2h El temporizador se encuentra en el modo temporizador 64 bits Watchdog.

3h El temporizador se encuentra en el modo temporizador 32 bits encadenado.

La versión completa de la Tabla 6 para la configuración del temporizador puede consultar en “TMS320DM643x DMP 64-Bit Timer” [47].


53

4.5 Archivos de aplicación para la RF5 en el procesador DM6437 Los archivos de aplicación como lo son el código de tareas, células y los diferentes módulos (ALGRF, CHAN, SCOM, UTL, etc), se encuentran asociados a la carpeta de implementación de estructura de trabajo para el procesador TMS320DM6437. En la Figura 4.3 se muestran las carpetas que componen la estructura de trabajo exclusivas para el procesador TMS320DM6437, destacando los archivos más importantes contenidos en las carpetas.

Figura 4.3. Estructura de trabajo nivel cinco.

• app/rf5 es la carpeta raíz de la aplicación RF5. • app/rf5/appConfig contiene las aplicaciones específicas de scripts para

el uso de la DM6437, estos archivos crean y configuran objetos de propiedades globales, parámetros específicos, tareas y objetos DIO de la aplicación.

• app/rf5/cells contiene el código de implementación de las células, aquí el sistema se encarga de agregar el código interfaz para el entendimiento de


los algoritmos XDAIS con la aplicación. Debe existir una carpeta por cada algoritmo.

• app/rf5/projects es la carpeta contenedora de los archivos específicos para el procesador TMS320DM6437 con su aplicación RF5, aquí se incluye la configuración específica de la tarjeta. Así como los archivos Linker que son los encargados de llamar a las tareas que componen a la aplicación.

• app/rf5/threads contiene las carpetas con el código para el hardware independiente (configuración de tareas).

• Include contiene los archivos cabecera utilizados por la RF5. • lib contiene las librerías relacionadas con las aplicaciones de la RF5, cada módulo

cuenta con su librería. • src contiene las carpetas con el código fuente de los módulos algrf, chan, scom, sscr,

utl38 y la aplicación. La características de cada módulo se pueden consultar en [38].

4.6 Adaptación de la RF5 Una adaptación a la RF5 puede ser desde cambiar los algoritmos XDAIS a sustituir completamente todas las tareas y el código de la célula. Para poder hacer una adaptación adecuada será necesario añadir nuevos algoritmos, células, canales, tareas, cambiar controladores de los dispositivos o implementar la comunicación de datos en los subprocesos que se ejecutan a velocidades diferentes, en las siguientes secciones se describirá como realizar todos estos cambios para generar la RF5 en el procesador DM6437, esto para poder implementar y probar los algoritmos desarrollados de procesamiento de video e imágenes en la SEPI ESIME Zacatenco.

4.6.1 Agregar nuevo código fuente para los módulos Cuando la RF5 no es suficiente para la adaptación de una aplicación específica es necesario realizar la adaptación de todos los módulos (células, canales, proceso y tareas), para agregar nuevo código a la RF5, se puede comenzar agregando nuevas células y después la forma de trabajo de las tareas (método de abajo hacia arriba), o bien, se puede comenzar por la creación de las tareas que solo se comunican entre sí, y después añadir los canales y células (de arriba hacia abajo). En caso de que la aplicación sea muy parecida a la ya existente en la RF5, es mejor comenzar utilizando el método de abajo hacia arriba.

38 ALGRF: Encargado de utilizar el DSP/BIOS para la asignación de memoria dinámica. CHAN: Administra la ejecución en serie de los algoritmos XDAIS contenidos en una célula. SCOM: Encargado de la comunicación sincronizada que existe entre las áreas. SSCR: Se encarga de la superposición de la memoria de datos solicitada por los algoritmos XDAIS. UTL: Se encarga de la depuración y diagnóstico del sistema.


55

4.6.1.1 Agregar nuevas células y algoritmos XDAIS En la siguiente descripción se muestran los pasos para agregar una nueva célula o para realizar un cambio de algoritmo XDAIS a la RF5.

1. En la carpeta …\estructuradetrabajo5\apps\rf5\cells se crea una nueva carpeta con el nombre de la aplicación (myalg).

2. En la nueva carpeta se escribe en lenguaje C el nuevo algoritmo con el nombre imyalg.c.

3. Se escribe en la carpeta …\estructuradetrabajo5\include el archivo imyalg.h. 4. Se escriben las librerías compiladas de algoritmos en ...\

estructuradetrabajo5\lib. 5. En la carpeta ...\estructuradetrabajo5\apps\rf5\cells\myalg crear la librería

cellMyalg.h. 6. Agregar el archivo cellMyalg al proyecto de aplicación en CCStdio. 7. Modificar el archivo link.cmd, quitar las librerías no utilizadas y agregar las

nuevas. 8. Actualizar los setparamsAndStartChannels() en el archivo thrProcess ubicado en

la dirección …\estructuradetrabajo5\apps\rf5\thread\process. 9. Realizar pruebas de operación con la nueva célula integrada a la RF5 [48].

4.6.1.2 Agregar nuevos canales a las tareas Los canales a diferencia de las células, solo son contenedores, por lo que no es necesario realizar la programación de algún código en especial para la creación de uno o más canales. Solo será suficiente con ampliar la lista CHAN_Objs y escribir el nuevo número de canales y lo mismo para ICELL_Objs para el nuevo número de células. La ruta en donde se encuentran estos objetos es …\ estructuradetrabajo5\apps\rf5\threads\main\appResources.h con la instrucción #define NUMCHANNELS 2.

4.6.1.3 Agregar nuevas tareas a la aplicación Si agregar nuevos canales y células para adaptar la aplicación no es suficiente (debido a que se necesita agregar una tarea totalmente diferente a la ya establecida en la estructura), la última parte para poder adaptar nuestra aplicación es agregar nuevas tareas, y a continuación se hace la descripción del procedimiento:

1. Si la nueva tarea utiliza algoritmos, canales o células, se realizará una copia de la carpeta process ubicada en la dirección …\ estructuradetrabajo5\apps\rf5\threads\process y nos funcionará como plantilla, si


la nueva tarea no utiliza algoritmos, canales o células, realizaremos una copia de la carpeta rxSplit o txJoin y la utilizaremos como plantilla.

2. Si la nueva tarea tiene comunicación con otra tarea (utilizando los mensajes SCOM), se agregará typedef en appThreads.h (ubicada en …\ estructuradetrabajo5\apps\rf5\threads\main).

3. Se agrega la llamada a la función para inicializar la nueva tarea y su puesta en marcha en la appThreads.c (ubicada en …\ estructuradetrabajo5\apps\rf5\threads\main).

4. Agregar una tarea para llamar a la función de la tarea run() de la configuración del DSP/BIOS.

5. Si la tarea recibe mensajes de control, se deben enumerar los mensajes de comandos que corresponden al archivo cabecera de la tarea.

6. Si otra tarea necesita enviar un mensaje de control, se debe incluir el archivo en la cabecera de la tarea.

7. Si la nueva tarea tiene una prioridad diferente a las tareas ya creadas, se tienen que configurar en el DSP/BIOS [48].

4.7 Adaptación de un algoritmo de detección de bordes en la estructura de trabajo nivel cinco

En este capítulo se describe la adaptación de la estructura de trabajo nivel cinco (RF5) para la creación de un sistema de detección de bordes en tiempo real. El proceso de detección de bordes, se puede definir como la transición entre dos regiones de niveles de gris significativamente distintos. La detección de bordes es una herramienta fundamental en el área de procesamiento de imágenes que nos revela información valiosa sobre las fronteras de los objetos que puede ser utilizada para segmentar una imagen, reconocer objetos, etc. La forma de poder realizar la detección de bordes por medio de la discretización de una señal es derivando la señal obtenida (primera o segunda derivada)

Para poder realizar el cálculo de la primera derivada a lo largo de una línea en una imagen como la que se muestra en la Figura 4.4, se realiza a partir de la ecuación ( 2 ) [24]:

( 2 )


57

Figura 4.4. (a) Imagen original, (b) Extracción de la fila central de la imagen (a).

La función que representa a la Figura 4.4 (b) podría verse como se muestra en la Figura 4.5 (a) y su derivada (Figura 4.5 (b)).

Figura 4.5. (a) Función que representa el perfil horizontal de la imagen original. (b) Primera derivada a partir del perfil horizontal.

La derivada de una función continua en un punto x puede ser interpretada por la pendiente de la tangente en ese punto en particular. Sin embargo, en una función discreta la derivada en un punto u (la pendiente de la tangente a ese punto) puede ser calculada a partir de la

Imagen esférica de 4 bits o de 16 niveles de intensidad

Corte transversal de la esfera con un ancho de un pixel


diferencia existente entre los puntos vecinos a u dividido por el valor de muestreo entre ambos puntos. Por lo que la derivada puede ser aproximada por [24]:

( 3 )

Utilizando estos conceptos es como se realiza la implementación de detección de bordes en el procesador TMS320DM6437 que se explica a continuación.

4.8 Estructura del árbol de navegación de la RF5 La estructura de trabajo RF5 tiene una estructura definida para identificar fácilmente los módulos que componen su arquitectura, la navegación que presenta la estructura de trabajo se observa en la Figura 4.6, en donde la implementación de módulos de comunicación, cabeceras y librerías están listan para realizar la personalización de la aplicación que se desea implementar en el procesador DM6437. Para realizar la personalización de la aplicación es necesario modificar las tareas que contienen el código de descripción de canales así como la implementación de la célula contenedora del algoritmo de procesamiento de imagen/video.

Figura 4.6 Árbol de navegación de la RF5.

Módulos de comunicación

Librerías Cabeceras

Personalización de la aplicación

Archivos de configuración para el procesador DM6437

Código para la implementación de células


59

La tarea que sufre más modificaciones es la tarea proceso, que es la tarea principal de la estructura de trabajo ya que es la encargada de procesar el algoritmo principal de la aplicación. La tarea proceso está compuesto por una librería y el código fuente principal para la ejecución de la tarea, en la carpeta process podremos encontrar dos archivos uno con extensión .h que es la librería y otro .c que es el código de la tarea.

4.9 Implementación de un algoritmo de detección de bordes utilizando la estructura de trabajo nivel cinco

Los módulos necesarios para la implementación de un algoritmo de detección de bordes utilizando la estructura de trabajo para el procesador DM6437 se pueden observar en la Figura 4.7 que está compuesta por tres tareas, un módulo de mensaje de comunicación sincronizada unidireccional y otro bidireccional, un driver para el control de periféricos y sus buffers necesarios para guardar la información de forma temporal.

En donde la tarea thrCapture es la encargada de recibir los datos a través del subsistema de procesamiento de video VPFE, almacenando la información en tres buffers diferentes.

Figura 4.7 Procesamiento de un algoritmo de detección de bordes utilizando la RF5.

La función de cada uno de estos elementos se detalla a continuación:

La tarea thrCapture es la encargada de recibir los datos a través del subsistema de procesamiento de video VPFE almacenando la información en tres buffers diferentes.

El módulo SCOM que comparten la tarea thrCapture y thrProcess es un módulo unidireccional en donde la tarea emisora deposita un mensaje cada vez que ha transferido una imagen codificada al buffer intermedio que comparten ambas tareas, el mensaje que intercambian contiene la información de la dirección de memoria en donde comienza la imagen, tamaño de la imagen, estándar de video con el que se encuentra codificada.


La tarea thrProcess se encarga de leer las imágenes codificadas y se realiza el procesamiento de la imagen guardando el resultado en alguno de los tres buffers de salida que comparte con la tarea thrDisplay

El módulo SCOM bidireccional que regula la comunicación entre las tareas thrProcess y thrDisplay en donde la tarea thrProcess deposita un mensaje en el módulo SCOM cada vez que ha terminado el proceso de detección de bordes indicando la dirección en que se encuentra y el tamaño de la imagen, después la tarea thrProcess queda bloqueada en espera de una contestación por parte de la tarea thrDisplay. La tarea thrDisplay recibe el mensaje del módulo SCOM y realiza su proceso para después enviar un mensaje a la tarea thrProcess para que comience a procesar la siguiente imagen y la tarea thrDisplay queda bloqueada en espera de recibir una nueva imagen.

Para terminar el proceso de la aplicación la tarea thrDisplay se encarga de transferir las imágenes procesadas al puerto de video del DSP para que las envíe de forma automática al encoder de video.

El driver Videoport se encarga de transferir las imágenes decodificas que son obtenidas de la tarea thrDisplay al periférico integrado al DSP que se encarga de generar la trama de salida que es enviada al encoder de video.

La comunicación entre tareas se realiza utilizando 2 módulos SCOM. El procedimiento de intercambio de información y su utilidad se puede detallar en el capítulo tres.

4.9.1 Arquitectura de software y flujo de datos Podemos observar en la Figura 4.8 la estructura general contenida en el procesador TMS320DM6437 para la detección de bordes en tiempo real implementada por medio de la RF5, así como las tareas de las que se compone (thrCapture, thrProcess y thrDisplay), que describe de forma general la aplicación en términos de arquitectura de software y de flujo de datos.

Figura 4.8. Flujo de datos de la aplicación.


61

La RF5 tiene la característica de poder implementar fácilmente algoritmos XDAIS, esto quiere decir que el trabajo del diseñador no consiste en realizar el desarrollo real del algoritmo, sino más bien trabajar sobre la incorporación de algoritmos XDAIS o algoritmos de diseño propio de imágenes y video dentro de células e integrarlas para su correcta comunicación con el canal de procesamiento [49].

El sistema de detección de bordes utiliza el algoritmo EDGE XDAIS y su integración celular se realiza encapsulando el algoritmo en una célula y colocándolo en el código de aplicación. Dada la estructura del canal de procesamiento, es necesario agregarle una célula dentro del canal, para utilizar el algoritmo de detección de bordes:

EDGE XDAIS. Ejecuta el algoritmo que se basa en la aproximación discreta de la primera derivada en los niveles de intensidad de la imagen, en donde la derivada de la señal continua proporciona las variaciones locales con respecto a la variable, de forma que el valor de la deriva es mayor cuanto más rápidas son estas variaciones.

El ajuste de la señal de la cámara para el procesamiento de datos se realiza en el formato D139 utilizando la función CONV_YUY2toYUV (realizar el ajuste de tamaño en caso de no coincidir con el requerido para la aplicación).

4.10 Arquitectura de la Tarea de Captura Antes de que la señal sea utilizada por la tarea de captura (thrCapture), se realiza un proceso de digitalización de la señal de video analógica40 entregada por la cámara de video, este proceso de digitalización es ejecutado por el subsistema de procesamiento de video Front-End (VPFE -ver capítulo dos) y entregada a la tarea thrCapture en sistema YUV como se muestra en la Figura 4.9.

Figura 4.9. Digitalización de la señal de video.

39 Formato para cámaras de video con una resolución de 704x480 pixeles. 40 La señal de video analógica, es una señal eléctrica compleja en la que se codifica la imagen en sus diferentes componentes de luz y color agregando la sincronización necesaria para su posterior reconstrucción. La señal de video compuesto consta de una componente de crominancia que es la encargada de portar la información de color de la imagen, una componente de luminancia que se encarga de almacenar los niveles de intensidad de la imagen y el sincronismo que indica las características del barrido efectuado en la captación de la imagen.


Una vez que se ha digitalizado la señal analógica de video, la tarea de captura (thrCapture) se encarga de realizar el proceso de almacenar el sistema YUV41, utilizando solo la parte de luminancia42 y discriminando la crominancia43, como se muestra en la Figura 4.10, en donde el bloque de Video YUV forma parte de la etapa posterior de digitalización de la señal analógica de video y la función de demultiplexión es un algoritmo que forma parte de la tarea thrCapture.

Figura 4.10. Almacenamiento de la imagen en la memoria externa (VPFE). [28]

El almacenamiento de la señal de video en los buffer se realiza con el siguiente código:

static Void getInputFrame(Void) { ... CONV_YUY2toYUV((const Uint16 *) framePtr, CAPF_WIDTH, CAPF_HEIGHT, (Uint16 *) thrCaptureBufferY, (Uint16 *) thrCaptureBufferU, (Uint16 *) thrCaptureBufferV), // se realiza la copia de Y, U, & V en los buffers thrCaptureBufYUV[0] = thrCaptureBufferY; thrCaptureBufYUV[1] = thrCaptureBufferU; thrCaptureBufYUV[2] = thrCaptureBufferV; } //en caso de que se requiera modificar el tamaño de la imagen #define PROCF_HEIGHT (CAPF_HEIGHT) #define PROCF_WIDTH (CAPF_WIDTH)

4.11 Arquitectura de la Tarea Proceso La aplicación para la detección de bordes se ejecuta por medio de la tarea (thrProcess).

La cámara de video captura la imagen, y a su salida, existe una señal de video analógico, esta señal es tomada por la tarea de captura (thrCapure) para su digitalización en el sistema YUV, la tarea de captura se encarga de recibir la imagen al mismo tiempo que almacena el

41 El estándar YUV también conocido como CCIR 601, se encarga de transportar la información de video con respecto a tres componentes, Y(luminancia), U&V (crominancia). 42 La luminancia es la intensidad de luz proveniente o reflejada por un objeto o punto determinado y se define como la densidad angular y superficial de flujo luminoso que incide, atraviesa o emerge de una superficie siguiendo una dirección determinada. 43 Componente de la señal de video que contiene la información de color, y está definido por dos magnitudes, la saturación que nos indica la cantidad de color y el matiz que nos indica que color es.


63

video digital en tres buffers para su posterior procesamiento, cada buffer es procesado por la tarea Process (thrProcess), que es la encargada de realizar la detección de bordes, y por último se envía la información al monitor por medio de la tarea de salida (thrDisplay) en el sistema YUV.

La incorporación del algoritmo de detección de bordes XDAIS EDGE_TI a la RF5 se explica en los siguientes subtemas.

4.12 Personalización de la RF5 Para personalizar una aplicación utilizando la RF5 esta detallada en el capítulo 3. Para la personalización de las tareas que son parte de la arquitectura de la RF5, primero se ubica la tarea que se desea cambiar en este caso es integrar nuestro algoritmo de detección de bordes, y para que lo pueda interpretar la RF5 es necesario que este algoritmo se encuentre encapsulado en una célula que sirve como interfaz con el canal de comunicación.

Una vez ubicada la carpeta de la tarea thrProcess es necesario abrir el archivo .h que se encuentra en su interior que como se muestra en Figura 4.11.

Los detalles de su configuración se detallan a continuación.

4.12.1 Creación del canal de procesamiento En esta sección se realiza la descripción de la estructura del canal, encargado de contener la célula de detección de bordes.

Antes de encapsular el algoritmo es necesario describir el canal que se va a utilizar, para esto se necesita primero definir el número de canales requeridos por thrProcess.h (…estructuratrabajo5/apps/rf5/threads/process), este proceso nos permite crear cualquier estructura de canales requerida por medio de dos conjuntos de instrucciones, un conjunto de instrucciones define el tipo y número de canales y otro conjunto de instrucciones describe el número de células contenidas en cada canal.

El primer conjunto de instrucciones describe el tipo y número de canales que se van a implementar, dado que solo necesitamos un canal para la detección de bordes, se agrega el canal NUMEDGECHANS con el valor uno.

/**** thrProcess.h ****/ // canal para la detección de bordes enum { CHEDGE = 1, NUMEDGECHANS };


Figura 4.11. Modificación del archivo thrProcess.h para inicializar canales y células.

El siguiente conjunto describe el número de células utilizadas por el canal, en este caso el canal EDGE tiene una célula (CHEDGENUMCELLS) y se describe de la siguiente manera.

/**** thrProcess.h ****/ // célula EDGE enum { CHEDGECELLEDGE = 1, CHEDGECELLYUV, CHEDGENUMCELLS };

La estructura de la tarea thrProcess define su característica general y el estado del sistema, entre las variables contenidas en esta tarea se encuentran CHAN y los objetos ICELL para el canal, y la implementación es la siguiente.

/**** thrProcess.h ****/ /*descripción del estado de la tarea (definición de la estructura)*/ typedef struct ThrProcess { CHAN_Obj edgeChans[NUMEDGECHANS]; ... ICELL_Obj edgeCells[NUMEDGECHANS * CHEDGENUMCELLS]; ... Int edgePlacement[NUMEDGECHANS]; ... }

Número de canales

Número de células utilizadas por el canal

Integración de módulos en la tarea thrProcess


65

4.12.2 Procedimiento para habilitar e inicializar el canal Una vez definida la estructura es necesario habilitar el canal; para esto se ejecuta un bucle para el canal que contiene la célula EDGE, en este caso el bucle se ejecuta una sola vez como parte de una rutina de inicializacion, el código esta contenido en el archivo thrProcess.c.

//abrir el canal edge for (chanNum = 1; chanNum < NUMEDGECHANS; chanNum++) { // cunjunto de parámetros para el algoritmo thrProcess.edgeCells[chanNum * CHEDGENUMCELLS].algParams =

(IALG_Params *)&edgeParams; // abrir el canal UTL_logDebug1("Process channel: %d", chanNum); rc = CHAN_open( &thrProcess.edgeChans[chanNum], &thrProcess.edgeCells[chanNum * CHEDGENUMCELLS], CHEDGENUMCELLS, NULL ); UTL_assert( rc == TRUE ); }

La ejecución del canal esta contenida en la función principal de la tarea thrProcess (…estructuratrabajo5/apps/rf5/threads/process/thrProcess.c), ejecutando la función thrProcessRun en un bucle infinito.

//ejecución del canal edge for (chanNum = 1; chanNum < NUMEDGECHANS; chanNum++) { chan = &(thrProcess.edgeChans[chanNum]); // asignación del buffer a los objetos ICC // buffer para el modulo SCOM ICC_setBuf(chan‐>cellSet[CHEDGECELLEDGE].inputIcc[1], scombufCap‐>bufYUV, 1); ICC_setBuf(chan‐>cellSet[CHEDGECELLYUV].outputIcc[1], scombufDisp‐>bufYUV + thrProcess.edgePlacement[chanNum], 1); UTL_stsStart( stsExeTimeChEdge ); rc = CHAN_execute( &thrProcess.edgeChans[ chanNum ], NULL ); UTL_assert( rc == TRUE ); UTL_stsStop( stsExeTimeChEdge ); }

4.12.3 Condiciones para agregar una célula Despues de haber personalizado el canal es necesario configurar las condiciones para agregar la célula que estará dentro del canal. La célula es el contenedor del algoritmo que se agregará a la RF5, el administrador del canal (CHAN) utiliza la célula como interfaz de ejecucion, la integración celular al canal es de la siguiente manera:

La variable utilizada necesita ser declarada en ThrProcess.h

/* definición de la estructura describiendo el estado de la tarea */ typedef struct ThrProcess {


... EDGE_Env edgeEnv[NUMEDGECHANS]; ... }

La estructura de ThrProcess es utilizada para almacenar las variables necesarias para la ejecucion del algoritmo, esta estructura necesita ser inicializada.

//configuración de las características de la célula edge for(i = 0; i < (NUMEDGECHANS); i++) { thrProcess.edgeEnv[i].intYBuf = intYBuf; thrProcess.edgeEnv[i].intUBuf = intUBuf; thrProcess.edgeEnv[i].intVBuf = intVBuf; thrProcess.edgeEnv[i].yBufSize = EDGE_Y_BUFSIZE; thrProcess.edgeEnv[i].uBufSize = EDGE_U_BUFSIZE; thrProcess.edgeEnv[i].vBufSize = EDGE_V_BUFSIZE; thrProcess.edgeEnv[i].numBlocks = EDGE_NUMBLOCKS;

}

4.13 Arquitectura de la Tarea Display La tarea display (thrDisplay), realiza el proceso de convertir los resultados digitales en una señal analógica, este proceso de conversión es ejecutado por el subsistema de procesamiento de video Back-End (VPBE -ver capítulo dos) y finalmente se envía la señal de video analógico a un monitor como se muestra en la Figura 4.12.

Figura 4.12. Conversión digital analógica.

El código fuente de esta tarea se encuentra en thrDisplay.c y thrDisplay.h (…/estructuratrabajo5/apps/rf5/threads/display).

La aplicación principal de la tarea Display se escribe como sigue:

for (chanNum = 0; chanNum < NUMEDGECHANS; chanNum++) { DAT_copyd(DAT_1D2D, scombufCap‐>bufYUV[Y],scombufDisp‐>bufYUV[Y], PROCF_WIDTH, PROCF_HEIGHT,OPF_WIDTH); DAT_copyd(DAT_1D2D, scombufCap‐>bufYUV[CR],scombufDisp‐>bufYUV[U], PROCF_WIDTH >> 1, PROCF_HEIGHT >> 1, OPF_WIDTH >> 1); prevCbId = DAT_copyd(DAT_1D2D, scombufCap‐>bufYUV[V],scombufDisp‐>bufYUV[V], PROCF_WIDTH >> 1, PROCF_HEIGHT >> 1, OPF_WIDTH >> 1); DAT_wait(prevCbId); }


67

4.14 Análisis en tiempo real utilizando el DSP/BIOS El DSP/BIOS utilizado por el CCS proporciona varios módulos de análisis en tiempo real, incluyendo el LOG de mensajes de registro y STS para las estadísticas calculadas. La instrumentación LOG y STS transfiere los datos estadísticos a la PC. Los resultados obtenidos de los algoritmos procesados en la tarjeta TMS320DM6437, se obtuvieron realizando el método “stop-mode”, debido a problemas de compatibilidad con el RTDX (no se tiene compatibilidad de la tarjeta TMS320DM6437 con el módulo RTDX), algunas veces existe incompatibilidad del software para poder utilizar el RTDX, pero los resultados se pueden obtener deteniendo la aplicación.

4.14.1 Módulo UTL En la programación de la RF5 se encuentran módulos llamados UTL, que son macros que contienen el prefijo UTL_xxx. Estos macros pueden ser expandidos con el código que realiza la función de depuración, en particular, los módulos CHAN, ICC, SSCR, y SCOM, que hacen uso de la macro UTL_assert.

Con la expansión condicionada por el código de las macros, se puede reducir el tamaño del código y eliminar funciones innecesarias en la fase de implementación.

Todas la macros UTL las podemos encontrar en el documento: Reference Frameworks for eXpressDSP Software: API Reference [38].

El módulo UTL implementa las siguientes clases de funciones de depuración:

Message severity macros. Errores, advertencias, mensajes de diagnóstico, y mensajes de depuración son enviados a través de las macros que expanden a LOG_printf()-style. Los nombres de las macros son UTL_logError, UTL_logWarning(), UTL_logMessage(), y UTL_logDebug().

Assertion macro. Detiene la ejecución cuando existe alguna falla y muestra la línea de código fuente en la ventana de depuración, la sintaxis de la macro es UTL_assert(<condición>). Esta función en particular es muy útil en las operaciones de inicialización como puede ser en la ejecución de un algoritmo.

Time measurement macros. Esta macro se encarga de medir el tiempo de ejecución que existe entre dos ejecuciones periódicas en un punto del programa. Las estadísticas se muestran en los objetos STS en CCStudio. Las macros son UTL_stsStart() y UTL_stsSTOP() para los tiempos de ejecución, UTL_stsPeriod() para medir el tiempo entre dos ejecuciones periódicas en un punto del programa, y UTL_stsPhase para la medición de fase entre dos puntos periódicos. La RF5 implementada para el procesador


TMS320DM6437 contiene diez objetos STS que se pueden utilizar para la medición de tiempo/periodo con funciones UTL_sts.

XDAIS algorithm diagnostics macros. La macro se encarga de reportar el uso de la pila y requisitos XDAIS, los nombres de las macros son UTL_showAlgMem() y UTL_showHeapUsage().

En la Tabla 7 se observa el cuadro comparativo para la función de detección de bordes con RF5 y sin RF544 utilizando el procesador DM6437 a 594 MHz en formato de video D1 NTSC:

Tabla 7. Cuadro comparativo de tiempo de procesamiento de un algoritmo con RF5 y sin RF5 en una trama.

Función (Procesamiento con RF5)

Tiempo (ms)

Función (Procesamiento sin RF5)

Tiempo (ms)

Extracción de luminancia 0.8 Extracción de luminancia 3.2 Extracción de una ventana

7x7 1.2 Extracción de una ventana

7x7 5.7

Gradiente y magnitud 2.0 Gradiente y magnitud 13.7 Bucle de detección de

máximos locales 4.3 Bucle de detección de

máximos locales 10

Procesamiento de la imagen (para crear una imagen

binaria)

5.9 Procesamiento de la imagen (para crear una

imagen binaria)

9.7

Algoritmo de detección de bordes

18.5 Algoritmo de detección de bordes

47.6

Insertar crominancia 5.9 Insertar crominancia 8.5 Tiempo de procesamiento 38.6 Tiempo de procesamiento 98.4

Tabla 8. Cuadros por segundo procesados en un algoritmo de detección de bordes con RF5 y sin RF5.

Función (Procesamiento con RF5) FPS Función

(Procesamiento sin RF5) FPS

Cuadros por segundo 25.9 Cuadros por segundo 10.2

A modo de comparación, al implementar un algoritmo de procesamiento de video en el procesador DM642 a 720 MHz con una estructura de trabajo nivel cinco, utilizando un filtro de vector de mediana (FVM) tiene un resultado de tiempo de procesamiento para un cuadro que se muestra en la Tabla 9 [50].

44 El algoritmo de detección de bordes sin la utilización de una estructura de trabajo fue realizada utilizando Simulink de MatLab utilizando diferentes módulos (Video Capture DM6437, Deinterleave YCbCr, Edge Detection, Convert Image y Video Display), se realiza la traducción de MatLab a un proyecto compatible con Code Compose Studio generando el código en lenguaje C (librerías, drivers, y código fuente) que servirá como software de comparación con la RF.


69

Tabla 9. Tiempo de procesamiento para una trama utilizando el procesador DM642 con una estructura de trabajo nivel cinco.

Función (Procesamiento con RF5)

Tiempo (ms)

FVM (DM642) 26.6

Un IDK (Image Developer’s Kit) es una plataforma de prototipado rápido para el desarrollo de algoritmos de procesamiento de imágenes y video. Utilizando las herramientas de hardware y software se pueden implementar algoritmos conceptuales en la tarjeta IDK, con entrada y salida de video en tiempo real, el resultado de tiempo de procesamiento de una trama ejecutando un algoritmo FVM se muestra en la Tabla 10 [50].

Tabla 10. Tiempo de procesamiento de una trama con un algoritmo FVM en un IDK.

Función Tiempo (ms)

FVM (IDK) 122

Se realizo la medición del tiempo de procesamiento en tres tramas diferentes en formato D1 utilizando la estructura de trabajo nivel cinco implementada en el procesador DM6437, los resultados se muestran en la Figura 4.13.

(a) Lampara. (b) Columna y techo. (c) Circuito impreso

38.6 ms 38.6 ms 38.6 ms Figura 4.13. Tiempo de procesamiento para tres tramas diferentes.

4.15 Conclusiones Los tiempos de procesamiento para el algoritmo de detección de bordes permanecen constantes sin que dependa del número de detalles que contenga la trama, ya que al proceso de implementación realiza la exploración de la imagen siempre en su totalidad.

La implementación de la estructura de trabajo nivel cinco en el procesador TMS320DM6437 reduce al mínimo los requisitos de memoria interna del procesador, lo que nos permite tener un mejor tiempo de procesamiento de datos en la memoria cache, además de mejorar el tiempo gracias al módulo SSCR encargado de la superposición de datos que son solicitados por el algoritmo de detección de bordes.


La RF5 permite la adaptación rápida de una aplicación y de forma personalizada. La RF5 puede ser tomada como una metodología para la construcción de diferentes aplicaciones en el área de procesamiento de video e imágenes, gracias a la estructura de programación para la inserción o extracción de algoritmos hace que el código sea reutilizable o utilizado como un punto de partida para futuros proyectos, que nos permite en periodos cortos de tiempo, realizar la ejecución de código de procesamiento de imágenes y video, que se verán reflejados en la implementación de proyectos con un tiempo de desarrollo, pruebas y validación mucho menores.


71

Capítulo 5. Conclusiones y trabajo a futuro Este trabajo de investigación y adaptación hacia el procesador TMS320DM6437, se concentra en la correcta programación y aprovechamiento de los recursos que se tienen con la arquitectura de hardware, nos enfocamos en dejar la tarjeta programada en sus puertos de entrada y salida utilizando las potencialidades que nos ofrecen las herramientas de TI (DSP/BIOS, CCS y Algoritmos XDAIS), lo que permitirá concentrar los esfuerzos en el desarrollo de algoritmos de procesamiento de imágenes y video en lugar de enfocarnos en la programación de la tarjeta, así la migración de nuestro algoritmo de procesamiento de imágenes y video para la tarjeta será más simple de probar y validar.

Con la implementación de un algoritmo de detección de bordes se comprueba la funcionalidad de la estructura de trabajo nivel cinco en el procesador TMS320DM6437.

Los resultados obtenidos con respecto a las pruebas de implementación de un algoritmo de detección de bordes, comprueba que se mejoró el tiempo de procesamiento utilizando la estructura de trabajo implementada, y el número de tramas analizadas por segundo se mejoro con respecto a una programación sin RF5.

Al utilizar la RF5 se aprovecha de mejor manera la arquitectura específica del procesador, reduciendo al mínimo los requisitos de memoria interna, lo que nos permite tener una mejor administración de la memoria cache y por consecuencia se aceleraran los cálculos matemáticos y de esta manera se logra mejorar el tiempo de procesamiento.

La RF5 puede ser tomada como una metodología para la construcción de diferentes aplicaciones por su flexibilidad comparadas con la RF1 y RF3. Gracias a su estructura de programación facilita la inserción o extracción de algoritmos lo que hace que el código sea reutilizable o también puede ser utilizado como un punto de partida para futuros proyectos.

La implementación de la RF5 actualmente solo esta probada para la implementación de algoritmos de imagen/video. Es importante mencionar que por el momento no se ha realizado la implementación de algoritmos de procesamiento de audio, así como el control del puerto RS232 y el envió de video a través del puerto Ethernet.


5.1 Trabajo a futuro El trabajo realizado de implementación de la estructura de trabajo nivel cinco probando su funcionamiento utilizando un algoritmo de detección de bordes, el trabajo a futuro está en probar otros algoritmos de procesamiento de imágenes/video.

Realizar pruebas en la cual se generen dos o más canales y en cada canal se introduzcan más de una célula para probar la multicanalidad y multiprocesamiento.

Migrar la estructura de trabajo a la nueva plataforma de programación CCS 5.3, utilizando la nueva versión de drivers y CSL, probando el reconocimiento de periféricos y tiempo de procesamiento.

Implementar la RF5 con los módulos de procesamiento de audio.

Utilizar un sistema mínimo para el procesamiento de imagen/video utilizando la estructura de trabajo como herramienta de diseño de proyecto.


73

Referencias [1] A. Varfolomieiev, O. Antonyuk y O. Lysenko, «CAMSHIFT object tracking algorithm

implementation on dm6437 EVM,» Proceedings of the 4th European DSP in Education and Research Conference, pp. 96-100, 2010.

[2] N. Bharatkumar Gohil, «Car license plate detection,» 2010.

[3] Texas Instruments, «TMS320C6000 DSP/BIOS Application Programming Interface (API) Reference Guide,» [En línea]. http://www.ti.com/lit/ug/spru403g/spru403g.pdf.

[4] Texas Instruments, «eXpressDSP Algorithm Standard Rules and Guidelines,» [En línea]. eXpressDSP Algorithm Standard Rules and Guidelines.

[5] S. F. I. o. T. (EPFL), «Decision Tradeoff Using Example-Critiquing,» p. 290, 2004.

[6] N. Kehtarnavaz y M. Gamadia, Real-Time Image and Video Processing: From Research to Reality, Morgan & Claypool, 2006.

[7] A. Bovik, “Introduction to Digital Image and Video Processing” Handbook of Image and Video Processing, Amsterdam, 2005.

[8] J. L. Hennessy y D. A. Patterson, Computer Architecture: A Quantitative Approach, Prentice Hall.

[9] S. A. McKee, «Reflections on the Memory Wall,» Computer Systems Laboratory, Abril 2004.

[10] M. K. Dong, Z. J. Hu y F. B., «Research on Architectures for High Performance Image Processing,» Proceedings of the Fourth International Workshop on Advanced Parallel Processing Technologies, 2001.

[11] B. H., C. W., J. P. y K. R., «Architecture Study for Smart,» Proceedings of the European Optical Society Conference on Industrial Imaging and Machine Vision, pp. 39-49, 2005.

[12] K. S., O. S. y A. T., «An Integrated Memory Array Processor Architecture for Embedded Image Recognition Systems,» Proceedings of the 32nd International Symposium on Computer Architecture, pp. 134-135, 2005.

[13] «Intel Processor,» [En línea]. http://www.intel.com/content/www/us/en/processor-


comparison/compare-intel-processors.html.

[14] «ARM The arqchiteture for the Digital World,» [En línea]. http://www.arm.com/products/processors/index.php.

[15] S. A. Dyer y B. K. Harms, «Digital Signal Processing,» Journal: "Advances in Computers, pp. 59-117, 1993.

[16] M. Sandler, L. Hayat, L. Costa y A. Naqvl, «A comparative evaluation of DSPs, Microprocessors and the transputer for image processing,» Dept. Electronic & Electrical Engineering,, pp. 1532-1535.

[17] Texas Instruments, «TMS320C6000 DSP External Memory Interface (EMIF), Reference Guide,» 2008. [En línea]. http://www.ti.com/lit/ug/spru266e/spru266e.pdf .

[18] Texas Instruments, «TMS320C64x+ DSP Cache,» [En línea]. Available: http://www.ti.com/lit/ug/spru862b/spru862b.pdf.

[19] Texas Instruments, «TMS320C64x/C64x+ DSP CPU and Instruction Set,» [En línea]. http://focus.ti.com/lit/ug/spru732j/spru732j.pdf.

[20] Texas Instruments, «TMS320DM6437 Digital Media Procesor,» [En línea]. http://www.ti.com/product/tms320dm6437.

[21] Texas Instruments, «TMS320C64x+ DSP Megamodule, Reference Guide,» [En línea]. http://www.ti.com/lit/ug/spru871k/spru871k.pdf.

[22] Texas Instruments, «TMS320DM6437 Digital Media Processor (Rev. D),» 2006. [En línea]. www.ti.com/lit/ds/sprs345d/sprs345d.pdf.

[23] Texas Instruments, «TMS320DM643x DMP Host Port Interface (HPI),» 2007. [En línea]. http://www.ti.com/lit/ug/spru998d/spru998d.pdf.

[24] R. Gonzalez y R. Woods, Digital Image Processing, Addison-Wesley, 1992.

[25] Texas Instruments, «How to Use the VPBE and VPFE Driver on TMS320DM643x,» 2007. [En línea]. http://www.ti.com/lit/an/spraap3a/spraap3a.pdf.

[26] International Telecommunication Union, «International Telecommunication Union,» [En línea]. Available: http://www.itu.int/rec/R-REC-BT.656/en.

[27] IEEE Computer Society, «Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks


75

(WPANs),» 2006.

[28] Texas Instruments, «TMS320DM643x DMP DSP Subsystem Reference Guide,» 2008. [En línea]. http://www.ti.com/lit/ug/spru978e/spru978e.pdf.

[29] Texas Instruments, «TMS320DM6437/35/33/31 Digital Media Processor (DMP) Silicon Revisions 1.3, 1.2, 1.1, and 1.0,» 2011. [En línea]. http://www-s.ti.com/sc/techlit/sprz250.

[30] Texas Instruments, «TMS320C64x DSP Two-Level Internal Memory Reference Guide,» 2006. [En línea]. http://www.ti.com/lit/ug/spru610c/spru610c.pdf.

[31] Texas Instruments, «TMS320DM643x DMP Peripherals Overview Reference Guide,» 2007. [En línea]. http://www.ti.com/lit/ug/spru983a/spru983a.pdf.

[32] Texas Instruments, «Using the TMS320DM643x Bootloader,» 2012. [En línea]. http://www.ti.com/lit/an/spraag0e/spraag0e.pdf.

[33] Texas Instruments, «TMS320DM643x DMP Enhanced Direct Memory Access (EDMA3) Controller,» 2008. [En línea]. http://www.ti.com/lit/ug/spru987a/spru987a.pdf.

[34] L. A. y K. D., «High-Quality Algorithm for Bayer Pattern Interpolation,» Programming and Computer Software, vol. 30, nº 6, pp. 347-358, 2004.

[35] Analog Devices, «12-Bit, Integrated, Multiformat SDTV/HDTV Video Decoder and RGB Graphics Digitizer,» 2005.

[36] A. Osborne, An Introduction to Microcomputers Volume 1: Basic Concepts, vol. 1, Osborne-McGraw Hill.

[37] Texas Instruments, «Reference Frameworks for eXpressDSP Software: RF1, A Compact Static System,» Mayo 2003. [En línea]. http://www.ti.com/lit/an/spra791d/spra791d.pdf.

[38] Texas Instruments, «Reference Frameworks for eXpressDSP Software: API Reference,» Marzo 2002. [En línea]. http://my.fit.edu/~vkepuska/ece3551/TI%20Tutorial/Chapters/Xdais/spra147.pdf.

[39] Texas Instruments, «Reference Frameworks for eXpressDSP Software: RF3, A Flexible, Multi-Channel, Multi-Algorithm, Static System,» Abril 2003. [En línea]. http://www.ti.com/lit/an/spra793d/spra793d.pdf.


[40] Texas instruments, «TMS320VC5402 Fixed-Point Digital Signal Processor,» Octubre 1998. [En línea]. http://www.ti.com/lit/ds/symlink/tms320vc5402.pdf.

[41] Texas Instruments, «Reference Frameworks for eXpressDSP Software: RF5, An Extensive, High-Density System,» Abril 2003. [En línea]. http://www.tij.co.jp/jp/lit/an/spra795a/spra795a.pdf.

[42] Texas Instruments, «Building IOM-Compliant Drivers from the DCP Tool,» Septiembre 2005. [En línea]. http://www.ti.com/lit/an/spraab8/spraab8.pdf.

[43] Texas Instruments, «TMS320DM643x DMP Multichannel Buffered Serial Port (McBSP) Interface,» Septiembre 2007. [En línea]. http://www.ti.com/lit/ug/spru943c/spru943c.pdf.

[44] Texas Instruments, "TMS320DM642 Video/Imaging Fixed-Point Digital Signal Processor," Octubre 2010. [En línea]. http://www.ti.com/lit/ds/symlink/tms320dm642.pdf.

[45] Texas Instruments, "DSP/BIOS 5.40 Textual Configuration (Tconf) User’s Guide," Febrero 2009. [Online]. Available: http://www.ti.com/lit/ug/spru007i/spru007i.pdf.

[46] T. Instruments, «TMS320DM643x DMO Video Processing End (VPFE) User's Guide,» Octubre 2010. [En línea]. http://www.ti.com/lit/ug/spru977d/spru977d.pdf.

[47] Texas Instruments, «TMS320DM643x DMP 64-Bit Timer User's Guide,» Enero 2009. [En línea]. http://www.ti.com/lit/ug/spru989/spru989.pdf.

[48] Texas Instruments, «DSP/BIOS Driver Developer's Guide,» Noviembre 2002. [En línea]. http://www.eit.lth.se/fileadmin/eit/courses/eti121/References/spru616.pdf.

[49] Texas Instruments, «TMS320 DSP Algorithm Standard Rules and Guidelines,» Febrero 2007. [En línea]. http://www.ti.com/lit/ug/spru352g/spru352g.pdf.

[50] A. J. Rosales Silva, «Métodos y algoritmos de procesamiento de imágenes multiespectrales y multicanales en 2d y 3d para supresión de ruido implementándolos en hardware,» México D.F., 2008.

[51] Texas Instruments, «Codec Engine Al gorithm Creator User’s Guide,» Septiembre 2007. [En línea]. http://www.ti.com/lit/ug/sprued6c/sprued6c.pdf.


77

Anexos

/*Obtener las muestras de imagen utilizando cualquier cámara de video con salida analógica */

/*Iniciar el proceso de digitalización utilizando el subsistema de procesamiento de video*/

/*Iniciar la separación de canales utilizando tres buffers diferentes*/

/*Seleccionar el buffer con el contenido de luminancia utilizado por el algoritmo de detección de bordes*/

/*Procesar el contenido de luminancia utilizando un algoritmo XDAIS*/

/*Transformar los resultados en escala de grises a resultados binarios*/

/*Reconstruir la imagen con sus componentes de crominancia para obtener una imagen YUV */

/*Convertir la imagen digital a analógica utilizando el subsistema de procesamiento de video*/

/*Mostrar resultados en pantalla*/

Cámara de videoCámara de video

Digitalización de la imagen(VPFE)

Separación de canales(Y, U, V)

Separación de canales(Y, U, V)

Buffer = YBuffer = Y Buffer = 0Buffer = 0

EDGE XDAISEDGE XDAIS

Transformación de la imagen

Transformación de la imagen

Reconstruirimagen

Reconstruirimagen

CAD(VPBE)CAD(VPBE)

Mostrar en pantallaMostrar en pantalla

no

si


/**** ======== thrProcess.h ======== ****/ /*configuración del número de canales y células utilizadas en nuestro proyecto*/ #ifndef THRPROCESS_ #define THRPROCESS_ #include <chan.h> #include <icell.h> #include "edge/celledge.h" #include "appThreads.h" #ifdef __cplusplus extern "C" { #endif #define edge_NUMLINES 2 #define edge_NUMBLOCKS (PROCF_HEIGHT / edge_NUMLINES) // tamaño del buffer (utilizando doble buffer) #define edge_Y_BUFSIZE ((2 * PROCF_WIDTH) * edge_NUMLINES) #define edge_U_BUFSIZE (((2 * PROCF_WIDTH) * edge_NUMLINES) >> 2) #define edge_V_BUFSIZE (((2 * PROCF_WIDTH) * edge_NUMLINES) >> 2) // definir el número de canales enum { CHEDGE = 1, NUMEDGECHANS }; // definir el número de células enum { CHEDGECELLEDGE = 1, CHEDGENUMCELLS }; /* prototypes for public functions */ extern Void thrProcessInit( Void ); extern Void thrProcessStartup( Void ); extern Void thrProcessRun( Void ); #ifdef __cplusplus } #endif // extern "C" #endif // THRPROCESS_


79

/**** ======== thrProcess.c ======== ****/ /*Configuración de la estructura del proyecto */ #include <std.h> #include <sts.h> #include <string.h> #include <tsk.h> #include <csl_dat.h> #include <csl_cache.h> #include <chan.h> #include <icell.h> #include <scom.h> #include <icc_linear.h> #include <utl.h> #include "edge/celledge.h" #include "thrProcess.h" #pragma DATA_SECTION(ybuffCap,".EXTPROCBUFF"); #pragma DATA_SECTION(ubuffCap,".EXTPROCBUFF"); #pragma DATA_SECTION(vbuffCap,".EXTPROCBUFF"); #pragma DATA_SECTION(ybuffDis,".EXTPROCBUFF"); #pragma DATA_SECTION(ubuffDis,".EXTPROCBUFF"); #pragma DATA_SECTION(vbuffDis,".EXTPROCBUFF"); #pragma DATA_SECTION(ybuff,".EXTPROCBUFF"); #pragma DATA_SECTION(ubuff,".EXTPROCBUFF"); #pragma DATA_SECTION(vbuff,".EXTPROCBUFF"); #pragma DATA_ALIGN(ybuffCap,MEMALIGN); #pragma DATA_ALIGN(ubuffCap,MEMALIGN); #pragma DATA_ALIGN(vbuffCap,MEMALIGN); #pragma DATA_ALIGN(ybuffDis,MEMALIGN); #pragma DATA_ALIGN(ubuffDis,MEMALIGN); #pragma DATA_ALIGN(vbuffDis,MEMALIGN); #pragma DATA_ALIGN(ybuff,MEMALIGN); #pragma DATA_ALIGN(vbuff,MEMALIGN); #pragma DATA_ALIGN(ubuff,MEMALIGN); #pragma DATA_SECTION(intYBuf, ".INTPROCBUFF"); #pragma DATA_SECTION(intUBuf, ".INTPROCBUFF"); #pragma DATA_SECTION(intVBuf, ".INTPROCBUFF"); #pragma DATA_SECTION(prevY, ".EXTPROCBUFF"); #pragma DATA_SECTION(prevU, ".EXTPROCBUFF"); #pragma DATA_SECTION(prevV, ".EXTPROCBUFF"); #pragma DATA_ALIGN(intYBuf, MEMALIGN); #pragma DATA_ALIGN(intUBuf, MEMALIGN); #pragma DATA_ALIGN(intVBuf, MEMALIGN); #pragma DATA_ALIGN(prevY, MEMALIGN); #pragma DATA_ALIGN(prevU, MEMALIGN); #pragma DATA_ALIGN(prevV, MEMALIGN);


ThrProcess thrProcess; // Buffers para el modulo ICC static Char ybuff [ PROCF_SIZE_IN_PIXELS ]; static Char ubuff[ PROCF_SIZE_IN_PIXELS >> 2 ]; static Char vbuff[ PROCF_SIZE_IN_PIXELS >> 2 ]; static Char *bufYUV[3] = {ybuff, ubuff, vbuff}; // Buffers para el modulo SCOM static Char ybuffCap [ PROCF_SIZE_IN_PIXELS ]; static Char ubuffCap[ PROCF_SIZE_IN_PIXELS >> 2 ]; static Char vbuffCap[ PROCF_SIZE_IN_PIXELS >> 2 ]; static Void setParamsAndStartChannels( Bool doChannelOpen ); static Void checkMsg(); Void thrProcessInit() { Int i; scomReceiveFromCapture = SCOM_ueate( "scomToProcessFromCapture", &SCOM_ATTRS ); scomReceiveFromDisplay = SCOM_ueate( "scomToProcessFromDisplay", &SCOM_ATTRS ); UTL_assert( scomReceiveFromCapture != NULL); UTL_assert( scomReceiveFromDisplay != NULL); for(i = 0; i < (NUMEDGECHANS + NUMCOMBOCHANS); i++) { thrProcess.edgeEnv[i].intYBuf = intYBuf; thrProcess.edgeEnv[i].intUBuf = intUBuf; thrProcess.edgeEnv[i].intVBuf = intVBuf; thrProcess.edgeEnv[i].prevY = prevY; thrProcess.edgeEnv[i].prevU = prevU; thrProcess.edgeEnv[i].prevV = prevV; thrProcess.edgeEnv[i].yBufSize = EDGE_Y_BUFSIZE; thrProcess.edgeEnv[i].uBufSize = EDGE_CR_BUFSIZE; thrProcess.edgeEnv[i].vBufSize = EDGE_CB_BUFSIZE; thrProcess.edgeEnv[i].numBlocks = EDGE_NUMBLOCKS; } Void thrProcessStartup() { setParamsAndStartChannels( TRUE ); } /** ======== inicialización de canales ========**/ static Void setParamsAndStartChannels( Bool doChannelOpen ) {


81

IEDGE_Params edgeParams; ICC_Handle inputIcc; ICC_Handle outputIcc; Uns chanNum; ICELL_Handle cell; Bool rc; // parámetros para todos los algoritmos XDAIS edgeParams=IEDGE_PARAMS; if (doChannelOpen == FALSE) { ICELL_Obj defaultCell = ICELL_DEFAULT; for (chanNum = 0; chanNum < NUMEDGECHANS; chanNum++) { cell = &thrProcess.edgeCells[ chanNum * CHEDGENUMCELLS ]; *cell = defaultCell; cell‐>name = "EDGE"; cell‐>cellFxns = &EDGE_CELLFXNS; cell‐>cellEnv = (Ptr *)&thrProcess.diffEnv[chanNum]; cell‐>algFxns = (IALG_Fxns *)&EDGE_IEDGE; cell‐>algParams = (IALG_Params *)&diffParams; cell‐>suBucketIndex = VIDEOPROCSCRBUCKET; inputIcc = (ICC_Handle)ICC_linearUeate( NULL, 0); UTL_assert( inputIcc != NULL); outputIcc = (ICC_Handle)ICC_linearUeate( &thrProcess.OutputBuff, sizeof(thrProcess.OutputBuff)); UTL_assert( outputIcc != NULL); rc = CHAN_regCell ( cell, &inputIcc, 1, &outputIcc, 1 ); } /**** thrProcessRun ****/ Void thrProcessRun() { CHAN_Handle chan; Int prevYId; Int prevUId; Int prevVId; UTL_logDebug1("thrProcessRun: task = 0x%x", TSK_self()); scomSendToCapture = SCOM_open( "scomCapture" ); scomSendToDisplay = SCOM_open( "scomDisplay" ); UTL_assert( scomSendToCapture != NULL); UTL_assert( scomSendToDisplay != NULL); memset(ybuff, 0x00, PROCF_SIZE_IN_PIXELS); memset(ubuff, 0x80, PROCF_SIZE_IN_PIXELS >> 2); memset(vbuff, 0x80, PROCF_SIZE_IN_PIXELS >> 2); memset(ybuffCap, 0x00, PROCF_SIZE_IN_PIXELS); memset(ubuffCap, 0x80, PROCF_SIZE_IN_PIXELS >> 2); memset(vbuffCap, 0x80, PROCF_SIZE_IN_PIXELS >> 2); memset(ybuffDis, 0x00, OPF_SIZE_IN_PIXELS); memset(ubuffDis, 0x80, OPF_SIZE_IN_PIXELS >> 2);


memset(vbuffDis, 0x80, OPF_SIZE_IN_PIXELS >> 2); SCOM_putMsg( scomSendToCapture, &thrProcess.scombufCap ); SCOM_putMsg( scomSendToDisplay, &thrProcess.scombufDisp ); // loop principal while (TRUE) { ScomProcToDisp *scombufDisp; ScomCapToProc *scombufCap; Int chanNum; Bool rc; checkMsg(); scombufCap = SCOM_getMsg(scomReceiveFromCapture, SYS_FOREVER); scombufDisp = SCOM_getMsg(scomReceiveFromDisplay, SYS_FOREVER); if (thrProcess.diffEnv‐>SetReference == TRUE) { CACHE_wbInvL2(scombufCap‐>bufYCRCB[Y], CAPF_SIZE_IN_PIXELS, CACHE_WAIT); CACHE_wbInvL2(scombufCap‐>bufYCRCB[CR], CAPF_SIZE_IN_PIXELS>>2, CACHE_WAIT); CACHE_wbInvL2(scombufCap‐>bufYCRCB[CB], CAPF_SIZE_IN_PIXELS>>2, CACHE_WAIT); prevYId = DAT_copy2d(DAT_2D1D, (Void *) scombufCap‐>bufYCRCB[Y], (Void *) prevY, PROCF_WIDTH, PROCF_HEIGHT, PROCF_WIDTH); prevUId = DAT_copy2d(DAT_2D1D, (Void *) scombufCap‐>bufYCRCB[CR], (Void *) prevU, PROCF_WIDTH>>1, PROCF_HEIGHT>>1, PROCF_WIDTH>>1); prevVId = DAT_copy2d(DAT_2D1D, (Void *) scombufCap‐>bufYCRCB[CB], (Void *) prevV, PROCF_WIDTH>>1, PROCF_HEIGHT>>1, PROCF_WIDTH>>1);

CACHE_invL2(prevY, CAPF_SIZE_IN_PIXELS, CACHE_WAIT); CACHE_invL2(prevU, CAPF_SIZE_IN_PIXELS>>2, CACHE_WAIT); CACHE_invL2(prevV, CAPF_SIZE_IN_PIXELS>>2, CACHE_WAIT);

thrProcess.diffEnv‐>SetReference = FALSE; } DAT_wait(prevYId); DAT_wait(prevUId); DAT_wait(prevVId); for (chanNum = 0; chanNum < NUMPASSCHANS; chanNum++) { DAT_copy2d(DAT_1D2D, scombufCap‐>bufYUV[Y],scombufDisp‐>bufYCRCB[Y],PROCF_WIDTH, PROCF_HEIGHT, OPF_WIDTH);


83

DAT_copy2d(DAT_1D2D, scombufCap‐>bufYCRCB[CR],scombufDisp‐>bufYCRCB[CR],PROCF_WIDTH >> 1, PROCF_HEIGHT >> 1, OPF_WIDTH >> 1); prevVId = DAT_copy2d(DAT_1D2D, scombufCap‐>bufYCRCB[CB],scombufDisp‐>bufYCRCB[CB],PROCF_WIDTH >> 1, PROCF_HEIGHT >> 1, OPF_WIDTH >> 1); DAT_wait(prevVId); } for (chanNum = 0; chanNum < NUMEDGECHANS; chanNum++) { chan = &(thrProcess.edgeChans[chanNum]); ICC_setBuf(chan‐>cellSet[CHEDGECELLEDGE].inputIcc[0], scombufCap‐>bufYUV, 0); thrProcess.OutputBuff.y = scombufDisp‐>bufYCRCB[Y] + Q2_Y_OFFSET; thrProcess.OutputBuff.u = scombufDisp‐>bufYUV[CR] + Q2_CR_OFFSET; thrProcess.OutputBuff.v = scombufDisp‐>bufYUV[CB] + Q2_CB_OFFSET; thrProcess.edgeEnv[0].linePitch = OPF_WIDTH; ICC_setBuf(chan‐>cellSet[CHEDGECELLEDGE].outputIcc[0], &thrProcess.OutputBuff, 0); UTL_stsStart( stsExeTimeChEdge ); rc = CHAN_execute( &thrProcess.edgeChans[ chanNum ], NULL ); UTL_assert( rc == TRUE ); UTL_stsStop( stsExeTimeChEdge ); }

“Diseño de una Estructura de Trabajo (RF) para el ...aplicaciones y finalmente probar su...

Documents

Transcript of “Diseño de una Estructura de Trabajo (RF) para el ...aplicaciones y finalmente probar su...