UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Bridge Wireless para printer Esc/Pos USB

Autor:Ing. Jorge Crespo Romero

Director:Juan Manuel Cruz (FIUBA, UTN-FRBA)

Codirector:Esp. Ing. Julián Iglesias

Jurados:Esp. Ing. Sergio Renato De Jesús Meleán (FIUBA)

Esp. Ing. Ernesto Gigliotti (UTN-FRA, FIUBA)Esp. Ing. Guillermo Evangelista (FIUBA))

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires entre abril ydiciembre de 2017.

III

Resumen

En esta memoria se detalla el desarrollo de un Bridge wifi para una impresoracon interfaz USB y protocolo esc/pos. El proyecto surge de una necesidad de la

empresa TecnoAccion SA, que requería una solución que añadiese mayorfuncionalidad y versatilidad al equipamiento existente alcanzando un

compromiso entre un costo reducido y capacidad de ampliación defuncionalidad futura.

Para llevar a cabo el desarrollo se han aplicado conocimientos adquiridos en lacarrera, entre los mismos herramientas de sincronización entre procesos e hilosinter-proceso, desarrollo guiado por pruebas (Test Driven Development. TDD)

con test unitarios e integración continua con tareas de compilación y testeoautomáticas.

V

Agradecimientos

Es difícil condensar en unas líneas todo el apoyo que he recibido tanto durante eldesarrollo de este trabajo como durante toda mi vida.

En primer lugar, agradecer a TecnoAcción SA todo el apoyo y soporte recibido. Alos compañeros de trabajo, y a los supervisores que también veo como compañe-ros.

En segundo lugar a toda mi etapa formativa anterior. A la universidad y profe-sores del otro lado del charco por dirigirme y motivarme para acabar estandodonde estoy.

En tercer lugar a la Nación Argentina, a la UBA y a la organización de la Carrera.A mis directores Juan Manuel y Julián por el apoyo recibido y soportar el trabajoque les haya dado. A todos los profesores de las asignaturas de la carrera, porponerle tantas ganas y empuje a su tarea de enseñanza.

Y por último, y más importante. A toda mi familia y a los amigos fuera del planoformativo o laboral. Porque siempre están ahí para todo lo necesario. Por todo loque hemos compartido y compartiremos en el futuro.

A todos, muchas gracias.

VII

Índice general

Resumen III

1. Introducción General 11.1. Motivación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Introducción general de las tecnologías utilizadas . . . . . . . . . . 21.3. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Introducción Específica 52.1. Requerimientos del proyecto . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Requerimientos de Hardware . . . . . . . . . . . . . . . . . . 52.1.2. Requerimientos de Firmware . . . . . . . . . . . . . . . . . . 62.1.3. Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2. Planificacion del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Diseño e Implementación 113.1. Entorno de desarrollo y herramientas . . . . . . . . . . . . . . . . . 113.2. Librería esc/pos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3. Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4. Integración del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4. Ensayos y Resultados 234.1. Test unitarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2. Pruebas de comunicación . . . . . . . . . . . . . . . . . . . . . . . . 264.3. Pruebas de impresión . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5. Conclusiones 315.1. Trabajo realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Bibliografía 33

IX

Índice de figuras

1.1. Tipos de conectores USB. . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Esquema del sistema desarrollado. . . . . . . . . . . . . . . . . . . . 4

2.1. Planificación de las tareas en formato de tabla. . . . . . . . . . . . . 82.2. Diagrama de Gantt de las tareas. . . . . . . . . . . . . . . . . . . . . 9

3.1. Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2. Ciclo de trabajo de Jenkins . . . . . . . . . . . . . . . . . . . . . . . . 133.3. Portal de acceso de Jenkins . . . . . . . . . . . . . . . . . . . . . . . . 133.4. Modelo Maestro-Esclavo de comunicación con la impresora . . . . 143.5. Máquina de estados de la comunicación con la impresora . . . . . . 173.6. Esquema general de la solución integrada . . . . . . . . . . . . . . . 183.7. Flujo de trabajo del hilo de la impresora . . . . . . . . . . . . . . . . 20

4.1. Plantilla de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2. Impresión de la plantilla de pruebas . . . . . . . . . . . . . . . . . . 30

XI

Índice de Tablas

3.1. Listado de comandos ESC/POS . . . . . . . . . . . . . . . . . . . . . 15

XIII

Dedicado a Tamara

1

Capítulo 1

Introducción General

En el presente capítulo se presenta una introducción general del proyecto desdeel punto de vista del origen y motivación del mismo, y se explican las tecnologíasnecesarias para su implementación a nivel funcional.

1.1. Motivación del proyecto

La empresa TecnoAcción SA suministra un servicio de adquisición de apuestasy comunicación de las mismas a servicios centralizados para las loterías más im-portantes del país. Para llevar a cabo dicho servicio, se apoya en distintos dispo-sitivos de comunicación, adquisición de apuestas con interacción del usuario yde suministro de recibo en forma de ticket.

Entre los terminales de juego existen versiones portátiles de bajo peso y dimensio-nes, y dispositivos estáticos en formato All-in-one de pantalla táctil con periféricos,entre ellos impresoras térmicas de puesto de venta.

El número de agencias de lotería en el país es elevado, por lo que el número determinales de juego es una cifra considerable en consecuencia. De esta manerasegún el equipamiento de agencia típico existe al menos una terminal estática,con su impresora asociada en cada una de las agencias.

En su momento, a la hora de valorar el equipamiento en función de las necesi-dades, la empresa TecnoAcción SA se decidió por la adquisición de impresorascon interfaz USB (Universal-Serial-Bus, Bus Serie Universal) dando prioridad a lacalidad de impresión y costo respecto a la versatilidad de otro tipo de interfacesadicionales.

Sin embargo, en los últimos años se ha diversificado el servicio en las agenciascon suministro de contenidos audiovisuales informativos y otros como cuponesdescuento y publicidad en los tickets de lotería que ha supuesto un impacto parala organización física de la agencia.

Uno de los problemas principales es la acumulación de clientes en el mostradordonde se sitúa el agenciero con el terminal de juego. Sobre todo en el caso de ter-minales estáticas, donde terminal y periféricos están cableados mediante cablesde interfaz USB (Universal-Serial-Bus, Bus Serie Universal) con sus periféricos ensus cercanías.

De esta manera surgió la necesidad de implementar una solución que dotase ala instalación de equipamiento en agencias de lotería una flexibilidad que actual-mente no posee. Si se logra reubicar de cierta manera los puntos de reunión de

2 Capítulo 1. Introducción General

los clientes la agencia ganaría capacidad de modificar la distribución física delmobiliario y mejorar a su vez la organización y seguridad en el recinto.

Con ese objetivo en mente, el autor del presente trabajo propuso a TecnoAcciónSA la implementación de una solución que habilite a las impresoras con una in-terfaz inalámbrica que permita su reubicación en otra zona de la agencia. La im-plementación se realizaría mediante el uso de un sistema embebido comercial coninterfaz inalámbrica y una interfaz USB que permite la conexión con la impresora.El sistema embebido, de esta manera, proporcionaría a la impresora de una inter-faz inalámbrica no crítica (en cuanto a la fiabilidad y seguridad de la misma) que,permita su uso desde la distancia de la terminal de juego. Por otro lado, ya quelos sistemas embebidos comerciales actuales de bajo costo poseen una potencia ycaracterísticas claramente sobredimensionadas para este proyecto se deja abiertala puerta a otros desarrollos futuros de índole audiovisual o de sistemas.

