diseño e implementación de un sistema de control de acceso y

DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE CONTROL DE
ACCESO Y AUTORIZACIÓN MEDIANTE PROTOCOLO USB
MIGUEL ANGEL CÁRDENAS GONZÁLEZ
RODRIGO LÓPEZ BEJARANO
GERMÁN ALBERTO TORRE PÉREZ
UNIVERSIDAD DE SAN BUENAVENTURA
FACULTAD DE INGENIERÍA
PROGRAMA DE INGENIERÍA ELECTRÓNICA
BOGOTÁ DC
2009
DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE CONTROL DE
ACCESO Y AUTORIZACIÓN MEDIANTE PROTOCOLO USB
MIGUEL ANGEL CÁRDENAS GONZÁLEZ
RODRIGO LÓPEZ BEJARANO
GERMAN ALBERTO TORRE PÉREZ
Proyecto de grado como requisito para optar al título de Ingeniería
Electrónica.
Asesor
Néstor Penagos
Ingeniero Electrónico
UNIVERSIDAD DE SAN BUENAVENTURA
FACULTAD DE INGENIERÍA
PROGRAMA DE INGENIERÍA ELECTRÓNICA
BOGOTÁ DC
2009
NOTA DE ACEPTACION
________________________________
________________________________
________________________________
________________________________
________________________________
________________________________
FIRMA DEL PRESIDENTE DEL JURADO
________________________________
FIRMA DE JURADO
________________________________
FIRMA DE JURADO
A mi madre, quien me apoyo durante toda la carrera, quien me dio las
fuerzas y los ánimos de seguir y salir adelante.
Germán Alberto Torre Pérez
A mi familia y compañeros que estuvieron siempre conmigo durante
este largo proceso y no permitieron que renunciara a mi meta.
Miguel Angel Cárdenas González
A mis padres que me dieron la oportunidad de realizar mis estudios y
me apoyaron incondicionalmente y me ayudaron para que esto sea una
realidad.
Rodrigo López Bejarano
AGRADECIMIENTOS
A nuestras familias que nos apoyaron incondicionalmente, en todas las cosas
tanto buenas como malas, a nuestros amigos que forman una parte integral
de la formación y se convierten en una fuente de inspiración y admiración.
Por último un agradecimiento cordial a todos los docentes de la universidad
que probaron ser un grupo de personas confiables y calificadas para ejercer
su labor.
CONTENIDO
INTRODUCCIÓN .......................................................................................... VII
1. PLANTEAMIENTO DEL PROBLEMA ......................................................... 1
1.1. ANTECEDENTES (ESTADO DEL ARTE) ............................................ 1
1.2. DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA ......................... 5
1.3. JUSTIFICACIÓN .................................................................................. 7
1.4. OBJETIVOS DE LA INVESTIGACIÓN ................................................. 8
1.4.1. Objetivo General. ........................................................................... 8
1.4.2. Objetivos Específicos..................................................................... 8
1.5. ALCANCES Y LIMITACIONES ........................................................... 9
1.5.1. Alcances. ..................................................................................... 9
1.5.2. Limitaciones. ................................................................................ 10
2. MARCO DE REFERENCIA....................................................................... 11
2.1. MARCO TEÓRICO - CONCEPTUAL ................................................. 11
2.1.2. Funcionamiento. .......................................................................... 14
2.1.3. Cables y Conectores.................................................................... 18
2.1.4. Especificación USB...................................................................... 21
2.2. MARCO NORMATIVO ....................................................................... 23
2.2.1. Clases USB. ................................................................................ 23
2.2.2. Relación Driver-Dispositivo. ......................................................... 24
2.2.3. Descriptores. ................................................................................ 25
2.2.4. Clases, Subclases y Protocolos. ................................................ 26
2.2.5. Localización del driver. .............................................................. 26
I
2.2.6. Peticiones específicas de Clase USB y peticiones específicas del
fabricante. .............................................................................................. 28
3. METODOLOGÍA ....................................................................................... 30
3.1. ENFOQUE DE LA INVESTIGACIÓN ................................................. 30
3.2. LÍNEA DE INVESTIGACIÓN .............................................................. 30
3.3. HIPÓTESIS ........................................................................................ 30
3.4. VARIABLES ....................................................................................... 31
3.4.1. Variables independientes............................................................. 31
3.4.2. Variables dependientes ............................................................... 31
4. DESARROLLO INGENIERIL .................................................................... 32
4.1. MÓDULOS. ........................................................................................ 35
4.1.1. Módulo Llave. . ........................................................................... 35
4.1.2. Módulo de software...................................................................... 40
4.1.3. Módulo De Apertura. .................................................................... 45
4.2. DISEÑO DEL CIRCUITO ................................................................... 51
4.2.1. MPLab IDE 8.14. ......................................................................... 51
4.2.2. Proteus 7.2. ................................................................................. 54
4.3. INSTALACIÓN DEL DRIVER EN WINDOWS XP .............................. 59
5. PRESENTACIÓN Y ANÁLISIS DE RESULTADOS .................................. 63
6. CONCLUSIONES ..................................................................................... 69
7. RECOMENDACIONES ............................................................................. 70
BIBLIOGRAFÍA ............................................................................................. 72
WEBLIOGRAFÍA........................................................................................... 73
GLOSARIO ................................................................................................... 74
II
ANEXOS ....................................................................................................... 77
ANEXO A CÓDIGO FUENTE DEL MICROCONTROLADOR PIC18F4550
MÓDULO LLAVE .......................................................................................... 78
ANEXO B CÓDIGO FUENTE DEL MICROCONTROLADOR PIC16F628A
MÓDULO MOTOR ........................................................................................ 81
ANEXO C CÓDIGO FUENTE PROGRAMA MÓDULO SOFTWARE ........... 90
III
LISTA DE FIGURAS
Figura 1. Estructura de proyecto UMGina. ...................................................... 3
Figura 2. CDVI UGM. ...................................................................................... 4
Figura 3. Interfaz host – device USB ............................................................ 13
Figura 4. Codificación NRZI .......................................................................... 14
Figura 5. Conector USB tipo A. ..................................................................... 20
Figura 6. Conector USB tipo B. ..................................................................... 20
Figura 7. Diagrama a bloques del sistema. ................................................... 34
Figura 8. Diagrama de flujo del módulo llave ................................................ 35
Figura 9. Diagrama de pines del microcontrolador tipo PDIP ....................... 38
Figura 10. Diagrama de pines del microcontrolador tipo TQFP .................... 39
Figura 11. Diagrama de flujo del módulo software ........................................ 40
Figura 12. Interfaz grafica de C++ Builder 6 ................................................. 42
Figura 13. Ventana principal USB key. ......................................................... 43
Figura 14. Ventana de selección de puerto. ................................................. 43
Figura 15. Ventana principal USB key con lista de usuarios desplegada. .... 44
Figura 16. Diagrama de flujo del módulo de apertura ................................... 45
Figura 17. Diagrama de pines del integrado FT232. ..................................... 47
Figura 18. Diagrama de pines del microcontrolador PIC 16f628A. ............... 48
Figura 19. Diagrama de pines driver L298. ................................................... 49
Figura 20. Pestillo eléctrico. .......................................................................... 50
Figura 21. Ventana de trabajo de MPLAB. ................................................... 51
Figura 22. Configuración de proyecto. .......................................................... 52
Figura 23. Diagrama esquemático realizado en proteus ISIS módulo llave. . 55
Figura 24. Diseño del circuito impreso PCB en proteus ARES módulo llave. 56
Figura 25. Visualización 3D de los componentes en el circuito impreso
módulo llave. ................................................................................................. 56
IV
Figura 26. Diagrama esquemático realizado en proteus ISIS módulo apertura.
...................................................................................................................... 57
Figura 27. Diseño del circuito impreso PCB en proteus ARES módulo
apertura. ....................................................................................................... 58
Figura 28. Visualización 3D de los componentes en el circuito impreso
módulo apertura. ........................................................................................... 58
Figura 29. Opción de búsqueda del controlador en internet. ........................ 59
Figura 30. Opción de instalación automática o manual. ............................... 60
Figura 31. Selección de la ubicación del controlador. ................................... 61
Figura 32. Localización grafica de la carpeta contenedora. .......................... 62
Figura 33. Proceso de copiado de archivos al directorio raíz de Windows. .. 62
Figura 34. Componentes del sistema. .......................................................... 63
Figura 35. Módulo llave foto real y diseño 3D. .............................................. 64
Figura 36. Conexión módulo apertura a módulo software. ........................... 65
Figura 37. Ventana de inicio de interfaz. ....................................................... 65
Figura 38. Selección de puerto. .................................................................... 66
Figura 39. Conexión módulo llave a módulo apertura................................... 66
Figura 40. Reconocimiento de usuario. ........................................................ 67
Figura 41. Sistema abierto. ........................................................................... 68
Figura 42. Sistema cerrado y en modo de espera. ....................................... 68
V
LISTA DE TABLAS
Tabla 1. Distancias y calibres de cable USB ............................................... 19
Tabla 2. Disposición de pines y colores de identificación en cables USB..... 19
Tabla 3. Comparación de los microcontroladores optativos del módulo llave.
...................................................................................................................... 37
Tabla 4. Comparación
de los microcontroladores
optativos de módulo
apertura. ....................................................................................................... 46
VI
INTRODUCCIÓN
Un sistema de control de acceso se desarrolla mediante la creación de tres
bloques o módulos que, mancomunadamente uno de software y dos de
hardware generan un sistema robusto de elevada seguridad, sin dejar de
lado la eficiencia y su asequibilidad.
Los elementos construidos enteramente para el sistema operativo Windows y
basados en el protocolo USB, permiten crear un sistema innovador que
genera un avance en cuanto a sistemas de control de acceso a recintos
mediante la autenticación electrónica; siendo una implementación sencilla
pero efectiva en el aspecto de seguridad para bóvedas y recintos de media y
baja seguridad.
La importancia de restringir el acceso a lugares, objetos, y sistemas de
almacenamiento de datos, como computadores personales o servidores,
radica en la seguridad, dado que es posible que personas malintencionadas
intenten acceder a ellos, con el fin de sustraer bienes o información; para
personas o empresas en general, proteger estos elementos es un proceso
crítico.
En el desarrollo de esta acción se utilizan las características y tecnologías
electrónicas para diseñar un módulo “llave”, que permita la autenticación de
datos y acceder a un recinto o depósito protegido con seguridad activa,
haciendo uso de un sistema que consta de un dispositivo con memoria de
almacenamiento de información, un computador que realiza la verificación de
datos y la posterior autorización de acceso, y un aparato que acciona el
mecanismo que abre la puerta del recinto o contenedor.
VII
1. PLANTEAMIENTO DEL PROBLEMA
1.1. ANTECEDENTES (ESTADO DEL ARTE)
Con el nacimiento de la propiedad privada, el ser humano ha intentado
desarrollar métodos de control de acceso que generen seguridad y
privacidad; en la era de las cavernas el ser humano imponía barreras físicas
como fuego y elementos cortantes para evitar que algunos animales e
incluso otros humanos no accedieran a este lugar considerados seguros.
En las antiguas civilizaciones (egipcia, romana y china entre otras), se
desarrollaron la puerta y las cerraduras, que protegían ciudades y casas de
ser asaltadas con facilidad por ejércitos invasores y/o visitantes no deseados,
este fue un invento muy útil, pero por si solo implicaba grandes esfuerzos
para que las personas autorizadas pudieran entrar y salir de estos lugares,
debido a su seguridad que, se basaba en grandes trancas de madera,
cadenas o simplemente puertas muy pesadas, estos sistemas requerían de
muchos hombres para poder abrir o cerrar. Más adelante surgió un adelanto
tecnológico llamado el cerrojo, que se integro a la puerta para optimizar su
función, de esta forma, se remplazaron las grandes y pesadas trancas por
sistemas más livianos hechos en metal pero más resistentes, este sistema
admitía que la puerta fuera más fácil de abrir, y en general más rápida.
Cuando se inventaron las primeras cerraduras eran grandes cajas metálicas
que necesitaban para abrirse, llaves de hierro muy grandes y pesadas. Sin
embargo, en el siglo XX hubo una gran evolución en el diseño de nuevos
sistemas de acceso por puerta que han ocasionado una amplia gama de
tipos de llaves.
1
La mayoría de llaves son de acero, pero en los automóviles u otras
dependencias ya se usan llaves que llevan incorporado un sistema
electrónico para abrir a distancia sin necesidad de meterlas en la cerradura;
solamente se introduce cuando deja de funcionar el dispositivo electrónico.
Estas llaves sirven también para iniciar la puesta en marcha del motor del
automóvil.
Las llaves modernas de las habitaciones de hotel, son una simple tarjeta de
plástico donde se codifica un periodo de validez de acuerdo con la estancia
de los clientes en el hotel, y además sirve como interruptor general de la
electricidad cuando se abandona la habitación.
Otros tipos de llaves sirven de control, por ejemplo, el acceso a
aparcamientos privados de automóviles, son unos dispositivos electrónicos
que actúan a distancia, abriendo y cerrando la puerta cuando se le indica.
Basado en proyectos que aportan una base para el desarrollo ingenieril, se
observan la evolución de los sistemas analógicos hasta la introducción de
sistemas digitales, con las últimas técnicas de seguridad.
2
Proyectos Relacionad
R
dos:
P
Proyecto:
UMGina: Sistema de
d control de acceso
o en aulass basado en
e
t
tarjetas
inte
eligentes de
e la Universsidad de Murcia.
A
Autor:
T. Jiménez- A Gómez Skarmeta-- J. García
a Ros- G. Martínez- J.
Hidalgo- J. Gil- O. Cán
novas- S. Navarro
N
y M.
M Serrano
D
Detalles
del
d proyec
cto: El Serrvicio de Informática de la Un
niversidad de
d
M
Murcia,
ha
a desarrolla
ado un sisstema de control
c
de acceso basado en la
u
utilización
de
d tarjetas inteligentess, para suss equipos en
e aulas de
e libre acceso
(
(ALAs),
co
omplementa
ando así otros elem
mentos de seguridad
d como so
on:
a
autenticació
ón, integrid
dad, confide
encialidad y no repud
dio abordad
dos por otros
p
proyectos
de
d la misma
a Universid
dad dotando
o de un sisttema globa
al de control y
g
gestión
de reservas trransparente
e al usuario
o y fácil de administrar
a
r.
F
Figura
1. Es
structura de proyecto UM
MGina.
F
Fuente:
Estruc
ctura de proyecto UMGina Grupo de seguridad y criptogra
afía-Universida
ad de Murcia
3
P
Proyecto:
Sistema de
e control de
e acceso ce
entralizado CDVI UGM
M.
A
Autor:
CDV
VI.
D
Detalle
de
el proyecto
o: Ugm es un Produccto que em
mplea electrónica digittal
p
para
sumin
nistrar contrrol, en el momento
m
de
e acceder a un recintto, capaz de
d
m
manejar
ha
asta 128 lecctores (puertas), de forma centralizada, la unidad centrral
p
provee
con
nexión con los disposittivos en loss cuales se pueden ussar diferentes
t
técnicas
de
e autenticación, como
o biometría, teclados, RFID, etc. Además de
d
m
mantener
comunicació
c
ón continua
a con los le
ectores, la unidad
u
central es capaz
d comunicarse con un PC, con
de
c
el obje
etivo de lle
evar un reg
gistro de los
l
lectores,
almacenar co
ontraseñass y monitore
ear en gene
eral el uso del
d sistema
a.
F
Figura
2. CD
DVI UGM.
F
Fuente:
Estac
ción Central CD
DVI UGM. [En Línea]
L
Productos de control de
d acceso en líínea
4
Proyecto: Sistema de control y acceso de personas para un autobús
intermunicipal en Colombia
Autor: Camilo Andrés Molina Vega, Bogotá Universidad de san
buenaventura facultad de Ingeniería, Ingeniería electrónica 2005.
Proyecto: Prototipo de un sistema de control de acceso de personal
mediante uso de tarjetas inteligentes de tecnología RFID
Autor: Luis Eduardo Ramirez Rojas y Deiber Zambrano Marquez, Bogotá
Universidad de san buenaventura facultad de Ingeniería, Ingeniería
electrónica 2004.
5
1.2. DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA
En la actualidad existen varios métodos de control de acceso, uno de los más
usados es la llave, sin embargo, esta puede tener una serie de desventajas:
•
La acción de manipular continuamente una llave genera desgaste,
tanto de esta como de la cerradura en la que se usa, por lo cual deben
ser reemplazadas y generan un gasto adicional.
•
Por ser algo tan común puede ser copiada por casi cualquier persona,
lo que representa un grado de inseguridad para el usuario; además
hace vulnerable el sistema de control de acceso.
•
El hecho de tener tantas llaves como número de puertas a las que se
desea acceder, genera incomodidad y confusión cuando las llaves son
del mismo tipo.
•
Con un sistema de control de acceso tradicional, se pierden muchas
características que un sistema digital robusto puede ofrecer, como la
posibilidad de registrar el usuario y el momento en que se accede al
sistema.
•
¿Cómo diseñar un sistema de control que resulte eficaz y de fácil
manejo para el usuario final, utilizando el protocolo USB?
6
1.3. JUSTIFICACIÓN
La importancia del desarrollo de este proyecto radica en la necesidad de
implementar un sistema que ofrezca mayor seguridad que las cerraduras
mecánicas actuales, mediante la aplicación de tecnología digital y los
desarrollos electrónicos contemporáneos.
Este sistema puede ser utilizado prácticamente en cualquier campo en el que
se requiera seguridad, es decir, empresas, hoteles, bancos, edificios,
propiedades estatales y privadas en general, lo que permite un área de
aplicación extensa, incluyendo todos los sectores (comerciales, industriales y
domésticos).
Gracias a la aplicación de las técnicas de autenticación digital, este sistema
ofrece mayores beneficios con respecto a los sistemas de seguridad basados
en tarjetas electro-magnéticas, dado que, un dispositivo USB generalmente
tiene mayor capacidad de almacenamiento y la posibilidad de guardar
contraseñas o algoritmos de identificación.
El desarrollo de este proyecto tiene grandes ventajas como la utilización de
estándares de puertos USB, que son de gran uso en la actualidad y que dada
su versatilidad permiten ser empleadas en un sin número de aplicaciones.
Además de incluir un protocolo de nivel universal como el USB, se puede
partir de las experiencias adquiridas durante el desarrollo del proyecto para
diseñar futuras implementaciones y mejoras basándose en el uso de
estándares de amplia documentación.
7
1.4. OBJETIVOS DE LA INVESTIGACIÓN
1.4.1. Objetivo General.
Diseñar e implementar un sistema que permita el control de acceso a
puertas, gabinetes y/o cajas de seguridad implementando el protocolo USB.
1.4.2. Objetivos Específicos.
•
Diseñar un sistema electrónico, tanto de “llave” como de “cerradura”
que permita el acceso, únicamente a los usuarios deseados.
•
Crear un software que sea capaz de comparar la entrada de un
dispositivo físico con una base de datos diseñada para el sistema.
•
Diseñar un sistema de codificación de los datos, tanto de usuario
como códigos de seguridad, usando la interfaz grafica proporcionada
por un PC.
•
Elaborar un circuito que controle el actuador que a su vez permita
desbloquear las cerraduras de las puertas a las que se quiera
acceder.
8
1.5. ALCANCES Y LIMITACIONES
1.5.1. Alcances.
El módulo central será capaz de interpretar una
información proveniente de un dispositivo portátil correspondiente a la
identificación de usuario, las instrucciones y el código necesario para poder
interpretar la información contenida en la memoria de dicho dispositivo
portátil (llave), además de los aspectos de configuración del sistema.
Con la construcción del dispositivo se busca facilitar las labores que pueda
ejercer una persona encargada del control de acceso, reduciendo el número
posible de personas en la planta.
Otra ventaja de utilizar un sistema de control de acceso con estas
características, será la capacidad de personalización, lo que lo hace
altamente adaptable a la mayoría de situaciones o escenarios de uso,
además de la adaptabilidad del proyecto, los bajos costos, su sencillez de
instalación y puesta en marcha.
Este sistema será sencillo de usar, ya que, está diseñado para que personas
sin experiencia en el área de electrónica y computación, puedan acceder
fácilmente a todas las características de su interfaz grafica de configuración,
que se realizan desde el equipo central.
Una gran característica, es la posibilidad de crear copias de respaldo tanto
de las bases de datos como de las configuraciones, usando las herramientas
nativas del sistema operativo Windows, plataforma para la cual se creara el
programa de configuración y registro.
9
1.5.2. Limitaciones. Una debilidad de este sistema es la robustez, en cuanto
al respaldo de alimentación eléctrica, debido a que la fuente de respaldo
tendría un tiempo límite, por este factor el sistema podría fallar.
Otra característica limitante del proyecto es la funcionalidad del programa a
implementar cuando se posee una gran cantidad de puertas y usuarios a
controlar por un solo ordenador, dado que, necesitaría una gran cantidad de
puertos USB disponibles y esto ralentizaría el proceso considerablemente,
porque se debería buscar puerto a puerto la ubicación de la llave;
La necesidad de hacer un sistema que se pueda modificar una vez instalado,
pues se debe dejar abierta la posibilidad de cambio de contraseñas o
modificación de la organización física que se le dé al sistema.
En cuanto a la necesidad del de utilizar un sistema central, compuesto por el
PC, dado que es necesario que dicho sistema cumpla con los requisitos
mínimos para ejecutar un sistema operativo como Windows XP, para el cual
se ha diseñado el programa de interfaz con el usuario final.
10
2. MARCO DE REFERENCIA
2.1. MARCO TEÓRICO - CONCEPTUAL
El control de acceso tiene como propósito minimizar la probabilidad de que
personas malintencionadas ingresen a áreas o entornos donde pueden
causar algún tipo de daño. Un buen sistema de control de acceso debe
encontrar el balance adecuado entre seguridad y funcionalidad, ya que de
nada sirve implementar un sistema de control de acceso de alta tecnología, si
este implica muchas complicaciones y costos elevados para la empresa o el
usuario que lo desee utilizar; como un mecanismo de ayuda para encontrar
este balance se usará la tecnología de puertos y dispositivos USB.
Con el pasar del tiempo han surgido bastantes y muy variadas funciones
para los puertos USB, además de los equipos tradicionales como el teclado,
el mouse y la impresora, los puertos USB hoy abren las puertas de un PC a
docenas de accesorios que hoy se pueden usar a través de esos conectores
como memorias, cámaras, reproductores de música, computadores de mano,
ventiladores, lámparas y parlantes.
Actualmente los dispositivos de almacenamiento USB son muy populares,
debido a su facilidad de uso y relativamente bajo costo. Además de su gran
capacidad, algunos de estos dispositivos cuentan además con reproductores
multimedia, haciéndolos aun más atractivos al público. Una línea de estos
dispositivos multimedia, el iPod® de la compañía Apple™, posee
capacidades que varían entre 1 y 80 GB; sin duda, los dispositivos de
almacenamiento USB han revolucionado desde hace algunos años la
manera en que las personas manejan sus archivos y su vida diaria. Pero en
procura de aprovechar al máximo las características de este puerto, y los
11
beneficios del protocolo que lo maneja se ha querido encontrar una nueva
función en el campo de la seguridad electrónica. Para entender mejor la
concepción de esta idea se explicarán los principales conceptos y
generalidades del funcionamiento de un puerto y de los dispositivos USB.
2.1.1. Hardware de USB. Los dispositivos USB adoptan una topología de
estrella y se organiza por niveles a partir de un controlador host instalado en
la placa base, que actúa de interfaz entre el bus de ésta (generalmente a la
interfaz PCI) y el primer dispositivo USB, el denominado concentrador raíz
("Root hub"), instalado también en la placa. El controlador de host es único;
suele ser un chip Intel con una denominación como 82371AB/EB; 82801DB,
etc. Dada la proliferación de este tipo de dispositivos, las placas modernas
pueden disponer de varias concentradoras raíces, cada uno con su propia
salida, generalmente 2 conectores del tipo "A" por cada uno de ellos. Cada
uno de estos concentradores se considera el origen de un bus (numerados
sucesivamente a partir del 0), del que cuelgan los dispositivos en el orden en
que son detectados por el Sistema. El bus USB soporta intercambio
simultáneo de datos entre un ordenador anfitrión y un amplio conjunto de
periféricos.
Todos los periféricos conectados comparten el ancho de banda del bus por
medio de un protocolo de arbitraje basado en testigos ("Tokens"). El bus
permite conexión y desconexión dinámica, es decir, que los periféricos se
conecten, configuren, manipulen y desconecten mientras el sistema anfitrión
y otros periféricos permanecen en funcionamiento.
En un bus USB existen dos tipos de elementos: Anfitrión ("host") y
dispositivos; a su vez, los dispositivos pueden ser de dos tipos:
concentradores y funciones.
12
L
Los
conce
entradores ("Hubs") son
s
el centtro de una estrella, y sirven pa
ara
c
conectar
co
on el sistem
ma anfitrión
n, con otro hub o con una función
n. Cada hu
ub
p
puede
conectar hasta
a 7 dispositivos, aunq
que lo norrmal es que sean de 4
s
salidas,
y proporciona
p
ar 500 mA de energía
a de alimen
ntación (ha
asta 2.5 W)) a
c
cada
uno de
d ellos, ya que el cab
ble de cone
exión tiene hilos de se
eñal (datos)) y
d alimenta
de
ación (5 V. DC ± 0.25 V).
Es importa
ante consid
derar el proceso
p
físsico y el proceso ló
ógico de las
c
comunicac
iones por protocolo
p
U
USB.
El ho
ost USB, o dispositivo
o anfitrión se
e
encarga
de
e controlar la conexió
ón y actúa como un maestro
m
co
ontrolando un
u
e
esclavo
que
e se puede
e considerar como un USB device
e, o perifériico USB.
F
Figura
3. Intterfaz host – device USB
B
F
Fuente:
USB Complete: Evverything You
u Need to Develop USB Pe
eripherals, Th
hird Edition
13
El host utiliiza un softw
ware que se
s encarga de crear la
as conexion
nes y asign
nar
n
números
de
d dispositivo, así como tam
mbién de designar el tipo de
d
t
transferenc
cia que se puede usa
ar, luego de
e establece
er estos pa
arámetros de
d
cconfiguración del disp
positivo y del host, el software de
e la capa de
d función se
c
comunica
con
c
el softw
ware de sistema USB
B, comuniccándole el tipo
t
de clase
q tiene el
que
e dispositivvo USB con
nectado al sistema, lu
uego este selecciona
s
el
d
driver
auto
omáticamen
nte, en este
e caso el software de sistema se refiere al
s
sistema
operativo Win
ndows que selecciona
a el driver automáticam
a
mente de un
na
l
lista
de disp
positivos, esta
e
lista se
e llama TPL
L (Targeted Peripheral List).
2
2.1.2.
Func
cionamiento. El bus serie USB es síncron
no, y utiliza
a el algoritm
mo
d codificación NRZI ("Non Return to Zerro Inverted"" invertido sin retorno
de
oa
c
cero).
F
Figura
4. Co
odificación NRZI
N
F
Fuente:
USB Complete: Evverything You
u Need to Develop USB Pe
eripherals, Th
hird Edition
L “ceros”” provocan un cambio de nivel, Los “unos” no
Los
n provocan
n cambio.
Para evitarr periodos largos sin cambios se
s introduce
e un cero cada 6 unos
c
consecutivo
os
14
En este sistema existen dos voltajes opuestos; una tensión de referencia
corresponde a un "1", pero no hay retorno a cero entre bits, de forma que una
serie de unos corresponde a un voltaje uniforme; en cambio los ceros se
marcan como cambios del nivel de tensión, de modo que una sucesión de
ceros produce sucesivos cambios de tensión entre los conductores de señal.
A partir de las salidas proporcionadas por los concentradores raíz
(generalmente conectores del tipo "A") y utilizando concentradores
adicionales, pueden conectarse más dispositivos hasta el límite señalado.
El protocolo de comunicación utilizado es el testigo, que guarda cierta
similitud con el sistema Token-Ring de IBM. Puesto que todos los periféricos
comparten el bus y pueden funcionar de forma simultánea, la información es
enviada en paquetes; cada paquete contiene una cabecera que indica el
periférico a que va dirigido.
Existen cuatro tipos de paquetes distintos:
Token; Datos; Handshake, y Especial; el máximo de datos por paquete es de
8; 16; 32 y 64 Bytes. Se utiliza un sistema de detección y corrección de
errores
bastante
robusto
tipo
CRC
("Cyclical
Redundancy
Check"
comprobación de redundancia cíclica).
La comprobación de redundancia cíclica (CRC) es un tipo de función que
recibe un flujo de datos de cualquier longitud como entrada y devuelve un
valor de longitud fija como salida. El término suele ser usado para designar
tanto a la función como a su resultado. Pueden ser usadas como suma de
verificación para detectar la alteración de datos durante su transmisión o
almacenamiento. Las CRCs son populares porque su implementación en
hardware binario es simple, son fáciles de analizar matemáticamente y son
particularmente efectivas para detectar errores ocasionados por ruido en los
15
canales de transmisión. La CRC fue inventada y propuesta por W. Wesley
Peterson en un artículo publicado en 1961.
El CRC es un código de detección de error-cuyo cálculo es una larga división
de computación en el que se descarta el cociente y el resto se convierte en el
resultado, con la importante diferencia de que la aritmética que usamos
conforma que el cálculo utilizado es el arrastre de un campo finito, en este
caso los bits. El tamaño del resto es siempre menor que la longitud del
divisor, que, por lo tanto, determina el tamaño del resultado. La definición de
un CRC especifica el divisor que se utilizará, entre otras cosas. Aunque CRC
se puede construir utilizando cualquier tipo de regla finita, todos CRC de uso
común emplean una base finita binaria, esta base consta de dos elementos,
generalmente el 0 y 1, el resto de este artículo se centrara en este tipo de
composición, es decir el ámbito binario y los principios generales de los CRC.
Para el cálculo de CRC se debe tener en cuenta que La mecánica de la
informática con su lenguaje binario produce unas CRC simples. Los bits
representados de entrada son alineados en una fila, y el (n +1) representa el
patrón de bits del divisor CRC (llamado "polinomio") se coloca debajo de la
parte izquierda del final de la fila. Aquí está la primera de ellas para el cálculo
de 3 bits de CRC:
11010011101100
<--- entrada
1011
<--- divisor (4 Bits)
-------------01100011101100
<--- resultado
Si la entrada que está por encima del extremo izquierdo tiene como divisor 0,
no hace nada y pasar el divisor a la derecha de uno en uno. Si la entrada que
16
está por encima de la izquierda tiene como divisor 1, el divisor es [Or
exclusiva] en la entrada (en otras palabras, por encima de la entrada de cada
bit el primer bit conmuta con el divisor). El divisor es entonces desplazado
hacia la derecha, y el proceso se repite hasta que el divisor llega a la
derecha, en la parte final de la fila de entrada. Aquí está el último cálculo:
00000000001110
<--- resultado de la multiplicación de cálculo
1011 <--- divisor
-------------00000000000101
<--- resto (3 bits)
Desde la izquierda se divide por cero todos los bits de entrada, cuando este
proceso termina el único bits en la fila de entrada que puede ser distinto de
cero es n bits más a la derecha, en la parte final de la fila. Estos n bits son el
resto de la división, y será también el valor de la función CRC (es el CRC
elegido a menos que la especificación de algún proceso posterior lo cambie).
El funcionamiento del dispositivo USB está centrado en el host, todas las
transacciones se originan en él. Es el controlador host el que decide todas
las acciones, incluyendo el número asignado a cada dispositivo (esta
asignación es realizada automáticamente por el controlador "host" cada vez
que se inicia el sistema o se añade, o elimina, un nuevo dispositivo en el
bus), su ancho de banda, etc. Cuando se detecta un nuevo dispositivo es el
host el encargado de cargar los drivers oportunos sin necesidad de
intervención por el usuario.
El sistema utiliza cuatro tipos de transacciones que resuelven todas las
posibles situaciones de comunicación. Cada transacción utiliza un mínimo
de tres paquetes, el primero es siempre un Token que avisa al dispositivo
que puede iniciar la transmisión.
17
•
Transferencia de control ("Control transfer"): Ocurre cuando un
dispositivo se conecta por primera vez.
En este momento el
controlador de host envía un paquete "Token" al periférico
notificándole el número que le ha asignado.
•
Transferencia de pila de datos ("Bulk data transfer"): Este proceso se
utiliza para enviar gran cantidad de datos de una sola vez. Es útil para
dispositivos que tienen que enviar gran cantidad de datos cada vez,
como escáneres o máquinas de fotografía digital.
•
Transferencia por interrupción ("Interrupt data transfer"): Este proceso
se utiliza cuando se solicita enviar información por el bus en una sola
dirección (de la función al host).
•
Transferencia de datos isócrona ("Isochronous data transfer"): Este
proceso se utiliza cuando es necesario enviar datos en tiempo real.
Los datos son enviados con una cadencia precisa ajustada a un reloj,
de modo que la transmisión es a velocidad constante.
2.1.3. Cables y Conectores. El cable de bus USB es de 4 hilos, y
comprende líneas de señal (datos) y alimentación, con lo que las funciones
pueden utilizar un único cable. Existen dos tipos de cable: apantallado y sin
apantallar. En el primer caso el par de hilos de señal es trenzado; los de
tierra y alimentación son rectos, y la cubierta de protección (pantalla) solo
puede conectarse a tierra en el anfitrión. En el cable sin apantallar todos los
hilos son rectos. Las conexiones a 15 Mbps y superiores exigen cable
apantallado.
18
S utilizan diámetros estándar para
Se
p
los hilos de alime
entación de
el bus. Pa
ara
c
cada
secció
ón se autorriza una lon
ngitud máxima del seg
gmento.
T
Tabla
1. Dis
stancias y ca
alibres de ca
able USB
F
Fuente:
USB Complete:
C
Evverything You Need to Devvelop USB Pe
eripherals, Third Edition
T
Tabla
2. Dis
sposición de pines y colo
ores de identificación en
n cables USB
B
F
Fuente:
USB Complete: Evverything You
u Need to Develop USB Pe
eripherals, Th
hird Edition
S usan dos
Se
d
tipos de
d conectores, A y B.
B
Amboss son polarrizados (so
olo
p
pueden
ins
sertarse en
n una possición) y utilizan siste
emas de presión
p
pa
ara
s
sujetarse.
Los de tipo A utilizan
n la hembra
a en el sisttema anfitrrión, y suele
en
19
u
usarse
en dispositivos en los qu
ue la conexxión es permanente (por
(
ejemplo,
r
ratones
y te
eclados).
L de tipo
Los
o B utilizan la hembra en el dispo
ositivo USB
B (función),, y se utiliza
an
e sistema
en
as móviles (por ejemplo, cámarras fotográfficas o alta
avoces). En
E
g
general
pod
demos afirm
mar que la hembra de
e los conecctores A esttán en el lad
do
d host (P
del
PC) o de lo
os concentrradores (Hu
ubs), mienttras las de tipo B está
án
d lado de
del
e los periféricos.
F
Figura
5. Co
onector USB
B tipo A.
F
Fuente:
USB Complete: Evverything You
u Need to Develop USB Pe
eripherals, Th
hird Edition
Figura 6. Conector
C
US
SB tipo B.
F
Fuente:
USB Complete: Evverything You
u Need to Develop USB Pe
eripherals, Th
hird Edition
20
2.1.4. Especificación USB. Universal Serial Bus. En computadores, un bus
es un subsistema que transfiere datos o electricidad entre componentes del
ordenador dentro de
un ordenador o entre ordenadores. Un bus puede
conectar varios periféricos utilizando el mismo conjunto de cables.
La tecnología USB ha sido promovida principalmente por Intel, aunque le han
seguido todos los grandes fabricantes, de forma que se ha convertido en un
estándar importante. En sus comienzos los interesados en esta tecnología
se agruparon en un foro, el USB Implementers Forum Inc., (USB-IF), que
agrupa a más de 460 compañías y ha publicado diversas revisiones de la
norma.
•
USB 0.9: Primer borrador, publicado en Noviembre de 1995.
•
USB 1.0: Publicada en 1996 establece dos tipos de conexión: La
primera, denominada velocidad baja ("Low speed"), ofrece 1.5 Mbps,
y está pensada para periféricos que no requieren un gran ancho de
banda, como ratones o joysticks. La segunda, denominada velocidad
completa ("Full speed"), es de 12 Mbps, y está destinada a los
dispositivos más rápidos.
•
USB 1.1: El USB 1.1 es un bus externo que soporta tasas de
transferencia de datos de 12 Mbps Un solo puerto USB se puede
utilizar para conectar hasta 127 dispositivos periféricos, tales como
ratones, módems, y teclados. El USB también soporta la instalación
Plug-and-Play y el hot plugging. Empezó a utilizarse en 1996, algunos
fabricantes de ordenadores empezaron a incluir soporte para USB en
sus nuevas máquinas. Con el lanzamiento del iMac en 1998 el uso del
USB se extendió. Se espera que substituya totalmente a los puertos
de serie y paralelos.
21
•
USB 2.0: La eshjpecificación del USB 2.0 fue lanzada en abril de
2000.También conocido como USB de alta velocidad, el USB 2.0 es
un bus externo que soporta tasas de transferencia de datos de hasta
480Mbps. El USB 2.0 es una extensión del USB 1.1, utiliza los mismos
cables y conectadores y es completamente compatible con USB 1.1.
Hewlett-Packard, Intel, Lucent, Microsoft, NEC y Philips tomaron
juntos la iniciativa para desarrollar una tasa de transferencia de datos
más alta que la del USB 1.1 para resolver las necesidades de ancho
de banda de las nuevas tecnologías.
22
2.2. MARCO NORMATIVO
Una Clase USB define un grupo de dispositivos de similares características,
cuyos requisitos vienen definidos mediante una Especificación de Clase
USB.
Las distintas Especificaciones de Clase USB permiten que los fabricantes
puedan desarrollar dispositivos que pueden controlarse mediante drivers
adaptativos (drivers que pueden controlar a los dispositivos en función de la
propia información descriptiva proporcionada por el dispositivo). Los drivers
adaptativos compatibles con una determinada Clase se denominan Drivers
de Clase.
De esta manera, los fabricantes de Sistemas Operativos y otras casas de
software pueden desarrollar distintos Drivers de Clase, con la finalidad de
poder controlar dispositivos pertenecientes a cualquiera de dichas Clases, sin
necesidad de que el fabricante del dispositivo tenga que desarrollar también
los drivers para cada entorno operativo en que quiera que funcione su
dispositivo.
2.2.1. Clases USB. Desde el punto de vista de USB, una Clase es un grupo
de dispositivos (o interfaces dentro de un dispositivo) con ciertas
características en común. Típicamente, dos dispositivos pertenecen a la
misma Clase si ambos utilizan formatos similares en los datos que reciben o
transmiten, o si ambos utilizan una misma forma de comunicarse con el
sistema.
El uso principal de una Clase USB es la de describir la forma en que un
interfaz se comunica con el sistema, tanto a nivel de datos como a nivel de
control. También existe un uso secundario, que es el de proporcionar
información sobre la funcionalidad que proporciona dicho interfaz. De esta
manera, la información de Clase proporcionada por el dispositivo puede
23
utilizarse para que el sistema localice un driver que pueda controlar tanto la
conectividad entre el interfaz y el sistema, como la propia funcionalidad del
dispositivo.
2.2.2. Relación Driver-Dispositivo. USB define una relación entre drivers y
dispositivos, totalmente diferente a la filosofía tradicional. En vez de permitir
que el driver tenga acceso directo al hardware del dispositivo, USB sólo
permite al driver comunicarse con el dispositivo a través de las “pipes”
establecidas entre el sistema USB y los distintos endpoints del dispositivo.
Una vez establecidas los pipes, el Sistema Operativo las pone a disposición
del driver en forma de interfaces software. Los tipos de transferencias a
través de dichas pipes dependen del tipo de endpoint, y pueden ser de 4
tipos: Bulk, Control, Interrupción e Isócrono.
Por esta razón, las Clases USB se basan en la forma en que el dispositivo o
interfaz se comunica con el sistema, y no simplemente en el tipo de servicio
proporcionado por el dispositivo. Por ejemplo, en la Clase de Dispositivos de
Impresión no interesa cuántos cartuchos de tinta o qué colores soporta la
impresora, sino si se envían los datos a través de una pipe tipo Bulk-OUT y si
tiene o no una pipe tipo Bulk-IN para reportar información de estado.
Asimismo, en la Clase de Dispositivos de
almacenamiento Masivo no
interesa si se trata de un disco duro o de un disquete, ni el número de
cabezas o cilindros, ni siquiera la capacidad del dispositivo. Lo que interesa
es si las lecturas y escrituras se van a realizar a través de pipes tipo Bulk-IN
y Bulk-OUT o a través de una pipe de Control, y si se va a utilizar una pipe de
Interrupción para reportar información de estado o si se realiza mediante
otros mecanismos.
Las Clases USB también pueden definir el formato de los datos que se
transmiten. Por ejemplo, la Clase de Dispositivos de Almacenamiento Masivo
define varios métodos opcionales para encapsular (transportar) distintos
24
juegos de comandos estándares, en los paquetes de datos que se transfieren
a través de las pipes. Un dispositivo concreto puede soportar uno o varios de
dichos métodos de transporte, y uno o varios juegos de comandos estándar
(SCSI, UFI, ATA, ATAPI, etc.), de forma que cuando el sistema lee la
información proporcionada por el dispositivo, puede buscar y asociar un
Driver de Clase compatible con alguno de los métodos de transporte y juegos
de comandos que el dispositivo soporta.
2.2.3. Descriptores. Desde el punto de vista del sistema USB, un dispositivo
puede tener varias posibles Configuraciones, en cada una de las cuales el
dispositivo puede funcionar de una manera distinta. En cada una de las
posibles configuraciones, el dispositivo queda organizado como un conjunto
de Interfaces, donde cada Interfaz especifica qué partes del hardware del
dispositivo interactúa con el sistema USB. Cada una de esas partes de
hardware se denomina Endpoint. Entonces, de una manera jerárquica, un
dispositivo es una colección de posibles Configuraciones, cada Configuración
es una colección de Interfaces, y cada Interfaz es una colección de
Endpoints. A su vez los Interfaces pueden admitir configuraciones
alternativas, con distintas colecciones de Endpoints en cada una de ellas.
Los dispositivos proporcionan toda la información descriptiva al sistema a
través de unas estructuras de datos denominados Descriptores. Existen
distintos descriptores que proporcionan información a nivel de dispositivo, de
configuración, de interfaz y de endpoint.
Las especificaciones de Clase USB definen las configuraciones, interfaces (y
sus
configuraciones
alternativas)
y
endpoints
que
pertenecientes a dicha Clase o Subclase deben soportar.
25
los
dispositivos
2.2.4. Clases, Subclases y Protocolos. Los descriptores de dispositivo y
de interfaz contienen una serie de campos que permiten al sistema clasificar
a los dispositivos. Estos campos son la Clase, la Subclase y el Protocolo.
El Sistema Operativo puede utilizar estos campos para localizar y asociar al
dispositivo o interfaz un determinado Driver de Clase, de entre todos los
Drivers de esa Clase disponibles en el sistema. También puede seleccionar
una
determinada
configuración
del
dispositivo,
o
una
determinada
configuración alternativa de un interfaz, en función de los protocolos
soportados por los distintos Drivers de Clase disponibles en el sistema para
esa Clase y Subclase de dispositivo.
2.2.5. Localización del driver. En algunas ocasiones, sólo es necesario un
driver para controlar a un dispositivo, mientras que en otras son necesarios
distintos drivers para controlar los distintos interfaces disponibles en el
dispositivo.
Se entiende que debe existir una manera estándar de localizar y asociar
drivers a dispositivos e interfaces, de manera que los fabricantes de
dispositivos y de Sistemas Operativos trabajen según un modelo común.
Una vez seleccionada una configuración, queda establecido el número de
interfaces.
Las
características
concretas
de
cada
interfaz
pueden
seleccionarse posteriormente a través de las posibles configuraciones
alternativas.
El algoritmo para localizar y asociar un driver se basa en la información
recibida del dispositivo en los descriptores. La primera búsqueda se basa en
la información recibida en el Descriptor de Dispositivo, y se trata de localizar
un único driver que controle todo el dispositivo. La información en la que se
basa esta primera búsqueda es (en orden de prioridad):
•
Fabricante & Producto & Versión del producto.
•
Fabricante & Producto.
26
Si no se ha localizado un driver y el campo Clase indica que el dispositivo
pertenece a una Clase específica del Fabricante, es decir, no pertenece a
una Clase estándar USB, la búsqueda continúa según los campos:
•
Fabricante & Subclase & Protocolo
•
Fabricante & Subclase
Si en cambio el dispositivo pertenece a una Clase estándar USB, la
búsqueda continúa en función de los campos:
•
Clase & Subclase & Protocolo
•
Clase & Subclase
Si en este proceso ya se ha localizado un driver, este driver ya puede
participar en la elección de la configuración en la que debe funcionar el
dispositivo.
Si no se ha podido localizar un driver, el Sistema Operativo es responsable
de seleccionar una configuración para el dispositivo, y seguir buscando un
driver para cada interfaz disponible en dicha configuración. Esta segunda
búsqueda se basa en la información recibida en los descriptores de
dispositivo y de interfaz. De nuevo en orden de prioridad, los campos
utilizados en esta segunda fase son:
•
Fabricante & Producto & Versión del producto & Número de la
configuración & Número del interfaz.
•
Fabricante & Producto & Número de la configuración & Número del
interfaz.
27
Si no se ha localizado un driver y el interfaz pertenece a una Clase
Específica del Fabricante, es decir, no pertenece a una Clase estándar USB,
la búsqueda continúa según los campos:
•
Fabricante & Subclase del interfaz & Protocolo del interfaz
•
Fabricante & Subclase del interfaz
Si en cambio el interfaz pertenece a una Clase estándar USB, la búsqueda
continúa en función de los campos:
•
Clase del interfaz & Subclase del interfaz & Protocolo del interfaz
•
Clase del interfaz & Subclase del interfaz
2.2.6. Peticiones específicas de Clase USB y peticiones específicas del
fabricante. La norma USB denomina “peticiones” (requests) a las distintas
funciones que el sistema USB puede solicitar a los dispositivos, lo cual es
distinto de los comandos que las aplicaciones pueden enviar, y que
dependerán del juego de comandos que se esté utilizando en concreto con
cada dispositivo.
La norma USB define una serie de peticiones estándar que deben
implementar todos los dispositivos, mientras que las especificaciones de
Clase USB y los fabricantes de dispositivos pueden definir peticiones
adicionales, denominadas respectivamente peticiones específicas de Clase y
peticiones específicas del Fabricante.
La forma de enviar al dispositivo una petición USB es siempre a través de
una Transferencia de Control dirigida a la pipe de Control por Defecto, en
cuya fase de SETUP se indica el tipo de petición (Estándar, de Clase o de
Fabricante) y el destinatario de la misma (el dispositivo, un interfaz o un
endpoint).
28
Si la petición es Estándar, está definida en la propia norma USB, pero si es
de Clase, la Clase a la que pertenece el destinatario de la petición indica en
qué Especificación de Clase está definida dicha petición.
Por ejemplo, si el destinatario es el dispositivo, entonces la Clase indicada en
el descriptor del dispositivo indica la Especificación de Clase donde está
definida la petición. Si el destinatario es un interfaz o endpoint, entonces la
Clase indicada en el descriptor del interfaz indica la Especificación de Clase
donde está definida la petición. Si la petición es de Fabricante, entonces es el
propio fabricante quien ha definido dicha petición.
29
3. METODOLOGÍA
3.1. ENFOQUE DE LA INVESTIGACIÓN
La investigación y desarrollo del proyecto se fundamentaron por el enfoque
Empírico-Practico, ya que la teoría fue la base del proyecto, que luego fue
evaluada con métodos prácticos de experimentación y optimización
creciente, partiendo desde un inicio claro, fundamentado por la teoría hasta
la terminación del trabajo justificado por la relación Teoría-Práctica, que se
desarrollo durante las diferentes etapas del proyecto.
3.2. LÍNEA DE INVESTIGACIÓN
Tecnologías actuales y sociedad
Sublinea de facultad: Instrumentación y control de procesos
Campo Temático: Control
3.3. HIPÓTESIS
Con el diseño de un sistema de control de acceso y autorización, que brinde
sencillez y facilidad de manejo a los usuarios, y además sea capaz de actuar
de forma robusta ante cualquier situación, se logran vencer algunos
obstáculos, como los altos costos que sistemas mucho más complejos
devengan, la dificultad que tienen los usuarios para adaptarse a sistemas
complejos de muchas opciones que en algún momento se consideran
innecesarias, y la dificultad de implementación de otros sistemas basados en
técnicas biométricas o de complejos algoritmos de encriptación.
30
3.4. VARIABLES
3.4.1. Variables independientes.
•
TIPO DE MICROCONTROLADOR: Anteriormente se menciono que el
fabricante microchip ofrece diferentes modelos establecidos en
distintas gamas, pero el modelo que mejor se adapta a los
requerimientos y que tiene mejor relación función-costo, es el PIC
18f4550.
•
COMUNICACIÓN INTERNA ENTRE MÓDULOS: Ya sea USB o
UART, la comunicación limpia y clara entre los módulos es necesaria.
•
EXPERIENCIA DE USUARIO: se especifica que el usuario puede ser
cualquier persona con conocimiento o no de sistemas informáticos y
manejo de plataforma Windows, dada la sencillez y claridad del
programa los usuarios no dependen enteramente de un conocimiento
previo para manejar el programa y el sistema en general.
3.4.2. Variables dependientes
•
DISEÑO DE LOS MÓDULOS: Depende enteramente de la selección
del microcontrolador, el cual también afecta la forma en la que se
simulan los circuitos en la etapa de diseño.
•
INTERFAZ DE USUARIO: Depende en gran parte del diseño del
programa, pues es posible que se le de mayor importancia a las
funciones que pueda ofrecer dejando a un lado la sencillez y claridad.
31
4. DESARROLLO INGENIERIL
Para el desarrollo correcto del proyecto, se tiene en cuenta el siguiente
proceso:
Teoría USB.
Para desarrollar este paso es necesario disponer de una fuente de
información amplia, y que sea consistente con los requerimientos, en este
caso la fuente primaria de información para la implementación de este
proceso en especial fue el foro de implementadores USB (USB implementers
Forum). Desde el punto de vista electrónico, fue necesario aprender los
requerimientos de voltaje, corriente, codificación lineal, entre otros. Desde el
punto de vista de compatibilidad de los dispositivos con cualquier sistema,
también fue necesario investigar las opciones y los documentos del
fabricante del microcontrolador.
Programación Software:
Para este paso, fue necesario recurrir al programa de diseño Borland C++
Builder, (Versión 6.0) que facilita enormemente la programación de la interfaz
de usuario del programa, dado que el paquete ofrece un sistema IDE con
entorno grafico en el que la opción de programación es totalmente orientada
a objetos, de esta forma se pueden configurar el comportamiento de
ventanas, botones, cuadros de texto y demás opciones disponibles, todo
manteniendo el estándar C++.
El objetivo del programa en la parte del PC, es simplificar la experiencia de
usuario final, de esta forma se tratan de ocultar todos aquellos detalles
complejos que puedan comprometer la sencillez y claridad de la interfaz de
programa final, esta interfaz se pensó para que cualquier usuario que tenga
experiencia mínima de manejo de computadores pueda usar la aplicación.
Selección de hardware:
32
En este punto, se tenía un conocimiento general de lo que el programa y el
dispositivo físico deberían realizar, el siguiente paso fue elegir los
componentes más adecuados a las necesidades del programa, en la parte
del computador personal, se eligió la plataforma Windows que mantiene
estabilidad y compatibilidad entre versiones.
En el caso del módulo “llave”, se pensó en manejar un microcontrolador del
fabricante microchip, consecuentemente, fue necesario explorar las opciones
de todas las gamas de microcontroladores, aunque haciendo énfasis en los
sistemas de comunicaciones alámbricas, específicamente que pudieran
manejar el protocolo serial universal USB.
El fabricante ofrece varios modelos dentro de las gamas media y alta que
mantienen la compatibilidad con USB, en principio el objetivo del proyecto es
brindar sencillez y rapidez durante las etapas de desarrollo, y estos factores
se lograban de manera óptima con el dispositivo perteneciente a la gama
media de referencia 18f4550, que además de ofrecer la conexión USB,
brinda ventajas ante sus competidores de gamas superiores como los PIC de
16 bits serie 24 o los PIC de 32 bits serie 32, como: como la facilidad de
desarrollo ya que es un sistema de 8 bits el cual se ha manejado durante la
carrera, la facilidad de desarrollo del Firmware siendo posible elegir el
lenguaje de programación entre assembler, Basic y C.
Para simplificar la comunicación entre los módulos de software y de apertura,
se opto por elegir un módulo de conversión USB a UART, compatible con el
microcontrolador 16f628 que controla el driver que consecuentemente
controla el mecanismo de apertura de la puerta. El Driver L298 es un driver
de puente completo doble, que con una entrada TTL puede controlar cargas
inductivas como el motor.
Durante el desarrollo y evolución de los pasos mencionados anteriormente,
fue necesario realizar pruebas para comprobar la consistencia y la correcta
comunicación del sistema global, para el análisis de la parte electrónica fue
33
necesario realizar simulaciones en primera instancia, en la que se pueden
descartar elementos de forma sencilla y sin que incremente los costos del
diseño, para la parte de simulación se uso el programa Proteus ISIS, ya que
ofrece la posibilidad de incluir los microcontroladores totalmente funcionales,
lo que ofrece una ventaja enorme sobre los diseños físicos.
Cuando se cumplió la etapa de simulaciones se paso a hacer prototipos
físicos sencillos que demostrarían que los resultados obtenidos en las
simulaciones fueran consistentes con los resultados prácticos. Para el caso
del software del computador, fue necesario realizar secuencias de prueba y
error, hasta que el programa compilaba por completo, de esta forma se
observo el proceso completo de desarrollo del programa, desde las primeras
etapas de declaración de variables hasta las etapas avanzadas de manejo de
errores.
En el desarrollo del proyecto se contempla el diseño y configuración de tres
módulos; a continuación se muestra la interacción y el funcionamiento de
cada uno de ellos y su disposición en el sistema; módulo móvil que para
efectos de practicidad será llamado “la llave”, un módulo software que verifica
si la llave está autorizada y un módulo de apertura, que está encargado de la
activación mecánica del cerrojo una vez haya sido hecha la verificación en
los módulos anteriores.
Figura 7. Diagrama a bloques del sistema.
34
4 MÓDU
4.1.
ULOS.
4
4.1.1.
Módulo Llave. Este aparrtado explicca en detalle el proceso de diseñ
ño
y posterior desarrollo que representa la “llavve”.
F
Figura
8. Dia
agrama de flujo
f
del mód
dulo llave
35
Para el desarrollo de este módulo, se toman en cuenta algunos criterios
como son:
•
Tamaño del módulo.
•
Elección del microcontrolador.
•
Programador.
•
Dispositivos a emplear.
•
Diseño del circuito.
A continuación se desarrollan los criterios para el diseño y construcción del
módulo móvil.
4.1.1.1. Tamaño del módulo. Es un aspecto muy importante a tener en
cuenta, ya que el objetivo es que este remplace una llave común, por esta
razón no debe ser grande ni pesado, tampoco debe presentar una
manipulación difícil, pues está pensado para ser usado por todo tipo de
usuario.
4.1.1.2. Elección del microcontrolador. Para la mayoría de circuitos
electrónicos en el mundo, se necesita algún dispositivo que realice
operaciones lógicas digitales y de control, este proyecto no es la excepción,
pero el microcontrolador debe ser seleccionado de una manera cuidadosa,
analizando las características y requerimientos del diseño.
Como una de las prioridades del proyecto es utilizar el protocolo USB,
obviamente el microcontrolador que se seleccione debe ser funcional para
este protocolo.
Se pensó en el microcontrolador Microchip 18f4550 que se puede encontrar
en diferentes package pero tiene una configuración TQFP que resulta muy
útil por su pequeño tamaño, además de tener manejo de USB incorporado.
36
Al comienzo del proyecto fue necesario observar que microcontroladores
ofrecían la posibilidad de trabajar con protocolos alámbricos de transmisión
de datos, que facilitaran la función de interfaz entre el PC y el dispositivo
final, en la siguiente tabla se observan algunas de las características
específicas de cada uno de los microcontroladores que se pensaron para la
Aplicación.
Tabla 3. Comparación de los microcontroladores optativos del módulo llave.
Analizando las características se decidió que la mejor opción en cuanto a
funcionalidad solamente sería el PIC32, gracias a su arquitectura de 32 bits
nos daría mayores opciones y la oportunidad de profundizar en la
complejidad de la aplicación sin embargo el costo de la importación y de
poder conseguirse en un almacén local el precio total del dispositivo sería
muy elevado para los requerimientos de la aplicación, además, las opciones
de “Embeded Host” y “USB On The Go”, serian un poco desperdiciadas..
La opción que nos ofrece el PIC24, sería una opción media entre la
complejidad del PIC32 y la sencillez del PIC18, dada su arquitectura de 16
bits, se encuentra en una posición media que ofrece las ventajas de las dos
gamas, sin embargo analizando los requerimientos de la aplicación que se
estaba desarrollando se llego a la conclusión de que este Pic ofrece muy
37
b
buenas
po
osibilidadess a un precio
p
acccesible, au
unque algu
unas no se
a
aprovechar
rían al máxximo, además de esto se intento buscar el dispositivo
d
e
en
e mercado
el
o nacional sin
s mayor éxito.
A final, el PIC18 offrece variass ventajas sobre los otros disp
Al
positivos, las
c
cuales
se liistan a conttinuación:
•
Men
nor costo.
•
Arqu
uitectura 8 bits acorde
e a lo apren
ndido en la universidad
d.
•
Posibilidad de programacción en len
nguaje C, que facilita
a la tarea de
d
dise
eño del prog
grama.
•
Num
mero de pin
nes suficiente para los requerimie
entos.
•
No está
e
limitad
do a un mo
odelo especcífico de prrogramadorr, puesto qu
ue
se pueden
p
usa
ar los progra
amadores genéricos
g
m comunes.
más
F
Figura
9. Dia
agrama de pines
p
del miccrocontrolad
dor tipo PDIP
P
F
Fuente:
Microchip inc., www.microc
w
chip.com
38
F
Figura
10. Diagrama
D
de pines del microcontrola
m
ador tipo TQFP
F
Fuente:
Microchip inc., www.microc
w
chip.com
L caracte
Las
erísticas priincipales po
or las que se
s eligió este micro so
on:
•
Velocidad
V
d hasta 48MHz
de
4
con
n cristal exxterno, y de 8MHz co
on
oscilador
o
intterno.
•
Módulo
M
PWM.
•
Comunicaci
C
USART y UART).
U
ón serial sííncrona y asíncrona (U
•
Comunicaci
C
ón I2C.
•
35
3 pines I/O
O (Entrada y salida).
•
Módulo
M
de comunicaci
c
ón USB.
39
4
4.1.2.
Mód
dulo de so
oftware. Para el con
ntrol del mó
ódulo de apertura
a
y la
l
lectura
del módulo lla
ave, se utiliza el módu
ulo de softw
ware, que consta
c
de un
u
p
programa
y un entorno grafico
o que se encargan de crear los
l
usuario
os,
g
gestionar
una
u
base de
d datos a partir de un
u archivo de texto, verificar
v
si la
i
información
n grabada en
e el módu
ulo llave corrresponde a un usuarrio autorizad
do
y por ultimo
o enviar la orden
o
de acctivación pa
ara el módu
ulo de aperrtura.
F
Figura
11. Diagrama
D
de flujo del mó
ódulo softwa
are
40
En la elaboración del módulo de software se tuvo en cuenta un factor muy
importante, el hecho de que el sistema de control de acceso es diseñado
para todo tipo de usuarios, esto hace que sea necesaria una interfaz de fácil
manejo y comprensión, razón por la cual este módulo se creó en compilador
Borland C++ Builder versión 6.0.
•
C++Builder
C++Builder es un entorno de desarrollo integrado en lenguaje C++ para
Windows inicialmente de la empresa Borland, actualmente de su filial
CodeGear, dentro de sus características más importantes se puede observar
que es un IDE que se ejecuta bajo línea de comandos.
Una de sus más grandes ventajas es que es completamente intuitivo, siendo
como programar en un entorno Visual Basic pero con la solidez de un
lenguaje como C++.
•
Versiones C++Builder
Lanzado después de Delphi, y con un entorno similar a éste. Muchos
componentes de Delphi pueden utilizarse en C++. La última versión es
C++Builder 2009 (lanzada en 2008), de la que existen tres ediciones:
Professional, Enterprise y Architect. Está incluido en CodeGear RAD estudio
2009, junto con Delphi 2009. La anterior versión 2006 estuvo incluida en
Borland Developer Studio 2006. En septiembre de 2006 se lanzó una versión
reducida, llamada Turbo C++, recuperando un nombre clásico dentro de los
productos Borland. Junto con otras herramientas de desarrollo fue transferido
a CodeGear al crearse esta filial de Borland en noviembre de 2006.
•
Interfaz de C++ Builder
En este entorno se pueden encontrar de manera muy fácil dos secciones,
una sección grafica que permite arrastrar elementos, ubicar botones, campos
41
d texto, campos de comprrobación entre
de
e
otross objetos de mane
era
i
instantánea
a, y la se
ección de código en
e la cuall se lleva a cabo la
p
programac
ión de todos los elem
mentos que compone
en la aplicación, de tal
t
m
manera
qu
ue el prog
gramador pueda
p
mon
nitorear el progreso en los dos
a
aspectos.
F
Figura
12. In
nterfaz graficca de C++ Builder
B
6
F
Fuente:
Borland Software Corporation copyright 2002
S
Software
para
p
contro
ol de acce
eso y autorrización mediante pro
otocolo US
SB
“
“USB
Key”.. Para ver el
e código fu
uente véase
e ANEXO 3.
3
L columna
La
a vertebral del sistema
a de control de acceso
o es el prog
grama que se
c
creó,
encarrgado de re
ealizar una interacción
n entre el módulo
m
llave
e y el módu
ulo
d apertura
de
a por med
dio de la creación
c
y posterior verificación
v
de usuarios
42
d
dentro
de una
u lista de
efinida por medio de una interfa
az gráfica y de fácil uso
p
para
cualqu
uier persona que haga
a las veces de adminisstrador.
F
Figura
13. Ventana
V
principal USB ke
ey.
Fuente: Dis
seño propio
o MBR.1
Esta es la ventana
v
principal dond
de se puede encontra
ar la lista de
e los usuarios
a
autorizados
s, la opción
n de registra
ar que sirve
e para crea
ar un usuariio nuevo, y la
o
opción
de seleccionar
s
r puerto, qu
ue verifica el puerto en
e el que se
e encuentra
an
c
conectados
s los módulos llave y de
d apertura
a.
F
Figura
14. Ventana
V
de selección
s
de
e puerto.
Fuente: Dis
seño propio
o MBR.
1
MBR: diseñado por los autores
a
como parte del dessarrollo del prroceso
43
L ventana
La
a de selección de puerto permite
e selecciona
ar manualm
mente en qu
ue
p
puerto
se conectaron
c
los módulo
os llave y de
e apertura.
F
Figura
15. Ventana
V
principal USB ke
ey con lista de usuarios desplegada
a.
Fuente: Dis
seño propio
o MBR.
Después de haber se
eleccionado
o el puerto correcto,
c
se
e despliega
a una lista de
d
l usuario
los
os permitido
os y el pro
ograma enttra en mod
do de de espera.
e
En el
m
modo
de es
spera el PC
C escanea constantem
mente los puertos
p
preg
guntando por
p
u usuario autorizado
un
o, una vez se introduzca en el puerto USB
B un módu
ulo
l
llave
con un
u usuario permitido, el program
ma envía al módulo de
e apertura la
o
orden
de activación
a
de un dispositivo eléctrico llamad
do pestillo, que
q al recib
bir
e
esta
orden retira el se
eguro que bloquea la puerta, pe
ermitiendo así
a el acceso
a recinto o deposito.
al
Una vez re
etirado el módulo
m
llave, el progrrama envía al módulo
o de apertu
ura
u orden para que vuelva a su posición inicial (de bloqueo) de
una
d tal mane
era
q vuelva al modo de
que
e espera.
44
4
4.1.3.
Mód
dulo De Ap
pertura. Estte mecanissmo recibe órdenes de
el módulo de
d
s
software
que le indicca si debe
e activar el
e pestillo o si es un
n usuario no
n
a
autorizado
mantener restringido
r
el acceso al
a recinto monitoreado
m
o.
Figura 16.
1 Diagram
ma de flujo de
el módulo de
e apertura
45
Para llevar a cabo esta función se utiliza un sistema compuesto por dos
microcontroladores que se encargan de recibir la información del ordenador y
convertirlo en señales de voltaje para el driver del motor que acciona la
apertura del pestillo.
Tabla 4. Comparación de los microcontroladores optativos de módulo apertura.
PIC16F628A
Memoria de programa(KB)
PIC16F877A
3.5 flash
14 flash
5
5
RA M (bytes)
224
368
EEPROM(bytes)
128
256
18
40
Velocidad CPU(MIPS)
Pines
Esta tabla muestra las opciones que se tenían para el control del motor, la
característica principal era que tuvieran UART para poder comunicarse con el
integrado FT232 que convierte USB a Serial, según las características la
mejor opción fue el PIC16F628A en parte porque tiene un costo más bajo y
tiene menos características que se podrían desperdiciar.
46
El integrado FT232 se
s encarga de recibir la informacción del orrdenador y la
c
convierte
en
e una tabla
a de datos que
q envía al
a PIC para procesarlo
os.
F
Figura
17. Diagrama
D
de pines del in
ntegrado FT2
232.
F
Fuente:
Futu
ure Technolo
ogy Devicess International Limited.
47
El microcon
ntrolador prrincipal es el
e PIC 16f6
628A que re
ecibe la info
ormación y la
p
procesa
pa
ara enviar la
as ordenes al driver L2
298 para acctivar el mo
otor.
F
Figura
18. Diagrama
D
de pines del microcontrola
m
ador PIC 16ff628A.
F
Fuente:
Microchip inc., www.microc
w
chip.com
48
El driver L2
298 se enca
arga de con
nvertir la información del
d micro en
e señales de
d
12 voltios para
p
activar el motor en el mom
mento de la apertura y el cierre del
d
p
pestillo
de la puerta qu
ue controla
a.
F
Figura
19. Diagrama
D
de pines driver L298.
F
Fuente:
© 2000 STMicro
oelectronics
49
El accionad
dor es un pestillo
p
elécctrico que fu
unciona con modo iniccial “cerrad
do”
l cual evita que ante
lo
e una falla de
d electricid
dad el siste
ema no que
ede abierto
oy
v
vulnerable
a ser pene
etrado por intrusos; el pestillo o seguro
s
es activado por
p
u motor de
un
e 12 voltioss que recibe
e señales de
d voltaje del driver L2
298.
F
Figura
20. Pestillo
P
eléctrrico.
F
Fuente:
Zho
ongshan Rd Car Accesso
ories Manuffacturing Facctory.
En la etapa
a de desarrrollo del programa pa
ara el micrrocontrolado
or, se usa el
e
entorno
de
e programa
ación propo
orcionado por el fabricante miccrochip, esste
e
entorno
es llamado MPLab IDE (Integrated
(
ent Environ
nment), en su
Developme
ú
última
vers
sión 8.14, permite
p
dessarrollar el programa
p
e lenguaje
en
e de maquin
na
a
assembler
(ensambla
ador), adem
más incluye
e una opció
ón de desccarga gratuita
a
adicional
de
el compilad
dor C18 que
e desarrolla
a el proceso
o en un lenguaje de alto
n
nivel
como C.
50
4 DISEÑ
4.2.
ÑO DEL CIR
RCUITO
4
4.2.1.
MPLab IDE 8.14. El entorno de
d desarro
ollo proporrcionado por
p
m
microchip,
es muy se
encillo e inttuitivo de usar, y tiene
e una gran
n cantidad de
d
f
funciones
completas mezcladass con una interfaz liimpia y orrdenada. Las
c
característi
cas princip
pales del IDE, son:
•
Posiibilidad de reemplazar
r
r los motore
es de comp
pilación.
•
Sopo
orte para desarrollo de aplicaciones robusta
as usando lenguajes de
d
alto nivel.
•
Simu
ulador de fu
uncionamie
ento a nivel de registro
os.
F
Figura
21. Ventana
V
de trabajo de MPLAB.
F
Fuente:
Microchip techn
nology incorp
porated USA
A
51
S debe crrear un pro
Se
oyecto, sele
eccionando Project en
n la barra de comando
os,
l
luego
se selecciona
s
la opción Project
P
Wizzard, con el
e fin de seleccionar la
c
configuraci
ón del proyyecto.
A continua
ación se muestra el
e proceso
o de crea
ación de un proyeccto
s
seleccionan
ndo específicamente el
e kit de com
mpilador C18.
F
Figura
22. ConFiguració
C
ón de proyeccto.
F
Fuente:
Microchip techn
nology incorp
porated USA
A
52
aparece una pantalla de bienvenida, que describe la función de la ultima
ventana en aparecer, clic en Next, para luego encontrar la ventana de
selección de dispositivo, en la que se elije el microcontrolador para realizar la
tarea, luego, aparece la ventana de selección de compilador, en la que
aparecen los kits disponibles, seleccionamos “Show all Installed Toolsuits”,
en esta opción aparecerá en la lista desplegable “Microchip C18 Toolsuite”,
clic en Next, aparece la ventana de localización de archivo de proyecto, en el
que se le indica al programa el lugar en el que se guarda el archivo.
Después de seleccionar el lugar del archivo, clic en Next y aparece la opción
de agregar archivos existentes al proyecto, en esta ventana, se pueden
agregar los segmentos de código, como no se poseen, se pasara por alto
esta opción, para agregar más tarde los archivos de encabezado del
programa. Por último, la última ventana de esta selección muestra un
resumen de la configuración del proyecto, el dispositivo a usar y el Toolsuite
con el que se pretende compilar el código.
53
4.2.2. Proteus 7.2. Proteus es un software informático utilizado para crear y
simular circuitos electrónicos.
Este programa está compuesto por tres módulos básicos:
•
I.S.I.S. (“Sistema inteligente de entrada esquemática"): ISIS el módulo
se utiliza para capturar esquemáticos. Aquí usted puede sacar sus
componentes y conexiones directamente en el área de trabajo. I.S.I.S.
le permite elegir una gran cantidad de componentes con la información
del fabricante de sus bibliotecas. Se hace automáticamente las
conexiones entre dos puntos del circuito, y le da un "Netlist" de la
tabla. V.S.M. (“Virtual Modeling System"): Esta utilidad está integrada
en el programa principal. Permite simular el circuito y ver distintos
gráficos, pantallas o instrumentos que nos dan información acerca de
cómo es su circuito de trabajo.
•
ARES (“Advanced Routing modelado"): Este módulo es uno con el
que usted puede hacer las placas de circuito impreso (PCB).
Automáticamente las rutas de los PCB y le permite modificar de forma
manual, lo que le da el aspecto final de la PCB.
54
Figura 23. Diagrama
D
esquemático realizado
r
en proteus ISIS
S módulo lla
ave.
Fuente: Labcenter Ele
ectronics. Diseño
D
prop
pio MBR.
55
F
Figura
24. Diseño
D
del circuito impre
eso PCB en proteus
p
ARE
ES módulo lllave.
Fuente: Labcenter Ele
ectronics. Diseño
D
prop
pio MBR.
F
Figura
25. Visualización
V
n 3D de los componente
c
s en el circu
uito impreso módulo llave.
Fuente: Labcenter Ele
ectronics. Diseño
D
prop
pio MBR.
56
Figura 26. Diagrama
F
D
esquemático realizado
r
en proteus ISIS
S módulo ap
pertura.
Fuente: Labcenter Ele
ectronics. Diseño
D
prop
pio MBR.
57
F
Figura
27. Diseño
D
del circuito impre
eso PCB en proteus
p
ARE
ES módulo apertura.
a
Fuente: Labcenter Ele
ectronics. Diseño
D
prop
pio MBR.
F
Figura
28. Visualizació
ón 3D de lo
os compone
entes en el circuito impreso módu
ulo
a
apertura.
Fuente: Labcenter Ele
ectronics. Diseño
D
prop
pio MBR.
58
4 INSTA
4.3.
ALACIÓN DEL DRIVER
R EN WIND
DOWS XP
A conecta
Al
ar el dispo
ositivo móvvil (llave), en un computador con sistem
ma
o
operativo
Windows
W
X
XP,
apareccerá una ventana
v
pa
ara indicarr la falta del
d
c
controlador
r del dispossitivo.
F
Figura
29. Opción
O
de bú
úsqueda del controladorr en internet..
Fuente: Mic
crosoft Win
ndows XP.
En esta ven
ntana es ne
ecesario ind
dicarle al sistema ope
erativo que el driver esstá
a
almacenad
o en el equ
uipo local, y que no es
e necesariio conectarrse a intern
net
p
para
busca
arlo, en esta
a ventana se
s le indica al sistema operativo la
l opción “N
No
p el mom
por
mento”, y lu
uego se habilitara el botón
b
siguie
ente en la parte inferiior
d la ventana, luego
de
o de dar clic
c en sigu
uiente, la ventana
v
ca
ambiara pa
ara
m
mostrar
el nombre de
el dispositivvo conecta
ado y dos opciones
o
para ubicar el
c
controlador
r.
59
F
Figura
30. Opción
O
de insstalación automática o manual
m
.
Fuente: Mic
crosoft Win
ndows XP.
En este caso, el nombre del dispositivo llavve, es Pic USB. Wind
dows además
d indicar el nombrre del disp
de
positivo co
onectado, permite se
eleccionar la
i
instalación
automática del conttrolador, siempre y cuando
c
estte haya sid
do
i
incluido
en los paquettes incluidos por defeccto en el sisstema opera
ativo.
L otra opción es instalar el controlador desde una lista o ubicació
La
ón
e
especifica,
para este caso en esspecial, se usa la seg
gunda opciión, luego de
d
s
seleccionar
rla, se da clic en siguie
ente y aparrecen las siiguientes opciones.
60
F
Figura
31. Selección
S
de la ubicación
n del controllador.
Fuente: Mic
crosoft Win
ndows XP.
L opciones proporccionadas en
Las
n esta venta
ana permite
en indicar la
a ruta exaccta
d la carpe
de
eta que co
ontiene el archivo
a
del controlador, y tamb
bién permite
en
e
examinar
el
e equipo carpeta
c
por carpeta para
p
indica
arle en qué
é lugar estta,
t
también
ofrrece la possibilidad de buscar en medios exttraíbles com
mo disquetes
y CDs, dad
do que es la
a forma má
ás común para
p
distribuir los conttroladores de
d
a
algunos
dis
spositivos, para este caso
c
se busca la carp
peta conten
nedora con el
b
botón
exam
minar, que muestra
m
otrra ventana:
61
F
Figura
32. Localización
L
grafica de la
a carpeta co
ontenedora.
Fuente: Mic
crosoft Win
ndows XP.
En esta ve
entana pod
demos indiccar la ruta hacia la carpeta
c
con
ntenedora de
d
f
forma
grafica, accedie
endo a los directorioss en forma jerárquica,, después de
d
s
seleccionar
r el lugar de
e origen de
e la carpeta
a, se da clicc en acepta
ar, y luego en
e
s
siguiente,
después
d
de
e este proceso se iniccia una cop
pia de archivos del lug
gar
d origen a la carpeta
de
a de controladores de Windows.
W
F
Figura
33. Proceso de
d copiado de archivo
os al directtorio raíz de
d Windowss .
Fuente: Mic
crosoft Win
ndows XP.
62
5 PRESEN
5.
NTACIÓN Y ANÁLISIS
S DE RESU
ULTADOS
El funciona
amiento de
el sistema de control de acceso se basa en que por
p
m
medio
de recursos de softw
ware y ha
ardware se
e pueda realizar un
na
a
autentificac
ción para po
oder acced
der a un reccinto o depo
osito, en el caso de esste
p
proyecto
se
e usará un deposito qu
ue hace lass veces de caja fuerte.
L
Los
compo
onentes de
el sistema
a se puede
en observa
ar en las dos figuras
s
siguientes
F
Figura
34. Componente
C
s del sistem
ma.
Fuente: Dis
seño propio
o MBR.
1. Pesttillo eléctricco: Es un dispositivo usado
u
comú
únmente en
n los seguros
para
a las puerta
as de los au
utomóviles, su función
n es bloque
ear por med
dio
de un
u motor bipolar la ap
pertura de una puerta
a, este se abre con un
u
volta
aje de 12V DC y se cierra
c
con un
u voltaje de
d -12V DC
C, la señal de
d
activ
vación le lle
ega por me
edio de un driver que a su vez es
e controlad
do
63
por medio del integrado
i
T
TF232
y el microcontrrolador 16F
F628A. (todos
los elementos
e
mencionad
dos anteriorrmente haccen parte de
el módulo de
d
aperrtura).
2. Circu
uito princip
pal del
módulo de
e apertura
a: en este
e circuito se
encu
uentran el microcontro
olador, el in
ntegrado y el driver anteriormen
a
nte
men
ncionado.
3. Puerrto USB he
embra en el cual se conecta el
e módulo llave para su
postterior autenticación.
4. Puerrtos USB del
d PC para leer los datos del módulo llave y enviiar
seña
al de contro
ol al módulo
o de apertura.
5. PC en
e el cual se
s encuentrra el módulo de softwa
are, principal encargad
do
de controlar
c
el sistema.
F
Figura
35. Módulo
M
llave foto real y diseño
d
3D.
Fuente: Dis
seño propio
o MBR.
6. Mód
dulo llave: En
E el cual se
s guarda la identidad
d del usuario, para qu
ue
sea leída por el módulo de softwa
are, y este accione el
e módulo de
d
aperrtura
64
L pasos para obserrvar el resulltado del sisstema son los siguientes.
Los
1. Conectar los pu
uertos USB
B de la caja fuerte a loss del PC.
F
Figura
36. Conexión
C
mó
ódulo apertura a módulo
o software.
Fuente: Dis
seño propio
o MBR.
2. Inicia
ar el módullo de softwa
are.
F
Figura
37. Ventana
V
de in
nicio de inte
erfaz.
Fuente: Dis
seño propio
o MBR.
65
3. Sele
eccionar el puerto en el
e que se encuentra
e
c
conectado
e módulo de
el
d
aperrtura.
F
Figura
38. Selección
S
de puerto.
Fuente: Dis
seño propio
o MBR.
4. Intro
oducir el mó
ódulo llave en el puerto USB hem
mbra de la caja
c
fuerte.
F
Figura
39. Conexión
C
mó
ódulo llave a módulo ape
ertura.
Fuente: Dis
seño propio
o MBR.
66
5. Espe
erar a que
e el módu
ulo de softtware reco
onozca el dispositivo y
veriffique el usu
uario (aproxximadamente 6 segund
dos).
F
Figura
40. Reconocimie
R
ento de usua
ario.
Fuente: Dis
seño propio
o MBR.
67
6. Una vez el programa envié
e
la se
eñal de acctivación al módulo de
d
aperrtura, el pe
estillo eléctrrico libera el
e seguro e la puerta,, permitiend
do
abrirrla.
F
Figura
41. Sistema
S
abie
erto.
Fuente: Dis
seño propio
o MBR.
7. Una vez manip
pulado el co
ontenido de
e la caja fue
erte se proccede a cerrrar
la puerta y rettirar el módulo llave para que el módulo de softwa
are
evo la puerta y condu
uzca el sisttema hasta
a el modo de
d
bloquee de nue
era.
espe
F
Figura
42. Sistema
S
cerra
ado y en mo
odo de espera.
Fuente: Dis
seño propio
o MBR.
68
6. CONCLUSIONES
El diseño de un sistema de acceso controlado vía USB se cumple a
cabalidad dado que se comprobó que el prototipo y sus componentes han
realizado las funciones debidas para la consecución de la seguridad
necesaria para el proyecto.
Para este sistema se diseñó un software y dos tipos de hardware para poder
generar los módulos de acuerdo a la necesidad del proyecto basado en los
sistemas preexistentes.
El dispositivo puede reconocer el tipo de usuario y sus permisos para
acceder o no a cada recinto de acuerdo a la base de datos desarrollado en el
módulo software, lo que evita tener que tener un dispositivo llave por cada
puerta a la que se desee acceder.
Para poder concluir el proyecto se presentaron varios inconvenientes como la
selección del microcontrolador, el desarrollo de los elementos físicos, y la
interconexión hardware-software, sin embargo, por medio del método de
prueba y error se pudo llegar a conseguir los elementos y sistemas óptimos
para el completo funcionamiento del proyecto.
Mediante el uso del protocolo USB y el desarrollo de esta aplicación, se
puede
observar
que
USB
está
relacionado
en
gran
medida
al
almacenamiento masivo de datos, también se pueden notar las aplicaciones
como dispositivos HID, y en general usos que faciliten la interacción entre el
Computador personal y proyectos electrónicos que puedan requerir la
transferencia de datos usando este protocolo en vez de usar los protocolos
antiguos como serial o paralelo.
69
7. RECOMENDACIONES
Dado que el sistema consta de varios módulos, es fundamental aprender a
configurar todos los detalles que hacen funcionar correctamente el sistema,
para lograr esto, es necesario revisar los siguientes parámetros:
•
El proyecto fue diseñado en base a la plataforma Windows, que ofrece
en la mayoría de los casos compatibilidad con versiones antiguas y
versiones futuras, lo que ofrece una fácil migración del programa
cuando se presente un cambio en el sistema operativo, sin embargo,
es recomendado tener un computador con sistema operativo Windows
XP, preferiblemente con Service Pack 2, que ofrece incrementos en la
estabilidad global del sistema.
•
El módulo software fue diseñado enteramente en Borland C++ Builder,
pero eso no implica que sea necesario tenerlo instalado, dado que el
programa compila una versión Stand Alone del módulo.
•
La primera vez que se conectan los módulos Llave y Apertura, el
sistema operativo genera un cuadro de dialogo que informa al usuario
que los controladores o drivers necesarios para el correcto
funcionamiento de dichos módulos no se encuentran, el sistema
operativo informa de este problema ya que los drivers no son incluidos
o no vienen en la lista de controladores por defecto incluidos en la
instalación del sistema operativo, en este caso el usuario debe
suministrar el archivo de controlador para cada uno de los dispositivos,
siendo estos, para el Módulo Apertura el controlador del integrado
FT232 y el controlador del puerto COM USB. Para el caso del Módulo
70
llave, es necesario proveer al sistema operativo con el controlador
correspondiente al microcontrolador PIC 18F4550.
•
Cabe mencionar que la Comunicación entre los módulos es
fundamental para el funcionamiento del sistema, es por eso que se
recomienda que antes de conectar los dispositivos para su uso, se
ejecute el programa principal, de esta forma el sistema reconocerá los
módulos y funcionara correctamente.
71
BIBLIOGRAFÍA
DIERKS, ALLEN C. The TLS Protocol Version 1.0, Request For Comments
2246, Enero 1999.
FREIER Alan, KOCHER. The SSL Protocol Version 3.0, Internet Draft, 1996.
GÓMEZ A., GARCÍA J. y otros. Experiencia piloto de certificación en la
Universidad de Murcia. Noviembre 1998.
GÓMEZ A., GARCÍA J. y otros. Providing Security to University Environment
Communications. Junio 1999
MICROSOFT Corp. Winlogon User Interface. Microsoft Network Developer
Library.
PC/SC Workgroup, Interoperability Specification for ICCs and Personal
Computer System, Diciembre 1997.
WAHL M. HOWES T. KILLE S. Lightweight Directory Access Protocol (v 3),
Request for Comments 2251, 1997.
Ward. M, (2006, Abril). ! Cuidado con la memoria USB!
72
WEBLIOGRAFÍA
http://www.criptored.upm.es/guiateoria/gt_m142b1.htm
[13 de Septiembre de 2007 16:45]
http://www.avatarharden.com/controldeacceso
[19 de Septiembre de 2007 18:40]
http://www.biztechmagazine.com/article.asp?item_id=76
[19 de Septiembre de 2007 20:15]
http://www.apple.com/pr/library/2007/04/09ipod.html
[4 de Marzo de 2008 15:45]
http://www.everythingusb.com/revolution.html [15 de Marzo de 2008 11:03]
http://news.bbc.co.uk/hi/spanish/science/newsid_4951000/4951
[14 de Agosto de 2008 16:20]
http://www.darkreading.com/document.asp?doc_id=95556
[9 de Octubre de 2008 09:26]
http://www.zator.com/Hardware/H6_4.htm [11 de Octubre de 2008 19:42]
http://www.zator.com/Hardware/H2_5_3.htm [19 de Octubre de 2008 19:35]
http://www.slideshare.net/manlopez/aspectos-formales-de-la-presentacinoral-y-escrita-de-trabajos [5 de Noviembre de 2008 11:52]
http://host.nigde.edu.tr/muzam/PIC16F648A.pdf
[16 de Marzo de 2009 11:28]
http://www.create.ucsb.edu/~dano/CUI/PIC18F4550datasheet.pdf
[16 de Abril de 2009 11:55]
http://www.ftdichip.com/Documents/DataSheets/ds232b18.pdf
[16 de Abril de 2009 14:36]
http://www.datasheetcatalog.com/datasheets_pdf/L/2/9/8/L298.shtml
[18 de Abril de 2009 19:25]
73
GLOSARIO
AUTENTICACIÓN: en la seguridad electrónica, la autenticación es el
proceso de intento de verificar la identidad digital de un usuario. Es un modo
de asegurar que los usuarios son quién ellos dicen que ellos son y que la
persona que intenta realizar funciones en un sistema es de hecho la que
tiene la autorización para hacerlo así.
AUTORIZACIÓN: proceso por el cual un sistema electrónico o una red de
computadores autoriza al usuario identificado a acceder a determinados
recursos o lugares.
CERTIFICADO DIGITAL: un documento digital mediante el cual un tercero
confiable (una autoridad de certificación) garantiza la vinculación entre la
identidad de un sujeto o entidad y su clave.
CONFIDENCIALIDAD: es la propiedad de un documento, dato, contraseña o
mensaje que únicamente está autorizado para ser leído o entendido por
algunas personas o entidades. Se dice que un dato es confidencial si éste
sólo está autorizado a ser leído o entendido por un destinatario designado.
CONTROL DE ACCESO: el control que se ejerce del ingreso de las
personas a un recinto o a toda una edificación.
DEVICE: dispositivo periférico que se conecta al host para recibir y transmitir
datos hacia el host.
DRIVER: un controlador de dispositivo, llamado normalmente controlador (en
inglés, driver) es un programa informático que permite al sistema operativo
interactuar con un periférico, haciendo una abstracción del hardware y
proporcionando una interfaz -posiblemente estandarizada- para usarlo. Se
puede esquematizar como un manual de instrucciones que le indica cómo
debe controlar y comunicarse con un dispositivo en particular. Por tanto, es
una pieza esencial, sin la cual no se podría usar el hardware.
74
FIRMWARE: es un bloque de instrucciones de programa para propósitos
específicos, grabado en una memoria de tipo no volátil (ROM, EEPROM,
flash,...), que establece la lógica de más bajo nivel que controla los circuitos
electrónicos de un dispositivo de cualquier tipo. Al estar integrado en la
electrónica del dispositivo es en parte hardware, pero también es software,
ya que proporciona lógica y se dispone en algún tipo de lenguaje de
programación. Funcionalmente, el firmware es el intermediario (interfaz) entre
las órdenes externas que recibe el dispositivo y su electrónica, ya que es el
encargado de controlar a ésta última para ejecutar correctamente dichas
órdenes externas.
HARDWARE: corresponde a todas las partes físicas y tangibles de una
computadora, o a componentes eléctricos, electrónicos, electromecánicos y
mecánicos; cables, gabinetes o cajas, periféricos de todo tipo y cualquier
otro elemento físico involucrado; contrariamente al soporte lógico e intangible
que es llamado software.
HOST: dispositivo central capaz de controlar la transmisión y conexión de
todos los dispositivos USB conectados.
Microcontrolador: es un circuito integrado o chip que incluye en su interior
las tres unidades funcionales de una computadora: CPU, Memoria y
Unidades de entrada y salida.
PESTILLO ELÉCTRICO: es un dispositivo que permite mediante voltaje
bipolar controlar un motor que a su vez mueve un seguro permitiendo abrir
una puerta, comúnmente se usa en automóviles y en cajas de seguridad.
PROTOCOLO: es el conjunto de reglas que especifican el intercambio de
datos u órdenes durante la comunicación entre las entidades que forman
parte de un sistema electrónico.
SOFTWARE: se refiere al equipamiento lógico o soporte lógico de un
computador digital, y comprende el conjunto de los componentes lógicos
necesarios para hacer posible la realización de una tarea específica, en
75
contraposición a los componentes físicos del sistema (hardware). Tales
componentes lógicos incluyen, entre otros, aplicaciones informáticas tales
como procesador de textos, que permite al usuario realizar todas las tareas
concernientes a edición de textos; software de sistema, tal como un sistema
operativo, el que, básicamente, permite al resto de los programas funcionar
adecuadamente, facilitando la interacción con los componentes físicos y el
resto de las aplicaciones, también provee una interfaz ante el usuario.
STAND ALONE: independiente. Separado de un conjunto. Autónomo.
Caracteriza a un terminal o un puesto de trabajo que está conectado
directamente al ordenador o a un concentrador; es decir, que tiene una sola
conexión a través de una línea externa. (Stand-alone).
STAND BY: se denomina Stand-by al consumo en espera de diferentes
aparatos electrónicos, tales como televisión, reproductores de audio o vídeo,
aire acondicionado, algunos modelos de frigoríficos, algunas vitrocerámicas,
alimentadores/cargadores, PC, etc. En Stand by, el aparato se encuentra
conectado, a la espera de recibir órdenes, por lo que consume energía
eléctrica. Se calcula que casi un 15% del consumo de una vivienda se
produce por aparatos electrónicos conectados en Stand by. Se recomienda
que para ahorrar energía, averías, dinero y evitar contaminación se
desconecten los aparatos electrónicos de manera que cuando no se vayan a
utilizar queden totalmente desconectados de la red eléctrica.
USB: Universal Serial Bus.
76
ANEXOS
77
ANEXO A CÓDIGO FUENTE DEL MICROCONTROLADOR PIC18F4550
MÓDULO LLAVE
#include <18F4550.h>
#fuses
HSPLL,
NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGE
N
#use delay(clock=48000000)
#define USB_HID_DEVICE
FALSE
//deshabilitamos el uso de las
directivas HID
#define USB_EP1_TX_ENABLE
USB_ENABLE_BULK
//turn on
EP1(EndPoint1) for IN bulk/interrupt transfers
#define USB_EP1_RX_ENABLE
USB_ENABLE_BULK
//turn on
EP1(EndPoint1) for OUT bulk/interrupt transfers
#define USB_EP1_TX_SIZE 1
#define USB_EP1_RX_SIZE 3
//
100k
//
VBUS-----+----/\/\/\/\/\----- (I/O PIN ON PIC)
//
|
//
+----/\/\/\/\/\-----GND
//
100k
//
(where VBUS is pin1 of the USB connector)
//
/////////////////////////////////////////////////////////////////////////////
//#define USB_CON_SENSE_PIN PIN_B2 // sense pin
#include <pic18_usb.h>
//Microchip PIC18Fxx5x Hardware layer for CCS's
PIC USB driver
#include <PicUSB.h>
//ConFiguración del USB y los descriptores para
este dispositivo
#include <usb.c>
//handles usb setup tokens and get descriptor reports
/////////////////////////////////////////////////////////////////////////////
//
// Al conectar el PicUSB al PC encendemos el Led Rojo hasta que el
dispositivo
// Halla sido conFigurado por el PC, en ese momento encenderemos el Led
Verde.
// Esperaremos hasta que se reciba un paquete proveniente del PC.
Comprobaremos
78
// El primer byte del paquete recibido para comprobar si queremos entrar en
el
// modo Suma, donde se realizará una suma de dos operandos, que
corresponderán
// con los dos bytes restantes del paquete recibido; una vez realizada la suma
// enviaremos el paquete con el resultado de vuelta al PC. Si entramos en el
// modo Led comprobaremos el segundo byte del paquete recibido para
comprobar
// si deberemos apagar los leds, encender el verde o el rojo.
//
/////////////////////////////////////////////////////////////////////////////
#define LEDV PIN_E0
#define LEDA PIN_E1
#define LEDR PIN_E2
#define LED_ON output_high
#define LED_OFF output_low
#define modo
recibe[0]
#define param1 recibe[1]
#define param2 recibe[2]
#define resultado envia[0]
void main(void) {
int8 recibe[3];
int8 envia[1];
//declaramos variables
LED_OFF(LEDV);
LED_OFF(LEDA); //encendemos led rojo
LED_ON(LEDR);
usb_init();
//inicializamos el USB
usb_task();
//habilita periferico usb e interrupciones
usb_wait_for_enumeration();
//esperamos hasta que el PicUSB sea
conFigurado por el host
LED_OFF(LEDR);
LED_OFF(LEDA);
LED_ON(LEDV);
//encendemos led verde
while (TRUE)
{
79
if(usb_enumerated())
//si el PicUSB está conFigurado
{
// usb_put_packet(1, envia, 1, USB_DTS_TOGGLE); //enviamos el
paquete de tamaño 1byte del EP1 al PC
if (usb_kbhit(1))
//si el endpoint de salida contiene datos del host
{
usb_get_packet(1, recibe, 3); //cojemos el paquete de tamaño 3bytes
del EP1 y almacenamos en recibe
if (modo == 0) // Modo_Suma
{
resultado = param1 + param2; //hacemos la suma
usb_put_packet(1, envia, 1, USB_DTS_TOGGLE); //enviamos el
paquete de tamaño 1byte del EP1 al PC
}
if (modo == 1) // Modo_Led
{
if
(param1
==
0)
{LED_OFF(LEDV);
LED_OFF(LEDA);} //apagamos los leds
if
(param1
==
1)
{LED_ON(LEDV);
LED_OFF(LEDA);} //encendemos led verde
if
(param1
==
2)
{LED_OFF(LEDV);
LED_OFF(LEDA);} //encendemos led rojo
if
(param1
==
3)
{LED_OFF(LEDV);
LED_ON(LEDA);}
}
}
}
}
}
80
LED_OFF(LEDR);
LED_OFF(LEDR);
LED_ON(LEDR);
LED_OFF(LEDR);
ANEXO B CÓDIGO FUENTE DEL MICROCONTROLADOR PIC16F628A
MÓDULO MOTOR
*
0000:
0001:
0002:
0003:
0004:
0005:
0006:
0007:
0008:
0009:
000A:
000B:
000C:
000D:
000E:
000F:
0010:
0011:
0012:
0013:
0014:
0015:
0016:
0017:
0018:
0019:
001A:
001B:
001C:
001D:
001E:
001F:
0020:
0021:
0022:
0023:
0024:
0025:
MOVLW 00
MOVWF 0A
GOTO 12A
NOP
MOVWF 7F
SWAPF 03,W
CLRF 03
MOVWF 21
MOVF 7F,W
MOVWF 20
MOVF 0A,W
MOVWF 28
CLRF 0A
SWAPF 20,F
MOVF 04,W
MOVWF 22
MOVF 77,W
MOVWF 23
MOVF 78,W
MOVWF 24
MOVF 79,W
MOVWF 25
MOVF 7A,W
MOVWF 26
MOVF 7B,W
MOVWF 27
BCF 03.7
BCF 03.5
MOVLW 8C
MOVWF 04
BTFSS 00.5
GOTO 022
BTFSC 0C.5
GOTO 09B
MOVF 22,W
MOVWF 04
MOVF 23,W
MOVWF 77
81
0026: MOVF 24,W
0027: MOVWF 78
0028: MOVF 25,W
0029: MOVWF 79
002A: MOVF 26,W
002B: MOVWF 7A
002C: MOVF 27,W
002D: MOVWF 7B
002E: MOVF 28,W
002F: MOVWF 0A
0030: SWAPF 21,W
0031: MOVWF 03
0032: SWAPF 7F,F
0033: SWAPF 7F,W
0034: RETFIE
.................... #include <16F628A.h>
.................... #device PIC16F628A
.................... #list
....................
....................
.................... #FUSES NOWDT
.................... #FUSES INTRC
.................... #FUSES NOPUT
.................... #FUSES NOPROTECT
.................... #FUSES NOBROWNOUT
.................... #FUSES MCLR
.................... #FUSES NOLVP
.................... #FUSES NOCPD
....................
.................... #use delay(clock=4000000)
0086: MOVLW 2E
0087: MOVWF 04
0088: BCF 03.7
0089: MOVF 00,W
008A: BTFSC 03.2
008B: GOTO 09A
008C: MOVLW 01
008D: MOVWF 78
008E: CLRF 77
008F: DECFSZ 77,F
0090: GOTO 08F
0091: DECFSZ 78,F
0092: GOTO 08E
0093: MOVLW 4A
82
0094: MOVWF 77
0095: DECFSZ 77,F
0096: GOTO 095
0097: GOTO 098
0098: DECFSZ 00,F
0099: GOTO 08C
009A: RETLW 00
....................
rs232(baud=9600,parity=N,xmit=PIN_B2,rcv=PIN_B1,bits=8)
.................... //#USE STANDARD_IO (B)
....................
.................... #define RIGHT PIN_B5
.................... #define LEFT PIN_B4
.................... #define ENABLE PIN_B3
.................... #define SENSOR PIN_B0
....................
.................... int1 openFlag, closeFlag;
.................... int dRead;
....................
.................... //*******************************************************
.................... //*******************************************************
....................
.................... #int_rda
.................... void RxInt(void)
.................... {
.................... disable_interrupts(int_rda);
009B: BSF 03.5
009C: BCF 0C.5
.................... dRead = getc();
009D: BCF 03.5
009E: BTFSS 0C.5
009F: GOTO 09E
00A0: MOVF 1A,W
00A1: MOVWF 2B
.................... delay_ms(100);
00A2: MOVLW 64
00A3: MOVWF 2E
00A4: CALL 086
.................... if(dRead == '1')
00A5: MOVF 2B,W
00A6: SUBLW 31
00A7: BTFSS 03.2
00A8: GOTO 0B0
.................... {
83
#use
....................
openFlag = true;
00A9: BSF 2A.0
....................
closeFlag = false;
00AA: BCF 2A.1
....................
printf("1");
00AB: MOVLW 31
00AC: BTFSS 0C.4
00AD: GOTO 0AC
00AE: MOVWF 19
.................... }//
.................... else if(dRead == '2')
00AF: GOTO 0C6
00B0: MOVF 2B,W
00B1: SUBLW 32
00B2: BTFSS 03.2
00B3: GOTO 0BB
.................... {
....................
openFlag = false;
00B4: BCF 2A.0
....................
closeFlag = true;
00B5: BSF 2A.1
....................
printf("2");
00B6: MOVLW 32
00B7: BTFSS 0C.4
00B8: GOTO 0B7
00B9: MOVWF 19
.................... }//
.................... else
00BA: GOTO 0C6
.................... {
....................
openFlag = false;
00BB: BCF 2A.0
....................
closeFlag = false;
00BC: BCF 2A.1
....................
putc(dRead);
00BD: MOVF 2B,W
00BE: BTFSS 0C.4
00BF: GOTO 0BE
00C0: MOVWF 19
....................
output_toggle(PIN_A1);
00C1: BSF 03.5
00C2: BCF 05.1
00C3: MOVLW 02
00C4: BCF 03.5
84
00C5: XORWF 05,F
.................... }//
....................
enable_interrupts(int_rda);
00C6: BSF 03.5
00C7: BSF 0C.5
.................... }//
....................
00C8: BCF 03.5
00C9: BCF 0C.5
00CA: BCF 0A.3
00CB: GOTO 022
.................... void openMotor(void)
.................... {
....................
.................... output_high(LEFT);
*
00EC: BSF 03.5
00ED: BCF 06.4
00EE: BCF 03.5
00EF: BSF 06.4
.................... output_low(RIGHT);
00F0: BSF 03.5
00F1: BCF 06.5
00F2: BCF 03.5
00F3: BCF 06.5
.................... output_high(ENABLE);
00F4: BSF 03.5
00F5: BCF 06.3
00F6: BCF 03.5
00F7: BSF 06.3
.................... delay_ms(500);
00F8: MOVLW 02
00F9: MOVWF 2C
00FA: CLRF 29
00FB: BTFSC 0B.7
00FC: BSF 29.7
00FD: BCF 0B.7
00FE: MOVLW FA
00FF: MOVWF 2E
0100: CALL 086
0101: BTFSC 29.7
0102: BSF 0B.7
0103: DECFSZ 2C,F
0104: GOTO 0FA
85
.................... output_low(ENABLE);
0105: BSF 03.5
0106: BCF 06.3
0107: BCF 03.5
0108: BCF 06.3
....................
.................... openFlag = false;
0109: BCF 2A.0
....................
.................... }//
010A: GOTO 158 (RETURN)
....................
.................... void closeMotor(void)
.................... {
....................
.................... output_high(RIGHT);
010B: BSF 03.5
010C: BCF 06.5
010D: BCF 03.5
010E: BSF 06.5
.................... output_low(LEFT);
010F: BSF 03.5
0110: BCF 06.4
0111: BCF 03.5
0112: BCF 06.4
.................... output_high(ENABLE);
0113: BSF 03.5
0114: BCF 06.3
0115: BCF 03.5
0116: BSF 06.3
.................... delay_ms(500);
0117: MOVLW 02
0118: MOVWF 2C
0119: CLRF 29
011A: BTFSC 0B.7
011B: BSF 29.7
011C: BCF 0B.7
011D: MOVLW FA
011E: MOVWF 2E
011F: CALL 086
0120: BTFSC 29.7
0121: BSF 0B.7
0122: DECFSZ 2C,F
0123: GOTO 119
86
.................... output_low(ENABLE);
0124: BSF 03.5
0125: BCF 06.3
0126: BCF 03.5
0127: BCF 06.3
....................
.................... closeFlag = false;
0128: BCF 2A.1
....................
.................... }//
0129: GOTO 169 (RETURN)
....................
.................... void pic_config(void)
.................... {
....................
.................... setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
*
012A: CLRF 04
012B: BCF 03.7
012C: MOVLW 1F
012D: ANDWF 03,F
012E: BSF 03.5
012F: BSF 0E.3
0130: MOVLW 19
0131: MOVWF 19
0132: MOVLW A6
0133: MOVWF 18
0134: MOVLW 90
0135: BCF 03.5
0136: MOVWF 18
0137: MOVLW 07
0138: MOVWF 1F
....................
.................... pic_config();
0139: GOTO 0CC
.................... openFlag = false;
013A: BCF 2A.0
.................... closeFlag = false;
013B: BCF 2A.1
....................
.................... output_low(PIN_B3);
013C: BSF 03.5
013D: BCF 06.3
013E: BCF 03.5
87
013F: BCF 06.3
.................... output_low(PIN_B4);
0140: BSF 03.5
0141: BCF 06.4
0142: BCF 03.5
0143: BCF 06.4
.................... output_low(PIN_B5);
0144: BSF 03.5
0145: BCF 06.5
0146: BCF 03.5
0147: BCF 06.5
.................... printf("inicializado");
0148: CLRF 2C
0149: MOVF 2C,W
014A: CALL 035
014B: INCF 2C,F
014C: MOVWF 77
014D: MOVF 77,W
014E: BTFSS 0C.4
014F: GOTO 14E
0150: MOVWF 19
0151: MOVLW 0C
0152: SUBWF 2C,W
0153: BTFSS 03.2
0154: GOTO 149
....................
.................... for(;;)
.................... {
....................
if(openFLag)
0155: BTFSS 2A.0
0156: GOTO 166
....................
{
....................
....................
openMotor();
0157: GOTO 0EC
....................
printf("girando hacia la izquierda\n\r");
0158: CLRF 2C
0159: MOVF 2C,W
015A: CALL 046
015B: INCF 2C,F
015C: MOVWF 77
015D: MOVF 77,W
015E: BTFSS 0C.4
015F: GOTO 15E
88
0160: MOVWF 19
0161: MOVLW 1C
0162: SUBWF 2C,W
0163: BTFSS 03.2
0164: GOTO 159
....................
....................
}
....................
else if(closeFlag)
0165: GOTO 177
0166: BTFSS 2A.1
0167: GOTO 177
....................
{
....................
....................
closeMotor();
0168: GOTO 10B
....................
printf("girando hacia la derecha\n\r");
0169: CLRF 2C
016A: MOVF 2C,W
016B: CALL 067
016C: INCF 2C,F
016D: MOVWF 77
016E: MOVF 77,W
016F: BTFSS 0C.4
0170: GOTO 16F
0171: MOVWF 19
0172: MOVLW 1A
0173: SUBWF 2C,W
0174: BTFSS 03.2
0175: GOTO 16A
....................
....................
}
....................
else
0176: GOTO 177
....................
{
....................
....................
}
....................
....................
/*output_toggle(PIN_B3);
....................
delay_ms(1000);*/
....................
.................... }
0177: GOTO 155
....................
89
ANEXO C CÓDIGO FUENTE PROGRAMA MÓDULO SOFTWARE
//--------------------------------------------------------------------------#include <vcl.h>
#pragma hdrstop
#include "Unit1.h"
#include "stdio.h"
#include "stdlib.h"
#include "COMM.h"
#include "Unit2.h"
//--------------------------------------------------------------------------#pragma package(smart_init)
#pragma resource "*.dfm"
TForm1 *Form1;
String vid_pid_norm = "vid_04d8&pid_0011";
String out_pipe = "\\MCHP_EP1";
String in_pipe = "\\MCHP_EP1";
//--------------------------------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
libdinam = LoadLibrary("mpusbapi.dll");//LoadLibrary("NumToTxt.dll");
if (libdinam == NULL){
ShowMessage("error de carga dll");
}
else {
usbclose = (MPUSBClose)GetProcAddress(libdinam,"_MPUSBClose");
usbreadint
=
(MPUSBReadInt)GetProcAddress(libdinam,"_MPUSBReadInt");
usbwrite = (MPUSBWrite)GetProcAddress(libdinam,"_MPUSBWrite");
usbread = (MPUSBRead)GetProcAddress(libdinam,"_MPUSBRead");
usbopen = (MPUSBOpen)GetProcAddress(libdinam,"_MPUSBOpen");
usbgetdevice
=
(MPUSBGetDeviceCount)GetProcAddress(libdinam,"_MPUSBGetDeviceCou
nt");
usbversion
=
(MPUSBGetDLLVersion)GetProcAddress(libdinam,"_MPUSBGetDLLVersion"
);
if (usbclose == NULL){ShowMessage("error al cargar la funcion usbclose");}
90
if (usbreadint == NULL){ShowMessage("error al cargar la funcion
usbreadint");}
if (usbwrite == NULL){ShowMessage("error al cargar la función usbwrite");}
if (usbread == NULL){ShowMessage("error al cargar la funcion usbread");}
if (usbopen == NULL){ShowMessage("error al cargar la funcion usbopen");}
if (usbgetdevice == NULL){ShowMessage("error al cargar la funcion
usbgetdevice");}
if (usbversion == NULL){ShowMessage("error al cargar la funcion
usbversion");}
}
}
//-----------------------------------------------------------------------------void __fastcall TForm1::Button1Click(TObject *Sender)
{
sumapic(Edit1->Text.ToInt(),Edit2->Text.ToInt());
Edit3->Text = (String)resultadopic();
Memo1->Lines->LoadFromFile("USERS.TXT");
//int id;
bool encontrado=false;
for(int i=0;i<Memo1->Lines->Count;i++)
{
if (Edit3->Text.ToInt() == Memo1->Lines->Strings[i].SubString(1,2))
//if resultadopic() == id de usuario registrada en Archivo.txt
{
Label6->Caption = "OK:::OK:::OK";
//muestra confirmación
Label7->Caption = Memo1->Lines->Strings[i].SubString(4,40);
//muestra el nombre del usuario que introdujo la llave.
if(motorFuera == true)
{
encontrado = true;
}
else
{
motorFuera = true;
motorDentro = false;
encontrado = true;
motorPort.OpenCommPort();
motorPort.WriteString("1");
motorPort.CloseCommPort();
91
}
}
}
if (encontrado==false)
{
Label6->Caption = "No Registrado";
Label7->Caption = "--";
if(motorDentro == true)
{
}
else
{
motorDentro = true;
motorFuera = false;
motorPort.OpenCommPort();
motorPort.WriteString("2");
motorPort.CloseCommPort();
}
}
encontrado = false;
}
//-----------------------------------------------------------------------------void openpipes(){
DWORD selection = 0;
myOutPipe = usbopen(selection, vid_pid_norm, out_pipe, 0, 0);
myInPipe = usbopen(selection, vid_pid_norm, in_pipe, 1, 0);
}
//-----------------------------------------------------------------------------void closepipes(){
usbclose(myOutPipe);
usbclose(myInPipe);
}
//-----------------------------------------------------------------------------void sendpacket(byte* SendData, DWORD SendLength){
int SendDelay = 1000;
DWORD SentDataLength;
openpipes();
usbwrite(myOutPipe,
SendDelay);
(void*)SendData,
92
SendLength,
&SentDataLength,
closepipes();
}
//-----------------------------------------------------------------------------void recivepacket(byte* ReceiveData, DWORD *ReceiveLength){
int ReceiveDelay=1000;
DWORD ExpectedReceiveLength = *ReceiveLength;
openpipes();
usbread(myInPipe,
(void*)ReceiveData,
ExpectedReceiveLength,
ReceiveLength, ReceiveDelay);
closepipes();
}
//-----------------------------------------------------------------------------void sumapic(int sumando1, int sumando2){
byte* send_buf = new byte[3];
send_buf[0] = 0x00;
// Código de Entrada a Modo_Suma
send_buf[1] = (byte)sumando1;
send_buf[2] = (byte)sumando2;
sendpacket(send_buf, 3);
}
//-----------------------------------------------------------------------------int resultadopic(){
int result = 0;
byte* receive_buf = new byte[1];
DWORD RecvLength = 1;
recivepacket(receive_buf, &RecvLength);
result = receive_buf[0];
return result;
}
//-----------------------------------------------------------------------------void ledpic(byte led){
byte* send_buf = new byte[2];
send_buf[0] = 0x01;
// Código de Entrada a Modo_Led
send_buf[1] = (byte)led;
sendpacket(send_buf, 2);
}
//-----------------------------------------------------------------------------void __fastcall TForm1::Button2Click(TObject *Sender)
93
{
ledpic(0x00); //led off
}
//--------------------------------------------------------------------------void __fastcall TForm1::Button3Click(TObject *Sender)
{
ledpic (0x02); // led rojo
}
//--------------------------------------------------------------------------void __fastcall TForm1::Button4Click(TObject *Sender)
{
ledpic (0x01); //led verde
}
//--------------------------------------------------------------------------void __fastcall TForm1::Button5Click(TObject *Sender)
{
ledpic(0x03); //led off
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Button6Click(TObject *Sender)
{
/* MODE
r
Open for reading only.
w
Create for writing. If a file by that name already exists, it will be
overwritten.
a
Append; open for writing at end-of-file or create for writing if the file
does not exist.
r+
Open an existing file for update (reading and writing).
w+
Create a new file for update (reading and writing). If a file by that name
already exists, it will be overwritten.
a+
Open for append; open (or create if the file does not exist) for update at
the end of the file.
*/
FILE *stream;
stream = fopen("USERS.TXT", "a+");
fprintf(stream, "\n");
fprintf(stream, Edit6->Text.c_str());
fprintf(stream, " ");
fprintf(stream, Edit5->Text.c_str());
fprintf(stream, " ");
fprintf(stream, Edit4->Text.c_str());
94
fclose(stream);
}
void __fastcall TForm1::Button7Click(TObject *Sender)
{
// if(start==1)return;
int Ports = motorPort.FindAvPorts();
Form2->ComboBox1->Clear();
Form2->ComboBox1->Text = "Seleccione Puerto";
for (int i=0 ; i<Ports ;i++)
{
Form2->ComboBox1->Items->Add( motorPort.m_vPorts[i].data() );
}
Form2->Visible=true;
Form2->Show();
}
//--------------------------------------------------------------------------void __fastcall TForm1::Timer1Timer(TObject *Sender)
{
Button1->Click();
}
//---------------------------------------------------------------------------
95