GP2X: una herramienta para el desarrollo de sistemas embebidos

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR Ingeniería de la Computación GP2X: una herramienta para el desarrollo de sistemas embebidos Por Carlos Zager Fernández Tutor Académico Alberto Armengol Tutor Industrial Ricardo Strusberg INFORME FINAL DE CURSOS EN COOPERACIÓN Presentado ante la Ilustre Universidad Simón Bolívar como Requisito Parcial para Optar el Título de Ingeniero en Computación Sartenejas, Octubre de 2007

2

3 GP2X: una herramienta para el desarrollo de sistemas embebidos Por Carlos Zager Fernández Resumen El presente informe documenta el proceso y los resultados de la investigación y producción de un prototipo de sistema embebido creado con el sistema de entretenimiento personal GP2X. Para el diseño del prototipo se hizo uso de la metodología incremental en conjunto con la metodología de prototipado. Se investigó sobre las posibilidades, tanto en hardware como en software, del equipo y se hicieron diversas pruebas con el desarrollo de juegos y aplicaciones relativamente simples. El prototipo creado y los resultados obtenidos durante la investigación y desarrollo del mismo, demuestran la capacidad del equipo para ser usado como una herramienta útil para el desarrollo de este tipo de sistemas. I

4 Índice General Resumen......I Índice General......II Índice de tablas......iv Índice de figuras......v Glosario de términos y acrónimos......vi Introducción Capítulo 1.Planteamiento del problema Hipótesis Objetivos Capítulo 2.Entorno empresarial Descripción de la empresa Misión de la empresa Visión de la empresa Ubicación del pasante...7 Capítulo 3.GP2X Descripción Especificaciones técnicas Aplicaciones oficiales Software no oficial Accesorios Capítulo 4.Marco Teórico Fundamentos conceptuales Metodología de desarrollo iterativo o incremental Beneficios del desarrollo iterativo Metodología de desarrollo por prototipado Tipos de prototipos de sistemas de información Ventajas del uso de prototipos Desventajas Aplicaciones candidatas para ser desarrolladas con prototipos Proceso de elaboración de prototipos Sistemas embebidos Aplicaciones de un sistema embebido Ventajas de un sistema embebido sobre las soluciones industriales tradicionales..22 II

5 Capítulo 5.Marco metodológico Metodología del proyecto Capítulo 6.Fase de pruebas Materiales y equipos utilizados Algunas pruebas de uso sobre el software Reproductores de sonido Ambientes gráficos Pruebas de uso sobre el hardware Pruebas de desempeño Entrada/Salida hdparm tiotest Procesamiento y renderizado gráfico Otros dispositivos Capítulo 7.Desarrollo de juegos Qué clase de juegos pueden desarrollarse para el GP2X?...41 Capítulo 8.GP2X y sistemas embebidos Posibles sistemas embebidos eticket2x Diseño del sistema Aplicación de pago centralizado Aplicación del estacionamiento Conclusiones y recomendaciones Referencias bibliográficas Apéndices III

6 Índice de tablas Tabla 1: Información técnica del GP2X Tabla 2: Información técnica del Cradle GP2X Tabla 3: Tabla comparativa entre reproductores de sonido Tabla 4: Tabla comparativa entre ambientes gráficos Tabla 5: Resultados de prueba del hardware Tabla 6: Formato de los resultados de la prueba de procesamiento y renderizado gráfico...32 Tabla 7: Comparaciones entre dispositivos embebidos Tabla 8: Comparación entre ambientes de desarrollo Tabla 9: Descripción de la tabla TICKET de la base datos usada por la aplicación de pago centralizado de eticket2x Tabla 10: Descripción de la tabla TICKET_LOST de la base datos usada por la aplicación de pago centralizado de eticket2x Tabla 11: Descripción de la tabla TICKET de la base datos usada por la aplicación del estacionamiento de eticket2x IV

7 Índice de figuras Figura 1 : Vista frontal del GP2X Modelo F Figura 2: Vista frontal del GP2X Modelo F Figura 3: Cradle GP2X Figura 4: DFD del proceso de elaboración de prototipos Figura 5: Resultado del comando hdparm tt en GP2X...30 Figura 6: Resultado del comando hdparm tt en Pentium Figura 7: Resultado del comando tiotest en GP2X Figura 8: Resultado del comando tiotest en Pentium Figura 9: Resultados de procesamiento y renderizado gráfico en lenguaje Fenix en el GP2X...33 Figura 10: Resultados de procesamiento y renderizado gráfico en lenguaje python en el GP2X...33 Figura 11: Resultados de procesamiento y renderizado gráfico en lenguaje Fenix en el Pentium Figura 12: Resultados de procesamiento y renderizado gráfico en lenguaje python en el Pentium Figura 13: Toma de pantalla del juego Tank de Atari Inc Figura 14: Esquema MVC de las aplicaciones de eticket2x...46 Figura 15: Interfaz gráfica de pago centralizado eticket2x Figura 16: Ejemplo de ticket de salida del sistema eticket2x...49 Figura 17: Ejemplo de ticket de entrada del sistema eticket2x...53 V

8 Glosario de términos y acrónimos CPU DFD Central Processing Unit Diagrama de flujo de datos Es el componente en una computadora digital que interpreta las instrucciones y procesa los datos contenidos en los programas de computadora Representa la forma más tradicional para especificar los detalles algorítmicos de un proceso. GPH Gamepark Holdings Empresa sur coreana creadora de la GP2X LCD Liquid Crystal Display Se trata de un sistema eléctrico de presentación de datos formado por 2 capas conductoras transparentes y en medio un material especial cristalino (cristal líquido) que tienen la capacidad de orientar la luz a su paso. PDA Personal Digital Assistant Es un computador de mano originalmente diseñado como agenda electrónica(calendario, lista de contactos, bloc de notas y recordatorios) con un sistema de reconocimiento de escritura. PSP Playstation Portable Es una videoconsola portátil de la compañía japonesa Sony Computer Entertainment RAM Random Access Memory Se trata de una memoria de semiconductor en la que se puede tanto leer como escribir información. Se utiliza normalmente como memoria temporal para almacenar resultados intermedios y datos similares no permanentes SD Secure Digital Es un formato de tarjeta de memoria flash que se utiliza comúnmente en dispositivos portátiles TFT Thin Film Transistor Es un tipo especial de transistor de efecto campo que se construye depositando finas películas sobre contactos metálicos, donde cada capa activa cada píxel, obteniéndose mejores tiempos de respuesta, al no ser necesario el barrido VI

9 Introducción Hoy en día la tecnología es indispensable en nuestras vidas. La aparición hace pocos años de los celulares o las PDA cambió nuestra manera de comportarnos. Cada vez son más los equipos que tienen un tamaño tan reducido como para caber en la palma de la mano, y sin embargo poseen una variada cantidad de funcionalidades. La aparición de este tipo de equipos ha revolucionado el mercado electrónico, existiendo hoy un dispositivo para casi cualquier cosa que se nos pueda ocurrir, desde aquellos que nos permiten almacenar y reproducir música y videos, decirnos nuestra ubicación geográfica, organizar nuestras vidas a través de calendarios y agendas, hasta aquellos que incluso nos permiten medir nuestro estado de salud en cualquier momento sin asistencia médica. Pero así como existen dispositivos para todo, también podemos encontrarnos que como era de esperar en un mercado que se encuentra en plena evolución, los precios fluctúan y tienden a ser bastante elevados, debido a que es el último grito tecnológico. La empresa Corvus Latinoamérica se ha planteado la tarea de buscar una alternativa económica pero totalmente funcional, para el desarrollo de este tipo de sistemas embebidos, con el objetivo de entrar en este mercado con un producto que esté basado en herramientas libres. Con este fin han decidido evaluar el dispositivo GP2X, para demostrar que éste es más que un simple sistema de entretenimiento. 1

10 Capítulo 1. Planteamiento del problema En la actualidad existe gran cantidad de dispositivos electrónicos que son controlados o configurados a través de equipos externos. A estos últimos se les suele llamar interfaces o aplicaciones. Por lo general, estos equipos suelen ser desarrollados específicamente para este fin o son equipos ya existentes que fueron adaptados para suplir esta necesidad. En muchos casos estos equipos son PDA o Laptops, que suelen ser buenos para la tarea, pero la mayor parte de las veces son demasiado costosos como para ser usados sólo con esta finalidad. En Corvus Latinoamérica se han propuesto la tarea de buscar alternativas a este problema, que cumplan con las exigencias y requerimientos de sus clientes, pero a la vez tengan también un precio más económico, haciendo uso de herramientas de software libre, de manera que puedan surgir en un mercado que cada vez se hace más y más competitivo. Con este fin han decidido probar un dispositivo de entretenimiento creado por la empresa sur coreana Gamepark Holdings (GPH), llamado GP2X, como posible herramienta para el desarrollo de sistemas embebidos. Con éste vamos a realizar nuestras pruebas, comparaciones y vamos a crear un prototipo de aplicación. Para ello nos hemos planteado la siguiente hipótesis y con ella un conjunto de objetivos. 2

11 1.1 Hipótesis Dadas las características del GP2X ( portabilidad, alto rendimiento y facilidad para el desarrollo de nuevas aplicaciones ) podemos demostrar que es posible la creación de aplicaciones de bajo costo y alto rendimiento, que suplan las necesidades y requerimientos de nuestros clientes, pudiendo así competir con aquellos dispositivos que ya pueden ser encontrados en el mercado. 1.2 Objetivos Recopilar y generar información sobre el GP2X. Uso del dispositivo. Aplicaciones actuales y futuras. Pruebas de funcionalidad y capacidad. Comparar el dispositivo con otras alternativas en el mercado. Observar virtudes y desventajas en comparación con estos. Seleccionar un ambiente de desarrollo adecuado. Investigar los posibles ambientes de desarrollo para el dispositivo y seleccionar la opción más adecuada. Demostrar que el GP2X no sólo es una consola de entretenimiento. 3

12 Seleccionar una posible aplicación (usos y programas) y crear un prototipo de la misma. Analizar que tipo de aplicación podría desarrollarse y escoger una de ellas según sea la preferencia. Diseñar y codificar un prototipo de la aplicación seleccionada. 4

13 Capítulo 2. Entorno empresarial Este capítulo expone una breve descripción de la empresa donde se realizó el trabajo de pasantía, así como también el ambiente de trabajo en el que se encontraba el pasante. 2.1 Descripción de la empresa Corvus Latinoamérica C.A., inició sus pasos en el mercado a partir del año 89 en el área de informática, iniciándose como empresa de tecnología, diseñando e implementando la organización en redes de comunicación (LAN, WAN) e integrando Software y Hardware como soluciones a las Empresas. Es a partir del año 94 donde Corvus Latinoamérica C.A., incorporó en sus soluciones, servicios del área de desarrollo en plataformas de código abierto (Sistema Operativo Linux). Corvus Latinoamérica, actualmente brinda los servicios de desarrollo en Código Abierto con el sistema operativo Linux, consultorías en el área de Seguridad de Datos e integración de servicios con otras plataformas. Corvus Latinoamérica, como empresa de servicios de consultoría y ejecución de proyectos informáticos, tiene como objetivo ser el respaldo a sus clientes en la aplicación de tecnología informática de punta, que les permitirá optimizar sus recursos operativos y financieros, para convertirse en una organización competitiva dentro de un entorno globalizado. 5

