1. Introducción¶

En este capítulo se presenta una introducción a la asignatura de laboratorio SDG2, y la descripción general del proyecto de la asignatura y la organización de este. Aquí se podrá encontrar información sobre la evaluación y el calendario que se seguirá.

1.1 Sistemas Digitales II¶

La asignatura se imparte con una metodología de Aprendizaje Basado en Proyectos ². Los alumnos tienen como objetivo realizar el desarrollo de un sistema electrónico empotrado complejo basado en un microcontrolador de bajas prestaciones partiendo de una descripción y unas especificaciones básicas. Este aprendizaje requiere por tu parte el manejo de distintas fuentes de información y disciplinas necesarias para resolver problemas. Tu papel ha de ser activo, con un compromiso y responsabilidad por tu propio aprendizaje. Trabajarás en parejas desde el principio y desarrollarás un proyecto planificando la actuación, distribuyendo las tareas, evaluando las posibles consecuencias, y previendo los éxitos.

Como indica la Guía de Aprendizaje Basado en Proyectos del Servicio de Innovación Educativa-UPM ², y a modo de resumen, las características más relevantes a las que debe atender son (recuperado de la Guía de Aprendizaje de la asignatura):

• No existe una única solución correcta.

• Se presenta la situación y los alumnos tienen que ampliar la información para avanzar en el proyecto.

• El papel del profesor es supervisar y revisar el plan de trabajo y evolución de cada pareja, utilizando las clases de laboratorio y las tutorías para ayudar a resolver dudas. El profesor tiene también el papel de evaluar el progreso y trabajo final.

• La interacción con el alumno se da en las sesiones de laboratorio: orientación a las dudas y problemas encontrados para seguir el progreso de los estudiantes para evitar equivocaciones, corregir errores conceptuales y orientar el aprendizaje. Se realiza un seguimiento de cada pareja. También en las tutorías.

• El lugar de trabajo es el laboratorio y fuera de este.

Las sesiones de laboratorio plantean al alumno ir consiguiendo hitos que corresponderán a ciertos niveles de desarrollo (funcionalidad) del proyecto. El proyecto propuesto se divide en 4 versiones básicas más una versión final de libre elección. Las versiones básicas son requisitos de funcionalidad obligatorios, pero para completar el proyecto y conseguir la máxima nota las parejas deberán implementar la versión final de libre elección.

Harás frente a un caso real de diseño e implementación de un sistema electrónico basado en microcontrolador de bajas prestaciones, empleando los medios disponibles en el laboratorio B-043 y componentes electrónicos —alguno de los cuales deberá adquirir— (ver materiales en ).

