Plataforma de emulación de hardware para sistemas …laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-MSE-Agustin-Bassi-2018.pdfabierto para facilitar el aprendizaje de programación

UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE MAESTRÍA EN SISTEMAS EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Plataforma de emulación de hardwarepara sistemas embebidos

Autor:Esp. Lic. Juan Agustín Bassi

Director:Dr. Ing. Pablo Martín Gomez (FIUBA)

Jurados:Mg. Ing. Diego Javier Brengi (UNLaM, INTI)

Mg. Ing. Facundo Santiago Larosa (UTN-FRH, FIUBA)Ing. Juan Manuel Cruz (FIUBA, UTN-FRBA)

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entre enerode 2018 y diciembre de 2018.

III

Resumen

Esta memoria describe el desarrollo de ViHard, una plataforma de códigoabierto para facilitar el aprendizaje de programación de sistemas embebidos.

Consta de un programa de PC que emula dispositivos de hardware de maneravirtual y que se comunica con el sistema embebido mediante un puerto

USB-Serie. De esta forma, el sistema embebido actúa sobre hardware virtual quees emulado en la PC, lo que permite a los principiantes focalizarse en aprenderlas técnicas de programación sin preocuparse por el conexionado del hardware,

y a los programadores avanzados probar distintos diseños sin necesidad decontar con el hardware implementado.

El desarrollo se realizó en un marco de trabajo ordenado metodológicamente yutilizando herramientas para versionado de código, priorización de tareas,

trazabilidad de requisitos, análisis de código y técnicas de testing para sistemasembebidos.

V

Agradecimientos

Al director de este trabajo, Dr. Ing. Pablo Martín Gomez.

VII

Índice general

Resumen III

1. Introducción General 11.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Descripción técnica-conceptual . . . . . . . . . . . . . . . . . . . . . 21.3. Caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4. Propósito y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Introducción Específica 72.1. Principio de funcionamiento de ViHard . . . . . . . . . . . . . . . . 72.2. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1. Listado de requerimientos . . . . . . . . . . . . . . . . . . . . 92.3. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1. Desglose del trabajo en tareas . . . . . . . . . . . . . . . . . . 112.3.2. Diagrama Activity On-Node . . . . . . . . . . . . . . . . . . 132.3.3. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . 15

3. Diseño e Implementación 173.1. Tecnologías y herramientas utilizadas . . . . . . . . . . . . . . . . . 17

3.1.1. Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.2. Gitkraken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.3. NodeJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.4. ElectronJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.5. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.6. EDU-CIAA-NXP . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2. Diseño de la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.1. Definición de periféricos virtuales . . . . . . . . . . . . . . . 193.2.2. Mapa de periféricos virtuales . . . . . . . . . . . . . . . . . . 193.2.3. Definición de las funciones de acceso a hardware virtual . . 203.2.4. Protocolo de comunicación . . . . . . . . . . . . . . . . . . . 21

3.3. Aplicación de escritorio . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.1. Orden del directorio . . . . . . . . . . . . . . . . . . . . . . . 243.3.2. Visualización de la aplicación . . . . . . . . . . . . . . . . . . 253.3.3. Diseño de la interfaz gráfica de usuario . . . . . . . . . . . . 263.3.4. Programación de la aplicación . . . . . . . . . . . . . . . . . 28

Archivo JavaScript “index.js” . . . . . . . . . . . . . . . . . . 29Archivo JavaScript “periphericals.js” . . . . . . . . . . . . . . 29Archivo JavaScript “source_code.js” . . . . . . . . . . . . . . 31

3.4. Biblioteca de código embebida . . . . . . . . . . . . . . . . . . . . . 323.4.1. Convenciones adoptadas . . . . . . . . . . . . . . . . . . . . 323.4.2. Pruebas unitarias de firmware . . . . . . . . . . . . . . . . . 333.4.3. Detalles de la biblioteca . . . . . . . . . . . . . . . . . . . . . 373.4.4. Documentación en formato Doxygen . . . . . . . . . . . . . 40

VIII

3.5. Ejemplos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.6. Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.6.1. Matriz de trazabilidad de requerimientos . . . . . . . . . . . 423.6.2. Uso de la plataforma . . . . . . . . . . . . . . . . . . . . . . . 43

4. Ensayos y Resultados 454.1. Tiempos de ejecución de comandos virtuales . . . . . . . . . . . . . 454.2. Documentación HTML de Doxygen . . . . . . . . . . . . . . . . . . 474.3. Resultados de unit testing sobre firmware . . . . . . . . . . . . . . . 484.4. Porting del firmware a diferentes arquitecturas . . . . . . . . . . . . 514.5. Análisis estático de firmware con SonarCloud . . . . . . . . . . . . 524.6. Demostración de caso de uso . . . . . . . . . . . . . . . . . . . . . . 55

5. Conclusiones 595.1. Trabajo realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Bibliografía 61

IX

Índice de figuras

1.1. Esquema de la plataforma ViHard. . . . . . . . . . . . . . . . . . . . 3

2.1. Esquema de funcionamiento detallado de ViHard. . . . . . . . . . . 82.2. Diagrama Activity On-Node. . . . . . . . . . . . . . . . . . . . . . . 142.3. Diagrama de Gantt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1. Directorio de trabajo de aplicación de escritorio. . . . . . . . . . . . 253.2. Pestañas principales de la aplicación. . . . . . . . . . . . . . . . . . . 263.3. Panel de conexiones de la aplicación. . . . . . . . . . . . . . . . . . . 263.4. Organización de periféricos virtuales. . . . . . . . . . . . . . . . . . 263.5. Visualización de la pestaña “Firmware Embebido”. . . . . . . . . . 273.6. Visualización de la pestaña “Información”. . . . . . . . . . . . . . . 283.7. Diagrama de flujo del programa de PC. . . . . . . . . . . . . . . . . 313.8. Matriz de trazabilidad de requisitos. . . . . . . . . . . . . . . . . . . 42

4.1. Documentacion HTML a partir de Doxygen. . . . . . . . . . . . . . 474.2. Resultados de pruebas unitarias parte 1. . . . . . . . . . . . . . . . . 494.3. Resultados de pruebas unitarias parte 2. . . . . . . . . . . . . . . . . 504.4. Resultados de pruebas unitarias parte 2. . . . . . . . . . . . . . . . . 504.5. Métricas de firmware en SonarCloud. . . . . . . . . . . . . . . . . . 524.6. Métricas específicas de cada archivo de código. . . . . . . . . . . . . 534.7. Sugerencias de refactorización realizadas por SonarCloud. . . . . . 534.8. Visualización de las mejoras aplicadas al código. . . . . . . . . . . . 544.9. Potenciómetro conectado a EDU-CIAA-NXP. . . . . . . . . . . . . . 554.10. Programa de PC ViHard mostrando valor ADC. . . . . . . . . . . . 57

XI

Índice de Tablas

2.1. Desglose del trabajo en tareas. . . . . . . . . . . . . . . . . . . . . . . 12

3.1. Mapa de periféricos virtuales. . . . . . . . . . . . . . . . . . . . . . . 203.2. Funciones de acceso al hardware virtual. . . . . . . . . . . . . . . . 203.3. Caracteres de control del protocolo. . . . . . . . . . . . . . . . . . . . 213.4. Valores ASCII de comandos de hardware virtual. . . . . . . . . . . . 223.5. Valores ASCII de los periféricos virtuales. . . . . . . . . . . . . . . . 223.6. Comandos de escritura y lectura. . . . . . . . . . . . . . . . . . . . . 233.7. Ejemplos de comandos de escritura. . . . . . . . . . . . . . . . . . . 233.8. Ejemplos de comandos de lectura. . . . . . . . . . . . . . . . . . . . 243.9. Requisitos específicos de firmware. . . . . . . . . . . . . . . . . . . . 333.10. Pruebas unitarias de firmware. . . . . . . . . . . . . . . . . . . . . . 343.11. Requisitos de firmware vs. pruebas unitarias. . . . . . . . . . . . . . 34

4.1. Tiempos de ejecución de comandos virtuales . . . . . . . . . . . . . 46

1

Capítulo 1

Introducción General

En este capítulo se exponen las problemáticas observadas que originaron el desa-rrollo del presente trabajo, junto con una breve descripción de la plataforma pro-puesta para solucionarlas.

1.1. Motivación

En la enseñanza de programación de sistemas embebidos la curva inicial de apren-dizaje resulta muy difícil para los principiantes. Esto en parte se debe a que eldesarrollo está compuesto por distintas áreas involucradas, entre las que se en-cuentran hardware, firmware y software. Para realizar desarrollos es necesariocontar con conocimientos en varios aspectos, principalmente en programaciónprocedural, electrónica, hardware, periféricos, microcontroladores, lenguaje deprogramación C, entre otros.

Uno de los mayores inconvenientes que se presenta al iniciarse con los sistemasembebidos son las conexiones con hardware, ya que para que funcione correcta-mente se deben respetar niveles de tensión, polarización, condiciones mínimas ymáximas, etc. A su vez, cuando el sistema no funciona, resulta muy difícil identi-ficar si el problema está asociado al hardware, como una pista en cortocircuito oun periférico dañado, o bien a una falla en la programación del firmware.

Con este panorama, y teniendo como objetivo expandir las fronteras de los siste-mas embebidos, se pensó en desarrollar una plataforma que emule dispositivosde hardware dentro de una aplicación de PC, trabajando en conjunto con unabiblioteca alojada en el sistema embebido.

De esta manera, los principiantes se pueden focalizar en aprender las técnicas deprogramación ejecutando sus algoritmos sobre el hardware emulado y dejandopara más adelante la implementación en el hardware real, ya que el traspaso serealiza de manera muy sencilla.

2 Capítulo 1. Introducción General

1.2. Descripción técnica-conceptual

En la figura 1.1 se observa una computadora en la cuál se ejecutan dos aplica-ciones. Por un lado, el programa para desarrollar el firmware embebido y porotro, la aplicación ViHard que contiene el hardware emulado de manera virtual.Los elementos de hardware emulados son pulsadores, LEDs, entradas y salidasanalógicas, display 7 segmentos y display LCD. El firmware en el sistema em-bebido contiene una biblioteca que mediante sus funciones permite controlar elhardware virtualizado en la PC a través de un puerto USB.

Se debe tener presente que la lógica de la aplicación se encuentra en el sistemaembebido. El software de PC únicamente provee el acceso al hardware de maneravirtual.

Otro detalle interesante es que no hay restricciones para realizar un programa queacceda paralelamente a hardware real y virtual. Por ejemplo, se podría desarrollarun firmware que lea el valor de un potenciómetro físico y muestre el valor leídoen el display LCD virtual, así como también crear un firmware que cuando sepresione un pulsador virtual se encienda un LED físico.

1.2. Descripción técnica-conceptual 3

FIGURA 1.1: Esquema de la plataforma ViHard, donde se apreciaal sistema embebido conectado con la PC para descargar el firm-ware a la vez que se conecta a la aplicación para interactuar con el

hardware virtual.

4 Capítulo 1. Introducción General