1.2. Introducción general de las tecnologías utilizadas

En esta sección se a realiza una introducción histórica y se explican brevementelas características más importantes de las tecnologías sobre las que se sostiene elproyecto.

El Universal Serial Bus, más conocido por las siglas USB, es un bus estándar in-dustrial que define los cables, conectores y protocolos usados en un bus paraconectar, comunicar y proveer de alimentación eléctrica entre computadoras, pe-riféricos y dispositivos electrónicos. El desarrollo surge de un grupo de empresasque buscaban unificar la forma de conectar periféricos a sus equipos, por aque-lla época poco compatibles entre sí, entre las que estaban Intel, Microsoft, IBM,Compaq, DEC, NEC y Nortel. La primera especificación completa 1.0 se publicóen 1996, pero en 1998 con la especificación 1.1 comenzó a usarse de forma masiva.

El USB es utilizado como estándar de conexión de periféricos como teclados, rato-nes, memorias USB, joysticks, escáneres, cámaras digitales, teléfonos móviles, re-productores multimedia, impresoras, sistemas de adquisición de datos, módems,tarjetas de red, tarjetas de sonido, tarjetas sintonizadoras de televisión, grabado-ras de DVD externas y discos duros externos. Su aceptación ha sido tan grandeque ha desplazado a otro tipo de conectores como el puerto serie, puerto paralelo,puerto de juegos, Apple Desktop Bus o PS/2.

Dentro de la terminología USB, el PC que soporta este tipo de bus, se denominaHost USB; mientras que por su parte y dentro de la misma terminología, todoperiférico y/o dispositivo, se denomina Device.

Existen distintos conectores USB según la función del mismo (host o device) yde la versión de USB (USB 2.0 y USB 3.0). Un resumen de las fundamentalestopologías se muestra en la Figura 1.1.

Por otra parte,Wifi (proveniente de la marca Wi-Fi) es un mecanismo de conexiónde dispositivos electrónicos de forma inalámbrica. Los dispositivos habilitadoscon wifi (como una computadora personal, un televisor inteligente, una video-consola, un teléfono inteligente o un reproductor de música) pueden conectarsea internet a través de un punto de acceso de red inalámbrica.

1.3. Objetivos del proyecto 3

FIGURA 1.1: Tipos de conectores USB.

Wi-Fi es una marca de la Alianza Wi-Fi, la organización comercial que adopta,prueba y certifica que los equipos cumplen con los estándares 802.11 relacionadosa redes inalámbricas de área local.

El estándar IEEE 802.11 define el uso de los dos niveles inferiores de la arquitectu-ra o modelo OSI (capa física y capa de enlace de datos), especificando las normasde funcionamiento de una red de área local inalámbrica (WLAN). La primera ver-sión de la norma se publicó en 1997 por el Institute of Electrical and ElectronicsEngineers (Instituto de Ingenieros Eléctricos y Electrónicos) o IEEE, el cual ac-tualmente se encarga de su mantenimiento. Las especificaciones de este estándarproporcionan la base para los productos con redes inalámbricas que hacen uso dela marca Wi-Fi.

Dicho estándar es objeto de constante revisión, habiendo dado a lugar a nume-rosas variantes en función de la frecuencia utilizada y el comportamiento entrenodos. Todas estas variantes se nombran típicamente añadiendo una letra comosufijo, por ejemplo:IEE 802.11g, IEEE 802.11n, etc.

1.3. Objetivos del proyecto

El objetivo principal de este proyecto es la implementación de un dispositivo Wi-reless para cumplir una necesidad de conexión inalámbrica de una impresoraBematech MP4200. Este dispositivo se debe implementar con un sistema embe-bido de la familia OrangePi y poseer interfaz WiFi y USB para su conexión conla impresora. Un esquema simplificado del sistema desarrollado se muestra en laFigura 1.2.

Con este dispositivo se pretende una mejora en la simplicidad de la instalacióndel equipamiento y reducción de costes de cableado y tendido del mismo en agen-cias de lotería. La funcionalidad deseada es la impresión de archivos en formatográfico raw, con unas dimensiones físicas determinadas. Como punto final el pro-yecto comprende la documentación de todo el software asociado.

4 Capítulo 1. Introducción General

FIGURA 1.2: Esquema del sistema desarrollado.

El siguiente objetivo es principalmente formativo. Desde el punto de vista delsistema a desarrollar el autor del siguiente trabajo espera obtener experiencia yconocimientos en protocolos WiFi y USB. Por otro lado, desde la realización deltrabajo, el autor también espera adquirir experiencia y hábito en el uso de he-rramientas automáticas de documentación, el uso de test unitarios y sistemas decontrol de versiones distribuidos.

En último lugar, el siguiente trabajo se presenta como medio para completar laCESE (Carrera de Especialización de Sistemas Embebidos) de la UBA (Universi-dad de Buenos Aires)

Entre los objetivos del proyecto no se encuentra desarrollar la herramienta queenvía el archivo a imprimir al dispositivo, la conexión de más de una impresoraal sistema embebido ni la compatibilidad con otros modelos de impresora delmismo u otro fabricante.

5

Capítulo 2

Introducción Específica

En este capítulo se muestra con detalle el desarrollo del proyecto y se describenlos requerimientos de la solución implementada, la organización del trabajo rea-lizado en distintas tareas y su planificación temporal.

2.1. Requerimientos del proyecto

En esta sección se listan los requerimientos previos del trabajo, que dieron for-ma a la implementación final. Para su mejor presentación se realiza una divisiónde los mismos en secciones en función de su naturaleza: hardware, firmware ydocumentación.

2.1.1. Requerimientos de Hardware

A continuación se listan los requerimientos del proyecto a nivel físico, electrónicoy de interfaces de conexión de los elementos utilizados.

1. El sistema utilizará un dispositivo OrangePI Plus. Es una familia de siste-mas embebidos de moderada popularidad y con una relación entre presta-ciones y costo muy interesante.

2. El sistema utilizará una impresora Bematech MP4200. Ese modelo de impre-sora ha sido ampliamente distribuida por TecnoAcción SA en las agenciasdel país, por lo que es la opción más razonable entre los modelos con losque trabaja actualmente. El modelo utilizado es el más básico, y posee unabuena relación entre prestaciones y costo de la impresora.

3. La placa OrangePI Plus poseerá una antena o un conector U.FL. De esta ma-nera se puede sustituir la antena por otra de mayor ganancia si la ubicacióndel embebido no es la más adecuada en cuanto a cobertura.

4. Las comunicaciones inalámbricas se realizarán bajo estándar IEEE802.11.Se utilizará la versión más extendida de WiFi doméstico, que es la que im-plementan casi todas la soluciones basadas en embebidos como OrangePi,Arduino, RaspberryPi, etc.

5. La conexión entre la impresora y OrangePi se realizará mediante un conec-tor USB 2.0. La impresora elegida no integra interfaz USB 3.0. Además, laimpresora dispone de un sistema de alimentación adicional por lo que la

6 Capítulo 2. Introducción Específica

posible mejora en suministro de potencia de USB 3.0 no afecta al sistemapropuesto.

2.1.2. Requerimientos de Firmware

En esta subsección se indican los requerimientos relativos al desarrollo softwarey la implementación a nivel lógico.

1. Se utilizará un repositorio Git para versionado. Se aprovecha la realizaciónde este proyecto para la familiarización con herramientas de control de ver-siones distribuidas.

