Coche teledirigido. Autores: David López Luengo Nauzet Melián Batista Jose Luis Santana Acosta Aythami Santana Monzón

Transcripción

1 Coche teledirigido Autores: David López Luengo Nauzet Melián Batista Jose Luis Santana Acosta Aythami Santana Monzón Año académico: 2005/2006

2 Introducción La práctica que a continuación se presenta y expone, pretende describir todo el proceso y características técnicas que conllevó hacer un coche teledirigido. Nos referimos a él con comillas ya que cuando está montado, más que coche teledirigido parece un cacharro con ruedas, pero no se trataba de hacer algo con carrocería, marchas, luces, ceniceros y demás, sino de trabajar las entrañas del aparato. La práctica se puede dividir en dos grandes bloques bien diferenciados, de hecho la forma de trabajar del grupo fue así, con dos equipos que investigaban y desarrollaban independientemente. Los bloques de trabajo son: Diseño del artefacto móvil: que cubre todo lo que es el movimiento del coche. La transmisión de información: que debe haber desde el mando hasta el coche, para saber cómo moverse. Para una mayor facilidad de lectura (y sobre todo de escritura por parte de los autores), esta memoria también estará dividida en los mismos bloques casi totalmente independientes entre si.

3 Diseño del artefacto móvil El diseño del artefacto móvil (coche en adelante) se ha basado más en principios físicos y diseño hardware que en diseño software. El circuito tiene una serie de entradas, según las cuales los motores giran (o no) en un sentido u otro. Hemos delegado la función de interpretación de las entradas a la placa receptora, de forma que el circuito principal del coche sólo tiene que preocuparse de responder ante las entradas pertinentes. El diseño hardware se ha dividido en 5 áreas principales: El selector. Podríamos decir que este es el corazón del diseño. El selector estaba en principio formado por un L293B, cuyo funcionamiento se detalla a continuación: El L293B está dividido longitudinalmente en dos partes. Cada una de estas partes tiene una señal de entrada ENABLE, dos señales de entrada IN1 e IN2 y dos señales de salida OUT1 y OUT2. OUT1 estará activada si IN1 está activada, pero además ENABLE debe estar activada. Lo mismo pasa con OUT2, y con OUT3 y OUT4 en la otra mitad. En términos más generales, podemos decir que OUTx = (INx and ENABLEy). Evidentemente, en la expresión anterior y vale 1 para x entre 1 y 2, mientras que y vale 2 para valores de x 3 y 4. Dado que cada motor necesita dos señales para ser controlado, hemos decidido que (ENABLE1 & IN1 & IN2), y por lo tanto (OUT1 & OUT2) controlen un motor, y (ENABLE2 & IN3 & IN4), y por lo tanto (OUT3 & OUT4) controlen el otro motor. Como veremos en el siguiente punto, los motores pueden aceptar a través de sus dos líneas de entrada cualquier combinación excepto 11. Esto nos ahorra una entrada por cada lado del selector, ya que simplemente podemos hacer que una entrada sea la negada de la otra. De esta forma nunca se podrá dar la combinación 11, y la 00 la podemos conseguir desactivando el ENABLE de ese lado. Es por ello que al selector le añadimos un DM El DM 7405 es un negador que tiene una serie de parejas ENTRADA SALIDA. Como cabe esperar, SALIDAx = NOT(ENTRADAx). Al conectar la entrada IN1 del selector a una entrada del negador, obtenemos en la salida pertinente del negador lo que será la entrada IN2 del selector. Lo mismo pasa con IN3 e IN4.

4 Los motores. Los motores dotan al coche de movilidad. Usaremos dos motores con los que controlaremos el avance (o retroceso) y el giro del coche (tracción y dirección trasera). Como ya hemos dicho en el punto anterior, cada motor va conectado (aunque no directamente, como veremos en el siguiente punto) a un lateral del selector. Cada motor tiene dos entradas, que corresponderán con las salidas del selector OUT1 y OUT2 (OUT3 y OUT4 para el segundo motor). La tabla de verdad de los motores es la siguiente. Entrada Entrada Acción del Motor Reposo Giro en un sentido Giro en el sentido opuesto ERROR!!! En el manejo de los motores se han de tener en cuenta dos aspectos muy importantes. El primero es que nunca se les debe proporcionar la combinación de entrada 11. Este aspecto ya está controlado con el negador del apartado anterior. El segundo aspecto a controlar es que debemos proteger el motor durante los cambios en el sentido de giro. Cuando se cambia el sentido de giro, se necesita invertir la polaridad de cada una de las bobinas, y para que este proceso no dañe al motor se ha de proteger adecuadamente (como veremos en el siguiente punto). Los puentes. Como hemos comentado en el punto anterior, necesitamos proteger a los motores frente a los cambios en el sentido de giro de los mismos. Ésto se consigue conectando un puente en H a las entradas del motor, o lo que es lo mismo, interponiendo un puente en H entre cada motor y el lado del selector al que está conectado. De esta forma, la conexión real entre un lado del selector y el motor que controla sería SELECTOR PUENTE EN H MOTOR. En cuanto a la construcción de los puentes en H, cada uno se realiza con 4 diodos configurados como muestra el siguiente esquema:

5 Montaje del esquema anterior El divisor de tensión. Una de las necesidades de un dispositivo móvil es la libertad de movimiento, y ésta no es posible si dicho dispositivo ha de estar conectado mediante cables a un lugar fijo. Es por ello que necesitamos usar una batería, no podemos depender de una fuente de alimentación fija. Dado que el circuito necesita ser alimentado en unas ocasiones por 5V, y en otras por

