Implementación de un entorno de comunicación Bluetooth, basado en el módulo CC2650, para la transmisión del ritmo cardiaco

UNIVERSIDAD DE VALLADOLID ESCUELA DE INGENIERIAS INDUSTRIALES Grado en Ingeniería Electrónica Industrial y Automática Implementación de un entorno de comunicación Bluetooth, basado en el módulo CC2650, para la transmisión del ritmo cardiaco. Autor: Álvarez Urueña, Alonso Tutor: Pérez Turiel, Javier Ingeniería de Sistemas y Automática Valladolid, julio de 2021. 1 RESUMEN En el marco del desarrollo de una plataforma de rehabilitación neuromotora robotizada, se pretende incorporar la posibilidad de establecer comunicaciones inalámbricas (Bluetooth Low Energy). Para ello, se integra un módulo comercial CC2650 (TI) al dispositivo robotizado, que está basado en el microcontrolador TMS320F28069M (TI). Como primera fase de desarrollo, se plantea la transmisión del ritmo cardiaco por Bluetooth: el microcontrolador F28069M recibe las señales electrocardiográficas registradas mediante un módulo de Sparkfun basado en el AD8232, calcula el ritmo cardiaco mediante el algoritmo de Pan-Tomkins y lo transmite al módulo CC2650 mediante comunicación I2C para que este envíe dicha información mediante Bluetooth a otro módulo CC2650, el cual transmitirá el valor del ritmo cardiaco a otro microcontrolador F28069M. ABSTRACT Within the framework of the development of a robotic neuromotor rehabilitation platform, the aim is to incorporate the possibility of establishing wireless communications (Bluetooth Low Energy). To this end, a commercial CC2650 (TI) module is integrated into the robotic device, which is based on the TMS320F28069M (TI) microcontroller. As a first stage of development, the transmission of the heart rate via Bluetooth is proposed: the F28069M microcontroller receives the electrocardiographic signals recorded by a Sparkfun module based on the AD8232, calculates the heart rate using the Pan-Tomkins algorithm and transmits it to the CC2650 module via I2C communication so that it can send this information via Bluetooth to another CC2650 module, which will transmit the heart rate value to another F28069M microcontroller. PALABRAS CLAVE Bluetooth Low Energy, comunicación inalámbrica, microcontrolador, ritmo cardiaco y Texas Instruments. KEYWORDS Bluetooth Low Energy, wireless communication, microcontroller, heart rate and Texas Instruments. 2 3 ÍNDICE 1. Introducción y objetivos ........................................................................................ 9 2. Estado del arte ................................................................................................... 13 2.1. Introducción .................................................................................................... 13 2.2. LAUNCHXL-F28069M ..................................................................................... 17 2.3. LAUNCHXL-CC2650 ........................................................................................ 22 2.4. Protocolo de comunicación BLE .................................................................... 39 2.5. Protocolo de comunicación I2C ..................................................................... 56 2.6. Electrocardiograma (ECG) .............................................................................. 64 3. Desarrollo y programación del proyecto ............................................................ 71 3.1. Paso 1: F28069M_TX ..................................................................................... 71 3.2. Paso 2: CC2650_Peripheral_BLE .................................................................. 77 3.3. Paso 3: CC2650_Central_BLE ....................................................................... 85 3.4. Paso 4: F28069M_RX .................................................................................... 93 3.5. Tabla de conexiones del proyecto ................................................................. 96 3.6. Comprobación de resultados y captura del montaje final ........................... 97 4. Conclusiones .................................................................................................... 103 5. Bibliografía ....................................................................................................... 105 6. Anexos .............................................................................................................. 111 6.1. Cálculo resistencia pull-up para el bus I2C ................................................ 111 4 5 ÍNDICE DE ILUSTRACIONES Ilustración 1. Esquema del proyecto. ............................................................................. 9 Ilustración 2. Logo de ITAP. ........................................................................................... 11 Ilustración 3. Foto del dispositivo Trazein. .................................................................. 13 Ilustración 4. Foto del prototipo detector de ECG/EEG/EMG. ................................... 14 Ilustración 5. Foto del sistema de cuidado de la salud portátil desarrollado. .......... 14 Ilustración 6. Esquema de funcionamiento de RobHand. .......................................... 15 Ilustración 7. Un usuario realizando una terapia bilateral asistida por EMG con la plataforma robótica RobHand. ..................................................................................... 15 Ilustración 8. Microcontrolador LAUNCHXL-F28069M. .............................................. 17 Ilustración 9. Funcionamiento de los núcleos C28x y CLA dentro de la CPU ............ 18 Ilustración 10. Esquema de puertos y funcionalidades del microcontrolador. ........ 18 Ilustración 11. Code Composer Studio. ......... Ilustración 12. Energia. Ilustración 13. controlSUITE………………………………………… ................................................................... 21 Ilustración 14. Microcontrolador LAUNCHXL-CC2650 ................................................ 22 Ilustración 15. Esquema de puertos y funcionalidades del microcontrolador. ........ 23 Ilustración 16. Diagrama de bloques del microprocesador. ...................................... 24 Ilustración 17. “Pinout” del microcontrolador (I). ........................................................ 26 Ilustración 18. “Pinout” del microcontrolador (II). ....................................................... 26 Ilustración 19. Instalador de CCS. ................................................................................ 27 Ilustración 20. Explorador de recursos. ....................................................................... 28 Ilustración 21. Menú desplegable “Help”. ................................................................... 29 Ilustración 22. Seleccionar “ARM Compiler Tools 5.2.9”. .......................................... 29 Ilustración 23. Menú desplegable “Project”. ............................................................... 30 Ilustración 24. Importar los programas “App” y “Stack”. ........................................... 30 Ilustración 25. Seleccionar el compilador “TI v5.2.9”. ............................................... 31 Ilustración 26. Hacer clic en “Edit” en la ventana de propiedades del proyecto...... 32 Ilustración 27. Seleccionar “Preferences” en la ventana desplegable. .................... 32 Ilustración 28. Hacer clic en “Refresh” para actualizar los paquetes de software que el IDE tiene listados. ...................................................................................................... 33 Ilustración 29. Cambiar la versión de XDXtools a la 3.62.0.06. ................................ 33 Ilustración 30. Estructura de un programa típico de un microcontrolador con superloop. ...................................................................................................................... 34 Ilustración 31. Comparación de un programa de un microcontrolador sin SO (BareMetal) con un RTOS. ...................................................................................................... 35 Ilustración 32. Ejemplo de ejecución de varias tareas con Preemtive Scheduling. . 35 Ilustración 33. Estados de una tarea. .......................................................................... 36 Ilustración 34. Tipos de hilos (threads) en TI-RTOS. ................................................... 37 Ilustración 35. Estructura de un programa en CCS. ................................................... 39 Ilustración 36. Comunicación entre las dos imágenes de un programa a través de ICall. ................................................................................................................................ 40 Ilustración 37. Logo Bluetooth versión 4.0. ................................................................ 40 Ilustración 38. Arquitectura de la pila del protocolo BLE. .......................................... 41 Ilustración 39. Canales RF de BLE. .............................................................................. 42 6 Ilustración 40. Intervalos de tiempo de emisión y espera de paquetes de respuesta. ........................................................................................................................................ 43 Ilustración 41. Secuencia de eventos para iniciar una conexión. ............................. 44 Ilustración 42. Comunicación entre dispositivos maestro y esclavo. ........................ 45 Ilustración 43. Diagrama de estados del nivel Link Layer. ......................................... 45 Ilustración 44. Formatos de los paquetes de datos. .................................................. 46 Ilustración 45. Formato de paquete de datos para transmisión de información. .... 47 Ilustración 46. Operaciones de solicitud y respuesta. ................................................ 49 Ilustración 47. Operación de tipo orden. ..................................................................... 49 Ilustración 48. Operaciones de indicación y confirmación. ........................................ 49 Ilustración 49. Operación de notificación. ................................................................... 50 Ilustración 50. Propiedades de un atributo. ................................................................ 50 Ilustración 51. Perfil GATT. ............................................................................................ 51 Ilustración 52. Elementos de una característica. ....................................................... 52 Ilustración 53. Ejemplo de una tabla de datos de un atributo. .................................. 53 Ilustración 54. Pila del protocolo BLE con perfiles...................................................... 55 Ilustración 55. Logo del bus I2C. .................................................................................. 56 Ilustración 56. Ejemplo de implementación de comunicación entre dispositivos mediante I2C. ................................................................................................................ 56 Ilustración 57. Configuración "open drain". ................................................................. 57 Ilustración 58. Estructura básica de los mensajes en la comunicación I2C............. 57 Ilustración 59. Esquema del módulo I2C del microcontrolador. ................................ 59 Ilustración 60. Esquema para obtener la señal de reloj del módulo I2C y del reloj SCL. ................................................................................................................................. 60 Ilustración 61. Configuración de la señal SCL. ............................................................ 60 Ilustración 62. Fórmula para obtener la señal de reloj SCL. ...................................... 61 Ilustración 63. Valores de “d” en función de IPSC. ..................................................... 61 Ilustración 64. Validación de datos. ............................................................................. 61 Ilustración 65. Condiciones de inicio y parada. .......................................................... 61 Ilustración 66. Estructura del mensaje si la dirección del esclavo son 7 bits. ......... 62 Ilustración 67. Estructura del mensaje si la dirección del esclavo son 10 bits. ....... 62 Ilustración 68. Estructura del mensaje en formato libre. ........................................... 62 Ilustración 69. Estructura del mensaje en repetición de la condición de inicio. ...... 63 Ilustración 70. Sincronización de la señal de reloj SCL. ............................................. 63 Ilustración 71. Representación teórica de un ECG. .................................................... 64 Ilustración 72. Representación del complejo QRS. ..................................................... 65 Ilustración 73. Opciones de colocación de los electrodos periféricos según la American Heart Association (AHA). ............................................................................... 66 Ilustración 74. Diagrama de bloques de la fase de pre-procesado del algoritmo. ... 66 Ilustración 75. Sensor electrocardiográfico. ................................................................ 67 Ilustración 76. Electrodos. ............................................................................................ 68 Ilustración 77. Colocación errónea de los electrodos................................................. 68 Ilustración 78. Colocación correcta de los electrodos. ............................................... 69 Ilustración 79. Parches desechables para electrodos................................................ 69 Ilustración 80. Gráfica de los valores detectados por el sensor. ............................... 70 7 Ilustración 81. Árbol del proyecto "F28069M_TX_P1"................................................ 71 Ilustración 82. Código de la función "Config_ADC()". .................................................. 72 Ilustración 83. Código de la función "adc_isr()". ......................................................... 73 Ilustración 84. Código de la función "I2C_Init()". ......................................................... 73 Ilustración 85. Código de la función "i2c_tx_isr()". ..................................................... 74 Ilustración 86. Código de la función “ePWM2_Timer()”. ............................................ 75 Ilustración 87. Código de la función "epw2_timer_isr()". ........................................... 75 Ilustración 88. Código del bucle for infinito del "main()". ........................................... 76 Ilustración 89. Fragmento de la función "detect()". .................................................... 76 Ilustración 90. Árbol del proyecto "CC250_Peripheral_BLE_P2". .............................. 78 Ilustración 91. Captura de la herramienta generadora de servicios. ........................ 79 Ilustración 92. Constantes definidas en "ConstantesVitales.h". ................................ 79 Ilustración 93. Instrucción que añadir en "ConstantesVitales.c" (I). .......................... 80 Ilustración 94. Instrucción que añadir en “ConstantesVitales.c” (II). ........................ 80 Ilustración 95. Instrucción que añadir en "ConstantesVitales.c" (III). ........................ 80 Ilustración 96. Modificación (I) en "BLE_Peripheral.c". .............................................. 80 Ilustración 97. Modificación (II) en "BLE_Peripheral.c". ............................................. 81 Ilustración 98. Modificación (II) en "BLE_Peripheral.c". ............................................. 81 Ilustración 99. Modificación (III) en "BLE_Peripheral.c". ............................................ 81 Ilustración 100. Código ubicado en el fichero "I2C_RX.c". ......................................... 81 Ilustración 101. Código de la función "I2C_RX_createTask()”. .................................. 82 Ilustración 102. Código de la función “I2C_RX_TaskFxn()” (I). .................................. 82 Ilustración 103. Código de la función “I2C_RX_TaskFxn()” (II). ................................. 83 Ilustración 104. Código de la función “I2C_RX_TaskFxn()” (III). ................................ 83 Ilustración 105. Modificación (I) en "main.c"............................................................... 84 Ilustración 106. Modificación (II) en "main.c".............................................................. 84 Ilustración 107. Árbol del proyecto "CC2650_Central_BLE_P3". .............................. 85 Ilustración 108. Modificación (I) del fichero "simple_central.c". ................................ 86 Ilustración 109. Modificación (II) del fichero "simple_central.c". ............................... 86 Ilustración 110. Modificación (III) del fichero "simple_central.c". .............................. 86 Ilustración 111. Modificación (IV) del fichero "simple_central.c". ............................. 87 Ilustración 112. Modificación (V) del fichero "simple_central.c". .............................. 87 Ilustración 113. Modificación (VI) del fichero "simple_central.c". ............................. 87 Ilustración 114. Fragmento de código de la función "SimpleBLECentral_init()". ...... 87 Ilustración 115. Fragmento de código (I) de la función "SimpleBLECentral_processRoleEvent()". .................................................................... 88 Ilustración 116. Fragmento de código (II) de la función "SimpleBLECentral_processRoleEvent()". .................................................................... 88 Ilustración 117. Fragmento de código (I) de la función "SimpleBLECentral_handleKeys()". .............................................................................. 88 Ilustración 118. Fragmento de código (II) de la función "SimpleBLECentral_handleKeys()". .............................................................................. 89 Ilustración 119. Fragmento de código (III) de la función "SimpleBLECentral_handleKeys()". .............................................................................. 89 8 Ilustración 120. Fragmento de código (IV) de la función "SimpleBLECentral_handleKeys()". .............................................................................. 89 Ilustración 121. Fragmento de código de la función "SimpleBLECentral_processGATTMsg()". ..................................................................... 90 Ilustración 122. Fragmento de código (I) de la función "SimpleBLECentral_processGATTDiscEvent()". ........................................................... 90 Ilustración 123. Fragmento de código (II) de la función "SimpleBLECentral_processGATTDiscEvent()". ........................................................... 91 Ilustración 124. Código localizado en el fichero "I2C_TX.h". ...................................... 91 Ilustración 125. Código de la función “recible_BLE()” en el fichero "I2C_TX.c". ....... 91 Ilustración 126. Declaración de la variable global "dato_ble". .................................. 92 Ilustración 127. Fragmento de código de la función " I2C_TX_TaskFxn()". ............... 92 Ilustración 128. Código del fichero “main.c”. .............................................................. 92 Ilustración 129. Fragmento de código de la función “main()”. .................................. 92 Ilustración 130. Árbol del programa "F28069M_RX_P4". .......................................... 93 Ilustración 131. Declaraciones de las variables globales y de las funciones auxiliares del programa. ................................................................................................ 93 Ilustración 132. Código de la función "I2C_Init()". ...................................................... 94 Ilustración 133. Código de la función "i2c_rx_isr()". ................................................... 95 Ilustración 134. Captura (I) del depurador de CCS. .................................................... 97 Ilustración 135. Captura (I) del programa Logic 2. ..................................................... 97 Ilustración 136. Captura (II) del depurador de CCS. ................................................... 98 Ilustración 137. Captura (I) de la app "BLE Scanner". ................................................ 98 Ilustración 138. Captura (II) de la app "BLE Scanner". ............................................... 99 Ilustración 139. Captura (III) de la app "BLE Scanner". .............................................. 99 Ilustración 140. Captura (I) del terminal serie. ........................................................ 100 Ilustración 141. Captura (II) del terminal serie. ....................................................... 100 Ilustración 142. Captura (III) del terminal serie. ...................................................... 100 Ilustración 143. Captura (III) del depurador de CCS. ............................................... 101 Ilustración 144. Captura (IV) del depurador de CCS. ............................................... 101 Ilustración 145. Captura (II) del programa Logic 2. ................................................. 101 Ilustración 146. Foto del montaje final del proyecto. .............................................. 102 Ilustración 147. Esquema de la resistencia pull-up embebida en la LaunchPad. 111 Ilustración 148. Frecuencia señal SCL a 100 KHz. ................................................. 112 Ilustración 149. Frecuencia señal SCL a 400 KHz. ................................................. 112 Ilustración 150. Especificaciones del protocolo I2C. Tabla de Texas Instruments. ..................................................................................................................................... 114 Ilustración 151. Frecuencia señal SCL a 100 KHz. ................................................. 115 Ilustración 152. Frecuencia señal SCL a 400 KHz. ................................................. 115 15 La plataforma RobHand [6] (Robot para la Rehabilitación de la Mano) realiza terapias bilaterales asistidas por EMG, las cuales permiten entrenamiento activoasistencial (Ilustración 7). La plataforma de rehabilitación robótica incorpora una solución integrada de EMG hecha a medida para el reconocimiento de gestos en tiempo real cuya salida se utiliza en el controlador bio-cooperativo del exoesqueleto (Ilustración 6). Las señales EMG registradas se procesan creando dos vías de biorretroalimentación (una fuente de fuerza y otra visual) para ayudar al usuario a tomar conciencia y confianza en el control voluntario del sistema mientras realiza tareas de rehabilitación. Ilustración 6. Esquema de funcionamiento de RobHand. Ilustración 7. Un usuario realizando una terapia bilateral asistida por EMG con la plataforma robótica RobHand. 16 17 2.2. LAUNCHXL-F28069M La placa de desarrollo LAUNCHXL-F28069M (Ilustración 8 e Ilustración 10) [7] desarrollada por Texas Instruments pertenece a la familia de procesadores C2000 [8] e integra el microcontrolador TMS320F28069M [9]. Es una herramienta de desarrollo y evaluación de aplicaciones electrónicas, estandarizada y de bajo costo (P.V.P. de 24,99$). Además, es compatible con multitud de “BoosterPacks” o módulos de expansión de Texas Instruments y ofrece la herramienta de depuración JTAG, la cual proporciona una interfaz de comunicación directa con un ordenador para facilitar la programación, la depuración y la evaluación del código desarrollado [10] [11] [12]. Ilustración 8. Microcontrolador LAUNCHXL-F28069M. Todos los manuales técnicos y el resto de la documentación se encuentran ubicados en la carpeta adjunta a este documento llamada “Documentación/LaunchPad F28069M”. CARACTERÍSTICAS TÉCNICAS  CPU: TMS320F28069 de 32 bits a 90 MHz. Arquitectura Harvard modificada (Ilustración 9). Programable en C/C++ y ensamblador.  CLA (Control Law Accelerator): Acelerador de hardware de coma flotante de 32 bits totalmente programable e independiente de la CPU principal, diseñado para cálculos matemáticos intensos. Se ejecuta en paralelo con la CPU C28, duplicando el rendimiento computacional. Además, está diseñado para responder rápidamente a interrupciones y tiene acceso a todos los periféricos del microcontrolador. 18 Ilustración 9. Funcionamiento de los núcleos C28x y CLA dentro de la CPU  FPU (Unidad de Punto Flotante): Operaciones en coma flotante de forma nativa y precisión única.  Memoria: 100KB de RAM, 256KB de Flash y 2KB de ROM.  6 DMA (Canales de acceso directo a memoria)  Soporte JTAG para analizar, emular y depurar código en tiempo real vía hardware.  8 modulos ePWM (“enhanced” PWM): 16 canales PWM en total (8 son HRPWM) con temporizadores de 16 bits independientes para cada módulo.  16 canales de conversores ADC de 12 bits de resolución (0 a 3,3V) con muestreo y retención doble.  PIE (Peripheral Interrupt Expansion): Bloque que soporta todo tipo de interrupciones producidas por los módulos periféricos del microcontrolador. Ilustración 10. Esquema de puertos y funcionalidades del microcontrolador. 19  80 pines GPIO multiplexados que ofrecen diferentes funciones.  3 temporizadores de 32 bits.  Sensor de temperatura.  Método de seguridad “Key and Lock” de 128 bits para proteger el acceso a los bloques de memoria e impedir la ingeniería inversa del firmware.  Módulos de comunicación serie:  2 módulos SCI (UART).  2 módulos SPI.  1 módulo I2C.  1 módulo con interfaz eCAN con un transmisor-receptor integrado.  1 USB 2.0.  2 LEDs integrados programables.  Botón RESET.  3 interruptores de selección de arranque (boot).  Biblioteca InstaSPIN cargada en la ROM.  2 interfaces para encoders de 5V.  Modo de funcionamiento de bajo consumo.  Interfaz de comunicación con un ordenador a través de XDS100v2 USB aislada galvánicamente. 20 DISPOSICIÓN DE LOS PINES O “PINOUT” Ilustración 4. “Pinout” del microcontrolador (I). Ilustración 5. “Pinout” del microcontrolador (II). 21 SOFTWARE DE DESARROLLO El LaunchPad F28069M es compatible con los IDE Code Composer Studio [13] y Energia [14], aunque durante el desarrollo de estas prácticas se trabajará únicamente con Code Composer Studio. Este entorno de desarrollo está diseñado por la propia Texas Instruments, por lo que este dispone de un conjunto muy completo de herramientas para desarrollar y optimizar aplicaciones embebidas. Dispone de un compilador de C/C++ optimizado, editor de código, árbol de proyecto y depurador de código, entre otras cosas. Una vez descargado e instalado, el programa sugiere al usuario la instalación de controlSUITE [15] y C2000WARE [16], los cuales son software añadido al IDE con documentación, bibliotecas, drivers específicos y ejemplos para diferentes microcontroladores de la familia C2000. Ilustración 11. Code Composer Studio. Ilustración 12. Energia. Ilustración 13. controlSUITE. Para aprender a utilizar y programar el microcontrolador con el IDE Code Composer Studio antes de desarrollar el programa objetivo, se hará uso de la documentación técnica oficial proporcionada por Texas Instruments, tutoriales y ejemplos incluidos en el software C2000WARE [17] [18] [19] [20]. 22 2.3. LAUNCHXL-CC2650 Esta plataforma de desarrollo (Ilustración 14) [21] manufacturada por Texas Instruments, incorpora un microprocesador CC2650, perteneciente a la familia de procesadores C26xx. Esta herramienta de desarrollo de aplicaciones electrónicas, con un P.V.P. de 29$, permite desarrollar proyectos con conectividad Bluetooth de baja energía en el ecosistema SimpleLink [22], el cual provee manuales de uso y multitud de ejemplos. El propósito del microcontrolador es facilitar el desarrollo de software para aplicaciones relacionadas con el Internet de las Cosas o “IoT” utilizando el kit de desarrollo de software (SDK) de Texas Instruments llamado TI BLE-Stack [23], el cual cuenta con la pila de software certificada de la versión 4.1 de Bluetooth. El controlador de BLE (Bluetooth Low Energy) y de la MAC de IEEE 802.15.4 está embebido en una ROM y se ejecuta en parte en un procesador ARM Cortex-M0. La LaunchPad CC2650 [24] [25] [26] [27] posee un microprocesador ARM CortexM3 de 32 bits a 48 MHz de frecuencia, y tiene multitud de módulos periféricos junto a un sensor de baja potencia que se encarga de interactuar con sensores externos almacenando información de manera autónoma a la CPU cuando el resto del sistema está en suspensión o “sleep mode”. Ilustración 14. Microcontrolador LAUNCHXL-CC2650 23 El desarrollo y depuración de proyectos para este microcontrolador puede llevarse a cabo en los IDE Code Composer Studio e IAR Embedded Workbench [28] pero no en Energia. También puede cargarse firmware a través de SmartRF Studio [29] y SmartRF Flash Programmer 2 [30]. Al igual que la LaunchPad F28069M, este microcontrolador es compatible con multitud de “BoosterPacks” o módulos de expansión de Texas Instruments y ofrece la herramienta de depuración JTAG, la cual proporciona una interfaz de comunicación directa con un ordenador para facilitar la programación, la depuración y la evaluación del código desarrollado. Todos los manuales técnicos y el resto de la documentación (Ilustración 15) se encuentran ubicados en la carpeta adjunta a este documento llamada “Documentación/LaunchPad CC2650”, de la misma manera que con la LAUNCHXLF28069M. Ilustración 15. Esquema de puertos y funcionalidades del microcontrolador. 24 CARACTERÍSTICAS TÉCNICAS  CPU: ARM Cortex-M3 de 32 bits a 48 MHz.  Memoria: 128KB de Flash, 8KB de SRAM (Cache) y 20KB de SRAM.  Controlador de sensores de muy bajo consumo: Arquitectura de 16 bits, 2 KB de SRAM y puede ejecutarse de manera autónoma con respecto al resto del sistema. Ilustración 16. Diagrama de bloques del microprocesador. 31 En el árbol de proyectos, hacer clic derecho sobre el proyecto “simple_peripheral_cc2650lp_stack” y seleccionar “Properties”. En la pestaña “Project” (Ilustración 25) de la opción “CCS General” cambiar la versión del compilador a TI v5.2.9. Ilustración 25. Seleccionar el compilador “TI v5.2.9”. Después, de nuevo en el árbol de proyectos, hacer clic derecho sobre el proyecto “simple_peripheral_cc2650lp_app” y seleccionar “Properties”. En la pestaña “Project” de la opción “CCS General” cambiar la versión del compilador a TI v5.2.9, al igual que con el programa de la pila. Ahora, en la pestaña “Products”, seleccionar “XDCtools [3.62.0.08_core]” y seleccionar “Edit”, como muestra la Ilustración 26. 32 Ilustración 26. Hacer clic en “Edit” en la ventana de propiedades del proyecto. En la ventana emergente, seleccionar “Preferences” (Ilustración 27). Ilustración 27. Seleccionar “Preferences” en la ventana desplegable. Aparecerá otra ventana emergente y en su parte derecha se selecciona la opción “Refresh” (Ilustración 28). 33 Ilustración 28. Hacer clic en “Refresh” para actualizar los paquetes de software que el IDE tiene listados. Instalar todo lo que nos sugiere el IDE y reiniciar. Volvemos a la pestaña “Products” en las propiedades del proyecto y seleccionamos “Edit” habiendo elegido XDCtools previamente. En la ventana emergente (Ilustración 29), seleccionar la versión 3.32.0.06_core en el desplegable de la parte derecha. Aceptar. Aplicar cambios y cerrar las propiedades. Ilustración 29. Cambiar la versión de XDXtools a la 3.62.0.06. Por último, para asegurarnos de que todos los paquetes se han instalado correctamente y se ha configurado el IDE adecuadamente, se compilan ambos proyectos y se comprueba que no hay errores. 34 TI-RTOS La LAUNCHXL-CC2650 pertenece a la familia de microcontroladores del ecosistema SimpleLink, el cual provee el entorno y las herramientas necesarias para desarrollar proyectos y aplicaciones, siendo en este caso el TI BLE-SDK, que permite y facilita la programación del microcontrolador para aplicaciones con BLE (bluetooth de baja energía). Sin embargo, por debajo de esta pila o stack subyace un sistema operativo en tiempo real (RTOS) que gobierna el microcontrolador y se encarga de organizar todos los procesos que ejecuta la CPU. En un microcontrolador que no tenga que realizar un número significativo de tareas simultáneamente o con un programa con una lógica sencilla, normalmente se ejecuta un único proceso en un bucle infinito (super-loop) tras haberse inicializado todas las funciones, variables y módulos necesarios. El único suceso que puede parar el desarrollo de este único proceso o hilo en ejecución es una interrupción (ISR, Interrupt Service Routine), la cual es una llamada a la CPU para que realice una acción específica cuando se da una circunstancia determinada por el programador y, a continuación, se vuelve a ejecutar el bucle infinito en el lugar donde se había sido detenido por la interrupción. La siguiente imagen muestra un esquema de la estructura de un programa típico de un microcontrolador. A esta estructura se la conoce como “Bare-Metal” (Ilustración 30). Ilustración 30. Estructura de un programa típico de un microcontrolador con superloop. Sin embargo, la LaunchPad CC2650 trabaja con un sistema operativo en tiempo real desarrollado por la propia Texas Instruments, el TI-RTOS (antiguo SYS/BIOS) [33] [34], aunque también puede funcionar con FreeRTOS si se desea. Al trabajar con un sistema operativo (SO), el proceso de crear una aplicación que haga uso de varios módulos periféricos y de la pila de la comunicación Bluetooth es más sencillo y llevadero para el programador. Al utilizar un sistema operativo en tiempo real, el planificador o scheduler de tareas del kernel se encarga de asignar tiempo de ejecución en la CPU y organizar todos los hilos o tareas que posea la aplicación. 35 Ilustración 31. Comparación de un programa de un microcontrolador sin SO (Bare-Metal) con un RTOS. El scheduler de TI-RTOS puede funcionar de dos maneras:  Preemptive Scheduling (programación preferente, Ilustración 32): Este es el funcionamiento por defecto de TI-RTOS y el que se va a utilizar en este caso. Con este método de planificación, una tarea que se esté ejecutando continua su funcionamiento hasta que bien termine, bien sea interrumpida por otra tarea con mayor prioridad o bien la propia tarea ceda el uso de la CPU porque pasa a estado de suspensión (la tarea “se duerme”). Ilustración 32. Ejemplo de ejecución de varias tareas con Preemtive Scheduling.  Time-slice Scheduling (programación de intervalos de tiempo): En este tipo de planificación cada tarea dispone de un determinado intervalo de tiempo para ejecutarse. No obstante, este método de planificación no es aconsejable ni propicio para aplicaciones de tiempo real. 36 Tipos de hilos o procesos En TI-RTOS hay 4 tipo de hilos (threads, Ilustración 34), con prioridad de mayor a menor según se definan a continuación, y el scheduler se encarga de que el proceso activo que tenga mayor prioridad se ejecute:  Hardware Interrupts (Hwi): Hilo que se ejecuta hasta acabar su trabajo. No bloquea nada y solo pueden ser reemplazados por otro hilo Hwi de mayor prioridad. Todos los hilos Hwi comparten la misma pila (la pila del sistema) y hay un número máximo de Hwi. Otro aspecto a destacar es que el scheduler no puede administrar la interrupción, ya que para que tenga la menor latencia posible (teóricamente latencia cero), el kernel es quien se encarga de tratar la interrupción. Sin embargo, esta situación trae la desventaja de que estas interrupciones no pueden llamar a las API para utilizar semáforos, colas u otros métodos de comunicación entre procesos. Este tipo de procesos se generan por interrupciones a nivel de hardware para hacer que la BIOS genere un guardado, anidado o restauración de contexto. Un Hwi debe ser tratado inmediatamente después de generarse.  Software Interrupts (Swi): Hilo muy similar al Hwi, las únicas diferencias son que este tipo de interrupciones son disparadas por eventos de software y que tienen menor prioridad que las Hwi. También se ejecutan hasta su finalización una vez iniciados y comparten la misma pila del sistema junto con los Hwi. Los Swi se utilizan para realizar trabajos de Hwi diferidos para minimizar la latencia de las interrupciones.  Tasks (tareas): Tipo de hilo más común en el SO. En este caso, cada tarea tiene su propia pila donde mantiene su estado y de esta manera se pueden bloquear utilizando semáforos u otros tipos de comunicación entre procesos. Pueden clasificarse por prioridad y no hay un número máximo de tareas permitidas. Ilustración 33. Estados de una tarea. 37  Idle (inactivo, ocioso): Hilo por defecto que siempre se ejecuta con el menor nivel de prioridad, 0. Este tipo de hilos realizan tareas en segundo plano y sin importancia crítica para el sistema cuando no hay ningún otro hilo en ejecución. Con el objetivo de consumir la menor energía posible, el microcontrolador puede entrar en modo “bajo consumo” cuando se está ejecutando un proceso tipo Idle. Ilustración 34. Tipos de hilos (threads) en TI-RTOS. Métodos de comunicación entre procesos  Semaphores (semáforos): Regula el acceso a un recurso común entre procesos. Pueden ser utilizados para sincronizar tareas o para exclusión mutua (mutex).  Mailboxes (buzones): Módulo de paso de mensajes entre procesos.  Queues (colas de mensajes): Lista doblemente enlazada sin sincronización.  Gates (puertas): Método que protege el acceso simultáneo a estructuras de datos críticas. Es un objeto de exclusión mutua (mutex) reentrante.  Events (eventos): Módulo que permite la sincronización a través de múltiples eventos. De todas maneras, TI-RTOS es compatible con el estándar de la IEEE POSIX y el SDK de SimpleLink permite que las APIs de POSIX se ubiquen encima de la estructura de TI-RTOS. 38 Con el objetivo de comprender el funcionamiento del microprocesador, aprender a trabajar con esta placa que contiene un procesador de una arquitectura diferente a la LaunchPad F28069M y que posee un sistema operativo en tiempo real, se estudiarán los ejemplos de SimpleLink “Project Zero” y “Simple Central”. Además, estos programas servirán como base a la hora de desarrollar los programas que se ejecutarán en microcontroladores CC2650. Las explicaciones de estos programas se encuentran en la documentación y se ubican en SimpleLink y en el explorador de recursos de Code Composer Studio a su vez. Antes de comenzar a desarrollar programas en este microcontrolador, es necesario descargar e instalar la versión 2.02.01.18 de BLE-STACK, que además instala la versión 2.20.01.08 de TI-RTOS, para compilar los programas de ejemplo de SimpleLink Academy (versión 1.11.00), la cual también es necesaria descargar e instalar.  BLE-STACK: [35].  SimpleLink Academy: [36]. PROJECT ZERO Para estudiar este programa de ejemplo de la versión 1.11 de SimpleLink Academy, será necesario utilizar las guías y documentación correspondiente: [37] [38] [39] [40]. Para realizar la conexión con el microcontrolador será necesario un smartphone con Bluetooth 4.1 como mínimo y la aplicación BLE Scanner [41] instalada en el dispositivo. Además, será necesario instalar en el PC un terminal de comunicación en serie. Se recomienda el programa PuTTY [42] o utilizar el terminal de comunicaciones integrado en Code Composer Studio. SIMPLE CENTRAL Este programa de prueba de SimpleLink para el microcontrolador LAUNCHXLCC2650 se encuentra explicado en el soporte “Resource Explorer” de Texas Instruments [43]. Este programa implementa un dispositivo BLE en modo de funcionamiento central o maestro con funcionalidad de cliente GATT. Para trabajar con este ejemplo, se necesita que otro dispositivo trabaje como elemento periférico en la conexión BLE, por lo que se va a utilizar otro módulo CC2650 que tendrá cargado el ejemplo “simple_peripheral” de SimpleLink Academy. 39 2.4. Protocolo de comunicación BLE En este apartado se va a explicar cómo funciona la pila de protocolo de la comunicación de Bluetooth Low Energy o BLE y como se ha implementado su uso en el microcontrolador LAUNCHXL-CC2650 por parte de Texas Instruments a través de una lista de APIs para interactuar con dicha pila. Los proyectos programados para este microcontrolador constan de dos partes (Ilustración 35), “stack” y “application”. En la parte de “stack”, el protocolo BLE está implementado como la tarea de mayor prioridad, mientras que en la parte de “application” se ubica TIRTOS, el GAPRole y la aplicación desarrollada por el programador. Esto facilita las modificaciones a los desarrolladores de aplicaciones, puesto que tan sólo necesitaran cargar la parte de “application” al microcontrolador, dejando la parte de “stack” invariable para todo tipo de aplicaciones o cambios a un mismo programa. Ilustración 35. Estructura de un programa en CCS. La entidad que se encarga de comunicar las dos imágenes del programa es ICall (Indirect Call Framework). Esta capa de software proporciona un mecanismo para que la aplicación interactúe con los servicios de la API de la pila del protocolo BLE, así como otros servicios de TI-RTOS (como por ejemplo la sincronización de hilos o el control del montículo). ICall permite que la aplicación y la pila BLE operen eficientemente, se comuniquen y compartan recursos en un entorno RTOS unificado. El componente central de la entidad ICall es el “dispatcher” (controlador de transporte o despachador, Ilustración 36), que facilita la interfaz del programa de aplicación entre la aplicación y la pila de protocolos BLE a través de la frontera de la imagen dual. Aunque la mayoría de las interacciones de ICall se abstraen dentro de la API de la pila BLE (como por ejemplo GAP, HCI, etc.), ICall también ofrece otros servicios relacionados con TI-RTOS tal y como se mencionó previamente, como la sincronización y comunicación entre procesos y la asignación y control del montículo. 40 Ilustración 36. Comunicación entre las dos imágenes de un programa a través de ICall. Nótese que la mayor parte de los protocolos de la pila están almacenados en una única librería ya compilada, puesto que sus derechos y autoría pertenecen a Bluetooth Special Interest Group (SIG, [44]), aunque el uso de licencias BLE es totalmente gratuita. BLE es una tecnología de red de área personal inalámbrica o WPAN destinada a aplicaciones de pequeño costo, que requieran un consumo de energía lo más bajo posible y que operen durante largos períodos de tiempo con el uso de baterías de pequeña capacidad. Sus aplicaciones más comunes están relacionadas con la asistencia sanitaria, el deporte, balizas, seguridad y el entretenimiento. BLE (también llamado Bluetooth Smart) se lanzó al mundo con la versión 4.0 de Bluetooth (Ilustración 37) y es necesario puntualizar que BLE y Bluetooth Classic son protocolos diferentes y no son compatibles entre sí, aunque normalmente los fabricantes de módulos Bluetooth suelen incluir ambas especificaciones en sus dispositivos. Ilustración 37. Logo Bluetooth versión 4.0. 47  Las PDUs de los paquetes que transmiten información (connection) pueden transportar como máximo 246 bytes de información debido a las cabeceras de control de los diferentes niveles de la pila. Ilustración 45. Formato de paquete de datos para transmisión de información. Acrónimo del campo Nombre completo del campo PDU He Cabecera de la PDU MIC Message Integrity Check L2 He Cabecera del nivel L2CAP Op Código de operación ATT Par/Pay Parámetros ATT y mensaje En la versión 4.0 y 4.1 de BLE el tamaño máximo del campo de la PDU que corresponde a los parámetros ATT y al mensaje es de 22 bytes. c) Host-Controller Interface (HCI, interfaz controlador-servidor) Último nivel de la parte del controlador de la arquitectura del protocolo BLE. Este nivel vincula los niveles del controlador con los del servidor a través de una interfaz de comunicación estándar, la cual puede ser una función de una API o interfaces de comunicación comunes como UART, SPI o USB. Esta situación permite que un controlador pueda trabajar con diferentes instancias de “hosts” o que, en un PC, por ejemplo, el controlador esté implementado en un módulo o chip mientras que el “host” y la aplicación se ejecutan vía software en la propia CPU del ordenador. 48 d) Logical Link Control and Adaptation Protocol (L2CAP, nivel de control de enlace lógico y protocolo de adaptación) Primera capa de la parte del “host” de la pila del protocolo BLE, encargada de mantener una comunicación lógica de extremo a extremo. Este nivel tiene dos funciones principales:  Ofrece servicios de encapsulación de datos para los niveles superiores, recombinando los paquetes de datos de los niveles inferiores para formar un paquete más grande que puede ser recibido y procesado por los niveles superiores. Al mismo tiempo, esta capa realiza el servicio opuesto, fragmenta los mensajes provenientes de los niveles superiores en el formato de paquete BLE estándar para los niveles inferiores, los cuales deben de tener un tamaño máximo de 27 bytes.  Se encarga de dar soporte a dos protocolos principales del nivel superior: el “Attribute Protocol”, (ATT, protocolo de atributos) y “Security Manager Protocol”, (SMP, protocolo administrador de seguridad), explicados a continuación. e) Security Manager Protocol (SMP, protocolo administrador de seguridad) Nivel que provee servicios de emparejamiento y distribución de claves de seguridad con el objetivo de conseguir una conexión e intercambio de datos seguro entre dispositivos BLE. El uso de los procedimientos de seguridad es recomendable, pero no obligatorio. Los dos principales sistemas de seguridad implementados en BLE son:  Pairing (emparejamiento): Sistema de autentificación de dispositivos que establece claves compartidas, secretas y temporales que se utilizan para cifrar una conexión. Existen tres sistemas de emparejamiento:  Just Works (Simplemente funciona): Conexión directa. En realidad, no es ningún sistema de auntentificación de seguridad.  Passkey Entry (Clave de acceso): Contraseña de 6 dígitos que deben introducir los dispositivos que quieren realizar una conexión.  Numeric Comparison (comparación numérica): Número de 6 dígitos que se muestra en los dispositivos que quieren realizar una conexión. Para iniciar la conexión, los usuarios de ambos terminales deberán aceptar la solicitud de conexión con dicho número.  OOB (Out of Band): Claves encriptadas transferidas a través de otros sistemas de comunicación, como NFC, por ejemplo.  Bonding (enlazamiento o vinculación): La vinculación es el emparejamiento seguido de la distribución de claves que pueden utilizarse para cifrar el enlace en conexiones futuras entre los mismos dispositivos, resultando en una encriptación de los mensajes. 49 f) Attribute Protocol (ATT, protocolo de atributos) Esta capa de la pila BLE implementa un protocolo de cliente-servidor y define como un cliente puede encontrar y acceder a los atributos de un servidor. El cliente solicita información del servidor y este le enviará la respuesta a su petición siempre y cuando no tenga ninguna petición previa pendiente. Las operaciones que ofrece este nivel a la pareja cliente-servidor son las siguientes:  Request (solicitud): Operación realizada por un cliente a un servidor, en la que el cliente pide realizar al servicio una acción determinada.  Response (respuesta): Esta operación la realiza un servidor a un cliente en respuesta a una solicitud recibida previamente. Ilustración 46. Operaciones de solicitud y respuesta.  Command (orden): Operación similar a la solicitud, pero a diferencia de esta, una orden no necesita una respuesta inmediata por parte del servidor. Ilustración 47. Operación de tipo orden.  Indication (indicación): Operación que realiza un servidor a un cliente, informando a este último sobre el valor de un atributo determinado.  Confirmation (confirmación): Mensaje de respuesta después de una indicación por parte de un cliente a un servidor. Las indicaciones y las confirmaciones tienen el sentido inverso a las solicitudes y respuestas. Ilustración 48. Operaciones de indicación y confirmación. 50  Notification (notificación): Operación inversa a las órdenes. En este caso, es el servidor quien envía un mensaje a un cliente sin necesidad de recibir una respuesta. Ilustración 49. Operación de notificación. Los servidores organizan y almacenan sus datos e información en forma de atributos, los cuales poseen cuatro elementos o propiedades (Ilustración 50):  Manipulador (Handler): Método que sirve para acceder a los datos de un atributo. El manipulador identifica al atributo inequívocamente en el servidor.  Identificador UUID (Universal Unique Identification Address), el cual especifica la naturaleza de los datos del atributo. Los UUID tienen un tamaño de 128 bits. Sin embargo, Bluetooth SIG ha definido 128 tipos de atributos estándar, llamados Bluetooth Base UUID, cuyo identificador es de 16 bits, lo que permite una comunicación más rápida y eficiente.  Datos y valores etiquetados y direccionables, con tamaños de 0 a 512 bytes.  Lista de permisos del atributo: Lectura, escritura o ambos a la vez. Ilustración 50. Propiedades de un atributo. Cuando un cliente quiere leer o escribir valores en un atributo en un servidor, el primero envía una solicitud de lectura o escritura al segundo a través del manipulador. Después, el servidor envía una respuesta con el valor del atributo o con una respuesta de acuse de recibo. Si la operación es de lectura, el cliente tiene que realizar el tratamiento pertinente del valor recibido basándose en el UUID del atributo. En cambio, en una operación de escritura, el cliente es el encargado de asegurarse que los datos enviados se corresponden con el tipo de atributo. Si ocurre algún error, el servidor rechazará la operación. 51 g) Generic Attribute Profile (GATT, perfil de atributos genéricos) Este es uno de los dos niveles superiores la pila BLE (Ilustración 51), y está ubicado encima del nivel ATT. Su cometido es jerarquizar y organizar cómo se intercambia información entre diferentes aplicaciones, además de definir el procedimiento de búsqueda y acceso de atributos. En esta capa, los datos se organizan en “Services” (servicios), los cuales contienen “Characteristics” (características), que son una combinación de datos de usuario y metadatos o información descriptiva y contienen dos o más atributos. Estos servicios se organizan en perfiles llamados “GATT profiles”, en los que cada uno puede contener varios servicios. Tanto los servicios como las características se identifican a través de un UUID de 16 bits o de 128 bits si el perfil no está predefinido por Bluetooth SIG. Ilustración 51. Perfil GATT. Como ya se ha mencionado, las características (Ilustración 52) se componen de dos o más atributos, y están formadas por 3 elementos:  Declaration (declaración), constituida a su vez por:  Properties (propiedades): Determina si un valor de la característica puede ser leído, escrito, notificado, indicado o emitido (broadcast).  Value handle (manipulador): Manipulador del atributo que controla el valor de la característica, permitiendo que la búsqueda de la característica por parte de un cliente sea rápida y eficaz, recibiendo únicamente el valor de la característica.  Type (UUID): Identificador del valor de la característica. 52  Value (valor): Es un atributo.  Descriptor: Los descriptores se utilizan para actualizar la información relacionada con el valor de la característica. Son los siguientes:  Characteristic Extended Properties Descriptor: Expande las propiedades de una característica ya definidas en la declaración.  Characteristic User Description Descriptor: Asocia un “string” con una característica.  Characteristic Presentation Format Descriptor: Se utiliza para asociar un número con una descripción estándar del valor, como por ejemplo un número decimal que representa la temperatura junto con su unidad, los grados centígrados.  Characteristic Aggregation Format Descriptor: Descriptor que habilita el uso de formatos más complejos.  Client Characteristic Configuration Descriptor (CCCD): Debe usarse si una característica está utilizando notificaciones o indicaciones. Para habilitar las notificaciones el CCCD debe tener el valor “1”, mientras que para habilitar las indicaciones el valor del CCCD tiene que ser “2”.  Server Characteristic Configuration Descriptor: Debe ser utilizado si la característica va a ser retransmitida (broadcast). Ilustración 52. Elementos de una característica. 53 Los procedimientos que realiza este nivel son 3:  Discovery (descubrimiento): Procedimiento que se utiliza para descubrir los servicios, características y atributos en un servidor. Hay cuatro elementos que deben ser descubiertos:  Primary Service Discovery: El cliente descubre primero todos los servicios o únicamente uno específico a través de su UUID.  Relationship Discovery: Después, el cliente puede descubrir servicios secundarios y otro tipo de servicios.  Characteristic Discovery: El cliente descubre las características de un servicio.  Characteristic Descriptor Discovery: El cliente descubre los descriptores de una característica.  Client-initiated (iniciado por el cliente): Un cliente lee o escribe en los valores de las características de un servidor y en sus descriptores asociados.  Server-initiated (iniciado por el servidor): Un servidor envía datos a un cliente directamente sin que este le haya hecho ninguna solitud. El servidor puede enviar notificaciones o indicaciones de los valores de una característica. Las notificaciones no necesitan acuse de recibo, pero las indicaciones sí. Ilustración 53. Ejemplo de una tabla de datos de un atributo. Los niveles GATT y GAP (explicado a continuación) conforman la principal interfaz de la pila del protocolo BLE. 54 h) Generic Access Profile (GAP, perfil de acceso genérico) Última capa de la pila BLE, cuyo cometido es definir cómo los dispositivos se buscan, conectan y enlazan entre sí, a través de roles de funcionamiento, modos, procedimientos y enlaces seguros. Los roles o modos de funcionamiento de los dispositivos se agrupan por parejas y son los siguientes:  (1) Advertiser (publicador o anunciante): Dispositivo que emite paquetes de datos al medio con información relativa a los servicios que presta. Si un dispositivo, con el rol de escáner quiere recibir la información, deberá realizarse una conexión entre ambos dispositivos previamente.  (1) Scanner (escáner): Dispositivo en escucha en el espectro RF de paquetes de datos que establece comunicaciones con dispositivos en modo “Advertiser”.  (2) Central: Dispositivo maestro que inicia una conexión y una vez realizada, la administra. Nótese que un maestro puede realizar conexiones con varios esclavos a la vez. Un dispositivo central puede tener varios periféricos.  (2) Peripheral (periférico): Dispositivo esclavo que acepta una conexión por parte de un dispositivo maestro y que seguirá sus instrucciones.  (3) Broadcaster (emisor): Dispositivo que emite paquetes de datos al medio, sin necesidad de haber creado previamente ninguna conexión con otro dispositivo.  (3) Observer (observador): Dispositivo en escucha en el espectro RF de paquetes de datos emitidos por dispositivos en modo “Broadcaster”. 55 i) Profiles (perfiles) Los perfiles son especificaciones que describen casos de uso para dos o más dispositivos con varios servicios. También describen los procedimientos de cómo los dispositivos deben ser descubiertos y conectados a través de las funciones de GATT y GAP y qué servicios son necesarios en cada dispositivo. Las aplicaciones que utilicen la pila del protocolo BLE pueden implementar los perfiles predefinidos por Bluetooth SIG o crear uno propio con las especificaciones deseadas en cuanto a comportamiento y servicios. Ilustración 54. Pila del protocolo BLE con perfiles. La mayor parte de la documentación del protocolo de comunicación BLE proviene de Texas Instruments y de Nordic Semiconductor (Ilustración 54), una de las empresas integrantes de Bluetooth SIG. 56 2.5. Protocolo de comunicación I2C a) Fundamentos del protocolo I2C El protocolo de comunicación I2C o I2C, Inter-Integrated Circuit [54], fue desarrollado por Phillips Semiconductors (hoy NXP Semiconductors, perteneciente a Qualcomm) en 1982. También fue llamado TWI (Two Wire Interface) por otras tecnológicas por motivos de licencia hasta que esta venció en 2006. Ilustración 55. Logo del bus I2C. Este es un bus de comunicación serie síncrono que se utiliza principalmente para comunicar diferentes partes de un mismo circuito, como un controlador y sus circuitos periféricos, por ejemplo. El protocolo [55] utiliza únicamente dos cables para la transmisión y recepción de datos, SDA (datos en serie) y SCL (reloj serie), tal y como muestra la Ilustración 56. Además, I2C es multi-maestro, multi-esclavo, single-ended, transmite los datos a través del método de conmutación de paquetes y tiene acuse de recibo, que significa que el transmisor del mensaje recibe una notificación por parte del receptor si el mensaje ha llegado correctamente. Ilustración 56. Ejemplo de implementación de comunicación entre dispositivos mediante I2C.  El cable SDA es el medio por el cual se transmite o recibe el mensaje.  Por otro lado, el cable SCL porta la señal de reloj gobernada por el dispositivo maestro para que todos los dispositivos del bus estén sincronizados. 63  Repetición de la condición de inicio (Ilustración 69): Al final de cada mensaje de datos y el consiguiente bit de confirmación, el dispositivo maestro puede enviar un bit de arranque y comenzar una nueva transmisión sin necesidad de enviar un bit de parada antes. Esto permite al maestro comunicarse con varios esclavos con direcciones diferentes sin tener que ceder el control del bus I2C con el bit de parada. Este modo de funcionamiento puede aplicarse con el direccionamiento de 7 bits, el de 10 bits o el de formato libre. Ilustración 69. Estructura del mensaje en repetición de la condición de inicio. Últimas consideraciones: El bit correspondiente a lectura o escritura es 0 si el maestro quiere escribir y 1 si el maestro va a recibir información del esclavo. El número de bits que componen el mensaje de datos a transmitir o recibir se especifica en el campo “BC” del registro “I2CMDR”. SINCRONIZACIÓN DE LA SEÑAL DE RELOJ En el caso de que en el bus I2C haya más de un dispositivo maestro (Ilustración 70), sus señales de reloj deben ser sincronizadas para que los datos puedan ser escritos y leídos correctamente. Como todos los pines SCL del bus I2C están conectados entre sí, el dispositivo que primero genere un semiperiodo de nivel bajo prevalece sobre los demás, obligando al resto de dispositivos a iniciar su semiperiodo de nivel bajo. La señal de reloj se mantiene a nivel bajo durante el tiempo marcado por el dispositivo con el mayor semiperiodo a nivel bajo, mientras que el resto de los dispositivos deben esperar antes de iniciar sus semiperiodos de nivel alto. De esta manera se obtiene una señal de reloj SCL sincronizada, donde el dispositivo más lente determina la duración del semiperiodo de nivel bajo y el más rápido fija la duración del semiperiodo de nivel alto. Ilustración 70. Sincronización de la señal de reloj SCL. 64 2.6. Electrocardiograma (ECG) Un electrocardiograma (ECG, Ilustración 71) [59] es un procedimiento médico que detecta la actividad eléctrica del corazón en función del tiempo, puesto que cada vez que el corazón late, una señal eléctrica circula a través de él. Esta prueba [60] es ampliamente utilizada para valorar la condición del corazón de forma no invasiva y se usa para evaluar el estado del sistema de conducción del corazón a nivel muscular, pero también, de forma indirecta, la condición de este órgano como una bomba y la aparición de ritmos patológicos causados por daño al tejido de conducción de las señales eléctricas, otros trastornos no-cardíacos o para medir el valor del ritmo cardiaco. El ECG es la representación gráfica de la actividad bioeléctrica del músculo cardíaco, por lo que un equipo de registro de ECG (electrocardiógrafo) es comparable a un voltímetro midiendo diferencias de potencial eléctrico. Ilustración 71. Representación teórica de un ECG. La forma estándar [61] de un electrocardiograma registrando un latido cardíaco normal consiste en una onda “P”, un complejo “QRS” y una onda “T”, separados estos 3 eventos por 2 periodos o segmentos de inactividad. Después de la aparición de la onda “T”, existe otra pequeña onda “U”, pero esta última suele pasar desapercibida o directamente no registrarse porque es poco significativa.  La onda P es la señal eléctrica correspondiente a la despolarización auricular.  El complejo QRS (Ilustración 72), formado por las ondas Q, R y S, corresponde a la corriente eléctrica que causa la contracción de los ventrículos derecho e izquierdo, llamada despolarización ventricular, la cual es mucho más potente que la de las aurículas y hace trabajar a más masa muscular, produciendo de este modo una mayor deflexión en el electrocardiograma. Es debido a esto que la detección del complejo QRS es el que se suele utilizar para calcular el valor del ritmo cardiaco. 65 Ilustración 72. Representación del complejo QRS.  La onda T representa la repolarización de los ventrículos. Estos son eventos eléctricos que no deben ser confundidos con los eventos mecánicos correspondientes, es decir, a la contracción y relajación de las aurículas y ventrículos del corazón. De esta manera, la sístole mecánica o contracción ventricular comienza justo después del inicio del complejo QRS y culmina justo antes de terminar la onda T. La diástole, que es la relajación y rellenado ventricular posterior a la sístole, que corresponde con la contracción de las aurículas, se produce justo después de iniciarse la onda P. DERIVACIONES En electrocardiografía, una derivación se refiere a la medida del voltaje entre dos electrodos. Los electrodos se colocan sobre el cuerpo del paciente y se conectan al aparato de detección electrocardiográfica. Las derivaciones de un ECG utilizan diferentes combinaciones de electrodos para medir distintas señales procedentes del corazón desde ángulos diferentes. Para realizar un ECG estándar de 12 derivaciones se utilizan diez electrodos, para obtener 3 derivaciones periféricas y 9 precordiales. Sin embargo, para medir el valor del ritmo cardiaco es suficiente con utilizar las derivaciones I, II y III correspondientes a las derivaciones periféricas, las cuales se colocarán respectivamente en el brazo izquierdo, en el brazo derecho y en la pierna derecha (véase la Ilustración 73). Esta última metodología será la aplicada en el proyecto, ya que utilizaran 3 electrodos colocados en el brazo izquierdo, en el brazo derecho y en la pierna derecha. 66 Ilustración 73. Opciones de colocación de los electrodos periféricos según la American Heart Association (AHA).  La derivación I mide la diferencia de potencial entre el electrodo del brazo derecho y el izquierdo.  La derivación II mide la diferencia de tensión del brazo derecho a la pierna izquierda.  La derivación III mide la diferencia de potencial del brazo izquierdo a la pierna izquierda. ALGORITMO DE PAN-TOMKINS PARA DETECTAR QRS Algoritmo propuesto por Jiapu Pan y Willis J. Tompkins en 1985, en la revista IEEE “Transactions on Biomedical Engineering” [62] para detectar el complejo QRS de un electrocardiograma (ECG). Como el complejo QRS posee un pico muy representativo en la gráfica del ECG, esta característica lo hace especialmente adecuado para medir la frecuencia cardíaca. Este algoritmo [63] aplica una serie de filtros para resaltar el contenido de frecuencia de esta despolarización rápida del corazón y elimina el ruido de fondo (Ilustración 74). A continuación, eleva al cuadrado la señal para amplificar la contribución del QRS, lo que facilita la identificación del complejo QRS. Por último, se aplican umbrales adaptativos para detectar los picos de la señal filtrada. Ilustración 74. Diagrama de bloques de la fase de pre-procesado del algoritmo. Una vez reconocido el complejo QRS, el valor de la frecuencia cardiaca se calcula en función de la distancia entre dos complejos QRS consecutivos (o picos R). 𝐻𝐻𝐻𝐻(𝑏𝑏𝑏𝑏𝑚𝑚)=60 𝐻𝐻𝐻𝐻(𝑠𝑠) 67 SENSOR DE SPARKFUN (AD8232) El sensor que se utilizará en el proyecto para detectar las señales electrocardiográficas de los pacientes será el SparkFun Single Lead Heart Rate Monitor [64], basado en el AD8232 [65] exhibido en la Ilustración 75. Según el fabricante, este sensor se utiliza para medir la actividad eléctrica del corazón. Esta actividad eléctrica puede ser graficada como un electrocardiograma y la salida puede ser leída por un controlador como una señal analógica. Como los ECGs pueden ser extremadamente ruidosos, el sensor actúa como un amplificador operacional para ayudar a obtener una señal clara de los intervalos PR y QT de forma sencilla. El AD8232 es un bloque de acondicionamiento de señal integrado para ECG y otras aplicaciones de medición de marcadores. Está diseñado para extraer, amplificar y filtrar pequeñas señales eléctricas en presencia de condiciones ruidosas, como las creadas por el movimiento o la colocación de electrodos a distancia. Ilustración 75. Sensor electrocardiográfico. El sensor dispone de nueve conexiones a las que se pueden soldar pines, cables u otros conectores. /SDN, LO+, LO-, OUTPUT, 3.3V, GND proporcionan pines esenciales para operar este monitor con un Arduino u otra placa de desarrollo. También se proporcionan en esta placa los pines RA (brazo derecho), LA (brazo izquierdo) y RL (pierna derecha) para conectar y utilizar otras conexiones de electrodos. Pin Descripción de la conexión 3.3 V Tensión de alimentación GND Tierra OUPUT Salida de la señal analógica LOSeñal digital de desconexión - LO+ Señal digital de desconexión + /SDN Señal digital de apagado RL Entrada del electrodo de la pierna derecha LA Entrada del electrodo del brazo izquierdo RA Entrada del electrodo del brazo derecho 68 Además, hay un LED embebido en la PCB que se iluminará al mismo ritmo que los latidos del corazón. Los electrodos utilizados, expuestos en la Ilustración 76, también son del mismo fabricante [66]. Tienen una longitud de 24 pulgadas y poseen un conector jack de 3,5 mm para poder acoplarse al sensor descrito previamente. Ilustración 76. Electrodos. Es muy importante remarcar que la asignación correcta de los electrodos NO se corresponde con el código de colores que describe la web y el tutorial del fabricante [67] [68] (Ilustración 77), sino con el código de colores de la Ilustración 78. Ilustración 77. Colocación errónea de los electrodos. 69 Conexión CORRECTA de los electrodos: Brazo izquierdo Rojo Brazo derecho Negro Pierna derecha Azul Ilustración 78. Colocación correcta de los electrodos. Además, los electrodos deben conectarse a unos parches desechables que se adhieren a la superficie corporal del paciente, como los mostrados a continuación. Ilustración 79. Parches desechables para electrodos. 70 Por último, si se realiza una prueba de testeo del sensor de SparkFun se puede comprobar en la siguiente imagen cómo se detecta la forma de onda de un electrocardiograma de forma satisfactoria, diferenciándose fácilmente los componentes del ECG sin mucho ruido eléctrico. Ilustración 80. Gráfica de los valores detectados por el sensor. Complejos QRS 71 3. Desarrollo y programación del proyecto Una vez comprendido el funcionamiento de los microcontroladores F28069M y CC2650, y tras haber programado una serie de programas de prueba utilizando diferentes módulos como los GPIO, ADC, ePWM, I2C, BLE, las tareas de TI-RTOS y el tratamiento de las interrupciones; se van a desarrollar los 4 programas correspondientes a las especificaciones del trabajo definidas en el apartado de introducción y objetivos del proyecto. 3.1. Paso 1: F28069M_TX Programa del primer módulo F28069M. Este microcontrolador se encarga de recibir las señales electrocardiográficas del sensor de Sparkfun, les aplica el algoritmo de Pan-Tomkins para hallar el valor del ritmo cardiaco o BMP (Beats Per Minute) y transmite dicho valor a un módulo CC2650 mediante comunicación I2C en modo rápido o 'fast' (400 kHz), trabajando como dispositivo esclavo en el bus. Código significativo y explicación del programa: Árbol del proyecto en Code Composer Studio (Ilustración 81). Ilustración 81. Árbol del proyecto "F28069M_TX_P1". 72 MÓDULO ADC Se utiliza el módulo ADC (pin ADCINA4) para recibir los valores electrocardiográficos detectados por el sensor de Sparkfun (AD8232). Para ello se configura el ADC junto al módulo ePWM1 en la Ilustración 82 para que se genere una interrupción y poder muestrear la señal analógica a una frecuencia de 1 kHz. Ilustración 82. Código de la función "Config_ADC()". La instrucción “AdcRegs.ADCSOC1CTL.bit.CHSEL = ECG_PIN” selecciona el pin analógico ADCINA4 como entrada de la señal analógica y “AdcRegs.ADCSOC1CTL.bit.TRIGSEL = 5” asigna la señal del módulo ePWM1 como disparador. La frecuencia de muestreo (1 kHz), se rige por la siguiente fórmula (para el modo de funcionamiento “up count”) y se consigue asignando los valores de los factores en los registros correspondientes: 𝑓𝑓=𝑆𝑆𝑆𝑆𝑆𝑆𝐶𝐶𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 (𝑆𝑆𝑇𝑇𝑃𝑃𝐻𝐻𝑇𝑇+ 1)∗𝐻𝐻𝑆𝑆𝑃𝑃𝐶𝐶𝑆𝑆𝑆𝑆𝑇𝑇𝐼𝐼𝐻𝐻∗𝐶𝐶𝑆𝑆𝑆𝑆𝑇𝑇𝐼𝐼𝐻𝐻 =90 ∙106 (44999 + 1)∗2∗1=1000 𝐻𝐻𝐻𝐻 Una vez configurado el módulo ADC se programa la función que tratará la interrupción producida por el ADC (Ilustración 83). Así, cada vez que se produzca una interrupción (disparada por el módulo ePWM cada 1 ms), se leerá y almacenará en la variable “dato” el valor electrocardiográfico detectado por el sensor de Sparkfun. 79 Utilizando dicha herramienta (Ilustración 91), se introduce el nombre del servicio a implementar, su identificador (de 16 o 128 bis) y se definen el número de características que se quieren incluir. En este caso solo se implementará una característica, y por ende será necesario introducir su nombre, identificador (de 16 o 128 bits), la longitud de la característica y sus propiedades y permisos. Los UUIDs serán los definidos previamente (ambos de 16 bits) las propiedades y permisos serán únicamente de lectura, tal y como muestra la siguiente ilustración. Ilustración 91. Captura de la herramienta generadora de servicios. Una vez generado el servicio personalizado, se copiará el código de “your-service.h” en un nuevo fichero que se llamará “ConstantesVitales.h”, localizado en la carpeta “PROFILES”. Del mismo modo, el contenido de “your-service.c” se incluirá en un nuevo fichero “ConstantesVitales.c” ubicado en la misma carpeta. Dentro del fichero “ConstantesVitales.h” se localizan todas las constantes y las declaraciones de las funciones de la API, tal y como muestra la Ilustración 92. Ilustración 92. Constantes definidas en "ConstantesVitales.h". 80 Por otro lado, en el fichero “ConstantesVitales.c”, donde se ubica la definición y programación de todas las funciones que implementan el servicio “Heart Rate”, será necesario incluir las siguientes instrucciones (Ilustración 93 e Ilustración 94): Ilustración 93. Instrucción que añadir en "ConstantesVitales.c" (I). Ilustración 94. Instrucción que añadir en “ConstantesVitales.c” (II). Estas instrucciones se encargan de habilitar el uso de eventos como método de comunicación entre los procesos de comunicación del bus I2C y de la modificación del atributo de la característica del servicio “Heart Rate”. Por otro lado, dentro de la función “ConstantesVitales_ReadAttrCB()” (Ilustración 95) será necesario realizar la publicación de un evento con la instrucción “Event_post()” para indicar al proceso de comunicación I2C que el atributo de la característica ya ha sido leído por el dispositivo “central” o maestro conectado al microcontrolador CC2650. En este caso, el funcionamiento del evento es equivalente al levantamiento de un semáforo. Ilustración 95. Instrucción que añadir en "ConstantesVitales.c" (III). BLE Peripheral Los ficheros “ProjectZero.c” y “ProjectZero.h”, localizados en la carpeta “Application” serán renombrados a “BLE_Peripheral” (.c y .h respectivamente). Además, el fichero “.c” sufrirá las siguientes modificaciones (además de las eliminaciones de los 3 servicios de prueba mencionadas anteriormente):  Inclusión del fichero de cabecera del servicio “Heart Rate” (Ilustración 96). Ilustración 96. Modificación (I) en "BLE_Peripheral.c". 81  Modificación del nombre de dispositivo anunciante de servicios dentro del array “static uint8_t advertData[]” (Ilustración 97). Ilustración 97. Modificación (II) en "BLE_Peripheral.c".  Cambio del nombre del dispositivo (Ilustración 98). Ilustración 98. Modificación (II) en "BLE_Peripheral.c".  Se añade el servicio “Heart Rate” al servidor GATT dentro de la función “ProjectZero_init()” (Ilustración 99). Ilustración 99. Modificación (III) en "BLE_Peripheral.c". TAREA DE EJECUCIÓN DEL PROTOCOLO I2C Una vez implementado el servicio “Heart Rate” y configurado toda la parte del protocolo BLE, se va a introducir la tarea de ejecución del protocolo I2C con la creación de los ficheros “I2C_RX.c” e “I2C_RX.h” dentro de la carpeta “Application”. El código de este hilo de ejecución se basa en la explicación del tutorial de SimpleLink Academy y en el ejemplo “tmp007”. Primero se declara un array de dos números enteros sin signo de 8 bits (véase la Ilustración 100). El primer número siempre será 0, pues será el valor del atributo “Heart Rate Value Format bit”, indicando que el atributo “Heart Rate Measurement Value” (el segundo número del array) será de 8 bits. Después se declara el evento “readEvent” para posibilitar la comunicación entre los hilos de ejecución del protocolo BLE y el I2C. Ilustración 100. Código ubicado en el fichero "I2C_RX.c". 82 La función “I2C_RX_createTask()” (Ilustración 101) se responsabiliza de la creación de la tarea que ejecuta el funcionamiento de la comunicación I2C. Ilustración 101. Código de la función "I2C_RX_createTask()”. Esta tarea únicamente ejecutará una función, “I2C_RX_TaskFxn()” (Ilustración 102 e Ilustración 103), que será la encargada de realizar la comunicación a través del protocolo I2C con el primer microcontrolador F28069M, trabajando en modo maestro y recibiendo el valor del ritmo cardiaco a una velocidad de transmisión de 400 kbps [77] [78]. Ilustración 102. Código de la función “I2C_RX_TaskFxn()” (I). 83 Ilustración 103. Código de la función “I2C_RX_TaskFxn()” (II). En esta tarea se inicializa y configura el módulo I2C del microcontrolador, estableciendo la velocidad de transmisión, la dirección del dispositivo esclavo y las estructuras de datos a enviar y recibir a través del bus. Luego, dentro del bucle infinito (Ilustración 104), se esperará a la publicación del evento definido en el apartado “BLE Peripheral” para establecer la comunicación a través del protocolo I2C y recibir el valor del ritmo cardiaco y almacenarlo en la segunda posición del array “msg_recibido”. Antes de pasar a la siguiente iteración, se llama a la función “ConstantesVitales_SetParameter()” para modificar el valor del atributo de la característica “Heart Rate Measurement” con el nuevo valor del ritmo cardiaco recién recibido por el bus I2C. Ilustración 104. Código de la función “I2C_RX_TaskFxn()” (III). La razón por la cual los módulos CC2650 trabajan como dispositivos maestros en la comunicación I2C y no como esclavos es porque las funciones de la API únicamente permiten trabajar como dispositivo maestro. Si estos microcontroladores trabajaran como esclavos, harían el desarrollo del programa un grado más complejo, ya que sería necesario bajar el nivel de abstracción en la programación, y como la configuración de los microcontroladores F28069M como maestros o esclavos posee el mismo nivel de dificultad se ha decido que los CC2650 sean maestros y los dispositivos F28069M esclavos. 84 MAIN Por último, en el fichero “main.c” de la carpeta “Startup” se añade la inclusión del fichero “I2C_RX.h” (Ilustración 105) y dentro de la función “main()” se llama a la función que crea la tarea de ejecución del protocolo I2C “I2C_RX_createTask()” (Ilustración 106). Ilustración 105. Modificación (I) en "main.c". Ilustración 106. Modificación (II) en "main.c". 85 3.3. Paso 3: CC2650_Central_BLE Programa del segundo módulo CC2650. Este microcontrolador funciona en el rol de dispositivo maestro dentro del protocolo BLE, con el objetivo de buscar, descubrir y conectarse automáticamente al primer microcontrolador CC2650 para leer la característica 'Heart Rate Measurement' del servicio 'Heart Rate' cuando el usuario pulse la señal digital de entrada BUTTON1 (botón derecho de la PCB del microcontrolador). Únicamente se almacenará el segundo octeto de la característica, el cual corresponde al atributo “Heart Rate Measurement Value”, donde se localiza el valor del ritmo cardiaco, que es el dato que se quiere enviar al último microcontrolador del proyecto a través del bus I2C en modo maestro. Este programa se basa en el ejemplo de SimpleLink 'simple_central', explicado en el apartado de programas de prueba del microcontrolador CC2650 y se ha desarrollado con la ayuda del foro de Texas Instruments [79]. De esta manera, y al igual que con el programa para el primer módulo CC2650, la imagen “Stack” del programa permanecerá invariable y la parte “App” se modificará. Código significativo y explicación de la imagen “App” del programa: Árbol del proyecto en Code Composer Studio (Ilustración 107). Ilustración 107. Árbol del proyecto "CC2650_Central_BLE_P3". 86 SERVICIO “HEART RATE” Se añade una copia de los ficheros desarrollados en el programa anterior, “ConstantesVitales.c” y “ConstantesVitales.h”, en la carpeta “PROFILES”. BLE Central En el fichero “simple_central.c”, ubicado en la carpeta “Applications” se deberá modificar e incluir las siguientes líneas de código:  Se añade el módulo de eventos para habilitar la comunicación entre procesos (Ilustración 108). Ilustración 108. Modificación (I) del fichero "simple_central.c".  Se cambia el valor de la constante booleana “DEFAULT_LINK_WHITE_LIST” para utilizar la lista blanca de direcciones predefinidas de dispositivos para conectar el microcontrolador central al periférico automáticamente (Ilustración 109). Ilustración 109. Modificación (II) del fichero "simple_central.c".  Se cambia el valor de la constante booleana (Ilustración 110) “DEFAULT_DEV_DISC_BY_SVC_UUID” con el objetivo de descubrir solamente los dispositivos que implementan el servicio que nos interese (en este caso el “Heart Rate”). Ilustración 110. Modificación (III) del fichero "simple_central.c". 87  Modificación para la legibilidad del código (Ilustración 111). Se sustituye “MENU_ITEM_READ_WRITE” por “MENU_ITEM_READ”, ya que solo va a ser posible leer la característica del servicio. Ilustración 111. Modificación (IV) del fichero "simple_central.c".  Nombre del dispositivo (Ilustración 112). Ilustración 112. Modificación (V) del fichero "simple_central.c".  Se comenta la variable booleana que permite escribir el valor de la característica (Ilustración 113). Ilustración 113. Modificación (VI) del fichero "simple_central.c".  Dentro de la función “SimpleBLECentral_init()” (Ilustración 114) se introduce la dirección Bluetooth del dispositivo esclavo o periférico, la cual se deberá conocer de antemano y se añade dicha dirección a la “White List” después de haber sido vaciada. Es muy importante remarcar que la dirección Bluetooth debe ser introducida al revés, con el formato Little Endian, es decir, los bits están ordenados del menos significativo al más significativo. Ilustración 114. Fragmento de código de la función "SimpleBLECentral_init()". 88  En la función “SimpleBLECentral_processRoleEvent()” (Ilustración 115 e Ilustración 116) se comentan las siguientes líneas de código y se introducen unas nuevas con el objetivo de lograr el establecimiento automático de la conexión BLE buscando el identificador del servicio “Heart Rate”. Ilustración 115. Fragmento de código (I) de la función "SimpleBLECentral_processRoleEvent()". Ilustración 116. Fragmento de código (II) de la función "SimpleBLECentral_processRoleEvent()".  Ahora, dentro de la función “SimpleBLECentral_handleKeys()” (Ilustración 117, Ilustración 118, Ilustración 119 e Ilustración 120) se comentan todas las líneas de código correspondientes a la escritura del valor de la característica del servicio. Ilustración 117. Fragmento de código (I) de la función "SimpleBLECentral_handleKeys()". 95 Tras configurar el módulo I2C, se programa la función que tratará las interrupciones producidas por el microcontrolador maestro del bus (Ilustración 133). Ilustración 133. Código de la función "i2c_rx_isr()". Esta función se encarga de recibir el valor del ritmo cardiaco del segundo microcontrolador CC2650. Para ello, cuando se produzca la interrupción “RRDY” o “datos listos para ser recibidos”, el dato transmitido se almacenará en el registro “I2CDRR”, cuyo valor será asignado a la variable “resultado”. 96 3.5. Tabla de conexiones del proyecto Parches Electrodos Brazo izquierdo Rojo Brazo derecho Negro Pierna derecha Azul Sensor SparkFun MCU 1 (F28069M) 3.3 V 3.3 V GND GND OUTPUT ADCINA4 MCU 1 (F28069M) MCU 2 (CC2650) P33 (SCL) DIO4 (SCL) P32 (SDA) DIO5 (SDA) GND GND MCU 3 (CC2650) MCU 4 (F28069M) DIO4 (SCL) P33 (SCL) DIO5 (SDA) P32 (SDA) GND GND 97 3.6. Comprobación de resultados y captura del montaje final Utilizando las herramientas de depuración de Code Composer Studio, un analizador lógico digital y la aplicación para Android “BLE Scanner” se van a mostrar los resultados y el contenido de las variables que almacenan el valor del ritmo cardiaco en cada microcontrolador.  MCU 1 (F28069M): En la siguiente imagen se visualiza el buffer de BPM, así como el contador de microsegundos “EPwm2TimerIntCount” y la variable que almacena el valor del ritmo cardiaco que será transmitido a través del bus I2C, “bpm_media”. Ilustración 134. Captura (I) del depurador de CCS Conectando un analizador lógico digital en paralelo a los pines que forman el bus I2C se puede comprobar como la comunicación entre el primer F28069M y el primer módulo CC2650 se realiza de manera satisfactoria cada vez que se realiza una lectura de la característica en el MCU 3 (Ilustración 135). La dirección del dispositivo esclavo (el MCU 1) es 0x05 y el siguiente byte de la trama se corresponde con el valor del ritmo cardiaco. Ilustración 135. Captura (I) del programa Logic 2. 98  MCU 2 (CC2650): Cada vez que el segundo módulo CC2650 (MCU 3) realice una lectura de la característica del servicio “Heart Rate”, este microcontrolador, trabajando como dispositivo periférico en el protocolo BLE, mandará al MCU 1 la orden de que se envíe el valor BPM a través del bus I2C y lo almacenará en el segundo número del array “msg_recibido”. A continuación, se actualizarán los atributos “Heart Rate Value Format bit” y “Heart Rate Measurement Value” con los valores del array “msg_recibido”, tal y como se puede verificar con los valores del array “ConstantesVitales_ECGVal” (Ilustración 136). El valor del primer atributo siempre será 0 (msg_recibido[0]) porque eso significa que el tamaño del segundo atributo son 8 bits, y el valor del segundo atributo se corresponde con el valor del ritmo cardiaco (msg_recibido[1]). Ilustración 136. Captura (II) del depurador de CCS. Si se utiliza un smartphone con la aplicación “BLE Scanner” como dispositivo central o periférico para conectarse al CC2650 que trabaja como dispositivo periférico se comprueba que el microcontrolador tiene implementado el servicio “Heart Rate” y que la lectura del atributo de la característica “Heart Rate Measurement” se realiza satisfactoriamente. Descubrimiento y conexión al dispositivo CC2650 llamado “Ritmo Cardiaco” (Ilustración 137): Ilustración 137. Captura (I) de la app "BLE Scanner". 99 Se despliega el servicio “Heart Rate” y se pulsa en el botón virtual “R” (Ilustración 138) para realizar una lectura del atributo de la característica “Heart Rate Measurement”: Ilustración 138. Captura (II) de la app "BLE Scanner". El dispositivo CC2650 enviará el valor del ritmo cardiaco a la aplicación “BLE Scanner” (Ilustración 139): Ilustración 139. Captura (III) de la app "BLE Scanner". 100  MCU 3 (CC2650). Se abre un terminal de comunicación serie para visualizar la navegación por el menú de opciones cuando el dispositivo maestro se conecte al periférico. Cuando se abre el terminal serie (Ilustración 140) se observa que el dispositivo ya ha encontrado al CC2650 esclavo y se ha realizado la conexión de manera automática. Ilustración 140. Captura (I) del terminal serie. Se navega por el menú de opciones con el botón izquierdo (BUTTON1, Ilustración 141) hasta encontrar la opción “Read req”. Ilustración 141. Captura (II) del terminal serie. Se pulsa el botón derecho (BUTTON2, Ilustración 142) para enviar una solicitud de lectura del atributo de la característica que almacena el valor del ritmo cardiaco. Una vez recibido el mensaje, el valor BPM se muestra por el terminal serie. Ilustración 142. Captura (III) del terminal serie. 101 Puede comprobarse en el depurador de expresiones del IDE CCS (Ilustración 143) como la variable global “dato_ble” guarda el valor del ritmo cardiaco recibido a través del protocolo BLE. Este será el valor que se envía a través del bus I2C al último microcontrolador del proyecto. Ilustración 143. Captura (III) del depurador de CCS.  MCU 4 (CC2650). En este último dispositivo se recibe por el bus I2C el valor del ritmo cardiaco cada vez que el MCU 3 realiza una lectura del atributo de la característica “Heart Rate Measurement”. La variable “resultado” (Ilustración 144) es la encargada de almacenar el valor del ritmo cardiaco, tal y como muestra la siguiente imagen: Ilustración 144. Captura (IV) del depurador de CCS. Por último, se puede verificar que la comunicación a través del bus I2C es correcta con la ayuda del analizador lógico digital. En la siguiente ilustración se muestra una trama del mensaje enviado desde el MCU 3 al MC4. En ella se puede observar la dirección I2C del dispositivo esclavo (0x10) y en el segundo byte de la trama, el valor del rimo cardiaco en ese momento, 76 BPM. Ilustración 145. Captura (II) del programa Logic 2. 102 Foto de la implementación final del proyecto (Ilustración 146): Ilustración 146. Foto del montaje final del proyecto. Las placas de desarrollo LAUNCHXL-CC2650 pueden conectarse directamente a las LAUNCHXL-F28069M tanto por encima como por debajo, ya que la disposición de sus pines lo hace posible (formato “Booster Pack”), pero en la imagen anterior se muestran conectados mediante cables individuales por motivos de claridad y presentación. MCU 2 Sensor MCU 1 Electrodos MCU 3 MCU 4 103 4. Conclusiones El proyecto, consistente en el desarrollo de una infraestructura de software que habilite la comunicación inalámbrica (BLE) entre dos parejas de microcontroladores F28069M y CC2650, con el objetivo de transmitir el valor del ritmo cardiaco de un paciente, ha sido realizado de manera satisfactoria cumpliendo todas las especificaciones definidas en el apartado de introducción y objetivos del proyecto. Cada vez que se envíe la orden (pulsando el botón 1 del microcontrolador CC2650 que trabaja como dispositivo maestro en el protocolo BLE), el valor del ritmo cardiaco calculado en el primer módulo F28069M con el algoritmo de Pan-Tomkins en base a los valores del electrocardiograma detectados por el sensor de SparFun, será enviado a través del bus I2C al primer módulo CC2650. Después, el segundo microcontrolador CC2650, trabajando en modo maestro en el protocolo BLE, leerá el atributo de la característica “Heart Rate Measurement” del primer CC2650 (funcionando en modo periférico o esclavo). Una vez leído y almacenado el valor del ritmo cardiaco, este será enviado a través del bus I2C al segundo F28069M y último microcontrolador del proyecto, que guardará en su memoria dicho dato, tal y como marcan las especificaciones del trabajo. Como este trabajo es un primer acercamiento a la implementación de la comunicación inalámbrica en la plataforma de rehabilitación neuromotora RobHand, las líneas futuras de desarrollo deberían seguir los siguientes pasos:  En el programa del primer módulo F28069M habría que sustituir el algoritmo de Pan-Tomkins por los nuevos datos a enviar y, si su longitud difiere de 1 byte, será necesario aumentar el número de paquetes a enviar a través del bus I2C.  Del mismo modo, al programa del módulo CC2650 que trabaja como dispositivo periférico en el protocolo BLE, también será necesario introducir un número significativo de cambios. Estos estarán relacionados con el servicio y las características del protocolo BLE que se quieran implementar y, al igual que en el punto anterior, con el tamaño del mensaje a recibir a través del bus I2C.  Por otro lado, el programa del segundo microcontrolador CC2650 no requeriría de tantos cambios como en los dos programas previos. Solamente habría que modificar el tamaño de la característica a leer (y qué octetos), además del número de paquetes a transmitir a través del protocolo I2C si el mensaje excede en longitud a 1 byte.  Para acabar, en el último programa del proyecto, correspondiente al segundo microcontrolador F28069M, únicamente sería necesario modificar el número de paquetes de datos a recibir a través del bus I2C si el mensaje tiene un tamaño mayor a 1 byte. 104 Como puede observarse, los programas del segundo microcontrolador F28069M y del segundo módulo CC2650 serían los menos propensos a sufrir un gran número de modificaciones, mientras que los programas del primer módulo F28069M y del primer CC2650 necesitarían un mayor trabajo de adaptación con el cambio de las especificaciones. 111 6. Anexos Adjunto a este documento se encuentran dos carpetas. La carpeta “Code Composer Studio” almacena los 4 programas desarrollados para los microcontroladores del proyecto y en “Documentación” se encuentran todos los manuales técnicos y otros documentos digitales a los que se hace referencia a lo largo de este trabajo. 6.1. Cálculo resistencia pull-up para el bus I2C RESISTENCIA PULL-UP INTERNA DEL MICROCONTROLADOR F28069M Ilustración 147. Esquema de la resistencia pull-up embebida en la LaunchPad. Primero se va a observar el funcionamiento de la señal de reloj SCL del módulo I2C utilizando la resistencia pull-up embebida en la LaunchPad F28069M (Ilustración 147) a diferentes frecuencias de trabajo. 112  Frecuencia SCL de 100 KHz: Ilustración 148. Frecuencia señal SCL a 100 KHz.  Frecuencia de SCL de 400 KHz: Ilustración 149. Frecuencia señal SCL a 400 KHz. 113 Como puede observarse (Ilustración 148 e Ilustración 149), la señal de reloj tiene una forma deficiente y muy diferente a la ideal. Si se trabaja a 100 KHz con esta señal de reloj la comunicación I2C funciona correctamente, pero a frecuencias más altas, como a 400 KHz, por ejemplo, la comunicación es del todo imposible, puesto que los dispositivos esclavos detectan una frecuencia de reloj con un valor que se corresponde a la mitad del real. Para solucionar este contratiempo se va a desactivar la resistencia pull-up interna y se va a calcular e implementar una externa [80]. CÁLCULO RESISTENCIA PULL-UP El valor mínimo de la resistencia se calcula de forma muy sencilla con la siguiente ecuación: 𝐻𝐻𝑝𝑝(𝑚𝑚í𝐹𝐹)=𝐻𝐻𝐶𝐶𝐶𝐶 −𝐻𝐻𝑂𝑂𝑆𝑆(𝑚𝑚á𝑥𝑥) 𝐼𝐼𝑂𝑂𝑆𝑆 𝐻𝐻𝑂𝑂𝑆𝑆 es el máximo valor de tensión que es considerado como nivel lógico bajo. Por otro lado, el cálculo de la resistencia máxima es algo más complejo. Este valor máximo está limitado por la capacitancia del bus, 𝐶𝐶𝑏𝑏, debido a las especificaciones del protocolo I2C en cuanto a tiempo de subida. Si la resistencia es demasiado grande, la señal no llegará a nivel alto antes de que llegue el momento de volver a cambiar el nivel lógico. La ecuación [81] que caracteriza este comportamiento en la siguiente: 𝐻𝐻(𝑡𝑡)=𝐻𝐻𝐶𝐶𝐶𝐶 ∙�1−𝐹𝐹−𝑡𝑡 𝑅𝑅𝐶𝐶� Para 𝐻𝐻𝐼𝐼𝐼𝐼 = 0,7 ∙𝐻𝐻𝐶𝐶𝐶𝐶 =𝐻𝐻𝐶𝐶𝐶𝐶 ∙�1−𝐹𝐹−𝑡𝑡1 𝑅𝑅𝑅𝑅 � Para 𝐻𝐻𝐼𝐼𝑆𝑆 = 0,3 ∙𝐻𝐻𝐶𝐶𝐶𝐶 =𝐻𝐻𝐶𝐶𝐶𝐶 ∙�1−𝐹𝐹−𝑡𝑡2 𝑅𝑅𝑅𝑅 � De esta manera, el tiempo de subida será 𝑡𝑡𝑟𝑟=𝑡𝑡2−𝑡𝑡1= 0,8473 ∙𝐻𝐻𝑝𝑝∙𝐶𝐶𝑏𝑏, por lo que la resistencia máxima es: 𝐻𝐻𝑝𝑝(𝑚𝑚á𝑥𝑥)=𝑡𝑡𝑟𝑟 0,8473 ∙𝐶𝐶𝑏𝑏 114 Ahora se consultan las especificaciones de los parámetros del protocolo I2C (Ilustración 150) para obtener los datos de las ecuaciones a resolver: Ilustración 150. Especificaciones del protocolo I2C. Tabla de Texas Instruments. Se halla el rango de resistencias adecuado para los siguientes datos: 𝐻𝐻𝐶𝐶𝐶𝐶 = 3,3 𝐻𝐻; 𝑡𝑡𝑟𝑟=300 ∙10−9 𝑠𝑠 (queremos 400 Kbit/s); 𝐶𝐶𝑏𝑏=200 ∙10−12 𝐹𝐹 𝐻𝐻𝑝𝑝(𝑚𝑚í𝐹𝐹)=3,3 −0,4 3∙10−3 =966,67 Ω 𝐻𝐻𝑝𝑝(𝑚𝑚á𝑥𝑥)=300 ∙10−9 0,8473 ∙200 ∙10−12 = 1,77 𝑆𝑆Ω Tras calcular el rango de resistencias hay que decidirse por un valor concreto. Cuanto más pequeña sea la resistencia mejor para la velocidad de conmutación entre niveles lógicos, pero el consumo de corriente será mayor; mientras que cuanto mayor sea la resistencia se consumirá menos corriente, pero la velocidad de cambio será menor. De esta manera, se eligen dos resistencias pull-up de 1 KΩ, una para cada línea del bus, SDA y SCL. Por último, se comprueba la forma de la señal y su funcionamiento con la ayuda del osciloscopio digital y se observa que los resultados (Ilustración 151 e Ilustración 152) son mucho mejores que con la resistencia interna del microcontrolador, además de que la frecuencia que detecta el osciloscopio digital de la señal de reloj es prácticamente idéntica a la teórica. 115 RESULTADOS  Frecuencia de SCL de 100kHz: Ilustración 151. Frecuencia señal SCL a 100 KHz.  Frecuencia de SCL de 400kHz: Ilustración 152. Frecuencia señal SCL a 400 KHz.