2. Se utilizará Doxygen como herramienta para generar la documentación. Deesta manera se pretende generar un hábito en el desarrollo de documenta-ción por parte del autor de este trabajo.

3. Se realizarán tests unitarios para los módulos de la impresora y manejadorde eventos general. A su vez, se realizarán pruebas integradas del sistemacompleto para verificar su funcionalidad.

4. El protocolo Esc/Pos utilizado será el estándar de la impresora usada. Es unestándar internacional y se intentará evitar el uso de comandos exclusivosde esta impresora en el caso de que existiesen.

5. Se utilizará TCP como protocolo de comunicación sobre WiFi. De esta mane-ra se dispone de una conexión confiable permitiendo el uso de protocolos dered como SFTP (Secure -File-Transfer-Protocol) o SCP (Secure-Copy-Protocol)

2.1.3. Documentación

Durante la realización del proyecto se redactan distintos documentos entregables.

1. Se elaborará un informe de avance. Aproximadamente en la fase intermediade la extensión total del proyecto se realizará un informe que detalle lastareas conseguidas hasta el momento y matice los requerimientos listandolas medidas que se tomen si el desarrollo no es el esperado.

2. Se elaborará un informe final. Se elabora este documento, en el que se ex-plica todo el trabajo realizado y la metodología y técnicas utilizadas en surealización.

2.2. Planificacion del proyecto

El proyecto dió inicio en abril y finalizó en noviembre de 2017. Teniendo en cuentala disponibilidad temporal del autor del trabajo, se estimó una carga de trabajouniforme durante todo ese intervalo de tiempo.

Para su mejor seguimiento y desarrollo se dividió el mismo en distintas tareasespecíficas de duración acotada. La definición de las tareas, junto con su duraciónestimada se muestran en la Figura 2.1.

2.2. Planificacion del proyecto 7

Una vez se definieron las tareas se diseñó una planificación de las distintas tareasde trabajo en cascada por simplicidad, ya que no existían dependencias compli-cadas entre las mismas. En la Figura 2.2 se muestra el diagrama de Gantt corres-pondiente a la planificación realizada para el presente proyecto. Esta planificaciónpudo ser cumplida sin desvíos significativos.

8 Capítulo 2. Introducción Específica

FIGURA 2.1: Planificación de las tareas en formato de tabla.

2.2. Planificacion del proyecto 9

FIGURA 2.2: Diagrama de Gantt de las tareas.

11

Capítulo 3

Diseño e Implementación

En este capítulo se detallan las características del diseño y del desarrollo del tra-bajo realizado y se muestran los retos más significativos y las decisiones que sehan tomado a la hora de afrontar los mismos.

3.1. Entorno de desarrollo y herramientas

El autor del trabajo decidió utilizar este proyecto como medio para ejercitar eluso de herramientas con las que no está familiarizado y ha tenido en contacto endistintas materias de la Carrera de Especialización en Sistemas Embebidos.

Desde el punto de vista del desarrollo se realizó un esfuerzo en utilizar una fór-mula de desarrollo automatizado en base a test unitarios junto a elementos deintegración continua. El código que se ha ido desarrollando se ha manejado enun sistema de control de versiones SVN al comienzo del proyecto y un sistemabasado Git en la fase final del proyecto. Un esquema del entorno de desarrollo semuestra en la Figura 3.1.

FIGURA 3.1: Entorno de desarrollo

A continuación se explican los detalles más relevantes de cada uno de los compo-nentes:

Sistema de control de versiones.

12 Capítulo 3. Diseño e Implementación

En su experiencia profesional, el autor de este trabajo ha utilizado repeti-damente sistemas de control de versiones centralizados basados en Subver-sion. Estos sistemas son muy parecidos a un sistema de control de archivosy funcionan registrando las diferencias entre los mismos en las distintassubidas que se realizan por parte de los desarrolladores.

En el área de la empresa TecnoAcción SA donde trabaja el autor de esteproyecto se realizó una transición entre un sistema Subversion a otro siste-ma de control de versiones distribuido basado en Git. Dado que algunas delas tareas que componen el trabajo se realizaron en parte con recursos dela empresa TecnoAcción SA, también se tuvo que realizar la transición delrepositorio Subversion de TecnoAccion SA al entorno de Git.

De esta manera, en la fase final del proyecto se creó un repositorio en Github(una plataforma de desarrollo colaborativo basada en Git) que incluye elcódigo del proyecto. Se lograron así dos objetivos: la publicación abiertapara su uso como futura referencia para consulta y la posibilidad de mejoracontinua del código del proyecto gracias a las colaboraciones que puedansurgir en el futuro.

Herramientas de testing automático.

Debido a su experiencia laboral y formación, el autor está familiarizado conlenguajes de programación de bajo nivel como C. Dados los otros retos queiba a tener que enfrentar en la realización de este trabajo, se decidió porutilizar lenguaje C por ser el lenguaje de programación con el que estabamás familiarizado. De las distintas opciones disponibles se optó por utilizarCeedling aprovechando la compatibilidad con el lenguaje de programaciónutilizado y que el autor había recibido una introducción al mismo en la asig-natura Ingeniería del Software de la Carrera de Especialización en SistemasEmbebidos.

Ceedling es un sistema Open Source de compilación para proyectos de soft-ware desarrollados en C que se puede ver como una extensión alrededorde Rake en Ruby (una herramienta de control de dependencias como Ma-ke). Ceedling está enfocado en el desarrollo TDD (Test-Driven-Development,Desarrollo Dirigido por Tests) en lenguaje C, e integra otros proyectos co-mo Unity (un framework para realización de test unitarios especializado ensistemas embebidos), CMock (una herramienta de mocking y generación destub) y Cexception (una librería de manejo de excepciones en C).

En este trabajo se han realizado test unitarios de las partes críticas del siste-ma. Dado que determinadas capas de la implementación están basadas enlibrerías populares de moderada antigüedad, se ha dejado de lado la reali-zación de testeo unitario en esas partes.

Respecto al orden del código realizado, los tests unitarios realizados se en-cuentran en la carpeta test/ del proyecto. Cada grupo de test está distribuidoen archivos c nombrados con prefijo test.

Por ejemplo, el archivo bema.c contiene las funciones de comunicación con laimpresora. Todos los test que prueben el comportamiento de esas funcionesestán incluidos en el archivo test_bema.c de la carpeta test/.

Software de integración continua.

3.1. Entorno de desarrollo y herramientas 13

Jenkins es un software de integración continua open source escrito en len-guaje Java. Está basado originalmente en el proyecto Hudson, pero cambiósu nombre a Jenkins debido a un conflicto de propiedad intelectual. Es unservidor automatizado que se puede utilizar para la automatización de to-do tipo de tareas relacionadas con la compilación, el testing y el desplieguede todo tipo de proyectos software.

Para la realización de este trabajo, el autor configuró en una máquina virtualpara albergar un servidor Jenkins que realizase consultas periódicamente enel repositorio respecto a las subidas de código que iba realizando. Si habíacambios desde la última consulta, el servidor Jenkis realizaba unas accionesque se resumen en la figura 3.2.

FIGURA 3.2: Ciclo de trabajo de Jenkins

Una vez que el servidor Jenkins detecta nuevas versiones de código en elrepositorio realiza la descarga del mismo. En el siguiente paso, medianteCeedling se realiza la compilación con rake y el compilador gcc del códigode la aplicación del sistema y de los tests. Si la compilación no ha podidocompletarse, Jenkins envía a modo de alerta un correo electrónico al autordel trabajo avisando del error adjuntando un extracto de la salida de consoladel comando de compilación con el mensaje de error ocurrido.

