ACTIVIDAD: TALLER Y LABORATORIO – AUTOMATIZACIÓN DE MEMORIAS ROM Y RAM

Universidad del Pacífico
Programa: Ingeniería de Sistemas
Asignatura: Arquitectura de Hardware
Semestre: Sexto
Jornadas: Diurna y nocturna
Modalidad: Trabajo grupal – Grupos previamente conformados
Herramienta obligatoria: Proteus
Entregables: Informe técnico institucional + Archivo de simulación Proteus + Vídeo explicativo.

1. Descripción de la actividad

Como se explicó detalladamente durante las tres últimas clases de Arquitectura de Hardware, tanto en la jornada diurna como nocturna, cada grupo deberá desarrollar un Taller y Laboratorio de Automatización de Memorias ROM y RAM, mediante el diseño y simulación de un circuito electrónico en Proteus.

El circuito deberá integrar obligatoriamente:

• Dos (2) memorias ROM externas.

• Dos (2) memorias RAM externas.

• Un (1) bus de datos compartido.

• Un (1) bus de direcciones compartido.

• Un sistema de bus de control compartido, con las señales necesarias para seleccionar cada memoria y ejecutar las operaciones correspondientes.

• Elementos de entrada y visualización que permitan ingresar, consultar y verificar la información almacenada.

El objetivo es automatizar el almacenamiento y la recuperación de información, utilizando como datos de prueba los números de cédula de los integrantes del grupo.

Los estudiantes podrán utilizar microcontroladores, como Arduino u otros compatibles con Proteus, para controlar y automatizar el funcionamiento de las cuatro memorias externas.

Importante: Las memorias RAM y ROM deben ser componentes externos independientes dentro del circuito. No se aceptará reemplazarlas únicamente por la memoria interna de un microcontrolador.

2. Requisitos obligatorios del circuito

A. Integración de las cuatro memorias

Diseñar un único circuito que permita acceder individualmente a las dos memorias ROM y las dos memorias RAM, utilizando los buses compartidos.

El sistema deberá identificar y seleccionar correctamente cada memoria, evitando conflictos de comunicación en el bus de datos.

B. Memorias ROM – Lectura de información

Las dos memorias ROM deberán contener información previamente programada, correspondiente a los números de cédula de los integrantes del grupo.

El circuito deberá permitir:

• Seleccionar cualquiera de las dos memorias ROM.

• Acceder a diferentes direcciones de memoria.

• Leer los datos previamente almacenados.

• Visualizar y comprobar que la información recuperada corresponde con los datos programados.

Aclaración: Las memorias ROM se programan previamente. Durante la simulación se deberá demostrar su lectura, sin exigir escritura en tiempo de ejecución.

C. Memorias RAM – Escritura y lectura

Las dos memorias RAM deberán permitir almacenar temporalmente los números de cédula de los integrantes del grupo.

El sistema deberá permitir:

1. Seleccionar la memoria RAM que se desea utilizar.

2. Ingresar el número de cédula mediante los elementos de entrada diseñados.

3. Seleccionar o asignar las direcciones de memoria.

4. Escribir y almacenar los datos.

5. Acceder posteriormente a las mismas direcciones.

6. Leer los datos almacenados y comprobar que corresponden con la información ingresada.

Los números de cédula podrán almacenarse en varias posiciones de memoria, según la capacidad y organización de las memorias seleccionadas. El grupo deberá explicar la codificación utilizada.

D. Bus de datos, direcciones y control

El circuito deberá utilizar una arquitectura de buses compartidos para comunicar las cuatro memorias.

Los estudiantes deberán explicar y demostrar:

• Cómo se selecciona cada memoria ROM o RAM.

• Cómo se determina la dirección de memoria.

• Cómo se transfieren los datos por el bus compartido.

• Cómo funcionan las señales de lectura y escritura.

• Cómo se evita que dos memorias transmitan simultáneamente sobre el bus de datos.

• Cómo se realiza la comunicación entre el sistema de control y las memorias externas.

Se permite utilizar decodificadores, multiplexores, registros, buffers, microcontroladores y demás componentes necesarios.

No se aceptarán cuatro circuitos independientes. Las cuatro memorias deberán funcionar integradas en una misma arquitectura.

E. Automatización del proceso

El sistema deberá automatizar las operaciones de selección, direccionamiento, escritura y lectura, según corresponda.

El usuario deberá poder seleccionar o solicitar una operación, mientras que el circuito ejecuta automáticamente la secuencia necesaria para acceder a la memoria.

