Embed Size (px)
Citation preview
Sistemas Embebidos
INFORME
DEL PROYECTO
POSICIONADOR 2D CON GOLPEADOR
GRUPO4
Integrantes: Guzman Vigliecca, Vittorio Scopelli, Maximiliano Silva
Tutor: Conrado Rossi
Instituto de Ingeniería Eléctrica
Facultad de Ingeniería
Universidad de la República
Resumen
El proyecto consiste en la implementación del software de control de un
posicionador de dos dimensiones. Se encuentra basado en motores paso a
paso, utilizando un microcontrolador MSP430G2553 y periféricos para
controlar la posición. Este proyecto se enmarca en un proyecto de grado,
el cual requiere de un dispositivo que permita golpear una superficie
controladamente y en una posición bien determinada.
Para cumplir con estos objetivos, se desarrolló un software que integra el
control de dos motores a paso, junto con cuatro interruptores de parada, y
un led que simula el estado del golpeador. Se utilizó una arquitectura
Round Robin con interrupciones, en donde las interrupciones están
asociadas a un Timer y a la comunicación. El Timer se encarga de dar el
período de los pasos del motor y el tiempo de los golpes, mientras que la
comunicación se encarga de recibir y enviar comandos hacia la pc.
El dispositivo se comunica con la PC utilizando la UART, y es capaz de
recibir, interpretar y ejecutar comandos relativos a la posición y
velocidad, y enviar mensajes de error o con información del estado
actual.
Tabla de contenidos Resumen ........................................................................................................................... 2
1 Introducción .............................................................................................................. 4
1.2 Antecedentes .......................................................................................................... 4
1.3 Descripción del problema ...................................................................................... 5
2 Objetivos ........................................................................................................................ 5
3 Alcance .......................................................................................................................... 5
4 Diseño ............................................................................................................................ 5
4.1 Descripción funcional del sistema .......................................................................... 5
4.2 Elementos del hardware .......................................................................................... 6
4.3 Software .................................................................................................................. 9
5 Implementación ......................................................................................................... 10
5.1 Inicialización ......................................................................................................... 10
5.2 Abstracción de hardware....................................................................................... 11
5.3 Comunicación ....................................................................................................... 12
5.4 Módulo SHELL .................................................................................................... 13
5.5 Comandos del sistema .......................................................................................... 14
5.6 Estructura del MAIN ............................................................................................ 15
6 PRUEBAS ................................................................................................................. 16
7 Conclusiones .............................................................................................................. 18
8 Referencias ................................................................................................................ 18
9 Anexo ........................................................................................................................ 19
9.1 Conceptos del curso aplicados al proyecto ........................................................... 19
9.2 Planificación del proyecto .................................................................................... 19
9.3 Archivos fuente ..................................................................................................... 20
Especificación del proyecto de Sistemas embebidos ................................................. 21
1 Introducción
Este trabajo se enmarca en un proyecto de ingeniería que consiste en estudiar la
propagación de ondas en materiales. Para ello se detectará, con sensores piezoeléctricos
la respuesta al impulso de golpes en el material. Mediante un algoritmo se podrá
determinar en base a estas respuestas la posición del golpe.
Esto genera la necesidad de construir un dispositivo que sea capaz de dar golpes en
determinada posición del material cuando el usuario lo requiera, así como “barrer” toda
la superficie con una distancia entre golpes fija durante todo el barrido. La posición del
golpe o el valor de la distancia entre golpes será determinada por el usuario mediante
comandos por Matlab. Además será necesario determinar la posición del golpeador en
cada instante para asociar la respuesta al impulso con la posición correspondiente.
1.2 Antecedentes
Existen distintos tipos de sistemas de automatización relacionados al posicionamiento.
Uno de los más importantes es el control numérico computarizado (CNC).Aparte de
aplicarse en las máquinas-herramienta para modelar metales, el CNC se usa en la
fabricación de muchos otros productos de ebanistería o carpintería. Este sistema ha
revolucionado la industria debido al abaratamiento de microprocesadores y a la
simplificación de la programación (ver figura 1a). [1]
Otra aplicación en auge relacionada al posicionamiento es la impresora 3D. Esta
máquina es capaz de realizar réplicas de diseños en 3D, creando piezas o maquetas
volumétricas. Por este motivo, se agrega otro grado de libertad al posicionador, para
tener acceso a un espacio de tres dimensiones. Comúnmente se ha utilizado en el
prototipado o en la prefabricación de piezas o componentes, en sectores como la
arquitectura y el diseño industrial (ver figura 1b). [2]
Figura 1: En la figura a) se observa una máquina herramienta CNC, ampliamente utilizada en la industria. En
la figura b) se tiene una impresora 3D para la creación de objetos tridimensionales. Ambas máquinas tienen en
común la necesidad posicionamiento preciso y controlado.
1.3 Descripción del problema
Se quiere programar un microcontrolador para manejar un posicionador en dos ejes con
un golpeador. Con este objetivo, el microcontrolador será capaz de recibir comandos y
enviar información hacia un PC a través de un puerto serial.
2 Objetivos
El objetivo del proyecto es generar las señales que controlan los motores del
posicionador y el golpeador, e interpretar las señales recibidas que permiten el correcto
posicionamiento del mismo. Además se debe implementar una comunicación serial con
la PC que permita al usuario el control del posicionador. Se entregaran los códigos
correspondientes que permitan lograr lo anterior.
3 Alcance
- Generación de las señales para controlar el golpeador y los motores, a través de
los drivers de los mismos.
- Recepción e interpretación de las señales de los sensores de contacto que se
encargan de controlar que el posicionador no se vaya de rango.
- Implementación de la comunicación serial con la PC, así como la interpretación
de los comandos correspondientes.
- Se encuentra fuera de alcance la construcción física del golpeador.
- También queda fuera la programación de alto nivel.
4 Diseño
4.1 Descripción funcional del sistema
El sistema es capaz de mover los motores y el golpeador de acuerdo a comandos
recibidos desde el PC por medio del puerto serial. Estos comandos son los necesarios
para mover el posicionador y controlar el golpeador, es decir: moverse hacia cierto
punto, volver al origen, golpear, cambiar la velocidad, etc.
Figura 2: Esquema general del sistema
Además el sistema determina y devuelve la posición en la que se encuentra el golpeador
cuando se lo solicita. También es capaz de evitar que se vaya de rango, para eso se
cuenta con sensores de contacto conectados al microcontrolador. La posición se
determina contando los pasos de los motores stepper a partir de la posición inicial o de
una posición seteada por el usuario.
A continuación se presenta un diagrama de bloques con los componentes esenciales del
sistema posicionador (figura 2).
4.2 Elementos del hardware
La plataforma principal de hardware utilizada fue el MSP 430G2553, en un launchpad
MSP-EXP430G2. Dicho microcontrolador fue el utilizado durante el curso, y se eligió
nuevamente para el proyecto dado que cumplía con las exigencias requeridas.
A continuación se enumeran algunas de las características principales por las cuales se
eligió dicho microcontrolador:
- El launchpad posee 14 pines de entrada y salida. Se utilizó un pin para cada
sensor de fin de carril, y un pin para el golpeador. También se conectaron dos
drivers para controlar los motores, con dos entradas cada uno, y se debió tener
Figura 3: a) Motor stepper Nema 17 bipolar, posee cuatro cables de salida b) Driver Allegro’s A4988, usado
para suministrar la potencia a los motores y realizar el manejo en la secuencia de la corriente que pasa por los
bobinados
en cuenta que dos de los pines estaban ocupados por la UART. De todas formas
se precisaron 11 de los 14 pines disponibles.
- Se dispone de 16MHz frecuencia interna, y de un cristal externo a 32-kHz.
Dichas frecuencias son más que aceptables, dado que los pulsos encargados de
mover los motores no pueden superar 1kHz.
- Se dispone de una Uart para la comunicación serial con la computadora,
necesaria para realizar los comandos que controlan al posicionador.
Sin entrar en detalles sobre los elementos constructivos del posicionador, se describen
algunos de los componentes más importantes del hardware.
El movimiento es producto de la acción de dos motores paso a paso, híbridos bipolares
Nema 17, con una precisión de 0,9 grados por paso (figura 3a). Consta de cuatro cables
correspondientes a dos bobinados. Al hacer pasar corriente por ellos con una secuencia
determinada, se logra girar el rotor.
Para poder suministrarle la potencia necesaria a las bobinas de los motores, se utilizan
dos drivers Allegro’s A4988 (figura 3b) que también se encargan de realizar la
secuencia en el manejo de la corriente que pasa por los bobinados.
La comunicación se realiza a través de dos pines de entrada en el driver de 3,3V. En uno
de los pines se le indica el sentido en que se quiere girar el rotor, mientras que en el otro
se realiza la instrucción de dar pasos. Cada uno de los pasos se le indica mediante un
pulso.
De esta forma, al conectar los pines de nuestro microcontrolador con los pines del
driver, y el driver a los cables del motor, se obtiene el esquema que se representa en la
siguiente figura (figura 4).
Para resolver los fines de rango físicos en el posicionamiento, se decidió utilizar
sensores de contacto que se activen cuando en uno de los ejes se alcance el límite. En
primera instancia se intentó utilizar simplemente botones, de forma que cortocircuiten
un pin de entrada del microcontrolador a VCC cuando se lo presione, y se mantenga
abierto en otro momento.
Esto no fue una solución ya que cuando el pin dejaba sin
cortocircuitar, automáticamente se detectaba una entrada
lógica ya que el pin del MSP quedaba sin ningún voltaje de
referencia. Por esta razón se decidió utilizar micro switches.
Dichos dispositivos, permiten mantener un pin de entrada del
microcontrolador en tierra o VCC según se lo presione
(figura 5). Además poseen la característica de necesitar muy
poca fuerza al pulsarlos, por lo que no se ve afectado el
sistema.
Finalmente se integraron los elementos estructurales del posicionador, con todos los
componentes del hardware descritos, como se puede apreciar en la figura 6. Un motor
implementa el movimiento en un eje, y el otro montado arriba, el movimiento del carro.
Figura 4: Esquema de la conexión del driver
Figura 5: Micro switch de
parada
Figura 6: fotografía del posicionador
Cabe destacar, que el golpeador no pudo ser implementado como tal, por lo que se lo
representó con un led del microcontrolador.
4.3 Software
Se eligió una arquitectura Round Robin con interrupciones. Esta arquitectura no posee
un orden de prioridad en las interrupciones, sin embargo, en el sistema del golpeador
existen ciertos eventos que se deben atender con un orden de prioridad.
La interrupción de los sensores de contacto para el fin de carril, es la de mayor
importancia. Esto se debe a que es la interrupción que necesita un menor tiempo de
respuesta. De todas formas, hay tener en cuenta que el error al realizar un paso fuera del
rango es muy bajo, por lo tanto este no es un factor determinante a la hora de elegir la
arquitectura del software.
Las otras interrupciones asociadas, son las interrupciones de la UART para la
comunicación serial con la computadora, y las interrupciones del timer.
Las arquitecturas de planificación por encolado de funciones y RTOS, pueden ser
ejecutadas en orden de prioridad, lo cual es una ventaja en comparación con la
arquitectura Round Robin con interrupciones, para el manejo de la prioridad de los
sensores de contacto. Pero como se dijo anteriormente esto no es un factor determinante
para el funcionamiento del sistema.
El aumento de la complejidad de las arquitecturas de planificación por encolado de
funciones y RTOS, frente a la arquitectura Round Robin, fue finalmente el factor
principal a la hora de elegir la última.
De todas formas para el envío de mensajes a la computadora, se utilizaron colas
circulares de espera. Esta resolución se tomó debido a la necesidad del sistema de poder
realizar muchos envíos de mensajes al mismo tiempo, como se detallara más adelante.
[3]
Figura 7: Esquema general del software. Arquitectura Round-Robin con interrupciones.
Finalmente en la figura 7, se puede apreciar el diagrama de flujos del software con
arquitectura Round Robin con interrupciones.
Describiendo brevemente el diagrama, el sistema comienza inicializando los
componentes principales, así como la configuración del software. Luego comienza el
loop principal, en donde distintas banderas indican la ejecución de los handlers.
El primer bloque que se observa asociado a un handler, es el movimiento del motor.
Éste solo se mueve si se cumple cierto tiempo, el cual es un múltiplo del tiempo de las
interrupciones del timer, este múltiplo determina la velocidad con la que se moverán los
motores. De igual forma ocurre con el bloque asociado al golpeador. Por último, el
bloque de recepción se encarga de ejecutar el handler asociado a los mensajes.
5 Implementación
En esta sección, se describirán las características y las funciones de cada uno de los
módulos implementados, así como la capa de abstracción del hardware y la ejecución de
los comandos enviados desde la computadora.
El entorno de desarrollo integrado que se utilizó, es el IAR EmbeddedWorkbench. Este
es el ambiente que se venía utilizando en el curso, y cumple con todos los
requerimientos para el proyecto.
5.1 Inicialización
En la figura 8, se aprecia el diagrama de flujo encargado de
la inicialización del software. A continuación se describirán
brevemente sus funciones.
En primera instancia se comienza desactivando el watchdog
mediante la modificación del registro correspondiente. Esta
decisión se tomó pensando en que el watchdog podría
reiniciar el software en algún momento en la ejecución con
un tiempo fijo, lo que hubiera sido impráctico porque el
tiempo entre la llegada entre un comando y otro podría ser
arbitrariamente grande. Se podría haber utilizado el mismo
como timer pero se optó por utilizar el timer A por una
cuestión de que es más sencillo de entender ya que el
watchdog está pensando para vigilar el código más que para
actuar como timer.
Figura 8: Bloques de inicialización
El bloque de inicializar sensores, inicializa cuatro pines del MSP como entradas para los
sensores de contacto.
Luego se inicializan los pines del MSP como salidas para los motores. Dos de los pines
a inicializar corresponden al sentido de giro y otros dos para indicar los pasos. En total
se tienen cuatro pines utilizados.
Para la UART se inicializan los pines de comunicación, se fija la velocidad de
transmisión, se habilitan interrupciones, y otras características de la comunicación (bit
de paridad, largo de la palabra, etc).
Al inicializar el timer, se fija la frecuencia de interrupciones en un milisegundo. Se
tomó esta frecuencia dado que es la máxima que soportan los motores.
Para el golpeador, como se mencionó anteriormente, no se tiene una implementación
física, por lo que se inicializa un pin del MSP asociado a un led como salida. El led se
prende si al golpeador se le indica que baje, y se apaga si se el mismo sube. En el caso
del golpe el led parpadea simulando la acción rápida de bajada y subida.
Finalmente se inicializan las variables de la cola circular de manera de que quede vacia
desde un punto de vista lógico.
5.2 Abstracción de hardware
La capa de abstracción de hardware (en inglés, Hardware Abstraction Layer o HAL) es
un elemento que funciona como una interfaz entre el software y el hardware del sistema,
proveyendo una plataforma de hardware consistente sobre la cual corren las
aplicaciones.
Las HAL permiten que las aplicaciones sean independientes del hardware porque
abstraen información acerca de tales sistemas, como lo son las cachés, los buses de E/S
y las interrupciones. De esta forma permite la portabilidad del código a otro hardware,
sin necesidad de modificarlo. [4]
Figura 9: Elementos incluidos en la capa de abstracción del hardware.
Los elementos incluidos en la capa de abstracción del hardware, son los referidos a los
sensores, los motores, y al golpeador. (Figura 9)
En este caso particular la capa de abstracción se centra en los pines de salida y entrada
de todos los periféricos utilizados. Esta capa de abstracción nos permitirá en una etapa
posterior del proyecto cambiar de microcontrolador si fuese necesario, ya que no todos
los microcontroladores llevan mapeados los puertos en memoria en las mismas
posiciones, variando incluso dentro de los microcontroladores de una misma familia, y
solo habría que modificar esta capa y no el resto de los módulos.
5.3 Comunicación
La comunicación con la pc, se realizó a través del módulo USCI configurada como
UART, como fue visto en el curso. Dicha implementación, tuvo a su vez dos
características importantes vinculadas al envío de los datos, y al reconocimiento de los
comandos recibidos desde la computadora. (Figura 10)
En cuanto al envío de los datos, se debió implementar una cola de transmisión. Esta
decisión se tomó ya que en determinados momentos en la operación del posicionador,
se debían enviar más de un mensaje a la vez.
En particular, cuando el posicionador llega al destino en alguno de los ejes, envía un
mensaje de llegada. Además al llegar a los límites, también debe enviar un mensaje de
límite para cada eje. Cualquiera de estos mensajes se puede enviar en el mismo
momento. Como peor caso, se tiene el envío de los cuatro mensajes al mismo tiempo,
por esto se implementó una cola de largo cuatro.
En cuanto a la recepción de los comandos, se incluyó un intermediario, SHELL. Este
módulo fue proporcionado, y no se desarrolló en este proyecto pero si se realizaron
algunas modificaciones para la correcta implementación en nuestro sistema que se
describen más adelante.
Figura 10: Comunicación basada en una cola de transmisión y en un módulo UART
Figura 11: Esquema general de comunicación.
En la figura se tiene el esquema del envío desde una computadora de los comandos a
ejecutarse en el posicionador. La UART proporciona el módulo de entrada de los datos
al microcontrolador, mientras que el SHELL, se encarga de identificar los comandos, y
vincularlos a las funciones correspondientes a su instrucción.
5.4 Módulo SHELL
El módulo Shell consta de una estructura o lista que vincula cada comando con su
función asociada. Esto fue una gran ventaja al momento de tratar los comandos
entrantes pues si no se hubiera contado con este módulo cada comando debería haber
sido tratado por separado en el Round Robin.
En nuestra arquitectura de comandos (página 9) se ve que hay un bloque llamado
ejecutar comando. Este bloque es justamente el SHELL, al cual se le entrega el nombre
de comando más cierta cantidad de parámetros, luego ejecuta la función correspondiente
con estos parámetros.
El Shell proporcionado inicialmente fue diseñado para PC y compilado para esta última.
Al intentar compilarlo en el MSP daba error de memoria RAM. El problema era que la
estructura del SHELL incluía en su interior una descripción en código ASCII de los
comandos, también incluía un comando help, que venía por defecto y tenía mucho texto
asociado. Estos textos ASCII por más cortas que fueran las descripciones ocupaban un
lugar enorme comparado con la capacidad RAM del MSP430 (512B). Solo teniendo en
cuenta que cada letra ocupa 1B solo se podría tener 512 letras en total (si se ocupara
toda la ram), cantidad insuficiente para la gran cantidad de comandos y descripciones
que se tenían que hacer, además había que tener en cuenta que se necesitaba ya unos
400B de ram para almacenar las variables para que funcionara el resto del programa.
Por lo tanto se optó por borrar de la estructura del SHELL la parte de descripciones y el
comando HELP que venía por defecto.
5.5 Comandos del sistema
Para poder interactuar con el posicionador, se crearon algunos comandos
imprescindibles para el correcto control, tanto de la posición y velocidad del
posicionador, como del golpeador y el estado de los distintos dispositivos del sistema. A
continuación
En los cuadros de la figura, se encuentran listados
los distintos comandos implementados.
El comando SETSPEED define el período para los
pasos de los motores, mientras SETSPEEDG el
tiempo de los golpes.
SETPOINT se utiliza para indicarle al posicionador
que realice una cantidad de pasos determinada,
cambiando las variables pointX y pointY.
Al mandar STOP, se igualan las variables que
indican la posición actual, con las variables que
tienen la posición objetivo. Cabe destacar que las
variables que se modifican son las de objetivo, y no
las del estado actual.
Al ejecutar el comando SETCERO, se indica que
la posición actual es el origen. Mientras que el comando RETCERO, coloca como
objetivo la posición indicada como origen.
READSPEED, SPEEDG Y POSICION, indican el estado actual del sistema, mediante
la devolución a la computadora del valor de los parámetros velocidad de los pasos,
velocidad del golpe y posición actual respectivamente.
Finalmente los comandos encargados del movimiento del golpeador son UP, DOWN y
GOLPEAR. Los primeros bajan y suben el dispositivo “golpeador”, mientras que
GOLPEAR, primero baja y luego sube el dispositivo con una velocidad determinada.
Figura 12: Comandos de control del
posicionador y golpeador.
5.6 Estructura del MAIN
Para entender el funcionamiento del programa, se demostrará el modo de operación a
través de un ejemplo. En el diagrama de flujo de la figura 13, se demuestra lo que
ocurre cuando se envía el comando “GOLPEAR”.
Luego de que el comando es recibido y almacenado en memoria, la Shell lo asocia a una
función y la ejecuta. Una bandera se prende indicando que el golpeador esta abajo, y se
baja el golpeador.
Se permanece con el golpeador abajo, hasta que una interrupción por Timer apaga la
bandera del golpeador y este se levanta.
Figura 13: Diagrama de flujo de ejecución del comando GOLPEAR.
Otro de los comandos principales es el SETPOINT X Y, el cual se encarga del
movimiento. De la misma forma que con el comando GOLPEAR, se observa el
diagrama de flujo en la figura 14, los pasos internos que se siguen al momento de que se
ingresa un comando.
De la misma forma que en el ejemplo anterior, la Shell ejecuta su función asociada y se
fijan las coordenadas ingresadas, a la posición objetivo. Luego se suceden los pasos
hasta que la posición actual, y la posición objetivo sean iguales.
6 PRUEBAS
Las pruebas se hicieron por módulo y finalmente se probó todo el sistema integrado.
Cuando nos referimos a pruebas por módulo quiere decir que probamos la
comunicación a través de la UART por un lado, las interrupciones del timer por otro, el
control de los motores, golpeador, etc.
Probar la UART y el timer fue cuestión de tomar el código implementado en el curso y
adaptarlo, ya sea incluyendo el módulo SHELL y cambiando la velocidad de
transmisión para el caso de la comunicación, como cambiando el tiempo de interrupción
en el caso del timer (1ms). Luego se enviaron comandos a través de la UART y se
Figura 14: Diagrama de flujo de ejecución del comando GOLPEAR.
verificó que los mismos se ejecutaban cada 1 ms según el timer. En esta prueba no se
tuvo ningún tipo de problemas.
La prueba del módulo SHELL llevó a que se hicieran algunas correcciones en el diseño
del mismo como se explicó en el punto 5.4.
Para probar todos los periféricos se inicializaron los pines correspondientes y se verificó
que los drivers y los leds actuaban según lo previsto. En esta prueba se tuvo un
problema de ruido a la entrada de los drivers que generaba un movimiento extraño del
motor esto se solucionó poniendo a tierra los pines que no se utilizaban.
Por último se integró todo en el Round-Robin y se inició la etapa de debagueo del
software hasta tener el mismo listo para cargarlo en el MSP. Al cargarlo al
microcontrolador nos dimos cuenta de muchos problemas que fuimos solucionando ya
con el hardware conectado ya que era un complemento más a la interfaz del debuger.
Algunos problemas que surgieron en esta etapa fueron:
la aparición de simultaneidad en las transmisiones de algunos eventos,
como llegar al fin de carrera y llegar a la vez al punto (x, y). En este caso
antes de que terminara de enviar el mensaje de fin de carrera, comenzaba
a enviar la alerta de llegada al punto seteado. En este punto es donde
apareció la cola de mensajes de transmisión solucionando este problema.
Vale destacar que la cola de transmisión fue adaptada de la cola de
funciones utilizada en el curso, solo que esta vez la cola era de punteros a
caracteres.
problemas varios de banderas que se iniciaban en una función y se
reiniciaban en otra. Esto se solucionó centralizando los cambios de
banderas a un solo lugar.
Problemas de datos compartidos que también se pudieron solucionar
centralizando los cambios de variables solo en la rutina de interrupción o
dentro del Round Robin.
Por último se probaron los comandos en general haciendo que los motores vayan a un
lado y a otro activando todos los periféricos posibles.
Se podría concluir que todas las pruebas terminaron siendo exitosas ayudando a corregir
el código y no dejando nada pendiente.
7 Conclusiones
• Se logró cumplir en tiempo y forma el plan de trabajo estipulado en un principio.
• Se construyó satisfactoriamente un módulo de posicionamiento 2D controlado
mediante comandos.
• La elección del microcontrolador fue correcta pero se deberá cambiarlo si se
agregan funcionalidades (2 puertos libres y <100 bytes de memoria disponible).
• Se pudo adaptar y reutilizar módulos creados a lo largo del curso (UART, cola
circular, etc).
• Se logró utilizar conceptos aprendidos en el curso (manejo de interrupciones,
arquitectura, inicialización de periféricos, etc) efectivamente para lograr el
objetivo.
8 Referencias
[1] https://es.wikipedia.org/wiki/Control_numérico
[2] https://es.wikipedia.org/wiki/Impresora_3D
[3]https://eva.fing.edu.uy/pluginfile.php/66220/mod_resource/content/4/T7-
Arquitecturas-soft.2016.pdf
[4]https://es.wikipedia.org/wiki/Capa_de_abstracci%C3%B3n_de_hardware
9 Anexo
9.1 Conceptos del curso aplicados al proyecto
- Se utilizó un sistema embebido como lo es el MSP430 para el desarrollo de la
aplicación.
- Lenguaje escrito en C.
- Se utilizaron herramientas de desarrollo (IAR)
- Interrupciones, no hubo problemas de datos compartidos
- Utilización de los distintos módulos de hardware dentro del MSP430
o Timer
o Watchdog
o UART
o Leds y pines
- En el estudio de las arquitecturas de software, se tuvieron en cuenta distintas
alternativas: Round-Robin, Planificación por cola y RTOS. En particular se
implementó Round-Robin con interrupciónes, y la planificación por cola para el
envío de datos.
9.2 Planificación del proyecto
Se lograron implementar todos los puntos propuestos para el proyecto, en tiempo y
forma según lo establecido por nuestro plan de trabajo previamente entregado.
Las horas dedicadas correspondieron con las horas planificadas. La compatibilidad entre
el proyecto de fin de carrera y el proyecto de sistemas embebidos, facilitó cumplir con
lo planeado.
9.3 Archivos fuente
A continuación se listan y se describen los archivos fuente entregados.
▼ ProyectoSisemDoxygen
▼ colaTransmision Módulo con la estructura de la cola de transmisión y sus funciones de comando.
colaT.c
colaT.h
▼ hal Módulo de abstracción de hardware.
hal.c
hal.h
▼ shell Declaración de estructura y funciones del Shell
funcionesShell.c
funcionesShell.h
shell.c
shell.h
shellcmds.h
▼ timerA0 Funciones relacionadas al timer
timerA0.c
timerA0.h
▼ uart Funciones relacionadas al UART
uart.c
uart.h
main.c Programa principal
Especificación del proyecto de Sistemas
embebidos
“Posicionador 2D con Golpeador”
Especificación del Proyecto
Integrantes: Vittorio Scopelli
Guzman Vigliecca
Maximiliano Silva
Tutor: Conrado Rossi
Descripción del problema
Se quiere programar un microcontrolador para manejar un posicionador en dos ejes con un
golpeador. Con este objetivo, el microcontrolador será capaz de recibir comandos y enviar
información hacia un PC a través de un puerto serial.
Antecedentes
Este trabajo se enmarca en un proyecto de ingeniería que consistirá en estudiar la propagación
de ondas en materiales. Para ello se detectará, con sensores piezoeléctricos la respuesta al
impulso de golpes en el material. Mediante un algoritmo se podrá determinar en base a estas
respuestas la posición del golpe.
Esto genera la necesidad de construir un dispositivo que sea capaz de dar golpes en
determinada posición del material cuando el usuario lo requiera, así como “barrer” toda la
superficie con una distancia entre golpes fija durante todo el barrido. La posición del golpe o el
valor de la distancia entre golpes será determinada por el usuario mediante comandos por
Matlab. Además será necesario determinar la posición del golpeador en cada instante para
asociar la respuesta al impulso correspondiente.
Objetivos
El objetivo del proyecto es generar las señales que controlan los motores del posicionador, e
interpretar las señales recibidas que permiten el correcto posicionamiento del mismo.
Además se implementará una comunicación serial con la PC que permita al usuario el control
del posicionador. Se entregaran los códigos correspondientes que permitan lograr lo anterior.
Alcance
- Se generarán las señales para controlar los motores y el golpeador, a través de los
drivers de los mismos.
- Se recibirán e interpretarán las señales de los sensores infrarrojos que se encargan de
controlar que el posicionador no se vaya de rango.
- Se implementará la comunicación serial con la PC, así como los comandos
correspondientes.
- El proyecto no incluye la construcción física del golpeador.
Descripción del sistema
Descripción funcional:
El sistema deberá ser capaz de mover los motores y el golpeador de acuerdo a comandos
recibidos desde el PC por medio del puerto serial. Estos comandos serán los necesarios para
mover el posicionador, es decir: moverse hacia cierto punto, volver al origen, golpear, etc.
Además, para el correcto funcionamiento del mismo, el sistema deberá ser capaz de
determinar la posición en la que se encuentra el golpeador, así como evitar que se vaya de
rango, para eso se cuentan con sensores infrarrojos que estarán conectados al
microcontrolador. La posición se determinará contando los pasos de los motores stepper.
Diagrama de bloques:
Requerimientos y restricciones del sistema
Procesamiento y memoria:
El uso de memoria se va a restringir a almacenamiento de variables para la comunicación vía
UART y variables para determinar el estado de funcionamiento de los motores (constante
movimiento, un solo paso, n pasos, etc.). En resumen, no más de algunas decenas de bytes de
memoria RAM y como mucho un KB de memoria fija para el programa (dependiendo de la
cantidad de comandos que se implementen).
El uso del procesador va a ser mínimo ya que el movimiento del motor o golpeador será cada
un cierto tiempo millones de veces mayor que un período del reloj del sistema, y en cada
iteración con los motores y el golpeador solo se enviaría una señal o a los drivers o a la PC (en
caso de reportar la posición).
Tiempos de respuesta:
No hay un tiempo de respuesta máximo requerido. Al menos no en la escalas de tiempo de un
procesador.
Diseño preliminar
Plataforma de hardware:
Se utilizara un launchpad MSP-EXP430G2 que contiene un MSP 430G2553. También se
dispondrá de tres motores y sus respectivos drivers ( los sensores infrarrojos serán simulados).
Se utilizará la UART del MSP para la comunicación con la PC.
Arquitectura de software:
Se utilizará la arquitectura Round Robin con interrupciones, dejando el micro en modo bajo
consumo cuando no se lo esté utilizando. Los comandos son ingresados por el usuario,por lo
que la mayor parte del tiempo el micro estará inactivo resultando muy atractiva esta
arquitectura. Otro de las razones por la que se eligió esta arquitectura se debe a la simplicidad
del programa el cual no ameritaría un RTOS por ejemplo.
Planificación
Actividades/Tareas:
1. Implementar comunicación PC (2 días): Probar y establecer una comunicación serial
UART con la PC utilizando relterm.
2. Definir lista de comandos y disenar la arquitectura round robin correspondiente(2
dias)
3. Implementar los comandos: Se refiere al código que se ejecuta por cada comando(17
dias)
4. Probar UART y motores: Verificar el correcto funcionamiento de todo lo anterior y
además implementarlo en los motores reales. (10 días)
5. Implementar las interrupciones de los sensores.(4 días)
Describir las pruebas a realizar:
1. Para probar la comunicación entre la PC y el MSP utilizaremos un programa que haga
que el MSP retransmita todo lo que reciba al PC.
2. Para hacer las pruebas finales que el funcionamiento de los comandos uno a uno sea
el especificado. En primera instancia observando simplemente los registros de salida y
luego en una segunda instancia utilizando los motores reales.
3. Forzar interrupciones de los sensores y verificar el correcto funcionamiento de las
ISR’s.
Hito 1:
Del 9 al 30 de mayo:
1) Se entregará el código del sistema sin incluir las interrupciones de los sensores, sin
haber sido probado pero compilando correctamente.
Hito 2 (defensa):
Del 30 de mayo al 13 de junio:
2) Todo el sistema funcionando tal cual fue descrito anteriormente.