14 Corvus Latinoamérica se ha convertido en un integrador de plataformas híbridas (Windows Linux) para dar respuestas a las necesidades de las empresas en proceso de migración o en planes de migración. Así mismo, a la vanguardia de las prioridades de las compañías, Corvus Latinoamérica ha fortalecido la Unidad de Seguridad de Datos y de Información, una de las áreas más vulnerables dentro de una organización, por medio del apoyo de especialistas de distintos países que dispone la empresa, los cuales ejecutan bajo el más estricto convenio de confidencialidad los procesos de pruebas requeridos por nuestros clientes. Corvus Latinoamérica brinda a sus clientes : Amplia trayectoria en soporte local y regional. Conoce el mercado del Código Abierto. Experiencia en proyectos de consultoría, implantación y soporte en estándares abiertos en el país y fuera de él. Crear y desarrollar soluciones basándose en las necesidades y requerimientos de los clientes, con empleo de tecnología de punta y un trabajo especializado en plataformas abiertas. Personal especializado y calificados en programación avanzada en las principales herramientas del mercado (tecnologías y software libre), proyectos y base de datos relacionales y lógicas. 6

15 2.1.1 Misión de la empresa Ejecutar proyectos informáticos en áreas de gestión crítica bajo sistemas abiertos (Integración de plataformas hibrídas) y el mantenimiento de la Seguridad de Datos e Información en la empresa o institución de forma inviolable Visión de la empresa Ser una empresa líder en proyectos de plataformas abiertas en Latinoamérica contando con un equipo de profesionales especializados que brinda soluciones a la medida de sus clientes, empresas y a la comunidad. 2.2 Ubicación del pasante El trabajo de pasantía documentado en el presente informe corresponde a un proyecto interno de la empresa Corvus Latinoamérica, en donde estuvo ubicado el pasante. Este se encontraba en un ambiente de trabajo conjunto, conformado por un equipo de personal capacitado en distintas áreas de informática y tecnología, en el cual debía participar activamente estando presente en reuniones de trabajo, donde debía aportar sus ideas para la toma de decisiones en los proyectos que tenía en el momento la empresa. Aparte de esto tenía como labor el levantamiento de información, diseño, desarrollo y configuración, para lo cual estuvo supervisado por un Tutor Industrial y un Tutor Académico. 7

16 Capítulo 3. GP2X Este capítulo presenta una breve descripción del GP2X, sus características y especificaciones técnicas. 3.1 Descripción El GP2X es un sistema de entretenimiento portátil, creado por la empresa sur coreana Gamepark Holdings. El mismo utiliza GNU/Linux como sistema operativo nativo, con un kernel , compilado específicamente para la arquitectura del equipo. Figura 1 : Vista frontal del GP2X Modelo F-100 Figura 2: Vista frontal del GP2X Modelo F-200 Entre las características principales del mismo se tiene: Su desarrollo se está haciendo de forma abierta, de manera que cualquiera que así lo desee pueda desarrollar tanto software como hardware extra para el equipo. Esto ha atraído a mucha gente de la comunidad de software libre a crear proyectos hechos en casa. [Archive, 2007] 8

17 Reproducción de música y videos. Visualización de imágenes y libros. Reproducción de juegos nativos o emulados. Capacidad de enviar la señal de video a un televisor. Capacidad de actualizar el firmware. En el modelo nuevo GP2X F 200 se tiene una pantalla táctil. 3.2 Especificaciones técnicas Hay que hacer la acotación que ya terminando el plazo de la pasantía salió al mercado el nuevo modelo GP2X F 200 1, este se está poniendo sólo como una referencia. Durante todo el desarrollo del presente informe cada vez que se hable de GP2X nos vamos a a estar refiriendo al modelo GP2X F100. A continuación, en la siguiente tabla, podemos encontrar la descripción técnica del equipo. 2 1 Para mayor información ver 2 Para mayor información consultar [Guyfawkes, 2007] 9

18 Nombre del producto GP2X F100 CPU Doble núcleo: ARM920T Procesador principal ARM940T : Coprocesador de Video Datos Generales Memoria Flash Nand Dimensiones Peso RAM Almacenamiento USB Sistema Operativo Baterías Pantalla Resolución 64 Mega Bytes 143.6mm 82.9mm 34mm 161g (sin las baterías) SDRAM 64 Mega Bytes Tarjeta Secure Digital (SD) Puerto USB 2.0 Alta Velocidad GNU/Linux 2AA 3.5 TFT LCD (hardware 16,7 Millones de colores/software 260,000colores) 320 X 240 (QVGA) Puerto de Entrada / Salida Audífonos Puerto USB 2.0 (5pin Mini) Puerto de extensión EXT Adaptador de corriente 3V 1A Puerto SDIO Compresión de video MPEG4 (Xvid, DivX) Formato Compresión de audio avi mp3, ogg Video Resolución Max 720x Fps Bit Rate Max Video: 2500 Kbps Max Audio: 384Kbps Subtítulos TV OUT SMI Movie/Game Screen Audio anales Frecuency Rate Formato Bit Rate Sampling Ecualización Estereo 20Hz~20KHz wma, mp3, ogg 16bit/8~48KHz Normal, Jazz, Rock, Clásica, Dance, Heavy Metal, Disco, Soft, Live 3D, Hall, Pop Control Visor de Imágenes Joystick digital de 8 direcciones Botón principal A, B, X, Y Botón Start, Select Botón L, R Botón Volumen +/ Formato JPEG, BMP, PCX, GIF, PNG Visor de Libros Formato TXT (ASCII) Vida útil de baterías Video Audio Aprox. 4 horas (estándar por pruebas de la GPH) Aprox. 6 horas (estándar por pruebas de la GPH) Tabla 1: Información técnica del GP2X 10

19 3.3 Aplicaciones oficiales El GP2X viene incorporado con un conjunto de aplicaciones oficiales 3, que permiten realizar el conjunto de actividades básicas del mismo, esto es reproducir música y videos, visualizar imágenes y libros, reproducir juegos emulados o nativos. 3.4 Software no oficial Aparte de esto se puede encontrar gran variedad de aplicaciones no oficiales 4 que han sido desarrolladas por gente de la comunidad y que pueden ser muy útiles, ampliando así las capacidades del equipo. 3.5 Accesorios El GP2X se aprovecha del uso del puerto EXT para poder incorporar accesorios al mismo. Por ejemplo podemos encontrar un dispositivo creado por la compañía GPH, que ellos llamaron Cradle (ver Figura 3). Las características de este son: 3 Para mayor información ver las aplicaciones oficiales en el apéndice A 4 Para mayor información de algunas aplicaciones no oficiales ver el apéndice A 11

20 Datos generales Nombre del producto Cradle GP2X Dimensiones Peso Voltaje 150mm 140mm 62mm 185g 5V 3A Puerto Entrada/Salida USB 4 Puertos USB 2.0 Alta velocidad Audio Video Interfaz de desarrollo Audio RCA (izquierda, derecha) Súper video (SVHS) Puerto serial Puerto Paralelo 24 pines (JTAG) Tabla 2: Información técnica del Cradle GP2X Figura 3: Cradle GP2X Como se puede apreciar en la figura el Cradle contiene 4 puertos USB que se incorporan al GP2X, por lo que este se vuelve muy versátil permitiendo así conectar prácticamente cualquier dispositivo USB. Por ejemplo: mouse, teclado, discos duros externos, pendrives, adaptadores Bluetooth o Wi fi, joystick o cámara Web, entre otros. 12

21 Aparte de esto existen iniciativas de la gente de la comunidad y de algunas empresas comerciales, de crear hardware de terceros para el equipo. Una referencia interesante a esto podría ser: Incorporarle al GP2X un sistema de GPS. [Sprites, 2007] Mini Cradle. 5 5 Ver 13

22 Capítulo 4. Marco Teórico Este capítulo presenta las bases teóricas que fundamentan el desarrollo del proyecto. 4.1 Fundamentos conceptuales Metodología de desarrollo iterativo o incremental El proceso iterativo es aquel en el que el desarrollo se organiza en una serie de miniproyectos cortos, de duración fija llamados iteraciones; el resultado de cada uno es un sistema que puede ser probado, integrado y ejecutado. Cada iteración incluye sus propias actividades de análisis de requisitos, diseño, implementación y pruebas. El ciclo de vida iterativo se basa en la ampliación y refinamiento sucesivos del sistema mediante múltiples iteraciones, con retroalimentación cíclica y adaptación como elementos principales que dirigen para converger hacia un sistema adecuado. El sistema crece incrementalmente a lo largo del tiempo, iteración tras iteración, y por ello, este enfoque también se conoce como desarrollo iterativo e incremental. 4.2 Beneficios del desarrollo iterativo Aplacar tan pronto como sea posible riesgos altos. Progreso visible en las primeras etapas. Una temprana retroalimentación, compromiso de los usuarios y adaptación, que nos lleva a 14

23 un sistema refinado que se ajusta más a las necesidades reales del personal involucrado. Gestión de la complejidad; el equipo no se ve abrumado por la parálisis del análisis o pasos muy largos y complejos. El conocimiento adquirido en una iteración se puede utilizar metódicamente para mejorar el propio proceso de desarrollo, iteración a iteración. [Larman, 2003] 4.3 Metodología de desarrollo por prototipado El diseño de prototipos es una popular técnica de ingeniería utilizada para desarrollar modelos a escala de un producto o de sus componentes. Cuando se aplica al desarrollo de sistemas de información, el diseño de prototipos implica la creación de un modelo o modelos iterativos de trabajo de un sistema o subsistema. [Whitten, 1996] La elaboración de prototipos consiste en el desarrollo de un sistema no funcional rápido y barato para que los usuarios finales lo evalúen. Al interactuar con el prototipo, los usuarios pueden tener una mejor idea de sus requerimientos de información. El prototipo avalado por los usuarios puede ser usado como marco de referencia para crear el sistema definitivo. El prototipo es una versión operativa de un sistema de información o parte del sistema, pero se trata sólo de un modelo preliminar. Una vez que opera, el prototipo será luego mejorado hasta que se apegue exactamente a los requerimientos de los usuarios. Para muchas aplicaciones, un prototipo puede ser extendido y mejorado una y otra vez antes de aceptar el diseño final. Una 15