6 6V, se hace necesario el uso de un divisor de tensión para conseguir estos valores. Hemos construido el divisor de tensión como una conexión serie de resistencias en paralelo con algunos diodos Zener (para proteger el circuito de los picos de tensión). La tensión a la que están sometidos los motores depende de cuántos motores están en movimiento (cuantos más motores estén en movimiento, menor será la tensión a la que estarán sometidos). Los motores necesitan un mínimo de tensión para presentar movimiento. Es por ello que necesitamos suministrar al circuito la tensión suficiente para que todos los motores puedan moverse simultáneamente. El problema se presenta cuando no se mueven todos los motores: la tensión a extremos de los que se mueven es extremadamente alta. Es un problema de diseño de muy fácil resolución cuando entran en juego los Zener. Con la implementación del divisor de tensión, hemos tenido el problema de que las resistencias que necesitamos son muy bajas, sobre 20 Ω, y esto ocasiona que las resistencias se deterioren, debido a que el voltaje a suministrar es muy elevado, para la cantidad de potencia que pueden disipar estas resistencias. Por lo tanto, no hemos implementado el divisor de tensión. Es un tema que se quedó en el tintero. Otra forma de suministrar los voltajes necesarios podría ser mediante asociación en serie de pilas de 1,5 V de formato AA o AAA. No se ha implementado esta forma de suministrar el voltaje, debido a la cantidad de pilas que se necesitan. El PIC. Es el punto de enlace entre el coche y la placa receptora. Su función es doble: por un lado, gobierna sobre la placa receptora, interpretando sus señales y realizando la comunicación con la placa emisora; por otra parte, genera las señales que necesita el selector para controlar los motores (cerrando así el círculo). La forma de conectar nuestro circuito selector puente motor al PIC es conectar las entradas de la siguiente forma: ENABLE1 a RA3, INT1 a RA2, ENABLE2 a RA1 e INT2 a RA0. Sobre el programa del PIC que controla la placa receptora, nuestra única labor fue traducir los comandos de 3 bits que recibe la placa a los 4 bits de entrada que requiere el selector. El código es el siguiente.

7 List p=16f84 include "p16f84.inc" Dec Uni Aux tmp t1 t2 bin equ equ equ equ equ equ equ 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 org 0x00 goto Inicio org 0x05 RIA bsf PORTB, 3 bsf PORTB, 2 return RDA bsf PORTB, 1 bsf PORTB, 0 return RIAt bsf PORTB, 3 bcf PORTB, 2 return RDAt bsf PORTB, 1 bcf PORTB, 0 return Read movf PORTA,0 movwf bin movwf tmp movlw 0x07 andwf tmp,1 btfsc STATUS,Z

8 goto Apaga btfsc bin,2 goto Atras btfsc bin,1 call RIA btfsc bin,0 call RDA return Atras clrf PORTB btfss bin,1 call RIAt btfss bin,0 call RDAt return Apaga clrf PORTB return Inicio bsf STATUS,RP0 clrf TRISA clrf TRISB comf TRISA,1 bcf STATUS,RP0 call Read goto Start Start Stop nop nop end

9 La transmisión de información Este bloque describe cómo se realizó todo lo referente a lo que sería el mando de un coche teledirigido y el receptor que debe haber. Para ello se trabajó con dos placas RF (radiofrecuencia). Los temas de los que hablaremos serán: Descripción de las placas RF. Montaje de las placas RF. Uso de las placas RF. Diseño del protocolo. Implementación del protocolo. Descripción de las placas RF Las placas usadas para la transmisión son dos XE1201A, estas placas tienen 2 modos de trabajo: ó transmisión ó recepción. No se puede trabajar con los dos modos a la vez, lo que sí se puede es diseñar un programa que conmute a las placas de forma que se dé la impresión de que la comunicación es en ambos sentidos, pero en un momento dado tenemos la certeza de que la comunicación es en una dirección en concreto. El chip de la placa tiene 32 pines, sin embargo a nosotros como usuarios no nos interesa cómo está diseñada por dentro sino solamente cómo usarla para nuestro fin, debido a ésto pasamos a centrarnos solo en 11 pines, como nota diremos que si se está interesado en el funcionamiento interno de las placas (método de transmisión, modulación de la señal, filtrado de la señal, etc...), toda esa información está compilada en los manuales de referencia de las placas que acompañan a esta memoria.

10 Apariencia de una placa XE1201A En la imagen superior podemos apreciar redondeados en rojo los 11 pines que es importante conocer para el uso de las placas. El lector podrá decir percibir que en total son 15 pines los que hay señalados, esto es debido a que ciertos de ellos son muy usados y es más cómodo tenerlos separados del resto, estos pines son el Vcc, Vss, TXD, RXD y CLKD. Los dos superiores son los pines de alimentación de la placa, Vcc corresponde al polo positivo (cables de color rojo normalmente) y Vss al polo negativo o tierra (cables comúnmente negros). En la parte de abajo a la derecha vemos los pines TXD, RXD y CLKD. TXD es el pin por el que se transmiten datos hacia la otra placa. RXD es el opuesto a TXD, es el pin por el que se reciben los datos. CLKD es el reloj de la placa, no tiene efecto en el transmisor, donde realmente se le puede dar uso es en el receptor. De estos 3 pines se hablará más profundamente más adelante, ya que es muy importante conocer a fondo su funcionamiento y limitaciones, para poder desarrollar programas que funcionen correctamente. Los otros 5 pines restantes son: SD: Encargada de enviarle los datos de configuración a la placa. SC: El reloj que controla la transmisión de los datos de configuración. DE: Esta es la línea encargada de indicar el comienzo y fin de la transacción de los datos de configuración. EN: Indica si la placa está encendida o apagada. RXTX: Es el pin encargado de poner a la placa en modo receptor ó transmisor.

11 A continuación podemos ver la situación de cada uno de los pines anteriormente citados en la placa, redondeados de rojo están los que se repiten dentro y fuera. Disposición de los pines en la placa. Información relevante sobre cada uno de los pines A continuación hablaremos más detalladamente sobre los 11 pines, indicando que valores deben tomar o tomaron en nuestra práctica y el por qué. Vdd: Poco que decir, es el polo positivo o cable rojo, si se revisa la información del datasheet de las placas observaremos que su valor debe oscilar entre 2,4 y 5,5 V, teniendo como valor normal de trabajo 3,5 V. En nuestra práctica decidimos usar 3,9 V ya que, si usamos menos, el circuito muchas veces se empieza a comportar de forma extraña. Llegamos a concluir que esto podía ser debido a que se derivara potencia a otra parte de la circuitería, ésto se vio corroborado cuando vimos que si conectábamos la placa al micropic trainer y ambos estaban enchufados no funcionaba nada, sin embargo si apagábamos la micropic trainer la placa empezaba a funcionar. Vss: Es la toma de tierra de la placa, comentamos antes que entre Vdd y ésta mantenemos una diferencia de 3,9 V. RXD: El pin por el que se reciben los datos, la velocidad con la que es leído un bit y puesto en este pin viene dada por la velocidad que se le haya determinado a CLKD durante la configuración. TXD: El pin por donde se envían los datos, hay que tener en cuenta que la

