diseno e implementacion de un sistema de control de...
TRANSCRIPT
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.
I
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
II
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
III
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
IV
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
V
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
VI
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
VII
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.
1
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.
2
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.
Pt
A
DM
u
(
a
p
g
F
F
Proyectos R
Proyecto: tarjetas inte
Autor: T.
Hidalgo- J.
Detalles dMurcia, ha
utilización d
(ALAs), co
autenticació
proyectos d
gestión de
Figura 1. Es
Fuente: Estruc
Relacionad
UMGina:
eligentes de
Jiménez- A
Gil- O. Cán
del proyeca desarrolla
de tarjetas
omplementa
ón, integrid
de la misma
reservas tr
structura de
ctura de proye
dos:
Sistema d
e la Univers
A Gómez
novas- S. N
cto: El Ser
ado un sis
inteligentes
ando así
dad, confide
a Universid
ransparente
proyecto UM
cto UMGina G
3
de control
sidad de M
Skarmeta-
Navarro y M
rvicio de I
stema de c
s, para sus
otros elem
encialidad
dad dotando
e al usuario
MGina.
rupo de seguri
de acceso
urcia.
- J. García
M. Serrano
nformática
control de
s equipos e
mentos de
y no repud
o de un sist
o y fácil de a
dad y criptogra
o en aulas
a Ros- G.
de la Un
acceso b
en aulas de
seguridad
dio abordad
tema globa
administrar
afía-Universida
s basado e
Martínez-
niversidad d
asado en
e libre acce
d como so
dos por otr
al de contro
r.
ad de Murcia
en
J.
de
la
so
on:
os
l y
P
A
Dp
m
p
t
m
d
l
F
F
Proyecto:
Autor: CDV
Detalle depara sumin
manejar ha
provee con
técnicas de
mantener c
de comuni
lectores, al
Figura 2. CD
Fuente: Estac
Sistema de
VI.
el proyectonistrar contr
asta 128 lec
nexión con
e autentica
comunicació
carse con
macenar co
DVI UGM.
ción Central CD
e control de
o: Ugm es
rol, en el m
ctores (pue
los disposit
ción, como
ón continua
un PC, c
ontraseñas
DVI UGM. [En L
4
e acceso ce
un Produc
momento de
rtas), de fo
tivos en los
o biometría
a con los le
con el obje
s y monitore
Línea] Product
entralizado
cto que em
e acceder
rma centra
s cuales se
, teclados,
ectores, la u
etivo de lle
ear en gene
os de control d
CDVI UGM
mplea elect
a un recint
lizada, la u
pueden us
RFID, etc
unidad cen
evar un reg
eral el uso d
de acceso en lí
M.
rónica digit
to, capaz d
nidad centr
sar diferent
. Además d
tral es cap
gistro de l
del sistema
ínea
tal
de
ral
es
de
az
os
a.
5
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.
6
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?
7
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.
8
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.
9
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.
10
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.
11
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
12
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.
L
c
p
s
c
d
c
e
e
F
F
Los conce
conectar co
puede con
salidas, y p
cada uno d
de alimenta
Es importa
comunicac
encarga de
esclavo que
Figura 3. Int
Fuente: USB
entradores
on el sistem
ectar hasta
proporciona
de ellos, ya
ación (5 V.
ante consid
iones por p
e controlar
e se puede
terfaz host –
Complete: Ev
("Hubs") s
ma anfitrión
a 7 dispos
ar 500 mA
que el cab
DC ± 0.25
derar el p
protocolo U
la conexió
e considera
– device USB
verything You
13
son el cent
n, con otro
itivos, aunq
de energía
ble de cone
V).
proceso fís
USB. El ho
ón y actúa
r como un
B
u Need to De
tro de una
hub o con
que lo nor
a de alimen
exión tiene
sico y el
ost USB, o
como un m
USB device
velop USB Pe
estrella, y
una función
rmal es qu
ntación (ha
hilos de se
proceso ló
dispositivo
maestro co
e, o periféri
eripherals, Th
y sirven pa
n. Cada hu
e sean de
asta 2.5 W)
eñal (datos)
ógico de l
o anfitrión
ontrolando u
ico USB.
hird Edition
ara
ub
4
) a
) y
as
se
un
n
t
c
c
q
d
s
l
2d
c
F
F
L
c
El host utili
números d
transferenc
configuraci
comunica c
que tiene e
driver auto
sistema op
lista de disp
2.1.2. Funcde codifica
cero).
Figura 4. Co
Fuente: USB
Los “ceros”
Para evitar
consecutivo
iza un softw
de dispos
cia que se
ón del disp
con el softw
el dispositiv
omáticamen
erativo Win
positivos, e
cionamiención NRZ
odificación N
Complete: Ev
” provocan
r periodos
os
ware que s
itivo, así
puede usa
positivo y d
ware de si
vo USB con
nte, en este
ndows que
esta lista se
to. El bus
I ("Non Re
NRZI
verything You
un cambio
largos sin
14
se encarga
como tam
ar, luego de
el host, el
stema USB
nectado al
e caso el
selecciona
e llama TPL
serie USB
turn to Zer
u Need to De
de nivel, L
cambios s
de crear la
mbién de
e establece
software de
B, comunic
sistema, lu
software d
a el driver a
L (Targeted
es síncron
ro Inverted"
velop USB Pe
os “unos” n
se introduce
as conexion
designar
er estos pa
e la capa d
cándole el t
uego este s
e sistema
automáticam
Peripheral
no, y utiliza
" invertido
eripherals, Th
no provocan
e un cero
nes y asign
el tipo d
arámetros d
de función
tipo de cla
selecciona
se refiere
mente de un
List).
a el algoritm
sin retorno
hird Edition
n cambio.
cada 6 un
nar
de
de
se
se
el
al
na
mo
o a
os
15
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
16
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
17
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.
18
• 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.
S
c
T
F T
F
S
p
s
Se utilizan
cada secció
Tabla 1. Dis
Fuente: USB C
Tabla 2. Dis
Fuente: USB
Se usan d
pueden ins
sujetarse.
diámetros
ón se autor
stancias y ca
Complete: Ev
sposición de
Complete: Ev
dos tipos d
sertarse en
Los de tip
estándar p
riza una lon
alibres de ca
verything You
pines y colo
verything You
de conecto
n una pos
o A utilizan
19
para los hil
ngitud máxi
able USB
Need to Dev
ores de iden
u Need to De
res, A y B
sición) y u
n la hembra
os de alime
ma del seg
velop USB Pe
tificación en
velop USB Pe
B. Ambos
tilizan siste
a en el sist
entación de
gmento.
eripherals, Th
n cables USB
eripherals, Th
s son polar
emas de p
tema anfitr
el bus. Pa
ird Edition
B
hird Edition
rizados (so
presión pa
rión, y suele
ara
olo
ara
en
u
r
L
e
g
d
d
F
F
F
usarse en
ratones y te
Los de tipo
en sistema
general pod
del host (P
del lado de
Figura 5. Co
Fuente: USB
Figura 6. C
Fuente: USB
dispositivo
eclados).
o B utilizan
as móviles
demos afirm
PC) o de lo
e los perifér
onector USB
Complete: Ev
Conector US
Complete: Ev
s en los qu
la hembra
(por ejem
mar que la
os concentr
icos.
B tipo A.
verything You
SB tipo B.
verything You
20
ue la conex
en el dispo
plo, cámar
hembra de
radores (Hu
u Need to De
u Need to De
xión es pe
ositivo USB
ras fotográf
e los conec
ubs), mient
velop USB Pe
velop USB Pe
rmanente (
B (función),
ficas o alta
ctores A est
tras las de
eripherals, Th
eripherals, Th
(por ejemp
, y se utiliza
avoces). E
tán en el lad
tipo B está
hird Edition
hird Edition
lo,
an
En
do
án
21
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.
22
• 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.
23
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
24
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
25
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 los dispositivos
pertenecientes a dicha Clase o Subclase deben soportar.
26
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.
27
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.
28
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).
29
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.
30
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.
31
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.
32
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:
33
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
34
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.
4
4y
F
4.1. MÓDU
4.1.1. Módy posterior
Figura 8. Dia
ULOS.
ulo Llave. desarrollo
agrama de f
Este apar
que repres
flujo del mód
35
rtado explic
enta la “llav
dulo llave
ca en detal
ve”.
le el proceso de diseñ
ño
36
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.
37
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
b
a
e
A
c
F
F
buenas po
aprovechar
el mercado
Al final, el
cuales se li
• Men
• Arqu
• Pos
dise
• Num
• No e
se p
Figura 9. Dia
Fuente: Mic
osibilidades
rían al máx
o nacional s
PIC18 of
istan a cont
nor costo.
uitectura 8
ibilidad de
eño del prog
mero de pin
está limitad
pueden usa
agrama de p
rochip inc., w
s a un p
ximo, adem
sin mayor é
frece varias
tinuación:
bits acorde
programac
grama.
nes suficien
do a un mo
ar los progra
pines del mic
www.microc
38
precio acc
ás de esto
xito.
s ventajas
e a lo apren
ción en len
te para los
odelo espec
amadores g
crocontrolad
chip.com
cesible, au
se intento
sobre los
ndido en la
nguaje C,
requerimie
cífico de pr
genéricos m
dor tipo PDIP
unque algu
buscar el d
otros disp
universidad
que facilita
entos.
rogramador
más comun
P
unas no
dispositivo e
positivos, l
d.
a la tarea d
r, puesto qu
es.
se
en
as
de
ue
F
F
L
Figura 10. D
Fuente: Mic
Las caracte
• V
o
• M
• C
• C
• 3
• M
Diagrama de
rochip inc., w
erísticas pri
Velocidad d
oscilador int
Módulo PW
Comunicaci
Comunicaci
35 pines I/O
Módulo de c
pines del m
www.microc
incipales po
de hasta 4
terno.
M.
ón serial sí
ón I2C.
O (Entrada y
comunicaci
39
microcontrola
chip.com
or las que s
48MHz con
íncrona y a
y salida).
ón USB.
ador tipo TQ
se eligió es
n cristal ex
síncrona (U
FP
te micro so
xterno, y d
USART y U
on:
e 8MHz co
UART).
on
4l
p
g
i
y
F
4.1.2. Módlectura del
programa
gestionar u
información
y por ultimo
Figura 11. D
dulo de somódulo lla
y un ento
una base d
n grabada e
o enviar la o
Diagrama de
oftware. P
ave, se utili
rno grafico
de datos a
en el módu
orden de ac
flujo del mó
40
ara el con
za el módu
o que se
partir de u
ulo llave cor
ctivación pa
ódulo softwa
ntrol del mó
ulo de softw
encargan
un archivo
rresponde
ara el módu
are
ódulo de a
ware, que c
de crear l
de texto, v
a un usuar
ulo de aper
apertura y
consta de u
los usuario
verificar si
rio autorizad
rtura.
la
un
os,
la
do
41
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
d
i
p
m
a
F
F
S
“
L
c
d
de texto,
instantánea
programac
manera qu
aspectos.
Figura 12. In
Fuente: Bor
Software p
“USB Key”.
La columna
creó, encar
de apertura
campos
a, y la se
ión de tod
ue el prog
nterfaz grafic
land Softwa
para contro
. Para ver e
a vertebral
rgado de re
a por med
de compr
ección de
os los elem
gramador p
ca de C++ B
re Corporati
ol de acce
el código fu
del sistema
ealizar una
dio de la c
42
robación e
código e
mentos qu
pueda mon
Builder 6
on copyrigh
eso y autor
uente véase
a de contro
interacción
creación y
entre otros
en la cual
e compone
nitorear el
t 2002
rización m
e ANEXO 3
l de acceso
n entre el m
posterior v
s objetos
l se lleva
en la aplic
progreso
ediante pro
3.
o es el prog
módulo llave
verificación
de mane
a cabo
ación, de t
en los d
otocolo US
grama que
e y el módu
de usuari
era
la
tal
os
SB
se
ulo
os
d
p
F
a
o
c
F
1
dentro de u
para cualqu
Figura 13. V
Fuente: Dis
Esta es la v
autorizados
opción de s
conectados
Figura 14. V
Fuente: Dis
1 MBR: diseñ
una lista de
uier person
Ventana prin
seño propio
ventana pri
s, la opción
seleccionar
s los módul
Ventana de s
seño propio ado por los a
efinida por
a que haga
cipal USB ke
o MBR.1
ncipal dond
n de registra
r puerto, qu
os llave y d
selección de
o MBR.
autores como
43
medio de
a las veces
ey.
de se pued
ar que sirve
ue verifica
de apertura
e puerto.
parte del des
una interfa
de adminis
e encontra
e para crea
el puerto e
a.
sarrollo del pr
az gráfica y
strador.
ar la lista de
ar un usuari
en el que se
roceso
y de fácil u
e los usuari
io nuevo, y
e encuentra
so
os
la
an
L
p
F
l
m
u
l
o
e
a
u
q
La ventana
puerto se c
Figura 15. V
Fuente: Dis
Después d
los usuario
modo de es
un usuario
llave con u
orden de a
esta orden
al recinto o
Una vez re
una orden
que vuelva
a de selecc
conectaron
Ventana prin
seño propio
e haber se
os permitido
spera el PC
autorizado
un usuario
activación d
retira el se
o deposito.
etirado el m
para que
al modo de
ión de pue
los módulo
cipal USB ke
o MBR.
eleccionado
os y el pro
C escanea
o, una vez
permitido,
e un dispo
eguro que
módulo llav
vuelva a s
e espera.
44
rto permite
os llave y de
ey con lista
o el puerto c
ograma ent
constantem
se introdu
el program
sitivo eléct
bloquea la
e, el progr
u posición
e selecciona
e apertura.
de usuarios
correcto, se
tra en mod
mente los p
zca en el
ma envía al
rico llamad
puerta, pe
rama envía
inicial (de
ar manualm
desplegada
e despliega
do de de e
puertos preg
puerto USB
módulo de
do pestillo, q
ermitiendo a
al módulo
bloqueo) d
mente en qu
a.
a una lista d
espera. En
guntando p
B un módu
e apertura
que al recib
así el acce
o de apertu
de tal mane
ue
de
el
por
ulo
la
bir
so
ura
era
4s
a
4.1.3. Módsoftware q
autorizado
dulo De Apue le indic
mantener r
Figura 1
pertura. Est
ca si debe
restringido
16. Diagram
45
te mecanis
e activar e
el acceso a
ma de flujo de
smo recibe
el pestillo o
al recinto m
el módulo de
órdenes de
o si es un
monitoreado
e apertura
el módulo d
n usuario n
o.
de
no
46
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 PIC16F877A
Memoria de programa(KB) 3.5 flash 14 flash
Velocidad CPU(MIPS) 5 5
RA M (bytes) 224 368
EEPROM(bytes) 128 256
Pines 18 40
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.
c
F
F
El integrad
convierte e
Figura 17. D
Fuente: Futu
o FT232 s
en una tabla
Diagrama de
ure Technolo
se encarga
a de datos q
pines del in
ogy Devices
47
de recibir
que envía a
ntegrado FT2
s Internation
la informac
al PIC para
232.
al Limited.
ción del or
procesarlo
rdenador y
os.
la
p
F
F
El microcon
procesa pa
Figura 18. D
Fuente: Mic
ntrolador pr
ara enviar la
Diagrama de
rochip inc., w
rincipal es e
as ordenes
pines del m
www.microc
48
el PIC 16f6
al driver L2
microcontrola
chip.com
628A que re
298 para ac
ador PIC 16f
ecibe la info
ctivar el mo
f628A.
ormación y
otor.
la
p
F
F
El driver L2
12 voltios p
pestillo de
Figura 19. D
Fuente: © 2
298 se enca
para activa
la puerta qu
Diagrama de
000 STMicro
arga de con
r el motor
ue controla
pines drive
oelectronics
49
nvertir la in
en el mom
a.
r L298.
formación d
mento de la
del micro e
apertura y
en señales d
y el cierre d
de
del
l
v
u
F
F
e
e
ú
a
a
n
El accionad
lo cual evit
vulnerable
un motor de
Figura 20. P
Fuente: Zho
En la etapa
entorno de
entorno es
última vers
assembler
adicional de
nivel como
dor es un p
a que ante
a ser pene
e 12 voltios
Pestillo eléctr
ongshan Rd
a de desar
e programa
llamado M
sión 8.14, p
(ensambla
el compilad
C.
pestillo eléc
e una falla d
etrado por i
s que recibe
rico.
Car Accesso
rrollo del p
ación propo
PLab IDE (
permite des
ador), adem
dor C18 que
50
ctrico que fu
de electricid
ntrusos; el
e señales d
ories Manuf
rograma pa
orcionado
(Integrated
sarrollar el p
más incluye
e desarrolla
unciona co
dad el siste
pestillo o s
de voltaje d
facturing Fac
ara el micr
por el fab
Developme
programa e
e una opció
a el proceso
n modo inic
ema no que
seguro es
el driver L2
ctory.
rocontrolado
ricante mic
ent Environ
en lenguaje
ón de desc
o en un len
cial “cerrad
ede abierto
activado p
298.
or, se usa
crochip, es
nment), en
e de maquin
carga gratu
guaje de a
do”
o y
por
el
ste
su
na
ita
lto
4
4m
f
c
F
F
4.2. DISEÑ
4.2.1. MPmicrochip,
funciones
característi
• Posi
• Sopo
alto
• Simu
Figura 21. V
Fuente: Mic
ÑO DEL CIR
Lab IDE es muy se
completas
cas princip
ibilidad de r
orte para d
nivel.
ulador de fu
Ventana de t
rochip techn
RCUITO
8.14. El
encillo e int
mezcladas
pales del ID
reemplazar
esarrollo d
uncionamie
rabajo de M
nology incorp
51
entorno d
tuitivo de u
s con una
E, son:
r los motore
e aplicacio
ento a nivel
PLAB.
porated USA
de desarro
sar, y tiene
interfaz li
es de comp
nes robusta
de registro
A
ollo propor
e una gran
impia y or
pilación.
as usando
os.
rcionado p
n cantidad d
rdenada. L
lenguajes d
por
de
as
de
S
l
c
A
s
F
F
Se debe cr
luego se s
configuraci
A continua
seleccionan
Figura 22. C
Fuente: Mic
rear un pro
selecciona
ón del proy
ación se
ndo especí
ConFiguració
rochip techn
oyecto, sele
la opción P
yecto.
muestra e
ficamente e
ón de proyec
nology incorp
52
eccionando
Project Wiz
el proceso
el kit de com
cto.
porated USA
Project en
zard, con e
o de crea
mpilador C
A
n la barra d
el fin de s
ación de
18.
e comando
eleccionar
un proyec
os,
la
cto
53
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.
54
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.
FFigura 23. D
Fuente: La
Diagrama es
bcenter Ele
quemático r
ectronics. D
55
realizado en
Diseño prop
proteus ISIS
pio MBR.
S módulo llaave.
F
F
Figura 24. D
Fuente: La
Figura 25. V
Fuente: La
Diseño del ci
bcenter Ele
Visualización
bcenter Ele
rcuito impre
ectronics. D
n 3D de los c
ectronics. D
56
eso PCB en p
Diseño prop
componente
Diseño prop
proteus ARE
pio MBR.
s en el circu
pio MBR.
ES módulo ll
uito impreso
lave.
módulo llave.
F
Figura 26. D
Fuente: La
Diagrama es
bcenter Ele
quemático r
ectronics. D
57
realizado en
Diseño prop
proteus ISIS
pio MBR.
S módulo appertura.
F
F
a
Figura 27. D
Fuente: La
Figura 28.
apertura.
Fuente: La
Diseño del ci
bcenter Ele
Visualizació
bcenter Ele
rcuito impre
ectronics. D
ón 3D de lo
ectronics. D
58
eso PCB en p
Diseño prop
os compone
Diseño prop
proteus ARE
pio MBR.
entes en el
pio MBR.
ES módulo a
circuito im
apertura.
preso módu
ulo
4
A
o
c
F
a
p
p
d
m
c
4.3. INSTA
Al conecta
operativo W
controlador
Figura 29. O
Fuente: Mic
En esta ven
almacenad
para busca
por el mom
de la vent
mostrar el
controlador
ALACIÓN D
ar el dispo
Windows X
r del dispos
Opción de bú
crosoft Win
ntana es ne
o en el equ
arlo, en esta
mento”, y lu
ana, luego
nombre de
r.
EL DRIVER
ositivo móv
XP, aparec
sitivo.
úsqueda del
ndows XP.
ecesario ind
uipo local,
a ventana s
uego se ha
o de dar c
el dispositiv
59
R EN WIND
vil (llave),
cerá una v
controlador
dicarle al s
y que no e
se le indica
bilitara el b
clic en sigu
vo conecta
DOWS XP
en un co
ventana pa
r en internet.
istema ope
es necesari
al sistema
botón siguie
uiente, la v
ado y dos o
mputador
ara indicar
.
erativo que
io conectar
operativo l
ente en la
ventana ca
opciones p
con sistem
r la falta d
el driver es
rse a intern
la opción “N
parte inferi
ambiara pa
ara ubicar
ma
del
stá
net
No
ior
ara
el
F
d
i
i
L
e
s
Figura 30. O
Fuente: Mic
En este ca
de indicar
instalación
incluido en
La otra o
especifica,
seleccionar
Opción de ins
crosoft Win
so, el nom
el nombr
automátic
los paquet
pción es
para este
rla, se da c
stalación au
ndows XP.
bre del dis
re del disp
a del cont
tes incluido
instalar el
caso en es
lic en siguie
60
tomática o m
positivo llav
positivo co
trolador, si
s por defec
controlad
special, se
ente y apar
manual.
ve, es Pic
onectado,
empre y c
cto en el sis
or desde
usa la seg
recen las si
USB. Wind
permite se
cuando est
stema opera
una lista
gunda opci
iguientes o
dows adem
eleccionar
te haya sid
ativo.
o ubicació
ión, luego d
pciones.
ás
la
do
ón
de
F
L
d
e
t
y
a
b
Figura 31. S
Fuente: Mic
Las opcion
de la carpe
examinar e
también ofr
y CDs, dad
algunos dis
botón exam
Selección de
crosoft Win
es proporc
eta que co
el equipo c
rece la pos
do que es la
spositivos,
minar, que m
la ubicación
ndows XP.
cionadas en
ontiene el a
carpeta po
sibilidad de
a forma má
para este c
muestra otr
61
n del control
n esta venta
archivo de
r carpeta p
buscar en
ás común p
caso se bu
ra ventana:
lador.
ana permite
l controlad
para indica
medios ext
para distrib
sca la carp
en indicar la
or, y tamb
arle en qué
traíbles com
uir los cont
peta conten
a ruta exac
bién permite
é lugar est
mo disquet
troladores d
nedora con
cta
en
ta,
es
de
el
F
f
s
s
d
F
Figura 32. L
Fuente: Mic
En esta ve
forma grafi
seleccionar
siguiente, d
de origen a
Figura 33.
Fuente: Mic
Localización
crosoft Win
entana pod
ca, accedie
r el lugar de
después de
a la carpeta
Proceso d
crosoft Win
grafica de la
ndows XP.
demos indic
endo a los
e origen de
e este proc
a de control
de copiado
ndows XP. 62
a carpeta co
car la ruta
directorios
e la carpeta
eso se inic
adores de W
de archivo
ontenedora.
hacia la c
s en forma
a, se da clic
cia una cop
Windows.
os al direct
carpeta con
jerárquica,
c en acepta
pia de archi
torio raíz d
ntenedora d
, después d
ar, y luego e
vos del lug
de Windows
de
de
en
gar
s.
5
m
a
p
L
s
F
5. PRESEN
El funciona
medio de
autentificac
proyecto se
Los compo
siguientes
Figura 34. C
Fuente: Dis
1. Pest
para
de u
volta
activ
NTACIÓN Y
amiento de
recursos
ción para po
e usará un
onentes de
Componente
seño propio
tillo eléctric
a las puerta
un motor b
aje de 12V
vación le lle
Y ANÁLISIS
el sistema
de softw
oder acced
deposito qu
el sistema
s del sistem
o MBR.
co: Es un d
as de los au
ipolar la ap
DC y se c
ega por me
63
S DE RESU
de control
ware y ha
der a un rec
ue hace las
a se puede
ma.
ispositivo u
utomóviles,
pertura de
cierra con u
edio de un
ULTADOS
de acces
ardware se
cinto o depo
s veces de
en observa
usado comú
su función
una puerta
un voltaje d
driver que
o se basa
e pueda
osito, en el
caja fuerte
ar en las
únmente en
n es bloque
a, este se
de -12V DC
a su vez e
en que p
realizar un
caso de es
.
dos figur
n los segur
ear por med
abre con u
C, la señal d
es controlad
por
na
ste
as
os
dio
un
de
do
F
por
los e
aper
2. Circu
encu
men
3. Puer
post
4. Puer
seña
5. PC e
de c
Figura 35. M
Fuente: Dis
6. Mód
sea
aper
medio del i
elementos
rtura).
uito princip
uentran el
ncionado.
rto USB he
terior auten
rtos USB d
al de contro
en el cual s
controlar el
Módulo llave
seño propio
dulo llave: E
leída por
rtura
integrado T
mencionad
pal del
microcontro
embra en
ticación.
del PC pa
ol al módulo
se encuentr
sistema.
foto real y d
o MBR.
En el cual s
el módulo
64
TF232 y el
dos anterior
módulo de
olador, el in
el cual se
ra leer los
o de apertu
ra el módul
diseño 3D.
se guarda
de softwa
microcontr
rmente hac
e apertura
ntegrado y
conecta e
datos del
ra.
o de softwa
la identidad
are, y este
rolador 16F
cen parte de
a: en este
el driver a
el módulo l
módulo ll
are, princip
d del usua
accione e
F628A. (tod
el módulo d
e circuito
anteriormen
lave para
ave y envi
al encargad
rio, para qu
el módulo d
os
de
se
nte
su
iar
do
ue
de
L
F
F
Los pasos
1. Con
Figura 36. C
Fuente: Dis
2. Inicia
Figura 37. V
Fuente: Dis
para obser
ectar los pu
Conexión mó
seño propio
ar el módul
Ventana de in
seño propio
rvar el resul
uertos USB
ódulo apertu
o MBR.
lo de softwa
nicio de inte
o MBR.
65
ltado del sis
B de la caja
ra a módulo
are.
erfaz.
stema son
fuerte a los
o software.
los siguien
s del PC.
tes.
F
F
3. Sele
aper
Figura 38. S
Fuente: Dis
4. Intro
Figura 39. C
Fuente: Dis
eccionar el
rtura.
Selección de
seño propio
oducir el mó
Conexión mó
seño propio
puerto en e
puerto.
o MBR.
ódulo llave
ódulo llave a
o MBR.
66
el que se e
en el puert
a módulo ape
encuentra c
o USB hem
ertura.
conectado e
mbra de la c
el módulo d
caja fuerte.
de
F
5. Espe
verif
Figura 40. R
Fuente: Dis
erar a que
fique el usu
Reconocimie
seño propio
e el módu
uario (aprox
ento de usua
o MBR.
67
ulo de soft
ximadamen
ario.
tware reco
te 6 segund
onozca el
dos).
dispositivo
y
F
F
6. Una
aper
abrir
Figura 41. S
Fuente: Dis
7. Una
la p
bloq
espe
Figura 42. S
Fuente: Dis
vez el p
rtura, el pe
rla.
Sistema abie
seño propio
vez manip
uerta y ret
uee de nue
era.
Sistema cerra
seño propio
rograma e
estillo eléctr
erto.
o MBR.
pulado el co
tirar el mó
evo la pue
ado y en mo
o MBR.
68
envié la se
rico libera e
ontenido de
dulo llave
rta y condu
odo de espe
eñal de ac
el seguro e
e la caja fue
para que
uzca el sist
ra.
ctivación a
e la puerta,
erte se proc
el módulo
tema hasta
l módulo d
, permitiend
cede a cerr
de softwa
a el modo d
de
do
rar
are
de
69
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.
70
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
71
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.
72
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!
73
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-presentacin-
oral-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]
74
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.
75
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
76
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.
77
ANEXOS
78
ANEXO A CÓDIGO FUENTE DEL MICROCONTROLADOR PIC18F4550 MÓDULO LLAVE
#include <18F4550.h> #fuses HSPLL, NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN #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
79
// 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]; //declaramos variables int8 envia[1]; 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) {
80
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(LEDR); LED_OFF(LEDA);} //apagamos los leds if (param1 == 1) {LED_ON(LEDV); LED_OFF(LEDR); LED_OFF(LEDA);} //encendemos led verde if (param1 == 2) {LED_OFF(LEDV); LED_ON(LEDR); LED_OFF(LEDA);} //encendemos led rojo if (param1 == 3) {LED_OFF(LEDV); LED_OFF(LEDR); LED_ON(LEDA);} } } } } }
81
ANEXO B CÓDIGO FUENTE DEL MICROCONTROLADOR PIC16F628A MÓDULO MOTOR
* 0000: MOVLW 00 0001: MOVWF 0A 0002: GOTO 12A 0003: NOP 0004: MOVWF 7F 0005: SWAPF 03,W 0006: CLRF 03 0007: MOVWF 21 0008: MOVF 7F,W 0009: MOVWF 20 000A: MOVF 0A,W 000B: MOVWF 28 000C: CLRF 0A 000D: SWAPF 20,F 000E: MOVF 04,W 000F: MOVWF 22 0010: MOVF 77,W 0011: MOVWF 23 0012: MOVF 78,W 0013: MOVWF 24 0014: MOVF 79,W 0015: MOVWF 25 0016: MOVF 7A,W 0017: MOVWF 26 0018: MOVF 7B,W 0019: MOVWF 27 001A: BCF 03.7 001B: BCF 03.5 001C: MOVLW 8C 001D: MOVWF 04 001E: BTFSS 00.5 001F: GOTO 022 0020: BTFSC 0C.5 0021: GOTO 09B 0022: MOVF 22,W 0023: MOVWF 04 0024: MOVF 23,W 0025: MOVWF 77
82
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
83
0094: MOVWF 77 0095: DECFSZ 77,F 0096: GOTO 095 0097: GOTO 098 0098: DECFSZ 00,F 0099: GOTO 08C 009A: RETLW 00 .................... #use 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 .................... {
84
.................... 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
85
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
86
.................... 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
87
.................... 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
88
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
89
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 ....................
90
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,"_MPUSBGetDeviceCount"); usbversion = (MPUSBGetDLLVersion)GetProcAddress(libdinam,"_MPUSBGetDLLVersion"); if (usbclose == NULL){ShowMessage("error al cargar la funcion usbclose");}
91
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();
92
} } } 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, (void*)SendData, SendLength, &SentDataLength, SendDelay);
93
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)
94
{ 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());
95
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(); } //---------------------------------------------------------------------------