24 vez que el diseño ha terminado, el prototipo puede convertirse en un sistema pulido de información. En la Figura 7 puede observarse un diagrama de flujo que explica el proceso. El proceso de desarrollo de un diseño preliminar, de probarlo, afinarlo y probarlo de nuevo se ha denominado proceso iterativo de desarrollo de sistemas, por que los pasos necesarios al desarrollar el sistema pueden repetirse una y otra vez. Cada una de las versiones va reflejando con mayor precisión los requerimientos de los usuarios. En vez de generar especificaciones detalladas y documentos de autorizaciones, el prototipo genera rápidamente un modelo operativo del sistema. Los requerimientos se determinan dinámicamente a medida que el prototipo se construye. El análisis del sistema, el diseño y la implantación ocurren al mismo tiempo. [Laudon, 1996] Tipos de prototipos de sistemas de información Los prototipos de viabilidad se utilizan para probar la viabilidad de una tecnología específica aplicable a un sistema de información. Sobre la base de los resultados del prototipo, puede adoptarse una decisión sobre si se sigue adelante o no con el desarrollo de la solución técnica. Los prototipos de necesidades (a veces denominados prototipos de descubrimiento) se utilizan para descubrir las necesidades de los usuarios con respecto a la empresa. Pretenden simular la forma de pensar de los usuarios. 16

25 Los prototipos de diseño (también llamados prototipos de comportamiento) se utilizan para simular el diseño del sistema de información final. Mientras que los prototipos de necesidades se centraban sólo en contenido, los prototipos de diseño lo hacen en la forma y el funcionamiento del sistema deseado. Los prototipos de implantación (a veces llamados prototipos de producción) constituyen una extensión de los prototipos de diseño donde el prototipo evoluciona directamente hacia el sistema de producción Ventajas del uso de prototipos Los usuarios se hacen participantes más activos en el desarrollo de sistemas. Suelen mostrarse más interesados en los prototipos de trabajo que en las especificaciones de diseño en papel. La definición de necesidades se simplifica por el hecho de que muchos usuarios finales no comprenden o no son capaces de enunciar detalladamente sus necesidades hasta que ven un prototipo. La probabilidad de que los usuarios finales aprueben un diseño y luego rechacen su implantación se reducirá notablemente. Los prototipos se crean con rapidez y tienen un costos bajo de desarrollo. 17

26 Desventajas Los prototipos suelen pasar a las fases de análisis y diseño con demasiada rapidez. Ello empuja al analista a pasar demasiado rápido a la codificación, sin haber comprendido bien las necesidades y los problemas. Los prototipos pueden desalentar la consideración de soluciones técnicas alternativas. El analista suele seguir adelante con el primer prototipo alternativo que suscita una reacción razonablemente favorable en los usuarios. Los sistemas implantados desde prototipos son con frecuencia poco flexibles para adaptarse a los cambios en las necesidades, ya que han sido desarrollados por encima. No siempre es fácil cambiar los prototipos. Los prototipos rara vez se pulen Aplicaciones candidatas para ser desarrolladas con prototipos Los prototipos son más eficaces en el desarrollo de sistemas de información cuando se cumplen ciertas condiciones. Cualquiera de las siguientes cinco condiciones sugieren la necesidad de utilizar un prototipo: No se conocen los requerimientos: La naturaleza de la aplicación es tal que existe poca información disponible con respecto a las características que debe tener el sistema para satisfacer los requerimientos de los usuarios 18

27 Los requerimientos necesitan evaluarse: Se conocen los requerimientos aparentes de información, tanto de los usuarios finales como de la organización, pero es necesario evaluarlos y verificarlos Costos altos: La inversión de recursos financieros y humanos así como el tiempo necesario para generar la aplicación es sustancial. Existen otros proyectos que también compiten por los mismos recursos. Alto riesgo: La evaluación inexacta de los requerimientos del sistema y el desarrollo incorrecto de una aplicación ponen en peligro a la organización, a sus empleados y también a sus propios recursos. Nueva tecnología: el deseo de instalar nueva tecnología ya sea en los campos de computación, de las comunicaciones de datos u otras áreas relacionadas, abre nuevas fronteras para la organización. Muchas compañías no tienen experiencia en el uso de cierta tecnología ni tampoco las demás organizaciones con las que se comunican. [Senn, 1992] 19

28 Proceso de elaboración de prototipos Identificar requerimientos básicos Etapa 1 Desarrollo de un prototipo operativo Etapa2 Uso del Prototipo Etapa 3 Si Usuario satisfecho? No Prototipo operativo Revisar y Mejorar el prototipo Etapa 4 Figura 4: DFD del proceso de elaboración de prototipos 4.4 Sistemas embebidos Un sistema integrado o embebido, es un sistema informático de uso específico construido dentro de un dispositivo mayor. Los sistemas integrados se utilizan para usos muy diferentes de los usos generales para los que se emplea un ordenador personal. En un sistema integrado la mayoría de los componentes se encuentran incluidos en la placa base. Dos de las diferencias principales son el precio y el consumo. Puesto que los sistemas integrados se pueden fabricar por decenas de millares o por millones de unidades, una de las 20

29 principales preocupaciones es reducir los costos. Los sistemas integrados suelen usar un procesador relativamente pequeño y una memoria pequeña para reducir los costes. Se enfrentan, sobre todo, al problema de que un fallo en un elemento implica la necesidad de reparar la placa en su totalidad. [Sistemas, 2007] Aplicaciones de un sistema embebido Los lugares donde se pueden encontrar los sistemas embebidos son numerosos y de variada naturaleza. A continuación se exponen varios ejemplos para ilustrar las posibilidades de los mismos: En una fábrica, para controlar un proceso de montaje o producción. Puntos de servicio o venta. Puntos de información al ciudadano. Decodificadores para la recepción de televisión. Sistemas radar de aviones. Equipos de medicina en hospitales y ambulancias. Máquinas de revelado automático de fotos. Cajeros automáticos. Y un sin fin de posibilidades aún por descubrir o en estado embrionario como son las neveras inteligentes que controlen su suministro vía Internet, PCs de bolsillo, etc. 21

30 Ventajas de un sistema embebido sobre las soluciones industriales tradicionales Los equipos industriales de medida y control tradicionales están basados en un microprocesador con un sistema operativo propietario o específico para la aplicación correspondiente. Dicha aplicación se programa en ensamblador para el microprocesador dado o en lenguaje C. Con los modernos sistemas PC embebidos basados en microprocesadores i486 o i586 se llega a integrar el mundo del PC compatible con las aplicaciones industriales. Ello implica numerosas ventajas: Posibilidad de utilización de sistemas operativos potentes que ya realizan numerosas tareas: comunicaciones por redes de datos, soporte gráfico, concurrencia con lanzamiento de hilos, etc. Estos sistemas operativos pueden ser los mismos que para PCs compatibles, con fuertes exigencias en hardware o bien ser una versión reducida de los mismos con características orientadas a los PCs embebidos. Al utilizar dichos sistemas operativos se pueden encontrar fácilmente herramientas de desarrollo software potentes así como numerosos programadores que las dominan, dada la extensión mundial de las aplicaciones para PCs compatibles. Reducción en el precio de los componentes hardware y software debido a la gran cantidad de PCs en el mundo. [Sistemas, 2007] 22

31 Capítulo 5. Marco metodológico El presente capítulo tiene como finalidad dar a conocer la metodología utilizada para el desarrollo del presente proyecto y de los prototipos producidos en el mismo. 5.1 Metodología del proyecto El proyecto se dividió en varias etapas: Investigación Recopilación de información referente a sistemas embebidos, GP2X y ambientes de desarrollo para el mismo, comparación con otros dispositivos. Investigación de juegos en 2D. Fase de pruebas Aprovechar la experiencia ganada en la etapa anterior para realizar un conjunto de pruebas que demostrasen la capacidad del GP2X y de los ambientes de desarrollo seleccionados. Probar las distintas aplicaciones que corren actualmente en el GP2X. Análisis y levantamiento de requerimientos Dados los resultados de las pruebas escoger un sistema que fuese el más adecuado para el desarrollo de las aplicaciones. 23

32 Analizar cuales posibles aplicaciones podrían ser desarrolladas y escoger una de ellas para realizar una prueba de concepto. Realizar el levantamiento de requerimientos para el desarrollo de la aplicación seleccionada. Analizar y escoger un juego en 2D que probase la funcionalidad del ambiente de desarrollo y mostrasen la capacidad del GP2X. Diseño y codificación Diseñar y codificar un prototipo de la aplicación seleccionada. Diseñar y codificar un prototipo del juego seleccionado. Evaluación de los prototipos Evaluar los prototipos desarrollados para comprobar su funcionalidad. Realizar un análisis de riesgo para decidir si vale la pena desarrollar el producto de aplicación final. Por otro lado la metodología usada para el desarrollo de los prototipos de aplicación en el proyecto, fue una unión entre el modelo de desarrollo incremental en conjunto con el modelo de desarrollo por prototipado; gracias a que por sus características aportaban al proyecto gran dinamismo en cuanto a velocidad y obtención de un producto temprano. 24

33 Capítulo 6. Fase de pruebas Este capítulo presenta un conjunto de pruebas realizadas sobre software y hardware en el equipo, así como también los materiales y equipos utilizados durante las mismas. Las pruebas fueron escogidas para ver la funcionalidad actual de algunas de las aplicaciones que actualmente se pueden encontrar para el GP2X, así como también para probar el desempeño de este pensando en aplicaciones futuras. 6.1 Materiales y equipos utilizados Mouse USB : Lenovo, Modelo MO28UOL Teclado USB : Lenovo, Modelo SK 8825 (L) Unidad DVD USB: ADS Technologies Dual Link Drive Kit, Modelo LL5 DLX 185 Pendrive: Smart G2 Dell Memory Key 256MB, Modelo SM9FLAMK Joysticks: Genius, Modelo G 08XU y Genius MaxFire 12 U vibration Cámara Web USB: iconcepts Mini Web Cam Adaptador Wi fi: Belkin Wireless G USB Network Adapter, Modelo F5D7050 Adaptador Bluetooth: Belkin Bluetooth USB Adapter, Modelo F8T003 ver 2.11 Laser scanner: Birch, Modelo Pilas recargables : 4 Energizer 2500mAh AA 25

34 Memoria SD: SD Trascend 4GB Cradle: Accesorio oficial de la GPH Cable EXT a S video y RCA: Accesorio oficial de la GPH Cable Paralelo a Paralelo Cable Svideo Svideo, RCA a RCA Cable USB a serial Cable USB a PS2 6.2 Algunas pruebas de uso sobre el software En el caso del software se escogió realizar las pruebas sobre los reproductores de sonido, usando varios archivos en común para probar que las aplicaciones fuesen capaces al menos de reproducir los mismo archivos. Por otro lado se escogió probar los entornos de ambientes gráficos ya que estas son las aplicaciones que más uso tienen en el GP2X, a través de ellas se controla el dispositivo. Para la clasificación de la interfaz gráfica se utilizo la siguiente métrica Nada amigable Poco amigable Amigable Muy amigable Difícil desplazamiento Confunde al usuario Difícil de usar Facil de usar Poco atractivo Totalmente intuitivo Bastante atractivo 26

