Como en el diseño anterior, en este proyecto se utilizará un uC de rango medio de la linea MicroChip, tipo 16F628, de 8 bits de longitud de registros internos, memoria, y dos puertas de entrada/salida RA(RA0-RA7) y RB(RB0-RB7) que se asignarán según la Fig.10.7
Las referencias y datos para el diseño pueden verse aquí:
Las referencias y datos para el diseño pueden verse aquí:
De acuerdo a lo visto en el punto 9) Sincronizando Relojes con Señal GPS , respecto a las Fig. 9.9 y Fig. 9.10, se aplicarán dichos conceptos en este diseño.
Entonces, en forma similar en el uC se dispondrán 12 registros o lugares de memoria de 8 bits donde se almacenarán los dígitos a mostrar en el display del Reloj
La asignación de los registros para almacenar y mostrar Horas, Minutos y Segundos; y Dia, Mes y Año; será la siguiente:
Entonces, en forma similar en el uC se dispondrán 12 registros o lugares de memoria de 8 bits donde se almacenarán los dígitos a mostrar en el display del Reloj
La asignación de los registros para almacenar y mostrar Horas, Minutos y Segundos; y Dia, Mes y Año; será la siguiente:
| Nombre | Función | Rango utilizado | Rango máximo (8 bits) |
| HD | Decenas de Horas | 0-1 | 0-255 |
| HU | Unidades de Horas | 0-9 | 0-255 |
| MD | Decenas de Minutos | 0-5 | 0-255 |
| MU | Unidades de Minutos | 0-9 | 0-255 |
| SD | Decenas de Segundos | 0-5 | 0-255 |
| SU | Unidades de Segundos | 0-9 | 0-255 |
| AD | Decenas de Año | 0-9 | 0-255 |
| AU | Unidades de Año | 0-9 | 0-255 |
| ED | Decenas de Mes | 0-1 | 0-255 |
| EU | Unidades de Mes | 0-9 | 0-255 |
| DD | Decenas de Dia | 0-3 | 0-255 |
| DU | Unidades de Dia | 0-9 | 0-255 |
Programación del microcontrolador, diagramas de flujo simplificados
Aquí tambíen se aplica lo visto en la Entrada 9) Sincronizando Relojes con Señal GPS
El programa PPal será similar al utilizado en el proyecto anterior del Reloj ZM1022 como se describió en la Entrada 6) y la ISR o Rutina de Servicio responderá al diagrama de flujo y descripción de la Fig. 9.9.
Análisis del módulo USART del uC
En el capítulo 12 de la referencia de arriba se detalla la programación del módulo USART del uC, con sus registros exclusivos y tablas de velocidades.
Los detalles de configuración para este diseño específico se pueden consultar en el código fuente ASM del Reloj.
En el capítulo 12 de la referencia de arriba se detalla la programación del módulo USART del uC, con sus registros exclusivos y tablas de velocidades.
Los detalles de configuración para este diseño específico se pueden consultar en el código fuente ASM del Reloj.
 |
| Fig.12.1 Resumen de Configuración USART en Rx |
 |
