Controladora Semaforos

🚦 Controladora de Semáforos Móviles de 3 Estados (V9.1)

🧭 Las decisiones vigentes viven en DECISIONES.md — una fila por decision, con su fecha, su motivo y que deroga. (Aqui se publicaba cuantas hay; se quito el 11/09 porque decia 18 y 9 cuando ya eran mas: se cuentan alli.) Si un parrafo de cualquier documento contradice una fila de ahi, gana la fila: el parrafo esta caducado. Se lee ANTES de encargar un cambio de alcance.

🔴 Lo que este README no puede decirte, y es lo primero

▶️ Donde esta parado el trabajo y por donde se retoma lo dice ESTADO.md, que se reescribe en cada cierre; aqui no se repite. Lo que paso, en HISTORIA.md y en git log.

La instalación certificada es e303485 (V8.4, 31/07/2026). Lo de debajo llegó a una mesa el 3-4/09 y la noche del 04/09 —banco con dos tarjetas; la última cinta, 05/09 22:19, sobre 42a52cd— y 🔴 el 10/09 llegó por primera vez a una calle: un Maestro (SERIE:179DB0) corrió en El Sisga con firmware V9 SIN_BANCO —el paquete del 08/09 (7ff7d12); después se probó el del 10/09 (b354fe9)—. Su cinta y su diario están en evidencia/ (308 tramas, 308 checksums que casan). Lo que se reportó allí, lo que dice la cinta y la rama que salió de ahí, validada por el diff, están en roadmap.md §3.16 (N-162). 🔴 Con 7ff7d12, el Maestro 179DB0 se declara en hora con el reloj parado: no se usa el Modo Degradado allí. Desde el 29/09 el funcional prueba en banco las candidatas (a505fa2, 6bd1e4f, d3606be; cintas en evidencia/300920261130/, 011020260934/, 021020260914/), pero ninguna ha pasado banco completo.

La razon lineas de instrumento / lineas de producto la mide el pre-commit en cada commit (.githooks/trinquete.sh, contra el techo RAZON_TECHO de .topes): si sube por encima del techo, el commit se para. El techo solo baja, cuando un acta de campo archiva un tema (CLAUDE.md §4). Cuenta el indice, sin historico/, e incluye la app y el ESP32, asi que no se compara con las razones de la serie anterior (esa serie, en HISTORIA.md).

Tres auditorías externas independientes dijeron lo mismo, y la tercera lo dijo de la respuesta a la segunda. La regla que salió de ahí vive en CLAUDE.md §0 y §8:

Un 20/20 sobre decenas de miles de líneas de instrumento que nunca han tocado una tarjeta no es un entregable: es una coartada.

La tabla de abajo es verdad. Lee lo que mide antes de lo que puntúa.

📐 LA SPEC — empieza por aquí, y son nueve ficheros (SPEC_0 a SPEC_8)

Escritas el 12–13/09 desde el fuente, verificando cada afirmación contra el código; manda la SPEC y DECISIONES.md es su índice. SPEC_0 es la vista del sistema y SPEC_7 el modo sin reloj. Sustituyen a ~17.000 líneas de manuales que describían un sistema que ha cambiado cuatro veces. Nacieron por debajo de 300 líneas a propósito (hoy SPEC_1 y SPEC_2 lo pasan): un fichero que no se puede leer entero no lo lee nadie entero, y entonces cada lector deriva su propia versión.

⚠️ La spec dice qué HACE el equipo hoy, no qué debería hacer. Lo que no cumple una decisión vigente vive en el apartado «HUECOS MEDIDOS» de cada una, con la medida pegada. Y los manuales viejos siguen en el árbol a propósito: se intentó jubilarlos y se paró con medida — hay contenido que ninguna spec cubre todavía (la receta de la APK, los ensayos de cámara con instrumento, la trama canónica con checksums de la que cuelga un pack). Está contado en roadmap.md 1.35(a).

🔧 Qué se probó en banco, y qué no

El 3 y 4 de Septiembre esto vio una tarjeta. El funcional ejecutó la guía de 29 pasos sobre 617bd00: 24 pasos completados, 4 bloqueados por el enlace Bluetooth y 1 abortado por un incidente de seguridad. Informe en evidencia/Informe_Pruebas_Banco_Semaforos_V9.0.pdf.

Funcionó en cobre: carga por SWD al primer intento, radio entre puntas con caída a ámbar en ~20 s y vuelta sola en ~3 s, talanquera, cámara de demanda y masa común a 0 V.