35 6.2.1 Reproductores de sonido Para la realización de las pruebas de sonido, se generó un tono en la aplicación Audacity 6, siguiendo los siguientes parámetros: Tono 300 Hz Amplitud: 1 Mono Efecto: Fade in Efecto: Phaser (stages: 4, LFO Freq: 1.3 Hz, LFO start Phase: 270º, Depth: 225,Feedback: 50) Efecto: Una Repetición Efecto: Reverse Posteriormente fue grabado en los formatos mp3, ogg y wav. A continuación se muestra los resultados de probar este conjunto de archivos en los diferentes reproductores así como también una evaluación cualitativa de los mismos dada por su usabilidad y atractivo en la interfaz. 6 Para mayor información ver 27

36 Variable/Aplicación MusicPlayer (oficial) OLDPLAY GMU CraigAmp3 ommpc2x Estado Funcional Funcional Funcional Funcional Funcional Reproduce MP3 Reproduce OGG Reproduce WAV Listas de reproducción Diseño de interfaz Amigable Amigable Amigable Muy amigable Amigable Tabla 3: Tabla comparativa entre reproductores de sonido Ambientes gráficos A continuación se muestra los resultados de comprobar los distintos entornos de ambientes gráficos que existen para el GP2X. Variable/Aplicación gp2xmenu (oficial) gmenu2x gp2xmb StylishMenu sycophant xynth Estado Funcional Funcional Funcional Desarrollo Funcional Desarroll o Diseño de interfaz Tipo de Desplazamiento Sonidos en menú Muy amigable Muy amigable Muy amigable Poco Amigable Poco Amigable Nada amigable Menú Menú Menú Menú Menú Puntero Uso de enlaces rápidos Tabla 4: Tabla comparativa entre ambientes gráficos 28

37 6.3 Pruebas de uso sobre el hardware Las pruebas realizadas sobre el hardware fueron realizadas con dispositivos USB conectados a través del Cradle. Hardware/Variables Funcionó Teclado Mouse Pendrive Unidad DVD externa 7 Joysticks Cámara web Adaptador Wi Fi 8 Adaptador Bluetooth Cable serial Cable ps2 Tabla 5: Resultados de prueba del hardware 6.4 Pruebas de desempeño A continuación se muestra un conjunto de pruebas realizadas para medir la capacidad de escritura y lectura del hardware del GP2X, así como también la capacidad de computo y renderizado gráfico del mismo, con el fin de dar un patrón de comparación al momento de decidir que tipo de aplicaciones se pueden desarrollar. 7 Fallo por falta de soporte en el kernel. Este no tenía los drivers necesarios 8 Fallo por falta de soporte en el kernel. Este no tenía los drivers necesarios 29

38 6.4.1 Entrada/Salida A continuación se muestra el resultado de dos pruebas de desempeño muy comunes en ambientes GNU/Linux, que se utilizan para medir el desempeño de los dispositivos entrada/salida. Los resultados son comparados con los de una computadora Intel Pentium GHz, 768 MB RAM y un disco duro Fujitsu MPA3026AT 2GB Ultra ATA/ RPM, para tener un punto de comparación de un ambiente con el que estamos más acostumbrados a trabajar hdparm El comando ejecutado en ambos ambientes fue #hdparm -tt /dev/$disco, donde $disco es la ruta del disco con que se realizó la prueba. Figura 5: Resultado del comando hdparm -tt en GP2X Figura 6: Resultado del comando hdparm -tt en Pentium 4 Como se puede observar el GP2X tiene un desempeño muy pobre (cerca de 4 veces menos) con respecto al de la computadora Pentium 4 y esto se debe a que en el caso de esta última ésta tiene un disco duro IDE, y el GP2X tiene una memoria flash que se sabe tiene una lectura/escritura mucho más lenta que la de un disco duro. 30

39 tiotest El comando ejecutado en ambos ambientes fue #tiotest, por lo que el mismo corrió con todos sus parámetros por defecto. Figura 7: Resultado del comando tiotest en GP2X Figura 8: Resultado del comando tiotest en Pentium 4 Este caso al igual que el anterior hace todavía mas evidente la seria diferencia en el rendimiento de un disco duro frente al de una memoria flash Procesamiento y renderizado gráfico A continuación se presenta los resultados de tiempo de corrida de un par de programas de 31

40 desempeño en el GP2X y en la computadora Pentium 4 mencionada anteriormente. Los programas 9 fueron escritos en lenguaje Python (haciendo uso de la librería pygame) y lenguaje Fenix; y en ambos se realiza el cálculo de 1000 puntos aleatorios dentro de un espacio de 320x240 pixeles y luego son renderizados en pantalla. Las mediciones del tiempo fueron realizadas usando la herramienta GNU time. En el caso del GP2X se usó una versión de time compilada para arquitecutra Arm que fue descargada de los repositorios de la distribución Debian. Los resultados están formateados de la siguiente manera: Tiempo %E Tiempo real transcurrido (en [horas:]minutos:segundos) %S Número total de segundos de CPU que el proceso consumió en modo de núcleo. %U Número total de segundos de CPU que el proceso consumió en modo de usuario. %P Porcentaje de CPU que recibió este trabajo, calculado como (%U + %S) / %E. Memoria %F Número de faltas de página principales, que ocurrieron mientras el proceso se ejecutaba. Estas son faltas en las que la página debe ser leída desde disco. %R Número de faltas de página menores o recuperables. Estas son faltas para páginas que no son válidas pero que no han sido reclamadas aún por otras páginas virtuales. De este modo, los datos en la página son todavía válidos, pero las tablas de sistema deben actualizarse. %W Número de veces que el proceso fue intercambiado hacia afuera de la memoria principal. %c Número de veces que el proceso fue intercambiado de contexto involuntariamente (porque finalizase la porción de tiempo). %w Número de esperas: veces que el programa fue intercambiado de contexto voluntariamente, por ejemplo, mientras se espera a que se complete una operación de E/S. Tabla 6: Formato de los resultados de la prueba de procesamiento y renderizado gráfico 9 Para mayor información ver el código fuente de los programas en el apéndice G 32

41 Tiempo Transcurrido 0:12.85 Tiempo Transcurrido 0:12.49 Modo kernel 2.80 seg Modo kernel 2.35 seg Modo usuario 3.95 seg Modo usuario 7.94 seg Porcentaje CPU 52% Porcentaje CPU 82% Memoria Falta de páginas principales 154 Faltas de páginas recuperables 318 Fuera de memoria principal 0 Intercambio de contexto involuntario 0 Intercambio de contexto voluntario 0 Memoria Falta de páginas principales 772 Faltas de páginas recuperables 872 Fuera de memoria principal 0 Intercambio de contexto involuntario 0 Intercambio de contexto voluntario 0 Figura 9: Resultados de procesamiento y renderizado gráfico en lenguaje Fenix en el GP2X Figura 10: Resultados de procesamiento y renderizado gráfico en lenguaje python en el GP2X Tiempo Transcurrido 0:11.28 Tiempo Transcurrido 0:04.51 Modo kernel 0.00 seg Modo kernel 0.04 seg Modo usuario 0.40 seg Modo usuario 0.11 seg Porcentaje CPU 3% Porcentaje CPU 3% Memoria Falta de páginas principales 4 Faltas de páginas recuperables 1247 Fuera de memoria principal 0 Intercambio de contexto involuntario 220 Intercambio de contexto voluntario 1704 Memoria Falta de páginas principales 32 Faltas de páginas recuperables 2307 Fuera de memoria principal 0 Intercambio de contexto involuntario 1376 Intercambio de contexto voluntario 1560 Figura 11: Resultados de procesamiento y renderizado gráfico en lenguaje Fenix en el Pentium 4 Figura 12: Resultados de procesamiento y renderizado gráfico en lenguaje python en el Pentium 4 Como puede ser observado de los resultados, en los cuales se compara el GP2X contra la 33

42 computadora Pentium 4 y a la vez Python contra Fenix. Se puede concluir que el rendimiento del GP2X frente a una computadora de escritorio es menor, pero esto se esperaba así ya que hay que recordar que el GP2X es un sistema embebido y se esta cambiando poder de computo por portabilidad y integración en otros ambientes. Por otro lado también se puede observar que el lenguaje Python tuvo un mejor desempeño en cuanto a tiempo de corrida pero decae frente al lenguage Fenix en cuanto a uso de recursos ya que requirió de mayor cantidad de memoria para su funcionamiento. De esta forma se puede observar que todo va a depender de la aplicación que queramos desarrollar y cual es nuestra métrica más importante, si una ejecución rápida o poco uso de recursos. 6.5 Otros dispositivos A continuación vamos a presentar una tabla comparativa con los dispositivos electrónicos que se encuentran actualmente en el mercado y que consideramos podrían ser una competencia directa con el GP2X. La misma fue creada a partir de la información técnica que pudimos encontrar de cada uno de los dispostivos, ya que no se poseía de un ejemplar para cada dispositivo escogido, que en cuestiones de comparación habría sido lo más ideal para poder hacer pruebas en común sobre cada uno de ellos. 34

43 Variable\Dispositivo Nintendo DS Mylo PSP mm x 73.66mm x Tamaño mm x 84.58mm x 28.7mm24.2mm x 123mm x 63mm 22.86mm Peso 275g 129.3g 280g Doble núcleo: ARM946E-S y CPU ARM7TDMI ARM9 PSP CPU RAM 4MB RAM / 656KB VRAM 1GB 32MB RAM / 4MB DRAM Almacenamiento interno No No No Almacenamiento externo No Memory Stick Pro Duo Memory Stick Duo 3 Semitransparent Reflexive Pantalla TFT Color LCD 2.4 TFT Color LCD 4.3 TFT Color LCD 3 Semitransparent Reflexive TFT Color LCD con Pantalla táctil Resolución de pantalla 256x192 pixels 320x240 pixels 480x272 pixels Colores desplegables Millones Pantalla táctil Si No No Bateria Litio Litio Litio Tiempo de vida de la batería 6-10 horas Música: 45 horas Video: 8 horas Vo-IP: 3,5 horas Videos No MPEG4/AAC MPEG4/AAC Musica No MP3 OGG MP3 VBR MP3 Atrac3 WMA WMA PCM WAV Atrac3plus Fotos No JPEG JPEG BMP PNG Juego Si No Si Libros No No No Comunicacion Wifi b Wifi b Wifi b Mini USB Mini USB Infrarojo Teclado No Teclado QWERTY desplegable No Microfono Si Si Si Precio $ $ $ Variable\Dispositivo ipod Touch Palm TX GP2X Tamaño 110mm x 61.8mm x 8mm 120.9mm x 78.23mm x 15.49mm143.6mm x 82.9mm x 34mm Peso 120g g 161g Doble núcleo: ARM920T y CPU Intel Xscale ARM 312Mhz ARM940T RAM 128MB 64MB Almacenamiento interno 16GB 128MB 64MB SDRAM Almacenamiento externo No SD, SDIO y MMC Memoria Secure Digital Pantalla 3.5 Color LCD 3.2 TFT touchscreen 3.5 TFT LCD Resolucion 480.x320 pixels 320x480 pixels 320x240 pixels Colores 16,7 Millones ,7 Millones Pantalla táctil Si Si No Batería Litio Litio 2AA Tiempo de vida de la batería Musica: 22 horas 5 horas Música: 6horas Video: 5 horas Video: 4 horas Videos MPEG4/AAC MPEG4/AAC AVI M4V MOV Musica AAC MP3 OGG Protected AAC WMA MP3 MP3 WMA MP3 VBR Audible AIFF WAV Apple Lossless Fotos JPEG JPEG JPEG BMP TIFF BMP GIF BMP PCX TIFF GIF GIF PSD PNG PNG Juego No Si Si Libros No PDF TXT ebooks Comunicaciones Wifi b y g Wifi b USB USB Bluetooth 1.1 USB Infrarojo (irda) Teclado No No No Precio $ $ $ Tabla 7: Comparaciones entre dispositivos embebidos 35