12 placa trabaja a una velocidad determinada y por lo tanto aunque nosotros cambiemos los bits muy rápidamente en esta pata, la placa sólo los va a leer a una velocidad constante lo que nos producirá pérdida de información, es por ello que el programa que desarrollemos se tendrá que adaptar a estos tiempos muertos entre bit y bit, la velocidad de lectura viene dada por la función * 2( n/8) donde n es un entero sin signo que viene definido por ciertos bits de la configuración. Ahora no nos centraremos en eso, tan sólo diremos que cuanto más pequeño es n mayor es la velocidad de trabajo, si n = 0 la velocidad de trabajo es Hz (65,573 Khz). CLKD: Este es el reloj que controla la velocidad de lectura de bits en la placa receptora, además también sirve para que la placa pueda pasarle un filtro a la señal obteniendo más claramente el bit. A pesar de todo ello se puede trabajar sin esta señal. En nuestro caso es más que recomendable usarla ya que, como bien señaló un día el profesor, la única manera que tenemos de saber si hemos configurado una placa con nuestro programa es comprobar que el reloj está en funcionamiento, extremadamente útil. SD: Por esta línea se le pasan los valores de los 3 registros de configuración a la placa, no llegamos a descubrir si hay una velocidad límite para pasar los datos por aquí a diferencia de por TXD, pero al parecer el PIC no trabaja lo bastante rápido como para hacer que se pierdan bits, puesto que no nos hizo falta poner un retardo después del envío de un bit, aunque lo que si hicimos por precaución fue enviarlos todos con el mismo intervalo de tiempo entre ellos. SC: El reloj que controla a que velocidad transcurre la información por SD, al igual que el anterior, no llegamos a notar que hiciera falta un límite de velocidad aunque también lo hacemos conmutar de alto a bajo y viceversa a una velocidad constante. DE: La función de este pin es indicar el comienzo de una transacción de configuración. El valor del mismo esta siempre alto (1) y cuando se quiere transmitir por SD se conmuta a bajo (0). Se debe mantener este valor durante toda la transmisión para saber cuando finaliza ésta. ES IMPORTANTE NO CONFUNDIRLO CON SD, la mayor diferencia entre ambos es que, por lo general, SD cambiará bastantes veces en una transacción, mientras que DE no cambia, está a 0 siempre. A continuación vemos una figura de como se lleva a cabo una configuración:

13 Transacción de configuración de una placa Puede apreciarse como DE es la que define cuales de los bits de SD son parte de la configuración y como SC es la que define la velocidad a la que estos bits son leídos por la placa. Resaltado con círculos rojos está el hecho de que hay que dejar unos margenes de tiempo entre el cambio de señales para que las lecturas de las mismas sean estables, pero como ya resaltamos antes, con la velocidad a la que trabajamos no notamos problemas. EN: En la mayoría de dispositivos para la computación a este bit se le suele también llamar CE (Chip Enable), en el caso de estas placas se llama solo EN (ENable) y es el encargado de decir si una placa está encendida o apagada. Mucho cuidado, una placa puede estar siendo alimentada y a su vez estar apagada, esto hará que no transmita o reciba nada pero puede ser configurada y mantendrá la configuración siempre y cuando no se le corte la corriente, podríamos encender una placa, configurarla, luego apagarla, posteriormente configurarla de nuevo y encenderla y obtendríamos una placa configurada como la última vez. RXTX: Este pin controla el modo en el que se encuentra la placa, o bien receptora o bien transmisora, si está a nivel bajo (0) la placa será transmisora y si está a nivel alto (1) estará en modo receptora. Como se observa debido a esto la comunicación solo puede ser como mucho half duplex (información puede viajar en ambos sentidos, pero sólo en uno en un momento dado). GND: Es el pin de tierra (ground), este debe estar conectado a la misma tierra que el controlador de la placa (en nuestro caso el PIC) para que puedan tener una referencia común. NOTA: El funcionamiento de los pines EN y RXTX se ve condicionado a cómo configuremos las placas, ya que como veremos más adelante, en uno de los registros de configuración se puede decidir si hacer caso a estos dos pines o hacer caso a otros dos bits de configuración.

14 Configuración de las placas Una vez conocidos los pines relevantes para el usuario pasemos al tema sobre el uso de las placas. A continuación expondremos cómo se las configura y qué posibilidades se ofrece. Para configurar una placa se le debe enviar la información a través del bus 3 cables (3 wire bus), el cuál está formado por SD, SC y DE. La representación de la información se hace en forma de 3 registros de 14 bits cada uno, conocidos como registros A, B y C. Sin embargo por el bus 3 cables no se envían 14 bits sino 16 para poder direccionar que registro se está configurando y para conseguir que una palabra de configuración sean 2 bytes justos. Así bien, sabemos que para configurar un placa debemos en primer lugar desactivar la señal DE y luego enviar dos bytes de información por SD mientras vamos conmutando a una velocidad constante la señal SC, ahora nos falta saber cómo es representada la información que se envía, fácil respuesta, los primeros bits que se envían son los más significativos del registro, salvando los dos primeros que son los que indican el registro que se está configurando según la siguiente tabla: Representación de los 2 primeros bits de configuración Para ilustrar mejor ésto, expondremos nuestro propio caso como ejemplo. Nosotros debemos transmitirle a la placa la palabra 0x1c10, si pasamos este número a binario se nos queda: Como vemos los dos primeros bits están a 0 lo que quiere decir que configuramos el registro A. La transmisión de estos bits se iría haciendo de izquierda a derecha, 3 ceros seguidos (los dos de direccionamiento y uno de datos), luego 3 unos, etc... Bien, ya sabemos lo que significan los dos primeros bits de una palabra de

15 configuración, pasemos ahora al significado de los 14 bits restantes, éstos dependen del registro que estemos configurando. A nuestro parecer (y en el caso de nuestra práctica), como usuarios solo vamos a configurar el registro A, el B y el C los dejaremos a cómo vienen por defecto, ya que no interfieren en nuestro trabajo. El formato del registro A es el siguiente: Formato del registro A Como vemos consta de 6 campos, de estos 6 nos centraremos solo en 5 de ellos y haremos especial énfasis en el funcionamiento del primero de ellos Control mode ya que es, a nuestro parecer, el campo que más quebraderos de cabeza puede dar a quienes vayan a usar las placas RF, por ello queremos dejarlo lo mejor documentado posible: A13 Control mode: Este campo de un único bit, se podría decir que lo que pretende es configurar a la placa para ser usada por otro ente externo (ya sea persona o dispositivo) o por ella misma. Explicamos, si el bit está a 0 entonces los siguientes bits A11 y A10 no tendrán relevancia alguna, para saber si la placa está encendida o apagada se chequeará el pin EN y para saber si es emisora o receptora se chequeará el pin RXTX. Todo lo contrario ocurre si ése bit está a 1, entonces el valor de los pines EN y RXTX será irrelevante y dará igual los cambios que en ellos haya, la placa sólo hará caso al valor de los bits A11 y A10. Es importante comprender el funcionamiento de este bit ya que puede llevar a muchos errores, en definitiva podríamos decir que es una especie de interruptor entre bits A11 y A10, y pines EN y RXTX. A12 Control clock: Este bit indica si el reloj de la placa está siempre activo o en caso contrario si solo está activo según lo esté la placa o no. Si el bit está a 1 significa que el reloj siempre estará funcionando (obviamente si la placa tiene alimentación), independientemente de si el bit A11 ó el pin EN están altos o bajos. En caso contrario (A12 = 0), el reloj solo funciona si la placa está encendida, es decir si el bit A11 está activo ó el pin EN. Mucho cuidado, el bit A13 (control mode) afecta indirectamente aquí, ya que si éste está a 1 (es decir, se hace caso de bits A11 y A10 y no a las patas EN y RXTX), el pin EN no afectará al funcionamiento del reloj y viceversa en caso de que A13 esté a 0.

16 A11 Chip enable: El equivalente al pin EN, si está a 0 indica que la placa está apagada, si está a 1 indica que la placa está encendida. Sólo tiene validez cuando el bit A13 está a 1. A10 RXTX: El nombre lo dice todo, el equivalente al pin RXTX, si se encuentra a 0 la placa está en modo transmisor, si está a 1 la placa está en modo receptor. Sólo tiene validez cuando el bit A13 está a 1. A5 A0: Estos bits son sólo relevantes en una placa receptora, indican la frecuencia de muestreo del pin RXD, dicho de otra forma, la velocidad a la que lee el receptor. Puede tomar valores entre 0 y 63. La fórmula que define la frecuencia de muestreo es la siguiente: DR = * 2 ( n/8) El valor resultado es una cantidad de hertzios (Hz). N es el valor de este campo, debido a ésto, las frecuencias en las que puede trabajar la placa es entre aproximadamente los 280 Hz y los 65,573 Khz. Obsérvese que cuanto más pequeño es el valor en este campo mayor es la frecuencia de muestreo. Al principio comentamos que estos bits sólo son relevantes en un receptor, en el emisor existe en el registro B un campo para controlar la velocidad de envío. En nuestro caso no lo comentaremos ya que no lo hemos usado, pero queremos al menos dejar nombrado que existe la opción. Los valores por defecto de los 3 registros nada más dar alimentación a las placas son los que siguen: Valores por defecto para los registros de configuración En nuestro caso B y C quedarán como muestra la figura pero A lo cambiamos, más adelante hablaremos de ello.

17 Comprobación del funcionamiento de las placas y técnicas de depuración del diseño de nuestro propio driver. Una parte que se nos atragantó mucho en la práctica fue el hecho de comprobar que los programas diseñados para un receptor y para un emisor funcionaban correctamente independientemente entre ellos. Para poder depurar encontramos de gran utilidad el programa de prueba que se entrega junto con las placas, pero que, a nuestro parecer, está pobremente documentado y de forma muy liosa, es por ello que hemos decidido crear este apartado, para que si en un futuro alguien vuelve a trabajar con las placas tenga un sitio donde consultar medianamente el manejo del programa. Este apartado no pretende ser una guía con todo lujo de detalles de cómo funciona el programa, sino solamente indicar unos cuantos pasos básicos que le puedan asegurar al alumno si lo que hace debería o no funcionar, ya que un gran problema que se presenta en el desarrollo de este tipo de prácticas es la incertidumbre sobre lo que uno mismo desarrolla. Empecemos ya ha hablar sobre el programa, a primera vista uno piensa que es bastante inútil, ya que no entiende nada y no sabe a donde dirigirse ni que tocar. La primera idea es la de montar las placas RF con su placa auxiliar llamada PC XE1201 Inteface board V2.0. La forma de montar el circuito es bastante intuitiva, a pesar de todo en la siguiente foto se muestra. Montaje del circuito de prueba de una placa RF

18 Como se observa en la figura, la alimentación para ambas piezas es más o menos la misma, las que usamos nosotros oscilaban entre los 3,5 y 3,9 que es el valor medio que se especifica en el datasheet. Ahora veamos que partes del programa nos interesan. Nada más entrar en él se nos dará la bienvenida anunciando a Xemics, le damos a ok y entonces aparecemos en una pantalla con 5 menús distintos, a nosotros sólo nos interesa el que se llama Features program, es con este menú con el que configuramos las placas y probamos su funcionamiento. A continuación se muestran las pantallas que hemos seguido. Pantalla de bienvenida y los 5 menús Pantalla de configuración

