Implementación de módulo de movimiento de motores paso a paso...

UNIVERSIDAD POLITECNICA DE MADRID

ESCUELA TECNICA SUPERIOR DEINGENIERIA Y DISENO INDUSTRIAL

Grado en Ingenierıa Electronica y AutomaticaIndustrial

TRABAJO FIN DE GRADO

Implementacion de modulo demovimiento de motores paso a

paso con controlador integradoAutor: Pablo Carrillo Carrasco

Tutor: Dr. Basil MohammedAl-Hadithi

Departamento: Electronica,Automatica e Informatica

Industrial

Cotutor: Carlos Pastor RamırezIngeniero de sistemas embebidos

en PVHardware

Madrid, Junio 2018

UNIVERSIDAD POLITECNICA DE MADRID

ESCUELA TECNICA SUPERIOR DEINGENIERIA Y DISENO INDUSTRIAL

Grado en Ingenierıa Electronica y AutomaticaIndustrial

TRABAJO FIN DE GRADO

Implementacion de modulo demovimiento de motores paso a

paso con controlador integrado

Firma Tutor Firma Autor Firma Cotutor

iii

Tıtulo: Implementacion de modulo de movimiento de motores pasoa paso con controlador integradoAutor: Pablo Carrillo CarrascoTutor: Dr. Basil Mohammed Al-HadithiCotutor: Carlos Pastor Ramırez

EL TRIBUNAL

Presidente:

Vocal:

Secretario:

Realizado el acto de defensa y lectura del Trabajo Fin de Grado eldıa ....... de .................... de ... en .........., en la Escuela Tecnica Su-perior de Ingenierıa y Diseno Industrial de la Universidad Politecnicade Madrid, acuerda otorgarle la CALIFICACION de:

VOCAL

SECRETARIO PRESIDENTE

El placer mas noble es eljubilo de comprender.

Leonardo Da Vinci

Agradecimientos

Quiero agradecer a mis companeros de la carrera por hacer mas facily a la vez valiosos estos anos academicos. A Basil por ofrecerme estaoportunidad, diferente, y marcar el camino del trabajo que siemprerequiere un punto mas de esfuerzo. A Carlos por su paciencia y guıa,de la que he aprendido mucho y sin la cual no habrıa sido posible esteproyecto. A Jorge por su ejemplo de trabajo, persona y companero debatallas en los ultimos anos, y a Pablo por contagiarme su espıritu,que me hizo ver la ingenierıa de otra forma, y por su ejemplo humano.

Finalmente quiero agradecer a mi familia por estar siempre ahı,cuando ni yo mismo estaba, y por haberme dado todo lo que soy ypudiera ser en la vida.

viii AGRADECIMIENTOS

Resumen

Este Trabajo de Fin de Grado tiene como objetivo la implemen-tacion del driver DRV8711 de control de motores paso a paso con unmicrocontrolador ARM Cortex M4 de bajo coste para inicializar regis-tros e implementar control en bucle abierto en velocidad y posicion. Elmicrocontrolador se comunica con el driver mediante interfaz STEP/-DIR y SPI para configurar registros internos y monitorizar el estado.Debera poderse controlar y monitorizar utilizando UART y SPI escla-vo desde un sistema externo.

Se plantea en primer lugar un breve estudio cronologico sobre cam-pos relativos y afines a este proyecto y los fundamentos tecnicos quelos avalan, plasmados en los capıtulos de Estado del Arte y Funda-mentos Generales.

Continua con el desarrollo de un prototipo y la implementacion defirmware, que finaliza con la implementacion en un sistema motorizadode movimiento horizontal sensorizado.

Palabras clave: ARM, Microcontrolador, Motor paso a paso, Firmwa-re.

x RESUMEN

Abstract

This project aims to implement the stepper motor control driverDRV8711 with an ARM Cortex M4 low-cost microcontroller to initia-lize registers and set open loop control for position and speed. Thedevice communicates via STEP/DIR interface and SPI to configureinner registers and monitor the state. An external system should con-trol the system via UART and slave SPI.

At first, a chronologcial study of related fields along techninal know-ledge is written covering the State of Art and Fundamental Knowledgechapters.

Then, hardware prototyping and firmware have been developed.Finally, a real sensorized system application is implemented.

Keywords: ARM, Microcontroller, Stepper Motor, Firmware

xii ABSTRACT

Indice general

Agradecimientos VII

Resumen IX

Abstract XI

Indice de siglas XXI

1. Introduccion 11.1. Motivacion del proyecto . . . . . . . . . . . . . . . . . 11.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . 11.3. Materiales utilizados . . . . . . . . . . . . . . . . . . . 21.4. Estructura del documento . . . . . . . . . . . . . . . . 2

2. Estado del arte 52.1. Evolucion de los microcontroladores . . . . . . . . . . . 5

2.1.1. Origen de los microprocesadores . . . . . . . . . 52.1.2. Microprocesador vs microcontrolador . . . . . . 62.1.3. Sistemas ARM . . . . . . . . . . . . . . . . . . 72.1.4. Microcontroladores STM32 . . . . . . . . . . . . 8

2.2. Evolucion de los motores electricos . . . . . . . . . . . 92.2.1. Origen de las maquinas electricas . . . . . . . . 92.2.2. Motores de corriente continua . . . . . . . . . . 112.2.3. Motores paso a paso . . . . . . . . . . . . . . . 13

2.3. Control de motores paso a paso . . . . . . . . . . . . . 16

3. Fundamentos generales para sistemas embebidos 193.1. Tecnologıa embebida . . . . . . . . . . . . . . . . . . . 19

3.1.1. Sistema microcontrolador . . . . . . . . . . . . 203.1.2. Microcontrolador STM32F410C8 . . . . . . . . 22

xiv INDICE GENERAL

3.2. Sistemas de comunicacion . . . . . . . . . . . . . . . . 233.2.1. Modulacion por Ancho de Pulso . . . . . . . . . 243.2.2. Receptor-Transmisor Asıncrono Universal . . . 253.2.3. Interfaz de Perifericos Serie . . . . . . . . . . . 253.2.4. Circuito Interintegrado . . . . . . . . . . . . . . 27

3.3. Control de motores . . . . . . . . . . . . . . . . . . . . 273.3.1. Manipulacion del paso o Microstepping . . . . . 273.3.2. Modos de decaıda o Decay Modes . . . . . . . . 28

3.4. Controlador DRV8711 de TI . . . . . . . . . . . . . . . 303.5. Software de desarrollo . . . . . . . . . . . . . . . . . . 31

3.5.1. IDEs . . . . . . . . . . . . . . . . . . . . . . . . 313.5.2. Terminales de comunicacion . . . . . . . . . . . 32

4. Desarrollo del proyecto 334.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.1. Prototipo del sistema . . . . . . . . . . . . . . . 334.1.2. Pinout y conexion de los componentes . . . . . 36

4.2. Desarrollo de firmware . . . . . . . . . . . . . . . . . . 404.2.1. Estructura funcional . . . . . . . . . . . . . . . 414.2.2. Inicializacion con STM32CubeMX . . . . . . . . 434.2.3. Main . . . . . . . . . . . . . . . . . . . . . . . . 464.2.4. Modulo Parser . . . . . . . . . . . . . . . . . . 484.2.5. Modulo STT (maquina de estados) . . . . . . . 534.2.6. Modulo DRV . . . . . . . . . . . . . . . . . . . 55

4.3. PCB y controlador final . . . . . . . . . . . . . . . . . 634.3.1. PCB . . . . . . . . . . . . . . . . . . . . . . . . 634.3.2. Pinout del controlador . . . . . . . . . . . . . . 654.3.3. Carcasa protectora . . . . . . . . . . . . . . . . 67

4.4. Maqueta de aplicacion . . . . . . . . . . . . . . . . . . 69

5. Pruebas y resultados 735.1. Funcionalidades del controlador . . . . . . . . . . . . . 73

5.1.1. Dinamica . . . . . . . . . . . . . . . . . . . . . 745.1.2. Registros . . . . . . . . . . . . . . . . . . . . . . 74

5.2. Pruebas en maqueta . . . . . . . . . . . . . . . . . . . 75

6. Conclusiones 796.1. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 79

INDICE GENERAL xv

6.2. Desarrollos futuros . . . . . . . . . . . . . . . . . . . . 79

Bibliografıa 81

Anexo: Esquematico de diseno del controlador 85

xvi INDICE GENERAL

Indice de figuras

1.1. Driver de motores para Raspberry . . . . . . . . . . . . 2

2.1. El primer microprocesador, Intel 4004 . . . . . . . . . . 62.2. Zilog Z80 . . . . . . . . . . . . . . . . . . . . . . . . . 62.3. Logo en chip con tecnologıa ARM . . . . . . . . . . . . 82.4. Dinamo de Faraday . . . . . . . . . . . . . . . . . . . . 92.5. Generador de corriente alterna, disenado por Hippolyte

Pixii . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6. Motor Magnetico Recıproco de Boucherot . . . . . . . 102.7. Distribucion de la corriente y flujo del motor . . . . . . 112.8. Circuito equivalente del motor de corriente continua . . 122.9. Regla de la mano izquierda . . . . . . . . . . . . . . . . 132.10. Angulo de paso de 90 grados . . . . . . . . . . . . . . . 142.11. Circuito de control con microcontrolador PIC . . . . . 162.12. Circuito de control de un motor bipolar . . . . . . . . . 172.13. Diagrama de bloques de un motor paso a paso conec-

tado a un sistema fotovoltaico . . . . . . . . . . . . . . 18

3.1. El sistema embebido . . . . . . . . . . . . . . . . . . . 203.2. Layout basico del microcontrolador . . . . . . . . . . . 203.3. Caracterısticas del microcontrolador STM32F410 . . . 223.4. Comunicacion en paralelo . . . . . . . . . . . . . . . . 233.5. Comunicacion en serie . . . . . . . . . . . . . . . . . . 243.6. Senal PWM de onda cuadrada y ciclo de trabajo D . . 253.7. Comunicacion por interfaz UART . . . . . . . . . . . . 253.8. Ejemplo de comunicacion por interfaz SPI . . . . . . . 263.9. Envıo de un mensaje con el protocolo I2C . . . . . . . 273.10. Generacion de microstepping con diferentes divisiones . 283.11. Diferentes flujos de los decay modes en el puente en H . 293.12. Esquematico del sistema controlador con DRV8711 . . 30

xviii INDICE DE FIGURAS

3.13. Logo del IDE Atollic TRUEStudio . . . . . . . . . . . 313.14. Logo del software CubeMX de STM32 . . . . . . . . . 323.15. Logo de Atom . . . . . . . . . . . . . . . . . . . . . . . 32

4.1. El board nucleo F303K8 . . . . . . . . . . . . . . . . . 344.2. BOOST-DRV8711 de TI . . . . . . . . . . . . . . . . . 354.3. Motores paso a paso Wantai Motors . . . . . . . . . . . 364.4. Diagrama de comunicacion del sistema . . . . . . . . . 364.5. Pinout del Nucleo-F303K8, canales SPI resaltados . . . 374.6. Pinout del Boost-DRV8711, canales SPI resaltados . . 374.7. Los cuatro hilos del motor paso a paso bipolar . . . . . 384.8. Sistema prototipo conectado . . . . . . . . . . . . . . . 394.9. Comparativa entre librerıas de abstraccion hardware . . 404.10. Componentes en el firmware del sistema . . . . . . . . 414.11. Patillas para comunicacion UART (azul) y SPI (rojo)

en el nucleo F303K8 . . . . . . . . . . . . . . . . . . . 434.12. Patilla PA2 . . . . . . . . . . . . . . . . . . . . . . . . 444.13. Flujo del analisis sintactico byte a byte . . . . . . . . . 494.14. Maquina de estados del sistema . . . . . . . . . . . . . 534.15. Paquete de bits para la comunicacion con el DRV8711 . 574.16. Mapa de los registros del DRV8711 . . . . . . . . . . . 584.17. Manejo de mascaras para paquetes de 8 bits . . . . . . 584.18. Transmision del paquete de bits por SPI . . . . . . . . 594.19. Esquematicos del DRV8711 y del circuito Bulk . . . . . 634.20. Layout del diseno . . . . . . . . . . . . . . . . . . . . . 644.21. Placa fabricada . . . . . . . . . . . . . . . . . . . . . . 644.22. Placa con los componentes soldados . . . . . . . . . . . 654.23. Pines de las bobinas del motor y VCC y GND . . . . . 664.24. Pines de conexion JTAG . . . . . . . . . . . . . . . . . 664.25. Pines del encoder, endstop y puerto UART . . . . . . . 674.26. Pieza superior de la carcasa . . . . . . . . . . . . . . . 684.27. Pieza inferior de la carcasa . . . . . . . . . . . . . . . . 684.28. Controlador con carcasa . . . . . . . . . . . . . . . . . 684.29. Diseno de la maqueta en CAD . . . . . . . . . . . . . . 694.30. Plano general de la maqueta . . . . . . . . . . . . . . . 694.31. Conexiones del endstop y encoder . . . . . . . . . . . . 704.32. Conexion del integrado de TI a los pines UART del

controlador . . . . . . . . . . . . . . . . . . . . . . . . 71

INDICE DE FIGURAS xix

5.1. Configuracion en Realterm para las pruebas . . . . . . 735.2. Variacion del consumo al cambiar los registros del driver 755.3. Aproximacion de la guıa al punto de origen . . . . . . . 765.4. Control del pendulo invertido con el controlador . . . . 77

xx INDICE DE FIGURAS

Indice de siglas

ARM Advanced Risc MachineAN Application NoteCAN Controller Area NerworkCC Corriente ContinuaCI Circuito IntegradoCS Chip SelectDRV DriverEEPROM Electrically-Erasable Programmable Read-Only MemoryEFK Extended Kalman FilterFPU Floating-Point UnitGND GroundGPIO General Purpose Input-OutputGUI Guide User InterfaceHAL Hardware Abstraction LayerI2C Interintegrated CircuitIDE Integrated Development EnviromentLED Light-Emitting DiodeLSB Least Significant BitMCU Microcontroller UnitMISO Master In Slave OutMOSI Master Out Slave InMOSFET Metal-Oxide-Semiconductor Field-Effect TransistorMSB Most Significant BitOEM Original Equipment ManufacturerPCB Printed Circuit BoardPIC Peripheral Interface ControllerPLA Polylactic AcidPWM Pulse-Width ModulationRISC Reduced Instruction Set ComputingSPI Serial Peripheral Interface

xxii INDICE DE SIGLAS

SS Slave SelectTI Texas InstrumentsTIM TimerUART Universal Asynchronous Receiver-TransmitterUSB Universal Serial Bus

Capıtulo 1

Introduccion

1.1. Motivacion del proyecto

De lleno en un mundo embebido, la creciente mejora tecnologicade estos sistemas llama la atencion a la hora de realizar un proyec-to. En pocos anos, la capacidad de trabajo de los microcontroladoresha aumentado considerablemente, reducido el consumo energetico, yalcanzado un nivel de produccion que ha bajado el coste por compo-nente hasta ser muy asequibles para cualquier persona.

Combinando el espıritu de aprendizaje con las modernas ramas dela Ingenierıa Electronica, y de explotar, y a la vez complementar, losconocimientos adquiridos en la carrera, surge este interesante proyectoque combina diversos campos, como son la electronica digital y laprogramacion, cuyo trabajo devuelve una bonita experiencia.

1.2. Objetivos

El objetivo principal de este proyecto es la puesta en marcha de unprototipo controlador utilizando placas de desarrollo y un driver demotores (figura 1.1). De forma mas concreta:

Implementar protocolo de monitorizacion SPI del driver.

Implementar protocolo de comunicacion UART y SPI para el or-denador/controlador.

Implementacion del driver y la solucion en PCB.

Caracterizar el funcionamiento.

2 CAPITULO 1. INTRODUCCION

Figura 1.1: Driver de motores para Raspberry

1.3. Materiales utilizados

Para el desarrollo del proyecto se ha decidido usar tecnologıas mo-dernas de bajo coste y consumo energetico, que permiten completarun proyecto funcional. Los materiales utilizados durante el prototipadodel proyecto son:

Microcontroladores STM32, de STMicroelectronics.

Driver DRV8711 de Texas Instruments.

Motores paso a paso modelo Nema 17 y Nema 23, de WantaiMotor.

Fuente de alimentacion.

Ordenador personal.

1.4. Estructura del documento

A continuacion y para facilitar la lectura del documento, se explicamınimamente el contenido de cada capıtulo.

En el capıtulo 1 se realiza una introduccion al proyecto, explican-do la motivacion, los objetivos y estructura del mismo.

En el capıtulo 2 se expone una pequena investigacion sobre pro-yectos con objetivos y campos de desarrollo afines a este proyecto.

En el capıtulo 3 se desarrolla de forma sintetizada los fundamen-tos tecnologicos que engloban el proyecto.

En el capıtulo 4 se explica detenidamente el desarrollo practicollevado a cabo en el proyecto.

1.4. ESTRUCTURA DEL DOCUMENTO 3

En el capıtulo 5 se definen los resultados obtenidos y discusionde estos.

En el capıtulo 6 se cierra el proyecto plasmando unas conclusionescon vision personal del mismo y lıneas futuras de trabajo.

4 CAPITULO 1. INTRODUCCION

Capıtulo 2

Estado del arte

En este capıtulo se expone un recorrido cronologico sobre las tecno-logıas y avances desarrollados en microcontroladores, implementacionde firmware, y motores.

2.1. Evolucion de los microcontroladores

La situacion actual en la que se encuentra el campo de los mi-crocontroladores tiene su raız en el desarrollo de la tecnologıa de loscircuitos integrados (CI), gracias a el cual ha sido posible incorporarcientos de miles de transistores en un solo chip. Este era uno de losrequisitos indispensables para la produccion de microprocesadores,cuyo volumen de estos CI aumentaba a medida que se le iban anadien-do perifericos externos, como memorias y timers. A este conjunto sele llamarıa posteriormente microcontrolador.

2.1.1. Origen de los microprocesadores

En 1969, un equipo de ingenieros japoneses llego a Estados Unidoscon la idea de optimizar el uso de circuitos integrados en las calcula-doras que disenaban. Este proyecto fue recogido por la empresa Intel,cuyo responsable de proyecto Marcian Hoff, planteo una solucion po-co convencional en la que la funcion del circuito integrado quedabadefinida por un programa almacenado en el mismo. Esto dio a luz alprimer microprocesador en 1971, denominandose Intel 4004 (figura2.1) [1].

6 CAPITULO 2. ESTADO DEL ARTE

Figura 2.1: El primer microprocesador, Intel 4004

Este microprocesador de 4 bits tenıa una velocidad de 6.000 opera-ciones por segundo, siendo superado en caracterısticas al ano siguientepor su sucesor, el microprocesador de 8 bits Intel 8008, con un set de45 instrucciones y una velocidad de 600.000 operaciones por segundo.

En 1976, un ingeniero de Intel fundarıa la empresa Zilog, disenandoel Z80 (figura 2.2) y resultando ser el microprocesador mas exitoso deaquellos anos, desbancando los mejores productos de Intel.

Figura 2.2: Zilog Z80

2.1.2. Microprocesador vs microcontrolador

Aunque el uso de microprocesadores suponıan una gran mejora tec-nologica en todo lo que reemplazaban, seguıan suponiendo un altocoste en produccion y gran complejidad en el diseno. El problemaprincipal residıa en que para realizar una funcionalidad de utilidad, elMCU requerıa estar rodeado de un gran numero de CIs adicionales [2].

2.1. EVOLUCION DE LOS MICROCONTROLADORES 7

Durante la decada de los 70 dos ingenieros de Texas Instrumentsdisenaron el TSM 1000: una combinacion de procesador con memoriade lectura y escritura/lectura, y reloj interno [3]. Intel no tardarıa enresponder, desarrollando el Intel 8048, optimizado especialmente paraaplicaciones de control [4].

Llegados los 90, la mejora en la fabricacion de semiconductores ylas tecnicas de produccion de chip dieron como resultado la capacidadpara anadir mas circuiterıa aun en un solo chip. Una de las formas desacar partido a estas mejoras recayo en aumentar la funciones y capa-cidades adicionales que anteriormente requerıan de chips externos [2].

Una de las caracterısticas en la que concurrıan los MCUs en aque-lla epoca era en el uso de las memorias EPROM que se usaban parael almacenamiento de datos, las cuales eran posible de borrar gra-cias a una ventana transparente de cuarzo a la que se exponıa a laluz ultravioleta. En 1993, la introduccion de la memoria EEPROMpermitıa a los microcontroladores un rapido borrado de memoria deforma electrica facilitando enormemente la reprogramacion de estos,y cuyo producto pionero fueron los PIC de Microchip [5].

2.1.3. Sistemas ARM

La arquitectura ARM (figura 2.3) se diseno para permitir imple-mentaciones de tamano muy reducido y de alto rendimiento. Estasarquitecturas tan simples permiten disenar dispositivos con muy ba-jo consumo de energıa. Se caracteriza fundamentalmente por ser unacomputadora de set de instrucciones reducido (Reduced InstructionSet Computer), como su propio nombre indica.


Figura 2.3: Logo en chip con tecnologıa ARM

El primer procesador ARM fue desarrollado, entre 1983 y 1985, porAcorn Computers Limited of Cambridge, siendo el primero a su vez enuso comercial. En 1990, ARM Limited se establecion como una com-panıa separada especıficamente dedicada a la explotacion de la nuevatecnologıa. El criterio de la empresa fue otorgar la licencia de estatecnologıa a varios fabricantes de semiconductores en todo el mundoy comenzo a establecerse como lıder del mercado para aplicacionesembebidas de bajo consumo y costo.

Una de las caracterısticas mas destacables de la tecnologıa ARMes el soporte de una herramienta que incluye un emulador del set deinstrucciones para verificacion del modelo de hardware, software, as-sembler, compiladores C, un linker, y un debugger simbolico [6].

2.1.4. Microcontroladores STM32

Esta familia de microcontroladores de 32 bits tuvo su comienzoen 2006, a cargo de la empresa STMicroelectronics. Estan basadosen el mismo procesador nucleo ARM de 32 bits, acompanados dememoria RAM estatica, memoria flash, interfaz de debugging y variosperifericos [7].

2.2. EVOLUCION DE LOS MOTORES ELECTRICOS 9

2.2. Evolucion de los motores electricos

2.2.1. Origen de las maquinas electricas

Los primeros desarrollos sobre motores y maquinas de rotacion vandesde los descubrimientos de Faraday en 1831, hasta el desarrollo delmotor de induccion de Tesla en 1888. Un gran descubridor y pione-ro en maquinas electricas fue Paul-Marie-Joachim Boucherot (1869 -1943), inventor del rotor de doble jaula.

Una de las primeras maquinas de rotacion electrica fue la dinamode Faraday en 1831 (figura 2.4), cuyo principal uso era la generacionde energıa.

Figura 2.4: Dinamo de Faraday

Con esta maquina se podıa demostrar el principio de reversibilidad,generando energıa electrica si se aportaba energıa mecanica, o energıamecanica aportando energıa electrica.

En 1832, basandose en los estudios de Faraday, el inventor Hip-polyte Pixii (1808 - 1835) diseno una maquina que constaba de todoslos elementos esenciales de un alternador moderno (figura 2.5), con launica diferencia de que presentaba una superficie de trabajo plana, envez de la superficie cilındrica actual.


Figura 2.5: Generador de corriente alterna, disenado por Hippolyte Pixii

La primera decada del siglo XX se produjeron grandes avances en eldesarrollo de motores electricos gracias a Paul Boucherot, quien disenoun turbo-alternador y la turbina para controlarlo (figura 2.6). Este in-geniero realizo estudios sobre el campo magnetico y sus magnitudes,relacionandolo con la superficie. Con ello, desarrollo varias maquinasque utilizaban las fuerzas magneticas y las convertıan en movimientorotativo. Fue el padre de los motores de rotor de jaula doble de induc-cion magnetica.

Figura 2.6: Motor Magnetico Recıproco de Boucherot


Existen muchos mas hitos en la industria de los motores electricos,hasta llegar a nuestros dıas (entorno a 200 anos), siendo estos simple-mente algunos ejemplos mas significativos de sus orıgenes [8].

2.2.2. Motores de corriente continua

Hasta la decada de los 80, los motores de corriente continua conescobilla (brushed motors) eran la eleccion automatica para cualquierproyecto en el que fuese necesario un control de par o velocidad.

Estos motores presentan dos circuitos electricos independientes. Unpequeno par de terminales conectados a los devanados del campo querodean cada polo. Estos devanados producen una fuerza magnetomo-triz que crea un flujo magnetico en los huecos de aire bajo los polos(figura 2.7). Los terminales principales transmiten el par producido ola corriente de trabajo a las escobillas que estan en contacto con laparte movil de la armadura del rotor, convirtiendo este flujo en energıamecanica [9].

Figura 2.7: Distribucion de la corriente y flujo del motor


Se destaca la importancia de dos elementos en estos motores: lasescobillas y el conmutador, que permiten controlar la distribucion dela corriente.

El circuito equivalente del motor de corriente continua queda ex-presado en la siguiente imagen (figura 2.8):

Figura 2.8: Circuito equivalente del motor de corriente continua

Y la fuerza electromotriz E generada se calcula a partir de la ecua-cion 2.1:

V = E + IR + LdI

dt(2.1)

En el motor de corriente continua la generacion de par se basaen la regla de la mano izquierda de Fleming, reflejada en la figura2.9: ‘Cuando un conductor esta situado en un campo magnetico y esatravesado por una corriente, aparece una fuerza sobre el’ [10]:


Figura 2.9: Regla de la mano izquierda

Que tambien se puede enunciar con la ecuacion 2.2:

F = BIL (2.2)Donde:

B = densidad de flujo magnetico en Teslas (T)

I = corriente electrica en Amperios (A)

L = longitud efectiva del conductor en metros (m)

F = fuerza en Newtons (N)

2.2.3. Motores paso a paso

Los motores paso a paso se definen como dispositivos electromecani-cos que convierten una serie de impulsos electricos en desplazamientosangulares discretos. Estos motores son ideales cuando se desea posi-cionamiento con un elevado grado de exactitud y/o una muy buenaregulacion de la velocidad, encontrando sus principales aplicaciones enrobotica, tecnologıa aeroespacial, sistemas informaticos, y manipula-cion y posicionamiento de piezas [11].


Como su propio nombre indica, los motores paso a paso avanzanuna seria de pasos durante su rotacion. Cada uno de estos pasos quedadefinido por el angulo de paso. En el ejemplo de la figura 2.10, se puedeobservar un paso de 90 grados para completar una rotacion.

Figura 2.10: Angulo de paso de 90 grados

Dado que el movimiento se produce por una senal discreta, se puededecir que es un motor ‘digital’. Esta caracterıstica resulta muy afın ainterfaces digitales como el uso de un microcontrolador para el controldel motor.

Los motores paso a paso son relativamente economicos en compa-racion con otro tipo de motores, aunque este factor siempre quedadeterminado por la resolucion requerida y el sistema de aplicacion,que hara variar el coste.

Sin embargo, el hecho de mayor importancia recae en que puedeser implementado sin ningun tipo de lazo de realimentacion, dado queel motor se mueve indistinto pasos con un angulo predeterminado ysolo es necesario contar el numero de pasos para posicionar el motorcorrectamente [12]. Esto no significa que no se apliquen sistemas delazo cerrado, como se estudiara mas adelante.

Tipos de motores y caracterısticas

Se pueden encontrar diferentes tipos de motores paso a paso:

Motor de pasos de reluctancia variable: tiene un rotor multipolarde hierro y un estator devanado laminado. Generalmente el pasoangular de este tipo de motor es de 15◦.


Motor de rotor iman permanente: permite mantener un par dife-rente de cero cuando el motor no esta energizado. El angulo derotacion se determina por el numero de polos en el estator.

Motor de pasos hıbrido: se caracteriza por tener varios dientes enel estator y en el rotor, teniendo este ultimo un iman concentricomagnetizado axialmente alrededor de su eje. Este tipo de motortiene una alta precision y alto par, se puede configurar para su-ministrar un paso angular tan pequeno como 1.8◦.

Siendo las caracterısticas principales de estos motores [12]:

Pasos por vuelta: pasos necesarios para completar una revolucion.Normalmente son 200 aunque este parametro puede cambiar endiferentes motores. En este caso al dividir entre los 360◦sale a1.8◦por paso.

Par motor (holding torque): la fuerza que ejerce el motor, cuyascaracterısticas se especifican siempre con el motor parado. El pardisminuye conforme el motor aumenta de velocidad, factor a teneren cuenta a la hora de aumentar la velocidad o aceleracion, dadoque se pierde precisionl.

Corriente por fase: corriente que soporta cada bobina del motor.Este parametro es dependiente del tipo de motor.

Tension: ındice de voltaje que soporta el motor, relacion directacon la velocidad del motor.

Inercia: a menor inercia mas aceleracion y deceleracion se puedeejercer sobre el motor, sin perdida de pasos.


2.3. Control de motores paso a paso

Actualmente, el rapido crecimiento de la tecnologıa electronica di-gital ha influenciado directamente en el desarrollo de los motores pasoa paso. Con el progreso de la tecnologıa de control, este motor es usa-do ampliamente en numerosas aplicaciones de control de movimiento,encontrados sobre todo en la industria de la robotica, de las impreso-ras, en control de sistemas, y maquinas de ensamblado automatico yhardware OEM [13][14].

Dentro del campo de los sistemas embebidos, el control de motoreses una aplicacion muy recurrida debido al alcance y por resultar unsistema economico de implementar. Un componente crıtico para rea-lizar el circuito de control en estos sistemas son los sensores, usadospara medir la corriente, posicion, velocidad y direccion del motor, ygracias a los avances en tecnologıa sensorial se ha mejorado la preci-sion y fidelidad a la vez que se reduce su coste. La funcion principalde los sensores es proporcionar feedback al sistema, usados en el buclecerrado de control [15]. La figura 2.11 esquematiza el circuito de con-trol.

Figura 2.11: Circuito de control con microcontrolador PIC

2.3. CONTROL DE MOTORES PASO A PASO 17

En los motores bipolares, como son los NEMA 17 y 23 utilizadosen este proyecto, un circuito basico de control para las bobinas es elpuente en H. Este puede ser configurado para permitir el paso de lacorriente en ambas direcciones. En el ejemplo de la figura 2.12 , lacorriente fluye de izquierda a derecha en la bobina 1 cuando los MOS-FETS Q1 y Q4 estan en ON, mientras Q2 y Q3 estan en OFF. Conla configuracion opuesta la corriente fluye de derecha a izquierda [16].

Figura 2.12: Circuito de control de un motor bipolar

Los diodos en paralelo a cada MOSFET protegen a estos de picosde voltaje causados por el alternado entre bobinas.

El uso del microcontrolador para el control resulta muy practicopara la generacion del PWM para el control de la velocidad del mo-tor, y de GPIOS para la direccion, aprovechando las nuevas tecnicasde programacion software. Otro factor de gran importancia es la po-sibilidad de fijar el microstepping (control del paso) del motor parauna mayor precision de movimiento, ası como acceder a los registrosdel driver para un control mas exhaustivo, siempre que el driver lopermita [17][18][19][20].

Tambien se puede realizar un diseno de control mas avanzado enestos sistemas sin hacer uso de sensores, manteniendo el lazo abierto.Para ello se aplica el Filtro Extendido de Kalman. El principal enfoquede esta alternativa recae en el control de posicion, donde se trabajael espacio de estados de este filtro para la estimacion de las variablesmecanicas del motor [21][22].


Aplicaciones industriales

Algunas de las aplicaciones industriales de uso generalizado de con-trol de estos motores se centran en la industria de energıa solar. Deforma mas concreta, y por la precision de posicion de los motores pasoa paso, un ejemplo serıa el seguimiento solar para una maxima irra-diacion en los paneles fotovoltaicos, cuyo esquematico se refleja en lafigura 2.13. El cambio a estos motores en los sistemas de seguimientogenera una mejora notable de eficiencia, y una mayor monitorizacionde esta al aplicar controles avanzados como logica borrosa o redes neu-ronales, que se aplica indiferentemente a sistemas fotovoltaicos comoa heliostatos [23][24][25].

Figura 2.13: Diagrama de bloques de un motor paso a paso conectado a un sistemafotovoltaico

En general a dıa de hoy cualquier sistema industrial mecanico cuyofoco de trabajo resida en la posicion, tiende a hacer uso de los motorespaso a paso por precision y facilidad de control sin necesidad de aplicarlazo cerrado.

Capıtulo 3

Fundamentos generales parasistemas embebidos

En este capıtulo se exponen la tecnologıa, mecanismos y protocolosbasicos que envuelven el proyecto, para su mejor comprension.

3.1. Tecnologıa embebida

Hoy en dıa existe una gran familiaridad con el concepto de micro-procesador, un circuito integrado de gran potencia de calculo con unproposito general, que podemos encontrar en ordenadores personalesportatiles o de sobremesa. Sin embargo no es el unico lugar donde en-contramos estos dispositivos, dado que se usan tambien en lavadoras,radios, camaras, televisiones, etc., cumpliendo una labor que requieremenor computacion y un control exclusivo de ese producto [26].

Es aquı donde entra el concepto de sistemas embebidos: micro-procesadores con control especıfico sobre un sistema. Un sistema em-bebido esta disenado para realizar funciones en tiempo real, sobrelas necesidades del sistema (figura 3.1). El modulo central se denominamicrocontrolador, el cual incluye un microprocesador, interfaces deentrada/salida, memoria, perifericos, etc.

Los lenguajes de programacion mas usados para implementar es-tos sistemas son C y C++, debido a su capacidad de optimizacion yeficiencia en relacion al hardware, y al mismo tiempo sin ser excesiva-mente tediosos para disenar codigo, en comparacion con lenguajes denivel mas bajo.

20CAPITULO 3. FUNDAMENTOS GENERALES PARA SISTEMAS EMBEBIDOS

Figura 3.1: El sistema embebido

3.1.1. Sistema microcontrolador

Los disenos internos del microprocesador moderno son generalmen-te similares. En la figura 3.2 se puede observar el diagrama de unmicrocontrolador tıpico. Todos los componentes estan conectados porun bus interno, y todo integrado en un chip, que se conecta con elmundo exterior a traves de los pines de entrada/salida [27].

Figura 3.2: Layout basico del microcontrolador

3.1. TECNOLOGIA EMBEBIDA 21

A continuacion se realiza un listado de estos modulos que componenel microcontrolador:

Unidad de procesamiento central: es el CPU del controla-dor, que contiene la aritmetica de la unidad logica, la unidad decontrol, y los registros (stack pointer, program counter, etc.).

Memoria: a veces separada en memoria de programa y memoriade datos. En controladores mas completos como los STM32 usa-dos en el proyecto, el controlador DMA maneja las transferenciasde datos entre los perifericas y la memoria, sin depender de laCPU.

Controlador de interrupciones: las interrupciones son utilespara detener el flujo del programa actual temporalmente, anteeventos internos o externos. En conjunto con los modos sleep,permiten reducir el consumo de potencia del MCU.

Timers/Counters: la mayorıa de los microcontroladores tienen2 o 3, los cuales pueden usar eventos de tiempo, medida de inter-valos, o contador de eventos. Muchos MCUs tienen generadoresde PWM de salida, que son especialmente utiles para los driversde motores.

Entradas/Salidas digitales: estos puerto son una de las carac-terısticas principales de los microcontroladores, alojando entre 3o 4 hasta 90 de ellos.

Entrada/Salidas analogicas: en diferencia de sus homologosdigitales, requieren una resolucion (entre 8 y 12 bits), y tienendiferentes numeros de canales. El modulo analogico incluye fun-cionalidades como el comparador analogico, y en algunos casos elMCU tambien incluye convertidor.

Interfaces de comunicacion: la mayorıa ofrece las interfacesmas importantes como son SPI, I2C y USART. Algunos tam-bien incluyen interfaces para buses de campo como IIC y CAN,o incluso interfaz de Ethernet.

Perro guardian o Watchdog: dado que muchas de las aplica-ciones operan entorno a sistemas de seguridad crıtica, se requiere


de una guarda contra errores de hardware o software. Este timerreinicia el microcontrolador si se da esta situacion.

Unidad de debugging: algunos MCUs estan equipados conhardware adicional para un debug remoto desde el chip hasta elPC, para la descarga de firmware.

3.1.2. Microcontrolador STM32F410C8

El microcontrolador elegido para el diseno final es el STM32F410(figura 3.3). Este microcontrolador se basa en nucleo ARM Cortex-M4de 32-bits, operando a una frecuencia de hasta 100 Mhz, con la carac-terıstica notable de incorporar una unidad de procesamiento flotante(FPU) en diferencia de Cortex-M inferiores. Entre otras caracterısti-cas de interes se tiene 2 memorias de alta velocidad (128Kbytes dememoria flash y 32 Kbytes de SRAM), ademas de 3 timers de 16 bits,timer particular de PWM para control de motores y varias decenas deGPIOS. Como interfaces de comunicacion disponemos de varias inter-faces USART y SPI, suficientes para el sistema del proyecto [28].

Figura 3.3: Caracterısticas del microcontrolador STM32F410

La empresa ST facilita tambien boards de prototipado que se usaranen los primeros pasos del proyecto.

3.2. SISTEMAS DE COMUNICACION 23

3.2. Sistemas de comunicacion

Con la finalidad de intercambiar informacion entre sistemas electroni-cos embebidos, ambos dispositivos han de compartir un protocolo decomunicacion comun. A lo largo de los anos se han definido cientos deprotocolos para el intercambio de datos, los cuales pueden clasificarseen dos categorıas: serial y paralelo [29].

En las transferencias en paralelo, cada bit del mensaje tiene supropio camino y el mensaje se transmite de una vez (figura 3.4). Estoquiere decir que un mensaje de n bits se transmite en paralelo median-te n caminos conductores separados. En una transmision serie, cadabit del mensaje se envıa en secuencia, de uno en uno. Este metodonecesita utilizar una o dos lıneas para las senales (figura 3.5).

La transmision en paralelo es mas rapida pero necesita muchos hi-los, usada sobretodo en distancias cortas y cuando la velocidad esimportante. La transmision serie es mas lenta pero menos cara puestoque solamente necesita un conductor [30].

Figura 3.4: Comunicacion en paralelo


Figura 3.5: Comunicacion en serie

Serial sıncrono y asıncrono

Se puede realizar una segunda clasificacion entorno a las interfacesde comunicacion: sıncrono y asıncrono.

Una interfaz serial sıncrona siempre empareja las lıneas de datoscon una senal de reloj, de forma que todos los dispositivos con estainterfaz comparten un mismo reloj. Ejemplos de interfaces sıncronasson SPI e I2C.

La forma asıncrona implica que los datos son transferidos sin laayuda de un reloj, por lo que este metodo minimiza el cableado y pi-nes de entrada/salida requeridos, pero requiere un punto extra paramantener la fidelidad al transmitir y recibir datos [29]. Un ejemplo deinterfaz asıncrona es UART, que se revisa en mayor detalle a conti-nuacion.

3.2.1. Modulacion por Ancho de Pulso

La modulacion por ancho de pulsos (PWM) de una senal es unatecnica en la que se modifica el ciclo de trabajo de una senal periodicasenoidal o cuadrada, para transmitir informacion a traves de un canalde comunicaciones o para controlar la cantidad de energıa que se envıaa una carga. En la figura 3.6 se puede observar una onda cuadradacon un ciclo de trabajo variable D.

En las aplicaciones con motores paso a paso, el PWM es la senalque controla los pasos del motor, que varıan en funcion del ciclo detrabajo (tambien denominado duty cicle).

3.2. SISTEMAS DE COMUNICACION 25

Figura 3.6: Senal PWM de onda cuadrada y ciclo de trabajo D

3.2.2. Receptor-Transmisor Asıncrono Universal

La interfaz UART se implementa con un hardware de comunicacio-nes usado para la transferencia de datos entre dispositivos, de formaserial. Al no tener senal de reloj y para mantener la robustez en lacomunicacion y reducir la intervencion de software durante la transfe-rencia de datos, este hardware soporta las interrupciones para trans-mision y recepcion, almacenamiento en FIFOs (buffering), y deteccionde errores.

La transmision se inicia con un bit de inicio (figura 3.7) y cuandose escribe un caracter en el buffer de transmision TX, informacion quese transmite inmediatamente si es el primer bit, o el anterior bit se halimpiado del buffer. Si el buffer contiene datos previos, el dato salien-te es mantenido hasta que la transmision finalice. Cuando los datosfinalizan, se envıa un bit de parada [31].

Figura 3.7: Comunicacion por interfaz UART

3.2.3. Interfaz de Perifericos Serie

Con la interfaz SPI, los dispositivos se comunican en un entornomaestro-esclavo, donde el maestro inicializa la comunicacion, y el es-clavo es controlado por el maestro a traves del pin SS (Slave Select).Ejemplos de uso de interfaz se encuentran en memorias EEPROM,drivers de pantallas, convertidores A/D y en la mayorıa de los micro-controladores.


Figura 3.8: Ejemplo de comunicacion por interfaz SPI

Si el dispositivo se configura como maestro, proporciona y controlala senal de reloj SCK que rige la transmision, y los esclavos no pue-den alterarla. Mientras los datos salen del maestro, simultaneamenteentran datos. Para comenzar la comunicacion, el maestro manda lasenal de reloj, y en cada pulso se envıa un bit de datos a traves del pinSDO o MOSI. Al mismo tiempo recibe datos por el pin SDI o MISO.Cuando el paquete de bits fijado finaliza, el maestro deja de enviar lasenal de reloj, y se desactiva el pin SS [32]. En la figura 3.8 se reflejaun ejemplo de funcionamiento.

3.3. CONTROL DE MOTORES 27

3.2.4. Circuito Interintegrado

El protocolo I2C es una interfaz de comunicacion bidireccionalmaestro/esclavo entre cualesquiera dispositivos que lo soporten. Es-tos dispositivos se conectan mediante un bus de 2 cables, permitiendomultiples maestros comunicarse con multiples esclavos.

El bus del protocolo I2C se comprime en las lıneas Serial Clock(SCL) y Serial Data (SDL). La senal de reloj generada por el dis-positivo maestro se envıa a traves de la lınea SCL para controlar latransmision de datos. La lınea SDA transfiere los datos recibidos/en-viados por el maestro/esclavo (figura 3.9). Ambas lıneas requieren unaresistencia pull-up en conexion de colector abierto.

Figura 3.9: Envıo de un mensaje con el protocolo I2C

3.3. Control de motores

3.3.1. Manipulacion del paso o Microstepping

Este metodo de control aplicado a los motores paso a paso se uti-liza en aplicaciones en las que posicionamiento de alta precision ybajas vibraciones y ruido son necesarios, lo que implica que la ondade corriente de las bobinas se asemeje lo maximo posible a una ondasinusoidal perfecta. Un motor paso a paso de dos fases se controla me-diante dos ondas sinusoidales desfasadas 90 grados.

Todos los posibles modos de microstepping se basan en el modelo deonda sinusoidal ideal, ajustando mediante pequenos picos en la onda(granulosidad), donde a menor tamano de los picos, mayor precision.


El paso completo (Full Step) es el mayor y consiste en la division en 90grados de la onda. El paso medio (Half Step) representa la mitad delanterior, y se va dividiendo sucesivamente para un obtener un mayornumero de pasos (figura 3.10).

Este metodo se utiliza para incrementar la resolucion de la posiciondel rotor del motor, y reducir la vibracion y el ruido en las operacionesdel motor [33].

Figura 3.10: Generacion de microstepping con diferentes divisiones

3.3.2. Modos de decaıda o Decay Modes

Cuando una bobina del motor se apaga, mediante el PWM, la co-rriente a traves de esta bobina comienza a caer hasta que alcanza elvalor 0, o hasta que la bobina se energice de nuevo. La velocidad ala que la corriente decae depende de la configuracion del puente en Hen ese instante. Los diferentes metodos de decay se denominan decaymodes [19].

Existen varios tipos de decay modes como se aprecia en la figura3.11, entre ellos:

Fast Decay: este modo se activa cuando el voltaje a traves dela bobina que se esta desenergizando, se revierte, lo que produceuna caıda rapida que da nombre a este modo.

3.3. CONTROL DE MOTORES 29

Slow Decay: se activa cuando se realiza un corto en la bobinadel motor. La caıda en este caso es mucho mas lenta dado que nohay voltaje aplicado a la bobina.

Figura 3.11: Diferentes flujos de los decay modes en el puente en H

Estos dos modos pueden a su vez ser usados de dos formas diferen-tes:

Fixed Decay: se fija un decay mode de entre los posibles parael controlador, para todas las veces.

Alternate Decay: el controlador puede usar dos modos diferen-tes y alternar entre ellos en el momento adecuado.


3.4. Controlador DRV8711 de TI

Este dispositivo es un controlador de motores paso a paso que haceuso de MOSFETs de canal N externos para el control de un motorpaso a paso bipolar, o dos motores de CC con escobillas (figura 3.12).Tiene integrado un indexador de microstepping con capacidad paramodos de paso desde Full Step hasta paso de 1/256.

El control del driver se simplifica con una interfaz STEP/DIR ogeneracion de PWM. Con la interfaz SPI se programa el controlador,accediendo a configurar parametros como corriente de salida, torque,modo de pasos, decay mode, y deteccion de parada. El controladortambien esta provisto de apagados internos en prevision de: proteccioncontra sobrecorriente, proteccion de cortocircuito, falta de tension, ysobrecalentamiento. Estas condiciones de error se indican a traves delpin FAULTn, e informacion mas detallada es enviada a traves de lainterfaz SPI.

Figura 3.12: Esquematico del sistema controlador con DRV8711

3.5. SOFTWARE DE DESARROLLO 31

3.5. Software de desarrollo

Durante el desarrollo del proyecto se usan diferentes herramientas,manteniendo siempre la tonica de un software de licencia libre o comomınimo de uso gratuito (como softwares de prueba o demos, algo quese puede permitir dado el alcance del proyecto).

3.5.1. IDEs

Atollic TrueSTUDIO

Esta es la herramienta principal de trabajo en la que se implemen-ta el codigo firmware en lenguaje C. El entorno de trabajo incluye elcompilador de ARM y la opcion de debug, que facilita el trabajo a lahora de afrontar errores, pudiendo comprobar registros en tiempo deejecucion.

Este software es de pago pero la version gratuita permite trabajarhasta un numero de lıneas de codigo aceptable para el proyecto.

Figura 3.13: Logo del IDE Atollic TRUEStudio

STM32CubeMX

Este software tiene la finalidad de facilitar el trabajo en el desa-rrollo. Genera un codigo de inicializacion en C para la IDE deseada,en funcion del nucleo o board usado en el proyecto (contiene la in-formacion de la mayorıa de los dispositivos de STM32), presentadouna interfaz grafica interactiva de los pines de microcontrolador, y uncontrol maximo de configuracion de parametros (configuracion de in-terfaces, frecuencias de trabajo, consumo de potencia, definicion depines, etc.) [7].


Figura 3.14: Logo del software CubeMX de STM32

Atom

Atom (figura 3.15) es un editor de texto libre y codigo abierto congran soporte de extensiones y multilenguaje, lanzado bajo una licenciade MIT [34].

En este proyecto se usa para el diseno de un terminal personalizadopara el controlador de motores, implementado en Python, aprovechan-do la versatilidad y sencillez de implementacion de este lenguaje.

Figura 3.15: Logo de Atom

3.5.2. Terminales de comunicacion

Estos programas permiten una interaccion completa a traves delpuerto serial, ya sea para obtener informacion de datos binarios ocaracteres, facilitando el trabajo de comunicacion con el microcontro-lador. Durante el proyecto se hace uso de Realterm y Putty, ambosprogramas gratuitos.

Capıtulo 4

Desarrollo del proyecto

En este capıtulo se expone el hilo de trabajo, desde una pequenaintroduccion de los componentes utilizados y su disposicion, pasandopor el desarrollo de firmware, y su implementacion en un hardwareobjetivo, cuyo diseno no es parte del proyecto, finalizando con unaaplicacion en sistema real (maqueta).

4.1. Introduccion

En el presente proyecto se disena e implementa un sistema contro-lador de motores paso a paso, cuyos elementos nucleo seran el micro-controlador, el driver para motores, y el motor en sı. En este casoy de forma mas concreta, se usa un nucleo de STM32 en comunicacioncon el DRV8711 de Texas Instruments, y diversos motores hıbridos deWantai Motor.

La primera etapa del proyecto esta centrada en el prototipado yen el desarrollo de firmware, haciendo uso de los boards que ponen adisposicion los fabricantes especialmente para este proposito.

Posteriormente se hace uso de un hardware objetivo con todos loselementos, y se incluye en una carcasa protectora disenada en softwareCAD e impresa con PLA (impresion 3D).

4.1.1. Prototipo del sistema

Siguiendo la estructura comentada, comenzamos planteando el sis-tema haciendo uso de boards.

34 CAPITULO 4. DESARROLLO DEL PROYECTO

Figura 4.1: El board nucleo F303K8

Como microcontrolador usamos el board nucleo F303K8 (figura4.1) que contiene un microprocesador ARM Cortex-M4 brindandonoslas prestaciones necesarias para el proposito del proyecto, ya comenta-das en el capıtulo de Fundamentos Generales. Como ventajas anadidasdel uso del board [7] destacamos:

Placa de desarrollo de 32 pines facilitando el uso de protoboard.

Soporte para diferentes interfaces vıa USB, destacando comuni-cacion serial y puerto de programacion y depuracion.

LEDs de comunicacion, energıa y usuario.

Boton push para reset.

Soporte para diferentes IDEs.

Para el driver de motores, Texas Instruments facilita una placa dedesarrollo que integra el DRV8711 (figura 4.2) elegido, especialmen-te disenado para motores paso a paso, pero que tambien puede serreoptimizado para motores CC de doble escobilla [35].

4.1. INTRODUCCION 35

Figura 4.2: BOOST-DRV8711 de TI

Este empaquetado incluye:

El driver DRV8711.

Cuatro MOSFETS CSD88537ND que forman el puente en H parael control del sistema.

Interfaz SPI para configuracion del driver e informe de estado.

Indicadores LED para stall y fault provocado por el motor.

Proteccion contra sobrecorriente, subvoltaje, lımite de tempera-tura y deteccion de stall.

Soportes para pines en placa protoboard.

Respecto a los motores paso a paso, se escoge el Nema 17 parael prototipado, mas pequeno y portable, el Nema 23 (figuras 4.3 (a)y (b)) que sera el que se use posteriormente en el sistema de control,con mayores prestaciones.


(a) Nema 17 (b) Nema 23

Figura 4.3: Motores paso a paso Wantai Motors

4.1.2. Pinout y conexion de los componentes

El controlador gestiona las comunicaciones con: el driver, a travesde interfaz SPI y STEP/DIR, estando este a su vez conectado almotor; y usuario/terminal mediante la interfaz UART, el cual inter-acciona con el controlador por comunicacion serial (figura 4.4).

Figura 4.4: Diagrama de comunicacion del sistema

Respecto a la interfaz SPI, se considera al microcontrolador co-mo maestro y al driver como esclavo, y para la comunicacion entreambos se necesitan cuatro canales:

SCK: reloj del Maestro, que sincroniza los bits transmitidos yrecibidos.

MOSI: transmision de datos Maestro-Esclavo.

MISO: recepcion de datos Esclavo-Maestro.

SS/CS: seleccion de esclavo/chip.


Figura 4.5: Pinout del Nucleo-F303K8, canales SPI resaltados

Figura 4.6: Pinout del Boost-DRV8711, canales SPI resaltados

Los respectivos pines para estos canales se encuentran en el pinoutde ambos (resaltados en las figuras 4.5 y 4.6), resultando la conexionentre ellos como se describe en la tabla 4.1:


Tabla 4.1: Conexiones SPI

F303K8 DRV8711SCK SPI1 SCLK SCLKMOSI SPI1 MOSI SDIMISO SPI1 MISO SDO

SS SPI1 SSEL SCS

La interfaz STEP/DIR se usa para controlar la velocidad y el sen-tido del motor, siendo STEP un PWM generado por el controladoren el que cada flanco propicia el paso del motor, y DIR un GPIO quecambia el sentido dependiendo de su valor discreto. Se usa entonces unpin en el que se activa un timer del micro para generar el PWM, y unpin activando GPIO para DIR. Se eligen los pines PA0 y PA1 (figura4.5), que se conectan respectivamente a STEP/AIN1 y DIR/AIN2del Boost (figura 4.6).

El cableado de las bobinas del motor quedan definidos por las fa-ses de las mismas, para este caso de prototipado el Nema 17 tenemoscuatro cables, dos por bobina (figura 4.7) que se conectan al puertoJ5 del DRV (Motor Outputs en la figura 4.6).

Figura 4.7: Los cuatro hilos del motor paso a paso bipolar


En cuanto a la interfaz UART, queda directamente accesible me-diante el puerto Micro USB que proporciona el board.

Finalmente, se igualan ambos dispositivos driver y controlador enterminos de energıa, conectando ambas patillas de 3.3V y tierra (pati-lla GND). En el puerto J4 del DRV (Motor Supply), se conectan loscables de la fuente de alimentacion. La imagen 4.8 refleja el prototipodel sistema conectado.

Figura 4.8: Sistema prototipo conectado


4.2. Desarrollo de firmware

Para el desarrollo de firmware se usa el lenguaje de programacionC en el entorno de desarrollo Atollic TrueSTUDIO, en cuya versiongratuita permite hacer uso de sus herramientas sin estar al completo,pero suficientes para el proyecto. Este entorno incluye el compiladorgcc-arm de GNU (Open Source) que permite el ensamblado de codigopara cualquier procesador ARM.

Para inicializar el codigo se hace uso del software CubeMX que pro-porciona la misma empresa ST, desde la que se activan los perifericosdeseados y su configuracion, explicados mas adelante. Una vez confi-gurado, se genera el codigo de inicio con los handlers (manejadores) decada periferico. Estos manejadores son creados sobre la librerıa HALde ST, que permite una abstraccion hardware sin hacer uso directo delibrerıas de nivel bajo como CMSIS o ST-Peripheral (figura 4.9), ysiendo su implementacion al mismo tiempo relativamente sencilla.

Figura 4.9: Comparativa entre librerıas de abstraccion hardware

4.2. DESARROLLO DE FIRMWARE 41

4.2.1. Estructura funcional

Para un diseno modular del firmware, se ha dividido el codigo enelementos que requieren de diferente comunicacion entre ellos. En lafigura 4.10 se representa la estructura planteada:

Figura 4.10: Componentes en el firmware del sistema


Diferenciando entre funciones principales se destacan:

Parser: Se encarga de la parte receptora en la comunicacion conel exterior del sistema, como una terminal/usuario u otros dispo-sitivos, a traves de las interfaces SPI y UART. Analiza los bytesentrantes para ejecutar un comando, siempre en caso de ser vali-do.

Data Parser: En caso de que Parser haya recibido un comandoacompanado de un valor numerico (set de velocidad, lectura deregistro especıfico, etc.), esta funcion almacena el valor en losregistros sombra.

Parser Response: Es la parte transmisora de la comunicacion,se ejecuta tras una peticion de usuario con informacion del co-mando o del estado interno del sistema.

STT o Maquina de Estados: Se encarga de actualizar el es-tado del sistema ante eventos de cambio. Tambien gestiona elpaso de los valores de los registros de sombra a activos, una vezverificados.

Controller: Gestiona la interfaz STEP/DIR, controlando el PWMpara la velocidad del motor y un GPIO para el sentido de este,segun el estado actual del sistema.

Driver Interface: Controla el acceso a los registros y la con-figuracion interna del DRV, mediante GPIO e interfaz SPI, enfuncion del comando o estado actual.

Como se puede observar en la figura, existe un duplicado en losregistros diferenciando entre registros sombra y registros activos,con el proposito de una verificacion previa a la modificacion de va-lores que puedan ser erroneos y afecten sensiblemente al controladoro al driver. Este mecanismo esta gestionado por el Parser Response(escritor en los registros sombra) y el STT (verificador y escritor deregistros activos).


4.2.2. Inicializacion con STM32CubeMX

Este software permite generar un codigo de inicio del firmware conla configuracion deseada, inicializando los manejadores de los periferi-cos, que para el prototipado son: UART, SPI, GPIOs y TIM (timerpara el PWM). Al configurar los perifericos, el modelo activa las pa-tillas correspondientes del microcontrolador, notificando su activacioncon color verde (figura 4.11).

Figura 4.11: Patillas para comunicacion UART (azul) y SPI (rojo) en el nucleoF303K8

Para la interfaz SPI (periferico SPI1) interesa una configuracionFull-Duplex Master, para una transmision bidireccional entre micro-controlador (maestro) y driver (esclavo), sacando el maximo partidoa este ultimo. Para la interfaz UART (periferico USART2), se usa elmodo asıncrono.


Se dispone de varios timers en el microcontrolador, cada uno deellos con cuatro canales PWM. Se activa el TIM2 con el canal 1 (pa-tilla PA0, STEP en figura 4.11).

Por ultimo, se activan los GPIO haciendo click en la patilla desea-da y seleccionando su funcion (ejemplo 4.12).

Figura 4.12: Patilla PA2

El resto de configuraciones son accesi-bles en la pestana Configuration, en laque fijaremos las siguientes caracterısti-cas:

Periferico UART:

Ratio de Baudios: 115200 Bits/s.

Tamano de palabra: 8 bits.

Paridad: Ninguna.

Bits de stop: 1 bit.

Periferico SPI:

Tamano del paquete de datos: 16 bits (necesario para la comuni-cacion con el driver, explicado mas adelante).

Primer bit: MSB (big-endian).

Preescalador: x64.

Formato: Motorola, reloj normalmente bajo y flanco de subida(CPOL = 0, CPHA = 0).

Periferico TIM:

Preescalador: x64.

Perıodo y modo del contador: 300, en modo Up.


Para el controlador final se implementara mas adelante el uso DMA(Direct Memory Access) en varios perifericos, lo que permitira una ma-yor concurrencia en la ejecucion del codigo en tiempo real.

Una vez terminada la configuracion, se genera automaticamente elcodigo main con las variables de tipo estructura (handlers) y susrespectivas funciones de inicializacion, mas las del reloj interno, yel manejador de errores:

#include "stm32f3xx_hal.h"

/∗ Handlers ∗/SPI_HandleTypeDef hspi1;TIM_HandleTypeDef htim1;UART_HandleTypeDef huart1;

/∗ Init functions ∗/void SystemClock_Config(void);void Error_Handler(void);static void MX_GPIO_Init(void);static void MX_SPI1_Init(void);static void MX_TIM1_Init(void);static void MX_USART1_UART_Init(void);

void HAL_TIM_MspPostInit(TIM_HandleTypeDef *htim);

int main(){}

A partir de ahora y para simplificar la lectura del proyecto, se deno-mina al codigo de cabecera anterior como codigo de inicializacion.

Primera prueba (blink test)

Una vez configurado el espacio de trabajo para el firmware, se rea-liza un codigo de test para comprobar su correcto funcionamiento.En este caso y siguiendo una prueba clasica, se realiza un Blink Test(parpadeo intermitente) con el led de usuario del board. Se puede ha-cer uso de las funciones del HAL acudiendo al documento que pone adisposicion ST (User Manual HAL Programming).


El codigo principal se implementa como sigue:

/∗ Codigo de inicializacion ∗/int main(){

/∗ Llamada a funciones de inicializacion ∗/while(1){HAL_GPIO_WritePin(GPIOB,GPIO_PIN_3,GPIO_PIN_SET);HAL_Delay(500);HAL_GPIO_WritePin(GPIOB,GPIO_PIN_3,GPIO_PIN_RESET);HAL_Delay(500);

}}

Como se puede observar, las funciones del HAL tienen parametrosintuitivos y por lo general se suele pasar el handler del periferico enuso como parametro por referencia. En este caso, al hacer uso de losGPIOs no es necesario pasar el handler, y solo basta indicar el regis-tro en memoria GPIO, el puerto en el que se escribe, y el valor que sequiere escribir.

En los siguientes subapartados se expone en mayor detalle la im-plementacion de los diferentes modulos.

4.2.3. Main

El modulo principal es el menos cargado en codigo, pero el masimportante ya que ejecuta el ciclo de trabajo.

Al codigo de inicializacion generado previamente por el softwareCubeMX se le incluye los modulos desarrollados para hacer uso de susfunciones:

#include "Parser.h"#include "STT.h"#include "DRV8711.h"

Y la estructura del codigo principal es simple: una vez inicializadoslos modulos, el puerto serial se queda a la escucha con un buffer de unbyte en una funcion con interrupcion activa.


/∗ Codigo de inicializacion ∗/void main(){

/∗ Llamada a funciones de inicializacion ∗/

ParserInit();STTInit();DRVInit();

HAL_UART_Receive_IT(&huart1,parser.byte,1);}

Cuando llega el byte, salta el callback de la funcion que contiene elflujo de trabajo principal, finalizando con la escucha serial de nuevo yrealizando ası un bucle.

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart){

command = Parser();

if(command){

//CicloParserData(command);status = STT(command);DriverInterface(command);DRVController(command);

//ResetParserReset();

}

//Escucha serialHAL_UART_Receive_IT(&huart1,parser.byte,1);

}

El trabajo de las funciones encapsuladas en este callback, se explicaen los siguientes modulos.


4.2.4. Modulo Parser

Este modulo es responsable de la entrada y salida de comunica-ciones con el exterior del sistema. Para su implementacion, se crea unarchivo de cabecera con su mismo nombre (Parser.h) el cual contienelas constantes, variables y declaracion y definicion de las funciones afi-nes. Es necesario incluir los datos principales, alojados en el moduloDRV (DRV8711.h), y se necesita declarar el handler principal, quesera el de la interfaz UART, para transmision y recepcion de informa-cion. Ası pues, las primeras lıneas de codigo de este modulo quedancomo sigue:

#include "DRV8711.h"extern UART_HandleTypeDef huart1;

Los manejadores son variables privadas del propio main del codigo yno son accesibles desde otros archivos de cabecera, por ello se hace usode extern (busca en el resto del codigo la referencia a esa variable).

Las variables principales de este modulo se encuentran en la es-tructura parser t y son el nucleo del analisis sintactico. Entre estasvariables se destacan:

typedef struct parser_t{char byte;char response[RESPONSE_SIZE];char string[BUFFER_SIZE];char number[BUFFER_SIZE];//...

};

La variable char byte es la entrada al parser: cada caracter intro-ducido se analiza y se introduce el buffer string, siempre que seanletras. Si el usuario introduce valores numericos, entonces se guardanlos caracteres en el buffer number, para un posterior conversion altipo de variable requerido. El almacenamiento en un buffer u otro vie-ne precedido por el caracter ‘:’, siendo por defecto el buffer de tipostring. Un caracter ‘;’ finaliza la recepcion de bytes para su posterioranalisis.

El diagrama de la figura 4.13 expresa mejor la relacion entre estasvariables:


Figura 4.13: Flujo del analisis sintactico byte a byte

Por ultimo, en buffer response se carga la informacion que se quie-re transmitir al usuario por el puerto serial. Este buffer es ampliamenteusado por diferentes modulos.

Funciones del modulo

Las funciones que componen este modulo son:

ParserInit: encapsula la inicializacion de todas las variables quelo requieren, poniendo a 0 diferentes contadores, preparando eltipo de analisis sintactico de string, y borrando la memoria de losbuffers. Esta funcion se llama al comienzo del main junto con elresto de inicializaciones.

void ParserInit(){parser.str_counter = 0;parser.num_counter = 0;parser.type = STRING;memset(parser.string,NULL,BUFFER_SIZE);memset(parser.number,NULL,BUFFER_SIZE);

}

Parser: esta es la funcion nucleo del modulo, en la que se anali-zan los bytes entrantes para retornar un comando valido para elsistema. Para ello se realiza un if-else de parser.byte, realizando


el flujo de analisis reflejado en la figura 4.13, para un posterioranalisis del comando con un switch-case sobre parser.string. Semuestra a continuacion el esqueleto de la funcion, con algunos delos posibles casos:

int Parser(){short command;if(parser.byte == ’;’){ /∗Fin de comando∗/switch(parser.string[0]){case ’M’:return COMM_MOVE;

break;//...case ’S’:return COMM_STOP;

break;//...default:ParserResponse("COMANDO INVALIDO\n\r");return COMM_NONE;

break;}

}else if(parser.byte[0] == ’:’){ /∗Separacion entre

Comando y Dato (String y Number)∗/parser.type = NUMBER;return 0;

}else { /∗Mientras no haya final de comando, se

guarda cada byte en buffer∗/if(parser.type == STRING){parser.string[parser.str_counter++] =

parser.byte;}else if(parser.type == NUMBER) {parser.number[parser.num_counter++] =

parser.byte;}


return 0;}

}

Al realizar un post-incremento de las variables contador auxiliares(str counter y num counter) en el indexado del buffer, los bytesse van almacenando progresivamente.

ParserData: esta funcion extrae los datos de parser.numberpara almacenarlos en los registros sombra de las diferentes varia-bles, en funcion del comando en ejecucion. Se muestra el ejemplode implementacion de los comandos MOVE y GET:

void ParserData(int command){ /∗Extrae datos delos comandos∗/switch(command){case COMM_MOVE:sscanf(parser.number," %d",&shadow_data.speed);

break;case COMM_GET:sscanf(parser.number," %d",&shadow_data.reg);

break;//...default:ParserResponse("DATOS INVALIDOS\n\r");

break;}

}

ParserResponse: recoge un string pasado como parametro y lotransmite por serial a traves de interfaz UART. Para ello se haceuso del handler pasandose por referencia a la funcion del HAL.

void ParserResponse(char *arg){int n;n=sprintf(parser.response,arg);HAL_UART_Transmit(&huart1,arg,n,400);

}


Comandos de usuario

El protocolo se disena para un manejo sencillo por parte del usuario,comenzando por el comando, y continuando por los valores numericosque se requieran para este, siguiendo un relacion de mas general amas particular, en caso de requerirse varios. Como se ha indicado pre-viamente, los comandos estan separados de los valores por ‘:’, y parafinalizar el mensaje, se escribe ‘;’. Los comandos que se han definidopara el manejo del controlador se listan a continuacion:

MOVE; /∗ Arranque del motor velocidad por defecto ∗/MOVE:SPEED; /∗ Se establece velocidad ∗/MOVE:SPEED:STEPS; /∗ Establece velocidad y pasos ∗/

STOP; /∗ Parada del motor ∗/

DIR; /∗ Cambio de sentido ∗/RIGHT; /∗ Sentido horario ∗/LEFT; /∗ Sentido antihorario ∗/

GET; /∗ Get del registro por defecto ∗/GET:REG; /∗ Registro deseado ∗/

SET:REG:SUB_REG:VALUE; /∗ Set del subregistro delregistro deseado ∗/

TEST; /∗ Arranque con variaciones de velocidad parael motor, a modo de test ∗/

Los registros son propios del DRV y el manejo de ellos permite un con-trol absoluto del motor. Se explica mas detalladamente en el moduloDRV.

Cualquier otro mensaje que se salga de este protocolo se resuelvecomo no valido, reiniciando la escucha serial.


4.2.5. Modulo STT (maquina de estados)

En este modulo se gestiona la maquina de estados del sistema. Cam-bia a un estado en funcion del comando entrante, siempre que este seavalido.

Se distinguen entre 4 estados, representados en la siguiente figura:

Figura 4.14: Maquina de estados del sistema

Ready: El motor esta listo para moverse.

Paro: El motor ha recibido el comando de pararse.

Marcha: El motor se mueve con normalidad.

Stall: El motor esta bloqueado ante el comando de moverse, porlo que se genera un estado de error.


El modulo STT lleva la funcion con el mismo nombre y que asig-na a una variable global de estado con su retorno, el correspondientesegun el comando. Respecto a la implementacion del codigo, se puederesolver con un simple switch-case:

int STT(int comm){switch(comm){case COMM_NONE: /∗No commands received∗/return STT_RDYSTP;break;

case COMM_MOVE:return STT_MOVE; /∗Changes state to Marcha∗/break;

//...default:break;

}}

Gestion de los registros

Este modulo tambien es el encargado de pasar los registros sombraa los registros reales, haciendo una pequena comprobacion, que se re-suelve en codigo con un analisis en rango del dato. Sigue un ejemplogenerico de implementacion:

/...if((shadow_data.value<=MAX_RANGE) ||

(shadow_data.value>=MIN_RANGE)){

data.value = shadow_data.value;

}/...


4.2.6. Modulo DRV

Este modulo gestiona toda la comunicacion e interaccion con elDRV8711, cuyas funciones principales son Driver Interface, que in-teracciona con el driver mediante SPI para manipular sus registros;y Controller, que se encarga de la interfaz STEP/DIR para el mo-vimiento del motor mediante un PWM y un GPIO respectivamente.

De la misma forma que se ha implementado Parser, el modulo co-mienza con los archivos de cabecera necesarios y los manejadores delmicrocontrolador, requiriendose todos para la funcionalidad del modu-lo:

#include "Parser.h"#include "STT.h"

extern SPI_HandleTypeDef hspi1; /∗ Comunicacion DRV ∗/extern TIM_HandleTypeDef htim1; /∗ Movimiento motor ∗/extern TIM_HandleTypeDef htim5; /∗ Encoder ∗/extern UART_HandleTypeDef huart1;/∗ Info serial ∗/

En este caso se hace uso de un segundo timer para una posteriorimplementacion de un encoder como realimentacion del sistema decontrol (apartado de variaciones sobre el prototipo).

Se declaran a continuacion las estructuras necesarias, a saber:

regs: estructura que contiene la variable value, que representa elvalor del paquete de 16 bits del registro en cuestion (se explica elfuncionamiento de los registros mas adelante).

data t: segunda estructura, contiene las variables principales pro-pias para el control del sistema (velocidad, pasos, direccion, etc.),ademas de una variable de tipo vector estructura de regs, dondese almacenan los datos de los registros.

Finalmente se declaran dos variables de esta ultima estructura: da-ta y shadow data.


/∗ Structures ∗/typedef struct regs{uint16_t value[DATA_SIZE]; /∗ Value in 16 bit pack ∗/

};

typedef struct data_t { /∗ Global Data ∗/int speed; /∗Velocidad del motor∗/uint32_t steps; /∗Pasos a dar∗/unsigned int mstp; /∗Valor del Microstepping∗/unsigned int period; /∗Periodo del timer para

control de velocidad∗/short dir; /∗Direccion del motor∗/struct regs registers[REG_SIZE]; /∗Vector de

registros del DRV∗/unsigned int reg; /∗Registro actual∗/unsigned int sreg; /∗Subregistro∗/unsigned int sreg_value; /∗Valor del subregistro∗/

};

/∗ Variables ∗/struct data_t data, shadow_data;

Antes de implementar los modulos principales, se crean las funcio-nes de inicio que son llamadas al comienzo del main.

DRVInitParams: inicializa las variables con un valor valido(aunque sea nulo), para el correcto inicio de las funciones.

DRVInit: realiza un set del registro de control (primer re-gistro) del DRV, habilitando el motor y fijando microstepping yganancia. Tambien se hace get de todos los registros internos delDRV para almacenarlos en la variable data.

void DRV_Init(){

DRV_InitParams();


/∗ Set Control Register ∗/DRV_SetRegister(REG_CTRL_ADDR,

SUBREG_CTRL_ENBL_pos,ENABLE); /∗ Enable Motor ∗/

DRV_SetRegister(REG_CTRL_ADDR,SUBREG_CTRL_MODE_pos,MSTP_256); /∗ Set Microstepping ∗/

DRV_SetRegister(REG_CTRL_ADDR,SUBREG_CTRL_ISGAIN_pos,3); /∗ Set Gain ∗/

/∗ Store Registers ∗/int rg;for(rg=0;rg<REG_SIZE;rg++){DRV_GetRegister(rg);

}}

Driver Interface

El protocolo de comunicacion con el DRV viene establecido en eldatasheet proporcionado por TI. Este protocolo define un paquete de16 bits como mensaje, ya sea para transmision o recepcion de infor-macion, dividido como se refleja en la siguiente figura:

Figura 4.15: Paquete de bits para la comunicacion con el DRV8711

Bit Read/Write: el MSB define si el paquete entrante al driveres de escritura o lectura (0 o 1 respectivamente).

Bits de direccion: estos bits definen el registro de entre 8 acce-


sibles (figura 4.16).

Bits de datos: los restantes 11 bits se dedican a los datos en sı.

La distribucion dentro de los bits de datos se refleja en la siguien-te figura, estando algunos de ellos reservados por el propio driver einaccesibles.

Figura 4.16: Mapa de los registros del DRV8711

Para la escritura de datos en los registros se implementa la funcionDRVSetRegister. Dado que los registros tienen a su vez subregistrosindependientes, se hace uso de mascaras para limpiar los bits delsubregistro a cambiar sin alterar el resto de la informacion del paquete(figura 4.17).

Figura 4.17: Manejo de mascaras para paquetes de 8 bits


El manejo de datos se realiza con una funcion macro que com-prueba el subregistro y genera la mascara. Sigue un ejemplo genericorepresentativo.

#define SUBREG_MASK_SET(_VAR_, _POS_)\

((_POS_ == SUBREG_A_X_pos) ? (_VAR_ =˜(SUBREG_A_X_mask + ADDR_RW_MASK)) :\

(_POS_ == SUBREG_A_Y_pos) ? (_VAR_ =˜(SUBREG_A_Y_mask + ADDR_RW_MASK)) :\

(_POS_ == SUBREG_A_Z_pos) ? (_VAR_ =˜(SUBREG_A_Z_mask + ADDR_RW_MASK)) :\

//...(_VAR_ = ˜(0x0 << 0)))

Desde DRVSetRegister se llama a esta macro en funcion del registroy se envıa el paquete de datos al driver por SPI, para lo cual, pone envalor logico alto el pin CS y se envıa el paquete (fig 4.18). Un valorlogico bajo en CS cierra la transmision.

Figura 4.18: Transmision del paquete de bits por SPI

Quedando la funcion de escritura como sigue:

void DRV_SetRegister(int reg, int subreg, int value){

uint16_t mask[DATA_SIZE];

switch(reg){case REG_CTRL_ADDR:CTRL_MASK_SET(mask[0], subreg);break;

//...}


/∗ Set del pin CS ∗/HAL_GPIO_WritePin(GPIOB, DRV_CS_Pin, GPIO_PIN_SET);

/∗ Se copia el valor actual en data ∗/DataCopy(DATA_SIZE, data.registers[reg].value,

TxData);

/∗ Mascara y escritura de datos ∗/TxData[0] = TxData[0] & mask[0];

TxData[0] +=(value << bit) +(WRITE<< BIT_RW) +(reg << BIT_ADDR);

/∗ Envıo del paquete ∗/HAL_SPI_Transmit(&hspi1, TxData, 1, 500);

/∗ Reset del pin CS ∗/HAL_GPIO_WritePin(GPIOB, DRV_CS_Pin, GPIO_PIN_RESET);

}

Para la funcion de lectura DRVGetRegister el funcionamientoes similar, pero en este caso se cambia el bit de RW a read, y no esnecesario el uso de mascaras, ya que simplemente se envıa el bit delectura y se guarda el paquete entrante en una variable:

void DRV_GetRegister(int reg){

/∗ Set pin CS ∗/HAL_GPIO_WritePin(GPIOB, DRV_CS_Pin, GPIO_PIN_SET);

/∗ Paquete en modo lectura ∗/TxData[0] =

(READ<< BIT_RW) + //Read bit(reg << BIT_ADDR);


/∗ Transmision y recepcion de datos ∗/HAL_SPI_TransmitReceive(&hspi1, TxData, RxData, 1,

1000);

/∗ Reset pin CS ∗/HAL_GPIO_WritePin(GPIOB, DRV_CS_Pin, GPIO_PIN_RESET);

/∗ Actualiza datos ∗/DataCopy(DATA_SIZE, RxData, data.registers[reg].value);}

Una vez definidas las operaciones de lectura y escritura, se imple-menta la funcion Interface que gestiona ambas en en base al comando:

void DriverInterface(int cmd){switch(cmd){case COMM_GET:DRV_GetRegister(data.reg);break;

case COMM_SET:DRV_SetRegister(data.reg, data.sreg,

data.sreg_value);break;

default:break;

}}

De esta forma, si se desean anadir futuras funciones de interaccioncon el driver resulta muy simple de implementar.

Controller

Esta funcion DRVController es mucho mas simple que la anteriory se encarga de la interfaz STEP/DIR y por tanto de gestionar lasfunciones que hacen uso de ella (Move, Stop, Dir, etc.). Para STEP,se genera un PWM cuyos pulsos sirven proporcionalmente para darlos pasos del motor, cuyas funciones de librerıa a usar son:


HAL_TIM_PWM_Start(HANDLER, CHANNEL);HAL_TIM_PWM_Start_IT(HANDLER, CHANNEL);HAL_TIM_PWM_Stop(HANDLER, CHANNEL);

La llamada a Start con interrupcion nos permite declarar una funcioncallback a la que se llama cada vez que se realiza un pulso. Para nuestrocaso dicha funcion sera:

void HAL_TIM_PWM_PulseFinishedCallback(HANDLER);

siendo de gran utilidad para la funcion Move, para realizar un recuentode los pulsos absolutos y relativos a cada movimiento, y establecer unposicionamiento.

Respecto a la interfaz DIR, la unica funcion relativa es de GPIO enla se establece un valor logico alto o bajo que define la direccion delmotor:

HAL_GPIO_WritePin(GPIOX, DRV_DIR_Pin, VALOR);

Ası pues, la funcion DRVController quedarıa:

void DRVController(int cmd){switch(cmd){case COMM_STOP:DRV_Stop();break;

case COMM_MOVE:DRV_Move();break;

case COMM_DIR:DRV_ToggleDirection();break;

case COMM_TEST:DRV_Test();break;

//...default:break;

}}

4.3. PCB Y CONTROLADOR FINAL 63

4.3. PCB y controlador final

Una vez implementada la parte funcional del software, se portaa una PCB que integra el microcontrolador, el driver y el resto deelementos necesarios.

4.3.1. PCB

Una vez realizadas las pruebas en el prototipo, se hace uso de unhardware objetivo disenado en el que se contengan todos los elemen-tos (driver, microcontrolador, puente en H, bus de comunicaciones,conector JTAG, etc.). Los modulos mas importantes son los del mi-croprocesador y el driver, y para cuya implementacion se acude a susrespectivos datasheet.

Como anadido, se encuentran diferentes puertos conectores: conec-tor de 4 entradas para las bobinas del motor, conector de 4 entradaspara la alimentacion del sistema, que se implementa con un pequenocircuito de proteccion; conector JTAG de 6 pines para la programa-cion de y debug del microcontrolador; y los pines para la comunicacionserial proporcionado por el bus de comunicaciones RS485.

Tambien se anade proteccion al sistema entero con un circuito bulkde condensadores (figura 4.19). El esquematico completo se puede en-contrar en el Anexo al final del documento.

Figura 4.19: Esquematicos del DRV8711 y del circuito Bulk


Layout

Para el layout (figura 4.20) del hardware objetivo tiene un disenopor planos, lo que mejora el comportamiento de los motores sin baja-das de tension. Los componentes estan pensados para soldarse por laparte superior de la placa.

Figura 4.20: Layout del diseno

Una vez fabricada la placa quedarıa:

Figura 4.21: Placa fabricada


Y con los componentes soldados:

Figura 4.22: Placa con los componentes soldados

Es necesario comentar que se ha anadido una resistencia extra (sepuede apreciar en el centro inferior de la figura 4.22) para el pull-updel pin de recepcion del SPI del STM32F4, dado que el pull-up tenıaun valor muy alto, lo que provocaba perdida de bits en la transmision.

4.3.2. Pinout del controlador

Entre los elementos fısicos (pines) del controlador para la comuni-cacion con el exterior del sistema, se tiene:

Conectores de energıa y bobinas del motor: se dispone enun lateral de dos conectores compactos de 4 entradas (figura 4.23),4 para la conexion de las bobinas del motor (en azul) y 2 paraVCC y GND (en rojo).


Figura 4.23: Pines de las bobinas del motor y VCC y GND

Pines JTAG: usado para la programacion y debug del nucleomicrocontrolador con un cable JTAG - USB (figura 4.24).

Figura 4.24: Pines de conexion JTAG


Pines de encoder, endstop y puerto UART: colocados enextremo lateral izquierdo (figura 4.25) estan los pines A y B pa-ra el encoder y VCC, SDL y GND para el endstop (en verde).Resaltado en morado estan los pines del puerto UART.

Figura 4.25: Pines del encoder, endstop y puerto UART

4.3.3. Carcasa protectora

Para proteger el controlador se ha disenado una carcasa en CADimpresa en 3D con PLA, mostrada en las siguientes figuras 4.26, 4.27y 4.28. Para la fijacion de las partes se ha disenado ejes y pasantes M3.


Figura 4.26: Pieza superior de la carcasa

Figura 4.27: Pieza inferior de la carcasa

Figura 4.28: Controlador con carcasa

4.4. MAQUETA DE APLICACION 69

4.4. Maqueta de aplicacion

Para aplicar el controlador a un sistema real, se ha disenado unapequena maqueta motorizada (figuras 4.29 y 4.30).

Figura 4.29: Diseno de la maqueta en CAD

Figura 4.30: Plano general de la maqueta


Esta maqueta consta de un raıl rectilıneo con uno de los soporteslaterales sensado con un final de carrera, y una guıa motorizada atraves de una correa y un NEMA 17, solidaria a un contrapeso paraun posterior ejemplo de control de pendulo invertido, todo ello ator-nillado sobre una tabla de madera de 36x19 cm.

Para la conexion del final de carrera o endstop (cables superioresgris, verde y blanco) y el encoder para el sistema de control del pendu-lo invertido (cables gris y blanco inferiores), se han usado los pines delcontrolador comentados en el apartado anterior Pinout del controla-dor (figura 4.31).

Figura 4.31: Conexiones del endstop y encoder

Para la comunicacion serial se conecta un convertidor generico UART- USB en los pines de comunicacion UART del controlador (figura4.32). Este chip permite el uso de esta interfaz a traves de un cableUSB.

4.4. MAQUETA DE APLICACION 71

Figura 4.32: Conexion del integrado de TI a los pines UART del controlador

En el siguiente capıtulo de este documento se pone en marcha lamaqueta con el controlador.

Capıtulo 5

Pruebas y resultados

En este capıtulo se exponen las pruebas realizadas con el contro-lador de forma independiente y posterior aplicacion a la maqueta, ylos resultados de dichas pruebas, previos a una breve discusion delconjunto.

5.1. Funcionalidades del controlador

En primer lugar se realizan pruebas con los comandos de usuariopara interaccionar con el driver, haciendo uso de la terminal serialRealterm.

Antes de las pruebas se configura la salida en ANSI para leer larecepcion serial y en modo Half Duplex para monitorizar lo que seenvıa y recibe. Se selecciona tambien el puerto correspondiente en laterminal (figura 5.1).

Figura 5.1: Configuracion en Realterm para las pruebas

74 CAPITULO 5. PRUEBAS Y RESULTADOS

5.1.1. Dinamica

Para mover el motor se hace uso del comando MOVE, en el quese puede introducir una velocidad y cantidad de pasos concretos omantener los valores por defecto. Para ello se envıa un string porUART siguiendo el protocolo (verde en la imagen).

El controlador responde con la confirmacion del comando (amarilloen la imagen). Este estado es permanente accesible con el comandoGET:8;.

El comando STOP funciona de la misma forma, generando el estadode READY.

5.1.2. Registros

El microcontrolador accede a los registros del driver a traves de lainterfaz SPI, y para su manipulacion se han implementado un settery getter, que se usaran de la siguiente forma:

SET:REGISTRO:SUBREGISTRO:VALOR;GET:REGISTRO;

El driver cuenta con 8 registros indexados del 0 al 7, cada uno consus subregistros particulares. Una vez enviado el comando, el contro-lador responde con la verificacion de la operacion.

En este caso se esta introduciendo un valor nulo al primer subre-gistro del registro 0, por lo que se deshabilita el motor (el motor dejade ejercer par para mantener la posicion), y se reduce el consumo depotencia, como se observa en la figura 5.2. De esta forma se puedeoperar con todos los registros del driver.

5.2. PRUEBAS EN MAQUETA 75

(a) Motor habilitado en driver (b) Motor deshabilitado en driver

Figura 5.2: Variacion del consumo al cambiar los registros del driver

Al hacer uso del getter, se obtiene el paquete de 16 bits del registrode forma que se puede comparar los valores con el datasheet del driver.Al estado del controlador se le otorga el valor 8 para el getter.

5.2. Pruebas en maqueta

Para hacer uso de la maqueta se considera un punto de partidainicial, posicion marcada por el endstop. A partir de ahı, cada pasoqueda registrado al implementar el callback del timer del motor, porlo que se lleva una cuenta de los pasos relativos y absolutos dados.Esta funcion sirve a su vez para detener el motor una vez se hayandado los pasos deseados, o si llega al final de la maqueta, seguridadimplementada por SW con una constante.

void HAL_TIM_PWM_PulseFinishedCallback(TIM_HandleTypeDef*htim){

/∗ Pasos absolutos ∗/data.abs_pulses += 1*data.dir*(MSTP_256/data.mstp);

/∗ Pasos relativos ∗/data.rel_pulses += 1;

/∗ Control de pasos o lımite maqueta ∗/if((data.rel_pulses >= data.steps) ||

(data.abs_pulses < MIN_PULSES) ||


(data.abs_pulses > MAX_PULSES)){__HAL_TIM_DISABLE(&htim1);data.abs_pulses -= 1 * data.dir;data.rel_pulses = 1;

}

Una vez implementado la funcion callback, se incluye en el codigouna funcion DRV Calib que lleve al motor hasta el punto de partidacada vez que inicie el sistema, para lo cual simplemente se lleva la guıade la maqueta a velocidad moderada y sin fijar pasos, hasta que entreen contacto con el endstop (figura 5.3), que se evalua con su GPIOcorrespondiente, y posteriormente se podra controlar el sistema.

void DRV_Calib(){/∗ Valores por defecto para iniciar movimiento y PWM ∗///...

HAL_TIM_PWM_Start(&htim1, TIM_CHANNEL_1);

/∗ Bloqueo hasta deteccion de endstop ∗/while(HAL_GPIO_ReadPin(GPIOB, nENDSTOP_Pin)){}

HAL_TIM_PWM_Stop(&htim1, TIM_CHANNEL_1);}

Figura 5.3: Aproximacion de la guıa al punto de origen

A partir de este punto se realizan de nuevo pruebas dinamicas.

5.2. PRUEBAS EN MAQUETA 77

Control de un pendulo invertido

Como ejemplo practico se incluye un codigo de control para man-tener el contrapeso de la maqueta en posicion vertical. Este codigoincluye principalmente un PID con el valor del encoder como sensorpara el sistema, con el que calibraremos el sistema variando las cons-tantes de las acciones de control (figura 5.4).

Respecto al controlador del motor, para ajustar el firmware se im-plementa una funcion DRV ChangeSpeed(int speed), cuyo parame-tro de entrada sera la velocidad con signo resuelta por el PID, quecontrolara la guıa de la maqueta. Esta funcion sera llamada cıclica-mente junto a la resolucion del PID.

Figura 5.4: Control del pendulo invertido con el controlador

Capıtulo 6

Conclusiones

6.1. Conclusion

En este proyecto se ha disenado e implementado el firmware delmodulo de movimiento para un controlador de motores con electroni-ca de bajo coste, con una puesta a punto en un hardware objetivo,cuyo diseno no ha sido parte del proyecto, para una posterior aplica-cion en sistema real.

Como se ha plasmado en el capıtulo de Estado del Arte, son nu-merosas las aplicaciones industriales de los motores paso a paso, sobretodo con el enfoque de precision en el movimiento que se ha tratado eneste trabajo. Sabiendo esto, los resultados son los esperados para unproyecto no innovador, con una respuesta del driver esperada median-te la comunicacion con el microcontrolador. Aunque tal vez sı habrıasido posible ahondar o exprimir mas las funcionalidades del nucleoARM abarcando mayor robustez en el ciclo de ejecucion en tiemporeal para reducir posibles fallos.

No cabe duda que es posible mejorar varios aspectos del proyecto,perspectiva posible gracias a lo aprendido durante el desarrollo de este,el cual ha aportado tanto a nivel academico como personal.

6.2. Desarrollos futuros

Dentro de la lınea del proyecto, caben destacar dos puntos amplia-mente extensibles:

Expansion del firmware: a pesar de estar implementados los

80 CAPITULO 6. CONCLUSIONES

comandos de usuario basicos, la estructura implementada permi-te la adicion de nuevos comandos que interaccionen con nuevosdatos requeridos: Tambien se puede ampliar el control a variosdrivers, con una previa modificacion en el codigo de seleccion dedriver en el comando en cuestion; ası como implementar el uso deotras interfaces para el sistema exterior (comunicacion con otrodispositivo a traves de SPI).

Desarrollo de una GUI : para completar el proyecto se podrıadisenar una interfaz de usuario guiada especıfica para el controlde motores y mas en concreto para el DRV8711, con un lenguajede programacion sencillo y orientado a objetos que permita lareutilizacion y mayor extension a otros controladores o drivers.

Bibliografıa

[1] MIT Computer Science and Artificial Intelligence Lab.www.csail.mit.edu. 2018.

[2] A. Trevennor. Practical AVR Microcontrollers. 2012.

[3] Stan Augarten. The Most Widely Used Computer on a Chip: TheTSM 1000. 1983.

[4] Computer History Museum. Oral History Panel on the Develop-ment and Promotion of the Intel 8048 Microcontroller. 2008.

[5] Hayashi Y. Tarui, Y. and K. Nagai. Electrically reprogrammablenonvolatile semiconductor memory. 1972.

[6] S. Marta Canel. Microcontroladores ARM de 32 bits. 2007.

[7] STMicroelectronics. www.st.com. 2018.

[8] E. R. Laithwaite. A History of Linear Electric Motors. 1987.

[9] A. Hughes and W. Drury. Electric Motors and Drives. Funda-mentals, types and applications 4th Edition. 2003.

[10] S. Nagamori. Permanent-Magnet and Brushless DC Motors.1985.

[11] Y. William H. Handbook of Small Electric Motors. 2003.

[12] M. McComb. Introduction to Stepper Motors. 2007.

[13] Richard Innes. Industrial Applications of Stepper Control Sys-tems. 1994.

[14] Liu L. Zhang, L. and J. Shen. Research on Stepper Motor MotionControl Based on MCU. 2017.

82 BIBLIOGRAFIA

[15] Microchip AN894. Motor Control Sensor Feedback Circuits. 2003.

[16] Microchip AN907. Stepping Motor Fundamentals. 2004.

[17] Jing X.D. Qi, F.Q. and S.Q. Zhao. Design of Stepping MotorControl System Based on AT89C51 Microcontroller. 2011.

[18] Wang Z. Wang, R. and L. Wang. Stepper Motor Control Basedon AT89S51 Microcontroller. 2015.

[19] Microchip AN1307. Stepper Motor Control with dsPIC DSC.2009.

[20] Microchip AN906. Stepper Motor Control using the PIC16F684.2004.

[21] Moussa Bendjedia. Position Control of a Sensorless Stepper Mo-tor. 2012.

[22] Rahaprian M.P. Vignesh Babu, S. and K.R Santha. SensorlessControl of Stepper Motor Using Extended Kalman Filter. 2013.

[23] S. Abdel Aziz and H. Awad. Development and Control of a SunTracking System based on Stepper Motor and 16f877a Mictrocon-troller. 2017.

[24] S. Marhraoui and A. Abbou. Solar MPPT for Stepper MotorDrive Using Industrials Applications. 2017.

[25] N. Jirasuwankul and C. Manop. A Lab-Scale Heliostat PositioningControl using Fuzzy Logic Based Stepper Motor Drive With MicroStep and Multi-Frecuency Mode. 2017.

[26] R. Toulson. Fast and Effective Embedded Systems Design. 2017.

[27] G Gridling and B. Weiss. Introduction to Microcontrollers. 2007.

[28] STMicroelectronics. STM32F410x Datasheet. 2018.

[29] SparkFun Electronics. Serial Communication. 2018.

[30] M. Morris Mano and C.R. Kime. Fundamentos de diseno logicoy de computadoras. 2005.

[31] Microchip TB3156. UART on 8-bit PIC Microcontrollers. 2017.

BIBLIOGRAFIA 83

[32] Microchip TB3157. SPI Communications on 8-bit PIC Microcon-trollers. 2017.

[33] Microchip AN822. Stepper Motor Microstepping with PIC18C452.2002.

[34] Atom. www.atom.io. 2018.

[35] Texas Instruments Incorporated. www.ti.com. 2018.

84 BIBLIOGRAFIA

Anexo: Esquematico de diseno delcontrolador

Se muestra a continuacion el esquematico de diseno completo, araız los datasheets proporcionados por los fabricantes, y de diferentesvaloraciones electronicas.

86 ANEXO: ESQUEMATICO DE DISENO DEL CONTROLADOR

1 1

2 2

3 3

4 4

DD

CC

BB

AA

Title

Num

berR

evisionSize

A4

Date:

20/11/2017Sheet of

File:C

:\Users\..\Steper_board.SchD

ocD

rawn B

y:

PC13

2

PC14/O

SC_IN

3

PC15/O

SC_O

UT

4

PA0

10

PA1

11

PA2

12

PA3

13

PA4

14

PA5

15

PA6

16

PA7

17

PB0

18

PB1

19

PB2

20

PB10

21

PB12

25

PB13

26

PB14

27

PB15

28

PA8

29

PA9

30

PA10

31

PA11

32

PA12

33

PA13

34

PA14

37

PA15

38

PB3

39

PB4

40

PB5

41

PB6

42

PB7

43

PB8

45

PB9

46

U1A

STM32F4

SWD

IOSW

CLK

SWO

SPI_DRV

_SCK

SPI_DRV

_MISO

SPI_DRV

_MO

SI

SPI_DEV

_SCK

SPI_DEV

_MISO

SPI_DEV

_MO

SI

RS485_R

XR

S485_TRIG

RS485_D

EV

RS485_TX

DRV

1_STEPD

RV1_D

IR

DRV

1_nSLEEPD

RV1_C

SD

EV1_C

S

DRV

_nSTALL

DRV

_nFAU

LT

DRV

_RESET

12

34

56

IDC

4

6Pos 1000mil

SPI_DEV

_SCK

SPI_DEV

_MISO

SPI_DEV

_MO

SID

EV1_C

SV

DD

GN

D

nSLEEP1

AIN

1_DIS

2

AIN

2_STEP3

BIN

14

BIN

25

nFAU

LT6

nSTALL

7

SPI_CLK

8

SPI_SI9

SPI_CS

10

SPI_SO11

RESET

12

GN

D13

GN

D14

GN

D15

GN

D16

GN

D17

GN

D18

BO

UT2

19B

OU

T220

BO

UT1

21B

OU

T122

VM

23V

M24

AO

UT2

25A

OU

T226

AO

UT1

27A

OU

T128

VM

29V

M30

GN

D31

GN

D32

GN

D33

GN

D34

GN

D35

GN

D36

CM

1

STP DRV

GN

D

GN

D

VC

CV

CC

VC

CV

CC

DRV

1_STEPD

RV1_D

IR

DRV

1_nSLEEP

DRV

1_CS

SPI_DRV

_SCK

SPI_DRV

_MISO

SPI_DRV

_MO

SI

DRV

_nSTALL

DRV

_nFAU

LT

DRV

_RESET

DRV

1_AO

2D

RV1_A

O1

DRV

1_AO

1

DRV

1_AO

2

DRV

1_BO

2D

RV1_B

O1

DRV

1_BO

1

DRV

1_BO

2

2 134

B1

4 row com

pat conector

DRV

1_AO

2

DRV

1_AO

1

DRV

1_BO

2

DRV

1_BO

1

VSS

23

VD

D24

VSS

35

VD

D36

VSS

47

VD

D48

VBA

T1

PH0_O

SC_IN

5

PH0/O

SC_O

UT

6

NR

ST7

VSSA

/VR

EF-8

VD

DA

/VR

EF+9

VC

AP_1

22

BO

OT0

44

PAD

49

U1B

STM32F4

C6

0.1uFC

70.1uF

C110.1uF

C8

0.1uFC

90.1uF

C10

0.1uFC

120.1uF

R1

10K

GN

D

GN

DG

ND

nRST

VD

DV

DD

VC

C

GN

D

VC

C

GN

D

GN

D

VD

D

Microcontroller regulator

Bulk capacitance

VIN

3

GN

D2

VO

UT

1U

2

UA

78L00

D2

PartD

3Part

32 1

D1

C4

0.1uFC

50.1uF

C1

C2

2 134

B2

4 row com

pat conector

Vin

12

34

56

JT1

JTAG

_6PIN

SWD

IOSW

CLK

VD

D

GN

D

SWO

nRST

NC

1

NC

2

NC

3

NC

4

VD

D5

TRG

6

RX

4857

TX485

8

DE

9

NC

10

NC

11

GN

D12

NC

13

NC

14

NC

15

NC

16

NC

17

NC

18G

ND

19A

20B

21ISO

_DE

22ISO

_TX23

ISO_R

X24

ISO_TR

G25

ISO_5V

26N

C27

NC

28N

C29

NC

30N

C31

NC

32N

C33

NC

34N

C35

NC

36C

M2

RS485_ISO

12

34

56

IDC

3

6Pos 1000mil

ABTRG

_ISO

12

34

56

IDC

2

6Pos 1000mil

ABTRG

_ISO

ISO_5V

ISO_5V

ISO_G

ND

ISO_G

ND

TRG

_ISO

AB

ISO_5V

12

34

56

IDC

1

6Pos 1000mil

VD

D

GN

D

ISO_G

ND

Vin

GN

DR

S485_RX

RS485_TR

IG

RS485_TX

RS485_D

EV

ENC

_BEN

C_A

12

34

56

IDC

5

6Pos 1000mil

VD

D

GN

D

ENC

_BEN

C_A

123

P1Header 3

ISO_G

ND

TX RX

TX RX

I2C1_SD

AI2C

1_SCL

I2C1_SD

AI2C

1_SCL

123

P2Header 3

123

P3Header 3

PWM

_1PW

M_2

PWM

_1

PWM

_2

5V5V

GN

D

GN

DVin1

GND2

Vout3

M1

P78Axx-0500

C3

0.1uFC

130.1uF

VS

R2

0R

GN

D

VC

C

VS

VC

CV

S

5V

D4

Green

R3

1K

GN

D

VD

D

Implementación de módulo de movimiento de motores paso a paso...

Documents

Transcript of Implementación de módulo de movimiento de motores paso a paso...