DESCRIPCIÓN DEL HARDWARE DEL SISTEMA Y...

Estudio y realización de un enlace Bluetooth para el sistema de 1 desarrollo basado en el MC68HC11

Ingeniería de Telecomunicación Iván Cuenca Zaldívar

Capítulo 1

DESCRIPCIÓN DEL HARDWARE DEL SISTEMA Y FUNCIONAMIENTO BÁSICO

El sistema de desarrollo del MC68HC11 obtenido al término de este

proyecto consta de los elementos originales, es decir, la tarjeta de desarrollo

creada en el Departamento de Ingeniería Electrónica, el cable RS-232 y el

programa VTF, con algunas modificaciones que se comentarán posteriormente,

y también de aquéllos que le proporcionan la característica inalámbrica, como

son los módulos de comunicación vía radio y la tarjeta interfaz entre el módulo

inalámbrico y la tarjeta de desarrollo. A continuación veremos una descripción

de todos estos elementos y sus características principales.



1.1 Planteamiento inicial. Sistema de desarrollo del MC68HC11

Como ya se ha comentado, los puntos de partida de este proyecto son la

tarjeta de desarrollo del MC68HC11 y el programa VTF, que se comunican por

el puerto serie. Veamos una descripción de estos elementos.

Figura 1-1: esquema del sistema de desarrollo original.

1.1.1 Tarjeta de desarrollo del MC68HC11

La tarjeta usada en el proyecto alberga un microcontrolador

MC68HC11E1. Este se diferencia de sus hermanos de la familia M68HC11 en

que incorpora 512 bytes de RAM y 512 bytes de EEPROM. La tarjeta permite

la comunicación con el puerto SCI a través de un conector DB9 hembra. De

sus 9 líneas sólo se usan 5:

• TxD (Pin 2): conectado a PD1 (línea de transmisión del SCI).

• RxD (Pin 3): conectado a PD0 (línea de recepción del SCI).

• CTS (Pin 7): conectado a XIRQ.

• DTR (Pin 4): conectado al RESET.

• GND (Pin 5): conectada a la tierra de la tarjeta.

En el apartado correspondiente a la norma RS-232 veremos las

polaridades de las líneas anteriores y con qué niveles de tensión se activan el

RESET y XIRQ.



También posee numerosos jumpers para configurar el microcontrolador

en sus distintos modos de arranque, seleccionar periféricos, desconectar las

señales anteriores del conector DB9 y numerosos conectores que exteriorizan

las entradas y salidas del microcontrolador. Se ha trabajado con la siguiente

configuración de los jumpers de la tarjeta de desarrollo:

• JEPROM en modo 8K.

• JA13 y JA14 en modo VCC.

• JWE en modo WR.

• JTXD en modo TXD.

• JRXD en modo RXD.

• JXIRQ cortocircuitado.

• MODA y MODB cortocircuitados. El microcontrolador arranca en modo

Bootstrap. Posteriormente se configurará en modo expandido.

• JVRH y JVRL cortocircuitados.

• JRI abierto o cortocircuitado, según la necesidad de cada momento.

• JE0 abierto.

Ilustración 1-1: tarjeta de desarrollo del MC68HC11.



Además, sólo dispondremos de un módulo de memoria RAM de 32

Kbytes ubicado en el zócalo EPROM de la tarjeta. El mapa de memoria es de

64 Kbytes y está configurado mediante el jumper JEPROM en el modo 32 + 8

Kbytes. Esto significa que en modo expandido sólo están disponibles para RAM

los 32 Kbytes más bajos y los últimos 8 Kbytes (el resto se reserva para

direccionar periféricos externos mediante las señales CS0 a CS5 del conector

denominado SLOT). Como sólo disponemos de un módulo RAM, el programa

monitor y el programa de usuario cargados por el VTF sólo podrán situarse en

los 8 Kbytes más altos del mapa de memoria, simulando el caso de tener una

memoria EPROM de 8 Kbytes en esa misma dirección.

Figura 1-2: mapa de memoria del MC68HC11E1.

En cuanto a su funcionamiento, el microcontrolador, debido a la

configuración de la tarjeta, arranca en modo Bootstrap. En este modo, el

MC68HC11 permanece a la espera de recibir por el puerto SCI los bytes del

fichero binario que constituyen el programa que va a ejecutar.

Modo Bootstrap Modo expandido$0000

$1000

$01FFRAM

512 bytes

$103FRegistros 64 bytes

$8000

$B600

$B7FF EEPROM 512 Bytes

$DFFF

$FFFF$FFC0 Vector de

interrupciones

$BF00$BFFF

Vectores de interrupción de

modos especiales

Boot ROM

$BFC0

RAM Ext.

RAM Externa

