domingo, 8 de marzo de 2020

10) Diseño de Reloj con tubos Nixie Mini. Reloj Retro IN0012


Introducción al Proyecto Reloj IN0012


              Este proyecto se trata de diseñar y construir un Reloj Retro Vintage con tubos Nixie miniatura tipo IN0012 como el de la figura:



Fig.10.1 Reloj Retro Nixie Mini

En este caso la construcción será desde cero (en el ZM1022 se aprovechaba una placa existente con su circuiteria TTL existente) 
Algunos de los componentes para este proyecto los vemos en las siguientes figuras:





Fig.10.2 Componentes principales del Reloj Retro Nixie Mini  IN0012


En la Fig.10.2 se pueden ver de izquierda a derecha, las válvulas o tubos nixie miniatura tipo IN0012 ó IN-12 de fabricación Rusa ya dispuestas en la plaqueta prototipo; luego la fuente de alimentación de 200V para las Nixies similar a la usada en el proyecto ZM1022; el uC de 8 bits de rango medio con su cristal de cuarzo; el regulador de 5V tipo 7805; tres circuitos integrados tipo SN74164 y seis integrados tipo SN74141; los diez zócalos para integrados y por último la fuente de alimentación de 12VCC.









Fig.10.3 Tubos Nixie Mini IN-12 y zócalos dispuestos en la placa prototipo


Características del tubo Nixie Mini IN0012 ó IN-12




Fig.10.4 Características y prueba de los Tubos Nixie Mini IN-12

En el proyecto anterior con tubos nixies ZM1022 hay una detallada explicación de estos tubos display y su funcionamiento. En este caso se trata de tubos similares modelo IN0012 ó IN-12 que es uno de lo mas pequeños que ha fabricado. Sus características y prueba de encendido pueden verse en la Fig. 10.5


Diagrama en bloques del circuito de Display del Reloj IN0012 



Fig.10.5 Diagrama en bloques parcial del Reloj


En el diagrama de la Fig.10.5  pueden verse arriba las seis Nixies IN0012 que corresponderán en pares, a la indicación de Horas, Minutos y Segundos del Reloj, y también podrán mostrar Dia, Mes y Año como ya se sugirió.
Como se ve, cada Nixie recibe en su Ánodo la alimentación de 200VDC a través de una resistencia limitadora de 30 Kohms. Los Cátodos de los tubos son manejados como ya se analizó en el Reloj ZM1022, por integrados decodificadores/drivers tipo SN74141 cuyas características ya fueron vistas.
La variante en este diseño es que utiliza tres registros de desplazamiento o conversores serie/paralelo para almacenar los códigos BCD de los dígitos a mostrar. 
Aqui se muestra un ejemplo de hora 23:47:19 como se indica en color rojo y la secuencia de carga de registros de entrada serial y salidas en paralelo.

Estos registros son tipo SN74164 y sus características son:

                 

Fig.10.6 Registro de Desplazamiento - Conversor Serie/Paralelo SN74164


El SN74164 posee ocho celdas o Flip-Flops que almacenan un bit cada uno en un arreglo serie o cascada, sus salidas independientes Q0-Q7 están disponibles en paralelo . La información o bits que ingresa por sus entradas A y B se va desplazando de izquierda a derecha pulsada por la señal de Clock, así con ocho pulsos de Clock los bits que ingresan en serie son almacenados y se presentan en las ocho salidas Q0-Q7, quedando fijos cuando la señal de Clock queda inactiva luego de los ocho pulsos. 
El integrado también posee una entrada de Clear para poner a Cero (Low o GND) todos los bits almacenados y sus salidas correspondientes.

En el diagrama 10.6 se ven los tres SN74164  dispuestos en cascada, necesarios para almacenar los 24 (6x4) bits necesarios para decodificar los seis dígitos BCD y mostrarlos en el display. 
Las entradas de Datos (bits) son AA y BB y el Clock es CC en cada integrado. Como indica la secuencia de carga de registros de la figura 10.6, los Datos (bits) entran en serie desde la izquierda y son desplazados por los 24 pulsos de Clock hasta quedar almacenados y en la posición correcta correspondiente a los dígitos a mostrar. 
Incluso adecuando los tiempos de la secuencia de carga, se puede lograr el efecto visual de que los números entran por la izquierda y van "caminando" por el display hasta quedar en la posición correcta.
Como se ve, este diseño minimiza el uso de señales (pines) del uC ya que todo el display se maneja con solo tres señales (Datos, Clock y Clear si se requiere) a diferencia del proyecto ZM1022 quutilizaba diez señales (pines).
En la Fig. 10.4 pueden verse ya dispuestos en la placa prototipo, los seis zócalos de los drivers SN74141 alineados en vertical con su correspondiente tubo Nixie, luego en horizontal se disponen los tres registros SN74164 y por ultimo se dispone el zócalo del uC 


