Un proyecto para entender circuitos en paralelo mientras programamos nuestra primera simulación de tránsito
Introducción
En nuestras clases hemos trabajado con distintos tipos de circuitos: los circuitos en serie, donde la corriente recorre un único camino y todos los componentes dependen unos de otros (si uno falla, falla todo el circuito), y los circuitos en paralelo, donde cada componente tiene su propio camino hacia la fuente y puede funcionar de manera independiente. Hoy vamos a ver cómo esa teoría que ya conocemos se convierte en un proyecto real: un semáforo peatonal programado con micro:bit, simulado en Tinkercad.
Pero este proyecto no es solo electrónica. Es, sobre todo, una excelente excusa para ejercitar el pensamiento computacional: esa forma de pensar que nos permite tomar un problema grande (controlar un semáforo real) y resolverlo paso a paso con lógica, patrones y algoritmos.
1. Repasando el circuito: ¿por qué es un circuito en paralelo?
Antes de tocar una sola línea de código, miremos el hardware. Nuestro semáforo tiene tres LEDs (rojo, amarillo y verde), cada uno conectado a un pin distinto de la micro:bit:
| LED | Pin |
|---|---|
| Rojo | P0 |
| Amarillo | P1 |
| Verde | P2 |
¿Por qué esto es un circuito en paralelo y no en serie? Porque cada LED tiene su propio camino independiente entre el pin de la micro:bit y tierra (GND). Esto es clave por dos razones que ya vimos en clase:
- Independencia eléctrica: la micro:bit puede encender el LED rojo sin que eso afecte al amarillo o al verde. Si estuvieran en serie, no podríamos controlar cada color por separado, ¡y un semáforo donde todos los colores se encienden o apagan juntos no sirve de nada!
- Mismo voltaje, distinta corriente: en paralelo, cada rama recibe el mismo voltaje (3.3V desde el pin activo), pero la corriente se reparte según la resistencia de cada rama. Por eso cada LED necesita su propia resistencia limitadora, calculada de forma independiente.
Pregunta para pensar: si conectáramos los tres LEDs en serie en un solo pin, ¿podríamos programar la secuencia rojo → amarillo → verde como lo hace un semáforo real? ¿Por qué sí o por qué no?
2. El problema real: ¿cómo lo descomponemos?
Aquí es donde entra el pensamiento computacional. Nuestro problema grande es: "quiero que la micro:bit controle un semáforo que además avise cuándo los peatones pueden cruzar." Ese problema es demasiado grande para programarlo de una sola vez. Por eso aplicamos el primer pilar del pensamiento computacional:
Descomposición
Dividimos el problema grande en partes pequeñas y manejables:
- Parte 1: encender y apagar LEDs en combinaciones específicas (escritura digital).
- Parte 2: mantener cada combinación durante un tiempo determinado (temporización).
- Parte 3: repetir la secuencia indefinidamente (ciclo infinito).
- Parte 4: mostrar una animación en la matriz de LEDs cuando el semáforo está en rojo, simulando a un peatón cruzando.
Cada una de estas partes, por separado, es sencilla. Juntas, resuelven el problema completo.
Reconocimiento de patrones
Si miramos un semáforo real, notamos un patrón que se repite: rojo → rojo+amarillo → verde → amarillo → rojo, una y otra vez. Una vez que identificamos este patrón, sabemos que no necesitamos escribir código distinto para cada "vuelta" del semáforo: basta con meter la secuencia dentro de un bucle que se repita para siempre.
Abstracción
No necesitamos saber cómo funciona internamente un semáforo de verdad (sus relés, su controlador industrial, su temporizador electromecánico) para construir el nuestro. Solo necesitamos abstraer lo esencial: tres estados de luces que cambian en el tiempo. Esa es la esencia de la abstracción: quedarnos con lo que importa para resolver el problema, e ignorar los detalles que no son relevantes para nuestro nivel.
Algoritmo
Finalmente, convertimos todo esto en una secuencia ordenada y precisa de instrucciones, es decir, un algoritmo. Y ese algoritmo es, literalmente, nuestro código.
3. Del algoritmo al código
Con el problema ya descompuesto, escribir el programa se vuelve mucho más simple. Así se ve nuestro algoritmo traducido a MakeCode:
function encenderSemaforo(rojo: number, amarillo: number, verde: number) {
pins.digitalWritePin(DigitalPin.P0, rojo)
pins.digitalWritePin(DigitalPin.P1, amarillo)
pins.digitalWritePin(DigitalPin.P2, verde)
}
basic.forever(function () {
encenderSemaforo(1, 0, 0)
basic.pause(3000) // Rojo
encenderSemaforo(1, 1, 0)
basic.pause(1000) // Rojo + Amarillo
encenderSemaforo(0, 0, 1) // Verde
basic.pause(5000)
encenderSemaforo(0, 1, 0)
basic.pause(1000) // Amarillo
// Momento del paso peatonal
encenderSemaforo(1, 0, 0) // Rojo: los peatones pueden cruzar
for (let i = 0; i < 4; i++) {
basic.showLeds(`
. # . . .
. # # # .
# . # . #
. . # . .
. # . # .
`)
basic.pause(300)
basic.showLeds(`
. # . . .
. # # # .
. # # . #
. . # . .
. # . # .
`)
basic.pause(300)
}
})Noten algo importante: no usamos ningún pulsador. La decisión de "cuándo pasan los peatones" no depende de una entrada externa, sino de la propia lógica del programa: cada vez que el semáforo llega a rojo, automáticamente se dispara la animación del peatón caminando en la matriz de LEDs, usando el bloque basic.showLeds() con un barrido de dos imágenes (como si fueran dos "fotogramas" de una animación).
¿Por qué esto también es pensamiento computacional?
Porque tomamos una decisión de diseño basada en evaluación lógica: en lugar de depender de una entrada física (que complicaría el circuito y requeriría otro componente), reutilizamos un estado que ya existe en nuestro sistema (el semáforo en rojo) como disparador de otro evento (la animación del peatón). Esto se llama reutilización de estados, y es una estrategia muy común en programación: en vez de crear una variable nueva para "¿puede pasar el peatón?", usamos la variable que ya tenemos (el estado del semáforo) para inferir la respuesta.
4. La función: otra forma de abstracción
Fíjense en la función encenderSemaforo(). En lugar de escribir tres líneas de digitalWritePin cada vez que queremos cambiar de color (lo cual tendríamos que repetir cinco veces en todo el programa), empaquetamos esa lógica en una sola función reutilizable. Esto no es un capricho de orden: es un pilar fundamental de la programación llamado abstracción funcional.
Beneficios que logramos:
- Si mañana cambiamos un LED de pin, solo corregimos un lugar en el código.
- El programa principal (
basic.forever) se lee casi como una receta en español: "rojo, rojo+amarillo, verde, amarillo, paso peatonal." Eso se llama legibilidad, y es tan importante como que el programa funcione.
5. Actividad para reforzar lo aprendido
Antes de cerrar, les dejo un reto para aplicar lo visto:
- Modifica los tiempos: cambia la duración de cada fase y observa cómo afecta el comportamiento general. ¿Qué pasa si el verde dura menos que el tiempo que necesita un peatón para cruzar?
- Identifica el circuito: dibuja el diagrama del circuito con los tres LEDs y señala dónde está cada "rama" del paralelo.
- Piensa en otra abstracción: ¿se te ocurre otra función que podrías crear para simplificar aún más el código? (Pista: ¿qué tal una función para la animación del peatón?)
Conclusión
Este proyecto es un ejemplo perfecto de cómo la electrónica y la programación no son dos mundos separados, sino dos caras de la misma moneda. Entender que nuestros LEDs están en paralelo nos ayuda a diseñar el circuito correctamente, y aplicar descomposición, patrones, abstracción y algoritmos nos permite convertir ese circuito en un sistema inteligente que simula, con unas pocas líneas de código, el comportamiento de un semáforo real.
La próxima vez que crucen una calle y vean el muñequito verde parpadeando, ¡ya sabrán que detrás de esa simple animación hay circuitos en paralelo, algoritmos y mucho pensamiento computacional!
¿Tienes dudas sobre el proyecto o quieres compartir tu propia versión? Déjamelo en los comentarios. 🚦
No hay comentarios:
Publicar un comentario