ESTUDIO Y ADAPTACIÓN DEL PROGRAMA VTF

Transcripción

1 Estudio y realización de un enlace Bluetooth para el sistema de 115 Capítulo 5 ESTUDIO Y ADAPTACIÓN DEL PROGRAMA VTF Ha sido necesario realizar pequeñas modificaciones en el código del programa VTF para adecuar su funcionamiento a las peculiaridades del modo de operación del módulo Bluematik. Para ello se ha analizado en profundidad el funcionamiento de dicho código y se ha contrastado con los resultados obtenidos en el laboratorio. La mayor parte de la problemática procede del hecho de que las líneas DTR y RTS del puerto serie virtual no están cableadas en la interfaz de la UART con el dispositivo anfitrión, sino que éste las debe deducir del procesamiento de las respuestas +BMSC, como se hace en el código del PIC16F636. Otros problemas han sido el retraso que se introduce entre los caracteres transmitidos desde el dispositivo remoto, debido al propio enlace Bluetooth, y el cambio de velocidad que debe realizarse para las dos fases de carga de programas. A continuación veremos estos problemas con mayor detalle y describiremos la solución adoptada.

2 Estudio y realización de un enlace Bluetooth para el sistema de Problema de la primera carga En el análisis del funcionamiento del módulo Bluematik hemos visto que una vez establecido el puerto serie virtual, el anfitrión recibe dos respuestas la primera vez que se abre: TxD: +BMSC:9,0 TxD: +BMSC:8,0 Esto es un pulso en la línea DTR del puerto serie virtual. Si, tras el establecimiento del puerto serie virtual, intentamos cargar un programa en la tarjeta de desarrollo mediante el VTF, obtenemos el siguiente resultado: Ilustración 5-1: comportamiento de TxD (arriba) y MUM (abajo) en la primera carga. Vemos que se reciben cuatro respuestas, asociadas a los cambios en las líneas DTR y RTS, y una serie de datos que debe ser el código del cargador intermedio. Se observa que parte de estos datos están entre las dos últimas respuestas. Vamos a ver lo que se recibe por la línea TxD. Debido a que el Cargador intermedio esta formado por caracteres ASCII que pueden no ser imprimibles, veremos la representación hexadecimal de lo que llega:

3 Estudio y realización de un enlace Bluetooth para el sistema de 117 TxD: 0D0A2B424D53433A392C300D0A 'Respuesta +BMSC:9,0 TxD: 0D0A2B424D53433A382C300D0A 'Respuesta +BMSC:8,0 TxD: 0D0A2B424D53433A412C300D0A 'Respuesta +BMSC:A,0 TxD: FF8E01FFCE A73C8630A72B860CA72D18CEFF 'Cargador intermedio TxD: 0D0A2B424D53433A382C300D0A 'Respuesta +BMSC:8,0 TxD: FF C000026F886FFA72F1F2E2006A62F81FF27 'Cargador intermedio 061F2E80F220E F2E20FCA62F1F2E20FCE6 2F B1F2E20FCE62FC1FF27231B97001F2E20 FCA62F18A B AC10026EC86FF90001F 2E80FCA72F20BEFCFFD618ED00C609183A18FFFFD686 2CA72DFEFFFE6E00 Lo que ha ocurrido es que el pulso inicial de la línea DTR genera las dos respuestas +BMSC no esperadas. Estas retrasan las respuestas asociadas al reset, de manera que cuando se empieza a recibir el Cargador intermedio aún no se ha generado la segunda respuesta asociada a RTS y el Cargador intermedio se recibe separado en dos bloques. Como no puede haber una separación mayor de 4 tiempos de bytes (33 ms a 1200 bps para el formato serie 8, n, 1) entre los caracteres del Cargador intermedio, la carga es incorrecta. 5.2 Problema de la latencia del enlace Bluetooth Aunque los caracteres del Cargador intermedio son enviados al puerto serie virtual de manera correlativa, sin retardo entre ellos, el procesamiento de la arquitectura Bluetooth introduce cierto retraso entre caracteres que puede ser confundido en la tarjeta de desarrollo con el fin del envío del cargador intermedio. Este fenómeno se observa en las cargas posteriores a la primera, en las que no existen pulsos no deseados de la línea DTR y el Cargador intermedio llega en un solo bloque.