19 Aunque la imagen está borrosa, cuando usemos el programa se verá claramente el nombre de cada botón y, si hemos leído y comprendido está memoria hasta ahora, no habrá problemas para entender que es cada opción ya que tienen los nombres de los bits a configurar. A la hora de configurar la placa aconsejamos primero guardar la configuración con el botón save y luego transmitir la trama con el botón grande del medio que pone transmit frame. Una vez hecho ésto la única forma que tenemos de comprobar que realmente la placa esta configurada es mirando el reloj (deberíamos haber activado el bit A12). Para mirarlo usamos el osciloscopio, al final de la memoria hay un anexo con una aproximación de cómo se usa, ya que consideramos que esta herramienta ha sido la más importante de la práctica, sin poder mirar las señales con ella dudamos mucho que la hubiéramos terminado a tiempo, no exageramos cuando decimos que ES EL GDB DE LA ELECTRÓNICA. No pudimos encontrar ningún manual del mismo así que diremos cómo lo usábamos nosotros y qué nos imaginábamos que hacía cada botón o palanca. Aconsejamos a cualquier persona que quiera usar las placas que primero pruebe a hacerlas funcionar a ambas con el programa, entienda el funcionamiento y consiga transmitir para luego diseñar e implementar su propio programa. Para depurar el driver de una placa aconsejamos que se ponga una placa configurada con el programa de XEMICS sabiendo que funciona y la otra configurada con nuestro programa, así si hay fallos (y lo más probable es que los haya) tendrán más localizado el problema. Todos los consejos que vamos dando son fruto de la experiencia de usar nosotros mismos las placas. Llegados a este punto hemos terminado de explicar cómo funcionan las placas y cómo se configuran, también hemos explicado cómo podemos comprobar si un programa hecho por nosotros está bien o no y cómo comprobar que una placa funciona, también hemos hablado de cómo conectar las placas con el programa de prueba y cómo usarlo. Es ahora cuándo ya podemos dejar de lado las placas (sólo por un momento) y hablar del verdadero trabajo de la práctica, que es el diseño del protocolo de comunicación y las peculiaridades que surgen alrededor de él.

20 Diseño del protocolo de comunicación y de los programas que se comunicarán con él. La comunicación entre las placas se hace por medio de una única línea así que de entrada sabemos que el protocolo debe ser serie. La idea que cogimos la obtuvimos pensando un poco en el protocolo RS 232 y su forma de transmitir, mantener la línea a un nivel y para iniciar comunicación enviar un start bit seguido de los datos y uno o dos stop bits para finalizar. También subimos un poco el nivel de abstracción y pensamos en una comunicación no orientada a conexión parecida a la que hace el protocolo UDP, no establece conexión, sino que envía el paquete y si llega bien y si no también. El motivo de esta última elección ha sido el hecho de que lo que se pretende enviar es información a un coche teledirigido, el cuál debe tener una respuesta coherente a ojos de los humanos, cuyo tiempo de respuesta es mucho menor al de una máquina, por lo tanto podemos permitirnos el lujo de que se pierdan un montón de paquetes ya que la velocidad de envío es muy elevada. Además esta filosofía resta dificultad a la implementación. Un problema con el que nos topamos nada más hacer funcionar las placas es que si la placa receptora está funcionando y la emisora no lo está, se está continuamente recibiendo ruido, hay que tener en cuenta que estas placas trabajan en el espectro de frecuencia de la banda ISM (Industrial Scientific Medic) la cuál no requiere licencia pero que usan muchísimas cosas, desde el mando de las puertas de los garajes, hasta los microondas, pasando por los terminales que usen WIFI, así que si no tuviéramos este detalle en cuenta podría pasar que si tenemos el receptor encendido considerablemente cerca de alguno de estos aparatos, pudiera ser que el coche empiece ha moverse sin aparente sentido. Estas transmisiones que no nos interesa captar es lo que llamamos ruido y hay que evitar que el receptor que diseñemos responda a ésto. Todo protocolo de acceso al medio de los que leamos (aconsejamos libros de redes de computadores de Andrew S. Tanenbaum y el de Stallings y Myiers) tienen una forma de reconocer si la información que se lee es relevante, por ejemplo en Ethernet para enviar una trama, ésta tiene que tener cómo comienzo de cabecera 7 bytes los cuales alternen entre 1 y 0. Si nos paramos un momento con el osciloscopio a mirar como es el ruido, veremos que alterna mucho. En nuestro protocolo para que el receptor sepa que hay un emisor funcionando lo que hacemos es tener primero que sincronizarnos, para ello intentamos leer 60 ceros seguidos, si lo conseguimos consideraremos que existe un emisor y por lo tanto nos quedaremos a la espera de detectar el start bit y los datos. Esto lo decidimos así debido a que en un momento dado la probabilidad de recibir un bit a 0 es de 1/2, si continuamos contando, la probabilidad de recibir 2 bits seguidos a 0 es 1/4, la de recibir 3 bits es 1/8... así sucesivamente la de recibir n bits a 0 será de 1/2n, decidimos usar 60 ceros debido a que consideramos que una probabilidad de 1/260, es lo bastante

21 amplia como para presuponer que con ruido no la recibiremos, no obstante, no se deje engañar al lector de que esa es la probabilidad definitiva, esa es la probabilidad de recibir una ristra de 60 ceros con sólo 60 lecturas, pero el receptor hace millones de lecturas, dependiendo de la velocidad que configuremos, en nuestro caso decidimos trabajar a la máxima velocidad (65,573 Khz). Esto quiere decir que en un segundo la placa lee bits cada segundo, por lo tanto la probabilidad durante un segundo de que leamos 60 ceros es de (65573/60)/ 260 = 65573/(60 * 260). Si probamos a dividir esto con una calculadora comprobaremos que el resultado es tan abrumadoramente pequeño que el aparato devuelve 0 redondo. Si nos fijamos un poco en la fórmula, para considerar que la probabilidad de que recibamos 60 ceros a base de ruido, nos damos cuenta de que necesitamos que el dividendo del cociente llegue a un orden de aproximadamente 260, esto quiere decir que cuando hayamos estado más o menos esa cantidad de segundos seguidos con la placa receptora encendida deberíamos en algún momento habernos sincronizado erróneamente, esto nos deja del orden de los miles de millones de años de espera... Consideraremos que esta cantidad es un buen margen : ) cómo para considerar que no recibiremos muchas tramas erróneas seguidas. Ahora explicaremos como detecta un receptor sincronizado con un emisor cuando este le envía datos. Entre ambos van a mantener todo el rato la señal de datos a un nivel bajo (enviando ceros). En el momento de que el transmisor tenga información que transmitir lo que hacemos es indicarle al receptor que va a recibir algo de importancia. Para ello enviamos un start bit, ponemos a 1 la línea de datos. Ahora debemos plantearnos otro problema, las placas de radiofrecuencia trabajan a mucha menos velocidad que los PIC's, antes comprobamos que la velocidad de recepción era como mucho 65,573 Khz. Si calculamos la relación de instrucciones ejecutadas por un PIC entre lectura y lectura de la placa de la línea RXD vemos lo siguiente: Si empezamos a hacer cálculos de las velocidades relativas entre PIC y placa nos damos cuenta de que el PIC puede ejecutar 15,25 instrucciones por cada lectura de la placa, redondeando tenemos que tienen una relación de 15 a 1. Esto se obtiene de la siguiente forma. La velocidad exterior del reloj del PIC con el que trabajamos es 4 Mhz, Sin embargo la ejecución de una instrucción se realiza en 4 ciclos, esto nos deja una velocidad efectiva de cara a contar instrucciones de 1 MHz, para hallar la relación dividimos: 1 Mhz/65,573 Khz = 15,25 Sin embargo hay que tener otro detalle en cuenta, el PIC no ejecuta una instrucción completa y luego empieza con otra, sino que tiene un pipeline de 2, la búsqueda de la instrucción (instruction fetch) y la ejecución (instruction exec). Esto

22 nos deja con que por cada 2 períodos de reloj del PIC se ejecuta una instrucción, pero de los 4 ciclos que tardará la siguiente se han solapado ya 2. En definitiva, podemos considerar que la velocidad de ejecución efectiva del PIC es de 2 Mhz, por lo que se nos queda que entre lectura y lectura de la placa, el PIC ejecuta 30 instrucciones. Así pues a la hora de implementar el lector tenemos que asegurarnos que el PIC lee la información de RXD cada 31 instrucciones. Ya atenderemos más adelante cómo conseguimos esto. Podemos decir que el protocolo de comunicación consiste en dos partes bien diferenciadas, la primera: la sincronización de ambas partes mediante el envío continuo de al menos 60 ceros. La segunda: el envío de la información mediante un start bit y los datos. Tratemos ahora la segunda parte, el envío de la información. Tenemos que decidir crear una trama y ver como es el envío, si hace falta fragmentar el paquete, cuantos bits tiene cada uno, la representación de los mismos, etc... Al tratarse de un objetivo simple, mover un coche, se facilita mucho esta tarea. Lo primero es ver cuantos movimientos puede tener el coche para saber cuanta información debe ser capaz de interpretar el receptor. En nuestro caso hemos decidido que el coche se pueda mover en 7 direcciones distintas, a saber: Adelante Atrás Izquierda y adelante Izquierda y atrás Derecha y adelante Derecha y atrás Parado Como vemos tenemos 7 casos distintos, para poder codificar esta información necesitamos al menos 3 bits ya que 23 = 8. Así pues, usaremos 3 bits para datos. Ahora debemos definir cuales serán los códigos válidos, en nuestro caso hemos tomado los siguientes: 000 = Parado 001 = Adelante 010 = Atrás 011 = Adelante e izquierda 100 = Adelante y derecha 101 = Atrás e izquierda 110 = Atrás y derecha Como solo necesitamos 7 de los 8 códigos posibles, dejamos fuera el 111, éste

23 podría ser usado en una ampliación de la práctica para usarlo como código de control por ejemplo, pero en nuestro caso simplemente no lo usaremos. Bien, ya tenemos la información. Nos hace falta algo más para enviar?. Como diseñadores del protocolo podríamos crear un diseño complejo con un montón de campos en la trama con información adicional, identificador del mando que envía la trama, identificador del receptor, largo de los datos, crear modos de configuración, hacer que el receptor mande un reconocimiento de la trama, numeración de secuencia y muchísimas más cosas. No obstante para hacer que un coche ande no nos hace falta nada de eso. Como ya dijimos antes, la conexión es no orientada a conexión, es decir, no hay reconocimientos por parte del receptor, esto nos deja un canal de comunicación puramente simplex (la información fluye en una única dirección), del mando al coche. Sin embargo no podemos enviar la información tal cuál la tengamos ya que como siempre vamos a tener la línea a nivel bajo mientras no enviemos nada, cuando empecemos a enviar, si resulta que los primeros bits del código están a 0 el receptor no sabría si el resultado de lo que le llega es 001, 000, 010, etc... Es por ello que tomamos también un poco del RS 232 y sus start bits. Para enviar información primero enviamos un bit que ponga la línea a 1 de forma que el receptor sabe que los siguientes 3 bits que lea son parte de la información. Al ser un paquete muy pequeño no tenemos que preocuparnos mucho de que pierdan sincronismo los extremos, pero analizaremos ese punto más adelante. Con esto tenemos que una comunicación es como sigue: 60 ceros y a partir de ahí la línea continuamente a nivel bajo, en cuanto se lea un 1 tomamos nota de los 3 próximos bits. Lo siguiente a plantearse es qué pasa después de una transmisión exitosa?. Debemos tener en cuenta que el mando puede apagarse en cualquier momento y el receptor no se enterará, entonces empezaremos a recibir ruido. Si no controlamos esta situación, si apagamos el mando después de que se hubiera sincronizado con el coche, éste empezará a leer el ruido y a interpretarlo lo que hará que el coche se mueva sin aparente sentido. Como ya hemos dicho varias veces, implementamos una transmisión no orientada a conexión, por lo tanto el receptor no debe presuponer que una vez sincronizado ya lo está para siempre, debe volver a un estado inicial e intentar resincronizarse de nuevo. Así pues ya podemos construir el flujo del receptor y del emisor. Transmisión que implementamos

24 La forma de comportarse del receptor será como sigue: 1 Configuramos el PIC. 2 Configuramos la placa como receptora. 3 Intentamos sincronizarnos, no saldremos de aquí hasta que lo logremos. 4 Una vez sincronizados nos quedamos a la espera del start bit. 5 Leído el start bit leemos 3 bits y guardamos lo leído. 6 Según el código leído le comunicamos a los motores su movimiento. 7 Volvemos al paso 3. La forma de comportarse del emisor será así: 1 Configurar el PIC. 2 Configurar la placa. 3 Compruebo si el mando está encendido. Si no lo está salto al paso 9. 4 Enciendo la placa. 5 Envío 60 ceros seguidos. 6 Leo el mando para obtener el código a enviar. 7 Envío el código precedido del start bit. 8 Salto al paso 3. 9 Apago la placa. 10 Salto al paso 3. Como observamos ambos componentes de la comunicación realizan su cometido con independencia de si hay ó no otro extremo. El mando intenta sincronizarse enviando 60 ceros y luego envía un dato, pero éste puede perderse si no hay ningún coche encendido y de ésto el mando no se da cuenta en ningún momento. El coche por su parte se atascará en sincroniza mientras no haya un mando que le envíe 60 ceros. Y con esto hemos terminado el diseño del protocolo de comunicación y el comportamiento de ambos extremos.