1.3. Caso de uso

Se supone que un desarrollador debe crear un algoritmo que, al presionar unpulsador, encienda un LED y al mismo tiempo informe en un display LCD si elLED está encendido o apagado.

Por el camino tradicional, deberá adquirir los componentes y conectarlos entresí a través de un hardware diseñado para tal fin o en una placa de prototipado.Luego de eso, deberá configurar adecuadamente el microcontrolador para queel hardware funcione; es decir, deberá configurar un puerto de entrada para elpulsador, un puerto de salida para el LED y puertos de entradas y salidas parael display LCD. Una vez realizados estos pasos, deberá realizar el algoritmo yprobar si cumple con el funcionamiento esperado.

Utilizando la plataforma ViHard, únicamente deberá cargar en el sistema embe-bido la biblioteca que provee el acceso al hardware virtual y en el firmware de suaplicación utilizar las funciones que la biblioteca provee para controlar el hard-ware virtualizado. El programa de PC contendrá elementos visuales que emu-larán pulsadores, LEDs y display LCD. El usuario pulsará un botón virtual enel software de PC, esa información le llegará al sistema embebido, y el sistemaembebido le enviará la orden a la aplicación que encienda el LED y a la vez queinforme el estado del LED en el Display LCD.

ViHard otorga la ventaja de que el desarrollador puede probar el algoritmo sinnecesidad de adquirir los componentes, conectarlos entre sí y, eventualmente,diseñar una placa de circuito impreso. De esta manera, se podrán realizar pruebasde algoritmos de manera muy rápida y prácticamente con los mismos resultados.

Por otro lado, es importante la flexibilidad que presenta una aplicación de soft-ware a la hora de cambiar su funcionamiento. Por ejemplo, se podrían agregarmás periféricos virtuales y que le lleguen al usuario como una actualización desoftware sin que esto represente un esfuerzo de conexionado para el desarrolla-dor.

En resumen, un principiante, tendrá la experiencia de relacionarse con un sistemaembebido con solo conectarlo a una PC mediante un puerto USB, liberando así elcamino de probar algoritmos de interacción con hardware de manera sencilla. Porsu parte, a un programador avanzado le permitirá realizar pruebas de conceptosin necesidad de contar con el hardware físico.

1.4. Propósito y alcance 5

1.4. Propósito y alcance

El principal objetivo fue desarrollar una plataforma de código abierto para fa-cilitar el aprendizaje y enseñanza de programación de sistemas embebidos quepueda ser adoptada por diversos agentes de enseñanza tales como escuelas téc-nicas, capacitaciones, carreras y cursos.

Se pensó como principal plataforma de hardware soportada a la EDU-CIAA-NXP,una de las placas Proyecto CIAA [1]. Se considera a la plataforma ViHard unaporte más a este proyecto libre y comunitario, por lo que se espera su adopcióncomo así también su apoyo en la difusión y presentación del proyecto.

El alcance del trabajo abarcó principalmente una planificación inicial, el desarro-llo de un programa de PC con hardware virtual, el desarrollo de una biblioteca defirmware que permite el acceso al hardware virtualizado, una serie de ejemplosque permiten demostrar su funcionamiento y una página web con la documenta-ción del proyecto.

7

Capítulo 2

Introducción Específica

En este capítulo se presenta una descripción detallada de ViHard, así como tam-bién las técnicas de gestión de proyectos aplicadas para llevar adelante el proyec-to.

2.1. Principio de funcionamiento de ViHard

La plataforma ViHard está compuesta por tres partes. Por un lado un progra-ma para PC que contiene el hardware emulado de manera virtual. Por otro lado,una biblioteca para el sistema embebido que, mediante los llamados a sus funcio-nes, permite controlar el hardware virtual. Este control es realizado mediante unprotocolo serial el cual se envía por el puerto USB. Por último, en el sistema em-bebido, además de la biblioteca para acceder al hardware virtual, se encuentra elprograma del usuario, es decir, la aplicación que desarrollará el programador pa-ra que el hardware virtual se comporte de la manera deseada. En la figura 2.1 seobserva un esquema en el que se describen las partes detalladas de la plataforma.

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

FIGURA 2.1: Esquema de funcionamiento detallado de la platafor-ma ViHard.

2.2. Requerimientos 9

2.2. Requerimientos

Los requerimientos del proyecto se dividieron en plantear un esquema de trabajo,investigar y definir la arquitectura de software, desarrollar la aplicación de PC,desarrollar la biblioteca de hardware virtual embebida, desarrollar ejemplos deuso y realizar documentación del proyecto. En la subsección 2.2.1 se describe cadagrupo de requerimientos.

2.2.1. Listado de requerimientos

Se deberá respetar un esquema de trabajo.

• Se deberá tener la información detallada del proyecto en directoriosdebidamente ordenados.

• Se deberá utilizar únicamente software libre para el desarrollo del pro-yecto.

• Se deberá versionar el proyecto en un repositorio Git y se utilizará lametodología de versionado Git Flow.

Se deberá investigar y definir la arquitectura del software.

• Se deberá investigar sobre plataforma de desarrollo Electron.

• Se deberá investigar sobre protocolos de comunicaciones seriales paraSistemas Embebidos.

• Se deberá investigar y documentar arquitectura de software para PC.

• Se deberá investigar y documentar arquitectura de software para elSistema Embebido.

• Se deberá investigar y documentar guía de estilo de código utilizadaen Lenguaje C.

Se deberá desarrollar la aplicación para PC.

• Se deberá desarrollar el programa con la plataforma Electron.

• Se deberá disponer de al menos 5 periféricos virtuales (pulsadores,LEDs, display 7 segmentos, potenciómetros, DAC, etc.).

• Se deberá conectar con el Sistema Embebido mediante comunicaciónserial.

• Se deberá elaborar documentación de uso de la plataforma.

• Se deberá integrar la documentación de uso dentro de la aplicación.

• Se deberá integrar el código fuente para el Sistema Embebido en laaplicación.

• Se deberá entregar una aplicación de escritorio para PC multiplatafor-ma.


Se deberá desarrollar la biblioteca embebida en lenguaje C.

• Se deberá respetar un estilo de código para toda la biblioteca.

• Se deberá aplicar test unitario a cada una de las funciones.

• Se deberá crear documentación en formato Doxygen o Markdown.

• Se deberá adaptar la biblioteca para soportar al menos 3 placas dedesarrollo.

Se deberán realizar ejemplos de uso.

• Se deberán realizar al menos 3 ejemplos de uso para cada plataformasoportada.

Se deberá entregar documentación del proyecto.

• Se deberá crear una matriz de trazabilidad de los requerimientos delproyecto.

• Se deberá elaborar un informe de avance del proyecto.

• Se deberá elaborar una memoria del proyecto.

• Se deberá elaborar una presentación de la memoria del proyecto.

• Se deberá presentar el proyecto públicamente.

2.3. Planificación 11

2.3. Planificación

La planificación del proyecto siguió los lineamientos y estrategias vistos en lasmaterias Gestión de Proyectos y Gestión de la Tecnología e Innovación. En estasubsección se describen en detalle.

2.3.1. Desglose del trabajo en tareas

Inicialmente, para definir objetivos concretos, se plantearon una serie de entrega-bles para el proyecto:

Aplicación para PC Linux/Windows.

Biblioteca de hardware virtual para al menos 3 placas de desarrollo.

Al menos 3 ejemplos de uso para cada plataforma soportada.

Documentación técnica del proyecto.

• Página web para utilización de la plataforma.

• Matriz de trazabilidad de requerimientos.

• Documentación de biblioteca embebida en formato Doxygen.

Documentación formal del proyecto.

• Informe de avance del proyecto.

• Memoria del proyecto.

• Presentación de memoria del proyecto.

Posteriormente, se procedió al diseño de una lista para desglosar el trabajo en ta-reas concretas. Se estimó un tiempo aproximado de 594 horas/hombre las cualesson detalladas en la tabla 2.1.


TABLA 2.1: Desglose del trabajo en tareas.

Tarea Horas/Hombre

Preparar el entorno de trabajo -— Crear estructura de directorios 2— Instalar las herramientas y programas necesarios 24— Estudiar metodología de versionado Git Flow 8— Crear repositorio Git 2Investigar y definir arquitectura de software -— Investigar sobre el desarrollo de aplicaciones Electron para PC 24— Investigar protocolos de comunicación seriales para Sistemas Embebidos 16— Investigar y documentar arquitectura de software para PC 12— Investigar y documentar arquitectura de software Sistema Embebido 16— Investigar y documentar guías de estilos de código en Lenguaje C 12Desarrollar la aplicación para PC -— Programar la interfaz de usuario en HTML y CSS 48— Programar el funcionamiento de la aplicación en Electron/NodeJS 60— Elaborar documentación de uso de la plataforma 30— Integrar la documentación de uso dentro de la aplicación 10— Integrar el firmware para el Sistema Embebido dentro de la aplicación 8— Empaquetar el programa para Linux y Windows 16Desarrollar biblioteca embebida sobre plataforma CIAA -— Codificar biblioteca en C 100— Aplicar test unitario a cada función 30— Crear documentación con Doxygen o Markdown 6— Crear programa de prueba para cada módulo de la biblioteca 10Realizar ejemplos de uso para las diferentes plataformas soportadas -— Crear programas de ejemplos para plataforma CIAA 24— Migrar ejemplos creados hacia las demás plataformas 8Crear documentación del proyecto -— Elaborar y corregir informe de avance del proyecto 16— Elaborar matriz de trazabilidad de requerimientos 16— Elaborar y corregir memoria del proyecto 80— Elaborar y corregir presentación del proyecto 16—————————————————————————————— —-Total horas/hombre 594


2.3.2. Diagrama Activity On-Node

Con el listado de tareas descripto en la sección 2.3.1, se evaluaron las dependen-cias de cada una de ellas y se creó el diagrama Activity On-Node. En la figura 2.2se pueden observar las tareas propuestas junto con el tiempo estimado en horasde cada una. Todas las flechas entrantes a un nodo son las dependencias de lamisma.

Es de interés notar cómo, luego que se definieron las tareas 2.4 a 2.6, se podríahaber realizado en paralelo el trabajo de desarrollar el programa de PC y desa-rrollar la biblioteca embebida de hardware virtual. Con esta planificación, y conmás de una persona para trabajar en el proyecto, la paralelización del trabajo ha-bría alcanzado aproximadamente 162 horas.


FIGURA 2.2: Diagrama Activity On-Node.


2.3.3. Diagrama de Gantt

Luego de la creación del diagrama Activity On-Node descripto en la subsección2.3.2, se establecieron las horas de trabajo semanales que se podían destinar alproyecto, y posteriormente se plantearon fechas concretas para iniciar las activi-dades. Con este trabajo realizado se elaboró el diagrama de Gantt el cual permitetener una referencia rápida del estado de avance del proyecto para cada momen-to. Este último es mostrado en la figura 2.3.

FIGURA 2.3: Diagrama de Gantt.

17

Capítulo 3

Diseño e Implementación

