Disseny i simulació d'una interfície per a la comunicació de dades

TRABAJO FINAL DE CARRERA TÍTULO DEL TFC: Diseño de nuevas técnicas de integración de un encoder incremental. TITULACIÓN: Ingeniería Técnica de Telecomunicaciones, especialidad en Técnicas de Telecomunicación. AUTOR: Jose Muñoz Cruz DIRECTOR: Mariano Wis Gil SUPERVISOR: Gabriel Montoro Lopez FECHA: 29 de Junio de 2006 Título: Diseño de nuevas técnicas de integración de un encoder incremental. Autor: Jose Muñoz Cruz Director: Mariano Wis Gil Supervisor: Gabriel Montoro Lopez Fecha: 19 de junio de 2006 Resumen Este trabajo final de Carrera se realizó en el Institut de Geomàtica (IG). Este centro trabaja en la integración de diferentes sensores de navegación terrestre con el fin de construir un sistema más estable y robusto frente a las interferencias y/o pérdidas de señal. Uno de estos sistemas es el TAG, que integra un sistema INS/GPS. A causa de que el GPS presenta problemas como la pérdida de señal, el ocultamiento de satélites, etc. No se pueden corregir los desvíos que se producen en el sensor inercial. Para compensar estos errores sin el GPS, se pensó en introducir un encoger incremental. Como este encoger generaba un flujo muy elevado de datos que saturaban al TAG, en este proyecto se diseñó un circuito de adaptación que absorbía este flujo de datos y los enviaba al TAG mediante un sistema de paquetes. De esta forma se puede elevar la velocidad del sistema teniendo solo en cuenta las modificaciones pertinentes en el circuito intermedio. Title: Design about new integration techniques of an incremental encoder Author: Jose Muñoz Cruz Director: Mariano Wis Gil Supervisor: Gabriel Montoro Lopez Date: June, 29th 2006 Overview This work was made in Insitut de Geomatica (IG). This centre works about the integration among different sensors of terrain orientation with the purpose of building a more stable and robust sytem as opposed to the interferences and/or lost of signal. One of these systems is TAG, which integrates a INS/GPS System. On account that GPS presents problems as well as lost of signal, hiding satellites....we can't correct the deflection produced by the inercial sensor. In order to compensate these errors without the GPS, they thought in introduce an incremental encode. This encode generates a flow very high of dates and because of this the TAG becomes saturated. For this reason, they designed a circuit of adaptation that absorves this flow of dates and they are sent to the TAG in a system of packages. By this way, we can elevate the system's speed considering single the pertinent modifications in the intermediate circuit. “I know that you will not understand anything, but it will be very funny to try to read it” Para mis padres que me han apoyado en todo momento. INDICE 0. INTRODUCCIÓN ..................................................................................1 1. MARCO DEL PROYECTO ....................................................................3 1.1 Institut de Geomàtica [1] ................................................................3 1.1.1. Geomática [1] ..................................................................3 1.2 Generalidades de los sistemas de navegación [1] .........................4 1.2.1 Sistema de posicionamiento Global [1] ............................5 1.2.2. Sistemas de Navegación Inercial [1] ...............................6 1.2.3. Sistema INS/GPS [1] .......................................................7 1.2.4 El odómetro elegido [1] ....................................................8 2. La Elección del sistema ......................................................................10 2.1 Introducción .................................................................................10 2.2 Tipos de sistemas posibles .......................................................... 11 2.2.1 Los Contadores Digitales ...............................................11 2.2.2 La FPGA ........................................................................13 2.2.3 Los Microcontroladores PIC ...........................................14 2.3 comparativa sobre los dos métodos. FPGA y PIC’s .................... 15 2.3.1 Ventajas y problemas de cada uno de los sistemas .......15 2.3.2 Ventajas del lenguaje VHDL ...........................................17 2.4 infraestructura necesaria para implementar sobre el PIC ............17 3. Los Microcontroladores .......................................................................19 3.1 introducción a los microcontroladores .......................................... 19 3.1.1 ¿Que es un microcontrolador? .......................................19 3.1.2 Los microcontroladores “PIC” .........................................20 3.2 Estructura de un microcontrolador ...............................................20 3.2.1 El procesador o CPU ......................................................22 3.2.2 Memoria ROM ................................................................22 3.2.3 Memoria RAM ................................................................ 23 3.2.4 Registros y Bits ..............................................................24 3.2.5 Líneas de Entrada/Salida (E/S), (Puertos) ..................... 27 3.2.6 Módulos Temporizadores Internos (TMRs) ....................28 3.3 Utilizando un microcontrolador .................................................... 30 3.4 Características técnicas de los PIC 16F87x ................................32 3.4.1 Los puertos del PIC 16F87x ...........................................34 4. Simulación e Implementación del código ............................................ 35 4.1 Introducción .................................................................................35 4.2 Características de las señales del odómetro ...............................36 4.2.1 Cableado de pruebas .....................................................36 4.2.2 Señales Testeadas .........................................................37 4.2.3 Cálculos de los pulsos ....................................................39 4.3. Software de Implementación del sistema. ..................................40 4.3.1 El Mplab .........................................................................40 4.3.1.1 El programa en Mplab .......................................41 4.3.2 El CCS ...........................................................................42 4.3.2.1 El programa en CCS .........................................42 4.3.3 El Proteus .......................................................................44 4.3.3.1 Simulaciones en Proteus ..................................44 5. CONCLUSIONES Y MEJORAS FUTURAS ........................................49 6. BIBLIOGRAFIA ................................................................................... 51 0. Introducción 1 0. INTRODUCCIÓN Este trabajo final de carrera se realizó en El Institut de Geomàtica (IG), que es un centro de investigación y docéncia en técnicas de geodesia y navegación. Este centro trabaja en la integración de diferentes sensores de navegación terrestres con el fin de conseguir un sistema más estable y robusto ante las interferencias y/o pérdidas de señal. Una de las principales herramientas con las que trabaja IG, es el TAG (Trayectoria, Actitud (orientación) y Gravimetría) y consiste en un sistema que integra tanto a nivel software como hardware varios sensores de navegación terrestres. El TAG utiliza principalmente dos tipos de sensores, el GPS (Sistema de Posición Global) y el INS (Sistema de Navegación Inercial). El GPS utiliza los satélites para calcular su posición, por otro lado, los sistemas inerciales se basan en las medidas que les proporcionan una serie de sensores (acelerómetros y giroscopios). La combinación de estos dos sistemas se denomina INS/GPS, el INS se toma como sistema principal y el GPS es utilizado para ir corrigiendo los errores que se generan en los sistemas inerciales. A causa de que el GPS presenta problemas como la pérdida de señal, el ocultamiento de satélites, etc. No puede corregir los desvíos que se producen en el sensor inercial, a causa de esto se pensó en integrar otro sensor complementario que permitiera reducir la acumulación de errores del INS cuando el GPS se quedara sin señal. El sensor elegido para este caso fue un odómetro o encoger incremental, el cual es capaz de proporcionar información del desplazamiento en un solo sentido o plano del espacio. En la figura 0.1 podemos ver un esquema global del sistema implementado. Este proyecto es la continuación de un trabajo final de carrera realizado por Elena Sanz llamado “Integración de un odómetro en un hardware experimental de adquisición de datos para aplicaciones en navegación terrestre”; si nos ponemos en situación, el proyecto principal se separó en tres secciones. En la primera Elena seleccionó e integró un odómetro con el sistema TAG, pero la velocidad máxima permitida de 5Km/h era insuficiente. En la segunda parte que es la que tiene en sus manos en este momento, se integra una fase intermedio entre el odómetro y el TAG, que realiza un conteo de las señales y las envía en tramas para poder elevar la velocidad hasta los 100Km/h. Además se prepara el sistema para poder soportar dos odómetros a esa velocidad. En la tercera parte se modificará el TAG para que lea dicha señal y se adaptará finalmente el segundo odómetro. 8 Diseño de nuevas técnicas de integración de un encoger incremental. No obstante este tipo de sistemas también presentan sus inconvenientes:  Requiere una calibración periódica de la transferencia de orientación.  La inversión económica inicial es muy alta.  Requiere el conocimiento del campo de gravedad.  Hay pocos fabricantes de estos sistemas integrados y en muchos de estos casos este tipo de tecnología es militar con todos los problemas que comportan. Una vez explicado el sistema de navegación que utiliza el TAG se puede intuir la razón por la que se ha pensado en este proyecto. Si el vehículo que transporta el TAG se encuentra en una zona en la que la no hay señal GPS o ésta es de mala calidad, el INS perderá su referencia con lo que aparecerán errores de deriva. Una posible solución o ayuda es la incorporación de un sensor que pueda medir distancias en una de las direcciones de movimiento y cuyo buen funcionamiento no estuviera ligado al GPS. Esto ayudaría a corregir los errores del INS, eso sí, sólo en uno de los planos del espacio. 1.2.4 El odómetro elegido [1] En el anexo 4 podemos ver todo el estudio que se realizó en el TFC de Elena Sanz [1] para ver que tipos de odómetros había en el mercado y su funcionamiento; además de las particularidades que se tuvieron en cuenta en el momento que se eligió precisamente este. A continuación podemos ver cual fue el odómetro elegido y sus características. Después de haber analizado las necesidades de nuestro sistema, buscamos entre los diferentes fabricantes de odómetros del mercado y elegimos el encoder óptico incremental Type RY 76 TD de eje hueco continuo (thought shaft) de la marca HENGSTLER. Fig. 1.2 Odómetro Type RY 76 TD 1. Marco del Proyecto 9 Los motivos de la elección de este odómetro fueron:  Era Hollow shaft, con lo que simplificaba el montaje  La empresa Hengstler tenía sucursal en España, con lo que el tiempo de espera para obtenerlo era menor.  Una relación de calidad precio adecuada.  Robustez  Señal de salida TTL Sus principales características son:  6 tipos de señales A, B, Z y sus negadas  Una señal de alarma  Número de revoluciones máxima: entre 1800 y 6000 revoluciones por minuto según la temperatura en la que se trabajara.  Clase de protección: IP65 (Ver anexo 5)  Alimentación a 5V.  Señal de salida tipo Line driver, según estándar RS422 (Ver anexo 6) 10 Diseño de nuevas técnicas de integración de un encoger incremental. 2. La Elección del sistema 2.1 Introducción Para empezar ha hablar de elección del sistema, habría que explicar un poco de donde radica el problema. Como hemos mencionado varias veces, anteriormente a este proyecto hubo un anterior que estudió el odómetro, el TAG e implementó una primera fase de este proyecto que era ínter conexionar un encoder incremental con un sistema INS/GPS mediante el TAG. Cuando se hicieron las pruebas de campo, se detectó que el TAG se saturaba en el momento de controlar el flujo de datos que introducía el odómetro a una velocidad superior a los 5Km/h. Como la idea inicial era el uso de dos encoders de mayor resolución (unos 1000 pulsos por vuelta o superior), y estarían en un vehículo que, como velocidad máxima, llegara a los 100Km/h, era impensable un sistema sin un circuito intermedio que canalizara toda esa información. Para montar ese circuito intermedio, se pensó en diferentes opciones. En los sucesivos puntos de este capítulo podremos ver más extensamente cada una de las opciones que se tuvieron en cuenta. Una primera opción fue crear un sistema de contadores digitales conectados en cascada para llegar ha realizar el conteo. Pero al introducir otro odómetro e incrementar el flujo de datos de los 100 actuales, a 1.000 o 10.000 pulsos por vuelta, sugirió descartar esta opción rápidamente. Como segunda opción, se pensó en los microcontroladores PIC, y se buscaron las diferentes opciones que esta tecnología nos ofrecía. Pero la dificultad de aprender un lenguaje de programación en tan poco tiempo descartó esta opción por su dificultad. Como había estudiado las FPGA’s en la asignatura EMA “Enginyeria i Medi ambient”, se valoró la opción de realizar el circuito bajo esta tecnología. Después de ver que tipos de FPGA’s habían en el mercado, y cual era la que mas se ajustaba a nuestro sistema, se estudió si era realmente necesario usar esta tecnología para un sistema a priori mas sistemático. La idea de que el sistema no tenia que evolucionar por si solo, sino que debía realizar un trabajo mas “Mecánico”, descartó rápidamente las DSP o los nuevos sistemas DSPIC, y prácticamente las FPGA’s ya que estas ultimas tenían además dos problemas más a añadir. Uno de esos problemas era su elevado coste para un sistema de estas características; y el otro era que no estaba en stock en los distribuidores más cercanos y corríamos el riesgo de que no llegara a tiempo. Finalmente al descartar sistemas mas complejos se volvió ha valorar la opción de utilizar los PIC para realizar el proyecto. Se buscó un modelo que se ajustara a nuestras características y se encontró el PIC16F873. Este modelo se sustituyó finalmente por el PIC16F876 ya que este último permitía la implementación de los dos odómetros al incluir mayor memoria. También se 2. La elección del Sistema 11 valoró la posibilidad de usar el Pic16f876a que añadía un sistema analogicodigital que podría ser muy útil para otras aplicaciones que se pudieran realizar en “El Institut de Geomàtica”. Esta segunda opción se descartó porque complicaba un poco su adquisición. En el momento de buscar un distribuidor para adquirir los microcontroladores, se buscó entre otras cosas que estuviera cercano y tuviera circuitos en stock; finalmente se adquirió en RS-amidata ya que nos permitía usar componentes más ecológicos. En el anexo 6 se puede ver la técnica RoHS usada por microchip y distribuida por RS-amidata que hace más ecológica la tecnología de microcontroladores al usar componentes menos contaminantes que los usados en la fabricación habitual. A continuación podemos ver algunas características de estos sistemas y una comparativa que sirvió para decidirse finalmente entre las FPGA’s y los microcontroladores PIC, siendo estos últimos los finalmente elegidos para implementar la aplicación. 2.2 Tipos de sistemas posibles Para realizar la parte de adaptación de la señal entre el odómetro y el TAG, se eligieron diferentes sistemas para su implementación, los más importantes son: • Contadores digitales • FPGA • PIC’s De cada uno de estos sistemas se estudió su viabilidad, su implementación y sus inconvenientes; a continuación podemos una breve explicación de cada uno de estos sistemas. 2.2.1 Los Contadores Digitales Los contadores digitales nos permitían elaborar el sistema rápidamente sin inconvenientes de programación ni lenguaje, pero la placa implementada para este proyecto, solo serviría para las pruebas que al final haríamos con ella pero no serviría directamente para el proyecto global (que esta fraccionado en tres partes, la primera realizada por Elena Sanz, la segunda realizada por mi, y la tercera que se desarrollará en el próximo cuatrimestre por otro alumno del EPSC). 12 Diseño de nuevas técnicas de integración de un encoger incremental. Fig. 2.1 Estructura del 74LS193 El chip que vemos en la figura 2.1 fue el elegido a la hora de implementar un circuito con contadores digitales; pero aparte de los impedimentos que hemos explicado, este tipo de circuitos requieren un cierto pretratamiento de las señales de entrada, para así poder ajustar las señales y poder evitar los problemas asociados a un posible movimiento lento de las transiciones. Para poder realizar esto se había de implementar un precircuito que limpiara las señales A y B, que además al tener un desfase de 90º entre ellas dificultaba el diseño de dicho precircuito. Este tipo de circuitos requería además la utilización de la señal Z, que con el PIC hemos obviado ya que no nos daba información útil, ya que el contador se ha de ir inicializando (o reajustando). De esta manera el contador solo nos daba cuentas de vuelta completa y se perdía un poco la necesidad del conteo, por otro lado también podíamos generar nosotros mismos la señal de reseteo del contador, pero eso implicaba añadir un reloj de cuarzo para que reseteara el circuito 20 veces por segundo (20Hz es la frecuencia de reseteo del contador implementado en el PIC). Otra opción para implementar el circuito, era usar el 74HC193 que es un contador con un reloj descendente y otro reloj ascendente. Este chip lleva incorporados dos flip-flop que normalmente están en estado hight; además para implementar el reset se había de incluir en el circuito un switch, cuando este esté en low state, se realizará el reset como si esta señal perteneciera al sistema. Esta segunda opción, con el 74HC193, nos permitía detectar mejor la dirección ya que al poner uno de los flip-flop en estado bajo el chip cambia el contador de directo a inverso, aunque esto nos podía causar algún tipo de problema en la detección de la información en el TAG. Además de los impedimentos anteriormente explicados, mediante los contadores digitales no se podía generar una trama ya conocida para poder 2. La elección del Sistema 13 trabajar con el TAG mediante este sistema, así que la señal que le enviaríamos al TAG seria una secuencia de bits la cual no teníamos demasiado claro que pudiera llegar a las velocidades que nosotros nos estábamos planteando (alrededor de los 100Km/h). Todos estos impedimentos, además de que había la posibilidad de realizar cambios de última hora, nos podían llevar al traste alguna de las placas ya realizadas (en el hipotético caso de haber empezado con este sistema), todo esto nos convenció para descartar este tipo de sistemas. 2.2.2 La FPGA Una FPGA es un dispositivo lógico programable que se puede configurar para implementar cualquier circuito digital. Hay diferentes FPGA’s en el mercado con mas o menos recursos internos para poder así implementar diseños más complejos. Una vez configurada y grabada con nuestro diseño, nos quedará un único chip como única maquinaria, necesitando así muy pocos componentes exteriores para acabar el sistema. Los sistemas FPGA nos permiten tener un gran abanico de posibilidades a la hora de programarlos, pero su mejor característica es que están programarlos con el lenguaje VHDL. Gracias a este lenguaje, y a los programas asociados a él, el mismo programa transforma el código escrito en lenguaje VHDL a lenguaje maquina y así poderle pedir a este que sea él quien apure más o menos los recursos de la FPGA. De esta forma podemos elegir el grado de saturación que tendrá el dispositivo cuando esté trabajando por si solo. Este tipo de circuitos tiene una memoria muy superior a los PIC’s y por tanto nos permitiría implementar el circuito de conteo de los dos odómetros, e incluso poder añadir otros circuitos que se quieran implementar en el futuro o que actualmente se estén desarrollando en el mismo proyecto. Para programar las FPGAs son necesarias una placa de entrenamiento/grabación y un software (tal y como veremos también en los PIC’s) La placa de entrenamiento conocida es una UP1 de altera, es un modelo muy antiguo que permite realizar pruebas con la FPGA ya programada, y así asegurarse de que el circuito funcione correctamente. Esta placa se utilizó en la asignatura EMA (Enginyeria y Medi Ambient). El problema principal de este sistema aparte de su elevado precio (en comparación con los microcontroladores PIC), es que los dos distribuidores de ALTERA en Cataluña son Arrow y EBV Elektronik; y al no tener esta placa en stock, el plazo de entrega superaba el tiempo de espera que nosotros nos habíamos prefijado para poder realizar el proyecto sin ningún contrapié. Aunque en teoría no había ningún problema en utilizar una de las placas de la UPC mientras nos la enviaran, debíamos adaptarnos a los horarios de clase ya que estas placas se están utilizando actualmente y eso no nos dejaba suficiente margen de trabajo. 14 Diseño de nuevas técnicas de integración de un encoger incremental. El software para programar en VHDL este tipo de dispositivos es Quartus II Web Edition, que requiere una tarjeta de red; es el recomendado por ALTERA y es gratuito. También existe otro llamado MAX+ PLUS II Student Edition V10.2 + Advanced síntesis que realiza lo mismo pero este es de pago. Fig. 2.2 Placa de programación/entrenamiento de la FPGA Finalmente por estos contratiempos y porque el dispositivo elevaba mucho el coste y estaba sobre dimensionado para esta tarea, decidimos descartar la opción de utilizar una FPGA. 2.2.3 Los Microcontroladores PIC Aunque haremos una gran explicación de este tipo de dispositivos más adelante en el apartado 3 de esta memoria, ahora haremos una breve introducción de lo que son este tipo de microcontroladores. Los sistemas PIC y en especial el PIC16F876 que es el modelo elegido, nos permite implementar dicho circuito fácilmente ya internamente adjunta una UART, que permite la conexión mediante el protocolo RS232 entre el microcontrolador y un PC, o en nuestro caso nos permite la comunicación entre el odómetro y el TAG, y un “diferenciador” de fase, que nos permite saber el desfase entre las dos señales y así conocer el sentido de la marcha. Para programar el PIC es necesaria una placa de programación y un software basado en el lenguaje C. Para adquirir la placa de programación PIC/ICD2, hablamos con la empresa SAGITRON, ubicada en castelldefels, cuyo presupuesto asciende a 128 Euros + IVA /precio unitario. Aunque con una sola placa ya habría suficiente. En este 2. La elección del Sistema 15 pack ya se incluía un software para la comunicación con el ordenador llamada MPlab que explicaremos más adelante. Pero la programación mediante este software se hace muy difícil ya que requiere escribir en lenguaje ensamblador. Para simplificar un poco la programación, se decidió adquirir otro programa que usara un lenguaje de programación que no fuera de bajo nivel; ya que el lenguaje de programación más extendido es el C, este fue el finalmente elegido. El software de programación basado en el lenguaje C elegido fue el CCS C, que viene en diferentes configuraciones, aunque con la licencia del PCW fue suficiente. Al final se eligió este PIC, ya que por su memoria nos permite implementar los dos odómetros, además de que este microcontrolador será utilizado por el Institut de Geomàtica para implementar otros proyectos en los que está actualmente. 2.3 comparativa sobre los dos métodos. FPGA y PIC’s En este apartado podemos ver las principales diferencias y características de funcionalidad de los dos dispositivos; como podremos comprobar las FPGA’s son chips mucho mas completos y con mayor capacidad para programar diferentes diseños, característica muy importante en el momento de adquirir un sistema para un laboratorio de investigación, pero para este diseño en particular esta sobredimensionado y su elevado coste no compensaba para la aplicación que nosotros queríamos desarrollar. Los microcontroladores PIC, y en especial el 16F876 tiene recursos suficientes como para emplearse en este diseño y en otros de características similares. El tener implementado dos periféricos, un contador y una UART, y poder trabajar con ellos simultáneamente fueron factores decisivos en el momento de la elección de la tecnología. 2.3.1 Ventajas y problemas de cada uno de los sistemas Para valorar cual de estos dos sistemas es el mejor a la hora de implementar nuestro sistema se ha de tener en cuenta varias cosas, entre ellas el tipo de circuito que vamos a diseñar, la necesidad o no de tener controlado el reloj interno del sistema, el numero de puertas, la facilidad de que otros en el futuro puedan modificar el programa, etc. Es aquí donde entramos a valorar las diferentes ventajas e inconvenientes que nos proporciona cada uno de estos sistemas • Para poder usar un PIC sólo es necesario una protoboard y unos pequeños cables donde introduciremos las señales, ya que no es necesario un circuito de adecuación para el PIC. • La FPGA si requiere de un circuito de adecuación especifico en el cual hay varios componentes críticos como el uso de cristales de cuarzo, ya 16 Diseño de nuevas técnicas de integración de un encoger incremental. que la FPGA no lleva ningún reloj interno, pero solo es necesario un cristal a la frecuencia más elevada porque si se pueden crear varios divisores de frecuencia internos y así poder utilizar cada apartado del programa como si fuera independiente. • El PIC lleva incorporado un reloj interno modificable para que trabaje a la frecuencia que nosotros creamos más óptima para el sistema. • La placa de la FPGA es un programador/entrenador, de esta manera podemos probar el programa directamente en la FPGA sin tener que montar el circuito final donde vaya a ir implementada, de esta forma se puede ir perfeccionando el programa, y al ser tan solo un prototipo, se puede ínter conexionar dicha placa con el sistema final sin tener que implementar la placa final. • El software de la FPGA lleva un simulador incorporado, donde puedes generar las señales teóricas recibidas y así ver como se comportaría nuestro sistema, incluso antes de gravar el chip, de esta forma no se pierde tanto tiempo programando los chips y probándolos, ya que se podría grabar directamente el programa final y hacer una única prueba. • La memoria en los PIC’s es más limitada y depende directamente del chip elegido para el sistema, en nuestro caso el PIC16F876 tiene suficiente memoria como para incluir dos odómetros al sistema, pero probablemente será insuficiente para otros proyectos futuros. • La memoria en la FPGA aparte de ser mayor, puede ser programada dentro del código, así se puede aprovechar recursos de memoria que habría de utilizar el programa que de otra forma estarían desaprovechados, aparte es más fácil poder incluir en el sistema una memoria externa y así ir ampliando el circuito sin tener que cambiar el chip elegido. • La programación de los PIC’s aunque sea en lenguaje C, siempre está mas cercana al código máquina (assembler), y el programa final es un poco menos intuitivo que la programación C ordinaria. • La FPGA se programa en lenguaje VHDL que al ser un lenguaje de alto nivel, aprovecha mejor los recursos del sistema que cualquier otro lenguaje, aparte es muy fácil de utilizar por su parecido al lenguaje C, • El PIC elegido, nos servirá para este sistema y algunos otros circuitos similares de implementación fácil, sin embargo la FPGA nos permite implementar circuitos mucho más complejos más fácilmente. 2. La elección del Sistema 17 2.3.2 Ventajas del lenguaje VHDL • Independencia de la metodología del diseño • Portabilidad. Permite la transferencia de diseños a diferentes entornos CAD, de simulación y de síntesis. • Rápido “Time-to-Market”, combinado con herramientas de síntesis automáticas permite exportar un diseño en tiempo record. • Versatilidad en la descripción de sistemas complejos • Posibilidad de reutilización de código en otros sistemas. • Es un lenguaje libre, e independiente de los fabricantes. 2.4 infraestructura necesaria para implementar sobre el PIC Para implementar cualquier sistema bajo tecnología PIC, son necesarias diferentes herramientas tanto software como hardware. Primero se ha de elegir de que compañía adquiriremos los microcontroladores, en nuestro caso hemos escogido los PIC’s de microchip. Esta empresa ya nos proporciona un software llamado Mplab mediante el cuál podemos programar el PIC bajo lenguaje ensamblador; pero este tipo de lenguaje es muy complejo y especifico de cada microcontrolador, así que si se cambia de familia de microcontroladores todo lo aprendido no sirve demasiado, y se ha de aprender las nuevas funciones para esa familia. Como esto es muy engorroso para una empresa que ha de cambiar de microcontrolador a menudo, decidimos familiarizarnos con un programa que funcionara bajo lenguaje C. El elegido fue el CCS C, ya que además de haberlo utilizado con anterioridad en la asignatura de EMA (Enginyeria i Medi Ambient), este software nos permitía mediante un pluggin que lleva incorporado poder utilizar el código directamente en el Mplab, de esta manera es más fácil el intercambio de archivos y de código entre programas, y no se tenia que pasar cada uno de ellos a hexadecimal para su implementación, ni simulación. Para poder realizar simulaciones más complejas que las que nos permitían tanto el Mplab como el CCS, decidimos también adquirir el programa PROTEUS, que es una potente herramienta de simulación para microcontroladores. De esta manera podemos realizar la simulación con señales casi idénticas a las reales y poder ver que fallos podía provocar el código una vez implementado físicamente en el chip. Una vez probado el código y ver que tanto en las simulaciones de uno u otro programa, el resultado era el esperado, fue necesario la adquisición de una placa que nos sirviera a la vez de programador y de entrenamiento del chip, ya 24 Diseño de nuevas técnicas de integración de un encoger incremental. 3.2.4 Registros y Bits Un registro es una posición de memoria en la cual se puede almacenar un dato. Es decir que la memoria esta dividida en pequeñas “partes” llamadas “Registros”. Dentro de la memoria, cada registro se identifica mediante un número, el cual se denomina “Dirección de memoria” y generalmente está expresado en formato Hexadecimal. El primer registro de una memoria corresponde a la dirección 00H. Dado que identificar a cada registro mediante un número hexadecimal puede resultar muy complejo a la hora de diseñar el programa, existe la posibilidad de asignar un “nombre” a una dirección de registro. En general, este nombre está directamente relacionado con la función que cada registro cumple dentro del sistema. Los registros no solo son utilizados por el programador (usuario) para almacenar los datos que la aplicación debe procesar, sino que, además, sirven para controlar todo el funcionamiento del microcontrolador en su conjunto. Esta función, la cumple un conjunto de registros que ya vienen “Predefinidos” desde la fábrica. Es decir, que el fabricante asigna las funciones de configuración y control del microcontrolador en un grupo de registros y el usuario no puede modificar la función que cumple cada uno de éstos. Cada Registro está dividido en 8 “partes” a los cuales se los denomina “Bits”. Entonces podemos decir que un Registro esta formado por un conjunto de 8 bits. El Bit es la menor unidad de información que un sistema digital puede procesar y solo puede contener los valores lógicos 0 y 1. Los sistemas digitales representan la información en forma de bits porque sus circuitos sólo pueden tener dos estados: encendido o apagado. En general podemos decir que: 1 = Encendido = Verdadero = “SI” = +5V 0 = Apagado = Falso = “NO” = 0V Cada Bit se identifica por la posición que ocupa dentro del registro, siendo el primer Bit el número 0, que es el que se encuentra en el extremo derecho del registro. Fig. 3.3 Estructura de un registro 3. Los Microcontroladores 25 Al igual que los registros, se puede asignar un nombre a cada Bit para facilitar su identificación. En un registro se puede almacenar una combinación 8 ceros y/o unos. Esto nos da una cantidad de 8 2 combinaciones, es decir, 256 posibles combinaciones de ceros y unos. Esto significa que un registro puede procesar valores entre 0 y 255. Esta característica de procesar números (“Dígitos”) es lo que da el nombre a la “Electrónica Digital”. La electrónica digital procesa números formados por combinaciones de ceros y unos. Cualquier señal analógica debe ser “digitalizada”, es decir, convertida a números, para poder ser procesada en un sistema digital. Podemos decir que el conjunto de ceros y unos almacenados en un registro se trata de un número entre 0 y 255, expresado en sistema Binario, esto es, en base 2. Para interpretar dicho número debemos realizar el cálculo de conversión de base para poder expresarlo en sistema decimal. El siguiente ejemplo muestra el desarrollo de un cálculo de conversión de base de sistema binario (base 2) a sistema decimal (base 10): Fig. 3.4 Cambio de Sistema binario a sistema decimal Se llama “Peso Binario” al valor que representa un Bit según la posición que ocupa dentro del registro. El Bit que está ubicado más hacia la derecha del registro, es el Bit menos significativo (LSB, Least Significant Bit) y tiene un peso de 120=. El Bit del extremo izquierdo del registro es el Bit más significativo (MSB, Most Significant Bit) y tiene un peso de 12827=. Los pesos binarios crecen de derecha a izquierda en potencias de 2. 26 Diseño de nuevas técnicas de integración de un encoger incremental. Fig.3.5 Sistema de pesos en los números binarios Una manera de simplificar el cálculo de conversión de binario a decimal, es, directamente sumar los valores de los pesos binarios de los bits cuyo valor sea 1. Fig. 3.6 Simplificación del cálculo de conversión. El sistema hexadecimal es un sistema en base 16 y consta de 16 dígitos diferentes que son: del 0 al 9 y luego de la letra “A” a la “F”, es decir, 10 dígitos numéricos y seis caracteres alfabéticos. El sistema hexadecimal se usa como forma simplificada de representación de números binarios y debido a que 16 es una potencia de 2 ( 1624=), resulta muy sencilla la conversión de los números del sistema binario al hexadecimal y viceversa. Mediante el sistema hexadecimal podemos representar un valor numérico de 8 bits utilizando sólo 2 dígitos. De ésta manera estamos dividiendo el registro de 8 bits en 2 partes de 4 bits cada una llamada Nibble. Al nibble correspondiente a los 4 bits menos significativos, se lo denomina “Nibble Bajo” y al nibble correspondiente a los 4 bits más significativos se lo denomina “Nibble Alto”. 3. Los Microcontroladores 27 Fig. 3.7 Separación entre Nibbles El sistema hexadecimal es utilizado para identificar las direcciones de registros de las memorias en sistemas digitales porque permite representar el valor de un Nibble con sólo 1 digito, ya que: Fig. 3.8 Sistema Hexadecimal Esto permite representar números grandes utilizando unos pocos dígitos. Por ejemplo: Fig. 3.9 Representación de 4 dígitos hexadecimales En la programación de microcontroladores, es habitual utilizar los 3 sistemas de numeración (Binario, Decimal y Hexadecimal) dependiendo del proceso que necesitemos realizar. Por eso es fundamental tener claros estos conceptos. 3.2.5 Líneas de Entrada/Salida (E/S), (Puertos) Los microcontroladores cuentan con una serie de pines destinados a entrada y salida de datos o señales digitales. A estos pines se les denomina “Puerto”. Como mencionamos anteriormente, todo el funcionamiento del microcontrolador está controlado a través de los registros. Los puertos no son 28 Diseño de nuevas técnicas de integración de un encoger incremental. la excepción, también están controlados por los registros. Por esto, un puerto no puede estar formado por más de 8 pines; 1 Pin por cada Bit de un registro. Un puerto si puede estar formado por menos de 8 pines. Un microcontrolador puede contener varios puertos dependiendo del modelo. A cada puerto se lo identifica con una letra. Por ejemplo; “Puerto A”, “Puerto B”, etc. Para poder utilizar un puerto, primero el mismo debe ser configurado. Cada pin de un puerto puede ser configurado como entrada o salida independientemente del resto de los pines del mismo puerto. 3.2.6 Módulos Temporizadores Internos (TMRs) Un temporizador interno (TMR) es un módulo de hardware incluido en el mismo microcontrolador el cual está especialmente diseñado para incrementar automáticamente el valor de un registro asociado al TMR cada vez que el módulo TMR recibe un pulso. A este pulso se lo llama “señal de reloj”. El módulo TMR siempre incrementa el valor del registro asociado, nunca decrementa dicho valor. Algunos microcontroladores pueden incluir más de un módulo TMR y la señal de reloj de cada uno de éstos puede ser de origen interno o externo. Si el origen de la señal de reloj está configurado como externo, el módulo temporizador puede ser utilizado como un contador de eventos externos, incrementando el TMR con cada pulso recibido mediante el pin correspondiente. Si el origen de la señal de reloj es interno, el TMR incrementa con cada ciclo del oscilador. Esto permite utilizar el temporizador como “contador de ciclos de programa”, donde, un ciclo corresponde al tiempo de ejecución de una instrucción, lo cual se puede calcular con la siguiente fórmula: 4 . 1 OscilaciónFrec (3.1) Donde “Frec. Osc.” es la frecuencia del oscilador utilizado. Dado que la velocidad de ejecución del microcontrolador corresponde a ¼ de la velocidad del cristal utilizado, cada ciclo de programa se ejecuta en un tiempo determinado según el cristal que estemos utilizando. Por ejemplo; con un cristal de 4Mhz la velocidad real de procesamiento del microcontrolador es de 1 Mhz. Aplicando la siguiente fórmula: 3. Los Microcontroladores 29 4 000.000.4 1 ms01.0 000.000.1 1= )(101.0 domicrosegunsms μ = (3.2) Esto significa que cada ciclo de programa se ejecuta a s μ 1 000.000.1 1= y dado que cada incremento del TMR corresponde a un ciclo de programa, si contamos los incrementos de un TMR, indirectamente podremos calcular el tiempo transcurrido. El incremento del TMR se realiza de manera automática y de forma paralela a la ejecución del resto del programa. Esto significa que el programa no debe “controlar” el incremento del TMR, lo cual sí debe realizarse en las temporizaciones por bucles, en las cuales el microcontrolador se queda “esperando” a que transcurra un tiempo, y no pueden ejecutarse otras tareas mientras no finalice la temporización. Entonces el TMR puede ser utilizado como temporizador mientras el microcontrolador ejecuta otros procesos. Por ejemplo: si diseñamos un programa que encienda y apague un led cada 1 segundo, el microcontrolador enciende el led y luego puede ocuparse de esperar a que transcurran los ciclos correspondientes a 1 segundo, luego apaga el led y continua esperando. Pero si el microcontrolador debe realizar alguna otra tarea además de temporizar, por ejemplo, mostrar valores en dígitos de 7 segmentos, el micro no puede quedarse temporizando por bucles ya que mientras se encuentre temporizando no podrá realizar el proceso de muestreo de los datos en los displays, y como resultado tendremos que los displays se apagan mientras el microcontrolador se encuentra temporizando. En este caso, se utiliza un TMR para realizar la temporización mientras el microcontrolador se ocupa de mostrar los datos en los displays. En general los microcontroladores cuentan con una interrupción por desbordamiento del TRM, es decir que, el microcontrolador se interrumpe cuando el TMR0 pasa de [] )11111111(255 Ba [] )00000000(0 B en los temporizadores de 8 bits y cuando pasa de [] )11111111_11111111(65535 B a [] )00000000_00000000(0 B en los temporizadores de 16 bits. Dado que s μ 256 es un tiempo relativamente corto (para un TMR de 8 bits a 4 Mhz.), existe la posibilidad de preescalar el TMR0 para que el registro asociado al TMR se incremente cada 2, 4, 8,o más ciclos. De esta manera, estamos multiplicando la cantidad de ciclos que deben ejecutarse para realizar un incremento del TMR. Al prescalador también se lo denomina predivisor. Por ejemplo, con un predivisor de 8, cada incremento del TMR se realiza cada 8 30 Diseño de nuevas técnicas de integración de un encoger incremental. ciclos de programa y el desbordamiento del TMR se realizara cada 2048 ciclos )8*255( ciclossincremento . Así podemos realizar interrupciones con periodos de tiempo mayores. 3.3 Utilizando un microcontrolador Como mencionamos anteriormente, el microcontrolador tiene una memoria de programa, donde grabamos las instrucciones necesarias para que el micro realice el trabajo que necesitamos. Cuando compramos un microcontrolador, la memoria de programa viene vacía. Para que un microcontrolador funcione es necesario “programarlo”. Los microcontroladores se programan en un lenguaje de programación llamado Ensamblador (en inglés Assembler) cuya principal característica es su altísima complejidad. Los lenguajes de programación se clasifican según el “Nivel” de programación en: • Lenguaje de “Alto Nivel”: permite que los algoritmos se expresen en un nivel y estilo de escritura fácilmente legible y comprensible por el hombre. En la actualidad se trata de lenguajes de tipo visual. • Lenguaje de “Bajo Nivel”: el usuario se acerca un poco más al lenguaje de maquina. Permiten un acceso más amplio al control físico de la maquina (hardware). • Lenguaje Ensamblador: Podríamos considerarlo el lenguaje de más bajo nivel. El usuario escribe código en el mismo “idioma” del procesador. Se tiene control total del sistema. Es necesario un conocimiento de la arquitectura mecánica del procesador para realizar una programación efectiva. El lenguaje de programación es muy especifico para cada modelo de procesador, incluso puede variar de un modelo a otro de procesador dentro de un mismo fabricante. • Podemos decir que los lenguajes de alto Nivel se asemejan más al lenguaje humano y que los lenguajes de bajo Nivel se asemejan más al lenguaje de máquina y en el lenguaje ensamblador el usuario debe programar en el propio “idioma del procesador”. 3. Los Microcontroladores 31 Fig. 3.10 Lenguajes de programación El microcontrolador sólo entiende de números, es decir que, el código Assembler (texto) no puede ser procesado directamente por el microcontrolador. Para poder grabar el programa en el micro, primero debemos convertir el texto del código Assembler a números, en general, en formato hexadecimal. A este proceso se le llama “Compilación”. Una vez desarrollado el código Assembler, el mismo debe ser “compilado”. Esto se realiza con un “software compilador” el cual se puede obtener de manera gratuita desde la página Web del fabricante del microcontrolador. El archivo compilado tiene una extensión .hex. Por último, después de compilado, el programa está listo para ser grabado al microcontrolador. Esto realiza mediante una “placa programadora”. A ésta placa programadora, comúnmente se la llama “programador”. Existen distintos tipos de programadores los cuales pueden ser para conectar a la PC mediante el puerto Serie (COM) o Paralelo (LPT). Cada programador trabaja en conjunto con un software, mediante el cual se realiza el proceso de lectura y escritura de los microcontroladores. A continuación se presenta un resumen del proceso de desarrollo del código y grabación de un microcontrolador: 1) Escribir el código Assembler. Se genera un archivo con extensión ASM. 32 Diseño de nuevas técnicas de integración de un encoger incremental. 2) Compilar el código Assembler. Se genera un archivo con extensión HEX. 3) Grabar (transferir) el programa desde la PC al microcontrolador mediante un programador. De estos 3 pasos, el primero insume el 98 % de tiempo y esfuerzo. 3.4 Características técnicas de los PIC 16F87x Inicialmente todos los microcontroladores incorporaron la arquitectura de Von Neumann, la cual se caracteriza por disponer de una sola memoria principal donde se almacenan los datos y las instrucciones. A esta memoria se accede a través de un sistema de buses único (direcciones, datos y control). Los microcontroladores de la familia 16F87x, al igual que el resto de los microcontroladores de la actualidad, están diseñados con la arquitectura Harvard. La arquitectura Harvard dispone de dos memorias independientes; una que contiene sólo instrucciones, y otra donde se almacenan los datos. Ambas memorias cuentan con sus respectivos sistemas de buses de acceso y es posible realizar operaciones de acceso (lectura o escritura) simultáneamente en ambas memorias. • Voltaje de alimentación: 5VCC. • CPU RISC • Circuito Integrado de 18 pines. • Pines de configurables como Entrada o Salida: o 16F870/3/6 = 22 pines o 16F874/7 = 33 pines • Frecuencia operación máxima: 20 Mhz. • Memoria Flash: o 16F870/3/4 = 4 Kbytes o 16F876/7 = 8 Kbytes • Memoria de Datos: o 16F870/3/4 = 192 Bytes o 16F876/7 = 368 Bytes • Memoria de Datos EEPROM: o 16F870/3/4 = 128 Bytes o 16F876/7 = 256 Bytes 3. Los Microcontroladores 33 • 2 Temporizadores internos de 8 bits. • 1 Temporizador interno de 16 bits. • Módulos CCP (Captura, Comparación y PWM): o 16F870 = 1 módulo o 16F873/4/6/7 = 2 módulos • 1 Módulo de comunicaciones USART. • Conversores Analógico-Digital: o 16F870/3/6 = 5 canales o 16F874/7 = 8 canales • Interrupciones: o 16F870/3/6 = 13 o 16F874/7 = 14 Como mencionamos anteriormente, para que un microcontrolador funcione es necesario grabarle un programa en su interior. Este programa será leído y ejecutado línea a línea por la CPU. Para que la CPU funcione, debe contar con un generador de impulsos de reloj externo que sincroniza el funcionamiento de todo el sistema. Como origen de la señal de reloj externa utilizamos un cristal. El microcontrolador ejecuta cada instrucción (1 ciclo de programa) a ¼ de la velocidad del cristal utilizado. En general, un ciclo de programa corresponde a una línea de código Assembler. Por ejemplo, si utilizamos un cristal de 4 Mhz, el microcontrolador estará ejecutando el código a una velocidad de 1 Mhz. Es decir que, ejecutará 1.000.000 de líneas de código del programa por segundo. Por lo tanto, cada línea de código se ejecutará en 1 microsegundo . 000.000.1 1Seg 40 Diseño de nuevas técnicas de integración de un encoger incremental. próximo el odómetro por un encoger incremental de mayor resolución y eso haría inviable el uso de un contador de 8 bits. Fig. 4.8 Sistema de conexión del odómetro En la figura 4.8 podemos ver el sistema que se montó para conectar el odómetro con la rueda de pruebas y así poder transmitir el movimiento angular. Esta estructura está formada por un eje en el que está colocada la rueda y el odómetro y una estructura de acero que sujeta este eje. Finalmente aunque los siguientes cálculos nos daban para un contador de 8 bits, pero se programó el contador a 16 bits para así poder implementar los dos odómetros y los aumentos en la frecuencia sin tener que modificar el código. Como podemos comprobar en la tabla 4.2 se tuvieron en cuenta diferentes diámetros para la rueda donde se instalara el odómetro ya que la rueda de pruebas no será en la que finalmente se instale el sistema. Tab. 4.2. Cálculo sobre diámetros y # de bits. Ø rueda Vel. Máxima # por Trama Bits Contador Supuesto 1 50 cm. 100 Km./h 88.42 7 Supuesto 2 16 cm. 100 Km./h 276.31 9 Supuesto 3 16 cm. 92 Km./h 255 8 Supuesto 4 17.2 cm. 100 Km./h 255 8 4.3. Software de Implementación del sistema. 4.3.1 El MPlab El MPlab es un software que junto con un emulador y un programador de los múltiples que existen en el mercado, forman un conjunto de herramientas de desarrollo muy completo para el trabajo y/o el diseño con los 4. Simulación e Implementación del código 41 microcontroladores PIC desarrollados y fabricados por la empresa Arizona Microchip Technology (AMT). El MPlab incorpora todas las utilidades necesarias para la realización de cualquier proyecto y, para los que no dispongan de un emulador, el programa permite editar el archivo fuente en lenguaje ensamblador de nuestro proyecto, además de ensamblarlo y simularlo en pantalla, pudiendo ejecutarlo posteriormente en modo paso a paso y ver como evolucionarían de forma real tanto sus registros internos, la memoria RAM y/o EEPROM de usuario como la memoria de programa, según se fueran ejecutando las instrucciones. Además el entorno que se utiliza es el mismo que si se estuviera utilizando un emulador. 4.3.1.1 El programa en MPlab El programa MPlab lo conseguimos al adquirir la placa de programación del microcontrolador, ya que microchip lo distribuye gratuitamente. Al adquirir el CCS C, que trataremos de el en el siguiente apartado, junto a este software había un pluggin instalable para que el MPlab pudiera compilar un archivo programado en C. Al compilar el código en el MPlab, éste genera un archivo en hexadecimal que podemos volcar directamente en el programador ICD 2. Además, el programa Proteus es también compatible con el MPlab así que usemos este programa como intermediario ente el CCS y el Proteus (ambos se explicarán con detalle en los siguientes apartados). Fig. 4.9 Compilación del código en MPlab 42 Diseño de nuevas técnicas de integración de un encoger incremental. 4.3.2 El CCS Si queremos realizar la programación de los microcontroladores PIC en un lenguaje como el C, es preciso utilizar un compilador de C. Dicho compilador nos genera ficheros en formato hexadedimal, que es el necesario para programar (utilizando un programador de PIC) un microcontrolador de 6, 8, 18 ó 40 patillas. El compilador de C que vamos a utilizar es el PCW de la casa CCS Inc. A su vez, el compilador lo integraremos en un entorno de desarrollo integrado (IDE) que nos va a permitir desarrollar todas y cada una de las fases que se compone este proyecto, desde la edición hasta la compilación pasando por la depuración de errores. La última fase, a excepción de la depuración y retoques hardware finales, será programar el PIC. Al igual que el compilador de Turbo C, éste "traduce" el código C del archivo fuente (.C) a lenguaje máquina para los microcontroladores PIC, generando así un archivo en formato hexadecimal (.HEX). Además de éste, también genera otros seis ficheros, que son copias de seguridad y otros archivos de opciones. 4.3.2.1 El programa en CCS La primera intención era hacer un contador de pulsos de 8 bits, y usar la entrada del Timer0 para realizar la detección, después enviar lo contado mediante tramas a través de la UART a una frecuencia de 20Hz. #use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8) Como podemos ver en la sentencia anterior la salida de la UART está configurada a 9600 bps, aunque sería insuficiente en el momento de incorporar el segundo odómetro o para odómetros de resolución muy elevada. Finalmente se tomó la entrada del Timer0 para la señal B (ya que esta entrada es de 8 bits) pero solo se usará para detectar la dirección del odómetro o dicho de otra forma para detectar el desfase entre las dos señales. La entrada del Timer1 se eligió para detectar la señal A (ya que esta entrada es de 16 bits) y así nos servirá también para odómetros de mayor resolución. La recarga de 50ms que vemos en el siguiente trozo de código sirve para realizar un reset del contador 20 veces por segundo y activar la bandera “Transmitir” para que la función monte la trama y la envíe a través de la UART. #int_TIMER1 void TIMER1_isr() { set_timer1(delayTMR1us(50000)); //recargar otros 50ms Transmitir = 1; //indicar transmitir } Hay que tener en cuenta que los pulsos son siempre iguales y con el mismo ancho de banda, lo único que va variando es la frecuencia que depende directamente de la velocidad. Si tenemos 100 pulsos por vuelta y por ejemplo 10 vueltas por segundo, estaríamos midiendo unos 1000 pulsos por segundo, 4. Simulación e Implementación del código 43 esto nos da que en 1ms se debe medir el desfase. Para ello se tomó la decisión de detectar el valor de B directamente cuando se tuviera un flanco de subida, y según el valor que detectáramos sabríamos cual era el sentido. Esto simplificaba mucho el código y nos ahorraba hacer una estima del desfase entre las señales. Otro dato a tener en cuenta es que la trama se envía en ASCII, si dejamos que sea el código en C quien transforme estos datos tendremos una demora de transformación, demora que nos retrasará el envío. Para paliar este efecto se pensó en hacer un paso de hexadecimal a BCD mediante los Nibbles y luego al incrementar las variables en 0x30 se consigue pasar directamente de BCD a ASCII y así conseguir la transformación sin penalización en el tiempo. Esta función la realiza el código que vemos a continuación. #define tascii 0x30 //para pasar de decimal a ASCII //Rutina para convertir la variable de intensidad de binario a BCD void convert2BCD(void) {int i; bin_2_BCD._byte.BCDbyteA = 0; bin_2_BCD._byte.BCDbyteB = 0; bin_2_BCD._byte.BCDbyteC = 0; for(i=0; i<16; i++){ if (bin_2_BCD._nibble._nibbleA > 4) bin_2_BCD._nibble._nibbleA += (3+tascii); if (bin_2_BCD._nibble._nibbleB > 4) bin_2_BCD._nibble._nibbleB += (3+tascii); if (bin_2_BCD._nibble._nibbleC > 4) bin_2_BCD._nibble._nibbleC += (3+tascii); if (bin_2_BCD._nibble._nibbleD > 4) bin_2_BCD._nibble._nibbleD += (3+tascii); if (bin_2_BCD._nibble._nibbleE > 4) bin_2_BCD._nibble._nibbleE += (3+tascii); shift_left(&bin_2_BCD,5,0); } } En la trama a enviar, además de los datos contados, se le añade un carácter de cabecera (head), otro carácter de final de trama, y se le añade un bit que nos indica la dirección en la cual está girando el odómetro. El código relacionado es el que encontramos a continuación. void enviartrama(void) {char head; //cabezera de la trama char fin; //caracter final de la trama char N1, N2, N3, dir; //variables de envío strcpy(head,"Z"); strcpy(fin,"Z"); If (sentido == 2) {Strcpy (dir,"2") ;} //introduce el valor de la dirección Else {strcpy (dir,"1") ;} //copia los Nibbles en las variables de envío strcpy(N1,(bin_2_BCD._byte.BCDbyteC+tascii)); strcpy(N2,(bin_2_BCD._byte.BCDbyteB+tascii)); strcpy(N3,(bin_2_BCD._byte.BCDbyteA+tascii)); 44 Diseño de nuevas técnicas de integración de un encoger incremental. //printf("Z1471Z"); //prueba de trama printf("%c%c%c%c%c%c ", head, N1, N2, N3, dir, fin); //trama a enviar } Otro de los problemas con los que nos hemos encontrado es que al enviar la trama se perdían pulsos ya que no contaba a la vez que trabajaba con la UART. La transmisión se ha de hacer a la vez que se hace la medición de los pulsos porque sino se perderían muchos pulsos y con lo cual los datos que se envían para saber la distancia recorrida eran erróneos e iban aumentando según pasaba el tiempo. Estas dos acciones las debía realizar el PIC en paralelo, para ello decidimos trabajar con interrupciones para poder usar el contador de forma independiente de la UART. El código completo lo podemos encontrar en el ANEXO 7. 4.3.3 El Proteus El Proteus es un programa de simulación que permite realizar un circuito virtual con las mismas características que tendría implementándolo físicamente. Con este software, también se pueden simular todo un grupo de instrumentos de laboratorio tales como osciloscopio, analizador de redes, fuentes de alimentación, analizador de espectros, etc. Además, también se pueden simular un gran número de circuitos y elementos electrónicos como pantallas LCD, amplificadores, Max55, resistencias, condensadores, etc. Gracias a estas características, el Proteus es una de las herramientas de simulación más completas que podemos encontrar en el mercado, ya que nos permite incluir todos los componentes que llevará nuestro circuito, así como los instrumentos que usaremos en el laboratorio para poder detectar posibles incompatibilidades y/o errores en el sistema. Este software nos permite cargar sobre un microcontrolador virtual el código que hemos realizado bajo CCS o bajo MPlab y simular las señales que nos llegaban del odómetro, de esta forma hemos ido reparando el programa antes de programarlo directamente sobre el microcontrolador físico. 4.3.3.1 Simulaciones en Proteus Antes de realizar la implementación directa con el microcontrolador, se decidió realizar algunas simulaciones para comprobar el comportamiento durante largo tiempo del sistema y con varios supuestos diferentes. De esta manera podíamos comprobar la respuesta del programa y el funcionamiento del microcontrolador sin tener que montar un gran sistema físicamente en el laboratorio. En la figura 4.10 podemos observar que se diseño un circuito en el cual tan solo había el microcontrolador PIC16F876, un reloj de cuarzo a 4Mhz, un 4. Simulación e Implementación del código 45 display conectado a la salida de la UART programado para mostrar los caracteres ASCII que le llegaran, la alimentación, el GND, y las señales A y B. Fig. 4.10 Prueba de envío con trama ya conocida Z1471Z En esta primera prueba se configuró una trama ya conocida, en este caso Z es el valor de la cabecera y del final de trama, se tomó la dirección como directa y el valor del contador se puso a 147. Esta configuración ya conocida nos sirvió para calibrar las simulaciones y asegurarnos de que el resultado que aparecía en el LCD era el esperado. Si no hubiera llegado bien esta trama, significaba que podía haber un fallo en el código de envío pero no en el de captura de la señal. De esta forma descartábamos parte del código a la hora de localizar algunos posibles errores. Una vez la trama ya conocida llegó a la LCD, se dejó que la trama calculada llegara directamente a la pantalla y se especificó la señal A a 2Khz y la señal B a 2 Khz. con un desfase de +90º, como podemos observar en la figura 4.11. 46 Diseño de nuevas técnicas de integración de un encoger incremental. Fig. 4.11. Simulación completa con señal de 2KHz De esta manera si llegaba un número erróneo o el valor de la dirección no era el correcto, ya sabíamos de antemano que el circuito virtual de pruebas no era la causa del posible error ya que la trama ya conocida había llegado correctamente. Esta señal también llegó bien, así que empezamos ha realizar ya pruebas de campo con datos en la frecuencia de A y B más cercanos a los que nos encontraríamos en una implementación real. Aunque la rueda de pruebas a la que está el odómetro conectado tiene un radio de 8cm., ya sabíamos que la implementación se haría sobre una rueda más grande y se realizaron pruebas con un radio de 25cm. En realidad se generaron muchas más simulaciones de las que mostramos en esta memoria pero creemos que las más interesantes son las que les mostramos a continuación. 4. Simulación e Implementación del código 47 Fig. 4.12 Simulación completa a 30Km/h, radio rueda 25cm, sentido anverso Fig. 4.13 Simulación completa a 30Km/h, radio rueda 25cm, sentido directo Además de aumentar el radio de la rueda, se hicieron pruebas a mayor y menor velocidad, y cambiando el sentido de la marcha. En las figuras 4.12 y 4.13 podemos observar que se realizaron las pruebas con un radio de 25cm y una velocidad media de 30Km/h, de esta manera simulábamos la velocidad y las ruedas de un coche convencional en una carretera urbana. 48 Diseño de nuevas técnicas de integración de un encoger incremental. Como se puede comprobar fácilmente en las imágenes, la única diferencia que nos dio esta simulación, era el bit que nos indicaba la dirección de la marcha. 5. Conclusiones y mejoras futuras 49 5. CONCLUSIONES Y MEJORAS FUTURAS A continuación se deja constancia de las conclusiones adquiridas tras la elaboración de este proyecto y se indican posibles líneas de trabajo futuro partiendo de la base de este proyecto. El diseño de un circuito de adaptación de las señales de un odómetro no es una tarea tan sencilla como a priori, a la vista de los diseños existentes, puede parecer. Debe realizarse un estudio lo mas exhaustivo posible porque cualquier cosa no considerada previamente puede derivar en problemas de difícil solución con el sistema adquirido. Una vez estudiados varios sistemas para implementar el diseño, se llegó a la conclusión que las FPGA’s aparte de su mayor flexibilidad en el momento de realizar un diseño por las opciones que ofrece, es mucho más fácil su programación y la adaptación de alguien que no conozca el lenguaje VHDL. Pero su disponibilidad para la realización del proyecto y su mayor coste, llevaron a renunciar a este sistema y a optar por los microcontroladores PIC. La dificultad de realizar el proyecto con PIC’s, y que había llevado a una primera exclusión de este sistema, era que había falta de familiarización con los lenguajes específicos, y con la programación de estos dispositivos. Una vez aprendidos el lenguaje y los diferentes programas, las principales dificultades radicaron en la variabilidad de la frecuencia de las señales, ya que tal y como está implementado y después de las simulaciones, se han detectado diferentes problemas que se habrán de solucionar en la siguiente evolución del proyecto global. Principalmente, la frecuencia de adquisición del PIC se ha mostrado muy justa para la detección de las señales, y se sabe insuficiente para implementar los dos odómetros y para aumentar su resolución. Para paliar estos problemas se sugiere cambiar el microcontrolador por un PIC18FXXX o similar, ya que permite la adaptación del código existente con pocas variaciones y permite elevar la frecuencia de adquisición. Hay que tener en cuenta que el programador y los lenguajes son 100% compatibles con estos otros. Estos PIC18FXXX son mas veloces y con el PLL activado pueden ejecutar sentencias hasta los 40Mhz (10 Mips) todos los modelos e incluso hay algunos que alcanzan los 48Mhz (12 Mips).Esto permitirá estar mas holgados con el diseño en el tema de los tiempos. La Utilización de lenguajes de alto nivel, permite lograr una mayor abstracción respecto al hardware utilizado, es decir, del tipo de microcontrolador. La estructura del diseño implementada nos permite agrupar todas las funciones dependientes del microcontrolador. Con esto, conseguimos que el cambio de microcontrolador solo afecte a algunas sentencias.