Podrán utilizarse pulsadores, teclados matriciales, displays, pantallas LCD, indicadores LED u otros elementos para ingresar datos, seleccionar operaciones y visualizar los resultados.

No será suficiente cambiar manualmente los valores de los buses desde Proteus para simular las operaciones. Debe existir un mecanismo de control y automatización implementado dentro del circuito.

F. Verificación de los números de cédula

El sistema deberá demostrar que los datos se almacenan y recuperan correctamente.

Para ello, cada grupo deberá:

• Mostrar la lectura de los números de cédula previamente programados en ROM.

• Ingresar y almacenar números de cédula en RAM.

• Cambiar de dirección o seleccionar otra memoria.

• Regresar a las posiciones utilizadas y recuperar los datos.

• Comparar y verificar que los números recuperados coinciden con los almacenados.

Nota: Los estudiantes podrán utilizar números de cédula de prueba o ficticios, con la misma estructura de sus documentos, para evitar divulgar información personal en el vídeo público.

3. Vídeo explicativo obligatorio

Cada grupo deberá elaborar un vídeo demostrando el funcionamiento completo del circuito en Proteus.

Todos los integrantes del grupo deben participar activamente en la explicación.

El vídeo deberá mostrar:

1. Presentación del proyecto y de sus integrantes.

2. Explicación de los componentes utilizados.

3. Identificación de las dos memorias ROM y las dos RAM.

4. Explicación de los buses de datos, direcciones y control.

5. Demostración de la selección de las cuatro memorias.

6. Lectura de los números almacenados previamente en ROM.

7. Ingreso y escritura de números de cédula en RAM.

8. Lectura y recuperación de los datos almacenados en RAM.

9. Funcionamiento de la automatización implementada.

10. Explicación de las mejoras creativas e innovaciones desarrolladas.

Muy importante: Las memorias RAM son volátiles y los datos escritos durante la simulación pueden perderse cuando esta se detiene o reinicia. Por lo tanto, el vídeo deberá demostrar, durante una misma ejecución de la simulación, el proceso completo de escritura, almacenamiento y posterior lectura de los datos.

No será suficiente presentar capturas de pantalla o explicar únicamente cómo se utiliza Proteus.

El vídeo debe mostrar el circuito en funcionamiento y evidenciar claramente que los cuatro dispositivos de memoria operan de manera integrada.

4. Informe técnico – Formato institucional obligatorio

El informe deberá elaborarse utilizando exclusivamente el documento adjunto:

Formato presentacion documentos – IS Unipacifico 2026.docx

Se debe conservar la estructura, presentación y organización del formato institucional del Programa de Ingeniería de Sistemas.

El documento deberá incluir:

• Título, identificación de los autores y resumen.

• Índice de términos.

• I. Introducción.

• II. Objetivos.

• III. Marco teórico o conceptual.

• IV. Materiales y herramientas.

• V. Metodología o desarrollo.

• VI. Resultados y análisis.

• VII. Dificultades encontradas (opcional).

• VIII. Conclusiones.

• Anexos.

• Referencias bibliográficas en formato IEEE.

En la metodología deberán explicar detalladamente la arquitectura del circuito, las conexiones, el funcionamiento de los buses, el direccionamiento, las señales de control, la automatización y las pruebas realizadas.

En resultados deberán incluir evidencias claras de lectura de ROM, escritura y lectura de RAM y recuperación correcta de los números almacenados.

Se deberá incorporar el enlace del vídeo explicativo en los anexos del informe, debidamente identificado.

El informe se entregará únicamente en formato PDF. No se aceptarán informes elaborados en formatos diferentes al institucional suministrado.

5. Creatividad e innovación – 50%

La creatividad constituye el 50% de la calificación total de la actividad.

Se valorará especialmente:

• Automatización de los procesos.

• Integración eficiente de las cuatro memorias.

• Diseño de interfaces para ingreso y visualización de datos.

• Selección automática de memorias y direcciones.

• Mecanismos de verificación de los números almacenados.

• Mejoras funcionales que amplíen lo explicado en clase.

• Originalidad y calidad técnica de la solución.

La creatividad deberá evidenciarse en el funcionamiento real del circuito y no solamente en su presentación gráfica.

6. Criterios de evaluación

Se evaluará el funcionamiento real del sistema, la calidad de la integración de los componentes y la capacidad de demostrar y explicar técnicamente las operaciones exigidas.