RAM Externa



Estos bytes se envían directamente por el puerto serie del ordenador en

formato 8, n, 1 (8 bits de datos, ningún bit de paridad y un bit de parada)

correspondiente a la norma RS-232. Posteriormente veremos esta norma más

detalladamente. En este modo de funcionamiento sólo se admiten dos

velocidades de transmisión por el puerto SCI: 1200 bps y 7812 bps. Para

determinar a cuál de ellas se está enviando el código, el primer byte enviado

debe ser el $FF. Mediante este byte se determina la velocidad de transmisión

del puerto SCI según se ilustra en la siguiente figura:

Figura 1-3: método para hallar la velocidad de comunicación en el modo Bootstrap.

El puerto SCI está muestreando a 7812 bps, de manera que si la

velocidad a la que se transmite el código es 7812 bps, el primer carácter

recibido se interpreta correctamente como $FF. Si por el contrario la velocidad

de transmisión es 1200 bps, el primer carácter se interpreta como $E0 o $C0 y

se cambia la velocidad de transmisión del SCI a 1200 bps. A continuación se

reciben los bytes correspondientes al programa que se va almacenando a partir

de la posición de memoria $0000, correspondiente a la RAM interna. El

microcontrolador decide que la recepción del programa ha concluido cuando no

recibe nada durante el tiempo correspondiente a 4 bytes. Seguidamente se

carga en el contador de programa la dirección $0000 y comienza a ejecutarse

el programa.

0 1 1 1 1 1 1 1 1 1

1 1 1 0 / 10 0 0 0 0 0

Start Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Stop

Start Bit 0

$FF @ 7812 bps

Instantes de muestreo en Rx

Instantes de muestreo en Rx

$FF @ 1200 bps

Interpretado en Rx como $FF

Interpretado en Rx como $C0 / $E0



1.1.2 El programa VTF

Es un programa desarrollado en Visual Basic 6.0 en el proyecto fin de

carrera de Víctor José Tienda Flores. El objetivo de dicho proyecto consistía en

que el sistema de desarrollo emulara lo más fielmente posible el

funcionamiento del código del usuario, cuando dicho código se alojara en la

EPROM del microcontrolador.

Ilustración 1-2: aspecto de la interfaz del VTF.

El VTF es una interfaz de usuario que permite cargar en la memoria de la

tarjeta de desarrollo el programa del usuario. Dicho programa debe estar en un

fichero codificado en formato S19 de Motorola. Una vez cargado, éste se

ejecuta y el VTF permite realizar las siguientes operaciones:

• Parar y reanudar la ejecución.



• Leer zonas de la memoria del microcontrolador y volcarlos a ficheros

binarios.

• Leer y escribir en los registros del microcontrolador.

• Leer los caracteres recibidos por el puerto serie.

• Enviar caracteres al microcontrolador por el puerto serie.

• Activar la interrupción XIRQ.

• Activar el RESET.

• Elección del puerto COM utilizado para la comunicación con la tarjeta.

• Elección de las direcciones de inicio donde serán ubicados el programa

de usuario y el programa monitor, que es el que proporciona la mayor

parte de las funcionalidades anteriores.

Todo esto y algunas cosas más se pueden consultar en el Manual del

Usuario presente en el menú Ayuda del VTF.

Para poder abordar el problema de la sustitución del cable serie por un

enlace inalámbrico es necesario conocer en un poco más de profundidad, que

la que ofrece el Manual del Usuario, de qué manera se produce la

programación y monitorización del MC68HC11. Este proceso se produce

básicamente en dos fases, atendiendo a la velocidad de transmisión:

• En primer lugar el VTF envía una señal de RESET a la tarjeta de

desarrollo, de manera que esta se reinicia en modo Bootstrap. A

continuación envía a 1200 bps el carácter $FF con lo que el puerto SCI

se configura a esta velocidad y se prepara para la recepción del código.

Tras el carácter $FF el VTF envía el código del denominado “Cargador

intermedio”, del fichero en formato S191. En realidad sólo manda la parte

de los datos de cada línea del fichero, no manda los campos longitud,

1 Para más información sobre el formato S19 de Motorola, consultar Anexo IV.



dirección ni checksum. Una vez recibido el Cargador intermedio, es

decir, cuando pasa el tiempo correspondiente a 4 bytes sin recibir nada,

comienza su ejecución. Se pasa a modo extendido, con lo cual se puede

acceder a la memoria externa, se cambia la velocidad de transmisión a

9600 bps y se envía repetidamente el carácter $FF por la línea TxD

hacia el PC.

Figura 1-4: proceso de programación. Fase a 1200 bps.

• A partir de ahora y hasta que se produzca una reprogramación, la