Asignación de entradas/salidas (pines) en el uC y su interface con el módulo NEO



Fig.10.7 Diagrama de asignación de pines e interfase con el módulo GPS


En este proyecto nuevamente usaremos un uC de rango medio, de 8 bits, que posee dos puertas de entradas/salidas de 8 bits (RA y RB) que bastarán para cumplir  los requerimientos de este diseño. En la Fig. 10.7 se muestra la asignación de patas (pines) adoptada en el uC y el circuito de interface con la placa de test (breakout board) del módulo NEO-M8N.
El criterio de asignación de puertas I/O aquí adoptado será el siguiente:


       Puerta A (RA0-RA7)
       Pin       Nombre     Función
       RA0     Red            Serán las tres señales 
       RA1     Green        de colores Rojo, Verde y Azul
       RA2     Blue           de los LEDs de Back Light (Luz de fondo de la Nixies)
       RA3     Azul           Led Indicador AZUL de Segundos, parpadeará cada  1 Seg.
       RA4                        No utilizada
       RA5     Reset          Reset o reinicio del Controlador
       RA6     Osc1           Conexiones del cristal de cuarzo de 8 MHz generador 
       RA7     Osc2           de sincronismo ó base de tiempo del Reloj

       Puerta B (RB0-RB7)
       Pin       Nombre     Función
       RB0     Rojo           Led Indicador ROJO de errores              
       RB1     Rxd            Recepción de Datos desde el módulo NEO
       RB2     Txd            Transmisión de Datos hacia el módulo NEO
       RB3     Clear          Clear o puesta a cero de los Registros de Desplazamiento
       RB4     Clock         Clock o pulsos de almacenamiento en los Registros            
       RB5     Datos         Datos o bits seriales a almacenar en los Registros
       RB6     PGC          Señales de Clock y Datos de la Programación del uC
       RB7     PGD          (In Circuit Serial Programing)

Es de notar que el módulo NEO-M8N se alimenta con 3,3 Voltios desde un regulador de tensión que se provee en su plaqueta de test, la que que se ve en la figura 10.7 junto con su antena activa integrada.
Entonces para realizar la interfase entre las señales de datos seriales  Txd y Rxd del módulo (3,3V) y el uC (5V) se usa un integrado CD40106 (sextuple inversor Schmitt Trigger) y tres resistores R1, R2 y R3 de adaptación de niveles. Este integrado además maneja los Leds indicadores de Recepción (Verde) y Transmisión (Amarillo) de Datos del módulo.
El uC también maneja dos Leds directamente
, uno AZUL (RA3) indicador de sincronismo de 1 Seg.,  igual que en el Reloj ZM1022 y otro ROJO (RB0) indicador de errores. 
Los errores pueden producirse en la USART del uC por diferencias de velocidad de transmisión de datos (Frame errors) y pérdida de datos (Overrun errors) y serán indicados por parpadeos en el Led ROJO. Normalmente si todo está ajustado correctamente como se analizó en la entrada 9) no habrá errores ni pérdida de datos.
Igualmente los mensajes ya vistos con la info de Hora y Fecha que usará el Reloj, de encabezamiento $GNRMC se reciben uno por segundo, por lo cual si un mensaje llega errado y es descartado en el proceso de validación ya visto, el siguiente mensaje correcto actualizará la información requerida.


Back Light o Luz de Fondo

Igual que en el Reloj ZM1022, para mejorar la presentación de este Reloj Retro IN0012, se dispondrá de iluminación de fondo de distintos colores que iluminará los tubos Nixie resaltando su imagen. 
Como en el anterior, en este diseño la luz de fondo será provista por LEDs RGB de tres colores y sus mezclas de tonos. Cada tubo Nixie tendrá un LED RGB que ilumina su base y ampolla de vidrio y será controlado por el circuito de la Fig. 10.8 y en la Fig. 10.7 se muestra en el recuadro Rojo su conexión al uC.