Como has venido trabajando en CELT, el laboratorio estará abierto durante \(2h30'\). Si se quiere hacer una analogía con las clases teóricas, las horas con profesor son \(2h\) de supervisión puramente dicha. El resto del tiempo es para que inicies las máquinas, prepares los montajes, y recojas ordenadamente al finalizar. El acceso al laboratorio está controlado por los maestros de laboratorio.

Por las mañanas habrá acceso libre siempre que haya un maestro de laboratorio o persona responsable que abra el laboratorio y vigile. Se recomienda que lleves tu propio material, pues no se garantiza que la persona responsable pueda hacerse cargo de los préstamos.

1.2 El proyecto Simone¶

El objetivo es desarrollar un sistema básico completamente funcional de una versión del clásico juego de memoria visual, Simón utilizando un teclado matricial y un LED RGB que permita al jugador identificar cada color que se represente por el LED con una tecla del teclado. A este sistema le vamos a llamar Simone. El sistema se basa en (i) una placa Nucleo-STM32F446RE que hará las veces de sistema central, (ii) un teclado matricial alfanumérico de membrana, y (iii) un LED RGB que cambia de color de forma aleatoria con cada secuencia de colores que crea el juego. Puede ver el video demostrativo en Demostración del sistema Simone. Al sistema básico posteriormente el alumno debe añadir más funcionalidades de su elección.

Para entender lo que vamos a construir, debemos viajar atrás en el tiempo, hasta 1978, cuando el ingeniero Ralph Baer (conocido como el padre de los videojuegos) y Howard J. Morrison presentaron al mundo el juego Simon. Este dispositivo con forma de platillo volante se convirtió en un icono de la cultura pop de los 80. Su funcionamiento era simple: un juego de memoria visual y auditiva donde la máquina generaba una secuencia progresiva de luces y sonidos aleatorios que el jugador debía repetir.

La mecánica original consistía en cuatro grandes botones de colores (rojo, verde, azul y amarillo), cada uno asociado a un tono musical específico. El juego comenzaba con una secuencia de un solo paso. Si el usuario acertaba, la máquina repetía la secuencia y añadía un nuevo paso al final. El juego terminaba cuando el usuario fallaba o tardaba demasiado en responder.

En esta práctica vamos a rendir homenaje a este clásico, pero elevando la complejidad técnica para adaptarla a un sistema embebido moderno basado en el STM32F446RE. Nuestro sistema, bautizado como Simone, mantiene la esencia del juego de memoria visual pero introduce diferencias significativas respecto al juguete original:

1. Interfaz de entrada: En lugar de cuatro botones grandes dedicados, utilizaremos un teclado matricial (desarrollado en la Versión 2). Esto nos obliga a mapear teclas específicas ('1', '2', ...) a colores.
2. Interfaz de salida: Sustituimos las cuatro bombillas independientes por un único LED RGB (desarrollado en la Versión 3). Esto implica que la secuencia no es espacial (luces en distintas posiciones), sino puramente cromática (el mismo punto de luz cambia de color).
3. Complejidad cromática: El juego original usaba 4 colores. Simone gestiona una paleta de 6 colores (rojo, verde, azul y amarillo, turquesa y blanco), aumentando la dificultad de memorización.
4. Niveles de dificultad dinámicos: Implementaremos un sistema de niveles (EASY, MEDIUM, HARD) que no solo afecta a la velocidad de reproducción, sino también a la intensidad lumínica (PWM). En los niveles difíciles, los colores se mostrarán más tenues y rápidos, poniendo a prueba tanto la memoria como la agudeza visual del jugador.
5. Feedback textual: Al carecer de altavoz en esta versión, utilizaremos la terminal de VSCode para enviar mensajes de estado, victoria o derrota, lo que nos servirá como herramienta de realimentación visual en tiempo real.

El reto de este proyecto no es solo programar la lógica del juego, sino orquestar los periféricos que construiréis a lo largo de las sesiones (botón, teclado, LED RGB) para que funcionen al unísono bajo el control de una máquina de estados finitos (FSM) central.

El alumno tiene la libertad de imaginar e implementar a través de la Versión 5 del proyecto cualquier sistema que desee. Por ejemplo: añadir un sistema de sonido, más teclados y LEDs, botones, un buzzer para generar sonidos, un LCD u otro RGB light, … o incluso añadir un sistema de comunicación inalámbrica para enviar la información a un dispositivo móvil.

El sistema correrá sobre la plataforma Nucleo-STM32F446RE (ver libro de fundamentos teórico-prácticos de la asignatura ⁴). Sería posible emplear otros modelos de placa Nucleo-STM32 si el modelo basado en el microcontrolador STM32F446RE no está disponible (*e.g.*, el modelo STM32F411RE). En dicho caso deberá realizar los pasos para adaptarse a la asignatura. Se deberá comprar una placa por pareja o una por cada miembro, si lo desea (les dará más posibilidades de hacer pruebas y nuevas implementaciones más interesantes). Los componentes electrónicos básicos se les prestan, pero se aconseja que consigáis los vuestros, sobre todo para la Versión 5 del proyecto. Para los primeros días o en caso de olvido, habrá placas de préstamo durante las sesiones de laboratorio.

Para poder trabajar en tu ordenador personal deberás tener instalado el entorno de compilación cruzada siguiendo los pasos de instalación del capítulo de la “Guía de instalación de herramientas para compilación cruzada en C” ⁵. Durante las sesiones de laboratorio no se resolverán problemas de instalación del entorno para no entorpecer al resto de compañeros que tengan dudas del proyecto. Si se tienen problemas en la instalación, se concertará una tutoría.

1.2.1 Materiales¶

La lista de materiales que se usan se muestra en la BOM del anexo. En la puede verlos agrupados por cada una de las "partidas" del proyecto: los básicos, los de la sensorización, y los de actuación.

Lo más urgente de adquirir es la placa Nucleo-STM32F446RE y el cable USB necesarios para la V1 y siguientes. El resto de HW se usará en las siguientes versiones. Durante las primeras sesiones podrás trabajar con las placas que se prestan en el laboratorio, pero no podrás llevártela. Cuando adquieras la tuya para trabajar en casa, será la que debes traer.

En el anexo se proporciona información de los componentes y un enlace para que tengas una orientación de cuál es. Puedes conseguirlos tú mismo. Muchos de dichos componentes quizás ya los tengas, como la protoboard, o los cables para la misma. El resto puedse conseguirlo en alguna tienda física de la ciudad, u online. Fíjate que algunos de los componentes no se venden por unidad en las tiendas online (quizás le convenga comprar con otros compañeros o ir a una tienda física y comprarlos unitarios). Un miembro de la pareja se responsabilizará del material prestado, que ha de devolver en la fecha del examen.

1.3 Organización (versiones)¶

El desarrollo del sistema Simone está guiado como un tutorial, por puntos. El proyecto básico son los requisitos mínimos obligatorios, y suponen el \(50\%\) del total de la calificación de la asignatura. Un \(20\%\) de la nota es la V5 (ver Evaluación y calendario).

El proyecto básico lo podemos dividir en versiones o fases, a modo de guía. Todos los códigos deberán estar documentados con Doxygen. Cada versión tiene un código de test unitarios HW y SW que se les proporcionará. Los códigos corren sobre la placa y nos da una indicación de si el sistema funciona correctamente.

Las características más importantes de cada versión son:

• Versión 1: desarrollo de la base del sistema con (i) FSM, (ii) interrupción de botón para interactuar con el juego y (iii) temporización de la pulsación con SysTick para poder iniciar y detener el juego. (iv) Por último, test unitarios y la documentación del código. (Estimado 2 semanas)

• Versión 2: desarrollo del subsistema de detección de teclas del teclado matricial con (i) FSM, (ii) excitación de las filas de manera alterna mediante interrupción de un temporizador, (iii) captura de entrada (input capture) de las columnas para detección de tecla, (iii) montaje HW del teclado, y (iv) test unitarios y documentación del código. (Estimado 3 semanas)

• Versión 3: desarrollo del subsistema de visualización (i) FSM, (ii) interrupciones de temporizadores para generación de PWM, (iii) montaje HW del LED RGB, y (iv) test unitarios y documentación del código. (Estimado 2 semanas)

• Versión 4: (i) implementación de modos de bajo consumo, (ii) integración de la FSM final del sistema y (iii) prueba y documentación del código. (Estimado 1-2 semanas)

• Versión 5: funcionalidades de libre elección del alumno. (Estimado 3 semanas)

1.4 Profesorado y turnos de laboratorio¶

El turno que elijas para asistir al laboratorio no tiene por qué coincidir con el grupo de matriculación. Puedes elegir el que mejor se ajuste a tu horario. El turno se elige por orden de inscripción en la página de Moodle de la asignatura. Típicamente habrá 2-3 profesores por turno y también podremos contar con la ayuda inestimable de los colaboradores docentes que te ayudarán en todo lo posible, aunque no tienen competencias de evaluación, i.e., para consultas de gestión de la asignatura, mejor pregunta a un profesor del turno.

Tradicionalmente un profesor se encarga de "un pasillo" del laboratorio y tiene seguimiento detallado de los alumnos de esos puestos. No obstante, siempre que sea posible se le atenderá por cualquier profesor que esté libre.

1.4.1 Turnos¶

Turnos de laboratorio

Lunes-jueves (16:30–18:30, apertura 16:00)

Viernes (10:30-12:30, apertura 10:00)

Algunos profesores pueden usar la pizarra para llevar un orden de atención a los alumnos que se vayan apuntando. Se podrá asistir al laboratorio si no es tu turno y ocupas las bancadas (pasillos) libres, si las hay. No se garantiza que haya profesores o colaboradores docentes para atenderte. Los alumnos del turno tienen preferencia.

1.4.2 Profesores y colaboradores docentes¶

Profesores

• AGH, Amadeo de Gracia Herranz (C-229) e-mail: amadeo.degracia@upm.es

• JPO, Josué Pagán Ortiz (coordinador) (C-221) e-mail: j.pagan@upm.es

• MGM, Manuel Gil Martín (coord. administrativo) (B-111) e-mail: manuel.gilmartin@upm.es

• JALM, Juan Antonio López Martín (B-111) e-mail: juanantonio.lopez@upm.es

• RCR, Román Cárdenas Rodríguez (B-305) e-mail: r.cardenas@upm.es

• RIL, Raúl Izquierdo López (C-206) e-mail: raul.izquierdo@upm.es

Colaboradores docentes

• ABG, Álvaro Basterra García
• SER, Sergio Esteban Romero
• IHA, Ignacio Hernández Abad
• IMF, Iván Martín Fernández

1.5 Evaluación y calendario¶

La asignatura tiene una componente práctica muy importante. No obstante, en esta asignatura no solo se aplican conceptos aprendidos, sino que también se adquieren otros nuevos. La asignatura tiene 2 grandes bloques de evaluación que se pueden liberar hasta la evaluación extraordinaria del mismo curso:

1. Un proyecto por parejas que tiene 2 partes:

   1. requisitos básicos obligatorios: versiones V1-V4. Es guiada. Supone un \(50\%\) de la nota total. Las especificaciones básicas del proyecto son requisitos impuestos por la asignatura

   2. funcionalidades de libre elección: V5. Desarrollo libre. Supone un \(20\%\) de la nota total.

   Las dos entregas de código (y documentación de la versión V5) se realizarán en buzones de Moodle que se abrirán cerca de la fecha de entrega. Solo un miembro de la pareja tiene que subir los ficheros fuente del proyecto. Si realiza implementaciones en V5 que incorporen HW nuevo, deberá mostrar su funcionamiento el día del examen práctico individual o cuando se convenga con su profesor asignado. En todo caso, se grabará un vídeo breve demostrativo de las funcionalidades implementadas en V5.

   Dispone de una rúbrica orientativa de evaluación del proyecto en la .

2. Un examen práctico individual que tiene el fin de diferenciar el trabajo de cada uno de los miembros de la pareja. Supone el \(30\%\) restante de la nota total.

   El examen consta típicamente de 2 ejercicios. Se proporciona un proyecto adaptado del trabajado durante el curso pero más sencillo. Este proyecto no compila y se pide que (i) se depure y corrija, y (ii) se hagan modificaciones. Se realiza en el laboratorio con los ordenadores del mismo. Se dispone de 1 hora para realizarlo. Se puede consultar la documentación que se proporciona. No se puede consultar internet. Se evalúa la capacidad de depuración de código, la capacidad de análisis y resolución de problemas, y la capacidad de implementación de soluciones. Puede ver cómo abordar esta prueba en estos vídeos de corrección de examen práctico de 2023, de 2024, y de 2025.

Se recomienda el uso de repositorios privados de código como GitHub o BitBucket para guardar el avance del proyecto cada semana. También puedes usar una memoria USB. Es responsabilidad exclusiva del alumno conservar copias de las distintas versiones del proyecto y de tus avances parciales. Los ordenadores del laboratorio se borran diariamente. No obstante, estará abierto continuamente un buzón en Moodle para que puedas subir copias de sus códigos cuando quieras. Este buzón no tiene copia de seguridad.

Es responsabilidad de la pareja protegerse de copiar o ser copiados. Los códigos pasan el anti-copy. Si se detecta una copia, la nota de los proyectos copia y copiado será 0. Sean honestos, inspírense, pregunten, pero nunca copien.

Conviene recordar que, como indica la Guía de Aprendizaje, cualquier evaluación o entrega realizada podrá requerir una evaluación oral complementaria por parte del profesor para validar que se ha realizado por el alumno sin ayuda de sistemas de Inteligencia Artificial.

Como sabrá, la normativa de la UPM ⁶ distingue entre evaluación progresiva y global. A continuación se presentan los criterios de evaluación en ambas modalidades.

1.5.1 Evaluación progresiva¶

En esta modalidad hay dos periodos de evaluación: uno a mitad de semestre y otro al final.

Puede ver el desglose de las calificaciones en la y el detalle de fechas de evaluación en el calendario de la . En particular:

• La semana de exámenes del GITST: LÍMITE de entrega por parejas versiones V1 y V2 (\(25\%\)). Solo se entrega un proyecto QUE COMPILE, hasta donde haya llegado. SI NO COMPILA, NO SE CORRIGE, Y LA NOTA ES 0. El profesor corrige con un HW idéntico al tuyo y en la siguiente sesión habrá realimentación de los problemas encontrados. El código debe compilar y cargar en la placa Nucleo-STM32F446RE. Esta fecha es el plazo límite de entrega en Moodle, y establecida dentro del periodo de evaluaciones intermedias de la ETSIT. .

• Último día lectivo: LÍMITE de entrega por parejas versiones V3 y V4 (\(25\%\)), y V5 (\(\geq20\%\)). El profesor corrige con un HW idéntico al tuyo. El código debe compilar y cargar en la placa Nucleo-STM32F446RE. Esta fecha es el plazo límite de entrega en Moodle.

  Hay que hacer 2 entregas separadas. Una para la parte obligatoria de requisitos mínimos V1-V4, y otra para V1-V5.

  Las funcionalidades de la V5 son de libre elección por el alumno, pueden ser SW, FW, o HW. Las parejas que realicen alguna implementación deberán documentarlas y explicarlas con Doxygen y Markdown utilizando una plantilla proporcionada. Con estas modificaciones SW o montajes alternativos añadidos al proyecto básico —y dependiendo de su dificultad y realización— se podrán sumar puntos hasta alcanzar la máxima nota: 10 puntos (ver ).

• En la fecha estipulada de exámenes de la ETSIT: examen práctico individual en el laboratorio (\(30\%\)). De 1 hora de duración aproximada. Se dividirá a los alumnos en varios horarios de evaluación que se harán disponibles cuando se acerque la fecha.

  El examen consiste en depurar un código dado, hacer que compile, y hacer modificaciones o pequeños desarrollos de código. Se hará con los ordenadores del laboratorio y no tendrá acceso a internet. Se le proporcionará la documentación de consulta necesaria. Puede ver cómo abordar esta prueba en estos vídeos de corrección de examen práctico de 2023, de 2024, y de 2025.

  La nota del examen ha de ser mayor de 5/10 y liberar el bloque "examen práctico"”", sino, quedará pendiente esta parte para la convocatoria extraordinaria.

  En algún momento de la jornada de evaluación, este día también (o cuando se convenga con el profesor), se realizará la demostración de las funcionalidades HW añadidas en V5, si las hay.

La gestión de los plazos también es parte del proyecto. No se aceptan proyectos después de la fecha límite. La fecha es no es la única fecha de entrega, sino la fecha límite. Si no es entrega en plazo, se va a convocatoria extraordinaria.

1.5.2 Evaluación mediante proyecto innovador¶

Dentro de la evaluación progresiva, aquellos alumnos que deseen realizar un proyecto innovador alternativo que se base en un problema o diseño propio (o propuesto por un profesor), pueden hacerlo. Deberán hablar con alguno de los profesores de la asignatura y presentarle durante la primera y segunda semana de curso una propuesta de proyecto donde describan, en 2 o 3 páginas:

• Objetivos del sistema propuesto.

• Recursos necesarios para llevarlo a cabo.

• Arquitecturas HW y SW propuestas para abordar el problema.

Para poder abordar el proyecto será necesario contar con la aprobación de dicho profesor. No será admitido ningún proyecto (por muy complejo o perfecto que sea) que no se ajuste a estas normas. En el canal de YouTube¹ de la asignatura puede ver vídeos de proyectos de alumnos en cursos pasados.

Solo se aceptarán 10 proyectos innovadores. Para poder evaluar las propuestas y que las parejas puedan comenzar a trabajar lo antes posible, disponen de no más de la segunda semana de clase para presentar la propuesta.

El proyecto es libre, no obstante ha de cubrir los conceptos básicos de la asignatura con los que se evalúa al resto de compañeros:

• Deberá trabajar con

• una base del sistema programada en C,

• donde se demuestre el manejo de registros básicos (parte del programa escrito a bajo nivel: bare-metal),

• que contenga una o varias FSM, interrupciones, y temporización.

• Metodología de proyecto como la propuesta (división de código en COMMON y PORT).

• Documentación del código con Doxygen.

• El lenguaje tipo Arduino no está permitido como base del sistema, aunque sí sobre elementos añadidos (otros microcontroladores). Cubierto lo básico en C, puede trabajar sobre el lenguaje que quiera, sea de alto nivel, o no.

• Cubierto lo anterior, sí puede hacer uso de la HAL del fabricante.

1.5.3 Evaluación global¶

En la modalidad de evaluación global se han de superar las mismas actividades que en la evaluación progresiva y tienen los mismos pesos y criterios.

El estudiante que no han hecho la entrega de V1-V2 puede optar a un \(7.5\), incluyendo V5, siempre que se cumplan los criterios de mínimos mencionados anteriormente.

1.5.4 Insignias¶

En general, las insignias, o badges en inglés, se usan como reconocimiento digital cuando se realiza un curso o una actividad. Constan de una imagen y una descripción con el nombre y los criterios que hay que cumplir para obtenerla, como se muestra en la . Sirven para reconocer logros a lo largo del curso. Están firmadas por un profesor y permite al alumno anexarla a su Curriculum Vitae, o almacenarlas en mochilas virtuales como Badgr, u OpenBadges. Puede conocer más sobre las insignias de Moodle UPM en el CanalTIC: Badges o insignias digitales. Puede leer más sobre insignias digitales en el manual “Insignias digitales como acreditación de competencias en la Universidad” ⁷.

Los profesores, bajo criterio consensuado, podrán otorgar insignias para reconocer algún mérito destacable en la asignatura. En concreto, se contemplan las siguientes insignias (ver figura de insignias):

• Para la evaluación progresiva y global:

• Mejor diseño HW: electrónica adicional, diseño de PCB, integración con otras placas, etc.

• Mejor diseño SW: funcionalidades FW o SW extras que sean significativas.

• Mejor diseño de producto: entendido como un todo, se valorará la experiencia de usuario, acabado con impresión 3D, etc.

• Proyecto destacado: proyecto que cumple funcionalidades, tiene mejoras considerables, etc. y a juicio de los profesores es un proyecto destacable.

• Para los proyecto innovadores:

• Todo proyecto innovador que lo merezca.

• El mejor proyecto innovador.

1.5.5 Rúbrica de evaluación¶

Una rúbrica “es una herramienta de puntuaciones en la que se valora la calidad de un producto (proyecto, tarea, etc.) en base a los criterios establecidos, iguales para todos los estudiantes. Dichos criterios se presentan en distintos grados y se completan según sea el producto evaluado” ². No espere ver una nota detallada de cada aspecto, sino un grado de consecución.

Para cada “Nivel de calidad” de la rúbrica existen procesos intermedios que han de ser superados aunque no queden descritos como tal en la misma. No obstante es una guía para que tenga siempre presente los objetivos de grano grueso del proyecto. El profesor puede tener mayor granularidad para evaluar parcialmente un criterio de la rúbrica que no se haya logrado en su completitud. El muestra la rúbrica del proyecto Simone.

1.5.6 Calendario¶

En la se muestra el calendario de la asignatura. A la izquierda, los días de la semana, señalando los eventos más importantes, como las evaluaciones. A la derecha un gráfico de colores para ver fácilmente qué días tiene clase cada turno. Orientativamente, se indica por qué versión del proyecto se debería ir cada semana. Ajústate lo más que puedas, no te confíes.

Fíjate que, debido a cómo es el calendario académico, hay alteraciones de los turnos que, en algunos casos nos llevan a estar varias semanas sin clase, no te distraigas durante ese tiempo para que no te cueste retomar las sesiones de laboratorio. Todos los turnos tienen el mismo número de horas de laboratorio. Las fechas de evaluación son iguales para todos los turnos.

En el curso 2025-26 se ha reducido una semana el semestre. Para mantener el número de horas de laboratorio, las 2 sesiones previas a la entrega intermedia y final serán de \(2h30'\) en lugar de \(2h\).