Resumen del proyecto 4




descargar 419.67 Kb.
títuloResumen del proyecto 4
página7/14
fecha de publicación28.11.2015
tamaño419.67 Kb.
tipoResumen
med.se-todo.com > Derecho > Resumen
1   2   3   4   5   6   7   8   9   10   ...   14

2.5Adaptación de comunicación con microcontroladores a USB

2.5.1Introducción


La arquitectura del proyecto heredado incluía un módulo de nivel intermedio (“Pic_comm”) que conectaba un módulo de alto nivel de los motores (“Motores”) con el microcontrolador PIC, que llevaba a cabo las órdenes. El esquema es el siguiente:



Además, el mismo módulo “Pic_comm” se comunicaba con varios módulos de sensores:



De esta forma, “Pic_comm” realizaba consultas al PIC para obtener información acerca del estado de los sensores, y propagaba esta información a los módulos adecuados mediante los puertos de conexión.

Por lo tanto, el módulo “Pic_comm” utiliza una comunicación bidireccional: por un lado proporciona información al PIC para hacer mover los motores, y por otro obtiene datos del PIC sobre los sensores. Esto se aclara con el siguiente gráfico:



Como vemos, del módulo “Motores” surge una orden que, a través del módulo “Pic_comm”, llega al PIC, el cual procesa las acciones y las envía al motor (en rojo). Por otro lado, el “Pic_comm” pregunta cuando sea necesario el estado a los encoders a través del PIC. Estos datos se propagan hacia el módulo superior “Encoders” (en azul).

El problema surgía en la comunicación entre el “Pic_comm” y el propio PIC. Al comienzo de nuestro trabajo, esta comunicación se realizaba en serie, y no era demasiado fiable. Por ello, uno de los objetivos potenciales sería cambiar esta comunicación a USB, mucho más robusta.

Este posible objetivo se hizo realidad cuando, de forma desconocida, el PIC dejó de funcionar, y como consecuencia el robot dejó de andar. Este problema ajeno a nosotros hizo que nos pusiéramos a trabajar junto a otras personas en la adaptación a USB para conseguir que el robot caminara de nuevo.

Nuestro trabajo principal se enfocó en modificar el módulo “Pic_comm” y todas las configuraciones necesarias del proyecto del robot para adaptar todo a este nuevo tipo de comunicación. Esto supuso un análisis profundo del complejo funcionamiento de este componente concurrente, que pasamos a describir a continuación:

2.5.2El módulo “Pic_comm”

2.5.2.1Diseño de hilos


Gran parte del trabajo en este módulo se realiza a través de hilos. A continuación mostramos la estructura de los hilos concurrentes que realizan las distintas tareas:

Hilo_escuchar_pto_serie: Hilo que escucha el puerto serie para controlar el overlapping y almacenar en el buffer los caracteres recibidos.

Hilo_recoger_comandos: Hilo que toma los caracteres del buffer cuando han sido completamente leídos del puerto y los traduce a un comando.

Hilo_escribir_pto_serie: Hilo que escribe en el puerto serie los comandos a enviar al PIC.

Hilo_utilizar_comandos: Hilo que recoge de la cola de comandos recibidos del PIC y los ejecuta enviando los datos a los módulos correspondientes.

Hilo_consola: Hilo que carga una consola interactiva para enviar comandos al PIC

Hilo_velocidad_izda: Hilo que recoge peticiones de cambio de velocidad en la rueda izquierda procedentes del módulo Motores y los guarda en la cola de comandos a enviar al PIC.

Hilo_velocidad_dcha: Hilo que recoge peticiones de cambio de velocidad en la rueda derecha procedentes del módulo Motores y los guarda en la cola de comandos a enviar al PIC.

Hilo_simulador_encoders: Hilo que simula el avance del robot mediante pulsos de encoders lo que permite hacer pruebas de movimiento sin necesidad de tener el

robot conectado al PC.

Hilo_ultrasonidos: Hilo que recoge peticiones de barrido de ultrasonidos y los almacena en la cola de comandos a enviar al PIC.

Hilo_infrarrojos: Hilo que recoge peticiones de barrido de infrarrojos y los almacena en la cola de comandos a enviar al PIC.

Sin entrar en más detalle sobre todos estos hilos (se puede obtener más información consultando la memoria del proyecto de SSII que referimos en la Bibliografía), pasamos a hablar de su funcionalidad.

2.5.2.2Funcionalidad


Este apartado se creó tras la fase de análisis del módulo, en la que se estudió con detenimiento su comportamiento y su utilidad. De esta forma acotaríamos el problema del cambio de comunicación, sabiendo dónde realizar los cambios pretendidos. Las conclusiones del análisis se escriben a continuación:

Este módulo es el encargado de hacer llegar las órdenes enviadas desde los módulos de más alto nivel hacia el PIC, que es el que en última instancia realiza las operaciones con los sensores y los motores.

Para ello debe conocer en qué puerto se encuentra cada PIC, ya que al disponer de varios microcontroladores, cada uno ocupándose de una tarea, necesitamos varios puertos y conocer unívocamente qué PIC se encuentra conectado a cada uno. La conexión hacia los PICs se realizaba en el proyecto heredado a través de un intérprete serie grabado en el firmware de los PICs de forma que, aunque la conexión física al ordenador es a través de USB, el intérprete hacía creer al sistema operativo que en realidad se trata de un puerto serie (al cual hubo que proporcionarle unos drivers previamente modificados).

Este sistema es el que tratamos de modificar en el proyecto actual, ya que la comunicación serie a veces se perdía, y había que reenviar los mismos datos varias veces para asegurar la consistencia. Además, otro de los inconvenientes que presenta dicho interprete es que sólo permitía el envío de cadenas de caracteres a través del puerto virtual, de forma que, si queríamos enviar datos numéricos, había que hacer una conversión a caracteres, enviarla a través del puerto, y en el receptor volver a realizar la conversión a datos numéricos.

