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.
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.
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 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
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:
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.
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
U-Center v20.01 User Guide
 |
| 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í:
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.
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.
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.
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)
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.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.
 |
| 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.
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:
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
No hay comentarios:
Publicar un comentario