✅ La regresión N-42 —el Modo Automático no movía las luces— está CERRADA EN COBRE. La cerró la sesión de banco de la noche del 04/09, con el responsable delante: «ahí cambia ese amarillo y este a verde. Ahora está funcionando». El arreglo es ceb8cc5 —se retiró el asistente entero: una sola puerta, el modo arranca corriendo—. (Este README publicó «regresión abierta» hasta el 07/09; el banco la había cerrado tres días antes.)

🔴 Y aparecieron tres defectos que ninguna cifra de la tabla de abajo podía ver, porque ninguno es una propiedad del código: la tarjeta Maestro tiene un corto de 3,3 V a masa (N-116), las entradas de campo no tienen ninguna protección mientras las salidas sí (N-120), y el ESP32 no se anunciaba por Bluetooth (N-117). Los tres pasaron el 20/20 sin despeinarlo.

(El cuarto de aquella lista, N-118 —«el mando A/B no responde, 0,6 V en reposo»—, quedó REFUTADO el 05/09: el propio banco había medido las dos ramas del experimento en la misma tabla. Mismo cobre, distinto pinMode, distinta tensión. Ver 05_Funcional/historico/DECISIONES_hist.md, cerradas.)

Verificación actual — cifras copiadas del acta evidencia/2026-10-16_compuerta.txt, que genera python 01_Firmware/compuerta.py en una sola corrida. No se escriben a mano — y desde N-62 eso ya no es una promesa: el pack documentos_01_cifras_del_acta compara esta tabla contra la última acta en cada corrida del banco. Cuando se escribió por primera vez, falló: esta tabla publicaba 32 rutas y 86,4 % de flash cuando el acta que ella misma citaba medía 38 rutas y 92,8 %. Las cifras eran del 05/08 y llevaban la palabra «copiadas» encima.

🛑 Aquí había una fila más, arnés de pantalla, y NO se actualiza: se RETIRA. Compilaba los cuatro lcd.cpp/menu.cpp reales contra 131 .c de U8g2, y se fue con el LCD el 13/09 (D-32 (1), 17d3a1f). La compuerta baja de 20 filas a 19 y el banco pierde sus 287 comprobaciones (145 Maestro + 142 Esclavo): es una bajada A PROPÓSITO, no una regresión. Se dice aquí abajo y no en la tabla porque en la tabla sólo caben filas con una medida detrás — una fila sin medida se lee como medida.

18 PASS · 1 FALLA · 0 ABORTADO, de 19 comprobaciones — la compuerta sale con código 1.

🔴 El 1 es el hallazgo, no una regresión. Lo acusa decisiones_01_anclas: D-22 y D-94..D-97 están vigentes en DECISIONES.md sin una línea que las construya. D-22 es poner Y1 y espera una tarjeta delante: si Y1 no oscila, el _Error_Handler es noreturn y la tarjeta queda a oscuras; D-94..D-97 son SPEC sin construir que también piden placa.

🛑 Ninguna se apaga poniéndole un ancla: se construye o se deja rojo. El 07/09 se intentó cerrar las de entonces poniéndoles el ancla en un comentario y la compuerta se puso en 20/20 sin que se construyera nada (roadmap.md §3.10); las anclas se revirtieron y el rojo volvió, que es donde tiene que estar.

🟢 Y cuando vuelva a 0, ese verde será más peligroso que el rojo, no menos. Mientras la compuerta sale con 1 nadie la confunde con un permiso; un 0 sí se confunde. Lo que dice es exactamente esto: los modelos y los arneses de PC no encuentran nada. No dice que el firmware funcione en la tarjeta. El contraejemplo está fechado: los tres defectos que pararon el banco del 3-4/09 pasaron estas 19 comprobaciones sin despeinarlas. Verde no es entregable.

Por qué la compuerta está hecha así — cuatro lecciones, en una línea cada una

El detalle de las cuatro, con su medida, está en roadmap.md.

Un acta no es una frase. evidencia/ guarda fecha, hash de HEAD y versión de toolchain de cada corrida, así que "20/20" deja de ser un número que envejece en un README y pasa a ser algo que el auditor re-corre sobre ese mismo commit. Estado de hoy en ESTADO.md; reglas permanentes en CLAUDE.md.

📦 El banco son 70 packs — y eso NO es una medalla