velocidad de transmisión será de 9600 bps. Tras el envío del Cargador

intermedio el VTF configura el puerto serie del PC a 9600 bps. Cuando

recibe el carácter $FF procedente de la tarjeta responde a su vez con

$FF de manera que el Cargador intermedio deja de mandar $FF y se

prepara para recibir los códigos de dos programas más. El VTF envía los

ficheros en formato S19 de Motorola del Monitor en tiempo real y del

programa del usuario, en este orden. A diferencia del Cargador

intermedio, ahora también se envían los campos dirección y tamaño.

Desde la tarjeta se responde a cada línea de los ficheros S19 recibidos



con un checksum, que es comprobado por el VTF para verificar que la

programación se está realizando correctamente. Al concluir el envío de

estos programas, que han sido ubicados en las posiciones especificadas

en el VTF, el Cargador intermedio realiza algunas operaciones y por

último se comienza a ejecutar el programa de usuario.

Figura 1-5: proceso de programación. Fase a 9600 bps.

La manera en que el VTF interactúa con el programa de usuario que se

está ejecutando consiste en mandar determinados caracteres, según el tipo de

operación que se quiere realizar, por el puerto serie. Esto hace que se ejecute

la rutina de interrupción del puerto SCI. Dicha rutina es parte del Monitor en

tiempo real, de manera que lo que se hace es pasarle el control y el Monitor en

tiempo real realiza la operación correspondiente. Al salir de la rutina prosigue la

ejecución del programa de usuario. Esta comunicación entre el PC y la tarjeta

de desarrollo se sigue realizando a 9600 bps, por lo que monitorizar el

MC68HC11 no debe ser un problema adicional para el desarrollo del sistema

inalámbrico.



Por último vamos a comentar las limitaciones del sistema de desarrollo original

que serán heredadas en el sistema definitivo, ya que se ha tratado de mantener

el esquema básico de funcionamiento del sistema original lo más intacto

posible:

• La configuración de los jumpers de la tarjeta debe ser la descrita

anteriormente.

• El watchdog no debe ser habilitado, ya que el usuario puede parar la

ejecución del programa durante un tiempo ilimitado, lo que haría que el

watchdog reseteara el microcontrolador, en caso de estar activo.

• El usuario sólo puede enviar caracteres al MC68HC11 a través del

terminal correspondiente del VTF. Previamente al envío del carácter, el

VTF envía un carácter de control para el Monitor en tiempo real, de

manera que el programa del usuario recibirá el carácter

aproximadamente 1 ms (el tiempo de un byte a 9600 bps) más tarde de

cuando debía haberlo recibido.

• No se debe cambiar la configuración del puerto SCI.

• No se debe anular la interrupción del puerto SCI ni hacer que alguna

rutina tenga mayor prioridad que la del puerto SCI.

• Si el usuario quiere recibir caracteres por el puerto SCI, debe hacerlo por

interrupción, no por espera activa.

1.1.3 La norma RS-232

La comunicación entre el VTF y la tarjeta de desarrollo se realizan en el

sistema original a través de un cable siguiendo el estándar RS-232. Es

conveniente conocer en detalle el nivel físico y el nivel de enlace de esta norma

para el posterior desarrollo del proyecto.

La RS-232 es una norma de transmisión serie asíncrona muy utilizada en

la industria y usada para la comunicación entre módems, ordenadores, etc. Al

ser la comunicación serie los bits se transmiten unos tras otros por la misma

línea. Por ser asíncrona, no existe un reloj común entre trasmisor y receptor, de

manera que se usa un bit para marcar el inicio de la trama y otro para el final.



Respecto a los datos transmitidos o recibidos, el estándar establece lo

siguiente:

• Niveles de tensión comprendidos entre -15 y -3 V se corresponden con el

nivel lógico ‘1’.

• Niveles de tensión comprendidos entre +3 y +15 V se corresponden con

el nivel lógico ‘0’.

• El reposo corresponde con el nivel lógico ‘1’, es decir, entre -15 y -3 V.

Para el resto de señales de la interfaz RS-232 se distingue:

• Señal activada: su nivel de tensión es superior a +3 V.

• Señal desactivada: su nivel de tensión es inferior a -3 V.

Los conectores usados son el DB25 y el DB9, tanto en sus versiones

macho como hembra. El conector macho se usa en los equipos DTE (equipo

terminal de datos, como el ordenador) y el hembra en el DCE (equipo de

comunicación de datos, como el módem o en nuestro caso la tarjeta de

desarrollo). A continuación vemos el aspecto, numeración y nomenclatura de

los pines del conector DB9, que es el usado en el sistema de desarrollo:

Figura 1-6: conectores DB9 macho (izquierda) y hembra (derecha) y numeración de pines.