7. Instrucciones de entrega en Moodle – AVAS

Subir a esta carpeta los archivos correspondientes al Taller y Laboratorio – Automatización de Memorias ROM y RAM.

La entrega deberá contener obligatoriamente:

1. Informe técnico en PDF

Elaborado en el formato institucional adjunto, incluyendo el enlace del vídeo explicativo.

2. Archivo original de simulación en Proteus

Se debe adjuntar el proyecto completo, con los archivos necesarios para abrirlo y ejecutarlo correctamente. Si se utilizan microcontroladores, incluir también el código fuente y los archivos compilados requeridos para la simulación.

3. Vídeo explicativo en YouTube

El vídeo deberá subirse a YouTube y su enlace deberá incluirse en el informe. Se recomienda configurarlo como No listado, verificando que el docente pueda visualizarlo sin solicitar permisos.

Todos los archivos deberán organizarse en una carpeta comprimida denominada:

Taller_Laboratorio_ROM_RAM_GrupoXX.zip

Fecha de entrega: domingo 8 de noviembre de 2026.
Hora límite: 23:59 horas (11:59 p. m.).
Tamaño máximo del archivo: 1 GB.

Condiciones de entrega

• El trabajo se realizará en los grupos previamente conformados.

• Se deben entregar los archivos de simulación funcionales y completos.

• Todos los integrantes deben participar en el vídeo explicativo.

• El informe deberá utilizar obligatoriamente el formato institucional suministrado.

• El vídeo debe demostrar la ejecución completa de las operaciones exigidas.

• Los archivos deben poder abrirse, ejecutarse y verificarse.

• Los nombres de los archivos no deben contener tildes ni caracteres especiales.

• La entrega debe realizarse dentro del plazo establecido en Moodle – AVAS.

Los trabajos que no cumplan los requisitos esenciales de funcionamiento, documentación y evidencias serán evaluados de acuerdo con los criterios establecidos, aplicando las deducciones correspondientes.

8. Observación final del docente

Se recuerda a todos los estudiantes de las jornadas diurna y nocturna que durante las tres últimas clases se explicó detalladamente el propósito, funcionamiento esperado y alcance de este taller y laboratorio.

La actividad consiste en diseñar un único circuito en Proteus que integre dos memorias ROM y dos memorias RAM externas, utilizando buses compartidos de datos, direcciones y control, y que permita automatizar la lectura y escritura de información según el tipo de memoria.

El propósito es que cada grupo demuestre que comprende cómo se almacena, direcciona, transmite y recupera la información dentro de un sistema de memoria.

No se trata simplemente de conectar cuatro memorias, sino de lograr que las cuatro funcionen correctamente dentro de un sistema integrado, automatizado y verificable.

Se espera que cada grupo aplique los conocimientos adquiridos, analice las soluciones presentadas en clase y desarrolle una propuesta funcional con creatividad, criterio técnico y capacidad de sustentación.

Segunda entrega – Avance del Proyecto Final

Implementación de subsistemas, comunicación y validación física – Corte 2

En esta segunda entrega, cada grupo deberá presentar el avance funcional del Proyecto Final de la asignatura Arquitectura de Hardware, dando continuidad al diseño y a la simulación desarrollados durante el primer corte.

El propósito de esta fase es demostrar que el proyecto ya cuenta con una implementación física parcial, funcional y validada, integrando principalmente el Arduino UNO, sensores, actuadores, mecanismos de control, alimentación y comunicación entre subsistemas.

En esta etapa se espera que el sistema pueda ejecutar físicamente las acciones previstas para el proyecto, aun cuando la decisión final todavía pueda provenir de comandos de prueba o de una lógica temporal de validación. La integración completa de la cámara, la Inteligencia Artificial, FreeRTOS y la inferencia local sobre el ESP32-S3 CAM se consolidará en la entrega final del tercer corte.

1. Informe técnico del avance

El grupo deberá actualizar el informe técnico utilizando el Formato de Presentación de Documentos del Programa de Ingeniería de Sistemas – Universidad del Pacífico, suministrado en Moodle.

El informe deberá entregarse en formato PDF e incluir, como mínimo:

• Título del proyecto.
• Nombres completos, códigos y correos institucionales de los integrantes.
• Resumen actualizado del avance.
• Introducción.
• Problema y justificación.
• Objetivo general y objetivos específicos.
• Marco teórico o conceptual relacionado con los componentes implementados.
• Arquitectura actualizada del sistema.
• Descripción de las modificaciones realizadas respecto al Corte 1.
• Identificación de sensores implementados.
• Identificación de actuadores implementados.
• Descripción del subsistema desarrollado con Arduino UNO.
• Descripción del sistema de control mediante GPIO, PWM, ADC, temporizadores o interrupciones, según corresponda.
• Diseño y justificación de la alimentación eléctrica.
• Descripción del protocolo de comunicación previsto o implementado entre ESP32-S3 CAM y Arduino UNO.
• Pruebas funcionales realizadas.
• Resultados y análisis técnico.
• Avance del dataset o conjunto de imágenes que será utilizado posteriormente para la IA.
• Dificultades encontradas y soluciones implementadas.
• Conclusiones.
• Referencias bibliográficas en formato IEEE.

Las figuras, diagramas, tablas, esquemas eléctricos y capturas deberán estar correctamente numerados, identificados y explicados. El formato institucional exige que los resultados no se limiten únicamente a mostrar imágenes, sino que incluyan interpretación y análisis técnico. Formato presentacion documentos…

2. Implementación física obligatoria

En esta segunda entrega, el grupo deberá demostrar físicamente el funcionamiento de los subsistemas principales del proyecto.

Como mínimo, deberá existir:

• Arduino UNO funcional.
• Un sensor o entrada física real.
• Un actuador físico real.
• Control mediante GPIO, PWM, ADC o interrupciones, según el proyecto.
• Alimentación adecuada.
• Driver de potencia cuando corresponda.
• Comunicación serial o mecanismo equivalente.
• Respuesta del sistema ante distintos comandos o condiciones.

Ejemplos:

• Un vehículo deberá mover motores y responder a órdenes de avance, giro y parada.
• Un clasificador deberá accionar servos o compuertas.
• Un sistema de acceso deberá mover una barrera.
• Un contador deberá detectar eventos y evitar duplicidad.
• Un sistema de selección deberá ejecutar correctamente las secuencias físicas previstas.

3. Comunicación entre ESP32-S3 CAM y Arduino UNO

El grupo deberá definir y, preferiblemente, implementar la comunicación entre ambos controladores.

Se recomienda utilizar:

UART

u otro protocolo técnicamente justificado.

El protocolo deberá incluir:

• comando;
• identificación de acción;
• confirmación o respuesta;
• manejo de comando inválido;
• comportamiento ante pérdida de comunicación.

Ejemplo:

ACTION:LEFT

ACTION:RIGHT

ACTION:STOP

ACTION:SAFE

Arduino UNO podrá responder:

ACK:LEFT

ACK:STOP

En esta etapa, si el ESP32-S3 CAM aún no genera automáticamente la decisión, los comandos podrán ser enviados manualmente desde un terminal o desde un programa de prueba.

Lo importante es comprobar que:

el sistema físico ejecuta correctamente la acción asociada al comando recibido.

4. Simulación en Proteus

El grupo deberá actualizar, complementar o corregir la simulación realizada en el primer corte utilizando el software Proteus, disponible para descarga en la plataforma AVAS.

La simulación deberá reflejar, en la medida en que Proteus lo permita:

• sensores;
• entradas digitales o analógicas;
• actuadores;
• Arduino UNO;
• lógica de control;
• señales PWM;
• comunicación;
• estados del sistema.

La simulación deberá coincidir con la arquitectura física presentada.

5. Diseño eléctrico y alimentación

El grupo deberá documentar:

• fuente o fuentes utilizadas;
• niveles de voltaje;
• GND común cuando corresponda;
• driver de motores o actuadores;
• resistencias;
• protecciones;
• consumo aproximado;
• adaptación de niveles lógicos si se utiliza comunicación entre 3,3 V y 5 V.

No se permitirá alimentar motores, servos de potencia o cargas similares directamente desde un GPIO.

6. Validación de sensores y actuadores

Cada grupo deberá realizar y documentar pruebas como mínimo sobre:

1. Lectura del sensor.
2. Respuesta del actuador.
3. Ejecución de distintos comandos.
4. Comando inválido.
5. Pérdida de comunicación.
6. Estado seguro.
7. Integración de entrada + procesamiento + salida.

Se recomienda presentar una tabla como:

7. Avance del dataset y componente de IA

Aunque la IA completa se integrará en el tercer corte, en esta entrega cada grupo deberá demostrar avance real en la preparación del componente visual.

Deberán presentar:

• clases definitivas;
• imágenes preliminares;
• criterios de etiquetado;
• condiciones de captura;
• variaciones de iluminación;
• distancia;
• orientación;
• fondo;
• estrategia de entrenamiento.

El banco de proyectos establece que el producto final deberá incorporar un modelo entrenado o adaptado, con inferencia local en la tarjeta, dejando RGB/HSV como referencia inicial y YOLO como opción avanzada cuando sea compatible. Banco 10 Proyectos Arquitectura…

8. Entregables

Dentro de una única carpeta deberán incluirse:

1. Informe técnico en PDF.
2. Archivos completos de simulación en Proteus.
3. Código fuente de Arduino UNO.
4. Código o programa utilizado para enviar comandos de prueba.
5. Diagrama de arquitectura actualizado.
6. Esquemático eléctrico.
7. Tabla de pruebas.
8. Evidencias fotográficas del montaje físico.
9. Evidencias del funcionamiento.
10. Avance del dataset.

9. Organización de la carpeta

La carpeta deberá denominarse:

Entrega_Avance_Proyecto_Final_2

Estructura sugerida:

Entrega_Avance_Proyecto_Final_2
│
├── Informe_Proyecto_Corte2.pdf
│
├── Simulacion_Proteus
│ └── Archivos completos
│
├── Codigo_Arduino
│ └── Archivos fuente
│
├── Evidencias
│ └── Fotografias_pruebas
│
└── Dataset_Avance

Posteriormente, la carpeta deberá comprimirse en uno de los siguientes formatos:

.ZIP,

El archivo comprimido no deberá superar los 1GB.

10. Nombre del archivo

Se recomienda utilizar:

Avance_Proyecto_Final_2_GrupoXX.zip

Ejemplo:

Avance_Proyecto_Final_2_Grupo03.zip

El nombre del archivo no debe contener tildes, ñ, caracteres especiales ni símbolos adicionales.

11. Entrega por grupo

La actividad se desarrollará en los mismos grupos conformados para el Proyecto Final.

Se realizará:

una sola entrega por grupo.

Todos los integrantes deberán conocer:

• arquitectura;
• circuito;
• sensores;
• actuadores;
• protocolo;
• código;
• pruebas;
• decisiones técnicas.

12. Aspectos a evaluar

En esta segunda entrega se valorará especialmente:

• Evolución respecto al primer corte.
• Corrección de observaciones anteriores.
• Funcionamiento del Arduino UNO.
• Integración de sensores.
• Control de actuadores.
• Uso adecuado de PWM, ADC, GPIO o interrupciones.
• Comunicación y protocolo.
• Diseño eléctrico.
• Alimentación segura.
• Calidad de las pruebas.
• Manejo de errores.
• Avance real del dataset.
• Calidad del informe.

13. Alcance de esta entrega

En este punto del semestre, el proyecto deberá poder demostrar:

ENTRADA / SENSOR → ARDUINO UNO → CONTROL → ACTUADOR

y, adicionalmente:

COMANDO EXTERNO / ESP32-S3 → COMUNICACIÓN → ARDUINO UNO → ACCIÓN

Todavía no se exige como requisito principal que la decisión sea generada completamente por la IA.

Esa sustitución se realizará en el tercer corte:

CÁMARA → IA → DECISIÓN → COMUNICACIÓN → ARDUINO → ACTUACIÓN

Fecha y hora límite de entrega

La fecha y hora serán las indicadas en Moodle para la actividad.

Jueves 12 de noviembre de 2026

Hora: 23:59 Hrs (11:59 p.m.)

Verifique cuidadosamente el cierre antes de realizar la entrega.

Las entregas posteriores a la fecha y hora establecidas estarán sujetas a las condiciones académicas definidas por el docente.

Recordatorio final

Antes de cargar el archivo deberán verificar que:

• el informe está en PDF;
• la simulación abre correctamente;
• el código compila;
• el montaje físico funciona;
• los sensores responden;
• los actuadores responden;
• los comandos se interpretan correctamente;
• el estado seguro está definido;
• todos los archivos están incluidos;
• la carpeta está comprimida;
• el archivo no supera 20 MB;
• el nombre no contiene caracteres especiales.

La Segunda Entrega corresponde al prototipo funcional intermedio del Proyecto Final. El objetivo es que al terminar el Corte 2 la parte electrónica, de control y actuación se encuentre estable, de manera que el Corte 3 pueda concentrarse en la integración del ESP32-S3 CAM, FreeRTOS, cámara e Inteligencia Artificial.