44 Como puede ser observado del estudio de la tabla, el GP2X es una buena escogencia entre los dispositivos comparados, ya que iguala o supera en muchas de las características a sus contrapartes y en la mayoría de los casos representa una opción más económica. Por otro lado se puede ver que el PSP, podría representar la otra mejor opción al momento de escoger un dispositivo para utilizarlo como herramienta para la creación sistemas embebidos. La única limitante de éste es que no existe un entorno de desarrollo abierto para desarrollar en el mismo, por lo que pierde valor al momento de pensar utilizarlo para algo más que para lo que fue diseñado. De nuevo el GP2X gracias a sus características y entorno de desarrollo abierto ofrece casi la misma funcionalidad, con la posibilidad de que puede ser mejorado por cualquiera que así lo desee. Por otro lado un par de verdaderas desventajas que se observan en el GP2X es la falta de una batería de litio y una red inalámbrica integrada en la placa base. Se recuerda que esto puede ser conseguido a través del Cradle conectándole un adaptador Wi fi o Bluetooth, y además existen proyectos independientes de la gente de la comunidad que explican como agregarle internamente un USB al GP2X, a través del cual se podría integrar el adaptador inalámbrico. [Archive, 2007] Hay que hacer notar también que, aparte de lo mencionado en el párrafo anterior, el hardware incluído en este tipo de dispositivos, es casi el mismo para todos, por lo que se podría decir que lo que realmente aporta algo nuevo al dispositivo es el sistema operativo que este usa y el 36

45 conjunto de aplicaciones que éste contiene. En este sentido el que ofrece mayor utilidad es el GP2X, ya que no está limitado por un conjunto de aplicaciones, al ser abierto su ambiente de desarrollo. 37

46 Capítulo 7. Desarrollo de juegos Al ser el GP2X un sistema de entretenimiento portátil con la capacidad de reproducir videojuegos emulados o nativos, era obvio que una de las pruebas necesarias para comprobar la funcionalidad y capacidad del equipo debía ser probar los juegos ya existentes, así como también probar los distintos ambientes de desarrollo de juegos para el mismo, desarrollando algunos prototipos. En este sentido se analizaron y probaron un conjunto de ambientes de desarrollo que fueron elegidos según su modo de programación, facilidad de programación, desempeño, portabilidad y presencia de API de juegos. Estos son: Lenguaje C++ con uso de librerías SDL. Lenguaje Python y librería pygame. Lenguaje Fenix. A continuación se muestra una comparación entre los distintos ambientes de desarrollo, para dar una idea rápida de una posible futura escogencia. 38

47 Ambiente de desarrollo Lenguaje C++ con SDL Lenguaje python y Pygame Lenguaje Fenix Modo de programación Orientación a objetos Orientación a objetos Multihilo (cada proceso es como un objeto) Facilidad de programación Poco intuitivo Excelente Bastante intuitivo Desempeño Portabilidad Presencia de API de juegos Bueno Ninguna Todas las arquitecturas donde corre python Muy intuitivo Muy bueno Todas las arquitecturas donde corre Fenix Tabla 8: Comparación entre ambientes de desarrollo Luego de realizar algunas pruebas y ver las distintas virtudes y desventajas de cada uno de los ambientes de desarrollo, se eligió Fenix como ambiente para desarrollar un prototipo de videojuego, que mostrase las funcionalidades y capacidades del GP2X. Fenix es sencillo de aprender y nos permitía realizar un rápido desarrollo de prototipos, junto con el hecho de que al ser tan portable pudimos encontrar un intérprete para el GP2X, y esto nos permitía desarrollar con calma en la computadora, probarlo en esta y una vez que estuviese listo el programa tan solo llevarlo al GP2X para ver como funcionaba en el equipo. Todos estos elementos fueron primordiales durante la pasantía ya que se tenía como limitante el tiempo de duración de la misma. 39

48 Como prueba de concepto se eligió realizar un juego llamado Tank2X 10, basado en el famoso y reconocido juego de combate y estrategia, Tank realizado por la compañía Atari Inc. en el año Figura 13: Toma de pantalla del juego Tank de Atari Inc. El trabajo investigativo en esa área incluyó una gran recopilación de material, se crearon dos wikis 11 para colocar la información recogida acerca del GP2X y del lenguaje Fenix, como medio para realimentar la comunidad y se dió una charla en una Jornada de Software Libre que tuvo lugar en las instalaciones del Instituto Superior de Estudios e Investigaciones Tecnológicas, (ISEIT) 12, en la cual se habló de Fenix como posible alternativa para el desarrollo de juegos 2D con software libre 13. Como resultado de esta investigación se logró juntar gran material de desarrollo de juegos 10 Para mayor información ver descripción de Tank2X en el apéndice C 11 y 12 I.S.E.I.T, es una institución líder en la formación de profesionales de alto perfil mediante programas y certificaciones en tecnologías abiertas y emergentes. 13 Para mayor información ver las láminas en el apéndice F 40

49 en 2D. Este material sirvió de base para la propuesta de un curso denominado Desarrollo de Videojuegos con Software Libre 14 que será utilizado por ISEIT como material para dictar un nuevo curso orientado a enseñar técnicas de programación y desarrollo de videojuegos tanto a niños como adultos. Este curso, así como todo el trabajo que se ha realizado sobre el equipo ha obtenido el aval de la compañía Gamepark Holdings, fabricante del GP2X. A través de ISEIT el curso será dictado en varios paises latinoamericanos. Centros de educación pública y privada de varios paises latinoamericanos evaluan incorporar el material del curso en el programa académico de bachillerato, como herramienta para fortalecer la enseñanza de las matemáticas, la física y la química en los jóvenes estudiantes. Por otro lado también se tiene como producto de la pasantía un prototipo de aplicación para la creación de mapas basados en cerámicas 15, creado como herramienta para la generación de los mapas usados por Tank2X. 7.1 Qué clase de juegos pueden desarrollarse para el GP2X? Debido a la arquitectura del GP2X básicamente sería posible desarrollar cualquier tipo de juego que no necesite excesivos recursos, incluso juegos multijugador basados en redes de comunicación. Por otro lado al ser la pantalla del GP2X reducida, debe tenerse en cuenta este aspecto al 14 Para mayor información ver el contenido programático en el apéndice B 15 Para mayor información ver la descripción de MapEdit en el apéndice D 41

50 momento de diseñar un juego, ya que si no se piensa bien, podría cometerse el fallo de que la interfaz no sea fácil de utilizar o que los gráficos no sean lo suficientemente grandes como para que pueda observarse los detalles. También hay que tomar en cuenta que el GP2X no viene integrado con una forma fácil de introducir datos, por lo que al momento del diseño del juego hay que considerar si se va a colocar alguna forma de teclado gráfico o si para poder jugar se necesita que se use un teclado conectado por ejemplo a través del Cradle. Con respecto a los gráficos, es posible realizar juegos tanto en 2D como en 3D para el GP2X, gracias a que este tiene un coprocesador que puede ser usado para el procesamiento gráfico. Está de más decir que la arquitectura del GP2X tiene sus limitaciones en cuanto a capacidad de procesamiento y por lo tanto hay que considerar este aspecto cuando se desarrolle un juego, ya que se tiene que estar pendiente de la cantidad de recursos necesarios tanto en memoria como en procesamiento. 42

51 Capítulo 8. GP2X y sistemas embebidos En este capítulo se presenta una descripción y algunos ejemplos de posibles sistemas embebidos que podrían ser desarrollados con el GP2X, así como también la descripción técnica del prototipo de sistema embebido desarrollado durante el transcurso de este proyecto. 8.1 Posibles sistemas embebidos Así como ya comentamos antes, en este proyecto se tenía como objetivo demostrar que el GP2X puede ser usado como herramienta para la creación de sistemas embebidos. Debido a sus características, tuvimos que pensar que clase de sistemas podían ser desarrollados, que fuesen interesantes y que pudiesen ser realizados en un tiempo reducido debido al poco tiempo de pasantía. Entre los sistemas que se tomaron en consideración están: Un electrocardiograma portátil. El GP2X podía ser usado para captar la señal y representarla de manera gráfica para una mejor comprensión de los resultados. 16 Una interfaz a otros dispositivos. Son muchos los equipos industriales que tienen algún puerto, normalmente serial, que puede ser usado para configurarlo o extraer data del mismo. En este caso el GP2X puede ser usado como una herramienta portátil para hacer de interfaz 16 Se puede conseguir una referencia a un proyecto parecido en monitor got granny/ 43

52 con el dispositivo. Un sistema de configuración, monitoreo o revisión de servidores de datos seguros. En este caso se tiene una máquina que no puede ser accedida sino físicamente y el GP2X podría servir como una llave de entrada al servidor, o una herramienta de monitoreo para chequear el estado del mismo o bien un sistema autónomo de configuración. Una vez más viendo el GP2X como una herramienta para extraer o poner datos en otro dispositivo. Un sistema portátil para controlar cámaras de seguridad. En aquellos lugares donde se necesita el uso de cámaras de seguridad, y en algún punto el guardia debe movilizarse de su puesto de mando, puede llevar consigo el GP2X para monitorear el estado de las cámaras, teniendo la capacidad incluso de girar estas si lo considerase necesario. Un sistema de control de tickets electrónicos. Utilizar el GP2X como un ente autónomo para la revisión de tickets electrónicos, como los entregados en un estacionamiento, o los utilizados en un automercado para el inventario. Un sistema portátil de búsqueda o almacenamiento de datos. En este caso se tiene data que quiere ser almacenada o consultada en un servidor central, y el GP2X sirve como herramienta para realizar la operación remotamente. Por ejemplo que se quiera utilizar el GP2X para tomar la huella dactilar de una persona y averiguar toda la información asociada. O en un restaurant para tomar las ordenes de los clientes. O en un evento de 44