Fig.10.8 Circuito de control de luz de fondo (Back Light)


Control del Display de Dígitos

Como ya se adelantó, el Display con los seis dígitos Nixies que se muestra en la Fig.10.5 se maneja con las tres señales vistas llamadas Datos, Clock y Clear, y su funcionamiento se muestra en el diagrama temporal de la Fig.10.5 .
En la Fig.10.7 se muestra en el recuadro Verde su conexión al uC usando los pines RB3, RB4 y RB5 respectivamente.


En la próxima entrada continuamos... 







domingo, 1 de marzo de 2020

9) Sincronizando Relojes con Señal GPS



Sincronismo de Relojes con Señal GPS. Uso de un módulo GNSS(GPS)

           Como se vio, el sincronismo de tiempo del Reloj ZM1022 recien diseñado, está determinado por un cristal de cuarzo común de 4 MHz instalado en la plaqueta del uC (fig. 8.3). Esta base de tiempo ó sincronismo es de las mas básicas y está sujeta a derivas térmicas e imprecisiones de tiempo que harán que el Reloj atrace ó adelante al cabo de unos días de funcionamiento y deberá corregirse usando los botones de seteado de horas y minutos. 

Además el diseño no prevee preservar la hora del Reloj en caso de un corte de energía, por lo cual si esto ocurre, este Reloj partirá siempre de una hora predeterminada en la programación del uC y deberá ajustarse con los botones la hora correcta.

Ambos inconvenientes se solucionarán con el agregado de un módulo receptor GNSS(1) mas conocido como GPS(2) que provea una función de tiempo real que el uC podrá consultar y actualizar su indicación de Hora, Minutos y Segundos, y eventualmente de Día, Mes y Año.
Con el agregado de este módulo y su lectura, quedará así la indicación del Reloj sincronizada con el tiempo UTC(5) que cuenta con la precisión de relojes atómicos de nivel Stratum1 o referencia primaria y no será necesario ajustarlo más .
También puede considerarse el uso de un módulo RTC (Real Time  Clock) como veremos en una próxima entrada.


Sincronismo del Reloj con Señal GPS. Selección de un módulo GNSS (GPS)
 


El módulo receptor y procesador de la señal GNSS (GPS) a utilizar será un Ublox GY-GPSV3-NEO-M8N de octava generación 8G y última tecnología que fue liberado para uso civil en 2018 (hasta 2018 la Ublox 8G  era de uso militar (drones), hoy es de uso militar la Ublox 9G)
El módulo se ve en la Fig. 9.1 , y que tendrá las siguientes características principales (en ingles):

UbloxCompact 8th generation GPS/GNSS receive/processor GPS module‎
 GY-GPSV3-NEO-M8N breakout board general features:
72-channel u-blox M8 engine GPS/QZSS L1 C/A, GLONASS L10F, BeiDou B1 SBAS L1 C/A: WAAS, EGNOS, MSAS Galileo-ready E1B/C (NEO-M8N)
SuperSense Indoor GPS, -167dBm
On-board Ultra low noise 3.3V voltage regulator and RF filter for noise blocking
I2C (SDA,SCL) and Uart (Tx,Rx)
Triple band GPS, Glonass and BeiDou antenna
Triple band Band Pass filter
Triple Band LNA
u-center GPS Evaluation Software
Extensive visualization and evaluation features
Supports AssistNow Online and AssistNow Offline A-GPS services
1 TTL UART port, 1 I2C port
Time pulse LED
Battery for HOT module start and settings storage
Build-in HMC5983 Compass
Dimensions: 33*33mm hole distance 22x22mm
Fully assembled and ready to use

 
Fig.9.1 Módulo GNSS tipo NEO-M8N y su antena receptora activa

Las hojas de datos del módulo pueden verse aquí:
Y sus características mas detalladas de funciones y protocolos pueden verse aquí:

Como puede verse, este módulo cumple con la mayoría de las especificaciones y normas actuales de los sistemas GNSS(1) globales que actualmente son cuatro, el GPS(USA), el GLONASS(URSS), el BeiDou(China) y el Galileo(UE, aún en desarrollo), y de su gran potencia y versatilidad se usará muy poco en la presente aplicación.
Aquí el uC del Reloj se comunicará con el módulo por medio de su interface serial USART(3), utilizando el protocolo universal NMEA(4) por medio del cual interrogará los parámetros de tiempo necesarios para actualizar su indicación de Hora, Minutos y Segundos, y eventualmente de Dia, Mes y Año. También el módulo NEO podrá operar en forma automática (default) enviando un set de mensajes determinado sin que le sean solicitados por el uC.