Si la compilación ha sido exitosa, se realiza la ejecución de los tests unitariosy se guarda el registro del resultado de ejecución. También realiza informesde cobertura de código que permiten al desarrollador un mejor análisis dela calidad de los tests.

El autor, consultando en cualquier momento el portal web del servidor Jen-kins puede seguir la evolución del proyecto y analizar los factores a mejorar.Como referencia, en la figura 3.3 se muestra una captura de pantalla del por-tal de acceso de Jenkins junto con el resultado de la compilación y ejecuciónde parte de los tests implementados.

FIGURA 3.3: Portal de acceso de Jenkins

14 Capítulo 3. Diseño e Implementación

3.2. Librería esc/pos

El ESC/P es un lenguaje para control de impresoras matriciales creado por Epson,y es ampliamente utilizado por otros fabricantes. Es un lenguaje simple, robustoy eficiente que permite utilizar una impresora matricial haciendo uso de todas lasfunciones predefinidas en fábrica[4].

El nombre ESC/P, también denominado Escape/P tiene su origen en el primer decarácter de las primeras implementaciones del protocolo, el valor ASCII 27 quecorresponde a la tecla Esc. A medida que se fue popularizando, fueron surgiendovariantes del mismo como ESC/P J84 soportando características de computado-ras japonesas, ESC/P2 como versión mejorada de ESC/P, ESC/P-R utilizándoseen varios modelos de impresoras Epson y ESC/POS como la especialización enimpresoras de recibo o factura que se usan típicamente en puntos de venta (POS,Points Of Sale).

El conjunto de comandos es muy extenso, y típicamente cada modelo de impre-sora suministra un listado de los comandos que soporta. Debido a las distintascaracterísticas de las impresoras algunos de los comandos pueden o no estar in-cluidos en la implementación del firmware de las distintas impresoras.

Mediante el uso de comandos ESC/POS se permite implementar complejos méto-dos de comunicación entre impresora y equipo controlador. Mientras que lo máshabitual es que el equipo al que se conecta la impresora empiece la comunicaciónexiste la posibilidad de ordenar a la impresora que, por ejemplo, mande cual-quier cambio en su estado (falta de papel, tapa abierta...) de manera instantánea.Sin embargo, ésta inmediatez en la comunicación se sacrifica por simplicidad enel diseño y se ha tomado como referencia un modelo de comunicación maestro-esclavo donde es el maestro quien en cualquier interacción envía comando a laimpresora y espera su respuesta. Este esquema se muestra en la figura 3.4.

FIGURA 3.4: Modelo Maestro-Esclavo de comunicación con la im-presora

Además de la impresora Bematech, TecnoAcción SA suministra otras impresorasde distintos fabricantes como Epson o Custom, por lo que el autor del trabajoha tomado en consideración los comandos más comunes entre los tres modelos.De esta manera se intentó conseguir la máxima compatibilidad para favorecer undesarrollo futuro lo más sencillo posible si se desease integrar otros modelos.

3.2. Librería esc/pos 15

En la Tabla 3.1 se muestra un resumen del subconjunto de comandos ESC/POSutilizados en este proyecto. Cada uno de los comandos está formado por carac-teres fijos, y otros que dependen del efecto deseado en la impresora. El formatoe información de estos comandos son de libre acceso en el manual de usuario dela impresora[3], por lo que la explicación detallada de cada uno de ellos no seconsidera relevante en esta memoria.

TABLA 3.1: Listado de comandos ESC/POS utilizados

Nombre del Efecto en Codificación encomando la impresora hexadecimal

GS F9h 5 n Selección de modo de 1D F9 35operación de la impresora

ESC J n Realiza un line feed 1B 4A n

GS F9h + n Configura la intensidad de impresión 1D F9 2B n

ESC m Realiza un corte parcial 1B 6D

GS F9h + n Fija la intensidad de impresión 1D F9 2B n

ESC c 5 n Deshabilita los botones del frontal 1B 63 35 n

GS L nL nH Fija el margen izquierdo 1D 4C nL nH

GS F8h 1 Petición de estado de la impresora 1D F8 31(formato extendido)

GS a n Habilitación/deshabilitación de 1D 61 ninforme automático de cambio de estado

GS v 0 m xL xH Impresion de un raster de bits 1D 76 30 m xL xHyL yH d1 ... dk yL yH d1 ... dk

GS F8h F Reset de la impresora 1D F8 46

Además de razones de compatibilidad con otras impresoras, la elección de loscomandos se basa en la operativa de la impresora en este trabajo. La imagen arecibir por la misma tiene un formato raw, por lo que no son necesarias muchasconsideraciones de dimensiones, geometría y control de la cabecera del archivoa imprimir como se deberían tener en cuenta en casos de imágenes en formatoprestablecido, por ejemplo bmp o png.

Por otro lado, pese a que no existe una comunicación bidireccional real entre elequipo que manda la impresión y el sistema embebido, es necesario controlar elestado de la impresora para realizar la impresión sólo cuando la impresora estéen un estado correcto. Esto se consigue mediante el uso de peticiones de estadoperiódicas para monitorizar el estado de la misma.

Desde el punto de vista del código de programación, toda la librería de coman-dos está contenida en un archivo header al que tiene acceso el hilo que manejala impresora. Respecto al contenido de ese archivo, se ha llegado a un compro-miso entre la versatilidad de los comandos y el caso de uso real en este trabajo.Para una mejor comprensión de este equilibrio se va a pasar a explicar un casoconcreto.

16 Capítulo 3. Diseño e Implementación

Si se consultan manuales de comandos ESC/POS se puede encontrar el formatodel comando de impresión de raster de bits:

GS v 0 m xL xH yL yH d1 ... dk

En este comando, GS v 0 sería la cabecera del comando en sí, y el resto de los ca-racteres dependen de las prestaciones de la impresora (m, densidad de impresiónen puntos por pulgada)y de la imagen a imprimir (xL xH yL yH son relativos a lasdimensiones de la imagen y d1 ... dk son los datos de la imagen a imprimir).

1 // Line feed2 s t a t i c unsigned char PRN_CMD_LINE_FEED[ ] =3 {4 0x1B , 0x4A , 0x305 } ;6

7 // P e t i c i o n del estado extendido a l a impresora8 s t a t i c unsigned char PRN_CMD_EXT_STATUS[ ] =9 {

10 0x1D , 0xF8 , 0x3111 } ;12

13 // Reset SW de l a impresora14 s t a t i c unsigned char PRN_RESET[ ] =15 {16 0x1d , 0xF8 , 0x7617 } ;18

19 // comando de impresion en formato r a s t e r20 s t a t i c unsigned char PRN_RASTER_PRINT[ ] =21 {22 0x1d , 0 x76 , 0 x30 ,23 0x3024 } ;

CODIGO DE PROGRAMA 3.1: Fragmento del listado de comandosESC/POS en el código

En la captura de Código de programa 3.1 se puede observar el comando inclui-do en el archivo de la librería, y cómo se ha sustituido directamente el valor dedensidad óptimo para la impresora según la documentación que suministra elfabricante (mcon valor de 0, que corresponde a 203 puntos por pulgada tanto envertical como horizontal).

3.3. Comunicaciones