En este capítulo se muestran las herramientas utilizadas, la definición de la arqui-tectura la plataforma, el desarrollo de software y firmware y su documentación.

3.1. Tecnologías y herramientas utilizadas

Para llevar adelante el desarrollo del proyecto se utilizaron diversas herramientasy tecnologías, todas de libre distribución, que son descriptas en esta sección.

3.1.1. Trello

Para gestionar la priorización y seguimiento de las tareas se utilizó Trello [2],un tablero interactivo y digital accesible desde múltiples dispositivos y siempresincronizado.

Un tablero de Trello es básicamente una página web que contiene listas dispues-tas de manera horizontal de modo que se puede apreciar de un vistazo todas lastareas del proyecto. Los ítems dentro de las listas, llamados cards, pueden arras-trarse y soltarse en otras listas o reordenarse.

3.1.2. Gitkraken

Gitkraken [3] es una potente y elegante interfaz gráfica multiplataforma para Gitdesarrollada con ElectronJS. De forma muy sencilla permite llevar el completoseguimiento de repositorios, ver ramas, tags, crear nuevos, todo el historial detrabajo, commits, etcétera.

3.1.3. NodeJS

NodeJS [4] es un entorno en tiempo de ejecución multiplataforma, de códigoabierto, basado en el lenguaje de programación ECMAScript, asíncrono, con I/Ode datos en una arquitectura orientada a eventos. Fue creado con el enfoque deser útil en la creación de programas altamente escalables, como por ejemplo, ser-vidores web.

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

3.1.4. ElectronJS

ElectronJS [5] es una plataforma para desarrollar aplicaciones de escritorio multi-plataforma utilizando tecnologías web (HTML, CSS y JavaScript), creada y man-tenida por Github.

Funciona creando dos tipos de procesos, el proceso main y el proceso renderer.El primero es un proceso de NodeJS, viene a ser la aplicación en si misma, es-te proceso tiene acceso a varias APIs que ayudan a comunicarse con el sistemaoperativo y realizar distintas acciones o efectos.

El proceso renderer es un proceso de Chromium [6] con un motor de NodeJSincorporado. Por lo que desde el renderer se pueden utilizar módulos para leer yescribir en el disco, hacer peticiones a una base de datos directamente, etc.

3.1.5. Eclipse

Eclipse [7] es un IDE (entorno de desarrollo integrado) que permite realizar laprogramación y compilación de programas para múltiples lenguajes. Bajo su ex-tensión CDT permite realizar el desarrollo de programas escritos en lenguajeC/c++. Es una herramienta que se basa en el agregado de plugins para poten-ciar su funcionamiento, de esta manera, partiendo de una funcionalidad base sele pueden agregar módulos acordes a las necesidades del proyecto. Otro de losmotivos por lo que se utilizó esta herramienta es que provee un debugger quepermite correr el programa en la plataforma real de hardware teniendo controlsobre la ejecución del mismo, pudiendo parar/resumir el programa, analizar va-riables, stack, etc.

3.1.6. EDU-CIAA-NXP

Como principal placa de hardware soportada para el proyecto se optó por utilizarla EDU-CIAA-NXP. Esta es una de las placas del Proyecto CIAA [1], un proyec-to libre centrado en el trabajo colaborativo que busca la innovación para crear,diseñar y desarrollar soluciones electrónicas en la industria.

Se utilizó esta plataforma por ser un proyecto de código abierto, poseer una sólidacomunidad de desarrolladores e incentivar la industria nacional.

3.2. Diseño de la arquitectura 19

3.2. Diseño de la arquitectura

Previo a realizar el desarrollo del programa de PC y el firmware para el sistemaembebido, se realizó el diseño de la arquitectura que es detallado en esta sección.

3.2.1. Definición de periféricos virtuales

Según la lista de requerimientos planteada en la subsección 2.2.1, la plataformadebía proveer acceso a al menos 5 periféricos virtuales. Los periféricos que sedecidieron emular fueron:

LEDs.

Pulsadores.

Entradas analógicas.

Salidas analógicas.

Display LCD.

Display 7 segmentos.

3.2.2. Mapa de periféricos virtuales

A partir de la decisión de los periféricos a emular, así como también inspirándoseen la placa EDU-CIAA-NXP que posee como hardware externo 4 LEDs y 4 pul-sadores, se estableció el mapa de periféricos virtuales que es descripto en la tabla3.1. El prefijo ’VH_’ proviene de ViHard.


TABLA 3.1: Mapa de periféricos virtuales.

Nombre del periférico Tipo del periférico

VH_LEDR LEDVH_LEDG LEDVH_LEDB LEDVH_LED1 LEDVH_LED2 LEDVH_LED3 LEDVH_LED4 LED- -VH_TEC1 PULSADORVH_TEC2 PULSADORVH_TEC3 PULSADORVH_TEC4 PULSADOR- -VH_ADC_CH1 ENTRADA ANALÓGICA- -VH_DAC_CH1 SALIDA ANALÓGICA- -VH_LCD1 DISPLAY LCD- -VH_7SEG DISPLAY 7 SEGMENTOS

3.2.3. Definición de las funciones de acceso a hardware virtual

Con los periféricos virtuales ya definidos se establecieron las funciones que la pla-taforma debía ofrecer al usuario para acceder al hardware virtual. Tales funcionesestán detalladas en la tabla 3.2.

TABLA 3.2: Funciones de acceso al hardware virtual.

Nombre de la función Tipo de la función

GPIO_READ Entrada/Salida digital de propósito generalGPIO_WRITE Entrada/Salida digital de propósito general- -ADC_READ Entrada/Salida analógicaDAC_WRITE Entrada/Salida analógica- -LCD_WRITE_BYTE Escritura display LCDLCD_WRITE_STRING Escritura display LCD- -7SEG_WRITE Escritura display 7 segmentos


3.2.4. Protocolo de comunicación

Con los periféricos virtuales y las funciones de acceso al hardware virtual ya de-finidas, se desarrolló el protocolo de comunicación entre el sistema embebido yla aplicación. La premisa fue que debía ser un protocolo serial.

Se realizó una investigación sobre el estado del arte y se determinó que exis-ten dos corrientes principales: utilizar un protocolo estándar de mercado -ya seaXML, YML o JSON-, o utilizar un protocolo ad-hoc.

Si bien todo el desarrollo del proyecto se basó en metodologías y herramientasestándar, en este caso, utilizar un protocolo ya definido requería que en el siste-ma embebido se deba implementar un parser, es decir, una biblioteca capaz decodificar y decodificar los mensajes del protocolo.

Como el propósito del proyecto es que se utilice con microcontroladores, sobre-cargar el código de usuario con una biblioteca de esta índole se consideró ungasto de memoria innecesario por lo que se estableció un protocolo ad-hoc.

Otro de los motivos por los que se desarrolló un protocolo a medida fue que ellargo de los mensajes podía reducirse a la mínima expresión y de esta maneratransmitirlos entre la aplicación y el sistema embebido en el menor tiempo posi-ble.

Para establecer el protocolo se utilizaron algunos mecanismos bien conocidos enla industria, tales como carácter de inicio y fin de trama y separadores de coman-dos. La tabla 3.3 muestra los caracteres de control del protocolo.

TABLA 3.3: Caracteres de control del protocolo.

Carácter de control ASCII que lo representa

COMMAND_INIT {COMMAND_END }COMMAND_SEPARATOR ;

El intercambio de mensajes entre el programa de PC y la biblioteca en el sistemaembebido requirió que a cada comando de acceso al hardware virtual y a cada pe-riférico virtual se le asigne un valor. La tabla 3.4 muestra el valor establecido paralos comandos mientras que la tabla 3.5 muestra el valor asignado a los periféricosvirtuales.


TABLA 3.4: Valores ASCII de los comandos de acceso al hardwarevirtual.

Comando ASCII que lo representa

COMMAND_GPIO_READ aCOMMAND_GPIO_WRITE b- -COMMAND_ADC_READ cCOMMAND_DAC_WRITE d- -COMMAND_LCD_WRITE_BYTE eCOMMAND_LCD_WRITE_STRING f- -COMMAND_7SEG_WRITE g

TABLA 3.5: Valores ASCII de los periféricos virtuales.

Periférico virtual ASCII que lo representa

VH_LEDR aVH_LEDG bVH_LEDB cVH_LED1 dVH_LED2 eVH_LED3 fVH_LED4 g- -VH_TEC1 hVH_TEC2 iVH_TEC3 jVH_TEC4 k- -VH_ADC_CH1 l- -VH_DAC_CH1 m- -VH_LCD1 n- -VH_7SEG o


Los comandos fueron separados en grupos de escritura y de lectura que son de-tallados en la tabla 3.6.

TABLA 3.6: Comandos de escritura y lectura.

Comandos de escritura Comandos de lectura

GPIO_WRITE GPIO_READDAC_WRITE ADC_READLCD_WRITE_BYTELCD_WRITE_STRING7SEG_WRITE

Los comandos de escritura únicamente envían datos desde el sistema embebidohacia la aplicación de PC. En este caso, el esquema de protocolo planteado fue elsiguiente:

{command;peripherical;value}

Los comandos de lectura, deben enviar un mensaje al programa en la computado-ra para consultar el estado del periférico y luego esperar la respuesta para recibirel estado. Este esquema, conocido como request/response [8], llevó a que se leasigne el valor ASCII ‘0’ para identificar un request y el valor ASCII ‘1’ para iden-tificar un response. De este modo, la representación de un comando de lecturaquedó establecida de la siguiente manera:

{command;peripherical;request}{command;peripherical;response;value}

El punto final para establecer el protocolo fue escribir algunos ejemplos de co-mandos reales para poder copiar y pegar el texto en las futuras pruebas que sefueron realizando. La tabla 3.7 muestra ejemplos de comandos de escritura, mien-tras que la tabla 3.8 muestra ejemplos de comandos de lectura.

TABLA 3.7: Ejemplos de tramas seriales de comandos de escritura.

Caso de comando de escritura Trama serial a enviar

Escribir en VH_LED2 el valor 1 {b;e;1}Escribir en VH_DAC1 el valor 128 {d;n;128}Escribir en VH_LCD1 el byte ‘f’ {e;o;f}Escribir en VH_LCD1 la cadena “Hola” {f;o;Hola}Escribir en VH_7SEG el número 3 {g;p;3}


TABLA 3.8: Ejemplos de tramas seriales de comandos de lectura.

Caso de comando de lectura Trama Tipo

Leer el estado de VH_TEC1. El sistema embebido pregunta el {a;0;g} Requestestado y la aplicación de PC responde que esta en ‘1’ {a;1;g;1} Response- -Leer el valor de VH_CH1.El sistema embebido pregunta el {c;0;k} Requestestado y la aplicación de PC responde que el valor es 184 {c;1;k;184} Response

3.3. Aplicación de escritorio

Para realizar la aplicación de escritorio se utilizó la tecnología ElectronJS [5]. Esteframework que se implementa sobre NodeJS [4] permite crear aplicaciones deescritorio para múltiples sistemas operativos mediante el uso de tecnologías web(JavaScript, CSS y HTML).

