Entorno de programación educativo en lenguaje Python para la EDU CIAA NXP

Entorno de programación educativo en lenguaje Python para la EDU CIAA NXP Autor Director del trabajo Ing. Eric Pernia Jurado propuesto para el trabajo Ing. Pedro Martos Ing. Alejandro Permingeat Ing. Gerardo Sager Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de Proyectos entre abril y mayo de 2016. Página 1 de 22

Tabla de contenido Registros de cambios Acta de Constitución del Proyecto Identificación y análisis de los interesados 1. Propósito del proyecto 2. Alcance del proyecto 3. Supuestos del proyecto 4. Requerimientos 5. Entregables principales del proyecto 6. Desglose del trabajo en tareas 7. Diagrama de Activity On Node 8. Diagrama de Gantt 9. Matriz de uso de recursos de materiales 10. Presupuesto detallado del proyecto 11. Matriz de asignación de responsabilidades 12. Gestión de riesgos 13. Gestión de la calidad 14. Comunicación del proyecto 14. Gestión de Compras 16. Seguimiento y control 17. Procesos de cierre Página 2 de 22

Registros de cambios Revisión Cambios realizados Fecha 1.0 Creación del documento 30/03/2016 1.1 Primeras correcciones hasta punto 6 03/04/2016 1.2 Se completó hasta punto 11 08/04/2016 1.3 Correcciones título, gant y matriz responsabilidades 12/04/2016 1.4 Se completó hasta punto 17 15/04/2016 1.5 Correcciones gant 18/04/2016 1.6 Se agregaron los Jurados 08/05/2016 Página 3 de 22

Acta de Constitución del Proyecto Buenos Aires, 30 de marzo de 2016 Por medio de la presente se acuerda con el Sr. Ernesto Gigliotti que su Proyecto Final de la Carrera de Especialización en Sistemas Embebidos se titulará Entorno de programación educativo en lenguaje Python para la EDU CIAA NXP., consistirá esencialmente en el soporte del firmware del proyecto micropython para la placa EDU CIAA, la realización de un entorno de programación y la generación de documentación y ejemplos, y tendrá un presupuesto preliminar estimado de 600 hs de trabajo, con fecha de inicio miércoles 30 de marzo de 2016 y fecha de presentación pública miércoles 14 de diciembre de 2016. Se adjunta a esta acta la planificación inicial. Ariel Lutenberg Director de la CESE FIUBA Página 4 de 22

Identificación y análisis de los interesados Rol Nombre y Apellido Departamento Puesto Auspiciante Cliente Jurado FIUBA Jurados de la CESE Impulsor Ernesto Gigliotti Responsable Ernesto Gigliotti UTN FRA Desarrollador Colaboradores Martin Ribelotta Responsable Software IDE del proyecto CIAA Orientadores Eric Pernia UNQUI/FIUBA Docente en la Carrera de Esp. en Sistemas Embebidos Equipo Opositores Usuario Final Alumnos de nivel secundario y universitario Escuelas secundarias y universidades 1. Propósito del proyecto El objetivo principal del proyecto será proveer una herramienta que permita a estudiantes de educación secundaria y universitaria aprender programación y electrónica, utilizando el lenguaje Python junto con la plataforma EDU CIAA NXP. 2. Alcance del proyecto El proyecto incluye el desarrollo del soporte para la placa, de modo que se puedan utilizar desde módulos python, las entradas y salidas de la placa así como también los periféricos básicos como UART, entradas analógicas, etc.. Página 5 de 22