1 2 3 4 5 5 4 3 2 1

6 7 8 9 9 8 7 6



Conector DB9 macho Conector DB9 hembra

Pin Nombre Dirección Nombre Dirección

1 DCD Entrada DCD Salida

2 RxD Entrada TxD Salida

3 TxD Salida RxD Entrada

4 DTR Salida DTR Entrada

5 GND No aplicable GND No aplicable

6 DSR Entrada DSR Salida

7 RTS Salida CTS Entrada

8 CTS Entrada RTS Salida

9 RI Entrada RI Salida

Tabla 1-1: pines de los conectores DB9 macho y hembra.

De todas estas líneas sólo nos interesan 5, las demás no las usamos.

Vistas desde el DTE (conector DB9 macho) las líneas usadas son:

• Pin 2: RxD. El DTE recibe los datos que envía el DCE por esta línea. Es

la línea usada por la tarjeta de desarrollo para enviar datos al ordenador.

• Pin 3: TxD. Es la línea usada para transmitir datos desde el DTE al DCE,

en nuestro caso del ordenador a la tarjeta de desarrollo.

• Pin 4: DTR (Data Terminal Ready). El DTE activa esta línea para indicar

al DCE que está listo para enviar datos. Cuando se desactiva, el DCE

termina la comunicación. Aquí es usada para activar la señal XIRQ de la

tarjeta de desarrollo.

• Pin 5: GND. Es la tierra del sistema, referencia para todas las señales.

• Pin 7: RTS (Request To Send). El DTE activa esta línea para indicar que

esta listo para recibir datos. En nuestro caso sirve para enviar un RESET

a la tarjeta de desarrollo.



La norma RS-232 permite enviar datos de diversas longitudes, añadir

bits de paridad y distintos tamaños del bit de parada. En nuestro caso

usaremos el formato 8, n, 1, es decir, datos de 8 bits, ninguna paridad y 1 bit de

parada. A continuación vemos la forma de la trama al enviar el carácter $63 (en

binario 01100011):

Figura 1-7: trama correspondiente al carácter $63 en la línea serie.

Para concluir, vamos a aclarar cuáles son los valores de tensión para el

RESET y XIRQ y su relación con las señales DTR y RTS. Es necesario

conocer estos valores para la implementación de la tarjeta interfaz, como

veremos en un capítulo posterior. Las señales TxD, RxD y DTR del cable serie

son convertidas a niveles TTL mediante el integrado MAX232 que incorpora la

tarjeta de desarrollo. La señal RTS, en cambio, no pasa por el MAX232.

Bit Start Bit Stop Datos (8 bits)

15 V

-15 V

3 V

-3 V

1 1 0 0 0 1 1 0

Bit menos significativo

Bit más significativo



1.1.3.1 Polaridades del RESET, XIRQ, RTS y DTR

La señal RESET del MC68HC11 es activa a nivel bajo. Esta señal se

genera en la tarjeta de desarrollo a partir de la señal RTS de la siguiente forma:

Figura 1-8: circuito del RESET.

Por tanto podemos ver que cuando RTS está activado (+3 a +15 V), el

transistor T1 conduce y la señal RESET también está activada (0 V).

La señal XIRQdel MC68HC11 es activa a nivel bajo. Esta señal proviene

de la señal DTR tras su paso por el MAX232. Por tanto cuando DTR está

activada (+3 a +15 V) la señal XIRQ también está activada (0 V).

Señal Estado Tensión Tensión Estado Señal

Activada +3 a +15 V 0 V Activada RTS

Desactivada -15 a -3 V 5 V DesactivadaRESET

Activada +3 a +15 V 0 V Activada DTR

Desactivada -15 a -3 V 5 V DesactivadaXIRQ

Tabla 1-2: relaciones eléctricas entre señales.

RESET

PULSADOR

JRI R8RTS

R9

R10

D2

T1



1.2 Sistema de desarrollo inalámbrico

La actualización del canal de comunicaciones del sistema de desarrollo

original a un canal inalámbrico constituye el propósito de este proyecto. En este

apartado veremos una descripción del hardware adquirido y desarrollado para

sustituir el cable serie por un enlace inalámbrico, así como una breve

justificación de la tecnología y de los circuitos usados. Más adelante, en otro

capítulo, veremos una descripción del proceso de diseño hasta llegar al

hardware aquí presentado y el software creado y modificado para el correcto

funcionamiento de todo el sistema.

La parte inalámbrica del sistema consta básicamente de tres elementos:

• Un adaptador USB Bluetooth que se conectará en el PC.

• Un módulo Bluematik, que es un dispositivo Bluetooth que incorpora una

UART.