53 publicidad para tomar encuestas. Al final, luego de haber estudiado todas las opciones, decidimos implementar un prototipo del sistema de tickets electrónicos, debido a una necesidad de la misma empresa. Esto representaba una gran oportunidad ya que se podría trabajar con un caso de la vida real, además de ser un cliente con la necesidad de una pronta solución. 8.2 eticket2x El prototipo de sistema embebido que fue desarrollado adopto eticket2x 17 como nombre, y básicamente es un sistema de control de entrada/salida para un estacionamiento. Está basado en tickets impresos con código de barra tipo code Diseño del sistema El sistema está desarrollado con el lenguaje Python que es una lenguaje libre, con alta portabilidad y rápido desarrollo. Debido a que se deseaba que el GP2X trabajáse autónomamente, el sistema se dividió en dos módulos independientes. Por un lado vamos a tener la aplicación del estacionamiento y por el otro tendremos una aplicación para el pago centralizado Aplicación de pago centralizado Está desarrollada con el lenguaje Python, haciendo uso de las librerías pygtk y pysqlite2. 17 Para mayor información ver el manual técnico en el apéndice E 45

54 Fue desarrollada siguiendo un esquema Model View Controller (MVC). Figura 14: Esquema MVC de las aplicaciones de eticket2x Está subdividida en varios módulos: lib/barcode.py Módulo que contiene un conjunto de funciones que permiten la creación de un ticket. Este contiene un encabezado usado para especificar los datos fiscales, un código de barra de tipo code128 acompañado de su valor en caracteres. lib/lite_dbapi.py Modulo de abstracción para el uso de la librería pysqlite2. lib/cypher.py Módulo que contiene una función de cifrado utilizada para la verificación de la autenticidad del ticket. eticket2x_paycenter.py Módulo que contiene todas las funciones de la aplicación. Representa el núcleo en el MVC. eticket2x_paycenter_gtk.glade y eticket2x_paycenter-gtk 46

55 Módulo que haciendo uso de la librería pygtk y pyglade aporta una interfaz gráfica a la aplicación. Representa la vista en el MVC. eticket2x_paycenter.db Base de datos de tipo SQLite, donde se registra toda la información asociada a los tickets de entrada y de salida. Representa los datos en el MVC. Interfaz gráfica Figura 15: Interfaz gráfica de pago centralizado eticket2x 47

56 Base de datos TICKET Nombre de registro Tipo de registro Descripción TICKET_ID Integer Identificador del ticket. TICKET_DATE_IN TICKET_DATE_OUT TICKET_DATE_ROUT TICKET_TYPE Char(12) Char(12) Char(12) Char(1) Fecha y hora de entrada al estacionamiento. Fecha y hora en la que fue cancelado el ticket. Fecha y hora de salida estacionamiento. Tipo de ticket. Posible valores: E - Estándar P Perdido C - Cortesía Tabla 9: Descripción de la tabla TICKET de la base datos usada por la aplicación de pago centralizado de eticket2x del TICKET_LOST Nombre de registro TICKET_ID Tipo de registro Integer Descripción Identificador del ticket. Referencia foránea al campo TICKET_ID de la tabla TICKET. CLIENT_NAME Char(50) Nombres del dueño del vehiculo. CLIENT_LASTNAME Char(50) Apellidos del dueño del vehículo. CLIENT_ID Char(10) Cédula del dueño del vehículo. VEHICLE_ID Char(10) Placa del vehículo Tabla 10: Descripción de la tabla TICKET_LOST de la base datos usada por la aplicación de pago centralizado de eticket2x La tabla TICKET contiene todos los datos necesarios para poder identificar a que hora el cliente entró, pagó y salió del estacionamiento, además de que tipo de ticket de salida usó. Si se 48

57 observa bien la tabla se nota que se tiene TICKET_OUT que es la hora en la que fue realizado el pago y TICKET_ROUT que es la hora real en la que se salió del estacionamiento. Esto se hizo pensando que si la aplicación fuese vendida a alguna institución como por ejemplo un centro comercial, es muy probable que les interesase conocer el tiempo que le toma a sus clientes salir del estacionamiento luego de que se haya realizado el pago, bien por que les toma mucho tiempo llegar al sitio donde dejaron su vehículo o por que decidieron realizar alguna otra diligencia antes de irse. Por otro lado la tabla TICKET_LOST contiene los campos necesarios para poder almacenar la información de un cliente que perdió un ticket, de manera que quede un registro de su información y la del vehículo que sacó del estacionamiento. Formato del ticket de salida Un ticket es un papel impreso que contiene varias partes, primero tenemos en la parte superior del mismo el contenido fiscal colocado por la empresa, luego podemos encontrar el código de barras tipo code128 y debajo de este la representación en caracteres del valor del código. Figura 16: Ejemplo de ticket de salida del sistema eticket2x 49

58 El código esta definido de la siguiente manera: Tipo de ticket: Es el primer caracter y representa que tipo de ticket de salida, dependiendo del valor que este tenga representa un caso distinto. Los posibles valores son: E (estándar, es el ticket normal), P (perdido) y C (cortesía). Código del ticket: Son los siguientes 5 caracteres y representan el código de identificación del ticket. Este código es el mismo que el código del ticket de entrada a partir del cual fue generado. Esto para que exista un vínculo directo entre ambos y sea fácil de identificar cuales tickets están relacionados. Código de seguridad: Son los siguientes 4 caracteres y es un código generado a partir de una función de hash. Esto es usado para saber que el ticket es válido y no fue forjado. La función de hash es común para ambas aplicaciones. Es como una huella electrónica que asegura la integridad del ticket. El algoritmo es fácilmente alterable por si se desea cambiarlo periódicamente para evitar huecos de seguridad. Fecha y hora: los siguientes 12 caracteres y expresan la fecha y hora en la que fue emitido el ticket, siguiendo el siguiente formato %dia%mes%año%hora%minutos%segundos 50

59 De esta manera un ticket con el valor de código de barra E estaría expresado por Código del ticket : Código de seguridad: 4912 Fecha: 12/09/07 Hora: 18:57: Aplicación del estacionamiento Está desarrollada con el lenguaje Python, haciendo uso de las librerías pygame y pysqlite2. Fue desarrollada siguiendo el mismo esquema MVC que para la aplicación de pago centralizado. Está subdividida en varios módulos: lib/barcode.py, lib/lite_dbapi.py, lib/cypher.py Son los mismos módulos que en la aplicación anterior eticket2x.py Módulo que contiene todas las funciones de la aplicación. Representa el núcleo en el MVC. eticket2x-gtk Módulo que haciendo uso de la librería pygame aporta una interfaz gráfica a la aplicación. Representa la vista en el MVC. 51

60 eticket2x.db Base de datos de tipo SQLite, donde se registra toda la información asociada a los tickets de entrada y de salida. Representa los datos en el MVC. Base de datos TICKET Nombre de registro Tipo de registro Descripción TICKET_ID Integer Identificador del ticket. TICKET_DATE_IN TICKET_DATE_ROUT TICKET_TYPE Char(12) Char(12) Char(1) Fecha y hora de entrada al estacionamiento. Fecha y hora de salida del estacionamiento. Tipo de ticket. Posible valores E Estándar P Perdido C Cortesía Tabla 11: Descripción de la tabla TICKET de la base datos usada por la aplicación del estacionamiento de eticket2x Esta base de datos es un subconjunto de la base de datos del pago centralizado. La información de esta es sincronizada para complementar la otra. De esta manera se tiene la hora real de salida. Además, en caso de que ocurra una perdida de ticket, con esta información puede ser descubierto cual fue el ticket que se perdió. Formato del ticket de entrada Sigue el mismo formato del ticket de salida, en el cual se tienen las tres partes. 52

61 Figura 17: Ejemplo de ticket de entrada del sistema eticket2x El código de barras a su vez esta definido en dos secciones: Código del ticket: son los primeros 5 caracteres del código y expresan el identificador numérico que tuvo el ticket al ser registrado en la base de datos. Este valor es único para cada ticket ya que para cada nuevo ticket se aumenta el valor en uno. Fecha y hora: son los siguientes 12 caracteres y sigue el mismo formato que en el ticket de salida. 53

62 Conclusiones y recomendaciones Conclusiones El GP2X ha comprobado ser una herramienta muy útil para el desarrollo de sistemas embebidos. Su capacidad de cómputo y buen diseño, lo vuelven una herramienta capaz de competir tanto en el mercado de entretenimiento como también para aquellos innovadores que lo quieran usar para otros fines. El lenguaje de programación de juegos Fenix ha demostrado ser una herramienta fácil de aprender y utilizar para el desarrollo de juegos en 2D. Aunque se encuentra todavía en una etapa temprana de su desarrollo, se espera grandes cosas de este proyecto. La escogencia de las metodologías incremental y prototipado para el desarrollo del proyecto, fue una de las bases para que el mismo se diera con éxito. El mercado de sistemas embebidos esta en pleno crecimiento y es un gran negocio invertir en el mismo, ya que ahora es cuando existen proyectos innovadores para desarrollar en este campo. Recomendaciones La siguiente versión del GP2X incorpora una pantalla táctil. Esto va a permitir desarrollar aplicaciones mucho más potentes, ya que ahora podríamos crear por ejemplo un teclado 54

63 virtual, parecido al usado por las PDA. Una de las primeras cosas que se nota al evaluar un GP2X, es la carencia de este de algún sistema de conexión inalámbrica en placa. Si se ve la competencia, muchos de los productos que están en la misma área están manejando este recurso para ampliar sus capacidades. Como tal, se recomienda la incorporación de un dispositivo de este estilo para volver al equipo mucho más poderoso de lo que ya es. Luego de la experiencia ganada con la investigación de frameworks de juego, se recomienda el lenguaje Fenix para la creación de videojuegos 2D, debido a la facilidad de aprendizaje, rápido desarrollo y alto rendimiento. Se recomienda el uso de la aplicación CraigAmp3 para escuchar música en el dispositivo, debido a que supera en funcionalidad al reproductor musical que viene con el GP2X. Se recomienda la incorporación de un RTC 18 en el equipo, permitiendo así crear programas de calendario, alarmas, etc. productos que son normalmente buscados por ejecutivos para usar en sus negocios. Por ejemplo los PDA suelen incluir diferentes ambientes de aplicaciones de este tipo. Por último se recomienda la incorporación de una batería de litio en el equipo, y que la misma pudiese ser recargada directamente por este. Esto mejoraría mucho los tiempos de uso y lo haría más práctico, aunque seguramente aumentaría su costo. 18 Real Time Clock ó Reloj de tiempo real 55