El protocolo de comunicación jerárquico bidireccional NMEA

El protocolo NMEA es un estandar de comunicaciones jerárquico bidireccional (master-slave) para equipos electrónicos marítimos introducido en USA en el año 1983 y actualizado en los 2000s. Su manual de referencia puede verse aquí:
NMEA Reference Manual

El módulo NEO-M8N a utilizar dispone entre otros de ese protocolo, el cual incluye comandos para interrogar al módulo sobre gran variedad de parámetros, incluidos los de tiempo necesarios para esta aplicación.
Este protocolo utiliza comunicación serial asincrónica (normas RS422/RS232) entre un dispositivo "hablador" (master ó talker) y uno o varios "escuchas" (slave ó listener). 
Los parámetros de comunicación serial normalizados son los siguientes:

Baud rate: 9600 
Number of data bits: 8 (bit 7 is 0) 
Stop bits: 1 (or more) 
Parity: none 
Handshake: none

El formato general de los mensajes ó sentencias del protocolo NMEA  prevee tres clases de sentencias, pudiendo ser estas de interrogación, de respuesta y propietarias. Se utilizan exclusivamente caracteres imprimibles en formato ASCII(6), comenzando el mensaje con el signo $ (pesos) y terminando con CR (carriage return) y LF (line feed) 
El formato general de un mensaje de respuesta será el siguiente:

$TTSSS,D1,D2,...<CR>,<LF>

Donde TT es el identificador del dispositivo que envía el mensaje (dos letras), SSS es identificador de mensaje (tres letras) , y D1, D2, etc son los datos que eventualmente acompañaran la respuesta.

Por otro lado, el formato general de un mensaje de interrogación será el siguiente:
 
$TTLLQ,SSS<CR>,<LF> 

Donde TT es el identificador del dispositivo que interroga (dos letras), LL es el identificador del dispositivo que contesta (dos letras), la letra "Q" indica que es una interrogación (Query), y SSS es identificador de sentencia ó parametro solicitado (tres letras)
Los identificadores de dispositivo (Talker Identifiers) ya están definidos en el protocolo NMEA y pueden consultarse en su normativa (enlace de arriba)
Los identificadores de sentencia y sus formatos también ya están definidos en el protocolo y son varios los mensajes que se pueden utilizar para obtener los datos de tiempo requeridos en este diseño.

El código universal ASCII

El código ASCII (American Standard Code for Information Interchange) es un código que utiliza números/bytes de 7 u 8 bits (dígitos binarios) para representar caracteres del alfabeto latino y otros símbolos.  Su representación en 7 u 8 bits se muestra a continuación:


Fig.9.2 Código ASCII de 7 bits

Fig.9.3 Código ASCII extendido de 8 bits

Como sabemos con 8 bits (dígitos binarios) se pueden obtener 256 combinaciones o números posibles y las tablas muestran los caracteres o símbolos representados por cada combinación. Los números binarios o combinaciones binarias de 8 bits se representan por simplicidad en numeración Hexadecimal

Test y pruebas del módulo GNSS NEO-M8N


Para probar el modulo receptor NEO-M8N, conocer sus características principales y elegir el mensaje a utilizar para obtener Hora y Fecha, se utilizará la aplicación provista por el fabricante, la U-Center v20.01 GNSS Evaluation Software for Windows cuya guía de usuario puede verse aqui:
U-Center v20.01 User Guide
y que se muestra a continuación:
 
Fig. 9.4 Prueba del módulo NEO-M8N con la aplicación U-Center

En la figura 9.4 se muestran las primeras pruebas con el módulo y la aplicación brinda toda la información disponible en tiempo real que provee el módulo NEO-M8N. Le daremos un rápido vistazo a sus pantallas.
En la linea de abajo se lee que el módulo está conectado al Computador por la interface serial COM6 a 9600 baudios y que utiliza el protocolo NMEA.
De izquierda a derecha en la pantalla de la aplicación aparecen distintas ventanas con información variada.
La primera ventana muestra los satélites GNSS recibidos, su rótulo y nivel de señal, los 6 de letra G son GPS (USA) y los 4 de letra R son GLONASS (Rusia), los Verdes están OK recibidos normalmente, los Azules están en proceso de adquisición, y en los Rojos se ha perdido la señal.
Luego está la ventana de Satellite Position que muestra la constelación visible y su posición relativa, luego la ventana de Signal History que indica el historial de señal, sus rotulos y las banderas de nacionalidad de los distintos satélites visibles.
Luego aparecen las ventanas de Data View, Altitude, Compass y Watch (Reloj) que se muestran con mas detalle aquí:


Fig.9.5 Ventanas de Data, Altitude, Compass y Watch (Reloj)

Por último aparece la ventana de Consola que muestra los mensajes en formato NMEA que se reciben del módulo y que proveen toda la información para actualizar todas las ventanas.



El mensaje $GNRMC con indicación de Hora y Fecha, su Adquisición y Procesamiento

Luego de este vistazo a las pantallas de la aplicación U-center de test y control, veremos cual mensaje de la gran variedad que envía el módulo será el requerido para que el uC rescate la info de Hora y Fecha necesaria para mostrar en el Reloj.


Fig 9.6 Pantalla mostrando la Consola de Mensajes en Formato Packet

Fig. 9.7  Mensaje $GNRMC que codifica Hora y Fecha en ASCII y Hexadecimal

Como se ve, los caracteres o símbolos se transmiten según los parámetros de comunicación serial normalizados arriba con dato/byte/caracter codificados en 8 bits, y la ventana de consola los muestra tanto en codificación ASCII como en Hexadecimal. 
Entonces el microcontrolador uC deberá recibir la información de mensajes del módulo por medio de su USART e identificar aquel mensaje que tenga el encabezado $GNRMC, (24-47-4E-52-4D-43-2C en Hexa)  y luego adquirir  la info de Hora, Minutos y Segundos y almacenarlos en los registros de memoria HD, HU, MD, MU, SD y SU correspondientes según ya se vio en el diseño reciente del Reloj ZM1022. 
También se efectuará la adquisición de la info de Año, Mes y Día disponible en el mensaje y se almacenarán en registros de memoria llamados DD, DU, ED, EU, AD, y AU, serán 6 registros para los 6 dígitos necesarios si se requiere que el Reloj muestre Fecha además de Hora.

La interface serial USART y su ISR (Interrupt Service Rutine) 

El microcontrolador uC a utilizar deberá disponer del módulo para comunicación serial bidireccional asincrónica USART (Universal Synchronous Asynchronous Receiver Transmitter module). El capitulo 12 del manual de referencia explica su funcionamiento y configuración:
 Flash-Based, 8-Bit CMOS Microcontrollers Reference


El módulo USART deberá programase con los parámetros de comunicación ya determinados arriba, que son :


Baud rate: 9600 
Number of data bits: 8 
Stop bits: 1


Fig.9.8 Transmisión del caracter ASCII  "N" en Comunicación Serial Asincrónica


En la figura 9.8 vemos el ejemplo del envío del carácter o letra "N" en código ASCII tal como será transmitido desde el módulo GPS al uC y se muestra en los mensajes de consola (mensaje $GNRMC). 

La interface USART del uC será programada para que genere una Interrupción y dispare la ISR (Interrupt Service Rutine) o Rutina de Servicio de Interrupción. 
La ISR es una rutina/proceso/programa cuya ejecución es solicitada por un evento de hardware.  Si la ISR esta habilitada por la configuración de inicialización del uC, esta será llamada a ejecutarse cuando el evento de hardware determinado ocurra, por lo cual el proceso/programa/código principal (PPal) que el uC este corriendo en ese momento será "interrumpido" (de ahí su nombre) y pasará a ejecutarse la ISR. Cuando la ISR finaliza su proceso, se produce una RFI (Return From Interrupt) o retorno desde la ISR al programa PPal y este continua ejecutándose normalmente desde donde fue interrumpido.