Por otro lado, este módulo también se encarga de transmitir a los módulos de más alto nivel los datos proporcionados por el PIC, de modo que la comunicación es bidireccional; por ejemplo, si el PIC envía los datos registrados por un ultrasonido, este módulo de comunicación con el PC (Pic_comm), sabe que dicho valor ha de reenviarlo al módulo de más alto nivel encargado de controlar los sensores. Al igual que realiza transmisiones, también se encarga de recibir todos los datos procedentes del PIC; es decir, la información de los encóders, información de los ultrasonidos, infrarrojos y brújula, así como comandos informativos para saber si todavía existe comunicación con el PIC y saber si el comando enviado anteriormente ha sido recibido en éste. En este caso se recibiría un comando ACK confirmando la recepción.

En el proyecto heredado, los comandos recibidos por parte de todos los sensores del robot se denominaron comandos con dato, por lo que su tratamiento era diferente al de los comandos informativos. En el caso de los comandos con dato, se hacía una división del comando recibido, tomando los 8 primeros caracteres como identificador del comando, mientras que el resto de caracteres eran tratados de manera que serían convertidos a un número entero para su posterior procesamiento en módulos superiores.

Todos estos problemas pasados se pretendieron solucionar mediante el cambio a comunicación USB, además de realizando una modificación importante en la representación de los datos enviados y recibidos. Estos cambios los pasamos a describir a continuación:

2.5.3Modificaciones realizadas

2.5.3.1Proceso de ingeniería


Tras el análisis del problema (diseño e implementación del módulo “Pic_comm” y la comunicación utilizada por el mismo), pasamos a crear un diseño propio a partir de la especificación deseada, para poder así llevar a cabo el cambio propuesto:


2.5.3.2Diseño


En este apartado pasamos a dar algunos detalles de alto nivel acerca de las soluciones tomadas en la especificación (ver diagrama del apartado anterior) para llevar a cabo los cambios pertinentes.
2.5.3.2.1Cambio en la comunicación

La misión principal era cambiar todas aquellas funciones que se comunicaran con el PIC, leyendo o escribiendo de su puerto, para adaptarlas a la nueva interfaz de lectura/escritura USB con la que había sido modificado el firmware del microcontrolador, tanto de motores como de sensores. Aquí se muestra un diagrama básico de este cambio, en el que podemos observar que la mayor modificación consiste en el uso de la nueva interfaz para comunicación por USB, con la consiguiente adaptación de las funciones y los hilos del módulo “Pic_comm”. Los detalles de implementación se ofrecen en el apartado 3.3.1.


2.5.3.2.2Cambio en la representación de los comandos

Se realizó un cambio importante en la representación de la información transmitida del robot al PIC y viceversa. Como el intérprete serie que había en el trabajo anterior sólo permitía la transmisión de caracteres, la mayoría de las órdenes que se enviaban al PIC se hacían en forma de códigos de comando, indicando un carácter de control de comando (@ en caso de tratarse de comandos de control de algún dispositivo) y un código que determinaba el comando.

Por ejemplo, si queríamos recibir la lectura del ultrasonido 1, se enviaba a través del puerto serie el comando " @80|UltraSonido1\0", tras lo cual, el PIC determinaba la acción a realizar, y una vez obtenido el resultado, enviaba el valor registrado a través del puerto al PC.

De igual modo, también se disponía de códigos informativos, como por ejemplo, "@99|ACK\0" que indicaba que el último comando enviado se recibió y ejecutó con éxito, y muchos otros, que determinaban si el comando no era reconocido por el PIC al que se envió, comandos de pruebas ("@55|Testing\0") etc.…

Realizar el cambio a comunicación USB nos permitiría transmitir datos de manera más libre. Por ello, lo más cómodo fue realizar la transmisión de datos hexadecimales. Éstos se codificaron de manera que la flexibilidad a la hora de crear o modificar comandos de control era inmensa. Esto, unido a la facilidad de manejo de un solo dato hexadecimal más que de una cadena de caracteres que requería “trocearla” para obtener toda la información que contenía, hacía de esta nueva representación la ideal. Además, de esta manera unificábamos los comandos que portaban datos con aquellos que no. Vemos este cambio con un gráfico que muestra la diferencia entre representaciones de datos:


2.5.4Firmware del PIC


Este apartado pretende explicar la API de la nueva librería utilizada para realizar la comunicación mediante USB, que aunque no ha sido hecha por nosotros, sí la hemos utilizado en el módulo “Pic_comm”.
1   2   3   4   5   6   7   8   9   10   ...   14

similar:

Resumen del proyecto 4 iconResumen del proyecto

Resumen del proyecto 4 iconResumen del proyecto

Resumen del proyecto 4 iconResumen del proyecto

Resumen del proyecto 4 iconResúmen del Proyecto

Resumen del proyecto 4 iconResumen ejecutivo del proyecto 7

Resumen del proyecto 4 iconResumen del proyecto y caracteristicas del sitio

Resumen del proyecto 4 iconResumen el proyecto de investigación se centró en el estudio del aceite esencial de

Resumen del proyecto 4 iconResumen El diseño, desarrollo y divulgación de cocinas solares de...

Resumen del proyecto 4 iconEsquema de proyecto feria de ciencias denominación del proyecto (nombre)

Resumen del proyecto 4 iconResumen El presente proyecto surge como una necesidad de aplicar...


Medicina



Todos los derechos reservados. Copyright © 2015
contactos
med.se-todo.com