25 Implementación del protocolo y de los programas que se comunican, el mando y el coche. Llegados a este punto a llegado la hora de picar código, ya tenemos una idea de lo que queremos implementar ahora tenemos que escribir en el ensamblador del PIC los programas, para que se haga más amena esta parte no pondremos todo el código a pelo y luego lo comentaremos, sino que iremos poniendo trozos de código y comentándolos según los pasos que deben seguir los programas como se explicó anteriormente. Como aviso, esto no será un manual de como escribir código para un PIC, se le supondrá al lector unos conocimientos de programación medios, que se cubren perfectamente haciendo las primeras prácticas de la asignatura, ni siquiera necesitamos saber manejar interrupciones pues no las usamos, tampoco nos hace falta saber programar con código reubicable. Empezaremos viendo y explicando el mando ya que fue el primero que fue desarrollado y probado. Programa principal del mando No tiene mucho que explicar, se entiende rápidamente y se puede ver como en él se plasma la idea del flujo. Nada más empezar configuramos el PIC, luego la placa. Terminado esto entramos en un bucle infinito cuyo trabajo es comprobar que la placa esté encendida, nosotros decidimos que fueran los 5 switches de la micropic trainer que están conectados al puerto A del PIC que nos servirán para emular un mando, a saber, tienen este orden desde el menos significativo hasta el más significativo (en la placa van de derecha a izquierda): Enciende ó apaga la placa. Mueve el coche para delante.

26 Mueve el coche para detrás. Mueve el coche a la izquierda. Mueve el coche a la derecha. Evidentemente el coche no se puede mover para atrás y adelante a la vez así que hay unas preferencias, en caso de que tengamos esos dos switches encendidos tendrá preferencia él de ir hacia delante y lo mismo pasa con los de izquierda y derecha, la preferencia la tiene él de ir hacia la izquierda. Si el switch menos significativo no está a uno pues apagamos la placa y volvemos a comprobar, así continuamente hasta que lo enciendan. Una vez a 1 el switch correspondiente, encendemos la placa y la ponemos en modo transmisor, además empezamos a transmitir ceros. Después el flujo es una serie de llamadas a funciones las cuales implementa el funcionamiento del mando. Terminado ésto se vuelve a comprobar si el mando está encendido y repetimos todo el proceso, así infinitamente. Función de configuración del PIC en el mando Aquí ponemos el puerto B, en el cuál se conecta la placa, a los valores de entrada y salida necesarios. Veamos el por qué del valor 0x50. En binario este valor es , esto quiere decir que salvo dos pines del puerto B, el resto son todos de salida. la forma en que se decidió conectar el puerto B a los diferentes pines de la placa fue como sigue:

27 Conexión del puerto B con la placa de radiofrecuencia Los números de Pin interfaz placa siguen el mismo orden que en las figuras cuando explicábamos que hacía cada pin. Para poder conectar los pines a la micropic trainer que a su vez es la que se conectaba al PIC usamos un zócalo y sacamos cables hasta las posiciones que correspondían en la micropic trainer. En las siguientes figuras se puede apreciar el zócalo con los cables y el lugar de conexión. Zócalo para la conexión en la micropic trainer

28 Otra vista del zócalo de conexión Zona de conexión del zócalo en la micropic trainer En las 3 fotos se ha marcado con un punto rojo la dirección de conexión del zócalo, en el manual de la placa micropic trainer pone a que se conecta cada una de las entradas del conector superior al del PIC (el que tiene el punto rojo en la foto), sin embargo lo que no dice es el orden de los números el cuál no es muy lógico, cada uno de los agujeros está numerado de 1 a 28 y el orden es, empezando arriba a la izquierda el 1, el inferior el 2, el inferior el 3... así hasta el final de la primera

29 columna que sería el 14, luego pasamos a la columna de la derecha pero contamos de abajo hacia arriba, es decir que el agujero de abajo derecha sería el 15 y el de arriba derecha el 28. Bien, después de este pequeño paréntesis para explicar cómo conectar la placa a la micropic trainer, sigamos con la explicación del código. Habíamos visto cómo configurábamos cada una de los pines del puerto B, ahora continuemos con el por qué. Pues salvando el RXD (que es la información que lee la placa y le pasa al PIC) y el CLKD (que es para funcionamiento interno de la placa pero que el PIC puede leer), el resto son para que el PIC pueda pasarle información a la placa y controlarla o enviar datos. Programa que configura la placa de radiofrecuencia

30 A primera vista puede parecer lioso pero si se comprende lo que hace la mitad, ya se entiende la otra también. Básicamente lo que hace es transmitirle a la placa los valores del registro A a través de la interfaz del bus 3 cables. Lo primero que se hace es poner una variable CONTADOR a 0, esta variable será la que cuente cuantos bits hemos enviado, también se baja de nivel la línea DE (en el programa se llama E porque DE ya era otra macro) y a partir de ahí se empieza la transferencia. La configuración se hace poniendo en la variable AREG el byte que se transmite, en el primer caso 0x1c. Para transmitir lo primero que se hace es conmutar SC a bajo, luego rotamos AREG de forma que el bit que tenemos en el carry es siempre el que hay que transmitir. Chequeamos a cómo está el carry y ponemos la línea a uno si estaba a uno, después de hacer esto siempre conmutamos el reloj a alto para que la placa lea el dato, en caso de que tuviéramos que enviar un 0 el btfsc se saltaría la instrucción que pone a 1 SD y como justo antes de comprobar la ponemos a 0 se transmite lo que queremos. Al final de esta primera parte siempre incrementamos el contador y comprobamos si el bit que está activo en el es el bit 3 ya que 23 = 8. La segunda parte es lo mismo solo que ahora ponemos en AREG 0x10 y volvemos ha hacer lo mismo. Al final volvemos a poner DE a 1 para indicar el fin de la configuración. Programa que intenta sincronizar al emisor con el receptor Aquí tenemos ya el primer programa que implementa parte del protocolo antes descrito. Como vemos se mueve un 0x3c = 60 a una variable contadora y se pone a bajo la línea de datos TXD. Luego se entra en un bucle de 60 iteraciones. Para diseñar este bucle hemos tenido en cuenta que cada lectura en el receptor se hace cada 30 instrucciones del PIC, para conseguir esto, primero creamos todas las instrucciones útiles del bucle, en nuestro caso decrementar la variable y comprobar si llego a 0, contamos cuanto cuestan: el decremento 1 instrucción, el btfss en general siempre dirá que la variable no llego a 0 (salvo cuando ya tengamos que salir) y por lo tanto su coste será 1, el goto al ser una instrucción que retoca el contador de programa cuesta 2 instrucciones. Así pues, el coste es de 4 instrucciones para que sumen 30 le