Entonces el módulo USART del uC llamará a la ISR cada vez que un carácter/byte/dato se recibe en la comunicación serial y está disponible libre de errores (luego veremos que errores pueden ocurrir) en el correspondiente registro interno de recepción de datos de la USART. 
Dado que la comunicación será con velocidad de datos o Baud Rate de 9600 baudios, cada bit como muestra la Fig. 9.8  durará 104,16 uS y el datagrama completo de 10 bits (1 St, 8 bits, 1 Sp) durará 1,04 mS. 
Entonces suponiendo que no haya pausa entre los caracteres enviados por el módulo GPS, podemos estimar que la ISR será disparada cada 1,04 mS aproximadamente y unas 60 o 70 veces por segundo de acuerdo a la longitud del mensaje recibido.
Además, la ISR será ejecutada para todo carácter de mensaje que se deba chequear o adquirir para luego almacenar en los registros de memoria
En este caso como ya se definió, la ISR deberá entonces identificar el mensaje que tenga el encabezado $GNRMC, (24-47-4E-52-4D-43-2C en Hexa)  y luego leer los dígitos de Hora, Minutos y Segundos que llegan codificados en ASCII y almacenarlos en los registros de memoria HD, HU, MD, MU, SD y SU, luego ignorará los datos no requeridos del mensaje contando las "comas" separadoras de parámetros no requeridos, y luego leerá los digitos de Año, Mes y Dia que llegan codificados en ASCII y los almacenará en los registros DD, DU, ED, EU, AD y AU,  usar la Fig. 9.7 como referencia para el contenido del mensaje..
(para Mes se usa la letra E porque la M ya esta usada para Minutos, entonces EU será el registro para las Unidades de Mes y ED será el registro de las Decenas de Mes) 
Entonces para el procesamiento especifico de este mensaje con encabezamiento $GNRMC, la ISR responderá al siguiente diagrama de flujo (se usa RSI que es ISR en español)





Fig.9.9 Diagrama de flujo de la Rutina de Servicio ISR para el proceso del mensaje $GNRMC

Como se ve en el diagrama simplificado de la Fig. 9.9 , la ISR (ó RSI) sigue un modelo de programación de "maquina de estados" bastante sencillo que ingresa por el óvalo Verde, su variable de estado en el diagrama es É y el dato/caracter recibido por la USART estará  disponible en Á cuando esta provoca la interrupción e invoca a la rutina ISR. Todas estas variables asi como los registros de memoria de dígitos ya vistos, son bytes de 8 bits y su valor se expresa en Hexadecimal en el diagrama.
El diagrama muestra tres columnas de proceso y este proceso es muy sencillo. 
En la primera se espera la llegada de la tira de caracteres o String de encabezamiento de mensaje $GNRMC, partiendo del estado de reposo É=0. 
La variable de estado Ë sólo evolucionará´dentro de la secuencia exitosa 0,1,2,3,4,5,6 de la "maquina de estados"  y quedará en É=7 si solo si se recibe con 7 ejecuciones sucesivas de la ISR el encabezamiento de mensaje correcto $GNRMC, (Salidas por Si de los IF o tomas de decisión de la 1ra. columna). 
Cualquier desviación en ese encabezamiento (Salida por No de los IF o tomas de decisión de la columna). corresponderá a otro tipo de mensaje y se descartará su procesamiento volviendo al estado de reposo É=0. La salida de la ISR una vez que se actualizó a su Éstado correcto ocurre por el óvalo Naranja
La segunda columna del diagrama corresponde a la adquisición de los datos de Hora, Minutos y Segundos partiendo del estado É=7, y se almacenan en los correspondientes registros de memoria. Como se ve la secuencia de estados exitosa de adquisición de datos sera 7,8,9,A,B,C.
En el estado É=C se carga el contador de ","(comas) Í=8 ya que 8 son las comas separadoras de parámetros dentro del mensaje hasta llegar a los datos a adquirir de Día, Mes y Año. 
Mientras el contador Í se decrementa con sucesivos llamados y ejecuciones de la ISR, el Éstado de esta permanece invariable en É=C. Una vez que el contador de comas Í llega a cero, recién se evoluciona al nuevo estado É=F (final de la columna central).
Por último, la tercera columna del diagrama corresponde a la adquisición de los datos de Dia, Mes y Año que como dijimos también están disponibles en el mensaje. 
Partiendo del estado É=F,  se almacenan estos datos en los correspondientes registros de memoria. Como se ve la secuencia de estados exitosa de adquisición de estos datos ahora será F,10,11,12,13 y 14. El último estado 14 es implícito y se supone que se alcanza al final de la columna actualizando el último valor, finalizando la secuencia de estados exitosa y volviendo al estado de reposo É=0 a la espera del siguiente mensaje.
Como se definió, el ingreso en la RSI es único y corresponde al óvalo Verde en el diagrama, pero la salida que producirá el retorno desde la ISR al programa PPal. podrá ser de dos tipos, con "eco" de dato (óvalo bordó) ó  sin "eco" de dato (óvalo naranja).  El "eco" de dato significa que el dato/caracter/byte recibido por la USART y procesado/validado por la ISR , es retransmitido (echoed) por la salida de TX del uC, que en el diagrama se incluye sólo para los datos útiles que son la Hora y Fecha requeridas. Con esta opción es posible chequear con un simple LED en esta salida ó con una aplicación tipo Hiperterminal en PC, que el proceso de mensajes y la adquisición de datos esta siendo la correcta.