python 01_Firmware/Simulaciones/banco/correr.py --listar
python 01_Firmware/Simulaciones/banco/correr.py --pack esclavo_03   # un fallo, solo, en 1 s

Por qué se migró — había tanto instrumento como firmware: 8.898 líneas contra 8.895, uno a uno. Y los simuladores no ejecutan el C++, lo reimplementan a mano: son una segunda copia que alguien sincroniza, y eso falló cuatro veces en una semana.

⚠️ Pero correr.py NO es compuerta.py. El banco es una fila de veinte: un x/y de packs no dice nada de las otras diecinueve, y una de ellas puede estar en ABORTADO por el mismo cambio que acabas de comitear. Antes de comitear se corre compuerta.py, completo.

📦 Qué se le manda al funcional, y por qué son dos paquetes

Un paquete es una autorización implícita: quien lo recibe asume que puede instalarlo. Con el banco sin pasar, eso obliga a separar lo que pide una medida de lo que entrega una versión.

El LEEME_PRIMERO no abre con la cifra en verde — abre diciendo qué corre en campo, que esto no es eso, y qué sigue roto. El método está en orquestador:entregar y en .claude/particularidades/entregar.md.

Certificado en campo: 31 de Julio de 2026 (V8.4, dos radios en enlace directo) Última actualización del repositorio: 11 de Septiembre de 2026 (la cifra vigente y su hash de HEAD están en el acta que cita la tabla de arriba, y no se repiten aquí: este pie llevaba 14 PASS sobre HEAD 2cde016 cuando el acta ya medía otra cosa, y un recuento viejo no se lee como viejo, se lee como medida.) Repositorio Oficial: github.com/dieleoz/Controladora_Semaforos-2 — remoto origin. Normativa Aplicable: Resolución 2024 del Ministerio de Transporte de Colombia (Secuencia de Luces y Tiempos de Seguridad Vial)

🧭 La arquitectura vigente, decidida en obra el 28/08 y cerrada el 31/08

El documento con el detalle medido —fichero:linea en cada afirmación, las decisiones abiertas con dueño y las medidas de multímetro— es 05_Funcional/17_Arquitectura_28-08_y_Decisiones_Abiertas.md, y manda la SPEC (05_Funcional/SPEC_0..8; DECISIONES.md es su índice). Aquí va sólo el reparto, porque un README que describe el aparato anterior manda a cablear el aparato anterior.

El reparto, en una frase

El STM32 sigue siendo el controlador del semáforo. El ESP32 es un módulo de expansión colgado de un puerto serie: aporta reloj y Bluetooth, y NO manda sobre las luces.

                       fuente propia 12 V (NO sale de la tarjeta)
                                    |
   +--------------------+     +-----v--------------------+
   |   STM32F103C8      |     |         ESP32            |
   |   (controlador)    |     |   (modulo de expansion)  |
   |                    |     |                          |
   |  luces    J3-J8    |     |  DS3231  GPIO21 SDA      |
   |  barrera  J15      |     |          GPIO22 SCL      |
   |  camaras  J16 (*)  |     |          (pila propia)   |
   |  LoRa     J12      |     |                          |
   |           USART3   |     |  Bluetooth (sustituye    |
   |                    |     |   al modulo SPP)         |
   |  USART1 remapeado  |     |                          |
   |  PB6 TX == J17 p3 <------ GPIO16 (RX2)              |
   |  PB7 RX == J17 p2 ------> GPIO17 (TX2)              |
   +---------|----------+     +-----------|--------------+
             |                            |
             +-------- masa comun --------+
                       9600 8N1

(*) Aquí ponía camaras J14, J16. ✏️ 11/09: las cámaras van a J16 —dos por poste, p10 y p12 (D-25)—. J14 no lleva cámara: A-2 lo reserva al fin de carrera, pero el firmware lo sigue leyendo como cámara de demanda (CAM_DEMANDA_PIN = PB0) — conflicto abierto, del responsable → D-27 (11/09): J14 LIBRE, sin cablear; el fin de carrera no se instala en este despliegue, así que en J14 no se conecta nada (ARQUITECTURA.map §7.3).

El enlace, pin a pin — y la fuente

9600 8N1. El USART1 ya está remapeado a PB6/PB7 en el firmware de las dos puntas (N-76, bluetooth.cpp, grep -n "SerialBT(PB7, PB6)") — el puerto y el pinout son los mismos que ya tenía el módulo SPP; lo que se enchufa, no.