31 añadimos el retardo de 26. El mismo razonamiento se sigue en todos los bucles que envíen datos, primero se construye el programa y luego se rellena con retardos. Programa que lee del puerto A el movimiento del coche Largo pero no complicado, lo único que se hace es leer el puerto A de derecha a izquierda buscando que código se debe poner en COD_RES que es la variable que va a contener el dato de 3 bits a enviar al coche. Evidentemente COD_RES tiene 8 bits, solo son importantes los 3 menos significativos.

32 Programa que envía la información contenida en COD_RES

33 La primera parte ya lo dicen los comentarios, se deja en la parte superior de COD_RES los 3 bits de importancia. La forma de transmitirlos será igual que con la configuración de la placa, a través del carry los iremos enviando. Si nos fijamos, justo antes de la etiqueta envia_cod está el envío del start bit, este tiene un menor retardo que el resto de envíos porque queremos hacer que el receptor se desvíe aproximadamente medio intervalo de lectura con respecto al emisor, de forma que aproximadamente el emisor cambie el valor del bit a enviar unos 10 ciclos antes de que el receptor lo lea, para que la línea se mantenga estable y si el receptor por algún motivo de redondeos se adelanta o se atrasa un poco en la lectura haya un margen para que se mantenga dentro del bit que debe leer y no en un cambio, este es el motivo de por qué no tenemos en cuenta que los extremos pierdan el sincronismo, sólo hacemos 4 lecturas, los redondeos no pueden desplazarnos en tan poco tiempo, de todas formas hay que tener en cuenta que si quisiéramos usar protocolo con paquetes de más bits, habría que tener en cuenta la pérdida de sincronismo. El resto de envíos si se hacen cada 30 instrucciones. Aunque es un poco largo no nos debe asustar, ya que la parte interesante del programa solo llega hasta la etiqueta mide_ret, de ahí para abajo no es más que un truco que hicimos para que entre un bit y otro haya 30 instrucciones ya que cuando empezamos a implementarlo nos topamos con un problema, si queríamos enviar un bit 0 después de un bit 0 podíamos dejar 30 instrucciones por medio, lo mismo pasaba si queríamos enviar 1 y habíamos enviado la última vez un 1, pero si ocurría que queríamos enviar un 1 después de un 0 ó un 0 después de un 1 solo podíamos poner 29 o 31 instrucciones de por medio, ésto era debido a que las instrucciones btfsx no tienen un coste fijo, sino que dependiendo de si hacen el salto ó no, cuestan 2 ó 1 instrucciones respectivamente, el por qué de esto es que cuando un btfsx falla en el pipeline del PIC ya entró la siguiente instrucción en su etapa instruction fetch por lo que no hay problemas ya que al fallar no se modifica el contador de programa y es esa la instrucción a ejecutar, sin embargo si el btfsx acierta significa que la siguiente instrucción a ejecutar no es la inmediatamente inferior sino la posterior (2 más abajo), hay que modificar el contador de programa y además hay que retirar la última instrucción en el pipeline (correspondiente a la que se debería ejecutar si btfsx hubiera fallado), todo ello conlleva una pérdida de una instrucción y por ello las instrucciones que modifican el contador de programa valen 2 y no 1. El trozo de código a partir de la etiqueta mide_ret lo único que hace es añadir un retardo coherente según lo que se envió y lo que se pretende enviar, de forma que siempre tengamos un retardo igual a 30 instrucciones. Si nos fijamos bien podríamos decir que hemos hecho un case en ensamblador del PIC. Durante el envío del bit siempre se rota COD_RES para dejar en el bit carry el nuevo bit a enviar y se incrementa la variable contadora para salir cuando hayamos

34 enviado 3 bits. Y con esto ya hemos analizado el mando, ahora pasaremos al análisis del coche o receptor. Programa principal del receptor No hay mucho que comentar, simplemente son unas cuantas llamadas a las funciones que a continuación veremos. Lo primero que se hace es configurar el PIC y luego la placa y a partir de ahí se entra en un bucle infinito en el que intentamos sincronizarnos, luego recibir el dato y luego poner los motores con el funcionamiento adecuado. No comentaremos las funciones de configuración del PIC ni la placa ya que son prácticamente iguales que en el mando y solo cambian ciertos datos, pero lo que es el algoritmo son copias íntegras para ambos programas. Tampoco comentaremos la función de control de los motores ya que se encuentra comentada en la parte de la memoria que se encarga de la descripción de los motores y el trabajo con ellos. Así pues, las funciones que comentaremos son SINCRONIZA y LEE_CODIGO.

35 Función que intenta sincronizarse con un emisor Esta es la función que complementa el apartado del sincronismo entre placas, antes comentamos la que enviaba 60 ceros, ésta es la que los recibe. Como vemos preparamos dos contadores, uno a 0 y otro a 60 (0x3c) y empezamos a leer el pin RXD en busca de ceros, desde el momento en que leamos un 0 los empezamos a contar y volvemos a leer, repetimos esta acción hasta que leemos los 60 ceros o bien hasta que leemos un 1, en tal caso volvemos a empezar desde el principio. Tenemos que resaltar que entre lectura y lectura de ceros dejamos un total de 30 ciclos de PIC como en el emisor debido a las latencias de trabajo de la placa. Queremos resaltar el hecho de que esta función es bloqueante, con ésto queremos decir que el programa se bloquea aquí si no se logra sincronizar.