• La tarjeta interfaz entre la tarjeta de desarrollo y el módulo Bluematik.

1.2.1 Tecnología inalámbrica elegida

La primera decisión que hubo que tomar al inicio del proyecto fue la

elección de la tecnología inalámbrica del canal de comunicaciones del sistema

de desarrollo. En el mercado existen varias opciones, como Bluetooth, IEEE

802.11.x o ZigBee. Otra opción sería el diseño y construcción de los

transceptores adaptados a las especificaciones del sistema. Esto último, que

posiblemente habría sido lo más eficiente y económico, se descartó porque

implicaba una complejidad que quedaba fuera del ámbito de los objetivos del

proyecto. Finalmente se optó por emplear la tecnología Bluetooth por las

siguientes razones:

• Ofrece una velocidad de transmisión de hasta 1 Mbps, muy superior a la

usada en la tarjeta de desarrollo, lo cual da un margen suficiente por si

se necesita experimentar a mayor velocidad.



• Los dispositivos Bluetooth suelen tener un consumo bastante bajo, lo

que permite alimentar de forma autónoma la tarjeta de desarrollo.

• El alcance que se puede conseguir sin el uso de antenas externas, lo

que hace el diseño más compacto, es de hasta 100 m, más que

suficiente para el entorno de trabajo de un laboratorio al que se orienta

este proyecto.

• Los adaptadores Bluetooth para los PCs se conectan por USB, por lo

que no hay que diseñar ningún dispositivo interfaz ni controladores para

utilizarlos. Esta es una ventaja decisiva frente a otras tecnologías.

• Desde un punto de vista económico los adaptadores anteriores son muy

baratos y fáciles de conseguir. Este punto también ha sido decisivo en la

elección.

El adaptador Bluetooth - puerto serie que se usará en la tarjeta de

desarrollo requiere una mención aparte. En el mercado existe una amplia

variedad de dispositivos que ofrecen esta característica. En un principio se hizo

una búsqueda comparativa de estos dispositivos respecto a precios, modo de

compra, configurabilidad, y características físicas. Se llegó a la conclusión de

que el módulo a elegir debía cumplir con lo siguiente:

• Debía ser lo más pequeño posible, con objeto de que la tarjeta de

desarrollo final fuera manejable y mantuviera en lo posible las

dimensiones originales.

• Además tenía que ser fácil de acoplar en las placas de prueba que

habría que diseñar para su estudio y funcionamiento. Un formato DIL

similar al de los circuitos integrados sería muy positivo.

• Su precio y método de compra debían cumplir con los requisitos formales

del Departamento de Ingeniería Electrónica.



Los dos primeros puntos hicieron que se optara por un dispositivo

embebido frente a uno monolítico, pues el primero suele ofrecer menor tamaño

y mejores características de conexión, más apropiadas al trabajo de

laboratorio. Por el contrario los monolíticos presentan un acabado más

comercial, aunque eso no es problema para el uso de una tarjeta de desarrollo.

Ilustración 1-3: comparación entre un módulo embebido (a la izquierda el NiceBlueCom II de

Amber-Wireless) y un módulo monolítico (a la derecha el Promi-SD101 de Initium).

El factor económico tuvo la última palabra, y finalmente se eligió el

módulo Bluematik del fabricante Flexipanel, que podía ser adquirido en nuestro

país a través del distribuidor Farnell.

1.2.2 El adaptador USB Bluetooth

Mediante el adaptador USB Bluetooth se ofrece a las aplicaciones del

PC la capacidad de usar numerosos servicios de Bluetooth, como son el uso de

manos libres, auriculares, envío de objetos, acceso a la red telefónica por

marcación o el servicio de puerto serie, entre otros. Este último es el servicio

más interesante para el desarrollo del proyecto.



De entre los numerosos adaptadores USB Bluetooth que existen en el

mercado, se ha adquirido el modelo CBT200U2 del fabricante Conceptronic.

Ilustración 1-4: adaptador USB Bluetooth CBT200U2 de Conceptronic.

Este pequeño y cómodo dispositivo viene equipado con un firmware que

incorpora la versión 2.0 de Bluetooth. Las principales diferencias con la versión

anterior (1.2) son los nuevos servicios ofrecidos y las mejoras en las

velocidades de envío de datos. El CBT200U2 ofrece en radio de cobertura de

hasta 200 m y adjunta un CD con los controladores necesarios para la

conexión con otros dispositivos.

1.2.2.1 Manejo del software instalado

Tras la instalación de los controladores se crea un icono en la barra de

tareas que nos indica el estado de las conexiones Bluetooth.

Ilustración 1-5: icono del estado de las conexiones Bluetooth.

Cuando el adaptador USB Bluetooth no esta conectado al puerto USB, el