Por otro lado se desarrollará un software a modo de entorno de programación, monoarchivo, que permita escribir el programa que se ejecutará en la placa. El alcance del proyecto también incluye la realización de proyectos de ejemplo utilizando la placa y el lenguaje Python, así como también la documentación de las bibliotecas desarrolladas para programar. El proyecto no incluye la implementación de periféricos complejos como ethernet, usb o can. 3. Supuestos del proyecto Para el desarrollo del presente proyecto se supone que la placa sobre la que se plantea el desarrollo es accesible a bajo costo y en la cantidad demandada, por alumnos de nivel secundario y universitario. Se tomará como base el port de micropython para el lpc43xx realizado por Martin Ribelotta el cual incluye la inicialización básica del intérprete Python, la realización de un módulo REPL y la implementación de un Filesystem simple dentro de la memoria Flash del microcontrolador, todas estas características se suponen estables y funcionando. 4. Requerimientos 1. Grupo de requerimientos referidos a las bibliotecas Python disponibles para programar: 1.1 Manejo de los leds que dispone la placa. 1.2 Utilización de los pulsadores. 1.3 Manejo y configuración de los pines designados como GPIO. 1.4 Configuración y utilización de la UART. 1.5 Configuración y utilización de la interface RS485.. 1.6 Lectura de las entradas ADC. 1.7 Salida DAC. 1.8 Utilización de la EEPROM interna. 2. Grupo de requerimientos referidos al entorno de desarrollo 2.1 El software deberá ser multiplataforma (Windows/Linux/OSX) 2.2 No debe ser necesario recompilar el firmware de la placa para cambiar el script de python. 2.3 El programa de python se enviará por el COM virtual generado al conectar la placa a la PC. 2.4 El software deberá tener embebida una terminal serial, por donde se implementará la interfaz de salida y entrada estándar del programa de Python. 2.5 El software deberá tener porciones de código de ejemplo que puedan insertarse fácilmente junto con lo que el usuario programa (Snippets) 2.6 El software deberá tener links para acceder fácilmente a la documentación online y a los proyectos de ejemplo. Página 6 de 22

3. Grupo de requerimientos referidos a los proyectos de ejemplo 3.1 Los proyectos de ejemplo serán divididos en tres categorías: Inicial, Intermedio y Avanzado. 3.2 Los proyectos de ejemplo consistirán en el código fuente, la explicación del mismo en forma detallada, y un esquemático de conexión con componentes externos en el caso que se requiera. 3.3 Los proyectos de ejemplo estarán basados en los proyectos típicos de electrónica que se realizan en escuelas secundarias. 4. Grupo de requerimientos generales 4.1 El acceso a la información del proyecto será libre y gratuita. 4.2 Se publicará la documentación de las bibliotecas de Python disponibles para programar. 5. Entregables principales del proyecto Repositorio de firmware. Instructivo de instalación de firmware. Instalador y código fuente del software entorno de desarrollo. Instructivo de utilización del software entorno de desarrollo. Repositorio con proyectos de ejemplo. Documentación de las bibliotecas Python que pueden utilizarse para programar. 6. Desglose del trabajo en tareas 1. Grupo de tareas respecto al firmware (127 hs) 1.1 Puesta en marcha del core básico de micropython. (12hs) 1.2 Configuración y habilitación de features. (4 hs) 1.3 Creación de una Biblioteca C para el uso de leds. (4 hs) 1.4 Creación de un Módulo Python para el uso de leds. (6 hs) 1.5 Creación de una Biblioteca C para uso de pulsadores. (4 hs) 1.6 Creación de un Módulo Python para uso de pulsadores. (6 hs) 1.7 Creación de una Biblioteca C para uso de la UART. (12 hs) 1.8 Creación de un Módulo Python para uso de la UART. (8 hs) 1.9 Creación de una Biblioteca C para uso de GPIOs. (8 hs) 1.10 Creación de un Módulo Python para uso de GPIOs. (6 hs) 1.11 Creación de una Biblioteca C para uso de ADC. (8 hs) 1.12 Creación de un Módulo Python para uso de ADC. (6 hs) 1.13 Creación de una Biblioteca C para uso de DAC. (4 hs) 1.14 Creación de un Módulo Python para uso de DAC. (5 hs) 1.15 Creación de una Biblioteca C para uso de Timers. (8 hs) 1.16 Creación de un Módulo Python para uso de Timers. (6 hs) 1.17 Creación de una Biblioteca C para el uso de la EEPROM interna. (4 hs) 1.18 Creación de un Módulo Python para uso de la EEPROM interna. (4 hs) 1.19 Implementación de protocolo xmodem para transferir archivo desde el IDE a la placa. (12 hs) Página 7 de 22