Los motivos por el cual se eligió ElectronJS para realizar la aplicación fueron:

Tiene una comunidad muy grande de desarrolladores.

Posee muy buena documentación.

Hay claros ejemplos de que la tecnología funciona correctamente (aplicacio-nes como Atom, Visual Studio Code o Gitkraken lo demuestran).

El programa se desarrolla una única vez y se despliega en múltiples arqui-tecturas (develop once, deploy everywhere).

Es una tecnología en crecimiento.

Las aplicaciones gráficas representan un gran complemento para visualizary controlar sistemas embebidos.

3.3.1. Orden del directorio

Trabajar con ElectronJS hizo que se ordenara de una manera determinada el di-rectorio de trabajo. Esta forma permitió separar el código fuente (HTML y Ja-vaScript) de los estilos de la aplicación (CSS), así como también ofreció un lugardonde alojar los tipos de letras, imágenes, logos, archivos extras y los archivos ydirectorios necesarios para la distribución de la aplicación. La figura 3.1 muestrael directorio ‘electron‘ con sus subcarpetas y archivos.

3.3. Aplicación de escritorio 25

FIGURA 3.1: Directorio de trabajo de aplicación de escritorio.

3.3.2. Visualización de la aplicación

Para desarrollar la aplicación de escritorio se comenzó con la creación de los dibu-jos de los componentes electrónicos virtuales y algunos componentes adicionalessiguiendo las recomendaciones de la metodología de desarrollo web.

Los dibujos fueron creados con el programa Inkscape [9], una herramienta de di-bujo libre y multiplataforma. El propósito de hacerlo con este programa fue quepermite exportar los dibujos en formato SVG (gráficos vectoriales). Este tipo deformato hace que la imagen no se deforme bajo ningún tipo de resolución de pan-talla. Pensando que la aplicación puede ejecutarse en una resolución mínima de1024x600 hasta en una resolución de 4K, se consideró éste el formato más adecua-do.

El siguiente paso fue seleccionar los tipos de letra para la aplicación. La páginaDaFont [10] contiene miles de tipografías disponibles para descargar de mane-ra libre y gratuita. Pensando en realizar la aplicación lo más realista posible, sedescargaron los tipos de letras correspondientes a display LCD, 7 segmentos y laletra que es generalmente utilizada en la serigrafía de los circuitos impresos.

Trabajar con tecnologías web hizo muy sencillo el trabajo de incluir estas tipogra-fías, así como también las imágenes de los componentes.


3.3.3. Diseño de la interfaz gráfica de usuario

La premisa fue que la aplicación debía ser minimalista y fácil de utilizar. Esta con-dición llevó a diseñar el layout y navegación en tres pestañas que son mostradasen la figura 3.2.

FIGURA 3.2: Pestañas principales de la aplicación.

La pestaña “Periféricos virtuales”, además de contener los componentes de hard-ware, contiene el panel de control de conexión con el sistema embebido, en el cualse puede seleccionar el puerto, la velocidad de conexión, recargar la lista de puer-tos disponibles y el switch para realizar la conexión/desconexión con el sistemaembebido. La figura 3.3 muestra el panel de control de conexión.

FIGURA 3.3: Panel de conexiones de la aplicación.

La organización de los periféricos virtuales dentro de la aplicación se realizó demanera similar a cómo se organizaría dentro de un circuito impreso real. La figura3.4 muestra la organización de los mismos.

FIGURA 3.4: Organización de periféricos virtuales.

La pestaña “Firmware embebido” contiene la biblioteca de código embebida ViHardjunto con un programa de ejemplo que se debe cargar en el sistema embebido pa-ra poder controlar el hardware virtual. La utilización de HTML y CSS hizo quesea muy sencillo la creación de subpestañas para visualizar el código fuente.


Si bien el firmware no estaba realizado en este punto del desarrollo, lo que sehizo fue que el programa muestre cualquier archivo fuente .c y .h y luego, almomento de completar el firmware, únicamente hubo que mostrar los archivoscorrespondientes. La figura 3.5 demuestra la visualización del firmware dentrode la aplicación.

FIGURA 3.5: Visualización de la pestaña “Firmware Embebido”.

Otro punto interesante es que para ponerle estilo al firmware, es decir, para queresalten en diferentes colores las palabras reservadas del lenguaje C, se utilizó laherramienta online hilite [11], la cual, a partir del código fuente en C lo puedeconvertir a código HTML con la sintaxis resaltada para el lenguaje en cuestión.

Por último, la pestaña “Información” contiene una breve descripción de la pla-taforma. Es lo que se puede encontrar en la opción “About” o “Acerca de” en lamayoría de los programas de escritorio. Si bien esta información puede resultartrivial, lo importante es que desde esta pestaña se puede acceder a la informaciónonline de la plataforma con las últimas actualizaciones.

La figura 3.6 muestra la breve descripción de la plataforma así como también losenlaces directos a la documentación online, el repositorio oficial y el foro oficial.Cada link se abre en una pestaña nueva del navegador por defecto del sistema.


FIGURA 3.6: Visualización de la pestaña “Información”.

3.3.4. Programación de la aplicación

La programación de la aplicación se realizó en lenguaje JavaScript. La misma fuerealizada una vez que la interfaz de usuario estuvo prácticamente terminada.

Una aplicación de ElectronJS debe tener un archivo llamado “main.js”. En esteproceso se realizan las tareas elementales que se necesitan para crear la aplica-ción de escritorio. El framework ElectronJS provee este archivo ya que es comúna todas las aplicaciones. La única porción de código que se le agregó fueron fun-ciones para obtener el ancho y alto de la resolución de pantalla del sistema, deesta manera, se sabe de que tamaño se debe crear la ventana de escritorio.

Además del archivo indicado anteriormente, se crearon tres archivos JavaScriptque realizan las tareas propias de la aplicación y que son descriptos en las si-guientes subsecciones.


Archivo JavaScript “index.js”

Es el archivo invocado desde main.js. Contiene la aplicación en sí.

En este archivo se carga el HTML inicial que contiene el título de la aplicación,las pestañas de navegación y el footer o pie.

También se realiza la carga de los demás archivos HTML que van dentro de cadapestaña del programa, es decir el código HTML correspondiente a:

Periféricos virtuales

Firmware embebido

Información

Como se mencionó en la subsección 3.3.2, los dibujos de la aplicación se realizaronen formato SVG, esto permite escalarlos a cualquier tamaño sin perder calidad deimagen.

Cuando el programa inicia y se obtiene la resolución de pantalla del sistema, seaplica un zoom sobre la aplicación, que puede ser positivo o negativo, para queel tamaño de los objetos en pantalla quede siempre acorde a la resolución.

Como la plataforma ViHard está orientada a la educación, y siendo las compu-tadoras del programa Conectar Igualdad [12] las más comunes entre los estudian-tes, la resolución típica de la aplicación está adaptada a esta pantalla que, en lamayoría de los casos, es de 1024x600 píxeles.

El factor de zoom que se aplica es un valor empírico que se adapta a las resolu-ciones más generales de pantalla. Para eso, se investigaron cuales son las resolu-ciones más típicas de los monitores de PC [13].

Archivo JavaScript “periphericals.js”

En este archivo se encuentra el corazón de la aplicación, desde donde se adminis-tra la conexión con el sistema embebido, el manejo del protocolo de comunicacióny el estado de los periféricos virtuales.

Si bien es un solo archivo, se trató de aplicar una división por capas en la cual sepueden distinguir:

Capa lógica: Desde esta capa se toman las decisiones de más alto nivel delprograma haciendo uso de las funciones de las capas inferiores.

Capa API: Desde esta capa se manejan funciones de la capa de driver ytambién generando una entrada o salida significativa para la capa superior.

Capa driver: Principalmente se acceden a funciones del puerto serie del sis-tema a nivel de driver, así como también al manejo de la consola de NodeJSpara realizar log.


La convención de estilo que se aplicó para nombrar sus componentes fueron:

Constantes: Mayúscula separados por guión bajo.Ej: const COMMAND_SEPARATOR = ’;’;

Variables globales: UpperCammelCase.Ej: let BaudRateSelected = 0;

Variables locales: lowerCammelCase.Ej: let isConnected = false;

Funciones: Prefijo de la capa a la que pertenece y separado por un guiónbajo su funcionalidad.Ej: function Api_SerialTryToListPorts(){...}

El código JavaScript funciona orientado a eventos que pueden ser:

Asincrónicos: Interacción del usuario con los componentes visuales o arribode datos por el puerto serie. No se puede predecir en qué momento van aocurrir.

Sincrónicos: Tareas periódicas mediante temporizadores, aprovechando losrecursos de los sistemas operativos multitarea.

Para manejar el estado de los elementos que representan los periféricos virtualesse utilizó una variable dedicada para cada uno.

La figura 3.7 muestra una descripción visual del diagrama de flujo del programa.Durante la inicialización se cargan todos los componentes del sistema. Cuandola aplicación y el sistema embebido están conectados, la aplicación espera recibircomandos provenientes del sistema embebido y ejecutar la acción requerida, porejemplo, encender un LED virtual.


FIGURA 3.7: Diagrama de flujo del programa de PC.

Archivo JavaScript “source_code.js”

En este archivo se presentan las funciones necesarias para cargar dentro del pro-grama de PC el código fuente de firmware, así como también la funcionalidadpara copiar al portapapeles del sistema los archivos de código fuente de firmwa-re mediante la pulsación de un botón.


3.4. Biblioteca de código embebida

El objetivo de la biblioteca de código embebida es proveer al usuario el acceso alhardware virtual que se encuentra en la PC. Con el propósito de ser utilizado fá-cilmente, el código de la biblioteca se basa únicamente en un archivo de cabecerallamado “vihard.h” y un archivo de código fuente llamado “vihard.c”.

Para permitir el acceso al hardware virtual, la tarea principal de la biblioteca esconvertir la llamada a una de sus funciones desde el código de usuario en un co-mando del protocolo de comunicación descripto en la subsección 3.2.4, y enviarlopor el puerto USB-Serie.

3.4.1. Convenciones adoptadas

Antes de comenzar la programación del código se establecieron las premisas prin-cipales que éste debía cumplir. Estas premisas surgieron de las recomendacionesadquiridas en las asignaturas Ingeniería de Software y en Certificación de Siste-mas Embebidos. Entre las principales características del código se encuentran:

Documentación de todas las funciones y variables en formato Doxygen.

Ancho máximo de línea fijado en 80 caracteres.

Uso de la biblioteca stdint, stdfloat y stdbool para manejo de tipos de datosuniversales entre los diferentes compiladores.

Inicialización previo a utilizar todas las variables.

Funciones con un único punto de retorno.

Utilización exclusiva de memoria estática.

Minimización del footprint de la biblioteca (reducción de uso de memoria).

Convención de nombres:

• Los nombres de constantes, variables y funciones deben tener un sig-nificado. Ej: Vh_LcdWriteString()

• Deben dar indicios de su tipo. Ej.: dataPtr, txBuff, ReadyFlag, sleep-Mod, timeCtr.