icono toma el aspecto de la imagen de la izquierda. Cuando sí está conectado

toma el aspecto de la imagen de la derecha. Si hacemos doble clic en este

icono o en el que se crea en el escritorio, se abre una ventana de diálogo

donde podemos gestionar las conexiones Bluetooth.



Ilustración 1-6: ventana de diálogo para las conexiones Bluetooth.

Si hacemos clic en el círculo central se inicia la búsqueda de los

dispositivos Bluetooth presentes en el área de cobertura. Estos son

representados en la elipse punteada que rodea al círculo central mediante un

icono que representa la clase del dispositivo remoto encontrado (móvil, portátil,

manos libres, etc.).

Ilustración 1-7: dispositivos Bluetooth encontrados en el área de cobertura.



Para conocer los servicios ofrecidos por un dispositivo remoto, basta con

pulsar en dicho dispositivo con el botón derecho del ratón y se abre un menú

con esa y otras opciones. Tras pulsar la opción, si el dispositivo remoto tiene

habilitada la opción de seguridad, se nos solicitará el número PIN (por defecto

usaremos el 0000). Una vez introducido correctamente el PIN, el dispositivo

queda emparejado (lo que se muestra con un trazo rojo junto al icono del

dispositivo) y los servicios ofrecidos son resaltados en la fila de iconos de la

parte superior de la ventana.

Ilustración 1-8: servicios ofrecidos por el dispositivo Bluetooth.

El único servicio que usaremos será el servicio de puerto serie. Para

poder usarlo sólo tenemos que abrir con el botón derecho el mismo menú de

antes y pulsar en ‘conectar’. Una vez hecho esto, el puerto serie queda

conectado y un mensaje desde el icono de la barra de tareas nos indica el

número de puerto COM utilizado.



Ilustración 1-9: conexión del servicio de puerto serie.

Otras opciones del menú abierto nos permiten desconectar el servicio,

emparejar y desparejar el dispositivo.

Los adaptadores de otros fabricantes también son válidos, pues

Bluetooth es un estándar y como tal es independiente de quién lo manufacture.

Los servicios son los mismos y su uso también. Incluso sin el software que

acompaña a cualquier adaptador sería posible establecer una conexión puerto

serie, ya que Windows XP incorpora controladores nativos para Bluetooth. Sin

embargo es recomendable usar el software suministrado por el dispositivo.



1.2.2.2 El servicio de puerto serie

Gracias a este servicio es posible sustituir el cable serie del sistema de

desarrollo por un enlace inalámbrico basado en tecnología Bluetooth. Mediante

el servicio de puerto serie los controladores de Bluetooth instalados crean un

puerto COM virtual, pues no está asociado a ninguna UART del PC, pero que

se comporta de la misma forma que si se tratase de un puerto COM real. Así,

cualquier software, como es el caso del programa VTF, que utilice un puerto

COM para enviar datos, podrá enviarlos vía radio a través del adaptador USB

Bluetooth sin más que seleccionar el número de puerto COM adecuado. En el

otro extremo del enlace, el dispositivo Bluetooth remoto habilita un puerto COM

virtual análogo que permite a las aplicaciones que lo usen recibir y mandar

datos al PC.

Ilustración 1-10: lista de puertos reales y virtuales creados por los controladores Bluetooth.



1.2.3 El módulo Bluematik

El Bluematik es un dispositivo Bluetooth versión 1.1, fabricado por

Flexipanel y que posee una UART que permite controlarlo y configurarlo

mediante comandos AT, como veremos más adelante.

Este módulo permite que la tarjeta de desarrollo, a través de la UART

del Bluematik, pueda comunicarse vía Bluetooth con el PC, usando el servicio

de puerto serie.

Ilustración 1-11: módulo Bluematik.

Presenta las siguientes características:

• La tensión nominal de alimentación es de 5V ± 0.2V.

• Puede funcionar como maestro o esclavo.

• Permite autenticación y encriptación.

• Se controla mediante comandos AT enviados a través de la UART.

• Es capaz de buscar dispositivos Bluetooth en la zona de cobertura.

• Es un dispositivo de radio clase I, su radio de alcance es 100 m.

• Presenta los modos de bajo consumo Sniff y Hold.

• La UART tiene la capacidad de controlar flujo por hardware.

• Su arquitectura tiene implementada la capa de corrección de errores de

Bluetooth.



1.2.3.1 Descripción física

El Bluematik es un módulo embebido de 18 pines en formato Dual In

Line (DIL). Posee toda la circuitería de RF necesaria, incluida la antena de

montaje superficial y un conector coaxial tipo Murata MM8430 que permitiría el

uso de una antena externa. Realmente está formado por un módulo UGPZ1-

