Saltar al contenido
Cursos Ladetec

2021En uso

Tablero digital sobre video NTSC para un Moskvich

Un STM32 que genera la señal de video de televisión por software, sin chip de video, y la inyecta en el monitor de la cámara de retroceso del carro. En la pantalla que el resto del tiempo está apagada salen temperatura del motor, voltaje de la batería y revoluciones. Todo el hardware de video son dos resistencias y un conector RCA.

Tablero de un Moskvich con un monitor pequeño montado sobre la consola, encendido con fondo azul oscuro: arriba a la izquierda un icono de batería con 12.2V, al centro una barra de segmentos escalonada con las marcas 80, 84 y 88, y a la derecha el número 71 en grande junto a un icono de termómetro sobre ondas
El instrumento funcionando en el carro, sobre el monitor de la cámara de retroceso: 12,2 V, 71 °C y la barra escalonada marcando los tres umbrales del control. La imagen entera la dibuja el microcontrolador línea por línea.

El Moskvich ya tenía instalada una pantalla: el monitor de la cámara de retroceso, que se enciende cuando se mete el cambio de marcha atrás y pasa el resto del viaje negro. Comprar otra pantalla para poner un instrumento al lado era pagar dos veces por lo mismo. La pregunta era si el microcontrolador podía hablarle a ese monitor en el idioma que el monitor ya entiende, que es video compuesto de televisión analógica.

Puede, pero no porque tenga hardware para eso. La señal NTSC se genera por software, con los periféricos que trae el chip puestos a otra cosa: un canal de PWM del TIMER2, desbordando cada 63,5 microsegundos, produce los pulsos de sincronismo que le dicen al monitor dónde empieza cada línea; el contenido de cada línea sale por el SPI1 empujado por DMA, de modo que los bits del framebuffer se convierten en niveles de luminancia sin que el núcleo tenga que intervenir. Las dos señales se suman con una red resistiva contra los 75 ohm de la entrada del monitor. Eso es todo el hardware de video: dos resistencias y un RCA. La base es la librería TTVout de Tamakichi, el port a STM32 de la TVout clásica de Arduino.

Sobre una mesa de taller, una placa Blue Pill en protoboard conectada por cables a un monitor pequeño que muestra un rectángulo con sus dos diagonales y el texto 448x216 en el centro, con un programador ST-Link azul enchufado a una laptop
La prueba de banco del video: patrón de encuadre a 448×216 generado por el STM32 y entrando al monitor por un RCA. Entre la placa y el monitor no hay más que unas resistencias.

La pantalla trabaja a 224 por 108 píxeles en blanco y negro. Es poquísimo, y obliga a decidir qué merece estar ahí: el número grande de la temperatura del refrigerante con su barra graduada en los tres umbrales del control, el voltaje de la batería con su icono, las revoluciones del motor, y la velocidad y la hora que vienen del GPS. Los dígitos grandes necesitaron una fuente propia de 16 por 24, porque la del sistema a esa resolución no se lee de un vistazo desde el asiento.

Las revoluciones se cuentan por flancos en la señal de la bobina, y ahí el problema no es contar sino no contar de más: la ignición de un carro es una de las fuentes de ruido más sucias que hay a bordo. El contador solo acepta un cambio de estado cuando lo ve tres lecturas seguidas, y convierte flancos por milisegundo en revoluciones por minuto con una constante que depende de los cilindros y de la bobina.

El resto —la máquina de estados de la temperatura, el filtro de media móvil, el menú de un solo pulsador, los parámetros en EEPROM emulada sobre flash— está tal cual heredado del controlador del Lada que hicimos con Casanova. Esa es la ventaja de haber separado el controlador de la pantalla en aquel proyecto: cambiar de una TFT a color por SPI a un monitor de televisión en blanco y negro tocó la capa de presentación y nada más. Lo que sí hubo que mover fue el voltímetro, de PA1 a PA2, porque PA1 es ahora el pin del sincronismo y no admite negociación.

Este Moskvich no tiene electroventilador, así que la parte del proyecto original que manejaba los relés de dos velocidades quedó dentro del código sin nada que accionar. No es elegante, pero es lo que pasa de verdad cuando se reutiliza un proyecto: una parte del código sobra y uno no la quita por no romper lo que funciona.

Hay que decir en qué estado quedó. El equipo está instalado y en uso, pero el código que subí al repositorio es el de la carpeta de trabajo, y ese no compila tal como está: una alarma antirrobo por sensor piezoeléctrico, que empecé y no terminé, usa dos constantes que nunca llegué a definir. El GPS tampoco entrega datos, porque la llamada que abre el puerto serie no está en el arranque: el código que lo decodifica está completo, falta una línea. Lo que está corriendo en el carro es el binario de diciembre de 2021, anterior a todo eso, y lo dejé preservado en el repositorio junto a los dos ficheros exactos con que se compiló.

Lo que no hace

  • Video monocromo de 224×108 píxeles. No hay color, y el texto fino no se lee: cabe un número grande y poco más.
  • El firmware no conmuta entre la cámara y el instrumento. Qué mira el monitor se resuelve fuera del código.
  • El GPS está cableado y decodificado, pero en esta versión del código no arranca: velocidad y hora se quedan en cero.
  • No registra ni comunica nada. Lo que no se mire en la pantalla se pierde.

El código publicado no compila tal cual y no es exactamente el que está corriendo en el carro: tiene encima una alarma antirrobo a medio hacer que usa dos constantes sin definir. El README lo dice fichero por fichero y el repositorio guarda aparte la versión que de verdad se compiló y el binario instalado.

Código →