2. Grupo de tareas respecto al software (80 hs) 2.1 Implementación de editor con syntax highlighter. (16 hs) 2.2 Envío de archivo a la placa. (12 hs) 2.3 Menú configuración puerto serie. (8 hs) 2.4 Menú con snippets. (8 hs) 2.5 Terminal serie integrada. (18 hs) 2.6 Instructivo de instalación y uso. (12 hs) 2.7 Generación de instaladores. (6 hs) 3. Grupo de tareas de testing de firmware (100 hs) 3.1 Crear tests unitarios de bibliotecas C (32 hs) 3.2 Crear tests unitarios de módulos Python (40 hs) 3.3 Crear test funcional de cada módulo Python de cada periférico (28 hs) 4. Grupo de tareas de testing de software (44 hs) 4.1 Crear test unitarios para pantalla de terminal integrada. (12 hs) 4.2 Crear test unitarios para pantalla de snippets. (8 hs) 4.3 Crear test unitarios para pantalla de configuración. (4 hs) 4.4 Crear test unitarios para envío de archivo a la placa. (12 hs) 4.5 Test funcional de integración. (8 hs) 5. Grupo de tareas respecto a los proyectos de ejemplo (80 hs) 5.1 Crear al menos 4 proyectos de ejemplo de nivel inicial. (8 hs) 5.2 Crear documentación de los proyectos de nivel inicial. (8 hs) 5.3 Crear al menos 4 proyectos de ejemplo de nivel intermedio. (12 hs) 5.4 Crear documentación de los proyectos de nivel intermedio. (12 hs) 5.5 Crear al menos 4 proyectos de ejemplo de nivel avanzado. (24 hs) 5.6 Crear documentación de los proyectos de nivel avanzado. (16 hs) 6. Grupo de tareas respecto a documentación de bibliotecas (29 hs) 6.1 Crear documentación del módulo de python para el uso de leds. (3 hs) 6.2 Crear documentación del módulo de python para el uso de pulsadores. (3 hs) 6.3 Crear documentación del módulo de python para el uso de la UART. (4 hs) 6.4 Crear documentación del módulo de python para el uso de GPIOs. (3 hs) 6.5 Crear documentación del módulo de python para el uso de leds. (3 hs) 6.6 Crear documentación del módulo de python para el uso de ADC. (3 hs) 6.7 Crear documentación del módulo de python para el uso de DAC. (3 hs) 6.8 Crear documentación del módulo de python para el uso de Timers. (4 hs) 6.9 Crear documentación del módulo de python para el uso de la EEPROM. (3 hs) Página 8 de 22

7. Grupo de tareas respecto a la escritura del trabajo (92hs) 7.1 Escribir memoria del trabajo (80 hs) 7.2 Escribir presentación (12 hs) Total de horas: 552hs 7. Diagrama de Activity On Node NOTA: Las tareas 2.x y 3.x se han indicado que pueden ser resueltas de forma simultánea, sin embargo debido a que existirá un solo programador en el proyecto las tareas se desarrollarán en forma consecutiva. Página 9 de 22

8. Diagrama de Gantt Página 10 de 22

Página 11 de 22

Página 12 de 22

Página 13 de 22

Página 14 de 22

9. Matriz de uso de recursos de materiales Código WBS Nombre de la tarea Recursos requeridos (horas) PC EDU CIAA NXP 1.x Desarrollo de Firmware 127 hs 127 hs 2.x Desarrollo IDE 80hs 0hs 3.x Testing Firmware 100hs 100hs 4.x Testing IDE 44hs 20hs 5.x Proyectos de ejemplo 6.x Documentación bibliotecas 7.x Escribir trabajo final y presentación 80hs 29hs 92hs 80hs 0hs 0hs 10. Presupuesto detallado del proyecto Categoría Detalle Costo Costo directo 600hs a $120/hr $72.000 Costo indirecto 30% del costo directo $21.600 Materiales EDU CIAA NXP $750 TOTAL $94.350 Página 15 de 22

11. Matriz de asignación de responsabilidades Código WBS Título de la tarea 1.x Desarrollo de Firmware Listar todos los nombres y apellidos y el rol definidos en el proyecto Ernesto Gigliotti Responsable Martin Riobelotta Colaborador Eric Pernia Orientador P C A I Alumnos escuelas secundarias y universidades Usuario 2.x Desarrollo IDE P A I 3.x Testing Firmware P A 4.x Testing IDE P A 5.x Proyectos ejemplo P A I 6.x Documentación bibliotecas P A I 7.x Escribir trabajo final P A Referencias: P = Responsabilidad Primaria S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado 12. Gestión de riesgos Riesgo 1: El código fuente implementado no cabe en la memoria del microcontrolador de la placa. Severidad (S)=7. Es una limitante en la cantidad de periféricos a los que se les puede dar soporte para poder ser utilizados desde el lenguaje Python. Probabilidad de ocurrencia (O)=3. El microcontrolador utilizado posee una gran cantidad de memoria de programa, por lo que es poco probable que ocurra. Tasa de no detección (D)=5. Es difícil estimar cuánto espacio va a ocupar un código que todavía no se programó. Página 16 de 22