• Utilizar el nombre del módulo como parte del nombre de las fun-ciones del mismo. Ej.Módulo LCD (lcd.h, lcd.c) contiene: LCD_init(),LCD_PutString(), etc.

Utilizar mayúsculas o minúsculas para indicar el alcance del objeto.

• Constantes: MAX, MIN

• Variables locales: maxTemp, errorCnt

• Variables globales (privadas): MaxTemp, ErrorCnt

• Variables globales (públicas): DAC_MaxTemp, Network_ErrorCnt

• Funciones locales (privadas): ClearTime, InChar

• Funciones globales (públicas): Timer_ClearTime, Key_InChar

3.4. Biblioteca de código embebida 33

3.4.2. Pruebas unitarias de firmware

Con las convenciones del firmware establecidas, el siguiente paso fue implemen-tar la metodología TDD (test driven development o desarrollo guiado por prue-bas). Esta forma de trabajo, aprendida en la asignatura Testing para Sistemas Em-bebidos, sugiere comenzar el desarrollo escribiendo primero las pruebas y luegola codificación del software.

La idea del TDD es que los requisitos sean traducidos a pruebas, de este modo,cuando las pruebas pasen se garantizará que el software cumple con los requisitosque se han establecido.

Si bien los requisitos generales del proyecto fueron establecidos en la planifica-ción, como lo detalla la subsección 2.2.1, para utilizar TDD fue necesario crearrequisitos específicos del firmware, enumerados en la tabla 3.9.

TABLA 3.9: Requisitos específicos de firmware.

Requisito

1. El envío de una trama serial deberá terminar con el caracter NULL.2. Todas las funciones deberán devolver su estado de ejecución.3. Todos los LEDs deberán ser apagados al iniciar.4. El DAC deberá setearse en 0 al iniciar.5. El display LCD deberá setearse con un texto vacío al iniciar.6. El display 7 segmentos deberá setearse con el valor “-“ al iniciar.7. Deberá convertir la lectura del ADC virtual en un entero de 10 bits.8. El valor máximo que se podrá escribir en el DAC será un entero de 10 bits.9. La cantidad máxima de caracteres de una línea del LCD deberá ser 18.10. La cantidad máxima de caracteres multilínea del LCD deberá ser 53.

Con los requisitos establecidos, se idearon las pruebas unitarias que se debíanrealizar para comprobar que cada requisito fuera cumplido, y que son numeradasen la tabla 3.10.


TABLA 3.10: Pruebas unitarias de firmware.

Prueba unitaria

1. Chequear que el envío de cualquier comando termine con NULL.2. Enviar comandos con periféricos inválidos y chequear si retornan error.3. Enviar comandos con periféricos válidos y chequear si retornan OK.4. Chequear que al inicio los LEDs 1 a 4 sean puestos en 0.5. Chequear que al inicio el valor para el DAC sea 0.6. Chequear que al inicio el valor para el LCD este vacío.7. Chequear que al inicio el valor para el 7 segmentos sea “-“.8. Simular respuesta ACD >10 bits y chequear si acomoda su rango.9. Enviar valor DAC >10 bits y chequear si limita a valor dentro del rango.10. Enviar valor DAC <0 y chequear si limita a valor dentro del rango.11. Enviar cadena para línea del LCD >18 bytes y chequear si es truncada.12. Enviar cadena para multilínea del LCD >53 bytes y chequear si es truncada.

Como paso anterior al desarrollo de las pruebas, se creó una matriz de trazabili-dad de requisitos vs. pruebas unitarias a realizar, la cual es detallada en la tabla3.11. De este modo, cada requisito quedó asociado a una prueba en particular.

TABLA 3.11: Requisitos de firmware vs. pruebas unitarias. El pre-fijo “T“ significa de test y el prefijo “R“ significa requisito.

- T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12

R1 xR2 x xR3 xR4 xR5 xR6 xR7 xR8 x xR9 xR10 x


Para la implementación de pruebas unitarias se optó por utilizar minunit [14],una herramienta que sólo permite testear una condición booleana. Lo notablede la misma es que se compone de únicamente 3 líneas de código en forma deMACROS de Lenguaje C. Se consideró esta característica especialmente útil, yaque el uso de memoria sobre el microcontrolador es prácticamente despreciable.

Sobre esta simple biblioteca se realizaron algunas modificaciones para hacer suutilización más entendible. Todo el código correspondiente a la herramienta mi-nunit puede verse en el algoritmo 3.1, mientras que el algoritmo 3.2 muestra unejemplo de cómo utilizarla.

1 # i f n d e f _MIN_UNIT_H_2 # def ine _MIN_UNIT_H_3

4 # def ine MINUNIT_ASSERT( errorMessage , condit ionToEvaluate ) \5 do { \6 i f ( ! ( condit ionToEvaluate ) ) \7 re turn errorMessage ; \8 } while ( 0 )9

10 # def ine MINUNIT_RUN_TEST( funct ionToTest ) \11 do { \12 char ∗errorMessage = funct ionToTest ( ) ; \13 AmountTestsRun++; \14 i f ( errorMessage ) \15 re turn errorMessage ; \16 } while ( 0 )17

18 s t a t i c i n t AmountTestsRun = 0 ;19

20 i n t MinUnit_AmountTestsRun ( void ) {21 re turn AmountTestsRun ;22 }23

24 # endi f /∗ _MIN_UNIT_H_ ∗/

ALGORITMO 3.1: Código C de la herramienta de test minunit.


1 # include " sapi . h"2 # include " minunit . h "3

4 i n t FooVar = 7 ;5

6 s t a t i c char ∗ Test_Foo ( ) {7 MINUNIT_ASSERT( " error , foo != 7 " , FooVar == 7) ;8 re turn 0 ;9 }

10

11 s t a t i c char ∗ ExecuteAl lTes ts ( ) {12 MINUNIT_RUN_TEST( Test_Foo ) ;13 re turn 0 ;14 }15

16 i n t main ( void ) {17 char ∗ r e s u l t = ExecuteAl lTes ts ( ) ;18

19 i f ( r e s u l t != 0 ) {20 s t d i o P r i n t f ( " %s\n" , r e s u l t ) ;21 }22 e l s e {23 s t d i o P r i n t f ( "ALL TESTS PASSED\n" ) ;24 }25 s t d i o P r i n t f ( " Tes ts run : %d\n" , MinUnit_AmountTestsRun ( ) ) ;26

27 re turn 0 ;28 }

ALGORITMO 3.2: Ejemplo de uso de la herramienta de testminunit.

El último paso de utilizar la metodología TDD fue la limpieza del código de labiblioteca sin alterar su funcionamiento. Esta acción es conocida con el nombrede refactorización. El propósito es facilitar su mantenimiento, mejorar su facilidadde comprensión y eliminar código muerto. Se realizó la refactorización del códigouna vez que todos los test pasaron satisfactoriamente.


3.4.3. Detalles de la biblioteca

Para acceder al hardware virtual en la PC, la biblioteca expone al usuario unaserie de funciones que realizan el acceso de manera transparente sin que se debapreocupar por lo que ocurre debajo. El algoritmo 3.3 muestra las funciones ex-puestas al usuario para el acceso al hardware virtual. El prefijo “Vh_” provienede ViHard y es para identificar a las funciones específicas de esta biblioteca.

1 /∗============[ e x t e r n a l f u n c t i o n s d e c l a r a t i o n ]======================∗/2

3 VhError_t Vh_BoardConfig ( u i n t 3 2 _ t baudRate ) ;4

5 VhError_t Vh_GpioRead ( VhPeriph_t gpioPin , bool_ t ∗ pinValue ) ;6 VhError_t Vh_GpioWrite ( VhPeriph_t gpioPin , bool_ t p i n S t a t e ) ;7 VhError_t Vh_GpioToggle ( VhPeriph_t gpioPin ) ;8

9 VhError_t Vh_AdcRead ( VhPeriph_t adcCh , u i n t 1 6 _ t ∗ adcValue ) ;10 VhError_t Vh_DacWrite ( VhPeriph_t dacCh , u i n t 1 6 _ t dacValue ) ;11

12 VhError_t Vh_7SegsWrite ( VhPeriph_t d7Segs , u i n t 8 _ t asciiToShow ) ;13

14 VhError_t Vh_LcdWriteString ( VhPeriph_t dLcd , LcdLine_t l , char ∗ s t r ) ;

ALGORITMO 3.3: Funciones de la biblioteca de código embebida.

Además de las funciones, en el header de la biblioteca se encuentra el mapa deperiféricos virtuales, que se muestra en el algoritmo 3.4 en forma de un enum deLenguaje C. Este mapa de periféricos fue inspirado por el análogo utilizado enla biblioteca sAPI del firmware de la CIAA [15]. Así como en las funciones, losperiféricos virtuales tienen el prefijo “VH_” por ViHard.