🔴 El ESP32 lleva fuente propia desde 12 V. NO cuelga de los 3,3 V de J17 p6/p8. Ese riel sale del U5 y es el mismo que alimenta al STM32 que gobierna el semáforo: un ESP32 con radio da picos de corriente del orden de medio amperio, y un reset del controlador provocado por un periférico de diagnóstico es el reparto de riesgo que no se acepta. El accesorio no puede tumbar al que manda.

Lo que se retira, y por qué — tachado, no borrado

Una vía descartada que desaparece en silencio vuelve a proponerse. Por eso van tachadas con su motivo al lado, y no suprimidas.

🔴 Y su consecuencia declarada, que es una propiedad del sistema y no una avería (D-16): SIN TELÉFONO NO HAY FORMA DE OPERAR EL EQUIPO. Ni ámbar, ni volver a automático, ni parar el cruce. Va escrito en el manual del operario: el teléfono es herramienta crítica.

Las cámaras van a J16 p10 y p12 — dos por poste (D-25, 11/09) — y ya se cablean

(Resumen: la tabla que manda es 05_Funcional/17_… §1.7. La columna «red» es el nombre heredado del netlist, no el papel del pin.)

✅ D-25 (11/09, el responsable): las conexiones de la guía de cámaras del Sisga quedan DEFINITIVAS —4 cámaras, dos por poste— y derogan de D-13 solo «una por poste, p12 vacío». 🔴 Lo que el que cablea tiene que saber, medido en el firmware de hoy: las dos entradas hacen LO MISMO (piden paso; botones.cpp, CAM_J16[2]), ninguna protege la pluma (el veto es A-1.bis, sin construir), y una segunda cámara muerta desde la instalación no la detecta nadie (el vigilante salta el pin que nunca dio un flanco): se comprueba cada cámara por separado al instalar. Las frases falsas de la guía del 10/09 se corrigen en su versión nueva (roadmap.md §3.16) → ✏️ 11/09: es 05_Funcional/Camaras_Sisga_4x.html, con la fe de erratas delante y la talanquera en J15 al final. ⚠️ La app (también la APK del 10/09) pone CAM: OK — las dos ven en cuanto detecta CUALQUIERA de las dos cámaras del poste, aunque la otra no haya detectado nunca: por eso cada cámara se comprueba con el multímetro en su borne (0 V en reposo, 3,3 V con algo en la zona), y no con la app.

✅ La medida M3 está CERRADA desde el 03/09 y las cámaras se cablean (D-3). Medido en cobre —multímetro, conector vacío, paso 20 de la Guía—: el pull-down de 10 kΩ que declaraba el netlist es real y está en las cuatro posiciones (R65–R68 con su 100 nF); p10 y p12 dan 0 V en reposo, así que la entrada es activa en ALTO, que es lo que el firmware ya hacía. El paso 21 cableó p10 contra p11 en normalmente abierto y funcionó, sin demandas fantasma.

🛑 No se cablea cámara a J16 hasta cerrar la medida M3 — caducado: este README lo siguió publicando cuatro días después de cerrarse, y el 05/09 se le contestó al responsable con ese párrafo. Se conserva tachado porque una vía descartada que desaparece vuelve a proponerse.

⚠️ El orden sigue siendo asimétrico: primero el firmware cargado, después el destornillador. Un commit no protege de un destornillador — se exige la carga verificada en la tarjeta, no el merge. ✏️ 11/09, con D-25 vale para los DOS pines: con un binario anterior a deeeab4 (la V8.4 incluida) PB14 es botonAceptar() y PB15 es botonCancelar(), así que lo que se cablee en p10 o en p12 puede actuar como un botón en un equipo que está en la calle.

Seis luces gobernadas, no ocho

pines.h declara ocho salidas de luz, pero el semáforo peatonal nunca se conectó a nada:

Es hardware pagado y muerto —tiene opto, MOSFET y bornera propia—. Se anota aquí porque "conserva las 8 luces" es la clase de frase que se copia de documento en documento sin que nadie corra el grep: la barrera de salidas de CLAUDE.md §2 custodia ocho nombres; el equipo mueve seis.

🛑 Lo que esta arquitectura NO autoriza