Consideraciones de interacción entre ISR y PPal y Tiempos de Ejecución

Fig. 9.10 Relación entre ISR y Ppal.


La interacción entre la ISR y el proceso ó programa principal Ppal se resume en la Fig. 9.10

Como se ve, el Ppal es el encargado de leer los dos grupos de datos/dígitos en memoria y mostrarlos en el display (el display podrá ser de Nixies u otro tipo de display).
Como ya se definio en el diseño del Reloj ZM1022, este será un proceso en lazo repetitivo que se ejecutará una vez por segundo de modo de actualizar el display en cada segundo y ver viva la indicación de los Segundos avanzando.
Si el display a utilizar es de 6 dígitos como el mostrado, la técnica adoptada en el PPal para mostrar la Hora , por ejemplo 12:43:50;  y la Fecha, por ejemplo 13/03/19; será la siguiente:
En cada cuenta de 0 a 10 de las unidades de segundos (SU), durante un trio de segundos por ejemplo los segundos 5, 6 y 7, el display mostrará la Fecha o sea el grupo de dígitos DD,DU,ED,EU,AD,AU; y en los 7 segundos restantes mostrará la Hora o sea el grupo de dígitos HD,HU,MD,MU,SD,SU con los segundos avanzando. Esta técnica se utilizará en el diseño siguiente del Reloj IN0012 (este nombre es por el tipo de lámparas Nixie a utilizar)
Como ya se analizó y se muestra en la Fig. 9.9 ;  la ISR será la encargada de detectar el mensaje requerido desde los datos transmitidos por el módulo GPS, adquirir los caracteres y actualizar los grupos de dígitos en memoria. La ISR actuará por Interrupciones, interrumpiendo en su proceso al programa Ppal, pero este no notará absolutamente nada.

Tiempos de Ejecución a considerar en ambos procesos
 

Si consideramos utilizar como hasta ahora, un uC de rango medio, de 8 bits, funcionando con Clock de 4 Mhz como en el proyecto ZM1022, su ciclo de instrucción sera de 1 uS (Clock/4)
Para el PPal, podemos estimar que el uC deberá ejecutar unas 100 intrucciones de su código de maquina para completar las tareas necesarias que indica la Fig 9.10,  por lo cual tardará en ese proceso unos 100 uS, y hasta el segundo siguiente estará ocioso el resto del tiempo o sea unos 999.900 uS ó 99,9 mS. Esto implica que el tiempo de proceso efectivo será sólo del 0,1 /1000 del tiempo total disponible.

Para la ISR que interrumpirá el PPal ya sea que este esté ocupado u ocioso, su proceso no será fijo sino que dependerá como se vio en el diagrama de la Fig 9.9, del Estado É en que se encuentre el proceso "maquina de estados" del mensaje, pero nunca ocupará mas de 10 instrucciones en cualquier rama del proceso, por lo cual su tiempo de ejecución se puede estimar en unos 10 uS en el peor caso, o sea que le restará al PPal un 10% de su tiempo aproximadamente, cosa que no será notada ni afectará el funcionamiento del Reloj.

Procesos con tiempos de ejecución largos con mayor cantidad de instrucciones podrían implicar perdidas de datos en los mensajes o superposiciones de datos en la USART,  pero este no será el caso pues esos tiempos de ejecución son del orden del ancho de un bit transmitido (a 9600 baudios) y el tiempo claramente sobrará y durante la mayoria de este el uC estará ocioso.



Por último, un video explicativo sobre lo aquí comentado:
 




En la próxima entrada continuamos... 



Referencias:

(1) GNSS: Global Navigation Satellite System
(2) GPS: Global Position System (USA)
(3) USART: Universal Synchronous Asynchronous Receiver Transmitter
(4) NMEA: National Marine Electronics Association
(5) UTC: Coordinated Universal Time
(6) ASCII: American Standard Code for Information Interchange