1
Objetos para programar puertos serie y paralelo
SerialPort, Web Serial y pySerial. El paralelo queda como legado.
Puertos e interfaces
Comunicación serie y Mesa Dorada
P2-Actividad colaborativa. Exposición.
Desarrollo de Interfaces para Computadora
- Diego Ronaldo Sánchez Pichardo 219961
- Gael Mateo Pérez Montejo 219957
Agenda
En esta exposición cubrimos cuatro temas de puertos e interfaces y, al final, Mesa Dorada, el sitio de reservaciones del restaurante en Villahermosa.
2
Diseño de interfaz gráfica con conectividad a puertos
Estado, registro y errores visibles. La lectura no congela la pantalla.
3
Una app con interfaz conectada al puerto serie
El monitor de temperatura muestra el patrón: sensor, puerto y alerta.
4
Aplicaciones que transfieren datos por puertos estándar
RS-232, USB CDC, tickets, lectores y PLC.
5
Mesa Dorada: requisitos, pantallas, datos y la reservación
Los tres roles (Clientes, Frontend y Backend) los cubrimos entre los dos.
Objetos para programar puertos serie y paralelo
Para hablar con un puerto serie no se programa el hardware bit a bit. Se usa un objeto que ya encapsula la conexión: abrir, configurar, leer, escribir y cerrar.
SerialPort
Open, Close, Read y Write. El evento DataReceived avisa cuando llegan datos. Corre en un hilo aparte, así que la interfaz se actualiza con cuidado.
Web Serial API
requestPort() y luego port.open con el baudRate. Se leen y escriben streams. Pide permiso expreso y funciona sobre todo en Chrome y Edge, con HTTPS.
pySerial
Se abre con puerto, baudrate, parity, bytesize y stopbits. Después se usa read, write y readline.
Puerto paralelo
Hoy es legado (LPT, IEEE 1284). Se usaba para impresoras y para salida digital simple de 8 bits. En Windows moderno casi no se usa. Si hace falta, se recurre a un adaptador USB o a una librería de acceso de bajo nivel.
Propiedades de la serie
BaudRate9600 o 115200
ParityNone, Even, Odd
DataBitscasi siempre 8
StopBits1 o 2
Típica115200 8N1
Diseño de interfaz con conectividad a puertos
Una interfaz de puertos tiene que dejar claro si hay conexión, qué está pasando y qué salió mal. Si el usuario no ve el estado, no confía en la app.
Puerto COM3
conectado
115200 8N1
12:01 TX abierto COM3 · 115200 8N1
12:01 RX T:24.5
12:01 RX T:24.6
12:02 TX LED:ON
12:02 RX T:24.8
12:03 RX T:24.7
12:03 TX ack
TX es salida. RX es entrada. La pantalla sigue viva.
Indicador de estado
desconectado / error
conectando
conectado, con la config al lado
Errores claros
- puerto ocupado
- dispositivo desconectado
- tiempo de espera agotado
- permiso denegado
- error de trama
La lectura no debe congelar la interfaz. Se atiende en un hilo o con eventos, y la pantalla se actualiza en el hilo de la UI. El mismo panel serviría para una impresora o una terminal junto a Mesa Dorada.
Una app con interfaz conectada al puerto serie
Ejemplo: un monitor de temperatura con Arduino. El microcontrolador lee un sensor y envía por el puerto serie una línea como T:24.5, a 115200 baudios. La app la recibe, la muestra y avisa si pasa un umbral.
→
→
→
T:--.-T:24.5
alerta de umbral
1SENSORConectado al Arduino. De ahí sale la lectura de temperatura.
2ARDUINOEscribe la línea por el puerto serie. USB CDC aparece como COM.
3CONEXIÓNSe elige el puerto y se abre. La config típica es 115200 8N1.
4PANTALLALa app parsea cada línea y actualiza la etiqueta o una gráfica.
5ALERTASi el valor pasa el umbral, se enciende el aviso en pantalla.
6CIERREAl salir se cierra el puerto y queda libre para otro programa.
Puente con Mesa Dorada. Este flujo es el mismo patrón: un periférico envía o recibe texto y la interfaz reacciona. Al confirmar una reserva, una impresora podría sacar el ticket de cocina. Hoy la reserva termina en el folio y el QR.
Aplicaciones que usan transferencias por puertos estándar
Los puertos estándar siguen en uso, aunque hoy muchos dispositivos llegan como USB y el sistema los expone como un puerto serie virtual.
RS-232
El serie clásico (conector DB9 o DB25). Todavía aparece en equipo industrial y en adaptadores USB a serie.
DB9 · DB25
USB CDC
El dispositivo se presenta como un puerto COM virtual. Es el caso de muchos Arduino y de chips como CH340, CP2102 o FT232.
COM virtual
Tickets POS
Suelen hablar ESC/POS por USB o por serie. Reciben un texto o una secuencia de comandos y entregan el ticket térmico.
ESC/POS
Lectores
Unos se hacen pasar por teclado (HID) y otros envían la lectura por serie o por USB CDC. Un lector podría tomar el folio que ya entrega Mesa Dorada.
HID o CDC
PLC industriales
Un protocolo habitual es Modbus RTU, sobre RS-232 o RS-485. El mismo cuidado de estado y de errores aplica cuando el puerto no es un COM de laboratorio.
Modbus RTU
Posible integración con Mesa Dorada. Cuando confirmamos, el sitio ya muestra folio, QR y depósito simulado. Conectar una impresora de tickets para cocina, un lector de ese folio o una terminal para el depósito sería esta misma transferencia. Esa conexión no está hecha en el sistema.
Lo que pedimos como clientes
Para Mesa Dorada nos pusimos en el lugar de quien reserva una mesa y de quien recibe en el salón. De ahí salieron los requisitos del sitio y del panel del host.
Quien reserva necesita
- 01 Buscar rápido por fecha, hora y personas desde el inicio.
- 02 Ver el menú con alérgenos y filtros.
- 03 Reservar con un asistente de 4 pasos y disponibilidad real.
- 04 Recibir folio, código QR y un depósito simulado.
- 05 Consultar su reservación.
- 06 Ver ubicación y contacto, y ajustar tema e idioma.
Quien atiende necesita
- 01 Mapa de mesas, incluidas las que se pueden unir.
- 02 Libro del día de un vistazo.
- 03 Turnos del servicio.
- 04 Clientes y su folio.
- 05 Reportes del servicio.
- 06 Administración con permisos según el rol.
Pantallas que diseñamos
Buscamos una interfaz rápida, con botones claros y formularios cortos. El sitio del comensal y el panel del host comparten la paleta cálida de Mesa Dorada.
01 INICIO
BÚSQUEDA RÁPIDA
12 nov
16:30
4
Ver disponibilidad
02 MENÚ
GlutenLácteosNuecesMariscos
Entradagluten
Plato fuertelácteos
Pescadomariscos
Postrenueces
03 MI RESERVACIÓN
FOLIO
MD-1842
Gael Mateo Pérez Montejo
4 personas · 16:30
Depósito simulado
04 PANEL DEL HOST
Mesa 1
ocupada
ocupada
2 + 3
unidas
unidas
Mesa 4
libre
libre
Mesa 5
libre
libre
Asistente de 4 pasos: de la búsqueda a la confirmación sin rodeos.
Filtros de alérgenos visibles en el menú, no escondidos en una nota.
Tema claro u oscuro, y el idioma ES / EN, a la mano en el sitio.
El folio y el QR dejan la confirmación clara en mi reservación.
Datos, reglas y seguridad
Monorepo con apps/api, apps/web, packages/shared y e2e. Bun y Hono en el API, PostgreSQL con Drizzle, React 19 con Vite, TanStack y Tailwind v4 en la web.
Clientes
- Reserva la mesa
- Consulta su folio y el QR
- Revisa el estado
1 a N
Reservaciones
- Folio y estado
- Personas, fecha y hora
- Una por mesa y turno
N a 1
Mesas
- Tienen capacidad
- Se pueden unir
- Vuelven a quedar libres
Usuarios
- Rol y permisos
- Libro y mapa
- Turnos y reportes
1 a 1
Depósito
- Es simulado
- Uno por reservación
- Ligado al folio
en
Turnos
- Arman el libro del día
- Ordenan el salón
- Cierran la mesa
Menú
Platillos y alérgenos, aparte de la reserva. El filtro del sitio sale de aquí.
BunHonoZodDrizzlePostgreSQLReact 19ViteTanStackTailwind v4Playwright
Reglas de negocio
- Disponibilidad real antes de confirmar.
- Mesas unibles si el grupo no cabe en una sola.
- Sin doble reserva en el mismo turno.
- El panel muestra solo lo que el rol permite.
Seguridad
CSRF en lo que cambia datos, rate limit en el API y validación con Zod antes de guardar. Playwright cubre el flujo de extremo a extremo.
Recorrido de Mesa Dorada
Así se ve el flujo que vamos a recorrer: inicio, disponibilidad con mesas unibles, folio con QR y el libro del host.
1 · INICIO Y BÚSQUEDA
Busca tu mesa
Fecha 12 nov
Hora 16:30
4 personas
Ver disponibilidad
2 · ASISTENTE, PASO DE MESA
01 Datos02 Horario03 Mesa04 Confirmar
Mesa 4 libre · cabe el grupo
Mesas 2 y 3 unibles
Mesa 1 ocupada en ese horario
3 · FOLIO, QR Y DEPÓSITO
FOLIO
MD-1842
Gael Mateo Pérez Montejo
Depósito simulado registrado
4 · LIBRO DEL DÍA
14:00Diego Ronaldo Sánchez Pichardo · mesa 1 · 2 personas
16:30Gael Mateo Pérez Montejo · mesas 2 y 3 · folio MD-1842
1 ocupada
2 + 3 unidas
4 libre
5 libre
Si en el salón hubiera impresora, el mismo aviso podría salir en ticket. En el sistema el cierre es el folio, el QR y el depósito simulado. El host lo ve en el mapa y en el libro.
Cómo funciona la app
Este recorrido une lo que pedimos como clientes, lo que se ve en pantalla y las reglas del API.
1
Búsqueda
- Fecha
- Hora
- Número de personas
2
Disponibilidad
- Mesas libres
- Mesas unibles
- Sin doble reserva
3
Confirmación
- Zod valida
- Se guarda
- Sale el folio
4
Folio y QR
- Código en pantalla
- Depósito simulado
- MD-1842 · 4 personas · 16:30
5
Servicio
- Libro del día
- Mapa de mesas
- Turno del host
6
Cierre
- Termina el turno
- Se libera la mesa
- Lista para otra reserva
Una impresora de cocina, un lector del folio o una terminal de pago entrarían en el paso 4. Quedan como integración posible, no como parte del sistema.
Cómo nos repartimos los roles
La actividad pide tres roles: Clientes, Frontend y Backend. Los cubrimos entre los dos, sobre Mesa Dorada.
LOS DOS
Clientes
Definimos qué necesita quien reserva y quien recibe en el salón.
- Búsqueda rápida desde el inicio
- Menú con alérgenos y filtros
- Folio, QR y depósito simulado
- Libro del día, mapa y permisos
DIEGO LIDERA, GAEL APOYA
Frontend
Diego lideró las pantallas y la paleta. Gael revisó que el flujo se sienta rápido.
- Inicio, menú y mi reservación
- Asistente de 4 pasos
- Tema claro u oscuro, ES y EN
- Panel del host: mapa y libro
DIEGO LIDERA, GAEL APOYA
Backend
Diego lideró el modelo y las reglas. Gael apoyó en los casos de prueba.
- Disponibilidad real
- Mesas unibles, sin doble reserva
- Roles y permisos del panel
- Zod, CSRF y rate limit
Diego Ronaldo Sánchez Pichardo
Gael Mateo Pérez Montejo
Lo que nos llevamos
Gracias. ¿Preguntas?