• Nada de esto ha pasado banco entero, y la compuerta no lo suple. Lo que este apartado llama medido se midió en su mayoría sobre ficheros —el .cpp, el .h, el .kicad_sch y el .kicad_pcb—. Un fichero dice lo que alguien dibujó; una placa dice lo que se fabricó.
• 🟠 Sin pantalla, $STATUS es el único tablero que existe — y hoy trae BAT:-- porque no hay un solo analogRead en src/. Un campo que no se mide se retira o se marca; no se deja con aspecto de medida.
• 🟠 El ESP32 de este proyecto no tiene watchdog en el Repetidor (los dos STM32 sí: 4 s; el ESP32 de expansión también, desde vigilante.cpp), y hay precedente escrito de uno clavado tumbando el enlace. Con la pantalla y el mando retirados, un ESP32 colgado deja el equipo sin ninguna superficie de mando.

El plano de conexiones que se entrega —J17, J16, PB6/PB7, el DS3231 y el SWD— es 05_Funcional/Montaje_Campo_2026-10-05.html, con el cobre medido en 17_... y SPEC_5.

🗂️ Paquete Oficial de Entregables y Manuales (05_Funcional/, en .md y .docx)

ARCHIVADOS el 28/09 en 05_Funcional/historico/: todas las filas salvo la 10 y la 17. No son vigentes; mandan las SPEC_0..8 (CLAUDE.md §15). La columna «Estado» describe cada manual antes de archivarlo.

(La lista se ha desfasado CUATRO veces por lo mismo, y sigue sin instrumento: el 27/08 anunciaba 11 manuales de los 14 que existían; el 28/08, 15 de 16; el 31/08, 16 de 17; y hasta el 11/09, 17 de 19. Contar los ficheros es ls 05_Funcional/[0-9]*.md; que nadie lo haga es lo que hace falta cerrar.)

🛠️ Estructura del Ecosistema de Firmware

• 01_Firmware/Maestro: El controlador. Máquina de estados STM32, barrera de salidas (semaforo.cpp, el único que escribe pines de luz), Modo Degradado, mando de relés (código conservado) y telemetría Bluetooth (USART1 remapeado a PB6/PB7 → J17).
• 01_Firmware/Esclavo: Nodo secundario STM32 con ACK por radio (USART3), fallback de orfandad a 25 s, ámbar local con veto SFTY-21 y telemetría Bluetooth.
• 01_Firmware/ESP32_Expansion: El módulo de expansión —reloj DS3231 y Bluetooth—, con watchdog (vigilante.cpp).
• 01_Firmware/Repetidor: Puente ESP32 back-to-back. ⚠️ Fuera de la configuración vigente y sin watchdog: es el mismo firmware que se quedó clavado tumbando el enlace el 31/07. No es el ESP32 de expansión.
• 01_Firmware/Simulaciones/: simuladores y banco/ con sus packs (cuántos, en el acta).
• 01_Firmware/Validacion_LCD/ · _Ciclo/ · _Respaldo/ · _Automatico/: los arneses que compilan C++ real. Qué compila cada uno y su punto ciego: ARQUITECTURA.map; su crónica, ARQUITECTURA_hist.map.
• 01_Firmware/compuerta.py: la única forma correcta de verificar — 18 PASS · 1 FALLA · 0 ABORTADO, exit code 1. Las cifras están en la tabla de arriba, que se copia del acta; ésta es sólo la puerta. Qué se corre según lo que se toca (la cadencia) y por qué el simulador está congelado: CLAUDE.md §4.
• .githooks/ y .topes: el pre-commit del método (topes de documentos, ancho, relatos, 500 líneas por fichero de código salvo el firmware grabado) y el trinquete instrumentos/producto. Se activa con git config core.hooksPath .githooks.
• .claude/particularidades/: lo propio de este repo para las skills del plugin orquestador@diego (entregar, verificar) y la mecánica larga de CLAUDE.md.
• ESTADO.md es el punto de retomar; HISTORIA.md, la crónica; DECISIONES.md, lo ya contestado.
• Los paquetes no se versionan: salen a entregas/ (ignorada por git), y los retirados a entregas/RETIRADOS/.

🛑 Y para cerrar donde se abrió: nada de este README es un permiso. En campo corre la V8.4; la V9.1 compila y pasa 18 de las 19 filas de la compuerta — la que falla es el censo de decisiones sin construir, y falla con razón (D-22 necesita una tarjeta delante). Lo que hay hoy en el árbol no ha visto una tarjeta. Nada sube a campo sin pasar banco — y el banco no lo sustituye ningún número verde de esta página.