Riesgo 2: Pérdida de los materiales de trabajo (placa o PC) Severidad (S)=2. Existen muchas en el mercado, es muy simple conseguir un reemplazo (ya sea la placa o una PC) Probabilidad de ocurrencia (O)=3. No es muy probable que ocurra. Aunque es posible por una mala manipulación de la placa o caso de robo. Tasa de no detección (D)=8. Es muy complicado saber cuando va a ocurrir un accidente de este tipo con antelación. Riesgo 3: No se llegan a cumplir todos los requerimientos. Severidad (S)=5. Puede limitarse el proyecto a tener menos soporte de hardware en una primera versión, y luego incluir más horas para completarlo. Probabilidad de ocurrencia (O)=4. No es muy probable que ocurra ya que se pretende que el proyecto sea el trabajo final de una carrera de especialización y se terminará a tiempo. Tasa de no detección (D)=2. Si las tareas están bien estimadas, es fácil detectar si se llegará a tiempo a completarlas todas. Riesgo 4: La plataforma no es utilizada por la comunidad CIAA. Si la documentación es confusa y es dificultoso comenzar a utilizar la placa con el firmware y el IDE desarrollados, el proyecto probablemente sea ignorado. Severidad (S)=8. Si la plataforma no es utilizada el proyecto pierde todo su sentido, ya que ésta fue la razón de existencia del mismo. Probabilidad de ocurrencia (O)=2. Como parte de las tareas a desarrollar se declararon las relacionadas a la creación de ejemplos y documentación, por lo que no es probable que ocurra. Tasa de no detección (D)=3. Al ser parte de los requerimientos, en la etapa de validación y verificación se detectará el problema. Riesgo 5: La memoria RAM del microcontrolador no es suficiente para la implementación de todos los drivers y módulos de python. Severidad (S)=8. No podrán implementarse los módulos de python deseados, limitando lo que luego será posible hacer con la placa. Probabilidad de ocurrencia (O)=7. La placa EDU CIAA NXP no posee los chips de memoria externa, y la cantidad de memoria RAM que posee el microcontrolador no es tanta, por lo que es posible que este hecho ocurra. Tasa de no detección (D)=1. La mayor parte de la memoria es consumida por el port de micropython en sí y no por los drivers agregados, por lo que es posible detectar este problema antes de comenzar el desarrollo de los drivers. Página 17 de 22

b) Tabla de gestión de riesgos: (El RPN se calcula como RPN=SxOxD.) Riesgo Severidad Ocurren. Detección RPN Severidad* Ocurren. * Detecc * RPN* 1 7 3 5 105 5 3 3 45 2 2 3 8 48 3 5 4 2 40 4 8 2 4 64 5 1 3 15 5 8 7 1 56 Criterio adoptado: Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 60 Nota: Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación. c) Plan de mitigación de los riesgos que originalmente excedían el PRN máximo establecido: Riesgo 1: Plan de mitigación: Pueden programarse algunas rutinas en assembler para que ocupen menos espacio. Severidad (S)=5. Aunque es más trabajoso de realizar y quizá menos portable, con esta solución se solucionaría el problema. Probabilidad de ocurrencia (O)=3. No es probable que ocurra ya que la memoria disponible es grande. Tasa de no detección (D)=3. Se estima de antemano que el código en ASM ocupa un tercio del código en C. Riesgo 4: Plan de mitigación: Se deberán reevaluar los ejemplos desarrollados y generar contenido multimedia (Videos, notas, presentaciones, fotos, etc) que ayude a la comprensión y utilización de la plataforma. Severidad (S)=5. Se sumará más tiempo de proyecto del requerido. Probabilidad de ocurrencia (O)=1. Al agregar material informativo bajará la probabilidad de que ocurra el riesgo. Tasa de no detección (D)=3. Al ser parte de los requerimientos, en la etapa de validación y verificación se detectará el problema. Página 18 de 22