4 Estudio y realización de un enlace Bluetooth para el sistema de 118 Ilustración 5-2: TxD (arriba) y MUM (abajo) en la segunda carga. A pesar de que el Cargador intermedio no es interrumpido por ninguna respuesta, la carga es incorrecta debido al excesivo retraso entre los caracteres recibidos. Una ampliación de la captura de osciloscopio nos permite ver que los retrasos superan los 33 ms permitidos: Ilustración 5-3: ampliación para ver retrasos entre caracteres. La escala de tiempos es 50 ms.

5 Estudio y realización de un enlace Bluetooth para el sistema de Problema del cambio de velocidad La programación de la tarjeta de desarrollo se realiza en dos fases, una a 1200 bps para la carga del Cargador intermedio y otra a 9600 bps para la carga del monitor en tiempo real y programa de usuario. Entre una y otra el PIC16F636 reconfigura la UART del módulo Bluematik a la velocidad adecuada. Esto puede tardar hasta 1 segundo, como podemos ver en la siguiente captura del osciloscopio: Ilustración 5-4: líneas TxD (arriba) y MUM (abajo) cuando se cambia la velocidad del módulo Bluematik a 9600 bps tras el cargador intermedio. Esto no supone ningún problema ya que el programa VTF espera hasta 2 segundos el envío por parte del Cargador intermedio del carácter $FF, que indica que puede comenzar la carga del monitor en tiempo real y el programa de usuario. Sin embargo, si, una vez programada la tarjeta de desarrollo con éxito, volvemos a programarla, la programación falla. Esto se debe a que el VTF manda un Reset y a continuación el Cargador intermedio, y mientras éste se envía el módulo Bluematik realiza el cambio de velocidad (ya que estaba configurado a 9600 bps y debe pasar a 1200 bps), por lo que las respuestas consecuencia del cambio de velocidad se intercalan con el Cargador intermedio.

6 Estudio y realización de un enlace Bluetooth para el sistema de 120 Ilustración 5-5: líneas TxD (arriba) y MUM (abajo) al reprogramar la tarjeta de desarrollo. En esta ilustración vemos que al volver a programar lo primero que nos llega son los mensajes correspondientes al Reset (las dos primeras bajadas de MUM). A continuación llegan los primeros datos del cargador intermedio y seguidamente se cambia la velocidad a 1200 bps (las dos siguientes bajadas de MUM son los mensajes OK y +BURT:5,0,0). Tras esto llega el resto del Cargador intermedio. Lógicamente, la programación falla. Para evitar esto necesitamos saber cuánto dura el cambio de velocidad. Esto se averigua fácilmente mandando un Reset tras la programación (correcta o no) de la tarjeta de desarrollo: Ilustración 5-6: líneas TxD (arriba) y MUM (abajo) al mandar Reset desde VTF. La duración del proceso es aproximadamente 1.5 segundos.

7 Estudio y realización de un enlace Bluetooth para el sistema de Soluciones adoptadas Se han tomado dos soluciones a los problemas anteriores basados en estrategias muy distintas. El problema de la latencia se ha resuelto en el propio código del PIC16F636 mientras que el de la primera carga y el cambio de velocidad se ha solucionado modificando el código del programa VTF Solución al problema de la latencia Este problema se ha resuelto configurando el parámetro MFS del módulo Bluematik a su tamaño menor. MFS es el tamaño máximo de los datos Bluetooth, y se ha observado que disminuyéndolo el retraso entre caracteres se hace menor. El menor tamaño que se puede configurar es $2C, y el comando utilizado es AT+BMFS=2C, el cual está incluido en el código del microcontrolador. A continuación vemos dos capturas de osciloscopio donde se muestra la diferencia de duración del cargador intermedio con MFS configurado a $140 (valor por defecto) y a $2C. Ilustración 5-7: duración del Cargador intermedio (arriba) con MFS = $140 y línea MUM (abajo).

8 Estudio y realización de un enlace Bluetooth para el sistema de 122 Ilustración 5-8: duración del Cargador intermedio (arriba) con MFS = $2C y línea MUM (abajo). Vemos que la duración se reduce en casi 1 segundo. Al ampliar la captura se observa que la separación entre caracteres no supera el tiempo crítico de 33 ms y la carga del programa finaliza correctamente. Ilustración 5-9: ampliación de la captura con MFS = 2C. Se han realizado otras pruebas que demuestran que el mérito no se debe exclusivamente a la disminución de MFS. El módulo Bluematik empieza a recibir el Cargador intermedio cuando está emitiendo la respuesta +BMSC:8,0. Mientras MUM está a 0 el Bluematik no puede transmitir el Cargador intermedio, sólo respuestas, de manera que una parte del Cargador intermedio se almacena en la memoria interna del módulo Bluematik. Cuando MUM sube, se empieza a transmitir el Cargador intermedio.