| Fig.12.2 Resumen de Configuración USART en Tx |
Recibiendo la Hora UTC, mostrando la Hora Local
Al utilizar un módulo GNSS (GPS) para obtener la información de Hora y Fecha desde los sistemas satelitales, aparece el problema de la corrección a la Hora Local que deberá ser mostrada en el Reloj.
Los sistemas de satélites GNSS ya vistos (GPS, GLONASS, Beidou, Galileo) son globales y transmiten sus señales a todo el mundo, por lo cual envían con alta presición exclusivamente el tiempo UTC (Coordinated Universal Time) ó GMT (Greenwich Mean Time) como se analizó en la Entrada 9) Por lo cual el país o región que reciba y procese dicha señal, deberá realizar las correcciones necesarias a su Hora Local, que dependerá de su posición geográfica y factores estacionales (países que adelantan su hora en invierno, etc.)
Este problema de corrección de tiempo que parece trivial, puede complicarse por ciertas pautas que deben tenerse en cuenta.
Por ejemplo los países americanos que se encuentran al Oeste de Greenwich o Meridiano Cero tienen correcciones de tiempo negativas, p.e. para Argentina la corrección o Offset horario es (-3), esto significa que cuando la Hora UTC es p.e. 09:17 en Argentina es Hora Local 06:17. La solución de este corrimiento o Offset horario en principio parece facil, sólo basta restar 3 a la Hora UTC y queda la Hora Local corregida, pero no siempre es tan sencillo.
Los problemas aparecen cuando la Hora UTC es p.e. 02:36 entonces la Hora Local será 23:36 y la resta debe hacerse en el sistema sexagesimal para obtener el resultado correcto, y además si el Reloj muestra Fecha como es el caso de este diseño, la Fecha UTC ya estará un día adelantada a la Fecha Local y también deberá corregirse mostrando el dia anterior.
Esta corrección al día anterior que debe mantenerse en las tres últimas horas del día corriente en un país con Offset ( -3) como Argentina se complica un poco más el primer día del mes, ya que el día anterior al 1ro de mes depende de cual fue el mes anterior que puede contar con 28, 30 o 31 días, y se deberá mostrar además el mes anterior en ese caso. También además en un reloj que muestra Mes y Año como en este caso, deberá corregirse el Mes mostrado y el año mostrado en las tres últimas horas del 31/12, ya que el tiempo UTC ya estará en año y mes nuevo, mientrás que el país todavía en año y mes viejo. Otra complicación adicional son también los años bisiestos que deberán tenerse en cuenta para una corrección de Hora y Fecha correcta a lo largo de los años.
Es de notar además que los módulos GNSS como el NEO-M8N aquí utilizado, no incluyen corrección por posición geográfica en su programación ni en la información de Hora y Fecha provista en sus mensajes de protocolo que ya fueron analizados.
En diseños sofisticados que utilicen programación de alto nivel (lenguajes C, Basic, VB.NET, etc.) se pueden implementar bases de datos de calendarios o códigos complejos que realicen una corrección correcta de Hora, Dia, Mes y Año en cualquier posición geográfica del mundo y en cualquier año.
Pero en el caso de programación de bajo nivel como es el código ASM de los microcontroladores, que además manejan sumas y restas en numeración binaria básica, una corrección de tiempo que tenga en cuenta todas las variantes aquí señaladas puede complicarse.
Por ejemplo la instrucción de resta binaria (SUB, Capitulo 15 Instruction Set de la referencia de arriba) que se usaría para realizar la resta del Offset horario no daría el resultado esperado en forma directa y habría que corregirlo en algunos casos. Por ejemplo para Hora UTC=17 implica Hora Local=17-3=14 pero la intrucción SUB daría como resultado 0x0E (Exa) y no 14
Para resolver este problema existen algunas alternativas en el código de los uC. Se puede encarar conversiones del sistema binario al sexagesimal, tomas de desición anidadas (Case) que analicen todos los casos de Hora, Dia, Mes y Año, y también está el método de combinación de Algoritmos y Tablas de Conversión que será el aquí utilizado.
Entonces, para resolver el Offset horario en la programación de este Reloj se utilizará la siguiente combinación de algoritmo y tabla
Al utilizar un módulo GNSS (GPS) para obtener la información de Hora y Fecha desde los sistemas satelitales, aparece el problema de la corrección a la Hora Local que deberá ser mostrada en el Reloj.
Los sistemas de satélites GNSS ya vistos (GPS, GLONASS, Beidou, Galileo) son globales y transmiten sus señales a todo el mundo, por lo cual envían con alta presición exclusivamente el tiempo UTC (Coordinated Universal Time) ó GMT (Greenwich Mean Time) como se analizó en la Entrada 9) Por lo cual el país o región que reciba y procese dicha señal, deberá realizar las correcciones necesarias a su Hora Local, que dependerá de su posición geográfica y factores estacionales (países que adelantan su hora en invierno, etc.)
Este problema de corrección de tiempo que parece trivial, puede complicarse por ciertas pautas que deben tenerse en cuenta.
Por ejemplo los países americanos que se encuentran al Oeste de Greenwich o Meridiano Cero tienen correcciones de tiempo negativas, p.e. para Argentina la corrección o Offset horario es (-3), esto significa que cuando la Hora UTC es p.e. 09:17 en Argentina es Hora Local 06:17. La solución de este corrimiento o Offset horario en principio parece facil, sólo basta restar 3 a la Hora UTC y queda la Hora Local corregida, pero no siempre es tan sencillo.
Los problemas aparecen cuando la Hora UTC es p.e. 02:36 entonces la Hora Local será 23:36 y la resta debe hacerse en el sistema sexagesimal para obtener el resultado correcto, y además si el Reloj muestra Fecha como es el caso de este diseño, la Fecha UTC ya estará un día adelantada a la Fecha Local y también deberá corregirse mostrando el dia anterior.
Esta corrección al día anterior que debe mantenerse en las tres últimas horas del día corriente en un país con Offset ( -3) como Argentina se complica un poco más el primer día del mes, ya que el día anterior al 1ro de mes depende de cual fue el mes anterior que puede contar con 28, 30 o 31 días, y se deberá mostrar además el mes anterior en ese caso. También además en un reloj que muestra Mes y Año como en este caso, deberá corregirse el Mes mostrado y el año mostrado en las tres últimas horas del 31/12, ya que el tiempo UTC ya estará en año y mes nuevo, mientrás que el país todavía en año y mes viejo. Otra complicación adicional son también los años bisiestos que deberán tenerse en cuenta para una corrección de Hora y Fecha correcta a lo largo de los años.
Es de notar además que los módulos GNSS como el NEO-M8N aquí utilizado, no incluyen corrección por posición geográfica en su programación ni en la información de Hora y Fecha provista en sus mensajes de protocolo que ya fueron analizados.
En diseños sofisticados que utilicen programación de alto nivel (lenguajes C, Basic, VB.NET, etc.) se pueden implementar bases de datos de calendarios o códigos complejos que realicen una corrección correcta de Hora, Dia, Mes y Año en cualquier posición geográfica del mundo y en cualquier año.
Pero en el caso de programación de bajo nivel como es el código ASM de los microcontroladores, que además manejan sumas y restas en numeración binaria básica, una corrección de tiempo que tenga en cuenta todas las variantes aquí señaladas puede complicarse.
Por ejemplo la instrucción de resta binaria (SUB, Capitulo 15 Instruction Set de la referencia de arriba) que se usaría para realizar la resta del Offset horario no daría el resultado esperado en forma directa y habría que corregirlo en algunos casos. Por ejemplo para Hora UTC=17 implica Hora Local=17-3=14 pero la intrucción SUB daría como resultado 0x0E (Exa) y no 14
Para resolver este problema existen algunas alternativas en el código de los uC. Se puede encarar conversiones del sistema binario al sexagesimal, tomas de desición anidadas (Case) que analicen todos los casos de Hora, Dia, Mes y Año, y también está el método de combinación de Algoritmos y Tablas de Conversión que será el aquí utilizado.
Entonces, para resolver el Offset horario en la programación de este Reloj se utilizará la siguiente combinación de algoritmo y tabla
Constante - Offset + Hora UTC = Índice, Tabla(Índice) = Hora Local
La Constante se adopta en 8 y el algoritmo funciona en principio para Offsets de -3, -4, -5 y -6
El uC resolverá la Ecuación en binario y la Tabla utilizará la combinación de instrucciones CALL/RETLW
El código ASM para lograr la conversión horaria será el siguiente:
El uC resolverá la Ecuación en binario y la Tabla utilizará la combinación de instrucciones CALL/RETLW
El código ASM para lograr la conversión horaria será el siguiente:
| Instruccion ASM (nemónico) | Parámetro | Comentario |
| movfw | OFFSET | Cargar el OFFSET(3) |
| subwf | CONSTANTE (8) | Resolver (CONS. - OFFSET) |
| addwf | HoraUTC | Sumar Hora UTC |
| call TablaHoraria | Índice = CONS. - OFFSET + HUTC | Entrar a la Tabla con el Índice |
| retlw | HoraLocal | Obtener Hora Local |
La Tabla de conversión horaria, que se accede con Call TablaH es la siguiente:
| Ïndice | 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |
| 00 | 99 99 18 19 20 21 22 23 00 01 02 03 04 05 06 99 |
| 10 | 99 99 04 05 06 07 08 09 10 11 12 13 14 15 16 99 |
| 20 | 99 99 14 15 16 17 18 19 20 99 99 99 99 99 99 99 |
Aqui algunos ejemplos de como funciona la conversión horaria para distintas Horas y distintos Offsets
| Ejemplo | Hora UTC | País | Offset | Operación uC | Índice Tabla | Valor Tabla | Hora Local |
| 1 | 00 | Arg./Brasil | -3 | 8-3+00=05 | 05 | 21 | 21 |
| 2 | 09 | Arg./Brasil | -3 | 8-3+09=0E | 0E | 06 | 06 |
| 3 | 17 | Arg./Brasil | -3 | 8-3+17=1C | 1C | 14 | 14 |
| 4 | 00 | Chile/Bolivia | -4 | 8-4+00=04 | 04 | 20 | 20 |
| 5 | 11 | Chile/Bolivia | -4 | 8-4+11=15 | 15 | 07 | 07 |
| 6 | 16 | Canadá/USA | -5 | 8-5+16=19 | 19 | 11 | 11 |
| 7 | 08 | Canadá/USA | -6 | 8-6+08=0A | 0A | 14 | 14 |
Se usa en el caso que el Dia UTC ya sea el dia siguiente pero el Día Local a mostrar en el Reloj todavía deba ser el Día anterior. En este caso no hay algoritmo previo y se accede directamente a la tabla
| Dia UTC | 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0F |
| 00 | 99 99 01 02 03 04 05 06 07 08 99 99 99 99 99 |
| 10 | 09 10 11 12 13 14 15 16 17 18 99 99 99 99 99 |
| 20 | 19 20 21 22 23 24 25 26 27 28 99 99 99 99 99 |
| 30 | 29 30 |
Tabla de Dia Anterior al 1ro. de mes
Se usa en el caso que el Dia UTC ya sea el dia siguiente y además primer día del Mes, pero el Día Local a mostrar en el Reloj todavía deba ser el Día anterior. En este caso no hay algoritmo previo y se accede directamente a la tabla.
| Dia UTC | 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |
| 00 | 99 31 31 28 31 30 31 30 31 31 99 99 99 99 99 99 |
| 10 | 30 31 30 |
El valor 99 si es leido y mostrado en el Diplay en el proceso de alguna de las Tablas, indicará error de Tabla o de proceso.
Los demás detalles de uso de estas tablas para este diseño específico se pueden consultar en el código fuente ASM del Reloj.
Desarrollo del código de programación del uC en lenguaje ASM
El código completo de programación del uC se encuentra disponible en este enlace:
código ASM reloj retro IN0012
Y aquí algunas pantallas de IDE con parte de ese código:
código ASM reloj retro IN0012
Y aquí algunas pantallas de IDE con parte de ese código:
 |
| Fig.12.3 Código de Inicialización del Módulo USART de acuerdo a las Fig.12.1 y 12.2 |
 |
| Fig.12.4 Código de la ISR del módulo USART |
 |
| Fig.12.5 Código parcial de la Tabla de Corrección Horaria y sus Algoritmos |
Como en el diseño anterior, los programadores PICKit2 y PICKit3 de MicroChip que se usarán para flashear el uC se ven en las Figs. 7.9 y 7.10
En la próxima entrada continuamos con el próximo proyecto. Un saludo...
No hay comentarios:
Publicar un comentario