603A de ALPS Electric CO., Ltd., que es el verdadero dispositivo Bluetooth con

la UART, y una pequeña tarjeta que adapta las conexiones del UGPZ1 al

formato DIL, mucho más cómodo de usar. Ambos se interconectan mediante

un conector AXK6F20345 de Matsushita Electric Works, Ltd., como podemos

ver en la ilustración:

Ilustración 1-12: componentes del Bluematik y detalle de los conectores.

La distribución, nomenclatura y direccionalidad de los pines del

Bluematik es la siguiente:

Figura 1-9: patillaje del Bluematik.

RTS TxD ReservadoReservadoRxD ReservadoRESET ReservadoOn/Off

MUM Reservado

Vcc Reservado

HUM Reservado

CTS Reservado

GND

Antena Conector coaxial

18 17 16 15 14 13 12 11 10

1 2 3 4 5 6 7 8 9



En la siguiente tabla vemos la función asignada a cada pin del

dispositivo:

Pin Nombre Función

1 MUM Indica el tipo de dato que sale del Bluematik a través de TxD. Si vale ‘0’, es una respuesta a un comando AT. Si es un ‘1’, es un dato recibido.

3 Vcc Tensión de alimentación: 5V ± 0.2V.

5 HUM Indica el tipo de dato que entra en el Bluematik a través de RxD. Si vale ‘0’, es un comando AT. Si es ‘1’, es un dato para transmitir vía Bluetooth.

7 CTS Control del flujo que sale por TxD. Si es ‘0’, se envían datos por TxD. Si es ‘1’, se para el envío de datos por TxD.

9 GND Tierra del circuito.

10 On/Off Activa cuando vale ‘1’ o desactiva cuando vale ‘0’ el Bluematik.

12 RESET Reset del sistema, activo a nivel alto.

14 RxD Entrada de datos serie.

17 TxD Salida de datos serie.

18 RTS Control del flujo que entra por RxD. Si es ‘0’, se acepta la recepción de datos por RxD. Si es ‘1’, no enviar datos por RxD.

Tabla 1-3: función de los pines del Bluematik.

Para la realización de tarjetas de prueba del Bluematik será necesario

conocer sus dimensiones y la separación entre pines. En la siguiente figura

tenemos estos datos:

Figura 1-10: detalle de las dimensiones del Bluematik.

33 mm

19.65 mm

17.78 mm (0.7”)

1.27 mm

2.54 mm(0.1”)

5.5 4 2 mm

1.75 x 1.75 mm

1 mm de diámetro

22 mm

Antena



El fabricante recomienda no situar pistas ni componentes bajo la antena

y el conector coaxial, y de ser posible, situar esta zona fuera del límite de la

tarjeta donde se monte.

1.2.3.2 Funcionamiento básico.

El módulo Bluematik se conecta a un dispositivo electrónico anfitrión

mediante la interfaz que ofrece su UART y las líneas HUM y MUM. El

dispositivo anfitrión utiliza las capacidades del Bluematik para comunicarse con

un dispositivo remoto.

Figura 1-11: conexionado y funcionamiento general.

Mediante el envío de comandos AT, el anfitrión configura el Bluematik

según sus necesidades. Entre las características configurables podemos

destacar las siguientes:

• Velocidad de transmisión de la UART.

• Clase de dispositivo Bluetooth (teléfono móvil, portátil, periférico, etc.).

• Tipo de servicio que se ofrece (servicio de puerto serie, manos libres,

etc.).

• Configuración de los modos de bajo consumo de Bluetooth (Sniff y Hold).

• Características de seguridad del enlace inalámbrico (autenticación y

encriptación).

• Papel de maestro o esclavo en el enlace inalámbrico.

TxD RxD RTS CTS MUM HUM

BluematikAnfitrión Dispositivo remoto

Canal

Bluetooth

RxD TxD CTS RTS IO1 IO2

IO1 e IO2 son entradas/salidas de propósito general.



La lista de comandos AT la veremos más detalladamente en un capítulo

posterior.

Una vez que el anfitrión ha configurado adecuadamente el módulo

Bluematik, mediante el envío de comandos AT a través de RxD y poniendo a ‘0’

la línea HUM (por ejemplo a 9600 bps, con autenticación y encriptación,

activando el perfil de puerto serie y como esclavo), se puede iniciar la

comunicación por Bluetooth con un dispositivo remoto. Para ello el anfitrión

debe poner a ‘1’ la línea HUM y a continuación envía los datos serie a través de

RxD. A su vez el dispositivo remoto envía datos que son recibidos por el

anfitrión a través de la línea TxD del Bluematik.

1.2.4 La tarjeta interfaz

El módulo Bluematik requiere una configuración previa a su uso como

