Aclaraciones

14 12 2007

Hoy hemos estado hablando con Xabier y hemos aclarado varias cosas. Entre ellas, las ideas sobre qué es lo que envía el PC al PIC, la forma de programar el PIC, el protocolo RS232 y la forma en la que podremos testear programas entre PC y PIC.

Comunicación entre PC y PIC

El PC no debe enviar el vector de estados de la máquina, tal y como hacíamos hasta ahora; sino el vector de salidas, es decir, el estado de los diferentes motores y mecanismos del proceso. Una etapa puede tener asociadas a ella diferentes salidas, como por ejemplo Motor1 encendido, Motor2 encendido y Motor3 apagado. Esto es realmente lo que hay que enviar, ya que el PIC no debe procesar los estados, sólo actúa de puente.

Para arreglar este problema, se debe modificar el código del controlador que tenemos en estos momentos. Se deberá pedir al usuario que configure las diferentes etapas que declare, creando una “Matriz de salidas”, en la cual cada fila corresponderá con su etapa, y cada columna con las diferentes salidas del programa (ej: Motor1, Motor2, Motor3; 3 salidas para como máximo 2^3 etapas, eligiendo por ejemplo 4 etapas), guardándola en un fichero, para que pueda ser cargada después de cerrar el programa. El usuario deberá introducir el número de salidas del sistema, y configurarlas para cada etapa.

Protocolo RS232

En el cable de serie, si no enviamos nada, tendremos -12V, es decir, un 1 lógico tras la conversión de -12V a 5V por la UART. Al enviar algo, el bit de Inicio será un 0, gracias al cual se detectará en el PIC (el controlador ya tiene su propio sistema de detección implementado) que se está enviando información desde el PC. Después vendrán 8 bits de datos, con un retardo entre ellos de 100ms por la diferencia de velocidades entre RS232 (9600baudios) y PIC(4mhz). Tras ello, vendría el bit de paridad, el cual no usaremos (actualmente lo estamos usando en el Controlador, así que habrá que cambiarlo). Después, vendrán 2 bits de stop (unos lógicos). Por lo tanto el PIC tiene que enviar estos tipos de paquetes, sabiendo que entre bytes habrá siempre 2 bits de stop. El esquema está en el capítulo 20 del pdf del PIC16F84A.

Programación del PIC

Lo ideal sería por medio de interrupciones, pero podemos dejarlo como un extra, programándolo por medio de la técnica polling; bucle infinito realizando las diferentes tareas del PIC (recibir información de los sensores y enviarla al PC, recibir información del PC y enviarla a las salidas).

Testear PIC y PC interconectados

Es obligatorio el uso de una placa con un MAX232, ya que el uTrainer no dispone de él, y se quemaría con los 12V del protocolo RS232. Así que ya puestos, no estaría mal hacernos nuestra propia placa.

Espero que para el Lunes tenga el programa del Controlador actualizado y funcionando, para poder testearlo en las 3 horas de PBL. También intentaré aprender cómo simular con el MPLAB.


Acciones

Information

One response

15 12 2007
ionbixen

la cosa es que si no tenemos que hacerlo mediante interrupciones va a ser bastante mas sencillo y no tenemos porque comernos la cabeza para saber como simular interrupciones en el maplba de todas formas nos ha dicho Xabi que el LUNES va a venir tito a explicarnos como va el simupic o el maplab o noseke…

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s




A %d blogueros les gusta esto: