Desarrollo de una plataforma de supervisión y control vía internet
Texto completo
(2) IEL1-03-II-24. RESUMEN. Se diseñó e implementó un sistema que permite operar y supervisar dispositivos remotos vía una conexión a una red de área local IEEE 802.3 (Ethernet) usando la pila de protocolos TCP/IP. Si la red tiene conexión a Internet entonces se pueden desarrollar aplicaciones de monitoreo y control remoto vía Internet. El sistema es flexible, no está limitado a una aplicación en particular; más bien provee ciertas capacidades con las cuales se puede abordar el desarrollo de una aplicación específica de monitoreo y control; para esto el desarrollo incluye una plataforma hardware con conexión a la red con capacidad de servidor HTTP, lo que hace que la interfaz remota pueda visualizarse en un navegador web convencional, y de manejo de datagramas UDP, con lo que se abre la posibilidad de generar eventos o alertas. Además cuenta con interfaces paralela de propósito general, serial (RS-232), SPI, I2C y posibilidad de implementar otras como GPIB o USB, por ejemplo. También se implementaron librerías en software para soportar el desarrollo de las aplicaciones: el algoritmo AES (Advanced Encryption Standard) de cifrado de datos para permitir aplicaciones seguras, la posibilidad de almacenar valores o parámetros de configuración en memoria no volátil y la capacidad de programar la dirección IP utilizando un PC o un teclado matricial externo, o automáticamente con el protocolo de configuración dinámica de host, DHCP. El trabajo se desarrolló hasta lograr un prototipo completamente funcional y se demostró su funcionamiento en una aplicación sencilla de monitoreo de temperatura por Internet. El sistema propuesto es de utilidad en aplicaciones de monitoreo y control remoto de ancho de banda relativamente bajo (el límite teórico máximo es de cerca de 10kBps) y donde se desee una solución hardware como alternativa a utilizar un computador personal.. 2.
(3) IEL1-03-II-24. En este documento se recogen las motivaciones y los objetivos del proyecto, así como su ubicación en el marco del monitoreo/control remoto y la Internet, el proceso de diseño de la solución y finalmente los resultados obtenidos, posibles aplicaciones y perspectivas futuras. También se incluyen como referencia un manual de funcionamiento de la plataforma desarrollada, los diagramas eléctricos, y una guía completa para el desarrollo de una aplicación sencilla de monitoreo remoto de temperatura.. 3.
(4) IEL1-03-II-24. CONTENIDO. Página Introducción. 7. Objetivos. 9. 1. Marco teórico. 10. 1.1. Conceptos de redes ethernet. 10. 1.2. Protocolos de Internet. 12. 2. Metodología. 15. 3. Características de la solución. 17. 4. Solución. 19. 4.1. Arquitectura propuesta. 19. 4.2. Selección de módulo de red y de control de aplicación. 20. 4.3. Módulo de red (SitePlayer SP1). 21. 4.4. Módulo de control de aplicación (Motorola MC68HC908GP32). 22. 4.5. Integración de los componentes. 23. 5. Resultados. 25. 5.1. Hardware. 25. 5.1.1. Primer prototipo. 26. 5.1.2. Segundo prototipo. 27. 5.2. Software. 28. 5.2.1. Comunicación con el SitePlayer. 28. 5.2.2. Algoritmo de seguridad: AES. 29. 5.2.3. Datos de configuración en memoria no volátil. 30. 5.2.4. Configuración manual de IP. 31. 5.2.5. UART. 31. 5.3. Ejemplo de aplicación: monitoreo remoto de temperatura 6. Conclusiones y perspectivas. 31 33. 4.
(5) IEL1-03-II-24. Apéndice 1: Manual de usuario. 35. Apéndice 2: Código de librerías software. 39. Apéndice 4: Plano eléctrico. 60. Referencias bibliográficas. 61. 5.
(6) IEL1-03-II-24. LISTA DE FIGURAS. Página Figura 1: Estructura de una aplicación de monitoreo/control remoto. 8. Figura 2: Topologías de bus y estrella en una red ethernet. 11. Figura 3: Formato de un marco ethernet. 12. Figura 4: Pila de protocolos de Internet. 13. Figura 5: Diagrama funcional por niveles del sistema. 19. Figura 6: Diagrama de los principales bloques que componen el sistema. 24. Figura 7: Primer prototipo del sistema. 26. Figura 8: Segundo prototipo del sistema. 27. Figura 9: Formato de comando para el SitePlayer. 28. Figura A1.1: Componentes de la tarjeta. 35. Figura A1.2: Conector CON4. 36. Figura A1.3: Conector CON5. 36. 6.
(7) IEL1-03-II-24. INTRODUCCIÓN. Con el enorme desarrollo de Internet y el aumento de las posibilidades de acceso a la red, cada día son más las posibles aplicaciones de monitoreo y control remoto de sistemas o procesos en medios industriales, comerciales o residenciales; y los sistemas electrónicos hardware, por su costo, tamaño y robustez son una alternativa atractiva en muchas de estas aplicaciones. De hecho se estima que en algunos años el número de sistemas embebidos con conexión a Internet superará al de computadores personales. Por otra parte, uno de los medios físicos de acceso más popular a Internet son las redes de área local (LAN) basadas en el estándar IEEE 802.3, comúnmente conocidas como ethernet, que usan la pila de protocolos TCP/IP [1-4]; dichas redes son comunes en entornos industriales, comerciales, campus universitarios e incluso muchas conexiones residenciales de Internet por cable tienen una interfaz ethernet. Es por esto que un sistema hardware con capacidad de conexión a Internet a través de una interfaz ethernet es bastante relevante. La idea de este trabajo es aprovechar la popularidad actual de las redes ethernet y de los computadores personales, para proveer una forma de monitorear y controlar sistemas remotos; y hacerlo de una forma económica, eficiente y flexible. La aplicación de monitoreo/control remoto que se considera es como la de la figura 1; en este contexto, el sistema propuesto es la caja “unidad de monitoreo / control” y cuenta con dos interfaces: una de propósito general hacia el dispositivo que se pretende monitorear/controlar, y una hacia la red ethernet. La unidad remota es accesible mediante los protocolos de Internet TCP/IP ya sea dentro de la red local, o desde Internet cuando se dispone de conexión. En esta estructura, se considera un computador personal como interfaz hacia el usuario del sistema por ser común, versátil y fácil de programar, pero esto no necesariamente tiene. 7.
(8) IEL1-03-II-24. que ser así, en general se contempla el uso de otros dispositivos como otros sistemas embebidos, PDA,s, etc. En todo caso, este computador no es esencial para el funcionamiento del sistema. La unidad de monitoreo/control, además de proveer la interfaz entre el dispositivo y la red, también tiene la posibilidad de ser programada para añadir funcionalidades como tomar acciones de control o generar señales de alerta ante eventos, sin la participación de un programa de aplicación remoto.. Local. Dispositivo a. Unidad de. monitorear /. monitoreo /. controlar. control. Red local / Internet. Interfaz ethernet. Interfaz de propósito general. Remoto. PC de monitoreo / control Figura 1. Estructura de una aplicación de monitoreo/control remoto.. Como convención a lo largo del documento todas las referencias al sistema se basarán en el esquema de la figura 1, se considerará “local” a la unidad de monitoreo / control y al dispositivo objeto de la aplicación y “remoto” al PC u otro sistema de interfaz con el usuario.. 8.
(9) IEL1-03-II-24. OBJETIVOS. Básicamente, el sistema propuesto debe provee una interfaz entre una aplicación de monitoreo o control ejecutándose por ejemplo (aunque no necesariamente) en un computador, y el sistema o proceso que se desea monitorear o controlar. La interfaz con la aplicación remota será a través de una red de área local ethernet usando la pila de protocolos de Internet TCP/IP. Debe permitir una comunicación segura en ambos sentidos, hacia y desde el dispositivo remoto, por segura se entiende que los datos transmitidos no puedan ser interceptados y que no sea posible ejecutar acciones de control o modificar el estado del dispositivo local de aplicación sin la debida autorización El módulo que se desarrolle debe ser flexible, de tal forma que se adapte a distintas. aplicaciones,. por. lo. tanto. la. interfaz. con. el. dispositivo. a. controlar/monitorear será lo más general posible, tanto en el aspecto físico como en el lógico, tendrá interfaces serial y paralela de propósito general y la posibilidad de ampliar a otras interfaces físicas y protocolos de comunicación. Aunque la conexión a una red cableada implica que las aplicaciones serán esencialmente estáticas (no móviles como podría ser el caso en una red inalámbrica), el sistema deberá ser portable, en el sentido que deberá poder cambiarse el punto de conexión con facilidad, también se requiere que sea de tamaño relativamente pequeño y de bajo costo. Es importante que el sistema pueda responder a diferentes eventos provenientes tanto de la red como del dispositivo de aplicación local y a su vez pueda generar eventos o señales en ambos sentidos. El resultado del proyecto será el desarrollo de un sistema completo: unidad hardware y un programa local flexible sobre PC; el sistema se comprobará funcionando en una aplicación específica de monitoreo y control, como la supervisión remota de temperatura.. 9.
(10) IEL1-03-II-24. MARCO TEÓRICO. 1.1 CONCEPTOS DE REDES ETHERNET. La primera red ethernet surgió de un trabajo en Xerox Corporation sobre redes de área local y, debido a su éxito se propuso una especificación en 1980 por Digital Equipment Corporation, Intel Corporation y Xerox Corporation (por eso también se conoce como ethernet DIX); en base a. esta especificación, se desarrolló el. estándar IEEE 802.3, publicado en 1985. Ambos estándares especifican únicamente las capas física y de enlace de datos del modelo OSI de referencia de redes, es decir especificaciones del canal físico, niveles eléctricos y tiempos de las señales involucradas, así como el formato del marco utilizado en la transmisión de datos (que soporta una longitud máxima de información de 1500 bytes). Aunque los dos estándares son muy similares, incluso completamente compatibles a nivel físico, existen algunas diferencias a nivel de la capa de enlace de datos [2,3]; realmente hoy en día quedan pocas redes ethernet originales y la gran mayoría se acogen al estándar IEEE 802.3; es práctica común y se hará a lo largo de este documento, utilizar los términos ethernet y 802.3 indiferentemente para referirse a las redes compatibles con el estándar IEEE 802.3. El estándar define redes operando sobre cable coaxial en topología de bus a 10 Mbps o sobre cable UTP en topología de estrella a 10 o 100Mbps (esta última opción también se conoce como fast ethernet); también hay implementaciones sobre fibra óptica. En la topología de estrella los equipos se conectan a un repetidor multipuesto central conocido como concentrador o hub (figura 2). Las implementaciones con cable UTP y topología de estrella son de lejos las mas populares por su facilidad de implementación y mantenimiento, buena velocidad, bajo costo y flexibilidad.. 10.
(11) IEL1-03-II-24. En una red ethernet, todos los equipos se comunican usando un canal compartido, el acceso al medio físico está controlado por el. protocolo CSMA/CD: Carrier. Sense Multiple Access / Collision Detection, la idea es que los equipos pueden transmitir por el canal siempre que no se encuentre en uso; debido a retardos, es posible que dos transmisiones se interfieran y se presente una colisión; los equipos deben poder detectar la colisión y entonces detener la transmisión y reintentarla después de un intervalo de tiempo aleatorio.. Segmento de bus. Concentrador (HUB). Figura 2. Topologías de bus y estrella en una red ethernet (adaptada de [2]).. 11.
(12) IEL1-03-II-24. La información se transmite a través de la red en paquetes denominados marcos, en la figura 3 se muestra el formato de un marco IEEE 802.3 básico [2,4]. Orden de transmisión. • • • • • • •. PRE: preámbulo, 7 bytes para sincronizar la transmisión. SFD: Delimitador de inicio de marco, 1 byte, indica comienzo de las direcciones y datos. DA: Direccion destino, 6 bytes SA: Dirección origen, 6 bytes Longitud / tipo: 4 bytes, longitud de los datos o tipo de marco si se emplea un tipo de marco opcional. Datos / relleno: 46-1500 bytes, contenido de datos del marco, si la longitud de los datos en menor que 46 bytes, se rellena hasta lograr al menos 46 byes. FCS: 4 bytes, verificación de redundancia cíclica para detección de errores en el marco. Figura 3. Formato de un marco ethernet.. Cada interfaz de red (tarjeta de red) está identificada por una dirección única de red de 48 bits, conocida también como dirección MAC (Media Access Card).. Como ya se mencionó, el estándar IEEE 802.3 define únicamente las capas física y de enlace de datos, por lo que queda abierta la posibilidad de utilizar otros protocolos en las capas superiores; es muy común que sobre una red ethernet se trabaje con la pila de protocolos de Internet (TCP/IP) y en este caso, la red local puede estar conectada a la Internet a través de una pasarela (gateway).. 1.2 PROTOCOLOS DE INTERNET. A continuación se presenta una breve descripción de los protocolos en la pila de protocolos de Internet, relevantes al proyecto (aquellos resaltados en la figura 4 [3]).. 12.
(13) IEL1-03-II-24. •. Capa física y de enlace de datos: La pila de protocolos no especifica estas capas, los protocolos de Internet pueden correr sobre distintos tipos de redes, ethernet, token-rign, etc.. Figura 4. Pila de protocolos de Internet (adaptada de http://www.auggy.mlnet.com/ibm/ 3376c23.html). •. IP: Internet Protocol IP es el protocolo que oculta la red física subyacente y crea una red virtual en la que todos los hosts se identifican por una dirección de 32 bits (dirección IP). En el nivel de IP se maneja el enrutamiento de los datos entre las distintas redes que conforman Internet. Es un protocolo no confiable y no orientado a la conexión, se limita a entregar datos en paquetes llamados datagramas entre dos puntos de la red. Los datagramas se pueden perder, duplicar o llegar en desorden.. •. ARP: Address Resolution Protocol En el caso de las redes ethernet (y también en otras redes físicas), los equipos en la red se identifican por direcciones MAC, y para dirigir los marcos ethernet al destino correcto en la red no es suficiente la dirección IP. El protocolo de resolución de dirección se encarga de obtener la dirección MAC a partir de la dirección IP de un equipo en la red. Cuando un equipo desea enviar datos a un IP en la red, envía primero una petición ARP a toda la red solicitando la dirección de red asociada al IP deseado; si un equipo en la red identifica como. 13.
(14) IEL1-03-II-24. suyo ese IP, envía una respuesta ARP con su dirección MAC, con la que ya se puede establecer la comunicación. Normalmente, además, los equipos guardan en una tabla (caché ARP) las correspondencias IP/MAC obtenidas por ARP para usos futuros. •. ICMP: Internet Control Message Protocol Este protocolo es parte integral de IP, y lo utiliza para enviar mensajes cortos reportando errores en la comunicación IP; también es utilizado por el popular ping para, por medio de respuestas de eco, determinar si un determinado host es accesible en la red.. •. UDP: User Datagram Protocol UDP es básicamente una interfaz de aplicación para IP, añade el concepto de puertos para enviar y recibir datagramas entre distintos procesos ejecutándose en. un. host. con. una. sola. dirección. IP,. en. ese. sentido. es. un. multiplexor/demultiplexor para IP. No añade fiabilidad, control de flujo o recuperación de errores. •. TCP: Transmisión Control Protocol TCP proporciona una conexión lógica confiable entre dos procesos ejecutándose en hosts en la red; desde el punto de vista de la aplicación, TCP transfiere un flujo continuo de bytes a través de Internet, el protocolo se encarga de segmentar la información y transmitirla en datagramas IP al destino. También se garantiza que todos los datos lleguen al destino y se reciban en el orden correcto y se implementa control de flujo, es decir evitar que se produzca sobrecarga en los buffers de recepción. TCP establece y configura una conexión entre los dos procesos, por la que se puede enviar información simultáneamente en los dos sentidos.. •. HTTP: Hypertext Transfer Protocol Proporciona la forma más común de transferir contenido Web (páginas y otros recursos) desde un servidor hacia el navegador, funciona sobre TCP.. 14.
(15) IEL1-03-II-24. METODOLOGÍA. En el proceso de diseño e implementación del sistema para monitoreo y control remoto vía Internet, se siguió la siguiente metodología: Primero un estudio teórico de las características de las redes relevantes al proyecto; redes de área local ethernet cubriendo los niveles físico y de enlace de datos y los distintos protocolos de Internet. Se propuso una arquitectura de alto nivel del sistema, que garantizara que se cumplieran los objetivos del proyecto. Después, se realizó la evaluación de distintas plataformas hardware comerciales con soporte ethernet (incluyendo la interfaz física) y que implementen la pila de protocolos de Internet (TCP/IP), o aquellas para las que se puedan obtener los controladotes de software TCP y desarrollar la interfaz física necesaria. Para dichas plataformas también fue necesario investigar la disponibilidad de los sistemas de desarrollo (hardware y software) correspondientes y familiarizarse con ellos, también contemplar la posibilidad de implementar los que no estén disponibles. Con base en estos datos, y teniendo en cuenta los planteamientos de flexibilidad y economía, se hizo la selección de la plataforma adecuada y se desarrollaron los primeros prototipos de pruebas, inicialmente hasta el grado de lograr una conexión básica, también para familiarizarse con el funcionamiento y capacidades del hardware escogido. Luego se refinó el diseño del sistema para lograr todas las características deseadas y se implementó un prototipo completamente funcional, sobre el que se realizaron pruebas para detectar errores o posibles mejoras en la implementación. Este diseño incluyó una parte hardware: interfaces con la red y con el dispositivo a monitorear/controlar, circuito de programación de la aplicación, alimentación, ubicación de los componentes en una tarjeta de circuito impreso, etc. y una parte. 15.
(16) IEL1-03-II-24. software: implementación y manejo de protocolos de alto nivel, consideraciones de seguridad, etc. Finalmente, sobre esta implementación se desarrolló una aplicación de monitoreo remoto vía Internet completa (específicamente monitoreo remoto de temperatura con seguridad), para validar el funcionamiento del sistema e identificar errores y posibles modificaciones o mejoras.. 16.
(17) IEL1-03-II-24. CARACTERÍSTICAS DE LA SOLUCIÓN. Para cumplir con los objetivos del proyecto, la plataforma a diseñar debe tener las siguientes características específicas: •. Plataforma hardware autosuficiente; aunque en una aplicación específica puede utilizarse un computador u otro dispositivo para el monitoreo o control, este no debe ser necesario para el funcionamiento del sistema. •. Debe contar con una interfaz a una red IEEE 802.3 baseT, es decir conexión con cable UTP a un hub (no se consideran las implementaciones con cable coaxial).. •. Acceder a la red mediante los protocolos de Internet.. •. Tener la capacidad de comunicarse con estos protocolos con aplicaciones corriendo en otras plataformas, por ejemplo JAVA o C en un computador.. •. Debe contar con distintas interfaces para el dispositivo local a monitorear o controlar: puertos digitales de propósito general, puerto serial, análogo/digital, etc.. •. Tener flexibilidad en la aplicación, capacidad de cambiar y programar la aplicación con facilidad.. •. Capacidad para implementar otras interfaces mediante extensiones de hardware / software (como GPIB o USB).. •. El punto de conexión debe poder establecerse y cambiarse con facilidad, esto implica la capacidad de reprogramar la dirección IP del dispositivo.. •. Los datos de configuración (como por ejemplo la dirección IP asignada) deben persistir ante interrupciones de la alimentación.. •. Debe implementar algún algoritmo de seguridad para la comunicación.. 17.
(18) IEL1-03-II-24. •. Tener la capacidad de responder a eventos generados tanto en la red como en las interfaces de aplicación.. •. Tener también la capacidad de generar eventos hacia la red y las interfaces de aplicación.. 18.
(19) IEL1-03-II-24. SOLUCIÓN. 4.1 ARQUITECTURA PROPUESTA. La arquitectura básica consiste en dos módulos funcionales, uno para manejar las funciones de comunicación en la red y otro para manejar las interfaces y acciones sobre el dispositivo local; la aplicación particular de supervisión o control se construye sobre estas dos bases. En la figura 5 se muestra un diagrama por niveles del sistema con la arquitectura propuesta, se puede ver la separación de las funciones de red y de control, integradas por el programa de aplicación. El sistema debe proveer ciertas funcionalidades básicas integradas, estas son la interfaz de red, los protocolos de comunicación y algoritmo de seguridad en cuanto a funciones de red, y las interfaces y protocolos en cuanto al control y monitoreo local; estos se indican en la figura 5 como cajas en color oscuro; se indica en color claro la flexibilidad de la aplicación y la posibilidad de implementar otras interfaces y protocolos.. NIVEL DE APLICACIÓN Programa de aplicación local. Aplicación remota de monitoreo / control. Librerías Seguridad. UART, 2. SPI, I C. Protocolos de comunicación Interfaz a la RED. NIVEL FÍSICO. Red Ethernet. Otros (GPIB, USB). Sistema local a supervisar / controlar. Interfaz serial, paralela, etc. Conexión física local. SISTEMA. Figura 5: Diagrama funcional por niveles del sistema.. 19.
(20) IEL1-03-II-24. Con esta arquitectura, desde el punto de vista de una aplicación específica, las funciones de red y de control se manejan por separado, lo cual permite un desarrollo más sencillo de aplicaciones; además se pueden manejar cambios o actualizaciones en cada una de las funciones por separado, facilitando el mantenimiento del sistema.. 4.2 SELECCIÓN DE MÓDULO DE RED Y DE CONTROL DE APLICACIÓN. La implementación del sistema estuvo guiada por la disponibilidad de plataformas que implementaran las funciones de red o para las que se pudieran implementar dichas funciones. Se evaluaron distintas opciones comerciales como: •. Microcontrolador Dallas DS80C400: microcontrolador con arquitectura 8051, MAC ethernet y manejo de TCP/IP como software en ROM.. •. Microcontroladores Rabbit con manejo de TCP/IP por software.. •. SitePlayer SP1: Coprocesador web con MAC ethernet y servidor HTTP con contenido dinámico.. •. Microcontroladores Microchip PIC para los que se consiguen las librerias TCP/IP (sin MAC).. Los microcontroladores de Dallas y Rabbit tienen un buen desempeño pero sus principales inconvenientes fueron los elevados costos de sistemas de desarrollo y la complejidad de los mismos que podría impedir la completa implementación del sistema en el tiempo disponible. Los microcontroladores PIC tienen un sistema de desarrollo sencillo y económico pero no están diseñados realmente para tareas de red, con lo que las funciones de red corriendo en software limitan severamente la capacidad de realizar otras tareas. Finalmente se escogió el coprocesador web SitePlayer SP1 de Netmedia que se describirá con más detalle adelante; su costo es relativamente bajo (US$ 29 a la fecha) y el sistema de desarrollo es bastante asequible.. 20.
(21) IEL1-03-II-24. Para complementar la funcionalidad del SitePlayer, se utiliza un microcontrolador de propósito general, en este caso el escogido fue un microcontrolador Motorola de la familia HC08. Así, la división funcional de la arquitectura queda aproximadamente reflejada en la división estructural, el SitePlayer implementa las funciones de red mientras que el microcontrolador maneja el control de las interfaces y la interacción con el dispositivo local de aplicación (aproximadamente porque algunas funciones como la seguridad tienen que ser implementadas en el microcontrolador).. 4.3 MÓDULO DE RED (SITEPLAYER SP1). La hoja de datos del SitePlayer SP1 se puede encontrar en [5]; su característica más importante desde el punto de vista de este proyecto, es el concepto que implementa de un coprocesador web: el SitePlayer es un módulo que permite conectividad a una red ethernet y que maneja los protocolos de Internet de forma transparente con el usuario y que se comunica con (posiblemente) un procesador externo a través de un puerto serial por medio de cierto conjunto de comandos predefinidos, logrando así efectivamente la separación de las funciones de red de las del resto de la aplicación. El módulo implementa un servidor HTTP con hasta 48KB de memoria flash de contenido web estático como código html, imágenes, sonidos, scripts, applets JAVA, etc. y 768 bytes de memoria RAM para datos de contenido dinámico (una explicación más práctica se verá en la aplicación mostrada en la sección XXX). También permite el manejo directo de envío y recepción de datagramas UDP de hasta la capacidad de la memoria RAM y los protocolos ARP e ICMP. La principal desventaja que tiene el SitePlayer es que no es posible establecer conexiones TCP, el uso de TCP se hace de forma transparente únicamente a través de HTTP; para aplicaciones que necesiten un flujo de datos orientado a. 21.
(22) IEL1-03-II-24. conexión del estilo de TCP habría que implementar un protocolo con confiabilidad y control de congestión sobre UDP. El SitePlayer es autónomo, para funcionar no requiere la intervención de un agente externo de control, pero por si solo no es lo suficientemente poderoso para la mayoría de aplicaciones, en particular no implementa ningún algoritmo de seguridad; por esto se decidió complementarlo con el microcontrolador de propósito general. La comunicación entre ambos se hace a través de un conjunto de comandos seriales que incluyen escribir y leer datos de memoria, configurar los parámetros de comunicación y dirección IP, enviar y permitir la recepción de datagramas UDP y cambiar el contenido web dinámico. Con estos comandos, el microcontrolador puede usar todas las funciones de red disponibles en el SitePlayer.. Para hacer las primeras pruebas de desarrollos con el SitePlayer, se contó con el kit de desarrollo SPK1 de NetMedia. El software de desarrollo (incluyendo un emulador para PC) se puede conseguir gratuitamente en el sitio web de NetMedia [5]. Además, para verificar las funciones de red se utilizó herramienta ethereal, un software de análisis de tráfico en redes.. 4.4 MÓDULO DE CONTROL DE APLICACIÓN (MOTOROLA MC68HC908GP32). El. microcontrolador. elegido. fue. el. Motorola. MC86HC908GP32,. un. microcontrolador de propósito general de 8 bits con 32KB de memoria flash de programa y 512B de memoria RAM, puerto serial, 33 pines de E/S de propósito general multiplexados con 8 canales de conversión A/D de 8 bits, puerto SPI e I2C, y otros periféricos comunes como temporizadores, etc. Este proporciona las distintas interfaces con el dispositivo de aplicación y también la capacidad de adaptarse a distintas aplicaciones siendo reprogramado. 22.
(23) IEL1-03-II-24. fácilmente. Además, por ser programable, deja abierta la posibilidad de implementar otras interfaces y protocolos de interfaz en software (posiblemente usando hardware adicional), como por ejemplo GPIB o USB. Otra característica importante es que la memoria de programa se puede programar con un circuito sencillo que puede ir en el dispositivo final si se hace una multiplexión adecuada de ciertas líneas.. Los primeros desarrollos de pruebas con el microcontrolador se hicieron con el kit de desarrollo MINI-MAX/908-C de Bipom Electronics, que incluye software de programación. Después se hicieron montajes en proto-board y circuito impreso que incluían el circuito de programación y el desarrollo software se realizó con el entorno de desarrollo CodeWarrior IDE de MetroWerks, del cual se puede conseguir una versión especial con ensamblador sin límite de código [9].. 4.5 INTEGRACIÓN DE LOS COMPONENTES. El sistema completo incluye los módulos de red (SitePlayer) y de control (microcontrolador Motorola), una fuente de alimentación, un conector ethernet para la red, el circuito de programación para el microcontrolador, un driver RS-232, conectores para los puertos y otros componentes menores (figura 6). La fuente tiene una salida regulada de 5V y una salida de alto voltaje sin regular para utilizar con el microcontrolador en modo de programación. El microcontrolador requiere de un conjunto de elementos y circuitos de soporte, el cristal y un filtro para el reloj, condensadores de filtro en la alimentación y el circuito de programación; este último es básicamente un conjunto de drivers 3estados para multiplexar ciertas líneas de E/S con voltajes que permiten ingresar al modo de programación y permitir la comunicación serial por un solo pin del microcontrolador ya que la programación se hace de forma serial.. 23.
(24) IEL1-03-II-24. El driver RS-232 y el conector permiten la comunicación serial con un dispositivo externo; esta interfaz está también multiplexada y se comparte entre la UART del sistema y el circuito de programación del microcontrolador.. Esta implementación se realizó en una tarjeta de circuito impreso como se describe en el capítulo 5, el diagrama esquemático completo del sistema se encuentra en el apéndice 3. Alimentación Fuente RS-232 Red. Programación en circuito del microcontrolador. Conector Ethernet RJ45 con filtros. Comunicaciones (SitePlayer). Paralelo 8 bits. reset Interfaz serial 300 – 115.200bps. Paralelo 8 bits. Driver RS-232. Microcontrolador de propósito general (Motorola MC68HC908GP32). P8 / ADC 8 canales. P8 / SPI 2 /I C. Figura 6: Diagrama de los principales bloques que componen el sistema.. 24.
(25) IEL1-03-II-24. RESULTADOS. Los resultados del proyecto son básicamente un desarrollo hardware: la tarjeta de monitoreo/control, y desarrollo software: librerías para el microcontrolador que soportan el desarrollo de aplicaciones. También se validó el funcionamiento del sistema implementando una aplicación sencilla de monitoreo remoto de temperatura con seguridad en la comunicación.. 5.2 HARDWARE. Después de distintos montajes de pruebas con los sistemas de desarrollo y protoboard, se desarrolló una tarjeta hardware que agrupa los distintos componentes del sistema: SitePlayer, microcontrolador, circuito de programación, conectores y otros componentes necesarios para su operación. En los conectores está la interfaz con la red y la interfaz con la aplicación que incluye E/S de propósito general (puertos A,B,D del microcontrolador), conversores A/D, puerto SPI e I2C, UART. También hay un conector para el puerto de 8 bits del SitePlayer. Una descripción más detallada de los componentes y conectores se encuentra en el apéndice 1: manual de usuario.. Se desarrollaron dos prototipos completamente funcionales del sistema, ambos son esencialmente equivalentes salvo pequeñas mejoras que se hicieron al segundo y se explicarán más adelante.. 25.
(26) IEL1-03-II-24. 5.2.1 Primer prototipo En la figura 7 se puede ver una fotografía del primer prototipo del sistema en la que se señalan los distintos componentes. Se utilizó una versión en encapsulado DIP del microcontrolador que fue la misma con la que se realizaron pruebas en proto-board, también va el oscilador de cristal para generar la señal de reloj y el circuito de programación. El cambio entre los modos de programación y operación se logra con un jumper. Para la conexión a la red se utilizó un conector RJ-45 con filtros ethernet, el UN1S041C de Bothhand. La fuente de interrupción externa del microcontrolador (pin IRQ) se comparte a través de una lógica AND (cableada), ya que es activa por flanco o nivel bajo, para permitir 3 fuentes distintas de interrupción: la UART externa (ver 5.2.5), la interrupción del SitePlayer, y una interrupción externa proveniente de la aplicación disponible en el conector del puerto paralelo D. La fuente de alimentación incluye un conector para adaptador DC, un regulador de 5V y un led de indicación de encendido.. Jumper de propósito general. Conectores puertos paralelos A,B,D.. Microcontrolador Motorola MC68HC908GP32. Programación del microcontrolador. Oscilador Conector DB-9 hembra, puerto serial y programación microcontrolador. Pulsadores de reset SitePlayer SP1. Jumper programación del microcontrolador Conector puerto paralelo del SP1. Conector RJ-45 con filtros Ethernet NU1S041C. Conector para adaptador y regulador. Figura 7: primer prototipo del sistema.. 26.
(27) IEL1-03-II-24. Hay conectores para 3 puertos de E/S del microcontrolador y uno del SitePlayer, uno DB-9 para el puerto serial y dos pulsadores para reiniciar el SitePlayer y el microcontrolador por separado. Finalmente, hay un jumper de propósito general que conecta un “0” o “1” lógico al pin 0 del puerto C del microcontrolador, que puede ser utilizado por el software de aplicación.. 5.2.1 Segundo prototipo En el segundo prototipo (figura 8) se utilizó un encapsulado de montaje superficial (QFP de 44 pines) para el microcontrolador, este proporciona 3 pines de E/S más que el encapsulado DIP y permite una tarjeta más compacta. Además se reorganizaron los pulsadores de reset y los leds para una mejor disposición visual. Se añadió un led de propósito general conectado al pin 5 del puerto C.. Jumper programación del microcontrolador. Conector puerto paralelo del SP1. SitePlayer SP1. Conector para adaptador y regulador. Conector RJ-45 con filtros Ethernet NU1S041C. Conector DB-9 hembra, puerto serial y programación microcontrolador. Oscilador. Jumper de propósito general. Pulsadores de reset. Programación del microcontrolador Leds. Conectores puertos paralelos A,B,D.. Microcontrolador Motorola MC68HC908GP32. Figura 8: segundo prototipo del sistema.. 27.
(28) IEL1-03-II-24. 5.2 SOFTWARE. Para soportar el desarrollo de aplicaciones, se implementaron librerías en lenguaje de ensamble para el microcontrolador Motorola que proveen la funcionalidad básica uso de las capacidades del SitePlayer, cifrado de datos, almacenamiento de datos en memoria no volátil, configuración manual de dirección IP y una UART ya que la que tiene el microcontrolador está dedicada a la comunicación con el SitePlayer. Los detalles de la implementación de las rutinas y su convención de llamada se describen en el apéndice 2. Todas las librerías desarrolladas, una vez compiladas ocupan 2 kB de la memoria FLASH de programa del microcontrolador. 5.2.1 Comunicación con el SitePlayer Para la comunicación entre el microcontrolador y el SitePlayer y el uso de las funciones de red se implementaron todos los comandos proporcionados por el SitePlayer; un comando consiste en una serie de datos que se envían por el puerto serial y que pueden tener respuesta. El formato de un comando es el siguiente [5]:. Figura 9: formato de comando para el SitePlayer. 28.
(29) IEL1-03-II-24. El comando se especifica en los 4 bits mas significativos del primer byte; en los 4 bits menos significativos se especifica el numero de datos menos 1 (para los comandos que lo requieren, si no se deja en cero), es decir 0 corresponde a 1 byte y 15 a 16 que es el número máximo de bytes a enviar/recibir en un comando. La dirección toma 1 o 2 bytes dependiendo de si el comando puede direccionar más allá de las primeras 256 posiciones de memoria. Finalmente vienen los datos (si los hay). Los comandos implementados son los siguientes: •. Status: Retorna el estado del SitePlayer en 1 byte, incluyendo una bandera que indica si ha habido modificaciones de los datos desde la red y 7 variables de bit de propósito general.. •. Read / Write: permiten leer/escribir en la memoria del SitePlayer con direcciones de 1 byte (primeros 256 bytes de memoria). •. ReadX / WriteX: leer/escribir en la memoria del SitePlayer con direcciones de 2 bytes.. •. UDPsend: envio de datagrama UDP. Usando estos comandos, también se implementaron otras rutinas para iniciar el SitePlayer y los parámetros de comunicación y habilitar la recepción de datagramas UDP.. 5.2.2 Algoritmo de seguridad: AES Para permitir seguridad en las comunicaciones, se implementó un algoritmo de cifrado de datos, el estándar AES (Advanced Encryption Standard) propuesto por el NIST estadounidendse (National Institute for Standards and Technology) y recomendado. para. proteger. información. sensible. en. las. agencias. gubernamentales [7]. AES es bastante seguro y resistente a múltiples ataques, y tiene la ventaja de ser un estándar ampliamente aceptado, para el que se consigue el código fuente de. 29.
(30) IEL1-03-II-24. implementaciones en C, JAVA y otros lenguajes, lo que facilita su integración con aplicaciones remotas en esos lenguajes. AES está basado en un algoritmo propuesto por Rijndael y Ammenend; es un algoritmo de cifrado simétrico por bloques de 16 bytes con clave de 128, 192 y 256 bits; para este proyecto se implementó la clave de 128 bits aunque el código puede modificarse fácilmente para los demás tamaños de clave. Para facilitar la implementación y hacerla más eficiente, se almacena la clave expandida en memoria RAM, para lo que hay que reservar 176 bytes, esta se utiliza en todos los subsecuentes procesos de cifrado/descifrado. Con un reloj de 9.8MHz, el cifrado / descifrado de un bloque toma alrededor de 20ms. Se desarrollaron las rutinas de expansión de clave, cifrado y descifrado de bloque.. 5.2.3 Datos de configuración en memoria no volátil El microcontrolador Motorola. elegido. puede programar su propia memoria. FLASH desde el programa de aplicación gracias a que tiene un espacio de memoria único para datos y programas y puede ejecutar programas desde memoria RAM; usando estas capacidades, en una nota de aplicación de Motorola [8] se describe el uso de la memoria FLASH como EEPROM para almacenar pequeños bloques de datos de forma no volátil. Los datos se almacenan en páginas de 128 bytes (tamaño de la página de borrado de la memoria FLASH), y el bloque se reutiliza tantas veces como quepa un boque de datos en la página, multiplicando el número de veces que se puede re-escribir la memoria, que es de 10.000 veces inicialmente; por ejemplo si se almacenan bloques de 4 bytes, que caben 32 veces en una página, se pueden re-escribir 320.000 veces. Se implementaron las rutinas para establecer los bloques de EEPROM en FLASH, leer y escribir bloques de datos; el número de bloques está limitado únicamente por la memoria disponible, así que. las rutinas se pueden utilizar en las. 30.
(31) IEL1-03-II-24. aplicaciones para almacenar cualquier tipo de datos, en principio de hasta 128 bytes de longitud.. 5.2.4 Configuración manual de IP Para permitir la fácil reconfiguración de la dirección IP del dispositivo, se implementó una rutina que la lee desde un teclado matricial externo y la almacena en un bloque de memoria FLASH como EEPROM (ver 5.2.3); esta dirección es utilizada por la rutina de iniciación del SitePlayer para programar la dirección IP. El hardware adicional necesario para utilizar esta funcionalidad es únicamente un teclado matricial y un conector; el teclado utiliza pines de E/S de propósito general de los puertos A y B del microcontrolador y la capacidad de interrupción de teclado.. 5.2.5 UART Debido a que el microcontrolador dedica su puerto serial a la comunicación con el SitePlayer y que se deseaba disponer de una interfaz serial para el dispositivo de aplicación local, fue necesario implementar una UART por software; esta utiliza los pines 2 y 4 del puerto C del microcontrolador y comparte el driver RS-232 y el conector DB-9 de la tarjeta con el circuito de programación del microcontrolador.. 5.3 EJEMPLO DE APLICACIÓN: MONITOREO REMOTO DE TEMPERATURA. Para validar el funcionamiento de la plataforma hardware se desarrolló una aplicación de monitoreo remoto de temperatura con seguridad.. 31.
(32) IEL1-03-II-24. El hardware externo es un sensor de temperatura (National Semiconductors LM35) y un amplificador. Este se conecta a una entrada de conversor A/D del microcontrolador a través del conector en la tarjeta.. El programa en el microcontrolador convierte el dato de temperatura y actualiza los valores máximo y mínimo y los envía al SitePlayer para ser publicados en web, tanto en forma plana como cifrada. Se utilizan las rutinas proporcionadas de comandos del SitePlayer, FLASH como EEPROM, configuración manual de IP y AES. En el SitePlayer hay una página web pública que muestra el valor de la temperatura actual utilizando imágenes para los dígitos, y un applet de JAVA que permite leer los datos de temperatura cifrados utilizando una contraseña. Para conectarse al sistema y monitorear la temperatura solo se requiere conocer la dirección IP y un navegador web convencional; para visualizar el applet-seguro también es necesario que esté instalado el entorno de ejecución JAVA, que se puede descargar de forma gratuita del sitio web de SUN microsystems. En esta aplicación (aunque sencilla) intervinieron todos los componentes del sistema, se programó el SitePlayer, el microcontrolador, se utilizaron las librerías desarrolladas y la interfaz hardware.. 32.
(33) IEL1-03-II-24. CONCLUSIONES Y PERSPECTIVAS. Se desarrolló e implementó un sistema hardware flexible para el monitoreo y control remoto vía Internet a través de una red de área local Ethernet. El sistema provee una plataforma para el desarrollo de interfaces teleoperadas que incluye puerto Ethernet, serial, paralelo, análogo/digital y la capacidad de desarrollar otros como GPIB o USB. Se logró implementar un prototipo completamente funcional del sistema. También se implementaron librerías de software útiles en el desarrollo de nuevas aplicaciones, incluyendo el soporte para cifrado de datos con el estándar AES. La plataforma desarrollada es bastante flexible y se puede adaptar a distintas aplicaciones. Se provee la capacidad de programar tanto el SitePlayer como el microcontrolador en campo. Como el SitePlayer aísla todas las funciones de red del programa de control en el microcontrolador, el desarrollo de aplicaciones es bastante rápido. Como el SitePlayer incorpora un servidor Web, las aplicaciones remotas de monitoreo/control pueden visualizarse como páginas Web o applets de Java que corren en un navegador, haciéndolas muy portables. El sistema puede generar avisos de eventos y enviarlos por la red utilizando datagramas UDP. Para aplicaciones de complejidad demasiado alta para el microcontrolador seleccionado, el diseño es adaptable otros procesadores más potentes sin alterar las funciones y el hardware de red y también se pueden mejorar las prestaciones del SitePlayer mediante actualizaciones de firmware que proporciona el fabricante sin modificar la parte de control de la aplicación; esto es posible debido a la separación de las dos funciones (de red y control) y su interacción por una interfaz serial sencilla basada en comandos.. 33.
(34) IEL1-03-II-24. Aunque el SitePlayer tiene buena funcionalidad y es fácil de usar, no permite establecer conexiones TCP directamente, sólo a través de HTTP. Entonces, para la comunicación está la opción de utilizar UDP e implementar la confiabilidad y control de congestión o trabajar orientado a Web, recibiendo datos por HTTP y publicando las respuestas en el servidor (posiblemente cifradas con AES por seguridad). Por otra parte, la máxima tasa de transmisión/recepción de datos está acotada por la comunicación serial entre el microcontrolador y el SitePlayer, es decir alrededor de 10kBps en el mejor de los casos. En una aplicación específica hay otras limitantes como velocidad de procesamiento de los datos en el microcontrolador y velocidad de la conexión entre la red local e Internet. En todo caso como los retardos en la red son pequeños, se pueden desarrollar aplicaciones en tiempo real.. El sistema desarrollado encuentra aplicaciones en instrumentación y operación remota en proyectos y laboratorios, por ejemplo. También en sistemas de seguridad, como informando el estado de alarmas, o controlando luces, por ejemplo. En una aplicación determinada puede ser monitoreado o controlado por un computador remoto corriendo un programa en JAVA u otros lenguajes.. Otros desarrollos que se podrían implementar para mejorar el sistema serían por ejemplo la capacidad de cambiar los datos de configuración como dirección IP o contraseña a través de la red; asimismo podría lograrse la reprogramación del microcontrolador vía Internet. La tarjeta de circuito impreso también podría hacerse más compacta usando mejores tecnologías de PCB y componentes de montaje superficial.. 34.
(35) IEL1-03-II-24. APÉNDICE 1: MANUAL DE USUARIO. COMPONENTES DE LA TARJETA. En la figura A1.1 se muestran los distintos componentes de la tarjeta, que se describirán a continuación.. U7. CON6. U1. CON1. CON2. J1 J2 U6 CON3. U2. U3. P1. U4 P2 U5 L1 L2 L3. CON5. CON4. Figura A1.1: Componentes de la tarjeta. •. U1: SitePlayer SP1. •. U2: Microcontrolador Motorola MC68HC908GP32-CFB. •. U3: Driver RS-232: MAX232N. •. U4,U5: Drivers 3-estados, 74LS125 para programación del microcontrolador.. •. U6: Oscilador, usar uno de frecuencia máxima 32MHz.. •. U7: Regulador 5V, 7805.. •. CON1: Conector para alimentación, usar un adaptador de 9-12VDC positivo en el centro.. 35.
(36) IEL1-03-II-24. •. CON2: Conector para red; usar un cable con conector RJ-45, cable cruzado sólo si se conecta directamente a otra tarjeta de red (como un PC), cable no cruzado en otro caso. El conector tiene 3 leds incorporados, uno de los cuales indica el establecimiento de conexión a la red.. •. CON3: Conector DB-9 hembra para interfaz serial, terminación null-modem; utilizar cable no cruzado.. •. CON4: Conector puertos A y B del microcontrolador: multiplexa E/S de propósito general, conversor A/D y módulo de interrupción de teclado.. Figura A1.2: conector CON4.. •. CON5: Conector puerto D del microcontrolador y fuente de interrupción externa.. Figura A1.3: conector CON5. •. CON6: Conector puerto paralelo del SitePlayer SP1.. •. P1: Pulsador para reset del SitePlayer. •. P2: Pulsador para reset del Microcontrolador. •. J1:. Jumper. para. cambiar. modo. (programación/operación). 36. de. operación. del. microcontrolador.
(37) IEL1-03-II-24. •. J2: Jumper de propósito general, conecta tierra o VCC al pin 0 del puerto C del microcontrolador.. •. L1: Led de indicación, se enciende cuando la fuente está conectada.. •. L2: Led de indicación, se enciende cuando jumper J1 está en posición de modo de programación.. •. L3: Led de indicación de propósito general, conectado al pin 5 del puerto C del microcontrolador.. PROGRAMACIÓN DEL MICROCONTROLADOR. El programa para el microcontrolador puede escribirse con cualquier herramienta de desarrollo para microcontroladores Motorola de la familia 08 (CodeWarrior de Metrowerks [9] es un buen ejemplo), la descarga del programa se hace usando el protocolo de programación de modo monitor de la familia 08, MON08, a través del puerto serial. Para programar el microcontrolador en la tarjeta, deben seguirse los siguientes pasos: •. Desconectar cualquier dispositivo de los conectores CON4 y CON5.. •. Conectar el cable serial al conector CON3.. •. Poner el jumper J1 en la posición de programación, el led L2 debe encenderse.. •. Presionar el pulsador P2 con lo que el microcontrolador entra en modo monitor.. •. Descargar el programa con la herramienta software seleccionada.. •. Una vez descargado el programa, retornar el jumper J1 a la posición de operación, el led L2 debe apagarse.. •. Desconectar el adaptador del conector CON1 y volver a conectarlo, este power-on reset saca al microcontrolador de modo monitor.. 37.
(38) IEL1-03-II-24. Nota: con un oscilador de 9.8304 MHz la tasa de transmisión para programación es de 9600 bauds, si se utiliza otra frecuencia la tasa cambia proporcionalmente.. PROGRAMACIÓN DEL SITEPLAYER. El archivo binario para programar el SitePlayer se crea utilizando la herramienta SiteLinker que puede obtenerse en el sitio web de NetMedia [5]. El SitePlayer se programa a través de la interfaz de red con el SiteLinker. Mientras dura el proceso de descarga del archivo binario, debe interrumpirse la comunicación serial desde el microcontrolador, para lograr esto se deben seguir los siguientes pasos: •. Poner el jumper J1 en la posición de programación, el led L2 debe encenderse.. •. Presionar el pulsador P2 con lo que el microcontrolador entra en modo monitor y se interrumpe la comunicación serial.. •. Descargar el archivo binario al SitePlayer.. •. Desconectar el adaptador del conector CON1 y volver a conectarlo, este power-on reset saca al microcontrolador de modo monitor y reinicia el SitePlayer.. 38.
(39) IEL1-03-II-24. APÉNDICE 2: CÓDIGO DE LIBRERÍAS SOFTWARE. El código de implementación de la memoria FLASH como EEPROM se encuentra disponible en la nota de aplicación de Motorola “FLASH as EEPROM” [8]. COMANDOS PARA EL SITEPLAYER Y CONFIGURACION MANUAL DE IP. ;************************************************************************** ;* COMSP.ASM: Comandos para el SP * ;* CVA - 2003 * ;* * ;* Rutinas: * ;* - SPiniciar Acciones de inicio del SP * ;* - SP20nops Envia 20 NOPS * ;* - SPstatus Pide y recibe byte de status * ;* - SPwrite Comando Write, pagina 0 * ;* - SPread Comando Read, pagina 0 * ;* - SPwriteX Comando WriteX, todo el espacio de direcciones * ;* - SPreadX Comando ReadX, todo el espacio de direcciones * ;* - SPhabUDP Habilita/deshabilita recepcion de datagramas UDP * ;* - SPenvUDP Envio de datagramas UDP * ;* - SPICconf Configuracion manual de IP * ;* * ;************************************************************************** Include 'comsp.inc' Include 'flashee.asm'a ;* Iniciacion del SP ========================================================== ;* ;* - Reset del SP por hardware, espera respuesta ;* - configura BR ;* - configura IP ;* ;* Se habilita la recepcion serial por defecto, pero no las interrupciones SPiniciar: ; ; Reset hardware del SP, 1 en PTC1 ; bset 1, PTC bset 1, DDRC ldx #$ff ; Delay para pulso de reset. SPiniCiclo0 lda #$ff dbnza * dbnzx SPiniCiclo0 bclr 1, DDRC ; PTC1 en alta impedancia ; ; Retardo de 1seg aprox para reset del SP (clk de 2.54 MHz) ; lda #14 ; contador temporal en la pila psha SPiniCiclo1 ldx #$ff SPiniCiclo2 lda #$ff dbnza * dbnzx SPiniCiclo2 dbnz 1,sp, SPiniCiclo1 pula ;. 39.
(40) IEL1-03-II-24. ; Configuracion de SCI local y del SP ; mov #$40, SCC1 ; Habilita SCI mov #$0C, SCC2 ; Habilita Tx, Rx, no interrupciones mov #$04, SCBR ; BR local inicial= 9600 brclr TC, mov #$33, brclr TC, mov #$F0, brclr TC, mov #$FF, brclr TC, mov #$18, brclr TC, mov #$FC,. SCS1, SCDR SCS1, SCDR SCS1, SCDR SCS1, SCDR SCS1, SCDR. *. ; Envia comando ComParams. *. ; Envia BR, #$FFF0 = 76800. * *. ; Envia Delay, #$FC18 = 300us. *. mov #$01, SCBR. ; BR local = 76800. lda #$ff dbnza * bsr SP20nops. ; Retardo y 20 nops para que se estabilice. ; ; Envia la direccion IP ; ldhx #SPMMIP ; Pone en la pila la pshx ; direccion en el SP del IP (para SPwriteX) pshh ldhx #EE_StartAddr1 lda #EE_BlockSize1 jsr EERead aix #1. ; Llamado a EERead ; retorna en H:X la direccion del dato (IP) ; y es pasado a SPwriteX ; pero incrementado en 1 para descartar el primer 00. lda #4 jsr SPwriteX ais #2 ; ; Asigna MAC de destino UDP = 255.255.255.255.255.255 (broadcast) ; lda #$FF ; MAC en la pila psha psha psha psha psha psha ldhx #SPMMUDPMAC pshx pshh. ; Pone en la pila la ; direccion en el SP del IP (para SPwriteX). tsx aix #2. ;. ; pone H:X a apuntar a la direccion de MAC en la pila. lda #6 jsr SPwriteX ais #2 ais #6. ; Para MAC en la pila. rts ;* 20 comandos NOP ============================================================= ;* ;* Envia 20 nops NOP ($00), util para terminar cualquier posible secuencia ;* de comandos y llevar el SP a un estado de escucha sin tener que hacer ;* reset ;* SP20nops: psha lda #20. 40.
(41) IEL1-03-II-24. SP20nops1: brclr TC, SCS1, * mov #$00, SCDR dbnza SP20nops1 pula rts ;* Comando STATUS =============================================================== ;* ;* Envia el comando de status ($10) y espera la respuesta, si despues de cierto ;* tiempo (300ms aprox, como 10 veces el tiempo tipico de respuesta) no ha ;* recibido respuesta, retorna error. ;* ;* Retorna: ;* - Acc: byte de status ;* - Flag C: 1 si error, 0 si no ;SPstatus: ; pshh ; pshx ; ; brclr TC, SCS1, * ; mov #$10, SCDR ; envia comando de status ; brclr TC, SCS1, * ; espera fin de envio ; ldhx #0 ;SPstatCiclo: ; aix #1 ; cphx #$FFFF ; beq SPstatError ; brclr SCRF, SCS1, SPstatCiclo ; ; lda SCDR ; clc ; ;SPstatSalir: ; pulx ; pulh ; rts ; ;SPstatError ; sec ; bra SPstatSalir. ; Espera respuesta ; y cuenta hasta $FFFF, si no llega ; en ese lapso, (aprox. 300ms), sale. ; Carga respuesta en Acc ; no hubo error. ; indica error en bit de C ; sale. ;* Comando Write ========================================================== ;* ;* Recibe ;* - H:X : direccion de datos a enviar ;* - Acc : Numero de datos a escribir ;* - Pila: Direccion (SP) donde se escribiran los datos (1 byte, pagina 0) ;* ;* Convencion de llamada: ;* ldx #DirSP ;* pshx ;* ldhx #DatosOrigen ;* lda #NumeroDatos ;* jsr SPWrite ;* ais #1 ;* ;* Cambia: ;* - Acc, H:X ;* SPwrite: psha ; Guarda # de datos para contador add #$7F brclr TC, SCS1, * sta SCDR brclr TC, SCS1, * lda 4, SP sta SCDR pula SPwciclo. ; Suma byte de comando (80h) + #bytes - 1 ; Envia comando WriteX. ; Envia direccion (SP) ; Saca # de datos ; y los envia. 41.
(42) IEL1-03-II-24. brclr TC, SCS1, * mov ,x+, SCDR dbnza SPwciclo rts ;* Comando Read ============================================================= ;* ;* Recibe ;* - H:X : direccion de datos a leer ;* - Acc : Numero de datos a leer ;* - Pila: Direccion (SP) de donde se leeran los datos (1 byte, pagina 0) ;* ;* Convencion de llamada: ;* ldx #DirSPorigen ;* pshx ;* ldhx #DatosDestino ;* lda #NumeroDatos ;* jsr SPread ;* ais #1 ;* ;* Cambia: ;* - Acc, H:X ;* ;SPread: ; psha ; Guarda # de datos para contador ; ; ;. add #$BF brclr TC, SCS1, * sta SCDR. ; ; ;. brclr TC, SCS1, * lda 4, SP sta SCDR. ; pula ;SPrciclo ; brclr SCRF, SCS1, * ; mov SCDR, x+ ; dbnza SPrciclo ;. ; Suma byte de comando (C0h) + #bytes - 1 ; Envia comando ReadX. ; Envia direccion (SP) ; Saca # de datos ; y los va leyendo. rts. ;* Comando WriteX ============================================================= ;* ;* Recibe ;* - H:X : direccion de datos a escribir ;* - Acc : Numero de datos a escribir ;* - Pila: Direccion (SP) donde se escribiran los datos (push LSB primero) ;* ;* Convencion de llamada: ;* ldhx #DirSPdestino ;* pshx ;* ldhx #DatosOrigen ;* lda #NumeroDatos ;* jsr SPwriteX ;* ais #1 ;* ;* Cambia: ;* - Acc, H:X (queda apuntando despues del ultimo dato, util para escribir bloques grandes) ;* SPwriteX: psha ; Guarda # de datos para contador add #$8F brclr TC, SCS1, * sta SCDR. ; Suma byte de comando (90h) + #bytes - 1 ; Envia comando WriteX. brclr TC, SCS1, * lda 5, SP. 42.
(43) IEL1-03-II-24. sta SCDR. ; Envia direccion (LSB). brclr TC, SCS1, * lda 4, SP sta SCDR. ; Envia direccion (MSB). pula SPwXciclo. ; Saca # de datos ; y los envia. brclr TC, SCS1, * mov ,x+, SCDR dbnza SPwXciclo rts ;* Comando ReadX ============================================================= ;* ;* Recibe ;* - H:X : direccion de datos a leer ;* - Acc : Numero de datos a leer ;* - Pila: Direccion (SP) de donde se leeran los datos (push LSB primero) ;* ;* Convencion de llamada: ;* ldhx #DirSPorigen ;* pshx ;* pshh ;* ldhx #DatosDestino ;* lda #NumeroDatos ;* jsr SPreadX ;* ais #2 ;* ;* Cambia: ;* - Acc, H:X (queda apuntando después del ultimo dato leido, util para leer bloques grandes) ;* SPreadX: psha ; Guarda # de datos para contador pshx pshh add #$CF brclr TC, SCS1, * sta SCDR. ; Suma byte de comando (D0h) + #bytes - 1 ; Envia comando ReadX. brclr TC, SCS1, * lda 7, SP sta SCDR. ; Envia direccion (LSB). brclr TC, SCS1, * lda 6, SP sta SCDR. ; Envia direccion (MSB). pula SPrXciclo. ; Saca # de datos ; y los va leyendo. brclr SCRF, SCS1, * mov SCDR, x+ dbnza SPrXciclo pulh pulx rts ;* Habilitacion de recepcion UDP ================================================== ;* ;* Habilita o deshabilita la recepcion de datagramas UDP escribiendo 1 o 0 ;* en la direccion $FF20 del SP ;* ;* Recibe: ;* - Acc: Valor a escribir en UDPrcvr: 1 habilita, 0 deshabilita ;* ;SPhabUDP. 43.
(44) IEL1-03-II-24. pshh pshx brclr TC, SCS1, * mov #$90, SCDR ldhx #SPMMUDPRCVR brclr TC, SCS1, * stx SCDR brclr TC, SCS1, * pshh pulx stx SCDR brclr TC, SCS1, * sta SCDR. ; Envia comando WriteX, 1byte ;Carga direccion de UdpRcvr ; Envia direccion (LSB) ; Envia direccion (LSB). pulx pulh rts ;* Envia un datagrama UDP ============================================================= ;* ;* Utiliza el comando UDPsend del SP, copia los datos en un buffer temporal en el SP ;* ubicado en la posicion SPMMUDPDAT (definida en comsp.inc). ;* ;* Recibe ;* - H:X : direccion de datos a escribir ;* - Acc : Numero de datos a escribir ;* - Pila: Apuntador al IP.puerto destino (2 bytes) ;* ;* Convencion de llamada: ;* ldhx #ApuntadorIP+puerto ;* pshx ;* pshh ;* ldhx #DatosOrigen ;* lda #NumeroDatos ;* jsr SPenvUDP ;* ais #2 ;* ;* Cambia: ;* - Acc, X ;* SPenvUDP: jsr SP20nops pshx pshh. ; Guarda apuntador a datos. ; ; Primero se arma en la pila un "paquete" con IP, puerto de destino, ; direccion del buffer de memoria y numero de datos (10 bytes en total) ; y luego se envia al SP con WriteX ; ldx 5, sp ; H:X -> IP.puerto pshx pulh ldx 6, sp psha ; guarda numero de datos psha ; mas un byte de 0 para completar lda #0 ; los dos bytes necesarios sta 2,sp lda #SPMMUDPDAT >> 8 ; guarda direccion del buffer de datos psha ; (MSB primero para que quede en el SP LSB primero) lda #SPMMUDPDAT & $ff psha lda 4,x ; se guarda el puerto, MSB primero para lo mismo psha lda 5,x psha. 44.
(45) IEL1-03-II-24. lda 3,x psha lda 2,x psha lda 1,x psha lda ,x psha tsx lda #SPMMUDPIP & $ff psha lda #SPMMUDPIP >> 8 psha lda #10 jsr SPwriteX ais #10 numero de datos pula ais #1 psha. ; H:X --> bloque para enviar ; Direccion donde se escribiran los datos (de configuracion). ; libera lo que se uso de la pila, excepto el. ; ; Ahora se copian los datos al buffer en la memoria del SP en grupos de 16 (maximo) ; ldx 2, sp ; H:X -> datos de origen pshx pulh ldx 3, sp lda #SPMMUDPDAT & $ff ; Pone en la pila la direccion inicial (SP) psha ; donde se escribiran los datos lda #SPMMUDPDAT >> 8 psha SPenvUDPciclo: lda 3,sp cmp #16 bls SPenvUDPult ; Si quedan mas de 16 datos, envia 16 lda #16 jsr SPwriteX lda 2,sp ; Incrementa en la pila el apuntador a los datos add #16 ; en el SP, H:X queda listo al salir de WriteX sta 2,sp lda 1,sp adc #0 sta 1,sp lda 3,sp ; decrementa contador de datos en 16 sub #16 sta 3,sp bra SPenvUDPciclo SPenvUDPult: ; envia el ultimo grupo de datos jsr SPwriteX ais #5 ; y libera espacio en pila ; ; Finalmente, se envia el comando UDPsend ; brclr TC, SCS1, * mov #$50, SCDR rts ;* ;* ;* ;* ;* ;* ;* ;* ;*. Configuracion manual de IP ========================================================== Permite configurar manualmente la direccion IP del SP con un teclado matricial externo. PTB4-7 salidas para el barrido de columnas PTA4-7 entradas de interrupcion (filas) Los digitos se introducen en notacion decimal, separados por * , para poder introducir el primer digito (o volver a empezar para corregir un error) hay. 45.
(46) IEL1-03-II-24. ;* que presionar # . ;* ;* La rutina de interrupcion de teclado solo debe interrumpir a esta rutina ;* (por la forma como se guardan las variables en la pila) ;* Solo se puede salir con un RESET externo ;* IPcont EQU 1 ; Direcciones de las variables relativas a SP IPbyte EQU 2 IPdir EQU 3 SPIPconf: sei ais #-7. ; deshabilita interrupciones ; espacio en pila para variables locales ; (este espacio nunca se libera). jsr SPiniciar sei lda sta lda sta. #0 IPbyte, SP #$FF IPcont, SP. ; ;Configuacion de interrupcion ; bset IMASKK, INTKBSCR mov #$f0, INTKBIER bset ACKK, INTKBSCR bclr IMASKK, INTKBSCR bclr MODEK, INTKBSCR mov #$F0, DDRB mov #$0F, DDRA mov #$00, PTB cli. ; contador en FF, byte no valido de teclado ; PTA4-7 generan interrupcion ; ; ; ;. habilita interrupciones. por flanco de bajada y nivel bajo salidas para barrido de columnas entradas para filas. ; habilita interrupciones. ; ; Ciclo de espera de interrupcion de teclado ; bra * ;* Atencion de interrupcion de teclado (PTA) ===================================== ;* ;* Lee del teclado los numeros presionados y va armando la direccion IP. ;* se anade un byte al IP cuando se completan 3 digitos o cuando se oprime * ;* cuando la lee toda, la guarda en FLASH ;* ;* En esta rutina, a las direcciones de variables en pila se les suma 5 para ;* compensar lo que guarda la atencion de interrupcion. ;* isrTec: lda #$FF dbnza *. ; delay para ayudar evitar ruido ; (ademas de que el harwdare tiene histeresis). ; ;Primero se determina la tecla presionada barriendo las columnas ; ; Primera columna mov #$E0, PTB brclr 4, PTA, IsrTec1 brclr 5, PTA, IsrTec4 brclr 6, PTA, IsrTec7 brclr 7, PTA, IsrTecAst ; Segunda columna mov #$D0, PTB brclr 4, PTA, IsrTec2 brclr 5, PTA, IsrTec5 brclr 6, PTA, IsrTec8 brclr 7, PTA, IsrTec0 ; Tercera columna mov #$B0, PTB. 46.
(47) IEL1-03-II-24. brclr 4, PTA, IsrTec3 brclr 5, PTA, IsrTec6 brclr 6, PTA, IsrTec9 brclr 7, PTA, IsrTecNum ; Cuarta columna (letras) jmp IsrTecSalir IsrTec9: IsrTec8: IsrTec7: IsrTec6: IsrTec5: IsrTec4: IsrTec3: IsrTec2: IsrTec1: IsrTec0:. inca inca inca inca inca inca inca inca inca. ; ; Si se presiono un digito, se multiplica por 10 y se suma al byte actual ; psha ldx IPbyte+6, SP ; IPbyte = IPbyte * 10 lda #10 mul sta IPbyte+6, SP pula add IPbyte+5, SP ; IPbyte += digito presionado sta IPbyte+5, SP bra IsrTecSalir ; ; Si se presiona Numero (#), renicia el contador para introducir un nuevo IP ; IsrTecNum: lda #0 sta IPcont+5, SP sta IPbyte+5, SP sta IPdir+5, SP ; Primer byte del IP en 00 (para flashEE) bra IsrTecSalir ; ; Si se presiono Asterisco (*), se almacena el byte y se pasa al siguiente ; Si se completan los 4 bytes, lo envia al SP y lo almacena en FLASH ; IsrTecAst: lda IPcont+5, SP ; Si IPcont==255 sale cmp #$ff ; es decir, si no se ha presionado # beq IsrTecSalir tsx aix #5+IPdir-1 lda IPcont+5, SP inca IsrTecAst1: aix #1 dbnza IsrTecAst1 lda IPbyte+5, SP sta ,x lda IPcont+5, SP cmp #03 beq IsrTecEnviar inc IPcont+5, SP clra sta IPbyte+5, SP bra IsrTecSalir IsrTecEnviar: lda #$ff sta IPcont+5, SP. ; almacena Byte en el vector (desplazado una posicion). ; si IPcont==3, envia el IP al SP y lo guarda en FLASH ; si no, incrementa el contador ; y borra el byte para recibir el siguiente. ; Envia el IP al SP. 47.
(48) IEL1-03-II-24. brclr 6, SCS1, * mov #$93, SCDR. ; Comando WriteX, 4 bytes. brclr 6, SCS1, * mov #$E6, SCDR brclr 6, SCS1, * mov #$FF, SCDR. ; Direccion, FFE6 (LSB primero). brclr 6, SCS1, lda IPdir+1+5, sta SCDR brclr 6, SCS1, lda IPdir+2+5, sta SCDR brclr 6, SCS1, lda IPdir+3+5, sta SCDR brclr 6, SCS1, lda IPdir+4+5, sta SCDR. ; Datos. * SP * SP * SP * SP. ldhx #EE_StartAddr1 pshx pshh tsx aix #IPdir+7-1 lda #EE_BlockSize1 jsr EEWrite ais #2. ; Escribe el IP en FlashEE. IsrTecSalir: clr PTB bset ACKK, INTKBSCR rti. ; Interrupt Acknowledge. ALGORITMO DE CIFRADO: AES ;****************************************************************** ;* AES - CVA ;****************************************************************** ; **************************************************************** ; Variables ; **************************************************************** MY_ZEROPAGE: SECTION SHORT tempa ds.b 1 ;variables de proposito general tempb ds.b 1 ap0 ds.b 1 ;apuntadores de proposito general ap1 ds.b 1 i ds.b 1 ;contadores para ciclos j ds.b 1 ronda ds.b 1 RAM: SECTION AESclave ds.b 176 bloquea ds.b 16 bloqueb ds.b 16 bloquec ds.b 16 ; ; ; ; ; ; ;. ;clave expandida de AES. ;vectores de bloque para AES. *************************************************************** * Rutinas de manejo de AES *************************************************************** ----------------------------------------------------------------------------Expansion de la clave AES, toma el vector constante AESclavei (16B) y deja la clave expandida en el vector (RAM) AESclave (176B). 48.
(49) IEL1-03-II-24. AESexpandirClave: pshh pshx ;Ronda 0: se copia la clave inicial en los primeros 16 bytes ldhx #$00; AESecR0: lda AESclavei,X sta AESclave,X incx cpx #16 blo AESecR0 ;Las 10 rondas restantes mov #0, i mov #16, ap0 AESecR1: ;clave[X] = FSb[clave[(ap0)-3]] ^ clave[(ap0-16)] ^ rcon[i]; pshx ldx ap0 lda AESclave-3,X tax lda AESfsb,X ldx ap0 eor AESclave-16,X ldx i eor AESrcon,X pulx sta AESclave,X incx ;clave[X] = FSb[clave[(ap0)-2]] ^ clave[(ap0)-15]; pshx ldx ap0 lda AESclave-2,X tax lda AESfsb,X ldx ap0 eor AESclave-15,X pulx sta AESclave,X incx ;clave[X] = FSb[clave[(ap0)-1]] ^ clave[(ap0)-14]; pshx ldx ap0 lda AESclave-1,X tax lda AESfsb,X ldx ap0 eor AESclave-14,X pulx sta AESclave,X incx ;clave[X] = FSb[clave[(ap0)-4]] ^ clave[(ap0)-13]; pshx ldx ap0 lda AESclave-4,X tax lda AESfsb,X ldx ap0 eor AESclave-13,X pulx sta AESclave,X incx ; for(j=4; j<16; j++) ; clave[X] = clave[ap0 + j-4] ^ clave[ap0+j-16]; mov #4, j. 49.
(50) IEL1-03-II-24. AESecR2: pshx lda ap0 add j tax lda AESclave-4,X eor AESclave-16,X pulx sta AESclave,X incx inc lda cmp blo inc lda add sta cmp blo. j j #16 AESecR2. i ap0 #16 ap0 #176 AESecR1. pulx pulh rts ; -----------------------------------------------------------------------------------------; Multiplicacion sobre el campo GF(256) ; usando las tablas logaritmica y exponencial ; Los parametros de entrada vienen en tempa,tempb, ; el resultado se retorna en tempa. ; AESmulGF: pshh pshx lda #0 cbeq tempa, AESmulGFret cbeq tempb, AESmulGFret ldhx #0 ldx tempa lda AEStl,X ldx tempb add AEStl,X bcs AESmulGFc tax lda AESte,X bra AESmulGFret. ;Retorna no-cero. ;Si no hay carry, retorna. AESmulGFc sub #255 tax lda AESte,X AESmulGFret: sta tempa sta tempb. ;Valores a retornar. pulx pulh rts ; -------------------------------------------------------------------------------------; Cifra un bloque de 16 bytes (128 bits) ; El bloque se recibe en bloquea y se retorna en bloqueb AEScifrar: pshh pshx ldhx #0. 50.
(51) IEL1-03-II-24. mov #1, ronda ;Ronda 0 (solo "add round key") ;for(i=0; i<16; i++) ; estado[i] = bloque[i] ^ clave[i]; AEScifrarR0: lda AESclave,X eor bloquea,X sta bloqueb,X incx cbeqx #16, AEScifrarR1 bra AEScifrarR0 ;//Rondas 1 a 9 ;for(ronda=1; ronda <=10; ronda++) AEScifrarR1: ; //"Sub Bytes" ; for(i=0; i<16; i++) ; estado[i] = FSb[estado[i]]; ldhx #0 AEScifrarSB: pshx lda bloqueb,X tax lda AESfsb,X pulx sta bloqueb,X incx cbeqx #16, AEScifrarSR bra AEScifrarSB ;//"Shift Row" AEScifrarSR: ; temp=estado[1]; ; estado[1]=estado[5]; ; estado[5]=estado[9]; ; estado[9]=estado[13]; ; estado[13]=temp; lda bloqueb+1 sta tempa lda bloqueb+5 sta bloqueb+1 lda bloqueb+9 sta bloqueb+5 lda bloqueb+13 sta bloqueb+9 lda tempa sta bloqueb+13 ; temp=estado[2]; ; estado[2]=estado[10]; ; estado[10]=temp; ; temp=estado[6]; ; estado[6]=estado[14]; ; estado[14]=temp; lda bloqueb+2 sta tempa lda bloqueb+10 sta bloqueb+2 lda tempa sta bloqueb+10 lda bloqueb+6 sta tempa lda bloqueb+14 sta bloqueb+6 lda tempa sta bloqueb+14 ; temp=estado[15]; ; estado[15]=estado[11]; ; estado[11]=estado[7];. 51.
(52) IEL1-03-II-24. ; estado[7]=estado[3]; ; estado[3]=temp; lda bloqueb+15 sta tempa lda bloqueb+11 sta bloqueb+15 lda bloqueb+7 sta bloqueb+11 lda bloqueb+3 sta bloqueb+7 lda tempa sta bloqueb+3 lda cmp bne jmp. ronda #10 *+5 AEScifrarARK. ;Si es ronda 10 va a "AddRoundKey". mov #0, i mov #0, ap0 mov #0, j mov #0, ap1 AEScifrarMC: ; A=MulGF(mmulf[i*4], ldx ap0 lda AESmmulf,X sta tempa ldx ap1 lda bloqueb,X sta tempb jsr AESmulGF psha. estado[j*4]. ). ; A=A ^ MulGF(mmulf[i*4+1], ldx ap0 lda AESmmulf+1,X sta tempa ldx ap1 lda bloqueb+1,X sta tempb jsr AESmulGF pula eor tempa psha. estado[j*4+1] ). ; A=A ^ MulGF(mmulf[i*4+2], ldx ap0 lda AESmmulf+2,X sta tempa ldx ap1 lda bloqueb+2,X sta tempb jsr AESmulGF pula eor tempa psha. estado[j*4+2] ). ; A=A ^ MulGF(mmulf[i*4+3], ldx ap0 lda AESmmulf+3,X sta tempa ldx ap1 lda bloqueb+3,X sta tempb jsr AESmulGF pula eor tempa sta tempa. estado[j*4+3] ). ; estemp[j*4+i] = resultado anterior (tempa) lda ap1 add i tax. 52.
(53) IEL1-03-II-24. lda tempa sta bloquec,X inc lda add sta. j ap1 #4 ap1. ;j=j+1, ap1=ap1+4. lda j ;si j=4 -> j=0, i++ cmp #4 bne AEScifrarMC inc lda add sta. i ap0 #4 ap0. mov #0,j mov #0, ap1 lda i cmp #4 bne AEScifrarMC ;for(i=0; i<16; i++) ;estado[i] = estemp[i]; ldhx #0 AEScifrarMC2 lda bloquec,X sta bloqueb,X incx cbeqx #16, AEScifrarARK bra AEScifrarMC2. AEScifrarARK lda ronda ldx #16 mul sta ap0. ;ap0= 16*ronda. ldhx #0 AEScifrarARK2 pshx stx tempa lda ap0 add tempa tax lda AESclave,X pulx eor bloqueb,X sta bloqueb,X incx cbeqx #16, AEScifrarSigRonda bra AEScifrarARK2 AEScifrarSigRonda inc lda cmp beq jmp. ronda ronda #11 AEScifrarFIN AEScifrarR1. AEScifrarFIN pulx pulh rts ; --------------------------------------------------------------------------------------; Descifra un bloque de 16 bytes (128 bits). 53.
(54) IEL1-03-II-24. ; El bloque se recibe en bloqueb y se retorna en bloquea ; void DescifrarBloque(unsigned char * bloque, unsigned char * estado) AESdescifrar: pshh pshx ldhx #0 mov #9, ronda ;//Ronda 0 (solo "add round key") ;for(i=0; i<16; i++) ; estado[i] = bloque[i] ^ clave[i+160]; AESdescifrarR0: lda AESclave+160,X eor bloqueb,X sta bloquea,X incx cbeqx #16, AESdescifrarR9 bra AESdescifrarR0 ;//Rondas 1 a 9 ;for(ronda=9; ronda >=0; ronda++) AESdescifrarR9: ;temp=estado[13]; ;estado[13]=estado[9]; ;estado[9]=estado[5]; ;estado[5]=estado[1]; ;estado[1]=temp; lda bloquea+13 sta tempa lda bloquea+9 sta bloquea+13 lda bloquea+5 sta bloquea+9 lda bloquea+1 sta bloquea+5 lda tempa sta bloquea+1 ; temp=estado[2]; ; estado[2]=estado[10]; ; estado[10]=temp; ; temp=estado[6]; ; estado[6]=estado[14]; ; estado[14]=temp; lda bloquea+2 sta tempa lda bloquea+10 sta bloquea+2 lda tempa sta bloquea+10 lda bloquea+6 sta tempa lda bloquea+14 sta bloquea+6 lda tempa sta bloquea+14 ;temp=estado[3]; ;estado[3]=estado[7]; ;estado[7]=estado[11]; ;estado[11]=estado[15]; ;estado[15]=temp; lda bloquea+3 sta tempa lda bloquea+7 sta bloquea+3 lda bloquea+11 sta bloquea+7 lda bloquea+15 sta bloquea+11 lda tempa sta bloquea+15. 54.
(55) IEL1-03-II-24. ; //"Sub Bytes" ; for(i=0; i<16; i++) ; estado[i] = RSb[estado[i]]; ldhx #0 AESdescifrarSB: pshx lda bloquea,X tax lda AESrsb,X pulx sta bloquea,X incx cbeqx #16, AESdescifrarARK bra AESdescifrarSB ; //"Add Round Key" ;for(i=0; i<16; i++) ; estado[i] = estado[i] ^ clave[16*ronda+i]; AESdescifrarARK lda ronda ldx #16 mul sta ap0. ;ap0= 16*ronda. ldhx #0 AESdescifrarARK2 pshx stx tempa lda ap0 add tempa tax lda AESclave,X pulx eor bloquea,X sta bloquea,X incx cbeqx #16, AESdescifrarMC bra AESdescifrarARK2. ; //"Mix column" (Excepto en la ronda 0) ; for(i=0; i<4; i++) ; for(j=0; j<4; j++) ; { ; estemp[j*4+i] = MulGF(mmulr[i*4], estado[j*4] ) ^ ; MulGF(mmulr[i*4+1], estado[j*4+1]) ^ ;. MulGF(mmulr[i*4+2],. ;. MulGF(mmulr[i*4+3],. estado[j*4+2]) ^ estado[j*4+3]); ; ; ;. } for(i=0; i<16; i++) estado[i] = estemp[i];. AESdescifrarMC lda cmp bne jmp. ronda #0 *+5 AESdescifrarFIN. ;Si es ronda 0 termina. mov #0, i mov #0, ap0 mov #0, j mov #0, ap1 AESdescifrarMC2: ; A=MulGF(mmulr[i*4], ldx ap0. 55. estado[j*4]. ).
Documento similar
"No porque las dos, que vinieron de Valencia, no merecieran ese favor, pues eran entrambas de tan grande espíritu […] La razón porque no vió Coronas para ellas, sería
Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en
De acuerdo con Harold Bloom en The Anxiety of Influence (1973), el Libro de buen amor reescribe (y modifica) el Pamphihis, pero el Pamphilus era también una reescritura y
entorno algoritmo.
Habiendo organizado un movimiento revolucionario en Valencia a principios de 1929 y persistido en las reuniones conspirativo-constitucionalistas desde entonces —cierto que a aquellas
The part I assessment is coordinated involving all MSCs and led by the RMS who prepares a draft assessment report, sends the request for information (RFI) with considerations,
De hecho, este sometimiento periódico al voto, esta decisión periódica de los electores sobre la gestión ha sido uno de los componentes teóricos más interesantes de la
Ciaurriz quien, durante su primer arlo de estancia en Loyola 40 , catalogó sus fondos siguiendo la división previa a la que nos hemos referido; y si esta labor fue de