13. Gestión de la calidad Para cada uno de los requerimientos del proyecto indique: Req #1.x: Grupo de requerimientos referidos a las bibliotecas Python disponibles para programar. Verificación y validación: Responsable de la verificación: Ernesto Gigliotti Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se realizarán tests de todos los módulos y drivers desarrollados. Responsable de la validación: Ernesto Gigliotti Validación a aplicar para medir el cumplimiento de lo requerido: > Se revisarán los ejemplos generados en donde se utilizan los módulos de Python disponibles, de esta forma se valida si se cubrió la utilización de los periféricos requeridos. Req #2.x: Grupo de requerimientos referidos al entorno de desarrollo. Verificación y validación: Responsable de la verificación: Ernesto Gigliotti Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se realizarán tests unitarios de la mayoría de las partes del software. Responsable de la validación: Ernesto Gigliotti Validación a aplicar para medir el cumplimiento de lo requerido: > Se probará el ejecución del software en los diferentes sistemas operativos para los que fue diseñado y su correcto funcionamiento y conectividad con la placa. Req #3.x: Grupo de requerimientos referidos a los proyectos de ejemplo. Verificación y validación: Responsable de la verificación: Ernesto Gigliotti Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se revisará el correcto funcionamiento de los ejemplos generados, chequeando que cumplan con su propósito. Responsable de la validación: Ernesto Gigliotti Validación a aplicar para medir el cumplimiento de lo requerido: > Se revisarán las explicaciones poniéndose del punto de vista del usuario, para asegurarse de un claro entendimiento de las mismas. Req #4.x: Grupo de requerimientos generales. Verificación y validación: Responsable de la verificación: Ernesto Gigliotti Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se evaluará que sea posible publicar la información en la web del proyecto CIAA. Responsable de la validación: Ernesto Gigliotti Validación a aplicar para medir el cumplimiento de lo requerido: > Se pedirá a un grupo reducido de personas que prueben la plataforma para asegurarse de que la información brindada sea la correcta. Página 19 de 22

14. Comunicación del proyecto El plan de comunicación del proyecto es el siguiente: PLAN DE COMUNICACIÓN DEL PROYECTO Qué comunicar? Audiencia Propósito Frecuencia Método de comunicac. Responsable Avances generales Eric Pernia (Director) Mantener informado y obtener ideas y consejos. Mensual e mail Ernesto Gigliotti Existencia del proyecto Comunidad CIAA Informar la existencia e incentivar la participación en el proyecto. Mensual e mail Ernesto Gigliotti Nuevas features para microython Martin Ribelotta (Colaborador) Agregar al port de micropython lo desarrollado. Cuando existan versiones estables Pull Requests mediante GITHUB Ernesto Gigliotti 14. Gestión de Compras No se realizará ninguna compra para la realización del proyecto ya que se cuenta con todos los materiales necesarios para el proyecto. Página 20 de 22

16. Seguimiento y control SEGUIMIENTO DE AVANCE Tarea del WBS Indicador de avance Frecuencia de reporte Responsable de seguimiento Persona a ser informada Método de comunicac. 1.x Cantidad de periféricos soportados única vez Ernesto Gigliotti Eric Pernia e mail 2.x Software Completo y estable única vez Ernesto Gigliotti Eric Pernia e mail 3.x Los tests pasaron satisfactoriamente única vez Ernesto Gigliotti Eric Pernia e mail 4.x Los tests pasaron satisfactoriamente única vez Ernesto Gigliotti Eric Pernia e mail 5.x Cantidad de ejemplos desarrollados única vez Ernesto Gigliotti Eric Pernia e mail 6.x Cantidad de bibliotecas documentadas única vez Ernesto Gigliotti Eric Pernia e mail 7.x Se terminó de escribir el trabajo final única vez Ernesto Gigliotti Eric Pernia e mail Página 21 de 22

17. Procesos de cierre Pautas de trabajo que se seguirán para analizar si se respetó el Plan de Proyecto original: Se revisará que se hayan cumplido los requerimientos, comparándolos con el proyecto terminado. A cargo de Ernesto Gigliotti. Identificación de las técnicas y procedimientos útiles e inútiles que se utilizaron, y los problemas que surgieron y cómo se solucionaron: Para verificar si las tareas fueron realizadas en el tiempo esperado, se comparará el cronograma propuesto con el real, detectando las que llevaron mucho más tiempo de lo planeado y de esta forma poder analizar en dónde falló la planificación. A cargo de Ernesto Gigliotti. Por último se enviará un e mail de agradecimiento al director de la tesis y los colaboradores del proyecto, así como también a los coordinadores de la carrera y toda la gente que se sume a utilizar y probar la plataforma durante el transcurso del desarrollo. Página 22 de 22