El sistema embebido se comunica con el entorno mediante dos protocolos de co-municación. La interfaz con la impresora es un conector USB 2.0 que permite unaconexión fiable y con un ancho de banda más que suficiente para la informaciónque intercambia con esta aplicación. Las imágenes a imprimir llegan por la inter-faz WiFi a través de un driver integrado en el sistema operativo instalado en elsistema embebido.

A continuación se muestran las características de la implementación y las API(Application Programming Interface) que se utilizaron en cada uno de los casos. Nose va a entrar en detalles, quedando el código como referencia para consultas.

3.3. Comunicaciones 17

Comunicaciones USB

La comunicación USB con la impresora se basa en la API libusb versión1.0. Libusb en una librería open source que permite la comunicación con dis-positivos USB desde user space[6]. La aplicación desarrollada se basa en lainterfaz síncrona de libusb, resultando en una implementación más simplede la comunicación a costa de perder características más potentes pero pres-cindibles en este trabajo. La comunicación entre el programa y la impresorase puede resumir en tres pasos principales:

En primer lugar el programa realiza la identificación de la impresora y secomprueba el estado de la comunicación. Mediante el uso de las funcionesde la API libusb se inicializa la librería, se busca el dispositivo entre todaslas interfaces USB y se realiza la apertura de la interfaz con el dispositivo.A partir de este punto existe comunicación con la impresora.

A continuación, con la comunicación con la impresora ya está establecida,el sistema embebido envía la configuración de la impresora (tipo de coman-dos a utilizar, densidad de impresión...). Una vez configurada, el sistemaembebido monitoriza la impresora pidiendo el estado de manera periódicay envía la imagen a imprimir en el caso de que hubiese alguna disponible.

En ultimo lugar, si en algún momento falla la comunicación con la impre-sora (por desconexión, apagado u otro motivo), se pide un reset mediantesoftware a la impresora y se reconfigura (si el fallo indica que la interfazestá ocupada cuando no debería estarlo) o se libera la interfaz y dispositivoen libusb, y se vuelve a inicializar volviendo al paso inicial.

En la figura 3.5 se puede observar este comportamiento:

FIGURA 3.5: Máquina de estados de la comunicación con la im-presora

Comunicación WiFi

Para cumplir las funciones de sistema operativo se decidió la instalación deuna distribución ligera de Linux basada en Ubuntu Xenial[1]. De entre to-das las posibilidades open source se eligió una distribución desarrollada porArmbian[2] por el reducido espacio en disco que ocupa y porque la relativaantigüedad de la misma la hace más estable (y con los bugs existentes biendocumentados) que otras opciones existentes en el mercado.

18 Capítulo 3. Diseño e Implementación

Armbian suministra toda una variedad de distribuciones para cada uno delos sistemas embebidos de la familia OrangePi, resultando una distribuciónestable y fiable para la OrangePi Pc Plus utilizada.

Desde el punto de la aplicación desarrollada, la comunicación WiFi es to-talmente independiente. Mediante la configuración del sistema operativodurante el arranque, se enciende el módem y se abre la interfaz WiFi. Acontinuación se registra en la red WiFi disponible a tal efecto y toma unaIP dinámica (si existe un servidor DHCP en la red) o una configurada demanera estática.

Este trabajo no incluye el desarrollo del sistema de envío de imágenes, porlo que a nivel funcional el envío de las imágenes a imprimir se realiza me-diante el uso de protocolo SCP (Secure Copy Protocol) autentificándose elemisor. Por ejemplo, con nombre de archivo y una IP arbitrarios:

scp image2print root@192.168.0.2:/home/root/

La aplicación se encarga por sí misma de monitorizar la carpeta /home/root/en busca de nuevos archivos recibidos. El resto de la aplicación manejarálos mismos y los enviará a imprimir. Si una impresión termina con éxito, serealiza el borrado de la imagen para controlar el espacio en disco usado.

3.4. Integración del sistema

En esta sección se muestra como se compuso el sistema final integrando los com-ponentes previamente desarrollados por separado. El código desarrollado se pue-de encontrar en la web en un repositorio de GitHub[5].

El diagrama con la solución desarrollada se muestra en la figura 3.6.

FIGURA 3.6: Esquema general de la solución integrada

La aplicación se basa en un unico programa que lanza un hilo para manejar laimpresora. El programa principal crea las condiciones de inicialización y el me-canismo de sincronización programa principal-hilo, y por último, el hilo que secomunica con la impresora.

A continuación se explican y muestran las caraterísticas más relevantes de cadauno de los elementos para obtener una vision global de la funcionalidad conse-guida:

Programa principal.

3.4. Integración del sistema 19

El programa principal genera un entorno controlado para la ejecución delresto de tareas. Crea la cola de mensajes, lanza el hilo de control de la im-presora y queda en un bucle continuo (inotify_loop()) de monitorización dela carpeta definida como RUTA IMPRESION en el archivo main.h.

La monitorización se realiza mediante las herramientas de la API inotifyperteneciente a Linux. En el bucle se realiza una vigilancia de archivos quehan sido abiertos y cerrados tras haber modificado su contenido. De estamanera se consigue un alerta de existencia de nuevo archivo en la carpeta,pero se evita el acceso prematuro al archivo al mismo mientras esta siendoescrito. Con este mecanismo se consigue que la monitorización de la carpetadonde se añaden las imágenes sea tan sencilla como realizar la lectura de unarchivo.

Cuando se detecta el nuevo archivo, se genera un evento con datos del mis-mo. El bucle lee el nombre del archivo entre los detalles del evento y realizados acciones. En primer lugar registra el archivo en una tabla como referen-cia y a continuación avisa al hilo que maneja la impresora de que existe unarchivo a imprimir.

El programa principal lleva un registro de los archivos que se han recibidoconformado por la ruta del archivo y un número de referencia. De esta ma-nera se evita una saturación del sistema (demasiadas imágenes pendientesde imprimir) y se tiene un recurso útil si se quisiese realizar medidas derendimiento en el futuro.

Una vez se ha anotado la nueva imagen en el registro, el programa principalutiliza la cola de mensajería para avisar al hilo de control de la impresorade la existencia del archivo.

Posteriormente, y de manera cíclica, va revisando si el hilo de control dela impresora ha terminado de imprimir algún archivo para eliminarlo delregistro.

Cola de mensajes.

La comunicación entre el programa principal y el hilo de control de la im-presora se ha implementado mediante una cola de mensajería entre todaslas herramientas IPC (inter-process-communication) disponibles en un siste-ma Linux. Este mecanismo es un método sencillo para el intercambio deinformación reducida de manera asíncrona.

La creción de la cola se realiza mediante un archivo llamado msg_key quesirve como clave de acceso a la misma. De esta manera se consigue que otrosprocesos o puedan acceder a la cola de mensajería que utiliza el aplicativo.

El intercambio de información implica dos tipos de mensajes con una es-tructura común. Los detalles de la implementación se puede observar en elfragmento 3.2 de código de programa de msg_types.h.

1 //Tipos de mensajes2 # def ine HOST2PRINTER_PRINTER_REQ 23 # def ine PRINTER2HOST_PRINT_RESULT 54