9 Estudio y realización de un enlace Bluetooth para el sistema de 123 Los datos almacenados en la memoria son transmitidos de manera correlativa, hasta que la memoria se vacía y se transmiten los datos que van llegando. Estos presentan retrasos, pero inferiores a 33 ms. Si introducimos un retraso suficientemente grande en el código del VTF tras el reset, de manera que el Cargador intermedio no se almacena en la memoria del Bluematik, en algunos casos aparece algún retraso entre datos superior a 33 ms y la carga finaliza incorrectamente Solución al problema de la primera carga y del cambio de velocidad Aunque son dos problemas separados se pueden resolver de la misma forma. Resolverlos de manera independiente reduciría en algunos casos en algo más de medio segundo el tiempo de carga de la tarjeta de desarrollo, sin embargo habría que tener en cuenta una casuística elevada (si se programa tras pulsar el Reset, si se programa por primera vez pero el puerto ha sido abierto anteriormente, si se programa una tarjeta que ya estaba programada y que estábamos monitorizando ). La solución que se ha adoptado evita todos estos casos. Estos dos problemas tienen algo en común. Las respuestas del Bluematik se intercalan con el Cargador intermedio porque este es enviado demasiado cerca del Reset. Sin embargo esta proximidad con el Reset afecta positivamente a la latencia de los datos. Así pues debemos retrasar el envío del Cargador intermedio pero manteniéndolo próximo al Reset. La solución consiste en insertar otro Reset justo al abrir el puerto serie virtual, dejar pasar un tiempo para que se reciban las respuestas de cambio de velocidad o pulso de DTR, y finalmente mandar otro Reset seguido del Cargador intermedio. Esto es muy sencillo de programar en Visual Basic 6.0. En el formulario principal se ha creado una variable booleana que representa al medio: Public canal_bluetooth As Boolean 'Si es verdadero indica que se va a 'realizar la programación vía Bluetooth Esta variable es inicializada en el procedimiento Form_Load: canal_bluetooth = False 'Inicialmente la programación es por cable

10 Estudio y realización de un enlace Bluetooth para el sistema de 124 También se ha creado un botón de comando (denominado bt_canal_tx) en el que aparece un icono que representa el canal usado para realizar la programación (Bluetooth o cable serie). Al pulsarlo cambiamos el medio: Ilustración 5-10: interfaz del programa VTF modificado. El procedimiento que realiza esto es el siguiente: Private Sub bt_canal_tx_click() If canal_bluetooth = False Then bt_canal_tx.picture = LoadPicture(App.Path & "\iconos\bt_bluetooth.gif") canal_bluetooth = True Else bt_canal_tx.picture = LoadPicture(App.Path & "\iconos\bt_cable232.gif") canal_bluetooth = False End If End Sub

11 Estudio y realización de un enlace Bluetooth para el sistema de 125 En el procedimiento boton_carga se ha incluido una línea para cargar inicialmente el icono del botón de comandos: bt_canal_tx.picture = LoadPicture(App.Path & _ "\iconos\bt_cable232.gif") Finalmente, en la función envio_prg, tras la línea com_link_inicio incluimos el siguiente código que resuelve el problema: If canal_bluetooth = True Then com_link.rtsenable = True espera_t 0.5 com_link.rtsenable = False 'Introduzco un retardo para que no 'se solape el cargador intermedio con las 'señales DTR y RTS en el Bluematik espera_t 1.5 End If Con estos cambios vemos que la programación usando Bluetooth se realiza de forma correcta: Ilustración 5-11: líneas TxD (arriba) y MUM (abajo) al realizar la primera programación.

12 Estudio y realización de un enlace Bluetooth para el sistema de 126 Ilustración 5-12: líneas TxD (arriba) y MUM (abajo) al reprogramar la tarjeta de desarrollo. 5.5 Otras modificaciones Se ha modificado el Manual del usuario del VTF comentando el uso del botón Canal. Se ha comprobado que en el programa original el bit DWOM del registro SPCR estaba a 1 (salidas del puerto D en colector abierto) tras el envío del Cargador intermedio. Por ello se ha modificado el código del Cargador intermedio (fichero carg.asm) para que DWOM permanezca a 0 (salidas CMOS), incluyendo las siguientes líneas: SPCR EQU $28 ; Justo al principio del fichero LDAA #$4 ; Bajo LDX #$1000 STAA SPCR,X También se ha modificado y personalizado el formulario frm_acerca_de.