transceptor Bluetooth, como hemos visto en la descripción de su

funcionamiento. Por otra parte la tarjeta de desarrollo no está capacitada para

realizar dicha configuración, ya que arranca en modo Bootstrap y no posee

ningún programa almacenado en memoria no volátil para realizar tales

operaciones. Además, determinadas respuestas del Bluematik deben ser

traducidas para su correcta interpretación como la activación o desactivación

de las líneas DTR y RTS del puerto COM virtual. Todo esto será abordado en

mayor profundidad en capítulos posteriores, pero ya podemos intuir la

necesidad de añadir un elemento al sistema de desarrollo que permita un uso

transparente por parte de la tarjeta de desarrollo del puerto COM virtual. Este

elemento es la tarjeta interfaz.

Ilustración 1-13: caras superior e inferior de la tarjeta interfaz.



En el diseño de la tarjeta interfaz se ha intentado que sus dimensiones

sean lo más reducidas posibles con objeto de alterar lo mínimo preciso la

tarjeta de desarrollo. Además, para hacerla más robusta se han eliminado

todos los puntos de test e indicadores LED, a excepción de los LEDs de las

líneas TxD y RxD, presentes en versiones anteriores. También se ha procurado

que la circuitería usada sea lo mas sencilla y reducida posible.

La tarjeta interfaz está construida en una placa PCB de doble cara y

consta de los siguientes componentes:

• Dos LEDs de 3 mm para indicar el movimiento de las líneas TxD (LED

rojo) y RxD (LED verde).

• Dos resistencias 1/4W de 1K para limitar la corriente de los LEDs.

• Dos terminales de zócalos rectos de hilera simple y 9 vías donde se

acopla el Bluematik.

• Dos terminales de pines rectos de hilera simple y 8 pines para conectar

la tarjeta interfaz en la tarjeta de desarrollo.

• Un terminal de pines rectos de un sólo pin para conectar al RESET de la

tarjeta de desarrollo.

• Un microcontrolador PIC16F636 de Microchip Technology Inc.

La conexión entre la tarjeta de desarrollo y la tarjeta interfaz se realiza a

través del zócalo del MAX232, donde se sustituye éste por dos terminales de

zócalos rectos de hilera simple y 8 vías.

Ilustración 1-14: detalle del zócalo del MAX232 de la tarjeta de desarrollo.



1.2.4.1 El microcontrolador PIC16F636

Para configurar e interpretar las respuestas del módulo Bluematik se ha

usado este sencillo microcontrolador. El PIC16F636 tiene un formato DIL de 14

pines y es un microcontrolador de 8 bits realizado en tecnología CMOS. Como

viene siendo habitual en la familia Microchip el juego de instrucciones usado se

reduce a sólo 35, que salvo las de salto, se ejecutan en un ciclo de instrucción.

En la siguiente figura podemos ver la nomenclatura y numeración del patillaje

del microcontrolador:

Figura 1-12: patillaje del PIC16F636.

Otras características de interés de este microcontrolador son las

siguientes:

• Permite usar reloj interno o externo de hasta 20 MHz.

• Puede usar interrupciones.

• Posee un amplio rango de voltajes de funcionamiento (2.0 V a 5.5 V).

• Modo de ahorro energético Sleep.

• Incorpora memoria flash de 2048 words para programa, memoria

EEPROM de 256 bytes y SRAM de 128 bytes.

• Implementa en su arquitectura una pila de 8 niveles de profundidad.

• Como periféricos internos posee dos temporizadores de 8 y 16 bits y un

comparador analógico.

• Su consumo es muy bajo, lo que permite dotar a la tarjeta de desarrollo

de alimentación autónoma.

Vss RA0/C1IN+/ICSPDAT/ULPWU RA1/C1IN-/Vref/ICSPCLK RA2/T0CKI/INT/C1OUT RC0/C2IN+ RC1/C2IN- RC2

Vdd RA5/T1CKI/OSC1/CLKIN RA4/T1G/OSC2/CLKOUT

RA3/MCLR/Vpp RC5

RC4/C2OUT RC3

1 2 3 4 5 6 7

141312111098



• Cuenta con los modos de direccionamiento directo, indirecto y relativo.

• Permite utilizar 12 de sus pines como entradas o salidas de propósito

general.

Memoria de programa Memoria de datos

Flash (words) EEPROM (bytes) SRAM (bytes)

I/O Comparadores Temporizadores

2048 256 128 12 1 8/16 bit

Tabla 1-4: principales características del PIC16F636.

DESCRIPCIÓN DEL HARDWARE DEL SISTEMA Y...

Documents

Transcript of DESCRIPCIÓN DEL HARDWARE DEL SISTEMA Y...