5 s t r u c t msgbuf {6 long mtype ;7 s t r u c t msg_info {

20 Capítulo 3. Diseño e Implementación

8 char mresult ; //Resultado de l a operacion : ERR_OK todo fuebien

9 char mfi le_ index ; // Referenc ia del archivo en e l r e g i s t r o10 char mfile_name [NAME_LENGTH] ; // Nombre de archivo , d i r e c c i o n11 } i n f o ;12 } ;

CODIGO DE PROGRAMA 3.2: .Estructura y tipos de losmensajes de intercomunicación programa principal-hilo de

impresora"

Cada mensaje esta compuesto por su tipo mtype y una estrucura de datoscon el nombre del archivo mfile_name, el índice correspondiente al registroque mantiene el programa principal mfile_index y el resultado de la opera-ción mresult.

Existen dos tipos de mensaje:

HOST2PRINTER_PRINTER_REQ: Indica que el programa principal ha de-tectado una imagen a imprimir. Este mensaje tendrá el campo mresult a unvalor inicializado y mfile_index con el subindice del registro del programaprincipal. Tiene como origen programa principal y como destino el hilo dela impresora.

PRINTER2HOST_PRINT_REQ: Indica que la impresión del archivo dadopor mfile_name y mfile_index ha terminado con un resultado cargado en mre-sult. Tiene como origen el hilo de la impresora y como destino el programaprincipal.

Hilo de control de la impresora.

Desde el programa principal se lanza un hilo que se encarga de realizartodas las tareas relativas a la impresora. La rutina del hilo se llama prin-ter_handler().

El hilo se encarga de referenciar la cola de mensajería para manejar la co-municación con el programa principal y a continuación se encarga de lagestión de la impresora. En la figura 3.7 se muestra el flujo de control de laimpresora.

FIGURA 3.7: Flujo de trabajo del hilo de la impresora

3.4. Integración del sistema 21

El objetivo del hilo de control de la impresora es la monitorización del es-tado de la misma de manera continua. Y si el estado es correcto, verificar siexisten imagenes pendientes de impresión. A continuación se explica cadauno de los estados del diagrama mostrado en la figura 3.7:

• Inicialización de la impresora.

En primer lugar se debe realizar la apertura de la comunicación con laimpresora. Mediante la API libusb se consigue configurar la interfazUSB siguiendo las pautas recomendadas en su documentación [6].

Una vez existe comunicación efectiva con la impresora, se pasa a con-figurar el modo de operación para que utilice comandos ESC/POS es-tándar, deshabilitar el envío automático de cambio de estado para queno interfiera con el funcionamiento del aplicativo y por último se fijala impresión a nivel máximo de intensidad.

• Petición del estado a la impresora.

Se realiza una petición a la impresora para que reporte su estado. Serealiza mediante la función prn_get_status() en el archivo bema.c.En fun-ción de la información que se recibe de la impresora se pasa un códigode estado de la misma. Es una tarea que se ejecuta periódicamente.

• Reset de la impresora.

Si el estado de la impresora es erróneo pero no hay problemas de co-municacion con la misma, se pide un reset de software a la impresora.De esta manera se pretende conseguir salir del estado de error.

A continuación se pide otra vez el estado a la impresora.

• Comprobación si hay archivo a imprimir. Impresión del archivo.

Si el estado de la impresora es correcto, se puede comprobar si hayimagenes pendientes de escribir. Realiza una lectura en la cola de men-sajería buscando mensajes de tipo HOST2PRINTER_PRINTER_REQ ysi existe alguno imprime la imagen a la que apunta. Una vez terminala impresión envía un mensaje de vuelta con los mismos campos peromarcando el resultado de la operación en mresult y modificando el tipodel mismo a PRINTER2HOST_PRINT_REQ

Tras realizar la impresión se vuelve a pedir el estado a la impresorapara volver a evaluar el mismo.

• Cierre de la interfaz USB. Se reinicializa la interfaz.

Si la impresora ha devuelto un error grave (impresora offline o desco-nectada) o falla la comunicación con la misma el hilo cierra el interfazdel dispositivo USB y vuelve a intentar inicializar la misma.

23

Capítulo 4

Ensayos y Resultados

En este capítulo se da una visión global a las pruebas y los resultados obtenidoscon el sistema implementado. En la primera sección se explican los test unitariosque se han realizado y la cobertura de los mismos en el sistema desarrollado. En lasegunda sección se listan las pruebas realizadas de intercomunicación entre hilos,impresora y el equipo que envía la imagen que se quiere imprimir. En tercer lugar,se muestra un resumen de las pruebas de impresión, comparando las imagenesen formato digital y las impresiones resultantes.

4.1. Test unitarios

En programación, un test unitario es una forma de comprobar el correcto fun-cionamiento de una unidad de código. El término unidad puede referirse a unmétodo, una función o una clase. Mediante un test unitario se comprueba que launidad funciona correctamente y eficientemente por separado. La idea de los testunitarios no es garantizar el funcionamiento de un sistema al completo, si no decada una de sus partes de manera independiente.

Suponiendo que se quiera testear una función, un test unitario útil comprueba nosólo el funcionamiento de la misma, si no que comprueba también nombre y tipode sus parámetros y valor de retorno.

Los test unitarios implementados se centraron en la comprobación del funcio-namiento de las funciones más importantes desarrolladas. Pese a que no se rea-lizaron muchos tests se buscó comprobar los puntos más críticos del sistema. Lainclusión de mayor número e incrementar su alcance puede ser interesante y que-da como una posible tarea futura. Mediante el uso de CMock en el entorno deCeedling se pudieron realizar funciones mock para simular el comportamientode otras funciones de otras capas con dependencias con el objeto de test.

Para la generación y ejecución de los tests se necesitó modificar el archivo de con-figuración del proyecto para tener en cuenta las particularidades del mismo. Losflags de ejecución, compilación y las rutas de las librerías a enlazar se muestranen el fragmento de código 4.1.

1 : cmock :2 : mock_prefix : mock_3 : when_no_prototypes : : warn4 : e n f o r c e _ s t r i c t _ o r d e r i n g : TRUE5 : when_ptr : : compare_ptr6 : plugins :7 − : ignore

24 Capítulo 4. Ensayos y Resultados

8 − : c a l l b a c k9 : t r e a t _ a s :

10 uint8 : HEX811 uint16 : HEX1612 uint32 : UINT3213 i n t 8 : INT814 bool : UINT815 : mock_path : bui ld/mocks16 : inc ludes :17 − bema . h18 − usb_comm . h19 − e r r o r . h20 − /usr/include/l ibusb −1.0/ l i b u s b . h

CODIGO DE PROGRAMA 4.1: Configuración de CMock

Todos los test unitarios están incluidos en la carpeta test del proyecto. Los archi-vos que los contienen tienen extensión .c y se nombran en función del archivoal que pertenece la función a testear. Por ejemplo: las pruebas de las funcionesexistentes en bema.c se encuentran en el archivo test_bema.c.

En el fragmento de código de programa 4.2 se muestra como ejemplo la estructurade uno de los tests.

1 # include "mock_usb_comm . h"2

3 void setUp ( ) {4

5 memset(&bema_status , 0 , s i z e o f ( bema_status ) ) ;6 bema_status . t ime_status_change=time (NULL) +1000; // Se fuerza que no se

pida e s t a t u s a l a p r i n t e r en e l t e s t7

8 }9

10 void tearDown ( ) {11

12 }13

14 /∗∗ Se comprueba que l a funcion que devuelve e l estado de l a p r i n t e r enfuncion de su e s t r u c t u r a de e s t a t u s es c o r r e c t a .

15 ∗ Tambien se resuelven l a s pr ior idades ent re e r r o r e s .16 ∗/17 void t e s t _ p r n _ g e t _ s t a t u s _ d e v u e l v e _ e l _ e r r o r _ c o r r e c t o ( ) {18 i n t 1 6 _ t r e t ;19 p r i n t f ( " t e s t _ p r n _ g e t _ s t a t u s _ d e v u e l v e _ e l _ e r r o r _ c o r r e c t o \n" ) ;20 r e t = prn_get_s ta tus ( ) ;21 TEST_ASSERT_EQUAL_INT16 ( re t , ERR_OK) ;22

23 bema_status . busy =1;24 r e t = prn_get_s ta tus ( ) ;25 TEST_ASSERT_EQUAL_INT16 ( re t , ERR_PRN_BUSY) ;26

27 bema_status . e r r o r _ r =1;28 r e t = prn_get_s ta tus ( ) ;29 TEST_ASSERT_EQUAL_INT16 ( re t , ERR_PRN_ERROR_R) ;30

31 bema_status . e r ror_ur =1;32 r e t = prn_get_s ta tus ( ) ;33 TEST_ASSERT_EQUAL_INT16 ( re t , ERR_PRN_ERROR_UR) ;34

35 bema_status . e r r o r _ c u t t e r =1;36 r e t = prn_get_s ta tus ( ) ;

4.1. Test unitarios 25

37 TEST_ASSERT_EQUAL_INT16 ( re t , ERR_PRN_CUTTER) ;38

39 bema_status . no_paper =1;40 r e t = prn_get_s ta tus ( ) ;41 TEST_ASSERT_EQUAL_INT16 ( re t , ERR_PRN_NO_PAPER) ;42

43 bema_status . prn_opened =1;44 r e t = prn_get_s ta tus ( ) ;45 TEST_ASSERT_EQUAL_INT16 ( re t , ERR_PRN_COVER) ;46

47 bema_status . o f f l i n e =1;48 r e t = prn_get_s ta tus ( ) ;49 TEST_ASSERT_EQUAL_INT16 ( re t , ERR_PRN_OFFLINE) ;50

51 bema_status . not_plugged =1;52 r e t = prn_get_s ta tus ( ) ;53 TEST_ASSERT_EQUAL_INT16 ( re t , ERR_PRN_PLUG) ;54 }

CODIGO DE PROGRAMA 4.2: Ejemplo de test unitario

En primer lugar, se realizan las inicializaciones necesarias en la función setUp().En este caso se carga una variable global del proyecto (bema_status) con un valorde inicialización 0.

En cuanto a la función de test, se busca que le nombre sea lo más explícita y des-criptiva posible a costa incluso de que la longitud del nombre sea excesiva. Eneste caso la función test_prn_get_status_devuelve_el_error_correcto compruebaque la función interpreta bien la estructura bema_status de la impresora y de-vuelve el valor de retorno esperado.

En el interior del test se pueden ver las comprobaciones que se realizan. Por ejem-plo TEST_ASSERT_EQUAL_INT16 (ret, ERR_PRN_ERROR_UR) comprueba queel valor ret y el definido como ERR_PRN_ERROR_UR coinciden, tomando comotipo de dato entero de 16 bits. Si se cumplen todas las comprobaciones dentro deun test se considera que el mismo se ha pasado con éxito.

Con el uso de mocking se puede conseguir testear funcionalidades del códigoindependizando el mismo de otras API o funciones externas. En el fragmento decódigo de programa 4.3 se puede ver su uso con una función perteneciente a laAPI libusb.

1 /∗∗2 ∗ Se comprueba que l a funcion usb_comm_send devuelve e l va lor de

retorno esperado3 ∗/4 void test_usb_comm_send_devuelve_el_error_correcto ( ) {5 i n t 3 2 _ t r e t ;6 u i n t 1 6 _ t s i z e =4;7 unsigned char data [ s i z e ] ;8

9 // caso ok , pero l ibusb_bulk t r a n s f e r no devuelve e l va lor de datosenviados

10 l ibusb_bulk_transfer_IgnoreAndReturn ( 0 ) ;11 r e t =usb_comm_send ( data , s i z e ) ;12 TEST_ASSERT_EQUAL_INT32 ( 0 , r e t ) ;13

14 // casos nok15 l ibusb_bulk_transfer_IgnoreAndReturn ( 1 ) ;16 r e t =usb_comm_send ( data , s i z e ) ;

26 Capítulo 4. Ensayos y Resultados

17 TEST_ASSERT_EQUAL_INT32 ( 1 , r e t ) ;18

19 l ibusb_bulk_transfer_IgnoreAndReturn (−3) ; // F a l l o desde LIBUSB20 r e t =usb_comm_send ( data , s i z e ) ;21 TEST_ASSERT_EQUAL_INT32 (−3 , r e t ) ;22 }

CODIGO DE PROGRAMA 4.3: Ejemplo de test unitario y mocking

En el código, libusb_bulk_transfer_IgnoreAndReturn(0) es una función mock delibusb_bulk_transfer que es ignorada (no se llama a la ejecución de la funciónreal) y devuelve un valor de retorno de 0. En el resto de funciones mock que apa-recen en el fragmento 4.3 , libusb_bulk_transfer_IgnoreAndReturn(1) y la fun-ción libusb_bulk_transfer_IgnoreAndReturn(-3) tienen un comportamiento simi-lar salvo el valor de retorno, que es 1 y -3 respectivamente.

4.2. Pruebas de comunicación

Mientras que los test unitarios comprueban y dan fiabilidad a las funciones decódigo a pequeña escala, no cubrían las necesidades para el sistema de comuni-cación y el sistema completo. Con el sistema integrado completamente, se reali-zaron distintas pruebas parciales y globales:

Recepción de imagen incompleta.

Preparación: Se utiliza el aplicativo final. Se añade un software especial queinterrumpe periódicamente la comunicación WiFi del sistema embebido.

Ejecución: Se lanza el aplicativo y el software especial. Se envía una imagendesde una computadora en la red WiFi mediante un comando scp. Se obser-va que el comando falla y no aparece la imagen en la carpeta de impresióny por lo tanto no se imprime nada.

Resultado: Pasa la prueba.

Sincronización mediante la cola de mensajería.

Preparación: Se utiliza el aplicativo final.

Ejecución: Se cambia el contenido del archivo msg_key entre ejecuciones deaplicativo.

Resultado: Pasa la prueba.

Prueba de envío de imagen al sistema embebido.

Preparación: Se modifica el sistema eliminando la parte de control de la im-presora. Se sustituye la función de manejo de la impresora por una funciónque no realice ninguna operación en un bucle infinito. Se monitoriza la colade mensajería.

Ejecución: Se lanza el aplicativo y se verifica que la cola de mensajería. Seenvía una imagen al sistema embebido a la carpeta designada. Se comprue-ba el estado de la cola de mensajería. Se envía otra imagen al sistema embe-bido. Se comprueba de nuevo el estado de la cola de mensajería.

4.2. Pruebas de comunicación 27

Resultado: Pasa la prueba. Tras lanzar el aplicativo la cola de mensajería notiene ningún mensaje. Tras enviar la primera imagen aparece un mensajecon datos correctos. Tras enviar la segunda imagen aparece otro mensaje enla cola de mensajería.

Recepción de mensajes por parte del hilo de la impresora.

Preparación: Se modifica el aplicativo evitando que el hilo principal saquemensajes de la cola de mensajería. Se envía una imagen y se verifica el esta-do de la cola de mensajería. Se abre la tapa de la impresora y se envía otraimagen. Se verifica el estado de la cola de nuevo

Ejecución: Se envía una imagen, se observa que la impresión es correcta y severifica que existe un mensaje en la cola enviado por el hilo de la impresoraindicando que la imagen ha sido impresa correctamente. Se abre la tapa dela impresora y se envía otra imagen. En este caso el mensaje de la cola indicaque la impresión no se ha realizado correctamente.

Resultado: Pasa la prueba.

Eliminación de imágenes impresas.

Preparación: Se utiliza el aplicativo final.

Ejecución: Se envía una imagen, y una vez se ha realizado la impresión co-rrectamente se comprueba que la imagen ha sido borrada de la carpeta.

Resultado: Pasa la prueba.

Prueba de límite de número de imágenes.

Preparación: Se utiliza el aplicativo final.

Ejecución: Se lanza el aplicativo y se apaga la impresora para que no serealicen impresiones. Se envían más imágenes que el límite del aplicativo(20). Se observa que las imágenes adicionales son eliminadas del disco.

Resultado: Pasa la prueba. Una vez existen 20 imagenes en la carpeta deimpresión, las adcionales son eliminadas por el aplicativo.

Verificación de estado de la impresora 1.

Preparación: Se utiliza el aplicativo final.

Ejecución: Se abre la tapa de la impresora. Se envía una imagen. Se cierra latapa de la impresora. Verificar por la salida de programa que no se realiza elreset de la impresora, no se vuelve a inicializar la interfaz mediante libsuby que se reporta estado de tapa abierta.

Resultado: Pasa la prueba. La impresión queda encolada en la cola de men-sajes hasta que la impresora está operativa. Una vez está disponible se rea-liza la impresión. Por la salida del programa se muestra que no se mandael reset a la impresora y se pide su estado en bucle de manera indefinida(reportándose la tapa abierta) hasta que se cierra la tapa.

Verificación de estado de la impresora 2.

Preparación: Se utiliza el aplicativo final.

28 Capítulo 4. Ensayos y Resultados

Ejecución: Se abre la tapa de la impresora y se saca el papel. Se envía unaimagen. Se cierra la tapa la impresora. Verificar por la salida de programaque no se realiza el reset de la impresora y no se vuelve a inicializar la inter-faz mediante libsub. Se verifica que la impresora indica que no tiene papel.Se abre la tapa, se añade el papel y se cierra la tapa.

Resultado: Pasa la prueba. La impresión queda encolada en la cola de men-sajes hasta que la impresora está operativa. Una vez está disponible se rea-liza la impresión. Por la salida del programa se muestra que no se manda elreset a la impresora ni se inicializa de nuevo y se pide su estado en bucle demanera indefinida (reportándose falta de papel y/o tapa abierta) hasta quese añade papel y cierra la tapa.

Desconexión de la impresora 1.

Preparación: Se utiliza el aplicativo final.

Ejecución: Se desconecta la impresora mientras el aplicativo se ejecuta. Seenvía una imagen. Se conecta la impresora.

Resultado: Pasa la prueba. La impresión queda encolada en la cola de men-sajes hasta que la impresora está operativa. Una vez está disponible se rea-liza la impresión.

Desconexión de la impresora 2.

Preparación: Se utiliza el aplicativo final.

Ejecución: Se desconecta la impresora y se lanza aplicativo. Se envía unaimagen. Se conecta la impresora.

Resultado: Pasa la prueba. La impresión queda encolada en la cola de men-sajes hasta que la impresora está operativa. Una vez está disponible se rea-liza la impresión.

Impresión de una imagen

Preparación: Se utiliza el aplicativo final.

Ejecución: Se lanza el aplicativo. Se envía una imagen. Se verifica el estadode la cola de mensajería y estado de la imagen.

Resultado: Pasa la prueba. La impresión se realiza correctamente y la colaqueda vacía. El archivo de imagen es borrado por el aplicativo.

Impresión de dos imagenes

Preparación: Se utiliza el aplicativo final.

Ejecución: Se lanza el aplicativo. Se envía dos imagenes a la vez. Se verificael estado de la cola de mensajería y estado de la imagenes.

Resultado: Pasa la prueba. Las impresiones se realizan correctamente y lacola queda vacía. Los archivos de imagen son borrados por el aplicativo.

4.3. Pruebas de impresión 29

4.3. Pruebas de impresión

La impresora que integra este sistema es un modelo de impresora térmica. Estoes, realiza la impresión mediante la elevación de temperatura de los cabezales y lapuesta contacto de los mismos con papel termosensible que toma una tonalidadnegra al someterse a una temperatura determinada.

La verificación física de las impresiones realizadas era un punto necesario paraverificar la del sistema. Dada la naturaleza física de la impresión se realizaroncomparaciones visuales de la imagen impresa y la misma realizada en una im-presora láser doméstica.

Se realizaron distintas impresiones de cupones de juego y logos e iconos de juegosde lotería y se comprobó que la impresión era correcta.

Para el estudio más detallado de las impresiones se utilizó una una plantilla deimpresión utilizada por TecnoAcción SA y se pasó a verificar manualmente conmicroscopio y aumento 3x de varios puntos de transición blanco/negro tomadosal azar. La plantilla se muestra en la figura 4.1, mientras que la figura 4.2 incluyeuna fotografía la misma plantilla impresa.

FIGURA 4.1: Plantilla de pruebas

Mediante la verificación de las imágenes se comprobó, como es razonable, que lacalidad de la impresión laser es muy superior a la de la impresora térmica, peroque la resolución conseguida en el sistema era la esperada.

30 Capítulo 4. Ensayos y Resultados

FIGURA 4.2: Impresión de la plantilla de pruebas

31

Capítulo 5

Conclusiones

En este capítulo se realiza un resumen de los objetivos conseguidos.

5.1. Trabajo realizado

Durante la ejecución de este proyecto se han alcanzado los objetivos planteadosinicialmente:

Se consiguió un aplicación que funcionase como bridge Wifi-USB de unaimpresora Bematech MP4200 y permitiese la impresión de imágenes en for-mato raw.

Se creó un set reducido de test unitarios que permiten comprobar el funcio-namiento del código escrito.

Se logró una puesta en práctica de herramientas de trabajo como la automa-tización de compilación, ejecución de tests y reporte de resultados. Adicio-nalmente se adquirieron y pusieron en práctica conocimientos adquiridosen la Carrera de Especializacion en Sistema Embebidos.

En consecuencia, se lograron los principales objetivos propuestos para este traba-jo.

5.2. Próximos pasos

Tras los resultados obtenidos, se listan una serie de mejoras que se pueden reali-zar para incrementar la funcionalidad del trabajo realizado:

Se puede incrementar la funcionalidad del bridge, añadiendo más opcionesde configuración y operatoria con la impresora actual.

Añadir el soporte para otros modelos de impresora.

Implementar soporte para impresión de archivos en formato de bitmap.

Implementar el servicio de envío de imágenes a imprimir.

33

Bibliografía

[1] Armbian. Armbian Ubuntu Desktop - Legacy Kernel. URL: https://dl.armbian.com/orangepipcplus/Ubuntu_xenial_default_desktop.7z.

[2] Armbian. Armbian web page. URL: https://www.armbian.com/.[3] Bematech. Bematech mp4200 user manual April 2010 (First Edition: April 2010).

URL: https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=http://bematechus.com/wp-content/uploads/2016/01/MP4200TH_english_user-manual.pdf.

[4] EPSON. EPSON Webpage. URL: https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=2.

[5] jocrespo. URL del respositorio. URL:https://github.com/jocrespo/bema_wifi.

[6] libusb. libusb API web page. URL:http://libusb.sourceforge.net/api-1.0/index.html.