1 /∗∗2 ∗ Mapa de p e r i f r i c o s v i r t u a l e s a l o s que se puede acceder .3 ∗/4 typedef enum _ViHardPeriph {5 // Valores corespondientes a l o s leds6 VH_LEDR = ’ a ’ , //! < VH_LEDR7 VH_LEDG = ’ b ’ , //! < VH_LEDG8 VH_LEDB = ’ z ’ , //! < VH_LEDB9 VH_LED1 = ’ c ’ , //! < VH_LED1

10 VH_LED2 = ’d ’ , //! < VH_LED211 VH_LED3 = ’ e ’ , //! < VH_LED312 VH_LED4 = ’ f ’ , //! < VH_LED413 // Valores corespondientes a l a s t e c l a s14 VH_TEC1 = ’ g ’ , //! < VH_TEC115 VH_TEC2 = ’h ’ , //! < VH_TEC216 VH_TEC3 = ’ i ’ , //! < VH_TEC317 VH_TEC4 = ’ j ’ , //! < VH_TEC418 // Valores coorespondientes a l o s pines ADC19 VH_ADC_CH1 = ’ k ’ , //! < VH_ADC_CH120 // Valores coorespondientes a l o s pines DAC21 VH_DAC_CH1 = ’n ’ , //! < VH_DAC_CH122 // Valores coorespondientes a l p e r i f r i c o LCD23 VH_LCD1 = ’ o ’ , //! < VH_LCD124 // Valores coorespondientes a l p e r i f r i c o 7 segmentos25 VH_7SEG = ’p ’ , //! < VH_7SEG26 } ViHardPeriph_t ;

ALGORITMO 3.4: Enumeración de Lenguaje C para los periféricosvirtuales.

Se consideró como la principal plataforma soportada por ViHard a la EDU-CIAA-NXP, pero con el propósito de ser altamente portable, la única dependencia quetiene para poder ejecutarse en otras arquitecturas son las funciones que manejanel puerto serie para configurar el puerto y velocidad determinados, la de escribirun byte y la de leer un byte. El resto del código es ANSI C [16] independiente dela plataforma.

Con la intención de realizar una rápida migración a otras plataformas, las funcio-nes que manejan el puerto serie fueron escritas como MACROS de Lenguaje C enel archivo “vihard.h” y que pueden ser reemplazadas fácilmente por el usuario.En el archivo “vihard.c” se hace uso del puerto serie a través de estas MACROS.El algoritmo 3.5 muestra, además de las MACROS del puerto serie, la única partedel código que se compila de manera condicional dependiendo de la plataforma.


1 # i f defined (BOARD_EDU_CIAA_NXP)2 // CONFIGURACIONES DEL MICROCONTROLADOR3 # def ine VIHARD_SERIAL_PORT UART_USB4 # def ine VIHARD_BAUDRATE 1152005 # def ine CLOCK_SPEED_MHZ 2046 // MACROS DEL PUERTO SERIE7 # def ine UART_CONFIG( baudrate ) \8 uartConfig (VIHARD_SERIAL_PORT, baudrate )9 # def ine UART_READ_BYTE( byteToRead ) \

10 uartReadByte (VIHARD_SERIAL_PORT, &byteToRead )11 # def ine UART_WRITE_BYTE( byteToWrite ) \12 uartWriteByte (VIHARD_SERIAL_PORT, ( u i n t 8 _ t ) byteToWrite )13

14 # e l i f defined (BOARD_CIAA_ZERO)15

16 // todo poner a c l a llamada c o r r e c t a17

18 # e l i f defined (BOARD_ARDUINO)19

20 // todo poner a c l a llamada c o r r e c t a21

22 # endi f

ALGORITMO 3.5: Compilación condicional del código C.

Como se puede notar en el algoritmo 3.5, las definiciones están realizadas para laBOARD_EDU_CIAA_NXP, pero el porting a las demás, como pueden serBOARD_CIAA_ZERO, BOARD_ARDUINO o cualquier otra, no requiere de ma-yor esfuerzo que copiar el código correspondiente a BOARD_EDU_CIAA_NXPy reemplazar el contenido para la plataforma en cuestión.


3.4.4. Documentación en formato Doxygen

El código de la biblioteca embebida fue totalmente documentado en formatoDoxygen [17]. El IDE utilizado para realizar la programación fue Eclipse [7]. Con-figurar como herramienta de documentación a Doxygen dentro de Eclipse haceque automáticamente se generen los templates o plantillas para documentar eneste formato presionando la combinación de teclas “/** + ENTER”. El algorit-mo 3.6 muestra un ejemplo de cómo se genera automáticamente el template deDoxygen.

1 /∗∗2 ∗ @brief B r i e f of DoxygenTemplate funct ion .3 ∗ @param f i r s t4 ∗ @param second5 ∗ @return6 ∗/7 i n t DoxygenTemplate ( char f i r s t , f l o a t second ) {8 re turn 0 ;9 }

ALGORITMO 3.6: Plantilla de documentación Doxygen.

Una vez escrito, testeado y validado el código de la biblioteca embebida, se proce-dió a crear la documentación en formato HTML a través de la herramienta Doxy-gen. Para eso, se instaló el plugin Eclox en Eclipse, como se detalla en su páginaweb oficial [18]. Luego de instalar el plugin, se adaptó el archivo de configura-ción de Doxygen -denominado Doxyfile-, con los parámetros para la salida de ladocumentación en formato HTML. Esto permitió tener una documentación to-talmente actualizada y acoplada al código fuente sin perder actualizaciones nidesincronización, como suele presentarse utilizando otras herramientas.

3.5. Ejemplos de uso 41

3.5. Ejemplos de uso

A medida que se fue desarrollando la biblioteca, se fueron testeando cada una delas funciones, no solo con unit testing, sino también con funciones que accedíana cada uno de los periféricos virtuales.

Este código se mantuvo siempre acompañando el entero desarrollo de la bibliote-ca. En el archivo “test_vihard.c”, archivo utilizado como la aplicación de usuario,además de la función que realiza un test integral de la plataforma haciendo usotodas sus funciones, están los tests que se realizaron sobre cada periférico virtualindividualmente.

Es una práctica recomendada por la ingeniería y testing de software que el códigode testing acompañe al código de la plataforma ya que, de esta manera, se puedetener un seguimiento de todo el camino recorrido hasta llegar a la versión deproducción.

Los ejemplos fueron realizados inicialmente para la plataforma EDU-CIAA-NXP.Una vez que se validó el funcionamiento de los mismos, se realizó el porting alas demás plataformas, cambiando únicamente las líneas correspondientes a lacompilación condicional.


3.6. Documentación

La especificación de los requerimientos listados en la subsección 2.2.1 establecióque se debía generar documentación de uso de la plataforma y una matriz detrazabilidad de requerimientos. En esta sección se presenta la creación de cadauna de ellas.

3.6.1. Matriz de trazabilidad de requerimientos

La observación de las normas vistas en la asignatura Certificación de SistemasElectrónicos, hizo que se tomaran consideraciones especiales para llevar a cabo eldesarrollo del proyecto.

Una de las actividades fundamentales fue crear una matriz de trazabilidad derequisitos obtenida de la norma ISO 21500 [19]. Este documento permite llevarel historial de cada uno de los requerimientos especificados en la planificacióncon el objetivo de saber en qué estado está cada uno, cuales son sus objetivos, susentregables y cómo será su validación.

La figura 3.8 muestra la plantilla de la que se partió para realizar la matriz detrazabilidad de requisitos del proyecto.

FIGURA 3.8: Plantilla de matriz de trazabilidad norma ISO 21500.

3.6. Documentación 43

3.6.2. Uso de la plataforma

Si bien la documentación fue un proceso que acompañó al desarrollo del código,la misma comenzó a pulirse y tomar forma una vez que tanto la aplicación de PC,la biblioteca embebida y los ejemplos de uso estaban ya realizados. Esto permitiógenerar la documentación justa y acorde a las necesidades de uso.

Se optó por realizar la documentación de toda la plataforma mediante una páginaweb y, desde la aplicación, proveer un link directo a la página.

La página web se desarrolló con la herramienta Google Sites 2 [20], la cual esuna plataforma que potencia la original herramienta Google Sites, ya que per-mite comportamiento responsivo y una manera muy fácil y amigable de crearcontenido. Algunas de las razones por las que se eligió esta plataforma son:

Hosting gratuito.

Comportamiento responsivo.

No se necesita programar para crear la web.

Se puede linkear cualquier clase de imagen o link externo.

Se pueden linkear directamente documentos de Google, ya sean Docs, Sli-des, Sheets, Imágenes, etcétera.

La última de las opciones, linkear documentos de Google, fue el motivo princi-pal por el que se optó por esta herramienta. De esta forma, primero se diseñó laestructura de la página web y luego se realizó la documentación de la plataformaen Slides de Google independientes, las cuales se linkearon a la web, permitiendoasí, mostrar siempre el último contenido.

Además de la documentación, también se pudieron adjuntar botones de descargadel programa de PC para Windows y Linux. De esta manera, en un lugar centra-lizado se accede a todo lo necesario para poder utilizar la plataforma.

Por ultimo, se agregó la sección de “Preguntas frecuentes” para que los usuariospuedan encontrar respuestas a sus preguntas más comunes de una manera ágil yrápida.

Para ver estas características en funcionamiento, se puede visitar la página webde ViHard [21].

45

Capítulo 4

Ensayos y Resultados

En este capítulo se muestran las pruebas más relevantes realizadas sobre la pla-taforma con sus respectivos resultados.

4.1. Tiempos de ejecución de comandos virtuales

Durante el desarrollo de la biblioteca de código embebida, se presentó el proble-ma que el intercambio de mensajes entre el sistema embebido y la aplicación dePC necesitaban enviarse con una temporización definida para que pudieran serinterpretarlos correctamente.

Esta problemática, hizo que fuera necesario utilizar el módulo de debug provistopor la EDU-CIAA-NXP junto con el debugger de Eclipse para analizar y modifi-car el comportamiento del firmware en tiempo de ejecución.

Para resolver el inconveniente se crearon dos variables en la biblioteca de códigoembebida: una destinada a establecer un tiempo de retardo entre la lectura decada dato proveniente del puerto serie, y otra para establecer un tiempo mínimode demora entre el envío de cada comando. Mientras el firmware se ejecutaba,mediante el debugging se fue cambiando el valor de las variables hasta encontraruna relación óptima entre velocidad de comunicación e integridad de los datos.

Se encontró que el tiempo entre lecturas del puerto serie depende de la velocidadde comunicación (baudrate) seleccionado. La relación de tiempo que se encontróestá representada de la siguiente manera:

microsegundos_entre_lecturas =1,000,000us

baudrate+ (

1,000,000us

baudrate0,1) (4.1)

El tiempo entre comandos quedó fijado en 7 ms, que es un tiempo razonable paraque la aplicación de PC pueda procesar los comandos recibidos.

Luego de eso, se creó una función de test que mide el tiempo que tarda en eje-cutarse cada comando mediante la biblioteca cycles_counter [22],la cual se desa-rrolló para otros proyectos y se encuentra disponible en el firmware oficial delproyecto CIAA [1].

Con la EDU-CIAA-NXP con un reloj de 204 Mhz, y una velocidad de conexiónserie de 115200 baudios, los tiempos de comunicación para cada comando que-daron establecidos como los demuestra la tabla 4.1. La representación de estostiempos puede tener una desviación aproximada de 500 us.

46 Capítulo 4. Ensayos y Resultados

TABLA 4.1: Ensayos de tiempos de ejecución de cada función queaccede al hardware virtual desde el sistema embebido.

Función de hardware virtual Tiempo de ejecución en micro segundos

7SegsWrite 7526AdcRead 9452DacWrite 7789GpioRead 8865GpioWrite 7532GpioToggle 16350LcdWrite 12375

Como se puede notar en la tabla 4.1, el tiempo más grande se encuentra en 12,375ms mientras que el mínimo 7,526 ms. Estos tiempos están muy ligados al retardoentre comandos fijados en 7 ms.

Se consideró un tiempo más que aceptable para tratarse de una aplicación dehardware virtual, por lo que el test de aceptación pasó satisfactoriamente.

4.2. Documentación HTML de Doxygen 47

4.2. Documentación HTML de Doxygen

Utilizando el plugin Eclox para el IDE Eclipse, mencionado en la subsección 3.3.4se creó la documentación de la biblioteca de firmware en formato Doxygen. Elformato de salida seleccionado fue HTML. La herramienta configura dentro deun directorio toda la documentación, incluyendo funciones, definiciones, varia-bles, explicaciones, etcétera. La figura 4.1 muestra el resultado de la creación dela documentación en formato de página web, visualizando la misma en un nave-gador.

FIGURA 4.1: Página de inicio de la documentación de firmwareen formato HTML generada automáticamente con la herramienta

Doxygen.

Como se puede apreciar en la figura 4.1 dentro de la documentación hay links alos archivos del proyecto, así como también a la documentación específica de lasfunciones, typedefs, enumeraciones, macros, etcétera.


4.3. Resultados de unit testing sobre firmware

Como se mencionó en la subsección 3.4.3, la herramienta utilizada para realizarel test unitario del firmware fue minunit, una utilidad minimalista pensada parasistemas embebidos.

El ensayo que se practicó para realizar las pruebas unitarias fue traducir a nom-bres de funciones los casos de prueba que se plantearon el la tabla 3.9. La nomen-clatura utilizada fue Test_Tx_NombreDeLaPrueba, donde x representa el númerode test. El algoritmo 4.1 muestra el código que fue llamado para ejecutar todas laspruebas unitarias.

1 s t a t i c char ∗ Test_T1_CommandsEndWithNull ( ) { . . . }2

3 s t a t i c char ∗ Tes t_T2_SendInva l idPer ipher i ca l s ( ) { . . . }4

5 s t a t i c char ∗ Test_T3_SendVal idPer ipher ica ls ( ) { . . . }6

7 s t a t i c char ∗ Test_T4_LedsOffAtIni t ( ) { . . . }8

9 s t a t i c char ∗ Test_T5_DacSetZeroAtInit ( ) { . . . }10

11 s t a t i c char ∗ Test_T6_LcdBlankAtInit ( ) { . . . }12

13 s t a t i c char ∗ Test_T7_7SegsValueAtIni t ( ) { . . . }14

15 s t a t i c char ∗ Test_T8_AdcValueUpperThanMax ( ) { . . . }16

17 s t a t i c char ∗ Test_T9_DacValueUpperThanMax ( ) { . . . }18

19 s t a t i c char ∗ Test_T10_DacValueLowerThanMin ( ) { . . . }20

21 s t a t i c char ∗ Test_T11_LcdWriteLineTruncation ( ) { . . . }22

23 s t a t i c char ∗ Test_T12_LcdWriteMult i l ineTruncat ion ( ) { . . . }24

25 s t a t i c char ∗ ExecuteAl lTes ts ( ) {26 MINUNIT_RUN_TEST( Test_T1_CommandsEndWithNull ) ;27 MINUNIT_RUN_TEST( Tes t_T2_SendInva l idPer ipher i ca l s ) ;28 MINUNIT_RUN_TEST( Test_T3_SendVal idPer ipher ica ls ) ;29 MINUNIT_RUN_TEST( Test_T4_LedsOffAtIni t ) ;30 MINUNIT_RUN_TEST( Test_T5_DacSetZeroAtInit ) ;31 MINUNIT_RUN_TEST( Test_T6_LcdBlankAtInit ) ;32 MINUNIT_RUN_TEST( Test_T7_7SegsValueAtIni t ) ;33 MINUNIT_RUN_TEST( Test_T8_AdcValueUpperThanMax ) ;34 MINUNIT_RUN_TEST( Test_T9_DacValueUpperThanMax ) ;35 MINUNIT_RUN_TEST( Test_T10_DacValueLowerThanMin ) ;36 MINUNIT_RUN_TEST( Test_T11_LcdWriteLineTruncation ) ;37 MINUNIT_RUN_TEST( Test_T12_LcdWriteMult i l ineTruncat ion ) ;38 re turn 0 ;39 }

ALGORITMO 4.1: Llamados a las funciones de pruebas unitarias.

4.3. Resultados de unit testing sobre firmware 49

Se ejecutó el código de pruebas unitarias sobre la placa de desarrollo EDU-CIAA-NXP, utilizada a lo largo del proyecto, y para visualizar la ejecución de los tests,se conectó la misma a una interfaz serial. La figura 4.2 muestra la primer partede los tests, la figura 4.3 la segunda parte y la figura 4.4 la última parte, con elresumen que se realizó al terminar de ejecutar los mismos.

FIGURA 4.2: Resultados de pruebas unitarias parte 1.




4.4. Porting del firmware a diferentes arquitecturas 51

4.4. Porting del firmware a diferentes arquitecturas

Como se especificó en la subsección 3.4.3, la biblioteca embebida fue pensada pa-ra ser altamente portable hacia otras arquitecturas, ya que se necesitan solamente6 líneas de código de compilación condicional, y que están relacionadas con pa-rámetros específicos del microcontrolador en cuestión, tales como velocidad delreloj y configuraciones del puerto serie.

El porting se realizó a partir del código desarrollado para la EDU-CIAA-NXPhacia las plataformas CIAA ZERO [23] y Arduino [24]. Esta última, ampliamentedifundida entre estudiantes y hobbystas de los sistemas embebidos. El algoritmo4.2 muestra el código desarrollado para utilizar ViHard en tales plataformas.

1 # i f defined (BOARD_EDU_CIAA_NXP)2 // CONFIGURACIONES DEL MICROCONTROLADOR3 # def ine VIHARD_SERIAL_PORT UART_USB4 # def ine VIHARD_BAUDRATE 1152005 # def ine CLOCK_SPEED_MHZ 2046 // MACROS DEL PUERTO SERIE7 # def ine UART_CONFIG( baudrate ) \8 uartConfig (VIHARD_SERIAL_PORT, baudrate )9 # def ine UART_READ_BYTE( byteToRead ) \

10 uartReadByte (VIHARD_SERIAL_PORT, &byteToRead )11 # def ine UART_WRITE_BYTE( byteToWrite ) \12 uartWriteByte (VIHARD_SERIAL_PORT, ( u i n t 8 _ t ) byteToWrite )13

14 # e l i f defined (BOARD_CIAA_ZERO)15 // CONFIGURACIONES DEL MICROCONTROLADOR16 # def ine VIHARD_SERIAL_PORT UART017 # def ine VIHARD_BAUDRATE 960018 # def ine CLOCK_SPEED_MHZ 2519 // MACROS DEL PUERTO SERIE20 # def ine UART_CONFIG( baudrate ) \21 uartConfig (VIHARD_SERIAL_PORT, baudrate )22 # def ine UART_READ_BYTE( byteToRead ) \23 uartReadByte (VIHARD_SERIAL_PORT, &byteToRead )24 # def ine UART_WRITE_BYTE( byteToWrite ) \25 uartWriteByte (VIHARD_SERIAL_PORT, ( u i n t 8 _ t ) byteToWrite )26

27 # e l i f defined (BOARD_ARDUINO)28 // CONFIGURACIONES DEL MICROCONTROLADOR29 # def ine VIHARD_SERIAL_PORT 030 # def ine VIHARD_BAUDRATE 960031 # def ine CLOCK_SPEED_MHZ 1632 // MACROS DEL PUERTO SERIE33 # def ine UART_CONFIG( baudrate ) \34 S e r i a l . begin ( baudrate )35 # def ine UART_READ_BYTE( byteToRead ) \36 S e r i a l . read(&byteToRead )37 # def ine UART_WRITE_BYTE( byteToWrite ) \38 S e r i a l . wri te ( ( u i n t 8 _ t ) byteToWrite )39 # endi f

ALGORITMO 4.2: Porting de ViHard hacia otras plataformas.


4.5. Análisis estático de firmware con SonarCloud

Cuando se finalizó el desarrollo de la biblioteca de código embebida, se analizósu calidad con el propósito de identificar posibles puntos de falla. Para tal fin seutilizó la herramienta SonarCloud [25], una plataforma que permite realizar todaclase de análisis sobre calidad del código, cobertura, identificación de vulnerabi-lidades, mantenibilidad, entre otros datos.

SonarCloud realiza un análisis estático del código fuente para determinar lasmétricas del mismo. Utilizar esta plataforma requirió descargar la herramientabuild-wrapper, que realiza una compilación del código agregando informaciónadicional para ser analizada posteriormente. Una vez realizada la compilación,se ejecutó la utilidad sonar-scanner, que toma los datos compilados con build-wrapper, los procesa y los envía a la nube para poder visualizarlos.

La figura 4.5 muestra una visualización general del proyecto, que incluye los ar-chivos vihard.h y vihard.c, así como también el archivo main.c que hace uso detodas las funciones del módulo.

FIGURA 4.5: Métricas de firmware en SonarCloud.

4.5. Análisis estático de firmware con SonarCloud 53

La métrica ”Bugs” está asociada a los posibles errores que pueda tener la codi-ficación del programa, mientras que ”Vulnerabilities” se relaciona mayormentecon programación de servidores resaltando las posibles vulnerabilidades que po-dría presentar ante hackings. La métrica ”Code Smells” (en español “Olor delcódigo”) sugiere que hay bloques de software que pueden ser potenciales puntosde falla. ”Coverage” significa el porcentaje de código que fue probado con inte-gración continua de software [26] y con ”Duplications” apunta al porcentaje decódigo que se repite, un caso que suele presentarse a menudo cuando se copia ypega parte del mismo código en distintos lugares del programa.

En una inspección más específica del código, se pudieron relevar datos asociadosa cada uno de los archivos analizados, como lo muestra la figura 4.6.

FIGURA 4.6: Métricas específicas de cada archivo de código.

La columna “Code Smells” señaló que había partes que debían modificarse, yaque podían desencadenar posibles fallas o vulnerabilidades. En la mayoría delos casos estas advertencias estuvieron ligadas a sintaxis, por ejemplo, eliminaruna línea de código comentado o corregir las tabulaciones de algunas expresio-nes, pero en otros casos, a análisis de código más específico y profundo, comola sugerencia de modificación de algunas funciones para bajar el nivel de com-plejidad cognitiva [27], una variable que mide que tan difícil son de entender lasexpresiones lógicas de una función, como lo demuestra la figura 4.7.

FIGURA 4.7: Sugerencias de refactorización realizadas por Sonar-Cloud.


Luego de realizar algunas de las acciones sugeridas por SonarCloud, se compilónuevamente el firmware con build-wrapper, se enviaron los datos a la nube consonar-scanner y se chequeó la nueva información. Como puede verse en la figura4.8, los valores de la columna “Code Smells” mejoraron notablemente.

FIGURA 4.8: Visualización de las mejoras aplicadas al código.

Esta plataforma, utilizada en la asignatura Diseño de Sistemas Críticos, resultóun complemento muy útil para mejorar la calidad del código, y si bien la bi-blioteca embebida ViHard no representa un software crítico, analizarlo con unaherramienta de esta índole sirvió como puerta de entrada a realizarlo en futurosproyectos.

4.6. Demostración de caso de uso 55

4.6. Demostración de caso de uso

Como se explicó en la sección 1.2, el uso de la biblioteca ViHard dentro de unfirmware embebido no restringe a utilizar funciones que accedan a hardware realy virtual al mismo tiempo, con la excepción del puerto USB-Serie por el que seconecta el sistema embebido a la aplicación de hardware virtual en la PC.

Para demostrar un caso de uso se desarrolló un firmware que lee el valor de unpotenciómetro físico y muestra el valor leído en el display LCD virtual de la apli-cación de PC.

Se utilizó una placa EDU-CIAA-NXP a la que se conectó un potenciómetro en suentrada analógica CH1, como lo demuestra la figura 4.6.

FIGURA 4.9: Potenciómetro conectado a EDU-CIAA-NXP.


A continuación, se desarrolló el programa que realiza las acciones requeridas yque está descripto en el algoritmo 4.3.

1 # include " sapi . h"2 # include " vihard . h"3

4 i n t main ( void ) {5 // VARIABLE PARA LEER EL VALOR DEL ADC6 u i n t 1 6 _ t adcValue = 0 ;7 // ARREGLO DONDE SE GUARDA EL TEXTO A ENVIAR AL LCD8 char lcdText [ 2 0 ] ;9

10 // CONFIGURA PLACA EDU CIAA NXP11 boardConfig ( ) ;12 // HABILITA ADC13 adcConfig ( ADC_ENABLE ) ;14 // CONFIGURA BIBLIOTECA VIHARD15 Vh_BoardConfig (VIHARD_BAUDRATE) ;16

17 while ( 1 ) {18 // LEE EL VALOR DEL ADC19 adcValue = adcRead ( CH1 ) ;20 // FORMATEA EL TEXTO CON EL VALOR DEL ADC21 s t d i o S p r i n t f ( lcdText , " Valor ADC: %d" , adcValue ) ;22 // ENVIA EL TEXTO AL LCD VIRTUAL23 Vh_LcdWriteString (VH_LCD1, LCD_LINE_ALL , lcdText ) ;24 // ESPERA 1 SEGUNDO25 delay ( 1 0 0 0 ) ;26 }27 re turn 0 ;28 }

ALGORITMO 4.3: Firmware de demostración de caso de uso.

Luego de desarrollar el algoritmo, se conectó la EDU-CIAA-NXP a la aplicaciónde hardware virtual en la PC a través del puerto USB y se ejecutó el firmwaredesarrollado. En la figura 4.10 se puede apreciar que el valor del potenciómetroleído en pin CH1 de la EDU-CIAA-NXP se muestra en el display LCD virtual.

4.6. Demostración de caso de uso 57

FIGURA 4.10: Programa de PC ViHard mostrando valor ADC.

59

Capítulo 5

Conclusiones

Este capítulo resume el trabajo que se realizó, se listan las conclusiones pertinen-tes y se esbozan las posibilidades del trabajo a futuro.

5.1. Trabajo realizado

Las principales conclusiones sobre el trabajo realizado son:

El desarrollo de ViHard como plataforma abierta realiza un aporte al pro-yecto CIAA y a cualquier plataforma de hardware o kit de desarrollo. Esteaporte es útil para toda la comunidad de sistemas embebidos en general,pero principalmente para principiantes, lo que alienta a que más personasgeneren interés por los sistemas embebidos.

Al tratarse de una plataforma libre que facilita el aprendizaje, se espera suadopción en el ámbito académico como una herramienta de enseñanza deprogramación.

Es especialmente útil para realizar un prototipado rápido o pruebas de con-cepto de cómo se comportará un sistema embebido sin necesidad de contarcon el hardware implementado.

Se creó una herramienta de la cual no se conocen otras similares, por lo quepuede ser una nueva rama de desarrollo.

Se aplicaron conocimientos adquiridos en Gestión de la Tecnología e Inno-vación, Certificación de Sistemas Electrónicos, Diseño de Sistemas Críticosy Testing para Sistemas Embebidos. Entre los principales se encuentran ma-triz de trazabilidad de requisitos, análisis estático de código, implementa-ción de técnicas de programación multitarea, desarrollo de código guiadopor pruebas y análisis dinámico.

60 Capítulo 5. Conclusiones

5.2. Próximos pasos

La plataforma aún está en etapa de desarrollo, realizando iteraciones y mejorasconstantes. Aplicando parcialmente la metodología Lean Startup [28], aprendi-da en la asignatura Gestión de Emprendimientos Tecnológicos, se espera lograraprendizaje sobre cuales son las características específicas que los usuarios nece-sitan, de manera tal que los próximos pasos del proyecto estén guiados por lasdevoluciones otorgadas por las personas que utilizan la plataforma.

Las mejoras estarán principalmente orientadas en:

Crear nuevos periféricos virtuales tales como analizador de señales, oscilos-copio, simuladores de entradas numéricas representando distintos tipos desensores, entre otros.

Crear y distribuir el programa de PC tanto para Windows, Linux y OS X.

Portar la biblioteca de código embebida hacia nuevos microcontroladores yplacas de desarrollo.

Optimizar la velocidad de comunicación entre el sistema embebido y la PCpara cada plataforma.

Reducir el consumo de CPU de la aplicación de PC.

Crear mayor cantidad de ejemplos de uso.

61

Bibliografía

[1] Proyecto CIAA. Computadora Industrial Abierta Argentina.http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start. Disponible:2018-11-21. 2018.

[2] Wikipedia. Trello. Ed. por Wikipedia.https://en.wikipedia.org/wiki/Trello, note = Disponible: 2018-11-21.2018.

[3] Wikipedia. Gitkraken. Ed. por Wikipedia.https://en.wikipedia.org/wiki/Axosoft, note = Disponible: 2018-11-21.2018.

[4] Wikipedia. NodeJS. Ed. por Wikipedia.https://es.wikipedia.org/wiki/Node.js. Disponible: 2018-11-21. 2018.

[5] Wikipedia. ElectronJS. Ed. por Wikipedia.https://en.wikipedia.org/wiki/Electron_(software_framework).Disponible: 2018-11-21. 2018.

[6] Wikipedia. Chromium. Ed. por Wikipedia.https://en.wikipedia.org/wiki/Chromium_(web_browser), note =Disponible: 2018-11-21. 2018.

[7] Wikipedia. Eclipse IDE. Ed. por Wikipedia.https://en.wikipedia.org/wiki/Eclipse_(software), note = Disponible:2018-11-21. 2018.

[8] Wikipedia. Comunicaciones Request-Response. Ed. por Wikipedia.https://en.wikipedia.org/wiki/Request\T1\textendashresponse, note =Disponible: 2018-11-21. 2018.

[9] Wikipedia. Inkscape. Ed. por Wikipedia.https://en.wikipedia.org/wiki/Inkscape, note = Disponible: 2018-11-21.2018.

[10] DaFont. DaFont. Ed. por DaFont. https://www.dafont.com/es, note =Disponible: 2018-11-21. 2018.

[11] hilite. hilite. Ed. por hilite. http://hilite.me, note = Disponible: 2018-11-21.2018.

[12] Gobierno Argentina. Conectar Igualdad. Ed. por Gobierno Argentina.https://www.argentina.gob.ar/educacion/aprender-conectados/conectar-igualdad, note = Disponible: 2018-11-21. 2018.

[13] Icon Medios. Resoluciones de PC más utilizadas. Ed. por Icon Medios.https://www.iconmedios.com/resoluciones-de-pantallas-mas-utilizadas,note = Disponible: 2018-11-21. 2018.

[14] Jera. Herramienta de pruebas unitarias MinUnit. Ed. por Jera.http://www.jera.com/techinfo/jtns/jtn002.html, note = Disponible:2018-11-21. 2018.

[15] Eric Pernia. Biblioteca de firmware sAPI. Ed. por Eric Pernia.https://github.com/epernia/sAPI, note = Disponible: 2018-11-21. 2018.

http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start

https://en.wikipedia.org/wiki/Trello

https://en.wikipedia.org/wiki/Axosoft

https://es.wikipedia.org/wiki/Node.js

https://en.wikipedia.org/wiki/Electron_(software_framework)

https://en.wikipedia.org/wiki/Chromium_(web_browser)

https://en.wikipedia.org/wiki/Eclipse_(software)

https://en.wikipedia.org/wiki/Request\T1\textendash response

https://en.wikipedia.org/wiki/Inkscape

https://www.dafont.com/es

http://hilite.me

https://www.argentina.gob.ar/educacion/aprender-conectados/conectar-igualdad

https://www.argentina.gob.ar/educacion/aprender-conectados/conectar-igualdad

https://www.iconmedios.com/resoluciones-de-pantallas-mas-utilizadas

http://www.jera.com/techinfo/jtns/jtn002.html

https://github.com/epernia/sAPI

62 BIBLIOGRAFÍA

[16] Wikipedia. ANSI C. Ed. por Wikipedia.https://en.wikipedia.org/wiki/ANSI_C, note = Disponible: 2018-11-21.2018.

[17] Wikipedia. Doxygen. Ed. por Wikipedia.https://en.wikipedia.org/wiki/Doxygen, note = Disponible: 2018-11-21.2018.

[18] Eclipse. Plugin Eclox para Eclipse. Ed. por Eclipse.https://marketplace.eclipse.org/content/eclox, note = Disponible:2018-11-21. 2018.

[19] ISO. Norma ISO 21500. Ed. por Asociación española para la calidad.https://www.aec.es/web/guest/centro-conocimiento/norma-iso-21500,note = Disponible: 2018-11-21. 2018.

[20] Wikipedia. Google Sites 2. Ed. por Wikipedia.https://en.wikipedia.org/wiki/Google_Sites, note = Disponible:2018-11-21. 2018.

[21] Juan Agustin Bassi. Página web oficial de ViHard. Ed. porJuan Agustin Bassi. https://sites.google.com/view/vihard, note =Disponible: 2018-11-21. 2018.

[22] Agustin Bassi. Libreria para ciclos de clock para EDU-CIAA NXP. Ed. porEric Pernia. https://github.com/ciaa/firmware_v2/blob/master/modules/lpc4337_m4/sapi/inc/sapi_cyclesCounter.h, note = Disponible:2018-11-21. 2018.

[23] Proyecto CIAA. Placa de desarrollo CIAA ZERO. Ed. por Proyecto CIAA.http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:ciaa-z3r0, note = Disponible: 2018-11-21. 2018.

[24] Arduino. Pagina Arduino. Ed. por Arduino. https://www.arduino.cc, note= Disponible: 2018-11-21. 2018.

[25] Sonar Source S.A. Página web oficial de SonarCloud. Ed. porSonar Source S.A. https://sonarcloud.io, note = Disponible: 2018-11-21.2018.

[26] Wikipedia. Integración continua de software. Ed. por Wikipedia. 2018.[27] Santiago Lopez. Complejidad cognitiva en software. Ed. por Santiago Lopez.

https://enmilocalfunciona.io/complejidad-cognitiva, note = Disponible:2018-11-21. 2018.

[28] Wikipedia. Metodología Lean Startup. Ed. por Wikipedia.https://en.wikipedia.org/wiki/Lean_Startup, note = Disponible:2018-11-21. 2018.

https://en.wikipedia.org/wiki/ANSI_C

https://en.wikipedia.org/wiki/Doxygen

https://marketplace.eclipse.org/content/eclox

https://www.aec.es/web/guest/centro-conocimiento/norma-iso-21500

https://en.wikipedia.org/wiki/Google_Sites

https://sites.google.com/view/vihard

https://github.com/ciaa/firmware_v2/blob/master/modules/lpc4337_m4/sapi/inc/sapi_cyclesCounter.h

https://github.com/ciaa/firmware_v2/blob/master/modules/lpc4337_m4/sapi/inc/sapi_cyclesCounter.h

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:ciaa-z3r0

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:ciaa-z3r0

https://www.arduino.cc

https://sonarcloud.io

https://enmilocalfunciona.io/complejidad-cognitiva

https://en.wikipedia.org/wiki/Lean_Startup

Documents

Plataforma de emulación de hardware para sistemas …laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-MSE-Agustin-Bassi-2018.pdfabierto para facilitar el aprendizaje de programación