64 Referencias bibliográficas [Wiki, 2007] Wikipedia (2007). GP2X Wiki. (ver [GPH, 2007] [Sprites, 2007] [Archive, 2007] [Sistemas, 2007] [Standards, 2007] [GP2X, 2007] [Guyfawkes, 2007] [Open2x, 2007] [Fenix, 2007] GPH (2007). GP2X Official Developer Community. (ver Sprites mods (2007). Intro, transferring the GPS module. (ver GP2X File Archive (2007). File Archive. Carrick Information Technologies. (ver Wikipedia (2007). Sistemas integrados. Wikipedia, The Free Encyclopedia. (ver Project Infinity (2007). GP2X Standards. (ver Gamepark Holdings (2007). GP2X Personal Entertainment System. (ver Guyfawkes (2007). GP2X User Guide. (ver bin/cfiles.cgi?0,0,0,0,23,933) Open2x (2007). Open2x. (ver Fenix World (2007). Fenix World. (ver 56

65 [Lycos, 2007] Lycos (2007). Tutoriales Fenix. (ver [FenixDivsite, 2007] Divsite (2007). Fenix the way to game development. (ver [Sourceforge, 2007] [Referencia, 2007] [Fenix, 2007] [Divsite, 2007] [Larman, 2003] [Laudon, 1996] [Whitten, 1996] [Senn, 1992] Sourceforge (2007). Fenix project. (ver (2007). Referencia de Fenix. (ver (2007). Fenix manual. (ver Divsite (2007). Foros DIVSite. (ver Larman, Craig (2003). UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al proceso unificado. Segunda Edición. Prentice Hall / Pearson. Pág: Laudon, Kenneth C. Laudon, Jane Price (1996). Administración de los sistemas de información. Organización y tecnología. Tercera Edición. Prentice Hall / Pearson. Pág: Whitten, Jeffrey L. Bentley, Lonnie D. Barlow, Victor M (1996). Análisis y diseño de sistemas de información. McGraw Hill. Pág: Senn, James A (1992). Análisis y diseño de sistemas de información. Segunda Edición. McGraw Hill. Pág:

66 Apéndices 58

67 Apéndice A Aplicaciones del GP2X

68 Aplicaciones del GP2X Aplicaciones oficiales del GP2X A continuación se muestra una breve descripción de cada uno de los programas incluídos en el GP2X por defecto. 1 gp2xmenu Ambiente gráfico de menú para controlar las aplicaciones. Figura 1: GP2X Menú mplayer Reproductor de videos. Figura 2: GP2X Reproductor de videos 1 Para mayor información sobre el uso de las aplicaciones ver el apéndice B

69 MusicPlayer Reproductor de música. Figura 3: GP2X Reproductor de música PhotoViewer Visor de imágenes. Figura 4: GP2X Visor de imágenes

70 EbookViewer Visor de libros. Figura 5: GP2X Visor de libros Explorer Explorador del sistema de archivos. Figura 6: GP2X Explorador del sistema de archivos

71 Algunas aplicaciones no oficiales del GP2X CraigAmp3 Un reproductor de música (mp3, ogg, wav, midi) para el GP2X que soporta: Listas de reproducción (crear, cargar, salvar y editar) Búsqueda por medio de un teclado en pantalla (etiquetas id3, nombres de archivos, etc. Puede salvar los resultados como una lista de reproducción) Arte gráfico (descubrimiento automático) Aleatoriedad (sin repeticiones) Varios estados de pantalla (encendida, apagada y automática) Corre a distintas velocidades de CPU. Por defecto corre a 140Mhz para 320Kbps y a menos de 100Mhz para 128Kbps Lectura y visualización completa de todas las etiquetas halladas en id3 Basado en el reconocido programa de reproducción de audio Winamp Facilidad de uso Figura 7: CraigAmp3 Gmenu2X Es una ambiente gráfico alternativo para el GP2X La habilidad principal de la aplicación es la habilidad de crear vínculos director a los juegos y aplicaciones de manera que se puedan ejecutar directamente sin tener que buscarlas dentro de todo el sistema de archivos Maneja distintos menús en forma de tabs Permite el uso de diferentes pieles para personalización Overclocker nativo Configuración de volúmen y gamma 2 2 Ver

72 Figura 8: GMenu2X GP2XMB Es una ambiente gráfico alternativo para el GP2X, con el mismo diseño visual que el Cross Media Bar de la SONY. 3 Figura 9: GP2XMB Sterm Es un sencillo emulador de un terminal Soporta el uso de pieles para personalización Incorpora el uso del comando screen parapermitir el uso de varios terminales simultáneos. 4 Figura 10: Sterm 3 Ver 4 Ver

73 GP2X GPE Es un porte de la aplicación GPE Palmtop Environment para el GP2X. Muchos programas funcionales vienen incluidos, entre ellos: AbiWord Evince Gaim Dillo Gnumeric Xchat The GIMP GpsDrive GCC Figura 11: GP2X GPE

74 Apéndice B Desarrollo de videojuegos con Software Libre Nivel 1 Contenido programático

75 Desarrollo de videojuegos con Software Libre Nivel 1 Contenido programático Objetivo: Al finalizar el curso los estudiantes van a conocer sobre: Elementos de un videojuego Artefactos en un videojuego Técnicas de programación de videojuegos Animación básica Al finalizar el curso los estudiantes van a haber desarrollado una serie de videojuegos sencillos que se consideran como clásicos. Al finalizar el curso los estudiantes van a ser capaces de desarrollar un juego de plataforma 2D. Al finalizar el curso los estudiantes van a ser capaces de desarrollar en el lenguaje Fenix. Prerequisitos: Tener interés en el desarrollo de videojuegos. Conocimientos de programación básicos (manejo de funciones, estructuras de control y estructuras de datos).

76 Temario: Introducción a los videojuegos Introducción a Fenix Elementos de un videojuego Sprites Animación Input Tiempo Sonido y música Storyboard Artefactos en un videojuego Personajes Héroe Vida Puntaje Armas Vehículo Enemigos Inteligencia artificial Evadir Perseguir Enemigos Jefes NPCS (None player characters) Escenario Fondo Durezas Plataforma Nubes Paredes Transportadores Puertas Escaleras Huecos Ascensores Resortes Checkpoint Especiales tems Técnicas de programación Tableros Scrolling Mapa de durezas Mapa de cerámicas

77 Prácticas: Práctica 1: Hello ISEIT Descripción: Primer contacto con Fenix Nuevo recurso aprendido: Frame, procesos, carga y descarga de imágenes, incialización de la ventana, sprites, input por teclado o mouse Práctica 2 y 3: Pong Descripción: Realizar un clon del clasico juego Pong Nuevo recurso aprendido: Mostar texto, dureza (limites de ventana), colisiones, score, game over, carga y descarga de sonidos y musica, menús, inteligencia artificial (evadir y perseguir) Práctica 4: Breakout Descripción: Realizar un clon del clasico juego Breakout Nuevo recurso aprendido: Vida, multiprocesamiento, señales, estructuras de control, items, puntaje máximo Práctica 5: Scorched Earth Descripción: Realizar un clon del clasico juego Scorched Earth Nuevo recurso aprendido: Física de proyectil, disparo Práctica 5: Astrosmash Descripción: Realizar un clon del clasico juego Astrosmash Nuevo recurso aprendido: Armas, enemigo jefe, independencia de movimiento, aleatoriedad, escenario Práctica 6: Space Invaders Descripción: Realizar un clon del clasico juego Space Invaders Nuevo recurso aprendido: Ataque enemigo pre elaborado y directo Práctica 7 y 8: Laberinto Descripción: Realizar un juego de laberinto Nuevo recurso aprendido: Animación, scrolling, mapa de durezas, mapas de cerámicas, enemigos (trampas, enemigos tontos), puertas, checkpoint, ascensores, piso, vehículo Práctica 9 y 10: Juego de plataforma 2D Descripción: Realizar un prototipo de un juego de plataforma 2D Nuevo recurso aprendido: Escaleras, juntar todo lo aprendido hasta ahora

78 Apéndice C TANK2X Descripción de prototipo

79 TANK2X Descripción de prototipo TANK2X es un remake del reconocido juego Tank de Atari Inc, creado en El objetivo del juego es eliminar al oponente. Para ello debemos desplazarnos con nuestro tanque a través de multiples escenarios en los cuales nos espera una variedad de sorpresas y horas de adicción. A medida que se va avanzando en el juego este va tomando mayor dificultad pudiendo así tener enemigos más inteligentes, más fuertes, con mejores armas, más de un enemigo a la vez, etc. Lenguaje de programación: Fenix Plataforma: Multiplataforma (cualquiera soportada por Fenix) Archivos: prg/tank2x.prg Contiene el código fuente del programa. dcb/tank2x.dcb Es el binario generado por el compilador de Fenix. sound/cannon.wav Sonido de un disparo de cañon. sound/kaboom.wav Sonido de una explosión.

80 fpg/maps.fpg Contiene el conjunto de mapas de textura del juego. fpg/menu.fpg Contiene el logo del juego y el ícono usado para la selección de la opción de menú. fpg/tanks.fpg Contiene un conjunto de imágenes de tanques que varían en el color del tanque. fpg/share.fpg Contiene la imagen de fondo del campo de batalla, las balas y las explosiones. Estado actual del sistema Actualmente el juego se encuentra en un estado en el que es jugable, pero no han sido desarrolladas todas las funcionalidades propuestas. Funcionalidades desarrolladas Menú Juego interactivo contra una computadora semi inteligente Algunos pocos mapas Capturas de pantalla Mejoras recomendadas Manejar distintos tipos de zonas duras en el mapa. Por ejemplo: Paredes que luego de una serie de disparos se destruyan Paredes falsas. Podrían ser por ejemplo zonas verdes que no fuesen paredes en realidad, o fuesen tuneles vegetales Agua y puentes Piso rugoso donde la velocidad de movimiento es reducida Computadora con inteligencia evolutiva

81 Niveles con más de una computadora Disparos que reboten en la pared una cierta cantidad de veces Disparos especiales que hieran más de lo normal o que tengan algun efecto especial. Podría ser disparos paralizantes, disparos que disminuyan la velocidad, etc Uso de items. Por ejemplo: Una vida mas Aceleración momentanea Invisibilidad Invulnerabilidad Sonidos de ambiente que reflejen un campo de batalla Gráficos mas estilizados

82 Apéndice D MapEdit Descripción de prototipo

83 MapEdit Descripción de prototipo MapEdit es una utilidad para la creación y edición de mapas basados en cerámicas, es decir, aquellos mapas de imágenes que se construyen a partir de imágenes preelaboradas de menor tamaño, que juntas forman una imagen mayor. Lenguaje de programación: Fenix. Plataforma: Multiplataforma (cualquiera soportada por Fenix). Estructuras de datos Formato FMT (File Map Tile): Es un archivo de tipo FPG que tiene las siguientes características: Los archivos con código menor a 200, describen una capa del mapa Ejemplo: Si la capa es de 100x100 cerámicas, entonces el archivo será de 100x100 pixels, y cada pixel del mismo tendrá como color aquel formado por la representación numérica de la ceŕamica que va en esa posición. La representación numérica es construida a partir de la tupla RGB (0 255,0 255,0 255) de manera que un color (1,10,4) representa el valor *1+256*10+4=68100 Los archivos mayores a 200 contendran las cerámicas usadas por el mapa, independientemente la capa. Por restricciones del formato FPG, que sólo puede contener 999 imágenes, entonces solo se podrán contener hasta 199 capas para un mapa y 799 cerámicas en total.

84 Archivos: mapedit.prg Contiene el código fuente de la utilidad. mapedit.dcb Es el binario generado por el compilador de Fenix. *.fpg Representan las librería de imágenes para ser usadas como cerámicas. *.fmt Representan los archivos de mapas. Diseño del sistema Funciones F1 Crea un nuevo mapa. Permite escojer el tamaño del mapa, el tamaño. F2 Agrega una nueva capa al mapa que esta siendo editado. F5 Abre una ventana de selección que permite escojer la cerámica a ser usada. F6 Abre una ventana de selección que permite escojer la capa a ser editada. F9 Abre una ventana de selección que permite cargar una librería de cerámicas. F10 Abre una ventana de selección que permite cargar un mapa existente. F12 Permite salvar el mapa que esta siendo editado. Uso de la utilidad Al abrir la utilidad esta inicia con un nuevo mapa que tiene una nueva capa de 320x240 con un tamaño de cerámica de 16. Automáticamente es abierta la ventana de selección que permite cargar las librerías de cerámicas. Por defecto se encuentra seleccionada una cerámica negra, esta representa el vacío. Si se desea que una posición de la capa quede transparente, ésta debe contener la cerámica del vacío. Una vez seleccionada la cerámica a ser usada, ésta puede ser colocada en una posición del mapa haciendo click con el botón izquierdo del mouse. En caso de que se desee cubrir todo un área con una misma ceŕamica, esto puede ser realizado activando la herramienta de selección de área haciendo click con el botón derecho del mouse, esto activa un recuadro de selección que puede ser arrastrado. Una vez que se tenga el área cubierta, de nuevo se hace click en el botón derecho del mouse y todas aquellas cerámicas que de alguna manera esten en contacto con el área seleccionada seran alteradas quedando reemplazadas por la cerámica seleccionada. Estado actual del sistema Actualmente el sistema se encuentra en etapa de desarrollo.

85 Apéndice E eticket2x Manual técnico

86 eticket2x Manual técnico Caracas, 2007

87 Introducción El objetivo de este manual es dar a conocer el objetivo, instalación, funcionamiento y mantenimiento del sistema eticket2x. Está orientado a aquellas personas interesadas en instalar, mantener y usar el sistema. El sistema eticket2x es un proyecto de la empresa Corvus de Latinoamérica, como una propuesta de sistema alternativo para el control de entrada y salida en los estacionamientos, basado en el uso de tickets impresos con código de barra tipo codigo128. Los conceptos usados en el mismo son fácilmente llevables a otros ambientes donde se haga uso de tickets basados en código de barras para controlar algún tipo de información. Como por ejemplo: supermercados, librerías, disco tiendas, etc.

88 Índice de contenidos Introducción Índice de contenidos Objetivos Requerimientos del sistema Instalación Instalación del sistema de control Instalación del pago centralizado Funcionamiento Casos de uso Normal Ticket de cortesía Tiempo límite superado Ticket perdido Diagrama del proceso Uso Mantenimiento Preguntas frecuentes Qué pasa si se fue la luz y el GP2X se apagó? Cómo hago si detecto que los tickets de estacionamiento estan siendo clonados?...14 Cómo hago si a un usuario se le perdió el ticket? Puede el sistema evolucionar para añadirle un mayor número de posibilidades?...14 Limitaciones, dificultades y sus soluciones Estado del sistema Referencias

89 Objetivos Realizar un prototipo de sistema embebido, basado en el dispositivo de entretenimiento personal GP2X, haciendo uso de software libre. Realizar un prototipo de sistema para controlar la entrada y salida en los estacionamientos, capaz de entregar, verificar y controlar el cobro de tickets impresos con código de barra tipo código128.

90 Requerimientos del sistema Debe ser desarrollado con software libre. Debe poder ser ejecutado en el GP2X, el cuál debe funcionar como un sistema autónomo, es decir, que este no estará conectado a una red comunicacional para poder funcionar. Los tickets deben usar un código de barra tipo código128. Debe ser capaz de generar (imprimir) un ticket de entrada. Debe permitir levantar la barrera del estacionamiento para que el carro pueda entrar o salir según sea el caso. Debe existir un sistema de pago centralizado para poder realizar el cobro de los tickets. Este debe tener las siguientes características: Debe permitir hacer el cobro y la facturación del pago. Debe ser capaz de generar (imprimir) el ticket de salida. Debe permitir tomar acciones en caso de que un ticket se extravíe. Debe permitir generar un nuevo ticket Debe permitir realizar un cobro especial por la tarifa de extravío Debe poder detectar cual fue el ticket extraviado Debe dejar un registro de información sobre los datos del carro y la persona a la cual se le extravió el ticket.(ejm: nombre y cédula de la persona, placa del carro) Debe ser capaz de verificar un ticket de salida Si el ticket es válido, debe levantarse la barrera del estacionamiento para permitir que el carro salga. Si es inválido debe informársele a la persona que se dirija al pago centralizado. Si el tiempo límite luego de haber realizado el pago fue superado, debe informársele a la persona que debe dirigirse al sistema de pago centralizado para cancelar un nuevo ticket.

91 Instalación El sistema consiste de dos módulos principales: Sistema de control Sistema de pago centralizado Instalación del sistema de control Se verifica que en el GP2X donde vaya a ser instalada la aplicación, este instalado el paquete: pygame En caso contrario, habría que instalarlo. Para ello puede descargarse el paquete pygame para el GP2X desde la dirección bin/cfiles.cgi?0,1,0,0,14,917 Luego de haberlo descargado debe copiarse a la SD o a la Nand del GP2X a manera de que este pueda ser usado Se procede a copiar la carpeta et2x scontrol en la SD o la Nand según se prefiera. Se conecta el lector laser al GP2X. Actualmente, para el prototipo que fue desarrollado esto se realiza conectando el lector laser a un craddle oficial a través de un cable USB a PS2 y luego el GP2X se coloca en el craddle. Para la versión final esto debería de realizarse directamente a través de un circuito electrónico que este conectado al GP2X. Se procede a ejecutar la aplicación desde el menú de utilidades.

92 Instalación del pago centralizado Se verifica que en la máquina donde vaya a ser instalada la aplicación,esten instalados los siguientes paquetes: Python2.4 o mayor PyGTK2 PyGlade2 PySQLite2 En caso de que alguna de estas faltase, habría que instalarlas. La instalación resolvería las dependencias necesarias si así fuese el caso. Esto puede ser logrado en una máquina con Ubuntu Feisty 7.04 ejecutando la orden #sudo aptitude install python2.4 python glade2 python pysqlite2 python gtk2 Se procede a copiar la carpeta et2x scentral al sitio donde se desee que quede instalada la misma. Esto puede ser logrado haciendo uso de la orden #cp et2x scentral /capeta_instalacion Luego basta con entrar a la carpeta y ejecutar el ejecutable et2x central Esto puede ser logrado haciendo uso de las ordenes #cd /carpeta_instalacion/et2x scentral #./et2x central

93 Funcionamiento Casos de uso Normal 1. Primero la persona llega al estacionamiento y agarra un ticket de entrada. En ese momento queda registrado en la base de datos del sistema de control, la información relacionada con el ticket de entrada y la hora en la cual fue generado. 2. Luego de que la persona ha realizado sus diligencias, procede a dirigirse al centro de pago centralizado, donde entrega el ticket que obtuvo al momento de la entrada. 3. El identificador del ticket es ingresado en el sistema de pago centralizado, bien sea manualmente o valiendose de un lector laser para leer el código de barras. 4. En este momento el sistema conoce el momento en el que el cliente entro al sitio y junto con la información de la hora actual (hora de salida), realiza el cálculo de las horas a ser facturadas. 5. Basándose en la tarifa que se cobra por hora o fracción se realiza el cálculo del monto a ser cobrado. 6. Se realiza el cobro y se genera el ticket de salida En este momento queda registrado en la base de datos del sistema de pago centralizado, la información relacionada con el ticket de entrada, de salida y el monto que fue facturado. 7. En este momento la persona se dirige a retirar su carro 8. Cuando ya se encuentra en la salida, debe presentar el ticket de salida bajo el lector laser del sistema de control 9. Una vez que este es leído y verificado como ticket válido se levanta la barrera del estacionamiento para permitir a la persona retirarse Ticket de cortesía El procedimiento es el mismo que en el primer caso de uso, sólo que al momento de realizar el pago se marca el ticket como un ticket de cortesía y no se le realiza ningun cobro a la persona.

94 Tiempo límite superado Este caso es igual al anterior, sólo que en el paso 9 el ticket no es verificado como válido ya que el tiempo límite luego de haber realizado el pago fue superado. 10. Una vez que fue detectado que el tiempo límite luego de haber realizado el pago fue superado, se le informa al usuario que debe dirigirse al centro de pago centralizado para cancelar una tarifa de recargo por el tiempo consumido. 11. Una vez que el usuario se dirige al pago centralizado, se selecciona en el sistema que se va a realizar un pago especial asociado al hecho de que se supero el tiempo límite. 12. El sistema procede a calcular el tiempo a ser facturado, basándose en la hora de salida que marcaba el ticket de salida, usándolo en este caso como hora de entrada, y la hora actual como hora de salida. Queda registrado en la base de datos del sistema de pago centralizado una nueva entrada de ticket de salida, asociado al identificador del ticket. 13. A partir de aquí el procedimiento es el mismo que en el paso 5. Ticket perdido Este caso es parecido al normal, sólo que al momento en que la persona vaya a pagar debe informar que se le extravio el ticket. Se selecciona en el sistema que se va a relizar un cobro de una tarifa especial por ticket extraviado. Al realizar esta operación el sistema aplica como cobro el monto seleccionado para perdida de ticket y le coloca la hora de salida basándose en la hora actual. En este momento se crea en la base de datos un nuevo registro con la información de un nuevo ticket donde la hora de entrada y salida es la misma. Fijese que la incongruencia de ambas bases de datos puede ser usada para detectar cual fue el ticket perdido. A partir de aquí todo es igual al proceso normal como si nos encontrasemos en el paso 6.

95 Diagrama del proceso Entrar al estacionamiento y agarrar ticket de entrada Diligencias Cobro tarifa normal Dirigirse al pago centralizado es ticket perdido? No Dirigirse a la salida Si Cobro tarifa especial No es ticket valido? Si Si se supero el tiempo límite luego de realizar el pago? No Salir del estacionamiento

96 Uso Como ya se comento antes el sistema esta compuesto por dos aplicaciones, una de ellas que va en el sitio donde se encuentra la entrada o salida del estacionamiento y la otra es un pago centralizado. El uso de la aplicación de entrada o salida consiste en agarrar el ticket de entrada al momento de entrar y colocar el ticket de salida bajo el lector laser al momento de salir. Las pantallas que pueden ser vistas durante este proceso son: En cambio la aplicación de pago centralizado tiene una interfaz gráfica diseñada en GTK y debe ser controlada por una persona. Dependiendo de la situación la persona debe insertar la información del ticket de entrada para realizar el cálculo del precio a ser facturado y en caso de que sea el caso de que un ticket se haya perdido debe introducir la información del cliente. La interfaz esta diseñada de manera que es bastante intuitiva y se ve así: